JP3799010B2 - メッシュ型ネットワーク用ブリッジ - Google Patents
メッシュ型ネットワーク用ブリッジ Download PDFInfo
- Publication number
- JP3799010B2 JP3799010B2 JP2002369070A JP2002369070A JP3799010B2 JP 3799010 B2 JP3799010 B2 JP 3799010B2 JP 2002369070 A JP2002369070 A JP 2002369070A JP 2002369070 A JP2002369070 A JP 2002369070A JP 3799010 B2 JP3799010 B2 JP 3799010B2
- Authority
- JP
- Japan
- Prior art keywords
- bridge
- port
- mesh
- bpdu
- backup
- 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
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
-
- 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
- H04L12/4625—Single bridge functionality, e.g. connection of two networks over a single bridge
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0677—Localisation of faults
-
- 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
- H04L45/04—Interdomain routing, e.g. hierarchical routing
-
- 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/12—Shortest path evaluation
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、複数のブリッジが相互に回線接続されるメッシュ型ネットワークに回線接続され最短経路を構築するための手段と複数のメッシュ接続ポートとを有するブリッジに関する。
【０００２】
【従来の技術】
ネットワークの形態の一つとして、複数のブリッジが相互に回線接続されたメッシュ型ネットワークがある。なかでも、各ブリッジ間に少なくとも１つの回線を持つように複数のブリッジの全てが相互に回線接続されたフルメッシュ型ネットワーク（以下、ＦＭＮという）が良く知られている。図２３はこの種のＦＭＮの一例を示している。
【０００３】
ここでは、メッシュ接続されているブリッジをメッシュ型ネットワーク用ブリッジと称し、メッシュ接続されたネットワークを、それ以外の部分と区別する意味でメッシュ型ドメインと記述する。また、メッシュ型ドメインがフルメッシュで接続されている場合、ＦＭＮドメインと記述する場合がある。
【０００４】
図２４に示すように、各メッシュ型ネットワーク用ブリッジ３２は、メッシュ接続されるメッシュ接続ポート３３と、それ以外の非メッシュ接続ポート３４を有している。メッシュ接続ポート３３は、他のメッシュ型ネットワーク用ブリッジ３２と回線接続を行うために用いられる。また、非メッシュ接続ポート３４には、例えばノード３７やメッシュ型ネットワーク用ブリッジ３２ではない外部ネットワークを構築するためのブリッジ３６などが接続される。
【０００５】
ところで、複数のブリッジによる冗長経路を含むネットワークでは、経路を決定する際にスパニングツリープロトコル（ＳＴＰ）が一般的に用いられる。
【０００６】
例えば図２５に示すように、ＬＡＮ１とＬＡＮ２がブリッジＡによって接続され、ＬＡＮ１にパソコン等のノードｎ１が接続され、更にＬＡＮ２にハブＡが接続されたネットワークの場合、ノードｎ１から送信されたパケットは、ＬＡＮ１→ブリッジＡ→ＬＡＮ２→ハブＡを介してハブＡに接続されるパソコン等のノードｎ２を含むブロードキャストドメインの全てのノードに送信されることになる。そして、このようなネットワークに対して、ＬＡＮ１とＬＡＮ２との間にブリッジＡと並列にハブＢを接続すると、ノードｎ１から送信されたパケットは、ネットワーク上をループし、トラフィックが増大し、その結果、ノードｎ１以外のノード（ノードｎ１を除くその他のブロードキャストドメインのノード）からパケットを送信することができなくなる。
【０００７】
そこで、図２５に示すようなブリッジＡとハブＢでネットワークを構成した場合、あるノードから送信されたパケットがネットワーク上をループするのを防ぐためにスパニングツリープロトコルが用いられる。
【０００８】
また、図２６に示すように、パソコン等のノードｎ１が接続されたＬＡＮ１と、ハブＡが接続されたＬＡＮ２との間に２つのブリッジＡ，Ｂを並列に接続し、ノードｎ１とハブＡに接続されたパソコン等の各ノードｎ２，ｎ３，ｎ４，…との間で通信を行う場合、通常は一方のブリッジＡを使用して通信を行い、ブリッジＡがリンクダウンしたときにブリッジＢを使用して通信を行うことで、ネットワークに冗長性を持たせるためにスパニングツリープロトコルが用いられる。
【０００９】
ここで、スパニングツリープロトコルの基本的なアルゴリズムは下記（１）〜（５）からなる。
【００１０】
（１）Configuration Bridge Protocol Data Units（以下ＢＰＤＵ）という特別なフレームをブリッジ間で交換する。交換したＢＰＤＵにもとづいて以下の作業を行う。
（２）ネットワークのルートブリッジを選択する。ルートブリッジはブリッジ接続されたＬＡＮ全体に１個だけ存在する。
（３）各ブリッジはルートブリッジに至る最短経路を計算する（ルートブリッジへの最短経路を与えるポートはルートポートと呼ばれる）。
（４）各ＬＡＮに対し、そのＬＡＮに接続されているブリッジから「指定ブリッジ（designated bridge)」を選択する。
（５）各ブリッジはスパニングツリーに属するポート（指定ポート：designated port)とそうでないポート（ブロッキングポート：blocked port) を選択する。ブロッキングポートで受信したデータフレームはすべて廃棄される。また、ブロッキングポートからのフレームの送信は一切行われない。なお、受信したＢＰＤＵは一切フォワーディングされない。
【００１１】
上述したＢＰＤＵのデータ部分には少なくともルートＩＤ、ブリッジＩＤ、ルートパス・コストが含まれている。ルートＩＤは、ルートブリッジ（と仮定されたブリッジ）のＩＤであり、ブリッジのＭＡＣアドレスおよび管理者が指定する優先度から作成される。ブリッジＩＤは、ＢＰＤＵを送信したブリッジＩＤであり、ブリッジのＭＡＣアドレスおよび管理者が指定する優先度から作成される。ルートパス・コストは、ＢＰＤＵを送信したブリッジからルートブリッジに至る最短（と思われる）経路のコストである。
【００１２】
初期状態（電源投入時）では、各ブリッジは自分自身がルートブリッジであり、ルートパス・コストは０として動作する。各ブリッジは、ＢＰＤＵの初期値をすべてのポートに送信すると、ほかのブリッジから送信されたＢＰＤＵをすべてのポートから受信する。ブリッジがあるポートからよりよいＢＰＤＵを受信した場合、ブリッジはそのポートに対するＢＰＤＵの送信を停止し、その後自分自身が送信するＢＰＤＵの値を変更する。これにより、スパニングツリーが安定状態になった場合、スパニングツリーを構成するＬＡＮのなかで１個のブリッジのみが定期的にＢＰＤＵを送信するようになる。
【００１３】
上記ＢＰＤＵの優劣は、例えばＢＰＤＵ１とＢＰＤＵ２がある場合、下記（１）〜（４）の規則にもとづいて優劣の判断がなされる。
（１）ＢＰＤＵ１のルートＩＤがＢＰＤＵ２のルートＩＤよりも数値的に小さい場合には、ＢＰＤＵ１はＢＰＤＵ２よりもよいＢＰＤＵと判断される。
（２）ＢＰＤＵ１のルートＩＤがＢＰＤＵ２のルートＩＤと数値的に等しい場合には、ＢＰＤＵ１のルートパス・コストがＢＰＤＵ２のルートパス・コストよりも小さければ、ＢＰＤＵ１はＢＰＤＵ２よりもよいＢＰＤＵと判断される。
（３）ＢＰＤＵ１のルートＩＤがＢＰＤＵ２のルートＩＤと数値的に等しく、かつＢＰＤＵ１のルートパス・コストがＢＰＤＵ２のルートパス・コストと等しい場合には、ＢＰＤＵ１のブリッジＩＤがＢＰＤＵ２のブリッジＩＤよりも数値的に小さければ、ＢＰＤＵ１はＢＰＤＵ２よりもよいＢＰＤＵと判断される。
（４）ＢＰＤＵ１のルートＩＤがＢＰＤＵ２のルートＩＤと数値的に等しく、かつＢＰＤＵ１のルートパス・コストがＢＰＤＵ２のルートパス・コストと等しく、かつＢＰＤＵ１のブリッジＩＤがＢＰＤＵ２のブリッジＩＤと数値的に等しい場合には、ＢＰＤＵ１のポートＩＤがＢＰＤＵ２のポートＩＤよりも小さければ、ＢＰＤＵ１はＢＰＤＵ２よりもよいＢＰＤＵと判断される。
【００１４】
そして、各ブリッジは自身のＢＰＤＵの初期値と、全ポートから受信した他のブリッジからのＢＰＤＵを比較し、もっともよいＢＰＤＵからルートＩＤを選択する。次に、各ブリッジは、〈ルートパス・コスト〉＝〈もっともよいＢＰＤＵ中のルートパス・コスト〉＋パスコストに従って自分自身のルートパス・コストを計算する。なお、パスコストとは、各ポートが個別にもっているルートへのコストであり、その値は管理者が設定可能である。
【００１５】
いったんルートＩＤ、ルートポート、ルートパス・コストが定まると、これらの値にもとづいて各ブリッジはそれ以降に自分自身が送信するＢＰＤＵの内容を更新する。さらに、更新した自分自身のＢＰＤＵとルートポート以外のポートから受信したＢＰＤＵを比較し、ルートポート以外の各ポートに対して、自分自身が指定ブリッジになるかどうか判断する。指定ブリッジとなったポートは指定ポートと呼ばれ、指定ブリッジとならなかったポートはブロッキングポートと呼ばれる。
【００１６】
そして、ルートポート、指定ポート、ブロッキングポートに対する、ＢＰＤＵの送信およびデータフレームのフォワーディングは、ルートポートではＢＰＤＵを送信せずデータフレームをフォワーディングし、指定ポートではＢＰＤＵを送信してデータフレームをフォワーディングし、ブロッキングポートではＢＰＤＵを送信せずデータフレームをフォワーディングしない。
【００１７】
以上のようにしてスパニングツリーがいったん構成されると、各ブリッジは下記の（１）〜（４）に示す定常動作を行う。この定常動作は、ブリッジの故障や新たなブリッジの追加によっていったん構成したスパニングツリーを再構成するために必要な動作である。
【００１８】
（１）ＢＰＤＵには、「message age 」という要素が含まれている。この値は、ルートブリッジがこのＢＰＤＵに対応するＢＰＤＵを生成してからの経過時間を示す。
（２）ルートブリッジは、全ポートに対して、定期的に自分自身のＢＰＤＵを送信する。このとき、message age は０に設定される。
（３）各ブリッジは受信したＢＰＤＵを保存する。また、各ポートのＢＰＤＵのmessage age の値を時間の経過とともに増加させる（message age タイマー）。
（４）ルートブリッジ以外のブリッジは、ルートポートからＢＰＤＵを受信すると、自分自身のＢＰＤＵを全指定ポートに送信する。この際、message age の値には、ルートポートのmessage age と等しいかそれより大きく、受信ＢＰＤＵのmessage age よりも大きい値が使われる。
【００１９】
ここで、スパニングツリーの再構成は下記（１）、（２）に示すような場合に発生する。
【００２０】
（１）保存されているＢＰＤＵのmessage age タイマーがタイムアウトした場合（max age を超えた場合）
（２）あるポートに保存してあるＢＰＤＵよりもよいＢＰＤＵや、message age の値が小さなＢＰＤＵを同じポートから受信した場合
上記の事象が発生した場合、ブリッジはルートＩＤ、ルートパスコスト、ルートポートの再計算を行う。
【００２１】
ところで、スパニングツリーの構成（再構成）が開始されてからネットワーク上のすべてのブリッジが定常状態にならないうちに、データフレームの送信を行うのは非常に危険である。それは、スパニングツリー構成中には一時的なループが発生している可能性があるためである。したがって、各ブリッジは自分自身の指定ポートを決定してもすぐにはデータフレームのフォワーディングを開始しない。
【００２２】
ブリッジの各ポートの状態（ＳＴＰ状態）としては下記の５種類がある。
（１）listening ：データフレームに関する作業は何もおこなわない。
（２）learning：始点ＭＡＣアドレスの学習はおこなうがフォワーディングはおこなわない。
（３）forwarding：データフレームのフォワーディングもおこなう。
（４）Blocking：フォワーディングはおこなわないが、ＢＰＤＵの受信だけはおこなう。
（５）Disable：ポートを完全に閉塞した状態。一切のパケットの送受信をおこなわない。
listening 状態およびlearning状態の長さはforward delay と呼ばれ、ルートブリッジがその値を決定し、ＢＰＤＵにその値を入れて各ブリッジに伝える。
また、listening 状態およびlearning状態で用いられるタイマーはforwardingタイマーと呼ばれる。
【００２３】
スパニングツリーの再構成が発生すると、ホストの位置が変化し、旧い学習テーブルの内容が正しくなくなる場合がある。このため、スパニングツリーに対応しているブリッジは学習テーブルaging タイマーのタイムアウト値として以下の２種類の値をもっている。
（１）通常値：この値は数分といった長い時間に設定される。
（２）ＳＴＰ状態変化後に使用される値：この値はforward delay の値と同じ値になる。
【００２４】
ブリッジはスパニングツリーの再構成を検知すると、一定期間学習テーブルaging タイマーのタイムアウト値をforward delay と同じ値に設定する。
【００２５】
ところで、スパニングツリー・アルゴリズムは、下記（１）〜（５）に示すように、スパニングツリーの再構成が発生したことをすべてのブリッジに通知する仕組みをもっている。
【００２６】
（１）ブリッジがＳＴＰ状態の変化を検知すると、そのブリッジはＴＣＮ−ＢＰＤＵ(Topology Change Notification ＢＰＤＵ）と呼ばれるフレームをルートポートにhello time間隔で送信する。ルートポートからＴＣＡ(Topology Change Acknowledgment)フラグが立ったＢＰＤＵを受信するまでこれを継続する。
（２）ＴＣＮ−ＢＰＤＵを受信したブリッジもまた、ＴＣＮ−ＢＰＤＵをそれ自身のルートポートに送信する。一方、ＴＣＮ−ＢＰＤＵを受信したポートに対しては次のＢＰＤＵの送信時に、ＢＰＤＵのＴＣＡフラグを立ててＢＰＤＵを送信する。
（３）ルートブリッジはＴＣＮ−ＢＰＤＵを受信するか、あるいは自分自身のポートの状態が変化した場合、その時点からmax age ＋forward delay 時間のあいだＴＣ(Topology Change) フラグの立ったＢＰＤＵを送信する。
（４）ＴＣフラグの立ったＢＰＤＵをルートポートから受信したブリッジは、自分自身のＢＰＤＵについてもＴＣフラグを立てて送信する。これは、ルートポートからＴＣフラグが立っていないＢＰＤＵを受信するまで継続する。
（５）ルートポートからＴＣフラグの立ったＢＰＤＵを受信しているあいだ、ブリッジはforward delay の値を学習テーブルaging タイマーのタイムアウト値として用いる。
【００２７】
このように、スパニングツリーは、冗長なブリッジ・ネットワークにおいてループを自動的に取り除くとともに、機器の故障やケーブル不良などによるネットワーク・トポロジーの変更を自動的に検知し、ループが発生しないようにネットワーク・トポロジーを動的に変更するアルゴリズムである。
【００２８】
そして、上述したスパニングツリープロトコルを適用したＩＥＥＥ ８０２．１Ｄに従うネットワーク構成では、自動的に閉鎖ポートを作成し、ネットワークのループを回避し、ループのない経路が利用できるようになっている。
【００２９】
しかしながら、上述したスパニングツリーを適用したＩＥＥＥ ８０２．１Ｄを例えば図２７に示すようなＦＭＮに採用した構成では、ＦＭＮにおいて必ずしも最適ではない経路が出来てしまうという問題がある。
【００３０】
図２７はスパニングツリーを適用したＩＥＥＥ ８０２．１ＤをＦＭＮに採用した場合のネットワーク構成（図２３と同一）の一例を示している。なお、図２７において、ブリッジａ〜ｄがメッシュ型ネットワーク用ブリッジ３２である。図２７のネットワーク構成では、ブリッジａがルートブリッジとなり、ブリッジｂとブリッジｄとの間のブリッジｄ側のポート、ブリッジｂとブリッジｃとの間のブリッジｃ側のポート、ブリッジｃとブリッジｄとの間のブリッジｄ側のポートがスパニングツリープロトコルにより各々閉鎖ポートに設定される。
【００３１】
従って、図２７のネットワーク構成において、ノードａからノードｂに通信を行う場合、最短経路のブリッジｅ→ブリッジｄ→ブリッジｂを通らず、ブリッジｅ→ブリッジｄ→ブリッジａ→ブリッジｂを通る。このため、ノードａからノードｂへの通信が遠回りすることになり、遅延を生じるという問題があった。
【００３２】
また、上記従来のネットワーク構成では、一部のノードに対して過度な負荷がかかるという問題があった。例えば図２７のネットワーク構成の場合、スパニングツリープロトコルにより閉鎖ポートが設定されているので、ブリッジ間で通信を行う際にルートブリッジであるブリッジａを必ず経由することになり、ブリッジａに過度な負荷がかかる。しかも、一部の回線に対する負荷がかかり、効率的な回線利用が行えず、回線利用率の問題も招いていた。
【００３３】
さらに、上述したメッシュ型ネットワークをインターネット上に構築し、Ｌ２ＴＰ（Ｌａｙｅｒ２ Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ）を利用してイーサネット（Ｒ）フレームをインターネットに流すような場合には、余計な課金が生じるという問題があった。Ｌ２ＴＰは、ＥｔｈｅｒｎｅｔやＰＰＰなどのＬ２フレームをＩＰにカプセル化して、インターネットに送信する手段である。例えば図２７に示すメッシュ型ネットワークをインターネット上に構築した場合、ノードａからノードｂへの通信では、メッシュ型ネットワーク用ブリッジｄ→メッシュ型ネットワーク用ブリッジａの間と、メッシュ型ネットワーク用ブリッジａとメッシュ型ネットワーク用ブリッジｂとの間でインターネット上を通るため、２度の課金が生じて料金が倍になってしまう。
【００３４】
そこで、ＦＭＮにおけるフォワーディングの最適化を図るため、CE-based Virtual Private LAN(http://www.ietf.org/internet-draft/draft-lee-ce-based-vpl-00.txt)において、ＦＭＮブリッジ間の通信にＩＥＥＥ ８０２．１Ｄを改良したオプティマイズド・フォワーディングを利用するものが提案されている。この提案では、スパニングツリーを動作させないことを前提としている。
【００３５】
そして、このオプティマイズド・フォワーディングでは、ブリッジ間で通信を行う場合、ＦＭＮ上の最短経路を通り、かつループフリーになるように、以下のアルゴリズムが適用される。
【００３６】
（１）ＦＭＮ接続ポートから受信したユニキャストパケットをフラッティングするときは全ての非ＦＭＮ接続ポートにフラッティングする。他のＦＭＮ接続ポートにはフラッティングしない。
（２）ＦＭＮ接続ポートから受信したマルチキャストパケットをマルチキャストするときは全ての非ＦＭＮ接続ポートにマルチキャストする。他のＦＭＮ接続ポートにはマルチキャストしない。
（３）非ＦＭＮ接続ポートから受信したユニキャストパケットをフラッティングするときは全てのＦＭＮ接続ポートと非ＦＭＮ接続ポートにフラッティングする。
（４）非ＦＭＮ接続ポートから受信したマルチキャストパケットをマルチキャストするときは全てのＦＭＮ接続ポートと非ＦＭＮ接続ポートにマルチキャストする。回線効率をさらに向上させるため、ＩＧＭＰ Ｓｎｏｏｐｉｇを併用し、不要な配信を回避することを推奨する。
【００３７】
そして、上述したオプティマイズド・フォワーディングを図２３のＦＭＮに採用すれば、例えばブリッジｃと他のブリッジ（ブリッジａ、ブリッジｂ、ブリッジｄ）との間で通信を行う場合、ブリッジｃからのパケットを受けた各ブリッジは、パケットを他のメッシュ型ネットワーク用ブリッジにフラッティングしない。このため、ブリッジ間で通信を行う場合、遠回りによる遅延を生じることなく、最短経路を使用して通信を行うことができ、スパニングツリーを適用したＩＥＥＥ ８０２．１Ｄの問題を解消することができるという利点を有している。
【００３８】
【発明が解決しようとする課題】
しかしながら、オプティマイズド・フォワーディングを利用した場合でも、以下に説明するような問題点が考えられる。
【００３９】
上述したオプティマイズド・フォワーディングでは、スパニングツリーを動作させないことを前提とするので、ブリッジ間で通信を行う場合、回線障害が起きても冗長経路を使用できないという問題があった。例えば図２８のネットワーク構成において、ノードｃからノードｂに通信を行う場合、ブリッジｂとブリッジｃとの間で回線障害が起きると、ノードｃからのパケットはブリッジａおよびブリッジｄに対してフラッティングされるが、ブリッジａおよびブリッジｄが受けたパケットがブリッジｂにはフラッティングされない。このため、冗長経路を使用できず、ノードｃからのパケットをノードｂに送出することができない。
【００４０】
また、図２９に示すように、ブリッジａとブリッジｃとの間に新たにブリッジｆおよびブリッジｇを増設してバックアップ経路を形成すると、ブリッジａ、ブリッジｃ、ブリッジｆ、ブリッジｇによってループが形成される。しかしながら、上述したオプティマイズド・フォワーディングでは、スパニングツリーを動作させないことを前提とするので、万一ネットワーク上の経路にループが発生しても、そのループを検出して閉鎖ポートを設定することができない。このため、あるノードから送出されたパケットがループを形成する経路上に流れ、回線効率を低下させるという問題を招く。
【００４１】
そこで、本発明は、上記問題点に鑑みてなされたものであり、経路の遠回りによる遅延の減少、一部の装置に対する過度な負荷の減少、回線利用率の向上を図るとともに、メッシュ型ドメイン外部でのループを回避できるメッシュ型ネットワーク用ブリッジを提供することを目的としている。
【００４２】
【課題を解決するための手段】
上記目的のメッシュ型ドメイン外部でのループを回避するため、請求項１の発明は、複数のブリッジが相互に回線接続されるメッシュ型ネットワークに回線接続され、最短経路を構築するための手段と複数のメッシュ接続ポートとを有するメッシュ型ネットワーク用ブリッジにおいて、
前記複数のメッシュ接続ポートと該複数のメッシュ接続ポートと関連付けられた少なくとも１つの論理ポートとを記憶する論理ポート記憶部と、
前記複数のメッシュ接続ポートのいずれかのポートからＢＰＤＵを受信したときには該ＢＰＤＵを前記論理ポートから受信したと読み替える読み替え手段と、
前記読み替え手段からのＢＰＤＵを受信するＢＰＤＵ受信手段と、
前記メッシュ接続ポートから受信したＢＰＤＵに基づいて、前記論理ポートのＳＴＰ状態を決定するＳＴＰ情報管理手段と、
該ＳＴＰ情報管理手段から前記ＳＴＰ状態の情報を受けて記憶するＳＴＰ情報記憶部と、
前記ＳＴＰ情報管理手段で決定されたＳＴＰ状態に基づき、ＳＴＰに従ってＢＰＤＵを送信するＢＰＤＵ送信手段であって、前記論理ポートに送信するときは、同一のルートパスコストとポートプライオリティとを持つＢＰＤＵを、当該論理ポートに関連付けられた前記複数のメッシュ接続ポート全てから送信する前記ＢＰＤＵ送信手段と、
同一論理ポートに関連付けられた全てのメッシュ接続ポートを該論理ポートの状態に設定するポート状態設定手段と、
を有するＳＴＰ処理部を備えている。
【００４５】
【発明の実施の形態】
図１は、本発明の第１の実施の形態の概略構成を示すブロック図、図４は本発明によるメッシュ型ネットワーク用ブリッジを採用したメッシュ型ネットワークの一例を示す図、図５は図４のメッシュ型ネットワークにおいてスパニングツリープロトコル（ＳＴＰ）がメッシュ接続ポートを論理的に一つのポートと見なしてＢＰＤＵを送出する概念図、図６（ａ）〜（ｄ）はＢＰＤＵのフレーム・フォーマットを示す図、図７は本発明によるメッシュ型ネットワーク用ブリッジのＢＰＤＵの送信処理のフローチャート、図８は本発明によるメッシュ型ネットワーク用ブリッジのＢＰＤＵの受信処理のフローチャート、図９（ａ），（ｂ）は本発明によるメッシュ型ネットワーク用ブリッジを採用したメッシュ型ネットワークをＳＴＰから見た等価図、図１９は第１の実施の形態の論理ポート記憶部のフォーマットを示す図、図２０はＳＴＰ情報記憶部のフォーマットを示す図、図２１はメッシュ型ネットワーク用ブリッジが論理ポートを複数持つ場合を説明するための図、図２２はメッシュ型ネットワーク用ブリッジ間で回線が複数ある場合を説明するための図である。
【００４６】
スパニングツリープロトコルは、メッシュ型ドメイン内では前述のように適用されない。しかし、メッシュ型ドメイン外部とのループ回避が必要となるため、メッシュ型ドメイン外部を含むネットワーク全体としては、スパニングツリープロトコルのやり取りが必要となる。
【００４７】
本発明は、最短経路構築手段（オプティマイズド・フォワーディングをするための手段）を適用したメッシュ型ドメインとメッシュ型ドメイン外部とのループを回避するため、メッシュ型ドメインとメッシュ型ドメイン外部とを含むネットワーク全体にスパニングツリープロトコルを適用することを実現したものである。
【００４８】
以下に図１に基づいて第１の実施の形態を説明する。
最短経路構築手段１１は、パケット送受信手段１２からパケットを受け取り、パケットを適切なポートに対して出力処理する。このとき、ＩＥＥＥ ８０２．１Ｄ のルールに基づいたフォワーディング＆ラーニングが行われ、フォワーディングテーブルを参照し、宛先ポートが分かっているときは、その宛先ポートに出力し、宛先が不明なときは、フラッティング処理が行われる。ＩＥＥＥ ８０２．１Ｄ によれば、フラッティング処理は全ポートに対して出力が行われることになるが、前述しているオプティマイズド・フォワーディング・アルゴリズムの４つのルール（段落〔００３６〕参照）が適用されることで、最短経路を構築する。
【００４９】
パケット送受信手段１２は、自ポート（メッシュ接続ポート３、非メッシュ接続ポート４）に接続された他のメッシュ型ネットワーク用ブリッジ２、ノード７やメッシュ型ネットワーク用ブリッジ２以外のブリッジ６（例えば図２におけるブリッジ６ｅ）との間でのパケットの送受信を行う手段である。送受信されるパケットの種類としては、例えばＢＰＤＵ、後述する隣接通知パケットやバックアップ依頼・解除パケットを含むメッシュ制御パケット、その他のパケットなどである。
【００５０】
パケット送受信手段１２の内部的な動きとしては、第１の実施の形態では、受信したＢＰＤＵを受信ポート番号と共に読み替え手段１３に渡し、ＢＰＤＵ送信手段１５から渡されたＢＰＤＵを指定されたポートに送出する。
【００５１】
ＳＴＰ処理部５は、自ポート（メッシュ接続ポート３、非メッシュ接続ポート４）から受信したＢＰＤＵに基づいてＳＴＰ情報記憶部を管理し、ＳＴＰの状態を決定し、自ポートにＢＰＤＵを送出するスパニングツリープロトコルを制御する処理部である。同一論理ポートに関連付けられたメッシュ接続ポートは、論理的に１つのポートとして処理する。ＳＴＰ処理部５は、読み替え手段１３〜ＳＴＰ情報記憶部１９の７ブロックを有する。以下に各々のブロックについて説明する。
【００５２】
読み替え手段１３は、パケット送受信手段１２から受け取ったＢＰＤＵをＢＰＤＵ受信手段１４に渡す。このとき、受け取ったＢＰＤＵが論理ポート１０に関連付けられたメッシュ接続ポート３からのとき、関連付けられた論理ポート１０から受け取ったと読み替える。
【００５３】
ＢＰＤＵ受信手段１４は、読み替え手段１３からのＢＰＤＵを受信し、ＳＴＰ情報管理手段１６に受信ポート番号（読み替えられた場合、読み替えられた後の論理ポートの番号）とＢＰＤＵ全体を渡す。
【００５４】
ＢＰＤＵ送信手段１５は、ＳＴＰ情報管理手段１６の要求により、ＢＰＤＵをポートに送出するようにパケット送受信手段１２に依頼する。このとき送出先が論理ポート１０のときは、当該論理ポートに関連付けられている全てのメッシュ接続ポート３，３，３から同一のルートパスコストとポートプライオリティとを持つＢＰＤＵを送出するように依頼する。
【００５５】
ＳＴＰ情報管理手段１６は、ＢＰＤＵ受信手段１４から受け取った情報に基づいて、ＳＴＰ状態を決定し、ＳＴＰ情報記憶部１９に記憶する。以下の場合、スパニングツリープロトコルに従い、送出先ポート番号のポートにＢＰＤＵを送信することをＢＰＤＵ送信手段１５に要求する。
１）ＳＴＰ状態に変化が生じたとき
２）自身がルートブリッジのとき、タイマ駆動による定期的なハローパケットの送信
３）自身がルートブリッジでないときで、ハローパケットを受け取った場合、ルートブリッジ以外へ送信
【００５６】
ポート状態設定手段１７は、ＳＴＰ情報管理手段１６によって決定されたＳＴＰ状態をポート３，３，３，４に設定する。論理ポートに状態を設定するときは、論理ポート記憶部から当該論理ポート１０に関連付けられたメッシュ接続ポート３，３，３の番号（物理番号）を参照し、当該論理ポート１０に関連付けられている全てのメッシュ接続ポートを同一のＳＴＰ状態に合わせる。
【００５７】
論理ポート記憶部１８は、論理ポート１０と論理ポート１０に関連付けられた複数のメッシュ接続ポート３，３，３が図１９に示すようなテーブルとして記憶している。ブリッジ内には、複数の論理ポートがあっても良い。図４に示すようなメッシュ型ネットワークに本発明のメッシュ型ネットワーク用ブリッジを用いるときは、論理ポートは１つで足りるが、図２１に示すように２つのメッシュ型ネットワークを接続する位置に用いられるメッシュ型ネットワーク用ブリッジでは、２つの論理ポートが必要となる。そして、それぞれの論理ポート毎に異なるメッシュ接続ポートが関連付けられる。１つのメッシュ接続ポートに対して関連付けられる論理ポートは１つであって、複数の論理ポートに関連付けられることはない。
【００５８】
複数の論理ポートを持つ場合のオプティマイズド・フォワーディングは、２つの論理ポートを持つ図２１のメッシュ型ネットワーク用ブリッジ２ｃを例に説明すると、次のように行われる。
【００５９】
メッシュ型ネットワーク１ａに接続されているメッシュ接続ポートから受け取ったパケットは、該メッシュ接続ポートが関連付けられている論理ポートから受け取ったと見なされ、該論理ポートに関連付けられている（すなわち、メッシュ型ネットワーク１ａに接続されている）他のメッシュ接続ポートには送らない。そして、もう１つの論理ポートに関連付けられている（すなわち、メッシュ型ネットワーク１ｂに接続されている）全てのメッシュ接続ポートに送る。
【００６０】
論理ポートが複数ある場合の処理は、上記のように行えば良いが、図２１は、ブリッジ２ａとブリッジ２ｃが、メッシュ型ネットワーク１ａ，１ｂで相互接続されている例である。この場合、上記のように単純にオプティマイズド・フォワーディングを行った場合、ブリッジ２ａとブリッジ２ｃとの間でループが発生することになる。しかし、このような場合は、２つの論理ポートでスパニングツリープロトコルが適用され、一方が閉鎖ポートに設定されるため、ループが発生することはない。例えば、ブリッジ２ｃのメッシュ型ネットワーク１ａに接続されているメッシュ接続ポートが閉鎖ポートに設定された場合、ブリッジ２ｃからブリッジ２ｂへのデータは、ブリッジ２ａを経由して送られる。つまり、冗長経路を持ったネットワーク構成と等価になる。
【００６１】
ＳＴＰ情報記憶部１９は、ポート番号毎にポートの状態と最後に受けたＢＰＤＵに関する情報とを図２０に示すようなテーブルとして記憶している。
【００６２】
ここで、本実施の形態では、出力ＢＰＤＵも一つの論理ポートからの出力として処理し、全てのメッシュ接続ポートのポート番号（ＢＰＤＵ内のポートＩＤ）に同一の論理ポート番号を設定しているが、それを受信する接続先メッシュ型ネットワーク用ブリッジはＢＰＤＵ内のポート番号を無視するため、必ずしも同一のポート番号を設定する必要はない。
【００６３】
次に、メッシュ型ドメイン外部でのループ回避を行うために送出されるＢＰＤＵのフォーマット構成について図６（ａ）〜（ｄ）を参照しながら説明する。図６（ａ）はＢＰＤＵ本体のフレーム・フォーマットを示す図、図６（ｂ）はＢＰＤＵのデータに含まれるフラグ（flags）のフレーム・フォーマットを示す図、図６（ｃ）はＢＰＤＵのデータに含まれるルートＩＤ（root ID）、ブリッジＩＤ（bridge ID）のフレーム・フォーマットを示す図、図６（ｄ）はＳＴＰ状態の変化を検出したときに送信されるＴＣＮ−ＢＰＤＵのフレーム・フォーマットを示す図である。
【００６４】
図６（ａ）に示すように、ＢＰＤＵは、ヘッダ部分とデータ部分から構成される。図６（ｂ）に示すように、フラグは、ＴＣＡ、未使用領域、ＴＣから構成される。ＴＣＡのｂｉｔが立ったＢＰＤＵをルートポートから受信したブリッジは、ルートポートへのＴＣＮ−ＢＰＤＵの送信を停止する。ＴＣのｂｉｔが立ったＢＰＤＵをルートポートから受信したブリッジは、ＴＣフラグの立っていないＢＰＤＵを受信するまで、学習テーブルaging タイマーのタイムアウト値をforward delay の値に設定し、自分自身もＴＣフラグの立ったＢＰＤＵを送信する。
【００６５】
図６（ｃ）に示すように、ルートＩＤおよびブリッジＩＤは、上位２octet は管理者が設定するpriority、下位６octet はブリッジのＭＡＣアドレスである。ルートＩＤおよびブリッジＩＤは、上位２octet の管理者が設定するpriorityが優先され、ＭＡＣアドレスを含めた全体の大小によってブリッジの上位下位の判別ができるようになっている。例えば各ブリッジのＢＰＤＵのルートＩＤの上位２octet をデフォルトの状態とした場合、ルートＩＤのＭＡＣアドレスの一番小さいブリッジがルートブリッジとなる。
【００６６】
その他、ルートパス・コスト（root path cost）は、ルートへの最短（と思われる）コストである。ポートＩＤ（port ID）は、上位１octet は管理者が設定するpriority、下位１octet はブリッジに固有のＩＤである。このポートＩＤは、メッシュ接続の場合、受信時には無視されるので、下位１octet は設定の必要はないが、本実装による同一論理ポートに関連付けされた全てのメッシュ接続ポート３のときは、同一のＩＤが用いられる。
【００６７】
message age は、ルートブリッジからの経過時間を示し、単位は１／２５６秒である。したがって、この値が２５６の場合、ルートは１秒前にこのＢＰＤＵに対応するＢＰＤＵを送信したことになる。
【００６８】
max age は、ＢＰＤＵの有効期間を示し、単位は１／２５６秒である。また、hello timeは、ルートブリッジがＢＰＤＵを送信する時間間隔を示し、単位は１／２５６秒である。すなわち、ルートブリッジはhello time間隔でＢＰＤＵを送信する。
【００６９】
forward delay は、listening の期間、learningの期間、スパニングツリーの再構成が発生した場合の学習テーブルaging タイマーに用いられるパラメータを示し、単位は１／２５６秒である。
【００７０】
トポロジーチェンジタイマーは、図６（ｄ）に示すフラグのＴＣを立てる期間を計測するタイマーである。
【００７１】
また、メッシュ型ドメイン内で論理ポートが閉鎖ポートになる場合は、そのメッシュ型ネットワーク用ブリッジ２の同一の論理ポートに関連付けされた全てのメッシュ接続ポート３を閉鎖するようにし、同一の論理ポートに関連付けされたメッシュ接続ポート３を部分的には閉鎖しない。これにより、オプティマイズド・フォワーディングとの矛盾を回避している。
【００７２】
なお、上述したＢＰＤＵのポートＩＤとして与えられる上記論理ポートの論理ポート番号は、物理ポート（実際にメッシュ型ネットワーク用ブリッジ２と接続されるメッシュ接続ポート３）とは異なる番号か、もしくはメッシュ接続ポート番号（物理ポート）の中の代表番号を用いることができる。
【００７３】
次に、ＢＰＤＵ送信処理の動作について図７のフローチャートを参照しながら説明する。なお、図７において、Ｘは全てのポートにＢＰＤＵを出すため、処理ループを実現するための変数であり、Ｘ＝１，２，３，…ＭＡＸＰＯＲＴとインクリメントされながらループを回る。本実施の形態では、処理を簡単にするため、実装されているポート数をｎとするとｎに続くｎ＋１，ｎ＋２，・・・ＭＡＸＰＯＲＴを論理ポート番号としている。ＭＡＸＰＯＲＴは装置に実装しているポートの数＋論理ポートの数である。Ｎは全てのメッシュ接続ポートに同一ＢＰＤＵを出すためにメッシュ接続ポートを探しながらループするための変数である。
【００７４】
このＢＰＤＵ送信処理では、まずＸ＝１とし（ＳＴ１）、Ｘ≦ＭＡＸＰＯＲＴ（最大ポート）か否かを判別する（ＳＴ２）。Ｘ≦ＭＡＸＰＯＲＴでないと判断したときには（ＳＴ２−Ｎｏ）、すなわちポートが最大ポートを超えたと判断したときには処理を終了する。これに対し、Ｘ≦ＭＡＸＰＯＲＴと判断すると（ＳＴ２−Ｙｅｓ）、Ｘが論理ポートか否かを判別する（ＳＴ３）。すなわち、論理ポートのとき関連付けられた全てのメッシュ接続ポート３を一つのポートとするか否かを判別する。
【００７５】
そして、Ｘが論理ポートでないと判断すると（ＳＴ３−Ｎｏ）、Ｘがメッシュ接続ポートか否かを判別する（ＳＴ４）。メッシュ接続ポートでないと判断すると（ＳＴ４−Ｎｏ）、ポートＸ用（非メッシュ接続ポート番号）のＢＰＤＵをポートに送信し（ＳＴ５）、Ｘ＝Ｘ＋１にする（ＳＴ６）。その後、ＳＴ２の処理に戻る。メッシュ接続ポートと判断すると（ＳＴ４−Ｙｅｓ）、論理ポートに対する送信処理のところで送信されるので、ここでは送信せずＳＴ６の処理に移行する。Ｘが論理ポートと判断されると（ＳＴ３−Ｙｅｓ）、Ｎ＝１とし（ＳＴ７）、Ｎ≦ＭＡＸＰＯＲＴ（最大ポート数）か否かを判別する（ＳＴ８）。
【００７６】
そして、Ｎ≦ＭＡＸＰＯＲＴでないと判断すると（ＳＴ８−Ｎｏ）、ＳＴ６の処理に移行する。これに対し、Ｎ≦ＭＡＸＰＯＲＴと判断すると（ＳＴ８−Ｙｅｓ）、ポート番号Ｎが論理ポートＸに関連付けられたメッシュ接続ポートか否かを判別する（ＳＴ９）。ポート番号Ｎが論理ポートＸに関連付けられたメッシュ接続ポートと判断すると（ＳＴ９−Ｙｓｅ）、ポート番号ＮにポートＸ用（論理ポート番号）のＢＰＤＵを送信する（ＳＴ１０）。そして、Ｎ＝Ｎ＋１とし（ＳＴ１１）、ＳＴ８の処理に戻る。これに対し、ポート番号Ｎが論理ポートＸに関連付けられたメッシュ接続ポートでないと判断すると（ＳＴ９−Ｎｏ）、ＳＴ１１の処理に移行する。
【００７７】
次に、ＢＰＤＵ受信処理の動作について図８のフローチャートを参照しながら説明する。このＢＰＤＵ受信処理では、パケットを受信すると（ＳＴ２１）、ＢＰＤＵか否か判断する（ＳＴ２２）。ＢＰＤＵでないと判断すると（ＳＴ２２−Ｎｏ）、そのままパケットをフォワードする（ＳＴ２３）。ＢＰＤＵと判断すると（ＳＴ２２−Ｙｅｓ）、受信ポートがメッシュ接続ポート３か否か判別する（ＳＴ２４）。受信ポートがメッシュ接続ポート３と判断すると（ＳＴ２４−Ｙｅｓ）、受信ポート番号に関連付けられた論理ポート番号を用いる（ＳＴ２５）。これに対し、受信ポートがメッシュ接続ポート３でないと判断すると（ＳＴ２４−Ｎｏ）、受信ポート番号に実際の物理ポート番号を用いる（ＳＴ２６）。そして、上記のように受信ポートに用いる番号が決定すると、ＢＰＤＵ受信処理を行い（ＳＴ２７）、ＳＴＰ情報の管理を行い（ＳＴ２８）、ポートの状態を設定する（ＳＴ２９）、ＩＥＥＥ ８０２．１Ｄに準拠したスパニングツリープロトコルによるＢＰＤＵの受信処理が行われる。上記ＳＴ２９のポートの状態設定は、論理ポートに対する設定の場合、該論理ポートに関連付けされた全てのメッシュ接続ポートに設定することになる。
【００７８】
ここで、図９（ａ）に示すように、例えばブリッジ２ａとブリッジ２ｃとの間にバックアップ経路（外部ネットワーク）としてブリッジ６ｆおよびブリッジ６ｇ（いずれもメッシュ型ネットワーク用ブリッジ２ではない）を接続すると、ブリッジ２ａ、ブリッジ２ｃ、ブリッジ６ｆ、ブリッジ６ｇによってループが形成される。
【００７９】
しかし、本実施の形態のメッシュ型ネットワーク用ブリッジ２では、メッシュ接続ポート３から受信したＢＰＤＵは、関連付けられた論理ポートから受信したものと見なし、受信したＢＰＤＵに基づいてＳＴＰ状態を決定している。
【００８０】
これにより、スパニングツリープロトコルは、図９（ｂ）に示すように、一本のバス型ＬＡＮに対して複数台（図９（ｂ）の例ではブリッジ２ａ〜２ｄの４台）のメッシュ型ネットワーク用ブリッジが接続されているものとして認識する。そして、受信したＢＰＤＵに基づいて閉鎖ポートを設定する。図９（ｂ）の例では、ブリッジ６ｆとブリッジ６ｇとの間でブリッジ６ｇ側のポートを閉鎖ポートに設定する。
【００８１】
このように、本実施の形態のメッシュ型ネットワーク用ブリッジ２によれば、全てのメッシュ接続ポート３を論理的に一つのポートと見なし、全てのメッシュ接続ポート３に同一のＢＰＤＵを送出している。また、メッシュ接続ポート３から受信したＢＰＤＵは、全て関連付けられた一つの論理ポートから受信したものと見なし、受信したＢＰＤＵに基づいてＳＴＰ情報記憶部を構築している。
【００８２】
これにより、スパニングツリープロトコルは、一本のバス型ＬＡＮに対して複数台のメッシュ型ネットワーク用ブリッジ２が接続されているものとして認識し、受信したＢＰＤＵに基づいて閉鎖ポートを設定するので、メッシュ型ドメインとメッシュ型ドメイン外部とのループを回避することができる。しかも、メッシュ型ドメイン内において、メッシュ型ネットワーク用ブリッジ間に回線障害が無ければ、メッシュ型ネットワーク用ブリッジ間の最短経路で通信を行うことができる。これにより、経路の遠回りにより遅延の減少、一部の装置に対する過度な負荷の減少、回線利用率の向上を図ることができる。
【００８３】
ところで、上述した実施の形態では、メッシュ型ネットワーク１を構成する各メッシュ型ネットワーク用ブリッジ２，２間を接続する回線が一つの場合について図示して説明したが、各メッシュ型ネットワーク用ブリッジ２，２間を２つ以上の回線で接続する構成にしても良い。但し、対向接続されるメッシュ型ネットワーク用ブリッジ２，２間の回線を２本以上同一の論理ポートに関連付けるときは、Ｌｉｎｋ Ａｇｇｒｅｇａｔｉｏｎ（ＩＥＥＥ ８０２．３ａｄ）により束ねられている必要がある。Ｌｉｎｋ Ａｇｇｒｅｇａｔｉｏｎ により束ねられていると、対向接続されるメッシュ型ネットワーク用ブリッジ間の複数の回線が１つのポートと見なされる。そして本発明を適用すると、その１つのポートは、１つの論理ポートに関連付けられる。（図２２参照）
【００８４】
さて、前述したオプティマイズド・フォワーディングは、メッシュ型ドメイン内で送信すべき回線が利用可能であることが前提になっており、回線障害が発生すると通信が遮断され、その回線に接続されているブリッジへは到達不能となる。
【００８５】
そこで、本発明は、メッシュ型ネットワーク用ブリッジ２を採用したメッシュ型ネットワーク１で、回線障害を検出したメッシュ型ネットワーク用ブリッジ２は、継続してメッシュ型ドメイン内に残り、到達不能となったメッシュ型ネットワーク用ブリッジ２と接続している他のメッシュ型ネットワーク用ブリッジ２を経由して、到達不能になったブリッジにパケットを到達させる。
【００８６】
図２は、本発明の第２の実施の形態の概略構成を示すブロック図、図１０および図１１は本発明によるメッシュ型ネットワーク用ブリッジを採用したメッシュ型ネットワークにおいてバックアップ依頼による経路の形成を行った場合の説明図、図１２は本発明によるメッシュ型ネットワーク用ブリッジが持つバックアップ候補記憶部の一例を示す図、図１３は本発明によるメッシュ型ネットワーク用ブリッジが持つバックアップ受付テーブルの一例を示す図、図１４はメッシュ制御パケットのフォーマットを示す図、図１５は図１４のフォーマットにおいて隣接通知を行う場合のオプションのフォーマットを示す図、図１６は図１４のフォーマットにおいてバックアップ依頼・解除を行う場合のオプションのフォーマットを示す図、図１７は本発明によるメッシュ型ネットワーク用ブリッジの回線障害検出時のバックアップ依頼処理のフローチャート、図１８は本発明によるメッシュ型ネットワーク用ブリッジのバックアップ受付処理のフローチャートである。
【００８７】
以下に図２に基づいて第２の実施の形態を説明する。なお、第１の実施の形態と同じ部分については、その説明を省略するが、第２の実施形態では、パケット送受信手段１２の内部的な動きは、次のようになる。受信したバックアップ依頼パケットをバックアップ依頼受付手段２４に渡し、バックアップ依頼送出手段２３から渡されたバックアップ依頼パケットを指定されたポートに送出する。
【００８８】
回線障害検出手段２１は、自ポート（メッシュ接続ポート３、非メッシュ接続ポート４）とそのポートに接続されているポートとの間の回線障害を検出する手段であり、例えばポートを介してリンクダウンなどのイベントを検出すると、そのイベントをバックアップブリッジ選択手段２２に通知する。
【００８９】
なお、回線障害検出の方法としては、後述するメッシュ制御パケットの一種として用意される隣接ブリッジ通知用パケットをメッシュ型ネットワーク用ブリッジ２，２間で交換して相手ブリッジに一定時間内に届くか否かにより回線障害を検出するキープアライブによる検出、通常導通しているメッシュ型ネットワーク用ブリッジ２，２同志のポート間の接続が外れたときに発生する割込信号によって回線障害を検出するリンクダウンによる方法、定期的にやり取りするパケットが所定時間経過しても来ないことにより回線障害を検出する方法など様々なものが考えられる。
【００９０】
バックアップブリッジ選択手段２２は、回線障害検出手段２１から回線障害が発生したポート番号が通知されると、そのポートがメッシュ接続ポート３のとき、バックアップ候補記憶部２７から、通知されたポート番号に接続されている隣接ブリッジ（到達不能ブリッジ）を見つけ、その到達不能ブリッジをバックアップ候補に持つ隣接ブリッジを依頼先ブリッジとして選択し、バックアップ依頼送出手段２３に通知する。このとき、障害が通知された接続ポートに障害が発生したことを示すため、バックアップ候補記憶部２７の当該接続ポートの残り時間を“０”に書き換える。
【００９１】
バックアップ依頼送出手段２３は、バックアップブリッジ選択手段２２から到達不能ブリッジと依頼先ブリッジが通知されると、▲１▼依頼先ブリッジに対する、バックアップターゲットを到達不能ブリッジとし、バックアップソースを自分としたバックアップ依頼パケットの送信をパケット送受信手段１２に依頼し、▲２▼宛先が到達不能ブリッジであるパケットを受け取ったときには、（到達不能ブリッジへではなく）依頼先ブリッジに送出するような経路を形成するように経路制御手段２５に依頼する。
【００９２】
バックアップ依頼受付手段２４は、パケット送受信手段１２を経由して他のブリッジからのバックアップ依頼パケットを受け取ると、▲１▼該パケットを受信した接続ポートと該パケットで示されたバックアップターゲット（到達不能ブリッジ）とバックアップソース（依頼元ブリッジ）と監視用の残り時間とを合わせてバックアップ受付テーブル２８に登録し、▲２▼バックアップソースから宛先がバックアップターゲットであるパケットを受け取ったときにはバックアップターゲットに送出するような経路を形成するように経路制御手段２５に依頼する。受信したバックアップ依頼パケットが示すバックアップソースとバックアップターゲットの組み合せが既にバックアップ受付テーブル２８にある場合は、残り時間を初期値にする。残り時間を定期的に監視し残り時間がなくなったとき、または、パケット送受信手段１２からバックアップ解除依頼を受け取ったときは、バックアップ受付テーブル２８からそのバックアップ経路の項目（バックアップソース、バックアップターゲット、残り時間）を削除するとともに経路制御手段２５にバックアップ経路の停止を依頼する。
【００９３】
経路制御手段２５は、バックアップ依頼送出手段２３またはバックアップ依頼受付手段２４から、バックアップ経路の形成を依頼されたとき、依頼されたバックアップ経路を形成するように最短経路構築手段１１にオプティマイズド・フォワーディングの例外処理を依頼する。また、バックアップ経路の解除を要求されたときは、最短経路構築手段１１に、指定のバックアップ経路の例外処理を止めることを依頼する。
【００９４】
バックアップ候補記憶部制御手段２６は、メッシュ接続ポート３，３，３に回線接続されているブリッジが、自身の存在と、自身とメッシュ接続している他のブリッジ（隣接ブリッジ）の情報とを含む隣接通知パケットを定期的に送出し、隣接通知パケットを受け取ったとき、受信ポート番号、ソースアドレス、隣接ブリッジの情報を取り出し、受信ポートをバックアップ候補テーブルの接続ポートとして、ソースアドレスを該テーブルの隣接ブリッジとして、隣接ブリッジを該テーブルのバックアップ候補として、回線障害を検出するための残り時間とともにバックアップ候補記憶部２７に記憶する。また、バックアップ候補記憶部２７に記憶された残り時間を定期的に監視し、一定期間隣接通知パケットが通知されていないことを検出したとき、回線障害が発生したことを回線障害検出手段２１に通知する。
【００９５】
バックアップ候補記憶部２７は、前述のバックアップ候補テーブルを記憶している。該バックアップ候補テーブルは、図１２に示すように、接続ポート・隣接ブリッジ・バックアップ候補、および残り時間を書き込むようになっている。その書き込みについては、バックアップブリッジ選択手段２２とバックアップ候補記憶部制御手段２６の説明で述べたので省略する。
【００９６】
次に、本例のメッシュ型ネットワーク用ブリッジ２を採用したメッシュ型ネットワーク１内での回線障害を検出したときのバックアップ経路形成の動作について説明する。
【００９７】
本例のメッシュ型ネットワーク用ブリッジ２は、他のメッシュ型ネットワーク用ブリッジ２との間での回線障害を検出したときに、到達不能になったメッシュ型ネットワーク用ブリッジ２との間の迂回路（バックアップ経路）を別の到達可能なメッシュ型ネットワーク用ブリッジ２との間に形成するシグナリングプロトコルを有している。
【００９８】
このシグナリングプロトコルによるバックアップ要求時には、以下の処理が実行される。まず、後述する図１４に示すメッシュ制御パケットの一種として用意される隣接通知パケットをメッシュ型ネットワーク用ブリッジ２，２相互間で交換する（図１０参照）。この隣接通知パケットによる通知は、一定時間（例えば２秒）間隔で全てのメッシュ型ネットワーク用ブリッジ２に通知される。隣接通知パケットを受信したメッシュ型ネットワーク用ブリッジ２は、その隣接通知パケットを送ってきたメッシュ型ネットワーク用ブリッジ２の存在とそのメッシュ型ネットワーク用ブリッジ２との回線が利用可能であることを認識する。これに対し、隣接通知パケットによる通知が一定時間（例えば８秒）届かなければ、そのメッシュ型ネットワーク用ブリッジ２との間に回線障害が起きたことを検出する。
【００９９】
上記隣接通知パケットには、自分と隣接関係にある他のメッシュ型ネットワーク用ブリッジ２のブリッジＩＤ（ＭＡＣアドレス）が格納される。これにより、隣接通知パケットを受信したメッシュ型ネットワーク用ブリッジ２は、隣接通知パケットを送信したメッシュ型ネットワーク用ブリッジ２が到達不能ブリッジとなったときのバックアップ依頼先の情報が含まれるバックアップ候補テーブルを管理することが可能となる。
【０１００】
回線障害を検出したメッシュ型ネットワーク用ブリッジ２は、バックアップ候補テーブルから到達不能ブリッジへのバックアップが可能なメッシュ型ネットワーク用ブリッジ２を見つけ出し、バックアップ依頼を行う。例えば図１１に示すように、ブリッジ２ｃとブリッジ２ｄとの間で回線障害が発生した場合には、ブリッジ２ｃからブリッジ２ａに対してバックアップ依頼を行う。このバックアップ依頼は、到達不能ブリッジと自分のブリッジのＭＡＣアドレスをそれぞれ「バックアップターゲット」、「バックアップソース」として指定したバックアップ依頼パケットをブリッジ２ａに送出することで行なう。
【０１０１】
そして、バックアップ依頼を受けたメッシュ型ネットワーク用ブリッジ２ａは、「バックアップターゲット」と接続しているポートと「バックアップソース」と接続しているポートとの間でフラッティングとマルチキャストの配信を行い、バックアップ経路を形成する。
【０１０２】
この例では、バックアップしなければならない回線を指定するために、到達不能ブリッジを識別できる識別情報として、到達不能ブリッジのＭＡＣアドレスを用いているが、バックアップ対象回線を指定するために、回線番号を設定しておき、その回線番号を指定して、バックアップ依頼する方法もある。
【０１０３】
ここで、上述したバックアップ経路の形成時に用いられるバックアップ候補テーブルについて図１２を参照しながら説明する。このバックアップ候補テーブルは、メッシュ接続ポート３の数分だけ用意する。図１２はメッシュ接続ポート３が４つの場合の例を示している。隣接通知パケットをメッシュ接続ポート３から受信したときに、そのメッシュ接続ポートに接続されたメッシュ型ネットワーク用ブリッジ２を隣接ブリッジとして登録し、隣接通知パケット内の隣接ブリッジは、バックアップ候補として登録する。そして、残り時間を１０（例えば１０秒に相当）に初期化する。なお、残り時間は、毎秒減算され、再び隣接通知パケットをメッシュ接続ポート３から受信すると１０に再初期化される。
【０１０４】
この残り時間が“０”になったとき、つまり隣接通知パケットが１０秒間来ない場合、その接続ポートで回線障害が発生したこととする。
【０１０５】
次に、図１３に示すバックアップ受付テーブル２８について説明する。メッシュ型ネットワーク用ブリッジ２がバックアップ依頼を受け付けると、受信した接続ポート、バックアップターゲット、バックアップソースの情報と合わせて残り時間を記録する。
【０１０６】
また、バックアップソースのつながっているポートとバックアップターゲットのつながっているポートの間でのパケットのフラッディングとマルチキャストの経路の形成を経路制御手段２５に依頼する。
【０１０７】
上記バックアップ依頼は、所定時間（例えば２秒）毎に送られて来るので、その都度、残り時間を１０に初期化する。そして、バックアップ解除パケットを受けるか、残り時間が０になると、そのエントリを削除し、経路制御手段２５にバックアップソースのつながっているポートとバックアップターゲットのつながっているポートの間でのパケットのフラッディングとマルチキャストフォワーディングの停止を指示する。
【０１０８】
次に、上述した隣接通知パケットおよびバックアップ依頼パケットを含むメッシュ制御パケットについて図１４を参照しながら説明する。
【０１０９】
このメッシュ制御パケットは、図１４に示すように、あて先ソース、ソースアドレス、パケット長、ＬＬＣ ＤＳＡＰ、ＬＬＣ ＳＳＡＰ、ＬＬＣ制御、プロトコルＩＤ、プロトコルバージョン、コマンド、オプション、パディング、ＦＣＳによって構成される。以下に、一般的な用語の説明は省略し、本発明に関連して新しく作成した「コマンド」と「オプション」について説明する。
【０１１０】
本例では、上記メッシュ制御パケットのコマンドは、以下のコマンドコードを割り当てている。０ｘ００…隣接通知、０ｘ０１…バックアップ依頼、０ｘ０２…バックアップ解除。
【０１１１】
また、オプションは、コマンド毎に異なり、以下のように定義している。隣接通知では、隣接ブリッジリストをオプションに格納する。オプションフィールドのフォーマットは、例えば図１５に示すように構成される。例えば隣接ブリッジ数を０〜１５（最大）とし、隣接通知は２秒毎に行う。これにより、メッシュ型ネットワーク用ブリッジ２は、自分のバックアップ候補テーブルを参照し、隣接ブリッジの一覧を全メッシュ接続ポート３に送出する。
【０１１２】
バックアップ依頼・解除では、図１６に示すように、バックアップターゲットとバックアップソースをオプションに格納する。バックアップ依頼は、バックアップ候補から選択したブリッジに出力する。バックアップを依頼したメッシュ型ネットワーク用ブリッジ２から隣接通知パケットを受けると、バックアップターゲットが隣接に含まれているかチェックし、隣接していなかった場合は、バックアップ解除を送り、別の候補ブリッジを選択してバックアップ依頼を送り直す。また、バックアップ依頼にはレスポンスがないので、隣接通知パケットを受けるたびに毎回バックアップ依頼を送る。そして、バックアップ依頼を受けたメッシュ型ネットワーク用ブリッジ２は、バックアップ受付テーブル２８に記録し、バックアップターゲットと、バックアップソースの間のフォワーディングを開始する。バックアップ依頼が１０秒間来ない場合は、バックアップ処理を停止し、バックアップ受付テーブル２８から削除する。
【０１１３】
このように、上述したバックアップ依頼プロトコルによりバックアップ経路を形成することができる。
【０１１４】
回線障害検出時のバックアップ依頼の処理について図１７のフローチャートを参照しながら説明する。このバックアップ依頼の処理では、回線障害を検出すると（ＳＴ３１）、障害を検出したポートがメッシュ接続ポート３か否か判断する（ＳＴ３２）。メッシュ接続ポート３でないと判断すると（ＳＴ３２−Ｎｏ）、処理を終了する。メッシュ接続ポート３と判断すると（ＳＴ３２−Ｙｅｓ）、バックアップ候補テーブルを検索し、障害を検出したポートから隣接ブリッジ（到達不能ブリッジ）のアドレスを求め、アドレスをＸとする（ＳＴ３３）。このとき、回線障害を検出したポートであることを示すため残り時間を“０”にする。
【０１１５】
次に、バックアップ候補を選択する。ここでＮは、バックアップ候補テーブルに登録されている全てのメッシュ接続ポートを検索するため、Ｎ＝１，２，３，・・・ＭＡＸＰＯＲＴとインクリメントする変数である。Ｎを１にする（ＳＴ３４）。Ｎがメッシュ接続ポート数内かどうかを判断し（ＳＴ３５）、Ｎがメッシュ接続ポート数を超えたとき（ＳＴ３５−Ｎｏ）、処理を終了する。Ｎがメッシュ接続ポート内のとき（ＳＴ３５−Ｙｅｓ）、ポート番号Ｎに隣接ブリッジがあるか否か判断する（ＳＴ３６）。隣接ブリッジがないときは（ＳＴ３６−Ｎｏ）、Ｎを＋１し（ＳＴ４２）ＳＴ３５へ進む。隣接ブリッジがあるときは（ＳＴ３６−Ｙｅｓ）、その隣接ブリッジが回線接続されているか判断する（ＳＴ３７）。（回線障害が発生していないか調べるため、残り時間が“０”でないことを確認する。）回線接続されていないときは（ＳＴ３７−Ｎｏ）、Ｎを＋１し（ＳＴ４２）ＳＴ３５へ進む。回線接続されているときは（ＳＴ３７−Ｙｅｓ）、隣接ブリッジのアドレスをバックアップ候補アドレスＹとする（ＳＴ３８）。ポート番号Ｎのバックアップ候補の中に到達不能ブリッジＸがあるか検索する（ＳＴ３９）。バックアップ候補の中にＸがないときは（ＳＴ３９−Ｎｏ）、Ｎを＋１し（ＳＴ４２）ＳＴ３５へ進む。バックアップ候補の中にＸがあるときは（ＳＴ３９−Ｙｅｓ）、ＹとＸとの回線が接続されているので、ブリッジＹにブリッジＸのバックアップを依頼し（ＳＴ４０）、ブリッジＸへ送るパケットはブリッジＹに送る経路を形成し（ＳＴ４１）終了する。
【０１１６】
すなわち、このバックアップ依頼の処理では、回線障害を検出すると、まずバックアップ候補テーブルを見て、そのポートがメッシュ接続ポート３かどうかを確認する。そして、そのポートがメッシュ接続ポート３であれば、そのポートの隣接ブリッジのアドレス（Ｘ）を取り出し、今度はそのアドレス（Ｘ）と接続されている、つまり、Ｘをバックアップ候補に持つ回線接続された隣接ブリッジがあるかどうかを再びバックアップ候補テーブルから検索する。自分と回線接続されていて、かつ、到達不能ブリッジＸとも回線接続されている隣接ブリッジが見つかれば、その隣接ブリッジを依頼先ブリッジ（Ｙ）とする。そして、依頼先ブリッジが見つかると、自分のＭＡＣアドレスをバックアップソースとして、到達不能ブリッジのアドレス（Ｘ）をバックアップターゲットとして依頼先ブリッジ（Ｙ）に送信する。
【０１１７】
次に、バックアップ依頼を受け付ける処理ついて図１８のフローチャートを参照しながら説明する。このバックアップ依頼受付の処理では、バックアップ依頼パケットを受け取り（ＳＴ５１）、受信したポートをＳとし（ＳＴ５２）、バックアップ依頼パケットのターゲットブリッジをＸとする（ＳＴ５３）。
【０１１８】
次に、ターゲットブリッジの接続ポートを選択するため、ポート検索用変数Ｎを１にする（ＳＴ５４）。Ｎがメッシュ接続ポート数内かどうかを判断し（ＳＴ５５）、Ｎがメッシュ接続ポート数を超えたとき（ＳＴ５５−Ｎｏ）、処理を終了する。Ｎがメッシュ接続ポート内のとき（ＳＴ５５−Ｙｅｓ）、ポート番号Ｎの隣接ブリッジがＸか否か判断する（ＳＴ５６）。隣接ブリッジがＸでないときは（ＳＴ５６−Ｎｏ）、Ｎを＋１し（ＳＴ６０）、ＳＴ５５へ進む。隣接ブリッジがＸのときは（ＳＴ５６−Ｙｅｓ）、回線障害を検出しているかどうか判断する（ＳＴ５７）。残り時間を参照し、回線障害を検出しているとき（ＳＴ５７−Ｙｅｓ）、処理を終了する。回線障害を検出していないとき（ＳＴ５７−Ｎｏ）、ターゲットブリッジに接続されているポートをＴとする（ＳＴ５８）。ポートＳからきたブリッジＸへ送るパケットはポートＴに送る経路を形成し（ＳＴ５９）終了する。
【０１１９】
このように、本実施の形態によれば、回線障害を検出したメッシュ型ネットワーク用ブリッジ２は、到達不能ブリッジに隣接するメッシュ型ネットワーク用ブリッジ２を見つけ出し、この見つけ出したメッシュ型ネットワーク用ブリッジ２に対し、到達不能ブリッジのＭＡＣアドレスをバックアップターゲットとし、かつ自分のＭＡＣアドレスをバックアップソースとするバックアップ依頼パケットを送出している。そして、バックアップ依頼パケットを受けたメッシュ型ネットワーク用ブリッジ２は、バックアップ依頼パケットに含まれるバックアップターゲットと接続しているポートとバックアップソースと接続しているポートとの間でフラッティングとマルチキャストの配信を行ってバックアップ経路を形成している。これにより、回線障害時の経路のバックアップを行うことができる。
【０１２０】
以上、第１の実施の形態のブリッジは、メッシュ型ネットワークにオプティマイズド・フォワーディングを適用しながら、そのメッシュ型ネットワークに接続される外部のネットワーク全体にＳＴＰを適用できるようなメッシュ型ネットワーク用ブリッジであり、第２の実施の形態のブリッジは、メッシュ型ネットワークに全体としては、オプティマイズド・フォワーディングを適用しながら、回線障害が発生した場合でも通信が可能なメッシュ型ネットワーク用ブリッジである。図４は、第１の実施の形態と第２の実施の形態とを合わせたメッシュ型ネットワーク用ブリッジを示した。このようにすれば、前述の第１の実施の形態と第２の実施の形態の特長を合わせ持ったメッシュ型ネットワーク用ブリッジとすることができる。
【０１２１】
【発明の効果】
以上の説明で明らかなように、本発明によれば、メッシュ型ネットワーク用ブリッジ間の最短経路で通信を行うことで、経路の遠回りによる遅延の減少、一部の装置に対する過度な負荷の減少、回線利用率の向上を図るとともに、複数のメッシュ接続ポートを１つの論理ポートに関連付けることで、メッシュ型ドメインとメッシュ型ドメイン外部とでスパニングツリーを構築し、メッシュ型ドメイン外部でのループを回避することができる。
【図面の簡単な説明】
【図１】本発明によるメッシュ型ネットワーク用ブリッジの第１の実施の形態の概略構成を示すブロック図
【図２】本発明によるメッシュ型ネットワーク用ブリッジの第２の実施の形態の概略構成を示すブロック図
【図３】本発明によるメッシュ型ネットワーク用ブリッジの第１の実施の形態と第２の実施の形態とを合わせた形態の概略構成を示すブロック図
【図４】本発明によるメッシュ型ネットワーク用ブリッジを採用したメッシュ型ネットワークの一例を示す図
【図５】図４のメッシュ型ネットワークにおいてＳＴＰがメッシュ接続ポートを論理的に一つのポートと見なしてＢＰＤＵを送出する概念図
【図６】ＢＰＤＵのフレーム・フォーマットを示す図であり
（ａ）は、ＢＰＤＵ本体のフォーマット示す図
（ｂ）は、ＢＰＤＵに含まれる flags のフォーマットを示す図
（ｃ）は、ＢＰＤＵに含まれる root ID, bridge IDのフォーマットを示す図
（ｄ）は、ＴＣＮ−ＢＰＤＵのフォーマットを示す図
【図７】本発明によるメッシュ型ネットワーク用ブリッジを採用したメッシュ型ネットワークにおけるＢＰＤＵの送信処理のフローチャート
【図８】本発明によるメッシュ型ネットワーク用ブリッジを採用したメッシュ型ネットワークにおけるＢＰＤＵの受信処理のフローチャート
【図９】本発明によるメッシュ型ネットワーク用ブリッジを採用したメッシュ型ネットワークにおいてＳＴＰを動作させたときのネットワークの状態を説明するための図であり、
（ａ）は、メッシュ型ネットワークの一例を示す図
（ｂ）は、（ａ）の示したネットワークにおいてＳＴＰを動作させたときのネットワークの状態の等価図
【図１０】本発明によるメッシュ型ネットワーク用ブリッジを採用したメッシュ型ネットワークにおける隣接通知パケットとバックアップ候補テーブルとの関係の説明図
【図１１】本発明によるメッシュ型ネットワーク用ブリッジを採用したメッシュ型ネットワークにおいてバックアップ依頼による経路の復旧を行う場合の説明図
【図１２】本発明によるメッシュ型ネットワーク用ブリッジが持つバックアップ候補テーブルの一例を示す図
【図１３】本発明によるメッシュ型ネットワーク用ブリッジが持つバックアップ受付テーブルの一例を示す図
【図１４】メッシュ制御パケットのフォーマットを示す図
【図１５】図１４のフォーマットにおいて隣接通知を行う場合のオプションのフォーマットを示す図
【図１６】図１４のフォーマットにおいてバックアップ依頼・解除を行う場合のオプションのフォーマットを示す図
【図１７】本発明によるメッシュ型ネットワーク用ブリッジを採用したメッシュ型ネットワークにおける回線障害検出時のバックアップ依頼処理のフローチャート
【図１８】本発明によるメッシュ型ネットワーク用ブリッジを採用したメッシュ型ネットワークにおけるバックアップ受付処理のフローチャート
【図１９】本発明によるメッシュ型ネットワーク用ブリッジにおける論理ポートテーブルの一例を示す図
【図２０】本発明によるメッシュ型ネットワーク用ブリッジにおけるＳＴＰ情報テーブルの一例を示す図
【図２１】本発明によるメッシュ型ネットワーク用ブリッジを採用した２つのメッシュ型ネットワークを含むネットワークの一例を示す図
【図２２】本発明によるメッシュ型ネットワーク用ブリッジを採用したメッシュ型ネットワークにおいてブリッジ間で回線が複数ある場合を示す図
【図２３】ＦＭＮの一例を示す図
【図２４】ＦＭＮに使用されているメッシュ型ネットワーク用ブリッジの概念図
【図２５】スパニングツリーの目的を説明するための図
【図２６】スパニングツリーの目的を説明するための図
【図２７】スパニングツリーを適用したメッシュ型ネットワークの一例を示す図
【図２８】メッシュ型ネットワークにオプティマイズド・フォワーディングを採用した場合の問題点を説明するための図
【図２９】メッシュ型ネットワークにオプティマイズド・フォワーディングを採用した場合の問題点を説明するための図
【符号の説明】
１…メッシュ型ネットワーク、２…メッシュ型ネットワーク用ブリッジ、３…メッシュ接続ポート、４…非メッシュ接続ポート、５…ＳＴＰ処理部、６…非メッシュ型ネットワーク用ブリッジ、７…ノード、１０…論理ポート、１１…最短経路構築手段、１２…パケット送受信手段、１３…読み替え手段、１４…ＢＰＤＵ受信手段、１５…ＢＰＤＵ送信手段、１６…ＳＴＰ情報管理手段、１７…ポート状態設定手段、１８…論理ポート記憶部、１９…ＳＴＰ情報記憶部、２０…フォワーディングテーブル、２１…回線障害検出手段、２２…バックアップブリッジ選択手段、２３…バックアップ依頼送出手段、２４…バックアップ依頼受付手段、２５…経路制御手段、２６…バックアップ候補記憶部制御手段、２７…バックアップ候補記憶部、２８…バックアップ受付テーブル、３１…メッシュ型ネットワーク、３２…メッシュ型ネットワーク用ブリッジ、３３…メッシュ接続ポート、３４…非メッシュ接続ポート、３６…非メッシュ型ネットワーク用ブリッジ、３７…ノード。
【発明の属する技術分野】
本発明は、複数のブリッジが相互に回線接続されるメッシュ型ネットワークに回線接続され最短経路を構築するための手段と複数のメッシュ接続ポートとを有するブリッジに関する。
【０００２】
【従来の技術】
ネットワークの形態の一つとして、複数のブリッジが相互に回線接続されたメッシュ型ネットワークがある。なかでも、各ブリッジ間に少なくとも１つの回線を持つように複数のブリッジの全てが相互に回線接続されたフルメッシュ型ネットワーク（以下、ＦＭＮという）が良く知られている。図２３はこの種のＦＭＮの一例を示している。
【０００３】
ここでは、メッシュ接続されているブリッジをメッシュ型ネットワーク用ブリッジと称し、メッシュ接続されたネットワークを、それ以外の部分と区別する意味でメッシュ型ドメインと記述する。また、メッシュ型ドメインがフルメッシュで接続されている場合、ＦＭＮドメインと記述する場合がある。
【０００４】
図２４に示すように、各メッシュ型ネットワーク用ブリッジ３２は、メッシュ接続されるメッシュ接続ポート３３と、それ以外の非メッシュ接続ポート３４を有している。メッシュ接続ポート３３は、他のメッシュ型ネットワーク用ブリッジ３２と回線接続を行うために用いられる。また、非メッシュ接続ポート３４には、例えばノード３７やメッシュ型ネットワーク用ブリッジ３２ではない外部ネットワークを構築するためのブリッジ３６などが接続される。
【０００５】
ところで、複数のブリッジによる冗長経路を含むネットワークでは、経路を決定する際にスパニングツリープロトコル（ＳＴＰ）が一般的に用いられる。
【０００６】
例えば図２５に示すように、ＬＡＮ１とＬＡＮ２がブリッジＡによって接続され、ＬＡＮ１にパソコン等のノードｎ１が接続され、更にＬＡＮ２にハブＡが接続されたネットワークの場合、ノードｎ１から送信されたパケットは、ＬＡＮ１→ブリッジＡ→ＬＡＮ２→ハブＡを介してハブＡに接続されるパソコン等のノードｎ２を含むブロードキャストドメインの全てのノードに送信されることになる。そして、このようなネットワークに対して、ＬＡＮ１とＬＡＮ２との間にブリッジＡと並列にハブＢを接続すると、ノードｎ１から送信されたパケットは、ネットワーク上をループし、トラフィックが増大し、その結果、ノードｎ１以外のノード（ノードｎ１を除くその他のブロードキャストドメインのノード）からパケットを送信することができなくなる。
【０００７】
そこで、図２５に示すようなブリッジＡとハブＢでネットワークを構成した場合、あるノードから送信されたパケットがネットワーク上をループするのを防ぐためにスパニングツリープロトコルが用いられる。
【０００８】
また、図２６に示すように、パソコン等のノードｎ１が接続されたＬＡＮ１と、ハブＡが接続されたＬＡＮ２との間に２つのブリッジＡ，Ｂを並列に接続し、ノードｎ１とハブＡに接続されたパソコン等の各ノードｎ２，ｎ３，ｎ４，…との間で通信を行う場合、通常は一方のブリッジＡを使用して通信を行い、ブリッジＡがリンクダウンしたときにブリッジＢを使用して通信を行うことで、ネットワークに冗長性を持たせるためにスパニングツリープロトコルが用いられる。
【０００９】
ここで、スパニングツリープロトコルの基本的なアルゴリズムは下記（１）〜（５）からなる。
【００１０】
（１）Configuration Bridge Protocol Data Units（以下ＢＰＤＵ）という特別なフレームをブリッジ間で交換する。交換したＢＰＤＵにもとづいて以下の作業を行う。
（２）ネットワークのルートブリッジを選択する。ルートブリッジはブリッジ接続されたＬＡＮ全体に１個だけ存在する。
（３）各ブリッジはルートブリッジに至る最短経路を計算する（ルートブリッジへの最短経路を与えるポートはルートポートと呼ばれる）。
（４）各ＬＡＮに対し、そのＬＡＮに接続されているブリッジから「指定ブリッジ（designated bridge)」を選択する。
（５）各ブリッジはスパニングツリーに属するポート（指定ポート：designated port)とそうでないポート（ブロッキングポート：blocked port) を選択する。ブロッキングポートで受信したデータフレームはすべて廃棄される。また、ブロッキングポートからのフレームの送信は一切行われない。なお、受信したＢＰＤＵは一切フォワーディングされない。
【００１１】
上述したＢＰＤＵのデータ部分には少なくともルートＩＤ、ブリッジＩＤ、ルートパス・コストが含まれている。ルートＩＤは、ルートブリッジ（と仮定されたブリッジ）のＩＤであり、ブリッジのＭＡＣアドレスおよび管理者が指定する優先度から作成される。ブリッジＩＤは、ＢＰＤＵを送信したブリッジＩＤであり、ブリッジのＭＡＣアドレスおよび管理者が指定する優先度から作成される。ルートパス・コストは、ＢＰＤＵを送信したブリッジからルートブリッジに至る最短（と思われる）経路のコストである。
【００１２】
初期状態（電源投入時）では、各ブリッジは自分自身がルートブリッジであり、ルートパス・コストは０として動作する。各ブリッジは、ＢＰＤＵの初期値をすべてのポートに送信すると、ほかのブリッジから送信されたＢＰＤＵをすべてのポートから受信する。ブリッジがあるポートからよりよいＢＰＤＵを受信した場合、ブリッジはそのポートに対するＢＰＤＵの送信を停止し、その後自分自身が送信するＢＰＤＵの値を変更する。これにより、スパニングツリーが安定状態になった場合、スパニングツリーを構成するＬＡＮのなかで１個のブリッジのみが定期的にＢＰＤＵを送信するようになる。
【００１３】
上記ＢＰＤＵの優劣は、例えばＢＰＤＵ１とＢＰＤＵ２がある場合、下記（１）〜（４）の規則にもとづいて優劣の判断がなされる。
（１）ＢＰＤＵ１のルートＩＤがＢＰＤＵ２のルートＩＤよりも数値的に小さい場合には、ＢＰＤＵ１はＢＰＤＵ２よりもよいＢＰＤＵと判断される。
（２）ＢＰＤＵ１のルートＩＤがＢＰＤＵ２のルートＩＤと数値的に等しい場合には、ＢＰＤＵ１のルートパス・コストがＢＰＤＵ２のルートパス・コストよりも小さければ、ＢＰＤＵ１はＢＰＤＵ２よりもよいＢＰＤＵと判断される。
（３）ＢＰＤＵ１のルートＩＤがＢＰＤＵ２のルートＩＤと数値的に等しく、かつＢＰＤＵ１のルートパス・コストがＢＰＤＵ２のルートパス・コストと等しい場合には、ＢＰＤＵ１のブリッジＩＤがＢＰＤＵ２のブリッジＩＤよりも数値的に小さければ、ＢＰＤＵ１はＢＰＤＵ２よりもよいＢＰＤＵと判断される。
（４）ＢＰＤＵ１のルートＩＤがＢＰＤＵ２のルートＩＤと数値的に等しく、かつＢＰＤＵ１のルートパス・コストがＢＰＤＵ２のルートパス・コストと等しく、かつＢＰＤＵ１のブリッジＩＤがＢＰＤＵ２のブリッジＩＤと数値的に等しい場合には、ＢＰＤＵ１のポートＩＤがＢＰＤＵ２のポートＩＤよりも小さければ、ＢＰＤＵ１はＢＰＤＵ２よりもよいＢＰＤＵと判断される。
【００１４】
そして、各ブリッジは自身のＢＰＤＵの初期値と、全ポートから受信した他のブリッジからのＢＰＤＵを比較し、もっともよいＢＰＤＵからルートＩＤを選択する。次に、各ブリッジは、〈ルートパス・コスト〉＝〈もっともよいＢＰＤＵ中のルートパス・コスト〉＋パスコストに従って自分自身のルートパス・コストを計算する。なお、パスコストとは、各ポートが個別にもっているルートへのコストであり、その値は管理者が設定可能である。
【００１５】
いったんルートＩＤ、ルートポート、ルートパス・コストが定まると、これらの値にもとづいて各ブリッジはそれ以降に自分自身が送信するＢＰＤＵの内容を更新する。さらに、更新した自分自身のＢＰＤＵとルートポート以外のポートから受信したＢＰＤＵを比較し、ルートポート以外の各ポートに対して、自分自身が指定ブリッジになるかどうか判断する。指定ブリッジとなったポートは指定ポートと呼ばれ、指定ブリッジとならなかったポートはブロッキングポートと呼ばれる。
【００１６】
そして、ルートポート、指定ポート、ブロッキングポートに対する、ＢＰＤＵの送信およびデータフレームのフォワーディングは、ルートポートではＢＰＤＵを送信せずデータフレームをフォワーディングし、指定ポートではＢＰＤＵを送信してデータフレームをフォワーディングし、ブロッキングポートではＢＰＤＵを送信せずデータフレームをフォワーディングしない。
【００１７】
以上のようにしてスパニングツリーがいったん構成されると、各ブリッジは下記の（１）〜（４）に示す定常動作を行う。この定常動作は、ブリッジの故障や新たなブリッジの追加によっていったん構成したスパニングツリーを再構成するために必要な動作である。
【００１８】
（１）ＢＰＤＵには、「message age 」という要素が含まれている。この値は、ルートブリッジがこのＢＰＤＵに対応するＢＰＤＵを生成してからの経過時間を示す。
（２）ルートブリッジは、全ポートに対して、定期的に自分自身のＢＰＤＵを送信する。このとき、message age は０に設定される。
（３）各ブリッジは受信したＢＰＤＵを保存する。また、各ポートのＢＰＤＵのmessage age の値を時間の経過とともに増加させる（message age タイマー）。
（４）ルートブリッジ以外のブリッジは、ルートポートからＢＰＤＵを受信すると、自分自身のＢＰＤＵを全指定ポートに送信する。この際、message age の値には、ルートポートのmessage age と等しいかそれより大きく、受信ＢＰＤＵのmessage age よりも大きい値が使われる。
【００１９】
ここで、スパニングツリーの再構成は下記（１）、（２）に示すような場合に発生する。
【００２０】
（１）保存されているＢＰＤＵのmessage age タイマーがタイムアウトした場合（max age を超えた場合）
（２）あるポートに保存してあるＢＰＤＵよりもよいＢＰＤＵや、message age の値が小さなＢＰＤＵを同じポートから受信した場合
上記の事象が発生した場合、ブリッジはルートＩＤ、ルートパスコスト、ルートポートの再計算を行う。
【００２１】
ところで、スパニングツリーの構成（再構成）が開始されてからネットワーク上のすべてのブリッジが定常状態にならないうちに、データフレームの送信を行うのは非常に危険である。それは、スパニングツリー構成中には一時的なループが発生している可能性があるためである。したがって、各ブリッジは自分自身の指定ポートを決定してもすぐにはデータフレームのフォワーディングを開始しない。
【００２２】
ブリッジの各ポートの状態（ＳＴＰ状態）としては下記の５種類がある。
（１）listening ：データフレームに関する作業は何もおこなわない。
（２）learning：始点ＭＡＣアドレスの学習はおこなうがフォワーディングはおこなわない。
（３）forwarding：データフレームのフォワーディングもおこなう。
（４）Blocking：フォワーディングはおこなわないが、ＢＰＤＵの受信だけはおこなう。
（５）Disable：ポートを完全に閉塞した状態。一切のパケットの送受信をおこなわない。
listening 状態およびlearning状態の長さはforward delay と呼ばれ、ルートブリッジがその値を決定し、ＢＰＤＵにその値を入れて各ブリッジに伝える。
また、listening 状態およびlearning状態で用いられるタイマーはforwardingタイマーと呼ばれる。
【００２３】
スパニングツリーの再構成が発生すると、ホストの位置が変化し、旧い学習テーブルの内容が正しくなくなる場合がある。このため、スパニングツリーに対応しているブリッジは学習テーブルaging タイマーのタイムアウト値として以下の２種類の値をもっている。
（１）通常値：この値は数分といった長い時間に設定される。
（２）ＳＴＰ状態変化後に使用される値：この値はforward delay の値と同じ値になる。
【００２４】
ブリッジはスパニングツリーの再構成を検知すると、一定期間学習テーブルaging タイマーのタイムアウト値をforward delay と同じ値に設定する。
【００２５】
ところで、スパニングツリー・アルゴリズムは、下記（１）〜（５）に示すように、スパニングツリーの再構成が発生したことをすべてのブリッジに通知する仕組みをもっている。
【００２６】
（１）ブリッジがＳＴＰ状態の変化を検知すると、そのブリッジはＴＣＮ−ＢＰＤＵ(Topology Change Notification ＢＰＤＵ）と呼ばれるフレームをルートポートにhello time間隔で送信する。ルートポートからＴＣＡ(Topology Change Acknowledgment)フラグが立ったＢＰＤＵを受信するまでこれを継続する。
（２）ＴＣＮ−ＢＰＤＵを受信したブリッジもまた、ＴＣＮ−ＢＰＤＵをそれ自身のルートポートに送信する。一方、ＴＣＮ−ＢＰＤＵを受信したポートに対しては次のＢＰＤＵの送信時に、ＢＰＤＵのＴＣＡフラグを立ててＢＰＤＵを送信する。
（３）ルートブリッジはＴＣＮ−ＢＰＤＵを受信するか、あるいは自分自身のポートの状態が変化した場合、その時点からmax age ＋forward delay 時間のあいだＴＣ(Topology Change) フラグの立ったＢＰＤＵを送信する。
（４）ＴＣフラグの立ったＢＰＤＵをルートポートから受信したブリッジは、自分自身のＢＰＤＵについてもＴＣフラグを立てて送信する。これは、ルートポートからＴＣフラグが立っていないＢＰＤＵを受信するまで継続する。
（５）ルートポートからＴＣフラグの立ったＢＰＤＵを受信しているあいだ、ブリッジはforward delay の値を学習テーブルaging タイマーのタイムアウト値として用いる。
【００２７】
このように、スパニングツリーは、冗長なブリッジ・ネットワークにおいてループを自動的に取り除くとともに、機器の故障やケーブル不良などによるネットワーク・トポロジーの変更を自動的に検知し、ループが発生しないようにネットワーク・トポロジーを動的に変更するアルゴリズムである。
【００２８】
そして、上述したスパニングツリープロトコルを適用したＩＥＥＥ ８０２．１Ｄに従うネットワーク構成では、自動的に閉鎖ポートを作成し、ネットワークのループを回避し、ループのない経路が利用できるようになっている。
【００２９】
しかしながら、上述したスパニングツリーを適用したＩＥＥＥ ８０２．１Ｄを例えば図２７に示すようなＦＭＮに採用した構成では、ＦＭＮにおいて必ずしも最適ではない経路が出来てしまうという問題がある。
【００３０】
図２７はスパニングツリーを適用したＩＥＥＥ ８０２．１ＤをＦＭＮに採用した場合のネットワーク構成（図２３と同一）の一例を示している。なお、図２７において、ブリッジａ〜ｄがメッシュ型ネットワーク用ブリッジ３２である。図２７のネットワーク構成では、ブリッジａがルートブリッジとなり、ブリッジｂとブリッジｄとの間のブリッジｄ側のポート、ブリッジｂとブリッジｃとの間のブリッジｃ側のポート、ブリッジｃとブリッジｄとの間のブリッジｄ側のポートがスパニングツリープロトコルにより各々閉鎖ポートに設定される。
【００３１】
従って、図２７のネットワーク構成において、ノードａからノードｂに通信を行う場合、最短経路のブリッジｅ→ブリッジｄ→ブリッジｂを通らず、ブリッジｅ→ブリッジｄ→ブリッジａ→ブリッジｂを通る。このため、ノードａからノードｂへの通信が遠回りすることになり、遅延を生じるという問題があった。
【００３２】
また、上記従来のネットワーク構成では、一部のノードに対して過度な負荷がかかるという問題があった。例えば図２７のネットワーク構成の場合、スパニングツリープロトコルにより閉鎖ポートが設定されているので、ブリッジ間で通信を行う際にルートブリッジであるブリッジａを必ず経由することになり、ブリッジａに過度な負荷がかかる。しかも、一部の回線に対する負荷がかかり、効率的な回線利用が行えず、回線利用率の問題も招いていた。
【００３３】
さらに、上述したメッシュ型ネットワークをインターネット上に構築し、Ｌ２ＴＰ（Ｌａｙｅｒ２ Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ）を利用してイーサネット（Ｒ）フレームをインターネットに流すような場合には、余計な課金が生じるという問題があった。Ｌ２ＴＰは、ＥｔｈｅｒｎｅｔやＰＰＰなどのＬ２フレームをＩＰにカプセル化して、インターネットに送信する手段である。例えば図２７に示すメッシュ型ネットワークをインターネット上に構築した場合、ノードａからノードｂへの通信では、メッシュ型ネットワーク用ブリッジｄ→メッシュ型ネットワーク用ブリッジａの間と、メッシュ型ネットワーク用ブリッジａとメッシュ型ネットワーク用ブリッジｂとの間でインターネット上を通るため、２度の課金が生じて料金が倍になってしまう。
【００３４】
そこで、ＦＭＮにおけるフォワーディングの最適化を図るため、CE-based Virtual Private LAN(http://www.ietf.org/internet-draft/draft-lee-ce-based-vpl-00.txt)において、ＦＭＮブリッジ間の通信にＩＥＥＥ ８０２．１Ｄを改良したオプティマイズド・フォワーディングを利用するものが提案されている。この提案では、スパニングツリーを動作させないことを前提としている。
【００３５】
そして、このオプティマイズド・フォワーディングでは、ブリッジ間で通信を行う場合、ＦＭＮ上の最短経路を通り、かつループフリーになるように、以下のアルゴリズムが適用される。
【００３６】
（１）ＦＭＮ接続ポートから受信したユニキャストパケットをフラッティングするときは全ての非ＦＭＮ接続ポートにフラッティングする。他のＦＭＮ接続ポートにはフラッティングしない。
（２）ＦＭＮ接続ポートから受信したマルチキャストパケットをマルチキャストするときは全ての非ＦＭＮ接続ポートにマルチキャストする。他のＦＭＮ接続ポートにはマルチキャストしない。
（３）非ＦＭＮ接続ポートから受信したユニキャストパケットをフラッティングするときは全てのＦＭＮ接続ポートと非ＦＭＮ接続ポートにフラッティングする。
（４）非ＦＭＮ接続ポートから受信したマルチキャストパケットをマルチキャストするときは全てのＦＭＮ接続ポートと非ＦＭＮ接続ポートにマルチキャストする。回線効率をさらに向上させるため、ＩＧＭＰ Ｓｎｏｏｐｉｇを併用し、不要な配信を回避することを推奨する。
【００３７】
そして、上述したオプティマイズド・フォワーディングを図２３のＦＭＮに採用すれば、例えばブリッジｃと他のブリッジ（ブリッジａ、ブリッジｂ、ブリッジｄ）との間で通信を行う場合、ブリッジｃからのパケットを受けた各ブリッジは、パケットを他のメッシュ型ネットワーク用ブリッジにフラッティングしない。このため、ブリッジ間で通信を行う場合、遠回りによる遅延を生じることなく、最短経路を使用して通信を行うことができ、スパニングツリーを適用したＩＥＥＥ ８０２．１Ｄの問題を解消することができるという利点を有している。
【００３８】
【発明が解決しようとする課題】
しかしながら、オプティマイズド・フォワーディングを利用した場合でも、以下に説明するような問題点が考えられる。
【００３９】
上述したオプティマイズド・フォワーディングでは、スパニングツリーを動作させないことを前提とするので、ブリッジ間で通信を行う場合、回線障害が起きても冗長経路を使用できないという問題があった。例えば図２８のネットワーク構成において、ノードｃからノードｂに通信を行う場合、ブリッジｂとブリッジｃとの間で回線障害が起きると、ノードｃからのパケットはブリッジａおよびブリッジｄに対してフラッティングされるが、ブリッジａおよびブリッジｄが受けたパケットがブリッジｂにはフラッティングされない。このため、冗長経路を使用できず、ノードｃからのパケットをノードｂに送出することができない。
【００４０】
また、図２９に示すように、ブリッジａとブリッジｃとの間に新たにブリッジｆおよびブリッジｇを増設してバックアップ経路を形成すると、ブリッジａ、ブリッジｃ、ブリッジｆ、ブリッジｇによってループが形成される。しかしながら、上述したオプティマイズド・フォワーディングでは、スパニングツリーを動作させないことを前提とするので、万一ネットワーク上の経路にループが発生しても、そのループを検出して閉鎖ポートを設定することができない。このため、あるノードから送出されたパケットがループを形成する経路上に流れ、回線効率を低下させるという問題を招く。
【００４１】
そこで、本発明は、上記問題点に鑑みてなされたものであり、経路の遠回りによる遅延の減少、一部の装置に対する過度な負荷の減少、回線利用率の向上を図るとともに、メッシュ型ドメイン外部でのループを回避できるメッシュ型ネットワーク用ブリッジを提供することを目的としている。
【００４２】
【課題を解決するための手段】
上記目的のメッシュ型ドメイン外部でのループを回避するため、請求項１の発明は、複数のブリッジが相互に回線接続されるメッシュ型ネットワークに回線接続され、最短経路を構築するための手段と複数のメッシュ接続ポートとを有するメッシュ型ネットワーク用ブリッジにおいて、
前記複数のメッシュ接続ポートと該複数のメッシュ接続ポートと関連付けられた少なくとも１つの論理ポートとを記憶する論理ポート記憶部と、
前記複数のメッシュ接続ポートのいずれかのポートからＢＰＤＵを受信したときには該ＢＰＤＵを前記論理ポートから受信したと読み替える読み替え手段と、
前記読み替え手段からのＢＰＤＵを受信するＢＰＤＵ受信手段と、
前記メッシュ接続ポートから受信したＢＰＤＵに基づいて、前記論理ポートのＳＴＰ状態を決定するＳＴＰ情報管理手段と、
該ＳＴＰ情報管理手段から前記ＳＴＰ状態の情報を受けて記憶するＳＴＰ情報記憶部と、
前記ＳＴＰ情報管理手段で決定されたＳＴＰ状態に基づき、ＳＴＰに従ってＢＰＤＵを送信するＢＰＤＵ送信手段であって、前記論理ポートに送信するときは、同一のルートパスコストとポートプライオリティとを持つＢＰＤＵを、当該論理ポートに関連付けられた前記複数のメッシュ接続ポート全てから送信する前記ＢＰＤＵ送信手段と、
同一論理ポートに関連付けられた全てのメッシュ接続ポートを該論理ポートの状態に設定するポート状態設定手段と、
を有するＳＴＰ処理部を備えている。
【００４５】
【発明の実施の形態】
図１は、本発明の第１の実施の形態の概略構成を示すブロック図、図４は本発明によるメッシュ型ネットワーク用ブリッジを採用したメッシュ型ネットワークの一例を示す図、図５は図４のメッシュ型ネットワークにおいてスパニングツリープロトコル（ＳＴＰ）がメッシュ接続ポートを論理的に一つのポートと見なしてＢＰＤＵを送出する概念図、図６（ａ）〜（ｄ）はＢＰＤＵのフレーム・フォーマットを示す図、図７は本発明によるメッシュ型ネットワーク用ブリッジのＢＰＤＵの送信処理のフローチャート、図８は本発明によるメッシュ型ネットワーク用ブリッジのＢＰＤＵの受信処理のフローチャート、図９（ａ），（ｂ）は本発明によるメッシュ型ネットワーク用ブリッジを採用したメッシュ型ネットワークをＳＴＰから見た等価図、図１９は第１の実施の形態の論理ポート記憶部のフォーマットを示す図、図２０はＳＴＰ情報記憶部のフォーマットを示す図、図２１はメッシュ型ネットワーク用ブリッジが論理ポートを複数持つ場合を説明するための図、図２２はメッシュ型ネットワーク用ブリッジ間で回線が複数ある場合を説明するための図である。
【００４６】
スパニングツリープロトコルは、メッシュ型ドメイン内では前述のように適用されない。しかし、メッシュ型ドメイン外部とのループ回避が必要となるため、メッシュ型ドメイン外部を含むネットワーク全体としては、スパニングツリープロトコルのやり取りが必要となる。
【００４７】
本発明は、最短経路構築手段（オプティマイズド・フォワーディングをするための手段）を適用したメッシュ型ドメインとメッシュ型ドメイン外部とのループを回避するため、メッシュ型ドメインとメッシュ型ドメイン外部とを含むネットワーク全体にスパニングツリープロトコルを適用することを実現したものである。
【００４８】
以下に図１に基づいて第１の実施の形態を説明する。
最短経路構築手段１１は、パケット送受信手段１２からパケットを受け取り、パケットを適切なポートに対して出力処理する。このとき、ＩＥＥＥ ８０２．１Ｄ のルールに基づいたフォワーディング＆ラーニングが行われ、フォワーディングテーブルを参照し、宛先ポートが分かっているときは、その宛先ポートに出力し、宛先が不明なときは、フラッティング処理が行われる。ＩＥＥＥ ８０２．１Ｄ によれば、フラッティング処理は全ポートに対して出力が行われることになるが、前述しているオプティマイズド・フォワーディング・アルゴリズムの４つのルール（段落〔００３６〕参照）が適用されることで、最短経路を構築する。
【００４９】
パケット送受信手段１２は、自ポート（メッシュ接続ポート３、非メッシュ接続ポート４）に接続された他のメッシュ型ネットワーク用ブリッジ２、ノード７やメッシュ型ネットワーク用ブリッジ２以外のブリッジ６（例えば図２におけるブリッジ６ｅ）との間でのパケットの送受信を行う手段である。送受信されるパケットの種類としては、例えばＢＰＤＵ、後述する隣接通知パケットやバックアップ依頼・解除パケットを含むメッシュ制御パケット、その他のパケットなどである。
【００５０】
パケット送受信手段１２の内部的な動きとしては、第１の実施の形態では、受信したＢＰＤＵを受信ポート番号と共に読み替え手段１３に渡し、ＢＰＤＵ送信手段１５から渡されたＢＰＤＵを指定されたポートに送出する。
【００５１】
ＳＴＰ処理部５は、自ポート（メッシュ接続ポート３、非メッシュ接続ポート４）から受信したＢＰＤＵに基づいてＳＴＰ情報記憶部を管理し、ＳＴＰの状態を決定し、自ポートにＢＰＤＵを送出するスパニングツリープロトコルを制御する処理部である。同一論理ポートに関連付けられたメッシュ接続ポートは、論理的に１つのポートとして処理する。ＳＴＰ処理部５は、読み替え手段１３〜ＳＴＰ情報記憶部１９の７ブロックを有する。以下に各々のブロックについて説明する。
【００５２】
読み替え手段１３は、パケット送受信手段１２から受け取ったＢＰＤＵをＢＰＤＵ受信手段１４に渡す。このとき、受け取ったＢＰＤＵが論理ポート１０に関連付けられたメッシュ接続ポート３からのとき、関連付けられた論理ポート１０から受け取ったと読み替える。
【００５３】
ＢＰＤＵ受信手段１４は、読み替え手段１３からのＢＰＤＵを受信し、ＳＴＰ情報管理手段１６に受信ポート番号（読み替えられた場合、読み替えられた後の論理ポートの番号）とＢＰＤＵ全体を渡す。
【００５４】
ＢＰＤＵ送信手段１５は、ＳＴＰ情報管理手段１６の要求により、ＢＰＤＵをポートに送出するようにパケット送受信手段１２に依頼する。このとき送出先が論理ポート１０のときは、当該論理ポートに関連付けられている全てのメッシュ接続ポート３，３，３から同一のルートパスコストとポートプライオリティとを持つＢＰＤＵを送出するように依頼する。
【００５５】
ＳＴＰ情報管理手段１６は、ＢＰＤＵ受信手段１４から受け取った情報に基づいて、ＳＴＰ状態を決定し、ＳＴＰ情報記憶部１９に記憶する。以下の場合、スパニングツリープロトコルに従い、送出先ポート番号のポートにＢＰＤＵを送信することをＢＰＤＵ送信手段１５に要求する。
１）ＳＴＰ状態に変化が生じたとき
２）自身がルートブリッジのとき、タイマ駆動による定期的なハローパケットの送信
３）自身がルートブリッジでないときで、ハローパケットを受け取った場合、ルートブリッジ以外へ送信
【００５６】
ポート状態設定手段１７は、ＳＴＰ情報管理手段１６によって決定されたＳＴＰ状態をポート３，３，３，４に設定する。論理ポートに状態を設定するときは、論理ポート記憶部から当該論理ポート１０に関連付けられたメッシュ接続ポート３，３，３の番号（物理番号）を参照し、当該論理ポート１０に関連付けられている全てのメッシュ接続ポートを同一のＳＴＰ状態に合わせる。
【００５７】
論理ポート記憶部１８は、論理ポート１０と論理ポート１０に関連付けられた複数のメッシュ接続ポート３，３，３が図１９に示すようなテーブルとして記憶している。ブリッジ内には、複数の論理ポートがあっても良い。図４に示すようなメッシュ型ネットワークに本発明のメッシュ型ネットワーク用ブリッジを用いるときは、論理ポートは１つで足りるが、図２１に示すように２つのメッシュ型ネットワークを接続する位置に用いられるメッシュ型ネットワーク用ブリッジでは、２つの論理ポートが必要となる。そして、それぞれの論理ポート毎に異なるメッシュ接続ポートが関連付けられる。１つのメッシュ接続ポートに対して関連付けられる論理ポートは１つであって、複数の論理ポートに関連付けられることはない。
【００５８】
複数の論理ポートを持つ場合のオプティマイズド・フォワーディングは、２つの論理ポートを持つ図２１のメッシュ型ネットワーク用ブリッジ２ｃを例に説明すると、次のように行われる。
【００５９】
メッシュ型ネットワーク１ａに接続されているメッシュ接続ポートから受け取ったパケットは、該メッシュ接続ポートが関連付けられている論理ポートから受け取ったと見なされ、該論理ポートに関連付けられている（すなわち、メッシュ型ネットワーク１ａに接続されている）他のメッシュ接続ポートには送らない。そして、もう１つの論理ポートに関連付けられている（すなわち、メッシュ型ネットワーク１ｂに接続されている）全てのメッシュ接続ポートに送る。
【００６０】
論理ポートが複数ある場合の処理は、上記のように行えば良いが、図２１は、ブリッジ２ａとブリッジ２ｃが、メッシュ型ネットワーク１ａ，１ｂで相互接続されている例である。この場合、上記のように単純にオプティマイズド・フォワーディングを行った場合、ブリッジ２ａとブリッジ２ｃとの間でループが発生することになる。しかし、このような場合は、２つの論理ポートでスパニングツリープロトコルが適用され、一方が閉鎖ポートに設定されるため、ループが発生することはない。例えば、ブリッジ２ｃのメッシュ型ネットワーク１ａに接続されているメッシュ接続ポートが閉鎖ポートに設定された場合、ブリッジ２ｃからブリッジ２ｂへのデータは、ブリッジ２ａを経由して送られる。つまり、冗長経路を持ったネットワーク構成と等価になる。
【００６１】
ＳＴＰ情報記憶部１９は、ポート番号毎にポートの状態と最後に受けたＢＰＤＵに関する情報とを図２０に示すようなテーブルとして記憶している。
【００６２】
ここで、本実施の形態では、出力ＢＰＤＵも一つの論理ポートからの出力として処理し、全てのメッシュ接続ポートのポート番号（ＢＰＤＵ内のポートＩＤ）に同一の論理ポート番号を設定しているが、それを受信する接続先メッシュ型ネットワーク用ブリッジはＢＰＤＵ内のポート番号を無視するため、必ずしも同一のポート番号を設定する必要はない。
【００６３】
次に、メッシュ型ドメイン外部でのループ回避を行うために送出されるＢＰＤＵのフォーマット構成について図６（ａ）〜（ｄ）を参照しながら説明する。図６（ａ）はＢＰＤＵ本体のフレーム・フォーマットを示す図、図６（ｂ）はＢＰＤＵのデータに含まれるフラグ（flags）のフレーム・フォーマットを示す図、図６（ｃ）はＢＰＤＵのデータに含まれるルートＩＤ（root ID）、ブリッジＩＤ（bridge ID）のフレーム・フォーマットを示す図、図６（ｄ）はＳＴＰ状態の変化を検出したときに送信されるＴＣＮ−ＢＰＤＵのフレーム・フォーマットを示す図である。
【００６４】
図６（ａ）に示すように、ＢＰＤＵは、ヘッダ部分とデータ部分から構成される。図６（ｂ）に示すように、フラグは、ＴＣＡ、未使用領域、ＴＣから構成される。ＴＣＡのｂｉｔが立ったＢＰＤＵをルートポートから受信したブリッジは、ルートポートへのＴＣＮ−ＢＰＤＵの送信を停止する。ＴＣのｂｉｔが立ったＢＰＤＵをルートポートから受信したブリッジは、ＴＣフラグの立っていないＢＰＤＵを受信するまで、学習テーブルaging タイマーのタイムアウト値をforward delay の値に設定し、自分自身もＴＣフラグの立ったＢＰＤＵを送信する。
【００６５】
図６（ｃ）に示すように、ルートＩＤおよびブリッジＩＤは、上位２octet は管理者が設定するpriority、下位６octet はブリッジのＭＡＣアドレスである。ルートＩＤおよびブリッジＩＤは、上位２octet の管理者が設定するpriorityが優先され、ＭＡＣアドレスを含めた全体の大小によってブリッジの上位下位の判別ができるようになっている。例えば各ブリッジのＢＰＤＵのルートＩＤの上位２octet をデフォルトの状態とした場合、ルートＩＤのＭＡＣアドレスの一番小さいブリッジがルートブリッジとなる。
【００６６】
その他、ルートパス・コスト（root path cost）は、ルートへの最短（と思われる）コストである。ポートＩＤ（port ID）は、上位１octet は管理者が設定するpriority、下位１octet はブリッジに固有のＩＤである。このポートＩＤは、メッシュ接続の場合、受信時には無視されるので、下位１octet は設定の必要はないが、本実装による同一論理ポートに関連付けされた全てのメッシュ接続ポート３のときは、同一のＩＤが用いられる。
【００６７】
message age は、ルートブリッジからの経過時間を示し、単位は１／２５６秒である。したがって、この値が２５６の場合、ルートは１秒前にこのＢＰＤＵに対応するＢＰＤＵを送信したことになる。
【００６８】
max age は、ＢＰＤＵの有効期間を示し、単位は１／２５６秒である。また、hello timeは、ルートブリッジがＢＰＤＵを送信する時間間隔を示し、単位は１／２５６秒である。すなわち、ルートブリッジはhello time間隔でＢＰＤＵを送信する。
【００６９】
forward delay は、listening の期間、learningの期間、スパニングツリーの再構成が発生した場合の学習テーブルaging タイマーに用いられるパラメータを示し、単位は１／２５６秒である。
【００７０】
トポロジーチェンジタイマーは、図６（ｄ）に示すフラグのＴＣを立てる期間を計測するタイマーである。
【００７１】
また、メッシュ型ドメイン内で論理ポートが閉鎖ポートになる場合は、そのメッシュ型ネットワーク用ブリッジ２の同一の論理ポートに関連付けされた全てのメッシュ接続ポート３を閉鎖するようにし、同一の論理ポートに関連付けされたメッシュ接続ポート３を部分的には閉鎖しない。これにより、オプティマイズド・フォワーディングとの矛盾を回避している。
【００７２】
なお、上述したＢＰＤＵのポートＩＤとして与えられる上記論理ポートの論理ポート番号は、物理ポート（実際にメッシュ型ネットワーク用ブリッジ２と接続されるメッシュ接続ポート３）とは異なる番号か、もしくはメッシュ接続ポート番号（物理ポート）の中の代表番号を用いることができる。
【００７３】
次に、ＢＰＤＵ送信処理の動作について図７のフローチャートを参照しながら説明する。なお、図７において、Ｘは全てのポートにＢＰＤＵを出すため、処理ループを実現するための変数であり、Ｘ＝１，２，３，…ＭＡＸＰＯＲＴとインクリメントされながらループを回る。本実施の形態では、処理を簡単にするため、実装されているポート数をｎとするとｎに続くｎ＋１，ｎ＋２，・・・ＭＡＸＰＯＲＴを論理ポート番号としている。ＭＡＸＰＯＲＴは装置に実装しているポートの数＋論理ポートの数である。Ｎは全てのメッシュ接続ポートに同一ＢＰＤＵを出すためにメッシュ接続ポートを探しながらループするための変数である。
【００７４】
このＢＰＤＵ送信処理では、まずＸ＝１とし（ＳＴ１）、Ｘ≦ＭＡＸＰＯＲＴ（最大ポート）か否かを判別する（ＳＴ２）。Ｘ≦ＭＡＸＰＯＲＴでないと判断したときには（ＳＴ２−Ｎｏ）、すなわちポートが最大ポートを超えたと判断したときには処理を終了する。これに対し、Ｘ≦ＭＡＸＰＯＲＴと判断すると（ＳＴ２−Ｙｅｓ）、Ｘが論理ポートか否かを判別する（ＳＴ３）。すなわち、論理ポートのとき関連付けられた全てのメッシュ接続ポート３を一つのポートとするか否かを判別する。
【００７５】
そして、Ｘが論理ポートでないと判断すると（ＳＴ３−Ｎｏ）、Ｘがメッシュ接続ポートか否かを判別する（ＳＴ４）。メッシュ接続ポートでないと判断すると（ＳＴ４−Ｎｏ）、ポートＸ用（非メッシュ接続ポート番号）のＢＰＤＵをポートに送信し（ＳＴ５）、Ｘ＝Ｘ＋１にする（ＳＴ６）。その後、ＳＴ２の処理に戻る。メッシュ接続ポートと判断すると（ＳＴ４−Ｙｅｓ）、論理ポートに対する送信処理のところで送信されるので、ここでは送信せずＳＴ６の処理に移行する。Ｘが論理ポートと判断されると（ＳＴ３−Ｙｅｓ）、Ｎ＝１とし（ＳＴ７）、Ｎ≦ＭＡＸＰＯＲＴ（最大ポート数）か否かを判別する（ＳＴ８）。
【００７６】
そして、Ｎ≦ＭＡＸＰＯＲＴでないと判断すると（ＳＴ８−Ｎｏ）、ＳＴ６の処理に移行する。これに対し、Ｎ≦ＭＡＸＰＯＲＴと判断すると（ＳＴ８−Ｙｅｓ）、ポート番号Ｎが論理ポートＸに関連付けられたメッシュ接続ポートか否かを判別する（ＳＴ９）。ポート番号Ｎが論理ポートＸに関連付けられたメッシュ接続ポートと判断すると（ＳＴ９−Ｙｓｅ）、ポート番号ＮにポートＸ用（論理ポート番号）のＢＰＤＵを送信する（ＳＴ１０）。そして、Ｎ＝Ｎ＋１とし（ＳＴ１１）、ＳＴ８の処理に戻る。これに対し、ポート番号Ｎが論理ポートＸに関連付けられたメッシュ接続ポートでないと判断すると（ＳＴ９−Ｎｏ）、ＳＴ１１の処理に移行する。
【００７７】
次に、ＢＰＤＵ受信処理の動作について図８のフローチャートを参照しながら説明する。このＢＰＤＵ受信処理では、パケットを受信すると（ＳＴ２１）、ＢＰＤＵか否か判断する（ＳＴ２２）。ＢＰＤＵでないと判断すると（ＳＴ２２−Ｎｏ）、そのままパケットをフォワードする（ＳＴ２３）。ＢＰＤＵと判断すると（ＳＴ２２−Ｙｅｓ）、受信ポートがメッシュ接続ポート３か否か判別する（ＳＴ２４）。受信ポートがメッシュ接続ポート３と判断すると（ＳＴ２４−Ｙｅｓ）、受信ポート番号に関連付けられた論理ポート番号を用いる（ＳＴ２５）。これに対し、受信ポートがメッシュ接続ポート３でないと判断すると（ＳＴ２４−Ｎｏ）、受信ポート番号に実際の物理ポート番号を用いる（ＳＴ２６）。そして、上記のように受信ポートに用いる番号が決定すると、ＢＰＤＵ受信処理を行い（ＳＴ２７）、ＳＴＰ情報の管理を行い（ＳＴ２８）、ポートの状態を設定する（ＳＴ２９）、ＩＥＥＥ ８０２．１Ｄに準拠したスパニングツリープロトコルによるＢＰＤＵの受信処理が行われる。上記ＳＴ２９のポートの状態設定は、論理ポートに対する設定の場合、該論理ポートに関連付けされた全てのメッシュ接続ポートに設定することになる。
【００７８】
ここで、図９（ａ）に示すように、例えばブリッジ２ａとブリッジ２ｃとの間にバックアップ経路（外部ネットワーク）としてブリッジ６ｆおよびブリッジ６ｇ（いずれもメッシュ型ネットワーク用ブリッジ２ではない）を接続すると、ブリッジ２ａ、ブリッジ２ｃ、ブリッジ６ｆ、ブリッジ６ｇによってループが形成される。
【００７９】
しかし、本実施の形態のメッシュ型ネットワーク用ブリッジ２では、メッシュ接続ポート３から受信したＢＰＤＵは、関連付けられた論理ポートから受信したものと見なし、受信したＢＰＤＵに基づいてＳＴＰ状態を決定している。
【００８０】
これにより、スパニングツリープロトコルは、図９（ｂ）に示すように、一本のバス型ＬＡＮに対して複数台（図９（ｂ）の例ではブリッジ２ａ〜２ｄの４台）のメッシュ型ネットワーク用ブリッジが接続されているものとして認識する。そして、受信したＢＰＤＵに基づいて閉鎖ポートを設定する。図９（ｂ）の例では、ブリッジ６ｆとブリッジ６ｇとの間でブリッジ６ｇ側のポートを閉鎖ポートに設定する。
【００８１】
このように、本実施の形態のメッシュ型ネットワーク用ブリッジ２によれば、全てのメッシュ接続ポート３を論理的に一つのポートと見なし、全てのメッシュ接続ポート３に同一のＢＰＤＵを送出している。また、メッシュ接続ポート３から受信したＢＰＤＵは、全て関連付けられた一つの論理ポートから受信したものと見なし、受信したＢＰＤＵに基づいてＳＴＰ情報記憶部を構築している。
【００８２】
これにより、スパニングツリープロトコルは、一本のバス型ＬＡＮに対して複数台のメッシュ型ネットワーク用ブリッジ２が接続されているものとして認識し、受信したＢＰＤＵに基づいて閉鎖ポートを設定するので、メッシュ型ドメインとメッシュ型ドメイン外部とのループを回避することができる。しかも、メッシュ型ドメイン内において、メッシュ型ネットワーク用ブリッジ間に回線障害が無ければ、メッシュ型ネットワーク用ブリッジ間の最短経路で通信を行うことができる。これにより、経路の遠回りにより遅延の減少、一部の装置に対する過度な負荷の減少、回線利用率の向上を図ることができる。
【００８３】
ところで、上述した実施の形態では、メッシュ型ネットワーク１を構成する各メッシュ型ネットワーク用ブリッジ２，２間を接続する回線が一つの場合について図示して説明したが、各メッシュ型ネットワーク用ブリッジ２，２間を２つ以上の回線で接続する構成にしても良い。但し、対向接続されるメッシュ型ネットワーク用ブリッジ２，２間の回線を２本以上同一の論理ポートに関連付けるときは、Ｌｉｎｋ Ａｇｇｒｅｇａｔｉｏｎ（ＩＥＥＥ ８０２．３ａｄ）により束ねられている必要がある。Ｌｉｎｋ Ａｇｇｒｅｇａｔｉｏｎ により束ねられていると、対向接続されるメッシュ型ネットワーク用ブリッジ間の複数の回線が１つのポートと見なされる。そして本発明を適用すると、その１つのポートは、１つの論理ポートに関連付けられる。（図２２参照）
【００８４】
さて、前述したオプティマイズド・フォワーディングは、メッシュ型ドメイン内で送信すべき回線が利用可能であることが前提になっており、回線障害が発生すると通信が遮断され、その回線に接続されているブリッジへは到達不能となる。
【００８５】
そこで、本発明は、メッシュ型ネットワーク用ブリッジ２を採用したメッシュ型ネットワーク１で、回線障害を検出したメッシュ型ネットワーク用ブリッジ２は、継続してメッシュ型ドメイン内に残り、到達不能となったメッシュ型ネットワーク用ブリッジ２と接続している他のメッシュ型ネットワーク用ブリッジ２を経由して、到達不能になったブリッジにパケットを到達させる。
【００８６】
図２は、本発明の第２の実施の形態の概略構成を示すブロック図、図１０および図１１は本発明によるメッシュ型ネットワーク用ブリッジを採用したメッシュ型ネットワークにおいてバックアップ依頼による経路の形成を行った場合の説明図、図１２は本発明によるメッシュ型ネットワーク用ブリッジが持つバックアップ候補記憶部の一例を示す図、図１３は本発明によるメッシュ型ネットワーク用ブリッジが持つバックアップ受付テーブルの一例を示す図、図１４はメッシュ制御パケットのフォーマットを示す図、図１５は図１４のフォーマットにおいて隣接通知を行う場合のオプションのフォーマットを示す図、図１６は図１４のフォーマットにおいてバックアップ依頼・解除を行う場合のオプションのフォーマットを示す図、図１７は本発明によるメッシュ型ネットワーク用ブリッジの回線障害検出時のバックアップ依頼処理のフローチャート、図１８は本発明によるメッシュ型ネットワーク用ブリッジのバックアップ受付処理のフローチャートである。
【００８７】
以下に図２に基づいて第２の実施の形態を説明する。なお、第１の実施の形態と同じ部分については、その説明を省略するが、第２の実施形態では、パケット送受信手段１２の内部的な動きは、次のようになる。受信したバックアップ依頼パケットをバックアップ依頼受付手段２４に渡し、バックアップ依頼送出手段２３から渡されたバックアップ依頼パケットを指定されたポートに送出する。
【００８８】
回線障害検出手段２１は、自ポート（メッシュ接続ポート３、非メッシュ接続ポート４）とそのポートに接続されているポートとの間の回線障害を検出する手段であり、例えばポートを介してリンクダウンなどのイベントを検出すると、そのイベントをバックアップブリッジ選択手段２２に通知する。
【００８９】
なお、回線障害検出の方法としては、後述するメッシュ制御パケットの一種として用意される隣接ブリッジ通知用パケットをメッシュ型ネットワーク用ブリッジ２，２間で交換して相手ブリッジに一定時間内に届くか否かにより回線障害を検出するキープアライブによる検出、通常導通しているメッシュ型ネットワーク用ブリッジ２，２同志のポート間の接続が外れたときに発生する割込信号によって回線障害を検出するリンクダウンによる方法、定期的にやり取りするパケットが所定時間経過しても来ないことにより回線障害を検出する方法など様々なものが考えられる。
【００９０】
バックアップブリッジ選択手段２２は、回線障害検出手段２１から回線障害が発生したポート番号が通知されると、そのポートがメッシュ接続ポート３のとき、バックアップ候補記憶部２７から、通知されたポート番号に接続されている隣接ブリッジ（到達不能ブリッジ）を見つけ、その到達不能ブリッジをバックアップ候補に持つ隣接ブリッジを依頼先ブリッジとして選択し、バックアップ依頼送出手段２３に通知する。このとき、障害が通知された接続ポートに障害が発生したことを示すため、バックアップ候補記憶部２７の当該接続ポートの残り時間を“０”に書き換える。
【００９１】
バックアップ依頼送出手段２３は、バックアップブリッジ選択手段２２から到達不能ブリッジと依頼先ブリッジが通知されると、▲１▼依頼先ブリッジに対する、バックアップターゲットを到達不能ブリッジとし、バックアップソースを自分としたバックアップ依頼パケットの送信をパケット送受信手段１２に依頼し、▲２▼宛先が到達不能ブリッジであるパケットを受け取ったときには、（到達不能ブリッジへではなく）依頼先ブリッジに送出するような経路を形成するように経路制御手段２５に依頼する。
【００９２】
バックアップ依頼受付手段２４は、パケット送受信手段１２を経由して他のブリッジからのバックアップ依頼パケットを受け取ると、▲１▼該パケットを受信した接続ポートと該パケットで示されたバックアップターゲット（到達不能ブリッジ）とバックアップソース（依頼元ブリッジ）と監視用の残り時間とを合わせてバックアップ受付テーブル２８に登録し、▲２▼バックアップソースから宛先がバックアップターゲットであるパケットを受け取ったときにはバックアップターゲットに送出するような経路を形成するように経路制御手段２５に依頼する。受信したバックアップ依頼パケットが示すバックアップソースとバックアップターゲットの組み合せが既にバックアップ受付テーブル２８にある場合は、残り時間を初期値にする。残り時間を定期的に監視し残り時間がなくなったとき、または、パケット送受信手段１２からバックアップ解除依頼を受け取ったときは、バックアップ受付テーブル２８からそのバックアップ経路の項目（バックアップソース、バックアップターゲット、残り時間）を削除するとともに経路制御手段２５にバックアップ経路の停止を依頼する。
【００９３】
経路制御手段２５は、バックアップ依頼送出手段２３またはバックアップ依頼受付手段２４から、バックアップ経路の形成を依頼されたとき、依頼されたバックアップ経路を形成するように最短経路構築手段１１にオプティマイズド・フォワーディングの例外処理を依頼する。また、バックアップ経路の解除を要求されたときは、最短経路構築手段１１に、指定のバックアップ経路の例外処理を止めることを依頼する。
【００９４】
バックアップ候補記憶部制御手段２６は、メッシュ接続ポート３，３，３に回線接続されているブリッジが、自身の存在と、自身とメッシュ接続している他のブリッジ（隣接ブリッジ）の情報とを含む隣接通知パケットを定期的に送出し、隣接通知パケットを受け取ったとき、受信ポート番号、ソースアドレス、隣接ブリッジの情報を取り出し、受信ポートをバックアップ候補テーブルの接続ポートとして、ソースアドレスを該テーブルの隣接ブリッジとして、隣接ブリッジを該テーブルのバックアップ候補として、回線障害を検出するための残り時間とともにバックアップ候補記憶部２７に記憶する。また、バックアップ候補記憶部２７に記憶された残り時間を定期的に監視し、一定期間隣接通知パケットが通知されていないことを検出したとき、回線障害が発生したことを回線障害検出手段２１に通知する。
【００９５】
バックアップ候補記憶部２７は、前述のバックアップ候補テーブルを記憶している。該バックアップ候補テーブルは、図１２に示すように、接続ポート・隣接ブリッジ・バックアップ候補、および残り時間を書き込むようになっている。その書き込みについては、バックアップブリッジ選択手段２２とバックアップ候補記憶部制御手段２６の説明で述べたので省略する。
【００９６】
次に、本例のメッシュ型ネットワーク用ブリッジ２を採用したメッシュ型ネットワーク１内での回線障害を検出したときのバックアップ経路形成の動作について説明する。
【００９７】
本例のメッシュ型ネットワーク用ブリッジ２は、他のメッシュ型ネットワーク用ブリッジ２との間での回線障害を検出したときに、到達不能になったメッシュ型ネットワーク用ブリッジ２との間の迂回路（バックアップ経路）を別の到達可能なメッシュ型ネットワーク用ブリッジ２との間に形成するシグナリングプロトコルを有している。
【００９８】
このシグナリングプロトコルによるバックアップ要求時には、以下の処理が実行される。まず、後述する図１４に示すメッシュ制御パケットの一種として用意される隣接通知パケットをメッシュ型ネットワーク用ブリッジ２，２相互間で交換する（図１０参照）。この隣接通知パケットによる通知は、一定時間（例えば２秒）間隔で全てのメッシュ型ネットワーク用ブリッジ２に通知される。隣接通知パケットを受信したメッシュ型ネットワーク用ブリッジ２は、その隣接通知パケットを送ってきたメッシュ型ネットワーク用ブリッジ２の存在とそのメッシュ型ネットワーク用ブリッジ２との回線が利用可能であることを認識する。これに対し、隣接通知パケットによる通知が一定時間（例えば８秒）届かなければ、そのメッシュ型ネットワーク用ブリッジ２との間に回線障害が起きたことを検出する。
【００９９】
上記隣接通知パケットには、自分と隣接関係にある他のメッシュ型ネットワーク用ブリッジ２のブリッジＩＤ（ＭＡＣアドレス）が格納される。これにより、隣接通知パケットを受信したメッシュ型ネットワーク用ブリッジ２は、隣接通知パケットを送信したメッシュ型ネットワーク用ブリッジ２が到達不能ブリッジとなったときのバックアップ依頼先の情報が含まれるバックアップ候補テーブルを管理することが可能となる。
【０１００】
回線障害を検出したメッシュ型ネットワーク用ブリッジ２は、バックアップ候補テーブルから到達不能ブリッジへのバックアップが可能なメッシュ型ネットワーク用ブリッジ２を見つけ出し、バックアップ依頼を行う。例えば図１１に示すように、ブリッジ２ｃとブリッジ２ｄとの間で回線障害が発生した場合には、ブリッジ２ｃからブリッジ２ａに対してバックアップ依頼を行う。このバックアップ依頼は、到達不能ブリッジと自分のブリッジのＭＡＣアドレスをそれぞれ「バックアップターゲット」、「バックアップソース」として指定したバックアップ依頼パケットをブリッジ２ａに送出することで行なう。
【０１０１】
そして、バックアップ依頼を受けたメッシュ型ネットワーク用ブリッジ２ａは、「バックアップターゲット」と接続しているポートと「バックアップソース」と接続しているポートとの間でフラッティングとマルチキャストの配信を行い、バックアップ経路を形成する。
【０１０２】
この例では、バックアップしなければならない回線を指定するために、到達不能ブリッジを識別できる識別情報として、到達不能ブリッジのＭＡＣアドレスを用いているが、バックアップ対象回線を指定するために、回線番号を設定しておき、その回線番号を指定して、バックアップ依頼する方法もある。
【０１０３】
ここで、上述したバックアップ経路の形成時に用いられるバックアップ候補テーブルについて図１２を参照しながら説明する。このバックアップ候補テーブルは、メッシュ接続ポート３の数分だけ用意する。図１２はメッシュ接続ポート３が４つの場合の例を示している。隣接通知パケットをメッシュ接続ポート３から受信したときに、そのメッシュ接続ポートに接続されたメッシュ型ネットワーク用ブリッジ２を隣接ブリッジとして登録し、隣接通知パケット内の隣接ブリッジは、バックアップ候補として登録する。そして、残り時間を１０（例えば１０秒に相当）に初期化する。なお、残り時間は、毎秒減算され、再び隣接通知パケットをメッシュ接続ポート３から受信すると１０に再初期化される。
【０１０４】
この残り時間が“０”になったとき、つまり隣接通知パケットが１０秒間来ない場合、その接続ポートで回線障害が発生したこととする。
【０１０５】
次に、図１３に示すバックアップ受付テーブル２８について説明する。メッシュ型ネットワーク用ブリッジ２がバックアップ依頼を受け付けると、受信した接続ポート、バックアップターゲット、バックアップソースの情報と合わせて残り時間を記録する。
【０１０６】
また、バックアップソースのつながっているポートとバックアップターゲットのつながっているポートの間でのパケットのフラッディングとマルチキャストの経路の形成を経路制御手段２５に依頼する。
【０１０７】
上記バックアップ依頼は、所定時間（例えば２秒）毎に送られて来るので、その都度、残り時間を１０に初期化する。そして、バックアップ解除パケットを受けるか、残り時間が０になると、そのエントリを削除し、経路制御手段２５にバックアップソースのつながっているポートとバックアップターゲットのつながっているポートの間でのパケットのフラッディングとマルチキャストフォワーディングの停止を指示する。
【０１０８】
次に、上述した隣接通知パケットおよびバックアップ依頼パケットを含むメッシュ制御パケットについて図１４を参照しながら説明する。
【０１０９】
このメッシュ制御パケットは、図１４に示すように、あて先ソース、ソースアドレス、パケット長、ＬＬＣ ＤＳＡＰ、ＬＬＣ ＳＳＡＰ、ＬＬＣ制御、プロトコルＩＤ、プロトコルバージョン、コマンド、オプション、パディング、ＦＣＳによって構成される。以下に、一般的な用語の説明は省略し、本発明に関連して新しく作成した「コマンド」と「オプション」について説明する。
【０１１０】
本例では、上記メッシュ制御パケットのコマンドは、以下のコマンドコードを割り当てている。０ｘ００…隣接通知、０ｘ０１…バックアップ依頼、０ｘ０２…バックアップ解除。
【０１１１】
また、オプションは、コマンド毎に異なり、以下のように定義している。隣接通知では、隣接ブリッジリストをオプションに格納する。オプションフィールドのフォーマットは、例えば図１５に示すように構成される。例えば隣接ブリッジ数を０〜１５（最大）とし、隣接通知は２秒毎に行う。これにより、メッシュ型ネットワーク用ブリッジ２は、自分のバックアップ候補テーブルを参照し、隣接ブリッジの一覧を全メッシュ接続ポート３に送出する。
【０１１２】
バックアップ依頼・解除では、図１６に示すように、バックアップターゲットとバックアップソースをオプションに格納する。バックアップ依頼は、バックアップ候補から選択したブリッジに出力する。バックアップを依頼したメッシュ型ネットワーク用ブリッジ２から隣接通知パケットを受けると、バックアップターゲットが隣接に含まれているかチェックし、隣接していなかった場合は、バックアップ解除を送り、別の候補ブリッジを選択してバックアップ依頼を送り直す。また、バックアップ依頼にはレスポンスがないので、隣接通知パケットを受けるたびに毎回バックアップ依頼を送る。そして、バックアップ依頼を受けたメッシュ型ネットワーク用ブリッジ２は、バックアップ受付テーブル２８に記録し、バックアップターゲットと、バックアップソースの間のフォワーディングを開始する。バックアップ依頼が１０秒間来ない場合は、バックアップ処理を停止し、バックアップ受付テーブル２８から削除する。
【０１１３】
このように、上述したバックアップ依頼プロトコルによりバックアップ経路を形成することができる。
【０１１４】
回線障害検出時のバックアップ依頼の処理について図１７のフローチャートを参照しながら説明する。このバックアップ依頼の処理では、回線障害を検出すると（ＳＴ３１）、障害を検出したポートがメッシュ接続ポート３か否か判断する（ＳＴ３２）。メッシュ接続ポート３でないと判断すると（ＳＴ３２−Ｎｏ）、処理を終了する。メッシュ接続ポート３と判断すると（ＳＴ３２−Ｙｅｓ）、バックアップ候補テーブルを検索し、障害を検出したポートから隣接ブリッジ（到達不能ブリッジ）のアドレスを求め、アドレスをＸとする（ＳＴ３３）。このとき、回線障害を検出したポートであることを示すため残り時間を“０”にする。
【０１１５】
次に、バックアップ候補を選択する。ここでＮは、バックアップ候補テーブルに登録されている全てのメッシュ接続ポートを検索するため、Ｎ＝１，２，３，・・・ＭＡＸＰＯＲＴとインクリメントする変数である。Ｎを１にする（ＳＴ３４）。Ｎがメッシュ接続ポート数内かどうかを判断し（ＳＴ３５）、Ｎがメッシュ接続ポート数を超えたとき（ＳＴ３５−Ｎｏ）、処理を終了する。Ｎがメッシュ接続ポート内のとき（ＳＴ３５−Ｙｅｓ）、ポート番号Ｎに隣接ブリッジがあるか否か判断する（ＳＴ３６）。隣接ブリッジがないときは（ＳＴ３６−Ｎｏ）、Ｎを＋１し（ＳＴ４２）ＳＴ３５へ進む。隣接ブリッジがあるときは（ＳＴ３６−Ｙｅｓ）、その隣接ブリッジが回線接続されているか判断する（ＳＴ３７）。（回線障害が発生していないか調べるため、残り時間が“０”でないことを確認する。）回線接続されていないときは（ＳＴ３７−Ｎｏ）、Ｎを＋１し（ＳＴ４２）ＳＴ３５へ進む。回線接続されているときは（ＳＴ３７−Ｙｅｓ）、隣接ブリッジのアドレスをバックアップ候補アドレスＹとする（ＳＴ３８）。ポート番号Ｎのバックアップ候補の中に到達不能ブリッジＸがあるか検索する（ＳＴ３９）。バックアップ候補の中にＸがないときは（ＳＴ３９−Ｎｏ）、Ｎを＋１し（ＳＴ４２）ＳＴ３５へ進む。バックアップ候補の中にＸがあるときは（ＳＴ３９−Ｙｅｓ）、ＹとＸとの回線が接続されているので、ブリッジＹにブリッジＸのバックアップを依頼し（ＳＴ４０）、ブリッジＸへ送るパケットはブリッジＹに送る経路を形成し（ＳＴ４１）終了する。
【０１１６】
すなわち、このバックアップ依頼の処理では、回線障害を検出すると、まずバックアップ候補テーブルを見て、そのポートがメッシュ接続ポート３かどうかを確認する。そして、そのポートがメッシュ接続ポート３であれば、そのポートの隣接ブリッジのアドレス（Ｘ）を取り出し、今度はそのアドレス（Ｘ）と接続されている、つまり、Ｘをバックアップ候補に持つ回線接続された隣接ブリッジがあるかどうかを再びバックアップ候補テーブルから検索する。自分と回線接続されていて、かつ、到達不能ブリッジＸとも回線接続されている隣接ブリッジが見つかれば、その隣接ブリッジを依頼先ブリッジ（Ｙ）とする。そして、依頼先ブリッジが見つかると、自分のＭＡＣアドレスをバックアップソースとして、到達不能ブリッジのアドレス（Ｘ）をバックアップターゲットとして依頼先ブリッジ（Ｙ）に送信する。
【０１１７】
次に、バックアップ依頼を受け付ける処理ついて図１８のフローチャートを参照しながら説明する。このバックアップ依頼受付の処理では、バックアップ依頼パケットを受け取り（ＳＴ５１）、受信したポートをＳとし（ＳＴ５２）、バックアップ依頼パケットのターゲットブリッジをＸとする（ＳＴ５３）。
【０１１８】
次に、ターゲットブリッジの接続ポートを選択するため、ポート検索用変数Ｎを１にする（ＳＴ５４）。Ｎがメッシュ接続ポート数内かどうかを判断し（ＳＴ５５）、Ｎがメッシュ接続ポート数を超えたとき（ＳＴ５５−Ｎｏ）、処理を終了する。Ｎがメッシュ接続ポート内のとき（ＳＴ５５−Ｙｅｓ）、ポート番号Ｎの隣接ブリッジがＸか否か判断する（ＳＴ５６）。隣接ブリッジがＸでないときは（ＳＴ５６−Ｎｏ）、Ｎを＋１し（ＳＴ６０）、ＳＴ５５へ進む。隣接ブリッジがＸのときは（ＳＴ５６−Ｙｅｓ）、回線障害を検出しているかどうか判断する（ＳＴ５７）。残り時間を参照し、回線障害を検出しているとき（ＳＴ５７−Ｙｅｓ）、処理を終了する。回線障害を検出していないとき（ＳＴ５７−Ｎｏ）、ターゲットブリッジに接続されているポートをＴとする（ＳＴ５８）。ポートＳからきたブリッジＸへ送るパケットはポートＴに送る経路を形成し（ＳＴ５９）終了する。
【０１１９】
このように、本実施の形態によれば、回線障害を検出したメッシュ型ネットワーク用ブリッジ２は、到達不能ブリッジに隣接するメッシュ型ネットワーク用ブリッジ２を見つけ出し、この見つけ出したメッシュ型ネットワーク用ブリッジ２に対し、到達不能ブリッジのＭＡＣアドレスをバックアップターゲットとし、かつ自分のＭＡＣアドレスをバックアップソースとするバックアップ依頼パケットを送出している。そして、バックアップ依頼パケットを受けたメッシュ型ネットワーク用ブリッジ２は、バックアップ依頼パケットに含まれるバックアップターゲットと接続しているポートとバックアップソースと接続しているポートとの間でフラッティングとマルチキャストの配信を行ってバックアップ経路を形成している。これにより、回線障害時の経路のバックアップを行うことができる。
【０１２０】
以上、第１の実施の形態のブリッジは、メッシュ型ネットワークにオプティマイズド・フォワーディングを適用しながら、そのメッシュ型ネットワークに接続される外部のネットワーク全体にＳＴＰを適用できるようなメッシュ型ネットワーク用ブリッジであり、第２の実施の形態のブリッジは、メッシュ型ネットワークに全体としては、オプティマイズド・フォワーディングを適用しながら、回線障害が発生した場合でも通信が可能なメッシュ型ネットワーク用ブリッジである。図４は、第１の実施の形態と第２の実施の形態とを合わせたメッシュ型ネットワーク用ブリッジを示した。このようにすれば、前述の第１の実施の形態と第２の実施の形態の特長を合わせ持ったメッシュ型ネットワーク用ブリッジとすることができる。
【０１２１】
【発明の効果】
以上の説明で明らかなように、本発明によれば、メッシュ型ネットワーク用ブリッジ間の最短経路で通信を行うことで、経路の遠回りによる遅延の減少、一部の装置に対する過度な負荷の減少、回線利用率の向上を図るとともに、複数のメッシュ接続ポートを１つの論理ポートに関連付けることで、メッシュ型ドメインとメッシュ型ドメイン外部とでスパニングツリーを構築し、メッシュ型ドメイン外部でのループを回避することができる。
【図面の簡単な説明】
【図１】本発明によるメッシュ型ネットワーク用ブリッジの第１の実施の形態の概略構成を示すブロック図
【図２】本発明によるメッシュ型ネットワーク用ブリッジの第２の実施の形態の概略構成を示すブロック図
【図３】本発明によるメッシュ型ネットワーク用ブリッジの第１の実施の形態と第２の実施の形態とを合わせた形態の概略構成を示すブロック図
【図４】本発明によるメッシュ型ネットワーク用ブリッジを採用したメッシュ型ネットワークの一例を示す図
【図５】図４のメッシュ型ネットワークにおいてＳＴＰがメッシュ接続ポートを論理的に一つのポートと見なしてＢＰＤＵを送出する概念図
【図６】ＢＰＤＵのフレーム・フォーマットを示す図であり
（ａ）は、ＢＰＤＵ本体のフォーマット示す図
（ｂ）は、ＢＰＤＵに含まれる flags のフォーマットを示す図
（ｃ）は、ＢＰＤＵに含まれる root ID, bridge IDのフォーマットを示す図
（ｄ）は、ＴＣＮ−ＢＰＤＵのフォーマットを示す図
【図７】本発明によるメッシュ型ネットワーク用ブリッジを採用したメッシュ型ネットワークにおけるＢＰＤＵの送信処理のフローチャート
【図８】本発明によるメッシュ型ネットワーク用ブリッジを採用したメッシュ型ネットワークにおけるＢＰＤＵの受信処理のフローチャート
【図９】本発明によるメッシュ型ネットワーク用ブリッジを採用したメッシュ型ネットワークにおいてＳＴＰを動作させたときのネットワークの状態を説明するための図であり、
（ａ）は、メッシュ型ネットワークの一例を示す図
（ｂ）は、（ａ）の示したネットワークにおいてＳＴＰを動作させたときのネットワークの状態の等価図
【図１０】本発明によるメッシュ型ネットワーク用ブリッジを採用したメッシュ型ネットワークにおける隣接通知パケットとバックアップ候補テーブルとの関係の説明図
【図１１】本発明によるメッシュ型ネットワーク用ブリッジを採用したメッシュ型ネットワークにおいてバックアップ依頼による経路の復旧を行う場合の説明図
【図１２】本発明によるメッシュ型ネットワーク用ブリッジが持つバックアップ候補テーブルの一例を示す図
【図１３】本発明によるメッシュ型ネットワーク用ブリッジが持つバックアップ受付テーブルの一例を示す図
【図１４】メッシュ制御パケットのフォーマットを示す図
【図１５】図１４のフォーマットにおいて隣接通知を行う場合のオプションのフォーマットを示す図
【図１６】図１４のフォーマットにおいてバックアップ依頼・解除を行う場合のオプションのフォーマットを示す図
【図１７】本発明によるメッシュ型ネットワーク用ブリッジを採用したメッシュ型ネットワークにおける回線障害検出時のバックアップ依頼処理のフローチャート
【図１８】本発明によるメッシュ型ネットワーク用ブリッジを採用したメッシュ型ネットワークにおけるバックアップ受付処理のフローチャート
【図１９】本発明によるメッシュ型ネットワーク用ブリッジにおける論理ポートテーブルの一例を示す図
【図２０】本発明によるメッシュ型ネットワーク用ブリッジにおけるＳＴＰ情報テーブルの一例を示す図
【図２１】本発明によるメッシュ型ネットワーク用ブリッジを採用した２つのメッシュ型ネットワークを含むネットワークの一例を示す図
【図２２】本発明によるメッシュ型ネットワーク用ブリッジを採用したメッシュ型ネットワークにおいてブリッジ間で回線が複数ある場合を示す図
【図２３】ＦＭＮの一例を示す図
【図２４】ＦＭＮに使用されているメッシュ型ネットワーク用ブリッジの概念図
【図２５】スパニングツリーの目的を説明するための図
【図２６】スパニングツリーの目的を説明するための図
【図２７】スパニングツリーを適用したメッシュ型ネットワークの一例を示す図
【図２８】メッシュ型ネットワークにオプティマイズド・フォワーディングを採用した場合の問題点を説明するための図
【図２９】メッシュ型ネットワークにオプティマイズド・フォワーディングを採用した場合の問題点を説明するための図
【符号の説明】
１…メッシュ型ネットワーク、２…メッシュ型ネットワーク用ブリッジ、３…メッシュ接続ポート、４…非メッシュ接続ポート、５…ＳＴＰ処理部、６…非メッシュ型ネットワーク用ブリッジ、７…ノード、１０…論理ポート、１１…最短経路構築手段、１２…パケット送受信手段、１３…読み替え手段、１４…ＢＰＤＵ受信手段、１５…ＢＰＤＵ送信手段、１６…ＳＴＰ情報管理手段、１７…ポート状態設定手段、１８…論理ポート記憶部、１９…ＳＴＰ情報記憶部、２０…フォワーディングテーブル、２１…回線障害検出手段、２２…バックアップブリッジ選択手段、２３…バックアップ依頼送出手段、２４…バックアップ依頼受付手段、２５…経路制御手段、２６…バックアップ候補記憶部制御手段、２７…バックアップ候補記憶部、２８…バックアップ受付テーブル、３１…メッシュ型ネットワーク、３２…メッシュ型ネットワーク用ブリッジ、３３…メッシュ接続ポート、３４…非メッシュ接続ポート、３６…非メッシュ型ネットワーク用ブリッジ、３７…ノード。
Claims (1)
- 複数のブリッジが相互に回線接続されるメッシュ型ネットワーク（１）に回線接続され、最短経路を構築するための手段（１１）と複数のメッシュ接続ポート（３）とを有するメッシュ型ネットワーク用ブリッジ（２）において、
前記複数のメッシュ接続ポートと該複数のメッシュ接続ポートと関連付けられた少なくとも１つの論理ポートとを記憶する論理ポート記憶部（１８）と、
前記複数のメッシュ接続ポートのいずれかのポートからＢＰＤＵを受信したときには該ＢＰＤＵを前記論理ポートから受信したと読み替える読み替え手段（１３）と、
前記読み替え手段からのＢＰＤＵを受信するＢＰＤＵ受信手段（１４）と、
前記メッシュ接続ポートから受信したＢＰＤＵに基づいて、前記論理ポートのＳＴＰ状態を決定するＳＴＰ情報管理手段（１６）と、
該ＳＴＰ情報管理手段から前記ＳＴＰ状態の情報を受けて記憶するＳＴＰ情報記憶部（１９）と、
前記ＳＴＰ情報管理手段で決定されたＳＴＰ状態に基づき、ＳＴＰに従ってＢＰＤＵを送信するＢＰＤＵ送信手段であって、前記論理ポートに送信するときは、同一のルートパスコストとポートプライオリティとを持つＢＰＤＵを、当該論理ポートに関連付けられた前記複数のメッシュ接続ポート全てから送信する前記ＢＰＤＵ送信手段（１５）と、
同一論理ポートに関連付けられた全てのメッシュ接続ポートを該論理ポートの状態に設定するポート状態設定手段（１７）と、
を有するＳＴＰ処理部（５）を備えたことを特徴とするメッシュ型ネットワーク用ブリッジ。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002369070A JP3799010B2 (ja) | 2002-12-19 | 2002-12-19 | メッシュ型ネットワーク用ブリッジ |
| US10/732,507 US7366191B2 (en) | 2002-12-19 | 2003-12-09 | Mesh network bridges making operable spanning tree protocol and line fault backup protocol in optimized forwarding environment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002369070A JP3799010B2 (ja) | 2002-12-19 | 2002-12-19 | メッシュ型ネットワーク用ブリッジ |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2006020661A Division JP4137947B2 (ja) | 2006-01-30 | 2006-01-30 | メッシュ型ネットワーク用ブリッジ |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004201140A JP2004201140A (ja) | 2004-07-15 |
| JP3799010B2 true JP3799010B2 (ja) | 2006-07-19 |
Family
ID=32765403
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002369070A Expired - Fee Related JP3799010B2 (ja) | 2002-12-19 | 2002-12-19 | メッシュ型ネットワーク用ブリッジ |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7366191B2 (ja) |
| JP (1) | JP3799010B2 (ja) |
Families Citing this family (74)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7234157B2 (en) * | 2002-06-27 | 2007-06-19 | Lenovo Singapore Pte Ltd | Remote authentication caching on a trusted client or gateway system |
| US7792991B2 (en) | 2002-12-17 | 2010-09-07 | Cisco Technology, Inc. | Method and apparatus for advertising a link cost in a data communications network |
| US7707307B2 (en) * | 2003-01-09 | 2010-04-27 | Cisco Technology, Inc. | Method and apparatus for constructing a backup route in a data communications network |
| IL155449A (en) * | 2003-04-15 | 2008-06-05 | Eci Telecom Ltd | Technology for improving stp protocols in ethernet networks supporting vlans |
| US20060029074A2 (en) * | 2004-02-09 | 2006-02-09 | Packethop, Inc. | ENHANCED MULTICASE FORWARDING CACHE (eMFC) |
| US7716363B1 (en) * | 2004-02-10 | 2010-05-11 | Cisco Technology, Inc. | Method and apparatus of providing zero configuration single source multicasting reporting |
| US8868790B2 (en) | 2004-02-13 | 2014-10-21 | Oracle International Corporation | Processor-memory module performance acceleration in fabric-backplane enterprise servers |
| US7633955B1 (en) | 2004-02-13 | 2009-12-15 | Habanero Holdings, Inc. | SCSI transport for fabric-backplane enterprise servers |
| US7843906B1 (en) | 2004-02-13 | 2010-11-30 | Habanero Holdings, Inc. | Storage gateway initiator for fabric-backplane enterprise servers |
| US7359383B2 (en) * | 2004-03-29 | 2008-04-15 | Hewlett-Packard Development Company, L.P. | Load balancing with mesh tagging |
| US7376089B2 (en) * | 2004-03-29 | 2008-05-20 | Hewlett-Packard Development Company, L.P. | Multiple-instance meshing |
| JP2005318086A (ja) * | 2004-04-27 | 2005-11-10 | Fujitsu Ltd | 伝送装置 |
| US8713295B2 (en) | 2004-07-12 | 2014-04-29 | Oracle International Corporation | Fabric-backplane enterprise servers with pluggable I/O sub-system |
| US7872989B1 (en) * | 2004-07-12 | 2011-01-18 | Habanero Holdings, Inc. | Full mesh optimization for spanning tree protocol |
| JP4532253B2 (ja) * | 2004-12-20 | 2010-08-25 | 富士通株式会社 | フレーム転送装置及びフレームのループ抑止方法 |
| US7916668B2 (en) * | 2004-12-30 | 2011-03-29 | Alcatel Lucent | Spanning tree protocol with burst avoidance |
| US7626967B2 (en) * | 2005-01-05 | 2009-12-01 | Intel Corporation | Methods and apparatus for providing a transparent bridge associated with a wireless mesh network |
| US7933197B2 (en) | 2005-02-22 | 2011-04-26 | Cisco Technology, Inc. | Method and apparatus for constructing a repair path around a non-available component in a data communications network |
| US7957277B2 (en) | 2005-02-25 | 2011-06-07 | Interdigital Technology Corporation | Wireless communication method and system for routing packets via intra-mesh and extra-mesh routes |
| US8036597B2 (en) * | 2005-04-01 | 2011-10-11 | Interdigital Technology Corporation | Method and apparatus for determining a level of involvement of mesh points in a wireless communication system |
| US7848224B2 (en) * | 2005-07-05 | 2010-12-07 | Cisco Technology, Inc. | Method and apparatus for constructing a repair path for multicast data |
| US8325629B2 (en) * | 2005-07-15 | 2012-12-04 | Cisco Technology, Inc. | System and method for assuring the operation of network devices in bridged networks |
| KR101298155B1 (ko) | 2005-07-21 | 2013-09-16 | 파이어타이드, 인코포레이티드 | 임의적으로 상호접속된 메쉬 네트워크들의 효율적 작동을가능케하는 방법 |
| US7693043B2 (en) * | 2005-07-22 | 2010-04-06 | Cisco Technology, Inc. | Method and apparatus for advertising repair capability |
| US7969994B2 (en) * | 2005-07-29 | 2011-06-28 | Hewlett-Packard Development Company, L.P. | Method and apparatus for multiple connections to group of switches |
| US7668173B2 (en) * | 2005-12-01 | 2010-02-23 | Azalea Networks | Method and system for an adaptive wireless routing protocol in a mesh network |
| US7944853B2 (en) * | 2006-01-06 | 2011-05-17 | Belair Networks Inc. | Virtual root bridge |
| CN100442779C (zh) * | 2006-02-10 | 2008-12-10 | 华为技术有限公司 | 一种以太网中的控制***和数据报文传输方法 |
| JPWO2007094520A1 (ja) * | 2006-02-16 | 2009-07-09 | 日本電気株式会社 | ノード、ネットワークシステム、フレーム転送方法及びフレーム転送プログラム |
| US7768926B2 (en) * | 2006-03-09 | 2010-08-03 | Firetide, Inc. | Effective bandwidth path metric and path computation method for wireless mesh networks with wired links |
| JP4822905B2 (ja) * | 2006-03-31 | 2011-11-24 | 富士通株式会社 | ブリッジ装置、ブリッジ装置における制御方法、及び制御プログラム |
| CN100583825C (zh) * | 2006-08-30 | 2010-01-20 | 华为技术有限公司 | 最短路径桥中对称树的生成方法 |
| US7940776B2 (en) | 2007-06-13 | 2011-05-10 | Cisco Technology, Inc. | Fast re-routing in distance vector routing protocol networks |
| CA2703546A1 (en) | 2007-10-25 | 2009-04-30 | Trilliant Networks, Inc. | Gas meter having ultra-sensitive magnetic material retrofitted onto meter dial and method for performing meter retrofit |
| JP4808274B2 (ja) * | 2007-11-21 | 2011-11-02 | 富士通株式会社 | ネットワークの試験方法及びシステム |
| EP2215545A4 (en) * | 2007-11-25 | 2011-04-20 | Trilliant Networks Inc | SYSTEM AND METHOD FOR UPDATE PROCESSING |
| US8332055B2 (en) | 2007-11-25 | 2012-12-11 | Trilliant Networks, Inc. | Energy use control system and method |
| CA2714026A1 (en) * | 2007-11-25 | 2009-05-28 | Trilliant Networks, Inc. | System and method for transmitting and receiving information on a neighborhood area network |
| EP2215556B1 (en) * | 2007-11-25 | 2019-08-28 | Trilliant Networks, Inc. | System and method for transmitting power status notifications in an advanced metering infrastructure network |
| EP2215555A4 (en) * | 2007-11-25 | 2011-01-26 | Trilliant Networks Inc | SYSTEM AND METHOD FOR OPERATING MESH DEVICES IN OVERLAPPING MESH NETWORKS WITH MULTIPLE TREE STRUCTURE |
| JP4586902B2 (ja) | 2008-07-16 | 2010-11-24 | 日本電気株式会社 | ブリッジ、システム、ブリッジ制御方法、及びプログラム |
| US7881228B2 (en) * | 2008-07-23 | 2011-02-01 | Hewlett-Packard Development Company, L.P. | System and method for broadcast pruning in Ethernet based provider bridging network |
| FR2945690B1 (fr) * | 2009-05-13 | 2011-05-20 | Canon Kk | Procede et dispositif de parametrage d'un pont au sein d'un reseau de communication. |
| US8787211B2 (en) * | 2009-05-13 | 2014-07-22 | Telefonaktiebolaget Lm Ericsson (Publ) | Methods and arrangements for configuring the L2GPs in a first STP domain connected towards a second STP domain |
| US9270487B1 (en) * | 2009-10-13 | 2016-02-23 | Teradata Us, Inc. | Full bisection bandwidth network |
| US8805983B2 (en) * | 2009-10-19 | 2014-08-12 | Dell Products L.P. | Local externally accessible managed virtual network interface controller |
| US8284681B2 (en) * | 2010-06-01 | 2012-10-09 | Etherwan Systems, Inc. | Expandable network system and redundant method for the same |
| US8542578B1 (en) | 2010-08-04 | 2013-09-24 | Cisco Technology, Inc. | System and method for providing a link-state path to a node in a network environment |
| CA2809034A1 (en) | 2010-08-27 | 2012-03-01 | Randy Frei | System and method for interference free operation of co-located tranceivers |
| US9215124B2 (en) * | 2010-11-03 | 2015-12-15 | Broadcom Corporation | Unified vehicle network frame protocol |
| WO2012068045A2 (en) | 2010-11-15 | 2012-05-24 | Trilliant Holdings Inc. | System and method for securely communicating across multiple networks using a single radio |
| US20130259050A1 (en) * | 2010-11-30 | 2013-10-03 | Donald E. Eastlake, III | Systems and methods for multi-level switching of data frames |
| US9282383B2 (en) | 2011-01-14 | 2016-03-08 | Trilliant Incorporated | Process, device and system for volt/VAR optimization |
| US8970394B2 (en) | 2011-01-25 | 2015-03-03 | Trilliant Holdings Inc. | Aggregated real-time power outages/restoration reporting (RTPOR) in a secure mesh network |
| WO2012173667A2 (en) | 2011-02-10 | 2012-12-20 | Trilliant Holdings, Inc. | Device and method for facilitating secure communications over a cellular network |
| WO2012122310A1 (en) | 2011-03-08 | 2012-09-13 | Trilliant Networks, Inc. | System and method for managing load distribution across a power grid |
| US9001787B1 (en) | 2011-09-20 | 2015-04-07 | Trilliant Networks Inc. | System and method for implementing handover of a hybrid communications module |
| US9571387B1 (en) * | 2012-03-12 | 2017-02-14 | Juniper Networks, Inc. | Forwarding using maximally redundant trees |
| US9179197B2 (en) * | 2012-10-10 | 2015-11-03 | Sonos, Inc. | Methods and apparatus for multicast optimization |
| GB2524749B (en) * | 2014-03-31 | 2018-12-19 | Metaswitch Networks Ltd | Spanning tree protocol |
| US9692684B2 (en) * | 2014-09-05 | 2017-06-27 | Telefonaktiebolaget L M Ericsson (Publ) | Forwarding table precedence in SDN |
| EP3213584B1 (en) * | 2014-10-30 | 2020-02-26 | Telefonaktiebolaget LM Ericsson (publ) | Handling of backup path in a wireless communication system |
| US10193789B2 (en) * | 2015-10-07 | 2019-01-29 | Arris Enterprises Llc | Handling port identifier overflow in spanning tree protocol |
| US10554425B2 (en) | 2017-07-28 | 2020-02-04 | Juniper Networks, Inc. | Maximally redundant trees to redundant multicast source nodes for multicast protection |
| KR102543905B1 (ko) * | 2018-08-13 | 2023-06-15 | 삼성전자 주식회사 | 5G Ethernet service를 제공하는 방법 및 장치 |
| CN108881070A (zh) * | 2018-09-12 | 2018-11-23 | 盛科网络（苏州）有限公司 | 用于在Smart Link组中的选择端口的方法和装置 |
| US10721163B1 (en) * | 2019-03-15 | 2020-07-21 | Dell Products L.P. | Spanning tree protocol bridge-based link selection system |
| WO2020224958A1 (en) * | 2019-05-03 | 2020-11-12 | Nokia Technologies Oy | Method and apparatus for port management of ethernet bridges |
| US20220321485A1 (en) * | 2019-06-14 | 2022-10-06 | Nokia Technologies Oy | Apparatus, method and computer program |
| US11689455B2 (en) * | 2020-05-28 | 2023-06-27 | Oracle International Corporation | Loop prevention in virtual layer 2 networks |
| US11831544B2 (en) | 2020-07-14 | 2023-11-28 | Oracle International Corporation | Virtual layer-2 network |
| US11757773B2 (en) | 2020-12-30 | 2023-09-12 | Oracle International Corporation | Layer-2 networking storm control in a virtualized cloud environment |
| US11671355B2 (en) | 2021-02-05 | 2023-06-06 | Oracle International Corporation | Packet flow control in a header of a packet |
| US11777897B2 (en) | 2021-02-13 | 2023-10-03 | Oracle International Corporation | Cloud infrastructure resources for connecting a service provider private network to a customer private network |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5138615A (en) * | 1989-06-22 | 1992-08-11 | Digital Equipment Corporation | Reconfiguration system and method for high-speed mesh connected local area network |
| JPH0662011A (ja) | 1992-08-04 | 1994-03-04 | Fujitsu Ltd | Ｌａｎ収容及びバックアップ機能付きｔｄｍ |
| JPH06120949A (ja) | 1992-10-08 | 1994-04-28 | Omron Corp | ネットワーク間相互接続システム |
| US6246689B1 (en) * | 1998-09-21 | 2001-06-12 | Lucent Technologies Inc. | Method and apparatus for efficient topology aggregation for networks with hierarchical structure |
| JP3787048B2 (ja) | 1999-12-24 | 2006-06-21 | 富士通株式会社 | パケット中継装置冗長構成システム及びパケット中継装置冗長構成方法 |
| EP1132844A3 (en) * | 2000-03-02 | 2002-06-05 | Telseon IP Services Inc. | E-commerce system facilitating service networks including broadband communication service networks |
| JP3967141B2 (ja) | 2002-01-28 | 2007-08-29 | 富士通株式会社 | フレーム中継システムおよびフレーム中継装置 |
-
2002
- 2002-12-19 JP JP2002369070A patent/JP3799010B2/ja not_active Expired - Fee Related
-
2003
- 2003-12-09 US US10/732,507 patent/US7366191B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US20040190454A1 (en) | 2004-09-30 |
| US7366191B2 (en) | 2008-04-29 |
| JP2004201140A (ja) | 2004-07-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3799010B2 (ja) | メッシュ型ネットワーク用ブリッジ | |
| JP3715501B2 (ja) | スパニングツリー用ブリッジ及びそれを用いた経路変更方法 | |
| JP4031500B2 (ja) | ノード冗長方法、インタフェースカード、インタフェースデバイス、ノード装置およびパケットリングネットワークシステム | |
| JP4860949B2 (ja) | パケット交換通信網における迅速な端末間フェイルオーバーを提供する方法及び装置 | |
| JP4836008B2 (ja) | 通信システム、通信方法、ノード、およびノード用プログラム | |
| JP5566463B2 (ja) | コンピュータネットワークにおけるデータ転送の技術 | |
| JP3664935B2 (ja) | スパニングツリープロトコルを用いたブリッジ経路決定方法及びスパニングツリープロトコルを備えたブリッジ | |
| US7619966B2 (en) | Hybrid virtual private LAN extensions | |
| US7120683B2 (en) | Single switch image for a stack of switches | |
| JP4459018B2 (ja) | ノード装置 | |
| CN101047601B (zh) | 基于vpls的双归属网络的实现方法及*** | |
| US8811235B2 (en) | System and method for assuring the operation of network devices in bridged networks | |
| JP3635268B2 (ja) | ブリッジ及びそれを用いた経路変更方法 | |
| US11477116B2 (en) | Loop detection in ethernet packets | |
| US20090274155A1 (en) | Technique for providing interconnection between communication networks | |
| US20080310430A1 (en) | Control System, Data Message Transmission Method And Network Device In The Ethernet | |
| WO2006011689A1 (ja) | ネットワークシステム、ノード及びノード制御プログラム、ネットワーク制御方法 | |
| JP2003008609A (ja) | 回線の冗長機能付き通信装置 | |
| KR20080089285A (ko) | 이더넷 링 네트워크에서의 보호 절체 방법 | |
| JPWO2002087175A1 (ja) | リストレーション・プロテクション方法及び装置 | |
| WO2008119300A1 (fr) | Procédé et dispositif de protection pour service d'arborescence ethernet | |
| CN101610221B (zh) | 一种stp切换时ip单播平滑切换的方法及装置 | |
| JP2005130049A (ja) | ノード | |
| JP2002330152A (ja) | 障害時／増設時におけるスパニングツリー制御装置及び方法 | |
| JP4137947B2 (ja) | メッシュ型ネットワーク用ブリッジ |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20051121 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051129 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060130 |
|
| 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: 20060328 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060421 |
|
| 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: 20090428 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100428 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |