JP2009522877A - 任意のデータフロー用の高信頼性、高スループット、高パフォーマンス転送及びルーティングメカニズム - Google Patents

Abstract

本発明は、既存のコンテンツ送出ネットワーク基盤を活用して、基礎となる転送メカニズムとしてインターネットプロトコル（ＩＰ）を使用するあらゆるアプリケーションのパフォーマンスを強化するシステムを提供する。オーバーレイネットワークが、エッジノード、中間ノード、ゲートウエイノードのセットを具える。このネットワークが、ＩＰパケットの最適ルーティングを提供する。インターネットアプリケーションのユーザは、このオーバーレイを使用して、通常のネットワーク状態でパフォーマンスを改良し、通常のデフォルトＢＧＰルーティングがユーザに密集したパスあるいはパフォーマンスが良好でないパスの使用を余儀なくするような場合でも良好なパフォーマンスを維持することができ、あるいは、ネットワークが止まっている場合でもユーザがターゲットサーバアプリケーションに通信を維持することができる。
【選択図】 図７

Description

本発明は、一般にインターネットを介したデータパケットの転送及びルーティングに関する。

公のインターネットは、仮想プライベートネットワーク（ＶＰＮ）を介した電子商取引によるオフィス間の接続などの様々なミッションクリティカルなアプリケーションや、最近では分散アプリケーションを開発するための新しいパラダイムのようなウェブサービスのために、企業によって益々利用されるようになっている。しかしながら、現在のインターネットルーティング基盤に基づくボーダゲートウェイプロトコル（ＢＧＰ）は、これらのアプリーションの信頼性及び性能ニーズをサポートするのに適していない。特に、主としてＢＧＰプロトコルにより決定されるインターネットルーティングは、いくつかの弱点を有している。まず、ＢＧＰは、最短のＡＳ（自律システム）のパス長として知られている測定基準（metric）を用いてパケットのための次のホップを決定する。図１Ａにより、ＡＳパスが一つであるため、ネットワークＤ向けのデータをネットワークＡから直接的に送ることが分かる。ＢＧＰは集まる（converge）のが遅いことが分かっているため、これは必ずしも好ましいものではない。したがって、２つのネットワーク間のリンクが利用可能でない場合、総ての関連するルータが気づき、問題を回避するには数分かかることがある。この時間にパケットが失われる。さらに図１Ｂに示すように、ピアのポリシー（peering policy）は、ネットワークが別のネットワークからのパケットを許容せず、ＢＧＰがこの問題を効果的に避けることができないことを示している。別の問題は、様々なインターネットアプリケーションが最適なパフォーマンスのための端末間の接続の様々な特徴（例えば、最小の損失、待ち時間、または待ち時間における可変性）を必要とすることである。ＢＧＰは、サービスの質のためのルートについての取り組みをせず、これらの測定基準についての概念がない。図２に示すように、ＢＧＰは代替的なルートよりも長い待ち時間のルート（ネットワークＡとＤの間）を選択する。

ビジネスがウェブトランザクション、仮想プライベートネットワーク（ＶＰＮ）及びウェブサービスなどのアプリケーションのためにインターネットを信頼するに伴い、本分野にはインテリジェントルーティングを必要とする。例えば、ＲｏｕｔｅＳｃｉｅｎｃｅや他の企業が提供する製品などのリアルタイムのネットワークの状態の測定に基づいたインテリジェントルーティングの概念が、本分野で知られている。しかしながら、これらの製品は、適切な指令をルータに与えることにより外向きのルートの最初のホップのみを制御する能力のみを有する。例えば、ＢＧＰ通知（advertisement）に影響を及ぼすことによる内向きのルートを制御する試みは、これらの通知を変更可能な低い周波数、この通知の粗い粒度、インターネット上の複数のルータからの協力の要求、及びいくつかのＩＳＰによるポリシーオーバーライド（policy override）の偏在により制限される。

分散型コンピュータシステムもまた、よく知られた従来技術である。このような分散型コンピュータシステムは、サービスプロバイダにより操作及び管理される「コンテンツデリバリーネットワーク」又は「ＣＤＮ」である。サービスプロバイダは、自分自身又は第三者のためにサービスを提供する。この種の「分散型システム」は通常、ネットワークにリンクした自立型コンピュータと、ソフトウェア、システム、プロトコル、及びコンテンツデリバリ又は外部の基盤のサポートなどの様々なサービスを容易にするように設計された技術の集合体を意味する。通常、「コンテンツデリバリ」は、コンテンツプロバイダの代わりにコンテンツ、ストリーミングメディア、及びアプリケーションのストレージ、キャッシング、又は転送を意味しており、限定ではなく、要求ルーティング、供給（provisioning）、データ監視及び報告、コンテンツの対象化、個人化、及びビジネスインテリジェンスを含むこれとともに用いられる補助的な技術を含む。「外部の基盤」の用語は、事業体が部分的に或いは全体的に第三者の代わりに第三者のウェブサイトの基盤を操作及び／または管理できる分散型システム及び関連技術を意味する。

周知の分散型コンピュータシステムは、インターネットを中心に分散した一組のマシンを有すると考えられる。通常、マシンの多くは、インターネットの端部（エッジ）、即ちエンドユーザのアクセスネットワークに又はこの近くに配置されたサーバである。ネットワークオペレーションコマンドセンタ（ＮＯＣＣ）は、システム内の様々なマシンの操作を管理（administer and manage）するために利用される。ウェブサイト２０６などの第三者のサイトが、コンテンツ（例えば、ＨＴＭＬ、組み込みページオブジェクト（embedded page objects）、ストリーミングメディア、ソフトウェアダウンロード等）の送達を分散型コンピュータシステムに、具体的には「エッジ」サーバに委ねる。このようなコンテンツを必要とするエンドユーザは、分散型システムに向けられ、コンテンツをより確実かつ効率的に取得する。詳細には示していないが、分散型コンピュータシステムは、用法（usage）やエッジサーバからの他のデータを収集し、このデータを一の領域または一組の領域を超えて集め、このデータを他のバックエンドシステムに送り、監視、ロギング、警告、広告、管理、及び他の使用可能な管理機能を強化する分散型データ収集システムなどの他の基盤を具えている。分散型ネットワークエージェントは、ネットワークとサーバ負荷を監視し、ネットワーク、トラフィック、及びＣＤＮにより管理されるコンテンツドメインに対して権限のあるメカニズムを取り扱うＤＮＳクエリーにロードデータを提供する。分散型データ転送メカニズムは、制御情報（例えば、コンテンツを管理し、負荷バランスを強化するメタデータ等）をエッジサーバに分配するのに利用される。図３に示すように、所定のマシン３００は、１又はそれ以上のアプリケーション３０６ａ乃至ｎをサポートするオペレーティングカーネル（Ｌｉｎｕｘ等）３０４を動作させる汎用ハードウェア（例えば、Ｉｎｔｅｌ Ｐｅｎｔｉｕｍプロセッサ）３０２を具えている。コンテンツデリバリサービスを強化するために、例えば、所定のマシンは通常、ＨＴＴＰウェブプロキシ３０７、ネームサーバ３０８、ローカル監視処理３１０、分散したデータの収集処理３１２等の一組のアプリケーションを動作させる。

前述したようなコンテンツデリバリネットワークは、補助的なネットワーク又はメカニズムを具えており、特定のデータの転送を促進し、又はデータのスループットを改良する。したがって、インターネットＣＤＮは、情報分散技術を用いてストリーミングメディアの転送を提供し、これにより、所定のストリームが複合的で冗長なパスを介して送信される。このような技術の一つは、アカマイテクノロジー社に付与された「Streaming media subscription mechanism for a content delivery network」の名称の米国特許第６，７５１，６７３号に記されている。ＣＤＮは転送メカニズムを提供して、時間をかけて収集した性能データに基づいて、一対のホスト、例えば、２つのＣＤＮサーバ、又はＣＤＮエッジサーバとカスタマーオリジンサーバの間の通信を促進する。典型的なＨＴＴＰに基づく技術は、アカマイテクノロジー社の「Optimal route selection in a content delivery network」の名称の公開された米国特許出願２００２／０１６３８８２に記されている。

本発明の目的は、任意のデータフローのための信頼性のあるハイスループットでハイパフォーマンスの転送及びルーティングメカニズムを提供することである。

本発明の別の目的は、インターネット上の問題からデータを回避させるインターネット上のオーバレイを提供し、最善のサービスルート又はパスを最小の待ち時間とロスで見つけることである。

本発明のさらに別の目的は、既存のコンテンツデリバリネットワーク基盤を用いて、基礎をなす転送メカニズムとしてインターネットプロトコル（ＩＰ）を利用する任意のアプリケーションの性能を強化するシステムを提供することである。

本発明のさらに一般的な目的は、インターネット上のビジネス用のアプリケーションの性能と信頼性を改善するオーバレイメカニズムを提供することである。

本発明のさらに別の目的は、インターネットのアプリケーションの利用者が改良された性能を通常のネットワーク状態で取得できる技術を提供すること、通常のデフォルトＢＧＰルーティングが、密集したあるいはパフォーマンスが良好でないパスの使用をユーザに余儀なくさせるような場合に、高い性能を取得又は維持すること、またはネットワークの停止中にさえユーザが通信できることである。

本発明は、具合の悪い実行パスを検出してこれを迂回するとともに、直接的なパスが通常通りに機能する場合によりよい代替的な実行パスを見つける拡張性があり、可用性が高く、信頼性のあるオーバレイサービスを提供し、これにより、改良されたアプリケーションの性能と信頼性を保証する。

前述の内容は、本発明のより適切な特徴の一部の概要である。これらの特徴は単なる例示であると理解すべきである。開示された発明を別の方法で利用することにより、または本発明を後述するように修正することにより、その他の多くの有益な結果を得ることができる。

本発明及び本発明の利点をより完全に理解するために、ここで、添付図面を考慮して以下の記載について説明する。

本発明は、公にルーティング可能なインターネット上に設置される「オーバレイ（overlay）」メカニズムである。必須ではないが、オーバレイは既存のコンテンツデリバリネットワーク（ＣＤＮ）基盤を用いることが好適である。一般に、本発明のオーバレイメカニズムは、ダウンしたリンクを迂回することにより（図４）、または最も待ち時間の少ないパスを発見することにより（図５）、ＩＰを転送プロトコルとして用いるアプリケーションのパフォーマンスを強化する。したがって、図４では、ネットワークＡとＤの間のリンクがダウンしており、このため、オーバレイはネットワークＢを介してパケットを送る。図５では、オーバレイは、ＢＧＰルーティングが決定する遅いネットワークＡからネットワークＤへのパスの代わりに、ネットワークＡ、ネットワークＣ、ネットワークＤを介したパスを用いる。図４及び５では、クライアントがサーバと通信を試みていると仮定している。しかしながら、単一又は所定のクライアントの説明は、限定を意味するものではない。これは一般化である。本発明によると、オーバレイメカニズムは、様々な動作環境で利用される。このような環境の一つは、単一のサーバ（又はサーバファーム）へのアクセスを要求する複数のクライアント（例えば、ローミングクライアント（roaming client））が存在する環境である。これは時折、「リモートアクセス」と呼ばれる。別のシナリオでは、２以上の所定のエンドポイントが、互いに通信するのを要求する。これは時折、サイト対サイト又は「リモートオフィス」実施例と呼ばれる。一般化すると、分かるように、オーバレイメカニズムは、一組のサーバでＩＰパケットを受信し、ゼロまたはそれ以上の一連のＣＤＮサーバを介してこれらのパケットを送り、これらを所定の規定されたＩＰアドレスに送達することにより動作する。

本発明に係るオーバレイＩＰ（ＯＩＰ）のルーティングメカニズムは、図６に示すような典型的な一組の構成要素を具えている。
・エッジサーバ６０２−通常、以下に述べるＯＩＰエッジサーバのソフトウェア処理を動作させるＣＤＮエッジサーバである。以下に説明するように、このソフトウェアは、ＩＰパケットを受信し、カプセル化し、転送する責任を有する。
・エッジ領域６００−通常、オーバレイメカニズム用に構成されたＣＤＮエッジ領域である。
・中間サーバ６０６−通常、カプセル化されたパケットをエッジ領域６００又は他の中間サーバから受信し、これを他の中間サーバ又はゲートウェイ領域に転送するサーバである。
・中間領域６０４−中間サーバの領域である。
・ゲートウェイサーバ６１０−通常、カプセル化されたパケットをオーバレイから受信するように構成され、ソースネットワークアドレス変換（ＮＡＴ）を元のパケットに適用し、これをターゲットサーバに転送するエッジサーバである。
・ゲートウェイ領域６０８−通常、顧客構内に配置されるゲートウェイサーバを具えるある種のエッジ領域である。
・ターゲットサーバ６１２−トラフィックがオーバレイを介して送られるマシンである。
・ターゲットアドレス−ターゲットサーバのＩＰアドレスであり、このアドレスは時折、ＣＤＮの仮想ＩＰアドレスと比較して、ダイレクトアドレスと呼ばれる。
・スロット−オーバレイの単一の「インスタンス」であり、スロットは、単一のターゲットアドレスに対応する番号が付されたインデックスである。
・仮想ＩＰアドレス−通常、スロットに対応するＣＤＮアドレスであり、スロット毎に、エッジ領域毎の一の仮想ＩＰアドレスがあることが好適である。これは時折、ＶＩＰと呼ばれる。
・パス６１４−エッジ領域とゲートウェイ領域の間のＣＤＮ領域の順序集合（ordered set）である。
・パスセグメント６１６−パスの単一のホップである。
・トンネル６１８−エッジサーバからゲートウェイサーバへの１以上のパスのセットである。
・セッション６２０−クライアント６２２からターゲットサーバへの単一の端末間（end-to-end）の接続であり、このセッションは５つの要素（ＩＰペイロードプロトコル、ソースアドレス、送信先アドレス、ソースポート、送信先ポート）により決まる。このソースはクライアントであり、送信先がターゲットである。

第１の実施例、リモートアクセスでは、パケットを単一のＩＰアドレスに送信するのを所望する１又はそれ以上のクライアントが存在する。図７は、オーバレイＩＰメカニズムがこの動作を実現する様子を示している。ステップ１では、クライアント７００は、ホスト名を決定するＤＮＳ要求を生成する。このホスト名は、（例えば、ＣＮＡＭＥにより）権限のあるＤＮＳ７０２により管理されるドメインが付され、通常、権限のあるＤＮＳはＣＤＮサービスプロバイダにより管理される。このホスト名は、単一のゲートウェイ領域（及びターゲットアドレス）に対応するのが好適である。これは前述したようにスロットと呼ばれる。ステップ２では、ＤＮＳクエリーは、ホスト名のための単一のＩＰアドレスを返却する。このアドレスは、最も実行可能なエッジ領域７０６を特定し、この領域はホスト名専用であることが好適である。このアドレスは、前述したように仮想ＩＰアドレスと呼ばれる。ステップ３では、クライアント７００は、仮想ＩＰアドレスへのＩＰパケットの送信を開始する。これらのパケットは、エッジ領域７０６内のサーバにより受信される。エッジ領域７０６は、ゲート領域７０４を分かっており、この領域に、ＩＰパケットヘッダ内の送信先アドレスに基づいてパケットが送信される。次いで、パケットがカプセル化される。ステップ４では、好適にはＣＤＮマッピングシステムにより提供されるルートに基づいて、エッジ領域７０６内のエッジサーバが、複数のカプセル化されたパケットのコピーを複数のパスを介して送信する。この複数のパスによるパケットの転送動作を行う技術が、アカマイテクノロジー社に付与された米国特許第６，６６５，７２６及び６，７５１，６７３に記されている。ステップ５に示すように、いくつかの中間サーバは、カプセル化されたパケットを受信し、好適にはＣＤＮマッピングシステムから提供されたルートに基づいて、再度パケットをゲートウェイ領域７０４に（直接的に、あるいは図示されていない他の中間領域を介して）転送する。ステップ６では、パケットがゲートウェイ領域７０４内のサーバにより受信され、複製物が取り除かれる。送信先ＮＡＴは、仮想ＩＰをターゲットアドレスに変換し、パケットが送信される前にソースネットワークアドレスポート変換がパケットに適用され、返却トラフィックもオーバレイネットワークを介して送信されるようにする。返却トラフィックがクライアントのパケットが生成されるエッジ領域７０６に送信されるように、情報を格納するのが好適である。ステップ７では、ゲートウェイ領域７０４が、ターゲットアドレスからＩＰパケットを受信し、パケットをネットワークアドレス変換しない（ｄｅ−ＮＡＴ）。次に、パケットがカプセル化される。ステップ８では、パケットの複数のコピーが複数のパスを介して送られる。ステップ９では、中間サーバが、このセッションのために元のエッジ領域にパケットを送信する。ステップ１０では、パケットがエッジサーバにより受信され、複製物が取り除かれる。パケットが、仮想ＩＰアドレスから供給され、要求しているクライアント７００に返信される。これにより、端末間の転送が完了する。

以下に典型的なエッジサーバ、中間サーバ、及びゲートウェイサーバの追加的な詳細を記す。

Ｉ．エッジサーバ
エッジサーバは、（便宜上、ｏｉｐｄと称する）処理を動作させ、この処理は以下の機能、すなわち、仮想ＩＰアドレスのパケットを受信し、予測されるプロトコル／ポート、無効あるいはアタックトラフィック、又は特殊なアクセスコントロールリスト（ＡＣＬ）に基づいてパケットをフィルタリングし、カプセル化／カプセル開放をし、複製されたパケットを転送し、複製されたパケットを受信する機能を提供する。
ここで、これらの各機能を説明する。

パケット受信
仮想ＩＰアドレスに向かうＩＰパケットは、エッジサーバのＴＣＰ／ＩＰスタックにより処理されるべきではなく、これらは常に通過（tunneled）あるいはドロップされなくてはならない。したがって、エッジサーバのオペレーティングシステムのカーネルは、パケットがローカルで処理される前にパケットを捕まえる（これをｏｉｐｄに送る）フックを具えている。代表的な実施例では、エッジサーバが、汎用的なハードウェア及びＬｉｎｕｘのオペレーティングシステムのカーネルを動作させる。このカーネルは、ｉｐ＿ｔａｂｌｅ、ｉｐ＿ｑｕｅｕｅ及びｉｐ＿ｆｉｌｔｅｒモジュールを具えている。マシンのスタートアップ時には、コンフィグレーションスクリプトが、任意の仮想ＩＰアドレス向けの総てのパケットがユーザの空間に送達されるように（ｉｐ＿ｔａｂｌｅモジュール内の）ルールを設定する。ｉｐ＿ｑｕｅｕｅモジュールを利用して従うアプリケーションが無い場合、パケットはドロップする。

パケットフィルタリング
３種類のパケットのフィルタリング、即ち、予測／許可されるＴＣＰ／ＵＰＤ、無効又はアタックトラフィック、ＣＤＮサービスプロバイダ又は顧客が指定するホワイトリスト／ブラックリストＡＣＬがサポートされることが好ましい。エッジサーバ処理ｏｉｐｄは、ポートに基づいてＴＣＰ／ＵＤＰパケットをフィルタリングするのが好適である。

カプセル化
エッジサーバ処理により提供される重要な機能がカプセル化される。カプセル化のヘッダは、以下の情報又はその情報の一部を含んでいる。
・プロトコルバージョン−標準的なバージョンフィールド。
・ＴＴＬ−パケットが自動的にゲートウェイ領域（あるいは方向に基づいてエッジ領域）に送られる前に通過可能な多くのホップの数である。これは各ホップでデクリメントする。
・パス番号−パケットが通過する各パスは識別子を有する。この番号は、マップ又は他のデータ構造内で特定されるインデックスに対応することが好適である。
・転送状態（forward state）−ゲートウェイサーバにより利用される。
・データ長−ＯＩＰパケットのペイロード内のバイト数である。
・ソースサービスアドレス−カプセル化マシンのサービスアドレスである。
・送信先サービスアドレス−トンネルの受信側のサービスアドレスである。
・メッセージシーケンス番号−複製したパケットを特定し、トンネルを介したロスを決定する。
・ＯＩＰスロット番号−パケットのスロットである。
・シリアル番号−ＩＰパケットのハッシュ情報により決定される。
・エッジ領域番号−パケットを送信する領域の領域番号である。
・ＳＲＭＭ中間領域のマップルール−このスロットのために使用される中間領域を決定する。
・メッセージ認証コード−ＯＩＰパケットの信頼性を判断するのに用いられる。

パケットがカプセル化された場合、ｏｉｐｄ処理は、ＩＰヘッダの送信先アドレスフィールド内の仮想ＩＰアドレスに基づいてＣＤＮの顧客を知る。次に、この処理は以下のマップを含むコンフィギュレーションファイルを調べる。
Ｖｉｒｔｕａｌ ＩＰ ａｄｄｒｅｓｓ −＞ ＳＲＩＰ ｓｌｏｔ ｎｕｍｂｅｒ

これは時折、「ＶＩＰマップ」と呼ばれる。このマップはインストールの際に決定され、様々なエッジサーバの構成要素がマップの一貫性のあるビューを有することが好適である。次に、好適にはスロットコンフィギュレーションファイルで生成される「Ｓｌｏｔ Ｃｏｎｆｉｇｒａｔｏｎ Ｍａｐ」を用いて、スロット番号をこの顧客のためのゲートウェイ領域の番号を調べるのに利用される。次に、エッジサーバ処理は、情報のハッシュ値を計算してシリアル番号にし、負荷バランスのために管理可能な量に負荷を分散する。ハッシュは、少なくともソースＩＰアドレスを含むことが好適である。次のヘッダがＴＣＰ又はＵＤＰの場合、発信元ポート及び送信先ポートも同様にハッシュ値が計算される。

エッジサーバ処理は、シリアル番号をサービスアドレスにマップする第１の低レベルのマップ（以下に示すようなサービスＢ）を承認する。具体的には、シリアル番号は、マップにインデックスを付して、単一のサービスアドレスを含むゲートウェイ領域を特定するのに用いられる。これは、パケットの総て（例えば、３つ）のコピーが送信されるサービスアドレスである。次に、エッジサーバ処理は、過去にパケットをこのアドレスに転送したかを判断するためにチェックする。過去に転送した場合は、エッジサーバ処理はシーケンス番号をインクリメントさせ、この番号をカプセル化したヘッダ内の「メッセージシーケンス番号」フィールド内で使用する。エッジサーバ処理がこのＩＰアドレスに何も送信していない場合、以下に説明するように状態を初期化する。

パケット転送
「パケット転送」機能は、以下のように動作する。この時点では、カプセル化したヘッダの多くが満たされている。ヘッダについての追加の情報は、以下のように生成される。総てのエッジサーバは、マップを行う割り当て処理（以下に説明するＳＲＭＭと呼ばれる）を許可することが好適であり、ＭａｐｐｅｒＸ．ＯＩＰ．ｓｒ＿ａｓｓｎ＿Ｄ＿ｒｅｇｉｏｎＹは、Ｘが適切なＭａｐｐｅｒの接頭辞であり、Ｙが領域番号である。送信先領域番号とＳＲＭＭ中間領域ルールは、割り当てメッセージにインデックスを付するために用いられる。これは、１又はそれ以上の次のホップ領域の番号を生成し、次のホップ領域の番号は、スロット毎に設定可能であることが好適である。次のホップはそれぞれ、パス番号によりインデックスが付される。このパス番号はカプセル化ヘッダに含まれており、ダウンストリームの中間ノードは次のホップを知っている。割り当てメッセージが次の領域を有していない場合、単一のカプセル化したパケットが、送信先サーバのアドレスに送られる（これは、ＮＯＣＣ内の警告を発するべきである）。次のホップ領域毎に、第２の低レベルのマップ（以下に説明するサービスＣ）がチェックされる。このマップにインデックスを付するために用いられるシリアル番号は、カプセル化パケットヘッダに含まれるシリアル番号であることが好適である。これらの各マップが、各シリアル番号の単一のサービスアドレスのみを含むことが好適である。これは、パケットが次に転送されるサービスアドレスである。シリアル番号は、情報（即ち、５つの要素）を特定する接続（コネクション）から導出されることが好適である。送信される次の領域がゲートウェイ領域である場合、第１の低レベルのマップは、チェックが既に送信エッジサーバにより行われているためチェックする必要がない。この最初の検査は、複数のパスに沿って送信される前に行われ、中間領域を同期させるのを阻止する。

ヘッダ情報が終了すると、ＭＡＣがヘッダ及びデータ用に計算される。この計算は、ＳＨＡ−１、ＭＤ５等に基づいている。中間ノードによる転送を単純化するために、ＴＴＬフィールドは、変更可能である場合はハッシュに含まれていなくてもよい。

複製されたパケット
前述したように、エッジサーバ処理は、複製されたパケットを送信することが好適である。前述したように、エッジサーバ処理は、冗長性のために、各パケットの複数のコピーを様々な方向に送信することが好適である。受信側は、複製物をフィルタリングする効率的な方法を必要とする。複製されたパケットを処理する場合、最初の目的は、ドロップするパケットをできるだけ少なくすることであり、次の目的は、複製されたパケットをできるだけ少なくターゲットサーバに送信することである。エッジサーバ処理は、トンネルレベルで複製されたパケットを追跡する。ペア毎（エッジ発信元アドレス、エッジ送信先アドレス）に、エッジサーバ処理が、パケットを受信する各サービスアドレスごとにどのパケットが受信されたか（及びされなかったか）を表すスライドウインドウの状態を維持することが好適である。処理アルゴリズムの一つについて述べる。このアルゴリズムは、ウインドウのサイズである一のパラメータと、これまでラップアラウンド用に調整して見える最大シーケンス番号を維持する。二つのデータオブジェクト；すなわち、ウインドウと、好ましくは、ウインドウのサイズは、不必要にリセットされないように十分に大きくなくてはならない。従って、
oip.packet.window.size>=(max_packet_rate*max_packet_age)
初期化する際に、ウインドウ全体をＮＵＬＬに初期化することが好適である。最も大きなシーケンス番号は、第１パケットの番号にセットされており、スライドウインドウへの入力は、ＳＥＥＮにセットされている。新しいパケットごとに、シーケンス番号＞最大シーケンス番号＋oip.packet.windowサイズであれば、その状態が初期化されて再開する。パケットがウインドウ内にあるが、最大シーケンス番号より小さい場合は、アルゴリズムが、ウインドウの入力がＳＥＥＮにセットされたかどうかをチェックする。ＳＥＥＮにセットされていれば、パケットがドロップし、さもなければＳＥＥＮとマークされる。パケットがこれまでの最大シーケンス番号より大きい場合は、アルゴリズムがその最大番号をパケットにセットして、その入力をＳＥＥＮとマークし、その間の全ての入力をＵＮＳＥＥＮとマークする。２つの値を用いることで十分正確であるが、３つの値を用いると、状態に２ビットを必要とする。送信者が状態を再開すると、ランダムに選んだシーケンス番号が、受信者が維持している現ウインドウ内にくることがあり、パケットを不必要にドロップさせることがある。これを防止するために、送信者は定期的に、データを送った各サービスアドレスについてのマップ（サービスアドレス、最後のシーケンス番号）を書くことが好適である。エッジサーバが開始して立ち上がると、このファイルを読み取って大きな数字を加え、サーバがウインドウにないことを確実にする。この値は、ウインドウウサイズより十分に大きくなくてはならない。

上述したように、エッジ領域が複数のエッジサーバを具えることが好適である。従って、本システムは、エッジサーバ障害迂回機能を実装することができる。これによって、単一のエッジサーバが故障した場合に、その結果ドロップするであろうパケットの数が最小になる。各エッジ領域は、所定数の構造マシンのバディグループを有する。傷害迂回で動作する複製物の除去のために、ＳＥＥＮパケット状態は、バディグループ中の全てのマシンに公開される。このデータは、おそらく非常に頻繁に変化する。従って、各マシンがそのバディグループの全てのマシンに最大シーケンス番号のＳＥＥＮを表示する更新データを送信することが好適である。各マシンは、バックエンドネットワークを通してそのバディグループの全てのマシンに、この情報を好適にはＴＣＰを用いて送信する。

II．中間サーバ
中間サーバは、エッジサーバに実装されているものと同じ「転送パケット」機能を有する。この中間サーバは、MapperX.OIP.sr_assn_D_region Yチャネルと契約している。各中間領域は、ＳＲＭＭ中央領域ルールが割り当てられており、このルールに従って設定されているスロット用のパケットのみを受信する。送信先領域番号とスロットの中央領域ルールを用いて、割り当てメッセージにインデックスを付して、次のホップを決定する。マシンが異なる中央領域ルールを有するスロット用パケットを受信した場合は、それを送り続けるが、警告を発しなければならない。別の中間領域に送信する場合は、第２の低レベルマップを用いて、次のホップサーバのサービスアドレスを決定する。次の領域がゲートウエイ領域である場合は、ヘッダ中の送信先サービスアドレスを用いることが好ましい。パケットを転送する前に、ＴＴＬフィールドをデクリメントしなければならない。ＴＴＬが１になると、パケットがゲートウエイ領域サービスのアドレスに転送される。

III．ゲートウエイサーバ
上述したとおり、ゲートウエイ領域は、一般的に顧客データセンタに位置する特殊なエッジ領域であることが好ましい。理想的には、これは、ターゲットサーバに近いところにある。ゲートウエイサーバは、エッジサーバ処理ｏｉｐｄのインスタンスも動作させて、エッジサーバとゲートウエイサーバとして同時に作動することができる。ゲートウエイ領域の各マシンは、インストール及び安全なアクセス用に使用する自身のＣＤＮ−特定ＩＰアドレスであって、オーバーレイネットワーク通信に用いるサービスアドレスとしてのアドレスを有することが好ましい。上述したとおり、単一のＶＩＰアドレスを固定クライアントのマッピング用に使用し、いくつかのＮＡＴアドレスを使用するのが好適である。ゲートウエイ領域は、好ましくは、冗長性用マシンを何台か備えている。これらのマシンは、負荷が分散されている。

ゲートウエイサーバは、以下の機能を提供する：すなわち、接続トラッキング、状態同期、ネットワークアドレス変換、シーケンス番号変換、領域内パケット転送、エッジ領域へのパケット返還機能である。これらの各機能を以下に詳細に説明する。

トラック接続
トラック接続のために、エッジサーバ処理ｏｉｐｄは、なりすましとＩＰアドレス変換を実行するｌｉｂａｌｉａｓライブラリなどのＮＡＴライブラリを使用する。このライブラリは、好ましくは、ハッシュテーブルあるいはその他のデータ構造内に接続トラッキング情報を保存する。新しい接続が設定されると、新しい入力がテーブルに加えられる。既存の入力が参照されると、その時間スタンプが更新される。既存の入力が所定の時間内に参照されない場合（この意味は、プロトコルと接続状態に応じて変化する）は、入力がテーブルから削除される。新規の接続トラックが作られると、これを標準ｌｉｂａｌｉａｓデータベースに加えら、更に、新しく作られ、まだ同期していない接続トラックのリストも加えることが好ましい。既存の接続トラックが変更されると、そのリストにすでにあるか、あるいは新規入力リスト載っていない限り、変更されたが同期していない入力リストに加えられる。既存の接続トラックが削除されると、このトラックはｌｉｂａｌｉａｓデータベースから削除され、削除入力リストに加えられる（現在新規入力リストにない限り、すなわち、それに関する情報が同期しておらず、削除情報を同期する必要がない場合でない限り）。ｏｉｐｄ処理は、定期的に、データベースへ更新（新規、変更、及び削除リスト）を同期する。これによって、接続追跡データベースを、ゲートウエイ領域全体で共有することができ、ゲートウエイ領域内のマシン間で接続状態ごとの情報を移動させることができる。

状態同期
ゲートウエイサーバ内で動作しているｏｉｐｄ処理は、いくつかの情報片を単一の接続に関連付けることが好適である。この情報は、ゲートウエイ領域中の全てのマシンで同期している。この結果、一連の機能がｌｉｂａｌｉａｓライブラリに加わって、同期するデータの収集を容易にする。各タイプのリスト（新規、変更、削除）の同期について１の機能があり、一つは、ピアマシンを初期化するために全記録を収集する機能であり、一つは、単一の入力に対する要求に応答する機能である。これらの機能について以下に述べる。

ＧｅｔＳｙｎｃＮｅｗＤａｔａ機能は、まだ同期していない新規記録を全て同期させるデータパケットを立ち上げる。ＴＣＰパケットの場合、完全に接続されていると考えられる（すなわち、ＳＹＮパケットがクライアントとサーバの両方から見られた）これらのパケットのみが同期する。好ましくは、ｏｉｐｄ処理によって完全に接続されたことがマークされるまで常に同じマシンによって操作される。これによって、潜在的なレース状態が部分的に接続されたトラッキング入力の同期に関連付けられ、その時間切れを防止することができる。

ＧｅｔＳｙｎｃＭｏｄＤａｔａ機能は、まだ同期していない変更した全記録ての同期用のデータパケットを作る。アクティブな入力は、少なくとも、データベース中あるいはリモートマシン上でタイムアウトしないことを確実にするために十分頻繁に同期することが望ましい。好ましくは、ｏｉｐｄ処理は、リスト中の各入力が少なくとも定期的に（例えば、ＵＤＰ接続入力用のタイムアウト期間）確実に同期されるようにする。これによって、接続入力が誤ってタイムアウトしなくなり、同時に、同期したゲートウエイ領域を保持するのに必要な帯域が制限される。

ＧｅｔＳｙｎｃＤｅｌＤａｔａ機能は、削除した記録についての情報を収集し、ＧｅｔＳｙｎｃＡｌｌＤａｔａ機能は、データベース中の入力全てについての情報を収集する。

同期データをリモートマシンで受信すると、このデータはアクティブな接続に適用される場合（すなわち、ＧｅｔＳｙｎｃＡｄｄＤａｔａ、ＧｅｔＳｙｎｃＭｏｄＤａｔａ、ＧｅｔＳｙｎｃＡｌｌＤａｔａによって収集される場合）、ＧｅｔＳｙｎｃＡｄｄＤａｔａ機能に送信される。この方法は、一のデータがある場合、ローカルデータベース中に新規接続入力をつくるか、既存の入力を更新する。ＴＣＰ接続については、各方向（イン／アウト）に一台、二台の有限状態のマシンを用いて、接続状態をｌｉｂａｌｉａｓによって追跡することが好ましい。ＧｅｔＳｙｎｃＡｄｄＤａｔａ機能によって、ローカルマシン上の有限状態のマシンが有効な移送を追跡して、アクティブな接続が誤って非接続、あるいは切断としてマークされないようにする。削除すべき記録に関する同期データは、ＧｅｔＳｙｎｃＤｅｌＤａｔａに送信され、ここで、このデータ入力に関するローカルテーブルの時間スタンプが、削除した入力の時間スタンプより近くない限り、ローカルテーブルから入力を削除する。

好ましくは、これらのｌｉｂａｌｉａｓ同期ルーチンは、送信者スレッドと受信者スレッドを含むＮＡＴ＿ｓｙｎｃモジュールによって使用される。このモジュールは、その全ての同期ピア（例えば、ゲートウエイ領域の他の全てのマシン）の先端アドレス及び後端アドレスで初期化される。送信者スレッドは、そのピアの一つに接続しており、初期化手順の一部として接続追跡テーブルのスナップショットを全部取り出す。次いで、反応の良いものを見つけるまで各ピアを試して、そのマシンからテーブルの更新をリクエストする。好ましくは、この初期化が完了し、全てのピアノードを試してしまうまで、他のオーバーレイ活動性処理は行われない。送信者スレッドは、好ましくは、リアルタイムクロックを用いて、同期を行う。各クロック反復について、送信者スレッドは、ＧｅｔＳｙｎｃＡｄｄＤａｔａ、ＧｅｔＳｙｎｃＤｅｌＤａｔａ、ＧｅｔＳｙｎｃＭｏｄＤａｔａを用いて、同期用データを回収する。このデータは、次いで、この領域の全てのライブピアへ送られる。活動性をチェックするために、送信者スレッドは、最後の既知の良好なアドレス（先端あるいは後端のいずれか）を用いてピアノードへのＴＣＰ接続の設定を試みることが好ましい。この接続が失敗したら、次いで、送信者スレッドは、他のアドレスを介した接続の設定を試みる。次の同期の試みにおいて再び試すことができるが、これが失敗したらピアが故障であると仮定する。送信者の同期クロックが反復するレートがＧｅｔＳｙｎｃＭｏｄＤａｔａアルゴリズムで使用するｌｉｂａｌｉａｓに設定され、各同期期間にいくつ変更レコードを送るべきかを決定する。このレートは、設定可能である。上述したとおり、各クロック反復において、全ての新しい接続入力（半接続ＴＣＰを除く）、妥当な数の変更入力、及び全削除入力が同期される。受信スレッドは、リモート接続が入ってくるのを単に待つだけであり、次いで、この接続をメッセージタイプに応じて処理する。更新及び削除メッセージは、適宜のＳｅｔＳｙｎｃ法に渡す。初期化リクエストは、受信者にＧｅｔＳｙｎｃＡｌｌＤａｔａ機能を動作させて、このデータをリモートマシンに送信する。

ネットワークアドレス変換
上述したとおり、オーバーレイは、ターゲットサーバに送るべきサービスアドレス（ゲートウエイ）に到着するすべてのパケットについて発信元ネットワークアドレス変換（ＮＡＴ）を実行する。これによって、パケットは確実にオーバーレイを介して送り返される。発信元ＮＡＴのアドレスは、好ましくは、領域ごと及びマシンごとに規定される。好ましくは、ＮＡＴアドレスの周囲を移動することが望ましいため、所定のマシンは静ＮＡＴアドレスに割り当てられない。また、パケットがゲートウエイサーバに届くと、関連する接続タイプに応じてＮＡＴが別々に適用されることが好ましい。これらの接続タイプは、例えば、サービスごとにあるいはポートごとに：すなわち、ＴＣＰ、長期；ＴＣＰ、短期；ＵＰＤ−セッション；ＵＤＰ−クエリー／応答；及びＩＣＭＰに設定可能である。クエリー／応答ＵＤＰ接続は、典型的には、クライアントからサーバへの単一ＵＤＰパケットと、サーバーからクライアントへのゼロあるいはそれ以上の応答パケットを具えるのみである。ＵＤＰクエリー／応答及びＩＣＭＰについては、新しいＮＡＴアドレス、ポート／ＩＣＭＰｉｄが各入力パケットについて選択されることが好ましい。好ましくは、ゲートウエイ領域中の各マシンは、新しいＮＡＴセッションを作るのに使用できるのみである。自身のポート／ＩＣＭＰｉｄレンジが与えられており、それに対しては、パケットを受信すると、エッジサーバ処理（以下により詳細に説明する）が、フリーアドレス、ポート／ＩＣＭＰｉｄを選択し、パケットをターゲットサーバへ転送する。ＮＡＴアドレスを持つマシンがサーバからの応答パケットを受信するが、通常は、このマシンはアドレスを元に戻すＮＡＴセッション情報を持っていい。従って、このマシンは、到着ポート／ＩＣＭＰｉｄをチェックして、ｐｏｒｔ／ＩＣＭＰｉｄを持つマシンへ応答を送信する。この第２のマシンは、次いで、パケットを元に戻して、元のクライアントアドレスとポート／ＩＣＭＰｉｄを含め、オーバーレイへ送り返す。この操作を図８に示す。両方のタイプのＴＣＰ接続について、ＳＹＮパケットが見られる場合にのみ新しいＮＡＴアドレスとポートを選択することが好ましい。どちらの場合でも、ＮＡＴ発信元ポート番号を用いて、そのセッションを作ったサーバへパケットを送り返す。長期接続用には、ゲートウエイサーバ間で送る必要のあるデータ量を低減することが望ましい。好ましくは、これは、ＮＡＴセッション情報を同期させることによって行われる。特に、データパケットが受信されると、エッジサーバ処理（以下に述べるように）は、なんらかの接続状態データが存在するかどうかを決定する。データが存在する場合は、この処理を発信元ＮＡＴに適用して、パケットを送出する。接続状態データがない場合は、エッジサーバ処理がパケットを所有マシンに転送する。クライアントからの複数パケットを含むＵＤＰ接続に関しては、クライアントアドレス及びポートについてのセッション情報を有するかどうかをマシンがチェックする。情報を有している場合は、マシンがそのＮＡＴ情報を使用する。有していない場合は、マシンが、このクライアントアドレス、ポートについての領域ワイドロックを取得することが好ましい。これによって、パケットが二台のゲートウエイサーバに同時に着信した場合に、この二台の一方だけがＮＡＴセッションを設定することを確実にする。

シーケンス番号変換
ゲートウエイサーバでのｏｉｐｄ処理が、ターゲットサーバからクライアントへのＳＹＮパケットを受信すると、シーケンス番号変換を行ってパケットにタグを付けて、パケット中のホストｉｄを表示する。この処理が、オーバーレイからのパケットを受信すると、そのパケットぱけっとの状態情報を有していない場合に、シーケンス番号を見て、どのゲートウエイサーバへパケットを転送するべきかを決める。各ホストが独自の識別子を割り振られていることが好ましい。各ゲートウエイ領域には、最大サイズが割り当てられ、シーケンス番号スペースは、２＊最大サイズのピースに分けられることが好ましい。ＳＹＮクッキーをサポートするために、最上位の８ビットのみを変更して、各ホストにシーケンス番号スペースの二つの連続ブロックを割り当てるのが好ましい。ゲートウエイ領域に着信する第１のパケットは１台のサーバによって処理され、次のパケットが状態同期する前に別のサーバで処理されると、第２のサーバはＡＣＫシーケンス番号の上位８ビットを用いて、パケットを転送するべきサーバを決定する。これは、図９に記載されている。ターゲットサーバへパケットを転送する前には、ｏｉｐｄ処理はシーケンス番号変換を適用しないようにして、ターゲットサーバが正しいＡＣＫシーケンス番号を得るようにしなければならない。

領域内送信
別のゲートウエイサーバにパケットを転送する前に、ヘッダフイールドの転送状態を変更して、パケットがすでに転送された旨を表示する。受信マシンは、このパケットをあたかもオーバーレイから受信したように操作するが、ｏｉｐｄ処理が何かの理由でパケットを再度転送する必要がある場合は、代わりにパケットをドロップする。

エッジ領域へのパケットの返送
好ましくは、パケットは、オーバーレイを介して最初にパケットを送信した領域と同じエッジ領域にターゲットサーバから返送される。これによって、エッジサーバで、クライアントが最初にパケットを送った仮想ＩＰの発信元アドレスを有するＩＰパケットを送信することができる。ゲートウエイ領域でパケットが受信されると、カプセル化したＩＰパケットは、クライアントが使用していた仮想ＩＰを含み、ヘッダはエッジ領域番号を含むであろう。この情報は接続によって保存され、ＮＡＴセッション情報と同じ方法で同期する。ゲートウエイサーバがターゲットサーバからパケットを受信すると、発信元ＩＰアドレス（ターゲットアドレスを含む）を、保存した仮想ＩＰで置き換える。次いで、パケットを正しい領域に転送する。

エッジサーバ領域と同様に、ゲート上領域がバディグループのサーバを実装することが好ましい。このグループは、ある領域用に構成されており、その領域中の各サーバは、活動性及び負荷をチェックするモニタ処理を具える。必要に応じて、マシンまたはソフトウエアで傷害迂回を実装することができる。

負荷の報告
オーバーレイメカニズムは、負荷バランスを実装することが好ましい。このため、各サーバがいくつかの負荷バランス機能を実行するマシン内ＤＮＳ処理を実行する。この機能は：仮想ＩＰアドレスとＮＡＴＩＰアドレスをマッピングしてエッジサーバを生かす、シーケンス番号をマッピングしてエッジサーバを生かす、シーケンス番号をマッピングして、中間サーバを生かす、機能である。これらの機能は、サービスＢ、サービスＣ、サービスＤの、３つの異なるサービスを必要とする。サービスＢは、オーバーレイに入力するバイトを表し、サービスＣは、オーバーレイから出力するバイトを表す。図１０は、様々な負荷情報片が、異なるサービスについて報告される様子を示す。

サービスＢは、仮想ＩＰアドレスとＮＡＴアドレスの双方をマシン上にマッピングする。インストール時に、スロットから仮想アドレスへ、及びＮＡＴスロットからＮＡＴアドレスへ１対１のマッピングが設定される。全ての領域が同じ番号のＶＩＰスロットを確実にサポートするようにするために、ネットワークのワイドコンフィグレーション変動を設定して、サービスＢマップにおけるＮＡＴアドレス用の所定のシーケンス番号セットを残しておくようにする。ＮＡＴスロットは、スロット番号で始まり、下方に動作する。ービスＢについては、マシン内ＤＮＳ処理が、エッジサーバの活動性、マシン能力をバイトで、及びスロットごとのバイト負荷を知る必要がある。マシン上で稼働しているモニタ処理を用いて活動性を測定する。ｏｉｐｄ処理はサーバ内外のバイト負荷をモニタ処理に報告する。サービスＣについては、マシン内ＤＮＳ処理が、エッジサーバの活動性、マシン能力（測定基準に従って）、及びシーケンス番号ごとの測定基準の値を知る必要がある。代表的な測定基準は「ｆｌｉｔ」である。「ｆｌｉｔ」は、一般的に所定のサーバマシン上の非帯域リソース利用を表す仕事の任意単位である。このような利用は、一般的には、ＣＰＵの利用、ディスクの利用、スレッドやセマフォなどのオペレーティングシステム抽出制限リソース、その他、及びこれらの組み合わせに及ぶ。代表的な実施例では、ｆｌｉｔは、いくつかの独立したマシン変動の所定の一次関数あるいは凸関数である。しかしながら、以下に大まかに説明する負荷バランスについては、サーバに入力するバイト数が、ｆｌｉｔの値としてとても近い数字である。サービスＤについては、マシン内ＤＮＳ処理が、中間サーバの活動性、マシン能力（測定基準に従って）、及びシーケンス番号ごとの測定基準の値を知る必要がある。

領域割当
領域割当処理は、オーバーレイメカニズムのＤＮＳコンテンツサーバ内で実行する。ある領域へマッピングした接続は、各々、クライアント−＞サーバ及びサーバ−＞クライアントからその領域へ対応するトラフィックを有しているので、サービスＢ及びＣを考慮する必要がある。このため、領域モニタ処理は、サービスＢ及びＣの内外のバイトの和を報告する。この領域割当処理は、エッジ領域ｆｌｉｔ容量測定基準と、エッジ領域バイト負荷と、ｆｌｉｔ負荷（サービスＢ及びＣについて）を知る必要がある。ある領域へのマッピングした各接続は、その領域が送受信する負荷量に影響する。なぜならば、パケットは、パケットを発信したエッジ領域へ送信されることが好ましいからである。これを正しく処理するためには、この領域割当処理が、入ってくるバイトと出て行くバイトの最大数を用いて、ある領域に負荷がどのようにかかるかを決定することが好ましい。

マップメーカ
割当処理（ＳＲＭＭ）は、着信領域（スロットと同じ）、エッジ領域対当たりのバイト数と、中間領域についての領域ｆｌｉｔ負荷という、二つの情報片を用いる。エッジにおけるｏｉｐｄ処理は、オーバーレイに入れるバイト数、好ましくは、着信領域によってブレークダウンされるバイト負荷を報告する。これは、オーバーレイにある要求であり、領域モニタからＳＲＭＭ処理への新しいメッセージ中で送信される値である。中間領域は、サービスＤの層バイト数とｆｌｉｔを報告する。ｆｌｉｔ負荷は、バイト負荷に関係するので、ＳＲＭＭ処理は、必要に応じてエッジバイトと、ｆｌｉｔキャップ、及びバイト／ｆｌｉｔ比を用いて、中間領域における妥当なバイトキャップを推測する。この情報は、ＳＲＭＭが次に承認する既存の領域割当メッセージになる。

（ＳＲＭＭ）処理は、エッジ領域からゲートウエイ領域への最適パス、並びに、ゲートウエイ領域からエッジ領域へ戻る最適パスを特定する領域レベルマップを生成する。上述したとおり、好ましくは、ＳＲＭＭサービスは、エッジ領域からの入力と、負荷、及び中央領域からの容量情報を要求する。更に、各中間領域は、一又はそれ以上の中央領域マップルールに割り当てられており、各スロットは、特定の中央領域マップルールに割り当てられている。好ましくは、ＳＲＭＭは、同じマップルールを有する中間領域を介して特定のスロットについてのトラフィックをマッピングするだけである。

動作中に、ＳＲＭＭは、各エッジ領域から各ゲートウエイ領域へ複数パスを決定する一方で、同じ中間領域を二つのパスが共有せず、全ての中間領域が正しく負荷バランスがとれるようにする。デフォルトによっては、３つのパスが選択される。これらの要求を処理するために、好ましくは、ＳＲＭＭアルゴリズムについて以下の簡素化を想定する。すなわち、選択した第１のパスは、十分な容量があることを提供するピンサブシステムからの最適な（すなわち、マルチホップパスをサポートすることができる）所定の情報であり、次の二つのパスは、単一の中間領域のみを含む。

パスの決定は、上述の想定に対応する二つの部分にブレークダウンされる。第１の部分は、最短パスアルゴリズムのシーケンスを動作させるステップを含む。各中央マップルールについて、Ｄｉｊｋｓｔｒａのアルゴリズムは各送信先ごとに稼働され、ここでは送信先がすべてのエッジ領域とゲートウエイ領域にある。必要に応じて、これらの計算にエッジバイト負荷を用い、各中間領域についてランニングトータルを追跡する。総負荷が各中間領域の容量以下であれば、この部分のパス決定が行われる。容量以下でない場合は、容量を超える全てのノードが価格調整を行い、アルゴリズムが繰り返される。価格調整は、オーバーフローするノードを使用する各リンクのスコアに恒常的要因を乗算することによって適用される。この処理は、安定するまで繰り返される。次いで、各ノードの容量が更新される。

基本的には、（エッジ領域、ゲートウエイ領域）の対（発信元、送信先）のリストが決定される。それぞれについて、アルゴリズムが、その対に十分な容量がある最も良い中間ノードを選択する。このアルゴリズムの出力は、領域ごとにサービスＤについてのＩＰ割当メッセージを作る。これは、（着信領域、パス番号）によってインデックスされる。

エッジマッピング
上述したとおり、カスタマＣＮＡＭＥのホストネームを、ＣＤＮサービスプロバイダのＤＮＳに提供するサービスを用いて、そのドメインについて権限が与えられる。所望の場合は、ホストネームは、グローバル輸送管理ホストネームに構築して、更なる利益を提供することができる。

背景として、オーバーレイメカニズムは、「顧客一人当たりの」領域を使用することができる。顧客一人当たりの領域は、単一のスロットのみについてのトラフィックをサポートする。このようなアプローチは、企業ファイヤーウオールの背後のユーザにとって望ましい。特に、このようなユーザは、パブリックＣＤＮエッジ領域へゆくことによって、ＷＡＮパフォーマンスへグレードを下げないように、ＬＡＮパフォーマンスを維持するであろうターゲットサーバ付近に位置するＣＤＮ領域にマッピングすることができる。図１１では、企業ファイヤーウオールの背後のクライアントが、ゲートウエイ領域に直接マッピングされており、一方で、その他のクライアントは、パブリック領域にマッピングされている。グローバル輸送管理を用いて、特別な、予め決められた発信元ＩＰアドレスを有するユーザは、これらの「顧客一人当たりの」領域にマッピングされる。

図１２は、この機能を提供するためにグローバル輸送管理（ＧＴＭ）処理をオーバーレイ内にどのように実装するかを示す処理フロー図である。所定の決定地点で情報が入手できない場合は、「何も」パスが取られないことが好ましい。従って、ＧＴＭが、予め決めたマッピングデータをなんら有していない場合は、クライアントがパブリック領域にマッピングされる。同様に、ＧＴＭが地理情報をなんら有していない場合は、クライアントはパブリック領域にマッピングされる。ＧＴＭが活動性フィードバック情報を有していない場合、その領域がダウンであると仮定して、ダイレクトＩＰアドレスを用いてクライアントをマッピングする。ＧＴＭは、その領域の仮想ＩＰにピンテストを行って、ゲートウエイ領域から活動性情報を得る。

フェイルセーフマッピング
背景として、カスタマのターゲットサーバアドレスは、フェイルセーフＩＰアドレスを考慮することができる。オーバーレイが端末相互間の問題（顧客特有の問題あるいはその他）を検出したら、ＣＤＮの権限のあるＤＮＳが、このＩＰアドレスを分配することが好適である。これは、全ての通信からオーバーレイを除去する効果を有する。図１３は、正常なオーバーレイルーティングを示す図であり、図１４は、フェイルセーフ動作を示す図である。フェイルセーフ動作は、例えば、複数領域がダウンするか、あるいは容量不足である、ＧＴＭが、ゲートウエイ領域において仮想ＩＰを試験する活動性情報を有していない、一又はそれ以上のネームサーバ処理が割当を行うのに十分な情報を有していない、その他、といった顧客一人当たりの問題など、様々な出来事の結果としてトリガされる。

管理プロトコル
ＣＤＮサービスプロバイダは、顧客がログイン可能であり、ルーティング構成、並びにビューパフォーマンスを実行できる、顧客が当面するエキストラネットと、トラフィック使用統計データを提供する。ルーティング構成は、ＢＧＰ情報を入力し、下が手エッジサーバは、ローカルルータ付きＢＧＰセッションと、オーバーレイネットワークを使用するアプリケーション用のアプリケーションＩＰ情報を設定できる。

本発明のオーバーレイメカニズムは、様々な利点を提供する。好ましくは、このメカニズムは、連続的にモニタを行い、各ローカルエッジノードから中間ノードへ、各ローカルエッジノードから各リモートエッジノードへ、及び全ての中間ノード間のパフォーマンスを分析する。従って、例えば、これらのパフォーマンスの測定には、待ち時間とパケットロスが含まれている。このデータは、組み合わせて分析され、二つのエッジ位置間の最適パスを決定する。オーバーレイネットワークが、ＢＧＰで決定したパスより良い型をを提供できる場合は、パケットを中断して、中間ノードを介してそのパケットルートを決定する。不良に動作するパスをさけてルーティングすることに加えて、オーバーレイは、動作可能時間を確実にするためにパケットの複製物を使用する。オーバーレイのパフォーマンス測定粒度は、出力がパケットの送信を中断できる程度である。この問題を防止するために、パケットは、エッジで複製され、複数のオーバーレイパスを介して送信される。このパスの一つは、直接的にルーティングしたパスであっても良いが、パケットが中断され、送信エッジでカプセル化されて、リモートエッジでカプセルが解かれる。リモートエンドで受信された第１のパケットを使用して、その他のパケットはドロップする。代替の実施例では、フェイルセーフＩＰアドレス（通常、ターゲットサーバのＩＰアドレス）は、ＣＤＮ認証ＤＮＳによってある条件の下分配される。

リモートアクセスの実施例
図１５に記載されているリモートアクセスでは、複数クライアント１５０２ａ−ｎが、ターゲットサーバ１５０４の単一のＩＰアドレスにパケットを送信している。オーバーレイメカニズム１５００は、権限のあるＤＮＳ１５０６と、少なくとも一つのエッジ領域１５０８と、一又はそれ以上の中間領域１５０１と、一又はそれ以上のゲートウエイ領域１５１２を具える。対象となるアプリケーションは、ターゲットサーバ上で一部実行可能である。クライアント側のアプリケーションは、クライアントマシンの上で実行する。このマシンは、ラップトップ、モバイルコンピュータ装置、その他であっても良い。このアプリケーションの特別な機能性（あるいは、クライアントとサーバに分散した状態で、アプリケーションをどのように実装するか）はオーバーレイからは見えない。これは、クライアントとサーバ間の通信が、ＩＰトランスポートを介して生じると想定されているだけである。この実施例では、このアプリケーションは、インターネットドメインに関連している。上述したとおり、このドメインは、サービスプロバイダによって管理されているオーバーレイネットワークドメインに対して付される（ＣＮＡＭＥを介して）。このアプリケーションドメインに対するＤＮＳクエリーが、権限のあるＤＮＳ１５０６をＶＩＰアドレスに戻す。所定のクライアント（そのマシンは、通常、クライアント側のアプリケーションあるいはインスタンスを稼働している）は、上述したとおり、オーバーレイメカニズムを介してターゲットサーバ上のこのアプリケーションに接続する。特に、このアプリケーション行きのデータパケットは、エッジにおいてカプセル化され、複製され、複数のパスを通って送信され、ゲートウエイで処理されて、複製物を除去する。ゲートウエイでは、送信先ＮＡＴが、仮想ＩＰをターゲットアドレスに変換し、発信元ネットワークアドレスポート変換を送信前にパケットに適用して、戻りのトラフィックもオーバーレイネットワークを介して送信されるようにする。好ましくは、情報を保存しておいて、戻りのトラフィックが、クライアントのパケットが発信されたエッジ領域に送られるようにする。アプリケーションが応答すると、ゲートウエイ領域がターゲットアドレスからＩＰパケットを受信して、そのパケットをネットワークアドレス変換しない。次いで、パケットがカプセル化される。このパケットの複数コピーが、次いで、複数パスに沿って送信される。中間サーバは、このパケットをこのセッションの元のエッジ領域に送り返す。このパケットは、エッジサーバによって受信され、複製物が除去される。パケットは、仮想ＩＰアドレスから発信されており、リクエストしているクライアントに送り返される。

リモートオフィスの実施例
この実施例では、図１６に示すように、アプリケーションがターゲットサーバ上１６０４で実行され、クライアントマシン１６０２（自身が、アプリケーションまたはアプリケーションインスタンスであってもよい）は、固定したリモートエンド地点にある。代表的な例では、クライアント１６０２とサーバ１６０４は、一対の地理的に分散したサイトに配置されている。理解を容易にするために、クライアントマシン１６０２は、企業ファイヤーウオールの外側であるが、ルータ１６０８近くに配置されていると仮定する。この実施例では、クライアントマシン１６０２は、リモートオフィス促進（ＲＯＡ）処理１６１０を実行する。この処理１６１０は、自身をターゲットサーバＩＰアドレスとして、公示している。従って、ルータ１６０８は、この処理をルータとして見ている。ターゲットサーバＩＰアドレスを公示することによって、処理１６１０は、ルータ１６０８を用いてＢＧＰセッションを設定し、これによって、ユーザに意識させることなく、リモートオフィスに位置するアプリケーション用に意図したデータパケットを遮断する。一旦遮断されると、この処理１６１０は、カプセル化と、リモートアクセス実施例のエッジサーバによって実行されるその他の機能を実行する。オーバーレイメカニズムは、上述した態様で、二つのサイト間にパケット通信を提供する。

リモートオフィスの実施例では、オーバーレイが、ＢＧＰプロトコルの使用を変更することによって、データをカプセル化する方法を提供する。一般的に、この技術は、ＥＧＲＰ、ＯＳＰＦ、その他を含む所定のインターネットプロトコルに用いることができる。変更ＢＧＰアプローチは好ましいが、インラインアプローチ（例えば、パケットグラバ）を用いてオーバーレイにパケットを設けることもできる。

変動
クライアントの帯域を節約し、サービスプロバイダの帯域コストを低減するために、どの程度パケットを複製するかについての動的決定を実装することが好ましい。従って、例えば、所定の数（例えば、３コピー）で始まって、この数を、ロス／待ち時間が受け入れ可能であれば、動的に低減する。

一般的に、上述したオーバーレイメカニズムは、任意のデータフローが統合的に実装されているルーティング「クラウド」として一般化することができる。このクラウド内で、上述した送信技術を用いて、データを一又はそれ以上のの中間ノードを通過させて、冗長パスに沿って転送し、送信メカニズムとしてＴＣＰあるいはＵＤＰを使用し、マルチディメンションパラメータスペース中の最適性を決定するフローまたはクラス特定ロジックあるいはこれらの組み合わせに従うことができる。

使用するアーキテクチュアと課金モデルに基づいて、ローカルコントローラ又は、「ノブマシーン」をオーバーレイの入り口地点で使用することができる。このエレメントの動機は、クラウドに流れる、クラウド内の帯域が独自のコストを有することである。いくつかの場合（例えば、全てのＶＰＮトラフィックが操作されている）このトラフィック全てがクラウドに流れることは意味がない。なぜなら、最小限、このソリューションについてのコストベースは、代替のソリューションの２倍であるからである。従って、コントローラの目的は、コスト／利益のトレードオフビジネス論理を伴うシステムを提供する簡単で有効な手段を提供することである。（このように、このボックスは、アグレッシブにシステムを使用するやり方、すなわち、その名前を制御する有効なノブである）。提供されたルールに基づいて、コントローラは、パケットごとに、あるいはフローごとに、トラフィックがクラウドを介してその他のエンドポイントに送信するべきか、あるいは直接に送られるべきかについて、決定を行う。デフォルトによっては、全てのトラフィックが、コントローラを介して流れることが好ましい。しかしながら、コントローラは、適宜のビジネス論理を使用して、フローをクラウドに送るべき時を決定するように構築することができる。この情報は、クラウド中で生じる挙動にも影響する。

コントローラによって使用できるルールは、全くフレキシブルである。このルールは、ドメイン（例えば、イントラネットトラフィックは重要であるが、所定のコンテンツプロバイダは重要ではない）、ＩＰアドレス（例えば、東京オフィスにトラフィックをルートづけることは重要であるが、シカゴオフィスには不要である）、パフォーマンス予測（例えば、コントローラは、親サーバを用いてこの直接かつ代替のパスについてのＱｏＳ測定基準を理解し、予測した改良が所定のスレッシュホールドより大きいか、及び／又は、直接パスの品質が所定のスレッシュホールド以下である場合に、トラフィックの方向付けを選択することができる）、信頼性の予測（例えば、コントローラは、直接かつ代替のパスに関する様々な信頼性測定基準を理解し、予測した改良が、所定のスレッシュホールドより大きい、及び／又は、直接パスの品質が所定のスレッシュホールドの下である場合に、トラフィック用の親サーバを介して代替パスを使用することを選択することができる）など、に基づいてトラフィックを選択するステップを具える。もちろん、これらのルールは共に用いることにより強力になる。例えば、異なるドメインについてパフォーマンスと信頼性の測定基準を別々に設定するように選択できる。

このように、パスの最適化は、時間をかけて集めたパフォーマンスデータに基づいて、一のノードから別のノードへＣＤＮ領域を介してデータパケットを得るという一般的な考え方である。この技術は、上述したとおり、ＨＴＴＰトラフィック用の顧客の元のサーバへ戻る接続性を改良するのに使用されていた。更に、サービス特性を調整して、この特性が、パフォーマンスを十分に改良できる（例えば、待ち時間をｘ％低減する）場合に、好適に呼び出されるようにする。本発明によれば、コンテンツ送出ネットワークは、「クラウド」として見られ、このクラウドに、データフローが入り込んで、「中央」をこえて最適に方向付けられ（例えば、最適化技術によって）、他方側に現れ、送信先に向けたその方向に現れる。例えば、イーストコースト（例えばケンブリッジ）のオフィスから、カリフォルニアのオフィス（例えばサンマテオ）に向けて出力するＶＰＮを考える。ＢＧＰを単に使用する代わりに、本発明は、このトラフィックを「入力ポイント」として方向付けることができる。次いで、このトラフィックはネットワークを介して流れ、適宜の数のバウンスを取って、適宜のオフィス近くの「出口ポイント」でネットワークを出る。特別な実装では、コントローラをケンブリッジオフィスにおいて、このコントローラを介して全トラフィックが流れる。このコントローラを用いて、両方のビジネスルール（例えば、第１ドメインへのトラフィックは重要であるが、第２ドメインへのトラフィックは重要でない）と、サービスの質（ＱｏＳ）ルール（例えば、直接的なパスが内場合、あるいは代替パスが何パーセントか良い場合にのみ、代替パスを用いる）に基づいてリアルタイムで決定を行う。もちろん、これらの例は、本発明を限定するものではない。

限定を意味するものではないが、コントローラマシンは、エッジあるいはＩＳＰネットワークに実装することができる。いくつかの可能なアプリケーションについて以下に述べる。

ウエブトランザクション
ウエブ上で安全なトランザクションを提供する企業は、本発明を用いて、これらのトランザクションの信頼性と性能を改善することができる。一例は、オンラインクレジットカードトランザクションのプロバイダである。トランザクションは、定義によるものであり、キャッシュ不可であるため、さらには、各リクエストが有価であるため、魅力的である。本発明は、単に、ＨＴＴＰＳサポートをエッジサーバ最適化技術に加えるだけでウエブトランザクションを容易にすることができる。このコンテキストでは、安全なコンテンツ（例えば，ＳＳＬを介して）をサポートするＣＤＮ領域を、始点への接続を用いて、あるいは、これによって提供されるネットワークを介して、ＨＴＴＰＳルーティングクラウドへの「入力地点」として見ることができる。本質的には、このＨＴＴＰエッジサーバの実装は、各エッジ領域が入力地点として作用し、ある領域セット（親領域）が出力地点として作用することができる、一般化したクラウドにも及ぶ。

もう一つの適用領域は、ＳＯＡＰがＨＴＴＰに実装されているため、安全なＨＴＴＰクラウドがＳＯＡＰベースの全トランザクションをサポートしている領域である。従って、本発明は、ＳＯＡＰベースのウエブトランザクションの実装に使用することができる。

ＶＰＮ ＱｏＳ
有効なフローのもう一つの機会はＶＰＮｓの領域にある。ＶＰＮトラフィックは、ビジネスが価値のあるものであるとの情報に関する特性と、地理的に分散した位置間を流れる定義による情報に関する特性の、二つの特性を有する。簡単なアイディアは、ＶＰＮトラフィックを、ファイヤーウォール背後の末端間のセマンティクスを有する暗号化したＩＰデータストリームとして見ることである。このように、ＵＤＰベースの転送メカニズムをクラウドを介して提供することが可能である。多分、トラフィックはクライアントから見えないようにノブマシンを介して流れ、適宜クラウドの方向に向かう。このようにして、ＶＰＮ上の全てのトラフィックが、ノブ設定に基づくサービスから利益を得る。

この技術は、企業コンテンツ送出ネットワークの提供に適用できる。企業ＣＤＮとクラウドを用いて、ＣＤＮサービスプロバイダは、企業がＶＰＮ−ベースのアーキテクチュアを持っている場合は、その企業データの各ピースのパフォーマンスと信頼性を改良することができる。例えば、ＶｏＤコンテンツと保存可能なウエブコンテンツは全て、カスタマのオフィスのキャッシュに保存することができる。しかしながら、ライブのストリーミングは、キャッシュに保存することができない。企業ＣＤＮは、有限であるリソースを保護するためにトラフィックを速度制限することができる。クラウドは、冗長性と再転送を提供して、これらのストリームの質を改良する。更に、Ｐ２Ｐビデオコンファレンス、データベース同期、他といった、その他のデータフローも、この機能性から利益を得ることができる。

ウエブサービスネットワーク
ウエブサービスがより広く受け入れられてくると、システムのキーの弱さの一つが、その間に生じるメッセージになる。この機能性（ＳＯＡＰ、ＵＤＤＩ、他）をサポートするためにいくつかのプロトコルが開発されているが、二つの要素が欠けている。第１の要素は、セキュリティ、待機、及び、非拒否／ロギングなどの、アプリケーション層機能セットであり、第２の要素は、これらのメッセージの転送メカニズムである。

ＢＧＰルーティング層をブラックボックスとして使用して、所定の通信にアウトバウンドルートとインバウンドルートを全て決定しており、従って、ＢＧＰ関連の問題の影響を受けにくいため、上述のオーバーレイ技術が有利であることは当業者には自明である。

当業者は、本発明が、アプリケーション特定測定基準に応じて、パフォーマンスと信頼性の改良のために、分散した潜在的グローバルコンピュータネットワーク内のＩＰトラフィックの層３の一般目的のルーティングを容易にすることを認識するであろう。このシステムは、任意のＩＰフローを受け入れて、このフローをコンテンツ送信ネットワークを介してルーティングを行い、例えば、メタデータによって設定された測定基準など、測定基準セットを実行するようにしている。このメタデータは、発信元、送信先、フロー、アプリケーションタイプ、他といった特性に基づいて、いくつかの方法に適用することができる。これらの測定基準を実行するために、このシステムは、ホップごと、パケットごとのベースで、代替ルート及び／又は複数ルートに沿ってトラフィックのルートを決定することもできる。

本発明について述べてきたとおり、以下の通り特許を請求する。

図１Ａは、４つの相互に接続されたネットワークのセットを示しており、ＢＧＰがどのようにネットワークＡとネットワークＤの間のパケットフローのルートの決定するかを示している。 図１Ｂは、ネットワークＡとネットワークＤがピアである場合に、問題が発生したときに送信先サーバが到達不可能である様子を示している。 図２は、ＢＧＰルーティングの決定が待ち時間について鈍感であり、このため、パフォーマンスが落ちることを示している。 図３は、通常のコンテンツデリバリネットワークエッジサーバの構成を示している。 図４は、本発明のオーバレイメカニズムがデータリンク内のルートを決定し、パフォーマンスを改良する様子を示している。 図５は、本発明のオーバレイメカニズムが、最小の待ち時間を有するパスを発見してパフォーマンスを改良する様子を示している。 図６は、本発明の一実施例に係るオーバレイメカニズムを具える一組の構成要素を示している。 図７は、図６のオーバレイメカニズムを介しでデータがどのように流れるかを示している。 図８は、一実施例において、ゲートウェイ領域がネットワークアドレス変換ＮＡＴを管理する様子を示している。 図９は、所定のゲートウェイ領域内で実行されるシーケンス番号変換機能を示している。 図１０は、様々な情報負荷の一部がオーバレイ内で報告される様子を示している。 図１１は、本発明の代替的な実施例を示しており、企業のファイヤウォールＩＰの背後のクライアントがゲートウェイ領域に直接的にマップされ、一方、他のクライアントが公の領域にマップされる。 図１２は、代替的な実施例において、グローバルなトラフィック管理（ＧＴＭ）がオーバレイ内で実現される様子を示す処理フロー図である。 図１３は、通常のオーバレイルーティングを示している。 図１４は、図１３に示すオーバレイのフェールセーフ動作を示している。 図１５は、オーバレイメカニズムを利用して、ターゲットサーバ上の所定のアプリケーションに対する複数のクライアントによるリモートアクセスを実現する様子を示している。 図１６は、オーバレイメカニズムを利用して、ターゲットサーバ上の所定のアプリケーションへのサイト対サイト（site-to-site）（リモートオフィス）を実現する様子を示している。

Claims (17)

1. １又はそれ以上のクライアントマシンのリモートアクセスをターゲットサーバ上で動作するアプリケーションに提供する方法において、クライアントマシンがインターネットプロトコル（ＩＰ）転送を用いてインターネット上のアプリケーションと通信し、前記方法が、
   前記クライアントマシンと前記アプリケーションの間で通信される要求データパケット毎に、前記要求データパケットをカプセル化し、前記カプセル化された要求データパケットを複製し、前記カプセル化された要求データパケットを一組のパスを介して転送するステップと、
   前記ターゲットサーバ近くのゲートウェイにおいて、前記要求データパケットを修復すべく受信データを処理し、ネットワークアドレス変換を前記修復された要求データパケットに適用し、前記アプリケーションでさらに処理すべく、前記要求データパケットを前記ターゲットサーバに転送するステップと、を具えることを特徴とする方法。
2. 請求項１に記載の方法において、前記カプセル化が、仮想ＩＰアドレスを有するサーバで行われることを特徴とする方法。
3. 請求項２に記載の方法において、所定の仮想ＩＰアドレスが、所定のドメインに対する問い合わせを前記クライアントマシンに実行させることにより取得されることを特徴とする方法。
4. 請求項２に記載の方法において、前記ネットワークアドレス変換が、前記仮想ＩＰアドレスを前記ターゲットサーバのＩＰアドレスに変換する送信先ネットワークアドレス変換（ＮＡＴ）を実行することを特徴とする方法。
5. 請求項４に記載の方法において、前記ネットワークアドレス変換が、更なる処理のために、前記パケットが前記ターゲットサーバに転送される前に、送信元ネットワークアドレス変換（ＮＡＴ）を前記パケットに適用することを特徴とする方法。
6. 請求項５に記載の方法がさらに、前記ゲートウェイで応答データパケットを受信し、前記応答データパケットをカプセル化し、前記カプセル化した応答データパケットを複製し、一組のパスを介して前記カプセル化した応答データパケットを転送するステップを具えることを特徴とする方法。
7. 請求項６に記載の方法がさらに、前記仮想ＩＰアドレスを有するサーバにおいて、前記応答データパケットを修復すべく受信データを処理し、前記要求データパケットを前記クライアントマシンに転送するステップを具えることを特徴とする方法。
8. 請求項３に記載の方法において、前記所定のドメインが、前記アプリケーションと関連するドメインをエイリアス化（aliasing）することにより取得されることを特徴とする方法。
9. 請求項８に記載の方法がさらに、所定の失敗条件に応じて、前記アプリケーションに関連するドメインを非エイリアス化（dealiasing）するステップを具えることを特徴とする方法。
10. 複数のクライアントマシンのリモートアクセスをターゲットサーバ上で動作するアプリケーションに提供する方法において、各クライアントマシンがインターネットプロトコル（ＩＰ）転送を用いてインターネット上のアプリケーションと通信し、前記方法が、
    各エッジ領域及び各ゲートウェイ領域が１又はそれ以上のサーバを具える少なくとも１又はそれ以上のエッジ領域及び１又はそれ以上のゲートウェイ領域を具えるオーバーレイネットワークを構築するステップと、
    クライアントマシン毎に、且つ前記アプリケーションと関連するホスト名のＤＮＳレゾリューション（resolution）に応じて、このようなクライアントマシンをそれぞれ、所定のエッジ領域内の所定のサーバに関連する仮想ＩＰアドレスに関連付けるステップと、
    前記所定のエッジ領域内の所定のサーバにおいて、前記クライアントマシンと前記アプリケーションとの間で通信される要求データパケット毎に、前記要求データパケットをカプセル化し、前記カプセル化された要求データパケットを複製し、前記カプセル化された要求データパケットをゲートウェイ領域の所定のサーバに転送するステップであって、前記要求データパケットが、一組のパスそれぞれを介して前記ゲートウェイ領域の所定のサーバに転送されるステップと、
    前記ゲートウェイ領域内の所定のサーバにおいて、前記要求データパケットを修復すべく受信データを処理し、ネットワークアドレス変換を前記修復された要求データパケットに適用し、前記アプリケーションでさらに処理すべく、前記要求データパケットを前記ターゲットサーバに転送するステップと、を具えることを特徴とする方法。
11. 請求項１０に記載の方法において、前記所定のエッジ領域が、ＤＮＳレゾリューション時において、最も実行可能なエッジ領域であることを特徴とする方法。
12. 請求項１０に記載の方法において、前記オーバーレイネットワークが一組の中間領域を具えており、少なくとも中間領域が一組のサーバを具えていることを特徴とする方法。
13. 請求項１０に記載の方法において、前記一組のパスそれぞれが、一組の中間領域により規定されることを特徴とする方法。
14. 請求項１０に記載の方法において、前記ネットワークアドレス変換が、前記仮想ＩＰアドレスを前記ターゲットサーバのＩＰアドレスに変換する送信先ネットワークアドレス変換（ＮＡＴ）を実行することを特徴とする方法。
15. 請求項１４に記載の方法において、前記ネットワークアドレス変換が、更なる処理のために、前記パケットが前記ターゲットサーバに転送される前に、送信元ネットワークアドレス変換（ＮＡＴ）を前記パケットに適用することを特徴とする方法。
16. 請求項１５に記載の方法がさらに、前記ゲートウェイで応答データパケットを受信し、前記応答データパケットをカプセル化し、前記カプセル化された応答データパケットを複製し、一組のパスを介して前記カプセル化された応答データパケットを転送するステップを具えることを特徴とする方法。
17. 請求項１６に記載の方法がさらに、前記仮想ＩＰアドレスを有するサーバにおいて、前記応答データパケットを修復すべく受信データを処理し、前記要求データパケットを前記クライアントマシンに転送するステップを具えることを特徴とする方法。

Images