JP4658606B2 - Ｉｐネットワーク接続のための資源管理 - Google Patents

Description

本発明は、ＩＰネットワーク接続のための資源管理に関する。

本願は、その全体を本明細書に組み込んだ、２００２年１０月４日の「ＬＩＮＵＸ ＫＥＲＮＥＬ ＣＨＡＮＧＥＳ ＦＯＲ ＶＩＲＴＵＡＬ ＲＯＵＴＥＲＳ ＡＮＤ ＤＩＳＴＲＩＢＵＴＥＤ ＨＯＳＴ ＦＵＮＣＩＴＯＮＳ」という名称の、米国仮出願第６０／４１６，１５１号の特典を請求する。

Ｌｉｎｕｘのようなオペレーティングシステムは、コンピュータのハードウェアおよび他の資源によるソフトウェアの使用に役立つことを含めて、コンピュータにおいて重要な役割を果す。場合により、オペレーティングシステムまたは関連するソフトウェアは、コンピューティングタスクを課される際に、コンピュータの資源を共用または組み合わせることを可能にする。

例えば、コンピュータ資源の共用を可能にするために様々なシステムが提案されてきた。これらは、仮想マシンモニタ、マシンシミュレータ、アプリケーションエミュレータ、オペレーティングシステムエミュレータ、埋め込まれたオペレーティングシステム、レガシー仮想マシンモニタ、およびブートマネージャを含む。これらシステムのそれぞれを、以下で概説する。

仮想マシンモニタ
１９６０年代後半および１９７０年代の集中的な研究の対象であった１つのシステムは、「仮想マシンモニタ」（ＶＭＭ）として知られるようになった。例えば、Ｒ．Ｐ．Ｇｏｌｄｂｅｒｇ著、「Ｓｕｒｖｅｙ ｏｆ ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ ｒｅｓｅａｒｃｈ」、ＩＥＥＥ Ｃｏｍｐｕｔｅｒ、第７巻、第６号、１９７４年を参照されたい。この期間、さらにＩＢＭ社は、そのＶＭ／３７０システムで使用するための仮想マシンモニタを採用した。

仮想マシンモニタは、ハードウェア上で直接実行され、マシンのすべての資源を仮想化するソフトウェアの小さな一部である。エクスポートされたインターフェースはマシンのハードウェアインターフェースと同じなので、オペレーティングシステムはＶＭＭの有無を判定することができない。したがって、ハードウェアインターフェースが基礎をなすハードウェアと互換性を有するならば、同じオペレーティングシステムを、仮想マシンモニタ上または未加工のハードウェア上で実行することができる。

仮想マシンモニタは、ハードウェアが不足しており、オペレーティングシステムが未発達の頃には一般的であった。システムのすべての資源を仮想化することにより、複数の独立したオペレーティングシステムが同じマシン上に共存することができる。例えば、各ユーザは独自の仮想マシンに単一のユーザオペレーティングシステムを実行させることができる。

仮想マシンモニタの研究は、仮想化に特に適したプロセッサアーキテクチャの設計をもたらした。これにより、仮想マシンモニタは、モニタの実施を簡素化し性能を向上させる「直接実行」として知られる技術を使用することができるようになった。直接実行により、オペレーティングシステムがその特権のある命令を直接実行できないように、ＶＭＭは、特権の低いモードでプロセッサをセットアップする。特権の低い実行は、例えばオペレーティングシステムが特権のある命令を発行しようとする際などに、トラップを生成する。したがって、仮想マシンでオペレーティングシステムの正確な実行を可能にするには、ＶＭＭは、そのトラップを正確にエミュレートするだけでよい。

ハードウェアが低価格化し、オペレーティングシステムが複雑化したので、直接実行に基づくＶＭＭはその魅力を失い始めた。しかし最近では、特定の問題を解決するためにＶＭＭが提案されている。例えば、「Ｈｙｐｅｒｖｉｓｏｒ−ｂａｓｅｄ ｆａｕｌｔ ｔｏｌｅｒａｎｃｅ」、ＡＣＭ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍｓ（ＴＯＣＳ）、第１４巻、（１）、１９９６年２月でＴ．Ｃ．ＢｒｅｓｓｏｕｄおよびＦ．Ｂ．Ｓｃｈｎｅｉｄｅｒによって記載され、また米国特許出願第５，４８８，７１６号の「Ｆａｕｌｔ ｔｏｌｅｒａｎｔ ｃｏｍｐｕｔｅｒ ｓｙｓｔｅｍ ｗｉｔｈ ｓｈａｄｏｗ ｖｉｒｔｕａｌ ｐｒｏｃｅｓｓｏｒ」、（Ｓｃｈｎｅｉｄｅｒ他著）に記載されるように、Ｈｙｐｅｒｖｉｓｏｒシステムは故障耐性を提供する。別の例として、Ｄｉｓｃｏシステムは、拡張可能なマルチプロセッサで有用なオペレーティングシステムを実行する。「Ｄｉｓｃｏ：Ｒｕｎｎｉｎｇ Ｃｏｍｍｏｄｉｔｙ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍｓ ｏｎ Ｓｃａｌａｂｌｅ Ｍｕｌｔｉｐｒｏｃｅｓｓｏｒｓ」、Ｅ．Ｂｕｇｎｉｏｎ、Ｓ．Ｄｅｖｉｎｅ、Ｋ．Ｇｏｖｉｌ、およびＭ．Ｒｏｓｅｎｂｌｕｍ著、ＡＣＭ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍｓ（ＴＯＣＳ）、第１５巻、第４号、１９９７年１１月、４１２〜４４７頁を参照されたい。

仮想マシンモニタは、「バイナリエミュレーション」または「バイナリトランスレーション」として知られる技術を使用して、異なるプロセッサアーキテクチャ間にアーキテクチャ上の互換性を提供することもできる。これらのシステムでは、仮想アーキテクチャと基礎をなすアーキテクチャとは一致せず、これらは基礎をなすアーキテクチャ上に仮想アーキテクチャをエミュレートする必要があるので、ＶＭＭは直接実行を使用することができない。これは、特定のプロセッサのアーキテクチャのために書かれた仮想マシン全体（オペレーティングシステムおよびアプリケーション）を、互いの上で実行することを可能にする。例えば、ＩＢＭ ＤＡＩＳＹシステムは、ＰｏｗｅｒＰＣおよびｘ８６システムをＶＬＩＷアーキテクチャ上で実行することを最近提案した。例えば、Ｋ．ＥｂｃｉｏｇｌｕおよびＥ．Ｒ．Ａｌｔｍａｎ著、「ＤＡＩＳＹ：Ｃｏｍｐｉｌａｔｉｏｎ ｆｏｒ １００％ Ａｒｃｈｉｔｅｃｔｕｒａｌ Ｃｏｍｐａｔｉｂｉｌｉｔｙ」Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ２４ｔｈ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｃｏｍｐｕｔｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ、１９９７年を参照されたい。

マシンシミュレータ／エミュレータ
マシンエミュレータとしても知られるマシンシミュレータは、既存のオペレーティングシステム上でアプリケーションプログラムとして実行される。これらは、オペレーティングシステムおよびそのアプリケーションを実行するのに十分な精度を有する所与のコンピュータシステムのコンポーネントすべてをエミュレートする。マシンシミュレータは、マルチプロセッサの性能を検討する研究でしばしば使用される。例えば、Ｍ．Ｒｏｓｅｎｂｌｕｍ他著、「Ｕｓｉｎｇ ｔｈｅ ＳｉｍＯＳ ｍａｃｈｉｎｅ ｓｉｍｕｌａｔｏｒ ｔｏ ｓｔｕｄｙ ｃｏｍｐｌｅｘ ｃｏｍｐｕｔｅｒ ｓｙｓｔｅｍｓ」、ＡＣＭ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｍｏｄｅｌｉｎｇ ａｎｄ Ｃｏｍｐｕｔｅｒ Ｓｉｍｕｌａｔｉｏｎ、第７巻、第１号、１９９７年１月を参照されたい。これらは、Ｉｎｔｅｌ ｘ８６マシンを「ＶｉｒｔｕａｌＰＣ」または「ＲｅａｌＰＣ」製品としてＰｏｗｅｒＰＣベースのＡｐｐｌｅ Ｍａｃｉｎｔｏｓｈシステムでシミュレートするためにも使用されている。

マシンシミュレータは、ＤＡＩＳＹのようないくつかのＶＭＭとバイナリエミュレーション技術を共用する。しかしマシンシミュレータは、ホストオペレーティングシステム上で実行される点で、ＶＭＭと異なる。マシンシミュレータはオペレーティングシステムによって提供されるサービスを使用できるので、このことにはいくつかの利点がある。一方、これらのシステムは、ホストオペレーティングシステムによってある程度の制約を受ける場合がある。例えば、保護を提供するオペレーティングシステムは、アプリケーションプログラムに、特権のある命令を発行し、またはそのアドレス空間を直接変更することを許可しない。これらの制約は、通常、特にアプリケーションから保護されたオペレーティングシステム上で実行される場合には、重大なオーバーヘッドに繋がる。

アプリケーションエミュレータ
マシンシミュレータと同様に、アプリケーションエミュレータも、異なるプロセッサアーキテクチャ全体に互換性を提供するために、アプリケーションプログラムとして実行される。しかしマシンシミュレーションとは異なり、これらは、アプリケーションレベルのソフトウェアをエミュレートし、そのアプリケーションのシステムコールをホストオペレーティングシステムへの直接コールに変換する。これらのシステムは、アーキテクチャを検討する研究において、また新しいＰｏｗｅｒＰＣベースのＭａｃｉｎｔｏｓｈシステム上の６８０００アーキテクチャ用に書かれたレガシーバイナリを実行するに、使用されている。これらは、Ｍｉｃｒｏｓｏｆｔ ＮＴを実行するＡｌｐｈａワークステーション上でＭｉｃｒｏｓｏｆｔ ＮＴのために書かれたｘ８６アプリケーションを実行するためにも使用されている。すべての場合に、予想されるオペレーティングシステムは、基礎をなすオペレーティングシステムと一致し、これによってこの実施態様は簡素化される。ＩｎｓｉｇｎａのＳｏｆｔＷｉｎｄｏｗｓ（登録商標）として知られる他のシステムは、ＰＣ以外のプラットフォームでＷｉｎｄｏｗｓ（登録商標）アプリケーションおよびＷｉｎｄｏｗｓ（登録商標）オペレーティングシステムの修正バージョンを実行するためにバイナリエミュレーションを使用する。少なくとも２つの知られたシステムにより、Ｍａｃｉｎｔｏｓｈアプリケーションを他のシステム上で実行することができる。すなわち、Ｅｘｅｃｕｔｅｒは、それらをＬｉｎｕｘまたはＮｅｘｔを実行するＩｎｔｅｌプロセッサで実行し、ＭＡＥはそれらをＵｎｉｘ（登録商標）オペレーティングシステム上で実行する。

オペレーティングシステムエミュレータ
オペレーティングシステム（ＯＳ）エミュレータは、１つの所与のオペレーティングシステムアプリケーションバイナリインターフェース（ＡＢＩ）のために書かれたアプリケーションを別のオペレーティングシステム上で実行させることを可能にする。これらは、元のオペレーティングシステムに対してそのアプリケーションによって行われたすべてのシステムコールを、基礎をなすオペレーティングシステムに対する一連のシステムコールに翻訳する。ＡＢＩエミュレータは、Ｕｎｉｘ（登録商標）アプリケーションをＷｉｎｄｏｗ ＮＴ（Ｓｏｆｔｗａｙ ＯｐｅｎＮＴエミュレータ）上で実行し、またＭｉｃｒｏｓｏｆｔ社製のオペレーティングシステムのために書かれたアプリケーションをパブリックドメインオペレーティングシステム（Ｌｉｎｕｘ ＷＩＮＥプロジェクト）上で実行することを可能にするために現在使用されている。

基本的にオペレーティングシステムから独立した仮想マシンモニタおよびマシンシミュレータと異なり、ＡＢＩエミュレータは、それらがエミュレートしているオペレーティングシステムと緊密に結合している。アプリケーションがターゲットプロセッサの命令セットアーキテクチに対して既にコンパイル済みであるという点で、オペレーティングシステムエミュレータはアプリケーションエミュレータと異なる。ＯＳエミュレータは、アプリケーションの実行を気にかける必要はなく、基礎をなすオペレーティングシステムに対して行うコールだけを気にかければよい。

埋め込まれたオペレーティングシステム
ホストオペレーティングシステムによって提供されないアプリケーションに対して付加的な保証を提供することが目的の場合には、ユーザレベルでのＡＢＩのエミュレーティングは任意選択ではない。例えば、ＶｅｎｔｕｒＣｏｍ ＲＴＸ Ｒｅａｌ−Ｔｉｍｅサブシステムは、リアルタイムのカーネルをＭｉｃｒｏｓｏｆｔ ＮＴオペレーティングシステムに埋め込む。これは、リアルタイムのプロセスが同一システム内で従来のＮＴプロセスと共存することを効率的に可能にする。

この共存は、オペレーティングシステムの最低レベルの修正、すなわちそのハードウェア抽象層（ＨＡＬ）を要求する。これは、ＲＴＸシステムが最初にすべての入出力割込みを処理することを可能にする。どちらの環境も同じアドレス空間を共用し、エントリポイントに割り込むので、このソリューションは、Ｗｉｎｄｏｗｓ（登録商標）ＮＴと緊密に連結されている。

レガシー仮想マシンモニタ
最も顕著にはＩｎｔｅｌアーキテクチャを有する特定のプロセッサは、所与のレガシーアーキテクチャを仮想化するように特別に設計された特別実行モードを含んでいる。このモードは、レガシーアーキテクチャの厳密な仮想化をサポートするように設計されており、既存のアーキテクチャの仮想化をサポートするようには設計されていない。

レガシー仮想マシンモニタは、プロセッサの特別モードを使用したレガシーオペレーティングシステムの実行を可能にする、適切なソフトウェアサポートから構成される。具体的には、Ｍｉｃｒｏｓｏｆｔ社製のＤＯＳ仮想マシンは仮想マシン内のＤＯＳをＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）およびＮＴ上で実行する。別の例としては、フリーウェアＤＯＳＥＭＵシステムはＬｉｎｕｘ上でＤＯＳを実行する。

これらのシステムは、一般には仮想マシンモニタの一形式と言われるが、これらは、ＤＯＳＥＭＵのような既存のオペレーティングシステム上で、またはＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）およびＭｉｃｒｏｓｏｆｔ ＮＴのような既存のオペレーティングシステムの一部として実行される。この点で、これらは、上記の本当の仮想マシンモニタとも、後述する本発明に適用される「仮想マシンモニタ」という用語の定義とも全く異なる。

資源を結合するという点で、結合の欠如を処理することが困難または不可能である可能性のある、要求の多いコンピューティングタスクを処理するために、このような結合を使用することができる。例えば、電気通信ネットワークには、広帯域低遅延の情報フローをサポートすることが益々求められている。要求される帯域幅は、いくつかのアプリケーションに対しては、秒速ギガビット近くの急速処理である（具体的には、例えばビデオオンデマンド、動画の共用シミュレータ、および分散コンピューティング）。

「インテリジェントネットワーク」を提供することは、特定番号へのコール転送のように、コンピュータプログラムを交換局に接続された複数の（例えば最高１００の）ホストコンピュータ上で実行することに役立つ。サービスが特定の顧客に提供されるべき方法（例えば、顧客へのコールがルーティングされるべき特定番号）は、ホストコンピュータ上のその顧客に関して記憶されたデータによって異なる。したがって、数十、数百ものホストコンピュータ上には数百万の加入者記録がある可能性がある。

「Ｔｗｅｎｔｙ−ｔｗｅｎｔｙ ｖｉｓｉｏｎ−ｓｏｆｔｗａｒｅ ａｒｃｈｉｔｅｃｔｕｒｅｓ ｆｏｒ ｉｎｔｅｌｌｉｇｅｎｃｅ ｉｎ ｔｈｅ ２１ｓｔ ｃｅｎｔｕｒｙ」、Ｐ．Ａ．Ｍａｒｔｉｎ、ＢＴ ＴｅｃｈｎｏｌＪ 第１３巻、第２号、１９９５年4月で、著者は、要求される分散型処理を実施するためにオブジェクト指向技術を使用することを提案している。

オブジェクト指向技術の説明は、例えば、ＢＴ ＴｅｃｈｎｏｌＪ第１１巻、第３号（１９９３年7月）、Ｅ．Ｌ．ＣｕｓａｃｋおよびＥ．Ｓ．Ｃｏｒｄｉｎｇｌｅｙ編、「Ｏｂｊｅｃｔ ｏｒｉｅｎｔｅｄ ｔｅｃｈｎｏｌｏｇｙ」に記載されている。この用語は常に正確に使用されるわけではないが、本明細書では、オブジェクト指向コンピューティングは、データが「カプセル化された」形式で記憶されるコンピューティング技術のことである。この形式では、データはコーリングプログラムまたはルーチンによって直接アクセス可能ではなく、データを読み、書き、編集することのできるプログラムの限られた一部によってのみアクセス可能である。データの記録およびその関連付けられたコンピュータコードは「オブジェクト」と呼ばれる。オブジェクトへの／からの通信は、一般に「メッセージの受け渡し」によるものである。すなわち、オブジェクトへのコールは、データ値を渡し、オブジェクトに含まれる複数のプログラムのうちの１つのプログラムの動作を呼び出し、その動作は次いでデータ値を戻す。

オブジェクト指向方式の使用を望むプログラマーには、様々な言語が使用可能である。そのうちの現在最も一般的なものはＣ＋＋である。
分散型処理は、いくつかの点で単一プロセッサ動作と異なる。まず、他のプログラムまたはデータが同一ホストコンピュータ上にコーリングプログラムとして置かれているか、または異なるホストコンピュータ上に置かれているかによって、異なるアクセス技術が要求される場合がある。プログラムまたはデータの位置は、別のプログラムからそこに到達できる速度にも影響を与える。また、１つまたは複数のホストコンピュータは、動作を他のコンピュータに任せて、故障する可能性がある。

分散型コンピューティングは、従来は、１つのコンピュータ上の「クライアント」プログラムが別のコンピュータ上の「サーバ」プログラムに問い合わせ、その「サーバ」プログラムが次に、クライアントプログラムが要求した機能を実行するか、またはデータを戻す、「クライアント／サーバ」構成を使用することによって実行されている。

オブジェクト指向技術は、分散型処理には広く適用されて来なかった。この点における最新技術の概要は、「Ｏｂｊｅｃｔ ｏｒｉｅｎｔｅｄ ｐｒｏｇｒａｍｍｉｎｇ ｓｙｓｔｅｍｓ」、Ｂｌａｉｒ Ｇ．、Ｐｉｔｍａｎ Ｐｕｂｌｉｓｈｉｎｇ、Ｌｏｎｄｏｎ、１９９１年（ＩＳＢＮ ０−２７３−０３１３２−５）の特に第9章、２２３〜２４３頁、と、「Ｄｉｓｔｒｉｂｕｔｅｄ ｓｙｓｔｅｍｓ ａｎｄ ｏｂｊｅｃｔｓ」、Ｄａｖｉｄ ＨｕｔｃｈｉｓｏｎおよびＪｏｎａｔｈａｎ Ｗａｌｐｏｌｅに記載されている。従前の試みでは、分散処理を取り扱うように従来のオブジェクト指向プログラミングを拡張するために、一般に、新しい構文が既存のコンピュータ言語に追加され、または新しいコンピュータ言語が作成された。

特定のアプリケーションは変更される可能性があるが、無線通信システムのコンポーネントは、以下で詳述するように一般に類似している。例えば、無線通信システムは、通常、無線端末すなわち移動局、無線基地局、携帯電話交換中継局（ＭＴＳＯ）としばしば呼ばれる交換またはネットワーク制御デバイス、および公衆交換電話網（ＰＳＴＮ）のような、無線通信システムがアクセスを提供するネットワークを含む。

様々な無線通信アプリケーションは、使用可能な周波数スペクトラムを効率良く使用するよう情報を送信するために、複数の変調技術のどれかを使用する。例えば、高容量複数アクセスシステムを構築するために、周波数分割多元接続（ＦＤＭＡ）、時分割多元接続（ＴＤＭＡ）、および符号分割多元アクセス変調技術が使用される。一般的な無線スペクトラムを占有する多くの移動局と通信するように設計された電気通信システムは、複数アクセスシステムと呼ばれる。

例えば、ＡＭＰＳアナログセルラ無線システムのようなＦＤＭＡアナログセルラシステムでは、使用可能な周波数スペクトラムは、多数の無線チャネル、例えば、メッセージ伝送チャネルにそれぞれが対応した、数対の送受信搬送波周波数などに分割される。各送受信周波数チャネルの帯域幅は、一般に２５〜３０ｋＨｚの狭帯域である。したがって、ＦＤＭＡシステムは、情報を、音声信号のような送信された情報の帯域幅と同等の帯域幅で送信することを可能にする。ＦＤＭＡシステムにおけるセルラサービスエリアは、一般に複数のセルに分割されており、各セルは、セル間の共同チャネル干渉を低減するのに役立つように選択された一組の周波数チャネルを有する。

伝送回路が周波数と時間の両方のドメイン、例えばＦＤ／ＴＤＭＡシステムで特徴付けられるように、周波数分割がしばしば時分割と組み合わされる。デジタルＦＤ／ＴＤＭＡ（一般にＴＤＭＡと呼ばれる）セルラシステムでは、狭帯域周波数チャネルは、複数のタイムスロットに分割されるデジタル伝送経路として再フォーマットされる。様々なコールからのデータ信号は、割り当てられたタイムスロットにインターリーブされ、それに相当するより高いビットレートで送出され、各移動局に割り当てられたタイムスロットが定期的に反復される。ＴＤＭＡ帯域幅はある程度ＦＤＭＡ帯域幅よりも広いが、約３０ｋＨｚの帯域幅は一般にＡＭＰＳ−ＤデジタルＴＤＭＡセルラシステムに使用される。

セルラ複数アクセス変調に対するもう１つの方式はＣＤＭＡである。ＣＤＭＡは、送信された信号が占有する帯域幅はベースバンド情報信号（例えば、音声信号）が要求する帯域幅よりもかなり広い、無線通信システムを介して情報を送信するためのスペクトラム拡散技術である。したがって、ＣＤＭＡ変調は、同一周波数チャネルを共用する様々な信号を特定するためにコードワードを使用して、多重変調によりスペクトル的に狭帯域情報信号を広帯域幅全体に広げる。送信された信号の認知は、適切なコードワードを使用してスペクトル的にコード化された信号を選択することにより行われる。ＦＤＭＡおよびＴＤＭＡ変調技術で使用される約３０ｋＨｚの狭帯域チャネルとは対照的に、ＣＤＭＡシステムは、一般に、約１．２５ＭＨｚまたはそれ以上の帯域幅を利用する。

通常、上記の移動通信システムは、地理的「対象エリア」が「セル」と呼ばれる複数のより小さな地理的エリアに区画されるように、階層的に構成される。図１を参照すると、各セルは、ベーストランシーバステーション（「ＢＴＳ」）１０２ａによってサービスを受けることが好ましい。いくつかのＢＴＳ １０２ａ〜ｎは、ベースステーションコントローラ（「ＢＳＣ」）１０６ａにより固定リンク１０４ａ〜ｎを介して集中的に管理される。ＢＴＳおよびＢＳＣは、基地局サブシステム（「ＢＳ」）１０７と総称される場合がある。いくつかのＢＳＣ １０６ｂ〜ｎは、固定リンク１０８ａ〜ｎを介して移動交換局（「ＭＳＣ」）１１０により集中管理することができる。

ＭＳＣ １１０はローカル交換局（後述する移動管理要件を処理する付加的な特徴を有する）として動作し、数群の幹線を介して電話網（「ＰＳＴＮ」）１２０と通信する。米国移動網は、家庭用ＭＳＣとサービス提供ＭＳＣを含む。家庭用ＭＳＣは、移動加入者（上記で移動局または「ＭＳ」とも呼ばれる）１１４に関連付けられた交換局に対応するＭＳＣである。この関連付けは、ＭＳの、エリアコードのような電話番号に基づいている。ＭＳの例には、移動電話、ＰＤＡ、双方向ページャ、またはラップトップコンピュータのようなハンドヘルドデバイス、または冷蔵車または軌道車、コンテナ、もしくはトレーラに取り付けられた移動ユニットのような移動ユニット装置が含まれる。

家庭用ＭＳＣは、後述するホームロケーションレジスタ（「ＨＬＲ」）１１８を担当する。一方、サービス提供ＭＳＣは、ＭＳコールをＰＳＴＮに接続するために使用される交換局である。したがって、家庭用ＭＳＣとサービス提供ＭＳＣの機能は、同一エンティティによってサービスが提供される場合があるが、そうでない場合もある（ＭＳがローミング中の場合など）。通常、訪問位置レジスタ（「ＶＬＲ」）１１６はＭＳＣ １１０と共に置かれ、その移動網には論理的に単一のＨＬＲ（論理的に単一のＨＬＲは、物理的に分散しているが単一エンティティとして扱われる）が使用される。後述するように、ＨＬＲおよびＶＬＲは、加入者情報およびプロフィールを記憶するために使用される。

無線チャネル１１２は、対象エリア全体に関連付けられる。上記のように、無線チャネルは、個々のセルに割り当てられた数群のチャネルに区画される。これらのチャネルは、コール接続および関連する構成を確立し、コール接続が一度確立されると音声またはデータ情報を搬送する目的で、信号送受情報を搬送するために使用される。

移動網信号送受は、少なくとも２つの重要な態様を有する。第１の態様は、ＭＳとそのネットワークの残りの間での信号送受を伴う。２Ｇ（「２Ｇ」は「第２世代」のために使用される業界用語）とそれ以降の技術の場合、この信号送受は、ＭＳ（ＴＤＭＡまたはＣＤＭＡのような）によって使用されるアクセス方法に関わり、例えば無線チャネルの割り当ておよび認証に関する。第２の態様は、ＭＳＣ、ＢＳＣ、ＶＬＲ、およびＨＬＲ間における信号送受のような、移動網における様々なエンティティ間での信号送受を伴う。この第２の部分は、特に信号送受システムＮｏ．７（「ＳＳ７」）の状況で使用される場合には、移動アプリケーション部分（「ＭＡＰ」）と呼ばれることがある。ＳＳ７は、電話網の要素がそれによってメッセージ形式で情報を交換する、共通チャネル信号送受システムである。

様々な形式の信号送受（並びにデータおよび音声通信）は、様々な基準に従い送受信される。例えば、電子機械工業会（「ＥＩＡ」）および米国電気通信工業会（「ＴＩＡ」）は、ＭＡＰ基準である、ＩＳ−４１のような、多くの米国基準を定義することに役立つ。同様に、ＣＣＩＴＴおよびＩＴＵは、国際ＭＡＰ基準である、ＧＳＭ−ＭＡＰのような、国際基準を定義することに役立つ。これらの基準に関する情報は、関連組織ではよく知られており、その情報も提供している場合があり、文献としては、例えばＢｏｓｓｅ著、「ＳＩＧＮＡＬＩＮＧ ＩＮ ＴＥＬＥＣＯＭＭＵＮＩＣＡＴＩＯＮＳ ＮＥＴＷＯＲＫＳ」（Ｗｉｌｅｙ １９９８年）を参照されたい。

ＭＳ １１４からのコールを提供するには、ユーザは番号をダイヤルし、セルフォンまたは他のＭＳで「送信」を押す。ＭＳ １１４は、ＭＳＣ １１０に要求されるサービスを示すダイヤルされた番号をＢＳ １０７を介して送信する。ＭＳＣ １１０は、要求されたサービスがＭＳ １１４に許可されるか否かを判定するために、関連付けられたＶＬＲ １１６（後述）をチェックする。サービス提供ＭＳＣは、ＰＳＴＮ １２０上でダイヤルしたユーザのローカル交換局にそのコールをルーティングする。ローカル交換局は、呼び出されたユーザ端末をアラートし、サービス提供ＭＳＣ １１０を介してアンサーバック信号がＭＳ １１４にルーティングされて戻され、サービス提供ＭＳＣ １１０はＭＳへのスピーチ経路を完成する。このセットアップが一度完成すると、そのコールを続行することができる。

ＭＳ １１４へのコールを提供するために、（そのコールがＰＳＴＮ １２０から発信されたものと仮定して）ＰＳＴＮユーザはＭＳの関連付けられた電話番号をダイヤルする。少なくとも米国基準に従えば、ＰＳＴＮ １２０は、そのコールをＭＳの家庭用ＭＳＣにルーティングする（ＭＳにサービスを提供するＭＳＣであってもなくてもよい）。ＭＳＣは次いで、ＨＬＲ １１８に、どのＭＳＣがそのＭＳに現在サービスを提供するかを特定するよう問い合わせる。これは、コールが来ることをサービス提供ＭＳＣに通知するようにも動作する。家庭用ＭＳＣは次いで、そのコールをサービス提供ＭＳＣにルーティングする。サービス提供ＭＳＣはＭＳを適切なＢＳを介してページングする。ＭＳは応答し、適切な信号送受リンクがセットアップされる。

通話中、ＢＳ １０７とＭＳ １１４は、例えば信号の状態により必要ならば、チャネルまたはＢＴＳ １０２を変更するよう協働することができる。これらの変更は、「ハンドオフ」として知られており、これらは独自のタイプの周知のメッセージおよび信号送受を伴う。

図２は、ＣＤＭＡ移動網におけるＢＳ １０７とＭＳＣ １１０の間の信号送受およびユーザトラフィックインターフェースをより詳細に示す。ＢＳ １０７は、「Ａ１」インターフェースとして知られる音声およびデータ回路を制御するために、ＳＳ７ベースのインターフェースを使用して信号送受情報を伝達する。「Ａ２」として知られるインターフェースは、ＭＳＣの交換コンポーネント２０４とＢＳ １０７の間のユーザトラフィック（音声信号など）を搬送する。ソースＢＳとＭＳＣの間の回線交換データコール（音声コールとは反対に）に対するユーザトラフィックのための経路を提供するために、「Ａ５」として知られるインターフェースが使用される。Ａ１、Ａ２、Ａ５の１つまたは複数に関する情報は、ＣＤＭＡ Ｉｎｔｅｒｎｅｔｗｏｒｋｉｎｇ−Ｄｅｐｌｏｙｉｎｇ ｔｈｅ Ｏｐｅｎ−Ａ Ｉｎｔｅｒｆａｃｅ、Ｓｕ−Ｌｉｎ Ｌｏｗ、Ｒｏｎ Ｓｃｈｎｅｉｄｅｒ著、Ｐｒｅｎｔｉｃｅ Ｈａｌｌ、２０００年、ＩＳＢＮ ０−１３−０８８９２２−９に記載されていよう。

移動通信プロバイダは、インターネットに対して、「データコール」のような新しいサービスを提供する。これらのサービスの少なくとも一部の場合、ＭＳＣは元来音声コール用に設計されているので、ＭＳＣは費用効果がない。多くのＭＳＣソフトウェアアーキテクチャによって使用される独占権および閉じた設計により、新しいサービスをＭＳＣに統合することは、困難または実現不可能である。すなわち、そのサービスを提供するために必須のソフトウェア論理をＭＳＣ １１０に追加することは容易ではない。そのようなサービスを提供するために、しばしば交換付属物が使用される。例えば、相互作用機能（「ＩＷＦ」）は、インターネットに対するデータコールをルーティングするための付属物である。機能をＭＳＣに統合する方式と幹線側の付属物を追加する方式のどちらの方式も、サービスの提供にＭＳＣを必要とする。ＭＳＣ設計の変更により、または幹線側の付属物を介して新しいサービスを統合することは、ＭＳＣでのネットワーク輻輳を増大させ、費用の掛かるＭＳＣ資源を消費する可能性がある。

データコールは、通常、パケット交換媒体の一例であるインターネットを利用する。パケット交換媒体は次のように動作する。一連のデータが１つのホストからネットワークを介して別のホストに送信されることになる。そのデータシーケンスは、それぞれが制御情報を含んだヘッダを有する、１つまたは複数のパケットにセグメント化され、各パケットはネットワークを介してルーティングされる。一般的なタイプのパケット交換は、配信に関してはほとんどまたは全く保証しないデータグラムサービスである。より高いレベルに一括して論理的に属することのできるパケットは、ネットワークレベルでは相互に関連付けられない。１つのパケットは、送信者から別のパケットがそれ以前に送信される前に、レシーバに到着し、損傷を受けた状態で到着し（その場合は破棄される）、任意に遅らされ（それを破棄させることのできる失効機構があるにも関わらず）、複製され、また失われる可能性がある。

無線トランシーバ技術（例えば、ナノセルシステムで）を使用して、広範囲の地理的エリアに亘って数十メガヘルツの帯域幅に対する信頼あるアクセスを提供する、少なくとも１つの無線インターネットシステムが提供されている。１領域内の数十、数百セルに依存するセルラ無線音声システムとは対照的に、ローカル無線トランシーバシステムは、その領域内の数千、数万ものトランシーバに依存する。このようなシステムでは、各トランシーバは、例えば、従来のセルの対象の約１００分の１である０．０５平方キロメートルを対象とする。無線周波数（ＲＦ）スペクトラムの高い空間再利用は、ローカル無線トランシーバシステムが、従来のセルシステムよりも所与のデータレートでより多くの活動状態にあるデバイスに対応することを可能にする。さらに、ユーザはアクセスポイントにより近くなるので、そのローカル無線トランシーバシステムは低電力伝送に対応する。ローカル無線トランシーバシステムは、デバイスのバッテリに比較的小さいドレインを有して高速で動作する、多数のデバイスをサポートすることができる。

例えば、１０，０００のトランシーバアクセスポイント（セルセンタ）の全市域ローカル無線トランシーバシステムネットワークでは、各ポイントがそのユーザに１−Ｍｂ／ｓの共同スループットを提供する場合、１つのトランシーバ当たり１０台の活動状態にあるデバイスを、それぞれ１００ｋｂ／ｓでサポートすることができ、これは、その市内では１００，０００台の活動状態にあるデバイスに相当する。各デバイスが期間の１０％だけ活動状態にある場合、このようなネットワークは百万台のデバイスをサポートすることができるが、但し、チャネルアクセス、ハンドオフ、および非対称トラフィック（例えば、デバイスからよりもデバイスに対してより多くのビットが流れる）に対するいかなる準備のためのオーバーヘッドによって消費される帯域幅に対してある程度のアカウンティングを行う必要がある場合がある。

各ローカル無線トランシーバシステムのアクセスポイントは、ＩＥＥＥ ８０２．１１のような無線ローカルエリアネットワーク（ＬＡＮ）技術に対するアクセスポイントであるか、これに類似したものであってよい。各アクセスポイントとインターネットの間にリンク（これに加えて、またはこれの代わりに無線リンクを使用してもよい）を提供するために、非対称デジタル加入者線（ＡＤＳＬ）またはケーブルモデム回線を使用することができる。アクセスデバイスの配置に関して、各デバイスが電力を必要とし、好適には適切な無線周波数対象のために高められるので、高速の隣接するインターネットアクセス基盤が根幹としてサービスを提供する、電信柱および建物の場所は典型的が候補となる。

本発明の一態様では、ＩＰネットワーク接続のための資源が管理される。オペレーティングシステムカーネルソフトウェアのプロシージャに、１つのフィールドが追加される。このフィールドは、仮想ルータ・コンテキストを参照する。パケット処理ソフトウェアコードを仮想ルータ・コンテキストに従って実行させるように、パケット処理ソフトウェアコードが修正される。

本発明の実施態様は、次に示す利点の１つまたは複数を提供することができる。同じプロセッサまたはオペレーティングシステムの同じインスタンスで、複数のホストを実施することができる。１つのＩＰアドレスが２つの異なるエンティティとしてサービスを提供するように、その同じＩＰアドレスを２つのコンテキストで使用することができる。設備の一部は、複数の専用ネットワーク間で情報を漏洩せずに複数の専用ネットワークに参加することができる。１つのインターネットプロトコル（ＩＰ）アドレスに対するホスト実施態様は、１つのオペレーティングシステムの別個のインスタンスを実行している、複数の、連結のゆるいプロセッサ全体に広げることができる。１つのＩＰホストに対して、結合した処理パワーを使用することができる。分散型ホストは、複数の動作を１つのホストで実行することを要求する、既存の構成または既存のプロトコルと互換性を有することができる。顧客が顧客の実施態様の全体的な設計を変更する必要がないように、既存の構成と共に分散型ホストを使用することができる。

図面を含めて以下の説明から、また特許請求の範囲から、他の利点および特徴が明らかになろう。

通信システムは、コンピューティング資源の共用または結合に依存する特徴を含めて、通信特徴を提供する。通信システムは、以下で述べるようなインターネットメディアゲートウェイ機構（「ＩＭＧ」）およびＳｏｆｔｓｗｉｔｃｈ機構を有する。図３Ａは、ＢＳＣ ４１５ＡとＭＳＣ ４２０Ａの間に接続されたＩＭＧ ４１０Ａを有し、Ｓｏｆｔｓｗｉｔｃｈ ４２５Ａと通信するシステム４００例を示す。ＩＭＧ ４１０Ａは、Ａ１、Ａ２、およびＡ５インターフェースによってＢＳＣ ４１５Ａと通信する。後述するように、Ｓｏｆｔｓｗｉｔｃｈ ４２５Ａは、ＢＳＣ ４１５ＡとＭＳＣ ４２０Ａの間のＩＭＧ ４１０Ａを介した経路セットアップおよび通信を調整する。ＩＭＧ ４１０Ａはインターネット４３０とも通信し、後述するように、ＩＭＧ ４１０Ａは、インターネット４３０を介してメールサーバ４４０にメッセージを向けることができる。同様に、図３ＡでＩＭＧ ４１０Ｂ、Ｓｏｆｔｓｗｉｔｃｈ ４２５Ｂ、ＢＳＣ ４１５ＢおよびＭＳＣ ４２０Ｂにより例示するように、他のＢＳＣとＭＳＣとの接続に、他のＩＭＧとＳｏｆｔｓｗｉｔｃｈｅを提供することができる。ＭＳＣ ４２０Ａ、４２０Ｂは、ＰＳＴＮ ４６０を介して相互に接続されており、通信することができる。ＳｏｆｔＳｗｉｔｃｈ ４２５Ａ、４２５Ｂは、ＳＳ７システム４７０を介して相互に接続されており、通信することができる。（図３Ｂは、ＩＭＧ ４１０ＡとＢＳＣ ４１５Ａの間にＭＳＣ ４２０Ａが接続され、ＩＭＧ ４１０ＢとＢＳＣ ４１５Ｂの間にＭＳＣ ４２０Ｂが接続されている代替構成４０２を示す。）
図４は、１つまたは複数の移動無線ネットワーク上に音声およびデータサービスを提供することをサポートし、これに役立つことのできるシステム１０１０を示す。この特定の実施態様では、システム１０１０は、時分割多重（ＴＤＭ）データ、非同期転送モード（ＡＴＭ）セルデータ、およびインターネットプロトコル（ＩＰ）パケットデータを含めて複数のデータタイプをサポートすることのできる、通信事業者クラスの高性能なプラットフォームであるＳｔａｒｎｅｔ Ｎｅｔｗｏｒｋｓ社のＳＴ−１６ ＩＭＧ製品を含むことができる。ＳＴ−１６アーキテクチャは、パケット処理にはパケット加速器カード（ＰＡＣ）のような加速器カード（例えば、カード１０２０）を、音声処理にはテレフォニー加速器カード（ＴＡＣ）を使用する。各ＰＡＣはデータ処理を実行することができ、各ＴＡＣは音声処理を実行することができる。ＳＴ−１６では、物理的入出力（Ｉ／Ｏ）インターフェースが業界基準回線カード（例えば、カード１０３０Ａ、１０３０Ｂ）で終端し、様々な物理的インターフェース基準に従ってＴＤＭ、パケットまたはＡＴＭセルデータタイプを搬送することができる。ＴＤＭインターフェースは主として音声トラフィックを搬送するので、ＴＤＭ回線カードはＴＡＣと通信する。イーサネット（登録商標）回線カードはパケットデータトラフィックを搬送し、ＰＡＣと通信することができる。光回線カードは、音声およびデータトラフィックの両方を搬送することのできるＡＴＭセルをサポートし、ＰＡＣまたはＴＡＣと通信することができる。ＳＴ−１６は、いかなるスロットの回線カードでもＳＴ−１６のいかなるスロットの加速器カードと通信することを可能にするために使用される、重複クロスバーカード（ＲＣＣ）（例えば、カード１０４０Ａ、１０４０Ｂ）も有する。

ＳＴ−１６は、回線カードおよびＲＣＣに加速器カードを接続するためのリンクを提供するために、カード対カード通信システム（「ＳＴＡＲＣｈａｎｎｅｌ」）を使用する。一実施態様では、ＳＴＡＲＣｈａｎｎｅｌリンクは、４．０Ｇｂｐｓデータ容量を有し、チャネルロックモードで動作する２つの物理的シリアルリンクを含む。各物理的シリアルリンクは２．５Ｇｂｐｓでクロック制御されており（８Ｂ／１０Ｂ符号化）、２．０Ｇｂｐｓデータを搬送することができる。

ＳＴ−１６では、仮想化および分散型ホストを実施することが望ましい。
仮想化に関しては、複数のホストが同じプロセッサまたはオペレーティングシステムの同じインスタンスで実施される。この場合、可能ならば、後述するように、同じシステムで様々なコンテキストを伴い複数のＩＰアドレスが実施される。ＩＰネットワーク接続に関しては、各コンテキストは、それぞれのコンテキストからはっきりと分離される。したがって、１つのＩＰアドレスが２つの異なるエンティティとしてサービスを提供するように、同じＩＰアドレスを２つの異なるコンテキストで使用することができる。これは、少なくとも、インターネットから分離された専用ネットワークの場合には望ましい。異なる専用ネットワークは同じＩＰアドレスを使用することができるが、専用ネットワークは相互に分離されているので、これら専用ネットワークのそれぞれで同じＩＰアドレスは異なる意味を有する。

複数の専用ネットワーク間で情報を漏洩せずに、その複数の専用ネットワークに設備の一部を参加させることが望ましい場合がある。例えば、設備は、一組の専用ネットワークの各専用ネットワークに対して、それら専用ネットワークを１つのネットワークに統合せずに同時に一組の機能を提供することができる。このコンテキストは、ソフトウェアの一部を１つの物理システム上で実行し、ソフトウェアの他の部分を別の物理システム上で実行するほど容易に、またはそれと同じくらい容易に、ソフトウェアの２つの部分が設備の同じ物理部分で実行されることを可能にし、場合によっては、オペレーティングシステムの同じインスタンスで実行されることを可能にする。

例えば、このコンテキストにより、２つの専用ネットワークにサービスを提供する設備の一部は、両方の専用ネットワークに同じＩＰアドレスを有することができ、メッセージを発行したネットワークがどれかによって入来メッセージに対して異なる反応を示すことができる。

専用ネットワークは、偶発的または意図的に、もしくはアドレスが希少である結果として、１つのＩＰアドレスを共用することができる。後者の場合、インターネット上では、莫大な量のルーティング可能なアドレス空間（インターネット上で直接的に通信するために使用されるアドレス空間）の使用を得ることは困難か、または高価になる場合がある。その結果、ルーティング可能なアドレス空間の大きなブロックの代わりに専用ネットワークを使用する場合がある。内線電話付き社内電話システムが１つの主要な公衆電話番号を何倍にも用いるのと同様に、専用ネットワークは１つのＩＰアドレスを何倍に用いる。ここで、社内電話システムのユーザが公衆電話システムを必ずしも必要とせずに相互通信することができるのと同様に、専用ネットワークのコンピュータは、インターネット自体を必ずしも必要とせずにインターネットプロトコルを使用して相互通信することができる。

仮想化の場合、例えばボイスメールシステムが２つの別個の社内電話システムから同じ電話の内線（例えば、内線１１０）で到達可能なのと同様に、設備の一部は、２つの異なる専用ネットワーク上の同じアドレスで到達可能であってよい。電話の内線でボイスメールシステムに到着した着信コールが、どの社内電話システムがそのコールを発信したかによって異なる方法で扱われるのと同様に、設備の一部での入来通信は、どの専用ネットワークがその通信を送信したかによって異なる方法で扱われる。どちらの場合でも、誤った取り扱いを避けることが肝要であろう。

従来、Ｌｉｎｕｘオペレーティングシステムは、ボイスメールシステムが２つの社内電話システムにサービスを提供するように、２つの専用ネットワークにサービスを提供することはできない。後述するような仮想化により、Ｌｉｎｕｘオペレーティングシステムは、複数の異なる専用ネットワークに参加することができ、専用ネットワークで同じアドレスが使用されている場合でさえ誤った取り扱いを避けることができる。仮想化のために、ＩＰネットワーク接続を扱うオペレーティングシステムカーネル内の多くの、またはすべての場所で、入来データパケットのようなデータを取り扱うために適切なコンテキストを、例えばコンテキスト番号によって示すために、多くの、またはすべての適切なデータ構造に１つの要素が追加される。

特定の実施態様では、その要素は、ルーティングテーブルを含めて、そのカーネル内のすべての関連するデータ構造にコンテキスト番号を保持し、そのシステムによって処理されるすべてのパケットには、パケットがシステムを通過する際に、そのパケットに関連付けられたコンテキストをシステムが追跡するように、コンテキスト番号でタグが付けられる。Ｌｉｎｕｘオペレーティングシステムは、ルーティングテーブルの複数のインスタンスを可能にし、各コンテキストは独自のルーティングテーブルを有し、各ルーティングテーブルはコンテキスト番号に関連付けられる。パケットがシステムに着信したときに、そのパケットが属するコンテキストをシステムが判定することができるように、システムに対する各インターフェースにはコンテキスト番号が関連付けられる。アプリケーションに対するカーネルのインターフェースの一部である各データ構造には、コンテキスト番号が関連付けられる。したがって、アプリケーションが使用中のソケットが属するコンテキストをシステムが特定することができるように、例えば、ネットワーク接続を使用するためにアプリケーションが使用するソケットとして知られる抽象概念にコンテキスト番号が関連付けられる。

その結果、少なくともいくつかの実施態様では、アプリケーションコードにほとんど、または全く修正を加えずにシステムがＬｉｎｕｘまたはいかなるＵｎｉｘ（登録商標）のようなオペレーティングシステムに対してでも一般的に書かれたアプリケーションコードを実行することができるように、システムは、カーネル内のコンテキスト化／仮想化に基づいて、複数のコンテキストで動作するオペレーティングシステムの１つのインスタンスを有することができる。

プロセッサが単一のＩＰホストを実施するように、分散型ホストが、１つのインターネットプロトコル（ＩＰ）アドレスに対するホスト実施態様を、オペレーティングシステムの別個のインスタンスを実行中の、複数の、結合のゆるいプロセッサ全体に広げられるようにする点で、分散型ホストは仮想化と異なる。したがって、結合された処理パワーを１つのＩＰホストに対して使用することができる。これは、１つのプロセッサで使用可能な処理パワーを使用するだけでは実現不可能または不可能な結果を可能にすることができる。

コンピュータシステムを複数のホストとして振舞わせる方式と異なり、分散型ホストは、複数の動作を１つのホスト上で実行することを要求する既存の構成または既存のプロトコルと互換性を有する。例えば、顧客が顧客の実施態様の全体的な設計を変更することを必要としないように、既存の構成と共に分散型ホストを使用することができる。具体的には、少なくともいくつかの実施態様では、分散型ホストシステムは、Ｌｉｎｕｘまたは他のＵｎｉｘ（登録商標）スタイル環境のために書かれたアプリケーションソフトウェアを、そのアプリケーションソフトウェアにほとんどまたは全く修正を加えずに実行することができる。したがって、分散型ホストシステムは、Ｌｉｎｕｘまたは他のＵｎｉｘ（登録商標）タイプのオペレーティングシステム上で実行することが既に可能な既存のソフトウェアを異なった機種で実行させることを含めて、価値が追加され、または拡張された特徴をシステムに組み込むことを可能にする。

特定の実施態様に関して、Ｌｉｎｕｘ ＩＰ実施態様に対する修正は、次の２つの広い範疇に含まれる。
（１）仮想化の場合、複数のオペレーティングシステムインスタンスがあるかのように、個々のオペレーティングシステムインスタンスがＩＰのルータ（転送）とホスト機能の両方をサポートできるようにするための、仮想ルータと仮想ホストに対するサポート、すなわち、空間のオーバーラップが数値である場合であっても、複数の別個のＩＰアドレス空間に対する、別個のようなサポート。

（２）分散型ホストの場合、異なるオペレーティングシステムインスタンスから同じホストの異なる転送制御プロトコル（ＴＣＰ）またはユーザデータグラムプロトコル（ＵＤＰ）ポートにサービスを提供することを可能にするための、分散型ＩＰホストに対するサポート。

従来のＬｉｎｕｘは、仮想化された転送サポートに必須のすべて、またはほとんどすべてである、複数のルーティングテーブルに対するサポートを含む。しかし、従来のＬｉｎｕｘは、仮想化されたホスト機能はサポートしない。具体的には、従来のＬｉｎｕｘは、プロセスまたはソケットがその仮想ルータ・コンテキストを選択する方法も、複数の異なるプロセスが同じアドレス／プロトコル／ポート（異なる仮想ルータ・コンテキストで）をバインドする方法も提供しない。次に示す修正（図５）は、そのようなサポートを追加する。

プロセスのディフォルト仮想ルータ・コンテキストを記憶する、ｐｒｏｃ構造または適切な構造（ｐｒｏｃ構造は、プロセス毎にインスタンス化されたカーネルデータ構造であり、カーネルプロセス状態情報を含む）に、１つのフィールドが追加される（ステップ１０１０）。プロセスのディフォルト仮想ルータ・コンテキストが、その作成時において、その親がｆｏｒｋ（）またはｃｌｏｎｅ（）を使用したときにその親のディフォルト仮想ルータ・コンテキストがどんなものであれ、それになるように、カーネルプロセス作成コードは、フィールドを継続可能にするのに適するように修正される。また、初期システムプロセスｉｎｉｔをセットアップするコードは、起動時に自動作成されたディフォルト仮想ルータ・コンテキストをｉｎｉｔが確実に使用するように修正される。

ソケットの仮想ルータ・コンテキストを示す、インターネットプロトコルファミリー（ＴＣＰ、ＵＤＰおよび未加工ＩＰ）に対する適切なソケット毎のデータ構造に、１つのフィールドが追加される（ステップ１０２０）。作成時に、そのフィールドが、プロセスのためのディフォルト仮想ルータ・コンテキストからポピュレートされるように、ソケット作成コードが修正される。

プロセスのディフォルト仮想ルータ・コンテキストを設定するためのサポート（例えば、ｐｒｏｃｆｓ拡張として）が追加される（ステップ１０３０）。
ソケットの仮想ルータ・コンテキストを設定するためのサポート（例えば、ｓｅｔｓｏｃｋｏｐｔとして）が追加される（ステップ１０４０）。

仮想ルータ・コンテキストを作成、削除するためのサポート（例えば、ｐｒｏｃｆｓまたはｎｅｔｌｉｎｋ拡張として）が追加される（ステップ１０５０）。
インターフェースに仮想ルータ・コンテキストを関連付けるためのサポート（例えば、ｐｒｏｃｆｓまたはｎｅｔｌｉｎｋ拡張として）が追加される（ステップ１０６０）。

ＴＣＰ、ＵＤＰ、未加工ＩＰソケット、およびインターネット制御メッセージプロトコル（ＩＣＭＰ）に対するパケット入来処理コードが、入来パケットが関連付けられたソケットの特定で、パケットの入来インターフェースの仮想ルータ・コンテキストが考慮されるように、修正される（ステップ１０７０）。

ＴＣＰ、ＵＤＰ、および未加工ＩＰソケットに対するパケット出口処理コードが、出口パケットのために使用するルーティングテーブルの選択で、パケットを送信するソケットの仮想ルータ・コンテキストが考慮されるように、修正される（ステップ１０８０）。

分散型ホストの場合、分散型ホスト機能は、異なるオペレーティングシステムインスタンスで実行中のプロセスが、同じホスト（ＩＰアドレス）で異なるソケットをバインドすることを可能にする。少なくとも１つの特定の実施態様では、次に示す方式をとることができる。

特定のプロセッサがそのパケットの消費者になるとネットワークプロセッサ（ＮＰ）サブシステムが判定できる場合の入来パケットの場合、そのパケットはプロセッサに送信される。

特定のプロセッサがそのパケットの消費者になるとＮＰサブシステムが判定できない場合の入来パケットの場合、そのパケットはすべてのプロセッサに送信される（例えば、Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ（ＭＡＣ）ブロードキャストにより）。

プロセッサがそれ自体に向けられたものでない（が、別のプロセッサに向けられたものである可能性がある）と判定するパケットを受信した場合、そのプロセッサはそのパケットを無視し、いかなる方法でもそのパケットに対して応答しようとはしない。

各(分散型)ホストに対して、１つの特定のプロセッサがそのホストのためのリードプロセッサとして設計される。このプロセッサは、全体としてホストに対応し、例えばいくつかの（しかしすべてではない）ＩＣＭＰパケットおよびアドレス分解プロトコル（ＡＲＰ）要求のようないかなる特定の「接続」または「ポート」にも対応しないパケットを処理し、これに応答する義務を有する。

分散型ホストからの出口パケットの処理は、通常のホストの出口パケットに対する処理から基本的に変更されていない。
テストおよびシミュレーション（ＮＰサブシステムなしに）のために、ホストのためのリードプロセッサが他のプロセッサに対してそれ自体を宛先としないパケットを（ＭＡＣブロードキャストによって）転送できるようにするための機能が追加される。ＩＰ技術では、この機能は、従来の転送とは異なり（例えば、ＴＴＬが減分されないので）、ブリッジに近いものである。

分散型ホスト機能を上記のように実施するために、次に示すカーネル変更（図６）が使用される。
特定のインターフェースが分散型ホストに対するリードインターフェースであるか否かを指定できるようにするために、拡張機能（例えば、ｐｒｏｃｆｓまたはｎｅｔｌｉｎｋの拡張機能）が追加される（ステップ２０１０）。

ローカルにバインドされていないポートに到達するパケットに対して一切の応答を避けるように、ＴＣＰおよびＵＤＰ入来コードが修正される（ステップ２０２０）。
ポートがバインドされるか、またはフローがローカルに存在しない限り、特定のポートまたはフローと相関関係のあるいかなるＩＣＭＰパケットに対しても、そのパケットが無視されるように、また、そのホストに対して大域的ないかなるＩＣＭＰパケットに対しても（例えば、エコー要求）、そのホストのリードインターフェースだけがそのパケットを処理するように、ＩＣＭＰ入来コードが修正される（ステップ２０３０）。

非リードインターフェースがＡＲＰ要求に応答しないように、ＡＲＰコードが修正される（ステップ２０４０）。
ＮＰサブシステムなしに動作に対して上記の転送／ブリッジをサポートするために、コードが入来経路に追加される（ステップ２０５０）。

カーネルＩＰ仮想化に関してより具体的には、カーネル内のすべてのＩＰパケットバッファ（ｓｋｂｕｆｆｓ）に状況番号でタグが付けられる。処理中のパケットの状況番号は、２つの機構のうちの１つによって特定される。

（１）ネットワークインターフェースを介してカーネルを入力するパケットには、インターフェースに構成された状況番号でタグが付けられる。ｉｐ＿ｒｃｖ（）（ｎｅｔ／ｉｐｖ４／ｉｐ＿ｉｎｐｕｔ．ｃ）内にある次に示すコードは、ネットワークインターフェースによって導入されたいかなるＩＰパケットに対するバッファにでもタグを付ける。

（２）アプリケーションソケットを介してカーネルを入力するパケットには、それが出力の準備を完了した際にソケットに構成された状況番号でタグが付けられる（ディフォルトで、これはソケットを作成したアプリケーションのディフォルト状況番号である）。関連するソフトウェアコードは、主としてｎｅｔ／ｉｐｖ４／ｉｐ＿ｏｕｔｐｕｔ．ｃにある。ｉｐ＿ｂｕｉｌｄ＿ｘｍｉｔ（）からの一例を次に示す。

上記の表において、ｓｋｂはｓｋｂｕｆｆ構成に対するポインタであり、ｓｋはソケット構成に対するポインタである。さらに、仮想化に対処するためにｖｒ＿ｉｎｄｅｘが両方の構成に付いている。

カーネルがユーザプロセスにパケットを提供することを必要とする場合、そのパケットを提供すべきプロセスを特定する際に、カーネルはそのパケットの状況番号を考慮する。ＴＣＰパケットに関する特定を行うソフトウェアコードからの一例を次に示す。

上記の表は、ｎｅｔ／ｉｐｖ４／ｔｃｐ＿ｉｐｖ４．ｃのｔｃｐ＿ｖ４＿ｒｃｖ（）からのものである。ＣＯＮＦＩＧ＿ＮＥＴ＿ＩＰ＿ＶＩＲＴＵＡＬは、カーネルがＩＰ仮想化サポートによって構築される際に定義される。示すように、仮想化が使用中の場合に＿ｔｃｐ＿ｖ４＿ｌｏｏｋｕｐの引数リストの先頭に追加引数が付加される。さらに、＿ｔｃｐ＿ｖ４＿ｌｏｏｋｕｐ（）は、パケットを消費するソケットの特定を許可し、ハッシュテーブルでの検索を実行する。仮想化が使用中の場合、参照を実行する際のキーの一要素としてパケットの状況番号（ｓｋｂ−＞ｖｒ＿ｉｎｄｅｘ）が使用される。この方法で、例えば、通常ならば同一の特性を有するが（ソースアドレス、ソースポート、宛先アドレス、宛先ポート）異なる状況に属する２つの異なるパケットを、２つの異なるソケットに向けることができる。

カーネルがＩＰフォワーディング検索を実行する場合（例えば、ルータとして動作する場合、またはローカルアプリケーションを発生させたパケットを遠隔の宛先に提供する場合）、その検索もまたパケットの状況を考慮させられる。具体的には、パケット毎に異なるルーティングテーブルが使用される。仮想化のために、多くの、または大部分のルート検索を実行するｆｉｂ＿ｌｏｏｋｕｐ（）（ｎｅｔ／ｉｐｖ４／ｆｉｂ＿ｒｕｌｅｓ．ｃの）に次のコードが付加される。

上記の表において、ｖｒは、ＣＯＮＦＩＧ＿ＮＥＴ＿ＩＰ＿ＶＩＲＴＵＡＬが定義される際に引数リストの先頭に付加されるｆｉｂ＿ｌｏｏｋｕｐに対する付加引数である。ｆｉｂ＿ｇｅｔ＿ｔａｂｌｅ（）に対するコールはルーティングテーブル番号を取り、仮想化に対するサポートはＬｉｎｕｘの複数のルーティングテーブルをサポートするという既存の機能を使用する。状況化が使用中の場合、ルーティングテーブル番号を計算するために状況番号が使用される。ｆｉｂ＿ｌｏｏｋｕｐ（）の残りは、ｆｉｂ＿ｇｅｔ＿ｔａｂｌｅ（）に対するコールによって戻されたルーティングテーブルに作用する。

さらに、提供されたＬｉｎｕｘ上のホスト機能を実施することに関して、以下に示す「クラスタ」は、単一の提供されたホストを実施する一群のシステムの総称である。少なくとも１つの特定の実施態様は、次に示す事項に依存する。

提供されたホストに参加する各カーネルは、それがその提供されたホストの「リーダ」であるか否かを判定し、「リーダ」でない場合は、その提供されたホストの「リーダ」はどのシステムかを特定することができる。提供されたホストの「リーダ」は、その提供されたホスト全体に対して特定のサービスを（例えば、一意に）実行するよう設計されたシステムである。一般に、これは、適切に提供できなかったサービスに対して使用される。この情報は、インターフェースアドレス毎に、例えばｉｎ＿ｉｆａｄｄｒ構成内に維持される。

ポート毎または接続毎に提供されるべきプロトコルの場合（例えば、ＵＤＰおよびＴＣＰ）、提供されたホストを実施する一組のシステムにパケットが到着した際に、その特定のパケットを処理するシステムを正確に特定することができるように、実際のプロトコルが修正される。したがって、一般に、どのポートおよび／または接続がどのシステムで処理されているかを示す項目を有するデータベースが維持される。これは、カーネルとユーザプロセスの間で、ルーティングプロトコルを実施するユーザプロセスによって使用される「ｒｔｎｅｔｌｉｎｋ」インターフェースにある程度類似したインターフェースを実施することによって達成することができる。具体的には、このようなインターフェースは、ユーザプロセスに、他のユーザプロセスによるｂｉｎｄ（）ｐｏｒｔｓおよびａｃｃｅｐｔ（）ｃｏｎｎｅｃｔｉｏｎｓの要求を通知する。このインターフェースを使用するユーザプロセスは、クラスタの中の遠隔ホストにより、または少なくとも提供されたインターフェースのリーダにより、データベースの同期を取ることを担当する。少なくとも大部分の場合において、ｔｃｐ＿ｖ４＿ｒｃｖ（）とｕｄｐ＿ｒｃｖ（）のような機能は、入来パケット毎に、そのパケットが処理されるべきか無視されるべきか、かつ／またはそのクラスタの別のメンバーに送信されるべきかを検索するように修正される。

少なくともいくつかの実施態様において、いくつかのプロトコル（例えば、ＡＲＰ）場合、リーダシステムに対するすべての要求を単純に処理し、非リーダシステムに到達した要求は常に無視するだけで十分である。ＡＲＰの場合、これは、受信中のパケットが、そのローカルシステムをリーダとするアドレスに対応するか否かをチェックするためにａｒｐ＿ｒｃｖ（）を修正することにより達成することができる。リーダである場合、そのパケットは通常通りに処理することができる。非リーダである場合、そのパケットは無視するか、そのクラスタの別のメンバーに送信することができる。

いくつかのプロトコルの場合（例えば、ＩＰのマルチキャストが分散方式でサポートされる場合は、ＩＣＭＰおよび恐らくはＩＧＭＰ）、受信したパケットは分散型ホスト環境において異なる方法で処理される。ＩＣＭＰの場合、分散型ホストを実施するクラスタのすべてのシステムにはエコー要求ではなく各パケットを送信することができ、次いで各システムは、そのパケットに基づいて取る動作があるならば、それを特定することができる。エコー要求がリーダシステムによって処理される。他のＩＣＭＰパケットは、一般に、そのシステムが分散型ホストの一部でないかのような方法で、各システムによって処理される。分散型ホスト環境におけるＩＣＭＰパケットの正確な処理は、特定の実施態様によって異なる。

分散型ホストクラスタ内のシステムによるＩＣＭＰエラーパケットの発信は、分散型ホストの機能が使用中でない場合にどのようにしてそれらが生成されるかに関して修正される。具体的には、リーダシステムによってのみ「ＩＣＭＰ到達不可能」メッセージを生成することができる。特定の実施態様によって、そのクラスタ内の非リーダシステムによって、少なくともいくつかの他のＩＣＭＰメッセージを生成することができる。

他の実施態様は、首記の特許請求の範囲内に含まれる。例えば、上記の１つまたは複数の特徴は、オブジェクトコードまたは実行可能なコードで実施することができる。上記の１つまたは複数の特徴は、入来通信のみ、または送出通信のみ、またはリアルタイム通信のみ、または優先順位の高いかデータレートの高い通信のみ、というように特定の通信のみで使用するよう実施することができる。オペレーティングシステムには、内蔵機能としてこれら特徴の１つまたは複数を提供することができる。

通信システムを示すブロック図である。 通信システムを示すブロック図である。 通信システムを示すブロック図である。 通信システムを示すブロック図である。 通信システムを示すブロック図である。 ＩＰネットワーク接続用の資源を管理する際に使用するための方法を示す流れ図である。 ＩＰネットワーク接続用の資源を管理する際に使用するための方法を示す流れ図である。

Claims (7)

1. １つの分散型ＩＰホストを実装する少なくとも１つのオペレーティングシステムを起動する通信システムにおける、ネットワークプロセッサ・サブシステムを選択的に形成する複数のプロセッサを用いるための方法であって、
   処理すべき入来したパケットを、前記ネットワークプロセッサ・サブシステムにおいておよび前記分散型ＩＰホストの前記少なくとも１つのオペレーティングシステムによって受け取るステップと、
   前記ネットワークプロセッサ・サブシステムにおいて、可能な場合には、前記複数のプロセッサのうちどれを前記入来パケットについてのターゲット・プロセッサにするかを決定するステップと、
   前記複数のプロセッサのうちの１つを前記入来パケットのターゲット・プロセッサにすると決定した場合には、前記入来パケットを、前記ネットワークプロセッサ・サブシステムから前記複数のプロセッサのうちの前記１つに送るステップと、
   前記複数のプロセッサのどれを前記入来パケットのターゲット・プロセッサにするかを決定しない場合には、前記入来パケットを、前記ネットワークプロセッサ・サブシステムから前記複数のプロセッサの各々に送るステップと、
   前記ネットワークプロセッサ・サブシステムにおいて、前記複数のプロセッサのうちの１つを、前記分散型ＩＰホストのリード・プロセッサとして指定するステップであって、該リード・プロセッサが、前記分散型ＩＰホスト全体に対応付けられるような入来パケットを処理するステップと、
   を備える方法。
2. 請求項１に記載の方法において、前記入来パケットを前記複数のプロセッサの各々に送る場合には、メディア・アクセス制御（ＭＡＣ）ブロードキャストが使用される、方法。
3. 拡張機能を追加するステップであって、該拡張機能は、前記分散型ＩＰホストを実装する前記少なくとも１つのオペレーティングシステムにおいて、前記分散型ＩＰホストの特定のオペレーティングシステム・カーネル・インターフェースが前記分散型ＩＰホストについてのリード・オペレーティングシステム・カーネル・インターフェースであるかを指定するために使用される、ステップを更に備える、請求項１に記載の方法。
4. 前記拡張機能は、ｐｒｏｃｆｓの拡張機能及びｎｅｔｌｉｎｋの拡張機能のうちの１つである請求項３に記載の方法。
5. 請求項３に記載の方法であって、さらに、前記分散型ＩＰホストの非リード・インターフェースがアドレス解決プロトコル（ＡＲＰ）リクエストに応答しないように、アドレス解決プロトコル（ＡＲＰ）のコードを修正するステップを含む、方法。
6. 請求項１に記載の方法において、前記入来パケットが、前記分散型ＩＰホストの前記少なくとも１つのオペレーティングシステムによってローカルにバインドされていないポート番号に対するものである場合には、伝送制御プロトコル（ＴＣＰ）コードおよびユーザ・データグラム・プロトコル（ＵＤＰ）コードのうちの少なくとも１つは、前記入来パケットが無視されるように修正される、方法。
7. 請求項１に記載の方法であって、さらに、前記入来パケットが、前記分散型ＩＰホスト全体に対応付けられているようなインターネット制御メッセージング・プロトコル（ＩＣＭＰ）パケットである場合には、前記特定のポート番号が前記分散型ＩＰホストの前記少なくとも１つのオペレーティングシステムによってバインドされていなければ、ＩＣＭＰパケットが前記分散型ＩＰホストによって無視されるように、インターネット制御メッセージング・プロトコル（ＩＣＭＰ）コードを修正するステップを備える、方法。

Images