JP2007243288A - 通信システム、ノード、通信方法、およびノード用プログラム - Google Patents

Abstract

【課題】ネットワーク間を接続するリンク、またはネットワークと端末間を接続するリンクを高信頼化した通信システムを提供する。
【解決手段】インタリンク接続ノードは、１つのフレームに対し、接続先（ネットワークまたは端末）を同じくするインタリンク接続ノードのうちのいずれか１つのみが、そのフレームにカプセル化されたイーサネットフレームをインタリンク経由で送信するよう制御する。具体的には、自ノードに接続されているインタリンクに障害が発生していない場合に、自ノードと接続先を同じくするインタリンク接続ノード宛のユニキャストフレーム、および、フレーム送信済み識別子が付加されていないブロードキャストフレームであれば、そのイーサネットフレームをインタリンク経由で接続先に送信するとともに、ブロードキャストフレームであれば、フレーム送信済み識別子を付加した上で、隣接ノードに転送する。
【選択図】図１

Description

本発明は、通信システム、ノード、通信方法、およびノード用プログラムに関し、特に、信頼性の高い通信システム、およびそのような通信システムに適用されるノード、通信方法、およびノード用プログラムに関する。

近年、インターネットの普及により、文字や画像などのデータ配信のみならず、通話や映像配信にもインターネットが利用されるようになった。このため、基幹系通信システムのトラフィック量が急激に増大している。特に、基幹系通信システムを構成するネットワーク間を接続するリンク（以下、インタリンクと記述する。）を流れるトラフィックは膨大な量になるため、インタリンクの高信頼化技術は、安定した通信を継続的に提供する上で、極めて重要である。ここで、インタリンクの高信頼化技術とは、トラフィックの集中による輻輳の発生を抑制し、かつ、インタリンクの異常による通信の遮断を回避する技術をいう。なお、インタリンクの異常には、インタリンクの切断等による異常だけでなくインタリンク両端のノード（以下、インタリンク接続ノードと記述する）の故障等による異常も含む。

以下、信頼性の高い基幹系通信システムを実現するネットワークの例として、非特許文献１に開示されているＲＰＲ（Resilient Packet Ring ）が適用されたネットワーク（以下、ＲＰＲネットワークと記述する。）を取り上げて、複数のＲＰＲネットワーク間を接続するインタリンクの信頼性を向上させる技術について説明する。非特許文献１は、２００４年にＩＥＥＥ（the Institute of Electrical and Electronics Engineers ）から発行された標準化文書である。

図１９は、ＲＰＲネットワークの例を示す説明図である。ＲＰＲは、図１９に示すようなリングトポロジのネットワーク上で、フレーム（パケット）を転送するためのネットワークプロトコルである。

図１９に示す通信システムは、８台のＲＰＲに準拠して動作するノード（以下、ＲＰＲノードと記述する。）によりＲＰＲネットワーク８０を構成し、各ＲＰＲノードの配下に１台の端末を収容した例である。ここで、ＲＰＲノードの配下に端末を収容するとは、ＲＰＲノードに、そのＲＰＲノードが属するリングネットワークに属していない端末を接続させることをいう。なお、端末は、そのＲＰＲノードが属するリングネットワーク以外のリングネットワークに属していたり、その他の通信ネットワークに属していてもよい。また、ＲＰＲノードの配下に収容される端末を、単に、配下の端末と記す場合もある。

図１９に示す例では、各ＲＰＲノード８００〜８７０は、それぞれポートＰ１〜Ｐ３を有する。各ＲＰＲノード８００〜８７０は、ポートＰ１，Ｐ２を用いて、隣接するＲＰＲノードとＲＰＲフレームを送受信する。また、各ＲＰＲノード８００〜８７０は、配下の端末（端末１８００〜１８７０のうちの１つ）を備える。個々のＲＰＲノードと配下の端末とは、ＲＰＲノードのポートＰ３と、配下の端末が有するポート（図示せず。）とを用いてフレーム（イーサネットフレーム）を送受信する。なお、イーサネット（Ethernet）は、登録商標である。

ＲＰＲの主な特徴としては、高速のプロテクション機能が広く知られている。例えば、ＲＰＲネットワークにおいて、ＲＰＲノード間のリンクが切断された場合、そのリンクの両側のＲＰＲノードが切断を検出し、即座に他の全てのＲＰＲノードにその旨を通知する。障害発生の通知を受信した他のＲＰＲノードは、リンクの切断箇所を迂回するように、トラフィックを操作する（通信方向やＴＴＬ等を制御する）動作状態に遷移する。このため、通信を継続して行うことが可能となる。ここで、プロテクション機能とは、ある箇所に発生した障害によって通信が途絶えてしまうことを防止するための機能をいう。

ＲＰＲは、都市網のように、大容量のトラフィックが流れる基幹系通信システムへの採用を前提として、ＳＤＨ（Synchronous Digital Hierarchy ）またはＳＯＮＥＴ（Synchronous Optical Network ）といった伝送技術と同等の５０ｍｓ以内の短時間で通信を回復するように設計されているため、信頼性の高い通信システムを構築することが可能である。

また、２個のＲＰＲネットワーク間を接続するインタリンクの信頼性を向上させる従来の技術として、非特許文献２に開示されているＬＡＧ（Link Aggregation）がある。なお、非特許文献２もＩＥＥＥから発行された標準化文書である。

ＬＡＧは、複数の物理ポートをあたかも１個の論理ポートに仮想化する技術である。換言すれば、複数のリンクをあたかも１本の論理リンクに仮想化する技術である。ＬＡＧを適用すると、障害の発生していない通常時において、論理リンクに属する複数の物理リンクにトラフィックを分散させて送信するので、リンクの通信帯域を増大（最大で物理リンクの通信帯域の総和にまで）させることが可能となる。また、物理リンクの切断による異常時においては、障害の発生していない他の正常な物理リンクのみを用いてフレームを転送するので、通信を続行させることが可能である。

図２０は、ＲＰＲネットワーク同士の接続にＬＡＧを適用した例を示す説明図である。図２０に示す通信システムは、ＲＰＲネットワーク８０とＲＰＲネットワーク９０間を接続するインタリンクにＬＡＧを適用した例である。図２０に示す例では、ＲＰＲネットワーク８０に属するＲＰＲノード８００およびＲＰＲネットワーク９０に属するＲＰＲノード９００は、ポートＰ１〜Ｐ３の他にポートＰ４を有する。ＲＰＲノード８００のポートＰ３，Ｐ４にはＬＡＧが設定される。同様に、ＲＰＲノード９００のポートＰ３，Ｐ４にもＬＡＧが設定される。そして、ＲＰＲノード８００のポートＰ３とＲＰＲノード９００のポートＰ４とをインタリンク４９１により接続し、ＲＰＲノード８００のポートＰ４とＲＰＲノード９００のポートＰ３とをインタリンク４９２により接続する。このような構成により、図２０に示す例では、ＲＰＲネットワーク８００とＲＰＲネットワーク９００間の接続の信頼性を向上させている。

また、２個のＲＰＲネットワーク間の接続の高信頼度化技術が、特許文献１に開示されている。図２１は、特許文献１に記載されたネットワークの構成を示す説明図である。特許文献１に記載されたネットワークでは、図２１に示すように、ＲＰＲノード８００およびＲＰＲノード９００がＲＰＲネットワーク８０およびＲＰＲネットワーク９０の両方に属するように配置される。そして、ＲＰＲノード８００，ＲＰＲノード９００のうち一方のノードが現用ノードとしてＲＰＲネットワーク間（ＲＰＲネットワーク８０とＲＰＲネットワーク９０間）のフレーム転送を行い、他方のノードが予備用ノードとしてＲＰＲネットワーク間のフレーム転送を行わない動作状態に設定される。予備用ノードが現用ノードの障害を検出した場合には、予備用ノードがＲＰＲネットワーク間のフレーム転送を行う動作状態に遷移する。そして、ＲＰＲノード８００およびＲＰＲノード９００以外の全てのＲＰＲノードのフォワーディングデータベースの内容を消去させる。この結果、現用ノードを経由して転送されていたトラフィックが、予備用ノードを経由して転送されるようになる。従って、現用ノードに障害が発生した場合でも、通信を継続して行うことができる。

また、特許文献２には、２つのリングネットワークを接続させた通信ネットワークシステムが記載されている。特許文献２に記載された通信ネットワークシステムでは、２つのリングネットワーク間を接続するインタリンクを２重化した上で、一方のインタリンクを現用系として、他方を予備系として使用する。現用系のインタリンクに障害が発生した場合に、通信に使用するインタリンクを予備系に切り替えることにより、通信を継続して行うことが可能である。

特開２００３−２５８８２２号公報（段落００１５−００８５、図１） 特開２０００−００４２４８号公報（段落００７３−００７６） "IEEE Std 802.17 Part17:Resilient packet ring(RPR) access method and physical layer specifications", IEEE Inc, 2004, p.27-54 "IEEE Std 802.3ad Amendment to Carrier Sense Multiple Access with Collision Detection(CSMA/CD) Access Method and Physical Layer Specifications- Aggregation of Multiple Link Segments", IEEE Inc, 2000, p.95-107

しかし、上記に示した高信頼化技術では、基幹系通信システムを構成するネットワーク間を接続するインタリンクに対してもプロテクション機能を実現することができるが、それぞれ以下のような問題がある。まず、ＬＡＧを適用した通信システムでは、１つの論理ポートに仮想化することが可能な物理ポートは、１つのノードに属する物理ポートに制限される。このため、論理ポートを仮想化するノード（インタリンク接続ノード）の一方が故障しただけで、通信が遮断してしまうという問題がある。例えば、図２０に例示する通信システムにおいて、ＲＰＲノード８００またはＲＰＲノード９００のいずれか一方が故障すれば、ＲＰＲネットワーク８０とＲＰＲネットワーク９０間の全ての通信が停止してしまう。

また、特許文献１に記載された通信システムでは、ネットワークの接続点が複数個存在するにも関わらず、いずれか１つの接続点のみでしかフレーム転送を行わないため、輻輳の発生を抑制することができない。現用／予備を切り替えて、いずれか１つのみを使用する点において、特許文献２に記載の通信ネットワークシステムの問題点も同様である。

なお、リングネットワーク間を接続させたネットワークトポロジにおいて、複数の接続点で無制御にフレーム転送を行うと、同じフレームを２重に受信してしまう多重受信や、ブロードキャスト送信されたフレームが永久にリングから削除されない現象（ブロードキャストストームと呼ばれる）が発生する問題がある。高信頼化技術の前提として、このような現象の発生を防止する必要がある。

そこで、本発明は、ネットワーク間を接続するインタリンクやネットワークと端末とを接続するリンクの信頼性の高い通信システム、およびそのような通信システムに適用されるノード、通信方法、およびノード用プログラムを提供することを目的とする。

本発明による通信システムは、端末が接続される複数のノードを含む通信システムであって、前記複数のノードのうちの一部のノードは、それぞれリンク（インタリンク）を介して共通の端末または当該通信システムとは異なる通信システムに含まれるノードが端末として接続されることによって、共通の接続先（共通の端末または当該通信システムとは異なる通信システム）を有するグループとしてまとめられ、前記グループに属するノードは、システム内通信用フレームに格納されている、当該通信システムが含むノードに接続される端末から受信したフレームを共通の接続先の端末またはノードに送信したか否かを示す識別子を、前記システム内通信用フレームに付加する識別子付加手段と、システム内通信用フレームを受信した場合に、前記システム内通信用フレームで示される情報に基づいて、前記システム内通信用フレームに格納されているフレームを共通の接続先の端末またはノードに送信するか否かを判定する送信判定手段とを備えたことを特徴とする。

なお、共通の端末に接続されるとは、複数のノードが同じ端末に接続されることをいう。また、共通の通信システムに含まれるノードに接続されるとは、複数のノードが他の同じ通信システムに含まれるノードに接続されることをいう。

また、グループに属するノードは、識別子付加手段によって識別子が付加されたシステム内通信用フレームを当該通信システムに含まれるノードに送信するシステム内通信用フレーム送信手段と、送信判定手段の判定結果に応じて、システム内通信用フレームに格納されているフレームを共通の接続先の端末またはノードに送信する端末通信用フレーム送信手段とを備えていてもよい。

また、グループに属するノードは、共通の接続先の端末またはノードと自ノードとの間のリンクの障害状態を監視する障害監視手段を備え、送信判定手段は、自ノードと同じグループに属するノードの識別子付加手段によって付加される識別子および前記障害監視手段が監視した前記リンクの障害状態に基づいて、前記システム内通信用フレームに格納されているフレームを共通の接続先の端末またはノードに送信するか否かを判定してもよい。

また、識別子付加手段は、自ノードが、共通の接続先の端末またはノードに、ブロードキャストによる転送を示すシステム内通信用フレームに格納されているフレームを送信した場合に、送信した旨を示す送信済み識別子を付加してもよい。

また、識別子付加手段は、自ノードが、共通の接続先の端末またはノードに、ブロードキャストによる転送を示すシステム内通信用フレームに格納されているフレームを送信しなかった場合に、送信しなかった旨を示す未送信識別子を付加してもよい。

また、送信判定手段は、システム内通信用フレームの送信元アドレスが、自ノードと同じグループに属するノードのアドレスである場合に、送信しない旨を決定してもよい。

また、送信判定手段は、ブロードキャストによる転送を示すシステム内通信用フレームを受信したときに、前記システム内通信用フレームに送信済み識別子が付加されていない、または未送信識別子が付加されている場合であって、共通の接続先の端末またはノードとの間でフレームを送受信可能である場合に、送信する旨を決定してもよい。

また、グループに属するノードは、システム内通信用フレームに設定されている転送経路を示す経路情報を変更することによって、前記システム内通信用フレームの転送経路を変更する転送経路変更手段を備えていてもよい。

また、グループに属さない各ノードは、前記グループに属するノードのうちのいずれか１つと対応づけられることによって、前記グループに属するノードのうちのいずれか１つに割り当てられ、送信判定手段は、ブロードキャストによる転送を示すシステム内通信用フレームを受信したときに、自ノードが前記グループに属するノードの中で前記システム内通信用フレームを最初に受信したノードであれば、前記システム内通信用フレームの送信元ノードが自ノードに割り当てられている場合であって、共通の接続先の端末またはノードとの間でフレームを送受信可能である場合に、および、自ノードが前記グループに属するノードの中で前記システム内通信用フレームを最初に受信したノードでなければ、前記システム内通信フレームに未送信識別子が付加されている場合または送信識別子が付加されていない場合であって、共通の接続先の端末またはノードとの間でフレームを送受信可能である場合に、送信する旨を決定し、転送経路変更手段は、前記送信判定手段が送信しない旨を決定した場合であって、自ノード以降の前記システム内通信用フレームの転送経路上に、前記グループに属する他のノードが配置されていない場合に、前記システム内通信用フレームの経路情報を前記グループに属する他のノードまで到達可能に変更してもよい。

また、転送経路変更手段は、経路情報として、システム内通信用フレームに格納されているＴＴＬを変更してもよい。

また、グループに属さないノードは、システム内通信用フレームを受信した場合に、前記システム内通信用フレームで示される情報に基づいて、前記システム内通信用フレームに格納されているフレームを自ノードに接続される端末に送信するか否かを判定する第２の送信判定手段を備えていてもよい。

また、第２の送信判定手段は、ブロードキャストによる転送を示すシステム内通信用フレームを受信したときに、前記システム内通信用フレームの送信元ノードが前記システム内通信用フレームの生成時に設定した転送経路上に自ノードが配置されていない場合に、送信しない旨を決定してもよい。

送信判定手段は、システム内通信用フレームの宛先アドレスが自ノードと同じグループに属するノードのアドレスであって、共通の接続先の端末またはノードとの間でフレームを送受信可能である場合に、送信する旨を決定してもよい。

また、共通の端末は、該端末に接続される各ノードとのフレーム送受信の可否と、前記各ノードにおける当該通信システムが含む他のノードとのフレーム送受信の可否とに基づいて、前記ノードのいずれか１つにフレームを送信する選択送信手段を備えていてもよい。

また、識別子付加手段は、システム内通信用フレームのヘッダ、または、システム内通信用フレームのプリアンブル、または、システム内通信用フレーム間のインタフレームギャップの予め定められたフィールドの値を用いることによって、識別子を表現してもよい。

また、識別子付加手段は、システム内通信用フレームの宛先アドレスに、ブロードキャストによる転送を示すブロードキャスト用アドレスとは異なるアドレスであって、当該通信システムに属するノードにおいて、ブロードキャスト用アドレスを宛先アドレスとするシステム内通信用フレームと同様のフレーム転送処理が行われるアドレスを用いることによって、識別子を表現してもよい。

また、グループに属するノードは、自ノードに接続される当該通信システムが含む他のノードとの間の全リンクでフレームを送受信不可能な場合に、共通の接続先の端末またはノードに、自ノードとの間でフレームを送受信不可能な旨を検出させるリンク制御手段を備えていてもよい。なお、リンク制御手段は、例えば、共通の接続先である端末またはノードとの間でフレームを送受信するポートを閉じたり、リンクの障害を検出するための制御フレームのやりとりを停止することによって、リンクダウンを検出させる。

また、当該通信システム、および、当該通信システムとは異なる共通の通信システムは、ＲＰＲネットワークであってもよい。

また、本発明によるノードは、端末が接続される複数のノードを含む通信システムにおいて、前記複数のノードのうち、リンクを介して共通の端末または当該通信システムとは異なる通信システムに含まれるノードが端末として接続されることによって、共通の接続先を有するグループとしてまとめられるノードであって、システム内通信用フレームに格納されている、当該通信システムが含むノードに接続される端末から受信したフレームを共通の接続先の端末またはノードに送信したか否かを示す識別子を、前記システム内通信用フレームに付加する識別子付加手段と、システム内通信用フレームを受信した場合に、前記システム内通信用フレームで示される情報に基づいて、前記システム内通信用フレームに格納されているフレームを共通の接続先である端末またはノードに送信するか否かを判定する送信判定手段とを備えたことを特徴とする。

また、システム内通信用フレームに設定されている転送経路を示す経路情報を変更することによって、前記システム内通信用フレームの転送経路を変更する転送経路変更手段を備えていてもよい。

また、グループに属さないノードであって、システム内通信用フレームを受信した場合に、前記システム内通信用フレームで示される情報に基づいて、前記システム内通信用フレームに格納されているフレームを自ノードに接続される端末に送信するか否かを判定する第２の送信判定手段を備えていてもよい。

また、本発明による通信方法は、端末が接続される複数のノードを含む通信システムであって、前記複数のノードのうちの一部のノードが、それぞれリンクを介して共通の端末または当該通信システムとは異なる通信システムに含まれるノードが端末として接続されることによって、共通の接続先を有するグループとしてまとめられる通信システムに適用される通信方法であって、前記グループに属するノードが、システム内通信用フレームに格納されている、当該通信システムが含むノードに接続される端末から受信したフレームを共通の接続先の端末またはノードに送信したか否かを示す識別子を、前記システム内通信用フレームに付加し、システム内通信用フレームを受信した場合に、前記システム内通信用フレームで示される情報に基づいて、前記システム内通信用フレームに格納されているフレームを共通の接続先の端末またはノードに送信するか否かを判定することを特徴とする。

また、グループに属するノードが、システム内通信用フレームに設定されている転送経路を示す経路情報を変更することによって、前記システム内通信用フレームの転送経路を変更してもよい。

また、グループに属さないノードが、システム内通信用フレームを受信した場合に、前記システム内通信用フレームで示される情報に基づいて、前記システム内通信用フレームに格納されているフレームを自ノードに接続される端末に送信するか否かを判定してもよい。

また、本発明によるノード用プログラムは、端末が接続される複数のノードを含む通信システムにおいて、前記複数のノードのうち、リンクを介して共通の端末または当該通信システムとは異なる通信システムに含まれるノードが端末として接続されることによって、共通の接続先を有するグループとしてまとめられるノードが備えるコンピュータに、システム内通信用フレームに格納されている、当該通信システムが含むノードに接続される端末から受信したフレームを共通の接続先の端末またはノードに送信したか否かを示す識別子を、前記システム内通信用フレームに付加する処理、およびシステム内通信用フレームを受信した場合に、前記システム内通信用フレームで示される情報に基づいて、前記システム内通信用フレームに格納されているフレームを共通の接続先の端末またはノードに送信するか否かを判定する処理を実行させることを特徴とする。

また、コンピュータに、システム内通信用フレームに設定されている転送経路を示す経路情報を変更することによって、前記システム内通信用フレームの転送経路を変更する処理を実行させてもよい。

また、グループに属さないノードが備えるコンピュータに、システム内通信用フレームを受信した場合に、前記システム内通信用フレームで示される情報に基づいて、前記システム内通信用フレームに格納されているフレームを自ノードに接続される端末に送信するか否かを判定する処理を実行させてもよい。

本発明によれば、共通の接続先を有するインタリンク接続ノードによって、１つのフレームに対して、複数あるインタリンクのうちのいずれか１つのみでフレーム転送を行うよう制御することができるので、障害が発生していない通常時に、フレームの多重受信およびブロードキャストストームの発生を防止した上で、複数のインタリンクにトラフィックを分散しつつ、インタリンク接続ノード同士の間でそれぞれフレーム転送を行うことができる。従って、ネットワーク間のリンクの通信帯域を拡大することができ、輻輳の発生を抑制することができる。

また、本発明によれば、インタリンクやインタリンク接続ノードの異常時においても、他の正常なインタリンクを経由してフレーム転送ができるので、通信を継続して行うことができる。従って、信頼性の高い通信システムを実現することができる。

また、本発明によれば、同じＲＰＲネットワーク内におけるインタリンク接続ノード同士で、自ノードに接続されたインタリンクの障害発生状況などの情報を相互に通知する必要がないため、特別なインタリンク接続ノード間プロトコルを要せず、障害復旧時間を短縮することができる。

実施の形態１．
図１は、本発明による通信システムの第１の実施の形態を示す説明図である。第１の実施の形態の通信システムは、ＲＰＲノード１００〜１７０を含むＲＰＲネットワーク１０と、ＲＰＲノード２００〜２７０を含むＲＰＲネットワーク２０とを備える。既に述べたように、ＲＰＲネットワークとは、ＲＰＲが適用されたネットワークである。

また、図１に例示する通信システムでは、ＲＰＲネットワーク１０，２０は、インタリンク４２０，４３０を介して相互に接続されている。なお、既に説明したようにインタリンクは、通信システムが備える異なるネットワーク間を接続するリンクである。本例では、ＲＰＲノード１００，１１０，２００，２７０がインタリンク接続ノードとなっている。

ＲＰＲノードは、”ＩＥＥＥ Ｓｔｄ ８０２．１７”に準拠して動作するノードである。本発明の通信システムが備えるＲＰＲノードのうち、インタリンク接続ノードであるＲＰＲノード（ＲＰＲノード１００，１１０，２００，２７０）は、”ＩＥＥＥ Ｓｔｄ ８０２．１７”に準拠して動作するだけでなく、他の動作（本発明の目的を実現するための動作）も行う。

第１の実施の形態では、各ＲＰＲノードはそれぞれ３つのポートＰ１，Ｐ２，Ｐ３を有する。ポートＰ１，Ｐ２は、ＲＰＲフレームを送受信するためのポートであり、各ＲＰＲノード１００〜１７０，２００〜２７０は、ポートＰ１，Ｐ２を用いて隣接するＲＰＲノードとＲＰＲフレームを送受信する。また、ポートＰ３は、配下に収容する端末との間でフレーム（イーサネットフレーム）を送受信するためのポートである。

ＲＰＲネットワーク１０，２０を接続させるインタリンク４２０は、ＲＰＲノード１００のポートＰ３と、ＲＰＲノード２００のポートＰ３との間に設けられる。同様に、インタリンク４３０は、ＲＰＲノード１１０のポートＰ３と、ＲＰＲノード２７０のポートＰ３との間に設けられる。ＲＰＲネットワーク１０に属するインタリンク接続ノード１００，１１０と、ＲＰＲネットワーク２０に属するインタリンク接続ノード２００，２７０とは、インタリンク４２０，４３０によって、それぞれ一対一に接続される。

なお、ＲＰＲネットワーク１０のインタリンク接続ノード１００，１１０にとっては、それぞれ、ＲＰＲネットワーク２０のインタリンク接続ノード２００，２７０が、配下に収容している端末となる。同様に、ＲＰＲネットワーク２０のインタリンク接続ノード２００，２７０にとっては、それぞれ、ＲＰＲネットワーク１０のインタリンク接続ノード１００，１１０が、配下に収容している端末となる。

図１では図示を省略しているが、インタリンク接続ノードであるＲＰＲノード１００，１１０，２００，２７０を除く、ＲＰＲノード１２０〜１７０，２１０〜２６０のポートＰ３には、図１９に示すＲＰＲネットワークと同様に、配下の端末（例えば、ユーザ端末）が１台収容されているものとする。

さらに、インタリンク接続ノードでない各ＲＰＲノード（ＲＰＲノード１２０〜１７０，２１０〜２６０）の配下の端末に、別のノードまたは他のネットワークが接続されていてもよい。ただし、インタリンク接続ノード以外の各ＲＰＲノードの配下に収容された端末に他の端末等が接続された結果、ループが形成されると、そのループに起因してブロードキャストストームが生じることにより、通信が不安定になる等の問題が生じる。よって、インタリンク接続ノード以外の各ＲＰＲノードの配下の端末に他の端末等が接続されることによりループが形成される構成となってはならない。

なお、本実施の形態では、インタリンク接続ノードによってループが形成される構成となっているが、本発明によるインタリンク接続ノードは、ブロードキャストストームの発生を防止することができるため、上記で示した構成の対象外とする。

図１に示す通信システムにおいて、同一のＲＰＲネットワークに属するＲＰＲノード間では、ＲＰＲフレームを転送（送受信）する。また、ＲＰＲノードとその配下の端末間（インタリンクを介したインタリンク接続ノード間を含む）では、イーサネットフレームを転送する。ＲＰＲフレームは、イーサネットフレームをペイロード（ヘッダ部分等を除いたデータ本体）としてカプセル化したフレームであり、ＲＰＲフレームのヘッダには、送信元および宛先（送信先）のアドレスやＴＴＬ（Time to Live）が含まれる。なお、ＲＰＲフレームの送信元および送信先のアドレスとして、ＲＰＲノードのアドレスや、ブロードキャスト送信を示すアドレス、あるいはマルチキャスト送信を示すアドレスが格納される。

次に、ＲＰＲノードの構成について説明する。図２は、図１に示す通信システムが備えるインタリンク接続ノードでないＲＰＲノードの構成例を示すブロック図である。また、図３は、図１に示す通信システムが備えるインタリンク接続ノードであるＲＰＲノードの構成例を示すブロック図である。

まず、インタリンク接続ノード以外のＲＰＲノードの構成について説明する。ここでは、図１に示すＲＰＲノード１２０を例に説明するが、他のＲＰＲノード１３０〜１７０，２１０〜２６０の構成も、ＲＰＲノード１２０の構成と同様である。

図２に示すように、ＲＰＲノード１２０は、入力ポート５００−１〜３と、ＲＰＲフレーム生成部５１０と、ＲＰＲスイッチ処理部５２０と、イーサネットフレーム抽出部５３０と、出力ポート５４０−１〜３と、ＦＤＢ５５０と、ＦＤＢ管理部５６０と、ＴＤＢ５７０と、ＭＡＣアドレス管理テーブル５８０と、ポート状態監視部５９０とを備える。

ＲＰＲノード１２０の入力ポート５００−１〜３は、図１に示すＲＰＲノード１２０のポートＰ１〜Ｐ３における受信側に対応するポート（フレームを受信するポート）である。入力ポート５００−１，２は、隣接するＲＰＲノードから送信されるＲＰＲフレームを受信するポートである。なお、入力ポート５００−１は、時計回り方向に隣接するＲＰＲノードから送信されるＲＰＲフレームを受信するポートであり、入力ポート５００−２は、反時計回り方向に隣接するＲＰＲノードから送信されるＲＰＲフレームを受信するポートである。また、入力ポート５００−３は、配下の端末（図示せず。）から送信されるイーサネットフレームを受信するポートである。

ＲＰＲノード１２０の出力ポート５４０−１〜３は、図１に示すＲＰＲノード１２０のポートＰ１〜Ｐ３における送信側に対応するポート（フレームを送信するポート）である。出力ポート５４０−１，２は、隣接するＲＰＲノードにＲＰＲフレームを送信するポートである。なお、出力ポート５４０−１は、時計回り方向に隣接するＲＰＲノードにＲＰＲフレームを送信するポートであり、出力ポート５４０−２は、反時計回り方向に隣接するＲＰＲノードにＲＰＲフレームを送信するポートである。また、出力ポート５４０−３は、配下の端末（図示せず。）にイーサネットフレームを送信するポートである。

具体的には、ＲＰＲノード１２０の入力ポート５００−１は、時計回り方向に隣接するＲＰＲノード１３０の出力ポート５４０−２から送信されるＲＰＲフレームを受信する。また、ＲＰＲノード１２０の入力ポート５００−２は、反時計回り方向に隣接するＲＰＲノード１１０の出力ポート５４０−１から送信されるＲＰＲフレームを受信する。また、ＲＰＲノード１２０の入力ポート５００−３は、配下の端末の出力ポートから送信されるイーサネットフレームを受信する。

また、ＲＰＲノード１２０の出力ポート５４０−１は、時計回り方向に隣接するＲＰＲノード１３０の入力ポート５００−２にＲＰＲフレームを送信する。また、ＲＰＲノード１２０の出力ポート５４０−２は、反時計回り方向に隣接するＲＰＲノード１１０の入力ポート５００−１にＲＰＲフレームを送信する。また、ＲＰＲノード１２０の出力ポート５４０−３は、配下の端末の入力ポートにイーサネットフレームを送信する。

ＲＰＲフレーム生成部５１０は、入力ポート５００−３から入力されるイーサネットフレームをカプセル化することにより、ＲＰＲフレームを生成する。

ＲＰＲスイッチ処理部５２０は、”ＩＥＥＥ Ｓｔｄ ８０２．１７”において定義されるＲＰＲに関する処理を行う。ＲＰＲスイッチ処理部５２０が行う処理の例として、隣接ＲＰＲノードから受信したＲＰＲフレームの転送、ＴＤＰ（Topology Discovery Protocol）によるＲＰＲネットワークのトポロジ情報の管理、ＦａｉｒｎｅｓｓによるＲＰＲネットワーク上のトラフィックの通信帯域の動的制御、ＯＡＭ（Operations, Administration, Maintenance）によるＲＰＲネットワークの管理等がある。以下の説明では、ＲＰＲスイッチ処理部５２０の処理の詳細については、本発明によるノードの動作に深く関わる動作を除き、説明を省略する。

イーサネットフレーム抽出部５３０は、ＲＰＲスイッチ処理部５２０から入力されるＲＰＲフレームのペイロードに格納されたイーサネットフレームを抽出する。

ＦＤＢ５５０は、自ノードと同一のＲＰＲネットワークに属するＲＰＲノードの配下に収容される端末を管理するためのデータベースである。ＦＤＢ５５０は、端末のノード識別子（ＭＡＣアドレス）と、その端末を収容しているＲＰＲノードのノード識別子（ＭＡＣアドレス）とを対応づけて記憶する。なお、ＦＤＢ５５０に記憶する対応関係は、後述のＦＤＢ管理部５６０によって登録される。ＲＰＲフレームを送受する過程で、このような対応関係をＦＤＢ５５０に登録していく処理を、ＭＡＣアドレス学習と呼ぶ。

図４は、ＲＰＲノード１２０のＦＤＢ５５０に登録された対応関係の例を示す説明図である。図４に示す例では、例えば、ＲＰＲノード１３０配下の端末のＭＡＣアドレスと、ＲＰＲノード１３０のＭＡＣアドレスとが対応づけられて登録されている。このことは、ＲＰＲノード１２０が、自ノード配下の端末から、ＲＰＲノード１３０配下の端末のＭＡＣアドレスを宛先ＭＡＣアドレスとするイーサネットフレームを受信した場合に、そのイーサネットフレームをカプセル化したＲＰＲフレームの宛先ＭＡＣアドレスをＲＰＲノード１３０のＭＡＣアドレスに設定すればよいことを意味する。つまり、イーサネットフレームの宛先ＭＡＣアドレスに対し、どのＲＰＲノード宛にＲＰＲフレームを送信すればよいのかを示している。

ＦＤＢ管理部５６０は、自ノード（そのＦＤＢ管理部５６０を備えるＲＰＲノード）の各種状態に応じて、または、自ノードが備える他の構成要素からの要求に従って、ＦＤＢ５５０に登録された内容を更新する。例えば、ＲＰＲノード１２０のＦＤＢ管理部５６０は、ＲＰＲフレーム受信時に、端末のＭＡＣアドレスとその端末を収容しているＲＰＲノードのＭＡＣアドレスとの対応関係をＦＤＢ５５０に登録することによってＭＡＣアドレス学習を行う。具体的には、ＦＤＢ管理部５６０は、イーサネットフレーム抽出部５３０からの要求により、自ノードが受信したＲＰＲフレームの送信元ＭＡＣアドレスと、そのＲＰＲフレームにペイロードとして格納されたイーサネットフレームの送信元ＭＡＣアドレスとを対応づけてＦＤＢ５５０に登録する。なお、端末とその端末を収容しているＲＰＲノードとの対応関係において、複数の端末に対し１つのＲＰＲノードが対応づけられることもあり得る。

ＴＤＢ（Topology DataBase）５７０は、自ノード（そのＴＤＢ５７０を備えるＲＰＲノード）が属するＲＰＲネットワークに関する情報を管理するためのデータベースである。ＴＤＢ５７０は、自ノードが属するＲＰＲネットワークのトポロジの状態および障害発生状況を示す情報を記憶する。例えば、ＴＤＢ５７０は、自ノードが属するＲＰＲネットワークに属する各ＲＰＲノードにおけるＲＰＲノード間リンクの障害状態を示す情報を、接続経路上の順番に記憶する。なお、ＴＤＢ５７０に記憶するＲＰＲネットワークに関する情報は、ＴＤＰ（Topology Discovery Protocol ）に従うＲＰＲスイッチ処理部５２０によって管理（登録）される。

図５は、ＲＰＲノード１２０のＴＤＢ５７０に登録された情報の例を示す説明図である。図５に示す例では、ＲＰＲノード１２０と同一のＲＰＲネットワーク（ＲＰＲネットワーク１０）に属する各ＲＰＲノードのポートＰ１，Ｐ２（隣接するＲＰＲノードとＲＰＲフレームを送受信するポート）の状態を示す情報が、ＲＰＲノード１００から時計回り方向の接続順に、ＲＰＲノードのノード識別子（ＭＡＣアドレス）と対応づけられて登録されている。すなわち、ＲＰＲネットワーク１０に属する各ＲＰＲノードがどのＲＰＲノードと接続されているか、および各ＲＰＲノードの隣接ＲＰＲノードとの接続ポートＰ１，Ｐ２がそれぞれ有効であるか無効であるかを示す情報が登録されている。有効とは、ポートを運用可能な状態を意味し、無効とは、ポートを運用できない状態を意味する。

図５に示す例では、例えば、ＲＰＲノード１４０は、時計回り方向ではＲＰＲノード１５０と接続され、反時計回り方向ではＲＰＲノード１３０と接続されていることが示されている。また、例えば、ＲＰＲノード１４０のポートＰ１（時計回り方向への転送ポート）のポート状態は無効であり、ポートＰ２（反時計回り方向への転送ポート）のポート状態は有効であることが示されている。このような情報がＴＤＢ５７０に登録されているということは、「ＲＰＲノード１４０は、ポートＰ１でＲＰＲフレームを送受信できない、かつ、ポートＰ２でＲＰＲフレームを送受信できる。」ということを意味している。また、例えば、図５では、ＲＰＲノード１５０のポートＰ２のポート状態は無効であることが示されている。この情報から、何らかの理由により、ＲＰＲノード１４０とＲＰＲノード１５０間リンクに障害が発生していることがわかる。

なお、他のノードのポート状態は、以下のように登録される。各ＲＰＲノードは、ＲＰＲネットワークのトポロジを管理するために、隣接するＲＰＲノードとＲＰＲフレームを送受信するポート（ポートＰ１，Ｐ２）の状態を格納したＴＰフレーム（Topology and Protection frame ）を一定の時間間隔でブロードキャスト送信する。ＲＰＲスイッチ処理部５２０は、各ＲＰＲノードから送信されるＴＰフレームを参照して、ＴＤＢ５７０に登録されている送信元ＲＰＲノードのポートＰ１，２の状態を更新する。また、自ノードのポートＰ１，２の状態は、ポート状態監視部５９０によって更新される。すなわち、ポート状態監視部５９０が、自ノードのポートＰ１，２の状態を監視し、監視した結果、ポートＰ１，２の状態に応じて、ＴＤＢ５７０に登録されている自ノードのポートＰ１，２の状態を更新する。

図５に示す例では、説明を簡単にするため、ＲＰＲノードのポート状態が有効か無効かを示す情報のみを示しているが、”ＩＥＥＥ Ｓｔｄ ８０２．１７”で定義されているＴＤＢでは、ＲＰＲネットワークを構成するＲＰＲノードに関する様々な情報が管理される。図１に示すＴＤＢ５７０は、これらの情報についても登録される。

ＭＡＣアドレス管理テーブル５８０は、自ノード（そのＭＡＣアドレス管理テーブル５８０を備えるＲＰＲノード）に対して、割り当てられたＭＡＣアドレスを管理するためのテーブルである。図６は、ＲＰＲノード１２０のＭＡＣアドレス管理テーブル５８０に登録される情報の例を示す説明図である。図６に示すように、ＲＰＲノード１２０のＭＡＣアドレス管理テーブル５８０は、自ノード（ＲＰＲノード１２０）のＭＡＣアドレスを含む。ＭＡＣアドレス管理テーブル５８０へのＭＡＣアドレスの登録は、予め通信システムの管理者によって、設定インタフェースを介して行われる。なお、ＭＡＣアドレス管理テーブル５８０は、具体的には、ＲＰＲノードが備えるメモリ等の記憶装置に記憶される。

なお、ＭＡＣアドレス管理テーブル５８０に登録されたＭＡＣアドレスは、ＲＰＲノードの他の構成要素によって参照される。少なくとも、ＲＰＲフレーム生成部５１０、ＲＰＲスイッチ処理部５２０およびイーサネットフレーム抽出部５３０は、ＭＡＣアドレス管理テーブル５８０に登録されたＭＡＣアドレスを参照する。

ポート状態監視部５９０は、自ノード（そのポート状態監視部５９０を備えるＲＰＲノード）の少なくとも入力ポート５００−１，２および出力ポート５４０−１，２の状態を監視するとともに、監視した状態に従って自ノードのＴＤＢ５７０に登録されている情報のうち、自ノードのポート状態に関する情報を更新する。ポート状態監視部５９０は、例えば、入力ポート５００−１が受信可能な状態であり、かつ、出力ポート５４０−１が送信可能な状態である場合に、ポートＰ１の状態に「有効」を登録し、それ以外の場合に「無効」を登録する。また、例えば、入力ポート５００−２が受信可能な状態であり、かつ、出力ポート５４０−２が送信可能な状態である場合に、ポートＰ２の状態に「有効」を登録し、それ以外の場合に「無効」を登録する。

次に、インタリンク接続ノードであるＲＰＲノードの構成について説明する。ここでは、図１に示すインタリンク接続ノード１００を例に説明するが、他のインタリンク接続ノード１１０，２００，２７０の構成も、インタリンク接続ノード１００の構成と同様である。本実施の形態において、インタリンク接続ノードであるＲＰＲノードは、”ＩＥＥＥ Ｓｔｄ ８０２．１７”に準拠して動作しつつ、他の動作（本発明の目的を実現するための動作）を行うノードである。図３に示すように、インタリンク接続ノードは、インタリンク接続ノードでないＲＰＲノードと比べ、ポート状態テーブル６００およびインタリンク接続ノード管理テーブル６１０が追加されている点、および、ポート状態監視部５９０が入力ポート５００−３および出力ポート５４０−３のポート状態も監視する点が異なる。また、ＲＰＲスイッチ処理部５２０が、”ＩＥＥＥ Ｓｔｄ ８０２．１７”において定義されるＲＰＲに関する処理を行うだけでなく、他の動作（本発明の目的を実現するための動作）を行う点が異なる。

ポート状態監視部５９０は、入力ポート５００−１，２および出力ポート５４０−１，２の状態を監視して、ＴＤＢ５７０に登録されている自ノードのポート状態を更新するとともに、入力ポート５００−３および出力ポート５４０−３のポート状態を監視して、その状態に従って自ノードのポート状態テーブル６００に登録されているポート状態に関する情報を更新する。ポート状態監視部５９０は、例えば、入力ポート５００−３が受信可能な状態であり、かつ、出力ポート５４０−３が送信可能な状態である場合に、ポート状態テーブル６００に「有効」を登録し、それ以外の場合に「無効」を登録する。

ポート状態テーブル６００は、自ノード（そのポート状態テーブル６００を備えるインタリンク接続ノード）のポートＰ３（配下の端末、すなわち他のＲＰＲネットワークとイーサネットフレームを送受信するポート）の状態を示す情報を管理するためのテーブルである。図７は、インタリンク接続ノード１００のポート状態テーブル６００に登録されるポート状態の例を示す説明図である。図７に示すように、インタリンク接続ノード１００のポート状態テーブル６００は、自ノードのポートＰ３の状態を示す情報を含む。なお、ポート状態テーブル６００は、具体的には、インタリンク接続ノードが備えるメモリ等の記憶装置に記憶される。

図７に示す例では、例えば、自ノードのポートＰ３のポート状態は無効であることが示されている。このような状態がインタリンク接続ノード１００のポート状態テーブル６００に登録されているということは、「インタリンク接続ノード１００は、ポートＰ３でイーサネットフレームを送受信できない。」ということを意味している。この情報から、何らかの理由により、ＲＰＲノード１００と他のＲＰＲネットワークとを接続するリンク（インタリンク４２０）に障害が発生していることがわかる。

なお、ポート状態テーブル６００に登録されるポートＰ３の状態は、インタリンク接続ノードの他の構成要素によって参照される。少なくとも、ＲＰＲスイッチ処理部５２０およびイーサネットフレーム抽出部５３０は、ポート状態テーブル６００に登録されるポートＰ３の状態を参照する。

インタリンク接続ノード管理テーブル６１０は、自ノード（そのインタリンク接続ノード管理テーブル６１０を備えるインタリンク接続ノード）と同一のＲＰＲネットワークに属するインタリンク接続ノードのうち、自ノードがインタリンクを介して接続される他のＲＰＲネットワークと同一のＲＰＲネットワークとインタリンクを介して接続されるインタリンク接続ノードを管理するためのテーブルである。以下、インタリンク接続ノードとインタリンクを介して接続される他のネットワークのことを、インタリンク接続先ネットワークと表現する。

インタリンク接続ノード管理テーブル６１０は、換言すれば、自ノードと同一のＲＰＲネットワークに属し、自ノードと同一のインタリンク接続先ネットワークと接続されるインタリンク接続ノードを管理するためのテーブルである。図８は、インタリンク接続ノード１００のインタリンク接続ノード管理テーブル６１０に登録された情報の例を示す説明図である。図８に示すように、インタリンク接続ノード１００のインタリンク接続ノード管理テーブル６１０は、ＲＰＲネットワーク１０に属するインタリンク接続ノードのうち、インタリンク接続ノード１００と同一のインタリンク接続先ネットワーク（ＲＰＲネットワーク２０）と接続されるインタリンク接続ノード、ＲＰＲノード１００とＲＰＲノード１１０のノード識別子（ＭＡＣアドレス）を含む。インタリンク接続ノード管理テーブル６１０へのインタリンク接続ノードのＭＡＣアドレスの登録は、予め通信システムの管理者によって、設定インタフェースを介して行われる。なお、インタリンク接続ノード管理テーブル６１０は、具体的には、インタリンク接続ノードが備えるメモリ等の記憶装置に記憶される。

なお、インタリンク接続ノード管理テーブル６１０に登録されたインタリンク接続ノードのＭＡＣアドレスは、インタリンク接続ノードの他の構成要素によって参照される。少なくとも、ＲＰＲスイッチ処理部５２０は、インタリンク接続ノード管理テーブル６１０に登録されたＭＡＣアドレスを参照する。

なお、インタリンク接続ノード管理テーブル６１０に、自ノードを含めたインタリンク接続ノードを登録することによって、自ノードがインタリンク接続ノードか否かを判断することが可能となる。例えば、インタリンク接続ノードが、インタリンク接続ノード管理テーブル６１０の登録内容に応じて、インタリンク接続ノードとして動作するか、そうでない標準のＲＰＲノードとして動作するかを切り替える切替手段を有することによって、インタリンク接続ノードとそうでないＲＰＲノードとを共通の装置を用いて実現することができる。例えば、インタリンク接続ノードとして動作可能なＲＰＲノードを用いてネットワークを構築することによって、ネットワークトポロジに応じてインタリンク接続ノード管理テーブル６１０の登録内容を変更するだけで、インタリンク接続ノードの配置を自在に変更することができる。なお、このような実装を行わない場合には、自ノードを含めなくてもよい。

次に、動作について説明する。まず、正常時の動作について説明する。具体的には、正常時に、ＲＰＲノード配下の端末間でインタリンク４２０，４３０のいずれか１つを介して、イーサネットフレームを送受信し合うときの動作について説明する。ここでは、ＲＰＲノード１４０配下の端末（図１において図示せず。以下、端末１４０１という。）およびＲＰＲノード２４０配下の端末（図１において図示せず。以下、端末２４０１という。）とがフレームを送受信し合う場合を例に説明する。

以下の説明では、イーサネットフレームを受信するＲＰＲノードにおいてＭＡＣアドレス学習が行われていない場合と、既にＭＡＣアドレス学習が行われている場合それぞれについて説明する。以下に説明する端末１４０１から端末２４０１へのフレーム転送は、イーサネットフレームを受信するＲＰＲノード（ＲＰＲノード１４０およびＲＰＲネットワーク２０に属するインタリンク接続ノード）において、端末２４０１に関するＭＡＣアドレス学習が行われていない場合の例である。

ここでは、端末１４０１から端末２４０１へのフレーム転送を行う時点で、各ＲＰＲノードのＦＤＢ５５０、およびインタリンク接続ノード管理テーブル６１０は、以下の状態になっているものとする。

ＲＰＲネットワーク１０およびＲＰＲネットワーク２０に属する全てのＲＰＲノードのＦＤＢ５５０には、情報が全く登録されていないものとする。すなわち、ＲＰＲノード１００〜１７０，２００〜２７０において、ＭＡＣアドレス学習は一切行われていないものとする。

また、ＲＰＲネットワーク１０に属するインタリンク接続ノードのインタリンク接続ノード管理テーブル６１０には、ＲＰＲネットワーク１０に属し、ＲＰＲネットワーク２０をインタリンク接続先ネットワークとするインタリンク接続ノードのＭＡＣアドレスが登録されているものとする。すなわち、インタリンク接続ノードであるＲＰＲノード１００，１１０のインタリンク接続ノード管理テーブル６１０には、ＲＰＲノード１００およびＲＰＲノード１１０のＭＡＣアドレスが登録されているものとする。

同様に、ＲＰＲネットワーク２０に属するインタリンクリンク接続ノードのインタリンク接続ノード管理テーブル６１０には、ＲＰＲネットワーク２０に属し、ＲＰＲネットワーク１０をインタリンク接続先ネットワークとするインタリンク接続ノードのＭＡＣアドレスが登録されているものとする。すなわち、インタリンク接続ノードであるＲＰＲノード２００，２７０のインタリンク接続ノード管理テーブル６１０には、ＲＰＲノード２００およびＲＰＲノード２７０のＭＡＣアドレスが登録されているものとする。

まず、端末１４０１は、ＲＰＲノード１４０に対して、宛先ＭＡＣアドレスを端末２４０１のＭＡＣアドレスとするイーサネットフレームを送信する。ＲＰＲノード１４０の入力ポート５００−３はそのイーサネットフレームを受信する。入力ポート５００−３が受信したイーサネットフレームは、ＲＰＲフレーム生成部５１０に送られる。すなわち、ＲＰＲノード１４０のＲＰＲフレーム生成部５１０は、入力ポート５００−３を介して、端末１４０１からのイーサネットフレームを入力する。

ＲＰＲノード１４０のＲＰＲフレーム生成部５１０は、イーサネットフレームの宛先ＭＡＣアドレスを検索キーとして、ＦＤＢ５５０を検索し、イーサネットフレームの宛先ＭＡＣアドレスが示す端末を配下に収容しているＲＰＲノードのＭＡＣアドレスを取得する。つまり、ＦＤＢ５５０から、イーサネットフレームの宛先ＭＡＣアドレスに対応づけられたＲＰＲノードのＭＡＣアドレスを検索して読み込む。取得に成功した場合には、ＲＰＲフレーム生成部５１０は、イーサネットフレームをカプセル化し、読み込んだＲＰＲノードのＭＡＣアドレスを宛先ＭＡＣアドレスとするＲＰＲフレームを生成する。

ここでは、ＦＤＢ５５０には情報が全く登録されていないため、ＲＰＲフレーム生成部５１０は、イーサネットフレームの宛先ＭＡＣアドレスに対応づけられたＲＰＲノードのＭＡＣアドレスの取得に失敗する。

ＲＰＲノードのＭＡＣアドレスの取得に失敗した場合、ＲＰＲフレーム生成部５１０は、宛先ＭＡＣアドレスにブロードキャスト用ＭＡＣアドレスを格納し、かつ、送信元ＭＡＣアドレスに自ノード（ＲＰＲノード１４０）のＭＡＣアドレスを格納し、かつ、ペイロードにイーサネットフレームを格納したＲＰＲフレームを生成する。ＲＰＲフレーム生成部５１０は、自ノードのＭＡＣアドレスについては、ＭＡＣアドレス管理テーブル５８０を参照することによって確認すればよい。ＲＰＲフレーム生成部５１０は、生成したＲＰＲフレームをＲＰＲスイッチ処理部５２０に送る。

ＲＰＲノード１４０のＲＰＲスイッチ処理部５２０は、ＲＰＲフレームの宛先ＭＡＣアドレスがブロードキャスト用ＭＡＣアドレスである場合、すなわち、ＲＰＲフレームがブロードキャストフレームである場合、ＲＰＲフレームをブロードキャスト送信する。

具体的には、ＲＰＲスイッチ処理部５２０は、ＲＰＲフレームのＴＴＬフィールドに、ＲＰＲネットワーク１０に属するＲＰＲノードのノード数（または自ノードを除くためノード数から１を減算した数）を格納した上で、出力ポート５４０−１または出力ポート５４０−２のいずれか一方から、ＲＰＲフレームを送信する。ＲＰＲスイッチ処理部５２０は、ＲＰＲネットワーク１０に属するＲＰＲノードのノード数については、ＴＤＢ５７０を参照することによって確認すればよい。

ここでは、ＲＰＲノード１４０のＲＰＲスイッチ処理部５２０が、ＲＰＲフレームのＴＴＬフィールドに、ＲＰＲネットワーク１０に属するＲＰＲノードのノード数から１を減算した数（＝７）を格納した上で、出力ポート５４０−２からＲＰＲフレームを送信する場合を例にして説明する。ＲＰＲノード１４０が出力ポート５４０−２からＲＰＲフレームを送信すると、ＲＰＲノード１３０がそのＲＰＲフレームを受信する。

図９は、インタリンク接続ノードでないＲＰＲノード（本例ではＲＰＲノード１３０）がブロードキャスト送信されたＲＰＲフレームを受信した場合の動作の一例を示すフローチャートである。基本的には、インタリンク接続ノードでないＲＰＲノードは、”ＩＥＥＥ Ｓｔｄ ８０２．１７”に準拠して動作すればよい。

ＲＰＲノード１３０は、入力ポート５００−１において、ＲＰＲノード１４０の出力ポート５４０−２から送信されたＲＰＲフレームを受信する（ステップＳ１０１）。ＲＰＲノード１３０の入力ポート５００−１が受信したＲＰＲフレームは、ＲＰＲスイッチ処理部５２０に送られる。すなわち、ＲＰＲノード１３０のＲＰＲスイッチ処理部５２０は、入力ポート５００−１を介して、ＲＰＲノード１４０からのＲＰＲフレームを入力する。

ＲＰＲノード１３０のＲＰＲスイッチ処理部５２０は、受信したＲＰＲフレームの送信元ＭＡＣアドレスが自ノードのＭＡＣアドレスである場合（ステップＳ１０２のＹｅｓ）、ループ構成によるブロードキャストストームの発生を防止するため、そのＲＰＲフレームを破棄する（ステップＳ１０３）。本例では、ＲＰＲフレームの送信元ＭＡＣアドレスは、ＲＰＲノード１４０のＭＡＣアドレスであるので、ＲＰＲノード１３０のＲＰＲスイッチ処理部５２０は、この破棄処理を行わない。なお、ＲＰＲスイッチ処理部５２０は、ＭＡＣアドレス管理テーブル５８０を参照することによって、自ノードのＭＡＣアドレスを確認すればよい。

次に、ＲＰＲスイッチ処理部５２０は、ＲＰＲフレームの送信元ＭＡＣアドレスが自ノードのＭＡＣアドレスでない場合であって、ＲＰＲフレームの宛先ＭＡＣアドレスがブロードキャスト用ＭＡＣアドレスである場合には、受信したＲＰＲフレームにカプセル化されたイーサネットフレームを配下の端末に転送するための制御（配下の端末への転送制御）、および、受信したＲＰＲフレームを隣接するＲＰＲノードに転送するための制御（隣接ＲＰＲノードへの転送制御）を行う。なお、配下の端末への転送に関する動作（ステップＳ１０４，Ｓ１０５）と隣接ＲＰＲノードへの転送に関する動作（ステップＳ１０６〜Ｓ１０８）とは、置き換えて動作させることも、並列して動作させることも可能である。ここでは、ＲＰＲスイッチ処理部５２０は、まず、配下の端末への転送制御を行う。

ＲＰＲスイッチ処理部５２０は、受信したＲＰＲフレームをイーサネットフレーム抽出部５３０に送る。このとき、ＲＰＲスイッチ処理部５２０は、受信したＲＰＲフレームを隣接するＲＰＲノードにも送信できるようＲＰＲフレームのコピーを生成した上で、イーサネットフレーム抽出部５３０に送る。

ＲＰＲノード１３０のイーサネットフレーム抽出部５３０は、ＲＰＲスイッチ処理部５２０から送られたＲＰＲフレームをデカプセル化し、ペイロードに格納されているイーサネットフレームを抽出する。そして、抽出したイーサネットフレームを自ノードの出力ポート５４０−３から自ノードの配下の端末に送信する（ステップＳ１０４）。また、イーサネットフレーム抽出部５３０は、イーサネットフレームを抽出する際に、受信したＲＰＲフレームに基づくＭＡＣアドレス学習を行うように、ＦＤＢ管理部５６０に要求する。

ＲＰＲノード１３０のＦＤＢ管理部５６０は、イーサネットフレーム抽出部５３０からの要求に従って、受信したＲＰＲフレームに基づくＭＡＣアドレス学習を行う（ステップＳ１０５）。ＦＤＢ管理部５６０は、受信したＲＰＲフレームのペイロードに格納されているイーサネットフレームの送信元ＭＡＣアドレス（ここでは、端末１４０１のＭＡＣアドレス）と、ＲＰＲフレームの送信元ＭＡＣアドレス（ここでは、ＲＰＲノード１４０のＭＡＣアドレス）との対応関係をＦＤＢ５５０に登録することによって、端末１４０１に関するＭＡＣアドレス学習を行う。

なお、本例では、ＦＤＢ５５０に情報が全く登録されていないので、ＦＤＢ管理部５６０は、イーサネットフレーム抽出部５３０からの要求に応じて対応関係をＦＤＢ５５０に登録する。仮に、イーサネットフレーム抽出部５３０から要求された対応関係が既にＦＤＢ５５０に登録済みである場合、ＦＤＢ管理部５６０は、イーサネットフレーム抽出部５３０からの要求を無視してもよい。なお、登録済みか否かをイーサネットフレーム抽出部５３０が確認し、ＦＤＢ管理部５６０に要求をださないようにすることも可能である。また、仮に、イーサネットフレーム抽出部５３０から要求された対応関係と異なる対応関係がＦＤＢ５５０に登録済みである場合には、ＦＤＢ管理部５６０は、ＦＤＢ５５０に登録されている情報を上書き更新する。

また、ＲＰＲスイッチ処理部５２０は、隣接ＲＰＲノードへの転送制御として、まず、受信したＲＰＲフレームに格納されたＴＴＬの値を１だけ減算する（ステップＳ１０６）。減算後のＴＴＬの値が０より大きければ、ＲＰＲスイッチ処理部５２０は、そのＲＰＲフレームを次のＲＰＲノードに送信する（ステップＳ１０７のＹｅｓ，Ｓ１０８）。具体的には、ＲＰＲノード１３０のＲＰＲスイッチ処理部５２０は、受信時の転送方向と同じ方向に転送するよう、自ノードの出力ポート５４０−２からＲＰＲノード１２０に減算後のＴＴＬを格納したＲＰＲフレームを送信する。また、減算した結果、ＴＴＬの値が０であれば、ＲＰＲスイッチ処理部５２０は、そのＲＰＲフレームを破棄する（ステップＳ１０７のＮｏ，Ｓ１０３）。

本例では、ＲＰＲノード１３０が受信するＲＰＲフレームに格納されたＴＴＬの値は、ＲＰＲノード１４０で設定されたＴＴＬの値（＝７）であるため、ＲＰＲスイッチ処理部５２０が１減算したとしても０にはならない。よって、ＲＰＲノード１３０は、隣接するＲＰＲノード１２０に減算したＴＴＬを格納したＲＰＲフレームを転送する。

以降、ＲＰＲネットワーク１０に属し、かつ、インタリンク接続ノードでないＲＰＲノード１２０，１７０，１６０，１５０は、上記のＲＰＲノード１３０と同様に動作し、ＲＰＲフレームを次のＲＰＲノードに転送する。従って、ＲＰＲノード１４０からブロードキャスト送信されたＲＰＲフレームは、ＲＰＲノード１３０およびＲＰＲノード１２０を経由して、インタリンク接続ノード１１０に転送される。

次に、図１０を参照して、ＲＰＲネットワーク１０に属するインタリンク接続ノードが、ブロードキャスト送信されたＲＰＲフレームを転送する動作について説明する。図１０は、インタリンク接続ノード（本例ではＲＰＲノード１１０）がブロードキャスト送信されたＲＰＲフレームを受信した場合の動作の一例を示すフローチャートである。

図１０に示すように、インタリンク接続ノードにおいて、送信元ＭＡＣアドレスが自ノードのＭＡＣアドレスであるブロードキャストフレームを受信した場合の動作（ステップＳ１０１〜１０３）、および隣接ＲＰＲノードへの転送に関する動作（ステップＳ１０６〜Ｓ１０８）は、上述のＲＰＲノード１３０と同様であるが、配下の端末（すなわちインタリンク接続先ネットワーク）への転送に関する動作（ステップＳ２０１〜Ｓ２０４）は、上述のＲＰＲネットワーク１３０の動作（ステップＳ１０４，Ｓ１０５）とは異なる。

すなわち、本実施の形態におけるインタリンク接続ノードは、受信したＲＰＲフレームがブロードキャストフレームであっても、条件によっては、自ノード配下の端末（すなわちインタリンク接続先ネットワーク）に対して、ＲＰＲフレームのペイロードに格納されているイーサネットフレームを送信しない場合がある。

ここでは、インタリンク接続ノード１１０がＲＰＲノード１２０から転送されてきたＲＰＲフレームを受信した場合を例にして説明するが、インタリンク接続ノード１００の動作もインタリンク接続ノード１１０と同様である。

インタリンク接続ノード１１０のＲＰＲスイッチ処理部５２０は、受信したＲＰＲフレームの送信元ＭＡＣアドレスが自ノードのＭＡＣアドレスでない場合であって、ＲＰＲフレームの宛先ＭＡＣアドレスがブロードキャスト用ＭＡＣアドレスである場合には（ステップＳ１０２のＮｏ）、まず、配下の端末（インタリンク接続先ネットワーク）にイーサネットフレームを送信するか否かを決定する。ＲＰＲスイッチ処理部５２０は、後述する条件に基づいて、ＲＰＲフレームのペイロードに格納されているイーサネットフレームを出力ポート５４０−３から送信するか否かを決定する。

ＲＰＲスイッチ処理部５２０は、受信したＲＰＲフレームの送信元ＭＡＣアドレスが、自ノードと同一のインタリンク接続先ネットワークに接続されるインタリンク接続ノードのＭＡＣアドレスであるか否かを判定する（ステップＳ２０１）。ＲＰＲスイッチ処理部５２０は、自ノードと同一のインタリンク接続先ネットワークと接続されるインタリンク接続ノードについては、インタリンク接続ノード管理テーブル６１０を参照することによって確認すればよい。

ここで、受信したＲＰＲフレームの送信元ノードが自ノードと同一のインタリンク接続先ネットワークと接続されるインタリンク接続ノードであるということは、そのＲＰＲフレームが、インタリンク接続先ネットワークに属するＲＰＲノードから送信元ＭＡＣアドレスが示すインタリンク接続ノードを経由して転送されたＲＰＲフレームであることを示している。このような場合には、ＲＰＲスイッチ処理部５２０は、再度そのＲＰＲフレームをインタリンク接続先ネットワークに転送することによるブロードキャストストームの発生を防止するため、インタリンクへの転送を行わないよう制御する。従って、ＲＰＲスイッチ処理部５２０は、受信したＲＰＲフレームの送信元ＭＡＣアドレスが自ノードと同一のインタリンク接続先ネットワークに接続されるインタリンク接続ノードのＭＡＣアドレスである場合には、配下の端末にイーサネットフレームを送信しない旨を決定する（ステップＳ２０１のＹｅｓ）。

また、ＲＰＲスイッチ処理部５２０は、そのＲＰＲフレームにフレーム送信済み識別子が付加されているか否かを判定する（ステップＳ２０２）。

ここで、フレーム送信済み識別子とは、ＲＰＲフレームにカプセル化されたイーサネットフレームが既に他のインタリンクを介してインタリンク接続先ネットワークに転送されていることを示す識別子である。フレーム送信済み識別子の表現方法としては、以下の例に示すように、様々な方法を用いることが可能である。例えば、ＲＰＲフレームのヘッダ内のフィールド、またはＲＰＲフレーム間のインタフレームギャップの未使用領域の１ビットを用いて、そのビットの値が１の場合にフレーム送信済み識別子が付加されていると定義し、０の場合にフレーム送信済み識別子が付加されていないと定義してもよい。

なお、未使用領域等を用いてフレーム送信済み識別子を表現する場合には、インタリンク接続ノードでないＲＰＲノードにおいて、フレーム送信済み識別子が付加されたＲＰＲフレームは正常フレームとして受信されなければならない。

また、インタリンク接続ノードでないＲＰＲノードとの相互接続性を考慮するならば、ＲＰＲフレームの宛先ＭＡＣアドレスを用いて表現する方法を用いてもよい。例えば、ＲＰＲフレームの宛先ＭＡＣアドレスが、予め定めておいた特殊マルチキャストＭＡＣアドレスである場合にフレーム送信済み識別子が付加されていると定義し、ブロードキャスト用ＭＡＣアドレスである場合にフレーム送信済み識別子が付加されていないと定義することも可能である。特殊マルチキャストＭＡＣアドレスをＲＰＲネットワークに属する全てのＲＰＲノードが属するグループのＭＡＣアドレスとして定義しておけば、その意味はブロードキャスト用ＭＡＣアドレスと等価である。

このような場合には、インタリンク接続ノードでないＲＰＲノードは、宛先ＭＡＣアドレスが特殊マルチキャストＭＡＣアドレスであるＲＰＲフレーム（マルチキャストフレーム）を、宛先ＭＡＣアドレスがブロードキャスト用ＭＡＣアドレスであるＲＰＲフレーム（ブロードキャストフレーム）と同様にフレーム転送するため、相互接続性を維持することが可能である。なお、特殊マルチキャストＭＡＣアドレスを用いてフレーム送信済み識別子を表現する場合には、そのマルチキャストＭＡＣアドレスは本来のマルチキャスト送信の目的に使用することはできないので、フレーム送信済み識別子として予約扱いにしなければならない。

なお、フレーム送信済み識別子は、配下の端末（インタリンク接続先ネットワーク）にイーサネットフレームを送信したインタリンク接続ノードによって付加される。

ＲＰＲスイッチ処理部５２０は、受信したＲＰＲフレームにフレーム送信済み識別子が付加されている場合には、既に他のインタリンク接続ノードによってインタリンク接続先ネットワークに送信済みであるとして、再度そのＲＰＲフレームをインタリンク接続先ネットワークに転送することによる転送先ネットワーク内での多重受信を防止するため、インタリンクへの転送を行わないよう制御する。従って、ＲＰＲスイッチ処理部５２０は、受信したＲＰＲフレームにフレーム送信済み識別子が付加されている場合には、配下の端末にイーサネットフレームを送信しない旨を決定する（ステップＳ２０２のＹｅｓ）。

また、ＲＰＲスイッチ処理部５２０は、自ノードのポートＰ３の状態が有効か否かを判定する（ステップＳ２０３）。ＲＰＲスイッチ処理部５２０は、自ノードのポートＰ３の状態については、ポート状態テーブル６００を参照することによって確認すればよい。ＲＰＲスイッチ処理部５２０は、自ノードのポートＰ３の状態が無効である場合には、インタリンク接続先ネットワークに転送不可能であるとして、インタリンク接続先ネットワークへの転送を行わないよう制御する。ＲＰＲスイッチ処理部５２０は、自ノードのポートＰ３の状態が無効である場合、すなわち、インタリンク４３０に障害が発生している場合には、配下の端末にイーサネットフレームを送信しない旨を決定する（ステップＳ２０３のＮｏ）。

また、ＲＰＲスイッチ処理部５２０は、上記以外の場合、すなわち、受信したＲＰＲフレームの送信元ＭＡＣアドレスが自ノードと同一のインタリンク接続先ネットワークに接続されるインタリンク接続ノードのＭＡＣアドレスでない場合であって、そのＲＰＲフレームにフレーム送信済み識別子が付加されていない場合であって、かつ、自ノードのポートＰ３のポート状態が有効である場合に、配下の端末（インタリンク接続先ネットワーク）にイーサネットフレームを送信する旨を決定する（ステップＳ２０１のＹｅｓ，Ｓ２０２のＹｅｓ,Ｓ２３０のＮｏ）。

次に、ＲＰＲスイッチ処理部５２０は、配下の端末にイーサネットフレームを送信する旨を決定した場合には、上述のＲＰＲノード１３０と同様にイーサネットフレームを配下の端末（インタリンク接続先ネットワーク）に送信する。すなわち、ＲＰＲスイッチ処理部５２０は、ＲＰＲフレームをイーサネットフレーム抽出部５３０に送る。イーサネットフレーム抽出部５３０は、ＲＰＲフレームからイーサネットフレームを抽出し、そのイーサネットフレームを、自ノードの出力ポート５４０−３から送信する（ステップＳ１０４）。また、この際、ＦＤＢ管理部５６０が、受信したＲＰＲフレームに基づいて、端末１４０１のＭＡＣアドレスとＲＰＲノード１４０のＭＡＣアドレスとの対応関係をＦＤＢ５５０に登録することによってＭＡＣアドレス学習を行う（ステップＳ１０５）。

一方、配下の端末にイーサネットフレームを送信しない旨を決定した場合には、ＲＰＲスイッチ処理部５２０は、ＲＰＲフレームをイーサネットフレーム抽出部５３０に送らず、配下の端末へのイーサネットフレームの送信も行わない。なお、配下の端末にイーサネットフレームを送信しない旨を決定した場合であっても、ＭＡＣアドレス学習については行ってもよい。

なお、ＲＰＲスイッチ処理部５２０は、配下の端末にイーサネットフレームを送信するか否かの決定に関わらず、ＴＴＬで示される許容範囲内で隣接するＲＰＲノードにＲＰＲフレームを転送する。隣接するＲＰＲノードへのＲＰＲフレームの転送は、上述のＲＰＲノード１３０の動作と同様の動作で実行する。すなわち、ＲＰＲスイッチ処理部５２０は、受信したＲＰＲフレームに格納されたＴＴＬの値を１だけ減算し（ステップＳ１０６）、減算後のＴＴＬの値が０より大きければ、そのＲＰＲフレームを次のＲＰＲノードに送信する（ステップＳ１０７のＹｅｓ，Ｓ１０８）。なお、ＴＴＬの値が０であれば、そのＲＰＲフレームを破棄する（ステップＳ１０７のＮｏ，Ｓ１０３）。

ただし、本実施の形態において、インタリンク接続ノードは、隣接するＲＰＲノードにＲＰＲフレームを転送する際に、配下の端末への転送有無に応じて次の動作を行う。ＲＰＲスイッチ処理部５２０は、配下の端末にイーサネットフレームを送信する旨を決定した場合には、自ノードによって既にインタリンク接続先ネットワークに転送されていることを示すため、受信したＲＰＲフレームにフレーム送信済み識別子を付加した上で（ステップＳ２０４）、そのＲＰＲフレームを次のＲＰＲノードに送信する。例えば、ＲＰＲスイッチ処理部５２０は、そのＲＰＲフレームのヘッダ内のフィールド、またはＲＰＲフレームに含まれるインタフレームギャップの未使用領域の１ビットの値を１に書き換えた上で、そのＲＰＲフレームを送信する。また、例えば、宛先アドレスを予め定めておいた特殊マルチキャストＭＡＣアドレスに書き換えた上で、そのＲＰＲフレームを送信する。

なお、自ノード以降からＴＴＬの値が０となるまでの経路上に、同一のインタリンク接続先ネットワークに接続されるインタリンク接続ノードが存在しない場合には、フレーム送信済み識別子を付加しなくてもよい。また、同様の場合、他のインタリンク接続ノードによって付加されたフレーム送信済み識別子を削除することも可能である。

本例では、インタリンク接続ノード１１０が受信するＲＰＲフレームは、その宛先ＭＡＣアドレスがブロードキャスト用ＭＡＣアドレスであり、かつ、送信元ＭＡＣアドレスがＲＰＲノード１４０のＭＡＣアドレスであり、かつ、フレーム送信済み識別子が付加されていないので、インタリンク接続ノード１１０は、配下の端末にイーサネットフレームを送信する旨を決定する。従って、インタリンク接続ノード１１０は、配下の端末であるＲＰＲノード２７０に受信したＲＰＲフレームにカプセル化されたイーサネットフレームを送信するとともに、次のＲＰＲノード（ＲＰＲノード１００）にフレーム送信済み識別子を付加したＲＰＲフレームを送信する。

なお、インタリンク接続ノードにおいては、既に説明したように、配下の端末への転送有無に応じて隣接するＲＰＲノードに転送するＲＰＲフレームにフレーム送信済み識別子を付加する必要があるため、ＲＰＲスイッチ処理部５２０は、配下の端末にイーサネットフレームを送信するか否かを決定した後に、隣接ＲＰＲノードへの転送制御を行わなければならない。なお、送信するか否かを決定した後は、配下の端末への転送に関する動作と隣接ＲＰＲノードへの転送に関する動作とを置き換えて動作させることも可能であるが、配下の端末への転送結果を受け取って、その結果に基づいて動作させることがより好ましい。

以降、ＲＰＲネットワーク１０に属し、かつ、インタリンク接続ノードであるＲＰＲノード１００は、上記のＲＰＲノード１１０と同様に動作し、ＲＰＲフレームを次のＲＰＲノードに転送する。なお、ＲＰＲノード１００においては、ＲＰＲノード１１０によってフレーム送信済み識別子が付加されていることから、配下の端末にイーサネットフレームを送信しない旨が決定される。従って、ＲＰＲノード１００は、配下の端末であるＲＰＲノード２００に受信したＲＰＲフレームにカプセル化されたイーサネットフレームを送信せずに、受信したＲＰＲフレームに格納されたＴＴＬの値を１だけ減算した上で、そのＲＰＲフレームを次のＲＰＲノード（ＲＰＲノード１７０）に送信する。

インタリンク接続ノード１００は、この際、自ノード以降からＴＴＬの値が０となるまでの経路上に、同一のインタリンク接続先ネットワークに接続されるインタリンク接続ノードが存在しないため、受信したＲＰＲフレームに付加されたフレーム送信済み識別子を削除した上で、ＲＰＲノード１７０にＲＰＲフレームを送信することも可能である。また、ＲＰＲノード１００は、配下の端末にイーサネットフレームを送信しない場合であっても、ＭＡＣアドレス学習については行ってもよい。

以上の動作によって、ＲＰＲノード１４０からブロードキャスト送信されたＲＰＲフレームは、ＲＰＲノード１３０およびＲＰＲノード１２０を経由して、インタリンク接続ノード１１０によってＲＰＲネットワーク２０のインタリンク接続ノード２７０に転送されるとともに、ＲＰＲノード１００，ＲＰＲノード１７０，ＲＰＲノード１６０，ＲＰＲノード１５０の順番で転送された後、ＲＰＲフレームのＴＴＬの値が０となるために、ＲＰＲノード１５０のＲＰＲスイッチ処理部５２０によって破棄される。なお、仮に、ＲＰＲノード１４０が自ノードを含むノード数（＝８）をＴＴＬに設定した場合には、ＲＰＲノード１５０がＲＰＲノード１４０に転送した後、送信元ＭＡＣアドレスが自ノードのＭＡＣアドレスと一致するために、ＲＰＲノード１４０のＲＰＲスイッチ処理部５２０によって破棄される。

また、仮に、ＲＰＲノード１４０が出力ポート５４０−１からＲＰＲフレームを送信した場合には、ＲＰＲフレームは、ＲＰＲノード１５０，ＲＰＲノード１６０およびＲＰＲノード１７０を経由して、インタリンク接続ノード１００によってＲＰＲネットワーク２０のインタリンク接続ノード２００に転送されるとともに、ＲＰＲノード１１０，ＲＰＲノード１２０およびＲＰＲノード１３０の順番で転送された後、ＲＰＲフレームのＴＴＬの値が０となるために、ＲＰＲノード１３０のＲＰＲスイッチ処理部５２０によって破棄される。

このように、本実施の形態におけるインタリンク接続ノードは、ブロードキャストフレームを受信した場合には、そのＲＰＲフレームのフレーム送信済み識別子を確認した上で、配下の端末（すなわちインタリンク接続先ネットワーク）にイーサネットフレームを送信するので、同一のインタリンク接続先ネットワークに接続されるインタリンクのうちのいずれか１つのみを用いてインタリンク接続先ネットワークに転送するという通信秩序を保ちながら、その時々のＲＰＲフレームの転送経路およびインタリンクの障害状態に応じて複数のインタリンクにトラフィックを分散することができる。

図１に示す例では、ＲＰＲノード１００，１１０のいずれか１つが、ブロードキャスト送信されたＲＰＲフレームに格納されたイーサネットフレーム（ＲＰＲノード１４０の配下の端末１４０１が送信したイーサネットフレーム）をインタリンク（インタリンク４２０，４３０）を介して、ＲＰＲネットワーク２０に転送する。

次に、ＲＰＲネットワーク１０からＲＰＲネットワーク２０にイーサネットフレームが転送されてから、そのイーサネットフレームがＲＰＲノード２４０の配下の端末に転送されるまでの動作について説明する。ここでは、既に説明したように、インタリンク接続ノード１１０によってインタリンク４３０を介してＲＰＲノード２７０にイーサネットフレームが転送された場合を例にして説明する。

インタリンク接続ノード１１０によってイーサネットフレームが送信されると、ＲＰＲネットワーク２０に属するインタリンク接続ノードであるＲＰＲノード２７０がそのイーサネットフレームを受信する。ＲＰＲノード２７０は、ＲＰＲノード１１０から送信されたイーサネットフレームを入力ポート５００−３で受信すると、ＲＰＲフレーム生成部５１０に送る。ＲＰＲノード２７０が配下の端末からイーサネットフレームを受信した場合の動作については、インタリンク接続ノードでないＲＰＲノードの場合と同様である。すなわち、前述のＲＰＲノード１４０と同様である。

本例では、ＲＰＲノード２７０は、イーサネットフレームの宛先ＭＡＣアドレス（ここでは、端末２４０１）に対応づけられたＲＰＲノードのＭＡＣアドレスの取得に失敗するため、宛先ＭＡＣアドレスにブロードキャスト用ＭＡＣアドレスを格納し、かつ、送信元ＭＡＣアドレスに自ノード（ＲＰＲノード２７０）のＭＡＣアドレスを格納し、かつ、ペイロードにイーサネットフレームを格納したＲＰＲフレームを生成する。そして、隣接するＲＰＲノード（ＲＰＲノード２００）にそのＲＰＲフレームを送信する。

以下、ＲＰＲノード２７０が、ＴＴＬフィールドに、ＲＰＲネットワーク２０に属するＲＰＲノードのノード数から１引いた数（＝７）を格納した上で、出力ポート５４０−１からＲＰＲフレームを送信する場合を例にして説明する。なお、ＲＰＲネットワーク２０に属する他のＲＰＲノード（インタリンク接続ノードであるＲＰＲノードおよびインタリンク接続ノード以外のＲＰＲノード）の動作は、ＲＰＲネットワーク１０に属するＲＰＲノードと同様である。

インタリンク接続ノードであるＲＰＲノード２００は、ＲＰＲノード２７０から送信されたＲＰＲフレームを受信する。インタリンク接続ノード２００が隣接するＲＰＲノードからブロードキャスト用ＭＡＣアドレスを受信した場合の動作は、前述のインタリンク接続ノード１００，１１０と同様である。

ここでは、インタリンク接続ノード２００は、受信したＲＰＲフレームの宛先ＭＡＣアドレスがブロードキャスト用ＭＡＣアドレスであっても、送信元ＭＡＣアドレスがＲＰＲノード２７０のＭＡＣアドレス、すなわち、自ノードと同一のインタリンク接続先ネットワークに接続されるインタリンク接続ノードのＭＡＣアドレスであることから、配下の端末にイーサネットフレームを送信しない旨を決定する。

従って、インタリンク接続ノード２００は、配下の端末であるＲＰＲノード１００にイーサネットフレームを送信せずに、受信したＲＰＲフレームに格納されたＴＴＬの値を１だけ減算した上で、そのＲＰＲフレームを次のＲＰＲノード（ＲＰＲノード２１０）に送信する。

以降、ＲＰＲネットワーク２０に属し、かつ、インタリンク接続ノードでないＲＰＲノード２１０，ＲＰＲノード２２０，ＲＰＲノード２３０，ＲＰＲノード２４０，ＲＰＲノード２５０，ＲＰＲノード２６０は、前述のＲＰＲノード１３０と同様に動作し、ＴＴＬで示される許容範囲内で次のＲＰＲノードにＲＰＲフレームを転送する。

従って、ＲＰＲノード２７０からブロードキャスト送信されたＲＰＲフレームは、ＲＰＲノード２１０，ＲＰＲノード２２０，ＲＰＲノード２３０，ＲＰＲノード２４０，ＲＰＲノード２５０，ＲＰＲノード２６０の順番に転送され、ＲＰＲノード２１０〜２６０配下の端末には、そのＲＰＲフレームに格納されたイーサネットフレームが送信される。

すなわち、本例では、端末１４０１から送信されたイーサネットフレームは、ＲＰＲノード１４０によってＲＰＲフレームにカプセル化され、ＲＰＲネットワーク１０に属する各ＲＰＲノードに転送されるうちに、インタリンク接続ノード１１０によって一旦デカプセル化され、ＲＰＲネットワーク２０に属するインタリンク接続ノード２７０に転送される。そして、インタリンク接続ノード２７０によって再度カプセル化され、ＲＰＲネットワーク２０の各ＲＰＲノードに転送されるうちに、ＲＰＲノード２４０によってデカプセル化され端末２４０１に転送される。

なお、ＲＰＲノード２７０からブロードキャスト送信されたＲＰＲフレームは、ＲＰＲノード２６０に転送された後、そのＴＴＬの値が０になるために、ＲＰＲノード２６０のＲＰＲスイッチ処理部５２０により廃棄される。また、ＲＰＲノード２１０〜２６０のＦＤＢ５５０には、ＭＡＣアドレス学習の結果、端末１４０１のＭＡＣアドレスとＲＰＲノード２７０のＭＡＣアドレスとの対応関係が登録される。なお、インタリンク接続ノード２００においても、ＭＡＣアドレス学習については行ってもよい。

なお、仮に、ＲＰＲノード２７０が出力ポート５４０−２からＲＰＲフレームを送信した場合には、ＲＰＲフレームは、ＲＰＲノード２６０，ＲＰＲノード２５０，ＲＰＲノード２４０，ＲＰＲノード２３０，ＲＰＲノード２２０，ＲＰＲノード２１０，ＲＰＲノード２００（インタリンク接続ノード２００）の順番で転送された後、ＲＰＲフレームのＴＴＬの値が０となるために、ＲＰＲノード２００のＲＰＲスイッチ処理部５２０によって破棄される。このような場合には、インタリンク接続ノード２００は、送信元ＭＡＣアドレスが自ノードと同一のインタリンク接続先ネットワークに接続されるインタリンク接続ノードのＭＡＣアドレスであることから、配下の端末にイーサネットフレームを転送しない旨を決定する。

また、仮に、ＲＰＲノード２００がインタリンク４２０を介してＲＰＲノード１００から送信されたイーサネットフレームを受信した場合には、送信元ＭＡＣアドレスをＲＰＲノード２００とするブロードキャストフレームが、出力ポート５４０−１、または、出力ポート５４０−２のいずれか一方から、送信されることになる。このような場合には、ＲＰＲネットワーク２０に属する各ＲＰＲノードのＦＤＢ５５０には、端末１４０１のＭＡＣアドレスとＲＰＲノード２００のＭＡＣアドレスとの対応関係が登録される。

次に、端末１４０１から端末２４０１にイーサネットフレームが転送されたことを前提として、端末２４０１から端末１４０１にイーサネットフレームを転送（返信）する場合の動作について説明する。以下に説明する端末２４０１から端末１４０１へのフレーム転送は、イーサネットフレームを受信するＲＰＲノード（ＲＰＲノード２４０およびＲＰＲネットワーク１０に属するインタリンク接続ノード）において、端末１４０１に関するＭＡＣアドレス学習が行われている場合の例である。

ここでは、端末２４０１から端末１４０１へのフレーム転送を行う時点で、各ＲＰＲノードのＦＤＢ５５０は、以下の状態になっているものとする。

ＲＰＲネットワーク１０に属する全てのＲＰＲノードのＦＤＢ５５０には、端末１４０１のＭＡＣアドレスと、ＲＰＲノード１４０のＭＡＣアドレスとの対応関係が登録されているものとする。また、ＲＰＲネットワーク２０に属する全てのＲＰＲノードのＦＤＢ５５０には、端末１４０１のＭＡＣアドレスと、ＲＰＲノード２７０のＭＡＣアドレスとの対応関係が登録されているものとする。なお、この状態は、上述の説明において配下の端末にイーサネットフレームを転送しないインタリンク接続ノードがＭＡＣアドレス学習を行っていた場合に相当する。

まず、端末２４０１は、ＲＰＲノード２４０に対して宛先ＭＡＣアドレスを端末１４０１とするイーサネットフレームを送信する。ＲＰＲノード２４０の入力ポート５００−３はそのイーサネットフレームを受信する。入力ポート５００−３が受信したイーサネットフレームは、ＲＰＲノード２４０のＲＰＲフレーム生成部５１０に送られる。

ＲＰＲノード２４０のＲＰＲフレーム生成部５１０は、イーサネットフレームの宛先ＭＡＣアドレスを検索キーとして、ＲＰＲノード２４０のＦＤＢ５５０を検索し、イーサネットフレームの宛先ＭＡＣアドレスが示す端末を配下に収容しているＲＰＲノードのＭＡＣアドレスを取得する。つまり、ＦＤＢ５５０から、イーサネットフレームの宛先ＭＡＣアドレス（端末１４０１のＭＡＣアドレス）に対応づけられたＲＰＲノードのＭＡＣアドレスを検索して読み込む。

ここでは、ＲＰＲフレーム生成部５１０は、ＲＰＲノード（ＲＰＲノード２７０）のＭＡＣアドレスの取得に成功する。ＭＡＣアドレスの取得に成功した場合には、取得したＭＡＣアドレスを宛先ＭＡＣアドレスに格納し、かつ、送信元ＭＡＣアドレスに自ノードのＭＡＣアドレスを格納し、かつ、ペイロードに自ノード配下の端末より受信したイーサネットフレームを格納したＲＰＲフレームを生成する。ＲＰＲフレーム生成部５１０は、生成したＲＰＲフレームをＲＰＲスイッチ処理部５２０に送る。なお、ＭＡＣアドレスの取得に失敗した場合には、前述のＲＰＲノード１４０の場合と同様に、ブロードキャスト用ＭＡＣアドレスを宛先ＭＡＣアドレスとする。

ＲＰＲノード２４０のＲＰＲスイッチ処理部５２０は、ＲＰＲフレームの宛先ＭＡＣアドレスがノード固有のＭＡＣアドレスである場合、すなわち、ＲＰＲフレームがユニキャストフレームである場合、ＲＰＲフレームをユニキャスト送信する。具体的には、ＲＰＲスイッチ処理部５２０は、ＲＰＲフレームのＴＴＬフィールドに、出力ポート５４０−１または出力ポート５４０−２のうち、実際にＲＰＲフレームを出力する側から宛先となるＲＰＲノードまでのホップ数を格納した上で、出力ポート５４０−１または出力ポート５４０−２のいずれか一方から、ＲＰＲフレームを送信する。ＲＰＲスイッチ処理部５２０は、自ノードから宛先ノードまでのホップ数については、出力ポートを定めた上で、ＴＤＢ５７０を参照することによって確認すればよい。

ここでは、ＲＰＲノード２４０のＲＰＲスイッチ処理部５２０が、出力ポート５４０−２からＲＰＲフレームを送信する場合を例にして説明する。この場合、ＴＴＬフィールドには、ＲＰＲノード２４０から反時計回りの経路におけるＲＰＲノード２７０までのホップ数（＝５）が格納される。ＲＰＲノード２４０が出力ポート５４０−２からＲＰＲフレームを送信すると、ＲＰＲノード２３０がそのＲＰＲフレームを受信する。

図１１は、インタリンク接続ノードでないＲＰＲノード（本例ではＲＰＲノード２３０）がユニキャスト送信されたＲＰＲフレームを受信した場合の動作の一例を示すフローチャートである。基本的には、インタリンク接続ノードでないＲＰＲノードは、”ＩＥＥＥ Ｓｔｄ ８０２．１７”に準拠して動作すればよい。

ＲＰＲノード２３０は、入力ポート５００−１において、ＲＰＲノード２４０の出力ポート５４０−２から送信されたＲＰＲフレームを受信する（ステップＳ１０１）。ＲＰＲノード２３０の入力ポート５００−１が受信したＲＰＲフレームは、ＲＰＲスイッチ処理部５２０に送られる。

ＲＰＲノード２３０のＲＰＲスイッチ処理部５２０は、まず、ＲＰＲフレームの送信元ＭＡＣアドレスが自ノードのＭＡＣアドレスである場合（ステップＳ１０２のＹｅｓ）、ループ構成によるブロードキャストストームの発生を防止するため、ＲＰＲフレームを破棄する（ステップＳ１０３）。本例では、ＲＰＲフレームの送信元ＭＡＣアドレスは、ＲＰＲノード２４０のＭＡＣアドレスであるので、ＲＰＲノード２３０のＲＰＲスイッチ処理部５２０は、この破棄処理を行わない。

次に、ＲＰＲスイッチ処理部５２０は、ＲＰＲフレームの送信元ＭＡＣアドレスが自ノードのＭＡＣアドレスでない場合であって、ＲＰＲフレームの宛先ＭＡＣアドレスがノード固有（ユニキャスト用）のＭＡＣアドレスである場合には、ＲＰＲフレームの宛先ＭＡＣアドレスが自ノードのＭＡＣアドレスか否かを判定する（ステップＳ３０１）。

ＲＰＲスイッチ処理部５２０は、受信したＲＰＲフレームの宛先ＭＡＣアドレスが、自ノードのＭＡＣアドレスである場合には、配下の端末への転送制御を行う（ステップＳ３０１のＹｅｓ）。配下の端末への転送制御は、前述のＲＰＲノード１３０と同様である。すなわち、ＲＰＲスイッチ処理部５２０は、受信したＲＰＲフレームのＭＡＣアドレスと自ノードのＭＡＣアドレスとが一致する場合には、そのＲＰＲフレームをイーサネットフレーム抽出部５３０に送る。イーサネットフレーム抽出部５３０は、ＲＰＲフレームからイーサネットフレームを抽出し、そのイーサネットフレームを、自ノードの出力ポート５４０−３から配下の端末に送信する（ステップＳ１０４）。また、この際、ＦＤＢ管理部５６０が、端末２４０１とＲＰＲノード２４０のＭＡＣアドレスの対応関係をＦＤＢ５５０に登録することによってＭＡＣアドレス学習を行う（ステップＳ１０５）。

一方、ＲＰＲスイッチ処理部５２０は、受信したＲＰＲフレームの宛先ＭＡＣアドレスが、自ノードのＭＡＣアドレスでない場合には、隣接ＲＰＲノードへの転送制御を行う（ステップＳ３０１のＮｏ）。なお、隣接ＲＰＲノードへの転送制御も、前述のＲＰＲノード１３０と同様である。すなわち、ＲＰＲスイッチ処理部５２０は、受信したＲＰＲフレームの宛先ＭＡＣアドレスと自ノードのＭＡＣアドレスとが一致しない場合には、そのＲＰＲフレームに格納されたＴＴＬの値を１だけ減算し（ステップＳ１０６）、減算後のＴＴＬの値が０より大きければ、そのＲＰＲフレームを次のＲＰＲノードに送信する（ステップＳ１０７のＹｅｓ，Ｓ１０８）。また、減算した結果、ＴＴＬの値が０であれば、ＲＰＲスイッチ処理部５２０は、そのＲＰＲフレームを破棄する（ステップＳ１０７のＮｏ，Ｓ１０３）。

本例では、ＲＰＲノード２４０から送信されたユニキャストフレームの宛先ＭＡＣアドレスは、ＲＰＲノード２３０のＭＡＣアドレスではないため、ＲＰＲノード２３０は、配下の端末にイーサネットフレームを送信せずに、ＴＴＬを減算した上で次のＲＰＲノード（ＲＰＲノード２２０）にＲＰＲフレームを転送する。

以降、ＲＰＲネットワーク２０に属し、かつインタリンク接続ノードでないＲＰＲノード２２０，２１０は、上記のＲＰＲノード２３０と同様に動作し、ＲＰＲフレームを次のＲＰＲノードに転送する。従って、ＲＰＲノード２４０からユニキャスト送信されたＲＰＲフレームは、ＲＰＲノード２３０，ＲＰＲノード２２０およびＲＰＲノード２１０を経由して、インタリンク接続ノードであるＲＰＲノード２００に転送される。なお、各ＲＰＲノードにおいて、配下の端末にイーサネットフレームを転送しない場合であっても、ＭＡＣアドレス学習については行ってもよい。

次に、図１２を参照して、ＲＰＲネットワーク２０に属するインタリンク接続ノード、すなわちＲＰＲノード２００，２７０が、ユニキャスト送信されたＲＰＲフレーム（宛先ＭＡＣアドレスがノード固有のＭＡＣアドレスであるＲＰＲフレーム）を転送する動作について説明する。

図１２は、インタリンク接続ノード（本例ではＲＰＲノード２００）がユニキャスト送信されたＲＰＲフレームを受信した場合の動作の一例を示すフローチャートである。図１２に示すように、送信元ＭＡＣアドレスが自ノードのＭＡＣアドレスであるユニキャストフレームを受信した場合の動作（ステップＳ１０１〜１０３）、および隣接ＲＰＲノードへの転送に関する動作（ステップＳ１０６〜Ｓ１０８）は、上述のＲＰＲノード２３０と同様であるが、配下の端末（すなわちインタリンク接続先ネットワーク）への転送に関する動作（ステップＳ２０１，Ｓ４０１〜Ｓ４０５，Ｓ１０４〜Ｓ１０５）は、上述のＲＰＲネットワーク２３０の動作（ステップＳ３０１，Ｓ１０４〜Ｓ１０５）とは異なる。

すなわち、本実施の形態におけるインタリンク接続ノードは、受信したＲＰＲフレームが自ノード宛以外のユニキャストフレームであっても、条件によっては、自ノード配下の端末（すなわちインタリンク接続先ネットワーク）に対して、ＲＰＲフレームのペイロードに格納されているイーサネットフレームを送信する場合がある。また、自ノード宛のユニキャストフレームを送信できなかった場合に隣接ＲＰＲノードにＲＰＲフレームを転送する場合がある。

ここでは、インタリンク接続ノード２００がＲＰＲノード２１０から転送されてきたＲＰＲフレームを受信した場合を例にして説明するが、インタリンク接続ノード２７０の動作もインタリンク接続ノード２００と同様である。

インタリンク接続ノード２００は、入力ポート５００−１において、ＲＰＲノード２１０の出力ポート５４０−２から送信されたＲＰＲフレームを受信する（ステップＳ１０１）。ＲＰＲノード２００の入力ポート５００−１が受信したＲＰＲフレームは、ＲＰＲスイッチ処理部５２０に送られる。

インタリンク接続ノード２００のＲＰＲスイッチ処理部５２０は、まず、ＲＰＲフレームの送信元ＭＡＣアドレスが自ノードのＭＡＣアドレスである場合（ステップＳ１０２のＹｅｓ）、ループ構成によるブロードキャストストームの発生を防止するため、ＲＰＲフレームを破棄する（ステップＳ１０３）。本例では、ＲＰＲフレームの送信元ＭＡＣアドレスは、ＲＰＲノード２４０のＭＡＣアドレスであるので、ＲＰＲノード２００のＲＰＲスイッチ処理部５２０は、この破棄処理を行わない。

次に、ＲＰＲスイッチ処理部５２０は、ＲＰＲフレームの送信元ＭＡＣアドレスが自ノードのＭＡＣアドレスでない場合であって、ＲＰＲフレームの宛先ＭＡＣアドレスがノード固有の（ユニキャスト用）ＭＡＣアドレスである場合には、そのＲＰＲフレームが自ノードのインタリンク接続先ネットワーク宛か否かを判定する。

まず、ＲＰＲスイッチ処理部５２０は、受信したＲＰＲフレームの送信元ＭＡＣアドレスが、自ノードと同一のインタリンク接続先ネットワークに接続されるインタリンク接続ノードのＭＡＣアドレスであるか否かを判定する（ステップＳ２０１）。

ＲＰＲフレームの送信元ＭＡＣアドレスが、自ノードと同一のインタリンク接続先ネットワークに接続されるインタリンク接続ノードのＭＡＣアドレスである場合には（ステップＳ２０１のＹｅｓ）、そのＲＰＲフレームはインタリンク接続先ネットワークから送信されたＲＰＲフレームであるとして、再度そのＲＰＲフレームをインタリンク接続先ネットワークに転送することによるブロードキャストストームの発生を防止するため、配下の端末への転送を行わないよう制御する。従って、そのＲＰＲフレームはインタリンク接続先ネットワーク宛でないと判定する。

また、ＲＰＲスイッチ処理部５２０は、そのＲＰＲフレームの宛先ＭＡＣアドレスが自ノードと同一のインタリンク接続先ネットワークに接続されるインタリンク接続ノード（自ノードを含む）のＭＡＣアドレスであるか否かを判定する（ステップＳ４０１）。ＲＰＲスイッチ処理部５２０は、例えば、ＲＰＲフレームの送信元ＭＡＣアドレスが、インタリンク接続ノード管理テーブル６１０に登録されているインタリンク接続ノードのＭＡＣアドレスと一致するか否かを判定する。なお、インタリンク接続ノード管理テーブル６１０に自ノードのＭＡＣアドレスを含まない場合には、さらに、ＭＡＣアドレス管理テーブル５８０に登録されている自ノードのＭＡＣアドレスと一致するか否かを判定すればよい。ＲＰＲフレームの宛先ＭＡＣアドレスが、自ノードと同一のインタリンク接続先ネットワークに接続されるインタリンク接続ノードのＭＡＣアドレスでない場合には（ステップＳ４０１のＮｏ）、ＲＰＲスイッチ処理部５２０は、そのＲＰＲフレームがインタリンク接続先ネットワーク宛でないと判定する。

また、ＲＰＲスイッチ処理部５２０は、上記以外の場合、すなわち、受信したＲＰＲフレームの送信元ＭＡＣアドレスが自ノードと同一のインタリンク接続先ネットワークに接続されるインタリンク接続ノードのＭＡＣアドレスでない場合であって、かつ、宛先ＭＡＣアドレスが自ノードと同一のインタリンク接続先ネットワークに接続されるインタリンク接続ノードのＭＡＣアドレスである場合には、そのＲＰＲフレームはインタリンク接続先ネットワーク宛であると判定する（ステップＳ２０１のＹｅｓ，Ｓ４０１のＮｏ）。

次に、ＲＰＲスイッチ処理部５２０は、受信したＲＰＲフレームがインタリンク接続先ネットワーク宛でないと判定した場合には、上述のＲＰＲノード２３０と同様に、隣接するＲＰＲノードにＲＰＲフレームを送信する。すなわち、ＲＰＲスイッチ処理部５２０は、そのＲＰＲフレームに格納されたＴＴＬの値を１だけ減算し（ステップＳ１０６）、減算後のＴＴＬの値が０より大きければ、そのＲＰＲフレームを次のＲＰＲノードに送信する（ステップＳ１０７のＹｅｓ，Ｓ１０８）。なお、減算した結果、ＴＴＬの値が０であれば、そのＲＰＲフレームを破棄する（ステップＳ１０７のＮｏ，Ｓ１０３）。

一方、受信したＲＰＲフレームがインタリンク接続先ネットワーク宛であると判定した場合には、ＲＰＲスイッチ処理部５２０は、自ノードのポートＰ３の状態が有効か否かを判定する（ステップＳ４０２）。ＲＰＲスイッチ処理部５２０は、受信したＲＰＲフレームがインタリンク接続先ネットワーク宛であって、自ノードのポートＰ３の状態が有効である場合には（ステップＳ４０２のＹｅｓ）、上述のＲＰＲノード２３０と同様に、イーサネットフレームを配下の端末（インタリンク接続先ネットワーク）に送信する。すなわち、ＲＰＲスイッチ処理部５２０は、ＲＰＲフレームをイーサネットフレーム抽出部５３０に送る。イーサネットフレーム抽出部５３０は、ＲＰＲフレームからイーサネットフレームを抽出し、そのイーサネットフレームを、自ノードの出力ポート５４０−３から自ノードの配下の端末（インタリンク接続先ネットワーク）に送信する（ステップＳ１０４）。また、この際、ＦＤＢ管理部５６０が、受信したＲＰＲフレームに基づいて、端末２４０１とＲＰＲノード２４０のＭＡＣアドレスの対応関係をＦＤＢ５５０に登録することによってＭＡＣアドレス学習を行う（ステップＳ１０５）。

また、ＲＰＲスイッチ処理部５２０は、受信したＲＰＲフレームがインタリンク接続先ネットワーク宛であっても、自ノードのポートＰ３の状態が無効である場合、すなわち、インタリンク４２０に障害が発生している場合には（ステップＳ４０２のＮｏ）、インタリンク接続先ネットワークに転送不可能であるとして、自ノードと同一のインタリンク接続先ネットワークに接続される他のインタリンク接続ノードにそのＲＰＲフレームが到達するよう、次のように動作する。

ＲＰＲスイッチ処理部５２０は、受信したＲＰＲフレームの宛先ＭＡＣアドレスが自ノードのＭＡＣアドレスでない場合には（ステップＳ４０３のＮｏ）、通常の隣接ＲＰＲノードへの転送制御を行う。すなわち、ＲＰＲスイッチ処理部５２０は、そのＲＰＲフレームに格納されたＴＴＬの値を１だけ減算し（ステップＳ１０６）、減算後のＴＴＬの値が０より大きければ、そのＲＰＲフレームを次のＲＰＲノードに送信する（ステップＳ１０７のＹｅｓ，Ｓ１０８）。また、減算した結果、ＴＴＬの値が０であれば、そのＲＰＲフレームを破棄する（ステップＳ１０７のＮｏ，Ｓ１０３）。

一方、受信したＲＰＲフレームの宛先ＭＡＣアドレスが自ノードのＭＡＣアドレスである場合には（ステップＳ４０３のＹｅｓ）、ＲＰＲスイッチ処理部５２０は、自ノードまで到達されるように設定されていたＴＴＬの値を、自ノードと同一のインタリンク接続先ネットワークに接続される他のインタリンク接続ノードまで到達されるよう設定しなおして、そのＲＰＲフレームを次のＲＰＲノードに転送する（ステップＳ４０４，Ｓ１０８）。すなわち、ＲＰＲスイッチ処理部５２０は、ＲＰＲフレームが自ノード宛であれば、そのＴＴＬの値を他のインタリンク接続ノードまでのホップ数に変更し、そのＲＰＲフレームを次のＲＰＲノードに送信する。

本例では、端末２４０１が送信したイーサネットフレームは、ＲＰＲノード２４０からＲＰＲノード２７０宛のユニキャストフレームとして送信されるので、インタリンク接続ノード２００は、宛先アドレスが自ノードと同一のインタリンク接続先ネットワークに接続されるインタリンク接続ノードのＭＡＣアドレスであるとして、インタリンク接続先ネットワーク宛であると判定する。従って、インタリンク接続ノード２００は、自ノードのポートＰ３が有効であれば、隣接するＲＰＲノード（ＲＰＲノード２７０）にはＲＰＲフレームを転送せずに、配下の端末であるＲＰＲノード１００にイーサネットフレームを送信する。

仮に、ＲＰＲネットワーク２０に属する各ＲＰＲノードのＦＤＢ５５０に、端末１４０１のＭＡＣアドレスとＲＰＲノード２００のＭＡＣアドレスとが対応づけられていたとしても、ＲＰＲノード２４０からＲＰＲノード２００宛のユニキャストフレームとして送信されるという点が違うだけで、転送動作は同様である。

また、仮に、ＲＰＲノード２４０が出力ポート５４０−１からＲＰＲフレームを送信した場合には、ＲＰＲフレームは、ＲＰＲノード２５０，２６０を経由して、インタリンク接続ノードであるＲＰＲノード２７０に転送される。ここで、ＲＰＲノード２７０は、受信したＲＰＲフレームが自ノードと同一のインタリンク接続先ネットワークに接続されるインタリンク接続ノード（ここでは、自ノード）のＭＡＣアドレスであるとして、インタリンク接続先ネットワーク宛であると判定する。従って、インタリンク接続ノード２７０は、自ノードのポートＰ３が有効であれば、隣接するＲＰＲノード（ＲＰＲノード２００）にはＲＰＲフレームを転送せずに、配下の端末であるＲＰＲノード１１０にイーサネットフレームを送信する。

このように、本実施の形態におけるインタリンク接続ノードは、ユニキャストフレームを受信した場合には、そのＲＰＲフレームが自ノード宛である場合に限らず、自ノードと同一のインタリンク接続先ネットワークと接続される他のインタリンク接続ノード宛である場合には、配下の端末（すなわちインタリンク接続先ネットワーク）にイーサネットフレームを送信するので、同一のインタリンク接続先ネットワークに接続されるインタリンクのうちのいずれか１つのみを用いてインタリンク接続先ネットワークに転送するという通信秩序を保ちながら、その時々のＲＰＲフレームの転送経路およびインタリンクの障害状態に応じて複数のインタリンクにトラフィックを分散することができる。

図１に示す例では、ＲＰＲノード２００，２７０のいずれか１つが、ユニキャスト送信されたＲＰＲフレームに格納されたイーサネットフレーム（ＲＰＲノード２４０の配下の端末２４０１が送信したイーサネットフレーム）をインタリンク（インタリンク４２０，４３０）を介して、ＲＰＲネットワーク１０に転送する。

次に、ＲＰＲネットワーク２０からＲＰＲネットワーク１０にイーサネットフレームが転送されてから、そのイーサネットフレームがＲＰＲノード１４０の配下の端末に転送されるまでの動作について説明する。ここでは、ＲＰＲノード２００によってインタリンク４２０を介してＲＰＲノード１００にイーサネットフレームが転送された場合を例にして説明する。

ＲＰＲネットワーク１０に属する各ＲＰＲノード（インタリンク接続ノードを含む）がユニキャストフレームを受信した場合の動作については、ＲＰＲネットワーク２０に属する各ＲＰＲノードと同様である。本例では、インタリンク接続ノードであるＲＰＲノード１００がＲＰＲノード２００から送信されたイーサネットフレームを受信すると、イーサネットフレームの宛先ＭＡＣアドレス（ここでは、端末１４０１）に対応づけられたＲＰＲノードのＭＡＣアドレス（ここでは、ＲＰＲノード１４０）の取得に成功するため、宛先ＭＡＣアドレスにＲＰＲノード１４０のＭＡＣアドレスを格納し、かつ、送信元ＭＡＣアドレスに自ノード（ＲＰＲノード１００）のＭＡＣアドレスを格納し、かつ、ペイロードにイーサネットフレームを格納したＲＰＲフレームを生成する。

ここで、ＲＰＲノード１００は、出力ポート５４０−２からＲＰＲフレームを転送する場合、そのＲＰＲフレームのＴＴＬフィールドに、ＲＰＲノード１００からＲＰＲノード１４０までの反時計回りの経路におけるホップ数（＝４）を格納した上で、次のＲＰＲノード（ＲＰＲノード１７０）にそのＲＰＲフレームを送信する。

以降、ＲＰＲノード１００から送信されたＲＰＲノード１４０宛のユニキャストフレームは、ＲＰＲノード１７０，ＲＰＲノード１６０，ＲＰＲノード１５０，ＲＰＲノード１４０の順番に転送され、ＲＰＲノード１４０によって、配下の端末１４０１にそのＲＰＲフレームに格納されたイーサネットフレームが送信される。

なお、仮に、ＲＰＲノード１００が、出力ポート５４０−１からＲＰＲフレームを転送する場合、そのＲＰＲフレームのＴＴＬフィールドには、ＲＰＲノード１００からＲＰＲノード１４０までの時計回りの経路におけるホップ数（＝４）が格納された上で、次のＲＰＲノード（ＲＰＲノード１１０）に転送される。ここで、インタリンク接続ノード１１０は、受信したＲＰＲフレームの送信元ノード（ＲＰＲノード１００）が自ノードと同一のインタリンク接続先ネットワークに接続されるインタリンク接続ノードであること、または、受信したＲＰＲフレームの宛先ノード（ＲＰＲノード１４０）が自ノードと同一のインタリンク接続先ネットワークに接続されるインタリンク接続ノードでないことから、インタリンク接続先ネットワーク宛でないと判定する。従って、配下の端末にイーサネットフレームを送信せずに、次のＲＰＲノード（ＲＰＲノード１２０）にＲＰＲフレームを転送する。

以上では、端末１４０１と端末２４０１間の通信を例に、正常時におけるフレーム転送の動作を説明した。本実施の形態では、正常時、異なるネットワーク間で転送されるイーサネットフレームが経由するインタリンクは、そのイーサネットフレームがカプセル化されたＲＰＲフレームを最初に受信したインタリンク接続ノードに接続されるインタリンクである。例えば、イーサネットフレームをカプセル化して隣接するＲＰＲノードに転送する際に、ＲＰＲフレーム毎に送信方向（時計回りと反時計回りのいずれか）を切り替える等の制御を行って、ＲＰＲフレーム毎に最初に受信するインタリンク接続ノードを分散させることにより、異なるネットワーク間を流れるトラフィックを複数のインタリンクに分散することが可能となる。従って、１つのインタリンクへトラフィックが集中することによる輻輳の発生を抑制することができるため、信頼性の高い通信システムを構築することが可能となる。

次に、いずれかのインタリンクに、切断などの障害が発生したときの障害回復動作について説明する。ここでは、インタリンク４２０に障害が発生した場合を例にして、インタリンク４３０のみでＲＰＲネットワーク間の通信を継続させる障害回復動作について説明する。

インタリンク４２０に障害が発生すると、例えば、ＲＰＲノード１００のポート状態監視部５９０は、自ノードのポートＰ３（入力ポート５００−３または出力ポート５４０−３）が無効（ポートを運用できない状態）になったことを検出する。そして、ポート状態監視部５９０は、ポート状態テーブル６００に登録されているポート状態を「無効」に変更する。同様に、ＲＰＲノード２００のポート状態監視部５９０も、自ノードのポートＰ３が無効になったことを検出し、ポート状態テーブル６００に登録されているポート状態を「無効」に変更する。

インタリンク接続ノードのブロードキャストフレームおよびユニキャストフレームの転送動作は、正常時におけるフレーム転送の動作の際に説明したように、自ノードのポートＰ３の状態が有効である場合にのみ、配下の端末（すなわち、インタリンクを経由してインタリンク接続先ネットワーク）にイーサネットフレームを転送する。

ここでは、最初に受信したインタリンク接続ノードに接続されるインタリンクに障害が発生した場合を例にとって障害回復動作について説明する。

例えば、各ＲＰＲノードにおいてＭＡＣアドレス学習が行われていない場合には、ＲＰＲノード１４０が、配下の端末１４０１から送信された端末２４０１宛のイーサネットフレームを格納したブロードキャストフレームを出力ポート５４０−１から送信すると、ＲＰＲノード１４０から転送されたブロードキャストフレームは、ＲＰＲノード１５０，１６０，１７０を経由して、インタリンク接続ノード１００に転送される。

ここで、インタリンク４２０に障害が発生している場合には、図１０に示すように、インタリンク接続ノード１００は、送信元ＭＡＣアドレスが自ノードのＭＡＣアドレスでないブロードキャストフレームを受信した場合であっても、自ノードのポートＰ３の状態が無効であるため、配下の端末にイーサネットフレームを送信しない旨を決定する。従って、配下の端末（インタリンク接続先ネットワーク）にイーサネットフレームを送信せずに、また、ＲＰＲフレームにフレーム送信済み識別子を付加することなく、次のＲＰＲノード（ＲＰＲノード１１０）にＲＰＲフレームを転送する。

そして、インタリンク接続ノード１１０は、送信元ＭＡＣアドレスが自ノードと同一のインタリンク接続先ネットワークに接続されるインタリンク接続ノードのＭＡＣアドレスでなく、フレーム送信済み識別子が付加されていないため、自ノードのポートＰ３が有効であれば、配下の端末にイーサネットフレームを送信する旨を決定する。従って、配下の端末（インタリンク接続先ネットワーク）にイーサネットフレームを送信するとともに、次のＲＰＲノード（ＲＰＲノード１２０）にＲＰＲフレームを転送する。なお、この場合、インタリンク接続ノード１１０からＴＴＬの値が０となるまでの経路上に、同一のインタリンク接続先ネットワークに接続されるインタリンク接続ノードが存在しないため、フレーム送信済み識別子を付加しなくてもよい。

また、例えば、各ＲＰＲノードにおいてＭＡＣアドレス学習が行われている場合には、ＲＰＲノード１４０は、配下の端末１４０１から送信された端末２４０１宛のイーサネットフレームを格納したＲＰＲフレームを、例えば宛先ＭＡＣアドレスをＲＰＲノード１００のＭＡＣアドレスとするユニキャストフレームとして出力ポート５４０−１から送信する。

ここで、インタリンク４２０に障害が発生している場合には、図１２に示すように、インタリンク接続ノード１００は、送信元ＭＡＣアドレス（ＲＰＲノード１４０のＭＡＣアドレス）が自ノードと同一のインタリンク接続先ネットワークに接続されるインタリンク接続ノードのＭＡＣアドレスでなく、かつ、宛先ＭＡＣアドレス（ここでは、ＲＰＲノード１００のＭＡＣアドレス）が自ノードと同一のインタリンク接続先ネットワークに接続されるインタリンク接続ノードのＭＡＣアドレスであるユニキャストフレームを受信した場合であっても、自ノードのポートＰ３の状態が無効であるため、配下の端末にイーサネットフレームを送信しない。そして、インタリンク接続ノード１００は、他のインタリンク接続ノードにＲＰＲフレームが到達されるよう、ＴＴＬの値を自ノードから他のインタリンク接続ノードまでのホップ数（ここでは、ＲＰＲノード１１０までの１ホップ）に変更した上で、次のＲＰＲノード（ＲＰＲノード１１０）にそのＲＰＲフレームを転送する。

そして、インタリンク接続ノードであるＲＰＲノード１１０によって、自ノードのインタリンク接続先ネットワーク宛であると判定された上で、インタリンク４３０を介してＲＰＲノード２７０に送信される。

なお、ＲＰＲノード１４０が出力ポート５４０−２から送信する場合には、インタリンク接続ノード１１０が、ブロードキャストフレームであっても、ＲＰＲノード１００宛のユニキャストフレームであっても、インタリンク４２０の障害状態に関わらず、正常時と同様に、インタリンク４３０を介してインタリンク接続先ネットワークに転送する。

その後、ブロードキャストフレームについては、フレーム送信済み識別子が付加された上で、ＲＰＲノード１００に転送される。なお、ＲＰＲノード１００は、受信したＲＰＲフレームにフレーム識別子が付加されていることから、例えこの時点でインタリンク４２０の障害が復旧していたとしても配下の端末にイーサネットフレームを送信せずに、次のＲＰＲノード（ＲＰＲノード１７０）に転送する。

以上に説明したように、本実施の形態によれば、インタリンク４２０に障害が発生していたとしても、インタリンク接続ノード１１０によって、正常なインタリンク４３０を経由して転送されるため、ＲＰＲネットワーク１０とＲＰＲネットワーク２０間の通信を続行することが可能である。

また、インタリンク接続ノードは、障害発生時においても、受信したＲＰＲフレームの情報と、自ノードにおけるインタリンク接続ポート（ポートＰ３）の状態とに基づいて、イーサネットフレームをインタリンクに送信するか否かを決定することができるため、例えば、インタリンク接続ノード間で特別な制御フレームをやりとりすることなく、トラフィック制御することが可能である。

なお、インタリンクの障害が復旧した場合には、そのインタリンクに接続されているインタリンク接続ノード（ここでは、ＲＰＲノード１００およびＲＰＲノード２００）が障害の復旧を検出し、自ノードのインタリンク接続ポート（ポートＰ３）の状態を有効に変更することによって、正常時のフレーム転送動作に戻る。すなわち、インタリンク４２０およびインタリンク４３０の両方にトラフィックを分散しながらフレームを転送する状態に復帰する。ここで、正常時のフレーム転送動作に戻るか否かも、自ノードにおけるインタリンク接続ポートの状態の基づいて判断することができるため、他のインタリンク接続ノードと障害情報を相互に通知し合う等のノード間プロトコルを要することなく、高速に復帰することができる。

次に、いずれかのインタリンク接続ノードに障害が発生したときの障害回復動作について説明する。ここでは、インタリンク接続ノードであるＲＰＲノード１００に障害が発生した場合を例にして説明する。なお、ＲＰＲノード１００に障害が発生した場合には、ＲＰＲネットワーク１０に属するインタリンク接続ノードでないＲＰＲノードは、”ＩＥＥＥ Ｓｔｄ ８０２．１７”に準拠して動作することによって、トラフィックを操作する。

このような障害が発生した場合、ＲＰＲネットワーク１０に属する他のＲＰＲノードは、”ＩＥＥＥ Ｓｔｄ ８０２．１７”に規定されているＴＤＰ（Topology Discovery Protocol ）によって、ＲＰＲノード１００との通信が不可能になったことを認識する。具体的には、ＲＰＲノード１００と隣接するノードが、それぞれＲＰＲノード１００との間でＲＰＲフレームを送受信するポートの異常を検出する。そして、そのポートの異常を示すＴＰフレームを一定の時間間隔でブロードキャスト送信することによって、他のＲＰＲノードに通知する。ＴＰフレームを受信した各ＲＰＲノードは、自ノードのＴＤＢ５７０を更新する。そして、各ＲＰＲノードは、自ノードのＴＤＢ５７０に基づいて、ＲＰＲノード１００に向かうＲＰＲフレームを迂回させる。

例えばブロードキャストフレームであれば、Ｗｒａｐｐｉｎｇと呼ばれるプロテクション機能を用いて通信方向やＴＴＬ等を制御することによって、ＲＰＲノード１００を迂回しながらＲＰＲノード１００を除くＲＰＲネットワーク１０に属する全てのＲＰＲノードに転送することができる。また、例えばＲＰＲノード１１０宛のユニキャストフレームであれば、ＳｔｅｅｒｉｎｇまたはＷｒａｐｐｉｎｇと呼ばれるプロテクション機能を用いることによって、ＲＰＲノード１００を迂回しながらＲＰＲノード１１０に転送することができる。

また、例えばＲＰＲノード１００宛のユニキャストフレームであったとしても、Ｗｒａｐｐｉｎｇと呼ばれるプロテクション機能を用いて、ＲＰＲノード１００を迂回する過程で他のインタリンク接続ノードであるＲＰＲノード１１０が受け取ることができる。例えば、障害発生前にあるＲＰＲノードから時計回り方向に送信されたＲＰＲノード１００宛のユニキャストフレームであれば、ＲＰＲノード１７０によって、その転送方向を逆向き（反時計回り）に変更され転送される。結果、ＲＰＲノード１６０，ＲＰＲノード１５０，ＲＰＲノード１４０，ＲＰＲノード１３０，ＲＰＲノード１２０を経由してＲＰＲノード１１０まで転送される。なお、転送方向が変更された後は、ＲＰＲフレームのＴＴＬは減算されないため、ＲＰＲノード１１０が受信するＲＰＲフレームのＴＴＬは、ＲＰＲノード１７０からＲＰＲノード１００までのホップ数（１ホップ）のままである。また、障害発生後であれば、ＲＰＲノード１００宛のＲＰＲフレームはブロードキャストフレームとして送信されるため、ＲＰＲノード１００を迂回しながらＲＰＲノード１００を除くＲＰＲネットワーク１０に属する全てのＲＰＲノードに転送することができる。

インタリンク接続ノードであるＲＰＲノード１１０に転送されると、ＲＰＲノード１１０によって、ＲＰＲフレームに格納されたイーサネットフレームがインタリンク４２０を介してＲＰＲノード２７０に送信される。なお、インタリンク接続ノード１１０がイーサネットフレームを配下の端末に送信する動作は、前述のインタリンク４２０に障害が発生した場合と同様である。

以上に説明したように、インタリンク接続ノードであるＲＰＲノード１００に障害が発生していたとしても、他のＲＰＲノードが、”ＩＥＥＥ Ｓｔｄ ８０２．１７”に規定されているＷｒａｐｐｉｎｇやＳｔｅｅｒｉｎｇと呼ばれるプロテクション機能を用いることによって、他のインタリンク接続ノードであるＲＰＲノード１１０に転送される。そして、インタリンク接続ノード１１０によって、正常なインタリンク４３０を経由して転送されるので、ＲＰＲネットワーク１０からＲＰＲネットワーク２０への通信は続行される。

また、ＲＰＲネットワーク２０からＲＰＲネットワーク１０への通信については、インタリンク接続ノード１００とインタリンクを介して接続されるインタリンク接続ノード２００のポート状態監視部５９０がインタリンク４２０の障害を検出することによって、前述のインタリンク障害時における障害回復動作と同様に、他のインタリンク（インタリンク４３０）を経由するよう制御されて、続行することができる。

次に、いずれかのインタリンク接続ノードとその隣接ＲＰＲノード間のリンクの両方に障害が発生したときの障害回復動作について説明する。ここでは、ＲＰＲノード１００とＲＰＲノード１７０間のリンク、および、ＲＰＲノード１００とＲＰＲノード１１０間のリンクに障害が発生した場合を例にして説明する。

このような障害が発生した場合、ＲＰＲネットワーク１０に属する他のＲＰＲノードは、”ＩＥＥＥ Ｓｔｄ ８０２．１７”に規定されているＴＤＰ（Topology Discovery Protocol ）によって、ＲＰＲノード１００との通信が不可能になったことを認識する。ここで、ＲＰＲネットワーク１０からＲＰＲネットワーク２０への通信は、前述のインタリンク接続ノード１００に障害が発生したときの障害回復動作と同様の動作によって、続行することができる。

しかしながら、ＲＰＲネットワーク２０からＲＰＲネットワーク１０への通信については、インタリンク４２０に障害が発生していないため、インタリンク接続ノード２００において事実上インタリンク４２０が使用不可能になったことが認識されない。このため、インタリンク接続ノード２００が正常時と同様にインタリンク４２０とインタリンク４３０とにトラフィックを分散してフレームを転送し続けることによって、通信が遮断される事態が生じる恐れがある。

この問題を回避するために、本実施の形態によるインタリンク接続ノードでは、自ノード（ＲＰＲノード１００）と隣接するＲＰＲノード（ＲＰＲノード１１０およびＲＰＲノード１７０）間の２つのリンクの両方に障害が発生した場合に、インタリンクの接続先ノード（ＲＰＲノード２００）にインタリンクの障害を検出させるため、インタリンク側ポート（ポートＰ３）を故意にダウン（停止）させる。例えば、ポート状態監視部５９０がポートＰ３を閉じたり、ＲＰＲスイッチ処理部５２０がリンクの障害を検出するための制御フレームのやりとりを停止する等の制御を行う。

結果、インタリンク接続ノード２００がインタリンク４２０の異常を検出し、前述のインタリンク障害時の障害回復動作と同様に、他のインタリンクを経由するよう制御することによって、ＲＰＲネットワーク２０からＲＰＲネットワーク１０への通信も続行することが可能となる。

なお、ＲＰＲノード１００は、自ノードと隣接するＲＰＲノード間の２つのリンクのうちいずれかの障害が復旧した場合には、インタリンクの接続先ノードにインタリンクの障害復旧を検出させるため、インタリンク側ポートをアップ（再開）させる。例えば、ポートを開いたり、リンクの障害を検出するための制御フレームのやりとりを再開する等の制御を行う。

以上のように、インタリンク接続ノードとその隣接ＲＰＲノード間のリンクの両方に障害が発生した場合であっても、インタリンク接続ノードのインタリンク側ポートを故意に停止することにより、ＲＰＲネットワーク１０とＲＰＲネットワーク２０間の通信を維持することが可能である。

なお、ＲＰＲネットワーク１０またはＲＰＲネットワーク２０のいずれか一方、または両方において、ＲＰＲノード間のリンクに障害が発生した場合、もしくは、インタリンク接続ノード以外のＲＰＲノードに障害が発生した場合にも、各ＲＰＲノードが、”ＩＥＥＥ Ｓｔｄ ８０２．１７”に規定されているＳｔｅｅｒｉｎｇやＷｒａｐｐｉｎｇを用いることによって、正常なＲＰＲノード間で通信を続行させる。つまり、宛先までの経路の全てが遮断されていない限り、ＲＰＲネットワーク１０とＲＰＲネットワーク２０間の通信を継続することが可能である。

以上のように、本実施の形態によれば、異なるネットワーク間のフレーム転送において、１つのＲＰＲフレームに対し、同一のインタリンク接続先ネットワークに接続されるインタリンクのうちのいずれか１つのみを用いてインタリンク接続先ネットワークに転送するという通信秩序を保ちながら、その時々のＲＰＲフレームの転送経路およびインタリンクの障害状態に応じて複数のインタリンクにトラフィックを分散させることができるので、フレームの多重受信およびブロードキャストストームの発生を防止しつつ、ネットワーク間のリンクの通信帯域を拡大して輻輳の発生を抑制することができる。

また、本実施の形態では、１つのインタリンク接続ノードのみがインタリンクを介してそのＲＰＲフレームに格納されたイーサネットフレームを転送するので、特にトラフィックが集中しやすいインタリンクに余計なフレームを転送することがなく、より効果的に輻輳の発生を抑制することができる。

また、インタリンクやインタリンク接続ノードに障害が発生した場合であっても、他の正常なインタリンクを経由してフレームを転送することができるので、通信を継続して行うことができる。

さらに、上記効果は、インタリンク接続ノード間で特別に情報をやりとりするようなインタリンク接続ノード間プロトコルを要しないので、余計なトラフィックを発生させることなく、また障害発生時には、従来技術と比べて非常に高速に障害回復処理を開始することができる。

実施の形態２．
以下に、本発明の第２の実施の形態について、図面を参照して説明する。本実施の形態による通信システムの構成は、図１に示す第１の実施の形態と同様である。また、本実施の形態によるＲＰＲノードおよびインタリンク接続ノードの構成も、図２，３に示す第１の実施の形態と同様である。

本実施の形態による通信システムは、ＲＰＲネットワークにおけるブロードキャストフレームの転送方法が第１の実施の形態と異なる。第１の実施の形態では、”ＩＥＥＥ Ｓｔｄ ８０２．１７”においてＵｎｉｄｉｒｅｃｔｉｏｎａｌ Ｂｒｏａｄｃａｓｔと呼ばれるブロードキャスト転送方法でブロードキャストフレームを転送する例を示した。Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｂｒｏａｄｃａｓｔと呼ばれるブロードキャスト転送方法は、ＲＰＲフレームのＴＴＬフィールドに、ＲＰＲネットワークを構成するＲＰＲノードのノード数、またはノード数から１を引いた数を設定した上で、時計回り方向と反時計回り方向のいずれか１つの方向に送信する方法である。

一方、”ＩＥＥＥ Ｓｔｄ ８０２．１７”では、Ｂｉｄｉｒｅｃｔｉｏｎａｌ Ｂｒｏａｄｃａｓｔと呼ばれるブロードキャスト転送方法も開示している。Ｂｉｄｉｒｅｃｔｉｏｎａｌ Ｂｒｏａｄｃａｓｔと呼ばれるブロードキャスト転送方法は、ＲＰＲフレームを複製し、各ＲＰＲフレームのＴＴＬフィールドに、ＲＰＲネットワークを構成するＲＰＲノードのノード数から１を減算した値の１／２の値を設定した上で、一方を時計回り方向に、他方を反時計回り方向に送信する方法である。

例えば、ノード数が偶数の場合は、一方のＲＰＲフレームのＴＴＬフィールドにノード数から１を減算した値の１／２の値を超えない最大の自然数を、他方にはノード数から１を減算した値の１／２の値を超える最小の自然数を設定する。

両方向に送信された各ブロードキャストフレームは、それぞれのＴＴＬの値が０になるまで、順番に次のＲＰＲノードに転送され、ＴＴＬが０になった時点で破棄される。なお、両方向に送信された各ブロードキャストフレームが破棄されるＲＰＲノード間のリンクは、Ｃｌｅａｖｅ Ｐｏｉｎｔと呼ばれる。

例えば、図１に示す通信システムにおいて、ＲＰＲノード１４０から送信されるブロードキャストフレームは、Ｂｉｄｉｒｅｃｔｉｏｎａｌ Ｂｒｏａｄｃａｓｔによる転送では、時計回り方向に転送するＲＰＲフレームのＴＴＬには４、反時計回り方向に転送するＲＰＲフレームのＴＴＬには３が設定された上で転送される。この際のＣｌｅａｖｅ Ｐｏｉｎｔは、時計回り方向に転送するＲＰＲフレームが破棄されるＲＰＲノード１００と反時計回り方向に転送するＲＰＲフレームが破棄されるＲＰＲノード１１０との間のリンク（ＲＰＲノード１００−ＲＰＲノード１１０間リンク）となる。

このようなブロードキャスト方法を行うと、第１の実施の形態におけるインタリンク接続ノードでは、次のような問題が生じる。あるインタリンク接続ノード（例えば、ＲＰＲノード１００）がインタリンクを介して配下の端末にイーサネットフレームを転送し、そのＲＰＲフレームにフレーム送信済み識別子を付加したとしても、他のインタリンク接続ノード（例えば、ＲＰＲノード１１０）にそのＲＰＲフレームが転送されずに、逆方向に転送されたＲＰＲフレームが転送される場合がある。このような場合には、そのインタリンク接続ノードは、既に別のインタリンク接続ノードによって転送されていることを認識できずに、再度イーサネットフレームを転送してしまう。

つまり、フレーム送信済み識別子が認識されずにインタリンク４３０およびインタリンク４２０の２つの経路から、２重にイーサネットフレームが送信されてしまう。その結果、イーサネットフレームの宛先となる端末は、本来１回しか受信しないはずのイーサネットフレームを複数回受信してしまうことになる。

なお、第１の実施の形態においては、時計回り方向と反時計回り方向のうちのいずれか一方にのみブロードキャストフレームを送信するＵｎｉｄｉｒｅｃｔｉｏｎａｌ Ｂｒｏａｄｃａｓｔによる転送方法を用いているため、このような問題は生じない。

以降では、Ｂｉｄｉｒｅｃｔｉｏｎａｌ Ｂｒｏａｄｃａｓｔによるブロードキャスト転送を行う通信システムにおける上記の問題を解決する方法について説明する。図１３は、インタリンク接続ノードであるＲＰＲノードが、Ｂｉｄｉｒｅｃｔｉｏｎａｌ Ｂｒｏａｄｃａｓｔによるブロードキャスト送信されたＲＰＲフレームを受信した場合の動作の一例を示すフローチャートである。

図１３に示すように、インタリンク接続ノードがブロードキャストフレームを受信した場合、その送信元ＭＡＣアドレスが自ノードのＭＡＣアドレスである場合の動作（ステップＳ１０１〜１０３）は、図１０に示す第１の実施の形態と同様である。

本実施の形態では、Ｂｉｄｉｒｅｃｔｉｏｎａｌ Ｂｒｏａｄｃａｓｔによるブロードキャスト転送を行う通信システムにおける上記の問題を、インタリンク接続ノード以外の各ＲＰＲノードを、各インタリンク接続ノードに従属するグループに分類することによって解決する。なお、各ＲＰＲノードをインタリンク接続ノードに従属するグループに分類する方法については、後述する。

図１３に示すように、本実施の形態によるインタリンク接続ノードは、インタリンク側ポート（ポートＰ３）が有効であって、かつ、自ノードがその送信元ノードからの転送経路においてそのフレームを最初に受信したインタリンク接続ノードであって、かつ、その送信元ノードが自ノードに割り当てられたグループに属する場合に、配下の端末（すなわち、インタリンク接続先ネットワーク）にそのフレームに格納されたイーサネットフレームを送信する。

インタリンク接続ノードのＲＰＲスイッチ処理部５２０は、受信したＲＰＲフレームの送信元ＭＡＣアドレスが自ノードのＭＡＣアドレスでない場合であって、ＲＰＲフレームの宛先ＭＡＣアドレスがブロードキャスト用ＭＡＣアドレスである場合には（ステップＳ１０２のＮｏ）、配下の端末（すなわちインタリンク接続先ネットワーク）にイーサネットフレームを送信するか否かを決定する。ＲＰＲスイッチ処理部５２０は、受信したブロードキャストフレームがＢｉｄｉｒｅｃｔｉｏｎａｌ Ｂｒｏａｄｃａｓｔによる転送方法を用いて転送された場合、第１の実施の形態とは異なる条件に基づいて、イーサネットフレームを配下の端末に送信するか否かを決定する。なお、ブロードキャストの転送方法については、受信したＲＰＲフレームのヘッダ情報に含まれるブロードキャストの送信方法を示すフィールドを参照することによって認識できる。なお、システムにおいて統一されている場合には予め定められた転送方法であるとして固定的に動作させてもよい。

まず、ＲＰＲスイッチ処理部５２０は、受信したＲＰＲフレームの送信元ＭＡＣアドレスが、自ノードと同一のインタリンク接続先ネットワークに接続されるインタリンク接続ノードのＭＡＣアドレスである場合には、そのＲＰＲフレームはインタリンク接続先ネットワークから送信されたＲＰＲフレームであるとして、配下の端末にイーサネットフレームを送信しない旨を決定する（ステップＳ２０１のＹｅｓ）。

次に、ＲＰＲスイッチ処理部５２０は、自ノードがそのＲＰＲフレームを受信した最初のインタリンク接続ノードであるか否かを判定する（ステップＳ５０１）。ＲＰＲスイッチ処理部５２０は、例えば、ＲＰＲフレームの受信ポートと送信元ＭＡＣアドレスとに基づいて、そのＲＰＲフレームの転送経路を確認する（転送方向および始点を認識する）。そして、ＴＤＢ５７０を参照して、その転送経路上にインタリンク接続ノード管理テーブル６１０に登録されているＭＡＣアドレスが配置されているか否かを確認することによって判定する。

ＲＰＲスイッチ処理部５２０は、自ノードがそのＲＰＲフレームを受信した最初のインタリンク接続ノードである場合には（ステップＳ５０１のＹｅｓ）、その送信元ノードが自ノードに割り当てられたグループに属しているか否かを判定する（ステップＳ５０２）。ＲＰＲスイッチ処理部５２０は、送信元ノードが自ノードに割り当てられたグループに属している場合には（ステップＳ５０２のＹｅｓ）、自ノードのポートＰ３の状態が有効か否かを判定する（ステップＳ５０３）。

ここで、自ノードのポートＰ３の状態が有効であれば、配下の端末にイーサネットフレームを送信する旨を決定する（ステップＳ５０３のＹｅｓ）。すなわち、ＲＰＲスイッチ処理部５２０は、受信したＲＰＲフレームの送信元ＭＡＣアドレスが自ノードと同一のインタリンク接続先ネットワークに接続されるインタリンク接続ノードのＭＡＣアドレスでない場合であって、かつ、自ノードがそのＲＰＲフレームを受信した最初のインタリンク接続ノードである場合であって、かつ、そのＲＰＲフレームの送信元ＭＡＣアドレスが自ノードに割り当てられたグループに属するＲＰＲノードのＭＡＣアドレスである場合であって、かつ、自ノードのポートＰ３のポート状態が有効である場合に、配下の端末（すなわち、インタリンク接続先ネットワーク）にイーサネットフレームを送信する旨を決定する。

また、ＲＰＲスイッチ処理部５２０は、自ノードがそのＲＰＲフレームを受信した最初のインタリンク接続ノードでない場合であっても（ステップＳ５０１のＮｏ）、そのＲＰＲフレームにフレーム送信済み識別子が付加されていない場合には（ステップＳ５０４のＮｏ）、自ノードのポートＰ３の状態を確認した上で、配下の端末にイーサネットフレームを送信する旨を決定する。なお、ブロードキャストフレームを最初に受信したインタリンク接続ノードが、配下の端末にイーサネットフレームを転送しなかった場合に、そのブロードキャストフレームにフレーム未送信識別子を付加することにより、配下の端末にイーサネットフレームを送信するか否かを容易に判定することが可能である。そのような場合には、そのフレーム未送信識別子が付加されているか否かを確認することによって判定すればよい。ここで、フレーム未送信識別子が付加されていることは、自ノードが最初に受信したインタリンク接続ノードでなく、かつ、フレーム送信済み識別子が付加されていないことと同義である。

フレーム未送信識別子の表現方法は、フレーム送信済み識別子と同様に、ＲＰＲフレームのヘッダのフィールド、またはフレーム送信済み識別子とは異なるマルチキャスト用ＭＡＣアドレスなどを用いることによって実現することができる。

また、ＲＰＲスイッチ処理部５２０は、上記以外の場合には、配下の端末（インタリンク接続先ネットワーク）にイーサネットフレームを送信しない旨を決定する。すなわち、自ノードが最初にブロードキャストフレームを受信したインタリンク接続ノードでない、かつ、フレーム送信済み識別子が付加されていない場合、または、自ノードが最初にブロードキャストフレームを受信したインタリンク接続ノードである、かつ、送信元ノードが自ノードのグループに属しない場合、または、自ノードのポートＰ３が無効の場合には、イーサネットフレームを送信しない旨を決定する。

ＲＰＲスイッチ処理部５２０は、配下の端末にイーサネットフレームを送信する旨を決定した場合には、第１の実施の形態と同様にイーサネットフレームを配下の端末に送信する。

一方、配下の端末にイーサネットフレームを送信しない旨を決定した場合には、ＲＰＲスイッチ処理部５２０は、ＲＰＲフレームをイーサネットフレーム抽出部５３０に送らず、配下の端末へのイーサネットフレームの送信も行わない。なお、配下の端末にイーサネットフレームを送信しない旨を決定した場合であっても、ＭＡＣアドレス学習については行ってもよい。

なお、ＲＰＲスイッチ処理部５２０は、配下の端末にイーサネットフレームを送信するか否かの決定に関わらず、隣接するＲＰＲノードにＲＰＲフレームを転送する。隣接するＲＰＲノードへのＲＰＲフレームの転送は、第１の実施の形態と同様である。

ＲＰＲスイッチ処理部５２０は、配下の端末にイーサネットフレームを送信する旨を決定した場合には、自ノードによってＲＰＲフレームにカプセル化されたイーサネットフレームがインタリンクを介して他のＲＰＲネットワークに既に転送されていることを示すため、ＲＰＲフレームにフレーム送信済み識別子を付加した上で（ステップＳ２０４）、次のＲＰＲノードにそのＲＰＲフレームを送信する。なお、自ノード以降からＴＴＬの値がとなるまでの経路上に、同一のインタリンク接続先ネットワークに接続されるインタリンク接続ノードが存在しない場合には、フレーム送信済み識別子を付加しないようにしてもよい。

さらに、本実施の形態において、ＲＰＲスイッチ処理部５２０は、他の条件は満たしたがインタリンク側ポートのポート状態が無効であるために、配下の端末にイーサネットフレームを送信しない旨を決定した場合には（ステップＳ５０３のＮｏ）、以降のブロードキャストフレームの経路（そのＴＴＬの値が０となるまでの経路）上に、他のインタリンク接続ノードが配置されているか否かを確認し（ステップＳ５０６）、配置されていなければ、その先のインタリンク接続ノードまで到達されるようＴＴＬの値を更新する（ステップＳ５０７）。すなわち、ＲＰＲスイッチ処理部５２０は、ブロードキャストフレームの転送方向に向かって、自ノードから次のインタリンク接続ノードまでのホップ数の最小値にＴＴＬの値を変更した上で、ＲＰＲフレームを送信する。

ただし、自ノードから次のインタリンク接続ノードまでのホップ数の最小値が、自ノードから送信元ノードまでのホップ数を超える場合、すなわち、次のインタリンク接続ノードまでの経路上に送信元ノードが存在する場合には、送信元ＲＰＲノードにより廃棄されるため、ＴＴＬの値を変更する必要はない。

なお、ブロードキャストフレームの経路上において、ブロードキャストフレームを最初に受信したインタリンク接続ノードでない場合の動作は、第１の実施の形態におけるブロードキャストフレーム受信時のインタリンク接続ノードの動作と同様である。

すなわち、インタリンク接続ノードは、自ノードがブロードキャストフレームを２番目以降に受信したインタリンク接続ノードである場合には、ブロードキャストフレームの送信元ＲＰＲノードが自ノードに割り当てられているノードであるか否かを確認する必要はない。

以上に説明したように、インタリンク接続ノード以外のＲＰＲノードを重複しないように各インタリンク接続ノードに割り当てた上で、インタリンク接続ノードがブロードキャストフレームを最初に受信したインタリンク接続ノードである場合には、自ノードに割り当てられたグループに属するＲＰＲノードから送信されたブロードキャストフレームのみ、それにカプセル化されたイーサネットフレームをインタリンク接続先ネットワークに送信する。

以降では、インタリンク接続ノード以外の各ＲＰＲノードを、各インタリンク接続ノードに従属するグループに分類する方法について説明する。ここでは、インタリンク接続ノード以外の各ＲＰＲノードをグループに分けた上で、各グループを各インタリンク接続ノードに割り当てる方法を例にして説明する。

まず、分散させて転送を行うインタリンクの数に合わせて、グループを定義する。なお、グループの数は任意であるが、ブロードキャストフレームを全インタリンクに分散させて転送する場合には、インタリンク接続ノードのノード数分のグループを定義する。

次に、同じＲＰＲネットワークに属するインタリンク接続ノード以外の全てのＲＰＲノードを、定義したグループのうちのいずれか１つに属するように分類する。すなわち、同一のＲＰＲノードが複数のグループに属することがないように分類する。最後に、それぞれのグループを各インタリンク接続ノードに割り当てる。インタリンク接続ノードにグループを割り当てる方法は任意である。

以下は、ブロードキャストフレームの送信元ＲＰＲノードからのホップ数が最小であるインタリンク接続ノードによって、そのブロードキャストフレームに格納されたイーサネットフレームが他のＲＰＲネットワークに転送させるためのグループ構成方法の一例である。本グループ構成方法を用いると、各インタリンク接続ノードに従属するグループとして、ブロードキャストフレームの転送経路において、そのインタリンク接続ノードから近いＲＰＲノードが均等に分類される。

まず、あるインタリンク接続ノードから次のインタリンク接続ノードまでの経路上に配置されるＲＰＲノード（両端のインタリンク接続ノードを含む）を１ノードと仮想する。次に、その仮想したＲＰＲノードのＣｌｅａｖｅ Ｐｏｉｎｔを求める。ここでは、あるインタリンク接続ノードから時計回り方向の経路における次のインタリンク接続ノードまでを１ノードと仮想した場合のＣｌｅａｖｅ Ｐｏｉｎｔと、逆に反時計回り方向の経路で仮想したＲＰＲノードのＣｌｅａｖｅ Ｐｏｉｎｔとの２点を求める。

例えば、図１に示すＲＰＲネットワーク１０において、インタリンク接続ノード１００からインタリンク接続ノード１１０までの経路上の各ＲＰＲノードを１ノードと仮想すると、時計回り方向の経路に基づく仮想ノードは、ＲＰＲノード１００，１１０を含み、反時計回り方向の経路に基づく仮想ノードは、ＲＰＲノード１００，１７０〜１１０を含むことになる。時計回り方向の経路に基づく仮想ノードのＣｌｅａｖｅ Ｐｏｉｎｔは、ＲＰＲノード１４０−ＲＰＲノード１５０間のリンクである。また、反時計回り方向の経路に基づく仮想ノードのＣｌｅａｖｅ Ｐｏｉｎｔは、ＲＰＲノード１００−ＲＰＲノード１１０間のリンクである。

次に、仮想ノードの起点および終点となった各インタリンク接続ノードから、求めた２点のＣｌｅａｖｅ Ｐｏｉｎｔまでの経路上に配置されているＲＰＲノードを、そのインタリンク接続ノードのグループに割り当てる。

本例では、インタリンク接続ノード１００のグループには、ＲＰＲノード１００からＲＰＲノード１００−ＲＰＲノード１１０間リンクまでに配置されたＲＰＲノード（ここでは、該当ノードなし）、およびＲＰＲノード１００からＲＰＲノード１４０−ＲＰＲノード１５０間リンクまでに配置されたＲＰＲノード（ここでは、ＲＰＲノード１７０〜１５０）が割り当てられる。同様に、インタリンク接続ノード１１０のグループには、ＲＰＲノード１１０からＲＰＲノード１００−ＲＰＲノード１１０間リンクまでに配置されたＲＰＲノード（ここでは、該当ノードなし）、およびＲＰＲノード１１０からＲＰＲノード１４０−ＲＰＲノード１５０間リンクまでに配置されたＲＰＲノード（ここでは、ＲＰＲノード１２０〜１４０）が割り当てられる。

なお、上記の説明では正常時のＣｌｅａｖｅ Ｐｏｉｎｔを前提としているが、実際のＣｌｅａｖｅ Ｐｏｉｎｔは、ＲＰＲノード障害やＲＰＲノード間リンクの障害状態に応じて動的に変化する。ＲＰＲノード障害やＲＰＲノード間リンクに障害が発生した場合には、その障害発生箇所がＣｌｅａｖｅ Ｐｏｉｎｔとなる。

従って、上述のグループ構築方法を用いる場合には、各インタリンク接続ノードが、ブロードキャストフレームを受信した際に、その時のＣｌｅａｖｅ Ｐｏｉｎｔに基づいて動的に自ノードのグループに属するＲＰＲノードを求めることができる。

例えば、図１に示すＲＰＲネットワーク１０において、ＲＰＲノード１３０に障害が発生した場合、ＲＰＲノード１００からＲＰＲノード１１０までの時計回り方向の経路に基づく仮想ノードのＣｌｅａｖｅ Ｐｏｉｎｔは、ＲＰＲノード１４０−ＲＰＲノード１３０間リンクとなる。なお、反時計回り方向の経路におけるＣｌｅａｖｅ Ｐｏｉｎｔは、仮想ノード内部の障害と見なし、正常時から変更しないものとする。従って、インタリンク接続ノード１００のグループには、ＲＰＲノード１４０〜１７０が割り当てられる。また、インタリンク接続ノード１１０のグループには、ＲＰＲノード１２０〜１３０が割り当てられる。

また、例えば、ＲＰＲノード１５０−ＲＰＲノード１６０間リンクに障害が発生した場合、ＲＰＲノード１００からＲＰＲノード１１０までの時計回り方向の経路に基づく仮想ノードのＣｌｅａｖｅ Ｐｏｉｎｔは、ＲＰＲノード１５０−ＲＰＲノード１６０間リンクとなる。従って、インタリンク接続ノード１００のグループには、ＲＰＲノード１６０，１７０が割り当てられ、インタリンク接続ノード１１０のグループには、ＲＰＲノード１２０〜１５０が割り当てられる。

また、例えば、ＲＰＲノード１００−ＲＰＲノード１１０間リンクに障害が発生した場合には、Ｃｌｅａｖｅ Ｐｏｉｎｔは正常時と変わらず、インタリンク接続ノード１００のグループには、ＲＰＲノード１５０〜１７０が割り当てられ、インタリンク接続ノード１１０のグループには、ＲＰＲノード１２０〜１４０が割り当てられる。

以上に説明したように、本実施の形態によれば、ブロードキャストフレームをＢｉｄｉｒｅｃｔｉｏｎａｌ Ｂｒｏａｄｃａｓｔと呼ばれるブロードキャスト転送方法によって転送された場合であっても、複数のインタリンク接続ノードが同一のイーサネットフレームを同一の他のＲＰＲネットワークに送信することなく、第１の実施の形態と同様の効果が得られる。

実施の形態３．
以下に、本発明の第３の実施の形態について、図面を参照して説明する。図１４は、本実施の形態による通信システムの構成例を示す説明図である。図１４に示す通信システムは、図１に示す第１の実施の形態のＲＰＲネットワーク１０に、ＲＰＲノード３００〜３７０を含むＲＰＲネットワーク３０がインタリンク４４０およびインタリンク４５０を介して接続された通信システムである。なお、ＲＰＲネットワーク３０に属するＲＰＲノード３００〜３７０は、図２および図３に示す第１の実施の形態における他のＲＰＲネットワークに属するＲＰＲノード（例えば、ＲＰＲノード１００〜１７０，ＲＰＲノード２００〜２７０）と同様である。なお、本実施の形態では、ＲＰＲノード１００，１１０，２００，２７０が、ＲＰＲネットワーク１０−ＲＰＲネットワーク２０間のインタリンク接続ノードであり、ＲＰＲノード１４０，１５０，３００，３７０が、ＲＰＲネットワーク１０−ＲＰＲネットワーク３０間のインタリンク接続ノードである。

本実施の形態では、同一ＲＰＲネットワーク内で異なるインタリンク接続先ネットワークに接続されるインタリンク接続ノードの間で、フレーム送信済み識別子およびフレーム未送信識別子の表現方法を区別する点が第１の実施の形態と異なる。なお、他の点に関しては、第１の実施の形態と同様である。

例えば、インタリンク接続先ネットワークがＲＰＲネットワーク２０であるインタリンク接続ノード１００，１１０と、インタリンク接続先ネットワークがＲＰＲネットワーク３０であるインタリンク接続ノード１４０，１５０とで同じフレーム送信済み識別子を用いると次のような問題が生じる。仮に、インタリンク接続ノード１００がブロードキャストフレームに格納されたイーサネットフレームをＲＰＲネットワーク２０に送信して、そのブロードキャストフレームにフレーム送信済み識別子を付加した場合、インタリンク接続ノード１４０，１５０は、そのフレーム送信済み識別子を認識し、ＲＰＲネットワーク３０にイーサネットフレームを送信しない。このため、ＲＰＲネットワーク３０に属する各ＲＰＲノードの配下の端末にイーサネットフレームを転送することができない。

従って、インタリンク接続先ネットワークがＲＰＲネットワーク２０であるインタリンク接続ノード１００，１１０と、インタリンク接続先ネットワークがＲＰＲネットワーク３０であるインタリンク接続ノード１４０，１５０とで同じフレーム送信済み識別子を用いてしまうと、ＲＰＲネットワーク１０およびＲＰＲネットワーク２０に属する各ＲＰＲノードの配下の端末と、ＲＰＲネットワーク３０に属する各ＲＰＲノードの配下の端末間で通信を行うことができなくなるという問題が生じる。

このような問題を解決するために、本実施の形態では、既に説明したように、同一ＲＰＲネットワーク内で異なるインタリンク接続先ネットワークに接続されるインタリンク接続ノードの間で、フレーム送信済み識別子およびフレーム未送信識別子の表現方法を区別する。本例では、インタリンク接続ノード１４０，１５０が用いるフレーム送信済み識別子と、インタリンク接続ノード１００，１１０が用いるフレーム送信済み識別子とで異なる表現方法を用いる。異なる表現方法を用いることによって、インタリンク接続ノード１００またはインタリンク接続ノード１１０が付加したフレーム送信識別子を、インタリンク接続ノード１４０またはインタリンク接続ノード１５０が誤って認識することはなくなるので、１つのブロードキャストフレームに格納されたイーサネットフレームは、ＲＰＲネットワーク２０と、ＲＰＲネットワーク３０のそれぞれに送信される。

フレーム送信済み識別子の表現方法として、例えば、ブロードキャストフレームの宛先ＭＡＣアドレスを、ブロードキャスト用ＭＡＣアドレスからマルチキャストＭＡＣアドレスに変更する方法を用いる場合は、インタリンク接続ノード１００，１１０が用いるマルチキャストＭＡＣアドレスの値と、インタリンク接続ノード１４０，１５０が用いるマルチキャストＭＡＣアドレスの値を異なる値で定義すればよい。

なお、フレーム送信済み識別子として定義した特殊マルチキャストＭＡＣアドレスは、第１の実施の形態と同様に、ＲＰＲネットワークに属する全てのＲＰＲノードが属するグループのＭＡＣアドレスとして定義しておく。

各インタリンク接続ノードは、宛先ＭＡＣアドレスが自ノードと同一のインタリンク接続先ネットワークに接続されるインタリンク接続ノードに対して定義されたマルチキャストＭＡＣアドレスである場合に、フレーム送信識別子が付加されたと認識し、そうでない場合には、通常のブロードキャストフレームまたは通常のマルチチャストフレームとして認識すればよい。このように動作することによって、例えば、インタリンク接続ノード１４０，１５０は、インタリンク接続ノード１００またはインタリンク接続ノード１１０が付加したマルチキャストＭＡＣアドレスを宛先ＭＡＣアドレスとするＲＰＲフレームを、ブロードキャスト用ＭＡＣアドレスを宛先ＭＡＣアドレスとするＲＰＲフレームとして処理することができる。同様に、例えば、インタリンク接続ノード１００，１１０は、インタリンク接続ノード１４０またはインタリンク接続ノード１５０が付加したマルチキャストＭＡＣアドレスを宛先ＭＡＣアドレスとするＲＰＲフレームを、ブロードキャスト用ＭＡＣアドレスを宛先ＭＡＣアドレスとするＲＰＲフレームとして処理することができる。

以上に説明したように、本実施の形態によれば、複数のＲＰＲネットワーク間のインタリンクを２重化することができるので、より信頼性の高い通信システムを構築することが可能である。

実施の形態４．
以下に、本発明の第４の実施の形態について、図面を参照して説明する。図１５は、本実施の形態による通信システムの構成例を示す説明図である。図１５に示す通信システムは、図１に示す第１の実施の形態のＲＰＲネットワーク１０とＲＰＲネットワーク２０間の接続に、インタリンク４６０を追加して３重化した通信システムである。

本実施の形態では、ＲＰＲノード１００，１１０，１７０，２００，２１０，２７０が、インタリンク接続ノードである。なお、本実施の形態における各ノードの構成、およびフレーム転送動作は、第１の実施の形態と同様である。

本実施の形態では、例えば、インタリンク４２０とインタリンク４３０に障害が発生した場合であっても、インタリンク４６０を介して通信を継続することができる。なお、インタリンクの数は、３つに限られない。本発明を適用した通信システムは、ＲＰＲネットワーク間を３本以上のインタリンクにより接続することができるので、より信頼性の高い通信システムを構築することが可能である。

実施の形態５．
以下に、本発明の第５の実施の形態について、図面を参照して説明する。図１６は、本実施の形態による通信システムの構成例を示す説明図である。図１６に示す通信システムは、同一のインタリンク接続先ネットワークに接続されるインタリンク接続ノードが隣接する位置に配置されるのではなく、１ホップ以上離れた位置に配置されている点が第１の実施の形態と異なる。本実施の形態では、ＲＰＲノード１１０，１７０，２１０，２７０がインタリンク接続ノードである。なお、他の点に関しては、第１の形態と同様である。

本実施の形態では、図１６に示す構成において、Ｂｉｄｉｒｅｃｔｉｏｎａｌ Ｂｒｏａｄｃａｓｔによるブロードキャストフレームの転送が行われた際に、インタリンク接続ノード以外のＲＰＲノードに生じる問題の解決方法について説明する。

なお、全てのＲＰＲノードがＵｎｉｄｉｒｅｃｔｉｏｎａｌ Ｂｒｏａｄｃａｓｔによるブロードキャストフレームの転送を行う場合の各ＲＰＲノード（インタリンク接続ノードであるＲＰＲノードを含む）の動作は、第１の実施の形態と同様である。また、Ｂｉｄｉｒｅｃｔｉｏｎａｌ Ｂｒｏａｄｃａｓｔによるブロードキャストフレームの転送を行う場合のインタリンク接続ノードの動作は、第２の実施の形態と同様である。

以降では、ＲＰＲネットワーク１０およびＲＰＲネットワーク２０に属する全ＲＰＲノードが、Ｂｉｄｉｒｅｃｔｉｏｎａｌ Ｂｒｏａｄｃａｓｔによるブロードキャストフレームの転送を行う通信システムにおいて、インタリンク４３０に障害が発生した場合に、第２の実施の形態で説明したブロードキャストフレームの転送方法により生じる問題とその解決方法を説明する。

ここでは、ＲＰＲノード１４０からＢｉｄｉｒｅｃｔｉｏｎａｌ Ｂｒｏａｄｃａｓｔによるブロードキャストフレームの転送が行われた場合を例にして説明する。ここでは、ＲＰＲノード１４０は、障害が発生しているインタリンク４３０に接続されるインタリンク接続ノード１１０のグループに属しているものとする。

本例では、ＲＰＲノード１４０からＲＰＲフレームがブロードキャスト送信されると、インタリンク接続ノード１１０には、反時計回り方向に送信されたブロードキャストフレームがＲＰＲノード１２０から転送される。図１３で示すように、インタリンク接続ノード１１０は、第２の実施の形態と同様に、自ノードがＲＰＲフレームを受信した最初のインタリンク接続ノードであって、そのＲＰＲフレームの送信元ＭＡＣアドレスが自ノードに割り当てられたグループに属するＲＰＲノードのＭＡＣアドレスであっても、自ノードのポートＰ３のポート状態が無効であるために、配下の端末（すなわちインタリンク接続先ネットワーク）にイーサネットフレームを送信しない。

このとき、受信したブロードキャストフレームのＴＴＬの値が、以降の経路において他のインタリンク接続ノード（ここでは、ＲＰＲノード１７０）に到達される値であれば、インタリンク接続ノード１１０は、特に何もせず、次のＲＰＲノード（ＲＰＲノード１００）にブロードキャストフレームを転送する。

一方、ＴＴＬの値が他のインタリンク接続ノードまで到達可能な値でなければ、インタリンク接続ノード１１０は、そのＴＴＬの値を自ノードから次のインタリンク接続ノードまでのホップ数（ここでは、２ホップ）に更新した上で、次のＲＰＲノードに転送する。

後者の場合において、例えば、ブロードキャストフレームの送信元ノードのＣｌｅａｖｅＰｏｉｎｔがＲＰＲノード１００−ＲＰＲノード１１０間リンクであった場合、ＲＰＲノード１００は、時計回り方向に転送されるブロードキャストフレームと、インタリンク接続ノード１１０が他のインタリンク接続ノードに転送されるようＴＴＬを更新した反時計回り方向に転送されるブロードキャストフレームの２つのブロードキャストフレームを受信する。このため、ＲＰＲノード１００は、同一のブロードキャストフレームであってもそれを認識できずに、それぞれのブロードキャストフレームに格納されたイーサネットフレームを自ノードの配下の端末に送信する。従って、ＲＰＲノード１００配下の端末は、同じイーサネットフレームを２重に受信してしまうという問題が生じる。

従って、ＲＰＲノード１００は、これら２つのブロードキャストフレームのいずれか１つに対してのみ、配下の端末への転送制御を行う必要がある。

本実施の形態では、インタリンク接続ノードでないＲＰＲノードにおいて、インタリンク接続ノードによりＴＴＬを更新された、正常時なら受信しないはずのブロードキャストフレームに対しては、配下の端末への転送制御を行わないよう制御することによって、上記問題を解決する。

図１７は、本実施の形態におけるインタリンク接続ノードでないＲＰＲノード（本例では、ＲＰＲノード１００）が、Ｂｉｄｉｒｅｃｔｉｏｎａｌ Ｂｒｏａｄｃａｓｔによるブロードキャスト送信されたＲＰＲフレームを受信した場合の動作の一例を示すフローチャートである。

図１７に示すように、本実施の形態におけるＲＰＲノードは、ブロードキャストフレームを受信した場合に、配下の端末に送信しない場合がある点が第１の実施の形態と異なる。なお、ブロードキャストフレームの送信元ＭＡＣアドレスが自ノードのＭＡＣアドレスである場合の動作（ステップＳ１０１〜１０３）、および隣接するＲＰＲノードにＲＰＲフレームを転送する動作（ステップＳ１０６〜１０８）は、第１の実施の形態と同様である。すなわち、本実施の形態におけるＲＰＲノードは、”ＩＥＥＥ Ｓｔｄ ８０２．１７”に準拠して動作するだけでなく、他の動作（本発明の目的を実現するための動作）も行う。

ＲＰＲノード１００のＲＰＲスイッチ処理部５２０は、受信したＲＰＲフレームの送信元ＭＡＣアドレスが自ノードのＭＡＣアドレスでない場合であって、ＲＰＲフレームの宛先ＭＡＣアドレスがブロードキャスト用ＭＡＣアドレスである場合には（ステップＳ１０２のＮｏ）、配下の端末にイーサネットフレームを送信するか否かを決定する。ＲＰＲスイッチ処理部５２０は、受信したブロードキャストフレームがＢｉｄｉｒｅｃｔｉｏｎａｌ Ｂｒｏａｄｃａｓｔによる転送方法を用いて転送された場合、以下の示す条件に従って、配下の端末にイーサネットフレームを送信するか否かを決定する。

ＲＰＲノード１００のＲＰＲスイッチ処理部５２０は、フレーム送信済み識別子が付加されている場合に、配下の端末にイーサネットフレームを送信する旨を決定する。また、ＲＰＲスイッチ処理部５２０は、フレーム送信済み識別子が付加されていない、または、フレーム未送信識別子が付加されている場合には、送信元ノードがそのフレームの生成時に設定した転送経路上に、自ノードが配置されていれば、配下の端末にイーサネットフレームを送信する旨を決定する。

なお、上記で示した送信元ノードがフレーム生成時に設定した転送経路上に自ノードが配置されているという条件は、送信元ノードから自ノード（ＲＰＲノード１００）までのホップ数が、ブロードキャストフレームの生成時に送信元ノードにより設定されるＴＴＬの初期値（すなわち、送信元ノードからＣｌｅａｖｅ Ｐｏｉｎｔまでのホップ数）以下であるという条件と一致する。ＲＰＲスイッチ処理部５２０は、受信したＲＰＲフレームの転送経路における送信元ノードから自ノードまでのホップ数が、送信元ノードにより設定されるＴＴＬの初期値（送信元ノードからＣｌｅａｖｅ Ｐｏｉｎｔまでのホップ数）以下である場合に、配下の端末にイーサネットフレームを送信する旨を決定する。

ＲＰＲスイッチ処理部５２０は、配下の端末にイーサネットフレームを送信しない旨を決定した場合には、ＲＰＲフレームをイーサネットフレーム抽出部５３０に送らず、配下の端末へのイーサネットフレームの送信も行わない。なお、配下の端末にイーサネットフレームを送信しない旨を決定した場合であっても、ＭＡＣアドレス学習については行ってもよい。

一方、配下の端末にイーサネットフレームを送信する旨を決定した場合には、第２の実施の形態と同様に、イーサネットフレームを配下の端末に送信する。すなわち、ＲＰＲスイッチ処理部５２０は、ＲＰＲフレームをイーサネットフレーム抽出部５３０に送る。イーサネットフレーム抽出部５３０は、ＲＰＲフレームからイーサネットフレームを抽出し、そのイーサネットフレームを、自ノードの出力ポート５４０−３から自ノードの配下の端末に送信する（ステップＳ１０４）。この際、ＦＤＢ管理部５６０が、受信したＲＰＲフレームに基づいて、端末とＲＰＲノードのＭＡＣアドレスの対応関係をＦＤＢ５５０に登録することによってＭＡＣアドレス学習を行う（ステップＳ１０５）。

なお、ＲＰＲスイッチ処理部５２０は、配下の端末にイーサネットフレームを送信するか否かの決定に関わらず、隣接するＲＰＲノードにＲＰＲフレームを転送する。隣接するＲＰＲノードへのＲＰＲフレームの転送動作は、第２の実施の形態と同様である。すなわち、ＲＰＲスイッチ処理部５２０は、受信したＲＰＲフレームに格納されたＴＴＬの値を１だけ減算し（ステップＳ１０６）、減算後のＴＴＬの値が０より大きければ、そのＲＰＲフレームを次のＲＰＲノードに送信する（ステップＳ１０７のＹｅｓ，Ｓ１０８）。なお、ＴＴＬの値が０であれば、そのＲＰＲフレームを破棄する（ステップＳ１０７のＮｏ，Ｓ１０３）。

以上に説明したように、本実施の形態によれば、インタリンク接続ノードに挟まれたＲＰＲノード１００が、送信元ノードが設定したＣｌｅａｖｅＰｏｉｎｔを超えて転送されたブロードキャストフレームを認識し、そのフレームに格納されたイーサネットフレームを配下の端末に送信しないため、例えインタリンク接続ノードのトラフィック操作によって同一のＲＰＲフレームを受信したとしても、配下の端末が２重にイーサネットフレームを受信する事態を回避することができる。

従って、インタリンク接続ノードの配置が制限されることがないため、信頼性の高い通信システムを容易に構築することが可能となる。

実施の形態６．
以下に、本発明の第６の実施の形態について、図面を参照して説明する。図１８は、本実施の形態による通信システムの構成例を示す説明図である。図１８に示す通信システムは、ＲＰＲノード１００〜１７０を含むＲＰＲネットワーク１０を備える。ＲＰＲノード１２０〜１７０には、それぞれ配下の端末（端末７２０〜７７０）が１台収容されている。また、ＲＰＲノード１００とＲＰＲノード１１０には、共通の端末７００が１台収容されている。

このような構成において、ＲＰＲノード１００およびＲＰＲノード１１０をインタリンク接続ノードと見なし、ＲＰＲノード１００−端末７００間リンクと、ＲＰＲノード１１０−端末７００間リンクをそれぞれインタリンクと見なすことによって、異なるＲＰＲネットワーク間の通信だけでなく、ＲＰＲノードと端末間の通信においても信頼性の高い通信システムを構築することができる。

なお、本実施の形態における各ＲＰＲノードの構成は、他の実施の形態と同様である。また、フレーム転送動作は、端末７００がイーサネットフレームを送信する際に、ＲＰＲノード１００とＲＰＲノード１１０のいずれか１つにイーサネットフレームを送信する点を除いては、他の実施の形態と同様である。

端末７００がイーサネットフレームを送信するＲＰＲノードについては、以下の条件を満たす必要がある。まず、障害が発生していないＲＰＲノードであること。次に、端末７００とＲＰＲノード間を接続するリンクに障害が発生していないこと。次に、ＲＰＲネットワーク１０に属する他のＲＰＲノードと通信が可能であること。なお、通信可能な他のＲＰＲノードは出来る限り多い方が好ましい。

ＲＰＲノード１００およびＲＰＲノード１１０が共に上記の条件を満足する場合には、イーサネットフレームの到着順序を維持する限り、端末７００は、ＲＰＲノード１００とＲＰＲノード１１０のいずれかを介してイーサネットフレームを送受信するので、ＲＰＲネットワーク１０と端末７００間の複数のリンクにトラフィックを分散させることができる。

なお、端末７００がイーサネットフレームを送信するＲＰＲノードを選択する機能は、端末７００のポートＰ１〜Ｐ２にＬＡＧを適用した上で、上記の条件を満足するイーサネットフレームの送信先選択アルゴリズムを実装することにより実現できる。

以上のように、本発明によれば、ＲＰＲネットワーク間を接続するインタリンクの冗長化に加えて、ＲＰＲネットワークと端末間のリンクを冗長化する、いわゆるマルチホーミングの構成も容易に実現することが可能である。

また、上記の各実施の形態では、ＲＰＲノードやインタリンク接続ノードが、ＲＰＲフレーム生成部５１０，ＲＰＲスイッチ処理部５２０などの各処理部を備える構成として説明したが、ＲＰＲノードやインタリンク接続ノードが、コンピュータを備え、そのコンピュータがプログラムに従って、各処理部と同様の動作をする構成であってもよい。なお、プログラムは、予めノードが備える記憶装置に記憶させておけばよい。

特許請求の範囲に記載された識別子付加手段、送信判定手段、転送経路変更手段は、例えば、インタリンク接続ノードのＲＰＲスイッチ処理部５２０によって実現される。また、障害監視手段は、例えば、インタリンク接続ノードのポート状態監視部５９０によって実現される。また、リンク制御手段は、例えば、インタリンク接続ノードのＲＰＲスイッチ処理部５２０、ポート状態監視部５９０によって実現される。また、第２の送信判定手段は、例えば、インタリンク接続ノードでないＲＰＲノードのＲＰＲスイッチ処理部５２０によって実現される。また、選択送信手段は、例えば、端末７００が備える送信先選択アルゴリズムが実装されたＣＰＵによって実現される。

本発明による通信システムの第１の実施の形態を示す説明図。 インタリンク接続ノードでないＲＰＲノードの構成例を示すブロック図。 インタリンク接続ノードであるＲＰＲノードの構成例を示すブロック図。 ＦＤＢに登録された対応関係の例を示す説明図。 ＴＤＢに登録された情報の例を示す説明図。 ＭＡＣアドレス管理テーブルに記憶される情報の例を示す説明図。 ポート状態テーブルに記憶される情報の例を示す説明図。 インタリンク接続ノード管理テーブルに記憶される情報の例を示す説明図。 インタリンク接続ノードでないＲＰＲノードにおけるブロードキャストフレーム転送動作の処理経過の例を示すフローチャート。 インタリンク接続ノードであるＲＰＲノードにおけるブロードキャストフレーム転送動作の処理経過の例を示すフローチャート。 インタリンク接続ノードでないＲＰＲノードにおけるユニキャストフレーム転送動作の処理経過の例を示すフローチャート。 インタリンク接続ノードであるＲＰＲノードにおけるユニキャストフレーム転送動作の処理経過の例を示すフローチャート。 第２の実施の形態においてインタリンク接続ノードであるＲＰＲノードにおけるブロードキャストフレームの転送動作の処理経過を示すフローチャート。 本発明による通信システムの第３の実施の形態を示す説明図。 本発明による通信システムの第４の実施の形態を示す説明図。 本発明による通信システムの第５の実施の形態を示す説明図。 第５の実施の形態によるインタリンク接続ノードではないＲＰＲノードにおけるブロードキャストフレームの転送動作の処理経過を示すフローチャート。 本発明による通信システムの第６の実施の形態を示す説明図。 ＲＰＲネットワークの例を示す説明図。 ＲＰＲネットワーク同士の接続にＬＡＧを適用した例を示す説明図。 特許文献１に記載されたネットワークの構成を示す説明図。

符号の説明

１０、２０、３０、８０、９０ ＲＰＲネットワーク
１００〜１７０、２００〜２７０、３００〜３７０、８００〜８７０、９００〜９７０ ＲＰＲノード
４００〜４６０、４９１、４９２ インタリンク
５００−１〜３ 入力ポート
５１０ ＲＰＲフレーム生成部
５２０ ＲＰＲスイッチ処理部
５３０ イーサネットフレーム抽出部
５４０−１〜３ 出力ポート
５５０ ＦＤＢ
５６０ ＦＤＢ管理部
５７０ ＴＤＢ
５８０ ＭＡＣアドレス管理テーブル
５９０ ポート状態監視部
６００ ポート状態テーブル
６１０ インタリンク接続ノード管理テーブル
７００〜７７０ 端末

Claims (27)

1. 端末が接続される複数のノードを含む通信システムであって、
   前記複数のノードのうちの一部のノードは、それぞれリンクを介して共通の端末または当該通信システムとは異なる通信システムに含まれるノードが端末として接続されることによって、共通の接続先を有するグループとしてまとめられ、
   前記グループに属するノードは、
   システム内通信用フレームに格納されている、当該通信システムが含むノードに接続される端末から受信したフレームを共通の接続先の端末またはノードに送信したか否かを示す識別子を、前記システム内通信用フレームに付加する識別子付加手段と、
   システム内通信用フレームを受信した場合に、前記システム内通信用フレームで示される情報に基づいて、前記システム内通信用フレームに格納されているフレームを共通の接続先の端末またはノードに送信するか否かを判定する送信判定手段とを備えた
   ことを特徴とする通信システム。
2. グループに属するノードは、
   識別子付加手段によって識別子が付加されたシステム内通信用フレームを当該通信システムに含まれるノードに送信するシステム内通信用フレーム送信手段と、
   送信判定手段の判定結果に応じて、システム内通信用フレームに格納されているフレームを共通の接続先の端末またはノードに送信する端末通信用フレーム送信手段とを備えた
   請求項１記載の通信システム。
3. グループに属するノードは、
   共通の接続先の端末またはノードと自ノードとの間のリンクの障害状態を監視する障害監視手段を備え、
   送信判定手段は、自ノードと同じグループに属するノードの識別子付加手段によって付加される識別子および前記障害監視手段が監視した前記リンクの障害状態に基づいて、前記システム内通信用フレームに格納されているフレームを共通の接続先の端末またはノードに送信するか否かを判定する
   請求項１または請求項２に記載の通信システム。
4. 識別子付加手段は、自ノードが、共通の接続先の端末またはノードに、ブロードキャストによる転送を示すシステム内通信用フレームに格納されているフレームを送信した場合に、送信した旨を示す送信済み識別子を付加する請求項１から請求項３のうちのいずれか１項に記載の通信システム。
5. 識別子付加手段は、自ノードが、共通の接続先の端末またはノードに、ブロードキャストによる転送を示すシステム内通信用フレームに格納されているフレームを送信しなかった場合に、送信しなかった旨を示す未送信識別子を付加する請求項１から請求項４のうちのいずれか１項に記載の通信システム。
6. 送信判定手段は、システム内通信用フレームの送信元アドレスが、自ノードと同じグループに属するノードのアドレスである場合に、送信しない旨を決定する請求項１から請求項５のうちのいずれか１項に記載の通信システム。
7. 送信判定手段は、ブロードキャストによる転送を示すシステム内通信用フレームを受信したときに、前記システム内通信用フレームに送信済み識別子が付加されていない、または未送信識別子が付加されている場合であって、共通の接続先の端末またはノードとの間でフレームを送受信可能である場合に、送信する旨を決定する請求項４から請求項６のうちのいずれか１項に記載の通信システム。
8. グループに属するノードは、システム内通信用フレームに設定されている転送経路を示す経路情報を変更することによって、前記システム内通信用フレームの転送経路を変更する転送経路変更手段を備えた請求項１から請求項７のうちのいずれか１項に記載の通信システム。
9. グループに属さない各ノードは、前記グループに属するノードのうちのいずれか１つと対応づけられることによって、前記グループに属するノードのうちのいずれか１つに割り当てられ、
   送信判定手段は、ブロードキャストによる転送を示すシステム内通信用フレームを受信したときに、自ノードが前記グループに属するノードの中で前記システム内通信用フレームを最初に受信したノードであれば、前記システム内通信用フレームの送信元ノードが自ノードに割り当てられている場合であって、共通の接続先の端末またはノードとの間でフレームを送受信可能である場合に、および、自ノードが前記グループに属するノードの中で前記システム内通信用フレームを最初に受信したノードでなければ、前記システム内通信フレームに未送信識別子が付加されている場合または送信識別子が付加されていない場合であって、共通の接続先の端末またはノードとの間でフレームを送受信可能である場合に、送信する旨を決定し、
   転送経路変更手段は、前記送信判定手段が送信しない旨を決定した場合であって、自ノード以降の前記システム内通信用フレームの転送経路上に、前記グループに属する他のノードが配置されていない場合に、前記システム内通信用フレームの経路情報を前記グループに属する他のノードまで到達可能に変更する請求項８記載の通信システム。
10. 転送経路変更手段は、経路情報として、システム内通信用フレームに格納されているＴＴＬを変更する請求項８または請求項９に記載の通信システム。
11. グループに属さないノードは、システム内通信用フレームを受信した場合に、前記システム内通信用フレームで示される情報に基づいて、前記システム内通信用フレームに格納されているフレームを自ノードに接続される端末に送信するか否かを判定する第２の送信判定手段を備えた請求項１から請求項１０のうちのいずれか１項に記載の通信システム。
12. 第２の送信判定手段は、ブロードキャストによる転送を示すシステム内通信用フレームを受信したときに、前記システム内通信用フレームの送信元ノードが前記システム内通信用フレームの生成時に設定した転送経路上に自ノードが配置されていない場合に、送信しない旨を決定する請求項１１に記載の通信システム。
13. 送信判定手段は、システム内通信用フレームの宛先アドレスが自ノードと同じグループに属するノードのアドレスであって、共通の接続先の端末またはノードとの間でフレームを送受信可能である場合に、送信する旨を決定する請求項１から請求項１２のうちのいずれか１項に記載の通信システム。
14. 共通の端末は、該端末に接続される各ノードとのフレーム送受信の可否と、前記各ノードにおける当該通信システムが含む他のノードとのフレーム送受信の可否とに基づいて、前記ノードのいずれか１つにフレームを送信する選択送信手段を備えた請求項１から請求項１３のうちのいずれか１項に記載の通信システム。
15. 識別子付加手段は、システム内通信用フレームのヘッダ、または、システム内通信用フレームのプリアンブル、または、システム内通信用フレーム間のインタフレームギャップの予め定められたフィールドの値を用いることによって、識別子を表現する請求項１から請求項１４のうちのいずれか１項に記載の通信システム。
16. 識別子付加手段は、システム内通信用フレームの宛先アドレスに、ブロードキャストによる転送を示すブロードキャスト用アドレスとは異なるアドレスであって、当該通信システムに属するノードにおいて、ブロードキャスト用アドレスを宛先アドレスとするシステム内通信用フレームと同様のフレーム転送処理が行われるアドレスを用いることによって、識別子を表現する請求項１から請求項１４のうちのいずれか１項に記載の通信システム。
17. グループに属するノードは、自ノードに接続される当該通信システムが含む他のノードとの間の全リンクでフレームを送受信不可能な場合に、共通の接続先の端末またはノードに、自ノードとの間でフレームを送受信不可能な旨を検出させるリンク制御手段を備えた請求項１から請求項１６のうちのいずれか１項に記載の通信システム。
18. 当該通信システム、および、当該通信システムとは異なる共通の通信システムは、ＲＰＲネットワークである請求項１から請求項１７のうちのいずれか１項に記載の通信システム。
19. 端末が接続される複数のノードを含む通信システムにおいて、前記複数のノードのうち、リンクを介して共通の端末または当該通信システムとは異なる通信システムに含まれるノードが端末として接続されることによって、共通の接続先を有するグループとしてまとめられるノードであって、
    システム内通信用フレームに格納されている、当該通信システムが含むノードに接続される端末から受信したフレームを共通の接続先の端末またはノードに送信したか否かを示す識別子を、前記システム内通信用フレームに付加する識別子付加手段と、
    システム内通信用フレームを受信した場合に、前記システム内通信用フレームで示される情報に基づいて、前記システム内通信用フレームに格納されているフレームを共通の接続先の端末またはノードに送信するか否かを判定する送信判定手段とを備えた
    ことを特徴とするノード。
20. システム内通信用フレームに設定されている転送経路を示す経路情報を変更することによって、前記システム内通信用フレームの転送経路を変更する転送経路変更手段を備えた請求項１９に記載のノード。
21. グループに属さないノードであって、
    システム内通信用フレームを受信した場合に、前記システム内通信用フレームで示される情報に基づいて、前記システム内通信用フレームに格納されているフレームを自ノードに接続される端末に送信するか否かを判定する第２の送信判定手段を備えた請求項１９または請求項２０に記載のノード。
22. 端末が接続される複数のノードを含む通信システムであって、前記複数のノードのうちの一部のノードが、それぞれリンクを介して共通の端末または当該通信システムとは異なる通信システムに含まれるノードが端末として接続されることによって、共通の接続先を有するグループとしてまとめられる通信システムに適用される通信方法であって、
    前記グループに属するノードが、システム内通信用フレームに格納されている、当該通信システムが含むノードに接続される端末から受信したフレームを共通の接続先の端末またはノードに送信したか否かを示す識別子を、前記システム内通信用フレームに付加し、
    システム内通信用フレームを受信した場合に、前記システム内通信用フレームで示される情報に基づいて、前記システム内通信用フレームに格納されているフレームを共通の接続先の端末またはノードに送信するか否かを判定する
    ことを特徴とする通信方法。
23. グループに属するノードが、システム内通信用フレームに設定されている転送経路を示す経路情報を変更することによって、前記システム内通信用フレームの転送経路を変更する請求項２２に記載の通信方法。
24. グループに属さないノードが、システム内通信用フレームを受信した場合に、前記システム内通信用フレームで示される情報に基づいて、前記システム内通信用フレームに格納されているフレームを自ノードに接続される端末に送信するか否かを判定する請求項２２または請求項２３に記載の通信方法。
25. 端末が接続される複数のノードを含む通信システムにおいて、前記複数のノードのうち、リンクを介して共通の端末または当該通信システムとは異なる通信システムに含まれるノードが端末として接続されることによって、共通の接続先を有するグループとしてまとめられるノードが備えるコンピュータに、
    システム内通信用フレームに格納されている、当該通信システムが含むノードに接続される端末から受信したフレームを共通の接続先の端末またはノードに送信したか否かを示す識別子を、前記システム内通信用フレームに付加する処理、および
    システム内通信用フレームを受信した場合に、前記システム内通信用フレームで示される情報に基づいて、前記システム内通信用フレームに格納されているフレームを共通の接続先の端末またはノードに送信するか否かを判定する処理
    を実行させるためのノード用プログラム。
26. コンピュータに、
    システム内通信用フレームに設定されている転送経路を示す経路情報を変更することによって、前記システム内通信用フレームの転送経路を変更する処理
    を実行させるための請求項２５に記載のノード用プログラム。
27. グループに属さないノードが備えるコンピュータに、
    システム内通信用フレームを受信した場合に、前記システム内通信用フレームで示される情報に基づいて、前記システム内通信用フレームに格納されているフレームを自ノードに接続される端末に送信するか否かを判定する処理
    を実行させるための請求項２５または請求項２６記載のノード用プログラム。

Images