JP2006074769A - ネットワークのポートマッピング用システム - Google Patents

Abstract

【課題】 アプリケーションによって指定されたターゲットサービスポートを、トランスペアレント通信に対応するサービスポートへマッピングする。
【解決手段】 エンドノード内のサービスポートの１つは、アプリケーショントランスペアレント通信プロトコルに対応するデバイスを含む。動作時に、アプリケーションによって開始されて、ターゲットサービスポートおよびこれからアクセス可能なターゲットサービスを指定するポートマッピング要求が、エンドノードの１つにより受信される。ターゲットサービスが実行されるエンドノードの特徴を記述した１組の入力パラメータがアクセスされる。エンドノードの特徴に基づき、ターゲットサービスへのアクセスに使用可能な上記デバイスを示す出力データが提供され、ターゲットサービスポートの上記デバイスに関連したサービスポートへのマッピングが可能になる。
【選択図】図２

Description

本発明は、ネットワークのポートマッピング用システムに関する。

通信ネットワークのポートマッピングは、アプリケーションが指定したターゲットサービスポートを、そのアプリケーションにトランスペアレントなプロトコルを使用してアドレス指定できる関連したサービスポートへ変換することとして定義することができる。
リモートアプリケーションと通信したいローカルアプリケーションは、リモートアプリケーションをアドレス指定する方法を知る必要があり、また、リモートアプリケーションが実行されているシステムのネットワークアドレス（例えば、ＩＰアドレス）も知る必要がある。
これは、サービスポート、すなわち、リモートシステムで実行されているアプリケーションを一意に特定するＮビット識別子（ＴＣＰ等の下位レベルプロトコルは１６ビット数を使用する）を指定することによって行われる。

サービスポートは、ネットワークにおいて接続を確立する目的でアプリケーション（例えば、ソケットアプリケーション）によって使用されるリスンポートである。
ソケットインターフェースは、通常、ＴＣＰ／ＩＰネットワーキングサービスにアクセスして、他のホストで実行されているプロセスへの接続を作成するのに使用されるデファクトＡＰＩ（アプリケーションプログラミングインターフェース）である。
ソケットＡＰＩによって、アプリケーションは、ホストのポートおよびＩＰアドレスとバインドすることが可能になる。

しかしながら、ポートアドレス空間は、一般に、ＩＰアドレス当たり１６ビットに限られており、ＲＤＭＡ（リモートダイレクトメモリアクセス）を使用するネットワークプロトコルの場合、ソケットアプリケーションの「リスン」オペレーションは、２つのリスンポートを必要とする。
１つはＲＤＭＡ対応でないクライアント用の非ＲＤＭＡポートであり、１つはＲＤＭＡ対応のＲＤＭＡポートである。
したがって、ＲＤＭＡをベースとしたプロトコルを使用すると、非ＲＤＭＡリスンポートおよびＲＤＭＡリスンポートを複製することが必要となるために、限られたポート空間が消費される（したがって、有効なポート空間が縮小される）おそれがある。
上述したタイプのシステムに関係したさらに別の問題には、アプリケーションが適切なＲＤＭＡポートを発見することを可能にするポートマッピングメカニズムが必要になることが含まれ、また、ポートマッパサービスロケーションを決定する必要があること、すなわち、ポートマッピングワイヤプロトコル交換を実行するターゲットへのポートを決定する必要があることも含まれる。

複数のエンドノードを含むネットワークにおいて、アプリケーションによって指定されたターゲットサービスポートを、アプリケーショントランスペアレント通信に対応する、機能強化されたサービスポートへマッピングするシステムおよび方法が開示される。
エンドノード内のサービスポートの少なくとも１つは、アプリケーショントランスペアレント通信プロトコルに対応するトランスペアレントプロトコル対応のデバイスを含む。

動作時に、アプリケーションによって開始されて、ターゲットサービスポートおよび当該ポートからアクセス可能なターゲットサービスを指定するポートマッピング要求が、エンドノードの１つにおいて受信される。
次に、ターゲットサービスが実行されるエンドノードの特徴を記述した１組の入力パラメータがアクセスされる。
次に、エンドノードの特徴に基づいた、ターゲットサービスにアクセスするのに使用できるトランスペアレントプロトコル対応のデバイスを示す出力データが提供され、それによって、ターゲットサービスポートを、トランスペアレントプロトコル対応のデバイスに関連した機能強化されたサービスポートへマッピングすることが可能になる。

［定義］
エンドノード：サービスを提供するのに使用されるあらゆるクラスのデバイスであり、例えば、サーバ、クライアント、ストレージアレイ、電気機器、ＰＤＡ等である。
２つのエンドノードは、各エンドノードのポート間の論理接続を介して互いに通信する。
ポート：ポートは、論理接続の端部を指定するものであり、ネットワーク上を送信されるメッセージの宛先アドレスの最終部分である。
例えば、ＴＣＰ環境では、ネットワークを介して送信されるあらゆるパケットが、パケット自身の送信元アドレスおよび宛先アドレスを運ぶ。
接続は、ＴＣＰ接続を含めて、或るＩＰアドレスの特定のポートから別のＩＰアドレスの特定のポートへ行われる。
したがって、あらゆるＴＣＰ接続は、アドレス１、ポート１、アドレス２、ポート２の４タプルによって一意に特定される。
ここで、各アドレスはＩＰアドレスであり、各ポートは１６ビット数である。
ポートマッピング：アプリケーションが指定したターゲットサービスポートの、関連したＲＤＭＡ対応のサービスポートへのアプリケーショントランスペアレントな変換である。
サービスポートは、この文書では、接続を確立する目的でソケットアプリケーションによって使用されるリスンポートである。
ポートマッパプロトコル：ポートマッピングサービスプロバイダとクライアントとの間でポートマッピング情報を通信するのに使用されるワイヤプロトコルである。
クライアントは、ＰＭクライアントであってもよいし、接続ピア（connecting peer）であってもよい。
接続ピア：（ＣＰ）接続確立要求を送信するピアである。
接続ピアは、ポートマッパプロトコルの状況で使用される場合、接続ピアの代わりに動作する管理エージェントとすることもできる。
受諾ピア：（ＡＰ（accepting peer））接続確立中に接続確立要求に対する応答を送信するピアである。
ＰＭクライアント：接続ピアの代わりにポートマッパプロトコルを実施する。
ＰＭクライアントは、ＣＰと同じ場所に配置されてもよいし、複数の潜在的なＣＰに対して分散されてもよい。
ＰＭＳＰ：ポートマッピングサービスプロバイダである。
受諾ピアに関連付けられた管理エージェントであり、ポートマッピング機能を実施する役割を担当する。
ＰＭＳＰは、ソケットダイレクトプロトコル（ＳＤＰ）のリスンポートおよびＩＰアドレス（例えば、ＲＤＭＡアドレス）がもしあれば、それらを返す。
接続ピアは、それらリスンポートおよびＩＰアドレスを使用して、指定された受諾ピアとのＲＤＭＡをベースとした接続を確立することができる。
ポリシー管理エージェント：通常、ソフトウェアで実施されるエンティティであり、ポリシー管理オペレーションを実行するエンティティである。
ＰＭＡは、ポートマッピングポリシーを実施し、例えば、ＰＭＳＰと協力してポートマッピング機能を実行する。

［システム環境］
本システムは、通信ネットワークのポートマッピングを行う関連した方法を含む。
一実施の形態では、本ポートマッピングシステムは、ソケットダイレクトプロトコル（ＳＤＰ）等の、ＲＤＭＡを使用するワイヤプロトコルと共に動作する。
ソケットダイレクトプロトコルは、本明細書で述べる例において例示のトランスポートプロトコルとして使用される。
ＳＤＰは、ＲＤＭＡ（リモートダイレクトメモリアクセス）を使用して、ＴＣＰ等の下位レイヤプロトコル（ＬＬＰ）上でＳＯＣＫ＿ＳＴＲＥＡＭセマンティクスを提供するバイトストリームトランスポートプロトコルである。
ＳＤＰは、ＴＣＰのストリームセマンティクスをそっくりまねたものであり、本システムの例示の一実施の形態では、ＳＤＰがその上で動作するところの下位レイヤプロトコルはＴＣＰである。
ＳＤＰによって、既存のソケットアプリケーションは、アプリケーションに対する変更を何ら必要とすることなく、データ転送についてＲＤＭＡの性能利益を得ることが可能になる。
したがって、ＳＤＰは、ＴＣＰ上でのソケットの従来の実施と比較して、ＣＰＵ利用およびメモリ帯域幅利用を低くすることができると同時に、現在のほとんどのネットワークアプリケーションが依拠するよく知られたバイトストリーム指向のセマンティクスを維持することができる。
本システムは、本明細書で例示の目的で使用されるＳＤＰおよびＴＣＰ以外のトランスポートレイヤプロトコルと共に動作できることに留意すべきである。

ＳＤＰは、ＳＯＣＫ＿ＳＴＲＥＡＭアプリケーションの下でトランスペアレントに動作する。
ＳＤＰは、アプリケーションが、そのアプリケーションが定義したリスンポートを使用してサービスをアドバタイズすること、および、ＳＤＰのＲＤＭＡ対応のリスンポートを使用してトランスペアレントに接続を行うことを可能にすることを目的とする。
一方、ＳＤＰ接続ピアが、ＳＤＰ通信用の接続を作成する際に使用するポートおよびＩＰアドレスを知らない場合、ＳＤＰは、ＳＤＰ／ＲＤＭＡ通信に使用できるＴＣＰポートおよびＩＰアドレスへの従来のＳＯＣＫ＿ＳＴＲＥＡＭ通信に使用されるＴＣＰポートおよびＩＰアドレスを解決しなければならない。
この文書における「ＲＤＭＡ」へのその後の参照は、ＳＤＰプロトコル、および、ハードウェアトランスポートメカニズムとしてＲＤＭＡを使用する他のあらゆるプロトコルにまで及ぶことを目的としたものである。

図１は、本ポートマッピングシステムの動作環境を提供する従来技術のネットワーク１００のハイレベルアーキテクチャを示す図である。
図１に示すように、エンドノード１０２（＊）で実行されるアプリケーション１０１（＊）は、各ポート１０３（＊）、ネットワークインターフェースカード１０４（＊）／１０５（＊）、およびファブリック１０６を介して自身のピアアプリケーション１０１（＊）と通信する。
本明細書で使用するように、参照番号に続く「ワイルドカード」指示子「（＊）」は、複数の同様のエンティティの任意のものを示す。
エンドノード１０２（＊）は、複数のポート１０３（＊）を使用してファブリック１０５（＊）に接続を行うことができる。
例えば、エンドノード１０２（１）は、ポート１０３（１）〜１０３（ｎ）を含み、これらポートのいずれも、対応するネットワークインターフェースカードを介してファブリック１０６に接続することができる。
この対応するネットワークインターフェースカードは、ＮＩＣ１０４（＊）、ＲＮＩＣ１０５（＊）、または、エンドノード１０２（＊）間の通信を実施する他の任意のデバイスとすることができる。
ＲＮＩＣ１０５（＊）は、ＲＤＭＡ（リモートダイレクトメモリアクセス）プロトコルをサポートするＮＩＣ（ネットワークインターフェースカード）である。
本明細書で使用するように、「ＲＮＩＣ」は、一般名称であり、ＲＤＭＡプロトコルをサポートする任意のタイプの相互接続とすることができる。
例えば、相互接続の実施態様は、ＴＣＰ／ＩＰ上のＲＤＭＡ、ＳＣＴＰ上のＲＤＭＡ、ＩｎｆｉｎｉＢａｎｄ上のＲＤＭＡ、またはメーカ独自のプロトコル（例えば、Ｉ／Ｏ相互接続もしくはバックプレーン相互接続）上のＲＤＭＡとすることができる。

図２は、本ポートマッパシステム２００の例示のハイレベルアーキテクチャを示す図である。
図２に示すように、サーバとして機能するポートマッパサービスプロバイダ（ＰＭＳＰ）２０４、およびポートマッパクライアント（ＰＭクライアント）２０３は、以下で詳述するポートマッパプロトコル２１０を使用して通信する。
ポートマッパプロトコル２１０によって、接続ピアは、従来のアドレスを与えられたＲＤＭＡアドレスを発見することができる。
ＲＤＭＡアドレスは、同じターゲットサービスのＴＣＰポートおよびＩＰアドレスであるが、ＲＤＭＡアドレスでは、ＲＤＭＡ上のＳＤＰ等のＲＤＭＡをベースとしたプロトコルを使用してデータを転送することが必要となる。

受諾ピア（ＡＰ）２０２および接続ピア（ＣＰ）２０１は、ポートマッパプロトコルからの結果を使用して、ＬＬＰ（下位レベルプロトコル、例えばＴＣＰ）接続のセットアップを開始する。
本明細書で説明するポートマッパプロトコル２１０によって、接続ピア２０１は、ポートマッパクライアント２０３を通じて、ポートマッパサービスプロバイダ２０４と交渉し、アプリケーションが指定したターゲットサービスポートを関連したＲＤＭＡサービスポートへ変換することが可能になる。
ＣＰ２０１とＡＰ２０２との間の通信は、バックプレーン、スイッチ、ケーブル、または無線を含む任意のファブリックタイプを介して実施することができる。

ポートマッパサービスプロバイダ２０４は、集中化エージェント（例えば、１つもしくは２つ以上のＰＭクライアント２０３、ＣＰ２０１、またはＡＰ２０２の代わりに動作する中央管理エージェント）を使用して実施することもできるし、あるいは、ＰＭＳＰ２０４は、分散させることもできる。
ＰＭＳＰ２０４は、ポートマッパプロトコル２１０を実施するのに使用される任意の管理エージェント機能を追加して含むことができる。
ＰＭＳＰ２０４は、接続ピア２０１または受諾ピア２０２と同じ場所に配置することを含めて、ネットワーク内のあらゆる場所に配置することができる。
一実施の形態では、ＰＭＳＰ２０４は、単に問い合わせサービスのみとすることができ、したがって、ＣＰ２０１が、ＡＰ２０２との通信を確立するのに必要なポートマッパプロトコル２１０を実施することが必要となる。

図２に示す例では、接続ピア２０１が、受諾ピア２０２とのＲＤＭＡ通信用の接続を作成する際に使用するポートおよびＩＰアドレスを知らない場合、標準的なＴＣＰマッピング２０５によって提供される（かつ、例えば従来のＳＯＣＫ＿ＳＴＲＥＡＭ通信に使用される）従来のＴＣＰポートおよびＩＰアドレス２０７を、ＲＤＭＡ通信に使用できるＴＣＰポートおよびＩＰアドレス（ＲＤＭＡアドレス）２０８へのＲＤＭＡマッピング２０６を介して解決しなければならない。

図３Ａは、ポートマッピングオペレーションを実施するための、ポートマッパサービスプロバイダ（ＰＭＳＰ）２０４とポートマッパクライアント２０３との間の例示の交換シーケンスを示す図である。
ＲＤＭＡ接続のセットアップは２段階で行われ、第１段階はスリーウェイメッセージ交換を含む。
例示の一実施の形態では、スリーウェイメッセージ交換は、以下で詳述するポートマッパプロトコル２１０を使用する。
クライアントの観点から、ＲＤＭＡ接続のセットアップの第１段階は、ＰＭクライアント２０３によって実行され、ＣＰ２０１とＡＰ２０２との間の下位レベルプロトコル（ＬＬＰ）接続のセットアップに使用されるアドレス（ＲＤＭＡアドレス２０８または従来のアドレス２０７のいずれか）が発見される。

図３Ａに示すように、最初に、サービスポート１０３（＊）、接続ピアＩＰアドレス、および受諾ピアＩＰアドレスに基づいてポートマッピング機能を提供するようにＰＭＳＰに要求するために、ポートマッパ要求メッセージ（ＰＭＲｅｑｕｅｓｔ）３０１がＰＭクライアント２０３からＰＭＳＰ２０４へ送信される。
これに応答して、ＰＭＳＰ２０４は、ポートマッパ応答メッセージ（ＰＭＡｃｃｅｐｔ）３０２をＰＭクライアント２０３へ送信する。
あるいは、ＰＭＤｅｎｙメッセージ３０４がＰＭＳＰ２０４によって送信されて、ポートマッピングオペレーションが拒否された、すなわち、オペレーションを実行することができなかったことを示すこともできる。

ＰＭＡｃｃｅｐｔメッセージ３０２は、ＰＭＳＰ２０４によって使用され、マッピングされたポート、使用される接続ピアＩＰアドレス、使用される受諾ピアＩＰアドレス、および、そのマッピングが有効な状態にある期間を示す時間値を返す。

次に、ＰＭクライアント２０３は、応答メッセージを受信したことを確認するポートマッパ肯定応答メッセージ（ＰＭ ＡＣＫ）３０３を送信する。
応答メッセージで返された時間値内に肯定応答メッセージが返信されないと、マッピングは無効にされることがあり、関連した資源は解放されることがある。

接続をセットアップする第２段階は、接続ピア２０１が、第１段階で交渉したアドレスを使用して、ＡＰ２０２で実行されている特定のサービスへの接続の確立を試みる時に行われる。
接続のセットアップの第２段階では、接続ピア２０１が、図３Ａのポートマッパプロトコルメッセージ交換の結果を使用して、受諾ピアのＲＤＭＡアドレスへのＬＬＰ（例えば、ＴＣＰ）接続のセットアップを試みるか、または、ＣＰ２０１が従来のアドレスへのＬＬＰ接続のセットアップを試みる。
前者によって、ＲＤＭＡ接続のセットアップが開始される。
後者によって、従来のストリーミングモード通信が使用される。

図３Ｂは、接続ピア２０１と受諾ピア２０２との間の接続を確立するための、接続ピア２０１と受諾ピア２０２との間の例示の交換シーケンスを示す図である。
図３Ｂの例で使用されるＬＬＰはＴＣＰである。
図３Ｂに示すように、接続ピア２０１は、図３Ａで説明したポートマッピングプロセスによって提供されたＲＤＭＡアドレスを使用して、ＴＣＰ ＳＹＮメッセージを受諾ピア２０２へ送信することによりＴＣＰ接続を開始する。
これに応答して、受諾ピア２０２は、ＴＣＰ ＳＹＮ ＡＣＫ３０５で応答する。
次に、接続ピア２０１は、受諾ピア２０２へＴＣＰ ＡＣＫ３０６を送信することによって応答し、ＣＰ２０１とＡＰ２０２との間のＴＣＰ接続を確立する。

図４は、アドレス／ポート解決を実行し、接続ピア２０１と受諾ピア２０２との間の接続を確立する例示のＡＰＩ呼び出しシーケンスを示す図である。
図４に示すように、時刻４１０において、受諾ピア２０２は、ｌｉｓｔｅｎ（）コール４０１を発行することによってリスンポート１０３（＊）を作成する。
次に、サービス解決が、接続ピア２０１が発行したｇｅｔｓｅｒｖｂｙｎａｍｅ（）コール４０２によって開始され、時間区間４１１の間続く。
接続フェーズ４１２の間、ＣＰ２０１およびＡＰ２０２は、ｃｏｎｎｅｃｔ（）コール４０３およびａｃｃｅｐｔ（）コール４０４を交換する。
交換後、ＣＰとＡＰとの間の通信が、ｓｅｎｄ（）コール４０５およびｒｅｃｅｉｖｅ（）コール４０６を交換することによって行われる。

図４に示すＡＰＩ呼び出しシーケンスでは、時間区間４１１の期間中であるサービス解決（例えば、ｇｅｔｓｅｒｖｂｙｎａｍｅ（）要求により）の期間中または時間区間４１２の期間中である接続処理（例えば、ｃｏｎｎｅｃｔ（）要求を介して）の期間中のいずれかで、ポートマッパサービスはトランスペアレントに起動される。
受諾ピア２０２は、ｌｉｓｔｅｎ（）時において対応するサービスのリスンポートを作成することもできるし、ポートマッパ要求メッセージが受信されたことに応答してリスンポートを動的に作成することもできる。
接続ピア２０１または受諾ピア２０２のいずれも、使用されるポートマッピングサービスと相互作用する前、または、当該相互作用の一部として、中央ポリシー管理エージェントまたはローカルポリシー管理エージェントと相互作用することができる。
ＡＰ２０２は、動的なリスンポートの作成を実施することができ、ＣＰ２０１またはＣＰ２０１の代わりに動作するエージェント５０１（＊）（図５に示すように）に、Ｎ個の単位時間ごとに毎回問い合わせを行うか、または、永続的または一時的にキャッシュされたマッピングの結果を使用するように要求することができる。

［ポリシー管理エージェントの構成］
図５は、ローカルポリシー管理エージェント５０１（Ａ）および５０１（Ｂ）を使用するポートマッピングの例示の構成を示す図であり、図６は、集中化ポリシー管理エージェント６０１を使用する例示のポートマッピング構成を示す図である。
図５および図６において、ローカルポリシー管理エージェント５０１（＊）は、ポートマッピングポリシーを実施し、例えばＰＭＳＰ２０４（＊）と協力してポートマッピング機能を実行する。

図５に示すように、ポートマッピングサービスプロバイダ（ＰＭＳＰ）は、ＡＰ２０２（５）と同じ場所に配置されたＰＭＳＰ２０４（Ｌ）によって示すように、各ＡＰ２０２と同じ場所に配置して分散させることができる。
図５の構成では、ポートマッピング情報は、ＣＰ２０１（５）とＡＰ２０２（５）との間で直接通信される。

代替的に、ポートマッピングサービスプロバイダは、図６に示すように集中化させることができる。
図６では、集中化ポリシー管理エージェント６０１を使用する集中化ＰＭＳＰ２０４（Ｃ）が示されている。
集中化ポリシー管理エージェント６０１は、１つまたは２つ以上のＰＭクライアント２０３（図６に図示せず）、または、矢印６０２／６０３で示すように接続ピア２０１（６）もしくは受諾ピア２０２（６）の代わりに動作することができる。

ＰＭＳＰ２０４（＊）、ＰＭクライアント２０３、ＣＰ２０１、またはＡＰ２０２は、中央ポリシー管理エージェント６０１または同じ場所に配置されたポリシー管理エージェント５０１と相互作用して、負荷バランシング（例えば、サービスベース、ハードウェア資源ベース、エンドノードサービス容量ベース）、宛先の変更等のエンドノード特有のポリシーまたはサービス特有のポリシーを実施することができる。

接続ピア２０１で実行され、ＡＰ ＲＤＭＡサービスリスンポートのアプオリの知識を有するアプリケーションは、ＰＭＳＰと相互作用する必要なく、そのリスンポートをターゲットにすることができる。
このようなアプリケーションは、依然としてポリシー管理エンティティと相互作用して、好ましいＣＰおよびＡＰ ＲＮＩＣアドレスを取得することができる。
例えば、複数のＲＮＩＣ１０５（＊）がＣＰ２０１またはＡＰ２０２のいずれかで利用可能である場合、ポリシー管理相互作用（以下で詳述）を使用して、どのＲＮＩＣ１０５（＊）を通信目的でターゲットとするかが決定される。

［ポートマッピングシステムの構成］
図７は、ポートマッピングが、ローカルＰＭクライアント２０３およびローカルポリシー管理エージェント５０１によって接続ピア１０１の代わりに実行される例示の一実施態様を示す図である。
図７に示す構成では、接続ピア２０１は、接続ピアのローカルＰＭクライアント２０３とコンタクトし、ターゲットＡＰ２０２のサービスポートをマッピングするようにＰＭクライアントに要求する。
ＰＭクライアント２０３は、キャッシュされた有効なマッピングを有する場合、このマッピングをＣＰ２０１に直ちに返すことができる。
ＰＭクライアント２０３が、キャッシュされた有効なマッピングを有しない場合、または、マッピングサービスを実行する前にローカルポリシーが有効であると確認される場合、ＰＭクライアントは、ローカルポリシー管理エージェント５０１とコンタクトして、必要なポートマッピング情報を取得することができる。

ＰＭクライアント２０３は、システムにローカルなポリシー管理エージェント（例えば、ローカルＰＭＡ５０１（Ａ））または中央で管理されたポリシー管理エージェント６０１（図６に示すような）を調べて、最適な応答を決定することができる。
有効なポートマッピングが、ポリシー管理エージェント５０１／６０１によって返されると、ＣＰ２０１は、ＡＰ２０２との接続確立に直接進むことができる。

受諾ピア２０２は、（例えば、ループバック通信を介して）ＣＰ２０１と同じ場所に配置することもできるし、リモートとすることもできる。
本明細書で使用するように、用語「リモート」は、ＣＰ２０１から論理的または物理的に別個の離れたエンドノードターゲットを示す。
ＡＰとＣＰとの間の通信は、エンドノードのバックプレーンを横断することもできるし、Ｉ／Ｏベースのファブリック（有線または無線）を横断することもできる。

図８は、接続ピア２０１および受諾ピア２０２がそれぞれローカルポリシー管理エージェント５０１（８ａ）／５０１（８ｂ）およびローカルＰＭクライアント２０３／ＰＭＳＰ２０４をそれぞれ使用する例示のポートマッピング構成を示す図である。
図８に示すように、ＣＰ２０１は、ＰＭクライアント２０３と同じ場所に配置することができ、ＰＭＳＰ２０４は、ＡＰ２０２と同じ場所に配置することができる。
これらはそれぞれ、破線のボックス８０１および８０２に示す。
図８の構成では、ＣＰ２０１およびＡＰ２０２は、それらの各ＰＭクライアント／ローカルＰＭＳＰと協議することができ、かつ／または、ローカルポリシー管理エージェントを直接調べることができる。
ＣＰ２０１およびＡＰ２０２がそれらのローカルＰＭクライアント２０３／ＰＭＳＰ２０４を使用する場合、これらＣＰおよびＡＰは、ポートマッパプロトコル、およびマッピングされたポートへの接続確立プロトコルを実施する。

代替的に、接続ピア２０１および受諾ピア２０２は、自身の各ＰＭクライアント２０３／ＰＭＳＰ２０４を使用して、自身に代わってポートマッパプロトコルを代理させることができる。
この場合、ＰＭクライアント２０３とＰＭＳＰ２０４との間の通信（破線の矢印８０３によって示す）は、例示の一実施の形態では、スリーウェイＵＤＰ／ＩＰデータグラムハンドシェークを使用する。
ＰＭクライアント２０３とＰＭＳＰ２０４との間の通信は、どのパスを介しても行うことができる。
この通信は、ＣＰとＡＰとの間の通信に使用される実際のハードウェアを介して行う必要はない。

図９は、ＰＭクライアントまたはＰＭＳＰ９０４が中央で管理される例示のポートマッピング構成を示す図である。
例示の一実施の形態では、複数のＰＭクライアント／ＰＭＳＰインスタンス９０４をファブリック内に分散させることができる。
図９の矢印９０１および９０２によって示すように、中央ポリシー管理エージェント６０１は、ＣＰ／ＡＰローカルポリシー管理エージェント５０１（Ｅ）／５０１（Ｆ）と直接通信して、ＣＰ２０１またはＡＰ２０２を含むエンドノード１０２（＊）に特有のローカルポートマッピングポリシーを発見することができる。
ポートマッピングポリシーの発見プロセスの期間中、中央ポリシー管理エージェント６０１は、中央ポリシー管理エージェントがＰＭＳＰ要求に正確に応答できるように、エンドノードの関連したハードウェア、ファブリック接続、システム使用モデル、サービス優先度等を決定する。
例えば、新たなサービスがサポートされ、その新たなサービスがＲＤＭＡに使用されるべきであることをローカルポリシーが示す場合において、資源（システム、ＲＮＩＣ等）がサポートを提供できるとき、ＡＰ２０２は中央ＰＭＳＰ９０４を更新する。

接続ピア２０１が、ＰＭクライアント９０４にポートマップ要求メッセージを直接発行する場合、ＰＭクライアントは（アプリオリの知識に基づいて）直ちに応答するか、または、ＰＭクライアント９０４は、ＡＰ２０２および／またはＡＰ２０２のローカルポリシー管理エージェント５０１（Ｆ）と協議して応答を生成することができる。

図１０は、所与のサービスの特定のＡＰ ＩＰターゲットアドレスが集約アドレスである例示のポートマッピングの実施態様を示す図である。
図１０に示すように、ＰＭクライアント２０３は、単一のＲＮＩＣを示す特定の受諾ピアのＩＰアドレスを含めて、所与のサービスの特定のＡＰ ＩＰアドレスをターゲットとすることができ、また、１つまたは２つ以上のエンドノード１０２上の複数のＲＮＩＣ１０５（＊）の１つを示す特定のＡＰ ＩＰアドレスをターゲットとすることもできる。
後者の状況では、ＡＰ ＩＰアドレスは、複数のＲＮＩＣ１０５（＊）を集約し、ＡＰ ＲＮＩＣポートへのＩＰアドレス解決は、パケットを誤った経路で送るのを回避するために一意でなければならない。
例えば、ＡＰ２０２（Ａ）およびＡＰ２０２（Ｂ）は、各グループ１０５（Ａ）および１０５（Ｂ）に複数のＲＮＩＣを有することができ、各ＲＮＩＣグループまたはそのサブセットは、単一の集約ＩＰアドレスを有することができる。

ＰＭＳＰ２０４とのポートマッパプロトコル交換の結果、ＰＭクライアント２０３は、当該ＰＭクライアントが最初に選択したＡＰ ＩＰアドレスとは異なる「改訂された」ＡＰ ＩＰアドレスをＰＭＳＰ２０４から受信することができる。
図１０の例では、矢印１００１に示すように、ＰＭクライアント２０３は、ＰＭＳＰ２０４を使用して、最初に受諾ピア２０２（Ａ）の１つまたは２つ以上のＲＮＩＣ１０５（Ａ）を選択する。
一方、ＡＰ２０２（Ａ）またはそのポリシー管理エージェント（図示せず）のいずれかは、ＰＭクライアント２０３が選択したＩＰアドレスとは異なるＩＰアドレスを返す場合がある。
このような場合、ＰＭクライアント２０３は、ＰＭＡｃｃｅｐｔメッセージ３０２で返された、改訂されたＩＰアドレスを受諾し、その後のＲＤＭＡ送信を、改訂されたＩＰアドレスのターゲット受諾ピア２０２へ向ける。

最初に選択されたアドレスとは異なるＩＰアドレスを受諾することによって、ＡＰ２０２または当該ＡＰに代わって動作するポリシー管理エージェント５０１は、所望のサービスについて適切なＲＮＩＣ１０５（＊）を選択することが可能になる。
選択されたＲＮＩＣは、同じエンドノードにおけるものであってもよいし、別個のエンドノードに宛先を変更されたものであってもよい。
ＲＮＩＣ選択ポリシーは、以下で詳述するように、システム負荷バランシングアルゴリズムまたはシステムサービス品質（ＱｏＳ）パラメータに基づいて、最適なサービス配信を行うことができる。

［ポートマッパプロトコル］
図３Ａに関して前述したように、例示の一実施の形態では、ポートマッパワイヤプロトコル２１０は、ＰＭクライアント２０３と、受諾ピア２０２の代わりに動作するポートマッパサービスプロバイダ（ＰＭＳＰ）２０４または受諾ピア自体との間で、スリーウェイＵＤＰ／ＩＰ（データグラム）メッセージ交換を使用する。
図１１は、ポートマッパプロトコル２１０を介して送信される各ポートマッパメッセージの例示の共通フィールドを示す図である。
以下のフィールドは図１１に示されたものである。
−ＯＰフィールド１１０２は、ポートマッパメッセージタイプを特定するのに使用される２ビットオペレーションコードである。
−ＩＰＶフィールド１１０３は、使用中のＩＰアドレスのタイプを示す。
ＩＰＶ＝０ｘ４は、ＩＰｖ４アドレスが使用されることを示し、ＣｐｌＰａｄｄｒフィールドおよびＡｐｌＰａｄｄｒフィールドの最初の３２ビットのみが有効である。
ＩＰＶ＝０ｘ６は、ＩＰｖ６アドレスが使用されることを示す。
すなわち、ＣｐｌＰａｄｄｒフィールドおよびＡｐｌＰａｄｄｒフィールドの１２８ビットすべてが有効である。
−ＰｍＴｉｍｅフィールド１１０４は、ポートマッパ受諾メッセージに使用されて、応答メッセージが生成されてからの、ＡＰポートフィールド（ＯＰ＝１）が有効であるとみされる全時間を示す。
−ＡＰポートフィールド１１０５は、関連したポートを要求するのに使用されるか、または、マッピングされたポートを返すのに使用される。
−ＣＰポートフィールド１１０６はＣＰのＴＣＰポートを示す。
−ＡｓｓｏｃＨａｎｄｌｅ（関連ハンドル）フィールド１１０７は、接続ピアがポートマッパトランザクションを一意に特定するのに使用される。
−ＣｐｌＰａｄｄｒフィールド１１０８は、ＲＤＭＡ／ＳＤＰセッション確立に使用されるＣＰ ＩＰアドレスを含む。
ＣｐｌＰａｄｄｒは、メッセージを送信するのにＵＤＰ／ＩＰデータグラムヘッダに使用されるＩＰアドレスと異なる場合がある。
−ＡｐｌＰａｄｄｒフィールド１１０９は、ＲＤＭＡ／ＳＤＰセッション確立に使用されるＡＰ ＩＰアドレスを含む。
ＡｐｌＰａｄｄｒは、メッセージを送信するのにＵＤＰ／ＩＰデータグラムヘッダに使用されるＩＰアドレスと異なる場合がある。

ＰＭクライアント２０３とＰＭＳＰ２０４／ＡＰ２０２との間のスリーウェイＵＤＰ／ＩＰメッセージ交換で送信される最初のメッセージはＰＭＲｅｑメッセージ３０１（図３Ａに示す）である。
このメッセージは、ＰＭクライアント２０３によってＰＭＳＰ（またはＡＰ）へ送信され、対応するサービスポート用のＲＤＭＡリスンポートを要求する。

ＰＭＲｅｑメッセージフィールドは、ＰＭクライアントによって以下のように設定される。
ＯＰフィールド１１０２：０の値に設定される。
ＩＰＶフィールド１１０３：ＣｐｌＰＡｄｄｒおよびＡｐｌＰＡｄｄｒがＩＰｖ４アドレスである場合には０ｘ４に設定され、ＣｐｌＰＡｄｄｒおよびＡｐｌＰＡｄｄｒがＩＰｖ６アドレスである場合には０ｘ６に設定される。
ＰｍＴｉｍｅフィールド１１０４：０に設定され、受信においては無視される。
ＡＰポートフィールド１１０５：関連したサービスのリスンポートに設定される。
ＣＰポートフィールド１１０６：接続ピアがサービスに接続する際に使用するローカルＴＣＰポート番号に設定される。
ＡｓｓｏｃＨａｎｄｌｅフィールド１１０７：接続ピアによって、実行中のトランザクションを区別する一意の値に設定される。
ＣｐｌＰａｄｄｒフィールド１１０８：ＬＬＰ接続確立を開始する接続ピアのＩＰアドレスに設定される。
ＡｐｌＰａｄｄｒフィールド１１０９：接続確立に使用されるターゲット受諾ピアのＩＰアドレスに設定される。

ＰＭクライアント２０３がＵＤＰ／ＩＰを使用してポートマッパサービスプロバイダポート１０３（＊）をターゲットにすることにより、ポートマッパ要求（ＰＭＲｅｑ）メッセージ３０１が送信される。
ポートマッピングオペレーションが成功すると、ＰＭＳＰ２０４／ＡＰ２０２は、ＰＭＡｃｃｅｐｔメッセージ３０２を返す。
ＰＭＡｃｃｅｐｔメッセージ３０２は、ＰＭＲｅｑｕｅｓｔメッセージ３０１の対応するフィールド内に含まれるＵＤＰポートおよびＩＰアドレスの情報を使用してＵＤＰ内にカプセル化される。

ポートマッパ受諾（ＰＭＡｃｃｅｐｔ）メッセージ３０２は、ポートマッパ要求メッセージ３０１に応答して、ＰＭＳＰ２０４／ＡＰ２０２により送信される。

ＰＭＡｃｃｅｐｔメッセージフィールドは、ＰＭＳＰ／ＡＰによって以下のように設定される。
ＯＰフィールド１１０２：０１の値に設定される。
ＩＰＶフィールド１１０３：ＰＭＲｅｑメッセージのＩＰＶフィールドと同じ値に設定される。
ＰｍＴｉｍｅフィールド１１０４：応答メッセージが生成されてからの、ＡＰポートフィールド（ＯＰ＝１）が有効であるとみされる全時間を示すように設定される。
ＡＰポートフィールド１１０５：ＲＤＭＡリスンポートに設定される。
ＣＰポートフィールド１１０６：対応するＰＭＲｅｑメッセージのＣＰポートフィールドと同じ値に設定される。
ＡｓｓｏｃＨａｎｄｌｅフィールド１１０７：対応するＰＭＲｅｑメッセージのＡｓｓｏｃＨａｎｄｌｅフィールドと同じ値に設定される。
ＣｐｌＰａｄｄｒフィールド１１０８：対応するＰＭＲｅｑメッセージのＣｐｌＰＡｄｄｒフィールドと同じ値に設定される。
ＡｐｌＰａｄｄｒフィールド１１０９：接続確立で使用される受諾ピアのＩＰアドレスに設定される。
受諾ピアは、対応するＰＭＲｅｑメッセージで要求されたものと異なるＡｐｌＰＡｄｄｒを返すことができる。

ＰＭＡｃｃｅｐｔメッセージ３０２は、対応するＰＭＲｅｑメッセージ３０１を配信するのに使用されたＵＤＰ／ＩＰヘッダに含まれるアドレス情報を使用して送信される。

ＰＭクライアント２０３は、ＰＭＡｃｃｅｐｔメッセージ３０２を受信すると、ポートマッパ肯定応答（ＰＭＡｃｋ）メッセージ３０３を返す。
このＰＭＡｃｋメッセージ３０３は、対応するＰＭＡｃｃｅｐｔメッセージ内に含まれるＵＤＰポートおよびＩＰアドレスの情報を使用してＵＤＰ内にカプセル化される。
ＰＭＡｃｋメッセージフィールドは、ＰＭクライアントによって以下のように設定される。
ＯＰフィールド１１０２：０２の値に設定される。
ＩＰＶフィールド１１０３：対応するＰＭＡｃｃｅｐｔメッセージのＩＰＶフィールドと同じ値に設定される。
ＰｍＴｉｍｅフィールド１１０４：０に設定され、受信においては無視される。
ＡＰポートフィールド１１０５：対応するＰＭＡｃｃｅｐｔメッセージのＡＰポートフィールドと同じ値に設定される。
ＣＰポートフィールド１１０６：対応するＰＭＡｃｃｅｐｔメッセージのＣＰポートフィールドと同じ値に設定される。
ＡｓｓｏｃＨａｎｄｌｅフィールド１１０７：対応するＰＭＡｃｃｅｐｔメッセージのＡｓｓｏｃＨａｎｄｌｅフィールドと同じ値に設定される。
ＣｐｌＰａｄｄｒフィールド１１０８：対応するＰＭＡｃｃｅｐｔメッセージのＣｐｌＰＡｄｄｒフィールドと同じ値に設定される。
受諾ピアの一実態態様は、ＣｐｌＰＡｄｄｒを使用して、対応するＰＭＡｃｃｅｐｔメッセージで返されたＡＰポートとのＣｐｌＰＡｄｄｒの関連を通じて、その後のＬＬＰ接続要求の有効性を確認することができる。
ＡｐｌＰａｄｄｒフィールド１１０９：対応するＰＭＡｃｃｅｐｔメッセージのＡｐｌＰＡｄｄｒフィールドと同じ値に設定される。

ＰＭＡｃｋメッセージ３０３は、ＰＭクライアントが、ＰＭＡｃｃｅｐｔメッセージを配信するのに使用されたＵＤＰ／ＩＰヘッダに含まれるアドレス情報を使用することによって送信される。

図３Ａのスリーウェイメッセージ交換は、集中化したポートマッパの実施態様または分散した（ピアツーピア）ポートマッパの実施態様のいずれかをサポートすると同時に、接続ピア２０１と受諾ピア２０２との間で交換されるパケット数を最小にする。
ポートマッパメッセージにより与えられた柔軟性により、さまざまな相互運用可能な実施態様のオプションが可能になる。
例えば、ＰＭクライアント２０３は、接続ピア２０１の代わりに動作するエージェントとして実施することもできるし、接続ピアの一部として実施することもできる。
ポートマッピングサービスプロバイダ２０４も、受諾ピア２０２の代わりに動作するエージェントとして実施することもできるし、受諾ピアの一部として実施することもできる。
これに加えて、ＰＭＡｃｃｅｐｔメッセージ３０２内のＡｐｌＰＡｄｄｒフィールド１１０９は、ローカルポリシーの決定によって、要求されたＩＰアドレス（すなわち、ＰＭＲｅｑｕｅｓｔ３０１のＡｐｌＰＡｄｄｒフィールド１１０９）と異なることがある。

例えば、受諾ピア２０２が複数のネットワークインターフェースを含み、そのローカルポリシーがネットワークインターフェース負荷バランシングをサポートする場合、受諾ピア２０２は、図１０に関して先に示したように、選択されたターゲットインターフェースのＡｐｌＰＡｄｄｒ１１０９について、ＰＭＲｅｑメッセージで要求されたＡｐｌＰＡｄｄｒとは異なるＡｐｌＰＡｄｄｒ１１０９を返すことができる。
肯定応答メッセージは、応答を送信するのに使用されたＵＤＰ／ＩＰデータグラムに含まれる送信元アドレスに返されるべきである。
ＰＭＳＰ２０４は、適切な応答を生成するために要求の宛先を別のエンドノードへ変更していることがあるので、対応するＣＰ２０１またはＣＰの代わりに動作するエージェントは、応答メッセージ内の情報のみを使用しなければならず、元の要求メッセージの情報を使用してはならない。

スリーウェイメッセージ交換によって、受諾ピア２０２は、接続ピアがＰｍＴｉｍｅフィールド１１０４で指定された期間内しかＲＤＭＡリスンポートを利用しないという知識を用いて、当該ＲＤＭＡリスンポートを動的に作成することが可能になる。
ＰＭＡｃｋメッセージが受信されない場合、受諾ピア２０２は、その期間が満了すると関連した資源を解放することができる。
資源を解放できることによって、ＲＤＭＡリスンポートの消費を介してサービス拒否攻撃の影響が最小にされる。

ポートマッピングオペレーションが成功しない場合、受諾ピアはＰＭＤｅｎｙメッセージ３０４を返す。
このＰＭＤｅｎｙメッセージ３０４は、対応するＰＭＲｅｑｕｅｓｔメッセージ内に含まれるＵＤＰポートおよびＩＰアドレスの情報を使用してＵＤＰ内にカプセル化される。
ＰＭＤｅｎｙメッセージフィールドは、受諾ピアによって以下のように設定される。
ＯＰフィールド１１０２：０３の値に設定される。
ＩＰＶフィールド１１０３：ＰＭＲｅｑメッセージのＩＰＶフィールドと同じ値に設定される。
ＰｍＴｉｍｅフィールド１１０４：０に設定され、受信においては無視される。
ＡＰポートフィールド１１０５：対応するＰＭＲｅｑメッセージのＡＰポートフィールドと同じ値に設定される。
ＣＰポートフィールド１１０６：対応するＰＭＲｅｑメッセージのＣＰポートフィールドと同じ値に設定される。
ＡｓｓｏｃＨａｎｄｌｅフィールド１１０７：対応するＰＭＲｅｑメッセージのＡｓｓｏｃＨａｎｄｌｅフィールドと同じ値に設定される。
ＣｐｌＰＡｄｄｒフィールド１１０８：対応するＰＭＲｅｑメッセージのＣｐｌＰＡｄｄｒフィールドと同じ値に設定される。
ＡｐｌＰＡｄｄｒフィールド１１０９：対応するＰＭＲｅｑメッセージのＡｐｌＰＡｄｄｒフィールドと同じ値に設定される。

ＰＭＤｅｎｙメッセージは、ＰＭＲｅｑメッセージ３０１を配信するのに使用されたＵＤＰ／ＩＰヘッダに含まれるアドレス情報を使用して送信される。
ＰＭクライアントは、ＰＭＤｅｎｙメッセージ３０４を受信すると、関連したポートマッパトランザクションを完了したものとして取り扱い、ＰＭＡｃｋメッセージを発行しない。
ポートマッパオペレーションは、例えば、このようなサービスマッピングが存在しないことや、資源を使い果たしたこと等のさまざまな理由から失敗することがある。

［ＰＭクライアントの挙動］
ＰＭクライアント２０３および接続ピア２０１の組み合わせによって、ポートマッパメッセージのＡｓｓｏｃＨａｎｄｌｅ１１０７、ＣｐｌＰＡｄｄｒ１１０８、およびＣｐＰｏｒｔ１１０６の組み合わせが、ネットワークにおけるパケットの最大寿命内で一意となることを保証するように、当該組み合わせが選択される。
これによって、ＰＭＳＰ２０４は、遅延した複製メッセージに遭遇しないことが保証される。
ＰＭクライアント２０３は、ＰＭＲｅｑメッセージ３０１を送信する時にタイマを装備する。
ＰＭＲｅｑメッセージに対する応答のタイムアウトが発生すると（すなわち、対応するＰＭＡｃｃｅｐｔメッセージ３０２もＰＭＤｅｎｙメッセージ３０４も、タイムアウトが発生する前に受信されなかった）、ＰＭクライアント２０３は、ＰＭＲｅｑメッセージ３０１を再送し、（タイムアウトによる）最大個数の再送までのタイムアウトを再装備する。

ＰＭクライアント２０３は、ＰＭＲｅｑ３０１のあらゆる再送において同じＡｓｓｏｃＨａｎｄｌｅ１１０７、ＡｐＰｏｒｔ１１０５、ＡｐｌＰＡｄｄｒ１１０９、ＣｐＰｏｒｔ１１０６、およびＣｐｌＰＡｄｄｒ１１０８を使用する。
例示の一実施の形態では、ホストによって選ばれる最初のＡｓｓｏｃＨａｎｄｌｅ１１０７をランダムに選び、サードパーティがプロトコル３１０を妨害することをより困難にすることができる。
ＡｓｓｏｃＨａｎｄｌｅ、ＡｐＰｏｒｔ、ＣｐＰｏｒｔ、ＡｐｌＰＡｄｄｒ、およびＣｐｌＰＡｄｄｒの組み合わせは、接続ピア２０１に関連したホスト内において一意である。
これによって、ＰＭＳＰ２０４は、クライアント要求を区別することが可能になる。

ＰＭクライアント２０３は、最大個数のタイムアウトの後に、ＰＭＳＰ２０４からの回答を受信しないと、ＲＤＭＡアドレスへの接続の試みを停止し、その代わりに、ＬＬＰ接続セットアップ用の従来のアドレスを使用する。
従来のＬＬＰ接続セットアップによって、ストリーミングモードのデータ転送が開始される。

ＰＭクライアント２０３は、ＲＤＭＡアドレスへの接続を試みている時にＬＬＰ接続リセット（例えば、ＴＣＰ ＲＳＴセグメント）を受信すると、これを、ＰＭＤｅｎｙメッセージ３０４を受信したことと等価であるとみなし、したがって、従来のアドレスを使用してサービスへの接続を試みる。

ＰＭクライアント２０３は、ＰＭＲｅｑメッセージ３０１に対する応答を受信し、その後、同じ要求についての別の応答を受信すると、当該要求に対する追加されたあらゆる応答（ＰＭＡｃｃｅｐｔまたはＰＭＤｅｎｙ）を廃棄する。

ＰＭクライアントが、ＰＭＡｃｃｅｐｔ３０２またはＰＭＤｅｎｙ３０４を受信し、このメッセージの受信に対応する関連した状態を有しない場合、そのメッセージは廃棄される。

［ＰＭサーバの挙動］
ＰＭＳＰ２０４は、ＰＭＡｃｃｅｐｔメッセージ３０２を送信する時にタイマを装備することができる。
このタイマは、ＰＭＡｃｋ３０３またはＲＤＭＡアドレスへのＬＬＰ接続セットアップ要求（例えば、ＴＣＰ ＳＹＮ）のいずれかが行われた時に無効にされる。
ＰＭＡｃｋメッセージ３０３またはＬＬＰ接続セットアップ要求が、タイムアウト間隔の終了前に受信されない場合、ＰＭＲｅｑ３０１に関連したすべての資源は削除される。
この手続きは、一定のサービス拒否攻撃に対する保護に役立つ。

ＰＭＳＰ２０４は、複製のＰＭＲｅｑメッセージ３０１を検出すると、ＰＭＡｃｃｅｐｔメッセージ３０２またはＰＭＤｅｎｙメッセージ３０４のいずれかで応答する。
これに加えて、ＰＭＳＰは、複製されたＰＭＲｅｑメッセージについての前のＰＭＡｃｃｅｐｔメッセージを送信した時にタイマを装備していた場合、ＰＭＡｃｃｅｐｔメッセージの再送時にそのタイマをリセットする。

ＰＭＳＰ２０４が、接続ピア２０１をサービスにアタッチしようと試みている時、そのサービスは、利用可能または利用不能の２つの状態の一方を有することができる。
ＰＭＳＰは、複製のＰＭＲｅｑメッセージ３０１を受信すると、要求されたサービスの最も近時の状態を使用して、そのＰＭＲｅｑに対し（ＰＭＡｃｃｅｐｔ３０２またはＰＭＤｅｎｙ３０４のいずれかで）応答することができる。

上述した方法によって、ＰＭＳＰ２０４は、要求されたサービスに関する最も近時の状態情報の通信を試みる。
しかしながら、ポートマッパプロトコル２１０は、ＵＤＰ／ＩＰにマッピングされるので、受信時にメッセージを再配列できる可能性がある。
したがって、ＰＭＳＰが複製のＰＭＲｅｑメッセージ３０１を受信し、ＰＭＳＰがその応答をＰＭＡｃｃｅｐｔからＰＭＤｅｎｙへ、または、ＰＭＤｅｎｙからＰＭＡｃｃｅｐｔへ変更すると、その応答は、順序通りに受信されない可能性がある。
この場合、ＰＭクライアント２０３は、ＰＭＳＰから受信した最初の応答を使用する。

ＰＭＳＰ２０４が、当該ＰＭＳＰ２０４がすでにＰＭＡｃｃｅｐｔ３０２を返信したトランザクションのＰＭＲｅｑ３０１を受信したが、ＡｓｓｏｃＨａｎｄｌｅ１１０７が前の要求と一致しない場合、ＰＭＳＰは、前の要求に関連した状態の廃棄およびクリーンアップを行い、新たなＰＭＲｅｑを通常通り処理する。
この要求のＰＭＳＰ状態が削除された後に複製メッセージが到着すると、ＰＭＳＰは、その複製メッセージを新たな要求とみなし、応答を生成することに留意されたい。
前の応答が接続ピア２０１による作用を受けていた場合、最新の応答は、一致した状況を有しないはずであり、したがって、ＰＭクライアント２０３によって廃棄される。

［ポートマッピングポリシー管理］
本ポートマッピングシステムでは、ポリシー管理は、所与のイベントをどのようにハンドリングするかを定義するルールによって統制される。
例えば、ポリシー管理を使用して、ＣＰ２０１またはＡＰ２０２のいずれかが所与のサービスに使用する最適なＲＮＩＣ１０５を決定することができる。
このように決定されたＲＮＩＣは、所与のエンドノード１０２における複数のＲＮＩＣの１つである場合もあるし、別個のエンドノードにおけるものである場合もある。
例示の一実施の形態では、ＰＭＡおよびＰＭＳＰ／ＰＭクライアントは、ツーウェイ交換要求応答通信を介して情報を交換する。
このツーウェイ交換要求応答通信では、ＰＭＳＰ／ＰＭクライアントが、どのポートをマッピングするかに関する情報、および、ＲＮＩＣを特定するのに使用されるＩＰアドレスを要求する。
ＰＭＡ５０１（＊）は、１回限りの情報を返すこともできるし、ＰＭＳＰが１組の資源を或る期間の間キャッシュできることを示す情報を返すこともできる。

図１２〜図１５は、ポートマッピングポリシーのさまざまな態様を実施するのに使用できる例示のモデルを示している。
図１２は、アウトバウンドＲＮＩＣ１０５（１）が選択される例示のポートマッピングポリシー管理のシナリオを示す図である。
図１２に示すように、ＣＰ２０１は、２つ以上のＲＮＩＣ１０５（＊）を含むことができる。
ターゲットサービス／リモートエンドノード１０２（Ｒ）は、先に示したように、サービス解決中に（例えば、ｇｅｔｓｅｒｖｂｙｎａｍｅ（）要求によって）導出された情報、または、接続処理中に（例えば、ｃｏｎｎｅｃｔ（）コールからのｃｏｎｎｅｃｔ（）要求を介して）導出された情報から特定される。

ローカルＰＭクライアント２０３は、相互接続インターフェースライブラリ１２０１（例示の一実施の形態ではソケットライブラリである）にアクセスして、有効なポートマッピングがあるかどうかを判断することができる。
本明細書で使用するように、「ソケットライブラリ」は、ソケットインフラストラクチャにアクセスするアプリケーションによって使用されるメカニズムの一般名称である。
本説明は、ソケットの実施態様を対象とするが、明示的なアクセスまたはトランスペアレントなアクセス（図１２に示すような）をメッセージパッシングインターフェース等の他の相互接続インターフェースライブラリに適用することができる。

ＰＭクライアント２０３は、ローカルポリシー管理エージェントまたは集中化ポリシー管理エージェント（ＰＭＡ）１２０２を調べて、アプリケーション１０１がＲＤＭＡポートを使用して促進されるべきかどうかを判断することができ、また、例えばＲＮＩＣ１０５（１）といったターゲットのアウトバウンドＲＮＩＣを特定することもできる。
ＰＭＡ１２０２は、資源マネージャ１２０３と協力して、アプリケーション特有の資源要件および制限を決定することができ、リモートエンドノードＩＰアドレスを調べて、ＣＰ２０１に関連したＲＮＩＣのいずれかがこのエンドノード１０２（Ｒ）に到達できるかどうかを判断することができる。
また、ＰＭＡ１２０２は、アプリケーション特有のポリシー管理を提供する資源マネージャ１２０３にアクセスして、選択されたＲＮＩＣ１０５（１）が利用可能な資源を有するかどうか、および、関連したアプリケーション１０１の負荷が軽減されるべきかどうかを判断することもできる。

これに加えて、ＰＭＡ１２０２は、ルーティングテーブル（ローカルまたはリモートのいずれか（図示せず））にアクセスして、ＲＮＩＣ１０５（＊）を選択することもできる。
適切なＲＮＩＣ１０５（＊）の選択は、さまざまな判定基準に基づくことができ、例えば、負荷バランシング、ＲＮＩＣ属性および資源、ＱｏＳ（サービス品質）分離（segregation）等に基づくことができる。
例えば、ＲＮＩＣ１０５（１）は高優先度のトラフィックをハンドリングすることができる一方、ＲＮＩＣ１０５（２）はベストエフォートに基づいてトラフィックをハンドリングする。

［ポリシー管理判定基準］
例示のポリシー管理判定基準には、以下のものが含まれる。
−ターゲットサービスの検査：
サポートできるサービスの個数はエンドノードごとに変化する。
ターゲットサービスの仕事負荷は、現在のエンドノードの仕事負荷と組み合わせられるべきであり、新たなＲＤＭＡセッションが確立されるべきかどうかを判断すべきである。
サービスは、関連したユーザに応じて考慮することができる。
例えば、ＱｏＳ／サービスレベルの目標ベースのポリシーは、サービス課金、公平目的でのエンドノード（または複数のエンドノード）およびファブリックにおける他のアクティビティに対するアクセス量等のユーザ属性に応じて考慮することができる。
アプリケーションのプロセッサセット（プロセッサを含めて、アプリケーションが実行される利用可能な計算素子のサブセット）には、ＲＮＩＣ／資源のサブセットおよびＱｏＳ、すなわち、サービス（個数およびタイプ）の選択、ターゲットＲＮＩＣ等を割り当てることができる。
これを所与のプロセッサセットについて最適化して、システム自体におけるアクセスを改善することができる。
−所与のサービス用のＣＰの検査：
所与のＣＰの促進されるセッションの個数は、サービスごとにもしくはサービスを集約したものごとに制限することもできるし、サービスユーザおよびそのユーザによって実行されているトランザクションタイプと組み合わせて（例えば、ブラウジング対トランザクションサービス）制限することもできる。
−ＡＰの試験：
十分な資源が特定のＡＰに利用可能でなければならない。
サービスを提供できる複数のターゲットＡＰが存在する場合がある。
多くのエンドノードのうちの１つが、関連したサービスを提供できる場合があり、この関連したサービスは、任意の個数のＲＮＩＣにわたる場合がある。
ＲＮＩＣは、互いに統一性がある場合、集約グループとして取り扱うことができる。

図１３は、インバウンドＲＮＩＣ１０５（＊）が選択される例示のポートマッピングポリシー管理のシナリオを示す図である。
図１３に示すように、ＡＰ２０２は、２つ以上のＲＮＩＣ１０５（＊）を含むことができる。
ＰＭＳＰ２０４がＣＰ２０１によって開始されたポートマッパ要求を受信した場合において、受信したＡｐｌＰａｄｄｒ１１０９が、例えばＲＮＩＣ１０５（３）といった特定のＡＰ ＲＮＩＣと１対１に一致するものであるとき、ＡＰ２０２ハードウェアは、特定されたものとみなすことができる。
受信したＡｐｌＰａｄｄｒ１１０９が、Ｎ個の受諾ピアのＲＮＩＣ１０５（＊）と１対Ｎ対応を有する場合、ＡＰ２０２にローカルなポリシーは、どのＲＮＩＣ１０５（＊）を選択するかを判断する。
いずれの場合も、ＰＭＳＰ２０４は、ＰＭＡ１２０２とコンタクトし、さまざまな判定基準を使用してサービスを促進すべきかどうかを判断する。
これらローカルなポリシー判定基準には、以下で詳述するように、例えば、利用可能なＲＮＩＣ属性／資源、サービスＱｏＳ要件、ならびに、ＡＰエンドノードの稼動中の負荷および特定のサービスがエンドノードの負荷に及ぼす影響が含まれ得る。

ＰＭＡ１２０２が、どの判定基準がローカルポリシーの決定に利用可能であるかを判断した後、ＰＭＳＰ２０４は、開始されるサービスを促進すべきかどうかを判断するために、当該サービスをＰＭＡに通知する。
そのサービスが促進されるものである場合、ＰＭＳＰ２０４は、ハードウェア（ＲＮＩＣを論理的に特定するＩＰアドレスを介して）およびマッピングされたポート（ＲＤＭＡリスンポート）を特定して、ＰＭＡｃｃｅｐｔメッセージで返す。
ＰＭＳＰ２０４は、所与のサービスの適切なハードウェアを特定すると、この情報をキャッシュして、多数のセッションを予約することができる（確立または予約されたこれら多数のセッションはＰＭＡ１２０２が追跡することができる）。
ＰＭＳＰ２０４は、ハードウェアを特定すると、そのハードウェアの関連資源のすべておよび実行ノードも特定して、その後の接続要求（例えば、ＴＣＰ ＳＹＮ）を迅速に処理することを可能にすることができる。
これらのハードウェア関連資源には、接続状況、メモリマッピング、ＱｏＳ目的のスケジューリングリング（scheduling ring）等が含まれる。
ＰＭＳＰ２０４は、資源をキャッシュまたは予約すると、新たなポートマップ要求ごとにＰＭＡ１２０２と相互作用することを回避でき、単に、自身のキャッシュから動作して、マッピング要求を完了することができる。

ＰＭＡ１２０２は、ＡＰ２０２と協力して、その後のＲＤＭＡセッションの確立用に資源を予約することができる。
ポートマッピングオペレーションが成功すると、ＰＭＳＰ２０４は、適切なＡｐｌＰａｄｄｒ１１０９、および、ＡＰポートフィールド１１０５で示されたサービスポート１０３（＊）を有するＰＭＡｃｃｅｐｔメッセージ３０２を返す。

図１４は、単一のターゲットＩＰアドレスが、複数のＲＮＩＣ１０５（＊）を表すのに使用される例示のポートマッピングポリシー管理のシナリオを示す図である。
図１４では、接続ピア２０１（またはＣＰ２０１のＰＭクライアント２０３）は、ＡＰ２０２における一意のＡＰ ＩＰポートマッピングアドレスをターゲットにする。
集中化ＰＭＳＰ２０４（またはＡＰ２０２にローカルなＰＭＳＰ）が、ポートマッピング要求を受信し、ローカルまたは中央のＰＭＡ１２０２に問い合わせを行って、アプリケーション１０１を促進するかどうかに関するローカルポリシーを決定し、促進する場合には、どのＲＮＩＣ１０５（＊）を使用すべきかを決定する。
ＰＭＡ１２０２は、資源マネージャ１２０３と情報を交換して、ローカルポートマッピングポリシーを決定することができる。

ＰＭＳＰ２０４は、このように決定されたポリシーを適用して、図１４のＣＰ２０１によって示された単一のエンドノード内の複数のＲＮＩＣから適切なＲＮＩＣ１０５（＊）を選択する。
この例では、単一のＩＰアドレスがＡＰ２０２によってアドバタイズされるものと仮定し、そのアドレスはＲＮＩＣ１０５（１）およびＲＮＩＣ１０５（２）のＩＰアドレスを集約するのに使用されるものと仮定する。
ＣＰ２０１が、ポートマッピング用のＡＰ ＩＰアドレス１．２．３．４をターゲットにすると、ＰＭＳＰ２０４は、ＩＰアドレスがターゲットＩＰアドレスに集約されたＲＮＩＣ１０５（＊）のうち適切なものを選択する。
次に、ＣＰ２０１は、ＰＭＡｃｃｅｐｔメッセージ３０２のＡｐｌＰａｄｄｒ１１０９を、選択されたＲＮＩＣ（例えば、図１４のＲＮＩＣ１０５（１））の対応するＩＰアドレスに設定し、適切なＡｐｌＰａｄｄｒ１１０９を有するＰＭＡｃｃｅｐｔメッセージ３０２でＣＰ２０１に応答して、ＣＰ２０１とＡＰ２０２との間の一意のＲＤＭＡポートの関連付けを作成する。

図１５は、複数のＲＮＩＣ１０５（＊）が、異なるエンドノードに存在する例示のポートマッピングポリシー管理のシナリオを示す図である。
図１５に示すエンドノードの双方は受諾ピア２０２であるが、本明細書で説明するように、適切なＲＮＩＣ１０５（＊）を選択することは、異なるエンドノードに複数のＲＮＩＣを有するＣＰ２０１またはＡＰ２０２のいずれにも適用可能である。
ポートマッピングポリシーが最適なエンドノードによって導出され、それによって、例えば、アプリケーションインスタンスまたはＱｏＳベースのパス選択の機能を起動することができる。

図１５では、単一の集約ＩＰアドレスがＡＰ２０２によってアドバタイズされる。
図１５に示すように、エンドノードの受諾ピア２０２（１）および２０２（２）は、１．２．３．４の集約ＩＰアドレス（ＡｐｌＰａｄｄｒ１１０９）を有し、そのＲＮＩＣ１０５（１）〜１０５（４）は、それぞれ１．２．３．１２３、１．２．３．１２４、１．２．３．１２５、および１．２．３．１２６のＩＰアドレスを有する。
受諾ピア２０１がＰＭＲｅｑメッセージ３０１を受信すると、関連したＰＭＳＰ２０４は、ローカル／集中化ＰＭＡ１２０２および／または資源マネージャ１２０３を含む１つまたは２つ以上のポリシー管理エンティティと協力して、最適なエンドノードおよびＲＮＩＣ１０５（＊）を決定する。
この例では、矢印１５０１によって示すように、ＩＰアドレス１．２．３．１２５を有し、ＡＰ２０２（２）に存在するＲＮＩＣ１０５（３）が、最適なＲＮＩＣ／エンドノード対を構成する。

複数の接続ピア２０１（＊）に複数のＲＮＩＣが存在する場合、最適なＣＰ２０１（図１５に図示せず）は、所与のエンドノードで実行されているアプリケーションが決定することができ、ＰＭＡ２０４、ＰＭＡ１２０２、および／または資源マネージャ１２０３を含むポリシー管理エンティティによって選択されるように、ターゲットサービス、サービス／システムＱｏＳ、ＲＮＩＣ資源等の組み合わせを使用して、最適なＲＮＩＣ１０５（＊）が決定される。

［トランスペアレントなサービス移動］
ファブリックへのＲＮＩＣアクセスは、ケーブルの分離または故障、スイッチの故障等を含む多くの理由によって機能しないことがある。
機能しないＲＮＩＣ１０５（＊）がマルチポートであり、他のポートが、対象となるＣＰ２０１／ＡＰ２０２にアクセスできる場合において、十分な資源がそのＲＮＩＣの当該他のポートに存在するとき、フェイルオーバをＲＮＩＣ内に含めることができる。
例えば、図１５の図では、受諾ピア２０２（２）のＲＮＩＣ１０５（３）が機能しなくなると、破線の矢印１５０２によって示すように、同じエンドノード（例えば、接続ピア２０２（２））のＲＮＩＣ１０５（３）からＲＮＩＣ１０５（４）へ移動することによって、フェイルオーバを実行することができる。

マルチポートＲＮＩＣ内にフェイルオーバを実行するのに十分な資源がない場合、ＲＮＩＣの状態を同じエンドノードの別のＲＮＩＣへ移動させることができる。
ローカルなフェイルオーバが可能でなく、資源を十分に有しないＲＮＩＣが稼動中である場合、ＲＮＩＣの状態を１つまたは２つ以上のスペアのＲＮＩＣへ移動させることができる。
これらスペアのＲＮＩＣは、アイドル／スタンバイのＲＮＩＣ、または、コンフリクトを起こしていない利用可能な資源状態を有するアクティブなＲＮＩＣのいずれかである。

ターゲットのフェイルオーバＲＮＩＣは、Ｎ個のアクティブなＲＮＩＣに対して単一のスタンバイのＲＮＩＣが存在する場合には、Ｎ＋１の配置で構成することもできるし、複数（Ｍ個）のスタンバイのまたはアクティブ／利用可能なＲＮＩＣが存在する場合には、Ｎ＋Ｍ個のＲＮＩＣの構成とすることもできる。
スタンバイのＲＮＩＣは、その追加ポートがアクティブでなく、したがって、ＲＮＩＣの残りと衝突なしで使用できるマルチポートＲＮＩＣとすることができる。
この場合、すべてのＲＮＩＣは、アクティブの場合があるが、すべてのＲＮＩＣのすべてのポートがアクティブであるとは限らない。

図１５の例には、エンドノード間のフェイルオーバも示されている。
図１５の例では、受諾ピア２０２（２）におけるＲＮＩＣ１０５（３）は、矢印１５０１によって示すように、最初にＣＰ２０１によってターゲットとされる。
この例では、最初のターゲットＲＮＩＣ１０５（３）の故障によって、ＡＰ２０２（２）から異なるエンドノードのＡＰ２０２（１）へのＲＮＩＣの移動が引き起こされる。
これによって、破線の矢印１５０３によって示すように、ＣＰ２０１は、ＡＰ２０２（１）のＲＮＩＣ１０５（１）をターゲットとすることが可能になる。
エンドノード間のフェイルオーバは、ＲＮＩＣの移動に加えて、アプリケーション／セッション状態の移動を必要とする。
アプリケーションは、ターゲットのフェイルオーバエンドノードにおいてトランスペアレントに再開することができる。
このアプリケーションの再開は、アプリケーションの状態を使用して、故障前の優れたオペレーションを再生することによって行われ、エンドユーザが遭遇するサービスダウン時間が最小となるように行われる。

図１６は、予想された通信エンドノード、すなわち接続ピア２０１および受諾ピア２０２のそれぞれに関連した例示の１組のポリシー管理関数Ｆ１およびＦ２を示す図である。
関数Ｆ１は、ＰＭクライアントのポリシー管理関数であり、関数Ｆ２は、ＡＰ２０２に関連したＰＭＳＰ２０４のポリシー管理関数である。
関数Ｆ１およびＦ２は、各ポリシー管理エージェント５０１（１）および５０１（２）を介して実施される。
ポリシー管理エージェント５０１（１）および５０１（２）は、それぞれＰＭクライアント２０３のポートマッピングポリシーおよびＰＭサービスプロバイダ２０４のポートマッピングポリシーを実施する。
例示の実施の形態では、各ＰＭＡ５０１（＊）は、スタンドアロンオペレーションを行うことができるが、付加的な知能または制御が必要とされる場合には、資源マネージャ１２０３等の外部資源管理エンティティから入力を受け付けることもできる。
図１６の実施の形態では、システムデータおよびポリシールールを含む入力パラメータ１６０１は、資源マネージャ１２０３によってアクセス可能なパラメータストレージ１６００に記憶される。
スタンドアロンオペレーションでは、ＰＭＡ５０１（＊）が外部ポリシー管理源からの入力なしにポリシー管理を実施する場合、入力パラメータ１６０１は、ＰＭＡ５０１（＊）にとってローカルまたはリモートのいずれかでアクセス可能なメモリ１６０２（＊）に記憶することができる。

ＡＰ２０２またはＣＰ２０１は、入力パラメータ情報を使用して、ＰＭＡ５０１（＊）と共にポートマッピングポリシーを実施することができる。
ＣＰ２０１は、ＡＰ２０２とほぼ同じように入力パラメータ情報を使用して、例えば、サービスを促進すべきかどうか、どの資源（エンドノード、ＲＮＩＣ等）を使用するのか、促進するインスタンス数、ＰＭが資源をキャッシュ／予約することが可能かどうか等を特定する。
通信チャネルのいずれかの側で使用できる入力パラメータ１６０１（すなわち、接続ピア２０１または受諾ピア２０２のいずれかに適用可能なパラメータ）の例には、次のものが含まれる。
−例えばＲＮＩＣといった通信デバイスの個数。
−アプリケーション／サービス属性、および、所与のエンドノード／デバイスでそれらアプリケーション／サポート属性をサポートする能力。
例えば、分散データベースセッションを作成することによって、ウェブサーバセッションとは異なるレベルの資源（例えば、ＣＰＵ、メモリ、Ｉ／Ｏ）が必要となることがある。
特定のサービスに関する情報を使用して、一定の資源をどのように割り当てるべきかを決定することができ、また、実行の優先度、サービスのロケーション（例えば、エンドノードおよびデバイス）を決定することもできる。
−各エンドノードおよび各エンドノードデバイスにおける現在の仕事負荷。
−サービスがトランスペアレントな高可用性サービスを必要とするかどうか。
例えば、フェイルオーバ時の資源の再バランシングが、資源の可用性に応じて実行される場合に、２つ以上のデバイス間のトランスペアレントなフェイルオーバ。
−デバイスリンクの帯域幅および予想された資源要件。

各関数Ｆ１／Ｆ２の入力パラメータ１６０１は、ポートマッピング管理ポリシーによって決定された属性、および、現在のタイプのセッションのサービスデータレートである。
また、入力パラメータ１６０１は、ポートマッピングパラメータの永久的なまたは長期間のキャッシュもサポートして、高速接続の確立の使用を可能にすることもできる。
上述した入力パラメータは例であり、本システムと共に使用できる入力パラメータは本明細書で具体的に説明したものに限定されるものではないことに留意すべきである。

（ＰＭクライアント２０３／ＣＰ２０１の）関数Ｆ１および／または（ＰＭＳＰ２０４／ＡＰ２０２の）関数Ｆ２は、通常、対応するＰＭＡ５０１（＊）が１組のポリシー管理入力パラメータ１６０１を使用して実施する。
この１組のポリシー管理入力パラメータ１６０１は、ポリシールールを含み、例えば、資源マネージャ１２０３によって提供される。
各入力パラメータ１６０１は、簡単な値とすることができ、例えば、整数量で示された利用可能なメモリ量とすることができる。
あるいは、入力パラメータは、可変とすることもでき、かつ、所与の資源のアプリケーション使用要件、および、通信対アプリケーション実行に適用できる特定の資源の相対的な量を含む因子を考慮する関数（以下では、「主（primary）」関数Ｆ１およびＦ２と区別するために「サブ関数（sub-function）」と呼ぶ）によって記述することもできる。
各ポリシールールは、関数（例えば、ＣＰの場合、Ｆ１）に関連付けられ、１つまたは２つ以上の関連したサブ関数を有することができる。
これら１つまたは２つ以上の関連したサブ関数は、関数Ｆ１またはＦ２の一部として評価されて、適用可能な入力パラメータ１６０１がポートマッピングをサポートするかどうかを判断するものである。

ポリシールールおよび他の入力パラメータ１６０１を入力として使用して、関数Ｆ１および／またはＦ２を評価することにより、他の要求またはイベントしきい値を更新してターゲットサービスの現在の状態を反映できるように、影響を受けたサービスの状態の変化が示される。
この新たなターゲットサービス状態は、資源が制約されるようになる場合、仕事負荷を再バランシングすべきであることをポリシーが示す場合等に、他のイベントをトリガすることもできる。
したがって、ＰＭＡは、ネットワークコンポーネントの故障によっては引き起こされないトランスペアレントなサービス移動の実行を援助することができ、また、ＩＰ差別化サービス（IP-differentiated service）パラメータを返すこともできる。
このＩＰ差別化サービスパラメータには、特定のスケジューリングリングへの所与のセッションの割り当て、サービスレート等が含まれ得る。

上記に示したように、ＰＭＡ５０１（＊）は、返されるＩＰアドレスを単に変更することによって、サービスを異なるＲＮＩＣへ移動させることができ、したがって、異なる可能性のあるエンドノードへ移動させることができる。
これは、進行中の負荷バランシングの一部として行うこともできるし、過度の負荷の検出に応答して行うこともできる。
また、ＰＭＡは、セッションをスケジューリングリング等に割り当てて、ＰＭＡが消費できる資源量を変更し、負荷を削減してＳＬＡ要件に従い既存のサービスまたは新たなサービスをより良くサポートすることもできる。

ポリシールールは、さまざまなシステム資源および要件の態様から構成することができる。
これらの資源および要件の態様には、エンドノード内の資源および要件の態様、関連ファブリック、および／またはアプリケーションが含まれる。
ポリシールールを定式化する際に考慮できるシステムの態様には、以下のものが含まれる。
−ターゲットサービスが必要とする接続の個数をサポートするＲＮＩＣの能力。
各接続は、所与のサービスに関連付けられるが、アプリケーションは、所与の時間比率において、指定された性能レベルでアプリケーションが稼動するサービスレベルの目標を満たすために、複数の接続を必要とすることがある。
ポリシールールを実施することによって、サービスが所与の性能レベルで常に稼動できるように、特定のサービスをサポートするかどうか、または、そのサービス用に多数の接続を予約するかどうかを判断することができる。
ポリシールールが常駐し、したがって、アクセスする際に待ち時間を被らないように、当該ポリシールールは、ＲＮＩＣに永続的に保持されるいくつかの接続状況を割り当てるのに使用することができる。
−メモリマッピング資源。
これらの資源は、制限することもできるし、オプションとしてキャッシュすることもできる。
ＰＭＡは、どれだけの量のメモリマッピング資源が必要とされるか、および、サービスをサポートできるかどうかを決定することができる。
−スケジューリングリング、所与のスケジューリングリングにおいてサービスの提供を受ける接続の個数、（異なる優先度の接続は、通常、異なるスケジューリングリングに分離されるので、リング内およびスケジューリングリング間の双方の）アービトレーションレート等のＱｏＳ資源。
ＰＭＡは、他の接続に悪影響を与えることなく、新たな接続の追加が可能かどうかを判断することができると同時に、その新たな接続が自身のＳＬＡ要件を満たすことを確実にすることができる。
−サービスの帯域幅要件。
ポートマッピング用に選択されたＲＮＩＣは、ポートごとにサービスのニーズを満たす関連した帯域幅を有しなければならない。
関連して考慮すべき事項は、利用可能な帯域幅のどれだけの量が現在、他の接続／サービスによって消費されているかである。
−ＲＮＩＣがマルチポートである場合、帯域幅や待ち時間等のさまざまな属性に基づいて、どのポートを使用すべきであるかについて判断しなければならない。
−ＲＮＩＣが、ＰＣＩ−ＸやＰＣＩ Ｅｘｐｒｅｓｓ等のローカルＩ／Ｏ技術を介してアタッチされる場合、そのＩ／Ｏの関連した帯域幅および動作特性が考慮されるべきである（すなわち、リンクの効率、および、ＲＮＩＣがデバイスの必要な性能を発揮するかどうか）。
−サービスに利用可能なエンドノードメモリ帯域幅およびサービスレートも重要な態様である。
サービスのＣＰＵ消費は低い場合があるが、依然として、メモリ（および、Ｉ／Ｏがアタッチされる場合にはＩ／Ｏ帯域幅）の消費量は大きい場合があり、これは、そのエンドノードの他のサービスを妨害する可能性がある。
−所与のエンドノードに複数のＲＮＩＣが存在する場合、ＰＭＡは、（何がどこで実行されているかを追跡することにより）各ＲＮＩＣの状態を評価して、新しい最適なサービス配置を決定することができる。
また、ＰＭＡは、各エンドノードの状態を追跡することもできる。
各サービスは、エンドノードに異なった影響を与えることがある。
ミドルウェアをオプションで使用して、例えば、単位時間ごとに発生するサービストランザクションの個数を追跡することにより、各エンドノードの状態を追跡することができる。
トランザクションレートが所与のレベル未満に低下すると、エンドノードは過負荷になるおそれがあり、サービスを他のエンドノードへ移動させることによるか、低い優先度のサービスのスケジューリングレートを低減させることによるか、または、その状況に注意して、過負荷が軽減されるまで新たなサービスが確実に開始されないようにすることによって、負荷バランシングを行うことができる。
他の関連したポリシーは、各ＲＮＩＣが、負荷バランシング技法を使用して新たな接続を適切に割り当て、所与のサービスのＮ個のインスタンスまたはＭ個の異なるサービスをサポートできることを単に示すことができるものである。

ポリシールールの例として、要求されたサービスの帯域幅要件を扱うルール「Ｒ１」を考える。
このようなルールは、「Map the port (to RNIC) only if the RNIC has the associated bandwidth per port to meet the service needs.（ＲＮＩＣがポートごとにサービスのニーズを満たす関連した帯域幅を有する場合にのみ、ポートを（ＲＮＩＣへ）マッピングする。）」等の英語の説明を有することがある。
ルールＲ１では、以下の３つの関連した入力パラメータがある。
ｘ１＝サービスの帯域幅要件
ｘ２＝マッピングされるＲＮＩＣの帯域幅
ｘ３＝他の接続／サービス用にＲＮＩＣ（Ｎ）によって現在消費されている帯域幅

各入力パラメータ１６０１は、ポートをマッピングできることをポリシールールが示すかどうかを判断する関連したサブ関数を有することができる。
例えば、以下の関数を評価することによって、マッピングされる有効なポートを決定することができる。
Ｆ１＝Ｆ（Ｘ）＋Ｇ（Ｙ）＋Ｈ（Ｚ）＋…
ここで、関数Ｆ（Ｘ）、Ｇ（Ｙ）、Ｈ（Ｚ）…はサブ関数であり、Ｘ、Ｙ、およびＺは入力パラメータ１６０１（ポリシールールを含む）であり、各サブ関数は、関連したパラメータまたはルールが、要求されたポートマッピングサービスをサポートできるかどうかを検査するものである。
この例では、評価されたサブ関数の結果は論理ＯＲオペレーションを介して結合される。
これによって、ポートをマッピングすべきことを示すサブ関数があれば、ポートマッパワイヤプロトコルを介して戻る利用可能なポートを見つけ出すのに、参照関数（look-up function）を使用できるようになる。

関数Ｆ１／Ｆ２は、入力として、広範囲の入力パラメータ１６０１を取ることができる。
この入力パラメータ１６０１には、エンドノードタイプ、エンドノード資源、ＲＮＩＣタイプ／資源、アプリケーション属性（タイプ、優先度等）、ＲＮＩＣ、エンドノード、またはアタッチされたネットワークにおけるリアルタイム資源／負荷等が含まれる。
関数（Ｆ１またはＦ２）は、最良に適合したＣＰ／ＡＰ、ＲＮＩＣ、ポートマッピング等を返す。
各関数Ｆ１／Ｆ２は、通常、ＰＭＡ５０１（＊）によって実施されるが、ＰＭＡが使用されない環境では、ＰＭＳＰ２０４またはＰＭクライアント２０３によって実施することができる。

エンドノードに対するサービスの影響を求めるために、エンドノードは、所与の性能レベルで動作するのにどの資源が必要とされるかを判断できる必要がある。
１つの解は、アプリケーションレジストリ１６０２を使用して、サービス資源要件を追跡することである。
このようなレジストリまたは等価のアプオリな知識が利用可能である場合、ポリシー管理エージェント５０１（＊）は、そのレジストリの情報を使用して、ポートマッパ要求で特定されたサービスを検査することができ、サービスを促進すべきかどうかを判断することができる。
レジストリ１６０２は、促進されるサービスポートの簡単なテーブルとすることができる。
あるいは、ＰＭＡが、サービスの現在の集まりが実行されていることを検査することができるように、かつ、この新たなサービスインスタンスがあらゆる既存のＳＬＡ要件を満たし続ける間、動作できるかどうかを判断できるように、レジストリ１６０２は、よりローバストなものとすることができ、ＰＭＡに付加情報を提供することができる。

図１７は、ポートマッピング要求を処理する際に実行される例示の１組のハイレベルなステップを示すフローチャートである。
図１７に示すように、ステップ１７０５では、ポートマッピング要求がＰＭＡ５０１（＊）によって受信される。
ステップ１７１０では、ＰＭＡがＰＭクライアント／ＰＣまたはＰＭＳＰ／ＡＰに代わって機能しているかどうかについての判断が行われ、次いで、対応するステップ１７１５またはステップ１７２０が実行されて、各関数Ｆ１またはＦ２が実施される。
ステップ１７３０では、サブ関数（または、他の場所に記憶されている場合には、サブ関数のロケーションの印）を含めて、対応するＰＭＡ５０１（＊）の適用可能なルール１６０１（１）のリスト、および、追加された入力パラメータ１６０１（２）が、パラメータストレージ１６００に記憶された入力パラメータ１６０１から配置される。

ステップ１７３５では、適用可能なルール１６０１（１）およびそれ以外の対応する入力パラメータ１６０１（２）が適切な関数Ｆ１またはＦ２に適用される。
関数Ｆ１またはＦ２が評価された後、有効なポートマッピングが存在すると判断されると、ステップ１７４０で、以下の情報の一部またはすべてを含む応答が、対応するＰＭＳＰ／ＡＰまたはＰＭクライアント／ＣＰに返される。
−ＣＰ２０１によって使用されるターゲットＩ／Ｏデバイスまたは通信チャネル、ならびに、各デバイス／チャネルが複数のＩＰアドレスを割り当てている可能性があるため、使用されるＡＰターゲットＩＰアドレス。
−ＣＰ２０１とＡＰ２０２との間の通信に使用されるターゲット送信元およびリスンソケットポート。

図１８は、図１７のステップ１７３５を達成するのに実行される例示の１組のステップを示すフローチャートである。
図１７のステップ１７３５では、適用可能なルール１６０１（１）およびそれ以外の対応する入力パラメータ１６０１（２）が適切な関数Ｆ１またはＦ２に適用される。
図１８に示すように、ステップ１８０５では、マッピングされたポートが利用可能であるかどうかを判断するチェックが行われる。
ＲＮＩＣポートが現在利用可能でない場合には、その事実を示すＰＭＤｅｎｙメッセージがステップ１８１０で返され、このポートマッピング要求についてのルールの処理は終了する。
ＲＮＩＣポートが現在利用可能である場合には、ステップ１８１５で、各適用可能なルール１６０１（１）について、関連したサブ関数が評価されて、入力パラメータがポートマッピングをサポートするかどうかが判断される。

ステップ１８１７では、少なくとも１つのルールが満たされる場合、適用可能なルールの処理がステップ１８１８で続けられ、そうでない場合、ＰＭＤｅｎｙメッセージがステップ１８１０で返される。
ステップ１８１８では、要求されたポートマッピングオペレーションの資源要件が、その後のポリシーオペレーションをガイドしてレースの故障（race failure）を回避するために記憶される。
次に、マッピングされたポートに使用される特定のＲＮＩＣインスタンスおよびＩＰアドレスがステップ１８２０で特定される。
ステップ１８２５では、マッピングが有効である期間を示すＰＭＴｉｍｅの値が決定される。

ステップ１８３０では、マッピングがキャッシュされること、または、ＰＭＴｉｍｅによって指定された制限時間の間有効であることを示す応答が作成され、ステップ１８３５では、ポートマッピング要求が受諾されたことを示すＰＭＡｃｃｅｐｔメッセージが返される。

ＰＭクライアント／ＣＰの例示の関数Ｆ１の擬似コードを以下に示す。
［ＰＭクライアント／ＣＰの例示の擬似コード］
If (ターゲットＣＰが、利用可能な資源を備えた１つまたは２つ以上のＲＮＩＣを有する) then {
If (VALID(RNIC_id = F(アプリケーション(B/W要件、優先度、メモリマップ資源、必要な接続数)) {
// ポートマッピングオペレーションの確立を試みることができる
CP_connection = SELECT_CONN(RNIC_id);
予測された（projected）資源要件を記録する;
ポートマッパ要求を送信し、ポートマッパプロトコルを続ける;
} else {
// プロトコルの促進を続けることができないため、通常の接続確立パスを使用する
} else {
// プロトコルの促進を続けることができないため、通常の接続確立パスを使用する
・・・
}
ここで、F(アプリケーション(B/W要件、優先度、メモリマップ資源、必要な接続数)は、１つまたは２つ以上のパラメータ１６０１を入力として受け取るサブ関数であり、入力パラメータもサブ関数とすることができる。

関数Ｆ１の上記コードに類似した関数Ｆ２の１組のロジックが、以下に示すように、ＰＭＳＰ／ＡＰによって実行される。
［ＰＭＳＰ／ＡＰの例示の擬似コード］
If (潜在的なターゲットＡＰが、利用可能な１つまたは２つ以上のＲＮＩＣ資源と共に存在する) then {
If (VALID(RNIC_id = F(アプリケーション(入力パラメータ)) {
// ポートマッピングオペレーションの確立を試みることができる
Returned_AP_IP_addr = SELECT_AP_IP(ポートマッパ要求ＩＰアドレス);
AP_RNIC = SELECT_AP_RNIC(Returned_AP_IP_addr);
予測された資源要件を記録する;
ポートマッパ応答を送信し、ポートマッパプロトコルを続ける;
} else {
// プロトコルの促進を続けることができないため、通常の接続確立パスを使用する
} else {
// プロトコルの促進を続けることができないため、通常の接続確立パスを使用する
・・・
}

代替的な実施の形態では、関数Ｆ１およびＦ２は、適用可能な入力パラメータ１６０１を評価し、これらの関数は、論理式を評価するのではなく、単に、それらの適切な計算およびマッピングを実行して、ポートを直接返す。

ポートマッピングポリシー管理は、ローカルとしてのみまたはグローバルとしてのみ本システムで実施することもできるし、双方のハイブリッドとして本システムで実施することもでき、それによって、ローカルな最適化を可能にすると同時に中央管理の利益を得ることが可能になる。
例えば、この場合、ローカルホットプラグイベントが、利用可能な資源を変更でき、中央ポリシー管理エンティティがイベントに反応する必要がない。
ポリシー管理は、さまざまな方法で実施することができるが、その実施態様は、メッセージパッシングインターフェースで促進することができる。
このメッセージパッシングインターフェースは、ポリシー管理機能を複数のエンドノードにわたって分散させることを可能にし、既存の管理基盤の再利用を可能にする。

本システムでは、その範囲から逸脱することなく、一定の変更を行うことができる。
上記説明に含まれるすべての事項または添付図面に示すすべての事項は、例示として解釈されるべきであり、限定する意味に解釈されるべきでないことが留意されるべきである。
例えば、図２および図５〜図１６に示すシステム構成は、それら図に示すコンポーネント以外のコンポーネントを含むように解釈することができ、それらコンポーネントは、他の構成で配置することができる。
図３Ａ、図３Ｂ、図４、図１７、および図１８に示す要素およびステップも、上述したシステムの趣旨から逸脱することなく、本明細書に説明した方法に従って変更することができる。

従来技術のネットワークのハイレベルアーキテクチャを示す図である。 本ポートマッパシステムの例示のハイレベルアーキテクチャの例示の実施の形態を示す図である。 ポートマッピングオペレーションを実施するための、ポートマッパサービスプロバイダとポートマッパクライアントとの間の例示の交換シーケンスを示す図である。 接続ピアと受諾ピアとの間の接続を確立するための、接続ピアと受諾ピアとの間の例示の交換シーケンスを示す図である。 アドレス／ポート解決を実行し、接続ピアと受諾ピアとの間の接続を確立する例示のＡＰＩ呼び出しシーケンスを示す図である。 ローカルポリシー管理エージェントを使用するポートマッピングの例示の構成を示す図である。 集中化ポリシー管理エージェントを使用する例示のポートマッピング構成を示す図である。 ポートマッピングが、ローカルＰＭクライアントおよびローカルポリシー管理エージェントによって接続ピアの代わりに実行される例示の一実施態様を示す図である。 接続ピアおよび受諾ピアがそれぞれローカルＰＭクライアント／ＰＭＳＰおよびローカルポリシー管理エージェントを使用する例示のポートマッピングの一実施態様を示す図である。 ＰＭクライアント／ＰＭＳＰが中央で管理される例示のポートマッピングの一実施態様を示す図である。 所与のサービスの特定のＡＰ ＩＰターゲットアドレスが集約アドレスである例示のポートマッピングの一実施態様を示す図である。 ポートマッパワイヤプロトコルによって使用されるポートマッパ要求メッセージの例示のフィールドを示す図である。 アウトバウンドＲＮＩＣが選択される例示のポリシー管理のシナリオを示す図である。 インバウンドＲＮＩＣが選択される例示のポリシー管理のシナリオを示す図である。 単一のターゲットＩＰアドレスが、複数のＲＮＩＣを表すのに使用される例示のポリシー管理のシナリオを示す図である。 複数のＲＮＩＣが、異なるエンドノードに存在する例示のポリシー管理のシナリオを示す図である。 予想された通信エンドノードのそれぞれに関連した例示の１組のポリシー管理機能Ｆ１およびＦ２を示す図である。 ポートマッピング要求を処理する際に実行される例示の１組のハイレベルなステップを示すフローチャートである。 図１７のステップ１７３５の期間中に実行される例示の１組のステップを示すフローチャートである。

符号の説明

２０１・・・接続ピア，
２０２・・・受諾ピア，
２０３・・・ＰＭクライアント，
２０４・・・ＰＭサービスプロバイダ，
２０４（Ｌ）・・・ポートマッピングサービスプロバイダ，
２０４（Ｃ）・・・ポートマッピングサービスプロバイダ，
２０５・・・ＴＣＰマッピング，
２０６・・・ＲＤＭＡマッピング，
２０７・・・従来のアドレス，
２０８・・・ＲＤＭＡアドレス，
２１０・・・ポートマッパプロトコル，
５０１（Ａ）〜（Ｄ）・・・ローカルポリシー管理エージェント，
６０１・・・集中化ポリシー管理エージェント，
１２０１・・・相互接続インターフェースライブラリ，
１２０２・・・ローカルまたは中央ＰＭＡ，
１２０３・・・資源マネージャ，
１６００・・・入力パラメータ，
１６０２（１），（２）・・・メモリ，
１６０２・・・アプリケーションレジストリ，

Claims (10)

1. アプリケーションによって指定されたＲＤＭＡ対応でないポート（１０３（＊））を、複数のエンドノード（１０２（＊））を含むネットワークのＲＤＭＡ対応のポート（１０３（＊））へマッピングするシステムであって、
   前記エンドノード（１０２（＊））のうちの第１のエンドノードに配置され、サービスポート（１０３（＊））を介してターゲットサービスを要求する接続ピア（２０１）と、
   前記エンドノード（１０２（＊））のうちの第２のエンドノードに配置され、前記サービスポート（１０３（＊））も配置されている受諾ピア（２０２）と、
   前記アプリケーションの要件を含めて、前記エンドノード（１０２（＊））内のシステム資源の態様および要件を記述した１組のポリシールール（１６０１（１））と、
   前記受諾ピア（２０２）の代わりにサーバとして機能するポートマッピングサービスプロバイダ（２０４）と、
   前記接続ピア（２０１）の代わりに前記ポートマッピングサービスプロバイダ（２０４）と通信し、前記ポリシールール（１６０１（１））によって示されたポートマッピングポリシーを実施するポートマッパクライアント（２０３）と
   を備え、
   前記接続ピア（２０１）は、前記ポートマッパクライアント（２０３）を介して、前記ポートマッピングサービスプロバイダ（２０４）と交渉して、前記アプリケーションによって指定された、ターゲットサービス用の前記サービスポート（１０３（＊））を、前記受諾ピア（２０２）が、前記ターゲットサービスにアクセスするために使用する関連したＲＤＭＡサービスポート（１０３（＊））に変換することによって、ポートマッピング機能を実行する
   システム。
2. 前記ポートマッピングサービスプロバイダ（２０４）は、前記受諾ピア（２０２）と同じ場所に配置される
   請求項１に記載のシステム。
3. 前記ポートマッピングサービスプロバイダ（２０４）は、複数の潜在的な受諾ピア（２０２）および接続ピア（２０１）に対して集中化される
   請求項１に記載のシステム。
4. 複数の受諾ピア（２０２）
   を含み、
   複数のローカルポリシー管理エージェント（５０１）
   をさらに備え、
   前記ポートマッピングサービスプロバイダ（２０４）および前記ローカルポリシー管理エージェント（５０１）のいずれかは、前記受諾ピア（２０２）と同じ場所に配置され、
   前記受諾ピア（２０２）の前記ローカルポリシー管理エージェント（５０１）は、前記ポートマッピングサービスプロバイダ（２０４）と通信して、ポートマッピングポリシーを実施し、前記ポートマッピング機能を実行する
   請求項１に記載のシステム。
5. 前記ローカルポリシー管理エージェント（５０１）のいずれか以外が、前記ポートマッパクライアント（２０３）と通信して、前記ポートマッピング機能の少なくとも一部を実行する
   請求項４に記載のシステム。
6. 前記ポートマッピングサービスプロバイダ（２０４）は、前記ポートマッピングサービスプロバイダ（２０４）と通信して、ポートマッピングポリシーを実施し、前記ポートマッピング機能を実行する集中化ポリシー管理エージェント（５０１）を使用して集中化される
   請求項１に記載のシステム。
7. 前記ポートマッピングサービスプロバイダ（２０４）と通信してポートマッピングポリシーを実施し、
   ポートマッピングを実行するポリシー管理エージェント（５０１）
   を含み、
   前記ポートマッピングサービスプロバイダ（２０４）は、前記ポリシー管理エージェント（５０１）と相互作用して、エンドノード特有のポリシーまたはサービス特有のポリシーを実施し、受諾ピア（２０２）に関連付けられ、
   前記ポートマッピングサービスプロバイダ（２０４）は、前記接続ピア（２０１）が、指定された受諾ピア（２０２）とのＲＤＭＡベースの接続を確立するために使用できるＲＤＭＡアドレスを返す
   請求項１に記載のシステム。
8. ポートマッピング要求において特定されたサービスを検査して、前記サービスがマッピングされるべきかどうかを判断するために使用される情報を含んだアプリケーションレジストリ（１６０２）
   を含む請求項１に記載のシステム。
9. 前記レジストリ（１６０２）は、マッピングされる潜在的なサービスポート（１０３（＊））のテーブルである
   請求項８に記載のシステム。
10. 前記ポリシールール（１６０１（１））は、一群のステップであって、
    前記ターゲットサービスを検査するステップであって、サポートできるサービスの個数をエンドノード（１０２（＊））ごとに決定するステップと、
    所与のサービスの前記接続ピア（２０１）を検査するステップであって、所与の接続ピア（２０１）の同時発生のマッピングされるセッションの個数を決定するステップと、
    前記ＡＰを検査するステップであって、それによって、十分な資源が所与の受諾ピア（２０２）に利用可能であることを保証するステップと
    から成る一群のステップのうち少なくともいずれかを含むシステム態様
    を含む請求項１に記載のシステム。

Images