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

ノードおよびネットワーク制御方法 Download PDF

Info

Publication number
JP5167183B2
JP5167183B2 JP2009075829A JP2009075829A JP5167183B2 JP 5167183 B2 JP5167183 B2 JP 5167183B2 JP 2009075829 A JP2009075829 A JP 2009075829A JP 2009075829 A JP2009075829 A JP 2009075829A JP 5167183 B2 JP5167183 B2 JP 5167183B2
Authority
JP
Japan
Prior art keywords
node
failure
route
communication line
adjacent
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.)
Active
Application number
JP2009075829A
Other languages
English (en)
Other versions
JP2010232785A (ja
Inventor
偉 蒋
淳 清田
英樹 田代
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Azbil Corp
Original Assignee
Azbil Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Azbil Corp filed Critical Azbil Corp
Priority to JP2009075829A priority Critical patent/JP5167183B2/ja
Publication of JP2010232785A publication Critical patent/JP2010232785A/ja
Application granted granted Critical
Publication of JP5167183B2 publication Critical patent/JP5167183B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Small-Scale Networks (AREA)

Description

本発明は、イーサネット(登録商標)通信技術に関し、特に全二重イーサネットを用いたリング型イーサネット通信技術に関する。
ビル設備やプラント設備を監視制御する監視制御システムでは、情報収集機能や制御機能などの各種機能を有する通信機器をノードとして通信ネットワークを介して接続し、これらノードからの情報に基づき中央監視装置で個々の設備を監視制御するものとなっている。このような監視制御システムでは、通信ネットワークとしてイーサネットが用いられている。
イーサネットでは、複数のノードを接続する際、ハブやスイッチに各ノードをそれぞれ接続するスター配線方式が基本である。このようなスター配線方式は、比較的規模の小さいオフィス環境には適合するものの、ビル設備やプラント設備などの大規模な設備には必ずしも適合しない。その理由としては、スター配線方式では、ハブやスイッチと各ノードとをそれぞれ個別の配線を介して接続する必要があり、広範囲にわたってノードが設置されている場合には、ノード間を結ぶ配線が複雑化し、配線工事やメンテナンスの作業負担が増大するからである。
このようなイーサネットにおいて、各ノードをリング状に接続するリング型イーサネットが提案されている(例えば、特許文献1など参照)。このリング型イーサネットは、通信経路内に存在するリングトポロジーによる通信エラーを回避するSTP(Spanning Tree Protocol/IEEE 802.1D)機能や、これを改良したRSTP(Rapid Spanning Tree Protocol/IEEE 802.1w)機能などのネットワーク制御機能を用いて、システムの冗長化を実現することが可能となる。
図11は、典型的なリング型イーサネットシステムの構成例である。ここでは、5つのノードN1〜N5がリングでリング接続されており、ノード4のうちノード3側のポートでブロッキングが行われている。
このブロッキングにより、リングトポロジーからなる元のリングから、ルートノードN1からノードN2→ノードN3およびノードN5→ノードN4までの2つの枝経路を持つツリートポロジーが構築される。これにより、物理的にリングトポロジーを形成しているネットワークであっても、データループの発生が回避される。
このようなリング型イーサネットシステムでは、ルートノードと他のノードとの間でBPDU(Bridge Protocol Data Unit)と呼ばれるネットワーク制御情報のうち、Forwardingと呼ばれるBPDUをやり取りすることにより、リングでの障害発生を監視している。
図11の場合、ルートノードN1からノードN2方向とノードN5方向の2方向へForwarding BPDUが定期的に送信される。各ノードN2〜N5は、ルートノードN1からのForwarding BPDUを正常に受信した場合、後続のノードへ転送する。したがって、Forwarding BPDUが正常に受信できない場合、ルートノードN1側に隣接するノードとの間のセグメントで障害が発生したことが確認できる。
特開2005−109846号公報
このような従来技術では、リング型イーサネットシステムのリングとして全二重イーサネットを使用している場合、各ノード間のセグメントは、送信と受信とで異なる通信線を用いることになる。したがって、障害監視用のForwarding BPDUは、各セグメントのうちいずれか一方の通信線を介して転送されるため、他方の通信線については障害を監視できないという問題点があった。
図12は、全二重イーサネット対応のノードの要部構成を示すブロック図である。
全二重イーサネット通信では、隣接ノード間でデータ送受信を並列的に実行するため、ノードを接続するリングLには2つの独立した通信線La,Lbが設けられているとともに、各ノードにおいてリングLが接続される2つのポートP1,P2のそれぞれに、受信系と送信系が独立して構成されている。
ノードN2のRSTP処理部13がノードN3へForwarding BPDUを送信する場合、ノードN2において、MAC処理部12→ポートP2(物理層の送信回路→トランスの送信コイル→コネクタの送信ピン)を経由して通信線Laへ出力される。一方、ノードN3では、通信線LaからのForwarding BPDUを、ポートP1(コネクタの受信ピン→トランスの受信コイル→物理層の受信回路)→MAC処理部11を経由してRSTP処理部13で受信される。これにより、ノードN2,N3間のセグメントのうち一方の通信線Laに関する経路について、障害の有無が確認されることになる。
しかしながら、Forwarding BPDUは、通信線Laに関する経路しか通過していないことから、ノードN2,N3間のセグメントのうち通信線Lbに関する経路、すなわちノードN3のMAC処理部11→ポートP1(物理層の送信回路→トランスの送信コイル→コネクタの送信ピン)→通信線Lb→ポートP2(コネクタの受信ピン→トランスの受信コイル→物理層の受信回路)→MAC処理部12という経路については、障害を監視していないことになる。
本発明はこのような課題を解決するためのものであり、ノードを接続するリングとして全二重イーサネットを用いた場合でも、セグメントごとに両方の通信線について障害を監視できるリング型イーサネット制御技術を提供することを目的としている。
このような目的を達成するために、本発明にかかるノードは、第1および第2の通信線を有する全二重イーサネットからなるリングを介して、複数のノードをリング状に接続することにより、これらノード間のデータ通信を実現するとともに、RSTP(Rapid Spanning Tree Protocol)に基づいて、任意のノードで通信をブロッキングしてルートノードから2つの枝経路で通信を行い、通信の障害発生時には、障害検出ノードに当該ブロッキングを変更して構築したバックアップ系通信経路を用いて通信することで、リングでの障害発生を監視するリング型イーサネットシステムで用いられるノードであって、自ノードに隣接する一方の隣接ノードから第1の通信線を介して届く、ノードの1つであるルートノードからのヘルスチェックメッセージの正常性に基づいて、当該一方の隣接ノードとの間のセグメントにおける当該第1の通信線での障害有無を監視し、当該障害無の確認に応じて自ノードに隣接する他方の隣接ノードへ第1の通信線を介して当該ヘルスチェックメッセージを転送する第1の障害監視処理部と、障害無の確認に応じて一方の隣接ノードへ第2の通信線を介して当該ヘルスチェックメッセージに対する応答メッセージを返送し、他方の隣接ノードから第2の通信線を介して届く応答メッセージの正常性に基づいて、当該他方の隣接ノードとの間のセグメントにおける当該第2の通信線での障害有無を監視し、前記他方の隣接ノードとの間のセグメントにおける前記第2の通信線での障害有の確認に応じて、前記他方の隣接ノードへ前記第1の通信線を介して当該障害の発生を通知するための障害発生通知の間欠送信を開始する第2の障害監視処理部とを備えている。
これに加えて、一方の隣接ノードから第1の通信線を介して受信した障害発生通知に応じて、当該一方の隣接ノードとの間の障害セグメントをブロッキングする処理と、自ノードに対応するルートノードを識別するための新たなルートIDとして自ノードIDを設定する処理と、当該隣接ノードのルートIDを新たなルートIDへ変更指示するルートID変更通知を、自ノードに隣接する他方の隣接ノードへ第1の通信線を介して送信する処理とを実行する障害発生受信処理部と、一方の隣接ノードから第1の通信線を介して受信したルートID変更通知に応じて、自ノードに隣接する隣接ノードとの間のセグメントに対する自ノードでのブロッキングがある場合には、当該ブロッキングを解除する処理と、他方の隣接ノードから第2の通信線を介して届くヘルスチェックメッセージの正常性が確認されていない場合には、当該ルートID変更通知で指示された新たなルートIDへ自ノードのルートIDを変更するとともに、他方の隣接ノードへ第1の通信線を介して当該ルートID変更通知を転送する処理と、当該ヘルスチェックメッセージの正常性が確認されている場合には、変更前のルートIDへの復旧を指示するルートID復旧通知を当該一方の隣接ノードへ第2の通信線を介して返送する処理とを実行するルートID変更処理部と、他方の隣接ノードから第2の通信線を介して受信したルートID復旧通知に応じて、自ノードのルートIDを変更前のルートIDへ復旧する処理と、自ノードが障害発生通知の受信ノードでない場合には、一方の隣接ノードへ第2の通信線を介して当該ルートID復旧通知を転送する処理と、自ノードが障害発生通知の受信ノードである場合には、一方の隣接ノードへ第2の通信線を介して当該障害の解消を通知するための障害解消通知の間欠送信を開始する処理とを実行するルートID復旧処理部とをさらに備えている
また、他方の隣接ノードから第2の通信線を介して受信した障害解消通知に応じて、当該他方の隣接ノードへ第1の通信線を介して自ノードのMACアドレスを通知する処理と、当該他方の隣接ノードから第2の通信線を介して当該他方の隣接ノードのMACアドレスを取得する処理と、これらMACアドレスの大小関係に応じたいずれか一方のノードで、当該障害セグメントのブロッキングを行う処理とを実行する障害解消処理部をさらに備えてもよい。
また、本発明にかかるネットワーク制御方法は、第1および第2の通信線を有する全二重イーサネットからなるリングを介して、複数のノードをリング状に接続することにより、これらノード間のデータ通信を実現するとともに、RSTP(Rapid Spanning Tree Protocol)に基づいて、任意のノードで通信をブロッキングしてルートノードから2つの枝経路で通信を行い、通信の障害発生時には、障害検出ノードに当該ブロッキングを変更して構築したバックアップ系通信経路を用いて通信することで、リングでの障害発生を監視するリング型イーサネットシステムで用いられるネットワーク制御方法であって、ノードの第1の障害監視処理部が、自ノードに隣接する一方の隣接ノードから第1の通信線を介して届く、ノードの1つであるルートノードからのヘルスチェックメッセージの正常性に基づいて、当該一方の隣接ノードとの間のセグメントにおける当該第1の通信線での障害有無を監視し、当該障害無の確認に応じて自ノードに隣接する他方の隣接ノードへ第1の通信線を介して当該ヘルスチェックメッセージを転送する第1の障害監視ステップと、ノードの第2の障害監視処理部が、障害無の確認に応じて一方の隣接ノードへ第2の通信線を介して当該ヘルスチェックメッセージに対する応答メッセージを返送し、他方の隣接ノードから第2の通信線を介して届く応答メッセージの正常性に基づいて、当該他方の隣接ノードとの間のセグメントにおける当該第2の通信線での障害有無を監視し、他方の隣接ノードとの間のセグメントにおける第2の通信線での障害有の確認に応じて、他方の隣接ノードへ第1の通信線を介して当該障害の発生を通知するための障害発生通知の間欠送信を開始する第2の障害監視ステップとを備えている。
これに加えて、一方の隣接ノードから第1の通信線を介して受信した障害発生通知に応じて、当該一方の隣接ノードとの間の障害セグメントをブロッキングする処理と、自ノードに対応するルートノードを識別するための新たなルートIDとして自ノードIDを設定する処理と、当該隣接ノードのルートIDを新たなルートIDへ変更指示するルートID変更通知を、自ノードに隣接する他方の隣接ノードへ第1の通信線を介して送信する処理とを実行する障害発生受信処理ステップと、ノードのルートID変更処理部が、一方の隣接ノードから第1の通信線を介して受信したルートID変更通知に応じて、自ノードに隣接する隣接ノードとの間のセグメントに対する自ノードでのブロッキングがある場合には、当該ブロッキングを解除する処理と、他方の隣接ノードから第2の通信線を介して届くヘルスチェックメッセージの正常性が確認されていない場合には、当該ルートID変更通知で指示された新たなルートIDへ自ノードのルートIDを変更するとともに、他方の隣接ノードへ第1の通信線を介して当該ルートID変更通知を転送する処理と、当該ヘルスチェックメッセージの正常性が確認されている場合には、変更前のルートIDへの復旧を指示するルートID復旧通知を当該一方の隣接ノードへ第2の通信線を介して返送する処理とを実行するルートID変更処理ステップと、ノードのルートID復旧処理部が、他方の隣接ノードから第2の通信線を介して受信したルートID復旧通知に応じて、自ノードのルートIDを変更前のルートIDへ復旧する処理と、自ノードが障害発生通知の受信ノードでない場合には、一方の隣接ノードへ第2の通信線を介して当該ルートID復旧通知を転送する処理と、自ノードが障害発生通知の受信ノードである場合には、一方の隣接ノードへ第2の通信線を介して当該障害の解消を通知するための障害解消通知の間欠送信を開始する処理とを実行するルートID復旧処理ステップとをさらに備えている
また、ノードの障害解消処理部が、他方の隣接ノードから第2の通信線を介して受信した障害解消通知に応じて、当該他方の隣接ノードへ第1の通信線を介して自ノードのMACアドレスを通知する処理と、当該他方の隣接ノードから第2の通信線を介して当該他方の隣接ノードのMACアドレスを取得する処理と、これらMACアドレスの大小関係に応じたいずれか一方のノードで、当該障害セグメントのブロッキングを行う処理とを実行する障害解消処理ステップをさらに備えてもよい。
本発明によれば、ノードを接続するリングとして全二重イーサネットを用いた場合でも、上流ノードから届くヘルスチェックメッセージに基づき上流セグメントの第1の通信線での障害有無を監視できるとともに、下流ノードから届くヘルスチェックメッセージに対する応答メッセージに基づき下流セグメントの第2の通信線での障害有無を監視することが可能となる。
本実施の形態にかかるノードの要部構成を示すブロック図である。 本実施の形態にかかるリング型イーサネットシステムの構成例である。 第1の障害監視処理を示すフローチャートである。 第2の障害監視処理を示すフローチャートである。 障害発生受信処理を示すフローチャートである。 ルートID変更処理を示すフローチャートである。 ルートID復旧処理を示すフローチャートである。 障害解消処理を示すフローチャートである。 第2の障害監視処理(正常時)を示す説明図である。 第2の障害監視処理(障害発生時)を示す説明図である。 ルートID変更処理を示す説明図である。 ルートID復旧処理(ルートID復旧)を示す説明図である。 ルートID復旧処理(障害解消通知)を示す説明図である。 障害解消処理(障害解消時)を示す説明図である。 障害解消処理(ハンドシェーク)を示す説明図である。 障害解消処理(ブロッキング)を示す説明図である。 典型的なリング型イーサネットシステムの構成例である。 全二重イーサネット対応のノードの要部構成を示すブロック図である。
次に、本発明の一実施の形態について図面を参照して説明する。
[本実施の形態の構成]
まず、図1を参照して、本実施の形態にかかるノードについて説明する。図1は、本実施の形態にかかるノードの要部構成を示すブロック図である。
このノードNは、RSTP(Rapid Spanning Tree Protocol)に基づいて、リングLに対する冗長化制御処理を行うリング型イーサネットシステム1で用いられるデータ通信用のノードである。このリングLは、全二重イーサネットからなるリング状の通信経路であり、各ノードN間でデータ送受信を並列的に実行するため、リングLには2つの独立した通信線La,Lbが設けられている。
ノードNには、主な機能部として、リング接続制御部10とアプリケーション処理部20とが設けられている。
リング接続制御部10は、リングLを介して他のノードNとの間のデータ通信(イーサネット準拠)を制御する機能を有している。
アプリケーション処理部20は、リング接続制御部10を介して他のノードNとの全二重イーサネット通信により、例えばビル設備やプラント設備を監視制御するための各種アプリケーション処理を行う機能を有している。
リング接続制御部10には、主な処理部として、MAC処理部11,12、RSTP処理部13、および転送処理部14が設けられている。
MAC処理部11は、リング接続用のポートP1を介してリングLの一端L1と接続し、各ノードNとの間でMACフレームを送受信する機能と、自ノードのポートのいずれか一方による特定のMACフレームの送受信を規制するブロッキングを行う機能と、冗長化制御処理用の制御情報を含むMACフレームをRSTP処理部13へ出力する機能とを有している。
MAC処理部12は、リング接続用のポートP2を介してリングLの他端L2と接続し、各ノードNとの間でMACフレームを送受信する機能と、自ノードのポートのいずれか一方による特定のMACフレームの送受信を規制するブロッキングを行う機能と、冗長化制御処理用の制御情報を含むMACフレームをRSTP処理部13へ出力する機能とを有している。
RSTP処理部13は、MAC処理部11,12とそれぞれ接続し、RSTPに基づいてリングLに対する冗長化制御処理を行う機能を有している。
RSTP処理部13には、主な処理部として、第1の障害監視処理部13A、第2の障害監視処理部13B、障害発生受信処理部13C、ルートID変更処理部13D、ルートID復旧処理部13E、および障害解消処理部13Fが設けられている。
第1の障害監視処理部13Aは、自ノードに隣接する一方の隣接ノードから第1の通信線を介して届くルートノードからのヘルスチェックメッセージの正常性に基づいて、当該一方の隣接ノードとの間のセグメントにおける当該第1の通信線での障害有無を監視する機能と、当該障害無の確認に応じて自ノードに隣接する他方の隣接ノードへ第1の通信線を介して当該ヘルスチェックメッセージを転送する機能とを有している。
第2の障害監視処理部13Bは、第1の障害監視処理部13Aによる当該一方の隣接ノードとの間のセグメントにおける当該第1の通信線での障害無の確認に応じて、一方の隣接ノードへ第2の通信線を介して当該ヘルスチェックメッセージに対する応答メッセージを返送する機能と、他方の隣接ノードから第2の通信線を介して届く応答メッセージの正常性に基づいて、当該他方の隣接ノードとの間のセグメントにおける当該第2の通信線での障害有無を監視する機能と、他方の隣接ノードとの間のセグメントにおける第2の通信線での障害有の確認に応じて、他方の隣接ノードへ第1の通信線を介して当該障害の発生を通知するための障害発生通知の間欠送信を開始する機能とを有している。
障害発生受信処理部13Cは、一方の隣接ノードから第1の通信線を介して受信した障害発生通知に応じて、当該一方の隣接ノードとの間の障害セグメントをブロッキングする処理と、自ノードに対応するルートノードを識別するための新たなルートIDとして自ノードIDを設定する処理と、当該隣接ノードのルートIDを新たなルートIDへ変更指示するルートID変更通知を、自ノードに隣接する他方の隣接ノードへ第1の通信線を介して送信する処理とを実行する機能を有している。
ルートID変更処理部13Dは、一方の隣接ノードから第1の通信線を介して受信したルートID変更通知に応じて、自ノードに隣接する隣接ノードとの間のセグメントに対する自ノードでのブロッキングを解除する処理と、他方の隣接ノードから第2の通信線を介して届くヘルスチェックメッセージの正常性が確認されていない場合には、当該ルートID変更通知で指示された新たなルートIDへ自ノードのルートIDを変更するとともに、他方の隣接ノードへ第1の通信線を介して当該ルートID変更通知を転送する処理と、当該ヘルスチェックメッセージの正常性が確認されている場合には、変更前のルートIDへの復旧を指示するルートID復旧通知を当該一方の隣接ノードへ第2の通信線を介して返送する処理とを実行する機能とを有している。
ルートID復旧処理部13Eは、他方の隣接ノードから第2の通信線を介して受信したルートID復旧通知に応じて、自ノードのルートIDを変更前のルートIDへ復旧する処理と、自ノードが障害発生通知の受信ノードでない場合には、一方の隣接ノードへ第2の通信線を介して当該ルートID復旧通知を転送する処理と、自ノードが障害発生通知の受信ノードである場合には、一方の隣接ノードへ第2の通信線を介して当該障害の解消を通知するための障害解消通知の間欠送信を開始する処理とを実行する機能を有している。
障害解消処理部13Fは、他方の隣接ノードから第2の通信線を介して受信した障害解消通知に応じて、当該他方の隣接ノードへ第1の通信線を介して自ノードのMACアドレスを通知する処理と、当該他方の隣接ノードから第2の通信線を介して当該他方の隣接ノードのMACアドレスを取得する処理と、これらMACアドレスの大小関係に応じたいずれか一方のノードで、当該障害セグメントのブロッキングを行う処理とを実行する機能を有している。
ノードN間でやり取りするヘルスチェックメッセージ、応答メッセージ、および障害解消通知については、それぞれRSTPで用いるForwarding BPDU、Agree BPDU、およびPropose BPDUを利用してもよい。また、ルートID変更通知、ルートID復旧通知、MACアドレスをやり取りについても、ノードN間で定期的に送受信するBPDUを用いて通知してもよい。
図2は、本実施の形態にかかるリング型イーサネットシステムの構成例である。ここでは、前述した図1の構成を有する5つのノードN1〜N5が、リングL(通信経路)を介してノードN1〜N5の順に接続されている。これらノードN1〜N5には、データ通信用のアドレスとして、それぞれのノードに固有のMACアドレス「1」〜「5」が予め設定されている。
また、RSTP機能のイニシャル処理により、これらノードN1〜N5のうちノートN1が、冗長化制御処理を行うルートノードとして選択されており、各ノードN1〜N5には、このルートノードを識別するためのルートIDとして、ノードN1のMACアドレス「1」が設定されている。
また、RSTP機能のイニシャル処理により、ルートノードN1と他のノードN2〜N5との間でBPDUと呼ばれるネットワーク制御情報をやり取りすることにより、例えばノード間のコストやノードの優先順位に基づいてツリートポロジーの現用系通信経路を設定する。
図2の例では、ノードN3,N4の間を結ぶセグメントのコストが最大となり、このセグメントに接続されるノードN3,N4のうちMACアドレスの大きいノードN4のポートでブロッキングされている。
したがって、このリング型イーサネットシステム1は、リングLで各ノードN1〜N5が物理的に接続されているものの、現用系通信経路としては、ルートノードN1に対してノードN2,N3を接続する経路と、ルートノードN1からノードN4,N5を接続する経路の2の枝経路を持つツリートポロジーを持つことになる。また、ブロッキングされているノードN3,N4間のセグメントについては、常にデータ通信可能な状態にあり、他のセグメントでの障害発生時にブロッキングが解除されて、バックアップ系通信経路として用いられる。
[本実施の形態の動作]
次に、図3〜図8を参照して、本実施の形態にかかるノードの動作について説明する。図3は、第1の障害監視処理を示すフローチャートである。図4は、第2の障害監視処理を示すフローチャートである。図5は、障害発生受信処理を示すフローチャートである。図6は、ルートID変更処理を示すフローチャートである。図7は、ルートID復旧処理を示すフローチャートである。図8は、障害解消処理を示すフローチャートである。
ここでは、本実施の形態にかかるノードの主な動作として、第1の障害監視処理、第2の障害監視処理、障害発生受信処理、ルートID変更処理、ルートID復旧処理、および障害解消処理のそれぞれについて順に説明する。
なお、以下では、便宜上、自ノードに対してルートノードN1側に隣接する一方の隣接ノードを上流ノードと呼び、自ノードに対してルートノードN1とは反対側に隣接する他方の隣接ノードを下流ノードと呼ぶ。
また、ここでは、上記各処理の主体となるノードが、図2のノードN2のように、リングLのうち通信線La(第1の通信線)を介してヘルスチェックメッセージを受信し、これに対する応答メッセージを通信線Lb(第2の通信線)を介して返送する場合を例として説明する。なお、ノードN5のように、通信線Lbを介してヘルスチェックメッセージについては、例えば通信線Laと通信線Lbや上流と下流を相互に読み替えればよい。
また、ノードN間でやり取りするヘルスチェックメッセージ、応答メッセージ、および障害解消通知については、それぞれRSTPのForwarding BPDU、Agree BPDU、およびPropose BPDUを利用するものとする。なお、Forwarding BPDU、Agree BPDU、およびPropose BPDUは、BPDU(Fd)、BPDU(Ag)、およびBPDU(Pr)と略す。
[第1の障害監視処理]
まず、図3を参照して、本実施の形態にかかるノードの第1の障害監視処理について説明する。
図2のリング型イーサネットシステム1では、ルートノードN1のRSTP処理部13において、RSTP機能に基づく冗長化制御処理が行われており、リングの正常性確認を目的として、ルートノードN1から定期的にヘルスチェックメッセージとしてBPDU(Fd)が送信されている。特に、図2では、ノードN4のノードN3側ポートでブロッキングが行われていることから、ルートノードN1からノードN2とノードN5の2つの枝経路へ並行してBPDU(Fd)が送信され、ノードN2でBPDU(Fd)が中継転送されてノードN3まで送信され、ノードN5でBPDU(Fd)が中継転送されてノードN4まで送信される。
ルートノードN1以外の各ノードN2〜N5のRSTP処理部13は、第1の障害監視処理部13Aにより、常時、図3に示す第1の障害監視処理を実行して、上流ノードから、当該上流ノードとの間の上流セグメントのうち通信線Laを介して届くBPDU(Fd)の正常性を監視することにより、当該通信線Laの障害有無を監視している。
第1の障害監視処理部13Aは、まず、BPDU(Fd)の正規受信タイミング、例えば前回受信したBPDU(Fd)から正規受信間隔だけ経過した受信タイミングに応じて、上流ノードから通信線Laを介して届くBPDU(Fd)の受信を待機し(ステップ100)、BPDU(Fd)の受信タイミングやBPDU(Fd)に含まれるデータの整合性を検査することによりBPDU(Fd)の正常性を確認する(ステップ101)。
ここで、BPDU(Fd)の正常性を確認した場合(ステップ101:YES)、第1の障害監視処理部13Aは、上流セグメントの通信線Laについて障害無と判定し(ステップ102)、下流ノードへ通信線Laを介して当該BPDU(Fd)を転送し(ステップ103)、ステップ100へ戻る。
一方、上流セグメントの通信線Laで障害が発生して、上流ノードからのBPDU(Fd)の正常受信を確認できなかった場合(ステップ101:NO)、第1の障害監視処理部13Aは、上流セグメントの通信線Laについて障害有と判定し(ステップ104)、ステップ100へ戻る。
[第2の障害監視処理]
次に、図4を参照して、本実施の形態にかかるノードの第2の障害監視処理について説明する。
図3のステップ102において、上流セグメントの通信線Laについて障害無と判定した場合、ノードNの第2の障害監視処理部13Bは、図4の第2の障害監視処理を実行する。
第2の障害監視処理部13Bは、まず、上流ノードに対して上流セグメントの通信線Lbを介して、上流ノードから正常受信したBPDU(Fd)に対する応答メッセージを返送する(ステップ110)。
続いて、第2の障害監視処理部13Bは、下流ノードへ転送したBPDU(Fd)に対応するBPDU(Ag)の正規受信タイミング、例えば直前に送信したBPDU(Fd)から正規応答期間内を示す受信タイミングに応じて、下流ノードから通信線Lbを介して届くBPDU(Ag)の受信を待機し(ステップ111)、BPDU(Ag)の受信タイミングやBPDU(Ag)に含まれるデータの整合性を検査することによりBPDU(Ag)の正常性を確認する(ステップ112)。
ここで、BPDU(Ag)の正常性を確認した場合(ステップ112:YES)、第2の障害監視処理部13Bは、下流セグメントの通信線Lbについて障害無と判定し(ステップ113)、一連の第2の障害監視処理を終了する。
一方、下流セグメントの通信線Lbで障害が発生して、下流ノードからのBPDU(Ag)の正常受信を確認できなかった場合(ステップ112:NO)、第2の障害監視処理部13Bは、下流セグメントの通信線Lbについて障害有と判定し(ステップ114)、下流ノードへ下流セグメントの通信線Laを介して当該障害の発生を通知するための障害発生通知の間欠送信を開始し(ステップ115)、一連の第2の障害監視処理を終了する。この障害発生通知の間欠送信は、障害が解消されるまで継続される。
[障害発生受信処理]
次に、図5を参照して、本実施の形態にかかるノードの障害発生受信処理について説明する。
ルートノードN1以外の各ノードN2〜N5のRSTP処理部13は、図4のステップ115において間欠送信が開始された障害発生通知を、上流ノードから通信線Laを介して受信した場合、障害発生受信処理部13Cにより、図5の障害発生受信処理を実行する。
障害発生受信処理部13Cは、まず、障害発生通知を受信した上流セグメントをブロッキングし(ステップ120)、自ノードのMACアドレスを記憶部(図示せず)から読み出し、自ノードのMACアドレスを新たなルートIDとして記憶部へ設定する(ステップ121)。この際、自ノードが障害発生通知を受信したノードである旨を記憶部へ記録しておく。
続いて、障害発生受信処理部13Cは、当該隣接ノードのルートIDを、障害発生を検出した自ノードのMACアドレスからなる新たなルートIDへ変更する指示を含むルートID変更通知を、通信線Laを介して下流ノードへ送信し(ステップ122)、一連の障害発生受信処理を終了する。
[ルートID変更処理]
次に、図6を参照して、本実施の形態にかかるノードのルートID変更処理について説明する。
ルートノードN1以外の各ノードN2〜N5のRSTP処理部13は、上流ノードから通信線Laを介してルートID変更通知を受信した場合、ルートID変更処理部13Dにより、図6のルートID変更処理を実行する。
ルートID変更処理部13Dは、まず、自ノードのポートP1,P2のいずれかでブロッキングを行っているか確認し(ステップ130)、ブロッキングを行っている場合には(ステップ130:YES)、そのブロッキングを解除して(ステップ131)、ステップ132へ移行し、ブロッキングを行っていない場合には(ステップ130:NO)、直ちにステップ132へ移行する。
続いて、ルートID変更処理部13Dは、下流ノードから通信線Lbを介して、ルートノードN1からのBPDU(Fd)を正常受信しているか確認する(ステップ132)。
ここで、BPDU(Fd)を正常受信していない場合(ステップ132:NO)、ルートID変更処理部13Dは、受信したルートID変更通知で指定された新たなルートIDを、自ノードのルートIDとして記憶部に設定し(ステップ133)、当該ルートID変更通知を下流ノードへ通信線Laを介して転送し(ステップ134)、一連のルートID変更処理を終了する。
一方、ルートノードN1からのBPDU(Fd)を正常受信している場合(ステップ132:YES)、ルートID変更処理部13Dは、上流ノードのルートIDを元のルートノードN1のMACアドレスからなる元のルートIDへの復旧指示を含むルートID復旧通知を、当該ルートID変更通知を受信した隣接ノードへ送信し(ステップ135)、一連のルートID変更処理を終了する。
[ルートID復旧処理]
次に、図7を参照して、本実施の形態にかかるノードのルートID復旧処理について説明する。
ルートノードN1以外の各ノードN2〜N5のRSTP処理部13は、下流ノードから通信線Lbを介してルートID復旧通知を受信した場合、ルートID復旧処理部13Eにより、図7のルートID復旧処理を実行する。
ルートID復旧処理部13Eは、受信したルートID復旧通知で指定された元のルートノードN1のルートIDを、自ノードのルートIDとして記憶部に設定する(ステップ140)。この際、ルートID復旧通知に元のルートIDを含めて通知してもよく、各ノードで保存しておいた直前のルートIDを復旧させてもよい。
続いて、ルートID復旧処理部13Eは、記憶部を参照して、自ノードが障害発生通知の受信ノードかどうか確認する(ステップ141)。
ここで、自ノードが障害発生通知の受信ノードでない場合(ステップ141:NO)、ルートID復旧処理部13Eは、上流ノードへ通信線Lbを介して当該ルートID復旧通知を転送し(ステップ142)、一連のルートID変更処理を終了する。
一方、自ノードが障害発生通知の受信ノードであった場合(ステップ141:YES)、ルートID復旧処理部13Eは、上流ノードへ通信線Lbを介して当該障害の解消を通知するためのBPDU(Pr)の間欠送信を開始し(ステップ143)、一連のルートID変更処理を終了する。このBPDU(Pr)の間欠送信は、障害が解消されるまで継続される。
[障害解消処理]
次に、図8を参照して、本実施の形態にかかるノードの障害解消処理について説明する。
ルートノードN1およびノードN2〜N5のRSTP処理部13は、図7のステップ143において間欠送信が開始されたBPDU(Pr)を、下流ノードから通信線Lbを介して受信した場合、下流セグメントで発生していた障害が解消されて下流ノードとの間でデータ通信が可能となったと判定し、当該障害解消セグメントの両端に接続されている各ノードNのRSTP処理部13で、障害発生通知およびBPDU(Pr)の間欠送信を互いに停止して、障害解消処理部13Fにより、図8の障害解消処理を実行する。
障害解消処理部13Fは、まず、当該隣接ノードとの間で相互にルートIDと自ノードのMACアドレスをやり取りする(ステップ150)。ここで、両ルートIDがともにルートノードN1を示す「1」であり、両ルートIDが一致することから、当該セグメントの接続により、リングがループ状に接続されるため、ブロッキングが必要となる。
したがって、障害解消処理部13Fは、ブロッキングの位置を決定するため、自MACアドレスと相手MACアドレスとを大小比較する(ステップ151)。
ここで、自MACアドレスが相手MACアドレスより大きい場合(ステップ151:YES)、障害が解消されたセグメントを接続しているポートP1,P2のいずれかでブロッキングを行い(ステップ152)、一連の障害解消処理を終了する。
一方、自MACアドレスが相手MACアドレスより小さい場合(ステップ151:NO)、相手ノードでブロッキングが行われるため、障害解消処理部13Fは、直ちに一連の障害解消処理を終了する。なお、両ルートIDが一致しない場合、ブロッキングは不要となる。
[動作例]
次に、本実施の形態にかかるノードおよびリング型イーサネットシステムの動作例について説明する。ここでは、前述した図2のリング型イーサネットシステム1において、ルートノードN2とノードN3の間のセグメントで障害が発生した場合の障害発生動作、およびルートノードN2とノードN3の間のセグメントで発生した障害が解消された場合の障害解消動作について、それぞれ説明する。
[障害発生動作]
まず、図9A〜図9Eを参照して、障害発生動作について説明する。図9Aは、第2の障害監視処理(正常時)を示す説明図である。図9Bは、第2の障害監視処理(障害発生時)を示す説明図である。図9Cは、ルートID変更処理を示す説明図である。図9Dは、ルートID復旧処理(ルートID復旧)を示す説明図である。図9Eは、ルートID復旧処理(障害解消通知)を示す説明図である。
前述した図2のリング型イーサネットシステム1において、いずれのセグメントにも障害が発生していない場合、ノードN2〜N5は、ルートノードN1から送信されたBPDU(Fd)を受信した際、前述した図4の第2の障害監視処理により、図9Aに示すように、それぞれの上流ノードに対してBPDU(Ag)を返送する。ルートノードN1およびノードN2,N5は、それぞれの下流ノードから届くBPDU(Ag)の正常性に基づいて、下流セグメントの通信線Lb(La)での障害有無を監視する。
ここで、図9Bに示すように、ノードN2とノードN3の間のセグメントで障害が発生した場合、ルートノードN1から送信していたBPDU(Fd)がノードN2からN3へ届かなくなる。
これに応じて、ノードN2は、前述した図4の第2の障害監視処理により、ノードN3との間のセグメントでの障害発生を検出し、図9Bに示すように、下流ノードN3へ通信線Laを介して障害発生通知の送信を開始する。
一方、ノードN3は、上流ノードN2から通信線Laを介して障害発生通知を受信した場合、前述した図5の障害発生受信処理を実行し、図9Cに示すように、ノードN2側のポートでブロッキングを設定する。
続いて、ノードN3は、自MACアドレス「3」を自ノードN3のルートIDとして設定するとともに、下流ノードN4へルートID変更通知を送信する。これにより、ノードN3からノードN4に対してルートID変更通知が転送される。
ノードN4では、ルートID変更通知の受信に応じて、前述した図4のルートID変更処理を実行し、図9Dに示すように、ブロッキングを解除する。この場合、ノードN4は、ノードN5を介してルートノードN1からBPDU(Fd)を正常受信しているので、ルートID復旧通知を上流ノードN3へ返送する。
これに応じて、ノードN3は、ルートID復旧通知の受信に応じて、前述した図7のルートID復旧処理を実行し、自ノードN3のルートIDを元のルートノードN1に復旧する。この場合、自ノードが障害発生受信ノードであることから、図9Eに示すように、上流ノードN2へ通信線Lbを介してBPDU(Pr)の送信を開始する。
このように、ノードN2〜N5において、ルートノードN1からのBPDU(Fd)の受信に応じて上流ノードへ通信線Lbを介してBPDU(Ag)を返送するようにしたので、下流ノードから届くBPDU(Ag)の正常性に基づき通信線Lbの障害有無を監視することが可能となる。
また、通信線Lbでの障害発生時には、障害を検出したノードN2からその下流ノードN3に対して障害発生通知が送信される。これにより、ルートノードN1からのBPDU(Fd)を正常受信しているため、障害検出ノードN2でルートIDを変更できない場合でも、下流ノードに対するルートID変更処理を、ノードN3へ委託して実行することができる。
また、ルートID変更処理によりノードN3からルートID変更通知が送信された後、ノードN4でブロッキングが解除されてノードN3へルートID復旧通知が送信され、ノードN3からノードN2に対してBPDU(Pr)の送信が開始される。これにより、通信線Lbの障害復旧をノードN2で迅速に確認することが可能となる。
[障害解消動作]
次に、図10A〜図10Cを参照して、障害解消動作について説明する。図10Aは、障害解消処理(障害解消時)を示す説明図である。図10Bは、障害解消処理(ハンドシェーク)を示す説明図である。図10Cは、障害解消処理(ブロッキング)を示す説明図である。
図10Aに示すように、リング型イーサネットシステム1において、ノードN2とノードN3との間のセグメントでの障害が解消された場合、ノードN3からのBPDU(Pr)がノードN2へ届くことになり、ノードN2はノードN3との間でデータ通信が可能となったことを確認する。
これに応じて、図10Bに示すように、ノードN2とノードN3との間で前述した図8の障害解消処理により、MACアドレスが相互に交換され、ブロッキングする位置が再決定される。この場合、両MACアドレスの大きい方のノードN3側で改めてブロッキングが行われる。
これにより、このリング型イーサネットシステム1は、図10Cに示すように、バックアップ系通信経路として、ルートノードN1に対してノードN2を接続する経路と、ルートノードN1からノードN5,N4,N3を接続する経路の2の枝経路を持つツリートポロジーを持つことになる。したがって、BPDU(Fd)は、ルートノードN1からノードN2へ送信されるとともに、ルートノードN1からノードN5,N4,N3へ送信されることになる。
このように、障害解消時には、障害セグメントに接続されているいずれか一方のノード、ここではノードN3で当該障害セグメントがブロッキングされる。このため、障害解消時にツリートポロジーが変更せず、RSTP再構築によるコスト再計算が行われなくなるため、障害解消時における通信ロスの発生が回避される。
[本実施の形態の効果]
このように、本実施の形態は、ノードNの第2の障害監視処理部13Bにより、ルートノードからのBPDU(Fd)の受信に応じて上流ノードへ通信線Lbを介してBPDU(Ag)を返送し、下流ノードから通信線Lbを介して届くBPDU(Ag)の正常性に基づき、下流セグメントでの通信線Lbの障害有無を監視するようにしたので、ノードを接続するリングとして全二重イーサネットを用いた場合でも、上流ノードから届くBPDU(Fd)の正常性に基づき上流セグメントの通信線Laでの障害有無を監視できるとともに、下流ノードから届くBPDU(Ag)の正常性に基づき下流セグメントの通信線Lbでの障害有無を監視することが可能となる。
また、本実施の形態では、ノードNの第2の障害監視処理部13Bにより、通信線Lbでの障害発生時、障害を検出したノードNからその下流ノードに対して障害発生通知を送信するようにしたので、ルートノードN1からのBPDU(Fd)を正常受信しているため、障害検出ノードNでルートIDを変更できない場合でも、下流ノードに対するルートID変更処理を、障害セグメントの他端に接続されている下流ノードへ委託して実行することができる。
また、本実施の形態では、ノードNの障害発生受信処理部13Cにより、上流ノードからの障害発生通知に応じてルートID変更通知を下流ノードへ送信し、これに応じてルートノードN1からのBPDU(Fd)を正常受信しているノードNのルートID変更処理部13Dでブロッキングを解除して上流ノードへルートID復旧通知を返送し、障害発生通知の受信ノードNのルートID復旧処理部13Eにより、上流ノードに対してBPDU(Pr)の送信が開始される。
これにより、通信線Lbの障害復旧を上流ノードで迅速に確認することが可能となる。
また、本実施の形態では、障害解消時、障害セグメントに接続されているいずれか一方のノードで当該障害セグメントがブロッキングされるため、障害解消時にツリートポロジーが変更せず、RSTP再構築によるコスト再計算が行われなくなるため、障害解消時における通信ロスの発生が回避される。
1…リング型イーサネットシステム、N,N1,N2,N3,N4,N5…ノード、10…リング接続制御部、11,12…MAC処理部、13…RSTP処理部、13A…第1の障害監視処理部、13B…第2の障害監視処理部、13C…障害発生受信処理部、13D…ルートID変更処理部、13E…ルートID復旧処理部、13F…障害解消処理部、14…転送処理部、20…アプリケーション処理部、P1,P2…ポート、L…リング、La…通信線(第1の通信線)、Lb…通信線(第2の通信線)。

Claims (4)

  1. 第1および第2の通信線を有する全二重イーサネットからなるリングを介して、複数のノードをリング状に接続することにより、これらノード間のデータ通信を実現するとともに、RSTP(Rapid Spanning Tree Protocol)に基づいて、任意のノードで通信をブロッキングしてルートノードから2つの枝経路で通信を行い、通信の障害発生時には、障害検出ノードに当該ブロッキングを変更して構築したバックアップ系通信経路を用いて通信することで、前記リングでの障害発生を監視するリング型イーサネットシステムで用いられるノードであって、
    自ノードに隣接する一方の隣接ノードから前記第1の通信線を介して届く、前記ノードの1つであるルートノードからのヘルスチェックメッセージの正常性に基づいて、当該一方の隣接ノードとの間のセグメントにおける当該第1の通信線での障害有無を監視し、当該障害無の確認に応じて自ノードに隣接する他方の隣接ノードへ前記第1の通信線を介して当該ヘルスチェックメッセージを転送する第1の障害監視処理部と、
    前記障害無の確認に応じて前記一方の隣接ノードへ前記第2の通信線を介して当該ヘルスチェックメッセージに対する応答メッセージを返送し、前記他方の隣接ノードから前記第2の通信線を介して届く前記応答メッセージの正常性に基づいて、当該他方の隣接ノードとの間のセグメントにおける当該第2の通信線での障害有無を監視し、前記他方の隣接ノードとの間のセグメントにおける前記第2の通信線での障害有の確認に応じて、前記他方の隣接ノードへ前記第1の通信線を介して当該障害の発生を通知するための障害発生通知の間欠送信を開始する第2の障害監視処理部と
    前記一方の隣接ノードから前記第1の通信線を介して受信した前記障害発生通知に応じて、当該一方の隣接ノードとの間の障害セグメントをブロッキングする処理と、自ノードに対応するルートノードを識別するための新たなルートIDとして自ノードIDを設定する処理と、当該隣接ノードのルートIDを前記新たなルートIDへ変更指示するルートID変更通知を、自ノードに隣接する他方の隣接ノードへ前記第1の通信線を介して送信する処理とを実行する障害発生受信処理部と、
    前記一方の隣接ノードから前記第1の通信線を介して受信した前記ルートID変更通知に応じて、自ノードに隣接する隣接ノードとの間のセグメントに対する自ノードでのブロッキングがある場合には、当該ブロッキングを解除する処理と、前記他方の隣接ノードから前記第2の通信線を介して届く前記ヘルスチェックメッセージの正常性が確認されていない場合には、当該ルートID変更通知で指示された前記新たなルートIDへ自ノードのルートIDを変更するとともに、前記他方の隣接ノードへ前記第1の通信線を介して当該ルートID変更通知を転送する処理と、当該ヘルスチェックメッセージの正常性が確認されている場合には、変更前のルートIDへの復旧を指示するルートID復旧通知を当該一方の隣接ノードへ前記第2の通信線を介して返送する処理とを実行するルートID変更処理部と、
    前記他方の隣接ノードから前記第2の通信線を介して受信した前記ルートID復旧通知に応じて、自ノードのルートIDを変更前のルートIDへ復旧する処理と、自ノードが前記障害発生通知の受信ノードでない場合には、前記一方の隣接ノードへ前記第2の通信線を介して当該ルートID復旧通知を転送する処理と、自ノードが前記障害発生通知の受信ノードである場合には、前記一方の隣接ノードへ前記第2の通信線を介して当該障害の解消を通知するための障害解消通知の間欠送信を開始する処理とを実行するルートID復旧処理部と
    を備えることを特徴とするノード。
  2. 請求項に記載のノードにおいて、
    前記他方の隣接ノードから前記第2の通信線を介して受信した前記障害解消通知に応じて、当該他方の隣接ノードへ前記第1の通信線を介して自ノードのMACアドレスを通知する処理と、当該他方の隣接ノードから前記第2の通信線を介して当該他方の隣接ノードのMACアドレスを取得する処理と、これらMACアドレスの大小関係に応じたいずれか一方のノードで、当該障害セグメントのブロッキングを行う処理とを実行する障害解消処理部をさらに備えることを特徴とするノード。
  3. 第1および第2の通信線を有する全二重イーサネットからなるリングを介して、複数のノードをリング状に接続することにより、これらノード間のデータ通信を実現するとともに、RSTP(Rapid Spanning Tree Protocol)に基づいて、任意のノードで通信をブロッキングしてルートノードから2つの枝経路で通信を行い、通信の障害発生時には、障害検出ノードに当該ブロッキングを変更して構築したバックアップ系通信経路を用いて通信することで、前記リングでの障害発生を監視するリング型イーサネットシステムで用いられるネットワーク制御方法であって、
    前記ノードの第1の障害監視処理部が、自ノードに隣接する一方の隣接ノードから前記第1の通信線を介して届く、前記ノードの1つであるルートノードからのヘルスチェックメッセージの正常性に基づいて、当該一方の隣接ノードとの間のセグメントにおける当該第1の通信線での障害有無を監視し、当該障害無の確認に応じて自ノードに隣接する他方の隣接ノードへ前記第1の通信線を介して当該ヘルスチェックメッセージを転送する第1の障害監視ステップと、
    前記ノードの第2の障害監視処理部が、前記障害無の確認に応じて前記一方の隣接ノードへ前記第2の通信線を介して当該ヘルスチェックメッセージに対する応答メッセージを返送し、前記他方の隣接ノードから前記第2の通信線を介して届く前記応答メッセージの正常性に基づいて、当該他方の隣接ノードとの間のセグメントにおける当該第2の通信線での障害有無を監視し、前記他方の隣接ノードとの間のセグメントにおける前記第2の通信線での障害有の確認に応じて、前記他方の隣接ノードへ前記第1の通信線を介して当該障害の発生を通知するための障害発生通知の間欠送信を開始する第2の障害監視ステップと
    前記ノードの障害発生受信処理部が、前記一方の隣接ノードから前記第1の通信線を介して受信した前記障害発生通知に応じて、当該一方の隣接ノードとの間の障害セグメントをブロッキングする処理と、自ノードに対応するルートノードを識別するための新たなルートIDとして自ノードIDを設定する処理と、当該隣接ノードのルートIDを前記新たなルートIDへ変更指示するルートID変更通知を、自ノードに隣接する他方の隣接ノードへ前記第1の通信線を介して送信する処理とを実行する障害発生受信処理ステップと、
    前記ノードのルートID変更処理部が、前記一方の隣接ノードから前記第1の通信線を介して受信した前記ルートID変更通知に応じて、自ノードに隣接する隣接ノードとの間のセグメントに対する自ノードでのブロッキングがある場合には、当該ブロッキングを解除する処理と、前記他方の隣接ノードから前記第2の通信線を介して届く前記ヘルスチェックメッセージの正常性が確認されていない場合には、当該ルートID変更通知で指示された前記新たなルートIDへ自ノードのルートIDを変更するとともに、前記他方の隣接ノードへ前記第1の通信線を介して当該ルートID変更通知を転送する処理と、当該ヘルスチェックメッセージの正常性が確認されている場合には、変更前のルートIDへの復旧を指示するルートID復旧通知を当該一方の隣接ノードへ前記第2の通信線を介して返送する処理とを実行するルートID変更処理ステップと、
    前記ノードのルートID復旧処理部が、前記他方の隣接ノードから前記第2の通信線を介して受信した前記ルートID復旧通知に応じて、自ノードのルートIDを変更前のルートIDへ復旧する処理と、自ノードが前記障害発生通知の受信ノードでない場合には、前記一方の隣接ノードへ前記第2の通信線を介して当該ルートID復旧通知を転送する処理と、自ノードが前記障害発生通知の受信ノードである場合には、前記一方の隣接ノードへ前記第2の通信線を介して当該障害の解消を通知するための障害解消通知の間欠送信を開始する処理とを実行するルートID復旧処理ステップと
    を備えることを特徴とするネットワーク制御方法。
  4. 請求項に記載のネットワーク制御方法において、
    前記ノードの障害解消処理部が、前記他方の隣接ノードから前記第2の通信線を介して受信した前記障害解消通知に応じて、当該他方の隣接ノードへ前記第1の通信線を介して自ノードのMACアドレスを通知する処理と、当該他方の隣接ノードから前記第2の通信線を介して当該他方の隣接ノードのMACアドレスを取得する処理と、これらMACアドレスの大小関係に応じたいずれか一方のノードで、当該障害セグメントのブロッキングを行う処理とを実行する障害解消処理ステップをさらに備えることを特徴とするネットワーク制御方法。
JP2009075829A 2009-03-26 2009-03-26 ノードおよびネットワーク制御方法 Active JP5167183B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2009075829A JP5167183B2 (ja) 2009-03-26 2009-03-26 ノードおよびネットワーク制御方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2009075829A JP5167183B2 (ja) 2009-03-26 2009-03-26 ノードおよびネットワーク制御方法

Publications (2)

Publication Number Publication Date
JP2010232785A JP2010232785A (ja) 2010-10-14
JP5167183B2 true JP5167183B2 (ja) 2013-03-21

Family

ID=43048215

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009075829A Active JP5167183B2 (ja) 2009-03-26 2009-03-26 ノードおよびネットワーク制御方法

Country Status (1)

Country Link
JP (1) JP5167183B2 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6014015B2 (ja) * 2013-12-18 2016-10-25 プライムアースEvエナジー株式会社 電池情報収集装置及び電池情報収集方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0358644A (ja) * 1989-07-27 1991-03-13 Fujitsu Ltd 障害箇所検出方法
JP2003087280A (ja) * 2001-09-12 2003-03-20 Yazaki Corp リング型光通信システム
JP2005269059A (ja) * 2004-03-17 2005-09-29 Fujitsu Ltd データ中継装置、データ中継方法およびデータ中継プログラム

Also Published As

Publication number Publication date
JP2010232785A (ja) 2010-10-14

Similar Documents

Publication Publication Date Title
JP6076373B2 (ja) 相互接続ノードの状態変化に対応する技術
JP4074631B2 (ja) 伝送路システム、および同システムにおけるフレーム伝送装置、ならびに伝送路切り替え方法
US7944815B2 (en) System and method for network recovery from multiple link failures
JP5073812B2 (ja) 分散型イーサネットシステムおよび該システムに基づいて障害を検出する方法
JP5395450B2 (ja) リング型スイッチおよびリング型スイッチ制御方法
JP5281360B2 (ja) リング型スイッチングハブ、リング型イーサネットシステム、およびリング接続制御方法
JP2006180214A (ja) 中継ネットワークシステム、ノード装置、および障害通知方法
JP2006174422A (ja) 通信装置および障害通知方法
JP5167183B2 (ja) ノードおよびネットワーク制御方法
JP5912923B2 (ja) リング/スター型イーサネットシステム、リング/スター型スイッチ、およびフレーム転送制御方法
JP5167173B2 (ja) ノードおよびネットワーク制御方法
JP4287734B2 (ja) ネットワーク装置
JP2009147653A (ja) 通信システムおよびリングノード装置
JP4944986B2 (ja) 伝送路システムおよび伝送路構築方法
TWI308438B (en) Method for exchanging a network message
JP2011009858A (ja) ノードおよびネットワーク制御方法
JP2011024000A (ja) ノードおよびネットワーク制御方法
JP2011188414A (ja) リング型スイッチ、リング型イーサネットシステム、リング型スイッチ制御方法、およびリング型イーサネットシステム制御方法
JP5213805B2 (ja) ノードおよびネットワーク制御方法
JP4653800B2 (ja) 伝送路システム、フレーム伝送装置、伝送路システムにおける伝送路切り替え方法およびプログラム
JP2009004854A (ja) 通信システム
JP2006245780A (ja) リングネットワークシステムおよびリングノード装置
JP4966761B2 (ja) 伝送路システム、ノードおよびノード情報重複判定方法
JP2010068547A (ja) 2重ループ伝送の迂回構成方法
EP2260622A1 (en) Network device performing connection check, network system, and frame transfer method

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20111107

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20121016

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20121109

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: 20121218

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20121221

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20151228

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 5167183

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150