(57)【特許請求の範囲】
【請求項１】
複数のコンテンツ配信ネットワークにおけるコンテンツ配信を管理する、少なくとも一つのレベル４のサービス管理装置と、
前記複数のコンテンツ配信ネットワークのいずれかであって複数のデータセンターを持つコンテンツ配信ネットワークにおけるコンテンツ配信を管理する、少なくとも一つのレベル３のサービス管理装置と、
前記複数のデータセンターのいずれかであって複数のサーバ・ファームまたは複数のサービス・エンジン・ファームがあるデータセンターにおけるコンテンツ配信を管理する、少なくとも一つのレベル２のサービス管理装置と、
前記複数のサーバ・ファームまたは前記複数のサービス・エンジン・ファームのコンテンツ配信を管理する、少なくとも一つのレベル１のサービス管理装置と、
を含み、
前記レベル１及至４のサービス管理装置の各々は、上位レベルのサービス管理装置と下位レベルのサービス管理装置との間でディレクトリ・ゲートウェイ・プロトコルによる通信を確立し、
前記レベル３のサービス管理装置は、ユーザのリクエストを地理的負荷の均衡として異なるデータセンターへ導くＤＮＳ（Domain Name System）サーバとして運用するよう管理されることを特徴とする、ディレクトリ・イネーブル・ネットワークによる階層的なサービスおよびコンテンツの配信の管理のためのネットワーク・システム。
【請求項２】
前記サーバ・ファームに含まれるサーバの各々は、前記レベル２のサービス管理装置におけるマルチキャスト・オペレーションに対応するローカル・エリア・ネットワークに接続することを特徴とする請求項１に記載の、ディレクトリ・イネーブル・ネットワークによる階層的なサービスおよびコンテンツの配信の管理のためのネットワーク・システム。
【請求項３】
前記サーバ・ファームに含まれるサーバの各々は、インフィニバンド・スイッチと接続することを特徴とする請求項１または２に記載の、ディレクトリ・イネーブル・ネットワークによる階層的なサービスおよびコンテンツの配信の管理のためのネットワーク・システム。
【請求項４】
前記データセンターとの間にＶＰＮ（Virtual Private Network）を形成するように、前記データセンターを通過したデータがプライバシとセキュリティを保証するためＩＰＳＥＣ（Security Architecture for Internet Protocol）トンネルを通過することを特徴とする請求項１から３のいずれかに記載の、ディレクトリ・イネーブル・ネットワークによる階層的なサービスおよびコンテンツの配信の管理のためのネットワーク・システム。
【請求項５】
複数のコンテンツ配信ネットワークにおけるコンテント位置情報を保存する、少なくとも一つのレベル４のサービス管理装置と、
前記複数のコンテンツ配信ネットワークのいずれかであって、複数のデータセンターを持つコンテンツ配信ネットワークにおけるコンテント位置情報を保存する、少なくとも一つのレベル３のサービス管理装置と、
前記複数のデータセンターのうちの一つであって、複数のサーバ・ファームまたは複数のサービス・エンジン・ファームがあるデータセンターにおけるコンテント位置情報を保存する、少なくとも一つのレベル２のサービス管理装置と、
前記複数のサーバ・ファームまたは前記複数のサービス・エンジン・ファームのコンテント位置情報を保存する、少なくとも一つのレベル１のサービス管理装置と、
を含み、
少なくとも一つのレベル１のサービス管理装置と、少なくとも一つのレベル２のサービス管理装置が、ＬＡＮマルチキャストおよびリンク・ステート・ルーティング・プロトコルのサービス情報が満載されたオペーク・リンク・ステート・パケットを介して設けられ、
前記レベル１及至４のサービス管理装置の各々は、上位レベルのサービス管理装置と下位レベルのサービス管理装置との間でディレクトリ・ゲートウェイ・プロトコルによる通信を確立し、
前記レベル３のサービス管理装置は、ユーザのリクエストを地理的負荷の均衡として異なるデータセンターへ導くＤＮＳ（Domain Name System）サーバとして運用するよう管理されることを特徴とする、ディレクトリ・イネーブル・ネットワークによる階層的なサービスおよびコンテンツの配信の管理のためのネットワーク・システム。
【請求項６】
前記サーバ・ファームに含まれるサーバの各々は、前記レベル２のサービス管理装置におけるマルチキャスト・オペレーションに対応するローカル・エリア・ネットワークに接続することを特徴とする請求項５に記載の、ディレクトリ・イネーブル・ネットワークによる階層的サービスおよびコンテンツ配信の管理のためのネットワーク・システム。
【請求項７】
前記サーバ・ファームに含まれるサーバの各々は、インフィニバンド・スイッチと接続することを特徴とする請求項５または６に記載の、ディレクトリ・イネーブル・ネットワークによる階層的なサービスおよびコンテンツの配信の管理のためのネットワーク・システム。
【請求項８】
前記データセンターとの間にＶＰＮ（Virtual Private Network）を形成するように、前記データセンターを通過したデータがプライバシとセキュリティを保証するためＩＰＳＥＣ（Security Architecture for Internet Protocol）トンネルを通過することを特徴とする請求項５から７のいずれかに記載の、ディレクトリ・イネーブル・ネットワークによる階層的なサービスおよびコンテンツの配信の管理のためのネットワーク・システム。
【請求項９】
少なくとも一つのレベル４のサービス管理装置において、複数のコンテンツ配信ネットワークにおけるコンテント位置情報を保存するステップと、
少なくとも一つのレベル３のサービス管理装置において、前記複数のコンテンツ配信ネットワークのいずれかであって、複数のデータセンターを有するコンテンツ配信ネットワークにおけるコンテント位置情報を保存するステップと、
少なくとも一つのレベル２のサービス管理装置において、前記複数のデータセンターのいずれかであって、複数のサーバ・ファームまたは複数のサービス・エンジン・ファームがあるデータセンターにおけるコンテント位置情報を保存するステップと、
少なくとも一つのレベル１のサービス管理装置において、前記複数のサーバ・ファームまたは前記複数のサービス・エンジン・ファームのコンテント位置情報を保存するステップと、
前記レベル１及至４のサービス管理装置の各々において、上位レベルのサービス管理装置と下位レベルのサービス管理装置との間でディレクトリ・ゲートウェイ・プロトコルによる通信を確立するステップと、
を含むことを特徴とする、ディレクトリ・イネーブル・ネットワークによる階層的なサービスおよびコンテンツの配信の管理の方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はサービスのルーティング・インフォメーションを交換するためのシステムおよび方法にかかわる。特に階層的サービスネットワーク・インフラストラクチャ・デザイン（Hierarchical service network infrastructure design）を用い、プロトコルの利用によりコンテンツ配信ネットワークのパフォーマンスを大幅に改善し、ディレクトリ・イネーブル・ネットワークによる階層的サービス及びコンテンツ配信を管理するためのシステムおよび方法である。
【０００２】
【従来の技術】
Ｂ２Ｂ（Business to Business）、Ｂ２Ｃ（Business to Consumer）及びＣ２Ｃ（Consumer to Consumer）これらのコミュニケーションに対してウェブは最もパワフルかつ重要なメディアの一つとなっている。インターネットの構成は中央サーバによりインターネットの各ポイントにコンテントあるいはサービスを転送し、ウェブ・トラフィックの急増は多くのウェブサーバ渋滞及びインターネット・トラフィック・ジャムを引き起こす。従って、多数の協同するコンテント・アウェア・ネットワーク装置を必要とするコンテンツ配信のネットワークは設計され、ユーザに近いコンテントを分配し、また要求に応じてサブスクライバに最も近いコンテントの位置を定める。
【０００３】
【発明が解決しようとする課題】
ＢＧＰというインターネット・ルーティング・プロトコルはルータの間に大型インターネット・ルーツ（Large Internet routes）を交換する設計となる。ＢＧＰはコネクション・オリエンテッド（connection oriented）で、外部のルーティング・プロトコルとしてＴＣＰの上で運転する。存続メッセージを通じて隣の連結を保有し、また連結期間に一致的ルーティング・インフォメーションをシンクロさせる。しかし、ＢＧＰはこのウェブサーバーセントリック・インターネット（web server centric Internet）に情報を交換しない。一つのサービス ( LDAPディレクトのフォーマットで) ルーティング・プロトコルを用いてサービス・情報を交換し、しかもディレクトリ・イネーブル・ネットワーク経由の階層方式でサービス及びコンテンツ配信の管理、コンテンツ配信ネットワークのパフォーマンスの改善、サービスの提供及び管理に役に立つ。
【０００４】
【課題を解決するための手段】
本発明は、階層サービス・ネットワークのインフラストラクチャー・デザインを用い、コンテンツ配信ネットワークのパフォーマンスを改善するための複数のレベルのある新規なネットワーク・システムを提供することを目的とする。
【０００５】
本発明は、次の跳びのない場合にフロー・アドバータイズメント（flow advertisement）を通して、サーバから回転可能のクライアントまでホップ・バイ・ホップ（hop by hop）の方式で良質コンテントをどう転送する一種の方法かつプロトコルを提供することを目的とする。
【０００６】
【発明の実施の形態】
前述とその他の目的に従って、本発明に提出された新規なネットワーク・システムかつ方法そのものはディレクトリ・イネーブル・ネットワーク経由で階層的サービス及びコンテンツ配信を管理する。このネットワーク・システムは下記の構成がある。
【０００７】
サーバは別件特許出願中のレベル１のサービス管理装置を用いてサービス・情報を交換する。
【０００８】
こういうスケーラブル・ネットワーク（scalable network）を管理するため、インターネット・ルーティングのコンセプトを利用する。ＢＧＰというインターネット・ルーティング・プロトコルは大型インターネット・ルートの間の交換のために設計される。このプロトコルは階層ツリーの構造の中に各サービス管理装置の間に情報を交換するゆえにより良いかつスケーラブルなサービス提供及び管理に役に立つ。このプロトコルによる情報の交換はＬＤＡＰ（Light Weight Directory Access Protocol）のポピュラー・インダストリ・スタンダードの一部となり、一般的なディレクトリ・インフォメーション・スキーマ・フォーマットと定義される。このプロトコルはＤＧＰ（Directory Gateway Protocol）と名づけ、ティレクトリ・インフォメーション・ルーティング・プロトコルでもある。ディレクトリ・インフォメーションの交換がＤＧＰの親サービス管理装置と子サービス管理装置の間に行われる以外に、ＤＧＰは外部のルーティング・プロトコルとのＢＧＰに類似する。一方、ＢＧＰは隣とＩＰのルート・インフォメーションを交換する。ＢＧＰに類似するように、ＤＧＰはコネクション・オリエンテッドで、ＴＣＰの上で動作し、連結期間を経て隣同士の連結を持続させ、キープ・アライブ・メッセージを通じて一致するディレクトリ・インフォメーションをシンクロさせる。複数のデータ・センターにあるロード・バランスの中プロックシミティの計算とデータ・センターのローディング・ファクタが提案され、ＤＮＳがサブスクライバに反応する時にＤＮＳに使われてベスト・データ・センターを選択する。ＬＡＮの環境にサーバ装置まで情報を同時にアップデートするかつパフォーマンスを改善するために、一種のリライアブル・マルチキャスト・トランスポート・プロトコル（Multicast Transport Protocol）が提供される。このリライアブル・マルチキャスト・トランスポート・プロトコルの上に動作する一種のリライアブル・マルチキャスト・ディレクトリ・アップデート・プロトコルも提供され、スタンダードのＬＤＡＰオペレーションのようにディレクトリ・インフォメーションをマルチキャスティングすることによってパフォーマンスを改善する。このサービス・ネットワークをより効果的に管理するために、リライアブル・マルチキャスト・マネジメント・プロトコル（Reliable Multicast Management Protocol）も提供され、マネジメント・インフォメーションをサービス・デバイスまで転送するとともに同時にパフォーマンスを改善しかつマネジメント・オペレーション・コストを減少させる。コンテントをサブスクライバの近くにプッシュするため、キャッシュの利用は効果的であり、しかしキャッシュ・コンテントはオリジナル・サーバに一致させなければならない。ＤＧＰの伝達による一種のキャッシュ・インバリュデーションの方法は発明され、このコンテンツ配信ネットワークのキャッシュの新鮮度を維持することに役に立つ。このネットワークをより効果的に管理するため、サービス・エンジンのダイナミック・ディスカバリの方法として、ＬＡＮマルチキャスト（LAN multicast）とリンク・ステート・ルーティング・プロトコル (Link state routing protocol) のサービス情報が満載されオペーク・リンク・ステート・パケット（opaque link state packet）によって、レベル１のサービス管理装置及びレベル２のサービス管理装置が提供される。
【０００９】
ストリーミング・メディア・コンテンツ（streaming media content）という品質要望に満たすコンテンツ配信をサポートするために、フロー広告（次の跳びのない場合に）を通して、サービス・エンジンから回転可能のクライアントまでホップ・バイ・ホップ（hop by hop）の方式でコンテントを分配する方法が提供される。しかも他のスタンダードＬＡＮのあるかどうかあるいはＩＰのトラフィック・エンジニアリング関連のプロトコルと動作し合う。
【００１０】
ネットワークシステムのレイヤ
本発明のネットワークシステムのレイヤの具体例として、図１と図２と図３のように、図１は本発明のシステムによる複数のＣＤＮネットワークのコンテント・ピアリングを示す図である。この階層的ディレクトリ・イネーブル・ネットワークは安全なコンテンツ配信及び他のサービスを提供する。
【００１１】
このネットワークのサービス
ウェブ及びストリーミング・コンテンツ配信サービス（streaming content hosting service）、
ウェブ及びストリーミング・コンテント・ホスティング・サービス、
ＩＰＳＥＣ ＶＰＮサービス、
マネージッド・ファイアウォール・サービス（managed firewall service）、
将来にその他の新しいＩＰサービス。
【００１２】
階層的スケラブルな統合サービス・ネットワークHSISNの構成要素（Hierarchical Scalable Integrated Service Networks）
ａ．デバイス
統合サービス・スウィッチ（Integrated Service Switch,ＩＳＳ）：
ＩＰスウィッチ（サービス及びフロー仕様に基づいてＩＰトラフィックを転送する）。
サービス・エンジン（サーバ）：
サービス・システム（特殊ハードウェアに伴う）、ＨＴＴＰをプロセスする、キャッシュ、ＩＰＳＥＣ、ファイアウォール、プロクシなど。
サービス管理装置：
一種の選定されたシステムがマネジメント・エイジェントとなる、しかもＬＤＡＰサーバとしてＬＤＡＰのサーチ・サービス及びディレクトリ・ゲートウェー・プロトコルとして親のと子のサービス管理装置と動作し合ってディレクトリ・インフォメーションを交換する。
ＬＤＡＰの枠組み：
ディレクトリ・インフォメーションの定義として、サービス管理装置に交換され、ＬＤＡＰクライアントにサーチされる。
ＳＮＭＰ ＭＩＢ：
マネジメント・インフォメーションの定義として、ＳＮＭＰネットワークマネージャーとエイジェントの間に使用される。
【００１３】
プロトコル
スタンダード・プロトコル
現行のルーティング・プロトコル（ＯＳＰＦ、ＢＧＰ）はＩＳＳの上に作業し、ネットワークにある他のルータとのインターオペレーションが行われる。
各サーバＬＤＡＰをクライアントとして作業し、サービス管理装置もサービス・エンジンＬＤＡＰサーチ・リクエストにサーブするようにＬＤＡＰサーバとして動作する。
【００１４】
発明のプロトコル
サービス・インフォメーション・プロトコル（別件に特許出願中）
図６のように、ＩＳＳとサービス・エンジンとレベル１のサービス管理装置の間のＬＡＮ或いはインフィニバンド（一種のサーバの新しいＩ／Ｏ仕様）の環境に
１．  登録／非登録／更新サービスとサービスの特性
２．  サービス・コントロール広告 − サービス・エンジンの渋滞、リダイレクトなど。
【００１５】
無制限のサービス・エンジンがサポートされる（複数のボックスできわめて高いスケーラビリティがある）。これらの広告のもとにＩＳＳがメッセージを得られるサービス・エンジンまで転送するゆえに、サービス・コントロール広告は各サービス・エンジンの間にダイナミックにロード・バランスできる。ＩＳＳとサービス・エンジンとの間のキープ・アライブ・メッセージ（keep-alive message）は欠陥のある装置の検出に役に立つ。それでＩＳＳはその得られるサービス・エンジン・リストから外される。
【００１６】
フロー通告のプロトコル (Flow advertisement protocol)（別件に特許出願中）
サービス・エンジンから始めてＩＳＳまで（アプリケーション向きのフローあるいはセッション）
１．  ＩＳＳにフローを設立し、フロー・スウィッチングを許す。
２．  フローがフロー属性付きである。ＱｏＳがその属性の一つであり、他のフロー属性も可能。
フローの属性のＱｏＳとは、ストリーミング・コンテント・クォリティ・デリバリの要件を強化する。フローはＩＳＳによって外部のネットワークにマップできる。現存のあるいはＭＰＬＳ、ＤｉｆｆＳｅｖ、８０２．ｌｐ、ケーブルモデムSIDという将来の標準まで。
【００１７】
アサインド・ナンバー・オーソリティ・プロトコル（Assigned Numbers Authority Protocol ）（別件の特許出願中）
サブネットあるいはＬＡＮあるいは無限帯域までのグローバル・アサインに必要とするあらゆる数字である。たとえば、ＩＰアドレスプール（IP address pool）、ＭＰＬＳラベル・レンジ（MPLS label range）、グローバル・インターフェース・ナンバー（global interface number）、ＨＴＴＰクッキーズ（HTTP cookies）などがある。指名されたサービス管理装置は各サブネット（ＩＳＳを含むサービス・エンジン・ファームの代理として）に選抜されるパケット・パターン・マッチングの方式によるサービス・タイプは代表され、違う種類のサービス・エンジンが同一のサブネットにミックスされるあるいはすべての違う種類のサービス・エンジンが同一のサービス管理装置に代表される。
【００１８】
ディレクトリ・ゲートウェー・プロトコル（ＤＧＰ）
図１のように、複数のＣＤＮネットワークのためのコンテント・ピアリングのイラストレーション、図２、３のように複数のデータ・センターの統合サービス・ネットワークをイラストする。ディレクトリ・ゲートウェー・プロトコル（ＤＧＰ）はディレクトリ・インフォメーション・ルーティング・プロトコルと定義される。
ディレクトリインフォメーションフォーワーディングポリシによるが、典型的にレベル４のサービスマネージャーがＣＤＮ１、ＣＤＮ２及びＣＤＮ３のコンテント位置情報を保存する。ＣＤＮ１のレベル３のサービスマネージャーがＣＤＮ１のコンテント位置情報しか保存しない。ＣＤＮ２のレベル３のサービスマネージャーがＣＮＤ２のコンテント位置情報しか保存しない。ＣＤＮ３のレベル３のサービスマネージャーがＣＮＤ３のコンテント位置情報しか保存しない。
ディレクトリインフォメーションフォーワーディングポリシによるが、典型的にレベル３のサービスマネージャーがデータセンター１、データセンター２及びデータセンター３のコンテント位置情報を保存する。データセンター１のレベル２のサービスマネージャーがデータセンター１のコンテント位置情報だけを保存する。データセンター２のレベル２のサービスマネージャーがデータセンター２のコンテント位置情報だけを保存する。データセンター３のレベル２のサービスマネージャーがデータセンター３のコンテント位置情報だけを保存する。データセンターに通過したデータがＩＳＰＥＣトンネルを通ってプライバシ及びセキューリティを保証するあるいはさらにデータセンターの間にＶＰＮを生成する。
ＩＰルーツがＢＧＰの隣同士の間に交換するではなく、ディレクトリ・インフォメーションをＤＧＰの親と子の間に交換する以外に、ディレクトリ・ゲートウェー・プロトコルは外部のルーティング・プロトコルＢＧＰに類似するコンセプトを利用する。ＢＧＰに類似するように、ディレクトリ・ゲートウェー・プロトコルはそのコネクション・オリエンテッドかつＴＣＰの上に動作することによって、連結期間を通ってキープアライブ・メッセージ経由で隣同士の連結を維持するともに一致するディレクトリ・インフォメーションをシンクロ化する。しかし、もし親と子サービス管理装置の両者は同時にＤＧＰの連結を始めようとすると、ＤＧＰの連結は親サービス管理装置から子サービス管理装置まで始めるという連結衝突を防ぐ。フォワーディング・ループ を防ぐため、同じレベルのサービス管理装置の間の連結を許さない。冗長性の理由で多数の親サービス管理装置は同じ子サービス管理装置に連結すると子サービス管理装置にＬＤＡＰのサーチ・サービスを提供するには複数のバックアップが可能であるが、これは親と子サービスマネージャーの間だけを許す。
レベル１のサービス管理装置（一つのサービス・サブネットを代表して）は自分の親サービス管理装置（レベル２のサービス管理装置）との間にＤＧＰ連結が成立する。通常はレベル２のサービス管理装置は全体のデータ・センターを代表して動作する。
【００１９】
レベル２のサービス管理装置も自分の親サービスマネージャー（レベル３のサービス管理装置）との間にＤＧＰ連結を成立する。通常は一つのサーバ・ファームのサービス管理装置も自分の親サービス管理装置（レベル２あるいはレベル３のサービス管理装置）との間にＤＧＰ連結が成立する。
【００２０】
レベル３のサービス管理装置は通常ＤＮＳサーバとしてユーザのリクエストを違うデータ・センターへ引導する。それて地理的なロード・バランスになる。ＤＧＰインクリメンタルアップデーツ（DGP incremental updates）とプロックシミティ（proximity）からサブスクライバへの接近性という他の属性を通ってサービス・データ・センターによる更新されたサービス・ローディングの属性に基づいて、このＤＮＳの再引導の決定が成立する。
【００２１】
それぞれのディレクトリ・インフォメーション・フォワォーディング・ポリシ（directory information forwarding policy）に基づいて最初のＤＧＰの連結はディレクトリ・インフォメーションを交換する；この最初の交換の後に各サービス管理装置は自分のディレクトリ・インフォメーション・サービスとサービスの属性、コンテントとコンテントの属性などをもう一方のサイドまで増値的（増加するあるいは引き出す）に更新するだけ。サービス管理装置が代表するサービス・ドメインのローディング・ファクタ（反応時間）はサービス属性の一つであり、キャッシュ・コンテント・ロケーションを含めるコンテント・ロケーションはコンテントの属性の一つである。ＤＧＰのパケット・タイプはＯＰＥＮ、ＬＤＡＰ＿ＡＤＤ、ＬＤＡＰ＿ＤＥＬＥＴＥ、ＬＤＡＰ＿ＭＯＤＩＦＹ＿ＡＤＤ、ＬＤＡＰ＿ＭＯＤＩＦＹ＿ＲＥＰＬＡＣＥ、ＬＤＡＰ＿ＭＯＤＩＦＹ＿ＤＥＬＥＴＥ、ＮＯＴＩＦＩＣＡＴＩＯＮとＫＥＥＰＡＬＩＶＥである。
【００２２】
コンテント・チェンジはそのコンテントのコンテント属性（コンテントタイム）の変更と見なし、キャッシュ・コンテントを含むキャッシュ・サーバーに伝送される。頻繁に変更されるコンテントに対して（ＢＧＰのように）ＤＧＰが頻繁に変更されるディレクトリ・インフォメーションの伝送を抑えるディレクトリ・インフォメーション・ダンピングをサポートする。ＢＧＰのように、ＤＧＰもポリシ・ベース的に親と子サービス管理装置との間のフォワーディングをサポートする。フォワーディングする前にアグリゲーション・ポリシを用いてディレクトリ・インフォメーションを収集することが好ましい。また、ＢＧＰのように、ＴＣＰ ＭＤ５が認証に使用される。
【００２３】
接近度（proximity）の計算
上述のように、これは各データ・センターに更新されたサービス・ローディングの属性と共に使用される。ＤＮＳサーバがユーザ・リクエストをベストサービスデータセンターまで導引することを地理的ローディング・バランスと見なされる。各ＩＰデスティネーション（ＩＰルート、アドレスとマスク）は一つの（ｘ,ｙ）属性に指定され、ｘは地球の経度（-180 と+180の間、地球は球状で-180 と+180は同じ場所）とｙ（-90 と+90の間）は地球の緯度を意味するが、ＩＰデスティネーションは物理的に地球に置かれる所というのである。
【００２４】
サブスクライバのソース・アドレスが（ｘ１，ｙ１）属性を有するＩＰデスティネーションのもっとも長いプリフィックスにマッチする及びデータ・センターのＩＰアドレスプリフィックスが（ｘ２，ｙ２）の属性を有すると仮定する。
【００２５】
もし、|ｘ１−ｘ２|<=１８０、サブスクライバとデータセンターとの間の距離が
（（ｘ１−ｘ２）２＋（ｙ１−ｙ２）２）１/２）となる。
【００２６】
もし、|ｘ１−ｘ２|>１８０、サブスクライバとデータ・センターとの間の距離が
（（３６０−（|ｘ１−ｘ２|））２＋（ｙ１−ｙ２）２）１/２）。
【００２７】
（ｘ，ｙ）とのルート属性がＩＥＴＦに提案され、ＢＧＰのルート属性の延長と見なされる。
図４において、レベル２のサービス管理装置がキャッシュサーバファーム１とキャッシュサーバファーム２の（キャッシュ）コンテント位置情報を保存する。キャッシュサーバファーム１のレベル１のサーバマネージャーがキャッシュサーバファーム１の（キャッシュ）コンテント位置情報しか保存しない。キャッシュサーバファーム２のレベル１サーバマネージャーがキャッシュサーバファーム２の（キャッシュ）コンテント位置情報しか保存しない。
【００２８】
リライアブル・マルチキャスト・トランスポート・プロトコル（Reliable Multicast Transport Protocol）
図５のサービス・マネージャ・ファーム（Service Manager Farm）にあるディレクトリ・インフォメーション・マルチチャスト・アップデートと図７のリライアブル・マルチキャスト・トランスポート・プロトコル・シークエンスによって、リライアブル・マルチキャスト・トランスポート・プロトコルを用いて、マルチキャスト可能のネットワークにあるサービス・デバイスまで同時にインフォメーションを更新するとともにパフォーマンスを改善するという目的に満足できる。それはＴＣＰに類似するがスリーウェー・ハンドシェークではなくツーウェー（発送と承認のハンドシェーク）の方式で発送者とすべての受領者との間に定義され、連結が成立する。それで、サービス管理装置がウィンドウ・サイズ（パケットにある）を確定する。例えば、発送者が承認なしにメッセージを発送できる。ウィンドウ・サイズがサービスの属性の一つとしてそれぞれのサービス・エンジンによってサービス管理装置まで登録される。サービス管理装置が各受領者に登録されたウィンドウ・サイズのサービスの属性の中から最も低いバリューを選択する。各ウィンドウ側にサービス管理装置もすべての他の受領者の代表として受領の承認を担当する。サービス管理装置が承認を発送する前に沈黙期間(コンフィギアブル・バリューが可能)を待つ。もし受領者がシークエンスパケットから何かを検出したら、あるいはタイムアウトでコンフィギアブル・バリューに何らかのパケットの受領がない状態で、受領者がスターティング・シークエンス・ナンバーからリセンド・リクエストを発送しなければならない。発送者が特定のリセンド・リクエスト・ナンバーをリセンドするあるいは連結を中止する、そしてリスタートをする。連結が中止されない限りには受領者が受取ったパケットをおろす。最後のパケットがすべての受領者だけでなくサービス管理装置に承認され、連結の正常中止を表示できる。もし、サービス管理装置がいずれかの受領者がタイムアウト以内に最後のパケットを承認しないことを検出したら、サービス管理装置がその最後のパケットをその受領者（一つのユニキャスト・パケット）にリクエストをリセンドする。もし、３回のリセンドがトライされたら、そのデバイスが無効と宣告され、サービス管理装置にサービス・エンジン・リストから外される。もし、一つのパケットだけ伝送されたら、このプロトコルが信頼できるデータ・グラム・プロトコルとなる。ウィンドウ・サイズが承認のない未処理のパケットと定義される。承認とリセンド・リクエストの両者はサービス管理装置の監督を認めるマルチキャスト・パケットである。
図８において、この放棄のオペレーションが何らかの原因でも発送者のマルチキャストオペレーションの放棄を許す。これはトランスポートマルチキャストの放棄メッセージを発送すると他のものとＳＭに確認される。ＳＭが他のものが確認してから確認する。
【００２９】
リライアブル・マルチキャスト・ディレクトリ・アップデート・プロトコル（Reliable Multicast Directory Update Protocol）
図９のように、リライアブル・マルチキャスト・ディレクトリ・アップデート・プロトコルがイラストレートされる。これはリライアブル・マルチキャスト・トランスポート・プロトコルの上に動作する。トランスポート・レイヤがリライアブル・マルチキャスト・トランスポート・プロトコルである以外に、このプロトコルはＬＤＡＰのようにＴＣＰの上に動作する。
【００３０】
リライアブル・マルチキャスト・マネジメント・プロトコル（Reliable Multicast Management Protocol）
図１０のように、リライアブル・マルチキャスト・マネジメント・プロトコル・シークエンスがイラストレートされる。リライアブル・マルチキャスト・マネジメント・プロトコル・シークエンスがリライアブル・マルチキャスト・トランスポート・プロトコルの上に動作する。一つのパケットだけ伝送されるため、このプロトコルがリライアブル・マルチキャスト・データ・グラム・プロトコルになる。トランスポート・レイヤがマルチキャストとリライアビリティ・サービスを提供する以外に、このプロトコルはＳＮＭＰのようにイーサネット（登録商標）の上に動作する。
【００３１】
階層的マネジメント・インフォメーション（Hierarchical Management Information）及びマネジメントの方法
マネジメント・エイジェントがサービス管理装置の一部となる。ポリシ・ベース（policy-based）のサービス・マネジメントに対して、マネジメント・インフォメーションが違うレベルで定義される。マネジメント・インフォメーションの収集はレベルから次のレベルに執行される。例えば、ウェブ・ページ・ヒット（web page hit）の数について、ぞれぞれのキャッシュ・サービス・エンジンにカウンターが付きかつ全体のレベル１のサービス・エンジン・ファームあるいは全体のデータ・センターに一つのトータル・カウンターが付く。
【００３２】
コンフィギアレーション・マネジメント・インフォメーションに対して、コンフィギアレーションも違うレベルで定義される。例えば、デフォルト・ルータ・コンフィギアレーションが同じのサブネットに対応するが、ＤＮＳサーバが全体のデータ・センターに対応する。レベル１のサービス管理装置がデフォルト・ルータ・コンフィギアレーションを全体のサブネットまでマルチキャストすることを担当するが、レベル２のサービス管理装置が自分のデータ・センター・レベル・コンフィギアレーションを表示し、ＤＮＳサーバー・コンフィギアレーションをレベル１のサービス管理装置に伝送する。それから、レベル１のサービス管理装置が自分のサブネットにある自分のメンバーをマルチキャストする。低いレベルのコンフィギアレーションのポリシが高いのポリシと衝突してはいけない。衝突するなら、高いレベルのポリシが低いレベルのコンフィギアレーションのポリシを優先にする。
【００３３】
ディレクトリ・スキーマ（Directory schema）とＳＮＭＰ ＭＩＢ
ディレクトリ・インフォメーション・スキマとＳＮＭＰ ＭＩＢがこの階層的スケラブル統合ネットワーク（ＨＳＩＳＮ）にサポートすると定義される。
ウェブ・サイト物件
ウェブ・コンテント物件
サービス・エンジン物件
統合サービス・スウィッチ物件
ユーザ物件
例として、他の物件がと次のＵＲＬを使用する。
http://vision.yahoo.com/web/ie/fv.html
【００３４】
ウェブ・サイト・オブジェクト（オリジンあるいはキャッシュ）
オリジン・ウェブ・サイト
ＤＮ（Distinguished Name）：http, vision, yahoo, com
属性：
サービス・サイト・ＩＰ・アドレス
【００３５】
キャッシュ・サービス・サイト
ＤＮ（Distinguished Name）：subnet1, DataCenter2, CDN3
属性：
サービス・サイト・ＩＰ・アドレス
【００３６】
ウェブ・サイト物件の新しいエントリの生成
オリジン・サイトがＤＧＰ ＬＤＡＰ＿ＡＤＤ ＤＮ：http, vision, yahoo, comをレベル３のサービス管理装置まで送すると新しいエントリを追加する。
【００３７】
ウェブ・サイト物件のエントリ・モディフィケーション
サービス・レベル・アグリーメント（service level agreement）に基づいて、レベル３のサービス管理装置がＤＧＰ ＬＤＡＰ＿ＭＯＤＩＦＹ＿ＡＤＤにサービス・サイト・ロケーションのウェブ・サイトの物件エントリの属性を発送する。これらのＩＰアドレスがvision.yahoo.comのＤＮＳ・エントリ・リストに追加する。
【００３８】
vision.yahoo.comを担当するＹａｈｏｏのＤＮＳサーバがＤＮＳのリクエストをレベル３のサービス管理装置のＤＮＳに参照しなければならない。レベル３のサービス管理装置のＤＮＳが他のポリシに基づいて最低のサービス・メトリックを持つサービス・サイトのＩＰアドレスをサブスクライバまで応答する。
【００３９】
キャッシュ・ウェブ・サイト・セレクションがキャッシュ・ウェブ・サイトからサブスクライバまでのベストの反応に基づく。
ビデオベースのフィナンシャル・ページ付きＹａｈｏｏウェブ・サイトを例とする。
http://vision.yahoo.com/web/ie/fv.html
【００４０】
インターネット・アクセス・プロバイダーのＤＮＳサーバがvision.yahoo.comのためにYahooのＤＮＳサーバに参照する。YahooのＤＮＳサーバがコンテント・ディストリビューション・サービス・プロバイダーのレベル３のサービス・マネージャーに参照する。
【００４１】
各データセンターが一つあるいはそれ以上のサービス・ウェブ・サイトを持つが各サービス・ウェブ・サイトが仮想のＩＰアドレス付きのサーバ・ファームによってサーブされる。もしvision.yahoo.comの複数のキャッシュ・サービス・サイトがあればそのすべてはvision.yahoo.comにサーブする。（例えば、サイト１の216.136.131.74とサイト２の216.136.131.99）。それはそのサイトの中に一つを選択しポリシ・ベースのＤＮＳの応答とする。仮定に216.136.131.74がＤＮＳに選択され、サブスクライバに対する反応と見なす。
【００４２】
サブスクライバがhttpリクエストをhttp://216.136.131.74/web/ie/fv.htmlとして発送する。
【００４３】
サービス・メトリック（Service metric）
サービス・メトリックがサブクライバ１からサイト１までのサービス・メトリックが現行の平均サーバ・サービスの反応時間であり、サブスクライバからサイト１までのサイト１＋ウェート＊現行の接近度で計算をする。そのウェートはポリシに基づいて装備される。サイト１は現行の接近度を上記の計算式で計算する。レベル１のサービス管理装置のサイト１がサービス・エンジンによってキープ・アライブ・メッセージにある各サーバの反応時間を受取り、このサイトのローディング・ファクタとなるサーバによって現行の平均サービスの反応時間を計算する。
【００４４】
ウェブ・コンテント物件（オリジンあるいはキャッシュサイトにある）
ＤＮ：fv.html,ie,web,http,vision,yahoo,com
属性：
オリジナル・コンテント・ロケーション：オリジン・サーバのＩＰアドレス
キャッシュ・コンテント・ロケーション：
キャッシュ・サイト１のＤＮ、サイト１にこのコンテントをもつキャッシュ・サービス・エンジンの数、キャッシュ・サービス・サイト２のＤＮ、サイト２にこのコンテントをもつキャッシュ・サービス・エンジンの数、キャッシュ・サービス・サイト３１のＤＮ、サイト３１にこのコンテントをもつキャッシュ・サービス・エンジンの数、キャッシュ・サービス・サイト４１のＤＮ．．．．．
レベル１のサービス・マネージャにあるキャッシュ・コンテント・サービス・エンジンのＭＡＣアドレス：
サービス・エンジン１ＭＡＣ（レベル１のサービス管理装置だけに応用する）、
サービス・エンジン２ＭＡＣ（レベル１のサービス管理装置だけに応用する）、
．．．．．
キャッシュ・コンテントをもつキャッシュ・サービス・エンジンの数
コンテントの最終変更の日付と時間：
コンテントの有効期限と時間：
…
【００４５】
サービス・エンジン物件
ＤＮ：ＩＰアドレス、サブネット１、データ・センター２、ＣＤＮ３
属性：
サービス・タイプ：
サービス・エンジン・ネーム：
サービス・エンジン・サブネット・マスク：
サービス・エンジンＭＡＣアドレス：
サービス・エンジン・セキューリティ・ポリシ：違うデータ・センターの場合はＳＳＬを使う
サービス管理装置ＩＰアドレス：
サービス・エンジン認証：
【００４６】
統合サービス・スウィッチ物件
ＤＮ：サーバ・ファーム・インターフェースの上にあるＩＰアドレス、サブネット１、データ・センター２，ＣＤＮ３
属性：
スウィッチ・タイプ：
スウィッチＩＰアドレス：
スウィッチＭＡＣアドレス：
サービス管理装置ＩＰアドレス：
スウィッチ認証：
【００４７】
ユーザ物件
ＤＮ：名前、組織、国
属性：
住所：
Ｅメール・アドレス：
ユーザ認証：
銀行口座記録：
【００４８】
ウェブ・コンテント物件のニュー・エントリの生成と変更
サービス合意書に基いて、オリジン・サイトがＤＧＰ ＬＤＡＰ＿ＡＤＤ ＤＮ：fv.html, ie, web, http, vision, yahoo, comをレベル３サービス管理装置まで発送する。ＤＮＳが216.135.131.74を反応として発送する、そしてサブスクライバがhttpリクエストをhttp://216.136.131.74/web/ie/fv.htmlとして発送する。
【００４９】
本出願人の別の特許に基づいて、この仮想のＩＰアドレスの統合サービス・スウィッチがそのリクエストをより渋滞しないキャッシュ・サービス・エンジンに導引し、キャッシュ・エンジンが選択される。もしコンテントがキャッシュ・エンジン１にないとＬＤＡＰサーチ・リクエストをレベル１のサービス管理装置まで発送する。もしレベル１のサービス・マネージャーがコンテントも持ってないと、自分のレベル２のサービス管理装置に参照する。もしレベル２のサービス・マネージャーがコンテントも持ってないと、自分のレベル３のサービス管理装置に参照する。レベル３のサービス管理装置がオリジン・サーバＩＰアドレスの属性に戻り、キャッシュできるかどうかと他のコンテント属性を表示する。それはキャッシュ可能ではない、キャッシュ・エンジン１がサブスクライバをオリジン・サーバにhttp方式で再導引する。
【００５０】
それはキャッシュ可能のコンテントであれば、キャッシュ・エンジン１がサブクラバの代理として、新しいhttpセッションをオリジン・サーバに起動する。オリジン・サーバからのhttp反応にコンテントがキャッシュ可能と確定されたら、キャッシュ・エンジン１がそのコンテントをキャッシュできる。リダイレクトメッセージもＲＴＳＰにサポートされるが他の現存のアプリケーションプロトコルにサポートされない場合もある。そのコンテントがキャッシュされるとＤＮ：fv.html, ie, web, http, vision, yahoo, comの物件をレベル１のサービス管理装置にＬＤＡＰ＿ＡＤＤする。レベル１のサービス管理装置にその物件が発見されなければ、ＤＮ：fv.html, ie, web, http, vision, yahoo, comを自分のキャッシュ・コンテント・ロケーション（サービス・エンジンのＤＮ）の属性で追加する。レベル１のサービス管理装置に物件が発見されたら、その物件が新しいキャッシュ・コンテント・ロケーションの属性として変更される。レベル１のサービス管理装置がレベル２のサービス管理装置までＤＧＰ ＬＤＡＰ＿ＡＤＤあるいはＤＧＰ ＬＤＡＰ＿ＭＯＤＩＦＹ＿ＡＤＤ ＤＮ：fv.html, ie, web, http, vision, yahoo, comを動作する。そしてレベル２のサービス管理装置がレベル３のサービス管理装置ＤＧＰ ＬＤＡＰ＿ＡＤＤあるいはＤＧＰ ＬＤＡＰ＿ＭＯＤＩＦＹ＿ＡＤＤ ＤＮ：fv.html, ie, web, http, vision, yahoo, comを動作する。
【００５１】
キャッシュ・ロケーション・ダイレクトリ・インフォメーション・アップデートの更新は一種の誘発的な更新操作であり、その更新はＬＤＡＰサーバの内に現行のレプリケーション・プロセスに使用される定期的シンクロ化プロセスよりはるかに快速でなければならない。
【００５２】
最も近いロケーション（オリジンあるいはキャッシュ）からのコンテント・リトリーバル  隣のキャッシュ・サービス・エンジンからのリトリーバルが同じＬＡＮに同一のレベル１のサービス管理装置によって管理される。もし、別のサブスクライバがhttpリクエストhttp://216.136.131.74/web/ie/fv.htmlとしてを発送し、そのhttpリクエストが統合サービス・スウィッチによってサービス・エンジン２に伝送される。そのサービス・エンジン２はサービス・エンジン１のようにレベル１サービス管理装置（ＬＤＡＰサーバでもあり）の下に管理される。コンテントのないサービス・エンジン２は自分のレベル１のサービス管理装置からＬＤＡＰ＿ＳＥＡＲＣＨするとレベル１のサービス・マネージャーはサービス・エンジン１でその属性を返答し、コンテント・キャッシュ・ロケーション（content cashed location）となる。
【００５３】
それはキャッシュ可能コンテントであり、サービス・エンジン２がサブスクライバの代理として新しいhttpセッションをオリジン・サーバでなくサービス・エンジン１まで起動する。その上、コンテントをサブスクライバに返答する以外にコンテントをキャッシュする。一旦コンテントがキャッシュされたらサービス・エンジン２がＬＤＡＰ＿ＭＯＤＩＦＹ＿ＡＤＤするとそのコンテント属性に別のキャッシュ・ロケーション（自分自身）を追加する。
【００５４】
隣りのサイトからのリトリーバルが全体のデータ・センターの同じのレベル２のサービス・マネージャーに管理される。httpリクエストを第2サービス・サイト。例えばhttp：//216.136.131.99/web/ie/fv.htmlに発送する別のサブスクライバがあれば、そのhttpリクエストは216.136.131.99のサービス・サイトの統合サービス・スウィッチによってサービス・エンジン３１へ転送される。エントリが発見されないとレベル１のサービス・マネージャーがキャッシュ・コンテント・ロケーション（ＭＡＣアドレス）の属性とＤＮ：fv.html, ie, web, http, vision, yahoo, comを追加する。サービス・エンジン３１のレベル１のサービス・マネージャーがＤＧＰ ＬＤＡＰ＿ＡＤＤ ＤＮ：fv.html, ie, web, http, vision, yahoo, comをレベル２のサービス管理装置まで追加する。エントリが発見されるとレベル２のサービス・マネージャーが修正し、別のキャッシュ・ロケーション（自分自身）をコンテントの属性まで追加する及びそのコンテントを持つサイトの数をインクレメントする。
【００５５】
隣のデータ・センターからのリトリーバルが全体のＣＤＮ（コンテント配信ネットワーク）の同じのレベル３のサービス管理装置に管理される。別のデータセンターにあれば、第２サービス・サイトがあれば、もしそのデータセンターにまだキャッシュ・コンテントと持ってなければ、ＬＤＡＰ＿ＳＥＡＲＣＨがレベル３のサービス管理装置まで参照し、最終的にキャッシュデータ・センター・ロケーションを見つかった。もしその隣のデータセンターにキャッシュ・コンテントがあるとサブスクライバの代理としてhttpプロクシが一つのデータ・センターのキャッシュ・サービス・エンジンからオリジン・サーバでなく隣のデータ・センターまで起動される。もし複数のデータ・センターにキャッシュ・コンテントがあればキャッシュ・コンテントのあるキャッシュ・サービス・エンジン（そのデータ・センターに）の数がキャッシュデータ・センターの好みを決定する。
【００５６】
サービス・エンジンが動態的に自分のレベル１サービス管理装置となる自分の参照のＬＤＡＰサーバを発見できる。リンク・ステート・ルーティング・プロトコル（ｅｘ．ＯＳＰＥ）が動作しているかどうかによって、レベル１サービス管理装置がレベル２のサービス管理装置を捜すには静態的コンフィギアレーションを必要あるいは必要ないとする。もしそれは動作しているなら、オペーク・リンク・ステート・パケットを使ってサービス管理装置・インフォメーションを携帯して、ルーティング・ドメインまでフラドされる。ＬＤＡＰサーチの結果がポリシ・コンフィギアレーションに影響される。キャッシュ・ライフ・タイムがキャッシュできると、プロクシあるいはリダイレクトのようなコンテントのポリシ・マネジメント関連の属性をも追加できる。
【００５７】
キャッシュ・コンテント・インバリデーション（Cashed Content Invalidation）
オリジン・サーバがＤＮ：fv.html, ie, web, http, vision, yahoo, comのコンテントを修正するとＬＤＡＰ＿ＭＯＤＩＦＹ＿ＤＥＬＥＴＥによってレベル３のサービス管理装置からすべてのキャッシュ・コンテント・ロケーションを外す。そうでない場合には、ＤＧＰを通してそのコンテントの期限日付の属性を指定あるいは変更して、スケジュール的コンテント・アップデートを導入できる。レベル３のサービス管理装置がＬＤＡＰ＿ＭＯＤＩＦＹ＿ＤＥＬＥＴＥによってすべてのキャッシュ・コンテント・ロケーションを外すあるいは自分に管理されるレベル２のサービス管理装置からの期限日付を変更する。
【００５８】
レベル２のサービス管理装置がＬＤＡＰ＿ＭＯＤＩＦＹ＿ＤＥＬＥＧＴＥによってＬＤＡＰ＿ＭＯＤＩＦＹ＿ＤＥＬＥＴＥによってすべてのキャッシュ・コンテント・ロケーションを外すあるいは自分に管理されるレベル１のサービス管理装置からの期限日付を変更する。レベル１のサービス管理装置がすべてのキャッシュ・サービス・エンジンに通知（マルチキャスト）し、そのキャッシュ・コンテントをストレージから外す。
【００５９】
コンテントがオリジン・サーバによって変更されると、オリジン・サーバもＬＤＡＰ＿ＭＯＤＩＦＹ＿ＲＥＰＬＡＣＥを発送してレベル３のサービス管理装置に修正された日付と時間の属性のコンテントを修正する及びダウンワードに低いレベルのサービス管理装置とキャッシュ・サービス・エンジンに伝送する。最終の修正された日付と時間に基づいてサーバが何時かに古いコンテントの放棄を決定する。
【００６０】
サービス・エンジン（LDAPクライアント）とレベル１のサービス管理装置とレベル２のサービス管理装置との間の動態発見（dynamic discovery）
ＬＡＮ（レイヤ２）の環境にすべてのサービス・エンジンからレベル１のサービス管理装置まで、サービス・インフォメーションを伝送するにはレイヤ２のマルチキャストが使用される。周知のイーサネット・マルチキャスト・アドレスがレベル１のサービス管理装置（プライマリとバックアップのレベル１のサービス管理装置）のために定義される。
【００６１】
サービス・エンジンと一つのエリアあるいは自主的システムの中に提供されるサービスを伝送するには、リンク・ステート・ルーティング・ドメイン（link state routing domain）でオペーク・リンク・ステート・パケット・フラッディング（opaque-link-state-pocket flooding）がすべてのレベル１のサービス管理装置とレベル２のサービス管理装置に使用される。
【００６２】
レベル２のサービス管理装置が全体の自主的システムまで常にフラドしなければならない。全体の自主的システムに一つのレベル２のサービス管理装置しかないとレベル１のサービス管理装置によってオペーク・リンク・ステート・パケットが全体の自主的システムまでフラドしなければならない。各エリアに一つのレベル２のサービス管理装置しかあると、レベル１のサービス管理装置によってオペーク・リンク・ステート・パケットがそのエリアだけまでフラドしなければならない。他の同じレベルのサービス管理装置までのＤＧＰ連結が許されないが、ディレクトリ・インフォメーションのために、レベル２のサービス管理装置がレベル３のサービス管理装置を先に別のレベル２のサービス管理装置まで参照するはず。
【００６３】
自主的システムを越えて、サービスを伝送するにはレベル２、レベル３あるいはレベル４のサービス管理装置にあるＩＰマルチキャスト・ツリーの中にＩＰマルチキャストは利用できる。サービスをサービス管理装置の間に伝送、サーチと更新するには静態的コンフィギアレーションも利用される。
【００６４】
キャッシュ・サービス・エンジンからクランク・バック付きのクライアントまでホップ・バイ・ホップ方式のフロー通告による良質のコンテント・デリバリ（他のポリシにも可能）ＩＰフローのホップ・バイ・ホップ方式のフロー通告がパターン・マッチング・ルールに基づいて述べられる。鑑定とアカウントを検査あるいは起動されてから、キャッシュ・サービス・エンジンからアップ・ストリーム統合サービス・スウィッチまでフロー通告が始まる。フロー通告のプロトコルがサポートされるなら、フロー通告の統合サービス・スウィッチが継続にその隣のアップ・ストリームの統合サービス・スウィッチまでフロー通告する及びホップ・バイ・ホップにエンドユーザまで。しかし、エンドユーザはフロー通告のプロトコルに含まれていない。フロー通告のプロトコルがサポートされないなら、各ホップが静態のコンフィギアレーションあるいは信号プロトコルを通して、フローとフローの属性を自分（違うのも可能）のアップ・ストリーム・トラフィックの特徴に反映する。例えば、このホップ・バイ・ホップのフロー通告を通して、ＩＰフローがＡＴＭ ＳＶＣあるいはＰＶＣまで反映できる。ＡＴＭ ＳＶＣあるいはＰＶＣもＩＰフローまで反映できる。ＩＰ ＭＰＬＳがあれば、ＩＰフロー通告がＭＰＬＳ信号のプロトコルを通してＭＰＬＳまで反映できる。アップ・ストリーム・ホップがフロー信号をサポートしなければ、フロー通告が止まる。
【００６５】
フローは反映と定義されれば、フロー・スウイッチングにあらゆるホップが必要で、レイヤ２からレイヤ７までのスウィッチング・デバイスのすべてのネットワーク・デバイスを含めないといけない。トラフィック・クラスが定義されれば、ダウンストリームのホップが適当なアップ・ストリームのトラフィック・クラスまで反映しなければならない。サービス品質の典型の例として、サービス品質がアップ・ストリームのネットワークにあるDiffServ, Cable Modem’s SIDと 802lpまで反映できる。
【００６６】
リンクあるいはスウィッチがフロー・パスに沿って中断されたら、アップ・ストリームのホップがエンドユーザまでフローの放棄通告を発送し、フローを中止しなければならない。一方、ダウン・ストリーム・ホップが別のフロー通告を他のアップ・ストリームのホップまで起動し、エンドユーザまで伝送し、フローを再建する。もしアップ・ストリームのホップがこのフローを受取らない場合、スウィッチがフローを中止し、自分のダウンストリームホップまで通告する。そしてそのダウン・ストリーム・ホップが別のアップ・ストリーム・ホップを発見しなければならない及び再びエンドユーザまで伝送する。もしそのアップ・ストリームのホップが見つからない場合、一つのスウィッチが見つかるまでにそのフロー中止（クランクバック）を引き続きにダウン・ストリーム・ホップまで伝送するあるいはサービスエンジンに戻ってそのフローを放棄する。
【００６７】
ＰＫＩ付きＶＰＮ
コンテント関係なしのサービス・エンジンがＩＰＳＥＣエンジンを例として、ＰＫＩ付きＶＰＮが同じのディレクトリ・ネットワークを使用できる。ＰＫＩ付きＶＰＮも自分のレベル１サービス管理装置まで参照でき、認証と類似ものをサーチする。そして、階層的ユーザと経理管理に対して、レベル２と３のサービス管理装置まで参照する。
【図面の簡単な説明】
【図１】  本発明のシステムによる複数のＣＤＮネットワークのコンテントピアリングを示す図である。
【図２】  本発明のシステムによる複数のデータセンターの統合サービスネットワークを示す図である。
【図３】  本発明のシステムによる別の複数のデータセンターの統合サービス・ネットワークを示す図である。
【図４】  本発明のシステムによるサービス管理装置とテータ・センターのキャッシュイング・プロクシー・サーバー・ファームを示す図である。
【図５】  本発明のシステムによるサービス管理装置・ファームにあるディレクトリ・インフォメーション・マルチキャスト・アップデートを示す図である。
【図６】  本発明のシステムによる統合サービスＬＡＮを示す図である。
【図７】  本発明のシステムによるリライアブル・マルチキャスト・トランスポート・プロトコル・シークエンスを示す図である。
【図８】  本発明のシステムによるトランスポート・マルチキャスト・アボート・オペレーション・シークエンスを示す図である。
【図９】  本発明のシステムによるリライアブル・マルチキャスト・ディレクトリ・アップデート・プロトコル・シークエンスを示す図である。
【図１０】  本発明のシステムによるリライアブル・マルチキャスト・マネージメント・プロトコル・シークエンスを示す図である。
【図１】
0003916494.tif 000002
【図２】
0003916494.tif 000003
【図３】
0003916494.tif 000004
【図４】
0003916494.tif 000005
【図５】
0003916494.tif 000006
【図６】
0003916494.tif 000007
【図７】
0003916494.tif 000008
【図８】
0003916494.tif 000009
【図９】
0003916494.tif 000010
【図１０】
0003916494.tif 000011