(57)【特許請求の範囲】
【請求項１】
ネットワーク上の入力ルータから出力ルータへ転送されるP2Pパケットを入力ルータにおいて符号化するパケット符号化装置において、
パケットのデータを不可逆に符号化圧縮する符号化手段と、
パケットの符号化データを管理するキャッシュテーブルと、
パケットの符号化データを前記キャッシュテーブルから検索する検索手段と、
前記キャッシュテーブルに未登録の符号化データを当該キャッシュテーブルに登録するキャッシュ管理手段と、
パケットの符号化データが前記キャッシュテーブルに既登録であると、当該パケットのデータを前記符号化データに置き換えて符号化パケットを生成する符号化パケット生成手段と、
符号化データが未登録のパケットについては当該パケットを、既登録のパケットについては当該パケットに代えて前記符号化パケットを、出力する手段とを具備し、
前記パケットのパケット長が可変長であり、
前記符号化手段は、
パケットのデータを固定長単位で複数のデータ片に分割する手段と、
各データ片を不可逆に符号化圧縮して符号化データ片を生成する手段と、
前記符号化データ片を結合して符号化データを生成する手段とを含み、
前記分割する手段は、複数のパケットに分割された元データが、当該元データの先頭から固定長単位で分割されるように各パケットのデータを分割することを特徴とするパケット符号化装置。
【請求項２】
前記出力ルータを識別する識別手段を含み、
前記キャッシュテーブルでは、パケットの符号化データが前記出力ルータの識別情報と対応付けて管理され、
前記検索手段は、前記出力ルータの識別情報および符号化データのペアが一致するエントリをキャッシュテーブルから検索し、
前記キャッシュ管理手段は、前記出力ルータの識別情報および符号化データを対応付けてキャッシュテーブルに登録し、
前記符号化パケット生成手段は、出力ルータの識別情報および符号化データのペアが既登録であると、前記パケットのデータを当該符号化データに置き換えることを特徴とする請求項１に記載のパケット符号化装置。
【請求項３】
前記キャッシュ管理手段は、前記パケットのデータおよびその符号化データを対応付けてキャッシュテーブルに登録し、
前記検索手段は、パケットのデータと対応付けられた符号化データを前記キャッシュテーブルから検索し、
前記符号化パケット生成手段は、前記パケットのデータが前記キャッシュテーブルに既登録であると、当該パケットのデータを当該データと対応付けられた符号化データに置き換えることを特徴とする請求項２に記載のパケット符号化装置。
【請求項４】
前記P2Pパケットが再送パケットであるか否かを判定する手段を具備し、
再送パケットは、その符号化データが前記キャッシュテーブルに既登録であっても、符号化せずに転送することを特徴とする請求項１に記載のパケット符号化装置。
【請求項５】
前記出力ルータを含む他のノードから、当該他のノードのキャッシュテーブルに関する更新内容と同一の更新を要求する更新要求を受信する手段を含み、
前記キャッシュ管理手段は、エントリ追加の更新要求に応答して自身のキャッシュテーブルを更新することを特徴とする請求項１に記載のパケット符号化装置。
【請求項６】
前記キャッシュ管理手段は、エントリ削除の更新要求に応答して自身のキャッシュテーブルを更新することを特徴とする請求項５に記載のパケット符号化装置。
【請求項７】
前記請求項１ないし３のいずれかに記載のパケット符号化装置により符号化されたパケットを前記出力ルータにおいて復号するパケット復号装置であって、
転送された非符号化パケットのデータを不可逆に符号化圧縮する符号化手段と、
前記データおよびその符号化データを対応付けて管理するキャッシュテーブルと、
前記非符号化パケットのデータおよびその符号化データを対応付けて前記キャッシュテーブルに登録するキャッシュ管理手段と、
転送された符号化パケットの符号化データを、当該符号化データと前記キャッシュテーブル上で対応付けられているデータに置き換える復号手段とを含むことを特徴とするパケット復号装置。
【請求項８】
前記請求項４のパケット符号化装置により符号化されたP2Pパケットを前記出力ルータにおいて復号するパケット復号装置であって、
転送された符号化パケットの符号化データが前記キャッシュテーブルに未登録であると、当該符号化パケットを破棄する手段を含むことを特徴とする請求項７に記載のパケット復号装置。
【請求項９】
前記請求項５または６のパケット符号化装置により符号化されたP2Pパケットを前記出力ルータにおいて復号するパケット復号装置であって、
転送された非符号化パケットのデータを符号化して得られた符号化データおよび自身の識別情報のペアのエントリ追加を要求する更新要求をネットワーク上のノードへ通知する更新要求手段を含むことを特徴とする請求項７に記載のパケット復号装置。
【請求項１０】
前記更新要求手段が、キャッシュテーブルから削除したエントリの削除を要求する更新要求をネットワーク上のノードへ通知することを特徴とする請求項９に記載のパケット復号装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケット符号化方法および装置ならびに復号方法および装置に係り、特に、ピア・ツー・ピア通信に係るトラヒックの削減に好適なパケット符号化方法および装置ならびに復号方法および装置に関する。
【背景技術】
【０００２】
近年の高速ADSLやFTTHを利用したインターネット接続の普及に伴い、動画や音楽などの大容量コンテンツのファイル交換を定常的に行うユーザが増加し、これら一部のユーザによってISP(Internet Services Provider)ネットワークの帯域が占有される現象が社会問題を引き起こしている。
【０００３】
大容量コンテンツのファイル交換方式として、従来のクライアント／サーバ型のサービス形態に代わり、特許文献１に開示されているような、サーバを介さずにコンピュータ端末同士が直接通信するピア・ツー・ピア(P2P:Peer to peer)方式が普及し、特に、コンテンツファイルをピース状に細分化し、複数のピアが分散的にファイルを共有するBitTorrent（ビットトレント）が急激に増えている。
【０００４】
図２１は、BitTorrentのファイル交換手順を示したブロック図であり、映画や音楽などのコンテンツファイルは、ピース状に分割された多数のファイル片（以下、単にピースと表現する）と、後述するトラッカーへのリンクおよび各ピースのハッシュ値を含むメタ情報ファイルとに分割される。このメタ情報ファイルは、BitTorrentではトレントファイル(.torrent)と呼ばれ、所定のWebサーバに配置される。前記ピースは、ネットワーク上の多数のピアPi (i=1,2…N) へ分散配置される。
【０００５】
コンテンツファイルのダウンロードを希望するピアP1は、そのトレントファイルが保存されているWebサーバにアクセス(1)して当該トレントファイルを取得(2)し、これをトラッカーへ送信(3)してピア情報を要求する。前記トラッカーは、トレントファイルごとに各ピアPiのIPアドレスを管理するサーバであり、ピア情報要求を受信したトラッカーは、指定されたトレントファイルと対応付けられているピア情報リストを要求元のピアP1へ返信(4)する。ピア情報リストを受信したピアP1は、リストアップされている各ピアPiとの間にP2P接続を確立(5)し、下りリンクを利用してピースをダウンロードする。
【０００６】
ピースを取得したピアP1は、当該ピースから計算されるハッシュ値とトレントファイルに予め登録されている当該ピースのハッシュ値とを比較し、両者が一致すれば正規のピースとして保存する一方、不一致であれば不正ファイルとして破棄する。その後、全てのピースが揃うと、これら全てのピースとトレントファイルとを合成してコンテンツファイルを生成する。その後、ピアP1はファイルの供給ノードとして機能し、各ピアからの要求に応答してピースを上りリンクでアップロードする。
【０００７】
このようなP2Pトラヒックによる帯域圧迫を防止する技術として、特許文献２には、ネットワークの帯域を監視し、帯域が圧迫状態になるとP2Pパケットを識別して破棄する技術が開示されている。
【特許文献１】特開２００３−１１４８５７号公報
【特許文献２】特開２００８−４８１３１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
ISPなどがネットワークの帯域を確保するためにP2Pパケットを無条件で破棄してしまうと、ユーザがファイル交換アプリケーションを利用できなくなるのでサービスの低下を招いてしまう。一方、P2Pパケットをそのまま放置するとP2Pトラフィックがますます増殖し、帯域圧迫が深刻になってユーザがファイル交換アプリケーションを快適に使用できない状況に陥ることが懸念される。
【０００９】
ここで、P2Pトラヒックによる帯域圧迫は、一般的なトラヒック増加に起因した帯域圧迫とは異なり、人気のあるコンテンツファイルの集中的なダウンロードに起因することが多く、このとき、ネットワーク上には同一データのパケットが大量に流れている。そして、このような現象は特にBitTorrentにおいて顕著である。したがって、P2Pパケットのデータを符号化してキャッシュしておけばトラヒック量の削減が期待できる。
【００１０】
しかしながら、可逆な符号化方式では圧縮率が低いので十分な効果が得られない。一方、ハッシュ関数のような不可逆な符号化方式を採用すれば、高い圧縮率を得られるものの復号側での復号処理が困難になる。
【００１１】
本発明の目的は、上記した従来技術の課題を解決し、P2Pによるデータファイル交換量を維持しながら、ネットワーク上のトラヒック量を大幅に削減できるパケット符号化方法および装置ならびに復号方法および装置を提供することにある。
【課題を解決するための手段】
【００１２】
上記の目的を達成するために、本発明のパケット符号化装置は、以下のような手段を含むことを特徴とする。
(1)パケットのデータを不可逆に符号化圧縮する符号化手段と、パケットの符号化データを管理するキャッシュテーブルと、パケットの符号化データを前記キャッシュテーブルから検索する検索手段と、前記キャッシュテーブルに未登録の符号化データを当該キャッシュテーブルに登録するキャッシュ管理手段と、パケットの符号化データが前記キャッシュテーブルに既登録であると、当該パケットのデータを前記符号化データに置き換えて符号化パケットを生成する符号化パケット生成手段と、符号化データが前記キャッシュテーブルに未登録であったパケット、および前記符号化パケットを転送する手段とを含むことを特徴とする。
【００１３】
また、本発明のパケット復号装置は、以下のような手段を含むことを特徴とする。
(2)転送された非符号化パケットのデータを不可逆に符号化圧縮する符号化手段と、データおよびその符号化データを対応付けて管理するキャッシュテーブルと、前記非符号化パケットのデータおよびその符号化データを対応付けて前記キャッシュテーブルに登録するキャッシュ管理手段と、転送された符号化パケットの符号化データを、当該符号化データと前記キャッシュテーブル上で対応付けられているデータに置き換える復号手段とを含むことを特徴とする。
【発明の効果】
【００１４】
本発明によれば、ネットワーク上で同一のP2Pパケットが同一のイングレス／イーグレス間で複数回転送される場合、一回目以外は全て圧縮率の高い一方向関数により符号化されるので、ネットワーク上のP2Pトラヒック量を効率良く削減できるようになる。
【発明を実施するための最良の形態】
【００１５】
以下、図面を参照して本発明の最良の実施形態について詳細に説明する。図１は、本発明が適用されるネットワークの構成を示したブロック図である。
【００１６】
ISPネットワークNWの各エッジルータER1，ER2，ER3…には、P2Pパケットのペイロード部に格納されているデータを符号化圧縮してキャッシュするキャッシュサーバ１０（１０ａ，１０ｂ，１０ｃ…）が、それぞれ接続されている。各キャッシュサーバ１０には、図２に一例を示した符号化テーブル１１および復号テーブル１２が登録されている。
【００１７】
前記符号化テーブル１１では、P2Pパケットのペイロード部に登録されているデータの符号化データ（本実施形態では、ハッシュ値）が、当該P2PパケットがISPネットワークNW内で最後に経由する終端ノードの識別情報（例えば、IPアドレス）と対応付けられて記憶される。前記復号テーブル１２では、P2Pパケットのペイロード部のデータおよびそのハッシュ値が、相互に対応付けられて記憶される。
【００１８】
図３は、前記各エッジルータERの主要部の構成を示した機能ブロック図であり、いずれのエッジルータERも同一または同等の構成を備えている。
【００１９】
本発明のエッジルータERは、ネットワークNWの外部から受信したパケットをネットワークNW内のルータに転送し、ネットワークNW内のルータからのパケットをネットワークNW外へ送信するエッジルータとして機能するためのインターフェース１、ルーティング制御部２およびルーティングテーブル３と共に、本発明に固有の機能として、自ノードがP2PパケットをネットワークNWに転送する入力ルータ（ingress：イングレス）として機能するためのイングレス機能部４と、自ノードがP2PパケットをネットワークNWから外部へ転送する出力ルータ（egress：イーグレス）として機能するためのイーグレス機能部５とを備えている。
【００２０】
前記イングレス機能部４において、パケット識別部４１は、ISPネットワークNWへ転送するパケットがP2Pパケットであるか否かを識別する。終端ノード識別部４２は、P2PパケットがネットワークNW内で最後に経由する終端ノード（イーグレス）を識別する。符号化部４３は、P2Pパケットのペイロード部に登録されているデータを不可逆に符号化圧縮する。本実施形態では、前記データが所定のハッシュ関数に適用されてハッシュ値が算出される。
【００２１】
検索部４４は、前記P2Pパケットのデータを符号化して得たハッシュ値が前記符号化テーブル１１に既登録であるか否かを判定する。キャッシュ管理部４５は、未登録のハッシュ値を前記パケットの終端ノード識別情報と対応付けて符号化テーブル１１に登録する。P2P符号化パケット生成部４６は、データのハッシュ値が符号化テーブル１１に既登録であったP2Pパケットの当該データを前記ハッシュ値に置換し、符号化されたP2Pパケット（以下、P2P符号化パケットと表現する）を生成する。
【００２２】
前記イーグレス機能部５において、パケット識別部５１は、ネットワークNWから外部へ出力するパケットがP2PパケットおよびP2P符号化パケットのいずれであるかを識別する。符号化部５２は、P2Pパケットのデータをハッシュ関数に適用してハッシュ値を算出する。キャッシュ管理部５３は、前記P2Pパケットのデータおよびそのハッシュ値を、相互に対応付けて復号テーブル１２に登録する。
【００２３】
復号部５４は、P2P符号化パケットに登録されているハッシュ値と対応付けられているデータを前記復号テーブル１２から読み込み、当該P2P符号化パケットのハッシュ値を前記データに置換してP2Pパケットに復号する。
【００２４】
次いで、フローチャートを参照して第１実施形態の動作を詳細に説明する。ここでは、図１のエッジルータER1に外部から入力したP2Pパケットが、ISPネットワークNWを経由してエッジルータER2から出力される場合を例にして説明する。したがって、本実施形態ではER1がイングレス、ER2がイーグレス（終端ノード）となる。図４はER1の動作を示したフローチャートであり、図５はER2の動作を示したフローチャートである。
【００２５】
ER1では、図４のステップＳ１において、ネットワーク外部から受信したパケットがP2Pパケットであるか否かが、前記パケット識別部４１で識別される。P2Pパケット以外であれば、ルーティング制御部２がルーティングテーブル３に登録されている経路情報に基づいて周知のルーティングを実行し、前記パケットをネットワークNW内の所定の宛先へ転送する。
【００２６】
これに対して、受信パケットがP2PパケットであればステップＳ２へ進み、当該P2Pパケットの宛先IPアドレスまたは宛先のネットワークアドレス（以下、単に宛先アドレスと表現する）に基づいて、前記終端ノード識別部４２によりイーグレス（ここでは、ER2）が識別される。
【００２７】
本実施形態では、後に詳述するように、各ルータがイーグレスとして動作する際に、自ノードのIPアドレスと転送したP2Pパケットの宛先アドレスとを対応付けてDHT（Distributed Hash Table：分散ハッシュテーブル）に記憶するようにしている。したがって、ER1は受信したP2Pパケットの宛先アドレスを検索キーとしてDHTを参照することで、当該P2Pパケットのイーグレスを識別できる。
【００２８】
なお、イーグレスとして動作するルータが自ノードのIPアドレスと転送したP2Pパケットの宛先アドレスとを対応付けて記憶する先は上記のDHTに限定されず、ER1による参照が可能であれば、集中型のデータベースや他の分散型データベースであっても良い。
【００２９】
ステップＳ３では、前記符号化部４３において、前記P2Pパケットのデータがハッシュ関数に適用されてハッシュ値が算出される。ステップＳ４では、前記P2Pパケットの終端ノード識別情報およびハッシュ値のペアを含むエントリが前記符号化テーブル１１に既登録であるか否かが、前記検索部４４による検索結果に基づいて判定される。ER1が初めて受信したP2Pパケットであれば、未登録と判定されるのでステップＳ５へ進む。
【００３０】
ステップＳ５では、前記P2Pパケットのハッシュ値が、前記終端ノード識別情報と対応付けられて、前記キャッシュ管理部４５により符号化テーブル１１に新規登録される。なお、ハッシュ値が同一で終端ノード識別情報のみが異なるエントリが既登録であれば、当該エントリに終端ノード識別情報のみが追加登録される。ステップＳ６では、前記P2Pパケットが他のパケットと同様に前記ルーティング制御部２によりネットワークNWに転送される。
【００３１】
図５へ進み、前記ER1によりネットワークNWへ転送されたP2Pパケットを受信したER2では、ステップＳ２０、２１において、当該パケットがP2PパケットおよびP2P符号化パケットのいずれであるかが、前記パケット識別部５１により判定され、ここでは、P2Pパケットと判定されるのでステップＳ２２へ進む。ステップＳ２２では、当該P2Pパケットの宛先アドレス（IPアドレスまたはネットワークアドレス）および自ノード(ER2)のIPアドレスのペアがDHT（分散ハッシュテーブル）に登録される。
【００３２】
ステップＳ２３では、前記符号化部５２において、前記P2Pパケットのデータが、前記ER1と同一のハッシュ関数に適用されてハッシュ値が算出される。ステップＳ２４では、P2Pパケットのデータおよびそのハッシュ値が、前記キャッシュ管理部５３により相互に対応付けられて復号テーブル１２に登録される。ステップＳ２５では、前記P2Pパケットが他のパケットと同様に、前記ルーティング制御部２によりネットワークNW外へ転送される。
【００３３】
図４へ戻り、ER1において、前記ネットワークNWへ転送済のP2Pパケットと、終端ノードおよびデータが同一のP2Pパケットが改めて受信されると、ステップＳ４では、その終端ノード識別情報およびデータのハッシュ値のペアが符号化テーブル１１に既登録と判定されるのでステップＳ７へ進む。ステップＳ７では、前記P2P符号化パケット生成部４６において、前記P2Pパケットのデータが前記ハッシュ値に置換されてP2P符号化パケットが生成される。ステップＳ８では、当該P2P符号化パケットが前記ルーティング制御部２によりネットワークNWへ転送される。
【００３４】
図５へ進み、ER2は、このP2P符号化パケットをステップＳ２１で受信するとステップＳ２６へ進む。ステップＳ２６では、このP2P符号化パケットのハッシュ値と復号テーブル１２上で対応付けられているデータが読み込まれる。ステップＳ２７では、前記復号部５４において、前記P2P符号化パケットのハッシュ値が前記読み込まれたデータに置き換えられてP2Pパケットに復号される。ステップＳ２８では、当該P2Pパケットが前記ルーティング制御部２によりネットワークNW外へ転送される。
【００３５】
本実施形態によれば、ISPネットワークNW上で同一のP2Pパケットが同一のイングレス／イーグレス間で複数回転送される場合、一回目以外は全て、そのデータが圧縮率の高い一方向関数により符号化されるので、ネットワーク上のP2Pトラヒック量を効率良く削減できるようになる。
【００３６】
さらに、本実施形態では各ERが自ノードを経由するP2Pパケットの符号化および復号に必要な情報しかキャッシュしないので、キャッシュサーバの有効利用が可能になる。
【００３７】
次いで、本発明の第２実施形態について説明する。上記の第１実施形態では、ER1がP2Pパケットのデータを直ちに符号化し、ハッシュ値が符号化テーブル１１に既登録であるか否かに基づいて、当該P2PパケットがイングレスのER1にとって最初のP2Pパケットであるか否かを判定するものとして説明した。
【００３８】
しかしながら、処理負荷の高い符号化方式を採用する場合や、符号化テーブル１１をイーグレス機能部５の復号テーブル１２と共用する場合には、P2Pパケットのデータを符号化テーブル１１に登録しておき、P2Pパケットのデータが符号化テーブル１１に既登録であるか否かに基づいて、当該P2Pパケットがイングレスにとって最初のデータであるか否かを判定する方が望ましい場合もある。そこで、以下に説明する第２実施形態では、図６に一例を示したように、符号化テーブル１１では、ハッシュ値をそのデータおよび終端ノード識別情報と対応付けて管理するようにしている。
【００３９】
次いで、フローチャートを参照して本実施形態の動作を詳細に説明する。ここでも、図１のエッジルータER1に外部から入力したP2Pパケットが、ISPネットワークNWを経由して他のエッジルータER2から出力される場合を例にして説明する。図７はER1の動作を示したフローチャートである。なお、ER2の動作は前記第１実施形態と同じなので、ここでは説明を省略する。
【００４０】
図７のステップＳ１１では、ネットワーク外部から受信したパケットがP2Pパケットであるか否かが識別される。P2Pパケット以外であれば周知のルーティングが実行され、前記パケットがネットワークNW内の所定の宛先へ転送される。これに対して、受信パケットがP2PパケットであればステップＳ１２へ進み、当該P2Pパケットの宛先IPアドレスに基づいてイーグレス（ここでは、ER2）が識別される。
【００４１】
ステップＳ１３では、前記P2Pパケットのデータおよび前記終端ノード識別情報のペアを含むエントリが前記符号化テーブル１１に既登録であるか否かが、前記検索部４４による検索結果に基づいて判定される。ER1が初めて受信したP2Pパケットであれば、未登録と判定されるのでステップＳ１４へ進む。
【００４２】
ステップＳ１４では、前記P2Pパケットのデータがハッシュ関数に適用されてハッシュ値が算出される。ステップＳ１５では、前記P2Pパケットのデータおよびそのハッシュ値が、前記終端ノード識別情報と対応付けられて、前記キャッシュ管理部４５により符号化テーブル１１に新規登録される。ステップＳ１６では、前記P2Pパケットが他のパケットと同様に前記ルーティング制御部２によりネットワークNWに転送される。
【００４３】
その後、ER1において転送済のP2Pパケットと終端ノードおよびデータが同一のP2Pパケットが改めて受信されると、ステップＳ１３では、その終端ノード識別情報およびデータのペアが符号化テーブル１１に既登録と判定されるのでステップＳ１７へ進む。ステップＳ１７では、前記符号化テーブル１１上で当該ペアと同一ペアのエントリに登録されているハッシュ値が読み込まれる。ステップＳ１８では、前記P2Pパケットのデータが当該ハッシュ値に置換されてP2P符号化パケットが生成される。ステップＳ１９では、当該P2P符号化パケットが前記ルーティング制御部２によりネットワークNWへ転送される。
【００４４】
本実施形態によれば、ハッシュ値が符号化テーブル１１に未登録のP2Pパケットのみを対象に、そのデータの符号化処理が行われるので符号化処理の総量を減じることができる。したがって、処理負荷の高い符号化方式を採用した場合でも高速な処理が可能になる。
【００４５】
図８は、本発明の第３実施形態に係るエッジルータERの主要部の構成を示した機能ブロック図であり、図９は、キャッシュサーバ１０の一例を示した図である。本実施形態では、第１実施形態と較べて各ERのイングレス機能部４から終端ノード識別部４２が省略され、符号化テーブル１１でも、終端ノードの項目が省略され、識別情報の項目が追加されている。
【００４６】
図１０は前記ER1の動作を示したフローチャートであり、図１１は前記ER2の動作を示したフローチャートである。ここでも、ER1に外部から入力したP2PパケットがネットワークNWを経由してER2から出力される場合を例にして説明する。したがって、本実施形態でもER1がイングレス、ER2がイーグレス（終端ノード）となる。
【００４７】
ER1では、図１０のステップＳ４１において、ネットワーク外部から受信したパケットがP2Pパケットであると判定されるとステップＳ４２へ進み、そのペイロード部に格納されているデータがハッシュ関数に適用されてハッシュ値が算出される。ステップＳ４３では、このハッシュ値が前記符号化テーブル１１に既登録であるか否かが判定される。ER1が初めて受信したP2Pパケットであれば、未登録と判定されるのでステップＳ４４へ進む。ステップＳ４４では、前記P2Pパケットのハッシュ値が、当該パケットの送信元IPアドレス、ポート、宛先IPアドレス、ポートおよびシークエンス番号等の再送判別用の識別情報と対応付けられて符号化テーブル１１に登録される。ステップＳ４５では、前記P2Pパケットが他のパケットと同様に前記ルーティング制御部２によりネットワークNWへ転送される。
【００４８】
図１１へ進み、ER2は前記ER1によりネットワークNWに転送されたP2Pパケットを受信すると、ステップＳ５１では当該パケットがP2Pパケットと判定されるのでステップＳ５３へ進む。ステップＳ５３では、前記P2Pパケットのデータがハッシュ関数に適用されてハッシュ値が算出される。ステップＳ５４では、前記P2Pパケットのデータおよびそのハッシュ値が復号テーブル１２に登録される。ステップＳ５５では、前記P2Pパケットが他のパケットと同様に、前記ルーティング制御部２によりネットワーク外へ転送される。
【００４９】
図１０へ戻り、ER1はネットワークNWへ転送済のP2Pパケットとデータが同一のP2Pパケットを改めて受信すると、ステップＳ４３では、そのハッシュ値が符号化テーブル１１に既登録と判定されるのでステップＳ４６へ進む。ステップＳ４６では、当該P2Pパケットが再送パケットであるか否かが、当該パケットの送信元IPアドレス、ポート、宛先IPアドレス、ポートおよびシークエンス番号等と既登録の識別情報とを比較して判別される。再送パケットでなければステップＳ４７へ進み、前記P2Pパケットのデータが前記ハッシュ値に置換されてP2P符号化パケットが生成される。ステップＳ４８では、当該P2P符号化パケットが前記ルーティング制御部２によりネットワークNW内へ転送される。
【００５０】
図１１へ進み、ER2は、このP2P符号化パケットをステップＳ５２で受信するとステップＳ５６へ進む。ステップＳ５６では、P2P符号化パケットのハッシュ値が復号テーブル１２に既登録であるか否かが判定される。既登録であればステップＳ５７へ進み、このハッシュ値と復号テーブル１２上で対応付けられているデータが読み込まれる。ステップＳ５８では、前記P2P符号化パケットのハッシュ値が、前記読み込まれたデータに置換されてP2Pパケットに復号される。ステップＳ５９では、当該P2Pパケットが前記ルーティング制御部２によりネットワーク外へ転送される。
【００５１】
これに対して、前記ステップＳ５６において、P2P符号化パケットのハッシュ値が復号テーブル１２に未登録と判定されると、ステップＳ６０へ進んで当該P2P符号化パケットが破棄される。
【００５２】
図１０へ戻り、ER2においてP2P符号化パケットが破棄されると、その送信元からは、符号化前のP2Pパケットが再送信される。TCPでは再送パケットが同一経路で送信されるのが普通なので、ER1は、この再送P2PパケットをステップＳ４６で検知してステップＳ４５へ進む。ステップＳ４５では、当該再送P2Pパケットが他のパケットと同様に前記ルーティング制御部２によりネットワークNWへそのまま転送される。
【００５３】
なお、再送パケットが同一経路で送信されなくても、本実施形態では他のルータが改めてイングレスとして機能し、そのデータを前記ER1と同様に改めてキャッシュするので、２回目以降はP2P符号化パケットを転送できるようになる。また、再送パケットが上記のキャッシュ機能を備えていないエッジルータを経由したとしても、P2Pパケットが符号化されることなく転送されるだけなので、P2Pパケットの到達性に影響が生じることはない。
【００５４】
本実施形態によれば、ハッシュ値をキャッシュしていない終端ノードにP2P符号化パケットが転送されると、改めて符号化前のP2Pパケットが転送されるので、ER1では終端ノードでのキャッシュ状態を意識することなくP2P符号化パケットを転送できる。
【００５５】
図１２は、本発明の第４実施形態に係るエッジルータERの主要部の構成を示した機能ブロック図であり、前記と同一の符号は同一または同等部分を表している。
【００５６】
本実施形態では、ERのイーグレス機能部５にエントリ更新要求部５６を設けて、P2Pパケットを受信したイーグレス(ER2)が当該受信パケットの宛先アドレスおよび自ノードのIPアドレスをイングレス(ER1)へ通知するようにし、一方、イングレス機能部４では前記キャッシュ管理部４５が、エントリの更新内容を符号化テーブル１１に反映するようにした点に特徴がある。また、図１３は、本実施形態におけるキャッシュサーバ１０の内容を模式的に示した図である。
【００５７】
図１４は、前記ER1の動作を示したフローチャートであり、図１５は、前記ER2，ER3の動作を示したフローチャートである。
【００５８】
ER1は、図１４のステップＳ７１でネットワーク外部からP2Pパケットを受信するとステップＳ７２へ進む。ステップＳ７２では、その終端ノード（ここでは、ER2）が識別される。ステップＳ７３では、P2Pパケットのデータがハッシュ関数に適用されてハッシュ値が算出される。
【００５９】
ステップＳ７４では、前記P2Pパケットの終端ノード識別情報および前記ハッシュ値のペアと同一のペアを含むエントリが前記符号化テーブル１１に既登録であるか否かが判定される。ER1が初めて受信するP2Pパケットであれば、未登録と判定されるのでステップＳ７５へ進む。ステップＳ７５では、当該P2Pパケットが他のパケットと同様に前記ルーティング制御部２によりネットワークNWへ転送される。
【００６０】
図１５へ進み、ER2は、前記ER1によりネットワークNWに転送されたP2PパケットをステップＳ９１で受信するとステップＳ９３へ進む。ステップＳ９３では、前記P2PパケットのデータがER1と同一のハッシュ関数に適用されてハッシュ値が算出される。ステップＳ９４では、符号化テーブル１１の空き容量が十分であるか否かが判定され、不十分であればステップＳ９５へ進む。
【００６１】
ステップＳ９５では、符号化テーブル１１に登録されているエントリの一部が削除されて空き領域が確保される。本実施形態では、エントリごとにライフタイム、使用頻度、あるいは経過時間等が監視され、ライフタイムの短い順、使用頻度の低い順、あるいは登録からの経過時間が長い順などの適宜の優先度で各エントリが削除される。ステップＳ９６では、前記P2Pパケットのハッシュ値および終端ノード識別情報が相互に対応付けられて復号テーブル１２に登録される。
【００６２】
ステップＳ９７では、前記P2Pパケットが前記ルーティング制御部２によりネットワーク外へ転送される。ステップＳ９８では、前記エントリ更新要求部５６により、前記追加したハッシュ値および自ノード(ER2)のIPアドレスのペア、ならびに削除したハッシュ値および自ノードのIPアドレスのペアが、エントリ更新要求メッセージに登録されてネットワークNW上の全て、または一部のルータへ送信される。
【００６３】
図１４へ戻り、ER1では、前記エントリ更新要求メッセージがステップＳ７７で受信されるとステップＳ７８へ進む。ステップＳ７８では、受信したエントリ更新要求メッセージに基づいて前記符号化テーブル１１が更新される。すなわち、追加されたエントリと対応するエントリ（ハッシュ値およびER2のIPアドレスのペア）が符号化テーブル１１に未登録であれば当該エントリが新規に追加される一方、ハッシュ値は一致するもののIPアドレスが異なるエントリが既登録であれば、当該エントリの「終端ノード」の欄にER2のIPアドレスが追加される。
【００６４】
同様に、削除されたエントリと対応するエントリが符号化テーブル１１に既登録であれば当該エントリが削除され、その際、当該エントリの「終端ノード」の欄に前記ER2のIPアドレスのみならず他のルータのIPアドレスも登録されていれば、前記ER2のIPアドレスのみが削除される。
【００６５】
その後、ER1が転送済のP2Pパケットと終端ノード識別情報およびハッシュ値が同一のP2Pパケットを改めて受信すると、ステップＳ７４では、当該終端ノード識別情報およびハッシュ値のペアが符号化テーブル１１に既登録と判定されるのでステップＳ７９へ進む。ステップＳ７９では、前記P2Pパケットのデータが、そのハッシュ値に置換されてP2P符号化パケットが生成される。ステップＳ８０では、前記P2P符号化パケットが前記ルーティング制御部２によりネットワークNWへ転送される。
【００６６】
図１５へ進み、ER2は、このP2P符号化パケットをステップＳ９２で受信するとステップＳ９９へ進む。ステップＳ９７では、P2P符号化パケットのハッシュ値と復号テーブル１２上で対応付けられているデータが読み込まれる。ステップＳ１００では、前記P2P符号化パケットのハッシュ値が、前記読み込まれたデータに置換されてP2Pパケットに復号される。ステップＳ１０１では、当該P2Pパケットが前記ルーティング制御部２によりネットワーク外へ転送される。
【００６７】
一方、前記ER2がステップＳ９８で送信したエントリ更新要求メッセージは、ネットワーク上の全て、または一部のルータへ転送されるので、今回のP2Pパケットに対してイングレスとして機能しているER1以外の他のルータでも受信される。
【００６８】
例えばER3は、図１４のステップＳ７７で前記エントリ更新要求メッセージを受信するとステップＳ７８へ進む。しかしながら、ER3には前記P2Pパケットの終端ノード識別情報およびハッシュ値が未登録なので、ステップＳ７８では、終端ノード識別情報およびハッシュ値のペアが符号化テーブル１１に登録される。
【００６９】
ER3はその後、このペアと同一のP2PパケットをステップＳ７１で受信すると、ER3にとっては最初のP2Pパケットであるにもかかわらず、ステップＳ７４では既登録と判定されるのでステップＳ７９以降へ進み、その符号化パケットが生成されて転送される。
【００７０】
本実施形態によれば、イングレスとして機能していないノードも、イーグレスから送信されるエントリ更新要求メッセージに応答して自ノードのエントリを更新できるので、自ノードにとって最初のP2PパケットであってもP2P符号化パケットに変換して転送できるようになる。
【００７１】
なお、上記の各実施形態では、キャッシュサーバ１０を各エッジルータERに設け、ISPネットワークNWを通過するP2Pパケットのトラヒックを削減するものとして説明したが、本発明はこれのみに限定されるものではなく、図２０に一例を示したように、ネットワークNW内でユーザ端末１２の直前に位置するエンドルータ１１にキャッシュサーバ１０に設け、エッジルータERとエンドルータ１１との間、あるいはエンドルータ１１間で交換されるP2Pパケットを符号化／復号するようにしても良い。
【００７２】
また、上記の第３、４実施形態では、イングレスのER1においてP2Pパケットが符号化テーブル１１に既登録であるか否かの判定が、当該P2Pパケットのデータを符号化して得られたキャッシュ値に基づいて行われるものとして説明したが、本発明はこれのみに限定されるものではなく、前記第２実施形態と同様に、P2Pパケットのデータが既登録であるか否かに基づいて判定されるようにしても良い。
【００７３】
ところで、P2Pパケットが可変長であると、同一部分のコンテンツデータであっても、長さが同一の複数のデータに常に分割されるとは限らないので、キャッシュデータの有効利用が難しくなる。
【００７４】
例えば、図１６(a)に一例を示したように、１００バイトのデータが常に上位５０バイトと下位５０バイトとに２分割されれば、上位５０バイトおよび下位５０バイトのそれぞれから算出したハッシュ値をキャッシュすることで、当該ハッシュ値を同一部分のデータのパケットに対して再利用できる。
【００７５】
しかしながら、P2Pパケットが可変長であって、同図(b)に示したように、例えば上位４０バイトと下位６０バイトとに２分割されたり、あるいは３分割されたりすると、それぞれに改めてハッシュ値が計算されてキャッシュされるため、先に割り当てられたハッシュ値を再利用できなくなる。
【００７６】
そこで、本発明では元データを先頭から固定の単位長ごと切り出してデータ片を生成し、このデータ片ごとに符号化圧縮を行って符号化データを生成するようにしている。
【００７７】
図１７は、データを単位長ごとの符号化する手順を示したフローチャートであり、ステップＳ１０１では、可変長のP2Pパケットの一つが今回の注目パケットとして取り込まれる。ステップＳ１０２では、今回の注目パケットのシークエンス番号(Seq)およびパケット長(Len)がヘッダ情報から抽出される。ステップＳ１０３では、注目パケットのプリフィックスの位置が識別される。P2Pパケットでは、プリフィックスは各ピースの先頭位置に配置され、固有のバイト配列であることが多いので、バイト配列を参照することでプリフィックス位置を識別できる。ステップＳ１０４では、前記Seq、Lenおよびプリフィックス位置に基づいて、パケットデータの前後部分に生じる端数（前端数および後端数）が算出される。
【００７８】
図１８は、前記端数の算出方法を模式的に表現した図であり、例えば、Seqが１０００、Lenおよびヘッダ長から求まるペイロード長が６００バイト、単位長が１２８バイト、プリフィックス位置がペイロード先端から２００バイト目であり、プリフィックス（例えば、１２バイト）を符号化対象としなければ、前端数は７２（Mod[２００，１２８]）バイト、後端数は４（Mod[（６００−２００−１２），１２８]バイトとなる。なお、プリフィックス（例えば、１２バイト）を符号化対象とするのであれば、図１９に示したように、前端数は７２（Mod[２００，１２８]）バイト、後端数は１６（Mod[（６００−２００），１２８]バイトとなる。
【００７９】
図１７へ戻り、ステップＳ１０５では、前端数の次から単位長ごとにデータが符号化されてハッシュ値が算出される。図１９の例では、前端数と後端数との間のデータが４つの単位長に分割されることが判る。ステップＳ１０６では、符号化が後端数の手前まで完了したか否かが判定され、完了していなければステップＳ１０５へ戻り、符号化位置を単位長ずつ移動させながら符号化処理が継続される。
【００８０】
今回の注目パケットに関して、単位長ごとの符号化処理が全て（図１９では、４つ）完了するとステップＳ１０７へ進む。ステップＳ１０７では、図１９に示したように、前端数および後端数のデータはそのままで、単位長のデータのみが符号化されたP2P符号化パケットが生成される。
【００８１】
ステップＳ１０８では、符号化前のIPヘッダのTotal LengthおよびHeader Checksum、符号化前のTCPヘッダのChecksum、ならびに上記の単位長分割の結果を代表する符号化ステータスなどが、P2P符号化パケットのIPヘッダオプションまたはペイロード部の一部に登録される。本実施形態では、前端数バイト数、各単位長部分のバイト数（符号化「１６バイト」、非符号化「１２８バイト」）および後端数バイト数が符号化ステータスとして登録される。したがって、図１９に示した例では、（７２，１６，１６，１６，１６，１６）が符号化ステータスとして登録される。
【００８２】
なお、固定長部分であっても、符号化できなかった部分は１２８バイトのデータがそのまま登録される。また、端数が発生しない場合には「０」が登録される。さらに、符号化前のIPヘッダやTCPヘッダに関する情報は復号側でデータを再構築する際に計算できるので、これら全てを前記符号化ステータスとして登録することなく、その一部または全部を省略しても良い。
【００８３】
ステップＳ１０９では、前記P2P符号化パケットに関して、そのIPヘッダのTotal LengthおよびHeader Checksum、ならびにTCPヘッダのChecksumが再計算される。ステップＳ１１０では、全てのパケットに関して上記の処理が完了したか否かが判定され、完了していなければステップＳ１０１へ戻り、注目パケットを切り替えながら上記の各処理が繰り返される。
【００８４】
このP2P符号化パケットを復号する際は、ヘッダ情報からSeq、Lenおよび符号化ステータスを抽出し、これらに基づいて前端数および後端数を識別する。そして、符号化された固定長部分は復号し、前端数部、後端数部、および符号化されていない固定長部分はそのままとし、これら全てを結合してヘッダ情報を書き換えることでパケットデータが再現される。
【００８５】
なお、上記した実施形態では、コンテンツデータに含まれるプリフィックスに着目して当該コンテンツデータを固定長単位で分割するものとして説明したが、本発明はこれのみに限定されるものではなく、コンテンツデータの配送単位に付されてマーカとして機能するデータ配列であれば、他のデータ配列に着目するようにしても良い。
【図面の簡単な説明】
【００８６】
【図１】本発明が適用されるネットワークの構成を示したブロック図である。
【図２】キャッシュサーバの第１実施形態の内容を模式的に示した図である。
【図３】エッジルータの第１実施形態の構成を示した機能ブロック図である。
【図４】第１実施形態におけるイングレスルータの動作を示したフローチャートである。
【図５】第１実施形態におけるイーグレスルータの動作を示したフローチャートである。
【図６】キャッシュサーバの第２実施形態の内容を模式的に示した図である。
【図７】第２実施形態におけるイングレスルータの動作を示したフローチャートである。
【図８】エッジルータの第３実施形態の構成を示した機能ブロック図である。
【図９】キャッシュサーバの第３実施形態の内容を模式的に示した図である。
【図１０】第３実施形態におけるイングレスルータの動作を示したフローチャートである。
【図１１】第３実施形態におけるイーグレスルータの動作を示したフローチャートである。
【図１２】エッジルータの第４実施形態の構成を示した機能ブロック図である。
【図１３】キャッシュサーバの第４実施形態の内容を模式的に示した図である。
【図１４】第４実施形態におけるイングレスルータの動作を示したフローチャートである。
【図１５】第５実施形態におけるイーグレスルータの動作を示したフローチャートである。
【図１６】パケットデータをキャッシュする際の技術課題を説明した図である。
【図１７】パケットデータを単位長ごとに符号化する手順を示したフローチャートである。
【図１８】P2Pパケットのデータを単位長ごとに符号化する方法（その１）を示した模式図である。
【図１９】P2Pパケットのデータを単位長ごとに符号化する方法（その２）を示した模式図である。
【図２０】本発明の変形例を示した図である。
【図２１】BitTorrentのファイル交換手順を示したブロック図である。
【符号の説明】
【００８７】
１…インターフェース，２…ルーティング制御部，３…ルーティングテーブル，４…イングレス機能部，５…イーグレス機能部，１０…キャッシュサーバ，１１…符号化テーブル，１２…復号テーブル
【図１】
0005131915.tif 000002
【図２】
0005131915.tif 000003
【図３】
0005131915.tif 000004
【図４】
0005131915.tif 000005
【図５】
0005131915.tif 000006
【図６】
0005131915.tif 000007
【図７】
0005131915.tif 000008
【図８】
0005131915.tif 000009
【図９】
0005131915.tif 000010
【図１０】
0005131915.tif 000011
【図１１】
0005131915.tif 000012
【図１２】
0005131915.tif 000013
【図１３】
0005131915.tif 000014
【図１４】
0005131915.tif 000015
【図１５】
0005131915.tif 000016
【図１６】
0005131915.tif 000017
【図１７】
0005131915.tif 000018
【図１８】
0005131915.tif 000019
【図１９】
0005131915.tif 000020
【図２０】
0005131915.tif 000021
【図２１】
0005131915.tif 000022