(57)【要約】      （修正有）【課題】従来のオーバーレイネットワークにおける通信経路計算に必要な、オーバーレイノード間での試験パケットによるトラヒック測定を不要とし、ネットワークへの余分な負荷や、オーバーレイノード間での試験パケットによるトラヒック測定に伴う処理負荷・処理遅延等といった測定コスト・オーバヘッドを軽減する。【解決手段】ＩＰネットワーク５３上に論理的に設定された、ノード５１ａ〜５１ｆとリンクと管理サーバ５４で構成される論理ネットワーク（オーバーレイネットワーク５１）において、オーバーレイノードノード５１ａ〜５１ｆ間の品質情報を、ＩＰネットワーク５３で測定されたフロー情報を用いて推定する構成とする。【選択図】図５
2010200026.tif 000002
【特許請求の範囲】
【請求項１】
ＩＰネットワーク上に論理的に設定された、ノードとリンクと管理サーバで構成される論理ネットワーク上でのトラヒック制御方法であって、
上記論理ネットワークを構成する管理サーバは、上記ＩＰネットワークから該ＩＰネットワークのトラヒック情報を収集し、
上記論理ネットワークを構成する各ノードは、上記管理サーバから上記ＩＰネットワークのトラヒック情報を入手し、入手したＩＰネットワークのトラヒック情報を用いて、上記論理ネットワーク上での経路を選定する
ことを特徴とする論理ネットワークのトラヒック制御方法。
【請求項２】
請求項１に記載の論理ネットワークのトラヒック制御方法であって、
上記論理ネットワークを構成するノードは、中継したコンテンツをキャッシュし、キャッシュしたコンテンツの要求に応じて当該キャッシュを要求元に送信する
ことを特徴とする論理ネットワークのトラヒック制御方法。
【請求項３】
請求項１もしくは請求項２のいずれかに記載の論理ネットワークのトラヒック制御方法であって、
上記論理ネットワークを構成する管理サーバは、
上記ＩＰネットワーク上のネットワーク機器が検出するフロー毎のトラヒック情報を収集し、
収集したフロー毎のトラヒックを分析して品質メトリックを推定し、推定結果を上記論理ネットワークを構成するノードに送信する
ことを特徴とする論理ネットワークのトラヒック制御方法。
【請求項４】
請求項１から請求項３のいずれかに記載の論理ネットワークのトラヒック制御方法であって、
上記論理ネットワークを構成するノードは、当該論理ネットワークの提供主体が用意した複数のキャリアノードと、該キャリアノード以外の複数のエンドホストノードからなり、
上記管理サーバは、各キャリアノードを各キャリアノード毎のグループに分けて記憶管理すると共に、各キャリアノード間の接続状態を示す論理トポロジを決定し、決定した論理トポロジ情報を各キャリアノードに送信し、
各キャリアノードは、上記管理サーバから送信された論理トポロジにおける各論理リンクに対して上記トラヒック情報を用いた経路選定を行う
ことを特徴とする論理ネットワークのトラヒック制御方法。
【請求項５】
請求項４に記載の論理ネットワークのトラヒック制御方法であって、
上記管理サーバは、各コンテンツ毎に当該コンテンツを保持するノードを特定したコンテンツ保持リストを保持し、
各エンドホストノードは、所属先として特定されるグループを上記管理サーバに問い合わせ、該管理サーバが特定したグループのキャリアノードから、上記論理トポロジと当該キャリアノードが選択した経路情報を入手し、
コンテンツの要求時、上記エンドホストノードは、上記管理サーバから上記コンテンツ保持リストを入手し、該コンテンツ保持リストを参照して要求するコンテンツの配信元ノードを選定し、選定した配信元ノードに対して当該コンテンツの配信要求を送信し、
コンテンツ配信要求の受信時、上記エンドホストノードは、所属するグループのキャリアノードから入手した経路情報を参照して配信経路を選定し、選定した配信経路における次転送先のグループに所属するエンドホストノードもしくはキャリアノードを中継ノードに指定して要求されたコンテンツを転送し、
中継ノードに指定されたエンドホストノードもしくはキャリアノードは、受信したコンテンツを次転送先のグループに所属するエンドホストノードもしくはキャリアノードに中継転送すると共に、当該コンテンツをキャッシュして、次回の当該コンテンツの配信要求を受信した際に、キャッシュした当該コンテンツを要求元に送信する
ことを特徴とする論理ネットワークのトラヒック制御方法。
【請求項６】
請求項１から請求項５のいずれかに記載の論理ネットワークのトラヒック制御方法であって、
上記論理ネットワークはオーバーレイネットワークからなり、
上記ノードはオーバーレイノードからなることを特徴とする論理ネットワークのトラヒック制御方法。
【請求項７】
ＩＰネットワーク上に論理的に設定された、ノードとリンクと管理サーバで構成される論理ネットワーク上でのトラヒック制御を行うシステムであって、
上記ノードおよび上記管理サーバが、プログラムされたコンピュータ処理を実行する手段として、請求項１から請求項６のいずれかに記載のトラヒック制御方法におけるノードおよび管理サーバによる処理を実行する手段を具備したことを特徴とする論理ネットワークのトラヒック制御システム。
【請求項８】
コンピュータに、請求項１から請求項６のいずれかに記載の論理ネットワークのトラヒック制御方法におけるノードおよび管理サーバによる各処理手順を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネットにおけるエンド・ツー・エンドの通信品質を向上させる技術に係り、特に、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）ネットワーク上に論理的に形成されたオーバーレイネットワーク等の論理ネットワークを用いて、エンド・ツー・エンドの通信品質を効率的に向上させるのに好適な技術に関するものである。
【背景技術】
【０００２】
ＩＰネットワークを代表するインターネットは、多様なアプリケーションの収容を可能とすべく発展・普及してきており、その一方で、ＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）に対する要求も高まってきている。
【０００３】
これに伴い、エンド・ツー・エンドでの輻輳を回避し、品質を向上するための技術（「エンド・ツー・エンドＱｏＳ管理技術」）をインターネット上で実現することが重要な課題となっている。しかしながら、このような技術を実現する上では、以下に示す問題点がある。
【０００４】
（１）インターネットは既に社会的インフラ化しており、既存のネットワーク構造を大きく変更するような、ネットワークレイヤでの新たな機能拡張は困難である。
【０００５】
（２）インターネットは管理主体の異なる複数のＡＳ（Ａｕｔｏｎｏｍｏｕｓ  Ｓｙｓｔｅｍ）によって形成されており、全てのＡＳに対して一斉に新たな機能を拡張することは困難である。
【０００６】
こうした中、下位のネットワークレイヤを変更することなくエンド・ツー・エンドＱｏＳの向上を可能とする有力な技術として、例えば非特許文献１に記載の、オーバーレイネットワークによるＱｏＳ管理技術が注目されている。
【０００７】
オーバーレイネットワークとは、例えば非特許文献２においても記載のように、既存のリンクを用いて、その上位層に目的に応じて論理的（仮想的）なリンクを形成し、構成するネットワークである。
【０００８】
このようなオーバーレイネットワークによるＱｏＳ管理の基本的な概念を図１に例示する。図１において、１ａ〜１ｃはオーバーレイネットワーク（図中「Ｏｖｅｒｌａｙ−ＮＷ」と記載）１を構成するノード（オーバーレイノード）であり、２ａ〜２ｅはＩＰネットワーク（図中「ＩＰ−ＮＷ」と記載）２を構成するＩＰルータであり、ｘからｙに向けて、破線矢印で表わされる経路にトラヒックが流れているとする。また、この経路上には輻輳しているＩＰルータが存在しており、その結果として、ｘ，ｙ間のＱｏＳが低下しているとする。  
【０００９】
このとき、オーバーレイノード１ａ，１ｂ，１ｃで形成されるオーバーレイネットワークを用いて、実線矢印で表される経路（ｘ→オーバーレイノード１ａ→オーバーレイノード１ｂ→オーバーレイノード１ｃ→ｙ）にトラヒックを迂回させることができれば、上記の輻輳を回避できる。
【００１０】
実際、非特許文献３，４，５，６等では、上記のような迂回経路が実網において多数存在していることを実測に基づいて示している。しかし、これらの結果は、全てのオーバーレイノード間で測定した品質情報を利用して理想的な通信経路計算を行った場合の評価となっている。
【００１１】
これら品質情報は、オーバーレイノード間で試験パケットを用いて能動的に測定することによって得られたものであり、ネットワークへの余分な負荷や、オーバーレイノード間での測定に伴う処理負荷・処理遅延等といった測定コスト・オーバヘッドが存在してしまうという問題点があった。
【００１２】
また、Ｐ２Ｐファイル共有アプリケーションでは、あるユーザが所望のファイルを保持するノード（群）からダウンロードするが、この場合にも、どのノードからダウンロードするか選定する際に、ノード間の品質を考慮してダウンロード元を選定する方式が検討されている（例えば非特許文献７等）。
【００１３】
また、品質（ノード間遅延）を考慮することによるダウンロード時間を短縮できることも報告されている（非特許文献８）。
【００１４】
しかしながら、このようなアプローチも前述のオーバーレイ経路制御の場合と同じく、測定コスト・オーバヘッドの問題点があると考えられる。
【００１５】
上記問題を回避するため、非特許文献９では、ＩＳＰ（ＩＰネットワーク側）とＰ２Ｐ事業者（オーバーレイ側）で協調するアプローチ（Ｐ４Ｐと呼ばれる）が検討されている。この技術では、ＩＳＰ側がＩＰネットワークのトポロジやリンク負荷情報を開示し、特定のリンクに負荷が集中しないようなダウンロード元ノードをＰ２Ｐが選択できるようにする。
【００１６】
こうすることにより、オーバーレイ側が自身で測定をすることなく、ダウンロード時間を短縮できるノードを選択可能となり、ＩＳＰ側も負荷分散を図ることができる。
【００１７】
しかしながら、Ｐ４Ｐでは、あくまでもピア（つまりエンドホスト）の選択を制御することで、トラヒックの流れを制御しようとしており、エンドホストは自律的に振舞うため、ＩＳＰの望むようにトラヒックを制御できるとは限らない、という問題があった。
【先行技術文献】
【非特許文献】
【００１８】
【非特許文献１】Ｌ．Ｚｈｉ  ａｎｄ  Ｐ．Ｍｏｈａｐａｔｒａ，“ＱＲＯＮ：ＱｏＳ−ａｗａｒｅ  ｒｏｕｔｉｎｇ  ｉｎ  ｏｖｅｒｌａｙ  ｎｅｔ−ｗｏｒｋｓ，”ＩＥＥＥ  Ｊ．Ｓｅｌｅｃｔ．Ａｒｅａｓ  Ｃｏｍｍｕｎ．，ｖｏｌ．２２，ｐｐ．２９−４０，Ｊａｎｕａｒｙ  ２００４．
【非特許文献２】ＷＩＤＥプロジェクト，“オーバーレイネットワークによる統合分散環境，”ＷＩＤＥプロジェクト研究報告書，第１７部，２００２．
【非特許文献３】亀井，川原，“エンドホストオーバーレイネットワークによるトラヒックエンジニアリングとその有効性，”信学ソ大，ＢＳ−５−３，２００４．
【非特許文献４】Ｓ．Ｒｅｗａｓｋａｒ  ａｎｄ  Ｊ．Ｋａｕｒ，“Ｔｅｓｔｉｎｇ  ｔｈｅ  Ｓｃａｌａｂｉｌｉｔｙ  ｏｆ  Ｏｖｅｒｌａｙ  Ｒｏｕｔｉｎｇ  Ｉｎｆｒａｓｔｒｕｃｔｕｒｅｓ，”Ｐｒｏｃ．ＰＡＭ  ２００４．Ａｐｒｉｌ  ２００４．
【非特許文献５】Ｓ．Ｂａｎｅｒｊｅｅ，Ｔ．Ｇ．Ｇｒｉｆｉｎ  ａｎｄ  Ｍ．Ｐｉａｓ，“Ｔｈｅ  Ｉｎｔｅｒｄｏｍａｉｎ  Ｃｏｎｎｅｃｔｉｖｉｔｙ  ｏｆ  ＰｌａｎｅｔＬａｂ  Ｎｏｄｅｓ，”  Ｐｒｏｃ．ＰＡＭ  ２００４，Ａｐｒｉｌ  ２００４．
【非特許文献６】平岡，長谷川，村田，“遅延および帯域情報を用いたオーバーレイルーティングの有効性評価，”  信学技報  ＣＱ２００７−１８，２００７年７月．
【非特許文献７】Ｈ．Ｓｈｅｎ  ａｎｄ  Ｙ．Ｚｈｕ，“Ｐｌｏｖｅｒ：Ａ  Ｐｒｏａｃｔｉｖｅ  Ｌｏｗ−ｏｖｅｒｈｅａｄ  Ｆｉｌｅ  Ｒｅｐｌｉｃａｔｉｏｎ  Ｓｃｈｅｍｅ  ｆｏｒ  Ｓｔｒｕｃｔｕｒｅｄ  Ｐ２Ｐ  Ｓｙｓｔｅｍｓ，”ＩＥＥＥ  ＩＣＣ  ２００８．
【非特許文献８】Ｔ．Ｋａｒａｇｉａｎｎｉｓ，  Ｐ．Ｒｏｄｒｉｇｕｅｚ，  ａｎｄ  Ｋ．Ｐａｐａｇｉａｎｎａｋｉ，“Ｓｈｏｕｌｄ  ｉｎｔｅｒｎｅｔ  ｓｅｒｖｉｃｅ  ｐｒｏｖｉｄｅｒｓ  ｆｅａｒ  ｐｅｅｒ−ａｓｓｉｓｔｅｄ  ｃｏｎｔｅｎｔ  ｄｉｓｕｔｒｉｂｕｔｉｏｎ？”ＩＭＣ  ２００５．
【非特許文献９】Ｈ．Ｘｉｅ  ａｎｄ  Ｙ．Ｒ．Ｙａｎｇ，“Ｐ４Ｐ：Ｐｒｏｖｉｄｅｒ  Ｐｏｒｔａｌ  ｆｏｒ  Ａｐｐｌｏｃａｔｉｏｎｓ，”ＳＩＧＣＯＭＭ  ２００８．
【発明の概要】
【発明が解決しようとする課題】
【００１９】
解決しようとする問題点は、従来の技術では、（１）オーバーレイネットワークにおける通信経路計算を行う際、オーバーレイノード間で試験パケットを用いており、ネットワークへの余分な負荷や、オーバーレイノード間での測定に伴う処理負荷・処理遅延等といった測定コスト・オーバヘッドが存在してしまうという点と、（２）また、Ｐ２Ｐファイル共有アプリケーションでの、所望ファイルのダウンロード元のノードの選定を行う際にも、ノード間の品質（ノード間遅延など）を考慮するために、オーバーレイネットワークにおける経路制御の場合と同じく、測定コスト・オーバヘッドが存在してしまう点である。
【００２０】
本発明の目的は、これら従来技術の課題を解決し、エンドエンド間品質の向上とトラヒック転送の効率を向上させることである。
【課題を解決するための手段】
【００２１】
上記目的を達成するため、本発明では、ＩＰネットワーク上に論理的に設定された、ノードとリンクと管理サーバで構成される論理ネットワーク、例えば、オーバーレイネットワーク上でのトラヒックの制御方法であって、（１）オーバーレイノード間の品質情報を、ＩＰネットワークで測定されたフロー情報を用いて推定し、当該フロー情報を用いて、オーバーレイネットワークにおける通信経路計算を行う。また、（２）ＩＳＰ等のネットワーク提供者が制御可能なオーバーレイノード（キャリアオーバーレイノード）によってオーバーレイネットワークを形成し、ＩＰネットワークで通常監視しているトラヒック状況をオーバーレイネットワーク側にフィードバックしてＩＰネットワークとオーバーレイネットワークを連携させる。また、（３）ＩＰネットワークにおいて最適なトラヒック流通を実現する経路上にエンドホストが存在しない場合には、キャリアオーバーレイノードを用いてコンテンツの中継やキャッシュを行う。
【発明の効果】
【００２２】
本発明によれば、ＩＰネットワーク上に論理的に設定された、ノードとリンクと管理サーバで構成される論理ネットワーク、例えば、オーバーレイネットワークにおいて、（１）オーバーレイノード間の品質情報を、ＩＰネットワークで測定されたフロー情報を用いて推定しており、従来のオーバーレイネットワークにおける通信経路計算に必要な、オーバーレイノード間での試験パケットによるトラヒック測定が不要となり、ネットワークへの余分な負荷や、オーバーレイノード間での試験パケットによるトラヒック測定に伴う処理負荷・処理遅延等といった測定コスト・オーバヘッドを軽減できる。また、（２）ＩＳＰ等のネットワーク提供者が制御可能なオーバーレイノード（キャリアオーバーレイノード）によってオーバーレイネットワークを形成し、ＩＰネットワークで通常監視しているトラヒック状況をオーバーレイネットワーク側にフィードバックしてＩＰネットワークとオーバーレイネットワークを連携させており、ＩＳＰ等の望む形でのトラヒック制御が可能となる。また、（３）ＩＰネットワークにおいて最適なトラヒック流通を実現する経路上にエンドホストが存在しない場合には、キャリアオーバーレイノードを用いてコンテンツの中継やキャッシュを行っており、エンドエンド間品質の向上とトラヒック転送の効率を向上させることができる。
【図面の簡単な説明】
【００２３】
【図１】本発明を適用するオーバーレイネットワークによる経路制御例を示す説明図である。
【図２】本発明に係る論理ネットワークのトラヒック制御システムを適用した第１のネットワーク構成例を示すブロック図である。
【図３】本発明に係る論理ネットワークのトラヒック制御システムを構成するための手順例を示すフローチャートである。
【図４】本発明に係る論理ネットワークのトラヒック制御システムによるコンテンツ配信の手順例を示すシーケンス図である。
【図５】本発明に係る論理ネットワークのトラヒック制御システムを適用した第２のネットワーク構成例を示すブロック図である。
【図６】本発明に係る管理サーバの構成例を示すブロック図である。
【図７】本発明に係る空き帯域計算の動作例を示す説明図である。
【図８】本発明に係るｃＯＬノードの構成例を表すブロック図である。
【図９】本発明に係るｅＯＬノードの構成例を表すブロック図である。
【発明を実施するための形態】
【００２４】
以下、図を用いて本発明を実施するための形態例を説明する。図１に示した、ＩＰネットワーク２にＩＰルータ２ａ〜２ｅを介して接続するいくつかのオーバーレイノード１ａ〜１ｃによって構築される論理網であるオーバーレイネットワーク１において、オーバーレイノード１ａ〜１ｃは、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）や主メモリ等を具備したコンピュータ構成からなり、プログラムされたコンピュータ処理を実行することで、本発明の論理ネットワークのトラヒック制御に係る処理を行う。
【００２５】
また、図２に示すように、本例では、管理サーバ２４を設けており、この管理サーバ２４も、プログラムされたコンピュータ処理を実行することで、本発明の論理ネットワークのトラヒック制御に係る処理を行う。
【００２６】
すなわち、本例では、ＩＰネットワーク上に論理的に形成されたオーバーレイネットワークにおける、従来からの問題点（（１）ルーチングテーブル作成に測定コスト・オーバヘッドの負荷がかかる、（２）ネットワーク提供者であるＩＳＰ等においてネットワークのトラヒックを制御することができない）を解決し、かつ、（３）エンドエンド間品質の向上とトラヒック転送の効率の向上を図る。
【００２７】
上記（１），（２）の課題を解決するために、本例では、ＩＰ網（ＩＰネットワーク）で通常監視しているトラヒック状況をオーバーレイネットワーク側にフィードバックして、ＩＰ網とオーバーレイネットワークを連携させる技術と、上記（３）を達成するために、中継地点のオーバーレイノードにおいてコンテンツの中継と共にそのキャッシュを行う技術を備えている。
【００２８】
以下、上記（３）を達成するための第１の技術と、上記（１），（２）の課題を解決するための第２，第３の技術について説明する。
【００２９】
第１の技術においては、ＩＰネットワーク（ＩＰ網、ＩＰＮＷ）に接続するいくつかのオーバーレイノードによって構築される論理網であるオーバーレイネットワークがあるとし、このオーバーレイノードのうち、ＩＳＰやネットワークキャリア等のネットワーク提供者が用意するオーバーレイノードを「キャリアオーバーレイノード」と呼び、それらキャリアオーバーレイノード以外のオーバーレイノード（エンドユーザのＰＣ等）を「エンドホストオーバーレイノード」と呼ぶ。
【００３０】
これら２種類のオーバーレイノードによって構成されるオーバーレイネットワークにおいて、各キャリアオーバーレイノードを「代表ノード」としてオーバーレイノードグループを構成し、各エンドホストオーバーレイノードは、いずれかのグループに所属させる。
【００３１】
各オーバーレイノードグループは、他のグループと論理的に接続されているとする。その接続関係を「論理トポロジ」と呼ぶ。ここまでの手順を「フェーズ１」と呼び、以下の手順を「フェーズ２」と呼ぶ。
【００３２】
次に、その論理トポロジ上において、あるコンテンツを配信するための経路を計算し、その経路に沿って、コンテンツを転送させ、その途中経路上に位置するグループの中に、エンドホストオーバーレイノードが存在すれば、エンドホストオーバーレイノードがコンテンツ中継を行い、同時に当該コンテンツをキャッシュする。
【００３３】
エンドホストオーバーレイノードが存在しない場合は、キャリアオーバーレイノードがコンテンツ中継とキャッシュを行う。ここまでの手順が「フェーズ２」である。
【００３４】
フェーズ１について、図２を用いて説明する。図２において、ｃＯＬノード２１ａ，２２ａ，２３ａはキャリアオーバーレイノード、ｅＯＬノード２１ｂ，２１ｃ，２３ｂ〜２３ｄはエンドホストオーバーレイノードを表す。
【００３５】
各ｃＯＬノード２１ａ，２２ａ，２３ａは、各グループ２１，２２，２３に一つずつ設置されている。また、各ｅＯＬノード２１ｂ，２１ｃ，２３ｂ〜２３ｄはいずれかのグループ２１，２２，２３に所属しているとする。
【００３６】
どのグループに所属するかは、例えば、ｅＯＬノード２１ｂ，２１ｃ，２３ｂ〜２３ｄからみて最も近いｃＯＬノード２１ａ，２２ａ，２３ａの属するグループに所属させる。ここで近いとは、パケットの遅延時間でも良いし、地理的に近い（東京同士等）でも良い。
【００３７】
フェーズ１の手順に関して、図２と共に図３を用いて、入力（前提条件）から出力（コンテンツ配信のためのオーバーレイネットワークが構成されるまで）までの手順を順に説明する。
【００３８】
［１−１］まず、ＩＳＰあるいはキャリアといったＮＷ提供者（以下、キャリアとする）が、自身のＩＰ網に接続する形でサーバ（コンピュータ）を配置する。尚、サーバはＩＰ網での各エリア毎（例えば、東京、大阪、名古屋等、図２参照）に配置する（図３のステップＳ３０１）。
【００３９】
このエリアがグループに相当し、キャリアが配置したサーバが、キャリアオーバーレイノードｃＯＬノードである。
【００４０】
［１−２］次に、キャリアが、オーバーレイネットワーク（オーバーレイＮＷ）全体を管理するための図２に示す管理サーバ２４を設置する（ステップＳ３０２）。
【００４１】
［１−３］管理サーバ２４は、グループＸ２３と、そのグループ２３に属するｃＯＬノードＸ２３ｃのＩＰアドレス（ＩＰ＃ｘｘｘ）の対応表を管理する（ステップＳ３０３）。
【００４２】
［１−４］管理サーバ２４は、ｃＯＬノード２１ａ，２２ａ，２３ａを論理的に接続するかどうか決定する。つまり論理トポロジを決定する（ステップＳ３０４）。尚、論理的に接続するとは、お互いのｃＯＬノードが相手のＩＰアドレスを知っており、通信可能な状態にあることをさす。
【００４３】
［１−５］管理サーバ２４は、各ｃＯＬノード２１ａ，２２ａ，２３ａに対し、論理トポロジ情報を配布する（ステップＳ３０５）。尚、図２の例では、各グループ２１，２２，２３はフルメッシュで接続されている。
【００４４】
［１−６］各ｃＯＬノード２１ａ，２２ａ，２３ａは、配布されたトポロジにおいて、各論理リンクに対して品質メトリック（例えば遅延時間）を用いて、最適な経路を計算し、経路表を作成する（ステップＳ３０６）。尚、品質メトリックをどのように推定するか等については、第２の技術の説明以降で詳述する。
【００４５】
［１−７］一方、コンテンツ配信サービスを受けたいユーザ（グループ（３）２３のエンドホストノード：ｅＯＬノード２３ｃ）は、管理サーバ２４に問い合わせて、当該ｅＯＬノード２３ｃに最も近いｃＯＬノード２３ａを教えてもらい、そのｃＯＬノード２３ａに対し、グループ（３）２３への所属希望を通知して所属する（ステップＳ３０７）。
【００４６】
［１−８］ｅＯＬノード２３ｃは、所属したグループ（３）のｃＯＬノード２３ａから、トポロジ情報と経路表を入手する（ステップＳ３０８）。
【００４７】
以上がフェーズ１の手順である。
【００４８】
次に、フェーズ２の手順について、図２と共に図４を用いて説明する。
【００４９】
［２−１］まず、コンテンツを受信したいｅＯＬノードＹ２１ｂは、管理サーバ２４から該当するコンテンツ保持リストを入手する（図４のステップＳ４０１）。
【００５０】
［２−２］管理サーバ２４は、ｅＯＬノードＹ２１ｂにコンテンツ保持リストを返答する（ステップＳ４０２）。コンテンツ保持リストとは、当該コンテンツを保持しているノード（とそのノードの属するグループ）がリストアップされているものである。
【００５１】
［２−３］ｅＯＬノードＹ２１ｂは、コンテンツ保持リストの中から、配信元ノードを選定する。具体的には、フェーズ１のステップＳ３０８で入手した経路表を元に、自身からみて最小ホップで配信可能なグループを調べ、そのグループに属するｅＯＬノードまたはｃＯＬノードを配信元ノードとして選定する。
【００５２】
その後、ｅＯＬノードＹ２１ｂは、選定したノードへコンテンツ配信リクエストを送信する（ステップＳ４０３）。例えば、図２，図４の例では、コンテンツ配信元ノードはグループ（３）２３のｅＯＬノードＸ２３ｃである。
【００５３】
［２−４］コンテンツ配信元のｅＯＬノードＸ２３ｃは、自身の経路表をみて、次に転送すべきグループに属するノードへコンテンツを配信する。
【００５４】
例えば、図２のように、そのコンテンツ流通にとっての最適な経路がグループ（３）２３→グループ（２）２２→グループ（１）２１だったとする。
【００５５】
もし、グループ（２）２２に参加しているｅＯＬノードがあれば、このｅＯＬノードへコンテンツを転送する。もし、グループ（２）２２にｅＯＬノードが存在しない場合、グループ（２）２２のｃＯＬノードＡ２２ａを中継ノードとして指定し、そこへコンテンツをまず転送し（ステップＳ４０４）、そこから、要求元のｅＯＬノードＹ２１ｂに転送する（ステップＳ４０５）。
【００５６】
尚、コンテンツ転送方法としては、コンテンツそのものを一旦蓄積するｓｔｏｒｅ−ａｎｄ−ｆｏｒｗａｒｄ的でも良いし、コンテンツを構成する各パケットやピースをｃＯＬノードＡで受信しつつ次へ転送するｏｎ−ｔｈｅ−ｆｌｙ的な転送でも良い。
【００５７】
本例では、グループ（２）２２のｃＯＬノードＡ２２ａは、中継したコンテンツをキャッシュする。こうすることにより、ｅＯＬノードのみを用いるＰ２Ｐでは、グループ（２）２２を経由する最適な経路に沿ってトラヒックを転送できなかったのに対して、本例では、ｃＯＬノードＡ２２ａのキャッシュを利用することにより実現可能としている。
【００５８】
ステップＳ４０３の処理を、コンテンツ要求ノードにコンテンツが到達するまで繰り返して、フェーズ２を実現する。
【００５９】
尚、コンテンツをｃＯＬノード（Ａ２２ａ）でキャッシュしておく理由は、将来、例えば、グループ（２）２２に属するｅＯＬノードが発生し、そのノードが当該コンテンツを要求した場合には、オリジナルコンテンツをグループ（３）のｅＯＬノードＸ２３ｃから受信するのは非効率なためである。
【００６０】
一方、ｅＯＬノードＹ２１ｂは、受信した後は、そのコンテンツをキャッシュしておき、以降に、同じグループ（１）２１のｅＯＬノードＺ２１ｃから当該コンテンツの要求があった場合には、当該コンテンツをｅＯＬノードＹ２１ｂからｅＯＬノードＺ２１ｃに送信することにより、冗長なトラヒック転送を回避する。
【００６１】
次に、第２の技術においては、第１の技術におけるオーバーレイノードグループ間の接続関係（トポロジ）において、各論理リンクのメトリックとして、グループｉの代表ノードであるキャリアオーバーレイノードｉと、グループｊのキャリアオーバーレイノードｊの間の通信品質（遅延時間、パケット損失率、利用可能帯域のいずれか、またはそれらの組み合わせ）を用いて、転送経路を計算する。
【００６２】
そして、第３の技術においては、第２の技術におけるオーバーレイノード間の品質情報を、ＩＰネットワークで測定されたフロー情報を用いて推定する。
【００６３】
ここで、フロー情報とは、ＮｅｔＦｌｏｗ、ｓＦｌｏｗといった測定技術で得られる情報をさす。具体的には、ルータやスイッチといったネットワーク機器上で「フロー」（ＴＣＰ、ＵＤＰやＩＣＭＰの宛先、送信元のＩＰアドレスとポート番号の組み合わせで識別するセッション）単位でパケット数やバイト数を集計し、その集計データをＮｅｔＦｌｏｗパケットでトラヒック管理サーバに送信し、トラヒック管理サーバにおいて、各ルータ等のネットワーク機器からから収集したフロー情報を分析する。
【００６４】
フロー情報を用いて品質を推定する技術として、例えば、利用可能帯域に相当するＴＣＰスループットを推定する場合には、公知文献としての「Ｒ．Ｋａｗａｈａｒａ，  Ｔ．Ｍｏｒｉ，  Ｋ．Ｉｓｈｉｂａｓｈｉ，  Ｎ．Ｋａｍｉｙａｍａ，  ａｎｄ  Ｈ．Ｙｏｓｈｉｎｏ，“Ｐａｃｋｅｔ  ｓａｍｐｌｉｎｇ  ＴＣＰ  ｆｌｏｗ  ｒａｔｅ  ｅｓｔｉｍａｔｉｏｎ  ａｎｄ  ｐｅｒｆｏｒｍａｎｃｅ  ｄｅｇｒａｄａｔｉｏｎ  ｄｅｔｅｃｔｉｏｎ  ｍｅｔｈｏｄ，”  ＩＥＩＣＥ  Ｔｒａｎｓ．  Ｃｏｍｍｕｎ．，  Ｖｏｌ．Ｅ９１−Ｂ，  Ｎｏ．５，  ｐｐ．１３０９−１３１９，  Ｍａｙ  ２００８．」がある。
【００６５】
あるいは、遅延時間（ＲＴＴ：ｒｏｕｎｄ  ｔｒｉｐ  ｔｉｍｅ）やパケット損失率に相当するＴＣＰでのパケット再送率を推定するのであれば、例えば、インターネット上での公開ツールｔｃｐｔｒａｃｅ（ＵＲＬ＝ｈｔｔｐ：／／ｉｒｇ．ｃｓ．ｏｈｉｏｕ．ｅｄｕ／ｓｏｆｔｗａｒｅ／ｔｃｐｔｒａｃｅ／）を用いて推定可能である。
【００６６】
このように、ＩＰ網でのトラヒック測定情報を利用することにより、従来のオーバーレイネットワークで必要だったオーバーレイノード間での試験パケットによるトラヒック測定コストを削減することが可能となる。
【００６７】
また、ＩＰ網の状態をオーバーレイネットワークにフィードバックさせて連携することにより、ＩＰ網の状態に合わせてＩＳＰの望む形にトラヒックを制御可能としている。例えば、ＩＰ網の空き帯域等の状態という情報を、オーバーレイへの入力としてフィードバックし、オーバーレイ側では、経路を選択する際に、空き帯域が最も大きい経路を選択することにより、トラヒックが一箇所へ集中するのを回避する。
【００６８】
次に、本発明に係る第４の技術について説明する。この第４の技術においては、第１の技術のようにキャリアオーバーレイノードにコンテンツ中継を実施させる代わりに、通信経路はＩＰネットワーク内のルータまたはスイッチのみを用いて確立しておき、同時に、コンテンツキャッシュをさせたいキャリアオーバーレイノードに対してもトラヒックを転送させる経路をルータまたはスイッチ内で設定することにより、コンテンツキャッシュを行う。
【００６９】
例えば、インターネット上で開示されている「ｏｐｅｎｆｌｏｗ（ＵＲＬ＝ｈｔｔｐ：／／ｗｗｗ．ｏｐｅｎｆｌｏｗｓｗｉｔｃｈ．ｏｒｇ／）」と呼ばれる技術を用いて、今着目するコンテンツトラヒックの経路をＩＰネットワーク内で確立する。
【００７０】
このＯｐｅｎｆｌｏｗでは、
（ｉ）ルータ・スイッチにおいて、「ｆｌｏｗ  ｔａｂｌｅ（ＦＴ）」にエントリされてないフローからの一発目のパケットは、全て、予め用意されたｃｏｎｔｏｌｌｅｒへ転送され、
（ｉｉ）ｃｏｎｔｒｏｌｌｅｒで、そのフローに対してどういう制御をするかを特定し、その結果を、各ルータのＦＴにエントリし、
（ｉｉｉ）各ＦＴで、そのフローにマッチするパケットが到着したらどこへ転送するか（ＮｅｘｔＨｏｐ＝ｒｏｕｔｅｒ  Ｘへのように）、というような情報を書き込んでいくことにより、フローレベルで経路を制御する。
【００７１】
そこで、ｃＯＬノードで計算した経路情報をＦＴに反映させることにより、ＩＰネットワーク内で経路を制御することが可能となる。
【００７２】
また、ｃＯＬノードにコンテンツをキャッシュさせたい場合には、ＦＴにｃＯＬノードへもパケット転送するように書いておくことにより、ｃＯＬノードでパケットを受信してキャッシュすることができる。
【００７３】
以下、このような第１〜第４の技術を用いた本発明に係る論理ネットワークのトラヒック制御システムの構成と処理動作の実施例１，２を説明する。
【００７４】
［実施例１］
本実施例におけるシステムは、図５に示すように、オーバーレイネットワーク５１と下位転送ネットワーク（ＩＰネットワーク）５３の構成を持ち、オーバーレイネットワーク５１は、キャリアオーバーレイノード（ｃＯＬノード）５１ａ〜５１ｅ、エンドホストオーバーレイノード（ｅＯＬノード）５１ｆ〜５１ｉ、管理サーバ５４、により構成される。
【００７５】
下位転送ネットワーク５３は、ルータ５３ａ〜５３ｇ等のネットワーク機器を具備し、パーソナルコンピュータ等の通信端末機器である（ｅＯＬノード）５１ｆ〜５１ｉを終端するネットワーク機器５２ａ〜５２ｄが接続され、かつ、エッジルータ５２ｅ〜５２ｉ等を介して、オーバーレイネットワーク５１に接続されている。
【００７６】
管理サーバ５４は、図６において管理サーバ６４として示すように、プログラムされたコンピュータ処理を実行する機能として、トラヒック品質情報管理部６４ａとコンテンツ保持リスト管理部６４ｂ、ｃＯＬノード管理部６４ｃ、トポロジ決定部６４ｄ、エリアマップ部６４ｅを有している。
【００７７】
管理サーバ６４内のトラヒック品質情報管理部６４ａは、下位転送ネットワーク５３において測定されたトラヒック情報を収集し、エリア間のトラヒック品質マトリクスを作成する。ここで、エリアとは、東京や神奈川といった県単位で定義しても良いし、下位転送ネットワークのエッジルータが存在する単位でも良い。
【００７８】
以下、エリア間のトラヒック品質マトリクス作成の手順について述べる。
【００７９】
例えば、上述した第３の技術を用いて、フローｊ毎に品質ｄ＿ｊ（スループット、遅延、パケット損失率）を推定しておく。一方、ＩＰアドレスからエリアを対応づける位置データベースを別途用意しておく。
【００８０】
品質が推定されたフローｊの発ＩＰアドレスと着ＩＰアドレスを参照して、位置データベースを用いて、発ＩＰアドレスの対応するエリアＡと着ＩＰアドレスの対応エリアＢを照合する。
【００８１】
発エリアＡから着エリアＢへ向かうフローｊを集め、Σｄ＿ｊ／Ｎ＿ａｂにより、エリアＡからエリアＢへの品質ｄ＿ａｂとする。ここで、Ｎ＿ａｂは、エリアＡからエリアＢへ向かうフロー数である。
【００８２】
あるいは、下位転送ネットワークの各リンク負荷と、経路情報を用いて、エリア間での利用可能帯域を計算しても良い。
【００８３】
例えば、図７に示すように、オーバーレイネットワークがｃＯＬノードＡ７１ａ，Ｂ７１ｂ，Ｃ７１ｃで構成され、下位転送網（ネットワーク）がルータ（１）７２ａ〜（５）７２ｄで構成されているとする。また、下位転送ネットワークにおける各リンクでの空き帯域が７３ａ〜７３ｄに示す内容とする。
【００８４】
ここで、ｃＯＬノード７１ａ〜７１ｃと下位転送ＮＷでの位置は、図７に示すＤＢ７４で管理されているものとする。この例では、エリアＡ，Ｂ，ＣはそれぞれｃＯＬノードＡ，Ｂ，Ｃに対応しているものとする。
【００８５】
また、ＤＢ７４では、位置ＤＢ７４ａにおいて、エリアＡにルータ（１）７２ａが、エリアＢにルータ（３）７２ｃが存在することを管理している。さらに、図７の例では、ルータ（１）７２ａからルータ（３）７２ｃへの経路がルータ（２）７２ｂを介した構成になっており、また、各ルータ間のリンクの空き帯域を、ＤＢ７４におけるトラヒック情報ＤＢ７４ｂで管理している。
【００８６】
管理サーバ６４は、このように管理することにより、例えば、エリアＡからエリアＢへ経路での空き帯域は２Ｍｂｐｓというように計算する。
【００８７】
また、管理サーバ６４内のコンテンツ保持リスト管理部６４ｂでは、どのコンテンツをどのｃＯＬノードあるいはｅＯＬノードが保持しているかを管理している。
【００８８】
また、管理サーバ６４内のｃＯＬノード管理部６４ｃは、各ｃＯＬノードがどのエリア（＝どのオーバーレイグループ）に属するのかを示す対応表を管理している。具体的には、グループＩＤとそのグループに設置されたｃＯＬノードのＩＰアドレスの対応付けを行う。
【００８９】
また、管理サーバ６４内のトポロジ決定部６４ｄは、各ｃＯＬノードが形成するオーバーレイグループの接続関係（トポロジ）を決定する。
【００９０】
また、管理サーバ６４内のエリアマップ部６４ｅは、ｅＯＬノードからの問い合わせに対して、このｅＯＬノードに最も近いオーバーレイグループ（エリア）に設置されたｃＯＬノードのＩＰアドレスを返信する。そのために、問い合わせ元のｅＯＬノードのＩＰアドレスからエリアをマップするデータベースを管理している。
【００９１】
図８においては、ｃＯＬノード８１の構成例を示しており、ｃＯＬノード８１は、プログラムされたコンピュータ処理を実行する機能として、トポロジ形成管理部８１ａ、経路計算部８１ｂ、経路表管理部８１ｃ、コンテンツ転送部８１ｄ、コンテンツキャッシュ部８１ｅを具備している。
【００９２】
トポロジ形成管理部８１ａは、他のｃＯＬノードが形成するオーバーレイグループとの接続関係（トポロジ）を把握している。トポロジの決定は、管理サーバ（５４，６４）で集中的に決定しても良いし、ｃＯＬノード間で自律的にメッセージを交換して接続するか否かを決定しても良い。
【００９３】
経路計算部８１ｂは、管理サーバより、エリアＡ−Ｂ間のトラヒック品質情報ｄ＿ａｂを入手する。
【００９４】
その後、トポロジ形成管理部８１ａで形成したトポロジにおいて、エリアＡとエリアＢに設置されているｃＯＬノードＡとｃＯＬノードＢの管理するオーバーレイグループＡとオーバーレイグループＢが接続されていれば、その論理リンクＡＢの品質メトリックをｄ＿ａｂとする。
【００９５】
このようにして、トポロジ上の各論理リンクに品質メトリックを与えたら、メトリックを用いて最適な経路を計算する。例えば、遅延時間をメトリックとして用いる場合は、ダイクストラ法により最短経路を計算する。
【００９６】
コンテンツ転送部８１ｄおよび経路表管理部８１ｃは、後述するｅＯＬノード内のそれらと同じ動作をする。
【００９７】
図９においては、ｅＯＬノード９１の構成例を示しており、ｅＯＬノード９１は、プログラムされたコンピュータ処理を実行する機能として、ｃＯＬノード選定部９１ａ、コンテンツ要求部９１ｂ、経路表管理部９１ｃ、コンテンツ転送部９１ｄ、コンテンツキャッシュ部９１ｅを具備している。
【００９８】
ｅＯＬノード９１は、サービスを受ける際、例えば、あるコンテンツの受信を要求する際に、まずオーバーレイネットワークに参加する。具体的には、ｃＯＬノード選定部９１ａにおいて、どのｃＯＬノードに所属するかを決定する。この際、ｃＯＬノード選定部９１ａは、例えば管理サーバに問い合わせて、自身に最も近いｃＯＬノードを教えてもらう。
【００９９】
コンテンツ要求部９１ｂは、コンテンツ保持リストを参照して、コンテンツ受信要求を行う。このコンテンツ保持リストは、管理サーバで一元管理されていても良いし、ｃＯＬノードやｅＯＬノード間で分散管理していても良い。コンテンツ要求部９１ｂは、コンテンツ保持リストからコンテンツを保持しているｃＯＬあるいはｅＯＬノードのリストを入手し、そのリスト中から、最も近いノードを特定してリクエストを送信する。
【０１００】
コンテンツ転送部９１ｄは、コンテンツ要求元のｅＯＬノードから、あるいは、コンテンツを中継しているｅＯＬノードから、または、ｃＯＬノードから、リクエストを受信すると、そのコンテンツを、経路表管理部９１ｃで管理されている隣接ノード（ＮｅｘｔＨｏｐのｃＯＬノードあるいはｅＯＬノード）へ転送する。
【０１０１】
経路表管理部９１ｃは、ｃＯＬノードから経路表を入手して記憶装置に格納・保持しておく。また、その経路表をみて、ＮｅｘｔＨｏｐとなるオーバーレイグループＺのｃＯＬノードＺにアクセスし、そのｃＯＬノードに属するｅＯＬノードｚが存在すれば、ｅＯＬノードｚのＩＰアドレス（ＩＰ＃ｚ）を問い合わせて入手する。存在しなければ、ｃＯＬノードのＩＰアドレス（ＩＰ＃Ｚ）を通知してもらう。そのＩＰアドレスを、ＮｅｘｔＨｏｐ＃Ｚ＝ＩＰ＃ｚ（あるいＩＰ＃Ｚ）として管理しておく。
【０１０２】
コンテンツキャッシュ部９１ｅでは、コンテンツを転送する際に、当該コンテンツをキャッシュする。
【０１０３】
次に、本発明に係る論理ネットワークのトラヒック制御システムの構成と処理動作の実施例２を説明する。
【０１０４】
［実施例２］
［実施例１］では、図８に示すｃＯＬノード８１でのコンテンツ転送部８１ｄおよびコンテンツキャッシュ部８１ｅの動作は、図９に示すｅＯＬノード９１におけるコンテンツ転送部９１ｄおよびコンテンツキャッシュ部９１ｅの動作と同じとしていたが、以下に示す別のものとしても良い。
【０１０５】
第４の技術に記載したように、通信経路は下位転送網（ＩＰネットワーク）内のルータまたはスイッチのみを用いて確立しておき、同時に、コンテンツキャッシュをさせたいｃＯＬノードに対してもトラヒックを転送させる経路をルータまたはスイッチ内で設定することにより、コンテンツキャッシュを行う。
【０１０６】
具体的には、実施例１と同様に、ｅＯＬノード（仮にｅＯＬノードｚ０とする）内の経路表管理部（９１）において、ｃＯＬノードから経路表を入手して記憶装置に格納して保持しておく。
【０１０７】
また、その経路表を参照して、ＮｅｘｔＨｏｐとなるオーバーレイグループＺのｃＯＬノードＺにアクセスし、そのｃＯＬノードに属するｅＯＬノードｚが存在すれば、ｅＯＬノードｚのＩＰアドレス（ＩＰ＃ｚ）を問い合わせて入手し、そのＩＰアドレスを、ＮｅｘｔＨｏｐ＃Ｚ＝ＩＰ＃ｚとして管理しておく。
【０１０８】
ここまでは実施例１と同じ動作である。本実施例２においては、ｅＯＬノードｚが存在しない場合、もう１ホップ先のｃＯＬノードＺ２にアクセスし、そのｃＯＬノードに属するｅＯＬノードｚ２が存在すれば、当該ｅＯＬノードｚ２のＩＰアドレス（ＩＰ＃ｚ２）を問い合わせて入手し、そのＩＰアドレスを、ＮｅｘｔＨｏｐ＃Ｚ＝ＩＰ＃ｚ２として管理しておく。尚、本動作はｅＯＬノードが見つかるまで繰り返す。
【０１０９】
また、ｃＯＬノードＺに属するｅＯＬノードが存在しなかった旨を管理サーバに通知する。
【０１１０】
管理サーバは、その通知を受けたら、該当するフロー、つまりｅＯＬノードｚ０からｚ２へのコンテンツ転送に対して、最適な経路はｃＯＬノードグループＺを経由する経路であることと、キャッシュすべきノードはｃＯＬノードＺであることを、記憶装置に情報として記憶し管理しておく。
【０１１１】
一方、下位転送網内のルータにおいて、ｆｌｏｗ  ｔａｂｌｅ（ＦＴ）にエントリされてないフローからの一発目のパケットは、管理サーバへ転送する。
【０１１２】
管理サーバでは、そのフローに対してどういう制御をするかを選択する。具体的には、当該フローに対して、上述のように、最適な経路およびキャッシュ先が管理されている場合には、その結果を各ルータのＦＴにエントリし、各ＦＴで、そのフローにマッチするパケットが到着したらｃＯＬノードグループＺを経由できるような情報を書き込んでいくことにより、フローレベルで経路を制御する。
【０１１３】
同時に、ＦＴに、ｃＯＬノードＺへもパケット転送するように書いておき、ｃＯＬノードにおいても当該パケットを受信してキャッシュしておく。
【０１１４】
以上、図１〜図９を用いて説明したように、本例では、下位転送ネットワークであるＩＰネットワーク５３上に論理的に設定された、ノードとリンクと管理サーバで構成される論理ネットワークとしてのオーバーレイネットワーク５１上でのトラヒック制御を行うものであって、プログラムされたコンピュータ処理を実行する機能として、オーバーレイノード５１ａ〜５１ｉは、トポロジ形成管理部８１ａと経路計算部８１ｂ、経路表管理部８１ｃ、コンテンツ転送部８１ｄおよびコンテンツキャッシュ部８１ｅ、もしくは、ｃＯＬノード選定部９１ａとコンテンツ要求部９１ｂ、経路表管理部９１ｃ、コンテンツ転送部９１ｄおよびコンテンツキャッシュ部９１ｅを具備し、管理サーバ５４，６４は、トラヒック品質情報管理部６４ａとコンテンツ保持リスト管理部６４ｂおよびｃＯＬノード管理部６４ｃ、トポロジ決定部６４ｄ、エリアマップ部６４ｅを具備し、管理サーバ５４，６４は、トラヒック品質情報管理部６４ａによりＩＰネットワーク５３から当該ＩＰネットワークのトラヒック情報を収集し、オーバーレイノード５１ａ〜５１ｅは、トポロジ形成管理部８１ａにより、管理サーバ５４，６４からＩＰネットワーク５３のトラヒック情報を入手し、経路計算部８１ｂにより、入手したＩＰネットワークのトラヒック情報を用いて、オーバーレイネットワーク５３上での経路を選定し、経路表管理部８１ｃにより記憶装置に格納する。
【０１１５】
また、オーバーレイノード５１ａ〜５１ｉは、コンテンツキャッシュ部８１ｅ，９１ｅにより、中継したコンテンツをキャッシュし、キャッシュしたコンテンツの要求に応じてコンテンツ転送部８１ｄ，９１ｄを介して当該キャッシュを要求元に送信する。
【０１１６】
管理サーバ５４，６４のトラヒック品質情報管理部６４ａは、ＩＰネットワーク５３上のネットワーク機器（５３ａ〜５３ｇ）が検出するフロー毎のトラヒック情報を収集し、収集したフロー毎のトラヒックを分析して品質メトリックを推定し、推定結果をオーバーレイノード５１ａ〜５１ｅに送信する。
【０１１７】
オーバーレイノードは、オーバーレイネットワーク５１の提供主体が用意した複数のキャリアノード５１ａ〜５１ｅと、これらのキャリアノード５１ａ〜５１ｅ以外の複数のエンドホストノード５１ｆ〜５１ｉからなり、管理サーバ５４，６４は、ｃＯＬノード管理部６４ｃとトポロジ決定部６４ｄおよびエリアマップ部６４ｅにより、各キャリアノード５１ａ〜５１ｅを各キャリアノード５１ａ〜５１ｅ毎のグループに分けて記憶管理すると共に、各キャリアノード５１ａ〜５１ｅ間の接続状態を示す論理トポロジを決定し、決定した論理トポロジ情報を各キャリアノード５１ａ〜５１ｅに送信し、各キャリアノード５１ａ〜５１ｅは、管理サーバ５４，６４から送信された論理トポロジにおける各論理リンクに対して、経路計算部８１ｂにより、トラヒック情報を用いた経路選定を行う。
【０１１８】
また、管理サーバ５４，６４は、コンテンツ保持リスト管理部６４ｂにおいて、各コンテンツ毎に当該コンテンツを保持するノードを特定したコンテンツ保持リストを保持し、各エンドホストノード５１ｆ〜５１ｉは、所属先として特定されるグループを管理サーバ５４，６４に問い合わせ、管理サーバ５４，６４が特定したグループのキャリアノード５１ａ〜５１ｅから、論理トポロジと当該キャリアノード５１ａ〜５１ｅが選択した経路情報を入手する。そして、コンテンツの要求時、エンドホストノード５１ｆ〜５１ｉは、管理サーバ５４，６４からコンテンツ保持リストを入手し、このコンテンツ保持リストを参照して、要求するコンテンツの配信元ノードを選定し、選定した配信元ノードに対して当該コンテンツの配信要求を送信し、また、コンテンツ配信要求の受信時には、エンドホストノード５１ｆ〜５１ｉは、所属するグループのキャリアノード５１ａ〜５１ｅから入手した経路情報を参照して配信経路を選定し、選定した配信経路における次転送先のグループに所属するエンドホストノード５１ｆ〜５１ｉもしくはキャリアノード５１ａ〜５１ｅを中継ノードに指定して要求されたコンテンツを転送し、中継ノードに指定されたエンドホストノード５１ｆ〜５１ｉもしくはキャリアノード５１ａ〜５１ｅは、受信したコンテンツを次転送先のグループに所属するエンドホストノード５１ｆ〜５１ｉもしくはキャリアノード５１ａ〜５１ｅに中継転送すると共に、当該コンテンツをキャッシュして、次回の当該コンテンツの配信要求を受信した際に、キャッシュした当該コンテンツを要求元に送信する。
【０１１９】
このように、本例では、ＩＰネットワーク上に論理的に設定された、ノードとリンクと管理サーバで構成される論理ネットワークである、オーバーレイネットワークにおいて、（１）オーバーレイノード間の品質情報を、ＩＰネットワークで測定されたフロー情報を用いて推定しており、従来のオーバーレイネットワークにおける通信経路計算に必要な、オーバーレイノード間での試験パケットによるトラヒック測定が不要となり、ネットワークへの余分な負荷や、オーバーレイノード間での試験パケットによるトラヒック測定に伴う処理負荷・処理遅延等といった測定コスト・オーバヘッドを軽減できる。
【０１２０】
また、（２）ＩＳＰ等のネットワーク提供者が制御可能なオーバーレイノード（キャリアオーバーレイノード）によってオーバーレイネットワークを形成し、ＩＰネットワークで通常監視しているトラヒック状況をオーバーレイネットワーク側にフィードバックしてＩＰネットワークとオーバーレイネットワークを連携させており、ＩＳＰ等の望む形でのトラヒック制御が可能となる。
【０１２１】
また、（３）ＩＰネットワークにおいて最適なトラヒック流通を実現する経路上にエンドホストが存在しない場合には、キャリアオーバーレイノードを用いてコンテンツの中継やキャッシュを行っており、エンドエンド間品質の向上とトラヒック転送の効率を向上させることができる。
【０１２２】
尚、本発明は、図１〜図９を用いて説明した例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能である。例えば、本例では、オーバーレイネットワークを論理ネットワークの例としているが、これに限定されるものではない。
【０１２３】
また、図２において、各ｃＯＬノード２１ａ，２２ａ，２３ａは、各グループ２１，２２，２３に一つずつ設置されているが、例えば、対障害性を考慮して複数設置しても良い。
【符号の説明】
【０１２４】
１，５１：オーバーレイネットワーク（Ｏｖｅｒｌａｙ−ＮＷ）、１ａ〜１ｃ：オーバーレイノード、２，５３：ＩＰネットワーク（ＩＰ−ＮＷ、下位転送ネットワーク）、２ａ〜２ｅ：ＩＰルータ、２１，２２，２３：オーバーレイノードグループ、２１ａ，２２ａ，２３ａ，５１ａ〜５１ｅ：ｃＯＬノード（キャリアオーバーレイノード）、２１ｂ，２１ｃ，２３ｂ〜２３ｄ，５１ｆ〜５１ｉ：ｅＯＬノード（エンドホストオーバーレイノード）、２１ｄ：キャッシュ、２４，５４，６４：管理サーバ、５２ａ〜５２ｄ：通信端末機器、５２ｅ〜５２ｉ：エッジルータ、５３ａ〜５３ｇ：ルータ、６４ａ：トラヒック品質情報管理部、６４ｂ：コンテンツ保持リスト管理部、６４ｃ：ｃＯＬノード管理部、６４ｄ：トポロジ決定部、６４ｅ：エリアマップ部、７１ａ〜７１ｃ：ｃＯＬノードＡ〜Ｃ、７２ａ〜７２ｄ：ルータ（１）〜（５）、７３ａ〜７３ｄ：リンクでの空き帯域、７４：ＤＢ、７４ａ：位置ＤＢ、７４ｂ：トラヒック情報ＤＢ、８１：ｃＯＬノード、８１ａ：トポロジ形成管理部、８１ｂ：経路計算部、８１ｃ：経路表管理部、８１ｄ：コンテンツ転送部、８１ｅ：コンテンツキャッシュ部、９１：ｅＯＬノード、９１ａ：ｃＯＬノード選定部、９１ｂ：コンテンツ要求部、９１ｃ：経路表管理部、９１ｄ：コンテンツ転送部、９１ｅ：コンテンツキャッシュ部。
【図１】
2010200026.tif 000003
【図２】
2010200026.tif 000004
【図３】
2010200026.tif 000005
【図４】
2010200026.tif 000006
【図５】
2010200026.tif 000007
【図６】
2010200026.tif 000008
【図７】
2010200026.tif 000009
【図８】
2010200026.tif 000010
【図９】
2010200026.tif 000011