JP2015165657A - 情報指向ネットワーキングのためのコンテンツ名解決 - Google Patents

Abstract

【課題】名前付きデータオブジェクト（ＮＤＯ）のＩＰアドレスを、それらの名前に基づいて解決することができる装置を提供する。【解決手段】ＣＮＲ（コンテンツ名解決）サーバは、クライアントデバイスからの、名前付きデータオブジェクトに対する配信元を求めるクエリを受信する。クエリは、少なくとも、名前付きデータオブジェクトの名前プレフィックスを含む。また、名前付きデータオブジェクトの名前プレフィックスに対応するキャッシュサーバを特定し、名前付きデータオブジェクトの名前プレフィックスと関連付けられる１つ又は複数の発信元を判定する。さらにクライアントデバイスに、キャッシュサーバのネットワークアドレスを含み、１つまたは複数の配信元を指定するコンテンツレコードを含むクエリ応答を返す。【選択図】なし

Description

本開示は、一般的にコンピュータネットワークに関する。より詳細には、本開示は、コンテンツを提供することができる１つまたは複数のサーバに対するネットワークアドレスを得るためにコンテンツ片の名前を解決することに関する。

インターネットプロトコルスイートは、伝送制御プロトコル（ＴＣＰ）、およびインターネットプロトコル（ＩＰ）のような、エンドポイントを接続するように設計されている通信プロトコルのセットを含む。このプロトコルスイートにおいて、ＩＰパケットが送信元アドレスおよび宛先アドレスに基づいて交換およびルーティングされ、これが、今日のインターネットプロトコルのスイート全体の主要な基礎的要素としての役割を果たしている。ＩＰを基礎として、ＴＣＰが、信頼性のあるエンドツーエンドの伝送を可能にし、ドメイン名システムが、ユーザフレンドリなホスト名をＩＰアドレスにマッピングするディレクトリを提供する。また、ハイパーテキスト転送プロトコル（ＨＴＴＰ）が、ホスト内の個々のディレクトリおよびコンテンツ片に名前を付ける。今日、クライアントが特定のウェブコンテンツ片を所望するとき、クライアントは、最初にＤＮＳを使用してホスト名をＩＰアドレスにマッピングし、その後、ＨＴＴＰ要求をこのＩＰアドレスに送信して、ホストからコンテンツを受信する。

しかしながら、ウェブコンテンツにアクセスするためにインターネットプロトコルスイートおよびＤＮＳサーバを使用することによって、ＨＴＴＰサーバに性能ボトルネックが生じる。これは、これらのＨＴＴＰサーバが、同じコンテンツ片に対する各ＨＴＴＰ要求に個々に応答する必要があるためである。さらに悪いことに、インターネットユーザは主にコンテンツにアクセスできることに感心があり、必ずしもホストにではない。たとえば、高精細動画配信をストリーミングすることを所望するユーザは、そのメディアストリームの主要ホストからよりも速いビットレートをもたらすことができる近接するサーバから配信を得ることを好むことになる。

この食い違いによって、今日、コンテンツ配信を最適化または改善するように設計されている、コンテンツ配信ネットワーク（ＣＤＮ）およびＨＴＴＰプロキシのようないくつかの周辺技術が生じている。ＣＤＮは、コンテンツ公開元が自身のコンテンツを世界規模でより良好に、より効率的に配信するために採用し得るサービスとして発達している。ＣＤＮは、一般的に特別な文字セット（たとえば、ａ３８８．ｇ．ａｋａｍａｉｔｅｃｈ． ｎｅｔ）をＵＲＬにおける元のホスト名に追加することによって、ＤＮＳリダイレクションを利用する。このプロセスは、ローカルＤＮＳサーバが、クライアントによって要求されているホスト名を解決しようと試行するときに、ローカルＤＮＳサーバが代わりに、ＣＤＮに属する相対的にローカルなサーバのホスト名を解決するように構築される。このアドレスがクライアントに返され、クライアントはその後、そのローカルＣＤＮサーバからコンテンツをフェッチする。

ＨＴＴＰプロキシは、同じ問題に対して、クライアント側から公開元のＨＴＴＰサーバ上のトラフィックへとアプローチし、これは、インターネット全体を通じた混雑状態を低減する一助となる。ある団体が、ＨＴＴＰプロキシであって、当該プロキシがすべての発信ＨＴＴＰ要求、およびそれらのそれぞれの応答を見ることを可能にするネットワーク位置にある、ＨＴＴＰプロキシを配備する。プロキシは応答をキャッシュし、その後、それ以降その公開元のＨＴＴＰサーバに向かって進む要求なしに、同じコンテンツを求める後続の要求に直接応答する。

しかしながら、ＨＴＴＰプロキシは、ＤＮＳサーバまたはＣＤＮのいずれによっても確認応答されないため、配備することが困難であることが多い。ローカルプロキシを利用するクライアントについて、クライアントのブラウザは、ＨＴＴＰ要求をＨＴＴＰプロキシに直接送信するように構成される必要があるか、または、ＨＴＴＰプロキシが、クライアントとサーバとの間の経路の直上にあるネットワーク位置に配置される必要がある。

加えて、近年の研究努力によって、コンテンツを囲むネットワークスタック全体を再構築するために情報指向ネットワーキング（ＩＣＮ）が生み出されている。ＩＣＮにおいて、パケットは一般的に、パケットの送信元および宛先のネットワークアドレスを含まない。その代わり、クライアントは名前付きデータオブジェクト（ＮＤＯ）を求める要求を発行し、ネットワークにわたるルータがこれらの要求を、ネットワークを通じてコンテンツのコピーを記憶している最も近いネットワークノードへと直接ルーティングし、このネットワークノードが、要求されているＮＤＯを含むパケットを返してこの要求に応答する。しかしながら、ＩＣＮは、現行のインターネットアーキテクチャからの大きな展開を表し、基本的に今日のＴＣＰ／ＩＰスタックとの互換性がない。このように互換性がないことが、任意のある程度の配備に対する重大な障害になっており、ＩＣＮ提案の迅速な採用を妨げている。

一実施形態は、名前付きデータオブジェクト（ＮＤＯ）のＩＰアドレスを、それらの名前に基づいて解決するコンテンツ名解決システムを提供する。動作中、システムは、クライアントデバイスからの、名前付きデータオブジェクトに対する配信元を求めるクエリを受信することができる。クエリは、少なくとも、名前付きデータオブジェクトの名前プレフィックスを含む。システムはその後、名前付きデータオブジェクトの名前プレフィックスに対応するキャッシュサーバを特定し、名前付きデータオブジェクトの名前プレフィックスと関連付けられる１つまたは複数の発信元を判定する。システムはその後、キャッシュサーバのネットワークアドレスを含み、元のサーバ、コンテンツ配信ネットワーク（ＣＤＮ）ノード、または、名前付きデータオブジェクトをホストする任意の他のデバイスに対応することができる１つまたは複数の配信元アドレスを指定するコンテンツレコードを含むクエリ応答をクライアントデバイスに返す。

いくつかの実施形態において、名前付きデータオブジェクトは、情報指向ネットワーク（ＩＣＮ）の任意の名前付きオブジェクトを含むことができる。ＩＣＮにおいて、各コンテンツ片は個々に名前を付けられ、各データ片は、そのデータを、同じデータの他のバージョンまたは他の配信元からのデータのような、任意の他のデータ片から区別する一意の名前に拘束される。この一意の名前によって、ネットワークデバイスが、一意の名前を示す要求またはインタレストを広めることによってデータを要求することが可能になり、データの記憶場所、ネットワーク位置、アプリケーション、および搬送手段とは無関係にデータを得ることができる。名前付きデータネットワーク（ＮＤＮ）またはコンテンツ指向ネットワーク（ＣＣＮ）は、ＩＣＮアーキテクチャの例であり、以下の用語がＮＤＮまたはＣＣＮアーキテクチャの要素を説明する。
コンテンツオブジェクト：一意の名前に拘束される、単一の名前付きデータ片。コンテンツオブジェクトは「永続的」であり、これは、コンテンツオブジェクトがコンピューティング内で、または複数の異なるコンピューティングデバイスにわたって動き回ることができるが、変化はしないことを意味する。コンテンツオブジェクトの任意の構成要素が変化する場合、変更を行ったエンティティが、更新されたコンテンツを含む新たなコンテンツオブジェクトを作成し、新たなコンテンツを新たな一意の名前に拘束する。
一意の名前：ＩＣＮにおける名前は一般的に位置独立であり、コンテンツオブジェクトを一意に識別する。データ転送デバイスは、名前または名前プレフィックスを使用して、コンテンツオブジェクトのネットワークアドレスまたは物理的位置にかかわらず、コンテンツオブジェクトを生成または記憶するネットワークノードに向けてパケットを転送することができる。いくつかの実施形態において、名前は、階層構造可変長識別子（ＨＳＶＬＩ）であってもよい。ＨＳＶＬＩは、様々な方法で構造化することができる、いくつかの階層的構成要素に分割することができる。たとえば、個々の名前構成要素ｐａｒｃ、ｈｏｍｅ、ｎｄｎ、およびｔｅｓｔ．ｔｘｔを左に行くほど上位のプレフィックスになる様式で構造化して名前「／ｐａｒｃ／ｈｏｍｅ／ｎｄｎ／ｔｅｓｔ．ｔｘｔ．」を形成することができる。したがって、名前「／ｐａｒｃ／ｈｏｍｅ／ｎｄｎ」は、「／ｐａｒｃ／ｈｏｍｅ／ｎｄｎ／ｔｅｓｔ．ｔｘｔ．」の「親」または「プレフィックス」であり得る。追加の構成要素を使用して、共同文書のような、コンテンツアイテムの複数の異なるバージョン間で区別を付けることができる。

いくつかの実施形態において、名前は、コンテンツオブジェクトのデータ（たとえば、チェックサム値）および／またはコンテンツオブジェクトの名前の要素から導出される、ハッシュ値のような非階層識別子を含み得る。名前はフラットなラベルとすることもできる。以後、「名前」は、階層名前または名前プレフィックス、フラットな名前、固定長名前、任意長名前、またはレベル（たとえば、マルチプロトコルラベルスイッチング（ＭＰＬＳ）ラベル）のような、名前データネットワークにおけるデータ片の任意の名前を指すのに使用される。
インタレスト：データ片を求める要求を示し、そのデータ片の名前（または名前プレフィックス）を含むパケット。データ消費者は、情報指向ネットワークにわたって要求またはインタレストを広めることができ、この要求またはインタレストは、ＣＣＮ／ＮＤＮルータが、当該要求またはインタレストを満たすために要求されたデータを提供することができる記憶デバイス（たとえば、キャッシュサーバ）またはデータ生成者に向けて伝搬させることができる。

いくつかの実施形態において、ＩＣＮシステムは、コンテンツ指向ネットワーキング（ＣＣＮ）アーキテクチャを含むことができる。しかしながら、本明細書に開示する方法は、他のＩＣＮアーキテクチャにも同様に適用可能である。

いくつかの実施形態において、キャッシュサーバを識別しながら、システムは、キャッシュサーバが名前付きデータオブジェクトの名前プレフィックスに割り当てられているか否かを判定する。キャッシュサーバが名前付きデータオブジェクトの名前プレフィックスに割り当てられている場合、システムは、その名前プレフィックスのキャッシュサーバを選択し、コンテンツオブジェクトの名前プレフィックスをその選択されたキャッシュサーバに拘束する。

いくつかの実施形態において、システムは、複数のキャッシュサーバから１つのキャッシュサーバを選択するための負荷分散関数を使用することによって、および／または、名前付きデータオブジェクトの名前プレフィックスから、キャッシュサーバを識別するハッシュ値を計算するためのハッシュ関数を使用することによって、キャッシュサーバを選択することができる。

いくつかの実施形態において、システムは、ピアＣＮＲサーバから、第２の名前プレフィックスと関連付けられるコンテンツレコードを求める要求を受信することができる。システムは、そのピアＣＮＲサーバのために、名前プレフィックスと関連付けられる１つまたは複数のコンテンツサーバを選択することができる。システムは、名前プレフィックスの基本コンテンツレコードを生成し、選択されたコンテンツサーバを含むように基本コンテンツレコードを更新することによって第２のコンテンツレコードを生成することによって、要求を満たすためのコンテンツレコードを生成することができる。システムは、その後、コンテンツレコードをピアＣＮＲサーバに送信することができる。

いくつかの実施形態において、システムは、名前プレフィックスと関連付けられる１つまたは複数のキャッシュサーバを選択し、名前プレフィックスの基本コンテンツレコードを生成し、選択されたコンテンツサーバを含むように基本コンテンツレコードを更新することによって、コンテンツレコードを生成することができる。

いくつかの実施形態において、コンテンツレコードは、名前付きデータオブジェクトの名前、セキュリティフィールド、コンテンツ配信プロトコル、およびプロトコル属性セットをも含むことができる。

いくつかの実施形態において、コンテンツレコードは、各ネットワークアドレスに対して、対応するコンテンツ配信プロトコルおよびプロトコル属性セットを指定する。

いくつかの実施形態において、コンテンツレコードは、ソートされたリストにおいて配信元を含む。リストは、ＣＮＲサーバと配信元との間のホップカウント、ＣＮＲサーバと配信元との間の物理的距離、ＣＮＲサーバと配信元との間のネットワーク待ち時間、配信元にとって利用可能なネットワーク帯域幅、配信元における処理遅延、および、配信元における平均負荷のうちの１つまたは複数に従ってソートすることができる。

いくつかの実施形態において、名前プレフィックスの一部と関連付けられる遠隔コンテンツ名解決サーバを判定することによって、１つまたは複数の信頼できる配信元を判定することができる。システムは、その後、その遠隔コンテンツ名解決サーバに、名前プレフィックスと関連付けられるコンテンツレコードを求める要求を送信することができる。

いくつかの実施形態において、遠隔コンテンツ名解決サーバからコンテンツレコードを受信した後、システムは、名前プレフィックスと関連するコンテンツレコードを記憶する。

一実施形態は、コンテンツレコードを処理して、ローカルキャッシュまたは名前付きデータオブジェクトの元のサーバから名前付きデータオブジェクトを求めることができるキャッシュサーバを提供する。動作中、キャッシュサーバは、名前付きデータオブジェクトのクライアントデバイスから要求を受信することができる。要求は、名前付きデータオブジェクトの名前を含むことができ、名前付きデータオブジェクトの名前プレフィックスと関連付けられる１つまたは複数の配信元を指定するコンテンツレコードを含むことができる。キャッシュサーバは、ローカルキャッシュが名前付きデータオブジェクトを記憶しているか否かを判定する。キャッシュが名前付きデータオブジェクトを記憶していない場合、キャッシュサーバは、コンテンツレコードにおいて指定されている配信元に名前付きデータオブジェクトを求める要求を送信する。その後、指定されている配信元からの名前付きデータオブジェクトの受信に応答して、キャッシュサーバは、クライアントデバイスに名前付きデータオブジェクトを返す。

いくつかの実施形態において、指定されている配信元から名前付きデータオブジェクトを受信した後、キャッシュサーバは、ローカルキャッシュ内に名前付きデータオブジェクトを記憶する。

図１は、一実施形態による名前プレフィックスに基づいて名前付きデータオブジェクトを取り出すための例示的なコンピューティング環境を示す図である。 図２は、一実施形態によるコンテンツ名解決サーバによる例示的な通信を示す図である。 図３Ａは、一実施形態による例示的なコンテンツレコードを示す図である。 図３Ｂは、一実施形態による複数のコンテンツ配信プロトコルの配信元を含む例示的なコンテンツレコードを示す図である。 図４は、一実施形態による、名前付きデータオブジェクトに対する配信元を求めるクエリを処理するための方法を示す流れ図である。 図５は、一実施形態による、名前プレフィックスに割り当てられるキャッシュサーバを選択するための方法を示す流れ図である。 図６Ａは、一実施形態による、名前プレフィックスに関するコンテンツレコードを取得するための方法を示す流れ図である。 図６Ｂは、一実施形態による、名前プレフィックスに関するコンテンツレコードを動的に生成するための方法６５０を示す流れ図である。 図７は、一実施形態による、キャッシュサーバにおいてクエリを処理するための方法を示す流れ図である。 図８は、一実施形態による名前プレフィックスに基づいた名前付きデータオブジェクトの取り出しを促進する例示的な装置を示す図である。 図９は、一実施形態による名前プレフィックスに基づいた名前付きデータオブジェクトの取り出しを促進する例示的なコンピュータシステムを示す図である。

図面において、同様の参照符号は同じ図面要素を指す。

以下の説明は、当業者が実施形態を作成および使用することを可能にするために提示され、特定の用途およびその要件の文脈において提供される。開示される実施形態に対する様々な改変が、当業者には容易に認識され、本明細書において定義される一般的な原理は、本開示の精神および範囲から逸脱することなく他の実施形態および用途に適用されることができる。したがって、本発明は示されている実施形態に限定されず、本明細書において開示されている原理と特徴とに一致する最も広い範囲に合致するものである。

本発明の実施形態は、名前付きデータオブジェクト（ＮＤＯ）のＩＰアドレスを解決する問題を、それらの名前に基づいて解決する１つまたは複数のコンテンツ名解決（ＣＮＲ）サーバのシステムを提供する。クライアントデバイスが、ＮＤＯの名前を含む要求をローカルＣＮＲサーバに送信することができ、ＣＮＲサーバは、名前プレフィックスを、そのＮＤＯを提供することができるコンテンツ生成者に対するネットワークアドレスセットにマッピングすることによって、コンテンツ名解決を実行することができる。ＣＮＲサーバは、そのコンテンツ生成者のネットワークアドレスセットを含むパケットを返すことによって、クライアントデバイスの要求に応答することができる。

したがって、ＣＮＲサーバは、情報指向ネットワーキング（ＩＣＮ）からの利点の大部分を達成し、既存のインターネットおよびウェブ技術を活用することによって、エンドホスト、アプリケーション、およびネットワーククライアントにＩＣＮインターフェースを提供する。より重要なことには、ＣＮＲサーバは、コンピュータネットワークにわたってＩＣＮ機能を配備するコストを低減することができる。たとえば、インターネットサービスプロバイダ（ＩＳＰ）は、何らかのドメイン名システム（ＤＮＳ）サーバを、コンテンツ名解決を実行するＣＮＲ機能を実装するように適合させることができる。これによって、ＩＳＰが、自身の既存のルータおよびネットワークスイッチを保持することが可能になり、ネットワーククライアントが、ドメイン名に基づいてインターネットを介してコンテンツにアクセスし続けることが可能になる。これらの適合されたＤＮＳサーバは、ドメイン名解決を使用してドメイン名を含む要求を処理することができ、コンテンツ名解決を使用してＮＤＯの名前プレフィックスを含む要求を処理することができる。本開示の残りの部分において、「ＣＮＲサーバ」という用語は、コンテンツ名解決を実行するサーバを指すのに使用され、また、ドメイン名解決およびコンテンツ名解決の両方を実行する改変されたＤＮＳサーバを指すのにも使用される。

本明細書に説明するＣＮＲシステムは、２つの別個の要求−応答ペアリングを使用してコンテンツ配信を実行する。第１の要求は、コンテンツの名前を、そのコンテンツを見付けることができるアドレスにマッピングするＣＮＲサーバに対するものであり、第２の要求（たとえば、ＨＴＴＰ）は、コンテンツ自体を取得するためのものである。これは、一般的に単一の要求−応答ペアリングを通じてコンテンツ配信を実行するコンテンツ指向ネットワーク（ＣＣＮ）または名前付きデータネットワーク（ＮＤＮ）のような、情報指向ネットワーク（ＩＣＮ）とは異なる。ＩＣＮにおいて、コンテンツ要求はそのコンテンツを提供することができるノードにルーティングされ、そのノードはコンテンツを含む応答を返す。

ＣＮＲシステムの複数の要求−応答対が、コンテンツを位置特定する作業を、コンテンツを供給する作業から分離し、これによって、コンテンツ位置に関する１つのトポロジと、コンテンツ配布に関する別のトポロジとが生成される。これら２つのトポロジの各々を、特定のトラフィック負荷に最適化することができる。最も重要なことには、これら２つのトポロジは、互いから、および、ホスト間でＩＰパケットをルーティングするコアルーティングインフラストラクチャから独立して発展し最適化されることができる。

いくつかの実施形態において、ウェブブラウザのようなクライアントアプリケーションが名前付きデータオブジェクト（たとえば、名前「／ｐａｒｃ／ｖｉｄｅｏｓ／ｓｐｅｎｃｅｒ／ｖ１．ｍｐｅｇ」を有するＮＤＯ）にアクセスすることを所望するとき、ウェブブラウザは、ローカルＣＮＲサーバに、そのコンテンツ名を求めるＣＮＲ要求を発行する。ＣＮＲサーバは、特定の名前付きコンテンツ片を表す新たなタイプのＤＮＳリソースレコードであるコンテンツレコード（ＣＲ）を介してコンテンツ名を直接サポートするようにＤＮＳを拡張し得る。今日のＤＮＳにおけるように、クライアントの要求は、その名前に関する信頼できるＣＮＲゾーンにルーティングされ、この信頼できるＣＮＲゾーンは、存在する場合は、対応するコンテンツレコードによって応答する。クライアントアプリケーションがコンテンツレコードを受信すると、アプリケーションは、提供されたアドレスセットからアドレスを選択し、指定されているプロトコルを使用して、名前付きコンテンツを求めるコンテンツ要求をこのアドレスに発行する。

クライアントがＤＮＳを通じてコンテンツレコードを解決するとき、クライアントは、コンテンツの信頼性を検証するのに必要な情報とともに、コンテンツをホストするサーバのアドレスを受信する。コンテンツレコードを解決するとき、提供されるアドレスは、今日のホスト名の場合のように、元のサーバのネットワークアドレスである必要はないことに留意されたい。そうではなく、アドレスは、公開元からのサーバを指し示すことができるか、または、アドレスは、ＣＤＮノード、代替のミラー、もしくはさらにはローカルハイパーテキスト転送プロトコル（ＨＴＴＰ）キャッシュを指し示すことができる。

コンテンツレコードは、コンテンツを供給するのに使用されているプロトコルも、任意のプロトコル特有の情報とともに指定する。したがって、ＣＮＲサーバは、ＨＴＴＰ、ファイル転送プロトコル（ＦＴＰ）、ネットワークファイルシステム（ＮＦＳ）のような、現在既知のまたは後に開発される任意のコンテンツ配信プロトコルをサポートすることができる。これらのコンテンツ配信プロトコルのうち、ＨＴＴＰが最も一般的であり、今日使用されている普及しているプロトコルであり、そのため、以降、ＣＮＲシステムの機能を説明するためにＨＴＴＰが使用される。しかしながら、ＣＮＲシステムおよびコンテンツレコードは、ＨＴＴＰまたは任意の特定のコンテンツ配信プロトコルには決して限定されない。

図１は、一実施形態による名前プレフィックスに基づいて名前付きデータオブジェクトを取り出すための例示的なコンピューティング環境１００を示す。コンピューティング環境１００は、１つまたは複数の技術（たとえば、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｗｉ−Ｆｉ、セルラ、Ｅｔｈｅｒｎｅｔ（登録商標）、光ファイバなど）を介して実装されるコンピュータネットワークのような、様々なコンピューティングデバイスを互いに対してインターフェースする任意の有線または無線ネットワークを含むことができるコンピュータネットワーク１０２を含むことができる。いくつかの実施形態において、ネットワーク１０２はインターネットを含むことができる。

また、いくつかの実施形態において、ネットワーク１０２は、各々がＤＮＳサーバの階層と同様に名前プレフィックスセットを解決することができるＣＮＲサーバの階層を含むことができる。たとえば、クライアントデバイス１０８が、コンテンツレコードがローカルには存在しない名前プレフィックスを求めるクエリをＣＮＲサーバ１０４．５に発行する場合、ＣＮＲサーバ１０４．５は、その名前プレフィックスの少なくとも一部と関連付けられる別のＣＮＲサーバに転送することによって、名前プレフィックスを解決することができる。しかしながら、ＤＮＳとは異なり、コンテンツ名解決（ＣＮＲ）プロセスは、名前または名前プレフィックスを、ホストにではなく、その名前を有する名前付きデータオブジェクトにマッピングする。

コンテンツに名前を付けることによって直接、２つの別個のメカニズムを通じたはるかに精細な粒度の負荷分散が可能になる。第１に、コンテンツレコードは、異なるコンテンツ名または名前プレフィックスを、別個のサーバに割り当てることができる。これによって、複数の異なる名前付きデータオブジェクトが、複数の異なるコンテンツサーバによって、これらのコンテンツサーバに対する負荷を分散させるための中央負荷分散サーバを必要とすることなく、容易に供給されることが可能になる。第２に、複数のコンテンツサーバから必要に応じて特定のコンテンツ片に容易にアクセスすることができ、それによって、新たなＩＰアドレスをコンテンツレコードに追加することによって負荷が分散される。

加えて、コンテンツ名解決はコンテンツ名とホスト名とを結びつけないため、ホスト名の代わりにコンテンツ名を解決することによって、異なるＵＲＬを指定するか、またはＤＮＳリダイレクションを利用する必要なしに、コンテンツが様々なホストおよびサーバにわたって移動することが可能になる。ＣＮＲサーバ１０４は、コンテンツ片がネットワーク１０２にわたってどの程度移動することができるかを計上するために適切な場合にコンテンツレコードを動的に生成または更新することができる。たとえば、ＣＮＲサーバ１０４．５は、あるコンテンツ片の信頼できる配信元としてコンテンツサーバ１１０を指定する所与の名前プレフィックスのコンテンツレコードを含むことができる。そのコンテンツがコンテンツサーバ１１２において利用可能になると、ＣＮＲサーバ１０４．５は、そのコンテンツ片のもう１つの信頼できる配信元としてコンテンツサーバ１１２も指定するようにコンテンツレコードを更新することができる。

動的コンテンツレコード生成は、ＣＮＲ要求−応答経路に沿った任意の点において行うことができる。いくつかの実施形態において、ローカルＣＮＲサーバは、名前付きデータオブジェクトに対する近傍のホストのセットを示すコンテンツレコードを含むことができ、それによって、様々なＣＮＲサーバが、同じデータオブジェクトに対して複数の異なるネットワークアドレスを指定するコンテンツレコードを含むことができる。クライアントデバイス１０８は、コンテンツサーバ１１０に対するアドレスを指定するコンテンツレコードを受信し得、ＣＮＲサーバ１０４．３に対してローカルである異なるクライアントデバイスが、コンテンツサーバ１１２に対するアドレスを指定するコンテンツレコードを受信することができる。

表１は、本発目の一実施形態による、信頼できるＣＮＲサーバによって実行される擬似コードを提示する。この擬似コードは、ＤＮＳサーバがホストレコードを生成する様態と同様に、コンテンツレコードを生成する。しかしながら、一般的なＤＮＳサーバと異なり、表１の６行目は、ＣＮＲサーバが要求しているノードに位置特定されるアドレスセットも含むようにコンテンツレコードを生成することができる方法を示す。

いくつかの実施形態において、ＣＮＲサーバは、キャッシュサーバを名前プレフィックスに割り当てることもできる。たとえば、クライアントデバイス１０８は、名前付きデータオブジェクトを求めるクエリをローカルＣＮＲサーバ１０４．５に送信することができる。ＣＮＲサーバ１０４．５がそのコンテンツを含む近傍のキャッシュについてアウェアである場合で、かつ、ローカルＣＮＲサーバ１０４．５が基本コンテンツレコードをキャッシュしている場合、ＣＮＲサーバ１０４．５は、そのキャッシュしているサーバのアドレスを有する完全なコンテンツレコードを動的に生成することができる。その上、ＣＮＲサーバ１０４．５は、さらには信頼できるＣＮＲ１０４．１に問い合わせることなくそうすることができる。表２は、１つまたは複数のキャッシュサーバを、名前付きデータオブジェクトの名前プレフィックスに関連付けることができるＣＮＲサーバの例示的な擬似コードを含む。特に、一般的なＤＮＳサーバと異なり、表２の４行目は、ＣＮＲサーバが、所与の名前プレフィックスに割り当てられる１つまたは複数のキャッシュサーバに対するアドレスセットも含むようにコンテンツレコードを生成することができる方法を示す。

表１および表２における擬似コードは、標準的なＤＮＳポリシからの展開であり、実質的に、異なる位置に存在する２つのクライアントが、同じコンテンツ名または名前プレフィックスについてＤＮＳに問い合わせて、２つの異なる応答を受信し得ることを意味する。このＣＮＲ実施態様によって、（ＣＤＮ、プロキシ、ミラーサイトなどに対する）コンテンツ位置特定およびリダイレクションが、コンテンツ名前空間をフラグメント化するか、またはキャッシュを要求することなく、直接、クライアント（たとえば、クライアントデバイス１０８）と配信元サーバ（たとえば、コンテンツサーバ１１０または１１２）との間の経路上にあることが可能になる。

いくつかの実施形態において、ＣＮＲシステムは、アプリケーション層プロトコルを改変し、インターネットプロトコルスタックの残りの部分を変更されないままにすることによって配備することができる。これによって、ＣＮＲシステムが、既存のコンピュータネットワークにわたって配備されることが可能になる。たとえば、ＣＮＲサーバ１０４は、コンテンツ名解決を実行することもできるドメイン名サーバを含むことができる。しかしながら、ドメイン名をネットワークアドレスにマッピングする一般的なドメイン名サーバとは異なり、ＣＮＲサーバ１０４は、個々のコンテンツオブジェクトを、そのコンテンツオブジェクトを提供することができる１つまたは複数のネットワークデバイスにマッピングする。

また、クライアントデバイス１０８上のウェブブラウザを、コンテンツレコード解決をサポートするように変更することもできる。ウェブブラウザは、いずれのタイプのレコードがＣＮＲクエリによって返されるべきかを指定し得、「ｃｎｒ：／／」のような新たなプロトコルプレフィックスを使用してＣＮＲクエリを発行することができる。プレフィックス「ｃｎｒ：／／」で始まるユニバーサルリソースロケータ（ＵＲＬ）は、名前全体（たとえば、「ｃｎｒ：／／」プレフィックスに続く全体の名前）を表すコンテンツレコードを求めるＣＮＲクエリを含むことができる。他方、ＣＮＲサーバ１０４は、名前のホスト名部分（たとえば、名前のパス部分を含まない）を求める一般的なＤＮＳルックアップを実行することによって、プレフィックス「ｈｔｔｐ：／／」で始まるＵＲＬを解決することができる。

加えて、ＣＮＲシステムは、既存のウェブプロトコルスイートと互換性があり、そのため、配備は漸進的でドメインごとのものとすることができる。ドメイン（ｐａｒｃ．ｃｏｍなど）は、単純にそれらの既存のコンテンツにＣＮＲコンテンツレコードを加えることによって、コンテンツ名解決をサポートすることを選択することができる。コンテンツ名解決を実行しない一般的なＤＮＳサーバは、ＤＮＳサーバが、たとえそれらがリソースレコードのタイプを認識しない場合であっても依然としてクエリおよび応答を転送しなければならないことを所与として、依然としてこれらのＣＮＲクエリおよび応答に対するサポートを提供することができる。

コンテンツサーバは、配信元サーバおよびＣＤＮキャッシュを含め、それ自体がＣＮＲシステムをサポートするように変更される必要はない。クライアントがコンテンツレコードの解決に成功すると、クライアントは、コンテンツをフェッチするのに必要なすべての情報を受信し、標準的なコンテンツ要求を、既存のコンピュータネットワークにわたってサーバに送信することができる。

図２は、一実施形態によるコンテンツ名解決サーバによる例示的な通信を示す。動作中、クライアントデバイス２０２上で作動しているアプリケーションが、ダウンロードすべき名前付きデータオブジェクトの名前プレフィックスを受信する。クライアントデバイス２０２は、ローカルキャッシュにおいてルックアップ動作を実行して、名前付きデータオブジェクトがキャッシュされているか否かを判定することができる。クライアントデバイス２０２がデータオブジェクトをキャッシュしていない場合、クライアントデバイス２０２は、コンテンツ名解決サーバ２０４に問い合わせることによって、名前付きデータオブジェクトを記憶している遠隔サーバを判定することができる。いくつかの実施形態において、ＣＮＲサーバ２０４は、ドメイン名サーバを含むことができる。たとえば、インターネットサービスプロバイダが、コンテンツ名解決（ＣＮＲ）サーバ２０４をクライアントデバイス２０２に割り当ててもよい。クライアントデバイス２０２は、コンテンツオブジェクトの名前プレフィックスを示すクエリ２１０を、ＣＮＲサーバ２０４に送信することができる。

ＣＮＲサーバ２０４は、その名前プレフィックスのコンテンツレコードを取得し、クライアントデバイス２０２が名前付きデータオブジェクトを取得するのに使用することができるキャッシュサーバ２０６を判定する。その後、ＣＮＲサーバ２０４は、クエリ応答２１２がコンテンツレコードおよびキャッシュサーバ２０６のネットワークアドレスを含むように、クライアントデバイス２０２にクエリ応答２１２を送信する。その後、クライアントデバイス２０２は、クエリ応答からキャッシュサーバ２０６のネットワークアドレスを取得し、名前付きデータオブジェクトを求める要求２１４をキャッシュサーバ２０６に送信する。この要求は、キャッシュサーバ２０６がコンテンツ名解決サーバに問い合わせる必要なしに名前付きデータオブジェクトの配信元を判定するのに使用することができるコンテンツレコードを含むことができる。

キャッシュサーバ２０６は、名前プレフィックスを使用して、ローカルキャッシュにおいてルックアップ動作を実行して、キャッシュサーバ２０６が名前付きデータオブジェクトを記憶しているか否かを判定することができる。キャッシュサーバ２０６がデータオブジェクトを記憶していない場合、キャッシュサーバ２０６は、コンテンツレコードを使用して、その名前付きデータオブジェクトを提供することができるコンテンツサーバ２０８のネットワークアドレスを取得することができ、名前付きデータオブジェクトを求める要求２１６をコンテンツサーバ２０８に送信する。名前付きデータオブジェクト２１８を受信した後、キャッシュサーバは名前付きデータオブジェクトをキャッシュすることができ、名前付きデータオブジェクト２１８をクライアントデバイス２０２に送信する。クライアントデバイス２０２または別のクライアントデバイスが後に名前付きデータオブジェクト２１８を求める要求２２０を送信した場合、キャッシュサーバ２０６が、名前付きデータオブジェクト２１８のキャッシュコピーをクライアントデバイスに返すことができる。

いくつかの実施形態において、クライアントデバイス２０２が名前付きデータオブジェクトを求めるＣＮＲクエリの解決に成功すると、クライアントデバイス２０２は、基本コンテンツレコードおよび１つまたは複数のアドレスレコードを受信する。クライアントデバイス２０２がいくつかのアドレスレコードを受信する場合、クライアントデバイス２０２は、場所、可用性、または何らかの他のそのような基準によってレコードがランク付けされていると仮定することができる。したがって、クライアントデバイス２０２は、まず第１のアドレスから名前付きデータオブジェクトを要求し、その後、もし必要になればアドレスレコードのセットを通じて続行するはずである。アドレスレコードランク付けおよび順序付けのポリシは、ホストＩＰアドレス選択の規則と同様に生成および標準化されてもよい。

ＣＮＲコンテンツレコードの強度は、レコードが広範囲のコンテンツ配信プロトコルをサポートするのに十分に拡張可能であるようなものである。これによって、ＣＮＲサーバの配備が容易になり、また、ＣＮＲサーバが将来において、将来のネットワーク層ＩＣＮ提案をサポートするのに十分に拡張可能であることが保証される。

図３Ａは、一実施形態による例示的なコンテンツレコード３００を示す。コンテンツレコード３００は、その名前およびＤＮＳツリーにおける場所によって指定される、特定の名前付きコンテンツ片を指す。ＤＮＳレコードと同様に、コンテンツレコード３００は、名前付きデータオブジェクトのコンテンツ名３０２と、コンテンツレコードのタイプ３０４と、コンテンツレコードのクラスコード３０６と、コンテンツレコードが有効なままであるカウントを示す有効期間（ＴＴＬ）フィールド３０８とを含むことができる。コンテンツレコード３００とＤＮＳレコードとの間の１つの主要な区別は、コンテンツレコード３００のコンテンツ名３０２は、このコンテンツがどこにホストされているかとは無関係に、コンテンツ片に対応することであることに留意されたい。

コンテンツレコード３００は、名前付きデータオブジェクトを見付けることができる１つまたは複数のネットワークコンピュータに対するＩＰアドレスセット３１８をも含む。アドレスは、応答内に、個々のＤＮＳ Ａ｛ＡＡＡ｝レコードのように含まれる。アドレスのないコンテンツレコードは基本コンテンツレコードと称され、一方で完全なコンテンツレコードとは、少なくとも１つのアドレスレコードを有する基本コンテンツレコードを指す。いくつかの実施形態において、コンテンツレコードは、ソートされたリストにおいて配信元を含む。配信元のリストは、たとえば、ＣＮＲサーバと配信元との間のホップカウント、ＣＮＲサーバと配信元との間の物理的距離、ＣＮＲサーバと配信元との間のネットワーク待ち時間、配信元にとって利用可能なネットワーク帯域幅、配信元における処理遅延、配信元における平均負荷に基づいて、および／または、現在既知のもしくは後に開発される任意の他の性能基準に基づいてソートすることができる。

さらに、コンテンツレコード３００は、オブジェクトセキュリティフィールド３１０、レコードセキュリティフィールド３１２も含むことができる。オブジェクトセキュリティフィールド３１０は、クライアントがコンテンツオブジェクトの来歴および信頼性を検証するのに必要な情報を含む。オブジェクトセキュリティフィールド３１０は、たとえば、コンテンツから計算されるハッシュ値（たとえば、ｍｄ５：ｄ１３１ｄｄ０５．．．）を含むことができるか、または、クライアントによってコンテンツオブジェクトとともに提供される署名を検証するのに使用される、公開元からの公開鍵を含むことができる。したがって、クライアントは、コンテンツ片が多数の異なる配信元から来る可能性があり、そのうちのいくつかはコンテンツ公開元にとって未知である場合がある場合、オブジェクトセキュリティフィールドを使用して、コンテンツの配信元にかかわらず、攻撃から保護し、データの来歴および信頼性を保証することができる。

オブジェクトセキュリティフィールド３１０は、コンテンツレコード３００がコンテンツオブジェクトの安全を確保することを可能にする。しかしながら、これが機能するには、コンテンツレコード３００も安全確保されなければならない。これは、レコードセキュリティフィールド３１２によって達成される。コンテンツレコード３００は一種のＤＮＳレコードであるため、オブジェクトセキュリティフィールド３１０は、ドメイン名システムセキュリティ拡張（ＤＮＳＳＥＣ）のような、今日のいくつかの既存のセキュリティプロトコルのいずれか１つによってコンテンツレコード３００の安全を確保することができる。

いくつかの実施形態において、コンテンツレコード３００は、名前付きデータオブジェクトを取得するのに使用するためのコンテンツ配信プロトコルを指定するプロトコルフィールド３１４も含むことができ、コンテンツ配信を成功させるために必要なプロトコル特有の値を指定するプロトコル属性フィールド３１６を含む。ＨＴＴＰが、今日使用されている最も一般的なコンテンツ配信プロトコルである。ＨＴＴＰをサポートするために、コンテンツレコードは、コンテンツ名をＤＮＳからＨＴＴＰに変換するのに使用される、ホスト名長数（ＨＬＮ）をプロトコル属性として指定することができる。これは、ＤＮＳにおける名前が１つの階層的構成要素から構成され、一方でＨＴＴＰは２つの主要な構成要素、すなわち、ホスト名およびパスを有するため、重要である。したがって、ＨＬＮは、名前の残りの部分がコンテンツパスであると仮定して、ホスト名内の構成要素の数を示すために必要とされる。クライアントがＨＬＮを使用して名前をＤＮＳからＨＴＴＰへ変換すると、クライアントは、コンテンツレコード内に含まれるアドレスセット内のサーバのうちの１つにＨＴＴＰ要求を発行することができる。

ＦＴＰは、もう１つの人気のあるコンテンツ配信プロトコルであり、より大きいファイルを転送するのに優れていると考えられている。コンテンツレコードは、ＦＴＰ転送に使用されるファイル名を指定することによって、ＦＴＰをサポートすることができる。

いくつかの実施形態において、名前付きデータオブジェクトをホストするコンテンツサーバセットは、クライアントデバイスが、様々な可能性のあるコンテンツ配信プロトコルのうちの１つによってデータオブジェクトをダウンロードすることを可能にしてもよい。これらの様々なプロトコルに対応するために、コンテンツレコードは、配信元に対するアドレスごとにコンテンツ配信プロトコルおよびプロトコル属性を指定することができる。

図３Ｂは、一実施形態による複数のコンテンツ配信プロトコルの配信元を含む例示的なコンテンツレコード３５０を示す図である。コンテンツレコード３５０は、様々なコンテンツサーバのコンテンツ配信プロトコルセット３６４と、プロトコル属性セット３６６と、アドレスセット３６８とを含むことができる。特に、コンテンツレコード３５０は、アドレス３６８．１にあるコンテンツサーバが、コンテンツ配信プロトコル３６４．１をサポートすることができ、プロトコル３６４．１を介してコンテンツ配信を成功させるために必要なプロトコル特有の値３６６．１を指定する。

ＣＮＲシステムにおいて、コンテンツ片を要求するプロセスは、ＤＮＳ名によって開始するが、ユーザまたはアプリケーションがＨＴＴＰ ＵＲＬなどによって有効なフォーマットにある名前を提供する場合には、変換が実行されてもよい。ＤＮＳ名はコンテンツ要求において使用され、これは、ＣＮＲシステムを通じて通常どおりにルーティングされ、コンテンツレコード（ＨＬＮを含む）がクライアントに返される。その後、クライアントはＤＮＳ名をＨＬＮと組み合わせて使用して、ＨＴＴＰ名を構築し、ＨＴＴＰを使用してコンテンツ片を要求するのにこの名前を使用する。

いくつかの実施形態において、コンピュータは、ホスト名の終わりおよびパスの始まりを示す最初のスラッシュにおいて名前を分割することによって、ＨＴＴＰ ＵＲＬをＤＮＳコンテンツ名に変換する。その後、コンピュータは、最初に「／」文字によって分解されるすべての名前の順序を入れ替えることによって、パスをＤＮＳに変換する。たとえば、コンピュータは、「ｈｔｔｐ：／／ｐａｒｃ．ｃｏｍ／ｖｉｄｅｏｓ／ｓｐｅｎｃｅｒ／ｖ１．ｍｐｅｇ」内の名前構成要素の順序を入れ替えて、文字列「ｖ１．ｍｐｅｇ／ｓｐｅｎｃｅｒ／ｖｉｄｅｏｓ」を生成することができる。次に、コンピュータは、各「／」文字をピリオド（「．」）に置き換え、各ピリオド（「．」）を「／」文字に置き換える。上記の例で続けると、コンピュータは文字列「ｖ１／ｍｐｅｇ．ｓｐｅｎｃｅｒ．ｖｉｄｅｏｓ」を生成する。その後、コンピュータはホスト名をこの文字列に付加して、有効で完全なＤＮＳ名「ｖ１／ｍｐｅｇ．ｓｐｅｎｃｅｒ．ｖｉｄｅｏｓ．ｐａｒｃ．ｃｏｍ」を生成する。

２つのＵＲＬ「ｈｔｔｐ：／／ｐａｒｃ．ｃｏｍ／ｖｉｄｅｏｓ／ｓｐｅｎｃｅｒ／ｖ１．ｍｐｅｇ」および「ｈｔｔｐ：／／ｖｉｄｅｏｓ．ｐａｒｃ．ｃｏｍ／ｓｐｅｎｃｅｒ／ｖ１．ｍｐｅｇ」は両方とも同じＤＮＳコンテンツ名「ｖ１／ｍｐｅｇ．ｓｐｅｎｃｅｒ．ｖｉｄｅｏｓ．ｐａｒｃ．ｃｏｍ」に変換されるため、ＵＲＬ形式ＨＴＴＰからＤＮＳへの変換は多対１変換である。これは、ＨＴＴＰ−ＤＮＳ変換には良好であるが、コンピュータはＤＮＳ−ＨＴＴＰを実行するにはより多くの情報を必要とすることを意味する。いくつかの実施形態において、コンピュータは、コンテンツ内のＨＬＮを使用して、ＤＮＳ−ＨＴＴＰ変換を実行することができる。ＨＬＮレコードは、名前をＤＮＳからＨＴＴＰに変換するときにＵＲＬのホスト名構成要素の長さを示す整数を含む。

ＤＮＳからＨＴＴＰに変換するために、コンピュータは最初に、ＤＮＳ名からホスト名（ＨＬＮによって示される）を削除する。残りの文字列がＨＴＴＰパスであり、コンピュータは、上述したパスを変換するためのプロセスを逆順に実行することによって、これを変換することができる。上記からの例で続けると、ＨＬＮ＝３のとき、ＤＮＳ名「ｖ１／ｍｐｅｇ．ｓｐｅｎｃｅｒ．ｖｉｄｅｏｓ．ｐａｒｃ．ｃｏｍ」は、「ｈｔｔｐ：／／ｖｉｄｅｏｓ．ｐａｒｃ．ｃｏｍ／ｓｐｅｎｃｅｒ／ｖ１．ｍｐｅｇ」に変換される。また、ＨＬＮ＝２のとき、ＤＮＳ名は「ｈｔｔｐ：／／ｐａｒｃ．ｃｏｍ／ｖｉｄｅｏｓ／ｓｐｅｎｃｅｒ／ｖ１．ｍｐｅｇ」に変換される。

いくつかの実施形態において、ＣＮＲは、ＤＮＳフォーマットの名前に変換することができる他のタイプの名前の使用をサポートする。多くの異なる、可能性のあるよりユーザフレンドリな命名体系が、ＤＮＳ名にマッピングすることができる限り設計およびサポートすることができる。たとえば、コンテンツ指向ネットワーク（ＣＣＮ）命名体系を、名前付きデータオブジェクトの名前に使用することができる。ＣＣＮ名は本質的に階層的であり、最も全般的なものから最も特異的なものへと順序付けされた名前構成要素のセットを含む。ルートで始まる省略されていないＣＣＮ名は、「ｃｃｎ：／／ｃｏｍ／ｐａｒｃ／ｖｉｄｅｏｓ／ｓｐｅｎｃｅｒ／ｖ１．ｍｐｅｇ」のようになり得る。名前変換について上記のものと同様の規則セットを設計することによって、コンピュータは、このＣＣＮ名をＤＮＳ名「ｖ１／ｍｐｅｇ．ｓｐｅｎｃｅｒ．ｖｉｄｅｏｓ．ｐａｒｃ．ｃｏｍ」に変換することができ、その後、ＣＮＲによるコンテンツの解決に進む。これは、階層的ＤＮＳ文字列にマッピングすることができる複数の異なる命名体系およびフォーマットをサポートするためにどのようにＣＮＲを使用することができるかを示す。

図４は、一実施形態による、名前付きデータオブジェクトに対する配信元を求めるクエリを処理するための方法４００を提示する。動作中、ローカルＣＮＲサーバは、クライアントデバイスからの、名前付きデータオブジェクトに対する配信元を求めるクエリを受信することができる（動作４０２）。ローカルＣＮＲサーバは、クエリから名前プレフィックスを判定することができ（動作４０４）、この名前プレフィックスを使用して、名前プレフィックスに割り当てられているキャッシュサーバを特定し（動作４０６）、その名前プレフィックスの１つまたは複数の信頼できる配信元を指定するコンテンツレコードを判定する（動作４０８）。その後、ローカルＣＮＲサーバは、キャッシュサーバのネットワークアドレスを含み、コンテンツレコードを含むクエリ応答を生成し（動作４１０）、クエリ応答をクライアントデバイスに返す（動作４１２）。

図５は、一実施形態による、名前プレフィックスに割り当てられるキャッシュサーバを選択するための方法５００を示す流れ図を提示する。動作中、ローカルＣＮＲサーバは、名前プレフィックスと関連付けられるキャッシュサーバを求めるルックアップを実行し（動作５０２）、キャッシュサーバが名前プレフィックスに割り当てられているか否かを判定する（動作５０４）。そうである場合、ローカルＣＮＲサーバは割り当てられているキャッシュサーバを選択して、クライアントデバイスに返す（動作５０６）。

一方、キャッシュサーバが名前プレフィックスに割り当てられていない場合、ローカルＣＮＲサーバは、名前プレフィックスに割り当てるためのキャッシュサーバを選択する（動作５０８）。たとえば、ローカルＣＮＲサーバは、所定の選択アルゴリズムを使用してキャッシュサーバプールからキャッシュサーバを選択することができる。選択アルゴリズムは、負荷分散関数、ハッシュ関数、または、現在既知のまたは後に開発される任意の他の選択アルゴリズムを含むことができる。ローカルＣＮＲサーバは、名前プレフィックスを選択されたキャッシュサーバに拘束する（動作５１０）。ローカルＣＮＲサーバは、名前プレフィックスと関連付けられる名前付きデータオブジェクトを要求するクライアントデバイスにこのキャッシュサーバを返すことができる。

図６Ａは、一実施形態による、名前プレフィックスに関するコンテンツレコードを取得するための方法６００を示す流れ図を提示する。動作中、ローカルＣＮＲサーバは、名前プレフィックスと関連付けられるコンテンツレコードを求めるルックアップ動作を実行することができ（動作６０２）、コンテンツレコードが存在するか否かを判定する（動作６０４）。そうである場合、ローカルＣＮＲサーバはコンテンツレコードを含むクエリ応答を生成することができる（動作６０６）。

一方、ローカルＣＮＲサーバが名前プレフィックスのコンテンツレコードを記憶していない場合、ローカルＣＮＲサーバは信頼できるＣＮＲサーバからコンテンツレコードを取得することができる。たとえば、ローカルＣＮＲサーバは、名前プレフィックスの少なくとも一部と関連付けられる、信頼できるＣＮＲサーバを特定することができ（動作６０８）、名前プレフィックスと関連付けられるコンテンツレコードを求める要求を、信頼できるＣＮＲサーバに送信する（動作６１０）。ローカルＣＮＲサーバが名前プレフィックスのコンテンツレコードを受信すると（動作６１２）、ローカルＣＮＲサーバはコンテンツレコードを名前プレフィックスと関連付けて記憶することができ（動作６１４）、動作６０６に進んで、コンテンツレコードを含むクエリ応答を生成する。

図６Ｂは、一実施形態による、名前プレフィックスに関するコンテンツレコードを動的に生成するための方法６５０を示す流れ図を提示する。動作中、信頼できるＣＮＲサーバは、ローカルＣＮＲサーバから、第２の名前プレフィックスと関連付けられるコンテンツレコードを求める要求を受信することができる（動作６５２）。その後、信頼できるＣＮＲサーバは、名前プレフィックスと関連付けられる１つまたは複数のコンテンツサーバを選択し、信頼できるＣＮＲサーバは、上記ローカルＣＮＲサーバのために選択を行う（動作６５４）。

いくつかの実施形態において、信頼できるＣＮＲサーバは、コンテンツサーバに関する１つまたは複数の性能基準を計算し、その性能基準値が所定閾値を上回るコンテンツサーバを選択することによって、コンテンツサーバを選択することができる。これらの性能基準は、たとえば、ＣＮＲサーバと配信元との間のホップカウント、ＣＮＲサーバと配信元との間の物理的距離、および、ＣＮＲサーバと配信元との間のネットワーク待ち時間のようなローカルＣＮＲサーバとコンテンツサーバとの間の距離に関連する基準を含むことができる。性能基準は、配信元にとって利用可能なネットワーク帯域幅、配信元における処理遅延、配信元における平均負荷、および／または現在既知のもしくは後に開発される任意の他の基準のような、コンテンツサーバに関連する他の基準も含むことができる。

その後、信頼できるＣＮＲサーバは、名前プレフィックスの基本コンテンツレコードを生成し（動作６５６）、選択されたコンテンツサーバを含むように基本コンテンツレコードを更新することによってコンテンツレコードを生成する（動作６５８）。いくつかの実施形態において、信頼できるＣＮＲサーバは、リストが１つまたは複数の性能基準に基づいてソートされるように、ソートされたリストを使用してコンテンツサーバセットをコンテンツレコードに挿入することができる。その後、信頼できるサーバは、コンテンツレコードをローカルＣＮＲサーバに送信する（動作６６０）。

図７は、一実施形態による、キャッシュサーバにおいてクエリを処理するための方法７００を示す流れ図を提示する。動作中、キャッシュサーバはクライアントデバイスから名前付きデータオブジェクトを求める要求を受信することができ（動作７０２）、要求から名前プレフィックスを取得する（動作７０４）。その後、キャッシュサーバは、キャッシュサーバが、名前が名前プレフィックスに一致する名前付きデータオブジェクトを記憶しているか否かを判定する（動作７０６）。そうである場合、キャッシュサーバは一致する名前付きデータオブジェクトをクライアントデバイスに返すことができる（動作７０８）。

一方、キャッシュサーバが一致する名前付きデータオブジェクトを記憶していない場合、キャッシュサーバは、要求から信頼できる配信元に対するネットワークアドレスを判定し（動作７１０）、名前付きデータオブジェクトを求める要求を信頼できる配信元に送信する（動作７１２）。クライアントデバイスは要求内にＣＮＲサーバからのコンテンツレコードを含むことができることを想起されたい。いくつかの実施形態において、キャッシュサーバは、要求からコンテンツレコードを取得し、コンテンツレコードを分析して、信頼できる配信元に対する１つまたは複数のネットワークアドレスを取得する。キャッシュサーバが要求された名前付きデータオブジェクトを受信すると（動作７１４）、キャッシュサーバは名前付きデータオブジェクトをキャッシュに記憶し（動作７１６）、動作７０８に進んで名前付きデータオブジェクトをクライアントデバイスに返す。

ＨＴＴＰおよびＤＮＳに伴う重大な問題は、これらのプロトコルのいずれもが、ミラー、キャッシュ、またはＣＤＮのいずれによっても複数のサーバにわたってコンテンツを複製するための生来のメカニズムを提供しないことである。これによって、アプリケーション開発者は、ＨＴＴＰおよびＤＮＳフレームワークをうまく利用してウェブサービスのためのコンテンツ複製および負荷分散システムを開発することを強いられている。本発明のＣＮＲシステムは、効率的なコンテンツ複製および配信のための生来のサポートを提供し、これは、情報指向ネットワークを実装するための基礎としての役割を果たすことができる。

ＣＮＲシステムは、コンテンツ複製および配信トポロジを、名前解決トポロジ（たとえば、ＤＮＳ）から分離する。コンテンツ複製および配信トポロジは、ＣＤＮ、ミラー、およびＨＴＴＰキャッシュを含むことができる。ミラーは、コンテンツ公開元に対する負荷を軽減する一助となるように意図されている、寿命の長いコンテンツレプリカを含むことができる。他方、キャッシュは、ネットワークの端部付近に位置し、主に、コンテンツを求めるローカルな要求を満たすことによってネットワーク帯域幅を低減するように設計されている、寿命の短いレプリカを含むことができる。

いくつかの実施形態において、ＣＮＲシステムは、コンテンツ、およびコンテンツレコードを認証および安全確保するためのセキュリティモデルを実装する。これによって、セキュアなＩＣＮを実装することが可能になり、それによって、あらゆる配信元からコンテンツが来ることが可能になる。たとえば、ＣＮＲコンテンツレコードは、オブジェクトセキュリティフィールドによってオブジェクトレベルのセキュリティを実装し、レコードセキュリティフィールドによってレコードレベルのセキュリティを提供する。したがって、個人または組織は、名前付きデータオブジェクトの有効なコンテンツレコードを作成し、このコンテンツレコードを信頼できるＣＮＲサーバに公開することによって、名前付きデータオブジェクトを公開することができる。この有効なコンテンツレコードは、名前付きデータオブジェクトの１つまたは複数の配信元を指定することができ、名前付きデータオブジェクトの安全を確保する有効なオブジェクトセキュリティフィールド、および、コンテンツレコードの安全を確保する有効なレコードセキュリティフィールドを含む。

個人または組織が信頼できるＣＮＲサーバにコンテンツレコードをアップロードすると、他者が名前付きデータオブジェクトをミラーリングすることが可能になる。たとえば、他の人々または彼らのサーバコンピュータが、信頼できるＣＮＲサーバにある既存のコンテンツレコードに追加のＩＰアドレスを挿入することができる。これらの追加のＩＰアドレスは、ＦＴＰまたはＨＴＴＰサーバなどにおいて、名前付きデータをミラーリングする１つまたは複数のサーバに対応することができる。

ＣＮＲにおいて、コンテンツ片をミラーリングすることを所望する任意のホストは、ＣＮＲシステムを通じて自身をコンテンツのミラーとして登録することによってこれを行うことができる。この登録プロセスは、基本コンテンツレコードを変更することなく、新たなサーバのアドレスレコードを追加する。これによって、コンテンツの名前が維持され、ミラーがコンテンツと関連付けられ、ＣＮＲシステムを通じて名前を解決するアプリケーションにとってコンテンツが一時的にアクセス可能となる。

セキュリティの観点から、新たなコンテンツを発行するエンティティを、既存のコンテンツをミラーリングするエンティティから区別することが重要である。新たなデータオブジェクトを公開する団体は、新たな基本コンテンツレコードを作成する必要があり、信頼できるＣＮＲサーバは、この団体がそうする権利を有していることを保証しなければならない。たとえば、Ｓｐｅｎｃｅｒのみが、プレフィックス「／ｐａｒｃ／ｖｉｄｅｏｓ／ｓｐｅｎｃｅｒ」の下で基本コンテンツレコードを公開することを許可されるべきである。

対照的に、この同じ制約が、コンテンツをミラーリングすることを所望する団体にも適用されるわけではない。多くの場合、コンテンツミラーは、直接的な必要から生じ、時としてコンテンツ公開元は、気付かないか、この間に連絡を取られ得ないか、または、その瞬間を拡大するために必要なリソースを有しないかのいずれかである。したがって、他のエンティティは、公開元の明確な許可なしに自身のアドレスを既存のコンテンツレコードに付加することが可能になり得る。クライアントデバイスは、コンテンツオブジェクトのハッシュまたはチェックサムを含むことができるオブジェクトセキュリティフィールドを使用して、コンテンツの配信元にかかわらず、コンテンツが正確であることを検証することができる。公開元のみがコンテンツハッシュフィールドを作成または編集することができるため、悪意のある、または違法なホストが、自身をミラーとして登録し、悪意のあるコンテンツを配信することに成功してしまう可能性がある。しかしながら、クライアントは、オブジェクトセキュリティフィールドを使用して、このコンテンツが違法でないことを検証することが容易に可能になる。

ＣＮＲシステムは、コンテンツ配信ネットワーク（ＣＤＮ）のような、他の複雑なコンテンツ複製方式をサポートすることができる。コンテンツ公開元は、所与の地理的領域にわたって、または世界規模でのコンテンツ配信を最適化するためにＣＤＮを採用することができる。ＣＮＲシステムは、動的レコード生成を利用することによって、ＣＤＮに対する統合サポートを提供することができる。たとえば、ローカルＣＤＮまたはＨＴＴＰキャッシュに対応するアドレスを生成するローカルＤＮＳサーバに加えて、信頼できるＤＮＳサーバ自体が、公開元のサーバとは対照的に、特定のＣＤＮサーバセットのアドレスを提供することによって、応答を位置特定することができる。

ＣＤＮおよびミラーは一般的に、コンテンツの寿命の長いレプリカを保持し、コンテンツ公開元に対する負荷を低減するように意図されている。対照的に、キャッシュされたコンテンツは寿命が長くても、または短くてもよく、主に、クライアントにコンテンツの最近フェッチされたコピーを提供することによって、ネットワークトラフィックおよび待ち時間を低減するように意図されている。ＣＮＲシステムは、２つの以前は独立していたシステム、すなわち、ローカルＤＮＳキャッシュとローカルコンテンツキャッシュとを組み合わせることによって、キャッシングを達成する。

ＣＮＲ要求は最初に、１つまたは複数のキャッシングサーバと関連付けられている可能性があるローカルＣＮＲサーバに送信される。ＣＮＲサーバが関連付けられるキャッシングサーバを有する場合、ＣＮＲサーバは、ＤＮＳを通じて名前を解決する前に、ＤＮＳキャッシュヒットについてチェックすることができる。ローカルＣＮＲサーバは名前プレフィックスのキャッシュヒットについてチェックし、それによって、キャッシュヒットは、コンテンツ自体のキャッシュされたコピーを有するローカルＨＴＴＰプロキシに対応する。この場合、ローカルＣＮＲサーバはコンテンツキャッシュのアドレスを有するコンテンツレコードを動的に生成し、返す。

ローカルＣＮＲサーバは、要求を発行しているクライアントの正確なＩＰアドレスが分かるため、この実施態様は、一般的なＣＤＮよりも良好な、クライアントの場所の理解を達成する。一般的なＣＤＮは、ローカルＤＮＳサーバのアドレスに対するコンテンツを位置特定することが可能であるに過ぎない。また、ローカルＣＮＲサーバはコンテンツキャッシュについてアウェアであるため、ＣＮＲサーバはクライアントをキャッシュ自体に直接送ることができる。これは、常に公開元のアドレスを返す一般的なＤＮＳ要求とは異なり、ＨＴＴＰプロキシはキャッシュサーバにクライアントをリダイレクトするために直接、この経路に沿って置かれなければならない。

図８は、一実施形態による名前プレフィックスに基づいた名前付きデータオブジェクトの取り出しを促進する例示的な装置８００を示す。装置８００は、有線もしくは無線通信チャネルまたは現在既知のもしくは後に開発される任意の他の通信方法を介して互いと通信することができる複数のモジュールを備えることができる。装置８００は、１つまたは複数の集積回路を使用して実現されてもよく、図８に示すものよりも少ないまたは多いモジュールを含んでもよい。さらに、装置８００は、コンピュータシステムに統合されてもよく、または、他のコンピュータシステムおよび／もしくはデバイスと通信することが可能である別個のデバイスとして実現されてもよい。特に、装置８００は、クエリ処理モジュール８０２と、キャッシュ選択モジュール８０４と、コンテンツレコードルックアップモジュール８０６と、通信モジュール８０８とを備えることができる。

いくつかの実施形態において、クエリ処理モジュール８０２は、クライアントデバイスからの、名前付きデータオブジェクトに対する配信元を求めるクエリを処理することができる。キャッシュ選択モジュール８０４は、名前付きデータオブジェクトの名前プレフィックスに対応するキャッシュサーバを特定することができる。コンテンツレコードルックアップモジュール８０６は、名前付きデータオブジェクトの名前プレフィックスと関連付けられる１つまたは複数の配信元を指定するコンテンツレコードを取得することができる。通信モジュール８０８は、クライアントデバイスからクエリを受信することができ、クライアントデバイスにコンテンツレコードを返すことができる。

図９は、一実施形態による名前プレフィックスに基づいた名前付きデータオブジェクトの取り出しを促進する例示的なコンピュータシステム９０２を示す。コンピュータシステム９０２は、プロセッサ９０４と、メモリ９０６と、記憶デバイス９０８とを含む。メモリ９０６は、管理メモリとしての役割を果たす揮発性メモリ（たとえば、ＲＡＭ）を含むことができ、１つまたは複数のメモリプールを記憶するのに使用することができる。さらに、コンピュータシステム９０２は、表示デバイス（ディスプレイ）９１０、キーボード９１２、およびポインティングデバイス９１４に結合することができる。記憶デバイス９０８は、オペレーティングシステム９１６、コンテンツ名解決（ＣＮＲ）システム９１８、およびデータ９２８を記憶することができる。

ＣＮＲシステム９１８は、コンピュータシステム９０２によって実行されると、コンピュータシステム９０２に、本開示に記載する方法および／またはプロセスを実行させることができる命令を含むことができる。特に、ＣＮＲシステム９１８は、クライアントデバイスからの、名前付きデータオブジェクトに対する配信元を求めるクエリを処理するための命令（クエリ処理モジュール９２０）を含むことができる。さらに、ＣＮＲシステム９１８は、名前付きデータオブジェクトの名前プレフィックスに対応するキャッシュサーバを特定するための命令（キャッシュ選択モジュール９２２）を含むことができ、名前付きデータオブジェクトの名前プレフィックスと関連付けられる１つまたは複数の配信元を指定するコンテンツレコードを取得するための命令（コンテンツレコードルックアップモジュール９２４）を含むことができる。ＣＮＲシステム９１８は、クライアントデバイスからクエリを受信し、クライアントデバイスにコンテンツレコードを返すための命令（通信モジュール９２６も）も含むことができる。

データ９２８は、本開示に記載する方法および／またはプロセスによって入力として必要とされるか、または、出力として生成される任意のデータを含むことができる。特に、データ９２８は、少なくとも、名前付きデータオブジェクトセットのコンテンツレコード、および、名前プレフィックスを１つまたは複数のキャッシュサーバに関連付けるマッピングテーブルを記憶することができる。

この詳細な説明に記載するデータ構造およびコードは一般的に、コンピュータシステムによって使用するためのコードおよび／またはデータを記憶することができる任意のデバイスまたは媒体であってもよい、コンピュータ可読記憶媒体に記憶される。コンピュータ可読記憶媒体は、限定ではないが、ディスクドライブ、磁気テープ、ＣＤ（コンパクトディスク）、ＤＶＤ（デジタル多用途ディスクまたはデジタルビデオディスク）、または、現在既知のもしくは後に開発されるコンピュータ可読媒体を記憶することが可能なほかの媒体のような、揮発性メモリ、不揮発性メモリ、磁気および光記憶デバイスを含む。

詳細な説明の部に記載する方法およびプロセスは、上述のようなコンピュータ可読記憶媒体に記憶することができるコードおよび／またはデータとして具現化することができる。コンピュータシステムが、コンピュータ可読記憶媒体に記憶されているコードおよび／またはデータを読出し実行すると、コンピュータシステムは、データ構造およびコードとして具現化されており、コンピュータ可読記憶媒体内に記憶されている方法およびプロセスを実行する。

さらに、上述の方法およびプロセスは、ハードウェアモジュールに含まれ得る。たとえば、ハードウェアモジュールは、限定ではないが、特定用途向け集積回路（ＡＳＩＣ）チップ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、および、現在既知のまたは後に開発される他のプラグラム可能論理デバイスを含むことができる。ハードウェアモジュールが起動されると、ハードウェアモジュールは、ハードウェアモジュール内に含まれている方法およびプロセスを実行する。

Claims (3)

1. プロセッサと、
   メモリと、
   クライアントデバイスから、名前付きデータオブジェクトを求める要求を受信するための通信メカニズムであって、前記要求は、前記名前付きデータオブジェクトの名前を含み、前記名前付きデータオブジェクトの名前プレフィックスと関連付けられる１つまたは複数の配信元を指定するコンテンツレコードを含む、通信メカニズムと、
   キャッシュサーバが前記名前付きデータオブジェクトを記憶しているか否かを判定するためのキャッシングメカニズムと
   を備える装置であって、
   前記通信メカニズムは、
   前記キャッシュサーバが前記名前付きデータオブジェクトを記憶していないという判定に応答して、前記コンテンツレコードにおいて指定されている配信元に、前記名前付きデータオブジェクトを求める要求を送信し、
   前記指定されている配信元からの前記名前付きデータオブジェクトの受信に応答して、前記クライアントデバイスに前記名前付きデータオブジェクトを返すようにさらに構成されている、装置。
2. 前記キャッシングメカニズムは、前記指定されている配信元からの前記名前付きデータオブジェクトの受信に応答して、前記名前付きデータオブジェクトを記憶するようにさらに構成されている、請求項１に記載の装置。
3. 前記コンテンツレコードは、
   前記名前付きデータオブジェクトの前記名前、
   前記名前付きデータオブジェクトの完全性を検証するためのオブジェクトセキュリティフィールド、
   前記コンテンツレコードの完全性を検証するためのコンテンツセキュリティフィールド、
   コンテンツ配信プロトコル、および
   プロトコル属性セット
   のうちの少なくとも１つまたは複数をも含む、請求項１に記載の装置。

Images