(57)【特許請求の範囲】
【請求項１】
パケットトラフィックをルーティングするアドレシング可能ルータを含み、データのパケットがパケットのアドレスフィールドに基づいてソースノードから目的地ノードまでルーティングされるパケットスイッチ型ネットワークにおいて、改良が、
少なくとも１つのアドレシング可能ルータに接続されたリディレクタを含み、該リディレクタが、
Ａ）クライアントからのサービス要求を受け入れる論理であって、該サービス要求がエニーキャスト目的地アドレスへのエニーキャストメッセージである、論理と、
Ｂ）該サービス要求を処理する選択されたサーバを決定する論理であって、該選択されたサーバが該サービス要求を処理し得る複数のサーバのうちの１つである、論理と、
Ｃ）該サービス要求を該選択されたサーバにリディレクトする、該クライアントに向けられたリディレクションメッセージを生成する論理と、
を備えた、パケットスイッチ型ネットワーク。
【請求項２】
前記エニーキャスト目的地アドレスへの到達可能性をアドバタイズする論理をさらに備えた、請求項１に記載のリディレクタ。
【請求項３】
前記決定する論理が、
前記複数のサーバのネットワークトラフィック状態を監視する論理と、
該ネットワークトラフィック状態に基づいて該複数のサーバから前記選択されたサーバを選択する論理と、
を備えた、請求項１に記載のリディレクタ。
【請求項４】
前記決定する論理が、
前記複数のサーバのサーバ状態を監視する論理と、
該サーバ状態に基づいて該複数のサーバから前記選択されたサーバを選択する論理と、
を備えた、請求項１に記載のリディレクタ。
【請求項５】
前記選択されたサーバがマルチキャスティングサーバである、請求項１に記載のパケットスイッチ型ネットワーク。
【請求項６】
前記リディレクタが前記選択されたサーバである、請求項１に記載のパケットスイッチ型ネットワーク。
【請求項７】
パケットトラフィックをルーティングするアドレシング可能ルータを含み、データのパケットがパケットのアドレスフィールドに基づいてソースノードから目的地ノードまでルーティングされるパケットスイッチ型ネットワーク内のリディレクタを動作させる方法であって、
該リディレクタからエニーキャスト目的地アドレスへの到達可能性をアドバタイズするステップと、
クライアントからのサービス要求を受け入れるステップであって、該サービス要求が前記エニーキャスト目的地アドレスへのエニーキャストメッセージである、ステップと、
該サービス要求を処理する選択されたサーバを決定するステップであって、該選択されたサーバが該サービス要求を処理し得る複数のサーバのうちの１つである、ステップと、
該サービス要求を該選択されたサーバにリディレクトする、該クライアントに向けられたリディレクションメッセージを生成するステップと、
を包含する、方法。
【請求項８】
前記複数のサーバのトラフィック状態を監視するステップをさらに包含する、請求項７に記載の方法。
【請求項９】
前記決定するステップは、前記トラフィック状態に基づいて前記複数のサーバから前記選択されたサーバを決定するステップを包含する、請求項８に記載の方法。
【請求項１０】
前記複数のサーバのサーバ状態を監視するステップをさらに包含する、請求項７に記載の方法。
【請求項１１】
前記決定するステップが、前記サーバ状態に基づいて前記複数のサーバから前記選択されたサーバを決定するステップを包含する、請求項１０に記載の方法。
【請求項１２】
前記リディレクタにおいて前記サービス要求を処理するステップをさらに包含する、請求項７に記載の方法。
【請求項１３】
前記生成するステップが、前記選択されたサーバにおいて、マルチキャストグループをサブスクライブするように前記クライアントをリディレクトする、該クライアントに向けられたリディレクションメッセージを生成するステップを包含する、請求項７に記載の方法。
【請求項１４】
パケットトラフィックをルーティングするアドレシング可能ルータを含み、データのパケットがパケットのアドレスフィールドに基づいてソースノードから目的地ノードまでルーティングされるパケットスイッチ型ネットワークであって、
該アドレシング可能ルータのうちの少なくとも第１のルータに接続され、エニーキャストグループ内のクライアントと複数のノードとの間でデータパケットを伝搬させる論理を有する、少なくとも１つのサービスノードと、
該アドレシング可能ルータのうちの少なくとも第２のルータに接続された少なくとも１つのリディレクタであって、該少なくとも１つのリディレクタが、
Ａ）該エニーキャストグループ内の該複数のノードに関連するエニーキャスト目的地アドレスへの到達可能性をアドバタイズする論理と、
Ｂ）該クライアントからのサービス要求を受け入れる論理であって、該サービス要求が該エニーキャスト目的地アドレスへのエニーキャストメッセージである、論理と、
Ｃ）該サービス要求を該少なくとも１つのサービスノードにリディレクトする、該クライアントに向けられたリディレクションメッセージを生成する論理と、
を備えた、パケットスイッチ型ネットワーク。
【請求項１５】
前記少なくとも１つのサービスノードが、複数のサービスノードを含み、該少なくとも１つのリディレクタが、
該複数のサービスノードから、該サービス要求を処理する選択されたサービスノードを決定する論理と、
該サービス要求を該選択されたサービスノードにリディレクトする、前記クライアントに向けられたリディレクションメッセージを生成する論理と、
を備えた、請求項１４に記載のパケットスイッチ型ネットワーク。
【請求項１６】
前記複数のサービスノードから前記選択されたサービスノードを決定する論理が、
該複数のサービスノードにおいてネットワークトラフィック状態を監視する論理と、
該ネットワークトラフィック状態に基づいて該複数のサービスノードから該選択されたサービスノードを選択する論理と、
を備えた、請求項１５に記載のパケットスイッチ型ネットワーク。
【請求項１７】
前記複数のサービスノードから前記選択されたサービスノードを決定する論理が、
該複数のサービスノードにおけるサーバ状態を監視する論理と、
該サーバ状態に基づいて該複数のサービスノードから該選択されたサービスノードを選択する論理と、
を備えた、請求項１５に記載のパケットスイッチ型ネットワーク。
【請求項１８】
前記エニーキャストグループ内の前記複数のノードのうちの第１の部分が、第１の地理的位置に位置づけられ、該エニーキャストグループ内の該複数のノードのうちの第２の部分が、第２の地理的位置に位置づけられ、前記リディレクタが、
該エニーキャストサービス要求を送信する前記クライアントが、該エニーキャストグループ内の該ノードのうちの該第１の部分と、該エニーキャストグループ内の該ノードのうちの該第２の部分のいずれにより近いかを決定する論理と、
該クライアントが該エニーキャストグループ内の該ノードの該第１の部分により近い場合、該サービス要求を第１のサービスノードにリディレクトし、該クライアントが該エニーキャストグループ内の該ノードの該第２の部分により近い場合、該サービス要求を第２のサービスノードにリディレクトする、該クライアントに向けられた前記リディレクションメッセージを生成する論理と、
を備えた、請求項１４に記載のパケットスイッチ型ネットワーク。
【請求項１９】
パケットトラフィックをルーティングするアドレシング可能ルータを含み、データのパケットがパケットのアドレスフィールドに基づいてソースノードから目的地ノードまでルーティングされるパケットスイッチ型ネットワークであって、該アドレシング可能ルータのうちの少なくとも１つと少なくとも１つのサービスノードとに接続されたリディレクタを備えたパケットスイッチ型ネットワークを動作させる方法であって、
該リディレクタからエニーキャスト目的地アドレスへの到達可能性をアドバタイズするステップと、
該リディレクタにおいてクライアントからのサービス要求を受け入れるステップであって、該サービス要求が該エニーキャスト目的地アドレスへのエニーキャストメッセージである、ステップと、
該サービス要求を該少なくとも１つのサービスノードにリディレクトする、該クライアントに向けられたリディレクションメッセージを生成するステップと、
を包含する、方法。
【請求項２０】
前記少なくとも１つのサービスノードが複数のサービスノードを含み、前記生成するステップが、
該複数のノードから、前記サービス要求を処理する選択されたサービスノードを決定するステップと、
該サービス要求を該選択されたサービスノードにリディレクトする、前記クライアントに向けられたリディレクションメッセージを生成するステップと、
を包含する、請求項１９に記載の方法。
【請求項２１】
前記決定するステップが、
前記複数のサービスノードにおいてネットワークトラフィック状態を監視するステップと、
該ネットワークトラフィック状態に基づいて該複数のサービスノードから前記選択されたサービスノードを選択するステップと、
を包含する、請求項２０に記載の方法。
【請求項２２】
前記決定するステップが、
前記複数のサービスノードにおいてサーバ状態を監視するステップと、
該サーバ状態に基づいて該複数のサービスノードから前記選択されたサービスノードを選択するステップと、
を包含する、請求項２０に記載の方法。
【請求項２３】
前記エニーキャストグループの前記複数のノードの第１の部分が第１の地理的位置に位置づけられ、該エニーキャストグループの該複数のノードの第２の部分が第２の地理的位置に位置づけられ、前記生成するステップが、
該エニーキャストサービス要求を送信する前記クライアントが、該エニーキャストグループの該ノードの該第１の部分と、該エニーキャストグループの該ノードの該第２の部分のいずれにより近いかを決定するステップと、
該クライアントが該エニーキャストグループの該ノードの該第１の部分により近い場合、該サービス要求を第１のサービスノードにリディレクトし、該クライアントが該エニーキャストグループの該ノードの該第２の部分により近い場合、該サービス要求を第２のサービスノードにリディレクトする、該クライアントに向けられた前記リディレクションメッセージを生成する、請求項１９に記載の方法。
【発明の詳細な説明】
【０００１】
（関連出願の相互参照）
本出願は、１９９９年９月３日に出願された同時係属中の米国仮特許出願第６０／１５２，２５７号から優先権を主張する。本出願は、「ＰＥＲＦＯＲＭＩＮＧ  ＭＵＬＴＩＣＡＳＴ  ＣＯＭＭＵＮＩＣＡＴＩＯＮ  ＩＮ  ＣＯＭＰＵＴＥＲ  ＮＥＴＷＯＲＫＳ  ＢＹ  ＵＳＩＮＧ  ＯＶＥＲＬＡＹ  ＲＯＵＴＩＮＧ」の名称で１９９９年６月１日に出願された米国特許出願第０９／３２３，８６９号と、「ＳＹＳＴＥＭ  ＦＯＲ  ＰＲＯＶＩＤＩＮＧ  ＡＰＰＬＩＣＡＴＩＯＮ−ＬＥＶＥＬ  ＦＥＡＴＵＲＥＳ  ＴＯ  ＭＵＬＴＩＣＡＳＴ  ＲＯＵＴＩＮＧ  ＩＮ  ＣＯＭＰＵＴＥＲ  ＮＥＴＷＯＲＫＳ」の名称で１９９９年１月１日に出願された米国仮特許出願第６０／１１５，４５４号に関連する。本明細書において、全ての目的のために、上記出願の各々の開示の全体を参考として援用する。
【０００２】
（発明の分野）
本発明は、概して、データネットワークの分野に関し、さらに詳細には、データネットワークにおける情報の配信に関する。
【０００３】
（発明の背景）
大量使用（ｍａｓｓ  ａｄｏｐｔｉｏｎ）のためにインターネットのインフラストラクチャを拡大縮小するための中心的な挑戦の１つは、効率的な方法、実行可能な方法、そして費用を有効活用する方法によって、ソーシングサイトからインターネットの多くのユーザに、任意のコンテンツを配信する問題である。一般のニュース記事、ビデオブロードキャスト、株式相場、人気ソフトウェアの新作などの宣伝（ｄｉｓｓｅｍｉｎａｔｉｏｎ）は、全て、ネットワークの全体にわたって広がっている多数のユーザが皆、ほぼ同時に同じサーバから同じコンテンツを検索しようとする、いわゆる「フラッシュ効果（ｆｌａｓｈ  ｅｆｆｅｃｔ）」という結果になり得る。トラフィックフラッシュ（ｔｒａｆｆｉｃ  ｆｌａｓｈ）は、サーバを屈服させるだけでなく、ネットワークのバンド幅を無駄にする。なぜならば、ワイドエリアネットワークにわたって、同じコンテンツの多くの重複コピーが流れるからである。例えば、ＣＮＮのウェブサイト上の速報ニュースイベント（ｂｒｅａｋｉｎｇ  ｎｅｗｓ  ｅｖｅｎｔ）は、何百万ものユーザが記事のテキストをそのサーバから取ってくる原因となり得る。同様に、知名度の高い映画ブロードキャストのインターネット上のプレミアショーは、同様に、何百万ものユーザによるメディアコンテンツサーバへのアクセスの試みを促進し得る。
【０００４】
フラッシュ効果によって引き起こされた問題を克服するために、ウェブのための２つの主要メカニズム、すなわち、キャッシング（ｃａｃｈｉｎｇ）およびサーバ複製（ｓｅｒｖｅｒ  ｒｅｐｌｉｃａｔｉｏｎ）が提案された。キャッシングにおいて、キャッシュがネットワークのインフラストラクチャ内の戦略的ロケーションに配置されて、クライアントからのコンテンツリクエストを妨害する。キャッシュは、コンテンツリクエストを受信すると、コンテンツ格納装置（ｓｔｏｒｅ  ｏｆ  ｃｏｎｔｅｎｔ）を調べる。そして、リクエストされたデータが存在する場合、キャッシュは、そのリクエストをローカルに果たす。さもなければ、リクエストは元のサーバにリレーされ、応答がリレーされてクライアントに返される。このプロセスの間、キャッシュは、キャッシュのローカル格納装置に応答を格納する。ローカル格納装置を管理するための多くの戦略、例えば、オブジェクトをキャッシュからいつ処分するか、サーバと異なり得るオブジェクトをいつリフレッシュするかを決定することなどが提案された。キャッシュは、非トランスペアレントであり得、この場合、クライアントは、キャッシュのネットワークアドレスによって明白に構成される。または、キャッシュは、トランスペアレントであり得、この場合、クライアントは、キャッシュについて無知であり、キャッシュは、例えばレイヤ４のスイッチ（ｌａｙｅｒ−４  ｓｗｉｔｃｈ）を使用して、コンテンツリクエストをトランスペアレントに妨害する。
【０００５】
サーバ複製において、サーバは、ワイドエリアの全体にわたって展開され、クライアントは、これらの配信されたサーバに割り当てられて、ロードのバランスを保ち、ネットワークバンド幅をセーブする。これらの複製されたサーバは、元のサーバにおいて収容されたコンテンツのいくつかまたは全てを有し得、サーバの特定の構成がどのように展開されるか、マスターサーバからサーバにコンテンツがどのように配信されるか、およびクライアントが適切なサーバにどのように割り当てられるかの多くの変化例が存在する。
【０００６】
これらの種類のサーバ複製をサポートするために展開された多くの技術、およびキャッシング技術は、特例であって、根本をなすインターネットアーキテクチャに適合しない。例えば、トランスペアレントなキャッシングのための一般的な技術は、ＴＣＰの意味を無くし、従って、根本をなすマルチパスルーティングなどのＩＰパケットサービスの特定のモードと互換性が悪い。これによって、多数の困難な管理問題が導かれ、詳細には、道理にかなった方法でネットワークオペレーションセンタから管理され得る密接したネットワークアーキテクチャを提供しない。
【０００７】
同様のコンテンツ配信問題は、インターネットの全体にわたって多くのユーザにライブストリーミングメディアを配送することに伴う。ここで、サーバは、ライブブロードキャストフィードを生成し、クライアントは、ブロードキャストを受信するためにストリーミングメディアトランスポートプロトコルを用いてサーバに接続する。しかし、ブロードキャストにますます多くのクライアントがチューニング（ｔｕｎｅ  ｉｎ）すると、サーバおよびネットワークは、多数のクライアントに多数のパケットストリームを配送するタスクによって圧倒される。
【０００８】
このライブブロードキャスト問題の１つの解決策は、ネットワークレイヤマルチキャストの効率、またはインターネットアーキテクチャにおいて定義されるＩＰマルチキャストに影響を与えることである。このアプローチにおいて、サーバは、ストリームの個別のコピーを個々のクライアントに送信するのではなく、単一のパケットストリームを「マルチキャストグループ」に送信する。次いで、該当するストリームに関心のあるレシーバは、マルチキャストグループに「予約購読する」ことによって（例えば、インターネットグループ管理プロトコル、ＩＧＭＰを用いて、最寄りのルータに予約購読情報の信号を送ることによって）ブロードキャストに「チューニング」する。ネットワークは、配信パス内のファンアウトポイント（ｆａｎ  ｏｕｔ  ｐｏｉｎｔ）においてのみ、ソースから全てのレシーバにパケットをコピーすることによって、各レシーバにブロードキャストを効率的に配送する。従って、各パケットの１つのコピーのみが、任意の物理的リンク上に現れる。
【０００９】
残念ながら、多種多様の展開および拡張性の問題は、グローバルインターネットにおけるＩＰマルチキャストの承認および増殖（ａｃｃｅｐｔａｎｃｅ  ａｎｄ  ｐｒｏｌｉｆｅｒａｔｉｏｎ）を混乱させた。ネットワーク内の全てのルータがツリーがどの様なものなのかの一様に一貫性のある図（ｕｎｉｆｏｒｍｌｙ  ｃｏｎｓｉｓｔｅｎｔ  ｖｉｅｗ）を有することをマルチキャスト配信ツリーの計算が必要とするという事実に、これらの問題の多くは基本的に関連する。マルチキャストにおいて、各ルータは、単一のグローバルに一貫したマルチキャストルーティングツリーの正確なローカル図を有することが必要である。ルータが、ネットワークの異なる部分における所定のマルチキャストツリーの異なる見解を有する場合、ルーティングループおよびブラックホールは、避けられない。例えば、マルチキャストアドレス割り当て、マルチキャスト混雑制御、マルチキャストの確実配送などの多数の他の問題もまた、ＩＰマルチキャストの展開および承認を困難にした。ここ数年において、マルチキャストの商業展開の実質的な進歩にも関わらず、結果得られるインフラストラクチャは、依然として、比較的脆性であり、その到達度は極めて限定的である。
【００１０】
遍在するインターネットマルチキャストサービスの展開に対する実質的な技術障壁に加えて、ビジネスおよび経済の障壁もある。インターネットサービスプロバイダは、ワイドエリアマルチキャストサービスの提供にあまり成功していない。なぜならば、マルチキャストトラフィックの管理、監視、および提供が、かなり困難であるからである。さらに、マルチキャストセッション内のだれがトラフィック生成し得るか、そしてそのトラフィックがネットワークのどの部分まで到達できるかを制御するのは困難である。これらの障壁が原因となり、インターネットのより良い部分に到達するマルチキャストサービスは、いつになっても出現しそうにない。出現しても、プロセスが展開するには、確実に多くの年月がかかる。
【００１１】
マルチキャストの落とし穴を避けるために、他の人たちは、ストリーミングメディアブロードキャストを、スプリッタネットワークと呼ばれるアプリケーションレベルの解決策によってイネーブルにすることを提案した。このアプローチにおいて、ネットワークの全体にわたって配信されるサーバのセットが、サービスプロバイダのネットワーク内の戦略的ロケーションに配置される。これらのサーバは、「スプリッティング（ｓｐｌｉｔｔｉｎｇ）」能力と共に提供され、これは、所定のストリームを多数のダウンストリームサーバに複製することを可能にする。この能力によって、サーバは、ツリー状の階層に構成され得、ここで、ルートサーバは、多数のダウンストリームサーバにストリームを供給し、次いで、ストリームを、ダウンストリームサーバのさらに別の層（ｔｉｅｒ）に転送される多数のコピーに分ける。
【００１２】
残念ながら、サーバのスプリッタネットワークは、多数の問題によって悩まされている。第１に、スプリッタのツリーは静的に構成され、これは、単一のスプリッタが破損すると、破損点の下にあるサブツリー全体がサービスを失う。第２に、スプリッタネットワークは、単一のブロードキャストセンタに向けられる必要があり、明確な物理的サーバからなる個々のスプリッタネットワークは、各ブロードキャストネットワークのために保持される必要がある。第３に、スプリッタ抽出は、メディアサーバの延長に基づくため、必然的にプラットフォームに依存し、例えば、ＲｅａｌＮｅｗｏｒｋｓベースのスプリッタネットワークは、Ｍｉｃｒｏｓｏｆｔ  Ｎｅｔｓｈｏｗトラフィックを配信し得ない。第４に、スプリッタネットワークは、きわめてバンド幅の効率が悪い。なぜならば、スプリッタネットワークは、レシーバの関心を追跡せず、ダウンストリームレシーバを有さないスプリッタネットワークのサブツリーからのトラフィックを切り捨てないからである。最後に、スプリッタネットワークは、ポリシーコントロール（ｐｏｌｉｃｙ  ｃｏｎｔｒｏｌ）が不足し、２スプリッタノード間の経路に沿って消費される総ビットレートの制御、およびストリームを意識した方法によるフローの異なるクラスへの割り当てを行い得ない。
【００１３】
（発明の要旨）
上記の多種多様の問題に対処するために、本発明の一実施形態は、仮想オーバーレイブロードキャストネットワーク（ＯＢＮ）におけるコンテンツ配信の総合的なリダイレクトシステムを提供する。このシステムにおいて、サービスノードは、ネットワークのインフラストラクチャの全体にわたって戦略的ロケーションに配置されるが、前システムとは違い、これらのサービスノードは、ワイドエリアの全体にわたって、密接、調整、および管理された仮想オーバーレイネットワークに調整される。サービスノードは、ＩＰトンネルの全体にわって互いにピア接続され、ルーティング情報、クライアント予約購読データ、構成制御、バンド幅用意能力などを交換する。同時に、サービスノードは、コンテンツのためにアプリケーション特定リクエストを処理することが可能であり、例えば、サポートサービスの性質によって、ウェブサーバまたはストリーミングメディアサーバのようにみえる。要するに、サービスノードは、複合的な役割を有する。すなわち、サーバおよびアプリケーションレベルコンテンツルータの両方として機能する。
【００１４】
本発明の一実施形態において、パケットスイッチネットワークの改良が提供される。パケットスイッチネットワークは、パケットトラフィックをルーティングするためのアドレス可能なルータを含み、ここで、パケットデータは、パケットのアドレスフィールドに基づいて、ソースノードから目的地ノードにルーティングされる。改良は、アドレス可能なルータの少なくとも１つに結合されたリダイレクターを含み、クライアントからサービスリクエストを受け取るための論理、サービスリクエストを処理するための選択されたサーバを決定する論理（選択されたサーバは、サービスリクエストを処理可能な複数のサーバの内の１つである）、サービスリクエストを選択されたサーバにリダイレクトするためにクライアントに向けられるリダイレクトメッセージを生成するための論理を含む。
【００１５】
（特定の実施形態の説明）
本発明の包括的なリダイレクトシステムは、ネットワークインフラストラクチュアのすみずみに戦略的場所に設置されたサービスノードと連携して動作する。これらのサービスノードを、広域にわたって連携させることにより、仮想オーバーレイネットワークが、結合性、連携性、かつ、管理性を有するようになる。オーバーレイネットワークアーキテクチャは、基底のインターネットアーキテクチャの設計哲学（例えば、この設計哲学は拡張可能なアドレス指定、適応可能なルーティング、階層的命名、分散統括などを利用する）に類似した設計哲学に基づく。これにより、オーバーレイアーキテクチャは、インターネット自体に自明の、高いロバースト性、拡張性および管理性を同じく享受する。ルータが物理リンクを介して、直接的に相互に取り付けられる物理的インターネットワークとは異なり、仮想オーバーレイネットワーク内のサービスノードは、基底のＩＰネットワークによって提供されるパケットサービスを用いて、相互に通信する。したがって、仮想オーバーレイは、拡張可能性が高い。なぜならば、優れたコンテンツ配信の性能を提供するためには、多数の個々のコンポーネント（ルータ、スイッチおよびリンクなど）から形成されるネットワークの大領域（例えば、ＩＳＰのバックボーン全体）が、少数のサービスノードのみを必要とし得るからである。
【００１６】
本発明の別の重要な局面は、情報コンテンツを受信しようとするクライアントと、この情報コンテンツを実際に送信するサービスノードとの間の「接着」インターフェースである。すなわち、「接着」インターフェースは、クライアントがサービスノードに取り付け、コンテンツの特定の部分をリクエストし、このコンテンツを効果的に送信させることが可能なメカニズムである。これは時には、「サービスランデブ−」問題と呼ばれる。
【００１７】
基本的に、サービスランデブは、（１）サービスに一つの名称を発表し、（２）ネットワークにわたってこのサービスを繰り返し、かつ、（３）サービスを所望する各クライアントに、最適なサーバーからこのサービスを受信させることが可能なシステムを伴う。何百万ものクライアントを計測するために、サービスランデブメカニズムは、広域にわたって広がったサービスノードに、クライアントリクエストを効果的に配信し、かつ、ロードのバランスを調整する必要がある。さらに、ネットワークの帯域幅を効果的に利用するには、リクエストするクライアントにコンテンツが届くまで、コンテンツが通るネットワークリンクの数を最小にする必要がある。これら両方の点から論じられることは、リクエストに応じてそれを実行することが可能な近隣のサービスノードにクライアントを方向付けなければならないことである。リクエストに応じてそれを実行することが可能なサービスノードが近隣にない場合、リクエストに応じてそれを実行するために、システムは広域にわたるネットワーク内のいたるところにあるサービスノードにクライアントをリダイレクトすることが可能である必要がある。さらに、特定の場所におけるサービスノードをクラスタリングし、トラフィックロード状態に基づいて、クライアントをクラスタ内の個々のノードに接続させることが可能でなければならない。つまり、所望の結果を得るためには、サービスランデブシステムは、サーバ選択のメカニズムを提供し、かつ、ロードバランシングを実施するようにリダイレクトする必要がある。ローカルクラスタがオーバーロードになった場合、サーバ選択は、広域にわたって、バランスをロードするために補償する必要がある。
【００１８】
残念ながら、サービスランデブは難しい問題である。なぜならば、インターネットアーキテクチャが、より高い層のプロトコルに柔軟性およびロバースト性を課すネットワークの基底構造を故意に隠すため、特定のネットワークトランザクション用に選択されたサーバを検出、かつ、使用することが困難だからである。これらの問題を克服するために、本明細書に説明するランデブーサービスは、「エニーキャスト（ａｎｙｃａｓｔ）」ルーティング、すなわち位相のローカル性に基づいて近隣のサービスノードにユーザリクエストをルート付けするために用いられ得るネットワークレベルのメカニズムを利用する。
【００１９】
エニーキャストパケット転送の概念は、ネットワーク研究の文献において周知であるが、既存のパケット転送ネットワークとの互換性の問題があるため、この概念を実際に応用することは狭い範囲に限られている。概して、インターネットの動作は、最終的に合意される規格に準拠する。本明細書において記載するこの規格を、「リクエスト  フォー  コメント」（ＲＦＣ）と呼ぶ。インターネットの動作に適用可能なＲＦＣは、ＲＦＣ−１５４６およびその他を含む。
【００２０】
最も高いレベルにおいて、エニーキャストパケット転送を実施する主なアプローチが２つある。第一のアプローチは、特定の種類のエニーキャストアドレスを導入し、新たなルーティングプロトコルを作成し、「エニーキャストアウェア（ａｎｙｃａｓｔ  ａｗａｒｅ）」であるインターフェースを作動させることである。これは明らかに、標準化の長いプロセス、ルータベンダの採用などを伴う。第二のアプローチは、既存のユニキャストアドレス空間の一部を再利用することである。しかし、第二のアプローチには、これまでまだ解決されていない二つの対応する技術的難問がある。これらの難問は、（１）ステートフル分配プロトコル（ｓｔａｔｅｆｕｌ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ）をサポートする難問、および（２）ドメイン間のエニーキャストルーティングおよびルートの集合をサポートする難問である。幸運にも、本発明の実施形態は、これらの技術的難問に対し新奇な解決策を提供する。例えば、ステートフル分配プロトコルをサポートする問題の解決策は、本明細書中の「ステートフルエニーキャスティング」という名称のセクションで提示する。ドメイン間のエニーキャストルーティングおよびルートの集合をサポートする問題への解決策は、本明細書中の「ドメイン間エニーキャストルーティング」という名称のセクションで提示する。
【００２１】
本明細書において説明するランデブーサービスは、基底パケット転送が「エニーキャストアウェア」ではないことを仮定する。しかし、「エニーキャストアウェア」ネットワークに基づいたシステムも実行可能である。エニーキャストパケット転送は、クライアントからランデブーサービスの最も近いインスタンスにパケットを転送するために用いられる。
【００２２】
代わって、本発明の一実施形態は、完全で、動的なフレームワーク（ここで、ホストはエニーキャストグループを動的に結合および残すことが可能である）から、静的で、一時的なフレームワーク（ここで、ネットワークインフラストラクチュア内で特に構成されたホストのみがエニーキャストグループのメンバーである）まで、エニーキャストサービスモデルを簡略化する。この静的で、一時的なフレームワークにおいて、エニーキャストアドレスの割り当て、割付けおよび宣伝は、中央オーソリティに対するものであり、大きなブロックのエニーキャストアドレスと一つのよく接続されたバックボーンネットワークとを関連付ける。バックボーンネットワークは、コンテンツバックボーン（ＣＢＢ）と呼ぶことができる。
【００２３】
本発明の実施形態に含まれる別の利点は、明示的な、クライアントごとのサービスアクセスポイントにおいて、クライアントがコンテンツ配信ネットワークに取り付けることである。これにより、インフラストラクチュアがユーザ特定の認定、モニタリング、カスタマイゼーション、宣伝などを実行することが可能になる。対照的に、純粋なマルチキャストに基づいたアプローチは、マルチキャストレシーバ予約購読プロセスが完全に匿名であるため、拡張可能であるにもかかわらず、これらの機能のうちのいずれも提供しない。
【００２４】
要約すると、エニーキャストベースのサービスランデブを用いて構築される仮想オーバーレイネットワークは、以下の魅力的な特性を享受する。
・サービスアクセスメカニズムは、非常に拡張性がある。これは、新規な構成で配置された標準のルーティングプロトコルで達成することが可能なエニーキャストを用いて、最も近いサービスノードが検出されるためである。
・本システムは、実質的な帯域幅を節減する。これは、リクエストを最も近いサービスノードにルート付けすることが可能であり、これにより、コンテンツが通過する必要のあるネットワークリンクの数が最小限に留められるからである。
・本サービスインフラストラクチュアは、クライアント接続の細かい制御、モニタリングおよびカスタマイゼーションを提供する。
・本インフラストラクチュアの統括および構築は、非常に分散され、これにより、多様な範囲の統括エンティティによって管理される不均質の環境にわたって大規模に配置することが容易になる。
・本システムは、エニーキャストが標準の適用可能なルーティングプロトコル上に構築され、サービス要素が冗長のためにクラスタリングされる場合、利用可能性およびロバースト性が非常に高くなる。これにより、適切に機能し、かつ、その利用可能性を宣伝するサーバ上にのみリクエストをルート付けすることが保証される。
・本コンテンツブロードキャストネットワークは、インクリメンタルに配置可能である。これは、まずエニーキャストベースでリダイレクトするサービスをコンテンツブロードキャストバックボーン内に構築することが可能であり、次いで、増加するユーザの要求をつかむために、関連ＩＳＰ内に個人ベースでリダイレクトするサービスを構築することが可能だからである。
【００２５】
本明細書の以下のセクションにおいて、本発明内に含まれる仮想オーバーレイブロードキャストネットワーク向けのエニーキャストベースでリダイレクトシステムを実施するために用いられるアーキテクチャモデルおよび種々のシステムコンポーネントの実施形態の詳細を説明する。
【００２６】
（ネットワークアーキテクチャー）
図１は、インターネット１００の一部を含む典型的な構成要素および相互接続の一例である。インターネットサービスプロバイダ（ＩＳＰ）１０１、１０２、および１０３は、インターネットアクセスを提供する。典型的なＩＳＰは、アクセスデバイス１０６（例えば、ＤＳＬ、電話モデム、ケーブルモデム等）を介して、個々のカスタマーネットワーク１０４および／または個々のユーザをネットワークに接続するために、広域にわたってＩＰに基づくネットワークを作動する。典型的ＩＳＰはまた、エクスチェンジポイント１０８を介して、他のＩＳＰとピア接続することにより、あるＩＳＰのユーザから別のＩＳＰのユーザへ、データトラフィックが流れることができる。通信リンク１１１と相互接続された内部ＩＰルータ１１０の集合は、ＩＳＰ内のユーザ間の接続を提供する。エクスチェンジポイントに位置する特殊ボーダールータ１１２は、ローカルでないトラフィックを、ＩＳＰ内に、およびＩＳＰから転送する。しばしば、ＩＳＰ１０３等の個々のＩＳＰネットワークは、自律システム（ＡＳ）と呼ばれるが、これは、ネットワークルーティングプロトコルの観点で、独立し、かつ集合可能なユニットを表わすからである。ＩＳＰ内では、ドメイン内ルーティングプロトコルが走り（例えば、ＲＩＰまたはＯＳＰＦ）、ＩＳＰをわたって、ドメイン間ルーティングプロトコルが走る（例えば、ＢＧＰ）。「ドメイン内プロトコル」という用語は、しばしば、インテリアゲートウェイプロトコル（ＩＧＰ）という用語と置換え可能に用いられる。
【００２７】
インターネットおよびワールドワイドウェブ（ウェブ）が発達するにつれ、ＩＳＰは、２つの革新的なアーキテクチャー概念を一緒に組み合わせること、すなわち、（１）各エクスチェンジポイントで多数の隣接するＩＳＰと積極的にピア接続すること、および（２）これらのエクスチェンジポイントの近くに、アプリケーションサービスを含むデータセンター（例えば、ウェブサーバ）を併設することにより、より良い端末相互間ネットワークサービスパフォーマンスが得られ得ることを実現した。よって、各ピア接続ポイントの「併設設備」（ｃｏｌｏ）は、ユーザがネットワーク内のほぼどこにいても、近くのサービスへの高速接続を享受するように、各ピア接続ポイントでアプリケーションサービスが模写されることを可能にする。
【００２８】
図２は、オーバーレイＩＳＰ２００のための典型的アーキテクチャーを示し、サービスネットワークがこのように構築されているため、例えば、ＩＳＰ２０２、２０４、および２０６等の多数の既存のＩＳＰをわたってオーバーレイ構造が形成される。オーバーレイＩＳＰ２００は、ルータ２０８を介して、既存のＩＳＰと結合し、さらに、データセンター（ＤＣ）２１０と結合する。オーバーレイＩＳＰは、ＤＣに位置する併設設備（ｃｏｌｏ）にサーバを置くコンテンツプロバイダに、マシンスペースおよびネットワーク帯域幅を貸与する。
【００２９】
要約すれば、ＣＢＢのための自然構築ブロックがＩＳＰ併設設備（ｃｏｌｏ）である。本発明の実施形態では、サービスノードが併設設備（ｃｏｌｏ）内に収容され、利用可能なネットワーク接続を用いて、広域にわたるオーバーレイ構造内に配置される。しかしながら、サービスノードは、特殊な併設設備（ｃｏｌｏ）サイトに位置する必要がなく、実際には、ネットワークのどの部分にも存在することができる。併設設備（ｃｏｌｏ）は、サービスノードにとって便利で実効可能な配置チャネルである。
【００３０】
（ドメイン間エニーキャストルーティング）
図３は、本発明によるエニーキャスト（ａｎｙｃａｓｔ）ルーティングを実現するように構成されたネットワーク３００を示す。ネットワーク３００は、ルータ（Ｒ１〜Ｒ６）、２つのサーバデバイスＳ1およびＳ2、ならびに２つのクライアントＣ1およびＣ2を備える。ネットワーク３００の１つの実施形態では、両方のサーバデバイスが、ＩＧＰを介して、アドレスブロック「Ａ／２４」（すなわち、Ａは３２ビットのＩＰｖ４アドレスのための２４ビットのプレフィクスである）への到達可能性をアドバタイズする（ａｄｖｅｒｔｉｚｅ）。よって、２つのサーバデバイスは、ネットワーク３００のインフラストラクチャにサーバの利用可能度を反映するために、ルーティングアドバタイズメントを利用する。ルータＲ4およびＲ3は、それぞれ、それらの付加されたＬＡＮ３０２および３０４上の到達可能度アドバタイズメントを受信する（ｌｉｓｔｅｎ）ように構成される。ＩＧＰの計算の結果として、ネットワーク内のルータＲ１〜Ｒ６は、「Ａ」プリフィクスに該当するアドレスを介して、各クライアントからサーバへの最短経路を覚える。よって、クライアントＣ2がアドレスＡ1にパケットを送信すると（ここで、Ａ1のプレフィクスはＡである）、経路３１０で示すように、ルータＲ2はそれをルータＲ4に転送し、次いで、それをサーバＳ2に転送する。同様に、クライアントＣ1からＡ1に送信されたパケットは、経路３１２で示すように、サーバＳ1にルーティングされる。サーバＳ2が失敗すると、Ａ／２４に対するＳ2からのアドバタイズメントは終わり、ネットワークは、Ａ／２４への対応する最短経路ルートを再計算する。結果的に、経路３１４で示すように、そのようなルートをアドバタイズするノードが他にないため、Ｃ2からＡ1に送信されたパケットは、サーバＳ1にルーティングされる。
【００３１】
上述のエニーキャストルーティング方式により生じる問題のうちの１つは、エニーキャストルートが、エニーキャストに基づいたサービスノードで構成されていない可能性がある任意のサイトに、どのように広域を渡って伝播するかということである。エニーキャストルーティングのための新たなインフラストラクチャを必要とするのではなく、本発明の実施形態は、単一のＡＳが所与のエニーキャストアドレスブロックを「所有」し、通常のドメイン間プロトコル、すなわち、ＢＧＰを用いてアドバタイズする、フレームワークを単に用いて、既存のドメイン間ルーティングシステムに影響を与える。そして、他の独立したＡＳは、それらのＡＳのためのＩＧＰが、その単一のＡＳ内のサービスノードに、当該のエニーキャストアドレスブロックに送信されたパケットをルーティングするように、エニーキャスト認識サービスノード（ａｎｙｃａｓｔ−ａｗａｒｅ  ｓｅｒｖｉｃｅ  ｎｏｄｅｓ）で漸増的に構成され得る。
【００３２】
これを行うために、コンテンツバックボーン（ＣＢＢ）が、エニーキャストアドレスブロックを所有し、ＢＧＰを用いてそれをインターネットにアドバタイズする、「マスター」ＡＳに位置する。すなわち、ＩＳＰは、予め存在するが、用いられていないアドレス空間のブロックをつくりあげ（または、インターネット番号割当機構（Ｉｎｔｅｒｎｅｔ  Ａｓｓｉｇｎｅｄ  Ｎｕｍｂｅｒｓ  Ａｕｔｈｏｒｉｔｙ）からの新たなアドレスをリクエストし）、このブロックに、このアドレスのブロックがエニーキャストルーティング以外のためには用いられないことを宣言するＣＢＢに割当てる。マスターＡＳは、通常のＩＰネットワークであるかのように、再度ＢＧＰを用いて、広域にわたってエニーキャストブロック（このブロックを「Ａ」と呼ぶ）をアドバタイズする。よって、これまでに説明した構成では、インターネット内の任意の場所からブロックＡ内のアドレスに送信された、任意のパケットがマスターＡＳへとルーティングされる。
【００３３】
エニーキャストルーティングインフラストラクチャの基礎となるサービスを提供するために、ＣＢＢは、マスターＡＳ内にサービスノードを配置し、マスターＡＳのＩＧＰを用いて、Ａに対する到達可能度をアドバタイズするために、それらのノードを構成する。一旦、この部分が適切な位置につくと、パケットが（インターネット上のいずれかの場所から）マスターＡＳに入ると、マスターＡＳに入ったときにパケットが通過したボーダールータに最も近いＣＢＢサービスノードへとルーティングされる。マスターＡＳが密集して、ピア接続することを仮定すると、インターネット上の大部分のユーザは、マスターＡＳ（ＣＢＢ）内のサービスノードへの遅延が少なく、高速の経路を享受する。
【００３４】
これまでに説明されたアーキテクチャは、マスターＡＳ内に位置するノードに対する近接度に基づくサービスノード位置を実行可能なメカニズムに提供するが、システムは、全てのノードがそのマスターＡＳにあるという事実により限定される。よりスケーラブルなアプローチは、サービスノードが他のＩＳＰのネットワーク内にインストールされることを可能にする。そうするために、アフィリエイトＡＳ（すなわち、集合サービスをサポートするが、マスターＡＳではないＩＳＰ）は、単純に、サービスノードをマスターＡＳと全く同じ方法でインストールする。しかしながら、アフィリエイトは、ＩＧＰを用いて、そのドメイン内のみのエニーキャストブロックをアドバタイズし、そのドメイン外のエニーキャストブロックをそのピアにアドバタイズする。別の実施形態では、この方式に対して、複数のＡＳがＢＧＰ（すなわち、外部ルーティングプロトコル）内のエニーキャストブロックをアドバタイズするという拡張が提供される。この拡張は、本文書の別のセクションで説明される。
【００３５】
図４は、ドメイン間エニーキャストルーティングを達成するように構成された、マスターＡＳ４００、ならびにアフィリエイトネットワーク４０２、４０４、および４０６を示す。マスターＡＳ４００は、エニーキャストに基づくサービスノードＡ1、Ａ2、およびＡ3を備え、ルータ４０８を介して、３つのアフィリエイトネットワークと結合する。４つのクライアントＣ1、Ｃ2、Ｃ3、およびＣ4が、示されるとおり、アフィリエイトに付属する。アフィリエイト４０２および４０６は、内部に配置されたサービスノードを有さないが、アフィリエイト４０４は、そのインフラストラクチャに構成される単一のサービスノードＡ4を有する。よって、ユニキャストのドメイン間ルーティングプロトコルおよびドメイン内ルーティングプロトコルが通常に行動すると仮定して、Ｃ1からブロックＡに送信されるパケットは、経路４１０により示されるように、Ａ1に送信されるが、Ｃ2からブロックＡに送信されるパケットは、経路４１２により示される、Ａ2にルーティングされる。経路４１０および４１２は、アフィリエイト４０２からマスターＡＳ４００への最短のドメイン間経路を表わす。対照的に、クライアントＣ3からブロックＡに送信されるパケットは、経路４１４により示されるように、サービスノードＡ4にルーティングされる。これは、アフィリエイト４０４内のＩＧＰがサービスノードＡ4に、ブロックＡ、よって、そのアドレスへ送信される「ハイジャック（ｈｉｊａｃｋ）」パケットへの到達性をアドバタイズすることを可能にする。同様に、Ｃ4からブロックＡに送信されるパケットもまた、アフィリエイト４０６からマスターＡＳ４００への経路がアフィリエイト４０４を横切るため、経路４１６により示されるとおり、Ａ4により「ハイジャック」される。正確な操作のためにあらゆる場所に配置されるエニーキャスト知能を必要とすることなく、システムのロードを測定し、分布するため、これは、本発明によるアーキテクチャの熟慮された所望の特徴である。
【００３６】
エニーキャストアドレシングおよびルーティングアーキテクチャは、スケーラブルなサービスランデブ（ｓｅｒｖｉｃｅ  ｒｅｎｄｅｚｖｏｕｓ）のためのフレームワークを提供するが、エニーキャストアドレススペースの所有権は、好ましくは、ＣＢＢおよび／またはマスターＡＳに集中する。これにより、解決策の全体的な柔軟性がある程度制限されるが、アドレススペースの管理の集中化の利益を有する。このモデルでは、コンテンツプロバイダがＣＢＢとサインアップする場合、利用可能なアドレスのＣＢＢのブロックから専用のエニーキャストアドレススペースが割当てられる。次いで、コンテンツプロバイダは、それらのサービスを参照して、例えば、ユニフォームリソースロケータ（ＵＲＬ）のホスト部分として、このエニーキャストアドレススペースを用いる。よって、このようなウェブリンクをクリックするユーザは、ＣＢＢ内またはそのアフィリエイト内の最寄のサービスノードに向けられる。
【００３７】
（ネーミングおよびサービスディスカバリ）
サービスノードがサービスに対するエニーキャストリクエストを受信すると、そのサービスは、リクエストしているクライアントのために具体化されなければならない。すなわち、（マスターサービスの拡張が局所的に利用可能である場合）そのサービスリクエストは、局所的に満たされなければならないか、またはマスターサービスサイトから開始されなければならない。マスターサイトのサービスの位置確認をするための１つの方法は、上からエニーキャストルーティングアーキテクチャを繰り返し適用することである。しかし、パケットは、そのパケットが出てきたホストにルーテイングされて戻るため、エニーキャストパケットを該当するエニーキャストアドレスに送信する試みは失敗する。換言すれば、エニーキャストパケットは、それを受信したドメイン内に閉じ込められる。よって、システムは、リモートサービスノードとマスターサービスサイトとの間の通信のためのなんらかの他のメカニズムに依存しなければならない。
【００３８】
１つの実施形態では、サービスノードは、エニーキャストアドレスをマスターサービスサイト、または申し込まれたサービスに関するサブサービスの集合にさえもマッピングするために、なんらかのデータベースに問い合わせなければならない。幸いに、この種のマッピングを非常にスケーラブルかつロバストな方法で実施する分散型データベースがすでに存在する。全体として、インターネット内でのＩＰホストネームツーアドレスのマッピングを処理する、ドメインネームシステム（ＤＮＳ）は、この目的のために、容易に、再利用および構成され得る。さらに詳細には、ＲＦＣ−２０５２は、ＤＮＳサービス（ＳＲＶ）リソースレコードを用いて、任意のサービスエントリを定義するための方式を定義する。なんらかの明確な確定的アルゴリズムに従って、数字のエニーキャストアドレスをＤＮＳドメインネームに変換することにより、サービスノードは、このエニーキャストネームをキー入力されたＤＮＳ問合わせを用いて、サービスの位置を決定することができる。必要とされるＤＮＳ構成は、ＣＢＢにより実行され得るか、またはＣＢＢは、特定のエニーキャストブロックのためのＤＮＳサブドメインを構成するための権限を元のコンテンツプロバイダに委任し得、そのプロバイダが申し込まれたサービスを構成し、かつ適切であるように管理することができる。
【００３９】
代替的な方法は、単一のエニーキャストアドレスのみをＣＢＢに割り当て、クライアントＵＲＬにおけるコンテンツ発生サイトについてのさらなる情報を埋め込むことである。すなわち、エニーキャストルーティングが用いられて、ＣＢＢを介して公開された任意のコンテンツのクライアントリクエストを捕捉し、ＵＲＬについてのさらなる情報が用いられて、問題のコンテンツについての特定のロケーションまたは他の属性が識別される。この開示内容の残りの部分において、前者の（複数のエニーキャストアドレスが、ＣＢＢに割り当てられる）方法は、例示のために仮定されるが、当業者であれば、単一のエニーキャストアドレスのみが各ＣＢＢに割り当てられるように、システムがどのように簡略化されるのかは明らかである。
【００４０】
要するに、２つの独立した機構、すなわち、（１）エニーキャストアドレスおよびルーティングを用いるサービスインフラストラクチャに結合されたクライアント、ならびに（２）クライアントＵＲＬを介して明示的に運ばれるか、または、ＤＮＳのような配信されたディレクトリを介して暗示的に運ばれる補助情報を用いるマスタサービスサイトに結合されたサービスノードを用いることによって、拡大縮小できる様態で、サービスランデブー問題が解決される。卓越した拡大縮小性能は、近接に基づくエニーキャストルーティングおよびキャッシング、ならびに、ＤＮＳ内に構築された階層によって、得られる。
【００４１】
（ステートフルエニーキャスティング）
ＩＰパケットサービス上でのエニーキャストサービスの実現における問題点のうちの１つとして、基礎をなすルーティングインフラストラクチャのダイナミックであるという性質がある。パケットが複製され、（特に）異なる経路に沿ってルーティングされることをＩＰが可能にするので、エニーキャストサービスを用いて送信されたパケットは、複数のエニーキャストサービスノードに同時に送達されてもよいし、連続的なパケットが、断続的に、あるサービスノードから次のサービスノードへと送達されてもよい。
【００４２】
これは、特に、通信チャネルの端点が固定されると考えられるＴＣＰのようなトランスポート層プロトコルについて、問題である。例えば、エニーキャストアドレスを介するサービスノードへのＴＣＰ接続について考慮してみる。接続の途中で、エニーキャストルートが、クライアントのパケットが、急に異なるサービスノードにルーティングされるように変化するとする。しかし、新たなサービスノードは、現在のＴＣＰ接続について知識がないので、「接続リセット」という信号をクライアントに送り返す。これによって、接続が中断し、クライアントが呼び出そうとしていたサービスの分断につながり得る。この問題点の難しいところは、ＴＣＰ接続がステートフルであり、ＩＰがステートレスであることである。
【００４３】
かなりの量の研究が、この問題について論じられているが、本発明とともに用いるために充分な解決法は、生み出されていなかった。ＴＣＰプロトコルを、この問題点を回避するように変更することは可能であり得る。しかし、インターネットにおいて配布される何百万ものＴＣＰスタックのインストールされたベース全体を変更することは、不可能に近い。他のアプローチは、ルータがネットワーク内にステートを留めて、エニーキャストＴＣＰ接続が元の経路を維持することを確実にする方法を主張してきた。この方法も、インターネットインフラストラクチャにおける全てのルータを更新する必要があり、その仕事は依然大部分が研究段階にあるので、非現実的である。
【００４４】
本発明のある実施形態において、ステートフルエニーキャスティングという新規な方式が採用される。このアプローチにおいて、クライアントは、エニーキャストを、明らかに短命のトランザクションである、リダイレクトサービスの一部としてのみ用いる。すなわち、クライアントは、エニーキャストサービスを介してエニーキャスト参照ノードにコンタクトし、参照ノードがクライアントを通常アドレスおよびルーティング（ユニキャスト）サービスノードにリダイレクトする。従って、基礎をなすエニーキャストルートが不確かなためにリダイレクトプロセスが失敗する可能性は低い。このようなことが起こる場合、リダイレクトプロセスは、クライアントによって、またはコンテキストに応じて、コンタクトされた新たなサービスノードによって、再始動され得る。リダイレクトプロセスが、単一リクエストおよび単一応答用に設計される場合、クライアントは、エニーキャスティング病状から発生する任意の不一致を容易に解決し得る。
【００４５】
サービストランザクションが短命である（例えば、数回往復するれば、データが転送され得る）場合、リダイレクトの必要性は、限られる。すなわち、短いウェブ接続全体が、ＴＣＰエニーキャスト接続として処理され得る。一方、ストリーミング媒体のような長命接続は、ルート変化の影響を受けやすいが、ステートフルエニーキャスティングは、ルート変化が問題を起こす可能性（すなわち、変化が、リダイレクトプロセスの間に発生する必要性）を最小化する。しかしインフラストラクチャに基づくエニーキャストが幅広く配布されている場合、アプリケーション供給者は、エニーキャストサービスに対するサポートを提供するインセンティブを有し、その場合、クライアントは、ルーティング遷移が何らかの種類のサービスの分断を引き起こすときに、エニーキャストサービスをトランスペアレントに再呼び出しするように変更され得る。
【００４６】
他の実施形態において、ルーティング遷移の悪影響が、インフラストラクチャの動作方針を注意深く設計することによって、最小限にされる。従って、本明細書中で説明するように、ダイナミックなルーティング変化がかなり頻繁であるので、実際には、エニーキャストについてのＩＰのステートレス性によって引き起こされる問題点が最小限にされる大規模エニーキャスティングインフラストラクチャが、構築され得る。すなわち、本明細書中に記載のステートフルエニーキャスティング方法は、幅広く利用可能であり、ロバストであり、信頼できる、サービスランデブーシステムを提供し得る。
【００４７】
（近接に基づくリダイレクトシステム）
上記のアーキテクチャコンポーネントを前提として、このセクションは、これらのコンポーネントを結合するエニーキャストに基づくリダイレクトサービスに関する、本発明のある実施形態を説明する。この設計のコンポーネントのうちの一部は、明らかに、各種の有用なコンフィギュレーションおよび配布シナリオに一般化することができ、本明細書中の特定の記載に限定されるものではない。他の機構は、ストリーミング媒体放送またはウェブコンテンツ配信のような特定のサービスに特に適する。
【００４８】
近接に基づくリダイレクトシステムは、（１）任意のアプリケーション特有リダイレクトプロトコルがクライアントとサービスとの間で用いられることを可能にすること、および（２）リダイレクトサービスと、クライアントと、マスタサービスサイトと、ＣＢＢとの間にグルーを提供することによって、任意のコンテンツ配信ネットワークのサービスノード取り付け設備を提供する。
【００４９】
ＣＢＢは、マスタＡＳ内でルーティングされた特定のエニーキャストアドレス空間を所有する。各コンテンツプロバイダは、エニーキャストアドレス空間からの１つ以上のエニーキャストアドレスが割り当てられる。任意のサービスが、ＤＮＳを用いてエニーキャストアドレスに結合され得るので、個別のコンテンツプロバイダごとについて、１つのアドレスのみが必要とされる。例示のため、カノニカルコンテンツプロバイダのＤＮＳドメインが「ａｃｍｅ．ｃｏｍ」であり、ＣＢＢのドメインが「ｃｂｂ．ｎｅｔ」であるとする。ＣＣＢに割り当てられるエニーキャストアドレスブロックは、１０．１．１８／２４であり、ａｃｍｅ．ｃｏｍに割り当てられるアドレスは、１０．１．１８．２７である。コンテンツプロバイダ（ａｃｍｅ．ｃｏｍ）がウェブコンテンツ、オンデマンドストリーミング媒体コンテンツ、および生放送コンテンツを生成するとさらに仮定される。
【００５０】
以下のセクションは、本発明による、（コロ（ｃｏｌｏ）で規定される）ローカルアーキテクチャを含むコンポーネント、（ＩＳＰの間、またはＩＳＰにわたって規定される）広範囲アーキテクチャを含むコンポーネント、ならびに、これらのアーキテクチャおよびその基礎をなす一般的な原理に基づくある特定のリダイレクトアルゴリズムを説明する。
【００５１】
（ローカルアーキテクチャ）
このセクションは、特定のＩＳＰ内、例えば、コロ内部の近接に基づくリダイレクトサービスをサポートするデバイスの構成、およびこれらのデバイスがどのように構成され、外部のコンポーネントとインターフェースを取るのかについて説明する。
【００５２】
コンテンツ配信アーキテクチャは、２つの相互依存するが、別個のコンポーネント、すなわち、（１）制御およびリダイレクト設備、および（２）実際のサービス機能に本質的に分解する。すなわち、サービスは、典型的には、制御接続によって、呼び出され、データ接続にわたってサービスの配信をトリガする。さらに、制御接続は、典型的には、ＩＰホストにリダイレクトされるように修正可能である。従って、システムについての高レベルモデルは、以下の通りである。
【００５３】
・クライアントは、サービスをリクエストするようにエニーキャストアドレスへの制御接続を開始する。
【００５４】
・そのエニーキャストダイアローグについての端点でのエージェントが、クライアントを固定サービス−ノードロケーションにリダイレクトする（すなわち、標準的な、非エニーキャストＩＰアドレスによってアドレスされる）。
【００５５】
・クライアントは、この固定ロケーションへの制御接続を介して、サービスを取り付け、サービス転送を開始する。
【００５６】
制御およびデータ処理コンポーネントに出される要件は、大きく異なる。例えば、制御素子は、多数の短命なリクエストを処理して、リクエストを素早くリダイレクトする必要があり、サービス素子は、ストリーミング媒体のような持続性接続の保持されたロードを処理する必要がある。また、これら２つのデバイス階層についての管理要件は、失敗モードに対するシステムの感度と同様に、大きく異なる。例えば、制御素子は、ロードバランシングがサーバ選択に繰り込まれるように、サーバリソースを管理する必要がある。この点において、制御素子は、「サーバの健康状態」をモニタリングして、いずれのサーバがクライアントにリダイレクトされるかを決定し得る。例えば、サーバの健康状態は、制御素子によって間接的にモニタリングされ、受信され得る、サーバ容量、ローディング、予測されるサーバ遅延などのような様々なパラメータに基づき、サーバ選択決定を行うために用いられる。
【００５７】
図５に、特定のＩＳＰ内で、制御機能とサービス機能とがどのように分離されて、上記の要件を満たすかを表す、本発明のある実施形態を示す。この実施形態において、１つ以上のサービスノード（ＳＮ）、および１つ以上のエニーキャスト参照ノード（ＡＲＮ）のサービスクラスタ５０２は、コロ５００内で、ローカルエリアネットワークセグメント５０４に位置する。ネットワークセグメント５０４は、コロルータ５０６に結合され、その後、ＩＳＰおよび／またはインターネット５０８の残りに結合される。
【００５８】
この構成のもとに、インターネット５０８の任意のホスト５１２からのクライアントリクエスト５１０は、近接に基づくエニーキャストルーティングを用いて、最も近いＡＲＮ５１４にルーティングされる。ＡＲＮ５１４は、クライアント（経路５１６）を、本明細書中に説明した範囲の技術を用いて、候補サービスノード５１８（経路５２０）にリダイレクトする。このサービスモデルは、サービスノードがクラスタされるので、任意のクライアントロードに拡大縮小し、クラスタサイズを増大させることによって、システムがますます増大して提供されることが可能になる。さらに、ＡＲＮ自体が、層−４スイッチのようなローカルロードバランシングデバイスで、拡大縮小可能である。
【００５９】
任意の所与の時間において、ＡＲＮの１つ（例えばＡＲＮ５１４）はマスターとして指定され、残りのＡＲＮは、バックアップ５２２として指定される。この指定は、経時的に変化し得る。これらのエージェントは、個々の物理的コンポーネントとしてインプリメントされ得るか、または、全て１つの物理的デバイス内において動作し得る。この実施例ではＳＮおよびＡＲＮは単一のネットワークインターフェースを介して単一のネットワークセグメント５０４に取り付けられていると仮定するが、本システムは、これらのエージェントおよび物理的デバイスが複数のローカル−ネットワークセグメントにわたって動作するようにも、容易に一般化が可能である。各ＡＲＮは、サービス−ノードインフラストラクチャによって所有されているエニーキャストアドレススペースにも広告をルーティングすることのできる到達可能性を有しているが、広告を能動的に生成するのはマスターＡＲＮのみである。同様に、ネットワークセグメント５０４に取り付けられたＩＳＰのｃｏｌｏルータ（単数または複数）５０６は、これらの広告をリッスンしこれらの広告を伝搬させるように構成される。このルーティング情報の交換は、ＩＳＰ内において用いられるＩＧＰ（例えば、ＲＩＰ、ＯＳＰＦ等）に関わらず実行される。上記の実施例において、単一のＡＲＮが全てのエニーキャストアドレスに対するマスターとして選出され、残りのＡＲＮがバックアップとして機能する。別の実施形態において、各エニーキャストアドレスに対してマスターが選出される。これにより、ロードを複数の能動的ＡＲＮに分散させ、各ＡＲＮを、互いに素なエニーキャストアドレスの集合として機能させることが可能となる。いずれかのＡＲＮに不具合が生じると、そのエニーキャストアドレスに対して、選出プロセスが開始する。
【００６０】
本システムをブートストラップさせる際、以下の２つの主要な工程が行われる：すなわち、（１）ＡＲＮ（単数または複数）が、ＳＮクラスタ内のサービスノードの存在およびアドレスを発見しなければならない工程；および（２）ＡＲＮ（単数または複数）が、利用可能でありかつオーバーロードになっていないサービスノードを判定しなければならない工程。１つのアプローチとして、サービスクラスタ内のサービスノードのＩＰアドレスの列挙を備えるようにＡＲＮを構成するアプローチがある。あるいは、本システムでは、ローカル−エリアネットワークのマルチキャストに基づいた簡単なリソース発見プロトコルを用いることも可能であり、その場合、各サービスノードは、自身の存在を周知のマルチキャストグループ上でアドバタイズし、各ＡＲＮは、グループをリッスンして、全てのサービスノードの存在を推論する。後者のアプローチは、コンフィギュレーションのオーバーヘッドを最小化することにより、人間によるコンフィギュレーションエラーの可能性を回避する。
【００６１】
このマルチキャストを用いたリソース発見モデルを用いれば、新規のデバイスをネットワークにプラグインするだけで、システムは自動的にその新規のデバイスを用いるようになる。この技術は以下のように機能する。
【００６２】
・ＡＲＮ（単数または複数）が、周知のマルチキャストグループＧsに加入する。
【００６３】
・サービスクラスタ内のＳＮ（単数または複数）が、メッセージをグループＧsに送ることにより、自身の存在と、任意選択情報（例えば、システムロード）とをアドバタイズする。
【００６４】
・ＡＲＮ（単数または複数）が、これらのメッセージをモニタリングし、利用可能なサービスノードのデータベースを構築し、ロードの均衡などに用いられる任意選択の属性を格納および更新する。
【００６５】
・各データベースエントリは、対応するＳＮによる「更新」を必要とする。「更新」を行わないと、各データベースエントリは「タイムアウト」となり、ＡＲＮ（単数または複数）によって削除される。
【００６６】
・新規のサービスリクエストを受信した後、ＡＲＮは、データベース中の利用可能なノードのリストからサービスノードを選択して、当該ノードにクライアントを転送する。
【００６７】
サービスクラスタ中の全デバイスは単一のネットワークセグメントまたはＬＡＮ上の同じ場所に配置されている（ｃｏ−ｌｏｃａｔｅｄ）ため、ＩＰマルチキャストを用いる際、ＬＡＮの外部のまたはＬＡＮに取り付けられたルーティングエレメントに特殊なコンフィギュレーションは不要である点に留意されたい。
【００６８】
（不具合の回復）
上述してきたプロトコルの本質は、自動の不具合回復を行うように設計されているため、非常に高いレベルのサービスの利用可能性を発生させる。本システムは、ＡＲＮ不具合およびＳＮ不具合のどちらに対してもロバスト性を有する。
【００６９】
ＡＲＮはＳＮデータベースのエントリを「タイムアウト」にするため、ＳＮの不具合はサービスリクエストに用いられない。そのため、クライアントが（ユーザに対してトランスペアレントにまたはユーザとの相互作用によって）サービスに再度接続すると、サービスは、別のサービスノード上において再度開始する。ＡＲＮがそのクライアントについて永続性の状態を保持している場合、本システムは、（例えば、ＳＮの不具合が検出されて、切換えが発生した場合にユーザが２度にわたって課金されることの無いように）新規のサービスを最初から開始するのではなく、古いサービスの具体化（ｉｎｃａｒｎａｔｉｏｎ）を再開することができる。
【００７０】
ＡＲＮに不具合が発生した場合、別の問題も発生し得る。単一のｃｏｌｏ中に冗長なＡＲＮを保持することにより、以下の技術を用いて、この問題を解決することができる。
【００７１】
・各ＡＲＮが、周知のマルチキャストグループＧsに加入する；
・各ＡＲＮが、アドバタイズメッセージをグループＧsに送ることにより、自身の存在をアドバタイズする。
【００７２】
・各ＡＲＮは、能動的なＡＲＮピアのデータベースを構築し、エントリのうち、中間アドバタイズ期間よりも長い特定の構成可能な期間に従って更新されなかったエントリをタイムアウトする。
【００７３】
・最少の数で番号付けされたネットワークアドレスを有するＡＲＮ（すなわち、データベース中の残り全てのＡＲＮよりも少数のネットワークアドレスを有するＡＲＮ）は、自身をマスターＡＲＮとして選出し、エニーキャストアドレスブロックに対する到達可能性をＩＧＰを介して広告する動作を開始する。
【００７４】
従って、マスターＡＲＮに不具合が発生した場合、（単一のアドバタイズ間隔が経過した後に）バックアップのＡＲＮがこの状況をすぐに察知して、新規のマスターＡＲＮが選出される。この時点において、新規のＩＧＰルート広告の副作用として、ｃｏｌｏルータにより、エニーキャストパケットが新規のマスターＡＲＮにルーティングされる。
【００７５】
（広域アーキテクチャ）
単一のｃｏｌｏの取付け範囲内のデバイスのローカル−エリアアーキテクチャについて説明してきたが、広域アーキテクチャについて、個々のサービス−ノードクラスタを調整し、広域内において管理する方法を説明する。本発明に含まれるコンテンツのオーバーレイネットワークの実施形態を実現する広域コンポーネントは主に２つある。すなわち、
・作成元のコンテンツサイトからｃｏｌｏ内のサービスノードへの大量のデータのルーティングおよび管理を行うデータサービス。
【００７６】
・エニーキャストを用いたサービスの待ち合わせに関する問題に対する解決法。この解決法において、クライアントによってリクエストされたサービスを、作成元のマスターサイトに結合させる。
【００７７】
前者の問題の解決法−すなわち、広域を介したデータのサービスノードへの分散を信頼性および効率性を失わずに行う方法は、本開示の範囲外の内容である。例えば、ストリーミングブロードキャストネットワーク（例えば、１９９９年１月２２日に出願された「Ｓｙｓｔｅｍ  ｆｏｒ  Ｐｒｏｖｉｄｉｎｇ  Ａｐｐｌｉｃａｔｉｏｎ−ｌｅｖｅｌ  Ｆｅａｔｕｒｅｓ  ｔｏ  Ｍｕｌｔｉｃａｓｔ  Ｒｏｕｔｉｎｇ  ｉｎ  Ｃｏｍｐｕｔｅｒ  Ｎｅｔｗｏｒｋｓ」と題する係属中の米国特許出願第６０／１１５，４５４号に記載されたストリーミングブロードキャストネットワーク）を用いて、コンテンツを搬送することができる。また、コンテンツの搬送を、ネットワークニューストランスポートプロトコル（ＮＮＴＰ）等のフラッドアルゴリズムに基づいたファイル分散プロトコルによって行うことも可能である。
【００７８】
本願は、エニーキャストを用いた転送システムが利用可能なコンテンツ送達システムとインターフェースをとる様式についての記載を開示する。ＡＲＮと、ＳＮと、クライアントと、可能ならば作成元のサービスサイトまたはコンテンツサイトとの間でサービス固有の相互作用を行う新規なフレームワークが用いられている。例えば、クライアントは、ウェブリクエストをエニーキャストアドレスＡに対して開始することができ、このウェブリクエストは、アドレスＡへの到達可能性を広告している最近位のＡＲＮにルーティングされ、次いで、その最近位のＡＲＮは、当該クライアントを単純なＨＴＴＰ転送メッセージと共に選択されたＳＮに転送するか、または、そのウェブリクエストは、ＡＲＮから直接サービスされ得る。
【００７９】
エニーキャストを用いた転送システムの一実施形態において、ＡＲＮは、ＳＮに対し、未改変の既存のクライアントからＳＮに搬送することが不可能なアプリケーション固有の情報について「予備知識を与える（ｐｒｉｍｅ）」ことができる。ここで、ＡＲＮはＳＮに接触し、特定のポートＰに結合された特定の状態Ｑを取り付ける。ポートＰは、ＳＮによって割り当てられ、ＡＲＮに返送され得る。その後、ポートＰを介してクライアントをＳＮに転送することが可能となり、これにより、未改変のクライアントは、この新規の接続を介して状態Ｑを暗黙的に搬送する。例えば、Ｑは、特定のストリーミング媒体フィードについてサービスノードが加入すべき広域のブロードキャストチャンネルアドレスを表し得る。未改変のクライアントはＣＢＢインフラストラクチャに対して直接的なプロトコル適合性を持たないため、当該ダイアログにおけるクライアントを用いる必要無く、適切なチャンネル加入を状態転送Ｑによって搬送する。
【００８０】
既に取り付けられた大型のクライアント（例えば、ウェブブラウザならびにストリーミング媒体プレーヤおよびサーバ）を改変する必要が無いようするために、クライアントとＳＮとの間の相互作用を、既存のサービス固有のプロトコル（例えば、ウェブ用のＨＴＴＰ、ストリーミング媒体プロトコル用のＲＴＳＰ、または他のベンダー所有のプロトコル）を用いて行う。
【００８１】
クライアントリクエストが開始し、ＡＲＮによってインターセプトされた後、特定の広域サービスを呼び出して、ＣＢＢからコンテンツを引き出させて、ローカルサービスノードに入れさせなければならない（ただし、当該コンテンツが既に存在しない場合）。上述したように、エニーキャストを繰り返し用いると、不具合が生じる。そのため、ＤＮＳシステムを用いて、エニーキャストアドレスとサービスとの間のマッピングを、スケーラブルかつ分散した様式で再度行う。
【００８２】
例えば、コンテンツプロバイダ「ａｃｍｅ．ｃｏｍ」に関するウェブオブジェクトのキャッシュをサポートすることが所望され、かつ、ＣＢＢがａｃｍｅ．ｃｏｍに１０．１．１８．２７のエニーキャストアドレスを割り当てていると仮定した場合、マスターサーバに対するポインタを、以下のようなＳＲＶリソースレコードと共にＤＮＳとして構成することができる。
【００８３】
ａｎｙｃａｓｔ−１０−１−１８−２４．ｈｔｔｐ．ｔｃｐ．ｃｂｂ．ｎｅｔ  ＳＲＶ  ｗｗｗ．ａｃｍｅ．ｃｏｍ
サービスノードが自身のエニーキャストアドレス１０．１．１８．２７に対するクライアント接続リクエストをＴＣＰポート８０（すなわち、標準的なＨＴＴＰウェブポート）上で受信した場合、そのサービスノードは、（ａｎｙｃａｓｔ−１０−１−１８−２７．ｈｔｔｐ．ｔｃｐ．ｃｂｂ．ｎｅｔ）についてＤＮＳＳＲＶレコードに問い合わせをして、このサービスのマスターホストがｗｗｗ．ａｃｍｅ．ｃｏｍであることを知る。この知識はローカルにキャッシュすることができ、リクエストされたコンテンツがｗｗｗ．ａｃｍｅ．ｃｏｍからフェッチされた場合、そのコンテンツもローカルにキャッシュされ得る。その後、同じコンテンツに関する同じエニーキャストアドレスに対して次にリクエストが有った場合、そのリクエストをローカルに満たすことが可能である。ｗｗｗ．ａｃｍｅ．ｃｏｍに格納されたコンテンツはａｎｙｃａｓｔ−１０−１−１８−２７．ｈｔｔｐ．ｔｃｐ．ｃｂｂ．ｎｅｔを明示的に参照するリンクを有することができ、または、サイトは、以下のようなよりユーザに親しみ易い名称（例えば、ｗｗｗ−ｃｂｂ．ａｃｍｅ．ｃｏｍ。これは、エニーキャスト名称のＣＮＡＭＥに過ぎない）を用いることもできることに留意されたい：
ｗｗｗ−ｃｂｂ．ａｃｍｅ．ｃｏｍ  ＣＮＡＭＥ  ａｎｙｃａｓｔ  １０−１−１８−２７．ｈｔｔｐ．ｔｃｐ．ｃｂｂ．ｎｅｔ
やはりａｃｍｅ．ｃｏｍから来る非常に大規模なストリーミング媒体ブロードキャストをサポートすることが望まれる別の例について考える。マスターウェブサーバに加えて、ストリーミング媒体ＵＲＬをブロードキャストチャンネルアドレスにマッピングする「チャンネル割当てサービス」（ＣＡＳ）のロケーションを知る必要も出てくる。この「チャンネル割当てサービス」において、チャンネルアドレスは、６０／１１５４５４に記載されているようなアプリケーションレベルのマルチキャストグループに類似する。この場合、ＣＡＳを指向するＳＲＶリソースレコードについてＤＮＳに問い合わせて、以下の形態を有し得るレコードを入手する。
ａｎｙｃａｓｔ−１０−１−１８−２４．ｃａｓ．ｔｃｐ．ｃｂｂ．ｎｅｔ  ＳＲＶ  ｃａｓ．ａｃｍｅ．ｃｏｍ
ＡＲＮがストリーミングメディアＵＲＬに対するクライアント接続リクエストを受け取ると、ＡＲＮはｃａｓ．ａｃｍｅ．ｃｏｍをクエリしてそのＵＲＬをブロードキャストチャネルにマップし（および将来のクライアントリクエストのために結果を局所的にキャッシュし）、今やそのチャネルアドレスが既知となったのでＣＢＢを介してそのチャネルに加入する。
【００８４】
このようにＤＮＳにおけるサービスバインディング（ｂｉｎｄｉｎｇ）を格納することによって、任意のエニーキャストサービスノードは、動的および自動的に、特定のエニーキャストアドレスに結合された特定のサービスを発見し得る。これによって、一般のエニーキャストに基づくサービスランデブー機構およびコンテンツブロードキャストネットワークの構成および管理が大きく簡素化される。
【００８５】
このようにＤＮＳ  ＳＲＶレコードは、サービスネームから対応のサーバアドレスへのマッピングを格納する。しかし、ＡＲＮが名付けられたサービスの簡単なリストよりも多くの情報を必要とする場合があり得る。さらなる情報は、サービスノード選択アルゴリズムを特定し得るか、またはサービスノードセットアッププロシージャを特定し得る。これらの場合、名付けられたサービスに対する情報は、ディレクトリサーバ（ＬＤＡＰまたはＸ．５００など）中またはウェッブサーバのネットワーク上に格納され得る。ＤＮＳと比較して、これらのサーバはデータ表現においてより大きな柔軟性および拡張性を提供する。
【００８６】
（リダイレクトアルゴリズム）
上記の構成要素およびシステムアーキテクチャが得られるとして、本発明の１実施形態を提供して、どのようにしてエンドホストがサービス−ノードインフラストラクチャからサービスフローまたはトランザクションをステートフルエニーキャスティングを使用して呼び出すかを明示する。
【００８７】
・ユーザが、例えば、ＵＲＬとして表されるウェッブリンク上をクリックすることによって、コンテンツリクエストを開始する。
【００８８】
・クライアントがそのＵＲＬが参照するリソースのＤＮＳネームを決定する。このネームは、最終的に当局によって管理されたエニーキャストアドレスを決定する（例えば、ｗｗｗ．ａｃｍｅ．ｃｏｍは、ａｎｙ−１０−１−１８．２７．ｃｂｂ．ｎｅｔに対するＣＮＡＭＥである）。
【００８９】
・クライアントは、そのエニーキャストアドレスを使用して正常なアプリケーション接続を開始する（例えば、ポート８０上のＴＣＰ上のＨＴＴＰを使用したウェッブページリクエスト、またはポート５５４上のＴＣＰ上のＲＴＳＰ使用したストリーミングメディアリクエスト）。
【００９０】
・上記のエニーキャストルーティングインフラストラクチャの副作用として、クライアントのパケットは、そのアドレスへの到達性を広告する最も近いＡＲＮにルーティングされ、これによりそのＡＲＮに接続を開始する。ＡＲＮは、ポート８０上のウェッブリクエストなどの各構成されたサービスに対するリクエストを受理するように用意される。
【００９１】
・この時点で、データは利用可能であり、かつトランザクションされるべきものであれば、そのＡＲＮはコンテンツを用いて直接応答するか、または以下のようにリクエストするクライアントをサービスノードにリダイレクトする：
・ＡＲＮがその関連サービスクラスタから候補サービスノードＳを選択する。選択決定は、上記のようにローカルモニタリングプロトコルから保持されるロードおよびアベイラビリティ情報に基づいてなされ得る。
【００９２】
・ＡＲＮは、クライアントＣがＳにアタッチする準備において必要に応じてアプリケーション別ダイアログをＳを用いて行う。例えば、ライブブロードキャストストリーミングメディアの場合、ＡＲＮは、ブロードキャストチャネルを示し得る。Ｓは、そのブロードキャストチャネルに基づいて、リクエストを介してＣＢＢオーバーレイネットワークに同調する必要がある。このダイアログの一部として、ＳはＣをＳへ適切にリダイレクトするために必要な情報をＡＲＮに戻し得る。この情報が存在するかどうかおよびその情報の性質はリクエストされた特定のサービスに対して特定される。
【００９３】
・ＡＲＮは、元々のクライアントリクエストに、クライアントＣを上記選択されたサービスノードＳに向けるリダイレクトメッセージを用いて応答する。
【００９４】
・クライアントＣは、クライアントに特異的な方法でＳにコンタクトし、所望のサービスに関連するフローまたはコンテンツトランザクションを開始する。例えば、クライアントは、ストリーミングメディアコントロールプロトコルＲＴＳＰを使用してＳに接続してＲＴＰ上でストリーミングメディアのライブ転送を開始する。
【００９５】
（アクティブセッションフェイルオーバー）
上記のステートフルエニーキャスティングリダイレクトスキームの１つの欠点は、選択されたサービスノードが何らかの理由で失敗したならば、そのノードが与えられたすべてのクライアントはサービスの途絶を受けることとなる。クライアントがストリーミングメディアフィードのような持続するサービスを呼び出している場合、そうでなければビデオは停止し、そしてクライアントはリトライするよう強いられる。別の実施形態において、クライアントは、ユーザがサービスの低下に気が付く前にサービスノードの失敗を検出し、そしてリダイレクトプロセスの再呼び出しするように変更され得る。このプロセスを本明細書中で「アクティブセッションフェイルオーバー」と呼ぶ。
【００９６】
図６は、本発明にしたがって構築されたデータネットワーク８００の一部を示す。データネットワーク８００は、アクティブセッションフェイルオーバーがどのように動作してコンテンツを中断なしにクライアントに送達するかを明示するネットワークトランザクションを示す。
【００９７】
まず、クライアント８０２は、サービスリクエスト８２０をエニーキャストアドレスＡに送信する。サービスリクエスト８２０はＡＲＮ８０４にルーティングされる。サービスリクエスト８２０は、ＣＢＢ８０３から生じたコンテンツをリクエストする。ＡＲＮ８０４はそのリクエストを復号して、クライアント８０２に送信されるべきアプリケーション別リダイレクトメッセージを決定する。ＡＲＮ８０４によって送信されたリダイレクトメッセージ８２２は、クライアント８０２をサービスノード８０６にリダイレクトする。次に、クライアント８０２は、リクエスト８２４を送信して、アプリケーション別プロトコル（例えば、ＲＴＳＰなど）を介してコンテンツ（例えば、ストリーミングメディアフィードなど）を得る。このアプリケーション別プロトコルによって、ノード８０６は、クライアントリクエスト中のチャネル記述情報を使用してチャネル加入メッセージ８２６をサービスノード８０８に送信することによってストリーミングメディアチャネルを広い領域にわたってリクエストする（例えば、６０／１１５４５４参照）。その結果、コンテンツはパス８２８によって示されるようにサービスノード８０８からクライアントへフローする。
【００９８】
ここで、サービスノード８０６が失敗すると仮定する。クライアント８０２は、サービスにおける途絶に気が付き、そして前のセクションにおいて記載されたステートフルエニーキャストプロシージャを再呼び出しすることによって反応する：サービスリクエスト８３０がエニーキャストアドレスＡに送信され、そしてＡＲＮ８０４によって受け取られる。ＡＲＮ８０４は、リダイレクトメッセージ８３２を用いて応答し、クライアントを新しいサービスノード８１０にダイレクトする。ここで、クライアントは、８３４に示すように、サービスノード８１０から新しいサービスフィードをリクエストし得る。サービスノード８１０は、８３６に示されるように加入メッセージをノード８０８に送信し、そしてコンテンツは、８３８に示されるように再度クライアントへフローする。クライアントがストリーミングメディア信号をユーザへ提示する（ネットワーク遅延のばらつきに対応するために一般にとられる方法）前に十分なバッファリングを利用すると仮定すると、この全体のプロセスは、サービスが途絶することなく進行し得る。クライアントがアタッチする場合、クライアントはパケット再送信リクエストをサービスノード８１０に送信して、ストリームを適切に位置付け、そしてセッションフェイルオーバープロセス中に失われたパケットだけを再送信する。
【００９９】
例えば、クライアントが一時的なネットワーク停止のためにサービスノード８０６の失敗を誤って推測する可能性があり得る。この場合、クライアントは単にリダイレクトメッセージ８３２を無視し得、そしてサービスノード８０６からサービスを受け取ることを継続する。
【０１００】
（広域オーバーフロー）
上記のサービスランデブー機構の１つの起こりうる問題は、あるサービスノードの設定は、あまりにも多くのクライアントがその設定にルーティングされるがために容量を使い尽くし得ることである。この問題は、リダイレクトシステムが、オーバーロードの場合にクライアントサービスリクエストを広域にわたってリダイレクトし得る実施形態において解決され得る。例えば、ローカルサービスノードのすべてが容量いっぱいに稼動している場合、リダイレクタは非ローカルサービスノードを選択して、そしてそれにクライアントをリダイレクトし得る。次いでこのリダイレクト決定は、ネットワークおよびサーバ健康測定によって影響され得る。このアプローチは、リダイレクタは、ピリオド「プローブ」メッセージを候補サーバに送信して、ネットワーク経路遅延を測定する。リダイレクタは通常リクエストするクライアントに近いので、これらのリダイレクタ−サーバ測定は、クライアントと候補サーバとの間の対応ネットワーク経路の正確な推定を表す。
【０１０１】
この実施形態において、広域リダイレクトを行うための３つのステップがある：
・ＡＲＮは、候補サービスノードを発見する。
【０１０２】
・ＡＲＮは、各サービスとそれ自身との間でネットワーク経路特性を測定する。
【０１０３】
・ＡＲＮは、サービスノードにそれらの健康についてクエリする。
【０１０４】
上記ステップから情報が得られた場合、ＡＲＮは、いずれのリクエストするクライアントに対しても最高品質のサービスを得られる可能性のあるサービスノードを選択することができる。そうするために、各ＡＲＮは、いくつかの適格なサービスノードについてのロード情報を含む情報データベースを保持する。ＡＲＮは、その情報データベースを調べて、各クライアントリクエストに対して最も得やすいサービスノードを決定する。ＡＲＮは、そのロード情報を保持するために、ＡＲＮは、ネットワーク経路およびサービスノードを積極的にプローブし得る。あるいは、サービスノードはネットワークロードおよび内部ロードをモニターし、そしてロード情報をそれぞれのＡＲＮへリポートし得る。
【０１０５】
ローカルエリアロードバランシングを有効にするために、各ＡＲＮは、いくつかの近傍サービスノードのＩＰアドレスを用いて構成される。ＡＲＮは、それらのサービスノードについてのロード情報を保持する。しかし、このローカルエリアアプローチは、ロードが地理的に集中すると悪化する。なぜなら、ＡＲＮは、その近傍のサービスノードのすべてを完全にロードし、そしてそれによりそのクライアントからのさらなるサービスリクエストを拒否し得るからである。これは、ローカルエリアをちょうど越えるいくつかのサービスノードが十分に利用されていなくても起こり得る。
【０１０６】
本発明による広域ロードバランシングは、上記の問題を克服する。広域ロードバランシングにおいて、各ＡＲＮは、ネットワーク中のすべてのサービスノードのＩＰアドレスを用いて構成され、すべてのサービスノードに対するロード情報を含む情報データベースを保持する。あるいは、ＡＲＮはフラッディングアルゴリズムを使用してロード情報を交換する。
【０１０７】
本発明の別の実施形態は、可変域ロードバランシングと呼ばれるスキームを使用する。このスキームを用いると、各ＡＲＮは、いくつかの適格なサービスノードに対する情報データベースを保持し；そして適格なサービスノードの数は、ローカルロードとともに増加する。すなわち、近傍サービスノードがそれぞれの容量に近づくにつれ、ＡＲＮはその情報データベースに、ＡＲＮの現在の範囲をちょうど超えるいくつかのサービスノードについてのロード情報を付加する。以下に、漸次遠位サービスノードを発見するために使用され得る２つの異なる方法を提供する。
【０１０８】
第１の方法において、ＡＲＮは、何個かの隣接するサービスノードのＩＰアドレスを与えられる。サービスノードが仮想オーバーレイネットワークを形成すると仮定されるので、増加方向に離れたサービスノードを識別するため、ＡＲＮは、近傍のサービスノードのリストについて、これらのサービスノードに単に問い合わせる。このアプローチを、「オーバーレイネットワーククローリング」と呼んでもよい。
【０１０９】
第２の技術において、各ＡＲＮおよび各サービスノードは、階層ネーム空間からのマルチパートネームを割り当てられる。２つのサービスノードのネームが与えられた場合、ＡＲＮは、最長のパターンマッチを用いて、いずれが最も近いかを判定できる。例えば、右から左への最長パターンマッチを用いて、
ａｒｎ．ｓａｎｊｏｓｅ．ｃａｌｉｆｏｒｎｉａ．ｐａｃｉｆｉｃｃｏａｓｔ．ｕｓａ．ｎｏｒｔｈａｍｅｒｉｃａ
というネームが与えられたＡＲＮネームは、
ｓｎ．ｏｒｌａｎｄｏ．ｆｌｏｒｉｄａ．ａｔｌａｎｔｉｃｃｏａｓｔ．ｕｓａ．ｎｏｒｔｈａｍｅｒｉｃａ
という名前のサービスノードよりも
ｓｎ．ｓｅａｔｔｌｅ．ｗａｓｈｉｎｇｔｏｎ．ｐａｃｉｆｉｃｃｏａｓｔ．ｕｓａ．ｎｏｒｔｈａｍｅｒｉｃａ
という名前のサービスノードに近いと判定される。各ＡＲＮは、全てのサービスノードネームおよびそれらの対応するＩＰアドレスのディレクトリを検索することができる。このディレクトリは、ＤＮＳまたは類似の分配型ディレクトリ技術を用いて実行され得る。この可変領域負荷均衡化スキームは、クライアントを増加方向に離れたサービスノードにリダイレクトすることにより地理的に集中された負荷を処理する。このスキームは、ＡＲＮからサービスノードへの関係の数を最小化することにより、拡張性（ｓｃａｌａｂｉｌｉｔｙ）の問題を解決する。つまり、ＡＲＮは、近傍のクライアント負荷を処理するのに要求されるサービスノードの数をモニタするのみである。概して、所与のノードからＮ回ホップした距離にあるノードの数はＮ倍になるので、さらに、ＡＲＮが候補サービスノードを精査する速度は、距離に逆比例するように調節される。
【０１１０】
図７は、本発明に基づいて構成されたデータネットワーク９００の一部を示す。データネットワーク９００は、３つの接続されたローカルネットワーク９０２、９０４、および９０６を含む。本発明の一実施形態において説明するように、ネットワーク９００は、広域オーバーフローを提供するように構成される。
【０１１１】
ローカルネットワーク９０２は、関連する情報データベース（ＤＢ）９１０を有するＡＲＮ９０８（リダイレクタ）を含む。また、サービスノード９１２および９１４がローカルネットワーク９０２に含まれる。情報コンテンツ９２８をクライアント（Ｃ）９１６、９１８、９２０、９２２、９２４、および９２６に提供するサービスノードを示す。
【０１１２】
ネットワーク９０４および９０６は、ＡＲＮ９３０、９３２、情報データベース９３４、９３６、ならびにサービスノード９３８、９４０、９４２、および９４４をそれぞれ含む。これらのサービスノードは、情報コンテンツ９２８を多数の他のクライアントに提供する。
【０１１３】
ＡＲＮ９０８は、そのローカルサービスノード９１２および９１４のネットワークローディング特性をモニタする。このローディング情報は、ＤＢ９１０内に格納される。ＡＲＮは、また、他のサービスノードのローディング特性をモニタし得る。ある実施形態において、ＡＲＮは、互いにローディング情報を交換する。例えば、サービスノード９３８および９４０のローディング特性は、ＡＲＮ９３０によってモニタされ、ＤＢ９３４に格納される。ＡＲＮ９３０は、矢印９５４に示すように、このローディング情報をＡＲＮ９０８と交換し得る。別の実施形態において、ＡＲＮは、他のサービスノードをアクティブに精査して、それらのローディング特性を判定し得る。その後、これらの特性は、将来使用するために使用される。例えば、ＡＲＮ９０８は、矢印９５６に示すようにサービスノード９４４を精査し、矢印９５８に示すようにサービスノード９４２を精査する。したがって、ＡＲＮが、ローカルネットワーク内およびワイドエリア上の両方に配置されたサービスノードのローディング特性を判定し得るいくつかの方法が存在する。
【０１１４】
いくつかの時点において、クライアント９５０は、情報コンテンツ９２８の受け取りを試みる。クライアント９５０は、エニーキャストリクエスト９５２をネットワーク９０２に送信し、ネットワーク９０２において、エニーキャストリクエスト９５２は、ＡＲＮ９０８によって受け取られる。ＡＲＮ９０８は、クライアント９５０を、ローカルサービスノード（９１２，９１４）の一方にリダイレクトし得る。しかし、ＡＲＮ９０８に関連するＤＢ９１０は、ローカルサービスノードが、要求されたサービスをクライアント９５０に提供することができないかもしれないことを示す。ＡＲＮ９０８は、情報ＤＢ９１０を用いて、クライアント９５０からの要求を処理するためにはいずれのサービスノードが最も適切かを判定する。選択されたサービスノードは、ＡＲＮ９０８を有するローカルネットワーク内のサービスノードに限定されない。ワイドエリア上の任意のサービスノードが選択され得る。
【０１１５】
ＡＲＮ９０８は、サービスノード９４２がクライアント９５０からの要求に対してサービスを行う必要があると判定する。ＡＲＮ９０８は、リダイレクトメッセージ９６０をクライアント９５０に送信し、それにより、クライアントをサービスノード９４２にリダイレクトする。クライアント９５０は、矢印９６２に示すように、ＴＣＰのような転送層プロトコルを用いて要求をサービスノード９４２に送信する。サービスノード９４２は、矢印９６４に示すように、クライアントに、要求された情報コンテンツを提供することによって応答する。
【０１１６】
したがって、情報データベースおよびサービスノードを精査してローディング特性を得る能力を用いた場合、参照ノードは、本発明に基づいて、広域負荷バランシングを達成することができる。
【０１１７】
（技術的拡張）
このセクションは、上記実施形態に対する技術的拡張を含む本発明のさらなる実施形態を説明する。
【０１１８】
（ラストホップマルチキャスト）
ＩＰマルチキャストの使用は、広域配信コンテンツの「ラストホップ」配信における転送最適化として利用され得る。したがって、クライアントがエニーキャスト要求を発行することが可能であり、その結果、マルチキャストグループに含まれるようにリダイレクトされる。
【０１１９】
図８は、ＩＰマルチキャストを用いる本発明の一実施形態を示す。コンテンツプロバイダ６００は、３つのサービスノードＳＮ０〜ＳＮ３を提供して、アプリケーションレベルマルチキャストツリー６０４を介して情報コンテンツ６０２を提供する。クライアント６０６は、上述のように、サービスフィードを要求し、通路６０８に示すように、ＡＲＮによって受け取られる。ＡＲＮは、要求をサービスノードＳＮ０にリダイレクトして、通路６１０に示すようにデータ転送を開始する。しかし、各クライアントについて独立したデータチャネルを開始するのではなく、サービスノードは、特定のマルチキャストグループ６１２（グループＧと呼ぶ）に参加し、情報コンテンツを受け取ることを（制御接続を介して）クライアントに命令する。その後、クライアントはマルチキャストグループに参加し、サービスノードＳＮ０は情報コンテンツをローカル環境内のグループに送信する。
【０１２０】
図示のように、マルチキャストトラフィックは、サービスノードＳＮ０からそのフローを受け取る全てのクライアントへの配信パス内のファンアウトポイントにおいてのみ複製される。同時に、サービスノードＳＮ０は上流のサービスノードＳＮ１にコンタクトして、ユニキャストコネクション上の情報コンテンツを受け取る。この様態で、コンテンツは、ネットワークインフラストラクチャ全体を介したマルチキャストを可能にすることを必要とせずに、全ての関心のある受信者にコンテンツを配信する。
【０１２１】
（送信者添付物）
上のように説明したシステムは、エニーキャストルーティングに依存して、クライアント要求を最も近いサービスノードにルーティングした。同様に、エニーキャストは、コンテンツの生成された位置にあるサーバを最も近いサービスエントリポイントに橋渡しするために使用できる。コンテンツサーバが明らかに配信インフラストラクチャへと構成される場合、本明細書中で説明するシステムは、サービスインスタレーションを広域配信インフラストラクチャに登録し、接続するように適合され得る。
【０１２２】
図９は、サービスインスタレーションを広域配信インフラストラクチャに登録し、接続するように適合された本発明の実施形態７００を示す。サービスノードＳＮ０は、近くのサーバＳからの新たな広域配信チャネルをコンテンツ広域配信ネットワーク７０４に差し込むことを望む。サービスノードＳＮ０は、エニーキャストアドレスを用いてサービスクエリ７０６を送信する。サービスクエリは、ＳＮ０からの新たなＩＰトンネルについてのエンドポイントとして用いるのに最も利用可能な、広域配信ネットワーク７０４内のサービスノードのアイデンティティを要求する。サービスクエリは、エニーキャストアドレスを運び、最も近くのＡＲＮ（この場合はＡ１）にルーティングされる。Ａ１は最も利用可能なサービスノードを選択し、新たなチャネルがＳＮ０を介して利用可能であることを示す、広域配信ネットワーク７０４内のチャネルデータベースを更新し得る。この場合、Ａ１はＳＮ１を選択し、応答７０８をＳＮ０に送信する。この応答は、新たなＩＰトンネリング回路７０２を構築して、ノードＳＮ１にサービスを行うことを、ＳＮ０に命令する。
【０１２３】
この送信者添付物システムは、オーバーレイ広域配信ネットワークが、追加のサーバに達するようにダイナミックに拡大されることを可能にする。この送信者添付物システムは、既に説明したクライアント添付物システムとともに使用される場合、クライアント−サーバトラフィックを連続する１つ以上のトンネリング回路上にダイナミックにマッピングし、１つのトンネリングエンドポイントが最も近いクライアントであり、１つのトンネリングエンドポイントが最も近いサーバであるような、包括的なアーキテクチャを提供する。マッピングは、クライアントアプリケーションおよびサーバアプリケーションに明らかであり、且つそれぞれのアクセスルートに明らかな方法で実行される。
【０１２４】
（複数のマスター）
本明細書中に説明するさまざまな実施形態において、マスターＡＳのみが、ドメイン間ルーティングプロトコルを介してエニーキャストアドレスブロックを宣伝する。このスキームには２つの拡張がある。第１に、システムは、複数のマスターＡＳの間のエニーキャストアドレス空間を分割することにより、複数のマスターＡＳが共存できるように拡張され得る。つまり、本明細書に記載のシステムの複数の例は、それらがそれぞれのエニーキャストブロックに別々のアドレス空間を用いる限り、十分に機能し、互いに干渉しない。第２に、システムは、複数のマスターＡＳが同じまたは部分的に重なり合ったアドレスブロックを宣伝できるように拡張され得る。この場合、最小距離のエニーキャストルーティングは、ドメイン内ルーティングレベルおよびドメイン間ルーティングレベルの両方で動作する。例えば、ＢＧＰを介して同じエニーキャストブロックを外部に宣伝する北米のマスターＡＳと欧州のマスターＡＳとが存在し得る。その後、任意のクライアントから送信されてきたパケットは、いずれか近い方のマスターＡＳに送信され、一旦ＡＳの中に入ると、パケットは、必要であれば、そのＡＳ内の最も近いサービスノードにルーティングされるか、または、ワイドエリア上をリダイレクトされる。
【０１２５】
本発明は、仮想オーバーレイ広域配信ネットワークに基づくコンテンツ配信のための包括的なリダイレクトシステムを提供する。上記方法および実施形態が本発明の範囲から逸れることなく修正または組み合わせ可能であることは、当業者に明らかである。したがって、本明細書中の開示内容および記載は、以下の請求の範囲に記載の本発明の範囲の例示を目的としたものであって、本発明の範囲を限定する意図はない。
【図面の簡単な説明】
【図１】  図１は、インターネットの接続性の一部分を構成する典型的なコンポーネントおよび相互接続の一例を示す。
【図２】  図２は、典型的なオーバーレイＩＳＰモデルを示す。
【図３】  図３は、本発明によるエニーキャストルーティング方式を実施するために用いられるネットワーク部分３００を示す。
【図４】  図４は、ドメイン間エニーキャストルーティングを達成するように構成されたマスターネットワークおよび関連ネットワークを示す。
【図５】  図５は、本発明内に含まれる制御およびサービス機能がいかに特定のＩＳＰ内で分離されるかを示す。
【図６】  図６は、アクティブセッションの不良の回復（ｆａｉｌｏｖｅｒ）を実施するために、本発明によって構築されるデータネットワークの一部分を示す。
【図７】  図７は、広域のオーバーフローを実施するために、本発明によって構築されるデータネットワークの一部分を示す。
【図８】  図８は、本発明によるＩＰマルチキャストの使用を示す。
【図９】  図９は、登録し、かつ、サービスブロードキャストネットワークインフラストラクチュアにサービス設備を接続するように適合された、本発明の一実施形態を示す。
【図１】
0003807981.tif 000002
【図２】
0003807981.tif 000003
【図３】
0003807981.tif 000004
【図４】
0003807981.tif 000005
【図５】
0003807981.tif 000006
【図６】
0003807981.tif 000007
【図７】
0003807981.tif 000008
【図８】
0003807981.tif 000009
【図９】
0003807981.tif 000010