JP5590580B2 - オーバーレイネットワークで通信ピアの選択をサポートする方法およびシステム - Google Patents

Description

本発明は、オーバーレイネットワークで通信ピアの選択をサポートする方法に関する。複数の通信ピアがある情報を提供することによって前記オーバーレイネットワークに参加し、該参加している通信ピアおよび該通信ピアにより所有される情報のデータベースを維持管理する少なくとも１つのピアツーピアサーバーすなわちトラッカーが設けられ、該トラッカーは、ある通信ピアすなわち要求側クライアントから特定の情報に関する問合せを受信した後、すべての通信ピアのうち前記要求された情報を所有するサブセットを含むリストを前記要求側クライアントに提供することによって前記問合せに応答する。

また、本発明は、オーバーレイネットワークで通信ピアの選択をサポートするシステムに関する。該システムは、ある情報を提供することによって前記オーバーレイネットワークに参加する複数の通信ピアと、該参加している通信ピアおよび該通信ピアにより所有される情報のデータベースを維持管理する少なくとも１つのピアツーピアサーバーすなわちトラッカーを有し、該トラッカーは、ある通信ピアすなわち要求側クライアントから特定の情報に関する問合せを受信した後、すべての通信ピアのうち前記要求された情報を所有するサブセットを含むリストを前記要求側クライアントに提供することによって前記問合せに応答するように構成される。

オーバーレイネットワークに基づくアプリケーション、特にピアツーピア（Ｐ２Ｐ）ファイル共有アプリケーションは、インターネットトラフィック全体のかなりの割合を占める。例えばＩｐｏｑｕｅ（www.ipoque.com）によってなされている現在のインターネットトラフィック研究によれば、普及しているＢｉｔＴｏｒｒｅｎｔファイル共有アプリケーションだけで大量のトラフィックを生成しており、いくつかの環境では、ＩＳＰ（インターネットサービスプロバイダ）ネットワークにおけるトラフィック全体の５０％を超える割合に達する。したがって、多くの事業者がＰ２Ｐアプリケーションに対して不満であることも驚きではない。というのも、Ｐ２Ｐアプリケーションは大量のトラフィックを生じているからだけではない。このようなアプリケーションの本来の性質によれば、事業者によって優先されたはずの通信ピア（例えば自己のネットワーク内のピア）を選択することが可能となるのに、このトラフィックは事業者にとって高価なリンクを、制御不可能な形で通るからである。

したがって、いくつかのアプリケーションおよびＰ２Ｐオーバーレイネットワーク（例えばＢｉｔＴｏｒｒｅｎｔ）のようなアプリケーション層ネットワークは、通信ピアの選択を最適化しようとしている。すなわち、可能な通信ピアの選択肢がアプリケーションに提示されるとき、アプリケーションは、パフォーマンスを最大化するために、１つの最適な通信ピアまたは最適な通信ピアのセットを選択しようとする。ピアを選択するための尺度は、例えばラウンドトリップ時間とすることが可能である。このアプローチの問題は２つある。（Ａ）アプリケーションは、最適値を測定しなければならず、ある一定時間後およびすべての候補ピアを調べた後にのみ、最適解に到達することができる。（Ｂ）アプリケーションにとっての最適性の概念は、事業者にとっての最適性の概念と全く対照的であることが多いため、事業者はレート制限等の手段によってこれらのアプリケーションを処分するという事態が何度が生じている。事業者は、例えば自己のネットワーク内または他の事業者への低コストリンク上のトラフィックを保持することに通常は関心があるが、これは、位置に基づく最適化機能（ネットワークトポロジー的な位置の場合のような位置）を必要とする。

上記のような最適化は自明ではない。というのは、例えばＩＰアドレスに依拠することは、事業者ネットワーク内では不十分だからである。さらに、地理的座標に依拠することは誤りを生じるおそれがある。というのは、地理的近接性は、ネットワークトポロジー等における近接性を必ずしも意味しないからである。この問題を両者（アプリケーション／ユーザおよびネットワーク事業者）にとって満足なように解決するためには、最適化問題全体に対して一緒に対処する必要がある。ＡＬＴＯ（非特許文献１参照）およびＰ４Ｐ（非特許文献２参照）は、この最適化問題を解決しようとする２つのアプローチであるが、一方の当事者が他方の当事者に対して情報を開示しなければならず、サービスのためのインフラストラクチャ（通常はサーバー）が事業者によって提供されるという欠点がある。

アプリケーションまたはアプリケーション層ネットワークが候補ピアのリストから良好なピアを選択する際に事業者の選好をある程度尊重することは特に重要である。というのは、両当事者間にはある程度の不信があり、また、ユーザプライバシーや、事業者間のビジネス関係を隠蔽されたままに保持することのようないくつかのセキュリティ上の懸念が重要な役割を果たすからである。しかし、一般的な問題の結果として、この課題を解決しようとするいくつかの取り組みが生じている。理論的には、これらの取り組みは技術的な最適化問題を解決することはできるが、信頼、セキュリティおよびプライバシーの問題を十分に解決することはできない。その主な理由は、オーバーレイネットワークにおけるアプリケーションまたはピアは、自己のピアを選択するために、ネットワーク事業者によって提供されるサービスに問合せを行う必要があるか（プライバシーの問題）、または、その同じサービスが、事業者が通常開示してもよいとするよりも多くを開示する可能性のあるトポロジー的性質を開示する必要があるからである。

また、インターネットには多数のトラッカーがインストールされている。そのすべてが、信頼できる当事者によって運営されているわけではない。例えば、「The Pirate Bay」は、著作権付き資料の再配布のために主として使用されるスウォームをインデックス付けするためのＢｉｔＴｏｒｒｅｎｔトラッカーを運営している。すなわち、いかなる最適化方法も複数のトラッカーをサポートすることができなければならず、ネットワーク事業者およびユーザの秘密性／プライバシーに対する需要を考慮しなければならない。

http://www.ietf.org/dyn/wg/charter/alto-charter.html http://www.dcia.info/documents/P4P_Overview.pdf

したがって、本発明の目的は、オーバーレイネットワークで通信ピアの選択をサポートする頭書のような方法およびシステムにおいて、最適な候補通信ピアの効率的で確実な選択を可能にすることにより、一方で事業者の、他方でユーザ／アプリケーションの関心にできるだけ対応するような改良およびさらなる展開を行うことである。

本発明によれば、上記の目的は、請求項１の構成を備えた方法によって達成される。この請求項に記載の通り、本方法は、前記要求側クライアントから前記トラッカーへ送られるメッセージを受信するように配置されたネットワークエンティティが設けられ、該ネットワークエンティティが、前記要求側クライアントから前記トラッカーへ送られる前記メッセージのいずれにも、前記要求側クライアントのトポロジカル位置情報を記録することを特徴とする。

また、上記の目的は、請求項１８の構成を備えたシステムによって達成される。この請求項に記載の通り、本システムは、前記要求側クライアントから前記トラッカーへ送られるメッセージを受信するように配置されたネットワークエンティティをさらに有し、該ネットワークエンティティが、前記要求側クライアントから前記トラッカーへ送られる前記メッセージのいずれにも、前記要求側クライアントのトポロジカル位置情報を記録するように構成された位置情報挿入モジュールを有することを特徴とする。

本発明によって認識されたこととして、上記の目的は、追加的なネットワークエンティティを、好ましくは要求側クライアントのアクセスネットワーク内の事業者装置の形で含めることによって、達成することができる。このネットワークエンティティは、トラッカーへ送られるメッセージに、要求側クライアントのトポロジカル位置情報を挿入する。その結果、本発明によれば、コンテンツルーティングや通信ピア選択について知らなくても、事業者が最適化を支援することを可能にする一般的メカニズムが提供される。すなわち、要求側クライアントは自己のネットワーク事業者に特定の情報を開示する必要はなく、その逆も同様である。

本発明による方法およびシステムは、関与するすべての当事者の同意の下で動作可能である。特に、記録を行うネットワークエンティティが、要求側クライアントの事業者に属する場合、事業者は、参加しているピアに情報を開示する必要がなく、どの情報を開示するかをポリシーに基づいて決定することができる。他方、ユーザは、事業者に情報を開示する必要がない。実際には、ユーザは、自己に関する情報を特定のトラッカーに公開することをＩＳＰに対して明示的に要求する。結果として、本発明による方法およびシステムは、ネットワークトポロジー関連情報の開示を、制御され信頼された形で行い、これを用いて、ピアツーピアファイル共有アプリケーションのようなオーバーレイネットワークのパフォーマンスおよびリソース消費を最適化することができる。本発明による方法およびシステムは、より良いスケーラビリティおよび精度（事業者の情報／粗視的なＩＰレベルの情報）を提供するとともに、関連する提案の場合のような法的影響が少ない（例えば、ＩＥＴＦ ＡＬＴＯでは、例えばピアは事業者にすべての候補を開示するよう強制される場合がある）。

また、本発明によれば、位置情報の更新は対象が限定される。というのは、更新は、位置情報を知る必要のあるサーバーに対してのみ、かつ、そのようなサーバーが位置情報を実際に知る必要があるときにのみなされるからである。より詳細には、本発明によれば、ピアの候補セットを事業者に開示せずに、事業者によって提供されるトポロジカル情報を含む（例えば、ピアがオーバーレイネットワークに参加したときに特定のファイルに対する特定のトラッカーのみに対する）限定された実行時更新を可能にする。すなわち、位置情報の不要な更新は実行されず、更新は、実際に必要なとき、すなわち、アプリケーション層ネットワークの一部になるときまたはアプリケーションを開始するときにのみなされる。

本発明のもう１つの利点として、トポロジー情報を提供する中央サーバーを必要としない分散型の解決法であるということが挙げられる。さらに、関与するすべての当事者（例えば、ユーザ、ＩＳＰ、およびトラッカー）が、実行すべき手順をサポートする必要があるが、これは各当事者ごとにモジュール的である。すなわち、ＩＳＰはコンテンツアウェアである必要はない。

なお、注意すべき重要な点であるが、本発明は、トポロジカルな位置情報に基づいているのであって、物理的な位置情報に基づいているのではない。例えば、２つのピアが同じ建物内に位置しているが、異なるインターネットサービスプロバイダ（ＩＳＰ）に接続されている場合、トポロジカルな距離は、同じＩＳＰに接続されているが異なる場所に位置している２つのピア間の距離よりも大きい可能性がある。したがって、トラッカーに知らされるべき位置情報は地理的位置（例えば国コード、都市コード）を含んでもよいが、より重要なのは、ネットワークトポロジーに関連する情報である。

すでに述べたように、必要なトポロジー情報は、単にＩＰアドレスを比較するだけでは取得できない。企業および大学キャンパスのネットワークでは、ＩＰアドレスはネットワークトポロジーをある程度反映するように割り当てられるが、これは、通常の住民ユーザのブロードバンドアクセスネットワークには当てはまらない。この場合、ＩＰアドレスは、大きいアドレスプールから一時的に割り当てられる。したがって、２つのピアが「類似の」ＩＰアドレス（すなわち、それらの間の数値的な差が小さい）を有している場合に、それらがトポロジカルに近いと結論することはできない。また、クライアントおよび位置へのＩＰアドレスのマッピングは頻繁に変化する。したがって、静的なマッピングテーブルは十分ではない。

好ましい実施形態によれば、トラッカーが要求側クライアントに返すリストに含める通信ピアのサブセットは、トポロジー的に要求側クライアントの最も近くに位置する通信ピアを含む。これにより、トラッカーは、通信ピアのサブセットをランダムに選択することによってではなく、トラッカーが通信ピアの（相対的に）トポロジカルな位置について取得した知識に基づいて動作するピア選択モジュールを使用することによって、自己の応答を作成してもよい。この情報を用いて、トラッカーは、要求側クライアントに近い通信ピアを推薦することにより、システムをより効率的にする。というのは、トポロジカルな近接性によって、パフォーマンスおよび効率に関して、ランダムより良好なコネクションが得られることが多いからである。

要求された情報を所有する通信ピアの最適なサブセットを効果的かつ確実に生成するため、トラッカーは、トラッカーにおいて利用可能なトポロジカル位置情報を利用した最適化ストラテジを適用するようにしてもよい。基本的には、多次元順序関係を用いて、どの候補通信ピアが他の候補通信ピアよりも要求側クライアントに近いかを判定してもよい。このストラテジは、普遍的、すなわち、すべての参加している通信ピアに当てはまるストラテジである可能性が非常に高い。

有利な態様として、要求側クライアントからトラッカーへ送信されるメッセージにネットワークエンティティによって含められるトポロジカル位置情報は、要求側クライアントのインターネットサービスプロバイダの識別情報、その自律システム番号（Autonomous System Number）、その主配信フレームＩＤ、そのＤＳＬＡＭ／ＭＳＡＮ（Digital Subscriber Line Access Multiplexer/Multi-Service Access Node）および／またはその回線ＩＤ（例えば、ＲＦＣ３０４６／ＢＢＦ ＴＲ−１０１で規定されているようなエージェント回線ＩＤ（Agent Circuit ID）、リモートＩＤ等）を含む。さらに、ｘＤＳＬの場合におけるクロストーク等の、トラフィックを生成する際のレイヤ１の問題を回避することに関連する可能性のあるポートおよびラインカード位置を含めてもよい。以下で説明するように、これは、メッセージに記録を行う特定のネットワークエンティティと、要求側クライアントのトポロジカル位置情報がこのエンティティに実際にどの程度開示されるか、および、利用可能な情報がメッセージにどの程度記録されるかというその機能的およびトポロジー的な特性に強く依存する。これに関して注意すべき重要な点であるが、上記で列挙した情報のいずれも、通常はユーザに開示されない。

好ましい実施形態によれば、要求側クライアントからトラッカーへ送信される少なくとも１つのメッセージは、空または無効と標識されている位置フィールドを含むように構成される。ほとんどのインターネットユーザは自己の正確なトポロジカル位置（例えば、どの交換局に接続されているか）を知らないので、要求側クライアントは一般的には、トラッカーへ送信するメッセージに有効な位置情報を含めることができないだろうと仮定される。しかし、メッセージ内に十分なスペースがあるように要求側クライアントがメッセージを生成し、後でそのスペースを有効な位置情報で上書きすることができると都合がよい。このスペース（位置フィールド）は、例えばすべてゼロにセットすることによって、「空」または「無効」と標識されるべきである。

次のステップで、ネットワークエンティティは、空または無効と標識された位置フィールドを含む要求側クライアントのメッセージを検出した後、要求側クライアントの有効なトポロジカル位置情報で位置フィールドの（不正確な）内容を上書きすることによって、そのメッセージに記録を行うようにしてもよい。なお、要求側からトラッカーまでのメッセージの全経路上に、要求側クライアントの有効なトポロジカル位置情報を記録するネットワークエンティティが存在しない場合でも、システム全体が機能不全になることはなく、ユーザおよび事業者の両方にとって最適でなくなるだけである。

ユーザは、位置フィールドを、期待されるように「無効」へと初期化するのではなく、構文上有効だが自己の真の位置（すなわち存在位置）を反映しないトポロジカル位置データを記入する可能性がある。一般的に、本発明によれば、要求側クライアントからトラッカーへ送信されるメッセージの経路上のネットワークエンティティが、位置フィールドに含まれる情報を上書きすることが期待される。しかし、この動作をサポートするこのようなネットワークエンティティが経路上に存在しない場合、信頼できない情報がトラッカーに到達することになる。したがって、好ましい実施形態によれば、例えばネットワーク事業者またはユーザによって提供されるデータどうしをトラッカーが区別するために、メッセージに記録を行う各ネットワークエンティティは、挿入する情報のデジタル署名および／または暗号化を行う。

基本的に、要求側クライアントからトラッカーへ送信されるメッセージのシグナリング経路内のノードが、メッセージに位置情報を付加するようにしてもよい。これにより、メッセージは、例えば積み重ねられた階層的位置情報によって拡充されることが可能である。挿入されるトポロジカル位置情報は、物理媒体情報を含むことも可能である。物理媒体情報は、要求側クライアントによって使用される「アクセス回線種別」に関する位置情報を含むメッセージに特に関連性がある。可能な使用例として、Ｐ２Ｐネットワークが、光アクセス回線を有する顧客を優先的に選択してコンテンツを提供する場合が挙げられる。このような選択の理由は、電気アクセス回線（ｘＤＳＬ）を有する顧客は、帯域幅を過大に使用する際に、他のアクセス回線とのクロストークという問題を生じる可能性があるからである。

別の特に好ましい実施形態によれば、ネットワークエンティティは、要求側クライアントのインターネットサービスプロバイダによって運営される。というのは、事業者は一般的に、その顧客の関連するトポロジカル位置情報について知っているからである。所定のポリシーに基づいて、要求側クライアントのインターネットサービスプロバイダは、トラッカーへ送られるメッセージに要求側クライアントのどのトポロジカル位置情報を含めるかを決定してもよい。すなわち、事業者は、このようなパラメータのうちのいずれを開示するかを制御する。事業者がアプリケーションに対して開示するものが多いほど、事業者およびその顧客の両方にとって最適化の可能性が高くなる。しかし、事業者が位置情報を開示したくない場合、オーバーレイネットワークから事業者／ＩＳＰへ、あるいは事業者／ＩＳＰからオーバーレイネットワークへの情報フローはなくなる。

有利な態様として、メッセージに記録を行うネットワークエンティティは、要求側クライアントのアクセスネットワークにおける最初のＩＰアウェアな装置である。というのは、この装置は通常、クライアントのトポロジカル情報について最も完全な知識を有するからである。特に、ネットワークエンティティは、ＭＳＡＮ（Multi-Service Access Node）、ＢＲＡＳ（Broadband Remote Access Server）、ルータまたはＬ２／Ｌ３アクセスノードであってもよい。ただし、ネットワークエンティティは、メッセージにすでに有効な位置情報が記録されているか、あるいは、メッセージが空または無効と標識された位置フィールドを依然として含んでいるかを検出するために、メッセージをさらに上流分析するようにしてもよい。後者の場合、さらに上流に位置するこのようなネットワークエンティティは、メッセージに位置情報を含めることによって、記録を補ってもよい。一般的に、この情報は、要求側クライアントまでのトポロジカルな距離が大きくなるにつれて完全性が低下する。

有利な態様として、要求側クライアントのトポロジカル位置情報が記録されたメッセージは、通常のＩＰ転送手順によってトラッカーへ送信される。すなわち、ネットワークを通じてメッセージを転送する場合に、「通常の」メッセージの場合と同じメカニズムを適用可能である。

次のステップで、トラッカーは、要求側クライアントのトポロジカル位置情報を含むメッセージを受信した後、位置情報取得モジュールによってトポロジカル位置情報を抽出し、それを所定時間の長さの間ローカルデータベースに保存するようにしてもよい。トラッカーがその情報を削除するまでの時間は、一定の長さでも、動的に更新されてもよい。例えば、参加している通信ピアの個数および／または構成における変化の頻度に応じて更新されてもよい。要求側クライアントのトポロジカル位置情報を位置フィールドに記録したネットワークエンティティがメッセージの経路上にない場合、トラッカーはその位置フィールドを単に無視してもよい。

高い信頼性パフォーマンスに関して、トラッカーが、要求側クライアントのトポロジカル位置情報を含むメッセージの受信に確認応答するようにしてもよい。また、ネットワークエンティティは、所定期間内にトラッカーから確認応答を受信しない場合、要求側クライアントのトポロジカル位置情報を再送するようにしてもよい。

さらに別の好ましい実施形態によれば、トラッカーはサービス選択モジュールを有する。サービス選択モジュールは、要求側クライアントのトポロジカル位置情報を受信し、クライアント／ユーザがどのサービスにアクセスを許可されているかを判定するように構成される。一例として、ユーザが特定の地域内で見ることを許可されるＴＶ番組のセットを判定することが挙げられる（例えば、Ｚａｔｔｏｏでは、ＩＰアドレスの静的リストを用いて国単位で実施されている）。要求側クライアントからのメッセージにトポロジカル位置情報を記録するネットワークエンティティの種類に応じて、このようなサービスアクセス判定は、従来技術のシステムの場合よりもはるかに細かい粒度（例えば、国単位ではなく都市単位で）で行うことが可能である。というのは、利用可能なトポロジカル位置情報の精度が一般にかなり高くなるからである。また、サービス選択モジュールは、位置情報に基づいてチャンネルの推薦だけをするように動作することも可能である。利益を受ける可能性のある他のアプリケーション層ネットワークとしては、例えばコンテンツ配信ネットワーク（content distribution network, ＣＤＮ）が挙げられる。ＣＤＮにおいては、現在、ＩＰアドレスに基づく情報よりも、利用可能な位置情報がはるかに細かい粒度になっている。

本発明を好ましい態様で実施するにはいくつもの可能性がある。このためには、一方で請求項１および１８に従属する諸請求項を参照しつつ、他方で図面により例示された本発明の好ましい実施形態についての以下の説明を参照されたい。図面を用いて本発明の好ましい実施形態を説明する際には、本発明の教示による好ましい実施形態一般およびその変形例について説明する。

従来技術によるピアツーピアアプリケーションに対するネットワークトポロジーを全体的に例示する模式図である。 図１のネットワークトポロジーにおける従来技術のアプリケーション事例のメッセージシーケンスチャートを例示する模式図である。 図１のネットワークトポロジーにおける本発明の実施形態によるメッセージシーケンスチャートを例示する模式図である。 本発明の実施形態で使用されるアプリケーションおよび位置データを有するＩＰパケットを例示する模式図である。 本発明の実施形態により使用されるモジュールの機能モデルを例示する模式図である。

本発明ははるかに広範囲に適用可能であるが、好ましい実施形態についての以下の説明では、ＢｉｔＴｏｒｒｅｎｔのようなアプリケーションを最適化する例を用いて、本発明による方法およびシステムを説明する。結果として、以下の説明はＢｉｔＴｏｒｒｅｎｔの用語を利用するが、いかなる意味でもこの特定のＰ２Ｐプロトコルに限定されるものではない。任意の種類のアプリケーションが本発明から利益を受けることができる。

図１は、ＢｉｔＴｏｒｒｅｎｔのようなトラッカーに基づくピアツーピアファイル共有アプリケーションの動作の基本原理を示している。例示したシステムは、ある情報を提供することによって参加する複数の通信ピア（ピア＃１〜ピア＃８）を有する。もちろん、実世界の事例では、参加するピアの個数は一般にはるかに多く、数百あるいは数千のピアを含むこともあり得る。ピア＃１〜６は、インターネットサービスプロバイダＩＳＰ＃１の顧客である一方、ピア＃７およびピア＃８は他のＩＳＰに属する。ＩＳＰ＃１のネットワークは、インターネットへのアグリゲーションネットワークを含む。アグリゲーションネットワークには、ピア＃１〜３がマルチサービスアクセスノードＭＳＡＮ＃１経由で接続され、ピア＃４〜６がＭＳＡＮ＃２経由で接続される。また、システムはいわゆるトラッカーを有する。トラッカーは、すべての参加している通信ピアおよびそれらにより所有される情報のデータベースを維持管理する。上記ですでに述べたように、人気のあるコンテンツの場合、このリストは数千ないし数十万のピアからなることもある。

従来技術のアプローチによれば、このようなトラッカーに基づくＰ２Ｐファイル共有アプリケーションの動作の基本原理は以下の通りである。
１．特定の情報（例えばファイル）を取得したいピア（以下、要求側クライアントという）が、いわゆるトラッカーへコンテンツ識別子を送信する。
２．トラッカーは、所望のコンテンツを所有するピアのＩＰアドレスを数十個含むリストにより、要求側クライアントに応答する。すなわち、応答のサイズを小さく保つため、トラッカーは、すべての既知のピアではなくサブセットを返し、これは通常、ランダムに選び出される。
３．要求側クライアントは、トラッカーから知った１つまたは複数のアドレスへのデータコネクションを確立し、所望のコンテンツへのアクセスを開始する。

同じ従来技術の動作原理を、図２に、メッセージＦ１〜Ｆ６を含むメッセージシーケンスチャートの形式で例示する。図２からわかるように、トラッカーは、（要求側クライアントから要求された情報を提供することができると仮定されているピア＃３、４、６、および７のうちから）ピア＃４および＃７をランダムに選択する。メッセージＦ２により、要求側クライアントにこのことが通知される。図２の実施形態では、要求された情報は個別のチャンクからなると仮定されている。要求側クライアントは、必ずしも、トラッカーから受信したリストに含まれている単一のピアに対してすべてのチャンクを要求する必要はない。図２では、要求側エンティティは、ピア＃４に対して、要求する情報のチャンク１、３、および５を提供するよう求め、ピア＃７に対して、情報のチャンク２、４、および６を提供するよう求める。要求を分割することにより、情報のダウンロードを大幅に加速することができる。

このようなデータコネクションにおける２つのピアのトポロジカルな位置に応じて、達成可能なパフォーマンスおよびリソース消費は異なり得る。従来のピアツーピアソフトウェアは、ピア間の測定値に基づいて仮想的なトポロジーを最適化する。すなわち、ある別のピアとの間の測定されたスループットが十分でない場合、そのコネクションを終了し、トラッカーに対して、代わりに試行可能な他のピアを要求する。しかし、このアプローチは、時間のかかる測定に依拠しており、オーバーレイトポロジーが最適に近い状態に収束するのに時間を必要とする。これは特に、ピアがオーバーレイに頻繁に出入りする場合（例えば、ユーザがピアツーピアＴＶストリーミングアプリケーションでチャンネルを切り替えている場合）には問題となり得る。

図３は、本発明の実施形態によるメッセージシーケンスチャートの模式図である。基礎となるネットワークトポロジーは図２の場合と同じである。この例では、図２に関して上記で説明したようなピアとトラッカーとの間の通常のメッセージ交換の直前に、本発明による特定の手順が実行される。

しばらくの間（または一度も）トラッカーとメッセージを交換していなかった新しいピア（図２のピア＃１）が、そのトポロジカルな位置をトラッカーに通知するアップデート（Ｆ１）を送信する。ほとんどのインターネットユーザは自己の正確なトポロジカルな位置（例えば、どの交換局に接続されているか）を知らないので、このメッセージは、この段階では、有効な位置情報を含まないと仮定される。ただし、メッセージ内には、後で有効な位置情報で上書きすることができる十分なスペースがなければならない。このスペースは、例えばすべてゼロにセットすることによって、「空」または無効と標識されるべきである。このメッセージの目的は、ユーザ（あるいはより正確にはそのＰ２Ｐソフトウェア）がＩＳＰに対して、ユーザの位置を（メッセージの宛先ＩＰアドレスによって識別される）特定のトラッカーに開示することを命令することである。

プロバイダのネットワークにおける最初のＩＰアウェアな装置（図２のＭＳＡＮ＃１）が、このメッセージを検出する。この装置は、メッセージに「記録を行う」（それによりメッセージＦ１ａを生成する）。すなわち、上記で規定されたような空スペースが、図４の例に示すように有効な位置情報（例えば、ＩＳＰ ＩＤ、ＡＳ番号、ＭＳＡＮ ＩＤ、ポートＩＤ等）で上書きされる。また、シグナリングメッセージが許容すれば、位置情報は、すでにＰ２Ｐシグナリング手順の一部である（すなわち、この特定の目的のためだけでない）パケット内に記録されることも可能である。

図４は、本発明において使用される、要求側クライアントからトラッカーへ送信される典型的メッセージの構成を例示している。メッセージは、第１のヘッダ（ＩＰヘッダおよびＬ４ヘッダ（縦線）を含む）、第２のヘッダ（アプリケーションヘッダ（横線））、位置フィールド（白、その詳細は以下で説明する）、および他のアプリケーションおよび／またはペイロードのためのフィールド（格子縞）を有する。

図４の例は、位置情報が通常のアプリケーションシグナリング内に記録される場合を含んでいる。位置を開示するだけの目的でアプリケーションへ送られる専用メッセージの場合、図示されているアプリケーションヘッダは不要である。位置情報が「通常の」シグナリングメッセージ内に記録される使用例において、パケット内の一定位置が予約されるか否かは、今後の標準化の合意次第であり、アプリケーションによって異なり得る。ネットワーク要素は、アクセス制御リストを用いて定義される基準に基づいてＩＰヘッダフィールドを書き換える際の現在の手順に類似した所定のルールに基づいて、この記録機能を実施することができる。例えば特定のフレームフォーマットに対して専用のポート番号を割り当てることは、標準化にとって望ましい目標である。というのは、これにより、ネットワークノードにおけるパケット検査機能に対する要求が緩和されるからである。

図４に示した例は、事業者、ネットワーク番号、エリア、エリア内のｘｙ座標、アクセスノード、アクセスノード上のｘｙ座標（例えばスロットおよび／またはポート）に関連する要求側クライアントのトポロジカル位置情報の挿入を含む。また、アクセス回線種別に関連するトポロジカル情報が挿入される。これは、光アクセス回線を有する顧客が電気アクセス回線（ｘＤＳＬ）のみを有する顧客よりも優先される場合に有用となり得る。位置情報のフォーマットは、例えばＴＬＶ（type length value, 種別・長さ・値）に基づくことが可能である。

図３に戻って、記録が行われたメッセージ（Ｆ１ａ）は、ＩＰ転送の通常の手順を用いて、ネットワークを通じてトラッカーへ転送される。トラッカーは、位置情報を抽出し、それを適当な時間の間ローカルデータベースに保存することができる。トラッカーは、新しいピアによって、特定の情報を所有する他のピアについて問合せを受けた場合（メッセージＦ２）、ピアをランダムに選択することによってではなく、要求側に近いピアを推薦することによって応答を作成することができる（メッセージＦ３）。これは、本明細書に記載の方法を用いて問合せ側ピア＃１がその位置をトラッカーに開示しているだけでなく、同じ方法を用いて他のピアも過去にそれを実行していることを仮定している。しかし、位置情報が伝達されなくても、システム全体が機能不全になることはなく、ユーザおよび事業者の両方にとって最適でなくなるだけである。

トラッカーからの応答に基づいて、要求側ピアは、トラッカーによって指示されたピアからコンテンツのダウンロードを開始することができる（メッセージＦ４〜Ｆ７）。これにより、最適化されていないランダムなピア選択よりも良好な結果が得られ、ネットワークにおけるリソース使用が少なくなると考えられる。

図５は、本発明の実施形態により使用されるモジュールの機能モデルを例示する模式図である。要求側（Ｐ２Ｐ）クライアントは、シグナリングメッセージを生成する位置メッセージングモジュールを有する。シグナリングメッセージは、通常は（有効な）位置／トポロジー情報を含まないが、詳細なトポロジカル位置情報が挿入される（すなわち、上流の装置によって、特に、要求側クライアントの事業者のＭＳＡＮまたはＢＲＡＳまたはアクセスノードによって記録が行われる）ために十分なサイズの位置フィールドを含むフォーマットを有する。顧客が、本明細書の記載の記録方法をサポートしないＭＳＡＮ／ＢＲＡＳ／アクセスノードに接続されている場合、アクセスネットワークにおいてさらに上流の別のノード（例えば、メッセージフローのシグナリング経路内に位置する任意の種類のＬ２および／またはＬ３アウェアなアクセスノード）が、「空スペース」が依然として空であることを検出して、顧客／要求側クライアントのあまり詳細ではない位置情報を記録してもよい。いずれの場合でも、記録を行うネットワークエンティティは、パケット内の適当な場所に位置情報を記録する位置情報挿入モジュールを備えることになる。

トラッカー／（Ｐ２Ｐ）サーバーにおいて、位置情報は、位置情報取得モジュールによって取得される。位置情報取得モジュールは、その情報を、ピア選択モジュールもしくはサービス選択モジュールまたはその両方に入力するように構成される。ピア選択モジュールは、この情報に課された尺度に基づいて、当該クライアントによる（将来の）要求に最も良くサービスすることができるピアを計算する。この情報がサービス選択モジュールに渡されると、このモジュールは、ユーザがどのサービスにアクセスを許可されるかを判定する。一例として、ユーザが特定の地域内で見ることを許可されるＴＶ番組のセットを判定することが挙げられる（例えば、Ｚａｔｔｏｏでは、ＩＰアドレスの静的リストを用いて国単位で実施されている）。本発明によれば、はるかに細かい粒度（例えば、国単位ではなく都市単位で）で判定を行うことが可能である。

アプリケーションによっては、Ｐ２Ｐノードが（トラッカーのような第三者に位置情報を開示する代わりに）自己のトポロジカルな位置を見出すことができれば有益である。これを実現するため、本発明によれば、ピアは、トラッカーに割り当てられていない特別の「予約された」ＩＰあるいはＬ２アドレスへ位置更新メッセージを送信することが可能である。ＭＳＡＮ／ＢＲＡＳ／ＡＮは、この種のメッセージを検出した場合、位置情報を挿入して発信側へ返送する。例えばＥＴＳＩ ＴＳ １０２ ６５０にまとめられている緊急サービス位置決定方法のようなアプリケーションは、この機能から利益を受けることができる。

最後に、注意すべき点であるが、ピアのトポロジカルな位置をインターネット内の他の当事者に開示するという基本的問題を技術的に解決するための多くの方法がある。しかし、解決法は、多くの法的影響も考慮しなければならない。従来の各代替案は、本発明と比べて以下のような具体的欠点を有する。
１．ユーザに対して、Ｐ２Ｐソフトウェアにおいて、自己の位置の入力を要求し、Ｐ２Ｐプロトコル内でその位置を伝達することができる。しかし、主な問題点として、多くのユーザは自己のトポロジカルな位置（例えば、どの交換局およびＤＳＬＡＭ／ＭＳＡＮに接続されているか）を知らない。
２．トポロジーは、ピア間の測定値から推測することができる。しかし、これは時間がかかり、不正確なこともある。また、測定できるのはパフォーマンス関連のパラメータだけであり、トラフィックを伝送する際にＩＳＰに生じる金銭的コストは測定できない。
３．ネットワーク事業者は、「ネットワークトポロジーマップ」（ＩＥＴＦ ＡＬＴＯ参照）を公開することができるが、これを行うことにはかなり消極的である。というのは、これはトラッカー事業者に（Ｐ２Ｐを実際に使用するユーザに関する情報だけでなく）ネットワークトポロジー全体を開示することになるからである。
４．トラッカー事業者は、候補ピアアドレスのリストをＩＳＰへ送信して分類してもらうことにより、トポロジーアウェアなピア選択をネットワーク事業者に委任することも考えられる。しかし、トラッカー事業者は、誰がＰ２Ｐスウォームに参加しているかに関する情報をＩＳＰに開示することに消極的であり、ＩＳＰはこのサービスを提供することに消極的である。というのは、トラッカー事業者およびＩＳＰに対して、それらの顧客による著作権侵害活動を規制するように、コンテンツ所有権者および立法府が強制する可能性があるからである。

上記の説明および添付図面の記載に基づいて、当業者は本発明の多くの変形例および他の実施形態に想到し得るであろう。したがって、本発明は、開示した具体的実施形態に限定されるものではなく、変形例および他の実施形態も、添付の特許請求の範囲内に含まれるものと解すべきである。本明細書では特定の用語を用いているが、それらは総称的・説明的意味でのみ用いられており、限定を目的としたものではない。

Claims (15)

1. オーバーレイネットワークで通信ピアの選択をサポートする方法において、複数の通信ピアがある情報を提供することによって前記オーバーレイネットワークに参加し、該参加している通信ピアおよび該通信ピアにより所有される情報のデータベースを維持管理する少なくとも１つのピアツーピアサーバーすなわちトラッカーが設けられ、該トラッカーは、ある通信ピアすなわち要求側クライアントから特定の情報に関する問合せを受信した後、すべての通信ピアのうち前記要求された情報を所有するサブセットを含むリストを前記要求側クライアントに提供することによって前記問合せに応答し、
   前記要求側クライアントから前記トラッカーへ送られるメッセージを受信するように配置されたネットワークエンティティが設けられ、該ネットワークエンティティが、前記要求側クライアントから前記トラッカーへ送られる前記メッセージのいずれにも、前記要求側クライアントのトポロジカル位置情報を記録することを特徴とする、オーバーレイネットワークで通信ピアの選択をサポートする方法。
2. 前記トラッカーが前記リストに含める通信ピアのサブセットが、トポロジー的に前記要求側クライアントの最も近くに位置する通信ピアを含むことを特徴とする請求項１に記載の方法。
3. 前記トラッカーは、前記参加している通信ピアのいずれが前記参加している通信ピアのうちの他の通信ピアよりも前記要求側クライアントにトポロジー的に近いかを判定するために、多次元順序関係を適用することを特徴とする請求項１または２に記載の方法。
4. 前記トポロジカル位置情報が、要求側クライアントのインターネットサービスプロバイダの識別情報、その自律システム番号、その主配信フレームＩＤ、そのＤＳＬＡＭ／ＭＳＡＮ（Digital Subscriber Line Access Multiplexer/Multi-Service Access Node）および／またはその回線ＩＤを含むことを特徴とする請求項１ないし３のいずれか１項に記載の方法。
5. 要求側クライアントから前記トラッカーへ送信される少なくとも１つのメッセージが、空または無効と標識された位置フィールドを含むように構成され、および／または、
   前記ネットワークエンティティは、空または無効と標識された位置フィールドを含む要求側クライアントのメッセージを検出した後、該要求側クライアントの有効なトポロジカル位置情報で前記位置フィールドの内容を上書きすることによって、前記メッセージに記録を行い、および／または、
   前記ネットワークエンティティが、挿入するトポロジカル位置情報のデジタル署名および／または暗号化を行う
   ことを特徴とする請求項１ないし４のいずれか１項に記載の方法。
6. 挿入されるトポロジカル位置情報が、物理媒体情報を含むことを特徴とする請求項１ないし５のいずれか１項に記載の方法。
7. 前記ネットワークエンティティが、前記要求側クライアントのインターネットサービスプロバイダによって運営され、および／または、
   前記要求側クライアントのインターネットサービスプロバイダが、所定のポリシーに基づいて、前記トラッカーへ送られるメッセージに前記要求側クライアントのどのトポロジカル位置情報を含めるかを決定する
   ことを特徴とする請求項１ないし６のいずれか１項に記載の方法。
8. 前記ネットワークエンティティが、要求側クライアントのアクセスネットワークにおける最初のＩＰアウェアな装置であり、および／または、
   さらに上流のネットワークエンティティは、メッセージが空または無効と標識された位置フィールドを含んでいるかどうかを検出するために、メッセージを分析する
   ことを特徴とする請求項１ないし７のいずれか１項に記載の方法。
9. 要求側クライアントのトポロジカル位置情報を含むメッセージが、ＩＰ転送手順によって前記トラッカーへ送信されることを特徴とする請求項１ないし８のいずれか１項に記載の方法。
10. 前記トラッカーは、要求側クライアントのトポロジカル位置情報を含むメッセージを受信した後、該トポロジカル位置情報を抽出し、それを所定の長さの時間の間ローカルデータベースに保存し、および／または、
    前記トラッカーは、前記メッセージの経路上のどのネットワークエンティティも要求側クライアントのトポロジカル位置情報を位置フィールドに記録していない場合、該要求側クライアントからのメッセージの該位置フィールドを無視し、および／または、
    前記トラッカーが、要求側クライアントのトポロジカル位置情報の受信に確認応答する
    ことを特徴とする請求項１ないし９のいずれか１項に記載の方法。
11. 前記ネットワークエンティティは、所定期間内に前記トラッカーから確認応答を受信しない場合、要求側クライアントのトポロジカル位置情報を再送することを特徴とする請求項１ないし１０のいずれか１項に記載の方法。
12. オーバーレイネットワークで通信ピアの選択をサポートし、特に、請求項１ないし１１のいずれか１項に記載の方法を実行するシステムにおいて、該システムは、ある情報を提供することによって前記オーバーレイネットワークに参加する複数の通信ピアと、該参加している通信ピアおよび該通信ピアにより所有される情報のデータベースを維持管理する少なくとも１つのピアツーピアサーバーすなわちトラッカーを有し、該トラッカーは、ある通信ピアすなわち要求側クライアントから特定の情報に関する問合せを受信した後、すべての通信ピアのうち前記要求された情報を所有するサブセットを含むリストを前記要求側クライアントに提供することによって前記問合せに応答するように構成され、
    該システムは、前記要求側クライアントから前記トラッカーへ送られるメッセージを受信するように配置されたネットワークエンティティをさらに有し、該ネットワークエンティティが、前記要求側クライアントから前記トラッカーへ送られる前記メッセージのいずれにも、前記要求側クライアントのトポロジカル位置情報を記録するように構成された位置情報挿入モジュールを有することを特徴とする、オーバーレイネットワークで通信ピアの選択をサポートするシステム。
13. 前記ネットワークエンティティが、前記要求側クライアントのインターネットサービスプロバイダによって運営されることを特徴とする請求項１２に記載のシステム。
14. 前記ネットワークエンティティが、前記要求側クライアントのアクセスネットワークにおける最初のＩＰアウェアな装置であり、および／または、
    前記ネットワークエンティティが、ＭＳＡＮ（Multi-Service Access Node）、ＢＲＡＳ（Broadband Remote Access Server）、ルータまたはＬ２／Ｌ３アクセスノードである
    ことを特徴とする請求項１２または１３に記載のシステム。
    
15. 前記トラッカーは、要求側クライアントのトポロジカル位置情報が記録されたメッセージを受信した後に該メッセージからトポロジカル位置情報を抽出するように構成された位置情報取得モジュールを有し、および／または、
    前記トラッカーは、メッセージから抽出されるトポロジカル位置情報に基づいてトポロジー的に前記要求側クライアントの最も近くに位置する通信ピアのサブセットを判定するように構成されたピア選択モジュールを有し、および／または、
    前記トラッカーは、メッセージから抽出されるトポロジカル位置情報に基づいて前記要求側クライアントのアクセスが許可されるサービスを判定するように構成されたサービス選択モジュールを有する
    ことを特徴とする請求項１ないし１４のいずれか１項に記載のシステム。
    
    

Images