JP5069356B2

JP5069356B2 - データ伝送ネットワークにおけるアドレス解決のための技術

Info

Publication number: JP5069356B2
Application number: JP2010534372A
Authority: JP
Inventors: オクタヴィアンパップ，; アンドラスサスザー，; アッティラミハリー，; ラーシュウェストベルイ，
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2007-11-26
Filing date: 2007-11-26
Publication date: 2012-11-07
Anticipated expiration: 2027-11-26
Also published as: ATE541402T1; WO2009068045A1; EP2274897B1; US20100272107A1; EP2274897A1; JP2011504697A

Description

本発明は、データ伝送ネットワークにおける宛先ノードをアドレスする技術に関する。具体的には、本発明は、データ伝送ネットワークにおけるアドレス解決、例えば、ＩＰｖ４ネットワークにおけるＡＲＰベースのアドレス解決のための技術に関する。

例えば、固定通信ネットワークおよび移動通信ネットワークのようなデータ伝送ネットワークでは、通常、重層的なやり方でデータ伝送機能を構成する。しばしば、通信プロトコルの設計のため、機能レイヤは、少なくとも部分的にはいわゆるＩＳＯ／ＯＳＩ参照アーキテクチャに従って構成される。このアーキテクチャで、レイヤ２即ちリンク・レイヤには、ネットワークの物理ノード間でデータを転送することを担う機能を備える。レイヤ３即ちネットワーク・レイヤは、エンド・ツー・エンドに、即ち、通常多数のノードまたはホップを介して、データ・パケットを転送することを担う。例として、ネットワークは、レイヤ２機能に対してＩＥＥＥ８０２．ｘ機構（例えば、イーサネット（登録商標））を、そしてレイヤ３機能に対してＩＰ（インターネット・プロトコル）を配備してもよい。

ホストが次のホップにＩＰパケットを送信したい場合、ＩＰパケットをレイヤ２パケットに入れなければならない。レイヤ２ヘッダは、レイヤ２ＭＡＣ（媒体アクセス制御）アドレス、即ち、次のホップのネットワーク・アダプタの特定の物理アドレス（デバイス・アドレス、ハードウエア・アドレス）を含まなければならない。従って、送信ホストは、宛先ノードのネットワーク・アドレスに関連する物理アドレスを決定する必要がある。この決定を“アドレス解決”と呼ぶ。この目的のため、ホストは、複数の宛先用に個別の物理アドレスと個別のネットワーク・アドレスとの関連のリストにアクセスしてもよい。例えば、ＡＲＰ（アドレス解決プロトコル）を採用するＩＰｖ４環境では、ＩＰアドレスのＭＡＣアドレスへのマッピングを含む、“ＡＲＰキャッシュ”にアクセスしなければならない。

ホストが次のＩＰホップにパケットを送信したい場合で、ＡＲＰキャッシュにＩＰアドレスを見つけ出さない場合、ローカル物理ネットワーク、例えば、ＬＡＮ（ローカル・エリア・ネットワーク）内で“ＡＲＰ要求”を同報送信する。ＡＲＰ要求には、ホストがＭＡＣアドレスを要求するＩＰアドレスを含む。そのネットワーク・アドレスを自分のものとして認識するローカル・ネットワークのノードは、その物理アドレス（即ち、イーサネット（登録商標）ＬＡＮのＭＡＣアドレス）を含む“ＡＲＰ応答”（“ＡＲＰ応答”）を送信元に対して送信する。ホストは、ＩＰアドレスとそのＡＲＰキャッシュの受信物理アドレスとの関連を記録し、送信するパケットにその関連を適用する、即ち、ＭＡＣフレーム・ヘッダに物理アドレスを挿入する。ここではＩＰｖ４／ＡＲＰ環境のためにアドレス解決を概観したが、例えばＩＰｖ６／ＮＤ（近隣探索）環境のような、その他の環境において、同様な原理が適用できる可能性がある。

柔軟なネットワーク構成では、アドレス解決機構に加えて、リンク・レイヤとネットワーク・レイヤとの間の更なる相互運用を提供できる可能性がある。この点に関して広く採用されている技術は、“プロキシＡＲＰ”機能である。ノード、例えばルータを、それ自身の物理アドレスを供給することにより別のノードを対象としたＡＲＰ要求に答えるよう構成する。別のノードのふりをすることで、そのルータは、その他のノードにパケットを転送する責務を受け入れる。プロキシＡＲＰにより、プロキシＡＲＰルータで分離されている二つ以上の物理ネットワークに対して、単一ネットワーク・アドレスを使用可能となる。言い換えれば、プロキシＡＲＰ機構で、特定の物理ネットワークのホストは、例えば、デフォルト・ゲートウエイ経由で経路を構成する必要なしに、遠隔物理ネットワークのホストに到達できる。例えば、後で遠隔物理ネットワークを追加してしまってもよく、または、セキュリティ等の理由でネットワークを拡大するため、単一物理ネットワークを細分してもよい。プロキシＡＲＰで、ルーティング表を変更するための要求なしに、例えば、アップストリーム・ルータで、物理ネットワークを簡単に拡張できる。

ルータにおけるプロキシＡＲＰ機能は以下のように動作する。ルータが同報送信されたＡＲＰ要求を受信した場合、そこに表示されたネットワーク・アドレスを、ルータのルーティング表のネットワーク・アドレスおよびアドレス範囲と比較する。表示されたネットワーク・アドレスが、そのＡＲＰ要求を受信したネットワーク・インタフェースと関連する場合、ルータは何もしない。表示されたネットワーク・アドレスが異なるネットワーク・インタフェースと関連する場合、ルータは、それ自身の物理アドレス、もっと正確には、ＡＲＰ要求を受信した物理ネットワークに関するネットワーク・インタフェースの物理アドレスを提供することにより、ＡＲＰ要求に応答するであろう。

ＡＲＰ技術のようなアドレス解決機構を使用する場合、ＡＲＰキャッシュまたはホストに関連するマッピング表などの規模を制限することが一般的な問題である。従って、通常はタイムアウト機構が実装され、それによってアドレス・バインディングが所定の制限時間、例えば２０分後に期限切れとなる。期限切れ後、各々のバインディングをキャッシュから削除する。削除したアドレス・バインディングにパケットを送信する場合は、新規のＡＲＰ要求を送信しなければならない。次に、ＡＲＰ応答で受信したバインディングは、キャッシュに再挿入される。この機構は、特に大きな物理ネットワークでは、複雑で非効率である。

プロキシＡＲＰ機能によりネットワーク・セグメントの柔軟な（再）構成が可能となるが、そのセグメントのホストのＡＲＰキャッシュは、プロキシＡＲＰルータの同じ物理アドレスにバインディングした異なるＩＰアドレスを有する、大きなエントリ数を含む可能性がある。

更に、ルータの陰の遠隔物理ネットワークに宛先が位置するけれども、宛先ホストを同じローカル・物理ネットワークに接続すると仮定すると、プロキシＡＲＰ機構を提供するルータは、ホストに対して大きな数のＡＲＰ要求を処理し、答えなければならない可能性がある。

ほかの柔軟なプロキシＡＲＰ技術の採用を考慮する場合、上記の側面は障害である。

データ伝送ネットワークにおけるアドレス解決の技術に対して、プロキシＡＲＰ機能を含む上記で説明したＡＲＰ機構のようなアドレス解決技術の利点を保ち、同時にその一つ以上の欠点を避けるという要求がある。

この要求は、データ伝送ネットワークにおけるアドレス解決のための第一の方法によって満たされ、本方法には、データ伝送ネットワークのホストで実行される、少なくとも一つの物理アドレスと、多くのネットワーク・アドレスを含む少なくとも一つのネットワーク・アドレス範囲との関連を保持するステップと、ターゲット・ネットワーク・アドレスを獲得するステップと、関連するターゲット物理アドレスを決定するため、ターゲット・ネットワーク・アドレスとネットワーク・アドレス範囲とを比較するステップと、例えば、ホストによるデータ送信を開始するため、決定したターゲット物理アドレスを提供するステップとを含む。

データ伝送ネットワークには、バス・トポロジまたはリング・トポロジのようなネットワーク・トポロジにより構成した多くのホストを備えてもよい。例えば、データ伝送ネットワークには、インターネット／ＩＰネットワークを備えてもよいし、トークン・リングまたはＡＴＭのようなその他の技術に基づいてもよい。より高次のネットワーク・レイヤの観点から、ホストは、静的または動的な方法において、クライアント−サーバ関係、ピアツーピア関係または互いに任意のその他の通信関係にあってもよい。データ伝送ネットワークには、例えば、ホストとして移動端末デバイスを備えるＵＭＴＳネットワークのような移動ネットワークと、ノードＢ、ＲＮＣ、ＳＧＳＮ、ＧＧＳＮ等のようなＵＭＴＳネットワークの無線アクセスおよびコア・ネットワークのルーティング・ノードと、例えば、複数のアプリケーション・サーバによってネットワークのＩＭＳ領域において提供されるアプリケーション・サービスとを備えてもよい。

ネットワークにおけるホストは、固定または移動端末デバイスからの任意の計算デバイス、ルーティング・デバイス、例えば、ルータ、ゲートウエイまたはファイアウォールのようなネットワーク・デバイス、認証または権限付与サーバのようなネットワーク・サービスまたはアプリケーション・サービスを提供するサーバ・デバイスであってもよい。機能的な観点から、ホストは、ネットワークにおける、または特定の動的または静的ネットワーク・アドレス（例えば、レイヤ３アドレスまたはＩＰアドレス）が関連するネットワークに接続される、任意の機能エンティティであってもよい。本ホストには、同時に、リンク・レイヤにおけるアドレッシングのための物理アドレス、例えば、レイヤ２アドレスまたはＭＡＣアドレスを有する。

送信データには、ネットワークにおけるホストからもう1つのホスト、ノードまたはデバイスに送信すべき任意のデータを含む。例えば、本データは、プレゼンテーションまたはアプリケーション・レイヤのようなより高度のネットワーク・レイヤに関してもよい。アプリケーション・データには、例えば、音声、ビデオおよび／または任意の種類のマルチメディア・データを含んでもよい。送信データには、追加してまたは代わりに、制御データまたはシグナリング・データまたはより低次のネットワーク・レイヤのデータを含む。

ネットワーク・アドレス範囲には、例えば、ＣＩＤＲ（クラスレス・ドメイン間ルーティング）表記法、即ち、ネット・マスクまたはプレフィックス表記法により、データ伝送ネットワークのサブネットワークを表示してもよい。この場合、従って、多数のネットワーク・アドレスはアドレスの連続体、即ち、アドレス・シーケンスを形成する。或いは、ネットワーク・アドレス範囲は、シーケンスでは構成していない多数の個別ネットワーク・アドレスのセットを表示してもよい。また、ネットワーク・アドレス範囲には、これらの変形の任意の組合せを備えてもよい。

第一の方法の実現の１つのクラスには、ホストの物理アドレスに関連するネットワーク・アドレス範囲を決定する最初のステップを備える。実現のもう１つのクラスには、例えば、データ伝送ネットワークにおける（ルータのような）アドレス解決サポートノードにおける、ホストの外部のネットワーク・アドレス範囲の決定を備える。本方法の実現の後者のクラスの特徴について、以下に更に要約する。また、両方のクラスを合成してもよい。

ホストにおけるネットワーク・アドレス範囲の決定を参照して、ホストは、個別のネットワーク・アドレスと個別の物理アドレスとの関連のリストを保持してもよい。例えば、IPｖ４ネットワークでは、ホストは、個別のＩＰアドレスと個別のレイヤ２アドレス（例えば、ＭＡＣアドレス）との関連を含むＡＲＰキャッシュを保持してもよい。加えて、本リストにはまた、個別の物理アドレスに関連する一つ以上のネットワーク・アドレス範囲を含めてもよい。次に、ネットワーク・アドレス範囲を決定するステップには、異なる複数のネットワーク・アドレスまたはネットワーク・アドレス範囲またはその両方と、一つの同一物理アドレスとの関連を検出することを含んでもよい。例えば、二つ以上のネットワーク・アドレスが特定の物理アドレスと関連していてもよい。もうひとつの例として、一つ以上の個別のネットワーク・アドレスおよび一つ以上のネットワーク・アドレス範囲が、特定の物理アドレスと関連していてもよい。

この種類の実現化の一つのやり方には、ネットワーク・アドレス範囲を決定するステップで、ネットワーク・アドレス範囲を少なくとも所定の最小のサブネットワーク規模の範囲に設定するステップを含む。言い換えれば、ネットワーク・アドレス範囲には、例えば、ＩＰｖ４ネットワークにおいて最大２８ビット（または例えば、２６ビット、２４ビット等）を含む所定の最大ネット・マスクを備えてもよい。例えばＡＲＰ応答で、ルーティング・ノードからの制御データとして、最小サブネットワーク規模がホストに提供されるか、手動または任意の他の方法で、データ伝送ネットワークのオペレータによって構成されてもよい。所定の最小サブネットワーク規模は、ホストがコンタクトできるルーティング・ノードにおけるルーティングのために使用する最小のサブネットワーク規模を表わしてもよい。この規模は、ルータが細分したネットワーク・セグメントの規模と一致してもよく、送信ホストが一つの部分にあり、受信ノードまたはホストが、細分したセグメントの他の部分に位置する。

ネットワーク・アドレス範囲の決定をホストの外部で実行する、上記で説明した種類の実現化に関しては、第一の方法には、ホストで物理アドレスに関連するネットワーク・アドレス範囲の表示を受信するステップを有してもよい。例えば、データ伝送ネットワークにおけるアドレス解決サポートノード、例えば、ルーティング・ノードから、本表示を受信してもよい。本表示を、例えば、ＩＰｖ４ネットワークにおけるＡＲＰ応答に組み込んで受信してもよい。異なる実装では、アドレス解決サポートノードは、例えば、周期的ベースで、アドレス解決要求による事前のトリガなしに、ホストのネットワークにおけるネットワーク・アドレス範囲を同報送信する同報機能を実行してもよい。さらにもう一つの実装では、ホストのネットワークに接続したオペレータの端末から本表示を受信してもよい。

第一の方法の幾つかの実装では、ターゲット・ネットワーク・アドレスが複数のネットワーク・アドレス範囲と一致する場合、更なる決定のステップは、ターゲット物理アドレスを決定するために最小の一致するネットワーク・アドレス範囲を決定する。これは、‘最長プレフィックス一致’アルゴリズムの変形であってもよい。

第一の方法には、ターゲット・ネットワーク・アドレスがどのネットワーク・アドレス範囲にも、または個別のネットワーク・アドレスにも一致しない場合、ターゲット・ネットワーク・アドレスを含むアドレス解決要求を送信する更なるステップを有してもよい。第一の方法のこのやり方の一つの実装には、例えば、ネットワークにおけるアドレス解決サポートノードからＡＲＰ応答を受信するため、ＩＰｖ４ネットワークでＡＲＰ応答を同報送信するステップを有してもよい。例えば、プロキシＡＲＰ機能を提供することにより、アドレス解決をサポートする物理ネットワークの任意のノードを、‘アドレス解決サポートノード’と呼んでもよい。例えば、物理ネットワークに接続され、デフォルト・ゲートウエイとして動作するルータは、アドレス解決サポートノードとして動作してもよい。

上記で説明した要求は、データ伝送ネットワークにおけるアドレス解決の第二の方法により、更に満たされ、本方法には、データ伝送ネットワークのアドレス解決サポートノードにおいて、ターゲット・ネットワーク・アドレスを含むアドレス解決要求を受信するステップと、ターゲット・ネットワーク・アドレスに基づいて、ネットワーク・アドレス範囲を決定するステップと、アドレス解決サポートノードの物理アドレスの表示と決定されたネットワーク・アドレス範囲の表示とで応答するステップとを有する。

決定したネットワーク・アドレス範囲の表示には、例えば、添付のプレフィックス表示を有するターゲット・ネットワーク・アドレスを含んでもよい。

アドレス解決要求は、例えば、ＩＰｖ４ネットワークのＡＲＰ要求であってもよい。第二の方法の一つの変形において、ネットワーク・アドレス範囲を決定するステップには、ターゲット・ネットワーク・アドレスをルーティング表のネットワーク・アドレス範囲に一致させるステップを備えてもよい。例えば、アドレス解決サポートノードはルータであってもよく、または、ルータ、ゲートウエイ、プロセッサ・サーバまたは、個別のネットワーク・アドレスまたはネットワーク・アドレス範囲とルーティング・デバイスの特定のネットワーク・インタフェースとの関連を定義するルーティング表を保持する任意のその他の種類のルーティング・デバイスと関連させてもよい。この変形には、ターゲット・ネットワーク・アドレスが複数のネットワーク・アドレス範囲と一致する場合、最小の一致するネットワーク・アドレス範囲、即ち、アドレス指定された最小サブネットワークを決定するステップを有してもよく、即ち、言い換えれば、最長一致プレフィックスを決定する。

第一および第二の側面の何れか一つで、ネットワーク・アドレスとネットワーク・アドレス範囲をそれぞれ表わすため、ホストまたはアドレス解決サポートノードで単一のアドレス・フォーマットを使用してもよい。例えば、ＣＩＤＲ表記法のため、個別のホスト（即ち、ＩＰｖ４ネットワークには、３２ビットのネット・マスクを適用する）に、同じくサブネットワーク（ＩＰｖ４ネットワークでは、３２ビット以下を備えるネット・マスク）にアドレス指定することが可能となる。アドレス・フォーマットには、ネットワーク・アドレスまたはネットワーク・アドレス範囲の何れかを表示する範囲表示器を備えてもよい。上記の例では、範囲表示器、即ち、ＣＩＤＲ表記法におけるアドレス表示の斜線部分として、マスク長の表示を使用してもよい。

本方法の側面の一つまたは両方で、媒体アクセス制御“ＭＡＣ”アドレスとして物理アドレスを表わしてもよく、インターネット・プロトコル“ＩＰ”アドレスとしてネットワーク・アドレスを表わしてもよく、ネットワーク・アドレス範囲の表示を送信し、受信するため、アドレス解決プロトコル“ＡＲＰ”（例えば、ＩＰｖ４ネットワークで）または近隣探索“ＮＤ”（例えば、ＩＰｖ６ネットワーク）を採用してもよく、上述のいずれかを組み合わせても良い。

更に、上述の要求は、計算機プログラム製品で満たされ、それには、例えば端末デバイス、サーバまたはルータという、一つ以上の計算デバイス上で本計算機プログラム製品を実行する場合、本方法の何れか一つのステップおよび本明細書で説明する方法の側面を実行するプログラム・コード部分を含む。本計算機プログラム製品は、計算デバイスまたはリムーバブルＣＤ−ＲＯＭ、ＤＶＤまたはＵＳＢスティックの中にある、またはそれの関連する永久的または再書き込み可能メモリのような、計算機読み取り可能記録媒体に記録されてもよい。追加してまたは代わりに、例えば、インターネットまたは、電話線または無線リンクのような通信線のデータ・ネットワークを経由して、計算デバイスにダウンロードするため、本計算機プログラム製品を提供してもよい。

更に、上述の要求は、データ伝送ネットワークにおけるアドレス解決のために適合したホストによって満たされる。本ホストには、少なくとも一つの物理アドレスと多数のネットワーク・アドレスを備える少なくとも一つのネットワーク・アドレス範囲との関連を保持する第一の要素と、ターゲット・ネットワーク・アドレスを獲得する第二の要素と、関連するターゲット物理アドレスを決定するため、ターゲット・ネットワーク・アドレスとネットワーク・アドレス範囲とを比較する第三の要素と、決定したターゲット物理アドレスを提供する第四の要素とを備える。

例えば、本ホストは、データ伝送ネットワークにおけるその他のホスト、ノードまたはデバイスにサービスを提供するサーバであってもよい。一つの変形では、本ホストには、ホストの物理アドレスに関連するネットワーク・アドレス範囲を決定するよう適合した更なる要素を備える。前の変形と合成してもよいが、もう一つの変形では、本ホストには、ホストで物理アドレスに関連するネットワーク・アドレス範囲の表示を受信するよう適合した更なる要素を備える。

また更に、上述の要求は、データ伝送ネットワークにおけるアドレス解決に適合したホストで使用する記憶要素により満たされ、本記憶要素は、少なくとも一つの物理アドレスと多数のネットワーク・アドレスを備える少なくとも一つのネットワーク・アドレス範囲との関連を保持するよう適合したものである。

上述の要求は、データ伝送ネットワークにおけるアドレス解決をサポートするよう適合したアドレス解決サポートノードによって更に満たされる。本ノードには、ターゲット・ネットワーク・アドレスを備えるアドレス解決要求を受信する第一の要素と、ターゲット・ネットワーク・アドレスに基づいて、ネットワーク・アドレス範囲を決定する第二の要素と；アドレス解決サポートノードの物理アドレスの表示と決定したネットワーク・アドレス範囲の表示とで応答する第三の要素とを備える。本アドレス解決サポートノードは、データ伝送ネットワークにおけるルーティング・ノードであってもよい。

上述の要求は、上記で要約したような特徴を有するホストと上記で要約したような特徴を有するアドレス解決サポートノードとを備えるデータ伝送ネットワークにより、更に加えて満たされる。

また、上述の要求は、データ伝送ネットワークにおけるアドレス解決に関する信号によって満たされ、本信号は、アドレス解決サポートノードの物理アドレスの表示とネットワーク・アドレス範囲の表示とを表わすものである。例えば、本信号は、プレフィックス表示を含むよう変更したＡＲＰ応答メッセージを表わしてもよい。

以下において、次の図に示した典型的実施形態を参照して、本発明について更に説明する。

データ伝送ネットワークの第一の実施形態を概略的に示す。図１のデータ伝送ネットワークにおけるホストの実施形態の機能的要素を示す。図２のホストに関するＡＲＰキャッシュのデータを概略的に示す。図１のデータ伝送ネットワークにおけるアドレス解決サポートノードの実施形態の機能的要素を示す。ホストで実行されるデータ伝送ネットワークにおけるアドレス解決の方法の第一の実施形態のステップを示す。アドレス解決サポートノードで実行されるデータ伝送ネットワークにおけるアドレス解決の方法の第二の実施形態のステップを示す。アドレス解決要求／応答メッセージ・ペアを概略的に示す。アドレス解決メッセージの第一の実施形態のフォーマットを示す。アドレス解決メッセージの第二の実施形態のフォーマットを示す。データ伝送ネットワークの第一の実施形態を概略的に示す。データ伝送ネットワークの第二の実施形態を概略的に示す。データ伝送ネットワークの第三の実施形態を概略的に示す。

以下の説明では、説明と非限定を目的に、説明する技術のついての完全な理解を提供するため、特別なネットワーク・ホスト、通信プロトコル等を含む特定のネットワーク・システムのような特定の詳細について説明する。当業者には明らかであろうが、これらの特定の詳細から離れるその他の実施形態で、これらの技術を実施してもよい。例えば、熟練した技能者なら認識するであろうが、本発明を示すために下記に議論するイーサネット（登録商標）／ＩＰネットワークと異なるデータ伝送ネットワークで、それらを実施してもよい。レイヤ方式で構成する任意のデータ伝送ネットワークで、説明する技術を実施してもよく、ホスト、ノードまたはデバイス（本明細書では多かれ少なかれ、これらの用語はどちらを使っても変わりはない）は、それらの間の物理的接続のための関連の物理アドレスと、エンド・ツー・エンドまたは少なくとも次のホップのネットワーク接続のためのネットワーク・アドレスとを有する。通常は、これらのネットワークは、ネットワーク接続にルーティング機構を採用する、パケット型データ伝送ネットワークであろう。しかしながら、原理的には、ルーティングまたはスイッチング・アルゴリズムのようなアルゴリズムを使用して、ネットワークを通じて最適な経路を見付け出すことによりデータを伝送する、任意のシナリオのために、本説明の技術を使用してもよい。

更に、当業者は認識するであろうが、個別のハードウエア回路を使用して、プログラムしたマイクロプロセッサまたは汎用計算機とともにソフトウエア機能を使用して、特定用途向け集積回路（ＡＳＩＣ）を使用して、または一つ以上のデジタル信号プロセッサ（ＤＳＰ）を使用して、またはその両方を使用して、以下に本明細書で説明する機能を実装してもよい。本発明を方法として説明する場合、計算機プロセッサとプロセッサに連結したメモリにそれを実装してもよく、プロセッサが実行する場合、本明細書で開示する方法を実行する一つ以上のプログラムで、本メモリをエンコードしている。

図１は、データ伝送ネットワークの実施形態として、２個の物理ネットワーク（ローカル・エリア・ネットワーク、ＬＡＮ）１０２と１０４とを有するＩＰｖ４（インターネット・プロトコル４版）ネットワーク１００を概略的に示す。物理ネットワーク１０２と１０４の各々には、図１で“Ｈ”と指定した多くのホストを備える。ルータ“Ｒ”１０６を介して物理ネットワーク１０２と１０４とを互いに相互接続する。プロキシＡＲＰ機能をルータ１０６に実装し、個別の物理ネットワーク１０２と１０４とが単一の論理サブネットワークとして見え、単一のネットワーク・アドレス（範囲）を共有してもよい。実際には宛先ホストはプロキシＡＲＰルータ１０６の背後の遠隔物理ネットワークに位置するけれども、宛先ホストがローカル物理ネットワークに位置すると仮定するよう、ネットワーク１０２と１０４の一つまたは両方にホストを構成してもよい。

具体例として、物理ネットワーク１０２のホスト１０８は、ＩＰパケットのデータを遠隔物理ネットワーク１０４のホスト１１０に送信したい可能性がある。ホスト１０８は、そのＡＲＰキャッシュ内のホスト１１０のネットワーク・アドレスをバインディングするアドレスを見つけ出さない。従って、ホスト１０８は、物理ネットワーク１０２内のＡＲＰ要求を同報送信する。ルータ１０６は、プロキシＡＲＰ機能に基づき本要求に答える。ＡＲＰ応答には、ネットワーク１０２に接続したルータ１０６のネットワーク・アダプタの物理アドレス（即ち、ハードウエア・アドレスまたはデバイス・アドレス）を含む。ネットワーク１００のレイヤ２としてイーサネット（登録商標）を実装していると仮定すると、ルータ１０６の物理アドレスはＭＡＣ（媒体アクセス・プロトコル）アドレスである。ＡＲＰ応答で受信したＭＡＣアドレスを使用して、ホスト１０８はそのＩＰパケットをルータ１０６に向けて送信するであろう。ルータ１０６は、宛先ホスト１１０に向けてネットワーク１０４を介して本パケットを転送するであろう。

図２は、データ伝送ネットワークにおけるアドレス解決の方法２００の実施形態のステップを示す。データ伝送ネットワークのホスト、例えば、図１のホスト１０８で、本方法を実行してもよい。

ステップ２０２で、少なくとも一つの物理アドレスと、多数のネットワーク・アドレスを備える少なくとも一つのネットワーク・アドレス範囲との関連を保持する。例として、図１のシナリオを参照し、ネットワーク・アドレス範囲には、ホスト１１０のネットワーク・アドレスを含めてもよい。ネットワーク・アドレス範囲は、例えば、物理ネットワーク１０２と１０４の共通ネットワーク・アドレスを表示してもよい。ステップ２０４で、ターゲット・ネットワーク・アドレスを獲得する。例えば、ホストのより高次の通信レイヤから、またはホストで実行されるアプリケーションのアプリケーション・レイヤから、本ターゲット・ネットワーク・アドレスを受信してもよい。

ステップ２０６で、ターゲット・ネットワーク・アドレスをネットワーク・アドレス範囲と比較し、関連するターゲット物理アドレスを決定する。図１を参照して例として挙げると、ホスト１０８はそのＡＲＰキャッシュにアクセスし、ホスト１１０のネットワーク・アドレスがキャッシュのエントリと一致するかどうかを決定してもよい。ステップ２０８で、決定したターゲット物理アドレスをホストのその他の要素に提供し、例えば、決定したターゲット物理アドレスに基づきデータ送信を開始してもよい。例えば、ホスト１１０のネットワーク・アドレスがキャッシュ内のネットワーク・アドレス範囲に入るので、ホスト１０８はルータ１０６の物理アドレスにＩＰパケットを送信することを開始してもよく、それは、キャッシュのネットワーク・アドレス範囲に関連するのはこのアドレスである可能性があるからである。

図３は、データ伝送ネットワークにおけるアドレス解決の更なる方法３００の実施形態のステップを示し、例えば、図１のプロキシＡＲＰルータ１０６のようなアドレス解決サポートノードで実行してもよい。

ステップ３０２で、ターゲット・ネットワーク・アドレスを備えるアドレス解決要求を受信する。例えば、図１のルータ１０６で、ホスト１１０のネットワーク・アドレスを含むＡＲＰ要求を受信してもよい。ステップ３０４で、受信したターゲット・ネットワーク・アドレスに基づき、ネットワーク・アドレス範囲を決定する。例えば、ルータ１０６は、ネットワーク・アドレス範囲として、ネットワーク１０２と１０４の両方が共有するネットワーク・アドレスを決定してもよい。ステップ３０６で、アドレス解決サポートノードの物理アドレスの表示と決定したネットワーク・アドレス範囲の表示とを備える応答を提供する。上記の例では、プロキシＡＲＰルータ１０６は、ルータ１０６の適当なＭＡＣアドレスを表示するホスト１０８にＡＲＰ応答を、そしてネットワーク１０２と１０４の両方に対応するネットワーク・アドレス範囲を提供してもよい。

図４は、データ伝送ネットワークにおけるアドレス解決に適合するホスト４００の実施形態の機能構成ブロックを概略的に示す。ホスト４００は、図１の任意のホストＨ、例えば、ホスト１０８の実装であってもよい。

ホスト４００には、少なくとも一つの物理アドレスと、多数のネットワーク・アドレスを含む少なくとも一つのネットワーク・アドレス範囲との関連を保持するよう適合した記憶要素４０２を備える。物理アドレスとネットワーク・アドレスまたはネットワーク・アドレス範囲との関連は、一般的には、本明細書で ‘バインディング’と呼ぶことがある。記憶要素４０２の内容は、ネットワーク内または宛先での変化する条件、またはその両方のため動的に変化する可能性があるので、要素４０２はまた、‘バインディング・キャッシュ’とも名付けられる。バインディング・キャッシュ４０２の具体例は、ＩＰｖ４で使用可能なホストのＡＲＰキャッシュであってもよい。

ホスト４００は、ターゲット・ネットワーク・アドレスを獲得するよう適合した要素４０４を備える。図４に示す構成では、要素４０４は、ホスト４００が送信を意図するデータ・パケットをバッファするパケット・バッファ４０６をポーリングする。例えば、ホスト４００のＩＰレイヤが、バッファ４０６のＩＰパケットを提供してしまう可能性がある。パケットがバッファ４０６で利用可能であるということをポーリングで決定した場合、要素４０４は記憶したパケットにアクセスし、そのターゲット・ネットワーク・アドレスとしてＩＰアドレスを抽出するよう動作する。

要素４０４は、獲得したターゲット・ネットワーク・アドレスをコンパレータ４０８に供給するが、それは、獲得したターゲット・ネットワーク・アドレスと、バインディング・キャッシュ４０２に記憶したネットワーク・アドレスおよびネットワーク・アドレス範囲とを比較するよう適合している。例えば、ターゲット・ネットワーク・アドレスが、キャッシュ４０２に記憶したネットワーク・アドレスおよびネットワーク・アドレス範囲の少なくとも一つに入る場合、コンパレータ４０８は、（最もよく）一致するネットワーク・アドレスまたはアドレス範囲に関連する物理アドレスをキャッシュ４０２から抽出し、送信トリガ要素４１０に抽出した物理アドレスを提供する。

送信トリガ要素４１０は、決定したターゲット物理アドレスをホスト４００の適当な送信要素（図示せず）に提供することにより、データ送信を開始するよう適合しているが、任意のその他の要素にも本アドレスを供給するよう適合している可能性がある。要素４１０は、バッファ４０６のＩＰパケットをフレーム構成し、決定したターゲット物理アドレスを含むＭＡＣヘッダをＩＰパケットに追加するよう備える。その後、要素４１０はホスト４００のネットワーク・アダプタ（図示せず）をトリガし、ＩＰパケットを含むフレームを送信してもよい。

ホスト４００には、バインディング・オプティマイザ要素４１２を更に備え、それは、一つの同じ物理アドレスに関連する多数のネットワーク・アドレスを対象にするネットワーク・アドレス範囲を決定するよう適合している。要素４１２は、規則的な時間間隔で、またはトリガ信号に従って、またはその両方で、バインディング・キャッシュ４０２にアクセスする。キャッシュにアクセスする場合、バインディング・オプティマイザ４１２は、同じ物理アドレスを共有するバインディング・エントリを検出する。同じ物理アドレスに対して多数のバインディングを特定した場合、多数のバインディング・エントリは単一のエントリで置き換えられ、ネットワーク・アドレス範囲を物理アドレスと関連させる。言い換えれば、多数のアドレス（またはアドレス範囲）は、まとめて一つのネットワーク・アドレス範囲（または幾つかのネットワーク・アドレス範囲）になってしまう。オプティマイザ４１２が実行する可能性のある、バインディング・エントリ機構をまとめる例について、以下に更に説明する。

要素４１２に加えて、ホスト４００には、バインディング受信要素４１４を更に備え、これは、ホスト４００を接続するネットワーク（図示せず）から、物理アドレスに関連するネットワーク・アドレス範囲の表示を受信するよう適合している。例えば、そのようなバインディング表示を、ルータ、デフォルト・ゲートウエイ等のようなアドレス解決サポートノードから受信してもよい。要素４１４は、受信したバインディング表示をキャッシュ４０２のバインディング・エントリに追加する。要素４１４は、新規の追加エントリのため余分となったバインディング・エントリを除去するよう、キャッシュ４０２に更に作用する。例えば、同じ物理アドレスを新規のエントリとして表示するということに基づき、そのような余分のエントリを決定することができる。或いは、オプティマイザ４１２により、このキャッシュ最適化を実行してもよい。

図５は、ＡＲＰキャッシュにおけるバインディング・エントリを示し、図示の目的ため、バインディング・キャッシュ４０２の通常の実装であると仮定している。即ち、図４のオプティマイザ４１２のようなバインディング・オプティマイザにより、キャッシュの最適化を完了する前５０２および後５０４の、キャッシュの二つの状態を示す。

ＡＲＰキャッシュ５０２には多数のバインディング・エントリ５０６を含み、各エントリには、特定のＩＰｖ４アドレス（左列）とＭＡＣアドレス（右列）との関連を備える。キャッシュ５０２には、一つで同じＭＡＣアドレスと関連する異なるＩＰアドレスを有する多数のエントリを備える。例えば、キャッシュ５０２は図１のホスト１０８のようなホストに属する可能性があり、実際には、図１のルータ１０６のようなルータにより物理ネットワークを細分しているが、同じ物理ネットワークにあると仮定する複数のホストと通信する。ルータがプロキシＡＲＰ機能を切り換えてしまった場合、ルータは、実際には遠隔物理ネットワークに位置するそれらのホストのそれ自身のＭＡＣアドレスを、要求ホストに提供するであろう。

キャッシュ５０４に従って最適化の結果を示す。オプティマイザは単一のＭＡＣアドレスを有する多数のバインディング・エントリを特定し、これらの多数のエントリをまとめてキャッシュ５０４の単一のエントリ５０８にしてしまう。その結果、対応するネットワーク範囲を表示するプレフィックス表示“／２４”（ＣＩＤＲ表記法）により、多数の個別のＩＰアドレスを置き換えてしまう。実際、２５６個のＩＰアドレス１５９．１０９．１９９．０．．．１５９．１０９．１９９．２５５は、プロキシＡＲＰノードのＭＡＣアドレス、ＡＢ−ＣＤ−ＥＦ−１Ａ−２Ｂ−９８にならなければならない。表５０２と表５０４のその他のエントリは個別のアドレスを意味し、表ではプレフィックス表示“／３２”を省略した。

ホスト・アクセス・キャッシュ５０４は、ターゲット・ネットワーク・アドレス用にターゲット物理アドレスを決定するため、ターゲットＩＰアドレスと正確に一致するＩＰアドレスがあるかないか決定しなければならないばかりでなく、ターゲットＩＰアドレスが、バインディング・エントリ５０８のようなアドレス範囲エントリに入るか入らないかも決定しなければならない。エントリ５０８のような範囲エントリは、最適化の前にキャッシュ５０２に含まれた特定のエントリに加えて、同じ論理サブネット内の多くの更なるネットワーク・アドレスを対象とする。このマップは、ホストが属する物理ネットワークの多くのＡＲＰ要求を避ける助けとなる。

エントリ５０８のような範囲エントリを記憶するためにバインディング・キャッシュを可能とすることは、例えば、ＣＩＤＲ表記法を使用する場合、プレフィックスの数即ちネットマスク・ビット（図５のエントリ５０８では１０進の‘２４’）の表示、即ち、ＩＰｖ４ネットワーク・アドレスのためにはバインディング・エントリ当り少なくとも７ビットのための追加の記憶場所の提供を要求する。この例では、表示‘３２’は個別のＩＰアドレスを参照する。しかしながら、図５に示すように、キャッシュにおけるバインディング・エントリの数は著しく減少する可能性があるので、具体的には、図１に示すようなプロキシＡＲＰ構成の場合および同様なネットワーク・シナリオにおいて、要求される全記憶場所もまた減少する可能性がある。

例えば、定期的な方法で（周期的に）、受信した各ＡＲＰ応答の後、またはバインディング・キャッシュに新規のエントリまたは所定の数の新規エントリを追加したときは何時でも、図５に示すような最適化手順を実行してもよい。

最適化手順は、一般的には、一つで同じ物理アドレスを指し示す、キャッシュの多数のエントリを特定すること要求するが、多数の個別ネットワーク・アドレスを置き換えるネットワーク・アドレス範囲を決定できる技術が提供されなければならない。一つの方法には、多数の個別のアドレスを対象とする可能性のある最小のネットマスクを適用することにより、多数の個別ネットワーク・アドレスを一つにまとめることを備えてもよい。

更なる条件として、最小のサブネットワーク即ち、言い換えれば、ＣＩＤＲ表記法でアドレス範囲を表示すると仮定した場合のネットマスク・ビット（プレフィックス・ビット、サブネット・ビット）の最大数Ｎを表示する、所定のパラメータを提供してもよい。例えば、パラメータＮが多数の２４ビット（エントリ５０８参照）という数を示す場合、これは、多数の個別のＩＰアドレスをまとめて／２４サブネットより少なくないサブネット、即ち、ネットマスク２５５．２５５．２５５．０にする、ということを意味する。もし単に、最適化前にキャッシュの更なる特定のエントリにより、表示されたネットワーク・アドレス範囲内の全ネットワーク・アドレスを対象とするなら、パラメータＮより短いマスクを適用するよう、オプティマイザを更に構成してもよい。

パラメータＮは、例えば、管理者により構成可能であってもよく、または、デフォルト・ゲートウエイのようなルータ、またはホストの物理ネットワークに接続したプロキシＡＲＰルータから受信してもよい。ホストが属する物理ネットワークに接続したプロキシＡＲＰルータのルーティング表で表示する最小のサブネットにより、パラメータＮを設定してもよい。この場合、Ｎは、より小さいサブネット（即ち、より長いプレフィックス）内のルータにはルートが存在しない、ということを意味する。この方法では、ルータのルーティング表を参照して、論理サブネットワークを多数の物理ネットワークにマッピングすることを達成する。

所与のネットワーク・アドレス範囲内の殆んどない例外を無視するため、ルーティング表で表示するように、Ｎをより小さな値に設定してもよい。この場合、ホストのバインディング・キャッシュの最適化の間、対応するネットワーク・アドレスを異なる物理アドレスにバインド（結合）しなければならないであろうから、決定したネットワーク・アドレス範囲内に入り、そして例外に関するバインディング・エントリは、置き換えられないであろう。それ故、これらのバインディング・エントリはキャッシュにそのまま残るであろう。アドレス解決のためにキャッシュをアクセスする場合、最長プレフィックス一致原理を適用することは、これらの特定の個別宛先ネットワーク・アドレスに送信するつもりのデータ・パケットを正しい物理アドレスに送信するであろう、ということを保証する可能性がある。

バインディング・キャッシュにタイムアウト機構を適用する場合、最適化手順が挿入したネットワーク・アドレス範囲エントリのタイムアウト値を、置き換えられた個別のエントリからの最も遅いタイムアウト値に設定してもよい。この場合、表示されたサブネット内のアドレス・バインディングの将来の検索は、それ故、考えられる最長の期間で成功する可能性がある。

バインディング・キャッシュのエントリをタイムアウトの対象とすると、やはりキャッシュに表わされるネットワーク・アドレス範囲に入るネットワーク・アドレスを伴う特定のバインディング・エントリは有効期限が切れ、次にキャッシュから除外されるであろう。その場合、最長プレフィックス一致はもはや適用しないであろうが、第一のステップで、その物理アドレスがネットワーク・アドレス範囲に関連するノード、例えば、プロキシＡＲＰ機能を実行するルータにトラヒックを送信するであろう。しかしながら、そのルータは目的の宛先に正しくトラヒックを転送するであろう。物理ネットワーク内のルータ上にトラヒックを不必要に向かわせることを避けるため、物理ネットワークのアドレス解決要求が、バインディング・キャッシュに含まれるネットワーク・アドレス範囲内に入るネットワーク・アドレスを含むかどうかを監視するよう、ホストを構成してもよい。例えば、ＡＲＰ環境では、ホストは、ソース・ハードウエア・アドレスとしてプロキシＡＲＰルータのＭＡＣアドレスを含む各ＡＲＰ問い合わせ（クエリ）をリッスンしてもよい。そのような問い合わせを受信した場合、ホストは、そのルータのＭＡＣアドレスが、その問い合わせに表示したＡＲＰのターゲットＩＰアドレスに対して正しくないと結論付けることができる。ホストは次に、それ自身にＡＲＰ要求を同報送信するか、ルータのＡＲＰ要求に応じて送信した応答をリッスンしてもよく、次に、結果のバインディング・エントリをそのＡＲＰキャッシュに挿入してもよい。この場合、後続のパケットは物理ネットワークの２個のホスト間を直接流れるであろう。

この方法で、最適化アルゴリズムは、同じ物理アドレスを有する多数のバインディング・エントリをまとめて、適当に選択したネットワーク・アドレス範囲を含む単一のエントリにすることにより、ホストのバインディング・キャッシュを最適化するよう、動作できる。それ故、ホストのバインディング・キャッシュでのみ、プレフィックス集約をローカルに処理してもよく、即ち、ＩＰｖ４ネットワークのＡＲＰまたはＩＰｖ６ネットワークのＮＤのような、アドレス解決をサポートする通信プロトコルが関与する必要はない。それでもなお、物理ネットワークのＡＲＰルータのようなアドレス解決サポートノードを有するホストの適当な通信により、キャッシュ最適化を、追加してまたは代わりに、サポートしてもよい。これについては、以下に更に説明する。

図６は、データ伝送ネットワークにおけるアドレス解決をサポートするよう適合した、アドレス解決サポートノード６００の実施形態の機能構成ブロックを概略的に示す。以下では、説明と図示を目的に、ノード６００は図１のルータ１０６の実装であると仮定する。

ノード６００は受信要素６０２を備え、ターゲット・ネットワーク・アドレスを表示するアドレス解決要求を受信することに適合している。ここで示す例では、要素６０２は、ルータ６００を接続するＩＰｖ４ネットワーク（図示せず）からＡＲＰ要求６０４を受信することに適合している。ＡＲＰ要求６０４はターゲットＩＰアドレスを表示する。要素６０２は、要求６０４からアドレスを抽出し、決定要素６０６にそれを提供するが、それは、ターゲット・ネットワーク・アドレスに基づいてネットワーク・アドレスまたはネットワーク・アドレス範囲を決定するよう適合した一般的要素の実装である。ここで検討する場合では、要素６０６は修正プロキシＡＲＰ機能を実装している。

詳しくは、要素６０６は、要素６０２から提供されるターゲットＩＰアドレスによってトリガされ、ターゲットＩＰアドレスに一致するルーティング表６０８内のＩＰアドレス及びＩＰアドレス範囲を見つけるため、ルーティング表６０８にアクセスするよう構成される。ターゲットＩＰアドレスが、表６０８のルーティング・エントリの特定のＩＰアドレス範囲に入るという場合に集中して説明する。一致するＩＰアドレス範囲が、ルーティング・エントリにより、到来した要求６０４を受信したネットワーク・インタフェース（即ち、図６のネットワーク・インタフェース６１０）に関連があると決定した場合、要求元ホストおよびターゲットＩＰアドレスのホストは、同じ物理ネットワーク内にあり、それ故、決定要素６０６は、それ以上の動作を取ることなしに処理を完了してもよい。

一致するＩＰアドレス範囲が、ルーティング表６０８内で、インタフェース６１２のような入力ＡＲＰ要求６０４のインタフェースと異なるネットワーク・インタフェースに関連すると判明した場合、要素６０６は、要求元ホストに接続したＩＰインタフェース６１０に関連付けられた物理アドレスを決定する。次に、要素６０６はルーティング表６０８から一致するＩＰアドレス範囲を獲得し、また、ネットワーク・インタフェース６１０の決定した物理アドレスを獲得して、これらのデータを応答要素６１４に提供する。この要素は、通常、アドレス解決サポートノードの物理アドレスの表示と決定したネットワーク・アドレス範囲の表示とを含む要求６０４のようなアドレス解決要求に応答することに適合している。ここで説明する例では、要素６１４は修正ＡＲＰ応答６１６をＡＲＰ要求６０４の発信元に送信し、応答６１６には、ｉ／ｆ６１０の物理アドレスと表６０８からの一致するＩＰアドレス範囲とを含む。別の実施形態では、ノード６００は、ＡＲＰ要求６０４のようなアドレス解決要求によりトリガされることなく、ｉ／ｆ６１０の物理アドレスと一致するＩＰアドレス範囲を含む同報メッセージを、インタフェース６１０に接続したローカル・ネットワークへ提供することに、さらに適合してもよい。例えば、プロキシＡＲＰ機能を活性化する限り、周期的ベースでそのような同報メッセージを提供するよう、ノード６００を構成してもよい。

図７は、ＩＰｖ４ネットワークにおけるホスト７０２とホスト７０４との間のＡＲＰ要求／応答通信の特定の例を伴うアドレス解決要求／応答のペアを示す。ホスト７０２とルータ７０４は、例えば、図１のホスト１０８とルータ１０６の実装であってもよい。

ホスト７０２は、ルータ７０４に向けてＡＲＰ要求７０６を送信する。ＡＲＰ要求７０６は、ターゲット・ネットワーク・アドレス７０８として、ＩＰアドレス１５９．１０７．１．２を表示する。ルータ７０６は、図６に典型的に示すように動作してもよく、ホスト７０２に修正ＡＲＰ応答を提供する。応答７１０には、ターゲットＩＰアドレス７０８と、同じくプロキシＡＲＰルータ７０４のＭＡＣアドレス７１２とを含む。更に、ルータ７０４は、プレフィックス表示７１４、即ち、ＩＰアドレス７０８に関するネットマスクの表示を提供する。ルータ７０６は、そのルーティング表においてターゲット・アドレス７０８が一致するルーティング・エントリから、プレフィックス表示７１４を抽出してしまってもよい。プレフィックス表示７１４に基づき、ホスト７０２は、ルータ７０４のＭＡＣアドレス７１２が個別のターゲットＩＰアドレス７０８に対してばかりでなく、ネットワーク・アドレス範囲１５９．１０７．０．０／１６に対しても正しい、と結論付けてもよい。

図７に示すように、要求ホストにもどす非修正ターゲットＩＰアドレスとともに添付したプレフィックス表示を提供することにより、ホストのＡＲＰキャッシュがネットマスクの取り扱いに適合しない場合、従来のＡＲＰ処理におけるように、ホスト７０２は、ネットマスク表示７１０を無視し、ＩＰアドレス７０８を使用するのみということが、都合よく可能となる。図７に示すシナリオの起こり得る不利な点は、ホスト７０２が単純にＩＰアドレス７０８、プレフィックス表示７１４およびＭＡＣアドレス７１２の組合せをそのバインディングキャッシュに挿入できず、挿入する前に、ＩＰアドレス範囲を“１５９．１０７．１．２／１６”から“１５９．１０７．０．０／１６”に変換しなければならない可能性があることである。別の実施形態では、ルータは、その応答で、ターゲットＩＰアドレスを単純に反映する代わりに、サブネットのアドレス、即ち、（図７の例を参照して）“１５９．１０７．０．０／１６”を提供してもよい。

ホスト７０２が、そのＡＲＰキャッシュに関するプレフィックス処理に対して可能となる場合、ＡＲＰ応答７１０によって表示されるＩＰアドレス範囲を含むバインディング・エントリをキャッシュに挿入してもよく、図５に関して上記に示すようなキャッシュ最適化を実行してもよい。しかしながら、図５の例では、個別のＩＰアドレスのみを検出し、置換えを考慮したが、ホスト７０２における最適化には、プレフィックス表示７１４をすでに含む受信ＩＰアドレス７０８を含む。それにもかかわらず、図５で上記で議論したように、類似の規則を最適化のために適用してもよい。そのＩＰアドレス（範囲）がアドレス７０８とプレフィックス７１４が表示するアドレス範囲内に入る、任意のバインディング・エントリを取り除くことに加えて、例えば、拡張範囲の任意のＩＰアドレスが、ルータの同じＭＡＣアドレスに明確にバインディングしている場合、アドレス範囲の拡張を考慮してもよい。

対応するバインディング・エントリの有効期限がきれない限り、ホスト７０２は、表示されたアドレス範囲１５９．１０７．０．０／１６内に入る任意のＩＰアドレスに対して、更なるＡＲＰ要求を送信する必要はなくてもよい。

図８は、例えば、図７に表示したＡＲＰ要求７０６／ＡＲＰ応答７１０メッセージのペアに使用できる、考えられる修正したＡＲＰメッセージ・フォーマット８００の実施形態を示す。修正ＡＲＰ応答には、図８で“ＩＰ−Ｎｅｔ”と例として名付けた新規のプロトコル・タイプを含めてもよく、それはソース・プロトコル・アドレスとターゲット・プロトコル・アドレスには、追加のフィールド８０４と８０６とを含むということを表示している。通常のＡＲＰ用語に従った用語“ターゲット・アドレス”は、本明細書で使用する用語“ターゲット・ネットワーク・アドレス”と混同してはならない。

ソース・プロトコル・アドレスに関連して、フィールド８０４をソース・プロトコル・アドレス・マスクの表示に提供する。対応して、ターゲット・プロトコル・アドレスに関連するターゲット・プロトコル・アドレス・マスクの表示に、フィールド８０６を提供する。

対応するフィールド８０６は、ターゲット・プロトコル・アドレス、即ち、そこから対応するＡＲＰ要求が発生したホストのアドレス・マスクを含めて提供される。フィールド８０４と８０６は両方とも、例えば、１バイトの長さを持つことができるであろう。ターゲット・プロトコル・アドレス・マスク８０６は、ＡＲＰ応答において３２に設定されてもよい。図７の例を参照して、／１６のプレフィックス表示をＡＲＰ応答７１０において提供しているが、ソース・プロトコル・アドレス・マスク８０４は１６に設定されてもよい。

図８の例では、ＡＲＰ要求メッセージとＡＲＰ応答メッセージに共通フォーマットを使用すると仮定している。もう一つの実施形態では、図８で提案したフォーマットを修正ＡＲＰ応答メッセージにのみ使用してもよく、一方、非修正フォーマットを、即ち、ネットマスク表示無しに、ＡＲＰ要求に使用してもよい。

逆の互換性が特定のネットワークでの課題であれば、プロキシＡＲＰルータは、２個のＡＲＰ応答メッセージ、即ち、プロトコル・タイプ“ＩＰ”として表示する非修正ＡＲＰ応答と、例えば、追加のアドレス・マスク・フィールド８０４と８０８を含む図８のフォーマット８００による修正ＡＲＰ応答とを送信することができるだろう。

プレフィックスベースのバインディング・エントリをホストのバインディング・キャッシュに提供するため、既存のＡＲＰプロトコルを修正する代わりに、新規のプロトコルを実施することも可能であろう。また、両方の方法の組合せを考慮することも可能である。例えば、互換性問題を回避するため、先行するＡＲＰ要求／応答メッセージ・ペア内の個別のソース・ネットワーク・アドレスに適用されるプレフィックス表示（ネットマスク表示）を伝達する新規のプロトコルに従ったメッセージが後に続くネットマスク表示無しに、プロキシＡＲＰルータはＡＲＰ応答メッセージを送信してもよい。プレフィックス表示を受信または処理することに適合していないホストは、単に、新規の本プロトコル・メッセージを無視してもよい。

図９は、表最適化の前９０２と後９０４のＩＰｖ６のＮＤ表を示す。ＩＰｖ６環境での表最適化手順は、多くの点で、図５を参照して、ＩＰｖ４環境でのキャッシュ最適化手順で議論したものと同様な方法で実行してもよい。例えば、ＩＰｖ６のＮＤ表には、図９に示すように、ＩＰｖ４キャッシュと同様なＩＰアドレスと物理アドレスのための列を備える。ＩＰｖ６のアドレス解決は、 “近隣要請”と“近隣通知”のメッセージ・タイプを使用するが、これらのメッセージは、大まかには、ＡＲＰ要求とＡＲＰ応答のＩＰｖ４メッセージにそれぞれ対応する。

図９のＮＤ表には、それらがプレフィックス（表９０２と９０４では、個別のＩＰｖ６アドレスを含むエンティティのためのプレフィックス表示“／６４”を省略した）を処理できるよう、ネットマスクつまりプレフィックス表示を備えてもよい。最適化したＮＤ表９０４により、最適化したＩＰｖ４キャッシュを参照して議論したものと同様な方法で動作する、表最適化手順の結果を示す。

ＩＰｖ６では、近隣探索（ＮＤ）手順は有限状態機械に基づいている。従って、各バインディング・エントリは、起こり得る状態‘インコンプリート’、‘リーチャブル’、‘スレート’、‘ディレイ’および‘プローブ’の中から一つの状態に更に関連付けた。表最適化には、これを考慮しなければならない。近隣通知を受信した場合は周期的に、または、ＮＤ表がインコンプリート状態以外を有する新規エントリを受信する場合は何時でも、表最適化を実行してもよい。更に、適当な方法で、多数の以前のバインディング・エントリを置き換えるバインディング・エントリに対して、状態を決定しなければならない。一つの方法として、新規のバインディング・エントリが、置き換えたエントリの間の最も近いエントリの状態値を受信してもよい。もう一つの可能性は、状態‘インコンプリート’を除く状態値を、リーチャブル⇒スレート⇒ディレイ⇒プローブの順序で順位付けすることである。次に、まとめるべき任意のエントリが状態‘リーチャブル’を持ったなら、新規のエントリをまた‘リーチャブル’に設定するであろう。もしどのエントリも状態‘リーチャブル’を持たないが、しかし、‘スレート’を有する少なくとも一つのエントリがあれば、プレフィックス・エントリは状態として‘スレート’を獲得するであろう、等である。この方法を図９の表の例９０２に適用して、ＩＰｖ６アドレス範囲１５９．１０９．１９９．０／２４のバインディング・エントリに対して、まとめたバインディング・エントリの幾つかは状態‘リーチャブル’をもったので、この状態をまた、表９０４の置換えエントリに割当てる。

図１０は、データ伝送ネットワークの実施形態として、ＩＰｖ４ネットワーク１０００を概略的に示す。論理サブネットワーク１９２．１６８．１．０／２４には、２個の物理ネットワーク１００２と１００４とを備え、それらは２個の異なるＬＡＮであってもよい。２個のサーバが物理ネットワーク１００４に位置し、サーバ１はＩＰアドレス１９２．１６８．１．１を割当てられ、サーバ２はＩＰアドレス１９２．１６８．１．１７を割当てられている。ファイアウォール１００６は物理ネットワーク１００２からサーバ１とサーバ２を分離している。ファイアウォール１００６で、プロキシＡＲＰ機能を作動させる。

サーバ１およびサーバ２の両方のサーバのＡＲＰキャッシュには、ＩＰアドレス範囲１９２．１６８．１．０／２４をファイアウォール１００６のＭＡＣアドレスにバインディングする単一のマスク・エントリを含んでもよい。このエントリに基づき、事前にＡＲＰ要求を同報送信する必要なしに、サーバは物理ネットワーク１００２の任意の宛先ホストに対するデータをファイアウォール１００４に送信でき、同時に、ネットワーク１００２の各々のホストに対して個別のバインディング・エントリを含むキャッシュと比較して、サーバのＡＲＰキャッシュを著しく削減できる。

サブネット１００２のホストは、遠隔物理ネットワーク１００４の任意のサーバに対して個別のバインディング・エントリを持つ可能性があり、個別のエントリが存在し、かつ、それが最長プレフィックス一致のために選ばれない限り、エントリとして、１９２．１６８．１．０／２４をプロキシＡＲＰノード１００６のＭＡＣアドレスにバインディングすることは、サブネット１００２の内部トラヒックの大部分がファイアウォール１００６を介して転送され得るという状況を導くであろう。ホストにおける希望しないキャッシュ最適化を阻むため、図４と図５とを参照して上記で議論した機構のような任意のホスト内部のキャッシュ最適化は、その動作を停止してもよいであろう。加えて、サブネット１００４のサーバ・ファームにのみアドレス範囲表示を提供するよう、そしてアドレス範囲表示無しに従来のＡＲＰ応答をネットワーク１００２に提供するよう、ファイアウォール１００６を構成することができる。例えば、プロキシＡＲＰノード１００６は、ＬＡＮ１００２にのみプレフィックス表示／３２を、そしてＬＡＮ１００４にのみプレフィックス表示／２４を提供してもよい。

ルータ１００６のルーティング表には、ホスト・アドレスとして、サーバ１とサーバ２の個別のサーバ・アドレスを含む、即ち、３２ビットのネットマスクを有するエントリを含むであろう。他方、ＬＡＮ１００２のルーティング・エントリは、ＬＡＮ１００２に向かうインタフェースのファームウエア・アドレスを１９２．１６８．１．０／２４のサブネット・アドレスと関連付けるであろう。それ故、図６を参照して説明したような修正プロキシＡＲＰ機構は、前のパラグラフで説明した動作に至るであろう。

サーバ１がサーバ２と通信したい場合は、アドレス１９２．１６８．１．１７をサーバ２のＭＡＣアドレスにバインディングするもっと特定したエントリを、そのＡＲＰキャッシュで必要とするであろう。その結果、最長のプレフィックス一致原理を適用することは、直接的通信を許容する。例えば、ルータ１００４のＡＲＰ要求をリッスンすることにより、必要な特定のエントリを生成してもよい。

図１１は、データ伝送ネットワークの更なる実施形態として、バックボーン・ネットワーク１１０６に相互接続した、個別の物理ネットワーク１１０２と１１０４を備えるＩＰネットワーク１１００を示す。サブネット１１０２と１１０４の各々には、多数の無線アクセス・ポイント１１０８を備える。ネットワーク１１００は、ＩＰ型モビリティ概念を実装し、移動デバイス１１１０がネットワークにアクセス可能としている。

移動デバイス１１１０はそのホーム・ネットワーク１１０２に属するアドレス範囲の中の固定ＩＰアドレスを持つと仮定する。サブネットワーク１１０４は異なるＩＰアドレス・プレフィックスを持つであろう。デバイス１１００がアクセス・ネットワーク１１０４を介してネットワーク１１００に接続したい場合、アクセス／ルータ（ＡＲ）１１１２はプロキシＡＲＰ機能を提供する。具体的には、ルータ１１１２は、プロキシＡＲＰとして、デバイス１１１０のＡＲＰ要求に答える。この方法では、デバイス１１１０はそのホーム・サブネット１１０２にいると仮定する。アクセス・ルータ１１１２は、ホスト１１１０のホーム・サブネット１１０２に向けてバックボーン１１０６を通して伸びるトンネル１１１４を介して、デバイス１１１０から受信したパケットを転送する。

移動ホスト１１１０は、通常、例えば、確認／権限付与サービス、アプリケーション・サービス、その他のホスト等とのデータまたはマルチメディア通信のようなサービスを要求して、そのホーム・ネットワーク１１０２にある多数のサーバ、ホストまたはノードと通信したい。ホスト１１１０は、図５のキャッシュ５０４と同様の最適化されたＡＲＰキャッシュを持ってもよく、それは、ネットワーク１１０２のサブネット・アドレスを表示するネットワーク・アドレス範囲をアクセス・ルータ１１１２のＭＡＣアドレスに関連付ける、特定のバインディング・エントリを有する。以上に説明した技術のどれを実施してもよく、例えば、ホスト１１１０は、図４のオプティマイザ４１２のようなバインディング・オプティマイザを持ってもよく、またはアクセス・ルータ１１１２は、ホスト１１１０のＡＲＰキャッシュに挿入するため、ＩＰアドレス範囲表示を、例えば、プレフィックス表示の形式で、提供してもよく、またその両方があっても良い。

この方法で、移動ホスト１１１０のＡＲＰキャッシュの規模を著しく削減できる可能性がある。更に、移動ホスト１１１０からサブネット１１０４で同報送信されるＡＲＰ要求の数を著しく削減できる可能性がある。もっと更に、これは、アクセス・ルータ１１１２の処理負担を削減できる可能性がある。具体的には、サブネット１１０４がホスト１１１０のような多くの移動ホストからアクセスされる場合、アクセス・ルータ１１１２の処理負荷を著しく削減できる可能性がある。

図１２は、レイヤ３ＶＰＮ（仮想プリベート・ネットワーク）を実装するデータ伝送ネットワーク１２００の実施形態の概略的な説明図を示す。プロバイダ・エッジ（ＰＥ）デバイスは、カスタマ＃１のカスタマ・サイト１２０４および１２０６とカスタマ＃２のサイト１２０８および１２１０との間で、ＩＰトラヒックを転送するのに要求されるＶＰＮ機能を含むプロバイダ・イーサネット（登録商標）・ネットワーク１２０２に位置する、即ち、ネットワーク１２０２が相互接続するサブネット１２０４と１２０６はカスタマ＃１のためにＶＰＮを形成し、ネットワーク１２０２が相互接続するサブネット１２０８と１２１０はカスタマ＃２のためにＶＰＮを形成する。サイトをプロバイダ・ネットワーク１２０２と接続するため、カスタマ・サブネットワーク１２０４−１２１０の各々にカスタマ装置（ＣＥ）デバイスを提供する。

典型的な状況を図１２に示すが、そこではカスタマ＃１とカスタマ＃２は、それらのそれぞれのＶＰＮで、同じ、即ち、重複するプライベート・アドレス範囲を使用する。例えば、ネットワーク１２０４と１２０８は両方とも、それらのそれぞれのＶＰＮで、ネットワーク・アドレス１６．６．１．０／２４を割当てていた。従って、ネットワーク１２０２のＰＥルータ１２１２と１２１４のため、それぞれの対応するカスタマ・サブネットワークに向けた適当なネットワーク・インタフェースを選択するよう、機構が要求される。この目的のためにレイヤ３機構を使用してもよい。追加して、または代わりに、アドレス解決技術をも実施してもよい。

プロバイダ・ネットワーク１２０２で、カスタマ＃１とカスタマ＃２それぞれのために、ＶＬＡＮ＃１とＶＬＡＮ＃２（図１２で明確には図示せず）の２個のＶＬＡＮを構成してもよい。図１２のカスタマ＃１ネットワーク１２０４からカスタマ＃１ネットワーク１２１０６にＩＰパケット１２６０をたどることにより、アドレス解決技術を典型的に示す。パケットには、サブネットワーク・アドレス範囲１６．６．２．０／２４内に入る宛先ＩＰアドレスを含む。ルータ１２１２と１２１４は、同じ物理ネットワーク１２０２に位置するので、ルータ１２１２は、パケット１２１６の宛先ＩＰアドレスに基づき、次のホップのＭＡＣアドレスを決定するため、ＶＬＡＮ＃１でＡＲＰ要求１２１６を同報送信してもよい。

出口ルータ１２１４は、ＶＬＡＮ＃１のために、プロキシＡＲＰ機能を含む仮想ルータを実装している。従って、ルータ１２１４は、ＡＲＰ応答１２１８を提供することにより、ＡＲＰ要求１２１６に答えてもよい。ＶＬＡＮ＃１のＡＲＰ応答には、ＩＰアドレス範囲１６．６．２．０／２４の表示を備えてもよい。或いは、非修正ＡＲＰ要求／応答機構をＶＬＡＮ＃１で実施してもよく、内部キャッシュ最適化機構を入口ルータ１２１２で提供してもよい。また、両方の機構の組合せを実装できる。どの場合でも、入口ルータ１２１２における仮想ルータのＡＲＰキャッシュは、サブネットワーク１６．６．２．０／２４を出口ルータ１２１４のＭＡＣアドレスにバインディングするエントリを持つであろう。この方法で、ルータ１２１２のＡＲＰキャッシュ規模を著しく削減できる可能性がある。ルータ１２１４のＡＲＰ処理負担を実質的に削減でき、また、ＶＬＡＮ＃１に関する物理ネットワーク１２０２のネットワーク負荷を著しく削減できる。

本明細書で提案した技術は、一般的に、ネットワーク・ホストにおいて、ネットワーク・アドレスと物理アドレスとの関連の数が減少、即ち、削減したバインディング・キャッシュに至る可能性がある。その上、本技術は、同報送信したアドレス解決要求の削減した数のため、データ伝送ネットワークにおけるネットワーク負荷を削減できる可能性がある。更に、ルータ、デフォルト・ゲートウエイ、ファイアウォール等のようなアドレス解決サポートノードにおける、上記のアドレス解決要求を処理する処理負担を削減できる可能性がある。

本発明の好ましい実施形態との関連で本発明について説明したが、この説明は説明の目的のみになされたと理解すべきである。従って、本発明は本明細書に添付した特許請求項の範囲によってのみ制限を受けるということを意図している。

Claims

実装されたＡＲＰ機能を有するアドレス解決サポートノード（１０６，６００，７０４，１００６，１１１２，１２１４）で相互接続された２つの物理ネットワーク（１０２，１０４）を含むデータ伝送ネットワークにおけるアドレス解決の方法であって、前記方法は、データ伝送ネットワーク（１００、１０００、１１００，１２００）の、ＡＲＰキャッシュを有するホスト（１０８、４００、７０２、１１１０、１２１２で実行されるステップを有し、該ステップには、
前記アドレス解決サポートノードに関連付けられた少なくとも一つの物理ＭＡＣアドレスと、複数のＩＰネットワーク・アドレスを含む少なくとも一つのＩＰネットワーク・アドレス範囲との関連を前記ＡＲＰキャッシュに保持するステップ（２０２）と、
ターゲット・ＩＰネットワーク・アドレスを獲得するステップ（２０４）と、
前記ターゲット・ＩＰネットワーク・アドレスを前記ＩＰネットワーク・アドレス範囲と比較して関連するターゲット物理ＭＡＣアドレスを決定するステップ（２０６）と、
決定したターゲット物理ＭＡＣアドレスを提供するステップ（２０８）とを含み、
前記ホストは、個別のＩＰネットワーク・アドレスと個別の物理ＭＡＣアドレスとの関連（５０６）のリスト（５０２）を保持し、
前記保持するステップは、前記リストに含まれた一つの個別の物理ＭＡＣアドレスと関連する複数の個別のＩＰネットワーク・アドレスを特定し、前記複数の個別のＩＰネットワーク・アドレスをひとつのネットワーク・アドレス範囲にまとめてホストの物理アドレスに関連するネットワーク・アドレス範囲を決定するステップをさらに含むことを特徴とする方法。
前記ネットワーク・アドレス範囲が前記データ伝送ネットワークのサブネットワークを表示することを特徴とする請求項１に記載の方法。
前記ネットワーク・アドレス範囲を決定するステップにおいて、少なくとも所定の最小のサブネットワークサイズの範囲に前記ネットワーク・アドレス範囲を設定することを特徴とする請求項１または２のいずれか一項に記載の方法。
前記所定の最小のサブネットワークサイズは、ホストがコンタクトできるルーティング・ノードのルーティングに使用する最小のネットワークサイズを表わすことを特徴とする請求項３に記載の方法。
前記物理アドレスに関連する前記ネットワーク・アドレス範囲の表示（６１６）をホストで受信するステップを更に含む
ことを特徴とする請求項１または２に記載の方法。
前記ターゲット・ネットワーク・アドレスが複数のネットワーク・アドレス範囲と一致する場合、最小の一致するネットワーク・アドレス範囲を決定してターゲット物理アドレスを決定するステップを更に含むことを特徴とする請求項２乃至５の何れか一項に記載の方法。
前記ターゲット・ネットワーク・アドレスが何れのネットワーク・アドレス範囲にも、個別のネットワーク・アドレスにも一致しない場合、前記ターゲット・ネットワーク・アドレスを含むアドレス解決要求を伝送するステップを更に含むことを特徴とする請求項１乃至５の何れか一項に記載の方法。
２つの物理ネットワーク（１０２，１０４）を含むデータ伝送ネットワークにおけるアドレス解決の方法であって、
前記データ伝送ネットワーク（１００、１０００、１１００、１２００）のアドレス解決サポートノード（１０６、６００、７０４、１００６、１１１２，１２１４）において実行されるステップを有し、前記アドレス解決サポートノード（１０６、６００、７０４、１００６、１１１２，１２１４）は前記２つの物理ネットワーク（１０２，１０４）を相互接続し、実装されたＡＲＰ機能を有しており、前記ステップには、
ターゲット・ＩＰネットワーク・アドレスを含むＡＲＰアドレス解決要求（６０４）を受信するステップ（３０２）と、
前記ターゲット・ＩＰネットワーク・アドレスに基づいて、ＩＰネットワーク・アドレス範囲を決定するステップ（３０４）と、
前記アドレス解決サポートノードの物理ＭＡＣアドレスの表示（６１６）と、決定したＩＰネットワーク・アドレス範囲の表示とを含むＡＲＰ応答を応答するステップ（３０６）と
を含むことを特徴とする方法。
前記ネットワーク・アドレス範囲を決定するステップには、前記ターゲット・ネットワーク・アドレスと一致するルーティング表（６０８）のネットワーク・アドレス範囲を見付けるステップを含むことを特徴とする請求項８に記載の方法。
前記ネットワーク・アドレスと前記ネットワーク・アドレス範囲とを表わすのに、単一のアドレス・フォーマットを使用することを特徴とする請求項１乃至９の何れか一項に記載の方法。
前記アドレス・フォーマットには、前記ネットワーク・アドレスか前記ネットワーク・アドレス範囲かのどちらかを表示する範囲インジケータ（７１４）を含むことを特徴とする請求項１０に記載の方法。
一つ以上の計算デバイス上でコンピュータプログラムを実行する場合、請求項１乃至１１の何れか一項のステップを実行するためプログラム・コードを含むことを特徴とするコンピュータプログラム。
請求項１２に記載のコンピュータプログラムを記録したことを特徴とするコンピュータ読み取り可能記録媒体。
実装されたＡＲＰ機能を有するアドレス解決サポートノード（１０６，６００，７０４，１００６，１１１２，１２１４）で相互接続された２つの物理ネットワーク（１０２，１０４）を含むデータ伝送ネットワークにおけるアドレス解決に適したホストであって、
前記アドレス解決サポートノードに関連付けられた少なくとも一つの物理ＭＡＣアドレスと、複数のＩＰネットワーク・アドレスを含む少なくとも一つのＩＰネットワーク・アドレス範囲との関連を保持するＡＲＰキャッシュ（４０２）と、
ターゲット・ＩＰネットワーク・アドレスを獲得する第二の構成要素（４０４）と、
関連するターゲット物理ＭＡＣアドレスを決定するため、前記ターゲット・ＩＰネットワーク・アドレスを前記ＩＰネットワーク・アドレス範囲と比較する第三の構成要素（４０８）と、
決定したターゲット物理ＭＡＣアドレスを提供する第四の構成要素（４１０）とを備え、
前記ホストは、個別のＩＰネットワーク・アドレスと個別の物理ＭＡＣアドレスとの関連（５０６）のリスト（５０２）を保持し、
前記リストに含まれた一つの個別の物理ＭＡＣアドレスと関連する複数の個別のＩＰネットワーク・アドレスを特定し、前記複数の個別のＩＰネットワーク・アドレスをひとつのネットワーク・アドレス範囲にまとめてホストの物理アドレスに関連するネットワーク・アドレス範囲を決定し、前記ＡＲＰキャッシュに保持する構成要素をさらに備えることを特徴とするホスト。
前記物理アドレスに関連する前記ネットワーク・アドレス範囲の表示をホストで受信する更なる要素（４１４）を備えることを特徴とする請求項１４に記載のホスト。
２つの物理ネットワーク（１０２，１０４）を含むデータ伝送ネットワークにおけるアドレス解決をサポートするよう適合したアドレス解決サポートノード（１０５、６００、７０４、１００６、１１１２、１２１４）であって、前記アドレス解決サポートノード（１０６、６００、７０４、１００６、１１１２，１２１４）は前記２つの物理ネットワーク（１０２，１０４）を相互接続し、実装されたＡＲＰ機能を有しており、
ターゲット・ＩＰネットワーク・アドレスを備えるＡＲＰアドレス解決要求（６０４）を受信する第一の要素（６０２）と、
前記ターゲット・ＩＰネットワーク・アドレスに基づき、ＩＰネットワーク・アドレス範囲を決定する第二の要素（６０６）と、
前記アドレス解決サポートノードの物理ＭＡＣアドレスの表示（６１６）と、決定したＩＰネットワーク・アドレス範囲の表示と含むＡＲＰ応答を応答する第三の要素（６１４）と
を備えることを特徴とするアドレス解決サポートノード。
前記アドレス解決サポートノードが前記データ伝送ネットワークにおけるルーティング・ノードであることを特徴とする請求項１６に記載のアドレス解決サポートノード。
データ伝送ネットワーク（１００、１０００、１１００、１２００）であって、
請求項１４または１５に記載したホストと、請求項１６または１７に記載したアドレス解決サポートノードとを備えることを特徴とするデータ伝送ネットワーク。