JP2016536840A

JP2016536840A - 集中型アドレス解決の方法

Info

Publication number: JP2016536840A
Application number: JP2016517481A
Authority: JP
Inventors: ビュイ，ディン・タイ; ル・パレック，ミシェル
Original assignee: アルカテル−ルーセント
Priority date: 2013-09-27
Filing date: 2014-08-13
Publication date: 2016-11-24
Also published as: WO2015043820A1; EP2854377A1; EP2854377B1; US20160197876A1

Abstract

少なくとも１つの処理リソース、少なくとも１つの処理リソースコントローラ、少なくとも１つのネットワークリソース、および少なくとも１つのネットワークリソースソフトウェア定義ネットワークコントローラを含むデータセンタ内の集中型アドレス解決のための方法は以下のステップを含む：− 処理リソースコントローラに制御される処理リソースのすべてのＭＡＣアドレス−ＩＰアドレス関連付けを格納するために、このコントローラに関連付けられたローカルアドレス解決データベース（ＬＤＢ１）を維持するステップと、− ネットワークリソースソフトウェア定義ネットワークコントローラに制御されるネットワークリソースのすべてのＭＡＣアドレス−ＩＰアドレス関連付けを格納するために、このコントローラに関連付けられたローカルアドレス解決データベース（ＬＤＢ２）を維持するステップと、− データセンタ内のすべてのＭＡＣアドレス−ＩＰアドレス関連付けを格納するために、集中型アドレス解決データベース（ＣＡＲＤＢ）を維持するステップと、− リソースがＩＰアドレスの解決をリクエストした際に、このリソースからそのコントローラにユニキャスト読み込みメッセージを送信するステップであって、このコントローラは関連するローカルデータベース（ＬＤＢ１、ＬＤＢ２）がこのＩＰアドレスに関連付けられているＭＡＣアドレスを格納しているかを確認し、− このＩＰアドレスＭＡＣアドレスに関連付けられているＭＡＣアドレスがこのローカルデータベースに格納されている場合、ＭＡＣアドレスを、このＩＰアドレスの解決をリクエストしたリソースに提供し、− このＩＰアドレスＭＡＣアドレスに関連付けられているＭＡＣアドレスがこのローカルデータベースに格納されていない場合、ユニキャスト読み込みメッセージを集中型アドレス解決データベース（ＣＡＲＤＢ）に転送する、送信するステップ。

Description

本発明は全体として、データセンタでのインターネットプロトコルアドレス解決に関する。

データセンタは、物理的に複雑な施設であり、物理サーバ、ネットワークスイッチとルータ、ネットワークサービスアプライアンス、およびネットワークストレージを含む。データセンタの目的は、顧客にアプリケーション、コンピューティングおよび／またはストレージサービスを提供することである。データセンタでは、顧客は「テナント」と呼ばれる。それは、データセンタのコンピュータ、ストレージおよびネットワークリソースの集合に関連した人、企業内の組織、または企業であり得る。テナントに属する仮想レイヤ２または３のドメインは、仮想ネットワークを構成する。データセンタのテナントに提供されるサービスの１つは、仮想インフラストラクチャであり、ＩｎｆｒａｓｔｒｕｃｔｕｒｅａｓａＳｅｒｖｉｃｅとしても知られている。複数の仮想マシンは、ハイパーバイザのサービスを使用して１台の物理コンピュータサーバのリソースを共有する。ハイパーバイザは、仮想マシンをホストする物理コンピュータサーバ上で実行される、サーバ仮想化ソフトウェアである。ハイパーバイザは、自身がホストする仮想マシンに対して、共有のコンピューティング、メモリ、ストレージおよびネットワーク接続を提供する。ハイパーバイザは、しばしば仮想スイッチや仮想ルータなどの仮想ネットワークノードを組み込み、それらは、それぞれ物理イーサネット（登録商標）スイッチまたは物理ＩＰルータと同様のサービスを提供する。ハイパーバイザは、同じ物理サーバ内の仮想マシンと仮想ネットワークインターフェースコントローラとの間で、もしくは仮想マシンと、サーバを物理イーサネットスイッチまたはルータに接続する物理ネットワークインターフェースコントローラカードとの間でフレームを転送する。ハイパーバイザはまた、互いに通信すべきでない仮想マシン間で、ネットワーク分離を実現する。

データセンタはまた、ＳＤＮ（Ｓｏｆｔｗａｒｅ−ｄｅｆｉｎｅｄＮｅｔｗｏｒｋｉｎｇ）と称されるネットワーク仮想化を使用する。これは、ハードウェアリソース、ソフトウェアリソース、およびネットワーク機能をソフトウェアベースの仮想ネットワークに統合するプロセスである。ＳＤＮにより、ネットワーク管理者は個々のネットワークノードを手動で管理することなく、ＳＤＮコントローラを介してネットワークトラフィックに対するプログラム可能な集中制御を実施することができる。ＳＤＮの構成は、データ転送プレーンハードウェアから分離された論理ネットワークコントロールプレーンを作成することができる。つまり、ネットワークノードはパケットを転送することができ、個別のサーバはそのネットワークコントロールプレーン（つまりコントローラ）を動作させることができる。

ローカルエリアネットワークでのアドレス解決は典型的に、ＩＰｖ４（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌｖｅｒｓｉｏｎ４）のＡＲＰ（ＡｄｄｒｅｓｓＲｅｓｏｌｕｔｉｏｎＰｒｏｔｏｃｏｌ、ＩＥＴＦＲＦＣ８２６）プロトコルを使用して実施されている。ＮＤＰ（ＮｅｉｇｈｂｏｒＤｉｓｃｏｖｅｒｙＰｒｏｔｏｃｏｌ、ＩＥＴＦＲＦＣ４８６１）プロトコルは、ＩＰｖ６（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌｖｅｒｓｉｏｎ６）で同様に使用される。これらは、ＩＰアドレスをローカルネットワークで認識される物理マシンアドレスにマッピングする。例えばＩＰｖ４ではアドレスの長さは３２ビットであり、一方で例えばイーサネットローカルエリアネットワークでは物理アドレスの長さは４８ビットである。（この場合、物理マシンアドレスはまた、ＭＡＣ（ＭｅｄｉａＡｃｃｅｓｓＣｏｎｔｒｏｌ）アドレスとも称される）。通常ＡＲＰキャッシュと称されるテーブルは、各ＭＡＣアドレスと対応するＩＰアドレスとの間の相関関係を維持するために利用される。ＡＲＰプロトコルはこの相関関係を作成するためのプロトコルルールを提供し、アドレス変換を提供する。

送信機がローカルエリアネットワーク上の受信機に向けてパケットを送信すると、送信機はまずそのローカルＡＲＰプログラムに物理アドレス、例えば宛先ＩＰアドレスに関連付けられているＭＡＣアドレスを探すように依頼する。ＡＲＰプログラムはＡＲＰキャッシュを検索する。ＡＲＰプログラムが宛先ＭＡＣアドレスを発見すると、ＩＰパケットを正しい長さと形式のＭＡＣフレームにカプセル化して受信機に送信できるように、送信機にＭＡＣアドレスを提供する。ＡＲＰキャッシュに宛先ＩＰアドレスに一致するエントリが見つからない場合、ＡＲＰプロトコルは、あるマシンが自身と関連付けられたこのＩＰアドレスを持っているかを確認するため、ローカルエリアネットワーク上のすべてのマシンに対して特別な形式のリクエストパケットをブロードキャストする。このＩＰアドレスを自身のアドレスとして認識するマシンは、そのハードウェアアドレスを示しつつ応答を返す。送信機内のＡＲＰプロトコルは、将来の参照のためにＡＲＰキャッシュを更新し、次いで、受信機（すなわち、ＡＲＰリクエストに応答したマシン）のＭＡＣアドレスと共にパケットを送信する。

データセンタでは、仮想マシンがどのＩＰアドレスを使用していているか、また物理ネットワークがどのように展開されているかに関わりなく、仮想マシン（または作業負荷）をデータセンタ内のどこにでも配置することができる場合、仮想マシンおよび作業負荷の管理の柔軟性が最大になる。レイヤ３の観点からは、仮想マシンのＩＰアドレスをネットワーク上の実際の接続箇所を反映するように変更する必要がないように、仮想マシンの配置および移動がデータセンタのネットワークのＩＰサブネット境界と衝突しない場合に、データセンタ内の仮想マシンの移動は最も簡単になる。したがって、仮想マシンの管理の観点からは、仮想マシンの移動と関連するすべてのサーバがレイヤ２の同じドメイン上にある場合、操作は簡略化される。しかしながらこれは、大きなレイヤ２ドメインを意味する。ＩＰｖ４でのＡＲＰ、ＩＰｖ６でのＮＤＰを使用したアドレス解決は、非常に大きな数のホスト、例えば仮想マシンを含むデータセンタにおいて、拡張性の懸念を引き起こす。ＩＥＴＦ（ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅ）は、文献ＩＥＴＦＲＦＣ６８２０：ＡｄｄｒｅｓｓＲｅｓｏｌｕｔｉｏｎＰｒｏｂｌｅｍｓｉｎＬａｒｇｅＤａｔａＣｅｎｔｅｒＮｅｔｗｏｒｋｓ − Ｔ．Ｎａｒｔｅｎｅｔａｌ．−２０１３年１月でこの懸念を表明している。彼らは、解決策の仕様を標準化するために、ＡＲＭＤ（ａｄｄｒｅｓｓＲｅｓｏｌｕｔｉｏｎｆｏｒＭａｓｓｉｖｅｎｕｍｂｅｒｏｆｈｏｓｔｓｉｎｔｈｅＤａｔａｃｅｎｔｅｒ：データセンタの莫大な数のホストに対するアドレス解決）というワークグループを発足させた。

データセンタでのアドレス解決に関する従来技術の説明
１）物理ネットワーク全体（厳密にはアンダーレイＩＰネットワーク全体）のレイヤ２ドメインを、拡張可能なＡＲＰブロードキャストドメインに維持しながら拡張するために、ＩＥＴＦＮＶＯ３（ＮｅｔｗｏｒｋＶｉｒｔｕａｌｉｚａｔｉｏｎＯｖｅｒｌａｙｅｒ３）ワークグループで特定されたネットワークのようなオーバーレイネットワークを配備することができる。オーバーレイネットワークは、以下の文献で説明されているようなトンネル方式を使用して構築される：
− ＩＥＴＦｄｒａｆｔ−ｓｒｉｄｈａｒａｎ−ｖｉｒｔｕａｌｉｚａｔｉｏｎ−ｎｖｇｒｅ−０２ − ＮＶＧＲＥ：ＮｅｔｗｏｒｋＶｉｒｔｕａｌｉｚａｔｉｏｎｕｓｉｎｇＧｅｎｅｒｉｃＲｏｕｔｉｎｇＥｎｃａｐｓｕｌａｔｉｏｎ − Ｍ．Ｓｒｉｄｈａｒａｎｅｔａｌ．−２０１３年２月。
− ＩＥＴＦｄｒａｆｔ−ｍａｈａｌｉｎｇａｍ−ｄｕｔｔ−ｄｃｏｐｓ−ｖｘｌａｎ−０４ − ＶＸＬＡＮ：ＡＦｒａｍｅｗｏｒｋｆｏｒＯｖｅｒｌａｙｉｎｇＶｉｒｔｕａｌｉｚｅｄＬａｙｅｒ２ＮｅｔｗｏｒｋｓｏｖｅｒＬａｙｅｒ３Ｎｅｔｗｏｒｋｓ − Ｍ．Ｍａｈａｌｉｎｇａｍｅｔａｌ．−２０１３年５月。

この解決策は、アンダーレイネットワークでの大量の数のマルチキャストツリーの実装、つまりオーバーレイネットワークでのブロードキャストドメインがアンダーレイネットワークでのマルチキャストドメインにマッピングされることを必要とするので、十分ではない。これはアンダーレイネットワーク内に大量のステータスを維持しなければならないことを意味している。

注：レイヤ３オーバーレイネットワークの実装は、大量のシグナリング（例えばＯＳＰＦ（ＯｐｅｎＳｈｏｒｔｅｓｔＰａｔｈＦｉｒｓｔ）シグナリング）など、仮想マシンの移動性に関して他の懸念を引き起こす。

２）他のよく知られた解決策が、文献ＩＥＴＦｄｒａｆｔ−ｓｈａｈ−ａｒｍｄ−ａｒｐ−ｒｅｄｕｃｔｉｏｎ−０２ − ＡＲＰＢｒｏａｄｃａｓｔＲｅｄｕｃｔｉｏｎｆｏｒＬａｒｇｅＤａｔａＣｅｎｔｅｒｓ − Ｈ．Ｓｈａｈｅｔａｌ．−２０１１年１０月により提供されている。この文献は、ネットワーク全体に送信されるＡＲＰブロードキャストの数を減らす方法を提案している。この方法は、ＴｏＲスイッチ（ＴｏｐｏｆＲａｃｋＳｗｉｔｃｈ）、つまり同じラックにインストールされたすべての処理リソースからトラフィックを集約するネットワークノードで適用される。このＴｏＲスイッチは、単にＡＲＰフレームをブロードキャストドメイン全体にブロードキャストするのではなく、それらを賢く処理する。そのような処理が肯定の結果を生成する場合、トップオブラックスイッチからのＡＲＰプロキシの応答は、宛先のＭＡＣアドレスを含む。

この解決策はＴｏＲスイッチの設計を複雑化し、したがってそのコストを増大させるので、十分ではない。実際、ＴｏＲスイッチはこのＴｏＲスイッチを通過するすべてのＡＲＰトラフィックをモニタし、以下の方法で処理しなければならない：
− ＡＲＰリクエストプロトコルデータユニットは、コントロールプレーン中央処理ユニットにリダイレクトされなければならない。
− ＧｒａｔｕｉｔｏｕｓＡＲＰプロトコルデータユニットは、コントロールプレーン中央処理ユニットにリダイレクトされなければならない。
− 他のＡＲＰ応答プロトコルデータユニットは、２度送信されなければならない：複製の１つは、コントロールプレーン中央処理ユニットに送信され、もう１つの複製は通常通り転送される。

これらの動作は、追加の処理パワーとＡＲＰキャッシュのための追加のメモリ空間を必要とする（レイヤ２ドメインが大きくなる可能性がある）。さらに、ＴｏＲスイッチでＡＲＰエージングタイマを使用すると、仮想マシンが移動されたり削除されたりする場合の不整合に至ることがある。例えば、以下のような厄介な状況が生じることがある：ホストＡはトップオブラックスイッチ＃１に接続されており、ホストＢはトップオブラックスイッチ＃２に接続されている。ホストＢがホストＡに対してＡＲＰリクエストを発行し、かつスイッチ＃２でエントリが利用可能な場合、スイッチ＃２はホストＡの代わりにＡＲＰ応答を送信する。ホストＡはすでに利用できない可能性があるが、スイッチ＃２がこのことを知る方法はなく、ホストＡのためのエントリがタイムアウトするまで、スイッチ＃２はホストＡの代わりに応答し続ける。

ＡｄｄｒｅｓｓＲｅｓｏｌｕｔｉｏｎＰｒｏｔｏｃｏｌ、ＩＥＴＦＲＦＣ８２６ＮｅｉｇｈｂｏｒＤｉｓｃｏｖｅｒｙＰｒｏｔｏｃｏｌ、ＩＥＴＦＲＦＣ４８６１ＩＥＴＦＲＦＣ６８２０：ＡｄｄｒｅｓｓＲｅｓｏｌｕｔｉｏｎＰｒｏｂｌｅｍｓｉｎＬａｒｇｅＤａｔａＣｅｎｔｅｒＮｅｔｗｏｒｋｓ − Ｔ．Ｎａｒｔｅｎｅｔａｌ．−２０１３年１月ＩＥＴＦｄｒａｆｔ−ｓｒｉｄｈａｒａｎ−ｖｉｒｔｕａｌｉｚａｔｉｏｎ−ｎｖｇｒｅ−０２ − ＮＶＧＲＥ：ＮｅｔｗｏｒｋＶｉｒｔｕａｌｉｚａｔｉｏｎｕｓｉｎｇＧｅｎｅｒｉｃＲｏｕｔｉｎｇＥｎｃａｐｓｕｌａｔｉｏｎ − Ｍ．Ｓｒｉｄｈａｒａｎｅｔａｌ．−２０１３年２月ＩＥＴＦｄｒａｆｔ−ｍａｈａｌｉｎｇａｍ−ｄｕｔｔ−ｄｃｏｐｓ−ｖｘｌａｎ−０４ − ＶＸＬＡＮ：ＡＦｒａｍｅｗｏｒｋｆｏｒＯｖｅｒｌａｙｉｎｇＶｉｒｔｕａｌｉｚｅｄＬａｙｅｒ２ＮｅｔｗｏｒｋｓｏｖｅｒＬａｙｅｒ３Ｎｅｔｗｏｒｋｓ − Ｍ．Ｍａｈａｌｉｎｇａｍｅｔａｌ．−２０１３年５月ＩＥＴＦｄｒａｆｔ−ｓｈａｈ−ａｒｍｄ−ａｒｐ−ｒｅｄｕｃｔｉｏｎ−０２ − ＡＲＰＢｒｏａｄｃａｓｔＲｅｄｕｃｔｉｏｎｆｏｒＬａｒｇｅＤａｔａＣｅｎｔｅｒｓ − Ｈ．Ｓｈａｈｅｔａｌ．−２０１１年１０月

したがって、データセンタのインターネットプロトコルアドレス解決に対してより良い技術的な解決策を提供する必要がある。

この問題は、本発明による方法によって解決される。

本発明の第１の対象は、少なくとも１つの処理リソース、少なくとも１つの処理リソースコントローラ、少なくとも１つのネットワークリソース、および少なくとも１つのネットワークリソースソフトウェア定義ネットワークコントローラを含むデータセンタ内の集中型アドレス解決のための方法であり、この方法は以下のステップを含む：
− 処理リソースコントローラに制御される処理リソースのすべてのＭＡＣアドレス−ＩＰアドレス関連付けを格納するために、このコントローラに関連付けられたローカルアドレス解決データベースを維持するステップと、
− ネットワークリソースソフトウェア定義ネットワークコントローラに制御されるネットワークリソースのすべてのＭＡＣアドレス−ＩＰアドレス関連付けを格納するために、このコントローラに関連付けられたローカルアドレス解決データベースを維持するステップと、
− データセンタ内のすべてのＭＡＣアドレス−ＩＰアドレス関連付けを格納するために、集中型アドレス解決データベースを維持するステップと、
− リソースがＩＰアドレスの解決をリクエストした際に、このリソースからそのコントローラにユニキャスト読み込みメッセージを送信するステップであって、このコントローラは関連するローカルデータベースがこのＩＰアドレスに関連付けられているＭＡＣアドレスを格納しているかを確認し、
−− このＩＰアドレスＭＡＣアドレスに関連付けられているＭＡＣアドレスがこのローカルデータベースに格納されている場合、ＭＡＣアドレスを、このＩＰアドレスの解決をリクエストしたリソースに提供し、
−− このＩＰアドレスＭＡＣアドレスに関連付けられているＭＡＣアドレスがこのローカルデータベースに格納されていない場合、ユニキャスト読み込みメッセージを集中型アドレス解決データベースに転送する、送信するステップ。

それぞれコントローラに関連付けられているローカルデータベースにより、本発明による方法は、データプレーンの一連のＡＲＰブロードキャストメッセージ（またはＮＤＰマルチキャストメッセージ）を、コントロールプレーンの単一のユニキャストメッセージと置き換えることができる。単一のユニキャストメッセージを使用することは、第１セクションで提示された拡張性の課題を、仮想マシンの移動性に関する柔軟性を低下させることなく解決する。

この方法はまた、それぞれがデータセンタリソースの一部に責任を持つ複数のＳＤＮコントローラを持つアーキテクチャを考慮に入れるので、拡張性を改善する。

本発明の第２の対象は、コンピュータ上でプログラムが実行される際にこの方法を実施するためのコンピュータで実行可能な命令を含むコンピュータプログラム製品である。

本発明の他の特徴および利点は、以下の本発明の実施形態の詳細な説明を付随する図面と併せて考慮することで、より明らかになるであろう。

本発明の実施形態の詳細な特徴および利点を示すために、以下の説明は付随する図面を参照する。

本発明による方法の実施形態を含む典型的なデータセンタの１つの部分を表す略図である。本発明による方法の実施形態を含む典型的なデータセンタの１つの部分を表す略図である。

以下の説明は全体として、ＩＰｖ４のＡＲＰを改善することに焦点を置いているが、説明されている原則がＩＰｖ６のＮＤＰを改善することにも適用され得る（例えば、ネイバ要請（ＮｅｉｇｈｂｏｒＳｏｌｉｃｉｔａｔｉｏｎ）およびネイバアドバタイズメント（ＮｅｉｇｈｂｏｒＡｄｖｅｒｔｉｓｅｍｅｎｔ））。

図１ａおよび図１ｂに表されている典型的なデータセンタは、以下を含む：
− ３つの階層レベルとして構成されるネットワークリソースを介して接続されている仮想マシンＶＭ１、．．．、ＶＭ６である、処理リソース。
− ネットワーク仮想化エッジＮＶＥ１、．．．、ＮＶＥ４は、ネットワークリソースの第１の階層レベルの一部である。各ネットワーク仮想化エッジは、例えばＮＶＯ３ネットワーク（ＮｅｔｗｏｒｋＶｉｒｔｕａｌｉｚａｔｉｏｎＯｖｅｒｌａｙｅｒ３Ｎｅｔｗｏｒｋ）のエッジに位置するネットワークエンティティであり得る。これらは仮想マシンＶＭ１、．．．、ＶＭ６を使用可能にする。これらは、レイヤ２および／またはレイヤ３テナント分離と、テナントアドレス情報（ＭＡＣおよびＩＰアドレス）を隠すこととを可能にするネットワーク仮想化機能を実装する。ネットワーク仮想化エッジは、ハイパーバイザ、物理スイッチ、ルータ、またはネットワークサービスアプライアンス（図では示されていない）内の仮想スイッチの一部として実装され得る。
− ネットワークリソースの第２の階層レベルの一部である、トップオブラックスイッチＴｏＲＳ１、ＴｏＲＳ２、ＴｏＲＳ３。これらはネットワーク仮想化エッジＮＶＥ１、．．．、ＮＶＥ４からのトラフィックを集約する。
− ネットワークリソースの第３の階層レベルの一部であるコア１およびコア２。これらはＴｏＲスイッチＴｏＲＳ１、ＴｏＲＳ２、ＴｏＲＳ３からのトラフィックを集約する集約ノードである。コア１および２は、バックボーン（示されていない）およびワイドエリアネットワークに接続されている。
− データセンタ内に存在するすべてのＭＡＣ−ＩＰアドレス関連付けを格納する、集中型アドレス解決データベースＣＡＲＤＢ。集中型アドレス解決データベースＣＡＲＤＢは、複数の別個のアドレス解決テーブルＴＸ１、ＴＹ１、ＴＺ１として構成されており、テナント識別子−仮想ネットワーク識別子の各ペアに対して１テーブルである。この例では、テーブルＴＸ１は仮想ネットワークＶＮＸ内のテナントＡに対応している。テーブルＴＹ１は仮想ネットワークＶＮＹ内のテナントＡに対応している。テーブルＴＺ１は仮想ネットワークＶＮＺ内のテナントＤに対応している。各テーブル内で、ＭＡＣ−ＩＰ関連付けは、順序付けて格納されている（例えば、ＩＰアドレス順）。
− 複数のローカルアドレス解決データベースＬＤＢ１、ＬＤＢ２。ローカルアドレス解決データベースは各ネットワークリソースＳＤＮコントローラ、および各処理リソースコントローラに関連付けられている。説明を簡略化するために、ここではすべての仮想マシンＶＭ１、．．．、ＶＭ６が単一の処理リソースコントローラに制御され、すべてのネットワークノードが単一のネットワークＳＤＮコントローラに制御されていることを想定している。他の実施形態によれば、より多くのコントローラがあることがあり、それぞれはより少ない量のリソースを制御し、より小さいローカルアドレス解決データベースに関連付けられている。いくつかの例では、ＮＭＳ（ＮｅｔｗｏｒｋＭａｎａｇｅｍｅｎｔＳｙｓｔｅｍ）がネットワークリソースＳＤＮコントローラの役割を果たし得る。各コントローラは、それぞれの関連付けられたローカルデータベースに、その制御されるリソースのＭＡＣおよびＩＰアドレスと、それらのアドレス間の関連付けとに関するすべての情報を格納することに留意されたい。

前述のローカルデータベース（例えばＬＤＢ１、ＬＤＢ２）階層と、集中型データベースＣＡＲＤＢとの間に実装されたアドレス解決データベースの中間階層が存在し得ることに留意されたい。これは、データセンタの大きさやアーキテクチャに依存する。

図１Ａに示されているように、処理リソースコントローラのローカルデータベースＬＤＢ１は３つの別個のアドレス解決テーブルＴＸ２、ＴＹ２、ＴＺ２として構成されており、テナント識別子−仮想ネットワーク識別子の各ペアに対して１テーブルである。これらのアドレス解決テーブルＴＸ２、ＴＹ２、ＴＺ２は、処理リソースＳＤＮコントローラに制御されるすべての処理リソースに対して、ＩＰアドレスとＭＡＣアドレスとの間のすべての関連付けを格納する。

例えば、仮想ローカルエリアネットワークＶＮＸ内のテナントＡに対応するテーブルＴＸ２では：
＠ＩＰ１ − ＠ＭＡＣ１
＠ＩＰ３ − ＠ＭＡＣ３
例えば、仮想ローカルエリアネットワークＶＮＹ内のテナントＡに対応するテーブルＴＹ２では：
＠ＩＰａ − ＠ＭＡＣａ
＠ＩＰｃ − ＠ＭＡＣｃ
＠ＩＰｆ − ＠ＭＡＣｆ
例えば、仮想ローカルエリアネットワークＶＮＺ内のテナントＡに対応するテーブルＴＺ２では：
＠ＩＰ１ − ＠ＭＡＣ１
＠ＩＰ２ − ＠ＭＡＣ２
＠ＩＰ３ − ＠ＭＡＣ３
それで、ローカルアドレス解決データベースＬＤＢ１は、処理リソースＳＤＮコントローラに制御される処理リソースのＭＡＣおよびＩＰアドレスと、それらのアドレス間の関連付けとに関するすべての情報を含む。

同様に、ローカルアドレス解決データベースＬＤＢ２は、３つの別個のアドレス解決テーブルＴＸ３、ＴＹ３、ＴＺ３として構成されており、テナント識別子−仮想ネットワーク識別子の各ペアに対して１テーブルである。これらのアドレス解決テーブルＴＸ３、ＴＹ３、ＴＺ３は、ネットワークリソースＳＤＮコントローラに制御されるすべてのネットワークリソースに対して、ＩＰアドレスとＭＡＣアドレスとの間のすべての関連付けを格納する。

例えば、仮想ローカルエリアネットワークＶＮＸ内のテナントＡに対応するテーブルＴＸ３では：
＠ＩＰ２ − ＠ＭＡＣ２
＠ＩＰ４ − ＠ＭＡＣ４
＠ＩＰ５ − ＠ＭＡＣ５
例えば、仮想ローカルエリアネットワークＶＮＹ内のテナントＡに対応するテーブルＴＹ３では：
＠ＩＰｂ − ＠ＭＡＣｂ
＠ＩＰｄ − ＠ＭＡＣｄ
例えば、仮想ローカルエリアネットワークＶＮＺ内のテナントＡに対応するテーブルＴＺ３では：
＠ＩＰ４ − ＠ＭＡＣ４
＠ＩＰ５ − ＠ＭＡＣ５

それで、ローカルアドレス解決データベースＬＤＢ２は、ネットワークリソースＳＤＮコントローラに制御されるネットワークリソースのＭＡＣおよびＩＰアドレスと、それらのアドレス間の関連付けとに関するすべての情報を含む。

集中型アドレス解決データベースＣＡＲＤＢは、ローカルアドレス解決データベースＬＤＢ１およびＬＤＢ２に書き込まれたエントリを複製することにより、ポピュレートされる。

重要なのは、すべてのコントローラ（該当する場合はＮＭＳを含む）が、本発明による新しいプロトコルを介して集中型アドレス解決データベースＣＡＲＤＢと通信することである。この新しいプロトコルは集中型アドレス解決プロトコルＣＡＲＰと称され、以下で説明される。

本発明によれば、ＣＡＲＰプロトコルは、以下を実行させるために各コントローラ（それぞれローカルアドレス解決データベースＬＤＢ１、ＬＤＢ２と関連付けられている）を集中型アドレス解決データベースＣＡＲＤＢと通信可能にする：
− 衝突検出の仕組みを使用しつつ、集中型アドレス解決データベースＣＡＲＤＢにエントリを書き込む。
− 集中型アドレス解決データベースＣＡＲＤＢからエントリを削除する。
− 集中型アドレス解決データベースＣＡＲＤＢからエントリを読み込む。
− 任意選択で、集中型アドレス解決データベースＣＡＲＤＢが、そのエントリの１つが削除されたことをＳＤＮコントローラに警告するのを可能にする。

提案されたＣＡＲＰプロトコルはまた、仮想マシンＶＭ１、．．．、ＶＭ６とローカルアドレス解決データベースＬＤＢ１との間の通信に使用される。同じように、ＣＡＲＰプロトコルは、ネットワーク仮想化エッジＮＶＥ１、．．．、ＮＶＥ４、トップオブラックスイッチＴｏＲＳ１、ＴｏＲＳ２、ＴｏＲＳ３、コア１およびコア２、ならびにローカルアドレス解決データベースＬＤＢ２などのネットワークノード間の通信に使用される。

提案されたＣＡＲＰプロトコルによれば、アドレス解決手順は以下のステップを含む：
− 各処理リソース（例えば仮想マシン）またはネットワークリソース（例えばルータインターフェース）は、従来のようにＡＲＰリクエストメッセージを仮想ローカルエリアネットワークにブロードキャストするのではなく、ＣＡＲＰ読み込みメッセージをそのＳＤＮコントローラ（例えばコントロールチャネルを介して）に送信する。そのようなＣＡＲＰ読み込みメッセージは、ブロードキャストされる従来のＡＲＰリクエストメッセージと同じ役割を果たすユニキャストメッセージである。
− ＳＤＮコントローラがＣＡＲＰ読み込みメッセージに対する回答を持っていない（つまりそのローカルデータベースに対応するエントリがない）場合、このＣＡＲＰ読み込みメッセージを集中型アドレス解決データベースＣＡＲＤＢに転送する。
− ローカルコントローラおよび集中型アドレス解決データベースＣＡＲＤＢの両方がＣＡＲＰ読み込みメッセージに対する回答を持っていない（つまり、ＣＡＲＰ読み込みメッセージ内に含まれるリクエストに一致するエントリが、どちらのデータベースにも見つからない）場合、処理またはネットワークリソースは最終的に従来のＡＲＰリクエストを仮想ローカルエリアネットワークに対して（つまり、データプレーンに対して）ブロードキャストする。

本発明により、ＩＰホスト（例えば仮想マシンＶＭ１、．．．、ＶＭ６）またはルータからのＩＰインターフェース（例えば仮想ルータの仮想ポート）はほとんどの場合、従来のＡＲＰリクエストメッセージを仮想ローカルエリアネットワークに対してブロードキャストするのではなく、ＭＡＣ−ＩＰアドレス関連付けに関する回答を取得するために、ユニキャストＣＡＲＰ読み込みメッセージをそのコントローラに送信するだけでよい。このようにして、コントロールチャネルで送信されるユニキャスト読み込みメッセージは、データプレーン（例えば仮想ローカルエリアネットワーク）で送信される従来のブロードキャスト／マルチキャストリクエストメッセージを置き換える。これは、従来技術のセクションですでに説明された（データプレーンでの）ＡＲＰブロードキャストの拡張性の課題を解決する。

１−ＣＡＲＰプロトコルの詳細な説明
提案されたＣＡＲＰプロトコルは、所与のテナントに関連する各仮想ローカルエリアネットワークに対して、処理リソースＳＤＮコントローラと関連付けられているローカルアドレス解決データベース内に、別個のローカルアドレス解決テーブルを作成し、維持する。

同様に、提案されたＣＡＲＰプロトコルは、所与のテナントに関連する各仮想ローカルエリアネットワークに対して、ネットワークリソースＳＤＮコントローラと関連付けられているローカルアドレス解決データベース内に、別個のネットワーク関連アドレス解決テーブルを作成し、維持する。

各ローカルアドレス解決テーブル内で、ルックアップ手順を速めるために、エントリは事前定義された順序（例えばＩＰアドレスの昇順）でソートされる。同じＩＰアドレス、および／または同じＭＡＣアドレスは、別のアドレス解決テーブルの一部であり得る（つまり、重複があり得る）ことに留意されたい。

ＣＡＲＰプロトコルでは、ＮＭＳがネットワークＳＤＮコントローラの役割を果たし得ることに留意されたい。しかしながら、あるルータをすでに説明された手順に含めることができない場合（関連するＮＭＳが提案されたＣＡＲＰプロトコルをサポートしないなどの理由で）、データプレーンでの従来のＡＲＰブロードキャストが、それらのルータに関連付けられているアドレスの解決のために適用されるべきである。しかしながら、データセンタでのＡＲＰブロードキャストの拡張性を避けるために、処理リソースおよびネットワークリソース、特に、非常に大きな数、そして非常に動的（例えば作成されてから削除されるまでの時間が短い）になりやすい仮想化されたリソース（例えば仮想マシンおよびネットワーク仮想化エッジ）の最大数を、ＣＡＲＰ手順に含めることが推奨される。

処理リソースコントローラおよびネットワークリソースコントローラのどちらも、ＣＡＲＰプロトコルＷＲＩＴＥメッセージを使用して、それぞれのローカルデータベースＬＤＢ１およびＬＤＢ２のエントリを集中型アドレス解決データベースＣＡＲＤＢに複製する（さらなる詳細は以下を参照のこと）。よく知られているデータベース技術を使用することで、集中型アドレス解決データベースＣＡＲＤＢに書き込む際の重複（例えば同じＩＰアドレスが同じ仮想ネットワーク識別子に対して２度書き込まれること）は回避されるはずである。よく知られたデータベース技術を使用することで、書き込みの衝突も回避されるはずである。

最終的に、集中型アドレス解決データベースＣＡＲＤＢは、ＳＤＮコントローラと関連付けられたすべてのローカルアドレス解決データベースの統合されたバージョンを含む。

集中型アドレス解決データベースＣＡＲＤＢは、そのエントリのそれぞれの出所であるコントローラを追跡する（つまり、どのエントリがどのコントローラによって書き込まれたか）。そのエントリは、出所のコントローラの「色」で「色付けされている」ということができる。

注：ＩＰｖ６では、集中型およびローカルアドレス解決テーブルは以下のような追加の情報を含むことができる：
− ＩＰアドレスに関連付けられているサブネットプレフィックス。
− ＩＰアドレスがホストのアドレスであるか、またはルータインターフェースのアドレスであるかを示すフラグ。

これにより、ＳＤＮコントローラまたは集中型アドレス解決データベースは、同じＩＰｖ６サブネットのネイバのものを集め、所与のＩＰｖ６サブネットにあるルータインターフェースＩＰｖ６アドレスを識別することができる。

２−ＣＡＲＰプロトコルの典型的なメッセージ形式：
ＣＡＲＰメッセージはＩＰ／ＵＤＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ／ＵｎｉｖｅｒｓａｌＤａｔａｇｒａｍＰｒｏｔｏｃｏｌ）ヘッダにより伝達され得る。ＵＤＰポート番号はプロプライエタリな方法で実装することができるが、広範な配備のためには標準化することが望ましい。後者の場合、ＣＡＲＰプロトコルのＵＤＰポート番号はＩＡＮＡ（ＩｎｔｅｒｎｅｔＡｓｓｉｇｎｅｄＮｕｍｂｅｒＡｕｔｈｏｒｉｔｙ）によって割り当てられるべきである。

ＣＡＲＰメッセージはまた、リンクローカルアドレス範囲内で選択された宛先ＭＡＣアドレスと共に、（例えばＳＤＮコントローラと集中型アドレス解決データベースＣＡＲＤＢとの間の）Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔリンクを介してイーサネットヘッダにより伝達され得る。

例示的な実施形態では、ＣＡＲＰメッセージ形式は以下のフィールドを含む：

− ＩＰヘッダ：ＩＰｖ４ヘッダ（ＲＦＣ７９１ − 図４を参照）またはＩＰｖ６ヘッダ（ＲＦＣ２４６０ − 第３章を参照）

− ＵＤＰヘッダ：送信元ポート、宛先ポート、長さ（Ｌｅｎｇｔｈ）（ＵＤＰヘッダ＋ペイロード）、チェックサム（ＲＦＣ７６８を参照）。

− Ｔｙｐｅ（１６ビット）：ＣＡＲＰメッセージの型（Ｔｙｐｅ）を示す。ＣＡＲＰメッセージには４つのＴｙｐｅがある：
Ｔｙｐｅ＝０ｘ１：ＷＲＩＴＥメッセージ
Ｔｙｐｅ＝０ｘ２：ＷＲＩＴＥ＿ＲＥＳＰメッセージ
Ｔｙｐｅ＝０ｘ３：ＲＥＡＤメッセージ
Ｔｙｐｅ＝０ｘ４：ＲＥＡＤ＿ＲＥＳＰメッセージ
Ｔｙｐｅ＝０ｘ５：ＤＥＬＥＴＥメッセージ
Ｔｙｐｅ＝０ｘ６：ＤＥＬＥＴＥ＿ＲＥＳＰメッセージ

− Ｆｌａｇ（１６ビット）：
−− フラグ（ｆｌａｇ）は、「色」の変更を示すためにＷＲＩＴＥメッセージ内で使用される。つまり、ｆｌａｇ＝０ｘ０１は、メッセージに含まれるＩＰ−ＭＡＣペアが、「色」を、ＷＲＩＴＥメッセージを送信するコントローラの色に変更しようとしていることを示す。コントローラは、例えばコントロールネットワーク内のそのＩＰアドレスによって、集中型アドレス解決データベースによって識別されることに留意されたい。
−− フラグは、「色」の変更を示すためにＤＥＬＥＴＥメッセージ内で使用され、Ｆｌａｇ＝０ｘ８１は、メッセージに含まれるＩＰ−ＭＡＣペアが、「色」を、ＤＥＬＥＴＥメッセージを送信するコントローラの色から変更しようとしていることを示す。
−− フラグは、書き込みエラーを示すためにＷＲＩＴＥ＿ＲＥＳＰメッセージ内で使用される：
Ｆｌａｇｓ＝０ｘ０１：ＩＰアドレス重複エラー
Ｆｌａｇｓ＝０ｘ０２：ＭＡＣアドレス重複エラー
Ｆｌａｇｓ＝０ｘ０４：ＩＰｖ６サブネットマスクエラー
Ｆｌａｇｓ＝０ｘＦＦ：未知のエラー
−− フラグは、削除エラーを示すためにＤＥＬＥＴＥ＿ＲＥＳＰメッセージ内で使用される：
Ｆｌａｇｓ＝０ｘＦ１（任意選択）：特殊ＦＬＡＧ（下の注記を参照）
Ｆｌａｇｓ＝０ｘ８１：ＩＰアドレスが存在しない
Ｆｌａｇｓ＝０ｘ８２：ＭＡＣアドレスが存在しない
Ｆｌａｇｓ＝０ｘ８４：ＩＰｖ６サブネットマスクエラー
Ｆｌａｇｓ＝０ｘ８８：エントリが存在しない
Ｆｌａｇｓ＝０ｘＦＦ：未知のエラー

注：任意選択で、集中型アドレス解決データベースＣＡＲＤＢは、他のＳＤＮコントローラに、エントリがちょうど今削除されたことを、出所のＳＤＮコントローラによって（リアルタイムで）警告することができる。このことは、すべてのＳＤＮコントローラに、ＤＥＬＥＴＥ＿ＲＥＳＰメッセージを特殊フラグ（Ｆｌａｇ＝０ｘＦ１）と共に送信することによって実現され得る。この場合、ＳｅｑｕｅｎｃｅＮｕｍｂｅｒフィールドは、メッセージを受信するＳＤＮコントローラに無視される。

− ＳｅｑｕｅｎｃｅＮｕｍｂｅｒ：これはメッセージのシーケンス番号を示す。このフィールドは、Ｒｅｓｐｏｎｓｅメッセージ（つまりＷＲＩＴＥ＿ＲＥＳＰ／ＲＥＡＤ＿ＲＥＳＰ）を、同じシーケンス番号を持つＷＲＩＴＥ／ＲＥＡＤメッセージに関連付けることができる。Ｒｅｓｐｏｎｓｅがない場合、タイマが終了し、同じＷＲＩＴＥ／ＲＥＡＤメッセージを送信する再試行の設定可能な回数が実行される。

− メッセージの残りは、以下で詳細が説明される型−長さ−値（ＴｙｐｅＬｅｎｇｔｈＶａｌｕｅ）（ＴＬＶ）構造体として構成される。

様々な型−長さ−値（ＴｙｐｅＬｅｎｇｔｈＶａｌｕｅ）構造体は、例えば以下のように定義される：

−− ＣｏｎｔｅｘｔＩＤ型−長さ−値（ＴｙｐｅＬｅｎｇｔｈＶａｌｕｅ）：これは、ＩＰまたはＭＡＣアドレスが適用される（アドレス再利用のために）、テナント識別子（テナントＩＤ）および仮想ネットワーク識別子（ＶＮＩＤ）を示す。
注：提案されたＣＡＲＰプロトコルのメッセージにテナント識別子（テナントＩＤ）および仮想ネットワーク識別子（ＶＮＩＤ）があることは、従来のＡＲＰメッセージとの違いの１つである。従来のＡＲＰプロトコルでは、異なるテナントに関連するトラフィックを分離するために、データプレーンはコントロール／管理プレーンにより仮想チャネルに分割される。
これらの識別子は、データセンタ全体でペア（テナントＩＤ、ＶＮＩＤ）の単一性を保証するため、集中型の方式で管理されることに留意されたい。
レイヤ３上のレイヤ２オーバーレイの場合、仮想ネットワーク識別子はレイヤ２ブロードキャストドメイン（またはレイヤ３ＩＰサブネット）を識別することに留意されたい。全体として、仮想ネットワーク識別子はＩＰサブネット識別子として使用され得る。

−− ＩＰｖ４ＴＬＶ：この型−長さ−値（ＴｙｐｅＬｅｎｇｔｈＶａｌｕｅ）は、ＡＲＰリクエストの代わりとして、仮想マシンまたはルータから関連するＳＤＮコントローラに送信されるか、ＳＤＮコントローラから集中型アドレス解決データベースＣＡＲＤＢに送信されるＲＥＡＤメッセージに含まれる。これは、関連するＭＡＣアドレスを必要とするＩＰｖ４アドレスのリストを含む。

−− ＩＰｖ４−ＭＡＣ４８ＴＬＶ：この型−長さ−値（ＴｙｐｅＬｅｎｇｔｈＶａｌｕｅ）は以下に含まれる：
−−− 関連する（つまり、同じＳｅｑｕｅｎｃｅＮｕｍｂｅｒを持つ）ＲＥＡＤメッセージに応じたＲＥＡＤ＿ＲＥＳＰメッセージ。これはＩＰｖ４−ＭＡＣ４８アドレスペアのリストを含む。ＩＰｖ４ＴＬＶ（つまりＲＥＡＤメッセージ）に含まれるいくつかのＩＰｖ４アドレスはＩＰｖ４−ＭＡＣ４８ＴＬＶ（つまりＲＥＡＤ＿ＲＥＳＰメッセージ）のリストにはないことがある。この場合、そのそれぞれのアドレス解決動作が失敗したことを意味する。
−−− 仮想マシン／ルータ（任意選択）から関連するＳＤＮコントローラに、またはＳＤＮコントローラから集中型アドレス解決データベースＣＡＲＤＢに送信されるＷＲＩＴＥメッセージ。前者の場合（任意選択）、仮想マシン／ルータは、コントロールチャネルを使用して、データプレーン上でＩＰアドレスを使用する前に、このＩＰアドレスがアドレス衝突を発生させないかどうかを二重確認することができる。後者の場合、ＳＤＮコントローラは、衝突検出の仕組みを使用しつつ、エントリを集中型アドレス解決データベースＣＡＲＤＢに書き込むことができる。
−−− ＷＲＩＴＥ動作の間にエラーを発生させるＩＰｖ４−ＭＡＣペアをリストするために、ＳＤＮコントローラから仮想マシン／ルータ（任意）に、または集中型アドレス解決データベースＣＡＲＤＢからＳＤＮコントローラに送信されるＷＲＩＴＥ＿ＲＥＳＰメッセージ。エラータイプはＦｌａｇフィールドで示される。
ＩＰｖ４−ＭＡＣ４８ＴＬＶを持たず、Ｆｌａｇフィールドがすべて０に設定されたＷＲＩＴＥ＿ＲＥＳＰメッセージは、関連するＷＲＩＴＥメッセージの処理が１００％成功したことを意味することに留意されたい。
−−− 集中型アドレス解決データベースＣＡＲＤＢでエントリを削除するためにＳＤＮコントローラからそのデータベースに送信されるＤＥＬＥＴＥメッセージ。
−−− ＤＥＬＥＴＥ動作の間にエラーを発生させるＩＰｖ４−ＭＡＣペアをリストするために、集中型アドレス解決データベースＣＡＲＤＢからＳＤＮコントローラに送信されるＤＥＬＥＴＥ＿ＲＥＳＰメッセージ。エラータイプはＦｌａｇフィールドで示される。

−− ＩＰｖ４−ＭＡＣ６４ＴＬＶ：ＭＡＣアドレスのサイズが６４ビットであることを除き、ＩＰｖ４−ＭＡＣ４８ＴＬＶと同様の役割を持つ。

−− ルータ／ネイバリクエストＴＬＶ：この型−長さ−値（ＴｙｐｅＬｅｎｇｔｈＶａｌｕｅ）は、仮想マシンと同じサブネット上のデフォルトルータリストを取得するために、仮想マシンからその関連するＳＤＮコントローラへの、またはＳＤＮコントローラから集中型アドレス解決データベースＣＡＲＤＢへのＲＥＡＤメッセージに含まれる。

−− ルータ／ネイバリストＴＬＶ：この型−長さ−値（ＴｙｐｅＬｅｎｇｔｈＶａｌｕｅ）は、ルータ／ネイバリストを提供するために、ＳＤＮコントローラから仮想マシンへの、または集中型アドレス解決データベースＣＡＲＤＢからコントローラへのＲＥＡＤ＿ＲＥＳＰメッセージに含まれる。

３）仮想マシンが移動する際の動作：
ケース１：通常、仮想マシンの移動は、同じＩＰサブネット内の単一の処理リソースコントローラに管理される（例えば同じハイパーバイザ／物理マシン内の移動）。仮想マシンは、同じＩＰおよびＭＡＣアドレスを維持し、関連するコントローラテーブルのアドレス解決テーブル内においても、集中型アドレス解決データベースＣＡＲＤＢのアドレス解決テーブル内においても、何も修正されない。このようにして、本発明によれば、このような仮想マシンの移動はアドレス解決データベース修正に関連してシームレスである。

ケース２：しかしながら、同じＩＰサブネット内での仮想マシンの移動は、２つの異なる処理リソースコントローラを意味する。それは依然として同じＩＰおよびＭＡＣアドレスを維持する。しかし、処理リソースコントローラはどちらも、それぞれのアドレス解決テーブル内で修正を加える必要があり、一方でエントリを削除し、もう一方でエントリを追加しなければならない。またコントローラはどちらも、集中型アドレス解決データベースが関係するエントリの「色」を変更するように、集中型アドレス解決データベースに通知すべきである。仮想マシンが終了しようとしているコントローラは、集中型アドレス解決データベースＣＡＲＤＢにＤＥＬＥＴＥメッセージを送信し、もう一方は集中型アドレス解決データベースＣＡＲＤＢにＷＲＩＴＥメッセージを送信する。これらのＤＥＬＥＴＥおよびＷＲＩＴＥメッセージは、集中型アドレス解決データベースＣＡＲＤＢに到達する時刻が異なることがある：
− ＷＲＩＴＥメッセージがＤＥＬＥＴＥメッセージよりも先に到達した場合、集中型アドレス解決データベースＣＡＲＤＢはアドレス衝突エラーを（すぐには）発生させない（つまり、アドレス重複Ｆｌａｇフィールドを持つＷＲＩＴＥ＿ＲＥＳＰメッセージで応答する）。そうではなく、ＤＥＬＥＴＥメッセージの到着を待ち、続いて関連するエントリの「色」を変更する。関連するＤＥＬＥＴＥメッセージがタイマの終了までに到達しなかった場合に集中型アドレス解決データベースＣＡＲＤＢがアドレス衝突エラーを発生させるように、タイマを使用することができる。
− ＤＥＬＥＴＥメッセージがＷＲＩＴＥメッセージよりも先に到達した場合、集中型アドレス解決データベースＣＡＲＤＢはテーブル内のエントリを（すぐには）削除しない。そうではなく、関連するＷＲＩＴＥメッセージの到達を待つ。関連するＷＲＩＴＥメッセージがタイマの終了までに受信されなかった場合に集中型アドレス解決データベースＣＡＲＤＢがエントリを削除するように、ここでもタイマを使用することができる。

ケース３：仮想マシンが異なるＩＰサブネットに移動する。この場合、影響を受けるコントローラ（複数可）に関連付けられたテーブル内で、また場合によっては集中型アドレス解決データベースＣＡＲＤＢのテーブル内で（２つのコントローラが関係している場合）、古いエントリが削除され、新しいエントリが追加されるべきである。

本発明による方法は、複雑さをＴｏＲスイッチ（つまり、特定のハードウェア）からコントローラおよび集中型データベース（つまり、汎用のハードウェア）に移動するという利点もある。これによりコストを削減する。

Claims

少なくとも１つの処理リソース、少なくとも１つの処理リソースコントローラ、少なくとも１つのネットワークリソース、および少なくとも１つのネットワークリソースソフトウェア定義ネットワークコントローラを含むデータセンタ内の集中型アドレス解決のための方法であって、
− 処理リソースコントローラに制御される処理リソースのすべてのＭＡＣアドレス−ＩＰアドレス関連付けを格納するために、このコントローラに関連付けられたローカルアドレス解決データベース（ＬＤＢ１）を維持するステップと、
− ネットワークリソースソフトウェア定義ネットワークコントローラに制御されるネットワークリソースのすべてのＭＡＣアドレス−ＩＰアドレス関連付けを格納するために、このコントローラに関連付けられたローカルアドレス解決データベース（ＬＤＢ２）を維持するステップと、
− データセンタ内のすべてのＭＡＣアドレス−ＩＰアドレス関連付けを格納するために、集中型アドレス解決データベース（ＣＡＲＤＢ）を維持するステップと、
− リソースがＩＰアドレスの解決をリクエストした際に、このリソースからそのコントローラにユニキャスト読み込みメッセージを送信するステップであって、このコントローラは関連するローカルデータベース（ＬＤＢ１、ＬＤＢ２）がこのＩＰアドレスに関連付けられているＭＡＣアドレスを格納しているかを確認し、
−− このＩＰアドレスＭＡＣアドレスに関連付けられているＭＡＣアドレスがこのローカルデータベースに格納されている場合、ＭＡＣアドレスを、このＩＰアドレスの解決をリクエストしたリソースに提供し、
−− このＩＰアドレスＭＡＣアドレスに関連付けられているＭＡＣアドレスがこのローカルデータベースに格納されていない場合、ユニキャスト読み込みメッセージを集中型アドレス解決データベース（ＣＡＲＤＢ）に転送する、送信するステップと
を含む、方法。
リソースからそのコントローラへのユニキャスト読み込みメッセージが、テナント識別子（テナントＩＤ）および仮想ネットワーク識別子（ＶＮＩＤ）を含む、請求項１に記載の方法。
データセンタ内のすべてのＭＡＣアドレス−ＩＰアドレス関連付けを格納するために、集中型アドレス解決データベース（ＣＡＲＤＢ）を維持するステップが、各コントローラがこのコントローラに関連付けられたローカルデータベース（ＬＤＢ１、ＬＤＢ２）に書き込まれた各エントリを集中型データベース（ＣＡＲＤＢ）に複製するステップを含む、請求項１に記載の方法。
データセンタ内のすべてのＭＡＣアドレス−ＩＰアドレス関連付けを格納するために、集中型アドレス解決データベース（ＣＡＲＤＢ）を維持するステップが、コントローラが、集中型データベース（ＣＡＲＤＢ）に複製されたそのエントリのそれぞれと関連してこのコントローラを識別するいくらかの情報を、集中型アドレス解決データベース（ＣＡＲＤＢ）に書き込むステップを含む、請求項３に記載の方法。
コントローラが集中型データベースに複製した１つのエントリが削除された際に、集中型データベース（ＣＡＲＢＤ）からこのコントローラに警告メッセージを送信するステップをさらに含む、請求項１に記載の方法。
− 処理リソースコントローラに関連付けられたローカルアドレス解決データベース（ＬＤＢ１）が、テナント識別子−仮想ネットワーク識別子の各ペアに対する１つのテーブルを含むように、複数のテーブル（ＴＸ２、ＴＹ２、ＴＺ２）として構成され、
− ネットワークリソースソフトウェア定義ネットワークコントローラに関連付けられたローカルアドレス解決データベース（ＬＤＢ２）が、テナント識別子−仮想ネットワーク識別子の各ペアに対する１つのテーブルを含むように、複数のテーブル（ＴＸ３、ＴＹ３、ＴＺ３）として構成され、
− 集中型アドレス解決データベース（ＣＡＲＤＢ）が、テナント識別子−仮想ネットワーク識別子の各ペアに対する１つのテーブルを含むように、複数のテーブル（ＴＸ１、ＴＹ１、ＴＺ１）として構成される、請求項１に記載の方法。
集中型アドレス解決データベース（ＣＡＲＤＢ）を維持するステップが、集中型アドレス解決データベース内で、エントリの出所である各コントローラを追跡するステップを含む、請求項１に記載の方法。
マシンが第１の処理リソースコントローラおよび次いで第２のリソースコントローラに制御されるように、マシンが同じＩＰサブネット内で移動する場合、集中型アドレス解決データベース（ＣＡＲＤＢ）を維持するステップが、
− 第１のコントローラが、エントリを削除するために集中型アドレス解決データベース（ＣＡＲＤＢ）にＤＥＬＥＴＥメッセージを送信するステップと、
− 第２のコントローラが、新しいエントリを追加するために集中型アドレス解決データベース（ＣＡＲＤＢ）にＷＲＩＴＥメッセージを送信するステップと、
− 集中型アドレス解決データベースに、第２のコントローラが新しいエントリの出所であることを通知するステップと、
− さらに、
−− ＷＲＩＴＥメッセージがＤＥＬＥＴＥメッセージよりも先に到達した場合、集中型アドレス解決データベース（ＣＡＲＤＢ）は、新しいエントリを書き込む前に、所定の時間間隔の間ＤＥＬＥＴＥメッセージの到達を待ち、
−− ＤＥＬＥＴＥメッセージがＷＲＩＴＥメッセージよりも先に到達した場合、集中型アドレス解決データベース（ＣＡＲＤＢ）は、新しいエントリを書き込む前に、所定の時間間隔の間関連するＷＲＩＴＥメッセージの到達を待ち、所定の時間間隔の終了前に関連するＷＲＩＴＥメッセージを受信しない場合、削除されるべきエントリを削除するステップとを含む、請求項７に記載の方法。
マシンで実行可能なプログラム命令のセットを格納するデジタルデータ記憶媒体であって、プログラム命令はコンピュータ上で実行されると、
− 処理またはネットワークリソースコントローラに関連付けられたローカルアドレス解決データベース（ＬＤＢ１、ＬＤＢ２）を維持するステップであって、前記コントローラにより制御されるリソースに関連するすべてのＭＡＣアドレス−ＩＰアドレス関連付けを格納するための、維持するステップと、
− ローカルデータベース（ＬＤＢ１、ＬＤＢ２）に格納された各エントリを集中型データベース（ＣＡＲＤＢ）に複製することにより、データセンタ内のすべてのＭＡＣアドレス−ＩＰアドレス関連付けを格納するために、集中型アドレス解決データベース（ＣＡＲＤＢ）を維持するステップと、
− リソースがＩＰアドレスの解決をリクエストした際に、このリソースからユニキャスト読み込みメッセージを受信し、次いでこのリソースを制御するコントローラに関連付けられたローカルデータベース（ＬＤＢ１、ＬＤＢ２）がこのＩＰアドレスに関連付けられているＭＡＣアドレスを格納しているかを確認するステップであって、
−− このＩＰアドレスに関連付けられているＭＡＣアドレスがこのローカルデータベースに格納されている場合、ＭＡＣアドレスを、このＩＰアドレスの解決をリクエストしたリソースに提供し、
−− このＩＰアドレスＭＡＣアドレスに関連付けられているＭＡＣアドレスがこのローカルデータベースに格納されていない場合、ユニキャスト読み込みメッセージを集中型アドレス解決データベース（ＣＡＲＤＢ）に転送する、確認するステップと
をコンピュータに実施させる、デジタルデータ記憶媒体。
コンピュータ上でプログラムが実行される際に方法を実施するためのコンピュータで実行可能な命令を含むコンピュータプログラム製品であって、方法は、
− 処理またはネットワークリソースコントローラに関連付けられたローカルアドレス解決データベース（ＬＤＢ１、ＬＤＢ２）を維持するステップであって、前記コントローラにより制御されるリソースに関連するすべてのＭＡＣアドレス−ＩＰアドレス関連付けを格納するための、維持するステップと、
− ローカルデータベース（ＬＤＢ１、ＬＤＢ２）に格納された各エントリを集中型データベース（ＣＡＲＤＢ）に複製することにより、データセンタ内のすべてのＭＡＣアドレス−ＩＰアドレス関連付けを格納するために、集中型アドレス解決データベース（ＣＡＲＤＢ）を維持するステップと、
− リソースがＩＰアドレスの解決をリクエストした際に、このリソースからユニキャスト読み込みメッセージを受信し、次いでこのリソースを制御するコントローラに関連付けられたローカルデータベース（ＬＤＢ１、ＬＤＢ２）がこのＩＰアドレスに関連付けられているＭＡＣアドレスを格納しているかを確認するステップであって、
−− このＩＰアドレスに関連付けられているＭＡＣアドレスがこのローカルデータベースに格納されている場合、ＭＡＣアドレスを、このＩＰアドレスの解決をリクエストしたリソースに提供し、
−− このＩＰアドレスＭＡＣアドレスに関連付けられているＭＡＣアドレスがこのローカルデータベースに格納されていない場合、ユニキャスト読み込みメッセージを集中型アドレス解決データベース（ＣＡＲＤＢ）に転送する、確認するステップと
を含む、コンピュータプログラム製品。