(57)【要約】【課題】レイヤ２の拡張タグネットワークにおいて、マルチキャストフレームを転送する際に、カスタマと関係ある経路のみにフレームを転送し、それにより効率的なマルチキャスト転送を行うことを可能にするマルチキャスト制御方法を提供する。【解決手段】独立して動作する複数のスパニングツリーを用いる拡張タグネットワークで、マルチキャストフレームの送信元ノードが既知の特殊の制御メッセージを生成して、送信元ノードがルートノードになるスパニングツリーを沿ってブロードキャストし、同じマルチキャストグループカスタマがいるエッジノードからルートノードに制御メッセージを返信し、その制御メッセージを受信するノードはその制御メッセージを学習してマルチキャストテーブルの対応エントリを更新するなどのマルチキャストテーブル作成方法及びそのマルチキャストテーブルを参照してマルチキャストフレームを転送する方法によって、マルチキャスト制御を行う。【特許請求の範囲】
【請求項１】
複数のノードからなるネットワーク上で、前記ノードに収容されたホスト間でマルチキャストによってフレームの転送を行うネットワークにおいて、
第１のノードが、他ノードに対して自ノードが収容するホストと同じグループに属するホストが存在するかを問い合わせる問い合わせメッセージをブロードキャストにより送信し、
前記第１のノードと同じグループに属するホストを収容するノードが、前記第１のノードに対し、前記問い合わせメッセージに対する応答メッセージを返送信し、
前記第１のノード、前記応答メッセージを中継するノードが、前記応答メッセージを受信したポートと前記グループの情報とを対応付けたマルチキャストテーブルを作成することを特徴とするネットワーク。
【請求項２】
前記フレームをマルチキャスト転送する際に、各ノードが、前記マルチキャストテーブルを参照することにより、前記フレームが同じグループに属するホストを収容するノードのみに転送することを特徴とする請求項１記載のネットワーク。
【請求項３】
前記第１のノードは、前記問い合わせメッセージを、自身がルートノードとなるスパニングツリーに沿ってブロードキャストにより送信することを特徴とする請求項１または２に記載のネットワーク。
【請求項４】
前記応答メッセージは、前記第１のノードをルートノードとするスパニングツリーに沿って送信されることを特徴とする請求項１から請求項３のいずれか１項に記載のネットワーク
【請求項５】
前記マルチキャストテーブルは、各ツリーのルートノードとなる前記第１のノードの識別子毎に、前記グループの情報と、マルチキャストフレームを転送する前記ポートを記録して構成されることを特徴とする請求項１から請求項４の何れか１項に記載のネットワーク。
【請求項６】
前記中継ノードでは、前記複数のスパニングツリー毎に、前記マルチキャストテーブルを作成することを特徴とする請求項１から請求項５の何れか１項に記載のネットワーク。
【請求項７】
前記第１のノードが、前記グループが追加又は削除される時に、前記問い合わせメッセージに、前記グループの情報と、前記グループの追加又は削除の種別を示す情報を含むグループ情報を格納してブロードキャストにより送信することを特徴とする請求項１から請求項６の何れか１項に記載のネットワーク。
【請求項８】
前記エッジノード、前記中継するノードが、前記グループの情報に前記グループの削除を指定する情報を含む前記問い合わせメッセージを受信することにより、前記マルチキャストテーブルから、前記グループの情報に対応するエントリをクリアすることを特徴とする請求項７に記載のネットワーク。
【請求項９】
拡張タグ情報を含むフレームの拡張タグ格納領域に、ブロードキャストフォワーディングタグとグループの情報を示すタグが格納されている場合に、前記フレームをマルチキャストにより転送するフレームと認識することを特徴とする請求項１から請求項８の何れか１項に記載のネットワーク。
【請求項１０】
前記ノードが、前記グループが追加又は削除された場合に、前記問い合わせメッセージを生成し、かつ前記問い合わせメッセージに対する前記応答メッセージを生成すると共に、
受信した前記応答メッセージに基づいて前記マルチキャストテーブルを作成するマルチキャスト制御部を備えることを特徴とする請求項１から請求項９の何れか１項に記載のネットワーク。
【請求項１１】
前記エッジノードが、前記応答メッセージの送信後に、自ノードが収容するグループと同じグループに属するホストが存在するかを問い合わせるための第２の問い合わせメッセージを、自身がルートノードとなるスパニングツリーに沿ってブロードキャストにより送信し、
前記エッジノードと同じグループに属するホストを収容する前記第１のノードから、前記エッジノードに対し、前記第２の問い合わせメッセージに対する第２の応答メッセージを返信し、
前記第１のノード、前記エッジノード、前記中継するノードが、前記第２の応答メッセージを受信したポートと前記第２の問い合わせメッセージに含まれるグループの情報とを対応付けた情報によって、前記マルチキャストテーブルを更新することを特徴とする請求項１から請求項１０の何れか１項に記載のネットワーク。
【請求項１２】
同じグループを収容する複数のツリーのうちの１つのツリーについて、前記応答メッセージを受信したポートと前記グループの情報とを対応付けた全ての前記第１のノード間で共有する共有マルチキャストテーブルを作成し、
前記第１のノードは、前記共有マルチキャストテーブルと、前記拡張タグ付きフレームをブロードキャストする経路を示すテーブルとを参照して、前記フレームをマルチキャスト転送することを特徴とする請求項１に記載のネットワーク。
【請求項１３】
前記第１のノードは、前記共有マルチキャストテーブルと、前記拡張タグ付きフレームをブロードキャストする経路を示すテーブルとの論理積に基づいて決定された経路から、前記フレームをマルチキャスト転送することを特徴とする請求項１２に記載のネットワーク。
【請求項１４】
前記マルチキャストテーブルを用いる前記ノードは、
受信した前記マルチキャストフレームの拡張タグのうち、ブロードキャストフォワーディングタグとグループの情報を示すタグを検索して、前記マルチキャストテーブルの構成に基づいて、前記マルチキャストテーブルのみ、或いは前記マルチキャストテーブルと前記フォワーディングテーブルの双方を参照して、マルチキャスト転送ポートを決定し、前記マルチキャストフレームを転送することを特徴とする請求項１２又は請求項１３に記載のネットワーク。
【請求項１５】
前記第１のノード及び前記メッセージを転送する前記ノードが、
前記応答メッセージ或いは前記第２の応答メッセージを２回以上受信した場合に、２回目以降に受信した前記応答メッセージ或いは前記第２の応答メッセージを次のノードに転送しないように制御することを特徴とする請求項９に記載のネットワーク。
【請求項１６】
前記第１のノード及び前記問い合わせメッセージ及び応答メッセージを転送する前記ノードが、
受信した前記第２の問い合わせメッセージの第１のノードの識別子と当該問い合わせメッセージに格納されている前記グループの情報を管理するメッセージ受信テーブルを備え、
前記ノードは、
前記第２の問い合わせメッセージに対する前記応答メッセージ或いは前記第２の応答メッセージを最初に受信した時点で、前記メッセージ受信テーブルの前記グループの情報を削除し、
前記メッセージ受信テーブルに前記グループの情報が存在しない場合に、受信した前記応答メッセージ或いは前記第２の応答メッセージを転送しないように制御することを特徴とする請求項１５に記載のネットワーク。
【請求項１７】
前記問い合わせメッセージ及び前記応答メッセージに、複数のグループの情報を指定することを特徴とする請求項１から請求項１６の何れか１項に記載のネットワーク。
【請求項１８】
前記第１のノードは、
自ノードに複数のグループを収容する場合に、
前記複数のグループを指定する複数の前記グループの情報を、前記問い合わせメッセージに格納して転送することを特徴とする請求項１から請求項１７の何れか１項に記載のネットワーク。
【請求項１９】
転送路の障害を検出したノードから送信されたトポロジチェンジＢＰＤＵを受信すると、
各ノードは、前記マルチキャストテーブルの所定のエントリを無効化することを特徴とする請求項１から請求項１８の何れか１項に記載のネットワーク。
【請求項２０】
前記トポロジー変更ＢＰＤＵを受信した他ノードは、前記トポロジー変更ＢＰＤＵを分析し、トポロジー変更が発生したツリーのルートノードの識別情報を取得し、
前記ルートノードの識別情報に基づいて前記マルチキャストテーブル２０２１を検索し、取得したルートノードの識別情報に対応するエントリをクリアすることを特徴とする請求項１９に記載のネットワーク。
【請求項２１】
転送路の障害を検出したノードで、第２の問い合わせメッセージの再送を要求する要求メッセージを、前記ルートノードから送信される第２の問い合わせメッセージを待たずに、新たなツリーに沿って前記ルートノードに向けて送信し、
前記信要求メッセージを受信した中継ノードで、前記ルートノードの識別情報に対するマルチキャストテーブルのエントリをクリアすることを特徴とする請求項１９又は請求項２０に記載のネットワーク。
【請求項２２】
前記問い合わせメッセージを受信した前記エッジノードに自ノードの配下のグループの情報が事前に登録されてない場合、前記グループの情報に属する前記ホストが存在するかどうかを自ノードに接続されるホストに問い合わせ、
前記問い合わせに対する前記グループの情報に属する前記ホストからの応答があれば、前記グループの情報に関する前記応答メッセージを生成して送信することを特徴とする請求項１から請求項２１の何れか１項に記載のネットワーク。
【請求項２３】
複数のノードからなるネットワーク上で、前記ノードに収容され、グループによってグループ分けされたホスト間でマルチキャストによってフレームを転送する転送方法において、
第１のノードから、各ノードに対して自ノードが収容するホストと同じグループに属するホストが存在するかを問い合わせるための問い合わせメッセージをブロードキャストにより送信し、
前記第１のノードと同じグループに属するホストを収容するエッジノードから、前記ルートノードに対し、前記問い合わせメッセージに対する応答メッセージを返信し、
前記第１のノード、前記応答メッセージを中継するノードが、前記応答メッセージを受信したポートと前記グループを識別するグループの情報とを対応付けたマルチキャストテーブルを作成することを特徴とする転送方法。
【請求項２４】
前記フレームをマルチキャスト転送する際に、前記マルチキャストテーブルを参照することにより、前記フレームが同じグループに属するホストを収容するノードのみに転送することを特徴とする請求項２３に記載の転送方法。
【請求項２５】
前記フレーム第１のノードは、前記問い合わせメッセージを、自身がルートノードとなるスパニングツリーに沿ってブロードキャストにより送信することを特徴とする請求項２３又は請求項２４に記載の転送方法。
【請求項２６】
前記応答メッセージは、前記第１のノードをルートノードとするスパニングツリーに沿って送信されることを特徴とする請求項２３から請求項２５のいずれか１項に記載の転送方法
【請求項２７】
前記マルチキャストテーブルは、各ツリーのルートノードとなる前記第１のノードの識別子毎に、前記グループの情報と、マルチキャストフレームを転送する前記ポートを記録して構成されることを特徴とする請求項２３から請求項２６の何れか１項に記載の転送方法。
【請求項２８】
前記中継ノードでは、前記複数のスパニングツリー毎に、前記マルチキャストテーブルを作成することを特徴とする請求項２３から請求項２７の何れか１項に記載の転送方法。
【請求項２９】
前記第１のノードが、前記グループが追加又は削除される時に、前記問い合わせメッセージに、前記グループの識別情報と、前記グループの追加又は削除の種別を示す情報を含むグループ情報を格納してブロードキャストにより送信することを特徴とする請求項２３から請求項２８の何れか１項に記載の転送方法。
【請求項３０】
前記エッジノード、前記中継するノードが、前記グループ情報に前記グループの削除を指定する情報を含む前記問い合わせメッセージを受信することにより、前記マルチキャストテーブルから、前記グループの識別情報に対応するエントリをクリアすることを特徴とする請求項２９に記載の転送方法。
【請求項３１】
拡張タグ情報を含むフレームの拡張タグ格納領域に、ブロードキャストフォワーディングタグとグループの情報を示すタグが格納されている場合に、前記フレームをマルチキャスにより転送するフレームと認識することを特徴とする請求項２３から請求項３０の何れか１項に記載の転送方法。
【請求項３２】
前記エッジノードが、前記応答メッセージの送信後に、自ノードが収容するグループと同じグループに属するホストが存在するかを問い合わせるための第２の問い合わせメッセージを、自身がルートノードとなるスパニングツリーに沿ってブロードキャストにより送信し、
前記エッジノードと同じグループに属するホストを収容する前記第１のノードから、前記エッジノードに対し、前記第２の問い合わせメッセージに対する第２の応答メッセージを返信し、
前記第１のノード、前記エッジノード、前記中継するノードが、前記第２の応答メッセージを受信したポートと前記第２の問い合わせメッセージに含まれるグループの識別情報とを対応付けた情報によって、前記マルチキャストテーブルを更新することを特徴とする請求項２３から請求項３１の何れか１項に記載の転送方法。
【請求項３３】
同じグループを収容する複数のツリーのうちの１つのツリーについて、前記応答メッセージを受信したポートと前記グループの情報とを対応付けた全ての前記第１のノード間で共有する共有マルチキャストテーブルを作成し、
前記第１のノードは、前記共有マルチキャストテーブルと、前記拡張タグ付きフレームをブロードキャストする経路を示すテーブルとを参照して、前記フレームをマルチキャスト転送することを特徴とする請求項２３に記載の転送方法。
【請求項３４】
前記第１のノードは、前記共有マルチキャストテーブルと、前記拡張タグ付きフレームをブロードキャストする経路を示すテーブルとの論理積に基づいて決定された経路から、前記フレームをマルチキャスト転送することを特徴とする請求項３３に記載の転送方法。
【請求項３５】
前記マルチキャストテーブルを用いる前記ノードは、
受信した前記マルチキャストフレームの拡張タグのうち、ブロードキャストフォワーディングタグとグループ分離タグを検索して、前記マルチキャストテーブルの構成に基づいて、前記マルチキャストテーブルのみ、或いは前記マルチキャストテーブルと前記フォワーディングテーブルの双方を参照して、マルチキャスト転送ポートを決定し、前記マルチキャストフレームを転送することを特徴とする請求項３３又は請求項３４に記載の転送方法。
【請求項３６】
前記第１のノード及び前記メッセージを転送する前記ノードが、
前記第２の応答メッセージを２回以上受信した場合に、２回目以降に受信した前記第２の応答メッセージを次のノードに転送しないように制御することを特徴とする請求項３２に記載の転送方法。
【請求項３７】
前記第１のノード及び前記問い合わせメッセージ及び応答メッセージを転送する前記ノードが、
受信した前記第２の問い合わせメッセージの第１のノードの識別子と当該問い合わせメッセージに格納されている前記グループの情報を管理するメッセージ受信テーブルを備え、
前記ノードは、
前記第２の問い合わせメッセージに対する前記第２の応答メッセージを最初に受信した時点で、前記メッセージ受信テーブルの前記グループの情報を削除し、
前記メッセージ受信テーブルに前記グループの情報が存在しない場合に、受信した前記第２の応答メッセージを転送しないように制御することを特徴とする請求項３６に記載の転送方法。
【請求項３８】
前記問い合わせメッセージ及び前記応答メッセージに、複数のグループの情報を指定することを特徴とする請求項２３から請求項３７の何れか１項に記載の転送方法。
【請求項３９】
前記第１のノードは、
自ノードに複数のグループを収容する場合に、
前記複数のグループを指定する複数の前記グループの情報を、前記問い合わせメッセージに格納して転送することを特徴とする請求項２３から請求項３８の何れか１項に記載の転送方法。
【請求項４０】
転送路の障害を検出したノードから送信されたトポロジチェンジＢＰＤＵを受信すると、
各ノードは、前記マルチキャストテーブルの所定のエントリを無効化することを特徴とする請求項２３から請求項３９の何れか１項に記載の転送方法。
【請求項４１】
前記トポロジー変更ＢＰＤＵを受信した他ノードは、前記トポロジー変更ＢＰＤＵを分析し、トポロジー変更が発生したツリーのルートノードの識別情報を取得し、
前記ルートノードの識別情報に基づいて前記マルチキャストテーブル２０２１を検索し、取得したルートノードの識別情報に対応するエントリをクリアすることを特徴とする請求項４０に記載の転送方法。
【請求項４２】
転送路の障害を検出したノードで、第２の問い合わせメッセージの再送を要求する要求メッセージを、前記ルートノードから送信される第２の問い合わせメッセージを待たずに、新たなツリーに沿って前記ルートノードに向けて送信し、
前記信要求メッセージを受信した中継ノードで、前記ルートノードの識別情報に対するマルチキャストテーブルのエントリをクリアすることを特徴とする請求項４０又は請求項４１に記載の転送方法。
【請求項４３】
前記問い合わせメッセージを受信した前記エッジノードに自ノードの配下のグループの情報が事前に登録されてない場合、前記グループの情報に属する前記ホストが存在するかどうかを自ノードに接続されるホストに問い合わせ、
前記問い合わせに対する前記グループの情報に属する前記ホストからの応答があれば、前記グループの情報に関する前記応答メッセージを生成して送信することを特徴とする請求項２３から請求項４２の何れか１項に記載の転送方法。
【請求項４４】
複数のノードからなるネットワークであって、前記ノードに収容され、グループによってグループ分けされたホスト間でマルチキャストによってフレームの転送を行うネットワークのノードにおいて、
第１のノードが、各ノードに対して自ノードが収容するホストと同じグループに属するホストが存在するかを問い合わせるための問い合わせメッセージをブロードキャストにより送信する機能を有し、
前記第１のノードと同じグループに属するホストを収容するエッジノードが、前記ルートノードに対し、前記問い合わせメッセージに対する応答メッセージを返信する機能を有し、
前記第１のノード、前記応答メッセージを中継するノードが、前記応答メッセージを受信したポートと前記グループを識別するグループの情報とを対応付けたマルチキャストテーブルを作成する機能を有することを特徴とするノード。
【請求項４５】
前記フレームをマルチキャスト転送する際に、前記マルチキャストテーブルを参照することにより、前記フレームが同じグループに属するホストを収容するノードのみに転送することを特徴とする請求項４４に記載のノード。
【請求項４６】
前記第１のノードは、前記問い合わせメッセージを、自身がルートノードとなるスパニングツリーに沿ってブロードキャストにより送信する機能を有することを特徴とする請求項４４又は請求項４５に記載のノード。
【請求項４７】
前記応答メッセージは、前記第１のノードをルートノードとするスパニングツリーに沿って送信されることを特徴とする請求項４４から請求項４６のいずれか１項に記載の転送方法
【請求項４８】
前記マルチキャストテーブルを、各ツリーのルートノードとなる前記第１のノードの識別子毎に、前記グループの情報と、マルチキャストフレームを転送する前記ポートを記録することにより作成する機能を有することを特徴とする請求項４４から請求項４７に記載のノード。
【請求項４９】
前記中継ノードが、前記複数のスパニングツリー毎に、前記マルチキャストテーブルを作成する機能を有することを特徴とする請求項３６から請求項３８の何れか１項に記載のノード。
【請求項５０】
前記第１のノードが、前記グループが追加又は削除される時に、前記問い合わせメッセージに、前記グループの識別情報と、前記グループの追加又は削除の種別を示す情報を含むグループ情報を格納してブロードキャストにより送信する機能を有することを特徴とする請求項４４から請求項４９の何れか１項に記載のノード。
【請求項５１】
前記エッジノード、前記中継するノードが、前記グループ情報に前記グループの削除を指定する情報を含む前記問い合わせメッセージを受信することにより、前記マルチキャストテーブルから、前記グループの識別情報に対応するエントリをクリアする機能を有することを特徴とする請求項５０に記載のノード。
【請求項５２】
拡張タグ情報を含むフレームの拡張タグ格納領域に、ブロードキャストフォワーディングタグとグループの情報を示すタグが格納されている場合に、前記フレームをマルチキャスにより転送するフレームと認識する機能を有することを特徴とする請求項４４から請求項５１の何れか１項に記載のノード。
【請求項５３】
前記グループが追加又は削除された場合に、前記問い合わせメッセージを生成し、かつ前記問い合わせメッセージに対する前記応答メッセージを生成するすると共に、
受信した前記応答メッセージに基づいて前記マルチキャストテーブルを作成するマルチキャスト制御部を備えることを特徴とする請求項４４から請求項５２の何れか１項に記載のノード。
【請求項５４】
前記エッジノードが、前記応答メッセージの送信後に、自ノードが収容するグループと同じグループに属するホストが存在するかを問い合わせるための第２の問い合わせメッセージを、自身がルートノードとなるスパニングツリーに沿ってブロードキャストにより送信する機能を有し、
前記エッジノードと同じグループに属するホストを収容する前記第１のノードから、前記エッジノードに対し、前記第２の問い合わせメッセージに対する第２の応答メッセージを返信する機能を有し、
前記第１のノード、前記エッジノード、前記中継するノードが、前記第２の応答メッセージを受信したポートと前記第２の問い合わせメッセージに含まれるグループの識別情報とを対応付けた情報によって、前記マルチキャストテーブルを更新する機能を有することを特徴とする請求項４４から請求項５３の何れか１項に記載のノード。
【請求項５５】
同じグループを収容する複数のツリーのうちの１つのツリーについて、前記応答メッセージを受信したポートと前記グループの情報とを対応付けた全ての前記第１のノード間で共有する共有マルチキャストテーブルを作成する機能を有し、
前記第１のノードは、前記共有マルチキャストテーブルと、前記拡張タグ付きフレームをブロードキャストする経路を示すテーブルとを参照して、前記フレームをマルチキャスト転送する機能を有することを特徴とする請求項４４に記載のノード。
【請求項５６】
前記第１のノードは、前記共有マルチキャストテーブルと、前記拡張タグ付きフレームをブロードキャストする経路を示すテーブルとの論理積に基づいて決定された経路から、前記フレームをマルチキャスト転送する機能を有することを特徴とする請求項５５に記載のノード。
【請求項５７】
前記マルチキャストテーブルを用いる前記ノードは、
受信した前記マルチキャストフレームの拡張タグのうち、ブロードキャストフォワーディングタグとグループの情報を示すタグを検索して、前記マルチキャストテーブルの構成に基づいて、前記マルチキャストテーブルのみ、或いは前記マルチキャストテーブルと前記フォワーディングテーブルの双方を参照して、マルチキャスト転送ポートを決定し、前記マルチキャストフレームを転送する機能を有することを特徴とする請求項５５又は請求項５６に記載のノード。
【請求項５８】
前記第１のノード及び前記メッセージを転送する前記ノードが、
前記第２の応答メッセージを２回以上受信した場合に、２回目以降に受信した前記第２の応答メッセージを次のノードに転送しないように制御することを特徴とする請求項５４に記載のノード。
【請求項５９】
前記第１のノード及び前記問い合わせメッセージ及び応答メッセージを転送する前記ノードが、
受信した前記第２の問い合わせメッセージの第１のノードの識別子と当該問い合わせメッセージに格納されている前記グループの情報を管理するメッセージ受信テーブルを備え、
前記ノードは、
前記第２の問い合わせメッセージに対する前記第２の応答メッセージを最初に受信した時点で、前記メッセージ受信テーブルの前記グループの情報を削除する機能と、
前記メッセージ受信テーブルに前記グループの情報が存在しない場合に、受信した前記第２の応答メッセージを転送しないように制御する機能を有することを特徴とする請求項５８に記載のノード。
【請求項６０】
前記問い合わせメッセージ及び前記応答メッセージに、複数のグループの情報を指定することを特徴とする請求項４４から請求項５９の何れか１項に記載のノード。
【請求項６１】
前記第１のノードは、
自ノードに複数のグループを収容する場合に、
前記複数のグループを指定する複数の前記グループの情報を、前記問い合わせメッセージに格納して転送する機能を有することを特徴とする請求項４４から請求項６０の何れか１項に記載のノード。
【請求項６２】
転送路の障害を検出したノードから送信されたトポロジチェンジＢＰＤＵを受信すると、
各ノードは、前記マルチキャストテーブルの所定のエントリを無効化する機能を有することを特徴とする請求項４４から請求項６１の何れか１項に記載のノード。
【請求項６３】
前記トポロジー変更ＢＰＤＵを受信した他ノードは、前記トポロジー変更ＢＰＤＵを分析し、トポロジー変更が発生したツリーのルートノードの識別情報を取得し、
前記ルートノードの識別情報に基づいて前記マルチキャストテーブル２０２１を検索し、取得したルートノードの識別情報に対応するエントリをクリアする機能を有することを特徴とする請求項６２に記載のノード。
【請求項６４】
転送路の障害を検出したノードで、第２の問い合わせメッセージの再送を要求する要求メッセージを、前記ルートノードから送信される第２の問い合わせメッセージを待たずに、新たなツリーに沿って前記ルートノードに向けて送信し、
前記信要求メッセージを受信した中継ノードで、前記ルートノードの識別情報に対するマルチキャストテーブルのエントリをクリアすることを特徴とする請求項６２又は請求項６３に記載のノード。
【請求項６５】
前記問い合わせメッセージを受信した前記エッジノードに自ノードの配下のグループの情報が事前に登録されてない場合、前記グループの情報に属する前記ホストが存在するかどうかを自ノードに接続されるホストに問い合わせ、
前記問い合わせに対する前記グループの情報に属する前記ホストからの応答があれば、前記グループの情報に関する前記応答メッセージを生成して送信することを特徴とする請求項４４から請求項６４の何れか１項に記載のノード。
【請求項６６】
複数のノードからなるネットワーク上の各ノードで実行され、前記ノードに収容され、グループによってグループ分けされたホスト間でマルチキャストによってフレームを転送するマルチキャスト転送制御プログラムにおいて、
前記ノードであるコンピュータ装置に、
第１のノードから、各ノードに対して自ノードが収容するホストと同じグループに属するホストが存在するかを問い合わせるための問い合わせメッセージをブロードキャストにより送信し、
前記第１のノードと同じグループに属するホストを収容するエッジノードから、前記ルートノードに対し、前記問い合わせメッセージに対する応答メッセージを返信し、
前記第１のノード、前記応答メッセージを中継するノードが、前記応答メッセージを受信したポートと前記グループを識別するグループの情報とを対応付けたマルチキャストテーブルを作成する処理を実行させることを特徴とする転送制御プログラム。
【請求項６７】
前記フレームをマルチキャスト転送する際に、前記マルチキャストテーブルを参照することにより、前記フレームが同じグループに属するホストを収容する前記ノードのみに転送する処理を実行させることを特徴とする請求項６６に記載の転送制御プログラム。
【請求項６８】
前記フレーム第１のノードは、前記問い合わせメッセージを、自身がルートノードとなるスパニングツリーに沿ってブロードキャストにより送信することを特徴とする請求項６６又は請求項６７に記載の転送制御プログラム。
【請求項６９】
前記応答メッセージは、前記第１のノードをルートノードとするスパニングツリーに沿って送信されることを特徴とする請求項６６から請求項６８のいずれか１項に記載の転送方法
【請求項７０】
前記マルチキャストテーブルは、各ツリーのルートノードとなる前記第１のノードの識別子毎に、前記グループの情報と、マルチキャストフレームを転送する前記ポートを記録して構成されることを特徴とする請求項６６から請求項６９の何れか１項に記載の転送制御プログラム。
【請求項７１】
前記中継ノードでは、前記複数のスパニングツリー毎に、前記マルチキャストテーブルを作成することを特徴とする請求項６６から請求項７０の何れか１項に記載の転送制御プログラム。
【請求項７２】
前記第１のノードが、前記グループが追加又は削除される時に、前記問い合わせメッセージに、前記グループの識別情報と、前記グループの追加又は削除の種別を示す情報を含むグループ情報を格納してブロードキャストにより送信することを特徴とする請求項６６から請求項７１の何れか１項に記載の転送制御プログラム。
【請求項７３】
前記エッジノード、前記中継するノードが、前記グループ情報に前記グループの削除を指定する情報を含む前記問い合わせメッセージを受信することにより、前記マルチキャストテーブルから、前記グループの識別情報に対応するエントリをクリアすることを特徴とする請求項７２に記載の転送制御プログラム。
【請求項７４】
拡張タグ情報を含むフレームの拡張タグ格納領域に、ブロードキャストフォワーディングタグとグループの情報を示すタグが格納されている場合に、前記フレームをマルチキャスにより転送するフレームと認識することを特徴とする請求項６６から請求項７３の何れか１項に記載のネットワークにおける転送制御プログラム。
【請求項７５】
前記エッジノードが、前記応答メッセージの送信後に、自ノードが収容するグループと同じグループに属するホストが存在するかを問い合わせるための第２の問い合わせメッセージを、自身がルートノードとなるスパニングツリーに沿ってブロードキャストにより送信し、
前記エッジノードと同じグループに属するホストを収容する前記第１のノードから、前記エッジノードに対し、前記第２の問い合わせメッセージに対する第２の応答メッセージを返信し、
前記第１のノード、前記エッジノード、前記中継するノードが、前記第２の応答メッセージを受信したポートと前記第２の問い合わせメッセージに含まれるグループの識別情報とを対応付けた情報によって、前記マルチキャストテーブルを更新することを特徴とする請求項６６から請求項７４の何れか１項に記載の転送制御プログラム。
【請求項７６】
同じグループを収容する複数のツリーのうちの１つのツリーについて、前記応答メッセージを受信したポートと前記グループの情報とを対応付けた全ての前記第１のノード間で共有する共有マルチキャストテーブルを作成し、
前記第１のノードは、前記共有マルチキャストテーブルと、前記拡張タグ付きフレームをブロードキャストする経路を示すテーブルとを参照して、前記フレームをマルチキャスト転送することを特徴とする請求項６６に記載の転送制御プログラム。
【請求項７７】
前記第１のノードは、前記共有マルチキャストテーブルと、前記拡張タグ付きフレームをブロードキャストする経路を示すテーブルとの論理積に基づいて決定された経路から、前記フレームをマルチキャスト転送することを特徴とする請求項７６に記載の転送制御プログラム。
【請求項７８】
前記マルチキャストテーブルを用いる前記ノードは、
受信した前記マルチキャストフレームの拡張タグのうち、ブロードキャストフォワーディングタグとグループの情報を示すタグを検索して、前記マルチキャストテーブルの構成に基づいて、前記マルチキャストテーブルのみ、或いは前記マルチキャストテーブルと前記フォワーディングテーブルの双方を参照して、マルチキャスト転送ポートを決定し、前記マルチキャストフレームを転送することを特徴とする請求項７６又は請求項７７に記載の転送制御プログラム。
【請求項７９】
前記第１のノード及び前記メッセージを転送する前記ノードが、
前記第２の応答メッセージを２回以上受信した場合に、２回目以降に受信した前記第２の応答メッセージを次のノードに転送しないように制御することを特徴とする請求項７５に記載の転送制御プログラム。
【請求項８０】
前記第１のノード及び前記問い合わせメッセージ及び応答メッセージを転送する前記ノードが、
受信した前記第２の問い合わせメッセージの第１のノードの識別子と当該問い合わせメッセージに格納されている前記グループの情報を管理するメッセージ受信テーブルを備え、
前記ノードは、
前記第２の問い合わせメッセージに対する前記第２の応答メッセージを最初に受信した時点で、前記メッセージ受信テーブルの前記グループの情報を削除し、
前記メッセージ受信テーブルに前記グループの情報が存在しない場合に、受信した前記第２の応答メッセージを転送しないように制御することを特徴とする請求項７９に記載の転送制御プログラム。
【請求項８１】
前記問い合わせメッセージ及び前記応答メッセージに、複数のグループの情報を指定することを特徴とする請求項６６から請求項８０の何れか１項に記載の転送制御プログラム。
【請求項８２】
前記第１のノードは、
自ノードに複数のグループを収容する場合に、
前記複数のグループを指定する複数の前記グループの情報を、前記問い合わせメッセージに格納して転送することを特徴とする請求項６６から請求項８１の何れか１項に記載の転送制御プログラム。
【請求項８３】
転送路の障害を検出したノードから送信されたトポロジチェンジＢＰＤＵを受信すると、
各ノードは、前記マルチキャストテーブルの所定のエントリを無効化することを特徴とする請求項６６から請求項８２の何れか１項に記載の転送制御プログラム。
【請求項８４】
前記トポロジー変更ＢＰＤＵを受信した他ノードは、前記トポロジー変更ＢＰＤＵを分析し、トポロジー変更が発生したツリーのルートノードの識別情報を取得し、
前記ルートノードの識別情報に基づいて前記マルチキャストテーブルを検索し、取得したルートノードの識別情報に対応するエントリをクリアすることを特徴とする請求項８３に記載の転送制御プログラム。
【請求項８５】
転送路の障害を検出したノードで、第２の問い合わせメッセージの再送を要求する要求メッセージを、前記ルートノードから送信される第２の問い合わせメッセージを待たずに、新たなツリーに沿って前記ルートノードに向けて送信し、
前記信要求メッセージを受信した中継ノードで、前記ルートノードの識別情報に対するマルチキャストテーブルのエントリをクリアすることを特徴とする請求項８３又は請求項８４に記載の転送制御プログラム。
【請求項８６】
前記問い合わせメッセージを受信した前記エッジノードに自ノードの配下のグループの情報が事前に登録されてない場合、前記グループの情報に属する前記ホストが存在するかどうかを自ノードに接続されるホストに問い合わせ、
前記問い合わせに対する前記グループの情報に属する前記ホストからの応答があれば、前記グループの情報に関する前記応答メッセージを生成して送信することを特徴とする請求項６６から請求項８５の何れか１項に記載の転送制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークのマルチキャスト転送の制御方法に関し、特に、広域イーサネット（Ｒ）等のネットワークに所属する同じカスタマ（識別子）を有するユーザ（ホスト）間でマルチキャストフレームを転送する際に、該当カスタマが存在するノードのみにマルチキャストフレームが転送されるようにするネットワーク、転送方法、ノード及び転送制御プログラムに関する。
【背景技術】
【０００２】
広域イーサネット（Ｒ）の専用線（ＶＰＮ）サービスを提供する技術としては、例えば、本願出願人による特開２００４−１４０７７７号公報（特許文献１）に開示される技術等が提案されているが、これら従来の技術では同じカスタマ（グループ）に属するユーザ（ホスト）間でマルチキャストフレームを転送する際に、該当同じカスタマに属さないノード（経路）にまでマルチキャストフレームがフラッディングされる。
【０００３】
ここで、従来技術として、上記特許文献１において開示される拡張タグ付きイーサネット（Ｒ）フレームを用いたブロードキャストフレームのフォワーディング方法について図面を用いて説明する。
【０００４】
まず、特許文献１の拡張タグ付きイーサネット（Ｒ）フレームを用いたブロードキャストフレームのフォワーディング方法では、送信元ノードの識別子を既存のイーサネット（Ｒ）フレームに付加し、ネットワーク内の各ノードは、送信元ノードがルートノードになるスパニングツリーを用いてブロードキャストフレームを転送する。これにより、各送信元ノードは全ノードへの最低コスト経路を選択してブロードキャストフレームを転送することができ、ルートノード付近でのトラヒック集中を回避できるため、ネットワーク全体の帯域利用効率を向上させることが可能になる。
【０００５】
以下、上記特許文献１の技術で使用される拡張タグ付きイーサネット（Ｒ）フレームのフォーマットについて、図５０、図５１、図５２及び図５３を用いて説明する。
【０００６】
図５０は、ＩＥＥＥ８０２．１Ｑで規定されているイーサネット（Ｒ）フレーム（ＶＬＡＮタグ付き）のフォーマットを示している。イーサネット（Ｒ）フレーム４２００は、送信先ＭＡＣアドレス４２０１と、送信元ＭＡＣアドレス４２０２と、ＶＬＡＮタグ４２０３と、イーサネット（Ｒ）属性情報（タイプ）４２０４と、ペイロード４２０５と、ＦＣＳ（Frame Check Sequence）４２０６とから構成される。
【０００７】
図５１は、拡張タグ付きイーサネット（Ｒ）フレームフォーマットを示している。拡張タグ付きイーサネット（Ｒ）フレーム４３００は、送信先ＭＡＣアドレス４２０１と、送信元ＭＡＣアドレス４２０２と、拡張タグ格納領域４３０１と、イーサネット（Ｒ）属性情報（タイプ）４２０４と、ペイロード４２０５と、ＦＣＳ４２０６とから構成され、既存のイーサネット（Ｒ）フレーム４２００のＶＬＡＮタグ４２０３が拡張タグ格納領域４３０１に置き換わる。
【０００８】
また、図５２に示すように、他の構成の拡張タグ付きイーサネット（Ｒ）フレーム４４００も存在し、これは送信先ＭＡＣアドレス４２０１と、送信元ＭＡＣアドレス４２０２と、拡張タグ格納領域４３０１と、ＶＬＡＮタグ４２０３と、イーサネット（Ｒ）属性情報（タイプ）４２０４と、ペイロード４２０５と、ＦＣＳ４２０６とから構成され、拡張タグ格納領域４３０１は送信元ＭＡＣアドレス４２０２の後に挿入される。
【０００９】
拡張タグ格納領域４３０１には、１つまたは複数の拡張タグを格納可能である。図５３に示す拡張タグ格納領域４３０１の格納例では、９個の拡張タグ４５００〜４５０８が格納されている。まず、フォワーディングタグ４５００及びブロードキャストフォワーディングタグ４５０８、カスタマ分離タグ４５０１に関して説明する。
【００１０】
フォワーディングタグ４５００には、送信先ホストが接続されたエッジノードの識別子が格納される。また、送信先ホストが接続されたエッジノードの識別子を格納したフォワーディングタグ４５００の代わりに、送信元ホストが接続されたエッジノードの識別子を格納したブロードキャストフォワーディングタグ４５０８が付加される場合もある。
【００１１】
各中継ノードは、このフォワーディングタグ４５００又はブロードキャストフォワーディングタグ４５０８を参照してフレーム転送先を決定する。このフォワーディングタグ４５００又はブロードキャストフォワーディングタグ４５０８は、拡張タグ付きイーサネット（Ｒ）フレーム４３００、４４００において必ず格納される。
【００１２】
カスタマ分離タグ４５０１には、各ノードに収容（接続）されるユーザ（ホスト）をカスタマ（グループ）毎に識別するための識別子が格納されている。
【００１３】
ここで、カスタマとは、Ｌ２−ＶＰＮを利用するユーザ（ホスト）が属するグループを示すための識別情報であり、その各グループに対して各々を識別するための識別子が割り当てられる。同じカスタマ（グループ）に属するユーザ間で送受信されるフレームには、カスタマ分離タグ４５０１内にそのカスタマを示す識別子が格納される。
【００１４】
拡張タグの種類としては、フォワーディングタグ４５００又はブロードキャストフォワーディングタグ４５０８、カスタマ分離タグ４５０１以外にも、プロテクションタグ４５０２、ＯＡＭ＆Ｐタグ４５０３、品質情報タグ４５０４、フレーム制御タグ４５０５、セキュリティタグ４５０６、ユーザ拡張タグ４５０７などが必要に応じて格納される。
【００１５】
（従来の拡張タグ付きイーサネット（Ｒ）フレームを転送するネットワークでのブロードキャスト転送方法）
以下は、従来の拡張タグ付きイーサネット（Ｒ）フレームを転送するネットワークにおけるブロードキャスト転送方法を説明する。
【００１６】
拡張タグ付きイーサネット（Ｒ）フレーム４３００、４４００において、拡張タグ格納領域４３０１にフォワーディングタグ４５００が格納された場合は、送信先ホストが接続されたエッジノードをルートノードとするスパニングツリー上でユニキャスト転送される。一方、拡張タグ格納領域４３０１にブロードキャストフォワーディングタグ４５０８が格納された場合は、自ノードをルートノードとするスパニングツリー上で拡張タグフレームがブロードキャスト転送される。拡張タグフレームを転送する際の出力ポートは、各ノードの拡張タグフォワーディングテーブル（以降は、拡張タグFWテーブルと記す）の記載に基づき決定される。また、拡張タグＦＷテーブルはブロードキャストテーブルとユニキャストテーブルとで構成される。
【００１７】
従来の拡張付きイーサネット（Ｒ）フレームを転送するネットワーク２２００は、図５４で示すように、ノード１００−１〜１００−７で構成されており、ノード１００−１のポート＃１とノード１００−５のポート＃３にカスタマ#aに属するホスト（Ａ，Ｂ）が接続される。図５４において、各ノードからのリンク上に書かれている数字は各ポートのポート番号を示している。また、図５４では、送信元ホストが接続されるエッジノード（以下、入口側エッジノードという）１００−１から送信された拡張タグ付きブロードキャストフレームの転送経路（入口側エッジノードがルートノードになるスパニングツリー）が太線で記されている。
【００１８】
まず、入口側のエッジノードであるノード１００−１の処理について説明する。
【００１９】
ノード１００−１において、カスタマ#aのホストAから、ＭＡＣ＿ＤＡ＝０ｘＦＦＦＦであるブロードキャストフレーム、あるいはＭＡＣ＿ＤＡがマルチキャストアドレスであるマルチキャストフレーム、アドレス解決テーブル３００１においてＭＡＣ＿ＤＡに対する宛先ノード識別子が不明なフレーム（以降は、Ｕｎｋｎｏｗｎユニキャスト）を受信した場合は、ノード１００−１は、自ノードのノード識別子「１００−１」を格納したブロードキャストフォワーディングタグ４５０８と、カスタマＩＤ＝#aを格納したカスタマ分離タグ４５０１とを、ホストから入力した通常のイーサネット（R）フレーム４２００に対して付加し、拡張タグ付きイーサネット（R）フレーム４３００または４４００に変換する。
【００２０】
続いて、ノード１００−１は、ブロードキャストテーブル３２０１を参照して、ノード１００−１に対する出力ポート＃２、＃３との情報を取得し、ポート＃２、＃３に拡張タグ付きイーサネット（R）フレーム４３００または４４００を出力する。出力されたフレームは、中継ノード１００−２、１００−３に転送される。
【００２１】
次に、中継ノード１００−２、１００−３の転送処理を説明する。
【００２２】
中継ノード１００−２は、拡張タグ付きイーサネット（R）フレーム４３００または４４００を受信すると、ブロードキャストテーブル３２０２を参照し、ブロードキャストフォワーディングタグ４５０８に格納される入口側エッジノード識別子「１００−１」に対する出力ポート＃２、＃３、＃４の情報を取得し、ポート＃２、＃３、＃４に拡張タグ付きイーサネット（R）フレーム４３００を転送する。
【００２３】
転送されたフレームは、ノード１００−４、１００−５、１００−６に到着する。また、中継ノード１００−３が中継ノード１００−２と同じ処理を行うことにより転送されたフレームは、１００−７に到着する。
【００２４】
さらに、送信先ホストが接続されるエッジノード（以下、出口側のエッジノードという）１００−５について説明する。
【００２５】
出口側エッジノード１００−５では、拡張タグ付きイーサネット（R）フレーム４３００を受信すると、ブロードキャストテーブル３２０５を参照し、ブロードキャストフォワーディングタグ４５０８に格納される送信元ノード識別子「１００−１」に対する出力ポートエントリをサーチした結果、出力ポートが存在しないので、自ノードが出口側エッジノードであると判断する。
【００２６】
また、カスタマ識別テーブル３１０５を参照して、カスタマ「#a」の接続ポート＃３を取得する。他の出口側エッジノード１００−４、１００−６、１００−７もエッジノード１００−５と同じ処理を行うが、カスタマ#aが接続されていないため、フレームを廃棄する。
【００２７】
ノード１００−５では、フレームのブロードキャストフォワーディングタグ４５０８とカスタマ分離タグ４５０１を削除して、通常のイーサネット（Ｒ）フレーム４２００に変換し、カスタマ#aが接続されているポート＃３に当該フレームを転送する。その後、フレームは、ホストＢに到着する。以上説明した各ノードの転送処理により、従来の拡張タグ付きイーサネット（Ｒ）フレームを転送するネットワーク２２００において、ホストＡからのブロードキャストフレームの転送が行なわれる。
【００２８】
一方、ホストＢからのフレームは、図５５に示す経路に沿ってブロードキャスト転送される。ホストＢからのフレームを受信したノード１００−５は、自ノードがルートノードとなるスパニングツリー（図５５の太線で記されている転送経路）に沿ってフレームを転送し、ネットワーク内の各ノードは、上述の処理と同様の転送処理を行なうことにより、ネットワーク内の各ノードに対し、ブロードキャストされる。
【００２９】
【特許文献１】特開２００４−１４０７７７号
【発明の開示】
【発明が解決しようとする課題】
【００３０】
以上説明したように、従来の拡張付きイーサネット（Ｒ）フレームを転送するネットワーク２２００では、ブロードキャスト転送を行う際に、拡張タグ付きイーサネット（Ｒ）フレーム４３００または４４００のブロードキャストフォワーディングタグ４５０８のみを参照して転送するため、同一のカスタマ間で転送される拡張タグ付きブロードキャストフレーム（以降、マルチキャストフレームと記す）は、同じカスタマが存在しない経路にもフラッディングされるという問題がある。
【００３１】
例えば、図５４で示すように、従来拡張タグ付きイーサネット（Ｒ）フレームを転送するネットワーク２２００で送信元ノード１００−１からカスタマ#aに関してのマルチキャストフレームが転送される場合、そのマルチキャストフレームの転送に要する最小限の転送経路はノード１００−１→ノード１００−２→ノード１００−５を経る経路であるが、従来の転送方法では、その経路に加えて、ノード１００−１→ノード１００−３→ノード１００−７と、ノード１００−２→ノード１００−４と、ノード１００−２→ノード１００−６を経る経路にもカスタマ#aのマルチキャストフレームが転送されてしまう。
【００３２】
このように、従来、拡張タグ付きイーサネット（Ｒ）フレームを転送するネットワーク２２００では、同一のカスタマ間で転送されるマルチキャストフレームに対して、同一のカスタマが接続されていないポートを含む転送ポートにフラッディングするため、マルチキャストフレームは同じカスタマが存在しない経路にも転送されてしまい、その結果ネットワークリンクの帯域を圧迫してしまう可能性がある。
【００３３】
本発明の目的は、拡張タグネットワークにおいて、マルチキャストフレームを転送する際に、カスタマと関係ある経路のみにフレームを転送し、それにより効率的なマルチキャスト転送を可能とする、ネットワーク、転送方法、ノード及び転送制御プログラムを提供することにある。
【課題を解決するための手段】
【００３４】
上記目的を達成する本発明は、複数のノードからなるネットワーク上で、前記ノードに収容され、カスタマによってグループ分けされたホスト間でマルチキャストによってフレームの転送を行うネットワークにおいて、フレームの送信元のノードが、各ノードに対して自ノードが収容するカスタマと同じカスタマが存在するかを問い合わせるための問い合わせメッセージをブロードキャストにより送信し、前記送信元のノードと同じカスタマのホストを収容するエッジノードが、前記ルートノードに対し、前記問い合わせメッセージに対する応答メッセージを返信し、前記送信元のノード、前記エッジノード、前記応答メッセージを中継するノードが、前記応答メッセージを受信したポートと前記カスタマを識別するカスタマ識別情報とを対応付けたマルチキャストテーブルを作成し、前記フレームをマルチキャスト転送する際に、各ノードが、前記マルチキャストテーブルを参照することにより、前記フレームが同じカスタマに属するホストを収容する前記ノードのみに転送することを特徴とする。
【００３５】
本発明の他の態様によれば、前記エッジノードが、前記応答メッセージの送信後に、自ノードが収容するカスタマと同じカスタマに属するホストが存在するかを問い合わせるための第２の問い合わせメッセージを、自身がルートノードとなるスパニングツリーに沿ってブロードキャストにより送信し、前記エッジノードと同じカスタマに属するホストを収容する前記送信元のノードから、前記エッジノードに対し、前記第２の問い合わせメッセージに対する第２の応答メッセージを返信し、前記送信元のノード、前記エッジノード、前記中継するノードが、前記第２の応答メッセージを受信したポートと前記第２の問い合わせメッセージに含まれるカスタマの識別情報とを対応付けた情報によって、前記マルチキャストテーブルを更新することを特徴とする。
【００３６】
本発明の他の態様によれば、同じカスタマを収容する複数のツリーのうちの１つのツリーについて、前記応答メッセージを受信したポートと前記カスタマ識別情報とを対応付けた全ての前記送信元ノード間で共有する共有マルチキャストテーブルを作成し、前記送信元ノードは、前記共有マルチキャストテーブルと、前記拡張タグ付きフレームをブロードキャストする経路を示すテーブルとを参照して、前記フレームをマルチキャスト転送することを特徴とする。
【００３７】
本発明の他の態様によれば、前記送信元ノード及び前記メッセージを転送する前記ノードが、前記応答メッセージ或いは前記第２の応答メッセージを２回以上受信した場合に、２回目以降に受信した前記応答メッセージ或いは前記第２の応答メッセージを次のノードに転送しないように制御することを特徴とする。すなわち、前記送信元ノード及び前記問い合わせメッセージ及び応答メッセージを転送する前記ノードが、受信した前記問い合わせメッセージ或いは前記第２の問い合わせメッセージの送信元のノードの識別子と当該問い合わせメッセージに格納されている前記カスタマ識別情報を管理するメッセージ受信テーブルを備え、前記ノードは、前記問い合わせメッセージ或いは前記第２の問い合わせメッセージに対する前記応答メッセージ或いは前記第２の応答メッセージを最初に受信した時点で、前記メッセージ受信テーブルの前記カスタマ識別情報を削除し、前記メッセージ受信テーブルに前記カスタマ識別情報が存在しない場合に、受信した前記応答メッセージ或いは前記第２の応答メッセージを転送しないように制御する。
【００３８】
本発明のさらに他の態様によれば、前記問い合わせメッセージ及び前記応答メッセージに、複数のカスタマ識別情報を指定することを特徴とする。
【００３９】
本発明のさらに他の態様によれば、転送路の障害を検出したノードから送信されたトポロジチェンジＢＰＤＵを受信すると、各ノードは、前記マルチキャストテーブルの所定のエントリを無効化することを特徴とする。具体的には、前記トポロジー変更ＢＰＤＵを受信した他ノードは、前記トポロジー変更ＢＰＤＵを分析し、トポロジー変更が発生したツリーのルートノードの識別情報を取得し、前記ルートノードの識別情報に基づいて前記マルチキャストテーブル２０２１を検索し、取得したルートノードの識別情報に対応するエントリをクリアする。
【００４０】
（作用）
本発明によれば、フレームの送信元のノードが、各ノードに対して自ノードが収容するカスタマと同じカスタマが存在するかを問い合わせるための問い合わせメッセージを、自ノードがルートノードとなるツリー上にブロードキャストにより送信する。問い合わせメッセージを受信したノードである、送信元のノードと同じカスタマのホストを収容するエッジノードは、送信元のノードであるルートノードに対して、問い合わせメッセージに対する応答メッセージをユニキャストによって返信する。
【００４１】
送信元のノード、エッジノード、応答メッセージを中継するノードのそれぞれが、応答メッセージを受信したポートと問い合わせメッセージに含まれているカスタマを識別するカスタマ識別情報とを対応付けたマルチキャストテーブルを作成する。
【００４２】
フレームをマルチキャスト転送する際に、各ノードは、マルチキャストテーブルを参照して、カスタマ識別情報に対応するポートを転送ポートとして決定することにより、フレームが同じカスタマに属するホストを収容するノードのみに転送する。これにより、カスタマと関係ある経路のみにマルチキャストフレームが転送される。
【発明の効果】
【００４３】
本発明のネットワーク、マルチキャスト転送制御方法、ノード及びマルチキャスト転送プログラムによれば、マルチキャストフレームを転送する際に、カスタマと関係ある経路のみにフレームを転送することができ、それにより効率的なマルチキャスト転送が実現される。
【００４４】
その理由は、各ノードが、問い合わせメッセージに対する応答メッセージを受信したポートとカスタマを識別するカスタマ識別情報とを対応付けたマルチキャストテーブルを作成し、フレームをマルチキャスト転送する際に、各ノードが、マルチキャストテーブルを参照することにより、フレームが同じカスタマに属するホストを収容するノードのみに転送するためである。
【００４５】
また、同じカスタマを収容する複数のツリーのうちの１つのツリーについて、応答メッセージを受信したポートとカスタマ識別情報とを対応付けた全ての送信元ノード間で共有する共有マルチキャストテーブルを用いることにより、マルチキャストテーブルの構成を簡略化することができ、必要なメモリ量を大幅に削減することができる。
【００４６】
また、応答メッセージ或いは第２の応答メッセージを２回以上受信した場合に、２回目以降に受信した応答メッセージ或いは第２の応答メッセージを次のノードに転送しないように制御することにより、当該応答メッセージの転送に要するノードの処理負担を減少することができる。
【００４７】
また、複数のカスタマを収容するノードにおいて、複数のカスタマ情報を格納した問い合わせメッセージを生成することにより、生成するメッセージの全体数を減らすことができる。
【発明の実施するための最良の形態】
【００４８】
以下、本発明の実施の形態について図面を参照して詳細に説明する。
【００４９】
（第１の実施の形態）
本発明の第１の実施の形態による、マルチキャストテーブル作成の基本方式及びマルチキャストフレーム転送方法について説明する。
【００５０】
図１を参照すると、本発明の第１の実施の形態による拡張タグ付きイーサネット（Ｒ）フレームを転送するネットワーク２３００は、図５４に示した従来のネットワーク２２００におけるノード１００−１〜１００−７が本発明を適用したノード２００−１〜２００−７に置き換わっており、その中のノード２００−１と２００−４〜２００−７はエッジノードとして、ノード２００−２、ノード２００−３は中継ノードとして機能している。
【００５１】
図１では、各ノードのリンク上に書かれている数字は、各ポートのポート番号を示している。ノード２００−１のポート（１）とノード２００−５のポート（３）にはカスタマ＃ａのホストが接続されている。ここで、各ノードの接続関係、それぞれのポート数及びスパニングツリーの構成などは一例であって、本発明の内容を制限するものではない。
【００５２】
本実施の形態のノード２００−１〜２００−７では、拡張タグ付きのマルチキャストフレーム４３００を転送する際に、フレームがカスタマと関係ある経路のみにフレームが転送されるようにするため、マルチキャストフレームの転送ポートが記述されたマルチキャストテーブルを備える（マルチキャストテーブルは図７に示す構成であり、その詳細については後で説明する）。
【００５３】
続いて、図２を用いて本実施の形態におけるマルチキャストテーブル作成方法について説明する。
【００５４】
図２で示すように、送信元エッジノードでは、自ノードに収容（接続）しているカスタマの接続状況に変更が起こった場合に、その変更が生じたカスタマがサービス中であるノードが存在するか否かを確認するための制御メッセージ（以降、Ｑｕｅｒｙ制御メッセージと称する）を全ネットワーク上に自ノードがルートノードとなるスパニングツリーを経路としてブロードキャスト転送する。
【００５５】
一方、Ｑｕｅｒｙ制御メッセージ４７０１（図８）を受信した他のエッジノードのうち、同じカスタマを収容している他のエッジノードからは、Ｑｕｅｒｙ制御メッセージ４７０１への応答として、サービス中の同一カスタマを収容していることを送信元エッジノードに通知するための制御メッセージ（以降、Ｒｅｐｏｒｔ制御メッセージと称する）を送信元エッジノードに返信する。
【００５６】
転送経路上でＲｅｐｏｒｔ制御メッセージ４７０２（図８）を受信したノードは、Ｒｅｐｏｒｔ制御メッセージ４７０２の受信ポートをマルチキャストテーブルに記録する。この処理により、各ノードは、転送経路の下流方向に同一カスタマが存在するか否かを知ることができ、同一カスタマが存在する経路のみにフレーム転送することが可能となる。
【００５７】
以下、本実施の形態のノードの構成例、制御メッセージ（Ｑｕｅｒｙ制御メッセージ４７０１、Ｒｅｐｏｒｔ制御メッセージ４７０２）のフォーマット、マルチキャストテーブルの構成例に関して図３〜図８の図面を用いて詳細に説明する。
【００５８】
（ノードの構成）
図３は、ノード２００−１〜２００−７の構成を詳細に示した図である。なお、図３では、ノード２００−１の構成を示しているが、その他のノード２００−２〜２００−７についても図３と同じ構成である。
【００５９】
ノード２００−１は、フレーム解析部２０１１と、タグ挿入部２０１２と、タグスイッチ部２０１３と、タグ削除部２０１４と、ＭＡＣラーニング部２０１５、カスタマ管理モジュール２０１６、カスタマ識別テーブル２０１７、フォワーディングテーブル格納部２０１８と、ＳＴＰ制御部２０１９と、マルチキャスト制御部２０２０、マルチキャストテーブル２０２１を備えて構成される。
【００６０】
ノード２００−１が、エッジノードである場合は、ポート２１０−ｉｎ、２１０−ｏｕｔ、２２０−ｉｎ、２２０−ｏｕｔが利用され、中継ノードである場合は、２２０−ｉｎ、２２０−ｏｕｔだけが利用される。また、図３では、ポート２１０−ｉｎ、２１０−ｏｕｔ、２２０−ｉｎ、２２０−ｏｕｔをそれぞれ一本ずつしか記載していないが、各ポートの本数はこれに限られない。
【００６１】
入力ポート２１０−ｉｎには、既存のイーサネット（Ｒ）フレーム４２００が入力され、入力ポート２２０−ｉｎには、既存のイーサネット（Ｒ）フレーム４２００或いは拡張タグ付きイーサネット（Ｒ）フレーム４３００または４４００が入力される。
【００６２】
フレーム解析部２０１１は、入力されたフレームのヘッダ情報とフレーム種別情報、入力ポート情報などを解析し、既存のイーサネット（Ｒ）フレーム４２００の場合は、タグ挿入部２０１２またはタグスイッチ部２０１３に転送し、拡張タグ付きイーサネット（Ｒ）フレーム４３００の場合は、タグスイッチ部２０１３に転送する。同時に、当該ノードがエッジノードである場合には、フレーム解析部２０１１は、受信したフレームのＭＡＣ＿ＳＡ情報をＭＡＣラーニング部２０１５に送信する。また、ＳＴＰ（Spanning Tree Protocol）の制御フレームであるＢＰＤＵ  （Ｂｒｉｄｇｅ  Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  Ｕｎｉｔ）を受信した場合は、そのＢＰＤＵをＳＴＰ制御部２０１９に転送し、マルチキャストテーブルを更新する際に使用される制御フレーム（Ｑｕｅｒｙ制御メッセージ４７０１、Ｒｅｐｏｒｔ制御メッセージ４７０２）を受信した場合は、その制御フレームをマルチキャスト制御部２０２０に転送する。
【００６３】
タグ挿入部２０１２は、フレーム解析部２０１１より既存のイーサネット（Ｒ）フレーム４２００を受信すると、ＭＡＣ＿ＤＡを基にフォワーディングテーブル格納部２０１８を参照してフォワーディングタグを取得し、入力ポート（またはそれに加えてＶＬＡＮタグ）を基にカスタマ識別テーブル２０１７を参照してカスタマ分離タグを取得し、両方のタグを既存のイーサネット（Ｒ）フレーム４２００に付加することにより、拡張タグ付きイーサネット（Ｒ）フレーム４３００または４４００に変換して、タグスイッチ部２０１３に転送する。例えば、フレーム解析部２０１１より、あるカスタマに関するブロードキャストフレームを受信した場合は、ブロードキャストフォワーディングタグ４５０８とカスタマ分離タグ４５０１を格納して、タグスイッチ部２０１３に転送する。
【００６４】
タグスイッチ部２０１３は、フレーム解析部２０１１またはタグ挿入部２０１２より拡張タグ付きイーサネット（Ｒ）フレーム４３００を受信した場合は、フォワーディングテーブル格納部２０１８或いはマルチキャストテーブル２０２１の記述に従い、当該受信したフレームを出力ポート２２０−ｏｕｔ或いはタグ削除部２０１４に転送する。
【００６５】
ここで、タグスイッチ部２０１３は、図４に示すように、スイッチ部２１０１、テーブル検索部２１０２、テーブル制御部２１０３で構成されている。
【００６６】
スイッチ部２１０１は、受信した拡張タグ付きイーサネット（Ｒ）フレーム４３００または４４００の拡張タグ格納領域４３０１を検索して、ブロードキャストフォワーディングタグ４５０８とカスタマ分離タグ４３０１が格納されている場合は、テーブル検索部２１０２により、マルチキャストテーブル２０２１（フォワーディングテーブル格納部２０１８とマルチキャストテーブル２０２１両方を参照する場合もある）を参照し、一方、フォワーディングタグ４５００とカスタマ分離タグ４３０１が格納された場合は、テーブル検索部２１０２により、フォワーディングテーブル格納部２０１８を参照する。
【００６７】
また、スイッチ部２１０１は、フレーム解析部２０１１またはタグ挿入部２０１２より既存のイーサネット（Ｒ）フレーム４２００を受信した場合は、テーブル検索部２１０２により、フォワーディングテーブル格納部２０１８の記述に従い、受信したフレームを出力ポート２２０−ｏｕｔまたは出力ポート２１０−ｏｕｔに転送する。
【００６８】
タグスイッチ部２０１３内のテーブル制御部２１０３は、ＳＴＰ制御部２０１９又はマルチキャスト制御部２０２０により、フォワーディングテーブル格納部２０１８とマルチキャストテーブル２０２１を有効、あるいは無効にするといった処理を行う。
【００６９】
タグ削除部２０１４は、タグスイッチ部２０１３から拡張タグ付きイーサネット（Ｒ）フレーム４３００または４４００を受信すると、拡張タグ付きイーサネット（Ｒ）フレーム４３００または４４００に付加されている拡張タグ４３０１を外し、ポート２１０−ｏｕｔに転送する。また、タグスイッチ部２０１３から、既存のイーサネット（Ｒ）フレーム４２００を受信した場合は、拡張タグの削除処理を行うことなくそのまま出力ポート２１０−ｏｕｔに転送する。
【００７０】
出力ポート２２０−ｏｕｔは、他のノード２００と接続されており、出力ポート２１０−ｏｕｔは、既存のイーサネット（Ｒ）スイッチ又はホストと接続されている。
【００７１】
フォワーディングテーブル格納部２０１８には、フレームを転送するための情報を格納した各種テーブルが備えられている。すなわち、フォワーディングテーブル格納部２０１８には、ＭＡＣアドレスから出力ポートを解決するＭＡＣテーブル２２０１と、ＭＡＣアドレスから宛先ノード識別子を解決するアドレス解決テーブル２２０２と、拡張タグから出力ポートを解決する拡張タグＦＷテーブル２２０３が含まれる。
【００７２】
図５は、フォワーディングテーブル格納部２０１８の構成例を示す。フォワーディングテーブル格納部２０１８は、ＭＡＣテーブル２２０１と、アドレス解決テーブル２２０２と、拡張タグＦＷテーブル２２０３と、テーブル書込制御部２２０４と、テーブル読込制御部２２０５とから構成される。そして、さらに拡張タグＦＷテーブル２２０３は、ブロードキャストテーブル２２１１とユニキャストテーブル２２１２で構成される。各テーブルへの新たなデータの書込みはテーブル書込制御部２２０４を介して行なわれ、各テーブルからのデータの読み出しはテーブル読込制御部２２０５を介して行なわれる。
【００７３】
ＭＡＣラーニング部２０１５（図３を参照）は、フレーム解析部２０１１からヘッダ情報を受信すると、フォワーディングテーブル格納部２０１８のＭＡＣテーブル２２０１を参照して、受信したヘッダ情報のＭＡＣ＿ＳＡ（送信元アドレス）に対する出力ポートを検索し、エントリが存在しない場合は、ＭＡＣアドレスフィールドにＭＡＣ＿ＳＡを、出力ポートフィールドに受信ポートを格納する（通常のＭＡＣラーニング処理）。また、アドレス解決テーブル２２０２を参照して、受信したフレームのＭＡＣ＿ＳＡに対する宛先ノードのノード識別子を検索し、エントリが存在しない場合は、マルチキャストテーブル２０２１のノード識別子フィールドにフレームの送信元ノードのノード識別子を格納する（拡張タグラーニング処理）。
【００７４】
ＳＴＰ制御部２０１９は、フレーム解析部２０１１から受信したＢＰＤＵに基づいてＳＴＰ／ＲＳＴＰのポート情報の更新処理などを行ない、ＢＰＤＵを再作成し、隣接のノードに転送する。ＳＴＰ制御部２０１９は、ＶＬＡＮ毎にＳＴＰのポート情報を管理しており、ＳＴＰ／ＲＳＴＰの構成に変更があり、ポート状態に変更があった場合は、フォワーディングテーブル格納部２０１８を更新する。
【００７５】
カスタマ識別テーブル２０１７は、エッジノードのみに備えられるテーブルであり、自ノードに収容（接続）されるカスタマの識別子（カスタマＩＤ）と該当カスタマに対応する接続ポートを保持している。カスタマ識別テーブル２０１７は、入力ポートからカスタマＩＤを検索する構成と、カスタマＩＤから出力ポートを検索する構成の両方のテーブルを持つ。
【００７６】
カスタマ管理モジュール２０１６は、設定ＩＦ（インタフェース）２５００を介してネットワーク管理者等からカスタマの接続状況の変更に関する設定が行われると、そのカスタマ変更設定情報に基づいて、カスタマ識別テーブル２０１７を更新する。それと同時に、マルチキャスト制御部２０２０に対してカスタマ設定変更情報を通知する。
【００７７】
マルチキャスト制御部２０２０は、カスタマ管理モジュール２０１６からのカスタマ変更設定情報を受信した場合、その情報に基づき、Ｑｕｅｒｙ制御メッセージ４７０１またはＲｅｐｏｒｔ制御メッセージ４７０２を生成してタグスイッチ部２０１３に転送する。また、マルチキャスト制御部２０２０は、フレーム解析部２０１１から制御メッセージフレームを受信した場合、受信した制御メッセージの種別によって、マルチキャストテーブル２０２１の更新処理、またはカスタマ管理モジュール２０１６に該当カスタマの接続状況を問い合わせた上で制御メッセージの転送または廃棄処理を行う。転送の場合には、制御メッセージをタグスイッチ部２０１３に転送する。
【００７８】
マルチキャストテーブル２０２１は、あるカスタマに対するマルチキャストフレームを同一カスタマにのみ転送するためのマルチキャスト転送ポートを記述する構成となっている。
【００７９】
（制御メッセージのフレームフォーマット）
続いて、制御メッセージ（Ｑｕｅｒｙ制御メッセージ４７０１、Ｒｅｐｏｒｔ制御メッセージ４７０２）のフレームフォーマットについて説明する。図６は、本実施の形態における制御メッセージのフレームフォーマット例を示す。
【００８０】
制御メッセージのフレーム４６００は、送信先ＭＡＣアドレス４６０１と、送信元ＭＡＣアドレス４６０２と、拡張タグ格納領域４６０３と、Ｌｅｎｇｔｈ４６０４と、制御メッセージの属性情報４９００と、ＦＣＳ４６０５とから構成される。
【００８１】
送信先ＭＡＣアドレス４６０１には、制御メッセージ専用に定義した宛先ＭＡＣアドレス（ＭＡＣ＿ＤＡ（例えば、MAC_DA=00 00 4C 00 00 02））を格納する。
【００８２】
送信元ＭＡＣアドレス（ＭＡＣ＿ＳＡ）４６０２には、送信元ノードのＭＡＣアドレスを格納する。
【００８３】
拡張タグ格納領域４６０３には、ブロードキャストフォワーディングタグかフォワーディングタグのいずれかの拡張タグを格納する。
【００８４】
Ｌｅｎｇｔｈ４６０４には、制御メッセージの属性情報４９００の長さ情報を格納する。
【００８５】
制御メッセージの属性情報領域４９００には、制御メッセージの種類を示すＴｙｐｅ４９０２と、カスタマ情報４９０３とが格納される。
【００８６】
Ｔｙｐｅ４９０２には、制御メッセージの種別として、Ｑｕｅｒｙ制御メッセージ４７０１、Ｒｅｐｏｒｔ制御メッセージ４７０２の各メッセージを識別するための識別子を格納する。
【００８７】
例えば、Ｔｙｐｅ４９０２のサイズが２ビットであるとすると、Ｔｙｐｅ値（識別子）が「００」であればＱｕｅｒｙ制御メッセージ４７０１を示し、値「０１」であればＲｅｐｏｒｔ制御メッセージ４７０２を示すことができる（各メッセージの動作の詳細に関しては、以降に説明する）。
【００８８】
カスタマ情報４９０３には、マルチキャストテーブル２０２１を更新する際に、追加或いは削除の処理種別と、処理の対象となるカスタマの識別子を格納する。
【００８９】
例えば、カスタマ情報のサイズが１６ビットであるとすると、先頭の１ビットを、カスタマエントリの追加（Ｊｏｉｎ）或いは削除（Ｌｅａｖｅ）を示す識別子であるＪｏｉｎ／Ｌｅａｖｅ４９０４に割り当て、次の１ビットを、処理の対象をカスタマグループメンバーの１つ（Ｏｎｅ）或いは全て（Ａｌｌ）とすることを示す識別子であるＯｎｅ／Ａｌｌ４９０５に割り当て、最後の１３ビットを、マルチキャスト制御の対象となるカスタマの識別子を示すカスタマＩＤ４９０６に割り当てることができる。
【００９０】
本実施の形態の制御メッセージには、自ノードで収容しているカスタマと同じカスタマを収容するノードがネットワーク内に存在するか否かを確認する（問い合わせる）ためのメッセージであるＱｕｅｒｙ制御メッセージ４７０１と、Ｑｕｅｒｙ制御メッセージ４７０１の応答として、問い合わせと同じカスタマを収容している場合に、送信元エッジノードに対しその旨を通知するためのメッセージであるＲｅｐｏｒｔ制御メッセージ４７０２がある。
【００９１】
Ｑｕｅｒｙ制御メッセージ４７０１の場合、拡張タグ格納領域４６０３にブロードキャストフォワーディングタグ４５０８を格納し、Ｔｙｐｅ４９０２にＱｕｅｒｙ制御メッセージ４７０１であることを示す値を格納する。
【００９２】
このＱｕｅｒｙ制御メッセージ４７０１は、新たにカスタマを追加されたノードが、自ノードが送信元となるブロードキャスト転送経路上で（自ノードがルートノードとなるスパニングツリー上で）、他のエッジノードに対してそのカスタマの収容状況を確認する（問い合わせる）ために生成するメッセージである。
【００９３】
Ｒｅｐｏｒｔ制御メッセージ４７０２は、拡張タグ格納領域４６０３にフォワーディングタグ４５００を格納し、Ｔｙｅｐｅ４９０３にＲｅｐｏｒｔ制御メッセージ４７０２であることを示す値を格納して構成する。
【００９４】
Ｒｅｐｏｒｔ制御メッセージ４７０２は、Ｑｕｅｒｙ制御メッセージ４７０１で問い合わせを受けたカスタマを収容する場合に、Ｑｕｅｒｙ制御メッセージ４７０１の送信元ノードに対してその旨を通知するために生成するメッセージである。
【００９５】
（マルチキャストテーブル２０２１の構成例）
続いて、マルチキャストテーブル２０２１について説明する。図７は、本実施例におけるマルチキャストテーブル２０２１の構成例を示す。
【００９６】
マルチキャストテーブル２０２１は、ノードの識別子フィールドと、カスタマＩＤフィールドと、マルチキャスト転送ポートフィールドとマルチキャストテーブルのエントリが有効か無効かを示すＯＮ／ＯＦＦフィールドで構成されている。
【００９７】
ここで、ノードの識別子フィールドには、マルチキャストフレームのブロードキャストフォワーディングタグに格納される送信元ホストが接続されるエッジノードのノード識別子が格納され、カスタマＩＤフィールドには、その送信元ホストが接続されるエッジノードが収容するカスタマの識別子が格納され、マルチキャスト転送ポートフィールドには、前述の送信元エッジノードから受信するマルチキャストフレームの出力ポートがビットマップ形式で記述される。マルチキャスト転送ポートフィールドは、「１」が記述されていると転送可能であると仮定する。
【００９８】
また、ＯＮ／ＯＦＦフィールドは、対応エントリが有効（ＯＮ＝「１」）か無効（ＯＦＦ＝「０」）かを示していて、有効の際は対応エントリの転送ポートが参照できるが、無効の際は対応エントリの転送ポートが参照できなくなる。マルチキャストテーブルの初期状態は、全てのマルチキャスト転送ポートが「０」であり、対応エントリも無効（ＯＦＦ＝「０」）とする。
【００９９】
（第１の実施の形態の動作）
以下、マルチキャストテーブル２０２１の作成方法に関して図３〜図１３を用いて詳細に説明する。
【０１００】
本実施の形態では、図８で示すような２種類の制御メッセージとして、Ｑｕｅｒｙ制御メッセージ４７０１、Ｒｅｐｏｒｔ制御メッセージ４７０２を用いて、ノード２００−１にカスタマ＃ａが追加される場合を例にとって説明する。
【０１０１】
それぞれの制御メッセージは、本実施例の基本動作を説明する図９のシーケンスのうち、図１０、図１１の各状態を示す第１のステップと第２のステップにおいて生成される。
【０１０２】
まず、図９のシーケンスの図１０の状態を示す第１のステップを参照すると、エッジノード２００−１にカスタマ＃ａ（カスタマ＃ａに属するホスト）が追加されると、エッジノード２００−１は、Ｑｕｅｒｙ制御メッセージ４７０１を生成し、マルチキャストテーブル２０２１の該当エントリをクリア（初期状態に戻した後、タイマーを設定して起動する）して、Ｑｕｅｒｙ制御メッセージ４７０１を自ノードがルートノードとなるスパニングツリー上でネットワーク内にブロードキャストする。
【０１０３】
Ｑｕｅｒｙ制御メッセージ４７０１を受信した中継ノード２００−２、２００−３は、マルチキャストテーブル２０２１の該当エントリをクリアした後、Ｑｕｅｒｙ制御メッセージ４７０１を次ホップのノードにブロードキャスト転送する。受信ノード２００−４、２００−５、２００−６、２００−７では、Ｑｕｅｒｙ制御メッセージ４７０１を受信し、マルチキャストテーブル２０２１の該当エントリをクリアする。
【０１０４】
以上説明したＱｕｅｒｙ制御メッセージ４７０１の転送経路と各ノードの処理に関して、図１０で詳細に説明する。図１０では、の転送経路を太い点線で記している。
【０１０５】
エッジノード２００−１にカスタマ＃ａが追加されると、ノード２００−１は制御メッセージ専用のＭＡＣ＿ＤＡ（例えば、MAC_DA=00 00 4C 00 00 02）を用いるＱｕｅｒｙ制御メッセージ４７０１を生成する。
【０１０６】
このＱｕｅｒｙ制御メッセージ４７０１の生成において、拡張タグ格納領域４６０３に自ノードのノード識別子２００−１を格納したブロードキャストフォワーディングタグ４５０８を格納し、制御メッセージの属性情報４９００には、Ｑｕｅｒｙ制御メッセージ４７０１であることを示す値と、カスタマＩＤ（カスタマ＃ａ）、追加（Ｊｏｉｎ）、１つ（ｏｎｅ）等を示す値を格納する。
【０１０７】
ノード２００−１は、マルチキャストテーブル２０２１−１の該当エントリ（送信元ノード、カスタマ＃ａのエントリ）をクリアする。また、ブロードキャストテーブル２２１１−１を参照して、ブロードキャストフォワーディングタグ「ノード２００−１」に対するブロードキャストポート＃２、＃３を取得し、ポート＃２、＃３にＱｕｅｒｙ制御メッセージ４７０１を転送する。マルチキャストテーブルの該当エントリをクリアして「ＯＦＦ」とした場合、ノードは該当エントリに関するマルチキャストフレームを受信したら、マルチキャストテーブルを参照して転送するのではなくて、ブロードキャストテーブルを参照して転送するようにする。
【０１０８】
続いて、Ｑｕｅｒｙ制御メッセージ４７０１を受信した中継ノード２００−２、２００−３は、マルチキャストテーブル２０２１−２、２０２１−３の該当エントリをクリアする。また、ブロードキャストテーブル２２１１−２、２２１１−３を参照して出力ポートを取得し、Ｑｕｅｒｙ制御メッセージ４７０１を転送する。図１０の場合、中継ノード２００−２では、ブロードキャストテーブル２２１１−２を参照して、出力ポート＃２、＃３、＃４を取得し、Ｑｕｅｒｙ制御メッセージ４７０１を当該ポートから転送する。
【０１０９】
中継ノード２００−２、２００−３から転送されたＱｕｅｒｙ制御メッセージ４７０１は、ノード２００−４、２００−５、２００−６、２００−７で受信される。各ノードは、マルチキャストテーブルの該当エントリをクリアする。
【０１１０】
図１０で示すマルチキャストテーブル２０２１−１、２０２１−２、２０２１−５は、それぞれノード２００−１、２００−２、２００−５でＱｕｅｒｙ制御メッセージ４７０１を受信した後のマルチキャストテーブルの状態を示している。
【０１１１】
上述のＱｕｅｒｙ制御メッセージ４７０１の送受信に関しての動作を図３のノード構成に基づいて説明する。最初に送信元エッジノード２００−１について説明する。
【０１１２】
設定ＩＦ２５００経由でカスタマ＃ａの追加情報を受信したカスタマ管理モジュール２０１６は、カスタマ識別テーブル２０１７を更新すると共に、マルチキャスト制御部２０２０に対して、カスタマ＃ａに関する変更情報（追加情報）を通知する。
【０１１３】
カスタマ管理モジュール２０１６からカスタマ＃ａのカスタマ変更情報を受信したマルチキャスト制御部２０２０は、Ｑｕｅｒｙ制御メッセージ４７０１を生成して、マルチキャストテーブル２０２１−１の該当エントリをクリアする。続いて、Ｑｕｅｒｙ制御メッセージ４７０１をタグスイッチ部２０１３に送信する。
【０１１４】
タグスイッチ部２０１３では、フォワーディングテーブル格納部２０１８内のブロードキャストテーブル２２１１−１を参照して、Ｑｕｅｒｙ制御メッセージ４７０１を所定の出力ポート２２０−ｏｕｔに転送する。
【０１１５】
続いて、中継ノード２００−２、２００−３について説明する。
【０１１６】
Ｑｕｅｒｙ制御メッセージ４７０１を受信したフレーム解析部２０１１は、マルチキャスト制御メッセージであるため、マルチキャスト制御部２０２０に転送する。
【０１１７】
マルチキャスト制御部２０２０でフレーム解析部２０１１から受信したＱｕｅｒｙ制御メッセージ４７０１のＴｙｅｐｅ４９０２を参照して、Ｑｕｅｒｙ制御メッセージ４７０１であることを示す値が格納されているため、マルチキャストテーブル２０２１の該当エントリをクリアして、制御メッセージをタグスイッチ部２０１３に転送する。
【０１１８】
タグスイッチ部２０１３は、フォワーディングテーブル格納部２０１８内のブロードキャストテーブル２２１１を参照して、Ｑｕｅｒｙ制御メッセージ４７０１に格納されるブロードキャストフォワーディングタグに対する出力ポートを取得し、所定の出力ポート２２０−ｏｕｔに転送する。
【０１１９】
続いて、ノード２００−４〜２００−７について説明する。
【０１２０】
Ｑｕｅｒｙ制御メッセージ４７０１を受信したフレーム解析部２０１１は、マルチキャスト制御メッセージであるため、マルチキャスト制御部２０２０に転送する。マルチキャスト制御部２０２０でフレーム解析部２０１１から受信したＱｕｅｒｙ制御メッセージ４７０１のＴｙｅｐｅ４９０２を参照して、Ｑｕｅｒｙ制御メッセージ４７０１であることを示す値が格納されているため、マルチキャストテーブルの該当エントリをクリアした後、図９のシーケンスの次の第２のステップとして、図１１の状態で示される処理を行う。
【０１２１】
続いて、図９のシーケンスにおける図１１の状態を示す第２のステップについて説明する。
【０１２２】
図９のシーケンスの図１１の状態を示す第２のステップを参照すると、Ｑｕｅｒｙ制御メッセージ４７０１を受信した受信ノード２００−４、２００−５、２００−６、２００−７では、自ノードの配下に同じカスタマ＃ａを収容していれば、Ｑｕｅｒｙ制御メッセージ４７０１の応答としてＲｅｐｏｒｔ制御メッセージ４７０２を生成し、Ｑｕｅｒｙ制御メッセージ４７０１の送信元ノードであるノード２００−１に対しＲｅｐｏｒｔ制御メッセージ４７０２をユニキャスト転送し、マルチキャストテーブルの対応エントリを更新する。
【０１２３】
また、Ｒｅｐｏｒｔ制御メッセージ４７０２を受信した中継ノード２００−２では、Ｒｅｐｏｒｔ制御メッセージ４７０２の受信ポートを学習して、マルチキャストテーブル２０２１−２を更新し、Ｒｅｐｏｒｔ制御メッセージ４７０２を次ホップのノードに転送する。Ｒｅｐｏｒｔ制御メッセージ４７０２を受信した送信元ノード２００−１では、中継ノード２００−２と同様に、受信したＲｅｐｏｒｔ制御メッセージ４７０２の受信ポートを学習して、マルチキャストテーブル２０２１−１の対応エントリを更新する。
【０１２４】
以上説明したＲｅｐｏｒｔ制御メッセージ４７０２の転送経路と各ノードの処理に関して、図１１で詳細に説明する。図１１では、Ｒｅｐｏｒｔ制御メッセージ４７０２の転送経路を太い点線で記している。
【０１２５】
エッジノード２００−４、２００−５、２００−６、２００−７では、Ｑｕｅｒｙ制御メッセージ４７０１を受信した後、自ノードの配下に同じカスタマを収容しているかをサーチする。
【０１２６】
エッジノード２００−５は、ポート＃３にカスタマ＃ａのホストＢが接続されているため、Ｒｅｐｏｒｔ制御メッセージ４７０２を生成する。Ｒｅｐｏｒｔ制御メッセージ４７０２の生成において、拡張タグ格納領域４６０３にフォワーディングタグ４５００（対応するＱｕｅｒｙ制御メッセージ４７０１の送信元ノードのノード識別子２００−１）を格納し、制御メッセージの属性情報のＴｙｅｐｅ４９０２にＲｅｐｏｒｔ制御メッセージ４７０２であることを示す値を格納し、カスタマ情報４９０３に、カスタマ＃ａ、追加（Ｊｏｉｎ）、１つ（ｏｎｅ）等の値を格納する。また、マルチキャストテーブル２０２１−５の「送信元（ホストが接続される）ノード２００−１、カスタマ＃ａ」のエントリに対して、カスタマ識別テーブル３１０５（図５５を参照）から取得したカスタマ#aの接続ポート＃３のビットを「１」に更新し、該当エントリを「ＯＮ」（値「１」）にする。または、マルチキャストテーブルのエントリをクリアする際に設定するテーブル有効タイマーがタイマーアップすることにより、各ノードでは該当エントリを「ＯＮ」にする。
【０１２７】
さらに、エッジノード２００−５は、ユニキャストテーブル２２１２−５を参照して、フォワーディングタグ２００−１に対する出力ポートとしてポート＃１を取得し、ポート＃１からＲｅｐｏｒｔ制御メッセージ４７０２を転送する。
【０１２８】
一方、他のエッジノード２００−４、２００−６、２００−７は、Ｑｕｅｒｙ制御メッセージ４７０１に含まれるカスタマ＃ａを収容していないため、Ｒｅｐｏｒｔ制御メッセージ４７０２を生成せずに処理を終了する。
【０１２９】
続いて、中継ノード２００−２では、受信した制御メッセージがＲｅｐｏｒｔ制御メッセージ４７０２であれば、Ｒｅｐｏｒｔ制御メッセージ４７０２の格納情報から、フォワーディングタグ「送信元エッジノード２００−１」と、カスタマ情報「＃ａ」と、受信ポート「ポート＃３」とを学習し、マルチキャストテーブル２０２１−２において「送信元ノード２００−１、カスタマ＃ａ」のエントリに関して、Ｒｅｐｏｒｔ制御メッセージ４７０２を受信したポート＃３のビットを「１」に更新し、該当エントリを「ＯＮ」にする。
【０１３０】
続いて、中継ノード２００−２は、ユニキャストテーブル２２１２−２を参照して、フォワーディングタグ「２００−１」に対する出力ポートとしてポート＃１を取得し、Ｒｅｐｏｒｔ制御メッセージ４７０２をポート＃１に転送する。
【０１３１】
続いて、送信元ノード２００−１では、受信した制御メッセージがＲｅｐｏｒｔ制御メッセージ４７０２であれば、Ｒｅｐｏｒｔ制御メッセージ４７０２の格納情報から、フォワーディングタグ「送信元エッジノード２００−１」と、カスタマ情報（＃ａ）と、受信ポート（ポート＃２）とを学習し、マルチキャストテーブル２０２１−１において「送信元ノード２００−１、カスタマ＃ａ」のエントリに関して、Ｒｅｐｏｒｔ制御メッセージ４７０２を受信したポート＃２のビットを「１」に更新し、該当エントリを「ＯＮ」にする。
【０１３２】
図１１の右側に示されたマルチキャストテーブル２０２１−１、２０２１−２、２０２１−５は、それぞれノード２００−１、２００−２、２００−５でのＲｅｐｏｒｔ制御メッセージ４７０２を受信した後のマルチキャストテーブルの状態を示しており、それぞれＲｅｐｏｒｔ制御メッセージ４７０２の受信ポートのビットが「１」（ＯＮ）となり、それ以外のポートのビットが「０」（ＯＦＦ）となっている。
【０１３３】
上述のＲｅｐｏｒｔ制御メッセージ４７０２の送受信に関しての動作を図３のノード構成に基づいて説明する。最初に受信エッジノード２００−５について説明する。
【０１３４】
Ｑｕｅｒｙ制御メッセージ４７０１を受信したマルチキャスト制御部２０２０は、カスタマ管理モジュール２０１６に対して、自ノードでカスタマ＃ａを収容しているかどうかを問い合わせる。
【０１３５】
カスタマ管理モジュール２０１６はカスタマ識別テーブル２０１７を参照してカスタマ＃ａの接続状況（ポート＃３にカスタマ＃ａのホストＢが接続）を取得する。カスタマ管理モジュール２０１６は、カスタマ＃ａの接続ポート＃３をマルチキャスト制御部２０２０に通知し、マルチキャスト制御部２０２０は、マルチキャストテーブル２０２１のカスタマ＃ａのエントリを更新（ポート＃３のビットを「１」にし、該当エントリを「ＯＮ」にする）する。
【０１３６】
また、マルチキャスト制御部２０２０は、カスタマ＃ａに関するＲｅｐｏｒｔ制御メッセージ４７０２を生成して、タグスイッチ部２０１３に転送する。タグスイッチ部２０１３はフォワーディングテーブル格納部２０１８内のユニキャストテーブル２２１２−５を参照して、Ｒｅｐｏｒｔ制御メッセージ４７０２を所定のポート（ポート＃１）に出力する。
【０１３７】
なお、カスタマ管理モジュール２０１６からの回答が該当カスタマ無しの場合、Ｒｅｐｏｒｔ制御メッセージ４７０２を生成しない。
【０１３８】
続いて、中継ノード２００−２について説明する。
【０１３９】
Ｒｅｐｏｒｔ制御メッセージ４７０２を受信したフレーム解析部２０１１は、マルチキャスト制御メッセージであるため、マルチキャスト制御部２０２０に転送する。
【０１４０】
マルチキャスト制御部２０２０では、フレーム解析部２０１１から受信したＲｅｐｏｒｔ制御メッセージ４７０２のＴｙｅｐｅ４９０２を参照して、Ｒｅｐｏｒｔ制御メッセージ４７０２であることを示す値が格納されているため、メッセージをタグスイッチ部２０１３に転送する。
【０１４１】
同時に、Ｒｅｐｏｒｔ制御メッセージ４７０２の受信ポートに関して、マルチキャストテーブル２０２１−２を更新する。タグスイッチ部２０１３は、フォワーディングテーブル格納部２０１８内のユニキャストテーブル２２１２−２を参照して、Ｒｅｐｏｒｔ制御メッセージ４７０２に格納されるフォワーディングタグに対する出力ポートを取得し、所定の出力ポート２２０−ｏｕｔに転送する。
【０１４２】
続いて、送信元ノード２００−１について説明する。
【０１４３】
Ｒｅｐｏｒｔ制御メッセージ４７０２を受信したフレーム解析部２０１１は、マルチキャスト制御メッセージであるため、マルチキャスト制御部２０２０に転送する。
【０１４４】
マルチキャスト制御部２０２０では、フレーム解析部２０１１から受信したＲｅｐｏｒｔ制御メッセージ４７０２のＴｙｅｐｅ４９０２を参照して、Ｒｅｐｏｒｔ制御メッセージ４７０２であることを示す値が格納されているため、Ｒｅｐｏｒｔ制御メッセージ４７０２の受信ポートに関して、マルチキャストテーブル２０２１を更新する。Ｒｅｐｏｒｔ制御メッセージ４７０２に関してはそれを廃棄する。
【０１４５】
（マルチキャストテーブルにおける、マルチキャストフレームの転送方法）
以下に、上述のマルチキャストテーブルの作成方法によって生成されたマルチキャストテーブルを参照することにより、マルチキャストフレームを転送する本実施の形態のマルチキャスト転送方法について詳細に説明する。
【０１４６】
図１２は、本発明の拡張タグ付きフレームを転送するネットワーク２３００において、ノード２００−１から送信されるマルチキャストフレームに関する転送経路と各ノードのマルチキャストテーブル２０２１−１、２０２１−２、２０２１−５の状態を示している。各ノードのマルチキャストテーブル２０２１−１、２０２１−２、２０２１−５は、図９から１１で説明した手順により作成した内容となっている。また、ノード２００−１からのマルチキャスト転送経路を太線で示している。以降では、図３のノード構成も参照して説明する。
【０１４７】
まず、入口側のエッジノード２００−１の処理について説明する。
【０１４８】
ノード２００−１では、ポート＃１でカスタマ＃ａのホストＡから、送信先ＭＡＣアドレスが「ＭＡＣ＿ＤＡ＝０ｘＦＦＦＦ」であるブロードキャストフレームを受信する。
【０１４９】
ノード２００−１のフレーム解析部２０１１は、受信フレームが通常イーサネット（Ｒ）フレームであるため、タグ挿入部２０１２にフレームを転送する。タグ挿入部２０１２は、受信フレームのＭＡＣ＿ＤＡが「０ｘＦＦＦＦ」であるため、ブロードキャストフォワーディングタグとして、フレームの拡張タグ格納領域４３０１に自ノードのノード識別子「２００−１」を格納する。
【０１５０】
また、カスタマ識別テーブル２０１７（図３）を参照して、入力ポート＃１に対するカスタマＩＤ＝＃ａを取得し、カスタマタグとして、フレームの拡張タグ格納領域４３０１にカスタマＩＤ＝＃ａを更に格納する。タグ挿入部２０１２は、両方のタグを付加したフレームをタグスイッチ部２０１３に転送する。
【０１５１】
タグスイッチ部２０１３は、マルチキャストテーブル２０２１−１（図１２）を参照して、該当エントリ状態が「ＯＮ」であれば、「ノード２００−１、カスタマ＃ａ」に対する出力ポート＃２を取得し、ポート＃２にマルチキャストフレームを出力する。該当エントリ状態が「ＯＦＦ」であれば、タグスイッチ部２０１３内のテーブル検索部２１０２（図４を参照）は、フォワーディングテーブル格納部２０１８内のブロードキャストテーブル２２１１（図５を参照）を参照する。
【０１５２】
この例では、該当エントリ状態が「ＯＮ」であるので、エッジノード２００−１から出力されたフレームは、中継ノード２００−２のみに転送される。
【０１５３】
続いて、中継ノード２００−２の処理について説明する。
【０１５４】
ノード２００−２のフレーム解析部２０１１は、受信フレームが拡張タグ付きフレームであるため、フレームをタグスイッチ部２０１３に転送する。
【０１５５】
タグスイッチ部２０１３はマルチキャストテーブル２０２１−２（図１２）を参照して、該当エントリ状態が「ＯＮ」であれば、「ノード２００−１、カスタマ＃ａ」に対する出力ポート＃３を取得し、ポート＃３にマルチキャストフレームを出力する。該当エントリ状態が「ＯＦＦ」であれば、タグスイッチ部２０１３内のテーブル検索部２１０２（図４を参照）は、フォワーディングテーブル格納部２０１８内のブロードキャストテーブル２２１１（図５を参照）を参照する。
【０１５６】
この例では、該当エントリ状態が「ＯＮ」であるので、中継ノード２００−２から出力されたフレームはエッジノード２００−５のみに転送される。
【０１５７】
続いて、出口側のエッジノード２００−５の処理について説明する。
【０１５８】
ノード２００−５のフレーム解析部２０１１は、受信フレームが拡張タグ付きフレームであるため、フレームをタグスイッチ部２０１３に転送する。タグスイッチ部２０１３はマルチキャストテーブル２０２１−５（図１２）を参照して、該当エントリ状態が「ＯＮ」であれば、「ノード２００−１、カスタマ＃ａ」に対する出力ポート＃３を取得する。取得したポートがホスト側ポートである場合はタグ削除部２０１４に転送する。取得したポートがネットワーク側ポートである場合は出力ポート２２０−ｏｕｔにフレームを転送する。
【０１５９】
この例では、出力ポート＃３はホスト側ポートであるため、フレームがタグ削除部２０１４に転送される。タグ削除部２０１４は受信フレームのブロードキャストフォワーディングタグとカスタマ分離タグを削除して、通常のイーサネット（Ｒ）フレームに変換して出力ポート２１０−ｏｕｔ（出力ポート＃３）に転送する。また、該当エントリ状態が「ＯＦＦ」であれば、タグスイッチ部２０１３内のテーブル検索部２１０２（図４を参照）は、フォワーディングテーブル格納部２０１８内のブロードキャストテーブル２２１１（図５を参照）を参照する。
【０１６０】
この例では、該当エントリ状態が「ＯＮ」であるので、ノード２００−５から転送されたフレームはホストＢに到着する。
【０１６１】
以上説明したように、カスタマ＃ａのホストＡから送信されたブロードキャストフレームは、ネットワーク内において、ホストＡが接続するエッジノード２００−１とカスタマ＃ａの他のホストであるホストＢが接続するエッジノード２００−５間の最短経路上のみをフレーム転送され、ホストＢに到着することになる。すなわち、カスタマによって関連付けられた経路上のみでのマルチキャスト転送を実現している。
【０１６２】
以上、カスタマが追加される際に、マルチキャストテーブルを更新する方法と、マルチキャストテーブルを参照してマルチキャストフレームを転送する方法を説明した。
【０１６３】
図１３は、ノード２００−１からカスタマ＃ａが削除される場合の手順を示す図である。図１３を参照すると、カスタマが削除される際は、Ｑｕｅｒｙ制御メッセージ４７０１（Ｌｅａｖｅ）を生成して、その制御メッセージをネットワークにブロードキャストし、マルチキャストテーブル２０２１の対応のエントリを削除する。
【０１６４】
すなわち、図１３で示すように、カスタマ＃ａが削除されるノード２００−１では、Ｑｕｅｒｙ制御メッセージ４７０１（Ｌｅａｖｅ）を生成して、その制御メッセージをネットワーク（自ノードがルートノードとなるスパニングツリー）にブロードキャストする。
【０１６５】
このＱｕｅｒｙ制御メッセージ４７０１（Ｌｅａｖｅ）のブロードキャストにより、ノード２００−１、中継ノード２００−２と２００−３、受信ノード２００−４〜２００−７の各ノードは、マルチキャストテーブル２０２１の対応のエントリ（送信元ノード２００−１、カスタマ＃ａ）を削除する。図１３では、ノード２００−１、２００−２、２００−５の各マルチキャストテーブル２０２１−１、２０２１−２、２０２１−５の対応するエントリが削除された状態を示している。マルチキャストフレームを転送する際に、マルチキャストテーブルのエントリを参照して転送するが、該当エントリが存在しない場合は、該当エントリが「ＯＦＦ」である場合と同じ処理を行う。
【０１６６】
カスタマを削除する場合の他の処理については、カスタマを追加する際にＱｕｅｒｙ制御メッセージ４７０１を送信する場合と同じであるためその詳細を省略する。
【０１６７】
上述の説明では、各エッジノードが、自ノードに属する（接続する）全てのホストが属するカスタマ情報がカスタマ識別テーブル２０１７に事前に登録されていることを前提としている。例えば、図３８で示したと同じように、ノード２００−５のポート＃３に接続されているホストＢがカスタマ＃ａに属するものである事がカスタマ識別テーブル２０１７（図３）に事前に登録されていることを前提としている。
【０１６８】
続いて、エッジノードに属する（接続する）ホストのカスタマ情報がカスタマ識別テーブル２０１７に事前に登録されていない場合の処理に関して説明する。
【０１６９】
例えば、図４７で示すように、ノード２００−５のカスタマ識別テーブル２０１７−５にカスタマ情報が登録されていない（例えば、ポート＃３に接続するホストＢが属するカスタマの情報が登録されていない）場合は以下のような処理を行う。
【０１７０】
図４８のフローチャートで示すように、ステップ５１０１で、Ｑｕｅｒｙ制御メッセージ４７０１（例えば、Ｊｏｉｎメッセージ）を受信したエッジノードでは、カスタマ識別テーブル２０１７を検索してカスタマ情報が登録されていないエントリがあるかどうかを判別し（ステップ５１０２）、登録されていないエントリがあれば、すべてのダウンリンクポートに対して、該当カスタマに参加する（属する）ホストがあるかを確認する問い合わせメッセージ（例えば、ＩＧＭＰ  Ｊｏｉｎメッセージ等）を送信する（ステップ５１０３）。
【０１７１】
問い合わせメッセージを送信した後、タイマーを起動し（ステップ５１０４）、カスタマに参加する旨を示す返答メッセージを受信すると（ステップ５１０５）、カスタマ識別テーブル２０１７を更新して（ステップ５１０６）、該当カスタマに関するＲｅｐｏｒｔ制御メッセージ４７０２を生成し、図４９で示すように送信する（ステップ５１０７）。逆に、設定されたタイマー以内に返答メッセージが送信されない場合は、Ｒｅｐｏｒｔ制御メッセージ４７０２を生成しない。
【０１７２】
（第１の実施の形態による効果）
以上説明した第１の実施の形態のマルチキャスト転送方法の効果について説明する。
【０１７３】
従来方法では、送信元ノードがルートノードになるスパニングツリー上でマルチキャストフレームを転送する際は、同じカスタマがいない経路にもフラッディングされていた。
【０１７４】
これに対して、第１の実施の形態による転送方法では、送信元ノードからのブロードキャスト転送経路上（送信元ノードがルートノードになるスパニングツリー上）でカスタマの収容状況を問い合わせるＱｕｅｒｙ制御メッセージを送信し、そのカスタマを収容する他のエッジノードがＲｅｐｏｒｔ制御メッセージを返信し、経路上の各ノードがＲｅｐｏｒｔ制御メッセージの受信ポートをそのカスタマに関するブロードキャストポートとしてマルチキャストテーブルに学習する。ネットワーク内の各ノードは、マルチキャストフレームを転送する際に、本マルチキャストテーブルを参照して出力ポートを決定することにより、カスタマと関係ある経路のみにフレームを転送することが可能となる。
【０１７５】
すなわち、本実施の形態によれば、例えばレイヤ２の拡張タグネットワークにおいて、マルチキャストフレームを転送する際に、カスタマと関係ある経路のみにフレームを転送し、それにより効率的なマルチキャスト転送を行うことができる。
【０１７６】
（第２の実施の形態）
本発明の第２の実施の形態による、マルチキャストテーブル作成の基本方式及びマルチキャストフレーム転送方法について説明する。
【０１７７】
本第２の実施の形態よる拡張タグ付きフレームを転送するネットワーク２３００については、図１に示した第１の実施の形態と同様であり、かつ、その各ノードの構成についても、図３〜図６に示した構成と同じであるため、それらの詳細は省略する。
【０１７８】
第２の実施の形態におけるマルチキャストテーブル作成方法については、図１５で示すように、送信元エッジノードでは、自ノードに収容しているカスタマの接続状況に変更が起こった場合に、その変更が生じたカスタマがサービス中であるノードが存在するか否かを確認するためのＱｕｅｒｙ制御メッセージであるＱｕｅｒｙ１メッセージ４７０１−１を全ネットワーク上に（自ノードがルートノードとなるスパニングツリー上で）ブロードキャスト転送する。
【０１７９】
一方、Ｑｕｅｒｙ１メッセージ４７０１−１を受信した他のエッジノードのうち、同じカスタマを収容している他のエッジノードからは、Ｑｕｅｒｙ１メッセージ４７０１−１への応答として、サービス中の同一カスタマを収容していることを送信元エッジノードに通知するためのＲｅｐｏｒｔ制御メッセージであるＲｅｐｏｒｔ１メッセージ４７０２−１を送信元のエッジノードに返信する。
【０１８０】
転送経路上でＲｅｐｏｒｔ１メッセージ４７０２−１を受信したノードは、Ｒｅｐｏｒｔ１メッセージ４７０２−１の受信ポートをマルチキャストテーブルに記録する。この処理により、転送経路の下流方向に同一カスタマが存在するか否かを知ることができ、同一カスタマが存在する経路のみにフレーム転送することが可能となる。
【０１８１】
ここまでは、上述した第１の実施の形態によるマルチキャストテーブル作成方法と同じであるが、この第２の実施の形態では、さらに、Ｒｅｐｏｒｔ１メッセージ４７０２−１を返信したエッジノードが、最初に受信したメッセージがＱｕｅｒｙ１メッセージ４７０１−１である場合、Ｒｅｐｏｒｔ１メッセージ４７０２−１を送信した後に、自ノード配下の（接続される）カスタマと同じカスタマを収容するノードが存在するか否かを確認するためのＱｕｅｒｙ制御メッセージであるＱｕｅｒｙ２メッセージ４７０１−２を全ネットワーク上に（自ノードがルートノードとなるスパニングツリー上で）ブロードキャスト転送する。
【０１８２】
Ｑｕｅｒｙ２メッセージ４７０１−２を受信した他のエッジノードのうち、同じカスタマを収容している他のエッジノードからは、Ｑｕｅｒｙ２メッセージ４７０１−２への応答として、サービス中の同一カスタマを収容していることを送信元エッジノードに通知するためのＲｅｐｏｒｔ制御メッセージであるＲｅｐｏｒｔ２メッセージ４７０２−２を送信元のエッジノードに返信する。
【０１８３】
転送経路上でＲｅｐｏｒｔ２メッセージ４７０２−２を受信したノードは、Ｒｅｐｏｒｔ２メッセージ４７０２−２の受信ポートをマルチキャストテーブルに記録する。この処理により、Ｒｅｐｏｒｔ１メッセージ４７０２−１を返信したエッジノードから見た下流方向に同一カスタマが存在するか否かを知ることができ、同一カスタマが存在する経路のみにフレーム転送することが可能となる。
【０１８４】
以下、本実施の形態の制御メッセージ（Ｑｕｅｒｙ制御メッセージ、Ｒｅｐｏｒｔ制御メッセージ）のフォーマット、マルチキャストテーブルの構成についても、第１の実施の形態で示した図３〜図７と同様であるので、ここでは、第１の実施の形態との相違点のみを説明する。
【０１８５】
本実施の形態では図１４で示すように、制御メッセージとしてＱｕｅｒｙ１メッセージ４７０１−１、Ｒｅｐｏｒｔ１メッセージ４７０２−１、Ｑｕｅｒｙ２メッセージ４７０１−２、Ｒｅｐｏｒｔ２メッセージ４７０２−２の４種類を用いる。上述の４種類の制御メッセージは図６で示すフレームフォーマットのＴｙｐｅ４９０２に、制御メッセージの種別として、Ｑｕｅｒｙ１メッセージ４７０１−１、Ｒｅｐｏｒｔ１メッセージ４７０２−１、Ｑｕｅｒｙ２メッセージ４７０１−２、Ｒｅｐｏｒｔ２メッセージ４７０２−２の各メッセージを識別するための識別子を格納する。
【０１８６】
例えば、Ｔｙｐｅ４９０２のサイズが３ビットであるとすると、Ｔｙｐｅ値（識別子）が「０００」であればＱｕｅｒｙ１メッセージ４７０１−１を示し、値「００１」であればＲｅｐｏｒｔ１メッセージ４７０２−１を示し、値「０１０」であればＱｕｅｒｙ２メッセージ４７０１−２を示し、値「０１１」であればＲｅｐｏｒｔ２メッセージ４７０２−２を示すことができる。
【０１８７】
上記のように、本実施の形態の制御メッセージには、自ノードで収容しているカスタマと同じカスタマを収容するノードがネットワーク内に存在するか否かを確認する（問い合わせる）ためのＱｕｅｒｙ制御メッセージとして、Ｑｕｅｒｙ１メッセージ４７０１−１とＱｕｅｒｙ２メッセージ４７０１−２を用いる。また、Ｑｕｅｒｙ１メッセージ４７０１−１とＱｕｅｒｙ２メッセージ４７０１−２の応答として、問い合わせと同じカスタマを収容している場合に、Ｑｕｅｒｙ制御メッセージの送信元エッジノードに対しその旨を通知するためのＲｅｐｏｒｔ制御メッセージとして、Ｒｅｐｏｒｔ１メッセージ４７０２−１とＲｅｐｏｒｔ１メッセージ４７０２−１を用いる。
【０１８８】
Ｑｕｅｒｙ制御メッセージ（Ｑｕｅｒｙ１メッセージ４７０１−１或いはＱｕｅｒｙ２メッセージ４７０１−２）の場合、フレームの拡張タグ格納領域４６０３にブロードキャストフォワーディングタグ４５０８を格納し、Ｔｙｐｅ４９０２にＱｕｅｒｙ１メッセージ４７０１−１或いはＱｕｅｒｙ２メッセージ４７０１−２を示す値を格納する。
【０１８９】
Ｑｕｅｒｙ１メッセージ４７０１−１は、新たにカスタマを追加されたノードが、自ノードが送信元となるブロードキャスト転送経路上で（自ノードがルートノードとなるスパニングツリー上で）、他のエッジノードに対してそのカスタマの収容状況を確認する（問い合わせる）ために生成するメッセージである。
【０１９０】
一方、Ｑｕｅｒｙ２メッセージ４７０１−２は、Ｒｅｐｏｒｔ１メッセージ４７０２−１を返信したノードが、自ノードが送信元となるブロードキャスト転送経路上で（自ノードがルートノードとなるスパニングツリー上で）、他のエッジノードに対してそのカスタマの収容状況を確認するために生成するメッセージである。
【０１９１】
Ｒｅｐｏｒｔメッセージ（Ｒｅｐｏｒｔ１メッセージ４７０２−１或いはＲｅｐｏｒｔ２メッセージ４７０２−２）は、フレームの拡張タグ格納領域４６０３にフォワーディングタグ４５００を格納し、Ｔｙｅｐｅ４９０２にＲｅｐｏｒｔ１メッセージ４７０２−１或いはＲｅｐｏｒｔ２メッセージ４７０２−２を示す値を格納して構成する。
【０１９２】
Ｒｅｐｏｒｔ１メッセージ４７０２−１は、Ｑｕｅｒｙ１メッセージ４７０１−１で問い合わせを受けたカスタマを収容する場合に、Ｑｕｅｒｙ１メッセージ４７０１−１の送信元ノードに対してその旨を通知するために送信するメッセージである。
【０１９３】
一方、Ｒｅｐｏｒｔ２メッセージ４７０２−２は、Ｑｕｅｒｙ２メッセージ４７０１−２で問い合わせを受けたカスタマを収容する場合に、Ｑｕｅｒｙ２メッセージ４７０１−２の送信元ノードに対してその旨を通知するために送信するメッセージである。
【０１９４】
（第２の実施の形態の動作）
以下、第２の実施の形態によるマルチキャストテーブル２０２１の作成方法に関して図３〜図７、図１４〜図２１を用いて詳細に説明する。
【０１９５】
第２の実施の形態では、図１４で示すような４種類の制御メッセージとして、Ｑｕｅｒｙ１メッセージ４７０１−１、Ｒｅｐｏｒｔ１メッセージ４７０２−１、Ｑｕｅｒｙ２メッセージ４７０１−２、Ｒｅｐｏｒｔ２メッセージ４７０２−２を用いて、ノード２００−１にカスタマ＃ａが追加される場合を例にとって説明する。それぞれの制御メッセージは、本実施例の基本動作を説明する図１５のシーケンスのうち、図１６から図１９の各状態を示す第１から第４のステップにおいて生成される。
【０１９６】
まず、図１５のシーケンスの図１６の状態を示す第１のステップを参照すると、エッジノード２００−１にカスタマ＃ａ（カスタマ＃ａに属するホスト）が追加されると、エッジノード２００−１は、Ｑｕｅｒｙ１メッセージ４７０１−１を生成し、マルチキャストテーブル２０２１の該当エントリをクリアして、Ｑｕｅｒｙ１メッセージ４７０１−１を自ノードがルートノードとなるスパニングツリー上でネットワーク内にブロードキャストする。
【０１９７】
Ｑｕｅｒｙ１メッセージ４７０１−１を受信した中継ノード２００−２、２００−３は、マルチキャストテーブル２０２１の該当エントリをクリアした後、Ｑｕｅｒｙ１メッセージ４７０１−１を次ホップのノードにブロードキャスト転送する。受信ノード２００−４、２００−５、２００−６、２００−７では、Ｑｕｅｒｙ１メッセージ４７０１−１を受信し、マルチキャストテーブル２０２１の該当エントリをクリアする。
【０１９８】
以上説明したＱｕｅｒｙ１メッセージ４７０１−１の転送経路と各ノードの処理に関して、図１６で詳細に説明する。図１６では、Ｑｕｅｒｙ１メッセージ４７０１−１の転送経路を点線で記している。
【０１９９】
エッジノード２００−１にカスタマ＃ａが追加されると、ノード２００−１は制御メッセージ専用のＭＡＣ＿ＤＡ（例えば、MAC_DA=00 00 4C 00 00 02）を用いるＱｕｅｒｙ１メッセージ４７０１−１を生成する。
【０２００】
このＱｕｅｒｙ１メッセージ４７０１−１の生成において、フレームの拡張タグ格納領域４６０３に自ノードのノード識別子２００−１を格納したブロードキャストフォワーディングタグ４５０８を格納し、制御メッセージの属性情報４９００には、Ｑｕｅｒｙ１メッセージ４７０１−１であることを示す値と、カスタマＩＤ（カスタマ＃ａ）、追加（Ｊｏｉｎ）、１つ（ｏｎｅ）等を示す値を格納する。
【０２０１】
ノード２００−１は、マルチキャストテーブル２０２１−１の該当エントリ（送信元ノード、カスタマ＃ａのエントリ）をクリアする。また、ブロードキャストテーブル２２１１−１を参照して、ブロードキャストフォワーディングタグ「ノード２００−１」に対応するブロードキャストポート＃２、＃３を取得し、ポート＃２、＃３に転送する。マルチキャストテーブルの該当エントリをクリアして「ＯＦＦ」とした場合、ノードは該当エントリに関するマルチキャストフレームを受信したら、マルチキャストテーブルを参照して転送するのではなくて、ブロードキャストテーブルを参照して転送するようにする。
【０２０２】
続いて、Ｑｕｅｒｙ１メッセージ４７０１−１を受信した中継ノード２００−２、２００−３は、マルチキャストテーブル２０２１−２、２０２１−３の該当エントリをクリアする。また、ブロードキャストテーブル２２１１−２、２２１１−３を参照して出力ポートを取得し、Ｑｕｅｒｙ１メッセージ４７０１−１を転送する。図１６の場合、中継ノード２００−２では、ブロードキャストテーブル２２１１−２を参照して、出力ポート＃２、＃３、＃４を取得し、Ｑｕｅｒｙ１メッセージ４７０１−１を当該ポートから転送する。
【０２０３】
中継ノード２００−２、２００−３から転送されたＱｕｅｒｙ１メッセージ４７０１−１は、ノード２００−４、２００−５、２００−６、２００−７で受信される。各ノードは、マルチキャストテーブルの該当エントリをクリアする。
【０２０４】
図１６で示すマルチキャストテーブル２０２１−１、２０２１−２、２０２１−５は、それぞれノード２００−１、２００−２、２００−５でＱｕｅｒｙ１メッセージ４７０１−１を受信した後のマルチキャストテーブルの状態を示している。
【０２０５】
上述のＱｕｅｒｙ１メッセージ４７０１−１の送受信に関しての動作を図３のノード構成に基づいて説明する。最初に送信元エッジノード２００−１について説明する。
【０２０６】
設定ＩＦ２５００経由でカスタマ＃ａの追加情報を受信したカスタマ管理モジュール２０１６は、カスタマ識別テーブル２０１７を更新すると共に、マルチキャスト制御部２０２０に対して、カスタマ＃ａに関する変更情報（追加情報）を通知する。
【０２０７】
カスタマ管理モジュール２０１６からカスタマ＃ａのカスタマ変更情報を受信したマルチキャスト制御部２０２０は、Ｑｕｅｒｙ１メッセージ４７０１−１を生成して、マルチキャストテーブル２０２１−１の該当エントリをクリアする。続いて、Ｑｕｅｒｙ１メッセージ４７０１−１をタグスイッチ部２０１３に送信する。
【０２０８】
タグスイッチ部２０１３では、フォワーディングテーブル格納部２０１８内のブロードキャストテーブル２２１１−１を参照して、Ｑｕｅｒｙ１メッセージ４７０１−１を所定の出力ポート２２０−ｏｕｔに転送する。
【０２０９】
続いて、中継ノード２００−２、２００−３について説明する。
【０２１０】
Ｑｕｅｒｙ１メッセージ４７０１−１を受信したフレーム解析部２０１１は、マルチキャスト制御メッセージであるため、マルチキャスト制御部２０２０に転送する。
【０２１１】
マルチキャスト制御部２０２０でフレーム解析部２０１１から受信したＱｕｅｒｙ１メッセージ４７０１−１のＴｙｅｐｅ４９０２を参照して、Ｑｕｅｒｙ１メッセージ４７０１−１であることを示す値が格納されているため、マルチキャストテーブル２０２１の該当エントリをクリアして、制御メッセージをタグスイッチ部２０１３に転送する。
【０２１２】
タグスイッチ部２０１３は、フォワーディングテーブル格納部２０１８内のブロードキャストテーブル２２１１を参照して、Ｑｕｅｒｙ１メッセージ４７０１−１に格納されるブロードキャストフォワーディングタグに対する出力ポートを取得し、所定の出力ポート２２０−ｏｕｔに転送する。
【０２１３】
続いて、ノード２００−４〜２００−７について説明する。
【０２１４】
Ｑｕｅｒｙ１メッセージ４７０１−１を受信したフレーム解析部２０１１は、マルチキャスト制御メッセージであるため、マルチキャスト制御部２０２０に転送する。マルチキャスト制御部２０２０でフレーム解析部２０１１から受信したＱｕｅｒｙ１メッセージ４７０１−１のＴｙｅｐｅ４９０２を参照して、Ｑｕｅｒｙ１メッセージ４７０１−１であることを示す値が格納されているため、マルチキャストテーブルの該当エントリをクリアした後、図１５のシーケンスの次の第２のステップとして、図１７の状態で示される処理を行う。
【０２１５】
続いて、図１５のシーケンスにおける図１７の状態を示す第２のステップについて説明する。
【０２１６】
図１５のシーケンスの図１７の状態を示す第２のステップを参照すると、Ｑｕｅｒｙ１メッセージ４７０１−１を受信した受信ノード２００−４、２００−５、２００−６、２００−７では、自ノードの配下に同じカスタマ＃ａを収容していれば、Ｑｕｅｒｙ１メッセージ４７０１−１の応答としてＲｅｐｏｒｔ１メッセージ４７０２−１を生成し、Ｑｕｅｒｙ１メッセージ４７０１−１の送信元ノードであるノード２００−１に対しＲｅｐｏｒｔ１メッセージ４７０２−１をユニキャスト転送し、マルチキャストテーブルの対応エントリを更新する。
【０２１７】
また、Ｒｅｐｏｒｔ１メッセージ４７０２−１を受信した中継ノード２００−２では、Ｒｅｐｏｒｔ１メッセージ４７０２−１の受信ポートを学習して、マルチキャストテーブル２０２１−２を更新し、Ｒｅｐｏｒｔ１メッセージ４７０２−１を次ホップのノードに転送する。Ｒｅｐｏｒｔ１メッセージ４７０２−１を受信した送信元ノード２００−１では、中継ノード２００−２と同様に、受信したＲｅｐｏｒｔ１メッセージ４７０２−１の受信ポートを学習して、マルチキャストテーブル２０２１−１の対応エントリを更新する。
【０２１８】
以上説明したＲｅｐｏｒｔ１メッセージ４７０２−１の転送経路と各ノードの処理に関して、図１７で詳細に説明する。図１７では、Ｒｅｐｏｒｔ１メッセージ４７０２−１の転送経路を点線で記している。
【０２１９】
エッジノード２００−４、２００−５、２００−６、２００−７では、Ｑｕｅｒｙ１メッセージ４７０１−１を受信した後、自ノードの配下に同じカスタマを収容しているかをサーチする。
【０２２０】
エッジノード２００−５はカスタマ識別テーブル３１０５を参照し（図５５を参照）、ポート＃３にカスタマ＃ａのホストＢが接続されているため、Ｒｅｐｏｒｔ１メッセージ４７０２−１を生成する。Ｒｅｐｏｒｔ１メッセージ４７０２−１の生成において、フレームの拡張タグ格納領域４６０３にフォワーディングタグ４５００「送信元ノードのノード識別子２００−１」を格納し、制御メッセージの属性情報のＴｙｅｐｅ４９０２にＲｅｐｏｒｔ１メッセージ４７０２−１であることを示す値を格納し、カスタマ情報４９０３に、カスタマ＃ａ、追加（Ｊｏｉｎ）、１つ（ｏｎｅ）等の値を格納する。
【０２２１】
さらに、エッジノード２００−５は、ユニキャストテーブル２２１２−５を参照して、フォワーディングタグ２００−１に対する出力ポートとしてポート＃１を取得し、ポート＃１からＲｅｐｏｒｔ１メッセージ４７０２−１を転送する。
【０２２２】
また、図１７に示すマルチキャストテーブル２０２１−５において「送信元ノード２００−１、カスタマ＃ａ」のエントリに関して、Ｒｅｐｏｒｔ１メッセージ４７０２−１を受信したポート＃３のビットを「１」に更新し、該当エントリを「ＯＮ」（値「１」）にする。または、マルチキャストテーブルのエントリをクリアする際に設定したテーブル有効タイマーがタイマーアップされることにより、各ノードでは該当エントリを「ＯＮ」にする。
【０２２３】
一方、他のエッジノード２００−４、２００−６、２００−７は、Ｑｕｅｒｙ１メッセージ４７０１−１に含まれるカスタマ＃ａを収容していないため、Ｒｅｐｏｒｔ１メッセージ４７０２−１を生成せずに処理を終了する。
【０２２４】
続いて、中継ノード２００−２では、受信した制御メッセージがＲｅｐｏｒｔ１メッセージ４７０２−１であれば、Ｒｅｐｏｒｔ１メッセージ４７０２−１の格納情報から、フォワーディングタグ「送信元エッジノード２００−１」と、カスタマ情報「＃ａ」と、受信ポート「ポート＃３」とを学習し、マルチキャストテーブル２０２１−２において「送信元ノード２００−１、カスタマ＃ａ」のエントリに関して、Ｒｅｐｏｒｔ１メッセージ４７０２−１を受信したポート＃３のビットを「１」に更新し、該当エントリを「ＯＮ」にする。
【０２２５】
続いて、中継ノード２００−２は、ユニキャストテーブル２２１２−２を参照して、フォワーディングタグ「２００−１」に対応する出力ポートとしてポート＃１を取得し、Ｒｅｐｏｒｔ１メッセージ４７０２−１をポート＃１に転送する。
【０２２６】
続いて、送信元ノード２００−１では、受信した制御メッセージがＲｅｐｏｒｔ１メッセージ４７０２−１であれば、Ｒｅｐｏｒｔ１メッセージ４７０２−１の格納情報から、フォワーディングタグ「送信元エッジノード２００−１」と、カスタマ情報（＃ａ）と、受信ポート（ポート＃２）とを学習し、マルチキャストテーブル２０２１−１において「送信元ノード２００−１、カスタマ＃ａ」のエントリに関して、Ｒｅｐｏｒｔ１メッセージ４７０２−１を受信したポート＃２のビットを「１」に更新し、該当エントリを「ＯＮ」にする。
【０２２７】
図１７の右側に示されたマルチキャストテーブル２０２１−１、２０２１−２、２０２１−５は、それぞれノード２００−１、２００−２、２００−５でのＲｅｐｏｒｔ１メッセージ４７０２−１を受信した後のマルチキャストテーブルの状態を示しており、それぞれＲｅｐｏｒｔ１メッセージ４７０２−１の受信ポートのビットが「１」（ＯＮ）となり、それ以外のポートのビットが「０」（ＯＦＦ）となっている。
【０２２８】
上述のＲｅｐｏｒｔ１メッセージ４７０２−１の送受信に関しての動作を図３のノード構成に基づいて説明する。最初に受信エッジノード２００−５について説明する。
【０２２９】
Ｑｕｅｒｙ１メッセージ４７０１−１を受信したマルチキャスト制御部２０２０は、カスタマ管理モジュール２０１６に対して、自ノードでカスタマ＃ａを収容しているかどうかを問い合わせる。
【０２３０】
カスタマ管理モジュール２０１６はカスタマ識別テーブル２０１７を参照してカスタマ＃ａの接続状況（ポート＃３にカスタマ＃ａのホストＢが接続）を取得する。カスタマ管理モジュール２０１６は、カスタマ＃ａの接続ポート＃３をマルチキャスト制御部２０２０に通知し、マルチキャスト制御部２０２０は、マルチキャストテーブル２０２１のカスタマ＃ａのエントリを更新（ポート＃３のビットを「１」にし、該当エントリを「ＯＮ」にする）する。
【０２３１】
また、マルチキャスト制御部２０２０は、カスタマ＃ａに関するＲｅｐｏｒｔ１メッセージ４７０２−１を生成して、タグスイッチ部２０１３に転送する。タグスイッチ部２０１３はフォワーディングテーブル格納部２０１８内のユニキャストテーブル２２１２−５を参照して、Ｒｅｐｏｒｔ１メッセージ４７０２−１を所定のポート（ポート＃１）に出力する。
【０２３２】
なお、カスタマ管理モジュール２０１６からの回答が該当カスタマ無しの場合、Ｒｅｐｏｒｔ１メッセージ４７０２−１を生成しない。
【０２３３】
続いて、中継ノード２００−２について説明する。
【０２３４】
Ｒｅｐｏｒｔ１メッセージ４７０２−１を受信したフレーム解析部２０１１は、マルチキャスト制御メッセージであるため、マルチキャスト制御部２０２０に転送する。
【０２３５】
マルチキャスト制御部２０２０では、フレーム解析部２０１１から受信したＲｅｐｏｒｔ１メッセージ４７０２−１のＴｙｅｐｅ４９０２を参照して、Ｒｅｐｏｒｔ１メッセージ４７０２−１であることを示す値が格納されているため、メッセージをタグスイッチ部２０１３に転送する。
【０２３６】
同時に、Ｒｅｐｏｒｔ１メッセージ４７０２−１の受信ポートに関して、マルチキャストテーブル２０２１−２を更新する。タグスイッチ部２０１３は、フォワーディングテーブル格納部２０１８内のユニキャストテーブル２２１２−２を参照して、Ｒｅｐｏｒｔ１メッセージ４７０２−１に格納されるフォワーディングタグに対する出力ポートを取得し、所定の出力ポート２２０−ｏｕｔに転送する。
【０２３７】
続いて、送信元ノード２００−１について説明する。
【０２３８】
Ｒｅｐｏｒｔメッセージ４７０２−１を受信したフレーム解析部２０１１は、マルチキャスト制御メッセージであるため、マルチキャスト制御部２０２０に転送する。
【０２３９】
マルチキャスト制御部２０２０では、フレーム解析部２０１１から受信したＲｅｐｏｒｔ１メッセージ４７０２−１のＴｙｅｐｅ４９０２を参照して、Ｒｅｐｏｒｔ１メッセージ４７０２−１であることを示す値が格納されているため、Ｒｅｐｏｒｔ１メッセージ４７０２−１の受信ポートに関して、マルチキャストテーブル２０２１−１を更新する。Ｒｅｐｏｒｔ１メッセージ４７０２−１に関してはそれを廃棄する。
【０２４０】
その後、図１５のシーケンスの次の第３のステップとして、図１８の状態で示される処理を行う。
【０２４１】
続いて、図１５のシーケンスにおける図１８の状態を示す第３のステップについて説明する。
図１５のシーケンスの図１８の状態を示す第３のステップを参照すると、Ｒｅｐｏｒｔ１メッセージ４７０２−１を送信した２００−５では、カスタマ＃ａの収容に関する問い合わせを行うＱｕｅｒｙ２メッセージ４７０１−２を生成し、Ｑｕｅｒｙ２メッセージ４７０１−２を自ノードがルートノードとなるスパニングツリー上でネットワーク内にブロードキャストする。
【０２４２】
Ｑｕｅｒｙ２メッセージ４７０１−２を受信した中継ノード２００−２、２００−３では、Ｑｕｅｒｙ２メッセージ４７０１−２を次ホップのノードに転送する。これにより、受信ノード２００−１、２００−４、２００−６、２００−７に、Ｑｕｅｒｙ２メッセージ４７０１−２が到着する。
【０２４３】
以上説明したＱｕｅｒｙ２メッセージ４７０１−２の転送経路と各ノードの処理に関して、図１８で詳細に説明する。図１８では、Ｑｕｅｒｙ２メッセージ４７０１−２の転送経路を点線で記している。
【０２４４】
Ｒｅｐｏｒｔ１メッセージ４７０２−１を送信したエッジノード２００−５は、カスタマ＃ａの収容に関する問い合わせを行うＱｕｅｒｙ２メッセージ４７０１−２を生成する。
【０２４５】
Ｑｕｅｒｙ２メッセージ４７０１−２の生成において、フレームの拡張タグ格納領域４６０３にブロードキャストフォワーディングタグ４５０８（自ノードのノード識別子２００−５）を格納し、制御メッセージの属性情報のＴｙｅｐｅ４９０２にＱｕｅｒｙ２メッセージ４７０１−２であることを示す値を格納し、カスタマ情報４９０３にカスタマ＃ａ、追加（Ｊｏｉｎ）、１つ（ｏｎｅ）等の値を格納する。
【０２４６】
エッジノード２００−５は、ブロードキャストテーブル２２１１−５を参照して、ブロードキャストフォワーディングタグ「ノード２００−５」に対応する出力ポート＃１、＃２、＃５を取得し、当該ポートにＱｕｅｒｙ２メッセージ４７０１−２をブロードキャストする。
【０２４７】
続いて、Ｑｕｅｒｙ２メッセージ４７０１−２を受信した中継ノード２００−２、２００−３は、ブロードキャストテーブルを参照して出力ポートを取得し、Ｑｕｅｒｙ２メッセージ４７０１−２を転送する。図１８の場合、中継ノード２００−２では、ブロードキャストテーブル２２１１−２を参照して、出力ポート＃１を取得し、Ｑｕｅｒｙ２メッセージ４７０１−２をポート＃１から転送する。
【０２４８】
中継ノード２００−２、２００−３から転送されたＱｕｅｒｙ２メッセージ４７０１−２は、エッジノード２００−１、２００−４、２００−６、２００−７に到着する。
【０２４９】
図１８で示すマルチキャストテーブル２０２１−１、２０２１−２、２０２１−５は、ノード２００−１、２００−２、２００−５でのＱｕｅｒｙ２メッセージ４７０１−２を受信した後のマルチキャストテーブルの状態を示している。各ノードのマルチキャストテーブルの対応エントリが無効状態になっているのは、送信元ノード２００−５に対するエントリが作成されてない状態（初期状態）を示している例で、該当エントリのクリア操作を示しているのではない。
【０２５０】
上述のＱｕｅｒｙ２メッセージ４７０１−２の送受信に関する動作を図３のノード構成に基づいて説明する。最初にエッジノード２００−５について説明する。
Ｒｅｐｏｒｔ１メッセージ４７０２−１を生成、転送したマルチキャスト制御部２０２０は、カスタマ＃ａに関するＱｕｅｒｙ２メッセージ４７０１−２を生成した後、Ｑｕｅｒｙ２メッセージ４７０１−２をタグスイッチ部２０１３に送信する。タグスイッチ部２０１３では、フォワーディングテーブル格納部２０１８内のブロードキャストテーブル２２１１−５を参照して、Ｑｕｅｒｙ２メッセージ４７０１−２を所定の出力ポート２１０−ｏｕｔに転送する。
【０２５１】
続いて、中継ノード２００−２、２００−３について説明する。
【０２５２】
Ｑｕｅｒｙ２メッセージ４７０１−２を受信したフレーム解析部２０１１は、マルチキャスト制御メッセージであるため、マルチキャスト制御部２０２０に転送する。マルチキャスト制御部２０２０でフレーム解析部２０１１から受信したＱｕｅｒｙ２メッセージ４７０１−２のＴｙｅｐｅ４９０２を参照して、Ｑｕｅｒｙ２メッセージ４７０１−２であることを示す値が格納されているため、Ｑｕｅｒｙ２メッセージ４７０１−２をタグスイッチ部２０１３に転送する。
【０２５３】
タグスイッチ部２０１３はフォワーディングテーブル格納部２０１８内のブロードキャストテーブル２２１１を参照して、Ｑｕｅｒｙ２メッセージ４７０１−２に格納されるブロードキャストフォワーディングタグに対する出力ポートを取得し、所定の出力ポート２２０−ｏｕｔに転送する。
【０２５４】
続いて、受信ノード２００−１、４、６、７について説明する。
【０２５５】
Ｑｕｅｒｙ２メッセージ４７０１−２を受信したフレーム解析部２０１１は、マルチキャスト制御メッセージであるため、マルチキャスト制御部２０２０に転送する。マルチキャスト制御部２０２０でフレーム解析部２０１１から受信したＱｕｅｒｙ２メッセージ４７０１−２のＴｙｅｐｅ４９０２を参照して、Ｑｕｅｒｙ２メッセージ４７０１−２であることを示す値が格納されているため、図１５のシーケンスの次の第４のステップとして、図１９の状態で示される処理を行う。
【０２５６】
続いて、図１５のシーケンス図における図１９の状態を示す第４のステップについて説明する。
【０２５７】
図１５のシーケンスの図１９の状態を示す第４のステップを参照すると、Ｑｕｅｒｙ２メッセージ４７０１−２を受信したエッジノード２００−１、４、６、７では、自ノードの配下に同じカスタマ＃ａを収容していれば、Ｑｕｅｒｙ２メッセージ４７０１−２の応答としてＲｅｐｏｒｔ２メッセージ４７０２−２を生成し、Ｑｕｅｒｙ２メッセージ４７０１−２の送信元ノードであるノード２００−５に対しＲｅｐｏｒｔ２メッセージ４７０２−２をユニキャスト転送し、マルチキャストテーブルの対応エントリを更新する。
【０２５８】
また、Ｒｅｐｏｒｔ２メッセージ４７０２−２を受信した中継ノード２００−２では、Ｒｅｐｏｒｔ２メッセージ４７０２−２の受信ポートを学習して、マルチキャストテーブル２０２１−２を更新し、Ｒｅｐｏｒｔ２メッセージ４７０２−２を次ホップのノードに転送する。Ｒｅｐｏｒｔ２メッセージ４７０２−２を受信した送信元ノード２００−５では、中継ノード２００−２と同様に、受信したＲｅｐｏｒｔ２メッセージ４７０２−２の受信ポートを学習して、マルチキャストテーブル２０２１−５の対応エントリを更新する。
【０２５９】
以上説明したＲｅｐｏｒｔ２メッセージ４７０２−２の転送経路と各ノードの処理に関して、図１９で詳細に説明する。図１９では、Ｒｅｐｏｒｔ２メッセージ４７０２−２の転送経路を点線で示している。
【０２６０】
エッジノード２００−１、４、６、７の中で、自ノードの配下のポート＃１にカスタマ＃ａを収容しているエッジノード２００−１は、Ｒｅｐｏｒｔ２メッセージ４７０２−２を生成する。Ｒｅｐｏｒｔ２メッセージ４７０２−２の生成において、フレームの拡張タグ格納領域４６０３にフォワーディングタグ４５００「ルートノードのノード識別子２００−５」を格納し、制御メッセージの属性情報のＴｙｅｐｅ４９０２にＲｅｐｏｒｔ２メッセージ４７０２−２であることを示す値を格納し、カスタマ情報４９０３に「カスタマ＃ａ」、「追加（Ｊｏｉｎ）」、「ｏｎｅ」等の値を格納する。
【０２６１】
エッジノード２００−１は、ユニキャストテーブル２２１２−１を参照して、フォワーディングテーブル格納部２０１８の宛先ノード２００−５に対する出力ポート＃２を取得し、当該出力ポート＃２からＲｅｐｏｒｔ２メッセージ４７０２−２を転送する。
【０２６２】
また、図１９に示すマルチキャストテーブル２０２１−１において「送信元ノード２００−５、カスタマ＃ａ」のエントリを参照して、カスタマ＃ａが接続されているポート＃１のビットを「１」に更新する。
【０２６３】
続いて、中継ノード２００−２では、受信した制御メッセージがＲｅｐｏｒｔ２メッセージ４７０２−２であれば、Ｒｅｐｏｒｔ２メッセージ４７０２−２の格納情報から、フォワーディングタグ「送信元ノードのノード識別子２００−５」と、カスタマ情報「＃ａ」と、受信ポート「ポート＃１」とを学習し、マルチキャストテーブル２０２１−２において「送信元ノード２００−５、カスタマ＃ａ」のエントリに関して、Ｒｅｐｏｒｔ２メッセージ４７０２−２を受信したポート＃１のビットを「１」（ＯＮ）に更新する。
【０２６４】
続いて、中継ノード２００−２は、ユニキャストテーブ２２１２−２を参照して出力ポートを取得し、Ｒｅｐｏｒｔ２メッセージ４７０２−２をポート＃３に転送する。
【０２６５】
続いて、送信元ノード２００−５では、受信した制御メッセージがＲｅｐｏｒｔ２メッセージ４７０２−２であれば、Ｒｅｐｏｒｔ２メッセージ４７０２−２の格納情報から、フォワーディングタグ「送信元ノードのノード識別子２００−５」と、カスタマ情報「＃ａ」と、受信ポート「ポート＃１」とを学習し、マルチキャストテーブル２０２１−５において「送信元ノード２００−５、カスタマ＃ａ」エントリのエントリに関して、Ｒｅｐｏｒｔ２メッセージ４７０２−２を受信したポート＃１のビットを「１」（ＯＮ）に更新する。
【０２６６】
図１９の右側に示されたマルチキャストテーブル２０２１−１、２０２１−２、２０２１−５は、ノード２００−１、２００−２、２００−５でのＲｅｐｏｒｔ２メッセージ４７０２−２を送受信した後のマルチキャストれーブルの状態を示している。それぞれＲｅｐｏｒｔ２メッセージ４７０２−２に関連するＱｅｕｒｙ２メッセージ４７０４の送信元ノードである「２００−５」のエントリに関して、Ｒｅｐｏｒｔ２メッセージ４７０２−２の受信ポートビットを「１」（ＯＮ）にする。
【０２６７】
以上、図１９で説明したＲｅｐｏｒｔ２メッセージ４７０２−２の送受信に関してのノードの処理は、Ｒｅｐｏｒｔ１メッセージ４７０２−１の送受信時の処理と同じであるため、詳細な説明は省略する。
【０２６８】
（マルチキャストテーブルにおける、マルチキャストフレームの転送方法）
以下に、上述のマルチキャストテーブルの作成方法によって生成されたマルチキャストテーブルを参照することにより、マルチキャストフレームを転送する本実施の形態のマルチキャスト転送方法について詳細に説明する。
【０２６９】
図２０は、本発明の拡張タグネットワーク２３００において、ノード２００−１から送信されるマルチキャストフレームに関する転送経路と各ノードのマルチキャストテーブルを示している。各ノードのマルチキャストテーブルは図１５から図１９を用いて説明した手順により作成した内容となっている。また、ノード２００−１からのマルチキャスト転送経路を太線で示している。以降では、図３のノード構成も参照して説明する。
【０２７０】
まず、入口側のエッジノード２００−１の処理について説明する。
【０２７１】
ノード２００−１では、ポート＃１でカスタマ＃ａのホストＡから、送信先ＭＡＣアドレスが「ＭＡＣ＿ＤＡ＝０ｘＦＦＦＦ」であるブロードキャストフレームを受信する。
【０２７２】
ノード２００−１のフレーム解析部２０１１は、受信フレームが通常イーサネット（Ｒ）フレームであるため、タグ挿入部２０１２にフレームを転送する。タグ挿入部２０１２は、受信フレームのＭＡＣ＿ＤＡが「０ｘＦＦＦＦ」であるため、ブロードキャストフォワーディングタグとして、フレームの拡張タグ格納領域４３０１に自ノードのノード識別子「２００−１」を格納する。
【０２７３】
また、カスタマ識別テーブル２０１７（図３）を参照して、入力ポート＃１に対するカスタマＩＤ＝＃ａを取得し、カスタマタグとして、フレームの拡張タグ格納領域４３０１に更にカスタマＩＤ＝＃ａを格納する。タグ挿入部２０１２は、両方のタグを付加したフレームをタグスイッチ部２０１３に転送する。
【０２７４】
タグスイッチ部２０１３はマルチキャストテーブル２０２１−１（図２０）を参照して、該当エントリ状態が「ＯＮ」であれば、「ノード２００−１、カスタマ＃ａ」に対する出力ポート＃２を取得し、ポート＃２にマルチキャストフレームを出力する。該当エントリ状態が「ＯＦＦ」であれば、タグスイッチ部２０１３内のテーブル検索部２１０２（図４を参照）は、フォワーディングテーブル格納部２０１８内のブロードキャストテーブル２２１１（図５を参照）を参照する。
【０２７５】
この例では、エッジノード２００−１から出力されたフレームは、中継ノード２００−２に到着する。
【０２７６】
続いて、中継ノード２００−２の処理について説明する。
【０２７７】
ノード２００−２のフレーム解析部２０１１は、受信フレームが拡張タグ付きフレームであるため、フレームをタグスイッチ部２０１３に転送する。タグスイッチ部２０１３はマルチキャストテーブル２０２１−２（図２０）を参照して、該当エントリ状態が「ＯＮ」であれば、「ノード２００−１、カスタマ＃ａ」に対する出力ポート＃３を取得し、ポート＃３にマルチキャストフレームを出力する。該当エントリ状態が「ＯＦＦ」であれば、タグスイッチ部２０１３内のテーブル検索部２１０２（図４を参照）は、フォワーディングテーブル格納部２０１８内のブロードキャストテーブル２２１１（図５を参照）を参照する。
【０２７８】
この例では、中継ノード２００−２から出力されたフレームはエッジノード２００−５に到着する。
【０２７９】
続いて、出口側のエッジノード２００−５の処理について説明する。
【０２８０】
ノード２００−５のフレーム解析部２０１１は、受信フレームが拡張タグ付きフレームであるため、フレームをタグスイッチ部２０１３に転送する。タグスイッチ部２０１３はマルチキャストテーブル２０２１−５（図２０）を参照して、該当エントリ状態が「ＯＮ」であれば、「ノード２００−１、カスタマ＃ａ」に対する出力ポート＃３を取得する。取得したポートがホスト側ポートである場合はタグ削除部２０１４に転送する。取得したポートがネットワーク側ポートである場合は出力ポート２２０−ｏｕｔにフレームを転送する。
【０２８１】
この例では、出力ポート＃３はホスト側ポートであるため、フレームがタグ削除部２０１４に転送される。タグ削除部２０１４は受信フレームのブロードキャストフォワーディングタグとカスタマ分離タグを削除して、通常のイーサネット（Ｒ）フレームに変換して出力ポート２１０−ｏｕｔ（出力ポート＃３）に転送する。また、該当エントリ状態が「ＯＦＦ」であれば、タグスイッチ部２０１３内のテーブル検索部２１０２（図４を参照）は、フォワーディングテーブル格納部２０１８内のブロードキャストテーブル２２１１（図５を参照）を参照する。
【０２８２】
この例では、ノード２００−５から転送されたフレームはホストＢに到着する。
【０２８３】
以上説明したように、カスタマ＃ａのホストＡから送信されたブロードキャストフレームは、ネットワーク内において、ホストＡが接続するエッジノード２００−１とカスタマ＃ａの他のホストであるホストＢが接続するエッジノード２００−５間の最短経路上のみをフレーム転送され、ホストＢに到着することになる。すなわち、カスタマによって関連付けられた経路上のみでのマルチキャスト転送を実現している。
【０２８４】
図２１は、カスタマ＃ａのホストＢからのブロードキャスト転送について転送経路（マルチキャストテーブルのエントリが有効（ＯＮ）の場合）を示している。図２１に示す転送経路は、ホストＢが接続するノード２００−５が送信元ノードになるスパニングツリー上でＲｅｐｏｒｔ制御メッセージを受信したポートが選択され、図２１で示すように、ノード２００−５、２００−２、２００−１の経路になっている。各ノードにおける主信号フレームの転送処理については図３と図２０で説明した処理と同一であるため、詳細の説明は省略する。
【０２８５】
以上、カスタマが追加される際に、マルチキャストテーブルを更新する方法と、マルチキャストテーブルを参照してマルチキャストフレームを転送する方法を説明した。
【０２８６】
なお、ノードからカスタマが削除される場合の手順については、図１３に示した第１の実施の形態と同様の処理がなされる。
【０２８７】
上述の説明では、エッジノードの全てのカスタマ情報がカスタマ識別テーブル２０１７に事前に登録されていることを前提としている。例えば、図３８で示したと同じように、ノード２００−５のポート＃３に接続されているホストＢがカスタマ＃ａである事がカスタマ識別テーブル２０１７（図３）に事前に登録されている。
【０２８８】
エッジノード側のカスタマ情報がカスタマ識別テーブル２０１７に事前に登録されていない場合の処理に関しては、図５２〜図５４で説明した第１の実施の形態の場合と同様である。
【０２８９】
（第２の実施の形態による効果）
以上説明した第２の実施の形態のマルチキャスト転送方法の効果について説明する。
【０２９０】
従来方法では、送信元ノードがルートノードになるスパニングツリー上でマルチキャストフレームを転送する際は、同じカスタマがいない経路にもフラッディングされていた。
【０２９１】
これに対して、本実施の形態の転送方法では、送信元ノードからのブロードキャスト転送経路上（送信元ノードがルートノードになるスパニングツリー上）でカスタマの収容状況の問い合わせるＱｕｅｒｙメッセージを送信し、そのカスタマを収容する他のエッジノードがＲｅｐｏｒｔメッセージを返信し、経路上の各ノードがＲｅｐｏｒｔメッセージの受信ポートをそのカスタマに関するブロードキャストポートとしてマルチキャストテーブルに学習する。また、前記Ｒｅｐｏｒｔメッセージを返信した他のノードは、Ｒｅｐｏｒｔメッセージを返信後に、自らが送信元となりＱｕｅｒｙメッセージを送信し、その応答であるＲｅｐｏｒｔメッセージを受信する。ネットワーク内の各ノードは、マルチキャストフレームを転送する際に、双方向で本マルチキャストテーブルを参照して出力ポートを決定することにより、カスタマと関係ある経路のみにフレームを転送することが可能となる。
【０２９２】
すなわち、本実施の形態によれば、例えばレイヤ２の拡張タグネットワークにおいて、マルチキャストフレームを転送する際に、カスタマと関係ある経路のみにフレームを転送し、それにより効率的なマルチキャスト転送を行うことができる。
（第３の実施の形態）
【０２９３】
以下、本発明の第３の実施の形態について、図面を参照して詳細に説明する。
【０２９４】
（マルチキャストテーブルの構成例）
本発明の第３の実施の形態では、第１の実施の形態で説明したマルチキャストテーブルの構成を簡略化している。図７で説明した第１の実施の形態のマルチキャストテーブル２０２１は、送信元エッジノードの識別子フィールドと、カスタマＩＤフィールドと、マルチキャスト転送ポートフィールドとから構成されており、そのエントリの数は、「エッジノードの数×カスタマの数」となる。そのため、エッジノードの数に比例してエントリの数が増加する。
【０２９５】
これに対して、本実施の形態によるマルチキャストテーブル２０２１Ａは、図２２に示すように、カスタマＩＤフィールドと、マルチキャスト転送ポートフィールドで構成されており、マルチキャスト転送ポートエントリは、カスタマ毎に定義され、全ての送信元ノード間で共有する構成としている。
【０２９６】
このように簡略化したマルチキャストテーブル２０２１Ａを用いて転送処理を行なうために、本実施の形態では、マルチキャストテーブル２０２１Ａとフォワーディングテーブルを同時に参照することにより、指定のエッジノードから送信されたマルチキャストフレームの転送ポートを決定する。
【０２９７】
（第３の実施の形態によるマルチキャストテーブル作成方法）
以降では、第１の実施の形態の拡張タグネットワーク２３００に対して、図２３に示すように、ノード２００−４にカスタマ#aが追加される際のマルチキャストテーブル２０２１Ａの更新方法について、図２４のシーケンスを用いて説明する。
【０２９８】
図２３で示すように、拡張タグネットワーク２３００は、ノード２００−１、２００−５にカスタマ#aが追加された後の状態を示しており、ノード２００−１、２００−２、２００−５のマルチキャストテーブル２０２１Ａ−１、２０２１Ａ−２、２０２１Ａ−５は、第１の実施の形態のマルチキャストテーブル２０２１−１、２０２１−２、２０２１−５を、本実施の形態のマルチキャストテーブル２０２１Ａの構成に合わせて変更している。
【０２９９】
すなわち、カスタマ毎に、全ての送信元ノードに関するマルチキャスト転送ポートを共有させており、第１の実施の形態のマルチキャストテーブルにおいて、カスタマ毎に、マルチキャスト転送ポートエントリの論理和を取っている。Ｑｕｅｒｙ１メッセージ、Ｑｕｅｒｙ２メッセージとＲｅｐｏｒｔ１メッセージ、Ｒｅｐｏｒｔ２メッセージのフォーマットは、第２の実施の形態と同じフォーマットを使用している。また、ノードの構成も図３で説明した第１の実施の形態のノード構成と同じである。
【０３００】
まず、図２４のシーケンスの第１のステップ（図２５の状態）を参照すると、エッジノード２００−４にカスタマ#a（カスタマ＃ａに属するホスト）が追加されると、エッジノード２００−４は、Ｑｕｅｒｙ１メッセージ４７０１−１を生成し、対応のマルチキャストエントリをクリアして、Ｑｕｅｒｙ１メッセージ４７０１−１をネットワーク内にブロードキャスト転送する。
【０３０１】
Ｑｕｅｒｙ１メッセージ４７０１−１を受信した中継ノードと受信エッジノード２００−１〜７は、Ｑｕｅｒｙ１メッセージ４７０１−１を受信すると、対応のマルチキャストエントリをクリアして、次ホップのノードに転送する。エントリをクリアする動作では、対応のエントリを「ＯＦＦ」にし、タイマーを設定する。タイマーにはエントリが有効になるまでの時間が設定される。その時間内にノードでマルチキャストフレームが受信されると、ブロードキャストテーブルを参照して転送されるようにする。
【０３０２】
以上説明したＱｕｅｒｙ１メッセージ４７０１−１の転送経路と各ノードの処理に関して、図２５で詳細に説明する。図２５では、Ｑｕｅｒｙ１メッセージ４７０１−１の転送経路を点線で記している。
【０３０３】
エッジノード２００−４にカスタマ#aが追加されると、ノード２００−４は、Ｑｕｅｒｙ１メッセージ４７０１−１を生成し、ブロードキャストテーブル２２１１−４を参照して、ブロードキャストフォワーディングタグ「２００−４」に対する出力ポート＃１、＃３を取得し、当該ポートにＱｕｅｒｙ１メッセージ４７０１−１を転送する。一方、対応のマルチキャストエントリをクリアする。
【０３０４】
続いて、Ｑｕｅｒｙ１メッセージ４７０１−１を受信した中継ノード２００−２は、ブロードキャストテーブル２２１１−２を参照して、ブロードキャストフォワーディングタグ「２００−４」に対する出力ポート＃１、＃４、＃５を取得し、Ｑｕｅｒｙ１メッセージ４７０１−１をポート＃１、＃４、＃５に転送する。また、対応のマルチキャストエントリをクリアする。
【０３０５】
続いて、Ｑｕｅｒｙ１メッセージ４７０１−１を受信した受信エッジノード２００−１、２００−５、２００−６、２００−７では、図２４のシーケンスの次の第２のステップとして、図２６の状態で示される処理を行う。
【０３０６】
図２５のマルチキャストテーブル２０２１Ａ−１、２０２１Ａ−２、２０２１Ａ−４、２０２１Ａ−５は、Ｑｕｅｒｙ１メッセージ４７０１−１を受信した後のノード２００−１、２００−２、２００−４、２００−５のマルチキャストテーブルの状態を示している。
【０３０７】
なお、Ｑｕｅｒｙ１メッセージ等の制御メッセージの送受信時の処理に関して、ノード内の各部の処理は第１の実施の形態と同じであるため、第３の実施の形態では説明を省略する。
【０３０８】
続いて、図２４のシーケンスにおける図２６の状態を示す第２のステップについて説明する。
【０３０９】
図２４のシーケンスの図２６の状態を示す第２のステップを参照すると、Ｑｕｅｒｙ１メッセージ４７０１−１を受信した受信エッジノード２００−１、２００−５、２００−６、２００−７では、自ノードの配下に同じカスタマ＃aを収容していれば、Ｑｕｅｒｙ１メッセージ４７０１−１の応答としてＲｅｐｏｒｔ１メッセージ４７０２−１を生成し、Ｑｕｅｒｙ１メッセージ４７０１−１の送信元ノードであるノード２００−４に対しＲｅｐｏｒｔ１メッセージ４７０２−１をユニキャスト転送する。また、同じカスタマを収容していなければＲｅｐｏｒｔ１メッセージ４７０２−１の生成、転送は行わない。
【０３１０】
Ｒｅｐｏｒｔ１メッセージ４７０２−１を受信した中継ノード２００−２では、Ｒｅｐｏｒｔ１メッセージの受信ポートを学習して、マルチキャストテーブル２０２１Ａ−２を更新し、Ｒｅｐｏｒｔ１メッセージ４７０２−１を次ホップのノードに転送する。Ｒｅｐｏｒｔ１メッセージを受信した送信元ノード２００−４は、中継ノードと同様にＲｅｐｏｒｔ１メッセージ４７０２−１の受信ポートを学習して、マルチキャストテーブル２０２１Ａ−４を更新する。
【０３１１】
以上説明したＲｅｐｏｒｔ１メッセージ４７０２の転送経路と各ノードの処理に関して、図２６で詳細に説明する。図２６では、Ｒｅｐｏｒｔ１メッセージ４７０２の転送経路を点線で記している。
【０３１２】
エッジノード２００−１、２００−５、２００−６、２００−７では、Ｑｕｅｒｙ１メッセージ４７０１−１を受信した後、自ノードの配下に同じカスタマがいるかをサーチする。
【０３１３】
エッジノード２００−１はポート＃１に、またエッジノード２００−５はポート＃３にカスタマ#aのホストが接続されているため、それぞれのノードではＲｅｐｏｒｔ１メッセージ４７０２−１を生成すると共に、カスタマ#aの接続ポートをマルチキャストテーブル２０２１Ａ−１、２０２１Ａ−５に追加する。また、フォワーディングテーブル格納部２０１８内のユニキャストテーブル２２１２−１、２２１２−５を参照して、フォワーディングタグ４５００の「宛先ノード２００−４」に対する出力ポート＃２、＃２を取得し、当該ポートにＲｅｐｏｒｔ１メッセージ４７０２−１を転送する。一方、他のエッジノード２００−６、２００−７は、Ｑｕｅｒｙ１メッセージ４７０１−１に含まれるカスタマ#aを収容していないので、Ｒｅｐｏｒｔ１メッセージ４７０２−１を生成しない。
【０３１４】
中継ノード２００−２では、エッジノード２００−１からＲｅｐｏｒｔ１メッセージ４７０２−１を受信すると、Ｒｅｐｏｒｔ１メッセージ４７０２−１の格納情報から、カスタマ情報（#a）と、受信ポート（ポート＃１）とを学習し、マルチキャストテーブル２０２１Ａ−２において「カスタマ#a」のエントリに関して、Ｒｅｐｏｒｔ１メッセージ４７０２−１を受信したポート＃１のビットを「１」（ＯＮ）に更新する。
【０３１５】
続いて、ユニキャストテーブル２２１２−２を参照して、フォワーディングタグ「２００−４」に対する出力ポート＃２を取得し、ポート＃２にＲｅｐｏｒｔ１メッセージ４７０２−１を転送する。
【０３１６】
送信元ノード２００−４では、エッジノード２００−５と中継ノード２００−２からＲｅｐｏｒｔ１メッセージ４７０２−１を受信すると、それぞれのＲｅｐｏｒｔ１メッセージ４７０２−１の格納情報から、カスタマ情報（#a）と受信ポート（ポート＃３）、カスタマ情報（#a）と受信ポート（ポート＃１）とを学習し、マルチキャストテーブル２０２１Ａ−４において「カスタマ#a」のエントリに関して、受信ポート＃１、＃３のビットを「１」（ＯＮ）に更新する。
【０３１７】
続いて、図２４のシーケンスにおける図２７、図２９の状態を示す第３のステップについて説明する。
【０３１８】
図２４のシーケンスの図２７、図２９の状態を示す第３のステップを参照すると、Ｒｅｐｏｒｔ１メッセージ４７０２−１を送信したノード２００−１、２００−５では、カスタマ＃aに関するＱｕｅｒｙ２メッセージ４７０１−２を生成して、Ｑｕｅｒｙ２メッセージ４７０１−２をネットワーク上にブロードキャスト転送する。Ｑｕｅｒｙ２メッセージ４７０１−２を受信した中継ノードでは、ブロードキャストテーブル２２１１を参照して出力ポートを取得し、Ｑｕｅｒｙ２メッセージ４７０１−２を当該ポートに転送し、受信ノードに到着する。
【０３１９】
図２７、図２９において、点線で示すブロードキャスト転送経路上の各ノードは、Ｑｕｅｒｙ２メッセージ４７０１−２を受信すると、ブロードキャストテーブル２２１１を参照して出力ポートを取得し、当該ポートに転送する処理を行ない、次ホップのノードにＱｕｅｒｙ２メッセージ４７０１−２を転送する。ここでの各ノードの処理は、図２５で説明したＱｕｅｒｙ１メッセージＱｕｅｒｙ２メッセージ４７０１−１の送受信、または第１及び第２の実施の形態で説明したＱｕｅｒｙ制御メッセージの送受信と同じであるため、ここでは説明を省略する。
【０３２０】
図２７、図２９のマルチキャストテーブル２０２１Ａ−１、２０２１Ａ−２、２０２１Ａ−４、２０２１Ａ−５は、ノード２００−１、２００−２、２００−４、２００−５におけるＱｕｅｒｙ２メッセージ４７０１−２を受信した後のマルチキャストテーブルの状態を示している。
【０３２１】
受信エッジノード２００−１、２００−５、２００−６、２００−７では、Ｑｕｅｒｙ２メッセージ４７０１−２を受信すると、図２４のシーケンスの次の第４のステップとして、図２８、図３０に示す処理を行う。
【０３２２】
続いて、図２４のシーケンスにおける図２８、図３０の状態を示す第４のステップについて説明する。
【０３２３】
図２４のシーケンスの図２８、図３０の状態を示す第４のステップを参照すると、Ｑｕｅｒｙ２メッセージ４７０１−２を受信した受信エッジノード２００−４、２００−５、２００−６、２００−７では、自ノードの配下に同じカスタマ＃aを収容しているかをサーチし、カスタマ＃aが存在すれば、Ｒｅｐｏｒｔ２メッセージ４７０２−２を生成し、転送処理を行う。また、同じカスタマ＃aが存在しなければ、Ｒｅｐｏｒｔ２メッセージ４７０２−２を生成しない。
【０３２４】
Ｒｅｐｏｒｔ２メッセージ４７０２−２を受信した中継ノード、受信ノードでは、Ｒｅｐｏｒｔ１メッセージ４７０２−１の受信時と同様に、Ｒｅｐｏｒｔ２メッセージ４７０２−２の受信ポートを学習して、マルチキャストテーブル２０２１Ａを更新する。
【０３２５】
以上説明したＲｅｐｏｒｔ２メッセージの転送経路と各ノードの処理に関しては図２８、図３０で詳細に説明する。図２８、図３０では、Ｒｅｐｏｒｔ２メッセージ４７０２−２の転送経路は点線で記している。
【０３２６】
図２８は、ノード２００−１に対するＲｅｐｏｒｔ２メッセージ４７０２−２の転送経路を示している。ノード２００−１からのＱｕｅｒｙ２メッセージ４７０１−２を受信したノード２００−４〜２００−７の中で、自ノードの配下にカスタマが＃ａがいるノード２００−４と２００−５は、カスタマ＃ａに関するＲｅｐｏｒｔ２メッセージ４７０２−２を生成し、ユニキャストテーブル２２１２−４、２２１２−５を参照して、出力ポートを取得し、Ｒｅｐｏｒｔ２メッセージ４７０２−２を転送する。
【０３２７】
また、ノード２００−４では、マルチキャストテーブル２０２１Ａ−４における「カスタマ＃ａ」に対する出力ポートとしてカスタマ＃ａが接続しているポート＃２のビットを「１」に更新する。同様に、ノード２００−５では、マルチキャストテーブル２０２１Ａ−５における「カスタマ＃ａ」に対する出力ポートとしてカスタマ＃ａが接続しているポート＃３のビットを「１」に更新する。
【０３２８】
中継ノード２００−２では、ノード２００−４、２００−５から受信したＲｅｐｏｒｔ２メッセージ４７０２−２からカスタマ情報（＃ａ）と受信ポート（ポート＃２、＃３）とを学習し、マルチキャストテーブル２０２１Ａ−２において「カスタマ＃ａ」に対する出力ポートとして、ポート＃２、＃３のビットを「１」に更新する。続いて、ユニキャストテーブル２２１２−２を参照して、Ｒｅｐｏｒｔ２メッセージ４７０２−２をポート＃１に転送する。
【０３２９】
送信元ノード２００−１では、中継ノード２００−２から受信したＲｅｐｏｒｔ２メッセージ４７０２−２からカスタマ情報（＃ａ）と受信ポート（ポート＃１）とを学習し、マルチキャストテーブル２０２１Ａ−１において「カスタマ＃ａ」に対する出力ポートとして、ポート＃１のビットを「１」に更新する。
【０３３０】
以上説明した処理の結果、各ノードのマルチキャストテーブルは、ノード２００−１へのＲｅｐｏｒｔ２メッセージ４７０２−２の受信ポートのビットが１に更新され、図２８に示すマルチキャストテーブル２０２１Ａ−１、２０２１Ａ−２、２０２１Ａ−４、２０２１Ａ−５となっている。
【０３３１】
図３０では、ノード２００−５に対するＲｅｐｏｒｔ２メッセージ４７０２−２の転送が示されており、カスタマ＃aを収容するノード２００−１と２００−４からノード２００−５に対してＲｅｐｏｒｔ２メッセージ４７０２−２が転送され、経路上の各ノードはＲｅｐｏｒｔ２メッセージ４７０２−２の受信ポートを学習し、マルチキャストテーブル２０２１Ａを更新している。詳細については図２８と同じ処理であるため、説明は省略する。
【０３３２】
本実施の形態では、上述のマルチキャストテーブル作成方法により、ノード２００−１、２００−２、２００−４、２００−５では、マルチキャストテーブル２０２１Ａ−１、２０２１Ａ−２、２０２１Ａ−４、２０２１Ａ−５が図３０で示すように作成される。マルチキャストテーブル２０２１Ａ−１、２０２１Ａ−２、２０２１Ａ−４、２０２１Ａ−５は、設定されたタイマが終了することにより、対応エントリが「ＯＮ」になる。
【０３３３】
続いて、ノードからカスタマが削除される場合を説明する。
【０３３４】
図３４で示すように、ノード２００−１のカスタマ＃ａが削除されると、ノード２００−１では、カスタマ情報４９０３に削除（Ｌｅａｖｅ）を格納するＱｕｅｒｙ１メッセージ４７０１−１を生成して、Ｑｕｅｒｙ１メッセージ４７０１−１をネットワークにブロードキャスト（図２４を参照）し、マルチキャストテーブル２０２１Ａ−１の対応のエントリを削除（エントリを「ＯＦＦ」にする）する。
【０３３５】
Ｑｕｅｒｙ１メッセージ（Ｌｅａｖｅ）４７０１−１を受信するほかのエッジノードでは、マルチキャストテーブルの対応のエントリを削除（エントリを「ＯＦＦ」にする）する。
【０３３６】
Ｑｕｅｒｙ１メッセージ（Ｌｅａｖｅ）４７０１−１を受信するほかのエッジノードでは、同じカスタマを収容していれば、同じカスタマを削除するためのカスタマ情報４９０３に削除（Ｌｅａｖｅ）を格納するＱｕｅｒｙ２メッセージ４７０１−２を生成する。
【０３３７】
例えば、図３４において、ノード２００−５でカスタマ＃ａを収容しているが、ノード２００−５でもカスタマ＃ａを削除する場合、ノード２００−１から送信されたＱｕｅｒｙ１メッセージ（Ｌｅａｖｅ）４７０１−１に対して、Ｑｕｅｒｙ２メッセージ（Ｌｅａｖｅ）４７０１−２を生成してブロードキャストする。逆に、ノード２００−４ではカスタマ＃ａを削除する予定は無いため、ノード２００−１から送信されたＱｕｅｒｙ１メッセージ（Ｌｅａｖｅ）４７０１−１に対して、Ｑｕｅｒｙ２メッセージ（Ｊｏｉｎ）４７０１−２を生成してブロードキャストする。ノード２００−４から送信されたＱｕｅｒｙ２メッセージ（Ｊｏｉｎ）４７０１−２を受信するほかのエッジノードでは、同じカスタマ＃ａを収容していれば、Ｒｅｐｏｒｔ２メッセージ４７０２−２を返信する。
【０３３８】
なお、Ｑｕｅｒｙ１メッセージ（Ｌｅａｖｅ）４７０１−１とＱｕｅｒｙ２メッセージ（Ｌｅａｖｅ）４７０１−２に関しては、Ｒｅｐｏｒｔメッセージ（Ｌｅａｖｅ）というメッセージは生成しない。ＲｅｐｏｒｔメッセージはＱｕｅｒｙメッセージ（Ｊｏｉｎ）のみに回答するためのメッセージである。
【０３３９】
Ｑｕｅｒｙ２メッセージ（Join）４７０１−２により作成された対応エントリは、エントリ有効タイマ設定により、エントリが有効にする。
【０３４０】
上述のカスタマ削除処理は、第１及び第２の実施の形態に対して、第３の実施の形態と同じ手順で実行される（Ｑｕｅｒｙメッセージの送受信は、図９のシーケンスを参照）。
【０３４１】
（第３の実施の形態におけるマルチキャストフレームのフォワーディング方法）
上述のマルチキャストテーブルの作成方法によって生成されたマルチキャストテーブル２０２１Ａを参照してマルチキャストフレームを転送する本実施の形態でのマルチキャストキャスト転送方法について以下に詳細に説明する。
【０３４２】
本実施の形態では、ブロードキャストフォワーディングタグ４５０８およびカスタマ分離タグ４５０１を格納しているマルチキャストフレームを受信したら、ブロードキャストテーブル２２１１を参照して、ブロードキャストフォワーディングタグ４５０８に格納されるノード識別子に対する出力ポート（ブロードキャスト出力ポート）を取得すると共に、マルチキャストテーブル２０２１Ａを参照して、カスタマ分離タグ４５０１に格納されるカスタマＩＤに対する出力ポート（マルチキャスト出力ポート）を取得し、取得したブロードキャスト出力ポートとマルチキャスト出力ポートに対して「論理積」を取り、その結果として得られた出力ポートにマルチキャストフレームを転送する。
【０３４３】
以降では、図３１、図３２、図３３および図３のノード構成図を用いて第３の実施の形態のマルチキャストフレームの転送方法に関して詳細に説明する。
【０３４４】
図３１はノード２００−４のポート＃２に接続するカスタマ＃aのホストＣからブロードキャストフレームを受信した場合のカスタマ＃aに関するマルチキャスト転送経路を示している。マルチキャストフレームの転送経路は太線で示している。
【０３４５】
まず、入口側のエッジノードであるノード２００−４の処理から説明する。
【０３４６】
ノード２００−４はカスタマ＃ａからＭＡＣ＿ＤＡ＝０ｘＦＦＦＦのブロードキャストフレームを受信すると、ブロードキャストフォワーディングタグ４５０８に自ノードのノード識別子「２００−４」を格納し、カスタマ分離タグ４５０１にはカスタマＩＤ「＃ａ」を格納して、両タグを付加する。
【０３４７】
その後、ブロードキャストテーブル２２１１−４を参照して、ブロードキャストフォワーディングタグ「２００−４」に対するブロードキャスト出力ポート＃１、＃３を取得すると共に、マルチキャストテーブル２０２１Ａ−４を参照して、対応エントリが「ＯＮ」であれば、カスタマ＃ａに対するマルチキャスト出力ポート＃１、＃３を取得し、両者の論理積を取って、転送ポート＃１、＃３を取得し、当該ポート＃１、＃３にフレームを転送する。
【０３４８】
対応エントリが「ＯＦＦ」の場合は、対応エントリの代わりに仮エントリ（全てのポートが“１”）を利用し、マルチキャストフレームはマルチキャストテーブル２０２１Ａ−４の仮エントリとブロードキャストテーブル２２１１−４の両方を参照して転送する。
【０３４９】
ノード２００−４からカスタマ＃ａに関するマルチキャストフレームを受信した中継ノード２００−２は、ブロードキャストテーブル２２１１−２を参照して、ブロードキャスト出力ポート＃１を取得すると共に、マルチキャストテーブル２０２１Ａ−２を参照して、対応エントリが「ＯＮ」であれば、マルチキャスト出力ポート＃１、＃２、＃３を取得し、両者の論理積を取って、転送ポート＃１を取得し、当該ポート＃１にマルチキャストフレームを出力する。
【０３５０】
ノード２００−２からマルチキャストフレームを受信したエッジノード２００−１は、ブロードキャストテーブル２２１１−１を参照した結果、ブロードキャストフォワーディングタグ２００−４に対する出力ポートが存在しないことから、自ノードが出口側のエッジ（Ｅｇｒｅｓｓ）ノードであると判断する。
【０３５１】
同時にマルチキャストテーブル２０２１Ａ−１を参照して、対応エントリが「ＯＮ」であれば、マルチキャスト転送ポート＃１、＃２を取得し、その中でホスト側のポートであるポート＃１（カスタマ識別テーブルから判断する）を出力ポートとする。その後、マルチキャストフレームのブロードキャストフォワーディングタグとカスタマ分離タグを削除して、通常のイーサネット（Ｒ）フレーム４２００に変換してポート＃１に転送することにより、当該フレームがホストＡに到着する。
【０３５２】
同様に、ノード２００−４からフレームを受信したノード２００−５は、ブロードキャストテーブル２２１１−５を参照した結果、ブロードキャストフォワーディングタグ２００−４に対する出力ポートが存在しないことから、自ノードが出口側のエッジ（Ｅｇｒｅｓｓ）ノードであると判断し、同時にマルチキャストテーブル２０２１Ａ−５を参照して、マルチキャスト転送ポート＃１、＃２、＃３を取得し、その中でホスト側のポートであるポート＃３（カスタマ識別テーブルから判断する）を出力ポートとする。その後、マルチキャストフレームのブロードキャストフォワーディングタグとカスタマ分離タグを削除して、通常のイーサネット（R）フレーム４２００に変換してポート＃３に転送することにより、当該フレームがホストＢに到着する。
【０３５３】
上述のマルチキャストフレームの送受信に関するノード内の各部の動作に対して図３を用いて説明する。
【０３５４】
まず、入口側のエッジノード２００−４における処理から説明する。
【０３５５】
ポート＃１でカスタマ#aの端末Aから、ＭＡＣ＿ＤＡ＝０ｘＦＦＦＦであるブロードキャストフレームを受信したノード２００−４では、フレーム解析部２０１１は、受信フレームが通常イーサネット（Ｒ）フレームであるため、タグ挿入部２０１２にフレームを転送する。
【０３５６】
タグ挿入部２０１２は受信フレームのＭＡＣ＿ＤＡが０ｘＦＦＦＦであるため、ブロードキャストフォワーディングタグとして、フレームの拡張タグ格納領域４３０１に自ノードのノード識別子「２００−４」を格納する。また、カスタマ識別テーブル２０１７を参照して、入力ポート＃１に対するカスタマＩＤ＝＃aを取得し、カスタマタグとして、フレームの拡張タグ格納領域４３０１にカスタマＩＤ＝＃aを格納する。タグ挿入部２０１２は、両方のタグを付加したフレームをタグスイッチ部２０１３に転送する。
【０３５７】
タグスイッチ部２０１３内のテーブル検索部２１０２（図４）は、マルチキャストテーブル２０２１Ａを参照して、対応エントリが「ON」であれば、カスタマ#aに対する出力ポート＃１、＃２、＃３を取得すると共に、フォワーディングテーブル格納部２１０８内のブロードキャストテーブル２２１１を参照して、ノード識別子２００−４に対する出力ポート＃１、＃３を取得する。その後、タグスイッチ部２０１３は両者の論理積を取り、その結果としてポート＃１、＃３を得て、マルチキャストフレームを出力する。
【０３５８】
対応エントリが「OFF」の場合、タグスイッチ部２０１３内のテーブル検索部２１０２（図４）は、マルチキャストテーブル２０２１Ａのエントリの代わりに仮エントリ（全てのポートが「１」）を用いて、マルチキャストテーブル２０２１Ａの仮エントリとブロードキャストテーブル２２１１の論理積を取った結果のポートにマルチキャストフレームを出力する。
【０３５９】
続いて、中継ノードにおける処理を説明する。
【０３６０】
ノード２００−２のフレーム解析部２０１１は、受信フレームが拡張タグ付きフレームであるため、フレームをタグスイッチ部２０１３に転送する。タグスイッチ部２０１３はマルチキャストテーブル２０２１Ａを参照して、対応エントリが「ON」であれば、カスタマ#aに対する出力ポート＃１、＃２、＃３を取得すると共に、フォワーディングテーブル格納部２１０８内のブロードキャストテーブル２２１１を参照して、ノード識別子２００−４に対する出力ポート＃１を取得する。その後、タグスイッチ部２０１３は両者の論理積を取り、その結果としてポート＃１を得て、マルチキャストフレームを出力する。
【０３６１】
対応エントリが「OFF」の場合、タグスイッチ部２０１３内のテーブル検索部２１０２（図４）は、マルチキャストテーブル２０２１Ａのエントリの代わりに仮エントリ（全てのポートが「１」）を用いて、マルチキャストテーブル２０２１Ａの仮エントリとブロードキャストテーブル２２１１の論理積を取った結果のポートにマルチキャストフレームを出力する。
【０３６２】
続いて、出口側のエッジノード２００−１における処理を説明する。
【０３６３】
ノード２００−１のフレーム解析部２０１１は、受信フレームが拡張タグ付きフレームであるため、フレームをタグスイッチ部２０１３に転送する。
【０３６４】
タグスイッチ部２０１３はフォワーディングテーブル格納部２１０８内のブロードキャストテーブル２２１１を参照して、ノード識別子２００−４に対する出力ポートがないため、自ノードが出口側のエッジ（Ｅｇｒｅｓｓ）ノードであると判断する。
【０３６５】
また、マルチキャストテーブル２０２１Ａを参照して、対応エントリが「ON」であれば、カスタマ#aに対する出力ポート＃１、＃２を取得し、その中でホスト側ポートであるポート＃１を出力ポートとする。
【０３６６】
対応エントリが「OFF」の場合、タグスイッチ部２０１３内のテーブル検索部２１０２（図４）は、マルチキャストテーブル２０２１Ａのエントリの代わりに仮エントリ（全てのポートが「１」）を用いて、マルチキャストテーブル２０２１Ａの仮エントリとブロードキャストテーブル２２１１の論理積を取った結果のポートにマルチキャストフレームを出力する。
【０３６７】
タグスイッチ部２０１３はタグ削除部２０１４にフレームを転送し、タグ削除部２０１４は受信フレームのブロードキャストフォワーディングタグとカスタマ分離タグを削除して、通常のイーサネット（R）フレーム４２００に変換して、ホスト側の出力ポート２１０−ｏｕｔに転送する。
【０３６８】
図３２、図３３では、ノード２００−１、２００−５からのマルチキャストフレームを転送する際の転送経路を示している。マルチキャストフレームを送受信する各ノードの各部の処理は、上述のノード２００−４の説明と同一であるため、説明は省略する。
【０３６９】
以上、カスタマが追加される際に、マルチキャストテーブルを更新する方法と、マルチキャストテーブルを参照してマルチキャストフレームを転送する方法を説明した。
【０３７０】
図３４は、ノード２００−１からカスタマ＃ａが削除される場合の手順を示す図である。
【０３７１】
カスタマが削除される際は、上述したように、Ｑｕｅｒｙメッセージ（Leave）を生成して、その制御メッセージをネットワークにブロードキャストし、マルチキャストテーブルの対応のエントリを削除する。
【０３７２】
図３４で示すように、カスタマ#aが削除されるノード２００−１では、Ｑｕｅｒｙ１メッセージ（Leave）４７０１−１を生成して、その制御メッセージをネットワークにブロードキャストし、マルチキャストテーブル２０２１Ａの対応のエントリを削除する。Ｑｕｅｒｙ１メッセージ（Leave）４７０１−１を受信するほかのエッジノードでも、カスタマ#aを削除する場合には、対応のＱｕｅｒｙ２メッセージ（Leave）４７０１−２を生成して、全ネットワークにブロードキャストし、マルチキャストテーブル２０２１Ａの対応のエントリを削除するが、この送信処理は、Ｑｕｅｒｙ１メッセージ４７０１を送信する際と同じであるため、詳細の説明は省略する。
【０３７３】
（第３の実施の形態の効果）
以上説明したように、第３の実施の形態のマルチキャスト転送方法では、第１及び第２の実施の形態の場合と同様に、カスタマに関係する経路のみにマルチキャストフレームを転送することが可能となる。
【０３７４】
さらに、マルチキャストテーブル２０２１Ａとブロードキャストテーブル２２１１の両方を参照して、マルチキャスト出力ポートを決定し、マルチキャスト転送制御を行うことにより、マルチキャストテーブル２０２１Ａのエントリをカスタマ毎に全ての送信元ノードで共有することができる。
【０３７５】
これにより、第１及び第２の実施の形態では、マルチキャストテーブルにおいて「エッジノード数×カスタマ数」だけの数のエントリが必要であるのに対して、本実施の形態では、「カスタマ数」だけのエントリ数で対応可能であり、マルチキャストテーブルのエントリ数をエッジノード数分の一に大幅に削減可能となる。
【０３７６】
すなわち、本実施の形態によれば、マルチキャストテーブル構成の簡略化を可能にすることにより、マルチキャストテーブルのエントリ数を「エッジノード数×カスタマ数」から「カスタマ数」まで縮小することができ、テーブルに必要なメモリ量を大幅に削減することができる。
【０３７７】
（第４の実施の形態）
【０３７８】
本発明の第４の実施の形態について、図面を参照して説明する。
【０３７９】
本発明の第４の実施の形態は、第２、第３の実施の形態において、送信元エッジノードに対して他のエッジノードから送信されるあるカスタマに関するＲｅｐｏｒｔ１、２メッセージが、送信元エッジノードに複数回到着するのを回避する処理を加えている。
【０３８０】
第３の実施の形態で説明した図２７と図２８とを参照すると、ノード２００−１から送信されたカスタマ＃aに関するＱｕｅｒｙ２メッセージ４７０１−２に対して、カスタマ#aを収容しているエッジノード２００−４、２００−５では、ノード２００−１に対してＲｅｐｏｒｔ２メッセージ４７０２−２を転送している。
【０３８１】
図２８の例では、ノード２００−４、２００−５から送出されたＲｅｐｏｒｔ２メッセージ４７０２−２は、中継ノード２００−２を経由して、それぞれノード２００−１に到着している。しかしながら、ノード２００−１は先にポート＃２に到着したＲｅｐｏｒｔ２メッセージ４７０２−２により、カスタマ＃aに関する学習は完了するため、その後にポート＃２に到着するＲｅｐｏｒｔ２メッセージは意味を持たないことになる。
【０３８２】
これに対して、第４の実施の形態では、図３５に示すＱｕｅｒｙメッセージ受信テーブル３８００を各ノードで保持することにより、上記Ｒｅｐｏｒｔメッセージの複数回到着を回避する。
【０３８３】
このＱｕｅｒｙメッセージ受信テーブル３８００は、受信したＱｕｅｒｙメッセージの送信元エッジノードの識別子とそのＱｕｅｒｙメッセージに格納されているカスタマIDを管理するためのテーブルである。
【０３８４】
本実施例では、ノード２００−１から送信されたＱｕｅｒｙ２メッセージ４７０１−２とそれに対して返信されるＲｅｐｏｒｔ２メッセージ４７０２−２を例とするが、Ｑｕｅｒｙ１メッセージとＲｅｐｏｒｔ１メッセージに関しても同様の処理が適用できる。
【０３８５】
以下、図２７のＱｕｅｒｙ２メッセージ送受信処理と図２８のＲｅｐｏｒｔ２メッセージ送受信処理におけるＱｕｅｒｙメッセージ受信テーブル３８００の操作について説明する。図２７、図２８で示す拡張タグ付きフレームを転送するネットワーク２３００の各ノードでは、図３５に示す構成のＱｕｅｒｙメッセージ受信テーブル３８００を保持する。
【０３８６】
図２７において、ノード２００−１からのカスタマ#aに関するＱｕｅｒｙ２メッセージ４７０１−２を受信した各ノードは、Ｑｕｅｒｙメッセージ受信テーブル３８００の送信元ノード識別子＝「２００−１」に対するカスタマＩＤとして、Ｑｕｅｒｙ２メッセージ４７０１−２に格納しているカスタマID＝＃aを登録する。これは、ノード２００−１からカスタマ＃aに関するＱｕｅｒｙ２メッセージ４７０１−２を受信したことを示している。他の中継ノード２００−３およびエッジノード２００−４、２００−５、２００−６、２００−７でも同様の処理を行ない、Ｑｕｅｒｙメッセージ受信テーブル３８００を更新する。
【０３８７】
続いて、図２８を参照すると、Ｑｕｅｒｙ２メッセージ４７０１−２を受信したエッジノード２００−４、ノード２００−５では、カスタマ#aを収容しているため、Ｑｕｅｒｙ２メッセージ４７０１−２の送信元ノードであるノード２００−１に対してＲｅｐｏｒｔ２メッセージ４７０２−２をユニキャスト送信する。
【０３８８】
ここで、Ｒｅｐｏｒｔ２メッセージ４７０２−２を受信した各ノードでは、Ｑｕｅｒｙメッセージ受信テーブル３８００を検索して、Ｑｕｅｒｙ送信元ノードのエントリに、Ｒｅｐｏｒｔ２メッセージ４７０２−２の宛先ノード「ノード２００−１」が存在し、Ｒｅｐｏｒｔ２メッセージ４７０２−２に格納されているカスタマID（カスタマ＃a）が登録されていれば、そのカスタマIDを削除する。
【０３８９】
例えば、図３５で示すように、Ｒｅｐｏｒｔ２メッセージ４７０２−２を送信するノード２００−４のＱｕｅｒｙメッセージ受信テーブル３８００の状態は、本処理を施すことにより、「Ｒｅｐｏｒｔメッセージを受信した後」の状態を示す内容となる。
【０３９０】
具体的には、中継ノード２００−２では、エッジノード２００−４からカスタマ＃aに関するノード２００−１向けのＲｅｐｏｒｔ２メッセージ４７０２−２を受信したら、Ｑｕｅｒｙメッセージ受信テーブル３８００を検索して、ノード２００−１に対するエントリにカスタマ＃aが登録されているため、そのカスタマIDを削除する。
【０３９１】
その後、ノード２００−５からカスタマ＃aに関するノード２００−１向けのＲｅｐｏｒｔ２メッセージ４７０２−２を受信したら、Ｑｕｅｒｙメッセージ受信テーブル３８００を検索して、ノード２００−１に対するエントリにカスタマ＃aが登録されていないため、Ｒｅｐｏｒｔ２メッセージ４７０２−２を廃棄する。
【０３９２】
この処理により、あるカスタマに関する同一ノード宛てのＲｅｐｏｒｔ２メッセージを複数受信した場合、２番目以降に受信したメッセージを転送することを回避できる。
【０３９３】
図２８の例では、Ｒｅｐｏｒｔ２メッセージ４７０２−２の転送処理を行なわないノード（たとえば、エッジノード２００−７、２００−６や中継ノード２００−３）が存在する。このようなノードでは、Ｑｕｅｒｙメッセージ受信テーブル３８００のエントリが更新されないため、タイマを定義して、ある時間が経過した時点でＱｕｅｒｙメッセージ受信テーブル３８００のカスタマ情報をリセットするようにしてもよい。
【０３９４】
（第４の実施の形態による効果）
以上説明したように、第４の実施の形態では、カスタマに閉じたマルチキャスト転送を実現すると共に、Ｑｕｅｒｙメッセージを送信したノードに対して複数のＲｅｐｏｒｔメッセージが到着するのを回避でき、Ｒｅｐｏｒｔメッセージに対する処理負荷の軽減およびネットワーク帯域の効率化を図ることができる。
【０３９５】
すなわち、本実施の形態によれば、Ｑｕｅｒｙメッセージ受信テーブル３８００を用いることにより、同じルートノードに転送される同じカスタマに対するＲｅｐｏｒｔメッセージに対して、複数回の送信するのを防止し、Ｒｅｐｏｒｔメッセージに対するノードの処理負担を軽減することができる。
【０３９６】
（第５の実施の形態）
【０３９７】
本発明の第５の実施の形態について、図面を参照して説明する。
【０３９８】
本発明の第５の実施の形態は、第１から第４の実施の形態において、制御メッセージのカスタマ情報フィールドに複数のカスタマ情報を格納可能としている。
【０３９９】
図３６は、第５の実施の形態における制御メッセージ（Ｑｕｅｒｙメッセージ、Ｒｅｐｏｒｔメッセージ）のフレームフォーマットである。制御メッセージフレーム４６００Ａは、制御メッセージ属性情報４９００に複数のカスタマ情報４９０３を格納する構成となっている。
【０４００】
本実施の形態では、複数のカスタマが接続されているノードが制御メッセージ（Ｑｕｅｒｙメッセージ、Ｒｅｐｏｒｔメッセージ）を生成する際に、制御メッセージに自ノードの配下に収容している複数のカスタマ情報を格納することにより、生成される制御メッセージ数を減少することを目的としている。
【０４０１】
図３７は、本実施の形態の拡張タグネットワーク２３００の接続構成例を示す図である。エッジノード２００−１には、ポート＃１にカスタマ#aのホストＡが接続し、ポート＃４にカスタマ#bのホストＸが接続している。また、エッジノード２００−４には、ポート＃２にカスタマ#aのホストＣが接続し、エッジノード２００−６のポート＃にはカスタマ#bのホストＹが接続している。
【０４０２】
本実施の形態では、複数のカスタマを所有しているノード２００−１でＱｕｅｒｙ１メッセージ４７０１−１を生成する際には、制御メッセージの属性情報４９００にカスタマ#a、カスタマ#bの情報を一緒に格納することにより、Ｑｕｅｒｙ１メッセージのフレーム数を低減することができる。ここでは、Ｑｕｅｒｙ１メッセージを例に取り説明したが、他の制御メッセージ（Ｒｅｐｏｒｔ１メッセージ、Ｑｕｅｒｙ２メッセージ、Ｒｅｐｏｒｔ２メッセージ）においても、メッセージ内に複数カスタマの情報を格納可能である。
【０４０３】
図３７を参照すると、ノード２００−１において、カスタマ#aとカスタマ#bが同時に追加した場合、送信元エッジノード２００−１ではカスタマ#aとカスタマ#bのカスタマ情報を格納したＱｕｅｒｙ１メッセージ４７０１−１を生成してネットワークにブロードキャストする。Ｑｕｅｒｙ１メッセージ４８０１を受信した各ノードは、第１及び第２の実施の形態と同様に次ホップのノードに転送する。
【０４０４】
続いて、図３８を参照すると、Ｑｕｅｒｙ１メッセージ４７０１−１を受信した各エッジノード２００−４〜２００−７は、Ｑｕｅｒｙ１メッセージ４７０１−１に格納されるカスタマ情報に関し、カスタマ#aを収容するノード２００−４はカスタマ#aの情報のみを格納したＲｅｐｏｒｔ１メッセージ４７０２−１を生成して、ノード２００−１に対してユニキャスト送信し、カスタマ#bを収容するノード２００−６はカスタマ#bの情報のみを格納したＲｅｐｏｒｔ１メッセージ４７０２−１を生成して、ノード２００−１に対してユニキャスト送信する。他の受信エッジノード２００−５、７は、カスタマ＃a、＃bを収容しないので、Ｑｕｅｒｙ１メッセージ４７０１−１を廃棄する。
【０４０５】
中継ノード、受信ノードの処理は第１から第３の実施の形態で説明したのと同様に、Ｒｅｐｏｒｔ１メッセージの受信処理によりマルチキャストテーブルを更新する。
次に、図３９に示すように、エッジノード２００−４にさらにカスタマ＃ｃのホストＥが接続され、エッジノード２００−７にカスタマ＃ｃのホストＦが接続されている状態で、上記のようにノード２００−１からＱｕｅｒｙ１メッセージ４７０１−１が送信された場合について説明する。
図３９の場合、Ｑｕｅｒｙ１メッセージ４７０１−１を受信した各エッジノード２００−４〜２００−７は、上記のように、ノード２００−４がカスタマ#aの情報のみを格納したＲｅｐｏｒｔ１メッセージ４７０２−１を、ノード２００−６がカスタマ#bの情報のみを格納したＲｅｐｏｒｔ１メッセージ４７０２−１をノード２００−１に対してユニキャスト送信すると共に、その後、エッジノード２００−４が、カスタマ#aとカスタマ#ｃのカスタマ情報を格納したＱｕｅｒｙ２メッセージ４７０１−２を生成してネットワークにブロードキャストする。
続いて、図４０を参照して、エッジノード２００−４からのＱｕｅｒｙ２メッセージ４７０１−２を受信した各エッジノード２００−１、５、６、７についてのＱｕｅｒｙ２メッセージ４７０１−２に格納されるカスタマ情報に関する処理動作について説明する。カスタマ#aを収容するノード２００−１は、カスタマ#aの情報のみを格納したＲｅｐｏｒｔ２メッセージ４７０２−２を生成して、ノード２００−４に対してユニキャスト送信する。また、カスタマ#ｃを収容するノード２００−７は、カスタマ#ｃの情報のみを格納したＲｅｐｏｒｔ２メッセージ４７０２−２を生成して、ノード２００−４に対してユニキャスト送信する。
他の受信エッジノード２００−２、２００−３、２００−４は、カスタマ＃a、＃ｃを収容しないので、Ｑｕｅｒｙ２メッセージ４７０１−２を廃棄する。
【０４０６】
中継ノード、受信ノードの処理は第１から第３の実施の形態で説明したのと同様に、Ｒｅｐｏｒｔ２メッセージの受信処理によりマルチキャストテーブルを更新する。
【０４０７】
（第５の実施の形態による効果）
以上説明したように、本実施の形態では、複数のカスタマが接続されているノードが制御メッセージを生成する際に、制御メッセージに複数のカスタマ情報を格納することにより、生成される制御メッセージ数を減少することができる。
【０４０８】
（第６の実施の形態）
以下、本発明の第６の実施の形態について、図面を参照して詳細に説明する。
【０４０９】
上記第１から第５の実施の形態では、主に２種類のマルチキャスト転送方式（第１及び第２の実施の形態による第１の転送方式と、第３の実施の形態による第２の転送方式）について説明した。
【０４１０】
第１の転送方式では、マルチキャストテーブルのエントリを「スパニングツリー」及び「カスタマ」毎に作成する方法であり、第２の転送方式は、マルチキャストテーブルのエントリを「カスタマ」毎に作成する方法である。
【０４１１】
この第６の実施の形態では、上記第１の転送方式と第２の転送方式によるマルチキャスト転送方式における、「障害検出」と「障害回復」の処理に特徴を有する。
【０４１２】
図４１を参照すると、拡張タグネットワーク２３００のノード２００−２とノード２００−５の間でリンク障害が発生した場合、拡張タグネットワーク２３００ではRapid Spanning Tree Protocol（８０２．１ｗ）により、例えば図４２で示すような新たなスパニングツリーを生成する。
【０４１３】
本実施例では、障害が発生した後に生成される新しいスパニングツリーに沿ってマルチキャストフレームを転送するために、先ずトポロジー変更ＢＰＤＵを受信したノードで自ノードのマルチキャストテーブル２０２１のエントリをクリアする。
【０４１４】
また、クリアしたマルチキャストテーブル２０２１のエントリを再作成するために、障害検出ノードがスパニングツリーのルートノードに対してＱｕｅｒｙ２メッセージ４７０１−２の送信を要求する。
【０４１５】
要求を受けたルートノードが、Ｑｕｅｒｙ２メッセージ４７０１−２を送信し、Ｑｕｅｒｙ２メッセージ４７０１−２を受信した各ノードではＲｅｐｏｒｔ２メッセージ４７０２−２を返信する。Ｒｅｐｏｒｔ２メッセージ４７０２−２を受信したノードでは、マルチキャストポートを学習することにより、新しいトポロジーに対するマルチキャストテーブル２０２１のエントリが作成される。
【０４１６】
先ず、第１の転送方式のマルチキャスト転送方式における、「障害検出」及び「障害回復」の処理について説明する。
【０４１７】
第１の転送方式において、障害が発生していない「正常」時では、マルチキャストフレームを転送する際に、受信したマルチキャストフレームに格納されている「ソースタグ（送信元ノードＩＤ）」と「カスタマタグ」を検索し、マルチキャストテーブル２０２１を参照することにより、マルチキャストフレームを転送している。
【０４１８】
第１の転送方式における「障害検出」時の処理は以下のようになされる。
【０４１９】
拡張タグネットワーク２３００で、ルートポート側のリンク障害を検出したノードは、トポロジー変更ＢＰＤＵを生成して他ノードに送信するが、トポロジー変更ＢＰＤＵを受信した他ノードではトポロジー変更ＢＰＤＵを分析し、トポロジー変更が発生したスパニングツリーのルートノードのＩＤ情報を取得する。
【０４２０】
その後、マルチキャストテーブル２０２１を検索し、取得したルートノードＩＤに対するエントリをクリアし、そのエントリに対してタイマーを起動する。タイマーにはエントリが有効になるまでの時間が設定される。
【０４２１】
ノードは、タイムアップするまでの間、受信したマルチキャストフレームに対して、ブロードキャストテーブル２２１１を参照して取得したブロードキャスト出力ポートによって転送する。
【０４２２】
例えば、図４３で示すノード２００−３は、ノード２００−５からトポロジー変更ＢＰＤＵを受信したら、マルチキャストテーブル２０２１−３内でトポロジー変更が発生したスパニングツリーのルートノードである「ノード２００−１」に対応するエントリをクリアする。
【０４２３】
また、クリアしたエントリに対してタイマーを起動する。タイムアップするまでの間、送信元ノード２００−１から送信されるマルチキャストフレームの出力ポートは、ブロードキャストテーブル２２１１−３を参照して転送する。
【０４２４】
上述の「障害検出」時の処理に関してノード構成を示す図３、図４を用いて説明する。
【０４２５】
図３を参照すると、フレーム解析部２０１１は、受信したフレームを解析し、ＢＰＤＵフレームであれば、ＳＴＰ制御部２０１９に転送する。ＳＴＰ制御部２０１９は、受信したＢＰＤＵフレームの情報に基づき、Rapid Spanning Tree Protocol（８０２．１ｗ）に従って新たなスパニングツリー作成の処理を行う。
【０４２６】
スパニングツリー作成処理を行った結果、ポートの役割変更が発生したら、タグスイッチ部２０１３内のテーブル制御部２１０３（図４を参照）を通じてフォワーディングテーブル格納部２０１８を更新する。また、ＳＴＰ制御部２０１９は、受信したＢＰＤＵフレームがトポロジー変更ＢＰＤＵであれば、テーブル制御部２１０３を通じてマルチキャストテーブル２０２１をクリアし、タイマーを起動する。
【０４２７】
フレーム解析部２０１１が受信したフレームがマルチキャストフレームである場合に関しては上記第２の実施の形態で説明したので詳細は省略する。
【０４２８】
続いて、第１の転送方式における「障害回復」時の処理について説明する。
【０４２９】
先ず、図４４を用いてＱｕｅｒｙ２再送信要求メッセージ４８００のフレームフォーマットについて説明する。
【０４３０】
図示のように、Ｑｕｅｒｙ２再送信要求メッセージ４８００は、制御メッセージ４６００のフレームフォーマット（図６を参照）において、拡張タグ拡張領域４６０３にフォワーディングタグ４５００を格納し、制御メッセージの属性情報４９００にはＱｕｅｒｙ２再送信要求メッセージ４８００を示す値を格納して構成する。Ｆｒａｍｅフィールド４９０１は、Ｑｕｅｒｙ２再送信要求メッセージ４８００に複数カスタマ情報を格納する場合に利用する。
【０４３１】
続いて、Ｑｕｅｒｙ２再送信要求メッセージ４８００の生成及び送受信について詳細に説明する。
【０４３２】
図４２で示すノード２００−５では、ルートポート側のリンク障害を検出すると、ノードルートポートの変更情報から、ポロジー変更が発生するスパニングツリーのルートノードＩＤ情報（例えば、２００−１）を取得する。ノード２００−５では、ルートノードＩＤ情報を拡張タグ拡張領域４６０３に格納したＱｕｅｒｙ２再送信要求メッセージ４８００を生成する。
【０４３３】
続いて、図４５のシーケンスを用いて上述のＱｕｅｒｙ２再送信要求メッセージ４８００の送受信について説明する。
【０４３４】
ルートポート側でリンクダウンを検出したノードでは、マルチキャストテーブル２０２１内でトポロジー変更が発生したスパニングツリーに対応するエントリをクリアし、Ｑｕｅｒｙ２再送信要求メッセージ４８００を生成して、ルートノード２００−１から設定により定期的に送信されるＱｕｅｒｙ２メッセージ４７０１−２を待たずに、新しいスパニングツリーに沿ってルートノード２００−１向けてユニキャスト送信する。
【０４３５】
Ｑｕｅｒｙ２再送信要求メッセージ４８００を受信する中継ノードでは、対応ルートノードＩＤに対するマルチキャストテーブルのエントリをクリアした後、ルートノードに転送する。
【０４３６】
Ｑｕｅｒｙ２再送信要求メッセージ４８００を受信したルートノード２００−１では、対応ルートノードＩＤに対するマルチキャストテーブル２０２１のエントリをクリアする。また、自ノード宛のＱｕｅｒｙ２再送信要求メッセージ４８００であれば、自ノードの配下に収容しているカスタマ情報を格納したＱｕｅｒｙ２メッセージ４７０１−２を生成し、ネットワーク上にブロードキャストする。
【０４３７】
Ｑｕｅｒｙ２メッセージ４７０１−２を受信する各ノードでは、Ｒｅｐｏｒｔ２メッセージ４７０２−２を生成して返信する。Ｒｅｐｏｒｔ２メッセージ４７０２−２を受信したノードにおいては、マルチキャストポートを学習することにより、新しいトポロジーに対するマルチキャストテーブル２０２１のエントリエントリが作成される。
【０４３８】
続いて、上述の「障害回復」時の処理をノードの構成を示す図３、図４を用いて説明する。
【０４３９】
図４を参照すると、テーブル制御部２１０３は、フォワーディングテーブル格納部２０１８を参照していて、フォワーディングテーブル格納部２０１８でルートポート状態の変更がある場合はマルチキャスト制御部２０２０に通知する。
【０４４０】
マルチキャスト制御部２０２０は、テーブル制御部２１０３から受信するルートポート状態の変更情報を解析し、トポロジー変更が発生したスパニングツリーのルートノードＩＤを取得する。
【０４４１】
続いて、図３を参照すると、マルチキャスト制御部２０２０は、取得したルートノードＩＤをＱｕｅｒｙ２再送信要求メッセージ４８００の拡張タグ拡張領域４６０３に格納してタグスイッチ部２０１３に送信し、タグスイッチ部２０１３は、フォワーディングテーブル格納部２０１８を参照して、Ｑｕｅｒｙ２再送信要求メッセージ４８００を出力ポート２２０−ＯＵＴに転送する。
【０４４２】
中継ノードでは、フレーム解析部２０１１で受信するフレームを解析し、マルチキャスト制御メッセージであればマルチキャスト制御部２０２０に送信する。マルチキャスト制御部２０２０は受信したマルチキャスト制御メッセージのＴｙｐｅ４９０２を分析し、Ｑｕｅｒｙ２再送信要求メッセージ４８００であればマルチキャストテーブル２０２１をクリアした後、タグスイッチ部２０１３に転送する。タグスイッチ部２０１３は、フォワーディングテーブル格納部２０１８により、出力ポート２２０−ＯＵＴに転送する。
【０４４３】
ルートノードでは、フレーム解析部２０１１で受信するフレームを解析し、マルチキャスト制御メッセージであればマルチキャスト制御部２０２０に送信する。マルチキャスト制御部２０２０は受信したマルチキャスト制御メッセージのＴｙｐｅ４９０２を分析し、Ｑｕｅｒｙ２再送信要求メッセージ４８００であればマルチキャストテーブル２０２１をクリアする。
【０４４４】
また、自ノード宛のＱｕｅｒｙ２再送信要求メッセージ４８００であれば、カスタマ管理モジュール２０１６を検索して、自ノードの配下のカスタマ情報を格納したＱｕｅｒｙ２メッセージ４７０１−２を生成してタグスイッチ部２０１３に送信する。
【０４４５】
Ｑｕｅｒｙ２メッセージ４７０１−２の送受信からマルチキャストテーブルが再作成されるまでの処理に関しては、前述した他の実施の形態で説明したのと同様であるため説明は省略する。
【０４４６】
図４６を参照すると、上述の処理を通じて、送信元ノード２００−１がルートノードとなるスパニングツリー上の各ノードのマルチキャストテーブル２０２１は、マルチキャストテーブル２０２１−１、２０２１−２、２０２１−３、２０２１−５に示すようになる。
【０４４７】
続いて、第２の転送方式における、「障害検出」時及び「障害回復」時のマルチキャスト制御方式に関して説明する。
【０４４８】
第２の転送方式において、障害が発生していない「正常」時では、マルチキャストフレームを転送する際に、受信したマルチキャストフレームに格納されている「ソースタグ（送信元ノードＩＤ）」と「カスタマタグ」を検索し、マルチキャストテーブル２０２１とフォワーディングテーブル２２１１の両方を参照することによりマルチキャストフレームを転送している。
【０４４９】
第２の転送方式における「障害検出」時の処理は以下のようになされる。
【０４５０】
拡張タグネットワーク２３００で、ルートポート側のリンク障害を検出したノードは、トポロジー変更ＢＰＤＵを生成して他ノードに送信するが、トポロジー変更ＢＰＤＵを受信した他ノードでは、マルチキャストテーブルをクリアし、タイマーを起動する。
【０４５１】
クリアされたエントリが更新される（タイムアップするまで）までの間に受信したマルチキャストフレームに関しては、マルチキャストテーブル２０２１とフォワーディングテーブル（ブロードキャストテーブル２２１１）を参照して転送するが、第３の実施の形態で説明したように、参照するマルチキャストテーブルのエントリがクリアされて無効状態であれば、対応するマルチキャストエントリの代わりに用いる仮エントリ（全てのポートが「１」）とブロードキャストテーブル２２１１を参照して転送する。
【０４５２】
続いて、第２の転送方式における「障害回復」時の処理について説明する。
【０４５３】
「障害回復」時における、Ｑｕｅｒｙ２再送信要求メッセージ４８００の生成および送受信に関する処理は、上記第１の転送方式の場合と同じである。
【０４５４】
第１の転送方式と相違する点は、「障害回復」時（マルチキャストエントリが更新された後）のマルチキャストフレームの転送方法でるが、それぞれの転送方式におけるマルチキャストフレームの転送方法に関しては、第２の実施の形態と第３の実施の形態で説明しているので詳細な説明は省略する。
【０４５５】
以下は、第１と第２のそれぞれの転送方式における、「正常」時、「障害検出」時、「障害回復」時におけるマルチキャストフレームの転送方法をまとめて説明する。
【０４５６】
「正常」時において
第１の転送方式でマルチキャストフレームを転送する際には、マルチキャストテーブル２０２１のみを参照して転送する。
【０４５７】
第２の転送方式でマルチキャストフレームを転送する際には、マルチキャストテーブルとフォワーディングテーブルを参照して転送する。
【０４５８】
「障害検出」時において
第１の転送方式では、障害が発生した場合にマルチキャストテーブルをクリアし、タイマーアップするまで受信するマルチキャストフレームは、フォワーディングテーブルを参照して転送する。
【０４５９】
第２の転送方式では、障害が発生した場合にマルチキャストテーブルをクリアし、タイマーアップするまで受信するマルチキャストフレームは、マルチキャストテーブルの仮エントリとフォワーディングテーブルを参照して転送される。
【０４６０】
「障害回復」時において
第１の転送方式では、「障害検出」時の処理によりクリアされたマルチキャストテーブルのエントリが更新されたら（エントリが有効になる）、マルチキャストテーブルを参照してマルチキャストフレームを転送する。
【０４６１】
第２の転送方式では、「障害検出」時の処理によりクリアされたマルチキャストテーブルのエントリが更新されたら（エントリが有効になる）、マルチキャストテーブルとフォワーディングテーブルを参照してマルチキャストフレームを転送する。
（第６の実施の形態による効果）
第６の実施の形態によるマルチキャストフレームの転送方法では、リンクに障害が発生した場合でも、障害の回復処理が完了するまでの間、フレーム転送が中断されることがないと共に、回復処理が完了した後は、マルチキャストテーブルを用いた転送を自動的に移行することができる。
【０４６２】
なお、上記各実施の形態のネットワークシステムにおける、各ノードの各機能ついては、ハードウェアによることは勿論として、それらの各機能を有するマルチキャスト転送制御プログラムを、各ノードを構成するコンピュータ装置上で実行することで実現することが可能である。
【０４６３】
このマルチキャスト転送制御プログラムは、磁気ディスク、半導体メモリその他の記録媒体に格納され、その記録媒体からノード及び管理用サーバであるコンピュータ装置にロードされ、コンピュータ装置の動作を制御することにより、上述した各機能を実現する。
【０４６４】
以上好ましい複数の実施の形態をあげて本発明を説明したが、本発明は必ずしも、上記実施の形態に限定されるものでなく、その技術的思想の範囲内において様々に変形して実施することができる。
【図面の簡単な説明】
【０４６５】
【図１】本発明を適用する拡張タグネットワークの構成を示す図である。
【図２】本発明の第１の実施の形態のシーケンス例１を示す図である。
【図３】本発明の第１の実施の形態によるノードの構成を示すブロック図である。
【図４】本発明の第１の実施の形態によるタグスイッチ部の構成を示す図である。
【図５】本発明の第１の実施の形態によるフォワーディングテーブルの構成を示す図である。
【図６】本発明の第１の実施の形態による制御メッセージフレームの構成例を示す図である。
【図７】本発明の第１の実施の形態によるマルチキャストテーブルの構成例を示す図である。
【図８】本発明の第１の実施の形態による制御メッセージフレームの種類を示す図である。
【図９】本発明の第１の実施の形態による動作を説明するシーケンス図である。
【図１０】本発明の第１の実施の形態によるＱｕｅｒｙ１メッセージの転送経路及び処理を示す図である。
【図１１】本発明の第１の実施の形態によるＲｅｐｒｏｔ１メッセージの転送経路及び処理を示す図である。
【図１２】本発明の第１の実施の形態によるノード２００−１から送信されたマルチキャストフレームの転送方法を示す図である。
【図１３】本発明の第１の実施の形態による拡張タグネットワークからカスタマが削除されることを示す図である。
【図１４】本発明の第２の実施の形態による制御メッセージフレームの種類を示す図である。
【図１５】本発明の第２の実施の形態による動作を説明するためのシーケンス図である。
【図１６】本発明の第２の実施の形態によるＱｕｅｒｙ１メッセージの転送経路及び処理を示す図である。
【図１７】本発明の第２の実施の形態によるＲｅｐｒｏｔ１メッセージの転送経路及び処理を示す図である。
【図１８】本発明の第２の実施の形態によるＱｕｅｒｙ２メッセージの転送経路及び処理を示す図である。
【図１９】本発明の第２の実施の形態によるＲｅｐｒｏｔ２メッセージの転送経路及び処理を示す図である。
【図２０】本発明の第２の実施の形態によるノード２００−１から送信されたマルチキャストフレームの転送方法を示す図である。
【図２１】本発明の第２の実施の形態によるノード２００−５から送信されたマルチキャストフレームの転送方法を示す図である。
【図２２】本発明の第３の実施の形態によるマルチキャストテーブルの構成例を示す図である。
【図２３】本発明の第３の実施の形態による拡張タグネットワークにカスタマが追加されることを示す図である。
【図２４】本発明の第３の実施の形態による動作を説明するためのシーケンス図である。
【図２５】本発明の第３の実施の形態によるノード２００−４がルートノードになる拡張タグネットワークで、Ｑｕｅｒｙ１メッセージの転送経路及び処理を示す図である。
【図２６】本発明の第３の実施の形態によるノード２００−４がルートノードになる拡張タグネットワークで、Ｒｅｐｒｏｔ１メッセージの転送経路及び処理を示す図である。
【図２７】本発明の第３の実施の形態によるノード２００−１がルートノードになる拡張タグネットワークで、Ｑｕｅｒｙ２メッセージの転送経路及び処理を示す図である。
【図２８】本発明の第３の実施の形態によるノード２００−１がルートノードになる拡張タグネットワークで、Ｒｅｐｒｏｔ２メッセージの転送経路及び処理を示す図である。
【図２９】本発明の第３の実施の形態によるノード２００−５がルートノードになる拡張タグネットワークで、Ｑｕｅｒｙ２メッセージの転送経路及び処理を示す図である。
【図３０】本発明の第３の実施の形態によるノード２００−５がルートノードになる拡張タグネットワークで、Ｒｅｐｒｏｔ２メッセージの転送経路及び処理を示す図である。
【図３１】本発明の第３の実施の形態によるノード２００−４から送信されたマルチキャストフレームの転送方法を示す図である。
【図３２】本発明の第３の実施の形態によるノード２００−１から送信されたマルチキャストフレームの転送方法を示す図である。
【図３３】本発明の第３の実施の形態によるノード２００−５から送信されたマルチキャストフレームの転送方法を示す図である。
【図３４】本発明の第３の実施の形態による拡張タグネットワークからカスタマが削除されることを示す図である。
【図３５】本発明の第４の実施の形態によるＱｕｅｒｙ１メッセージ受信テーブルの構成例を示す図である。
【図３６】本発明の第５の実施の形態による制御メッセージフレームの構成例を示す図である。
【図３７】本発明の第５の実施の形態によるＱｕｅｒｙ１メッセージの転送経路及び処理を示す図である。
【図３８】本発明の第５の実施の形態によるＲｅｐｒｏｔ１メッセージの転送経路及び処理を示す図である。
【図３９】本発明の第５の実施の形態によるＱｕｅｒｙ２メッセージの転送経路及び処理を示す図である。
【図４０】本発明の第５の実施の形態によるＲｅｐｒｏｔ２メッセージの転送経路及び処理を示す図である。
【図４１】本発明の第６の実施の形態によるノード２００−５がルートポート側のリンク障害を検出した際に、マルチキャストフレームの転送経路及びマルチキャストテーブル状態を示す図である。
【図４２】本発明の第６の実施の形態によるノード２００−５がルートポート側のリンク障害を検出した際に、トポロジー変更によって生成された新しいスパニングツリーを示す図である。
【図４３】本発明の第６の実施の形態によるノード２００−５がルートポート側のリンク障害を検出した際に、クリアされたマルチキャストテーブルとマルチキャストフレームの転送経路を示す図である。
【図４４】本発明の第６の実施の形態によるＱｕｅｒｙ２再送信要求メッセージ４８００のフレーム構成例を示す図である。
【図４５】本発明の第６の実施の形態によるＱｕｅｒｙ２再送信要求メッセージ４８００に関する処理のシーケンスを示す図である。
【図４６】本発明の第６の実施の形態によるリンク障害回復が完了した際のマルチキャストフレームの転送経路を示す図である。
【図４７】本発明の第１の実施の形態によるエッジノードに自ノードが収容するカスタマ情報が登録されてない際に、配下のホストに対して送受信する問い合わせメッセージとホストから受信する回答メッセージの送受信状況を示す図である。
【図４８】本発明の第１の実施の形態によるエッジノードに自ノードが収容するカスタマ情報が登録されてない際に、配下のホストに対して問い合わせする処理の流れを示す図である。
【図４９】本発明の第１の実施の形態によるエッジノードに自ノードが収容するカスタマ情報が登録されてない際に、配下のホストに対して問い合わせした結果によってルートノードに送信するＲｅｐｏｒｔメッセージの送信状況を示す図である。
【図５０】従来のイーサネット（R）フレームの構成例を示す図である。
【図５１】拡張タグ付きイーサネット（R）フレームの構成例を示す図である。
【図５２】拡張タグ付きイーサネット（R）フレームの他の構成例を示す図である。
【図５３】拡張タグ格納領域の構成例を示す図である。
【図５４】従来のマルチキャスト転送方法を示す図である。
【図５５】従来のマルチキャスト転送方法を示す図である。
【符号の説明】
【０４６６】
１００、２００：ノード
１００−１、１００−２、１００−３、１００−４、１００−５、１００−６、１００−７：ノード
２００−１、２００−２、２００−３、２００−４、２００−５、２００−６、２００−７：ノード
２１０−ｉｎ、２２０−ｉｎ：入力ポート
２１０−out、２２０−out：出力ポート
２０１１：フレーム解析部
２０１２：タグ挿入部
２０１３：タグスイッチ部
２１０１：スイッチ部
２１０２：テーブル検索部
２１０３：テーブル制御部
２０１４：タグ削除部
２０１５：ＭＡＣラーニング部
２０１６：カスタマ管理モジュール
２０１７：カスタマ識別テーブル
２０１８：フォワーディングテーブル格納部
２２０１：フォワーディングテーブル内のMACテーブル
２２０２：フォワーディングテーブル内のアドレス解決テーブル
２２０３：フォワーディングテーブル内の拡張タグFWテーブル
２２１１：ブロードキャストテーブル
２２１２：ユニキャストテーブル
２０１９： STP制御部
２０２０：マルチキャスト制御部
２０２１：マルチキャストテーブル
２２００、２３００：拡張タグ付きイーサネット（Ｒ）フレームを転送するネットワーク
２０１７−１、２０１７−５：カスタマ識別テーブル
２２０１−１、２２０１−２、２２０１−４、２２０１−５：拡張タグ付きFWテーブル（ブロードキャストテーブル）
２２１２−１、２２１２−２、２２１２−４、２２１２−５：拡張タグタグ付きFWテーブル（ユニキャストテーブル）
２０２１−１、２０２１−２、２０２１−５：マルチキャストテーブル
２０２１Ａ、２０２１Ａ−１、２０２１Ａ−２、２０２１Ａ−４、２０２１Ａ−５：マルチキャストテーブル
３８００：Ｑｕｅｒｙメッセージ受信テーブル
４２００：イーサネット（R）フレーム
４３００：拡張タグ付きイーサネット（R）フレーム
４４００：拡張タグ付きイーサネット（R）フレーム
４６００、４８００：制御メッセージ
４７０１：Ｑｕｅｒｙ１メッセージ
４７０２：Ｒｅｐｏｒｔ１メッセージ
４７０３：Ｑｕｅｒｙ２メッセージ
４７０４：Ｒｅｐｏｒｔ２メッセージ
４８０１：Ｑｕｅｒｙ１メッセージ
４８０２：Ｒｅｐｏｒｔ１メッセージ
４２０３：VLANタグ
４３０１：拡張タグ格納領域
４５００、４５０１、４５０２、４５０３、４５０４、４５０５、４５０６、４５０７、４５０８：拡張タグ
４６０１：制御メッセージの特殊宛先MACアドレス格納領域
４８００：Ｑｕｅｒｙ２メッセージのフレームフォーマット
４９００：制御メッセージの属性情報
４９０１：Ｆｒａｍｅ
４９０２：制御メッセージのタイプ
４９０３：制御メッセージのカスタマ情報
４９０４、４９０５、４９０６：制御メッセージのカスタマ情報
４９０７：Ｑｕｅｒｙ２メッセージ領域
５０００：ＢＰＤＵフレームフォーマット
５１００：ＢＰＤＵパラメータ領域
【図１】
2006246264.tif 000002
【図２】
2006246264.tif 000003
【図３】
2006246264.tif 000004
【図４】
2006246264.tif 000005
【図５】
2006246264.tif 000006
【図６】
2006246264.tif 000007
【図７】
2006246264.tif 000008
【図８】
2006246264.tif 000009
【図９】
2006246264.tif 000010
【図１０】
2006246264.tif 000011
【図１１】
2006246264.tif 000012
【図１２】
2006246264.tif 000013
【図１３】
2006246264.tif 000014
【図１４】
2006246264.tif 000015
【図１５】
2006246264.tif 000016
【図１６】
2006246264.tif 000017
【図１７】
2006246264.tif 000018
【図１８】
2006246264.tif 000019
【図１９】
2006246264.tif 000020
【図２０】
2006246264.tif 000021
【図２１】
2006246264.tif 000022
【図２２】
2006246264.tif 000023
【図２３】
2006246264.tif 000024
【図２４】
2006246264.tif 000025
【図２５】
2006246264.tif 000026
【図２６】
2006246264.tif 000027
【図２７】
2006246264.tif 000028
【図２８】
2006246264.tif 000029
【図２９】
2006246264.tif 000030
【図３０】
2006246264.tif 000031
【図３１】
2006246264.tif 000032
【図３２】
2006246264.tif 000033
【図３３】
2006246264.tif 000034
【図３４】
2006246264.tif 000035
【図３５】
2006246264.tif 000036
【図３６】
2006246264.tif 000037
【図３７】
2006246264.tif 000038
【図３８】
2006246264.tif 000039
【図３９】
2006246264.tif 000040
【図４０】
2006246264.tif 000041
【図４１】
2006246264.tif 000042
【図４２】
2006246264.tif 000043
【図４３】
2006246264.tif 000044
【図４４】
2006246264.tif 000045
【図４５】
2006246264.tif 000046
【図４６】
2006246264.tif 000047
【図４７】
2006246264.tif 000048
【図４８】
2006246264.tif 000049
【図４９】
2006246264.tif 000050
【図５０】
2006246264.tif 000051
【図５１】
2006246264.tif 000052
【図５２】
2006246264.tif 000053
【図５３】
2006246264.tif 000054
【図５４】
2006246264.tif 000055
【図５５】
2006246264.tif 000056