(57)【特許請求の範囲】
【請求項１】
ＩＰまたはイーサネットネットワーク上でクライアントからサーバへのコンテンツ要求メッセージ、およびサーバからクライアントへのそのコンテンツ応答メッセージを中継するデータ転送装置であって、
前記コンテンツ要求メッセージのペイロードを確認する確認手段と、
ペイロードの中身のコンテンツ情報とコンテンツ要求メッセージの転送先を関連づけて登録する転送テーブルと、
前記転送テーブルに登録済みのコンテンツ情報に関するコンテンツ要求メッセージを、前記転送先に転送するパケット転送手段と、を備え、
前記転送テーブルは、同一コンテンツを有するサーバの数が、一定以上である場合、前記コンテンツ要求メッセージの転送先をマルチキャストアドレスで登録することを特徴とするデータ転送装置。
【請求項２】
前記確認手段は、前記コンテンツ応答メッセージのペイロードをさらに確認し、前記応答メッセージのコンテンツ情報が、前記転送テーブルに登録されていない場合、該コンテンツ情報と前記応答メッセージの送信元サーバのアドレスを関連づけて登録することを特徴とする請求項１に記載のデータ転送装置。
【請求項３】
前記転送テーブルは、ハッシュ関数により前記ペイロードの中身のコンテンツ情報からハッシュ値を生成し、該ハッシュ値と前記コンテンツ要求メッセージの転送先を関連づけて登録することを特徴とする請求項１または２に記載のデータ転送装置。
【請求項４】
ＩＰまたはイーサネットネットワーク上でクライアントからサーバへのコンテンツ要求メッセージ、および応答メッセージを中継するデータ転送方法であって、
前記コンテンツ要求メッセージのペイロードを確認する確認ステップと、
ペイロードの中身のコンテンツ情報とコンテンツ要求メッセージの転送先を関連づけて登録した転送テーブルに登録済みのコンテンツ情報に関する要求メッセージを、前記転送先に転送するパケット転送ステップと、を有する一方、
前記転送テーブルは、同一コンテンツを有するサーバの数が、一定以上である場合、前記コンテンツ要求メッセージの転送先をマルチキャストアドレスで登録することを特徴とするデータ転送方法。
【請求項５】
ＩＰまたはイーサネットネットワーク上でクライアントからサーバへのコンテンツ要求メッセージ、および応答メッセージを中継するコンピュータを、
前記コンテンツ要求メッセージのペイロードを確認する確認手段と、
ペイロードの中身のコンテンツ情報とコンテンツ要求メッセージの転送先を関連づけて登録する転送テーブルに登録済みのコンテンツ情報に関する要求メッセージを、前記転送先に転送するパケット転送手段と、して機能させる一方、
前記転送テーブルは、同一コンテンツを有するサーバの数が、一定以上である場合、前記コンテンツ要求メッセージの転送先をマルチキャストアドレスで登録することを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、レイヤ２、３ネットワークにおいて転送されるデータのコンテンツ情報に基づいてデータを転送するデータ転送装置、転送方法、およびプログラムに関する。
【背景技術】
【０００２】
従来、複数のサーバが同一のコンテンツを保持している環境で、あるクライアントがそのコンテンツを要求し、同コンテンツを保持するいずれかのサーバから、そのコンテンツを取得する場合、非特許文献１は、アプリケーション層でコンテンツの所在地のデータベースを作成し、クライアントはそのデータベースにコンテンツを保持するサーバを照会し、直接サーバに要求を出す集中管理型の配布方式を記載する。
【０００３】
また、非特許文献２は、コンテンツの情報から同一の規則で一意なｉｄ等を生成し、そのｉｄを持つネットワークノードにそのコンテンツを常に保持させる分散型配布方式を記載する。非特許文献３は、コンテンツを持つノードがそのＩＰアドレスがコンテンツを持つ事を明示的に広報し、クライアントはコンテンツを保持するサーバのＩＰアドレスあてに通常のＩＰルーティングの仕組みでコンテンツを要求することを記載する。
【０００４】
これらのアプリケーション層での仕組みにたよらず、ネットワーク層以下のルーティングプロトコル、スイッチングでコンテンツ要求／配信の仕組みを実現させる場合、ルーティング、スイッチングを担うルータ、スイッチはペイロード内のコンテンツ情報を知り得ない。このため、同じコンテンツに対する要求メッセージが異なるクライアントから送信されたとしても、ルータ、スイッチは、その要求メッセージをブロードキャスト（またはマルチキャスト）を用いて、全てのサーバに繰り返し送ることになる。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】BitTorrent, http://www.bittorrent.com/［平成２４年２月２４日検索］
【非特許文献２】I. Stoica, et al., "Chord: A scalable peer-to-peer lookup service for internet applications," Proc. conference on Applications, technologies, architectures, and protocols for computer communications, pp. 149-160, ACM SIGCOM'01, 2001.
【非特許文献３】Van Jacobson, “Introduction to Content Centric Networking,” FISS(Future Internet Summer School) 2009, June 2009.
【発明の概要】
【発明が解決しようとする課題】
【０００６】
背景技術で述べた通り、ＩＰ，イーサネット（登録商標）のような、ルーティングやＭＡＣ学習により、そのパケット（フレーム）の転送先を示すテーブルを構築するネットワーク機能を用いて、クライアントの要求に基づいたコンテンツ要求メッセージを、コンテンツを持つ可能性がある複数サーバに送信する場合、ルータやスイッチはペイロード上のコンテンツ情報を知り得ないため、同じコンテンツに対する要求メッセージが異なるクライアントから送信されたとしても、その要求メッセージをブロードキャスト（またはマルチキャスト）を用いて、複数サーバに繰り返し送ることになる（図１）。そのブロードキャストトラヒックにより、ネットワークの帯域が浪費されるという課題がある。
【０００７】
したがって、本発明は、同じコンテンツに対する要求メッセージが異なるクライアントから送信された場合、ブロードキャストをユニキャストまたはマルチキャストに変更することにより、ネットワークの帯域を浪費させないデータ転送装置、転送方法、およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記課題を解決するため本発明のデータ転送装置は、ＩＰまたはイーサネットネットワーク上でクライアントからサーバへのコンテンツ要求メッセージ、およびサーバからクライアントへのそのコンテンツ応答メッセージを中継するデータ転送装置であって、前記コンテンツ要求メッセージのペイロードを確認する確認手段と、ペイロードの中身のコンテンツ情報とコンテンツ要求メッセージの転送先を関連づけて登録する転送テーブルと、前記転送テーブルに登録済みのコンテンツ情報に関するコンテンツ要求メッセージを、前記転送先に転送するパケット転送手段とを備える。
そして、 前記転送テーブルは、同一コンテンツを有するサーバの数が、一定以上である場合、前記コンテンツ要求メッセージの転送先をマルチキャストアドレスで登録する。
【０００９】
また、前記確認手段は、前記コンテンツ応答メッセージのペイロードをさらに確認し、前記応答メッセージのコンテンツ情報が、前記転送テーブルに登録されていない場合、該コンテンツ情報と前記応答メッセージの送信元サーバのアドレスを関連づけて登録することも好ましい。
【００１０】
また、前記転送テーブルは、ハッシュ関数により前記ペイロードの中身のコンテンツ情報からハッシュ値を生成し、該ハッシュ値と前記コンテンツ要求メッセージの転送先を関連づけて登録することも好ましい。
【００１２】
上記課題を解決するため本発明のデータ転送方法は、ＩＰまたはイーサネットネットワーク上でクライアントからサーバへのコンテンツ要求メッセージ、および応答メッセージを中継するデータ転送方法であって、前記コンテンツ要求メッセージのペイロードを確認する確認ステップと、ペイロードの中身のコンテンツ情報とパケットの転送先を関連づけて登録した転送テーブルに登録済みのコンテンツ情報に関する要求メッセージを、前記転送先に転送するパケット転送ステップとを有する。
そして、 前記転送テーブルは、同一コンテンツを有するサーバの数が、一定以上である場合、前記コンテンツ要求メッセージの転送先をマルチキャストアドレスで登録する。
【００１３】
上記課題を解決するため本発明のプログラムは、ＩＰまたはイーサネットネットワーク上でクライアントからサーバへのコンテンツ要求メッセージ、および応答メッセージを中継するコンピュータを、前記コンテンツ要求メッセージのペイロードを確認する確認手段と、ペイロードの中身のコンテンツ情報とパケットの転送先を関連づけて登録する転送テーブルに登録済みのコンテンツ情報に関する要求メッセージを、前記転送先に転送するパケット転送手段として機能させる。
そして、 前記転送テーブルは、同一コンテンツを有するサーバの数が、一定以上である場合、前記コンテンツ要求メッセージの転送先をマルチキャストアドレスで登録する。
【発明の効果】
【００１４】
上記本発明により、レイヤ２、３のパケット転送機能に基づき、コンテンツの要求メッセージのブロードキャスト転送によるネットワーク帯域の浪費を避けて転送処理でき、かつ転送テーブルの使用メモリ量を低減させる事が出来る。
【図面の簡単な説明】
【００１５】
【図１】既存技術による要求メッセージのブロードキャストを示す。
【図２】本発明のデータ転送装置のシステム構成図を示す。
【図３】本発明の実施形態を説明するためのネットワーク構成である。
【図４】本発明の第１の実施形態での転送テーブルを示す。
【図５】本発明の第２の実施形態での転送テーブルを示す。
【発明を実施するための形態】
【００１６】
本発明を実施するための最良の実施形態について、以下では図面を用いて詳細に説明する。図２に、本発明のデータ転送装置のシステム構成図を示す。
【００１７】
本発明のデータ転送装置１は、ＩＰまたはイーサネットネットワーク上でクライアントからサーバへのコンテンツ要求メッセージ、サーバからクライアントへのその応答メッセージを中継するルータまたはスイッチ（以下中継ノード）である。データ転送装置１は、ペイロード確認部１１、転送テーブル１２、およびパケット転送部１３を備える。
【００１８】
ペイロード確認部１１は、コンテンツ要求メッセージ、応答メッセージパケット（フレーム）のペイロードを確認する機能を有する。
【００１９】
転送テーブル１２は、ペイロードの中身のコンテンツ情報とパケットの転送先を関連づけて登録する。転送テーブル１２は、コンテンツ名、宛先、Ｉ／Ｆを備え、これらを関連づけて保持している。
【００２０】
コンテンツ名は、サーバが持つコンテンツに関する情報である。宛先は、クライアントからの任意のコンテンツ要求の要求メッセージに応じて、そのコンテンツを持つサーバからの応答メッセージのコンテンツを含むパケットの送信元サーバのアドレス、または、コンテンツを持っている事を示す応答メッセージを含むパケットの送信元サーバのアドレスである。Ｉ／Ｆは送信元サーバへパケットを転送するインタフェースを示す。
【００２１】
これらの情報は、ペイロード確認部１１が、上記応答メッセージのペイロードを確認した際に、コンテンツ名が未登録である場合、ペイロード確認部１１は、コンテンツ名、送信元サーバのアドレス、Ｉ／Ｆを関連づけて登録する。
【００２２】
なお、転送テーブル１２は、同一コンテンツの所在地の数に応じて最適な転送形式（ユニキャスト、マルチキャスト）を選択することもできる。さらに、ハッシュ関数によりコンテンツ名からハッシュ値を生成し、このハッシュ値をコンテンツ名とすることにより、転送テーブル１２は、コンテンツ数が転送テーブル１２のメモリ制限またはアドレス空間制限を超えても、コンテンツを登録できる。
【００２３】
パケット転送部１３は、転送テーブル１２上に登録済みのコンテンツ名に関する要求メッセージを含むパケットを適切なコンテンツ保持サーバへ転送する。
【００２４】
図３は、本発明の実施形態を説明するためのネットワーク構成である。図３に示されるネットワーク構成において、中継ノードＳＷ２が、本発明のデータ転送装置１に対応する。
【００２５】
クライアントは、コンテンツａｂｃの要求メッセージを送信する。要求するコンテンツの保持サーバの宛先を知らないため、クライアントはブロードキャストアドレスを宛先として要求メッセージを送信する。
【００２６】
データ転送装置１は、上記要求メッセージパケットを受信し、ペイロード確認部１１がペイロードをチェックし、コンテンツａｂｃの要求メッセージであることを確認する。しかし、コンテンツａｂｃに対する最初の要求メッセージの場合、転送テーブル１２にコンテンツａｂｃは存在しない。このため、パケット転送部１３は、従来の図１のように、ブロードキャストで転送する。
【００２７】
上記要求メッセージパケットを受け取ったサーバＡ，Ｂ（ＳｖｒＡ，Ｂ）は、ユニキャストで応答メッセージをクライアントに返す（図３（ａ））。この応答メッセージを受けとったデータ転送装置１は、コンテンツａｂｃとサーバＡ，Ｂ（ＳｖｒＡ，Ｂ）を関連づけて転送テーブル１２に登録する。
【００２８】
図４は、本実施形態での転送テーブルを示す。図３においてコンテンツａｂｃはサーバＡ，Ｂ（ＳｖｒＡ，Ｂ）の両サーバが保持するため、図４のＳＷ２の転送テーブル上でコンテンツａｂｃは、ＳｖｒＡ，ＳｖｒＢのアドレスおよびインタフェースＡ，Ｂ（ＩＦＡ，Ｂ）と関連づけて登録される。
【００２９】
次に、別のクライアントが、コンテンツａｂｃの要求メッセージを送信し、データ転送装置１が受信した場合は、ペイロード確認部１１はコンテンツａｂｃの要求メッセージであることを確認する。
【００３０】
パケット転送部１３は、転送テーブル１２を参照し、コンテンツａｂｃの要求メッセージを複製し、ＳｖｒＡ，ＳｖｒＢのユニキャストアドレス宛で、インタフェースＡ，Ｂ（ＩＦＡ，Ｂ）から転送する（図３（ｂ））。
【００３１】
このように、本発明では、データ転送装置１がコンテンツを持つサーバの宛先を保持しているため、ブロードキャスト転送をユニキャスト転送に変更することができる。これにより、コンテンツの要求メッセージのブロードキャスト転送によるネットワーク帯域の浪費を避けることが実現される。
【００３２】
以下に、本発明の第２の実施形態を説明する。本実施形態は、登録されるコンテンツ数の増加や、複数サーバが同一コンテンツを持っていた場合の宛先ユニキャストアドレス数の複数登録に対するメモリ制限を考慮した形態である。
【００３３】
図５は、本発明の第２の実施形態での転送テーブルを示す。図５のようにコンテンツ名をそのまま保持するのではなく、テーブルのタプル数制限内のハッシュ値を生成するハッシュ関数によりコンテンツ名のハッシュ値を生成し、コンテンツ名の代わりに登録する。これにより、同一ハッシュ値を取るコンテンツ間でタプルを共有する。
【００３４】
本実施形態では、異なるコンテンツが同一ハッシュ値を取る場合がある。この場合、あるコンテンツの要求メッセージが同一ハッシュ値を取る他のコンテンツを保持する異なるサーバにも転送される。しかしながら、保持してないコンテンツの要求メッセージを受け取ったサーバはそれを破棄すればよく、同時に正しい宛先にも必ず要求メッセージが転送されるため、クライアントとしては要求したコンテンツを受け取る事が可能である。
【００３５】
また、本実施形態での転送テーブルは、宛先としても複数のユニキャストアドレスを登録するのではなく、コンテンツに対応するマルチキャストアドレスを一つ生成し宛先アドレスとして登録することもできる。同一コンテンツを保持しているサーバ数が、一定以上の場合、ユニキャストアドレスではなく、マルチキャストアドレスで登録する。これにより、宛先登録に必要な転送テーブル上の使用メモリ量を低減する事が可能である。
【００３６】
この場合、このマルチキャストアドレスを経由する中継ノード（図３では、ＳＷ３、ＳＷ４）も、コンテンツ情報をコンテンツ名のハッシュ値に基づいて生成し、コンテンツ情報に関連づけて登録することにより、他の中継ノードでもコンテンツ（のハッシュ値）とマルチキャストアドレスを転送テーブル上で関連づけることができる。
【００３７】
または、コンテンツを保持するサーバが応答メッセージの送信元アドレスとしてマルチキャストアドレスをコンテンツ毎に変えて付与する事もできる。
【００３８】
上記のいずれにおいても同コンテンツを保持するサーバは、同マルチキャストアドレスを受信できるように動作させる。
【００３９】
このようにして、応答メッセージを中継する、全ての中継ノード上で同一のハッシュ生成ルール、マルチキャストアドレス生成ルールに基づいて転送テーブルを構成する事により、要求メッセージを正しいコンテンツ保持宛先サーバに転送する事が可能となる。
【００４０】
また、任意のコンテンツの要求メッセージを送信するクライアントは、少なくとも初めて要求するコンテンツの保持サーバの宛先を知らないため、ブロードキャストアドレスを宛先として要求メッセージを送信するが、このコンテンツの宛先を転送テーブルに持つ、最初の中継ノードがこの要求メッセージを受け取った時に、宛先アドレスをコンテンツを保持するサーバの(マルチキャスト)アドレスに書き換える事により、続く中継ノードはペイロードをチェックする事無くマルチキャストアドレスのみを参照して通常のルーティング、スイッチングに基づく処理で、要求メッセージを宛先サーバに転送可能でもある。
【００４１】
また、以上述べた実施形態は全て本発明を例示的に示すものであって限定的に示すものではなく、本発明は他の種々の変形態様および変更態様で実施することができる。従って本発明の範囲は特許請求の範囲およびその均等範囲によってのみ規定されるものである。
【符号の説明】
【００４２】
１  データ転送装置
１１  ペイロード確認部
１２  転送テーブル
１３  パケット転送部
【図１】
0005796898.tif 000002
【図２】
0005796898.tif 000003
【図３】
0005796898.tif 000004
【図４】
0005796898.tif 000005
【図５】
0005796898.tif 000006