JP2004510394A - 仮想ｉｐフレームワーク及びインターフェイス接続方法 - Google Patents

Abstract

インターフェース接続方法と仮想ＩＰフレームワーク（１０）。好適な実施例はＩＰレベルで動作し、これによりフレームワークはＩＰの上部で動作する任意のアプリケーションで動作可能となる。入データ・パケットとパケット片は、ルーテッド・プロセスが外部ルータにアドレスを提供するための複数のネットワーク終端装置（２１）で受信される。各ネットワーク終端装置は複数の転送プロセス（１１ａ〜１１ｎ）の１つと組み合わされ、各転送プロセスは複数のフラグメンタ／デフラグメンタ（１２ａ〜１２ｎ）に接続されている。各転送プロセスは、共通のソース・アドレスを有する全ての入データを受信するために単一のフラグメンタ／デフラグメンタを選択する。入パケットとパケット片は次に、選択されたフラグメンタ／デフラグメンタに送られて、そこで、必要ならば再組み立てされる。前記選択されたフラグメンタ／デフラグメンタは、この選択されたフラグメンタ／デフラグメンタが再組み立てされた入データ・パケットを送るべき相手の有効なアプリケーション・サーバ（１４〜１７）を識別する。

Description

【０００１】
（発明の背景）
（発明の技術分野）
本発明は、通信システム、特に、複数のサーバとインターネットのようなパケット・データ・ネットワークとの間で故障耐性（ｆａｕｌｔ　ｔｏｌｅｒａｎｃｅ）があり、スケールラブルなインターフェイスを提供する仮想のインターネット・プロトコル（ＩＰ）フレームワークとインターフェイス接続する方法とに関する。
【０００２】
（関連技術の記載）
多くの会社は、現在インターネットを介して行われるビジネスにより、それぞれの収入の流れの大部分または全てを確立している。従って、これらの会社は非常に高い信頼性あるアクセス及び交換のテクノロジーを必要とする。これらの会社が短い期間の間だけでもインターネット・アクセスを失うと、多くの収入が失われる。従って、インターネット・アクセス・テクノロジの故障耐性を増大することは極めて望ましい。更に、これらの種類の会社はデータ取引の必要が増大し得るネットワーク・アクセス・テクノロジを必要としている。もしも例えば、より大きな帯域幅を得る必要がある場合、これらの会社はこれを容易に行うことができることが必要である。それ故、スケーラビリティを提供するソリューションも望ましい。
【０００３】
今日、ＩＰ界に存在する種々のテクノロジは、全て問題または限界を有している。故障耐性のみを扱うシステムは、一般的にはこのシステムとスケーラビリティに重きを置くシステムの両方の要求を達成するためにスケーラビリティに重きを置くシステムとは組み合わせることができない。それは、スケーラビリティに重きを置くシステムの一部が故障耐性を有さず、これによりシステム全体の故障耐性に影響が与えられるからである。一般的には、その要求の一方は他方の要求と妥協することになる。
【０００４】
例えば、クライアントがウエッブ・サーバにアクセスする時、ブラウザは最初に、ドメイン・ネーム・サーバ（ＤＮＳ）を使用して一意のＩＰアドレスに変換されたユニフォーム・リソース・ロケータ（ＵＲＬ）の名称を得る。この一意なＩＰアドレスにより、クライアントは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）の要求を扱うサーバに達することができる。それ故、単一のＩＰアドレスをクライアントに提供するソリューションが必要である。このソリューションはスケーラビリティと故障耐性を提供すべきであり、クライアントに更なる要求を課すべきではない。更に、ソリューションはＨＴＴＰトラフィックまたはＴＣＰトラフィックに特に制限されるべきではない。ソリューションは全ての種類のＩＰトラフィックに適用可能であることが望ましい。
【０００５】
マーケットには、スケーラビリティの程度を与えるラウンド・ロビンＤＮＳが存在する。このラウンド・ロビンＤＮＳは、同一のＵＲＬ名称の場合、別のＩＰアドレスを毎回提供する。ＤＮＳは互いに異なるサーバ間での負荷を平衡する任意のアルゴリズムを使用することができる。更に別のサーバを加えてもよく、ＤＮＳはより多くのサーバに対し負荷を分散する。しかし、ラウンド・ロビンＤＮＳソリューションは、平衡した分散を保証するためにクライアントがＤＮＳ要求をしなければならないという制限を有している。クライアントは、ＩＰアドレスをキャッシュ保存する能力を有し、そして、将来のアクセスのためにＤＮＳから新しいＩＰアドレスを得るよりもむしろキャッシュ保存したＩＰアドレスを使用してもよい。これにより、スケーラビリティの特徴を無効とすることができる。それは、クライアントがＤＮＳにより戻されたＩＰアドレスをキャッシュ保存する時は常にラウンド・ロビンＤＮＳが分散を保証することができないからである。システムの故障耐性は、もしクライアントがサーバのＩＰアドレスをキャッシュ保存し、そのサーバが後で故障を生じる場合には不利な影響を被る可能性もある。従って、スケーラビリティと故障耐性はクライアントの挙動により拘束される。クライアントに制限を加えずにスケーラビリティと故障耐性を提供することが望ましい。従って、ラウンド・ロビンＤＮＳは充分ではない。
【０００６】
他のソリューションは、パケットを異なるエンド・ホストに向け直す焦点に対し全てのメッセージを送ることである。この種のソリューションは、ＷＯ９９／３３２２７に示してあり、そこでは、ネットワーク・フロー・スイッチ（ＮＦＳ）が使用される。しかし、このソリューションでは、システム能力は増大することができない。それは、ＮＦＳが制限ファクタとなるからである。このＮＦＳは、ネットワーク・カードとＣＰＵにより制御されるインターネット・コントローラとを有する標準のルータのように実施され、トラフィックはＣＰＵとカードとの間を流れる。従って、ＣＰＵにおける能力の限界によりシステム全体の能力を制限することができる。ＮＦＳは、システムの故障耐性を大いに減少する単一の故障点でもある。
【０００７】
ＥＰ　０　８６５　１８０　Ａ２では、要求を複数のサーバに分散する２つの代替手段が記載されているが、これらの代替手段のどれもスケーラビリティを提供するものではない。一方の代替手段では、入トラフィックを管理するためにディスパッチャが使用される。ルータは、どのサーバがトラフィックを取るべきかを決定するようディスパッチャに要求する。ディスパッチャは単一点であって、その能力が充分に利用されると、別のサーバは加えることができない。ディスパッチャは、データを送りもするので、単一の故障点であり、それによりシステムの故障耐性を減少させてしまう。他方の代替手段は、バスを介するブロードキャストを使用する。しかし、このバスの帯域幅が制限されると、システムのスケーラビリティは同様に制限される。
【０００８】
ローカルディレクタとして知られる他の製品は、パケットがエンド・ホストに到達する前にパケットの正しい再組み立てを保証する単一の焦点も提供する。ローカルディレクタは、ＶＩＰ終端装置として動作し、要求を次のいずれかを使用して実際のエンド・ホストに送る：
１．ＭＡＣアドレス変換。全てのエンド・ホストはＶＩＰ終端装置をサポートする。ローカルディレクタは、特定のエンド・ホストのＭＡＣアドレスを使用してこのエンド・ホストにＩＰデータグラムを送信する。エンド・ホストは次に直接発信終端装置に対し逆方向に送信することができる。
【０００９】
２．トンネリング。ＩＰデータグラムは、エンド・ホストに送られるように他のプロトコル層でカプセル化される。エンド・ホストはこのカプセル化をサポートしなければならない。次に、エンド・ホストは発信端に対し逆方向に直接、またはローカル・ディレクタを介して送信することができる。
３．ネットワーク・アドレス変換（ＮＡＴ）。ローカルディレクタは、ＩＰヘッダを変換してＶＩＰアドレスを目的のエンド・ホストの実際のＩＰアドレスで置換する。エンド・ホストは、ローカルディレクタに対して逆方向に送信しなければならない。
【００１０】
ローカルディレクタのような実装の場合の問題は、それらが故障耐性問題を解決する「ホット・スタンバイ」技術を使用するということである。ホット・スタンバイ・システムでは、もし主システムが故障した場合に引き受ける用意のできた十分に能力のあり副システムを保守する。これは、故障耐性を扱うが、スケーラビリティは扱わない。それは、主システムまたは副システムの能力がシステム能力を制限するからである。従って、ローカル・ディレクタを使用するアーキテクチャはスケーラビリティの要求を満足しない。
【００１１】
現存のソリューションの欠点を克服するために、複数のサーバとインターネットのようなパケット・データ・ネットワークとの間で故障耐性で拡張可能のインターフェースを提供する仮想ＩＰ（ＶＩＰ）フレームワークを有することは有利であろう。更に、フレームはクライアント、アプリケーション設計者及び現存のネットワーク基盤に対する影響を制限するであろう。最後にこのフレームワークは多重プロトコルに適用可能であろう。本発明は、このようなフレームワークを提供する。
【００１２】
（発明の要約）
本発明は、サーバとネットワーク・インターフェースの高度な故障耐性と線形のスケーラビリティを提供するインターネット接続方法及びフレームワークである。このフレームワークは、クライアントとサーバにとっては透過であり、周囲のネットワーク基盤に対する影響も最小である。更に、好適な実施例はＩＰレベルで動作するので、本発明はＩＰの上部で動作するどのようなアプリケーションでも動作させることができる。
【００１３】
従って、１つの態様において、本発明は、パケット・データ・ネットワーク（ＰＤＮ）と複数のアプリケーション・サーバとをインターフェース接続する故障耐性のある拡張可能な方法である。入メッセージの場合、この方法は複数のネットワーク終端装置においてＰＤＮからの入データ・パケットとパケット片とを受信することにより開始される。ネットワーク終端の各々は複数の転送プロセスの１つと関係があり、その転送プロセスの各々は複数のフラグメンタ／デフラグメンタ（ｆｒａｇｍｅｎｔｅｒ／ｄｅｆｒａｇｍｅｎｔｅｒ）に接続されている。次に、各転送プロセスでは、共通のソース・アドレスを有する全ての入データ・パケットと全てのパケット片を受信するために単一のフラグメンタ／デフラグメンタを選択する。これに伴い、共通のソース・アドレスを有する入データ・パケットとパケット片とは選択したフラグメンタ／デフラグメンタに送られる。この場合入データ・パケットは、転送プロセスから受信した入パケット片から再組み立てされる。フラグメンタ／デフラグメンタの各々は、今度は複数のアプリケーション・サーバに接続され、選択されたフラグメンタ／デフラグメンタはその再組み立ての入データ・パケットを受信するための有効なアプリケーション・サーバを識別する。次に、この選択されたフラグメンタ／デフラグメンタは、その再組み立ての入データ・パケットをその有効なアプリケーション・サーバに送る。
【００１４】
出メッセージの場合、本方法は、有効なアプリケーション・サーバがその複数のフラグメンタ／デフラグメンタから１つのフラグメンタ／デフラグメンタを選択すると開始される。これに伴って、有効なアプリケーション・サーバからその選択されたフラグメンタ／デフラグメンタに出データ・パケットが送られ、その選択されたフラグメンタ／デフラグメンタによりその複数の転送プロセスから単一の転送プロセスが識別される。この選択されたフラグメンタ／デフラグメンタは、次に、出データ・パケットをネットワーク終端装置と関係付けるその識別された転送プロセスに対し、その出データ・パケットを送る。次に、この出データ・パケットはその関連するネットワーク終端装置からＰＤＮに送られる。
【００１５】
他の態様では、本発明はＰＤＮから入データ・パケットとパケット片とを受信して再組み立てのパケットを複数のアプリケーション・サーバに送る故障耐性があり拡張可能なインターフェースを提供するフレームワークである。このフレームワークは、ＰＤＮから入データ・パケットとパケット片とを受信する複数のネットワーク終端装置と、このネットワーク終端装置に関連付けた複数の転送プロセスと、を有している。この転送プロセスの各々は、共通のソース・アドレスを有する全ての入データ・パケットと全てのパケット片とを受信するために複数のデフラグメンタから単一のフラグメンタを識別する手段を有している。各デフラグメンタは入パケット片から入データ・パケットを再組み立てする手段とこの再組み立てした入データ・パケットを受信するために有効なアプリケーション・サーバを識別する手段とを有している。複数のプロセス間通信（ＩＰＣ）リンクは各デフラグメンタを各アプリケーション・サーバに接続し、複数のＩＰＣリンクは各デフラグメンタを各転送プロセスと接続する。フレームワークは、特定のクライアントＩＰアドレスに達するために使用することができるＶＩＰ転送部のリストを含むルーチング・プロセスも有してもよい。このルーチング・プロセスはＰＤＮの外部ルータに対してネットワーク終端装置のアドレスを提供する。
【００１６】
更に他の態様において、本発明は複数のアプリケーション・サーバから出データ・パケットを受信して出データ・パケットと出パケット片をＰＤＮに送る故障耐性があり拡張可能なインターフェースを提供するフレームワークである。複数のＩＰＣリンクは各アプリケーション・サーバを複数のフラグメンタに接続する。データ・パケットを発信するアプリケーション・サーバは、フラグメンタを選択し、この選択したフラグメンタに対して出データ・パケットを送る。各フラグメンタは、出パケット片に出データ・パケットを分解する手段と、複数の転送プロセスから１つの転送プロセスを識別する手段と、を有している。ルーチン処理は、出データ・パケットの出ルーチング情報をフラグメンタに提供するために利用してもよい。複数のＩＰＣリンクは、各フラグメンタを各転送プロセスに接続し、その選択されたフラグメンタは、ネットワーク終端装置に転送するために出データ・パケットと出パケット片とをその識別した転送プロセスに送る。次に、ネットワーク終端装置は、出データ・パケットと出パケット片とをＰＤＮに送る。
【００１７】
本発明は、更によく理解され、その多くの目的及び利点は添付の明細書と共に図面を参照することにより当業者に更に明らかとなろう。
【００１８】
（実施の形態の詳細な説明）
本発明は、複数のサーバとパケット・データ・ネットワーク（ＰＤＮ）との間に故障耐性があり拡張可能なインターフェースを提供するフレームワークである。このフレームワークは、ユーザとＰＤＮの既存のインフラストラクチャとに対する影響を制限している。好適な実施例では、フレームワークはインターネット・プロトコル（ＩＰ）の上部で動作する任意のより高いレベルのプロトコルを使用してもよい仮想ＩＰ（ＶＩＰ）フレームワークである。例えば、このＶＩＰフレームワークは、インターネットとインターフェイス接続するために使用してもよく、インターネット・プロトコル（ＩＰ）の上部で動作する送信制御プロトコル（ＴＣＰ）、ユーザ・データグラム・プロトコル（ＵＤＰ）、ファイル転送プロトコル（ＦＴＰ）またはハイパーテキスト転送プロトコル（ＨＴＴＰ）で動作するサーバとインターフェイス接続してもよい。従って、本発明は、故障耐性とスケーラビリティの両方を提供しながらＩＰレベルで動作するように設計されている。こうして、ソリューションはＩＰの上部で動作する他のアプリケーションの全てに適用することができる。
【００１９】
更に、フレームワークは、このフレームワークの外部での処理には透過であり、クライアントもサーバもＶＩＰフレームワークには気づかない。フレームワークの上部のアプリケーションは、通常の場合のように動作しつづけ、アプリケーション・デザイナはソケットの開閉、データの読み取りなどのためのオペレーティング・システムからの同一のアプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用しつづける。アプリケーションは、それらの下にあるプロトコル層についての差異は分からない。ネットワークの観点から、外部ルータはフレームワークを単なるより多くのルータと見なし、通常の如くフレームワークとインターネット接続を行う。
【００２０】
ＶＩＰフレームワークの場合、トラフィックの要求を扱うために必要とされるだけのウエッブ・サーバを開始して、全てのウエッブ・サーバは同一のＶＩＰアドレスを与えるようにしてもよい。従って、ＶＩＰアドレスは全てのサーバにより使用されるようＶＩＰフレームワークの中央で定義されている。しかし、フレームワークは１つ以上のＶＩＰアドレスをサポートすることができ、１つ以上のウエッブ・サイトをホストをすることができる。それ故、ローカル・ルーチング・テーブルは特定のクライアントＩＰアドレスに達するために使用することができるＶＩＰ転送部１１のリストを含むルート付けプロセスで設定することができる。
【００２１】
ウエッブ・サーバを始動すると、ソフトウエアはリスニング・ポートとして動作するＴＣＰサーバ・ソケットを開放するためにオペレーティング・システムからＡＰＩを使用する。ＡＰＩで使用されるＩＰアドレスは「全ての」利用可能なＩＰアドレスに設定することができ、または、明確に設定することができる。ジグソー（Ｊｉｇｓａｗ）（ウエッブ・サーバ・プラットホーム）のようなプログラムには、このサーバ・ソケットを開く時にどのＩＰアドレスを使用すべきかをソフトウエアに知らせる各サーバごとのコンフィグレーション・ファイルが存在する。ジグソーは、サンプルのＨＴＴＰ　１−１の実装とＪａｖａ（Ｒ）で実施される高級なアーキテクチャの上部に種々の特徴とを提供する。他のＡＰＩにより、サーバは、特定のホストに対してどのＩＰアドレスを提供することができるかを発見することができる。従って、サポートされたＶＩＰアドレスのリストはこのフレームワークでの全てのプロセッサにこのＡＰＩを介して利用可能とされる。こうして、ＶＩＰサーバ・ソケットはこのフレームワークの任意のプロセッサで開始することができる。
【００２２】
ＶＩＰフレームワークは、ネットワーク容量に対して更に多くのネットワーク・カードを追加することにより、拡張することもできる。ネットワーク容量の増加はサーバの容量の増加に頼られるべきではないということに注意することが重要である。換言すれば、サーバ・ソフトウエアの場所はネットワーク・インターフェース・カードの場所から切り離す必要がある。従って、ＶＩＰフレームワークで、ＴＣＰサーバ・ソケットの所有者が存在する同一のプロセッサでＩＰスタックが終端すると仮定する従来技術のシステムとは異なり、ＩＰスタックは、アプリケーションが要求を出す場合に必ずしも終るとは限らない。
【００２３】
図１は、本発明の仮想ＩＰ（ＶＩＰ）フレームワーク１０の簡略化したブロック線図である。ＶＩＰフレームワークは３つの基本処理型、すなわち、ＶＩＰ転送とフラグメンテーション／デフラグメンテーションとルーチングとを有する分散されたＩＰスタックを提供する。これらは、複数のＶＩＰ転送部１１ａ〜１１ｎ、複数のフラグメンタ／デフラグメンタ１２ａ〜１２ｎ、及びルーテッド・プロセス１３として示される。このルーテッド・プロセスは、特定のクライアントＩＰアドレスに到達するために使用することができるＶＩＰ転送部１１のリストを含む局部的なルーチング・テーブルを備えている。ルーテッド・プロセスは、全てのプロセッサに共通／包括的な情報を含んでいるが、ルーテッド・プロセスの局部段階により各プロセッサで利用可能でもある。処理は、図面で八角形で示してあり、黒円はＩＰパケットを再度ルートするイーサネット（Ｒ）・カードのようなネットワーク・インターフェース・カードを表し、三角形は、内部プロセス間通信（ＩＰＣ）プロトコルを使用するインターフェースを表す。同一の機能を発揮する他のプロトコルも利用してよい。
【００２４】
ＨＴＴＰ−１（１４）、ＨＴＴＰ−２（１５）、ＨＴＴＰ−３（１６）、ＨＴＴＰ−４（１７）のような複数のウエッブ・サーバは、ＩＰＣによりフラグメンタ／デフラグメンタ１２に接続されてもよい。ＨＴＴＰ−１とＨＴＴＰ−２はそれぞれ別々のプロセッサ１８と１９で動作するように示してあるが、ＨＴＴＰ−３とＨＴＴＰ−４は、同一のプロセッサ２０で動作するように示してある。４つのサーバのみが示してあるが、フレームワークは拡張可能であり、更に多くのサーバは、システム容量を増加するために更に加えてもよい。更に、ＨＴＴＰサーバのみが示してあるが、上位のアプリケーションはファイル転送のためにウエッブ・サーバまたはＦＴＰサーバのようなＩＰで動作する任意のサーバ・アプリケーションを含んでもよい。
【００２５】
ＶＩＰ転送部は、複数の外部ルータ２２〜２４に接続されるイーサネット（Ｒ）・カード２１のようなネットワーク終端装置と関連付けられている。外部ルータは、イントラネットまたはインターネットのようなパケット・データ・ネットワーク（ＰＤＮ）２５に接続される。外部ルータの各々は、イーサネット（Ｒ）・カード（及び関連のＶＩＰ転送部）のいずれとも接続することができ、ＶＩＰ転送部の各々はフラグメンタ／デフラグメンタのいずれとも接続することができ、フラグメンタ／デフラグメンタの各々はサーバのいずれとも接続することができる。例として、外部ルータ２３からＶＩＰ転送部１１ａ、フラグメンタ／デフラグメンタ１２ａ及びＨＴＴＰ−２サーバ１５に対する接続を表す実線が描いてある。
【００２６】
インターネットに接続されるネットワーク終端装置（例えば、イーサネット（Ｒ）・カード）を物理的に有する各プロセッサの場合、ＶＩＰ転送プロセスはそのプロセッサ上に存在する。実際には、ＶＩＰ終端装置として使用される各カードは対応のＶＩＰ転送プロセスを有している。カードはランタイムにＶＩＰ終端装置用に構成することができる。各ＶＩＰ終端装置は、ルーテッド・プロセス１３で定義された全てのＩＰアドレスを終端してもよい。あるいはまた、特定のＶＩＰ終端装置は特定のＶＩＰアドレスを終端させるだけであるということを特定してもよい。
【００２７】
なお、ネットワーク終端装置２１はこのような終端装置がＶＩＰアドレスに使用されるか否かに関係なく（プロセッサあたり）局部的に定義されるＩＰアドレスで構成されている。外部ルータ２２〜２４は、例えば、ルーチング情報プロトコル（ＲＩＰ）を使用してルーテッド・プロセス１３によりどの終端装置がＶＩＰアドレスをサポートするかを知らされる。本発明のスケーラビリティの一部は、若干の異なるプロセッサに存在し得るイーサネット（Ｒ）・カードのような若干の物理的終端装置が存在し得るという事実から来る。一般的には、ＩＰアドレスとはカードまたはＩＰ終端装置のことを云う。通常、各イーサネット（Ｒ）・アドレスごとに、異なるＩＰアドレスが割り当てられる。本発明は同一のものを割り当てる。外部ルータは、どのカードも皆別のアドレスとして見る。従って、ＶＩＰフレームワークは外部ルータをネットワークの他のルータのように監視して、データを所望の時にそれらに送る。データが一度フレームワークに入ると、イーサネット（Ｒ）層は、そのデータを受信して、そのレイヤ１情報を検証する。このデータがＩＰスタックに行くと、このスタックは分散される。
【００２８】
図２Ａと図２Ｂは、入メッセージがＰＤＮ２５からＶＩＰフレームワーク１０で受信された時における本発明の方法の好適な実施例のステップを示すフローチャートである。まず図２Ａで、パケット／フラグメントは、ステップ３１においてＰＤＮ（イントラネット／インターネット）２５から外部ルータ２２〜２４に達する。上述のように及びステップ３２で示したように、外部ルータはルーテッド・プロセス１３によりどの終端装置がそのパケットで示されたＶＩＰアドレスをサポートするかを知らされる。ステップ３３で次にパケット／フラグメントは、サポートするネットワーク終端装置２１とそれらの関連するＶＩＰ転送部（ｆｏｒｗａｒｄｅｒ）１１に送られる。しかし、パケットは分解され（更に小さなフレームにスライスされ）ている可能性があるので、フラグメントはＶＩＰフレームワークに入るために異なるルートを取ってもよい。受信したフラグメントは、ＴＣＰとアプリケーション層とまで送る前に再組み立てをしなければならない。パケットの再組み立ては共通の場所で行わなければならない。再組み立てを任意の単一ＶＩＰ転送プロセスにより行うことはできない。それは、そのプロセスが全ての分解フレームについて知らなくてよいからである。従って、入パケットの再組み立てはフラグメンタ／デフラグメンタ・レベル１２において行われる。
【００２９】
ＶＩＰ転送部１１により受信された全てのパケットは、パケットがどのような再組み立て（デフラグメンテーション）を必要としなくても所定のフラグメンタ／デフラグメンタ１２に対して、例えばＩＰＣを使用して、転送される。フレームワークでの進行障害の発生を回避するために、本発明は常にアクティブのフラグメンタ／デフラグメンタ・プロセスの複数の段階を作成する。例えば、フレームワークはプロセスの２５６個の段階を有してもよい。これらのフラグメンタ／デフラグメンタ・プロセスの段階は、フレームワークで分散され、多重プロセッサで動作する。例えば、２つのプロセッサの各々で動作する１２８個の段階、４つのプロセッサの各々で動作する６４個の段階、または極端な場合、２５６のプロセッサの各々で動作する１個の段階が存在してもよい。数２５６は、単に例示的なものであって実際には更に多く、または更に少ない段階が存在してもよい。その数は、必要ならば増大または減少させてもよい。
【００３０】
（各パケット片を含む）同一ソースから生じる全てのＩＰパケットは、同一ソースのＩＰアドレスを含んでいる。ステップ３４で、ソースＩＰアドレスは、どのフラグメンタ／デフラグメンタの段階１２がパケットの再組み立てに使用すべきかを決定するための決定論的機能計算において使用される。この決定論的機能計算により、特定のソースＩＰアドレスから来る全てのパケットは、ステップ３５において同一のフラグメンタ／デフラグメンタ・プロセスの段階に常に送られる。全てのＶＩＰ転送プロセス段階１１は、この同一の決定論的機能を利用する。従って、特定ソースＶＩＰアドレスから来る全てのパケットは、同一のフラグメンタ／デフラグメンタに達するよう保証される。好適な実施例では、その決定論的機能は完全なソースアドレスの値を０とｎ−１（ｎがフラグメンタ／デフラグメンタの段階の数の場合）の間の値に小さく切る。あるいはまた、完全なソースアドレス、行き先アドレスまたは行き先ポートは、予測可能な結果が得られる限りその機能への入力として利用してもよい。
【００３１】
あるフラグメンタ／デフラグメンタの段階が故障すると、この段階は、フレームワークの同一プロセッサまたは他のプロセッサで自動的に再始動される。もしあるＶＩＰ転送段階が故障すると、それは同一プロセッサで自動的に再始動される。ルーテッド・プロセス１３は、もしその故障が持続性のものである場合、故障したＶＩＰ転送段階が除外されるように外部ルータ２２〜２４を更新する。従って、フレームワークは、故障耐性と線形拡張可能な能力の両方を増大させる。
【００３２】
ステップ３６で、要求されると、フラグメンタ／デフラグメンタ１２はパケットの再組み立てを行う。ＩＰパケットが一度再組み立てされると、それはアプリケーション・サーバまで送ることができる。しかし、ＶＩＰフレームワークは、種々のアプリケーション・サーバで動作可能であるので、フラグメンタ／デフラグメンタ・プロセス１２は、まず、行き先ＶＩＰアドレスのための有効なアプリケーション・サーバを識別しなければならない。ステップ３７で、フラグメンタ／デフラグメンタは行き先ＶＩＰアドレスをパケットから抽出する。次に、処理は、図２Ｂ（ステップ４１）に移動し、そこで、フラグメンタ／デフラグメンタはＶＩＰアドレス／サーバ・ソケットの組み合わせとＩＰＣポートを関連付ける更新されたサーバ・ソケット・リストを保守する。この処理は以下に図３に関連して更に詳細に記載する。ステップ４２で、フラグメンタ／デフラグメンタは、サーバ・ソケット・リストから１つ以上の有効なアプリケーション・サーバを識別する。ステップ４３において、１つ以上の有効なアプリケーション・サーバが識別されたということが決定されると、処理はステップ４４に移動して、フラグメンタ／デフラグメンタはラウンド・ロビン選択または負荷平衡のような処理を使用して単一のサーバを選択する。次に、処理はステップ４５に移動して、フラグメンタ／デフラグメンタはその選択したサーバに対しＩＰＣを使用して再組み立てのパケットを送る。
【００３３】
次に図３を見ると、ＩＰＣポートをＶＩＰアドレス／サーバ・ソケットの組み合わせと関連付ける更新されたリストを保守するステップを示すフローチャートが示してある。ステップ５１において、全てのフラグメンタ／デフラグメンタはフレームワーク内のＩＰＣポート名称を公表するということを特に言及している。ステップ５２においてＶＩＰアドレス用のサーバ・ソケット（例えば、８０）を開くためにサーバがＡＰＩを使用すると、システム・コールは、それがＶＩＰアドレス用のソケットであるということを決定する。ステップ５３で、次にフレームワークはこの新しいサーバ・ソケットでＩＰＣポートのリストを更新するようフラグメンタ／デフラグメンタの１つに要求する。ＶＩＰアドレスとサーバ・ソケットの組み合わせが同一の場合、多くのＩＰＣポートが存在してもよい。従って、５４において、サーバ・ソケット・リストは全てのフラグメンタ／デフラグメンタの間で分散され共有される。
【００３４】
パケットが任意のソースのＩＰアドレスから生じてフラグメンタ／デフラグメンタの１つに達すると、その処理はそのパケットから行き先ＶＩＰアドレスと行き先ソケット（例えば、８０）を抽出する。次に、そのサーバ・ソケット・リストを介してフラグメンタ／デフラグメンタは、有効なアプリケーション・サーバを見つける。もし複数のサーバがこのＶＩＰアドレスとサーバ・ソケットの組み合わせとを提供できる場合、フラグメンタ／デフラグメンタはその１つを選択する。例えば、もし６つの異なるプロセッサが存在してＦＴＰサーバがこのＶＩＰアドレスを求めてそれらプロセッサで動作する場合、フラグメンタ／デフラグメンタはその１つを選択する。この選択はラウンド・ロビン選択に基づいてもよく、または、プロセッサの負荷、遅延または他の要因を考慮するために拡張してもよい。接続が一度なされると、この接続に対する他のパケットの全ては、そのサーバまで戻り、それらの処理を仕上げる。
【００３５】
図４は、出メッセージがＶＩＰフレームワークからＰＤＮへ送られる時の、本発明の方法の好適な実施例のステップを示すフローチャートである。ＨＴＴＰ−２　１５のようなアプリケーション・サーバがそれ自体と遠隔のクライアントとの間にソケットを確立する必要がある場合、このアプリケーション・サーバはまず、ステップ６１においてクライアント・ソケットを開く。このクライアント・ソケットは、そのアプリケーションと、遠隔のＩＰアドレス用の再組み立て点としての役目を果たすフラグメンタ／デフラグメンタ１２ａと、の間の管理されるＩＰＣリンクにより表される。フラグメンタ／デフラグメンタは、到来メッセージ用のフラグメンタ／デフラグメンタを識別するためにＶＩＰ転送部により使用されるのと同一の決定論的機能により、ステップ６２において識別してもよい。システム・コールはどのフラグメンタ／デフラグメンタがこの特定の遠隔ＩＰアドレスを与えるかを決定し、このフラグメンタ／デフラグメンタがステップ６３において、ＩＰＣ管理のリンクを設定するよう要求する。
【００３６】
ＩＰＣ管理のリンクが一度設定されると、サーバとクライアントは互いの通信のためにこの新しいクライアント・ソケットを使用することができる。前述のように、サーバに送られたクライアント・パケットは任意のＶＩＰ転送部１１を介してフレームワークに到達し、クライアント特定のフラグメンタ／デフラグメンタ１２と管理されたＩＰＣリンクとを介してサーバ・アプリケーションに転送される。クライアントに送られたサーバ・パケットはステップ６４において、アプリケーション・サーバからその管理されるＩＰＣリンクを介してフラグメンタ／デフラグメンタ１２に送られる。ステップ６５で、次にフラグメンタ／デフラグメンタは要求があればパケットを細分化し、ステップ６６でどの出ルートを使用すべきかを決定するためにルート付けプロセス１３においてルーチング・テーブルを使用する。
【００３７】
このルーチング・テーブルは、特定のクライアントＩＰアドレスに到達するために使用し得るＶＩＰ転送部１１のリストを含む局部的なテーブルである。例えば、内部ネットワーク用の第１のルートと外部ネットワーク用の別のルートが存在し得る。ルーテッド・プロセスは、単一のプロセッサに集中するか、分散してもよく、ルーテッド・プロセスは多重プロセッサで動作する。ルーテッド・プロセスは、ＶＩＰ転送部のリストを戻してもよく、すなわち、ラウンド・ロビンまたは負荷平衡の手順により選択された特定のＶＩＰ転送部を戻してもよい。局部的に利用可能なＶＩＰ転送部に優先順位を与えるために、局部利用可能なＶＩＰ転送部用のルーチング・テーブル登録は低いＭＥＴＲＩＣ値を有している。ステップ６７において、パケットはＰＤＮ２５に対してネットワーク終端装置２１と外部ルータ２２〜２４とを介して送られる。
【００３８】
上記から、ＶＩＰフレームワークにより外部存在は、フレームワーク全体を単一のＩＰアドレスとして見ることができ、同時に、高度のスケーラビリティと故障耐性を提供することができる。スケーラビリティの場合、別のプロセスをＶＩＰフレームワークの任意の層に追加することができる。もし、例えば多数のトランザクションが存在する場合、更に多くのサーバをＶＩＰフレームワークの実装に影響を与えずに加えることができる。もし充分なサーバが存在するが帯域幅に問題がある場合は、更に多くのＶＩＰ転送部を加えることができる。もしルータに対するトランクの容量が超過すると、別のトランクをＶＩＰフレームワーク基盤のいずれをも変化する必要なしに加えることができる。
【００３９】
故障耐性のために、故障したプロセスは迂回させることができる。それは、多重プロセッサで動作する各プロセスの段階が多く存在するからである。ＶＩＰ転送層では、ポートのイーサネット（Ｒ）・カードとルータとの間には物理的な接続が存在する。もしＶＩＰ転送プロセス１１が故障すると、出メッセージは外部ルータ２２〜２４に対しその故障のプロセスを迂回することができる。到来メッセージの場合、外部ルータは故障を検出し、パケットを、動作するＶＩＰ転送プロセスにルートを決めて送る。フラグメンタ／デフラグメンタ・レベルでは、プロセスの段階の各々はＶＩＰフレームワークで一意の「名称アドレス」を有している。従って、例えばプロセッサ１または１５で動作するこのプロセスの特定段階は常に見つけられる。もしある段階が故障してその後再始動される場合、その段階は同一の独自性を有する。それは一意の同一性を有するので、メッセージはその同一の段階に方向を決めて送り戻される。
【００４０】
同様に、状態依存の全てが制限され除外されていたという事実は、故障耐性に寄与する。すなわち、フラグメンタ／デフラグメンタとＨＴＴＰサーバとのようなクライアントとサーバとの位置における２つのプロセスの間でのトランザクションに関するメッセージが到来し、そして、フラグメンタ／デフラグメンタ・プロセスが故障すると、サーバは未決のトランザクションがあると言って数秒内にメッセージを送り返す。このメッセージが送り返された時は、故障したフラグメンタ／デフラグメンタ・プロセスはＶＩＰフレームワークで同一のプロセッサかまたは別のプロセッサのいずれかで再始動されているであろう。次に、フラグメンタ／デフラグメンタはそのトランザクションを続行し、フラグメンタ／デフラグメンタが故障した時に動作状態にあったプロセスのどれにでもパケットを送り始める。従って、その情報はフラグメンタ／デフラグメンタには保持されず、すなわち、情報は状態なしとなる。
【００４１】
従って、リスクは、プロセス故障の時に確立されていたトランザクションを失うだけで済む。しかし、ＴＣＰのようなプロトコルは誤り訂正機構を有していて、もしフラグメントが失われると送信を再度試みる。しかし、本発明は、ＴＣＰまたは再送信の試みを行う他のプロトコルに対して制限されない。例えば、ＵＤＰは再送信の能力を本来有していない。それは、送信物の配信を保証する必要がないからである。この場合、ＶＩＰフレームワークは、プロトコルの要件と一致する。
【００４２】
従って、フレームワークの利点には、サーバの線形のスケーラビリティ、ネットワーク・インターフェースの線形のスケーラビリティ、及び高度の故障耐性が含まれる。フレームワークは、クライアントとサーバにとって透過であるので、周りのＰＤＮ基盤に対する影響は最小である。更に、好適な実施例はＩＰレベルで動作するので、多くの種々のアプリケーションは上位層（ＵＤＰ，ＨＴＴＰ，ＦＴＰなど）で動作することができる。なお、本発明は第２世代のＩＰｖ４に制限されず、第３世代のＩＰｖ６に適用可能でもある。
【００４３】
更に、本発明は、ＩＰに対して制限されない。本発明は、他のプロトコルがメッセージ識別ヘッダと、メッセージ内容を含む要素を利用する限り、その他のプロトコルにも同様に適用可能である。例えば、遠距離通信においては、シグナリング・システム７（ＳＳ７）プロトコルが利用され、本発明は互いにトラフィックを発生し合う数千のノードを修正する必要なしに遠距離通信ネットワークで故障耐性とスケーラビリティとを提供するためにＳＳ７で実施してもよい。
【００４４】
フレームワークは、アプリケーション特定層より下のプロトコル・スタックの任意のレベルで実施することができる。この好適な実施例は、本発明の適用性を拡大しＩＰで動作する全てのプロトコルに対し利点を与えるためにＩＰ層において実施される。フレームワークは、特定のアプリケーションまたはＨＴＴＰのようなプロトコルに対し利点を与えることが望まれる場合、より高いレベルで実施することができる。
従って、本発明の動作及び構成は上記から明らかであると信ずる。図示し記載されたフレームワークと方法は好適なものとして特徴付けられたが、上記の請求項に明示された本発明の範囲から逸脱せずに種々の変形及び変更がなし得ることは容易に明らかであろう。
【図面の簡単な説明】
【図１】
本発明の仮想ＩＰ（ＶＩＰ）フレームワークの簡略化したブロック線図である。
【図２Ａ】
入メッセージがパケット・データ・ネットワークからＶＩＰフレームワークで受信された時の本発明の方法の好適な実施例のステップを示すフローチャートである。
【図２Ｂ】
入メッセージがパケット・データ・ネットワークからＶＩＰフレームワークで受信された時の本発明の方法の好適な実施例のステップを示すフローチャートである。
【図３】
ＩＰＣポートをＶＩＰアドレスとサーバ・ソケットとの組み合わせに関連付ける更新リストを保守するステップを示すフロー・チャートである。
【図４】
送信メッセージがＶＩＰフレームワークからパケット・データ・ネットワークに送られる時の本発明の方法の好適な実施例のステップを示すフローチャートである。

Claims (17)

1. 複数のアプリケーション・サーバとパケット・データ・ネットワーク（ＰＤＮ）との間に故障耐性があり拡張可能なインターフェースとを提供するフレームワークにおいて、
   前記ＰＤＮからの入データ・パケットと入パケット片とを受信すると共に、出データ・パケットと出パケット片とを前記ＰＤＮに送信する複数のネットワーク終端装置と、
   入データ・パケットをアプリケーション・サーバに送信すると共に出データ・パケットを前記アプリケーション・サーバから受信する複数のフラグメンタ／デフラグメンタであって、各前記フラグメンタ／デフラグメンタは、
   入パケット片から入データ・パケットを再組み立てする手段と、
   その再組み立てされた入データ・パケットを受信するために前記複数のアプリケーション・サーバから有効なアプリケーション・サーバを識別する手段と、
   出データ・パケットを出パケット片に分解する手段と、
   出データ・パケットと出パケット片とを受信するための複数の転送プロセスから１つの転送プロセスを識別する手段と、
   を有する前記複数のフラグメンタ／デフラグメンタと、
   転送プロセス（１１）の各々が前記複数のネットワーク終端装置（２１）の１つと関連していて、共通のソース・アドレスを有する入データ・パケットと入パケット片との全てを受信するために前記複数のフラグメンタ／デフラグメンタから単一のフラグメンタ／デフラグメンタを識別する手段を含んだ複数の転送プロセスと、
   前記転送プロセスの各々と前記フラグメンタ／デフラグメンタの各々との間の複数のプロセス間通信（ＩＰＣ）リンクと、
   前記フラグメンタ／デフラグメンタの各々と前記アプリケーション・サーバの各々との間の複数のＩＰＣリンクと、
   を備えた前記フレームワーク。
2. 前記フレームワークは、アプリケーション・サーバ・レベルの下の任意のプロトコル・レベルで実行される、請求項１記載のフレームワーク。
3. 前記フレームワークは、インターネット・プロトコル（ＩＰ）レベルで実行され、前記フレームワークは、前記ＩＰ・プロトコルによりサポートされる任意のプロトコルを動かすアプリケーション・サーバをサポートする仮想ＩＰ（ＶＩＰ）フレームワークである、請求項２記載のフレームワーク。
4. 前記ＰＤＮはインターネットであり、前記ネットワーク終端装置はイーサネット（Ｒ）・カードである、請求項３記載のフレームワーク。
5. 前記フレームワークは、シグナリング・システム７（ＳＳ７）フレームワークであって、このＳＳ７によりサポートされる任意のプロトコルを動かすアプリケーション・サーバをサポートする、請求項２記載のフレームワーク。
6. 前記フラグメンタ／デフラグメンタにより、前記アプリケーション・サーバの変更なしに前記アプリケーション・サーバはソケットを開閉し、データ・パケットを送受信することができる、請求項１記載のフレームワーク。
7. 前記フレームワークにアドレスのテーブルを有していて、前記ＰＤＮの外部ルータに対してネットワーク終端装置のアドレスを提供するルーチング・プロセスを更に有する、請求項１記載のフレームワーク。
8. 前記ルーチング・プロセスの前記テーブルは、特定のネットワーク終端装置のための特定のフレームワーク・アドレスを特定する、請求項７記載のフレームワーク。
9. 前記ネットワーク終端装置は、前記ＰＤＮの外部ルータと通信し、この外部ルータは追加のネットワーク・ルータのように見える、請求項７記載のフレームワーク。
10. 前記ルーチング・プロセスは、出データ・パケットのための出ルーチング情報を前記フラグメンタ／デフラグメンタに提供するルーチング・テーブルを有する、請求項７記載のフレームワーク。
11. 前記出ルーチング情報は、前記フラグメンタ／デフラグメンタが出データ・パケットと出パケット片とを送信すべき場合の、前記複数の転送プロセスの１つの識別を有している、請求項１０記載のフレームワーク。
12. 入データ・パケットと入パケット片をパケット・データ・ネットワーク（ＰＤＮ）から受信すると共に、再組み立てされたパケットを複数のアプリケーション・サーバに送信する故障耐性があり拡張可能なインターフェースを提供するフレームワークにおいて、
    入データ・パケットと入パケット片とを前記ＰＤＮから受信する複数のネットワーク終端装置と、
    入データ・パケットを前記アプリケーション・サーバに送信する複数のデフラグメンタであって、各前記デフラグメンタが、
    入パケット片から入データ・パケットを再組み立てする手段と、
    前記の再組み立てされた入データ・パケットを受信するために前記複数のアプリケーション・サーバから有効なアプリケーション・サーバを識別する手段と、
    を有する複数のデフラグメンタと、
    各々が前記複数のネットワーク終端装置の１つと関連していて、共通のソース・アドレスを有する入データ・パケットとパケット片の全てを受信するために前記複数のデフラグメンタから単一のデフラグメンタを識別する手段を備えている複数の転送プロセスと、
    前記転送プロセスの各々と前記フラグメンタ／デフラグメンタの各々との間の複数のプロセス間通信（ＩＰＣ）リンクと、
    前記フラグメンタ／デフラグメンタの各々と前記アプリケーション・サーバの各々との間の複数のＩＰＣリンクと、
    を備えたフレームワーク。
13. 複数のアプリケーション・サーバから出データ・パケットを受信すると共に、出データ・パケットと出パケット片とをパケット・データ・ネットワーク（ＰＤＮ）に送信する故障耐性があり拡張可能なインターフェースを提供するフレームワークにおいて、
    複数の転送プロセスと、
    前記アプリケーション・サーバから出データ・パケットを受信する複数のフラグメントであって、各前記フラグメントは、
    出データ・パケットを出パケット・フラグメントに分解する手段と、
    出データ・パケットと出パケット片とをネットワーク終端装置に転送するために前記複数の転送プロセスから１つの転送プロセスを識別する手段と、
    を有する複数のフラグメントと、
    各々が、前記複数の転送プロセスの１つと関連付けられていて、出データ・パケットと出パケット片とを前記ＰＤＮに送信する複数のネットワーク終端装置と、
    前記フラグメントの各々と前記アプリケーション・サーバの各々との間の複数のプロセス間通信（ＩＰＣ）リンクと、
    前記フラグメンタの各々と前記転送プロセスの各々との間の複数のＩＰＣリンクとを、
    有するフレームワーク。
14. 複数のアプリケーション・サーバをパケット・データ・ネットワーク（ＰＤＮ）とインターフェース接続する、故障耐性があり拡張可能な方法において、
    複数のネットワーク終端装置において、前記ＰＤＮから入データ・パケットと入パケット片とを受信するステップと、
    前記ネットワーク終端装置の各々を複数の転送プロセスの１つと関連付けるステップと、
    前記転送プロセスの各々を複数のフラグメンタ／デフラグメンタに接続するステップと、
    各転送プロセスにより共通のソース・アドレスを有する前記入データ・パケットとパケット片の全てを受信するために単一のフラグメンタ／デフラグメンタを選択するステップと、
    共通のソース・アドレスを有する前記入データ・パケットと入パケット片とを前記選択されたフラグメンタ／デフラグメンタに送信するステップと、
    前記転送プロセスから受信された前記入パケット片から前記選択されたフラグメンタ／デフラグメンタにより入データ・パケットを再組み立てするステップと、
    前記フラグメンタ／デフラグメンタの各々を前記複数のアプリケーション・サーバに接続するステップと、
    前記再組み立てされた入データ・パケットを受信するため、前記複数のアプリケーション・サーバから前記選択されたフラグメンタ／デフラグメンタにより有効なアプリケーション・サーバを識別するステップと、
    前記選択されたフラグメンタ／デフラグメンタから前記有効なアプリケーション・サーバに前記再組み立てされた入データ・パケットを送信するステップと、
    を有する故障耐性があり拡張可能な方法。
15. 前記有効なアプリケーション・サーバにより前記複数のフラグメンタ／デフラグメンタから１つのフラグメンタ／デフラグメンタを選択するステップと、
    前記有効なアプリケーション・サーバから前記選択されたフラグメンタ／デフラグメンタに出データ・パケットを送信するステップと、
    前記選択されたフラグメンタ／デフラグメンタにより前記複数の転送プロセスから単一の転送プロセスを識別するステップと、
    前記選択されたフラグメンタ／デフラグメンタから前記識別された転送プロセスに前記出データ・パケットを送信するステップと、
    前記識別された転送プロセスにより前記出データ・パケットをネットワーク終端装置と関連付けるステップと、
    前記関連付けられたネットワーク終端装置から前記ＰＤＮに出データ・パケットを送信するステップと、
    を更に有する請求項１４記載の故障耐性があり拡張可能な方法。
16. 前記選択されたフラグメンタ／デフラグメンタにより前記出データ・パケットを出パケット片に分割するステップを更に有する、請求項１５記載の故障耐性があり拡張可能な方法。
17. 前記選択されたフラグメンタ／デフラグメンタから前記識別された転送プロセスに前記出データ・パケットを送信する前記ステップは、前記選択されたフラグメンタ／デフラグメンタから前記識別された転送プロセスに出パケット・データを送信するステップも含む、請求項１６記載の故障耐性があり拡張可能な方法。

Images