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

通信システム、通信方法、ノード、およびノード用プログラム Download PDF

Info

Publication number
JP4836008B2
JP4836008B2 JP2007553006A JP2007553006A JP4836008B2 JP 4836008 B2 JP4836008 B2 JP 4836008B2 JP 2007553006 A JP2007553006 A JP 2007553006A JP 2007553006 A JP2007553006 A JP 2007553006A JP 4836008 B2 JP4836008 B2 JP 4836008B2
Authority
JP
Japan
Prior art keywords
node
frame
rpr
network
terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2007553006A
Other languages
English (en)
Other versions
JPWO2007077998A1 (ja
Inventor
大作 小笠原
正宏 坂内
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Priority to JP2007553006A priority Critical patent/JP4836008B2/ja
Publication of JPWO2007077998A1 publication Critical patent/JPWO2007077998A1/ja
Application granted granted Critical
Publication of JP4836008B2 publication Critical patent/JP4836008B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4637—Interconnected ring systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/407—Bus networks with decentralised control
    • H04L12/413—Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection (CSMA-CD)
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/42—Loop networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2596—Translation of addresses of the same type other than IP, e.g. translation from MAC to MAC addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/618—Details of network addresses
    • H04L2101/622—Layer-2 addresses, e.g. medium access control [MAC] addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies

Description

本発明は、通信システム、通信方法、ノード、およびノード用プログラムに関し、特に信頼性の高い通信システム、およびそのような通信システムに適用される通信方法、ノード、およびノード用プログラムに関する。
近年、インターネットの普及により、基幹系通信システムのトラフィック量が急激に増大している。特に、基幹系通信システムを構成するネットワーク間を接続するリンク（以下、「インタリンク」と記述する。）を流れるトラフィックは膨大な量になる。よって、安定した通信を継続的に提供するために、トラフィックの集中による輻輳の発生を抑制し、かつ、インタリンクの切断またはインタリンク両端のノード（以下、「インタリンク接続ノード」と記述する。）の故障等の異常による通信の遮断を回避する高信頼化技術は、極めて重要である。
以降では、信頼性の高い基幹系通信システムを実現するネットワークの例として、非特許文献１に開示されているＲＰＲ（Resilient Packet Ring）が適用されたネットワークシステム（以下、「ＲＰＲネットワーク」と記述する。）を取り上げ、複数のＲＰＲネットワーク間を接続するインタリンクの信頼性を向上させる技術を説明する。非特許文献１は、２００４年にＩＥＥＥ（the Institute of Electrical and Electronics Engineers）から発行された標準化文書である。
図１９は、ＲＰＲネットワークの例を示す説明図である。ＲＰＲは、図１９に示すようなリングトポロジのネットワーク上で、フレーム（パケット）を転送するためのネットワークプロトコルである。
図１９に示す通信システムは、８台のＲＰＲに準拠して動作するノード（以下、「ＲＰＲノード」と記述する。）によりＲＰＲネットワークを構成し、各ＲＰＲノードの配下に１台の端末を収容した例である。なお、ＲＰＲノードの配下に端末を収容するとは、ＲＰＲノードに、そのＲＰＲノードが属するリングネットワークに属していない端末を接続させることである。なお、端末は、そのＲＰＲノードが属するリングネットワーク以外のリングネットワークに属する、あるいは、その他の通信ネットワークに属していてもよい。また、ＲＰＲノードの配下に収容される端末を、単に、配下の端末と記す場合もある。
図１９に示す例では、各ＲＰＲノード８００〜８７０は、それぞれポートＰ１〜Ｐ３を有する。各ＲＰＲノード８００〜８７０は、ポートＰ１，Ｐ２を用いて、隣接するＲＰＲノードとＲＰＲフレームを送受信する。また、各端末１３００〜１３７０は、ポートＰ１を有する。個々のＲＰＲノードと、ＲＲＰノードに接続される端末とは、ＲＰＲノードのポートＰ３と端末のポートＰ１とを用いてフレーム（イーサネットフレーム）を送受信する。なお、イーサネット（Ethernet）は、登録商標である。
ＲＰＲの主な特徴としては、高速のプロテクション機能が広く知られている。例えば、ＲＰＲネットワークおいて、ＲＰＲノード間のリンクが切断された場合、そのリンクの両側のＲＰＲノードが切断を検出した直後に、即座に他の全てのＲＰＲノードにその旨を通知する。障害発生の通知を受信した他のＲＰＲノードは、リンクの切断箇所を迂回するように、トラフィックを送信する動作状態に遷移する。これにより、通信を継続して行うことが可能である。
ＲＰＲは、都市網のように、大容量のトラフィックが流れる基幹系通信システムへの採用を前提として、ＳＤＨ（Synchronous Digital Hierarchy）またはＳＯＮＥＴ（Synchronous Optical Network）と同等の５０ｍｓ以内の短時間で通信を回復するように設計されている。そのため、信頼性の高い通信システムを構築することが可能である。
２個のＲＰＲネットワーク間を接続するインタリンクの信頼性を向上させる従来の技術として、非特許文献２に開示されているリンクアグリゲーション（Link Aggregation）がある（以下、「ＬＡＧ」と記す。）。なお、非特許文献２もＩＥＥＥから発行された標準化文書である。
ＬＡＧは、複数の物理ポートをあたかも１個の論理ポートに仮想化する技術である。換言すれば、複数のリンクをあたかも１本の論理リンクに仮想化する技術である。ＬＡＧの適用により、障害の発生していない通常時は、論理リンクに属する複数の物理リンクに分散してトラフィックが送信される。これにより、リンクの通信帯域を、最大で、論理リンクに属する物理リンクの通信帯域の総和に増大させることが可能である。また、論理リンクに属する物理リンクに切断が生じた異常時には、障害の発生していない他の正常な物理リンクのみを用いてフレームを転送することにより、通信を続行することが可能である。
図２０は、ＲＰＲネットワーク同士の接続にＬＡＧを適用した例を示す説明図である。図２０に示す通信システムでは、ＲＰＲネットワーク８０５とＲＰＲネットワーク９０５とが接続される。図２０に示す例では、ＲＰＲネットワーク８０５に属するＲＰＲノード８００およびＲＰＲネットワーク９０５に属するＲＰＲノード９００は、ポートＰ１〜Ｐ３の他にポートＰ４を有する。ＲＰＲノード８００のポートＰ３，Ｐ４にはＬＡＧが設定される。同様に、ＲＰＲノード９００のポートＰ３，Ｐ４にもＬＡＧが設定される。そして、ＲＰＲノード８００のポートＰ３とＰＲＰノード９００のポートＰ４とをインタリンク４９１により接続し、ＲＰＲノード８００のポートＰ４とＲＰＲノード９００のポートＰ３とをインタリンク４９２により接続する。このような構成により、図２０に示す例では、ＲＰＲネットワーク８０５とＲＰＲネットワーク９０５との間の接続の信頼性を向上させている。
また、２個のＲＰＲネットワーク間の接続の高信頼化技術が、特許文献１に開示されている。図２１は、特許文献１に記載されたネットワークの構成を示す説明図である。特許文献１に記載されたネットワークでは、図２１に示すように、ＲＰＲノード８００およびＲＰＲノード９００がＲＰＲネットワーク８０５およびＲＰＲネットワーク９０５の両方に属するように配置される。そして、ＲＰＲノード８００，９００のうち一方のノードが、現用ノードとして、ＲＰＲネットワーク８０５とＲＰＲネットワーク９０５との間のフレーム転送を行う。また、他方のノードが、予備用ノードとして、ＲＰＲネットワーク間のフレーム転送を行わないように設定される。予備用ノードが現用ノードの障害を検出した場合には、予備用ノードがＲＰＲネットワーク間のフレームの転送を行う動作状態に遷移する。そして、ＲＰＲノード８００とＲＰＲノード９００以外の全てのＲＰＲノードのフォワーディングデータベースの内容を消去させる。この結果、現用ノードを経由して転送されていたトラフィックが、予備用ノードを経由して転送されるようになるため、現用ノードに障害が発生したとしても、通信を継続して行うことができる。
また、特許文献２には、２つのリングネットワークを接続させた通信ネットワークシステムが記載されている。特許文献２に記載された通信ネットワークシステムでは、一方のリングネットワーク内の複数のリング間接続ノード装置と、他方のリングネットワーク内の複数のリング間接続ノード装置とを接続させる。
また、特許文献３には、代表プロトコルアドレスを用いたネットワーク間接続方法が記載されている。
特開２００３−２５８８２２号公報（段落００１５−００８５、図１） 特開２０００−４２４８号公報（段落００７３−００７６） 特許第３５９９４７６号公報（段落００６８） "IEEE Standards 802.17 Part 17：Resilient packet ring (RPR) access method & physical layer specifications"，"5. Architecture Overview"、IEEE (Institute of Electrical and Electronics Engineers,Inc 、２００４年、p. 27-54 "IEEE Std 802.3ad Amendment to Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications"，"43. Link Aggregation"、IEEE (Institute of Electrical and Electronics Engineers,Inc)、２０００年、p. 95-107
しかし、ＬＡＧに関しては、以下のような問題がある。ＬＡＧの適用により、１つの論理ポートに仮想化することが可能な物理ポートは、１つのノードに属する物理ポートに制限される。そのため、リンクの両端のノードの一方が故障すると、通信が遮断してしまうという問題がある。例えば、図２０に例示する通信システムにおいて、ＲＰＲノード８００またはＲＰＲノード９００のいずれか一方が故障すれば、ＲＰＲネットワーク８０５とＲＰＲネットワーク９０５との間の全ての通信が停止する。
また、特許文献１に記載にされた通信システムでは、ネットワークの接続点が複数個存在するにも関わらず、いずれか１つの接続点のみでフレームが転送される。よって、輻輳の発生を抑制することは困難である。
そこで、本発明は、ネットワーク間を接続するインタリンクやネットワークと端末とを接続するリンクの信頼性の高い通信システム、およびそのような通信システムに適用される通信方法、ノード、およびノード用プログラムを提供することを目的とする。また、インタリンクの一端に配置されるノードに障害が生じても、通信を行うことができる通信システム、通信方法、ノード、およびノード用プログラムを提供することを目的とする。
また、本発明は、輻輳の発生を抑制することができる通信システム、通信方法、ノード、およびノード用プログラムを提供することを目的とする。
本発明による通信システムは、同一のネットワーク上に設けられ、他のネットワークと接続するためのリンク接続ノードグループに属することを示す共通の仮想アドレスが割り当てられた複数の第１のノードと、前記同一のネットワーク上にあって端末フレームを送受信する端末が接続され、且つ、前記リンク接続ノードグループには属さない第２のノードとを有するネットワークを複数備え、前記各ネットワークの前記リンク接続ノードグループに属する複数の第１のノードと、他のネットワークの前記リンク接続ノードグループに属する複数の第１のノードとが、それぞれリンクを介して接続され、前記各ネットワークの第２のノードは、ノードの物理アドレスまたは仮想アドレスと端末のアドレスとの対応関係を端末フレームの転送履歴に基づきデータベースに記録するデータベース管理部と、端末から受信した端末フレームを格納したネットワークフレームを生成するフレーム生成部と、ネットワークフレームを自ノードのネットワークに送信するスイッチ処理部とを有し、前記フレーム生成部は、前記端末から受信した前記端末フレームの宛先に対応するアドレスを前記データベースから検索し、検索されたアドレスが前記仮想アドレスである場合に自ノードのネットワーク上の前記複数の第１のノードのうち前記他のネットワークとの通信が可能な前記第１のノードを選択対象とし、選択対象とした第１のノードの物理アドレスのいずれか１つを、前記受信した前記端末フレームに含まれている所定のパラメータに基づいて前記ネットワークフレームの宛先として決定し、前記宛先として決定された第１のノードは、前記ネットワークフレームを受信し、前記他のネットワークに受信したネットワークフレームを送信することを特徴とする。
また、本発明による通信システムは、同一のネットワーク上に設けられ、他のネットワークと接続するためのリンク接続ノードグループに属することを示す共通の仮想アドレスが割り当てられた複数の第１のノードと、前記同一のネットワーク上にあって端末フレームを送受信する端末が接続され、且つ、前記リンク接続ノードグループには属さない第２のノードとを有するネットワークを複数備え、前記各ネットワークの前記リンク接続ノードグループに属する複数の第１のノードと、他のネットワークの前記リンク接続ノードグループに属する複数の第１のノードとが、それぞれリンクを介して接続され、前記各ネットワークの第２のノードは、ノードの物理アドレスまたは仮想アドレスと端末のアドレスとの対応関係を端末フレームの転送履歴に基づきデータベースに記録するデータベース管理部と、端末から受信した端末フレームを格納したネットワークフレームを生成するフレーム生成部と、ネットワークフレームを自ノードのネットワークに送信するスイッチ処理部とを有し、前記フレーム生成部は、前記端末から受信した前記端末フレームの宛先に対応するアドレスを前記データベースから検索し、検索されたアドレスが前記仮想アドレスである場合に前記仮想アドレスを割り当てられた全ての第１のノードに対するマルチキャスト通信の宛先を前記ネットワークフレームの宛先に設定し、前記複数の第１のノードには、それぞれ前記ネットワークフレームを前記他のネットワークに送信することを示すパラメータ値が設定され、且つ、前記パラメータ値は前記複数の第１のノード間で重ならないように設定され、前記複数の第１のノードは、マルチキャスト通信の宛先が設定された前記ネットワークフレームを受信し、受信した前記ネットワークフレームに含まれているパラメータ値または前記ネットワークフレームに格納されている前記端末フレームに含まれているパラメータ値と自己の第１のノードに設定されたパラメータ値との比較結果に基づいて、前記端末フレームを送出するか否かの判定を行うスイッチ処理部を有し、他のネットワークとの通信が可能な前記複数の第１のノードのいずれか１つが、前記判定の結果に基づいて前記端末フレームを前記他のネットワークに送信することを特徴とする。
また、本発明による通信方法は、同一のネットワーク上に設けられ、他のネットワークと接続するためのリンク接続ノードグループに属することを示す共通の仮想アドレスが割り当てられた複数の第１のノードと、前記同一のネットワーク上にあって端末フレームを送受信する端末が接続され、且つ、前記リンク接続ノードグループには属さない第２のノードとを有するネットワークを複数備えるシステムの通信方法であって、前記各ネットワークの前記リンク接続ノードグループに属する複数の第１のノードと、他のネットワークの前記リンク接続ノードグループに属する複数の第１のノードとが、それぞれリンクを介して接続され、前記各ネットワークの第２のノードは、ノードの物理アドレスまたは仮想アドレスと端末のアドレスとの対応関係を端末フレームの転送履歴に基づきデータベースに記録し、端末から受信した端末フレームを格納したネットワークフレームを生成し、前記端末から受信した前記端末フレームの宛先に対応するアドレスを前記データベースから検索し、検索されたアドレスが前記仮想アドレスである場合に自ノードのネットワーク上の前記複数の第１のノードのうち前記他のネットワークとの通信が可能な前記第１のノードを選択対象とし、選択対象とした第１のノードの物理アドレスのいずれか１つを、前記受信した前記端末フレームに含まれている所定のパラメータに基づいて前記ネットワークフレームの宛先として決定し、前記宛先として決定された第１のノードは、前記ネットワークフレームを受信し、前記他のネットワークに受信したネットワークフレームを送信することを特徴とする。
また、本発明による通信方法は、同一のネットワーク上に設けられ、他のネットワークと接続するためのリンク接続ノードグループに属することを示す共通の仮想アドレスが割り当てられた複数の第１のノードと、前記同一のネットワーク上にあって端末フレームを送受信する端末が接続され、且つ、前記リンク接続ノードグループには属さない第２のノードとを有するネットワークを複数備えるシステムの通信方法であって、前記各ネットワークの前記リンク接続ノードグループに属する複数の第１のノードと、他のネットワークの前記リンク接続ノードグループに属する複数の第１のノードとが、それぞれリンクを介して接続され、前記各ネットワークの第２のノードは、ノードの物理アドレスまたは仮想アドレスと端末のアドレスとの対応関係を端末フレームの転送履歴に基づきデータベースに記録し、端末から受信した端末フレームを格納したネットワークフレームを生成し、前記端末から受信した前記端末フレームの宛先に対応するアドレスを前記データベースから検索し、検索されたアドレスが前記仮想アドレスである場合に前記仮想アドレスを割り当てられた全ての第１のノードに対するマルチキャスト通信の宛先を前記ネットワークフレームの宛先に設定し、前記複数の第１のノードには、それぞれ前記ネットワークフレームを前記他のネットワークに送信することを示すパラメータ値が設定され、且つ、前記パラメータ値は前記複数の第１のノード間で重ならないように設定され、前記複数の第１のノードは、マルチキャスト通信の宛先が設定された前記ネットワークフレームを受信し、受信した前記ネットワークフレームに含まれているパラメータ値または前記ネットワークフレームに格納されている前記端末フレームに含まれているパラメータ値と自己の第１のノードに設定されたパラメータ値との比較結果に基づいて、前記端末フレームを他のネットワークとのリンクに送出するか否かの判定を行い、他のネットワークとの通信が可能な前記複数の第１のノードのいずれか１つが、前記判定の結果に基づいて前記端末フレームを前記他のネットワークに送信することを特徴とする。
また、本発明によるノードは、同一のネットワーク上に設けられ、他のネットワークと接続するためのリンク接続ノードグループに属することを示す共通の仮想アドレスが割り当てられ、且つ、他のネットワークの前記リンク接続グループに属する複数の第１のノードに対して、それぞれリンクを介して接続された複数の第１のノードと、前記同一のネットワーク上にあって端末フレームを送受信する端末が接続され、且つ、前記リンク接続ノードグループには属さない第２のノードとを有するネットワークを複数備えるシステムの前記第２のノードとしてのノードであって、ノードの物理アドレスまたは仮想アドレスと端末のアドレスとの対応関係を端末フレームの転送履歴に基づきデータベースに記録するデータベース管理部と、端末から受信した端末フレームを格納したネットワークフレームを生成するフレーム生成部と、ネットワークフレームを自ノードのネットワークに送信するスイッチ処理部とを有し、前記フレーム生成部は、前記端末から受信した前記端末フレームの宛先に対応するアドレスを前記データベースから検索し、検索されたアドレスが前記仮想アドレスである場合に自ノードのネットワーク上の前記複数の第１のノードのうち前記他のネットワークとの通信が可能な前記第１のノードを選択対象とし、選択対象とした第１のノードの物理アドレスのいずれか１つを、前記受信した前記端末フレームに含まれている所定のパラメータに基づいて前記ネットワークフレームの宛先として決定することを特徴とする。
また、本発明によるノードは、同一のネットワーク上に設けられ、他のネットワークと接続するためのリンク接続ノードグループに属することを示す共通の仮想アドレスが割り当てられ、且つ、他のネットワークの前記リンク接続グループに属する複数の第１のノードに対して、それぞれリンクを介して接続された複数の第１のノードと、前記同一のネットワーク上にあって端末フレームを送受信する端末が接続され、且つ、前記リンク接続ノードグループには属さない第２のノードとを有するネットワークを複数備えるシステムの前記第１のノードとしてのノードであって、前記複数のノードには、それぞれ前記ネットワークフレームを前記他のネットワークに送信することを示すパラメータ値が設定され、且つ、前記パラメータ値は前記複数の第１のノード間で重ならないように設定され、自ノードが属するリンク接続グループに対するマルチキャスト通信の宛先が設定された前記ネットワークフレームを受信し、受信した前記ネットワークフレームに含まれているパラメータ値または前記ネットワークフレームに格納されている前記端末フレームに含まれているパラメータ値と自己の第１のノードに設定されたパラメータ値との比較結果に基づいて、前記端末フレームを他のネットワークとのリンクに送出するか否かの判定を行うスイッチ処理部を有し、他のネットワークとの通信が可能な前記複数の第１のノードのいずれか１つが、前記判定の結果に基づいて前記端末フレームを前記他のネットワークに送信することを特徴とする。
また、本発明によるプログラムは、同一のネットワーク上に設けられ、他のネットワークと接続するためのリンク接続ノードグループに属することを示す共通の仮想アドレスが割り当てられ、且つ、他のネットワークの前記リンク接続グループに属する複数の第１のノードに対して、それぞれリンクを介して接続された複数の第１のノードと、前記同一のネットワーク上にあって端末フレームを送受信する端末が接続され、且つ、前記リンク接続ノードグループには属さない第２のノードとを有するネットワークを複数備えるシステムの前記第２のノードとしてのノードのためのプログラムであって、前記ノードを、ノードの物理アドレスまたは仮想アドレスと端末のアドレスとの対応関係を端末フレームの転送履歴に基づきデータベースに記録するデータベース管理手段と、端末から受信した端末フレームを格納したネットワークフレームを生成するフレーム生成手段と、前記ネットワークフレームを自ノードのネットワークに送信するスイッチ処理部として機能させ、前記フレーム生成部を、前記端末から受信した前記端末フレームの宛先に対応するアドレスを前記データベースから検索し、検索されたアドレスが前記仮想アドレスである場合に自ノードのネットワーク上の前記複数の第１のノードのうち前記他のネットワークとの通信が可能な第１のノードを選択対象とし、選択対象とした第１のノードの物理アドレスのいずれか１つを、前記受信した前記端末フレームに含まれている所定のパラメータに基づいて前記ネットワークフレームの宛先として決定する手段と、して機能させることを特徴とする。
また、本発明によるプログラムは、同一のネットワーク上に設けられ、他のネットワークと接続するためのリンク接続ノードグループに属することを示す共通の仮想アドレスが割り当てられ、且つ、他のネットワークの前記リンク接続グループに属する複数の第１のノードに対して、それぞれリンクを介して接続された複数の第１のノードと、前記同一のネットワーク上にあって端末フレームを送受信する端末が接続され、且つ、前記リンク接続ノードグループには属さない第２のノードとを有するネットワークを複数備えるシステムの前記第１のノードとしてのノードのためのプログラムであって、前記複数のノードには、それぞれ前記ネットワークフレームを前記他のネットワークに送信することを示すパラメータ値が設定され、且つ、前記パラメータ値は前記複数の第１のノード間で重ならないように設定され、前記ノードを、自ノードが属するリンク接続グループに対するマルチキャスト通信の宛先が設定された前記ネットワークフレームを受信し、受信した前記ネットワークフレームに含まれているパラメータ値または前記ネットワークフレームに格納されている前記端末フレームに含まれているパラメータ値と自己の第１のノードに設定されたパラメータ値との比較結果に基づいて、前記端末フレームを他のネットワークとのリンクに送出するか否かの判定を行うスイッチ処理手段と、他のネットワークとの通信が可能な前記複数の第１のノードのいずれか１つを、前記判定の結果に基づいて前記端末フレームを前記他のネットワークに送信する手段と、して機能させることを特徴とする。
本発明では、グループに属する第１のノードが、それぞれリンクを介して他のネットワークの第１のノードに接続される。従って、各ネットワークは、複数のリンクを介して接続されることになる。よって、ネットワーク間のリンクの通信の信頼性を高めることができる。また、複数のリンクを介して接続されるので、ネットワーク間の通信帯域を拡大することができる。
また、グループに属さない第２のノードが、ネットワークフレームの宛先を１つ決定するとき、端末フレームに含まれる情報に応じて決定することから、常に同じアドレスが決定されることを防止できる。従って、特定の第１のノードにのみネットワークフレームが送信されることに起因した輻輳が生じることを防止することができる。
また、グループに属さない第２のノードは、ネットワークフレームの宛先アドレスを決定するとき、グループに属する第１のノードのうち障害が発生していないノードのアドレスを選定する。従って、障害が発生している第１のノードにネットワークフレームが送信されることを防止できる。よって、いずれかの第１のノードに障害が発生したとしても、他の第１のノードを選択することにより、通信を継続することができる。
また、第１のノードにネットワークフレームがマルチキャスト送信されたとき、いずれか１つの第１のノードのみが、そのネットワークフレーム内の端末フレームを他のネットワークとのリンクへ送出すると判定する。従って、第１のノードが、端末フレームを送出するか否かを、ネットワークフレームに含まれる情報、あるいは、その端末フレームに含まれる情報に応じて判定することにより、端末フレームを他のネットワークとのリンクに送出するノードが常に同じ第１のノードとなることを防止できる。これにより、そのリンクに輻輳が生じることを防止することができる。
また、各ネットワークの第１のノードは、自ノードの物理アドレスとは別にグループに割り当てられた共通の仮想アドレスが設定されることで、グループとしてまとめられる。従って、任意のノードを第１のノードとしてグループにまとめることができるので、局舎の位置またはリンクの敷設場所等の制約を受け難い。したがって、複数のインタリンクを任意の場所に配置することができる。
本発明の通信システムによれば、ネットワークにてグループに属する第１のノードが、それぞれリンクを介して、他のネットワークの第１のノードと接続される。これにより、ネットワーク間の通信の信頼性が高められると共に、ネットワーク間の通信帯域を拡大することができる。
本発明による通信システムの第１の実施の形態を示す説明図である。 不適切な端末の接続態様の例を示す説明図である。 ＲＰＲノードの構成例を示すブロック図である。 ＦＤＢに登録された対応関係の例を示す説明図である。 ＴＤＢに登録された情報の例を示す説明図である。 インタリンク接続ノードグループテーブルに登録される情報の例を示す説明図である。 アドレスマッピングテーブルに登録される情報の例を示す説明図である。 ＭＡＣアドレス管理テーブルに記憶される情報の例を示す説明図である。 インタリンク接続ノードにおける配下の端末へのイーサネットフレーム送信動作の処理経過を示すフローチャートである。 ＲＰＲネットワークに属するＲＰＲノードの配下の端末を宛先とするイーサネットフレームを受信したＲＰＲノードの処理経過の例を示すフローチャートである。 インタリンク接続ノードグループに属するインタリンク接続ノードがマルチキャスト送信されたＲＰＲフレームを受信した場合における処理経過の例を示すフローチャートである。 インタリンクに障害が発生した場合におけるＲＰＲネットワークに属するＲＰＲノードの動作の例を示すフローチャートである。 インタリンクの障害が復旧した場合におけるＲＰＲネットワークに属するＲＰＲノードの動作の例を示すフローチャートである。 ＴＤＢに登録された情報の例を示す説明図である。 本発明による通信システムの第２の実施の形態を示す説明図である。 ＥｏＥエッジノードの構成例を示すブロック図である。 中継用ＦＤＢに登録された対応関係の例を示す説明図である。 実施の形態による通信システムの第３の実施の形態を示す説明図である。 ＲＰＲネットワークの例を示す説明図である。 ＲＰＲネットワーク同士の接続にＬＡＧを適用した例を示す説明図である。 従来のネットワークの構成の例を示す説明図である。
符号の説明
１０，２０ ＲＰＲネットワーク
１００〜１７０，２００〜２７０ ＲＰＲノード
４２０，４３０，４４０ インタリンク
５００−１，５００−２，５００−３ 入力ポート
５１０−１，５１０−２ フレーム解析部 ５３０ ＲＰＲスイッチ処理部
５４０ ＦＤＢ
５５０ ＦＤＢ管理部
５６０ ＴＤＢ
５７０ イーサネットフレーム抽出部
５８０−１，５８０−２，５８０−３ 出力ポート
５９０ インタリンク接続ノードグループテーブル
６００ アドレスマッピングテーブル
６１０ アドレスマッピングテーブル管理部
６２０ ポート状態監視部
６３０ ＭＡＣアドレス管理テーブル
以下、本発明の実施の形態を図面を参照して説明する。
実施の形態１．
図１は、本発明による通信システムの第１の実施の形態を示す説明図である。第１の実施の形態の通信システムは、それぞれＲＰＲノードを含むＲＰＲネットワーク１０およびＲＰＲネットワーク２０を備える。既に述べたように、ＲＰＲネットワークは、ＲＰＲが適用されたネットワークシステムである。
ＲＰＲノードは、“IEEE Standards 802.17”に準拠して動作するノードである。本発明の通信システムが備えるＲＰＲノード（図１に示す例ではＲＰＲノード１００〜１７０，２００〜２７０）は、“IEEE Standards 802.17”に準拠して動作するだけでなく、他の動作（本発明の目的を実現するための動作）も行う。
ＲＰＲネットワーク１０，２０は、インタリンク４２０，４３０，４４０を介して接続されている。インタリンクは、通信システムが備える異なるネットワーク（本例ではネットワーク１０，２０）内のノード間を接続するリンクである。
第１の実施の形態の各ＲＰＲノードは、それぞれ３つのポートＰ１，Ｐ２，Ｐ３を有する。ポートＰ１，Ｐ２は、ＲＰＲフレームを送受信するためのポートである。各ＲＰＲノード１００〜１７０，２００〜２７０は、隣接するＲＰＲノードに対し、ポートＰ１，Ｐ２を用いてＲＰＲフレームを送受信する。ポートＰ３は、そのノードの配下に収容する端末との間でイーサネットフレームを送受信するためのポートである。イーサネットフレームは、本発明における端末フレームに対応する通信フレームである。
ＲＰＲネットワーク１０，２０を接続するインタリンク４２０は、ＲＰＲノード１００のポートＰ３と、ＲＰＲノード２００のポートＰ３との間に設けられる。同様に、インタリンク４３０は、ＲＰＲノード１１０のポートＰ３と、ＲＰＲノード２７０のポートＰ３との間に設けられる。また、インタリンク４４０は、ＲＰＲノード１６０のポートＰ３と、ＲＰＲノード２３０のポートＰ３との間に設けられる。以降の説明において、インタリンクの両端に配置されたノードを「インタリンク接続ノード」と記す。図１に示す例では、ＲＰＲノード１００，２００、ＲＰＲノード１１０，２７０、ＲＰＲノード１６０，２３０がインタリンク接続ノードである。
ＲＰＲネットワーク１０に属するＲＰＲノード１００，１１０，１６０と、ＲＰＲネットワーク２０に属するＲＰＲノード２００，２７０，２３０とは、インタリンク４２０，４３０，４４０によって、それぞれ一対一に接続される。
なお、ＲＰＲネットワーク１０のインタリンク接続ノード１００，１１０，１６０にとっては、それぞれ、ＲＰＲネットワーク２０のインタリンク接続ノード２００，２７０，２３０が、配下の端末に相当する。同様に、ＲＰＲネットワーク２０のインタリンク接続ノード２００，２７０，２３０にとっては、それぞれ、ＲＰＲネットワーク１０のインタリンク接続ノード１００，１１０，１６０が、配下の端末に相当する。
図１では図示を省略しているが、インタリンク接続ノードであるＲＰＲノード１００、１１０、１６０、２００、２３０、２７０を除く各ＲＰＲノード１２０，１３０，１４０，１５０，１７０，２１０，２２０，２４０，２５０，２６０のポート３には、図１９に示すＲＰＲネットワークと同様に、配下の端末が１台収容されているものとする。
インタリンク接続ノード以外の各ＲＰＲノード１２０，１３０，１４０，１５０，１７０，２１０，２２０，２４０，２５０，２６０の配下に収容されている端末に、別のノードまたは他のネットワークが接続されていてもよい。ただし、その場合、配下の端末間でループが形成されると、そのループに起因してブロードキャストストームが生じることにより、通信が不安定になる等の問題が生じる。よって、インタリンク接続ノード以外の各ＲＰＲノードの配下の端末が、相互間でループを形成する構成は、避けることが望ましい。
図２は、不適切な端末の接続態様の例を示す説明図である。図２に示すように、ＲＰＲノード１３０に端末７１が接続され、ＲＰＲノード１２０に端末７２が接続されているとする。また、ＲＰＲノード２６０に端末７３が接続され、さらに端末７３に端末７４が接続されているとする。また、ＲＰＲノード２５０に端末７５が接続され、端末７５に端末７６が接続され、さらに端末７６に端末７７が接続されているとする。また、端末７３と端末７６が接続されているとする。図２に示す接続態様では、インタリンク接続ノード以外のＲＰＲノード２５０，２６０および端末７３，７６を含むループが形成される。すると、ブロードキャストストームが生じることがある。また、端末７１，７２間の通信が可能であったとしても、ループに含まれるＲＰＲノード２６０等を介した端末７４および端末７２間の通信は行えない等、通信が不安定になるという問題が生じる。よって、図２に例示するような、ＲＰＲノード２５０，２６０および端末７３，７６を含むループの形成は望ましくない。
図１に示す通信システムにおいて、同一のＲＰＲネットワークに属するＲＰＲノード間では、ＲＰＲフレームを送受信する。ＲＰＲフレームは、本発明におけるシステムフレームに対応する通信フレームである。ＲＰＲノードとその配下に収容される端末との間では、イーサネットフレームを送受信する。また、異なるＲＰＲネットワークに属するインタリンク接続ノード間では、イーサネットフレームを送受信する。ＲＰＲフレームは、ペイロードにイーサネットフレームを格納してカプセル化したフレームである。ＲＰＲフレームのヘッダには、送信元および宛先のアドレスやＴＴＬ（Time to Live）が含まれる。ＲＰＲフレームには、送信元および送信先のアドレスとして、ＲＰＲノードのアドレス、ブロードキャスト送信を示すアドレス、あるいは、マルチキャスト送信を示すアドレスが格納される。
次に、ＲＰＲノードの構成について説明する。図３は、図１に示す通信システムが備えるＲＰＲノードの構成例を示すブロック図である。ここでは、図１に示すＲＰＲノード１００を例に説明するが、他のＲＰＲノード１１０〜１７０およびＲＰＲノード２００〜２７０の構成も、ＲＰＲノード１００の構成と同様である。
図３に示すように、ＲＰＲノード１００は、入力ポート５００−１〜−３と、フレーム解析部５１０−１，−２と、ＲＰＲフレーム生成部５２０と、ＲＰＲスイッチ処理部５３０と、ＦＤＢ５４０と、ＦＤＢ管理部５５０と、ＴＤＢ（Topology DataBase）５６０と、イーサネットフレーム抽出部５７０と、出力ポート５８０−１〜−３と、インタリンク接続ノードグループテーブル５９０と、アドレスマッピングテーブル６００と、アドレスマッピングテーブル管理部６１０と、ポート状態監視部６２０と、ＭＡＣアドレス管理テーブル６３０とを備える。
ＲＰＲノード１００の入力ポート５００−１〜−３は、図１に示すＲＰＲノード１００のポートＰ１〜Ｐ３の受信側に対応するポートである。入力ポート５００−１，−２は、隣接するＲＰＲノードから送信されるＲＰＲフレームを受信するポートである。また、入力ポート５００−３は、配下の端末から送信されるイーサネットフレームを受信するポートである。
本実施形態のＲＰＲノード１００の入力ポート５００−１は、図１において時計回り方向に隣接するＲＰＲノード１１０の出力ポート５８０−２から送信されるＲＰＲフレームを受信する。
また、ＲＰＲノード１００の入力ポート５００−２は、反時計回り方向に隣接するＲＰＲノード１７０の出力ポート５８０−１から送信されるＲＰＲフレームを受信する。
また、ＲＰＲノード１００の入力ポート５００−３は、配下の端末から送信されるイーサネットフレームを受信するポートである。ＲＰＲノード１００はインタリンク接続ノードであり、ＲＰＲノード１００の配下の端末は、ＲＰＲネットワーク２０に属するＲＰＲノード２００である。従って、ＲＰＲノード１００の入力ポート５００−３は、ＲＰＲノード２００から送信されるイーサネットフレームを受信する。また、例えば、ＲＰＲノード１２０の入力ポート５００−３は、配下の端末（図示せず。）から送信されるイーサネットフレームを受信する。
ＲＰＲノード１００の出力ポート５８０−１〜−３は、図１に示すＲＰＲノード１００のポートＰ１〜Ｐ３における送信側に対応するポート（フレームを送信するポート）である。出力ポート５００−１，２は、隣接するＲＰＲノードにＲＰＲフレームを送信するポートである。また、出力ポート５００−３は、配下の端末にイーサネットフレームを送信するポートである。
ＲＰＲノード１００の出力ポート５８０−１は、図１の時計回り方向に隣接するＲＰＲノード１１０の入力ポート５００−２にＲＰＲフレームを送信する。
また、ＲＰＲノード１００の出力ポート５８０−２は、反時計回り方向に隣接するＲＰＲノード１７０の入力ポート５００−１にＲＰＲフレームを送信する。
また、出力ポート５８０−３は、配下の端末にイーサネットフレームを送信するポートである。例えば、ＲＰＲノード１００の出力ポート５８０−３は、配下の端末であるＲＰＲノード２００にイーサネットフレームを送信する。また、例えば、ＲＰＲノード１２０の出力ポート５８０−３は、配下の端末（図示せず。）にイーサネットフレームを送信する。
フレーム解析部５１０−１，５１０−２は、それぞれ入力ポート５００−１，５００−２に対応する。フレーム解析部５１０−１，５１０−２には、それぞれ対応する入力ポートからＲＰＲフレームが入力される。そして、各フレーム解析部５１０−１，５１０−２は、特殊ＲＰＲフレームをアドレスマッピングテーブル管理部６００に送り、特殊ＲＰＲフレーム以外のＲＰＲフレームをＲＰＲスイッチ処理部５３０に送る。
特殊ＲＰＲフレームとは、アドレスマッピングテーブル６００に記憶されているアドレス（ＭＡＣアドレス）の削除あるいは追加を指示するＲＰＲフレームまたは、以下に説明するＲＰＲフレームである。
同一のＲＰＲネットワークに属するインタリンク接続ノードは、グループ（「インタリンク接続ノードグループ」と呼ぶ。）にまとめられる。ブロードキャスト送信されたＲＰＲフレーム、あるいは、そのグループに属する各ＲＰＲノードにマルチキャスト送信されたＲＰＲフレームに格納されたイーサネットフレームは、グループに属するインタリンク接続ノードのうちいずれか一つによって、他のＲＰＲネットワークに送信される。このイーサネットフレームを他のＲＰＲネットワークに送信するインタリンク接続ノードおよびその判定基準の変更を指示するＲＰＲフレームも特殊ＲＰＲフレームに該当する。
特殊ＲＰＲフレームは、制御用フレームの一種であるが、標準化文書（非特許文献１）には記載されていない制御用フレームである。
ＲＰＲフレーム生成部５２０には、入力ポート５００−３からイーサネットフレームが入力される。そして、ＲＰＲフレーム生成部５２０は、入力されたイーサネットフレームをカプセル化することにより、ＲＰＲフレームを生成する。
ＲＰＲスイッチ処理部５３０は、“IEEE Standards 802.17”において定義されるＲＰＲに関する処理を行う。
ＲＰＲスイッチ処理部５３０が行う処理の例として、隣接するＲＰＲノードから受信したＲＰＲフレームの転送、Ｔｏｐｏｌｏｇｙ Ｄｉｓｃｏｖｅｒｙ ＰｒｏｔｏｃｏｌによるＲＰＲネットワークのトポロジ情報の管理、ＦａｉｒｎｅｓｓによるＲＰＲネットワーク上のトラフィックの通信帯域の動的制御、ＯＡＭ（Operations, Administration, Maintenance）によるＲＰＲネットワークの管理等がある。
以降の説明では、ＲＰＲスイッチ処理部５３０の処理の詳細については、本発明によるノードの動作に深く関わる動作を除き、説明を省略する。
ＦＤＢ５４０は、端末のＭＡＣアドレスとＲＰＲノードのＭＡＣアドレスとの対応関係、及び、端末のＭＡＣアドレスとインタリンク接続ノードグループに割り当てられた仮想ＭＡＣアドレスとの対応関係を記憶するデータベースである。
ＦＤＢ５４０には、端末のＭＡＣアドレスとＲＰＲノードのＭＡＣアドレスとの対応関係が、後述のＦＤＢ管理部５５０により登録される。また、端末のＭＡＣアドレスとインタリンク接続ノードグループに割り当てられた仮想ＭＡＣアドレスとの対応関係もＦＤＢ管理部５５０により登録される。データフレームを送受信する過程で、このような対応関係をＦＤＢ５４０に登録していく処理を、ＭＡＣアドレス学習と呼ぶ。
なお、インタリンク接続ノードグループとは、同一のＲＰＲネットワークに属するインタリンク接続ノードのうち、他の共通のＲＰＲネットワークまたは端末と接続されるＲＰＲノードのグループである。例えば、図１に示すＲＰＲネットワーク１０では、他の共通のＲＰＲネットワークとなるＲＰＲネットワーク２０に接続されるインタリンク接続ノード１００，１１０，１６０のグループが、インタリンク接続ノードグループとなる。同様に、インタリンク接続ノード２００，２７０，２３０のグループがインタリンク接続ノードグループとなる。また、インタリンク接続ノードグループには、ＲＰＲノードと同様にＭＡＣアドレスが割り当てられる。仮想ＭＡＣアドレスとは、インタリンク接続ノードグループに割り当てられたＭＡＣアドレスである。
本発明では、インタリンク接続ノードグループに仮想ＭＡＣアドレスを割り当て、複数のインタリンク接続ノードを１台のインタリンク接続ノードに仮想化することで、正常時はインタリンクの通信帯域を増大させる。そして、障害発生時には、正常なインタリンクを用いてフレームを転送することにより、ネットワーク間の通信を続行可能とする。
図４は、ＲＰＲノード１００のＦＤＢ５４０に登録された対応関係の例を示す説明図である。図４における例えば上から２段目の登録情報には、ＲＰＲノード１３０の配下に接続される端末のＭＡＣアドレスと、ＲＰＲノード１３０のＭＡＣアドレスとが対応付けられている。ＲＰＲノード１００は、ＲＰＲノード１３０の配下に接続される端末のＭＡＣアドレスを宛先とするイーサネットフレームを受信し、そのイーサネットフレームをカプセル化してＲＰＲフレームを生成するとき、ＲＰＲノード１３０のＭＡＣアドレスをＲＰＲフレームの宛先ＭＡＣアドレスとして記述する。
また、図４では示していないが、端末のＭＡＣアドレスと、仮想ＭＡＣアドレスとが対応付けられてＦＤＢ５４０に登録されてもよい。例えば、ＲＰＲネットワーク２０に属するＲＰＲノードのＦＤＢ５４０に、ＲＰＲネットワーク１０に属するＲＰＲノード１４０の配下の端末のＭＡＣアドレスと、ＲＰＲネットワーク２０のインタリンク接続ノードグループに割り当てられた仮想ＭＡＣアドレスとの対応関係を登録するという例である。この例において、ＲＰＲネットワーク２０に属するＲＰＲノードが、自ノード配下の端末からのイーサネットフレームをＲＰＲノード１４０配下の端末に転送するとする。この場合、ＲＰＲネットワーク２０に属するＲＰＲノードは、ＲＰＲノード１４０配下の端末のＭＡＣアドレスに対応付けられた仮想アドレスを参照して、ＲＰＲフレームの宛先ＭＡＣアドレスを決定する。
ＦＤＢ管理部５５０は、自ノード（そのＦＤＢ管理部５５０を備えるＲＰＲノード）の各種状態、または、自ノードが備える他の構成要素からの要求に従って、ＦＤＢ５４０に登録された内容を更新する。例えば、ＲＰＲノード１００のＦＤＢ管理部５５０は、イーサネットフレーム抽出部５７０からの要求により、端末のＭＡＣアドレスとその端末を収容しているＲＰＲノードのＭＡＣアドレスとの対応関係、または、端末のＭＡＣアドレスとインタリンク接続ノードグループに対して割り当てられる仮想ＭＡＣアドレスとの対応関係をＦＤＢ５４０に登録する。具体的には、ＦＤＢ管理部５５０は、自ノードが受信したＲＰＲフレームの送信元ＭＡＣアドレス（ＲＰＲノードのＭＡＣアドレスあるいは仮想ＭＡＣアドレス）と、そのＲＰＲフレームにカプセル化されたイーサネットフレームの送信元ＭＡＣアドレス（端末のＭＡＣアドレス）との対応関係をＦＤＢ５４０に登録する。また、ＲＰＲノード１００が備える他の構成要素からの要求に従って、ＦＤＢ５４０の内容を更新する。
ＴＤＢ５６０は、自ノード（そのＴＤＢ５６０を備えるＲＰＲノード）が属するＲＰＲネットワークのトポロジの状態、および、障害の発生状況等の情報を管理するためのデータベースである。例えば、ＲＰＲノード１００のＴＤＢ５６０は、ＲＰＲネットワーク１０のトポロジの状態等を管理するためのデータベースである。
ＴＤＢ５６０に登録されるＲＰＲネットワークに関する情報は、Ｔｏｐｏｌｏｇｙ Ｄｉｓｃｏｖｅｒｙ Ｐｒｏｔｏｃｏｌに従うＲＰＲスイッチ処理部５３０によって管理される。
図５は、ＲＰＲノード１００のＴＤＢ５６０に登録された情報の例を示す説明図である。図５に示すＴＤＢ５６０の例では、ＲＰＲネットワーク１０に属する各ＲＰＲノードのポートＰ１，Ｐ２の状態がそれぞれ有効であるか無効であるかを示す情報が登録されている。有効とは、ポートを運用可能な状態を意味し、無効とは、ポートを運用できない状態を意味する。また、ＴＤＢ５６０には、ＲＰＲノードのノード識別子に対応付けられて、ポートＰ１，Ｐ２の状態を示す情報が登録される。そして、ＲＰＲノードのノード識別子として、ＲＰＲノードのＭＡＣアドレスが用いられる。
図５に示すＴＤＢでは、例えば、ＲＰＲノード１４０のポートＰ１のポート状態は有効であり、また、ＲＰＲノード１４０のポートＰ２のポート状態は無効であることが示されている。これは、ＲＰＲノード１４０は、ポートＰ１でＲＰＲフレームを送受信でき、かつ、ポートＰ２でＲＰＲフレームを送受信できないことを示唆する。
また、例えば、図５に示す例では、ＲＰＲノード１５０のポートＰ１のポート状態が無効であることが示されている。この情報から、何らかの理由により、ＲＰＲノード１４０とＲＰＲノード１５０とを接続するリンクに障害が発生していることがわかる。
他のノードのポート状態は、以下のように登録される。各ＲＰＲノードは、ＲＰＲネットワークのトポロジを管理するために、ポートＰ１，Ｐ２の状態を格納したＴＰフレーム（Topology and Protection frame）を一定の時間間隔でブロードキャスト送信する。ＲＰＲスイッチ処理部５３０は、各ＲＰＲノードから送信されるＴＰフレームを参照して、ＴＤＢ５６０に登録されたＲＰＲノードのポートＰ１，Ｐ２の状態を更新する。また、ＴＤＢ５６０に登録された自ノードのポートＰ１，Ｐ２の状態は、ポート状態監視部６２０によって更新される。すなわち、ポート状態監視部６２０が、自ノードのポートＰ１，Ｐ２の状態を監視し、その状態をＴＤＢ５６０に登録し更新する。
なお、図５に示す例では、説明を簡単にするため、ＲＰＲノードのポート状態が有効か無効かを示す情報のみを示しているが、“IEEE Standards 802.17”で定義されているＴＤＢでは、ＲＰＲネットワークを構成するＲＰＲノードに関する様々な情報が管理される。ＴＤＢ５６０には、図５には図示されていないこれらの情報についても登録される。
イーサネットフレーム抽出部５７０には、ＲＰＲスイッチ処理部５３０からＲＰＲフレームが供給される。イーサネットフレーム抽出部５７０は、そのＲＰＲフレームのペイロードに格納されたイーサネットフレームを抽出する。
インタリンク接続ノードグループテーブル５９０は、自ノード（そのインタリンク接続ノードグループテーブル５９０を備えるＲＰＲノード）が属するＲＰＲネットワークに属するインタリンク接続ノードのうち、他の共通のネットワークシステムまたは端末と接続されるＲＰＲノードを、１つのインタリンク接続ノードグループとして記憶するテーブルである。図１に示す通信システムの場合、ＲＰＲネットワーク１０に属するインタリンク接続ノードのうち、他の共通のＲＰＲネットワーク２０と接続されるＲＰＲノードは、ＲＰＲノード１００，１１０，１６０である。従って、ＲＰＲネットワーク１０に属する各ＲＰＲノードのインタリンク接続ノードグループテーブル５９０には、ＲＰＲノード１００，１１０，１６０からなるグループが１つのインタリンク接続ノードグループとして登録される。
図６は、インタリンク接続ノードグループテーブル５９０に登録される情報の例を示す説明図である。インタリンク接続ノードグループテーブル５９０には、インタリンク接続ノードグループの名称と、そのグループの識別子と、そのグループに属する各インタリンク接続ノードのＭＡＣアドレスとが対応付けて登録される。インタリンク接続ノードグループの識別子には、そのインタリンク接続ノードグループに割り当てられた仮想ＭＡＣアドレスが用いられる。図６に示す例では、インタリンク接続ノードグループの名称として“Ａ”が登録されている。そして、その名称“Ａ”に対応付けて、インタリンク接続ノードグループ“Ａ”に割り当てられた仮想ＭＡＣアドレス“ａ”と、インタリンク接続ノードグループ“Ａ”に属する各インタリンク接続ノード１００，１１０，１６０のＭＡＣアドレスが登録されている。
各ＲＰＲノードは、自ノードのＭＡＣアドレスがインタリンク接続ノードグループテーブル５９０に登録されているか否かにより、自ノードがインタリンク接続ノードであるか否かを判定することができる。
なお、インタリンク接続ノードグループテーブル５９０には複数のインタリンク接続ノードグループが登録されてもよい。ただし、ループの構成となることを避けるために、異なるインタリンク接続ノードグループに属するＲＰＲノードは、異なるＲＰＲネットワークに接続されているという条件を満たしていなければならない。すなわち、１つのＲＰＲノードが複数のインタリンク接続ノードグループに同時に属することがあってはならない。
インタリンク接続ノードグループの名称、仮想ＭＡＣアドレス、各インタリンク接続ノードのＭＡＣアドレスのインタリンク接続ノードグループテーブル５９０への登録は、通信システムの管理者によって、管理インタフェースを介して行われる。管理インタフェースは、インタリンク接続ノードグループテーブル５９０やＭＡＣアドレス管理テーブル６３０に登録される情報が入力されるインタフェースである。
アドレスマッピングテーブル６００は、インタリンク接続ノードグループテーブル５９０に登録されているインタリンク接続ノードグループに割り当てられた仮想ＭＡＣアドレスと、そのインタリンク接続ノードグループに属するＲＰＲノードのＭＡＣアドレスとの対応関係を記憶するテーブルである。
インタリンク接続ノードグループテーブル５９０にＭＡＣアドレスが登録されたＲＰＲノードは、そのＭＡＣアドレスがアドレスマッピングテーブル６００に登録されることにより、フレームの転送処理時に、そのインタリンク接続ノードグループに属するＲＰＲノードであると認識される。
図７は、アドレスマッピングテーブル６００に登録される情報の例を示す説明図である。図７に示す例では、インタリンク接続ノードグループの仮想ＭＡＣアドレス“ａ”と、そのインタリンク接続ノードグループに属するＲＰＲノード１００、１１０、１６０のＭＡＣアドレスとの対応付けが登録されている。
管理者によってインタリンク接続ノードグループテーブル５９０への登録が行われると、アドレスマッピングテーブル管理部６１０が、その登録情報をインタリンク接続ノードグループテーブル５９０から読み込み、アドレスマッピングテーブルに登録する。従って、初期状態では、インタリンク接続ノードグループテーブル５９０及びアドレスマッピングテーブル６００に登録されている仮想ＭＡＣアドレスとインタリンク接続ノードグループに属する各ＲＰＲノードのＭＡＣアドレスとの対応関係は同一である。インタリンク接続ノードグループテーブル５９０に登録された情報は、管理者によって変更されない限り変更されることはない。一方、アドレスマッピングテーブル６００に登録された情報は、通信システムの運用時における障害の発生あるいは障害からの復旧に応じて、アドレスマッピングテーブル管理部６１０によって変更される。
なお、インタリンク接続ノードグループテーブル５９０に登録される名称は、グループの識別のために通信システムの管理者が任意に設定する情報であり、実際のフレーム転送に用いられるわけではない。そのため、アドレスマッピングテーブル６００に、インタリンク接続ノードグループの名称を登録しなくてよい。
アドレスマッピングテーブル管理部６１０は、アドレスマッピングテーブル６００の内容を更新する。
アドレスマッピングテーブル管理部６１０は、インタリンク接続ノードグループテーブル５９０に登録されている情報の変更に伴ってアドレスマッピングテーブル６００の内容を更新する。例えば、インタリンク接続ノードグループテーブル５９０の仮想ＭＡＣアドレスに対応するインタリンク接続ノードのＭＡＣアドレスが、管理者によって追加登録されたとする。すると、アドレスマッピングテーブル管理部６１０は、インタリンク接続ノードグループテーブル５９０に追加登録されたインタリンク接続ノードのＭＡＣアドレスを、その仮想ＭＡＣアドレスと対応付けてアドレスマッピングテーブル６００に登録する。
その他、アドレスマッピングテーブル管理部６１０は、ＴＤＢ５６０の登録内容の変更、及び、入力ポート５００−３および出力ポート５８０−３の状態の変化に伴い、アドレスマッピングテーブル６００の内容を更新する。
ポート状態監視部６２０は、自ノード（そのポート状態監視部６２０を備えるＲＰＲノード）の入力ポート５００−１〜−３および出力ポート５８０−１〜−３の状態を監視するとともに、その状態に従って自ノードのＴＤＢ５６０を更新する。
また、ポート状態監視部６２０は、自ノードの入力ポート５００−１〜−３および出力ポート５８０−１〜−３の状態を、自ノードのアドレスマッピングテーブル管理部６１０に通知する。
ＭＡＣアドレス管理テーブル６３０は、自ノード（そのＭＡＣアドレス管理テーブル６３０を備えるＲＰＲノード）に対して割り当てられたＭＡＣアドレスを記憶するテーブルである。図８に、ＲＰＲノード１００のＭＡＣアドレス管理テーブル６３０を示す。図８に示すように、ＲＰＲノード１００のＭＡＣアドレス管理テーブル６３０は、自ノード（ＲＰＲノード１００）のＭＡＣアドレスを記憶する。ＭＡＣアドレス管理テーブル６３０へのＭＡＣアドレスの登録は、通信システムの管理者によって管理インタフェースを介して行われる。
ＭＡＣアドレス管理テーブル６３０が記憶するＭＡＣアドレスは、ＲＰＲノードの他の構成要素によって参照される。少なくともＲＰＲスイッチ処理部５３０およびアドレスマッピングテーブル管理部６１０は、ＭＡＣアドレス管理テーブル６３０が記憶するＭＡＣアドレスを参照する。
次に、本実施形態の動作について説明する。まず、正常時の動作について説明する。具体的には、正常時に、端末間でインタリンク４２０，４３０，４４０のいずれか１つを介して、イーサネットフレームを送受信し合うときの動作について説明する。ここでは、ＲＰＲノード１４０の配下の端末（図１において図示せず。）およびＲＰＲノード２４０の配下の端末（図１において図示せず。）とがフレームを送受信し合う場合を例に説明する。
また、以下の説明において、ＲＰＲノード１４０の配下の端末からＲＰＲノード２４０の配下の端末へのフレーム転送は、ＦＤＢ５４０がＭＡＣアドレス学習を行っていない場合の例である。また、その後に説明するＲＰＲノード２４０の配下の端末からＲＰＲノード１４０の配下の端末へのフレーム転送は、ＦＤＢ５４０がＭＡＣアドレス学習を行っている場合の例である。
ＲＰＲノード１４０の配下の端末からＲＰＲノード２４０の配下の端末へのフレーム転送を行う時点で、ＦＤＢ５４０、インタリンク接続ノードグループテーブル５９０、およびアドレスマッピングテーブル６００は、以下の状態になっているものとする。
ＲＰＲネットワーク１０、２０の全てのＲＰＲノードのＦＤＢ５４０に情報が全く登録されていない、すなわち、全てのＲＰＲノードのＦＤＢ５４０において、未だＭＡＣアドレス学習が行われていないものとする。
ＲＰＲネットワーク１０に属する全てのＲＰＲノードのインタリンク接続ノードグループテーブル５９０には、インタリンク接続ノードグループの名称“Ａ”と、そのインタリンク接続ノードグループの仮想ＭＡＣアドレス“ａ”と、そのインタリンク接続ノードグループに属するＲＰＲノード１００，１１０，１６０のＭＡＣアドレスとが対応付けられて登録されているものとする。
また、ＲＰＲネットワーク１０に属する全てのＲＰＲノードのアドレスマッピングテーブル６００には、インタリンク接続ノードグループの仮想ＭＡＣアドレス“ａ”と、そのインタリンク接続ノードグループに属する各ＲＰＲノード１００，１１０，１６０のＭＡＣアドレスとが対応付けられて登録されているものとする。
同様に、ＲＰＲネットワーク２０に属する全てのＲＰＲノードのインタリンク接続ノードグループテーブル５９０には、インタリンク接続ノードグループの名称“Ｂ”と、そのインタリンク接続ノードグループの仮想ＭＡＣアドレス“ｂ”と、そのインタリンク接続ノードグループに属するＲＰＲノード２００，２３０，２７０のＭＡＣアドレスとが対応付けられて登録されているものとする。
また、ＲＰＲネットワーク２０に属する全てのＲＰＲノードのアドレスマッピングテーブル６００には、インタリンク接続ノードグループの仮想ＭＡＣアドレス“ｂ”と、そのインタリンク接続ノードグループに属する各ＲＰＲノード２００，２３０，２７０のＭＡＣアドレスとが対応付けられて登録されているものとする。
ＲＰＲノード１４０配下の端末からＲＰＲノード２４０配下の端末へのイーサネットフレームの転送について説明する。ＲＰＲノード１４０配下の端末が、ＲＰＲノード１４０に対してイーサネットフレームを送信すると、そのイーサネットフレームが、ＲＰＲノード１４０の入力ポート５００−３を介してＲＰＲフレーム生成部５２０へ供給される。
ＲＰＲノード１４０のＲＰＲフレーム生成部５２０は、イーサネットフレームの宛先ＭＡＣアドレスをキーとしてＦＤＢ５４０を検索する。検索に成功した場合には、ＲＰＲフレーム生成部５２０は、イーサネットフレームをカプセル化し、検索結果となるＭＡＣアドレスを宛先ＭＡＣアドレスとしたＲＰＲフレームを生成する。
現時点では、ＲＰＲノード１４０のＦＤＢ５４０には情報が登録されていないため、ＲＰＲノード１４０のＲＰＲフレーム生成部５２０は、イーサネットフレームの宛先ＭＡＣアドレスに対応付けられたＭＡＣアドレスの検索に失敗する。
ＭＡＣアドレスの検索に失敗した場合、ＲＰＲフレーム生成部５２０は、宛先ＭＡＣアドレスとしてブロードキャスト用ＭＡＣアドレスを設定し、かつ、送信元ＭＡＣアドレスに自ノード（ＲＰＲノード１４０）のＭＡＣアドレスを設定し、かつ、ペイロードにイーサネットフレームを格納したＲＰＲフレームを生成する。ＲＰＲフレーム生成部５２０は、自ノードのＭＡＣアドレスについては、ＭＡＣアドレス管理テーブル６３０を参照することによって確認する。
ＲＰＲノード１４０のＲＰＲスイッチ処理部５３０は、ＲＰＲフレーム生成部５２０が生成したＲＰＲフレームの宛先ＭＡＣアドレスがブロードキャスト用ＭＡＣアドレスである場合、ＲＰＲフレームをブロードキャスト送信する。
具体的には、ＲＰＲノード１４０のＲＰＲスイッチ処理部５３０は、ＲＰＲフレームのＴＴＬフィールドに、ＲＰＲネットワーク１０に属するＲＰＲノードのノード数を格納した上で、出力ポート５８０−１または出力ポート５８０−２のいずれか一方から、そのＲＰＲフレームを送信する。
あるいは、ＲＰＲスイッチ処理部５３０は、ＲＰＲフレームのＴＴＬフィールドにＲＰＲネットワーク１０に属するノード数の２分の１の値を格納した上で、出力ポート５８０−１および出力ポート５８０−２の両方からＲＰＲフレームを送信してもよい。
ここでは、前者の方法により、ＲＰＲノード１４０のＲＰＲスイッチ処理部５３０が、ノード数を設定したＲＰＲフレームを、隣接のＲＰＲノード１３０へ繋がる出力ポート５８０−２から送信する場合を例にして説明する。
隣接のＲＰＲノード１３０は、ＲＰＲノード１４０からのＲＰＲフレームを入力ポート５００−１から受信し、それをフレーム解析部５１０−１へ供給する。
ＲＰＲノード１３０のフレーム解析部５１０−１は、受信したＲＰＲフレームがアドレスマッピングテーブル管理部５９０が特殊ＲＰＲフレームか否かを判断し、否の場合は、それをＲＰＲスイッチ処理部５３０へ供給する。一方、受信したフレームが特殊ＲＰＲフレームであれば、それをアドレスマッピングテーブル管理部６１０へ供給する。本例でフレーム解析部５１０−１に入力されたＲＰＲフレームは、イーサネットフレームをカプセル化したＲＰＲフレームであり、特殊ＲＰＲフレームではない。従って、本例では、入力されたＲＰＲフレームがＲＰＲスイッチ処理部５３０へ供給される。
ＲＰＲスイッチ処理部５３０は、供給されたフレーム、すなわち宛先ＭＡＣアドレスにブロードキャスト用ＭＡＣアドレスが設定されたＲＰＲフレームを受けると、以下のように動作する。
ＲＰＲノード１３０のＲＰＲスイッチ処理部５３０は、ＭＡＣアドレス管理テーブル６３０を参照することにより、ＲＰＲフレームの送信元ＭＡＣアドレスが自ノードのＭＡＣアドレスか否かを判定する。その結果、送信元ＭＡＣアドレスが自ノードのＭＡＣアドレスである場合、ループが形成されることによるブロードキャストストームの発生を防止するため、そのＲＰＲフレームを廃棄する。本例では、ＲＰＲフレームの送信元ＭＡＣアドレスは、ＲＰＲノード１４０のＭＡＣアドレスであるので、この廃棄処理は行われない。
また、ＲＰＲフレームの送信元ＭＡＣアドレスが自ノードのＭＡＣアドレスでない場合、ＲＰＲスイッチ処理部５３０は、ＲＰＲフレームに格納されたＴＴＬの値を「１」減算する。そして、減算後のＴＴＬの値が「０」でなければ、そのＲＰＲフレームを次のＲＰＲノードに送信する。減算後のＴＴＬの値が「０」であれば、ＲＰＲスイッチ処理部５３０は、そのＲＰＲフレームを廃棄する。現時点では、ＲＰＲノード１４０で設定されたＴＴＬの値を、ＲＰＲノード１３０のＲＰＲスイッチ処理部５３０が「１」減算したとしても「０」にならない。よって、ＲＰＲノード１３０のＲＰＲスイッチ処理部５３０は、ＲＰＲフレームを自ノードの出力ポート５８０−２からＲＰＲノード１２０へ送信する。
一方、ＲＰＲノード１３０のＲＰＲスイッチ処理部５３０は、ＲＰＲフレームの宛先ＭＡＣアドレスがブロードキャスト用ＭＡＣアドレスである場合、そのＲＰＲフレームのコピーをイーサネットフレーム抽出部５７０へ供給する。
イーサネットフレーム抽出部５７０は、供給されたＲＰＲフレームのペイロードに格納されているイーサネットフレームの送信元ＭＡＣアドレス（ＲＰＲノード１４０配下の端末のＭＡＣアドレス）と、ＲＰＲフレームの送信元ＭＡＣアドレス（ＲＰＲノード１４０のＭＡＣアドレス）との対応関係をＦＤＢ５４０に登録するようにＦＤＢ管理部５５０に要求する。また、イーサネットフレーム抽出部５７０は、ＲＰＲフレームのペイロードに格納されているイーサネットフレームを抽出し、それを自ノードの出力ポート５８０−３から自ノードの配下の端末に送信する。これにより、ブロードキャスト通信のイーサネットフレームが、まずはＲＰＲノード１３０配下の端末へ送られる。
ＲＰＲノード１３０のＦＤＢ管理部５５０は、イーサネットフレーム抽出部５７０からの要求に従って、ＦＤＢ５４０にＭＡＣアドレスの対応関係を登録する。本例では、ＲＰＲノード１４０配下の端末のＭＡＣアドレスと、ＲＰＲノード１４０のＭＡＣアドレスとの対応関係をＦＤＢ５４０に登録する。
なお、仮に、イーサネットフレーム抽出部５７０から要求された対応関係が既にＦＤＢ５４０に登録済みである場合、ＦＤＢ管理部５５０は、イーサネットフレーム抽出部５７０からの要求を無視する、あるいは、既に登録されている情報に上書き処理してもよい。
以降、ＲＰＲネットワーク１０に属し、かつ、インタリンク接続ノードでないＲＰＲノード１２０，１７０，１５０は、上記のＲＰＲノード１３０と同様に動作し、ＲＰＲフレームを次のＲＰＲノードに転送し、かつ、そのＲＰＲフレーム内のイーサネットフレームを各自の配下の端末へ送信する。
ＲＰＲノード１４０からブロードキャスト送信されたＲＰＲフレームは、ＲＰＲノード１３０およびＲＰＲノード１２０を経由して、インタリンク接続ノードであるＲＰＲノード１１０に転送される。
次に、ＲＰＲネットワーク１０のインタリンク接続ノードであるＲＰＲノード１００，１１０，１６０が、ブロードキャスト送信されたＲＰＲフレームを転送する動作について説明する。ここでは、ＲＰＲノード１１０がＲＰＲノード１２０から転送されてきたＲＰＲフレームを受信した場合を例にして説明するが、ＲＰＲノード１００，１６０の動作もＲＰＲノード１１０と同様である。
ＲＰＲノード１１０がＲＰＲフレームを転送する基本動作は、上述のＲＰＲノード１３０のものと同様である。ここで、ＲＰＲノード１４０からブロードキャスト送信されたＲＰＲフレームは、図１における反時計回りに、ＲＰＲノード１３０、１２０、１１０、１００、１７０、１６０、１５０の順番で転送されると、ＲＰＲノード１５０にて、ＴＴＬの値が「０」となる。よって、このＲＰＲフレームは、ＲＰＲノード１５０のＲＰＲスイッチ処理部５３０によって廃棄される。
ＲＰＲフレームを自ノードの配下の端末へ転送する動作に関し、ＲＰＲノード１１０の動作は、上述のＲＰＲノード１３０の動作とは異なる。ＲＰＲノード１１０の配下の端末とは、ＲＰＲネットワーク２０に属するインタリンク接続ノード２７０を指す。ＲＰＲノード１１０は、ブロードキャスト送信されたＲＰＲフレームを受信したとき、その中のイーサネットフレームをインタリンク接続ノード２７０へ送信するか否かを所定の条件に従い決定する。
図９に示すフローチャートを参照して、ＲＰＲノード１１０が配下の端末（２７０）へイーサネットフレームを送信する動作に関し説明する。ＲＰＲノード１１０のＲＰＲスイッチ処理部５３０は、転送されてきたＲＰＲフレームに格納されているイーサネットフレームを出力ポート５８０−３から送信するか否か、すなわち、インタリンク接続ノード２７０へ送信するか否かを後述するアルゴリズムに従って決定する（ステップＳ１）。
ＲＰＲノード１１０は、出力ポート５８０−３からイーサネットフレームを送信すると決定した場合（ステップＳ１：Yes）、ＲＰＲスイッチ処理部５３０が、そのＲＰＲフレームをイーサネットフレーム抽出部５７０に供給する（ステップＳ２）。イーサネットフレーム抽出部５７０は、そのＲＰＲフレームからイーサネットフレームを抽出し、また、ＦＤＢ管理部５５０に対し、イーサネットフレームの送信元ＭＡＣアドレスと、ＲＰＲフレームの送信元ＭＡＣアドレスとの対応関係をＦＤＢ５４０に登録するよう指示する（ステップＳ３）。イーサネットフレーム抽出部５７０は、抽出したイーサネットフレームを自ノードの出力ポート５８０−３からインタリンク接続ノード２７０に送信する（ステップＳ４）。
一方、ＲＰＲノード１１０の出力ポート５８０−３からイーサネットフレームを送信しないと決定した場合（ステップＳ１：No）、ＲＰＲスイッチ処理部５３０は、ＲＰＲフレームをイーサネットフレーム抽出部５７０へ供給せず、また、ＭＡＣアドレス学習を行わない。なお、ＭＡＣアドレス学習は行ってもよいが、配下の端末へのイーサネットフレームの送信は行わない。
また、配下の端末に対しイーサネットフレームを送信しない場合であっても、次ホップに対するＲＰＲフレームの転送は、ＲＰＲノード１３０の動作と同様の動作で実行する。
イーサネットフレームをインタリンク接続ノード２７０へ送信するか否かの判定に関するアルゴリズムとしては、そのイーサネットフレームを、同一のインタリンク接続ノードグループに属するインタリンク接続ノードのうちの何れか１つから送信されるよう制御するものを採用する。前述したように、ＲＰＲフレームは、ＲＰＲネットワーク１０内で転送されることから、それに含まれるイーサネットフレームが複数のインタリンク接続ノードに届けられる。しかしながら、複数のインタリンク接続ノードのそれぞれがイーサネットフレームを送信すると、同一の宛先の複数のイーサネットフレームがＲＰＲネットワーク２０へ送られる。その結果、宛先の端末に同一内容のイーサネットフレームが複数回届けられることになる。よって、ブロードキャスト送信されたイーサネットフレームが、ＲＰＲネットワーク１０からＲＰＲネットワーク２０へ送信される場合、そのイーサネットフレームをインタリンク接続ノード（１００、１１０、１６０）の何れか１つから送信する。
そのようなアルゴリズムとして、例えば、フレームのヘッダまたはフレームのペイロード、あるいは、その双方の情報をパラメータとし、そのパラメータに応じて配下の端末にイーサネットフレームを送信するか否かを決定するというアルゴリズムを使用する。また、上記のようなパラメータを用いて行った所定の計算の結果に応じて、配下の端末にイーサネットフレームを送信するか否かを決定するというアルゴリズムであってもよい。ここで述べたフレームとは、ＲＰＲフレームであってもよいし、ＲＰＲフレーム内にカプセル化されているイーサネットフレームであってもよい。
上記のようなアルゴリズムで使用するパラメータとしては、例えば、イーサネットフレームの宛先ＭＡＣアドレス、送信元ＭＡＣアドレス、プライオリティ、ＶＬＡＮ ＩＤ、イーサタイプ、フレームのペイロードに格納されたＩＰパケットの宛先ＩＰアドレス、送信元ＩＰアドレス、さらに、そのＩＰパケットに格納されたＴＣＰパケットの宛先ＴＣＰポート番号、送信元ＴＣＰポート番号等が挙げられる。ここに挙げた各パラメータは例示であり、フレームに含まれる他の情報をパラメータとしてもよい。
具体的な例を挙げると、インタリンク接続ノードグループに属する各ＲＰＲノード（１００、１１０、１６０）に対し、イーサネットフレームを送信することを示すパラメータ値が重複しないように定めておけばよい。そして、受信したフレームのパラメータ値が、定められたパラメータ値に該当するならば、配下の端末にイーサネットフレームを送信すると決定すればよい。例えば、配下に送信すべきイーサネットフレームとして、ＲＰＲノード１００に適用するアルゴリズムには、ＶＬＡＮ_ＩＤが１〜１０００であるイーサネットフレームを設定し、ＲＰＲノード１１０のアルゴリズムには、ＶＬＡＮ_ＩＤが１００１〜２０００であるイーサネットフレームを設定し、ＲＰＲノード１６０は、ＶＬＡＮ_ＩＤが１〜２０００以外のイーサネットフレームを設定する。このアルゴリズムに従って、インタリンク接続ノードである各ＲＰＲノード１００，１１０，１６０が判定を行うことにより、同一宛先のイーサネットフレームが複数のノードから送信されることを防止できる。また、イーサネットフレームのトラフィックをインタリンク４２０〜４４０に分散することができる。
また、障害の発生により、いずれかのインタリンク接続ノードが配下の端末にイーサネットフレームを送信できない状態となったときには、そのインタリンク接続ノードに定められたパラメータの値を、他のインタリンク接続ノードが引き継ぐようにしてもよい。例えば、配下の端末にイーサネットフレームを送信できない状態となったインタリンク接続ノードが、自ノードに定められたパラメータの値を他のイーサネットフレームに指示する特殊ＲＰＲフレームを送信し、その特殊ＲＰＲフレームを受信したインタリンク接続ノードが、そのパラメータ値を自ノードに設定する。
また、別の例を挙げると、インタリンク接続ノードグループに属するインタリンク接続ノードのうちの何れか一つのみが、イーサネットフレームを配下の端末に送信するように定めてもよい。この場合、各インタリンク接続ノードは、自ノードが配下の端末にイーサネットフレームを送信すべきか否かの情報を予め登録しておく。そして、各インタリンク接続ノードは、ブロードキャスト送信されたＲＰＲフレームを受信したとき、予め登録した情報に基づいて、イーサネットフレームの送信の可否を決定する。また、イーサネットフレームを配下の端末に送信すべきインタリンク接続ノードに障害が発生したときには、配下の端末へのイーサネットフレーム送信を指示する特殊ＲＰＲフレームを、他のインタリンク接続ノードに送信する。そして、それ以降、そのインタリンク接続ノードが配下の端末へのイーサネットフレーム送信を行う。例えば、配下の端末へイーサネットフレームを送信すべきインタリンク接続ノードをＲＰＲノード１００としたケースにおいて、インタリンク４２０に障害が発生したとき、隣接のインタリンク接続ノードであるＲＰＲノード１１０をＲＰＲノード１００の代替とすればよい。この場合、ＲＰＲノード１００は、インタリンク４２０の障害を検出したとき、ＲＰＲフレーム中のイーサネットフレームを配下の端末に送信するよう指示する特殊ＲＰＲフレームを、ＲＰＲノード１１０に送信する。そして、この特殊ＲＰＲフレームを受信したＲＰＲノード１１０が、ブロードキャスト送信されたＲＰＲフレームを受信したときに、配下の端末（２００）にイーサネットフレームを送信する。
このように、ＲＰＲノード１００，１１０，１６０のいずれか一つが、ブロードキャスト送信されたＲＰＲフレームからイーサネットフレームを抽出して、そのイーサネットフレームをインタリンク４２０，４３０，４４０のいずれかを介して、ＲＰＲネットワーク２０に転送する。以下、ＲＰＲネットワーク１０からＲＰＲネットワーク２０にイーサネットフレームが転送されてから、そのイーサネットフレームがＲＰＲノード２４０の配下の端末に転送されるまでの動作について説明する。ここでは、ＲＰＲノード１１０が、ＲＰＲフレームに格納されたイーサネットフレームを、インタリンク４３０を介してＲＰＲノード２７０に転送した場合を例にして説明する。
ＲＰＲノード２７０は、ＲＰＲノード１１０からのイーサネットフレームを入力ポート５００−３で受信すると、それをＲＰＲフレーム生成部５２０に供給する。
ＲＰＲフレーム生成部５２０は、イーサネットフレームの宛先ＭＡＣアドレスをキーとしてＦＤＢ５４０を検索し、イーサネットフレームの宛先ＭＡＣアドレスに対応付けられたＭＡＣアドレスを読み込む。仮に、検索に成功した場合は、イーサネットフレームをカプセル化し、読み込んだＭＡＣアドレスを宛先ＭＡＣアドレスに設定することにより、ＲＰＲフレームを生成する。
現時点では、ＲＰＲノード２７０のＦＤＢ５４０には情報が全く登録されていないため、ＲＰＲノード２７０のＲＰＲフレーム生成部５２０は、上記検索に失敗する。
ＭＡＣアドレスの取得に失敗したことにより、ＲＰＲノード２７０のＲＰＲフレーム生成部５２０は、宛先ＭＡＣアドレスにブロードキャスト用ＭＡＣアドレスを設定し、かつ、送信元ＭＡＣアドレスにＲＰＲノード２７０の属するインタリンク接続ノードグループ“Ｂ”に割り当てられたＭＡＣアドレス“ｂ”を設定し、かつ、ペイロードにイーサネットフレームを格納することにより、ＲＰＲフレームを生成する。ＲＰＲフレーム生成部５２０は、アドレスマッピングテーブル６００を参照して、自ノードのＭＡＣアドレスに対応付けられた仮想ＭＡＣアドレス“ｂ”を送信元ＭＡＣアドレスとして用いる。ＲＰＲフレーム生成部５２０は、生成したＲＰＲフレームをＲＰＲスイッチ処理部５３０に供給する。
なお、送信元ＭＡＣアドレスの設定に関し、既述したＲＰＲノード１４０では自ノードのＭＡＣアドレスが設定されたのに対し、ＲＰＲノード２７０では、自ノードの属するインタリンク接続ノードグループの仮想ＭＡＣアドレス（“ｂ”）を送信元ＭＡＣアドレスが設定される。これは、ＲＰＲノード１４０はインタリンク接続ノードグループに属さないノードであるのに対し、ＲＰＲノード２７０は、インタリンク接続ノードグループに属するノードであることに基づく。ＲＰＲフレーム生成部５２０は、ＲＰＲフレーム生成時に、自ノードのＭＡＣアドレスがアドレスマッピングテーブル６００に登録されているか否かを判定することにより、自ノードがインタリンク接続ノードグループに属するか否かを判定する。
ＲＰＲノード２７０のＲＰＲスイッチ処理部５３０は、送信すべきＲＰＲフレームの宛先ＭＡＣアドレスがブロードキャスト用ＭＡＣアドレスである場合、そのＲＰＲフレームをブロードキャスト送信する。この動作は、既に説明したＲＰＲノード１４０のＲＰＲスイッチ処理部５３０によるブロードキャスト送信と同様である。
ＲＰＲノード２７０がＲＰＲフレームをブロードキャスト送信して以降、そのフレームをＲＰＲネットワーク２０に属する各ＲＰＲノードが転送する動作について説明する。以下、インタリンク接続ノードグループ“Ｂ”に属するＲＰＲノードの場合と、そのグループに属さないＲＰＲノードの場合とに分けて説明する。
インタリンク接続ノードグループ“Ｂ”に属するＲＰＲノードは、このグループに属する他のＲＰＲノードが送信元となってＲＰＲネットワーク２０にブロードキャスト送信したＲＰＲフレームを受信した場合、以下のように動作する。このとき受信するＲＰＲフレームとは、すなわち、上記グループ“Ｂ”の仮想ＭＡＣアドレス“ｂ”が送信元ＭＡＣアドレスとして設定され、かつ、ブロードキャスト用ＭＡＣアドレスが宛先ＭＡＣアドレスとして設定されているＲＰＲフレームを指す。フレーム解析部５１０−１（またはフレーム解析部５１０−２）は、入力された上記ＲＰＲフレームをＲＰＲスイッチ処理部５３０に供給する。ＲＰＲスイッチ処理部５３０は、ＲＰＲフレームに格納されたＴＴＬの値を「１」減算し、減算後のＴＴＬの値が「０」でなければ、そのＲＰＲフレームを次のＲＰＲノードに送信する。次のノードとは、ＲＰＲフレームを受信したポートとは反対側に接続されているＲＰＲノードである。一方、減算後のＴＴＬの値が「０」であれば、ＲＰＲスイッチ処理部５３０は、そのＲＰＲフレームを廃棄しイーサネットフレーム抽出部５７０に出力しない。従って、インタリンク接続ノードグループ“Ｂ”のＲＰＲノードに送信されたＲＰＲフレーム内のイーサネットフレームは、そのノードの配下の端末に送信されない。また、ＲＰＲフレームの送信元ＭＡＣアドレスとして設定されている仮想ＭＡＣアドレス（“ｂ”）と、そのＲＰＲフレーム内のイーサネットフレームの送信元ＭＡＣアドレス（ＲＰＲノード１４０の配下の端末のＭＡＣアドレス）との対応関係をＦＤＢ５４０に登録することも行われない。
このような、インタリンク接続ノードグループ“Ｂ”に属するＲＰＲノードの動作により、ＲＰＲネットワーク２０に転送されたイーサネットフレームが、再びＲＰＲネットワーク１０に転送されることを防止することができる。従って、ブロードキャストストームによってネットワークが不安定になることを回避することができる。
インタリンク接続ノードグループ“Ｂ” に属するＲＰＲノードが送信元となってＲＰＲネットワーク２０にブロードキャスト送信したＲＰＲフレームを、このグループ“Ｂ”に属さないＲＰＲノードが転送する動作は、前述したＲＰＲネットワーク１０におけるＲＰＲノード１３０のそれと基本的には同様である。ただし、インタリンク接続ノードグループ“Ｂ”の場合、ブロードキャスト送信されたＲＰＲフレームの送信元ＭＡＣアドレスには、インタリンク接続ノードグループ“Ｂ”の仮想ＭＡＣアドレス（“ｂ”）が設定されている。従って、インタリンク接続ノードグループ“Ｂ”のノードのＦＤＢ管理部５５０は、ＦＤＢ５４０にＭＡＣアドレスの対応関係を登録する際、この仮想ＭＡＣアドレス（“ｂ”）と、端末（ＲＰＲノード１４０配下の端末）のＭＡＣアドレスとの対応関係を登録する。このように、仮想ＭＡＣアドレスと端末のＭＡＣアドレスとの対応関係を登録する点が、上述のインタリンク接続ノードグループ“Ａ”の場合と異なる。
ＲＰＲネットワーク２０に属する各ＲＰＲノードによる上記の転送動作により、ＲＰＲノード２４０が、ブロードキャスト送信されたＲＰＲフレームを受信する。そして、ＲＰＲノード２４０は、自ノード配下の端末に、ＲＰＲフレームに格納されたイーサネットフレームを送信する。この結果、ＲＰＲネットワーク１０のＲＰＲノード１４０配下の端末から送信されたイーサネットフレームが、ＲＰＲネットワーク２０のＲＰＲノード２４０配下の端末に転送される。
以降では、上述のようにＲＰＲノード１４０配下の端末からＲＰＲノード２４０配下の端末へイーサネットフレームが転送されたことを前提として、ＲＰＲノード２４０配下の端末からＲＰＲノード１４０配下の端末にイーサネットフレームを転送（返信）する場合の動作について説明する。
なお、上述の転送動作により、現時点では、ＲＰＲネットワーク１０に属する全てのＲＰＲノードのＦＤＢ５４０に、ＲＰＲノード１４０配下の端末のＭＡＣアドレスとＲＰＲノード１４０のＭＡＣアドレスとの対応関係が登録されている。また、ＲＰＲネットワーク２０に属し、かつ、インタリンク接続ノードでないＲＰＲノードのＦＤＢ５４０には、ＲＰＲノード１４０配下の端末のＭＡＣアドレスと、インタリンク接続ノードグループ“Ｂ”の仮想ＭＡＣアドレス“ｂ”との対応関係が登録されている。
図１０に、ＲＰＲノード１４０の配下の端末を宛先とするイーサネットフレームを受信したＲＰＲノード２４０の処理手順を示す。
ＲＰＲノード２４０の配下の端末が、ＲＰＲノード２４０に対してイーサネットフレームを送信すると、ＲＰＲノード２４０の入力ポート５００−３はそのイーサネットフレームを受信する（ステップＳ１１）。
ＲＰＲノード２４０のＲＰＲフレーム生成部５２０は、受信したイーサネットフレームを格納するＲＰＲフレームの宛先ＭＡＣアドレスとなるＭＡＣアドレスを決定する（ステップＳ１２）。アドレスの決定にあたり、フレーム生成部５２０は、受信したイーサネットフレームの宛先ＭＡＣアドレスをキーとしてＦＤＢ５４０を検索し、そのキーに対応付けられたＭＡＣアドレスを読み込む。
フレーム生成部５２０が検索に失敗した場合には、前述のＲＰＲノード１４０と同様に、ブロードキャスト用ＭＡＣアドレスが宛先ＭＡＣアドレスとして設定される。本例では、ＲＰＲノード１４０配下の端末のＭＡＣアドレスと、インタリンク接続ノードグループ“Ｂ”の仮想ＭＡＣアドレス“ｂ”とが対応付けが既にＦＤＢ５４０に記憶されている。従って、ＲＰＲフレーム生成部５２０は、検索に成功し、インタリンク接続ノードグループ“Ｂ”の仮想ＭＡＣアドレス“ｂ”をＦＤＢ５４０から読み込む。
ＲＰＲノード２４０のＲＰＲフレーム生成部５２０は、アドレスマッピングテーブル６００を参照することにより、インタリンク接続ノードグループ“Ｂ”の仮想ＭＡＣアドレス“ｂ”に対応付けられている各ＭＡＣアドレスを読み込む。本例では、ＲＰＲネットワーク２０のインタリンク接続ノードであるＲＰＲノード２００，２３０，２７０のＭＡＣアドレスが読み込まれる。そして、ＲＰＲフレーム生成部５２０は、後述するアルゴリズムに従って、読み込んだＭＡＣアドレスの中から１つのＭＡＣアドレスを選択し、それをＲＰＲフレームの宛先ＭＡＣアドレスとして決定する。
次に、ＲＰＲノード２４０のＲＰＲフレーム生成部５２０は、イーサネットフレームをカプセル化してＲＰＲフレームを生成する（ステップＳ１３）。すなわち、決定したＭＡＣアドレスを宛先ＭＡＣアドレスに設定し、かつ、送信元ＭＡＣアドレスに自ノードのＭＡＣアドレスを設定し、かつ、ペイロードに自ノード配下の端末より受信したイーサネットフレームを格納したＲＰＲフレームを生成する。
ＲＰＲノード２４０のＲＰＲスイッチ処理部５３０は、生成されたＲＰＲフレームを、出力ポート５８０−１または出力ポート５８０−２のいずれか一方から送信する（ステップＳ１４）。このとき、ＲＰＲフレームのＴＴＬフィールドには、実際にＲＰＲフレームを出力する出力ポートから、宛先となるＲＰＲノードまでのホップ数が格納される。なお、ここで生成されたＲＰＲフレームの宛先ＭＡＣアドレスには、ＲＰＲノード２００，２３０，２７０のＭＡＣアドレスのいずれか１つが設定されていることから、ＲＰＲノード２４０からのＲＰＲフレームの送信は、ユニキャスト送信となる。
ここで、ＲＰＲフレーム生成部５２０が仮想ＭＡＣアドレスに対応する各ＭＡＣアドレスの中から１つのＭＡＣアドレスを選択する（図１０：ステップＳ１２）ためのアルゴリズムは、例えば、ラウンドロビンや重み付けラウンドロビンを採用することができる。
また、例えば、イーサネットフレームのヘッダまたはペイロード、あるいはその双方の情報をパラメータとし、そのパラメータに応じて、複数のＭＡＣアドレスから１つのＭＡＣアドレスを選択してもよい。また、パラメータを用いて行った所定の計算の結果に応じて、ＭＡＣアドレスを選択してもよい。
このようなアルゴリズムで使用するパラメータとしては、例えば、イーサネットフレームの宛先ＭＡＣアドレス、送信元ＭＡＣアドレス、プライオリティ、ＶＬＡＮ_ＩＤ、イーサタイプ、フレームのペイロードに格納されたＩＰパケットの宛先ＩＰアドレス、送信元ＩＰアドレスを適用することができる。また、そのＩＰパケットに格納されたＴＣＰパケットの宛先ＴＣＰポート番号、送信元ＴＣＰポート番号等であってもよい。ここに挙げた各パラメータは例示であり、フレームに含まれる他の情報をパラメータとしてもよい。
なお、インタリンク接続ノードが配下の端末にイーサネットフレームを転送できない状態になったことを、インタリンク接続ノードグループに属さないＲＰＲノードが検出したとする。この場合、インタリンク接続ノードグループに属さないＲＰＲノードは、パラメータによって定まるＭＡＣアドレスが、イーサネットフレームを転送可能なＲＰＲノードのＭＡＣアドレスのみになるように、パラメータとＭＡＣアドレスとの対応関係を変更すればよい。また、ラウンドロビンや重み付けラウンドロビンを採用する場合には、配下の端末にイーサネットフレームを転送可能なＲＰＲノードのＭＡＣアドレスのみを選択対象とすればよい。
以降では、ＲＰＲノード２４０のＲＰＲフレーム生成部５２０が、宛先ＭＡＣアドレスとしてＲＰＲノード２００のＭＡＣアドレスを選択した場合を例として説明する。
ＲＰＲノード２４０のＲＰＲフレーム生成部５２０は、宛先ＭＡＣアドレスにＲＰＲノード２００のＭＡＣアドレスを設定し、かつ、送信元ＭＡＣアドレスに自ノードのＭＡＣアドレスを設定し、かつ、ペイロードにイーサネットフレームを格納したＲＰＲフレームを生成する（ステップＳ１３）。
ＲＰＲノード２４０のＲＰＲスイッチ処理部５３０は、生成されたＲＰＲフレームを、出力ポート５８０−１または出力ポート５８０−２のいずれか一方から隣接のＲＰＲノード２５０へ送信する（ステップＳ１４）。このとき、ＲＰＲフレームのＴＴＬフィールドには、実際にＲＰＲフレームを出力する出力ポートからＲＰＲノード２００までのホップ数が設定される。ここでは、出力ポート５８０−１からＲＰＲフレームが送信される場合を例にして説明する。
ＲＰＲノード２５０は、入力ポート５００−２により、ＲＰＲノード２４０からのＲＰＲフレームを受信する。入力ポート５００−２が受信したＲＰＲフレームは、ＲＰＲノード２５０のフレーム解析部５１０−２に入力される。
ＲＰＲノード２５０のフレーム解析部５１０−２は、入力されたＲＰＲフレームが、アドレスマッピングテーブル管理部６１０が使用する特殊ＲＰＲフレームでなければ、それをＲＰＲスイッチ処理部５３０に供給する。また、仮に、特殊ＲＰＲフレームであれば、それをアドレスマッピングテーブル管理部６１０に供給する。本例でフレーム解析部５１０−２に入力されたＲＰＲフレームは、イーサネットフレームをカプセル化したＲＰＲフレームであり、特殊ＲＰＲフレームではない。従って、フレーム解析部５１０−２は、入力されたＲＰＲフレームをＲＰＲスイッチ処理部５３０に供給する。
ＲＰＲノード２５０のＲＰＲスイッチ処理部５３０は、ＲＰＲフレームを供給されると、以下のように動作する。
ＲＰＲスイッチ処理部５３０は、そのＲＰＲフレームの送信元ＭＡＣアドレスが自ノードのＭＡＣアドレスである場合、ループの形成によるブロードキャストストームの発生を防止するため、受信したＲＰＲフレームを廃棄する。
また、ＲＰＲスイッチ処理部５３０は、そのＲＰＲフレームが自ノードを宛先とするＲＰＲフレームであるか否かを判定する。すなわち、ＲＰＲスイッチ処理部５３０は、受信したＲＰＲフレームにおける宛先ＭＡＣアドレスと、自ノードのＭＡＣアドレスとが一致するか否かを判定する。
判定の結果、受信したＲＰＲフレームの宛先が自ノード（２５０）ではない場合、ＲＰＲスイッチ処理部５３０は、ＲＰＲフレームに格納されているＴＴＬの値を「１」減算する。そして、減算結果が「０」でなければ、そのＲＰＲフレームを出力ポート５８０−１から次のＲＰＲノード（２６０）に送信する。また、ＴＴＬから「１」減算した結果が「０」であれば、ＲＰＲスイッチ処理部５３０は、そのＲＰＲフレームを廃棄する。
一方、受信したＲＰＲフレームの宛先が自ノード（２５０）である場合、ＲＰＲスイッチ処理部５３０は、そのＲＰＲフレームをイーサネットフレーム抽出部５７０に供給する。イーサネットフレーム抽出部５７０は、そのＲＰＲフレーム内のイーサネットフレームの送信元ＭＡＣアドレス（ＲＰＲノード２４０配下の端末のＭＡＣアドレス）と、そのＲＰＲフレームの送信元ＭＡＣアドレス（ＲＰＲノード２４０のＭＡＣアドレス）の対応関係をＦＤＢ５４０に登録するようＦＤＢ管理部５５０に要求する。また、イーサネットフレーム抽出部５７０は、ＲＰＲフレームからイーサネットフレームを抽出し、出力ポート５８０−３から自ノード配下の端末にそのイーサネットフレームを送信する。また、ＦＤＢ管理部５５０は、イーサネットフレーム抽出部５７０の要求に従って、ＦＤＢ５４０に上記のＭＡＣアドレスの対応関係を登録する。
本例では、ＲＰＲノード２４０がユニキャスト送信したＲＰＲフレームにおける宛先ＭＡＣアドレスは、ＲＰＲノード２００のＭＡＣアドレスであり、ＲＰＲノード２５０のＭＡＣアドレスと一致しない。従って、ＲＰＲノード２５０のＲＰＲスイッチ処理部５３０は、ＲＰＲフレームに格納されているＴＴＬの値を「１」減算する。また、その減算結果は「０」ではないので、ＲＰＲスイッチ処理部５３０は、ＴＴＬ減算後のＲＰＲフレームを出力ポート５８０−１から次のＲＰＲノード（２６０）に送信する。
ＲＰＲノード２４０からユニキャスト送信されたＲＰＲフレームがＲＰＲノード２００に転送されるまでの、各ＲＰＲノードの動作は、上述のＲＰＲノード２５０の動作と同様である。
ＲＰＲノード２００の入力ポート５００−２を介してフレーム解析５１０−２にＲＰＲフレームが入力されると、ＲＰＲノード２００のフレーム解析部５１０−２は、そのＲＰＲフレームをＲＰＲスイッチ処理部５３０に供給する。ＲＰＲスイッチ処理部５３０は、受信したＲＰＲフレームの宛先ＭＡＣアドレスと、自ノードのＭＡＣアドレスとが一致するので、そのＲＰＲフレームをイーサネットフレーム抽出部５７０に供給する。イーサネットフレーム抽出部５７０は、ＲＰＲフレーム内のイーサネットフレームの送信元ＭＡＣアドレスと、そのＲＰＲフレームの送信元ＭＡＣアドレスとの対応関係をＦＤＢ５４０に登録するようＦＤＢ管理部５５０に要求する。また、イーサネットフレーム抽出部５７０は、ＲＰＲフレームからイーサネットフレームを抽出し、それを出力ポート５８０−３から自ノード配下の端末へ送信する。ここで、ＲＰＲノード２００の配下の端末とは、ＲＰＲネットワーク１０のＲＰＲノード１００である。また、ＲＰＲノード２００のＦＤＢ管理部５５０は、イーサネットフレーム抽出部５７０の要求に従って、自ノードのＦＤＢ５４０にＭＡＣアドレスの対応関係を登録する。この結果、ＲＰＲノード２４０が送信したイーサネットフレームがＲＰＲノード１００によって受信される。
また、ＲＰＲノード２４０が送信したイーサネットフレームがＲＰＲノード１００によって受信されるまでの動作は、上述のような動作ではなく、以下のような動作であってもよい。
ＲＰＲノード２４０配下の端末が、ＲＰＲノード１４０配下の端末を宛先とするイーサネットフレームをＲＰＲノード２４０に送信する。すると、ＲＰＲノード２４０のＲＰＲフレーム生成部５２０に、入力ポート５００−３を介して、そのイーサネットフレームが入力される。ＲＰＲノード２４０のＲＰＲフレーム生成部５２０は、自ノードの配下の端末から受信したイーサネットフレームの宛先ＭＡＣアドレス（ＲＰＲノード１４０配下の端末のＭＡＣアドレス）をキーとしてＦＤＢ５４０を検索する。ＦＤＢ５４０では、ＲＰＲノード１４０配下の端末のＭＡＣアドレスと、インタリンク接続ノードグループ“Ｂ”の仮想ＭＡＣアドレス“ｂ”とが対応付けられている。従って、ＲＰＲノード２４０のＲＰＲフレーム生成部５２０は、検索の結果、仮想ＭＡＣアドレス“ｂ”をＦＤＢ５４０から読み込む。
そして、ＲＰＲノード２４０のＲＰＲフレーム生成部５２０は、検索結果である仮想ＭＡＣアドレス“ｂ”を宛先ＭＡＣアドレスに設定し、かつ、送信元ＭＡＣアドレスに自ノードのＭＡＣアドレスを設定し、かつ、ペイロードに自ノード配下の端末より受信したイーサネットフレームを格納したＲＰＲフレームを生成する。
ＲＰＲノード２４０のＲＰＲスイッチ処理部５３０は、生成されたＲＰＲフレームのＴＴＬフィールドに、自ノード（２４０）から各インタリンク接続ノードまでのホップ数の最大値を格納する。そして、ＲＰＲノード２４０のＲＰＲスイッチ処理部５３０は、自ノードの出力ポート５８０−１または出力ポート５８０−２のいずれか一方から、そのＲＰＲフレームを送信する。この場合、ＲＰＲフレームの宛先アドレスには、インタリンク接続ノードグループに割り当てられた仮想ＭＡＣアドレスが格納されている。従って、この動作では、ＲＰＲノード２４０からのＲＰＲフレームの送信は、グループのインタリンク接続ノードを宛先としたマルチキャスト送信となる。また、ＴＴＬフィールドには、自ノードからインタリンク接続ノードまでのホップ数の最大値に替えて、自ノードが属するＲＰＲネットワーク２０のノード数を設定してもよい。
次に、ＲＰＲノード２４０のＲＰＲスイッチ処理部５３０が、出力ポート５８０−１からＲＰＲノードにＲＰＲフレームを送信する場合を説明する。
インタリンク接続ノードグループに属さない各ＲＰＲノードの動作は、前述のＲＰＲノード２５０の動作と同様である。従って、ＲＰＲノード２４０の出力ポート５８０−１から送信されたＲＰＲフレームは、ＲＰＲノード２５０，２６０を経由して、ＲＰＲノード２７０に転送される。ＲＰＲノード２７０のフレーム解析部５１０−２には、入力ポート５００−２を介してＲＰＲフレームが入力される。
ＲＰＲノード２７０のフレーム解析部５１０−２は、ＲＰＲフレームが特殊ＲＰＲフレームでなければ、そのＲＰＲフレームをＲＰＲスイッチ処理部５３０に供給する。本例では、フレーム解析部５１０−２に入力されたＲＰＲフレームは、イーサネットフレームをカプセル化したＲＰＲフレームであり、特殊ＲＰＲフレームではないので、フレーム解析部５１０−２は、ＲＰＲフレームをＲＰＲスイッチ処理部５３０に供給する。なお、特殊ＲＰＲフレームである場合、既に説明したように、その特殊ＲＰＲフレームはアドレスマッピングテーブル管理部６１０に供給される。
インタリンク接続ノードグループに属するＲＰＲノード２７０のＲＰＲスイッチ処理部５３０は、ＲＰＲフレームの送信元ＭＡＣアドレスが自ノードのＭＡＣアドレスである場合、ループの構成によるブロードキャストストームの発生を防止するため、受信したＲＰＲフレームを廃棄する。この動作は、インタリンク接続ノードグループに属さないＲＰＲノードと同様である。
また、ＲＰＲノード２７０のＲＰＲスイッチ処理部５３０は、ＲＰＲフレームの宛先ＭＡＣアドレスが自ノードの属するインタリンク接続ノードグループの仮想ＭＡＣアドレスでない場合、ＲＰＲフレームのＴＴＬの値を「１」減算する。減算後のＴＴＬの値が「０」でなければ、ＲＰＲフレームを次のＲＰＲノードに転送する。減算後のＴＴＬの値が「０」であれば、そのＲＰＲフレームを廃棄する。
また、インタリンク接続ノードのいずれか１つが、マルチキャスト送信されたＲＰＲフレーム内のイーサネットフレームを配下の端末、すなわち他のＲＰＲネットワークに属するＲＰＲノードに送信する。図１１は、インタリンク接続ノードグループに属するインタリンク接続ノードが、マルチキャスト送信されたＲＰＲフレームを受信した場合のフローチャートである。ここでは、そのインタリンク接続ノードとして、ＲＰＲノード２７０を例にして説明する。
ＲＰＲノード２７０のＲＰＲスイッチ処理部５３０は、マルチキャスト送信されたＲＰＲフレームの宛先ＭＡＣアドレスが自ノードの属するインタリンク接続ノードグループの仮想ＭＡＣアドレス（“ｂ”）である場合、後述するアルゴリズムに従って、そのＲＰＲフレーム内のイーサネットフレームを出力ポート５８０−３から送信するか否かを決定する（ステップＳ２１）。
ＲＰＲノード２７０の出力ポート５８０−３から配下の端末（ＲＰＲノード１１０）にイーサネットフレームを送信すると決定した場合（ステップＳ２１：YES）、ＲＰＲノード２７０のＲＰＲスイッチ処理部５３０は、ＲＰＲフレームをイーサネットフレーム抽出部５７０に供給する（ステップＳ２２）。これを受けたイーサネットフレーム抽出部５７０は、ＲＰＲフレームに格納されているイーサネットフレームの送信元ＭＡＣアドレスと、ＲＰＲフレームの送信元ＭＡＣアドレスとの対応関係をＦＤＢ５４０に登録するようＦＤＢ管理部５５０に要求する。ＦＤＢ管理部５５０は、ＦＤＢ５４０にアドレスの対応関係を登録する。また、イーサネットフレーム抽出部５７０は、ＲＰＲフレームからイーサネットフレームを抽出し（ステップＳ２３）、そのイーサネットフレームを出力ポート５８０−３から自ノードの配下の端末に送信する（ステップＳ２４）。
また、ＲＰＲノード２７０の出力ポート５８０−３から配下の端末（ＲＰＲノード１１０）にイーサネットフレームを送信しないと決定した場合（ステップＳ２１：NO）、ＲＰＲノード２７０のＲＰＲスイッチ処理部５３０は、ＲＰＲフレームに格納されたＴＴＬの値を「１」減算する（ステップＳ２５）。そして、減算後のＴＴＬの値が「０」でなければ（ステップＳ２６：YES）、ＲＰＲフレームを出力ポート５８０−１から次のＲＰＲノード（２００）に送信する（ステップＳ２７）。一方、減算後のＴＴＬの値が「０」であれば、ＲＰＲスイッチ処理部５３０は、そのＲＰＲフレームを廃棄する（ステップＳ２８）。
上記動作はインタリンク接続ノード２７０のものであったが、マルチキャスト送信されたＲＰＲフレームを他のインタリンク接続ノード（２００，２２０）が受信した場合の動作も同様である。
マルチキャスト送信されたＲＰＲフレーム内のイーサネットフレームを配下の端末に送信するか否かを決定するアルゴリズムとしては、同一のインタリンク接続ノードグループに属するＲＰＲノードのうちいずれか一つのＲＰＲノードのみが配下の端末にイーサネットフレームを送信すると決定するアルゴリズムを採用する。
そのようなアルゴリズムとして、例えば、フレームのヘッダまたはペイロード、あるいはその双方の情報をパラメータとし、そのパラメータに応じて、配下の端末にイーサネットフレームを送信するか否かを決定するというアルゴリズムを使用することができる。また、上記のようなパラメータを用いて行った所定の計算の結果に応じて、配下の端末にイーサネットフレームを送信するか否かを決定するというアルゴリズムを使用してもよい。ここで述べたフレームとは、ＲＰＲフレームであってもよいし、ＲＰＲフレーム内にカプセル化されているイーサネットフレームであってもよい。
このようなアルゴリズムで使用できるパラメータとしては、例えば、イーサネットフレームの宛先ＭＡＣアドレス、送信元ＭＡＣアドレス、プライオリティ、ＶＬＡＮ_ＩＤ、イーサタイプ、フレームのペイロードに格納されたＩＰパケットの宛先ＩＰアドレス、送信元ＩＰアドレスを用いることができる。また、そのＩＰパケットに格納されたＴＣＰパケットの宛先ＴＣＰポート番号、送信元ＴＣＰポート番号等であってもよい。ここに挙げた各パラメータは例示であり、フレームに含まれる他の情報をパラメータとしてもよい。
具体的な例を挙げると、配下の端末へイーサネットフレームを送信することを示すパラメータ値が、インタリンク接続ノードグループに属するＲＰＲノード間で重複しないように定めておけばよい。そして、受信したフレームのパラメータ値が、定められたパラメータ値に該当するならば、配下の端末にイーサネットフレームを送信すると決定する。例えば、パラメータ値をイーサネットフレームのＶＬＡＮ_ＩＤとする場合に、ＲＰＲノード２００にはＶＬＡＮ_ＩＤの１〜１０００を割り当て、ＲＰＲノード２７０にはＶＬＡＮ_ＩＤの１００１〜２０００を割り当て、ＲＰＲノード２３０には１〜２０００以外のＶＬＡＮ_ＩＤを設定する。このアルゴリズムに従って、各ＲＰＲノード２００，２７０，２３０が、イーサネットフレームを配下の端末に送信するか否かを決定すれば、転送が重複することなく、トラフィックをインタリンク４２０〜４４０に分散して転送することができる。
また、障害の発生により、いずれかのインタリンク接続ノードが配下の端末にイーサネットフレームを送信できない状態となったときには、そのインタリンク接続ノードに定められたパラメータ値を、他のインタリンク接続ノードが引き継ぐようにしてもよい。例えば、配下の端末にイーサネットフレームを送信できない状態となったインタリンク接続ノードが、自ノードに定められたパラメータ値を他のノードへ通知するための特殊ＲＰＲフレームを送信し、その特殊ＲＰＲフレームを受信したインタリンク接続ノードがそのパラメータ値を自ノードに設定する。
また、別の例を挙げると、インタリンク接続ノードグループに属するインタリンク接続ノードのうち、いずれか一つのみがイーサネットフレームを配下の端末に送信するように定めてもよい。この場合、各インタリンク接続ノードは、自ノードが配下の端末にイーサネットフレームを送信するように定められているか否かを予め記憶しておく。そして、各インタリンク接続ノードは、マルチキャスト送信されたＲＰＲフレームを受信したとき、自ノードが配下の端末にイーサネットフレームを送信するインタリンク接続ノードとして定められているかを判定する。また、イーサネットフレームを配下の端末に送信すべきインタリンク接続ノードに障害が発生したときには、前述の特殊ＲＰＲフレームを他のインタリンク接続ノードに送信する。そして、それを受信したインタリンク接続ノードみが、配下の端末へのイーサネットフレーム送信を引き継ぐ。例えば、ＲＰＲノード２００のみが、イーサネットフレームを配下の端末に送信すると設定しておく。そして、インタリンク４２０が切断するなどの障害が発生した場合には、イーサネットフレームの送信処理をＲＰＲノード２００からＲＰＲノード２７０が引き継ぐようにすればよい。このとき、ＲＰＲノード２００は、インタリンク４２０の障害を検出したならば、受信したＲＰＲフレーム内のイーサネットフレームを配下の端末に送信することを指示する特殊ＲＰＲフレームを、ＲＰＲノード２７０に送信する。そして、この特殊ＲＰＲフレームを受信したＲＰＲノード２７０が、マルチキャスト送信されたＲＰＲフレームを自ノードで受信したときに、配下の端末にイーサネットフレームを送信すればよい。
なお、ＲＰＲノード２４０がイーサネットフレームをカプセル化してＲＰＲフレームを生成して送信する場合に、ＲＰＲフレームの宛先ＭＡＣドレスとしてインタリンク接続ノードグループ“Ｂ”に属するＲＰＲノードのうちのいずれか１つのＭＡＣアドレスを設定することによりユニキャスト送信してもよい。また、ＲＰＲフレームの宛先ＭＡＣドレスとしてインタリンク接続ノードグループ“Ｂ”の仮想ＭＡＣアドレス“ｂ”を用いてマルチキャスト送信を行ってもよい。どちらの場合であっても、インタリンク４２０，４３０，４４０のいずれか１つを経由して、インタリンク接続ノードグループ“Ａ”に属するＲＰＲノードのいずれか１つにイーサネットフレームを転送することができる。
次に、ＲＰＲネットワーク２０からＲＰＲネットワーク１０にイーサネットフレームが転送されてから、そのイーサネットフレームがＲＰＲノード１４０の配下の端末に転送されるまでの動作について説明する。ここでは、ＲＰＲノード２００が、ＲＰＲフレームに格納されたイーサネットフレームを、インタリンク４２０を介してＲＰＲノード１００に転送した場合を例にして説明する。
ＲＰＲノード１００は、ＲＰＲノード２００から送信されたイーサネットフレームを入力ポート５００−３で受信すると、それをＲＰＲフレーム生成部５２０に供給する。
ＲＰＲノード１００のＲＰＲフレーム生成部５２０は、イーサネットフレームの宛先ＭＡＣアドレスをキーとしてＦＤＢ５４０を検索し、キーに対応するＭＡＣアドレスを読み込む。検索に失敗した場合には、宛先ＭＡＣアドレスにブロードキャスト用ＭＡＣアドレスを設定したＲＰＲフレームを生成する。一方、検索に成功した場合には、ＦＤＢ５４０から読み込んだＭＡＣアドレスを宛先ＭＡＣアドレスに格納したＲＰＲフレームを生成する。本例では、ＲＰＲノード１００のＦＤＢ５４０には、イーサネットフレームの宛先となる端末のＭＡＣアドレスと、その端末を配下に収容しているＲＰＲノード１４０のＭＡＣアドレスとが対応付けられて記憶されている。従って、ＲＰＲノード１００のＲＰＲフレーム生成部５２０がＦＤＢ５４０の検索に成功し、その結果、ＲＰＲノード１４０のＭＡＣアドレスがＦＤＢ５４０から読み込まれる。
ＲＰＲノード１００のＲＰＲフレーム生成部５２０は、宛先ＭＡＣアドレスにＲＰＲノード１４０のＭＡＣアドレスを設定し、かつ、送信元ＭＡＣアドレスに自ノードが属するインタリンク接続ノードグループ“Ａ”のＭＡＣアドレス“ａ”を設定し、かつ、ペイロードにＲＰＲノード２００から受信したイーサネットフレームを格納したＲＰＲフレームを生成する。アドレスマッピングテーブル６００では、インタリンク接続ノードグループのＭＡＣアドレス“ａ”に対応するＭＡＣアドレスに、自ノード（１００）のアドレスが含まれている。よって、ＲＰＲフレーム生成部５２０は、自ノードがインタリンク接続ノードグループに属していると判定し、そのインタリンク接続ノードグループの仮想アドレス“ａ”を、送信元ＭＡＣアドレスとして用いる。ＲＰＲフレーム生成部５２０は、生成したＲＰＲフレームをＲＰＲスイッチ処理部５３０に供給する。
ＲＰＲノード１００のＲＰＲスイッチ処理部５３０は、出力ポート５８０−１または出力ポート５８０−２のいずれか一方から、そのＲＰＲフレームを送信する。このとき、ＲＰＲフレームのＴＴＬフィールドには、ＲＰＲノード１００の出力ポート５８０−１または出力ポート５８０−２のうち、実際にＲＰＲフレームを出力するポートからＲＰＲノード１４０までのホップ数が格納される。この送信は、ユニキャスト送信である。
ここでは、ＲＰＲノード１００のＲＰＲスイッチ処理部５３０が、ＲＰＲフレームのＴＴＬフィールドに、自ノードからＲＰＲノード１４０までのホップ数を格納し、そのＲＰＲフレームを出力ポート５８０−２からＲＰＲノード１７０へ送信する場合を例にする。
ＲＰＲノード１００からユニキャスト送信されたＲＰＲフレームは、ＲＰＲノード１７０，１６０，１５０を経てＲＰＲノード１４０へ順次転送される。ＲＰＲノード１４０は、自ノードを宛先とするＲＰＲフレームを受信すると、そのＲＰＲフレームからイーサネットフレームを抽出し、自ノードの配下の端末にそのイーサネットフレームを送信する。このときのＲＰＲノード１７０，１６０，１５０の動作は、前述のＲＰＲノード２４０からユニキャスト送信されたＲＰＲフレームを転送するＲＰＲノード２５０の動作と同様である。また、配下の端末にイーサネットフレームを送信するＲＰＲノード１４０の動作は、ユニキャスト送信されたＲＰＲフレームを受信して配下の端末であるＲＰＲノード１００にイーサネットフレームを送信する前述のＲＰＲノード２００の動作と同様である。
ＲＰＲノード１４０の配下の端末は、ＲＰＲノード１４０が出力ポート５８０−３から送信したイーサネットフレームを受信する。このイーサネットフレームは、送信元がＲＰＲノード２４０の配下の端末であるイーサネットフレームである。
以上説明した本実施形態によれば、ＲＰＲネットワーク１０とＲＰＲネットワーク２０との間に複数のインタリンク（４２０，４３０，４４０）が設けられたことにより、信頼性の高い通信システムを実現することができる。また、ＲＰＲネットワーク間におけるイーサネットフレームの転送を行う場合に、複数のインタリンクに分散してイーサネットフレームを転送することにより、輻輳の発生を抑制することができる。
また、インタリンク接続ノードグループテーブル５９０に、ＲＰＲノードのＭＡＣアドレスとインタリンク接続ノードグループの仮想ＭＡＣアドレスとの対応関係を登録し、その対応関係をアドレスマッピングテーブル６００に登録することにより、ＲＰＲノードをインタリンク接続ノードグループとしてグループ化することができる。従って、ネットワーク上の任意のノードをインタリンク接続ノードとして動作させることが可能となり、これにより、局舎の位置またはリンクの敷設場所等の制約を受けることなく、複数のインタリンクを配置することができる。
次に、ＲＰＲネットワーク１０及び２０間のインタリンク４２０，４３０，４４０に、切断などの障害が発生したときの障害回復動作について説明する。ここでは、インタリンク４２０に障害が発生し、インタリンク４３０，４４０のみでＲＰＲネットワーク間の通信を行えるように障害回復する場合を例にして説明する。
図１２は、インタリンク４２０に障害が発生した場合におけるＲＰＲネットワーク１０に属するＲＰＲノードの動作の例を示すフローチャートである。インタリンク４２０に障害が発生すると、ＲＰＲノード１００のポート状態監視部６２０は、自ノードのポートＰ３（入力ポート５００−３または出力ポート５００−３）が無効になったことを検出する（ステップＳ４１）。そして、ポート状態監視部６２０は、ポートＰ３が無効になったことを自ノードのアドレスマッピングテーブル管理部６１０に通知する。
同様に、ＲＰＲノード２００のポート状態監視部６２０も、自ノードのポートＰ３が無効になったことを検出し、その旨をアドレスマッピングテーブル管理部６１０に通知する。ＲＰＲノード２００およびＲＰＲネットワーク２０に属する他のＲＰＲノードの動作は、ＲＰＲノード１００およびＲＰＲネットワーク１０に属する他のＲＰＲノードの動作と同様である。よって、以下の説明では、図１２を参照して、ＲＰＲノード１００およびＲＰＲネットワーク１０に属する他のＲＰＲノードの動作について説明し、ＲＰＲノード２００およびＲＰＲネットワーク２０に属する他のＲＰＲノードの動作については説明を省略する。
ポートＰ３が無効となったことが通知されると、ＲＰＲノード１００のアドレスマッピングテーブル管理部６１０は、インタリンク接続ノードグループテーブル５９０を参照して、自ノードがグループに属しているか否かを判定する。このとき、アドレスマッピングテーブル管理部６１０は、インタリンク接続ノードグループの識別子（仮想ＭＡＣアドレス）に対応付けられているＭＡＣアドレスの中に、自ノードのＭＡＣアドレスが含まれているか否かを判定し、含まれていれば自ノードがインタリンク接続ノードグループに属していると判定する。アドレスマッピングテーブル管理部６１０は、自ノードがインタリンク接続ノードグループに属している場合、アドレスマッピングテーブル６００から自ノードのＭＡＣアドレスを削除する（ステップＳ４２）。
さらに、ＲＰＲノード１００のアドレスマッピングテーブル管理部６１０は、ＲＰＲネットワーク１０に属する全てのＲＰＲノードに対して、各ＲＰＲノードのアドレスマッピングテーブル６００のエントリのうち、ＲＰＲノード１００のインタリンク接続ノードグループのエントリから、ＲＰＲノード１００のＭＡＣアドレスを削除することを命じる通知をブロードキャスト送信する（ステップＳ４３）。このブロードキャスト送信は、ＲＰＲスイッチ処理部５３０により行われる。
上記の通知処理として、アドレスマッピングテーブル管理部６１０は、例えば、宛先ＭＡＣアドレスとして削除通知専用の特殊ＭＡＣアドレスを設定し、かつ、送信元ＭＡＣアドレスに自ノード（１００）のＭＡＣアドレスを設定し、かつ、ペイロードに自ノードが属するインタリンク接続ノードグループの仮想ＭＡＣアドレスを格納した特殊ＲＰＲフレームを生成する。そして、その特殊ＲＰＲフレームをＲＰＲスイッチ処理部５３０がブロードキャスト送信する。以下、この特殊ＲＰＲフレームを削除通知用の特殊ＲＰＲフレームと記す。また、このブロードキャスト送信は、例えば、“IEEE Standards 802.17”で定義されるブロードキャスト送信である。なお、削除通知用の特殊ＲＰＲフレームは、そのフレームをブロードキャスト送信するＲＰＲスイッチ処理部５３０が生成するよう構成してもよい。
ＲＰＲノード１１０〜１７０の入力ポート５００−１または入力ポート５００−２のいずれか一方で受信された削除通知用の特殊ＲＰＲフレームは、各ＲＰＲノードのフレーム解析部５１０−１またはフレーム解析部５１０−２に供給される。フレーム解析部５１０−１またはフレーム解析部５１０−２は、入力された削除通知用の特殊ＲＰＲフレームをアドレスマッピングテーブル管理部６１０に供給する。
アドレスマッピングテーブル管理部６１０は、アドレスマッピングテーブル６００におけるＲＰＲノード１００が属するインタリンク接続ノードグループのエントリから、削除通知用の特殊ＲＰＲフレームに設定されている送信元ＭＡＣアドレス（ここではＲＰＲノード１００のＭＡＣアドレス）を削除する（ステップＳ４４）。
また、各ＲＰＲノードのアドレスマッピングテーブル６１０は、受信した削除通知用特殊ＲＰＲフレームを、ＲＰＲスイッチ処理部５３０により、次のＲＰＲノードに送信する（ステップＳ４５）。なお、削除通知用特殊ＲＰＲフレームの廃棄態様は、他のブロードキャスト送信されるＲＰＲフレームと同様である。
この結果、ＲＰＲネットワーク１０に属する各ＲＰＲノードのアドレスマッピングテーブル６００から、インタリンク４２０に対応するポートＰ３が無効になったＲＰＲノード１００のＭＡＣアドレスが削除される。また、上記と同様の処理がＲＰＲネットワーク２０にて行われることにより、そのＲＰＲネットワーク２０に属する各ＲＰＲノードのアドレスマッピングテーブル６００から、インタリンク４２０に対応するポートＰ３が無効になったＲＰＲノード２００のＭＡＣアドレスが削除される。
いま、各インタリンク接続ノードが、イーサネットフレームを配下の端末に送信するか否かの判定を、受信したＲＰＲフレームのパラメータに応じて決定しているとする。この場合、ポートＰ３が無効となったインタリンク接続ノードは、自ノードに定められているパラメータの値を引き継ぐ指示を、自ノードと同一のインタリンク接続ノードグループに属するいずれかのインタリンク接続ノードに通知する。この通知は、特殊ＲＰＲフレームによって行えばよい。パラメータ値を引き継いだインタリンク接続ノードのアドレスマッピングテーブル管理部６１０は、そのパラメータ値に合致するＲＰＲフレーム受信した時に、イーサネットフレームを配下の端末に送信するようにＲＰＲスイッチ処理部５３０に要求する。これにより、ポートＰ３が無効となったインタリンク接続ノードが行っていたイーサネットフレームの送信を、他のインタリンク接続ノードが引き継ぐことができる。
上記に替えて、グループに属するインタリンク接続ノードのうちの何れか一つが、イーサネットフレームを配下の端末に送信するよう設定されている場合は次のように動作する。そのインタリンク接続ノードは、自ノードのポートＰ３が無効であることを検出したとき、グループ内の他のインタリンク接続ノードに対し、自ノードの役割を引き継ぐよう指示するための前述の特殊ＲＰＲフレームを送信する。これにより、その特殊ＲＰＲフレームを受信したインタリンク接続ノードのみが、イーサネットフレームを配下の端末に送信することになる。
また、インタリンク接続ノードグループに属さない各ＲＰＲノードが、ラウンドロビンや重み付けラウンドロビンを採用して、宛先アドレスを決定（図１０：ステップＳ１２）しているとする。この場合、ポートＰ３が無効になったＲＰＲノードのＭＡＣアドレスがアドレスマッピングテーブル６００から削除されることにより、そのＭＡＣアドレスが自動的に宛先アドレスの選択対象から除外される。
上記に替えて、インタリンク接続ノードグループに属さない各ＲＰＲノードが、イーサネットフレームのパラメータに応じてＭＡＣアドレス決定処理を行っているとする。この場合、各ＲＰＲノードのアドレスマッピングテーブル管理部６１０は、削除通知用特殊ＲＰＲフレームを受信したときに、その送信元のインタリンク接続ノードに対応するパラメータ値を、他のインタリンク接続ノードに割り当てるように、ＲＰＲフレーム生成部５２０に通知すればよい。この場合、アドレスマッピングテーブル管理部６１０は、各インタリンク接続ノードに割り当てられたパラメータ値を、インタリンク接続ノード毎に予め記憶しておく。ＲＰＲフレーム生成部５２０は、削除通知用特殊ＲＰＲフレームの送信元のインタリンク接続ノードに対応するパラメータ値を、そのインタリンク接続ノードと同一のグループに属する他のインタリンク接続ノードに割り当てたうえで、ＭＡＣアドレス決定処理を行えばよい。この場合にも、ポートＰ３が無効になったＲＰＲノードのＭＡＣアドレスが、自動的に選択対象から除外される。
以上のような動作により、インタリンク４２０に障害が発生した場合に、ＲＰＲネットワーク１０からＲＰＲネットワーク２０に転送されるフレームの宛先として、インタリンク４２０に対応するＲＰＲノード１００が選択されることを防止できる。また、ＦＤＢ５４０の検索に失敗してＲＰＲフレームをブロードキャスト送信する場合や、インタリンク接続ノードグループに対してマルチキャスト送信する場合にも、正常なインタリンク（４３０，４４０）に接続されるＲＰＲノード（１１０，１６０）のうちのいずれか一つが、配下の端末にイーサネットフレームを送信する。ＲＰＲネットワーク２０からＲＰＲネットワーク１０にイーサネットフレームを転送する場合も同様である。従って、たとえインタリンクの何れかに障害が発生しても、ＲＰＲネットワーク１０とＲＰＲネットワーク２０と間の通信を継続させることができる。
さらにまた、他のインタリンク４３０，４４０のいずれかで障害が発生した場合も、各ＲＰＲネットワーク１０，２０の各ＲＰＲノードは、インタリンク４２０に障害が発生したときと同様に動作する。この結果、障害の発生していないインタリンクを経由して通信を続行することができる。
次に、インタリンク４２０の障害が復旧して、ＲＰＲノード１００のポートＰ３のポート状態が有効の状態に変化した場合の動作を説明する。
図１３は、インタリンク４２０の障害が復旧した場合におけるＲＰＲネットワーク１０の各ＲＰＲノードの動作の例を示すフローチャートである。インタリンク４２０の障害が復旧すると、インタリンク４２０に対応するＲＰＲノード１００は、ポート状態監視部６２０により、自ノードのポートＰ３のポート状態が有効になったことを検出する（ステップＳ５１）。そして、ポート状態監視部６２０は、ポートＰ３が有効になったことをアドレスマッピングテーブル管理部６１０に通知する。
同様に、ＲＰＲネットワーク２０では、インタリンク４２０に対応するＲＰＲノード２００のポート状態監視部６２０が、自ノードのポートＰ３が有効になったことを検出し、その旨の情報をアドレスマッピングテーブル管理部６１０に通知する。ＲＰＲノード２００およびＲＰＲネットワーク２０に属する他のＲＰＲノードの動作は、ＲＰＲノード１００およびＲＰＲネットワーク１０に属する他のＲＰＲノードの動作と同様である。以下の説明では、図１３を参照して、ＲＰＲノード１００およびＲＰＲネットワーク１０に属する他のＲＰＲノードの動作について説明する。
ポートＰ３が有効になったことが通知されると、ＲＰＲノード１００のアドレスマッピングテーブル管理部６１０は、インタリンク接続ノードグループテーブル５９０を参照して、自ノードがインタリンク接続ノードグループに属しているか否かを判定する。この動作については、図４（ステップＳ４２）に沿って前述したので詳細な説明を省略する。アドレスマッピングテーブル管理部６１０は、自ノードがインタリンク接続ノードグループに属している場合、アドレスマッピングテーブル６００に、自ノードのＭＡＣアドレスを追加する（ステップＳ５２）。すなわち、インタリンク接続ノードグループテーブル５９０で自ノードのＭＡＣアドレスと対応付けられている仮想ＭＡＣアドレスをアドレスマッピングテーブル６００において検索し、その仮想ＭＡＣアドレスと対応付けられているＭＡＣアドレスに、自ノードのＭＡＣアドレスを追加する。
さらに、ＲＰＲノード１００のアドレスマッピングテーブル管理部６１０は、ＲＰＲネットワーク１０に属する全てのＲＰＲノードに対して、アドレスマッピングテーブル６００にＲＰＲノード１００のＭＡＣアドレスを追加することを命じる通知をブロードキャスト送信する（ステップＳ５３）。このブロードキャスト送信は、ＲＰＲスイッチ処理部５３０を介して行われる。
上記の通知処理として、アドレスマッピングテーブル管理部６１０は、例えば、通知すべきノードのＭＡＣアドレスを宛先ＭＡＣアドレスに設定し、かつ、送信元ＭＡＣアドレスに自ノード（本例ではＲＰＲノード１００）のＭＡＣアドレスを設定し、かつ、ペイロードに自ノードが属するインタリンク接続ノードグループの仮想ＭＡＣアドレスを格納した特殊ＲＰＲフレームを生成しブロードキャスト送信すればよい。以下、この特殊ＲＰＲフレームを追加通知用の特殊ＲＰＲフレームと記す。
ＲＰＲノード１１０〜１７０は、追加通知用の特殊ＲＰＲフレームを受信したとき、フレーム解析部５１０−１またはフレーム解析部５１０−２により、アドレスマッピングテーブル管理部６１０へ供給する。
アドレスマッピングテーブル管理部６１０は、アドレスマッピングテーブル６００のグループ“Ａ”のエントリに、追加用特殊ＲＰＲフレームの送信元ＭＡＣアドレス、すなわちＲＰＲノード１００のＭＡＣアドレスを追加する（ステップＳ５４）。
また、アドレスマッピングテーブル管理部６１０は、追加通知用特殊ＲＰＲフレームを、ＲＰＲスイッチ処理部５３０を介して、次のＲＰＲノードへ送信する（ステップＳ５５）。
この結果、ＲＰＲネットワーク１０に属する各ＲＰＲノードのアドレスマッピングテーブル６００に、ポートＰ３が有効になったＲＰＲノード１００のＭＡＣアドレスが追加され、インタリンク４２０の障害発生以前の状態に戻る。同様に、ＲＰＲネットワーク２０に属する各ＲＰＲノードのアドレスマッピングテーブル６００に、ポートＰ３が有効になったＲＰＲノード２００のＭＡＣアドレスが追加され、インタリンク４２０の障害発生以前の状態に戻る。
いま、各インタリンク接続ノードが、いま、各インタリンク接続ノードが、ＲＰＲフレーム中のイーサネットフレームを配下の端末に送信するか否かを、そのＲＰＲフレームのパラメータに応じて決定しているとする。また、ポートＰ３が無効となったインタリンク接続ノードが、自ノードのパラメータ値を引き継がせる指示を、同一グループの他のインタリンク接続ノードに通知していたとする。この場合、インタリンクの復旧に伴い、ポートＰ３が有効となったインタリンク接続ノードが、引き継ぎ指示の通知先のインタリンク接続ノードに対して、引き継ぎを停止する指示を通知する。この通知は、特殊ＲＰＲフレームによって行えばよい。この特殊ＲＰＲフレームを受信したインタリンク接続ノードは、アドレスマッピングテーブル管理部６１０により、それまで引き継いでいたパラメータ値に合致するＲＰＲフレームを受信したとしても、その中のイーサネットフレームを配下の端末に送信しないようにＲＰＲスイッチ処理部５３０に要求する。また、ポートＰ３が有効になったインタリンク接続ノードは、インタリンク障害発生前と同様に、配下の端末に対するイーサネットフレームの送信を再開する。この結果、各インタリンク接続ノードは、インタリンク障害発生前と同様に、配下の端末にイーサネットフレームを送信することができる。
また、いま、ＲＰＲフレームに格納されたイーサネットフレームを配下の端末に送信するように定められているノードが、同一グループのインタリンク接続ノードのうちの何れか一つであるとする。そして、ポートＰ３が無効となったインタリンク接続ノードが、自ノードと同一グループに属する他のインタリンク接続ノードに、イーサネットフレームの送信を指示する特殊ＲＰＲフレームを送信していたとする。この場合、インタリンクの復旧に伴いポートＰ３が有効となったインタリンク接続ノードが、その特殊ＲＰＲフレームの送信先であるインタリンク接続ノードに対し、イーサネットフレームの送信停止を指示する特殊ＲＰＲフレームを送信する。その後、その特殊ＲＰＲフレームを受信したインタリンク接続ノードは、ブロードキャスト送信またはマルチキャスト送信されたＲＰＲフレームを受信しても、配下の端末にイーサネットフレームを送信しない。一方、ポートＰ３が有効になったインタリンク接続ノードは、インタリンク障害発生前と同様に、配下の端末に対するイーサネットフレームの送信を再開する。この結果、ＲＰＲネットワーク間のイーサネットフレーム送信態様は、インタリンクの障害発生前と同様になる。
さらにまた、いま、インタリンク接続ノードグループに属さない各ＲＰＲノードが、ラウンドロビンや重み付けラウンドロビンを採用して、ＭＡＣアドレス決定処理（図１０：Ｓ１２）を行っているとする。アドレスマッピングテーブル６００に、ポートＰ３が有効になったＲＰＲノードのＭＡＣアドレスが追加されると、ポートＰ３が有効になったＲＰＲノードのＭＡＣアドレスが選択対象として追加される。そのため、インタリンクの障害発生前と同様に、そのようなＭＡＣアドレスもＭＡＣアドレス決定処理における選択対象となる。
また、インタリンク接続ノードグループに属さない各ＲＰＲノードが、イーサネットフレームのパラメータに応じて、ＭＡＣアドレス決定処理を行っているとする。そして、インタリンク接続ノードグループに属さない各ＲＰＲノードのアドレスマッピングテーブル管理部６１０が、削除通知用の特殊ＲＰＲフレームを受信したときに、そのフレームの送信元のインタリンク接続ノードに対応するパラメータ値を、他のインタリンク接続ノードに割り当てるように、ＲＰＲフレーム生成部５２０に通知していたとする。この場合、アドレスマッピングテーブル管理部６１０は、追加通知用特殊ＲＰＲフレームを受信したときに、他のインタリンク接続ノードに割り当てていたパラメータ値を、追加通知用特殊ＲＰＲフレームの送信元のインタリンク接続ノードに割り当てるように、ＲＰＲフレーム生成部５２０に通知すればよい。この結果、ＲＰＲフレーム生成部５２０は、インタリンクの障害発生以前と同様に、ＭＡＣアドレス決定処理を再開する。
以上のような動作により、ＲＰＲネットワーク１０からＲＰＲネットワーク２０にイーサネットフレームを転送するときに、そのイーサネットフレームをカプセル化したＲＰＲフレームの宛先として、正常なインタリンクに接続されるＲＰＲノードだけでなく、復旧したインタリンク４２０に接続されるＲＰＲノード１００も選択されるようになる。また、ＦＤＢ５４０の検索に失敗してＲＰＲフレームをブロードキャスト送信する場合や、インタリンク接続ノードグループに対してマルチキャスト送信する場合にも、各インタリンク４２０，４３０，４４０に接続されるＲＰＲノード１００，１１０，１６０のいずれか一つが、配下の端末にイーサネットフレームを送信する。従って、インタリンク４２０に障害が発生する前の状態に復帰することができる。
以上の説明では、インタリンク接続ノードのアドレスマッピングテーブル管理部６１０が、インタリンクの障害検出をトリガとして、特殊ＲＰＲフレームをブロードキャスト送信することにより、ＲＰＲネットワークに属する全てのＲＰＲノードのアドレスマッピングテーブル６００を更新する態様を説明した。
以下の説明では、ＲＰＲノード１００〜１７０が、ＲＰＲネットワークのトポロジを管理するために使用するＲＰＲのＴｏｐｏｌｏｇｙ ａｎｄ Ｐｒｏｔｅｃｔｉｏｎフレーム（以下、「ＴＰフレーム」と記述する。）を利用してアドレスマッピングテーブル６００を更新する態様を説明する。
“IEEE Standards 802.17”によると、ＲＰＲノードは、ＲＰＲネットワークのトポロジを管理するために、隣接ＲＰＲノードと接続されるポート（ポートＰ１およびポートＰ２）のポート状態を格納したＴＰフレームを、ポートＰ１，Ｐ２の両方から、一定の時間間隔でブロードキャスト送信する。なお、ＴＰフレームは、特殊ＲＰＲフレームではない。
以下に説明する本実施形態の各ＲＰＲノードは、隣接ＲＰＲノードと接続されるポート（ポートＰ１およびポートＰ２）のポート状態に加えて、配下の端末と接続されるポート（ポートＰ３）のポート状態を格納したＴＰフレームを一定の時間間隔でブロードキャスト送信する。
また、各ＲＰＲノードのＴＤＢ５６０は、自ノードと同一のＲＰＲネットワークに属する各ＲＰＲノードのポートＰ１，Ｐ２のポート状態に加えて、各ＲＰＲノードのポートＰ３の状態も記憶する。図１４は、ＴＤＢ５６０に登録された情報の例を示す説明図である。図１４に示す例では、ＲＰＲネットワーク１０に属する各ＲＰＲノードのポートＰ１，Ｐ２，Ｐ３の状態を示す情報がＴＤＢ５６０に登録されている。図５に示す場合と同様に、ＲＰＲノードのノード識別子に対応付けられて、各ポートの状態を示す情報が登録される。ＲＰＲノードのノード識別子として、ＲＰＲノードのＭＡＣアドレスが用いられる。
また、以下に示すインタリンク障害発生時の動作態様では、前述の説明と同様に、インタリンク４２０に障害が発生した場合を例にして説明する。また、ＲＰＲネットワーク１０に属するＲＰＲノードについて説明し、ＲＰＲネットワーク２０に属するＲＰＲノードについては説明を省略する。
インタリンク４２０に障害が発生して、ＲＰＲノード１００のポートＰ３の状態が有効から無効に変化すると、ＲＰＲノード１００のポート状態監視部５３０は、ＴＤＢ５６０における自ノードのポートＰ３の状態を有効から無効に変更する。
ＲＰＲノード１００のＲＰＲスイッチ処理部５３０は、ＴＤＢ５６０が変更されると、ＲＰＲノード１００のポートＰ３が無効であることを示すＴＰフレームを一定の時間間隔でブロードキャスト送信する。
ＲＰＲネットワーク１０に属する他のＲＰＲノードのフレーム解析部５１０−１，５１０−２に、このＴＰフレームが入力されると、フレーム解析部５１０−１，５１０−２は、ＴＰフレームをＲＰＲスイッチ処理部５３０に送る。ＴＰフレームが送られたＲＰＲスイッチ処理部５３０は、ＲＰＲノード１００のポートＰ３が無効であることを自ノードのＴＤＢ５６０に記録する。
また、ＲＰＲネットワーク１０のＲＰＲノード１００を含む各ノードは、アドレスマッピングテーブル管理部６１０により、ＴＤＢ５６０においてＲＰＲノード１００のポートＰ３のポート状態が無効に変化したことを検出すると、このＲＰＲノード１００がインタリンク接続ノードグループに属しているか否かを判定する。この判定は、例えば、ＴＤＢ５６０においてポートＰ３の状態が変更されたＲＰＲノードのＭＡＣアドレスが、インタリンク接続ノードグループテーブル５９０に含まれているならば、ポートＰ３が無効になったＲＰＲノードがインタリンク接続ノードグループに属していると判定すればよい。アドレスマッピングテーブル管理部６１０は、ポートＰ３が無効になったＲＰＲノードがインタリンク接続ノードグループに属していると判定した場合、自ノードのアドレスマッピングテーブル６００から、そのＲＰＲノードのＭＡＣアドレスを削除する。
この結果、各ＲＰＲノードのアドレスマッピングテーブル６００において、ポートＰ３が無効になったＲＰＲノード１００のＭＡＣアドレスが削除される。
いま、各インタリンク接続ノードが、ＲＰＲフレーム中のイーサネットフレームを配下の端末に送信するか否かを、そのＲＰＲフレームのパラメータに応じて決定しているとする。この場合、例えば、既に説明した動作と同様の動作によって、ポートＰ３が無効となったインタリンク接続ノードが行っていたイーサネットフレームの送信を、他のインタリンク接続ノードが引き継げばよい。
また、いま、イーサネットフレームを配下の端末に送信するノードとして、同一グループのインタリンク接続ノードのうちの一つのみが設定されているとする。この場合も、既に説明した動作と同様の動作によって、ポートＰ３が無効となったインタリンク接続ノードが行っていたイーサネットフレームの送信を、他のインタリンク接続ノードが引き継げばよい。
また、インタリンク接続ノードグループに属さない各ＲＰＲノードが、ラウンドロビンや重み付けラウンドロビンを採用して、ＭＡＣアドレス決定処理を行っているとする。アドレスマッピングテーブル６００から、ポートＰ３が無効になったＲＰＲノードのＭＡＣアドレスが削除されたとき、ポートＰ３が無効になったＲＰＲノードのＭＡＣアドレスが選択対象から除外される。
また、インタリンク接続ノードグループに属さない各ＲＰＲノードが、イーサネットフレームのパラメータに応じてＭＡＣアドレス決定処理を行っているとする。この場合、インタリンク接続ノードグループに属さない各ＲＰＲノードのアドレスマッピングテーブル管理部６１０は、ＴＤＢ５６０においてポートＰ３の状態が無効になったＲＰＲノードがインタリンク接続ノードであるならば、そのインタリンク接続ノードに対応するパラメータ値を、他のインタリンク接続ノードに割り当てるように、ＲＰＲフレーム生成部５２０に通知すればよい。この場合、インタリンク接続ノードグループに属さない各ＲＰＲノードのアドレスマッピングテーブル管理部６１０は、各インタリンク接続ノードに割り当てられたパラメータ値を、インタリンク接続ノード毎に予め記憶しておけばよい。ＲＰＲフレーム生成部５２０は、この通知に従って、ポートＰ３の状態が無効になったインタリンク接続ノードのパラメータ値を、そのインタリンク接続ノードと同一のインタリンク接続ノードグループに属する他のインタリンク接続ノードに割り当てる。この場合にも、ポートＰ３が無効になったＲＰＲノードのＭＡＣアドレスが、アドレス決定処理の選択肢から除外される。
ＲＰＲノード１００は、自ノードのＭＡＣアドレスをアドレスマッピングテーブル６００から削除した後に、インタリンク４２０の障害が復旧したとき、ＴＤＢ５６０に記憶されている自ノードのポートＰ３の状態をポート状態監視部５３０により有効に変更する。
このようにＲＰＲノード１００のＴＤＢ５６０が変更されると、ＲＰＲノード１００のＲＰＲスイッチ処理部５３０は、ＲＰＲノード１００のポートＰ３の状態を無効から有効の状態に変更したＴＰフレームを一定の時間間隔でブロードキャスト送信する。
既に説明したように、ＴＰフレームが入力されたＲＰＲスイッチ処理部５３０は、ＴＰフレームが示すポート状態に合わせて、自ノードのＴＤＢ５６０が記憶している情報を更新する。ここでは、各ＲＰＲノードのＲＰＲスイッチ処理部５３０が、ＴＤＢ５６０に記憶されているＲＰＲノード１００のポートＰ３のポート状態の情報を、無効から有効に更新する。
また、ＲＰＲネットワーク１０のＲＰＲノード１００を含む各ノードは、アドレスマッピングテーブル管理部６１０により、ＴＤＢ５６０においてＲＰＲノード１００のポートＰ３のポート状態が有効の状態に変化したことを検出すると、自ノードのインタリンク接続ノードグループテーブル５９０において、ポートＰ３が有効になったＲＰＲノード１００がインタリンク接続ノードグループに属しているか否かを判定する。この判定は、前述したものと同様である。アドレスマッピングテーブル管理部６１０は、ポートＰ３が有効になったＲＰＲノードがインタリンク接続ノードグループに属していると判定した場合、インタリンク接続ノードグループテーブル５９０を参照して、ポートＰ３が有効になったインタリンク接続ノードのＭＡＣアドレスに対応する仮想ＭＡＣアドレスを確認する。そして、アドレスマッピングテーブル管理部６１０は、アドレスマッピングテーブル６００に、ポートＰ３が有効になったインタリンク接続ノード（１００）のＭＡＣアドレスを追加する。
この結果、各ＲＰＲノードのアドレスマッピングテーブル６００に記憶される情報は、インタリンク４２０における障害発生前と同様になる。
各インタリンク接続ノードが、ＲＰＲフレームのパラメータに応じて、イーサネットフレームを配下の端末に送信するか否かをを決定している場合、既に説明した動作と同様の動作によって、インタリンクの障害発生前と同様の態様に戻せばよい。
また、いずれか一つのインタリンク接続ノードのみが、イーサネットフレームを配下の端末に送信するように定められている場合も、既に説明した動作と同様の動作によって、インタリンクの障害発生前と同様の態様に戻せばよい。
また、インタリンク接続ノードグループに属さない各ＲＰＲノードが、ラウンドロビンや重み付けラウンドロビンを採用して、ＭＡＣアドレス決定処理を行っているとする。アドレスマッピングテーブル６００に、ポートＰ３が有効になったＲＰＲノードのＭＡＣアドレスが追加されたとき、そのＭＡＣアドレスが選択対象として追加される。
また、いま、インタリンク接続ノードグループに属さない各ＲＰＲノードが、イーサネットフレームのパラメータに応じてＭＡＣアドレス決定処理を行っているとする。また、それら各ＲＰＲノードのアドレスマッピングテーブル管理部６１０が、ポートＰ３の状態が有効から無効に変更されたインタリンク接続ノードに対応するパラメータ値を、他のインタリンク接続ノードに割り当てるように、ＲＰＲフレーム生成部５２０に通知していたとする。この場合、そのアドレスマッピングテーブル管理部６１０は、ＴＤＢ５６０においてポートＰ３の状態が無効から有効に変更されたとき、そのＲＰＲノードがインタリンク接続ノードであるならば、他のインタリンク接続ノードに割り当てていたパラメータの値を、インタリンクの障害発生以前の状態に戻すように、ＲＰＲフレーム生成部５２０に通知すればよい。
以上のように、ＴＰフレームを活用することにより、削除通知用特殊ＲＰＲフレームおよび追加用特殊ＲＰＲフレームを用いる場合と同様の障害回復動作を実現できる。
次に、ノード間のリンクではなく、インタリンク接続ノードに障害が発生したときの障害回復動作について説明する。ここでは、ＲＰＲノード１００に障害が発生した場合を例にして説明する。また、以下の動作は、各ＲＰＲノードのＴＤＢ５６０が、図１４に示すように、ＲＰＲノード毎にポートＰ１，Ｐ２，Ｐ３それぞれのポート状態を管理していることを前提とする。また、以下に示す動作では、ＴＰフレームをキープアライブフレームとして利用する。
各ＲＰＲノードは、自ノードの各ポートＰ１，Ｐ２，Ｐ３の状態を示すＴＰフレームを一定の時間間隔でブロードキャスト送信する。ＲＰＲノード１００に障害が生じたとき、ＲＰＲノード１００は、ＴＰフレームの送信が不可能となる。また、ＲＰＲネットワーク１０に属する他のＲＰＲノードは、ＲＰＲノード１００からＴＰフレームが届かなくなる。
ＲＰＲネットワーク１０に属する各ＲＰＲノードのＲＰＲスイッチ処理部５３０は、個々のＲＰＲノードからのＴＰフレームが到着しない状態が一定時間以上続いた場合、そのＲＰＲノードに障害が生じたと判定する。なお、この一定時間は、ＴＰフレームの送信時間間隔より長く定める。本例では、ＲＰＲネットワーク１０に属する各ＲＰＲノードのＲＰＲスイッチ処理部５３０が、ＲＰＲノード１００からのＴＰフレームが到着しない状態が一定時間続いたことにより、ＲＰＲノード１００における障害発生を検出する。ＲＰＲスイッチ処理部５３０は、自ノードのＴＤＢ５６０におけるＲＰＲノード１００のポートＰ１，Ｐ２，Ｐ３のポート状態を無効の状態に変更する。
障害が発生していない各ＲＰＲノードのアドレスマッピングテーブル管理部６１０は、ＴＤＢ５６０の上記変更を検出すると、自ノードのインタリンク接続ノードグループテーブル５９０を参照して、無効となったＲＰＲノード１００がインタリンク接続ノードグループに属しているか否かを判定する。この判定は、ＲＰＲノード１００のＭＡＣアドレスが、インタリンク接続ノードグループテーブル５９０に含まれているならば、インタリンク接続ノードグループに属していると判定する。アドレスマッピングテーブル管理部６１０は、障害が発生したＲＰＲノード１００がインタリンク接続ノードグループに属していると判定した場合には、アドレスマッピングテーブル６００から、ＲＰＲノード１００のＭＡＣアドレスを削除する。
この結果、ＲＰＲネットワーク１０の各ＲＰＲノードのアドレスマッピングテーブル６００から、障害の発生したＲＰＲノード１００のＭＡＣアドレスが削除される。
各インタリンク接続ノードが、ＲＰＲフレームを受信したときに、そのフレームのパラメータに応じて、イーサネットフレームを配下の端末に送信するか否かを決定しているとする。この場合、他のＲＰＲノードの障害発生を検出した各インタリンク接続ノードのアドレスマッピングテーブル管理部６１０は、ＴＤＢ５６０およびインタリンク接続ノードグループテーブル５９０を参照して、そのＲＰＲノードがインタリンク接続ノードであるか否かを判定する。障害が発生したＲＰＲノードがインタリンク接続ノードである場合、アドレスマッピングテーブル管理部６１０は、そのインタリンク接続ノードのＭＡＣアドレスをＴＤＢ５６０から読み込み、ＲＰＲスイッチ処理部５３０に通知する。ＲＰＲスイッチ処理部５３０は、そのインタリンク接続ノードに対応するパラメータ値を、他のインタリンク接続ノードに割り当てる。この場合、各インタリンク接続ノードのＲＰＲスイッチ処理部５３０は、各インタリンク接続ノードに割り当てられたパラメータ値を、インタリンク接続ノード毎に予め記憶しておけばよい。障害の発生していない各インタリンク接続ノードのＲＰＲスイッチ処理部５３０は、障害の発生したインタリンク接続ノードに対応するパラメータ値を他のインタリンク接続ノードに割り当てた後、その割り当てに従って、イーサネットフレームを配下の端末に送信するか否かを決定する。この結果、障害が発生したインタリンク接続ノードが分担していたイーサネットフレームの送信を、他のインタリンク接続ノードが引き継ぐことができる。
また、いずれか一つのインタリンク接続ノードのみが、イーサネットフレームを配下の端末に送信するように定められていたとする。この場合、イーサネットフレームの送信を行っていたインタリンク接続ノードに障害が発生した場合、他のインタリンク接続ノードのいずれか一つがイーサネットフレームの送信を引き継げばよい。また、この場合、どのインタリンク接続ノードに障害が発生したときに、どのインタリンク接続ノードがイーサネットフレームの送信を引き継ぐのかを予め定めておけばよい。各インタリンク接続ノードのＲＰＲスイッチ処理部５３０は、ＴＤＢ５６０におけるポート状態の変更により、他のインタリンク接続ノードの障害発生を検出したとき、自ノードがイーサネットフレーム送信を引き継ぐか否かを判定する。そして、その判定結果に従って、受信したＲＰＲフレームに格納されたイーサネットフレームを配下の端末に送信するか否かを決定すればよい。
また、インタリンク接続ノードグループに属さない各ＲＰＲノードが、ラウンドロビンや重み付けラウンドロビンを採用して、ＭＡＣアドレス決定処理を行っているとする。アドレスマッピングテーブル６００から、障害が発生したＲＰＲノードのＭＡＣアドレスが削除されたとき、障害が発生したＲＰＲノードのＭＡＣアドレスが選択対象から除外される。
また、インタリンク接続ノードグループに属さない各ＲＰＲノードが、イーサネットフレームのパラメータに応じてＭＡＣアドレス決定処理を行っているとする。この場合、それら各ＲＰＲノードのアドレスマッピングテーブル管理部６１０は、ＴＤＢ５６０およびインタリンク接続ノードグループテーブル５９０を参照して、障害が発生したＲＰＲノードがインタリンク接続ノードであるか否かを判定する。障害が発生したＲＰＲノードがインタリンク接続ノードである場合、アドレスマッピングテーブル管理部６１０は、そのインタリンク接続ノードに対応するパラメータ値を、他のインタリンク接続ノードに割り当てるように、ＲＰＲフレーム生成部５２０に通知する。この場合、インタリンク接続ノードグループに属さない各ＲＰＲノードのアドレスマッピングテーブル管理部６１０は、各インタリンク接続ノードに割り当てられたパラメータ値を、インタリンク接続ノード毎に予め記憶しておけばよい。ＲＰＲフレーム生成部５２０は、アドレスマッピングテーブル管理部６１０からの通知に従って、障害が発生したインタリンク接続ノードに対応するパラメータ値を、そのインタリンク接続ノードと同一のインタリンク接続ノードグループに属する他のインタリンク接続ノードに割り当てて、ＭＡＣアドレス決定処理を行えばよい。
以上の動作により、ＲＰＲネットワーク１０からＲＰＲネットワーク２０にイーサネットフレームを転送するときに、そのイーサネットフレームを内包したＲＰＲフレームの宛先として、障害の発生したＲＰＲノード１００が選択対象から除外される。そして、正常なＲＰＲノード１１０，１６０のいずれか１つが選択される。また、ＦＤＢ５４０の検索に失敗してＲＰＲフレームをブロードキャスト送信する場合や、インタリンク接続ノードグループに対してマルチキャスト送信する場合にも、正常なＲＰＲノード１１０，１６０のうちのいずれか１つが、配下の端末にイーサネットフレームを送信する。従って、ＲＰＲノード１００に障害が発生しても、ＲＰＲネットワーク１０からＲＰＲネットワーク２０への転送処理を続行することができる。
一方、ＲＰＲノード１００に障害が発生した場合、ＲＰＲノード２００にとっては、インタリンク４２０に障害が発生した状態と同じ状態（ＲＰＲノード１００と通信できない状態）になる。従って、ＲＰＲノード１００に障害が発生した場合、ＲＰＲノード２００は、インタリンク４２０に障害が発生したことを検出し、ＲＰＲネットワーク２０に属するＲＰＲノードは、インタリンクに障害が発生したときと同様の動作を行えばよい。よって、ＲＰＲネットワーク２０からＲＰＲネットワーク１０への通信も続行できる。
この結果、障害の発生したＲＰＲノード１００に接続されているインタリンク４２０がイーサネットフレームの転送に使用されなくなり、インタリンク４３０，４４０のみがイーサネットフレーム転送に使用されるようになるため、ＲＰＲネットワーク１０，２０間の通信を続行することができる。
次に、ＲＰＲノード１００の障害が復旧して、ＲＰＲノード１００のポートＰ１〜Ｐ３のポート状態が無効から有効に変化した場合の動作を説明する。
障害から復旧したＲＰＲノード１００は、自ノードの各ポートＰ１，Ｐ２，Ｐ３がいずれも有効であることを示すＴＰフレームを一定の時間間隔でブロードキャスト送信する。ＲＰＲネットワーク１０に属する他のＲＰＲノードは、ＲＰＲノード１００からのＴＰフレームを受信すると、ＲＰＲスイッチ処理部５３０により、ＲＰＲノード１００の復旧を検出する。ＲＰＲスイッチ処理部５３０は、自ノードのＴＤＢ５６０において、復旧したＲＰＲノード１００のポートＰ１，Ｐ２，Ｐ３のポート状態を無効から有効に変更する。
各ＲＰＲノードのアドレスマッピングテーブル管理部６１０は、ＴＤＢ５６０におけるＲＰＲノード１００のポートＰ３の状態が無効から有効に変化したことを検出すると、自ノードのインタリンク接続ノードグループテーブル５９０を参照して、そのＲＰＲノード１００がインタリンク接続ノードグループに属しているか否かを判定する。アドレスマッピングテーブル管理部６１０は、障害から復旧したＲＰＲノード１００がインタリンク接続ノードグループに属していると判定した場合には、自ノードのアドレスマッピングテーブル６００のエントリのうち、障害から復旧したＲＰＲノード１００が属するインタリンク接続ノードグループのエントリに、ＲＰＲノード１００のＭＡＣアドレスを追加する。
この結果、ＲＰＲネットワーク１０の各ＲＰＲノードのアドレスマッピングテーブル６００に、障害から復旧したＲＰＲノード１００のＭＡＣアドレスが追加される。
いま、各インタリンク接続ノードが、ＲＰＲフレームのパラメータに応じて、そのフレーム中のイーサネットフレームを配下の端末に送信するか否かを決定しているとする。そして、各インタリンク接続ノードのＲＰＲスイッチ処理部５３０が、障害が発生したインタリンク接続ノードに対応するパラメータの値を他のインタリンク接続ノードに割り当てていたとする。この場合、アドレスマッピングテーブル管理部６１０は、ＴＤＢ５６０を参照した結果、復旧したＲＰＲノードがインタリンク接続ノードである場合、そのインタリンク接続ノードのＭＡＣアドレスをＴＤＢ５６０から読み込み、ＲＰＲスイッチ処理部５３０に通知する。ＲＰＲスイッチ処理部５３０は、各インタリンク接続ノードに対するパラメータ値の割り当てを、障害発生前と同様に戻す。この結果、各インタリンク接続ノードは、障害発生前と同様に、配下の端末にイーサネットフレームを送信することができる。
また、いずれか一つのインタリンク接続ノードのみが、イーサネットフレームを配下の端末に送信するように定められていたとする。そして、そのインタリンク接続ノードに障害が発生し、他のインタリンク接続ノードがイーサネットフレームの送信を引き継いでいたとする。この場合、引き継いだインタリンク接続ノードのＲＰＲスイッチ処理部５３０は、ＴＤＢ５６０におけるポート状態の変更により、他のインタリンク接続ノードの復旧を検出したとき、障害発生前と同様に、配下の端末へのイーサネットフレームの送信を行わないことを認識する。一方、障害から復旧したインタリンク接続ノードは、障害発生前と同様に、配下の端末にイーサネットフレームを送信する。
また、インタリンク接続ノードグループに属さない各ＲＰＲノードが、ラウンドロビンや重み付けラウンドロビンを採用して、ＭＡＣアドレス決定処理を行っているとする。アドレスマッピングテーブル６００に、障害から復旧したＲＰＲノードのＭＡＣアドレスが追加されたとき、そのアドレスが選択対象に復帰する。
また、インタリンク接続ノードグループに属さない各ＲＰＲノードが、イーサネットフレームのパラメータに応じてアドレス決定処理を行っているとする。そして、それら各ＲＰＲノードのアドレスマッピングテーブル管理部６１０が、障害の発生したインタリンク接続ノードに対応するパラメータ値を、他のインタリンク接続ノードに割り当てるように、ＲＰＲフレーム生成部５２０に通知していたとする。この場合、それら各ＲＰＲノードのアドレスマッピングテーブル管理部６１０は、ＴＤＢ５６０におけるポート状態の変更によりインタリンク接続ノードの復旧を検出したとき、他のインタリンク接続ノードに割り当てたパラメータ値を、復旧したインタリンク接続ノードに割り当て直すように、ＲＰＲフレーム生成部５２０に通知する。ＲＰＲフレーム生成部５２０は、パラメータ値を割り当て直し、ＭＡＣアドレス決定処理を行う。
以上のような動作により、ＲＰＲネットワーク１０からＲＰＲネットワーク２０にイーサネットフレームを転送するときに、そのイーサネットフレームをカプセル化したＲＰＲフレームの宛先として、復旧したＲＰＲノード１００が選択肢に復活する。また、ＦＤＢ５４０の検索に失敗してＲＰＲフレームをブロードキャスト送信する場合や、インタリンク接続ノードグループに対してマルチキャスト送信する場合にも、同様である。
また、ＲＰＲノード２００は、ＲＰＲノード１００が障害から回復したことにより、インタリンク４２０が障害から回復したときと同じ状態（ＲＰＲノード１００と通信可能な状態）になる。従って、ＲＰＲノード１００が障害から復旧した場合、ＲＰＲノード２００は、インタリンク４２０が障害から復旧したことを検出し、ＲＰＲネットワーク２０に属するＲＰＲノードは、インタリンクが障害から復旧したときと同様の動作を行えばよい。この結果、インタリンク４２０を経由するＲＰＲネットワーク２０からＲＰＲネットワーク１０へのイーサネットフレーム転送も再開される。
以上のように、ＲＰＲノード１００が障害から復旧した場合、通信システムの動作は、ＲＰＲノード１００の障害発生前の正常時と同様の動作を行うようになる。
次に、ＲＰＲネットワーク（１０、２０）におけるインタリンク接続ノードの両側の２つのリンクに障害が発生した場合の動作について説明する。一例として、ＲＰＲネットワーク１０のＲＰＲノード１００及び１１０間のリンクと、ＲＰＲノード１００及び１７０間のリンクとに、それぞれ障害が発生した場合を説明する。この場合、ＲＰＲノート１００は、ＲＰＲネットワーク１０から孤立した状態となる。
このような障害が発生した場合、ＲＰＲネットワーク１０に属する各ＲＰＲノードは、Ｔｏｐｏｌｏｇｙ Ｄｉｓｃｏｖｅｒｙ Ｐｒｏｔｏｃｏｌにより、ＲＰＲノード１００との通信が不可能になったこと、すなわち、インタリンク４２０が使用不可能になったことを認識することができる。
ＲＰＲノード１００は、自ノードのリンクに障害が発生したことを検出すると、インタリンク４２０には障害が発生していないが、ＲＰＲノード２００との接続のためのポートＰ３を無効化する。この結果、ＲＰＲノード２００は、インタリンク４２０に障害が発生したと認識する。そして、ＲＰＲネットワーク２０に属する各ＲＰＲノードは、インタリンクに障害が発生したときと同様の動作を行う。これにより、ＲＰＲネットワーク２０からＲＰＲネットワーク１０への通信は、インタリンク４３０又は４４０を用いて続行される。
ここで、仮に、上記障害が発生しても、ＲＰＲノード１００が自ノードのポートＰ３を無効にしないとする。この場合、ＲＰＲネットワーク２０側では、インタリンク４２０が実質的に使用できないことを認識することができない。その結果、ＲＰＲネットワーク２０に属する配下の端末から送信されたイーサネットフレームが、インタリンク４２０を介してＲＰＲノード１００に転送され、結局、それより先に転送できないという事態が生じる。従って、ＲＰＲノード１００が自ノードのポートＰ３を無効化して、ＲＰＲネットワーク２０の各ＲＰＲノードに、インタリンク４２０に障害が発生したときと同様の動作を行わせることで、上記のような事態を回避することができる。
ＲＰＲネットワーク１０に属する各ＲＰＲノードは、リンク障害によりＲＰＲノード１００との通信が不可能になったことを認識したとき、ＲＰＲノード１００自体に障害が発生したときと同様の動作を行う。この結果、ＲＰＲネットワーク１０からＲＰＲネットワーク２０への通信も続行することができる。
また、障害が発生していた２つのリンクの少なくとも一方が復旧したとする。このとき、ＲＰＲノード１００は、復旧を検出すると、自ノードのポートＰ３のポート状態を有効の状態に変更する。
ＲＰＲノード２００は、インタリンク４２０の復旧を検出する。そして、各ＲＰＲネットワークのＲＰＲノードは、インタリンクが障害から復旧したときと同様の動作を行う。この結果、インタリンク４２０を経由するＲＰＲネットワーク２０からＲＰＲネットワーク１０へのフレーム転送が再開される。
また、ＲＰＲノード１００，１１０間のリンクおよびＲＰＲノード１００，１７０間のリンクそれぞれが障害から復旧したことにより、ＲＰＲネットワーク１０の各ＲＰＲノードは、ＲＰＲノード１００との通信が可能となったと認識する。そして、ＲＰＲネットワーク１０の各ＲＰＲノードは、インタリンク接続ノードが障害から復旧したときと同様の動作を行う。この結果、インタリンク４２０を経由するＲＰＲネットワーク２０からＲＰＲネットワーク１０へのフレーム転送も再開される。
以上のように、インタリンク接続ノードの両側のリンクにそれぞれ障害が発生した場合であっても、そのインタリンク接続ノードにおけるインタリンク用のポート（ポートＰ３）の状態を変更することにより、ＲＰＲネットワーク間の通信を維持することが可能である。
次に、ＲＰＲネットワーク１０またはＲＰＲネットワーク２０のいずれか一方または両方において、ＲＰＲノード間のリンクに障害が発生した場合、あるいはインタリンク接続ノード以外のＲＰＲノードに障害が発生した場合の障害回復について説明する。
ここでは、それぞれのＲＰＲネットワークにおいて、障害発生は一箇所であるものとする。従って、１つのＲＰＲネットワークでは、リンク障害またはノード障害が１箇所発生するものとする。
このような障害が発生した場合、“IEEE Standards 802.17”において “Ｓｔｅｅｒｉｎｇ”または“Ｗｒａｐｐｉｎｇ”と呼ばれるプロテクション機能により、正常なＲＰＲノード間の通信を続行することが可能である。そのため、特別な処理を行う必要はない。よって、上記のようなリンク障害またはノード障害が発生したときであっても、ＲＰＲネットワーク１０とＲＰＲネットワーク２０との間の通信を続行することができる。
実施の形態２．
図１５は、本発明による通信システムの第２の実施の形態を示す説明図である。第１の実施の形態と同様の構成部については、図１と同一の符号を付し、説明を省略する。
図１５に示す例では、通信システムは、ＲＰＲノード１００〜１７０を有するＲＰＲネットワーク１０と、ＥｏＥ（Ethernet over Ethernet）ノード７００〜７７０を有するＥｏＥネットワーク３０とを備える。ＥｏＥノードには、配下に端末を収容するＥｏＥエッジノードと、配下に端末を収容せずにＥｏＥフレームの中継を行うＥｏＥコアノードとがある。ＥｏＥエッジノードの配下の端末は、ＲＰＲネットワークに属するＲＰＲノードであってもよい。図１５に示す例では、ＲＰＲノード１００とＥｏＥノード７００とが、インタリンク４５０によって接続され、ＲＰＲノード１１０とＥｏＥノード７５０とが、インタリンク４６０によって接続され、ＲＰＲノード１６０とＥｏＥノード７２０とが、インタリンク４７０によって接続される。
ＥｏＥネットワークでは、イーサネットフレームの送信元端末を配下に収容する入口側ＥｏＥエッジノードが、その配下の端末から受信したイーサネットフレームをＥｏＥフレームにカプセル化することによりＥｏＥフレームを生成する。ＥｏＥエッジノードが出力したＥｏＥフレームは、ＥｏＥコアノードの中継により、宛先端末を収容する出口側ＥｏＥエッジノードへ転送される。出口側ＥｏＥノードは、ＥｏＥフレームから抽出したイーサネットフレームを配下の端末に転送する。ＲＰＲネットワークにおいてイーサネットフレームがカプセル化されるのと同様に、ＥｏＥネットワークにおいてもイーサネットフレームがカプセル化される。
図１５に示す例では、ＥｏＥノード７００，７１０，７３０，７４０，７５０が、ＥｏＥエッジノードである。また、ＥｏＥノード７６０，７７０がＥｏＥコアノードである。また、インタリンク４５０，４６０，４７０に接続されている各ＥｏＥエッジノード７００，７２０，７５０は、インタリンク接続ノードでもあり、インタリンク接続ノードグループを構成する。
ＥｏＥネットワークは、トポロジがリングに限定されない上、ＳＴＰ（Spanning Tree Protocol）を用いれば、ＥｏＥネットワーク内の経路を冗長化することが可能である。そのため、設定の簡便なイーサネットスイッチによって、耐障害性の高いネットワークを実現可能であるという長所を有している。
なお、ＥｏＥネットワークでは、ＲＰＲのＴｏｐｏｌｏｇｙ Ｄｉｓｃｏｖｅｒｙ Ｐｒｏｔｏｃｏｌのようなトポロジを管理するためのプロトコルや、ＯＡＭといったネットワーク管理用プロトコルは予め定められていない。
図１５におけるＥｏＥネットワーク３０は、ＥｏＥコアノード７６０，７７０の二重化構成によりループを構成しているが、以下の説明では、ＥｏＥネットワーク３０の制御プロトコルとしてＳＴＰを適用することによって、フレーム転送処理時にループの発生を回避しているものとする。
次に、ＥｏＥノードの構成について説明する。ただし、ＥｏＥコアノード７６０，７７０の構成は、一般的なイーサネットスイッチと同様の構成であるので、説明を省略する。
図１６は、ＥｏＥエッジノードの構成例を示すブロック図である。図１６では、ＥｏＥエッジノード７００を例に示しているが、各ＥｏＥエッジノード７００，７１０，７２０，７３０，７４０，７５０の構成は、いずれも同様である。
また、ＥｏＥエッジノードの構成要素のうち、ＲＰＲノードの構成要素と同様の構成要素については、図３と同一の符号を付し、説明を省略する。
ＥｏＥエッジノード７００は、ＲＰＲノードが備えるＲＰＲフレーム生成部５２０（図３参照。）の代わりに、フレーム生成部６４０を備える。また、ＥｏＥエッジノード７００は、ＲＰＲノードが備えるＲＰＲスイッチ処理部５３０の代わりに、スイッチ処理部６５０を備える。また、ＥｏＥエッジノード７００は、ＴＤＢ５６０を備えず、ＥｏＥネットワーク内でのフレーム転送に用いる中継用ＦＤＢ６６０を備える。
なお、図１５および図１６に示す例では、簡単のため、ＥｏＥエッジノード７００が３つのポートＰ１，Ｐ２，Ｐ３を備える場合を示しているが、ＥｏＥエッジノードは、一般のイーサネットスイッチと同様に、４ポート以上のポートを備えていてもよい。
フレーム生成部６４０の動作は、イーサネットフレームをカプセル化するときに、ＲＰＲフレームではなくＥｏＥフレームを生成する点を除き、ＲＰＲフレーム生成部５２０と同様である。
スイッチ処理部６５０の動作は、以下の点を除き、ＲＰＲスイッチ処理部５３０と同様である。ＲＰＲスイッチ処理部５３０と異なる点は、中継用ＦＤＢ６６０を参照してＥｏＥフレームの出力ポートを決定する点と、Ｔｏｐｏｌｏｇｙ Ｄｉｓｃｏｖｅｒｙ ＰｒｏｔｏｃｏｌやＦａｉｒｎｅｓｓ等のＲＰＲのプロトコルの処理を行わない点である。他のフレーム転送処理については、ＲＰＲスイッチ処理部５３０と同様である。
中継用ＦＤＢ６６０は、ＥｏＥネットワーク３０を構成するＥｏＥエッジノードのＭＡＣアドレスとＥｏＥノード７００の出力ポートとの対応関係を登録するデータベースである。スイッチ処理部６５０は、中継用ＦＤＢ６６０を参照して、フレーム生成部６４０によって生成されたＥｏＥフレームの宛先ＭＡＣアドレスと対応付けられた出力ポートを特定し、その出力ポートからＥｏＥフレームを送信する。
図１７は、ＥｏＥノード７００の中継用ＦＤＢ６６０に登録された対応関係の例を示す説明図である。図１７に示す例では、例えば、ＥｏＥノード７１０のＭＡＣアドレスと、出力ポートＰ１とが対応付けられている。従って、例えば、フレーム生成部６４０が、宛先ＭＡＣアドレスにＥｏＥノード７１０のＭＡＣアドレスを設定してＥｏＥフレームを生成した場合、スイッチ処理部６５０は、中継用ＦＤＢ６６０を参照して、ＥｏＥフレームにおける宛先ＭＡＣアドレス（ＥｏＥノード７１０のＭＡＣアドレス）に対応する出力ポートＰ１を検索し、そのＥｏＥフレームを出力ポートＰ１から送信する。
また、スイッチ処理部６５０は、ＥｏＥフレームを受信すると、そのＥｏＥフレームの送信元ＭＡＣアドレスに格納されているＭＡＣアドレスと、そのＥｏＥフレームを受信したポートとの対応関係を中継用ＦＤＢ６６０に登録する。
また、中継用ＦＤＢ６６０には、自ノードの配下の端末のＭＡＣアドレスと自ノードのポートとの対応関係も登録される。ＥｏＥエッジノードが配下の端末からイーサネットフレームを受信した場合、スイッチ処理部６５０は、受信したイーサネットフレームの送信元ＭＡＣアドレスに設定されているＭＡＣアドレスと、そのイーサネットフレームを受信したポートとの対応関係を、中継用ＦＤＢ６６０に登録する。スイッチ処理部６５０は、ＥｏＥフレームにカプセル化されているイーサネットフレームの宛先ＭＡＣアドレスに対応するポートを中継用ＦＤＢ６６０で検索し、そのポートをイーサネットフレームの出力ポートとして決定する。
以上のように、中継用ＦＤＢ６６０は、通常のイーサネットにおけるＭＡＣアドレス学習を行う。
なお、ＦＤＢ５４０も、ＭＡＣアドレス学習を行う。第二の実施の形態では、ＦＤＢ５４０には、ＥｏＥフレームの受信時に、そのＥｏＥフレームにカプセル化されているイーサネットフレームの送信元ＭＡＣアドレスと、そのＥｏＥフレームの送信元ＭＡＣアドレスとの対応関係が登録される。また、フレーム生成部６４０は、イーサネットフレーム受信時に、ＦＤＢ５４０を参照して、イーサネットフレームの宛先ＭＡＣアドレスに対応するＭＡＣアドレスを検索し、そのＭＡＣアドレスをＥｏＥフレームの宛先ＭＡＣアドレスに格納する。
以下の説明において、ＥｏＥネットワーク内のフレームの中継動作については、本発明の動作に深く関わらない限りは、簡潔に説明する。
第２の実施の形態におけるＲＰＲノード配下の端末とＥｏＥエッジノード配下の端末との間のフレーム転送は、第１の実施の形態で説明したＲＰＲノード配下の端末同士のフレーム転送と同様である。すなわち、第１の実施の形態（図１参照）で説明したＲＰＲノード１４０配下の端末とＲＰＲノード２４０配下の端末とのフレーム転送と同様である。
また、図１５に示すＥｏＥネットワーク３０におけるフレーム転送は、ＲＰＲフレームがＥｏＥフレームに変更された点と、ＥｏＥネットワーク３０内でＥｏＥフレームを転送する際に、中継用ＦＤＢ６６０を参照して出力ポートを決定する点を除き、第１の実施の形態で述べたＲＰＲネットワーク１０またはＲＰＲネットワーク２０におけるフレーム転送と同様である。
また、本実施の形態の通信システムの障害発生時および復旧時における動作は、以下に述べる点を除き、第１の実施の形態における障害発生時および復旧時における動作と同様である。
ＥｏＥネットワーク３０では、トポロジを管理するプロトコルが定められていないため、第１の実施形態のインタリンク障害時のフレーム転送で説明した、ＴＤＢ５５０の参照によりアドレスマッピングテーブル６００を更新する態様は、本実施の形態に適用できない。すなわち、インタリンクに対応するポートＰ３の状態を示すＴＰフレームを一定の時間間隔で送信し、そのＴＰフレームを受信したＲＰＲノードがＴＤＢ５６０のポートＰ３の状態を更新すると、アドレスマッピングテーブル管理部６１０が、アドレスマッピングテーブル６００を更新するという態様は、本実施の形態に適用できない。
従って、第２の実施の形態において、インタリンク障害が発生した場合は、そのインタリンクに接続されるインタリンク接続ノードが、特殊ＥｏＥフレームを送信することにより、他のＥｏＥエッジノードのアドレスマッピングテーブル６００の更新を要求する。特殊ＥｏＥフレームは、フレームの形態がＲＰＲフレームではなくＥｏＥフレームであるという点を除き、前述の特殊ＲＰＲフレームと同様のフレームである。
また、ＥｏＥネットワーク３０に属するＥｏＥエッジノードは、ＴＰフレームを一定の時間間隔で送信しない。そのため、第二の実施の形態では、ＴＰフレームが到着しないことを検出することによって、インタリンク接続ノードに障害が発生したことを検出することはできない。
従って、第２の実施の形態では、ＥｏＥネットワーク３０のインタリンク接続ノード７００，７２０，７５０が、一定の時間間隔でキープアライブフレームを送信する。そして、他のＥｏＥエッジノードは、キープアライブフレームが一定時間以上到着しない場合に、インタリンク接続ノードに障害が発生したと判定する。この判定における「一定時間」は、キープアライブフレームの送信時間間隔よりも長く定める。そして、ＥｏＥエッジノードは、障害発生を検出すると、アドレスマッピングテーブル６００を更新する。なお、この場合、インタリンク接続ノード７００，７２０，７５０は、ＥｏＥネットワークに属する各ＥｏＥエッジノードにキープアライブフレームが到達するようにキープアライブフレームを送信する。例えば、キープアライブフレームをブロードキャスト送信する。
以上のように、図１５に示す通信システムにおいても、ＲＰＲネットワークとＥｏＥネットワークとの間のインタリンクを冗長化することにより、信頼性の高い通信システムを実現することができる。
実施の形態３．
図１８は、本実施の形態による通信システムの第３の実施の形態を示す説明図である。ＲＰＲネットワーク１０は、ＲＰＲノード１００〜１７０を備える。図１８に示す例では、ＲＰＲノード１００，１１０，１７０は、共通の端末３００を配下に収容している。従って、ＲＰＲノード１００，１１０，１７０は、インタリンク接続ノードグループを構成するインタリンク接続ノードである。図１８に示す通信システムは、このような構成によりマルチホーミングの構成を実現している。端末３２０，３３０，３４０，３５０，３６０は、それぞれＲＰＲノード１２０，１３０，１４０，１５０，１６０の配下に収容される端末である。
各ＲＰＲノード１００〜１７０の構成は、第１の実施の形態における各ＲＰＲノードの構成（図３参照）と同様である。
本実施の形態におけるＲＰＲノードおよび端末の動作は、以下の点を除き、第１の実施の形態における動作と同様である。本実施の形態では、インタリンク接続ノード（１００，１１０，１７０）の配下に収容される端末３００は、イーサネットフレームをＲＰＲノードに送信するときに、ＲＰＲノード１００，１１０，１７０のうちいずれか１つを選択し、選択したＲＰＲノードにイーサネットフレームを送信する。
端末３００は、少なくとも以下の各条件を満たすＲＰＲノードを選択して、そのＲＰＲノードにイーサネットフレームを送信する。第１の条件は、端末３００を収容するＲＰＲノードに障害が発生していないことである。ＲＰＲノード１００，１１０，１７０のいずれかに障害が発生しているならば、端末３００は、そのＲＰＲノードを選択対象から除外する。第２の条件は、端末３００とＲＰＲノードとのリンクに障害が発生していないことである。例えば、端末３００とＲＰＲノード１００との間のリンクに障害が発生しているならば、端末３００は、ＲＰＲノード１００を選択対象から除外する。他のＲＰＲノードに関しても同様である。第３の条件は、選択対象のＲＰＲノードが、ＲＰＲネットワーク１０に属する他のＲＰＲノードと通信可能であることである。例えば、ＲＰＲノード１７０、１００間のリンクおよびＲＰＲノード１７０、１６０間のリンクのそれぞれに障害が発生しているとする。この場合、ＲＰＲノード１７０は、ＲＰＲネットワーク１０から孤立した状態となることから、自身に障害が発生していなくても、他のＲＰＲノードとＲＰＲフレームを送受信できない。このような場合、端末３００は、ＲＰＲノード１７０を選択対象から除外する。
端末３００は、各ＲＰＲノードとの間のリンクにおける障害発生を、ＲＰＲノードと同様に検出すればよい。すなわち、端末３００は、ポート状態監視部６２０と同様の装置を備え、ポートの状態を監視することによりリンクにおける障害発生を検出すればよい。
また、各ＲＰＲノード１００，１１０，１７０は、端末３００に対して一定期間毎にキープアライブフレームを送信し、端末３００は、一定期間を越えてもキープアライブフレームが到着しないときに、ＲＰＲノードに障害が発生したと判定すればよい。
また、ＲＰＲノード１００，１１０，１７０は、ＲＰＲネットワーク１０に属する他のＲＰＲノードと通信不可能になった場合には、その旨を示す情報を端末３００に送信すればよい。例えば、ＲＰＲノード１７０，１６０間のリンクおよびＲＰＲノード１７０，１００間のリンクの両方に障害が発生した場合、ＲＰＲノード１７０は、その旨の情報を端末３００に送信すればよい。
上記の端末３００の機能は、端末３００のポートＰ１〜Ｐ３にリングアグリゲーション（ＬＡＧ）を適用することにより容易に実現することができる。図１８に示す例では、端末３００のポートＰ１，Ｐ２，Ｐ３は、それぞれＲＰＲノード１００，１１０，１７０との間のリンクに接続されるポートである。
また、選択可能なＲＰＲノードが複数存在する場合、端末３００は、ラウンドロビンや重み付けラウンドロビンによってＲＰＲノード１０，１１０，１７０のいずれかを選択してもよい。あるいは、端末３００が送信しようとするイーサネットフレームに含まれるパラメータ値に応じてＲＰＲノード１０，１１０，１７０のいずれかを選択してもよい。
図１８では、ＲＰＲネットワーク１０の複数のＲＰＲノードが配下に共通の端末３００を収容している場合を示したが、この構成に替えて、ＥｏＥネットワークに属する複数のＥｏＥエッジノードが配下に共通の端末を収容している構成であってもよい。
以上のように、ＲＰＲネットワーク間を接続するインタリンクの冗長化のみではなく、ＲＰＲネットワークおよび端末間のリンクの冗長化についても、本発明を適用することにより実現することが可能である。
また、上記の各実施の形態では、ＲＰＲノードやＥｏＥノードが、フレーム解析部５１０−１，５１０−２などの各処理部を備える構成として説明したが、ＲＰＲノードやＥｏＥノードが、コンピュータを備え、そのコンピュータがプログラムに従って、図３や図１６に示す各処理部と同様の動作をする構成であってもよい。プログラムは、ノードが備える記憶装置に予め記憶させておけばよい。

特許請求の範囲に記載されたデータベースは、ＦＤＢ５４０によって実現される。また、検索手段、アドレス決定手段、フレーム生成手段、生成手段は、ＲＰＲフレーム生成部５２０（またはフレーム生成部６４０）によって実現される。また、システム内通信用フレーム送信手段、信号送信手段、送信可否判定手段、禁止手段、ブロードキャスト受信時送信可否判定手段、送信手段は、ＲＰＲスイッチ処理部５３０（またはスイッチ処理部６５０）によって実現される。リンク状態監視手段は、ポート状態監視部６２０によって実現される。リンク障害通知手段５３０は、ＲＰＲスイッチ処理部５３０によって実現される。端末フレーム送信手段、ブロードキャスト受信時端末フレーム送信手段は、イーサネットフレーム抽出部５７０によって実現される。

Claims (24)

  1. 同一のネットワーク上に設けられ、他のネットワークと接続するためのリンク接続ノードグループに属することを示す共通の仮想アドレスが割り当てられた複数の第１のノードと、前記同一のネットワーク上にあって端末フレームを送受信する端末が接続され、且つ、前記リンク接続ノードグループには属さない第２のノードとを有するネットワークを複数備え、
    前記各ネットワークの前記リンク接続ノードグループに属する複数の第１のノードと、他のネットワークの前記リンク接続ノードグループに属する複数の第１のノードとが、それぞれリンクを介して接続され、
    前記各ネットワークの第２のノードは、ノードの物理アドレスまたは仮想アドレスと端末のアドレスとの対応関係を端末フレームの転送履歴に基づきデータベースに記録するデータベース管理部と、端末から受信した端末フレームを格納したネットワークフレームを生成するフレーム生成部と、ネットワークフレームを自ノードのネットワークに送信するスイッチ処理部とを有し、
    前記フレーム生成部は、前記端末から受信した前記端末フレームの宛先に対応するアドレスを前記データベースから検索し、検索されたアドレスが前記仮想アドレスである場合に自ノードのネットワーク上の前記複数の第１のノードのうち前記他のネットワークとの通信が可能な前記第１のノードを選択対象とし、選択対象とした第１のノードの物理アドレスのいずれか１つを、前記受信した前記端末フレームに含まれている所定のパラメータに基づいて前記ネットワークフレームの宛先として決定し、
    前記宛先として決定された第１のノードは、前記ネットワークフレームを受信し、前記他のネットワークに受信したネットワークフレームを送信することを特徴とする通信システム。
  2. 前記フレーム生成部は、他のネットワークとのリンクが正常な第１のノードを認識し該第１のノードの物理アドレスを当該ネットワークフレームの宛先となるアドレスとして決定することを特徴とする請求項１記載の通信システム。
  3. 前記第１のノードは、他のネットワークとのリンクの状態を監視する監視部と、前記リンクに障害が発生したときにネットワークフレームの宛先の候補から自ノードを除外するよう指示する情報を他のノードに通知するアドレス管理部とを有することを特徴とする請求項２記載の通信システム。
  4. 前記フレーム生成部は、隣接ノードとの通信状態が正常な第１のノードを認識し該第１のノードの物理アドレスを当該ネットワークフレームの宛先となるアドレスとして決定することを特徴とする請求項１乃至３のいずれか１項に記載の通信システム。
  5. 前記第１のノードは、隣接ノードとの通信状態を監視する監視部と、隣接ノードとの通信に障害が発生したときにネットワークフレームの宛先の候補から自ノードを除外するよう指示する情報を他のノードに通知するアドレス管理部とを有することを特徴とする請求項４記載の通信システム。
  6. 同一のネットワーク上に設けられ、他のネットワークと接続するためのリンク接続ノードグループに属することを示す共通の仮想アドレスが割り当てられた複数の第１のノードと、前記同一のネットワーク上にあって端末フレームを送受信する端末が接続され、且つ、前記リンク接続ノードグループには属さない第２のノードとを有するネットワークを複数備え、
    前記各ネットワークの前記リンク接続ノードグループに属する複数の第１のノードと、他のネットワークの前記リンク接続ノードグループに属する複数の第１のノードとが、それぞれリンクを介して接続され、
    前記各ネットワークの第２のノードは、ノードの物理アドレスまたは仮想アドレスと端末のアドレスとの対応関係を端末フレームの転送履歴に基づきデータベースに記録するデータベース管理部と、端末から受信した端末フレームを格納したネットワークフレームを生成するフレーム生成部と、ネットワークフレームを自ノードのネットワークに送信するスイッチ処理部とを有し、
    前記フレーム生成部は、前記端末から受信した前記端末フレームの宛先に対応するアドレスを前記データベースから検索し、検索されたアドレスが前記仮想アドレスである場合に前記仮想アドレスを割り当てられた全ての第１のノードに対するマルチキャスト通信の宛先を前記ネットワークフレームの宛先に設定し、
    前記複数の第１のノードには、それぞれ前記ネットワークフレームを前記他のネットワークに送信することを示すパラメータ値が設定され、且つ、前記パラメータ値は前記複数の第１のノード間で重ならないように設定され、
    前記複数の第１のノードは、マルチキャスト通信の宛先が設定された前記ネットワークフレームを受信し、受信した前記ネットワークフレームに含まれているパラメータ値または前記ネットワークフレームに格納されている前記端末フレームに含まれているパラメータ値と自己の第１のノードに設定されたパラメータ値との比較結果に基づいて、前記端末フレームを送出するか否かの判定を行うスイッチ処理部を有し、
    他のネットワークとの通信が可能な前記複数の第１のノードのいずれか１つが、前記判定の結果に基づいて前記端末フレームを前記他のネットワークに送信することを特徴とする通信システム。
  7. 前記第１のノードのスイッチ処理部は、自ノードが属する前記リンク接続ノードグループの仮想アドレスが送信元アドレスとして設定され、且つ、ブロードキャスト通信のアドレスが宛先アドレスとして設定されたネットワークフレームを受信したとき、このネットワークフレームに格納されている端末フレームを他のネットワークとのリンクに送出しないと判定することを特徴とする請求項６記載の通信システム。
  8. 前記第１のノードのスイッチ処理部は、ブロードキャスト通信のアドレスが宛先アドレスとして設定され、且つ、第２のノードの物理アドレスが送信元アドレスとして設定されたネットワークフレームを受信したとき、前記ネットワークフレームに格納されている端末フレームを他のネットワークとのリンクに送出するか否かを判定し、
    前記リンク接続ノードグループに属する第１のノードのうちのいずれか１つの前記スイッチ処理部が、前記端末フレームを送出すると判定することを特徴とする請求項６又は７に記載の通信システム。
  9. 前記第１のノードのスイッチ処理部は、ブロードキャスト通信のアドレスが宛先アドレスとして設定され、且つ、第２のノードの物理アドレスが送信元アドレスとして設定されたネットワークフレームに含まれているパラメータ値または前記ネットワークフレームに格納されている前記端末フレームに含まれているパラメータ値に基づいて、前記端末フレームをリンクに送出するか否かを判定することを特徴とする請求項８記載の通信システム。
  10. 前記端末フレームをリンクへ送出する第１のノードは、他のネットワークとのリンクが正常であり且つ前記リンク接続ノードグループに属する前記複数の第１のノードのうちのいずれか１つであることを特徴とする請求項８又は９記載の通信システム。
  11. 前記第１のノードは、自ノードに割り当てられた共通の仮想アドレスを送信元に設定し、且つ、他のネットワークのリンクから受信した端末フレームを格納したネットワークフレームを生成するフレーム生成部を有し、
    前記第１のノードのスイッチ処理部は、前記フレーム生成部により生成されたネットワークフレームを自ノードのネットワークに送信することを特徴とする請求項１乃至１０のいずれか１項に記載の通信システム。
  12. 前記複数のネットワークのうちのいずれかがＲＰＲ（Resilient Packet Ring）ネットワークまたはＥｏＥ（Ethernet over Ethernet）ネットワークであることを特徴とする請求項１乃至１１のいずれか１項に記載の通信システム。
  13. 前記複数のネットワークのそれぞれがＲＰＲネットワークまたはＥｏＥネットワークであることを特徴とする請求項１乃至１１のいずれか１項に記載の通信システム。
  14. 前記第１のノードは、他のネットワークの第１のノードと一対一に接続されることを特徴とする請求項１乃至１３のいずれか１項に記載の通信システム。
  15. 前記リンク接続ノードグループに属する各第１のノードとの間にリンクが設定された端末を備え、前記端末は、前記リンク接続ノードグループのいずれかの第１のノードに対し端末フレームを送受信することを特徴とする請求項１乃至１２のいずれか１項に記載の通信システム。
  16. 前記端末は、端末フレームに設定されたパラメータ値に基づいて前記端末フレームを送信すべき第１のノードを決定することを特徴とする請求項１５記載の通信システム。
  17. 前記端末は、隣接ノードとの通信状態が正常な第１のノードを認識し該ノードを端末フレームを送信すべき第１のノードとして決定することを特徴とする請求項１５又は１６記載の通信システム。
  18. 前記第１のノードは、自ノードとの間にリンクが設定されている端末に対し、自ノードと隣接ノードとの通信状態を示す情報を通知することを特徴とする請求項１７記載の通信システム。
  19. 同一のネットワーク上に設けられ、他のネットワークと接続するためのリンク接続ノードグループに属することを示す共通の仮想アドレスが割り当てられた複数の第１のノードと、前記同一のネットワーク上にあって端末フレームを送受信する端末が接続され、且つ、前記リンク接続ノードグループには属さない第２のノードとを有するネットワークを複数備えるシステムの通信方法であって、
    前記各ネットワークの前記リンク接続ノードグループに属する複数の第１のノードと、他のネットワークの前記リンク接続ノードグループに属する複数の第１のノードとが、それぞれリンクを介して接続され、
    前記各ネットワークの第２のノードは、
    ノードの物理アドレスまたは仮想アドレスと端末のアドレスとの対応関係を端末フレームの転送履歴に基づきデータベースに記録し、端末から受信した端末フレームを格納したネットワークフレームを生成し、前記端末から受信した前記端末フレームの宛先に対応するアドレスを前記データベースから検索し、検索されたアドレスが前記仮想アドレスである場合に自ノードのネットワーク上の前記複数の第１のノードのうち前記他のネットワークとの通信が可能な前記第１のノードを選択対象とし、選択対象とした第１のノードの物理アドレスのいずれか１つを、前記受信した前記端末フレームに含まれている所定のパラメータに基づいて前記ネットワークフレームの宛先として決定し、
    前記宛先として決定された第１のノードは、前記ネットワークフレームを受信し、前記他のネットワークに受信したネットワークフレームを送信することを特徴とする通信方法。
  20. 同一のネットワーク上に設けられ、他のネットワークと接続するためのリンク接続ノードグループに属することを示す共通の仮想アドレスが割り当てられた複数の第１のノードと、前記同一のネットワーク上にあって端末フレームを送受信する端末が接続され、且つ、前記リンク接続ノードグループには属さない第２のノードとを有するネットワークを複数備えるシステムの通信方法であって、
    前記各ネットワークの前記リンク接続ノードグループに属する複数の第１のノードと、他のネットワークの前記リンク接続ノードグループに属する複数の第１のノードとが、それぞれリンクを介して接続され、
    前記各ネットワークの第２のノードは、ノードの物理アドレスまたは仮想アドレスと端末のアドレスとの対応関係を端末フレームの転送履歴に基づきデータベースに記録し、端末から受信した端末フレームを格納したネットワークフレームを生成し、前記端末から受信した前記端末フレームの宛先に対応するアドレスを前記データベースから検索し、検索されたアドレスが前記仮想アドレスである場合に前記仮想アドレスを割り当てられた全ての第１のノードに対するマルチキャスト通信の宛先を前記ネットワークフレームの宛先に設定し、
    前記複数の第１のノードには、それぞれ前記ネットワークフレームを前記他のネットワークに送信することを示すパラメータ値が設定され、且つ、前記パラメータ値は前記複数の第１のノード間で重ならないように設定され、
    前記複数の第１のノードは、マルチキャスト通信の宛先が設定された前記ネットワークフレームを受信し、受信した前記ネットワークフレームに含まれているパラメータ値または前記ネットワークフレームに格納されている前記端末フレームに含まれているパラメータ値と自己の第１のノードに設定されたパラメータ値との比較結果に基づいて、前記端末フレームを他のネットワークとのリンクに送出するか否かの判定を行い、
    他のネットワークとの通信が可能な前記複数の第１のノードのいずれか１つが、前記判定の結果に基づいて前記端末フレームを前記他のネットワークに送信することを特徴とする通信方法。
  21. 同一のネットワーク上に設けられ、他のネットワークと接続するためのリンク接続ノードグループに属することを示す共通の仮想アドレスが割り当てられ、且つ、他のネットワークの前記リンク接続グループに属する複数の第１のノードに対して、それぞれリンクを介して接続された複数の第１のノードと、前記同一のネットワーク上にあって端末フレームを送受信する端末が接続され、且つ、前記リンク接続ノードグループには属さない第２のノードとを有するネットワークを複数備えるシステムの前記第２のノードとしてのノードであって、
    ノードの物理アドレスまたは仮想アドレスと端末のアドレスとの対応関係を端末フレームの転送履歴に基づきデータベースに記録するデータベース管理部と、端末から受信した端末フレームを格納したネットワークフレームを生成するフレーム生成部と、ネットワークフレームを自ノードのネットワークに送信するスイッチ処理部とを有し、
    前記フレーム生成部は、前記端末から受信した前記端末フレームの宛先に対応するアドレスを前記データベースから検索し、検索されたアドレスが前記仮想アドレスである場合に自ノードのネットワーク上の前記複数の第１のノードのうち前記他のネットワークとの通信が可能な前記第１のノードを選択対象とし、選択対象とした第１のノードの物理アドレスのいずれか１つを、前記受信した前記端末フレームに含まれている所定のパラメータに基づいて前記ネットワークフレームの宛先として決定することを特徴とするノード。
  22. 同一のネットワーク上に設けられ、他のネットワークと接続するためのリンク接続ノードグループに属することを示す共通の仮想アドレスが割り当てられ、且つ、他のネットワークの前記リンク接続グループに属する複数の第１のノードに対して、それぞれリンクを介して接続された複数の第１のノードと、前記同一のネットワーク上にあって端末フレームを送受信する端末が接続され、且つ、前記リンク接続ノードグループには属さない第２のノードとを有するネットワークを複数備えるシステムの前記第１のノードとしてのノードであって、
    前記複数のノードには、それぞれ前記ネットワークフレームを前記他のネットワークに送信することを示すパラメータ値が設定され、且つ、前記パラメータ値は前記複数の第１のノード間で重ならないように設定され、
    自ノードが属するリンク接続グループに対するマルチキャスト通信の宛先が設定された前記ネットワークフレームを受信し、受信した前記ネットワークフレームに含まれているパラメータ値または前記ネットワークフレームに格納されている前記端末フレームに含まれているパラメータ値と自己の第１のノードに設定されたパラメータ値との比較結果に基づいて、前記端末フレームを他のネットワークとのリンクに送出するか否かの判定を行うスイッチ処理部を有し、
    他のネットワークとの通信が可能な前記複数の第１のノードのいずれか１つが、前記判定の結果に基づいて前記端末フレームを前記他のネットワークに送信することを特徴とするノード。
  23. 同一のネットワーク上に設けられ、他のネットワークと接続するためのリンク接続ノードグループに属することを示す共通の仮想アドレスが割り当てられ、且つ、他のネットワークの前記リンク接続グループに属する複数の第１のノードに対して、それぞれリンクを介して接続された複数の第１のノードと、前記同一のネットワーク上にあって端末フレームを送受信する端末が接続され、且つ、前記リンク接続ノードグループには属さない第２のノードとを有するネットワークを複数備えるシステムの前記第２のノードとしてのノードのためのプログラムであって、
    前記ノードを、
    ノードの物理アドレスまたは仮想アドレスと端末のアドレスとの対応関係を端末フレームの転送履歴に基づきデータベースに記録するデータベース管理手段と、
    端末から受信した端末フレームを格納したネットワークフレームを生成するフレーム生成手段と、
    前記ネットワークフレームを自ノードのネットワークに送信するスイッチ処理部として機能させ、
    前記フレーム生成部を、前記端末から受信した前記端末フレームの宛先に対応するアドレスを前記データベースから検索し、検索されたアドレスが前記仮想アドレスである場合に自ノードのネットワーク上の前記複数の第１のノードのうち前記他のネットワークとの通信が可能な第１のノードを選択対象とし、選択対象とした第１のノードの物理アドレスのいずれか１つを、前記受信した前記端末フレームに含まれている所定のパラメータに基づいて前記ネットワークフレームの宛先として決定する手段と、
    して機能させるためのプログラム。
  24. 同一のネットワーク上に設けられ、他のネットワークと接続するためのリンク接続ノードグループに属することを示す共通の仮想アドレスが割り当てられ、且つ、他のネットワークの前記リンク接続グループに属する複数の第１のノードに対して、それぞれリンクを介して接続された複数の第１のノードと、前記同一のネットワーク上にあって端末フレームを送受信する端末が接続され、且つ、前記リンク接続ノードグループには属さない第２のノードとを有するネットワークを複数備えるシステムの前記第１のノードとしてのノードのためのプログラムであって、
    前記複数のノードには、それぞれ前記ネットワークフレームを前記他のネットワークに送信することを示すパラメータ値が設定され、且つ、前記パラメータ値は前記複数の第１のノード間で重ならないように設定され、
    前記ノードを、
    自ノードが属するリンク接続グループに対するマルチキャスト通信の宛先が設定された前記ネットワークフレームを受信し、受信した前記ネットワークフレームに含まれているパラメータ値または前記ネットワークフレームに格納されている前記端末フレームに含まれているパラメータ値と自己の第１のノードに設定されたパラメータ値との比較結果に基づいて、前記端末フレームを他のネットワークとのリンクに送出するか否かの判定を行うスイッチ処理手段と、
    他のネットワークとの通信が可能な前記複数の第１のノードのいずれか１つを、前記判定の結果に基づいて前記端末フレームを前記他のネットワークに送信する手段と、
    して機能させるためのプログラム。
JP2007553006A 2006-01-06 2007-01-05 通信システム、通信方法、ノード、およびノード用プログラム Active JP4836008B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2007553006A JP4836008B2 (ja) 2006-01-06 2007-01-05 通信システム、通信方法、ノード、およびノード用プログラム

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2006001768 2006-01-06
JP2006001768 2006-01-06
JP2007553006A JP4836008B2 (ja) 2006-01-06 2007-01-05 通信システム、通信方法、ノード、およびノード用プログラム
PCT/JP2007/050034 WO2007077998A1 (ja) 2006-01-06 2007-01-05 通信システム、通信方法、ノード、およびノード用プログラム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2011177590A Division JP5334001B2 (ja) 2006-01-06 2011-08-15 通信システムおよびノード

Publications (2)

Publication Number Publication Date
JPWO2007077998A1 JPWO2007077998A1 (ja) 2009-06-11
JP4836008B2 true JP4836008B2 (ja) 2011-12-14

Family

ID=38228334

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2007553006A Active JP4836008B2 (ja) 2006-01-06 2007-01-05 通信システム、通信方法、ノード、およびノード用プログラム
JP2011177590A Active JP5334001B2 (ja) 2006-01-06 2011-08-15 通信システムおよびノード

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2011177590A Active JP5334001B2 (ja) 2006-01-06 2011-08-15 通信システムおよびノード

Country Status (4)

Country Link
US (1) US9461841B2 (ja)
JP (2) JP4836008B2 (ja)
CN (1) CN101366243B (ja)
WO (1) WO2007077998A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011229188A (ja) * 2006-01-06 2011-11-10 Nec Corp 通信システムおよびノード

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080159277A1 (en) * 2006-12-15 2008-07-03 Brocade Communications Systems, Inc. Ethernet over fibre channel
US20080181243A1 (en) * 2006-12-15 2008-07-31 Brocade Communications Systems, Inc. Ethernet forwarding in high performance fabrics
US8583780B2 (en) * 2007-11-20 2013-11-12 Brocade Communications Systems, Inc. Discovery of duplicate address in a network by reviewing discovery frames received at a port
US8108454B2 (en) * 2007-12-17 2012-01-31 Brocade Communications Systems, Inc. Address assignment in Fibre Channel over Ethernet environments
US20090296726A1 (en) * 2008-06-03 2009-12-03 Brocade Communications Systems, Inc. ACCESS CONTROL LIST MANAGEMENT IN AN FCoE ENVIRONMENT
JP5018716B2 (ja) * 2008-09-29 2012-09-05 富士通株式会社 アプリケーション間通信の高信頼化技術
US8848575B2 (en) 2009-02-23 2014-09-30 Brocade Communications Systems, Inc. High availability and multipathing for fibre channel over ethernet
CN101834772B (zh) * 2009-03-13 2013-11-06 中兴通讯股份有限公司 一种基于以太环网的介质访问控制地址分类方法和装置
JP5381194B2 (ja) * 2009-03-16 2014-01-08 富士通株式会社 通信プログラム、中継ノード、および通信方法
WO2010116406A1 (ja) * 2009-04-06 2010-10-14 三菱電機株式会社 マルチリングネットワークシステム、リングノード装置および負荷分散方法
EP2491685B1 (en) * 2009-10-21 2018-12-05 Telefonaktiebolaget LM Ericsson (publ) Resource reservation in multiple accesses
US8655909B2 (en) * 2010-02-25 2014-02-18 Mitsubishi Electric Corporation Communication apparatus and address learning method
US8593973B2 (en) 2010-03-09 2013-11-26 Juniper Networks, Inc. Communicating network path and status information in multi-homed networks
JP5521663B2 (ja) * 2010-03-15 2014-06-18 富士通株式会社 通信装置、通信システムおよび通信方法
US8625596B1 (en) 2010-09-28 2014-01-07 Juniper Networks, Inc. Multi-chassis topology discovery using in-band signaling
US9356799B2 (en) * 2011-06-28 2016-05-31 Broadcom Corporation Ethernet ring protection without MAC table flushing
CN103368839A (zh) * 2012-04-01 2013-10-23 中兴通讯股份有限公司 一种抑制sdh业务广播风暴的方法及装置
KR101392558B1 (ko) * 2012-11-02 2014-05-27 엘에스산전 주식회사 확장형 이더넷 링 네트워크
KR101978173B1 (ko) * 2013-01-18 2019-05-14 삼성전자주식회사 컨텐츠 중심 네트워크에서 컨텐츠 제공자가 데이터 패킷을 전송하는 방법 및 그 컨텐츠 제공자
EP3001609B1 (en) 2013-06-28 2017-08-09 Huawei Technologies Co., Ltd. Method and device for processing multicast message in nvo3 network, and nvo3 network
GB2524750B (en) * 2014-03-31 2021-04-21 Metaswitch Networks Ltd Spanning tree protocol
US9703738B2 (en) 2014-06-24 2017-07-11 Palo Alto Research Center Incorporated Computing system framework with unified storage, processing, and network switching fabrics incorporating network switches and method for making and using the same
CN104283790B (zh) * 2014-10-09 2017-09-15 新华三技术有限公司 Sdn中弹性分组环rpr的拓扑发现方法和设备
CN106789520B (zh) * 2016-12-26 2019-11-22 中核控制系统工程有限公司 一种高速故障安全多节点通信网络
JP7226166B2 (ja) * 2019-07-22 2023-02-21 株式会社デンソー 中継装置および車載通信ネットワーク
CN110933730B (zh) * 2019-11-27 2021-09-03 美的集团股份有限公司 确定多跳网络节点生存时间值的方法及装置
WO2021171601A1 (ja) * 2020-02-28 2021-09-02 日本電信電話株式会社 ネットワーク装置、ネットワークシステム及びプログラム
US11870672B2 (en) * 2020-04-16 2024-01-09 Ivanti, Inc. Self-election processes in managed subnets implementing modified swim protocols

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005027427A1 (ja) * 2003-09-10 2005-03-24 Fujitsu Limited ノード冗長方法、インタフェースカード、インタフェースデバイス、ノード装置およびパケットリングネットワークシステム

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH01161947A (ja) 1987-12-18 1989-06-26 Hitachi Ltd 多重ブリツジ方式
JP3599476B2 (ja) 1995-09-25 2004-12-08 古河電気工業株式会社 ネットワーク間接続方法
US5859836A (en) * 1996-07-29 1999-01-12 At&T Corp Alternate ring restoration technique
JP2000004248A (ja) 1998-03-30 2000-01-07 Toshiba Corp 通信ネットワ―クシステム
JP4183871B2 (ja) 2000-01-26 2008-11-19 株式会社日立製作所 負荷分散方法及び装置
JP2003023444A (ja) 2001-07-06 2003-01-24 Fujitsu Ltd 仮想ルータを利用した動的な負荷分散システム
EP1324542A1 (en) * 2001-12-26 2003-07-02 Alcatel Method for interconnecting a number of RPR rings in a wide area RPR network
US7383354B2 (en) * 2002-02-12 2008-06-03 Fujitsu Limited Spatial reuse and multi-point interconnection in bridge-interconnected ring networks
JP2003258822A (ja) 2002-02-27 2003-09-12 Nec Corp パケットリングネットワーク及びそれに用いるパケットリングネットワーク間の接続方法
US20030208525A1 (en) * 2002-05-06 2003-11-06 Vinay Bannai System and method for providing transparent lan services
JP4056864B2 (ja) 2002-11-26 2008-03-05 富士通株式会社 中継装置
JP4052956B2 (ja) * 2003-02-07 2008-02-27 富士通株式会社 Ｒｐｒネットワークシステム，ステーションノード，ブリッジノード及びｒｐｒカード
CN100428725C (zh) * 2003-06-20 2008-10-22 华为技术有限公司 一种实现对数据业务传输路径选择的方法
CN1299469C (zh) * 2003-08-06 2007-02-07 中兴通讯股份有限公司 一种基于业务等级交换的交换系统及其交换方法
JP4287734B2 (ja) 2003-11-21 2009-07-01 三菱電機株式会社 ネットワーク装置
JP4459018B2 (ja) * 2004-10-28 2010-04-28 富士通株式会社 ノード装置
US20060106968A1 (en) * 2004-11-15 2006-05-18 Wooi Teoh Gary C Intelligent platform management bus switch system
US7974223B2 (en) * 2004-11-19 2011-07-05 Corrigent Systems Ltd. Virtual private LAN service over ring networks
JP4526423B2 (ja) * 2005-03-17 2010-08-18 富士通株式会社 リング間接続方法及び装置
JP4836008B2 (ja) * 2006-01-06 2011-12-14 日本電気株式会社 通信システム、通信方法、ノード、およびノード用プログラム

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005027427A1 (ja) * 2003-09-10 2005-03-24 Fujitsu Limited ノード冗長方法、インタフェースカード、インタフェースデバイス、ノード装置およびパケットリングネットワークシステム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011229188A (ja) * 2006-01-06 2011-11-10 Nec Corp 通信システムおよびノード

Also Published As

Publication number Publication date
JPWO2007077998A1 (ja) 2009-06-11
CN101366243B (zh) 2012-02-08
US20090268746A1 (en) 2009-10-29
JP2011229188A (ja) 2011-11-10
JP5334001B2 (ja) 2013-11-06
CN101366243A (zh) 2009-02-11
US9461841B2 (en) 2016-10-04
WO2007077998A1 (ja) 2007-07-12

Similar Documents

Publication Publication Date Title
JP4836008B2 (ja) 通信システム、通信方法、ノード、およびノード用プログラム
JP4743201B2 (ja) パケットリングネットワークシステム、パケットリング間の接続方法、およびリング間接続ノード
JP5158369B2 (ja) 通信システム、ノード、端末、通信方法、およびプログラム
US7619987B2 (en) Node device
JP5152642B2 (ja) パケットリングネットワークシステム、パケット転送方法、およびノード
JP4900878B2 (ja) リングネットワークシステム、障害回復方法、障害検出方法、ノード、およびノード用プログラム
EP1468528B1 (en) Method and apparatus for priority-based load balancing for use in an extended local area network
JP5661929B2 (ja) マルチシャーシリンクアグリゲーションのためのシステムおよび方法
US7826400B2 (en) Packet ring network system and packet transport method
KR101563102B1 (ko) 가상 패브릭 링크 고장 복구를 위한 시스템 및 방법
US7876673B2 (en) Prevention of frame duplication in interconnected ring networks
JP4790591B2 (ja) リングノード装置
US8243741B2 (en) Frame switching device and address learning method
JP2003526277A (ja) デュアル・モードによる仮想ネットワーク・アドレス指定方式
WO2005027427A1 (ja) ノード冗長方法、インタフェースカード、インタフェースデバイス、ノード装置およびパケットリングネットワークシステム
JP2008167315A (ja) 回線冗長接続方法および広域通信網ノード装置
US20150172173A1 (en) Communication system, communication apparatus and path switching method
JP5029612B2 (ja) パケットリングネットワークシステム、パケット転送方法およびインタリンクノード
JP2007243288A (ja) 通信システム、ノード、通信方法、およびノード用プログラム
JP4299658B2 (ja) ネットワーク制御システム及び制御方法
JP2009147653A (ja) 通信システムおよびリングノード装置
JP2009077285A (ja) パケットリングネットワークシステム、およびフォワーディングデータベース管理方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20091214

RD03 Notification of appointment of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7423

Effective date: 20101015

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20101015

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20101018

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20101217

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20110224

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110523

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20110530

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110615

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110815

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110902

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110915

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

Free format text: PAYMENT UNTIL: 20141007

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4836008

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150