(57)【特許請求の範囲】
【請求項１】
データ処理の方法であって、
第２層予約リクエストを発信局から受信するのに応答して、ネットワーク・スイッチによって、前記発信局のデータ・フローのために、前記ネットワーク・スイッチのイングレス・キューの容量に対する予約を設定するステップと、
前記予約が有効な間の、前記ネットワーク・スイッチの前記イングレス・キュー上のキュー・オーバーラン状態に応答して、前記予約に従い送信された前記発信局の前記データ・フロー内のデータ・フレームを前記ネットワーク・スイッチによって維持し、ほかのデータ・フレームを破棄するステップと、
を含む方法。
【請求項２】
前記データ・フローは、前記発信局の複数のデータ・フローに関連し、
予約の設定は、前記発信局の前記複数のデータ・フローそれぞれのために、複数の予約のうちの各々１つを設定することを含む、
請求項１に記載の方法。
【請求項３】
前記データ・フローは、宛先局に宛てられ、
前記ネットワーク・スイッチは、前記発信局と前記宛先局との間のデータ経路内の複数のスイッチに関連し、
前記設定は、前記データ経路内の前記複数のスイッチそれぞれにて前記予約を設定することを含む、
請求項１または請求項２に記載の方法。
【請求項４】
前記ネットワーク・スイッチによって、前記第２層予約リクエストを受信すること
をさらに含む、請求項１〜３のいずれかに記載の方法。
【請求項５】
前記第２層予約リクエストは、リンク層検出プロトコル（ＬＬＤＰ）フレーム内で指定される、請求項１〜４のいずれかに記載の方法。
【請求項６】
前記第２層予約リクエストは、前記発信局の第２層アドレスおよびフロー識別子によって前記データ・フローを特定する、請求項１〜５のいずれかに記載の方法。
【請求項７】
前記予約の設定は、前記ネットワーク・スイッチの予約データ構造に前記予約を記録することを含む、請求項１〜６のいずれかに記載の方法。
【請求項８】
タイマの満了に応答して、前記ネットワーク・スイッチによって前記予約を削除すること
をさらに含む、請求項１〜７のいずれかに記載の方法。
【請求項９】
予約されたデータ・ボリュームが使い果たされるのに応答して、前記ネットワーク・スイッチによって前記予約を削除するステップ
をさらに含む、請求項１〜８のいずれかに記載の方法。
【請求項１０】
前記予約の間、前記イングレス・キュー内の予約された容量を前記ネットワーク・スイッチによって変更するステップ
をさらに含む、請求項１〜９のいずれかに記載の方法。
【請求項１１】
前記発信局によって、前記第２層予約リクエストを送信するステップ
をさらに含む、請求項１〜１０のいずれかに記載の方法。
【請求項１２】
スイッチであって、
複数のイングレス・キューのうちの各々１つをそれぞれ含む複数のポートと、
前記複数のポート間でデータ・フレームをスイッチングするよう動作可能なクロスバーと、
第２層予約リクエストを発信局から受信するのに応答して、前記発信局のデータ・フローのために、前記複数のイングレス・キューうちの１つの容量に対する予約を設定するよう動作可能な、スイッチ・コントローラであって、前記スイッチは、前記予約が有効な間の、前記スイッチの前記イングレス・キュー上のキュー・オーバーラン状態に応じて、前記予約に従い送信された前記発信局の前記データ・フロー内のデータ・フレームを維持し、ほかのデータ・フレームを破棄するよう動作可能である、前記スイッチ・コントローラと、
を含むスイッチ。
【請求項１３】
前記データ・フローは、前記発信局の複数のデータ・フローに関連し、
前記スイッチ・コントローラは、前記発信局の前記複数のデータ・フローそれぞれのために、複数の予約のうちの各々１つを設定するよう動作可能である、
請求項１２に記載のスイッチ。
【請求項１４】
前記データ・フローは、宛先局に宛てられ、
前記スイッチは、前記発信局と前記宛先局との間のデータ経路内の複数のスイッチに関連し、
前記スイッチは、前記発信局により近い別のスイッチから前記第２層予約リクエストを受信するよう動作可能である、
請求項１２または請求項１３に記載のスイッチ。
【請求項１５】
前記第２層予約リクエストは、リンク層検出プロトコル（ＬＬＤＰ）フレーム内で指定可能である、請求項１２〜１４のいずれかに記載のスイッチ。
【請求項１６】
前記第２層予約リクエストは、前記発信局の第２層アドレスおよびフロー識別子によって前記データ・フローを特定する、請求項１２〜１５のいずれかに記載のスイッチ。
【請求項１７】
前記スイッチ・コントローラは、前記スイッチ・コントローラが前記予約を記録する、関連する予約データ構造を含む、請求項１２〜１６のいずれかに記載のスイッチ。
【請求項１８】
前記スイッチ・コントローラは、タイマの満了に応答して、前記予約を削除するよう動作可能である、請求項１２〜１７のいずれかに記載のスイッチ。
【請求項１９】
前記スイッチ・コントローラは、予約されたデータ・ボリュームが使い果たされるのに応答して、前記予約を削除するよう動作可能である、請求項１２〜１８のいずれかに記載のスイッチ。
【請求項２０】
前記スイッチ・コントローラは、前記予約の間、前記イングレス・キュー内の予約された容量を変更するよう動作可能である、請求項１２〜１９のいずれかに記載のスイッチ。
【請求項２１】
請求項１２〜１９のいずれかに記載の前記スイッチと、
データリンクによって前記スイッチに結合可能なデータ処理システムと、
を含むシステムであって、前記データ処理システムは、
プロセッサと、
前記プロセッサに結合可能なデータ・ストレージと、
前記発信局であって、前記発信局は、前記データ処理システム内に配置可能であり、前記発信局の前記データ・フローのために、前記スイッチの前記イングレス・キューの容量に対する予約をリクエストするべく、前記スイッチへ前記第２層予約リクエストを送信するよう動作可能であり、前記発信局は、前記予約の許可に応じて、前記データ・フローのデータ・フレームを、前記予約された容量に従って前記スイッチへ送信し、その結果、前記データ処理システムは、前記スイッチによる前記データ・フレームの保証された転送を得るよう動作可能である、前記発信局と、
を含む、システム。
【請求項２２】
データ処理システムであって、
プロセッサと、
前記プロセッサに結合されたデータ・ストレージと、
前記データ処理システム内の発信局であって、前記発信局のデータ・フローのために、ネットワーク・スイッチのイングレス・キューの容量に対する予約をリクエストするべく、前記ネットワーク・スイッチへ第２層予約リクエストを送信するよう動作可能であり、前記予約の許可に応じて、前記データ・フローのデータ・フレームを、前記予約された容量に従って前記ネットワーク・スイッチへ送信するよう動作可能な、前記発信局であって、その結果、前記データ処理システムは、前記ネットワーク・スイッチによる前記データ・フレームの保証された転送を得るよう動作可能である、前記発信局と、
を含むデータ処理システム。
【請求項２３】
コンピュータ・プログラム・コードを有するプログラムを記録したコンピュータ可読ストレージ媒体であって、前記コンピュータ・プログラム・コードは、マシンによって実行されると、コンピュータに、
第２層予約リクエストを発信局から受信するのに応答して、前記発信局のデータ・フローのために、ネットワーク・スイッチのイングレス・キューの容量に対する予約を設定するステップと、
前記予約が有効な間の、前記ネットワーク・スイッチの前記イングレス・キュー上のキュー・オーバーラン状態に応答して、前記予約に従い送信された前記発信局の前記データ・フロー内のデータ・フレームを維持し、ほかのデータ・フレームを破棄するステップと、
を実行することによって第２層スイッチを実装させる、
前記コンピュータ可読ストレージ媒体。
【請求項２４】
前記データ・フローは、前記発信局の複数のデータ・フローに関連し、
予約の設定は、前記発信局の前記複数のデータ・フローそれぞれのために、複数の予約のうちの各々１つを設定することを含む、
請求項２３に記載のコンピュータ可読ストレージ媒体。
【請求項２５】
前記データ・フローは、宛先局に宛てられ、
前記ネットワーク・スイッチは、前記発信局と前記宛先局との間のデータ経路内の複数のスイッチに関連し、
前記設定は、前記データ経路内の前記複数のスイッチそれぞれにて前記予約を設定することを含む、
請求項２３または請求項２４に記載のコンピュータ可読ストレージ媒体。
【請求項２６】
前記第２層予約リクエストは、リンク層検出プロトコル（ＬＬＤＰ）フレーム内で指定される、請求項２３〜２５のいずれかに記載のコンピュータ可読ストレージ媒体。
【請求項２７】
前記第２層予約リクエストは、前記発信局の第２層アドレスおよびフロー識別子によって前記データ・フローを特定する、請求項２３〜２６のいずれかに記載のコンピュータ可読ストレージ媒体。
【請求項２８】
前記予約の設定は、前記ネットワーク・スイッチの予約データ構造に前記予約を記録することを含む、請求項２３〜２７のいずれかに記載のコンピュータ可読ストレージ媒体。
【請求項２９】
前記プログラム・コードは、前記コンピュータに、
タイマの満了に応答して、前記予約を削除するステップ
をさらに実行させる、請求項２３〜２８のいずれかに記載のコンピュータ可読ストレージ媒体。
【請求項３０】
前記プログラム・コードは、前記コンピュータに、
予約されたデータ・ボリュームが使い果たされるのに応答して、前記予約を削除するステップ
をさらに実行させる、請求項２３〜２９のいずれかに記載のコンピュータ可読ストレージ媒体。
【請求項３１】
前記プログラム・コードは、前記コンピュータに、
前記予約の間、前記イングレス・キュー内の予約された容量を変更するステップ
をさらに実行させる、請求項２３〜３０のいずれかに記載のコンピュータ可読ストレージ媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的には、ネットワーク通信に関し、特に、通信ネットワークにおけるスイッチ・キュー容量の予約に関する。
【背景技術】
【０００２】
当技術分野で周知のように、ネットワーク通信は、一般に、周知の７層開放型システム間相互接続（ＯＳＩ：Ｏｐｅｎ  Ｓｙｓｔｅｍｓ  Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）モデルに基づく。ＯＳＩモデルは、様々なプロトコル層の機能を定義するが、層プロトコル自体を規定するものではない。本願明細書では第７層〜第１層と呼ばれることもあるこの７層は、それぞれアプリケーション、プレゼンテーション、セッション、トランスポート、ネットワーク、データリンクおよび物理層である。
【０００３】
発信局（ｓｏｕｒｃｅ  ｓｔａｔｉｏｎ）にて、機能のスタックの最上位（アプリケーション）層で発信プロセスからデータが受領されると、データ通信が開始する。データは、データリンク層においてビットのデータ・フレームが得られるまで、スタックの１つ下位へと、各層において順次フォーマットされていく。データは、最後に物理層にて、電磁信号の形態でネットワーク・リンクを介して宛先局へ向けて送信される。送信されたデータは、宛先局で受信されると、発信局でデータが処理されたのとは逆の順序で、対応する機能のスタックを上へと渡され、このようにして、宛先局にて情報が受信側プロセスに供給される。
【０００４】
ＯＳＩモデルによってサポートされているものなどの階層型プロトコルの原理は、データはモデル層を上下に移動するが、発信および宛先局の各層はピア・ツー・ピア（すなわち第Ｎ層対第Ｎ層）方式で対話し、個々の層それぞれの機能が、個々の層の機能と、その直上および直下にあるプロトコル層との間のインターフェースに影響を及ぼすことなく実行されるというものである。この効果を得るために、発信局のプロトコル・スタックの各層は、通常、送信元プロセスによって生成されたデータがスタックを降下していくときにそのデータに情報（カプセル化されたヘッダの形態で）を追加する。宛先局では、非カプセル化されたデータが受信側プロセスに届くまで、フレームがスタックの各層を上へと伝わるにつれてこれらのカプセル化されたヘッダが１つずつ取り除かれる。
【０００５】
発信局と宛先局とを結合する物理ネットワークは、１つ以上の有線または無線ネットワーク・リンクによって相互接続された任意の数のネットワーク・ノードを含み得る。ネットワーク・ノードは、一般に、ネットワーク・トラフィックを生成および消費するホスト（例えばサーバ・コンピュータ、クライアント・コンピュータ、モバイル・デバイスなど）、スイッチおよびルータを含む。従来のネットワーク・スイッチは、種々のネットワーク・セグメントを相互接続し、ＯＳＩモデルのデータリンク層（第２層）にてデータを処理および転送する。スイッチは、典型的には、第２層媒体アクセス制御（ＭＡＣ：Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）アドレスによってデータ・トラフィックをフィルタリングすること、フレームの発信ＭＡＣアドレスを学習すること、および宛先ＭＡＣアドレスに基づきフレームを転送することを含む、基本的なブリッジ機能を少なくとも提供する。ＯＳＩモデルのネットワーク（第３層）にて種々のネットワークを相互接続するルータは、典型的には、ルート処理、経路決定および経路スイッチングなどのネットワーク・サービスを実装する。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
階層型通信プロトコルを実装する従来のコンピュータ・ネットワークでは、データ接続の信頼性は、上位層プロトコル（すなわち第４層以上）の専門とされてきた。例えば、着信データ・フレームを処理するためのスイッチのイングレス・ポートに結合されている発信局によって、そのイングレス・ポートの容量がオーバーランされると、スイッチは、処理できない着信フレームを通知なしに破棄し、パケット損失の検出および必要に応じた回復動作の実行は、トランスポート（第４層）およびその上位の層プロトコルに委ねられる。発信局と宛先局との間のデータ通信がパケット損失を許容しない場合、発信局にて送信元プロセスを抑制して損失パケットを回復および再送するために必要とされる処理により、データ通信をサポートするネットワーク・ノード、特に発信局のホストに、大きな計算負荷がかかる可能性がある。
【０００７】
パケット回復に関連するネットワーク・ノードの計算負荷を軽減しようと、インターネット技術タスク・フォースは、ＩＥＴＦ  ＲＦＣ２２０５に記載されている資源予約プロトコル（ＲＳＶＰ：Ｒｅｓｏｕｒｃｅ  Ｒｅｓｅｒｖａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）、およびその拡張でありＩＥＴＦ  ＲＦＣ３２０９および５１５１に記載されているＲＳＶＰトラフィック・エンジニアリング（ＴＥ：Ｔｒａｆｆｉｃ  Ｅｎｇｉｎｅｅｒｉｎｇ）プロトコルを開発した。ＲＳＶＰおよびその拡張ＲＳＶＰ−ＴＥは、ネットワーク中のネットワーク層リソースを予約し、特定レベルのサービス品質（ＱｏＳ：ｑｕａｌｉｔｙ  ｏｆ  ｓｅｒｖｉｃｅ）のインターネット上のアプリケーション・データ・ストリームにより統合サービスを提供することができるように、ホストまたはルータにより採用可能なトランスポート層（第４層）プロトコルである。
【課題を解決するための手段】
【０００８】
少なくとも１つの実施形態によれば、ネットワーク・スイッチが、第２層予約リクエスト（Ｌａｙｅｒ  ２  ｒｅｓｅｒｖａｔｉｏｎ  ｒｅｑｕｅｓｔ）を発信局から受信するのに応答して、発信局のデータ・フローのために、ネットワーク・スイッチのイングレス・キュー（ｉｎｇｒｅｓｓ  ｑｕｅｕｅ）の容量に対する予約を設定する。予約が有効な間の、ネットワーク・スイッチのイングレス・キュー上のキュー・オーバーラン状態（ｑｕｅｕｅ  ｏｖｅｒｒｕｎ  ｃｏｎｄｉｔｉｏｎ）に応答して、ネットワーク・スイッチは、予約に従い送信された発信局のデータ・フロー内のデータ・フレームを維持し、ほかのデータ・フレームを破棄する。
【０００９】
好適な実施形態では、データ・フローは、発信局の複数のデータ・フローに関連し、予約の設定は、発信局の複数のデータ・フローそれぞれのために、複数の予約のうちの各々１つを設定することを含む。好適には、データ・フローは、宛先局に宛てられ、ネットワーク・スイッチは、発信局と宛先局との間のデータ経路内の複数のスイッチに関連し、設定は、データ経路内の複数のスイッチそれぞれにて予約を設定することを含む。さらに好適には、ネットワーク・スイッチは、第２層予約リクエストを受信する。さらに好適には、第２層予約リクエストは、リンク層検出プロトコル（ＬＬＤＰ：Ｌｉｎｋ  Ｌａｙｅｒ  Ｄｉｓｃｏｖｅｒｙ  Ｐｒｏｔｏｃｏｌ）フレーム内で指定される。
【００１０】
好適な実施形態では、第２層予約リクエストは、発信局の第２層アドレス（Ｌａｙｅｒ  ２  ａｄｄｒｅｓｓ）およびフロー識別子（ｆｌｏｗ  ｉｄｅｎｔｉｆｉｅｒ）によってデータ・フローを特定する。好適には、予約の設定は、ネットワーク・スイッチの予約データ構造（ｒｅｓｅｒｖａｔｉｏｎ  ｄａｔａ  ｓｔｒｕｃｔｕｒｅ）に予約を記録することを含む。さらに好適には、ネットワーク・スイッチは、タイマの満了に応答して、予約を削除する。さらに好適には、ネットワーク・スイッチは、予約されたデータ・ボリュームが使い果たされるのに応答して、予約を削除する。さらに好適には、ネットワーク・スイッチは、予約の間、イングレス・キュー内の予約された容量を変更する。さらに好適には、発信局は、第２層予約リクエストを送信する。
【００１１】
以下、添付の図面を参照しながら、単なる例として本発明の実施形態について記載する。
【図面の簡単な説明】
【００１２】
【図１】一実施形態によるデータ処理環境の上位ブロック図である。
【図２】一実施形態によるデータ処理システムの上位ブロック図である。
【図３】一実施形態による、仮想化を採用するデータ処理環境の一部の上位ブロック図である。
【図４】一実施形態による、第２層ネットワーク・スイッチの例示の実施形態の上位ブロック図である。
【図５】一実施形態による、仮想または物理スイッチのイングレス・キュー容量をホストが予約する、例示のプロセスの上位論理フローチャートである。
【図６】一実施形態による、ホストのデータ・フローのためにイングレス・キュー容量を仮想または物理スイッチが予約する、例示のプロセスの上位論理フローチャートである。
【図７】一実施形態による、ホストとスイッチとの間、およびスイッチ間のＱＲｓｖ通信を実装するために利用可能な、例示のリンク層検出プロトコル（ＬＬＤＰ）フレームを示す。
【図８】一実施形態による、ＱＲｓｖリクエストとしての機能を果たすＬＬＤＰデータ・フレーム内でホストによってスイッチへ送られ得る、例示のＱＲｓｖリクエストＴＬＶ（Ｔｙｐｅ，Ｌｅｎｇｔｈ，Ｖａｌｕｅ：タイプ、長さ、値）を示す。
【図９】一実施形態による、ＱＲｓｖリクエストに対するＱＲｓｖレスポンスとしての機能を果たすＬＬＤＰデータ・フレーム内でスイッチによってホストへ送られ得る、例示のＱＲｓｖレスポンスＴＬＶを示す。
【図１０】一実施形態による、発信局のデータ・フローのためのエンド・ツー・エンドＱＲｓｖの設定をリクエストするために、ＬＬＤＰデータ・フレーム内でスイッチにより別のスイッチへ転送され得る、例示のＱＲｓｖリクエストＴＬＶを示す。
【図１１】一実施形態による、第２層でのＱＲｓｖの設定および利用の一例を示す時空図である。
【発明を実施するための形態】
【００１３】
本願明細書では、第２層にてネットワーク・スイッチ内のイングレス・キュー容量を予約する技術が開示される。上記の予約を使用することにより、ＲＳＶＰなどのより上位の層の予約プロトコルに関連する大きな処理オーバーヘッドを伴わずに、データ通信の信頼性の向上がもたらされる。
【００１４】
以下、図面、特に図１を参照する。一実施形態による、例示のデータ処理環境１００の上位ブロック図が示されている。図のように、データ処理環境１００は、リソース１０２の集合を含む。様々なホスト、クライアント、スイッチ、ルータ、ストレージなどを含み得るリソース１０２が、通信のために相互接続されており、これらは、１つ以上のパブリック、プライベート、コミュニティ、もしくはクラウド・ネットワーク、またはその組み合わせにおいて物理的または仮想的にグループ化され得る（図示せず）。このように、データ処理環境１００は、パーソナル（例えばデスクトップ、ラップトップ、ネットブック、タブレットまたはハンドヘルド）コンピュータ１１０ａ、スマート・フォン１１０ｂ、サーバ・コンピュータ・システム１１０ｃ、およびメディア・プレーヤ（例えばセット・トップ・ボックス、デジタル多用途ディスク（ＤＶＤ：ｄｉｇｉｔａｌ  ｖｅｒｓａｔｉｌｅ  ｄｉｓｋ）プレーヤまたはデジタル・ビデオ・レコーダ（ＤＶＲ：ｄｉｇｉｔａｌ  ｖｉｄｅｏ  ｒｅｃｏｒｄｅｒ））１１０ｄなどの家電など、様々なクライアント・デバイス１１０がアクセス可能なインフラストラクチャ、プラットフォーム、ソフトウェア、もしくはサービス、またはそのいずれかの組み合わせを提供することができる。当然のことながら、図１に示されているクライアント・デバイス１１０のタイプは説明のためのものにすぎず、クライアント・デバイス１１０は、パケット・ネットワークを介してリソース１０２と通信し、リソース１０２にアクセスすることができる、任意のタイプの電子デバイスとすることができる。
【００１５】
以下、図２を参照する。図１のリソース１０２またはクライアント・デバイス１１０の中で物理ホストを実装するために利用することができる、例示のデータ処理システム２００の上位ブロック図が示されている。示されている例示の実施形態では、データ処理システム２００は、ケーブル配線、もしくは有線もしくは無線、パブリックもしくはプライベート、ローカルもしくは広域の１つ以上のネットワーク（インターネットを含む）、またはその両方を介して、データ処理システム２００が１つ以上のコンピューティング・リソース１０２と通信できるようにする、１つ以上のネットワーク・インターフェース２０４を含む。データ処理システム２００はさらに、例えばデータ処理環境１００内のデータまたはソフトウェアの管理、アクセスおよび操作を行うためにデータおよびプログラム・コードを処理する、１つ以上のプロセッサ２０２（典型的には１つ以上の集積回路を含む）を含む。データ処理システム２００はさらに、データ処理システム２００もしくはデータ処理環境１００内のほかのリソース（単数または複数）またはその両方によって実行される処理の入力を受領して出力を提供する、ポート、ディスプレイ、ユーザ入力デバイスおよび付属デバイスなどの入出力（Ｉ／Ｏ：ｉｎｐｕｔ／ｏｕｔｐｕｔ）デバイス２０６を含む。最後に、データ処理システム２００は、メモリ、ソリッド・ステート・ドライブ、光もしくは磁気ディスク・ドライブ、テープ・ドライブなどを含む、１つ以上の揮発性または不揮発性ストレージ・デバイスを含み得るデータ・ストレージ２１０を含む。データ・ストレージ２１０は、例えば、プロセッサ（単数または複数）２０２によって実行されるとデータ処理システム２００に本願明細書に記載の機能性の少なくとも一部を実装させる、プログラム・コード（ソフトウェア、ファームウェアまたはその組み合わせを含む）を記憶するとよい。
【００１６】
以下、図３を参照する。一実施形態による、仮想化を採用する物理ホスト３１０を含むデータ処理環境３００の一部の上位ブロック図が示されている。例えば、データ処理環境３００は、図１のデータ処理環境１００の一部を実装することができ、物理ホスト３１０は、リソース１０２またはクライアント・デバイス１１０のうちの１つを実装することができる。
【００１７】
示されている実施形態では、データ処理環境３００は、１つ以上の有線もしくは無線ローカル・エリア・ネットワーク（ＬＡＮ：ｌｏｃａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ）またはインターネットなどの広域ネットワーク（ＷＡＮ：ｗｉｄｅ  ａｒｅａ  ｎｅｔｗｏｒｋ）を含み得るネットワーク３０２を含む。ネットワーク３０２には、アクセス・スイッチ３０４が接続されており、アクセス・スイッチ３０４は、物理リンク３０６によってアクセス・スイッチ３０４に接続されている、物理ホスト３１０を含む１つ以上の物理ホストに、ネットワーク３０２へのＯＳＩ第２層接続性を提供する。当然のことながら、物理リンク３０６は、有限の利用可能帯域幅を有し、これは一般に、アクセス・スイッチ３０４および物理ホスト３１０によって、それらの通信能力に基づいて、またはプロトコル依存のネゴシエーションにより決定される。
【００１８】
図３の物理ホスト３１０は、例えば、図２に示されたデータ処理システム２００を利用して実装することができる。例えば、示されている例では、物理ホスト３１０のネットワーク・インターフェース（単数または複数）２０４は、ペリフェラル・コンポーネント・インターコネクト・エクスプレス（ＰＣＩｅ：Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ  Ｅｘｐｒｅｓｓ）コンバージド・ネットワーク・アダプタ（ＣＮＡ：Ｃｏｎｖｅｒｇｅｄ  Ｎｅｔｗｏｒｋ  Ａｄａｐｔｅｒ）３１２を含む。示されている実施形態では、ＰＣＩｅ  ＣＮＡ３１２は、物理リンク３０６に結合された仮想イーサネット・ブリッジ（ＶＥＢ：Ｖｉｒｔｕａｌ  Ｅｔｈｅｒｎｅｔ  Ｂｒｉｄｇｅ）３１４、ならびに異なる複数のＯＳＩ第２層ネットワークのサポートを含む。したがって、この例では、ＰＣＩｅ  ＣＮＡ３１２は、ファイバ・チャネル・ホスト・バス・アダプタ（ＦＣ  ＨＢＡ：Ｆｉｂｒｅ  Ｃｈａｎｎｅｌ  Ｈｏｓｔ  Ｂｕｓ  Ａｄａｐｔｅｒ）３１６およびコンバージド・エンハンスド・イーサネット（ＣＥＥ：Ｃｏｎｖｅｒｇｅｄ  Ｅｎｈａｎｃｅｄ  Ｅｔｈｅｒｎｅｔ）ネットワーク・インターフェース・カード（ＮＩＣ：Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）３１８を少なくとも含む。
【００１９】
物理ホスト３１０は、物理ホスト３１０のリソースを仮想化および管理する仮想マシン・モニタ（ＶＭＭ：Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ  Ｍｏｎｉｔｏｒ）３３０を実行する。ＶＭＭ３３０は、示されている例ではＶＭ（ｖｉｒｔｕａｌ  ｍａｃｈｉｎｅ：仮想マシン）３５０ａ〜３５０ｎを含む、１つ以上の（場合によっては何千もの）ＶＭの実行をサポートする。示されている実施形態では、ＶＭ３５０はそれぞれ、少なくともＯＳＩモデルの第２層でのネットワーク接続性を提供する、仮想ネットワーク・インターフェース３５２ａ〜３５２ｅのうちの少なくとも１つ（場合により複数）を有する。
【００２０】
図のように、ＶＭＭ３３０は、そのＶＭ３５０が接続できる１つ以上の（示されている実施形態では少なくとも２つの）仮想ネットワークを提供する。例えば、示されている実施形態では、ＶＭＭ３３０は、ＶＥＢ３３４を含む仮想スイッチ（ＶＳ：ｖｉｒｔｕａｌ  ｓｗｉｔｃｈ）３３２を実装することによって、第１の仮想第２層ネットワークを提供する。同様に、ＶＭＭ３３０は、ＦＣ  Ｎ＿Ｐｏｒｔ識別子仮想化（ＦＣ  ＮＰＩＶ：ＦＣ  Ｎ＿Ｐｏｒｔ  Ｉｄｅｎｔｉｆｉｅｒ  Ｖｉｒｔｕａｌｉｚａｔｉｏｎ）３３６を実装することによって、第２の仮想ネットワークを提供する。様々な実施形態において、ＶＭＭ３３０によってサポートされる仮想ネットワークのそれぞれは、例えば特定のパーティのプライベート・ネットワーク、複数のパーティによって共有される共同プライベート・ネットワーク、またはパブリック・ネットワークとすることがきる。
【００２１】
示されている例では、ＶＭ３５０ａのネットワーク・インターフェース３５２ａは、ＶＥＢ３３４を介して第１の仮想ネットワークに接続され、ＶＭ３５０ａのネットワーク・インターフェース３５２ｂは、ＦＣ  ＮＰＩＶ３３６を介して第２の仮想ネットワークに接続されている。同様に、ＶＭ３５０ｎのネットワーク・インターフェース３５２ｃは、ＶＥＢ３３４を介して第１の仮想ネットワークに接続され、ＶＭ３５０ｎのネットワーク・インターフェース３５２ｅは、ＦＣ  ＮＰＩＶ３３６を介して第２の仮想ネットワークに接続されている。ＶＭ３５０ｎは、ＶＭＭ３３０によってサポートされる仮想ネットワーク（および付随するオーバーヘッド）をバイパスし、ＶＭＭ３３０を介してＣＥＥ  ＮＩＣ３１８の「仮想機能」として提供されるスタック３２０に直接接続されている、さらなるネットワーク・インターフェース３５２ｄを含む。図３にさらに示されているように、ＦＣ  ＮＰＩＶ３３６は、ＰＣＩｅ  ＣＮＡ３１２のＦＣ  ＨＢＡ３１６に接続されており、ＶＳ３３２のＶＥＢ３３４は、ＣＥＥ  ＮＩＣ３１８に接続されている。ＦＣ  ＨＢＡ３１６およびＣＥＥ  ＮＩＣ３１８のトラフィックは、ＰＣＩｅ  ＣＮＡ３１２のＶＥＢ３１４に集まる。
【００２２】
さらに後述するように、物理ホスト３１０と、アクセス・スイッチ３０４などのネットワーク・スイッチとは、協働して、第２層にて少なくともアクセス・スイッチ３０４の帯域幅を予約することによって、データ通信の信頼性を改善する。
【００２３】
以下、図４を参照する。図３のアクセス・スイッチ３０４などの第２層ネットワーク・スイッチ４００の例示の実施形態の上位ブロック図が示されている。ＶＳ３３２などの仮想スイッチも、同様の構造とされ、示されているポートおよびキュー構造が物理ネットワーク・スイッチではなくホストのデータ・ストレージにおいて実装されてもよい。
【００２４】
図のように、ネットワーク・スイッチ４００は、複数のポート４０２ａ〜４０２ｍを含む。各ポート４０２は、複数の受信（Ｒｘ）インターフェース４０４ａ〜４０４ｍのうちの各々１つと、関連するＲｘインターフェース４０４によって受信されるデータ・フレームをバッファに入れる複数のイングレス・キュー４０６ａ〜４０６ｍのうちの各々１つとを含む。各ポート４０２ａ〜４０２ｍはさらに、複数のイーグレス・キュー４１４ａ〜４１４ｍのうちの各々１つと、関連するイーグレス・キュー４１４からデータ・フレームを送信する複数の送信（Ｔｘ）インターフェース４２０ａ〜４２０ｍのうちの各々１つとを含む。
【００２５】
ネットワーク・スイッチ４００は、スイッチ・コントローラ４３０の命令の下で、データ・フレームをイングレス・キュー４０６ａ〜４０６ｍのいずれかから、イーグレス・キュー４１４ａ〜４１４ｍのいずれかへインテリジェントにスイッチングするクロスバー４１０を含む。データ・フレームをインテリジェントにスイッチングするために、スイッチ・コントローラ４３０は、観測されるデータ・フレームから、ポートと、データ・フレームにより指定される宛先ＭＡＣアドレスとの関連を学習し、宛先ＭＡＣアドレスとポート４０２との間の学習した関連付けをフォワーディング・テーブル４３２のエントリに記録し、続いて、クロスバー４１０を制御して、データ・フレームを、フォワーディング・テーブル４３２に記録されている関連付けに従ってスイッチングする。スイッチ・コントローラ４３０はさらに、所定の基準を満たすデータ・フレームに関する所望のポリシの管理および強制を実装する、ポリシ・モジュール４３４を含むとよい。
【００２６】
上述のように、ネットワーク・スイッチ４００の特定のＲｘインターフェース４０４におけるデータ・フレームの到着率が、着信データ・フレームをバッファに入れる関連するイングレス・キュー４０６の容量をオーバーランすると、その超過分のデータ・フレームは通知なしに破棄される。イングレス・キュー４０６のオーバーランは、複数の（場合によっては多数の）ＶＭ３５０が独立して同時にネットワーク・スイッチ４００の同じポート４０２へデータを送信し得る、図３のデータ処理環境３００などの仮想化環境において、特に問題である。
【００２７】
イングレス・キュー４０６のオーバーランを削減し、それによってデータ通信の信頼性を改善するために、ネットワーク・スイッチ４００は、特定のデータ・フローのためのイングレス・キュー４０６内の容量の予約をサポートすることが好ましい。具体的には、図５〜６を参照してさらに後述するように、スイッチ・コントローラ４３０は、発信局（例えばネットワーク・アダプタ（例えば図３のＰＣＩｅ  ＣＮＡ３１２）、ネットワーク・アダプタのドライバ、制御プログラム（例えばオペレーティング・システムもしくはＶＭＭ３３０）、仮想マシン（例えばＶＭ３５０）またはアプリケーション・プログラム）が、そのデータ・フローのうちの１つのために、発信局と宛先局との間に置かれた１つ以上のネットワーク・スイッチ４００のイングレス・キュー４０６内の容量の予約をリクエストするための能力を、サポートする。その結果、ネットワーク・スイッチ（単数または複数）４００のスイッチ・コントローラ４３０は、例えば、データ・フローの数、既に予約されているイングレス・キュー容量の量などの１つ以上の要因に基づき、かつポリシ・モジュール４３４によって示されるポリシを考慮することによって、予約リクエストを許可または拒否する。許可される場合、スイッチ・コントローラ４３０は、予約データ構造、例えば予約テーブル４４０のエントリ４４２に、その予約を記録する。示されているように、一実施形態では、予約テーブル４４０の各エントリ４４２には例えば、帯域幅が予約されるポート４０２を特定するポートＩＤ（ＰＩＤ：ｐｏｒｔ  ＩＤ）フィールド４４４、イングレス・キュー容量が予約されるデータ・フレームを、例えば発信ＭＡＣアドレスもしくはフローＩＤまたはその両方により特定する、予約（Ｒｓｖ：ｒｅｓｅｒｖａｔｉｏｎ）ＩＤフィールド４４６、予約ＩＤに関連するデータ・フローのデータ・フレームのために予約されるイングレス・キュー容量の量（例えば、イングレス・キュー・エントリの数、キングレス・キュー容量の割合、もしくはデータの総ボリューム、またはそのいずれかの組み合わせとして表される）を示す予約（Ｒｓｖ）サイズ・フィールド４４８が含まれ得る。こうすることで、ネットワーク・スイッチ４００上に予約されたイングレス・キュー容量を有するデータ・フローのフレームは、データ・フローのデータ転送速度が予約された容量以下である限り、イングレス・キュー・オーバーラン状態になった場合に廃棄されない。代わりに、イングレス・キュー容量の予約がない、または予約されたイングレス・キュー容量を上回る、ほかのデータ・フローのデータ・フレームが廃棄される。
【００２８】
以下、図５を参照する。一実施形態による、図３の物理ホスト３１０などのホストが、図４のネットワーク・スイッチ４００などのスイッチのイングレス・キュー容量を予約する、例示のプロセスの上位論理フローチャートが示されている。示されているプロセスは、例えば、ネットワーク・アダプタ（例えば図３のＰＣＩｅ  ＣＮＡ３１２）、ネットワーク・アダプタのドライバ、制御プログラム（例えばオペレーティング・システムまたはＶＭＭ３３０）、仮想マシン（例えばＶＭ３５０）またはアプリケーション・プログラムなどの発信局によって実行され得る。一般化として、そのような実施形態すべてを、発信局が存在する「ホスト」の動作と呼ぶ。
【００２９】
図５のプロセスは、ブロック５００にて開始し、続いて、ホストがホストのデータ・フローのためのイングレス・キュー容量の予約（以下「ＱＲｓｖ」という）をリクエストするか否かを判断することを示す、ブロック５０２へ進む。ホストは、例えば、データ・フローの予想帯域幅、データのタイプ、フレーム損失に対するデータ・フローの許容度、もしくは同じイングレス・キューを共有しているほかのデータ・フローの数、またはそのいずれかの組み合わせなどに基づき、ブロック５０２にて示されている判断を下すとよい。データ・フローのためのＱＲｓｖをリクエストしないというブロック５０２での判断に応答して、プロセスは、ブロック５０４にて終了する。その結果として、ホストは、ホストと宛先局との間のデータ経路内のスイッチのいずれにおいてもイングレス・キュー予約を利用せず、イングレス・キューのオーバーランによるデータ・フレーム損失という付随するリスクを伴いながら、データ・フローをデータ・フローの宛先局へ送信する。
【００３０】
ブロック５０２に戻る。ホストが、データ・フローのためのＱＲｓｖをリクエストするという判断を下すのに応答して、プロセスは、ブロック５０２からブロック５１０へ進む。ブロック５１０は、ホストが、ホストと宛先局との間のデータ経路内のネットワーク・スイッチに、データ・フローのためのＱＲｓｖリクエストを送ることを示す。ＱＲｓｖリクエストは、Ｒｓｖ  ＩＤを用いてデータ・フローを特定することが好ましい。ＱＲｓｖリクエストに関連するデータ・フローが、特定の発信局によって送信されるすべてのデータを含む場合、Ｒｓｖ  ＩＤは単に、発信局の発信ＭＡＣアドレスであってもよい。他方、ＱＲｓｖリクエストが、特定の発信局の、複数である可能性のあるデータ・フローのうちの１つのみに関する場合、Ｒｓｖ  ＩＤは、発信局の発信ＭＡＣアドレスと、追加のフローＩＤとを含むとよい。いずれにせよ、ＱＲｓｖリクエストは、データ・フローのために予約されるイングレス・キュー容量の量を示すことが好ましく、さらに、ＱＲｓｖの下で送信されるデータの総ボリューム（または分量）を示してもよい。さらに後述するように、好適な実施形態では、ＱＲｓｖリクエストは、参照によって本願明細書に引用したものとするＩＥＥＥ  ８０２．１ＡＢ規格によって定義されているリンク層検出プロトコル（ＬＬＤＰ）などの第２層プロトコルを利用して伝達される。ブロック５１０にてさらに示されているように、ホストはさらに、ＱＲｓｖリクエストが許可または拒否されるウィンドウを定義するリクエスト・タイマを開始してもよい。
【００３１】
ブロック５１０の後、ホストは、ブロック５１２に示されているように、リクエストを許可もしくは拒否するＱＲｓｖレスポンスがホストによって受信されるか、またはリクエスト・タイマが満了するまで待機する。続いてホストは、ブロック５１４にて、リクエストしたＱＲｓｖが、リクエスト・タイマによって定義されたウィンドウ内に許可されたか否かを判断する。されていなければ、プロセスは、既に説明したブロック５０２に戻る。一方、ブロック５１４にてホストが、ＱＲｓｖリクエストが許可されたと判断すれば、プロセスは、ホストがそのＱＲｓｖをローカルで記録すること（例えば、図４の予約テーブル・エントリ４４２に似たテーブル・エントリに）を示すブロック５２０へ進む。さらに、ホストは任意選択で、ＱＲｓｖの継続期間を追跡する満了タイマを開始してもよく、初期の満了タイマ値は、例えば、既定のＱＲｓｖ継続期間によって、またはＱＲｓｖレスポンスにより指定されるタイマ値に基づいて判断されるとよい。この時点で、イングレス・キュー容量が予約されているスイッチ（単数または複数）を介してホストによって送信されるデータ・フローのデータ・フレームは、イングレス・キュー・オーバーラン状態に応答して廃棄されないことが保証される。
【００３２】
ブロック５２２にて示されているように、データ・フローを構成するデータ・フレームの送信中、ホストは任意選択で、そのＱＲｓｖの増減を、発信局と宛先局との間のデータ経路内の１つ以上のネットワーク・スイッチと再ネゴシエーションすることによって行ってもよい。ホストは、例えば、データ・フローの実データ転送速度に少なくとも部分的に基づいて、ＱＲｓｖによって予約された帯域幅を調節してもよい。ブロック５２４にて、ホストは、ＱＲｓｖの満了タイマが満了したか否か、またはＱＲｓｖの下で送信されるデータの総許容ボリュームが使い果たされたかどうかを判断する。否定であれば、プロセスは、既に説明した任意選択のブロック５２２に戻る。一方、ホストがブロック５２４にて、ＱＲｓｖが満了したか、または使い果たされたと判断すると、プロセスは、上記のブロック５０２に戻るが、これは、必要であればホストがデータ・フローのためのＱＲｓｖの更新をリクエストできることを示す。
【００３３】
以下、図６を参照する。一実施形態による、図４のネットワーク・スイッチ４００などの物理ネットワーク・スイッチ、または仮想スイッチが、発信局のデータ・フローのためにイングレス・キュー容量を予約する、例示のプロセスの上位論理フローチャートが示されている。一実施形態では、示されているプロセスは、ソフトウェアもしくはファームウェアもしくはその両方の実行を用いて、または用いずに、集積回路においてプロセスを実装するとよい、スイッチ・コントローラ４３０などのハードウェアにおいて実装される。
【００３４】
図のように、プロセスはブロック６００にて開始し、続いて、ネットワーク・リンクによってスイッチのポートが結合されているホストから、スイッチが第２層ＱＲｓｖリクエストを受信することを示す、ブロック６０２へ進む。上述のとおり、ＱＲｓｖリクエストは、好適には、発信ＭＡＣアドレスもしくはフローＩＤまたはその両方などのＲｓｖ  ＩＤを用いてデータ・フローを特定し、さらに、データ・フローのために予約されるイングレス・キュー容量の量を示し、さらに、ＱＲｓｖの下で送信されるデータのボリュームを示してもよい。
【００３５】
ブロック６０２にてＱＲｓｖリクエストを受信するのに応答して、スイッチはブロック６０４にて、例えば関連するイングレス・キュー４０６の総利用可能帯域幅、リクエストされたＱＲｓｖの量（データ転送速度もしくはボリュームまたはその両方）、関連するイングレス・キュー４０６に関して現在有効なほかのＱＲｓｖがあればそれら、もしくは同じポート４０２上のほかのデータ・フローの数、またはそのいずれかの組み合わせに基づき、ＱＲｓｖリクエストを許可するか否かを判断する。ＱＲｓｖリクエストを拒否するというブロック６０４での判断に応答して、スイッチは、任意選択で、ＱＲｓｖリクエストを明示的に拒否するＱＲｓｖレスポンスを送っても、または単にＱＲｓｖリクエストを通知なしに破棄し、それによって、図５のブロック５１２〜５１４を参照して前述したように、リクエスト元ホストのリクエスト・タイマをタイムアウトさせてもよい。いずれにせよ、図６のプロセスは、ブロック６０４から、既に説明したブロック６０２へ戻る。
【００３６】
一方、ブロック６０４にてスイッチが、ホストのＱＲｓｖを許可することが可能であり、かつ許可するべきであると判断すると、スイッチは、例えば予約テーブル４４０の予約テーブル・エントリ４４２にＱＲｓｖを記録する。さらに、スイッチは、図５のブロック５２０を参照して前述したとおり、ＱＲｓｖの継続時間を定義する満了タイマを開始するとよい。ホストのデータ・フローのために、発信局に最も近いスイッチのみにおいてＱＲｓｖを設定することをホストが許されるか、またはそれをホストがリクエストする実施形態では、プロセスは、ブロック６１０から後述のブロック６２０へ進む。ホストのデータ・フローのために、発信局と宛先局との間のデータ経路内の２つ以上のスイッチにおいてＱＲｓｖを設定することをホストが許され、それをホストがリクエストするほかの実施形態では、プロセスはブロック６１２に移動する。
【００３７】
ブロック６１２は、スイッチが発信局と宛先局との間のデータ経路内の最後のホップであるか否かをスイッチが判断すること、すなわち、そのスイッチのポートに、介在するスイッチなしに宛先局がデータリンクにより接続されているかどうかを判断することを示す。そうであれば、プロセスは、後述のブロック６２０へ進む。そうでなければ、プロセスは、スイッチが、ＱＲｓｖリクエストの発信ＭＡＣアドレスをスイッチのＭＡＣアドレスに更新して、ＱＲｓｖリクエストが図６に示されているように同じく処理される、データ・フローの宛先局までのデータ経路内にある次のスイッチへ、ＱＲｓｖリクエストを転送することを示す、ブロック６１４に移動する。続いてプロセスは、ブロック６１４からブロック６２０へ進む。
【００３８】
ブロック６２０は、スイッチが、ＱＲｓｖリクエストが受信されたリクエスト元の局に、リクエストされたＱＲｓｖの許可を確認するＱＲｓｖ確認を送ることを示す。ＱＲｓｖ確認は、データ・フローのために予約されたデータ転送速度、ＱＲｓｖの下で送信され得るデータの総許容ボリューム、もしくは予約の継続期間、またはそのいずれかの組み合わせを示すことが好ましい。ブロック６２２にて示されているように、データ・フローを構成するデータ・フレームの送信中、スイッチは任意選択で、発信局と再ネゴシエーションすることによってデータ・フローのためのＱＲｓｖを増減させてもよい。スイッチは、例えば、データ・フローの実データ転送速度、ほかのデータ・フローによって予約されている帯域幅、もしくは容量がないためスイッチにより拒否されたＱＲｓｖリクエスト、またはそのいずれかの組み合わせに少なくとも部分的に基づいて、ＱＲｓｖによって予約された帯域幅を調節してもよい。ブロック６２４にて、スイッチは、ＱＲｓｖの満了タイマが満了したか否か、またはＱＲｓｖの下で送信されるデータの総許容ボリュームが使い果たされたかどうかを判断する。否定であれば、プロセスは、既に説明した任意選択のブロック６２２に戻る。一方、スイッチがブロック６２４にて、ＱＲｓｖが満了したか、または使い果たされたと判断すると、スイッチは、予約テーブル４４０からそのＱＲｓｖの予約テーブル・エントリ４４２を削除し（ブロック６２６）、プロセスは、上記のブロック６０２へ戻るが、これは、リクエストされればスイッチはデータ・フローのためのＱＲｓｖを更新することができることを示す。
【００３９】
以下、図７を参照する。一実施形態による、ホストとスイッチとの間およびスイッチ間の第２層ＱＲｓｖ通信を実装するために利用することができる、ＩＥＥＥ８０２．１ＡＢによって定義されたＬＬＤＰフレーム（ＬＬＤＰデータ・ユニット（ＬＬＤＰＤＵ：ＬＬＤＰ  ｄａｔａ  ｕｎｉｔ）とも呼ばれる）７００が示されている。示されている実施形態では、ＬＬＤＰフレーム７００は、プリアンブル・フィールド７００、それに続く宛先ＭＡＣアドレス・フィールド７０２を含む。ホストが、発信局に最も近いスイッチのみにおけるＱＲｓｖをリクエストする場合（選択によって、または実装制約が理由で）、宛先ＭＡＣアドレス・フィールド７０２は、直近のブリッジの既定のアドレス（すなわち０１：８０：Ｃ２：００：００：０Ｅ）を指定することが好ましい。発信局と宛先局との間のデータ経路内のすべてのスイッチにおけるＱＲｓｖの設定をホストがリクエストするほかの場合には、宛先ＭＡＣアドレス・フィールド７０２は、データ・フローが送られる宛先局の宛先ＭＡＣアドレスを示すことが好ましい。
【００４０】
ＬＬＤＰフレーム７００はさらに、発信局のＭＡＣアドレスを特定する発信ＭＡＣアドレス・フィールド７０４、ＬＬＤＰに割り当てられたイーサタイプ（すなわち０ｘ８８ＣＣ）を含むイーサタイプ・フィールド７０４、および（ＬＬＤＰの下で）必須である３つのシャーシＩＤ、ポートＩＤおよび生存期間（ＴＴＬ：Ｔｉｍｅ−ｔｏ−Ｌｉｖｅ）のタイプ、長さ、値（ＴＬＶ）フィールド７０６、７０８および７１０それぞれを含む。ＬＬＤＰにより要求されるＴＬＶの後、図８〜１０を参照してさらに詳しく後述されるように、任意選択のＴＬＶフィールド７１２が、ＱＲｓｖのリクエストまたは許可／拒否に利用されるＱＲｓｖ関連のＴＬＶを指定する。
【００４１】
以下、図８を参照する。一実施形態による、ＱＲｓｖリクエストとしての機能を果たすＬＬＤＰデータ・フレーム７００内でホストによってスイッチへ送られ得る例示のＱＲｓｖリクエストＴＬＶ８００が示されている。ＱＲｓｖリクエストＴＬＶ８００は、１２７の値によってＱＲｓｖリクエストＴＬＶ８００がカスタムＴＬＶであることを示すタイプ・フィールド８００と、ＱＲｓｖリクエストＴＬＶ８００の長さをオクテットで指定する長さフィールド８０２とを含むＴＬＶヘッダを含む。示されている例では、長さフィールド８０２は、スイッチが、発信局のすべてのトラフィックを単一の統合データ・フローと見なす場合は１４オクテットの長さを指定し、スイッチが、発信局の複数のデータ・フローのうちの１つのための予約を独立して処理するようリクエストされる場合は、３０オクテットの長さを指定する。
【００４２】
ＱＲｓｖリクエストＴＬＶ８００はさらに、ＴＬＶを発行している組織を一意的に特定する組織固有識別子（ＯＵＩ：ｏｒｇａｎｉｚａｔｉｏｎａｌｌｙ  ｕｎｉｑｕｅ  ｉｄｅｎｔｉｆｉｅｒ）フィールド８０４、ＴＬＶの組織定義サブタイプを示す組織定義サブタイプ・フィールド８０６、および組織定義情報ストリング８０８を含むＴＬＶ情報ストリングを含む。組織定義サブタイプ・フィールド８０６の示されている例では、発信局に近いスイッチのみに向けられた、発信局の単一の統合データ・フローのためのＱＲｓｖリクエストには、１のサブタイプが指定され、発信局と宛先局との間のデータ経路内のすべてのスイッチにおける、発信局の単一の統合データ・フローのためのエンド・ツー・エンドＱＲｓｖをリクエストするＱＲｓｖリクエストには、３のサブタイプが指定され、発信局に近いスイッチのみにおける、発信局の複数のデータ・フローのうちの１つのためのＱＲｓｖリクエストには、１１のサブタイプが指定され、発信局と宛先局との間のデータ経路内のすべてのスイッチにおける、発信局の複数のデータ・フローのうちの１つのためのエンド・ツー・エンドＱＲｓｖをリクエストするＱＲｓｖリクエストには、１３のサブタイプが指定される。さらに、示されている例では、組織定義情報ストリング８０８は、ＱＲｓｖリクエストＴＬＶ８００を含むＬＬＤＰフレーム７００がＱＲｓｖリクエストであることを示し、ＱＲｓｖがリクエストされるバイトおよびフレームの数（すなわちトラフィック・ボリューム）を指定する。さらに、スイッチが、発信局の複数のデータ・フローのためのＱＲｓｖを別々に処理する場合、組織定義情報ストリング８０８が、発信局の複数のデータ・フローのうちのどれに関してＱＲｓｖがリクエストされるのかを一意的に特定する。
【００４３】
以下、図９を参照する。一実施形態による、ＱＲｓｖレスポンスとしての機能を果たすＬＬＤＰデータ・フレーム７００内でスイッチによってホストへ送られ得る例示のＱＲｓｖレスポンスＴＬＶ９００が示されている。これを含むＬＬＤＰデータ・フレーム７００では、発信および宛先ＭＡＣアドレス・フィールド７０２および７０４が、それぞれ送信側スイッチおよび発信局のＭＡＣアドレスを指定する。
【００４４】
ＱＲｓｖレスポンスＴＬＶ９００は、１２７の値によってＱＲｓｖレスポンスＴＬＶ９００がカスタムＴＬＶであることを示すタイプ・フィールド９００と、ＱＲｓｖレスポンスＴＬＶ９００の長さをオクテットで指定する長さフィールド９０２とを含むＴＬＶヘッダを含む。示されている例では、ＱＲｓｖレスポンスが、発信局に近いスイッチから生じ、発信局の統合データ・フローのためのＱＲｓｖのリクエストに応答するものである場合、長さフィールド９０２は、１８オクテットの長さを指定し、ＱＲｓｖレスポンスが、宛先局に近い遠端のスイッチから生じ、発信局の統合データ・フローのためのＱＲｓｖのリクエストに応答するものである場合、１４オクテットの長さを指定し、ＱＲｓｖレスポンスが、発信局に近いスイッチから生じ、発信局の複数のデータ・フローのうちの１つのためのＱＲｓｖのリクエストに応答するものである場合、３２オクテットの長さを指定し、ＱＲｓｖレスポンスが、宛先局に近い遠端のスイッチから生じ、発信局の複数のデータ・フローのうちの１つのためのＱＲｓｖのリクエストに応答するものである場合、３４オクテットの長さを指定する。
【００４５】
ＱＲｓｖレスポンスＴＬＶ９００はさらに、ＴＬＶを発行している組織を一意的に特定する組織固有識別子（ＯＵＩ）フィールド９０４、ＴＬＶの組織定義サブタイプを示す組織定義サブタイプ・フィールド９０６、および組織定義情報ストリング９０８を含むＴＬＶ情報ストリングを含む。組織定義サブタイプ・フィールド９０６の示されている例では、ＱＲｓｖレスポンスが、発信局に近いスイッチから生じ、発信局の統合データ・フローのためのＱＲｓｖのリクエストに応答するものである場合、２のサブタイプが指定され、ＱＲｓｖレスポンスが、宛先局に近い遠端のスイッチから生じ、発信局の統合データ・フローのためのＱＲｓｖのリクエストに応答するものである場合、５のサブタイプを指定し、ＱＲｓｖレスポンスが、発信局に近いスイッチから生じ、発信局の複数のデータ・フローのうちの１つのためのＱＲｓｖのリクエストに応答するものである場合、１２のサブタイプを指定し、ＱＲｓｖレスポンスが、宛先局に近い遠端のスイッチから生じ、発信局の複数のデータ・フローのうちの１つのためのＱＲｓｖのリクエストに応答するものである場合、１５のサブタイプを指定する。
【００４６】
示されている例では、組織定義情報ストリング９０８は、ＱＲｓｖレスポンスＴＬＶ９００を含むＬＬＤＰフレーム７００が、ＱＲｓｖレスポンスであることを示し、ＱＲｓｖが許可されるバイトおよびフレームの数（すなわちトラフィック・ボリューム）ならびにＱＲｓｖの満了タイマ値を指定する。ＱＲｓｖレスポンスＴＬＶ９００が、リクエストされたＱＲｓｖの拒否を示すよう意図される場合、組織定義情報ストリング９０８により指定されるバイトおよびフレームはゼロとなる。さらに、スイッチが、発信局の複数のデータ・フローのためのＱＲｓｖを別々に処理する場合、組織定義情報ストリング９０８は、発信局の複数のデータ・フローのうちのどれに関してＱＲｓｖが許可または拒否されるのかを一意的に特定する。
【００４７】
以下、図１０を参照する。一実施形態による、発信局のデータ・フローのためのエンド・ツー・エンドＱＲｓｖの設定をリクエストするために、ＬＬＤＰデータ・フレーム７００内でスイッチにより別のスイッチへ転送され得る例示のＱＲｓｖリクエストＴＬＶ１０００が示されている。ＱＲｓｖリクエストＴＬＶ１０００は、１２７の値によってＱＲｓｖリクエストＴＬＶ１０００がカスタムＴＬＶであることを示すタイプ・フィールド１０００と、ＱＲｓｖリクエストＴＬＶ１０００の長さをオクテットで指定する長さフィールド１００２とを含むＴＬＶヘッダを含む。示されている例では、長さフィールド１００２は、発信局と宛先局との間のデータ経路内のスイッチが、発信局のすべてのトラフィックを単一の統合データ・フローと見なす場合、１８オクテットの長さを指定し、発信局と宛先局との間のデータ経路内のスイッチが、発信局の複数のデータ・フローのうちの１つのための予約を個別に処理するようリクエストされる場合、３４オクテットの長さを指定する。
【００４８】
ＱＲｓｖリクエストＴＬＶ１０００はさらに、ＴＬＶを発行している組織を一意的に特定する組織固有識別子（ＯＵＩ）フィールド１００４、ＴＬＶの組織定義サブタイプを示す組織定義サブタイプ・フィールド１００６、および組織定義情報ストリング１００８を含むＴＬＶ情報ストリングを含む。組織定義サブタイプ・フィールド１００６の示されている例では、発信局の単一の統合データ・フローのためのエンド・ツー・エンドＱＲｓｖをリクエストするＱＲｓｖリクエストには、４のサブタイプが指定され、発信局の複数のデータ・フローのうちの１つのためのエンド・ツー・エンドＱＲｓｖをリクエストするＱＲｓｖリクエストには、１４のサブタイプが指定される。さらに、示されている例では、組織定義情報ストリング１００８は、ＱＲｓｖリクエストＴＬＶ１０００を含むＬＬＤＰフレーム７００がＱＲｓｖ許可であることを示し、ＱＲｓｖがリクエストされるバイトおよびフレームの数（すなわちトラフィック・ボリューム）、ならびにＱＲｓｖが提供される継続期間を指定する。ＱＲｓｖリクエストＴＬＶ１０００が、転送元のスイッチまたは前のスイッチによる、リクエストされたＱＲｓｖの拒否を示すよう意図される場合、組織定義情報ストリング１００８により指定されるバイトおよびフレームはゼロとなる。さらに、スイッチが、発信局の複数のデータ・フローのためのＱＲｓｖを別々に処理する場合、組織定義情報ストリング１００８は、発信局の複数のデータ・フローのうちのどれに関してＱＲｓｖが許可または拒否されるのかを一意的に特定する。
【００４９】
以下、図１１を参照する。一実施形態による、第２層でのＱＲｓｖの設定および利用の一例を示す時空図が示されている。示されている例では、ホスト１１００が、複数の第２層スイッチ１１０２を介して、宛先局１１０４へデータ・フレームを送信しようとしている。スイッチ１１０２ａ〜１１０２ｎは、発信局／ホストに最も近い近端のスイッチ１１０２ａと、宛先局１１０４に最も近い遠端のスイッチ１１０２ｎとを少なくとも含む。
【００５０】
処理は、ホスト１１００の発信局（例えばネットワーク・アダプタ、ネットワーク・アダプタのドライバ、オペレーティング・システムもしくはＶＭＭなどの制御プログラム、仮想マシンまたはアプリケーション・プログラム）が、例えばＱＲｓｖリクエストＴＬＶ８００を含むＬＬＤＰ７００などのＱＲｓｖリクエストを送信することで開始する。上記のように、ＱＲｓｖリクエスト１１１０は、ホスト１１００に最も近いスイッチ１１０２ａのみでのＱＲｓｖ、またはホスト１１００と宛先局１１０４との間のすべてのスイッチ１１０２ａ〜１１０２ｎでのエンド・ツー・エンドＱＲｓｖをリクエストすることができる。
【００５１】
ＱＲｓｖリクエスト１１１０が、スイッチ１１０２ａのみでのＱＲｓｖをリクエストすると、スイッチ１１０２ａは、リクエストされたＱＲｓｖを許可または拒否するＱＲｓｖレスポンス１１１６（例えば、ＱＲｓｖレスポンスＴＬＶ９００を備えるＬＬＤＰ７００）を用いてＱＲｓｖリクエスト１１１０に応答する。他方、ＱＲｓｖリクエスト１１１０が、ホスト１１００と宛先局１１０４との間のデータ経路内のすべてのスイッチ１１０２ａ〜１１０２ｎでのエンド・ツー・エンドＱＲｓｖをリクエストすると、ＱＲｓｖリクエスト１１１２（例えば、ＱＲｓｖリクエストＴＬＶ１０００を含むＬＬＤＰ７００）が、スイッチ１１０２ａおよびそれに続く各スイッチ１１０２によって、スイッチ１１０２ｎに達するまで転送される。この場合、スイッチ１１０２ｎは、ＱＲｓｖレスポンス１１１４（例えば、適切に構成されたＱＲｓｖレスポンスＴＬＶ９００を含むＬＬＤＰ７００）を用いてＱＲｓｖリクエスト１１１２に応答し、ＱＲｓｖレスポンス１１１４は、スイッチ１１０２ｎ〜１１０２ａによって転送され、ＱＲｓｖレスポンス１１１６としてホスト１１００に供給される。
【００５２】
続いて、ホスト１１００は、データ・フローのデータ・フレーム１１１８を、スイッチ１１０２ａ〜１１０２ｎを介して宛先局１１０４へ送信する。ＱＲｓｖリクエストが許可されたと仮定すると、少なくともスイッチ１１０２ａ（および場合によっては、スイッチ１１０２ａ〜１１０２ｎのすべて）が、ＱＲｓｖにおいて合意されたデータ転送速度、データ量および継続期間パラメータまで、データ・フロー内のデータ・フレームに対する保証されたサービスを提供する。したがって、例えば、スイッチ１１０２ａが、ホスト１１００が予約を有するポート上で、その予約が有効な間に、イングレス・キュー・オーバーラン状態に直面すると、スイッチ１１０２ａは、ホスト１１００の予約を遵守するために、データ・フレーム１１１８を維持し、ほかのフレームを破棄する。ＱＲｓｖが使い果たされた後、または満了した後、ＱＲｓｖリクエスト１１２４によって示されているように、ホスト１１００は再びデータ・フローのためのＱＲｓｖをリクエストしてもよい。
【００５３】
記載したとおり、一部の実施形態では、ネットワーク・スイッチは、第２層予約リクエストを発信局から受信するのに応じて、発信局のデータ・フローのために、ネットワーク・スイッチのイングレス・キューの容量に対する予約を設定する。発信局が、そのデータ・フローに関して、イングレス・キュー上のオーバーラン状態にかかわらずネットワーク・スイッチによる保証された転送を享受するように、予約が有効な間の、ネットワーク・スイッチのイングレス・キュー上のキュー・オーバーランに応答して、ネットワーク・スイッチは、予約に従い送信された発信局のデータ・フロー内のデータ・フレームを維持し、ほかのデータ・フレームを破棄する。様々な実施形態において、予約は、複数のデータ・フローのために発信局が設定する複数の予約のうちの１つであってもよい。さらに、予約は、発信局と宛先局との間のデータ経路内の複数のスイッチそれぞれにおいてリクエストおよび設定されてもよい。
【００５４】
１つ以上の好適な実施形態を参照して記載したように、本発明について詳しく示したが、当業者には当然のことながら、実施形態において、形態および細部における様々な変更が、本発明の意図および範囲から逸脱することなく加えられ得る。例えば、各側面は、本願明細書に記載された機能を命令するプログラム・コード（例えばソフトウェア、ファームウェアまたはその組み合わせ）を実行するホストおよびネットワーク・スイッチに関して記載されたが、当然のことながら、実施形態は代わりに、記載された機能の１つ以上をマシンに実行させるようマシンによって処理可能なプログラム・コードを記憶する有形のマシン可読ストレージ媒体またはストレージ・デバイス（例えば、光学式ストレージ媒体、メモリ・ストレージ媒体、ディスク・ストレージ媒体など）を含むプログラム製品として実装されてもよい。さらに、本発明は、物理ネットワーク・スイッチにおける第２層でのイングレス・キュー容量の予約に関して記載されたが、当然のことながら、示されたプロセスは、図３のＶＳ３３２などの仮想スイッチにおけるイングレス・キュー容量の予約にも同様に適用できる。
【図１】
0005497246.tif 000002
【図２】
0005497246.tif 000003
【図３】
0005497246.tif 000004
【図４】
0005497246.tif 000005
【図５】
0005497246.tif 000006
【図６】
0005497246.tif 000007
【図７】
0005497246.tif 000008
【図８】
0005497246.tif 000009
【図９】
0005497246.tif 000010
【図１０】
0005497246.tif 000011
【図１１】
0005497246.tif 000012