JP5180972B2 - ネットワークツリー管理のための方法と装置 - Google Patents

Description

本発明は、一般的には、コンピュータネットワークにおけるデータトラフィックを制御するために成されており、そして、より具体的には、イーサネット（登録商標）やリンク状態原理を用いている同様なネットワークにおけるツリー管理のための方法とシステムに関する。

［関連する出願と優先権の主張］
本出願は、２００７年１月１９日に出願された米国仮出願６０／８８５、６６７での出願日に関連し、その出願日における利益を要求する。この出願は全て、その内容を参照によって本出願に組み込んだものとする。

コンピュータは、大まかに言って、しばしばデータと呼ばれる、有益な目的のための情報を蓄積して保存する能力を持つ電気機器である。多くの場合に、多数のコンピュータがお互いにデータを送信するために互いに接続される。そのように接続されているコンピュータの集合は、しばしばネットワークと呼ばれ、そして、２つのネットワークノードの間のコネクターはリンクと呼ばれる。コンピュータネットワークの１つのタイプはＬＡＮ（local area network）と呼ばれ、例えば、小規模なビジネスのオフィスや教育施設において見うけられる。多数のＬＡＮやその他のネットワークは、同様に、お互いに通信に組み込まれ得る。当然のことであるが、規則の体系、または、決められた手続きが、コンピュータとネットワークが互いに効果的に通信することができるように導入されなければならない。そのような規則や手続きの体系は、しばしばプロトコルと呼ばれ、そして、いくつかのものがコンピュータネットワークを含む通信のために発達してきている。

ＬＡＮ通信のためのプロトコルとして広範囲に認可されたグループは、ＩＥＥＥ（電気電子技術者協会：Institute of Electrical and Electronics Engineers）の援助の下で開発されてきている。一般的にＩＥＥＥ８０２と呼ばれる標準は、例えば、一般的なネットワークアーキテクチャをカバーし、ＩＥＥＥ８０２．１はブリッジングとマネージメントとを扱い、そして、ＩＥＥＥ８０２．３はイーサネットプロトコルである。イーサネットＬＡＮは一般的に、衝突検出や回避のシステムを使って、トラフィック、すなわち、あるコンピュータから他のコンピュータやその他の機器へのデータのフローを取り扱う（'衝突'は２またはより多くのコンピュータが同時に同じリンクを介してデータを送信しようと試みるときに発生する。）。これらの標準は定期的に改訂され、そして、ネットワークオペレーションの改善および技術の発展の考慮による必要性に応じて更新される。

典型的なイーサネットネットワークにおいては、あるコンピュータから他のコンピュータに送信されたデータやあるネットワークから他のネットワークに送信されたデータは、瞬時にまたは連続的に送信されるのではなく、その代わりに、離散的な'フレーム'に分割される。データフレームを使うことによって、ネットワークコンピュータはデータを交互に送信することがより一層可能となる。フレームは長さが変化する場合もあるが、それぞれのフレームは十分なアドレス情報を（実際のデータに加えて）含んでおり、そのため、フレームは所望の１つ以上の目的地に運ばれてよい。ルーティングは、それぞれのコンピュータがお互いに直接接続されていないために必要である。その代わりに、コンピュータとネットワークは中間機器に接続されており、中間機器は、データを受信し、目的アドレスを決定し、目的アドレスに応じてデータをルーティングする。そのような中間機器１つはブリッジと呼ばれている。ブリッジはネットワークコンポーネントに常駐するソフトウェアスイッチのタイプである。データフレームは送信元から送信先への経路上の多くのブリッジを介して運ばれうる。

図１５は、典型的なネットワーク１０のブリッジを示す単純化された接続図である。本発明の実施形態は、そのようなネットワークでの実装に有利である。ネットワーク１０は多くの構成要素を有してもよいが、明確にするために、ブリッジそのものだけが図示されている。コンピュータやサブネットワークのような個々の構成要素は、ブリッジの１つに接続され得る。図１５の実施形態には、１から９までの番号が振られた９つのブリッジが存在するが、本発明はより大きなまたは小さなネットワークにおける実装にもまた適している。図１５において、リンクは、接続するブリッジに従って番号が振られている。例えば、リンク２４は、ブリッジ２を直接ブリッジ４に接続している。経路とは、あるブリッジから他のブリッジへの全てのリンクを含んだものである。例えば、ブリッジ１からブリッジ９へのある経路は、リンク１３と、３８、８９を含んでいる。任意の２つのブリッジ間に２以上の経路があってもよいことは明らかである。

ブリッジが、例えば、ネットワークコンピュータまたはその他のブリッジからデータフレームを受信するとき、アドレス情報を検査し、それに従ってフレームを転送する。データは、その送信元から送信先に対していくつかのブリッジを経由しなければならないかもしれない。しかしながら、運用プロトコルがなければ、データのフレームは、何らかの原因によりブリッジからブリッジに、ついには、同じループに再送信されて以前たどり着いたブリッジに一巡して戻って、送信されるかもしれない。これは明らかに期待される現象ではなく、様々な技術がこのループ問題を避けるために発達してきている。

ループを避けるひとつの技術は、設定が固定されたネットワークを使って、常に同じ経路で特定の送信先を目指してフレームを搬送することであろう。ほとんどのネットワークは、しかしながら、変化する可能性があり、そして、時には構成要素とリンクの機能停止や輻輳に直面する。静的なルーティングシステムは、したがって、最善の解決方法ではない。さらに上手な解決方法では、'スパニングツリー（全域木）'がスパニングツリープロトコル（ＳＴＰ）に従って定期的に計算される。このスパニングツリーは、ツリー計算の際に存在するネットワークの経路を定義する。障害やその他のイベントの場合には、新しい状態に適応するためにツリーを再計算することができる。

スパニングツリーの計算は、好適には、各送信元から各送信先への経路を指定するだけでなく、どのような場合でもネットワーク通信が効果的なやり方で達成されるように、最適な経路を決定することを含む。ＩＥＥＥでの標準は、例えば、ネットワークのためのアクティブなトポロジーを決定するために、しばしば距離ベクトルメカニズムを使用する。アクティブなトポロジーは、データトラフィックの経路を決定するために使われることになる、データを転送する経路のツリーに関するものである。この距離ベクトル技術は公知のため、ここでは詳細には述べない。ただし、アクティブなトポロジーは分散的手法で設計されており、そのため、ネットワークにおけるどんなブリッジもデータ分配スキームをその全体として意識していない。従って、そのトポロジーは最適でない可能性があり、また、おそらくそうである。距離ベクトルによるアプローチは、また、ネットワークのどこかで発生している障害からの復旧、といった障害の扱いにおいて効率的でない。

より良い解決法は、ＯＳＰＦ（open shortest path first）やＩＳ−ＩＳ（intermediate system to intermediate system）のような、ルーティングプロトコルを使っているＩＰ（Internet protocol）の中心となる機能を適用することによって、リンク状態スパニングツリー計算を実行することであろう。ＩＰプロトコルは、典型的に、ＩＥＴＦ（Internet engineering task force）によって開発され、そして、広められた。一般的に、リンク状態アプローチは、トラフィック工学の応用を容易にし、そして、アクティブなトポロジーが最適化されることを可能にする。しかしながら、ＩＰルーティングプロトコルを直接実装することは、それぞれのブリッジが自分自身の転送テーブルを構成しなければならないかもしれないことを意味するであろう。これは、それ自体としては有害なことではないが、結果的に少なくとも一時的なループとなる長い利用できない期間を生み出すだろう。その他の問題の複雑さは、イーサネットフレームはＴＴＬ（time to live）フィールドを含まないため（ＩＰパケットのような）、一時的なループが、アクティブなトポロジーの変化が発生するときに問題になるかもしれないことである。もちろん、トポロジーが変化していることに気づいているブリッジは、新しいトポロジーが計算されるまで簡単にデータフレームを転送することを止めることができるかもしれないが、この手続きは、復旧を重大に鈍化する。

従って、スパニングツリーの計算にリンク状態アプローチを実装する方法のための当該技術分野における必要性が存在し、その計算は、リンク状態プロトコルの長所を保ったまま、しかし、それらが持っている問題、特に、時々アクティブなトポロジーを変化することに関連する問題、を軽減または消去する。本発明は、まさにそのような解決法を提供するものである。

先行技術における上で述べた欠陥に対処するために、コンピュータネットワーク、例えばイーサネットＬＡＮ、のアクティブなトポロジーを構成するための方法や配置を提供することが本発明の第１の目的である。本発明のさらなる目的は、ネットワークツリー管理に改善されたリンク状態アプローチを適用することであり、その改善されたリンク状態アプローチは、とりわけ、従来のアプローチに比べて有利な構成と改良された復旧時間を持つ。

一態様において、本発明は、イーサネットＬＡＮのようなネットワークを設定するための方法であり、データトラフィックの効果的な転送のために、近隣情報を収集し、リンク状態通知を生成および分配し、ネットワークのためのトポロジーデータベースを投入し、ルートブリッジにおいて、トポロジーデータベースから利用するツリー内のそれぞれのブリッジのためのポート状態を計算する。本方法では、さらに、ツリー通知メッセージを選択的に分配することによってツリーを通知し、ツリーのブリッジにおいてツリー通知メッセージを受信し、通知メッセージに従ってそれぞれのブリッジのポートを設定してもよい。本方法は、また、さらに、リンク状態通知をすでに処理しているネットワークブリッジにおける認識の特徴、そして、それらを転送するのではなく破棄することを含んでいてもよい。このようにして、ルーティング対象物の柔軟な集合の適用を可能とするリンク状態ＳＴＰのためのプロトコルが定義される。

別の態様において、本発明は少なくとも1つのルートブリッジを含むネットワークであって、当該ルートブリッジは、少なくとも1つの他のネットワークブリッジのポート状態を遠隔的に設定する。好適な実施形態において、アクティブなネットワークトポロジーは、ルートブリッジで計算され、全ての他のネットワークブリッジに課される。したがって、ルートブリッジはトポロジーデータベースを構築し、ネットワークのためのスパニングツリーを計算するためにトポロジーデータベースを使用するように構成される。ルートブリッジは、非ルートブリッジのためのツリーを記述するツリー通知メッセージを生成し、分配するようにさらに構成される。非ルートブリッジは、ツリー通知メッセージを受信し、処理するように構成される。非ルートブリッジは、ツリー通知メッセージにおける記述に従って自身のポートを設定し、選択的にリーフブリッジの方向にツリー通知メッセージを転送するようにも構成される。非ルートブリッジは、ツリー通知メッセージを他のブリッジに転送する前にツリー通知メッセージ内のツリー記述を修正するように構成されてもよい。このように、障害を追跡するデータベースを同期させるための時間が必要なくなるので、リンク状態データベース内の任意の潜在的な不一致に起因する問題が軽減または完全に解消されうる。いくつかの実施形態では、代替またはバックアップポートの使用が、障害状態が検出されたときに実施される。 さらに別の態様において、本発明はネットワークで使用するブリッジである。該ブリッジは、収集されたネットワーク情報に基づいてスパニングツリーを計算することによって、ルートブリッジとして機能し、計算されたツリーに従って自身を設定し、スパニングツリー内の他のブリッジを遠隔的に設定するように構成される。

以上では、当業者がこれから述べる本発明の詳細な説明をより良く理解しうるように、本発明の特徴や技術的利点をむしろ広く述べた。本発明の追加的な特徴や利点は以下に述べられ、本発明の請求項の主題を形成する。当業者は直ちに、本発明と同じ目的を実行するためのその他の構成を修正したり設計したりする基礎として、記載した思想や具体的な実施形態を使用可能であることを理解すべきである。 当業者はまた、そのような均等な構成は、その最も広い形式での本発明の精神および範囲から離れるものではないことを理解するべきである。

詳細な説明に入る前に、本明細書を通じて使われる特定の単語とフレーズに関して４つの定義を与えることは有意義であろう。用語"包含する（include）"と"備える（comprise）"は、その派生語と同様に、制限のない包含を意味する。用語"または（or）"は、および／または、の意味を含む。フレーズ"〜と関連する（associated with）"と"〜とともに関連する（associated therewith）"は、その派生語と同様に、〜を含む（include）、〜に含まれている（be included within）、〜と相互に接続する（interconnect with）、収容する（contain）、〜に収容される（be contained within）、〜にまたは〜と接続する（connect to or with）、〜にまたは〜と対になる（couple to or with）、〜と通信可能である（be communicable with）、〜と協調する（cooperate with）、インターリーブする（interleave）、〜を並置する（juxtapose）、〜に最も近い（be proximate to）、〜にまたは〜と隣接する（be bound to or with）、〜を持つ（have）、〜の性質を持つ（have a property of）、または同様なもの、を意味してもよい。そして、用語"コントローラ（controller）"は、少なくとも1つの操作を制御する任意のデバイス、システムやそれについての一部を意味し、そのようなデバイスは、ハードウェア、ファームウェアまたはソフトウェア、または同様なものからなる少なくとも２つのもののいくつかの組み合わせで実施されていてもよい。任意の特定のコントローラに関連する機能は、局所的であろうと遠隔的であろうと、集中化または分散化されうることに留意すべきである。特に、コントローラーは、１つ以上のデータプロセッサ、関連した入出力デバイスとメモリを含んでいてもよく、データプロセッサは、１つ以上のアプリケーションプログラムおよびオペレーティングシステムプログラムの少なくともいずれかを実行する。特定の単語とフレーズのための定義は本明細書を通じて与えられ、当業者は、ほとんどの例なしでも、そのことの大部分を理解するべきであり、そのような定義は、そのように定義された単語とフレーズの将来での使用と同様に、以前のものに対しても適用する。

本発明のより完全な理解のために、そして、その利点のために、参照は、添付の図面に併用して続く説明に対して作成されており、ここで同じ数字は同じ対象である：

本発明の実施形態に従って近隣発見を実行する方法を図示するフロー図である。 本発明の実施形態に従ってリンク状態通知（link state advertisement；LSA）を処理する方法を図示するフロー図である。 本発明の実施形態に従ってスパニングツリーを計算する方法を図示するフロー図である。 本発明の実施形態に従ったツリー設定の方法を図示するフロー図である。 本発明の実施形態に従ったＬＳＳＴＰ＿ＢＰＤＵ（link state spanning tree protocol bridge protocol data unit）を表す。 本発明の実施形態に従ったＬＳＡ＿ＢＤＰＵのためのＬＳＳＴＰパラメータを図示する。 本発明の実施形態に従ったＬＳＡ＿ＢＤＰＵのためのＬＳＳＴＰパラメータを図示する。 本発明の実施形態に従ったＬＳＡ＿ＢＤＰＵのためのＬＳＳＴＰパラメータを図示する。 本発明の実施形態に従ったＴＡ＿ＢＤＰＵ（tree advertisement BDPU）のためのＬＳＳＴＰを図示する。 本発明の他の実施形態に従ったＴＡ＿ＢＤＰＵのための簡単化されたＬＳＳＴＰを図示する。 本発明の実施形態が有利に実装されうる例示的なスパニングツリートポロジーを図示する。 本発明の実施形態に従った図９で示されるブリッジ１のためのツリー記述を図示する。 本発明の実施形態に従った図９で示されるブリッジ２のためのツリー記述を図示する。 本発明の実施形態に従った図９で示されるブリッジ３のためのツリー記述を図示する。 本発明の実施形態に従ったブリッジ構成を図示する。 本発明の実施形態に従ったルーティングプロトコルにおけるスパニングツリープロトコルの操作を図示する。 本発明の実施形態が有利に実装されうる例示的なネットワークのブリッジを図示する単純化された接続図である。 本発明の実施形態に従ったデータトラフィックフローを容易にする方法を図示するフロー図である。

ここで議論される図１から図１６と本明細書における本発明の原理を説明するために使われる様々な実施形態は、説明を目的としただけであって、決して本発明の範囲を制限する目的で解釈されるべきでない。当業者は、本発明の原理が任意の適当に配置されたコンピュータネットワークにおいて実施可能であることを理解するであろう。

本発明は、スパニングツリーアクティブトポロジーを使って、イーサネットＬＡＮ（local area network）のようなネットワークのデータトラフィックフローの管理を容易にすることに対する新しいアプローチを指向している。図１６は、本発明の実施形態に従ったデータトラフィックフローを容易にする方法２０を図示するフロー図である。スタート時点で、図１５に示されている構成のように、ネットワークは複数のブリッジを介してデータを通信できるように構成されている。例えば、このネットワークはイーサネットＬＡＮネットワークであって、ＩＥＥＥ８０２ファミリーのプロトコルに従って動作可能であるが、他の同様に構成されたネットワークも同じように使用されうる。この処理は、ネットワークが構成されて、そして操作のために活性化されたとき、または、ネットワークオペレータによって決定された所定の時間後に始まる。この実施形態においては、ネットワークのためのルートブリッジは決定されているということも仮定している。これは多くの方法でなし得ることであるが、与えられた実施形態で特に言及されない限り、本発明では特定の方法は要求されない。図１６の方法２０に戻ると、それぞれのネットワークブリッジが接続される他のブリッジを学習できるように、ステップ１０５における近隣発見が実行される。次に、近隣発見ステップ１０５で発見された情報はＬＳＡｓ（link state advertisements：リンク状態通知）を介して他のブリッジに送信される（ステップ１１０）。ＬＳＡｓはネットワークに氾濫するが、好適な実施形態において、例えば、特定のＬＳＡに含まれている情報をすでに学習していることを認識しているブリッジによって、それらは廃棄される（ステップは図示されていない）。

次に、ルートブリッジはトポロジーデータベースを収集し（ステップ１１５）、ネットワークのためのスパニングツリーを作成するためにトポロジーデータベースを使用し、それぞれのブリッジ（非ルート）のための必要なポート設定（ステップ１２０）を計算する。もちろん、それぞれのブリッジのためのポート設定は、ネットワークでの計算されたスパニングツリーを実行する。本発明に基づいて、ルートブリッジはそれぞれの非ルートブリッジのためにこれらを決定する。次に、ルートブリッジはネットワーク要素にＴＡｓ（tree advertisements：ツリー通知）を送信することによってスパニングツリーを通知する（ステップ１２５）。それから、各ブリッジは、それらのＴＡメッセージを処理し、ＴＡに含まれている指示に従ってそのポートを設定する（ステップ１３０）。この時点で、スパニングツリーは本発明の実施形態に従って設定されており、データトラフィックのルーティング（ステップ１３５）は開始または継続のいずれかが、場合によって生じうる。

また一方で、本発明の1つの利点は、現在のアクティブなトポロジーに従ってトラフィックをルーティングできないという障害に対処するネットワークの設定手法にある。これを説明するために、図１６の方法２０は、障害状態が検出されるステップ１４０が継続する。ここで使われているような障害、または障害状態は、現在のアクティブなトポロジーに従ってデータを転送することを妨げるか、または著しく抑制するような事象のことをいう。すなわち、障害は実際の機能停止を含み得るが、ネットワークブリッジ、リンクまたはその他の構成要素の追加や削除、または重大なボトルネックもまた含み得る。この実施形態において、代替（またはバックアップ）トポロジーが確立されているかどうかが判定される（ステップ１４５）。もし確立されているならば、代替トポロジーが実行される（ステップ１５０）。もし確立されていないならば、または代替トポロジーが成功しなければ、この実施形態の処理はステップ１２０に戻り、そして新しいツリーが計算される。もちろん、これは、ルートブリッジ・トポロジー・データベースが周期的な近隣発見メッセージを通じて維持されており、リンク状態情報が最新のものであることを前提としている。その他の実施形態においては、代わりとして、処理は、トポロジーデータベースを生成または更新し、ステップ１２０で新しいスパニングツリーを計算する前の、近隣発見ステップ１０５またはＬＳＡステップ１１０に戻ってもよい。けれども、いずれにしても、ルートブリッジは遠隔的に非ルートブリッジのポート状態を設定するので、全てのブリッジデータベースが同期するまで待機する必要はなく、一般的にはより高速な復帰時間に帰着することになる。最後に、バックアップまたは代替トポロジーの計算は任意のものであるが、多くの場合には、障害後の迅速な回復を支援することになることに注意されたい。代替トポロジーは最初のアクティブなトポロジーが決定されたとき、またはその後に計算されてもよく、そして、別々に通知されてもよい。

本発明の実施形態に関連した様々な運用は、さらに詳細に説明される。この目的のために、ＬＳＡｓやＴＡｓのような、上で述べた様々なメッセージは、個別の目的のために本発明に従って修正された標準ＢＰＤＵｓ（bridge protocol data units：ブリッジ・プロトコル・データ・ユニット）の形式になっているものと仮定する。このような方法で修正されたＢＰＤＵの使用は好ましいものではあるが、要求はされない。

図１は本発明の実施形態に従って近隣発見を実行する方法２５を図示するフロー図である。再び、スタート時点で、ネットワークは物理的に構成されており、本発明の方法に従って運用可能であることを前提としている。この実施形態において、近隣情報は近隣発見メッセージ、好ましくはＮＤ＿ＢＰＤＵｓ（ステップ２０５）を介して収集される。その他の実施形態では、近隣情報を収集するために利用可能な他のタイプのメッセージが使用されてもよい。本実施形態において、ＮＤ＿ＢＰＤＵｓは所定の時間期間（"ハロータイム期間"）に従って送受信される。受信ＮＤ＿ＢＰＤＵｓは検査され、当該情報は後の参照のためにトポロジーデータベースに保存される（ステップは図示していない）。

ＮＤ＿ＢＰＤＵｓが各ハロータイム期間で受信されるので、トポロジーデータベースに既に保存されている情報を含むものが数多くなる。ある時には、新しい近隣ブリッジが自分自身を通知してもよく、或いは、予期されたＮＤ＿ＢＰＤＵが受信されず、ネットワークの設定に変化をシグナリングする。従って、各ハロータイム期間において、各ブリッジは受信ＮＤ＿ＢＰＤＵｓを検査し、新しいリンクが出現したか、或いは、既存のリンクがタイムアウトしたかどうかを判定する（ステップ２１０）。すなわち、有効性を保証するＮＤ＿ＰＤＵが受信されない場合は、トポロジーデータベースの要素は所定数のハロータイム期間の後にタイムアウトされ、そして消去されてもよい。もし変化が生じなければ、処理は単純にステップ２０５に戻り、各ハロータイム期間で発信される近隣情報を収集する。もし変化が検知されると、ブリッジはＬＳＡ＿ＢＰＤＵｓを変化を通知するために分配する（ステップ２１５）。トポロジーデータベースはまたこのとき更新されてもよい（ステップは図示されない）。そのとき各ブリッジは、それが現時点でのルートブリッジであるかどうかを判定し（ステップ２２０）、もしそうであれば、新たに獲得したネットワーク情報も用いてツリー計算を実行する（ステップ２２５）。ここで注意すべきは、本発明においては、ルートブリッジのみがツリー計算処理を実行する必要があることである。本発明によれば、ルートブリッジは、ツリーを構築するために、どのようなアクティブなトポロジーアルゴリズムを実行してもよい。

ステップ２１５で分配されたＬＳＡ＿ＢＰＤＵｓは、続いて、様々なネットワークブリッジで受信される。図２は本発明の実施形態に従ってリンク状態通知（ＬＳＡ）を処理する方法３０を図示するフロー図である。ＬＳＤ＿ＢＰＤＵがブリッジで受信されると（ステップ２３０）、最初に、それが期限切れのものであるか、または以前に受信されたものであるかどうかを判定するために検査される（ステップ２３５）。これは１つ以上の技術を用いて実行してもよい。例えば、受信するブリッジは、ＬＳＡ＿ＢＰＤＵのシーケンス番号と送信ブリッジ識別子を検査してもよい。もし、より新しいＬＳＡ＿ＢＰＤＵがすでにそのブリッジで受信されていれば、検査されたＬＳＡ＿ＢＰＤＵは破棄されてもよい。他の実施形態において、パス・ベクトル・メカニズムが採用され、受信ブリッジは、ＬＳＡ＿ＢＰＤＵが以前見たものであるかどうかを判定するように自身のビットが設定されているかどうかを確認する。さらに別の実施形態において、経過時間を検査されるＬＳＡ＿ＢＰＤＵｓについて、有効期限フィールド（time-to-live:ＴＴＬ）が利用されてもよい。もし、これらの手法の１つ以上のものがＬＳＡ＿ＢＰＤＵｓはもはや有用でないということを示せば、それは破棄される（ステップ２４０）。これはＬＳＡ＿ＢＰＤＵｓが最早有用でない場合に、ネットワーク内で不必要に巡回し続けることを防ぐのに役立つ（但し、使用する判定技術に依存しているので、ある条件の下では、同じブリッジで２回以上処理されることもあるかもしれない）。

もし、ＬＳＡ＿ＢＰＤＵが以前に受信されていなければ、そのときは、受信ポートを除いて、ブリッジの各ポート上に転送され（ステップ２４５）、ブリッジのトポロジーデータベースは更新される（ステップ２５０）。図１にあるように、トポロジーデータベースを更新している各ブリッジは、そのとき、現在ルートブリッジであるかどうかを判定し（ステップ２５５）、もしそうであれば、新たに獲得されたネットワーク情報も用いてツリー計算を実行する。ここで再び注意すべきは、本発明においては、ルートブリッジのみがツリー計算処理を実行する必要があることである。

図３は、本発明の１つの実施形態に従ってルートブリッジにおいて成されるツリー計算処理を示す。図３は、本発明の実施形態に従ってスパニングツリーを計算する方法３５を図示するフロー図である。図３の方法３５は、ツリーの変化が必要であるかどうかの判定から始まる（ステップ２６５）。この判定は一定間隔で、または、きっかけとなるイベントの発生に基づいて、またはその両方で実行されてもよい。もし、ツリーの変化が必要でなければ、当然のことながら、ネットワークの通常の動作を単に続けてよい。もし、ツリーの変化が必要であると判定されると、方法３５では、現在のトポロジーデータベースから新しいツリーを計算し始める（ステップ２７０）。（ここで注意すべきは、方法３５はルートブリッジの動作を表現しており、そのため、ルートブリッジの状態を決定するステップは図示されていない。）その後、ルートブリッジは、破棄するポートを設定し（ステップ２７５）、続いて転送するポートを設定する（ステップ２８０）。ツリー設定は、例えば、ＴＡ＿ＢＰＤＵメッセージを使ってネットワーク全体に分配される（ステップ２８５）。

ＴＡ＿ＢＰＤＵ（またはその他のツリー通知メッセージ）が非ルートブリッジで受信されると、必要に応じて処理され、転送される。図４は本発明の実施形態に従った非ルートブリッジにおけるツリー設定の方法４０を図示するフロー図である。この処理は、ＴＡ＿ＢＰＤＵが受信されたかどうかの判定から始まる（ステップ２９０）。もし受信していなければ、当然のことながら、データトラフィックのルーティングは、もしあるのならば、通常通りに続けてよい。もし受信していれば、ＴＡ＿ＢＰＤＵが読み出され（ステップ２９５）、廃棄するポートが、いずれにしても、設定される（ステップ３０５）。廃棄するポートは最初に設定されなければならないことはないが、その順序は、ループのないトポロジーを作成するのに好適であり、役立つ。転送するポートは、もしあるのならば、その後設定される（ステップ３１０）。少なくとも１つの転送するポートが設定されると仮定すると、ＴＡ＿ＢＰＤＵは、その後各ブリッジの転送するポート上に転送される（ステップ３１５）。

ＢＰＤＵメッセージの形式は、一般的に、以下及び図５から１２で説明するような、ある違いと特別な検討事項を伴って、ＩＥＥＥ８０２のＭＳＴＰ ＢＰＤＵ形式に従う。図５は、本発明の実施形態に従った、ＬＳＳＴＰ＿ＢＰＤＵ（リンク状態スパニングツリーＢＰＤＵ：link state spanning tree protocol BPDU）４５を表す。本発明の実施に特に関連したＬＳＳＴＰ＿ＢＰＤＵフィールドに関して、ＢＰＤＵタイプフィールド３２０は、ＬＳＳＴＰ＿ＢＰＤＵメッセージであることを示す。ハロータイムフィールド３２５は、ＮＤ＿ＢＰＤＵｓにおいてのみ使用され、ＬＳＳＴＰ＿ＢＰＤＵの他のタイプでは使用されない。ここで注意すべきは、ツリー設定識別子フィールド３３０は、ＩＥＥＥ８０２．１ａｐの仮想ブリッジ化ＬＡＮ−修正９(Virtual Bridged Local Area Networks-Amendment 9)：最短パスブリッジング(ドラフトＤ０．３、２００６年５月９日)において提案されたものと同じであることである。以下でより詳細に述べられるように、ＬＳＳＴＰ＿ＤＵのタイプに従って、ＬＳＳＴＰ＿ＢＰＤＵパラメータ３３５は変化する。

本発明に従ったＮＤ＿ＢＰＤＵｓに関して、ＬＳＳＴＰパラメータ３３５は空白である。それは、必要な対応リンクブリッジとポート識別子が、提案されたＩＥＥＥ８０２ ＭＳＴＰ ＢＰＤＵにおいて現在のところ仕様化されているからである。言い換えれば、近隣発見処理は、動作を成功させるために追加的なＬＳＳＴＰパラメータを必要としない。

本発明に従ったＬＳＡ＿ＢＰＤＵｓに関して、いくつかのオプションが利用可能である。これらのオプションは、ＬＳＡｓが失効していたり、または、既に有用でなくなった場合に該ＬＳＡｓを破棄する文脈で上述した異なる実施形態に一般には対応する。。これらのオプションは図６ａから６ｃに図示されており、これは、本発明の３つの実施形態に従ったＬＳＡ＿ＢＤＰＵのためのＬＳＳＴＰパラメータを示している。各実施形態において、各ＬＳＳＴＰパラメータはフラグフィールド３４０とＬＳＳＴＰ・コンピュテーション・プロトコル識別子フィールド３４５を含み、リンク記述情報３５５が後に続く。図６ａにおいて、選択的なＬＳＡ−除去フィールド３５０ａは、送信ブリッジのブリッジＩＤと共にシーケンス番号を含む。図６ｂにおいて、選択的なＬＳＡ−除去フィールド３５０ｂはパスベクトルを含む。それぞれのＬＳＡ除去フィールドに関連したＬＳＡ除去オプションは上述した（図２を参照）。３番目の実施形態において、図６ｃに示すように、標準のＢＰＤＵメッセージの一部分であるＴＴＬ情報が代わりに使用されるため、ＬＳＡ−除去フィールドは必要ない。ここで注意すべきは、これらの２以上のＬＳＡ−除去オプションは、必要があればＬＳＳＴＰパラメータ適切に変更した上で使用されてもよいが、２以上のオプションを使うことは、現在のところは好ましいものではない。代わりの実施形態において、ＬＳＡ除去オプションは全く使用されないが、これは推奨されない。

図７は、本発明の実施形態に従ったＴＡ＿ＢＤＰＵ（ツリー通知：tree advertisement BPDU）のためのＬＳＳＴＰを図示するものである。このタイプのメッセージもまた、フラグフィールド３６０とＬＳＳＴＰ・コンピュテーション・プロトコル識別子フィールド３６５を含む。ツリーＩＤフィールド３７０が続き、ブリッジ数フィールド３７５は、当然にツリーの中のブリッジの数を特定する。個別のブリッジフィールド３８０が続き、識別されたツリーにおける個々のブリッジのためのものである。個別のブリッジフィールドは、それぞれ、ツリーの中のブリッジのうちの１つのためのポート設定を識別する。本実施形態では、各ブリッジのための指定転送ポートが特定され、そのブリッジにおける残りのポートは破棄されるポートであると仮定されて、適宜設定される。上述のように、これらの破棄されるポートは、好適には、転送ポートを設定するより先に、最初に設定される。この実施形態において、各ブリッジＩＤの後にに速やかにルートポートも特定される。ルートブリッジに対する代替ポートもリストされてもよい（しかし、図７には図示されていない）。

図８は、本発明の他の実施形態に従ったＴＡ＿ＢＤＰＵのための単純化されたＬＳＳＴＰパラメータである。ここで、ツリーＩＤフィールド３７０に続くリンク数フィールド３８５は、ブリッジの数ではなく、ツリー中のリンク数と関連する。従って、リンクフィールド３９０は、リンク数フィールド３８５に続き、ブリッジ間のリンクに関連してツリーを記述している。これはＴＡ＿ＢＰＤＵの大きさを減らすが、それぞれのブリッジが、受信したツリー記述に基づいてポートをどのように設定するかを決定しなければならないため、処理の複雑さが増加する。このトレードオフが好まれるものであるかどうかはネットワークによって差異が生じうる。

アプリケーションによっては、なお一層の短縮形式が有用となろう。図９の典型的なツリートポロジーは、例えば、図１０から図１２に図示されたＴＡ＿ＢＰＤＵ系列を使って通知通知されてもよい。図９から分かるように、ブリッジ１は２つの指定ポートを有するので、そこから伸びる２つのブランチは特にブリッジ２と３に通じている。続いて、ブリッジ２はブリッジ４、５及び６に伸びる３つのブランチを有し、ブリッジ３はブリッジ７に伸びる１つのブランチを有する。ブリッジ４からブリッジ７はリーフブリッジであり、したがって、それらから伸びるブランチを有しない。

本実施形態によれば、最初のＴＡ＿ＢＰＤＵはブリッジ１において受信される。このメッセージ（または、それに関連した箇所）を図１０に示す。このタイプのメッセージもまた、フラグフィールド４０５とＬＳＳＴＰ・コンピュテーション・プロトコル識別子フィールド４１０を含む。ツリーＩＤフィールド４１５がその後に続く。ツリーＩＤフィールド４１５の後に第１のツリー記述フィールド４２０がある。この第１のツリー記述フィールドはブリッジ１で必要とされる情報、すなわち、続くリンクとブリッジの関連性、を含む。図１０に表されているように、括弧の最初の集合は、ブリッジ１のポート１に関連した全てのリンク及びブリッジの識別子を囲んでおり、そして括弧の２番目の集合は、ブリッジ１のポート２に関連した全てのリンク及びブリッジの識別子を囲んでいる。後者に関して、ポート２はブリッジ３へのリンクが指定されており、そして、ブリッジ３のポート１はブリッジ７へのリンクに指定されている。ブリッジ１のポート１はまた、１つのブリッジであるブリッジ２へのリンクが指定されているが、ブリッジ２は３つのポートを持っているので、それぞれがブリッジ４、５及び６の各１つへのリンクに指定されており、ブリッジ２のポートの指定は、図１０のツリー記述フィールド４２０内にある角括弧内の集合にそれぞれ分離されている。

必然的に、ブリッジ１は、自分自身のポート１と２を設定するために、ツリー記述フィールド４２０内の情報を使う。それから、それはブリッジ２に対してＴＡ＿ＢＰＤＵのある修正バージョンを送信し、そして適切なポートを使ってブリッジ３にまた別のものを送信する。いずれの場合でも、受け取りブリッジに当てはまらないポート指定は、送信に先立ってブリッジ１によって取り除かれる。ブリッジ２に対して送信されるＴＡ＿ＢＰＤＵが図１１に図示されている。図１１において、ツリー記述フィールド４２０−２内では、残りの全てはブリッジ−２のためのポート割り当てであることを見ることができる。同様に、図１２はＴＡ＿ＢＰＤＵを図示し、これはブリッジ１からブリッジ３へ送信されるものである。図１２において、ツリー記述フィールド４２０−３内では、残りの全てはブリッジ３のポート１のためのポート割り当てであることを見ることができ、これはブリッジ７へのリンクに指定されている。例えば、ブリッジ４へのリンクに指定されている。ここで注意すべきは、ブリッジ４からブリッジ７は、リーフブリッジであり、それ自体は、設定する転送ポートを持ち合わせていないということである。これらのリーフブリッジに送信されるＴＡ＿ＢＰＤＵｓ（図示されない）は、図１０から図１２で表されているものと同様であるが、それらのツリー記述フィールドはＮＵＬＬ値を持つことになる。

図１３は、本発明の実施形態に従ったブリッジアーキテクチャを図示している。ここで注意すべきは、ＯＳＰＦまたはＩＳ−ＩＳのようなＩＰリンク状態ルーティングプロトコルは、ループの防止が保証されていないので、修正無しでは、イーサネットネットワークにおける転送制御への応用には適さないということである。けれども、本発明においては、ルーティング・プロトコル・エントリーが図１３に図示されているものよりも高いレイヤーで実装されている。より高いレイヤーエントリーとしてのＳＴＰ（スパニング・ツリー・プロトコル：spanning tree protocol）エントリーの運用は、図１４に図示されている。このルーティング・プロトコル・エントリーは、ＳＰＴエントリーと同じく、ブリッジのそれぞれのポートに付属されている。このようにして、ルーティング・プロトコル・エントリーはそれぞれのポート上でフレームを送受信することができる。ネットワークに送出することになるルーティング・プロトコル・メッセージに関して、ルーティング・プロトコル・エントリーは、メッセージが受信されたポートを除いた各ポート上のメッセージを送出する。その他のメッセージは、ルーティング・プロトコル・エントリーによって処理され、そして、指定ポート上にのみ送信される。

上述のように、ルーティングプロトコルは、いくつかの修正をしなければ適用可能でない。最初に、ＩＰアドレスはルーティングプロトコルにおいて、ＭＡＣアドレスに置き換えられ、そして各フレームは、そのヘッダー内のＭＡＣアドレスに従って転送されるものである。２番目に、ツリー通知は、ルーティング・プロトコル・メッセージに挿入され、そして、詳述したように、ツリー通知の処理はネットワークブリッジに実装される。ここで注意すべきは、ツリー通知は、ルーティング−プロトコル拡張のために準備されているルーティング・プロトコル・オブジェクトで実行されてもよい。ＯＳＰＦルーティングのために、例えば、新しいタイプのオパークＬＳＡ（Opaque LSA）が要求されてもよい。ＯＳＰＦにおけるオパークＬＳＡは、一般的なプロトコル拡張を提供し、そしてツリー通知は拡張のタイプを考慮してもよい。好適な実施形態において、タイプ９（リンクローカル）は、ツリー通知オパークＬＳＡｓのために使われる。ツリー通知は、そこで適用できる同様なプロトコル拡張を用いてＩＳ−ＩＳルーティングプロトコルに実装されてもよい。

本発明に関連して、ツリー通知メッセージ（例えば、ＴＡ＿ＢＰＤＵｓ）は、想定外のループを避けるために、あふれさせるべきではない。むしろ、ツリー通知メッセージは、通知するツリーの一部であるリンク上でのみ転送され、ルートブリッジからリーフまで送信される。ツリートポロジーは、ルートブリッジにおいて計算され、そして全てのその他のブリッジは、受信したツリー通知に従ってそれらのポートを設定する。

ここで注意すべきは、本発明に従ったツリー通知メッセージの処理は、ブリッジのルーティング・プロトコル・エントリーに実装された新しい機能を示してもよい。この新しい機能は、ツリーの一部分であるポートの適切な設定を含んでいる。すなわち、ブリッジが、ツリー通知を全てのポートに氾濫させる代わりに、選択された近隣ブリッジにのみ送信する。ブリッジは、いくつかの実施形態において（上記のように）、指定ポート上にそれを転送する前に、ツリー通知を調整しなければならない。上で述べたツリー記述スキームは適切な機能を伴ったルーティングプロトコルで実装されてもよい。

このように、ＩＰルーティングプロトコルはイーサネットネットワークにおける転送の制御、すなわち、アクティブなトポロジーの設定、のために使用されてもよい。

本発明は詳細に述べられたが、当業者は、その最も広い形態での発明の精神および範囲から離れることなく、様々な変更、代用及び、置換を実施することができることを理解すべきである。

Claims (17)

1. リンク状態により制御される複数のネットワークノードを有するコンピュータネットワーク内でツリーを設定し、更新する方法であって、トポロジーデータベースが各ネットワークノードで利用可能であり、
   ツリーのルートブリッジのみにより該ツリーを計算する工程と、
   前記ツリーを当該ツリーに参加している全てのネットワークノードに通知する工程と、
   ツリー通知に従って、ツリーに参加しないポートを廃棄することによりツリーを構成する工程と、
   前記ツリー通知を、廃棄されていないポートを介して前記ツリーに沿って転送する工程と
   を備えることを特徴とする方法。
2. 前記ツリーを計算する工程は、リンク状態通知メッセージから得られた近隣情報が入力されたトポロジーデータベースに基づいて実行され、該トポロジーデータベースは、リンク状態プロトコルにより保守されることを特徴とする請求項１に記載の方法。
3. 前記ツリーは、複数のイーサネット・ブリッジを包含するアクティブなトポロジーであることを特徴とする請求項１に記載の方法。
4. 前記ツリーは、他のネットワークノードから遠隔設置された該ツリーのルートブリッジにより構成されることを特徴とする請求項１に記載の方法。
5. 前記ツリーは、該ツリーの一部であるポートを通じて、前記ルートブリッジにより通知されることを特徴とする請求項１に記載の方法。
6. 前記ツリー通知は、全てのブリッジの全てのポート設定を含むメッセージの送信を含むことを特徴とする請求項５に記載の方法。
7. 前記ツリー通知は、前記ツリーの一部であるリンクの全てについての記述を含むメッセージの送信を含むことを特徴とする請求項５に記載の方法。
8. 前記ツリー通知は、前記ツリー内のノードの識別子と、前記ツリー内の各ノードのポート設定とを提供することを特徴とする請求項１に記載の方法。
9. 関連するサブツリーの記述が、前記ツリーのリーフブリッジへ転送されることを特徴とする請求項１に記載の方法。
10. スパニング・ツリー・プロトコルのファミリ（ＳＴＰ、ＲＳＴＰ、ＭＳＴＰ）に対する拡張として実施されることを特徴とする請求項１に記載の方法。
11. 前記ツリーを計算しないブリッジは、一時的なループを回避するために前記ツリー通知において受信されたツリーを構成することを特徴とする請求項１０に記載の方法。
12. 前記ツリーを計算しないブリッジが、閉じられたリンクを構成した後においてのみ、前記ツリー通知において受信されたツリーの一部であるアクティブなリンクを構成することを特徴とする請求項１１に記載の方法。
13. 前記ツリーを計算しないノードは、前記ツリーを構成した後に前記ツリー通知を転送することを特徴とする請求項１０に記載の方法。
14. 前記ツリーは、対応するポート設定により構成されることを特徴とする請求項１に記載の方法。
15. 前記ツリー通知は、特に前記ツリーの一部であるリンク上で転送されることを特徴とする請求項１に記載の方法。
16. 前記ツリーを計算しないノードは、前記ツリーにおける関連サブツリーのみを含む修正されたツリー通知を転送することを特徴とする請求項１に記載の方法。
17. 前記ルートブリッジが、前記トポロジーデータベースが変化した場合に、前記ツリーを再計算する工程と、
    新しい前記ツリーを前記ルートブリッジが通知する工程と、
    前記新しいツリーの通知に基づいて、未計算ブリッジにおいて前記ツリーの構成を更新する工程と
    をさらに備えることを特徴とする請求項１に記載の方法。

Images