JP5167173B2 - ノードおよびネットワーク制御方法 - Google Patents

Description

本発明は、イーサネット（登録商標）通信技術に関し、特に複数のサブリングを用いたリング型イーサネット通信技術に関する。

ビル設備やプラント設備を監視制御する監視制御システムでは、情報収集機能や制御機能などの各種機能を有する通信機器をノードとして通信ネットワークを介して接続し、これらノードからの情報に基づき中央監視装置で個々の設備を監視制御するものとなっている。このような監視制御システムでは、通信ネットワークとしてイーサネットが用いられている。

イーサネットでは、複数のノードを接続する際、ハブやスイッチに各ノードをそれぞれ接続するスター配線方式が基本である。このようなスター配線方式は、比較的規模の小さいオフィス環境には適合するものの、ビル設備やプラント設備などの大規模な設備には必ずしも適合しない。その理由としては、スター配線方式では、ハブやスイッチと各ノードとをそれぞれ個別の配線を介して接続する必要があり、広範囲にわたってノードが設置されている場合には、ノード間を結ぶ配線が複雑化し、配線工事やメンテナンスの作業負担が増大するからである。

このようなイーサネットにおいて、各ノードをリング状に接続するリング型イーサネットが提案されている（例えば、特許文献１など参照）。このリング型イーサネットは、通信経路内に存在するリングトポロジーによる通信エラーを回避するＳＴＰ(Spanning Tree Protocol/IEEE 802.1D)機能や、これを改良したＲＳＴＰ（Rapid Spanning Tree Protocol/IEEE 802.1w）機能などのネットワーク制御機能を用いて、システムの冗長化を実現することが可能となる。

図１０Ａは、典型的なリング型イーサネットシステムの構成例である。ここでは、５つのノードＮ１〜Ｎ５がリングにリング接続されている。通常、ノードに搭載されているＲＳＴＰ機能では、リング接続されているノードのうちから１つのルートノード、例えばＭＡＣアドレスの最も小さいノードを選択する。図１０Ａの例では、ノードＮ１がルートノードとして選択されている。
この後、ルートノードと他のノードとの間でＢＰＤＵ（Bridge Protocol Data Unit）と呼ばれるネットワーク制御情報をやり取りすることにより、例えばノード間のコストやノードの優先順位に基づいてツリートポロジーの現用系通信経路を設定する。

具体的には、ルートノードを基準として、ルートノードからコストの最も高いノード間を結ぶセグメントを現用系通信経路以外の不要経路として選択し、この不要経路に接続された一方のノードのポートをブロッキングすることにより、障害時のバックアップ系通信経路として設定する。
この際、コストとしては、ルートノードから任意のノードまでの間に位置するノード台数に比例するパラメータが用いられ、その最大コストとなるノード間でブロッキングされる。

図１０Ａの例では、ノードが１つ増えるごとにコストが１００ずつ増加しているため、ルートノードＮ１から左回りでノードＮ４までの最大コスト２００となり、ノードＮ３とノードＮ４の間を結ぶセグメントが不要経路と判断される。そして、この不要経路の端点に接続されているノードＮ３，Ｎ４のいずれか一方、例えばＭＡＣアドレスの大きい方のノードＮ４のポートでブロッキングされる。
このため、リングトポロジーからなる元のリングが、ルートノードＮ１からノードＮ３およびノードＮ４までの２つの枝経路からなるツリートポロジーに変更される。これにより、物理的にリングトポロジーを形成しているネットワークであっても、データループの発生が回避される。

一方、いずれかのノードで、ルートノードから定期的に送信されるＢＰＤＵが受信できなくなった場合、ルートノードに近い隣接ノードと当該ノードとの間のセグメントで障害が発生したと判断できる。このような場合、当該ノードからルートノードとは逆方向へ再構築要求が送信される。この再構築要求の受信に応じて、ブロッキングしているノードは、当該ブロッキングを解除する。これにより、ブロッキングされていたバックアップ系通信経路が利用されて、新たな通信経路が再構築される。

図１０Ｂは、従来技術によるリング型イーサネットシステム（障害発生時）の構成例である。通信経路を再構築する際、前述と同様にしてコストが再計算されて、ブロッキング位置が決定される。例えば、図１０Ｂに示すように、ルートノードＮ１とノードＮ２の間のセグメントで障害が発生した場合、ノードＮ４でのブロッキングが解除され、ルートノードＮ１から右回りでノードＮ２まで接続する新たな経路が再構築される。したがって、ノードＮ２，Ｎ３の間のコストは３００に変更される。

また、図１０Ｃは、従来技術によるリング型イーサネットシステム（障害解消時）の構成例である。図１０Ｃに示すように、ルートノードＮ１とノードＮ２の間のセグメントで発生した障害が解消された場合、再び通信経路の再構築が行われ、ノードＮ２，Ｎ３の間のコストは１００となる。このため、ノードＮ３，Ｎ４のコストが最も大きくなり、図１０Ａと同様にして、ノードＮ３，Ｎ４でブロッキングされることになる。

特開２００５−１０９８４６号公報

しかしながら、このような従来技術では、リング型イーサネットシステムにおいて、障害発生時および障害解消時、ブロッキングが解除あるいは設定されて、ツリートポロジーが変更される。したがって、ＲＳＴＰ機能に基づき通信経路のコスト再計算が必要となって、ノード間のセグメントが一時的に切断されるため、ノード間の通信が強制切断されて通信ロスが発生するという問題点があった。さらに、リング状のノード数が増えるに連れてコスト再計算の対象となるセグメントも増加するため、通信ロスの影響が大きくなるという問題点があった。
また、イーサネット運用上から見ると、障害発生経路での通信ロスは避けられないが、それ以外のセグメントにも通信ロスが発生すること、および、障害解消時にも、再び通信ロスが発生することは、大きな問題であり、リング型イーサネットにおいて十分な信頼性を得ることはできない。

本発明はこのような課題を解決するためのものであり、障害発生時、さらには障害解消時に発生する通信ロスを最小限に抑制できるリング型イーサネット制御技術を提供することを目的としている。

このような目的を達成するために、本発明にかかるノードは、リング状の通信経路を介して複数のノードとを接続することによりこれらノード間のデータ通信を実現するとともに、ＲＳＴＰに基づいて、任意のノードで通信をブロッキングしてルートノードから２つの枝経路で通信を行い、通信の障害発生時には、障害検出ノードに当該ブロッキングを変更して構築したバックアップ系通信経路を用いて通信することで、リングに対する冗長化制御処理を行うリング型イーサネットシステムで用いられるノードであって、自ノードに隣接する一方の隣接ノードとの間のセグメントでの障害発生に応じて、自ノードに対応するルートノードを識別するための新たなルートＩＤとして自ノードＩＤを設定するとともに、当該隣接ノードのルートＩＤを新たなルートＩＤへ変更指示するルートＩＤ変更通知を、自ノードに隣接する他方の隣接ノードへ送信する障害発生処理部と、自ノードに隣接する一方の隣接ノードからのルートＩＤ変更通知の受信に応じて、自ノードに隣接する隣接ノードとの間のセグメントで行っている自ノードでのブロッキングがある場合には、当該ブロッキングを解除する処理と、ルートノードからのＢＰＤＵを正常受信していない場合には、当該ルートＩＤ変更通知で指示された新たなルートＩＤへ自ノードのルートＩＤを変更するとともに、自ノードに隣接する他方の隣接ノードへ当該ルートＩＤ変更通知を転送し、ルートノードからのＢＰＤＵを正常受信している場合には、変更前のルートＩＤへの復旧を指示するルートＩＤ復旧通知を当該一方の隣接ノードへ返送する処理とを実行するルートＩＤ変更処理部と、ルートＩＤ復旧通知に応じて、自ノードのルートＩＤを変更前のルートＩＤへ復旧する処理と、自ノードが障害検出ノードでない場合には、当該ルートＩＤ復旧通知を受信した隣接ノードとは反対側の隣接ノードへ当該ルートＩＤ復旧通知を転送し、自ノードが障害検出ノードである場合には、障害セグメントをブロッキングするルートＩＤ復旧処理部とを備えている。

この際、自ノードに隣接する一方の隣接ノードとの間の障害セグメントで発生した障害の解消に応じて、当該一方の隣接ノードとの間で相互に自ノードのＭＡＣアドレスをやり取りし、これらＭＡＣアドレスの大小関係に応じたいずれか一方のノードで、当該障害セグメントのブロッキングを行う障害解消部をさらに備えてもよい。

また、本発明にかかるネットワーク制御方法は、リング状の通信経路を介して複数のノードとを接続することによりこれらノード間のデータ通信を実現するとともに、ＲＳＴＰに基づいて、任意のノードで通信をブロッキングしてルートノードから２つの枝経路で通信を行い、通信の障害発生時には、障害検出ノードに当該ブロッキングを変更して構築したバックアップ系通信経路を用いて通信することで、リングに対する冗長化制御処理を行うリング型イーサネットシステムで用いられるネットワーク制御方法であって、ノードのうち自ノードに隣接する一方の隣接ノードとの間のセグメントでの障害発生を検出した障害検出ノードが、自ノードに対応するルートノードを識別するための新たなルートＩＤとして自ノードＩＤを設定するとともに、当該隣接ノードのルートＩＤを新たなルートＩＤへ変更指示するルートＩＤ変更通知を、自ノードに隣接する他方の隣接ノードへ送信する障害発生処理ステップと、ノードのうち自ノードに隣接する隣接ノードとの間のセグメントでブロッキングを行っているブロッキングノードが、ルートＩＤ変更通知の受信に応じて、当該ブロッキングを解除するとともに、変更前のルートＩＤへの復旧を指示するルートＩＤ復旧通知を当該一方の隣接ノードへ返送するルートＩＤ変更処理ステップと、障害検出ノードが、ルートＩＤ復旧通知の受信に応じて、自ノードのルートＩＤを変更前のルートＩＤへ復旧するとともに、障害セグメントをブロッキングするルートＩＤ復旧処理ステップとを備えている。

この際、障害検出ノードが、障害の解消に応じて、当該障害セグメントを介して接続されている隣接ノードとの間で相互に自ノードのＭＡＣアドレスをやり取りし、これらＭＡＣアドレスの大小関係に応じたいずれか一方のノードで、当該障害セグメントのブロッキングを行う障害解消ステップをさらに備えてもよい。

本発明によれば、障害発生時、さらには障害解消時、ＲＳＴＰ再構築によるコスト再計算が行われなくなるため、障害解消時における通信ロスの発生が回避される。

本実施の形態にかかるノードの要部構成を示すブロック図である。 本実施の形態にかかるリング型イーサネットシステムの構成例である。 障害発生処理を示すフローチャートである。 ルートＩＤ変更処理を示すフローチャートである。 ルートＩＤ復旧処理を示すフローチャートである。 障害解消処理を示すフローチャートである。 障害発生処理を示す説明図である。 ルートＩＤ変更処理を示す説明図である。 ルートＩＤ復旧処理（ルートＩＤ復旧）を示す説明図である。 ルートＩＤ復旧処理（ブロッキング）を示す説明図である。 障害解消処理（ハンドシェーク）を示す説明図である。 障害解消処理（ブロッキング）を示す説明図である。 セグメント接続処理（ＭＡＣアドレス交換）を示す説明図である。 セグメント接続処理（セグメント接続）を示す説明図である。 典型的なリング型イーサネットシステムの構成例である。 従来技術によるリング型イーサネットシステム（障害発生時）の構成例である。 従来技術によるリング型イーサネットシステム（障害解消時）の構成例である。

次に、本発明の一実施の形態について図面を参照して説明する。
［本実施の形態の構成］
まず、図１を参照して、本実施の形態にかかるノードについて説明する。図１は、本実施の形態にかかるノードの要部構成を示すブロック図である。

このノードＮは、ＲＳＴＰ（Rapid Spanning Tree Protocol）に基づいてリングに対する冗長化制御処理を行うリング型イーサネットシステムで用いられるデータ通信用のノードであり、主な機能部として、リング接続制御部１０とアプリケーション処理部２０とが設けられている。
リング接続制御部１０は、リング状の通信経路であるリングを介して他のノードとの間のデータ通信（イーサネット準拠）を制御する機能を有している。
アプリケーション処理部２０は、リング接続制御部１０を介して他のノードとのイーサネット通信により、例えばビル設備やプラント設備を監視制御するための各種アプリケーション処理を行う機能を有している。

リング接続制御部１０には、主な処理部として、ＭＡＣ処理部１１，１２、ＲＳＴＰ処理部１３、および転送処理部１４が設けられている。
ＭＡＣ処理部１１は、リング接続用のポートＰ１を介してリングの一端Ｌ１と接続し、各ノードＮとの間でＭＡＣフレームを送受信する機能と、リングに関する冗長化制御処理用の制御情報を含むＭＡＣフレームをリングから受信した場合、当該ＭＡＣフレームに対して転送処理部１４への出力を規制する機能と、冗長化制御処理用の制御情報を含むＭＡＣフレームをＲＳＴＰ処理部１３へ出力する機能とを有している。

ＭＡＣ処理部１２は、リング接続用のポートＰ２を介してリングの他端Ｌ２と接続し、各ノードＮとの間でＭＡＣフレームを送受信する機能と、リングに関する冗長化制御処理用の制御情報を含むＭＡＣフレームをリングから受信した場合、当該ＭＡＣフレームに対して転送処理部１４への出力を規制する機能と、冗長化制御処理用の制御情報を含むＭＡＣフレームをＲＳＴＰ処理部１３へ出力する機能とを有している。

ＲＳＴＰ処理部１３は、ＭＡＣ処理部１１，１２とそれぞれ接続し、ＲＳＴＰに基づいてリングに対する冗長化制御処理を行う機能を有している。
ＲＳＴＰ処理部１３には、主な処理部として、障害発生処理部１３Ａ、ルートＩＤ変更処理部１３Ｂ、ルートＩＤ復旧処理部１３Ｃ、および障害解消処理部１３Ｄが設けられている。

障害発生処理部１３Ａは、自ノードに隣接する一方の隣接ノードとの間を接続するセグメント（通信経路）での障害発生に応じて、自ノードに対応するルートノードを識別するための新たなルートＩＤとして自ノードＩＤを設定する処理と、当該隣接ノードのルートＩＤを新たなルートＩＤへ変更指示するルートＩＤ変更通知を、自ノードに隣接する他方の隣接ノードへ送信する処理とを実行する機能とを有している。

ルートＩＤ変更処理部１３Ｂは、自ノードに隣接する一方の隣接ノードからのルートＩＤ変更通知の受信に応じて、自ノードに隣接する隣接ノードとの間のセグメントで行っている自ノードでのブロッキングを解除する処理と、ルートノードから定期的に送信されるＢＰＤＵ（Bridge Protocol Data Unit）を正常受信していない場合には、当該ルートＩＤ変更通知で指示された新たなルートＩＤへ自ノードのルートＩＤを変更するとともに、自ノードに隣接する他方の隣接ノードへ当該ルートＩＤ変更通知を転送し、ルートノードからのＢＰＤＵを正常受信している場合には、変更前のルートＩＤへの復旧を指示するルートＩＤ復旧通知を当該一方の隣接ノードへ返送する処理とを実行する機能とを有している。

ルートＩＤ復旧処理部１３Ｃは、自ノードに隣接する他方の隣接ノードからのルートＩＤ復旧通知に応じて、自ノードのルートＩＤを変更前のルートＩＤへ復旧する処理と、自ノードが障害検出ノードでない場合には、当該ルートＩＤ復旧通知を受信した隣接ノードとは反対側の隣接ノードへ当該ルートＩＤ復旧通知を転送し、自ノードが障害検出ノードである場合には、障害セグメントをブロッキングする処理とを実行する機能を有している。

障害解消処理部１３Ｄは、自ノードに隣接する一方の隣接ノードとの間を接続する障害セグメントで発生した障害の復帰に応じて、当該一方の隣接ノードとの間で相互に自ノードのＭＡＣアドレスをやり取りする処理と、これらＭＡＣアドレスの大小関係に応じたいずれか一方のノードで、当該障害セグメントのブロッキングを行う処理とを実行する機能を有している。
なお、ノードＮ間でやり取りするルートＩＤ変更通知、ルートＩＤ復旧通知、ＭＡＣアドレスをやり取りについては、定期的に送受信するＢＰＤＵを用いて通知してもよい。

図２は、本実施の形態にかかるリング型イーサネットシステムの構成例である。ここでは、前述した図１の構成を有する５つのノードＮ１〜Ｎ５が、リング（通信経路）を介してノードＮ１〜Ｎ５の順に接続されている。これらノードＮ１〜Ｎ５には、データ通信用のアドレスとして、それぞれのノードに固有のＭＡＣアドレス「１」〜「５」が予め設定されている。

また、ＲＳＴＰ機能のイニシャル処理により、これらノードＮ１〜Ｎ５のうちノートＮ１が、冗長化制御処理を行うルートノードとして選択されており、各ノードＮ１〜Ｎ５には、このルートノードを識別するためのルートＩＤとして、ノードＮ１のＭＡＣアドレス「１」が設定されている。

また、ＲＳＴＰ機能のイニシャル処理により、ルートノードＮ１と他のノードＮ２〜Ｎ５との間でＢＰＤＵと呼ばれるネットワーク制御情報をやり取りすることにより、例えばノード間のコストやノードの優先順位に基づいてツリートポロジーの現用系通信経路を設定する。
図２の例では、ノードＮ３，Ｎ４の間を結ぶセグメントのコストが最大となり、このセグメントに接続されるノードＮ３，Ｎ４のうちＭＡＣアドレスの大きいノードＮ４のポートでブロッキングされている。

したがって、このリング型イーサネットシステムは、リング状の通信経路で各ノードＮ１〜Ｎ５が物理的に接続されているものの、現用系通信経路としては、ルートノードＮ１に対してノードＮ２，Ｎ３を接続する経路と、ルートノードＮ１からノードＮ４を接続する経路の２の枝経路を持つツリートポロジーを持つことになる。また、ブロッキングされているノードＮ３，Ｎ４間のセグメントについては、常にデータ通信可能な状態にあり、他のセグメントでの障害発生時にブロッキングが解除されて、バックアップ系通信経路として用いられる。

［本実施の形態の動作］
次に、図３〜図６を参照して、本実施の形態にかかるノードの動作について説明する。図３は、障害発生処理を示すフローチャートである。図４は、ルートＩＤ変更処理を示すフローチャートである。図５は、ルートＩＤ復旧処理を示すフローチャートである。図６は、障害解消処理を示すフローチャートである。
ここでは、本実施の形態にかかるノードの主な動作として、障害発生処理、ルートＩＤ変更処理、ルートＩＤ復旧処理、および障害解消処理のそれぞれについて順に説明する。

［障害発生処理］
まず、図３を参照して、本実施の形態にかかるノードの障害発生処理について説明する。
図２のリング型イーサネットシステムでは、ルートノードＮ１のＲＳＴＰ処理部１３において、ＲＳＴＰ機能に基づく冗長化制御処理が行われており、リングの正常性確認を目的として、ルートノードＮ１から定期的にＢＰＤＵが送信されている。これにより、ルートノードＮ１からノードＮ２とノードＮ４の２つの枝経路へＢＰＤＵが送信され、ノードＮ２でＢＰＤＵが中継転送されてノードＮ３まで送信される。

ルートノードＮ１以外の各ノードＮ２〜Ｎ５のＲＳＴＰ処理部１３は、障害発生処理部１３Ａにより、常時、図３の障害発生処理を実行して、ＭＡＣ処理部１１，１２によるＢＰＤＵの正常受信を監視することによりリングの正常性を確認している。

障害発生処理部１３Ａは、まず、ＭＡＣ処理部１１，１２により、ＢＰＤＵの受信タイミングに応じて、ルートノードＮ１からのＢＰＤＵの受信を待機し（ステップ１００）、ＢＰＤＵの受信タイミングやＢＰＤＵに含まれるデータの整合性を検査することによりＢＰＤＵの正常受信を確認する（ステップ１０１）。
ここで、ＢＰＤＵの正常受信を確認できた場合には（ステップ１００：ＹＥＳ）、ステップ１００へ戻る。

一方、自ノードに対してルートノードＮ１側に隣接する一方の隣接ノードとの間のセグメントで障害が発生し、ルートノードＮ１からのＢＰＤＵの正常受信を確認できなかった場合（ステップ１０１：ＮＯ）、障害発生処理部１３Ａは、自ノードのＭＡＣアドレスを記憶部（図示せず）から読み出し、自ノードのＭＡＣアドレスを新たなルートＩＤとして記憶部へ設定する（ステップ１０２）。この際、自ノードが障害発生を検出したノードである旨を記憶部へ記録しておく。

続いて、障害発生処理部１３Ａは、自ノードに対してルートノードＮ１とは反対側に隣接する他方の隣接ノードへ、当該隣接ノードのルートＩＤを、障害発生を検出した自ノードのＭＡＣアドレスからなる新たなルートＩＤへ変更する指示を含むルートＩＤ変更通知を、ＭＡＣ処理部１１，１２から送信し（ステップ１０３）、ステップ１００へ戻る。

［ルートＩＤ変更処理］
次に、図４を参照して、本実施の形態にかかるノードのルートＩＤ変更処理について説明する。
ルートノードＮ１以外の各ノードＮ２〜Ｎ５のＲＳＴＰ処理部１３は、ＭＡＣ処理部１１，１２でルートＩＤ変更通知を受信した場合、ルートＩＤ変更部１３Ｂにより、図４のルートＩＤ変更処理を実行する。

ルートＩＤ変更部１３Ｂは、まず、自ノードのポートＰ１，Ｐ２のいずれかでブロッキングを行っているか確認し（ステップ１１０）、ブロッキングを行っている場合には（ステップ１１０：ＹＥＳ）、そのブロッキングを解除して（ステップ１１１）、ステップ１１２へ移行し、ブロッキングを行っていない場合には（ステップ１１０：ＮＯ）、直ちにステップ１１２へ移行する。

続いて、ルートＩＤ変更部１３Ｂは、ルートＩＤ変更通知を受信した隣接ノードとは反対側に接続されている隣接ノードから、ルートノードＮ１からのＢＰＤＵをＭＡＣ処理部１１，１２で正常受信しているか確認する（ステップ１１２）。
ここで、ルートノードＮ１からのＢＰＤＵを正常受信していない場合（ステップ１１２：ＮＯ）、ルートＩＤ変更部１３Ｂは、受信したルートＩＤ変更通知で指定された新たなルートＩＤを、自ノードのルートＩＤとして記憶部に設定し（ステップ１１３）、当該ルートＩＤ変更通知を受信した隣接ノードとは反対側に接続されている隣接ノードへ、ＭＡＣ処理部１１，１２を介して当該ルートＩＤ変更通知を転送し（ステップ１１４）、一連のルートＩＤ変更処理を終了する。

一方、ルートノードＮ１からのＢＰＤＵを正常受信している場合（ステップ１１２：ＹＥＳ）、ルートＩＤ変更部１３Ｂは、当該隣接ノードのルートＩＤを元のルートノードＮ１のＭＡＣアドレスからなる元のルートＩＤへの復旧指示を含むルートＩＤ復旧通知を、当該ルートＩＤ変更通知を受信した隣接ノードへ、ＭＡＣ処理部１１，１２を介して送信し（ステップ１１５）、一連のルートＩＤ変更処理を終了する。

［ルートＩＤ復旧処理］
次に、図５を参照して、本実施の形態にかかるノードのルートＩＤ復旧処理について説明する。
ルートノードＮ１以外の各ノードＮ２〜Ｎ５のＲＳＴＰ処理部１３は、ＭＡＣ処理部１１，１２でルートＩＤ復旧通知を受信した場合、ルートＩＤ復旧部１３Ｃにより、図５のルートＩＤ復旧処理を実行する。

ルートＩＤ復旧部１３Ｃは、受信したルートＩＤ復旧通知で指定された元のルートノードＮ１のルートＩＤを、自ノードのルートＩＤとして記憶部に設定し（ステップ１２０）、一連のルートＩＤ復旧処理を終了する。この際、ルートＩＤ復旧通知に元のルートＩＤを含めて通知してもよく、各ノードで保存しておいた直前のルートＩＤを復旧させてもよい。

続いて、ルートＩＤ復旧部１３Ｃは、記憶部を参照して、自ノードが障害発生を検出した障害検出ノードが確認する（ステップ１２１）。
ここで、自ノードが障害検出ノードでない場合（ステップ１２１：ＮＯ）、ルートＩＤ復旧部１３Ｃは、当該ルートＩＤ復旧通知を受信した隣接ノードとは反対側に接続されている隣接ノードへ、ＭＡＣ処理部１１，１２を介して当該ルートＩＤ復旧通知を転送し（ステップ１２２）、一連のルートＩＤ変更処理を終了する。

一方、自ノードが障害検出ノードであった場合（ステップ１２１：ＹＥＳ）、ルートＩＤ復旧部１３Ｃは、障害が発生しているセグメントを接続しているポートＰ１，Ｐ２のいずれかで、当該セグメントのブロッキングを行い（ステップ１２３）、一連のルートＩＤ変更処理を終了する。なお、当該セグメントで障害が発生していることから、リングがループ接続させることはないため、ステップ１２３のブロッキングを省いてもよい。

［障害解消処理］
次に、図６を参照して、本実施の形態にかかるノードの障害解消処理について説明する。
ルートノードＮ１およびノードＮ２〜Ｎ５のＲＳＴＰ処理部１３は、ＭＡＣ処理部１１，１２で、自ノードに隣接する隣接ノードとの間のセグメントで発生していた障害が解消され、当該隣接ノードとの間でデータ通信が可能となった場合、障害解消処理部１３Ｄにより、図６の障害解消処理を実行する。

障害解消処理部１３Ｄは、まず、当該隣接ノードとの間で相互にルートＩＤと自ノードのＭＡＣアドレスをやり取りする（ステップ１３０）。ここで、両ルートＩＤがともにルートノードＮ１を示す「１」であり、両ルートＩＤが一致することから、当該セグメントの接続により、リングがループ状に接続されるため、ブロッキングが必要となる。
したがって、障害解消処理部１３Ｄは、ブロッキングの位置を決定するため、自ＭＡＣアドレスと相手ＭＡＣアドレスとを大小比較する（ステップ１３１）。

ここで、自ＭＡＣアドレスが相手ＭＡＣアドレスより大きい場合（ステップ１３１：ＹＥＳ）、障害が解消されたセグメントを接続しているポートＰ１，Ｐ２のいずれかでブロッキングを行い（ステップ１３２）、一連の障害解消処理を終了する。
一方、自ＭＡＣアドレスが相手ＭＡＣアドレスより小さい場合（ステップ１３１：ＮＯ）、相手ノードでブロッキングが行われるため、障害解消処理部１３Ｄは、直ちに一連の障害解消処理を終了する。なお、両ルートＩＤが一致しない場合、ブロッキングは不要となる。

［動作例］
次に、本実施の形態にかかるノードおよびリング型イーサネットシステムの動作例について説明する。ここでは、前述した図２のリング型イーサネットシステムにおいて、ルートノードＮ１とノードＮ２の間のセグメントで障害が発生した場合の障害発生動作、ルートノードＮ１とノードＮ２の間のセグメントで発生した障害が解消された場合の障害解消動作、および未接続状態にあったノードＮ３，Ｎ４間のセグメントを接続した際のセグメント接続動作について、それぞれ説明する。

［障害発生動作］
まず、図７Ａ〜図７Ｄを参照して、障害発生動作について説明する。図７Ａは、障害発生処理を示す説明図である。図７Ｂは、ルートＩＤ変更処理を示す説明図である。図７Ｃは、ルートＩＤ復旧処理（ルートＩＤ復旧）を示す説明図である。図７Ｄは、ルートＩＤ復旧処理（ブロッキング）を示す説明図である。

前述した図２のリング型イーサネットシステムにおいて、ルートノードＮ１とノードＮ２の間のセグメントで障害が発生した場合、図７Ａに示すように、ルートノードＮ１から送信していたＢＰＤＵがノードＮ２，Ｎ３へ届かなくなる。
これに応じて、ノードＮ２は、前述した図３の障害発生処理により、ルートノードＮ１との間のセグメントでの障害発生を検出し、自ＭＡＣアドレス「２」を自ノードＮ２のルートＩＤとして設定するとともに、ルートノードＮ１とは逆方向のノードＮ３側へルートＩＤ変更通知を送信する。これにより、図７Ｂに示すように、ノードＮ２からノードＮ３に対してルートＩＤ変更通知が転送される。

ノードＮ３では、ルートＩＤ変更通知の受信に応じて、前述した図４のルートＩＤ変更処理を実行し、この場合、ルートノードＮ１からＢＰＤＵを正常受信していないので、ルートＩＤ変更通知で指定されたＭＡＣアドレス「２」を自ノードＮ３のルートＩＤとして設定して、当該ルートＩＤ変更通知をノードＮ４へ転送する。
一方、ノードＮ４では、ルートＩＤ変更通知の受信に応じて、前述した図４のルートＩＤ変更処理を実行し、図７Ｃに示すように、ブロッキングを解除する。この場合、ノードＮ５を介してルートノードＮ１からＢＰＤＵを正常受信しているので、ルートＩＤ復旧通知をノードＮ３側へ返送する。

これに応じて、ノードＮ３では、ルートＩＤ復旧通知の受信に応じて、前述した図５のルートＩＤ復旧処理を実行し、自ノードＮ３のルートＩＤを元のルートノードＮ１に復旧する。この場合、自ノードが障害検出ノードではないので、当該ルートＩＤ復旧通知をノードＮ２へ転送する。
また、ノードＮ２では、ルートＩＤ復旧通知の受信に応じて、前述した図５のルートＩＤ復旧処理を実行し、自ノードＮ２のルートＩＤを元のルートノードＮ１に復旧する。この場合、自ノードが障害検出ノードであることから、図７Ｄに示すように、ルートノードＮ１との間の障害セグメントをブロッキングする。

このように、障害発生時には、障害を検出したノードＮ２からノードＮ４までルートＩＤ変更通知が送信された後、ノードＮ４でブロッキングが解除されてノードＮ２へルートＩＤ復旧通知が送信され、ノードＮ２で障害セグメントがブロッキングされる。このため、ブロッキングが解除された後、ノードＮ２，Ｎ３間のセグメントについて、ＲＳＴＰ再構築によるコスト再計算が行われなくなるため、障害発生時における通信ロスの発生が回避される。

［障害解消動作］
次に、まず、図８Ａ，図８Ｂを参照して、障害解消動作について説明する。図８Ａは、障害解消処理（ハンドシェーク）を示す説明図である。図８Ｂは、障害解消処理（ブロッキング）を示す説明図である。

前述した図７Ｄのリング型イーサネットシステムにおいて、ルートノードＮ１とノードＮ２との間のセグメントでの障害が解消され、ルートノードＮ１とノードＮ２との間でデータ通信が可能となった場合、図８Ａに示すように、ルートノードＮ１とノードＮ２との間で前述した図６の障害解消処理により、ＭＡＣアドレスが相互に交換され、ブロッキングする位置が再決定される。この場合、図８Ｂに示すように、両ＭＡＣアドレスの大きい方のノードＮ２側でブロッキングが行われる。

このように、障害解消時には、障害セグメントに接続されているいずれか一方のノード、ここではノードＮ２で当該障害セグメントがブロッキングされる。このため、障害解消時にツリートポロジーが変更せず、ＲＳＴＰ再構築によるコスト再計算が行われなくなるため、障害解消時における通信ロスの発生が回避される。

［セグメント接続動作］
次に、図９Ａ，図９Ｂを参照して、セグメント接続動作について説明する。図９Ａは、セグメント接続処理（ＭＡＣアドレス交換）を示す説明図である。図９Ｂは、セグメント接続処理（セグメント接続）を示す説明図である。

図９Ａに示すように、ノードＮ３，Ｎ４間のセグメントを接続する際、当該セグメントの接続に応じてデータ通信が可能となったノードＮ３とノードＮ４との間で前述した図６の障害解消処理と同様のセグメント接続処理が実行され、それぞれのルートＩＤとＭＡＣアドレスが相互に交換される。

この場合、両ルートＩＤが一致していることから、当該セグメントの接続により、リングがループ状に接続されるため、ブロッキングが必要となる。このため、両ＭＡＣアドレスが比較され、この場合には、図９Ｂに示すように、両ＭＡＣアドレスの大きい方のノードＮ２側でブロッキングが行われる。なお、両ルートＩＤが一致しない場合、ブロッキングは不要となる。

［本実施の形態の効果］
このように、本実施の形態は、障害発生時、障害検出ノードからブロッキングノードまでルートＩＤ変更通知が送信された後、ブロッキングノードでブロッキングが解除されて障害検出ノードへルートＩＤ復旧通知が送信され、障害検出ノードで障害セグメントがブロッキングされる。このため、ブロッキングが解除されてリングのトポロジーが変更されても、ＲＳＴＰ再構築によるコスト再計算が行われなくなるため、障害発生時における通信ロスの発生が回避される。

また、障害解消時、障害セグメントに接続されているいずれか一方のノードで当該障害セグメントがブロッキングされるため、障害解消時にツリートポロジーが変更せず、ＲＳＴＰ再構築によるコスト再計算が行われなくなるため、障害解消時における通信ロスの発生が回避される。

１…リング型イーサネットシステム、Ｎ，Ｎ１，Ｎ２，Ｎ３，Ｎ４，Ｎ５…ノード、１０…リング接続制御部、１１，１２…ＭＡＣ処理部、１３…ＲＳＴＰ処理部、２０…アプリケーション処理部、Ｐ１，Ｐ２…ポート。

Claims (4)

1. リング状の通信経路を介して複数のノードとを接続することによりこれらノード間のデータ通信を実現するとともに、ＲＳＴＰ（Rapid Spanning Tree Protocol）に基づいて、任意のノードで通信をブロッキングしてルートノードから２つの枝経路で通信を行い、通信の障害発生時には、障害検出ノードに当該ブロッキングを変更して構築したバックアップ系通信経路を用いて通信することで、リングに対する冗長化制御処理を行うリング型イーサネットシステムで用いられるノードであって、
   自ノードに隣接する一方の隣接ノードとの間のセグメントでの障害発生に応じて、自ノードに対応するルートノードを識別するための新たなルートＩＤとして自ノードＩＤを設定するとともに、当該隣接ノードのルートＩＤを前記新たなルートＩＤへ変更指示するルートＩＤ変更通知を、自ノードに隣接する他方の隣接ノードへ送信する障害発生処理部と、
   自ノードに隣接する一方の隣接ノードからの前記ルートＩＤ変更通知の受信に応じて、自ノードに隣接する隣接ノードとの間のセグメントで行っている自ノードでのブロッキングがある場合には、当該ブロッキングを解除する処理と、前記ルートノードからのＢＰＤＵ（Bridge Protocol Data Unit）を正常受信していない場合には、当該ルートＩＤ変更通知で指示された前記新たなルートＩＤへ自ノードのルートＩＤを変更するとともに、自ノードに隣接する他方の隣接ノードへ当該ルートＩＤ変更通知を転送し、前記ルートノードからのＢＰＤＵを正常受信している場合には、変更前のルートＩＤへの復旧を指示するルートＩＤ復旧通知を当該一方の隣接ノードへ返送する処理とを実行するルートＩＤ変更処理部と、
   前記ルートＩＤ復旧通知に応じて、自ノードのルートＩＤを変更前のルートＩＤへ復旧する処理と、自ノードが障害検出ノードでない場合には、当該ルートＩＤ復旧通知を受信した隣接ノードとは反対側の隣接ノードへ当該ルートＩＤ復旧通知を転送し、自ノードが障害検出ノードである場合には、障害セグメントをブロッキングするルートＩＤ復旧処理部と
   を備えることを特徴とするノード。
2. 請求項１に記載のノードにおいて、
   自ノードに隣接する一方の隣接ノードとの間の前記障害セグメントで発生した障害の解消に応じて、当該一方の隣接ノードとの間で相互に自ノードのＭＡＣアドレスをやり取りし、これらＭＡＣアドレスの大小関係に応じたいずれか一方のノードで、当該障害セグメントのブロッキングを行う障害解消部をさらに備えることを特徴とするノード。
3. リング状の通信経路を介して複数のノードとを接続することによりこれらノード間のデータ通信を実現するとともに、ＲＳＴＰ（Rapid Spanning Tree Protocol）に基づいて、任意のノードで通信をブロッキングしてルートノードから２つの枝経路で通信を行い、通信の障害発生時には、障害検出ノードに当該ブロッキングを変更して構築したバックアップ系通信経路を用いて通信することで、リングに対する冗長化制御処理を行うリング型イーサネットシステムで用いられるネットワーク制御方法であって、
   前記ノードのうち自ノードに隣接する一方の隣接ノードとの間のセグメントでの障害発生を検出した障害検出ノードが、自ノードに対応するルートノードを識別するための新たなルートＩＤとして自ノードＩＤを設定するとともに、当該隣接ノードのルートＩＤを前記新たなルートＩＤへ変更指示するルートＩＤ変更通知を、自ノードに隣接する他方の隣接ノードへ送信する障害発生処理ステップと、
   前記ノードのうち自ノードに隣接する隣接ノードとの間のセグメントでブロッキングを行っているブロッキングノードが、前記ルートＩＤ変更通知の受信に応じて、当該ブロッキングを解除するとともに、変更前のルートＩＤへの復旧を指示するルートＩＤ復旧通知を当該一方の隣接ノードへ返送するルートＩＤ変更処理ステップと、
   前記障害検出ノードが、前記ルートＩＤ復旧通知の受信に応じて、自ノードのルートＩＤを変更前のルートＩＤへ復旧するとともに、前記障害セグメントをブロッキングするルートＩＤ復旧処理ステップと
   を備えることを特徴とするネットワーク制御方法。
4. 請求項３に記載のネットワーク制御方法において、
   前記障害検出ノードが、前記障害の解消に応じて、当該障害セグメントを介して接続されている隣接ノードとの間で相互に自ノードのＭＡＣアドレスをやり取りし、これらＭＡＣアドレスの大小関係に応じたいずれか一方のノードで、当該障害セグメントのブロッキングを行う障害解消ステップをさらに備えることを特徴とするネットワーク制御方法。

Images