マルチキャスト配信システム、配信ルータ、および、マルチキャスト配信方法
【課題】共有セグメントに複数のマルチキャスト配信ルータが接続される構成において、クエリアの障害回復時にもフロー配信を安定させること。
【解決手段】配信サーバ１から配信ルータ４を介してホスト６にマルチキャストのフローを配信するマルチキャスト配信システムであって、複数台の配信ルータ４と１台以上のホスト６とが共有セグメント５に接続され、配信ルータ４（Ｒ２）の転送制御部は、配信ルータ４（Ｒ１）の障害復旧を検出するまでは、配信ルータ４（Ｒ１）に代行して、所定フローを配信する処理を実行し、配信ルータ４（Ｒ１）の障害復旧を検出した後で、所定フローを配信要求するホスト６が共有セグメント５上で０台になったときに、所定フローを配信する処理を停止する。
【解決手段】配信サーバ１から配信ルータ４を介してホスト６にマルチキャストのフローを配信するマルチキャスト配信システムであって、複数台の配信ルータ４と１台以上のホスト６とが共有セグメント５に接続され、配信ルータ４（Ｒ２）の転送制御部は、配信ルータ４（Ｒ１）の障害復旧を検出するまでは、配信ルータ４（Ｒ１）に代行して、所定フローを配信する処理を実行し、配信ルータ４（Ｒ１）の障害復旧を検出した後で、所定フローを配信要求するホスト６が共有セグメント５上で０台になったときに、所定フローを配信する処理を停止する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチキャスト配信システム、配信ルータ、および、マルチキャスト配信方法に関する。
【背景技術】
【０００２】
ＩＰ（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）
【発明の概要】
【発明が解決しようとする課題】
【０００９】
共有セグメントに複数のルータが存在する場合、それらのうちの一部のルータの装置本体やルータに付属するネットワークインタフェースに障害が発生したときに、残りのルータがフロー配信を代行することで、配信制御を継続する。そして、障害が発生したルータが、障害から回復したときには、代行されていたフロー配信を再び担当する（切り戻す）ことで、正常時の状態に復帰する。ここで、障害から回復したルータにおけるフロー配信の復帰に伴い、その期間にフローの配信が不安定になる。
【００１０】
以下、同一セグメント内に、複数の配信ルータ（Ｒ１，Ｒ２）が存在するときの、３つの状態（状態１）〜（状態３）を順に説明する。
【００１１】
（状態１）配信ルータ（Ｒ１）の障害発生前の状態。配信ルータ（Ｒ１）がクエリアである。クエリア（Ｒ１）は、ＱＩ（Query Interval）時間間隔で周期的にクエリを送信する。ホストは、自らの配信要求を示すレポートを応答する。非クエリア（Ｒ２）は、タイマ上限値（以下、ＯＱＰＴ）を超過するまでにクエリを受信すれば、非クエリアの状態を維持して配信制御を行わない。
【００１２】
（状態２）配信ルータ（Ｒ１）の障害発生により他の正常なルータ（Ｒ２）へ配信制御を切り替えた状態。非クエリア（Ｒ２）は、クエリア（Ｒ１）からクエリを受信しなくなる。非クエリア（Ｒ２）は、自タイマがＯＱＰＴを超過すると、（Ｒ１）からクエリアを引き継ぎ、配信制御を再開する。
【００１３】
（状態３）配信ルータ（Ｒ１）の障害回復後に、ルータ（Ｒ２）から配信ルータ（Ｒ１）へと配信制御を切り戻す状態。クエリア選択アルゴリズムにより、ルータアドレスが最小ではないクエリア（Ｒ２）は非クエリアへ状態遷移して配信を停止する。これに対し、ルータアドレスが最小である配信ルータ（Ｒ１）は、再びクエリアとなり、ホストから配信要求を受信したことを契機に、配信を再開する。
【００１４】
従来技術（ＩＧＭＰｖ２／ＩＧＭＰｖ３／ＭＬＤｖ２）を用いるときには、（状態３）において、フローの配信が不安定になる。
【００１５】
図８は、フローの配信漏れが発生するまでの様子を示すフローチャートである。
Ｓ７００〜Ｓ７０４が、（状態２）に該当する。
Ｓ７００として、配信ルータ（Ｒ１）に、障害が発生する。Ｓ７０１として、配信ルータ（Ｒ２）は、クエリアに遷移すると、クエリをホストに送信する（Ｓ７０２）。Ｓ７０３として、ホストは、リポート（フローｆ１に対して配信要求を示す「join」を指定した内容を含む）を配信ルータ（Ｒ２）に送信する。Ｓ７０４として、配信ルータ（Ｒ２）は、リポートで指定されたフローｆ１を、ホストに配信する。
【００１６】
Ｓ７０５〜Ｓ７１４が、（状態３）に該当する。
Ｓ７０５として、配信ルータ（Ｒ１）は、障害から回復すると、クエリを送信する（Ｓ７１１）。
Ｓ７１２として、配信ルータ（Ｒ２）は、非クエリアに遷移（配信停止）する。
Ｓ７１３として、ホストは、リポート（ｆ１にjoin）を配信ルータ（Ｒ１）に送信する。
Ｓ７１４として、配信ルータ（Ｒ１）は、フローｆ１をホストに配信する。
【００１７】
ここで、Ｓ７１２からＳ７１４までの期間は、ホストにとっては、ｆ１にjoinしている（Ｓ７１３）にもかかわらず、どの配信ルータからもフローｆ１を受信できない期間（つまり、配信漏れの期間）である。
配信漏れの期間が発生する要因は、配信ルータ（Ｒ２）における個々のフローごとの配信状態が無視され、配信ルータ（Ｒ２）の状態がクエリアから非クエリアに遷移すれば、全てのフローのクエリアが無条件に配信ルータ（Ｒ１）切り戻されるためである。
【００１８】
図９は、フローの重複配信が発生するまでの様子を示すフローチャートである。Ｓ７００〜Ｓ７０５は、図８の動作と同じである。
Ｓ７２１として、配信ルータ（Ｒ１）は、クエリをホストおよび配信ルータ（Ｒ２）に送信する。
Ｓ７２２として、ホストは、リポート（ｆ１にjoin）を配信ルータ（Ｒ１）に送信する。
Ｓ７２３として、配信ルータ（Ｒ１）は、フローｆ１をホストに配信する。
Ｓ７２４として、配信ルータ（Ｒ２）は、Ｓ７２１の受信に伴い、非クエリアに遷移（配信停止）する。
【００１９】
ここで、Ｓ７２３からＳ７２４までの期間は、ホストにとっては、２台の配信ルータから、同じフローｆ１のデータが重複して配信されている期間である。
重複配信の期間が発生する要因は、個々のルータおよびホストが独立した制御動作を行うだけで、互いに同期制御を行っていないからである。図９に示すように、処理負荷の違いなどによりルータ間の配信制御の開始（Ｓ７２３）と停止（Ｓ７２４）との順序が逆転する場合には、重複配信が発生する。
【００２０】
そこで、本発明は、共有セグメントに複数のマルチキャスト配信ルータが接続される構成において、クエリアの障害回復時にもフロー配信を安定させることを、主な目的とする。
【課題を解決するための手段】
【００２１】
前記課題を解決するために、本発明は、配信サーバから配信ルータを介してホストにマルチキャストのフローを配信するマルチキャスト配信システムであって、複数台の前記配信ルータと１台以上のホストとが共有セグメントに接続され、その前記共有セグメントに送信されるパケットが、前記共有セグメントに接続される各装置が受信可能であり、前記配信ルータが、転送制御部と記憶手段とを有しており、前記配信ルータの記憶手段には、所定フローについて、正常時の配信担当を示すクエリアの配信ルータと、障害時の配信担当を示すセンダの配信ルータとが記憶されており、前記センダの配信ルータの転送制御部が、前記クエリアの配信ルータの障害復旧を検出するまでは、前記クエリアの配信ルータに代行して、前記所定フローを配信する処理を実行し、前記クエリアの配信ルータの障害復旧を検出した後で、前記所定フローを配信要求するホストが前記共有セグメント上で０台になったときに、前記所定フローを配信する処理を停止することを特徴とする。
【００２２】
これにより、配信ルータは、ホストにとってフロー配信が不要である時間帯として、所定フローを配信要求するホストが０台になる時間帯まで待ってからフローの配信を停止することにより、ホストのユーザへのフロー配信処理に対する影響を最小化する。
【００２３】
本発明は、前記クエリアの配信ルータの転送制御部が、前記センダの配信ルータの転送制御部からの前記所定フローを配信する処理が停止されたことを、前記センダの配信ルータから通知された後に、前記所定フローを配信する処理を再開することを特徴とする。
【００２４】
これにより、クエリアの配信ルータの配信再開が、センダの配信ルータの配信停止後になるので、クエリアとセンダとで同じコンテンツを重複配信することを防止できる。
【００２５】
本発明は、前記センダの配信ルータの転送制御部が、前記所定フローを配信する処理を停止する契機として、前記所定フローを配信要求するホストが前記共有セグメント上で０台になったとき、の代わりに、前記配信サーバから前記所定フローが配信されないときとすることを特徴とする。
【００２６】
これにより、配信ルータは、ホストにとってフロー配信が不要である時間帯として、所定フローが配信されない時間帯まで待ってからフローの配信を停止することにより、ホストのユーザへのフロー配信処理に対する影響を最小化する。
【００２７】
本発明は、前記センダの配信ルータの転送制御部が、前記所定フローを配信する処理を停止する契機として、前記所定フローを配信要求するホストが前記共有セグメント上で０台になったとき、の代わりに、前記所定フローとして配信されるコンテンツの優先度として、所定値よりも低い優先度が設定されているときとすることを特徴とする。
【００２８】
これにより、配信ルータは、比較的低い優先度のコンテンツが配信される時間帯まで待ってからフローの配信を停止することにより、ホストのユーザへのフロー配信処理に対する影響を少なくする。
【発明の効果】
【００２９】
本発明によれば、共有セグメントに複数のマルチキャスト配信ルータが接続される構成において、クエリアの障害回復時にもフロー配信を安定させることができる。
【図面の簡単な説明】
【００３０】
【図１】本発明の一実施形態に関するマルチキャスト配信システムを示す構成図である。
【図２】本発明の一実施形態に関する配信ルータを示す構成図である。
【図３】本発明の一実施形態に関するマルチキャスト配信システムの配信動作の前半（障害発生〜障害回復）の動作を示すフローチャートである。
【図４】本発明の一実施形態に関するマルチキャスト配信システムの配信動作の後半（障害回復〜配信の切り戻し）の動作を示すフローチャートである。
【図５】本発明の一実施形態に関する配信ルータがホストから「join」を受信したときの動作を示すフローチャートである。
【図６】本発明の一実施形態に関する配信ルータがホストから「leave」を受信したときの動作を示すフローチャートである。
【図７】本発明の一実施形態に関する切り戻し処理を示すフローチャートである。
【図８】フローの配信漏れが発生するまでの様子を示すフローチャートである。
【図９】フローの重複配信が発生するまでの様子を示すフローチャートである。
【発明を実施するための形態】
【００３１】
以下、本発明の一実施形態について、図面を参照して詳細に説明する。
【００３２】
図１は、マルチキャスト配信システムを示す構成図である。マルチキャストフロー（以下、単にフローとする）は、配信サーバ１から送信されて、マルチキャスト配信網２、リンク３、各配信ルータ４（Ｒ１，Ｒ２，Ｒ３）、共有セグメント５を経由して、各ホスト６（Ｈ１，Ｈ２，Ｈ３）に配信される。
これらのマルチキャスト配信システムの各装置は、ＣＰＵ（Central Processing Unit）とメモリとハードディスク（記憶手段）とネットワークインタフェースを有するコンピュータとして構成され、このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラムを実行することにより、各処理部を動作させる。
【００３３】
マルチキャスト配信網２は、例えば、インターネット網であり、配信サーバ１から配信ルータ４への経路決定のためのプロトコルとして、ＤＶＭＲＰ（Distance Vector Multicast Routing Protocol）や、ＰＩＭ−ＳＭ（Protocol Independent Multicast - Sparse Mode）、ＰＩＭ−ＳＳＭ（Protocol Independent Multicast - Source Specific Multicast）などが動作することを想定する。
共有セグメント５は、その共有セグメント５に接続される装置から送信されるパケットが、そのパケットの送信先だけでなく、同じ共有セグメント５に接続される他装置へも伝送される特性を有する。例えば、配信ルータ４（Ｒ１）からホスト６へ送信されるメッセージは、各ホスト６（Ｈ１，Ｈ２，Ｈ３）だけでなく、他の各配信ルータ４（Ｒ２，Ｒ３）も受信することができる。共有セグメント５は、例えば、イーサネット（登録商標）のＬＡＮ（Local Area Network）やアクセス集線スイッチ内のＶＬＡＮ（Virtual LAN）、スイッチ間を跨いだネットワークＶＬＡＮ(IEEE802.1adやIEEE802.1ahによるタグVLAN)等により構成される。
【００３４】
配信サーバ１は、フローの配信元となるサーバである。なお、フローの特定情報としては、フローのグループだけを特定情報とする（＊，ｇ）指定型であるＡＳＭ（Any Source Multicast）と、フローのグループとフローの送信元の配信サーバ１のアドレスの組を特定情報とする（ｓ，ｇ）指定型であるＳＳＭ（Source Specific Multicast）とが挙げられる。
以下、本実施形態では、フローの特定情報を（ｓ，ｇ）指定型として説明するが、（＊，ｇ）指定型にも本実施形態を応用することができる。ここで、（ｓ，ｇ）とは、（Source，Group）の略であり、最初のSourceが送信元の配信サーバ１のアドレスを示し、次のGroupがフローのグループを示す。
【００３５】
配信ルータ４は、マルチキャストのグループ管理プロトコル（ＩＧＭＰおよびＭＬＤのプロトコルなど）が動作するルータであり、配信サーバ１からの配信データを、ホスト６に転送する。配信ルータ４は、リンク３を介して、マルチキャスト配信網２と接続されている。
ホスト６は、配信ルータ４から配信データを受信する端末であり、リスナ（listener）とも呼ばれる。ホスト６は、配信ルータ４からのクエリを受信すると、自装置が希望するフローの情報を含めたレポートを作成し、配信ルータ４に返信する。
【００３６】
図２は、配信ルータ４を示す構成図である。
配信ルータ４は、フローの上流側（マルチキャスト配信網２の側）から順に、ＭＣ配信網接続インタフェース４１、ＭＣ配信網フレーム転送部４２、転送制御回路４３、共有セグメントフレーム転送部４４、共有セグメント接続インタフェース４５が接続されて構成される。
【００３７】
インタフェース（ＭＣ配信網接続インタフェース４１、共有セグメント接続インタフェース４５）は、ネットワークが接続される端点となる箇所であり、外部の網からデータを受信するインタフェース（受信ＩＦ部４１１，４５２）と、外部の網にデータを送信するインタフェース（送信ＩＦ部４５１，４１２）とから構成される。これらのインタフェースは、例えば、イーサネットのＰＨＹ層（Physical Layer）に実装される。
【００３８】
フレーム転送部（ＭＣ配信網フレーム転送部４２、共有セグメントフレーム転送部４４）は、インタフェースが送受信するデータの信号をフレーム単位に変換する処理部であり、受信インタフェースからの通信信号からフレームを構築する受信部（フレーム受信部４４２，４２１）と、構築されたフレームから送信インタフェースを介して送信する通信信号へとデコードする送信部（フレーム送信部４４１，４２２）とから構成される。これらのフレーム転送部は、例えば、イーサネットのＭＡＣ層（Media Access Control Layer）に実装される。
【００３９】
上流（配信サーバ１）から下流（ホスト６）に流れる下りのパケット（マルチキャストフローなど）は、受信ＩＦ部４１１→フレーム受信部４２１→配信フィルタ部４３１→フレーム送信部４４１→送信ＩＦ部４５１の順に、配信ルータ４内を通過する。
下流（ホスト６）から上流（配信サーバ１）に流れる上りのパケット（レポート（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演算）である。
このように、フローごとにクエリアを特定することで、共有セグメント５内に複数のフローが配信されるときに、そのフローごとの配信担当となるクエリアが負荷分散されるので、フローの配信漏れや重複配信を抑制しつつ、共有セグメント全体のフローのスループットを向上させることができる。
さらに、ルータ管理部４３４は、管理者から手動で設定された配信ルータ４をクエリアとするなど、任意のクエリア選択アルゴリズムを用いてもよい。
【００４９】
【表１】
【００５０】
表１は、配信ルータ４（Ｒ１）が正常時であるときの、各配信ルータ４の配信テーブル４３３を示す。なお、ホスト６からのレポートが、同じ共有セグメント５に属する各配信ルータ４に届くため、それらの各配信ルータ４内の配信テーブル４３３のデータ内容は、互いに同じものである。
配信テーブル４３３の左側の３列（フロー，Ｓ，Ｇ）について、フロー列、Ｓ列、Ｇ列は、フローの特定情報が（Ｓ，Ｇ）であることを示している。
配信テーブル４３３の中央の２列（センダ、クエリア）は、対応するフローについての配信ルータ４の役割を示す。配信テーブル４３３では、共有セグメント５内でのクエリアに該当する配信ルータ４に加え、そのクエリアよりも強い（優先される）配信権利を有するセンダ（Sender）が、フローごとに対応づけられている。例えば、クエリアかつセンダである配信ルータ４（Ｒ１）は、２つのフロー（ｆ１、ｆ２）を配信している。
【００５１】
なお、クエリアかつセンダそれぞれの役割は、障害の前後で以下のように引き継がれる。
・配信ルータ４（Ｒ１）の障害前は、クエリアとセンダとが同一の配信ルータ４（Ｒ１）に割り当てられている。
・配信ルータ４（Ｒ１）の障害中は、配信ルータ４（Ｒ２）がクエリアとセンダとの役割を配信ルータ４（Ｒ１）から代行する。
・クエリアの障害回復後は、クエリアを配信ルータ４（Ｒ２）から配信ルータ４（Ｒ１）へとすぐに引き継ぐ。一方、センダの配信ルータ４（Ｒ２）は、ホスト６のユーザに影響しない（または影響が少ない）時間帯まで待ってからフローの配信を停止し、その停止後に、センダを配信ルータ４（Ｒ１）へと引き継ぐ。
【００５２】
ここで、以下の説明では、センダの配信ルータ４（Ｒ２）から配信ルータ４（Ｒ１）への引き継ぎの契機として、「フローを視聴するメンバが０人（マルチキャストグループへの参加人数が０人）になる時間帯」、すなわち、「フローを配信要求するホスト６が共有セグメント５上で０台になる時間帯」を例示するが、その他にも、以下の時間帯としてもよい。
・フローを視聴するメンバが、所定数以下（例えば、３人以下）になる時間帯
・フローを視聴するメンバがいたとしても、上流側からフローが配信されない時間帯（深夜などの放送休止時間）
・フローのコンテンツとして、コンテンツ優先度が所定値より低い内容（無料放送など）が流れている時間帯。一方、コンテンツ優先度が所定値より高い内容（有料放送など）が流れている時間は、センダの引き継ぎ時間帯からは除外する。
【００５３】
配信テーブル４３３の右側の２列（配信状態、配信）は、対応するフローについての配信処理を説明するものである。
配信状態「join」とは、対応するフローの配信を希望する（換言すると、マルチキャストグループへ参加する）ホストが、共有セグメント５内に１台以上存在することを示す。
配信状態「leave」とは、対応するフローの配信を希望する（換言すると、マルチキャストグループへ参加する）ホストが、共有セグメント５内に０台である（換言すると、マルチキャストグループへの離脱）ことを示す。
「配信」列は、その列の配信テーブル４３３を収容する配信ルータ４が、対応するフローについて実際に配信しているか（「○」）否か（「−」）を示す。例えば、フローｆ１は、配信希望（join）されているため、配信ルータ４（Ｒ１）が配信し、配信ルータ４（Ｒ２）は配信しない。
つまり、一般的に、配信状態「join」であるときには、１台の配信ルータ４がフローの配信をすることで重複配信を抑制し、配信状態「leave」であるときには、フローの配信をする必要がないので、全ての配信ルータ４がフローの配信をしない。
【００５４】
図３は、マルチキャスト配信システムの配信動作の前半（障害発生〜障害回復）の動作を示すフローチャートである。このフローチャートを開始する前の各配信ルータ４内の配信テーブル４３３の内容は、表１に示したとおりである。
【００５５】
以下、フローチャートの送信処理の説明からは、その送信先の装置の記載を適宜省略する。図１で説明したように、送信先を明示的に指定しないメッセージが送信されていても、そのメッセージは共有セグメント５上を流れるので、その共有セグメント５に接続される各装置（配信ルータ４、ホスト６）が受信可能である（送信先となりうる）。
【００５６】
Ｓ１００として、配信ルータ４（Ｒ１）に障害が発生すると、フローｆ１などの各フローの配信が中断されてしまう（Ｓ１０１）。
Ｓ１０２として、配信ルータ４（Ｒ２）のフロー判定部４３２は、クエリアとセンダとの役割を配信ルータ４（Ｒ１）から代行する。そのため、配信ルータ４（Ｒ２）内のＧＱ死活監視用のタイマは、時間経過にしたがってタイマ値を増加させるとともに、配信ルータ４（Ｒ１）からのＧＱ受信によりタイマ値を０にリセットする。そして、タイマ値が所定しきい値（ＯＱＰＴ）を超過したときに、配信ルータ４（Ｒ２）は、Ｓ１０２の代行処理を起動させる。
Ｓ１０４として、配信ルータ４（Ｒ２）の配信管理部４３７は、クエリを送信する。
Ｓ１０５として、ホスト６は、リポート（ｆ１にjoin）を送信する。
Ｓ１０６として、配信ルータ４（Ｒ２）のフロー判定部４３２は、Ｓ１０５のjoinの受信処理（図５参照）を起動し、その結果としてフローｆ１の配信を開始する。
【００５７】
【表２】
【００５８】
表２は、表１の状態後に配信ルータ４（Ｒ１）が障害中であるときの（Ｓ１０６時点での）、各配信ルータ４の配信テーブル４３３を示す。
配信ルータ４（Ｒ１）内の配信テーブル４３３では、全フロー（any）の配信が不可（down）であり、センダもクエリアも自装置ではない（値「−」）。
配信ルータ４（Ｒ２）内の配信テーブル４３３では、表１の配信ルータ４（Ｒ１）内の配信テーブル４３３の内容を引き継いでいる。なお、表２におけるセンダ「Ｒ１→Ｒ２」という表記は、センダがＲ１からＲ２へと変更されたことを示す。
【００５９】
Ｓ１０７として、配信ルータ４（Ｒ１）は、障害回復すると、その障害回復に伴う各配信ルータ４内の配信テーブル４３３の更新処理（Ｓ１０８〜Ｓ１１３）が実行される。
Ｓ１０８として、配信ルータ４（Ｒ１）のフロー判定部４３２は、配信テーブル４３３を新規生成し、その全てのフローを未配信（値「−」）にする。
Ｓ１０９として、配信ルータ４（Ｒ１）の配信管理部４３７は、他の配信ルータ４から配信テーブル４３３のエントリを取得するための要求パケット（ルータクエリ）を送信する。
Ｓ１１０として、配信ルータ４（Ｒ２）のフロー判定部４３２は、自装置内の配信テーブル４３３において、クエリアとセンダとを切り戻す。具体的には、フロー判定部４３２は、全フローのエントリに対してクエリアを再設定（Ｒ２→Ｒ１）するとともに、自装置が非配信のフローのエントリ（other）に対して、そのセンダをクエリアと同じ「Ｒ１」に設定する。
Ｓ１１１として、配信ルータ４（Ｒ２）の配信管理部４３７は、自装置の識別情報（ＩＰアドレスなど）と、配信中のフローの識別情報とを格納するルータクエリ応答を、Ｓ１０９でルータクエリを送信した配信ルータ４（Ｒ１）に応答する。
【００６０】
Ｓ１１２として、配信ルータ４（Ｒ１）のフロー判定部４３２は、共有セグメント５内の各配信ルータ４から、それぞれルータクエリの応答パケット（Ｓ１１１）を受信すると、その応答パケットから配信中のフローと配信ルータの情報を取り出し、自装置内の配信テーブル４３３へと取り出したエントリを追加する。
Ｓ１１３として、配信ルータ４（Ｒ１）のフロー判定部４３２は、配信中でないフローの中で、クエリアであるフローに対して、センダを自装置に切り戻して設定する。
【００６１】
【表３】
【００６２】
表３は、表２の状態後に配信ルータ４（Ｒ１）が障害復旧したときの（Ｓ１１３時点での）、各配信ルータ４の配信テーブル４３３を示す。
配信ルータ４（Ｒ１）内の配信テーブル４３３では、表２の配信ルータ４（Ｒ２）内の配信テーブル４３３の内容が、Ｓ１１１のルータクエリ応答で通知されて、登録されている。しかし、配信ルータ４（Ｒ１）はフローｆ１，ｆ２に対しては非センダであるので、配信はしない（配信列が「−」）。さらに、未配信フロー（配信列が「−」のフロー「other」）のセンダが配信ルータ４（Ｒ１）に切り戻されている（Ｓ１１３）。
配信ルータ４（Ｒ２）内の配信テーブル４３３では、表２の状態から、未配信フロー（配信列が「−」のフロー「other」）のセンダが配信ルータ４（Ｒ１）に切り戻されている（Ｓ１１０）。
【００６３】
【表４】
【００６４】
表４は、表３の状態後にフローｆ３の配信状態を「join」にしたときの、各配信ルータ４の配信テーブル４３３を示す。ｆ１とｆ２以外のフロー（表３のフロー「other」）であるフローｆ３の配信は、そのセンダかつクエリアである配信ルータ４（Ｒ１）が担当する（配信列が「○」）。
【００６５】
図４は、マルチキャスト配信システムの配信動作の後半（障害回復〜配信の切り戻し）の動作を示すフローチャートである。このフローチャートは、図３のＳ１１３の続きとして実行される。
【００６６】
Ｓ１１４として、配信ルータ４（Ｒ１）の配信管理部４３７は、クエリを送信する。
Ｓ１１５として、ホスト６は、リポート（ｆ１にjoin）を送信する。
Ｓ１１６として、配信ルータ４（Ｒ１）のフロー判定部４３２は、Ｓ１１６のjoinの受信処理（図５参照）を起動した結果、フローｆ１を未配信とする。
Ｓ１１７として、配信ルータ４（Ｒ２）のフロー判定部４３２は、Ｓ１１６のjoinの受信処理（図５参照）を起動した結果、フローｆ１を配信継続とする。
【００６７】
Ｓ１２１として、ホスト６は、リポート（ｆ１をleave）を送信する。
Ｓ１２２として、配信ルータ４（Ｒ１）のフロー判定部４３２は、Ｓ１２１のleaveの受信処理（図６参照）を起動した結果、Ｓ１２４で後記するセンダの切り戻し処理を起動する。
Ｓ１２３として、配信ルータ４（Ｒ２）のフロー判定部４３２は、Ｓ１２１のleaveの受信処理（図６参照）を起動した結果、フローｆ１の配信を停止する。
【００６８】
【表５】
【００６９】
Ｓ１２４として、配信ルータ４（Ｒ１，Ｒ２）のフロー判定部４３２は、センダの切り戻し処理をする（図７参照）。つまり、フローｆ１のセンダがＲ２からＲ１へと切り戻される。
表５は、表４の状態後にフローｆ１の配信状態を「leave」にしたとき（Ｓ１２４時点での）の、配信テーブル４３３を示す。
【００７０】
Ｓ１３１として、配信ルータ４（Ｒ１）の配信管理部４３７は、クエリを送信する。
Ｓ１３２として、ホスト６は、リポート（ｆ１にjoin）を送信する。
Ｓ１３３として、配信ルータ４（Ｒ１）のフロー判定部４３２は、Ｓ１３２のjoinの受信処理（図５参照）を起動した結果、フローｆ１の配信を開始とする。
【００７１】
【表６】
【００７２】
Ｓ１３４として、配信ルータ４（Ｒ２）のフロー判定部４３２は、Ｓ１３２のjoinの受信処理（図５参照）を起動した結果、フローｆ１を未配信とする。
表６は、表５の状態後にフローｆ１の配信状態を「join」にしたときの（Ｓ１３４時点での）、各配信ルータ４の配信テーブル４３３を示す。Ｓ１２４で切り戻されたセンダである配信ルータ４（Ｒ１）が、フローｆ１の配信を担当する（配信列が「○」）。
【００７３】
【表７】
【００７４】
表７は、表６の状態後にフローｆ２の配信状態を「leave」にしたときの、各配信ルータ４の配信テーブル４３３を示す。表５で示したフローｆ１と同様である。
【００７５】
【表８】
【００７６】
表８は、表７の状態後にフローｆ２の配信状態を「join」にしたときの、各配信ルータ４の配信テーブル４３３を示す。表６で示したフローｆ１と同様である。
【００７７】
以上説明したように、フローｆ１のセンダの切り戻し処理（Ｓ１２４）に伴う、フローｆ１の配信不可時間が発生したとしても、その切り戻し処理（Ｓ１２４）の実行を、フローｆ１の配信が不要な時間（配信状態「leave」であるＳ１２１〜Ｓ１３２の時間）内に収めることにより、ホスト６にとってフローｆ１の配信漏れや重複配信などの不安定な配信として意識させずに済む。
【００７８】
図５は、配信ルータ４がホスト６から「join」を受信したときの動作を示すフローチャートである。
Ｓ２０１として、配信管理部４３７は、自装置内の配信テーブル４３３の受信したレポート「join」に該当するエントリの配信状態を「join」に更新する。
Ｓ２０２として、フロー判定部４３２は、Ｓ２０１で更新したエントリのセンダが自装置か否かを判定する。Ｓ２０２でＹｅｓならＳ２０４に進み、ＮｏならＳ２０３に進む。
Ｓ２０３として、配信フィルタ部４３１は、Ｓ２０１で更新したエントリのフローの配信をせずに、処理を終了する。
Ｓ２０４として、フロー判定部４３２は、Ｓ２０１で更新したエントリの配信列が「○」（自装置が配信している）か否かを判定する。Ｓ２０４でＹｅｓならＳ２０５に進み、ＮｏならＳ２０６に進む。
Ｓ２０５として、配信フィルタ部４３１は、フローの配信を継続する（配信列への修正は不要）。
Ｓ２０６として、配信フィルタ部４３１は、フローの配信を開始する（配信列を「−」から「○」に修正する）。
【００７９】
図６は、配信ルータ４がホスト６から「leave」を受信したときの動作を示すフローチャートである。
【００８０】
Ｓ２１１として、配信管理部４３７は、自装置内の配信テーブル４３３を参照し、レポート「join」に該当するエントリの配信状態が「join」か否かを判定する。Ｓ２１１でＹｅｓならＳ２１２に進み、Ｎｏなら終了する。
Ｓ２１２として、配信管理部４３７は、共有セグメント５内に、Ｓ２１１で判定したフローの配信を要求するホスト６が、「leave」の送信元であるホスト６の他に存在するか否かを判定する。Ｓ２１２でＹｅｓならＳ２１３に進み、ＮｏならＳ２１４に進む。
【００８１】
なお、Ｓ２１２の判定を行うために、配信ルータ４は、以下の２つの処理のうちのいずれかの処理を行う。
（処理Ａ）ホストトラッキングとして、ホスト６から送信されるjoin／leaveレポートを、その送信元であるホスト６ごとに対応づけて記録する。
（処理Ｂ）ＭＬＤｖ２にはＭＡＳＳＱ（ＩＧＭＰｖ３の場合はＧＳＳＱに相当）というクエリが定義されている。ＭＡＳＳＱを利用したfast leaveでは、フローに対するleaveメッセージを配信ルータ４が受信した場合、当該インタフェースからleave要求のあったフロー情報を格納したＭＡＳＳＱを送信する。ＭＡＳＳＱを受信したホスト６は、ＭＡＳＳＱで指定されているフローの視聴中ならば、ルータに対してフローを視聴中であることを示すレポートを返信する。
【００８２】
Ｓ２１３として、配信管理部４３７は、Ｓ２１１で判定したフローの配信状態として、「join」を維持する。
Ｓ２１４として、配信管理部４３７は、配信状態を「join」から「leave」へと更新する。
【００８３】
Ｓ２１５として、フロー判定部４３２は、Ｓ２１１で判定したフローについて、自装置内の配信テーブル４３３を参照してそのフローのセンダとクエリアとを取得し、自装置が取得したセンダやクエリアに該当するか否かを判定する。
自装置がセンダに該当する場合（Ｓ２１５のルータ種別＝センダ）、自装置がクエリアに該当するか否かにかかわらず、Ｓ２１７に進む。
自装置がセンダに該当せず、かつ、クエリアに該当する場合（Ｓ２１５のルータ種別＝非センダ＆クエリア）、Ｓ２１６に進む。
自装置がセンダにもクエリアにも該当しない場合（Ｓ２１５のルータ種別＝その他）、処理を終了する。
Ｓ２１６として、フロー判定部４３２は、クエリアである自装置に、センダの役割をもたせるため、センダの切り戻し処理（図７参照）を起動する。
Ｓ２１７として、フロー判定部４３２は、自装置がセンダとして現在フローを配信しているか否かを、自装置内の配信テーブル４３３内の「配信」列を参照して判定する。Ｓ２１７でＹｅｓならＳ２１８に進み、Ｎｏなら終了する。
Ｓ２１８として、配信フィルタ部４３１は、フローの配信を停止する。
【００８４】
図７は、切り戻し処理を示すフローチャートである。このフローチャートは、図６のレポート「leave」で示されるフローを指定して、図６のＳ２１６から呼び出される処理である。
Ｓ３０１として、配信ルータ４（Ｒ１）のフロー判定部４３２は、指定されたフローの切り戻しReady信号を配信ルータ４（Ｒ２）に送信する。
Ｓ３０２として、配信ルータ４（Ｒ２）のフロー判定部４３２は、自装置内の配信テーブル４３３において、Ｓ３０１の切り戻しReady信号で指定されたフローのセンダを空欄にする。
Ｓ３０３として、配信ルータ４（Ｒ２）のフロー判定部４３２は、Ｓ３０２で空欄にしたように、センダの役割を放棄することを、切り戻し先の配信ルータ４（Ｒ１）へ通知する。
【００８５】
Ｓ３０４として、配信ルータ４（Ｒ１）のフロー判定部４３２は、Ｓ３０３の放棄通知を受信すると、自装置が指定されたフローのクエリアに該当するか否かを判定する。Ｓ３０４でＹｅｓならＳ３０５に進み、Ｎｏなら終了する。
Ｓ３０５として、配信ルータ４（Ｒ１）のフロー判定部４３２は、自装置内の配信テーブル４３３において、指定されたフローのセンダを自装置に設定する。
Ｓ３０６として、配信ルータ４（Ｒ１）のフロー判定部４３２は、フローのセンダの獲得通知信号をＳ３０３の送信元である配信ルータ４（Ｒ２）へと返信する。
Ｓ３０７として、配信ルータ４（Ｒ２）のフロー判定部４３２は、Ｓ３０６の返信を受信すると、そのセンダの獲得通知信号で指定された配信ルータ４（Ｒ１）を、指定されたフローのセンダにする旨を、自装置内の配信テーブル４３３に設定する。
【００８６】
以上説明した本実施形態では、配信ルータ４がＩＰマルチキャストの配信制御を行うにあたり、共有セグメント５に複数の配信ルータ４が冗長接続される構成において、配信ルータ４の障害復帰時におけるフロー配信を安定させることを特徴とする。
配信ルータ４は、切り戻し対象のフローごとの配信状態（配信テーブル４３３のjoin/leave）や配信しているか否か（配信テーブル４３３の配信列）を考慮しつつ、フロー配信が不要である時間帯まで待ってからフロー配信を停止し、その後に切り戻し制御を行うことにより、切り戻し制御に伴うホスト６のユーザへの影響を最小化する。
また、共有セグメント５上で、複数の配信ルータ４が同じデータを重複配信しないようにするため、切戻し元と切戻し先の配信ルータ４間で、お互いの制御過程を同期確認し合いながら、配信開始／配信停止の順序性が保たれた、切戻し制御を行う（図７参照）。
これにより、従来技術に比べて高品質かつ高信頼性なＩＰマルチキャストサービスが実現可能となるので、地上デジタルテレビ放送のＩＰ再送信サービスなどのような高付加価値のネットワークサービスを、ホスト６のユーザに提供することができる。
【符号の説明】
【００８７】
１ 配信サーバ
２ マルチキャスト配信網
３ リンク
４ 配信ルータ
５ 共有セグメント
６ ホスト
４１ ＭＣ配信網接続インタフェース
４２ ＭＣ配信網フレーム転送部
４３ 転送制御回路
４４ 共有セグメントフレーム転送部
４５ 共有セグメント接続インタフェース
４１１ 受信ＩＦ部
４１２ 送信ＩＦ部
４２１ フレーム受信部
４２２ フレーム送信部
４４１ フレーム送信部
４４２ フレーム受信部
４５１ 送信ＩＦ部
４５２ 受信ＩＦ部
４３１ 配信フィルタ部
４３２ フロー判定部
４３３ 配信テーブル
４３４ ルータ管理部
４３５ ルータ管理テーブル
４３７ 配信管理部
４３９ 上位連携部
【技術分野】
【０００１】
本発明は、マルチキャスト配信システム、配信ルータ、および、マルチキャスト配信方法に関する。
【背景技術】
【０００２】
ＩＰ（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）
【発明の概要】
【発明が解決しようとする課題】
【０００９】
共有セグメントに複数のルータが存在する場合、それらのうちの一部のルータの装置本体やルータに付属するネットワークインタフェースに障害が発生したときに、残りのルータがフロー配信を代行することで、配信制御を継続する。そして、障害が発生したルータが、障害から回復したときには、代行されていたフロー配信を再び担当する（切り戻す）ことで、正常時の状態に復帰する。ここで、障害から回復したルータにおけるフロー配信の復帰に伴い、その期間にフローの配信が不安定になる。
【００１０】
以下、同一セグメント内に、複数の配信ルータ（Ｒ１，Ｒ２）が存在するときの、３つの状態（状態１）〜（状態３）を順に説明する。
【００１１】
（状態１）配信ルータ（Ｒ１）の障害発生前の状態。配信ルータ（Ｒ１）がクエリアである。クエリア（Ｒ１）は、ＱＩ（Query Interval）時間間隔で周期的にクエリを送信する。ホストは、自らの配信要求を示すレポートを応答する。非クエリア（Ｒ２）は、タイマ上限値（以下、ＯＱＰＴ）を超過するまでにクエリを受信すれば、非クエリアの状態を維持して配信制御を行わない。
【００１２】
（状態２）配信ルータ（Ｒ１）の障害発生により他の正常なルータ（Ｒ２）へ配信制御を切り替えた状態。非クエリア（Ｒ２）は、クエリア（Ｒ１）からクエリを受信しなくなる。非クエリア（Ｒ２）は、自タイマがＯＱＰＴを超過すると、（Ｒ１）からクエリアを引き継ぎ、配信制御を再開する。
【００１３】
（状態３）配信ルータ（Ｒ１）の障害回復後に、ルータ（Ｒ２）から配信ルータ（Ｒ１）へと配信制御を切り戻す状態。クエリア選択アルゴリズムにより、ルータアドレスが最小ではないクエリア（Ｒ２）は非クエリアへ状態遷移して配信を停止する。これに対し、ルータアドレスが最小である配信ルータ（Ｒ１）は、再びクエリアとなり、ホストから配信要求を受信したことを契機に、配信を再開する。
【００１４】
従来技術（ＩＧＭＰｖ２／ＩＧＭＰｖ３／ＭＬＤｖ２）を用いるときには、（状態３）において、フローの配信が不安定になる。
【００１５】
図８は、フローの配信漏れが発生するまでの様子を示すフローチャートである。
Ｓ７００〜Ｓ７０４が、（状態２）に該当する。
Ｓ７００として、配信ルータ（Ｒ１）に、障害が発生する。Ｓ７０１として、配信ルータ（Ｒ２）は、クエリアに遷移すると、クエリをホストに送信する（Ｓ７０２）。Ｓ７０３として、ホストは、リポート（フローｆ１に対して配信要求を示す「join」を指定した内容を含む）を配信ルータ（Ｒ２）に送信する。Ｓ７０４として、配信ルータ（Ｒ２）は、リポートで指定されたフローｆ１を、ホストに配信する。
【００１６】
Ｓ７０５〜Ｓ７１４が、（状態３）に該当する。
Ｓ７０５として、配信ルータ（Ｒ１）は、障害から回復すると、クエリを送信する（Ｓ７１１）。
Ｓ７１２として、配信ルータ（Ｒ２）は、非クエリアに遷移（配信停止）する。
Ｓ７１３として、ホストは、リポート（ｆ１にjoin）を配信ルータ（Ｒ１）に送信する。
Ｓ７１４として、配信ルータ（Ｒ１）は、フローｆ１をホストに配信する。
【００１７】
ここで、Ｓ７１２からＳ７１４までの期間は、ホストにとっては、ｆ１にjoinしている（Ｓ７１３）にもかかわらず、どの配信ルータからもフローｆ１を受信できない期間（つまり、配信漏れの期間）である。
配信漏れの期間が発生する要因は、配信ルータ（Ｒ２）における個々のフローごとの配信状態が無視され、配信ルータ（Ｒ２）の状態がクエリアから非クエリアに遷移すれば、全てのフローのクエリアが無条件に配信ルータ（Ｒ１）切り戻されるためである。
【００１８】
図９は、フローの重複配信が発生するまでの様子を示すフローチャートである。Ｓ７００〜Ｓ７０５は、図８の動作と同じである。
Ｓ７２１として、配信ルータ（Ｒ１）は、クエリをホストおよび配信ルータ（Ｒ２）に送信する。
Ｓ７２２として、ホストは、リポート（ｆ１にjoin）を配信ルータ（Ｒ１）に送信する。
Ｓ７２３として、配信ルータ（Ｒ１）は、フローｆ１をホストに配信する。
Ｓ７２４として、配信ルータ（Ｒ２）は、Ｓ７２１の受信に伴い、非クエリアに遷移（配信停止）する。
【００１９】
ここで、Ｓ７２３からＳ７２４までの期間は、ホストにとっては、２台の配信ルータから、同じフローｆ１のデータが重複して配信されている期間である。
重複配信の期間が発生する要因は、個々のルータおよびホストが独立した制御動作を行うだけで、互いに同期制御を行っていないからである。図９に示すように、処理負荷の違いなどによりルータ間の配信制御の開始（Ｓ７２３）と停止（Ｓ７２４）との順序が逆転する場合には、重複配信が発生する。
【００２０】
そこで、本発明は、共有セグメントに複数のマルチキャスト配信ルータが接続される構成において、クエリアの障害回復時にもフロー配信を安定させることを、主な目的とする。
【課題を解決するための手段】
【００２１】
前記課題を解決するために、本発明は、配信サーバから配信ルータを介してホストにマルチキャストのフローを配信するマルチキャスト配信システムであって、複数台の前記配信ルータと１台以上のホストとが共有セグメントに接続され、その前記共有セグメントに送信されるパケットが、前記共有セグメントに接続される各装置が受信可能であり、前記配信ルータが、転送制御部と記憶手段とを有しており、前記配信ルータの記憶手段には、所定フローについて、正常時の配信担当を示すクエリアの配信ルータと、障害時の配信担当を示すセンダの配信ルータとが記憶されており、前記センダの配信ルータの転送制御部が、前記クエリアの配信ルータの障害復旧を検出するまでは、前記クエリアの配信ルータに代行して、前記所定フローを配信する処理を実行し、前記クエリアの配信ルータの障害復旧を検出した後で、前記所定フローを配信要求するホストが前記共有セグメント上で０台になったときに、前記所定フローを配信する処理を停止することを特徴とする。
【００２２】
これにより、配信ルータは、ホストにとってフロー配信が不要である時間帯として、所定フローを配信要求するホストが０台になる時間帯まで待ってからフローの配信を停止することにより、ホストのユーザへのフロー配信処理に対する影響を最小化する。
【００２３】
本発明は、前記クエリアの配信ルータの転送制御部が、前記センダの配信ルータの転送制御部からの前記所定フローを配信する処理が停止されたことを、前記センダの配信ルータから通知された後に、前記所定フローを配信する処理を再開することを特徴とする。
【００２４】
これにより、クエリアの配信ルータの配信再開が、センダの配信ルータの配信停止後になるので、クエリアとセンダとで同じコンテンツを重複配信することを防止できる。
【００２５】
本発明は、前記センダの配信ルータの転送制御部が、前記所定フローを配信する処理を停止する契機として、前記所定フローを配信要求するホストが前記共有セグメント上で０台になったとき、の代わりに、前記配信サーバから前記所定フローが配信されないときとすることを特徴とする。
【００２６】
これにより、配信ルータは、ホストにとってフロー配信が不要である時間帯として、所定フローが配信されない時間帯まで待ってからフローの配信を停止することにより、ホストのユーザへのフロー配信処理に対する影響を最小化する。
【００２７】
本発明は、前記センダの配信ルータの転送制御部が、前記所定フローを配信する処理を停止する契機として、前記所定フローを配信要求するホストが前記共有セグメント上で０台になったとき、の代わりに、前記所定フローとして配信されるコンテンツの優先度として、所定値よりも低い優先度が設定されているときとすることを特徴とする。
【００２８】
これにより、配信ルータは、比較的低い優先度のコンテンツが配信される時間帯まで待ってからフローの配信を停止することにより、ホストのユーザへのフロー配信処理に対する影響を少なくする。
【発明の効果】
【００２９】
本発明によれば、共有セグメントに複数のマルチキャスト配信ルータが接続される構成において、クエリアの障害回復時にもフロー配信を安定させることができる。
【図面の簡単な説明】
【００３０】
【図１】本発明の一実施形態に関するマルチキャスト配信システムを示す構成図である。
【図２】本発明の一実施形態に関する配信ルータを示す構成図である。
【図３】本発明の一実施形態に関するマルチキャスト配信システムの配信動作の前半（障害発生〜障害回復）の動作を示すフローチャートである。
【図４】本発明の一実施形態に関するマルチキャスト配信システムの配信動作の後半（障害回復〜配信の切り戻し）の動作を示すフローチャートである。
【図５】本発明の一実施形態に関する配信ルータがホストから「join」を受信したときの動作を示すフローチャートである。
【図６】本発明の一実施形態に関する配信ルータがホストから「leave」を受信したときの動作を示すフローチャートである。
【図７】本発明の一実施形態に関する切り戻し処理を示すフローチャートである。
【図８】フローの配信漏れが発生するまでの様子を示すフローチャートである。
【図９】フローの重複配信が発生するまでの様子を示すフローチャートである。
【発明を実施するための形態】
【００３１】
以下、本発明の一実施形態について、図面を参照して詳細に説明する。
【００３２】
図１は、マルチキャスト配信システムを示す構成図である。マルチキャストフロー（以下、単にフローとする）は、配信サーバ１から送信されて、マルチキャスト配信網２、リンク３、各配信ルータ４（Ｒ１，Ｒ２，Ｒ３）、共有セグメント５を経由して、各ホスト６（Ｈ１，Ｈ２，Ｈ３）に配信される。
これらのマルチキャスト配信システムの各装置は、ＣＰＵ（Central Processing Unit）とメモリとハードディスク（記憶手段）とネットワークインタフェースを有するコンピュータとして構成され、このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラムを実行することにより、各処理部を動作させる。
【００３３】
マルチキャスト配信網２は、例えば、インターネット網であり、配信サーバ１から配信ルータ４への経路決定のためのプロトコルとして、ＤＶＭＲＰ（Distance Vector Multicast Routing Protocol）や、ＰＩＭ−ＳＭ（Protocol Independent Multicast - Sparse Mode）、ＰＩＭ−ＳＳＭ（Protocol Independent Multicast - Source Specific Multicast）などが動作することを想定する。
共有セグメント５は、その共有セグメント５に接続される装置から送信されるパケットが、そのパケットの送信先だけでなく、同じ共有セグメント５に接続される他装置へも伝送される特性を有する。例えば、配信ルータ４（Ｒ１）からホスト６へ送信されるメッセージは、各ホスト６（Ｈ１，Ｈ２，Ｈ３）だけでなく、他の各配信ルータ４（Ｒ２，Ｒ３）も受信することができる。共有セグメント５は、例えば、イーサネット（登録商標）のＬＡＮ（Local Area Network）やアクセス集線スイッチ内のＶＬＡＮ（Virtual LAN）、スイッチ間を跨いだネットワークＶＬＡＮ(IEEE802.1adやIEEE802.1ahによるタグVLAN)等により構成される。
【００３４】
配信サーバ１は、フローの配信元となるサーバである。なお、フローの特定情報としては、フローのグループだけを特定情報とする（＊，ｇ）指定型であるＡＳＭ（Any Source Multicast）と、フローのグループとフローの送信元の配信サーバ１のアドレスの組を特定情報とする（ｓ，ｇ）指定型であるＳＳＭ（Source Specific Multicast）とが挙げられる。
以下、本実施形態では、フローの特定情報を（ｓ，ｇ）指定型として説明するが、（＊，ｇ）指定型にも本実施形態を応用することができる。ここで、（ｓ，ｇ）とは、（Source，Group）の略であり、最初のSourceが送信元の配信サーバ１のアドレスを示し、次のGroupがフローのグループを示す。
【００３５】
配信ルータ４は、マルチキャストのグループ管理プロトコル（ＩＧＭＰおよびＭＬＤのプロトコルなど）が動作するルータであり、配信サーバ１からの配信データを、ホスト６に転送する。配信ルータ４は、リンク３を介して、マルチキャスト配信網２と接続されている。
ホスト６は、配信ルータ４から配信データを受信する端末であり、リスナ（listener）とも呼ばれる。ホスト６は、配信ルータ４からのクエリを受信すると、自装置が希望するフローの情報を含めたレポートを作成し、配信ルータ４に返信する。
【００３６】
図２は、配信ルータ４を示す構成図である。
配信ルータ４は、フローの上流側（マルチキャスト配信網２の側）から順に、ＭＣ配信網接続インタフェース４１、ＭＣ配信網フレーム転送部４２、転送制御回路４３、共有セグメントフレーム転送部４４、共有セグメント接続インタフェース４５が接続されて構成される。
【００３７】
インタフェース（ＭＣ配信網接続インタフェース４１、共有セグメント接続インタフェース４５）は、ネットワークが接続される端点となる箇所であり、外部の網からデータを受信するインタフェース（受信ＩＦ部４１１，４５２）と、外部の網にデータを送信するインタフェース（送信ＩＦ部４５１，４１２）とから構成される。これらのインタフェースは、例えば、イーサネットのＰＨＹ層（Physical Layer）に実装される。
【００３８】
フレーム転送部（ＭＣ配信網フレーム転送部４２、共有セグメントフレーム転送部４４）は、インタフェースが送受信するデータの信号をフレーム単位に変換する処理部であり、受信インタフェースからの通信信号からフレームを構築する受信部（フレーム受信部４４２，４２１）と、構築されたフレームから送信インタフェースを介して送信する通信信号へとデコードする送信部（フレーム送信部４４１，４２２）とから構成される。これらのフレーム転送部は、例えば、イーサネットのＭＡＣ層（Media Access Control Layer）に実装される。
【００３９】
上流（配信サーバ１）から下流（ホスト６）に流れる下りのパケット（マルチキャストフローなど）は、受信ＩＦ部４１１→フレーム受信部４２１→配信フィルタ部４３１→フレーム送信部４４１→送信ＩＦ部４５１の順に、配信ルータ４内を通過する。
下流（ホスト６）から上流（配信サーバ１）に流れる上りのパケット（レポート（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演算）である。
このように、フローごとにクエリアを特定することで、共有セグメント５内に複数のフローが配信されるときに、そのフローごとの配信担当となるクエリアが負荷分散されるので、フローの配信漏れや重複配信を抑制しつつ、共有セグメント全体のフローのスループットを向上させることができる。
さらに、ルータ管理部４３４は、管理者から手動で設定された配信ルータ４をクエリアとするなど、任意のクエリア選択アルゴリズムを用いてもよい。
【００４９】
【表１】
【００５０】
表１は、配信ルータ４（Ｒ１）が正常時であるときの、各配信ルータ４の配信テーブル４３３を示す。なお、ホスト６からのレポートが、同じ共有セグメント５に属する各配信ルータ４に届くため、それらの各配信ルータ４内の配信テーブル４３３のデータ内容は、互いに同じものである。
配信テーブル４３３の左側の３列（フロー，Ｓ，Ｇ）について、フロー列、Ｓ列、Ｇ列は、フローの特定情報が（Ｓ，Ｇ）であることを示している。
配信テーブル４３３の中央の２列（センダ、クエリア）は、対応するフローについての配信ルータ４の役割を示す。配信テーブル４３３では、共有セグメント５内でのクエリアに該当する配信ルータ４に加え、そのクエリアよりも強い（優先される）配信権利を有するセンダ（Sender）が、フローごとに対応づけられている。例えば、クエリアかつセンダである配信ルータ４（Ｒ１）は、２つのフロー（ｆ１、ｆ２）を配信している。
【００５１】
なお、クエリアかつセンダそれぞれの役割は、障害の前後で以下のように引き継がれる。
・配信ルータ４（Ｒ１）の障害前は、クエリアとセンダとが同一の配信ルータ４（Ｒ１）に割り当てられている。
・配信ルータ４（Ｒ１）の障害中は、配信ルータ４（Ｒ２）がクエリアとセンダとの役割を配信ルータ４（Ｒ１）から代行する。
・クエリアの障害回復後は、クエリアを配信ルータ４（Ｒ２）から配信ルータ４（Ｒ１）へとすぐに引き継ぐ。一方、センダの配信ルータ４（Ｒ２）は、ホスト６のユーザに影響しない（または影響が少ない）時間帯まで待ってからフローの配信を停止し、その停止後に、センダを配信ルータ４（Ｒ１）へと引き継ぐ。
【００５２】
ここで、以下の説明では、センダの配信ルータ４（Ｒ２）から配信ルータ４（Ｒ１）への引き継ぎの契機として、「フローを視聴するメンバが０人（マルチキャストグループへの参加人数が０人）になる時間帯」、すなわち、「フローを配信要求するホスト６が共有セグメント５上で０台になる時間帯」を例示するが、その他にも、以下の時間帯としてもよい。
・フローを視聴するメンバが、所定数以下（例えば、３人以下）になる時間帯
・フローを視聴するメンバがいたとしても、上流側からフローが配信されない時間帯（深夜などの放送休止時間）
・フローのコンテンツとして、コンテンツ優先度が所定値より低い内容（無料放送など）が流れている時間帯。一方、コンテンツ優先度が所定値より高い内容（有料放送など）が流れている時間は、センダの引き継ぎ時間帯からは除外する。
【００５３】
配信テーブル４３３の右側の２列（配信状態、配信）は、対応するフローについての配信処理を説明するものである。
配信状態「join」とは、対応するフローの配信を希望する（換言すると、マルチキャストグループへ参加する）ホストが、共有セグメント５内に１台以上存在することを示す。
配信状態「leave」とは、対応するフローの配信を希望する（換言すると、マルチキャストグループへ参加する）ホストが、共有セグメント５内に０台である（換言すると、マルチキャストグループへの離脱）ことを示す。
「配信」列は、その列の配信テーブル４３３を収容する配信ルータ４が、対応するフローについて実際に配信しているか（「○」）否か（「−」）を示す。例えば、フローｆ１は、配信希望（join）されているため、配信ルータ４（Ｒ１）が配信し、配信ルータ４（Ｒ２）は配信しない。
つまり、一般的に、配信状態「join」であるときには、１台の配信ルータ４がフローの配信をすることで重複配信を抑制し、配信状態「leave」であるときには、フローの配信をする必要がないので、全ての配信ルータ４がフローの配信をしない。
【００５４】
図３は、マルチキャスト配信システムの配信動作の前半（障害発生〜障害回復）の動作を示すフローチャートである。このフローチャートを開始する前の各配信ルータ４内の配信テーブル４３３の内容は、表１に示したとおりである。
【００５５】
以下、フローチャートの送信処理の説明からは、その送信先の装置の記載を適宜省略する。図１で説明したように、送信先を明示的に指定しないメッセージが送信されていても、そのメッセージは共有セグメント５上を流れるので、その共有セグメント５に接続される各装置（配信ルータ４、ホスト６）が受信可能である（送信先となりうる）。
【００５６】
Ｓ１００として、配信ルータ４（Ｒ１）に障害が発生すると、フローｆ１などの各フローの配信が中断されてしまう（Ｓ１０１）。
Ｓ１０２として、配信ルータ４（Ｒ２）のフロー判定部４３２は、クエリアとセンダとの役割を配信ルータ４（Ｒ１）から代行する。そのため、配信ルータ４（Ｒ２）内のＧＱ死活監視用のタイマは、時間経過にしたがってタイマ値を増加させるとともに、配信ルータ４（Ｒ１）からのＧＱ受信によりタイマ値を０にリセットする。そして、タイマ値が所定しきい値（ＯＱＰＴ）を超過したときに、配信ルータ４（Ｒ２）は、Ｓ１０２の代行処理を起動させる。
Ｓ１０４として、配信ルータ４（Ｒ２）の配信管理部４３７は、クエリを送信する。
Ｓ１０５として、ホスト６は、リポート（ｆ１にjoin）を送信する。
Ｓ１０６として、配信ルータ４（Ｒ２）のフロー判定部４３２は、Ｓ１０５のjoinの受信処理（図５参照）を起動し、その結果としてフローｆ１の配信を開始する。
【００５７】
【表２】
【００５８】
表２は、表１の状態後に配信ルータ４（Ｒ１）が障害中であるときの（Ｓ１０６時点での）、各配信ルータ４の配信テーブル４３３を示す。
配信ルータ４（Ｒ１）内の配信テーブル４３３では、全フロー（any）の配信が不可（down）であり、センダもクエリアも自装置ではない（値「−」）。
配信ルータ４（Ｒ２）内の配信テーブル４３３では、表１の配信ルータ４（Ｒ１）内の配信テーブル４３３の内容を引き継いでいる。なお、表２におけるセンダ「Ｒ１→Ｒ２」という表記は、センダがＲ１からＲ２へと変更されたことを示す。
【００５９】
Ｓ１０７として、配信ルータ４（Ｒ１）は、障害回復すると、その障害回復に伴う各配信ルータ４内の配信テーブル４３３の更新処理（Ｓ１０８〜Ｓ１１３）が実行される。
Ｓ１０８として、配信ルータ４（Ｒ１）のフロー判定部４３２は、配信テーブル４３３を新規生成し、その全てのフローを未配信（値「−」）にする。
Ｓ１０９として、配信ルータ４（Ｒ１）の配信管理部４３７は、他の配信ルータ４から配信テーブル４３３のエントリを取得するための要求パケット（ルータクエリ）を送信する。
Ｓ１１０として、配信ルータ４（Ｒ２）のフロー判定部４３２は、自装置内の配信テーブル４３３において、クエリアとセンダとを切り戻す。具体的には、フロー判定部４３２は、全フローのエントリに対してクエリアを再設定（Ｒ２→Ｒ１）するとともに、自装置が非配信のフローのエントリ（other）に対して、そのセンダをクエリアと同じ「Ｒ１」に設定する。
Ｓ１１１として、配信ルータ４（Ｒ２）の配信管理部４３７は、自装置の識別情報（ＩＰアドレスなど）と、配信中のフローの識別情報とを格納するルータクエリ応答を、Ｓ１０９でルータクエリを送信した配信ルータ４（Ｒ１）に応答する。
【００６０】
Ｓ１１２として、配信ルータ４（Ｒ１）のフロー判定部４３２は、共有セグメント５内の各配信ルータ４から、それぞれルータクエリの応答パケット（Ｓ１１１）を受信すると、その応答パケットから配信中のフローと配信ルータの情報を取り出し、自装置内の配信テーブル４３３へと取り出したエントリを追加する。
Ｓ１１３として、配信ルータ４（Ｒ１）のフロー判定部４３２は、配信中でないフローの中で、クエリアであるフローに対して、センダを自装置に切り戻して設定する。
【００６１】
【表３】
【００６２】
表３は、表２の状態後に配信ルータ４（Ｒ１）が障害復旧したときの（Ｓ１１３時点での）、各配信ルータ４の配信テーブル４３３を示す。
配信ルータ４（Ｒ１）内の配信テーブル４３３では、表２の配信ルータ４（Ｒ２）内の配信テーブル４３３の内容が、Ｓ１１１のルータクエリ応答で通知されて、登録されている。しかし、配信ルータ４（Ｒ１）はフローｆ１，ｆ２に対しては非センダであるので、配信はしない（配信列が「−」）。さらに、未配信フロー（配信列が「−」のフロー「other」）のセンダが配信ルータ４（Ｒ１）に切り戻されている（Ｓ１１３）。
配信ルータ４（Ｒ２）内の配信テーブル４３３では、表２の状態から、未配信フロー（配信列が「−」のフロー「other」）のセンダが配信ルータ４（Ｒ１）に切り戻されている（Ｓ１１０）。
【００６３】
【表４】
【００６４】
表４は、表３の状態後にフローｆ３の配信状態を「join」にしたときの、各配信ルータ４の配信テーブル４３３を示す。ｆ１とｆ２以外のフロー（表３のフロー「other」）であるフローｆ３の配信は、そのセンダかつクエリアである配信ルータ４（Ｒ１）が担当する（配信列が「○」）。
【００６５】
図４は、マルチキャスト配信システムの配信動作の後半（障害回復〜配信の切り戻し）の動作を示すフローチャートである。このフローチャートは、図３のＳ１１３の続きとして実行される。
【００６６】
Ｓ１１４として、配信ルータ４（Ｒ１）の配信管理部４３７は、クエリを送信する。
Ｓ１１５として、ホスト６は、リポート（ｆ１にjoin）を送信する。
Ｓ１１６として、配信ルータ４（Ｒ１）のフロー判定部４３２は、Ｓ１１６のjoinの受信処理（図５参照）を起動した結果、フローｆ１を未配信とする。
Ｓ１１７として、配信ルータ４（Ｒ２）のフロー判定部４３２は、Ｓ１１６のjoinの受信処理（図５参照）を起動した結果、フローｆ１を配信継続とする。
【００６７】
Ｓ１２１として、ホスト６は、リポート（ｆ１をleave）を送信する。
Ｓ１２２として、配信ルータ４（Ｒ１）のフロー判定部４３２は、Ｓ１２１のleaveの受信処理（図６参照）を起動した結果、Ｓ１２４で後記するセンダの切り戻し処理を起動する。
Ｓ１２３として、配信ルータ４（Ｒ２）のフロー判定部４３２は、Ｓ１２１のleaveの受信処理（図６参照）を起動した結果、フローｆ１の配信を停止する。
【００６８】
【表５】
【００６９】
Ｓ１２４として、配信ルータ４（Ｒ１，Ｒ２）のフロー判定部４３２は、センダの切り戻し処理をする（図７参照）。つまり、フローｆ１のセンダがＲ２からＲ１へと切り戻される。
表５は、表４の状態後にフローｆ１の配信状態を「leave」にしたとき（Ｓ１２４時点での）の、配信テーブル４３３を示す。
【００７０】
Ｓ１３１として、配信ルータ４（Ｒ１）の配信管理部４３７は、クエリを送信する。
Ｓ１３２として、ホスト６は、リポート（ｆ１にjoin）を送信する。
Ｓ１３３として、配信ルータ４（Ｒ１）のフロー判定部４３２は、Ｓ１３２のjoinの受信処理（図５参照）を起動した結果、フローｆ１の配信を開始とする。
【００７１】
【表６】
【００７２】
Ｓ１３４として、配信ルータ４（Ｒ２）のフロー判定部４３２は、Ｓ１３２のjoinの受信処理（図５参照）を起動した結果、フローｆ１を未配信とする。
表６は、表５の状態後にフローｆ１の配信状態を「join」にしたときの（Ｓ１３４時点での）、各配信ルータ４の配信テーブル４３３を示す。Ｓ１２４で切り戻されたセンダである配信ルータ４（Ｒ１）が、フローｆ１の配信を担当する（配信列が「○」）。
【００７３】
【表７】
【００７４】
表７は、表６の状態後にフローｆ２の配信状態を「leave」にしたときの、各配信ルータ４の配信テーブル４３３を示す。表５で示したフローｆ１と同様である。
【００７５】
【表８】
【００７６】
表８は、表７の状態後にフローｆ２の配信状態を「join」にしたときの、各配信ルータ４の配信テーブル４３３を示す。表６で示したフローｆ１と同様である。
【００７７】
以上説明したように、フローｆ１のセンダの切り戻し処理（Ｓ１２４）に伴う、フローｆ１の配信不可時間が発生したとしても、その切り戻し処理（Ｓ１２４）の実行を、フローｆ１の配信が不要な時間（配信状態「leave」であるＳ１２１〜Ｓ１３２の時間）内に収めることにより、ホスト６にとってフローｆ１の配信漏れや重複配信などの不安定な配信として意識させずに済む。
【００７８】
図５は、配信ルータ４がホスト６から「join」を受信したときの動作を示すフローチャートである。
Ｓ２０１として、配信管理部４３７は、自装置内の配信テーブル４３３の受信したレポート「join」に該当するエントリの配信状態を「join」に更新する。
Ｓ２０２として、フロー判定部４３２は、Ｓ２０１で更新したエントリのセンダが自装置か否かを判定する。Ｓ２０２でＹｅｓならＳ２０４に進み、ＮｏならＳ２０３に進む。
Ｓ２０３として、配信フィルタ部４３１は、Ｓ２０１で更新したエントリのフローの配信をせずに、処理を終了する。
Ｓ２０４として、フロー判定部４３２は、Ｓ２０１で更新したエントリの配信列が「○」（自装置が配信している）か否かを判定する。Ｓ２０４でＹｅｓならＳ２０５に進み、ＮｏならＳ２０６に進む。
Ｓ２０５として、配信フィルタ部４３１は、フローの配信を継続する（配信列への修正は不要）。
Ｓ２０６として、配信フィルタ部４３１は、フローの配信を開始する（配信列を「−」から「○」に修正する）。
【００７９】
図６は、配信ルータ４がホスト６から「leave」を受信したときの動作を示すフローチャートである。
【００８０】
Ｓ２１１として、配信管理部４３７は、自装置内の配信テーブル４３３を参照し、レポート「join」に該当するエントリの配信状態が「join」か否かを判定する。Ｓ２１１でＹｅｓならＳ２１２に進み、Ｎｏなら終了する。
Ｓ２１２として、配信管理部４３７は、共有セグメント５内に、Ｓ２１１で判定したフローの配信を要求するホスト６が、「leave」の送信元であるホスト６の他に存在するか否かを判定する。Ｓ２１２でＹｅｓならＳ２１３に進み、ＮｏならＳ２１４に進む。
【００８１】
なお、Ｓ２１２の判定を行うために、配信ルータ４は、以下の２つの処理のうちのいずれかの処理を行う。
（処理Ａ）ホストトラッキングとして、ホスト６から送信されるjoin／leaveレポートを、その送信元であるホスト６ごとに対応づけて記録する。
（処理Ｂ）ＭＬＤｖ２にはＭＡＳＳＱ（ＩＧＭＰｖ３の場合はＧＳＳＱに相当）というクエリが定義されている。ＭＡＳＳＱを利用したfast leaveでは、フローに対するleaveメッセージを配信ルータ４が受信した場合、当該インタフェースからleave要求のあったフロー情報を格納したＭＡＳＳＱを送信する。ＭＡＳＳＱを受信したホスト６は、ＭＡＳＳＱで指定されているフローの視聴中ならば、ルータに対してフローを視聴中であることを示すレポートを返信する。
【００８２】
Ｓ２１３として、配信管理部４３７は、Ｓ２１１で判定したフローの配信状態として、「join」を維持する。
Ｓ２１４として、配信管理部４３７は、配信状態を「join」から「leave」へと更新する。
【００８３】
Ｓ２１５として、フロー判定部４３２は、Ｓ２１１で判定したフローについて、自装置内の配信テーブル４３３を参照してそのフローのセンダとクエリアとを取得し、自装置が取得したセンダやクエリアに該当するか否かを判定する。
自装置がセンダに該当する場合（Ｓ２１５のルータ種別＝センダ）、自装置がクエリアに該当するか否かにかかわらず、Ｓ２１７に進む。
自装置がセンダに該当せず、かつ、クエリアに該当する場合（Ｓ２１５のルータ種別＝非センダ＆クエリア）、Ｓ２１６に進む。
自装置がセンダにもクエリアにも該当しない場合（Ｓ２１５のルータ種別＝その他）、処理を終了する。
Ｓ２１６として、フロー判定部４３２は、クエリアである自装置に、センダの役割をもたせるため、センダの切り戻し処理（図７参照）を起動する。
Ｓ２１７として、フロー判定部４３２は、自装置がセンダとして現在フローを配信しているか否かを、自装置内の配信テーブル４３３内の「配信」列を参照して判定する。Ｓ２１７でＹｅｓならＳ２１８に進み、Ｎｏなら終了する。
Ｓ２１８として、配信フィルタ部４３１は、フローの配信を停止する。
【００８４】
図７は、切り戻し処理を示すフローチャートである。このフローチャートは、図６のレポート「leave」で示されるフローを指定して、図６のＳ２１６から呼び出される処理である。
Ｓ３０１として、配信ルータ４（Ｒ１）のフロー判定部４３２は、指定されたフローの切り戻しReady信号を配信ルータ４（Ｒ２）に送信する。
Ｓ３０２として、配信ルータ４（Ｒ２）のフロー判定部４３２は、自装置内の配信テーブル４３３において、Ｓ３０１の切り戻しReady信号で指定されたフローのセンダを空欄にする。
Ｓ３０３として、配信ルータ４（Ｒ２）のフロー判定部４３２は、Ｓ３０２で空欄にしたように、センダの役割を放棄することを、切り戻し先の配信ルータ４（Ｒ１）へ通知する。
【００８５】
Ｓ３０４として、配信ルータ４（Ｒ１）のフロー判定部４３２は、Ｓ３０３の放棄通知を受信すると、自装置が指定されたフローのクエリアに該当するか否かを判定する。Ｓ３０４でＹｅｓならＳ３０５に進み、Ｎｏなら終了する。
Ｓ３０５として、配信ルータ４（Ｒ１）のフロー判定部４３２は、自装置内の配信テーブル４３３において、指定されたフローのセンダを自装置に設定する。
Ｓ３０６として、配信ルータ４（Ｒ１）のフロー判定部４３２は、フローのセンダの獲得通知信号をＳ３０３の送信元である配信ルータ４（Ｒ２）へと返信する。
Ｓ３０７として、配信ルータ４（Ｒ２）のフロー判定部４３２は、Ｓ３０６の返信を受信すると、そのセンダの獲得通知信号で指定された配信ルータ４（Ｒ１）を、指定されたフローのセンダにする旨を、自装置内の配信テーブル４３３に設定する。
【００８６】
以上説明した本実施形態では、配信ルータ４がＩＰマルチキャストの配信制御を行うにあたり、共有セグメント５に複数の配信ルータ４が冗長接続される構成において、配信ルータ４の障害復帰時におけるフロー配信を安定させることを特徴とする。
配信ルータ４は、切り戻し対象のフローごとの配信状態（配信テーブル４３３のjoin/leave）や配信しているか否か（配信テーブル４３３の配信列）を考慮しつつ、フロー配信が不要である時間帯まで待ってからフロー配信を停止し、その後に切り戻し制御を行うことにより、切り戻し制御に伴うホスト６のユーザへの影響を最小化する。
また、共有セグメント５上で、複数の配信ルータ４が同じデータを重複配信しないようにするため、切戻し元と切戻し先の配信ルータ４間で、お互いの制御過程を同期確認し合いながら、配信開始／配信停止の順序性が保たれた、切戻し制御を行う（図７参照）。
これにより、従来技術に比べて高品質かつ高信頼性なＩＰマルチキャストサービスが実現可能となるので、地上デジタルテレビ放送のＩＰ再送信サービスなどのような高付加価値のネットワークサービスを、ホスト６のユーザに提供することができる。
【符号の説明】
【００８７】
１ 配信サーバ
２ マルチキャスト配信網
３ リンク
４ 配信ルータ
５ 共有セグメント
６ ホスト
４１ ＭＣ配信網接続インタフェース
４２ ＭＣ配信網フレーム転送部
４３ 転送制御回路
４４ 共有セグメントフレーム転送部
４５ 共有セグメント接続インタフェース
４１１ 受信ＩＦ部
４１２ 送信ＩＦ部
４２１ フレーム受信部
４２２ フレーム送信部
４４１ フレーム送信部
４４２ フレーム受信部
４５１ 送信ＩＦ部
４５２ 受信ＩＦ部
４３１ 配信フィルタ部
４３２ フロー判定部
４３３ 配信テーブル
４３４ ルータ管理部
４３５ ルータ管理テーブル
４３７ 配信管理部
４３９ 上位連携部
【特許請求の範囲】
【請求項１】
配信サーバから配信ルータを介してホストにマルチキャストのフローを配信するマルチキャスト配信システムであって、
複数台の前記配信ルータと１台以上のホストとが共有セグメントに接続され、その前記共有セグメントに送信されるパケットは、前記共有セグメントに接続される各装置が受信可能であり、
前記配信ルータは、転送制御部と記憶手段とを有しており、
前記配信ルータの記憶手段には、所定フローについて、正常時の配信担当を示すクエリアの配信ルータと、障害時の配信担当を示すセンダの配信ルータとが記憶されており、
前記センダの配信ルータの転送制御部は、
前記クエリアの配信ルータの障害復旧を検出するまでは、前記クエリアの配信ルータに代行して、前記所定フローを配信する処理を実行し、
前記クエリアの配信ルータの障害復旧を検出した後で、前記所定フローを配信要求するホストが前記共有セグメント上で０台になったときに、前記所定フローを配信する処理を停止することを特徴とする
マルチキャスト配信システム。
【請求項２】
前記クエリアの配信ルータの転送制御部は、前記センダの配信ルータの転送制御部からの前記所定フローを配信する処理が停止されたことを、前記センダの配信ルータから通知された後に、前記所定フローを配信する処理を再開することを特徴とする
請求項１に記載のマルチキャスト配信システム。
【請求項３】
前記センダの配信ルータの転送制御部は、前記所定フローを配信する処理を停止する契機として、前記所定フローを配信要求するホストが前記共有セグメント上で０台になったとき、の代わりに、前記配信サーバから前記所定フローが配信されないときとすることを特徴とする
請求項１または請求項２に記載のマルチキャスト配信システム。
【請求項４】
前記センダの配信ルータの転送制御部は、前記所定フローを配信する処理を停止する契機として、前記所定フローを配信要求するホストが前記共有セグメント上で０台になったとき、の代わりに、前記所定フローとして配信されるコンテンツの優先度として、所定値よりも低い優先度が設定されているときとすることを特徴とする
請求項１または請求項２に記載のマルチキャスト配信システム。
【請求項５】
配信サーバから配信ルータを介してホストにマルチキャストのフローを配信するマルチキャスト配信システムに用いられる配信ルータであって、
複数台の前記配信ルータと１台以上のホストとが共有セグメントに接続され、その前記共有セグメントに送信されるパケットは、前記共有セグメントに接続される各装置が受信可能であり、
前記配信ルータは、転送制御部と記憶手段とを有しており、
前記配信ルータの記憶手段には、所定フローについて、正常時の配信担当を示すクエリアの配信ルータと、障害時の配信担当を示すセンダの配信ルータとが記憶されており、
自身の配信ルータが前記センダの配信ルータであるとき、自身の前記転送制御部は、
前記クエリアの配信ルータの障害復旧を検出するまでは、前記クエリアの配信ルータに代行して、前記所定フローを配信する処理を実行し、
前記クエリアの配信ルータの障害復旧を検出した後で、前記所定フローを配信要求するホストが前記共有セグメント上で０台になったときに、前記所定フローを配信する処理を停止することを特徴とする
配信ルータ。
【請求項６】
自身の配信ルータが前記クエリアの配信ルータであるとき、自身の前記転送制御部は、前記センダの配信ルータの転送制御部からの前記所定フローを配信する処理が停止されたことを、前記センダの配信ルータから通知された後に、前記所定フローを配信する処理を再開することを特徴とする
請求項５に記載の配信ルータ。
【請求項７】
自身の配信ルータが前記センダの配信ルータであるとき、自身の前記転送制御部は、前記所定フローを配信する処理を停止する契機として、前記所定フローを配信要求するホストが前記共有セグメント上で０台になったとき、の代わりに、前記配信サーバから前記所定フローが配信されないときとすることを特徴とする
請求項５または請求項６に記載の配信ルータ。
【請求項８】
自身の配信ルータが前記センダの配信ルータであるとき、自身の前記転送制御部は、前記所定フローを配信する処理を停止する契機として、前記所定フローを配信要求するホストが前記共有セグメント上で０台になったとき、の代わりに、前記所定フローとして配信されるコンテンツの優先度として、所定値よりも低い優先度が設定されているときとすることを特徴とする
請求項５または請求項６に記載の配信ルータ。
【請求項９】
配信サーバから配信ルータを介してホストにマルチキャストのフローを配信するマルチキャスト配信システムが実行するマルチキャスト配信方法であって、
複数台の前記配信ルータと１台以上のホストとが共有セグメントに接続され、その前記共有セグメントに送信されるパケットは、前記共有セグメントに接続される各装置が受信可能であり、
前記配信ルータは、転送制御部と記憶手段とを有しており、
前記配信ルータの記憶手段には、所定フローについて、正常時の配信担当を示すクエリアの配信ルータと、障害時の配信担当を示すセンダの配信ルータとが記憶されており、
前記センダの配信ルータの転送制御部は、
前記クエリアの配信ルータの障害復旧を検出するまでは、前記クエリアの配信ルータに代行して、前記所定フローを配信する処理を実行し、
前記クエリアの配信ルータの障害復旧を検出した後で、前記所定フローを配信要求するホストが前記共有セグメント上で０台になったときに、前記所定フローを配信する処理を停止することを特徴とする
マルチキャスト配信方法。
【請求項１０】
前記クエリアの配信ルータの転送制御部は、前記センダの配信ルータの転送制御部からの前記所定フローを配信する処理が停止されたことを、前記センダの配信ルータから通知された後に、前記所定フローを配信する処理を再開することを特徴とする
請求項９に記載のマルチキャスト配信方法。
【請求項１】
配信サーバから配信ルータを介してホストにマルチキャストのフローを配信するマルチキャスト配信システムであって、
複数台の前記配信ルータと１台以上のホストとが共有セグメントに接続され、その前記共有セグメントに送信されるパケットは、前記共有セグメントに接続される各装置が受信可能であり、
前記配信ルータは、転送制御部と記憶手段とを有しており、
前記配信ルータの記憶手段には、所定フローについて、正常時の配信担当を示すクエリアの配信ルータと、障害時の配信担当を示すセンダの配信ルータとが記憶されており、
前記センダの配信ルータの転送制御部は、
前記クエリアの配信ルータの障害復旧を検出するまでは、前記クエリアの配信ルータに代行して、前記所定フローを配信する処理を実行し、
前記クエリアの配信ルータの障害復旧を検出した後で、前記所定フローを配信要求するホストが前記共有セグメント上で０台になったときに、前記所定フローを配信する処理を停止することを特徴とする
マルチキャスト配信システム。
【請求項２】
前記クエリアの配信ルータの転送制御部は、前記センダの配信ルータの転送制御部からの前記所定フローを配信する処理が停止されたことを、前記センダの配信ルータから通知された後に、前記所定フローを配信する処理を再開することを特徴とする
請求項１に記載のマルチキャスト配信システム。
【請求項３】
前記センダの配信ルータの転送制御部は、前記所定フローを配信する処理を停止する契機として、前記所定フローを配信要求するホストが前記共有セグメント上で０台になったとき、の代わりに、前記配信サーバから前記所定フローが配信されないときとすることを特徴とする
請求項１または請求項２に記載のマルチキャスト配信システム。
【請求項４】
前記センダの配信ルータの転送制御部は、前記所定フローを配信する処理を停止する契機として、前記所定フローを配信要求するホストが前記共有セグメント上で０台になったとき、の代わりに、前記所定フローとして配信されるコンテンツの優先度として、所定値よりも低い優先度が設定されているときとすることを特徴とする
請求項１または請求項２に記載のマルチキャスト配信システム。
【請求項５】
配信サーバから配信ルータを介してホストにマルチキャストのフローを配信するマルチキャスト配信システムに用いられる配信ルータであって、
複数台の前記配信ルータと１台以上のホストとが共有セグメントに接続され、その前記共有セグメントに送信されるパケットは、前記共有セグメントに接続される各装置が受信可能であり、
前記配信ルータは、転送制御部と記憶手段とを有しており、
前記配信ルータの記憶手段には、所定フローについて、正常時の配信担当を示すクエリアの配信ルータと、障害時の配信担当を示すセンダの配信ルータとが記憶されており、
自身の配信ルータが前記センダの配信ルータであるとき、自身の前記転送制御部は、
前記クエリアの配信ルータの障害復旧を検出するまでは、前記クエリアの配信ルータに代行して、前記所定フローを配信する処理を実行し、
前記クエリアの配信ルータの障害復旧を検出した後で、前記所定フローを配信要求するホストが前記共有セグメント上で０台になったときに、前記所定フローを配信する処理を停止することを特徴とする
配信ルータ。
【請求項６】
自身の配信ルータが前記クエリアの配信ルータであるとき、自身の前記転送制御部は、前記センダの配信ルータの転送制御部からの前記所定フローを配信する処理が停止されたことを、前記センダの配信ルータから通知された後に、前記所定フローを配信する処理を再開することを特徴とする
請求項５に記載の配信ルータ。
【請求項７】
自身の配信ルータが前記センダの配信ルータであるとき、自身の前記転送制御部は、前記所定フローを配信する処理を停止する契機として、前記所定フローを配信要求するホストが前記共有セグメント上で０台になったとき、の代わりに、前記配信サーバから前記所定フローが配信されないときとすることを特徴とする
請求項５または請求項６に記載の配信ルータ。
【請求項８】
自身の配信ルータが前記センダの配信ルータであるとき、自身の前記転送制御部は、前記所定フローを配信する処理を停止する契機として、前記所定フローを配信要求するホストが前記共有セグメント上で０台になったとき、の代わりに、前記所定フローとして配信されるコンテンツの優先度として、所定値よりも低い優先度が設定されているときとすることを特徴とする
請求項５または請求項６に記載の配信ルータ。
【請求項９】
配信サーバから配信ルータを介してホストにマルチキャストのフローを配信するマルチキャスト配信システムが実行するマルチキャスト配信方法であって、
複数台の前記配信ルータと１台以上のホストとが共有セグメントに接続され、その前記共有セグメントに送信されるパケットは、前記共有セグメントに接続される各装置が受信可能であり、
前記配信ルータは、転送制御部と記憶手段とを有しており、
前記配信ルータの記憶手段には、所定フローについて、正常時の配信担当を示すクエリアの配信ルータと、障害時の配信担当を示すセンダの配信ルータとが記憶されており、
前記センダの配信ルータの転送制御部は、
前記クエリアの配信ルータの障害復旧を検出するまでは、前記クエリアの配信ルータに代行して、前記所定フローを配信する処理を実行し、
前記クエリアの配信ルータの障害復旧を検出した後で、前記所定フローを配信要求するホストが前記共有セグメント上で０台になったときに、前記所定フローを配信する処理を停止することを特徴とする
マルチキャスト配信方法。
【請求項１０】
前記クエリアの配信ルータの転送制御部は、前記センダの配信ルータの転送制御部からの前記所定フローを配信する処理が停止されたことを、前記センダの配信ルータから通知された後に、前記所定フローを配信する処理を再開することを特徴とする
請求項９に記載のマルチキャスト配信方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１２−２２２６９４（Ｐ２０１２−２２２６９４Ａ）
【公開日】平成２４年１１月１２日（２０１２．１１．１２）
【国際特許分類】
【出願番号】特願２０１１−８８３９０（Ｐ２０１１−８８３９０）
【出願日】平成２３年４月１２日（２０１１．４．１２）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２４年１１月１２日（２０１２．１１．１２）
【国際特許分類】
【出願日】平成２３年４月１２日（２０１１．４．１２）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]