JP6287864B2 - ＱｏＳ制御システム、ＱｏＳ制御方法及びプログラム - Google Patents

Description

本発明は、日本国特許出願：特願２０１２−１４７３２７号（２０１２年６月２９日出願）の優先権主張に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。

本発明は、ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）制御システム、ＱｏＳ制御方法及びプログラムに関し、特に、Ｉ／Ｏ仮想化技術を使用可能なサーバ仮想化環境に好適なＱｏＳ制御システム、ＱｏＳ制御方法及びプログラムに関する。

近年、サーバの性能向上、信頼性向上により、サーバ資源の仮想化（サーバ仮想化）の導入がデータセンタなどで進んでいる。サーバ仮想化技術により、これまで個々の物理的なサーバで稼動させていたサービスを仮想マシン上で稼動させ、この仮想マシンを１台の物理的なサーバに収容することで、物理的なサーバの台数を削減することができる。これによって、サーバの導入コストや運用コストを削減することが可能となる。

図１５は、サーバ仮想化技術を導入する前のデータセンタのネットワークアーキテクチャの一例を示したものである。図１５によると、データセンタのネットワークは大きく分けて３層に分かれており、サーバ１０が接続されるＴｏｐ−ｏｆ−Ｒａｃｋスイッチ（ＴｏＲスイッチ）１２、ＴｏＲスイッチ１２同士を接続するアグリゲーションスイッチ１４、アグリゲーションスイッチ１４とデータセンタ外部のネットワークを接続するコアスイッチ１６から構成される。サーバ１０はネットワークインタフェースカード（ＮＩＣ）１８を介してＴｏＲスイッチ１２に接続される。

一方、図１６は、図１５の環境にサーバ仮想化技術を導入したネットワークアーキテクチャを示したものである。図１６によると、サーバ１０内に１つ以上の仮想マシン２０が稼動しており、仮想マシン２０は、仮想スイッチ２２を介して、サーバ１０外部のネットワークと接続される。仮想スイッチ２２はソフトウェアで実現されたスイッチであり、各仮想マシン２０とＮＩＣ１８とを接続し、仮想マシン２０に対して、サーバ１０内部の仮想マシン２０同士の通信、およびサーバ１０外部のネットワークへの接続を提供する。つまり、サーバ仮想化技術を導入したデータセンタでは、ＴｏＲスイッチ１２の先にさらにネットワークスイッチが接続されたアーキテクチャとなる。

サーバ仮想化環境では、仮想化のオーバヘッドが存在するため、仮想マシン２０に高い通信性能を提供することが難しいという課題がある。これを解決するために、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）やチップセット、ＮＩＣ１８がＩ／Ｏの仮想化をサポートするようになってきた。このような技術の例として、ＳＲ−ＩＯＶ（Ｓｉｎｇｌｅ Ｒｏｕｔｅ Ｉ／Ｏ Ｖｉｒｔｕａｌｉｚａｔｉｏｎ）やＩＯＭＭＵ（Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｍｅｍｏｒｙ Ｍａｎａｇｅｍｅｎｔ Ｕｎｉｔ）といったＩ／Ｏ仮想化技術が存在する。

このような技術を用いると、仮想マシン２０は仮想スイッチ２２を介さずに直接ＮＩＣ１８にアクセスすることが可能となり、仮想化のオーバヘッドをなくすことができる。結果として、仮想マシン２０に高い性能を提供することができる。

図１７は、Ｉ／Ｏ仮想化技術を用いたサーバ１０内のアーキテクチャを示したものである。図１７を参照すると、サーバ１０で稼動する仮想マシン２０のいくつかが仮想スイッチ２２を介さずに、直接ＮＩＣ１８に接続されている。仮想スイッチ２２は、サーバ仮想化環境では、一般的に仮想マシンモニタ２４、あるいはハイパーバイザーと呼ばれる、サーバ仮想化環境を管理する領域で稼動する。ＮＩＣ１８はＩ／Ｏ仮想化をサポートするために、複数のインタフェースを提供する。仮想マシンモニタ２４と接続するための物理インタフェース１８０と、仮想マシン２０と接続するための仮想インタフェース１８１を備え、仮想インタフェース１８１は１枚のＮＩＣ１８に対して、複数備えられる。図１７において、仮想マシン２０のうち、ＶＭ ａとＶＭ ｂが仮想インタフェース１８１を介して、直接ＮＩＣ１８に接続されている。

このようなデータセンタの利用方法の１つとして、ＩａａＳ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）が存在する。ＩａａＳでは、データセンタの物理資源をサーバ仮想化技術やＶＬＡＮ（Ｖｉｒｔｕａｌ ＬＡＮ）などの技術を用いて論理的に分割し、異なるユーザに計算機とネットワークの環境を提供する。例えば、計算機環境は仮想マシン２０の形で、ネットワークはＶＬＡＮの形で提供される。ユーザは提供された仮想マシン２０にＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）を導入し、ネットワークを介して、仮想マシン２０同士を通信させ、何らかのサービスを実現することが可能である。

ＩａａＳのような環境では、複数のユーザが同一の環境を利用するため、計算資源やネットワーク資源の適切な割り当てと、アイソレーションが重要である。例えば、ネットワーク資源であれば、ユーザごとのＱｏＳ制御を行うことで、あるユーザの通信が、別のユーザの通信に影響を与えないことが求められる。Ｉ／Ｏ仮想化技術を用いない場合、仮想スイッチ２２にて、ＱｏＳ制御を行うことができる。ＱｏＳ制御の一例として、ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）フレームに含まれるＣｏＳ（Ｃｌａｓｓ ｏｆ Ｓｅｒｖｉｃｅ）フィールドや、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）パケットのＴｏＳ（Ｔｙｐｅ ｏｆ Ｓｅｒｖｉｃｅ）フィールド、ＤＳＣＰ（ＤｉｆｆＳｅｒｖ Ｃｏｄｅ Ｐｏｉｎｔ）フィールドに設定された値に基づいて、フレームやパケットを優先度付けされた複数のキューに振り分ける方法が存在する。これらの値は、ＱｏＳ制御を行うネットワーク区間の入り口となるスイッチにて、ＩＰヘッダに含まれるＩＰアドレスなどの情報を元に設定される。この設定処理をマーキングと呼ぶ。スイッチはキューの優先度に基づいて、フレームやパケットの転送をスケジューリングしたり、リンク帯域を割り当てたりする。仮想スイッチ２２でマーキングを行うと、ＴｏＲスイッチ１２がマーキングの処理をサポートする必要がなくなるため、データセンタの構築コストを低減できるというメリットがある。

ところが、Ｉ／Ｏ仮想化技術を用いた場合、ＴｏＲスイッチ１２に、仮想スイッチ２２にて本来行われるはずだったＱｏＳ制御の設定がなされていないフレームやパケットが届くことになる。また、Ｉ／Ｏ仮想化技術を利用する仮想マシン２０（図１７のＶＭ ａ、ＶＭ ｂ）はＮＩＣ１８を介してパケットを直接ネットワークに送出することができるため、ユーザに都合の良いようにマーキングしたパケットを送信することが可能である。例えば、図１７のＶＭ ａのユーザが全てのパケットを最高の優先度を持つように設定することも可能である。パケットのフォーマット上は正常なパケットがサーバ１０から送出されるため、ＴｏＲスイッチ１２からすると、サーバ１０から送出されたパケットが仮想スイッチ２２を経由したものかどうかを判断できない。結果として、データセンタ管理者のＱｏＳポリシーに沿わないＱｏＳ制御が行われる可能性がある。

さらに、サーバ１０とＴｏＲスイッチ１２の間の物理リンクの帯域が、ユーザ間で適切に共有されない可能性がある。先に述べたように、Ｉ／Ｏ仮想化技術を用いると、仮想スイッチ２２が提供するＱｏＳ制御がきかなくなるため、Ｉ／Ｏ仮想化技術を利用する仮想マシン２０がリンクを占有することが可能となってしまう。

このような問題を解決するための技術の一例が、特許文献１に記載されている。特許文献１では、ユーザの仮想マシンとＩ／Ｏ仮想化をサポートしたＩ／Ｏアダプタの間に、仮想マシンのＩ／Ｏを制御するＩ／Ｏ論理パーティションが存在し、システム管理者が所定のポリシーに従ってＩ／Ｏ論理パーティションを制御することで、仮想マシンに適切なＩ／Ｏ制御を提供することができる。Ｉ／Ｏ論理パーティションはＩ／Ｏデバイスの仮想インタフェースと接続される。

また、前述の問題を解決するための技術の別の例が、特許文献２に記載されている。特許文献２では、ＮＩＣを仮想化し、複数の優先度付けされた仮想ネットワークデバイスとする技術が記載されている。トラフィックフローを優先度に基づいて各仮想ネットワークデバイスに割り当てることで、優先度の高いトラフィックフローが、優先度の低いトラフィックフローに影響されることを低減することができる。

特開２０１２−０７３６６０号公報 特開２０１０−２８３８２８号公報

以下の分析は、本発明によって与えられたものである。

上述した特許文献１に示される技術には、以下に示す問題点が存在する。すなわち、ユーザの仮想マシンと、Ｉ／Ｏデバイスとの間にＩ／Ｏを制御する管理領域が存在する、つまり、従来の仮想化環境で仮想マシンモニタを経由して通信を行うのと同等であるため、Ｉ／Ｏ仮想化をサポートすることのメリットである高い性能が得られない。

さらに、上述した特許文献２に示される技術には、以下に示す問題点が存在する。すなわち、本技術をサーバ仮想化環境に適用すると、各仮想マシンに複数の仮想ネットワークデバイスを割り当て、トラフィック単位に仮想ネットワークデバイスを使い分けることと等しくなる。各仮想ネットワークデバイスがＩ／Ｏ仮想化技術により、仮想マシンから直接のアクセスが可能になるとすると、仮想ネットワークデバイスの選択は仮想マシンに委ねられることになり、ユーザの都合に合わせて仮想ネットワークデバイスが使用されることとなる。結果として、ネットワークがシステム管理者のＱｏＳポリシーとは異なる形で利用されることになる。

先に述べたＩ／Ｏ仮想化技術を用いることで発生する２つの問題は、Ｉ／Ｏ仮想化技術により、複数の仮想マシン２０が、ＴｏＲスイッチ１２の各ポートに直接接続された状態となっているにもかかわらず、仮想マシン２０とＴｏＲスイッチ１２の間に、制御するポイントが存在しないことが原因である。これによって、仮想マシン２０の間で通信を調停することができなくなっている。ＴｏＲスイッチ１２の１つのポートに複数のサーバが接続される状況は、通常は起こりえないため、特許文献１、２等に記載された技術ではこれらの問題を解決できない。

本発明の目的は、Ｉ／Ｏ仮想化技術を使用可能なサーバ仮想化環境において、各仮想マシンがＩ／Ｏ仮想化技術を利用して通信を行う場合においても、システム管理者が定めるＱｏＳポリシーに従って、トラフィックのＱｏＳ制御が可能なＱｏＳ制御システム、ＱｏＳ制御方法及びプログラムを提供することにある。

本発明の第１の視点によれば、トラフィックを識別する識別情報と、当該トラフィックに属するパケットに適用する優先度値と、前記パケット内に前記優先度値を格納する位置を示す情報と、を定めたＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）パラメータを保持し、前記トラフィックに属するパケットに優先度値を格納してから送信するネットワークインタフェースと、各トラフィックに適用するＱｏＳパラメータを含んだＱｏＳポリシーを保持して、前記ネットワークインタフェースを管理するネットワークインタフェース管理部と、を含むこと、を特徴とする、ＱｏＳ制御システムが提供される。

本発明の第２の視点によれば、ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）ポリシーを参照して、ネットワークインタフェースに対して、トラフィックを識別する識別情報と、当該トラフィックに属するパケットに適用する優先度値と、前記パケット内に前記優先度値を格納する位置を示す情報と、を含むＱｏＳパラメータを通知するステップと、前記ネットワークインタフェースに、前記ＱｏＳパラメータを用いて、前記識別情報に適合するパケットに優先度値を格納してから送信させるステップと、を含むＱｏＳ制御方法が提供される。本方法は、送信パケットに優先度値を格納してから送信するコンピュータという、特定の機械に結びつけられている。

本発明の第３の視点によれば、ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）ポリシーを参照して、ネットワークインタフェースに対して、トラフィックを識別する識別情報と、当該トラフィックに属するパケットに適用する優先度値と、前記パケット内に前記優先度値を格納する位置を示す情報と、を含むＱｏＳパラメータを通知する処理をＱｏＳ制御システムを構成するコンピュータに実行させ、前記ネットワークインタフェースに、前記ＱｏＳパラメータを用いて、前記識別情報に適合するパケットに優先度値を格納してから送信させるプログラムが提供される。なお、このプログラムは、コンピュータが読み取り可能な（非トランジエントな）記憶媒体に記録することができる。即ち、本発明は、コンピュータプログラム製品として具現することも可能である。

本発明によれば、Ｉ／Ｏ仮想化技術を使用可能なサーバ仮想化環境において、各仮想マシンがＩ／Ｏ仮想化技術を利用して通信を行う場合におけるＱｏＳポリシーに従ったトラフィックのＱｏＳ制御が可能となる。

本発明の第１の実施形態に係るＱｏＳ制御システムの構成を示した図である。 本発明の第１の実施形態に係るＱｏＳ制御システムのパケット転送処理（ＮＩＣのフローテーブルに該当エントリが存在しない場合）を示したシーケンス図である。 本発明の第１の実施形態に係るＱｏＳ制御システムのパケット転送処理（ＮＩＣのフローテーブルに該当エントリが存在する場合）を示したシーケンス図である。 本発明の第１の実施形態に係るＱｏＳ制御システムのＮＩＣの動作を表したフローチャートである。 本発明の第１の実施形態に係るＱｏＳ制御システムの仮想マシンモニタの動作を表したフローチャートである。 本発明の第２の実施形態に係るＱｏＳ制御システムの構成を示した図である。 キューの優先度に基づいて優先度キューに格納されたパケットを送出する処理を示したフローチャートである。 本発明の第２の実施形態に係るＱｏＳ制御システムの変形構成（優先度キュー容量小）を示した図である。 図８の構成における優先度キューを用いたパケット送出処理を示したフローチャートである。 本発明の第３の実施形態に係るＱｏＳ制御システムの構成を示した図である。 本発明の第３の実施形態に係るＱｏＳ制御システムの動作（スレーブポリシーテーブルへのエントリ追加）を示したシーケンス図である。 本発明の第３の実施形態に係るＱｏＳ制御システムの別の動作（スレーブポリシーテーブルからのエントリ削除）を示したシーケンス図である。 本発明の第３の実施形態に係るＱｏＳ制御システムの仮想マシンのパケット送信要求の発行処理を示したシーケンス図である。 本発明の第３の実施形態に係るＱｏＳ制御システムの仮想マシン２０のパケット送信要求の発行処理を示したフローチャートである。 サーバ仮想化技術を導入する前のデータセンタのネットワークアーキテクチャの一例を示した図である。 図１５の環境にサーバ仮想化技術を導入したネットワークアーキテクチャを示した図である。 Ｉ／Ｏ仮想化サポート技術を用いたサーバ内のアーキテクチャを示した図である。

はじめに本発明の一実施形態の概要について図面を参照して説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、本発明を図示の態様に限定することを意図するものではない。

本発明は、その一実施形態において、ネットワークインタフェースカード上にＱｏＳパラメータを保持する手段（図１の１８５）と、パケットをホストメモリから取得する手段（図１の１８３）と、取得したパケットのパケットヘッダに対して、優先度値を格納してから送信する手段（図１の１８２）と、前記ネットワークインタフェースカードを管理する手段（図１の２４）とを備える構成にて実現できる。

より具体的には、ＱｏＳパラメータは、トラフィックを識別する識別情報と、当該トラフィックに属するパケットに適用する優先度値と、前記パケット内に前記優先度値を格納する位置を示す情報と、を含んでいる。前記ネットワークインタフェースカードを管理する手段は、このようなＱｏＳパラメータを含んだＱｏＳポリシー（図１の２４０）を保持している。前記ネットワークインタフェースカードを管理する手段は、ＱｏＳポリシーに基づいて、ＱｏＳパラメータを、ネットワークインタフェースカードに通知する。

ネットワークインタフェースカードは、仮想マシンから発行されるパケット送信要求を受けると、ホストメモリからパケットを取得する。次に、ネットワークインタフェースカードは、前記ネットワークインタフェースカードを管理する手段から通知されたＱｏＳパラメータを、前記取得したパケットのパケットヘッダの情報を用いて、前記ＱｏＳパラメータを保持する手段を参照することで取得し、ＱｏＳパラメータに含まれる優先度値を取得する。ネットワークインタフェースカードは、該パケットのパケットヘッダに前記取得した優先度値を格納してから送信する。なおここで、ＱｏＳパラメータを保持する手段が、ホストメモリから取得したパケットに適合するＱｏＳパラメータを保持していない場合、ネットワークインタフェースカードは、前記ネットワークインタフェースカードを管理する手段に対し、適切な前記ＱｏＳパラメータを問い合わせて、適切な前記ＱｏＳパラメータを取得する。このようにして、ネットワークインタフェースカードに設定された優先度値が送信パケットに適用される。

以上のように、Ｉ／Ｏ仮想化技術を用いて、仮想マシンがネットワークインタフェースカードに対して直接、パケットの送信要求を発行し、パケットを送信できるような環境においても、システム管理者のＱｏＳポリシーが適用されて、パケットが送信されるようになる。その理由は、ネットワークインタフェースカードが、パケット送信要求に従って取得したパケットのヘッダ情報を元にして、ＱｏＳパラメータが格納されたテーブルを参照し、システム管理者のポリシーに従ったＱｏＳパラメータをパケットヘッダに適用するよう構成したためである。
［第１の実施形態］
続いて、本発明の第１の実施形態について図面を参照して詳細に説明する。なお、以下の説明では、ネットワークに転送するデータの単位を「パケット」に統一して表記するが、このことは、本技術が適用されるネットワークの種類等を制限するものではない。また、以降、「フロー」とも呼ばれる一連のパケット列を「トラフィック」と表記する。例えば、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）によって、あるファイルをダウンロードする際に、ファイルのダウンロード開始から完了までに流れたパケットをまとめてトラフィックとする。

図１は、本発明の第１の実施形態に係るＱｏＳ制御システムの構成を示した図である。図１を参照すると、ＮＩＣ１８Ｔ−１と、仮想マシン（ＶＭ）２０と、仮想マシンモニタ（ＶＭＭ）２４と、を含んだＱｏＳ制御システム１０ａが示されている。仮想マシン２０と、仮想マシンモニタ２４とは、サーバ１０の環境下で動作するコンピュータプログラムである。いずれもＱｏＳ制御システム１０ａを構成するサーバ等のＣＰＵ、メモリ、ディスク、Ｉ／Ｏといった各種資源を利用して実現される。以降、ＱｏＳ制御システム１０ａを構成するサーバ等のメモリを「ホストメモリ」と表記する。

ＮＩＣ１８Ｔ−１は、ＮＩＣ１８の送信側の構成を示したものであり、物理インタフェース１８０と、仮想インタフェース１８１と、ＴＸコントローラ（ＴＸ Ｃｔｒｌ）１８２と、ＤＭＡコントローラ（ＤＭＡＣ）１８３と、ホストバスインタフェース（Ｈｏｓｔ Ｂｕｓ Ｉ／Ｆ）１８４と、フローテーブル１８５と、ＴＸインタフェース（ＴＸ Ｉ／Ｆ）１８８と、を含んでいる。

物理インタフェース１８０は、Ｉ／Ｏ仮想化技術における、仮想マシンモニタ２４に対するインタフェースであり、ＮＩＣ１８Ｔ−１の動作を制御するためのインタフェースを備える。例えば、フローテーブル１８５に設定するエントリを通知する、仮想インタフェース１８１のステータスの読み出し、などが挙げられる。物理インタフェース１８０の実装例としては、ＳＲ−ＩＯＶのフィジカルファンクションが挙げられる。ＳＲ−ＩＯＶにおいて、フィジカルファンクションはＰＣＩ−Ｅｘｐｒｅｓｓのインタフェースが提供する一般的な機能を全て備える。

仮想インタフェース１８１は、仮想マシン２０がＩ／Ｏ仮想化技術を用いてＮＩＣ１８Ｔ−１に直接アクセスするためのインタフェースである。仮想インタフェース１８１の実装例としては、ＳＲ−ＩＯＶのバーチャルファンクションが挙げられる。ＳＲ−ＩＯＶにおいて、バーチャルファンクションはフィジカルファンクションの一部のリソースのみを利用して実現される。

仮想マシン２０は、仮想インタフェース１８１を通じてパケット送信要求をＮＩＣ１８Ｔ−１に発行する。パケット送信要求には、少なくとも送信パケットサイズと、送信パケットが格納されたホストメモリのアドレスと、が含まれる。場合によっては、送信パケットがホストメモリ上で連続な領域に格納されていない場合がある。この場合は、パケット送信要求に、サイズとアドレスをリストとして、複数個含めるが、本発明に本質的な差異を与えないため、ホストメモリ上の連続した領域にパケットが格納されているとして説明する。

ＴＸコントローラ１８２は、ＮＩＣ１８Ｔ−１のパケット送信処理を制御するコントローラである。ＴＸコントローラ１８２は、内部にパケットバッファを備え、一定数のパケットを保持できることが望ましい。ＴＸコントローラ１８２は、仮想インタフェース１８１から発行されるパケット送信要求から、送信パケットサイズ、送信パケットが格納されたホストメモリのアドレスを取得し、ＤＭＡコントローラ１８３に対して送信パケットの読み出し要求を発行する。続いて、読み出されたパケットに対して、ＱｏＳにおける優先度を示す値（以降、優先度値と表記する）をセット（マーキング）し、ＴＸインタフェース１８８にパケットを転送する。

フローテーブル１８５は、送信パケットに対して設定するＱｏＳのパラメータを保持するテーブルである。ＱｏＳのパラメータとして、少なくとも、優先度値をパケットヘッダのどのフィールドにセットするかを示す情報と、セットする優先度値が含まれる。例えば、ＣｏＳフィールド／ＴｏＳフィールド／ＤＳＣＰフィールドのいずれかを指定する値と、指定されたフィールドにセットする優先度値と、がＱｏＳのパラメータに少なくとも含まれる。また、Ｃｉｓｃｏ Ｓｙｓｔｅｍｓ社が実装するＩＳＬ（Ｉｎｔｅｒ Ｓｗｉｔｃｈ Ｌｉｎｋ）方式のように、ベンダ独自の方式でトラフィックの優先度付けを可能にしている場合もあるため、例えば、パケットヘッダの先頭からのバイト数／ビット数と、セットする優先度値、セットする優先度値のサイズ（バイト数／ビット数）をフローテーブルに保持することも考えられる。このことは、ＮＩＣ１８Ｔ−１がサポートする機能に依存する話であるが、本実施の形態に実質的な差異を与えない。

フローテーブル１８５の各エントリは、ＱｏＳのパラメータを検索するキーとして、パケットのヘッダ情報に含まれる、トラフィックの識別情報を、ＱｏＳのパラメータと対応付けて保持する。トラフィックの識別情報として、パケットヘッダに含まれるＩＰアドレスやＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）やＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）のポート番号、などが挙げられる。

フローテーブル１８５は、例えば、ＴＣＡＭ（Ｔｅｒｎａｒｙ Ｃｏｎｔｅｎｔ Ａｄｄｒｅｓｓａｂｌｅ Ｍｅｍｏｒｙ）のような形で実現することができる。

ＴＸコントローラ１８２は、取得したパケットのヘッダの情報を用いて、フローテーブル１８５を参照し、パケットにセットする優先度値を取得する。ＴＸコントローラ１８２は、取得した優先度値を用いて、パケットに対してマーキングを行い、ＴＸインタフェース１８８にパケットを転送する。

ネットワークによっては、パケットにエラー検出用のデータが付与されている場合がある。例えば、イーサネット（登録商標）においては、パケットの末尾にＦＣＳ（Ｆｒａｍｅ Ｃｈｅｃｋ Ｓｅｑｕｅｎｃｅ）が付与されており、パケットの宛先ＭＡＣアドレスから、ペイロード部の末尾までのデータを用いてＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）値を計算した結果が付与される。マーキングを行うと、パケットの内容が書き換わるため、ＴＸコントローラ１８２にて、エラー検出用のデータの再計算を行い、パケットの適切なフィールドに適用することが望ましい。

フローテーブル１８５に、該当するエントリが存在しない場合、ＴＸコントローラ１８２は、物理インタフェース１８０を通じて、仮想マシンモニタ２４に対して、このパケットに適用するＱｏＳパラメータの問い合わせを行う。この問い合わせには、パケットヘッダの情報のうち、フローテーブル１８５に登録可能な情報（上記トラフィックの識別情報として用いる情報）が含まれる。例えば、ＴＸコントローラ１８２は、ホスト側のＣＰＵに対する割り込みといった形で、仮想マシンモニタ２４に対して、問い合わせを行ったことを示す通知を行う。

ＤＭＡコントローラ１８３は、ＴＸコントローラ１８２からの要求に従って、ホストバスデータインタフェース１８４を通じて、メモリに格納されたデータを読み出す処理を行う。

ホストバスインタフェース１８４は、サーバ１０と、ＮＩＣ１８Ｔ−１とを接続するデータバスとのインタフェースであり、例えば、ＰＣＩ−Ｅｘｐｒｅｓｓにおいて、ＤＭＡ転送用のコマンド発行のためのインタフェースや、ホスト側から転送されてきたデータを格納するレジスタなどが該当する。

ＴＸインタフェース１８８は、ＮＩＣ１８Ｔ−１のネットワークへの物理的なインタフェースであり、ＴＸコントローラ１８２から受け取ったパケットをネットワークに送出する。その際に、ＴｏＲスイッチ１２がパケットの始まりを検出するための信号をパケットの前に付加するなどの処理を行う。例えば、ネットワークがイーサネットであれば、プリアンブル部がそれにあたる。

仮想マシン２０は、システムの管理者からアサインされたサーバ１０の資源（ＣＰＵやメモリ、ディスク、Ｉ／Ｏインタフェースなど）を用いて、ユーザがアプリケーションを動かすことのできる、仮想的な計算機である。一般に、ＩａａＳ環境では、ユーザは自身でＯＳを用意し、仮想マシン２０に導入することで、アプリケーションの実行環境を用意する。

仮想マシンモニタ２４は、仮想スイッチ２２のほか、ポリシーテーブル２４０が備えられる。仮想マシンモニタ２４は、ＮＩＣ１８Ｔ−１からの問い合わせに応じて、ポリシーテーブル２４０の内容を参照し、適切なＱｏＳパラメータを選択し、ＮＩＣ１８Ｔ−１に通知する。

ポリシーテーブル２４０には、ネットワーク管理者が定めた、トラフィックに対するプライオリティのポリシーが格納される。ポリシーの例として、パケットのＩＰアドレスや、ＴＣＰ／ＵＤＰのポート番号のような、トラフィックを識別する情報と、そのトラフィックの優先度値と、その優先度値をセットするパケットの位置を示す情報と、から構成する方式が考えられる。この場合、ポリシーテーブル２４０は、フローテーブル１８５のスーパーセットとなる。別のポリシーの例として、優先度値に、ＣｏＳやＴｏＳなどの特定の優先度付けを行うための方式と非依存な値を保持するということも考えられる。この場合、ポリシーテーブル２４０を参照して得られた優先度値を、実際に使用するＱｏＳ制御の方式に合った設定に変換する処理が必要である。例えば、ポリシーテーブル２４０に、優先度を０〜６３の６４段階（＝６ビット）で保持するとし、ネットワーク側で使用するＱｏＳ制御の仕組みがＴｏＳである場合、ＴｏＳの優先度は８段階であるため、｛ポリシーテーブル２４０の値、ＴｏＳの優先度｝＝｛０〜７、０｝｛８〜１５、１｝｛１６〜２３、２｝｛２４〜３１、３｝｛３２〜３９、４｝｛４０〜４７、５｝｛４８〜５５、６｝｛５６〜６３、７｝のように対応させる。

ＴＸコントローラ１８２は、フローテーブル１８５に該当するエントリが存在しないパケットを扱う場合に、仮想マシンモニタ２４に対し、パケットに適用するＱｏＳパラメータを問い合わせる。仮想マシンモニタ２４が、ポリシーテーブル２４０を参照し、設定するＱｏＳパラメータをＴＸコントローラ１８２に通知すると、ＴＸコントローラ１８２は、通知されたＱｏＳパラメータをフローテーブル１８５に登録する。また、以後、ＴＸコントローラ１８２は、通知されたＱｏＳパラメータに含まれる優先度値を、対象のパケットに適用する。この通知は、物理インタフェース１８０のレジスタを介して行うことが例として考えられる。つまり、仮想マシンモニタ２４が、物理インタフェース１８０の特定のレジスタにＱｏＳパラメータを書き込むことで、ＴＸコントローラ１８２にトリガがかかり、ＱｏＳパラメータのフローテーブル１８５への登録と、パケットへの適用が行われるように実現することが考えられる。このような仕組みを用いると、仮想マシンモニタ２４が、事前にフローテーブル１８５にフローエントリを登録しておくことも可能である。例えば、通信頻度の高いトラフィックに対するポリシーをあらかじめフローテーブル１８５に登録しておくことで、仮想マシンモニタ２４への問い合わせを削減することができる。

次に、図２、図３のシーケンス図、図４、図５のフローチャートを参照して、本実施形態の全体の動作について詳細に説明する。

図２は、本発明の第１の実施形態に係るＱｏＳ制御システムのパケット転送処理（ＮＩＣのフローテーブルに該当エントリが存在しない場合）を示したシーケンス図である。具体的には、図２は、仮想マシン２０がパケットの送信要求を発行したものの、ＮＩＣ１８Ｔ−１のフローテーブル１８５に、送信するパケットに該当するエントリが存在しない場合のパケット転送処理を示している。

まず、仮想マシン２０が、仮想インタフェース１８１を通じて、パケットの送信要求をＮＩＣ１８Ｔ−１に発行する（図２のステップＳ２００）。送信要求には、少なくとも転送するパケットのサイズと、そのパケットが格納されたホストメモリのアドレスが含まれている。発行されたパケット送信要求はＮＩＣ１８Ｔ−１に備えられるＴＸコントローラ１８２で解釈される。

次に、ＴＸコントローラ１８２は、仮想マシン２０からパケット送信要求を受け取ると、パケット送信要求に含まれるパケットのサイズと、メモリアドレスと、の情報を用いて、ＤＭＡコントローラ１８３に対し、パケットの読み出し要求を発行し、パケットを取得する（図２のステップＳ１８２）。取得したパケットは、ＴＸコントローラ１８２が備えるパケットバッファに格納される。

次に、ＴＸコントローラ１８２は、フローテーブル１８５から、取得したパケットのヘッダ情報に適合するトラフィック識別情報を持つエントリを検索する。この検索の結果、該当するエントリが存在しないことが分かると、ＴＸコントローラ１８２は、仮想マシンモニタ２４に対し、物理インタフェース１８０を通じて、このパケットに適用するＱｏＳパラメータの問い合わせを行う（図２のステップＳ１８５）。この問い合わせには、少なくともパケットヘッダのフィールドのうち、フローテーブル１８５を検索する際に用いることができるキーと同じフィールドの情報、即ち、上記トラフィックの識別情報として用いる情報が含まれる。

次に、仮想マシンモニタ２４は、ＮＩＣ１８Ｔ−１からＱｏＳパラメータの問い合わせがあると、問い合わせに含まれるパケットヘッダの情報を用いて、ポリシーテーブル２４０を参照し、このパケットに適用するＱｏＳパラメータを取得する（図２のステップＳ２４０）。先に述べたように、ポリシーテーブル２４０に保持されているポリシーが、特定の優先度付けを行うための方式と非依存である場合、ポリシーテーブル２４０から取得したポリシーを、ネットワーク側で使用する優先度付けの方式に対応させる処理を実行する。

次に、仮想マシンモニタ２４は、物理インタフェース１８０を通じてＮＩＣ１８−Ｔ１に対して、取得したＱｏＳパラメータを通知する（図２のステップＳ２４２）。

次に、ＴＸコントローラ１８２は、仮想マシンモニタ２４から通知されたＱｏＳパラメータをフローテーブル１８５に登録する（図２のステップＳ１８６）。

次に、ＴＸコントローラ１８２は、取得したＱｏＳパラメータに含まれる優先度値をパケットヘッダに適用する（図２のステップＳ１８７）。このときに、ＴＸコントローラ１８２にて、パケットのエラー検出用のデータの再計算を行い、パケットの該当するフィールドに適用する。

次に、ＴＸコントローラ１８２は、優先度値をセットしたパケットをＴＸインタフェース１８８に転送し、ネットワークにパケットを送出する（図２のステップＳ１８８）。

なお、図２のステップＳ１８６と、図２のステップＳ１８７〜ステップＳ１８８の処理に依存は無いため、処理手順が入れ替わっても良い。つまり、図２のステップＳ１８７〜ステップＳ１８８の処理を実行した後に、図２のステップＳ１８６の処理時を実行することも、同時に実行することも可能である。

ここで、ＴＸコントローラ１８２が、パケット全体を保持するバッファを備えない場合について、動作を説明する。この場合、図２のステップＳ１８２でパケット全体を読み出したとしても、図２のステップＳ１８５〜ステップＳ１８６のＱｏＳパラメータを問い合わせている間、パケットのパケットヘッダ以降の領域（ペイロード部）を保持できないため、破棄することになる。結果として、ＱｏＳ制御システム１０ａを構成するサーバのＰＣＩ−Ｅｘｐｒｅｓｓなどの内部バス帯域を無駄に使用してしまうことになる。

この場合、まず、ＴＸコントローラ１８２は、図２のステップＳ１８２において、ＤＭＡコントローラ１８３に対してパケットヘッダのみを読み出す要求を発行し、送信するパケットのパケットヘッダを取得する。この場合、パケットヘッダのサイズが事前に明らかな場合は、そのサイズを利用することが可能であるが、パケットヘッダのサイズが可変である場合には、パケットの先頭から、固定値でデータサイズを指定することが考えられる。

以降の図２のステップＳ１８５〜ステップＳ１８７の処理は、ＴＸコントローラ１８２が、パケット全体を保持するバッファを備える場合と同一である。その後、ステップＳ１８８の処理を実行する際に、ＴＸコントローラ１８２は、再度ＤＭＡコントローラ１８３に、パケットのペイロード部の読み出し要求を発行し、図２のステップＳ１８７でＱｏＳパラメータを適用したパケットヘッダの後続にペイロード部を付加して、パケットを送信する。この場合、パケットのエラー検出のためのデータを計算し、パケットに適用するのは、パケットのペイロード部を読み出したあととなる。

以上の動作により、仮想マシン２０から発行されたパケット送信要求に従って、ＮＩＣ１８Ｔ−１にてパケットに対して、優先度付けを行い、ネットワークにパケットが送出された。

図３は、本発明の第１の実施形態に係るＱｏＳ制御システムのパケット転送処理（ＮＩＣのフローテーブルに該当エントリが存在する場合）を示したシーケンス図である。より具体的には、図３は、仮想マシン２０がパケットの送信要求を発行し、ＮＩＣ１８Ｔ−１のフローテーブル１８５に、送信するパケットに該当するエントリが存在する場合のパケット転送処理を示している。なお、図２と同様の処理については同一の符号を付し、詳細な説明を省略する。

ＴＸコントローラ１８２は、仮想マシン２０からパケットの送信要求を受けると、ＤＭＡコントローラ１８３経由で送信するパケットのパケットヘッダを取得する（図３のステップＳ２００〜ステップＳ１８２）。そして、ＴＸコントローラ１８２は、パケットヘッダの情報を用いてフローテーブル１８５を参照し、パケットに適用する優先度値を取得する（図３のステップＳ１８４）。

以下図２と同様に図３のステップＳ１８７において優先度値を設定されたパケットは、ネットワークに送出される（図３のステップＳ１８８）。

図４は、図２、図３のシーケンス図における、ＴＸコントローラ１８２の処理を詳細に示したフローチャートである。

まず、ＴＸコントローラ１８２は、仮想マシン２０からパケット送信要求が発行されると（図４のステップＦ１８０のＹｅｓ）、パケット送信要求に含まれる、送信パケットが格納されたホストメモリのアドレスと、送信するパケットのサイズの情報を用いて、ＤＭＡコントローラ１８３に対し、パケットの読み出し要求を発行する（図４のステップＦ１８２）。ＴＸコントローラ１８２は、仮想マシン２０からパケット送信要求が発行されていない場合（図４のステップＦ１８０のＮｏ）、処理を開始しない。

次に、ＴＸコントローラ１８２は、フローテーブル１８５から、前記取得したパケットのヘッダ情報に適合するトラフィック識別情報を持つエントリを検索する（図４のステップＦ１８３）。

フローテーブル１８５に該当エントリが存在する場合（図４のステップＦ１８３の「エントリが存在する」）、ＴＸコントローラ１８２は、フローテーブル１８５の該当エントリから、パケットに適用する優先度値を取得する（図４のステップＦ１８４）。

一方、フローテーブル１８５にエントリが存在しない場合（図４のステップＦ１８３の「エントリが存在しない」）、ＴＸコントローラ１８２は、物理インタフェース１８０を通じて、仮想マシンモニタ２４に対して、ＱｏＳパラメータを問い合わせる（図４のステップＦ１８５）。

次に、ＴＸコントローラ１８２は、仮想マシンモニタ２４から、ＱｏＳパラメータの通知がなされると（図４のステップＦ１８６のＹｅｓ）、取得したＱｏＳパラメータをフローテーブル１８５に登録する（図４のステップＦ１８７）。一方、仮想マシンモニタ２４から、ＱｏＳパラメータの通知がなされていない場合（図４のステップＦ１８６のＮｏ）には、ＴＸコントローラ１８２は、仮想マシンモニタ２４からの通知を待つ。

次に、ＴＸコントローラ１８２は、取得した優先度値をパケットヘッダに適用する（図４のステップＦ１８８）。このときに、ＴＸコントローラ１８２は、パケットのエラー検出のためのデータを計算し、パケットに適用する。

次に、ＴＸコントローラ１８２は、優先度値を設定したパケットを、ＴＸインタフェースを通じてネットワークに送出する（図４のステップＦ１８９）。

このようにして、ＴＸコントローラ１８２は、パケットに優先度付けをして、ネットワークにパケットを送出する。

図５は、図２のシーケンス図における、仮想マシンモニタ２４の動作を詳細に示したフローチャートである。

まず、仮想マシンモニタ２４は、ＮＩＣ１８Ｔ−１からＱｏＳパラメータの問い合わせを受けると（図５のステップＦ２３８のＹｅｓ）、ＮＩＣ１８Ｔ−１からの問い合わせに応じて、ポリシーテーブル２４０を参照し、該当するＱｏＳパラメータを取得する（図５のステップＦ２４０）。なお、ＮＩＣ１８Ｔ−１からＱｏＳパラメータの問い合わせがない場合、仮想マシンモニタ２４は、処理を開始しない（図５のステップＦ２３８のＮｏ）。

次に、仮想マシンモニタ２４は、取得したＱｏＳパラメータを、物理インタフェース１８０を通じて、ＮＩＣ１８Ｔ−１に通知する（図５のステップＦ２４２）。

このようにして、仮想マシンモニタ２４は、ＴＸコントローラ１８２からの問い合わせに応じて、ＱｏＳパラメータを通知する。

ここで、仮想マシンモニタ２４に内蔵される仮想スイッチ２２に接続された仮想マシン２０（例えば、図１７のＶＭ ｃ、及びＶＭ ｄ）が、ＱｏＳ制御システム１０ａに配置されている場合の、ＮＩＣ１８Ｔ−１の処理について説明する。

仮想スイッチ２２に接続された仮想マシン２０が送信するパケットについては、仮想スイッチ２２において、ポリシーテーブル２４０を参照することで、優先度値を設定することが可能である。

また、一般に、Ｉ／Ｏ仮想化に対応したＮＩＣ１８は、物理インタフェース１８０と、各仮想インタフェース１８１とを、固有のＩＤを用いて識別可能である。

仮想スイッチ２２から、ＮＩＣ１８Ｔ−１に対して、パケットを送信する際には、仮想スイッチ２２が、ＮＩＣ１８Ｔ−１に対してパケット送信要求を発行する。

そのため、仮想スイッチ２２から物理インタフェース１８０を通じて発行された送信要求については、送信対象のパケットに、システム管理者のポリシーに基づいた優先度値の設定がなされているとし、ＴＸコントローラ１８２は、図４に示したような処理を行わずに、パケット送信要求に含まれる転送サイズと、アドレスに基づいて、ＤＭＡコントローラ１８３がホストメモリから読み出したパケットを、そのままネットワークに送出することが可能である。

一方で、仮想マシンモニタ２４の負荷が上昇すると、優先度値の設定を行うオーバヘッドにより、仮想スイッチ２２に接続された仮想マシン２０に係る通信の性能が劣化する可能性がある。

このような場合に、優先度値の付加を、仮想スイッチ２２で行わず、ＮＩＣ１８Ｔ−１で行うように、ＮＩＣ１８Ｔ−１の動作を切り替えることが考えられる。

例えば、ＮＩＣ１８Ｔ−１に、物理インタフェース１８０から送信されたパケットに対して、優先度値の付加を行うかどうかを切り替えることができる設定レジスタを設ける。この設定レジスタに対する設定は、物理インタフェース１８０を介して、仮想マシンモニタ２４から行うことができる。

ＣＰＵ使用率などの情報から、仮想マシンモニタ２４の負荷が上昇したと仮想マシンモニタ２４が判断した場合に、仮想マシンモニタ２４から、この設定レジスタの設定を行うことで、ＮＩＣ１８Ｔ−１側でパケットに対する優先度値の付加を行うようにすることが可能となる。この場合、仮想スイッチ２２からのパケット送信要求に対して、ＮＩＣ１８Ｔ−１が図４で示したような処理を実行することで、優先度が付与されたパケットがネットワークに送出されることになる。

また、あるいは、仮想マシンモニタ２４と、ＮＩＣ１８−Ｔ１の間のインタフェースを複数設ける、あるいは物理インタフェース１８０に、パケット送信要求を書き込むレジスタを複数設けることで、優先度値の付加を仮想スイッチ２２で行うか、ＮＩＣ１８Ｔ−１で行うかを使い分けることができる。

例えば、仮想マシンモニタ２４とＮＩＣ１８−Ｔ１の間のインタフェースとして、物理インタフェース１８０に加えて、仮想インタフェース１８１を割り当て、優先度値の付加を仮想スイッチ２２で行う場合は、パケット送信要求を物理インタフェース１８０に対して、優先度値の付加をＮＩＣ１８−Ｔ１で行う場合は、パケット送信要求を仮想インタフェース１８１に対して発行する。あるいは、物理インタフェース１８０に、パケット送信要求を書き込むレジスタが複数設けられている場合も同様に、パケット送信要求を発行するレジスタを、優先度値の付加を仮想スイッチ２２で行うかどうかに応じて使い分ける。

このようにすることで、仮想マシンモニタ２４の負荷が上昇した際に、その上昇の原因となったトラフィックに対してのみ、このトラフィックに属するパケットに対する優先度値の付加をＮＩＣ１８−Ｔ１に行わせるように制御することも可能となる。この場合、単位時間当たりに仮想スイッチ２２を通過したパケット数や、データサイズをモニタすることで、負荷が上昇した原因のトラフィックを特定することが可能である。

以上説明したように、本実施形態では、ＮＩＣ１８Ｔ−１は、フローテーブル１８５に登録されたＱｏＳパラメータに従って、Ｉ／Ｏ仮想化技術を用いて送信されるパケットに対して優先度値をセットする。このＱｏＳパラメータは、システム管理者のポリシーに従って、仮想マシンモニタ２４からの指示によって、フローテーブル１８５にセット、あるいは送信パケットに適用されるものである。このため、Ｉ／Ｏ仮想化技術を用いて高い性能を実現でき、さらに、仮想マシン２０のユーザが設定した優先度値がネットワークでの優先度制御に用いられることを防ぐことができる。
［第２の実施形態］
次に、本発明の第２の実施形態について図面を参照して詳細に説明する。図６は、本発明の第２の実施の形態に係るＱｏＳ制御システム１０ｂの構成を示した図である。図６を参照すると、本発明の第２の実施形態は、図１に示した本発明の第１の実施形態の構成に、優先度キュー１８６と、スケジューラ１８７とが追加され、フローテーブル１８５−２と、ポリシーテーブル２４０−２とに変更が加えられている。その他本発明の第１の実施形態と同様の構成要素については同一の符号を付し、詳細な説明を省略する。

優先度キュー１８６は、互いに異なる優先度を持った複数のキューから構成される。各キューは１段以上の深さを持ち、キューの各段は、ＴＸコントローラ１８２が優先度値をセットしたパケットを格納できる領域を持つ。優先度キュー１８６に含まれるキューの個数は、一般的なデータセンタ向けネットワークスイッチがサポートする、ポートごとのＱｏＳ用の優先度キューの個数と同等が望ましいが、ＮＩＣ１８Ｔ−２の実装コストなどの要因により、それよりも少なくなることも考えられる。少なくとも、優先度キュー１８６を構成するキューの個数や、各キューのＮＩＣ１８Ｔ−２内での優先度は、物理インタフェース１８０を通じて、仮想マシンモニタ２４が知ることができる。

フローテーブル１８５−２は、送信パケットに対して設定するパラメータを保持するテーブルである。各エントリには、ＱｏＳのパラメータとして、第１の実施形態のフローテーブル１８５が保持するパラメータに加えて、優先度キュー１８６のどのキューに格納するかを示す、キューの識別情報が含まれる。

スケジューラ１８７は、優先度キュー１８６に格納されたパケットを、パケットが格納されているキューの優先度に従って、ネットワークに送出する。パケットを送出するスケジューリング方式として、優先度の高いキューが空になるまで、優先度の低いキューのパケットを送出しない方式や、キューの優先度に基づいた重み付けをし、重み付けの比率に基づいてパケットを各キューから送出する方式、などが考えられる。どのようなスケジューリング方式を用いているか、複数のスケジューリング方式をサポートする場合、どれを使用するかは、物理インタフェース１８０を通じて、仮想マシンモニタが検知・指定することができる。

ポリシーテーブル２４０−２には、ネットワーク管理者が定めた、トラフィックに対するＱｏＳポリシーが格納される。ＱｏＳポリシーを構成する情報として、第１の実施形態のポリシーテーブル２４０に登録する情報に加えて、優先度キュー１８６のどのキューに格納するかを示す、キューの識別情報が含まれる。

次に、図７のフローチャートを参照して、本実施形態の動作について詳細に説明する。

図７は、ＮＩＣ１８Ｔ−２が、優先度キュー１８６に格納されたパケットを、キューの優先度に基づいてパケットを送出する処理を示したフローチャートである。本実施形態において、ＮＩＣ１８Ｔ−２は、図４のステップＦ１８８までの処理を実行した上で、図７に示す処理を行う。図７のステップＦ１８８までの処理は、本実施の第１の実施形態と同様（図４参照）であるため、詳細な説明を省略する。

まず、ＴＸコントローラ１８２は、優先度値をセットしたパケットを、その優先度値に基づいて、優先度キュー１８６の対応するキューに格納する（図７のステップＦ１８８０）。パケットにセットされる優先度値が表現することのできる優先度の高低が、優先度キュー１８６を構成するキューの個数で表現することのできる優先度の高低よりも広い場合、複数の優先度値をまとめて、１つのキューに対応させることが考えられる。例えば、パケットヘッダの優先度値を示すフィールドの上位数ビットの値を元に、各キューに割り振ることができる。

次に、スケジューラ１８７は、キューの優先度に基づいて、キューに格納されたパケットを、ＴＸインタフェース１８８に転送する。ＴＸインタフェース１８８は、ネットワークに前記転送されたパケットを送出する（図７のステップＦ１８８２）。

このようにして、ＮＩＣ１８Ｔ−２は、パケットの優先度に基づいて、パケットをネットワークに送出する。

本実施形態では、パケットのエラー検出のためのデータを計算し、パケットに適用する処理は種々のタイミングで実行することができる。例えば、ＴＸコントローラ１８２が図４のステップＦ１８８の時点で、パケットのエラー検出のためのデータの計算と適用を行うこととしてもよいし、スケジューラ１８８が、図７のステップＦ１８８２の時点で、前記パケットのエラー検出のためのデータの計算と適用を行うこととしてもよい。

ここで、優先度キュー１８６に、パケット全体を保持するだけの容量が備えられていない場合について図面を用いて説明する。本実施形態では、パケットがいつ送信されるかは、パケットが格納された優先度キュー１８６を構成するキューの優先度に依存する。キューの各段にパケット全体を保持するだけの容量が備えられていない場合、図４のステップＦ１８２でパケット全体を読み出したとしても、パケットのペイロード部はＮＩＣ１８Ｔ−２で破棄されることになる。

図８は、優先度キュー１８６に、パケット全体を保持するだけの容量が備えられていない場合のＱｏＳ制御システム１０ｂ−２の構成を示したものである。

図８を参照すると、ＱｏＳ制御システム１０ｂ−２では、ＮＩＣ１８Ｔ−３が、ＱｏＳ制御システム１０ｂと異なる。

ＮＩＣ１８Ｔ−３では、図６に示した構成と比較して、スケジューラ１８７−２が、ＤＭＡコントローラ１８３に対して、ホストメモリからデータを読み出す要求を出すことができるようになっている。

このような構成において、ＮＩＣ１８Ｔ−３が、パケットに優先度値を付与し、優先度に基づいてパケットを送信する処理について、図４、図９を用いて、その差異を説明する。

図９は、ＮＩＣ１８Ｔ−３が、パケットに優先度値を付与し、優先度に基づいてパケットを送信する処理の一部を示したフローチャートである。

まず、図４のステップＦ１８２において、ＴＸコントローラ１８２は、ＤＭＡコントローラ１８３を通じて、パケットヘッダのみを読み出す。

次に、ＴＸコントローラ１８２は、図４のステップＦ１８４、または図４のステップＦ１８５〜ステップＦ１８７の手順に従ってパケットに適用する優先度値を取得する。

次に、ＴＸコントローラ１８２は、図４のステップＦ１８８で、優先度値をパケットヘッダに適用する。

次に、ＴＸコントローラ１８２は、パケットヘッダに適用した優先度値に基づいて、パケットヘッダと、パケットの転送要求を優先度キュー１８６に格納する（図９のステップＦ１８８０−２）。

次に、スケジューラ１８７−２は、キューの優先度に基づいて、キューに格納されたパケット転送要求とパケットヘッダを読み出し（図９のステップＦ１８８２−２）、パケット転送要求に基づいて、ＤＭＡコントローラ１８３に対し、パケットのペイロード部の読み出しを要求する（図９のステップＦ１８８４−２）。

次に、スケジューラ１８７−２は、読み出されたパケットのペイロード部と、図９のステップＦ１８８２−２で読み出したパケットヘッダからパケットを生成し、ＴＸインタフェース１８８を通じて、ネットワークにパケットを送出する（図９のステップＦ１８８６−２）。

このようにして、優先度キュー１８６の各キューのサイズが小さい構成においても、パケットに優先度値を付与し、優先度に基づいてパケットを送信することが可能となる。

ここで、図９のステップＦ１８８０−２で格納されたパケット転送要求について、既に読み出したパケットヘッダの領域の分だけ、転送サイズと、パケットが格納されたホストメモリのアドレスを変更しておくことも考えられる。また、このような変更をせずに、スケジューラ１８７−２が、図９のステップＦ１８８４−２でＤＭＡコントローラ１８３に対し、パケットのペイロード部の読み出しを要求する際に、転送サイズと、読み出し元のアドレスを変更することも考えられる。さらに、転送要求には変更を加えずに、図９のステップＦ１８８４−２でパケット全体を読み出し、パケットヘッダ部を破棄するということも考えられる。

また、図８の構成の場合、パケットのエラー検出のためのデータを計算し、パケットに適用する処理は、スケジューラ１８７−２が、図９のステップＦ１８８６−２の時点で行うことになる。

ここで、仮想マシンモニタ２４に内蔵される仮想スイッチ２２に接続された仮想マシン２０が、ＱｏＳ制御システム１０ｂに配置されている場合の、ＮＩＣ１８Ｔ−２の処理について説明する。

仮想スイッチ２２に接続された仮想マシン２０が送信するパケットについては、仮想スイッチ２２において、ポリシーテーブル２４０−２を参照することで、優先度値を設定することが可能である。

そのため、仮想スイッチから物理インタフェース１８０を通じて発行された送信要求については、送信対象のパケットに、システム管理者のポリシーに基づいた優先度値の設定がなされているとし、ＴＸコントローラ１８２は、図４、図７で示したような処理を行わずに、パケット送信要求に含まれる転送サイズと、アドレスに基づいて、ＤＭＡコントローラ１８３がホストメモリから読み出したパケットに設定された優先度値に基づいて、優先度キュー１８６の適切なキューにパケットを格納する。

一方で、仮想マシンモニタ２４の負荷が上昇すると、優先度値の設定を行うオーバヘッドにより、仮想スイッチ２２に接続された仮想マシン２０に係る通信の性能が劣化する可能性がある。

このような場合に、優先度値の付加を、仮想スイッチ２２で行わず、ＮＩＣ１８Ｔ−２で行うように、ＮＩＣ１８Ｔ−２の動作を切り替えることが考えられる。この方法については、本発明の第１の実施形態に記載したものと同様であるため、詳細な説明を省略する。

以上のように、本実施形態では、ＮＩＣ１８Ｔ−２、ＮＩＣ１８Ｔ−３が備える優先度キュー１８６に、フローテーブル１８５に登録されたＱｏＳパラメータに従って付与された優先度値に基づいて、パケットが格納される。優先度キュー１８６に格納されたパケットは、キューの優先度に基づいて送信時刻がスケジューリングされる。これによって、優先度に基づいて、サーバ１０とＴｏＲスイッチ１２の間のリンクを使用することが可能となる。
［第３の実施形態］
次に、本発明の第３の実施形態について図面を参照して詳細に説明する。図１０は、本発明の第３の実施形態に係るＱｏＳ制御システム１０ｃの構成を示した図である。図１０を参照すると、第２の実施形態の構成の仮想マシン２０にスレーブポリシーテーブル２４２が追加された構成が示されている。その他本発明の第２の実施の形態と同様の構成要素については同一の符号を付し、詳細な説明を省略する。

スレーブポリシーテーブル２４２には、ポリシーテーブル２４０−２のエントリの一部が登録される。具体的には、優先度キュー１８６を構成する各キューに、あふれそうなキューが存在する場合に、そのキューの優先度に対応するポリシーが登録される。例えば、優先度キュー１８６を構成するキューが０〜７番の８つあり、この番号がそのままキューの優先度を示すとする。このときに、ＴＣＰパケットにおいて、宛先ポート番号として８０番または、４４３番を持つトラフィックに対して、キュー番号が５番のキューを使用するようにポリシーが設定されているとする。このキューがあふれそうな場合に、宛先ポート番号が８０番のトラフィックを示すポリシーと、宛先ポート番号４４３番のトラフィックを示すポリシーがスレーブポリシーテーブルに登録される。

スレーブポリシーテーブル２４２に登録されているポリシーは、そのポリシーにマッチするトラフィックが利用する優先度キュー１８６のキューがあふれそうなことを示す。そのため、各仮想マシン２０は、パケットを構築した際に、パケット送信要求をＮＩＣ１８Ｔ−２に発行する前に、スレーブポリシーテーブル２４２に、送信要求で送信しようとするパケットのパケットヘッダに適合するトラフィック識別情報を持つエントリが存在するか否かをチェックする。ここでもし、エントリが存在した場合には、優先度キュー１８６の該当するキュー（５番キュー）があふれそうであるため、仮想マシン２０は、パケットの送信要求の発行を延期するように動作することができる。

続いて、図１１のシーケンス図を参照して、本実施形態の動作について詳細に説明する。

図１１は、優先度キュー１８６を構成するキューのいずれかがあふれそうになった場合に、スレーブポリシーテーブルにエントリを追加する処理を示したシーケンス図である。

まず、ＮＩＣ１８Ｔ−２は、優先度キュー１８６を構成するキューのいずれかがあふれそうになると、そのキューの識別情報を物理インタフェース１８０を通じて、仮想マシンモニタ２４に通知する（図１１のステップＳ１８２−３）。この通知には、あふれそうなキューの識別情報が含まれる。また、キューのいずれかがあふれそうになるか否かの判定は、各キューの空き領域（収容可能パケット数）が所定のしきい値ＴＨ１未満となったか否かにより判定できる。このしきい値ＴＨ１は、仮想マシンモニタ２４が、物理インタフェース１８０から設定可能なように、ＮＩＣ１８−Ｔ２を構成することが考えられる。この場合、ＮＩＣ１８−Ｔ２は、設定されたしきい値ＴＨ１と、キューの空き領域を比較し、キューがあふれそうになるか否かの判定を行う。

次に、仮想マシンモニタ２４は、ＮＩＣ１８Ｔ−２からの通知に含まれる、あふれそうなキューの識別情報をもとに、ポリシーテーブル２４０−２を参照し、該当するポリシーを抽出する（図１１のステップＳ２４２−３）。ポリシーテーブル２４０に登録されているポリシーの構成要素には、第２の実施形態にて述べたように、優先度キュー１８６のどのキューに格納するかを示す情報が含まれているため、これと比較することで抽出可能である。

次に、仮想マシンモニタ２４は、抽出したポリシーを、このポリシーが適用される可能性のある仮想マシン２０に通知する（図１１のステップＳ２４４−３）。

ここで、「ポリシーが適用される可能性がある」ことについて、例を用いて説明する。例えば、「ＴＣＰパケットの宛先ポート番号が８０番のトラフィック」のような、トラフィックの送信元、宛先を限定しないポリシーの場合は、全ての仮想マシンに通知される。一方で、「ＶＬＡＮ ＩＤが１０２４番のトラフィック」のようなポリシーの場合、ポリシーが適用される仮想マシン２０が、ＶＬＡＮ ＩＤが１０２４の仮想マシン２０に限定されるため、ＶＬＡＮ ＩＤが１０２４のＶＬＡＮに属する仮想マシン２０にのみ通知される。また、「送信元ＭＡＣアドレスが００：１１：２２：３３：４４：５５で、ＶＬＡＮ ＩＤが１０２４のトラフィック」のようなポリシーの場合、仮想マシン２０が一意に定まるため、その仮想マシン２０に対してのみ通知される。

次に、ポリシーの通知を受けた仮想マシン２０は、スレーブポリシーテーブル２４２に、通知されたポリシーを登録する（図１１のステップＳ２０２−３）。

なお、仮想マシン２０に通知されるポリシーには、設定する優先度値の情報を含まないように通知することも可能である。

次に、図１２のシーケンス図を参照して、本実施形態の動作に係るスレーブポリシーテーブルからのエントリの削除の処理について詳細に説明する。

図１２は、優先度キュー１８６を構成するキューのうち、あふれそうになっていたキューのいずれかについて、空き領域に余裕ができた場合に、スレーブポリシーテーブル２４２からエントリを削除する処理を示したシーケンス図である。また、キューの空き領域に余裕ができたか否かの判定は、各キューの空き領域（収容可能パケット数）が所定のしきい値ＴＨ２以上となったか否かにより判定できる。このしきい値ＴＨ２は、前述のこのしきい値ＴＨ１と同一の値でもよいし、異なる値でもよい。このしきい値ＴＨ２の設定方法の例は、しきい値ＴＨ１の場合と同様であるため、詳細な説明を省略する。

まず、ＮＩＣ１８Ｔ−２は、優先度キュー１８６を構成するキューのうち、あふれそうになっていたキューについて、そのキューの空きに余裕ができると、そのキューの識別情報を物理インタフェース１８０を通じて、仮想マシンモニタ２４に通知する（図１２のステップＳ１８４−３）。

次に、仮想マシンモニタ２４は、ＮＩＣ１８Ｔ−２からの通知に含まれる、空きに余裕ができたキューの識別情報をもとに、ポリシーテーブル２４０を参照し、該当するポリシーを抽出する（図１２のステップＳ２４６−３）。ポリシーテーブル２４０に登録されているポリシーの構成要素には、第２の実施形態にて述べたように、優先度キュー１８６のどのキューに格納するかを示す情報が含まれているため、これと比較することで抽出可能である。

次に、仮想マシンモニタ２４は、抽出したポリシーを、このポリシーが適用される可能性のある仮想マシン２０に通知する（図１２のステップＳ２４８−３）。

次に、ポリシーの通知を受けた仮想マシン２０は、通知されたポリシーを、スレーブポリシーテーブル２４２から削除する。削除する際に、スレーブポリシーテーブル２４２を検索するために、通知されたポリシーに含まれるトラフィックを識別する情報を用いることができる。

次に、図１３のシーケンス図、図１４のフローチャートを参照して、上記スレーブポリシーテーブル２４２を利用した仮想マシン２０のパケット送信要求の抑制処理について詳細に説明する。

図１３は、スレーブポリシーテーブル２４２を利用して、仮想マシン２０がパケット送信要求を発行する処理を示したシーケンス図である。

まず、仮想マシン２０は、送信するパケットを生成すると、パケット送信要求をＮＩＣ１８Ｔ−２に発行する前に、生成したパケットのパケットヘッダの情報を用いて、スレーブポリシーテーブル２４２を参照する（図１３のステップＳ２０６−３）。

次に、スレーブポリシーテーブル２４２にエントリが存在しない場合、仮想マシン２０は、パケット送信要求を、仮想インタフェース１８１を通じて、ＮＩＣ１８Ｔ−２に発行する（図１３のステップＳ２０８−３）。

以降、ＮＩＣ１８Ｔ−２と仮想マシンモニタ２４が、図４のステップＦ１８０〜ステップＦ１８８、図５のステップＦ２３８〜ステップＦ２４２、図７の処理を実行することで、パケットがネットワークに送出される。

図１４は、スレーブポリシーテーブル２４２を利用して、仮想マシン２０がパケット送信要求を発行する処理を示したフローチャートである。

まず、仮想マシン２０は、送信するパケットを生成すると、パケット送信要求をＮＩＣ１８Ｔ−２に発行する前に、生成したパケットのパケットヘッダの情報を用いて、スレーブポリシーテーブル２４２を参照する（図１４のステップＦ２０６−３）。

次に、仮想マシン２０は、スレーブポリシーテーブル２４２にエントリが存在しない場合（図１４のステップＦ２０６−３の「エントリが存在しない」）、パケット送信要求を、仮想インタフェース１８１を通して、ＮＩＣ１８Ｔ−２に発行する（図１４のステップＦ２０８−３）。

一方、仮想マシン２０は、スレーブポリシーテーブル２４２にエントリが存在した場合（図１４のステップＦ２０６−３の「エントリが存在する」）、パケット送信要求の発行を、該当するエントリを削除する通知が仮想マシンモニタ２４からなされるまで遅延させる（図１４のステップＦ２１０−３）。

なお、スレーブポリシーテーブル２４２にエントリが存在するにもかかわらず、このエントリに該当するパケットのパケット送信要求を、仮想マシン２０が発行した場合、ＮＩＣ１８Ｔ−２にて送信要求を破棄することで、キューがあふれることを防ぐことができる。

以上説明したように、本実施形態では、優先度キュー１８６を構成するキューのいずれかがあふれそうになると、ＮＩＣ１８Ｔ−２から仮想マシンモニタ２４に対して、通知がなされ、仮想マシンモニタ２４を通じて、影響のある仮想マシン２０に通知される。これにより、仮想マシン２０が、キューのあふれそうな通信要求の発行を行うことを抑制することができる。

なお、本発明の第１から第３実施形態では、ポリシーテーブル２４０、あるいはポリシーテーブル２４０−２が、仮想マシンモニタ２４に備えられ、ネットワークインタフェースカード１８Ｔ−１、ネットワークインタフェースカード１８Ｔ−２、ネットワークインタフェースカード１８Ｔ−３が、フローテーブル１８５、フローテーブル１８５−２に登録されていないＱｏＳパラメータについて問い合わせる際に、仮想マシンモニタ２４に問い合わせるような構成をとっているが、サーバ１０の外部に備えられた、システム管理者が管理するコントローラにポリシーテーブル２４０を備え、このコントローラに問い合わせるという構成をとることも可能である。外部のコントローラに問い合わせる方法として、ＴＸインタフェース１８８を通じて問い合わせる方法や、サーバ１０が他の管理用外部インタフェースを備える場合に、この管理用外部インタフェースを用いることが考えられる。この場合、仮想マシンモニタ２４に対して、ＱｏＳパラメータの問い合わせの要求を、外部コントローラに発行してもらうように依頼するという構成が考えられる。

また、本発明の第１から第３実施形態では、サーバ仮想化環境を前提とした構成をとっているが、本発明の適用先はサーバ仮想化環境に限定されない。例えば、サーバ仮想化環境を用いずに、ＱｏＳ制御システム１０ａ、１０ｂ、１０ｂ−２、１０ｃを構成するサーバ上にベアメタルでＯＳを導入した場合でも、システム管理者が運用する外部コントローラから、ＮＩＣ１８を制御し、本発明のＱｏＳ制御を適用することも可能である。

最後に、本発明の好ましい形態を要約する。
［第１の形態］
（上記第１の視点によるＱｏＳ制御システム参照）
［第２の形態］
第１の形態のＱｏＳ制御システムにおいて、
前記ネットワークインタフェースは、外部からのパケット送信要求に応じてメモリからパケットを取得し、前記パケットに適合する識別情報を持つＱｏＳパラメータを用いて前記パケットに優先度値を格納してから送信することができる。
［第３の形態］
第１又は第２の形態のＱｏＳ制御システムにおいて、
前記ネットワークインタフェースは、送信パケットに適合する識別情報を持つＱｏＳパラメータを保持していない場合、前記ネットワークインタフェース管理部に対してＱｏＳパラメータの送信を要求することができる。
［第４の形態］
第３の形態のＱｏＳ制御システムにおいて、
前記ネットワークインタフェース管理部は、前記ＱｏＳポリシーから、前記ネットワークインタフェースからの前記ＱｏＳパラメータの送信要求を受けたパケットと同じ識別情報を持つＱｏＳパラメータを取得し、前記ネットワークインタフェースに通知することができる。
［第５の形態］
第１から第４いずれか一の形態のＱｏＳ制御システムにおいて、
前記ネットワークインタフェースは、さらに、
優先度が設定された１つ以上のキューから構成される優先度キューと、前記優先度キューを構成するキューの優先度に応じて、パケットの送信をスケジューリングするスケジューラと、を備える構成とすることができる。
［第６の形態］
第５の形態のＱｏＳ制御システムにおいて、
前記ネットワークインタフェースは、前記ＱｏＳパラメータとして、トラフィック毎に前記優先度キューを指定するための情報を保持することができる。
［第７の形態］
第６の形態のＱｏＳ制御システムにおいて、
前記ネットワークインタフェースは、前記優先度キューを指定するための情報に基づいて、前記ＱｏＳパラメータを適用したパケット、パケットヘッダ、またはパケット送信要求のいずれかを前記優先度キューのいずれかに格納することができる。
［第８の形態］
第５から第７いずれか一の形態のＱｏＳ制御システムにおいて、
前記ネットワークインタフェースは、前記ネットワークインタフェース管理部に対して、前記優先度キューの使用状況を通知する機能を有することができる。
［第９の形態］
第８の形態のＱｏＳ制御システムにおいて、
前記ネットワークインタフェース管理部は、前記ＱｏＳポリシーとして、さらに、前記優先度キューを構成するキューの識別情報を保持し、
前記ネットワークインタフェースから通知された前記優先度キューの使用状況に基づいて、前記キューの識別情報と一致するキューの識別情報を持つＱｏＳポリシーを選択し、パケット送信要求の発行元に対して、前記選択したＱｏＳポリシーを通知し、
前記パケット送信要求の発行元は、前記ＱｏＳポリシーを含む通知に従って、パケット送信要求の抑制又はパケット送信要求の送信再開を行うことができる。
［第１０の形態］
第１から第９いずれか一の形態のＱｏＳ制御システムにおいて、
前記ネットワークインタフェースは、前記ネットワークインタフェースにて優先度値の付与を行うか否かを設定可能であり、
前記ネットワークインタフェース管理部からの前記優先度値の付与の要否の設定を変更することにより、前記ネットワークインタフェースで優先度値の付与を行うか否かを制御することができる。
［第１１の形態］
（上記第２の視点によるＱｏＳ制御方法参照）
［第１２の形態］
（上記第３の視点によるプログラム参照）
なお、第１１の形態、第１２の形態は、第１の形態と同様に、第２〜第１０の形態に展開することが可能である。

なお、上記の特許文献および非特許文献の各開示を、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の請求の範囲の枠内において種々の開示要素（各請求項の各要素、各実施形態ないし実施例の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。

１ データセンタネットワークアーキテクチャ
２ データセンタネットワークアーキテクチャ
１０ サーバ
１０ａ ＱｏＳ制御システム
１０ｂ ＱｏＳ制御システム
１０ｂ−２ ＱｏＳ制御システム
１０ｃ ＱｏＳ制御システム
１２ Ｔｏｐ−ｏｆ−Ｒａｃｋスイッチ
１４ アグリゲーションスイッチ
１６ コアスイッチ
１８ ネットワークインタフェースカード
１８Ｔ−１〜１８Ｔ−３ ネットワークインタフェースカード送信部
２０ 仮想マシン
２２ 仮想スイッチ
２４ 仮想マシンモニタ
１８０ 物理インタフェース
１８１ 仮想インタフェース
１８２ ＴＸコントローラ
１８３、１８３−２ ＤＭＡコントローラ
１８４ ホストバスインタフェース
１８５、１８５−２ フローテーブル
１８６ 優先度キュー
１８７、１８７-２ スケジューラ
１８８ ＴＸインタフェース
２４０ ポリシーテーブル
２４２、２４０-２ スレーブポリシーテーブル

Claims (10)

1. トラフィックを識別する識別情報と、当該トラフィックに属するパケットに適用する優先度値と、前記パケット内に前記優先度値を格納する位置を示す情報と、を定めたＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）パラメータを保持し、前記トラフィックに属するパケットに優先度値を格納してから送信するネットワークインタフェースと、
   各トラフィックに適用するＱｏＳパラメータを含んだＱｏＳポリシーを保持して、前記ネットワークインタフェースを管理するネットワークインタフェース管理部と、を含み、
   前記ネットワークインタフェースは、さらに、
   優先度が設定された１つ以上のキューから構成される優先度キューと、前記優先度キューを構成するキューの優先度に応じて、パケットの送信をスケジューリングするスケジューラと、を備える
   ＱｏＳ制御システム。
2. 前記ネットワークインタフェースは、外部からのパケット送信要求に応じてメモリからパケットを取得し、前記パケットに適合する識別情報を持つ前記ＱｏＳパラメータを用いて前記パケットに優先度値を格納してから送信する請求項１のＱｏＳ制御システム。
3. 前記ネットワークインタフェースは、送信パケットに適合する識別情報を持つ前記ＱｏＳパラメータを保持していない場合、前記ネットワークインタフェース管理部に対して前記ＱｏＳパラメータの送信を要求する請求項１又は２のＱｏＳ制御システム。
4. 前記ネットワークインタフェース管理部は、前記ＱｏＳポリシーから、前記ネットワークインタフェースからの前記ＱｏＳパラメータの送信要求を受けたパケットと同じ識別情報を持つ前記ＱｏＳパラメータを取得し、前記ネットワークインタフェースに通知する請求項３のＱｏＳ制御システム。
5. 前記ネットワークインタフェースは、前記優先度キューを指定するための情報に基づいて、前記ＱｏＳパラメータを適用したパケット、パケットヘッダ、またはパケット送信要求のいずれかを前記優先度キューのいずれかに格納する
   請求項１乃至請求項４のいずれか一項に記載のＱｏＳ制御システム。
6. 前記ネットワークインタフェースは、前記ネットワークインタフェース管理部に対して、前記優先度キューの使用状況を通知する機能を有する請求項５に記載のＱｏＳ制御システム。
7. 前記ネットワークインタフェース管理部は、前記ＱｏＳポリシーとして、さらに、前記優先度キューを構成するキューの識別情報を保持し、
   前記ネットワークインタフェースから通知された前記優先度キューの使用状況に基づいて、前記キューの識別情報と一致するキューの識別情報を持つＱｏＳポリシーを選択し、パケット送信要求の発行元に対して、前記選択したＱｏＳポリシーを通知し、
   前記パケット送信要求の発行元は、前記ＱｏＳポリシーを含む通知に従って、パケット送信要求の抑制又はパケット送信要求の送信再開を行う請求項６のＱｏＳ制御システム。
8. 前記ネットワークインタフェースは、前記ネットワークインタフェースにて優先度値の付与を行うか否かを設定可能であり、
   前記ネットワークインタフェース管理部からの前記優先度値の付与の要否の設定を変更することにより、前記ネットワークインタフェースで優先度値の付与を行うか否かを制御する請求項１から７いずれか一のＱｏＳ制御システム。
9. 各トラフィックに適用するＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）パラメータを含んだＱｏＳポリシーを参照して、優先度が設定された１つ以上のキューから構成される優先度キューを有するネットワークインタフェースに対して、トラフィックを識別する識別情報と、当該トラフィックに属するパケットに適用する優先度値と、前記パケット内に前記優先度値を格納する位置を示す情報と、を含む前記ＱｏＳパラメータを通知するステップと、
   前記ネットワークインタフェースに、前記優先度キューを構成するキューの優先度に応じて、パケットの送信をスケジューリングさせるステップと、
   そのスケジューリングの結果に応じて、前記ネットワークインタフェースに、前記ＱｏＳパラメータを用いて、前記識別情報に適合するパケットに優先度値を格納してから送信させるステップと、を含む
   ＱｏＳ制御方法。
10. 各トラフィックに適用するＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）パラメータを含んだＱｏＳポリシーを参照して、優先度が設定された１つ以上のキューから構成される優先度キューを有するネットワークインタフェースに対して、トラフィックを識別する識別情報と、当該トラフィックに属するパケットに適用する優先度値と、前記パケット内に前記優先度値を格納する位置を示す情報と、を含む前記ＱｏＳパラメータを通知する処理と、
    前記ネットワークインタフェースに、前記優先度キューを構成するキューの優先度に応じて、パケットの送信をスケジューリングさせる処理と、
    そのスケジューリングの結果に応じて、前記ネットワークインタフェースに、前記ＱｏＳパラメータを用いて、前記識別情報に適合するパケットに優先度値を格納してから送信させる処理と、をコンピュータに実行させる、
    コンピュータ・プログラム。

Images