(57)【要約】【課題】Ｐ４Ｐ利用のコンテンツ配信アプリケーションにおいて、ポリシーに従ってトラヒック量を制御するトラヒック制御システム及び方法を提供する。【解決手段】アプリケーションから要求コンテンツのピアリスト及び容量関連の情報とを含む配信コンテンツ情報を受信し、通信相手を選択して通知するトラヒック制御システム１を、当該コンテンツ配信が行われるネットワークの情報を保存するネットワーク情報管理部２と、ネットワーク間のトラヒックに関するポリシーを保存するポリシー管理部３と、ネットワーク間のトラヒックの累積情報を保持し、該累積情報と前記配信コンテンツ情報とに基づいて前記ポリシーに従うよう前記通信相手を選択して前記アプリケーションに通知し、当該選択された通信相手を用いたコンテンツ配信により発生するトラヒックに基づいて前記累積情報を更新するトラヒック管理部４とを備えて構成する。【選択図】図３
2012029133.tif 000002
【特許請求の範囲】
【請求項１】
P2P通信によるコンテンツ配信を利用するアプリケーションから要求コンテンツのピース片を保有した通信相手候補のピアリストの情報と、当該要求コンテンツの容量に関連する情報と、を含む配信コンテンツ情報を受信し、該アプリケーションに対して当該コンテンツ配信により発生するトラヒックを制御するよう通信相手を選択して通知するトラヒック制御システムであって、
当該コンテンツ配信が行われるネットワーク内の各ネットワークを区別するネットワーク情報を保存するネットワーク情報管理部と、
前記ネットワーク情報に従って区別されたネットワーク間におけるトラヒックに関するポリシーを保存するポリシー管理部と、
前記区別されたネットワーク間のトラヒックの累積情報を保持し、該累積情報と前記配信コンテンツ情報とに基づいて前記ポリシーに従うよう前記通信相手を選択して前記アプリケーションに通知し、当該選択された通信相手を用いたコンテンツ配信により発生するトラヒックに基づいて前記累積情報を更新するトラヒック管理部とを備えることを特徴とするトラヒック制御システム。
【請求項２】
前記トラヒック制御システムと前記アプリケーションとが第１ネットワークに属し、前記通信相手候補のピアリストに含まれるピアに第２ネットワークに属するピアが含まれ、前記ネットワーク情報が、前記第１ネットワークと前記第２ネットワークとを区別する情報であることを特徴とする請求項１に記載のトラヒック制御システム。
【請求項３】
前記トラヒック管理部は前記第１ネットワークと前記第２ネットワーク間のトラヒックに関するポリシーを満たす範囲で前記第２ネットワークに属する通信相手を選択し、前記要求コンテンツのピース片のうち当該第２ネットワークから選択された通信相手が保有しないピース片を保有する通信相手をさらに前記第２ネットワーク以外のネットワークから選択することを特徴とする請求項２に記載のトラヒック制御システム。
【請求項４】
前記ポリシーが、前記区別されたネットワーク間の各回線における所定期間内のトラヒック量の上限及び下限の少なくとも一方を定めることを特徴とする請求項１または３に記載のトラヒック制御システム。
【請求項５】
前記トラヒック管理部が、前記ポリシーにて定められた上限及び下限の少なくとも一方と、前記所定期間内において前記配信トラヒック情報を受信した時点での期間経過割合と、に基づいて当該受信時点における累積トラヒックの上限目標値及び下限目標値の少なくとも一方を設定し、前記更新される累積情報が当該上限及び下限の少なくとも一方の目標値の範囲に収まるよう前記通信相手を選択することを特徴とする請求項４に記載のトラヒック制御システム。
【請求項６】
前記受信時点における累積トラヒックの上限目標値及び下限目標値がそれぞれ前記ポリシーにて定められた上限及び下限と前記期間経過割合との積で与えられることを特徴とする請求項５に記載のトラヒック制御システム。
【請求項７】
P2P通信によるコンテンツ配信を利用するアプリケーションから要求コンテンツのピース片を保有した通信相手候補のピアリストの情報と、当該要求コンテンツの容量に関連する情報と、を含む配信コンテンツ情報を受信し、該アプリケーションに対して当該コンテンツ配信により発生するトラヒックを制御するよう通信相手を選択して通知するトラヒック制御システムであって、
当該コンテンツ配信が行われるネットワーク内の各ネットワークを区別するネットワーク情報を保存するネットワーク情報管理部と、
前記ネットワーク情報に従って区別されたネットワーク間におけるトラヒックに関するポリシーを保存するポリシー管理部と、
前記区別されたネットワーク間に配置されたルータにアクセスして当該ネットワーク間の実トラヒック情報を受信し、該実トラヒック情報と前記配信コンテンツ情報とに基づいて前記ポリシーに従うよう前記通信相手を選択して前記アプリケーションに通知するトラヒック管理部とを備えることを特徴とするトラヒック制御システム。
【請求項８】
P2P通信によるコンテンツ配信を利用するアプリケーションから要求コンテンツのピース片を保有した通信相手候補のピアリストの情報と、当該要求コンテンツの容量に関連する情報と、を含む配信コンテンツ情報を受信し、該アプリケーションに対して当該コンテンツ配信により発生するトラヒックを制御するよう通信相手を選択して通知するトラヒック制御方法であって、
当該コンテンツ配信が行われるネットワーク内の各ネットワークを区別するネットワーク情報を保存するネットワーク情報管理段階と、
前記ネットワーク情報に従って区別されたネットワーク間におけるトラヒックに関するポリシーを保存するポリシー管理段階と、
前記区別されたネットワーク間のトラヒックの累積情報を保持し、該累積情報と前記配信コンテンツ情報とに基づいて前記ポリシーに従うよう前記通信相手を選択して前記アプリケーションに通知し、当該選択された通信相手を用いたコンテンツ配信により発生するトラヒックに基づいて前記累積情報を更新するトラヒック管理段階とを備えることを特徴とするトラヒック制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、トラヒック制御システム及び方法に関し、特にコンテンツ配信アプリケーションが発生するトラヒック量を、ネットワーク運用者のポリシーに従って制御するトラヒック制御システム及び方法に関する。
【背景技術】
【０００２】
従来技術として、以下の非特許文献１に示すP4P（Provider Portal for Applications）は、P2P(ピアツーピア)技術を用いたコンテンツ配信により、AS(自律システム：Autonomous System)間またはISP（インターネット  サービス  プロバイダ）内部のトラフィックが増加し、バックボーンを非常に圧迫している状況を踏まえて、複数のASがネットワーク情報公開し、P2P配信サービス側でこの情報を利用し、ASと配信サービスが互いに協力することで双方にとって効率良い配信を行う仕組みである。AS内部に設置されるネットワーク情報サーバ(iTracker)が、配信制御サーバ(appTracker)に対して、自身のネットワークにとって配信効率が良いピアの情報を提供する。ピア(要求ピア)がコンテンツを要求すると、appTrackerは自身が持つピア(候補ピア)の情報を、接続可能なピア情報としてiTrackerへ通知する。iTrackerは自身が持つネットワーク情報を元に、要求ピアと候補ピアのネットワーク的な距離を計算し、その距離が短いものを優先的に選択し、ピアリストとしてappTrackerに返答する。ここで、ネットワーク情報としては、予め運用者が定めたアドレス空間の集合を示すPID（Partition ID）や、AS番号が用いられる。要求ピアと候補ピアが、同じPID内になる割合を70%、同じAS内になる割合を80%という形で、同一ネットワーク上で通信が発生するように制御し、効率的な配信を実現している。また標準化機関であるIETF(Internet Engineering Task Force)では、以下の非特許文献２に示すように、上記P4Pの仕組みのうち、P2P配信システムと、ネットワーク側の制御サーバの間のプロトコルの標準化をALTO（Application Layer Traffic Optimization） WG (Working Group)において実施している。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】P4P:Provider Portal for Applications                        http://www.cs.washington.edu/homes/arvind/papers/p4p.pdf
【非特許文献２】IETF ALTO WGhttp://tools.ietf.org/wg/alto/
【発明の概要】
【発明が解決しようとする課題】
【０００４】
従来技術のP4Pにおいては、同じPID内で通信を行う割合を制御することで、トラヒック制御を行っている。このため、ある回線の１か月のトラヒック量を1TB(テラバイト)以下にするといった、絶対量としての制御ができないという問題があった。
【０００５】
また、ALTO WGでは、P2P配信システム−ネットワーク制御サーバ間の通信手順や、本通信手順において運ばれるネットワーク情報のフォーマットは規定しているものの、トラヒック制御を行うための仕掛けについては規定していない。
【０００６】
本発明の目的は上記した従来技術の課題を解決し、ネットワーク情報を考慮したP2PすなわちP4Pにおけるコンテンツ配信アプリケーションに対して、ポリシーに従ってトラヒック量を制御するトラヒック制御システム及び方法を提供することにある。
【課題を解決するための手段】
【０００７】
上記課題を解決するため、本発明は、P2P通信によるコンテンツ配信を利用するアプリケーションから要求コンテンツのピース片を保有した通信相手候補のピアリストの情報と、当該要求コンテンツの容量に関連する情報と、を含む配信コンテンツ情報を受信し、該アプリケーションに対して当該コンテンツ配信により発生するトラヒックを制御するよう通信相手を選択して通知するトラヒック制御システムにおいて、当該コンテンツ配信が行われるネットワーク内の各ネットワークを区別するネットワーク情報を保存するネットワーク情報管理部と、前記ネットワーク情報に従って区別されたネットワーク間におけるトラヒックに関するポリシーを保存するポリシー管理部と、前記区別されたネットワーク間のトラヒックの累積情報を保持し、該累積情報と前記配信コンテンツ情報とに基づいて前記ポリシーに従うよう前記通信相手を選択して前記アプリケーションに通知し、当該選択された通信相手を用いたコンテンツ配信により発生するトラヒックに基づいて前記累積情報を更新するトラヒック管理部とを備えることを第１の特徴とする。
【０００８】
また、前記トラヒック制御システムと前記アプリケーションとが第１ネットワークに属し、前記通信相手候補のピアリストに含まれるピアに第２ネットワークに属するピアが含まれ、前記ネットワーク情報が、前記第１ネットワークと前記第２ネットワークとを区別する情報であることを第２の特徴とする。
【０００９】
また、前記トラヒック管理部は前記第１ネットワークと前記第２ネットワーク間のトラヒックに関するポリシーを満たす範囲で前記第２ネットワークに属する通信相手を選択し、前記要求コンテンツのピース片のうち当該第２ネットワークから選択された通信相手が保有しないピース片を保有する通信相手をさらに前記第２ネットワーク以外のネットワークから選択することを第３の特徴とする。
【００１０】
また、前記ポリシーが、前記区別されたネットワーク間の各回線における所定期間内のトラヒック量の上限及び下限の少なくとも一方を定めることを第４の特徴とする。
【００１１】
また、前記トラヒック管理部が、前記ポリシーにて定められた上限及び下限の少なくとも一方と、前記所定期間内において前記配信トラヒック情報を受信した時点での期間経過割合と、に基づいて当該受信時点における累積トラヒックの上限目標値及び下限目標値の少なくとも一方を設定し、前記更新される累積情報が当該上限及び下限の少なくとも一方の目標値の範囲に収まるよう前記通信相手を選択することを第５の特徴とする。
【００１２】
さらに、前記受信時点における累積トラヒックの上限目標値及び下限目標値がそれぞれ前記ポリシーにて定められた上限及び下限と前記期間経過割合との積で与えられることを第６の特徴とする。
【００１３】
また、上記課題を解決するため、本発明は、P2P通信によるコンテンツ配信を利用するアプリケーションから要求コンテンツのピース片を保有した通信相手候補のピアリストの情報と、当該要求コンテンツの容量に関連する情報と、を含む配信コンテンツ情報を受信し、該アプリケーションに対して当該コンテンツ配信により発生するトラヒックを制御するよう通信相手を選択して通知するトラヒック制御システムであって、当該コンテンツ配信が行われるネットワーク内の各ネットワークを区別するネットワーク情報を保存するネットワーク情報管理部と、前記ネットワーク情報に従って区別されたネットワーク間におけるトラヒックに関するポリシーを保存するポリシー管理部と、前記区別されたネットワーク間に配置されたルータにアクセスして当該ネットワーク間の実トラヒック情報を受信し、該実トラヒック情報と前記配信コンテンツ情報とに基づいて前記ポリシーに従うよう前記通信相手を選択して前記アプリケーションに通知するトラヒック管理部とを備えることを第７の特徴とする。
【００１４】
また、上記課題を解決するため、本発明は、P2P通信によるコンテンツ配信を利用するアプリケーションから要求コンテンツのピース片を保有した通信相手候補のピアリストの情報と、当該要求コンテンツの容量に関連する情報と、を含む配信コンテンツ情報を受信し、該アプリケーションに対して当該コンテンツ配信により発生するトラヒックを制御するよう通信相手を選択して通知するトラヒック制御方法であって、当該コンテンツ配信が行われるネットワーク内の各ネットワークを区別するネットワーク情報を保存するネットワーク情報管理段階と、前記ネットワーク情報に従って区別されたネットワーク間におけるトラヒックに関するポリシーを保存するポリシー管理段階と、前記区別されたネットワーク間のトラヒックの累積情報を保持し、該累積情報と前記配信コンテンツ情報とに基づいて前記ポリシーに従うよう前記通信相手を選択して前記アプリケーションに通知し、当該選択された通信相手を用いたコンテンツ配信により発生するトラヒックに基づいて前記累積情報を更新するトラヒック管理段階とを備えることを第８の特徴とする。
【発明の効果】
【００１５】
前記第１の特徴によれば、当該コンテンツ配信により発生するネットワーク間のトラヒック量をポリシーに従って制御できる。前記第２、第３の特徴によればさらに、特に前記第１ネットワークと前記第２ネットワークとの間の回線に例えば課金契約がある場合などにもトラヒック量の制御ができる。前記第４〜第６の特徴によればさらに、所定期間内のトラヒックを所定範囲内に制御することができる。
【００１６】
前記第７の特徴によれば、当該コンテンツ配信により発生するネットワーク間のトラヒック量を、ルータから取得した実トラヒック量を監視しながら、ポリシーに従って制御できる。
【００１７】
前記第８の特徴によれば、当該コンテンツ配信により発生するネットワーク間のトラヒック量をポリシーに従って制御できる。
【図面の簡単な説明】
【００１８】
【図１】本発明のトラヒック制御装置によりトラヒック制御が実現される流れを示す図である。
【図２】本発明のトラヒック制御対象を示す図である。
【図３】本発明のトラヒック制御システムの構成を示すブロック図である。
【図４】自身のネットワークと隣接ネットワークとを区別するネットワーク情報の例を示す図である。
【図５】ポリシーの例を示す図である。
【図６】トラヒック制御が行われる具体例における構成を示す図である。
【図７】本発明のトラヒック制御装置に対してアプリケーションから問い合わせがあった際の処理の流れを示すフロー図である。
【図８】目標通信相手の算出方法を示す概念図である。
【図９】問い合わせ受信時に用いる上限目標値及び／又は下限目標値を設定する各実施形態を示す図である。
【図１０】図６の構成に対応する、実トラヒック量に基づく実施形態における構成を示す図である。
【図１１】本発明のトラヒック制御システムの実トラヒックに基づく実施形態における構成を示すブロック図である。
【発明を実施するための形態】
【００１９】
以下に、図面を参照して本発明を詳細に説明する。図１は、ハイブリッド型P2P配信システムにおいて本発明のトラヒック制御システム１を用いることによってP4Pにおいてトラヒック制御が実現される流れの概略を示す図である。ネットワークＮ１には当該配信システムに参加する各ノードのノードＡ、ノードＢ、…と、P4PにおけるappTrackerすなわち配信制御サーバと、トラヒック制御システム１が存在する。トラヒック制御システム１は後述するようにP4PにおけるiTrackerの役割と、本発明におけるトラヒック制御の役割とを担う。
【００２０】
またネットワークN1には隣接ネットワークとしてネットワークN2、N3、…、Nnがあり、各隣接ネットワークにも当該配信システムに参加するノードが存在している。これら隣接ネットワークN2、N3、…、NnとネットワークN1との間にはそれぞれ回線L2、L3、…、Lnが存在する。各ノード（ピア）はコンテンツ要求ノードであり同時にコンテンツのピース片を保有する候補ピアである。
【００２１】
なお、これらネットワークはオーバーレイネットワークではなくIPネットワークであり、物理的なネットワーク間の回線L2、L3、…、Lnにおけるトラヒックが制御対象となる。なおまた要求対象となるコンテンツは既に１回以上配信が行われ、ネットワーク上にピース片として存在し、且つその所在が配信制御サーバにて把握されているものとする。
【００２２】
所定のコンテンツを要求するノードＡは、（ａ）に示すように各コンテンツをピース片として保有しているピアのアドレスを管理している配信情報サーバに対して当該コンテンツを要求している旨を送信して、コンテンツのピース片毎のピアリストを受け取る。当該ピアリストはピース片の保有アドレス情報は含まれるが、実際にネットワーク上で通信する際の効率は考慮されておらず、最終的な通信相手の候補リストである。
【００２３】
ノードＡは当該ピアリストをさらに（ｂ）に示すように、当該要求コンテンツの情報と共にトラヒック制御システム１に送信する。当該送信はピアリストから最終的な通信相手の選択を要求するための送信であるので、当該送信を問い合わせとも呼ぶ。トラヒック制御システム１は受信したピアリストとコンテンツ情報とを用いて、実際にコンテンツ配信を行うにあたって発生するトラヒックに所定の制御を加えるようにピアリストから通信相手ピアを選択してノードＡに通知する。ノードＡは（ｃ）に示すように当該通知されたピア（保有ノード）と通信を行い、当該要求コンテンツを通知された各ピアから各ピースをダウンロードし、全ピース片を組み合わせて要求コンテンツを得る。
【００２４】
なお本発明においてトラヒック制御を行うにあたっては、コンテンツを要求するノードＡとトラヒック制御システム１とが同一のネットワークN1に属する実施形態を基本とし、ネットワークN1と、N1とは別のネットワークN2、N3、…Nnとの間のトラヒックを制御する。配信制御サーバは当該同一のネットワークN1に必ずしも属している必要はない。また図１ではハイブリッド型P2Pにおける例を示した。ピュア型P2Pの場合は、ハイブリッド型として上述した配信制御サーバとノードＡとトラヒック制御システム１との各役割が単一ノードにおいて担われるものとして同様に本願発明を適用できる。
【００２５】
本発明が対象とするトラヒック制御は図１における各回線L2、L3、…、Lnを対象とする。次に図２を用いてこのトラヒック制御対象について述べる。図２は、図１において二つの隣接するネットワークN1, N2のみに着目したものであり、その間の回線L２（上り／下り）と、それぞれのネットワークに点在するノードから構成される形態を示す。ネットワークN1には前述のようにトラヒック制御システム１とコンテンツ配信要求ノードＡとが存在する。図２においてノードとは、図１の場合の要求ノード／候補ノードの他にさらに、あるコンテンツの転送に関わるノードであり、コンテンツを提供するコンテンツサーバ、コンテンツを中継するキャッシュノードあるいはキャッシュサーバ、コンテンツを受信するエンドユーザ端末などが相当する。本発明では、この形態において以下のようなトラヒック制御を行うことを想定している。
【００２６】
ネットワークN1の運用者は、ノード間の通信におけるネットワークＮ２との間の回線L2の所定期間（例えば１か月）の使用量(単位はテラバイトなど)を一定値A1以上及び／又はA2未満のような所定範囲に制御する。ここで当該ノード間の通信とは当該コンテンツ配信による通信であり、また当該回線使用量は当該コンテンツ配信に起因する使用量である。なおまた回線L2の当該通信は、後述のネットワーク情報におけるネットワークN2の配下ネットワークとネットワークN1との通信によるものも含む。
【００２７】
このようなトラヒック制御を実現することにより本発明は、例えばネットワークN1とN2がそれぞれ別個のISP(インターネット  サービス  プロバイダ)であるような場合で、ISP間において従量課金の契約を行っている場合に、1日あるいは1カ月など所定期間のトラフィック量を一定量以下に制限したい場合に有用である。
【００２８】
本発明のシステム構成を図３に示す。トラヒック制御システム１は、ポリシー管理部２、ネットワーク情報管理部３及びトラヒック管理部４を備える。トラヒック管理部４は応答部４０を含む。ポリシー管理部２は、ネットワーク運用者により設定されたトラヒック制御に関するポリシーを保存して管理する。ネットワーク情報管理部３は、ネットワーク情報としてアドレス空間とネットワークとの対応付けを管理する。応答部４０は、アプリケーションからの問い合わせ要求に応じて、トラヒック管理部４で選択された通信相手の情報を提供し、アプリケーションとトラヒック制御システム１とのインタフェースを担う。トラヒック管理部４は、個々の要求においてトラヒック試算により通信相手先を選択すると共に当該選択結果から特定の回線のトラヒックを更新する。
【００２９】
なお、本発明においてアプリケーションとはピアやノードを指すものとする。これらは全て同じものを指すが、用語としての着目点が異なる。ピアはP2Pに対等に参加するという点、ノードはネットワーク接続・中継を担うという点に着目している。アプリケーションとはコンピュータで実行されるプログラム自体としてのアプリケーションを意味するのではなく、本願におけるようなP2P／P4P利用コンテンツ配信サービス等を利用する場合に当該ピア又はノードが主体となるという点に着目した用語である。
【００３０】
ネットワーク情報管理部３は、ネットワーク情報を管理して保存する。ネットワーク情報は、図４（ａ）に示すようなネットワークトポロジすなわち自身のネットワークN1と、隣接するネットワークN2-1〜N2-n2及びその配下のネットワークとの接続構成に対応する情報である。同図（ａ）では例えば隣接ネットワークN2-1の配下のネットワークの例としてN3-1、N3-2、…が示されているが、配下のネットワークの層数などは管理対象のネットワークに応じて任意である。ネットワーク接続構成は同図（ａ）に示すようにネットワークN1をルートとするツリー構造として把握されている。対応するネットワーク情報の例を同図（ｂ）に示す。なお前述のように自身のネットワークN1にはトラヒック制御システム１と、コンテンツ配信サービスを受けるため当該トラヒック制御システム１に問い合わせを行うアプリケーションとが存在する。
【００３１】
同図（ｂ）のネットワーク情報は次のように与えられる。すなわち自身のネットワークＮ１並びに各隣接ネットワークN2-1〜N2-n2及び各隣接ネットワークの配下ネットワークにおいて、各ネットワークに属するノードのアドレスが所属するプレフィックスとしてネットワーク情報が与えられる。ネットワーク情報における各ネットワークはこのようなプレフィックスのリストとして構成される。なおプレフィックスとは周知のように、IPアドレスの空間のことであり、IPv4アドレスの場合には、a.b.c.d/xの形式である。例えば自身のネットワークN1は同図（ｂ）に示すようにプレフィックスのリストとして｛P_N1-1, P_N1-2, ...｝としてネットワーク情報が与えられている。ネットワークN1の各隣接ネットワークN2-1,N2-2, ... , N2-n2も同様にそれぞれプレフィックスのリストでネットワーク情報が与えられている。
【００３２】
なおネットワーク情報の形式より明らかなように、ネットワーク情報によって区別されるのは各プレフィックスが自身のネットワークN1に属するか、当該N1に隣接する各ネットワークN2-1〜N2-n2及びその配下ネットワークのいずれかに属するか、のみである。例えばあるピアのアドレスがプレフィクスP_N2-1-1に一致する場合、図４（ｂ）のネットワーク情報により当該ピアはネットワークN2-1又はN2-1配下のネットワークに属するとわかるが、実際に同図（ａ）のネットワークN2-1かN3-1かN3-2又はそのさらに配下のいずれに属するかまでは区別されない。
【００３３】
なおまたネットワーク情報において上述のように隣接ネットワーク以下の区別を設けない形式が採用されていることにより、本発明において次のような効果がある。すなわち、各ピアを通信相手として選ぶにあたってトラヒック管理部４が当該ネットワーク情報を参照することにより、要求ピアが当該各ピアと通信する場合に用いる回線が、自身のネットワークと当該各ピアのアドレスに対応する隣接ネットワークとの間の回線として定まり、当該回線のトラヒック制御が可能になる。
【００３４】
任意のアドレスに対してネットワーク情報のプレフィックスの中から当該アドレスの所属するプレフィックスが周知の最長一致(longest match)により定まる。当該アドレスの所属するネットワークはネットワーク情報により当該アドレスが所属するプレフィックスの属するネットワークとして定まる。こうしてネットワーク情報を参照することで任意のアドレスに対して当該アドレスが所属するネットワークが自身のネットワークN1であるか、その隣接ネットワークN2-1〜N2-n2若しくはそれら各々の配下ネットワークであるか、が一意に定まる。なおこのようなネットワーク情報は運用者が予め与えておくものとする。なおまたネットワーク情報は一般には動的に変動するので、このような変動に対処してネットワーク情報を得るには特願2010-3882号（P2P型通信用ピア情報提供システム）の技術を用いてもよい。
【００３５】
ポリシー管理部２は、ある隣接ネットワークに対して、自身のネットワークとの間のトラヒックの絶対量を制御するポリシーを管理し保存する。ポリシー情報は、運用者が予め入力することを想定している。ポリシーの例を図５に示す。各行には、対象回線、パラメータ、方向、期間及び目標値を含む情報を設定する。対象回線はネットワーク情報管理部２で設定された自身のネットワークとその隣接ネットワークとの間の回線を設定する。目標値は、期間の欄で定める所定期間における上限及び下限の少なくとも一方を設定する。例えば図５においては、１行目は、ネットワークN1−N2-1間の回線に対して、下り方向の1カ月のトラヒック量を5TB以上10TB未満に設定することを示している。２行目は、ネットワークN1−N2-2間の回線に対して、トラヒック量を10GB以下に設定することを示している。
【００３６】
なおここで図５においては図４の例と同様にN1は自身のネットワーク、N2-1、N2-2はN1の隣接ネットワークである。ネットワークN2-1、N2-2以外にもさらにその他の隣接ネットワークとの間のポリシー情報を追加設定してもよい。なおまた、上述のポリシー情報の例において「パラメータ」の欄をトラヒックとして設定したが、当該欄は本発明の拡張として帯域を制御する場合などのために設けられている。「方向」の欄は下りとして設定したが、当該欄も拡張等を考慮した欄である。前述のように、本発明で制御されるトラヒックとは図５の例に示したように各隣接ネットワークから自身のネットワークへの下りトラヒックであり、且つP4Pによるコンテンツ配信を自身のネットワークのアプリケーションが利用するのに起因するトラヒックである。
【００３７】
応答部４０は、アプリケーションとのやりとりにおいてトラヒック制御システム１側のインタフェースの役割を果たす。アプリケーションからの問い合わせを応答部４０が受信すると、トラヒック管理部４がポリシーに従うトラヒック制御を可能とするための通信相手先情報の選択を行って、応答部４０から当該選択結果をアプリケーションに返信する。
【００３８】
図１を用いて概略は説明したが、アプリケーションから送信され応答部４０が受信する情報は詳細には次の通りであり、これらを配信コンテンツ情報と呼ぶこととする。すなわち要求するコンテンツのコンテンツサイズ、ビットレート、通信相手先候補のリスト（配信制御サーバより得たピアリスト）、通信相手先候補の選択数（＝分散数）などの情報を応答部４０は受信する。なおこのような配信コンテンツ情報のうち、コンテンツサイズ（＝容量）及びビットレート（＝容量÷時間）は共に当該コンテンツの容量に関連する情報であり、トラヒック制御を行うにあたって必須の情報である。
【００３９】
トラヒック管理部４では、ポリシー管理部２において設定された各隣接ネットワークとの間の回線における現トラヒック量すなわち累積情報を把握して管理する。またトラヒック管理部４は、アプリケーションからの問い合わせ時に応答部４０を介して受信した配信コンテンツ情報を用いて各ネットワークのポリシーの目標値を達成するための試算を行い、当該試算に基づいて通信相手先候補から通信相手を選択して応答部４０からアプリケーションに結果を返信させる。さらにトラヒック管理部４は当該選択結果に基づいて、管理しているトラヒックの累積情報を更新する。
【００４０】
図５に２行からなるポリシーの例を示したが、ポリシーがこのうち１行目のみからなる場合を具体例として、上記のようなトラヒック管理部４の機能の詳細を説明する。当該具体例における構成を図６に示す。同図に示すように自身のネットワークN1上に、トラヒック制御システム１が存在し、ネットワークN1と、その隣接ネットワークN2-1及び配下のネットワークN3-1、Ｎ3-2、…（これらを一括りにしてネットワークN2とする）と、にはそれぞれ当該コンテンツ配信に参加するn個（a1〜an）、m個(b1〜bm)のノードが存在するものとする。
【００４１】
ネットワークN1内のノードai（i=1〜n）とネットワークN2内のノードbj（j=1〜m）とが当該コンテンツ配信における通信をする場合は必ず回線L2（課金契約などを行っている回線を想定）が使われるものとする。回線L2は多重化や冗長化が施されていてもよいが、当該コンテンツ配信の通信において回線L2とは別の迂回経路などが用いられることはないものとする。
【００４２】
ネットワークN1内のアドレスとネットワークN2内のアドレスはネットワーク情報管理部３において図４（ｂ）で示したようなネットワーク情報により把握されている。ネットワークN1の運用者は、回線L２の下り方向の１か月のトラヒック量を5TB以上10TB未満に抑えるポリシー（図５の１行目のみからなるポリシー）を適用しており、当該ポリシーはポリシー管理部２に保存されている。
【００４３】
ネットワークN1内のノードは、アプリケーションインターフェースを介して、トラヒック制御システム１に通信相手情報の問い合わせを行い、トラヒック制御システム１より通信相手情報を得る。アプリケーションがBitTorrent（登録商標）などのハイブリッド型のP2Pアプリケーションの場合、トラッカーと呼ばれるサーバ機能がアプリケーションインターフェースとなる。また、ピュア型のP2Pアプリケーションの場合、ノード自身がアプリケーションインターフェースを有する。なお前述のように当該問い合わせにおいては同時に配信コンテンツ情報が送信され、トラヒック制御システム１内では応答部４０がノードとのやりとりを担うインタフェースとなる。
【００４４】
トラヒック管理部４では設定ポリシーに記載の各回線（当該具体例の場合はネットワークN1とN2-1間の回線L2のみ）におけるトラヒック累積情報を管理している。ポリシーにおいて設定されるのは所定期間内におけるトラヒック量であるので、トラヒック管理部４では定期的な処理として当該所定期間の開始時に累積情報を初期値ゼロに戻す。当該具体例の場合ならば最初に１か月の始まり（例えば2010年6月であれば、6月1日0時0分0秒）に、ネットワークN1とN2-1間の回線の累積トラヒック量を0に設定する。
【００４５】
図６の構成において時刻t1にコンテンツ配信を希望するネットワークN1内のノードaiからトラヒック制御システム１への問い合わせがあったと仮定する。その際の問い合わせ処理フローを図７、目標通信相手の算出方法を図８に示す。図７に示すようにフローはステップＳ０にて当該問い合わせの受信により開始される。トラヒック管理部４は次にステップＳ１において、t1時点での累積トラヒック量が下限目標値Tlowと上限目標値Thighの間の値（このうち例えばより下限に近い値）に更新されるように目標通信相手数を算出する。当該下限目標値Tlow及び上限目標値Thighはそれぞれポリシーで設定したトラヒックの下限及び上限に基づいて与えられるが、その与え方については後述する。
【００４６】
時刻t1における更新前の値である現累積トラヒック量をT1、当該問い合わせにおける１通信相手あたりのトラヒック量をTpとすると、t1時点の更新後の値となる累積トラヒック量T2を次式（数式１）を満たすように通信相手数kを選択する。
Tlow ≦ T2 = T1 + k×Tp < Thigh        …（数式１）
通信相手数kは（数式１）を満たす任意の数を選んでもよく、T2が最もTlowに近くなるように選んでもよく、又はT2が最もThighに近くなるように選んでもよい。なお、1通信相手あたりのトラヒック量Tpは、ステップS0の問い合わせ時にアプリケーションから受信した配信コンテンツ情報より得られるコンテンツサイズC、分散数＝通信相手数をDの情報を用いて、Tp=C/Dで算出可能である。
【００４７】
なお当該具体例においては上下限の両方が与えられているが、ポリシーにおいて所定期間におけるトラヒック上下限の片方のみが設定されている場合は、（数式１）における２つの不等式のうち対応する片方のみからkを選択すればよい。この場合もTlow又はThighにT2ができるだけ近づくようkを選択してもよい。
【００４８】
次にステップＳ２においてトラヒック管理部４は、ネットワークN2-1よりk個のノードを選択し、残りD−k個をネットワークN1も含めて他のネットワークより選択し、応答部４０を介してアプリケーションに選択結果を通知する。当該残りのD−k個は自身のネットワークN1のみから選択してもよい。
【００４９】
なおステップＳ2においてこのようにピアリスト中の通信相手の中から、各ノードが所属するネットワークに基づいて選択を行うにあたって、トラヒック管理部４はネットワーク情報管理部３で管理されたネットワーク情報を参照して各ノードのアドレス情報から各ノードの所属ネットワークを調べる。なおまた当該各ノードの所属ネットワーク調査は、配信コンテンツ情報を受け取った時点（ステップＳ０）で前もって通信相手候補中の全ノードに対して調査をしておいてもよい。
【００５０】
次にステップＳ３において、要求ノードは当該通知結果通りに通信するのが通常であるため実際にトラヒックが発生したものと仮定し、t1時点で選択したk個のノードからの通信量を加算し、トラヒックの累積情報すなわち累積トラヒック量をT2に変更する。この後ステップＳ４に進んで問い合わせ処理は終了する。
【００５１】
なお、通信相手については、アプリケーションより通知された通信相手候補リストの中から選択される。ネットワークN2-1に存在する通信相手候補が十分に多い場合には、そのうちk個を選ぶことで目標値を達成可能である。しかしながら、N2-1に存在する通信相手候補がk個より少ない場合には、全ての候補を選択してもk個未満となる。このとき、最終的に累積情報が下限目標値に届かないこととなるが、候補リストに含まれる全ての候補を選択することとする。
【００５２】
なおまた、本発明においては各ネットワークに属する通信相手「数」の決定が重要である。よって当該相手数の決定後、実際に通信するピアの選択は、通信相手候補リストから各ネットワークの当該相手数のピアをランダムに選んでもよいし、受信した配信コンテンツ情報に含まれる候補リストに並んでいる順で選んでも良い。また通信相手の選択にあたっては既に選択された通信相手の保有するピース片以外のピース片を所有する相手を選択して、最終的に全ピース片（上記の例ならD個）が揃う必要がある。このような処理はトラヒック管理部４が上記フローにおいてまだピース片を保有するピアが選択相手として選択されていないようなピース片の候補ピアリストを選択相手の探索対象とすることによって適宜実行しているものとする。
【００５３】
ここでステップＳ１において用いた下限目標値Tlowと上限目標値Thighの与え方を図８を用いて説明する。図８は図７のフローに従ってトラヒック制御システム１が自身のネットワークN1内のアプリケーション（ピア）から当該具体例の一ヶ月の間に問い合わせを受け続けるときの、期間内の経過時間に対して設定される下限目標値Tlow及び上限目標値Thigh並びに更新されるトラヒックの累積情報の変化の例を示す図である。
【００５４】
図８より明らかなように、下限目標値Tlow及び上限目標値Thighは共に期間開始時はゼロ（単位：TB）に設定され、所定期間（当該具体例においては１ヶ月内とした）での経過時間に直線的に比例する形で最終的に１ヶ月の期間終了時にポリシーで設定した下限5TB及び上限10TBとなるよう時間変化する。よって例えば前述のt1時点での下限目標値Tlow(t1)及び上限目標値Thigh(t1)は次のように与えられる。
Tlow(t1) ＝ 5TB × (時点t1における所定期間１ヶ月の経過割合)
Thigh(t1) ＝ 10TB × (時点t1における所定期間１ヶ月の経過割合)
図８ではこのように時間変化する上下限目標値を利用することで、問い合わせを受け続ける間のネットワークN1とN2-2間の累積トラヒックが当該目標値内部で推移している。
【００５５】
また、下限目標値Tlow及び上限目標値Thighの設定の実施形態としては図８のような所定期間内の経過割合に比例する実施形態以外であってもよく、一般に期間終了時にポリシー設定値に一致し且つ期間内の時間の経過割合に従って単調増加するように設定することができる。
【００５６】
よって他の実施形態としては例えば図９（ａ）〜（ｄ）に示すように（ａ）所定期間内の最初の部分では大きく直線的に増加して残りの部分では小さく増加する、（ｂ）その逆、（ｃ）曲線的に変化する、（ｄ）ステップ的に変化する、等も可能である。図８のような値がゼロから始まる一本の直線で上下限目標値が設定される実施形態では所定期間内においてトラヒック時間変化を一定に保とうとする効果が得られるが、図９に示すような各実施形態では所定期間内においてトラヒックの時間変化を一定にしないようにする効果が得られる。
【００５７】
なおまた累積トラヒックは期間開始時にゼロに設定されるが、図９の例を含め上下限目標値は期間開始時に必ずしもゼロとしなくともよい。また上限及び下限目標値の両方を用いる場合、両者の時間変化グラフの形・種類は同じでなくともよく、例えば上限に図９（ａ）、下限に同図（ｂ）を用いてもよい。
【００５８】
さらに図１０は、図６を応用した構成である。当該構成は、図６で説明した実施形態において用いた、配信コンテンツ情報やポリシーに基づいて間接的に算出・更新される情報であるトラヒックの累積情報（累積トラヒック）の別実施形態として、回線を流れるトラヒック量を直接的に用いる構成である。図６の実施形態をトラヒック累積情報に基づく実施形態、図１０の実施形態を実トラヒック量に基づく実施形態と呼ぶこととする。
【００５９】
図１０に示すように実トラヒック量に基づく実施形態では、トラヒック制御システム１は、ある時刻での実トラヒック量（実トラヒック情報）をルータから収集し、その結果をトラヒック制御にフィードバックする。トラヒック制御システム１は、ルータに外付けされたNetFlowやsFlowなどのトラヒック集計装置を介して、回線L2を流れる、該当アプリケーションのトラヒック量を収集する。なお当該収集を行う構成は後述のトラヒック収集部４１である。当該実施形態においてはこのような仕組みを導入することで、トラヒック量を累積情報として推定的に把握していたトラヒック累積情報に基づく実施形態と比べ、より正確に回線L2を流れたトラヒック量を測定することができる。
【００６０】
なお図１０に示すルータは、自身のネットワークＮ１に属し、自身のネットワークＮ１と隣接ネットワークＮ２との間の回線Ｌ２に接続されるルータであるので、上述のように当該ルータにアクセスすることによって回線L2を流れたトラヒック量を測定することができる。
【００６１】
実トラヒック量に基づく実施形態におけるトラヒック制御システム１の構成を図１１に示す。当該構成は図３（図６の実施形態におけるトラヒック制御システム１の構成）と比べた追加構成として、ルータにアクセスしてトラヒック量を収集するトラヒック収集部４１がトラヒック管理部４内に存在する。
【００６２】
トラヒック収集部４１は前述のようにルータにアクセスしてNetFlowやsFlowを介してトラヒック量を収集するが、これら従来技術では周知のようにポートやプロトコルを確認することでフローデータの由来アプリケーションを識別できるので、関連する所与の情報を設定しておくことで当該コンテンツ配信によるトラヒック量を把握することができる。
【００６３】
実トラヒック量に基づく実施形態におけるトラヒック制御システム１のトラヒック制御は、トラヒック累積情報に基づく実施形態とほぼ同様であるが、トラヒック制御システム１内で管理保存しておく必要のあるトラヒック累積情報ではなくてルータから随時収集可能な実トラヒック量を利用していることにより、図７のステップＳ３が省略される、という点が異なる。
【００６４】
すなわち、図７のステップＳ１においてt1時点での累積トラヒック量の代わりに、トラヒック収集部４１を介してt1時点でルータにアクセスして収集した実トラヒック量を用いるのであるが、当該実トラヒック量はルータ側で上記NetflowやsFlowによって管理され把握されているのでステップS3の加算・更新作業が不要となる。なおステップS2ではt1時点の実トラヒック量をT1として、（数式１）に従い同様に通信相手数を求める。当該計算においては更新後の値（に対応する値）Ｔ２を利用するが、前述のようにステップＳ３は省略される。
【００６５】
またステップＳ２では、ポリシーにて上限を定めている場合においては、収集した実トラヒック量が既に上限目標値Thighを超えている場合もありうるが、この場合はk=0としネットワークN2からは通信相手を選択しないようにすればよい。
【００６６】
なおまた、トラヒック累積情報に基づく実施形態における作業の、ポリシーで定める所定期間の開始時に累積情報を初期値ゼロに戻すという作業に対応する実トラヒック量に基づく実施形態における作業は、当該実施形態の意義から明らかではあるが、次の通りである。すなわちルータ側で管理される実トラヒック量を、当該ルータが接続するネットワーク間のポリシーにおいて定められた所定期間の開始時点毎にゼロに更新するようトラヒック制御システム１側から働きかける。
【００６７】
また当該更新の別実施形態として、ルータ側では値を更新せずに実トラヒックの累積量を蓄積されるままに管理しておき、トラヒック制御システム１側にてポリシーの定める所定期間の開始時点毎にルータにおける実トラヒック累積量を収集し、各ポリシー期間内は当該期間開始時点の累積量からの差分を上記実トラヒック量として用いるようにしてもよい。
【００６８】
以上のように、実トラヒック量に基づく実施形態ではトラヒック累積情報に基づく実施形態と比べて実トラヒック量を正確に把握できるという効果がある。トラヒック累積情報に基づく実施形態では、通信相手数に比例してトラヒックが発生するという仮定の下でトラヒック量を累積情報として予測していたが、BitTorrent（登録商標）などのアプリケーションでは必ずしも当該仮定が成立するとは限らない。このような場合であっても実トラヒック量に基づく実施形態では正確な制御が可能となる。
【００６９】
また逆に、当該仮定が完全には成立しないにせよある程度妥当な仮定となる状況では、トラヒック累積情報に基づく実施形態は実トラヒック量に基づく実施形態に比べて簡素な構成によってある程度正確な制御が可能となるという利点がある。
【００７０】
なおまた、トラヒック累積情報に基づく実施形態において部分的に実トラヒック量に基づく実施形態における実トラヒック収集作業を併用することも可能である。この場合、トラヒック累積情報を問い合わせ受信とは別に定期的にトラヒック収集部４１で収集した実トラヒック量によって上書き修正すればよい。こうすることによって実トラヒック量に基づく実施形態の場合に問い合わせ毎にルータから実トラヒックを収集する負荷を抑制し、かつ正確なトラヒック制御が可能となる。
【００７１】
以上、図６（及び図１０）のような自身のネットワークN1と隣接する一つのネットワークN2との間にのみポリシーが設定されている具体例を説明した。隣接するネットワークがN2以外にさらにN3、…、Nnのように複数存在してポリシーを設定する場合のトラフィック制御も前述の具体と同様の制御を各隣接ネットワーク毎に順次適用することで実現できる。なお、この場合ネットワークN1-N2間、N1-N3間、…N1-Nn間の回線は図１に示すようにそれぞれ別個の回線L2、Ｌ3、…、Lnであり、通信相手としてネットワークN2、N3、…、Nnのピアが選ばれた場合、当該コンテンツ配信においては対応する回線のみが用いられるものとする。
【００７２】
ネットワークN1-N2間、N1-N3間、…、N1-Nn間のポリシーをP2、P3、…、Pnとすると、ある時点t1でネットワークN1内の要求ピアから問い合わせを受信した場合は次のようにする。すなわち各ポリシーP2、P3、…、Pnによりt1時点で図７のステップＳ１と同様にして各回線での目標通信相手数をそれぞれk2、k3、…、knと求める。コンテンツの分散数がDの場合、まずN2からk2個選択し、残りの(D−k2)個をN3からk3個選択し、残りの(D−k2−k3)個をN4からk4個選択し、以下同様にして分散数D個に達して所望コンテンツの全ピース片が揃うまで選択する。ここでポリシーPiにおける目標通信相手数ki個がネットワークNiに存在しない場合は、Niからki個未満で最大限選択すればよい。ポリシーを設定した隣接ネットワークの全てN2、N3、…、Nnについて通信相手数を算出して通信相手を選択しても分散数D個に達しない場合は、残りの通信相手を自身のネットワークN1及び／またはポリシー設定隣接ネットワークN2、N3、…、Nn以外のネットワークから選択する。
【００７３】
なおこのように隣接ネットワークが複数ある場合、ポリシーに従って通信相手を選択する順番は上記のように例えばP2、P3、…、Pnと所定の順を設定しておくことができる。当該順番はポリシーに追加情報として含めることができる。また当該順番の設定の別実施形態として、上記ステップＳ１と同様にして求めた各回線での目標通信相手数k2、k3、…、knの多い方から順番に選択することもできる。目標通信相手数が多いということは、問い合わせ受信時点t1にて当該回線の累積情報とトラヒック目標値との乖離が大きいということを示唆するので、当該実施形態では各時点において目標から離れた回線を優先して選択して目標に近づけさせることができる。
【００７４】
なお、本発明においてトラヒック制御システム１とコンテンツを要求するアプリケーションとは同一のネットワークに属するのが基本であるとして説明したが、次の（１）、（２）を満たすならば別実施形態としてトラヒック制御システム１が要求アプリケーションと別ネットワークに属する実施形態も可能である。
（１）コンテンツを要求するアプリケーションが属するネットワークを自身のネットワークＮ１として、当該N1をルートとするツリー構造の図４のようなネットワークトポロジに基づくネットワーク情報がトラヒック制御システム１で管理できる。
（２）その他、アプリケーションとトラヒック制御システム１との間で図７に示すような問い合わせ処理のやりとりを行うことできる。
【００７５】
なお上記の実施形態はトラヒック制御システム１が要求アプリケーションの属するネットワークN1のトラヒック制御をリモートで実施する場合に相当する。また同様に、トラヒック制御システム１を構成するポリシー管理部２、ネットワーク情報管理部３、トラヒック管理部４、応答部４０（及び実トラヒックに基づく実施形態ではさらにトラヒック収集部４１）は、それぞれ必ずしもネットワークN1に属していなくてもよい。この場合も、トラヒック制御システム１の各部は別ネットワークに属していても互いに通信して上記（１）（２）を満たすよう機能するものとする。
【００７６】
以上のように、本発明では、アプリケーションからの情報通知などにより通信の絶対量を把握する手段と、トラヒック量を試算することで絶対量に応じてトラヒック制御を行う手段を有することで、絶対量を用いたトラヒック制御を行うことができるようになるという効果がある。
【００７７】
こうして本発明では絶対量をベースとしてトラヒック制御を行うため、ISP間において従量課金の契約を行っている場合などに、所定期間例えば1日あるいは1カ月のトラフィック量を制限したい場合に有用である。
【符号の説明】
【００７８】
１…トラヒック制御システム、２…ポリシー管理部、３…ネットワーク情報管理部、４…トラヒック管理部
【図１】
2012029133.tif 000003
【図２】
2012029133.tif 000004
【図３】
2012029133.tif 000005
【図４】
2012029133.tif 000006
【図５】
2012029133.tif 000007
【図６】
2012029133.tif 000008
【図７】
2012029133.tif 000009
【図８】
2012029133.tif 000010
【図９】
2012029133.tif 000011
【図１０】
2012029133.tif 000012
【図１１】
2012029133.tif 000013