JP4637562B2

JP4637562B2 - パッシブネットワークとアクティブネットワークの結合のためのゲートウェイ

Info

Publication number: JP4637562B2
Application number: JP2004370526A
Authority: JP
Inventors: オリビエ・マルス
Original assignee: アルカテル−ルーセント
Priority date: 2004-01-05
Filing date: 2004-12-22
Publication date: 2011-02-23
Anticipated expiration: 2024-12-22
Also published as: DE602004009397T2; DE602004009397D1; US20050147109A1; EP1551142B1; ES2293174T3; ATE375662T1; EP1551142A1; JP2005198278A

Description

本発明は通信ネットワークの分野に関し、特に、限定なしに、インターネットプロトコル（ＩＰ）ネットワークに関する。

パッシブネットワークでは、データパケットの送信は、リソース予約プロトコル（ＲＳＶＰ）などのプロトコルを用いて制御される。ＲＳＶＰは、統合サービスインターネット向けに設計されたリソース予約セットアッププロトコルである。ＲＳＶＰプロトコルはホストによって、特定のサービスの品質をネットワークから、特定のアプリケーションデータストリームまたはフローのために要求するために使用される。

ＲＳＶＰはまたルータによっても、サービス品質（ＱｏＳ）要求をフローのパスに沿ったすべてのノードに配信するため、および、要求されたサービスを提供するために維持された状態を確立するために使用される。ＲＳＶＰ要求は一般に、リソースがデータパスに沿った各ノード内で予約される結果となる。

ＲＳＶＰはシンプレックスのフローのためのリソースを要求し、すなわち、単方向のみでリソースを要求する。したがって、ＲＳＶＰは、同じアプリケーションプロセスが同時に送信側および受信側としての機能を果たす可能性があるとしても、送信側を受信側とは論理的に別個であるとして扱う。ＲＳＶＰはＩＰｖ４またはＩＰｖ６の上で動作し、プロトコルスタック内のトランスポートプロトコルの場所を占有する。しかし、ＲＳＶＰはアプリケーションデータをトランスポートせず、むしろ、ＩＣＭＰ、ＩＧＭＰのようなインターネット制御プロトコル、またはルーティングプロトコルである。ルーティングおよび管理プロトコルの実装と同様に、図１のように、ＲＳＶＰの実装は典型的には、データ転送パス内ではなく、バックグラウンドで実行するようになる。

サービスの品質は特定のデータフローのために、集合的に「トラフィック制御」と呼ばれるメカニズムによって実装される。これらのメカニズムには、パケット分類器１、アドミッション制御２および「パケットスケジューラ」３、または、特定のパケットがいつ転送されるかを決定するためのある他のリンク層依存メカニズムが含まれる。「パケット分類器」はＱｏＳクラス（および場合によってはルート）を各パケットについて決定する。各発信インタフェースについて、「パケットスケジューラ」または他のリンク層依存メカニズムは、約束されたＱｏＳを達成する。トラフィック制御は、統合サービスワーキンググループによって定義されたＱｏＳサービスモデルを実装する。

予約セットアップ中に、ＲＳＶＰＱｏＳ要求は２つのローカル判断モジュールであるアドミッション制御２およびポリシー制御４に渡される。アドミッション制御２は、ノードが要求されたＱｏＳを供給するために十分に使用可能なリソースを有するかどうかを決定する。ポリシー制御４は、ユーザが予約を行うための管理許可を有するかどうかを決定する。両方のチェックが成功する場合、所望のＱｏＳを得るために、パラメータがパケット分類器１内およびリンク層インタフェース内（例えば、パケットスケジューラ３内）で設定される。いずれかのチェックが失敗する場合、ＲＳＶＰプログラム５はエラー通知を、その要求を発信したアプリケーションプロセスに戻す。

ＲＳＶＰプロトコルメカニズムは、マルチキャストまたはユニキャスト配信パスのメッシュの全体で分散予約状態を作成および維持するための汎用機能を提供する。ＲＳＶＰ自体はＱｏＳおよびポリシー制御パラメータを不透明データとして転送および操作し、これらを適切なトラフィック制御およびポリシー制御モジュールへ、解釈のために渡す。ＱｏＳパラメータの構造および内容は、統合サービスワーキンググループによって開発された仕様において文書化されている。

ＲＳＶＰの詳細はリソース予約プロトコル仕様において開示されており、この仕様はｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２２０５．ｔｘｔから入手可能であり、全体として参照により本明細書に組み込まれる。

最近、いわゆるアクティブネットワークが開発されている。（「Ａｍａｎａｇｅｍｅｎｔａｒｃｈｉｔｅｃｔｕｒｅｆｏｒａｃｔｉｖｅｎｅｔｗｏｒｋｓ」、ＡｃｔｉｖｅＭｉｄｄｌｅｗａｒｅＳｅｒｖｉｃｅｓ、２００２年．Ｐｒｏｃｅｅｄｉｎｇｓ．ＦｏｕｒｔｈＡｎｎｕａｌＩｎｔｅｒｎａｔｉｏｎａｌＷｏｒｋｓｈｏｐ、Ｂａｒｏｎｅ、Ａ．、Ｃｈｉｒｃｏ、Ｐ．、ＤｉＦａｔｔａ、Ｇ．、４１〜４８頁、「Ａｃｔｉｖｅｎｅｔｗｏｒｋｉｍｐｌｅｍｅｎｔａｔｉｏｎｓ」、ＲｅｓｅａｒｃｈａｎｄＤｅｖｅｌｏｐｍｅｎｔ、２００２年．ＳＣＯＲｅＤ２００２．Ｈａｓｈｉｍ、Ｈ.、Ｍａｎａｎ、Ｊ．Ａ．、Ｓａｍａｄ、Ｍ．３７１〜３７４頁、「ＴｏｗａｒｄｓａｎＡｃｔｉｖｅＮｅｔｗｏｒｋＡｒｃｈｉｔｅｃｔｕｒｅ」、Ｄ．Ｌ．ＴｅｎｎｅｎｈｏｕｓｅおよびＤ．Ｊ．Ｗｅｔｈｅｒａｌｌ、ＣｏｍｐｕｔｅｒＣｏｍｍｕｎｉｃａｔｉｏｎＲｅｖｉｅｗ、Ｖｏｌ．２６、Ｎｏ．２，１９９６年４月、「ＡＳｕｒｖｅｙｏｆＡｃｔｉｖｅＮｅｔｗｏｒｋＲｅｓｅａｒｃｈ」、ＤａｖｉｄＬ．Ｔｅｎｎｅｎｈｏｕｓｅ、ＪｏｎａｔｈａｎＭ．Ｓｍｉｔｈ、Ｗ．ＤａｖｉｄＳｉｎｃｏｓｋｉｅ、ＤａｖｉｄＪ．Ｗｅｔｈｅｒａｌｌ、ＧａｒｙＪ．Ｍｉｎｄｅｎ、ＩＥＥＥＣｏｍｍｕｎｉｃａｔｉｏｎｓＭａｇａｚｉｎｅ１９９７年、「ＳｕｒｖｅｙｏｆＡｃｔｉｖｅＮｅｔｗｏｒｋＲｅｓｅａｒｃｈ」、ＤｒａｇｏｓＮｉｃｕｌｅｓｃｕ、１９９９年７月１４日、ｈｔｔｐ：／／ｐａｕｌ．ｒｕｔｇｅｒｓ．ｅｄｕ／〜ｄｎｉｃｕｌｅｓ／ｒｅｓｅａｒｃｈ／ｏｔｈｅｒ／ａｃｔｉｖｅ＿ｓｕｒｖｅｙ．ｐｄｆ）。

図２は、アクティブネットワークノードの一般的なアーキテクチャおよび主なコンポーネントを示す。各アクティブノードは、ノードオペレーティングシステム（ノードＯＳ）および１つまたは複数の実行環境（ＥＥ）を実行する。ノードＯＳは、ＥＥと下にある物理的リソースの間で動作する層であり、伝送帯域幅、プロセッササイクルおよびストレージを含む。ノードＯＳは、ＥＥをリソース管理の詳細および他のＥＥの存在から独立させながら、ＥＥにノードリソースへのアクセスを提供する。ノードＯＳに対して行われたすべての要求は、ユーザを含むネットワーク内の他のエンティティを表すプリンシパルに代わって行われる。要求は、ノードＯＳが、ＥＥがパケットを送信および受信できるようにするために実装する、通信チャネルの全体で行われる。

ネットワーク内のセキュリティを維持するために、ノードＯＳはまた、セキュリティポリシーデータベースおよび施行エンジンをも実装する。ノードＯＳはセキュリティ施行エンジンに依存して、プリンシパルが、要求されたサービスを受信することまたは要求されたオペレーションを実行することを許可される前に、要求を認証および許可する。

各ＥＥは、ノードに到着するアクティブパケットを解釈する仮想計算機を実装する。したがって、ＥＥは、それを通じてエンドツーエンドのネットワークサービスがアクセスされることが可能であるインタフェースを提供する。図２は、多数のＥＥが単一のアクティブノードによってどのようにサポートされることが可能であるかを示す。ＥＥは、ユーザによって提供されたパラメータを通じてステートレスに制御されることが可能である単純なサービスを提供することができ、あるいは、強力でステートフルなプログラミング言語、または中間における何かのためのインタプリタを実装することができる。

ユーザはサービスをアクティブネットワークから、ＥＥ内に存在するプログラミングインタフェースをプログラムするアクティブアプリケーション（ＡＡ）を介して得て、エンドツーエンドサービスを提供するサービスを得る。したがって、エンドユーザアプリケーション向けにカスタマイズされたサービスを実装するのは、ＡＡである。ＡＡを構成するコードは、ネットワークの関連ノードに、コードを搬送するパケットによってインバンドでロードされることが可能であり、あるいはこのコードはアウトオブバンドでインストールされることが可能である。

基本オペレーションモデルでは、パケットはアクティブノードに到着し、ノードＯＳはこれらのパケットを、それらのヘッダの内容に従って分類するように進む。次いでパケットは適切な論理チャネル上に配置され、各々は、セキュリティチェックを含む可能性のある、あるプロトコル処理に関連付けられる。各チャネルはパケットを、出力リンクに転送される前に処理するためにＥＥへ、あるいは、直接出力リンクへ配信する。

これまで、アクティブネットワークの使用は、レガシーパッシブネットワークとの相互運用性の欠如により限られている。したがって、パッシブおよびアクティブネットワークの結合のための方法および装置の必要性がある。
ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２２０５．ｔｘｔ「Ａｍａｎａｇｅｍｅｎｔａｒｃｈｉｔｅｃｔｕｒｅｆｏｒａｃｔｉｖｅｎｅｔｗｏｒｋｓ」、ＡｃｔｉｖｅＭｉｄｄｌｅｗａｒｅＳｅｒｖｉｃｅｓ、２００２年．Ｐｒｏｃｅｅｄｉｎｇｓ．ＦｏｕｒｔｈＡｎｎｕａｌＩｎｔｅｒｎａｔｉｏｎａｌＷｏｒｋｓｈｏｐ、Ｂａｒｏｎｅ、Ａ．、Ｃｈｉｒｃｏ、Ｐ．、ＤｉＦａｔｔａ、Ｇ．、４１〜４８頁「Ａｃｔｉｖｅｎｅｔｗｏｒｋｉｍｐｌｅｍｅｎｔａｔｉｏｎｓ」、ＲｅｓｅａｒｃｈａｎｄＤｅｖｅｌｏｐｍｅｎｔ、２００２年．ＳＣＯＲｅＤ２００２．Ｈａｓｈｉｍ、Ｈ.、Ｍａｎａｎ、Ｊ．Ａ．、Ｓａｍａｄ、Ｍ．３７１〜３７４頁「ＴｏｗａｒｄｓａｎＡｃｔｉｖｅＮｅｔｗｏｒｋＡｒｃｈｉｔｅｃｔｕｒｅ」、Ｄ．Ｌ．ＴｅｎｎｅｎｈｏｕｓｅおよびＤ．Ｊ．Ｗｅｔｈｅｒａｌｌ、ＣｏｍｐｕｔｅｒＣｏｍｍｕｎｉｃａｔｉｏｎＲｅｖｉｅｗ、Ｖｏｌ．２６、Ｎｏ．２，１９９６年４月「ＡＳｕｒｖｅｙｏｆＡｃｔｉｖｅＮｅｔｗｏｒｋＲｅｓｅａｒｃｈ」、ＤａｖｉｄＬ．Ｔｅｎｎｅｎｈｏｕｓｅ、ＪｏｎａｔｈａｎＭ．Ｓｍｉｔｈ、Ｗ．ＤａｖｉｄＳｉｎｃｏｓｋｉｅ、ＤａｖｉｄＪ．Ｗｅｔｈｅｒａｌｌ、ＧａｒｙＪ．Ｍｉｎｄｅｎ、ＩＥＥＥＣｏｍｍｕｎｉｃａｔｉｏｎｓＭａｇａｚｉｎｅ１９９７年「ＳｕｒｖｅｙｏｆＡｃｔｉｖｅＮｅｔｗｏｒｋＲｅｓｅａｒｃｈ」、ＤｒａｇｏｓＮｉｃｕｌｅｓｃｕ、１９９９年７月１４日、ｈｔｔｐ：／／ｐａｕｌ．ｒｕｔｇｅｒｓ．ｅｄｕ／〜ｄｎｉｃｕｌｅｓ／ｒｅｓｅａｒｃｈ／ｏｔｈｅｒ／ａｃｔｉｖｅ＿ｓｕｒｖｅｙ．ｐｄｆ

本発明は、パッシブおよびアクティブネットワークの結合のためのゲートウェイを提供する。

ゲートウェイは、プロトコルメッセージをパッシブネットワークから、および、アクティブパケットをアクティブネットワークから受信することができる。ゲートウェイは、受信されたパッシブネットワークプロトコルメッセージを同等のアクティブパケットに、アクティブネットワークを介した送信のために変換する。さらに、ゲートウェイは、受信されたアクティブパケットを同等のプロトコルメッセージに、パッシブネットワークを介した送信のために変換する。

本発明は、アクティブおよびパッシブネットワークを結合できるようにするので、特に有利である。このように、レガシーパッシブネットワークをアクティブネットワークと共に使用することができ、これによりアクティブネットワークの導入が大いに容易になる。特に、パッシブおよびアクティブネットワークの間の相互運用性は、既存のパッシブネットワークへの企業の投資を保護し、アクティブサブネットワークを段階的なプロセスで追加することを可能にする。

本発明の好ましい実施態様によれば、ゲートウェイによって結合されるパッシブおよびアクティブネットワークは、インターネットプロトコル（ＩＰ）タイプのネットワークである。好ましくは、ＲＳＶＰプロトコルはパッシブネットワークによって使用される。アクティブネットワークは、これまで考慮されてきたアクティブネットワークアーキテクチャ手法のいずれをも実装することができる。

本発明のさらに好ましい実施形態によれば、ゲートウェイは変換リポジトリに結合される。変換リポジトリは、パッシブネットワークプロトコルメッセージを同等のアクティブパケットに変換するため、およびその逆の変換のためのルックアップテーブルを有する。

もう１つの態様では、本発明は、異なるタイプのアクティブネットワークの結合に関する。このために、ゲートウェイによってアクティブネットワークの１つから受信されたアクティブパケットは、他のアクティブネットワークのノードによって実行可能であるコードを有する同等のアクティブパケットに変換される。このように、様々なタイプのアクティブネットワークの統合が実施されることが可能である。

さらにもう１つの態様では、本発明は、様々なタイプのアクティブおよびパッシブネットワークの結合に関する。ソースネットワーク（すなわち、パッシブまたはアクティブネットワーク）から受信されるデータパケットは、宛先ネットワーク（すなわち、パッシブまたはアクティブネットワーク）のための同等のデータパケットに変換される。

ソースネットワークからの着信データパケットと、宛先ネットワークへの発信データパケットの間の１対１関係は、必須ではないことに留意されたい。むしろ、ｍ対ｎ関係が存在する可能性があり、すなわち、ｍ個の数の着信データパケットがｎ個の数の発信データパケットに変換され、ここでｍおよびｎは、着信データパケットの宛先変換へのソースのために必要とされた変換の種類によって決まる。

以下で、本発明の好ましい実施形態がより詳細に、例としてのみ図面を参照することによって説明される。

図３はアクティブネットワーク１００を示し、これはパッシブネットワーク１０２に、ゲートウェイ１０４を用いて結合される。例えば、パッシブネットワーク１０２はＲＳＶＰプロトコル（図１を参照）を使用し、アクティブネットワーク１００は、図２のようなアーキテクチャに対応するネットワークノードを有する。好ましくは、アクティブネットワーク１００およびパッシブネットワーク１０２はＩＰネットワークである。

ゲートウェイ１０４はプロセッサ１０６を、コンピュータプログラム１０８の実行のために有する。プログラム１０８は、パッシブネットワーク１０２のプロトコルメッセージを、アクティブネットワーク１００のアクティブネットワークノードによって処理されることが可能である同等のアクティブパケットに変換するための、命令を有する。さらに、プログラム１０８は、アクティブパケットを、パッシブネットワーク１０２のレガシーノードによって処理されることが可能である同等のプロトコルメッセージに変換するための、命令を有する。

オペレーションにおいて、ゲートウェイ１０４はプロトコルメッセージ１１０をパッシブネットワーク１０２から受信する。これは、プロトコルメッセージ１１０を同等のアクティブパケット１１２に変換するプログラム１０８を呼び出す。プログラム１０８はプロトコルメッセージ１１０に対応する実行可能コードを決定し、この実行可能コードをアクティブネットワーク１００のアクティブネットワークノードによる実行のために搬送する、同等のアクティブパケット１１２を生成する。

同様に、ゲートウェイ１０４は、アクティブパケット１１４をアクティブネットワーク１００から受信するとき、アクティブパケット１１４内に含まれた実行可能コードを、パッシブネットワーク１０２のレガシーノードによって処理されることが可能である同等のプロトコルメッセージ１１６に変換する。

図４は、もう１つの実施形態を示す。図４の実施形態の要素のうち図３の要素に対応するものは、同じ参照番号によって指定される。

図４で考察される実施形態では、ゲートウェイ１０４は変換リポジトリ１１８に結合される。変換リポジトリ１１８は、ルックアップテーブル１２０および１２２を有する。ルックアップテーブル１２０は、同等のアクティブパケットの生成のために所与のプロトコルメッセージに最良に対応する、実行可能コードをルックアップする役目を果たす。同様に、ルックアップテーブル１２２は、アクティブパケットを用いて受信された所与の実行可能コードに最良に対応する、同等のプロトコルメッセージを含む。

ゲートウェイ１０４は、プロトコルメッセージ１１０を受信するとき、受信されたプロトコルメッセージ１１０に最良に対応する同等の実行可能コードを決定するために、変換リポジトリ１１８、すなわちルックアップテーブル１２０に問い合わせる。これに基づいて、プログラム１０８は同等のアクティブパケット１１２を生成する。

同様に、ゲートウェイ１０４は、アクティブパケット１１４を受信するとき、アクティブパケット１１４を用いて受信された実行可能コードに最良に対応する同等のプロトコルメッセージを決定するために、変換リポジトリ１１８、すなわちルックアップテーブル１２２に問い合わせる。プログラム１０８はこれに基づいて、同等のプロトコルメッセージ１１６を生成する。

別法として、ゲートウェイ１０４を、データパケットのアクティブネットワーク変換にアクティブにするために使用することができる。この場合、パッシブネットワーク１０２は第１のタイプのアクティブネットワークによって置き換えられる。アクティブネットワーク１００は、第１のタイプとは異なる第２のタイプを有し、すなわち、第１のタイプのデータパケットのコードは、アクティブネットワーク１００のノードによって実行されることが可能ではなく、その逆もまた同様である。第１のアクティブネットワークから受信された着信データパケットは、ゲートウェイによって同等の発信データパケットに、第２のアクティブネットワークを介した送信のために変換される。このために、変換リポジトリ１１８は対応するルックアップテーブルを、すなわち、第１のネットワークタイプの実行可能コードを第２のネットワークタイプの実行可能コードに変換するために、有する。

図５は、ゲートウェイ１０４によって実行される、アクティブおよびパッシブネットワークの結合のための方法を例示する。プロセス２００は、レガシープロトコルメッセージを、アクティブネットワークを介して送信するための役目を果たすのに対して、プロセス２０２は、アクティブパケットを、レガシーパッシブネットワークを介して送信するための役目を果たす。

プロセス２００はステップ２１０、２１２および２１４を有し、これらのステップは、プロトコルメッセージが受信される（ステップ２１０）たびに実行される。ステップ２１２で、ステップ２１０で受信されたプロトコルメッセージに対応し、アクティブネットワークのノードによって実行されることが可能である、同等の実行可能コードが決定される。これに基づいて、同等のアクティブパケットが生成され、ステップ２１４でアクティブネットワークに転送される。

プロセス２０２は、ステップ２２０、２２２および２２４を有する。これらのステップの実行は、アクティブパケットがゲートウェイによって受信される（ステップ２２０）たびにトリガーされる。ステップ２２２で、アクティブパケットに含まれた実行可能コードに最良に対応する同等のプロトコルメッセージが決定され、同等のプロトコルメッセージがこれに基づいて生成される。ステップ２２４で、同等のプロトコルメッセージがパッシブネットワークに転送される。

従来技術のＲＳＶＰアーキテクチャのブロック図である。従来技術のアクティブネットワークノードのブロック図である。本発明のゲートウェイの第１の実施形態のブロック図である。本発明のゲートウェイの第２の好ましい実施形態の図である。ゲートウェイによって実行される方法を例示する流れ図である。

符号の説明

１００アクティブネットワーク
１０２パッシブネットワーク
１０４ゲートウェイ
１０６プロセッサ
１０８プログラム
１１０プロトコルメッセージ
１１２同等のアクティブパケット
１１４アクティブパケット
１１６同等のプロトコルメッセージ
１１８変換リポジトリ
１２０、１２２ルックアップテーブル

Claims

パッシブネットワークとアクティブネットワークの結合のためのゲートウェイであって、
プロトコルメッセージ（１１０）をパッシブネットワーク（１０２）から受信するための手段（１０６、１０８）と、
アクティブパケット（１１４）をアクティブネットワーク（１００）から受信するための手段（１０６、１０８）と、
前記プロトコルメッセージ（１１０）を同等のアクティブパケット（１１２）に変換するための手段（１０６、１０８）と、
前記アクティブパケットを同等のプロトコルメッセージ（１１６）に変換するための手段（１０６、１０８）と、
前記同等のアクティブパケットをアクティブネットワークに転送するための手段（１０６、１０８）と、
前記同等のプロトコルメッセージをパッシブネットワークに転送するための手段（１０６、１０８）とを備え、さらに、
変換リポジトリ（１１８）を備え、前記変換リポジトリは、前記アクティブパケットを同等のプロトコルメッセージ（１１６）に変換するための手段（１０６、１０８）が前記アクティブパケットを前記同等のプロトコルメッセージに変換するために使用するルックアップテーブル（１２２）、および、前記プロトコルメッセージ（１１０）を同等のアクティブパケット（１１２）に変換するための手段（１０６、１０８）が前記プロトコルメッセージを前記同等のアクティブパケットに変換するために使用するルックアップテーブル（１２０）を備えるゲートウェイ。
前記プロトコルメッセージはＲＳＶＰメッセージである請求項１に記載のゲートウェイ。
アクティブネットワークおよびパッシブネットワークはＩＰネットワークである請求項１に記載のゲートウェイ。
少なくとも１つのパッシブネットワーク、少なくとも１つのアクティブネットワーク、および、少なくとも１つのアクティブおよびパッシブネットワークの結合のための少なくとも１つのゲートウェイを備えるネットワークであって、ゲートウェイが、
プロトコルメッセージ（１１０）をパッシブネットワーク（１０２）から受信するための手段（１０６、１０８）と、
アクティブパケット（１１４）をアクティブネットワーク（１００）から受信するための手段（１０６、１０８）と、
前記プロトコルメッセージ（１１０）を同等のアクティブパケット（１１２）に変換するための手段（１０６、１０８）と、
前記アクティブパケットを同等のプロトコルメッセージ（１１６）に変換するための手段（１０６、１０８）と、
前記同等のアクティブパケットをアクティブネットワークに転送するための手段（１０６、１０８）と、
前記同等のプロトコルメッセージをパッシブネットワークに転送するための手段（１０６、１０８）とを備え、
前記ゲートウェイが、さらに、
変換リポジトリ（１１８）を備え、前記変換リポジトリは、前記アクティブパケットを同等のプロトコルメッセージ（１１６）に変換するための手段（１０６、１０８）が前記アクティブパケットを前記同等のプロトコルメッセージに変換するために使用するルックアップテーブル（１２２）、および、前記プロトコルメッセージ（１１０）を同等のアクティブパケット（１１２）に変換するための手段（１０６、１０８）が前記プロトコルメッセージを前記同等のアクティブパケットに変換するために使用するルックアップテーブル（１２０）を備える、ネットワーク。
パッシブネットワークプロトコルメッセージを、アクティブネットワークを介して送信するための方法であって、
前記パッシブネットワークプロトコルメッセージを、アクティブネットワークのゲートウェイによって受信するステップと、
ルックアップテーブル（１２０、１２２）により、前記パッシブネットワークプロトコルメッセージを同等のアクティブパケットに変換するステップと、
前記同等のアクティブパケットを、アクティブネットワークを介して送信するステップとを備える方法。
アクティブパケットを、パッシブネットワークを介して送信するための方法であって、
前記アクティブパケットを、パッシブネットワークのゲートウェイによって受信するステップと、
ルックアップテーブル（１２０、１２２）により、前記アクティブパケットを同等のパッシブネットワークプロトコルメッセージに変換するステップと、
前記同等のパッシブネットワークプロトコルメッセージを、パッシブネットワークを介して送信するステップとを備える方法。
ゲートウェイに、ルックアップテーブル（１２０、１２２）により、パッシブネットワークプロトコルメッセージを同等のアクティブパケットに変換するステップと、アクティブパケットを同等のパッシブネットワークプロトコルメッセージに変換するステップを実行させる、コンピュータプログラム。
第１のアクティブネットワークと第２のアクティブネットワークの結合のためのゲートウェイであって、
第１のアクティブネットワークからの着信データパケットを受信するための手段（１０６、１０８）と、
前記着信データパケット（１１０）を同等の発信データパケットに、第２のアクティブネットワークを介した送信のために変換するための手段（１０６、１０８、１１８、１２０、１２２）とを備え、
前記変換するための手段は、前記着信データパケット（１１０）を前記同等の発信データパケットに変換するためのルックアップテーブル（１２０、１２２）を備えるゲートウェイ。