JP2005537687A5 - - Google Patents

Description

構成可能な適応型広域トラフィック制御および管理

本特許文献には著作権の保護を受ける情報が含まれる。本著作権所有者は、アメリカ合衆国において複製が行われるとき、何人が行う本特許文献または本特許のファクシミリによる複製に対しても異議を申し立てない。しかしながら特許商標庁のファイルまたは記録については別様に著作権上の権利を保留するものとする。

本発明の態様はネットワークトラフィックの管理に関する。本発明の別の態様は、インターネットなどのネットワークにおける構成可能な適応型広域トラフィックの制御と管理とに関する。

インターネットによるトラフィック量が大きくなるにつれて、ウェブコンテンツとアプリケーションのプロバイダは、高いトラフィック負荷の下で良好なエンドユーザ経験を維持するために、広範囲にわたる別個の位置に置かれた複数のサーバからのコンテンツの配信がますます必要となる。このことによって、いくつかの困難な挑戦すべき課題が生じることになるが、中でも、以下の課題が挙げられる。即ち、１以上の個々のサーバの故障に直面した際にこのような複数サーバシステムのフォールトトレランスを保証する方法と、経済上、契約上あるいは別の理由のために課せられる重要なコンテンツプロバイダポリシーの制約条件に基づいて個々のサーバへエンドユーザからの要求を分散する方法を制御する方法と、ネットワーク状態が変化したときエンドユーザが経験するような高いパフォーマンスを保証する方法と、である。

本発明は、構成可能な規則のセットに基づいて、（インターネットなどの）ネットワークトラフィックを分散する手段を提供することによりこれらの問題並びにその他の問題を解決するものである。これらの規則は以下の重要なファクタを考慮に入れるように構成することが可能である。重要なファクタとは、サーバの利用可能性と、本発明を配備するコンテンツプロバイダの特定の要件（地勢、ＩＰアドレス空間における位置、負荷共有などに基づく分散など）と、ネットワーク待ち時間の測定を含む、任意の所定時点におけるネットワーク（インターネット）の状態と、である。

これらの規則は、一体として、インターネットコンテンツとアプリケーションのプロバイダへ非常にきめ細かなレベルのネットワークインターネットトラフィック制御を提供するものであり、これによってプロバイダは、従来方式のウェブサーバおよびミラー化されたサーバファームとにより提供されるエンドユーザ経験を上まわるエンドユーザ経験（要求解決のスピードと、関連するダウンロード時間と、サーバの利用可能性とにより測定される）の劇的改善を図ることが可能となる。

本発明に対する多くの潜在的用途が存在する。１つの用途として、単一の組織が管理する１セットの指定サーバ向けに専らトラフィックを送るスタンドアローン型サービスの提供がある。本発明は、例えば、１以上の指定された宛先が、組織の制御の外側にあるサーバ（またはサーバのコレクション）を参照することができるようなさらに一般的な利用も可能である。後者の場合、例えば、潜在的宛先としてコンテンツ配信ネットワーク（ＣＤＮ）並びにローカルな負荷−バランス用サーバが含まれる。コンテンツ配信ネットワーク自体のＤＮＳ（ドメインネームサービス）のコンポーネントを提供するために本発明を利用することが可能である。本発明は加入者向けサービスとして配備することが可能である。あるいは、加入者自身が直接利用するソフトウェアとして展開することが可能である。

図面と関連して詳細に記載する実施形態例に関して本発明をさらに説明する。これらの実施形態は、本発明を限定しない実施形態例であり、全ての図面において、同様の参照番号は同様の部分を表すものとする。

詳細な実施例と関連して以下本発明について説明する。多種多様の形態で本発明を具現化できることが明らかになるが、これらの形態のいくつかは、開示された実施形態の形態とはきわめて異なるものとなる場合もある。したがって、本願明細書に開示された具体的な構造および機能の細部は単に典型的なものであり、本発明の範囲を限定するものではない。

本発明を配備できる複数の様々なシナリオが存在するが、本説明は、記載を明瞭にするために、また、専ら例示を旨として、コンテンツプロバイダまたはアプリケーションプロバイダのために、サードパーティがＤＮＳサービスを提供するシナリオに焦点を合わせるものである。

図１は、本発明の種々の実施形態による高レベルのフレームワークまたはシステム１００を示すものである。加入者１０２は、１以上のサーバグループ１０６−１〜１０６−ｋ（まとめて１０６）から構成される加入者サーバネットワーク１０４を介してコンテンツを提供する。

本説明で用いられているように、本発明の種々の実施形態によるフレームワークでは、以下の３つのグループのユーザが想定されている。即ち、インターネットを利用してコンテンツおよび／またはアプリケーションにアクセスすることを望むエンドユーザと、管理対象コンピュータネットワーク上でサービスを提供し、サポートする通信事業者と、エンドユーザの要望をサポートするのを助けるために通信事業者のサービスに加入する加入者（通常コンテンツおよび／またはアプリケーションプロバイダ）とである。

エンドユーザ、通信事業者、加入者という用語は、上記３つの役割を区別するためにこの本説明を通じて使用される。ただし、単一のエンティティにより２以上の役割が行われる多くのシナリオが存在する。このようなシナリオが本発明により想定されている。

個々のサーバグループ１０６は、サーバの１以上の層を含むサーバ階層に対応することができる。例えば、サーバ階層の第１層は、１以上の一次サーバを含むことができ、サーバ階層の第２層は、第１層の一次サーバが正しく機能できない場合に使われる１以上のオーバーフローサーバを備えることができる。一般に、ｊ番目のサーバグループの場合、サーバグループ１０６−ｊの第１層の一次サーバは１０８−ｊと表示され、サーバグループ１０６−ｊの第２層のオーバーフローサーバは１１０−ｊと表示される。

サーバグループ内の個々のサーバは、クライアントからなどの要求に応答してリソースを提供する任意の処理プロセスまたは処理プロセスのコレクションである。サーバはいずれの既製のウェブサーバであってもよい。実施形態によっては、サーバがアパッチサーバやネットスケープコミュニケーション社のサーバなどのようなウェブサーバであるものもある。

クライアント１１２は、加入者からコンテンツを取得するために、加入者サーバネットワーク１０４にアクセスする。コンテンツには、ビデオデータおよび音声データ等を含む任意の種類のデータが制限なしで含まれる。このアクセスを行うために、クライアント１１２のユーザはユニバーサルリソースロケータ（"ＵＲＬ"）などのリソースロケータをクライアント１１２のブラウザ１１４に入力する。ＵＲＬはネットワーク上のリソース（情報、データファイルなど）の所在位置を指定する。ＵＲＬは、Ｔ． Ｂｅｒｎｅｒｓ−Ｌｅｅらのユニフォームリソースロケータ（ＵＲＬ）（ネットワーク作業グループ、コメント要求：１７３８、カテゴリ：トラック規格、１９９４年１２月："ｈｔｔｐ：／／ｄｓ．ｉｎｔｅｒｎｉｃ．ｎｅｔ／ｒｆｃ／ｒｆｃ１７３８．ｔｘｔ"，）に詳細に定義されている。これは本願明細書で参照により援用されている。ＵＲＬは、以下のフォームを有する：スキーム：／／ｈｏｓｔ［：ｐｏｒｔ］／ｕｒｌ−ｐａｔｈ。この場合、スキームは"ファイル"（ローカルなシステム上のファイルを表す）や、"ｆｔｐ"匿名ＦＴＰファイルサーバ上のファイルを表す）や、"ｈｔｔｐ"（ウェブサーバ上のファイルを表す）や、"ｔｅｌｎｅｔ"（Ｔｅｌｎｅｔベースのサービスとの接続を表す）などのシンボルとすることができる。その他のスキームも利用可能であり、新たなスキームが時々追加される。ポート番号はオプションであり、ポート番号が設けられていなければ、（スキームに応じて）システムがデフォルトのポート番号に取り替える。"ｈｏｓｔ"フィールド（ホスト名）は、特定のコンピュータ用の１以上の特定のネットワークアドレスへの対応づけを行う。"ｕｒｌ−ｐａｔｈ"は"ｈｏｓｔ"フィールドで指定されたコンピュータに対する相対的なフィールドである。ｕｒｌ−パスは（但し必ずしもこれに限定されるものではないが）通常ウェブサーバディレクトリ内のファイルのパス名である。

フレームワークまたはシステム１００には少なくとも１つのドメインネームサービス（ＤＮＳ）のネームサーバ１１８−１が含まれる。好ましい実施形態では、システム１００は、特定の単一エンティティがすべて作動するＤＮＳネームサーバ１１８−１、１１８−２〜１１８−ｎ（まとめてネームサーバ１１８と呼ぶ）も備える。図１に図示の実施形態では、ネームサーバのうちの１つ１１８−１は米国用として機能し、別のネームサーバ１１８−２は英国用として機能し、別のネームサーバ１１８−３は日本用として機能する、等々。様々なネームサーバ１１８−１、１１８−２〜１１８−ｎを（まとめてまたは個々に）構成して、地理領域、地政学領域、企業構造またはその他の任意の論理的編成構造として機能させることが可能である。個々のネームサーバ１１８の構造と動作について以下説明する。

クライアントのブラウザ１１４が（ＵＲＬの形などで）要求を取得すると、ブラウザは、要求されたＵＲＬで指定されたホスト名のアドレスを求めてブラウザのリゾルバ１１６に対する問合せを行う。リゾルバ１１６は最終的に特定のネームサーバ（ネームサーバ１１８−１など）に対する問合せを行う。ネームサーバ１１８−１は、加入者サーバネットワークのサーバ（または複数のサーバ）のＩＰ（インターネットプロトコル）アドレス（または複数のアドレス）を返信する（出力するまたは出力を試みる）。リゾルバ１１６へ返信される特定のＩＰアドレスの決定は、（リゾルバのＩＰアドレスから決定されるような）リゾルバの所在位置および様々なポリシー（加入者ポリシー１２０、その他のポリシー１２２など）の複数のファクタに基づいて行うことも可能である。次いで、クライアントのブラウザ１１４は、所望のリソースを取得するために、加入者サーバネットワーク内の選択されたサーバと交信することができる。

本発明の種々の実施形態によるネームサーバ１１８−１、１１８−２〜１１８−ｎは、適応型トラフィック制御（ＡＴＣ）メカニズム１２６を備え、このＡＴＣメカニズム１２６はポリシーデータベース１２４内のポリシーに基づいてドメインネームサービスをクライアントに提供する。個々のネームサーバ１１８は、クライアントの要求をクライアントの所在位置と関連づける所在位置決定メカニズム１２８へのアクセスを含み、あるいは、このアクセスを行う。このようなメカニズム１２８は、ケーブル＆無線ＰＬＣ社のＴｒａｃｅＷａｒｅ（登録商標）製品などであってもよい。ＴｒａｃｅＷａｒｅ（登録商標）は、インターネット消費者の発信国、領域および大都市エリアを認識するその能力によってリアルタイムの、地理的人工知能（ｉｎｔｅｌｌｉｇｅｎｃｅ）を与えるインターネット地図帳を提供するサービスセットである。

加入者サーバネットワーク１０４は、内在的な加入者のために、インターネットコンテンツまたはサービスを提供するサーバネットワークを表す。例えば、加入者は、インターネットを介してエンドユーザのブラウザへコンテンツを配信する自身のサーバネットワークを有するコンテンツプロバイダになることができる。ある判断基準に基づいて、サーバネットワーク１０４内のすべてのサーバ間でサービス要求の処理を合理的に分散できるように加入者サーバネットワーク１０４を構成することができる。上記分散を行うために、例えば、１以上のサーバグループ（サーバグループ１ １０６−１〜サーバグループｋ １０６−ｋなど）を備えるように加入者サーバネットワーク１０４の編成を行うことができる。上記個々のサーバグループがサービス要求の一部を処理する責任を負うようにすることも可能である。例えば、フィンランドから着信するサービス要求は、ヨーロッパに物理的に配置されたサーバグループへ経路指定を行うことも可能である。

加入者サーバネットワーク１０４内の個々のサーバグループ１０６はさらに負荷を共有する複数のサーバを設けるようにすることも可能である。例えば、フィンランドからのサービス要求は、スカンジナビアに配置されたサーバへ次に経路指定を行うことも可能である。異なるサーバグループへの、および、その後の異なるサーバへのルート指定サービス要求を様々な判断基準に基づいて行うようにすることも可能である。例えば、要求元とサーバの所在位置との間の距離に基づいて上記のようなルート指定を行うことも可能である。例えば、フィンランドから発信されたサービス要求の場合、米国に配置されているサーバへ向けて送る代わりに、ノルウェーに配置されているサーバへ向けてこの要求を送る方が効率がよくなることが考えられる。サーバ負荷を用いて、サービス要求の経路指定を行う場所を決定することも可能である。例えば、米国内のサーバグループが過負荷状態にあり、一方メキシコにあるサーバが比較的アイドルな状態であれば、米国から発信されたサービス要求をメキシコにあるサーバグループへ経路指定することも可能である。

サーバグループ内のサーバを編成して、サーバからなる１以上の層を備えた階層にすることも可能である。異なる層におけるサーバが、異なる指定目的を持つようにすることができる。例えば、サーバ階層の第１層のサーバは一次機能サーバであるサーバを設けることができ、第２層のサーバは、第１層の一次サーバが利用できなくなったり、過負荷状態になったりした場合にのみアクティブになるオーバーフローサーバとして使用するサーバを設けることができ、さらに、第２層オーバフロー用として使用する第３層のサーバは、第２層の一次サーバとオーバーフロー（または第１層オーバーフロー）サーバとが利用できなくなったり、過負荷状態になったりした場合にのみアクティブになるサーバを設けることができる。

サーバグループ階層の第１層は１以上の一次サーバを備えることも可能である。複数の一次サーバが存在する場合、負荷を共有するようにこれらの一次サーバを構成することができる。例えば、５つの一次サーバが第１層に存在する場合、サーバグループへ経路指定した総サービス要求の２０％を個々のサーバが受け取るようにこれらの一次サーバを構成することも可能である。このような一次サーバの個々のサーバの場合、特定のサーバが過負荷状態になったり、故障したりした場合、このサーバへ最初に指定した負荷共有を分散したり、別のサーバへ送信したりすることができるように上記個々のサーバをさらに構成することも可能である。サーバが過負荷状態でないとき、分散された負荷を構成することも可能である。他のサーバに対して分散する対象部分は或る予め定義したポリシーにより決定することができる。

上記のように、基底サーバの固有の機能に基づいてサーバグループ１０６内のサーバを異なるカテゴリに類別することも可能である。例えば、サーバグループ１０６内のサーバは、一次サーバ、第１層オーバフローサーバ、または第２層オーバフローサーバ、などであってもよい。サーバを動的にモニタするか否かという観点から、および、サーバを動的にモニタする方法という観点からサーバの類別を行うことも可能である。例えば、実施形態のなかには、モニタ対象サーバまたは管理対象サーバのいずれかとしてサーバを類別できるものもある。

モニタ対象サーバの類別は、その利用可能性に関連して基底サーバを動的にモニタすることを示す。この場合、ある予め定めたスケジュールに基づいてサーバをその利用可能性に関連してプローブすることも可能である。この利用可能性を正確に検出できるように、ネットワークの異なる位置から基底サーバへこのようなプローブを送信することができる。すなわち、１つの位置から送られた基底サーバが１つのプローブに応答できなかった場合、必ずしも、サーバがそれ以上利用できないことを示すとはかぎらない（単にネットワークの一部の輻輳状態に起因する可能性もある）。

プローブは異なる方法で実現することができる。プローブは、単に、確認応答の要求のためにサーバへ送信する信号にすぎない場合もある。プローブは、基底サーバ上の指定した位置に記憶されたファイルのポーリングを行うポーリング処理である場合もある。このファイルを首尾よくポーリングを行うことができた場合、基底サーバは利用可能であると考えられる。検出された利用可能性を用いて、ネットワークトラフィックの管理が、サーバと関連するダイナミクスに応答するようにサーバと関連するポリシーの調整や更新を行うようにすることが可能となる。

管理対象サーバとして類別されたサーバは適応型ポリシーベースの管理方式にアクティブに参加することができる。モニタ対象サーバの場合と同様、その利用可能性に対して管理対象サーバを定期的にプローブすることができる。さらに、管理対象サーバはその負荷共有または分散された負荷に関連する情報を動的に提供することができる。管理対象サーバはその変更された容量またはその現在の負荷に基づいてその負荷共有または負荷分散部分を更新することができる。例えば、管理対象サーバがグレードアップされたとき、その負荷共有またはその負荷分散部分を増減できるようにその容量を増やすことができる。一方、管理対象サーバは、過負荷状態になった場合、その負荷共有を低いレベルへ改訂したり、故障を防止するためにその負荷分散部分を増やしたりすることができる。管理対象サーバは、サーバに記憶された指定ファイル内の対応する負荷共有または負荷分散情報を更新することにより、その負荷共有または分散された負荷を改訂することができ、さらに、このファイルをネームサーバによりポーリングして、動的に変更された負荷共有と負荷分散情報とを用いて、トラフィックを適宜送信できるようにすることも可能である。

加入者サーバネットワーク１０４内での（クライアント１１２からの）サービス要求の分散は、ポリシーデータベース１２４に記憶された１セットのＡＴＣポリシー（１２０、１２２）を介して制御可能である。様々な当局者がＡＴＣポリシーに影響を与えることができ、ポリシーデータベース１２４内にポリシーを形成することが可能となる。例えば、加入者はポリシーを設定して、加入者のネットワーク１０４内の基底サーバの地理上の所在位置と容量などの考慮と関連してトラフィックを送信することができる。例えば、ネームサーバ１１８の通信事業者や様々な地政学上のエンティティを含む他のポリシーエンティティ１３８は、ネットワークトラフィックの管理および送信方法に関するポリシーを知ることができる。例えば、政府や何らかの組織のエージェントはネットワークトラフィックポリシーのいくつかの態様を調整することができる。このような調整ポリシーは、調整ポリシーを満たす方法でクライアント１１２からのサービス要求を経路指定できるように一体化を要求される場合がある。

したがって、ポリシーデータベース１２４内のＡＴＣポリシーは、加入者ポリシー１２０と、加入者１０２とポリシーエンティティ１３８などの異なるソースから得られる別のポリシー１２２との組み合わせとすることができる。ポリシーデータベース１２４からＡＴＣメカニズム１２６によって異なるソースから得られるポリシーに、アクセスすることが可能である。ＡＴＣメカニズム１２６の方から見ると、ポリシーのソースは無関係のものであったり、決定できないものであったりする場合さえある。例えば、指定した位置に記憶したテキストファイルでポリシーを定義することも可能であり、ＡＴＣ管理フレームワーク１４２内のＡＴＣポリシー管理メカニズム１５２へ上記のポリシーをダウンロードし、次いで、ＡＴＣネームサーバネットワーク１４０内の個々のネームサーバ内に配置されているデータベース管理者１３２へこのポリシーを配信することも可能である。このダウンロードは、グラフィックユーザインタフェース（ＧＵＩ）、ファイル転送プロトコル（ＦＴＰ）または他の何らかのメカニズムのいずれかを介して行ってもよい。ポリシー作成者がウェブベースのＧＵＩを介して直接ポリシーを入力してもよい。例えば、加入者１０２は、好ましくは（"ｈｔｔｐｓ"プロトコルなどを用いて実現された）機密保護を施したインタフェースを介してＡＴＣ管理フレームワークと接続されるブラウザインタフェース１５６を介して加入者ポリシー１２０を入力することができる。

ＡＴＣメカニズム１２６により使用されるポリシーデータベース１２４から得られるポリシーは、まとめてＡＴＣポリシーと呼ばれ、これらのポリシーは加入者ポリシー１２０並びにその他のポリシー１２２を含むことができる。但し、これらのポリシーに限定されるものではない。異なるレベルの加入者サーバネットワーク１０４においてトラフィックの決定および／または制御を行うようにＡＴＣポリシーを編成することも可能である。図２は本発明の種々の実施形態による例示タイプのＡＴＣポリシー２００を示す。

ＡＴＣポリシー（２００）は、地政学ポリシー２１５、負荷共有ポリシー２４０、フェイルオーバポリシー２４５、層化フェイルオーバポリシー２５０、分散ポリシー２５５、調整ポリシー２６０、および、無階級ドメイン間ルート指定（ＣＩＤＲ）ブロックポリシー２１０などの異なるタイプのポリシーに類別することができる。

ポリシーデータベース１２４内のこれらの例示ポリシーについて以下さらに詳述する。地理的ポリシー（２１５）：決定は、エンドユーザのリゾルバのＩＰアドレスなどを用いて、エンドユーザの所在位置またはその近似位置に基づいて行われる。例えば、ＩＰアドレスが米国内であれば、要求は、加入者サーバネットワーク１０４内の"国内"グループのサーバへ向けて送信することができ、ＩＰアドレスが米国内でなければ、上記ネットワーク内の"国際"サーバへ向けることができる。この要求は、独自のコンテンツ配信ネットワーク（ＣＤＮ）または加入者が指定する別のサービスへ向けることも可能である。

負荷共有ポリシー（２４０）：加入者は、加入者サーバネットワーク１０４内の定義されたサーバセット内の加入者のサーバの各々へ送信する対象トラフィック（負荷共有）量を明白に指定することができる。通常負荷は個々のサーバの容量に基づいて指定することができる。このような指定に基づいて、個々のサーバの負荷共有を総負荷の割合（％）として導き出すことができる。

フェイルオーバポリシー（２４５）：一次サーバのいくつかが機能しなくなったフェイルオーバ状況に関して加入者はポリシーを指定することができる。このようなシナリオを処理するために、フェイルオーバポリシーは、例えば、サーバの利用可能性をモニタする頻度、および、一次サーバの部分的セットが利用できないことが検出された場合に採るべき戦略に関してＡＴＣメカニズムに指示を与えることができる。例えば、フェイルオーバポリシーは、別の一次サーバへ故障中のサーバの負荷を分散するように指定することができる。上記とは別に、フェイルオーバポリシーは、一次サーバ以外のサーバへ向けてトラフィックを送信するようにＡＴＣフレームワークに指示することもできる。

層化フェイルオーバポリシー（２５０）：加入者は、前の層内の１以上の加入者サーバが機能しなかった場合、次の層のサーバへ向けて再送信すべき負荷を定める層化フェイルオーバポリシーにより戦略を指定することができる。例えば、加入者サーバネットワークを定義する際に、一次サーバの第１層と、第１層オーバフローサーバの第２層と、第２層オーバフローサーバの第３層、などを含む階層として個々のサーバグループを構成することが可能である。この場合、層化フェイルオーバポリシーを定義して、一次サーバからオーバーフローサーバへ向けて負荷を再送信すべき時点を指示することができる。例えば、層化フェイルオーバポリシーは、すべての一次サーバが故障した場合、第２層へ負荷を送信すべきであること、さらに、第１層と第２層の双方のサーバが故障した場合、第３層のオーバーフローサーバへ負荷を送信すべきであることを示すことができる。トラフィックも別の何らかのサーバへ再送信することができる。例えば、コンテンツ配信ネットワーク（ＣＤＮ）が利用可能な場合、ＣＤＮ全体へ向けてトラフィックを再送信することも可能である。

分散ポリシー（２５５）：状況によっては、あるサーバへ最初に指定した"負荷"の部分を１以上の異なるサーバに分散したり、そのようなサーバへ向けて再送信したりすることも可能である。加入者サーバに向けられたトラフィック量が予め規定したレベルを超えた場合に上記分散や再送信を行うことができる。これらのケースでは、上記規定したレベルを超えない場合にサーバへ向け送信されるトラフィック（分散された小部分）の加入者指定の小部分を１以上の他の異なるサーバに分散することも可能である。過負荷に起因して生じる破滅的な故障を防ぐために、このような戦略を採ることが可能である。分散対象負荷を受け取るサーバは、オーバーフローサーバまたはコンテンツ配信ネットワークのような別の何らかのサーバであってもよい。サーバの応答時間に基づいて過負荷状況を検出することができる。例えば、サーバからの応答時間が長くなれば、サーバが過負荷状態であることを示すことができる。この場合、どこか別の場所へトラフィックを再送信するために分散ポリシー２５５を呼び出すことができる。例えば、（０．３、０．３、０．４）の負荷共有を持つサーバグループ内に合計３つの一次サーバを設け、総負荷の４０％を受け取るように指定されている一次サーバが完全に過負荷状態になった場合、分散ポリシーは、例えば、ＣＤＮ１０５内に配置されているサーバへ向けて一次サーバの最初の負荷の５０％を再送信することによりこのサーバの負荷を分散するように指定することができる。分散ポリシーは、分散用サーバへトラフィックの再送信を行う条件を指定することも可能である。このような条件は望ましいレベルの分散用サーバのパフォーマンスに関するものであってもよい。

ＣＩＤＲポリシー（２１０）：ＩＰアドレス空間のＣＩＤＲブロックに基づいてポリシー決定がサポートされている。ＣＩＤＲは、無階級ドメイン間ルート指定を示し、クラスＡ、Ｂ、Ｃに基づいてシステムを置き換えるＩＰアドレス指定方式である。ＣＩＤＲの場合、単一のＩＰアドレスを用いて多くの一意ＩＰアドレスの指定を行うことが可能である。

調整ポリシー（２６０）：何らかのポリシーエンティティにより或るポリシーを指定して、ネットワークトラフィックを制御することも可能である。システム１００においてこのようなポリシーを実施することも可能である。

ポリシーは静的ポリシーあるいは動的なポリシーいずれも可能である。加入者サーバネットワーク１０４からのサーバ選択は、適応型の、定期的に更新されるインターネットの状態マップに基づいて行うことも、適応的に更新されるポリシーに基づいて行うことも可能である。このマップは、ＩＰアドレスのネットワーク待ち時間に基づいて選択されたセットのネットワークエージェントへＩＰアドレスをまとめてクラスタすることができる。これによって、エンドユーザのブラウザまでの加入者サーバの"ネットワークでの近接性（ｐｒｏｘｉｍｉｔｙ）"に基づいて選択される加入者サーバの作動が可能となり、この結果ダウンロード時間の最適化が行われる。利用可能性と負荷などのサーバの動的状態を反映するこのような適応的方法で上記ポリシーを定義することができる。

地政学ポリシー２１５は、クライアントがどこに位置しているかに基づいてサーバの選択を決定することができる。図２に図示のように、地政学ポリシー２１５は、大陸ベース分散ポリシー２２０、国ベース分散ポリシー２２５、領域ベース分散ポリシー２３０および時間帯ベース分散ポリシー２３５にさらに類別することができる。これらのポリシーを設定して、異なる地理的または政治的判断基準に基づいて特定サーバグループを選択するプロセスを決定することができる。

地政学ポリシーは（上記記載の）負荷ベースポリシーとは異なる。前者は地理的判断基準または時間的判断基準に基づいて選択を案内するように設計されている。後者は基底サーバの動的容量と負荷とに関連する選択処理に関する。負荷共有ポリシー２４０はサーバの容量に基づいて選択を決定する。サーバグループ内の機能サーバが過負荷状態になったり、故障したりしたとき、部分的フェイルオーバポリシーまたは層化フェイルオーバポリシー（２４５と２５０）がトラフィック再送信処理プロセスを決定する。

ＡＴＣポリシー２００を階層で構築して、決定ツリーを形成することができる。図３は、本発明の一実施形態による、例示の加入者ポリシー階層または種々のタイプのポリシーに基づいて構成される決定ツリーを示す図である。図３では、大陸ベースの分散ポリシー２２０を用いて、特定の大陸に限定された選択処理プロセスがまず送信される。例えば、要求元クライアント１１２がアジアに位置すれば、大陸ベースの分散ポリシー２２０は、アジアに配置されているサーバ内でさらなる選択処理を送信することができる。同様に、クライアント１１２が北米またはヨーロッパのいずれかに位置していれば、対応する大陸に配置されている適当なサーバへ向けてさらなる選択処理プロセスを送信することができる。

一旦ＤＮＳ要求が適切な大陸へ向けられると、国ベースの分散ポリシー２２５は、クライアント１１２が位置する同じ国または近くの国にある特定のサーバへさらに選択肢を制約することができる。例えば、クライアント１１２が米国内に位置する場合、国ベースのポリシー２２５は、アメリカ合衆国内に配置されているサーバから選択を送信することができる。同様に、領域ベースの分散ポリシー２３０は、クライアント１１２がどこに位置するかに応じて、例えば西海岸や東海岸などにさらに選択を制約することができる。

特定サーバグループを選択した場合（大陸ベースのポリシー２２０に基づく階層決定と領域ベースのポリシー２３０の後など）、負荷共有ポリシー２４０は上記処理プロセスを決定することが望ましく、これにより、所定のサーバグループ内のサーバが選択される。このようなポリシーはサーバの容量に基づいて決定することもできる。あるいは基底サーバの動的パフォーマンスまたは負荷に基づいてこのようなポリシーを適宜改訂することができる。負荷共有ポリシー２４０は、サーバグループ内の個々のサーバが処理すべき総要求の（共有）割合（％）を指定することができる。例えば、サーバグループが合計の３つの一次サーバ（サーバ１、サーバ２、サーバ３）を含む場合、このサーバグループに対する負荷共有ポリシーは（０．３、０．５、０．２）として負荷共有を指定することが可能であり、これはサーバ１が総負荷の３０％を受け取り、サーバ２が負荷の５０％を受け取り、サーバ３が総負荷の２０％を受け取るべきであることを示す。

特定のデフォルトセットのサーバがそれ以上機能しないか、利用できなくなった場合に、層化フェイルオーバポリシー２５０はサーバの選択を決定する。例えば、サーバグループ内の一次サーバは、作動が正常である場合、サービスを提供するデフォルトセットのサーバと考えることができる。サーバの応答時間に基づいてこのような一次サーバの利用不能性を検出することができる。例えば、サーバが単に応答していなければ、このサーバは利用できないと考えられるかもしれない。すべての一次サーバがダウンした場合、トラフィックをどこへ向けて送信すべきであるかが層化フェイルオーバポリシー２５０により決定される。例えば、次の層のオーバーフローサーバへ向けてすべてのトラフィックを送信するように層化フェイルオーバポリシー２５０を指定することができる。

図４は、本発明の種々の実施形態による、加入者サーバネットワーク１０４と加入者ポリシー１２０との間の例示の関係を示す図である。ネットワーク階層またはツリーとして加入者サーバネットワーク１０４が図４に示されている。このネットワークでは、加入者サーバネットワーク１０４は、サーバグループｋ１０６−ｋを通じてサーバグループ１ １０６−１を含み、個々のサーバグループは、第１層内のそれ自身の一次サーバグループ１０８と、第２層内のオーバーフローサーバグループ１１０とを含む（例えば、サーバグループ１１０６−１は、一次サーバグループ１０８−１と、これと関連するオーバーフローサーバグループ１１０−１とを含む）ことができ、一方、サーバグループｋ１０６−ｋは、一次サーバグループ１０８−ｋと、この一次サーバグループ１０８−ｋと関連するオーバーフローサーバグループ１１０−ｋとを含む。

加入者ポリシー１２０は、クライアント１１２（リゾルバ１１６）からのＤＮＳ要求に応答してサーバのＩＰアドレスを返信できるように、加入者サーバネットワーク１０４内の（または別のあるサーバネットワーク内の）１以上のサーバの選択を決定する。加入者サーバネットワーク１０４において適切なサーバを決定したり、適切なサーバを選択したりするために、決定は階層で行うことができる。例えば、図４に図示のように、加入者サーバネットワーク１０４のレベルで、ＡＴＣメカニズム１２６は地政学上の分散決定４１０を行って、どのサーバグループを選択すべきかを決定することができる。一旦特定のサーバグループが選択されると、ＡＴＣメカニズム１２６は、例えば、サーバグループ内のサーバ間でトラフィック負荷を共有すべき方法に基づいてグループ内のどの特定のサーバを選択すべきかをさらに決定することができる。サーバグループレベルでの決定は負荷共有ポリシー２４０に基づくものであってもよい。この意思決定処理は、サーバ階層内の個々のブランチノードにおいて、適切なＡＴＣポリシーを適用して、適切な単数のサーバまたは複数のサーバの選択を決定できることを示す。

図４に例示のように、地政学ポリシー２１５を適用して、特定サーバグループと、負荷共有ポリシー２４０と、層化フェイルオーバポリシー２４５と２５０との選択を制御することができ、分散ポリシー２５５を適用して、トラフィックを再送信することができる。すなわち、加入者サーバネットワーク１０４はツリーを形成し、ＡＴＣポリシー２００はツリーの最上部からツリーの１以上のリーフまでのフローを決定する。ＡＴＣメカニズム１２６はＡＴＣポリシー２００を適用することによりフローの制御を行う。

図５は本発明の種々の実施形態による適応型トラフィック制御（ＡＴＣ）フレームワークの高レベルのアーキテクチャを示す図である。ＡＴＣフレームワークはＡＴＣ管理フレームワーク１４２とＡＴＣネームサーバネットワーク１４０を有する。ＡＴＣ管理フレームワーク１４２は、加入者または別のポリシー作成エンティティ（１３８）と関連する様々な管理上のタスクに責任を負うものであり、上記タスクには、ＡＴＣポリシー２００の操作と記憶、ＡＴＣネームサーバネットワーク１４０におけるネームサーバへのＡＴＣポリシー２００の伝播または配信、ネームサーバの行動のモニタ、適切な媒体にモニタ結果を表示するための状態レポートの作成、ネットワークオペレーションセンタ（ＮＯＣ）１４８（図１を参照）と加入者１０２へのへの警告の送信が含まれる。

ＡＴＣネームサーバネットワーク１４０は、ＤＮＳ要求への応答に対して責任を負うものであり、このＡＴＣネームサーバネットワーク１４０には、ＤＮＳ要求の処理と、加入者サーバネットワーク（または異なる指定されたネットワーク）から１以上のサーバを選択するためにＡＴＣポリシー２００を適用する処理と、選択したサーバのＩＰアドレスによる応答処理とが含まれる。ＡＴＣネームサーバネットワーク１４０によって、ＡＴＣ管理フレームワーク１４２からの受信か、サーバの動的作動状態による更新かのいずれかを受けるＡＴＣポリシー２００を動的に維持される。ＡＴＣネームサーバネットワーク１４０により、動的に更新されたＡＴＣポリシー２００に基づいてドメインネーム／ＩＰアドレスの解決される。ＡＴＣネームサーバネットワーク１４０は、ネットワーク内の個々のネームサーバの作動状態をモニタし、ログデータとモニタデータとをＡＴＣ管理フレームワーク１４２へ供給することも可能となる。

ＡＴＣ管理フレームワーク１４２はフォールトトレランスを持つように設計することができる。例えば、図１と図５とに示されているように、ＡＴＣ管理フレームワーク１４２は、管理マスタエージェント（ＡＭＡ）１４４と、１以上のＡＭＡバックアップ１４６−１〜１４６−ｍ（まとめて１４６）とを備えることができる。マスタエージェント１４４とバックアップ１４６とを備えたすべてのＡＭＡエージェントは正確な機能を実行することができるものであるが、これらの機能（マスタＡＭＡ１４４など）のうちの１つを中心的すなわち一次の管理マスタエージェントとし、その他の機能（ＡＭＡバックアップ１４６など）をバックアップ用すなわち２次的または冗長なマスタエージェントとすることができるという点を除くものとする。中心的すなわち一次的ＡＭＡ１４４はＡＭＡバックアップエージェント１４６を定期的にバックアップする責任を負うことができる。何らかの理由のために、一次ＡＭＡ１４４がそれ以上正しく機能しなくなった場合、ＡＭＡバックアップ１４６のうちの１つが中心的役割すなわちマスタＡＭＡ１４４の役割を引き受けることができる。

ＡＴＣネームサーバネットワーク１４０は複数のネームサーバエージェント１１８−１、１１８−２〜１１８−ｋを含むことが可能であり、これらのエージェントの各々は、特定の地理的（または他の任意の管理上のまたは機能上の）領域のＤＮＳ要求に対する責任を負うように設計することも可能である。例えば、ネームサーバエージェント１１８−１は、北米からのすべてのＤＮＳ要求を処理する責任を負うことが可能であり、ネームサーバ１１８−２はヨーロッパのＤＮＳ要求に対して責任を負うことが可能であり、ネームサーバ１１８−３は日本からのＤＮＳ要求に対して責任を負うことが可能である。さらに、ネームサーバエージェントは、ネットワーク内の別のネームサーバエージェントためのバックアップ用ネームサーバエージェントとして使用することも可能である。例えば、北米のネームサーバエージェントが正しく機能しなくなった場合、ヨーロッパのネームサーバエージェントを北米からのＤＮＳ要求の処理に一時的に割り当てることができる。その目的のために、ＡＴＣネームサーバネットワーク１４０内のネームサーバエージェントのすべてへＡＴＣポリシーをすべて伝えることができる。

図６は、本発明の種々の実施形態による管理マスタエージェント（ＡＭＡ）１４４の高レベル機能ブロック図を示すものである。ＡＭＡ１４４は、機密保護を施したウェブベースのグラフィックユーザインタフェース１６０と、ポリシー編集メカニズム１６２と、ＡＴＣポリシーデータベース１２４と、管理ポリシー更新メカニズム１６４と、ＡＴＣ管理ブラウザ１６６と、ＡＴＣポリシー管理メカニズム１５２と、レポート作成メカニズム１６８と、ＡＴＣネットワークモニタメカニズム１５０と、管理マスタバックアップメカニズム１７０とを有する。

ＡＴＣポリシーデータベース１２４はＡＴＣポリシー２００を記憶する。上記のように、ＡＴＣポリシー２００は、異なるソースからの（加入者からのポリシーおよびネットワークトラフィックを制御する別のエンティティからのポリシーなどの）ポリシーを含むことも可能である。加入者ポリシー１２０と別のポリシー１２２の双方を定義し、ＡＭＡ１４４へ提供することも可能である。図６に図示の例示の構成では、機密保護を施したウェブベースのＧＵＩ１６０を通じてＡＭＡ１４４でポリシーを受信することができる。ＡＭＡ１４４へポリシーを配信することができる別の手段を設けることも可能であり、これについては後程論じる。ポリシー編集メカニズム１６２は、受信したポリシーを編成して、ＡＴＣポリシー２００を形成し、次いで、ＡＴＣポリシーデータをベース１２４内に上記ＡＴＣポリシーを記憶する。

ＡＴＣポリシー管理メカニズム１５２は、ＡＴＣネームサーバネットワーク１４０内の関連するネームサーバへＡＴＣポリシー２００を配信または伝播し、それによって、ＡＴＣポリシー２００を用いて、ドメインネーム翻訳サービスを制御できるようにしてもよい。異なる手段を介して記憶済みＡＴＣポリシーの動的更新を行うことができる。例えば、ＡＴＣ管理ブラウザ１６６を介してポリシーを更新することも可能である。あるいは管理ポリシー更新メカニズム１６４は既存のＡＴＣポリシーの改訂を行うことも可能である。

上記とは別に、ＡＴＣポリシー管理メカニズム１５２を介して異なるソースから得られるポリシーをＡＭＡ１４４に設けることも可能であり、上記管理メカニズムは異なる位置からの動的に更新されたポリシーの定期的ポーリングを行うことができる。このような位置は、動的ポリシー関連情報を出力するように指定されたネットワーク位置、または、管理対象サーバとして類別されるサーバ（加入者サーバネットワーク１０４内か、ＣＤＮ１０５内かのいずれかに在る）を含むことも可能である。例えば、サーバは、サーバに記憶された指定ファイルを介してその負荷共有を動的に指定することも可能である。このような動的に定義された負荷共有情報を管理対象サーバから検索するために、ＡＴＣポリシー管理メカニズム１５２は、管理対象サーバに記憶された指定ファイルのポーリングを行って、関連する負荷共有情報を取得することができる。別のポリシー作成エンティティから動的ポリシーのポーリングを行うことも可能である。

ＡＴＣポリシーの配信は、ある予め定義した間隔に基づいて周期的に行うことが可能であり、あるいは、記憶されたＡＴＣポリシーが更新されるときはいつでもＡＴＣポリシーの配信をトリガーすることが可能である。ＡＴＣポリシー管理メカニズム１５２は、既存のＡＴＣポリシーに対して行われる変化をモニタすることができる。ＡＴＣポリシー管理メカニズム１５２は、ＡＴＣポリシーデータベースに記憶されたＡＴＣポリシーのポーリングを行い、変化が生じているかどうかを調べることができる。一方、指定した位置（このような位置は既存ＡＴＣポリシー内で指定することができる）からＡＴＣポリシー管理メカニズム１５２が動的ポリシーのポーリングを行うときはいつでも、上記管理メカニズムは、動的にポーリングされたポリシーが既存のＡＴＣポリシーと異なっているかどうかを決定することができる。更新されたポリシーが既存ＡＴＣポリシーと異なっている場合、ＡＴＣポリシー管理メカニズム１５２は、ＡＴＣネームサーバネットワーク１４０へ更新済みのＡＴＣポリシーを再配信することができる。

ＡＴＣネットワークモニタメカニズム１５０は、ＡＴＣネームサーバネットワーク１４０内の異なるネームサーバからＤＮＳログの要約を収集することができる。このような要約ログデータは、例えば、所定の時間内に特定のサーバへ向け送信された要求の数などの情報を提供するイベントの形で受信することができる。ＡＴＣネットワークモニタメカニズム１５０は、ＡＴＣシステム全体からのこのようなＤＮＳログの要約（またはイベント）をまとめて処理することができる。レポート作成メカニズム１６８はこれらの要約からモニタ状態レポートを作成することが可能であり、機密保護を施したウェブベースのＧＵＩ１６０を介してこのようなレポートを加入者１０２が利用できるようにする。

管理マスタバックアップメカニズム１７０は、ＡＭＡバックアップ１４６−１〜１４６−ｍを周期的に更新して、すべてのバックアップエージェントが最新のものであることを保証することができる。この周期的に更新には、ＡＴＣポリシーと、様々な制御メカニズム（ＡＴＣポリシー管理メカニズム１５２を含む）の作動状態、ポリシー編集メカニズム１６２、管理ポリシー更新メカニズム１６４とのそれぞれの複製化、および、最新情報の提供を含むことができる。

管理マスタエージェントの主機能として、ＡＴＣポリシーの管理と、ＡＴＣネームサーバネットワーク１４０内のネームサーバエージェントへの更新済みＡＴＣポリシーの供給の確認と、システムパフォーマンスの動的モニタ状態レポートを作成する様々なネームサーバのパフォーマンスのモニタと、ポリシーの動的更新が可能で、モニタレポートのチェックができる接続の維持とが挙げられる。

システムエラーおよびその他の異常条件を示すフラグ情報は、ＡＴＣネットワークモニタメカニズムまたはエージェント１５０により収集される。図７は、本発明の種々の実施形態によるＡＴＣネットワークモニタメカニズム１５０の内部機能ブロック図を示すものである。ＡＴＣネットワークモニタメカニズム１５０は、トラップハンドラ１７６と、処理メカニズム１８２と、警告生成メカニズム１８４とを含む。トラップハンドラ１７６は、ネームサーバネットワーク１４０内のネームサーバからイベントをトラップする。処理メカニズム１８２はトラップされた収集済みイベントを分析し、次いで、この分析情報に基づいて、必要な場合、警告生成メカニズム１８４による警告が生成される。次いで、ＡＴＣのネットワークオペレーションセンタ（ＮＯＣ）１４８と加入者１０２（図１）などへこのような警告を報告する。

トラップハンドラ１７６は、ネームサーバからイベントをトラップするイベント受信装置１７８と、トラップされたイベントを類別し、合理的かつ適切な方法でこれらのイベントを編成できるイベント統合メカニズム１８０とをさらに備える。処理メカニズム１８２は統合化されたイベントを処理して、有用なパターンあるいは情報を与えるパターンを特定することができ、これらのパターンはさらに警告生成メカニズム１８４により用いられて、システムのパフォーマンスに著しい影響を与える可能性のある厄介な問題を含むパターンの特定を行うことができる。

本発明に基づく適応型トラフィック制御（ＡＴＣ）フレームワークは、別のコンテンツ配信ネットワーク（ＣＤＮ）プロバイダと共に、または、別の任意のサービスと共に、ただ加入者のサーバのみへトラフィックを向けて送信するスタンドアローン型サービスとして展開することも可能である。

ＡＴＣネームサーバネットワーク１４０内の個々のドメインネームサーバには、所在位置決定装置１２８、適応型トラフィック制御（ＡＴＣ）メカニズム１２６、モニタエージェントまたはメカニズム１３０、データベース管理者１３２およびレポート作成装置１３４を設ける（図１）ことができる。ネームサーバ（１１８−１など）がクライアント１１２のリゾルバ１１６から要求を受信すると、所在位置決定装置１２８がリゾルバの位置を決定し、ＡＴＣメカニズム１２６へこのような所在位置情報を送信する。この所在位置情報に基づいて、ＡＴＣメカニズム１２６は、ポリシーデータベース１２４（加入者ポリシー１２０または別のポリシー１２２など）から関連するＡＴＣポリシーを検索し、検索された関連するポリシーに基づいて加入者サーバネットワーク１０４内の１以上のサーバを選択する。次いで、対応するＩＰアドレスまたは選択済みサーバのＣＮＡＭＥがリゾルバ１１６へ返信される。

データベース管理者１３２はポリシーデータベース１２４の保守管理を行う。データベース管理者１３２は、ＡＴＣ管理フレームワーク１４２内のＡＴＣポリシー管理メカニズム１５２からポリシーを受信し、このポリシーをポリシーデータベース１２４にポピュレートする。ＡＴＣ管理フレームワーク１４２から受信したＡＴＣポリシーは、加入者サーバネットワーク１０４（またはＣＤＮ１０５）においてサーバを定義または類別する情報を含むことができる。例えば、モニタ対象サーバと定義できるサーバもあれば、管理対象サーバに対応するサーバもある。

データベース管理者は、このような情報を受信すると、基底サーバの類別に関する情報をモニタメカニズム１３０に与えることができ、その結果、個々のサーバの状態に基づいてモニタメカニズム１３０は個々のサーバのモニタを行うことが可能となる。ＡＴＣポリシー管理メカニズム１５２が更新されたポリシーを配信すると、データベース管理者１３２はポリシーデータベース１２４に記憶された関連するポリシーを適宜更新する。

モニタメカニズム１３０は加入者サーバネットワーク内のネームサーバ１１８−１と１以上のサーバの作動状態をモニタする。モニタメカニズム１３０は、作動中ネームサーバ１１８−１内で生じたイベントを収集し、ＡＴＣ管理フレームワーク１４２内のＡＴＣネットワークモニタメカニズム１５０へこのようなイベントを送信することができる。一方で、モニタメカニズム１３０は、個々のサーバが定義されている態様（モニタ対象サーバか管理対象サーバのいずれか）に応じて、加入者サーバグループ１０４内の（またはＣＤＮ１０５内の）様々なサーバの処理をモニタすることができる。

サーバがモニタ対象サーバとして定義されている場合、モニタメカニズム１３０は（前述したように）サーバを動的にプローブしてその利用可能性を決定することができる。サーバが管理対象サーバとして定義されている場合、モニタメカニズム１３０は作動中その利用可能性をモニタすることができる。モニタメカニズム１３０はサーバから動的負荷共有情報のポーリングを行うことも可能である。サーバがもはや利用できないことをモニタメカニズム１３０が検出したとき、モニタメカニズム１３０は、ホスト名を解決する際にＡＴＣメカニズム１２６が考慮できるように、サーバがもはや利用できないことを示すローカルなポリシーを作成することをデータベース管理者１３２に知らせることができる。

モニタメカニズム１３０は、サーバからの動的負荷共有情報のポーリングを行うと、ポーリング済みの負荷共有のダイナミクスにより影響を受けている、ポリシーデータベース１２４内の負荷共有ポリシーを更新する旨をデータベース管理者１３２に知らせることができる。例えば、サーバグループ内の３つの一次サーバが当初負荷共有（０．３、０．３、０．４）を持っていて、第３の一次サーバがその負荷共有を次に０．２に変更した場合、データベース管理者１３２は、上記３つの一次サーバ間の負荷共有を（０．４、０．４、０．２）へ更新することができる。

レポート作成装置１３４は、保存されたログ情報１３６に基づいて基底ネームサーバの処理に関連するレポートを作成する。異なるネームサーバからのレポートを統合できるように、ＡＴＣ管理フレームワーク１４２内のレポートコンソリデータ（ｃｏｎｓｏｌｉｄａｔｏｒ）１５４へこのような作成済みレポートを送信することも可能である。

加入者は、２つの方法、ＤＮＳ ＣＮＡＭＥまたはＮＧ委任のうちの一方の方法でＡＴＣシステム（ＤＮＳサーバ）を起動（ターンアップ）させることができる。単一のＤＮＳホスト名を求めてトラフィックを送信するためにＡＴＣを使用する代わりに、加入者は、ＡＴＣへ向けて送信したい多くの異なるサブドメインを持つことができる。例えば、加入者が、ＡＴＣにより処理されるｄｌ．ｃｕｓｔｏｍｅｒ．ｃｏｍからのすべてのダウンロードをＡＴＣのサブドメインと共に望むことができ、しかも、ｄｌ．ｃｕｓｔｏｍｅｒ．ｃｏｍにより制御される他のすべての領域（ｗｗｗ．ｃｕｓｔｏｍｅｒ．ｃｏｍなど）を以下の加入者自身のネームサーバにより解決することができる。ｄｌ．ｃｕｓｔｏｍｅｒ．ｃｏｍ．＝＞ＡＴＣ。ａｎｙ．ｔｈｉｎｇ．ｄｌ．ｃｕｓｔｏｍｅｒ．ｃｏｍ．＝＞ＡＴＣ。ｗｗｗ．ｃｕｓｔｏｍｅｒ．ｃｏｍ．＝＞ＡＴＣでない。ｃｕｓｔｏｍｅｒ．ｃｏｍ．＝＞ＡＴＣでない。

この場合、加入者のＤＮＳゾーンファイル内にＣＮＡＭＥレコードを追加する代わりに、加入者は単にそのゾーンファイル内のＮＳレコードを介して命名をｄｌ．ｃｕｓｔｏｍｅｒ．ｃｏｍ．に委任する。

（ＮＳレコードを利用する）委任方法は、この方法が柔軟性があり、ＡＴＣの信頼性と、スケーラビリティと、柔軟性とがすべて得られるため、現在好適な方法である。委任のための最初の接触後、時折問合せを行う正しく作動するリゾルバは加入者自身の単複のネームサーバと再び接触しなくなる。この結果、ずっと良好な命名解決パフォーマンスが得られることになる。というのは、加入者のネームサーバを通じて行われる個々の新たなＤＮＳ要求をルート指定するという不必要なオーバーヘッドが省かれるからである。ＣＮＡＭＥ法ではループの中に加入者自身のネームサーバが保持される。すなわち、ＣＮＡＭＥ ＴＴＬが時間切れになるときはいつでも、クライアントリゾルバが加入者のネームサーバへ戻り、レコードをリフレッシュする。

ＣＮＡＭＥ法と委任法の双方の場合、ＡＴＣスイッチをターンオフする処理手順は同じであり、加入者がそのＤＮＳゾーンファイルを編集してＡＴＣへの委任権限が取り除かれる。ＤＮＳ要求は、適切な委任に関して時間切れが生じるまで加入者の定義したＡＴＣポリシーに基づいてサービスを受け続ける。

作動時のシステム：図８（ａ）はプロセスを示すフローチャートの例であり、この例において、ネームサーバは、本発明の一実施形態によるＡＴＣポリシーに基づいてＤＮＳ要求を解決する。まず、ユーザはユーザのブラウザ１１４の中へ（または入力としてＵＲＬを受け入れ、クライアント用の対応するリソースを取得する任意のアプリケーションの中へ）ＵＲＬを入力する（８０２）。クライアントのリゾルバ１１６は、サーバのＩＰアドレスを取得するためにＵＲＬのホスト名を解決しようと試みる。上記サーバからＵＲＬにより特定されるリソースを取得することができる（８０４）。クライアントのＤＮＳ（図示せず）により、リゾルバ１１６は、ＡＴＣネームサーバネットワーク１３４内のＤＮＳネームサーバ１１８へ向けて送信される（８０６）。リゾルバ１１６は、解決を試みているホスト名をネームサーバ１１８に提供する。

ネームサーバ１１８はホスト名の解決要求を受信し（８０８）、加入者サーバネットワーク１０４内で、または、リゾルバ１１６の所在位置に基づいて、並びに、ポリシーデータベース１２４から検索された関連するＡＴＣポリシーに基づいて、クライアントの要求を処理することができるＣＤＮ１０５内で１以上のサーバを確定する（８１０）。図８（ｂ）と関連してこの処理の詳細について説明する。選択されたサーバのＩＰアドレスは要求元リゾルバ１１６へ返信される（８１２）。次いで、ブラウザ１１４は、要求したリソースを取得するためにサーバのうちの１つと接続する（８１４）。

図８（ｂ）は、ドメインネームサーバが、クライアントと関連するＡＴＣポリシーの位置に基づいて１以上のサーバを選択する典型的処理を示すフローチャートである。リゾルバ１１６またはクライアントの所在位置をまず決定する（８１６）。次いで、ポリシーデータベース１２４から、関連するＡＴＣポリシーの検索を行う（８１８）。クライアントの所定位置と、関連するＡＴＣポリシーとに基づいて加入者サーバネットワーク１０４内のまたはＣＤＮ１０５内のいずれかの１以上のサーバを選択する（８２０）。

図８（ｃ）は、ドメインネームサーバ内のモニタメカニズム１３０が、加入者サーバネットワーク１０４内またはＣＤＮ１０５内の、ネームサーバ並びに１以上のサーバの処理をモニタする典型的処理を示すフローチャートである。ドメインネームサービス中に生じるイベントをモニタする（８２２）。ＡＴＣネットワークモニタメカニズム１５２へ上記のようなイベントを送信する（８２４）。さらに、１以上のサーバの利用可能性もモニタする（８２６）。さらに、１以上のサーバのいずれかが管理対象サーバとして定義されていれば（８２８で判定）、動的負荷共有情報のポーリングを行う（８３０）。利用可能性情報と動的負荷共有情報（そのような情報が何か存在すれば）の双方を用いて、ネームサーバにとってローカルな何らかのＡＴＣポリシーを更新する（８３２）。

図８（ｄ）は、ＡＴＣポリシー管理メカニズム１５２がＡＴＣポリシーを動的に維持し、これを配信する典型的処理を示すフローチャートである。最初、異なるソースからポリシーを受信し（８３４）、ネームサーバ１１８へこのポリシーを配信する（８３６）。バックアップが必要であれば（８３８で判定）、ＡＴＣポリシー管理メカニズム１５２がマスタバックアップエージェント１４６へ現在のポリシーを送信する（８４０）。

ＡＴＣポリシー管理メカニズム１５２は動的ポリシーの保守管理も行う。ＡＴＣポリシー管理メカニズム１５２は、或る定義した間隔で動的ポリシー情報（８４２）のポーリングを行い、このようなポーリング済みの動的ポリシー情報を用いて、既存のポリシーを更新する（８４４）。次いで、更新済みポリシーをネームサーバへ配信する（８４６）。バックアップエージェントへ更新済みポリシーを伝播する必要があれば（８４８で判定）、これらの更新済みポリシーをマスタバックアップエージェントへ送信する（８５０）。

図８（ｅ）は、ＡＴＣネットワークモニタメカニズム１５０がネームサーバの作動をモニタし、ＮＯＣ１４８と加入者１０２とへ警告を送信する典型的処理を示すフローチャートである。異なるネームサーバのモニタメカニズムから送信されたイベントをトラップする（８５２）。異なるソースからの上記のようなトラップしたイベントを統合し（８５４）、次いで、処理する（８５６）。何らかの警告状況が生じた場合（８５８で判定）、ＡＴＣネットワークモニタメカニズム１５０が警告を作成する（８６０）。次いで、作成された警告をＮＯＣ１４８と加入者１０２の双方へ送信する（８６２）。

ポリシー管理：ＡＴＣポリシーを最初に設定し、その後、サーバの動的状態に基づいて適宜このポリシーを更新することができる。ＡＴＣポリシーは様々な手段を介して形成することができる。上記説明したアプローチを適用して別のポリシーを形成することも可能である。ＧＵＩによるアプローチまたはファイルベースのアプローチ（またはこれら双方）を用いて加入者ポリシーを設定することも可能である。ＧＵＩによるアプローチによって、加入者ポリシーを形成する異なる手段を採用することも可能である。例えば、ブラウザを用いて直接ポリシーを入力できるようにすることも可能である。ＧＵＩによるアプローチを用いて、加入者ポリシーについての説明を含むＸＭＬファイルのロードを行って、ポリシーの構文解析と記憶とを行うことができるようにすることも可能である。別の代替方法として、加入者ポリシーについての説明を含むファイルのロードを同様の方法で行って、適宜構文解析を行うようにすることも可能である。ファイルベースの方法を用いる場合、加入者ポリシー（ＸＭＬに基づいて構築された加入者ポリシーか、別の何らかの構造の加入者ポリシーかのいずれか）についての説明を含むファイルにＦＴＰなどの別の手段を介してアクセスすることができる。

推奨実施例によっては、加入者が機密保護を施したウェブベースのＧＵＩ１６０（図６）にアクセスして加入者の機密保護を施したブラウザインタフェース１５６を使用するものもある。

図９（ａ）〜９（ｃ）は、本発明の種々の実施形態による、例示の機密保護を施したウェブベースのグラフィカルインタフェースを示し、このインタフェースを介して、加入者は、指定したネットワーク資源と関連して、負荷共有ポリシーとオーバーフローポリシーとを定義することができる。異なるタイプの負荷共有サーバ：（１）静的サーバ、（２）動的サーバ、（３）オーバーフローサーバを設けることができる。動的サーバとは、モニタ対象サーバまたは管理対象サーバのいずれかであり、このサーバの動的利用可能性をモニタすることが可能であり、さらに、サーバが利用できなくなった場合、サーバの負荷を再送信することが可能である。モニタ対象サーバの場合、その負荷共有と負荷分散部分の双方を動的なサーバにすることも可能である。

同様に、異なるタイプのサーバへのルート指定要求を決定するポリシーを適宜定義することも可能である。第１に、サーバが比較的静的で、時間中頻繁に変化しなければ、静的サーバを決定するポリシーが適用される。これは、サーバの利用可能性が安定したものであり、異なるサーバ間での負荷共有も比較的安定していることを意味する。サーバが頻繁に変化すると予想される場合、動的サーバを制御するポリシーが適用される。このようなポリシーには、フェイルオーバポリシー、分散ポリシー、および（前述の）層化フェイルオーバポリシーが含まれる。オーバーフローポリシーは、静的サーバまたは動的サーバのいずれかの一次サーバが何らかの理由のために利用できなくなったり、過負荷状態になったりしたときの要求フローの変更を制御する。この場合、関連するオーバーフローポリシーによって、どのオーバーフローサーバへネ−ムサービス要求を向けるべきであるかが決定される。

所定のサーバと関連する負荷共有とは、静的サーバ設定内の該サーバへ送信されるトラフィック量を表す。サーバへ送信するトラフィックの負荷共有を計算する例示の方法として、現在の静的サーバ設定のすべてのサーバの負荷共有量を加算し、この加算した合計で該サーバの負荷共有を除して、負荷共有を導き出す方法がある。

所定のサーバの分散部分は、サーバから再送信すべきトラフィックの割合（％）を表す。負荷共有ポリシーに基づいて負荷共有を行った後、再送信を行うことができる。図９（ａ）は、個々のリストされたサーバに様々な選択関連パラメータを割り当てたインタフェース例を示す図である。例えば、個々のサーバに対してＴＴＬが指定される。さらに、負荷共有と分散部分とを指定することも可能である。例えば、ニューヨークとロンドンのサーバの双方は１．０の負荷共有を有する。サーバ・ニューヨークに割り当てられた分散部分は０．２であり、これはその負荷の２０％が別のあるサーバへ再送信されることを意味し、また、サーバ・ロンドンに割り当てられた分散部分は０．３であり、これはその負荷の３０％が別のあるサーバへ再送信されることを意味する。

分散部分はリアルタイムで自動的に計算することができる。例えば、サーバの応答が緩慢で、過負荷状態になっている可能性が検出されると、その予想応答時間と実際の応答時間との間の不一致に基づいて分散部分の計算を行うことができる。次いで、自動的に計算されたこのようなトラフィック量を適用し、新しく計算した部分を異なるサーバへ再送信して、当初過負荷状態のサーバへの再送信を意図していたトラフィックの若干の負荷を受け持つようにすることが可能である。

個々のリソースサーバの場合、オンラインフラグをセットして、サーバが現在利用可能かどうかを示すことができる。このフラグは図９（ａ）の右側の列に示されている。このフラグがあると、保守管理などのためにサーバを落す必要がある場合、一時的にサーバの解除を行うことが可能となる。

動的サーバの比較的頻繁な変更が予想されるという事実に起因して、動的サーバの選択を決定するポリシーを２段階で定義することができる。静的サーバ用の場合と同様の方法で動的サーバ用のポリシーを当初指定してもよい。例えば、図９（ａ）に図示のように、ニューヨークとロンドンの動的サーバ用として負荷共有と分散部分とを定義することができる。しかし、作動中、動的サーバの選択を決定するポリシーを動的に確立することも可能である。例えば、ネットワーク上の１以上の指定した位置などから検索したオンライン状態レポートに基づいて、当初定義したポリシー（負荷共有、分散部分、オンラインフラグなど）を適宜改訂することも可能である。ネットワークの健康状態や他の任意のネットワークのパフォーマンスに関連するファクタ（保守管理など）に対して適応的に選択を実行する方法におけるかなりの柔軟性が動的ポリシーによって得られる。

加入者が指定した１以上のネットワーク位置のオンライン状態レポートを提供することができる。これらの位置はユニフォームリソースロケータ（ＵＲＬ）として指定することも可能であり、また、ＨＴＴＰ要求を通じて上記位置にアクセスすることも可能である。最初のポリシーで状態レポートの位置を指定して、この位置との一定のリンクを設けることができる。図９（ｂ）は状態レポートとのＵＲＬリンクを指定するための例示のＧＵＩを示す。状態レポートの所在位置に関連するＵＲＬリンクは"ｈｔｔｐ：／／ｓｅｒｖｅｒ"として指定され、このリンクは１０．０．０．３というＩＰアドレスを持つロンドンと命名されたサーバに対応するものである。このアクセスを認証することも可能であり、このような認証要件は最初のポリシーで指定してもよい。サーバのパフォーマンスのモニタ中に収集した情報に基づいてオンラインアクセス状態レポートを構築することも可能である。例えば、加入者サーバネットワーク内の個々のサーバは、そのパフォーマンスに関連する情報を含む状態レポートを提供することも可能である。ＡＴＣネームサーバネットワーク内のネームサーバはこのようなサーバからこのような情報のポーリングを行うことも可能であり、さらに、このような情報を用いてポリシーの更新を行うことができる。

状態レポートにアクセスする頻度を明白に指定することも可能である。例えば、３０秒毎などの定期的な時刻に状態レポートのポーリングを行うには、上記頻度は関連するメカニズム（具体的には個々のネームサーバのＡＴＣポリシー管理メカニズムまたはモニタメカニズム）を必要とする場合もある。

拡張可能マークアップ言語（ＸＭＬ）などの何らかの標準的言語を用いて状態レポートを構築することができる。このような状態レポートは改訂されたポリシーを含むことができる。加入者がネットワークパフォーマンスに基づいてこの改訂されたポリシーを手動で決定したり、ネットワークパフォーマンスに基づいて自動化処理によりこのポリシーを接続したり、あるいは、個々の管理対象サーバによりこのポリシーを作成したりすることも可能である。このようなケースで、更新済みポリシーが状態レポートの中に含まれ、この状態レポートのポーリングが行われるとき、以降のトラフィック制御時にこの更新済みポリシーが使用される。例えば、管理対象サーバはその動的容量に基づいてその負荷共有の再定義を行うことができる。このような動的に定義した負荷共有情報にアクセスして、実施時にこの情報を利用するとき、トラフィックはネットワークのダイナミクスに適応して制御される。

状態レポートがアクセスされると、関連するメカニズム（ＡＴＣ管理フレームワーク内のＡＴＣポリシー管理メカニズムまたは対応するネームサーバ内のＡＴＣメカニズム）は状態レポート内に含まれる情報に基づいて関連するポリシーの更新を行う。例えば、サーバ・ニューヨーク用の現在の負荷共有は、同じ分散部分（０．２）と共に０．４（前回の１．０からダウン）にすることが望ましいこと、また、サーバ・ロンドン用の現在の負荷共有は０．４の分散部分（４０％分散部分）と共に０．５（前回の１．０からダウン）にすることが望ましいことを状態レポートによって示すことができる。別のシナリオとして、個々の動的サーバに関するネットワークパフォーマンスデータを提供し、状態レポートにアクセス後、ＡＴＣメカニズムが現在のポリシーを適宜改訂することができる方法を状態レポートにより決定してもよい。

状態レポートが動的ポリシーを提供する場合、このレポートは一般に、個々の動的サーバに対して、以下の情報を含むことができる：＜ＳｅｒｖｅｒＳｔａｔｕｓ ｌｏａｄＳｈａｒｅ＝"ＬＳ" ｓｈｅｄＦｒａｃｔｉｏｎ＝"ＳＦ" ｏｎｌｉｎｅ＝"Ｂｏｏｌｅａｎ"／＞。但し、ＬＳとＬＦは数値を表し、"ブール（Ｂｏｏｌｅａｎ）"は"真"か"偽"かのいずれかの論理値を表す。

上述の動的ポリシーのメカニズムの場合、加入者またはサーバは、ＡＴＣポリシー階層全体を更新する必要なく、現行のポリシー（負荷共有、分散部分ポリシー、オンラインフラグなど）に対する変更を簡単に指定することができる。さらに、あるパラメータ（実施形態によっては"ダウンオンライン"呼ばれる）をＡＴＣポリシーでセットして、失敗したポーリングや、検索や、状態レポートのコンテンツの構文解析の失敗などの理由に起因して生じる、ＡＴＣポリシー管理メカニズムが状態レポートに正しくアクセスできない状況でＡＴＣメカニズムの行動を制御することができる。本発明のある実施形態によれば、上記状況の処理に適用できる３つの異なる例示のアプローチがある。

第１のアプローチとして、加入者は、当該サーバ用の状態レポートを正しく取得できない場合、特定のサーバを選択しないようにネームサーバ内のＡＴＣメカニズムに指示することができる。加入者は"ダウンオンライン"パラメータを偽にセットすることによりこのポリシーを指定することができる。この場合、ＡＴＣメカニズムは、ポーリングメカニズムが有効な状態レポートを検索するまで、基底サーバを選択処理プロセスの候補とみなさないことになる。

ポーリングの失敗を処理する第２のアプローチとして、ＡＴＣメカニズムが、そのデフォルトのポリシー（または最初のポリシー）に基づいて基底の動的サーバの選択を可能にするアプローチがある。この解決方法を指定するために、加入者は"ダウンオンライン"パラメータを真にセットすることができる。

状態レポートを正しく検索できない状況を処理する第３のアプローチとして、基底サーバの"オンライン"フラグがオンであれば（基底サーバが利用可能であれば）ＡＴＣメカニズムが基底サーバを選択できるようにするアプローチがある。これを行うために、加入者は、状態レポートで"オンライン"ＳｅｒｖｅｒＳｔａｔｕｓのみを指定し、"ダウンオンライン"は真または偽のいずれかにセットすることができる。この場合、ＡＴＣメカニズムは"オンライン"フラグが真にセットされているとき、ポリシーで指定されている負荷共有と分散部分とを使用する。負荷共有と負荷分散部分とは、双方とも動的に決定することができる（ＡＴＣポリシー管理メカニズムから配信される場合または基底サーバからＡＴＣメカニズム１３０によりポーリングされる場合のいずれかの場合）。

処理上異なるポリシーによりこれらサーバの選択を制御できるが、静的サーバと動的サーバの双方は一次サーバである。第３のタイプのサーバはオーバーフローサーバと呼ばれる。このサーバは、何らかの理由のために一次サーバを選択できない場合、代替サーバを提供するものである。一般に、オーバーフローサーバは、正準名（Ｃａｎｏｎｉｃａｌ ｎａｍｅ）すなわちＣＮａｍｅに対応し、（ケーブル＆無線ＰＬＣ社のフットプリントサービスなどのような）ＣＤＮを提供するサービスを指すものである。オーバーフローサーバの選択は一般に常時利用可能な信頼度に基づいて決定することができる。オーバーフローサーバは図９（ｃ）に示すウィンドウを介して定義することができる。図９（ｃ）で、オーバーフローサーバは、ＣＤＮサーバアドレス"ｃｕｓｔｏｍｅｒ．ｆｏｏｔｐｒｉｎｔ．ｎｅｔ"（図１に図示のＣＤＮ１０５など）を指すＣＮａｍｅにより定義される。

図１０（ａ）〜図１０（ｂ）は、１セットのリソースサーバに基づいて定義された加入者ポリシー例を示す図であり、この加入者ポリシーによって、着信要求の地理上の位置と個々の位置の時間帯などの異なる判断基準に基づいてサーバの選択が決定される。図１０（ａ）では、ＩＰアドレス１０．０．０．２を持つ"ｅａｓｔｓｅｒｖｅｒ"と、ＩＰアドレス１０．０．０．１を持つ"ｗｅｓｔｓｅｒｖｅｒ"と、ＣＮａｍｅ"ｃｕｓｔｏｍｅｒ．ｆｏｏｔｐｒｉｎｔ．ｎｅｔ"を持つサービスネットワークとを含む３つの異なるリソースサーバが定義されている。この場合、サービスネットワークは２以上のサーバを備えたものであってもよい。

図１０（ｂ）は、１セットのサーバへ向けてトラフィックを送信すべき方法を案内する１セットの地理的ポリシーの中に組み込まれた例示の決定ツリーを示す図である。図１０（ｂ）に示された決定ツリーでは、アメリカ合衆国と世界の残りの部分との間の分割に基づいて、サーバの選択はまずトップレベルで異なるリソースへ向けられる。リソースは、単一サーバ（またはＣＤＮ）あるいは１グループのサーバ（または複数のＣＤＮ）のいずれかに対応することができる。アメリカ合衆国以外の地理領域から開始された要求は"ロンドン"と命名されたリソースへ向けて送信される。アメリカ合衆国内では、時間帯ベースのポリシーがさらに適用される。中央時間帯内の領域から開始された要求は"ニューヨーク"と命名されたリソースへ向けて送信される。アラスカ時間帯内の領域から開始された要求はリソース"ロンドン"へ向けて送信される。最後に、これらの時間帯（アラスカまたは中央時間帯）のいずれにも属さないアメリカ合衆国内の領域から開始された要求は"ロンドン"または"ニューヨーク"のいずれかへ向けて送信することができる。

図１０（ｃ）〜図１０（ｄ）は、１セットのリソース（サーバまたはＣＤＮ）と、オーバーフローポリシーを持つ着信する要求の要求元の地理上の位置に基づいて定義される加入者ポリシーとに基づいて構築される別の決定ツリー例を示す図である。上記オーバーフローポリシーは、一次サーバが利用できなくなった場合、ＡＴＣメカニズムが予め定義したオーバーフローサーバへ向けてトラフィックを送信できるようにするポリシーである。図１０（ｃ）に図示のリソースウィンドウでは、以下の３つのリソース、すなわちリソースのＩＰアドレスに基づいて個々に定義された静的リソース"ロンドン"と"ニューヨーク"と、ＣＮａｍｅ"ｃｕｓｔｏｍｅｒ．ｓａｎｄｐｉｐｅｒ．ｎｅｔ"を持つ"シドニー"と命名されたサービスネットワークが定義される。個々のリソースは、或る階層を持つサーバグループなどの１セットのサーバに対応するものであってもよい。リソース"ロンドン"はさらに動的リソースと定義され、リソース"シドニー"はさらに"ｃｄｎ＿ｓｅｒｖｉｃｅ"というニックネームのオーバーフローサーバネットワークとして定義される。図１０（ｄ）は、これらのリソースに基づいて構築された決定ツリー例を示す図である。

図１０（ｄ）の決定ツリーは、要求がアメリカ合衆国からのものかどうかに基づいてまずトップレベルで２つの方向に分かれる。要求がアメリカ合衆国から開始されたものである場合、その要求は、図１０（ｄ）に例示のポリシーに基づいてリソース"ロンドン"の第１層にある動的サーバへ向けて送信される。アメリカ合衆国からの要求は、リソース"ｃｄｎ＿ｓｅｒｖｉｃｅ"内のオーバーフローサーバのうちの１つへ向けても送信することができる。リソース"ロンドン"の第１層にあるすべての一次サーバが機能できなくなった場合、あるいは、このような一次サーバが過負荷状態になった場合に、上記事態が生じる可能性がある。

本願明細書に記載の様々なウェブベースのインタフェースの他に、加入者ポリシーを定義できる別の手段も存在する。前述したように、例えば、ＡＴＣメカニズムによりダウンロードが可能で、トラフィックの制御に使用できるＸＭＬファイルの形で加入者ポリシーの構築または指定が可能である。

異なる手段を介して（ウェブベースのＧＵＩやＸＭＬファイルなどを介して）定義したポリシーを変換して、ＡＴＣメカニズム内の何らかの予め定義したフォーマットに変えることも可能である。ＡＴＣポリシーの管理と処理時の効率を図るために、このような予め定義したフォーマットを設計することも可能である。例えば、ＡＴＣポリシー用の内部形式を設計して、内部でＡＭＡがＡＴＣポリシーの記憶と、アクセスと、ネームサーバエージェントへの配信とを都合よく行うことができるように、さらに、ネームサーバエージェントが効率良くポリシーを適用できるようにすることも可能である。

前述したように、ＡＴＣポリシーの管理に加えて、ＡＭＡはネームサーバのパフォーマンスをモニタすることも可能であり、さらに、閲覧可能なＤＮＳログレポートを作成する。モニタメカニズムは、ネームサーバのＤＮＳログまたはネームサーバからトラップされたイベントのいずれからパフォーマンス情報を収集することができる。レポート作成メカニズムによりこのような収集情報を利用して、情報を与えるレポートを構築するようにすることも可能である。このレポート作成メカニズムは加入者が機密保護を施したウェブベースのＧＵＩを介してこのようなレポートを利用できるようにすることも可能である。図１１（ａ）〜図１１（ｃ）は、機密保護を施したウェブベースのＧＵＩを介してアクセス可能な例示タイプのレポート情報を示す図示である。図１１（ａ）は、加入者が指定のリソースサーバのＤＮＳログデータを閲覧できるようにするウェブインタフェースを示す図である。加入者は現在再査しているサーバの名前（"ｄｏｗｎｌｏａｄ．ｓｕｂｓｃｒｉｂｅｒ．ｃｏｍ"など）と、ログデータを編成すべき形式（ＩＰとＣＮａｍｅの問合せと、出力時の別個の項目としての応答を伴う返答との表示を意味する"別個"の出力スタイルの指定など）と、現在再査している時期（２００２年９月１日〜２００２年９月２４日など）と、ログデータの表示時に用いる時間分解能（時間分解能の自動的選択など）とを指定することが可能である。

図１１（ｂ）は指定サーバと関連するログデータのプロットを示す。このログデータは、或る分解能で、指定された時間（Ｘ軸）に対する特定サーバのログエントリに基づいて作成され、プロットで示されている。このプロット例は、２００２年９月２４日の２：３０ｐｍ〜３：３０ｐｍの間の時間中、基底サーバへ向けて送信されたトラフィックの量を反映するものである。トラフィック量は、分当たり基底サーバが生成した返答回数という点から記述される（Ｙ軸）。２：３６ｐｍと２：３８ｐｍとの間でトラフィックボリュームの急上昇が生じていることがこのプロット例で理解できる。

図１１（ｃ）は、図１１（ｂ）のものと同じログデータの図表を示し、この図表では、表の上部から下部までログデータが時間順にリストされている。例えば、左列の各行は時間をリストしている。例示の表では、１時間（２：３０ｐｍ〜３：３０ｐｍ）の範囲内のログデータは、各々１５分の複数のサブ期間に分けられている。個々のサブ期間の間、第３列は対応するサブ期間からの返答回数を出力する。例えば、３：１５ｐｍ〜３：３０ｐｍのサブ期間中、１３回の返答があり、別のサブ期間には返信がない（図１１（ｂ）に示すプロットと一致）。

本願明細書に記載の様々なメカニズムには、限定なしで、適応型トラフィック制御（ＡＴＣ）メカニズム、所在位置決定メカニズム、ポリシー編集メカニズム、管理ポリシー更新メカニズム、ＡＴＣポリシー管理メカニズム、レポート作成メカニズム、モニタメカニズムが含まれ、ハードウェアや、ソフトウェアまたはそれらを組み合わせた形で管理マスタバックアップメカニズムの実現が可能である。ソフトウェアの形で実現する場合、いずれの任意のタイプの適切な解釈またはコンパイルされるプログラム言語で上記メカニズムを実行することができる。ソフトウェアの形で部分的にまたは完全に実現された場合、本発明の態様は、ＲＯＭ、ディスク、ＡＳＩＣ、ＰＲＯＭ、等を含む任意のメモリまたは記憶媒体上に存在することができる（但しこれらに限定されるものではない）。特定のメカニズム（アルゴリズム、処理プロセスおよび機能）並びにアーキテクチャと関連して本発明について説明したが、当業者であれば、本発明をそのまま達成しながら、別のメカニズムおよび／またはアーキテクチャを使用することも可能であることを理解するであろう。

本発明の様々なメカニズムが（クライアント側やサーバ側の）特定のマシーンで機能している場合、これらのメカニズムはマシーンのメモリ内にまたは記憶装置上にもしくはこれらを組み合わせた形で存在するものであってもよい。さらに、特定の順序で実行するものとして上記処理の多くを示したが、当業者であれば、何らかの並列処理を含む別の順序も可能であり、これも本発明の範囲に属することを理解するであろう。

以上、本発明の好ましい実施形態と関連して本発明について記載したが、本記載は専ら例示を目的として行ったものであり、本発明は、本記載により限定されるものではない。実際、本発明の変形例は当業者には容易に明らかなものであろう。このような変形例も本発明の範囲に属するものである。したがって、例示の実施形態と関連して本発明について説明したが、本願明細書に用いた用語は、限定のための用語ではなく説明のための用語である。本発明の範囲と精神から逸脱することなく、添付の請求項の範囲内で変更を行うことが可能である。特定の構造、作用、材料と関連して本願明細書で本発明について記載したが、本発明は開示された上記詳細事項に限定されるものではなく、添付の請求の範囲内ですべての均等な構造、作用、材料に拡張されるものである。

上記記載の処理は、正しくプログラムされた汎用コンピュータ単独で実行することも可能であり、あるいは、専用コンピュータと接続して実行することも可能である。このような処理は、単一のプラットフォームにより、あるいは、分散処理用プラットフォームにより実行することも可能である。さらに、専用ハードウェアの形でまたは汎用コンピュータにより実行されるソフトウェアの形でこのような処理と機能とを実現することが可能である。このような処理時に処理されたデータ、または、このような処理の結果形成されたデータは当業で一般的な任意のメモリに記憶することが可能である。例えば、所定のコンピュータシステムやサブシステムのＲＡＭのような一時メモリにこのようなデータを記憶することも可能である。さらに、あるいは、代替の形で、例えば磁気ディスク、書き換え可能な光ディスク、等々の長期間の記憶装置にこのようなデータを記憶することも可能である。本願明細書での開示を目的として、コンピュータ可読媒体は、このような現行のメモリ技術、並びに、このような構造とこのようなデータのハードウェアあるいは回路表現を含むデータ記憶メカニズムを含む任意の形態のデータ記憶装置を含むことも可能である。

本発明の種々の実施形態によるフレームワークを示す。 本発明の種々の実施形態によるポリシーの例を示す。 本発明の種々の実施形態による、加入者ポリシーに基づいて構成される階層または決定ツリーの例を示す。 本発明の種々の実施形態による、加入者のネットワーク階層と加入者ポリシー間の関係の例を示す。 本発明の種々の実施形態による、適応型トラフィック制御のフレームワークの高レベルのアーキテクチャを示す。 本発明の種々の実施形態による、管理マスタエージェント（ＡＭＡ）の高レベル機能ブロック図を示す。 本発明の種々の実施形態による、モニタメカニズムの内部機能ブロック図を示す。 本発明の種々の実施形態による、コンテンツ配信フレームワークは適応型ポリシーベースのドメインネームサービスを提供するプロセスを示すフローチャートの例ある。 本発明の種々の実施形態による、ドメインネームサーバがポリシーをベースとするホスト名を解決するプロセスを示すフローチャートの例である。 本発明の実施形態による、上記プロセスでドメインネームサーバのモニタメカニズムがネ−ムサービスオペレーション並びにサーバの利用可能性と負荷共有状態とを動的にモニタするあるプロセスを示すフローチャートの例である。 本発明の種々の実施形態による、上記プロセスでＡＴＣ管理ネットワークが動的ポリシーを保持し、コンテンツ配信フレームワークの動作をモニタするあるプロセスを示すフローチャートの例である。 本発明の種々の実施形態による、ＡＴＣネットワークモニタメカニズムが異なるドメインネームサーバからイベントを捕捉し、必要な場合に警告を生成するプロセスを示すフローチャートの例である。 本発明の種々の実施形態による、例示の機密保護を施したウェブベースのグラフィカルインタフェースを示し、上記インタフェースを介して加入者は静的リソース間の負荷共有と分散部分ポリシーとを定義することができる。 本発明の種々の実施形態による、動的サーバに対するポリシーを定義するための例示インタフェースを示す。 本発明の種々の実施形態による、正準名（ｃａｎｏｎｉｃａｌ ｎａｍｅ）を用いてオーバーフローサーバが定義される例示のグラフィックユーザインタフェースを示す。 本発明の種々の実施形態による、１セットのリソースサーバに基づいて定義される加入者ポリシー例を示し、この加入者ポリシーにより、着信要求の地理上の位置と、それぞれの位置の時間帯とに基づいて選択が決定される。 本発明の種々の実施形態による、１セットのリソースサーバに基づいて定義される加入者ポリシー例を示し、この加入者ポリシーにより、着信要求の地理上の位置と、それぞれの位置の時間帯とに基づいて選択が決定される。 本発明の種々の実施形態による、オーバーフローポリシーにより、一次サーバが利用できなくなった場合、ＡＴＣメカニズム１５０が予め定義したサービス向けにトラフィックを送信することが可能となるオーバーフローポリシーと共に着信要求の地理上の位置に基づいて定義される加入者ポリシーの例を示す。 本発明の種々の実施形態による、オーバーフローポリシーにより、一次サーバが利用できなくなった場合、ＡＴＣメカニズム１５０が予め定義したサービス向けにトラフィックを送信することが可能となるオーバーフローポリシーと共に着信要求の地理上の位置に基づいて定義される加入者ポリシーの例を示す。 本発明の種々の実施形態による、グラフィックユーザインタフェースを介してログ情報を表示し、閲覧することが可能な例示のアーカイブされたログ情報を示す。 本発明の種々の実施形態による、グラフィックユーザインタフェースを介してログ情報を表示し、閲覧することが可能な例示のアーカイブされたログ情報を示す。 本発明の種々の実施形態による、グラフィックユーザインタフェースを介してログ情報を表示し、閲覧することが可能な例示のアーカイブされたログ情報を示す。

Claims (70)

1. コンテンツプロバイダのリソースが少なくとも２つの異なるネットワークからクライアントへ配信されるインターネットコンテンツの配信用フレームワークであって、
   加入者サーバネットワークと、
   前記加入者サーバネットワークとは異なる少なくとも１つのコンテンツ配信ネットワーク（ＣＤＮ）と、
   ポリシーに基づいてドメインネームサービスを提供する少なくとも１つのドメインネームサーバと
   を備え、
   ホスト名の解決を求めるクライアントの要求に応じて、前記ドメインネームサーバは、少なくとも１つのポリシーに対する考慮に少なくとも部分的に基づいて、（ａ）前記少なくとも１つのコンテンツ配信ネットワークと（ｂ）前記加入者サーバネットワークとのいずれか１つを選択し、前記ドメインネームサーバは前記選択されたネットワークに関連する情報を前記クライアントに提供する、フレームワーク。
2. ホスト名の解決を求める要求に応じて、前記ドメインネームサーバは、少なくとも前記クライアントの所在位置および別のポリシーに対する考慮の少なくとも一部に基づいて、１つのネットワークを選択する請求項１記載のフレームワーク。
3. 前記ドメインネームサーバは、
   （ａ）地理的ポリシーと、
   （ｂ）負荷共有ポリシーと、
   （ｃ）オーバーフローポリシーと、
   （ｄ）ネットワークを意識したポリシーとのうちの１以上に基づいて１つのネットワークを選択する請求項１記載のフレームワーク。
4. 前記少なくとも１つのポリシーに対する考慮は、
   要求元クライアントの地理上の所在位置に基づいて１つのネットワークの選択を決定する地政学に関するポリシーと、
   前記加入者サーバネットワークと前記少なくとも１つのコンテンツ配信ネットワーク（ＣＤＮ）とに関連する動的負荷情報に基づいて１つのネットワークの選択を決定する負荷共有ポリシーと、
   １つのネットワークの負荷を別のネットワークに分散する方法を決定する分散ポリシーと、
   前記ネットワーク内の少なくとも１つのサーバが機能しなくなった場合、そのネットワークの選択を決定する部分的フェイルオーバポリシーと、
   前の層内のサーバが機能しなくなった場合、サーバグループに対応するサーバ階層内の次の層のサーバの選択を決定するフェイルオーバポリシーと、
   モニタ対象サーバと管理対象サーバのうちの１つとして前記ネットワーク内のサーバを定義するサーバ指定ポリシーと
   のうちの少なくとも１つを含む請求項１記載のフレームワーク。
5. ドメインネームサービスを提供するドメインネームサーバであって、
   要求者の所在位置を決定する所在位置決定装置と、
   ポリシーに基づいてドメインネームサービスを提供する適応型トラフィック制御メカニズムと
   を備え、
   前記ドメインネームサーバは、
   （ａ）地理的ポリシーと、
   （ｂ）負荷共有ポリシーと、
   （ｃ）オーバーフローポリシーと、
   （ｄ）ネットワークを意識したポリシーと
   のうちの１以上のポリシーに少なくとも部分的に基づいて、少なくとも２つの異なるコンテンツ配信ネットワーク（ＣＤＮ）と加入者サーバネットワークとから１つのサーバネットワークを選択することを試みる、ドメインネームサーバ。
6. コンテンツプロバイダのリソースが、加入者サーバネットワークと前記加入者サーバネットワークとは異なる少なくとも１つのコンテンツ配信ネットワーク（ＣＤＮ）とを含む少なくとも２つの異なるネットワークからクライアントへ配信されるフレームネットワーク内で操作可能な、ドメインネームサービスを提供する方法であって、
   ホスト名の解決を求める要求をリゾルバから受信するステップと、
   前記要求元リゾルバの所在位置を決定するステップと、
   前記決定された所在位置と、別の動的ポリシーに対する考慮とに少なくとも部分的に基づいて、（ａ）前記少なくとも１つのコンテンツ配信ネットワークと（ｂ）前記加入者サーバネットワークとのいずれか１つを選択するステップと、
   前記要求元リゾルバへ前記選択されたネットワークに関連する情報であって、前記選択されたネットワークに関連するドメインネームを含む情報を提供するステップと、
   を備える方法。
7. 前記ネットワークは、
   （ａ）地理的ポリシーと、
   （ｂ）負荷共有ポリシーと、
   （ｃ）負荷分散ポリシーと、
   （ｄ）ネットワークを意識したポリシーと
   のうちの１以上のポリシーに基づいて選択される請求項６記載の方法。
8. インターネットコンテンツの配信用フレームワークであって、
   インターネットコンテンツを提供する加入者に関連するサーバネットワークと、
   前記加入者に関連するサーバネットワークとは異なる少なくとも１つのコンテンツ配信ネットワーク（ＣＤＮ）と、
   ポリシーに基づいてドメインネームサービスを提供する少なくとも１つのドメインネームサーバを備える適応型トラフィック制御（ＡＴＣ）ネームサーバネットワークと
   を備え、
   ホスト名の解決を求める要求に応じて、前記ＡＴＣネームサーバネットワーク内の少なくとも１つのドメインネームサーバが、少なくとも１つのポリシーに対する考慮の少なくとも一部に基づいて、（ａ）前記少なくとも１つのＣＤＮと（ｂ）前記加入者に関連するサーバネットワークとのいずれか１つを選択し、
   前記少なくとも１つのドメインネームサーバは、前記選択されたネットワークに関連する情報を要求者に提供し、
   前記情報は、（ａ）前記選択されたネットワークがＣＤＮの場合の前記選択されたネットワークのドメインネームと（ｂ）前記選択されたネットワークが前記加入者に関連するサーバネットワークの場合の前記加入者に関連するサーバネットワーク内のサーバのアドレスとのいずれかを含む、フレームワーク。
9. 前記ポリシーに対する考慮は、
   （ａ）地理的ポリシーに対する考慮と、
   （ｂ）負荷共有ポリシーに対する考慮と、
   （ｃ）オーバーフローポリシーに対する考慮と、
   （ｄ）ネットワークを意識したポリシーに対する考慮と
   のうちの１以上の考慮を備える請求項８記載のフレームワーク。
10. 適応型トラフィック制御用フレームワークであって、
    加入者サーバネットワークと前記加入者サーバネットワークとは異なる少なくとも１つのコンテンツ配信ネットワーク（ＣＤＮ）とを含む複数の異なるサーバネットワークと、
    適応型ポリシーに基づいてドメインネームサービスを提供する少なくとも１つのドメインネームサーバを備える適応型トラフィック制御（ＡＴＣ）ネームサーバネットワークと
    を備え、
    ホスト名の解決を求める要求に応じて、前記ＡＴＣドメインネームサーバネットワーク内の少なくとも１つのドメインネームサーバが、ポリシーと、前記要求者の所在位置とに少なくとも部分的に基づいて、（ａ）前記少なくとも１つのコンテンツ配信ネットワークと（ｂ）前記加入者サーバネットワークとのいずれか１つを選択し、
    前記少なくとも１つのドメインネームサーバは、前記選択されたネットワークに関連する情報を提供する、フレームワーク。
11. 前記選択されたネットワークに関連する情報は、
    前記選択されたネットワークに関連するドメインネームまたはＣＮＡＭＥを含む請求項１０記載のフレームワーク。
12. 前記加入者サーバネットワークは少なくとも１つのサーバグループを備え、前記少なくとも１つのサーバグループの個々のサーバがサーバ階層に対応する請求項１１記載のフレームワーク。
13. 前記サーバ階層は、
    少なくとも１つの一次サーバを備える第１層と、
    前記第１層内の前記少なくとも１つの一次サーバが機能しなくなった場合に機能する少なくとも１つの第１のレベルのオーバーフローサーバを備える第２層と、
    前記少なくとも１つの一次サーバと、前記１以上の第１のレベルのオーバーフローサーバとの双方が機能しなくなった場合、少なくとも１つの第２のレベルのオーバーフローサーバを備える第３層とのうちの少なくとも１つの層を含む請求項１２記載のフレームワーク。
14. 前記サーバネットワーク内の個々のサーバは、
    モニタ対象サーバと、
    管理対象サーバと
    のうち少なくとも１つであり、
    前記モニタ対象サーバの利用可能性が動的にモニタされ、
    前記管理対象サーバの利用可能性が動的にモニタされるか、または、前記管理対象サーバの負荷共有もしくは分散部分が動的に定義される、請求項１３記載のフレームワーク。
15. 前記ＡＴＣドメインネームサーバネットワーク内の個々のドメインネームサーバは、
    要求元クライアントの地理上の所在位置を決定する所在位置決定装置と、
    前記ポリシーベースのドメインネームサービスを容易に行うことが可能な適応型トラフィック制御（ＡＴＣ）メカニズムと、を備える請求項１４記載のフレームワーク。
16. 前記少なくとも１つのポリシーは、
    前記クライアントの地理上の位置に基づいて、前記サーバネットワーク内のサーバグループの選択を決定する地政学に関するポリシーと、
    サーバグループ内のサーバと関連する動的負荷共有情報に基づいて、前記サーバグループからのサーバの選択を決定する負荷共有ポリシーと、
    サーバグループ内のサーバの負荷を別のサーバに分散する方法を決定する分散ポリシーと、
    同じ層のサーバのうちの少なくとも１つのサーバが機能しなくなった場合、サーバ階層の層のサーバの選択を決定するフェイルオーバポリシーと、
    前の層内のサーバが機能しなくなった場合、サーバ階層内の次の層のサーバの選択を決定する層化フェイルオーバポリシーと、
    モニタ対象サーバと管理対象サーバとのうちの少なくとも１つとして前記サーバネットワーク内のサーバを定義するサーバ指定ポリシーとのうちの少なくとも１つのポリシーを含む請求項１５記載のフレームワーク。
17. 前記地政学に関するポリシーは、
    大陸ベースのポリシーと、
    国ベースのポリシーと、
    領域ベースのポリシーと、
    時間帯ベースのポリシーと
    のうちの少なくとも１つを含む請求項１６記載のフレームワーク。
18. 調整ポリシーをさらに備える請求項１７記載のフレームワーク。
19. 前記ドメインネームサーバは、前記ドメインネームサーバの作動中に生じるイベントを観察することが可能なモニタエージェントをさらに備える請求項１５記載のフレームワーク。
20. 前記モニタエージェントは、モニタ対象サーバか、管理対象サーバかのいずれかとして指定される、前記サーバネットワーク内の１以上のサーバの利用可能性がモニタされるようにさらに構成され、それによって、前記ドメインネームサーバは、前記１以上のサーバの利用可能性に基づいて前記サーバを決定することができる請求項１９記載のフレームワーク。
21. 前記モニタエージェントは、１以上の管理対象サーバから動的負荷共有情報と負荷分散情報とのポーリングを行うことが可能であり、それによって前記ドメインネームサーバは、前記管理対象サーバと関連する前記動的負荷共有情報と前記負荷分散情報とに基づいてサーバを決定することができる請求項２０記載のフレームワーク。
22. 前記ＡＴＣネームサーバネットワークの作動と、前記サーバネットワークの状態とを管理することが可能な適応型トラフィック制御（ＡＴＣ）管理フレームワークをさらに備える請求項１９記載のフレームワーク。
23. 前記ＡＴＣ管理フレームワークは、
    管理マスタエージェント（ＡＭＡ）と、
    少なくとも１つの管理マスタバックアップエージェントと、
    ネットワークオペレーションセンタと
    を備える請求項２２記載のフレームワーク。
24. 前記ＡＭＡは、
    前記少なくとも１つのドメインネームサーバの少なくとも１つのモニタエージェントから受信したイベント情報によって前記ＡＴＣドメインネームサーバネットワークの作動をモニタすることが可能なＡＴＣネットワークモニタメカニズムと、
    少なくとも１つのソースから少なくとも１つのポリシーを受信し、これを動的にポーリングし、前記ＡＴＣドメインネームサーバネットワーク内の前記少なくとも１つのドメインネームサーバへ前記少なくとも１つのポリシーを配信することが可能なＡＴＣポリシー管理メカニズムと、
    前記ＡＭＡが機能しなくなった場合、前記ＡＭＡの代わりに機能できるように、前記少なくとも１つの管理マスタエージェントがバックアップすることを可能にする管理マスタバックアップメカニズムと
    を備える請求項２３記載のフレームワーク。
25. 前記少なくとも１つのソースは、
    加入者ポリシーを定義するべく前記管理マスタエージェントとリアルタイムで交信し、前記ＡＴＣポリシー管理メカニズムによってポーリングを行うことが可能な動的ポリシーを提供することが可能な加入者と、
    前記ＡＴＣポリシー管理メカニズムが受信または動的ポーリングを行うことが可能なポリシーを定義する１以上のポリシーエンティティと、
    ポーリングを行うことが可能な動的負荷共有ポリシーと負荷分散ポリシーとを提供する前記サーバネットワーク内の１以上の管理対象サーバと
    のうちの少なくとも１つを含む請求項２４記載のフレームワーク。
26. 前記ＡＴＣネットワークモニタメカニズムは、
    異なるＡＴＣドメインネームサーバと関連するモニタエージェントからイベント情報を受信し、そのトラップしたイベント情報を統合することが可能なトラップハンドラと、
    前記統合されたトラップ済みイベント情報を分析することが可能な処理メカニズムと、
    前記処理から得られた処理結果に基づいて警告を生成し、前記ネットワークオペレーションセンタへ前記警告を送信する警告生成メカニズムと、を備える請求項２４記載のフレームワーク。
27. 前記警告生成メカニズムは、前記加入者へ前記警告を送信することがさらに可能である請求項２６記載のフレームワーク。
28. コンテンツプロバイダのリソースが、加入者サーバネットワークと前記加入者サーバネットワークとは異なる少なくとも１つのコンテンツ配信ネットワーク（ＣＤＮ）とを含む少なくとも２つの異なるサーバネットワークからクライアントへ配信されるフレームワーク内で操作可能な、ホスト名を解決するドメインネームサーバであって、
    ホスト名の解決を求める要求を受信した要求元クライアントの地理上の所在位置を決定することが可能な所在位置決定装置と、
    ポリシーベースのドメインネームサービスをサポートすることが可能な適応型トラフィック制御（ＡＴＣ）メカニズムと
    を備え、
    前記ドメインネームサーバは、（ａ）前記少なくとも１つのコンテンツ配信ネットワークと（ｂ）前記加入者サーバネットワークとのいずれか１つを選択して、前記少なくとも２つのネットワークのうちの前記選択された１つと関連する少なくとも１つのドメインネームである回答を提供し、
    前記ネットワークの前記選択は、前記所在位置決定装置により確かめられた前記所在位置と、少なくとも１つのポリシーとに少なくともに基づく、ドメインネームサーバ。
29. 前記少なくとも２つの異なるサーバネットワークは、
    少なくとも１つのサーバグループを備える加入者サーバネットワークと、
    少なくとも１つのサーバを備えるコンテンツ配信ネットワーク（ＣＤＮ）と
    のうちの少なくとも１つを含む、請求項２８記載のドメインネームサーバ。
30. 個々のサーバグループは、
    少なくとも１つの一次サーバを備える第１層と、
    前記少なくとも１つの一次サーバが機能しなくなった場合に機能する１以上の第１のレベルのオーバーフローサーバを備える第２層と、
    前記少なくとも１つの一次サーバと、前記１以上の第１のレベルのオーバーフローサーバとの双方が機能しなくなった場合、１以上の第２のレベルのオーバーフローサーバを備える第３層と
    のうちの少なくとも１つの層を含むサーバ階層に対応する、請求項２９記載のドメインネームサーバ。
31. 前記少なくとも１つのポリシーは、
    前記クライアントの地理上の位置に基づいて、サーバネットワークの選択を決定する地政学に関するポリシーと、
    前記サーバと関連する動的負荷共有情報に基づいて、サーバネットワークの選択を決定する負荷共有ポリシーと、
    サーバネットワークの負荷を別のサーバネットワークに分散する方法を決定する分散ポリシーと
    のうちの少なくとも１つを含む、請求項２８記載のドメインネームサーバ。
32. 前記地政学ポリシーは、
    大陸ベースのポリシーと、
    国ベースのポリシーと、
    領域ベースのポリシーと、
    時間帯ベースのポリシーと
    のうちの少なくとも１つを含む、請求項３１記載のドメインネームサーバ。
33. 調整ポリシーをさらに備える請求項３１記載のドメインネームサーバ。
34. 前記ドメインネームサーバの作動中に生じるイベントを観察し、適応型トラフィック制御（ＡＴＣ）管理フレームワークの適応型トラフィック制御（ＡＴＣ）ネットワークモニタメカニズムへこのようなイベントを送信することが可能なモニタエージェントをさらに備える請求項２８記載のドメインネームサーバ。
35. コンテンツプロバイダのリソースが、加入者サーバネットワークと前記加入者サーバネットワークとは異なる少なくとも１つのコンテンツ配信ネットワーク（ＣＤＮ）とを含む少なくとも２つの異なるネットワークからクライアントへ配信されるフレームワーク内で操作可能な、適応型トラフィック制御ベースのドメインネームサービスのための方法であって、
    適応型トラフィック制御（ＡＴＣ）ドメインネームサーバネットワーク内のドメインネームサーバにより、ホスト名の解決を求めるリゾルバからの要求を受信するステップと、
    前記クライアントの前記地理上の所在位置と、少なくとも１つのポリシーとに少なくとも部分的に基づいて、（ａ）前記少なくとも１つのコンテンツ配信ネットワークと（ｂ）前記加入者サーバネットワークとのいずれか１つから選択されたサーバネットワークに対応する回答を決定するステップと、
    前記回答を要求者へ提供するステップと
    を備え、
    前記回答は、前記選択されたサーバネットワークのドメインネームと、前記選択されたサーバネットワークのＣＮＡＭＥのうちの少なくとも１つである、方法。
36. 前記少なくとも２つの異なるサーバネットワークは、
    コンテンツ配信サービスを提供する加入者サーバネットワークと、
    前記コンテンツ配信サービスを提供するコンテンツ配信ネットワーク（ＣＤＮ）と
    のうちの少なくとも１つを含む、請求項３５記載の方法。
37. 前記加入者サーバネットワークは、少なくとも１つのサーバグループを含む、請求項３６記載の方法。
38. 個々のサーバグループは、
    少なくとも１つの一次サーバを備える第１層と、
    前記少なくとも１つの一次サーバが機能しなくなった場合に機能する１以上の第１のレベルのオーバーフローサーバを備える第２層と、
    前記少なくとも１つの一次サーバと、前記１以上の第１のレベルのオーバーフローサーバとの双方が機能しなくなった場合に機能する１以上の第２のレベルのオーバーフローサーバを備える第３層と
    のうちの少なくとも１つを含むサーバ階層に対応する、請求項３７記載の方法。
39. 前記サーバネットワーク内の個々のサーバを、
    モニタ対象サーバと、
    管理対象サーバと
    のうちの少なくとも１つのサーバとして指定することができ、
    前記モニタ対象サーバの利用可能性が動的にモニタされ、
    前記管理対象サーバの利用可能性が動的にモニタされるか、または前記管理対象サーバの負荷共有もしくは負荷分散が動的に定義される、請求項３８記載の方法。
40. 前記少なくとも１つのポリシーは、
    前記クライアントの地理上の位置に基づいて、サーバネットワークの選択を決定する地政学に関するポリシーと、
    前記サーバと関連する動的負荷共有情報に基づいて、サーバネットワークの選択を決定する負荷共有ポリシーと、
    サーバネットワークの負荷を別のサーバネットワークに分散する方法を決定する分散ポリシーと
    のうちの１以上のポリシーを含む、請求項３９記載の方法。
41. 前記地政学に関するポリシーは、
    大陸ベースのポリシーと、
    国ベースのポリシーと、
    領域ベースのポリシーと、
    時間帯ベースのポリシーと
    のうちの少なくとも１つを含む、請求項４０記載の方法。
42. 調整ポリシーをさらに備える、請求項４１記載の方法。
43. 前記回答を決定するステップは、
    前記クライアントの地理上の所在位置を決定するステップと、
    前記クライアントの地理上の所在位置に関連する１以上のポリシーを検索するステップと、
    前記検索された１以上のポリシーに基づいて前記サーバネットワークを特定するステップと、
    前記選択されたサーバネットワークのドメインネームとＣＮＡＭＥとのうちの少なくとも１つを特定するステップと
    を備える、請求項４２記載の方法。
44. 前記少なくとも１つのポリシーを確立するステップをさらに備える、請求項４３記載の方法。
45. 前記少なくとも１つのポリシーを確立するステップは、
    適応型トラフィック制御（ＡＴＣ）管理フレームワーク内の管理マスタエージェント（ＡＭＡ）の適応型トラフィック制御（ＡＴＣ）ポリシー管理メカニズムにより、少なくとも１つのソースから前記少なくとも１つのポリシーを受信するステップと、
    前記サーバネットワーク内の１以上の管理対象サーバからの前記少なくとも１つのポリシーの動的ポーリングを行うステップと
    のうちの少なくとも１つを備える、請求項４４記載の方法。
46. 前記少なくとも１つのソースは、
    加入者と、
    調整エンティティと
    のうちの少なくとも１つを含む、請求項４５記載の方法。
47. 前記ＡＴＣネームサーバネットワーク内の前記少なくとも１つのドメインネームサーバへ前記少なくとも１つのポリシーを配信するステップをさらに備える、請求項４６記載の方法。
48. 更新されたポリシーを生成するべく、前記ポーリングステップによりポーリングされた動的ポリシーに基づいてポリシーを動的に更新するステップと、
    前記ＡＴＣネームサーバネットワーク内の前記少なくとも１つのドメインネームサーバへ前記更新済みポリシーを配信するステップと
    をさらに備える、請求項４７記載の方法。
49. ドメインネームサーバ内のモニタメカニズムにより、前記ドメインネームサーバの作動状態をモニタするステップをさらに備える、請求項４８記載の方法。
50. 前記モニタするステップは、
    前記ドメインネームサーバの作動中に生じるイベントをモニタするステップと、
    前記ＡＴＣ管理フレームワーク内のＡＴＣネットワークモニタメカニズムへ前記イベントを送信するステップと
    を備える、請求項４９記載の方法。
51. 前記モニタメカニズムによって、モニタ対象サーバまたは管理対象サーバのいずれかのサーバとして指定された１以上のサーバの利用可能性をモニタし、それによって、前記ドメインネームサーバが、前記１以上のサーバの利用可能性に基づいて、前記サーバを決定することができるステップをさらに備える、請求項５０記載の方法。
52. 前記モニタメカニズムにより、前記サーバネットワーク内の１以上の管理対象サーバからの動的負荷共有情報または負荷分散情報のポーリングを行い、それによって前記ドメインネームサーバが、前記動的負荷共有情報と前記負荷分散情報とに基づいて前記サーバを決定することができるステップをさらに備える、請求項５１記載の方法。
53. 前記ＡＴＣ管理フレームワークにより、前記ＡＴＣネームサーバネットワークの作動状態を管理するステップをさらに備える、請求項５２記載の方法。
54. 前記管理するステップは、
    前記ＡＴＣネームサーバネットワーク内のモニタメカニズムからイベントを受信するステップと、
    前記ＡＴＣネットワークモニタメカニズムにより、前記ドメインネームサーバから受信した前記イベントを統合して、統合されたイベントを生成するステップと、
    前記統合されたイベントを処理するステップと
    を備える、請求項５３記載の方法。
55. 前記処理するステップの結果に基づいて警告を生成するステップと、
    前記ＡＴＣ管理ネットワークのネットワークオペレーションセンタと加入者とへ警告を送信するステップと
    をさらに備える、請求項５４記載の方法。
56. コンテンツプロバイダのリソースが、加入者サーバネットワークと前記加入者サーバネットワークとは異なる少なくとも１つのコンテンツ配信ネットワーク（ＣＤＮ）とを含む少なくとも２つの異なるサーバネットワークからクライアントへ配信されるフレームワーク内で操作可能な、ホスト名を解決する方法であって、
    適応型トラフィック制御（ＡＴＣ）ネームサーバネットワーク内のドメインネームサーバによって、リゾルバを介してクライアントからのホスト名の解決を求める要求を受信するステップと、
    前記クライアントの地理上の所在位置と、少なくとも１つのポリシーとに少なくとも部分的に基づいて、（ａ）前記少なくとも１つのコンテンツ配信ネットワークと（ｂ）前記加入者サーバネットワークとのいずれか１つを選択するステップと、
    少なくとも１つの所在位置ベースのポリシーに基づいて、前記選択されたサーバネットワークのドメインネームとＣＮＡＭＥとのうちの少なくとも１つを決定するステップと
    を備える、方法。
57. 前記加入者サーバネットワークは、少なくとも１つのサーバグループを含む、請求項５６記載の方法。
58. 個々のサーバグループは、
    少なくとも１つの一次サーバを備える第１層と、
    前記少なくとも１つの一次サーバが機能しなくなった場合に機能する１以上の第１のレベルのオーバーフローサーバを備える第２層と、
    前記少なくとも１つの一次サーバと、前記１以上の第１のレベルのオーバーフローサーバとの双方が機能しなくなった場合、１以上の第２のレベルのオーバーフローサーバを備える第３層と
    のうちの少なくとも１つを含むサーバ階層に対応する、請求項５７記載の方法。
59. 前記サーバネットワーク内の個々のサーバは、
    モニタ対象サーバと、
    管理対象サーバと
    のうちの少なくとも１つを備え、
    前記モニタ対象サーバの利用可能性が動的にモニタされ、
    前記管理対象サーバの利用可能性が動的にモニタされるか、または前記管理対象サーバの負荷共有もしくは負荷分散が動的にモニタされる、請求項５８記載の方法。
60. 前記少なくとも１つのポリシーは、
    前記クライアントの地理上の位置に基づいて、サーバネットワークの選択を決定する地政学に関するポリシーと、
    前記サーバネットワークと関連する動的負荷共有情報に基づいて、サーバネットワークの選択を決定する負荷共有ポリシーと、
    サーバネットワークのサーバの負荷を別のサーバネットワークに分散する方法を決定する分散ポリシーと、
    調整ポリシーと
    のうちの１以上を含む、請求項５９記載の方法。
61. 前記サーバネットワークを選択するステップは、
    前記クライアントの地理上の所在位置を決定するステップと、
    前記クライアントの地理上の所在位置に関連する１以上のポリシーを検索するステップと、
    前記検索された１以上のポリシーに基づいて前記サーバネットワークを決定するステップと
    を備える、請求項５６記載の方法。
62. 前記少なくとも１つのポリシーを動的に確立するステップをさらに備える、請求項６１記載の方法。
63. 前記少なくとも１つのポリシーを確立する前記ステップは、
    適応型トラフィック制御（ＡＴＣ）管理フレームワーク内の管理マスタエージェント（ＡＭＡ）の適応型トラフィック制御（ＡＴＣ）ポリシー管理メカニズムから配信される前記少なくとも１つのポリシーを受信するステップと、
    前記サーバネットワーク内の１以上の管理対象サーバから１以上の負荷共有ポリシーまたは負荷分散ポリシーの動的ポーリングを行うステップと、
    更新されたポリシーを生成するべく、前記ＡＴＣポリシー管理メカニズムから受信されるか、または管理対象サーバからポーリングされる、対応する動的ポリシーに基づいてポリシーを更新するステップと
    のうちの少なくとも１つを備える、請求項６２記載の方法。
64. 前記ドメインネームサーバのモニタメカニズムにより、前記ドメインネームサーバの作動状態をモニタするステップをさらに備える、請求項６３記載の方法。
65. 前記モニタステップは、
    前記ドメインネームサーバの作動中に生じるイベントをモニタするステップと、
    前記ＡＴＣ管理フレームワーク内のＡＴＣネットワークモニタメカニズムへ前記イベントを送信するステップと
    を備える、請求項６４記載の方法。
66. モニタ対象サーバまたは管理対象サーバのいずれかのサーバとして指定された１以上のサーバの利用可能性をモニタし、それによって前記ドメインネームサーバが、前記１以上のサーバの利用可能性に基づいて前記サーバを決定できるステップをさらに備える、請求項６５記載の方法。
67. 前記少なくとも１つのポリシーに対する考慮は、前記コンテンツプロバイダによって設定される、請求項１から４のいずれかに記載のフレームワーク。
68. 前記選択されたネットワークと関連する情報は、前記選択されたネットワークと関連するドメインネーム、または前記選択されたネットワークと関連するＣＮＡＭＥを含む、請求項１から４および６７のいずれかに記載のフレームワーク。
69. 前記少なくとも１つのポリシーに対する考慮は、前記ネットワークの各々に対する相対的負荷共有を特定する負荷共有ポリシーを含み、前記選択するステップは、前記負荷共有ポリシーを満たすように試みる、請求項１から４、６７および６８のいずれかに記載のフレームワーク。
70. 前記少なくとも１つのポリシーに対する考慮は、前記コンテンツプロバイダによって更新される、請求項１から４、６７から６９のいずれかに記載のフレームワーク。