JP4681049B2 - ネットワークにおける障害処理のための方法および装置 - Google Patents

Description

本発明は、ツリー構造のネットワークにおける障害処理に関するものである。

情報を交換するためのネットワーク、たとえばイーサネット（登録商標）・ネットワークには、リンクによって相互接続されているノードがある。ネットワーク内で対になっているエンド・ノード間に設定されている接続が、突如として故障することがある。最初に故障している接続を検出し、そしてそれを復旧させる方法が開発されてきている。

“スパニング・ツリー・プロトコル”（ＳＴＰ）は、最初のイーサネット（登録商標）向けの耐障害のための方法であり、主に、ブロードキャスト・メッセージの循環を避けるためのループ回避のために開発された。ＳＴＰはまた、未使用リンクの有効化による経路冗長性を提供する。リンク障害の場合、以前のバックアップ・リンクは、孤立したネットワーク・セグメントに到達するように有効化される。スパニング・ツリーの構築は、ブリッジの中からルート・ブリッジを選ぶことから始まる。残りのブリッジは、ルート・ブリッジへの最短経路を計算する。ルート・ブリッジへの最短経路を与えるポートが、ルート・ポートである。ブリッジは、ブリッジ・プロトコル・データ・ユニット（ＢＰＤＵ）メッセージでスパニング・ツリー情報を交換する。ＳＴＰの主な欠点は、収束が遅いことである。フェイルオーバ時間は、１０秒のオーダで、通常は３０〜６０秒であり、そしてネットワーク装置の数に依存する。ＳＴＰの更なる欠点は、殆んど制御できないことである。すなわち、最初のツリーは設定されうるが、障害後に形成されるツリーは予測不可能である。

“高速スパニング・ツリー・プロトコル”（ＲＳＴＰ）は、イーサネット（登録商標）耐障害性プロトコルの発展における次の段階であった。用語および大部分のパラメータはＳＴＰの場合と同じである。ＳＴＰとの最も重要な差異は、ポートの取りうる動作状態の数が５つの状態が３つの状態まで減っていることである。さらに、ポートでのメッセージ処理が、スパニング・ツリーで果たす役割に依存しない。ＢＰＤＵは同じフォーマットで変わらず、ほんのわずかの変更が導入されており、すなわちフラグのバイトのすべてのビットが使用されている。ＳＴＰの欠点の１つは、非ルートのブリッジが、１つのＢＰＤＵがそれらのルート・ポートに到達するとき、各ＢＰＤＵを生成するだけである。これとは対照的に、ＲＳＴＰでは、どのブリッジも予め定義された時間間隔で、たとえば２秒ごとに、いわゆるハローＢＰＤＵ（hello BPDU）を生成する。さらに、より高速なエージングがプロトコル情報に対して適用されており、すなわち、連続した３回のハロー周期の間にハローが受信されない場合、プロトコル情報は直ちに無効になる。このようにして各ＢＰＤＵは、ブリッジ間でのキープ・アライブ・メカニズムとして使用されており、それが復旧をより速くしている。ＲＳＴＰの収束時間は、秒のオーダに減少しているが、それでもなおキャリアグレードのネットワークには適用できない。

イーサリアル（EtheReal）は、高速スパニング・ツリーの再構成および故障検出を提供することを、狙ったプロトコルである。イーサリアルの障害検出メカニズムは、メッセージの発生元が稼動しているということを示すために、隣接相互間で周期的なハロー・メッセージを用いる。連続するハロー・メッセージが到達し損なうと、そのとき、接続は機能が停止したと想定され、そして新しいスパニング・ツリーの構築が始まる。イーサリアルでは、故障リンクを経由する接続はすべて停止され、そして新しいスパニング・ツリーが再構築されてから、再設定される。イーサリアルの主な欠点は、標準のイーサネット（登録商標）・スイッチがイーサリアルをサポートしておらず、一方、適切な運用のために全てのネットワーク・ノードがイーサリアルにより認識されるものでなければならないことである。さらに、予め計算されたスパニング・ツリーを用いるアーキテクチャほど速くなることはない。

障害検出は、また近年開発された“双方向転送検出”（ＢＦＤ）プロトコルに基づくことができよう。ＢＦＤは、当初隣接間の接続性を調べるために開発され、そして後にプロトコル“マルチホップ経路用ＢＦＤ”に拡張された。しかしながら、ＢＦＤは、まだイーサネット（登録商標）用には開発されてきてはいない。さらに、二地点間ＢＦＤが、起こりうるリンク障害の全てを検出するために、ネットワークの各々のエッジ・ノード間で実行される必要があると思われ、ネットワークにあまりにも過度に負荷を掛ける可能性がある。

仮想ＬＡＮ（ＶＬＡＮ）の使用が広がるにつれて、同じＳＴＰのインスタンスが全てのＶＬＡＮには向いていないので、現行の標準が適切ではなかったということが明らかになっている。したがって、“複数スパニング・ツリー・プロトコル”（ＭＳＴＰ）が、ＩＥＥＥにより開発された。ＭＳＴＰは、ＲＳＴＰおよびＶＬＡＮの最良の特徴を融合している。

ＭＳＴＰにより導入された主な改良は、いくつかのＶＬＡＮが単一のスパニング・ツリー・インスタンスに割り当てられうることである。これらのインスタンスは、二つ以上ある場合、お互いに独立している。スパニング・ツリー・インスタンスの最大数は、イーサネット（登録商標）・スイッチに依存している；１０００個のインスタンスに達することさえある。このように、ＭＳＴＰは、数多くのＶＬＡＮをサポートするのに必要とされるスパニング・ツリーの数を減少させる。さらに、ＭＳＴＰでは、複数の経路を提供することにより負荷分散も可能である。これに加えて、イーサネット（登録商標）・ネットワークを領域に分割することが、また可能であり、スパニング・ツリーの大きさを縮小することにより、大きなネットワークをより扱いやすくする。このように、ＭＳＴＰは元になったものより、よく大きさを調整するが、しかし、収束性は、ＲＳＴＰよりも良くない。

ＭＳＴＰの特性は、ＭＳＴＰに基づく耐障害性アプローチの考えをもたらす。この着想は、バイキング・システムにおいてまた適用され、そこでは、２つの異なるスパニング・ツリーに任意のエンド・ノード対に対して少なくとも２つの交換経路があるように、スパニング・ツリーが構築され、経路は中間のリンクないしノードを共有しない。各々のスパニング・ツリー・インスタンスは、１つの特定のＶＬＡＮに対応し、そのため、１つのＶＬＡＮを明確に選ぶことは、１つのスパニング・ツリーを暗に選択することになる。障害の場合、エンド・ノードは、代替の経路を選ぶためにＶＬＡＮを変更しなければならない。障害検出は、ネットワーク・スイッチにより提供されるサポートに基づいている。ネットワーク内の各々のスイッチは、障害の場合、ＳＮＭＰトラップを中央管理装置（Central Manager）に送信するように設定されている。この方法は、標準のイーサネット（登録商標）・スイッチに依っているけれども、故障管理センタを必要としており、コスト効率は高くなく、そしてフェイルオーバ手順を遅くする。中央管理装置は、中枢のサーバであり、故障処理を含め、ネットワークの全面的な運用に関与する。障害通知の後、中枢のサーバは、いずれのＶＬＡＮが影響を受けているかを見つけ出し、そしてバックアップＶＬＡＮを使用するために、必要な再構成をエンド・ノードに通知する。エンド・ノードの各々は、クライアント・モジュールを実行しなければならず、それは運用中にＶＬＡＮ選択に関与している。クライアントはまた、負荷測定を実行し、結果を周期的に中央管理装置に送信する。このように、構築されたスパニング・ツリーを用いて、トラフィック管理が中央で組織化されている。このシステムにより提供される障害迂回時間は、１秒をわずかに下回る。

ネットワーク障害処理における現今の上述した技術に関連する主要な問題は、現状の方法が、あまりにも遅いことである。これらの方法は秒以上のオーダの障害検出時間を有しており、リアルタイム・アプリケーションには受け入れがたい。

別の問題としては、上述した現状の方法の多くが、ネットワークに重い負荷を引き起こすことであろう。

さらに問題なのは、現状の方法の一部は、たとえばイーサネット（登録商標）・スイッチに準拠した標準ではないことである。

更なる問題は、いくつかの方法は十分にはロバストでなく、たとえば、故障処理が中央で管理されるシステムであることである。

さらに別の問題は、いくつかの故障検出システムが二地点間接続にのみ適用可能であり、スパニング・ツリーの分析には適用できないことである。

手短には、問題は以下の方法で解決される。多数のノードを有するネットワークにおいて、構成された仮想ローカル・エリア・ネットワーク（ＶＬＡＮ）があり、各々のＶＬＡＮは多数のノードの中の予め決められたノードに接続している。同報のアライブ・メッセージは、各ＶＬＡＮが稼動しているかどうかを調べるために一定の間隔で送信される。ノードは、アライブ・メッセージが到達しているかどうかを登録し、そして、予期されたメッセージが紛失している場合、同報の通知がノードの中の他のノードに送信される。この通知の後、これらのノードは、その時点でいずれのＶＬＡＮが使用できないかを知るであろう。

より詳細には、問題は、以下の方法で解決される。多数のＶＬＡＮが使用され、ＶＬＡＮのうちの少なくとも１つが残り、ＶＬＡＮがネットワークでの任意の単一障害の場合に接続性を提供するように、各ＶＬＡＮのトポロジーが構成されている。ネットワーク・ノードのうちの多くがエッジ・ノードであり、そしてエッジ・ノードのうちの一部が各ＶＬＡＮ上に定期的にアライブ・メッセージを同報するように仕向けられている。エッジ・ノードは異なるＶＬＡＮ上でこれらのメッセージを待ち受ける。待ち受けているノードの１つが、ＶＬＡＮのうちの１つでアライブ・メッセージの予期されるメッセージを１つ紛失するような場合、当該ノードは、実際のＶＬＡＮがその時点で使用できないことを、通知メッセージを各ＶＬＡＮ上の他のエッジ・ノードに同報することにより知らせる。

本発明による目的は、ネットワーク内での高速の障害処理を提供することである。

別の目的は、処理がネットワークにごくわずかしかトラフィック負荷を増やさないようになることである。

さらなる目的は、処理が現状の標準に準拠して行われるようにできることである。

なお別の目的は、処理がロバストで、そして運用が簡易になることである。

処理がスパニング・ツリーを有するネットワークに適用できるようになることも、また目的の１つである。

本発明の障害処理による主な長所は速いということである。

別の長所は、本発明の障害処理が簡易であり、ネットワークにごくわずかしかトラフィック負荷を増やさないようになることである。

さらなる長所は、本発明の障害処理が現今の標準および標準的な内部ノードに準拠して行われることができることである。

本発明の障害処理がネットワーク内に分散され、これにより、障害処理がロバストかつ信頼できるようになることに寄与することが、なお長所の１つである。

なお別の長所は、本発明の障害処理がネットワーク内のスパニング・ツリーに適用できることである。

本発明の障害処理が、ごく少数の異なる種別であるごく少数のメッセージを使用することになることも、また長所である。

本発明は、実施形態を活用し、そして以下の図面を参照して、より詳細にこれから説明されるであろう。

図１Ａには、簡単なイーサネット（登録商標）・ネットワークＮＷ１の例が示されており、それに関連して本発明の障害処理が説明されるであろう。ネットワークには、４つの交換ノード（ＳＷ１、ＳＷ２、ＳＷ３およびＳＷ４）が示されており、そしてまた４つのエッジ・ノード（ＥＮ１、ＥＮ２、ＥＮ３およびＥＮ４）が示されている。ノードは、全てリンクにより相互接続されており、図を簡単にするためにそのうちの１つのリンクＬ１のみが示されている。図１Ａに示されているネットワークＮＷ１は、説明のためにただ簡単化されたネットワークの例である。当然、本発明は、いくつもの内部ノードおよびエッジ・ノードを有する広域のネットワークに適用されることができる。ネットワークＮＷ１は、図では示されていないさらなるノードを有し、そしてネットワークのさらなる部分は、一点鎖線の輪郭線およびリンクＣ１により示唆されているだけである。３つのスパニング・ツリーがネットワークＮＷ１の例に定義されており、ノード間の実線で示されている第１のスパニング・ツリーＳＴ１、破線での第２のスパニング・ツリーＳＴ２および点線での第３のスパニング・ツリーＳＴ３である。スパニング・ツリー（ＳＴ１、ＳＴ２およびＳＴ３）の各々に対して、仮想ローカル・エリア・ネットワーク（ＶＬＡＮ１、ＶＬＡＮ２およびＶＬＡＮ３）が、それぞれ割り当てられている。ネットワークＮＷ１は、フレームを転送するタスクを有しており、トラフィック・メッセージＭ１のフレームにより例示されている。

図１Ｂにまた、ネットワークＮＷ１が示されている。図１Ａおよび図１Ｂは、障害が異なる場所にあるという点で異なり、後で詳細に説明されるであろう。

ネットワークＮＷ１、および同様のネットワークでは、トラフィック・メッセージＭ１のフレームがそれらの宛先に到達するのを妨げるような障害が起こることがある。それは、どんなタイプの障害も可能性があり、たとえばスイッチ障害ないし接続障害である。ネットワークの機能にとって、障害が検出され、それにより影響を受けるノードが通知を受け取り、そしてそれらのメッセージの送出を停止できることが不可欠である。また、ノードは、障害が修復されたら、送出を再開するように通知されることになるであろう。

上述のように、いくつかの最先端の方法は、このような障害処理に使用できる。それらは全て異なる欠点を抱えており、たとえばそれらは遅く、重いトラフィック負荷を生み、標準準拠ではない、あるいは十分ロバストではないといったことである。

図１Ａおよび図１Ｂに関連して、上記欠点を克服するような障害処理の実施形態が説明されるであろう。実施形態は、ツリーに基づいた転送を適用するイーサネット（登録商標）・アーキテクチャあるいは他のパケット交換ネットワークに対する分散型障害処理メカニズムであり、そしてそれが予め計算された複数のスパニング・ツリー（ＳＴ１、ＳＴ２およびＳＴ３）を耐障害性に提供する。スパニング・ツリーは全て、ネットワークのノード（ＥＮ１からＥＮ４およびＳＷ１からＳＷ４）の各々に接続しており、それらは図から見られるように含まれるリンクが異なるだけである。アーキテクチャは、市販されている標準のイーサネット（登録商標）・スイッチ（ＳＷ１からＳＷ４）を含む。故障検出および耐障害性を提供するために必要となる追加機能が、イーサネット（登録商標）・ネットワークＮＷ１のエッジ・ノードＥＮ１からＥＮ４までに実装される。本実装形態では、エッジ・ノードはＩＰルータである。複数のスパニング・ツリー（ＳＴ１、ＳＴ２およびＳＴ３）には、回線切り替えを提供するように適用されており、そしてツリーは、ＶＬＡＮないしプロトコルＭＳＴＰを用いて実装されている。スパニング・ツリーは固定的であり、そしてネットワーク要素のいずれかにおける単一障害の場合に、少なくとも１つの完全なスパニング・ツリーが残存するように、ネットワーク内で設定される。仮想ＬＡＮ（ＶＬＡＮ１、ＶＬＡＮ２およびＶＬＡＮ３）のうちの１つが、説明したように、スパニング・ツリーのそれぞれ１つに割り当てられている。それぞれのスパニング・ツリーへのトラフィック転送は、エッジ・ノードＥＮ１からＥＮ４内でＶＬＡＮの各ＩＤを用いて制御されることができる。すなわち、実施形態では、回線切り替えは、ネットワークＮＷ１内のＶＬＡＮ切り替えになる。本明細書では、ＶＬＡＮおよびスパニング・ツリーの間には１対１の対応がある。図１Ａおよび図１Ｂに示されているネットワークＮＷ１の例では、３つのスパニング・ツリー（ＳＴ１、ＳＴ２、ＳＴ３）が、ネットワークで現れる可能性のある任意の単一障害に対処することができるようにするために必要である。

障害の場合、エッジ・ノード（ＥＮ１からＥＮ４）の各々は、フレーム、たとえばトラフィック・メッセージＭ１のフレームを、影響を受けたスパニング・ツリーに転送することを停止する必要がある。したがって、障害検出のため、および特定の障害に影響を受けるＶＬＡＮの識別情報を全てのエッジ・ノードに知らせるために、プロトコルが必要である。障害処理方法は、以下で説明されるであろう。まず、障害処理の実施形態が大まかに説明され、そして詳細な例が、ネットワークＮＷ１に関連して、図１Ａ、図１Ｂ、図２Ａ〜Ｄおよび図３Ａ〜Ｄに与えられるであろう。

ネットワークにおける故障の処理に対して、新しい解決法が提案されている。実施形態では、障害はネットワーク内のスパニング・ツリー、たとえばネットワークＮＷ１内のスパニング・ツリーＳＴ１からＳＴ３までを用いて処理される。ネットワークは、もっと一般的にいえば、トラフィック転送にツリー・トポロジーが用いられるパケット交換ネットワーク、たとえば、イーサネット（登録商標）・ネットワークである。この新しい解決策では、ブロードキャスト・メッセージが、スパニング・ツリーのうちの１つが稼動しているかいないかを調べ、トラフィックおよび処理負荷をできるだけ減らすように利用される。したがって、エッジ・ノードの一部は、各々のＶＬＡＮに定期的にブロードキャスト・メッセージを送るように設定される。全ての他のノードは、これらのメッセージの到達をt登録し、そしていくつかのノードは、全てのＶＬＡＮで必要であれば、使用できない各ＶＬＡＮについての同報通知を直ちに送るように仕向けられている。同報された通知の後で、各々のエッジ・ノードは、いずれのＶＬＡＮが使用できないかが分かるであろう。障害検出の詳細な運用が、以下で説明される。

本発明の実施形態では、３つの種別のメッセージが使用される：
−アライブ（alive）： これらのメッセージは、各々のＶＬＡＮ内で予め定義されたキープ・アライブ周期ＫＡＰに従って周期的に同報される。

−障害（failure）： これらのメッセージは、障害が検出されたときに各々の影響を受けていないＶＬＡＮ内で同報され、そして故障したＶＬＡＮのＩＤを含む。

−修復（repaired）： これらのメッセージは、障害修復の通知のために、少なくとも故障ＶＬＡＮで、そしてできる限り各々のＶＬＡＮで同報される。

エッジ・ノードは、以下の役割のうちの１つを果たす：
−エミッタ（emitter）： アライブ・メッセージを周期的に同報するエッジ・ノード。

−通知（notifier）： 障害を検出すると直ちに障害メッセージを同報し、そしてまた障害修復を検出すると修復メッセージを同報するエッジ・ノード。

別の方法では、エッジ・ノードの一部が上述の高速通知ノードであり、直ちに障害メッセージを同報する。エッジ・ノードの他の部分はまた、通知ノードであるが、しかし多少遅延し、そして障害メッセージを直ちにではなく、それが障害を検出したと同じキープ・アライブ周期ＫＡＰ内で同報する。

−特別な役割を有さない（no special role）：あるキープ・アライブ周期内で障害を検出し、そして、次のキープ・アライブ・周期内で障害メッセージが紛失しているのを検出すると、障害メッセージを同報するエッジ・ノード。エミッタ・ノードでもなく、通知ノードでもない。

ネットワークには少なくとも２つのエミッタ・エッジ・ノードがあり、キープ・アライブ周期に従って各々のＶＬＡＮ内でアライブ・メッセージを周期的に同報する。これらのメッセージは、ＶＬＡＮに順々に短い時間内で、殆んど同時に送出される。このように、アライブ・メッセージは、検出区間と呼ばれる短い（トポロジーに依存する）区間内に、全てのＶＬＡＮ内の各々のエッジ・ノードに到達しなければならない。エッジ・ノードは、メッセージの到達を観測しなければならず、たとえばそれらは、アライブ・メッセージが到達したことを登録するテーブルを維持する。最初のメッセージが到達した時点でタイマーが始動される。１つ以上のアライブ・メッセージの到達が当該検出区間内でテーブルに登録されない場合、対応するＶＬＡＮが故障したと見なされる。ネットワーク内にエミッタ・ノードがあるのと同数のアライブ・メッセージが、ＶＬＡＮの各々の中で予期されることに注目されたい。全てのエッジ・ノードは、アライブ・メッセージの到達を監視する。少数の通知エッジ・ノードがあり、各々のＶＬＡＮにおける障害を検出後に障害メッセージを同報し、当該メッセージは故障した１つないし複数のＶＬＡＮのＩＤを含む。各々のエッジ・ノードは障害メッセージを受信し、それでそれらの全てが障害について通知されるであろう。通知メッセージを同報するノードの数は、障害後にあまりに大きなトラフィック負荷を避けるために限定される。しかしながら、ネットワークは、通知ノードが障害を他のノードに通知できない場合の備えができていなければならない。したがって、エッジ・ノードは、それが通知ノードでもエミッタでもなく、アライブ・メッセージの到達の紛失に基づいて障害を検出し、そして、次の検出区間の終了までに予期される障害通知を受信しない場合、このノードが同じように障害メッセージを同報する。エミッタ・ノードは、障害がその前に検出されていても、全てのＶＬＡＮ内にアライブ・メッセージを常に同報する。障害が修復すると、障害を検出したエッジ・ノードはまた、以前紛失したアライブ・メッセージを再度受信するので、修復を検出するであろう。このように、エッジ・ノードは、修復メッセージを他のノードに同報することにより、他のノードに通知することができ、メッセージは、修復ＶＬＡＮのＩＤを含むので、トラフィックが再びそれに送られることができる。修復メッセージを送出するエッジ・ノードは、通知ノードあるいは障害を検出した他のエッジ・ノードのいずれかの可能性がある。障害後の高トラフィック負荷を避ける別の可能性としては、ネットワークがエミッタおよび上述の高速の通知ノードを有し、しかし他のエッジ・ノードが低速の通知ノードであることである。それらは、特別な役割を有さないノードよりは速いが、しかし高速の通知ノードほど即座ではなく、障害メッセージを同報する。

ネットワークにおける障害処理の今までに大まかに説明された実施形態は、ここからネットワークＮＷ１に対して添付の図面に関連して詳しく説明されるであろう。この例では、ノードＥＮ３がエミッタのうちの１つであり、ノードＥＮ２は、通知ノードのうちの１つで、そしてノードＥＮ１およびＥＮ４は他の特別な役割を有さないの種別である。

図２Ａ〜Ｄは、通知ノードＥＮ２が障害に気付き、そして障害メッセージを送出する場合の状況を示している。この例では、障害は、ノードＥＮ３とＳＷ３間の接続が、スパニング・ツリーＳＴ２に対して故障していることである。障害は、図１Ａでは×印がされており、ＣＤ１で参照されている。

図２Ａ〜Ｄは、時間をＴで参照されている時間図である。図２Ａは、エミッタ・ノードＥＮ３が、スパニング・ツリーＳＴ１、ＳＴ２およびＳＴ３に対して、それぞれのＶＬＡＮ（すなわちＶＬＡＮ１、ＶＬＡＮ２およびＶＬＡＮ３）上にアライブ・メッセージＡ１、Ａ２およびＡ３を送信していることを示している。これらのメッセージはまた、図１Ａでも表示されている。アライブ・メッセージは、非常に短い時間区間ＴＩ内に、殆んど同時に同報され、そしてＫＡＰで参照されているキープ・アライブ周期毎にその初めに周期的に繰り返される。アライブ・メッセージの最上部には、ＶＬＡＮのいずれにメッセージが同報されるかを数字１、２、および３により表示されている。中央部には、メッセージ種別が表示されており、図２ではアライブ・メッセージ、下部には、メッセージがＶＬＡＮのいずれに関するものであるかが表示されている。注目すべきは、時間区間ＴＩが検出区間ＤＩより遥かに短く、そして図２から想定されうるより遥かに短いことである。

図２Ｂは、通知ノードＥＮ２が検出区間ＤＩ内でアライブ・メッセージＡ１、Ａ２、Ａ３を受信していることを示している。ネットワーク内での信号実行時間のために少量の時間ΔＴ１だけ、受信がずれている。検出区間ＤＩの最初の２つでは、アライブ・メッセージの全てが受信されているが、しかし３番目の検出区間では、障害ＣＤ１のために、アライブ・メッセージＡ１およびＡ３のみが受信されている。通知ノードＥＮ２がすぐに、スパニング・ツリーＳＴ２に障害があることを、ＶＬＡＮ（すなわちＶＬＡＮ２）を介して通知する。

図２Ｃは、通知ノードＥＮ２が３番目の検出区間の直後に障害メッセージＦ１およびＦ３を送出することを示している。メッセージの最上部には、メッセージが到達する各ＶＬＡＮに対するアイデンティティ（それぞれ１および３）が表示されている。中央部には、メッセージの種別、すなわち障害が表示されている。下部には、メッセージがＶＬＡＮのいずれに関係するか（この例ではＶＬＡＮ２）が表示されている。図２Ｂから見られるように、障害が直ぐに修復され、そして通知ノードＥＮ２が４番目の検出区間ＤＩ内でアライブ・メッセージＡ１、Ａ２、Ａ３の全てを受信している。通知ノードＥＮ２は、したがって修復メッセージＲ１、Ｒ２およびＲ３をＶＬＡＮ（すなわちＶＬＡＮ１、ＶＬＡＮ２およびＶＬＡＮ３）上に送信する。この例では、ＶＬＡＮ２が再び正常に稼動し、そしてスパニング・ツリーＳＴ２が完全に動作状態にあることを通知するために、障害メッセージの１キープ・アライブ周期後に、修復メッセージが送信されている。別のやり方として、通知ノードＥＮ２が修復したＶＬＡＮ（すなわちＶＬＡＮ２）上に修復メッセージＲ２のみを送信する。これは図では示されていない。この実施形態での長所は、障害処理により引き起こされるトラフィック負荷がより低いことである。

図２Ｄは、他のノードＥＮ１およびＥＮ４が受信するメッセージを示している。最初の２つの検出区間で、両ノードは、アライブ・メッセージＡ１、Ａ２、Ａ３を受信している。受信は、なお少量の時間ΔＴ２だけずれている。３番目の検出区間で、両ノードは、アライブ・メッセージＡ１およびＡ３のみを受信し、そして同じキープ・アライブ周期ＫＡＰ内で、それらは障害メッセージＦ１およびＦ３を受信している。次のキープ・アライブ周期で、ノードＥＮ１およびＥＮ４は、アライブ・メッセージＡ１、Ａ２，Ａ３の全てを、そしてまた修復メッセージＲ１、Ｒ２およびＲ３を受信している。このようにして、他のノードは、障害がスパニング・ツリーＳＴ１、ＳＴ２ないしＳＴ３のうちの１つで起こっているとき、および、障害が修復されスパニング・ツリーの全てが完全に動作状態になっているときに、ＶＬＡＮ（すなわちＶＬＡＮ１、ＶＬＡＮ２およびＶＬＡＮ３）を経由して通知される。

図３Ａ〜Ｄは、障害に気付き、そして障害メッセージを送信するのが、他の特別な役割を有さないノードのうちの１つ（ネットワークＮＷ１におけるノードＥＮ４）である場合の状況を示している。この例では、障害は、スパニング・ツリーＳＴ２に対して、ノードＳＷ１とＳＷ３間の接続が故障しているということである。障害は、図１Ｂでは×印がされており、そしてＣＤ２で参照されている。強調されるのは、それが図１Ａおよび図１Ｂの双方における全く同じネットワークＮＷ１であることである。

図３Ａ〜Ｄは、今までと同じように時間がＴで参照されている時間図である。異なるノードに対する図は、時間がそれぞれ区間ΔＴ３およびΔＴ４だけずれている。図３Ａは、エミッタ・ノードＥＮ３がアライブ・メッセージＡ１、Ａ２およびＡ３を、スパニング・ツリーＳＴ１、ＳＴ２およびＳＴ３に対して、それぞれのＶＬＡＮ（すなわちＶＬＡＮ１、ＶＬＡＮ２、およびＶＬＡＮ３）上に送信することを示している。これらのアライブ・メッセージは、図１Ｂにまた表示されている。メッセージは、図３Ａで説明されているように同報され、そしてまたメッセージの内容がこの図にあるように表示されている。

図３Ｂは、ノードＥＮ４が１番目の検出区間ＤＩでアライブ・メッセージＡ１、Ａ２、Ａ３の全てを受信していることを示している。２番目のキープ・アライブ周期ＫＡＰの第２番目の検出区間で、障害ＣＤ２のために、アライブ・メッセージＡ１およびＡ３のみが受信されている。２番目のキープ・アライブ周期ＫＡＰには、障害メッセージは受信されていない。３番目の検出区間では、メッセージＡ２がなお紛失しており、そしてこの３番目の検出区間の終わりまでには障害メッセージが受信されていない。障害ＣＤ２は、図１Ｂから理解されることができるように、通知ノードＥＮ２がアライブ・メッセージＡ１、Ａ２およびＡ３の全てを受信するのを妨げはしないことに注目してもらいたい。

図３Ｃは、ノードＥＮ４の振舞いを示している。それが２番目の検出区間で、アライブ・メッセージＡ１およびＡ２のみを受信しているとき、図２Ｄに関連して説明されているように障害メッセージＦ１およびＦ３を待っている。図３Ｂで説明されているように、障害メッセージが到達しない。ノードＥＮ４は、したがって、３番目のキープ・アライブ周期ＫＡＰで、ＶＬＡＮ（すなわちＶＬＡＮ１およびＶＬＡＮ３）上に障害メッセージＦ１およびＦ３を同報する。

図３Ｂから見られるように、障害ＣＤ２が、３番目のキープ・アライブ周期ＫＡＰの終わりで修復され、そしてノードＥＮ４が４番目の検出区間でアライブ・メッセージＡ１、Ａ２、Ａ３の全てを受信している。それが５番目の検出区間でまたアライブ・メッセージの全てを受信すると、ノードＥＮ４は、図３Ｃで示されているように５番目のキープ・アライブ周期で修復メッセージＲ１、Ｒ２、Ｒ３を同報する。

図３Ｄは、通知ノードＥＮ２内で何が生じているかを示している。最初の２つの検出区間ＤＩで、それがアライブ・メッセージＡ１、Ａ２、Ａ３の全てを受信している。３番目の検出区間ＤＩでまた、それがアライブ・メッセージの全てを受信し、しかし３番目のキープ・アライブ周期ＫＡＰで、それがまた障害メッセージＦ１およびＦ３を受信している。ノードは、たとえばトラフィック・メッセージＭ１のメッセージ・フレームをＶＬＡＮ（すなわちＶＬＡＮ２）に送信することを停止する。４番目の検出区間で、５番目の検出区間も同じように、ノードＥＮ２はさらに、アライブ・メッセージの全てを受信している。５番目のキープ・アライブ周期で、通知ノードＥＮ２は修復メッセージＲ１、Ｒ２、Ｒ３を受信し、そして再びトラフィック・メッセージＭ１のメッセージ・フレームをＶＬＡＮ（すなわちＶＬＡＮ２）に送信し始めることができる。

ネットワークＮＷ１のエッジ・ノードの残りもまた、障害メッセージＦ１、Ｆ３を受信すると、それらは、障害が報告されたＶＬＡＮ、この例ではＶＬＡＮ２上に、メッセージ・フレーム、たとえばトラフィック・メッセージＭ１を送信することを停止する。修復メッセージが到達すると、ノードは、再び、トラフィック・メッセージＭ１のフレームを送信し始める。しかしながら、当然であるが、エミッタ・ノードは、それらがそれ以前に障害メッセージを受信していても、アライブ・メッセージＡ１、Ａ２、Ａ３をＶＬＡＮの全てに常に同報する。

さらなる実施形態が、図３Ａ〜Ｄに簡単に示されている。この実施形態では、上記の明細書にあるように、ネットワークＮＷ１は、エミッタのうちの１つとしてノードＥＮ３を、そして通知ノードのうちの１つとしてノードＥＮ２を有している。差異は、ノードＥＮ１およびＥＮ４が、今度は、特別な役割を有さないノードである代わりに、上述した低速の通知ノードの役割を有していることである。低速の通知ノードは、高速の通知ノードより、最大でキープ・アライブ周期ＫＡＰと長さが同じほどの、長い検出区間を有している。このように、障害検出は、単一のキープ・アライブ周期内でなされることができる。低速の通知ノードＥＮ４は、図３Ｂで示されているように、最初のキープ・アライブ周期でアライブ・メッセージＡ１、Ａ２およびＡ３の全てを、しかし２番目のキープ・アライブ周期では２つのアライブ・メッセージＡ１およびＡ３のみを受信している。図３Ｃで、低速の通知ノードＥＮ４が２番目のキープ・アライブ周期で障害メッセージＦ１およびＦ３を同報することが、破線で簡単に示されている。障害メッセージは、直ぐには送信されずに、しかし２番目のキープ・アライブ周期の終わりで送信される。これは、図２Ｃの通常の通知ノードＥＮ２に対してよりは遅く、しかし特別な役割を有さないノードに対してよりは速い。修復メッセージは、図には示されていないが、アライブ・メッセージの全てが再び現れるとき、低速の通知ノードから送信される。エッジ・ノードのほんの一部が高速の通知ノードであり、そしてエッジ・ノードの残りが、エミッタを除いて、低速の通知ノードであるネットワークは、障害検出が、全ての障害についてむしろ速くなり、そしてさらに障害検出により引き起こされるトラフィック負荷が容認できる程度に低いという長所を有している。

上述したように、ネットワークのエミッタ・ノードの全ては、ＶＬＡＮの全てに対してアライブ・メッセージを送信する。全てのこれらアライブ・メッセージは、通知ノードおよび他の特別な役割を有さないノードに到達すると予期されている。図２および３で、しかしながら、エミッタ・ノードＥＮ３のみから同報されるアライブ・メッセージおよび障害ＣＤ１およびＣＤ２による異なるメッセージへの影響が示されている。

図２Ａ〜Ｄおよび図３Ａ〜Ｄに関連して、障害ＣＤ１およびＣＤ２が言及されている。障害が接続に関係しており、そして回線自身には関係していないことに、また触れられている。説明された障害検出方法は、当然回線上の障害をまた検出し、しかしそれから修復に要する時間は、図２Ａ〜Ｄおよび図３Ａ〜Ｄで示されているものよりも長いであろう。

エッジ・ノードは、障害検出メッセージの到達を観測し、そして登録しなければならない。この目的のための１つの可能性のある実装は、メッセージの到達に追随するテーブルを維持することである。これらのテーブルは、障害処理メッセージに対する根拠となるものであり、すなわち、これらのテーブルに基づいて新しいメッセージが同報されなければならないかどうかが決められる。

エミッタ・ノードは、なんらのテーブルも維持する必要はない。

通知ノードは、アライブ・メッセージを登録するためのテーブルを維持する。表１は、障害ＣＤ１が起こる場合の通知ノードＥＮ２におけるアライブ・メッセージ・テーブルを示している。

特別な役割を有さないエッジ・ノードは、アライブ・メッセージの到達および障害メッセージの到達もまた登録しなければならない。

表２は、障害ＣＤ１が起こる場合のノードＥＮ４で維持されている障害メッセージ用のテーブルを示している。ノードは、図２Ｄで示されているように、障害メッセージＦ１およびＦ３を受信する。

しかしながら、表２は、障害ＣＤ２が起こる場合はノードＥＮ４内では空白であり、障害は、ＶＬＡＮ（すなわちＶＬＡＮ２）の故障を示す図３Ｃの障害メッセージを同報するように、ノードＥＮ４にトリガーを掛ける。

図７ＡおよびＢ、図８ＡおよびＢ、および、図９ＡおよびＢに、エッジ・ノードの実装に関する例が与えられるであろう。

図７ＡおよびＢは、エミッタ・ノードＥＮ３についてのブロック図を示している。図７Ａで、ノードは、上位レイヤトラフィックにはインタフェース７１および下位レイヤトラフィックにはインタフェース７２を有している。トラフィック・メッセージ・ブロック７３は、インタフェース７１および７２を介してネットワークに接続されている。障害制御ブロック７４は、クロック７５、同報ブロック７６およびメッセージ選択ブロック７７に接続されている。メッセージ選択ブロックは、Ｎ１の場合は、トラフィック・メッセージＭ１をトラフィック・メッセージ・ブロック７３に送り、Ｙ１の場合は、Ｆ１およびＲ１のような障害プロトコル・メッセージを障害制御ブロック７４に送る。エミッタ・エッジ・ノードの主なタスクは、アライブ・メッセージＡ１、Ａ２およびＡ３を周期的に同報ブロック７６から同報することである。これは、クロック７５に基づいて障害制御ブロック７４により、予定が決められる。メッセージ選択ブロック７７がトラフィック・メッセージをブロック７３に送るので、ユーザ・トラフィックは、障害検出プロトコルには影響されない。障害制御ブロック７４は、障害検出プロトコルにおける役割にも係わらず、別の重要なタスクを有している：それは、ＶＬＡＮの切り替えを制御し、すなわち障害および修復の処理を管理する。図７Ｂには、エミッタ・ノードで障害処理部を説明するだけの代替案が示されている。ノードは、トラフィック・メッセージ・ブロック７３がなく、そして上位および下位レイヤのデータユニットに対するインタフェース７１Ｂおよび７２Ｂを有している。残りのブロックは、図７Ａにおけるものと同じである。

図８ＡおよびＢは、通知ノードＥＮ２についてのブロック図を示している。図８Ａは、エミッタ・ノードと同じように、ノードＥＮ２が、上位レイヤトラフィックにはインタフェース８１および下位レイヤトラフィックにはインタフェース８２を有することを示している。トラフィック・メッセージ・ブロック８３は、インタフェース８１および８２を介してネットワークに接続されている。障害制御ブロック８４は、クロック８５、同報ブロック８６およびメッセージ選択ブロック８７に接続されている。メッセージ選択ブロックは、Ｎ２の場合はトラフィック・メッセージＭ１をトラフィック・メッセージ・ブロック８３に送り、Ｙ２の場合はＦ１およびＲ１のような障害プロトコル・メッセージを障害制御ブロック８４に送る。通知ノードＥＮ２はまた、上記の表１を含む登録ブロック８８を有する。通知ノードは、通常のトラフィックを変えることはない。通知ノードは、アライブ・メッセージＡ１、Ａ２およびＡ３を同報せず、しかし上述したように、テーブル１を用いてこれらのメッセージの到達に追随する。しかしながら、通知ノードは、障害が現れたり、または消失したりすると、それぞれ障害メッセージＦ１、Ｆ３あるいは修復メッセージＲ１、Ｒ２、Ｒ３を、同報ブロック８６から同報する。エミッタ・ノードＥＮ３と同様に、通知ノードＥＮ２内の障害制御ブロック８４は、ＶＬＡＮの切り替えを制御する。図８Ｂに、通知ノードで障害処理部を説明するだけの代替案が示されている。ノードは、トラフィック・メッセージ・ブロック８３がなく、そして上位および下位レイヤのデータユニットに対するインタフェース８１Ｂおよび８２Ｂを有している。残りのブロックは、図８Ａにおけるものと同じである。

図９は、特別な役割を有さないノードＥＮ４についてのブロック図を示している。このノードは、通知ノードが、障害処理でそれらの役割を果たさない場合に、措置を講ずる。図９Ａに、通知ノードと同じように、ノードＥＮ４が、上位層トラフィックにはインタフェース９１および下位層トラフィックにはインタフェース９２を有することが示されている。トラフィック・メッセージ・ブロック９３は、インタフェース９１および９２を介してネットワークに接続されている。障害制御ブロック９４は、クロック９５、同報ブロック９６、登録ブロック９８およびメッセージ選択ブロック９７に接続されている。メッセージ選択ブロックは、Ｎ３の場合はトラフィック・メッセージＭ１をトラフィック・メッセージ・ブロック９３に送り、Ｙ３の場合はＦ１およびＲ１のような障害プロトコル・メッセージを障害制御ブロック９４に送る。ノードＥＮ４はまた、２つの上記の表１および表２を含む登録ブロック９８を有する。ノードＥＮ４は、通常のトラフィックを変えることはなく、そしてアライブ・メッセージＡ１、Ａ２およびＡ３を同報しない。それは、上述したように、表１および表２の各テーブルを用いてこれらのメッセージの到達に追随する。しかしながら、通知ノードがそれらの役割を果たさない場合、特別な役割を有さないノードは、障害が現れたり、または消失したりすると、それぞれ障害メッセージＦ１、Ｆ３あるいは修復メッセージＲ１、Ｒ２、Ｒ３を、同報ブロック９６から同報する。エミッタ・ノードＥＮ３と同様に、ノードＥＮ４内の障害制御ブロック９４は、ＶＬＡＮの切り替えを制御する。図９Ｂに、特別な役割を有さないノードで障害処理部を説明するだけの代替案が示されている。ノードは、トラフィック・メッセージ・ブロック９３がなく、そして上位および下位層のデータユニットに対するインタフェース９１Ｂおよび９２Ｂを有している。残りのブロックは、図９Ａにおけるものと同じである。

図４に、図１、２および３に関連して説明されている障害処理方法の最初の部分についてのフロー図が示されている。この方法は、ステップ４１から始まり、そこではエミッタ・ノードが指示され、たとえばパケット・ネットワークＮＷ１のノードＥＮ３である。ステップ４２では、通知ノードが指示される。ステップ４３では、ノード間での各ＶＬＡＮ（すなわちＶＬＡＮ１からＶＬＡＮ３）までが定義され、それは上述したようにスパニング・ツリーおよびプロトコルＭＳＴＰを用いてなされることができる。連続的なキープ・アライブ周期ＫＡＰは、ステップ４４で決められ、そしてステップ４５でキープ・アライブ周期内に検出区間ＤＩが決められる。ステップ４６では、ＶＬＡＮのいずれかが障害であると報告されるかどうかに係わらず、アライブ・メッセージＡ１、Ａ２、Ａ３がエミッタ・ノードから各ＶＬＡＮ上に繰り返し同報される。

図５に、障害処理方法の２番目で主要部が示されている。ステップ４６で、アライブ・メッセージが、説明されているように繰り返し同報される。ステップ５０１で、エッジ・ノードは、アライブ・メッセージＡ１、Ａ２、Ａ３の到達を調べる。次のステップ５０２で、ノードは、検出区間ＤＩの１区間内にアライブ・メッセージの全てが到達するかどうかを調べる。到達していれば、Ｙ１の場合であり、ノードは、次の一連のアライブ・メッセージを調べる。アライブ・メッセージのいずれかが到達し損なっていると、Ｎ１の場合であり、２通りの事態が起こりうる。

第１の場合、アライブ・メッセージＡ２の紛失に気付くのが通知ノードであれば、それはステップ５０３で障害メッセージＦ１およびＦ３を同報する。ステップ５０４で、通知ノードは、アライブ・メッセージの到達をチェックし、そしてステップ５０５で、通知ノードは検出区間ＤＩの１区間内にアライブ・メッセージの全てが到達しているかどうかをチェックする。もしそうでないなら、Ｎ２の場合であり、通知ノードは、ステップ５０４でのアライブ・メッセージ到達のチェックを続ける。ステップ５０５で、通知ノードは、検出区間ＤＩの１区間内にアライブ・メッセージの全てが到達しているかどうかをチェックする。もしそうでないなら、Ｎ２の場合であり、ノードは、ステップ５０４でのアライブ・メッセージをもう一度チェックする。アライブ・メッセージの全てが到達していると、Ｙ２の場合であり、通知ノードは、ステップ５０６で、修復メッセージＲ１、Ｒ２およびＲ３を同報する。通知ノードは、それからステップ５０１に戻り、そしてアライブ・メッセージＡ１、Ａ２、Ａ３の到達をチェックする。

第２の場合、それがエミッタでも通知ノードでもないノードであると、それは、ステップ５０７で、障害メッセージＦ１、Ｆ３の到達をチェックする。このチェックは、アライブ・メッセージの紛失に気付かれたキープ・アライブ周期に続くキープ・アライブ周期に実行される。ステップ５０８で、Ｙ３の場合、障害メッセージが到達しており、ステップ５０１に戻り、そしてアライブ・メッセージＡ１、Ａ２、Ａ３の到達を調べる。ステップ５０８で、Ｎ３の場合、障害メッセージが到達していなくて、そしてエッジ・ノードが、ステップ５０９で障害メッセージＦ１、Ｆ３を同報する。ステップ５１０で、ノードはアライブ・メッセージの到達を調べ、そしてステップ５１１で、ノードが、アライブ・メッセージの全てが検出区間ＤＩの１区間内に到達したかどうかを調べる。もしそうでないなら、Ｎ４の場合であり、ノードはアライブ・メッセージの到達を調べるステップ５１０に戻る。アライブ・メッセージの全てが到達していると、Ｙ４の場合であり、ノードは、ステップ５１２で修復メッセージＲ１、Ｒ２およびＲ３を同報する。ノードは、それからステップ５０１に戻り、アライブ・メッセージの到達を調べる。

図６に、障害処理方法の第３の部分についてのフロー図が示されている。ノードは、ステップ６１で障害メッセージを受信し、ステップはステップ５０３かステップ５０９のいずれかの後で起こる。ステップ６２で、ノードは、障害中のＶＬＡＮ（すなわちＶＬＡＮ２）上に、メッセージＭ１で例示されているトラフィック・メッセージを送信することを停止する。各ＶＬＡＮ上のノードは、ステップ５０６かステップ５１２のいずれかの後のステップ６３で修復メッセージを受信し、そしてステップ６４で再びトラフィック・メッセージを送信し始める。

本発明の実施形態の上述の説明は、多くのステップを含んでいるが、それらの全てが必要とは限らない。本発明の広範な実施形態は、以下のステップを含む。ステップ４１でエミッタ・ノードを指示するステップ、ステップ４３でスパニング・ツリー・プロトコルを用いずにＶＬＡＮを定義するステップ、ステップ４５で検出時間区間を決めるステップ、ステップ４６でアライブ・メッセージを同報するステップ、ステップ５０１でアライブ・メッセージをリッスンするステップ、ステップ５０２でノードにおけるアライブ・メッセージの紛失を指摘するステップ、ステップ５０３ないしステップ５０９で指摘したノードから障害メッセージを同報するステップ。

当該手順にまた他のステップを含むには理由がある。ノードの一部を通知ノードとして指示するステップは、必ずしも必要ではないが、障害処理を簡単で高速にする。また、決められたキープ・アライブ周期は処理を高速にする。通知ノードが使用される場合、通知ノードが障害を見逃すような状況において、また他のノードが障害メッセージを同報することができれば、障害処理はよりロバストになるであろう。障害メッセージを同報し終わると、障害処理は、方法のステップ５０４から５０６まで、あるいはステップ５１０から５１２までで首尾よく完了することができ、その結果、トラフィック・メッセージＭ１は、初めに停止され、それから、障害が修復するとステップ６２から６４で再び送信される。

図１Ａおよび図１Ｂに、４つの交換ノードおよび４つのエッジ・ノードを有するネットワークＮＷ１が示されており、そしてより大きなネットワークが示唆されている。実際の場合、ネットワークは、大抵非常に大きく、何百ものノードおよびそれ以上を有する。これらのノードの全部が、ＶＬＡＮに含まれなければならないわけではないということも注意すべきである。ノードの一部は、あまり重要ではない場合があり、残りのノードに対する障害処理を簡略化するために除外されることができる。図１Ａから図３Ｄまでの実施形態では、スパニング・ツリーＳＴ１、ＳＴ２およびＳＴ３が設定され、ＶＬＡＮが、スパニング・ツリーに割り当てられた。スパニング・ツリー・プロトコルＭＳＴＰは、周知の方法を提供するが、しかし、ＶＬＡＮを設定するには必要ではない。たとえば比較的小規模のネットワークに対しては、各ＶＬＡＮは、いかなる単一障害に対しても、各ＶＬＡＮのうちの少なくとも１つは損なわれるようなことはないことに留意し、ネットワーク内の関心のあるノードの全てを接続するように、個別的に設定されることができる。上記のネットワークは、ツリー構造をしており、この方法は、任意の同様のネットワークに対して、ツリー構造に何ら制約を加えるようなことはない。

一連の障害処理メッセージを有するネットワークの概観を示す図である。 別の一連の障害処理メッセージを有するネットワークを示している図である。 ネットワークにおける障害処理に関する時間図である。 ネットワークにおける障害処理に関する時間図である。 ネットワークにおける障害処理に関する時間図である。 ネットワークにおける障害処理に関する時間図である。 ネットワークにおける別の障害処理の時間図である。 ネットワークにおける別の障害処理の時間図である。 ネットワークにおける別の障害処理の時間図である。 ネットワークにおける別の障害処理の時間図である。 ネットワークにおける障害処理のフロー図である。 ネットワークにおける障害処理のフロー図である。 ネットワークにおける障害処理のフロー図である。 ネットワークにおけるエミッタ・ノードについてのブロック図である。 ネットワークにおけるエミッタ・ノードについてのブロック図である。 ネットワークにおける通知ノードについてのブロック図である。 ネットワークにおける通知ノードについてのブロック図である。 ネットワークにおける特別な役割を有さないノードについてのブロック図である。 ネットワークにおける特別な役割を有さないノードについてのブロック図である。

Claims (11)

1. 相互接続回線（Ｌ１）を有する複数のエッジノード（ＥＮ１．．ＥＮ４）およびスイッチノード（ＳＷ１．．ＳＷ４）を含むツリー構造のパケットネットワーク（ＮＷ１）における障害処理の方法であって、該方法は、
   前記ネットワークにおいて、ノードの所定のセットの各々を接続する少なくとも２つの異なるＶＬＡＮ（ＶＬＡＮ１．．ＶＬＡＮ３）を定義するステップ（４３）と、
   各々が検出時間間隔（ＤＩ）を１つ含む連続的なキープアライブ時間区間（ＫＡＰ）を定義するステップ（４４）と、
   エミッタノードとなる前記複数のエッジノードの第１部分を定義するステップ（４１）と、
   前記エミッタノードから、前記連続的なキープアライブ時間区間（ＫＡＰ）の各々の始まりの制限された時間間隔（ＴＩ）内で前記異なるＶＬＡＮ上にアライブメッセージ（Ａ１，Ａ２，Ａ３）を同報するステップ（４６）であって、該アライブメッセージの各々はＶＬＡＮの各々に対応している、ステップと、
   前記エミッタノードではないエッジノードで、前記アライブメッセージ（Ａ１．．Ａ３）を聴取するステップ（５０１）と、
   通知ノード（ＥＮ２）となる前記複数のエッジノードの第２部分を定義するステップ（４２）と、
   前記アライブメッセージの少なくとも１つ（Ａ２）が少なくとも１つのキープアライブ時間区間（ＫＡＰ）の検出時間間隔（ＤＩ）内で到達しなかったことを前記通知ノードの１つが検出した場合、該通知ノード（ＥＮ２，ＥＮ４）が、ＶＬＡＮ上に、少なくとも１つの未到着のアライブメッセージ（Ａ２）に対応する障害ＶＬＡＮ（ＶＬＡＮ２）のための障害メッセージ（Ｆ１，Ｆ３）を同報するステップ（５０３）と、
   連続する２つのキープアライブ時間区間（ＫＡＰ）の双方の検出時間間隔（ＤＩ）内で前記アライブメッセージが到達せず、かつ、前記連続する２つのキープアライブ時間区間（ＫＡＰ）の２番目のキープアライブ時間区間（ＫＡＰ）の検出時間間隔（ＤＩ）内で前記障害メッセージ（Ｆ１，Ｆ３）が到達しなかったことを、前記エミッタノードにも前記通知ノードにも属していない他のエッジノード（ＥＮ４）の１つが検出した場合、該他のエッジノード（ＥＮ４）が、前記２番目のキープアライブ時間区間（ＫＡＰ）内で前記障害メッセージ（Ｆ１，Ｆ３）を同報するステップ（５０９）と、
   を備えることを特徴とする障害処理の方法。
2. 前記通知ノード（ＥＮ２）は、前記アライブメッセージが到達しなかったことが検出されたキープアライブ時間区間内で即座に前記障害メッセージ（Ｆ１，Ｆ３）を同報する高速通知ノードである
   ことを特徴とする請求項１に記載の障害処理の方法。
3. 前記エミッタノードにも前記高速通知ノードにも属していない前記エッジノード（ＥＮ１，ＥＮ４）は、前記アライブメッセージが到達しなかったことが検出されたキープアライブ時間区間の終わりで、前記障害メッセージ（Ｆ１，Ｆ３）を同報する低速通知ノードである
   ことを特徴とする請求項２に記載の障害処理の方法。
4. エッジノード（ＥＮ１．．ＥＮ４）が、少なくとも１つの障害メッセージ（Ｆ１，Ｆ３）を受信するステップ（６１）と、
   エッジノードが、前記障害ＶＬＡＮ（ＶＬＡＮ２）上へのトラフィックメッセージ（Ｍ１）の送信を停止するステップ（６２）と、
   を備えることを特徴とする請求項１乃至３の何れか一項に記載の障害処理の方法。
5. 障害メッセージ（Ｆ１，Ｆ３）を同報したエッジノードが、障害ＶＬＡＮ（ＶＬＡＮ２）上にアライブメッセージ（Ａ２）が再び出現するのを待ち受けるステップ（５０４，５０５，Ｙ２；５１０，５１１，Ｙ４）と、
   前記障害メッセージを同報したエッジノード（ＥＮ２，ＥＮ４）から、前記ＶＬＡＮが修復されたことを指示する修復メッセージ（Ｒ１，Ｒ２，Ｒ３）を少なくとも障害ＶＬＡＮ（ＶＬＡＮ２）に同報するステップ（５０６；５１２）と、
   を備えることを特徴とする請求項１乃至３の何れか一項に記載の障害処理の方法。
6. エッジノード（ＥＮ１．．ＥＮ４）が、少なくとも障害ＶＬＡＮ（ＶＬＡＮ２）上で前記ＶＬＡＮ（ＶＬＡＮ２）が修復されたことを指示する修復メッセージ（Ｒ１，Ｒ２，Ｒ３）を待ち受けるステップ（６３）と、
   修復された前記ＶＬＡＮ（ＶＬＡＮ２）上にトラフィックメッセージ（Ｍ１）を送信するステップ（６４）と、
   を備えることを特徴とする請求項４に記載の障害処理の方法。
7. ツリー構造のパケットネットワーク（ＮＷ１）内の障害処理のためのシステムであって、該ネットワークは相互接続回線（Ｌ１）を有する複数のエッジノード（ＥＮ１．．ＥＮ４）およびスイッチノード（ＳＷ１．．ＳＷ４）を含み、該ネットワークはノードの所定のセットの各々を接続する少なくとも２つの異なるＶＬＡＮ（ＶＬＡＮ１．．ＶＬＡＮ３）を有し、前記複数のエッジノード（ＥＮ１．．ＥＮ４）には、各々が検出時間間隔（ＤＩ）を１つ含む連続的なキープアライブ時間区間（ＫＡＰ）が設定されており、該システムにおいて、
   前記複数のエッジノードの第１部分は、前記連続的なキープアライブ時間区間（ＫＡＰ）の各々の始まりの制限された時間間隔（ＴＩ）内で前記異なるＶＬＡＮ上にアライブメッセージ（Ａ１，Ａ２，Ａ３）を同報する（４６）同報ブロック（７６）を有するエミッタノードであり、
   前記複数のエッジノードの第２部分は、前記アライブメッセージの少なくとも１つ（Ａ２）が少なくとも１つのキープアライブ時間区間（ＫＡＰ）の検出時間間隔（ＤＩ）内で到達しなかったことを検出した場合、ＶＬＡＮ上に、少なくとも１つの未到着のアライブメッセージ（Ａ２）に対応する障害ＶＬＡＮ（ＶＬＡＮ２）のための障害メッセージ（Ｆ１，Ｆ３）を同報する同報ブロック（８６）を有する通知ノードであり、
   前記エミッタノードにも前記通知ノードにも属していない少なくとも１つの他のエッジノード（ＥＮ４）は、連続する２つのキープアライブ時間区間（ＫＡＰ）の双方の検出時間間隔（ＤＩ）内で前記アライブメッセージが到達せず、かつ、前記連続する２つのキープアライブ時間区間（ＫＡＰ）の２番目のキープアライブ時間区間（ＫＡＰ）の検出時間間隔（ＤＩ）内で前記障害メッセージ（Ｆ１，Ｆ３）が到達しなかったことを検出した場合、前記２番目のキープアライブ時間区間（ＫＡＰ）内で前記障害メッセージ（Ｆ１，Ｆ３）を同報する同報ブロック（９６）を有する
   ことを特徴とする障害処理のためのシステム。
8. 前記エミッタノードではないエッジノードは、前記アライブメッセージがキープアライブ時間区間（ＫＡＰ）の検出時間間隔（ＤＩ）内で到達したか否かを記録する第１テーブル（表１）を保持する登録ブロック（８８，９８）を有し、
   前記エミッタノードにも前記通知ノードにも属していない前記少なくとも１つの他のエッジノード（ＥＮ４）の前記登録ブロックは、前記障害メッセージがキープアライブ時間区間（ＫＡＰ）の検出時間間隔（ＤＩ）内で到達したか否かを記録する第２テーブル（表２）を更に保持するよう構成されている
   ことを特徴とする請求項７に記載の障害処理のためのシステム。
9. 前記エミッタノードではないエッジノード（ＥＮ１．．ＥＮ４）は、少なくとも１つの障害メッセージ（Ｆ１，Ｆ３）を受信した場合に、障害ＶＬＡＮ（ＶＬＡＮ２）へのトラフィックメッセージ（Ｍ１）の送信を停止するよう構成された制御ブロック（８４，９４）を有する、
   ことを特徴とする請求項７又は８に記載の障害処理のためのシステム。
10. 障害メッセージ（Ｆ１，Ｆ３）を同報したエッジノード（ＥＮ１．．ＥＮ４）は、障害ＶＬＡＮ（ＶＬＡＮ２）上にアライブメッセージ（Ａ２）を再び検出した場合に、前記ＶＬＡＮが修復されたことを指示する修復メッセージ（Ｒ１，Ｒ２，Ｒ３）を少なくとも障害ＶＬＡＮ（ＶＬＡＮ２）に同報するよう構成されている、
    ことを特徴とする請求項７又は８に記載の障害処理のためのシステム。
11. エッジノード（ＥＮ１．．ＥＮ４）は、前記ＶＬＡＮが修復されたことを指示する修復メッセージ（Ｒ１，Ｒ２，Ｒ３）を少なくとも障害ＶＬＡＮ（ＶＬＡＮ２）で待ち受けるよう構成されており、
    エッジノード（ＥＮ１．．ＥＮ４）は、修復メッセージ（Ｒ１，Ｒ２，Ｒ３）を受信した場合に、修復された前記ＶＬＡＮ（ＶＬＡＮ２）上にトラフィックメッセージ（Ｍ１）を送信する（６３）よう構成されている、
    ことを特徴とする請求項９に記載の障害処理のためのシステム。

Images