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

Abstract

【課題】ノードを接続するリングとして全二重イーサネットを用いた場合でも、セグメントごとに両方の通信線について障害を監視する。
【解決手段】ノードＮの第２の障害監視処理部１３Ｂにより、ルートノードからのＢＰＤＵ（Ｆｄ）の受信に応じて上流ノードへ通信線Ｌｂを介してＢＰＤＵ（Ａｇ）を返送し、下流ノードから通信線Ｌｂを介して届くＢＰＤＵ（Ａｇ）の正常性に基づき、下流セグメントでの通信線Ｌｂの障害有無を監視する。
【選択図】 図１

Description

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

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

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

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

図１１は、典型的なリング型イーサネットシステムの構成例である。ここでは、５つのノードＮ１〜Ｎ５がリングでリング接続されており、ノード４のうちノード３側のポートでブロッキングが行われている。
このブロッキングにより、リングトポロジーからなる元のリングから、ルートノードＮ１からノードＮ２→ノードＮ３およびノードＮ５→ノードＮ４までの２つの枝経路を持つツリートポロジーが構築される。これにより、物理的にリングトポロジーを形成しているネットワークであっても、データループの発生が回避される。

このようなリング型イーサネットシステムでは、ルートノードと他のノードとの間でＢＰＤＵ（Bridge Protocol Data Unit）と呼ばれるネットワーク制御情報のうち、Forwardingと呼ばれるＢＰＤＵをやり取りすることにより、リングでの障害発生を監視している。
図１１の場合、ルートノードＮ１からノードＮ２方向とノードＮ５方向の２方向へForwarding ＢＰＤＵが定期的に送信される。各ノードＮ２〜Ｎ５は、ルートノードＮ１からのForwarding ＢＰＤＵを正常に受信した場合、後続のノードへ転送する。したがって、Forwarding ＢＰＤＵが正常に受信できない場合、ルートノードＮ１側に隣接するノードとの間のセグメントで障害が発生したことが確認できる。

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

このような従来技術では、リング型イーサネットシステムのリングとして全二重イーサネットを使用している場合、各ノード間のセグメントは、送信と受信とで異なる通信線を用いることになる。したがって、障害監視用のForwarding ＢＰＤＵは、各セグメントのうちいずれか一方の通信線を介して転送されるため、他方の通信線については障害を監視できないという問題点があった。

図１２は、全二重イーサネット対応のノードの要部構成を示すブロック図である。
全二重イーサネット通信では、隣接ノード間でデータ送受信を並列的に実行するため、ノードを接続するリングＬには２つの独立した通信線Ｌａ，Ｌｂが設けられているとともに、各ノードにおいてリングＬが接続される２つのポートＰ１，Ｐ２のそれぞれに、受信系と送信系が独立して構成されている。

ノードＮ２のＲＳＴＰ処理部１３がノードＮ３へForwarding ＢＰＤＵを送信する場合、ノードＮ２において、ＭＡＣ処理部１２→ポートＰ２（物理層の送信回路→トランスの送信コイル→コネクタの送信ピン）を経由して通信線Ｌａへ出力される。一方、ノードＮ３では、通信線ＬａからのForwarding ＢＰＤＵを、ポートＰ１（コネクタの受信ピン→トランスの受信コイル→物理層の受信回路）→ＭＡＣ処理部１１を経由してＲＳＴＰ処理部１３で受信される。これにより、ノードＮ２，Ｎ３間のセグメントのうち一方の通信線Ｌａに関する経路について、障害の有無が確認されることになる。

しかしながら、Forwarding ＢＰＤＵは、通信線Ｌａに関する経路しか通過していないことから、ノードＮ２，Ｎ３間のセグメントのうち通信線Ｌｂに関する経路、すなわちノードＮ３のＭＡＣ処理部１１→ポートＰ１（物理層の送信回路→トランスの送信コイル→コネクタの送信ピン）→通信線Ｌｂ→ポートＰ２（コネクタの受信ピン→トランスの受信コイル→物理層の受信回路）→ＭＡＣ処理部１２という経路については、障害を監視していないことになる。

本発明はこのような課題を解決するためのものであり、ノードを接続するリングとして全二重イーサネットを用いた場合でも、セグメントごとに両方の通信線について障害を監視できるリング型イーサネット制御技術を提供することを目的としている。

このような目的を達成するために、本発明にかかるノードは、第１および第２の通信線を有する全二重イーサネットからなるリングを介して、複数のノードをリング状に接続することにより、これらノード間のデータ通信を実現するとともに、ＲＳＴＰ（Rapid Spanning Tree Protocol）に基づいてリングでの障害発生を監視するリング型イーサネットシステムで用いられるノードであって、自ノードに隣接する一方の隣接ノードから第１の通信線を介して届く、ノードの１つであるルートノードからのヘルスチェックメッセージの正常性に基づいて、当該一方の隣接ノードとの間のセグメントにおける当該第１の通信線での障害有無を監視し、当該障害無の確認に応じて自ノードに隣接する他方の隣接ノードへ第１の通信線を介して当該ヘルスチェックメッセージを転送する第１の障害監視処理部と、障害無の確認に応じて一方の隣接ノードへ第２の通信線を介して当該ヘルスチェックメッセージに対する応答メッセージを返送し、他方の隣接ノードから第２の通信線を介して届く応答メッセージの正常性に基づいて、当該他方の隣接ノードとの間のセグメントにおける当該第２の通信線での障害有無を監視する第２の障害監視処理部とを備えている。

この際、第２の障害監視処理部で、他方の隣接ノードとの間のセグメントにおける第２の通信線での障害有の確認に応じて、他方の隣接ノードへ第１の通信線を介して当該障害の発生を通知するための障害発生通知の間欠送信を開始し、一方の隣接ノードから第１の通信線を介して受信した障害発生通知に応じて、当該一方の隣接ノードとの間の障害セグメントをブロッキングする処理と、自ノードに対応するルートノードを識別するための新たなルートＩＤとして自ノードＩＤを設定する処理と、当該隣接ノードのルートＩＤを新たなルートＩＤへ変更指示するルートＩＤ変更通知を、自ノードに隣接する他方の隣接ノードへ第１の通信線を介して送信する処理とを実行する障害発生受信処理部と、一方の隣接ノードから第１の通信線を介して受信したルートＩＤ変更通知に応じて、自ノードに隣接する隣接ノードとの間のセグメントに対する自ノードでのブロッキングを解除する処理と、他方の隣接ノードから第２の通信線を介して届くヘルスチェックメッセージの正常性が確認されていない場合には、当該ルートＩＤ変更通知で指示された新たなルートＩＤへ自ノードのルートＩＤを変更するとともに、他方の隣接ノードへ第１の通信線を介して当該ルートＩＤ変更通知を転送する処理と、当該ヘルスチェックメッセージの正常性が確認されている場合には、変更前のルートＩＤへの復旧を指示するルートＩＤ復旧通知を当該一方の隣接ノードへ第２の通信線を介して返送する処理とを実行するルートＩＤ変更処理部と、他方の隣接ノードから第２の通信線を介して受信したルートＩＤ復旧通知に応じて、自ノードのルートＩＤを変更前のルートＩＤへ復旧する処理と、自ノードが障害発生通知の受信ノードでない場合には、一方の隣接ノードへ第２の通信線を介して当該ルートＩＤ復旧通知を転送する処理と、自ノードが障害発生通知の受信ノードである場合には、一方の隣接ノードへ第２の通信線を介して当該障害の解消を通知するための障害解消通知の間欠送信を開始する処理とを実行するルートＩＤ復旧処理部とをさらに備えてもよい。

また、他方の隣接ノードから第２の通信線を介して受信した障害解消通知に応じて、当該他方の隣接ノードへ第１の通信線を介して自ノードのＭＡＣアドレスを通知する処理と、当該他方の隣接ノードから第２の通信線を介して当該他方の隣接ノードのＭＡＣアドレスを取得する処理と、これらＭＡＣアドレスの大小関係に応じたいずれか一方のノードで、当該障害セグメントのブロッキングを行う処理とを実行する障害解消処理部をさらに備えてもよい。

また、本発明にかかるネットワーク制御方法は、第１および第２の通信線を有する全二重イーサネットからなるリングを介して、複数のノードをリング状に接続することにより、これらノード間のデータ通信を実現するとともに、ＲＳＴＰ（Rapid Spanning Tree Protocol）に基づいてリングでの障害発生を監視するリング型イーサネットシステムで用いられるネットワーク制御方法であって、ノードの第１の障害監視処理部が、自ノードに隣接する一方の隣接ノードから第１の通信線を介して届く、ノードの１つであるルートノードからのヘルスチェックメッセージの正常性に基づいて、当該一方の隣接ノードとの間のセグメントにおける当該第１の通信線での障害有無を監視し、当該障害無の確認に応じて自ノードに隣接する他方の隣接ノードへ第１の通信線を介して当該ヘルスチェックメッセージを転送する第１の障害監視ステップと、ノードの第２の障害監視処理部が、障害無の確認に応じて一方の隣接ノードへ第２の通信線を介して当該ヘルスチェックメッセージに対する応答メッセージを返送し、他方の隣接ノードから第２の通信線を介して届く応答メッセージの正常性に基づいて、当該他方の隣接ノードとの間のセグメントにおける当該第２の通信線での障害有無を監視する第２の障害監視ステップとを備えている。

この際、第２の障害監視ステップに、他方の隣接ノードとの間のセグメントにおける第２の通信線での障害有の確認に応じて、他方の隣接ノードへ第１の通信線を介して当該障害の発生を通知するための障害発生通知の間欠送信を開始するステップを含み、ノードの障害発生受信処理部が、一方の隣接ノードから第１の通信線を介して受信した障害発生通知に応じて、当該一方の隣接ノードとの間の障害セグメントをブロッキングする処理と、自ノードに対応するルートノードを識別するための新たなルートＩＤとして自ノードＩＤを設定する処理と、当該隣接ノードのルートＩＤを新たなルートＩＤへ変更指示するルートＩＤ変更通知を、自ノードに隣接する他方の隣接ノードへ第１の通信線を介して送信する処理とを実行する障害発生受信処理ステップと、ノードのルートＩＤ変更処理部が、一方の隣接ノードから第１の通信線を介して受信したルートＩＤ変更通知に応じて、自ノードに隣接する隣接ノードとの間のセグメントに対する自ノードでのブロッキングを解除する処理と、他方の隣接ノードから第２の通信線を介して届くヘルスチェックメッセージの正常性が確認されていない場合には、当該ルートＩＤ変更通知で指示された新たなルートＩＤへ自ノードのルートＩＤを変更するとともに、他方の隣接ノードへ第１の通信線を介して当該ルートＩＤ変更通知を転送する処理と、当該ヘルスチェックメッセージの正常性が確認されている場合には、変更前のルートＩＤへの復旧を指示するルートＩＤ復旧通知を当該一方の隣接ノードへ第２の通信線を介して返送する処理とを実行するルートＩＤ変更処理ステップと、ノードのルートＩＤ復旧処理部が、他方の隣接ノードから第２の通信線を介して受信したルートＩＤ復旧通知に応じて、自ノードのルートＩＤを変更前のルートＩＤへ復旧する処理と、自ノードが障害発生通知の受信ノードでない場合には、一方の隣接ノードへ第２の通信線を介して当該ルートＩＤ復旧通知を転送する処理と、自ノードが障害発生通知の受信ノードである場合には、一方の隣接ノードへ第２の通信線を介して当該障害の解消を通知するための障害解消通知の間欠送信を開始する処理とを実行するルートＩＤ復旧処理ステップとをさらに備えてもよい。

また、ノードの障害解消処理部が、他方の隣接ノードから第２の通信線を介して受信した障害解消通知に応じて、当該他方の隣接ノードへ第１の通信線を介して自ノードのＭＡＣアドレスを通知する処理と、当該他方の隣接ノードから第２の通信線を介して当該他方の隣接ノードのＭＡＣアドレスを取得する処理と、これらＭＡＣアドレスの大小関係に応じたいずれか一方のノードで、当該障害セグメントのブロッキングを行う処理とを実行する障害解消処理ステップをさらに備えてもよい。

本発明によれば、ノードを接続するリングとして全二重イーサネットを用いた場合でも、上流ノードから届くヘルスチェックメッセージに基づき上流セグメントの第１の通信線での障害有無を監視できるとともに、下流ノードから届くヘルスチェックメッセージに対する応答メッセージに基づき下流セグメントの第２の通信線での障害有無を監視することが可能となる。

本実施の形態にかかるノードの要部構成を示すブロック図である。 本実施の形態にかかるリング型イーサネットシステムの構成例である。 第１の障害監視処理を示すフローチャートである。 第２の障害監視処理を示すフローチャートである。 障害発生受信処理を示すフローチャートである。 ルートＩＤ変更処理を示すフローチャートである。 ルートＩＤ復旧処理を示すフローチャートである。 障害解消処理を示すフローチャートである。 第２の障害監視処理（正常時）を示す説明図である。 第２の障害監視処理（障害発生時）を示す説明図である。 ルートＩＤ変更処理を示す説明図である。 ルートＩＤ復旧処理（ルートＩＤ復旧）を示す説明図である。 ルートＩＤ復旧処理（障害解消通知）を示す説明図である。 障害解消処理（障害解消時）を示す説明図である。 障害解消処理（ハンドシェーク）を示す説明図である。 障害解消処理（ブロッキング）を示す説明図である。 典型的なリング型イーサネットシステムの構成例である。 全二重イーサネット対応のノードの要部構成を示すブロック図である。

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

このノードＮは、ＲＳＴＰ（Rapid Spanning Tree Protocol）に基づいて、リングＬに対する冗長化制御処理を行うリング型イーサネットシステム１で用いられるデータ通信用のノードである。このリングＬは、全二重イーサネットからなるリング状の通信経路であり、各ノードＮ間でデータ送受信を並列的に実行するため、リングＬには２つの独立した通信線Ｌａ，Ｌｂが設けられている。

ノードＮには、主な機能部として、リング接続制御部１０とアプリケーション処理部２０とが設けられている。
リング接続制御部１０は、リングＬを介して他のノードＮとの間のデータ通信（イーサネット準拠）を制御する機能を有している。
アプリケーション処理部２０は、リング接続制御部１０を介して他のノードＮとの全二重イーサネット通信により、例えばビル設備やプラント設備を監視制御するための各種アプリケーション処理を行う機能を有している。

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

ＭＡＣ処理部１２は、リング接続用のポートＰ２を介してリングＬの他端Ｌ２と接続し、各ノードＮとの間でＭＡＣフレームを送受信する機能と、自ノードのポートのいずれか一方による特定のＭＡＣフレームの送受信を規制するブロッキングを行う機能と、冗長化制御処理用の制御情報を含むＭＡＣフレームをＲＳＴＰ処理部１３へ出力する機能とを有している。

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

第１の障害監視処理部１３Ａは、自ノードに隣接する一方の隣接ノードから第１の通信線を介して届くルートノードからのヘルスチェックメッセージの正常性に基づいて、当該一方の隣接ノードとの間のセグメントにおける当該第１の通信線での障害有無を監視する機能と、当該障害無の確認に応じて自ノードに隣接する他方の隣接ノードへ第１の通信線を介して当該ヘルスチェックメッセージを転送する機能とを有している。

第２の障害監視処理部１３Ｂは、第１の障害監視処理部１３Ａによる当該一方の隣接ノードとの間のセグメントにおける当該第１の通信線での障害無の確認に応じて、一方の隣接ノードへ第２の通信線を介して当該ヘルスチェックメッセージに対する応答メッセージを返送する機能と、他方の隣接ノードから第２の通信線を介して届く応答メッセージの正常性に基づいて、当該他方の隣接ノードとの間のセグメントにおける当該第２の通信線での障害有無を監視する機能と、他方の隣接ノードとの間のセグメントにおける第２の通信線での障害有の確認に応じて、他方の隣接ノードへ第１の通信線を介して当該障害の発生を通知するための障害発生通知の間欠送信を開始する機能とを有している。

障害発生受信処理部１３Ｃは、一方の隣接ノードから第１の通信線を介して受信した障害発生通知に応じて、当該一方の隣接ノードとの間の障害セグメントをブロッキングする処理と、自ノードに対応するルートノードを識別するための新たなルートＩＤとして自ノードＩＤを設定する処理と、当該隣接ノードのルートＩＤを新たなルートＩＤへ変更指示するルートＩＤ変更通知を、自ノードに隣接する他方の隣接ノードへ第１の通信線を介して送信する処理とを実行する機能を有している。

ルートＩＤ変更処理部１３Ｄは、一方の隣接ノードから第１の通信線を介して受信したルートＩＤ変更通知に応じて、自ノードに隣接する隣接ノードとの間のセグメントに対する自ノードでのブロッキングを解除する処理と、他方の隣接ノードから第２の通信線を介して届くヘルスチェックメッセージの正常性が確認されていない場合には、当該ルートＩＤ変更通知で指示された新たなルートＩＤへ自ノードのルートＩＤを変更するとともに、他方の隣接ノードへ第１の通信線を介して当該ルートＩＤ変更通知を転送する処理と、当該ヘルスチェックメッセージの正常性が確認されている場合には、変更前のルートＩＤへの復旧を指示するルートＩＤ復旧通知を当該一方の隣接ノードへ第２の通信線を介して返送する処理とを実行する機能とを有している。

ルートＩＤ復旧処理部１３Ｅは、他方の隣接ノードから第２の通信線を介して受信したルートＩＤ復旧通知に応じて、自ノードのルートＩＤを変更前のルートＩＤへ復旧する処理と、自ノードが障害発生通知の受信ノードでない場合には、一方の隣接ノードへ第２の通信線を介して当該ルートＩＤ復旧通知を転送する処理と、自ノードが障害発生通知の受信ノードである場合には、一方の隣接ノードへ第２の通信線を介して当該障害の解消を通知するための障害解消通知の間欠送信を開始する処理とを実行する機能を有している。

障害解消処理部１３Ｆは、他方の隣接ノードから第２の通信線を介して受信した障害解消通知に応じて、当該他方の隣接ノードへ第１の通信線を介して自ノードのＭＡＣアドレスを通知する処理と、当該他方の隣接ノードから第２の通信線を介して当該他方の隣接ノードのＭＡＣアドレスを取得する処理と、これらＭＡＣアドレスの大小関係に応じたいずれか一方のノードで、当該障害セグメントのブロッキングを行う処理とを実行する機能を有している。

ノードＮ間でやり取りするヘルスチェックメッセージ、応答メッセージ、および障害解消通知については、それぞれＲＳＴＰで用いるForwarding ＢＰＤＵ、Agree ＢＰＤＵ、およびPropose ＢＰＤＵを利用してもよい。また、ルートＩＤ変更通知、ルートＩＤ復旧通知、ＭＡＣアドレスをやり取りについても、ノードＮ間で定期的に送受信するＢＰＤＵを用いて通知してもよい。

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

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

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

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

［本実施の形態の動作］
次に、図３〜図８を参照して、本実施の形態にかかるノードの動作について説明する。図３は、第１の障害監視処理を示すフローチャートである。図４は、第２の障害監視処理を示すフローチャートである。図５は、障害発生受信処理を示すフローチャートである。図６は、ルートＩＤ変更処理を示すフローチャートである。図７は、ルートＩＤ復旧処理を示すフローチャートである。図８は、障害解消処理を示すフローチャートである。

ここでは、本実施の形態にかかるノードの主な動作として、第１の障害監視処理、第２の障害監視処理、障害発生受信処理、ルートＩＤ変更処理、ルートＩＤ復旧処理、および障害解消処理のそれぞれについて順に説明する。
なお、以下では、便宜上、自ノードに対してルートノードＮ１側に隣接する一方の隣接ノードを上流ノードと呼び、自ノードに対してルートノードＮ１とは反対側に隣接する他方の隣接ノードを下流ノードと呼ぶ。

また、ここでは、上記各処理の主体となるノードが、図２のノードＮ２のように、リングＬのうち通信線Ｌａ（第１の通信線）を介してヘルスチェックメッセージを受信し、これに対する応答メッセージを通信線Ｌｂ（第２の通信線）を介して返送する場合を例として説明する。なお、ノードＮ５のように、通信線Ｌｂを介してヘルスチェックメッセージについては、例えば通信線Ｌａと通信線Ｌｂや上流と下流を相互に読み替えればよい。

また、ノードＮ間でやり取りするヘルスチェックメッセージ、応答メッセージ、および障害解消通知については、それぞれＲＳＴＰのForwarding ＢＰＤＵ、Agree ＢＰＤＵ、およびPropose ＢＰＤＵを利用するものとする。なお、Forwarding ＢＰＤＵ、Agree ＢＰＤＵ、およびPropose ＢＰＤＵは、ＢＰＤＵ（Ｆｄ）、ＢＰＤＵ（Ａｇ）、およびＢＰＤＵ（Ｐｒ）と略す。

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

ルートノードＮ１以外の各ノードＮ２〜Ｎ５のＲＳＴＰ処理部１３は、第１の障害監視処理部１３Ａにより、常時、図３に示す第１の障害監視処理を実行して、上流ノードから、当該上流ノードとの間の上流セグメントのうち通信線Ｌａを介して届くＢＰＤＵ（Ｆｄ）の正常性を監視することにより、当該通信線Ｌａの障害有無を監視している。

第１の障害監視処理部１３Ａは、まず、ＢＰＤＵ（Ｆｄ）の正規受信タイミング、例えば前回受信したＢＰＤＵ（Ｆｄ）から正規受信間隔だけ経過した受信タイミングに応じて、上流ノードから通信線Ｌａを介して届くＢＰＤＵ（Ｆｄ）の受信を待機し（ステップ１００）、ＢＰＤＵ（Ｆｄ）の受信タイミングやＢＰＤＵ（Ｆｄ）に含まれるデータの整合性を検査することによりＢＰＤＵ（Ｆｄ）の正常性を確認する（ステップ１０１）。

ここで、ＢＰＤＵ（Ｆｄ）の正常性を確認した場合（ステップ１０１：ＹＥＳ）、第１の障害監視処理部１３Ａは、上流セグメントの通信線Ｌａについて障害無と判定し（ステップ１０２）、下流ノードへ通信線Ｌａを介して当該ＢＰＤＵ（Ｆｄ）を転送し（ステップ１０３）、ステップ１００へ戻る。
一方、上流セグメントの通信線Ｌａで障害が発生して、上流ノードからのＢＰＤＵ（Ｆｄ）の正常受信を確認できなかった場合（ステップ１０１：ＮＯ）、第１の障害監視処理部１３Ａは、上流セグメントの通信線Ｌａについて障害有と判定し（ステップ１０４）、ステップ１００へ戻る。

［第２の障害監視処理］
次に、図４を参照して、本実施の形態にかかるノードの第２の障害監視処理について説明する。
図３のステップ１０２において、上流セグメントの通信線Ｌａについて障害無と判定した場合、ノードＮの第２の障害監視処理部１３Ｂは、図４の第２の障害監視処理を実行する。

第２の障害監視処理部１３Ｂは、まず、上流ノードに対して上流セグメントの通信線Ｌｂを介して、上流ノードから正常受信したＢＰＤＵ（Ｆｄ）に対する応答メッセージを返送する（ステップ１１０）。

続いて、第２の障害監視処理部１３Ｂは、下流ノードへ転送したＢＰＤＵ（Ｆｄ）に対応するＢＰＤＵ（Ａｇ）の正規受信タイミング、例えば直前に送信したＢＰＤＵ（Ｆｄ）から正規応答期間内を示す受信タイミングに応じて、下流ノードから通信線Ｌｂを介して届くＢＰＤＵ（Ａｇ）の受信を待機し（ステップ１１１）、ＢＰＤＵ（Ａｇ）の受信タイミングやＢＰＤＵ（Ａｇ）に含まれるデータの整合性を検査することによりＢＰＤＵ（Ａｇ）の正常性を確認する（ステップ１１２）。

ここで、ＢＰＤＵ（Ａｇ）の正常性を確認した場合（ステップ１１２：ＹＥＳ）、第２の障害監視処理部１３Ｂは、下流セグメントの通信線Ｌｂについて障害無と判定し（ステップ１１３）、一連の第２の障害監視処理を終了する。
一方、下流セグメントの通信線Ｌｂで障害が発生して、下流ノードからのＢＰＤＵ（Ａｇ）の正常受信を確認できなかった場合（ステップ１１２：ＮＯ）、第２の障害監視処理部１３Ｂは、下流セグメントの通信線Ｌｂについて障害有と判定し（ステップ１１４）、下流ノードへ下流セグメントの通信線Ｌａを介して当該障害の発生を通知するための障害発生通知の間欠送信を開始し（ステップ１１５）、一連の第２の障害監視処理を終了する。この障害発生通知の間欠送信は、障害が解消されるまで継続される。

［障害発生受信処理］
次に、図５を参照して、本実施の形態にかかるノードの障害発生受信処理について説明する。
ルートノードＮ１以外の各ノードＮ２〜Ｎ５のＲＳＴＰ処理部１３は、図４のステップ１１５において間欠送信が開始された障害発生通知を、上流ノードから通信線Ｌａを介して受信した場合、障害発生受信処理部１３Ｃにより、図５の障害発生受信処理を実行する。

障害発生受信処理部１３Ｃは、まず、障害発生通知を受信した上流セグメントをブロッキングし（ステップ１２０）、自ノードのＭＡＣアドレスを記憶部（図示せず）から読み出し、自ノードのＭＡＣアドレスを新たなルートＩＤとして記憶部へ設定する（ステップ１２１）。この際、自ノードが障害発生通知を受信したノードである旨を記憶部へ記録しておく。

続いて、障害発生受信処理部１３Ｃは、当該隣接ノードのルートＩＤを、障害発生を検出した自ノードのＭＡＣアドレスからなる新たなルートＩＤへ変更する指示を含むルートＩＤ変更通知を、通信線Ｌａを介して下流ノードへ送信し（ステップ１２２）、一連の障害発生受信処理を終了する。

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

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

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

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

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

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

続いて、ルートＩＤ復旧処理部１３Ｅは、記憶部を参照して、自ノードが障害発生通知の受信ノードかどうか確認する（ステップ１４１）。
ここで、自ノードが障害発生通知の受信ノードでない場合（ステップ１４１：ＮＯ）、ルートＩＤ復旧処理部１３Ｅは、上流ノードへ通信線Ｌｂを介して当該ルートＩＤ復旧通知を転送し（ステップ１４２）、一連のルートＩＤ変更処理を終了する。

一方、自ノードが障害発生通知の受信ノードであった場合（ステップ１４１：ＹＥＳ）、ルートＩＤ復旧処理部１３Ｅは、上流ノードへ通信線Ｌｂを介して当該障害の解消を通知するためのＢＰＤＵ（Ｐｒ）の間欠送信を開始し（ステップ１４３）、一連のルートＩＤ変更処理を終了する。このＢＰＤＵ（Ｐｒ）の間欠送信は、障害が解消されるまで継続される。

［障害解消処理］
次に、図８を参照して、本実施の形態にかかるノードの障害解消処理について説明する。
ルートノードＮ１およびノードＮ２〜Ｎ５のＲＳＴＰ処理部１３は、図７のステップ１４３において間欠送信が開始されたＢＰＤＵ（Ｐｒ）を、下流ノードから通信線Ｌｂを介して受信した場合、下流セグメントで発生していた障害が解消されて下流ノードとの間でデータ通信が可能となったと判定し、当該障害解消セグメントの両端に接続されている各ノードＮのＲＳＴＰ処理部１３で、障害発生通知およびＢＰＤＵ（Ｐｒ）の間欠送信を互いに停止して、障害解消処理部１３Ｆにより、図８の障害解消処理を実行する。

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

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

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

［障害発生動作］
まず、図９Ａ〜図９Ｅを参照して、障害発生動作について説明する。図９Ａは、第２の障害監視処理（正常時）を示す説明図である。図９Ｂは、第２の障害監視処理（障害発生時）を示す説明図である。図９Ｃは、ルートＩＤ変更処理を示す説明図である。図９Ｄは、ルートＩＤ復旧処理（ルートＩＤ復旧）を示す説明図である。図９Ｅは、ルートＩＤ復旧処理（障害解消通知）を示す説明図である。

前述した図２のリング型イーサネットシステム１において、いずれのセグメントにも障害が発生していない場合、ノードＮ２〜Ｎ５は、ルートノードＮ１から送信されたＢＰＤＵ（Ｆｄ）を受信した際、前述した図４の第２の障害監視処理により、図９Ａに示すように、それぞれの上流ノードに対してＢＰＤＵ（Ａｇ）を返送する。ルートノードＮ１およびノードＮ２，Ｎ５は、それぞれの下流ノードから届くＢＰＤＵ（Ａｇ）の正常性に基づいて、下流セグメントの通信線Ｌｂ（Ｌａ）での障害有無を監視する。

ここで、図９Ｂに示すように、ノードＮ２とノードＮ３の間のセグメントで障害が発生した場合、ルートノードＮ１から送信していたＢＰＤＵ（Ｆｄ）がノードＮ２からＮ３へ届かなくなる。
これに応じて、ノードＮ２は、前述した図４の第２の障害監視処理により、ノードＮ３との間のセグメントでの障害発生を検出し、図９Ｂに示すように、下流ノードＮ３へ通信線Ｌａを介して障害発生通知の送信を開始する。

一方、ノードＮ３は、上流ノードＮ２から通信線Ｌａを介して障害発生通知を受信した場合、前述した図５の障害発生受信処理を実行し、図９Ｃに示すように、ノードＮ２側のポートでブロッキングを設定する。
続いて、ノードＮ３は、自ＭＡＣアドレス「３」を自ノードＮ３のルートＩＤとして設定するとともに、下流ノードＮ４へルートＩＤ変更通知を送信する。これにより、ノードＮ３からノードＮ４に対してルートＩＤ変更通知が転送される。

ノードＮ４では、ルートＩＤ変更通知の受信に応じて、前述した図４のルートＩＤ変更処理を実行し、図９Ｄに示すように、ブロッキングを解除する。この場合、ノードＮ４は、ノードＮ５を介してルートノードＮ１からＢＰＤＵ（Ｆｄ）を正常受信しているので、ルートＩＤ復旧通知を上流ノードＮ３へ返送する。

これに応じて、ノードＮ３は、ルートＩＤ復旧通知の受信に応じて、前述した図７のルートＩＤ復旧処理を実行し、自ノードＮ３のルートＩＤを元のルートノードＮ１に復旧する。この場合、自ノードが障害発生受信ノードであることから、図９Ｅに示すように、上流ノードＮ２へ通信線Ｌｂを介してＢＰＤＵ（Ｐｒ）の送信を開始する。

このように、ノードＮ２〜Ｎ５において、ルートノードＮ１からのＢＰＤＵ（Ｆｄ）の受信に応じて上流ノードへ通信線Ｌｂを介してＢＰＤＵ（Ａｇ）を返送するようにしたので、下流ノードから届くＢＰＤＵ（Ａｇ）の正常性に基づき通信線Ｌｂの障害有無を監視することが可能となる。
また、通信線Ｌｂでの障害発生時には、障害を検出したノードＮ２からその下流ノードＮ３に対して障害発生通知が送信される。これにより、ルートノードＮ１からのＢＰＤＵ（Ｆｄ）を正常受信しているため、障害検出ノードＮ２でルートＩＤを変更できない場合でも、下流ノードに対するルートＩＤ変更処理を、ノードＮ３へ委託して実行することができる。

また、ルートＩＤ変更処理によりノードＮ３からルートＩＤ変更通知が送信された後、ノードＮ４でブロッキングが解除されてノードＮ３へルートＩＤ復旧通知が送信され、ノードＮ３からノードＮ２に対してＢＰＤＵ（Ｐｒ）の送信が開始される。これにより、通信線Ｌｂの障害復旧をノードＮ２で迅速に確認することが可能となる。

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

図１０Ａに示すように、リング型イーサネットシステム１において、ノードＮ２とノードＮ３との間のセグメントでの障害が解消された場合、ノードＮ３からのＢＰＤＵ（Ｐｒ）がノードＮ２へ届くことになり、ノードＮ２はノードＮ３との間でデータ通信が可能となったことを確認する。
これに応じて、図１０Ｂに示すように、ノードＮ２とノードＮ３との間で前述した図８の障害解消処理により、ＭＡＣアドレスが相互に交換され、ブロッキングする位置が再決定される。この場合、両ＭＡＣアドレスの大きい方のノードＮ３側で改めてブロッキングが行われる。

これにより、このリング型イーサネットシステム１は、図１０Ｃに示すように、バックアップ系通信経路として、ルートノードＮ１に対してノードＮ２を接続する経路と、ルートノードＮ１からノードＮ５，Ｎ４，Ｎ３を接続する経路の２の枝経路を持つツリートポロジーを持つことになる。したがって、ＢＰＤＵ（Ｆｄ）は、ルートノードＮ１からノードＮ２へ送信されるとともに、ルートノードＮ１からノードＮ５，Ｎ４，Ｎ３へ送信されることになる。

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

［本実施の形態の効果］
このように、本実施の形態は、ノードＮの第２の障害監視処理部１３Ｂにより、ルートノードからのＢＰＤＵ（Ｆｄ）の受信に応じて上流ノードへ通信線Ｌｂを介してＢＰＤＵ（Ａｇ）を返送し、下流ノードから通信線Ｌｂを介して届くＢＰＤＵ（Ａｇ）の正常性に基づき、下流セグメントでの通信線Ｌｂの障害有無を監視するようにしたので、ノードを接続するリングとして全二重イーサネットを用いた場合でも、上流ノードから届くＢＰＤＵ（Ｆｄ）の正常性に基づき上流セグメントの通信線Ｌａでの障害有無を監視できるとともに、下流ノードから届くＢＰＤＵ（Ａｇ）の正常性に基づき下流セグメントの通信線Ｌｂでの障害有無を監視することが可能となる。

また、本実施の形態では、ノードＮの第２の障害監視処理部１３Ｂにより、通信線Ｌｂでの障害発生時、障害を検出したノードＮからその下流ノードに対して障害発生通知を送信するようにしたので、ルートノードＮ１からのＢＰＤＵ（Ｆｄ）を正常受信しているため、障害検出ノードＮでルートＩＤを変更できない場合でも、下流ノードに対するルートＩＤ変更処理を、障害セグメントの他端に接続されている下流ノードへ委託して実行することができる。

また、本実施の形態では、ノードＮの障害発生受信処理部１３Ｃにより、上流ノードからの障害発生通知に応じてルートＩＤ変更通知を下流ノードへ送信し、これに応じてルートノードＮ１からのＢＰＤＵ（Ｆｄ）を正常受信しているノードＮのルートＩＤ変更処理部１３Ｄでブロッキングを解除して上流ノードへルートＩＤ復旧通知を返送し、障害発生通知の受信ノードＮのルートＩＤ復旧処理部１３Ｅにより、上流ノードに対してＢＰＤＵ（Ｐｒ）の送信が開始される。
これにより、通信線Ｌｂの障害復旧を上流ノードで迅速に確認することが可能となる。

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

１…リング型イーサネットシステム、Ｎ，Ｎ１，Ｎ２，Ｎ３，Ｎ４，Ｎ５…ノード、１０…リング接続制御部、１１，１２…ＭＡＣ処理部、１３…ＲＳＴＰ処理部、１３Ａ…第１の障害監視処理部、１３Ｂ…第２の障害監視処理部、１３Ｃ…障害発生受信処理部、１３Ｄ…ルートＩＤ変更処理部、１３Ｅ…ルートＩＤ復旧処理部、１３Ｆ…障害解消処理部、１４…転送処理部、２０…アプリケーション処理部、Ｐ１，Ｐ２…ポート、Ｌ…リング、Ｌａ…通信線（第１の通信線）、Ｌｂ…通信線（第２の通信線）。

Claims (6)

1. 第１および第２の通信線を有する全二重イーサネットからなるリングを介して、複数のノードをリング状に接続することにより、これらノード間のデータ通信を実現するとともに、ＲＳＴＰ（Rapid Spanning Tree Protocol）に基づいて前記リングでの障害発生を監視するリング型イーサネットシステムで用いられるノードであって、
   自ノードに隣接する一方の隣接ノードから前記第１の通信線を介して届く、前記ノードの１つであるルートノードからのヘルスチェックメッセージの正常性に基づいて、当該一方の隣接ノードとの間のセグメントにおける当該第１の通信線での障害有無を監視し、当該障害無の確認に応じて自ノードに隣接する他方の隣接ノードへ前記第１の通信線を介して当該ヘルスチェックメッセージを転送する第１の障害監視処理部と、
   前記障害無の確認に応じて前記一方の隣接ノードへ前記第２の通信線を介して当該ヘルスチェックメッセージに対する応答メッセージを返送し、前記他方の隣接ノードから前記第２の通信線を介して届く前記応答メッセージの正常性に基づいて、当該他方の隣接ノードとの間のセグメントにおける当該第２の通信線での障害有無を監視する第２の障害監視処理部と
   を備えることを特徴とするノード。
2. 請求項１に記載のノードにおいて、
   前記第２の障害監視処理部は、前記他方の隣接ノードとの間のセグメントにおける前記第２の通信線での障害有の確認に応じて、前記他方の隣接ノードへ前記第１の通信線を介して当該障害の発生を通知するための障害発生通知の間欠送信を開始し、
   前記一方の隣接ノードから前記第１の通信線を介して受信した前記障害発生通知に応じて、当該一方の隣接ノードとの間の障害セグメントをブロッキングする処理と、自ノードに対応するルートノードを識別するための新たなルートＩＤとして自ノードＩＤを設定する処理と、当該隣接ノードのルートＩＤを前記新たなルートＩＤへ変更指示するルートＩＤ変更通知を、自ノードに隣接する他方の隣接ノードへ前記第１の通信線を介して送信する処理とを実行する障害発生受信処理部と、
   前記一方の隣接ノードから前記第１の通信線を介して受信した前記ルートＩＤ変更通知に応じて、自ノードに隣接する隣接ノードとの間のセグメントに対する自ノードでのブロッキングを解除する処理と、前記他方の隣接ノードから前記第２の通信線を介して届く前記ヘルスチェックメッセージの正常性が確認されていない場合には、当該ルートＩＤ変更通知で指示された前記新たなルートＩＤへ自ノードのルートＩＤを変更するとともに、前記他方の隣接ノードへ前記第１の通信線を介して当該ルートＩＤ変更通知を転送する処理と、当該ヘルスチェックメッセージの正常性が確認されている場合には、変更前のルートＩＤへの復旧を指示するルートＩＤ復旧通知を当該一方の隣接ノードへ前記第２の通信線を介して返送する処理とを実行するルートＩＤ変更処理部と、
   前記他方の隣接ノードから前記第２の通信線を介して受信した前記ルートＩＤ復旧通知に応じて、自ノードのルートＩＤを変更前のルートＩＤへ復旧する処理と、自ノードが前記障害発生通知の受信ノードでない場合には、前記一方の隣接ノードへ前記第２の通信線を介して当該ルートＩＤ復旧通知を転送する処理と、自ノードが前記障害発生通知の受信ノードである場合には、前記一方の隣接ノードへ前記第２の通信線を介して当該障害の解消を通知するための障害解消通知の間欠送信を開始する処理とを実行するルートＩＤ復旧処理部と
   をさらに備えることを特徴とするノード。
3. 請求項２に記載のノードにおいて、
   前記他方の隣接ノードから前記第２の通信線を介して受信した前記障害解消通知に応じて、当該他方の隣接ノードへ前記第１の通信線を介して自ノードのＭＡＣアドレスを通知する処理と、当該他方の隣接ノードから前記第２の通信線を介して当該他方の隣接ノードのＭＡＣアドレスを取得する処理と、これらＭＡＣアドレスの大小関係に応じたいずれか一方のノードで、当該障害セグメントのブロッキングを行う処理とを実行する障害解消処理部をさらに備えることを特徴とするノード。
4. 第１および第２の通信線を有する全二重イーサネットからなるリングを介して、複数のノードをリング状に接続することにより、これらノード間のデータ通信を実現するとともに、ＲＳＴＰ（Rapid Spanning Tree Protocol）に基づいて前記リングでの障害発生を監視するリング型イーサネットシステムで用いられるネットワーク制御方法であって、
   前記ノードの第１の障害監視処理部が、自ノードに隣接する一方の隣接ノードから前記第１の通信線を介して届く、前記ノードの１つであるルートノードからのヘルスチェックメッセージの正常性に基づいて、当該一方の隣接ノードとの間のセグメントにおける当該第１の通信線での障害有無を監視し、当該障害無の確認に応じて自ノードに隣接する他方の隣接ノードへ前記第１の通信線を介して当該ヘルスチェックメッセージを転送する第１の障害監視ステップと、
   前記ノードの第２の障害監視処理部が、前記障害無の確認に応じて前記一方の隣接ノードへ前記第２の通信線を介して当該ヘルスチェックメッセージに対する応答メッセージを返送し、前記他方の隣接ノードから前記第２の通信線を介して届く前記応答メッセージの正常性に基づいて、当該他方の隣接ノードとの間のセグメントにおける当該第２の通信線での障害有無を監視する第２の障害監視ステップと
   を備えることを特徴とするネットワーク制御方法。
5. 請求項４に記載のネットワーク制御方法において、
   前記第２の障害監視ステップは、前記他方の隣接ノードとの間のセグメントにおける前記第２の通信線での障害有の確認に応じて、前記他方の隣接ノードへ前記第１の通信線を介して当該障害の発生を通知するための障害発生通知の間欠送信を開始するステップを含み、
   前記ノードの障害発生受信処理部が、前記一方の隣接ノードから前記第１の通信線を介して受信した前記障害発生通知に応じて、当該一方の隣接ノードとの間の障害セグメントをブロッキングする処理と、自ノードに対応するルートノードを識別するための新たなルートＩＤとして自ノードＩＤを設定する処理と、当該隣接ノードのルートＩＤを前記新たなルートＩＤへ変更指示するルートＩＤ変更通知を、自ノードに隣接する他方の隣接ノードへ前記第１の通信線を介して送信する処理とを実行する障害発生受信処理ステップと、
   前記ノードのルートＩＤ変更処理部が、前記一方の隣接ノードから前記第１の通信線を介して受信した前記ルートＩＤ変更通知に応じて、自ノードに隣接する隣接ノードとの間のセグメントに対する自ノードでのブロッキングを解除する処理と、前記他方の隣接ノードから前記第２の通信線を介して届く前記ヘルスチェックメッセージの正常性が確認されていない場合には、当該ルートＩＤ変更通知で指示された前記新たなルートＩＤへ自ノードのルートＩＤを変更するとともに、前記他方の隣接ノードへ前記第１の通信線を介して当該ルートＩＤ変更通知を転送する処理と、当該ヘルスチェックメッセージの正常性が確認されている場合には、変更前のルートＩＤへの復旧を指示するルートＩＤ復旧通知を当該一方の隣接ノードへ前記第２の通信線を介して返送する処理とを実行するルートＩＤ変更処理ステップと、
   前記ノードのルートＩＤ復旧処理部が、前記他方の隣接ノードから前記第２の通信線を介して受信した前記ルートＩＤ復旧通知に応じて、自ノードのルートＩＤを変更前のルートＩＤへ復旧する処理と、自ノードが前記障害発生通知の受信ノードでない場合には、前記一方の隣接ノードへ前記第２の通信線を介して当該ルートＩＤ復旧通知を転送する処理と、自ノードが前記障害発生通知の受信ノードである場合には、前記一方の隣接ノードへ前記第２の通信線を介して当該障害の解消を通知するための障害解消通知の間欠送信を開始する処理とを実行するルートＩＤ復旧処理ステップと
   をさらに備えることを特徴とするネットワーク制御方法。
6. 請求項５に記載のネットワーク制御方法において、
   前記ノードの障害解消処理部が、前記他方の隣接ノードから前記第２の通信線を介して受信した前記障害解消通知に応じて、当該他方の隣接ノードへ前記第１の通信線を介して自ノードのＭＡＣアドレスを通知する処理と、当該他方の隣接ノードから前記第２の通信線を介して当該他方の隣接ノードのＭＡＣアドレスを取得する処理と、これらＭＡＣアドレスの大小関係に応じたいずれか一方のノードで、当該障害セグメントのブロッキングを行う処理とを実行する障害解消処理ステップをさらに備えることを特徴とするネットワーク制御方法。

Images