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

Abstract

【課題】ブロッキング状態にあるポートに対する無駄な通信フレームの送受信を抑止して、ノードでの余分な電力消費を削減する。
【解決手段】送信可否判定処理部１３Ｅにより、隣接ノードからの通知に応じて、当該隣接ノードのポートのうち自ノード側ポートの状態を取得し、当該自ノード側ポートがブロッキング状態でない場合は、当該隣接ノードに対する通信フレームについて送信可と判定し、当該自ノード側ポートがブロッキング状態である場合は、当該隣接ノードに対する通信フレームについて送信不可と判定し、ＭＡＣ処理部１１，１２により、当該隣接ノードに対して当該通信フレームを送信する際、送信可判定に応じて当該隣接ノードに対して当該通信フレームを送信し、送信不可判定に応じて当該隣接ノードに対して当該通信フレームの送信を停止する。
【選択図】 図１

Description

本発明は、イーサネット（登録商標）通信技術に関し、特にＲＳＴＰ（Rapid Spanning Tree Protocol）に基づきツリートポロジーを形成してデータ通信を実現するリング型イーサネットの制御技術に関する。

ビル設備やプラント設備を監視制御する監視制御システムでは、情報収集機能や制御機能などの各種機能を有する通信機器をノードとして通信ネットワークを介して接続し、これらノード間でデータ通信を行うことにより、中央監視装置で個々の設備を監視制御するものとなっている。このような監視制御システムでは、通信ネットワークとしてイーサネットが用いられ、各ノード間でデータ通信用のＭＡＣフレームである通信フレームをやり取りすることにより、上位アプリケーションにおけるデータ通信が実現される。

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

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

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

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

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

このようにして、ツリートポロジーが形成された後、ＲＳＴＰによる網管理処理は、ヘルシチェック段階へ移行する。図１３Ｂは、ヘルシチェック動作を示す説明図である。ヘルシチェック段階では、ルートノードＮ１からノードＮ２方向とノードＮ５方向の２方向へ、障害監視用の制御フレームでForwarding ＢＰＤＵを用いたヘルスチェックメッセージが定期的に送信される。各ノードＮ２〜Ｎ５は、ルートノードＮ１からのヘルスチェックメッセージを正常に受信した場合、後続のノードへ転送する。したがって、ヘルスチェックメッセージが正常に受信できない場合、ルートノードＮ１側に隣接するノードとの間のセグメントで障害が発生したことが確認できる。

このような場合、障害発生を確認したノードからルートノードとは逆方向へ再構築要求が送信される。この再構築要求の受信に応じて、ブロッキングしているノードは、当該ブロッキングを解除する。これにより、ブロッキングされていたバックアップ系通信経路が利用されて、新たな通信経路が再構築される。

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

このような従来技術では、ＲＳＴＰによる網管理処理がヘルシチェック段階へ移行した後、各ノード間でデータ通信用のＭＡＣフレームである通信フレームをやり取りすることにより、上位アプリケーションにおけるデータ通信が開始される。
しかしながら、例えば通信フレームとして各ノード宛のブロードキャストフレームを受信した場合、各ノードは、通信経路上における後続ノードのポートでのブロッキング有無にかかわらず、受信した通信フレームを後続ノードへ転送するため、当該ノードと後続ノードとの間で余分な電力が消費されるという問題点があった。

図１４は、従来の通信フレームの転送を示す説明図である。
例えば、図１４に示すように、ノードＮ４のうちノードＮ３側ポートにおいてブロッキングが行われているツリートポロジーでは、ノードＮ３がノードＮ２から通信フレームを正常に受信した場合、ノードＮ３からノードＮ４に対して通信フレームが転送される。また、ノードＮ４では、ノードＮ３側ポートをブロックキングしているため、ノードＮ３から転送された通信フレームを取り込むことなく廃棄する。したがって、ブロッキングポートを介して接続されているノードＮ３，Ｎ４間で、ネットワーク制御に必要外の通信フレームが送受信されていることになり、これらノードＮ３，Ｎ４において余分な電力が消費されることになる。

本発明はこのような課題を解決するためのものであり、ブロッキング状態にあるポートに対する無駄な通信フレームの送受信を抑止して、ノードでの余分な電力消費を削減できるリング型イーサネットの制御技術を提供することを目的としている。

このような目的を達成するために、本発明にかかるノードは、リング状の通信経路を介して、各ノードに設けられた２つのポートをそれぞれの隣接ノードのポートと接続することにより、これらノードをリング状に接続するとともに、ＲＳＴＰ（Rapid Spanning Tree Protocol）に基づいてノードのうちのいずれか１つのノードで、ポートのうちのいずれか一方のポートをブロッキング状態に設定して当該ポートでの通信フレームの転送を停止することにより、各ノードでツリートポロジーを形成してデータ通信を実現するリング型イーサネットシステムで用いられるノードであって、自ノードの隣接ノードからの通知に応じて、当該隣接ノードのポートのうち自ノードが接続されている自ノード側ポートの状態を取得し、当該自ノード側ポートがブロッキング状態でない場合は、当該隣接ノードに対する通信フレームについて送信可と判定し、当該自ノード側ポートがブロッキング状態である場合は、当該隣接ノードに対する通信フレームについて送信不可と判定する送信可否判定処理部と、当該隣接ノードに対して当該通信フレームを送信する際、送信可判定に応じて当該隣接ノードに対して当該通信フレームを送信し、送信不可判定に応じて当該隣接ノードに対して当該通信フレームの送信を停止するＭＡＣ処理部とを備えている。

この際、ＲＳＴＰに基づく制御メッセージを自ノードの隣接ノードに対して送信する際、自ノードのポートのうち当該隣接ノードが接続されているポートがブロッキング状態であるか否かを当該制御メッセージで通知するポート状態通知処理部をさらに備えている。

また、本発明にかかるネットワーク制御方法は、リング状の通信経路を介して、各ノードに設けられた２つのポートをそれぞれの隣接ノードのポートと接続することにより、これらノードをリング状に接続するとともに、ＲＳＴＰ（Rapid Spanning Tree Protocol）に基づいてノードのうちのいずれか１つのノードで、ポートのうちのいずれか一方のポートをブロッキング状態に設定して当該ポートでの通信フレームの転送を停止することにより、各ノードでツリートポロジーを形成してデータ通信を実現するリング型イーサネットシステムで用いられるネットワーク制御方法であって、ノードの送信可否判定処理部が、自ノードの隣接ノードからの通知に応じて、当該隣接ノードのポートのうち自ノードが接続されている自ノード側ポートの状態を取得し、当該自ノード側ポートがブロッキング状態でない場合は、当該隣接ノードに対する通信フレームについて送信可と判定し、当該自ノード側ポートがブロッキング状態である場合は、当該隣接ノードに対する通信フレームについて送信不可と判定する送信可否判定ステップと、ノードのＭＡＣ処理部が、当該隣接ノードに対して当該通信フレームを送信する際、送信可判定に応じて当該隣接ノードに対して当該通信フレームを送信し、送信不可判定に応じて当該隣接ノードに対して当該通信フレームの送信を停止するＭＡＣ処理ステップとを備えている。

この際、ノードのポート状態通知処理部が、ＲＳＴＰに基づく制御メッセージを自ノードの隣接ノードに対して送信する際、自ノードのポートのうち当該隣接ノードが接続されているポートがブロッキング状態であるか否かを当該制御メッセージで通知する状態通知処理ステップをさらに備えてもよい。

本発明によれば、ブロッキング状態にあるポートに対する無駄な通信フレームの送受信が抑止されるため、ノードでの余分な電力消費を削減することができる。

本実施の形態にかかるノードの要部構成を示すブロック図である。 障害発生受信処理を示すフローチャートである。 ルートＩＤ変更処理を示すフローチャートである。 ルートＩＤ復旧処理を示すフローチャートである。 障害解消処理を示すフローチャートである。 送信可否判定処理を示すフローチャートである。 ポート状態通知処理を示すフローチャートである。 通信フレーム送信処理を示すフローチャートである。 正常時におけるヘルシチェックメッセージの転送を示す説明図である。 正常時における応答メッセージの転送を示す説明図である。 正常時における通信フレームの転送を示す説明図である。 障害発生時におけるヘルシチェックメッセージの転送を示す説明図である。 ルートＩＤ変更通知の転送を示す説明図である。 ルートＩＤ復旧通知の転送を示す説明図である。 障害発生後におけるヘルシチェックメッセージの転送を示す説明図である。 障害発生後における通信フレームの転送を示す説明図である。 障害解消処理（ハンドシェーク）を示す説明図である。 障害解消後におけるヘルシチェックメッセージの転送を示す説明図である。 障害解消後における応答メッセージの転送を示す説明図である。 障害解消後における通信フレームの転送を示す説明図である。 典型的なリング型イーサネットシステムの構成例である。 ヘルシチェック動作を示す説明図である。 従来の通信フレームの転送を示す説明図である。

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

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

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

リング接続制御部１０には、主な処理部として、ＭＡＣ処理部１１，１２、ＲＳＴＰ処理部１３、および転送処理部１４が設けられている。
ＭＡＣ処理部１１は、リング接続用のポートＰ１を介してリングＬの一端Ｌ１と接続し、各ノードＮとの間で各種ＭＡＣフレームを送受信する機能と、ＲＳＴＰ処理部１３によりポートＰ１に対してブロッキングが設定されている場合、ポートＰ１について、データ通信用のＭＡＣフレームである通信フレームの送受信を規制し、ネットワーク制御用のＭＡＣフレームである制御フレームのみを送受信する機能とを有している。

これに加え、ＭＡＣ処理部１１は、隣接ノードから受信した制御フレームをＲＳＴＰ処理部１３へ出力する機能と、隣接ノードに対してポートＰ１から通信フレームを送信する際、後述する送信可否判定処理部１３Ｅでの送信可判定に応じて当該隣接ノードに対して当該通信フレームを送信し、送信可否判定処理部１３Ｅでの送信不可判定に応じて当該隣接ノードに対して当該通信フレームの送信を停止する機能とを有している。

ＭＡＣ処理部１２は、リング接続用のポートＰ２を介してリングＬの他端Ｌ２と接続し、各ノードＮとの間で各種ＭＡＣフレームを送受信する機能と、ＲＳＴＰ処理部１３によりポートＰ１に対してブロッキングが設定されている場合、ポートＰ２について、データ通信用のＭＡＣフレームである通信フレームの送受信を規制し、ネットワーク制御用のＭＡＣフレームである制御フレームのみを送受信する機能とを有している。

これに加え、ＭＡＣ処理部１２は、隣接ノードから受信した制御フレームをＲＳＴＰ処理部１３へ出力する機能と、隣接ノードに対してポートＰ２から通信フレームを送信する際、後述する送信可否判定処理部１３Ｅでの送信可判定に応じて当該隣接ノードに対して当該通信フレームを送信し、送信可否判定処理部１３Ｅでの送信不可判定に応じて当該隣接ノードに対して当該通信フレームの送信を停止する機能とを有している。

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

障害監視処理部１３Ａは、ルートノードから定期的に送信されるヘルスチェックメッセージの正常受信の確認に応じて、自ノードに隣接する隣接ノードのうちルートノード側に隣接する上流ノードとの間を接続するセグメント（通信経路）での障害発生の有無を判定する機能と、上流ノードとの間のセグメントでの障害発生に応じて、自ノードに対応するルートノードを識別するための新たなルートＩＤとして自ノードＩＤを設定する処理と、相手ノードのルートＩＤを新たなルートＩＤへ変更指示するルートＩＤ変更通知を、上流ノードとは反対側に隣接する下流ノードへ送信する処理とを実行する機能と、ヘルスチェックメッセージの正常受信に応じて上流ノードに対して応答メッセージを返送する機能とを有している。

ルートＩＤ変更処理部１３Ｂは、自ノードの上流ノードからのルートＩＤ変更通知の受信に応じて、自ノードの隣接ノードとの間のセグメントで行っている自ノードでのブロッキングを解除する処理と、ルートノードから定期的に送信されるヘルスチェックメッセージを下流ノード側から正常受信していない場合には、当該ルートＩＤ変更通知で指示された新たなルートＩＤへ自ノードのルートＩＤを変更するとともに、自ノードの下流ノードへ当該ルートＩＤ変更通知を転送し、ルートノードからのヘルスチェックメッセージを下流ノード側から正常受信している場合には、変更前のルートＩＤへの復旧を指示するルートＩＤ復旧通知を上流ノードへ返送する処理とを実行する機能とを有している。

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

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

送信可否判定処理部１３Ｅは、各種制御フレームを用いた自ノードの隣接ノードからの通知に応じて、当該隣接ノードのポートのうち自ノードが接続されている自ノード側ポートの状態を取得する機能と、当該自ノード側ポートがブロッキング状態でない場合は、当該隣接ノードに対する通信フレームについて送信可と判定し、当該自ノード側ポートがブロッキング状態である場合は、当該隣接ノードに対する通信フレームについて送信不可と判定する機能とを有している。

ポート状態通知処理部１３Ｆは、各種制御フレームを自ノードの隣接ノードに対して送信する際、自ノードのポートのうち当該隣接ノードが接続されているポートがブロッキング状態に設定されているか否かを当該制御フレームに含めて送信する機能を有している。ポートに対するブロッキングの設定状態については、ノード内の記憶部（図示せず）に保存されており、ポート状態通知処理部１３Ｆは、このブロッキングの設定状態を取得して制御フレームに含める。

転送処理部１４は、ＭＡＣ処理部１１，１２から入力されたＭＡＣフレームを、当該ＭＡＣフレームに含まれる宛先情報に基づいて、これらＭＡＣ処理部１１，１２またはアプリケーション処理部２０のいずれかへ転送する機能と、アプリケーション処理部２０から入力されたＭＡＣフレームをＭＡＣ処理部１１，１２へ転送する機能とを有している。

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

ここでは、本実施の形態にかかるノードの主な動作として、第１の障害監視処理、第２の障害監視処理、障害発生受信処理、ルートＩＤ変更処理、ルートＩＤ復旧処理、障害解消処理、送信可否判定処理、および通信フレーム送信処理のそれぞれについて順に説明する。

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

また、後述するポート状態通知処理により、これら制御フレームで、当該制御フレームの転送元となるノードのポート状態が転送元ノードへ通知される。なお、ＲＳＴＰのＢＰＤＵには、通常、ＤＰ，ＲＰ，ＢＰ，ＵＰからなる４種類のポート情報が含まれており、本実施の形態では、これらポート情報を利用してもよい。ＤＰ（Designated Port）は、ＢＰＤＵ（Ｆｄ）を送信するポートを示し、ＲＰ（Root Port）はＢＰＤＵ（Ｆｄ）を受信し、ＢＰＤＵ（Ａｇ）を返信するポートを示している。また、ＢＰ（Blocking Port）は、ブロッキング状態に設定されているポートを示し、ＵＰ（Unknown Port）は、状態未定ポートを示している。以下では、これらポート情報を利用してポート情報を隣接ノードへ通知する場合を例として説明する。

［障害監視処理］
まず、図２を参照して、本実施の形態にかかるノードの障害監視処理について説明する。
リング型イーサネットシステムにおいて、ツリートポロジーが形成された後、ＲＳＴＰによる網管理処理がヘルシチェック段階へ移行する。図９は、正常時におけるヘルシチェックメッセージの転送を示す説明図である。ここでは、ルートノードＮ１からノードＮ３およびノードＮ４までの２つの枝経路からなるツリートポロジーが形成されている。

ヘルシチェック段階では、ルートノードＮ１のＲＳＴＰ処理部１３において、ＲＳＴＰ機能に基づく冗長化制御処理が行われており、リングの正常性確認を目的として、ルートノードＮ１から定期的にヘルシチェックメッセージとしてＢＰＤＵ（Ｆｄ）が送信されている。これにより、ルートノードＮ１からノードＮ２とノードＮ４の２つの枝経路へＢＰＤＵ（Ｆｄ）が送信され、ノードＮ２でＢＰＤＵ（Ｆｄ）が中継転送されてノードＮ３まで送信される。また、これらＢＰＤＵ（Ｆｄ）により、転送元ノードのポート状態としてＤＰが通知されている。

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

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

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

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

一方、ステップ１０１において、ＢＰＤＵ（Ｆｄ）の正常受信を確認できた場合（ステップ１０１：ＹＥＳ）、障害監視処理部１３Ａは、このＢＰＤＵ（Ｆｄ）に対する応答メッセージとして、上流ノードへＢＰＤＵ（Ａｇ）を返送し（ステップ１０４）、ステップ１００へ戻る。

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

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

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

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

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

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

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

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

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

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

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

［送信可否判定処理］
次に、図６を参照して、本実施の形態にかかるノードの送信可否判定処理について説明する。
各ノードＮ１〜Ｎ５のＲＳＴＰ処理部１３は、ネットワーク制御に用いられる制御フレームである各種ＢＰＤＵを、それぞれの隣接ノードからＭＡＣ処理部１１，１２を介して受信した際、送信可否判定処理部１３Ｅにより、図６の送信可否判定処理を実行する。

送信可否判定処理部１３Ｅは、まず、受信したＢＰＵＤから、当該ＢＰＵＤを受信した隣接ノードのポートのうち自ノードが接続されている自ノード側ポートの状態を取得する（ステップ１４０）。
続いて、送信可否判定処理部１３Ｅは、当該自ノード側ポートがブロッキング状態にあるか否か判断する（ステップ１４１）。

ここで、当該自ノード側ポートがブロッキング状態にある場合（ステップ１４１：ＹＥＳ）、送信可否判定処理部１３Ｅは、これ以降に当該隣接ノードへ転送するデータ通信用の通信フレームについて送信不可と判定し（ステップ１４２）、一連の送信可否判定処理を終了する。
一方、当該自ノード側ポートがブロッキング状態にない場合（ステップ１４１：ＮＯ）、送信可否判定処理部１３Ｅは、これ以降に当該隣接ノードへ転送する通信フレームについて送信可と判定し（ステップ１４３）、一連の送信可否判定処理を終了する。

［ポート状態通知処理］
次に、図７を参照して、本実施の形態にかかるノードのポート状態通知処理について説明する。
ルートノードＮ１以外の各ノードＮ２〜Ｎ５のＲＳＴＰ処理部１３は、転送処理部１４からの送信要求に応じてデータ通信用の通信フレームを隣接ノードへ送信する場合、図７のポート状態通知処理を実行する。

ポート状態通知処理部１３Ｆは、ＲＳＴＰ処理部１３から各種制御フレームを自ノードの隣接ノードに対して送信する際、自ノードのポートのうち当該隣接ノードが接続されているポートのポート状態を、ノード内の記憶部（図示せず）から取得する（ステップ１５０）。
この後、ポート状態通知処理部１３Ｆは、当該ポート状態を送信する制御フレームへ格納して、ＭＡＣ処理部１１，１２から隣接ノードへ送信し（ステップ１５１）、一連のポート状態通知処理を終了する。

［通信フレーム送信処理］
次に、図８を参照して、本実施の形態にかかるノードの通信フレーム送信処理について説明する。
各ノードＮ１〜Ｎ５のＭＡＣ処理部１１，１２は、転送処理部１４からの送信要求に応じてデータ通信用の通信フレームを隣接ノードへ送信する場合、図８の通信フレーム送信処理を実行する。

ＭＡＣ処理部１１，１２は、まず、転送処理部１４からの送信要求で指定された、通信フレームを送信すべき隣接ノードに関する送信可否判定結果を送信可否判定処理部１３Ｅから取得する（ステップ１６０）。
続いて、ＭＡＣ処理部１１，１２は、送信可否判定結果の内容を確認し（ステップ１６１）、送信可否判定結果が隣接ノードに対する通信フレームについて送信可を示す場合（ステップ１６１：ＹＥＳ）、ＭＡＣ処理部１１，１２は、当該隣接ノードに対して通信フレームを、対応するポートＰ１，Ｐ２から当該隣接ノードへ送信し（ステップ１６２）、一連の通信フレーム送信処理を終了する。

一方、送信可否判定結果が当該隣接ノードに対する通信フレームについて送信不可を示す場合（ステップ１６１：ＮＯ）、ＭＡＣ処理部１１，１２は、当該通信フレームの送信を停止し（ステップ１６３）、一連の通信フレーム送信処理を終了する。

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

前述したように、図９のリング型イーサネットシステムでは、ツリートポロジーが形成された後、ルートノードＮ１のＲＳＴＰ処理部１３において、ＲＳＴＰ機能に基づく冗長化制御処理が行われており、リングの正常性確認を目的として、ルートノードＮ１から定期的にヘルスチェックメッセージが送信されており、ルートノードＮ１のポート状態通知処理部１３Ｆにより、ヘルスチェックメッセージとしてポート状態ＤＰを含むＢＰＤＵ（Ｆｄ，ＤＰ）が送信されている。

これにより、ルートノードＮ１からノードＮ２とノードＮ５の２つの枝経路へ、並行してＢＰＤＵ（Ｆｄ）が送信され、同様にして、ノードＮ２でＢＰＤＵ（Ｆｄ，ＤＰ）が中継転送されてノードＮ３まで送信され、ノードＮ５でＢＰＤＵ（Ｆｄ，ＤＰ）が中継転送されてノードＮ４まで送信される。
この際、図９に示すように、ノードＮ４のノードＮ３側ポートでブロッキングが行われている。したがって、ノードＮ３からのＢＰＤＵ（Ｆｄ，ＤＰ）はノードＮ４で受信されるものの、ノードＮ４からノードＮ５へは転送されず廃棄される。同様にノードＮ５からのＢＰＤＵ（Ｆｄ，ＤＰ）はノードＮ４で受信されるものの、ノードＮ４からノードＮ３へは転送されず廃棄される。

一方、各ノードＮ２〜Ｎ５の障害監視処理部１３Ａで、ルートノードＮ１からのＢＰＤＵ（Ｆｄ，ＤＰ）の正常受信が確認できている場合、ＢＰＤＵ（Ｆｄ，ＤＰ）の受信に応じて、ＢＰＤＵ（Ａｇ）がそれぞれ返送される。図１０Ａは、正常時における応答メッセージの転送を示す説明図である。ここでは、ノードＮ４の上流側ポートがブロッキング状態であることから、ノードＮ４からのＢＰＤＵ（Ａｇ，ＢＰ）でポート状態がＢＰである旨がノードＮ３へ通知され、他のノードＮ２，Ｎ３，Ｎ５では、ＢＰＤＵ（Ａｇ，ＲＰ）でポート状態がＲＰである旨がノードＮ１，Ｎ２，Ｎ１通知される。

したがって、ノードＮ３の送信可否判定処理部１３Ｅにより、ノードＮ４からの（Ａｇ，ＢＰ）に基づき、ノードＮ４のノードＮ３側ポートがブロッキング状態であると認識され、これ以降、ノードＮ３のＭＡＣ処理部１１，１２での通信フレーム送信処理により、ノードＮ３からノードＮ４に対する通信フレームの送信が停止される。
図１０Ｂは、正常時における通信フレームの転送を示す説明図である。ノードＮ２から送信開始されたブロードキャストの通信フレームは、ノードＮ３においてノードＮ４への送信が停止される。これにより、ブロッキング状態にあるポートに対する無駄な通信フレームの送受信が抑止され、ノードでの余分な電力消費が削減される。

［障害発生動作］
次に、図１１Ａ〜図１１Ｅを参照して、障害発生動作について説明する。図１１Ａは、障害発生時におけるヘルシチェックメッセージの転送を示す説明図である。図１１Ｂは、ルートＩＤ変更通知の転送を示す説明図である。図１１Ｃは、ルートＩＤ復旧通知の転送を示す説明図である。図１１Ｄは、障害発生後におけるヘルシチェックメッセージの転送を示す説明図である。図１１Ｅは、障害発生後における通信フレームの転送を示す説明図である。

図１１Ａに示すように、ルートノードＮ１とノードＮ２の間のセグメントで障害が発生した場合、ルートノードＮ１が送信したＢＰＤＵ（Ｆｄ，ＤＰ）がノードＮ２へ届かなくなる。
これに応じて、ノードＮ２は、障害監視処理部１３Ａにより、ルートノードＮ１との間のセグメントでの障害発生を検出し、図１１Ｂに示すように、自ＭＡＣアドレス「２」を自ノードＮ２のルートＩＤとして設定するとともに、下流ノードＮ３へルートＩＤ変更通知を送信する。

一方、ノードＮ３は、上流ノードＮ２からルートＩＤ変更通知を受信した場合、ルートＩＤ変更処理部１３Ｂにより、通知されたＭＡＣアドレス「２」を自ノードＮ３のルートＩＤとして設定するとともに、下流ノードＮ４へルートＩＤ変更通知を送信する。
ノードＮ４では、ノードＮ３からのルートＩＤ変更通知の受信した場合、ルートＩＤ変更処理部１３Ｂにより、図１１Ｃに示すように、ブロッキングを解除する。この場合、ノードＮ４は、ノードＮ５を介してルートノードＮ１からＢＰＤＵ（Ｆｄ，ＤＰ）を正常受信しているので、ルートＩＤ復旧通知を上流ノードＮ３へ返送する。

ノードＮ３は、ノードＮ４からのルートＩＤ復旧通知の受信に応じて、ルートＩＤ復旧処理部１３Ｃにより、自ノードＮ３のルートＩＤを元のルートノードＮ１に復旧する。この場合、自ノードが障害発生受信ノードでないことから、上流ノードＮ２へルートＩＤ復旧通知を転送する。
ノードＮ２は、ノードＮ３からのルートＩＤ復旧通知の受信に応じて、ルートＩＤ復旧処理部１３Ｃにより、自ノードＮ２のルートＩＤを元のルートノードＮ１に復旧する。この場合、自ノードが障害発生受信ノードであることから、障害検出側のポートをブロッキング状態に設定する。

したがって、リング型イーサネットシステムのトポロジーは、ルートノードＮ１からノードＮ５，Ｎ４，Ｎ３，Ｎ２の１つの枝経路へ変更され、これ以降、ルートノードＮ１からのＢＰＤＵ（Ｆｄ，ＤＰ）は、ノードＮ５，Ｎ４，Ｎ３，Ｎ２の順で転送されることになる。ここで、ノードＮ３は、ノードＮ４からのＢＰＤＵ（Ｆｄ，ＤＰ）に基づいて、送信可否判定処理部１３Ｅにより、ノードＮ４のポートがブロッキング状態ではなくなったことを確認し、ノードＮ４に対する通信フレームについて送信可と判定する。

これにより、障害発生後、ノードＮ３からノードＮ４に対する通信フレームの送信が再開され、例えばノードＮ２から送信開始されたブロードキャストの通信フレームは、図１１Ｅに示すように、ノードＮ３からノードＮ４へ送信され、ルートノードＮ１まで転送される。
なお、ノードＮ２では、自ノードでルートノードＮ１側ポートをブロッキングしていることから、当該ポートについて通信フレームの送信は停止する。また、ルートノードＮ１において、ノードＮ２からのＢＰＵＤ（Ａｇ）が返送されないことから、ノードＮ２との間のセグメントでの障害発生を確認でき、当該ポートについて通信フレームの送信は停止する。

［障害解消動作］
次に、図１２Ａ〜図１２Ｄを参照して、障害解消動作について説明する。図１２Ａは、障害解消処理（ハンドシェーク）を示す説明図である。図１２Ｂは、障害解消後におけるヘルシチェックメッセージの転送を示す説明図である。図１２Ｃは、障害解消後における応答メッセージの転送を示す説明図である。図１２Ｄは、障害解消後における通信フレームの転送を示す説明図である。

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

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

また、各ノードＮ２〜Ｎ５で、ルートノードＮ１からのＢＰＤＵ（Ｆｄ，ＤＰ）の正常受信が確認できている場合、ＢＰＤＵ（Ｆｄ，ＤＰ）の受信に応じて、図１２Ｃに示すように、ＢＰＤＵ（Ａｇ）がそれぞれ返送される。ここでは、ノードＮ２のルートノードＮ１側ポートがブロッキング状態であることから、ノードＮ２からのＢＰＤＵ（Ａｇ，ＢＰ）でポート状態がＢＰである旨がルートノードＮ１へ通知され、他のノードＮ３〜Ｎ５では、ＢＰＤＵ（Ａｇ，ＲＰ）でポート状態がＲＰである旨がノードＮ２〜Ｎ４，Ｎ１へ通知される。

したがって、ルートノードＮ１の送信可否判定処理部１３Ｅにより、ノードＮ２からの（Ａｇ，ＢＰ）に基づき、ノードＮ２のルートノードＮ１側ポートがブロッキング状態であると認識され、これ以降、図１２Ｄに示すように、ルートノードＮ１のＭＡＣ処理部１１，１２での通信フレーム送信処理により、ルートノードＮ１からノードＮ２に対する通信フレームの送信が停止される。

［本実施の形態の効果］
このように、本実施の形態は、送信可否判定処理部１３Ｅにより、自ノードの隣接ノードからの通知に応じて、当該隣接ノードのポートのうち自ノードが接続されている自ノード側ポートの状態を取得し、当該自ノード側ポートがブロッキング状態でない場合は、当該隣接ノードに対する通信フレームについて送信可と判定し、当該自ノード側ポートがブロッキング状態である場合は、当該隣接ノードに対する通信フレームについて送信不可と判定し、ＭＡＣ処理部１１，１２により、当該隣接ノードに対して当該通信フレームを送信する際、送信可判定に応じて当該隣接ノードに対して当該通信フレームを送信し、送信不可判定に応じて当該隣接ノードに対して当該通信フレームの送信を停止する。
これにより、ブロッキング状態にあるポートに対する無駄な通信フレームの送受信が抑止され、ノードでの余分な電力消費を削減することができる。

また、本実施の形態では、ポート状態通知処理部１３Ｆで、ＲＳＴＰに基づく制御メッセージを自ノードの隣接ノードに対して送信する際、自ノードのポートのうち当該隣接ノードが接続されているポートがブロッキング状態であるか否かを当該制御メッセージで通知するようにしたので、ポート状態を通知するための個別のメッセージを新たな用いる必要がなくなり、ノード間のトラヒックを低減できる。

Ｎ，Ｎ１，Ｎ２，Ｎ３，Ｎ４，Ｎ５…ノード、１０…リング接続制御部、１１，１２…ＭＡＣ処理部、１３…ＲＳＴＰ処理部、１３Ａ…障害監視処理部、１３Ｂ…ルートＩＤ変更処理部、１３Ｃ…ルートＩＤ復旧処理部、１３Ｄ…障害解消処理部、１３Ｅ…送信可否判定処理部、１３Ｆ…ポート状態通知処理部、１４…転送処理部、２０…アプリケーション処理部、Ｐ１，Ｐ２…ポート。

Claims (4)

1. リング状の通信経路を介して、各ノードに設けられた２つのポートをそれぞれの隣接ノードのポートと接続することにより、これらノードをリング状に接続するとともに、ＲＳＴＰ（Rapid Spanning Tree Protocol）に基づいて前記ノードのうちのいずれか１つのノードで、前記ポートのうちのいずれか一方のポートをブロッキング状態に設定して当該ポートでの通信フレームの転送を停止することにより、前記各ノードでツリートポロジーを形成してデータ通信を実現するリング型イーサネットシステムで用いられるノードであって、
   自ノードの隣接ノードからの通知に応じて、当該隣接ノードのポートのうち自ノードが接続されている自ノード側ポートの状態を取得し、当該自ノード側ポートがブロッキング状態でない場合は、当該隣接ノードに対する通信フレームについて送信可と判定し、当該自ノード側ポートがブロッキング状態である場合は、当該隣接ノードに対する通信フレームについて送信不可と判定する送信可否判定処理部と、
   当該隣接ノードに対して当該通信フレームを送信する際、前記送信可判定に応じて当該隣接ノードに対して当該通信フレームを送信し、前記送信不可判定に応じて当該隣接ノードに対して当該通信フレームの送信を停止するＭＡＣ処理部と
   を備えることを特徴とするノード。
2. 請求項１に記載のノードにおいて、
   前記ＲＳＴＰに基づく制御メッセージを自ノードの隣接ノードに対して送信する際、自ノードのポートのうち当該隣接ノードが接続されているポートがブロッキング状態であるか否かを当該制御メッセージで通知するポート状態通知処理部をさらに備えることを特徴とするノード。
3. リング状の通信経路を介して、各ノードに設けられた２つのポートをそれぞれの隣接ノードのポートと接続することにより、これらノードをリング状に接続するとともに、ＲＳＴＰ（Rapid Spanning Tree Protocol）に基づいて前記ノードのうちのいずれか１つのノードで、前記ポートのうちのいずれか一方のポートをブロッキング状態に設定して当該ポートでの通信フレームの転送を停止することにより、前記各ノードでツリートポロジーを形成してデータ通信を実現するリング型イーサネットシステムで用いられるネットワーク制御方法であって、
   前記ノードの送信可否判定処理部が、自ノードの隣接ノードからの通知に応じて、当該隣接ノードのポートのうち自ノードが接続されている自ノード側ポートの状態を取得し、当該自ノード側ポートがブロッキング状態でない場合は、当該隣接ノードに対する通信フレームについて送信可と判定し、当該自ノード側ポートがブロッキング状態である場合は、当該隣接ノードに対する通信フレームについて送信不可と判定する送信可否判定ステップと、
   前記ノードのＭＡＣ処理部が、当該隣接ノードに対して当該通信フレームを送信する際、前記送信可判定に応じて当該隣接ノードに対して当該通信フレームを送信し、前記送信不可判定に応じて当該隣接ノードに対して当該通信フレームの送信を停止するＭＡＣ処理ステップと
   を備えることを特徴とするネットワーク制御方法。
4. 請求項３に記載のネットワーク制御方法において、
   前記ノードのポート状態通知処理部が、前記ＲＳＴＰに基づく制御メッセージを自ノードの隣接ノードに対して送信する際、自ノードのポートのうち当該隣接ノードが接続されているポートがブロッキング状態であるか否かを当該制御メッセージで通知する状態通知処理ステップをさらに備えることを特徴とするネットワーク制御方法。

Images