"配信サーバから配信ルータを介してホストにマルチキャストのフローを配信するマルチキャスト配信システムであって、複数台の前記配信ルータと1台以上のホストとが共有セグメントに接続され、その前記共有セグメントに送信されるパケットは、前記共有セグメントに接続される各装置が受信可能であり、前記配信ルータは、転送制御部と記憶手段とを有しており、前記配信ルータの記憶手段には、所定フローについて、正常時の配信担当を示すクエリアの配信ルータと、障害時の配信担当を示すセンダの配信ルータとが記憶されており、前記センダの配信ルータの転送制御部は、前記クエリアの配信ルータの障害復旧を検出するまでは、前記クエリアの配信ルータに代行して、前記所定フローを配信する処理を実行し、前記クエリアの配信ルータの障害復旧を検出した後で、前記所定フローを配信要求するホストが前記共有セグメント上で0台になったときに、前記所定フローを配信する処理を停止することを特徴とするマルチキャスト配信システム。前記クエリアの配信ルータの転送制御部は、前記センダの配信ルータの転送制御部からの前記所定フローを配信する処理が停止されたことを、前記センダの配信ルータから通知された後に、前記所定フローを配信する処理を再開することを特徴とする請求項1に記載のマルチキャスト配信システム。前記センダの配信ルータの転送制御部は、前記所定フローを配信する処理を停止する契機として、前記所定フローを配信要求するホストが前記共有セグメント上で0台になったとき、の代わりに、前記配信サーバから前記所定フローが配信されないときとすることを特徴とする請求項1または請求項2に記載のマルチキャスト配信システム。前記センダの配信ルータの転送制御部は、前記所定フローを配信する処理を停止する契機として、前記所定フローを配信要求するホストが前記共有セグメント上で0台になったとき、の代わりに、前記所定フローとして配信されるコンテンツの優先度として、所定値よりも低い優先度が設定されているときとすることを特徴とする請求項1または請求項2に記載のマルチキャスト配信システム。配信サーバから配信ルータを介してホストにマルチキャストのフローを配信するマルチキャスト配信システムに用いられる配信ルータであって、複数台の前記配信ルータと1台以上のホストとが共有セグメントに接続され、その前記共有セグメントに送信されるパケットは、前記共有セグメントに接続される各装置が受信可能であり、前記配信ルータは、転送制御部と記憶手段とを有しており、前記配信ルータの記憶手段には、所定フローについて、正常時の配信担当を示すクエリアの配信ルータと、障害時の配信担当を示すセンダの配信ルータとが記憶されており、自身の配信ルータが前記センダの配信ルータであるとき、自身の前記転送制御部は、前記クエリアの配信ルータの障害復旧を検出するまでは、前記クエリアの配信ルータに代行して、前記所定フローを配信する処理を実行し、前記クエリアの配信ルータの障害復旧を検出した後で、前記所定フローを配信要求するホストが前記共有セグメント上で0台になったときに、前記所定フローを配信する処理を停止することを特徴とする配信ルータ。自身の配信ルータが前記クエリアの配信ルータであるとき、自身の前記転送制御部は、前記センダの配信ルータの転送制御部からの前記所定フローを配信する処理が停止されたことを、前記センダの配信ルータから通知された後に、前記所定フローを配信する処理を再開することを特徴とする請求項5に記載の配信ルータ。自身の配信ルータが前記センダの配信ルータであるとき、自身の前記転送制御部は、前記所定フローを配信する処理を停止する契機として、前記所定フローを配信要求するホストが前記共有セグメント上で0台になったとき、の代わりに、前記配信サーバから前記所定フローが配信されないときとすることを特徴とする請求項5または請求項6に記載の配信ルータ。自身の配信ルータが前記センダの配信ルータであるとき、自身の前記転送制御部は、前記所定フローを配信する処理を停止する契機として、前記所定フローを配信要求するホストが前記共有セグメント上で0台になったとき、の代わりに、前記所定フローとして配信されるコンテンツの優先度として、所定値よりも低い優先度が設定されているときとすることを特徴とする請求項5または請求項6に記載の配信ルータ。配信サーバから配信ルータを介してホストにマルチキャストのフローを配信するマルチキャスト配信システムが実行するマルチキャスト配信方法であって、複数台の前記配信ルータと1台以上のホストとが共有セグメントに接続され、その前記共有セグメントに送信されるパケットは、前記共有セグメントに接続される各装置が受信可能であり、前記配信ルータは、転送制御部と記憶手段とを有しており、前記配信ルータの記憶手段には、所定フローについて、正常時の配信担当を示すクエリアの配信ルータと、障害時の配信担当を示すセンダの配信ルータとが記憶されており、前記センダの配信ルータの転送制御部は、前記クエリアの配信ルータの障害復旧を検出するまでは、前記クエリアの配信ルータに代行して、前記所定フローを配信する処理を実行し、前記クエリアの配信ルータの障害復旧を検出した後で、前記所定フローを配信要求するホストが前記共有セグメント上で0台になったときに、前記所定フローを配信する処理を停止することを特徴とするマルチキャスト配信方法。前記クエリアの配信ルータの転送制御部は、前記センダの配信ルータの転送制御部からの前記所定フローを配信する処理が停止されたことを、前記センダの配信ルータから通知された後に、前記所定フローを配信する処理を再開することを特徴とする請求項9に記載のマルチキャスト配信方法。共有セグメントに複数のルータが存在する場合、それらのうちの一部のルータの装置本体やルータに付属するネットワークインタフェースに障害が発生したときに、残りのルータがフロー配信を代行することで、配信制御を継続する。そして、障害が発生したルータが、障害から回復したときには、代行されていたフロー配信を再び担当する切り戻すことで、正常時の状態に復帰する。ここで、障害から回復したルータにおけるフロー配信の復帰に伴い、その期間にフローの配信が不安定になる。以下、同一セグメント内に、複数の配信ルータR1,R2が存在するときの、3つの状態状態1~状態3を順に説明する。状態1配信ルータR1の障害発生前の状態。配信ルータR1がクエリアである。クエリアR1は、QIQueryInterval時間間隔で周期的にクエリを送信する。ホストは、自らの配信要求を示すレポートを応答する。非クエリアR2は、タイマ上限値以下、OQPTを超過するまでにクエリを受信すれば、非クエリアの状態を維持して配信制御を行わない。状態2配信ルータR1の障害発生により他の正常なルータR2へ配信制御を切り替えた状態。非クエリアR2は、クエリアR1からクエリを受信しなくなる。非クエリアR2は、自タイマがOQPTを超過すると、R1からクエリアを引き継ぎ、配信制御を再開する。状態3配信ルータR1の障害回復後に、ルータR2から配信ルータR1へと配信制御を切り戻す状態。クエリア選択アルゴリズムにより、ルータアドレスが最小ではないクエリアR2は非クエリアへ状態遷移して配信を停止する。これに対し、ルータアドレスが最小である配信ルータR1は、再びクエリアとなり、ホストから配信要求を受信したことを契機に、配信を再開する。従来技術IGMPv2/IGMPv3/MLDv2を用いるときには、状態3において、フローの配信が不安定になる。図8は、フローの配信漏れが発生するまでの様子を示すフローチャートである。S700~S704が、状態2に該当する。S700として、配信ルータR1に、障害が発生する。S701として、配信ルータR2は、クエリアに遷移すると、クエリをホストに送信するS702。S703として、ホストは、リポートフローf1に対して配信要求を示すjoinを指定した内容を含むを配信ルータR2に送信する。S704として、配信ルータR2は、リポートで指定されたフローf1を、ホストに配信する。S705~S714が、状態3に該当する。S705として、配信ルータR1は、障害から回復すると、クエリを送信するS711。S712として、配信ルータR2は、非クエリアに遷移配信停止する。S713として、ホストは、リポートf1にjoinを配信ルータR1に送信する。S714として、配信ルータR1は、フローf1をホストに配信する。ここで、S712からS714までの期間は、ホストにとっては、f1にjoinしているS713にもかかわらず、どの配信ルータからもフローf1を受信できない期間つまり、配信漏れの期間である。配信漏れの期間が発生する要因は、配信ルータR2における個々のフローごとの配信状態が無視され、配信ルータR2の状態がクエリアから非クエリアに遷移すれば、全てのフローのクエリアが無条件に配信ルータR1切り戻されるためである。図9は、フローの重複配信が発生するまでの様子を示すフローチャートである。S700~S705は、図8の動作と同じである。S721として、配信ルータR1は、クエリをホストおよび配信ルータR2に送信する。S722として、ホストは、リポートf1にjoinを配信ルータR1に送信する。S723として、配信ルータR1は、フローf1をホストに配信する。S724として、配信ルータR2は、S721の受信に伴い、非クエリアに遷移配信停止する。ここで、S723からS724までの期間は、ホストにとっては、2台の配信ルータから、同じフローf1のデータが重複して配信されている期間である。重複配信の期間が発生する要因は、個々のルータおよびホストが独立した制御動作を行うだけで、互いに同期制御を行っていないからである。図9に示すように、処理負荷の違いなどによりルータ間の配信制御の開始S723と停止S724との順序が逆転する場合には、重複配信が発生する。そこで、本発明は、共有セグメントに複数のマルチキャスト配信ルータが接続される構成において、クエリアの障害回復時にもフロー配信を安定させることを、主な目的とする。前記課題を解決するために、本発明は、配信サーバから配信ルータを介してホストにマルチキャストのフローを配信するマルチキャスト配信システムであって、複数台の前記配信ルータと1台以上のホストとが共有セグメントに接続され、その前記共有セグメントに送信されるパケットが、前記共有セグメントに接続される各装置が受信可能であり、前記配信ルータが、転送制御部と記憶手段とを有しており、前記配信ルータの記憶手段には、所定フローについて、正常時の配信担当を示すクエリアの配信ルータと、障害時の配信担当を示すセンダの配信ルータとが記憶されており、前記センダの配信ルータの転送制御部が、前記クエリアの配信ルータの障害復旧を検出するまでは、前記クエリアの配信ルータに代行して、前記所定フローを配信する処理を実行し、前記クエリアの配信ルータの障害復旧を検出した後で、前記所定フローを配信要求するホストが前記共有セグメント上で0台になったときに、前記所定フローを配信する処理を停止することを特徴とする。これにより、配信ルータは、ホストにとってフロー配信が不要である時間帯として、所定フローを配信要求するホストが0台になる時間帯まで待ってからフローの配信を停止することにより、ホストのユーザへのフロー配信処理に対する影響を最小化する。本発明は、前記クエリアの配信ルータの転送制御部が、前記センダの配信ルータの転送制御部からの前記所定フローを配信する処理が停止されたことを、前記センダの配信ルータから通知された後に、前記所定フローを配信する処理を再開することを特徴とする。これにより、クエリアの配信ルータの配信再開が、センダの配信ルータの配信停止後になるので、クエリアとセンダとで同じコンテンツを重複配信することを防止できる。本発明は、前記センダの配信ルータの転送制御部が、前記所定フローを配信する処理を停止する契機として、前記所定フローを配信要求するホストが前記共有セグメント上で0台になったとき、の代わりに、前記配信サーバから前記所定フローが配信されないときとすることを特徴とする。これにより、配信ルータは、ホストにとってフロー配信が不要である時間帯として、所定フローが配信されない時間帯まで待ってからフローの配信を停止することにより、ホストのユーザへのフロー配信処理に対する影響を最小化する。本発明は、前記センダの配信ルータの転送制御部が、前記所定フローを配信する処理を停止する契機として、前記所定フローを配信要求するホストが前記共有セグメント上で0台になったとき、の代わりに、前記所定フローとして配信されるコンテンツの優先度として、所定値よりも低い優先度が設定されているときとすることを特徴とする。これにより、配信ルータは、比較的低い優先度のコンテンツが配信される時間帯まで待ってからフローの配信を停止することにより、ホストのユーザへのフロー配信処理に対する影響を少なくする。本発明によれば、共有セグメントに複数のマルチキャスト配信ルータが接続される構成において、クエリアの障害回復時にもフロー配信を安定させることができる。以下、本発明の一実施形態について、図面を参照して詳細に説明する。図1は、マルチキャスト配信システムを示す構成図である。マルチキャストフロー以下、単にフローとするは、配信サーバ1から送信されて、マルチキャスト配信網2、リンク3、各配信ルータ4R1,R2,R3、共有セグメント5を経由して、各ホスト6H1,H2,H3に配信される。これらのマルチキャスト配信システムの各装置は、CPUCentralProcessingUnitとメモリとハードディスク記憶手段とネットワークインタフェースを有するコンピュータとして構成され、このコンピュータは、CPUが、メモリ上に読み込んだプログラムを実行することにより、各処理部を動作させる。マルチキャスト配信網2は、例えば、インターネット網であり、配信サーバ1から配信ルータ4への経路決定のためのプロトコルとして、DVMRPDistanceVectorMulticastRoutingProtocolや、PIM-SMProtocolIndependentMulticastSparseMode、PIM-SSMProtocolIndependentMulticastSourceSpecificMulticastなどが動作することを想定する。共有セグメント5は、その共有セグメント5に接続される装置から送信されるパケットが、そのパケットの送信先だけでなく、同じ共有セグメント5に接続される他装置へも伝送される特性を有する。例えば、配信ルータ4R1からホスト6へ送信されるメッセージは、各ホスト6H1,H2,H3だけでなく、他の各配信ルータ4R2,R3も受信することができる。共有セグメント5は、例えば、イーサネット登録商標のLANLocalAreaNetworkやアクセス集線スイッチ内のVLANVirtualLAN、スイッチ間を跨いだネットワークVLAN等により構成される。配信サーバ1は、フローの配信元となるサーバである。なお、フローの特定情報としては、フローのグループだけを特定情報とする,g指定型であるASMAnySourceMulticastと、フローのグループとフローの送信元の配信サーバ1のアドレスの組を特定情報とするs,g指定型であるSSMSourceSpecificMulticastとが挙げられる。以下、本実施形態では、フローの特定情報をs,g指定型として説明するが、,g指定型にも本実施形態を応用することができる。ここで、s,gとは、Source,Groupの略であり、最初のSourceが送信元の配信サーバ1のアドレスを示し、次のGroupがフローのグループを示す。配信ルータ4は、マルチキャストのグループ管理プロトコルIGMPおよびMLDのプロトコルなどが動作するルータであり、配信サーバ1からの配信データを、ホスト6に転送する。配信ルータ4は、リンク3を介して、マルチキャスト配信網2と接続されている。ホスト6は、配信ルータ4から配信データを受信する端末であり、リスナlistenerとも呼ばれる。ホスト6は、配信ルータ4からのクエリを受信すると、自装置が希望するフローの情報を含めたレポートを作成し、配信ルータ4に返信する。図2は、配信ルータ4を示す構成図である。配信ルータ4は、フローの上流側マルチキャスト配信網2の側から順に、MC配信網接続インタフェース41、MC配信網フレーム転送部42、転送制御回路43、共有セグメントフレーム転送部44、共有セグメント接続インタフェース45が接続されて構成される。インタフェースMC配信網接続インタフェース41、共有セグメント接続インタフェース45は、ネットワークが接続される端点となる箇所であり、外部の網からデータを受信するインタフェース受信IF部411,452と、外部の網にデータを送信するインタフェース送信IF部451,412とから構成される。これらのインタフェースは、例えば、イーサネットのPHY層PhysicalLayerに実装される。フレーム転送部MC配信網フレーム転送部42、共有セグメントフレーム転送部44は、インタフェースが送受信するデータの信号をフレーム単位に変換する処理部であり、受信インタフェースからの通信信号からフレームを構築する受信部フレーム受信部442,421と、構築されたフレームから送信インタフェースを介して送信する通信信号へとデコードする送信部フレーム送信部441,422とから構成される。これらのフレーム転送部は、例えば、イーサネットのMAC層MediaAccessControlLayerに実装される。上流配信サーバ1から下流ホスト6に流れる下りのパケットマルチキャストフローなどは、受信IF部411→フレーム受信部421→配信フィルタ部431→フレーム送信部441→送信IF部451の順に、配信ルータ4内を通過する。下流ホスト6から上流配信サーバ1に流れる上りのパケットレポートjoinleaveなどは、受信IF部452→フレーム受信部442→配信管理部437の順に配信ルータ4内を通過し、上位網と連携が必要な場合は、更に、上位連携部439→フレーム送信部422→送信IF部412の順に、配信ルータ4内を通過する。転送制御回路43は、受信部からのフレームを受信して、そのフレーム内容に応じてIPマルチキャストの転送制御を行い、その結果を送信部に出力する。例えば、転送制御回路43は、フレーム受信部421を介してマルチキャストパケットを受信すると、自ルータが配信制御を行うフローかを判定し、自ルータが配信するフローの場合、フレーム送信部441に当該マルチキャストフローを転送する。一方、転送制御回路43は、共有セグメント内の他の配信ルータ4が配信制御を行うフローの場合、当該マルチキャストパケットを廃棄する。なお、転送制御回路43は、自ルータが配信するストリームの配信契機を、フレーム受信部442を介してホストからレポートjoinleaveを受信したときとする。転送制御回路43は、配信フィルタ部431、フロー判定部432、配信テーブル433、ルータ管理部434、ルータ管理テーブル435、配信管理部437、上位連携部439から構成される。以下、転送制御回路43の各構成要素について、詳細に説明する。配信フィルタ部431は、マルチキャストパケットのフィルタリング機能透過/廃棄を実行する。つまり、配信フィルタ部431がパケットを受信すると、フロー判定部432に対してパケットの透過/廃棄の判定結果を問い合わせ、他のルータが配信制御を行うパケットであれば廃棄する。一方、自ルータが配信制御を行うパケットであれば、当該フローが配信中の状態かをフロー判定部432が配信管理部437に問い合わせる。当該フローが配信中の状態であれば、配信フィルタ部431は、パケットを透過処理して共有セグメントフレーム転送部44のフレーム送信部441へ転送する。フロー判定部432は、フレーム受信部421から受信したマルチキャストパケットについて、配信テーブル433を参照することにより、パケットの転送透過または廃棄を決定する詳細は、後記するフローチャートで説明。フロー判定部432は、S,G単位に自ルータのフィルタリング制御ポリシを導出し、配信テーブル433に対する配信開始フローのエントリ追加や配信停止フローのエントリ削除などを行う。配信管理部437は、IGMP/MLDを実行することにより、自ルータをIGMP/MLDルータとして動作させ、ホスト6側から送信されるレポートjoinleaveを処理し、共有セグメント接続インタフェース45に対するフローごとの配信状態を配信テーブル433にて管理する。配信管理部437は、配信テーブル433を参照して、フレーム受信部421からのパケットの転送または廃棄を決定する。上位連携部439は、例えば、PIM-SSM等のマルチキャストルーティングプロトコルを動作させることにより、配信管理部437から受信した配信要求を、上流側へと送信して、マルチキャスト配信網2の配信制御と連携動作する。ルータ管理部434は、共有セグメント5に接続される各配信ルータ4自ルータおよび他ルータのエントリを把握するための信号を交換することで、ルータ管理テーブル435内のルータエントリを編集する。ルータ管理部434は、ルータ管理テーブル435の各配信ルータ4から、クエリアを決定するためのルータアドレス例えば、アドレスが最小である配信ルータ4をクエリアとするとして、自ルータのIPアドレスと、他ルータから受信したパケットから特定できる他ルータのIPアドレスとを参照する。他ルータのIPアドレスは、例えば、IGMPおよびMLDにおける他ルータから共有セグメント5に定期的に送信されるGQGeneralQueryメッセージなどのクエリの送信元アドレスである。なお、ルータエントリの登録用のメッセージは、送信元ルータのIPアドレスを検出可能であれば、GQだけに限定されず、任意のメッセージを用いてもよい。IGMPv3IPv4マルチキャストの場合は、GQとGSQGroupSpecificQueryとGSSQGroupandSourceSpecificQueryの3種類のクエリが規定されている。MLDv2IPv6マルチキャストの場合は、GQとMASQMulticastAddressSpecificQueryとMASSQMulticastAddressandSourceSpecificQueryの3種類のクエリが規定されている。マルチキャスト以外のメッセージを用いる場合は、pingICMPパケットや独自パケットなど。一方、ルータ管理部434は、ルータアドレスが最小である配信ルータ4をクエリアとする代わりに、フローの特定情報をもとに、そのフローごとにクエリアを特定してもよい。例えば、フローの特定情報がS,Gであり、共有セグメント5内の正常な障害が発生していないルータ数をNとしたときに、A=SGModNを計算し、共有セグメント5内でルータアドレスがA番目に小さい配信ルータ4をクエリアとするただし、A=0のときは、ルータアドレスが最大の配信ルータ4。ここで、例えば、Mod3とは、SG列の値を、ルータ数3で除算した余りmod演算である。このように、フローごとにクエリアを特定することで、共有セグメント5内に複数のフローが配信されるときに、そのフローごとの配信担当となるクエリアが負荷分散されるので、フローの配信漏れや重複配信を抑制しつつ、共有セグメント全体のフローのスループットを向上させることができる。さらに、ルータ管理部434は、管理者から手動で設定された配信ルータ4をクエリアとするなど、任意のクエリア選択アルゴリズムを用いてもよい。表1は、配信ルータ4R1が正常時であるときの、各配信ルータ4の配信テーブル433を示す。なお、ホスト6からのレポートが、同じ共有セグメント5に属する各配信ルータ4に届くため、それらの各配信ルータ4内の配信テーブル433のデータ内容は、互いに同じものである。配信テーブル433の左側の3列フロー,S,Gについて、フロー列、S列、G列は、フローの特定情報がS,Gであることを示している。配信テーブル433の中央の2列センダ、クエリアは、対応するフローについての配信ルータ4の役割を示す。配信テーブル433では、共有セグメント5内でのクエリアに該当する配信ルータ4に加え、そのクエリアよりも強い優先される配信権利を有するセンダSenderが、フローごとに対応づけられている。例えば、クエリアかつセンダである配信ルータ4R1は、2つのフローf1、f2を配信している。なお、クエリアかつセンダそれぞれの役割は、障害の前後で以下のように引き継がれる。配信ルータ4R1の障害前は、クエリアとセンダとが同一の配信ルータ4R1に割り当てられている。配信ルータ4R1の障害中は、配信ルータ4R2がクエリアとセンダとの役割を配信ルータ4R1から代行する。クエリアの障害回復後は、クエリアを配信ルータ4R2から配信ルータ4R1へとすぐに引き継ぐ。一方、センダの配信ルータ4R2は、ホスト6のユーザに影響しないまたは影響が少ない時間帯まで待ってからフローの配信を停止し、その停止後に、センダを配信ルータ4R1へと引き継ぐ。ここで、以下の説明では、センダの配信ルータ4R2から配信ルータ4R1への引き継ぎの契機として、フローを視聴するメンバが0人マルチキャストグループへの参加人数が0人になる時間帯、すなわち、フローを配信要求するホスト6が共有セグメント5上で0台になる時間帯を例示するが、その他にも、以下の時間帯としてもよい。フローを視聴するメンバが、所定数以下例えば、3人以下になる時間帯フローを視聴するメンバがいたとしても、上流側からフローが配信されない時間帯深夜などの放送休止時間フローのコンテンツとして、コンテンツ優先度が所定値より低い内容無料放送などが流れている時間帯。一方、コンテンツ優先度が所定値より高い内容有料放送などが流れている時間は、センダの引き継ぎ時間帯からは除外する。配信テーブル433の右側の2列配信状態、配信は、対応するフローについての配信処理を説明するものである。配信状態joinとは、対応するフローの配信を希望する換言すると、マルチキャストグループへ参加するホストが、共有セグメント5内に1台以上存在することを示す。配信状態leaveとは、対応するフローの配信を希望する換言すると、マルチキャストグループへ参加するホストが、共有セグメント5内に0台である換言すると、マルチキャストグループへの離脱ことを示す。配信列は、その列の配信テーブル433を収容する配信ルータ4が、対応するフローについて実際に配信しているか○否か-を示す。例えば、フローf1は、配信希望joinされているため、配信ルータ4R1が配信し、配信ルータ4R2は配信しない。つまり、一般的に、配信状態joinであるときには、1台の配信ルータ4がフローの配信をすることで重複配信を抑制し、配信状態leaveであるときには、フローの配信をする必要がないので、全ての配信ルータ4がフローの配信をしない。図3は、マルチキャスト配信システムの配信動作の前半障害発生~障害回復の動作を示すフローチャートである。このフローチャートを開始する前の各配信ルータ4内の配信テーブル433の内容は、表1に示したとおりである。以下、フローチャートの送信処理の説明からは、その送信先の装置の記載を適宜省略する。図1で説明したように、送信先を明示的に指定しないメッセージが送信されていても、そのメッセージは共有セグメント5上を流れるので、その共有セグメント5に接続される各装置配信ルータ4、ホスト6が受信可能である送信先となりうる。S100として、配信ルータ4R1に障害が発生すると、フローf1などの各フローの配信が中断されてしまうS101。S102として、配信ルータ4R2のフロー判定部432は、クエリアとセンダとの役割を配信ルータ4R1から代行する。そのため、配信ルータ4R2内のGQ死活監視用のタイマは、時間経過にしたがってタイマ値を増加させるとともに、配信ルータ4R1からのGQ受信によりタイマ値を0にリセットする。そして、タイマ値が所定しきい値OQPTを超過したときに、配信ルータ4R2は、S102の代行処理を起動させる。S104として、配信ルータ4R2の配信管理部437は、クエリを送信する。S105として、ホスト6は、リポートf1にjoinを送信する。S106として、配信ルータ4R2のフロー判定部432は、S105のjoinの受信処理図5参照を起動し、その結果としてフローf1の配信を開始する。表2は、表1の状態後に配信ルータ4R1が障害中であるときのS106時点での、各配信ルータ4の配信テーブル433を示す。配信ルータ4R1内の配信テーブル433では、全フローanyの配信が不可downであり、センダもクエリアも自装置ではない値-。配信ルータ4R2内の配信テーブル433では、表1の配信ルータ4R1内の配信テーブル433の内容を引き継いでいる。なお、表2におけるセンダR1→R2という表記は、センダがR1からR2へと変更されたことを示す。S107として、配信ルータ4R1は、障害回復すると、その障害回復に伴う各配信ルータ4内の配信テーブル433の更新処理S108~S113が実行される。S108として、配信ルータ4R1のフロー判定部432は、配信テーブル433を新規生成し、その全てのフローを未配信値-にする。S109として、配信ルータ4R1の配信管理部437は、他の配信ルータ4から配信テーブル433のエントリを取得するための要求パケットルータクエリを送信する。S110として、配信ルータ4R2のフロー判定部432は、自装置内の配信テーブル433において、クエリアとセンダとを切り戻す。具体的には、フロー判定部432は、全フローのエントリに対してクエリアを再設定R2→R1するとともに、自装置が非配信のフローのエントリotherに対して、そのセンダをクエリアと同じR1に設定する。S111として、配信ルータ4R2の配信管理部437は、自装置の識別情報IPアドレスなどと、配信中のフローの識別情報とを格納するルータクエリ応答を、S109でルータクエリを送信した配信ルータ4R1に応答する。S112として、配信ルータ4R1のフロー判定部432は、共有セグメント5内の各配信ルータ4から、それぞれルータクエリの応答パケットS111を受信すると、その応答パケットから配信中のフローと配信ルータの情報を取り出し、自装置内の配信テーブル433へと取り出したエントリを追加する。S113として、配信ルータ4R1のフロー判定部432は、配信中でないフローの中で、クエリアであるフローに対して、センダを自装置に切り戻して設定する。表3は、表2の状態後に配信ルータ4R1が障害復旧したときのS113時点での、各配信ルータ4の配信テーブル433を示す。配信ルータ4R1内の配信テーブル433では、表2の配信ルータ4R2内の配信テーブル433の内容が、S111のルータクエリ応答で通知されて、登録されている。しかし、配信ルータ4R1はフローf1,f2に対しては非センダであるので、配信はしない配信列が-。さらに、未配信フロー配信列が-のフローotherのセンダが配信ルータ4R1に切り戻されているS113。配信ルータ4R2内の配信テーブル433では、表2の状態から、未配信フロー配信列が-のフローotherのセンダが配信ルータ4R1に切り戻されているS110。表4は、表3の状態後にフローf3の配信状態をjoinにしたときの、各配信ルータ4の配信テーブル433を示す。f1とf2以外のフロー表3のフローotherであるフローf3の配信は、そのセンダかつクエリアである配信ルータ4R1が担当する配信列が○。図4は、マルチキャスト配信システムの配信動作の後半障害回復~配信の切り戻しの動作を示すフローチャートである。このフローチャートは、図3のS113の続きとして実行される。S114として、配信ルータ4R1の配信管理部437は、クエリを送信する。S115として、ホスト6は、リポートf1にjoinを送信する。S116として、配信ルータ4R1のフロー判定部432は、S116のjoinの受信処理図5参照を起動した結果、フローf1を未配信とする。S117として、配信ルータ4R2のフロー判定部432は、S116のjoinの受信処理図5参照を起動した結果、フローf1を配信継続とする。S121として、ホスト6は、リポートf1をleaveを送信する。S122として、配信ルータ4R1のフロー判定部432は、S121のleaveの受信処理図6参照を起動した結果、S124で後記するセンダの切り戻し処理を起動する。S123として、配信ルータ4R2のフロー判定部432は、S121のleaveの受信処理図6参照を起動した結果、フローf1の配信を停止する。S124として、配信ルータ4R1,R2のフロー判定部432は、センダの切り戻し処理をする図7参照。つまり、フローf1のセンダがR2からR1へと切り戻される。表5は、表4の状態後にフローf1の配信状態をleaveにしたときS124時点でのの、配信テーブル433を示す。S131として、配信ルータ4R1の配信管理部437は、クエリを送信する。S132として、ホスト6は、リポートf1にjoinを送信する。S133として、配信ルータ4R1のフロー判定部432は、S132のjoinの受信処理図5参照を起動した結果、フローf1の配信を開始とする。S134として、配信ルータ4R2のフロー判定部432は、S132のjoinの受信処理図5参照を起動した結果、フローf1を未配信とする。表6は、表5の状態後にフローf1の配信状態をjoinにしたときのS134時点での、各配信ルータ4の配信テーブル433を示す。S124で切り戻されたセンダである配信ルータ4R1が、フローf1の配信を担当する配信列が○。表7は、表6の状態後にフローf2の配信状態をleaveにしたときの、各配信ルータ4の配信テーブル433を示す。表5で示したフローf1と同様である。表8は、表7の状態後にフローf2の配信状態をjoinにしたときの、各配信ルータ4の配信テーブル433を示す。表6で示したフローf1と同様である。以上説明したように、フローf1のセンダの切り戻し処理S124に伴う、フローf1の配信不可時間が発生したとしても、その切り戻し処理S124の実行を、フローf1の配信が不要な時間配信状態leaveであるS121~S132の時間内に収めることにより、ホスト6にとってフローf1の配信漏れや重複配信などの不安定な配信として意識させずに済む。図5は、配信ルータ4がホスト6からjoinを受信したときの動作を示すフローチャートである。S201として、配信管理部437は、自装置内の配信テーブル433の受信したレポートjoinに該当するエントリの配信状態をjoinに更新する。S202として、フロー判定部432は、S201で更新したエントリのセンダが自装置か否かを判定する。S202でYesならS204に進み、NoならS203に進む。S203として、配信フィルタ部431は、S201で更新したエントリのフローの配信をせずに、処理を終了する。S204として、フロー判定部432は、S201で更新したエントリの配信列が○自装置が配信しているか否かを判定する。S204でYesならS205に進み、NoならS206に進む。S205として、配信フィルタ部431は、フローの配信を継続する配信列への修正は不要。S206として、配信フィルタ部431は、フローの配信を開始する配信列を-から○に修正する。図6は、配信ルータ4がホスト6からleaveを受信したときの動作を示すフローチャートである。S211として、配信管理部437は、自装置内の配信テーブル433を参照し、レポートjoinに該当するエントリの配信状態がjoinか否かを判定する。S211でYesならS212に進み、Noなら終了する。S212として、配信管理部437は、共有セグメント5内に、S211で判定したフローの配信を要求するホスト6が、leaveの送信元であるホスト6の他に存在するか否かを判定する。S212でYesならS213に進み、NoならS214に進む。なお、S212の判定を行うために、配信ルータ4は、以下の2つの処理のうちのいずれかの処理を行う。処理Aホストトラッキングとして、ホスト6から送信されるjoin/leaveレポートを、その送信元であるホスト6ごとに対応づけて記録する。処理BMLDv2にはMASSQIGMPv3の場合はGSSQに相当というクエリが定義されている。MASSQを利用したfastleaveでは、フローに対するleaveメッセージを配信ルータ4が受信した場合、当該インタフェースからleave要求のあったフロー情報を格納したMASSQを送信する。MASSQを受信したホスト6は、MASSQで指定されているフローの視聴中ならば、ルータに対してフローを視聴中であることを示すレポートを返信する。S213として、配信管理部437は、S211で判定したフローの配信状態として、joinを維持する。S214として、配信管理部437は、配信状態をjoinからleaveへと更新する。S215として、フロー判定部432は、S211で判定したフローについて、自装置内の配信テーブル433を参照してそのフローのセンダとクエリアとを取得し、自装置が取得したセンダやクエリアに該当するか否かを判定する。自装置がセンダに該当する場合S215のルータ種別=センダ、自装置がクエリアに該当するか否かにかかわらず、S217に進む。自装置がセンダに該当せず、かつ、クエリアに該当する場合S215のルータ種別=非センダクエリア、S216に進む。自装置がセンダにもクエリアにも該当しない場合S215のルータ種別=その他、処理を終了する。S216として、フロー判定部432は、クエリアである自装置に、センダの役割をもたせるため、センダの切り戻し処理図7参照を起動する。S217として、フロー判定部432は、自装置がセンダとして現在フローを配信しているか否かを、自装置内の配信テーブル433内の配信列を参照して判定する。S217でYesならS218に進み、Noなら終了する。S218として、配信フィルタ部431は、フローの配信を停止する。図7は、切り戻し処理を示すフローチャートである。このフローチャートは、図6のレポートleaveで示されるフローを指定して、図6のS216から呼び出される処理である。S301として、配信ルータ4R1のフロー判定部432は、指定されたフローの切り戻しReady信号を配信ルータ4R2に送信する。S302として、配信ルータ4R2のフロー判定部432は、自装置内の配信テーブル433において、S301の切り戻しReady信号で指定されたフローのセンダを空欄にする。S303として、配信ルータ4R2のフロー判定部432は、S302で空欄にしたように、センダの役割を放棄することを、切り戻し先の配信ルータ4R1へ通知する。S304として、配信ルータ4R1のフロー判定部432は、S303の放棄通知を受信すると、自装置が指定されたフローのクエリアに該当するか否かを判定する。S304でYesならS305に進み、Noなら終了する。S305として、配信ルータ4R1のフロー判定部432は、自装置内の配信テーブル433において、指定されたフローのセンダを自装置に設定する。S306として、配信ルータ4R1のフロー判定部432は、フローのセンダの獲得通知信号をS303の送信元である配信ルータ4R2へと返信する。S307として、配信ルータ4R2のフロー判定部432は、S306の返信を受信すると、そのセンダの獲得通知信号で指定された配信ルータ4R1を、指定されたフローのセンダにする旨を、自装置内の配信テーブル433に設定する。以上説明した本実施形態では、配信ルータ4がIPマルチキャストの配信制御を行うにあたり、共有セグメント5に複数の配信ルータ4が冗長接続される構成において、配信ルータ4の障害復帰時におけるフロー配信を安定させることを特徴とする。配信ルータ4は、切り戻し対象のフローごとの配信状態配信テーブル433のjoinleaveや配信しているか否か配信テーブル433の配信列を考慮しつつ、フロー配信が不要である時間帯まで待ってからフロー配信を停止し、その後に切り戻し制御を行うことにより、切り戻し制御に伴うホスト6のユーザへの影響を最小化する。また、共有セグメント5上で、複数の配信ルータ4が同じデータを重複配信しないようにするため、切戻し元と切戻し先の配信ルータ4間で、お互いの制御過程を同期確認し合いながら、配信開始/配信停止の順序性が保たれた、切戻し制御を行う図7参照。これにより、従来技術に比べて高品質かつ高信頼性なIPマルチキャストサービスが実現可能となるので、地上デジタルテレビ放送のIP再送信サービスなどのような高付加価値のネットワークサービスを、ホスト6のユーザに提供することができる。"