JP5830093B2

JP5830093B2 - 非対称ネットワーク・アドレス・カプセル化

Info

Publication number: JP5830093B2
Application number: JP2013518676A
Authority: JP
Inventors: リンダダンバー; グオリイン
Original assignee: ホアウェイ・テクノロジーズ・カンパニー・リミテッド
Priority date: 2010-06-29
Filing date: 2011-06-29
Publication date: 2015-12-09
Anticipated expiration: 2031-06-29
Also published as: US10367730B2; RU2551814C2; CN104396192A; SG186487A1; US9014054B2; EP2569905A2; RU2013103703A; BR112012033693A2; CN102971992A; WO2012006198A2; US20150222534A1; WO2012006170A2; US20120008528A1; US20150078387A1; CN108200225A; BR112012033693B1; US10389629B2; CN102971992B; CN108200225B; US8937950B2

Description

合衆国政府によって支援された研究または開発に関する陳述
非該当

マイクロフィッシュ付属物への言及
非該当

最新の通信およびデータネットワークは、ネットワークを介してデータを運ぶノードを備える。これらのノードは、個別のデータパケットまたはフレームをネットワークを介して運ぶルータ、スイッチ、ブリッジ、またはこれらの組み合わせを含むことがある。

一部のネットワークは、中間ノード上に予め構成されたルートを使用することなくネットワークを越えて一方のノードから別のノードへデータフレームを転送するデータサービスを提供する。他のネットワークは、予め構成された、または、予め確立されたパスに沿ってネットワークを越えて一方のノードから別のノードへデータフレームを転送することがある。

一実施形態では、開示は、複数のノードに接続され、ノードからの複数の出力フレームにヘッダを付加することにより出力フレームをカプセル化するために構成されているスイッチと、ローカルサイト内の複数のローカルノードに接続されている複数のローカルスイッチに接続されている複数のダウンストリームポート、および、ネットワーク内の複数のリモートゲートウェイと複数のコアスイッチとに接続され、入力フレームからヘッダを除去することにより、リモートゲートウェイより下にある複数のリモートノードからスイッチを含むゲートウェイより下にあるローカルスイッチを介して接続されているローカルノードへの複数の入力フレームをカプセル化解除するために構成されているアップストリームポートを備えるゲートウェイと、を備え、スイッチによってヘッダを出力フレームに付加することは、ノードからの出力フレームを転送するために使用されるネットワークにおけるリモートゲートウェイおよびコアスイッチ内の転送アドレステーブルのサイズを縮小する装置を含む。

別の実施では、開示は、ローカルホストからの出力フレームを受信するために構成されている受信機と、出力フレーム中のターゲットホストの宛先アドレス（ＤＡ）をターゲットホストのターゲットロケーションのＤＡにマッピングし、ターゲットロケーションのＤＡを使用して出力フレームをカプセル化するために構成されている論理回路と、ローカルスイッチからの予めカプセル化された出力フレームを受信し、予めカプセル化された出力フレームをターゲットロケーションにあるゲートウェイに送信するために構成されている送信機とを備え、送信機は、ローカルスイッチから受信されたフレームをカプセル化せず、ローカルホストに向けられたリモートゲートウェイからの入力フレームをカプセル化解除する、ネットワークコンポーネントを含む。

さらに別の実施形態では、開示は、ローカルノードにおいてローカルホストからリモートホストを宛先とされたフレームを受信するステップと、リモートホストのアドレスマッピングを取り出すためにアドレス解決要求をアドレス解決・プロトコル（ＡＲＰ）またはネイバー・ディスカバリ（ＮＤ）／ディレクトリ・サービス（ＤＳ）サーバに送信するステップと、リモートホストのアドレスマッピングに基づいて外部ヘッダをフレームに付加するステップと、リモート・ゲートウェイ・スイッチを介してリモートホストにフレームを転送するゲートウェイスイッチにフレームを送信するステップと、を備える方法を含む。

これらの特徴および他の特徴は、添付図面および請求項と併せて以下の詳細な説明から明瞭に理解されるであろう。

本開示のより完全な理解のため、今度は、同じ符号が同じ部品を表す添付図面および詳細な説明と併せて以下の簡単な説明が参照される。

仮想プライベート・ローカル・エリア・ネットワーク（ＬＡＮ）サービス（ＶＰＬＳ）相互接続型ＬＡＮの実施形態の概略図である。仮想レイヤ２ネットワークの実施形態の概略図である。ボーダー・コントロール・メカニズムの実施形態の概略図である。データフレーム転送スキームの実施形態の概略図である。データフレーム転送スキームの別の実施形態の概略図である。データフレーム転送スキームの別の実施形態の概略図である。相互接続型レイヤ２サイトの実施形態の概略図である。複数のアドレスドメインに亘るレイヤ２拡張の実施形態の概略図である。複数のアドレスドメインに亘るスードレイヤ２ネットワークの実施形態の概略図である。ドメインアドレス制約メカニズムの実施形態の概略図である。データフレーム転送スキームの別の実施形態の概略図である。データフレーム転送スキームの別の実施形態の概略図である。データフレーム転送スキームの別の実施形態の概略図である。データフレーム転送スキームの別の実施形態の概略図である。ブロードキャストスキームの実施形態の概略図である。ブロードキャストスキームの別の実施形態の概略図である。相互接続型ネットワーク区域の実施形態の概略図である。相互接続型ネットワーク区域の別の実施形態の概略図である。ＡＲＰプロキシスキームの実施形態の概略図である。データフレーム転送スキームの別の実施形態の概略図である。ＡＲＰプロキシスキームの別の実施形態の概略図である。フェイルオーバースキームの実施形態の概略図である。物理サーバの実施形態の概略図である。非対称ネットワーク・アドレス・カプセル化スキームの実施形態の概略図である。ＡＲＰ処理スキームの実施形態の概略図である。拡張ＡＲＰペイロードの実施形態の概略図である。別のデータフレーム転送スキームの実施形態の概略図である。機能強化ＡＲＰ処理方法の実施形態のプロトコル図である。拡張アドレス解決方法の実施形態のプロトコル図である。ネットワーク・コンポーネント・ユニットの実施形態の概略図である。汎用コンピュータシステムの実施形態の概略図である。

１つ以上の実施形態の例示的な実施が以下に記載されるが、開示されたシステムおよび／または方法は、現在のところ知られているか、既存であるかどうかとは無関係に、かなりの数の技術を使用して実施されることが最初に理解されるべきである。開示は、本書に例示され、記載された典型的な設計および実施を含めて、例示された実施形態、図面、および以下に例示された技術に決して限定されるべきではなく、請求項の均等物の全範囲に加えて請求項の範囲内で変更されてもよい。

レイヤ２またはレイヤ３ネットワークになり得る最新のデータネットワークは、複数のロケーションまたはサイトに亘って広がることを必要とすることがあるクラウドサービスおよび仮想マシン（ＶＭ）への接続性を提供する。サーバ（またはＶＭ）のクラスタとストレージ機器とを接続するデータセンタのためのレイヤ２ネットワークは、時には複数のロケーションに亘って広がることが必要である。データセンタネットワークは、配備済みのアプリケーションをサポートし、したがって、たとえば、何百万ドルもコストを節約するために、レイヤ２レベルに留まることをさらに必要とすることがある。サーバのクラスタおよび／またはストレージ機器の間のレイヤ２通信は、ロードバランシング、データベースクラスタリング、仮想サーバ故障復旧、ネットワークレイヤ（レイヤ３）より下のトランスペアレントオペレーション、複数のロケーションに亘るサブネットの拡散、および冗長性を含む。レイヤ２通信は、アプリケーション間のキープ・アライブ・メカニズムをさらに含む。一部のアプリケーションは、一方のサーバがアクティブでもよく、別のサーバがスタンバイでもよい複数のロケーション上で通信するために同じＩＰアドレスを必要とする。（異なるロケーションにある）アクティブサーバおよびスタンバイサーバは、両者間でキープ・アライブ・メッセージを交換することがあり、これらのメッセージは、レイヤ２キープ・アライブ・メカニズムを必要とすることがある。

図１は、ＶＰＬＳ相互接続型ローカル・エリア・ネットワーク（ＬＡＮ）１００の実施形態を例示する。ＶＰＬＳ相互接続型ＬＡＮ１００は、ユニファイドまたはフラット・レイヤ２ネットワークを確立するために、複数のＤＣロケーション、たとえば、物理ロケーションに亘ってレイヤ２ネットワークを接続するために使用され得るスケーラブルメカニズムである。ＶＰＬＳ相互接続型ＬＡＮ１００は、ＶＰＬＳ１１０と、エッジルータのような複数のエッジノード１１２を介してＶＰＬＳ１１０に接続されることがある複数のＬＡＮ１２０とを備えることがある。個々のＬＡＮ１２０は、対応するエッジノード１１２に接続された複数のレイヤ２スイッチ１２２と、対応するレイヤ２スイッチに接続された複数のアクセススイッチ１２４と、対応するアクセススイッチ１２４に接続された複数のＶＭ１２６とを備えることがある。ＶＰＬＳ相互接続型ＬＡＮ１００のコンポーネントは、図１に示されるように配置されることがある。

ＶＰＬＳ１１０は、異なるロケーションまたはＤＣに亘ってＬＡＮ１２０を接続するために構成されているどのようなネットワークでもよい。たとえば、ＶＰＬＳ１１０は、異なるＤＣに亘ってＬＡＮ１２０を相互接続するためにレイヤ３ネットワークを備えることがある。レイヤ２スイッチ１２２は、開放型システム相互接続（ＯＳＩ）モデル・データ・リンク層で通信するために構成されることがある。データ・リンク・プロトコルの実施例は、ＬＡＮ用イーサネット（登録商標）、ポイント・ツー・ポイント・プロトコル（ＰＰＰ）、ハイレベル・データ・リンク制御（ＨＤＬＣ）、および、ポイント・ツー・ポイント接続用アドバンストデータ通信制御プロトコル（ＡＤＣＣＰ）を含む。アクセススイッチ１２４は、レイヤ２スイッチ１２２とＶＭ１２６との間でデータを転送するため構成されることがある。ＶＭ１２６は、システムプラットフォーム、たとえば、オペレーティング・システム（ＯＳ）を提供するシステム仮想マシン、および／または、プログラムもしくはアプリケーションを動かすプロセス仮想マシンを備えることがある。個々のＬＡＮ１２０におけるＶＭ１２６は、複数のプロセッサ、中央プロセッサ・ユニット（ＣＰＵ）、またはコンピュータシステムに亘って分散させられることがある。ＬＡＮ１２０における複数のＶＭ１２６は、ディスク空間、メモリ、プロセッサ、および／または他のコンピューティングリソースのような同じシステムリソースを共用することもある。ＶＭ１２６は、シェルフに配置され、かつ、たとえば、アクセススイッチ１２４を介して、対応するＬＡＮ１２０に接続されることがある。

ＶＰＬＳ相互接続型ＬＡＮ１００の一部の態様は、非現実的な、または、望ましくない実施問題をもたらすことがある。一態様では、ＶＰＬＳ１１０は、マルチ・プロトコル・ラベル・スイッチング（ＭＰＬＳ）をサポートするワイド・エリア・ネットワーク（ＷＡＮ）を実施することを必要とすることがある。しかし、一部のオペレータは、ＷＡＮを介したＭＰＬＳをサポートしないので、ＶＰＬＳ相互接続型ＬＡＮ１００の実施が困難になることがある。さらに、ホスト・リンク層アドレスを解決するため、たとえば、ＬＡＮ１２０を越えるＶＭ１２６に対し、両方共に参照によってここに組み込まれるインターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ）リクエスト・フォー・コメント（ＲＦＣ）８２６に記載されるＩＰｖ４ＡＲＰ、および、ＩＥＴＦＲＦＣ４８６１によって記載されるＩＰｖ６ＮＤのようなＩＰバージョン４（ＩＰｖ４）ＡＲＰまたはＩＰバージョン６（ＩＰｖ６）ＮＤプロトコルが必要とされることがある。ＡＲＰは、すべての相互接続型ＬＡＮ１２０への要求をフラッディングさせ、よって、大量のシステムリソース（たとえば、帯域幅）を使い尽くすことがある。このようなＡＲＰフラッディングメカニズムは、ＬＡＮ１２０および／またはＶＭ１２６の個数が増加するのにつれて、スケーラビリティ問題に陥ることがある。ＶＰＬＳ相互接続型ＬＡＮ１００は、ＬＡＮ１２０に接続するためにメッシュ状スードワイヤ（ＰＷ）をセットアップすることも必要であり、このことは、トンネルの集中的な構成および状態維持を必要とすることがある。一部のシナリオでは、ＶＰＬＳ１１０は、ＬＡＮ１２０を発見し、個々のＬＡＮ１２０に対しメッシュ状ＰＷを構築するためにボーダー・ゲートウェイ・プロトコル（ＢＧＰ）を使用することがある。

オプティカル・トランスポート仮想化（ＯＴＶ）は、フラット・レイヤ２ネットワークを確立するために、複数のロケーションまたはＤＣを越えてレイヤ２ネットワークを接続するため提案された別のスケーラブルメカニズムである。ＯＴＶは、レイヤ２通信のＩＰカプセル化に依存してＣｉｓｃｏによって提案された方法である。ＯＴＶは、個々のロケーション（たとえば、ＤＣ）の内部のＭＡＣ到達可能性を他のロケーションに分散させるために中間システム対中間システム（ＩＳ−ＩＳ）ルーティングプロトコルを使用することがある。ＯＴＶスキームは、一部の非現実的な、または、望ましくない態様をさらに有することがある。一態様では、ＯＴＶは、プロバイダコアＩＰネットワークにより比較的多数のマルチキャストグループを維持することを必要とすることがある。個々のＬＡＮは、別個のオーバーレイトポロジを有することがあるので、サービス・プロバイダＩＰネットワークによって維持された比較的多量のオーバーレイトポロジが存在することがあり、このことは、コアネットワークに負担をもたらすことがある。ＯＴＶは、エッジノードがＩＰドメイン内の異なるマルチキャストグループに参加するためにインターネット・グループ・マネジメント・プロトコル（ＩＧＭＰ）を使用することをさらに必要とすることがある。個々のエッジノードが複数のＶＬＡＮに接続されている場合、エッジノードは、複数のＩＧＭＰグループに参加することを必要とすることがある。

ＯＴＶでは、個々のロケーションにあるゲートウェイのようなエッジ機器は、互いに１ホップ離れているＩＰホストでもよく、これは、到達可能性情報を交換するためにエッジ機器間でリンク・ステート・プロトコルを実施することを必要としないことがある。しかし、リンク・ステートは、ピアを認証するために使用されることもあり、これは、ピアがＩＧＭＰバージョン３（ＩＧＭＰｖ３）リポートを送信することによりＶＬＡＮに参加する場合にＯＴＶにおいて必要とされることがある。代替的に、ＯＴＶは、ＢＧＰ認証方法を使用することがある。しかし、ＢＧＰ認証タイミングは、ＩＳ−ＩＳ認証タイミングと異なることがある。たとえば、ＢＧＰは、数秒単位で性能を調整され、ＩＳ−ＩＳは、サブ秒単位で性能を調整されることがある。さらに、ＩＳ−ＩＳプロトコルは、ＯＴＶシステム内の個々のロケーションにおいてかなり多数、たとえば、数万のホストおよびＶＭを取り扱うため適切ではないことがある。ＯＴＶは、数万の閉じたユーザグループをサポートするため不適切になることもある。

ここに開示されているのは、フラットまたは単一レイヤ２ネットワークを取得するため複数の異なるロケーションにある複数のレイヤ２ネットワークを接続するためにスケーラブルメカニズムを提供するシステムおよび方法である。スケーラブルメカニズムは、複数のロケーションに亘って広がるフラット・レイヤ２ネットワークを取得する態様または難題を解決することがある。スケーラブルメカニズムは、アプリケーションのためのスケーラブル・アドレス解決をサポートし、ネットワークスイッチがロケーションを越える全部または複数のホストと関連付けられた複数のアドレスを維持することを可能にすることによりロケーションを越えるトポロジ・ディスカバリを容易化することがある。スケーラブルメカニズムは、たとえば、未知ホストアドレスのための異なるロケーションを越えるトラフィックの転送とトラフィックのブロードキャストとをさらに容易化し、マルチキャストグループをサポートすることがある。

これらの方法は、複数のロケーションに亘る比較的大きいフラット・レイヤ２をスケーリングするためにボーダー・コントロール・メカニズムを含む。したがって、アプリケーション、サーバ、および／またはＶＭは、レイヤ３、レイヤ２．５、またはレイヤ２ネットワークのような別のネットワークによって相互接続された複数のレイヤ２ネットワークを備える仮想レイヤ２ネットワークを知らないことがある。レイヤ２ネットワークは、異なった、または、別個の物理ロケーション、１つのロケーションの複数のフロア、または、レイヤ３によって相互接続された複数の列に位置することがある。プロトコル非依存アドレス解決・メカニズムは、複数のロケーションに亘る比較的大きい仮想レイヤ２ネットワークおよび／または実質的に多数のレイヤ２ネットワークを取り扱うために使用され、適していることがある。

図２は、異なるＤＣまたは物理ロケーションを越える仮想レイヤ２ネットワーク２００の実施形態を例示する。仮想レイヤ２ネットワーク２００は、ユニファイドまたはフラット・レイヤ２ネットワークを確立するために、複数のロケーション、たとえば、地理的ロケーションもしくはＤＣ、または、１台のデータセンタ内部の複数のサイトを越えるレイヤ２ネットワークを接続するスケーラブルメカニズムでもよい。仮想レイヤ２ネットワーク２００は、サービスネットワーク２１０と、エッジルータのような複数のエッジノード２１２を介してサービスネットワーク２１０に接続されることがある複数のレイヤ２ネットワーク２２０とを備えることがある。サービスネットワーク２１０は、ここでは、サービス・プロバイダ・ネットワーク、コアネットワーク、レイヤ３ネットワーク、レイヤ２ネットワークもしくはレイヤ２．５ネットワーク、または、複数のサイト内のコンポーネントを接続もしくは相互接続する他のネットワークのような相互接続ネットワークを意味することがある。個々のレイヤ２ネットワーク２２０は、対応するエッジノード２１２に接続された複数のＬ２ＧＷ２２２と、Ｌ２ＧＷ２２２に接続されることがある複数の中間スイッチ２２４とを備えることがある。仮想レイヤ２ネットワーク２００のコンポーネントは、図２に示されるように配置されることがある。中間スイッチ２２４は、複数のホストおよび／またはＶＭ（図示せず）に接続されることもある。

サービスネットワーク２１０は、サービス・プロバイダ・ネットワークのようなレイヤ２ネットワーク２２０を相互接続するために確立されたどのようなネットワークでもよい。たとえば、サービスネットワーク２１０は、仮想プライベート・ネットワーク（ＶＰＮ）のようなレイヤ２、レイヤ２．５またはレイヤ３ネットワークでもよい。サービスネットワーク２１０は、Ｌ２ＧＷ２２２の背後にあるすべてのアドレス、たとえば、ＭＡＣアドレスを知らないことがある。Ｌ２ＧＷ２２２は、個々のＤＣロケーション内のボーダーノードでもよく、ＤＣロケーションにおいて内部で通信するためにレイヤ２インターフェースを有することがある。Ｌ２ＧＷ２２２および中間スイッチ２２４は、ホストの対応するＭＡＣアドレスを使用して同じレイヤ２ネットワーク２２０内部の同じロケーションにおけるホストおよび／またはＶＭと通信することがある。しかし、Ｌ２ＧＷ２２２および中間スイッチ２２４は、他のレイヤ２ネットワーク２２０内のホスト／ＶＭのＭＡＣアドレスを知る必要がないことがある。その代わり、１つのレイヤ２ネットワーク２２０内のホストは、他のレイヤ２ネットワーク内のターゲットホストと通信するために宛先アドレスとして、（別のロケーションまたはサイトにおける）別のレイヤ２ネットワーク２２０のＬ２ＧＷ２２２のアドレスを使用できる。フレーム（たとえば、イーサネット（登録商標）フレーム）がターゲットサイト、たとえば、他のレイヤ２ネットワークのＬ２ＧＷ２２２に到達したとき、ターゲットホストの宛先アドレスは、後述されるように、フレームのペイロード中に搬送されるＩＰアドレスに基づいて、たとえば、ネットワークアドレス変換（ＮＡＴ）テーブルまたはＭＡＣアドレス変換（ＭＡＴ）テーブルを使用してＬ２ＧＷ２２２によって変換されることがある。

実施形態では、個々のＬ２ＧＷ２２２は、ローカルＩＰアドレス情報テーブル（Ｌｏｃａｌ−ＩＰＡｄｄｒＴａｂｌｅ）内のＬ２ＧＷ２２２の同じレイヤ２ネットワーク２２０内部のすべてのホスト／ＶＭのアドレスを維持することがある。Ｌ２ＧＷ２２２は、後述されるように、プロキシＡＲＰ機能を実施するためにさらに構成されることがある。付加的には、Ｌ２ＧＷ２２２は、ＭＡＣ転送テーブルを維持することがあり、このＭＡＣ転送テーブルは、非ＩＰアプリケーションのためのＭＡＣアドレスを備えることがある。ＭＡＣアドレスは、同じロケーション、たとえば、同じレイヤ２ネットワーク２２０内部のホスト／ＶＭと中間スイッチ２２４とのＭＡＣアドレスを備えることがある。

Ｌ２ＧＷ２２２は、他のロケーション（たとえば、他のレイヤ２ネットワーク２２０）におけるこのＬ２ＧＷのピア（たとえば、他のＬ２ＧＷ２２２）にすべてのアクティブＶＬＡＮと、このＬ２ＧＷのロケーションにおける個々のＶＬＡＮ下でのローカルホストのすべてのＩＰアドレスを通知することがある。ドメイン内に非ＩＰアプリケーションが存在する場合、Ｌ２ＧＷ２２２は、これのピアにこれらの非ＩＰアプリケーションのＭＡＣアドレスおよびＶＬＡＮをさらに通知することがある。レイヤ２サイトまたはレイヤ２ネットワーク２２０は、オペレーションの利便性のため、Ｌ２ＧＷ２２２のポート上および中間スイッチ２２４のポート上でイネーブル状態にされた多くのＶＬＡＮを有することがある。これによって、イネーブル状態にされたＶＬＡＮのいずれかに属するＶＭまたはホストは、付加的な構成無しでムーブインされることがある。サイト（またはレイヤ２ネットワーク２２０）においてアクティブ状態であるＶＡＬＮは、このサイトの内部に存在していたこのＶＬＡＮに属するホストを有することがある。異なるロケーションを越えるＬ２ＧＷ２２２は、Ｌ２ＧＷ２２２がローカルサイトにおいて（たとえば、個々のＬ２ＧＷ２２２のためのリモートＩＰアドレス情報テーブル中で）アクティブ状態であるＶＬＡＮのためのアドレス情報だけを保ち続ける場合でも、すべての他のロケーションのホストＩＰアドレスを取得することがある。ＶＬＡＮのＶＬＡＮ識別子（ＶＩＤ）に属するホストがローカルドメインに存在しない場合、ローカルドメインが宛先にされるべきこのＶＩＤのための通信が存在しないことがあるので、このＶＩＤのためのリモートホスト情報を保ち続ける必要がない。用語ＶＬＡＮおよびＶＩＤは、（たとえば、ＩＥＥＥ８０２．１Ｑに記載されているように）ＶＬＡＮに複数のＶＩＤが割り当てられているとしても、確立されたＶＬＡＮを意味するためにここでは互換的に使用される。したがって、個々のＬ２ＧＷ２２２は、ロケーション（レイヤ２ネットワーク２２０の１つ）に属するＩＰアドレスの個々のグループを同じロケーションに属する対応するＬ２ＧＷ２２２のＭＡＣアドレスにマッピングすることがある。Ｌ２ＧＷ２２２は、他のピア内の情報を更新するために、このＬ２ＧＷのＬｏｃａｌ−ＩＰＡｄｄｒＴａｂｌｅに変化があるとき、アドレス情報の更新内容をピアにさらに送信する。これは、インクリメント方式でアドレス情報の更新と個々のＬ２ＧＷ２２２におけるマッピングを可能にすることがある。

図３は、ボーダー・コントロール・メカニズム３００の実施形態を例示する。ボーダー・コントロール・メカニズム３００は、複数のサイト、ロケーションまたはＤＣを越えてフラットまたは仮想レイヤ２ネットワークを確立するスケーラブルメカニズムでもよい。仮想レイヤ２ネットワークは、サービスネットワーク３１０と、エッジルータのような複数のエッジノード３１２を介してサービスネットワーク３１０に接続されることがある複数のレイヤ２ネットワーク３２０とを備えることがある。個々のレイヤ２ネットワーク２２０は、対応するエッジノード３１２に接続されている複数のＬ２ＧＷ３２２と、Ｌ２ＧＷに接続されることがある複数の中間スイッチ３２４とを備えることがある。中間スイッチ３２４は、たとえば、ＶＭまたはサーバ上でインスタンス化されたホスト３２６にさらに接続される（到達できる）ことがある。仮想レイヤ２ネットワークのコンポーネントは、図２に示されるように配置されることがあり、仮想レイヤ２ネットワーク２００の対応するコンポーネントに類似することがある。

ボーダー・コントロール・メカニズム３００に基づいて、個々のＬ２ＧＷ３２２は、このＬ２ＧＷの対応するローカルレイヤ２サイト、たとえば、対応するレイヤ２ネットワーク３２０においてアクティブ状態であるＶＬＡＮに属するすべてのロケーション内のホストのＩＰアドレスを維持することがある。個々のＬ２ＧＷ３２２は、他のロケーション内のピアＬ２ＧＷ３２２のＭＡＣアドレスをさらに知ることもある。しかし、Ｌ２ＧＷ３２２は、他のロケーション内のホストのＭＡＣアドレスを維持しないことがあり、このことは、ＩＰアドレスは、簡略化されることがあり（たとえば、１０．１．１．ｘは、２５５台のホストを表現することがある）、一方、ＭＡＣアドレスは、簡略化されることがないので、Ｌ２ＧＷ３２２の間で交換された（そして記憶された）データのサイズを実質的に縮小することがある。Ｌ２ＧＷ３２２で維持されたＩＰアドレスは、同じロケーションの対応するＬ２ＧＷ３２２のＭＡＣアドレスにマッピングされることがある。具体的には、個々のロケーションまたはレイヤ２ネットワーク３００に属するホストＩＰアドレスの個々の集合は、このロケーション内のＬ２ＧＷ３２２のＭＡＣアドレスにマッピングされることがある。しかし、Ｌ２ＧＷ３２２は、異なるロケーションを越えて、非ＩＰアプリケーションを動かすノードのための複数のＭＡＣアドレスを交換することがある。

仮想レイヤ２ネットワークの異なるロケーションを越えるアドレス解決をサポートするために、ＡＲＰ（またはＮＤ）要求が第１のホスト３２６（ホストＡ）から送信され、第１のロケーションまたはレイヤ２ネットワーク３２０内の対応するローカルＬ２ＧＷ３２２によってインターセプトされることがある。ホストＡは、第２のロケーションまたはレイヤ２ネットワーク３２０内の第２のホスト３２６（ホストＢ）のＭＡＣアドレスを取得するためにＡＲＰ要求を送信することがある。ローカルＬ２ＧＷ３２２がホストＡと同じＶＬＡＮに属するホストＢのエントリ、たとえば、ホストＢのＩＰアドレスを有する場合、ローカルＬ２ＧＷ３２２は、これの一意のＭＡＣアドレスをホストＡに送信することによりＡＲＰ／ＮＤ要求に応答することがある。代替的には、ローカルＬ２ＧＷ３２２は、ＡＲＰ／ＮＤ応答中で（ホストＢが存在する場所にある）対応するＬ２ＧＷのＭＡＣアドレスをホストＡに送信することがある。ローカルＬ２ＧＷ３２２がＶＬＡＮのホストＢのエントリを維持しないか、または、記憶しない場合、ローカルＬ２ＧＷ３２２は、ホストＢが存在しないと仮定することがある。たとえば、Ｌ２ＧＷ３２２は、定期的または周期的に、これらのＬ２ＧＷのピアのローカルホストＩＰアドレスおよび対応するＶＬＡＮ（群）を用いてこれらのピアを更新することがある。一部のＬ２ＧＷ３２２は、一部のＶＬＡＮに対する他のロケーション内に新たに構成されたホストのＩＰアドレスの更新内容を受信していないことがある。このような場合、応答は返信されず、要求元エンティティ（ホストＡ）は、ターゲットホストのための複数のＡＲＰ／ＮＤ要求を送信することがある。

実施形態では、Ｌ２ＧＷ２２２は、個々のＶＬＡＮ下のローカルホストの複数のアグリゲーションされたＩＰアドレスを他のレイヤ２サイト内の他のＬ２ＧＷ２２２に送出することがある。アグリゲーションされたアドレス中のエントリの個数は、Ｌ２ＧＷ２２２のＬｏｃａｌ−ＩＰＡｄｄｒＴａｂｌｅ中の対応するエントリの個数より実質的に少ないことがある。一部の実施形態では、Ｌ２ＧＷ２２２は、リモートサイト内の単一ＶＬＡＮ（または、いずれかのＶＬＡＮ）下の（アグリゲーションされた形式の）ＩＰアドレスを請求するために、要求を他のレイヤ２サイト内のすべての他のＬ２ＧＷ２２２に送出することがある。このことは、アクティブ状態ではなかったＶＬＡＮに属するホストがＬ２ＧＷ２２０のローカルサイトに追加されるときに役立つことがある。

表１は、ボーダー・コントロール・メカニズム３００による対応するＬ２ＧＷのＭＡＣアドレスおよびＶＬＡＮへのホストアドレスのマッピングの実施例を例示する。複数のＬ２ＧＷＭＡＣアドレス（たとえば、Ｌ２ＧＷ１ＭＡＣおよびＬ２ＧＷ２ＭＡＣ）が複数の対応するホストアドレスにマッピングされることがある。個々のＬ２ＧＷＭＡＣアドレスは、同じロケーションまたはＤＣと関連付けられることがある複数のＶＬＡＮ（たとえば、ＶＬＡＮ＃、ＶＬＡＮ−ｘ、・・・）内の複数のホストＩＰ（またはＭＡＣ）アドレスにマッピングされることがある。個々のＶＬＡＮは、ホストの複数の仮想プライベートグループ（ＶＰＧ）（または閉じたユーザグループ）をさらに備えることがある。ＶＰＧは、レイヤ２ドメイン（またはＬ２ドメイン）に属し、かつ、レイヤ２を介して相互に通信することがあるホストおよび／またはＶＭのクラスタでもよい。レイヤ２ドメインは、ここでは、レイヤ２ネットワーク内のサブロケーションまたはサブサイトを意味するために使用されることがある。レイヤ２ネットワークが複数のサイトまたはロケーションを越えて広がるとき、個々のサイトは、ここでは、レイヤ２ドメインと呼ばれることがある。レイヤ２ドメイン、レイヤ２サイト、およびレイヤ２区域という用語は、ここでは、互換的に使用されることがある。ドメイン、サイト、および区域という用語も同様に、ここでは、互換的に使用されることがある。ＶＰＧ内のホストは、これらの間に確立されたマルチキャストグループをさらに有することがある。ＶＰＧ内部のホスト／ＶＭは、複数の物理ロケーションを越えて広がることがある。多くのケースの下では、１つのＶＬＡＮは、１顧客に専用になることがあり、たとえば、１つのＶＬＡＮ当たりに１つのＶＰＧしか存在しないことがある。したがって、このようなケースの下では、テーブル中にＶＰＧ列（または属性）を有する必要がない。

たとえば、ＶＬＡＮ＃は、Ｇ−ｘ１、Ｇ−ｘ２、・・・を含む複数のＶＰＧ内に複数のホストを備えることがある。そして、個々のＶＰＧは、複数のホストを備えることがある。ＩＰアプリケーションに対し、個々のＶＬＡＮ内のホストＩＰアドレスは、ＶＬＡＮ＃およびＶＬＡＮ−ｘ・・・）の場合のように、同じロケーション内の対応するＬ２ＧＷＭＡＣアドレスにマッピングされることがある。ＩＰアドレスは、テーブル中のエントリの量を削減するために簡略化されることがある。非ＩＰアプリケーションに対し、個々のＶＬＡＮ内のホストＭＡＣアドレスは、ＶＬＡＮ−ｘ１の場合のように、このＶＬＡＮに対する同じロケーション内の対応するＬ２ＧＷＭＡＣアドレスにマッピングされることがある。一部のケースでは、個々のＶＬＡＮに対し、１つのＶＰＧだけが存在することがあり、したがって、テーブル１中のＶＰＧ列は、必要とされないことがある。

図４は、複数のロケーションまたはＤＣを越える仮想レイヤ２ネットワークにおいて使用されることがあるデータフレーム転送スキーム４００の実施形態を例示する。仮想レイヤ２ネットワークは、サービスネットワーク４１０と、エッジルータのような複数のエッジノード４１２を介してサービスネットワーク４１０に接続されることがある複数のレイヤ２ネットワーク４２０とを備えることがある。個々のレイヤ２ネットワーク４２０は、対応するエッジルータ４１２に接続されている複数のＬ２ＧＷ４２２と、Ｌ２ＧＷ４２２に接続されることがある複数の中間スイッチ４２４とを備えることがある。中間スイッチ４２４は、ホスト４２６、たとえば、ＶＭにさらに接続されることがある。仮想レイヤ２ネットワークのコンポーネントは、図４に示されるように配置されることがあり、仮想レイヤ２ネットワーク２００の対応するコンポーネントに類似することがある。

データフレーム転送スキーム４００に基づいて、Ｌ２ＧＷ４２２は、内部フレームがＭＡＣアドレス変換を必要とすることを指示するためにイーサ・タイプ・フィールドを使用して、参照によりここに組み込まれるマック・イン・マック（ＭＡＣ−ｉｎ−ＭＡＣ）のための米国電気電子学会（ＩＥＥＥ）８０２．１ａｈ規格をサポートすることがある。たとえば、第１のＬ２ＧＷ４２２（ＧＷ１）は、第１のロケーション（Ｌｏｃ１）内の第１のホスト４２６（ホストＡ）からフレーム４４０、たとえば、イーサネット（登録商標）フレームを受信することがある。フレーム４４０は、第２のロケーション（Ｌｏｃ２）内の第２のホスト４２６（ホストＢ）を対象とすることがある。フレーム４４０は、ＧＷ１のＭＡＣ宛先アドレス（ＭＡＣ−ＤＡ）４２２（Ｌ２ＧＷ−Ｌｏｃ１）と、ホストＡのＭＡＣ送信元アドレス（ＭＡＣ−ＳＡ）４４４（Ａ’ｓＭＡＣ）と、ホストＢのＩＰ宛先アドレス（ＩＰ−ＤＡ）４４６（Ｂ）と、ホストＡのＩＰ送信元アドレス（ＩＰ−ＳＡ）４４８（Ａ）と、ペイロードとを備えることがある。ＧＷ１は、その後、内部フレーム４６０を取得するためにＭＡＣ外ヘッダをフレーム４４０に付加することがある。ＭＡＣ外ヘッダは、ＧＷ２のＭＡＣ−ＤＡ４６２（Ｌ２ＧＷ−Ｌｏｃ２）と、ＧＷ１のＭＡＣ−ＳＡ４６４（Ｌ２ＧＷ−Ｌｏｃ１）と、内部フレーム４６０がＭＡＣアドレス変換を必要とすることを指示するイーサ・タイプ４６６とを備える。内部フレーム４６０は、ＧＷ１のＭＡＣ−ＤＡ４６８（Ｌ２ＧＷ−Ｌｏｃ１）と、ホストＡのＭＡＣ−ＳＡ４７０（Ａ’ｓＭＡＣ）とをさらに備えることがある。内部フレーム４６０は、その後、サービスネットワーク４１０内でＧＷ２へ転送されることがあり、ＧＷ２は、フレームのＭＡＣアドレスを変換するためにＭＡＣ外ヘッダを処理することがある。したがって、ＧＷ２は、ホストＢのＭＡＣ−ＤＡ４８２（Ｂ’ｓＭＡＣ）と、ホストＡのＭＡＣ−ＳＡ４８４（Ａ’ｓＭＡＣ）と、ホストＢのＩＰ−ＤＡ４８６（Ｂ）と、ホストＡのＩＰ−ＳＡ４８８（Ａ）と、ペイロードとを備えることがある第２のフレーム４８０を取得することがある。第２のフレーム４８０は、その後、Ｌｏｃ２内のホストＢに転送されることがある。

データフレーム転送スキーム４００は、外部ＩＰヘッダのカプセル化を必要とするＣｉｓｃｏのＯＴＶスキームより簡単に実施できることがある。付加的には、多くのイーサネット（登録商標）チップは、ＩＥＥＥ８０２．１ａｈをサポートする。８０２．１ａｈにおいて指定されるようなサービスインスタンス・タグ（Ｉ−ＴＡＧ）は、異なるＶＰＧを区別するために使用されることがある。これによって、Ｉ−ＴＡＧフィールドは、たとえば、サービスネットワーク４１０において、プロバイダドメインの複数のＶＰＧを分離するためにデータフレーム転送スキーム４００においても使用されることがある。ＧＷ２は、ＭＡＴを使用して上述のＭＡＣ変換スキームを実行することがあり、これは、パブリックＩＰをプライベートＩＰに変換するためＮＡＴを使用することに類似することがある。伝送制御プロトコル（ＴＣＰ）セッションに基づいているＮＡＴスキームとは異なって、ＭＡＴスキームは、ＭＡＣアドレスを見つけるために内部ＩＰアドレスを使用することに基づくことがある。

図５は、非ＩＰアプリケーションのための別のデータフレーム転送スキーム５００の実施形態を例示する。データフレーム転送スキーム５００は、仮想レイヤ２ネットワーク内の異なるロケーションにおけるホスト間でフレームを転送するためにＩＰアドレスの代わりに、非ＩＰホストまたは非ＩＰアプリケーションを実施するホストのＭＡＣアドレスを使用することがある。仮想レイヤ２ネットワークは、サービスネットワーク５１０と、エッジルータのような複数のエッジノード５１２を介してサービスネットワーク５１０に接続されることがある複数のレイヤ２ネットワーク５２０とを備えることがある。個々のレイヤ２ネットワーク５２０は、対応するエッジノード５１２に接続されている複数のＬ２ＧＷ５２２と、Ｌ２ＧＷ５２２に接続されることがある複数の中間スイッチ５２４とを備えることがある。中間スイッチ５２４は、ホスト５２６、たとえば、ＶＭにさらに接続されることがある。仮想レイヤ２ネットワークのコンポーネントは、図５に示されるように配置されることがあり、仮想レイヤ２ネットワーク２００の対応するコンポーネントに類似することがある。

データフレーム転送スキーム５００に基づいて、Ｌ２ＧＷ５２２は、マック・イン・マック（ＭＡＣ−ｉｎ−ＭＡＣ）のためのＩＥＥＥ８０２．１ａｈをサポートすることがある。たとえば、第１のＬ２ＧＷ５２０（ＧＷ１）は、第１のロケーション（Ｌｏｃ１）内の第１のホスト５２６（ホストＡ）からフレーム５４０、たとえば、イーサネット（登録商標）フレームを受信することがある。フレーム５４０は、第２のロケーション（Ｌｏｃ２）内の第２のホスト５２６（ホストＢ）を対象とすること、または、向けられることがある。フレーム５４０は、ＧＷ１のＭＡＣ−ＤＡ５４２（Ｌ２ＧＷ−Ｌｏｃ１）と、ホストＡのＭＡＣ−ＳＡ５４４（Ａ’ｓＭＡＣ）と、ペイロードとを備えることがある。ＧＷ１は、その後、内部フレーム５６０を取得するためにＭＡＣ外ヘッダをフレーム５４０に付加することがある。ＭＡＣ外ヘッダは、ＧＷ２のＭＡＣ−ＤＡ５６２（Ｌ２ＧＷ−Ｌｏｃ２）と、ＧＷ１のＭＡＣ−ＳＡ５６４（Ｌ２ＧＷ−Ｌｏｃ１）と、内部フレーム５６０がＭＡＣ−ｉｎ−ＭＡＣフレームであることを指示するイーサ・タイプ５６６とを備えることがある。内部フィールド５６０は、ホストＢのＭＡＣ−ＤＡ５６８（Ｂ’ｓＭＡＣ）と、ホストＡのＭＡＣ−ＳＡ５７０（Ａ’ｓＭＡＣ）とをさらに備えることがある。内部フレーム５６０は、その後、サービスネットワーク５１０内でＧＷ２へ転送されることがあり、ＧＷ２は、第２のフレーム５８０を取得するために内部フレーム５６０を処理することがある。第２のフレーム５８０は、ホストＢのＭＡＣ−ＤＡ５８２（Ｂ’ｓＭＡＣ）と、ホストＡのＭＡＣ−ＳＡ５８４（Ａ’ｓＭＡＣ）と、ペイロードとを備えることがある。第２のフレーム５８０は、その後、Ｌｏｃ２内のホストＢに転送されることがある。

データフレーム転送スキーム５００は、外部ＩＰヘッダのカプセル化を必要とするＣｉｓｃｏのＯＴＶスキームより簡単に実施できることがある。付加的には、多くのイーサネット（登録商標）チップは、ＩＥＥＥ８０２．１ａｈをサポートする。８０２．１ａｈにおいて記載されるように、Ｉ−ＴＡＧは、異なるＶＰＧを区別するために使用されることがある。これによって、Ｉ−ＴＡＧフィールドは、たとえば、サービスネットワーク５１０において、プロバイダドメインの複数のＶＰＧを分離するためにデータフレーム転送スキーム５００においても使用されることがある。ＧＷ２は、ＭＡＣ変換スキームを実行することなく、上述のとおり、第２のフレーム５８０を処理することがある。

図６は、複数のロケーションを越える仮想レイヤ２ネットワークにおいて使用されることがある別のデータフレーム転送スキーム６００の実施形態を例示する。データフレーム転送スキーム６００は、仮想レイヤ２ネットワーク内の前ロケーションから新ロケーションへ移動し、かつ、第２のホストのための同一の知られたＭＡＣアドレスを維持するホストからのフレームを転送するために使用されることがある。仮想レイヤ２ネットワークは、サービスネットワーク６１０と、エッジルータのような複数のエッジノード６１２を介してサービスネットワーク６１０に接続されることがある複数のレイヤ２ネットワーク６２０とを備えることがある。個々のレイヤ２ネットワーク６２０は、対応するエッジノード６１２に接続された複数のＬ２ＧＷ６２２と、Ｌ２ＧＷ６２２に接続されることがある複数の中間スイッチ６２４とを備えることがある。中間スイッチ６２４は、ホスト６２６、たとえば、ＶＭにさらに接続されることがある。仮想レイヤ２ネットワークのコンポーネントは、図６に示されるように配置されることがあり、仮想レイヤ２ネットワーク２００の対応するコンポーネントに類似することがある。

第１のホスト６２６（ホストＡ）が前ロケーション（Ｌｏｃ１）から新ロケーション（Ｌｏｃ３）に移動するとき、ホストＡは、第２のホスト６２６（ホストＢ）のための同一の知られたＭＡＣアドレスを依然として使用することがある。データ転送スキーム６００によれば、Ｌｏｃ３のＬ２ＧＷ６２２（ＧＷ３）は、内部フレームがＭＡＣアドレス変換を必要とすることを指示するためにイーサ・タイプ・フィールドを使用して８０２．１ａｈＭＡＣ−ｉｎ−ＭＡＣをサポートすることがある。ＧＷ３は、ＭＡＣ外ヘッダ中のＧＷ２のＭＡＣアドレスを使用してデータをＬｏｃ２の第２のＬ２ＧＷ６２２（ＧＷ２）に送信するために、データフレーム転送スキーム４００に類似するデータフレーム転送スキームを実施することがある。このようにして、ＧＷ２は、（データフレーム転送スキーム４００に対して）上述のとおり、ＭＡＣ外ヘッダをカプセル化解除し、ＭＡＣアドレス変換を実行することがある。

たとえば、ＧＷ３は、Ｌｏｃ３へ移動した後、ホストＡからフレーム６４０、たとえば、イーサネット（登録商標）フレームを受信することがある。フレーム６４０は、Ｌｏｃ２内のホストＢを対象とすることがある。フレーム６４０は、Ｌｏｃ１の前Ｌ２ＧＷ６２２（ＧＷ１）のＭＡＣ−ＤＡ６４２（Ｌ２ＧＷ−Ｌｏｃ１）と、ホストＡのＭＡＣ−ＳＡ６４４（Ａ’ｓＭＡＣ）と、ホストＢのＩＰ−ＤＡ６４６（Ｂ）と、ホストＡのＩＰ−ＳＡ６４８（Ａ）と、ペイロードとを備えることがある。ＧＷ３は、その後、内部フレーム６６０を取得するためにＭＡＣ外ヘッダをフレーム６４０に付加することがある。ＭＡＣ外ヘッダは、ＧＷ２のＭＡＣ−ＤＡ６６２（Ｌ２ＧＷ−Ｌｏｃ２）と、ＧＷ１のＭＡＣ−ＳＡ６６４（Ｌ２ＧＷ−Ｌｏｃ１）と、内部フレーム６６０がＭＡＣアドレス変換を必要とすることを指示するイーサ・タイプ６６６とを備えることがある。内部フレーム６６０は、ホストＢのＭＡＣ−ＤＡ６６８（Ｂ’ｓＭＡＣ）とホストＡのＭＡＣ−ＳＡ６７０（Ａ’ｓＭＡＣ）とをさらに備えることがある。内部フレーム６６０は、その後、サービスネットワーク６１０内でＧＷ２に転送されることがあり、このＧＷ２は、フレームのＭＡＣアドレスを変換するためにＭＡＣ外ヘッダを処理することがある。したがって、ＧＷ２は、ホストＢのＭＡＣ−ＤＡ６８２（Ｂ’ｓＭＡＣ）と、ホストＡのＭＡＣ−ＳＡ６８４（Ａ’ｓＭＡＣ）と、ペイロードとを備えることがある第２のフレーム６８０を取得することがある。第２のフレーム６８０は、その後、Ｌｏｃ２内のホストＢに転送されることがある。

さらに、ホストＢは、Ｌｏｃ２から別のロケーション、たとえば、Ｌｏｃ４（図示せず）に移動することがある。ホストＢがＬｏｃ２からＬｏｃ４に移動したことをＧＷ２が知っている場合、ＧＷ２は、上述のとおり、ＭＡＣ外ヘッダ内のＭＡＣ−ＤＡとしてＬｏｃ４内の別のＬ２ＧＷ６２２（ＧＷ４）のＭＡＣアドレスを使用することがある。ホストＢがＬｏｃ２からＬｏｃ４に移動したことをＧＷ２が知らない場合、フレームは、ＭＡＣ外ヘッダ無しでＧＷ２によって転送されることがある。したがって、フレームは、たとえば、サービスネットワーク６１０内で失われることがある。フレームは、ホストＢがこのホストの新ロケーションをＧＷ２またはＬｏｃ２に知らせた後、フレームがＧＷ２によって再送信されるまで、一時的に失われることがある。

図７は、上記仮想レイヤ２ネットワークと類似するボーダー・コントロール・メカニズムを実施することがある相互接続型レイヤ２サイト（または区域）７００の実施形態を例示する。相互接続型レイヤ２サイト７００は、複数のボーダーまたはエッジノード７１２によって接続された複数のＬ２ＧＷ７２２を備えることがある。エッジノード、たとえば、エッジルータは、サービスネットワーク、たとえば、レイヤ３ネットワークに属することがある。相互接続型レイヤ２サイト７００は、Ｌ２ＧＷ７２２に接続された複数の中間スイッチ７２４と、中間スイッチ７２４に接続された複数のＶＭ７２６とをさらに備えることがある。Ｌ２ＧＷ７２２と、中間スイッチ７２４と、ＶＭ７２６とは、複数のレイヤ２（Ｌ２）アドレスドメインに対応する複数の部分集合をサポートすることがある。相互接続型レイヤ２サイト７００のコンポーネントは、図７に示されるように配置されることがあり、仮想レイヤ２ネットワーク２００の対応するコンポーネントに類似することがある。

個々のＬ２アドレスドメインは、ボーダー・コントロール・メカニズム３００のようなボーダー・コントロール・メカニズムを使用することがあり、個々のレイヤ２ドメイン内部の中間スイッチ７２４およびＶＭ７２６は、ローカルＭＡＣアドレスを知ることがあるが、他のＬ２アドレスドメイン内のホスト、サーバおよび／またはＶＭ７２６のためのＭＡＣアドレスおよびＶＬＡＮを知らないことがある。しかし、ホスト、サーバ、および／またはＶＭ７２６は、異なるレイヤ２ドメインを知ることなく、単一のフラット・レイヤ２ネットワーク内のように、相互に通信することがある。レイヤ２ドメインは、ボーダーまたはエッジノード７１２を介して互いに相互接続されることがあり、このボーダーまたはエッジノードは、コアネットワークまたはサービス・プロバイダ・ネットワーク（図示せず）に亘って相互接続されることがある。Ｌ２アドレスドメインは、１つのＤＣサイトまたは複数の地理的サイトに位置することがある。複数のサイト（ロケーション）を越える相互接続型レイヤ２サイト７００のアーキテクチャは、ここでは、サービスネットワーク（レイヤ３、２．５、２または他のネットワーク）、サービスネットワークによって相互接続されたサイトに亘るスードレイヤ２ネットワーク、仮想レイヤ２、またはスードレイヤ２ネットワークによって相互接続された複数のサイトを亘るレイヤ２拡張と呼ばれることもある。

図８は、サービスネットワークによって相互接続された複数のサイトに亘るレイヤ２拡張８００の一実施形態を例示する。レイヤ２拡張８００は、サービス・プロバイダまたはコアネットワーク（図示せず）に属することがある複数のボーダーまたはエッジノード８１２に接続された複数のＬ２ＧＷ８２２を備えることがある。レイヤ２拡張８００は、Ｌ２ＧＷ８２２に接続された複数の中間スイッチ８２４と、中間スイッチ８２４に接続された複数のホスト／サーバ／ＶＭ８２６とをさらに備えることがある。中間スイッチ８２４およびホスト／サーバ／ＶＭ８２６は、複数のＬ２アドレスドメインに分離または配置されることがある。たとえば、Ｌ２サイトのうちの１つが図８において点線円形によって指示される。Ｌ２ＧＷ８２２、中間スイッチ８２４、および／またはホスト／サーバ／ＶＭ８２６は、１つまたは複数のＤＣロケーションでレイヤ２ネットワークに対応することがある。レイヤ２拡張８００のコンポーネントは、図８に示されるように配置されることがあり、仮想レイヤ２ネットワーク２００の対応するコンポーネントに類似することがある。

図９は、複数のロケーションに亘るスードレイヤ２ネットワーク９００の実施形態の概略図である。スードレイヤ２ネットワーク９００は、１つのフラット・レイヤ２ネットワークを確立するために、複数のロケーション、たとえば、地理的ロケーションまたはＤＣを越えてレイヤ２を接続するメカニズムでもよい。スードレイヤ２ネットワーク９００は、サービス・プロバイダまたはコアネットワーク９１０と、エッジルータのような複数のエッジノード９１２を介してサービス・プロバイダまたはコアネットワーク９１０に接続されることがある複数のレイヤ２ネットワークドメイン９２０とを備えることがある。個々のレイヤ２サイト９２０は、異なるＤＣサイト（またはフロア、またはゾーン）またはロケーションに位置することがあり、対応するエッジノード９１２に接続された複数のＬ２ＧＷ９２２と、対応するＬ２ＧＷ９２２に接続された複数の中間スイッチ９２４とを備えることがある。中間スイッチ９２４は、複数のホスト／サーバ／ＶＭ（図示せず）にさらに接続されることがある。スードレイヤ２ネットワーク９００のコンポーネントは、図９に示されるように配置されることがあり、仮想レイヤ２ネットワーク２００の対応するコンポーネントに類似することがある。

図１０は、ドメインアドレス制約メカニズム１０００の実施形態を例示する。ドメインアドレス制約メカニズム１０００は、異なるレイヤ２サイトの間のアドレス解決を取り扱うために複数のサイトに亘るスードレイヤ２ネットワークで使用されることがある。複数のサイトに亘るスードレイヤ２ネットワークは、サービスネットワーク１０１０と、複数のエッジノード１０１２を介してサービスネットワーク１０１０に接続されることがある複数のレイヤ２ネットワークサイト１０２０とを備えることがある。レイヤ２サイト１０２０は、同じまたは異なるＤＣサイトに位置することがあり、対応するエッジノード１０１２に接続された複数のＬ２ＧＷ１０２２と、対応するＬ２ＧＷ１０２２に接続された複数の中間スイッチ１０２４とを備えることがある。中間スイッチ１０２４は、複数のホスト／サーバ／ＶＭ１０２６にさらに接続されることがある。スードレイヤ２ネットワークのコンポーネントは、図１０に示されるように配置されることがあり、仮想レイヤ２ネットワーク２００の対応するコンポーネントに類似することがある。

具体的には、１つのレイヤ２サイト１０２０におけるＬ２ＧＷ１０２２のＭＡＣアドレスは、このローカルサイトの外側の全部または複数のホストのためのプロキシとして使用されることがある。第１の選択肢（選択肢１）では、レイヤ２サイト１０２０内のローカルＬ２ＧＷ１０２２のためのＭＡＣアドレスは、他のレイヤ２ネットワークサイト１０２０内のホストのためのプロキシとして使用されることがある。このシナリオでは、ローカルホストのアドレスだけが同じローカルレイヤ２サイト１０２０内の中間スイッチ１０２４とホスト／サーバ／ＶＭ１０２６とによって知られることがある。他のレイヤ２サイト１０２０内の外部Ｌ２ＧＷ１０２２のＭＡＣアドレスは、ローカルレイヤ２サイト１０２０に晒されないことがある。

代替的には、第２の選択肢（選択肢２）では、リモートレイヤ２サイト１０２０内のＬ２ＧＷ１０２２のＭＡＣアドレスは、対応するサイト内に存在するすべてのホストのためのプロキシとして使用されることがある。この選択肢下で、他のレイヤ２サイト１０２０内の外部Ｌ２ＧＷ１０２２のＭＡＣアドレスは、個々のレイヤ２サイト１０２０において知られることがある。この選択肢では、ターゲットホストが存在するレイヤ２サイト１０２０に対応するリモートＬ２ＧＷ１０２２のＭＡＣアドレスは、たとえば、ホストがリモートレイヤ２サイト１０２０内のホストと通信することを意図し、外部ホストのアドレスを要求するとき、ローカルホストのＡＲＰ／ＮＤ要求に応答して返送されることがある。選択肢２は、一部の状況において、選択肢１へのいくつかの有意性を有することがある。

ドメインアドレス制約メカニズム１０００によれば、個々のＬ２ＧＷ１０２２は、たとえば、逆ＡＲＰスキームまたは他の方法を使用して、Ｌ２ＧＷ１０２２の同じローカルレイヤ２サイト１０２０内のすべてのホストアドレスを知ることがある。個々のＬ２ＧＷ１０２２は、ホストＩＰアドレスおよび対応するＶＬＡＮ（またはＶＩＤ）を他のレイヤ２サイト１０２０内の他のＬ２ＧＷ１０２０にさらに通知することがある。

異なるサイトを越える１つのレイヤ２の内部でアドレスを分解するために、ＡＲＰ／ＮＤ要求が第１のホスト１０２６（ホストＡ）から第１のサイト（サイト１）内の対応するローカルＬ２ＧＷ１０２２に送信されることがある。ホストＡは、第２のサイト（サイト２）内の第２のホスト１０２６（ホストＢ）のＭＡＣアドレスを取得するためにＡＲＰ／ＮＤ要求を送信することがある。ローカルＬ２ＧＷ１０２２がＶＬＡＮに対するホストＢのためのエントリ、たとえば、同じＶＬＡＮ下でのホストＢのＩＰアドレスを有する場合、ローカルＬ２ＧＷ１０２２は、これの一意のＭＡＣアドレス（選択肢１）またはサイト２内のホストＢと関連付けられた第２のＬ２ＧＷ１０２２のＭＡＣアドレス（選択肢２）をホストＡに送信することによりＡＲＰ要求に応答することがある。１つのサイト、たとえば、サイト１から送信されたＡＲＰ／ＮＤ要求は、ローカルＬ２ＧＷ１０２２によってインターセプトされることがあり、（ローカルＬ２ＧＷ１０２２によって）他のサイトに転送されないことがある。ローカルＬ２ＧＷ１０２２が同じＶＬＡＮ下でホストＢのためのエントリを備えない場合、ローカルＬ２ＧＷ１０２２は、ホストＢが存在しないと仮定することがあり、応答をホストＡに送信しないことがある。個々のサイトのＬ２ＧＷ１０２２は、これらのローカルホストのＩＰアドレスおよびこれらの対応するＶＬＡＮの更新内容を定期的または周期的にこれらのピアＬ２ＧＷ１０２２に送信することがある。一部のＬ２ＧＷ１０２２は、他のロケーション内に新たに構成されたホストのＩＰアドレスを受信していないことがあると考えられる。典型的に、ホストＡは、応答が受信されない場合、ＡＲＰ／ＮＤ要求を繰り返し送信することがある。

図１１は、複数のサイトに亘る１つのスードレイヤ２ネットワークの内部でメッセージまたはフレームを転送するために使用されることがあるデータフレーム転送スキーム１１００の実施形態を例示する。複数のサイトに亘るスードレイヤ２ネットワークは、サービス・プロバイダまたはコアネットワーク１１１０と、複数のエッジノード１１１２を介してサービス・プロバイダまたはコアネットワーク１１１０によって接続されることがある複数のレイヤ２ネットワークドメイン１１２０とを備えることがある。レイヤ２ネットワークドメイン１１２０は、１つ以上のＤＣサイトまたはロケーションに位置することがあり、対応するエッジノード１１１２に接続された複数のＬ２ＧＷ１１２２と、対応するＬ２ＧＷ１１２２に接続された複数の中間スイッチ１１２４とを備えることがある。中間スイッチ１１２４は、複数のホスト／サーバ／ＶＭ１１２６にさらに接続されることがある。スードレイヤ２ネットワークのコンポーネントは、図１１に示されるように配置されることがあり、仮想レイヤ２ネットワーク２００の対応するコンポーネントに類似することがある。

データフレーム転送スキーム１１００に基づいて、第１のＬ２ＧＷ１０２２（ＧＷ１）は、第１のアドレスドメイン１１２０（ドメイン１）内の第１のホスト１１２６（ホストＡ）から第１のフレーム１１４０、たとえば、イーサネット（登録商標）フレームを受信することがある。第１のフレーム１１４０は、第２のアドレスドメイン１１２０（ドメイン２）内の第２のホスト１１２６（ホストＢ）を対象とすることがある。第１のフレーム１１４０は、Ｌ２ＧＷ１１２２のＭＡＣ−ＤＡ１１４２（ＧＷ）を備えることがある。ホストＡは、ホストＢのためのＡＲＰ要求への返答としてのＧＷ１からのＡＲＰ応答中のＧＷのＭＡＣアドレスを取得することがある。ＧＷは、（選択肢１によると）ドメイン１内のＧＷ１、または、（選択肢２によると）ドメイン２内の第２のＬ２ＧＷ１１２２（ＧＷ２）に対応することがある。第１のフレーム１１４０は、ホストＡのＭＡＣ−ＳＡ１１４４（Ａ’ｓＭＡＣ）と、ホストＢのＩＰ−ＤＡ１１４６（Ｂ）と、ホストＡのＩＰ−ＳＡ１１４８（Ａ）と、ペイロードとを備えることがある。

選択肢１に基づいて、ＧＷ１は、第１のフレーム１１４０を受信し、（たとえば、ホストＢのＩＰ−ＤＡ１１４６によって指示されるように）ホストＢのＶＩＤ／宛先ＩＰアドレスを参照し、第１のフレーム１１４０内のＧＷのＭＡＣ−ＤＡ１１４２を内部フレーム１１６０内のＧＷ２のＭＡＣ−ＤＡ１１６２で置換することがある。ＧＷ１は、第１のフレーム１１４０内のホストＡのＭＡＣ−ＳＡ１１４４（Ａ’ｓＭＡＣ）を内部フレーム１１６０内のＧＷ１のＭＡＣ−ＳＡ１１６４でさらに置換することがある。内部フレーム１１６０は、ホストＢのＩＰ−ＤＡ１１６６（Ｂ）と、ホストＡのＩＰ−ＳＡ１１６８（Ａ）と、ペイロードとをさらに備えることがある。ＧＷ１は、サービス・プロバイダまたはコアネットワーク１１１０を介して内部フレーム１１６０をドメイン２に送信することがある。選択肢２に基づいて、ＧＷ１は、たとえば、アクセスリストに基づいて、ＧＷ２または他の外部Ｌ２ＧＷ１１２２を対象とするすべてのデータフレームを除去し、データフレームの送信元アドレス（ホストＡのＭＡＣ−ＳＡ１１４４またはＡ’ｓＭＡＣ）をＧＷ１の一意のＭＡＣアドレスで置換し、その後、宛先ＭＡＣに基づいてデータフレームを転送することがある

ＧＷ２は、内部フレーム１１６０を受信し、フレームのＭＡＣアドレスを変換するために内部フレーム１１６０を処理することがある。選択肢１に基づいて、ＧＷ２は、内部フレーム１１６０を受信し、（たとえば、ホストＢのＩＰ−ＤＡ１１６６によって指示されるように）ホストＢのＶＩＤ／宛先ＩＰアドレスを参照し、内部フレーム１１６０中のＧＷ２のＭＡＣ−ＤＡ１１６２を第２のフレーム１１８０中のホストＢのＭＡＣ−ＤＡ１１８２（Ｂ’ｓＭＡＣ）で置換することがある。ＧＷ２は、内部フレーム１１６０中のＧＷ１のＭＡＣ−ＳＡ１１６４を第２のフレーム１１８０中のＧＷ２のＭＡＣ−ＳＡ１１８４でさらに置換することがある。第２のフレーム１１８０は、ホストＢのＩＰ−ＤＡ１１８６（Ｂ）と、ホストＡのＩＰ−ＳＡ１１８８（Ａ）と、ペイロードとをさらに備えることがある。ＧＷ２は、その後、第２のフレーム１１８０を宛先ホストＢに送信することがある。選択肢２に基づいて、ＧＷ２は、（たとえば、ホストＢのＩＰ−ＤＡ１１６６によって指示されるように）ホストＢのＶＩＤ／宛先ＩＰアドレスを参照し、ＧＷ２のＭＡＣ−ＤＡ１１６２を第２のフレーム１１８０中のホストＢのＭＡＣ−ＤＡ１１８２（Ｂ’ｓＭＡＣ）で置換するだけでもよい。しかし、ＧＷ２は、ＭＡＣ−ＳＡ１１６４を保ち続けることがある。

上述のとおり、ＧＷ２は、第２のフレーム１１８０中のホストＢのための対応するＭＡＣ−ＤＡ１１８２（Ｂ’ｓＭＡＣ）を見つけるために、内部フレーム１１６０中のホストＢのためのＩＰ−ＤＡ１１６６を使用してＭＡＣアドレス変換を実行することがある。このＭＡＣ変換ステップは、たとえば、パブリックＩＰアドレスをプライベートＩＰアドレスに変換するためＮＡＴスキームとほぼ同じ作業量を必要とすることがある。データフレーム転送スキーム１１００におけるＭＡＣアドレス変換は、対応するＭＡＣアドレスを見つけるためにホストＩＰアドレスを使用することに基づくことがあり、一方、ＮＡＴスキームは、ＴＣＰセッションに基づいている。

図１２は、複数のアドレスドメインに亘るスードレイヤ２ネットワークの間でメッセージまたはフレームを転送するために使用されることがある別のデータフレーム転送スキーム１２００の実施形態を例示する。具体的には、スードレイヤ２ネットワークは、ＩＰ／ＭＰＬＳネットワークを介して相互接続されることがある。アドレスドメインに亘るスードレイヤ２ネットワークは、ＩＰ／ＭＰＬＳネットワーク１２１０と、複数のエッジノード１２１２を介してＩＰ／ＭＰＬＳネットワーク１２１０に接続されることがある複数のレイヤ２ネットワークドメイン１２２０とを備えることがある。ＩＰ／ＭＰＬＳネットワーク２１０は、アドレスドメイン間でインタードメイン、たとえば、レイヤ２ネットワークドメイン１２２０をサポートするためにＩＰサービスを提供することがある。レイヤ２ネットワークドメイン１２２０は、１つ以上のＤＣサイトまたはロケーションに位置することがあり、対応するエッジノード１２１２に接続された複数のＬ２ＧＷ１２２２と、対応するＬ２ＧＷ１２２２に接続された複数の中間スイッチ１２２４とを備えることがある。中間スイッチ１２２４は、複数のホスト／サーバ／ＶＭ１２２６にさらに接続されることがある。スードレイヤ２ネットワークのコンポーネントは、図１２に示されるように配置されることがあり、仮想レイヤ２ネットワーク２００の対応するコンポーネントに類似することがある。

データフレーム転送スキーム１２００に基づいて、第１のＬ２ＧＷ１０２２（ＧＷ１）は、第１のアドレスドメイン（ドメイン１）内の第１のホスト１２２６（ホストＡ）から第１のフレーム１２４０、たとえば、イーサネット（登録商標）フレームを受信することがある。第１のフレーム１２４０は、第２のアドレスドメイン（ドメイン２）内の第２のホスト１２２６（ホストＢ）を対象とすることがある。第１のフレーム１２４０は、Ｌ２ＧＷ１２２２のＭＡＣ−ＤＡ１２４２（ＧＷ）を備えることがある。ホストＡは、ホストＢのためのＡＲＰ要求への返答としてのＧＷ１からのＡＲＰ応答中のＧＷのＭＡＣアドレスを取得することがある。ＧＷは、（選択肢１によると）ドメイン１内のＧＷ１、または、（選択肢２によると）ドメイン２内の第２のＬ２ＧＷ１２２２（またはＧＷ２）に対応することがある。第１のフレーム１２４０は、ホストＡのＭＡＣ−ＳＡ１２４４（Ａ’ｓＭＡＣ）と、ホストＢのＩＰ−ＤＡ１２４６（Ｂ）と、ホストＡのＩＰ−ＳＡ１２４８（Ａ）と、ペイロードとを備えることがある。

ＧＷ１は、第１のフレーム１２４０を受信し、２つの選択肢のうちの１つに基づいてフレームを処理することがある。第１の選択肢では、ＧＷ１は、第１のフレーム１２４０を受信し、内部フレーム１２５０を取得するためにＩＰヘッダを付加することがある。ＩＰヘッダは、ＧＷ２のＩＰ−ＤＡ１２５１と、ＧＷ１のＩＰ−ＳＡ１２５２とを備えることがある。ＧＷ１は、内部フレーム１２５０中にＧＷ２のＭＡＣ−ＤＡ１２５３と、ＧＷ１のＭＡＣ−ＳＡ１２５４と、ホストＢのＩＰ−ＤＡ１２５６（Ｂ）と、ホストＡのＩＰ−ＳＡ１２５７（Ａ）とを取得するために、データフレーム転送スキーム１１００に類似する第１のフレーム１２４０をさらに処理することがある。ＧＷ１は、ＩＰ／ＭＰＬＳネットワーク１２１０を介して内部フレーム１２５０をＧＷ２に送信することがある。ＧＷ２は、内部フレーム１２５０を受信し、ホストＢのＭＡＣ−ＤＡ１２８２（Ｂ’ｓＭＡＣ）と、（選択肢１による）ＧＷ１または（選択肢２による）ＧＷ２のＭＡＣ−ＳＡ１２８４と、ホストＢのＩＰ−ＤＡ１２８６（Ｂ）と、ホストＡのＩＰ−ＳＡ１２８８（Ａ）と、ペイロードとを備える第２のフレーム１２８０を取得するためにデータフレーム転送スキーム１１００と類似する内部フレーム１２５０を処理することがある。ＧＷ２は、その後、第２のフレーム１２５０をホストＢに転送することがある。

第２の選択肢では、ＧＷ１は、第１のフレーム１２４０を受信し、第１のフレーム１２４０中のＧＷのＭＡＣ−ＤＡ１２４２を内部フレーム１２６０中のＩＰ−ＤＡ１２６２で置換することがある。ＧＷ１は、第１のフレーム１２４０中のホストＡのＭＡＣ−ＳＡ１２４４（Ａ’ｓＭＡＣ）を内部フレーム１２６０中のＧＷ１のＩＰ−ＳＡ１２６４でさらに置換することがある。内部フレーム１２６０は、ホストＢのＩＰ−ＤＡ１２６６（Ｂ）と、ホストＡのＩＰ−ＳＡ１２６８（Ａ）と、ペイロードとをさらに備えることがある。ＧＷ１は、内部フレーム１２６０をＩＰ／ＭＰＬＳネットワーク１２１０を介してＧＷ２に送信することがある。ＧＷ２は、内部フレーム１２６０を受信し、内部フレーム１２６０中のＧＷ２のＩＰ−ＤＡ１１６２を第２のフレーム１２８０中のホストＢのＭＡＣ−ＤＡ１２８２（Ｂ’ｓＭＡＣ）で置換することがある。ＧＷ２は、内部フレーム１２６０中のＧＷ１のＩＰ−ＳＡ１２６４を第２のフレーム１２８０中の（選択肢１による）ＧＷ２または（選択肢１による）ＧＷ１のＭＡＣ−ＳＡ１２８４とさらに置換することがある。第２のフレーム１２８０は、ホストＢのＩＰ−ＤＡ１２８６（Ｂ）と、ホストＡのＩＰ−ＳＡ１２８８（Ａ）と、ペイロードとをさらに備えることがある。ＧＷ２は、その後、第２のフレーム１２５０をホストＢに転送することがある。

複数のドメインを越える上記スードレイヤ２拡張またはネットワークでは、個々のＬ２ＧＷは、Ｌ２ＧＷの対応するアドレスドメインにおける個々のＶＬＡＮ内のすべてのホストのＩＰ−ＭＡＣマッピングのため構成されることがある。個々のＬ２ＧＷは、対応するアドレスドメインにおける個々のＶＬＡＮ内のすべてのホストのＩＰアドレスを定期的または周期的に他のアドレスドメイン内の他のＬ２ＧＷにさらに送信することがある。このようにして、アドレスドメイン内のＬ２ＧＷは、スードレイヤ２ネットワークのすべてのアドレスドメインに対し個々のＶＬＡＮ下でのホストのＩＰアドレスを取得することがある。個々のアドレスドメインにおけるホストのＭＡＣアドレスは、ローカルＬ２ＧＷによって他のアドレスドメインのＬ２ＧＷに送信されないことがあり、このことは、Ｌ２ＧＷ間で交換されるデータのサイズを実質的に縮小することがある。しかし、異なるアドレスドメインのＬ２ＧＷは、たとえば、非ＩＰアプリケーションの数が比較的少ない場合、これらのＬ２ＧＷの間で非ＩＰアプリケーションに対応するＭＡＣアドレスを交換することがある。ＢＧＰまたは類似する方法がアドレスドメインを越えるＬ２ＧＷ間で更新内容を含むアドレス情報を交換するために使用されることがある。

表２は、スードレイヤ２ネットワークにおける対応するＬ２ＧＷのＭＡＣアドレスへのホストアドレスのマッピングの実施例を例示する。複数のＬ２ＧＷＭＡＣアドレス（たとえば、ＧＷ−ＡＭＡＣおよびＧＷ−ＢＭＡＣ）は、複数の対応するホストアドレスにマッピングされることがある。個々のＬ２ＧＷＭＡＣアドレスは、同じアドレスドメイン内であってもよい複数のＶＬＡＮ（たとえば、ＶＩＤ−１、ＶＩＤ−２、ＶＩＤ−ｎ、・・・）内の複数のホストＩＰ（またはＭＡＣ）アドレスにマッピングされることがある。

上記スードレイヤ２拡張またはネットワークスキームは、別のアドレスドメイン内のいずれかのスイッチ／サーバ／ＶＭがアドレスドメインのＭＡＣアドレスを知ることを制約することがある。これらのスキームは、複数のロケーションにおける実質的に大きいレイヤ２ネットワークを接続するためにスケーラブルメカニズムをさらに提供することがある。複数のアドレスドメインを越えて広がる比較的大きいレイヤ２ネットワークでは、これらのスキームは、スードレイヤ２ネットワーク内のいずれかのスイッチが知ることがあるＭＡＣアドレスの数を制限することがあり、個々のスイッチは、スイッチのローカル・アドレス・ドメインのＭＡＣアドレスを知るだけでもよい。このスキームは、アドレスドメインを越えるスケーラブル・アドレス解決を使用して複数のアドレスドメインを越える到達可能性発見をさらに提供することがある。付加的には、これらのスキームは、アドレスドメイン間の転送および未知アドレスに対するブロードキャストを容易化することがあり、そして、マルチキャストグループをサポートすることがある。

図１３は、複数のアドレスドメインおよびロケーションに亘るスードレイヤ２ネットワーク間でメッセージまたはフレームを転送するために使用されることがある別のデータフレーム転送スキーム１３００の実施形態を例示する。データフレーム転送スキーム１３００は、上述の選択肢１に基づくことがあり、スードレイヤ２ネットワーク内で前ロケーションから新ロケーションへ移動し、第２のホストのための同一の知られたＭＡＣアドレスを維持するホストからフレームを転送するために使用されることがある。スードレイヤ２ネットワークは、サービス・プロバイダまたはコアネットワーク１３１０と、複数のエッジノード１１１２を介してサービス・プロバイダまたはコアネットワーク１３１０に接続されることがある複数のレイヤ２ネットワークドメイン１３２０とを備えることがある。レイヤ２ネットワークドメイン１３２０は、複数のＤＣサイトまたはロケーションに位置することがあり、対応するエッジノード１３１２に接続された複数のＬ２ＧＷ１３２２と、対応するＬ２ＧＷ１３２２に接続された複数の中間スイッチ１３２４とを備えることがある。中間スイッチ１３２４は、複数のホスト／サーバ／ＶＭ１３２６にさらに接続されることがある。スードレイヤ２ネットワークのコンポーネントは、図１３に示されるように配置されることがあり、仮想レイヤ２ネットワーク２００の対応するコンポーネントに類似することがある。

データフレーム転送スキーム１３００に基づいて、ＧＷ３は、Ｌｏｃ１からＬｏｃ３へ移動した後、第１のホスト１３２６（ホストＡ）から第１のフレーム１３４０、たとえば、イーサネット（登録商標）フレームを受信することがある。フレーム１３４０は、Ｌｏｃ２内の第２のホスト１３２６（ホストＢ）を対象とすることがある。第１のフレーム１３４０は、Ｌｏｃ１内のＧＷ１のＭＡＣ−ＤＡ１３４２と、ホストＡのＭＡＣ−ＳＡ１３４４（Ａ’ｓＭＡＣ）と、ホストＢのＩＰ−ＤＡ１３４６（Ｂ）と、ホストＡのＩＰ−ＳＡ１３４８（Ａ）と、ペイロードとを備えることがある。ＧＷ３は、第１のフレーム１３４０を処理し、たとえば、データフレーム転送スキーム１１００と同様に、第１のフレーム１３４０中のホストＡのＭＡＣ−ＳＡ１３４４（Ａ’ｓＭＡＣ）を第１の内部フレーム１３５０中のＧＷ３のＭＡＣ−ＳＡ１３５４で置換することがある。第１の内部フレーム１３５０は、ＧＷ１のＭＡＣ−ＤＡ１３５２と、ホストＢのＩＰ−ＤＡ１３５６（Ｂ）と、ホストＡのＩＰ−ＳＡ１３５８（Ａ）と、ペイロードとを備えることがある。ＧＷ３は、サービス・プロバイダまたはコアネットワーク１３１０を介して第１の内部フレーム１３５０をＬｏｃ１に送信することがある。

ＧＷ１は、第１の内部フレーム１３５０を受信し、（たとえば、ホストＢのＩＰ−ＤＡ１３５６によって指示されるように）ホストＢのＶＩＤ／宛先ＩＰアドレスを参照し、第１のフレーム１３４０中のＧＷ１のＭＡＣ−ＤＡ１３５２を第２の内部フレーム１３６０中のＧＷ２のＭＡＣ−ＤＡ１３６２で置換することがある。第２の内部フレーム１３６０は、ＧＷ３のＭＡＣ−ＳＡ１３６４と、ホストＢのＩＰ−ＤＡ１３６６（Ｂ）と、ホストＡのＩＰ−ＳＡ１３６８（Ａ）と、ペイロードとをさらに備えることがある。ＧＷ１は、サービス・プロバイダまたはコアネットワーク１３１０を介して第２の内部フレーム１３６０をＬｏｃ２に送信することがある。

ＧＷ２は、第２の内部フレーム１３６０を受信し、フレームのＭＡＣアドレスを変換するために第２の内部フレーム１３６０を処理することがある。ＧＷ２は、第２の内部フレーム１３６０を受信し、（たとえば、ホストＢのＩＰ−ＤＡ１３６６によって指示されるように）ホストＢのＶＩＤ／宛先ＩＰアドレスを参照し、内部フレーム１３６０中のＧＷ２のＭＡＣ−ＤＡ１３６２を第２のフレーム１３８０中のホストＢのＭＡＣ−ＤＡ１３８２（Ｂ’ｓＭＡＣ）で置換することがある。ＧＷ２は、第２の内部フレーム１３６０中のＧＷ３のＭＡＣ−ＳＡ１３６４をＧＷ２のＭＡＣ−ＳＡ１３８４でさらに置換することがある。ＧＷ２は、その後、第２のフレーム１３８０を宛先ホストＢに送信することがある。

さらに、ホストＢは、Ｌｏｃ２から別のロケーション、たとえば、Ｌｏｃ４（図示せず）に移動することがある。ＧＷ２がホストＢはＬｏｃ２からＬｏｃ４へ移動したことを知った場合、ＧＷ２は、更新内容をこのＧＷ２のピア（他のロケーション内の他のＬ２ＧＷ１３２２）に送信することがある。Ｌｏｃ４内のＬ２ＧＷ１３２２（ＧＷ４）がこれのドメインにホストＢが追加されたことを知ったとき、ＧＷ４は、これのピアをさらに更新することがある。したがって、個々のＬ２ＧＷ１３２２は、ホストＢに関するアドレス情報を更新していることがある。ホストＢがＬｏｃ２からＬｏｃ４へ移動したことをＬ２ＧＷ１３２２がまだ知らない場合、Ｌ２ＧＷ１３２２は、ローカルホストからのホストＢを対象とするフレームを依然としてＬｏｃ２に送信することがある。次に、ＧＷ２は、Ｌｏｃ２においてフレームを受信し、転送することがあるが、ホストＢは、Ｌｏｃ２から移動しているので、フレームは失われる。フレームは、ホストＢがこれの新ロケーションをＬ２ＧＷ１３２２に知らせた後、フレームがＬ２ＧＷ１３２２によって再送信されるまで、一時的に失われることがある。

図１４は、複数のサイトまたはドメインに亘るスードレイヤ２ネットワーク間でメッセージまたはフレームを転送するために使用されることがある別のデータフレーム転送スキーム１４００の実施形態を例示する。データフレーム転送スキーム１４００は、上述の選択肢２に基づくことがあり、スードレイヤ２ネットワーク内で前ロケーションから新ロケーションへ移動し、第２のホストのための同一の知られたＭＡＣアドレスを維持するホストからフレームを転送するために使用されることがある。スードレイヤ２ネットワークは、サービスネットワーク１４１０と、複数のエッジノード１４１２を介してサービスネットワーク１４１０によって接続されることがある複数のレイヤ２ネットワークドメイン１４２０とを備えることがある。レイヤ２ネットワークドメイン１４２０は、複数のＤＣサイトまたはロケーションに位置することがあり、対応するエッジノード１４１２に接続された複数のＬ２ＧＷ１４２２と、対応するＬ２ＧＷ１４２２に（直接的または間接的に）接続された複数の中間スイッチ１４２４とを備えることがある。中間スイッチ１４２４は、複数のホスト／サーバ／ＶＭ１４２６にさらに（直接的または間接的に）接続されることがある。スードレイヤ２ネットワークのコンポーネントは、図１４に示されるように配置されることがあり、仮想レイヤ２ネットワーク２００の対応するコンポーネントに類似することがある。

データフレーム転送スキーム１４００に基づいて、ＧＷ３は、Ｌｏｃ１からＬｏｃ３へ移動した後、第１のホスト１４２６（ホストＡ）から第１のフレーム１４４０、たとえば、イーサネット（登録商標）フレームを受信することがある。フレーム１４４０は、Ｌｏｃ２内の第２のホスト１４２６（ホストＢ）を対象とすることがある。第１のフレーム１３４０は、Ｌｏｃ２内のＧＷ２のＭＡＣ−ＤＡ１４４２と、ホストＡのＭＡＣ−ＳＡ１４４４（Ａ’ｓＭＡＣ）と、ホストＢのＩＰ−ＤＡ１４４６（Ｂ）と、ホストＡのＩＰ−ＳＡ１４４８（Ａ）と、ペイロードとを備えることがある。ＧＷ３は、第１のフレーム１４４０を処理し、たとえば、データフレーム転送スキーム１１００と同様に、第１のフレーム１４４０中のホストＡのＭＡＣ−ＳＡ１４４４（Ａ’ｓＭＡＣ）を内部フレーム１４６０中のＧＷ３のＭＡＣ−ＳＡ１４６４で置換することがある。内部フレーム１４６０は、ＧＷ２のＭＡＣ−ＤＡ１４６２と、ホストＢのＩＰ−ＤＡ１４６６（Ｂ）と、ホストＡのＩＰ−ＳＡ１４６８（Ａ）と、ペイロードとを備えることがある。ＧＷ３は、サービス・プロバイダまたはコアネットワーク１４１０を介して内部フレーム１４６０をＬｏｃ２に送信することがある。

ＧＷ２は、内部フレーム１４６０を受信し、フレームのＭＡＣアドレスを変換するために内部フレーム１４６０を処理することがある。ＧＷ２は、内部フレーム１４６０を受信し、（たとえば、ホストＢのＩＰ−ＤＡ１４６６によって指示されるように）ホストＢのＶＩＤ／宛先ＩＰアドレスを参照し、内部フレーム１４６０中のＧＷ２のＭＡＣ−ＤＡ１４６２を第２のフレーム１４８０中のホストＢのＭＡＣ−ＤＡ１４８２（Ｂ’ｓＭＡＣ）で置換することがある。内部フレーム１４６０は、さらにＧＷ３のＭＡＣ−ＳＡ。ＧＷ２は、その後、第２のフレーム１４８０を宛先ホストＢに送信することがある。

さらに、ホストＢは、Ｌｏｃ２から別のロケーション、たとえば、Ｌｏｃ４（図示せず）に移動することがある。ＧＷ２がホストＢはＬｏｃ２からＬｏｃ４へ移動したことを知った場合、ＧＷ２は、更新内容をこのＧＷ２のピア（他のロケーション内の他のＬ２ＧＷ１３２２）に送信することがある。Ｌｏｃ４内のＬ２ＧＷ１３２２（ＧＷ４）がこれのドメインにホストＢが追加されたことを知ったとき、ＧＷ４は、これのピアをさらに更新することがある。したがって、個々のＬ２ＧＷ１３２２は、ホストＢに関するアドレス情報を更新していることがある。ホストＢがＬｏｃ２からＬｏｃ４へ移動したことをＬ２ＧＷ１３２２２がまだ知らない場合、Ｌ２ＧＷ１３２２は、ローカルホストからのホストＢを対象とするフレームを依然としてＬｏｃ２に送信することがある。次に、ＧＷ２は、Ｌｏｃ２においてフレームを受信し、転送することがあるが、ホストＢは、Ｌｏｃ２から移動しているので、フレームは失われる。フレームは、ホストＢがこれの新ロケーションをＬ２ＧＷ１３２２に知らせた後、フレームがＬ２ＧＷ１３２２によって再送信されるまで、一時的に失われることがある。

上述のスードレイヤ２拡張またはネットワークは、個々のアドレスドメインにおけるアドレス解決をサポートすることがあり、Ｌ２ＧＷのドメイン／ロケーション内のすべてのホストのＩＰアドレスを使ってＬ２ＧＷを最新に更新された状態に保つメカニズムを使用することがある。アドレス解決およびＩＰアドレス更新は、２つのシナリオの一方で実施されることがある。第１のシナリオは、ホストまたはＶＭが追加され次第、または、ネットワークへ移動した後に無償ＡＲＰメッセージを送信するために構成されているときに対応する。第２のシナリオは、追加されるか、または、ネットワークへ移動したホストまたはＶＭがＡＲＰアナウンスメントを送信しないときに対応する。２つのシナリオは、上記仮想レイヤ２ネットワークにおいて説明されたように取り扱われることがある。

仮想レイヤ２ネットワークおよび同様に上述のスードレイヤ２ネットワークは、個々のロケーション／ドメインにおけるアドレス解決と、Ｌ２ＧＷのロケーション／ドメイン内のこのＬ２ＧＷのローカルホストのＩＰアドレスを使って個々のＬ２ＧＷを最新に更新された状態に保つメカニズムとをサポートすることがある。１つのシナリオでは、ホストまたはＶＭがネットワークに追加されたとき、ホストまたはＶＭは、無償ＡＲＰメッセージのようなＡＲＰアナウンスメントをこれのレイヤ２ネットワークまたはローカルエリアに送信することがある。別のシナリオでは、ネットワークに追加されたホストまたはＶＭは、ＡＲＰアナウンスメントを送信しないことがある。

第１のシナリオでは、レイヤ２ネットワークまたはロケーション／ドメイン内の新ＶＭは、無償ＡＲＰメッセージをＬ２ＧＷに送信することがある。Ｌ２ＧＷが無償ＡＲＰメッセージを受信したとき、Ｌ２ＧＷは、これのローカルＩＰＡｄｄｒＴａｂｌｅを更新することがあるが、無償ＡＲＰメッセージを他のロケーション／ドメインまたはレイヤ２ネットワークに転送しないことがある。付加的には、Ｌ２ＧＷは、ホストをシャットダウンする場合、または、ロケーション／ドメインからホストを取り除く場合を取り扱うためにＩＰＡｄｄｒＴａｂｌｅ中の個々のエントリに対しタイマを使用することがある。エントリのタイマが満了しようとしている場合、Ｌ２ＧＷは、（たとえば、ユニキャストを介して）ＡＲＰをエントリのホストに送信することがある。ＡＲＰをブロードキャストする代わりに、ユニキャストメッセージとしてＡＲＰを送信することは、ホストおよびＬ２ＧＷのローカルレイヤ２ドメインをフラッディングさせることを回避することがある。ホストが第１のロケーションから第２のロケーションに移動するとき、Ｌ２ＧＷは、第１のロケーションおよび／または第２のロケーションから更新メッセージを受信することがある。ホストが第１のロケーションおよび第２のロケーションの両方に存在することをＬ２ＧＷが検出した場合、Ｌ２ＧＷは、ホストが第１のロケーション内にもはや存在しないことを検証するために第１のロケーション内でローカルＡＲＰメッセージを送信することがある。ホストが第１のロケーションにもはや存在しないと決定したとき、たとえば、ＡＲＰメッセージへの応答が検出されない場合、Ｌ２ＧＷは、その結果、このＬ２ＧＷのローカルＩＰＡｄｄｒＴａｂｌｅを更新することがある。Ｌ２ＧＷがこのＬ２ＧＷの固有のロケーションに対するＡＲＰメッセージのための応答を受信した場合、ＢＧＰのＭＡＣマルチホーミングメカニズムが使用されることがある。

第２のシナリオでは、ロケーション内の新ホストは、ＡＲＰアナウンスメントを送信しないことがある。この場合、（たとえば、ホストでの）アプリケーションがＩＰホストのＭＡＣアドレスを分解する必要があるとき、アプリケーションは、このロケーション内でブロードキャストされることがあるＡＲＰ要求を送出することがある。ＡＲＰ要求は、たとえば、プロキシＡＲＰ機能を実施することにより、Ｌ２ＧＷ（またはトップ・オブ・ラック（ＴｏＲ）スイッチ）によってインターセプトされることがある。比較的大きいＤＣでは、Ｌ２ＧＷは、すべてのＡＲＰ要求を処理できないことがある。その代わりに、複数のＬ２ＧＷ代表要素（たとえば、ＴｏＲスイッチ）は、ＡＰＲアナウンスメントをインターセプトすることがある。Ｌ２ＧＷは、他のロケーションからこのＬ２ＧＷの対応する代表要素（ＴｏＲスイッチ）に知られたＩＰアドレス（たとえば、ＩＰアドレスの簡略版）をプッシュダウンすることがある。代表要素は、その後、ホストまたはローカルサーバからのＡＲＰ要求をインターセプトすることがある。ホストまたはサーバからのＡＲＰ要求中のＩＰアドレスがＬ２ＧＷのＩＰＡｄｄｒＴａｂｌｅ中に存在する場合、Ｌ２ＧＷは、ブロードキャストされたＡＲＰ要求をさらに転送することなく、Ｌ２ＧＷのＭＡＣアドレスと共にＡＲＰ応答をホストまたはサーバに返送することがある。非ＩＰアプリケーション、たとえば、ＩＰを用いることなくイーサネット（登録商標）に亘って直接的に動くアプリケーションに対し、アプリケーションは、データを送信するとき、ＤＡとしてＭＡＣアドレスを使用することがある。非ＩＰアプリケーションは、データフレームを送信する前にＡＲＰメッセージを送信しないことがある。データフレームは、未知フラッディングまたはマルチプルＭＡＣレジストレーション・プロトコル（ＭＭＲＰ）を使用して転送されることがある。

１つのシナリオでは、（たとえば、ホスト上の）アプリケーションは、対象とされたＩＰアドレスのＭＡＣアドレスを取得するために１つのロケーションにおいて相互接続されたレイヤ２ネットワークの１つに加入し次第、無償ＡＲＰメッセージを送信することがある。Ｌ２ＧＷまたはこれの代表要素（たとえば、ＴｏＲスイッチ）がＡＲＰ要求を受信し、このＬ２ＧＷのＩＰホストテーブルをチェックしたとき、ＩＰアドレスがテーブル中で見つけられた場合、Ｌ２ＧＷは、ＡＲＰ応答をアプリケーションに送信することがある。Ｌ２ＧＷは、対象とされたＩＰアドレスが別のロケーション内のＩＰホストに対応する場合、応答中でこのＬ２ＧＷのＭＡＣアドレスを送信することがある。ＩＰアドレスが見つからない場合、Ｌ２ＧＷから応答が送信されることはなく、このＬ２ＧＷは、すべてのロケーション内のホストの現在または最後の更新されたＩＰアドレスを維持することがある。比較的大きいＤＣでは、複数のＬ２ＧＷが、たとえば、同じロケーション内で使用されることがあり、個々のＬ２ＧＷは、ＶＬＡＮの部分集合を取り扱うことがある。したがって、個々のＬ２ＧＷは、対応するＶＬＡＮ内のホストのＩＰアドレスを備えるＩＰアドレスの部分集合を維持することが必要であることがある。

実質的に大きいＤＣ、たとえば、数万のＶＭを備えるＤＣの場合、単一ノードがすべてのＡＲＰ要求および／または無償ＡＲＰメッセージを取り扱うことは、難しいことがある。この場合、いくつかのスキームが考えられることがある。たとえば、複数のノードまたはＬ２ＧＷが上述のとおりＤＣの内部でＶＬＡＮの異なる部分集合を取り扱うために使用されることがある。付加的または代替的には、複数の代表要素が個々のロケーションにおいてＬ２ＧＷのため割り当てられることがある。たとえば、複数のＴｏＲスイッチまたはアクセススイッチが使用されることがある。個々のＬ２ＧＷの代表要素は、この代表要素の対応するダウンリンク上で、または、ポート・バインディング・プロトコルの形式で無償ＡＲＰメッセージをインターセプトする責任をもつことがある。代表要素は、連結されたアドレスリスト（ＡｄｄｒｅｓｓＬｉｓｔ）をこれらの代表要素のＬ２ＧＷに送信することがある。Ｌ２ＧＷは、このＬ２ＧＷの知られたＩＰアドレスリストを他のロケーションからこのＬ２ＧＷの代表要素へさらにプッシュダウンすることがある。複数のＬ２ＧＷがＶＬＡＮの異なる部分集合に対する責任をもつロケーション内に存在する場合、代表要素は、対応するＬ２ＧＷと関連付けられたＶＬＡＮ内に個々のＡｄｄｒｅｓｓＬｉｓｔを備える複数の連結されたメッセージを送信する必要があることがある。

ＣｉｓｃｏのＯＴＶスキームと比べると、上述の仮想レイヤ２ネットワークを使用することは、個々のロケーションにおける中間スイッチ上の転送テーブルのサイズを実質的に縮小することがある。１つのロケーション内のスイッチは、たとえば、大多数のホストがＩＰアプリケーションを動かすと仮定すると、他のロケーション内のＩＰホストのＭＡＣアドレスを知る必要がないことがある。このスキームは、Ｌ２ＧＷ間で交換されるアドレス情報のサイズをさらに実質的に縮小することがある。たとえば、数千のＶＭを備えることがあるサブネットは、Ｌ２ＧＷＭＡＣアドレスにマッピングされることがある。仮想レイヤ２ネットワークの階層的なレイヤ２スキームは、８０２．１ａｈ規格を使用することがあり、この規格は、商用イーサネット（登録商標）・チップ・セットによってサポートされることがあるが、Ｃｉｓｃｏのスキームは、独自のＩＰカプセル化を使用する。両方のスキームは、外部宛先アドレスとして、ピア・ロケーション・ゲートウェイ機器（Ｌ２ＧＷ）アドレスを使用することがある。階層的なレイヤ２スキームは、アドレス変換をさらに使用することがあり、このアドレス変換は、現在のＩＰゲートウェイによってサポートされることがある。しかし、階層的なレイヤ２スキームは、ＩＰアドレス変換の代わりにＭＡＣアドレス変換を使用することがある。ＭＡＣアドレス変換は、数万のアドレスに対するアドレス変換を実行することができるキャリアグレードＮＡＴ実施を必要とすることがある。

実施形態では、ＶＬＡＮは、複数のロケーションを越えて広がることがある。よって、マルチキャストグループは、複数のロケーションを越えてさらに広がることがある。具体的には、マルチキャストグループは、仮想レイヤ２ネットワーク内のロケーションの部分集合を越えて広がることがある。たとえば、仮想レイヤ２ネットワーク内におよそ１０のロケーションが存在する場合、マルチキャストグループは、１０のロケーションのうちの３つだけを越えて広がることがある。１つのサービスインスタンス内部のマルチキャストグループは、ネットワーク・アドミニストレータ・システム（ＮＭＳ）によって構成されることがあり、または、ＭＭＲＰを使用してＬａｙｅｒ２内に自動的に確立されることがある。Ｌ２ＧＷは、８０２．１ａｈをサポートするので、Ｌ２ＧＷは、クライアント・マルチキャストグループをコアネットワーク内の適切なマルチキャストグループにマッピングするために内蔵式コンポーネントを有することがある。最悪ケースのシナリオでは、Ｌ２ＧＷは、マルチキャスト・データ・フレームをサービスインスタンスのすべてのロケーションに複製することがある。たとえば、Ｍｉｃｒｏｓｏｆｔ研究データによれば、４つのトラフィックのうちのおよそ１つは、異なるロケーションに進むことがある。これによって、Ｌ２ＧＷによる複製は、プロバイダコア内で複雑なメカニズムを実施するより簡単であることがある。

仮想レイヤ２ネットワークは、たとえば、ＡＲＰ要求および／または動的ホスト構成プロトコル（ＤＨＣＰ）要求のためのブロードキャストトラフィックをサポートすることがある。ブロードキャストトラフィックは、個々のロケーションにおいて、ＴｏＲスイッチのような複数のＡＲＰ代表要素を作成することによりサポートされることがある。ブロードキャストトラフィックは、代表要素がサーバからのすべてのＩＰホストの現在更新内容を維持するために、新コンポーネントをポート・バインディング・プロトコルに追加することによりサポートされることもある。付加的には、Ｌ２ＧＷは、周期的または定期的に、他のロケーションからすべての知られたホストＩＰアドレスをプッシュダウンすることがある。

一部の場合に、Ｌ２ＧＷは、未知ＤＡを受信することがある。Ｌ２ＧＷは、これのロケーション内ですべてのホスト（またはアプリケーション）の現在の更新内容を保ち続け、周期的または定期的にこれのアドレス情報をすべてのピア（他のロケーション内の他のＬ２ＧＷ）に押し付けることがある。Ｌ２ＧＷが未知ＤＡを備えるフレームを受信する場合、Ｌ２ＧＷは、フレームを他のロケーションにブロードキャストすることがある。ネットワーク上の攻撃を回避するために、Ｌ２ＧＷが受信された未知ＤＡを転送またはブロードキャストする最大回数に制限が課されることがある。Ｌ２ＧＷは、アドレスを他のロケーションに送信する前に、未知アドレスに対する中間スイッチアドレスを間違えることを回避するために、別のロケーション内の中間スイッチのアドレスを知るために構成されることがある。個々のＤＣロケーションには、数万のＶＭが存在することがあるが、個々のＤＣ内のスイッチの数は、ＴｏＲもしくはアクセススイッチ、エンド・オブ・ローもしくはアグリゲーションスイッチ、および／または、コアスイッチの数のように制限されることがある。Ｌ２ＧＷは、たとえば、個々のスイッチからのブリッジ・プロトコル・データ・ユニット（ＢＰＤＵ）を介して、予めロケーション内のすべての中間スイッチのＭＡＣアドレスを知ることがある。メッセージは、マネジメントシステムまたは運用・管理・保守（ＯＡＭ）メッセージを除いて、中間スイッチに直接的に送信されないことがある。ＮＭＳ／ＯＡＭメッセージを受信することを期待するか、または、受信するために構成されている中間スイッチは、ロケーション内の他のスイッチが自律メッセージをＮＭＳに送信するか、または、ＭＭＲＰアナウンスメントを送信することにより、この中間スイッチのＭＡＣアドレスを知ることを可能にすることがある。

一部の実施形態では、Ｌ２ＧＷは、アドレス情報を交換するため、たとえば、ＩＳ−ＩＳの代わりに、ＢＧＰを使用することがある。複数の選択肢は、レイヤ２（Ｌ２）通信を制御するため使用されることがある。たとえば、転送選択肢は、ＭＡＣおよびＭＡＣを用いるレイヤ２単独転送と、ＭＰＬＳに亘るレイヤ２転送と、レイヤ３ネットワーク内のレイヤ２転送とを含むことがある。レイヤ２制御プレーンの選択肢は、レイヤ２ＩＳ−ＩＳメッシュ制御と、レイヤ２．５ＭＰＬＳ静的制御と、ラベル・ディストリビューション・プロトコル（ＬＤＰ）と、インテリア・ゲートウェイ・プロトコル（ＩＧＰ）制約ベース・ショーテスト・パス・ファースト（ＣＳＦＰ）を使用するリソース・リザベーション・プロトコル（ＲＳＶＰ）−トラフィック・エンジニアリング（ＴＥ）と、ＢＧＰディスカバリとを含むことがある。一意性のため要求されるＶＬＡＮ−ＭＡＣマッピング、および、ネットワークブリッジ型ＶＬＡＮ（たとえば、ＶＬＡＮ−４Ｋ）がＤＣに対して非常に小さいかどうかのような一部のＶＬＡＮマッピング問題がさらに考慮されることがある。表３は、レイヤ２制御プレーンのため使用されることがある複数の制御プレーン選択肢を例示する。これらの選択肢は、ＩＥＥＥ８０２．１ａｈ、ＩＥＥＥ８０２．１ｑ、およびＩＥＥＥ８０２．１ａｑに基づくことがあり、これらのすべてが参照によってここに組み込まれる。表４は、表２中の制御プレーン選択肢の利点および不利点（良い点および悪い点）の一部を例示する。

ＣｉｓｃｏのＯＴＶと、仮想レイヤ２ネットワークによってサポートされることがあるＢＧＰとの間には、複数の相違点が存在することがある。たとえば、ＯＴＶの基本的な態様は、ＯＴＶマルチキャストグループと、ＭＴ−ＩＳ−ＩＳを要求することがあるＯＴＶＩＳ−ＩＳ用法と、ＯＴＶ転送とを含むことがある。付加的には、ＢＧＰは、ＤＣマルチキャストグループの場合のようなＢＧＰ−ＭＡＣマッピングおよびＩＰオーバーレイをサポートすることがある。ＢＧＰ−ＭＡＣマッピングは、ＭＴ−ＢＧＰをさらに使用することがある。さらに、ＩＢＧＰは、ＭＴ−ＩＳ−ＩＳによって、かつ、ピアトポロジのためのＩＳ−ＩＳを使用してサポートされることがある（たとえば、ラベル・スイッチド・パス検証（ＬＳＶＰ））。

上記仮想レイヤ２ネットワークでは、１つのレイヤ２ネットワーク（またはＤＣ）内部のアプリケーションの数は、たとえば、長い間に実質的に増加することがある。よって、実質的に大きいレイヤ２ネットワークと関連付けられた問題を回避するためにメカニズムが必要とされることがある。これらの問題は、サーバ／ホストおよびこれらのアプリケーションの予測できない挙動を含むことがある。たとえば、サーバ／ホストは、異なるベンダに対応することがあり、一部は、ＡＲＰメッセージを送信するため構成されることがあり、その他は、メッセージをブロードキャストするために構成されることがある。さらに、典型的な低コストのレイヤ２スイッチは、フラッディングおよびブロードキャストを制限するようにポリシーが導入されたブロードキャスト・データ・フレームを阻止するために高性能機能をもたないことがある。ホストまたはアプリケーションは、ＩＰマッピングを頻繁に、たとえば、およそ数分単位で目標とするためにＭＡＣアドレスを経時的に消すこともある。ホストは、ホストが（アクティブ状態からスタンバイ状態に）スイッチオーバーを行うとき、または、ホストがソフトウェア・グリッチを有するときなどに無償ＡＲＰメッセージを頻繁に送出することもある。一部の場合、レイヤ２ネットワークのコンポーネントは、より少数のノードへのブロードキャストに限定するために、より小さいサブグループに分割される。

図１５は、レイヤ２ネットワーク／ドメイン、たとえば、仮想レイヤ２ネットワークまたは上記スードレイヤ２ネットワークの一部でもよいＶＬＡＮで使用されることがある典型的なブロードキャストスキーム１５００の実施形態を例示する。レイヤ２ネットワーク／ドメインまたはＶＬＡＮは、ポッド１５３０内、たとえば、ＤＣ内に位置する複数のアクセススイッチ（ＡＳ）１５２２を備えることがある。ＶＬＡＮは、ＡＳ１５２２に接続された複数の閉じたユーザグループ（ＣＵＧ）１５３５をさらに備えることがある。個々のＣＵＧ１５３５は、ＡＳ１５２２に接続された複数のエンド・オブ・ロー（ＥｏＲ）スイッチ１５２４と、ＥｏＲスイッチ１５２４に接続された複数のＴｏＲスイッチ１５３７と、ＴｏＲスイッチ１５３７に接続された複数のサーバ／ＶＭ１５３９とを備えることがある。ＡＳ１５２２は、仮想レイヤ２ネットワークまたはスードレイヤ２ネットワークの他のレイヤ２ネットワーク／ドメインに対応することがある他のＤＣ内の複数のポッド（図示せず）に接続されることがある。レイヤ２ネットワーク／ドメインまたはポッド１５３０のコンポーネントは、図１５に示されるように配置されることがある。

典型的なブロードキャストスキーム１５００は、ブロードキャストスケーラビリティ問題に陥ることがある。たとえば、未知ＤＡをもつフレームは、ＶＬＡＮ内のすべてのエンドシステムに向けてポッド１５３０内部でフラッディングさせられることがある。たとえば、未知ＤＡをもつフレームは、図１５に破線矢印によって指示されるように、ＣＵＧ１５３５においてＡＳ１５２２の全部または複数のサーバ／ＶＭ１５３９へフラッディングさせられることがある。未知アドレスをもつフレームは、ＡＳ１５２２を介して、ポッド１５３０と同じサービスと関連付けられることがあるコア内の（他のＤＣ内の）複数の他のポッドに向かって反対方向にフラッディングされることもある。フレームは、数千のＶＭに達することがある他のポッド内の複数のＶＭにさらにフラッディングされることがある。このような未知ＤＡのためのブロードキャストスキームは、比較的大きいネットワーク、たとえば、多くのＤＣを備えるネットワークでは効率的ではないことがある。

図１６は、レイヤ２ネットワーク／ドメイン、たとえば、仮想レイヤ２ネットワークまたは上記スードレイヤ２ネットワークの一部でもよいＶＬＡＮで使用されることがある別のブロードキャストスキーム１６００の実施形態を例示する。ブロードキャストスキーム１６００は、ブロードキャストスキーム１５００より制御され、よって、よりスケーラブルかつ効率的になることがある。レイヤ２ネットワーク／ドメインまたはＶＬＡＮは、ポッド１６３０、たとえば、ＤＣ内に位置する複数のＡＳ１６２２を備えることがある。ＶＬＡＮは、ＡＳ１６２２に接続された複数のＣＵＧ１６３５をさらに備えることがある。個々のＣＵＧ１６３５は、ＡＳ１６２２に接続された複数のＥｏＲスイッチ１６２４と、ＥｏＲスイッチ１６２４に接続された複数のＴｏＲスイッチ１６３７と、ＴｏＲスイッチ１６３７に接続された複数のサーバ／ＶＭ１６３９とを備えることがある。ＡＳ１６２２は、仮想レイヤ２ネットワークまたはスードレイヤ２ネットワークの他のレイヤ２ネットワーク／ドメインに対応することがある他のＤＣ内の複数のポッド（図示せず）に接続されることがある。レイヤ２ネットワーク／ドメインまたはポッド１６３０のコンポーネントは、図１６に示されるように配置されることがある。

ブロードキャストスキーム１６００のブロードキャスト範囲を制御または制限するために、未知ＤＡをもつフレームは、ポッド１５３０内部で単一のルート、たとえば、ブロードキャストサーバとして指定されることがある１つのサーバ／ＶＭ１６３９、または、ＡＳ１６２２だけに向けてフラッディングされることがある。フレームは、ルート化マルチポイント（ＲＭＰ）ＶＬＡＮ構成、たとえば、ブロードキャストサーバでルート化されたＲＭＰＶＬＡＮのためのプッシュＶＬＡＮタグを使用してルートに向けてフラッディングされることがある。しかし、フラッディングされたフレームは、たとえば、ブロードキャストサーバではないすべての他のサーバに転送されないことがあり、このことは、リンクリソースと無関係なフレームのサーバ処理とを節約することがある。付加的には、転送されたフレームは、コア、たとえば、他のポッドまたはＤＣに転送されないことがある。

一部の実施形態では、ブロードキャストサーバは、たとえば、効率、スケーラビリティ、および／またはセキュリティを改善するため、プロキシＡＲＰサーバ、ＤＨＣＰサーバ、および／または他の具体的な機能サーバをホストすることがある。たとえば、ブロードキャストサーバは、選択されたブロードキャストサービスだけを可能にするＤＣ内にセキュリティを提供するために構成されることがある。既知サービスが選択されない場合、未知ＤＡをもつデータフレームは、最初または元のＶＬＡＮ上のブロードキャストサーバからフラッディングされることがある。ブロードキャストスキーム１６００は、顧客アプリケーションがレイヤ２ブロードキャストを使用することが許されるケースを取り扱うために使用されることがある。データ・レート・リミッタは、ブロードキャストストームを防ぐために、たとえば、かなりの量のブロードキャストトラフィックを回避するために同様に使用されることがある。

上述のとおり、ＤＣ内のサーバ仮想化を導入するとき、ＤＣ内のホストの数は、たとえば、長い間に実質的に増加することがある。サーバ仮想化を使用して、最初に終端局をホストすることがある個々の物理サーバは、数百の終端局またはＶＭをホストできるようになることがある。ＶＭは、追加、削除、および／または、サーバ間で柔軟に移動されることがあり、このことは、サーバの性能および稼働率を改善することがある。この能力は、たとえば、クライアント制御型仮想サブネットおよび仮想ホストを提供するために、クラウド・コンピューティング・サービスのための基礎的要素として使用されることがある。クラウド・コンピューティング・サービスによって提供されるクライアント制御仮想サブネットは、クライアントが対応するＩＰアドレスおよびポリシーを使って自分の固有のサブネットを定義することを可能にすることがある。

仮想ホストの急速な成長は、ネットワークおよびサーバに実質的に影響を与えることがある。たとえば、１つの結果として生じる問題は、ホストからのＡＲＰＩＰバージョン４（ＩＰｖ４）要求のような頻繁なＡＲＰ要求、または、ＮＤＩＰバージョン６（ＩＰｖ６）要求のようなネイバー・ディスカバリ（ＮＤ）要求を取り扱うことであり得る。ＤＣ内のホストは、およそ数分単位で古くなることがあるキャッシュまたはエントリに起因して頻繁にこのような要求を送出することがある。ＤＣ内に異なるＭＡＣアドレスを有することがある数万のホストがある場合、１秒当たりのＡＲＰまたはＮＤメッセージもしくは要求の量は、１秒当たりに約１，０００から１０，０００要求を超えることがある。この要求のレートまたは頻度は、ホストにかなりの計算的負荷をかけることがある。ＤＣ内の実質的に多数の仮想ホストと関連付けられた別の問題は、１つのＶＬＡＮ内部に重複ＩＰアドレスが存在することであり得、これは、ＡＲＰまたはＮＤスキームが適切に作用することに影響を及ぼすことがある。一部のロードバランシング技術は、異なるＭＡＣアドレスをもつが、同じＩＰアドレスを使用するために同じアプリケーションに役立つ複数のホストを必要とすることがある。一部のクラウド・コンピューティング・サービスは、ユーザがＩＰアドレスとサブネット間で自己定義されたポリシーとを使って自分の固有のサブネットを使用することを可能にすることがある。したがって、利用可能なＶＬＡＮＳの最大数は、一部のシステムでは約４０９５であり、一方、数十万のクライアントサブネットが存在することがあるので、クライアント毎にＶＬＡＮを指定することは不可能であるかもしれない。このシナリオでは、結局は１つのＶＬＡＮである異なるクライアントサブネット内に重複ＩＰアドレスが存在することがある。

実施形態では、ＶＭおよび／または終端局のようなかなりの数のホストを含む単一のＶＬＡＮを備えることがある実質的に大きいレイヤ２ネットワークで使用されることがあるスケーラブル・アドレス解決・メカニズム。付加的には、重複ＩＰアドレスをもつＶＬＡＮにおける適切なアドレス解決のためのメカニズムが記載される。このメカニズムは、ＡＲＰＩＰｖ４アドレスおよびＮＤＩＰｖ６アドレスの両方のため使用されることがある。

図１７は、ブリッジ型レイヤ２ネットワーク、たとえば、イーサネット（登録商標）における相互接続型ネットワーク区域１７００の実施形態を例示する。ブリッジ型レイヤ２ネットワークは、コア区域１７１０内に、複数の区域１７２０に接続されることがある複数のコアブリッジ１７１２を備えることがある。レイヤ２ブリッジ型ネットワークは、コア区域１７１０および区域１７２０の一部でもよく、よって、コア区域１７１０と区域１７２０とを接続することがある複数のＤＢＢ１７２２をさらに備えることがある。個々の区域１７２０は、対応するＤＢＢ１７２２に接続された複数の中間スイッチ１７２４と、対応する中間スイッチ１７２４に接続された複数の終端局１７２６、たとえば、サーバ／ＶＭとをさらに備えることがある。相互接続型ネットワーク区域１７００のコンポーネントは、図１７に示されるように配置されることがある。

図１８は、相互接続型区域１７００と同様に構成されることがある相互接続型ネットワーク区域１８００の別の実施形態を例示する。相互接続型ネットワーク区域１８００は、コア区域１８１０内に、複数のコアブリッジ１８１２と、複数のＤＢＢ１８２２（たとえば、ＴｏＲスイッチ）または区域境界スイッチとを備えることがある。相互接続型ネットワーク区域１８００は、複数の区域１８２０内に、複数の中間スイッチ１８２４と、複数の終端局１８２６、たとえば、サーバ／ＶＭとをさらに備えることがある。区域１８２０は、区域１８２０をコア区域１８１０に接続するＤＢＢ１８２２をさらに備えることがある。相互接続型ネットワーク区域１８００のコンポーネントは、図１８に示されるように配置されることがある。ＶＬＡＮは、図１８中に太い実線によって指示されるように、相互接続型ネットワーク区域１８００内に確立されることがある。ＶＬＡＮは、ＶＩＤと関連付けられることがあり、コアブリッジ１８１０内のコアブリッジ１８１２の１つと、区域１８２０内のＤＢＢ１８２２の部分集合と、区域１８２０内の中間スイッチ１８２４およびサーバ／ＶＭ１８２６の部分集合との間に確立されることがある。

区域１８２０内のＤＢＢ１８２２は、区域１８２０内の個々の終端局１８２６のための＜ＭＡＣ、ＶＩＤ＞ペアを知り、維持することがある。このアドレス情報は、エッジ仮想ブリッジング（ＥＶＢ）仮想局インターフェース（ＶＳＩ）ディスカバリおよび構成プロトコル（ＶＤＰ）を介して、終端局１８２６によって対応する区域１８２０内の対応するＤＢＢ１８２２に通信されることがある。ＤＢＢ１８２２は、たとえば、ＭＭＲＰを介して、この情報を他のＤＢＢ１８２２にさらに登録することがある。代替的には、アドレス情報は、無償ＡＲＰメッセージを使用して、または、ＮＭＳから構成メッセージを送信することにより、終端局１８２６によってこれらのＤＢＢ１８２２に通信されることがある。

実施形態では、スケーラブル・アドレス解決・メカニズムは、相互接続型ネットワーク区域１８００内に比較的多数のホストを備えるＶＬＡＮをサポートするために実施されることがある。具体的には、１つの区域１８２０内のＤＢＢ１８２２のＭＡＣアドレスとＶＬＡＮのＶＩＤとは、他の区域１８２０からのこの区域のホストアドレスのＡＲＰ要求への応答として使用されることがある。一部のケースでは、ＤＳが個別の終端局１８２６またはホストのための比較的多数のメッセージを取り扱う能力をもたないことがあるとき、ＤＳは、区域１８２０内の終端局１８２６のための簡略化されたアドレス情報を取得するために構成されることがある。このようなケースでは、区域１８２０内のＤＢＢ１８２２は、区域のホストのためのすべての無償ＡＲＰメッセージを終端すること、または、これの区域１９２０から送信されたすべての無償ＡＲＰメッセージをスヌープし、そして、その代わりに、たとえば、ＤＳのためのホストアドレス情報を簡略化する無償グループアナウンスメントを送出することがある。ＤＢＢは、この区域１８２０内のすべてのホストＩＰアドレスを他の区域１８２０に知らせるために、このＤＢＢの固有の無償ＡＲＰアナウンスメントを送信することがある。

さらに、区域１８２０内のＤＢＢ１８２２は、たとえば、コア区域１８１０内のコアブリッジ１８１２を介して、このＤＢＢの固有のＭＡＣアドレスを他の区域１８２０に送信することにより、ＡＲＰプロキシとして役立つことがある。コアブリッジ１８１２は、中間スイッチ１８２４および終端局１８２６またはホストのＭＡＣアドレスではなく、区域１８２０内のＤＢＢ１８２２のＭＡＣアドレスだけを知ることがあり、このことは、このスキームをよりスケーラブルにさせる。たとえば、第１の区域１８２０内の第１の終端局１８２６が第２の区域１８２０内の第２の終端局１８２６のアドレスのためのＡＲＰ要求を送信するとき、第２の区域１８２０のＤＢＢ１８２２のＭＡＣアドレスは、第１の終端局１８２６に応答して返送されることがある。

図１９は、たとえば、相互接続型ネットワーク区域１８００のためのレイヤ２ブリッジ型ネットワークにおいて使用されることがあるＡＲＰプロキシスキーム１９００の実施形態を例示する。レイヤ２ブリッジ型ネットワークは、コア区域１９１０と、コア区域１９１０に接続された複数のＤＢＢ１９２２または区域境界スイッチと、これらの区域内の対応するＤＢＢ１９２２に接続された複数の終端局１９２６（たとえば、ＶＭ）とを備えることがある。レイヤ２ブリッジ型ネットワークは、たとえば、コア区域１９１０を介してＤＢＢ１９２２に接続されることがあるＤＳ１９４０をさらに備えることがある。ＤＢＢ１９２２および終端局１９２６は、レイヤ２ブリッジ型ネットワーク内に確立され、ＶＩＤと関連付けられたＶＬＡＮに属することがある。レイヤ２ブリッジ型ネットワークのコンポーネントは、図１９に示されるように配置されることがある。

ＡＰＲプロキシスキーム１９００に基づいて、第１のＤＢＢ１９２２（ＤＢＢＸ）は、これのローカル区域内の第１の終端局１９２６からのＡＲＰ要求をインターセプトすることがある。ＡＲＰ要求は、別の区域内の第２の終端局１９２６のためのＭＡＣアドレスを目的とすることがある。ＡＲＰ要求は、第２の終端局１９２６のＩＰＤＡ（１０．１．０．２）と、ＩＰ送信元アドレス（ＳＡ）（１０．１．０．１）と、第１の終端局１９２６のＭＡＣＳＡ（Ａ）とを備えることがある。第１の終端局１９２６は、ＶＭＡＲＰテーブル１９６０中の他の終端局１９２２のＩＰアドレスを維持することがある。ＤＢＢＸは、ＤＳ１９４０から第２の終端局１９２６のためのＭＡＣアドレスを取得するためにＤＳ問い合わせを送信することがある。このＤＳ問い合わせは、第２の終端局１９２６のＩＰアドレス（１０．１．０．２）と、第１の終端局１９２６のＩＰＳＡ（１０．１．０．１）およびＭＡＣＳＡ（Ａ）とを備えることがある。ＤＳ１９４０は、ＤＳアドレステーブル１９５０中に、ＩＰアドレスと、ＭＡＣアドレスと、関連付けられたＤＢＢ１９２２に関する情報または終端局１９２６（ホスト）のロケーションとを備えることがある。

ＤＳ１９４０は、その後、ＤＳアドレステーブル１９５０に指示されるように、第２の終端局１９２６のＩＰアドレス（１０．１．０．２）と、他の区域内の第２の終端局１９２６と関連付けられた第２のＤＢＢ１９２６のＭＡＣアドレス（Ｙ）（ＤＢＢＹ）とを備えるＤＳ応答をＤＢＢＸに返送することがある。次に、ＤＢＢＸは、第１の終端局１９２６のＩＰＤＡ（１０．１．０．１）およびＭＡＣＤＡ（Ａ）と、第２の終端局１９２６のＩＰＳＡ（１０．１．０．２）と、ＤＢＢＹのＭＡＣアドレス（Ｙ）とを備えるＡＲＰ応答を第１の終端局１９２６に送信することがある。第１の終端局１９２６は、その後、ＶＭＡＲＰテーブル１９６０において、ＤＢＢＹのＭＡＣアドレス（Ｙ）を第２の終端局１９２６のＩＰアドレス（１０．１．０．２）と関連付けることがある。第１の終端局１９２６は、第２の終端局１９２６を対象としたフレームを転送するためにＤＡとしてＤＢＢＹのＭＡＣアドレスを使用することがある。

ＡＲＰプロキシスキーム１９００では、ＤＢＢ１９２２は、区域内のホストのＭＡＣアドレスおよびＩＰアドレス無しで、区域内の他のＤＢＢ１９２２のＭＡＣアドレスだけを維持することが必要とされることがある。上述のとおり、ＤＢＢ１９２２に送信されたデータフレーム内のＤＡだけがＤＢＢＭＡＣアドレスに対応するので、ＤＢＢ１９２２は、他のアドレスを知る必要がないことがあり、このことは、このスキームをよりスケーラブルにさせる。

図２０は、たとえば、相互接続型ネットワーク区域１８００のためレイヤ２ブリッジ型ネットワークにおいて使用されることがあるデータフレーム転送スキーム２００の実施形態を例示する。レイヤ２ブリッジ型ネットワークは、コア区域２０１０と、コア区域２０１０に接続された複数の区域２０２０内の複数のＤＢＢ２０２２または区域境界スイッチと、これらの区域２０２０内の対応するＤＢＢ２０２２に接続された複数の中間スイッチ２０２４および終端局２０２６（たとえば、ＶＭ）とを備えることがある。区域２０２０を越えるＤＢＢ２０２２、中間スイッチ２０２４、および終端局２０２６の一部は、レイヤ２ブリッジ型ネットワークに確立され、ＶＩＤと関連付けられたＶＬＡＮに属することがある。レイヤ２ブリッジ型ネットワークのコンポーネントは、図２０に示されるように配置されることがある。

データフレーム転送スキーム２０００は、ＩＰＮＡＴに類似することがあるＤＢＢ２０２２におけるＭＡＴに基づくことがある。ＭＡＴは、対応するＭＡＣＤＡを見つけるために内部ＩＰＤＡおよびＡＲＰテーブルを使用することを備えることがある。たとえば、第１のＤＢＢ２０２２（ＤＢＢ１）は、第１の区域（区域１）内の第１の終端局２０２６（ホストＡ）からフレーム２０４０、たとえば、イーサネット（登録商標）フレームを受信することがある。フレーム２０４０は、第２の区域（区域２）内の第２の終端局２０２６（ホストＢ）を対象とすることがある。フレーム２０４０は、区域２内の第２のＤＢＢのＭＡＣ−ＤＡ２０４２（ＤＢＢ２）と、ホストＡのＭＡＣ−ＳＡ２０４４（Ａ’ｓＭＡＣ）と、ホストＢのＩＰ−ＤＡ２０４６（Ｂ）と、ホストＡのＩＰ−ＳＡ２０４８（Ａ）と、ペイロードとを備えることがある。ＤＢＢ１は、コア区域２０１０を介してフレーム２０４０を区域２に転送することがある。区域２内の第２のＤＢＢ２０２２（ＤＢＢ２）は、フレーム２０４０を受信し、フレーム２０４０中のＤＢＢ２のＭＡＣ−ＤＡ２０４２（ＤＢＢ２）を第２のフレーム２０８０中のホストＢのＭＡＣ−ＤＡ２０８２（Ｂ’ｓＭＡＣ）で置換することがある。ＤＢＢ２は、ホストＢのＩＰ−ＤＡ２０４６（Ｂ）と、これのＡＲＰテーブル中の対応するエントリとに基づいて、Ｂ’ｓＭＡＣを決定することがある。第２のフレームは、ホストＡのＭＡＣ−ＳＡ２０８４（Ａ’ｓＭＡＣ）と、ホストＢのＩＰ−ＤＡ２０８６（Ｂ）と、ホストＡのＩＰ−ＳＡ２０８８（Ａ）と、ペイロードとさらに備えることがある。ＤＢＢ２は、第２のフレーム２０８０を区域２内のホストＢに送信することがある。区域２で受信されたフレーム中のＳＡは、変更されていないのでデータフレーム転送スキーム２０００は、ネットワーク内で実施されたＤＨＣＰに影響を与えないことがある。

上記ネットワークでは、コア区域のコアブリッジまたはスイッチ、たとえば、コア区域１８１０内のコアブリッジ１８１２は、区域内のホストのＭＡＣアドレスおよびＩＰアドレス無しに、区域内のＤＢＢのＭＡＣアドレスだけを維持することが必要とされることがある。コア区域を介して転送されたデータフレーム中のＤＡは、上述のとおり、ＤＢＢＭＡＣアドレスだけに対応することがあるので、コアブリッジは、他のアドレスを知る必要がないことがある。ＤＢＢのＭＡＣアドレスは、コアブリッジの転送データベース（ＦＤＢ）内に維持されることがある。コアブリッジまたはスイッチは、リンク・ステートに基づくプロトコルを介してすべてのＤＢＢのトポロジを知ることがある。たとえば、ＤＢＢは、たとえば、ＩＥＥＥ８０２．１ａｑ、トランスペアレント・インターコネクト・オブ・ロッツ・オブ・リンク（ＴＲＩＬＬ）、またはＩＰに基づくコアを使用してリンク・ステート・アドバタイズメント（ＬＳＡ）を送出することがある。スパニング・ツリー・プロトコル（ＳＴＰ）がコアブリッジの間で使用される場合、ＭＡＣアドレス・ラーニングは、コアブリッジで停止される。この場合、ＤＢＢは、ＤＢＢ自体をコアブリッジに登録することがある。

実施形態では、ＤＢＢは、ＤＳが使用されていない場合、上述のとおり、ＡＲＰプロキシとしての役目を果たすことがある。無償ＡＲＰメッセージは、終端局の一意のＭＡＣアドレスを知らせるために終端局によって送信されることがある。無償グループアナウンスメントは、ＤＢＢの一意のＭＡＣアドレスとＤＢＢのローカル区域内部のすべてのホストのＩＰアドレスとを知らせるためにＤＢＢによってさらに送信されることがある。無償グループアナウンスメントは、ＭＡＣアドレスおよびＩＰアドレスを他の区域内の他のＤＢＢに知らせるために使用されることがある。知らされたＭＡＣアドレスおよびＩＰアドレスは、他のＤＢＢＳ内で、ホストＩＰＤＡに応じて受信されたフレーム中のＤＢＢＭＡＣＤＡを変換するために使用されることがある。無償グループＡＲＰは、ＤＢＢと関連付けられた個々のＶＬＡＮのためのホストＩＰアドレスの部分集合を知らせるためにＤＢＢによって送信されることがある。無償グループＡＲＰは、ＤＢＢのための複数のＶＬＡＮへのホストＩＰアドレスの部分集合のマッピングを備えることがある。

表５は、相互接続型区域内の対応するＤＢＢＭＡＣアドレスにホストＩＰアドレスをマッピングする実施例を例示する。このマッピングは、ＤＢＢと関連付けられた個々のＶＬＡＮのためのＤＢＢのホストＩＰアドレスを知らせるためにＤＢＢによって無償グループＡＲＰ中で送信されることがある。ＤＢＢＭＡＣアドレス（ＤＢＢ−ＭＡＣ）は、複数の対応するホストＩＰアドレスにマッピングされることがある。個々のＤＢＢＭＡＣアドレスは、同じ区域内でも異なる区域内でもよい複数のＶＬＡＮ内の複数のホストＩＰアドレス（たとえば、ＶＩＤ−１、ＶＩＤ−２、ＶＩＤ−ｎ、・・・）にマッピングされることがある。

一部の状況では、相互接続された区域内の複数のホストは、同じＩＰアドレスを有することがあり、同じＶＬＡＮ（またはＶＩＤ）と関連付けられることがある。たとえば、クラウド・コンピューティング・サービスの仮想サブネットは、クライアントが自分の固有のプライベートＩＰアドレスに名前を付けることを許すことがある。クラウド・コンピューティング・サービスによって提供される仮想サブネットの数は、許可されたＶＬＡＮの総数（たとえば、約４０９５のＶＬＡＮ）を実質的に超えることがある。したがって、複数の仮想ホスト（たとえば、ＶＭまたは仮想終端局）は、ＭＡＣアドレスは異なるが、同じＩＰアドレスをもつことを許可されることがある。他の例では、複数の終端局は、同じＩＰアドレスおよび異なるＭＡＣアドレスを使用して同じアプリケーションに役立つことがある。

実施形態では、ＤＢＢは、たとえば、同じ（重複）ＩＰアドレスを使用する異なるホストを区別するために、ここでは代表ＭＡＣアドレスと呼ばれる複数のＭＡＣアドレスが割り当てられることがある。ＤＢＢは、複数のＶＬＡＮとさらに関連付けられることがある。さらに、ＤＢＢ上の個々のＶＬＡＮは、たとえば、ＶＬＡＮ内部にホストの異なる部分集合を備える複数のサブネットまたは仮想サブネットと関連付けられることがある。仮想サブネットは、複数のサブネットＩＤと関連付けられることがある。ホストのための重複ＩＰアドレスの数がＶＬＡＮの仮想サブネットの数より実質的に少ない場合、ＤＢＢのための代表要素ＭＡＣアドレスの数は、同様に実質的に少なくなることがある。

図２１は、レイヤ２ブリッジ型ネットワーク内の相互接続されたネットワーク区域のため使用されることがあるＡＲＰプロキシスキーム２１００の実施形態を例示する。レイヤ２ブリッジ型ネットワークは、コア区域２１１０と、コア区域２１１０に接続された複数のＤＢＢ２１２２または区域境界スイッチと、これらの区域内の対応するＤＢＢ２１２２に接続された複数の終端局２１２６（たとえば、ＶＭ）とを備えることがある。レイヤ２ブリッジ型ネットワークは、たとえば、コア区域２１１０を介してＤＢＢ２１２２に接続されることがあるＤＳ２１４０をさらに備えることがある。ＤＢＢ２１２２および終端局２１２６は、レイヤ２ブリッジ型ネットワークに確立されたＶＬＡＮに属することがある。レイヤ２ブリッジ型ネットワークのコンポーネントは、図２１に示されるように配置されることがある。

ＡＲＰプロキシスキーム２１００に基づいて、第１のＤＢＢ２１２２（ＤＢＢＸ）は、このローカル区域内の第１の終端局２２２６からのＡＲＰ要求をインターセプトすることがある。ＡＲＰ要求は、別の区域内の第２の終端局２１２６のためのＭＡＣアドレスを目的とすることがある。このＡＲＰ要求は、第２の終端局２１２６のＩＰＤＡ（１０．１．０．２）と、第１の終端局２１２６のＩＰＳＡ（１０．１．０．１）およびＭＡＣＳＡ（Ａ）とを備えることがある。第１の終端局２１２６は、ＶＭＡＲＰテーブル２１６０中に他の終端局２１２２のＩＰアドレスを維持することがある。ＤＢＢＸは、その後、ＤＳ２１４０から第２の終端局２１２６のＭＡＣアドレスを取得するためにＤＳ問い合わせを転送することがある。ＤＳ問い合わせは、第２の終端局２１２６のＩＰアドレス（１０．１．０．２）と、第１の終端局２１２６のＩＰＳＡ（１０．１．０．１）およびＭＡＣＳＡ（Ａ）とを備えることがある。ＤＳ２１４０は、ＩＰアドレスと、ＭＡＣアドレスと、ＶＬＡＮＩＤまたはＶＩＤと、顧客（仮想サブネット）ＩＤと、関連付けられたＤＢＢ２１２２に関する情報または終端局２１２６のロケーションとをＤＳアドレステーブル２１５０に維持することがある。

ＤＳ２１４０は、要求元ＶＭ（第１の終端局２１２６）に属する顧客（仮想サブネット）ＩＤを決定するためにＤＳ問い合わせ中でＭＡＣＳＡ（Ａ）を使用することがある。たとえば、ＤＳアドレステーブル２１５０に応じて、顧客ＩＤＪｏｅは、ＭＡＣＳＡ（Ａ）に対応する。ＤＳ２１４０は、その後、第２の終端局２１２６のＩＰアドレス（１０．１．０．２）と、第１の終端局２１２６の顧客ＩＤ（Ｊｏｅ）に関連付けられた第２のＤＢＢ２１２６の代表ＭＡＣアドレス（Ｙ１）（ＤＢＢＹ）とを備えるＤＳ応答をＤＢＢＸに返送することがある。次に、ＤＢＢＸは、第１の終端局２１２６のＩＰＤＡ（１０．１．０．１）およびＭＡＣＤＡ（Ａ）と、第２の終端局２１２６のＩＰＳＡ（１０．１．０．２）と、ＤＢＢＹの代表ＭＡＣアドレス（Ｙ１）とを備えるＡＲＰ応答を第１の終端局２１２６に送信することがある。第１の終端局２１２６は、その後、ＶＭＡＲＰテーブル２１６０において、ＤＢＢＹの代表ＭＡＣアドレス（Ｙ１）を第２の終端局２１２６のＩＰアドレス（１０．１．０．２）と関連付けることがある。第１の終端局２１２６は、第２の終端局２１２６を対象とするフレームを転送するためにＤＢＢＹの代表ＭＡＣアドレスをＤＡとして使用することがある。

別の区域内の第３の終端局２１２６は、（第２の終端局２１２６のＡＲＰ要求を第３の終端局の区域内の対応するローカルＤＢＢ２１２２（ＤＢＢＺ）にさらに送信することがある。ＤＢＢＺは、その後、上述のとおり、ＤＳ２１４０と通信し、その結果、第３の終端局２１２６のＩＰＤＡ（１０．１．０．３）およびＭＡＣＤＡと、第２の終端局２１２６のＩＰＳＡ（１０．１．０．２）と、ＤＳアドレステーブル２１５０中で顧客ＩＤＢｏｂに関連付けられた第３の終端局２１２６のＤＢＢＹの代表ＭＡＣアドレス（Ｙ２）とを備えるＡＲＰ応答を第３の終端局２１２６に返送することがある。第３の終端局２１２６は、その後、第３の終端局２１２６のＶＭＡＲＰテーブル２１７０においてＤＢＢＹの代表ＭＡＣアドレス（Ｙ２）を第２の終端局２１２６のＩＰアドレス（１０．１．０．２）と関連付けることがある。第３の終端局２１２６は、第２の終端局２１２６を対象とするフレームを転送するためにＤＢＢＹのこの代表ＭＡＣアドレスをＤＡとして使用することがある。

表６は、相互接続された区域においてＶＬＡＮ内の対応する代表ＤＢＢＭＡＣアドレスに重複ホストＩＰアドレスをマッピングする実施例を例示する。重複ホストアドレスは、１つの対象とされたアプリケーションまたはホストのため複数のホストによって使用されることがある。代表ＭＡＣＤＢＢアドレスは、同じアプリケーションを使用する（または同じホストと通信する）異なるホストに対し割り当てられることがある。個々のＶＬＡＮに対して、ホストＩＰアドレスは、たとえば、ＶＬＡＮの異なるサブネットと関連付けられた複数のホストのための複数の代表ＤＢＢＭＡＣアドレス（ＭＡＣ−１２、ＭＡＣ−１３、ＭＡＣ−１４、・・・）にマッピングされることがある。代表ＤＢＢＭＡＣアドレスは、ベース（オリジナル）ＤＢＢＭＡＣアドレスアドレス（ＭＡＣ−１１）と関連付けられることもある。同じＩＰのためのベースおよび代表ＤＢＢＭＡＣアドレスは、異なるＶＬＡＮに対して異なることがある。ＶＬＡＮが代表アドレスを有しない場合、ＤＢＢベースアドレスは、このＶＬＡＮのため使用されることがある。１つのＶＬＡＮの内部におよそ１０の重複ＩＰアドレスが存在する場合、表６中のおよそ１０列（１０個のＭＡＣアドレス）が使用されることがある。

表７は、たとえば、複数のサブネットのための複数の代表ＭＡＣアドレスにホストＩＰアドレスをマッピングする実施例を例示する。このマッピングは、ＤＢＢと関連付けられた個々のＶＬＡＮのためのＤＢＢのホストＩＰアドレスを知らせるために、ＤＢＢによって無償グループＡＲＰ中で送信されることがある。個々の代表ＭＡＣアドレス（ＤＢＢ−ＭＡＣ１、ＤＢＢ−ＭＡＣ２、・・・）は、サブネット内の複数の対応するホストＩＰアドレスにマッピングされることがある。個々の代表ＤＢＢＭＡＣアドレスは、ホストＩＰアドレスのための顧客または仮想サブネットＩＤと関連付けられることがある。個々の代表ＤＢＢＭＡＣアドレスのためのホストＩＰアドレスは、複数のＶＬＡＮ（ＶＩＤ−１、ＶＩＤ−２、ＶＩＤ−ｎ、・・・）に対応することもある。個々のサブネット内のホストＩＰアドレスは、異なることがある。同一のＶＬＡＮと関連付けられているが、異なる顧客ＩＤと関連付けられている重複ホストＩＰアドレスは、異なる代表ＤＢＢＭＡＣアドレスにマッピングされることがある。

図２２は、レイヤ２ブリッジ型ネットワーク内の相互接続されたネットワーク区域のため使用されることがあるフェイルオーバースキーム２２００の実施形態を例示する。このフェイルオーバースキーム２１００は、相互接続された区域内のいずれかのＤＢＢ（たとえば、ＴｏＲスイッチ）が故障した場合に使用されることがある。レイヤ２ブリッジ型ネットワークは、コア区域１８１０内の複数のコアブリッジ２２１２および複数のＤＢＢ２２２２または区域境界スイッチと、複数の区域２２２０とを備えることがある。区域２２２０は、ＤＢＢ２２２２と、複数の中間スイッチ２２２４と、複数の終端局２２２６、たとえば、サーバ／ＶＭとを備えることがある。レイヤ２ブリッジ型ネットワークは、たとえば、コア区域２２１０を介してＤＢＢ２２２２に接続されることがあるＤＳ（図示せず）をさらに備えることがある。ＤＢＢ２２２２と、中間スイッチ２２２４と、終端局２２２６とのうちの一部は、レイヤ２ブリッジ型ネットワーク内に確立されたＶＬＡＮに属することがある。レイヤ２ブリッジ型ネットワークのコンポーネントは、図２２に示されるように配置されることがある。

アクティブＤＢＢ２２２２がＶＬＡＮ内で故障したとき、ＶＬＡＮは、１つ以上のスタンバイＤＢＢ２２２２を使用して確立されることがある。スタンバイＤＢＢ２２２は、ＶＬＡＮに属する中間スイッチ２２２４の少なくとも一部、および、おそらく新たな１つのコアブリッジ２２１２とアクティブ接続を確立することがある。これは、図２２において破線によって指示される。したがって、終端局２２２６がＶＬＡＮに亘って通信することを可能にするＶＬＡＮの終端局２２２６へのパスは、失われないことがある。ＶＬＡＮ内のＤＢＢ２２２が故障したとき、たとえば、明示的なメッセージをＤＳに送信するか、または、キープアライブ方法を使用することにより、ＤＳに故障が通知されることがある。このようにして、ＤＢＢは、故障したＤＢＢ、および、おそらくＤＳアドレステーブルのエントリ中のＶＬＡＮ内の他の元のＤＢＢ２２２２のアドレス情報をスタンバイ状態にあり、故障した他の元のＤＢＢ２２２２を置換するために使用された新たなＤＢＢ２２２２の情報で置換することがある。置換された故障した元のＤＢＢは、図２２では円によって指示される。故障したＤＢＢ２２２２を検出し次第、置換ＤＢＢは、すべての代表アドレスを含む故障したＤＢＢのアドレスが置換ＤＢＢ２２２２によって到達可能であることを指示するために、ＬＳＡをＤＳまたはコア区域２０１０に送信することがある。

サーバ仮想化を用いて、物理サーバは、より多くのＶＭ、たとえば、数十から数百の仮想終端局またはＶＭをホストすることがある。これは、ＤＣ内の仮想ホストの数の実質的な増加をもたらすことがある。たとえば、１つずつが最大約１２８台のＶＭをサポートすることがある約５０，０００台のサーバを備える比較的大きいＤＣの場合、ＤＣ内のＶＭの総数は、約５０，０００×１２８、すなわち、約６，４００，０００台のＶＭに匹敵することがある。このような大規模サーバプール全体の動的なリソース割り付けを達成するために、イーサネット（登録商標）ベースのレイヤ２ネットワークがＤＣ内で使用されることがある。おそらくかなりの数の仮想ホストを備えることになるこのような大規模レイヤ２ネットワークは、基礎となるイーサネット（登録商標）技術に新しい難題をもたらすことがある。たとえば、１つの問題は、フラットなＭＡＣアドレス空間に起因したＭＡＣ転送テーブルスケーラビリティであり得る。別の問題は、ＡＲＰおよび他のブロードキャストトラフィックによって引き起こされるブロードキャストストームの取り扱いであり得る。

ここではＦＤＢとも呼ばれるネットワークのコアにおけるＭＡＣ転送テーブルのサイズを縮小するための１つのアプローチは、たとえば、ＩＥＥＥ８０２．１ａｈおよびＴＲＩＬＬに準拠したネットワーク・アドレス・カプセル化を使用することであり得る。８０２．１ａｈおよびＴＲＩＬＬのネットワーク・アドレス・カプセル化は、ＩＥＥＥＰ８０２．１ａｈ／Ｄ４．２規格、および、ＩＥＴＦ草案ｄｒａｆｔ−ｉｅｔｆ−ｔｒｉｌｌ−ｒｂｒｉｄｇｅ−ｐｒｏｔｏｌ−１２−ｔｘｔにそれぞれ記載され、両方ともに参照によってここに組み込まれる。ネットワーク・アドレス・カプセル化によると、コアスイッチにおけるＦＤＢエントリの数は、ＶＭの数とは無関係に、ネットワーク内の（エッジおよびコアを含めて）スイッチの総数まで削減されることがある。たとえば、１エッジスイッチ当たりに約２０台のサーバを用いると、約５０，０００台のサーバのネットワーク内のエッジスイッチの数は、約５０，０００／２０、すなわち、２５００に等しくなることがある。しかし、データパスＭＡＣラーニングを用いると、エッジスイッチ（たとえば、ＤＣ内のＴｏＲスイッチ）のＦＤＢサイズは、ネットワーク・アドレス・カプセル化が使用されないときとほぼ同じになることがあり、これは、実質的に大きくなることがある。

ＴｏＲスイッチで選択的なＭＡＣラーニングを用いる場合でも、ＦＤＢサイズは、依然として実質的に大きくなることがある。たとえば、ＴｏＲスイッチが約４０個のダウンストリームポートを有する場合、１対のＴｏＲスイッチは、ＴｏＲスイッチに接続された最大で約４０台のデュアルホーム型サーバを有することがある。サーバが最大で約１２８台のＶＭをサポートする場合、ＴｏＲスイッチは、正常運転中に、たとえば、ＴｏＲスイッチがほぼ同数のＶＭを取り扱うとき、約１２８×４０／２、すなわち、約２，５６０台のＶＭがＴｏＲに接続されていることがある。１台のＴｏＲスイッチが故障した場合、ＶＭの数は、約５，１２０に増加することがある。個々のＶＭが平均で同時に約１０台のリモートＶＭと通信する場合、ＴｏＲスイッチのＦＤＢサイズ（たとえば、エントリの数）は、約２，５６０（ローカルＶＭ）＋２，５６０×１０（リモートＶＭ）＋２，５００（ＴｏＲスイッチ）、すなわち、約３０，６６０エントリに少なくとも比例することがあり、これは、故障シナリオでは、さらに倍増されることがある。

８０２．１ａｈおよびＴＲＩＬＬにおけるネットワーク・アドレス・カプセル化は、対称性をもつことがある。具体的には、エッジスイッチのような同じスイッチがアドレス・カプセル化を実行することがある。８０２．１ａｈおよびＴＲＩＬにおける対称ネットワーク・アドレス・カプセル化の課題は、エッジスイッチがローカルＶＮと通信するリモートＶＭを把握する必要がある点である。リモートＶＭの数は、実質的に変化することがある。ＰＲＥＳＴＯ０８において公開され、参照によってここに組み込まれる“ＴｏｗａｒｄｓａＮｅｘｔＧｅｎｅｒａｔｉｏｎＤａｔａＣｅｎｔｅｒＡｒｃｈｉｔｅｃｕｔｕｒｅ：ＳｃａｌａｂｉｌｉｔｙａｎｄＣｏｍｍｏｎｄｉｔｉｚａｔｉｏｎ”と題する論文においてＧｒｅｅｎｂｅｒｇ外によって提案された１つのアプローチは、ネットワーク・アドレス・カプセル化手順をＶＭの内側に移動させ、これによって、スイッチＦＤＢサイズをネットワーク内のローカルＶＭの数とエッジスイッチの数との合計に等しくなる（たとえば、上記実施例では、約２，５６０＋２，５００、すなわち、約５，０６０個のエントリに等しくなる）ことがあるこのサイズの最小値に縮小することである。このアプローチの欠点は、ゲスト・オペレーション・システム（ＯＳ）プロトコルスタックの変更である。

その代わりに、ネットワーク・アドレス・カプセル化を物理サーバの仮想スイッチ（たとえば、ハイパーバイザの内側）に移動させることは、さらに後述されるように、エッジスイッチＦＤＢサイズを縮小し、ゲストＯＳプロトコルスタックの変更を回避することがある。このようなネットワーク・アドレス・カプセル化は、アドレス・カプセル化解除が依然としてエッジスイッチ内のどこかで行われるので、ここでは、非対称ネットワーク・アドレス・カプセル化と呼ばれる。この非対称ネットワーク・アドレス・カプセル化のメカニズムは、中間／エッジスイッチまたはルータのＦＤＢ中に維持されるアドレスの量を削減することがある。

非対称ネットワーク・アドレス・カプセル化スキームは、上述された様々なネットワーク実施形態の場合と同様に、エッジスイッチおよびコアスイッチを備えるレイヤ２ネットワークで実施されることがある。たとえば、エッジスイッチは、ＤＣ内のＴｏＲスイッチに対応することがある。個々のエッジスイッチは、一意のＩＤが割り当てられることがあり、これは、（８０２．１ａｈの場合と同様に）ＭＡＣアドレスでもよく、（ＴＲＩＬＬの場合と同様に）約１６ビットのニックネームでもよく、または、ＩＰアドレスでもよい。ネットワークは、入口エッジスイッチから出口エッジスイッチにフレームのヘッダ中で搬送される宛先エッジスイッチＩＤに基づいてフレームを転送するために構成されることがある。フレームは、いずれかのトランスポート技術を使用してネットワークの内側で転送されることがある。非対称ネットワーク・アドレス・カプセル化スキームは、ＭＡＣ−ｉｎ−ＭＡＣとも呼ばれる８０２．１ａｈにおけるアドレス・カプセル化スキームに類似することがある。ＭＡＣラーニングは、ネットワーク内でディセーブル状態にされることがあるが、ポートに対向するエッジ・スイッチ・サーバ上でイネーブル状態にされることがある。サーバ、終端局、およびホストという用語は、ここでは互換的に使用されることがある。仮想サーバ、ＶＭ、仮想終端局、および仮想ホストという用語は、同様にここでは互換的に使用されることがある。

ＭＡＣ−ｉｎ−ＭＡＣでは、エッジスイッチに割り当てられ、ネットワークアドレスまたはバックボーンＭＡＣ（Ｂ−ＭＡＣ）アドレスとも呼ばれるＭＡＣアドレスと、ＶＭによって使用され、顧客ＭＡＣ（Ｃ−ＭＡＣ）アドレスとも呼ばれるＭＡＣアドレスとの２種類のＭＡＣアドレスが存在する。図２３は、ＤＣ内のデュアルホーム型サーバでもよい典型的な物理サーバ２３００の実施形態を例示する。物理サーバ２３００は、仮想スイッチ２３１０と、複数のＶＭ２３４０と、複数の物理ネットワーク・インターフェース・カード（ｐＮＩＣ）２３５０とを備えることがある。仮想スイッチ２３１０は、ＡＲＰプロキシ２３３０およびＦＤＢ２３２０を備えることがあり、このＦＤＢは、ローカルＦＤＢ２３２２およびリモートＦＤＢ２３２４を備えることがある。仮想スイッチ２３１０は、物理サーバ２３００のハイパーバイザの内側に位置することがある。仮想スイッチ２３１０は、ＶＭ２３４０の複数の対応する仮想ネットワーク・インターフェース・カード（ＮＩＣ）２３４２と、仮想スイッチ２３１０の複数の対応する仮想スイッチポート２３１２とを介してＶＭに接続されることがある。仮想スイッチ２３１０は、仮想スイッチ２３１０の複数の対応する仮想スイッチ・トランク・ポート２３１４を介してｐＮＩＣ２３１２にさらに接続されることがある。ｐＮＩＣ２３５０は、仮想スイッチ２３１０のためのアップリンクまたはトランクとしての役目を果たすことがある。物理サーバ２３００は、物理サーバ２３００の対応するｐＮＩＣ２３５０を介して複数のエッジスイッチ２３６０に接続されることがある。このようにして、エッジスイッチ２３６０は、物理サーバ２３００のコンポーネント（ｐＮＩＣ２３５０および仮想スイッチ２３１０）を介してＶＭ２３４０に接続されることがある。物理サーバ２３００のコンポーネントは、図２３に示されるように配置されることがある。

ロードバランシングのため、トラフィックは、仮想ポートＩＤまたはトラフィックのＶＭ送信元Ｃ−ＭＡＣアドレスに基づいてトランク（ｐＮＩＣ２３５０）に分散させられることがある。個々のＶＭ２３４０は、Ｃ−ＭＡＣアドレスが一意に割り当てられた仮想ＮＩＣ２３４２を有することがある。ＶＭ２３４０は、正常運転中にトラフィックをエッジスイッチ２３６０に送信することがある。たとえば、第１のＶＭ２３４０（ＶＭ１）は、対応する第１のエッジスイッチ２３５０（エッジスイッチＸ）を介してネットワーク（図示せず）内の他の物理サーバ内の外部ＶＭに向けられた複数のフレームを送信することがある。第２のエッジスイッチ２３６０（エッジスイッチＲ）は、エッジスイッチＸのためのバックアップでもよい。エッジスイッチＸが故障に起因して到達不可能になるとき（たとえば、対応するｐＮＩＣ２３５０が故障し、ｐＮＩＣ２３５０とエッジスイッチＸとの間のリンクが故障するか、または、エッジスイッチＸが故障するとき）、仮想スイッチ２３１０は、その後、フレームをエッジスイッチＲに送信することがある。

ＦＤＢ２３２０では、ローカルＦＤＢ２３２２は、ローカルＶＭ（ＶＭ２３４０）に対応することがあり、複数のＣ−ＭＡＣ宛先アドレス（Ｃ−ＭＡＣＤＡ）と、複数のＶＬＡＮＩＤと、複数の関連した仮想スイッチポートＩＤとを備えることがある。Ｃ−ＭＡＣＤＡおよびＶＬＡＮＩＤは、対応する仮想スイッチポートＩＤを取得するため、ローカルＦＤＢ２３２２を参照するために使用されることがある。リモートＦＤＢ２３２４は、（他の物理サーバ内の）外部ＶＭに対応することがあり、複数のＢ−ＭＡＣ宛先アドレス（Ｂ−ＭＡＣＤＡ）と、Ｂ−ＭＡＣＤＡに関連付けられた複数のＣ−ＭＡＣＤＡとを備えることがある。Ｃ−ＭＡＣＤＡは、対応するＢ−ＭＡＣＤＡを取得するため、ローカルＶＭによってリモートＦＤＢ２３２４を参照するために使用されることがある。リモートＦＤＢ２３２４は、後述されるように、ＡＲＰプロキシ２３３０によって埋められることがある。

対称アドレス・カプセル化に基づいて、ＶＭ２３４０からのイーサネット（登録商標）フレームは、タグ付き、または、タグ無しになることがある。フレームがタグ無しである場合、対応する仮想スイッチポート２３１２に割り当てられたＶＬＡＮＩＤが使用されることがある。ＶＭ２３４０からエッジスイッチ２３６０へのアップストリーム方向では、仮想スイッチ２３１０は、ＶＭ２３４０からイーサネット（登録商標）フレームを受信した後、以下のステップを実行することがある。
ステップ１：ローカルＦＤＢ２３２２のテーブル参照中にＣ−ＭＡＣＤＡおよびＶＬＡＮＩＤを使用する。一致が見つかった場合、フレームを（仮想スイッチポートＩＤによって）一致したＦＤＢエントリに指定された仮想スイッチポート２３１２に転送する。そうではない場合、ステップ２に進む。
ステップ２：リモートＦＤＢ２３２４のテーブル参照中にＣ−ＭＡＣＤＡを使用する。一致が見つかった場合、ＭＡＣ−ｉｎ−ＭＡＣカプセル化ベースの非対称ネットワーク・アドレス・カプセル化（後述される）を実行し、フレームをフレーム中のＣ−ＭＡＣＳＡと関連付けられた仮想スイッチ・トランク・ポート２３１４に転送する。そうではない場合、ステップ３に進む。
ステップ３：フレームを廃棄し、機能強化ＡＲＰ要求をネットワーク（図示せず）内のＡＲＰサーバに送信する。

図２４は、物理サーバで使用されることがある非対称ネットワーク・アドレス・カプセル化スキーム２４００の実施形態を例示する。非対称ネットワーク・アドレス・カプセル化スキーム２４００に基づいて、ＶＭ２４０２は、アップストリーム方向に、ネットワーク（図示せず）における別の物理サーバ内の別の外部またはリモートＶＭを対象とするフレームを送信することがある。フレームは、リモートＶＭのＣ−ＭＡＣＤＡ（Ｂ）２４１０と、ＶＭ２４０２のＣ−ＭＡＣＳＡ（Ａ）２４１２と、ＶＭ２４０２のＶＬＡＮのＣ−ＶＬＡＮＩＤ２４１４と、データまたはペイロード２４１６と、フレーム・チェック・シーケンス（ＦＣＳ）２４１８とを備えることがある。ＶＭ２４０２は、フレームを仮想スイッチ２４０４に送信することがある。

（同じ物理サーバ内の）仮想スイッチ２４０４は、ＶＭ２４０２からフレームを受信することがある。仮想スイッチ２４０４は、ＭＡＣ−ｉｎ−ＭＡＣフレームを取得するために、フレームを処理し、ヘッダをフレームに付加することがある。ヘッダは、Ｂ−ＭＡＣＤＡ（Ｙ）２４２０と、Ｂ−ＭＡＣＳＡ（０）２４２２と、Ｂ−ＶＬＡＮＩＤ２４２４と、インスタンス・サービスＩＤ（Ｉ−ＳＩＤ）２４２６とを備えることがある。Ｂ−ＭＡＣアドレス（Ｙ）は、エッジスイッチ２４０６内のＣ−ＭＡＣＤＡ（Ｂ）２４１０と関連付けられることがある。Ｂ−ＭＡＣアドレス（Ｙ）は、Ｃ−ＭＡＣアドレス（Ｂ）を有するリモートＶＭのロケーションを指示することがある。Ｂ−ＭＡＣＳＡ２４２２は、仮想スイッチ２４０４によってゼロにセットされることがある。Ｂ−ＶＬＡＮＩＤ２４２４は、Ｃ−ＶＬＡＮＩＤ２４１４にセットされることがある。Ｉ−ＳＩＤ２４１６は、選択自由であり、イーサネット（登録商標）フレームがＣ−ＭＡＣＤＡ（Ｂ）だけに送信された場合、ヘッダ内で使用されないことがある。仮想スイッチ２４０４は、その後、ＭＡＣ−ｉｎ−ＭＡＣフレームをエッジスイッチ２４０６に送信することがある。

（物理サーバに接続された）エッジスイッチ２４０６は、仮想スイッチ２４０４からＭＡＣ−ｉｎ−ＭＡＣフレームを受信することがある。エッジスイッチ２４０６は、ＭＡＣ−ｉｎ−ＭＡＣフレーム中の新ヘッダを取得するために、ＭＡＣ−ｉｎ−ＭＡＣフレームのヘッダを処理することがある。新ヘッダは、Ｂ−ＭＡＣＤＡ（Ｙ）２４４０と、Ｂ−ＭＡＣＳＡ（Ｘ）２４４２と、Ｂ−ＶＬＡＮＩＤ２４４４と、Ｉ−ＳＩＤ２４４６とを備えることがある。Ｂ−ＭＡＣＳＡ（Ｘ）２４４２は、エッジスイッチ２４０６のＢ−ＭＡＣアドレス（Ｘ）にセットされることがある。Ｂ−ＶＬＡＮＩＤ２４４４は、ネットワーク内のＶＬＡＮを一致させるために、必要に応じて、変更されることがある。ヘッダの残りのフィールドは、変更されないことがある。エッジスイッチ２４０６は、その後、ネットワークコア２４０８、たとえば、コアネットワークまたはネットワークコア区域を介して、Ｂ−ＭＡＣＤＡ（Ｙ）２４４２、および、おそらくＢ−ＶＡＮＩＤ２４４４に基づいて新ＭＡＣ−ｉｎ−ＭＡＣフレームを転送することがある。

ダウンストリーム方向では、エッジスイッチ２４０６は、ネットワークコア２４０８からＭＡＣ−ｉｎ−ＭＡＣフレームを受信し、フレーム・カプセル化解除を実行することがある。ＭＡＣ−ｉｎ−ＭＡＣフレームは、ヘッダと、リモートＶＭからＶＭ２４０２に送信された元のフレームとを備えることがある。ヘッダは、エッジスイッチ２４０６のＢ−ＭＡＣＤＡ（Ｘ）２４６０と、リモートＶＭおよびエッジスイッチ２４０６に対応するＢ−ＭＡＣＳＡ（Ｙ）２４６２と、リモートＶＭのＶＬＡＮのＢ−ＶＬＡＮＩＤ２４６４と、Ｉ−ＳＩＤ２４６６とを備えることがある。リモートＶＭの元のフレームは、ＶＭ２４０２のＣ−ＭＡＣＤＡ（Ａ）２４７０と、リモートＶＭのＣ−ＭＡＣＳＡ（Ｂ）２４７２と、ＶＭ２４０２に関連付けられたＣ−ＶＬＡＮＩＤ２４７４と、データまたはペイロード２４７６と、ＦＣＳ２４７８とを備えることがある。エッジスイッチ２４０６は、ＭＡＣ−ｉｎ−ＭＡＣフレームからヘッダを取り外し、残りの元のフレームを仮想スイッチ２４０４に転送することがある。エッジスイッチ２４０６は、出力スイッチポートＩＤを取得し、対応するスイッチポートに対向するか、または、接続された外部の物理サーバへ元のフレームを転送するために、Ｃ−ＭＡＣＤＡ（Ａ）２４７０およびＣ−ＶＬＡＮＩＤ２４７４を使用してこれの転送テーブルを参照することがある。次に、仮想スイッチ２４０４は、元のフレームをＶＭ２４０２に転送することがある。仮想スイッチ２４０４は、Ｃ−ＭＡＣＤＡ（Ａ）２４７０およびＣ−ＶＬＡＮＩＤ２４７４に基づいて元のフレームをＶＭ２４０２に転送することがある。

エッジスイッチ２４０６内の転送テーブルは、ローカルＦＤＢおよびリモートＦＤＢを含むことがある。ローカルＦＤＢは、ローカルＶＭのためのフレームを転送するため使用されることがあり、ＭＡＣラーニングを介して埋められ、受信されたフレーム中のＣ−ＭＡＣＤＡおよびＣ−ＶＬＡＮＩＤによってインデックス付けされることがある。リモートＦＤＢは、フレームをリモートＶＭに転送するため使用されることがあり、ルーティングプロトコルまたは集中型制御／管理プレーンによって埋められ、受信されたフレーム中のＢ−ＭＡＣＤＡとおそらくＢ−ＶＬＡＮＩＤとによってインデックス付けされることがある。

非対称アドレス・カプセル化スキーム２４００では、ＭＡＣ−ｉｎ−ＭＡＣカプセル化は、仮想スイッチ２４０４で実行されることがあり、一方、ＭＡＣ−ｉｎ−ＭＡＣカプセル化解除は、エッジスイッチ２４０６で実行されることがある。したがって、エッジスイッチ内のＦＤＢサイズは、実質的に縮小され、たとえば、メガＤＣ内の実質的に大きいレイヤ２ネットワークの場合でさえより管理しやすくなる。仮想スイッチ２４０４内のリモートＦＤＢサイズは、ローカルＶＭ、たとえば、ＶＭ２４０２と通信するリモートＶＭの数に依存することがある。たとえば、仮想スイッチが約１２８台のローカルＶＭをサポートし、個々のローカルＶＭが平均で同時に約１０台のリモートＶＭと通信する場合、リモートＦＤＢは、およそ１２８×１０、すなわち、およそ１，２８９のエントリを備えることがある。

図２５は、物理サーバ２３００で使用されることがあるＡＲＰ処理スキーム２５００の実施形態を例示する。ＡＲＰ処理スキーム２５００に基づいて、ＶＭ２５０２は、リモートＶＭのためのＡＲＰ要求をブロードキャストすることがある。ＡＲＰ要求は、ブロードキャストメッセージを指示するＣ−ＭＡＣＤＡ（ＢＣ）２５１０と、ＶＭ２５０２のＣ−ＭＡＣＳＡ（Ａ）２５１２と、ＶＭ２５０２のＶＬＡＮのＣ−ＶＬＡＮＩＤ２５１４と、ＡＲＰペイロード２５１６と、ＦＣＳ２５１８とを備えることがある。

ローカルＶＭからのすべてのＡＲＰメッセージをインターセプトするために構成されることがある（同じ物理サーバ内の）仮想スイッチ２５０４は、リモートＶＭのためのＡＲＰ要求をインターセプトすることがある。仮想スイッチ２５０４内のＡＲＰプロキシは、ユニキャスト拡張ＡＲＰ（ＥＲＡＰ）メッセージを取得するために、ＡＲＰ要求を処理し、フレームにヘッダを付加することがある。フレームは、たとえば、非対称ネットワーク・アドレス・カプセル化スキーム２４００に類似するＭＡＣ−ｉｎ−ＭＡＣを使用してカプセル化されることがある。ヘッダは、Ｂ−ＭＡＣＤＡ２５２０と、Ｂ−ＭＡＣＳＡ（０）２５２２と、Ｂ−ＶＬＡＮＩＤ２５２４と、Ｉ−ＳＩＤ２５２６とを備えることがある。Ｂ−ＭＡＣＤＡ２５２０は、ネットワーク内のＡＲＰサーバ２５０８と関連付けられることがある。Ｂ−ＶＬＡＮＩＤ２５２４は、Ｃ−ＶＬＡＮＩＤ２５１４にセットされることがある。Ｉ−ＳＩＤ２５２６は、選択自由でもよく、使用されなくてもよい。ＥＡＲＰメッセージは、Ｃ−ＭＡＣＤＡ（Ｚ）２５２８と、Ｃ−ＭＡＣＳＡ（Ａ）２５３０と、Ｃ−ＶＬＡＮＩＤ２５３２と、ＥＡＲＰペイロード２５３４と、ＦＣＳ２５３６とをさらに備えることがある。ＡＲＰプロキシは、受信されたフレーム中のＣ−ＭＡＣＤＡ（ＢＣ）２５１０およびＡＲＰペイロード２５１６をＥＡＲＰメッセージ中のリモートＶＭのＣ−ＭＡＣＤＡ（Ｚ）２５２８およびＥＡＲＰペイロード２５３４でそれぞれ置換することがある。仮想スイッチ２５０４は、その後、ＥＡＲＰメッセージをエッジスイッチ２５０６に送信することがある。

エッジスイッチ２５０６は、新ヘッダを取得するためにＥＡＲＰメッセージ中のヘッダを処理することがある。新ヘッダは、Ｂ−ＭＡＣＤＡ（Ｙ）２５４０と、Ｂ−ＭＡＣＳＡ（Ｘ）２５４２と、Ｂ−ＶＬＡＮＩＤ２５４４と、Ｉ−ＳＩＤ２５４６とを備えることがある。Ｂ−ＭＡＣＳＡ（Ｘ）２５４２は、エッジスイッチ２５０６のＢ−ＭＡＣアドレス（Ｘ）にセットされることがある。Ｂ−ＶＬＡＮＩＤ２５４４は、ネットワーク内のＶＬＡＮに一致させるために、必要に応じて、変更されることがある。ヘッダの残りのフィールドは、変更されなくてもよい。エッジスイッチ２５０６は、その後、新ＥＡＲＰメッセージをネットワーク内のＡＲＰサーバ２５０８に転送することがある。

ＡＲＰサーバ２５０８は、受信されたＥＡＲＰメッセージを処理し、ＥＡＲＰ応答をエッジスイッチ２５０６に返送することがある。ＥＡＲＰ応答は、ヘッダおよびＡＲＰフレームを備えることがある。ヘッダは、エッジスイッチ２５０６のＢ−ＭＣＤＡ（Ｘ）２５６０と、ＡＲＰサーバ２５０８のＢ−ＭＡＳＳＡ２５６２と、Ｂ−ＶＬＡＮＩＤ２５６４と、Ｉ−ＳＩＤ２５６６とを備えることがある。ＡＲＰフレームは、ＶＭ２５０２のＣ−ＭＡＣＤＡ（Ａ）２５６８と、要求先リモートＶＭのＣ−ＭＡＣＳＡ（Ｚ）２５７０と、Ｃ−ＶＬＡＮＩＤ２５７２と、ＥＡＲＰペイロード２５７４と、ＦＣＳ２５７６とを備えることがある。エッジスイッチ２５０６は、ヘッダを取り外すことによりＥＡＲＰメッセージをカプセル化解除し、その後、ＡＲＰフレームを仮想スイッチ２５０４に転送することがある。仮想スイッチ２５０４は、ＡＲＰフレームを処理し、その結果、ＡＲＰ応答をＶＭ２５０２に送信することがある。ＡＲＰ応答は、ＶＭ２５０２のＣ−ＭＡＣＤＡ（Ａ）２５９０と、リモートＶＭのロケーションと関連付けられたＣ−ＭＡＣＳＡ（Ｂ）２５９２と、Ｃ−ＶＬＡＮＩＤ２５９４と、ＡＰＲペイロード２５９６と、ＦＣＳ２５９８とを備えることがある。

仮想スイッチ２５０４内のＡＲＰプロキシは、エッジスイッチ２５０６内のリモートＦＤＢをポピュレートするためにＥＡＲＰメッセージをさらに使用することがある。ＡＲＰプロキシは、ＥＡＲＰペイロード２５７４中で見つけられることがあるリモートＣ−ＭＡＣおよびリモートスイッチＢ−ＭＡＣのペアを使ってＦＤＢテーブル中のエントリをポピュレートすることがある。Ｃ−ＭＡＣおよびリモートスイッチＢ−ＭＡＣは、ＥＡＲＰペイロード２５７４中の送信元ハードウェア・アドレス（ＳＨＡ）フィールドおよび送信元ロケーション・アドレス（ＳＬＡ）フィールドでそれぞれ見つけられることがある。

仮想スイッチ２５０４を備える物理サーバ内のハイパーバイザは、ＶＭ、たとえば、ローカルＶＭ２５０２またはリモートＶＭをＡＲＰ処理スキーム２５００と同様にＡＲＰサーバ２５０８にさらに登録することがある。この場合、仮想スイッチ２５０４は、すべてのターゲットフィールドに等しいすべての送信元フィールドをもつユニキャストＥＡＲＰフレームをＡＲＰサーバ２５０８に送信することがある。ＶＭを登録する別の方法は、Ｙ．Ｘｉｏｎｇ外による“ＡＭＡＣＡｄｄｒｅｓｓＤｅｌｅｇａｔｉｏｎＳｃｈｅｍｅｆｏｒＳｃａｌａｂｌｅＥｔｈｅｒｎｅｔＮｅｔｗｏｒｋｓｗｉｔｈＤｕｐｌｉｃａｔｅｄＨｏｓｔＩＰＡｄｒｅｓｓｅｓ”と題する米国仮特許出願第６１／３８９，７４７号に記載され、この米国仮出願は、これらの全体がそのまま再現されたかのように参照によってここに組み込まれる。このスキームは重複ＩＰアドレスシナリオを取り扱うことがある。

図２６は、ＥＡＲＰペイロード２５７４のようなＡＲＰ処理スキーム２５００で使用されることがあるＥＡＲＰペイロード２６００の実施形態を例示する。ＥＡＲＰペイロード２６００は、ハードウェア・タイプ（ＨＴＹＰＥ）２６１０と、プロトコル・タイプ（ＰＴＹＰＥ）２６１２と、ハードウェア・アドレス長（ＨＬＥＮ）２６１４と、プロトコル・アドレス長（ＰＬＥＮ）２６１６と、オペレーションフィールド（ＯＰＥＲ）２６１８と、ＳＨＡ２６２０と、送信元プロトコル・アドレス（ＳＰＡ）２６２２と、ターゲット・ハードウェア・アドレス（ＴＨＡ）２６２４と、ターゲット・プロトコル・アドレス（ＴＰＡ）２６２６とを備えることがあり、これらは、典型的なＡＲＰメッセージの要素になることがある。付加的には、ＥＡＲＰペイロード２６００は、ＳＬＡ２６２８と、ターゲット・ロケーション・アドレス（ＴＬＡ）２６３０とを備えることがある。図６は、ＥＡＲＰペイロード２６００の各フィールドのためのビットオフセットをさらに示し、このビットオフセットは、ビット単位で各フィールドのサイズをさらに指示する。

ＡＲＰサーバ（たとえば、ＡＲＰサーバ２５０８）を使用し、ネットワーク内のＭＡＣラーニングをディセーブル状態にすることの１つの問題は、ＡＲＰサーバをエッジスイッチに接続するエッジスイッチまたはリンクの故障に起因してＶＭが到達不可能になるケースである。このケースでは、仮想スイッチがＶＭのための新エッジスイッチまたは置換エッジスイッチの新ロケーションを知るためにある程度時間を要することがある。たとえば、物理サーバ２３００内のエッジスイッチＸが到達不可能になる場合、仮想スイッチ２３１０は、フレームをＶＭ１からエッジスイッチＲに転送することがあり、このフレームは、ＶＭ１のための新ロケーションになることがある。

ＶＭの新ロケーションに関して仮想スイッチ２３１０内のリモートＦＤＢを更新する時間を短縮するために、無償ＥＡＲＰメッセージが使用されることがある。仮想スイッチ２３１０は、ブロードキャスト・アドレス（ＢＣ）にセットされたＢ−ＭＡＣＤＡを含むＭＡＣ−ｉｎ−ＭＡＣカプセル化フレーム中で無償ＥＡＲＰメッセージをエッジスイッチＲに最初に送信することがある。無償ＥＡＲＰメッセージ中で、ＳＨＡ（たとえば、ＳＨＡ２６２０）は、ＴＨＡ（たとえば、ＴＨＡ２６２４）に等しくセットされることがあり、ＳＰＡ（たとえば、ＳＰＡ２６２２）は、ＴＰＡ（たとえば、ＴＰＡ２６２６）に等しくセットされることがあり、ＳＬＡ（たとえば、ＳＬＡ２６２８）は、ＴＬＡ（たとえば、ＴＬＡ２６３０）に等しくセットされることがある。エッジスイッチＲは、その後、たとえば、ディストリビューション・ツリーを介して、無償ＥＡＲＰメッセージをネットワーク内の複数または全部の他のエッジスイッチに送信することがある。エッジスイッチが無償ＥＡＲＰメッセージを受信するとき、エッジスイッチは、メッセージをカプセル化解除し、ポートに対向するエッジスイッチのサーバへメッセージを送出することがある。仮想スイッチがその後に無償ＥＡＲＰメッセージを受信するとき、仮想スイッチは、ＳＨＡがリモートＦＤＢ内に既に存在する場合、この仮想スイッチのリモートＦＤＢを更新することがある。ネットワーク内のＡＲＰサーバは、影響を受けたＶＭの新ロケーションを同じように更新することがある

上述の非対称ネットワーク・アドレス・カプセル化スキームは、一実施形態では、ＭＡＣ−ｉｎ−ＭＡＣカプセル化を使用することがある。代替的には、このスキームは、他のカプセル化方法に拡張されることがある。ＴＲＩＬＬがサポートされ、ネットワーク内で使用され、エッジスイッチが約１６ビットのニックネームによって識別される場合、ＴＲＩＬＬカプセル化が非対称ネットワーク・アドレス・カプセル化スキームで使用されることがある。代替的には、エッジスイッチがＩＰアドレスによって識別される場合、ＩＰ−ｉｎ−ＩＰカプセル化が使用されることがある。さらに、ネットワーク・アドレス・カプセル化は、仮想スイッチレベルで実行されることがあり、ネットワーク・アドレス・カプセル化解除は、エッジスイッチレベルで実行されることがある。一般に、ネットワーク・アドレス・カプセル化スキームは、カプセル化とカプセル化解除とが異なるレベルまたはコンポーネントで持続される限り、どのレベルで、または、いずれのネットワークコンポーネントに適用されてもよい。

相互接続型ネットワーク区域１８００の場合のように、区域に区分されているブリッジ型ネットワークでは、ＤＢＢは、複数の区域に参加しているブリッジでもよい。ＤＢＢのアドレスは、ＤＢＢのアドレスと個々の区域内のＶＭのＣ−ＭＡＣアドレスを区別するために、ここでは、ネットワークアドレスと呼ばれることがある。上記非対称アドレス・カプセル化スキームを使用して、ネットワークアドレスのカプセル化は、ホストにより接近したスイッチ、または、仮想ホストにより接近した仮想スイッチで行われることがある。たとえば、ＴｏＲスイッチのような中間スイッチ１８２４は、ネットワーク・アドレス・カプセル化を実行することがある。中間スイッチ１８２４は、ホストの部分集合から到来し、ターゲットＤＢＢアドレスを備えるデータフレームをカプセル化することがある。しかし、中間スイッチ１８２４は、ネットワーク側、たとえば、コア区域１８１０内のＤＢＢ１８２２からの入力データフレームを変更しないことがある。中間スイッチ１８２４より１レベル上にあるターゲットＤＢＢ１８２２は、ネットワーク側（コア区域１８１０）からのデータフレームをカプセル化解除し、カプセル化解除されたデータフレームをこの区域内のホストへ向けて転送することがある。

実施形態では、物理サーバ（たとえば、終端局１８２６）の内部の仮想スイッチは、ネットワーク・アドレス・カプセル化を実行することがあり、一方、ターゲットＤＢＢ１８２２は、ネットワーク・アドレス・カプセル化解除を実行することがある。この場合、カプセル化解除を実行するＤＢＢ１８２２は、カプセル化を実行する（終端局１８２６内の）仮想スイッチより２レベル上にあることがある。

ＤＢＢ１８２２に接続されたブリッジ型ネットワーク（たとえば、コア区域１８１０）は、ＩＰベースになることがある。ＤＢＢを相互接続するコアネットワーク（または区域）は、Ｌ３仮想プライベート・ネットワーク（ＶＰＮ）、Ｌ２ＶＰＮ、または標準的なＩＰネットワークになることがある。このようなシナリオでは、ＤＢＢは、このＤＢＢのローカル区域からのＭＡＣデータフレームを適切なターゲットＤＢＢアドレスを使ってカプセル化することがあり、ターゲットＤＢＢアドレスは、ＩＰヘッダでもＭＰＬＳヘッダでもよい。

図２７は、相互接続型ネットワーク区域１８００の場合のようなレイヤ２ブリッジ型ネットワークおいて使用されることがあるデータフレーム転送スキーム２７００の実施形態を例示する。データフレーム転送スキーム２７００は、上記非対称ネットワーク・アドレス・カプセル化スキームをさらに実施することがある。レイヤ２ブリッジ型ネットワークは、コア区域２７１０と、コア区域２７１０に接続された複数のＤＢＢ２７２２または複数の区域２７２０内の区域境界スイッチと、これらの区域２７２０内の対応するＤＢＢ２０２２に接続された複数の中間またはエッジスイッチ２７２４および物理サーバ２７２６とを備えることがある。物理サーバ２７２６は、複数のＶＭおよび仮想スイッチ（図示せず）を備えることがある。ＤＢＢ２７２２と、中間／エッジスイッチ２７２４と、区域２７２０を越える物理サーバ２７２６とのうちの一部は、レイヤ２ブリッジ型ネットワーク内に確立され、ＶＬＡＮＩＤと関連付けられたＶＬＡＮに属することがある。レイヤ２ブリッジ型ネットワークのコンポーネントは、図２７に示されるように配置されることがある。

非対称ネットワーク・アドレス・カプセル化スキームによれば、中間／エッジスイッチ２７２４は、第１の区域（区域１）における物理サーバ２７２６内の第１のＶＭ（ホストＡ）からフレーム２７４０、たとえば、イーサネット（登録商標）フレームを受信することがある。フレーム２０４０は、第２の区域（区域２）における第２の物理サーバ２７２６内の第２のＶＭ（ホストＢ）を対象とすることがある。フレーム２０４０は、区域２内の第２のＤＢＢのＢ−ＭＡＣＤＡ２７４２（ＤＢＢ２）と、ホストＡのＢ−ＭＡＣＳＡ２７４４（ＴｏＲＡ）と、ホストＢのＣ−ＭＡＣＤＡ２７４６（Ｂ）と、ホストＡのＣ−ＭＡＣＳＡ２７４８（Ａ）と、ホストＡのＩＰ−ＳＡ２７５０（Ａ）と、ホストＢのＩＰ−ＤＡ２７５２（Ｂ）と、ペイロードとを備えることがある。中間／エッジスイッチ２７２４は、フレーム２０４０を区域１内の第１のＤＢＢ２７２２（ＤＢＢ１）に転送することがある。ＤＢＢ１は、内部フレーム２７６０を取得するためにフレーム２７４０を受信し、処理することがある。内部フレーム２７６０は、ＤＢＢ２のＢ−ＭＡＣＤＡ２７６２と、ＤＢＢ１のＢ−ＭＡＣＳＡ２７６４と、ホストＢのＣ−ＭＡＣＤＡ２７６６（Ｂ）と、ホストＡのＣ−ＭＡＣＳＡ２７６８（Ａ）と、ホストＡのＩＰ−ＳＡ２７７０（Ａ）と、ホストＢのＩＰ−ＤＡ２７５２（Ｂ）と、ペイロードとを備えることがある。ＤＢＢ１は、その後、コア区域２７１０を介して内部フレーム２７６０を区域２に転送することがある。

区域２内のＤＢＢ２は、第２のフレーム２７８０を取得するためにインターフレーム２７４０を受信し、カプセル化解除することがある。ＤＢＢ２は、第２のフレーム２７８０を取得するために、内部フレーム２７６０からＤＢＢ２のＢ−ＭＡＣＤＡ２７６２とＢ−ＭＡＣＳＡ２７６４とを取り外すことがある。このようにして、第２のフレーム２７８０は、ホストＢのＣ−ＭＡＣＤＡ２７８２（Ｂ）と、ホストＡのＣ−ＭＡＣＳＡ２７８４（Ａ）と、ホストＡのＩＰ−ＳＡ２７８６（Ａ）と、ホストＢのＩＰ−ＤＡ２７８８（Ｂ）と、ペイロードとを備えることがある。ＤＢＢ２は、第２のフレーム２７８０を区域２内のホストＢに送信することがある。

データフレーム転送スキーム２７００では、中間／エッジスイッチ２７２４は、中間／エッジスイッチ２７２４に接続されたローカル物理サーバ２７２４から受信されたフレームのためのＭＡＣ−ｉｎ−ＭＡＣ機能を実行しないことがある。別の実施形態では、第１のフレーム２７４０のカプセル化手順は、中間／エッジスイッチ２７２４ではなく、物理サーバ２７２６内の仮想スイッチによって実行されることがあり、このことは、第１のフレーム２７４０を処理することなく物理サーバ２７２６から対応するＤＢＢ２７２２に転送することがある。

図２８は、相互接続型ネットワーク区域１８００の場合のようなレイヤ２ブリッジ型ネットワークおいて使用されることがある機能強化ＡＲＰ処理方法２８００の実施形態を例示する。機能強化ＡＲＰ処理方法２９００は、ステップ２８０１から始まることがあり、このステップで、ローカルホスト２８１０は、第１のブリッジ２８２０、たとえば、ローカルＤＢＢを介して、ＡＲＰ要求をローカルロケーション２８３０に送信することがある。ローカルロケーション２８３０は、ローカルホスト２８１０と同じロケーションまたは区域に対応することがある。ＡＲＰ要求は、リモートホスト２８６０と関連付けられたＭＡＣアドレスを取得するために送信されることがある。ローカルホスト２８１０は、ＩＰアドレスＩＰＡとＭＡＣアドレスＡとが割り当てられることがある。リモートホスト２８６０は、ＩＰアドレスＩＰＢとＭＡＣアドレスＢとが割り当てられることがある。ＡＲＰ要求は、ローカルホスト２８１０のＳＡＭＡＣアドレスＡおよびＳＡＩＰアドレスＩＰＡを備えることがある。ＡＲＰ要求は、リモートホスト２８６０のゼロにセットされたＤＡＭＡＣアドレスおよびＤＡＩＰアドレスＩＰＢをさらに備えることがある。ローカルロケーション２８３０は、ＡＲＰ要求をネットワーク内のＡＲＰサーバ２８４０に転送することがある。

ステップ２８０２で、ＡＲＰサーバ２８４０は、ＥＡＲＰ応答を第１のブリッジ２８２０に送信することがある。ＥＡＲＰ応答は、ローカルホスト２８１０のＳＡＭＡＣアドレスＡおよびＳＡＩＰアドレスＩＰＡと、リモートホスト２８６０のＤＡＭＡＣアドレスＢおよびＤＡＩＰアドレスＩＰＢと、リモートホスト２８６０のリモートロケーション２８５０内の第２のブリッジのＭＡＣアドレスとを備えることがある。ステップ２８０３で、第１のブリッジ２８２０は、ＥＡＲＰ応答を処理／カプセル化解除し、ＡＲＰ応答をローカルホスト２８１０に送信することがある。ＡＲＰ応答は、ローカルホスト２８１０のＭＡＣアドレスＡおよびＩＰアドレスＩＰＡと、リモートホスト２８６０のＭＡＣアドレスＢおよびＩＰアドレスＩＰＢとを備えることがある。このようにして、ローカルホスト２８１０は、リモートホスト２８６０のＭＡＣアドレスＢを知ることになることがある。第１のブリッジ２８２０は、（ローカルテーブル内で）リモートロケーション２８５０内のリモートブリッジのＭＡＣアドレスＹをリモートホスト２８６０のＩＰアドレスＩＰＢとさらに関連付けることがある。第１のブリッジ２８２０は、リモートホスト２８６０のＭＡＣアドレスＢを記憶する必要がないことがある。

ステップ２８０４で、ローカルホスト２８１０は、リモートホスト２８６０を対象とするデータフレームを第１のブリッジ２８２０に送信することがある。データフレームは、ローカルホスト２８１０のＳＡＭＡＣアドレスおよびＳＡＩＰアドレスと、リモートホスト２８６０のＤＡＭＡＣアドレスおよびＤＡＩＰアドレスを備えることがある。ステップ２８０５で、第１のブリッジ２８２０は、内部フレームを取得するために、データフレームを受信し、処理／カプセル化することがある。内部フレームは、第１のブリッジ２８２０のＳＡＭＡＣアドレスＸと、リモートブリッジのＤＡＭＡＣアドレスＹと、リモートホスト２８６０のＤＡＭＡＣアドレスＢおよびＤＡＩＰアドレスＩＰＢと、ローカルホスト２８１０のＳＡＭＡＣアドレスＡおよびＳＡＩＰアドレスＩＰＡとを備えることがある。ステップ２８０６で、リモートロケーション２８５０内のリモートブリッジは、内部フレームを受信し、第１のブリッジ２８２０のＳＡＭＡＣアドレスＸおよびリモートブリッジのＤＡＭＡＣアドレスＹを取り外すことにより第２のフレームを取得するために内部フレームを処理／カプセル化解除することがある。このようにして、第２のフレームは、ローカルホスト２８１０から送信された初期フレームに類似することがある。リモートブリッジは、その後、第２のフレームをリモートホスト２８６０に送信することがある。この方法２８００は、その後、終了することがある。

機能強化ＡＰＲ処理方法２８００では、コアネットワークは、トポロジ・ディスカバリのため８０２．１ａｑまたはＴＲＩＬＬを使用することがある。コアネットワークがトポロジ・ディスカバリのため８０２．１ａｑを使用する場合、第１のブリッジ２８２０は、ローカルホスト２８１０から送信されたフレームをカプセル化しないことがあり、処理無しでフレームをリモートロケーション２８５０に転送することがある。さらに、コアネットワークを介して転送されたフレームは、第２のロケーション２８５０だけで、フレーム中で指示されたアウトバウンドポートが知られていないときに限りフラッディングされることがある。

実施形態では、拡張アドレス解決・スキームは、ＴＲＩＬＬエッジノード、ＭＡＣ−ｉｎ−ＭＡＣエッジノード、または、他のタイプのオーバーレイ・ネットワーク・エッジノードでもよい区域ゲートウェイまたはゲートウェイノードによって実施されることがある。拡張アドレス解決・スキームは、ＡＲＰプロキシスキーム１９００のように、レイヤ２ブリッジ型ネットワークにおける複数の区域内のＤＢＢによって実施されたＡＲＰプロキシスキームに基づくことがある。たとえば、複数の物理サーバおよび／またはＶＭに接続されることがある中間／エッジノード２７２４は、上述のＡＲＰプロキシスキームに類似する拡張アドレス解決・スキームを実施することがある。ゲートウェイノードは、ターゲット宛先（たとえば、ホスト）と出口エッジノードとの間のマッピングを分解するためにＡＲＰプロキシスキームにおけるＤＳサーバを使用することがある。出口エッジノードは、ターゲット区域ゲートウェイ、ＴＲＩＬＬ出口ノード、ＭＡＣ−ｉｎ−ＭＡＣエッジノード、または、任意の他のタイプのオーバーレイ・ネットワーク・エッジノードでもよい。ＤＳからの応答は、上述のとおりのＥＡＲＰ応答でもよい。

拡張アドレス解決・スキームは、かなりの数のホストを使ってＤＣネットワークをスケーリングするために使用されることがある。オーバーレイ・ネットワーク（たとえば、ブリッジ型ネットワーク）は、ＭＡＣ−ｉｎ−ＭＡＣ、ＴＲＩＬＬ、または、他のタイプのレイヤ３もしくはレイヤ２・オーバー・イーサネット（登録商標）・ネットワークでもよい。オーバーレイ・ネットワークエッジは、アクセススイッチ（またはＴｏＲスイッチ）またはアグリゲーションスイッチ（またはＥｏＲスイッチ）のようなネットワークスイッチでもよい。オーバーレイ・ネットワークエッジは、サーバ内の仮想スイッチにさらに対応することがある。拡張アドレス解決・スキームを使用するオーバーレイ・ネットワークのための２つのシナリオが存在することがある。第１のシナリオは、ＴＲＩＬＬまたはＭＡＣ−ｉｎ−ＭＡＣネットワークの場合のような対称スキームに対応する。このシナリオでは、オーバーレイ・エッジノードは、カプセル化部分とカプセル化解除部分との両方を実行することがある。第２のシナリオは、オーバーレイ・ネットワークが上記非対称ネットワーク・アドレス・カプセル化スキームを実施することがある非対称スキームに対応する。

図２９は、オーバーレイ・ネットワークにおいて実施されることがある拡張アドレス解決方法２９００の実施形態を例示する。拡張アドレス解決方法２９００は、第１のＶＭ２９１０（ＶＭＡ）が第２のＶＭ２９８０（ＶＭＢ）のためアドレス指定されたフレームまたはパケットを第１のゲートウェイまたはハイパーバイザ（ＨＶ）２９２０（ＨＶＡ）に送信することがあるステップ２９０１から始まる。ＶＭＡおよびＶＭＢは、異なる区域内のエンドホストでもよい。ＶＭＡは、第１の区域においてＨＶＡに接続されることがあり、ＶＭＢは、第２の区域において第２のゲートウェイスイッチまたはＨＶ２９７０（ＨＶＢ）に接続されることがある。ＨＶは、データフレームまたはパケット上でオーバーレイ・ネットワーク・アドレス・ヘッダをカプセル化または追加するために構成されたオーバーレイ・ネットワーク・ノードでもよい。対称スキームシナリオでは、ＨＶは、ＤＢＢ、ＴＲＩＬＬエッジノード、またはＭＡＣ−ｉｎ−ＭＡＣエッジノードになることがある。非対称スキームシナリオでは、ＨＶは、ハイパーバイザ内部の仮想スイッチ、ゲートウェイスイッチ、またはアクセススイッチになることがある。

ステップ２９０２で、ＨＶＡは、ＶＭＢＩＰアドレスからＶＭＢＭＡＣアドレス、そして、対称スキームの場合、ＨＶＢＭＡＣアドレスペアへのマッピングを取り出すためにアドレス解決（ＡＲ）要求をＡＲＰサーバ２９３０に送信することがある。ＡＲＰサーバは、ＤＳ１９４０のようなＤＳサーバを備えるか、または、ＤＳサーバに対応することがある。非対称スキームでは、マッピングは、ＶＭＢＩＰアドレスからＶＭＢＭＡＣアドレス、および、第２のＤＢＢ２９６０（ＤＢＢＢ）ＭＡＣアドレスペアへのマッピングになることがある。ＤＢＢＢは、ＶＭＢの同じ区域内のリモートＤＢＢでもよい。

ＨＶＡは、ローカルＶＭからの（ブロードキャストされた）ＡＲＰ要求をインターセプトし、ＡＲＰ要求をＤＳサーバに転送するためにさらに構成されることがある。ＨＶＡは、その後、ＤＳサーバからＥＡＲＰ応答を取り出し、（ＥＡＲＰ応答によって指示されるように）ターゲットアドレスとターゲット・ゲートウェイ・アドレスとの間のマッピングをキャッシュすることがある。ターゲット・ゲートウェイ・アドレスは、ここでは、ターゲット・ロケーション・アドレスと呼ばれることもある。別の実施形態では、ＨＶＡによってＡＲＰ要求をインターセプトする代わりに、ＤＳサーバは、定期的もしくは周期的に、または、ＶＭが区域の間で移動または移るときに連結マッピング情報をＨＶＡに送信することがある。連結マッピング情報は、上述の仮想レイヤ２ネットワーク内のＬ２ＧＷと交換された同じ情報を備えることがある。たとえば、連結マッピング情報は、上述のとおり、無償グループアナウンスメントとしてフォーマット化されることがある。

ステップ２９０３で、ＨＶＡは、対称スキームの場合、（ＳＡ：ＶＭＡＭＡＣ、ＤＡ：ＶＭＢＭＡＣ）を備える内部・アドレス・ヘッダと、（ＳＡ：ＨＶＡＭＡＣ、ＤＡ：ＨＶＢＭＡＣ）を備える外部ヘッダとを作成することがある。非対称スキームでは、外部ヘッダは、（ＳＡ：ＨＶＡＭＡＣ、ＤＡ：ＤＢＢＢＭＡＣ）を備えることがある。ＨＶＡは、内部ヘッダおよび外部ヘッダをＶＭＡから受信されたフレームに付加し、結果として得られたフレームを同じ区域内のＨＶＡに接続されたブリッジ２９４０に送信することがある。この区域の内部で、ＨＶＢＭＡＣまたはＤＢＢＢＭＡＣになることがある外部ヘッダのＤＡは、不明であることがある。

ステップ２９０４で、フレームは、ブリッジ２９４０から区域内の第１のＤＢＢ２９５０（ＤＢＢＡ）に転送されることがある。コアは、ルーテッド転送（たとえば、８０２．１ａｑＳＰＢＭまたはＴＲＩＬＬ）で動作していることがあり、ラーニングは、コア内でディセーブル状態にされることがあるので、ＤＢＢＡで、ＤＡＨＶＢＭＡＣまたはＤＢＢＢＭＡＣは、知られていることがある。ステップ２９０５で、ＤＢＢＡは、フレームをＤＢＢＢに転送することがある。

ステップ２９０６で、ＤＢＢは、対称スキームの場合、ルーティングサブシステムからすべてのＨＶアドレスを知っているので、ＤＢＢＢは、フレームをＨＶＢに転送することがある。非対称スキームでは、ＤＢＢは、（ＤＡ：ＤＢＢＭＡＣ）を備える外部ヘッダを取り外し、区域に局所的なアドレスは、登録され、区域内で知られていることがあるので、残りのヘッダ中でフレームをＶＭＢＭＡＣに転送することがある。

ステップ２９０７で、ＨＶＢは、フレームを受信し、（ＤＡ：ＨＶＢＭＡＣ）を備える外部ヘッダを取り外し、対称スキームの場合、サーバに局所的なアドレスは、ＨＶＢに知られているので、結果として得られるフレームを残りのヘッダ中でＶＭＢＭＡＣに転送することがある。付加的には、ＨＶＢは、ＶＭＡＭＡＣ（残りのヘッダ中のＳＡ）からＨＶＡＭＡＣ（取り外されたヘッダ中のＳＡ）へのマッピングを知ることがあり、このマッピングは、ＶＭＢからＶＭＡへの応答フレーム中で実質的に使用されることがある。非対称スキームでは、フレームをＨＶＢに転送することに加えて、ＨＶＢは、ＶＭＡＭＡＣ（残りのヘッダ中のＳＡ）からＤＢＢＡＭＡＣへのマッピングを取り出すために、ＡＲＰメッセージをＡＲＰ（またはＤＳ）サーバ２９３０に送信することがあり、このマッピングは、ＶＭＢからＶＭＡへの応答フレーム中で引き続き使用されることがある。

ＶＭＢは、その後、ＶＭＡ（ＩＰ宛先アドレス）にアドレス指定されたフレームを送信することがある。ステップ２９０８で、ＨＶＢは、対称スキームの場合に、（ＳＡ：ＶＭＢＭＡＣ、ＤＡ：ＶＭＡＭＡＣ）を備える内部・アドレス・ヘッダと、（ＳＡ：ＨＶＢＭＡＣ、ＤＡ：ＨＶＡＭＡＣ）を備え外部ヘッダとをフレームに作成することがある。ＨＶＢは、前に受信されたメッセージまたはＡＲ応答から、ＶＭＡＩＰ対ＶＭＡＭＡＣマッピングと、ＶＭＡＭＡＣ対ＨＶＡＭＡＣマッピングとを維持することがある。非対称スキームでは、外部ヘッダは、（ＳＡ：ＨＶＢＭＡＣ、ＤＡ：ＤＢＢＡＭＡＣ）を備えることがある。ＨＶＢは、前に受信されたＡＲ応答から、ＶＭＡＭＡＣ対ＤＢＢＡＭＡＣマッピングを維持することがある。代替的には、ＨＶＢは、必要に応じてマッピングを取り出すために、ＡＲＰメッセージをＡＲＰ（またはＤＳ）サーバに送信することがある。フレームは、その後、上記ステップの場合と同じ方法で（たとえば、逆方向に）ＶＭＢからＶＭＡに転送されることがある。この方法２９００は、その後、終了することがある。

実施形態では、ネットワークは、複数のノードに接続され、ヘッダを出力フレームに付加することによりノードからの複数の出力フレームをカプセル化するために構成されているスイッチを備えることがある。ネットワークは、ローカルサイト内で複数のローカルノードに接続されている複数のローカルスイッチに接続された複数のダウンストリームポートと、複数のリモートゲートウェイおよびネットワーク内の複数のコアスイッチに接続されているアップストリームポートとを備えるゲートウェイをさらに備えることがある。ゲートウェイは、入力フレームからヘッダを取り外すことにより、リモートゲートウェイより下にある複数のリモートノードからスイッチを含むゲートウェイより下にあるローカルスイッチを介して接続されているローカルノードへの複数の入力フレームをカプセル化解除するために構成されることがある。スイッチによってヘッダを出力フレームに付加することは、ノードから出力フレームを転送するため使用されるネットワーク内のリモートゲートウェイおよびコアスイッチ内の転送アドレステーブルのサイズを縮小することがある。

さらに、スイッチは、仮想スイッチでも、非仮想すなわち物理スイッチでもよい。スイッチに接続されたノードは、複数のホスト、アプリケーション、仮想マシン、サーバ、コンポーネントと通信する他のネットワーク、または、これらの組み合わせを備えることがある。付加的には、ゲートウェイは、リモート・ゲートウェイ・スイッチを指示する外部ヘッダ内に宛先アドレスフィールドを含む複数の予めカプセル化されたデータフレームを受信することがある。カプセル化は、ゲートウェイスイッチのダウンストリームポートに接続されたローカルスイッチによって実行されることがある。ゲートウェイは、複数の予めカプセル化されたデータフレームをリモート・ゲートウェイ・スイッチに、カプセル化することなく、さらに転送することがある。

付加的には、フレーム中の外部ヘッダ内の送信元アドレスフィールドは、フレームがゲートウェイより下にあるローカルスイッチのうちの１つによってカプセル化されている場合でさえ、ゲートウェイのプロキシまたは代表アドレスになることがある。外部ヘッダの送信元アドレスフィールド中のゲートウェイのプロキシまたは代表アドレスを使用することは、ゲートウェイのアドレスに一致する送信元アドレスをもつローカルスイッチのうちの１つからフレームを受信するゲートウェイによる混乱を防止し、ローカルスイッチおよびローカルノードのアドレスがリモート・ゲートウェイ・スイッチおよびコアスイッチから見えないようにすることがある。ゲートウェイより下にあるローカルスイッチは、ゲートウェイからカプセル化解除されたデータフレームを受信し、ローカルスイッチのＦＤＢに基づいてゲートウェイからローカルノードにカプセル化解除されたデータフレームを転送することがある。ゲートウェイの転送アドレステーブルは、ゲートウェイより下にあるローカルスイッチに接続されたローカルノード、リモートゲートウェイ、およびコアスイッチのためのローカルＦＤＢまたはＦＩＢを備えることがある。ＦＤＢまたはＦＩＢは、リモートゲートウェイより下にあるリモートノードのためのエントリを備えないことがある。コアスイッチ内のＦＤＢは、ゲートウェイおよびリモートゲートウェイを含むゲートウェイのためのエントリだけを備えることがある。

リモートｓからの入力フレームからヘッダを取り外すことは、フレームをローカルノードに転送するため使用されるローカルスイッチ内の転送アドレステーブルのサイズを縮小することがある。ローカルスイッチ内のＦＤＢまたはＦＩＢは、リモートゲートウェイおよびリモートゲートウェイより下にあるリモートノードのためのエントリを必要としないことがある。ゲートウェイより下にあるローカルスイッチのＦＤＢまたはＦＩＢは、ゲートウェイを含む複数のローカルゲートウェイより下にあるすべてのローカルノードのエントリを備えることがある。スイッチは、ローカルノードからのＡＲＰ／ＮＤ要求を取り扱うために構成されたＡＲＰプロキシをさらに備えることがある。

図３０は、ネットワークを介してパケットを送信／受信する機器になることがあるネットワーク・コンポーネント・ユニット３０００の実施形態を例示する。たとえば、ネットワーク・コンポーネント・ユニット３０００は、仮想／スードレイヤ２ネットワーク内の異なるロケーション／ドメインを越えてＬ２ＧＷに位置することがある。ネットワーク・コンポーネント・ユニット３０００は、他のネットワークコンポーネントからパケット、オブジェクト、またはＴＬＶを受信する１つ以上の入口ポートまたはユニット３０１０と、パケットを送信する先のネットワークコンポーネントを決定する論理回路３０２０と、フレームを他のネットワークコンポーネントに伝送する１つ以上の出口ポートまたはユニット３０３０とを備えることがある。

上述のネットワークコンポーネントは、このコンポーネントに加えられる必要な負荷を取り扱うために十分な処理能力と、メモリリソースと、ネットワークスループット能力とをもつコンピュータシステムまたはネットワークコンポーネントのような汎用ネットワークコンポーネント上に実施されることがある。図３１は、ここに開示されたコンポーネントの１つ以上の実施形態を実施するため適した典型的な汎用コンピュータシステム３１００を例示する。汎用コンピュータシステム３１００は、補助記憶装置３１０４を含むメモリ機器と通信しているプロセッサ３１０２（ＣＰＵと呼ばれることもある）と、リード・オンリー・メモリ（ＲＯＭ）３１０６と、ランダム・アクセス・メモリ（ＲＡＭ）３１０８と、入力／出力（Ｉ／Ｏ）機器３１１０と、ネットワーク接続機器３１１２とを含む。プロセッサ３１０２は、１つ以上のＣＰＵチップとして実施されることがあり、または、１つ以上の特定用途向け集積回路（ＡＳＩＣ）の一部分でもよい。

補助記憶装置３１０４は、典型的には、１台以上のディスクドライブまたはテープドライブを備え、データの不揮発性記憶のため使用され、そして、ＲＡＭ３１０８がすべての作業データを保持するために十分に大きくされていない場合、オーバーフローデータ記憶装置として使用される。補助記憶装置３１０４は、プログラムが実行のため選択されたとき、ＲＡＭ３１０８にロードされたこのようなプログラムを記憶するために使用されることがある。ＲＯＭ３１０６は、命令と、おそらくは、プログラム実行中に読み出されるデータとを記憶するために使用される。ＲＯＭ３１０６は、典型的に、補助記憶装置３１０４の大記憶容量と比較して小さい記憶容量を有する不揮発性記憶装置である。ＲＡＭ３１０８は、揮発性データを記憶するために、そして、おそらくは、命令を記憶するために使用される。ＲＯＭ３１０６およびＲＡＭ３１０８の両方へのアクセスは、典型的に補助記憶装置３１０４へのアクセスより高速である。

少なくとも１つの実施形態が開示され、当業者によって行われた実施形態（群）および／または実施形態（群）の特徴の変形、組み合わせ、および／または変更は、開示内容の範囲内である。実施形態（群）の特徴の組み合わせ、統合、および／または省略から生まれる代替的な実施形態は、同様に開示内容の範囲内である。数値範囲または限定が明示されている場合、このような明確な範囲または限定は、明示された範囲または限定の範囲に入る同種の大きさの反復的な範囲または限定を含む（たとえば、約１から約１０は、２、３、４などを含み、０．１０より大は、０．１１、０．１２、０．１３などを含む）ことが理解されるべきである。たとえば、下限Ｒｌおよび上限Ｒｕをもつ数値範囲が開示されたときはいつでも、この範囲に入るあらゆる数値が具体的に開示されている。特に、範囲内の以下の数値が具体的に開示される：Ｒ＝Ｒｌ＋ｋ＊（Ｒｕ−Ｒｌ）、式中、ｋは、１パーセントから１００パーセントまで１パーセント刻みで変動する変数であり、すなわち、ｋは、１パーセント、２パーセント、３パーセント、４パーセント、７パーセント、・・・、７０パーセント、７１パーセント、７２パーセント、・・・、９７パーセント、９６パーセント、９７パーセント、９８パーセント、９９パーセント、または１００パーセントである。さらに、上記において定義されたような２つのＲ数によって定義された数値範囲は、同様に具体的に開示されている。請求項のいずれかの要素に関する用語「所望によっては（ｏｐｔｉｏｎａｌｌｙ）」の使用は、この要素が必要とされること、または、代替的には、この要素が必要とされないこと、そして、これらの代案がどちらも請求項の範囲に含まれることを意味する。「〜を備える」、「〜を含む」、および「〜を有する」のようなより広義の用語の使用は、「〜からなる」、「本質的に〜からなる」、および「実質的に〜で構成される」のようなより狭義の用語をサポートすることが理解されるべきである。結果として、保護の範囲は、上述の記載によって制限されるのではなく、請求項によって定められ、この保護の範囲は、請求項の主題のすべての均等物を含んでいる。ありとあらゆる請求項は、さらなる開示内容として明細書に組み込まれ、請求項は、本開示の実施形態（群）である。開示中の引例の検討は、この引例、特に、本願の優先日より後の公開日を有する引例が先行技術であるという自認ではない。本開示において引用されたすべての特許、特許出願、刊行物の開示内容は、典型的な、手続き的な、または、その他の詳細な補足を本開示に加える程度まで、参照によって組み込まれる。

いくつかの実施形態が本開示に記載されているが、開示されたシステムおよび方法は、本開示の趣旨または範囲から逸脱することなく、多くの他の具体的な形式で具現化されてもよいことが理解されるべきである。本実施例は、限定ではなく、例示としてみなされるべきであり、ここに記載された細部に限定されないことを意図している。たとえば、様々な要素またはコンポーネントは、組み合わされることがあり、もしくは、別のシステムに統合されることがあり、または、ある種の特徴は、省略されること、または、実施されないことがある。

さらに、個別または別個に様々な実施形態において記載され、例示された手法、システム、サブシステム、および方法は、本開示の範囲から逸脱することなく、他のシステム、モジュール、手法、または方法と組み合わされ、または、統合されることがある。互いに結合され、もしくは、直接的に結合され、または、通信するもとのとして示されるか、または、検討された他の要素は、電気的、機械的、または、それ以外を問わずに何らかのインターフェース、機器、または、中間コンポーネントを介して間接的に結合され、または、通信することがある。変更、置換、および代替の他の実施例は、当業者によって確かめることが可能であり、ここに開示された趣旨および範囲から逸脱することなく行われ得るであろう。

Claims

仮想スイッチを含む装置であって、
前記装置がアップストリーム方向において動作しているときに、前記仮想スイッチは、第１の仮想マシンから、前記第１の仮想マシンが第２の仮想マシンへ送信した出力フレームを受信し、前記出力フレームに第１のヘッダを付加することにより前記出力フレームをカプセル化し、前記第１のヘッダを含む前記出力フレームをエッジスイッチに送信するように構成されており、
前記装置がダウンストリーム方向において動作しているときに、前記仮想スイッチは、前記エッジスイッチから、前記第２の仮想マシンが前記第１の仮想マシンへ送信したフレームであって、入力フレームからヘッダを除去することにより前記エッジスイッチによりカプセル化解除されたフレームを受信し、前記ヘッダが除かれたフレームを前記第１の仮想マシンに転送するようにさらに構成されている、
装置。
前記アップストリーム方向において、前記エッジスイッチは、前記仮想スイッチから前記出力フレームを受信し、前記第１のヘッダを処理することにより前記出力フレームの第２のヘッダを取得し、前記第２のヘッダを含むフレームをネットワークコアを介して前記第２の仮想マシンに転送する、請求項１に記載の装置。
前記第２のヘッダ内の送信元アドレスフィールドは、プロキシまたは代表アドレスである、請求項２に記載の装置。
前記仮想スイッチは、カプセル化解除された入力フレームを、前記仮想スイッチの転送データベース（ＦＤＢ）に基づいて前記第１の仮想マシンへ転送するように構成された、請求項１に記載の装置。
前記エッジスイッチの転送テーブルは、前記エッジスイッチより下にある仮想スイッチに接続されたローカル仮想マシン、リモートエッジスイッチおよびコアスイッチのための前記エッジスイッチの転送データベース（ＦＤＢ）または転送情報ベース（ＦＩＢ）を備え、前記エッジスイッチのＦＤＢまたはＦＩＢは、前記リモートエッジスイッチより下にあるリモート仮想マシンのためのエントリを備えることがなく、前記コアスイッチ内の転送データベース（ＦＤＢ）は、前記エッジスイッチおよび前記リモートエッジスイッチを含むエッジスイッチのためのエントリだけを備える、請求項１に記載の装置。
前記仮想スイッチ内のＦＤＢまたは転送情報ベース（ＦＩＢ）は、リモートエッジスイッチおよび前記リモートエッジスイッチより下にあるリモート仮想マシンのためのエントリを備えない、請求項５に記載の装置。
前記エッジスイッチの前記ＦＤＢは、前記ローカル仮想マシンのエントリを備える、請求項６に記載の装置。
前記仮想スイッチは、前記第１の仮想マシンからのアドレス解決・プロトコル（ＡＲＰ）／ネイバー・ディスカバリ（ＮＤ）要求を取り扱うために構成されているＡＲＰプロキシを備える、請求項１に記載の装置。
前記出力フレームは、米国電気電子学会（ＩＥＥＥ）８０２．１ａｈ規格に準拠するメディア・アクセス・コントロール（ＭＡＣ）−ｉｎ−ＭＡＣを使用してカプセル化され、前記第１のヘッダは、前記出力フレームのターゲット宛先にマッピングされたターゲットロケーションのＭＡＣアドレスを備える、請求項１に記載の装置。
前記出力フレームは、トランスペアレント・インターコネクト・オブ・ロッツ・オブ・リンク（ＴＲＩＬＬ）を使用してカプセル化され、前記第１のヘッダは、前記出力フレームのターゲット宛先アドレスにマッピングされたターゲットロケーションのための１６ビットのニックネームを備える、請求項１に記載の装置。
前記出力フレームは、インターネット・プロトコル（ＩＰ）ｉｎ−ＩＰを使用してカプセル化され、前記第１のヘッダは、前記出力フレームのターゲット宛先アドレスにマッピングされたターゲットロケーションのＩＰアドレスを備える、請求項１に記載の装置。
エッジスイッチを含む装置であって、
前記装置がアップストリーム方向において動作しているときに、前記エッジスイッチは、仮想スイッチから、第１の仮想マシンが第２の仮想マシンへ送信した出力フレームであって、第１のヘッダを付加することにより前記仮想スイッチによりカプセル化された出力フレームを受信し、前記第１のヘッダを処理することにより前記出力フレームの第２のヘッダを取得し、前記第２のヘッダを含む前記出力フレームをネットワークコアを介して第２の仮想マシンに送信するように構成されており、
前記装置がダウンストリーム方向において動作しているときに、前記エッジスイッチは、前記ネットワークコアから、前記第２の仮想マシンが前記第１の仮想マシンへ送信した入力フレームを受信し、前記入力フレームからヘッダを除去することにより前記入力フレームをカプセル化解除し、前記入力フレームを前記仮想スイッチに転送するようにさらに構成されている、
装置。
前記ダウンストリーム方向において、前記仮想スイッチは、前記ヘッダが除かれた前記入力フレームを前記第１の仮想マシンに転送する、請求項１２に記載の装置。
前記第２のヘッダ内の送信元アドレスフィールドは、プロキシまたは代表アドレスである、請求項１２に記載の装置。
前記エッジスイッチの転送テーブルは、前記エッジスイッチより下にある仮想スイッチに接続されたローカル仮想マシン、リモートエッジスイッチおよびコアスイッチのための前記エッジスイッチの転送データベース（ＦＤＢ）または転送情報ベース（ＦＩＢ）を備え、前記エッジスイッチのＦＤＢまたはＦＩＢは、前記リモートエッジスイッチより下にあるリモート仮想マシンのためのエントリを備えることがなく、前記コアスイッチ内の転送データベース（ＦＤＢ)は、前記エッジスイッチおよび前記リモートエッジスイッチを含むエッジスイッチのためのエントリだけを備える、請求項１２に記載の装置。
前記エッジスイッチの前記ＦＤＢは、前記ローカル仮想マシンのためのエントリを備える、請求項１５に記載の装置。
前記出力フレームは、米国電気電子学会（ＩＥＥＥ）８０２．１ａｈ規格に準拠するメディア・アクセス・コントロール（ＭＡＣ）−ｉｎ−ＭＡＣを使用してカプセル化され、前記第１のヘッダは、前記出力フレームのターゲット宛先にマッピングされたターゲットロケーションのＭＡＣアドレスを備える、請求項１２に記載の装置。
前記出力フレームは、トランスペアレント・インターコネクト・オブ・ロッツ・オブ・リンク（ＴＲＩＬＬ）を使用してカプセル化され、前記第１のヘッダは、前記出力フレームのターゲット宛先アドレスにマッピングされたターゲットロケーションのための１６ビットのニックネームを備える、請求項１２に記載の装置。
前記出力フレームは、インターネット・プロトコル（ＩＰ）ｉｎ−ＩＰを使用してカプセル化され、前記第１のヘッダは、前記出力フレームのターゲット宛先アドレスにマッピングされたターゲットロケーションのＩＰアドレスを備える、請求項１２に記載の装置。