JP2008544690A - 経路情報を使用するマルチキャスト・ダウンロード - Google Patents

Abstract

【課題】従来技術の不利益を克服しつつ、より高い柔軟性及び改善された性能を与えるコンテンツ配信ネットワークを提供する。
【解決手段】エッジ・サーバからなるコンテンツ分配ネットワークを介する要求元クライアント（Ａ１、Ａ２、Ａ３）へのコンテンツのダウンロードが、コンテンツ要求の受信時に行われ、コンテンツ・サーバは、コンテンツを識別する供給源データとそのコンテンツの供給源へのネットワークを介する経路を識別する経路データとを含む要求ルーティング・メッセージによって応答する。要求ルーティング・メッセージ内に経路情報を有することにより、要求元クライアントが特定のエッジ・サーバに対して要求を行うことが可能になり、この特定のエッジ・サーバは、そのダウンロード要求を登録し、適当な位置からコンテンツにアクセス可能となり、それにより、コンテンツ・サーバと経路上の複数のエッジ・サーバとの間の頻繁な通信を未然に防ぐ。
【選択図】図２

Description

本発明は、コンテンツ・ファイルを効率的に配信する方法及びシステムに関する。

オーディオ、ビデオ、映画、及びそれらの類似物を含むファイル等のマルチメディア・ディジタル情報ファイルは、一般に、インターネットを介してダウンロードされる他のタイプのほとんどのファイルと比較して、はるかに大きいサイズを有する。要求されたマルチメディア・ファイルの配信が、ネットワークの輻輳、過剰なトラフィック、ネットワーク優先順位の存在、及び容量の制限に起因して、クライアント・コンピュータからの要求時にたやすく行われない場合もまれではない。

コンテンツを配信する以前の技術は、ネットワーク内の戦略的な地理的位置に配置されたエッジ・サーバを含むコンテンツ配信ネットワーク（ｃｏｎｔｅｎｔ ｄｅｌｉｖｅｒｙ ｎｅｔｗｏｒｋ、ＣＤＮ）を利用してきた。コンテンツ配信ネットワークは、そのようなエッジ・サーバ内でコンテンツをキャッシングすることができるが、ここで、エッジ・サーバという名前は、ネットワークのエッジ付近のその地理的位置に由来する。エッジ・サーバは、ネットワークが輻輳していたり停止していたりしてもクライアント・コンピュータにコンテンツを提供する。

非特許文献１及び２に、エッジ・サーバを使用するコンテンツ配信の異なる技術が記載されている。また、２００２年１１月７日の特許文献１、２００３年４月３日の特許文献２、２００３年１月２日の特許文献３、及びＬｅｉｇｈｔｏｎ他の特許文献４は、すべて参照によって組み込まれているものだが、コンテンツ配信ネットワークを開示している。これらの文書には、移動ツール（ｍｉｇｒａｔｏｒｙ ｔｏｏｌ）及び書き直しツールを使用してコンテンツ配信ネットワークから配信するためにコンテンツにタグを付ける方法も記載されており、この書き直しツールは、要求されたコンテンツをホスティングする可能性が最も高いエッジ・サーバを指すようにＵＲＬを書き直す。

ダウンロード・サービス・モデルにおいては、例えば、クライアントによるコンテンツの要求は、コンテンツに対する直接的な必要性を必ずしも反映したものではない。従って、あるコンテンツが、あるエッジ・サーバにおいて現在は使用可能ではない場合であっても、コンテンツ配信ネットワークが将来的にそのコンテンツをそのエッジ・サーバに配信可能である限り、クライアントは、そのコンテンツ要求を満たすことができる。コンテンツ配信ネットワークは、そのコンテンツ要求をあるエッジ・サーバにリダイレクトすることによってその要求を満足させ、このエッジ・サーバは、そのクライアントへのダウンロードが望まれる時にそのコンテンツを含むことになる。

現在のコンテンツ配信ネットワークは、通常、ネットワーク・リソース及びキャッシュ容量に基づいてコンテンツを配信するように動作する。コンテンツ配信ネットワークは、通常、クライアントからのコンテンツ要求に応答して、要求されたコンテンツのグローバル・アドレスとして働くユニフォーム・リソース・ロケータ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ、ＵＲＬ）を要求元クライアントに付与する。要求元クライアントに付与されるＵＲＬは、通常、そのコンテンツを有するか、又はコンテンツ・サーバに直接的又は間接的にリンクされた上流にある別のエッジ・サーバへのリンクを享受するか、のいずれかであるエッジ・サーバであって、コンテンツ配信ネットワーク内において最も近いエッジ・サーバに、そのクライアントをリダイレクトする。ブロードキャスト／マルチキャスト・コンテンツに対しては、エッジ・サーバは、コンテンツがストリーミングされている時に、コンテンツのうちの短い期間分をキャッシングすることができる。エッジ・サーバがコンテンツ・サーバにリンクする経路は、一般に、しばしばマルチキャスティング・ツリー（ｍｕｌｔｉｃａｓｔｉｎｇ ｔｒｅｅ）と称するツリー状構造の形をとり、このマルチキャスティング・ツリーにおいては、各エッジ・サーバは、別のエッジ・サーバ又はコンテンツ・サーバ自体の形態であるノードまでの「枝」によってリンクされた「葉」として現れる。

本発明者等の以前の特許出願である特許文献５、すなわち、「ＣＡＣＨＥ ＳＥＲＶＥＲ ＮＥＴＷＯＲＫ ＡＮＤ ＭＥＴＨＯＤ ＯＦ ＳＣＨＥＤＵＬＩＮＧ ＴＨＥ ＤＩＳＴＲＩＢＵＴＩＯＮ ＯＦ ＣＯＮＴＥＮＴ ＦＩＬＥＳ ＷＩＴＨＩＮ ＴＨＥ ＳＡＭＥ」（ＰＣＴ ＵＳ０４／０７６５２、２００４年３月１２日出願）は、遅延したダウンロード・サービスに対してマルチキャスティング・ツリーをどのように確立できるかに取り組んだものである。ネットワークの構成によっては、地理的近接の故に要求元クライアントの要求を満足するように指定されたエッジ・サーバが、コンテンツ・サーバへの直接的な接続を有しない可能性がある。その結果、マルチキャスティング・ツリーに特定のエッジ・サーバを追加することによって、コンテンツをダウンロードするための接続性を供するために、１つ又は複数の追加エッジ・サーバの追加が必要となる。このような状況下では、チェーン内のそのようなエッジ・サーバの各々が、すぐ上流のエッジ・サーバに関する情報を得るために、コンテンツ・サーバとの通信を必要とするはずである。その上、マルチキャスティング・ツリーは、一度作成されたならば、負荷平衡化に適合するために動的な変更を受けることが通常はできない。さらに、今日のコンテンツ配信ネットワークによって使用されるマルチキャスティング・ツリーの静的な性質として、ノードの迂回又は自動的な障害の回復ができない。

米国特許出願公開第２００２／００１６８８２号明細書 米国特許出願公開第２００３／００６５７６２号明細書 米国特許出願公開第２００３／０００２４８４号明細書 米国特許第第６１０８７０３号明細書 国際公開第２００５／０９９２２３号パンフレット 「Ｉｎｔｅｒｎｅｔ Ｂｏｔｔｌｅｎｅｃｋｓ：ｔｈｅ Ｃａｓｅ ｆｏｒ Ｅｄｇｅ Ｄｅｌｉｖｅｒｙ Ｓｅｒｖｉｃｅｓ」、白書、Ａｋａｍａｉ Ｎｅｔｗｏｒｋｓ社 Ｂａｒｂｉｒ他、「Ｋｎｏｗｎ ＣＮ Ｒｅｑｕｅｓｔ−Ｒｏｕｔｉｎｇ Ｍｅｃｈａｎｉｓｍｓ」、Ｎｅｔｗｏｒｋ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ、２００３年４月３日

従って、上述した不利益を克服しながら、より高い柔軟性及び改善された性能を与えるコンテンツ配信ネットワークが必要とされている。

本発明の原理の好ましい実施形態によれば、端的に言って、要求元クライアントにコンテンツを配信する方法が提供される。この方法は、あるコンテンツの供給源を識別する供給源データと、そのような供給源への経路を識別する経路データとを含むコンテンツ情報を、コンテンツ要求元クライアントに返すことによって開始される。要求元クライアントから受け取ったクライアント供給源情報の経路データが解析されて、要求されたコンテンツがそれを介して配信される少なくとも１つのサーバが識別される。その後、識別されたサーバを介する、要求されたコンテンツのダウンロードが行われる。この経路情報を有することによって、要求元クライアントが特定のエッジ・サーバに要求を行うことが可能になり、この特定のエッジ・サーバは、そのダウンロード要求を登録して、適当な上流の位置からコンテンツにアクセスすることができ、これにより、ダウンロードの要求を上流のサーバに直接に転送する必要がなくなるのである。

以後より詳細に説明される如く、本発明は、要求元クライアントが、通常、そのクライアントの要求を満足するサーバ（エッジ・サーバ又はキャッシュ・サーバ等）からコンテンツを含むコンテンツ・サーバへの経路を記述する経路情報を含んだユニフォーム・リソース・ロケータ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ、ＵＲＬ）の形でコンテンツ情報を受け取るといったコンテンツ・ダウンロード技術を提供する。そのような経路情報は、（１）以下、マルチキャスティング・ツリーと称する配信ルートに追加サーバ（ノード）を追加する能力、（２）サーバが動作不能になった場合にマルチキャスティング・ツリーをたやすく維持する能力、及び（３）サーバの間のリンケージを動的に更新する能力を含む、複数の利益を提供する。

本原理のコンテンツ・ダウンロード方法をよりよく理解するために、従来技術によるコンテンツ・ダウンロードの説明が役立つことがわかるであろう。この点、従来技術によるコンテンツ・ダウンロードに関して構成されたマルチキャスティング・ツリーを示す図１を参照されたい。この従来技術において、コンテンツ・サーバが、クライアントからコンテンツ要求を受信し、コンテンツ配信ネットワークのトポロジ及び状況に基づいて、要求されたコンテンツのマルチキャスティング・ツリーを作成するとする。この仮定の下において、コンテンツの最初の供給源、クライアントのユーザ・インターフェース、及び遅延ダウンロード・スケジューラのすべてが、コンテンツ・サーバに常駐している。実際には、これらのすべてを異なる実体とすることができるが、提示のためにこの仮定を用いることによって、問題の性質を変えずに簡易さが維持される。

議論のためとして、コンテンツ配信ネットワーク内に、以前のコンテンツ配信要求が存在せず、従って、コンテンツ・サーバＣＳ上のコンテンツＣ１に対してマルチキャスティング・ツリーが存在しないと仮定する。ここで、クライアントＡ１、Ａ３、及びＡ２が、それぞれ午後７時、午後８時、及び午後５時に、コンテンツＣ１の配信を求める要求を行うと仮定する。クライアントＡ１による第１の要求に対して、コンテンツ・サーバは、マルチキャスティング・ツリー（すなわち、配信ルート）を確立するが、このマルチキャスティング・ツリーには、エッジ・サーバＥ１を要求元クライアントＡ１にリンクする経路が含まれる。この経路は、次の関係によって表される、マルチキャスティング・ツリー内の第１の枝になる。
ＣＳ→Ｅ１→Ａ１

このリダイレクトされた要求をコンテンツ・サーバから受信する際、クライアントＡ１は、エッジ・サーバＥ１に要求を送信し、エッジ・サーバＥ１は、その要求キューを検査し、同一のコンテンツＣ１に対する要求がまだ存在しない場合には、その新しい要求をキューに追加する。午後８時の配信に関する同一コンテンツを求める要求がクライアントＡ３から到着する時点において、コンテンツ・サーバは、クライアントＡ１によって要求されたコンテンツのためのマルチキャスティング・ツリーを既に作成している。クライアントＡ３からの新しい要求を満足させるために、コンテンツ・サーバは、クライアントＡ３に最も近いエッジ・サーバ、例えばエッジ・サーバＥ３を、そのマルチキャスティング・ツリーにノードとして追加する。なお、ここでの議論においては、コンテンツ配信ネットワークの構造内において、エッジ・サーバＥ３はエッジ・サーバＥ２への接続だけを所有するものと仮定する。そのような情況下においては、コンテンツ・サーバはエッジ・サーバＥ３とＥ２との両方をマルチキャスティング・ツリーに追加することが必要となる。クライアントＡ３によって行われた要求の結果として生じた経路は、次のようになる。
ＣＳ→Ｅ１→Ｅ２→Ｅ３→Ａ３

要求ルーティング・メッセージが、Ａ３に送り返されるが、それは、Ｅ３が、要求されたコンテンツを受信するエッジ・サーバとして要求を満足することを示している。Ａ３は、要求ルーティング・メッセージを受信した際、Ｅ３に要求を送信する。Ｅ３は、その要求キューを検査し、コンテンツＣ１を求める要求をその要求キューに追加する。Ｅ３は、コンテンツＣ１を求める以前の要求を有していないので、そのコンテンツを求める要求を上流サーバに転送する必要がある。Ｅ３は、ポーリングによって又はコンテンツ・サーバからプッシュされることによって、その上流エッジ・サーバがＥ２であることを確立する。Ｅ２は、コンテンツＣ１を求める要求をＥ３から受信する。次いで、Ｅ２は、Ｅ３と同一の処理を繰り返し、その結果、コンテンツＣ１を求める要求が、Ｅ１に転送される。Ｅ１は、既にコンテンツＣ１を求める要求を有しているので、マルチキャスティング・ツリーに新たな経路を追加する手順は、Ａ３によって生成された要求によって停止する。

同様に、クライアントＡ２が、午後５時にこのコンテンツの配信を求める要求を行うと、コンテンツ配信ネットワークは、この要求元クライアントに最も近いエッジ・サーバ、例えばＥ２をマルチキャスティング・ツリーに追加する。エッジ・サーバＥ２は、以前に作成されたマルチキャスティング・ツリー内に既に存在するので、コンテンツ配信ネットワークがさらなるノードをそのツリーに追加する必要はない。しかしながら、このコンテンツの配信要求は、クライアントＡ１によって行われたコンテンツの要求に関する午後８時の配信時刻より早い、午後５時という配信時刻を有するので、Ｅ２は、この新しい配信時刻を有する要求をＥ１に送信する必要がある。Ｅ１は、その要求キューを検査し、午後５時のより早い配信時刻を有する新しい要求を追加する。クライアントＡ２によって要求されたコンテンツのためのマルチキャスト・ツリー内の経路は、次のようになる。
ＣＳ→Ｅ１→Ｅ２→Ａ２

所与のコンテンツについて、あるエッジ・サーバが別のエッジ・サーバのより近くにあるかどうかの判定は、リンク・コストとキャッシング・コストとの両方に依存する。最適のマルチキャスティング・ツリーは、リンク・コスト及びキャッシング・コストを最小にする。リンク・コストは、サーバ間の地理的距離に依存する。キャッシング・コストは、要求されたコンテンツを求めるすべての要求の間の最大のサービス時間差に依存する。言い換えると、コンテンツが所与のサーバでより長くキャッシングされるほど、そのコンテンツのキャッシング・コストがより高くなる。

この手法を使用することにより、各コンテンツ要求は、コンテンツ配信のためのリダイレクトされたローカル供給源として１つのエッジ・サーバを返す。この手法によれば、簡易さが供されるが、複数の不利益が生じる。上述したように、マルチキャスティング・ツリーは、要求元クライアントにコンテンツを効率的に配信するために、１つ又は複数の中間エッジ・サーバの追加を必要とする場合がある。そのような状況下で、各エッジ・サーバは、そのエッジ・サーバの次にある上流のエッジ・サーバに関する情報を得るために、コンテンツ・サーバと個別に通信する必要がある。そのような通信は、コンテンツ配信ネットワークの流れを妨げ、トラフィック遅延を引き起こす可能性がある。

以上説明した従来技術の手法によれば、マルチキャスティング・ツリーが、一度構成されたならば、ネットワーク・トラフィックの変化するパターンに適合するように動的な変更を受けることができず、従って負荷平衡化をもたらすことができないという不利益を招く。さらに、マルチキャスティング・ツリー内のノードが故障した場合（すなわち、エッジ・サーバが故障した場合）、ほとんどのコンテンツ配信ネットワークにおいて、サーバを迂回し又はそのような事象から自動的に回復する能力が欠けている。今日のコンテンツ配信ネットワークにおいては、通常、サーバの故障を報告又は発見し、さらにマルチキャスティング・ツリーを完全なままに維持するために、追加のプロトコルが必要とされる。

本発明の原理によるコンテンツの配信技術は、コンテンツの要求を行ったクライアントに対して、そのクライアントに最も近いエッジ・サーバからコンテンツ・サーバへのコンテンツ配信を介する経路を示す経路情報を返すことによって、従来技術の上述した不利益を克服するものである。従って、要求元クライアントが経路情報を得ると、そのクライアントは、最も近いエッジ・サーバに対して要求を行うことができ、その最も近いエッジ・サーバは、経路情報を解析して、その上流のサーバ（上流のエッジ・サーバ又はコンテンツ・サーバのいずれか）を識別する。上流のエッジ・サーバは各々、要求を解析して次の上流のサーバを識別し、以下同様となる。

本発明の原理によるコンテンツの配信技術を最もよく理解するために、議論のためとして、要求元クライアントのそれぞれが、コンテンツ配信ネットワーク内に以下に示す別個の経路を有するものと仮定する。
要求元クライアントＡ３は、次の経路を有する。
ＣＳ→Ｅ１→Ｅ２→Ｅ３→Ａ３
要求元クライアントＡ２は、次の経路を有する。
ＣＳ→Ｅ１→Ｅ２→Ａ２
要求元クライアントＡ１は、次の経路を有する。
ＣＳ→Ｅ１→Ａ１

要求元クライアントに経路情報を返すことによって、マルチキャスティング・ツリーの作成がどのように可能となるかを了解するために、各エッジ・サーバが、以後ＳＤＳと称する計画的ダウンロード・サービス（ｓｃｈｅｄｕｌｅｄ ｄｏｗｎｌｏａｄｉｎｇ ｓｅｒｖｉｃｅ）のためのプログラムを有することを前提とした、以下の例を検討されたい。コンテンツの要求に応答して、コンテンツ・サーバは、要求元クライアントに対して、コンテンツの供給源情報を含む要求ルーティング・メッセージ、例えばＵＲＬを返す。従って、この例では、クライアントＡ１に返されるコンテンツの供給源情報は、次のフォーマット、すなわちｈｔｔｐ：／／Ｅ１／ＳＤＳ＆ｐａｔｈ＝ＣＳ／Ｃ１を有するＵＲＬの形をとる。ＵＲＬを使用することにより、経路情報を提供する１つの技術が構成されるが、経路情報を埋め込むための、さらにはエッジ・サーバを介する計画的ダウンロードを実行するための他の機構が存在する可能性もある。

クライアントＡ２によるコンテンツの要求に応答して、経路を指定する、返される要求ルーティングＵＲＬは、次のフォーマット、すなわちｈｔｔｐ：／／Ｅ２／ＳＤＳ＆ｐａｔｈ＝Ｅ１＆ｐａｔｈ＝ＣＳ／Ｃ１を有する。このＵＲＬは、エッジ・サーバＥ２を指定する、追加された経路情報を有することに留意されたい。クライアントＡ３は、同一のコンテンツを求める要求を行う際、このマルチキャスティング・ツリーに参加し、次のフォーマット、すなわちｈｔｔｐ：／／Ｅ３／ＳＤＳ＆ｐａｔｈ＝Ｅ２＆ｐａｔｈ＝Ｅ１＆ｐａｔｈ＝ＣＳ／Ｃ１を有しており、経路を含んだ、返されるＵＲＬを受信する。

全経路情報を供給するにあたって与えられる利益は、クライアントＡ３が、リダイレクトされた経路を含むＵＲＬ、すなわちｈｔｔｐ：／／Ｅ３／ＳＤＳ＆ｐａｔｈ＝Ｅ２＆ｐａｔｈ＝Ｅ１＆ｐａｔｈ＝ＣＳ／Ｃ１を得る時に、最も明白になる。クライアントＡ３は、この経路を含むＵＲＬを使用して、要求されたコンテンツをエッジ・サーバＥ３から探す。この経路を含むＵＲＬを受信した時、エッジ・サーバＥ３は、その計画的ダウンロード・サービス・プログラム（ＳＤＳ）を使用して、最初に、経路を含むＵＲＬを解析する。その後、エッジ・サーバＥ３は、そのコンテンツを求める要求を登録し、次いで、ダウンロード要求としてその要求をキューイングする。最後に、エッジ・サーバＥ３は、経路を含むＵＲＬ、すなわちｈｔｔｐ：／／Ｅ２／ＳＤＳ＆ｐａｔｈ＝Ｅ１＆ｐａｔｈ＝ＣＳ／Ｃ１を使用して、上流のエッジ・サーバＥ２にアクセスする。

同様にして、エッジ・サーバＥ２のＳＤＳプログラムは、要求を処理し、必要な場合には、最初のサーバ又は指定されたサービス時刻の配信に使用可能な要求されたコンテンツを既に有する別のサーバに要求が達するまで、要求をエッジ・サーバＥ１に転送する。言い換えると、エッジ・サーバにおいてクライアントから経路を含むＵＲＬを受信することによって、ダウンロードの要求を上流のノードに転送する必要がなくなるのである。

各エッジ・サーバが本発明の原理によるダウンロードをサポートするためには、エッジ・サーバ内のＳＤＳプログラムが、（１）リダイレクトされたコンテンツ情報の要求における経路データを理解するための要求解析、（２）すべての着信した要求を登録するための要求キューイング、（３）ダウンロードの要求をキューイングするための要求集約、及び（４）ダウンロードの要求を上流のサーバに送信するための要求転送、を実行する必要がある。

本発明の原理に従って要求ルーティングと共に経路情報を提供することによって、複数の利益が達成される。第１に、経路情報を提供することによって、１つのコンテンツ要求においてマルチキャスト・ツリーに複数のサーバ（ノード）を追加することが可能になる。フラットであれ階層的であれ、コンテンツ配信ネットワークの構造に応じて、マルチキャスト・ツリーへのエッジ・サーバの追加を、エッジ・サーバ又はプロキシ・サーバを備え得る他のサーバを介して行うことができる。例えば、図２に示されたマルチキャスティング・ツリーを検討されたい。図２においては、クライアントＡ４が、クライアントＡ１、Ａ２、及びＡ３と同一のコンテンツを求める要求を行うが、エッジ・サーバＥ５が、そのクライアントの最も近くに存在する。クライアントＡ４の要求を満足させるエッジ・サーバＥ５は、エッジ・サーバＥ４に対する階層的な接続を有している。そのような状況下では、エッジ・サーバＥ４とＥ５との両方が、マルチキャスティング・ツリーに追加されることが必要となる。そのような追加は、Ｅ５が、クライアントＡ４によって返される経路を含むＵＲＬから、経路全体に関する経路情報を受け取るので、たやすく可能となる。その経路を含むＵＲＬを解析した時、エッジ・サーバＥ５は、エッジ・サーバＥ４への接続を開始して、要求されたコンテンツを探す。それに応答して、エッジ・サーバＥ４は、エッジ・サーバＥ３に接続し、以下同様となる。

本発明の原理に従って要求ルーティングと共に経路情報を提供することによって、マルチキャスティング・ツリーの維持も助けられる。通常のコンテンツ配信ネットワークにおいては、上流のエッジ・サーバのいずれか１つに、コンテンツの要求をサービスする能力が欠けている可能性が存在する。上流のエッジ・サーバから応答を受信できない場合、要求元エッジ・サーバは、その故障したノードを迂回し、ＵＲＬを解析して、より上流のエッジ・サーバに対して要求を行うことができる。上流のエッジ・サーバが、そうではなく「健全」に見える場合であっても、そのようなサーバが、そのサーバとコンテンツ・サーバとの間の情報の矛盾に起因してコンテンツ要求情報を失う可能性がある。エッジ・サーバとコンテンツ・サーバとの間におけるコンテンツの一貫性のためのマルチキャスティング・ツリーに関する情報を維持するためには、通常１つの又は追加のプロトコルの存在を必要とするはずであるが、これには費用がかさみ得ることが分かる。要求ルーティングのコンテンツ情報内に経路情報を有することによって、マルチキャスティング・ツリーの維持を、分散した形で自動的に行うことができる。具体的には、故障したノードの迂回又は故障したノードの回復を、コンテンツ・サーバに連絡する必要なしに行うことができる。

さらに、本発明の原理に従って要求ルーティングと共に経路情報を提供することによって、動的な更新が可能になる。コンテンツ要求ごとにリダイレクトされるＵＲＬ内に全経路情報を提供することによって、中間のエッジ・サーバが、そのコンテンツについて、その中間エッジ・サーバの上流サーバを動的に更新することができる。例えば、図３に示されているように、Ｅ３→Ｅ２→Ｅ１として配置されたエッジ・サーバ（ノード）Ｅ１、Ｅ２、及びＥ３を含む既存のマルチキャスト・ツリーを仮定する。図示の構成においては、エッジ・サーバＥ３は、要求されたコンテンツに対する上流のエッジ・サーバとしてエッジ・サーバＥ２を有している。同一コンテンツを求めているが異なるサービス時刻を有する新しい要求に対して、図４に示されたＥ４→Ｅ３→Ｅ１→ＣＳによって示されるような、新しい効率的な経路が存在する。この新たなとり得る経路に基づいて、エッジ・サーバＥ３は、その上流のエッジ・サーバをＥ１のコンテンツについて動的に更新するが、これは、返されるコンテンツ情報要求内に経路情報が存在しなければ可能にはならなかったはずである。

以上は、クライアントの要求を満足させるエッジ・サーバからコンテンツ・サーバへの経路を記述する経路情報を含むコンテンツ情報要求を返すことによって、コンテンツ・ファイルを効率的に配信する技術を説明するものである。

従来技術によるコンテンツ配信を理解するのに役立つマルチキャスティング・ツリーの例を示した図である。 本発明の原理によるコンテンツ配信を理解するのに役立つマルチキャスティング・ツリーの例を示した図である。 本発明の原理によるコンテンツ配信を理解するのに役立つマルチキャスティング・ツリーにおける別の例を示した図である。 クライアントからのコンテンツの要求に応答するノードの追加を示す、図３のマルチキャスティング・ツリーの変更を示した図である。

符号の説明

Ａ１、Ａ２、Ａ３、Ａ４ クライアント
ＣＳ コンテンツ・サーバ
Ｅ１、Ｅ２、Ｅ３、Ｅ４、Ｅ５ エッジ・サーバ

Claims (12)

1. エッジ・サーバを含むコンテンツ配信ネットワークを介してコンテンツ・サーバから要求元クライアントにコンテンツを配信する方法であって、
   前記コンテンツ・サーバによって、前記要求元クライアントからコンテンツの要求を受信し、
   前記コンテンツ・サーバによって、前記要求元クライアントから要求された前記コンテンツの供給源までの、エッジ・サーバの経路を作成し、
   前記クライアントが配信のためにそれを介して前記コンテンツを要求可能な少なくとも１つのエッジ・サーバを識別するために、前記コンテンツ・サーバによって、前記経路を含む要求ルーティング・メッセージを前記要求元クライアントに返す
   ステップを含むことを特徴とする配信方法。
2. エッジ・サーバによって、前記クライアントから前記コンテンツの配信要求を受信し、
   要求された前記コンテンツがそれを介して配信される少なくとも１つのサーバを識別するために、前記エッジ・サーバによって、前記コンテンツの要求内の経路データを解析し、
   前記エッジ・サーバによって、識別された前記サーバにコンテンツの要求を転送し、
   前記識別されたサーバから前記要求されたコンテンツを配信する
   ステップをさらに含むことを特徴とする請求項１に記載の配信方法。
3. 前記ルーティング・メッセージを返す前記ステップは、経路を含むユニフォーム・リソース・ロケータ（ＵＲＬ）を返すステップを含むことを特徴とする請求項１に記載の配信方法。
4. エッジ・サーバの経路を作成する前記ステップは、前記経路が前記コンテンツ配信ネットワーク内において要求されたコンテンツのための最初の経路ではない場合に、マルチキャスティング・ツリーに前記経路を追加するステップをさらに含むことを特徴とする請求項１に記載の配信方法。
5. コンテンツ配信を最適化するために、既存のマルチキャスティング・ツリーを更新するステップをさらに含むことを特徴とする請求項４に記載の配信方法。
6. 変化する条件に応じて、既存のマルチキャスティング・ツリーを動的に更新するステップをさらに含むことを特徴とする請求項５に記載の配信方法。
7. 前記既存のマルチキャスティング・ツリー内のサーバの故障に応じて、該マルチキャスティング・ツリーを更新するステップをさらに含むことを特徴とする請求項６に記載の配信方法。
8. コンテンツの利用可能性の変化に応じて、前記既存のマルチキャスティング・ツリーを動的に更新するステップをさらに含むことを特徴とする請求項６に記載の配信方法。
9. 解析する前記ステップは、コンテンツ情報内の前記経路情報に従って、マルチキャスティング・ツリーに少なくとも１つのサーバを追加するステップを含むことを特徴とする請求項３に記載の配信方法。
10. 要求元クライアントにコンテンツを配信する装置であって、
    コンテンツ・サーバ手段であって、（１）前記要求元クライアントからコンテンツの要求を受信し、（２）前記要求元クライアントから要求された前記コンテンツの供給源へのエッジ・サーバの経路を作成し、（３）前記コンテンツ・サーバによって、前記経路を含む要求ルーティング・メッセージを前記要求元クライアントに返し、（４）前記要求元クライアントによって、前記経路上の少なくとも第１のエッジ・サーバにコンテンツの要求を送信するための、コンテンツ・サーバ手段を備えており、
    前記エッジ・サーバ手段のうちの前記少なくとも１つが、要求されたコンテンツがそれを介して配信される少なくとも１つのサーバを識別するために、前記コンテンツの要求を受信し、該コンテンツの要求内の経路データを解析し、次いで、前記エッジ・サーバによって、識別された前記サーバにコンテンツの要求を転送し、その結果、前記識別されたサーバが前記要求されたコンテンツを配信することができる
    ことを特徴とする配信装置。
11. 前記要求ルーティング・メッセージは、経路を含むユニフォーム・リソース・ロケータを備えていることを特徴とする請求項１０に記載の配信装置。
12. 要求元クライアントにコンテンツを配信する方法であって、
    １つのコンテンツを求めるクライアントからの要求に応答して、前記コンテンツの供給源を識別する供給源データと該コンテンツ供給源への経路を識別する経路データとを含むコンテンツ情報を、前記要求元クライアントに返し、
    コンテンツの配信を開始するために、前記要求元クライアントから前記コンテンツ供給源情報を受信し、
    要求された前記コンテンツがそれを介して配信される少なくとも１つのサーバを識別するために、受信されたクライアントの供給源情報内の前記経路データを解析し、
    識別された前記サーバを介して、前記要求されたコンテンツをダウンロードする
    ステップを含むことを特徴とする配信方法。

Images