JP5572052B2 - マルチキャスト配信システム、配信ルータ、および、マルチキャスト配信方法 - Google Patents

Description

本発明は、マルチキャスト配信システム、配信ルータ、および、マルチキャスト配信方法に関する。

ＩＰ（Internet Protocol）ルータとＩＰホスト区間のＩＰマルチキャストの配信制御を行うプロトコルとして、ＩＰｖ４（Internet Protocol version 4）を利用する場合のＩＧＭＰ（Internet Group Management Protocol）や、ＩＰｖ６（Internet Protocol version 6）を利用する場合のＭＬＤ（Multicast Listener Discovery）が存在する。

また、ＩＰマルチキャストの配信制御の中でも、ＩＰマルチキャストの配信フローの送信元ＩＰアドレス（以下、Sourceを示す「Ｓアドレス」）と、宛先ＩＰアドレス（以下、Groupを示す「Ｇアドレス」）と、の両方（以下、（Ｓ，Ｇ））を指定して制御を行うＳＳＭ（Source-Specific Multicast）方式に対応したプロトコルとして、非特許文献１が示すＩＧＭＰｖ３（ＩＰｖ４）や、非特許文献２が示すＭＬＤｖ２（ＩＰｖ６）が存在する。

ＩＧＭＰｖ３／ＭＬＤｖ２では、ホストからフローの（Ｓ，Ｇ）アドレスと配信状態（join/leave）を示すレポートメッセージを送信し、ルータが本レポートメッセージを受信する度に当該フローの配信を開始（join）／停止（leave）するのが配信制御における基本的な動作となる。

ＩＰルータがＩＧＭＰ／ＭＬＤプロトコルを用いてＩＰマルチキャストの配信制御を行うにあたり、同じ１つの共有セグメントに複数ルータが冗長接続されることもある。共有セグメントに複数のルータが存在する場合、全てのルータがレポートメッセージを受信することになるため、各ルータが独立して自律的に配信制御を行うと、同一フローを重複して配信する状況に陥る。これは、配信系の帯域利用効率を低下させ、一度に配信可能なフロー種別（（Ｓ，Ｇ））の数が減少する点や、同一パケットを重複受信するホスト処理に悪影響を及ぼす可能性がある点が懸念される。

このような懸念を回避するため、ＩＧＭＰｖ３／ＭＬＤｖ２には、クエリア選択メカニズム（Querier election mechanism）が備わっている。すなわち、共有セグメントに複数のルータが存在する場合、その中の１台を代表ルータ（以下、クエリアと呼ぶ）として選択し、クエリアだけがＧＱ（General Query、以下適宜クエリと略す）の送信制御やホストから受信するＩＧＭＰ／ＭＬＤレポートの応答処理、マルチキャストフローの配信制御を行う。

クエリア選択方法としては、例えば、各ルータが他ルータから受信するクエリパケットの送信元ＩＰアドレスと自ＩＰアドレスを大小比較し、自アドレスの方が小さいルータは配信制御を継続する。逆に、自アドレスの方が大きいルータは配信制御を停止する。この判定動作を反復することにより、最終的にはアドレス最小となる１台のルータだけが配信制御を行う状態に収束する。

ＩＥＴＦ、"Internet Group Management Protocol, Version 3"、［online］、［平成２２年５月３１日検索］、インターネット（ＵＲＬ：http://www.rfc-editor.org/rfc/rfc3376.txt） ＩＥＴＦ、"Multicast Listener Discovery Version 2 (MLDv2) for IPv6"、［online］、［平成２２年５月３１日検索］、インターネット（ＵＲＬ：http://www.rfc-editor.org/rfc/rfc3810.txt）

しかし、共有セグメントに接続される複数のルータから、１台のクエリアを選択する手法では、そのクエリアに障害が発生したときに、マルチキャストのフロー配信が不安定になってしまう。
ここで、不安定とは、複数のルータから同一フローが二重配信されたり、フローの配信漏れが生じた状態を指す。
不安定の要因は、例えば、障害が発生したクエリアの代替となるクエリアが一時的に複数台決定されると、その複数台の代替クエリアからフローの重複配信が行われることである。
別の要因としては、例えば、障害が発生したクエリアの代替となるクエリアが選択されない期間には、フロー配信が途切れてしまうことである。

そこで、本発明は、共有セグメントに複数のマルチキャスト配信ルータが接続される構成において、クエリアの障害時にも安定したフロー配信を継続しつつ、障害フローの救済復旧を実現することを、主な目的とする。

前記課題を解決するために、本発明は、配信サーバから配信ルータを介してホストにマルチキャストのフローを配信するマルチキャスト配信システムであって、複数台の前記配信ルータと１台以上の前記ホストとが共有セグメントに接続され、その共有セグメントに送信されるパケットが、前記共有セグメントに接続される各装置が受信可能であり、前記配信ルータが、転送制御部と記憶手段とを有しており、前記配信ルータの記憶手段には、正常制御用データと障害制御用データとが記憶されており、前記正常制御用データが、前記共有セグメントを介して配信される１つのフローごとに１台の前記配信ルータを配信担当ルータとして割り当てるデータであり、前記障害制御用データが、前記１台以上の配信担当ルータを障害ルータとしたときに、前記障害ルータに割り当てられていた障害フローに対して、前記障害ルータとは別の前記配信ルータを、配信代行ルータとして割り当てるデータであり、前記共有セグメントに接続される各前記配信ルータの転送制御部が、前記障害ルータとして他装置の前記配信ルータを検出した後、前記配信サーバからフローの配信データを受信すると、受信した配信データの属するフローの特定情報を検索キーとして、前記正常制御用データと前記障害制御用データとをそれぞれ検索することで、検索したフローの前記配信担当ルータおよび前記配信代行ルータをそれぞれ取得し、取得した前記正常制御用データから検索される前記配信担当ルータまたは前記検出した障害ルータが配信していた前記障害フローに対する前記配信代行ルータが自装置であるときには、前記共有セグメントを介して受信したフローの配信データを前記ホストに転送し、取得した前記正常制御用データから検索される前記配信担当ルータおよび前記検出した障害ルータが配信していた前記障害フローに対する前記配信代行ルータが他装置であるときには、受信したフローの配信データを廃棄することを特徴とする。
さらに、本発明は、前記マルチキャスト配信システムに用いられる配信ルータ、および、前記マルチキャスト配信システムが実行するマルチキャスト配信方法である。

これにより、配信担当ルータの障害時には、配信代行ルータがフローの配信を円滑に代行することで、共有セグメントに複数のマルチキャスト配信ルータが接続される構成において、配信担当ルータの障害時にも安定したフロー配信を実現することができる。

本発明は、前記共有セグメントに接続される各前記配信ルータの転送制御部が、前記正常制御用データを前記記憶手段に格納するときに、受信した配信データの属するフローの特定情報と、前記共有セグメントに接続される前記配信ルータの数と、を引数とする所定関数を計算し、その所定関数の計算結果から一意に決定される前記配信ルータを、前記所定関数の計算に用いたフローに対する配信担当ルータとして決定し、前記障害制御用データを前記記憶手段に格納するときに、前記１台以上の配信ルータから選択した前記１台以上の障害ルータの組み合わせごとに、受信した配信データの属するフローの特定情報と、前記共有セグメントに接続される前記配信ルータの数から前記障害ルータの数を減じたルータの数と、を引数とする前記所定関数を計算し、その所定関数の計算結果から一意に決定される前記配信ルータを、前記所定関数の計算に用いたフローに対する配信代行ルータとして決定することを特徴とする。

これにより、障害ルータの組み合わせに応じて、配信担当ルータおよび配信代行ルータそれぞれが計算されるので、共有セグメントの配信ルータの構成を柔軟に設計することができる。

本発明によれば、共有セグメントに複数のマルチキャスト配信ルータが接続される構成において、クエリアの障害時にも安定したフロー配信を継続しつつ、障害フローの救済復旧を実現することができる。

本発明の一実施形態に関するマルチキャスト配信システムを示す構成図である。 本発明の一実施形態に関するマルチキャスト配信システムの処理概要（１台障害）を示す説明図である。 本発明の一実施形態に関するマルチキャスト配信システムの処理概要（２台障害）を示す説明図である。 本発明の一実施形態に関する配信ルータを示す構成図である。 本発明の一実施形態に関するフロー配信処理を示すフローチャートである。 本発明の一実施形態に関する障害制御テーブルの生成処理を示すフローチャートである。 本発明の一実施形態に関するルータ障害が発生した際における配信障害の復旧処理を示すフローチャートである。 本発明の一実施形態に関するルータ障害からの配信切替え後に配信要求を受信した際において、配信制御テーブルの更新処理を示すフローチャートである。 本発明の一実施形態に関するルータ障害からの配信切替え後に配信要求を受信した際において、要求に対するフロー配信処理を示すフローチャートである。

以下、本発明の一実施形態について、図面を参照して詳細に説明する。

図１は、マルチキャスト配信システムを示す構成図である。マルチキャストフロー（以下、単にフローとする）は、配信サーバ１から送信されて、マルチキャスト配信網２、リンク３、各配信ルータ４（Ｒ１，Ｒ２，Ｒ３）、共有セグメント５を経由して、ホスト６に配信される。
これらのマルチキャスト配信システムの各装置は、ＣＰＵとメモリとハードディスク（記憶手段）とネットワークインタフェースを有するコンピュータとして構成され、このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラムを実行することにより、各処理部を動作させる。

マルチキャスト配信網２は、例えば、インターネット網であり、配信サーバ１から配信ルータ４への経路決定のためのプロトコルとして、ＤＶＭＲＰ（Distance Vector Multicast Routing Protocol）や、ＰＩＭ−ＳＭ（Protocol Independent Multicast - Sparse Mode）、ＰＩＭ−ＳＳＭ（Protocol Independent Multicast - Source Specific Mode）などが動作することを想定する。
共有セグメント５は、その共有セグメント５に接続される装置から送信されるパケットが、そのパケットの送信先だけでなく、同じ共有セグメント５に接続される他装置へも伝送される特性を有する。例えば、配信ルータ４（Ｒ１）からホスト６へ送信されるメッセージは、ホスト６だけでなく、他の各配信ルータ４（Ｒ２，Ｒ３）も受信することができる。共有セグメント５は、例えば、イーサネット（登録商標）のＬＡＮ（Local Area Network）やアクセス集線スイッチ内のＶＬＡＮ（Virtual LAN）、スイッチ間を跨いだネットワークＶＬＡＮ(IEEE802.1adやIEEE802.1ahによるタグVLAN)等により構成される。

配信サーバ１は、フローの配信元となるサーバである。なお、フローの特定情報としては、フローのグループだけを特定情報とする（＊，ｇ）指定型であるＡＳＭ（Any Source Multicast）と、フローのグループとフローの送信元の配信サーバ１のアドレスの組を特定情報とする（ｓ，ｇ）指定型であるＳＳＭとが挙げられる。
以下、本実施形態では、フローの特定情報を（ｓ，ｇ）指定型として説明するが、（＊，ｇ）指定型にも本実施形態を応用することができる。ここで、（ｓ，ｇ）とは、（Source，Group）の略であり、最初のSourceが送信元の配信サーバ１のアドレスを示し、次のGroupがフローのグループを示す。

配信ルータ４は、マルチキャストのグループ管理プロトコル（ＩＧＭＰおよびＭＬＤのプロトコルなど）が動作するルータであり、配信サーバ１からの配信データを、ホスト６に転送する。配信ルータ４は、リンク３を介して、マルチキャスト配信網２と接続されている。
ホスト６は、配信ルータ４から配信データを受信する端末であり、リスナ（listener）とも呼ばれる。ホスト６は、配信ルータ４からのクエリを受信すると、自装置が希望するフローの情報を含めたリポートを作成し、配信ルータ４に返信する。

以下、図２，図３を参照して、図１のマルチキャスト配信システムの処理概要を説明する。なお、各処理や各処理で使用されるデータ構造の詳細は、図４以降で説明する。図２，図３では、ルータ障害時における障害フローの救済方法を説明している。
・図２（ａ）は、３台の配信ルータ４（Ｒ１，Ｒ２，Ｒ３）が全て正常動作している状態である。
・図２（ｂ）は、２台の配信ルータ４（Ｒ２，Ｒ３）が正常動作し、１台の配信ルータ４（Ｒ１）に障害が発生している状態である。
・図３は、１台の配信ルータ４（Ｒ２）が正常動作し、２台の配信ルータ４（Ｒ１，Ｒ３）に障害が発生している状態（二重障害）である。

図２（ａ）では、共有セグメント５内に３台の配信ルータ４が、４つのフロー（Ｆ１〜Ｆ４）をそれぞれ配信している。ここで、各配信ルータ４内の記憶手段には、４つのフローそれぞれについて、自ルータが配信担当か否かを特定する情報が格納されており、その特定情報をもとに、それぞれ配信するフローを重複や漏れがないように、分担して配信する。例えば、配信ルータ４（Ｒ１）は、２つのフロー（Ｆ１，Ｆ４）の配信を担当する。
これにより、共有セグメント５内の配信ルータ４のうち、１台の配信ルータ４だけをクエリアとして用いる従来のＩＧＭＰ／ＭＬＤ方式に比べ、フロー単位での負荷分散が実現でき、スループットを向上させることができる。

図２（ｂ）は、配信ルータ４（Ｒ１）に障害が発生したときの障害フローの救済方法を示す。配信ルータ４（Ｒ１）の障害により、配信ルータ４（Ｒ１）が担当していた障害フローＦ１，Ｆ４を、配信ルータ４（Ｒ１）が配信することが困難な状況にある。
このとき、他の配信ルータ４（Ｒ２，Ｒ３）は、図２（ａ）で自ルータが配信担当であるフローＦ３，Ｆ２の配信を継続しつつ、障害フローＦ１，Ｆ４の配信を配信ルータ４（Ｒ１）からそれぞれ代行して配信する。
ここで、各配信ルータ４内の記憶手段には、共有セグメント５内の各配信ルータ４のうちの障害が発生した配信ルータ４の組み合わせに応じて、その障害が発生した配信ルータ４が配信担当であったフローの代行担当を特定する情報が格納されており、その特定情報をもとに、それぞれ代行配信するフローを重複や漏れがないように、分担して配信する。
これにより、障害が発生したときでも、各配信ルータ４が代行配信を分担することで、フロー単位での負荷分散が実現でき、スループットを向上させることができる。
さらに、正常な配信ルータ４（Ｒ２，Ｒ３）がフローＦ１，Ｆ４を代行配信する契機を、配信ルータ４（Ｒ１）の障害を検知したこととすることで、フローＦ１，Ｆ４の通信切断を抑制することができる。

図３は、二重障害の例として、配信ルータ４（Ｒ１、Ｒ３）が故障した場合を示す。この場合は、唯一正常である配信ルータ４（Ｒ２）が、４つのフロー（Ｆ１〜Ｆ４）の配信を担当する。
ここで、配信ルータ４（Ｒ２）内の記憶手段には、２台の配信ルータ４（Ｒ１，Ｒ３）に障害が発生したときに、その障害が発生した配信ルータ４が配信担当であったフローの代行担当を特定する情報が格納されており、その特定情報をもとに、フローＦ１，Ｆ２，Ｆ４を代行配信する。

図４は、配信ルータ４を示す構成図である。
配信ルータ４は、フローの上流側（マルチキャスト配信網２の側）から順に、ＭＣ配信網接続インタフェース４１、ＭＣ配信網フレーム転送部４２、転送制御回路４３、共有セグメントフレーム転送部４４、共有セグメント接続インタフェース４５が接続されて構成される。

インタフェース（ＭＣ配信網接続インタフェース４１、共有セグメント接続インタフェース４５）は、ネットワークが接続される端点となる箇所であり、外部の網からデータを受信するインタフェース（受信ＩＦ部４１１，４５２）と、外部の網にデータを送信するインタフェース（送信ＩＦ部４５１，４１２）とから構成される。
フレーム転送部（ＭＣ配信網フレーム転送部４２、共有セグメントフレーム転送部４４）は、インタフェースが送受信するデータの信号をフレーム単位に変換する処理部であり、受信インタフェースからの通信信号からフレームを構築する受信部（フレーム受信部４４２，４２１）と、構築されたフレームから送信インタフェースを介して送信する通信信号へとデコードする送信部（フレーム送信部４４１，４２２）とから構成される。

上流（配信サーバ１）から下流（ホスト６）に流れる下りのパケット（マルチキャストフローなど）は、受信ＩＦ部４１１→フレーム受信部４２１→配信フィルタ部４３１→フレーム送信部４４１→送信ＩＦ部４５１の順に、配信ルータ４内を通過する。
下流（ホスト６）から上流（配信サーバ１）に流れる上りのパケット（配信要求（join/leave）など）は、受信ＩＦ部４５２→フレーム受信部４４２→配信管理部４３７→上位連携部４３９→フレーム送信部４２２→送信ＩＦ部４１２の順に、配信ルータ４内を通過する。

転送制御回路４３は、受信部からのフレームを受信して、そのフレーム内容に応じて転送制御を行い、その結果を送信部に出力する。
例えば、転送制御回路４３は、フレーム受信部４２１を介してマルチキャストパケットを受信すると、自ルータが配信制御を行うフローかを判定し、自ルータが配信するフローの場合、フレーム送信部４４１に当該マルチキャストフローを転送する。一方、転送制御回路４３は、共有セグメント内の他の配信ルータ４が配信制御を行うフローの場合、当該マルチキャストパケットを廃棄する。
なお、転送制御回路４３は、自ルータが配信するストリームの配信契機を、フレーム受信部４４２を介してホストから配信要求（join/leaveレポート）を受信したときとする。

転送制御回路４３は、配信フィルタ部４３１、フロー判定部４３２、配信制御テーブル４３３（正常制御テーブル４３３ａ、障害制御テーブル４３３ｂ）、ルータ管理部４３４、ルータ管理テーブル４３５、配信障害検出部４３６、配信管理部４３７、配信フィルタリスト４３８、上位連携部４３９から構成される。以下、転送制御回路４３の各構成要素について、詳細に説明する。

配信フィルタ部４３１は、マルチキャストパケットの透過／廃棄を実行する。つまり、配信フィルタ部４３１がパケットを受信すると、フロー判定部４３２に対してパケットの透過／廃棄の判定結果を問い合わせ、他のルータが配信制御を行うパケットであれば廃棄する。
一方、自ルータが配信制御を行うパケットであれば、当該フローが配信中の状態かを配信管理部４３７に問い合わせ、配信中状態であれば、パケットを透過処理して共有セグメントフレーム転送部４４のフレーム送信部４４１へ転送する。

フロー判定部４３２は、フレーム受信部４２１から受信したマルチキャストパケットについて、配信制御テーブル４３３を参照することにより、パケットの転送（透過）または廃棄を決定する。
例えば、フロー判定部４３２は、配信制御テーブル４３３内の正常制御テーブル４３３ａを参照して、共有セグメント５内の全配信ルータ４が正常な状態におけるフローの配信制御を実行するか否かを判定する。
フロー判定部４３２は、ルータ管理部４３４から共有セグメント５におけるルータ総数およびルータ順位を情報取得し、受信パケットの情報（（Ｓ，Ｇ）アドレス）との組み合わせにより、自ルータが制御するフローを識別し、共有セグメント５内の配信ルータ４間における同一フローの二重配信およびルータ間の配信漏れを抑止する。

配信障害検出部４３６は、共有セグメント５内の他の配信ルータ４の状態を管理する。例えば、共有セグメント５などの外部から障害発生および障害ルータの情報の通知を受信し、これを配信管理部４３７へと通知するとともに、これらの障害情報を内部管理する。また、障害回復時の切戻し制御に備えて、ルータ障害の回復情報も併せて管理する。

配信管理部４３７は、ＩＧＭＰ／ＭＬＤを実行することにより、自ルータをＩＧＭＰ／ＭＬＤルータとして動作させ、ホスト６側から送信される配信要求（join/leaveレポート）を処理し、共有セグメント接続インタフェース４５に対するフローごとの配信状態を配信フィルタリスト４３８として管理する。
なお、配信フィルタリスト４３８は、フローごとにそのフローをホスト６に配信するか否かを示す配信状態を対応づけたデータ構造である。
配信管理部４３７は、配信フィルタリスト４３８を参照して、フレーム受信部４２１からのパケットの転送または廃棄を決定する。
上位連携部４３９は、例えば、ＰＩＭ−ＳＳＭ等のマルチキャストルーティングプロトコルを動作させることにより、配信管理部４３７から受信した配信要求を、上流側へと送信して、マルチキャスト配信網２の配信制御と連携動作する。

配信管理部４３７は、ルータ障害時におけるフロー配信制御を行う。すなわち、共有セグメント５内の各配信ルータ４が故障した状況に備え、障害パタン毎の配信フロー割当てを手動設定もしくは自動計算する。なお、本処理は障害前もしくは障害後に実行することが可能であるが、障害前に実施することにより高速な切替えを実現することが可能となる。

配信管理部４３７は、配信フローの割当てを、障害ルータに割当てられているフローに限定する。すなわち、正常ルータでは、フロー判定部４３２で正常系において自ルータに割り付けられるフローを配信するともに、配信管理部４３７で障害系において自ルータへ割り付けられるフローの配信を障害ルータから引き継ぐ。
これにより、系切替え制御に伴う正常フローの配信中断を伴うことなく、障害フローを救済することが可能となる。

ルータ管理部４３４は、共有セグメント５に接続される各配信ルータ４（自ルータおよび他ルータ）のエントリをルータ管理テーブル４３５に記憶する。さらに、フロー判定部４３２は、ルータ管理テーブル４３５に格納される配信ルータ４の情報と、配信フィルタリスト４３８に格納されるフローの情報とから、配信ルータ４ごとの配信担当となるフローを特定するための配信制御テーブル４３３を作成する。

表１は、ルータ管理部４３４が生成および管理するルータ管理テーブル４３５の一例を示す。この例では、３台の配信ルータ４（Ｒ１，Ｒ２，Ｒ３）が登録されている。ルータ管理テーブル４３５は、共有セグメント５内の配信ルータ４の障害状況（障害発生した配信ルータ４の組み合わせ）ごとに、共有セグメント５内の各配信ルータ４の順位を対応づけて記憶する。この順位は、後記するように、配信制御テーブル４３３の作成に使用される（表２参照）。

ルータ管理部４３４は、ルータ管理テーブル４３５の各配信ルータ４の順位を決定するためのルータアドレス（例えば、アドレスの小さい順に順位を決定する）として、自ルータのＩＰアドレスと、他ルータから受信したパケットから特定できる他ルータのＩＰアドレスとを参照する。他ルータのＩＰアドレスは、例えば、ＩＧＭＰおよびＭＬＤにおける他ルータから共有セグメント５に定期的に送信されるＧＱ（General Query）メッセージなどのクエリの送信元アドレスである。
なお、ルータエントリの登録用のメッセージは、送信元ルータのＩＰアドレスを検出可能であれば、ＧＱだけに限定されず、任意のメッセージを用いてもよい。
・ＩＰｖ４マルチキャストの場合は、ＧＱとＧＳＱ（Group-Specific Query）とＧＳＳＱ（Group-and-Source-Specific Query）の３種類のクエリが規定されている。
・ＩＰｖ６マルチキャストの場合は、ＧＱとＭＡＳＱ（Multicast Address Specific Query）とＭＡＳＳＱ（Multicast Address and Source Specific Query）の３種類のクエリが規定されている。
・マルチキャスト以外のメッセージを用いる場合は、ｐｉｎｇ（ＩＣＭＰ）パケットや独自パケットなど。

ルータ管理部４３４は、３台の配信ルータ４（Ｒ１，Ｒ２，Ｒ３）のルータアドレスの小さい順が「Ｒ３，Ｒ２，Ｒ１」であるときに、障害ルータを除外した配信ルータ４の集合に対して、ルータアドレスの小さい順に順位を割り当てる。例えば、障害ルータがないときには、配信ルータ４（Ｒ２）は配信ルータ４（Ｒ３）の次の順位（２位）であるが（表の１行目）、配信ルータ４（Ｒ３）に障害が発生したときには、繰り上がって１位となる（表の２行目）。

表２は、配信制御テーブル４３３（正常制御テーブル４３３ａ、障害制御テーブル４３３ｂ）を示す。
配信制御テーブル４３３は、正常制御テーブル４３３ａと障害制御テーブル４３３ｂとから構成されており、その２つのテーブルを１つに統合した形式が、表２の一番上の配信制御テーブル４３３である。つまり、配信制御テーブル４３３の左側の列（フロー，Ｓ，Ｇ，Ｓ＋Ｇ）は、正常制御テーブル４３３ａと障害制御テーブル４３３ｂとで共通し、配信制御テーブル４３３の右側の列「正常時」から正常制御テーブル４３３ａを生成するとともに、配信制御テーブル４３３の右側の列「１台障害」から障害制御テーブル４３３ｂを生成することができる（データベースの表分離演算）。
配信制御テーブル４３３の左側の列（フロー，Ｓ，Ｇ，Ｓ＋Ｇ）について、フロー列、Ｓ列、Ｇ列は、フローの特定情報が（Ｓ，Ｇ）であることを示している。「Ｓ＋Ｇ」列は、ハッシュ値Ｍｏｄの計算用パラメータの一例であり、ＳとＧとの和である。

正常制御テーブル４３３ａには、共有セグメント５内の全配信ルータ４が正常な状態における、フローごとの配信ルータ割当ての情報が格納されており、必要に応じてフロー判定部４３２を介して読み出される。
正常制御テーブル４３３ａの「正常時」列は、ハッシュ値を示すＭｏｄ３と、そのハッシュ値からフローの配信担当として決定された配信ルータ４の識別子（Ｒ１〜Ｒ３）とが対応づけられている。Ｍｏｄ３とは、「Ｓ＋Ｇ」列の値を、ルータ数（３）で除算した余り（mod演算）である。
例えば、正常制御テーブル４３３ａの１行目（フローＦ１）は、「Ｓ＋Ｇ」列「３」÷全ルータ数「３」＝商が１で余りが０なので、「Ｍｏｄ３」列が「０」である。
そして、表１のルータ管理テーブル４３５の１行目（３台正常時）の配信ルータごとの順位では、Ｒ３（１位）→Ｒ２（２位）→Ｒ３（３位）となっている。ここで、「Ｍｏｄ３」列からルータ順位への変換処理は、「Ｍｏｄ３」列が０でないときには、「Ｍｏｄ３」列の値をそのままルータ順位とし、「Ｍｏｄ３」列が０であるときには、ルータ順位が最下位のルータ順位とする。よって、「Ｍｏｄ３」列が「０」から、ルータ順位が最下位のルータ「Ｒ１」へと変換され、正常制御テーブル４３３ａのＲ（配信担当）列として、「Ｒ１」が書き込まれる。

以上説明したように、フロー情報（Ｓ，Ｇ）からハッシュ値（mod[(S+G)，ルータ数]）を計算し、ハッシュ値とクエリア順位とを１：１に対応させ、クエリア順位から配信ルータ４の識別子（Ｒ１〜Ｒ３）へ変換することにより、フローごとの配信担当を決定する。
これにより、共有セグメント内に複数のフローが配信されるときに、そのフローごとの配信担当となるクエリアが負荷分散されるので、フローの配信漏れや重複配信を抑制しつつ、共有セグメント全体のフローのスループットを向上させることができる。

障害制御テーブル４３３ｂには、共有セグメント５内の全配信ルータ４のうちの１台以上の配信ルータ４が障害状態における、フローごとの配信ルータ割当ての情報が格納されており、必要に応じて配信管理部４３７を介して読み出される。
障害制御テーブル４３３ｂの「１台障害」列の作成方法は、正常制御テーブル４３３ａの「正常時」列の作成方法と、以下の違いがある。
・正常制御テーブル４３３ａの配信担当を示す「Ｒ」列を、障害制御テーブル４３３ｂでは、障害が発生した配信ルータ４（Ｒ１に障害が発生したとき、Ｒ３に障害が発生したとき）ごとにする。
・正常制御テーブル４３３ａのハッシュ値「Ｍｏｄ３」を、障害制御テーブル４３３ｂでは「Ｍｏｄ２」とする。これは、共有セグメント５内の全ルータ数「３」から、障害が発生したルータ数「１」を減じた結果、共有セグメント５内の正常動作するルータ数「２」となるためである。
・障害制御テーブル４３３ｂでは、「１台障害」列の計算対象となるレコードを、障害ルータが正常制御テーブル４３３ａにおいて配信担当となっていたフローに限定する。例えば、「Ｒ１障害」列では、障害ルータ「Ｒ１」が正常制御テーブル４３３ａの「Ｒ」列で「Ｒ１」となっているフローＦ１，Ｆ４だけを障害制御テーブル４３３ｂでの計算対象とし、それ以外のフローＦ２，Ｆ３は、計算対象外を示す「−」を「Ｒ１障害」列に記載する。

以下、障害制御テーブル４３３ｂの「１台障害」列の作成方法を、例示する。例えば、全３台の配信ルータ４のうちの、障害ルータがＲ１の１台であり、残りの２台が生存しているとする。
例えば、障害制御テーブル４３３ｂの１行目（フローＦ１）は、「Ｓ＋Ｇ」列「３」÷障害時の全生存ルータ数「２」＝商が１で余りが１なので、「Ｍｏｄ２」列が「１」である。
そして、表１のルータ管理テーブル４３５の４行目（「Ｒ１（１台障害時）」）の配信ルータごとの順位では、Ｒ３（１位）→Ｒ２（２位）となっている。
ここで、「Ｍｏｄ２」列からルータ順位への変換処理は、「Ｍｏｄ２」列が０でないときには、「Ｍｏｄ２」列の値をそのままルータ順位とし、「Ｍｏｄ２」列が０であるときには、ルータ順位が最下位のルータ順位とする。
よって、「Ｍｏｄ２」列が「１」から、ルータ順位が１位ルータ「Ｒ３」へと変換され、障害制御テーブル４３３ｂの１行目のＲ１障害列として、「Ｒ３」が書き込まれる。

以上説明した配信制御テーブル４３３の作成処理では、共有セグメント５に３台の配信ルータ４が接続されている例を説明したが、共有セグメント５に接続される配信ルータ４の台数は、任意の台数でもよい。例えば、共有セグメント５にｎ台の配信ルータ４が接続されているときには、各テーブルには、以下の内容が書き込まれる。
・ルータ管理テーブル４３５には、ｎ台正常時のレコード、１台障害時のレコード、２台障害時のレコード、…（ｎ−１）台障害時のレコードが書き込まれる。
・正常制御テーブル４３３ａには、ｎ台正常時のレコードが書き込まれる。
・障害制御テーブル４３３ｂには、ｎ台正常時のレコード、１台障害時のレコード、２台障害時のレコード、…（ｎ−１）台障害時のレコードが書き込まれる。なお、（ｎ−１）台障害時には、残った１台が全てのフローを配信することが明らかなため（図３参照）、障害制御テーブル４３３ｂから（ｎ−１）台障害時のレコードを省略してもよい。

さらに、ルータ管理テーブル４３５、障害制御テーブル４３３ｂに格納される２台以上の障害時のレコード（多重障害のレコード）は、あらかじめ作成してもよいし、必要時に作成してもよい。必要時とは、例えば、ｋ台障害が実際に発生したときに、（ｋ＋１）台障害時のレコードを作成する旨である。これにより、ルータ管理テーブル４３５、障害制御テーブル４３３ｂの記憶容量を節約できる。

図５は、フロー配信処理を示すフローチャートである。
Ｓ１１として、受信ＩＦ部４１１は、マルチキャスト配信網２から下り方向のパケットを受信する。Ｓ１１でＹｅｓならＳ１２に進む。
Ｓ１２として、配信フィルタ部４３１は、Ｓ１１で受信したパケットがマルチキャストか否かを判定する。この判定は、例えば、ＩＰｖ４の場合には、パケットのアドレスがクラスＤ（224.0.0.0〜239.255.255.255）のアドレスの場合をマルチキャストとすることで実現される。Ｓ１２でＹｅｓならＳ１４に進み、ＮｏならＳ１３に進む。
Ｓ１３として、配信フィルタ部４３１は、Ｓ１１で受信したパケットを、通常のパケット（ユニキャスト、ブロードキャストなどの非マルチキャストパケット）として転送する。

Ｓ１４として、フロー判定部４３２は、Ｓ１１で受信したパケットのフロー特定情報（Ｓ，Ｇ）を正常制御テーブル４３３ａから検索し、検索されたレコードの配信担当ルータ（Ｒ）列を参照することにより、自ルータが配信担当ルータか否かを判定する。Ｓ１４でＹｅｓならＳ１７に進み、ＮｏならＳ１５に進む。
Ｓ１５として、配信障害検出部４３６（または、ルータ管理部４３４）は、自ルータと同じ共有セグメント５に接続される他の配信ルータ４に障害が発生したか否かを判定する。この判定は、後記する配信障害検出部４３６（または、ルータ管理部４３４）の障害検出処理（図７のＳ２０１）の結果を記憶手段から読み取ることにより、実現される。Ｓ１５でＹｅｓならＳ１６に進み、ＮｏならＳ１９に進む。

Ｓ１６として、フロー判定部４３２は、Ｓ１１で受信したパケットのフロー特定情報（Ｓ，Ｇ）を障害制御テーブル４３３ｂから検索し、検索されたレコードの該当する障害時の配信代行ルータ（Ｒ１障害列など）を参照することで、自ルータが配信代行ルータか否かを判定する。Ｓ１６でＹｅｓならＳ１７に進み、ＮｏならＳ１９に進む。

Ｓ１７として、配信管理部４３７は、Ｓ１１で受信したパケットのフローに対して、配信フィルタリスト４３８において配信中状態（Join）が対応づけられているか否かを参照することにより、そのフローが配信中か否かを判定する。Ｓ１７でＹｅｓならＳ１８に進み、ＮｏならＳ１９に進む。

Ｓ１８として、配信フィルタ部４３１は、共有セグメント接続インタフェース４５を介して、Ｓ１１のパケットを該当する（配信先のホスト６が存在する）共有セグメント５へ転送する。
Ｓ１９として、配信フィルタ部４３１は、Ｓ１１で受信したパケットを廃棄する。

図６は、障害制御テーブル４３３ｂの生成処理を示すフローチャートである。
Ｓ１０１として、フロー判定部４３２は、正常制御テーブル４３３ａ内のレコード（正常系配信エントリ）を生成または更新する。
Ｓ１０２として、フロー判定部４３２は、障害制御テーブル４３３ｂに登録するレコード内容の設定方法をユーザに選択させる。手動設定ならＳ１１１へ進み、自動計算ならＳ１０３へ進む。
Ｓ１１１として、フロー判定部４３２は、障害制御テーブル４３３ｂの内容について、管理者から入力されたデータをそのまま障害制御テーブル４３３ｂに書き出す。つまり、ルータごと、もしくは（S,G）フローごとに管理者が配信代行ルータを選定し、障害制御テーブル４３３ｂに登録する。

Ｓ１０３として、ルータ管理部４３４は、障害時における全正常ルータの数を計算する。例えば、３台のルータのうちの１台に障害が発生したときには、全正常ルータは、２台である。
Ｓ１０４として、フロー判定部４３２は、正常制御テーブル４３３ａに登録されている全ての（S,G）フローに対し、障害系におけるハッシュ値Ｍｏｄ２を計算する。
Ｓ１０５として、ルータ管理部４３４は、ルータ管理テーブル４３５における障害時におけるクエリア順位から、配信代行ルータを計算する。
Ｓ１０６として、フロー判定部４３２は、配信代行ルータ（Ｓ１０５）とハッシュ値（Ｓ１０４）とを対応づけて、障害制御テーブル４３３ｂに登録（新規レコードを追加）する。

図７は、ルータ障害が発生した際における配信障害の復旧処理を示すフローチャートである。
Ｓ２０１として、配信障害検出部４３６（または、ルータ管理部４３４）は、自ルータと同じ共有セグメント５に接続される他の配信ルータ４に発生した障害を検出する。障害検出方法は、例えば、以下の２通りのいずれかである。
（検出１）配信障害検出部４３６が外部のネットワークから障害通知（障害ルータIPアドレス等）を受信してルータ管理部４３４へルータ障害発生を通知する。
（検出２）ルータ管理部４３４が共有セグメント５から受信するクエリの未受信を契機に、ルータ障害を検出する。

Ｓ２０２として、フロー判定部４３２は、障害制御テーブル４３３ｂを参照することで、Ｓ２０１で検出した障害ルータに割り当てられていたフローを障害フローとして特定する。
Ｓ２０３として、配信管理部４３７は、配信フィルタリスト４３８を参照して、障害フローのうちの配信中状態（Join）であるフローを１つずつ選択し、選択するフローが存在しないとき（Ｓ２０３，Ｎｏ）には、図７の処理を終了し、存在するとき（Ｓ２０３，Ｙｅｓ）には、Ｓ２０４に進む。
Ｓ２０４として、フロー判定部４３２は、Ｓ１６と同様に、自ルータが配信代行か否かを判定し、ＹｅｓならＳ２０５へ進み、ＮｏならＳ２０３に戻る。
Ｓ２０５として、配信フィルタ部４３１は、Ｓ２０３で選択されたフローについて、配信フィルタリスト４３８の状態を配信中状態（Join）に変更することで、当該フローを配信制御する。そして、Ｓ２０３へ戻る。

図８は、ルータ障害からの配信切替え後に配信要求を受信した際において、配信制御テーブル４３３の更新処理を示すフローチャートである。
Ｓ３０１として、配信管理部４３７は、配信要求（join/leave）を受信し、その対象となるフローの特定情報を、該当（Ｓ，Ｇ）として抽出する。以下のＳ３０２〜Ｓ３１３の処理は、配信制御テーブル４３３に未登録の該当（Ｓ，Ｇ）を、配信制御テーブル４３３に登録する処理である。

Ｓ３０２として、フロー判定部４３２は、該当（Ｓ，Ｇ）が正常制御テーブル４３３ａに登録されているか否かを判定し、ＹｅｓならＳ３０３へ進み、ＮｏならＳ３０５へ進む。
Ｓ３０５として、フロー判定部４３２は、該当（Ｓ，Ｇ）フローに対し、ハッシュ値（Ｍｏｄ３）と配信担当ルータ（Ｒ）とを計算し、その結果を正常制御テーブル４３３ａに登録（新規レコード追加）する。そして、Ｓ３１１へ進む。

Ｓ３０３として、フロー判定部４３２は、Ｓ１４と同様に、自ルータが配信担当か否かを判定し、Ｙｅｓなら図８の処理を終了し、ＮｏならＳ３０４へ進む。
Ｓ３０４として、フロー判定部４３２は、該当（Ｓ，Ｇ）が障害制御テーブル４３３ｂに登録されているか否かを判定し、Ｙｅｓなら図８の処理を終了し、ＮｏならＳ３１１へ進む。
Ｓ３１１〜Ｓ３１３は、図６のＳ１０４〜Ｓ１０６と同じ処理であるが、登録対象がＳ１０４での全ての（Ｓ，Ｇ）から、Ｓ３１１の該当（Ｓ，Ｇ）へと変更されている。
なお、図８のフローチャートが終了したら、Ｓ３０１の該当（Ｓ，Ｇ）を引数として、図９のフローチャートを起動させる。

図９は、ルータ障害からの配信切替え後に配信要求を受信した際において、要求に対するフロー配信処理を示すフローチャートである。
Ｓ４０１として、フロー判定部４３２は、Ｓ１４と同様に、該当（Ｓ，Ｇ）が自ルータの配信担当か否かを判定し、ＹｅｓならＳ４０２に進み、ＮｏならＳ４０４へ進む。
Ｓ４０２として、配信管理部４３７は、Ｓ１７と同様に、該当（Ｓ，Ｇ）が配信中状態（Join）か否かを判定し、Ｙｅｓなら図９の処理を終了し、ＮｏならＳ４０３へ進む。
Ｓ４０３として、配信フィルタ部４３１は、Ｓ２０５と同様に、当該フローを配信制御する。

Ｓ４０４として、配信障害検出部４３６（または、ルータ管理部４３４）は、Ｓ１５と同様に、障害時か否かを判定し、ＹｅｓならＳ４０５へ進み、Ｎｏなら図９の処理を終了する。
Ｓ４０５として、フロー判定部４３２は、Ｓ１６と同様に、該当（Ｓ，Ｇ）が自ルータの配信代行か否かを判定し、ＹｅｓならＳ４０３に進み、Ｎｏなら図９の処理を終了する。

以上説明した本実施形態では、あらかじめクエリア障害を想定した配信設定を準備しておくことにより、障害検出後に即時切替え可能とし、また、正常なクエリアに割当てされているフローに関しては、配信ルータを変更しないように、正常時と障害パタン毎の複数の配信設定を併用することを特徴とする。

これにより、ＩＰルータがＩＧＭＰ／ＭＬＤプロトコルを用いてＩＰマルチキャストの配信制御を行うときに、共有セグメントに複数ルータが冗長接続される構成で、ルータ障害が発生したときでも、フローの配信漏れや重複配信を抑制することで、安定したフロー配信を実現するとともに、複数ルータそれぞれに配信担当となるフローが割り当てられることで、共有セグメント内の系全体としての帯域利用効率（配信収容効率）を向上させることができる。

以下、本実施形態の効果を説明するために、以下の２つの比較例と比較する。
（比較例１）非特許文献１，２で示されるＩＧＭＰｖ３／ＭＬＤｖ２のクエリア選択メカニズム
（比較例２）共有セグメントに複数ルータが冗長接続されるときに、複数ルータそれぞれに配信担当となるフローを計算して割り当てるが、障害発生時には、共有セグメント内の全ルータそれぞれに対して配信担当となるフローを再計算する構成

以下、（比較例１）、（比較例２）、および、本実施形態の構成それぞれについて、４つの課題を解決するか否かを比較説明する。

第１の課題として、ＩＧＭＰｖ３／ＭＬＤｖ２では、セグメントに３台以上のルータが存在する場合、クエリアに障害が生じると、一時的に同一フローの二重配信が生じる可能性があることが挙げられる。
（比較例１）では、非クエリアは、クエリア障害が生じるとＧＱパケットを受信しなくなり、ＧＱ受信タイマがＯＱＰＴタイムアウト値に到達した場合には、非クエリアは現クエリアに障害が発生したと仮定したと判定してクエリア状態へ遷移する。ここで、ＩＧＭＰ／ＭＬＤホストからｊｏｉｎレポートを受信すると、クエリア状態へと遷移した全てのクエリアがこれに応答して配信を行うため、同一フローの二重配信が生じる。
（比較例１）では、ＯＱＰＴタイムアウトして非クエリアからクエリアへ遷移する制御動作が、ルータごとに独立しているため、系全体として新しいクエリアが一つに収束するまで所定時間が必要となる。

第２の課題として、（比較例２）は、全ルータが正常な状態においてフロー単位に配信ルータを分散する技術であり、クエリア障害が生じた状態における制御動作については規定していないとすると、何らか障害復旧の技術を導入しない限り、障害ルータに割当てられるフローが配信断したままとなる。
よって、障害検出と障害フローの救済は何らか別の方法が必要となる。ここで、障害の検出に関しては、どのような手段を用いても構わないが、例えば、従来のＩＧＭＰｖ３／ＭＬＤｖ２と同様に、ＯＱＰＴタイムアウトの仕組みを流用する方法などが考えられる。これに対して、障害検出後のフロー救済方法については、例えば、障害クエリアを除外した系において負荷分散の設定を再構成し直す方法が考えられる。
すなわち、障害系において、クエリア順位を再設定し、（Ｓ，Ｇ）フロー単位のハッシュ値の再計算を行い、ルータとフローの対応関係を変更することにより、障害フローの救済が可能となる。

しかし、第３の課題として、（比較例２）では、正常なクエリアで配信していたフローについても、配信ルータが切り替る可能性があるため、系切替えに伴う正常フローの配信断（瞬断等）を伴う。
また、第４の課題として、（比較例２）では、切替え後のルータとフローの対応関係の再計算が完了し、新旧の配信テーブルを切り替えるまでは、障害クエリアが制御するフロー配信を救済できないため、サービス断時間が長期化する。

一方、本実施形態の構成では、障害検出後の処理として、（比較例１）のような各自ルータの独自判断による代替クエリアへの変更でもなく、（比較例２）のようなフロー配信担当の再計算でもなく、障害ルータの担当分のフローだけをあらかじめクエリア障害を想定した配信設定に即時切替を行うことにより、前記した第１の課題〜第４の課題の発生を防止する。

つまり、本実施形態では、複数のＩＧＭＰ／ＭＬＤルータでフローの配信制御を負荷分散している系でルータ障害が発生した場合において、当該ルータで配信していたフローの制御を復旧する救済手段を提供可能なため、高信頼なＩＰマルチキャストサービスが実現可能となる。また、任意のルータ障害を想定した配信設定を事前準備が可能なため、迅速なサービス復旧が実現可能となる。さらに、正常なフロー配信には影響がないため、品質の安定性が高いサービスが実現可能となる。

１ 配信サーバ
２ マルチキャスト配信網
３ リンク
４ 配信ルータ
５ 共有セグメント
６ ホスト
４１ ＭＣ配信網接続インタフェース
４２ ＭＣ配信網フレーム転送部
４３ 転送制御回路
４４ 共有セグメントフレーム転送部
４５ 共有セグメント接続インタフェース
４１１ 受信ＩＦ部
４１２ 送信ＩＦ部
４２１ フレーム受信部
４２２ フレーム送信部
４４１ フレーム送信部
４４２ フレーム受信部
４５１ 送信ＩＦ部
４５２ 受信ＩＦ部
４３１ 配信フィルタ部
４３２ フロー判定部
４３３ 配信制御テーブル
４３３ａ 正常制御テーブル（正常制御用データ）
４３３ｂ 障害制御テーブル（障害制御用データ）
４３４ ルータ管理部
４３５ ルータ管理テーブル
４３６ 配信障害検出部
４３７ 配信管理部
４３８ 配信フィルタリスト
４３９ 上位連携部

Claims (6)

1. 配信サーバから配信ルータを介してホストにマルチキャストのフローを配信するマルチキャスト配信システムであって、
   複数台の前記配信ルータと１台以上の前記ホストとが共有セグメントに接続され、その共有セグメントに送信されるパケットは、前記共有セグメントに接続される各装置が受信可能であり、
   前記配信ルータは、転送制御部と記憶手段とを有しており、
   前記配信ルータの記憶手段には、正常制御用データと障害制御用データとが記憶されており、
   前記正常制御用データは、前記共有セグメントを介して配信される１つのフローごとに１台の前記配信ルータを配信担当ルータとして割り当てるデータであり、
   前記障害制御用データは、前記１台以上の配信担当ルータを障害ルータとしたときに、前記障害ルータに割り当てられていた障害フローに対して、前記障害ルータとは別の前記配信ルータを、配信代行ルータとして割り当てるデータであり、
   前記共有セグメントに接続される各前記配信ルータの転送制御部は、
   前記障害ルータとして他装置の前記配信ルータを検出した後、
   前記配信サーバからフローの配信データを受信すると、受信した配信データの属するフローの特定情報を検索キーとして、前記正常制御用データと前記障害制御用データとをそれぞれ検索することで、検索したフローの前記配信担当ルータおよび前記配信代行ルータをそれぞれ取得し、
   取得した前記正常制御用データから検索される前記配信担当ルータまたは前記検出した障害ルータが配信していた前記障害フローに対する前記配信代行ルータが自装置であるときには、前記共有セグメントを介して受信したフローの配信データを前記ホストに転送し、
   取得した前記正常制御用データから検索される前記配信担当ルータおよび前記検出した障害ルータが配信していた前記障害フローに対する前記配信代行ルータが他装置であるときには、受信したフローの配信データを廃棄することを特徴とする
   マルチキャスト配信システム。
2. 前記共有セグメントに接続される各前記配信ルータの転送制御部は、
   前記正常制御用データを前記記憶手段に格納するときに、受信した配信データの属するフローの特定情報と、前記共有セグメントに接続される前記配信ルータの数と、を引数とする所定関数を計算し、その所定関数の計算結果から一意に決定される前記配信ルータを、前記所定関数の計算に用いたフローに対する配信担当ルータとして決定し、
   前記障害制御用データを前記記憶手段に格納するときに、前記１台以上の配信ルータから選択した前記１台以上の障害ルータの組み合わせごとに、受信した配信データの属するフローの特定情報と、前記共有セグメントに接続される前記配信ルータの数から前記障害ルータの数を減じたルータの数と、を引数とする前記所定関数を計算し、その所定関数の計算結果から一意に決定される前記配信ルータを、前記所定関数の計算に用いたフローに対する配信代行ルータとして決定することを特徴とする
   請求項１に記載のマルチキャスト配信システム。
3. 配信サーバから配信ルータを介してホストにマルチキャストのフローを配信するマルチキャスト配信システムに用いられる配信ルータであって、
   複数台の前記配信ルータと１台以上の前記ホストとが共有セグメントに接続され、その共有セグメントに送信されるパケットは、前記共有セグメントに接続される各装置が受信可能であり、
   前記配信ルータは、転送制御部と記憶手段とを有しており、
   前記配信ルータの記憶手段には、正常制御用データと障害制御用データとが記憶されており、
   前記正常制御用データは、前記共有セグメントを介して配信される１つのフローごとに１台の前記配信ルータを配信担当ルータとして割り当てるデータであり、
   前記障害制御用データは、前記１台以上の配信担当ルータを障害ルータとしたときに、前記障害ルータに割り当てられていた障害フローに対して、前記障害ルータとは別の前記配信ルータを、配信代行ルータとして割り当てるデータであり、
   前記共有セグメントに接続される各前記配信ルータの転送制御部は、
   前記障害ルータとして他装置の前記配信ルータを検出した後、
   前記配信サーバからフローの配信データを受信すると、受信した配信データの属するフローの特定情報を検索キーとして、前記正常制御用データと前記障害制御用データとをそれぞれ検索することで、検索したフローの前記配信担当ルータおよび前記配信代行ルータをそれぞれ取得し、
   取得した前記正常制御用データから検索される前記配信担当ルータまたは前記検出した障害ルータが配信していた前記障害フローに対する前記配信代行ルータが自装置であるときには、前記共有セグメントを介して受信したフローの配信データを前記ホストに転送し、
   取得した前記正常制御用データから検索される前記配信担当ルータおよび前記検出した障害ルータが配信していた前記障害フローに対する前記配信代行ルータが他装置であるときには、受信したフローの配信データを廃棄することを特徴とする
   配信ルータ。
4. 前記共有セグメントに接続される各前記配信ルータの転送制御部は、
   前記正常制御用データを前記記憶手段に格納するときに、受信した配信データの属するフローの特定情報と、前記共有セグメントに接続される前記配信ルータの数と、を引数とする所定関数を計算し、その所定関数の計算結果から一意に決定される前記配信ルータを、前記所定関数の計算に用いたフローに対する配信担当ルータとして決定し、
   前記障害制御用データを前記記憶手段に格納するときに、前記１台以上の配信ルータから選択した前記１台以上の障害ルータの組み合わせごとに、受信した配信データの属するフローの特定情報と、前記共有セグメントに接続される前記配信ルータの数から前記障害ルータの数を減じたルータの数と、を引数とする前記所定関数を計算し、その所定関数の計算結果から一意に決定される前記配信ルータを、前記所定関数の計算に用いたフローに対する配信代行ルータとして決定することを特徴とする
   請求項３に記載の配信ルータ。
5. 配信サーバから配信ルータを介してホストにマルチキャストのフローを配信するマルチキャスト配信方法であって、
   複数台の前記配信ルータと１台以上の前記ホストとが共有セグメントに接続され、その共有セグメントに送信されるパケットは、前記共有セグメントに接続される各装置が受信可能であり、
   前記配信ルータは、転送制御部と記憶手段とを有しており、
   前記配信ルータの記憶手段には、正常制御用データと障害制御用データとが記憶されており、
   前記正常制御用データは、前記共有セグメントを介して配信される１つのフローごとに１台の前記配信ルータを配信担当ルータとして割り当てるデータであり、
   前記障害制御用データは、前記１台以上の配信担当ルータを障害ルータとしたときに、前記障害ルータに割り当てられていた障害フローに対して、前記障害ルータとは別の前記配信ルータを、配信代行ルータとして割り当てるデータであり、
   前記共有セグメントに接続される各前記配信ルータの転送制御部は、
   前記障害ルータとして他装置の前記配信ルータを検出した後、
   前記配信サーバからフローの配信データを受信すると、受信した配信データの属するフローの特定情報を検索キーとして、前記正常制御用データと前記障害制御用データとをそれぞれ検索することで、検索したフローの前記配信担当ルータおよび前記配信代行ルータをそれぞれ取得し、
   取得した前記正常制御用データから検索される前記配信担当ルータまたは前記検出した障害ルータが配信していた前記障害フローに対する前記配信代行ルータが自装置であるときには、前記共有セグメントを介して受信したフローの配信データを前記ホストに転送し、
   取得した前記正常制御用データから検索される前記配信担当ルータおよび前記検出した障害ルータが配信していた前記障害フローに対する前記配信代行ルータが他装置であるときには、受信したフローの配信データを廃棄することを特徴とする
   マルチキャスト配信方法。
6. 前記共有セグメントに接続される各前記配信ルータの転送制御部は、
   前記正常制御用データを前記記憶手段に格納するときに、受信した配信データの属するフローの特定情報と、前記共有セグメントに接続される前記配信ルータの数と、を引数とする所定関数を計算し、その所定関数の計算結果から一意に決定される前記配信ルータを、前記所定関数の計算に用いたフローに対する配信担当ルータとして決定し、
   前記障害制御用データを前記記憶手段に格納するときに、前記１台以上の配信ルータから選択した前記１台以上の障害ルータの組み合わせごとに、受信した配信データの属するフローの特定情報と、前記共有セグメントに接続される前記配信ルータの数から前記障害ルータの数を減じたルータの数と、を引数とする前記所定関数を計算し、その所定関数の計算結果から一意に決定される前記配信ルータを、前記所定関数の計算に用いたフローに対する配信代行ルータとして決定することを特徴とする
   請求項５に記載のマルチキャスト配信方法。

Images