"ホストにマルチキャストのフローを配信する複数台の配信ルータと1台以上の前記ホストとが共有セグメントに接続され、その共有セグメントに送信されるパケットは、前記共有セグメントに接続される前記配信ルータおよび前記ホストがそれぞれ受信可能であるマルチキャスト配信システムに用いられる前記配信ルータであって、前記共有セグメントに接続される前記配信ルータのインタフェースごとに、そのインタフェースの識別情報を引数として所定のハッシュ空間へと射影する第1ハッシュ関数を計算することで、IFハッシュ値を計算するIF状態管理部と、前記共有セグメントを介して前記配信ルータによる配信されるフローごとに、そのフローの識別情報を引数として前記所定のハッシュ空間へと射影する第2ハッシュ関数を計算することで、フローハッシュ値を計算し、計算した各前記IFハッシュ値によって区切られるハッシュ空間内の所定領域を、所定の前記IFハッシュ値の担当領域とし、その担当領域に含まれる前記フローハッシュ値に該当するフローを、所定の前記IFハッシュ値に該当する前記配信ルータのインタフェースが配信を担当するように制御し、前記所定のハッシュ空間に対して新たに前記IFハッシュ値を追加するときには、追加する前記IFハッシュ値の担当領域を、前記IFハッシュ値の担当領域の1つを分割した領域とし、前記所定のハッシュ空間から前記IFハッシュ値を削除するときには、削除する前記IFハッシュ値の担当領域を、他の1つの前記IFハッシュ値の担当領域へ統合するフロー割当処理部とを有することを特徴とする配信ルータ。前記IF状態管理部は、前記共有セグメントに流れる前記配信ルータからのマルチキャストのクエリメッセージを受信し、そのクエリメッセージに含まれる送信元IPアドレスを前記IFハッシュ値を計算するための前記インタフェースの識別情報として用いることを特徴とする請求項1に記載の配信ルータ。前記フロー割当処理部は、前記共有セグメントに流れる前記ホストからのマルチキャストのレポートメッセージを受信し、そのレポートメッセージに含まれる配信フローの送信元IPアドレス、および、配信フローの宛先IPアドレスのうちの少なくとも1つのIPアドレスを、前記フローハッシュ値を計算するための前記フローの識別情報として用いることを特徴とする請求項1に記載の配信ルータ。前記フロー割当処理部は、前記計算したIFハッシュ値が互いに同じ値となる前記配信ルータのインタフェース群について、前記インタフェース群のうちの1つのインタフェースには、前記同じ値として計算したIFハッシュ値を対応づけて前記所定のハッシュ空間に割り当て、前記インタフェース群のうちの他のインタフェースには、前記同じ値として計算したIFハッシュ値を起点として所定分だけ移動したIFハッシュ値を対応づけて前記所定のハッシュ空間に割り当て、前記所定のハッシュ空間から前記1つのインタフェースのIFハッシュ値が削除されるときには、前記他のインタフェースに対応づけられていたIFハッシュ値を、前記所定のハッシュ空間において移動前のIFハッシュ値へと戻すことを特徴とする請求項1ないし請求項3のいずれか1項に記載の配信ルータ。ホストにマルチキャストのフローを配信する複数台の配信ルータと1台以上の前記ホストとが共有セグメントに接続され、その共有セグメントに送信されるパケットは、前記共有セグメントに接続される前記配信ルータおよび前記ホストがそれぞれ受信可能であるマルチキャスト配信システムであって、前記マルチキャスト配信システムに用いられる前記各配信ルータは、前記共有セグメントに接続される前記配信ルータのインタフェースごとに、そのインタフェースの識別情報を引数として所定のハッシュ空間へと射影する第1ハッシュ関数を計算することで、IFハッシュ値を計算するIF状態管理部と、前記共有セグメントを介して前記配信ルータによる配信されるフローごとに、そのフローの識別情報を引数として前記所定のハッシュ空間へと射影する第2ハッシュ関数を計算することで、フローハッシュ値を計算し、計算した各前記IFハッシュ値によって区切られるハッシュ空間内の所定領域を、所定の前記IFハッシュ値の担当領域とし、その担当領域に含まれる前記フローハッシュ値に該当するフローを、所定の前記IFハッシュ値に該当する前記配信ルータのインタフェースが配信を担当するように制御し、前記所定のハッシュ空間に対して新たに前記IFハッシュ値を追加するときには、追加する前記IFハッシュ値の担当領域を、前記IFハッシュ値の担当領域の1つを分割した領域とし、前記所定のハッシュ空間から前記IFハッシュ値を削除するときには、削除する前記IFハッシュ値の担当領域を、他の1つの前記IFハッシュ値の担当領域へ統合するフロー割当処理部とを有することを特徴とするマルチキャスト配信システム。ホストにマルチキャストのフローを配信する複数台の配信ルータと1台以上の前記ホストとが共有セグメントに接続され、その共有セグメントに送信されるパケットは、前記共有セグメントに接続される前記配信ルータおよび前記ホストがそれぞれ受信可能であるマルチキャスト配信システムが実行するマルチキャスト配信方法であって、前記マルチキャスト配信システムに用いられる前記各配信ルータは、IF状態管理部と、フロー割当処理部とを有しており、前記IF状態管理部は、前記共有セグメントに接続される前記配信ルータのインタフェースごとに、そのインタフェースの識別情報を引数として所定のハッシュ空間へと射影する第1ハッシュ関数を計算することで、IFハッシュ値を計算し、前記フロー割当処理部は、前記共有セグメントを介して前記配信ルータによる配信されるフローごとに、そのフローの識別情報を引数として前記所定のハッシュ空間へと射影する第2ハッシュ関数を計算することで、フローハッシュ値を計算し、計算した各前記IFハッシュ値によって区切られるハッシュ空間内の所定領域を、所定の前記IFハッシュ値の担当領域とし、その担当領域に含まれる前記フローハッシュ値に該当するフローを、所定の前記IFハッシュ値に該当する前記配信ルータのインタフェースが配信を担当するように制御し、前記所定のハッシュ空間に対して新たに前記IFハッシュ値を追加するときには、追加する前記IFハッシュ値の担当領域を、前記IFハッシュ値の担当領域の1つを分割した領域とし、前記所定のハッシュ空間から前記IFハッシュ値を削除するときには、削除する前記IFハッシュ値の担当領域を、他の1つの前記IFハッシュ値の担当領域へ統合することを特徴とするマルチキャスト配信方法。前記した従来のクエリアの選択メカニズムは、契機1および契機2という単純な処理により、クエリアと非クエリアとの交代処理を実現しているので、実装はしやすいものの、IF集合の構成変更に伴って、フローの配信処理が不安定になる。不安定とは、具体的には、IF集合のうちのクエリアが0台となってしまい、フローがホストに配信されない配信断や、IF集合のうちのクエリアが2台以上となってしまい、同じフローがホストに対して別々に配信されてしまう重複配信である。つまり、クエリアの選択メカニズムは、精密に時刻同期/順序同期して実行されるわけではなく、他IFから送信されるクエリおよびホストから送信されるレポートの受信を契機にそれぞれ独立したタイミングで実行されるため、クエリアと非クエリアとの交代処理を実行する過程において、フローの配信処理が不安定になる。以下、IF集合の構成変更の例を変更1~変更4として、それぞれ説明する。変更1新しいIFをIF集合に増設する場合、増設先のIF集合にクエリアがすでに存在しているにもかかわらず、増設したIFはクエリアとして一旦起動する。よって、すでに存在しているクエリアと、増設したIFのクエリアとが同じIF集合に重複して存在するため、増設したIFとすでに存在しているクエリアとで、新たなクエリアを1つ選出する契機1が実行されるまでの期間において、重複配信が発生してしまう。変更2所定のIFをIF集合から減設する場合、その減設対象がクエリアであるときには、クエリアが減設されたときから、非クエリア間で新たなクエリアを選出するまでの期間において、クエリアが0台となってしまい、配信断が発生してしまう。変更3クエリアに障害が発生する場合、その障害発生クエリアを非クエリアが検出するには、クエリアからGQパケットを受信しない時間が標準規定上で定められたタイマ上限値例えば、256秒程度を超過するまで、GQパケットを待たなければならない。よって、非クエリアが障害発生クエリアを代行するまでの期間において、クエリアが0台となってしまい、配信断が発生してしまう。なお、タイマ上限値を短くすると、その分のGQパケットの送信頻度が上がってしまうため、IF集合のクエリアや他IFの負荷が上昇してしまう副作用が発生する。変更4クエリアが変更3の障害から復旧した場合、復旧したクエリアと、変更3でクエリアを代行していたクエリアは、それぞれフローを配信するので、クエリアを1つに集約するまでは、重複配信が発生してしまう。そこで、本発明は、共有セグメントに複数のマルチキャスト配信ルータのインタフェースが接続される構成において、それらのインタフェース集合に構成変更が発生してもフローの配信処理が不安定となる範囲を限定することを、主な目的とする。前記課題を解決するために、本発明は、ホストにマルチキャストのフローを配信する複数台の配信ルータと1台以上の前記ホストとが共有セグメントに接続され、その共有セグメントに送信されるパケットが、前記共有セグメントに接続される前記配信ルータおよび前記ホストがそれぞれ受信可能であるマルチキャスト配信システムに用いられる前記配信ルータであって、前記共有セグメントに接続される前記配信ルータのインタフェースごとに、そのインタフェースの識別情報を引数として所定のハッシュ空間へと射影する第1ハッシュ関数を計算することで、IFハッシュ値を計算するIF状態管理部と、前記共有セグメントを介して前記配信ルータによる配信されるフローごとに、そのフローの識別情報を引数として前記所定のハッシュ空間へと射影する第2ハッシュ関数を計算することで、フローハッシュ値を計算し、計算した各前記IFハッシュ値によって区切られるハッシュ空間内の所定領域を、所定の前記IFハッシュ値の担当領域とし、その担当領域に含まれる前記フローハッシュ値に該当するフローを、所定の前記IFハッシュ値に該当する前記配信ルータのインタフェースが配信を担当するように制御し、前記所定のハッシュ空間に対して新たに前記IFハッシュ値を追加するときには、追加する前記IFハッシュ値の担当領域を、前記IFハッシュ値の担当領域の1つを分割した領域とし、前記所定のハッシュ空間から前記IFハッシュ値を削除するときには、削除する前記IFハッシュ値の担当領域を、他の1つの前記IFハッシュ値の担当領域へ統合するフロー割当処理部とを有することを特徴とする。これにより、構成変更が発生したIFハッシュ値に近接するフローを収容変更するだけで済むので、フローの配信処理の不安定の影響を局所的にすることができる。よって、共有セグメントに複数のマルチキャスト配信ルータのインタフェースが接続される構成において、それらのインタフェース集合に構成変更が発生してもフローの配信処理が不安定となる範囲を限定することができる。本発明は、前記IF状態管理部が、前記共有セグメントに流れる前記配信ルータからのマルチキャストのクエリメッセージを受信し、そのクエリメッセージに含まれる送信元IPアドレスを前記IFハッシュ値を計算するための前記インタフェースの識別情報として用いることを特徴とする。これにより、既存のプロトコルのパケットフォーマットクエリをそのまま活用できる。本発明は、前記フロー割当処理部が、前記共有セグメントに流れる前記ホストからのマルチキャストのレポートメッセージを受信し、そのレポートメッセージに含まれる配信フローの送信元IPアドレス、および、配信フローの宛先IPアドレスのうちの少なくとも1つのIPアドレスを、前記フローハッシュ値を計算するための前記フローの識別情報として用いることを特徴とする。これにより、既存のプロトコルのパケットフォーマットレポートをそのまま活用できる。本発明によれば、共有セグメントに複数のマルチキャスト配信ルータのインタフェースが接続される構成において、それらのインタフェース集合に構成変更が発生してもフローの配信処理が不安定となる範囲を限定することができる。以下、本発明の一実施形態について、図面を参照して詳細に説明する。図1は、マルチキャスト配信システムを示す構成図である。マルチキャストフローは、配信サーバ1S1,S2,...から送信され、マルチキャスト配信網2、リンク3、配信ルータ4R1,R2,R3,...、共有セグメント5を経由し、ホスト6H1,H2,H3,H4,...に配信される。共有セグメント5は、例えば、イーサネットのセグメントマルチキャストVLANとして構成される。これらのマルチキャスト配信システムの各装置は、CPUCentralProcessingUnitとメモリとハードディスク記憶手段とネットワークインタフェースを有するコンピュータとして構成され、このコンピュータは、CPUが、メモリ上に読み込んだプログラムを実行することにより、各処理部を動作させる。配信ルータ4とホスト6と間のパケットは、共有セグメント5を介して送受信される。この送受信されるパケットは、配信ルータ4から送信されるクエリと、ホスト6から送信されるレポート配信中を示すJoin/未配信を示すLeaveとがある。RFCRequestforComments3810に記載されているように、レポートのICMPv6ヘッダ内のRecordTypeを5ALLOWNEWSOURCESに設定すると指定したS,Gに対するJoinとなり、RecordTypeを6BLOCKOLDSOURCESに設定すると指定したS,Gに対するLeaveとなる。図2は、配信ルータ4を示す構成図である。配信ルータ4は、マルチキャスト配信網2と接続するMC配信網接続インタフェース41、マルチキャスト配信網2とフレーム送受信を行うMC配信網フレーム転送部42、共有セグメント5とフレーム送受信を行う共有セグメントフレーム転送部44、共有セグメント5と接続する共有セグメント接続インタフェース45、フローの配信を制御する転送制御回路43から構成される。MC配信網接続インタフェース41と共有セグメント接続インタフェース45は、一般的な物理レイヤを司り、イーサネットの場合はPHYレイヤに相当する。MC配信網接続インタフェース41は、受信IF部411と送信IF部412とから構成される。共有セグメント接続インタフェース45は、送信IF部451と受信IF部452とから構成される。MC配信網フレーム転送部42と共有セグメントフレーム転送部44は、一般的なデータリンク層を司り、イーサネットの場合はMACMediaAccessControlレイヤに相当する。MC配信網フレーム転送部42は、フレーム受信部421とフレーム送信部422とから構成される。共有セグメントフレーム転送部44は、フレーム送信部441とフレーム受信部442とから構成される。転送制御回路43は、配信状態管理部431、MC配信網連携部432、IF状態管理部433、IF管理テーブル434、フロー割当処理部435、フロー配信テーブル436、配信フィルタ部437から構成される。レポートは、ホスト6から受信すると、共有セグメント接続インタフェース45、共有セグメントフレーム転送部44、配信状態管理部431を介して、フロー割当処理部435に通知される。配信状態管理部431は、従来のIGMP/MLDルータなどに相当し、IPマルチキャストフローのアクセス配信状態の管理を行う。ここで、配信状態管理部431は、ホスト6から受信したレポートの内容と現在のフロー配信状態に応じて、MC配信網連携部432を介して、配信に関する連携処理を行う。MC配信網連携部432は、従来のPIMルータなどに相当する。マルチキャスト配信網2と連携してIPマルチキャストルーティングの制御を行う。配信フィルタ部437は、フロー割当処理部435からの指示を受けて、フロー単位の配信フィルタを開閉する。フィルタが開放されたフローは、MC配信網フレーム転送部42から受信したフローパケットを共有セグメントフレーム転送部44へ転送する。逆に、フィルタ閉鎖されたフローは転送せずに廃棄する。IF状態管理部433は、共有セグメントに接続される全てのIFの情報を管理する。共有セグメント接続インタフェース45、共有セグメントフレーム転送部44、配信状態管理部431を介して受信する他IFからのクエリの送信元IPアドレスや受信時刻を検査し、IFの識別情報からIFハッシュ値を計算し詳細は、後記する表1で説明、他IFを死活監視する。IF管理テーブル434は、IF状態管理部433において検査されたIF情報が登録および管理されるデータベースである。IF状態管理部433は、フロー割当処理部435の指示に従い、IF管理テーブル434に登録したインタフェース情報を読み出して、フロー割当処理部435に引き渡す。フロー割当処理部435は、フローに対するIFの割当情報をフロー配信テーブル436に管理する。フロー割当処理部435は、レポートから読み取ったフローの識別情報をもとに、フローハッシュ値を計算する詳細は、後記する表2で説明。フロー割当処理部435は、IF状態管理部433から全てのIFハッシュ値を取得し、当該フローハッシュ値と全てのIFハッシュ値の方向距離を計算して当該フローに対する配信IFの割当てを決定して配信状態の制御を行う。ここで、これらの処理情報をフロー配信テーブル436に登録する。フロー配信テーブル436は、フロー割当処理部435において処理されたフローごとのインタフェースに対する割当情報および配信状態が登録および管理されるデータベースである。図3は、両テーブルIF管理テーブル434、フロー配信テーブル436が使用するリング状のハッシュ空間を示す説明図である。図3aは、ハッシュ空間の大きさであるハッシュ値の上限を決める定数nとしたときのハッシュ空間を示す。定数nとはハッシュ値の最大値1である。ハッシュ空間は、右回り時計回りにハッシュ値が大きくなるように構成され、12時の方向真上がハッシュ値0とハッシュ値n、6時の方向真下がハッシュ値n/2を示す。図3bは、図3aのハッシュ空間として、n=1000としたときの一例を示す。表1は、共有セグメント5ごとに生成されるIF管理テーブル434を示す。IF管理テーブル434は、IFの識別情報であるIFIDと、IFのIPアドレスと、そのIFのIFハッシュ値Hashと、そのIFが自身のものか否かを示すIFフラグと、IFが活動しているか否かを監視するためのクエリア死活監視タイマとを対応づけて格納する。例えば、IFIDR1は、自身が収容するIFである。IFIDR2R3は、他装置が収容するIFであり、クエリを受信してから経過した時間クエリア死活監視タイマの時間が所定時間以下なので、活動している。IFIDR4は、他装置が収容するIFであり、クエリを受信してから経過した時間が所定時間を超えたためタイムアウトしたため、活動していない。IF管理テーブル434のIFハッシュ値は、IFのIPアドレスを定数nで剰余算modした結果である。なお、各IFのIPアドレスは、クエリのIPv6ヘッダに記載されている送信元IPアドレスIPv6のリンクローカルアドレスを読み取れば取得できる。なお、以下では、ハッシュ関数の引数として、IFのIPアドレスを用いたが、他のIFの識別情報送信元IPアドレスの一部や、所定ルールで設定したIFのIDや、共有セグメント5におけるIFのクエリア順位共有セグメント5の中で何番目に小さいIPアドレスかなどを代わりに引数として用いてもよい。以下、ハッシュ空間の大きさをnとし、ハッシュ引数であるIFのIPアドレスをIPとし、ハッシュ関数をHとし、ハッシュ引数の変換関数をfとし、16進数表現をhと表記する。Hmodfn例えば、n1000、IPR1のfe80112233445566789aの場合Hmodh1000mod1000mod1353981000398表2は、共有セグメント5ごとに生成されるフロー配信テーブル436を示す。フロー配信テーブル436は、フローIDと、フローのSアドレスと、フローのGアドレスと、フローハッシュ値Hashと、フローの配信担当であるIFと、フローの配信状態とを対応づけて格納する。フローの配信状態は、配信中Joinか、未配信Leaveか、いずれかの値をとる。例えば、フローIDF1のフローは、IFR3から配信され、他のIFからは配信されない。フロー配信テーブル436のフローハッシュ値は、フローのS,Gアドレス情報を定数nで剰余算modした結果である。Sアドレスは、レポート内のICMPv6ヘッダのMulticastAddressから読み取ることができ、Gアドレスは、レポート内のICMPv6ヘッダのSourceAddress1~Nから読み取ることができる。なお、以下では、ハッシュ関数の引数として、フローのS,Gアドレス情報を用いたが、他のフローの識別情報Sアドレスを単体で用いる、Gアドレスを単体で用いる、などを代わりに引数として用いてもよい。以下、ハッシュ空間の大きさをnとし、ハッシュ引数であるフローのS,Gアドレス情報をSGとし、ハッシュ関数をHとし、ハッシュ引数の変換関数をfとし、16進数表現をhと表記する。Hmodfn例えば、n1000、SF1の20011000200030004000、GF1のff3e0001000200030004の場合Hmodhh1000mod1000mod1000114以上説明したIFハッシュ値およびフローハッシュ値それぞれについて、ネットワーク管理者がハッシュキーやハッシュ値を手動で設定してもよい。なお、ハッシュ関数は、必ずしも剰余算である必要はなく、一般的に用いられるその他のハッシュ関数を用いてもよい。ただし、同じ共有セグメント5内で配信制御の一貫性を保つため、ハッシュ値の計算方法は、同じ共有セグメント5に接続される配信ルータ4間で共通の方法とするほうがよい。なお、フローハッシュ値の計算において、互いに異なる2つのIF2つの引数であっても、ハッシュ関数により射影されるハッシュ空間内のハッシュ値が偶然一致してしまうハッシュ衝突が発生することもある。ハッシュ衝突が発生したときには、SNMPSimpleNetworkManagementProtocolコマンドなどで、ネットワーク管理者に衝突発生を警告する。または、フロー割当処理部435は、ハッシュ衝突が発生したときには、以下の1~4に示すハッシュ衝突の回避処理を実行してもよい。1互いに衝突しない全てのIFハッシュ値を、そのままハッシュ空間に配置する。2衝突する複数のIFハッシュ値のうち、そのIFハッシュ値の計算に使用されるIPアドレスが最小のIFハッシュ値を、そのままハッシュ空間に配置する。なお、この2の衝突判定は、IF集合の構成変更IFの増設やIFの障害回復のたびに実行される。3前記2で衝突する複数のIFハッシュ値のうち、2でハッシュ空間に配置されなかったIFハッシュ値については、そのIFハッシュ値とは別の場所例えば、IFハッシュ値を起点として右回りにn/8分ずつ順に移動した場所に補正して、ハッシュ空間に配置する。4IF集合の構成変更IFの減設やIFの障害発生により、すでにハッシュ空間に配置されたIFハッシュ値を削除するときには、その削除したIFハッシュ値が2でハッシュ空間に配置されたIFハッシュ値なら、3で補正して配置されたIFハッシュ値を、補正前のIFハッシュ値へと戻す。この4を実現するために、衝突する複数のIFハッシュ値を管理するデータ構造例えば、リスト構造を用意する。図4は、配信処理およびその前準備処理を示すフローチャートである。S101として、各配信ルータ4は、自身への電源投入などを契機に、両テーブルIF状態管理部433が生成するIF管理テーブル434、フロー割当処理部435が生成するフロー配信テーブル436を初期化する。なお、S101で初期化された両テーブルは、例えば配信ルータ4のシャットダウン時などに削除される。IF状態管理部433は、自IFのエントリをIF管理テーブル434に新規追加する。エントリ内容は、自IFのIPアドレス、そのIPアドレスのIFハッシュ値、自IFであることを示す自IFのIFフラグ、クエリアタイマGQ受信死活監視の無効化である。S102として、配信ルータ4R1は、共有セグメント5にクエリを送信するとともに、他IFからのクエリを受信する。S103として、配信ルータ4R2のIF状態管理部433は、S102で受信したクエリに記載されたIFを、自身のハッシュ空間に登録する。具体的には、IF状態管理部433は、受信パケットのIPヘッダから読み込んだ送信元IPアドレスを検索キーとして、IF管理テーブル434からその検索キーのエントリ以下、クエリエントリとするが存在するか否かを検索する。クエリエントリが存在するときには、そのクエリエントリのクエリア死活監視タイマ=0とする。クエリエントリが存在しないときには、IF管理テーブル434に対してクエリエントリを新規追加する。エントリ内容は、クエリの送信元IPアドレス、その送信元IPアドレスのIFハッシュ値、他IFであることを示す他IFのIFフラグ、クエリア死活監視タイマ=0である。図5は、図3bで示したリング状のハッシュ空間に、両ハッシュ値IFハッシュ値、フローハッシュ値を配置した旨を示す説明図である。図5aは、ハッシュ空間に3つのIFハッシュ値を配置した図である。S103のハッシュ空間の登録処理の一例として、配信ルータ4R3のIFハッシュ値136と、配信ルータ4R1のIFハッシュ値398と、配信ルータ4R2のIFハッシュ値767とが、それぞれ配置されている。そして、ハッシュ空間での方向距離に基づいて、フローを割り当てる。例えば、配信ルータ4R1の配信担当となるハッシュ空間は、自身より1つ前左回りに位置する配信ルータ4R3のIFハッシュ値1361を起点として、右回りに自身のIFハッシュ値398までの範囲である。図4に戻り、S111として、ホスト6は、クエリに対するレポートを返信する。ここでは、そのレポートにフローF1~F4に対する配信要求を示すJoinが含まれているとする。S112として、各配信ルータ4のフロー割当処理部435は、S111のレポートを参照して、各自のハッシュ空間にF1~F4を登録する詳細は図8参照。その結果、配信ルータ4R1はフローF2,F3の配信を担当し、配信ルータ4R2はフローの配信を担当しないものとする。図5bは、図5aのハッシュ空間に対して、フローハッシュ値を配置した例を示す。例えば、フローF1のフローハッシュ値114が、配信ルータ4R3のIFハッシュ値136の近傍に配置されている。フロー割当処理部435は、IFハッシュ値とフローハッシュ値との方向距離をもとに、各フローを担当するIFを決定する。例えば、図5aで示したように、配信ルータ4R1の配信担当となるハッシュ空間は、配信ルータ4R3のIFハッシュ値1361を起点として、右回りに自身のIFハッシュ値398までの範囲であるので、この範囲に含まれるフローハッシュ値177のフローF5は、配信ルータ4R1の配信担当となる。以下、IFハッシュ値Rおよびフローハッシュ値Fが計算されたハッシュ空間から、フローハッシュ値ごとに担当するIFハッシュ値を決定する方法を示す。ハッシュ距離DRFとし、各Fについて、もし、D≧0が1つ以上存在するときには、D≧0のうちの最小値となるRをFの配信担当として割り当てる。一方、D≧0が存在しないときには、Dが最小値となるRをFの配信担当として割り当てる。図4に戻り、S113として、配信サーバ1は、S111のJoinで指定されたフローF2のデータを共有セグメント5に配信する。このデータは、共有セグメント5に接続されているすべての配信ルータ4が受信可能であるが、今回はS112でフローF2の配信担当である配信ルータ4R1がホスト6に対してフローF2を配信する。S121として、ホスト6は、S111と同様にクエリに対するレポートを返信する。ここでは、そのレポートにフローF5に対する配信要求を示すJoinが含まれているとする。S122として、各配信ルータ4のフロー割当処理部435は、S112と同様に、S121のレポートを参照して、各自のハッシュ空間にフローF5を登録する詳細は図8参照。その結果、配信ルータ4R2はフローF5の配信を担当する。S123として、S113と同様に、配信ルータ4R2は、自身の配信担当であるフローF5をデータ配信する。S131として、ホスト6は、クエリに対するレポートを返信する。ここでは、そのレポートにフローF5に対する離脱要求を示すLeaveが含まれているとする。S132として、各配信ルータ4のフロー割当処理部435は、今回Leaveを受信したホスト6とは別のホスト6引き続きフローF5の配信を要求するホスト6が共有セグメント5内に存在しないときには、フロー配信テーブル436のハッシュ空間からフローF5を削除する。なお、フロー配信テーブル436内のエントリを削除する代わりに、そのエントリを休止中Leaveの状態に移行するとともに、後にそのエントリに対するJoinを受信したときには、休止中Leaveから活動中Joinへと状態遷移してもよい。このように、フロー配信テーブル436内に休止中のエントリを記憶し続けることで、フロー配信テーブル436のサイズは大きくなってしまうものの、休止中のエントリの再登録をせずに状態遷移するだけで済むので、配信制御を早期再開することができる。図6は、IF集合の構成変更処理を示すフローチャートである。S201として、フロー割当処理部435は、図4のS112,S122,S132などで説明したように、Joinされた各フローを担当する配信ルータ4のIFを計算する。ここでは、配信ルータ4R1がフローF5を担当し、配信ルータ4R2がフローF2,3を担当し、配信ルータ4R3がフローF1,4を担当するものとする。S211として、ネットワーク管理者が、共有セグメント5に配信ルータ4R4を増設または障害回復したとする。S212として、配信ルータ4R4は、自身のIFを示すIPアドレスを含めたクエリを共有セグメント5に送信することで、他の配信ルータ4R1~R3に自身の増設を通知する。S213として、他の配信ルータ4R1~R3のIF状態管理部433は、S212で通知された配信ルータ4R4のIFをハッシュ空間に登録するS103と同様の処理。S214として、各配信ルータ4のフロー割当処理部435は、IP集合の構成変更に伴い、更新されたハッシュ空間でのフロー担当を計算する。その結果、S201からの変更分として、フローF4の担当がR3からR4へと変更されるものの、他のフローF1~F3の担当は変更されない。このように、フローの担当変更が少ない理由として、図5bで示したようなリング上のハッシュ空間にIFハッシュ値を配置していくため、IFハッシュ値の増減の影響が局所的で済むことが、挙げられる。図7は、リング状のハッシュ空間においてIF集合の構成変更例を示す説明図である。図7aは、図5bの状態から、さらに配信ルータ4R4のIFIFハッシュ値=965が増設または障害回復されたときのハッシュ空間を示す。前回の配信ルータ4R3のIFの担当範囲R2→R3が、今回の配信ルータ4R4のIFの担当範囲R2→R4と、今回の配信ルータ4R3のIFの担当範囲R4→R3とに分割されている。図6に戻って、S221として、配信ルータ4R4に障害が発生しまたは減設され、配信ルータ4R4からのクエリが送信不可になったとする。S222として、他の配信ルータ4R1~R3のIF状態管理部433は、配信ルータ4R4からのクエリ受信のタイムアウトを検出し、ハッシュ空間から配信ルータ4R4のIFを削除する。具体的には、IF状態管理部433は、IF管理テーブル434に登録されたルータインタフェースの各エントリに対し、予め設定したクエリア死活監視用タイマの上限値に達しても当該インタフェースからのクエリを受信しないことを、タイムアウトとして検出判定する。そして、タイマ上限値を超過したエントリを削除する。ここで、IF状態管理部433は、タイマ上限値を超過したIF管理テーブル434のエントリを削除する代わりに、そのエントリを休止状態へ移行することとしてもよいS132と同様の状態遷移処理。S223として、フロー割当処理部435は、S222のIP集合の構成変更IF削除に伴い、更新されたハッシュ空間でのフロー担当を計算する。その結果、フローF4の担当がR4からR3へと戻ることで、S201の配信担当の状態へと戻る。図7bは、図7aの状態から、IFR4に障害が発生したときまたは減設されたときのハッシュ空間を示す。配信ルータ4R4のIFハッシュ値965を削除することで、前回の配信ルータ4R4のIFの担当範囲R2→R4と、前回の配信ルータ4R3のIFの担当範囲R4→R3とが、今回の配信ルータ4R3のIFの担当範囲R2→R3へと統合されている。図8は、フロー割当処理部435が実行するフローの割当処理図4のS112,S122を示すフローチャートである。本フローチャートの動作主体はフロー割当処理部435であるので、各処理ステップでの説明において、その動作主体の記載を省略する。S301として、ホスト6から受信したJoinが示すフローS,Gに対する既存エントリがフロー配信テーブル436内に存在するか否かを検索する。S301でYesならS303へ進み、NoならS302へ進む。S302として、フロー配信テーブル436にフローS,Gを新規のエントリとして登録する。エントリ内容は、フローS,Gのアドレス、そのS,Gアドレスから計算したフローハッシュ値、フローハッシュ値に対応するハッシュ空間内の配信担当IFである。S303として、フロー配信テーブル436内のフローS,Gの配信状態がLeaveであるか否かを参照し、フローが未配信の状態か否かを判定する。S303でYesならS304へ進み、Noなら図8の処理を終了する。S304として、フロー配信テーブル436内のフローS,GののIF列を自身が収容しているか否かを参照し、自身が配信担当か否かを判定する。S304でYesならS305へ進み、Noなら図8の処理を終了する。S305として、フローS,Gの配信を開始する。具体的には、フロー配信テーブル436内の配信状態をJoinとしてから、配信フィルタ部437に対してフィルタの開放を指示し、MC配信網連携部432を介して配信サーバ1に配信要求PIM-Joinを送信する。以上説明した本実施形態では、図1で示したように、複数台の配信ルータ4を単一の共有セグメント5へと接続し、その複数台の配信ルータ4間でフロー単位に配信担当を割り当てることで、マルチキャスト配信処理におけるアクセス分散を実現する。つまり、系全体としての冗長構成による障害リスク分散だけでなく、障害が発生していないときでも配信ルータ4間でそれぞれ自身の配信担当のフローを配信するので、アクセス収容効率が向上する。一方、フロー単位に配信担当を割り当てないと、パケットコピー処理などに必要な配信ルータ4の計算資源や、パケット配信処理に必要な共有セグメント5上の配信パス帯域の通信資源は有限であるため、特定の資源に負荷が集中する。それにより、システム全体の資源利用効率が低下し、輻輳によるパケット損失や遅延ゆらぎの増加などのサービス品質の劣化がユーザの利便性を低下させる。ここで、負荷集中をシステム増強で安易に緩和するだけでは、過剰コストが発生してしまう。各配信ルータ4は、図5で示したようなリング型のハッシュ空間を定義して、そのハッシュ空間に収まるようにIFハッシュ値とフローハッシュ値の両方を計算する。そして、IFハッシュ値とフローハッシュ値の方向距離に基づき、フローごとの配信担当を特定する。そのため、配信ルータ4の増減設/障害切替/回復切戻などの各イベントにより、共有セグメント5へと接続された配信ルータ4の構成変更が発生しても、リング型に閉じたハッシュ空間での方向距離に基づいたフロー割当を再計算するため、構成変更が発生したIFハッシュ値に近接するフローを収容変更するだけで済むので、フローの配信処理の不安定の影響を局所的にすることができる。よって、配信の品質および信頼性を保ちつつ設備需要の変動に柔軟に対応可能なIPマルチキャスト配信サービスが提供可能となる。なお、ハッシュ値を計算するための引数として、IFの識別情報IPアドレスなどや、フローの識別情報S,Gアドレス情報などを用いることで、ハッシュ計算の引数にはIF数を含めなくてもよい。つまり、配信ルータ4の構成変更が発生しても、構成変更されていない多くの配信ルータ4のIFハッシュ値が変わらないので、フローの配信処理の不安定の影響を局所的に限定することができる。さらに、ハッシュ計算の引数となる識別情報は、接続される全てのIFおよびホスト間で交換される制御パケットマルチキャスト/ブロードキャストを検出監視することで、容易に取得することができる。よって、既存のプロトコルのパケットフォーマットクエリやレポートをそのまま活用できるので、ルータ/ホスト間で特別な制御情報を交換することなく、スケーラブルで簡素な方法で、各ルータが自律分散的にフローごとの配信担当を特定することができる。以上説明したように、単一の共有セグメント5へと接続された複数台の配信ルータ4が、それぞれの配信担当のフローを配信ルータ4の構成変更に対しても柔軟に対応するため、配信品質および信頼性を維持しつつトラヒック需要の変動に強いマルチキャスト配信制御が可能となり、地上デジタル放送/BSデジタル放送のIP再送信サービスなどのような、高品質かつ高信頼性なIPマルチキャスト配信サービスが実現可能となる。"