JP7251060B2 - 情報処理装置、情報処理システム及び情報処理プログラム - Google Patents

Description

本発明は、情報処理装置、情報処理システム及び情報処理プログラムに関する。

近年、サーバコンピュータやクライアントコンピュータの性能の向上が目覚ましく、これらの性能向上に合わせて通信の高性能化の要望が高まっている。そして、通信の高性能化を実現するために、通信の送信元と送信先とが決められたデータの流れであるフローのレベルの制御が求められている。

例えば、フローには、ストレージへのアクセスのトラフィックや問い合わせを行うトラフィックなどがある。ストレージへのアクセスの場合、大量のデータが転送されることが多く、大きなパケットを用いてデータが転送されることが多い。これに対して、問い合わせを行う場合、小さなパケットを用いてデータが転送されることが多い。このように、フロー毎にパケットの大きさが異なるため、フローレベルでの制御を行うことでパケット転送の効率を上げることができ、通信性能の向上を実現することができる。

このようなフローレベルの制御を行う場合に、送信するパケットを蓄えるためのキューをフローに合わせて切り替えることが考えられる。例えば、小さいパケットであればレイテンシを低くすることが求められるため、キューに格納されたパケットが早く処理されることが好ましい。これに対して、大きいパケットであれば、スループットを高くすることが求められるため、キューを空にせずに常にパケットが存在することが好ましい。そこで、例えば、小さいパケットを格納するキューと大きいパケットのキューとを異ならせることが考えられる。

このように、フローレベルの制御によりキューを切り替える方法として、ＡＣＬ（Access Control List）を用いてヘッダ情報を比較し、転送量に応じてキューを切り替える従来技術がある。また、ハッシュ値を用いてフローを特定し、キューにパケットが残っていないフローの振り分け先を負荷の軽いキューに変更する従来技術がある。

特開２０１０－１６１５４６号公報

しかしながら、ＡＣＬを用いてキューを切り替える従来技術では、キューの切り替えを行うための設定を手動で行うことになり、自動化が困難であるとともに高速な切り替えに対応することが困難である。また、フローを特定してパケットがキューに残っていないフローのキューの切り替えを行う従来技術を用いても、フローの種類に応じた自動的なキューの切り替えは行っておらず、柔軟にキューを切り替えることは困難である。

開示の技術は、上記に鑑みてなされたものであって、通信性能を向上させる情報処理装置、情報処理システム及び情報処理プログラムを提供することを目的とする。

本願の開示する情報処理装置、情報処理システム及び情報処理プログラムの一つの態様において、複数のパケットが属するフローについて、前記パケットを格納し、格納した前記パケットを順次出力する複数のキューが設けられる。フロー識別部は、受信した前記パケットのヘッダ情報を取得して、取得した前記ヘッダ情報を基に前記フローの識別情報を取得し、受信したパケットの数に応じて前記フローの使用頻度を求め、前記識別情報及び前記使用頻度を管理テーブルの前記識別情報に対応する位置に登録し、且つ、前記使用頻度を基に、前記フローの前記パケットが当該フローのパケットを送信するキューとして決定されているキューに残っているか否かを判定し、当該フローのパケットを送信するキューとして決定されているキューに前記フローの前記パケットが残っていない場合、前記フローを前記管理テーブルから削除する。特徴量取得部は、前記フローに関する特徴量を取得する。送信制御部は、前記フローが前記管理テーブルに登録されていない場合、所定キューを前記フローのパケットを送信するキューと決定し、前記フローが前記管理テーブルに登録されている場合、前記特徴量取得部により取得された前記特徴量を基に、前記フローの前記パケットを送信するキューを決定し、前記フローの前記パケットを決定した前記前記フローのパケットを送信するキューに格納して送信させる。

１つの側面では、本発明は、通信性能を向上させることができる。

図１は、情報処理システムの概略構成図である。 図２は、実施例に係るスイッチのブロック図である。 図３は、中継処理部から送信キューセットの間の各地点において受け渡される情報をまとめた図である。 図４は、フロー識別テーブルの一例を表す図である。 図５は、転送量テーブルの一例を表す図である。 図６は、キュー情報管理テーブルの一例を表す図である。 図７は、送信キューセットのブロック図である。 図８は、フロー識別部によるフローの識別処理のフローチャートである。 図９は、フロー識別部によるエントリ管理のフローチャートである。 図１０は、フロー判別処理部によるフロー判別処理のフローチャートである。 図１１は、キュー切替処理部によるキューの切り替え処理のフローチャートである。 図１２は、キューに対するエンキュー処理のフローチャートである。 図１３は、キューに対するデキュー処理のフローチャートである。 図１４は、実施例２に係るフロー識別テーブルの一例を示す図である。 図１５は、実施例２に係るフロー識別部によるフロー識別処理のフローチャートである。 図１６は、実施例３に係るキュー情報管理テーブルの一例を表す図である。 図１７は、実施例４に係るスイッチのブロック図である。 図１８は、輻輳制御を行うスイッチのブロック図である。 図１９は、実施例５におけるスイッチの各地点において受け渡される情報をまとめた図である。 図２０は、実施例５におけるキュー情報管理テーブルの一例を示す図である。 図２１は、実施例５に係る送信キューセットのブロック図である。 図２２は、実施例５に係るキュー切替処理部によるキューの切り替え処理のフローチャートである。 図２３は、実施例７に係る情報処理システムのブロック図である。 図２４は、フロー判別テーブルの一例を表す図である。 図２５は、実施例７に係るサーバによるフロー管理の全体的な処理のフローチャートである。 図２６は、実施例７に係るサーバによる送信処理のフローチャートである。 図２７は、実施例７に係るサーバによる受信処理のフローチャートである。 図２８は、実施例５のスイッチを用いた場合の効果を説明するための図である。

以下に、本願の開示する情報処理装置、情報処理システム及び情報処理プログラムの実施例を図面に基づいて詳細に説明する。なお、以下の実施例により本願の開示する情報処理装置、情報処理システム及び情報処理プログラムが限定されるものではない。

図１は、情報処理システムの概略構成図である。図１に示すように本実施例に係る情報処理システム１は、スイッチ１００及びサーバ２０１～２０６を有する。

サーバ２０１～２０６は、それぞれスイッチ１００に接続される。そして、サーバ２０１～２０６は、それぞれが相互にスイッチ１００を介してパケットの送受信を行う。以下では、サーバ２０１～２０６をそれぞれ区別せずに表す場合、サーバ２００という。そして、パケットの送信元のサーバ２００を「送信側のサーバ２００」と呼び、パケットの送信先のサーバ２００を「受信側のサーバ２００」と呼ぶ。例えば、サーバ２０１がサーバ２０４にパケットを送信する場合、送信側のサーバ２００であるサーバ２０１が「第１通信装置」の一例にあたり、受信側のサーバ２００であるサーバ２０４が「第２通信装置」の一例にあたる。

スイッチ１００は、送信側のサーバ２００から送信された受信側のサーバ２００宛てのパケットを受信する。そして、スイッチ１００は、サーバ２００に接続されたポートから受信側のサーバ２００へ向けて、送信側のサーバ２００から送信されたパケットを送信する。

ここで、図１では、１台のスイッチ１００でサーバ２００同士が接続される場合を図示したが、接続形態はこれに限らない、スイッチ１００は他の通信機器を介して送信側のサーバ２００と受信側のサーバ２００とを接続してもよい。また、図１では、６台のサーバ２０１～２０６を図示したが、台数に特に制限は無い。

ここで、送信側のサーバ２００から受信側のサーバ２００へのパケット送信によるフローについて説明する。送信側のサーバ２００と受信側のサーバ２００とは、一連の関連するパケットを送信する通信を行う。このような、一連のパケットを送信する処理を「フロー」と言う。

パケットは、パケットの送受信を制御する情報を含むヘッダと送信するデータを含むペイロードを有する。パケットのヘッダには、フローを識別するための情報であるパケット情報が格納される。ここで、同じフローとして送受信されるパケットのそれぞれには、フローを識別するための情報として同じ情報が格納される。

例えば、パケットのヘッダには、宛先アドレス、送信元情報、宛先情報、プロトコル、並びに、送信元ポート番号及び宛先ポート番号などが格納される。例えば、送信元情報は送信元ＩＰ（Internet Protocol）などであり、宛先情報は宛先ＩＰなどである。本実施例では、フローを識別する情報として、５－ｔｕｐｌｅと呼ばれる、送信元ＩＰ、宛先ＩＰ、送信元ポート番号、宛先ポート番号及びプロトコルの５つの情報を用いる。ただし、フローを識別する情報は、フローとして表される一連のパケットを送信する処理を特定できればよく、他の情報を用いてもよい。

次に、図２を参照して、スイッチ１００の詳細について説明する。図２は、実施例に係るスイッチのブロック図である。このスイッチ１００が、「情報処理装置」の一例にあたる。

スイッチ１００は、図２に示すように、受信ポート１１１～１１２、中継処理部１０２、フロー識別部１０３、フロー判別処理部１０４、キュー切替処理部１０５、データ保持部１０６、送信キューセット１７１～１７２及び送信ポート１８１～１８２を有する。さらに、データ保持部１０６は、フロー識別テーブル１６１、転送量テーブル１６２及びキュー情報管理テーブル１６３を有する。

受信ポート１１１～１１２は、同じ機能を有しており、以下では、それぞれを区別しない場合、「受信ポート１１０」という。また、送信ポート１８１～１８２は、同じ機能を有しており、以下では、それぞれを区別しない場合、「送信ポート１８０」という。

受信ポート１１１～１１２は、図示しないが１つ又はいくつかのサーバ２００に接続される。受信ポート１１１～１１２は、接続先の送信側のサーバ２００からパケットの入力を受ける。そして、受信ポート１１１～１１２は、入力されたパケットを中継処理部１０２へ出力する。

中継処理部１０２は、パケットの入力を受信ポート１１０から受ける。中継処理部１０２は、ヘッダに格納された宛先情報及び宛先ポートなどの受信側のサーバ２００の情報からそのパケットを出力する送信ポート１８０を決定する。そして、中継処理部１０２は、決定した送信ポート１８０の識別子である送信ポートＩＤ(IDentifier)とともに送信元ＩＰ、宛先ＩＰ、送信元ポート番号、宛先ポート番号及びプロトコルを含むパケット情報、並びにパケットをフロー識別部１０３へ出力する。ここで、パケット情報は、実際にはパケットのヘッダに含まれるため、パケットを送ることでパケット情報も送ることができる。ただし、ここでの説明では、パケット情報が授受されることを明示するため、パケットとともにパケット情報も送信するように説明する。

図３は、中継処理部から送信キューセットの間の各地点において受け渡される情報をまとめた図である。図３に示すように、中継処理部１０２からフロー識別部１０３へ送信されるパケット送信の制御情報として、パケット情報及び送信ポートＩＤを含む情報セット１２１が送信される。

図２に戻って説明を続ける。フロー識別テーブル１６１は、例えば、図４に示したテーブルである。図４は、フロー識別テーブルの一例を表す図である。

フロー識別テーブル１６１は、送信元ＩＰ、宛先ＩＰ、送信元ポート番号、宛先ポート番号及びプロトコルを含むヘッダ情報、アドレス及び頻度情報が対応付けられて登録される。頻度情報とは、ある時点での各フローに含まれるパケットが送られる頻度を表す。さらに、後述するようにフロー識別テーブル１６１のアドレスは、フローＩＤにあたる。

本実施例に係るフロー識別テーブル１６１は、情報の内容を与えることで、その情報が格納されたエントリのアドレスを与えるＣＡＭ（Content Addressable Memory）である。

フロー識別部１０３は、パケット情報及び送信ポートＩＤを含む情報セット１２１を取得する。さらに、フロー識別部１０３は、パケット本体の入力を受ける。次に、フロー識別部１０３は、取得したパケット情報に含まれる送信元ＩＰ、宛先ＩＰ、送信元ポート番号、宛先ポート番号及びプロトコルを含むヘッダ情報を用いてフロー識別テーブル１６１を検索する。

ヘッダ情報に一致するエントリが存在する場合、フロー識別部１０３は、そのヘッダ情報が表すフローの識別情報であるフローＩＤとして、そのヘッダ情報に対応するアドレスを取得する。このフローＩＤが取得したパケットが属するフローの識別子である。さらに、フロー識別部１０３は、そのフローＩＤに対応する頻度情報を１つインクリメントする。さらに、フロー識別部１０３は、一致するエントリが存在したことを表すＦｏｕｎｄのメッセージをエントリの検索結果を表すエントリ情報とする。

また、ヘッダ情報に一致するエントリが存在せず、且つ、エントリに空きがある場合、フロー識別部１０３は、ヘッダ情報を空きエントリに登録し、頻度情報に１を登録する。そして、フロー識別部１０３は、登録したエントリのアドレスをそのヘッダ情報に対応するフローＩＤとして取得する。このフローＩＤが取得したパケットが属するフローの識別子となる。さらに、フロー識別部１０３は、エントリを新しく生成したことを表すＮｅｗのメッセージをエントリ情報とする。

また、ヘッダ情報に一致するエントリが存在せず、且つ、エントリに空きがない場合、フロー識別部１０３は、エントリが存在しないことを表すＮｏｔｆｏｕｎｄのメッセージをエントリ情報とする。この場合、フロー識別部１０３は、フローＩＤが存在しないことを表す情報をフローＩＤとしてもよい。

その後、フロー識別部１０３は、パケット本体とともに、図３に示すようにパケット情報、送信ポートＩＤ、フローＩＤ及びエントリ情報を含む情報セット１３１をフロー判別処理部１０４へ出力する。

また、フロー識別部１０３は、フロー識別テーブル１６１のエントリの管理を一定の周期で行う。具体的には、フロー識別部１０３は、フロー識別テーブル１６１のエントリの管理を行う周期を予め記憶する。そして、フロー識別テーブル１６１のエントリの管理のタイミングが到来すると、フロー識別部１０３は、フロー識別テーブル１６１からエントリを１つずつ選択する。

そして、フロー識別部１０３は、選択したエントリにおける頻度情報が０か否かを判定する。頻度情報が０でない場合、フロー識別部１０３は、選択したエントリの頻度情報を１つデクリメントする。すなわち、フロー識別部１０３から出力されたパケットは、出力されてから十分な期間が経過すれば送信ポート１８０から既に出力された可能性が高い。そこで、フロー識別部１０３は、出力時に１つ増やした頻度情報を１つ減らすことでそのフローに属するスイッチ１００内に滞留しているパケットの数を予測することができる。そして、頻度情報が０であればスイッチ１００内にそのフローに属するパケットが存在していない蓋然性が高いと予測できる。

そこで、頻度情報が０の場合、フロー識別部１０３は、選択したエントリのフローＩＤに対応するキューカウンタの値をキュー情報管理テーブル１６３から取得する。そして、フロー識別部１０３は、キューカウンタが０か否かを判定する。キューカウンタが０であれば、フロー識別部１０３は、送信キューセット１７０の中にそのフローに属するパケットが残っていないことが確認できるので、スイッチ１００内にそのフローに属するパケットが存在していないと予測できる。そこで、フロー識別部１０３は、選択したエントリを削除する。

フロー識別部１０３は、以上の処理をフロー識別テーブル１６１の全てのエントリに対して行い、フロー識別テーブル１６１を管理する。これにより、不要なエントリを削除することができ、フロー識別部１０３は、フロー識別テーブル１６１を有効に使用することができる。

転送量テーブル１６２は、各フローの転送量を表すテーブルである。図５は、転送量テーブルの一例を表す図である。図５に示すように、転送量テーブル１６２には、フローＩＤに対応させて各フローの特徴量として転送量が登録される。図５においてＦＩＤはフローＩＤ（Flow ID）を表す。また、本実施例の場合、１つのフローＩＤに対して全ての送信ポート１８０のカウンタを１つのエントリで管理する。これは、通信の多くはユニキャスト通信であり、出力先となる送信ポート１８０は１つに限定されることが多い。そのため、１つのフローＩＤに対して全ての送信ポート１８０を１つのエントリで管理してもほとんどの場合は問題にならないことを理由とする。

フロー判別処理部１０４は、パケット本体とともに、図３に示すようにパケット情報、送信ポートＩＤ、フローＩＤ及びエントリ情報を含む情報セット１３１の入力をフロー識別部１０３から受ける。そして、フロー判別処理部１０４は、取得したエントリ情報を確認する。

エントリ情報がＦｏｕｎｄの場合、フロー判別処理部１０４は、転送量テーブル１６２における取得したフローＩＤに対応するエントリを特定する。そして、フロー判別処理部１０４は、パケット情報からパケットのサイズを取得して、転送量テーブル１６２における取得したフローＩＤに対応するエントリの転送量にパケットの大きさを加算して書き込む。

エントリ情報がＮｅｗの場合、フロー判別処理部１０４は、転送量テーブル１６２にあらたにフローＩＤに対応するエントリを作成する。そして、フロー判別処理部１０４は、転送量を初期化する。その後、フロー判別処理部１０４は、パケット情報からパケットのサイズを取得して、作成したエントリの転送量にパケットの大きさを書き込む。

次に、エントリ情報がＦｏｕｎｄ又はＮｅｗのいずれの場合も、フロー判別処理部１０４は、パケット情報を確認して、そのパケットの出力キューとして特定キューが指定されているか否かを判定する。ここで、出力キューとは、パケットを入力して保持させ、その後、送信ポート１８０へ保持させたパケットを出力させるキューを指す。例えば、パケットの優先度が高い場合には、優先的に処理される予め決められた特定キューが出力キューとしてそのパケットに指定される。

パケットに特定キューが指定されている場合、フロー判別処理部１０４は、指定された特定キューを出力キューの候補として指定する候補キューとする。具体的には、フロー判別処理部１０４は、パケット情報に格納されたパケットの優先度を確認する。例えば、パケットの優先度は０～７で表される。この場合、数字が大きくなるほど優先度が高い。そして、パケットの優先度が７であれば、フロー判別処理部１０４は、優先的に処理される特定キューをそのパケットの候補キューとする。

一方、パケットに特定キューが指定されていない場合、フロー判別処理部１０４は、転送量が予め決められた閾値以上か否かを判定する。転送量が予め決められた閾値以上の場合、フロー判別処理部１０４は、送信ポート１８１に接続する送信キューセット１７０が有する複数のキューの内のロングキューを、そのパケットの候補キューとする。ロングキューとは、転送量の大きいフローに属するパケットを格納するために割り当てられたキューであり、スループットを高くすることを目的とするキューである。送信キューセット１７０については後で詳細に説明する。このロングキューが、「第１キュー」の一例にあたる。

これに対して、転送量が予め決められた閾値未満の場合、フロー判別処理部１０４は、送信ポート１８１に接続する送信キューセット１７０が有する複数の送信キューの内のショートキューを、そのパケットの候補キューとする。ショートキューとは、転送量の小さいフローに属するパケットを格納するために割り当てられたキューであり、レイテンシを低くすることを目的とするキューである。このショートキューが、「第２キュー」の一例にあたる。

一方、エントリがＮｏｔｆｏｕｎｄの場合、フロー判別処理部１０４は、デフォルトのキューを、そのパケットの候補キューとする。

その後、フロー判別処理部１０４は、パケット本体とともに、図３に示すパケット情報、フローＩＤ、エントリ情報及び候補キューの識別情報である候補キューＩＤを含む情報セット１４１をキュー切替処理部１０５へ出力する。このフロー判別処理部１０４が、「特徴量取得部」の一例にあたる。

キュー情報管理テーブル１６３は、フロー毎に、そのフローのパケットの出力キューの情報及び各フローに対する出力キューの状態を表すテーブルである。図６は、キュー情報管理テーブルの一例を表す図である。キュー情報管理テーブル１６３は、フローＩＤとＱ（Que）ＩＤとを対応付けて記憶する。ＱＩＤは、各フローＩＤを有するフローのパケットが送信されたキュー、すなわち各フローＩＤを有するフローの現在のキューを表す。また、キュー情報管理テーブル１６３は、フローＩＤ毎に、各フローＩＤを有するフローの現在のキューに格納されたそのフローのパケット数を表すキューカウンタを有する。

キュー切替処理部１０５は、パケット本体とともに、パケット情報、フローＩＤ、エントリ情報及び候補キューＩＤを含む情報セット１４１の入力をフロー判別処理部１０４から受ける。そして、キュー切替処理部１０５は、エントリ情報を確認する。

エントリ情報がＦｏｕｎｄの場合、キュー切替処理部１０５は、取得したフローＩＤの現在のキューのキューＩＤをキュー情報管理テーブル１６３から取得する。そして、キュー切替処理部１０５は、候補キューＩＤと現在のキューのキューＩＤが一致するか否かにより、キューの切り替えが発生するか否かを判定する。キューの切り替えが発生しない場合、キュー切替処理部１０５は、出力キューを候補キューとする。この場合、出力キューを現在のキューのまま維持することになる。

一方、キューの切り替えが発生する場合、キュー切替処理部１０５は、キュー情報管理テーブル１６３における取得したフローＩＤに対応するキューカウンタの値が０か否かを判定する。キューカウンタの値が０であれば、そのフローの現在のキューにそのフローのパケットが残っていないといえる。すなわち、キュー切替処理部１０５は、そのフローの現在のキューに、そのフローのパケットが残っている状態か否かを判定する。そして、キューカウンタの値が０であれば、現在のキューにパケットが残っていないので、キュー切替処理部１０５は、そのフローの出力キューを現在のキューから候補キューに変更する。

これに対して、キューカウンタの値が０でなく、現在のキューにパケットが残っている場合、キュー切替処理部１０５は、そのフローの出力キューを候補キューとされなかった現在のキューのまま維持する。これにより、パケットが特定のキューに残っているにも関わらず他のキューにパケットを格納することを回避することができ、パケットの順序逆転を回避することができる。

また、エントリ情報がＮｅｗの場合、キュー切替処理部１０５は、キュー情報管理テーブル１６３に新たに取得したフローＩＤを登録して対応するエントリを作成する。さらに、キュー切替処理部１０５は、生成したエントリのキューカウンタ値を０にして初期化する。そして、キュー切替処理部１０５は、そのフローの出力キューを候補キューに設定する。

また、エントリ情報がＮｏｔｆｏｕｎｄの場合、キュー切替処理部１０５は、そのフローの出力キューを候補キューに設定する。

その後、キュー切替処理部１０５は、そのフローの出力キューとして決定したキューを有する送信キューセット１７０へパケット、パケット情報及びそのパケットが属するフローのＦＩＤを出力する。さらに、パケットの出力とともに、キュー切替処理部１０５は、出力したパケットの出力キューのキューＩＤをパケットの出力先の送信キューセット１７０へ出力する。また、キュー切替処理部１０５は、出力したパケットが属するフローのフローＩＤ及び加算を指示するコマンドをキュー情報管理テーブル１６３へ出力する。これにより、キュー切替処理部１０５は、キュー情報管理テーブル１６３における指定したフローＩＤに対応するキューカウンタを１つインクリメントさせる。このキュー切替処理部１０５が、「送信制御部」の一例にあたる。

図７は、送信キューセットのブロック図である。送信キューセット１７０は、図７に示すように、セレクタ７０１、マルチプレクサ７０３、スケジューラ７０４及び複数のキュー７２１～７２３を有する。以下では、キュー７２１～７２３のそれぞれを区別しない場合、「キュー７２０」という。

セレクタ７０１は、パケット情報、フローＩＤ及びパケットの入力をキュー切替処理部１０５から受ける。さらに、セレクタ７０１は、そのパケットの出力キューを表すキューＩＤの入力をキュー切替処理部１０５から受ける。すなわち、セレクタ７０１は、図３に示すパケット情報、フローＩＤ及びキューＩＤを含む情報セット１５１、並びに、パケットの入力をキュー切替処理部１０５から受ける。

そして、セレクタ７０１は、指定されたキューＩＤを有するキュー７２０にパケット情報、フローＩＤ及びパケットを出力する。

キュー切替処理部１０５から入力されたキューＩＤで出力キューとして指定されたキュー７２０は、パケット情報、フローＩＤ及びパケットの入力をセレクタ７０１から受ける。そして、キュー７２０は、入力されたパケット情報、フローＩＤ及びパケットを格納する。その後、キュー７２０は、取得タイミングの古い順に保持するパケット情報、フローＩＤ及びパケットをマルチプレクサ７０３へ順次出力していく。

スケジューラ７０４は、マルチプレクサ７０３が出力するパケットの調停を行う。例えば、スケジューラ７０４は、ラウンドロビンなどでパケットを出力するキュー７２０を選択してマルチプレクサ７０３から出力させる。

マルチプレクサ７０３は、スケジューラ７０４から指定されたキュー７２０からパケット情報、フローＩＤ及びパケットを取得する。そして、マルチプレクサ７０３は、取得したパケット情報及びパケットを送信ポート１８０へ出力する。さらに、マルチプレクサ７０３は、パケットが属するフローのフローＩＤを、減算を指示するコマンドとともにキュー情報管理テーブル１６３へ出力する。これにより、送信キューセット１７０は、キュー情報管理テーブル１６３における指定したフローＩＤに対応するキューカウンタを１つデクリメントさせる。

図２に戻って説明を続ける。送信ポート１８０は、パケット情報に含まれる宛先情報で指定された受信側のサーバ２００に向けてパケットを送信する。

次に、図８を参照して、フロー識別部１０３によるフローの識別処理の流れについて説明する。図８は、フロー識別部によるフローの識別処理のフローチャートである。

フロー識別部１０３は、パケットとともにパケット情報及び送信ポートＩＤの入力を中継処理部１０２から受ける。そして、フロー識別部１０３は、パケット情報を用いてフロー識別テーブル１６１を検索する（ステップＳ１０１）。本実施例では、フロー識別部１０３は、パケット情報に含まれる送信元ＩＰ、宛先ＩＰ、送信ポート番号、宛先ポート番号及びプロトコルをフロー識別テーブル１６１へ出力することで検索を行う。

そして、フロー識別部１０３は、パケットが属するフローに該当するフローを検出する（ステップＳ１０２）。本実施例の場合、フロー識別テーブル１６１がＣＡＭであるので、フロー識別部１０３は、送信した情報に対応する情報を有するエントリがある場合、そのエントリに対応するフローＩＤをフロー識別テーブル１６１から取得する。そして、フローＩＤを取得することができた場合、フロー識別部１０３は、該当するフローを検出したと判定する。

該当するフローを検出した場合（ステップＳ１０２：肯定）、フロー識別部１０３は、パケットのエントリ情報をＦｏｕｎｄとする。さらに、フロー識別部１０３は、そのフロー識別テーブル１６１におけるそのフローＩＤに対応する頻度情報を１つインクリメントする（ステップＳ１０３）。

これに対して、該当するフローを検出しない場合（ステップＳ１０２：否定）、フロー識別部１０３は、フロー識別テーブル１６１に空エントリが存在するか否かを判定する（ステップＳ１０４）。

空エントリが存在する場合（ステップＳ１０４：肯定）、フロー識別部１０３は、パケットのエントリ情報をＮｅｗとする。さらに、フロー識別部１０３は、フロー識別テーブル１６１の空エントリにフローの識別情報を登録し、頻度情報を１とする（ステップＳ１０５）。そして、フロー識別部１０３は、登録した空エントリの識別情報をフローＩＤとして取得する。

これに対して、空エントリが存在しない場合（ステップＳ１０４：否定）、フロー識別部１０３は、パケットのエントリ情報をＮｏｔｆｏｕｎｄとする（ステップＳ１０６）。この場合、フロー識別部１０３は、フローＩＤが存在しないことを表す情報をフローＩＤとして取得する。

次に、図９を参照して、フロー識別部１０３によるエントリ管理の流れについて説明する。図９は、フロー識別部によるエントリ管理のフローチャートである。

フロー識別部１０３は、判定タイミングが到来したか否かを判定する（ステップＳ２０１）。判定タイミングが到来していない場合（ステップＳ２０１：否定）、フロー識別部１０３は、判定タイミングが到来するまで待機する。

これに対して、判定タイミングが到来した場合（ステップＳ２０１：肯定）、フロー識別部１０３は、未判定のエントリをフロー識別テーブル１６１から１つ選択する（ステップＳ２０２）。

そして、フロー識別部１０３は、選択したエントリにおける頻度情報が０か否かを判定する（ステップＳ２０３）。頻度情報が０でない場合（ステップＳ２０３：否定）、フロー識別部１０３は、選択したエントリの頻度情報を１つデクリメントする（ステップＳ２０４）。

これに対して、頻度情報が０の場合（ステップＳ２０３：肯定）、フロー識別部１０３は、選択したエントリのフローＩＤに対応するキューカウンタの値をキュー情報管理テーブル１６３から取得する。そして、フロー識別部１０３は、キューカウンタが０か否かを判定する（ステップＳ２０５）。

キューカウンタが０の場合（ステップＳ２０５：肯定）、フロー識別部１０３は、選択したエントリを削除する（ステップＳ２０６）。これに対して、キューカウンタが０でない場合（ステップＳ２０５：否定）、フロー識別部１０３は、ステップＳ２０７へ進む。

その後、フロー識別部１０３は、未判定のエントリが残っているか否かを判定する（ステップＳ２０７）。未判定のエントリが残っている場合（ステップＳ２０７：肯定）、フロー識別部１０３は、ステップＳ２０２へ戻る。

これに対して、未判定のエントリが残っていない場合（ステップＳ２０７：否定）、フロー識別部１０３は、エントリの管理処理を終了する。

次に、図１０を参照して、フロー判別処理部１０４によるフロー判別処理の流れについて説明する。図１０は、フロー判別処理部によるフロー判別処理のフローチャートである。

フロー判別処理部１０４は、パケット情報、送信ポートＩＤ、フローＩＤ及びエントリ情報の入力をフロー識別部１０３から受ける。そして、フロー判別処理部１０４は、エントリ情報がＦｏｕｎｄか否かを判定する（ステップＳ３０１）。エントリ情報がＦｏｕｎｄの場合（ステップＳ３０１：肯定）、フロー判別処理部１０４は、ステップＳ３０４へ進む。

これに対して、エントリ情報がＦｏｕｎｄでない場合（ステップＳ３０１：否定）、フロー判別処理部１０４は、エントリ情報がＮｅｗか否かを判定する（ステップＳ３０２）。

エントリ情報がＮｅｗの場合（ステップＳ３０２：肯定）、フロー判別処理部１０４は、転送量テーブル１６２に新たに取得したフローＩＤに対応するエントリを作成して転送量を初期化する（ステップＳ３０３）。

エントリ情報がＦｏｕｎｄ又はステップＳ３０３の後に、フロー判別処理部１０４は、取得したフローＩＤに対応する転送量テーブル１６２の転送量に取得したパケットの大きさを加算して登録する（ステップＳ３０４）。

その後、フロー判別処理部１０４は、パケットに特定キューが出力キューとして指定されているか否かを判定する（ステップＳ３０５）。

特定キューが指定されていない場合（ステップＳ３０５：否定）、フロー判別処理部１０４は、取得したフローＩＤに対応する転送量が閾値以上か否かを判定する（ステップＳ３０６）。

取得したフローＩＤに対応する転送量が閾値以上の場合（ステップＳ３０６：肯定）、フロー判別処理部１０４は、ロングキューをそのパケットの候補キューとする（ステップＳ３０７）。

これに対して、取得したフローＩＤに対応する転送量が閾値未満の場合（ステップＳ３０６：否定）、フロー判別処理部１０４は、ショートキューをそのパケットの候補キューとする（ステップＳ３０８）。

一方、特定キューが指定されている場合（ステップＳ３０５：肯定）、フロー判別処理部１０４は、特定キューをそのパケットの候補キューとする（ステップＳ３０９）。

また、エントリ情報がＮｅｗでない場合（ステップＳ３０２：否定）、すなわち、エントリ情報がＮｏｔｆｏｕｎｄの場合、フロー判別処理部１０４は、デフォルトのキューをそのパケットの候補キューとする（ステップＳ３１０）。

次に、図１１を参照して、キュー切替処理部１０５によるキューの切り替え処理の流れについて説明する。図１１は、キュー切替処理部によるキューの切り替え処理のフローチャートである。

キュー切替処理部１０５は、パケット情報、フローＩＤ、エントリ情報及び候補キューＩＤの入力をフロー判別処理部１０４から受ける。そして、キュー切替処理部１０５は、エントリ情報がＦｏｕｎｄか否かを判定する（ステップＳ４０１）。

エントリ情報がＦｏｕｎｄの場合（ステップＳ４０１：肯定）、キュー切替処理部１０５は、候補キューと現在のキューのキューＩＤが同一か否かにより、キューの切り替えが発生するか否かを判定する（ステップＳ４０２）。

キューの切り替えが発生する場合（ステップＳ４０２：肯定）、キュー切替処理部１０５は、キュー情報管理テーブル１６３における取得したフローＩＤに対応するキューカウンタの値が０か否かを判定する（ステップＳ４０３）。

キューカウンタが０の場合（ステップＳ４０３：肯定）、キュー切替処理部１０５は、パケットの出力キューを候補キューに切り替える（ステップＳ４０４）。

これに対して、キューの切り替えが発生しない場合（ステップＳ４０２：否定）及びキューカウンタが０でない場合（ステップＳ４０３：否定）、キュー切替処理部１０５は、出力キューを現在のキューに維持する（ステップＳ４０６）。

一方、エントリ情報がＦｏｕｎｄでない場合（ステップＳ４０１：否定）、キュー切替処理部１０５は、エントリ情報がＮｅｗか否かを判定する（ステップＳ４０５）。エントリ情報がＮｅｗでない場合（ステップＳ４０５：否定）、すなわち、エントリ情報がＮｏｔｆｏｕｎｄの場合、キュー切替処理部１０５は、ステップＳ４０８に進む。

これに対して、エントリ情報がＮｅｗの場合（ステップＳ４０５：肯定）、キュー切替処理部１０５は、キュー情報管理テーブル１６３に取得したフローＩＤに対応するエントリを作成して作成したエントリを初期化し（ステップＳ４０７）、ステップＳ４０８に進む。

キュー切替処理部１０５は、出力キューを候補キューに設定する（ステップＳ４０８）。

次に、図１２を参照して、キュー７２０に対するエンキュー処理の流れについて説明する。図１２は、キューに対するエンキュー処理のフローチャートである。

キュー切替処理部１５は、出力するパケットが属するフローＩＤに対応するキュー情報管理テーブル１６３のエントリのキューカウンタを１つインクリメントする（ステップＳ５０１）。

次に、キュー切替処理部１５は、キューＩＤに対応するキュー７２０にパケット情報、フローＩＤ及びパケットをエンキューする（ステップＳ５０２）。

次に、図１３を参照して、キュー７２０に対するデキュー処理の流れについて説明する。図１３は、キューに対するデキュー処理のフローチャートである。

キュー７２０は、パケット情報、フローＩＤ及びパケットをデキューして、送信ポート１８０へ出力する（ステップＳ６０１）。

その後、キュー７２０は、フローＩＤに対応するキュー情報管理テーブル１６３のエントリのキューカウンタを１つデクリメントする（ステップＳ６０２）。

ここで、本実施例では、候補キューを決定するための特徴量として転送量を用いる場合で説明したが、特徴量はフローの種類を判別できる情報であれば他の情報を用いてもよい。例えば、単位時間あたりの転送量の増分を表す転送量の増加速度を特徴量として用いてもよい。この場合、フロー判別処理部１０４は、一定期間毎に転送量の増分を測定し、測定結果が予め決められた増分閾値以上の場合はロングキューを候補キューとし、測定結果が増分閾値未満の場合はショートキューを候補キューとする。

また、本実施例では、特定キュー以外に、ロングキューとショーキューという２種類のキュー７２０にパケットの送信先を分ける場合で説明したが、キュー７２０の数及び種類はこれに限らず、フローの種類に応じた分類が可能であれば他の数や種類のキュー７２０を用いてもよい。

例えば、フロー識別部１０３が、パケット情報を用いて、フローの種類として、ストレージトラフィック、ストリーミング及びそれ以外のフローという分類を行う場合を考える。この場合、キュー７２０は、ストレージトラフィック、ストリーミング及びそれ以外のフローのそれぞれに対応する３種類のキュー７２０が用意される。そして、キュー切替処理部１０５は、フロー判別処理部１０４により判別されたフローの種類に応じてパケットの出力キューを決定する。

また、これらのキューの構成を組み合わせることも可能である。例えば、キュー７２０を、優先キューである特定キュー、ストレレージトラフィックにおけるロングキュー及びショートキュー、ストリーミング用のキュー、並びに、それ以外のトラフィックにおけるロングキュー及びショートキューの６本用意してもよい。

以上に説明したように、本実施例に係るスイッチは、パケットを受信すると、パケットが属するフローを識別し、そのフローに関する特徴量に応じて出力キューの候補を決定する。さらに、スイッチは、候補キューにそのフローに属するパケットが残っていない場合に、候補キューに出力キューを切り替えパケットを切替後の出力キューに格納する。これにより、本実施例に係るスイッチは、パケットの順番を守りつつ、フローの特徴量に応じて自動且つ高速度のフローの判別が可能となり、パケットを格納するキューを動的且つ高速で切り替えることができる。したがって、フローレベルでの制御によりキューの切り替えを行うことができ、通信性能を向上させることができる。

特に、本実施例に係るスイッチは、フロー毎の転送量に応じてパケットの出力キューを切り替えることができ、短いパケットと長いパケットとを分別してキューに格納することができる。これにより、低レイテンシが求められるキューと、高スループットが求められるキューとを分けることができ、各フローの特性に応じたキューの選択を行うことで通信性能を向上させることができる。

次に、実施例２について説明する。本実施例に係るスイッチは、フロー識別テーブルとしてハッシュ値により検索を行うテーブルを用いることが実施例１と異なる。本実施例に係るスイッチも図２のブロック図で表される。以下の説明では、実施例１と同様の各部の動作については説明を省略する。

図１４は、実施例２に係るフロー識別テーブルの一例を示す図である。図１４に示すように、本実施例に係るフロー識別テーブル１６１は、パケット情報に基づくハッシュ値に対応させたアドレスにヘッダ情報が登録される。例えば、本実施例では、送信元ＩＰ、宛先ＩＰ、送信元ポート、宛先ポート及びプロトコルから求めたハッシュ値が用いられる。

フロー識別部１０３は、中継処理部１０２から取得したパケット情報から送信元ＩＰ、宛先ＩＰ、送信元ポート、宛先ポート及びプロトコルを取得する。そして、フロー識別部１０３は、取得した送信元ＩＰ、宛先ＩＰ、送信元ポート、宛先ポート及びプロトコルからハッシュ値を求める。

次に、フロー識別部１０３は、算出したハッシュ値をアドレスとしてフロー識別テーブル１６１を読み出す。そのエントリが使用中であり、読み出したエントリのヘッダ情報がパケットのヘッダ情報と一致する場合、フロー識別部１０３は、パケットのエントリ情報をＦｏｕｎｄとする。また、フロー識別部１０３は、読み出したエントリのアドレス、すなわちハッシュ値をフローＩＤとして取得する。さらに、フロー識別部１０３は、ハッシュ値をアドレスとするエントリの頻度情報を１つインクリメントする。

これに対して、ハッシュ値をアドレスとするエントリが未使用の場合、フロー識別部１０３は、その空きエントリにパケットのヘッダ情報を登録して頻度情報を１とする。そして、フロー識別部１０３は、パケットのエントリ情報をＮｅｗとする。

また、ハッシュ値をアドレスとするエントリが使用中であり、そのエントリのヘッダ情報がパケットのヘッダ情報と一致しない場合、フロー識別部１０３は、そのエントリの頻度情報が０であるかどうかを判定する。そして、頻度情報が０であった場合、フロー識別部１０３は、そのエントリに対応するフローＩＤのキューカウンタの値をキュー情報管理テーブル１６３から取得する。そして、フロー識別部１０３は、キューカウンタが０であれば、そのエントリのヘッダ情報を登録して頻度情報を１とする。さらに、フロー識別部１０３は、パケットのエントリ情報をＮｅｗとする。頻度情報が０でない場合、あるいは頻度情報が０であるがキューカウンタが０でない場合、フロー識別部１０３は、パケットのエントリ情報をＮｏｔｆｏｕｎｄとする。

これらと並行して、フロー識別部１０３は、実施例１と同様に、フロー識別テーブル１６１を定期的にスキャンし、０を最小値として各エントリの頻度情報を１つデクリメントする。

次に、図１５を参照して、本実施例に係るフロー識別部１０３によるフロー識別処理の流れについて説明する。図１５は、実施例２に係るフロー識別部によるフロー識別処理のフローチャートである。

フロー識別部１０３は、中継処理部１０２から取得したパケット情報から送信元ＩＰ、宛先ＩＰ、送信元ポート、宛先ポート及びプロトコルを取得する。そして、フロー識別部１０３は、取得した送信元ＩＰ、宛先ＩＰ、送信元ポート、宛先ポート及びプロトコルからハッシュ値を算出する（ステップＳ７０１）。

次に、フロー識別部１０３は、算出したハッシュ値を用いてフロー識別テーブル１６１からフローを検索する（ステップＳ７０２）。

そして、フロー識別部１０３は、パケットが属するフローに該当するフローがフロー識別テーブル１６１に登録されているか否かを判定する（ステップＳ７０３）。

該当するフローが登録済みの場合（ステップＳ７０３：肯定）、フロー識別部１０３は、エントリ情報をＦｏｕｎｄとして、頻度情報を１つインクリメントする（ステップＳ７０４）。

該当するフローが登録されていない場合（ステップＳ７０３：否定）、フロー識別部１０３は、算出したハッシュ値をアドレスとしてフロー識別テーブル１６１を読み出し、読み出したエントリが未使用エントリであるかいなかを判定する（ステップＳ７０５）。未使用エントリである場合（ステップＳ７０５：肯定）、フロー識別部１０３は、パケットのエントリ情報をＮｅｗとする。さらに、フロー識別部１０３は、空きエントリにハッシュ値を登録して、そのエントリの頻度情報を１とする（ステップＳ７０６）。

これに対して、エントリが使用中の場合（ステップＳ７０５：否定）、フロー識別部１０３は、頻度情報が０で且つキューカウンタも０か否かを判定する（ステップＳ７０７）。

頻度情報が０で且つキューカウンタも０である場合（ステップＳ７０７：肯定）、フロー識別部１０３は、パケットのエントリ情報をＮｅｗとする。さらに、フロー識別部１０３は、空きエントリにハッシュ値を登録して、そのエントリの頻度情報を１とする（ステップＳ７０６）。

これに対して、頻度情報が０でない、又は、キューカウンタが０でない場合（ステップＳ７０７：否定）、フロー識別部１０３は、パケットのエントリ情報をＮｏｔｆｏｕｎｄとする（ステップＳ７０８）。

これらに並行して、フロー識別部１０３は、フロー識別テーブル１６１をスキャンし、０と最小値として各エントリの頻度情報を１つデクリメントする。

ここで、本実施例では、フロー識別部１０３は、パケットを受信した際に空のエントリが無ければその都度、フロー識別テーブル１６１の管理を行う場合で説明したが、フロー識別テーブル１６１の管理のタイミングはこれに限らない。例えば、フロー識別部１０３は、実施例１と同様に一定周期でフロー識別テーブル１６１の管理を繰り返してもよい。逆に、実施例１において、本実施例で説明したタイミングでフロー識別テーブル１６１を管理してもよい。

以上に説明したように、本実施例に係るスイッチは、ハッシュ値を用いてパケットが属するフローが登録済みか否かの判定を行う。このように、ＣＡＭを用いずにハッシュテーブルを用いてフローを検索する場合であっても、スイッチは、フローレベルでの制御によりキューの切り替えを行うことができ、通信性能を向上させることができる。この場合、通常の大容量メモリでフロー識別テーブルを保持することができ、ＣＡＭと比べて、回路規模を小さくすることができ、且つ、消費電力も抑えることができる。

次に、実施例３について説明する。本実施例に係るスイッチは、各フローについて送信ポート毎に異なるエントリを有するキュー情報管理テーブルを用いることが実施例１と異なる。本実施例に係るスイッチも図２のブロック図で表される。以下の説明では、実施例１と同様の各部の動作については説明を省略する。

図１６は、実施例３に係るキュー情報管理テーブルの一例を表す図である。本実施例に係るキュー情報管理テーブル１６３は、１つのフローＩＤに対応するエントリが送信ポート１８０毎に登録される。図１６は各フローＩＤに対応して送信ポート１８１～１８２に対応するエントリが登録された状態を表す。ただし、キュー情報管理テーブル１６３は、には、フローＩＤに属するパケットの現在のキューとして使用中のキュー７２０が接続する送信ポート１８０が登録されていれば、全ての送信ポート１８１～１８２が登録されなくてもよい。

キュー切替処理部１０５は、キュー情報管理テーブル１６３を用いて、各送信ポート１８０に接続される送信キューセット１７０毎に、パケットの格納状態を管理する。この場合も、キュー切替処理部１０５は、送信ポート１８０毎に、現在のキューと候補キューが異なる場合には、そのパケットが属するフローに対応するキューカウンタが０であれば、候補キューを出力キューとする。

このように、本実施例に係るスイッチは、各フローについて送信ポート毎にエントリを有するキュー情報管理テーブルを用いることで、送信ポート毎の出力キューの切替制御を行うことが可能となる。したがって、本実施例に係るスイッチは、実施例１の場合に比べてより適切なタイミングでキューの切り替えを行うことができ、通信性能をより向上させることができる。

図１７は、実施例４に係るスイッチのブロック図である。本実施例に係るスイッチ１００は、パケット本体はキュー７２０に送らずに、パケットの位置を示すポインタを送ることが実施例１と異なる。以下の説明では、実施例１と同様の各部の動作については説明を省略する。本実施例に係るスイッチ１００は、実施例１の各部に加えて、パケットバッファ１９１及び制御部１９２を有する。

受信ポート１１０は、パケットを受信すると、パケットバッファ１９１に受信したパケットを格納し、パケットバッファ１９１におけるパケットの格納場所を示すポインタを取得する。そして、受信ポート１１０は、パケットの格納場所を示すポインタとともに、中継処理部１０２にパケット情報を出力する。

中継処理部１０２、フロー識別部１０３、フロー判別処理部１０４、キュー切替処理部１０５はそれぞれ、パケット本体に代えて、パケットの格納場所を示すポインタを送信する。

そして、送信キューセット１７０における出力キューとされたキュー７２０には、パケット情報、フローＩＤ及びパケットの格納場所を示すポインタが格納される。

制御部１９２は、出力するパケットのパケット情報及びパケットの格納場所を示すポインタの入力を送信キューセット１７０から受ける。そして、制御部１９２は、パケットの格納場所を示すポインタを用いてパケットバッファ１９１に格納されたパケット本体を取得する。そして、制御部１９２は、パケット情報とパケット本体とを合わせて、パケットを出力した送信キューセット１７０に対応する送信ポート１８０へ出力する。

以上に説明したように、本実施例に係るスイッチは、パケット本体はキューに流さずにパケットの位置を示すポインタを流して、キューから出力されたポインタに応じてパケット本体を取得して出力する。このように、パケットを他の場所に格納した状態で処理を行っても、実施例１と同様の効果を得ることができる。

（ハードウェア構成）
ここで、以上の各実施例で説明したスイッチ１００は、例えば、ＬＳＩ（Large Scale Integration）で実現可能である。例えば、図２及び１７で例示したデータ保持部１６０及び送信キューセット１７０、並びに、図１７で例示したパケットバッファ１９１は、ＬＳＩを用いた記憶装置により実現される。さらに、ＬＳＩを用いた記憶装置には、図２及び１７で例示された中継処理部１０２、フロー識別部１０３、フロー判別処理部１０４及びキュー切替処理部１０５、並びに、図１７に例示した制御部１９２の機能を実現するプログラムを含む各種プログラムが格納される。

そして、ＬＳＩを用いた制御回路が、記憶装置から各種プログラムを読み出して実行することで、中継処理部１０２、フロー識別部１０３、フロー判別処理部１０４、キュー切替処理部１０５は及び制御部１９２の機能を実現する。特に、ＬＳＩ化されたスイッチ１００の場合、実施例４で示した態様を有する場合が多い。

ストレージトラフィックをイーサネット（登録商標）で実現する技術として、ＮＶＭｅｏＦ（Non Volatile Memory express（登録商標） over Fabric）及びＲｏＣＥ（RDMA（Remote Direct Memory Access ） over Converged Ethernet）といった技術が提案されている。そして、ＲｏＣＥでは、ＤＣＱＣＮ（Data Center Quantized Congestion Notification）という輻輳制御アルゴリズムが用いられることが多い。一方、短時間に通信が集中するマイクロバーストにより、通信性能が低下する現象が発生するおそれがあるため、そのような現象への対応も求められる。

以前は、ネットワークにおける輻輳制御の技術として、キューがいっぱいになった場合に、パケットの破棄を行い、そのパケットの破棄を検出した場合に送信レートを下げているテールドロップと呼ばれる手法が用いられていた。その後、ＥＣＮ（Explicit Congestion Notification）と呼ばれるネットワークにおける輻輳制御技術が用いられてきた。ＥＣＮは以下のような動作で実現される。スイッチが、予めキューの閾値を設定し、キューの長さに応じてパケットにマークを付ける。受信側装置は、パケットにつけられたマークを検出することで輻輳を検知し、送信側装置に輻輳の発生を通知する。送信側装置は、輻輳の発生の通知を受けて送信レートを下げる制御を行う。

その後、マイクロバーストを抑制する輻輳制御技術として、ＭＡ（Microburst Aware）－ＥＣＮという技術が提案された。ＭＡ－ＥＣＮでは、フローの初期時点ではＥＣＮの閾値の小さいキューにパケットを送信し、マイクロバーストが発生した際の突入時のスループットを抑えることで、他のフローへの影響を軽減させる。ＴＣＰ（Transmission Control Protocol）通信では、ＭＡ－ＥＣＮによってマイクロバースト発生時でも通信スループットの低下が抑えられた。

しかしながら、ＲｏＣＥでは、ＭＡ－ＥＣＮを用いても通信スループットの低下が発生する場合がある。これには、以下のような理由がある。ＲｏＣＥで用いる輻輳制御方式のＤＣＱＣＮでは、フローの初期段階から高いレートでパケットを送信し、且つ、キュー長が閾値付近になるように制御がなされる。これは、比較的高い通信レートが求められることと、パケットロスト防ぐためにＰＦＣというフロー制御の技術を用いるためである。この場合、フローの開始時にマイクロバーストが発生した場合にショートキューからの出力が抑制されず、結果的にロングキューからの出力パケットにＥＣＮのためのマークが多く付加されてしまい、ロングキューを用いるフローの転送レートが下がってしまうおそれがある。そこで、ＤＣＱＣＮを用いる構成でマイクロバーストの発生時にも転送レートを低下させないことが求められる。

図１８は、輻輳制御を行うスイッチのブロック図である。本実施例に係るスイッチ１００は、ショートキューの帯域制御を行うことと、輻輳制御を行い且つロングキューのキュー長によってロングキューの輻輳状態を判定し、輻輳状態でなければショートキューを候補とするパケットであってもロングキューへ回すことが実施例１と異なる。以下の説明では、実施例１と同じ各部の機能については説明を省略する。

ここで、本実施例では、図１８に示すように中継処理部１０２をフロー判別処理部１０４とキュー切替処理部１０５との間に配置した。これにより、パケットを出力する送信ポート１８０の決定処理が実施例１よりも後に移動するが、処理の位置の変更以外の変更はほぼない。すなわち、中継処理部１０２は、実施例１と同様にフロー識別部１０３の前に配置してもよい。

各部の間で受け渡しされるデータは、図１９のように示される。図１９は、実施例５におけるスイッチの各地点において受け渡される情報をまとめた図である。すなわち、受信ポート１１０からフロー識別部１０３へ送信される情報として、パケット情報を含む情報セット２１１が送信される。また、フロー識別部１０３からフロー判別処理部１０４へ送信される情報として、パケット情報、フローＩＤ及びエントリ情報を含む情報セット２１２が送信される。また、フロー判別処理部１０４から中継処理部１０２へ送信される情報として、パケット情報、フローＩＤ、エントリ情報及び候補キューＩＤを含む情報セット２１３が送信される。また、中継処理部１０２からキュー切替処理部１０５へ送信される情報として、パケット情報、フローＩＤ、エントリ情報、候補キューＩＤ及び送信ポートＩＤを含む情報セット２１４が送信される。また、キュー切替処理部１０５から送信キューセット１７０へ送信される情報として、パケット情報、フローＩＤ及びキューＩＤを含む情報セット２１５が送信される。

本実施例に係るキュー情報管理テーブル１６３は、図２０に示すようにＦＩＤ、ＱＩＤ及びキューカウンタに加えて、輻輳情報が登録される。図２０は、実施例５におけるキュー情報管理テーブルの一例を示す図である。輻輳情報は、対応するＱＩＤを有するキュー７２０に輻輳が発生しているか否かを表す情報である。ここで本実施例では、全てのポートを１つのエントリで管理したが、キュー情報管理テーブル１６３に、ポート毎にエントリを登録することも可能である。

キュー切替処理部１０５は、パケット本体とともに、パケット情報、フローＩＤ、エントリ情報、候補キューＩＤ及び送信ポートＩＤを含む情報セット２１４の入力を中継処理部１０２から受ける。そして、キュー切替処理部１０５は、エントリ情報を確認する。

エントリ情報がＦｏｕｎｄの場合、キュー切替処理部１０５は、候補キューＩＤを確認し、候補キューがショートキューか否かを判定する。候補キューがロングキューであれば、キュー切替処理部１０５は、その候補キューを維持する。

これに対して、候補キューがショートキューの場合、キュー切替処理部１０５は、キュー情報管理テーブル１６３における各ロングキューの輻輳情報を確認して各ロングキューに輻輳が発生しているか否かを判定する。輻輳が発生していなければ、キュー切替処理部１０５は、候補キューをロングキューとする。これに対して、輻輳が発生している場合、キュー切替処理部１０５は、候補キューをショートキューのまま維持する。

すなわち、キュー切替処理部１０５は、候補キューがショートキューであっても、ロングキューに輻輳が発生していなければ、ロングキューの転送レートは未だ余裕があるので、パケットをロングキューへ出力する。一方、輻輳が発生している場合、キュー切替処理部１０５は、ロングキューの転送レートを維持するため、ショートキューにパケットを振り分ける。

その後、キュー切替処理部１０５は、キューの切り替えが発生するか否かを判定する。キューの切り替えが発生しない場合、キュー切替処理部１０５は、出力キューを候補キューとする。この場合、出力キューを現在のキューのまま維持することになる。

一方、キューの切り替えが発生する場合、キュー切替処理部１０５は、キュー情報管理テーブル１６３における取得したフローＩＤに対応するキューカウンタの値が０であれば、そのフローの出力キューを現在のキューから候補キューに変更する。

これに対して、キューカウンタの値が０でない場合、キュー切替処理部１０５は、そのフローの出力キューを候補キューとされなかった現在のキューのまま維持する。

また、エントリ情報がＮｅｗの場合、キュー切替処理部１０５は、キュー情報管理テーブル１６３に新たに取得したフローＩＤを登録して対応するエントリを作成する。そして、キュー切替処理部１０５は、そのフローの出力キューを候補キューに設定する。

また、エントリ情報がＮｏｔｆｏｕｎｄの場合、キュー切替処理部１０５は、そのフローの出力キューを候補キューに設定する。

その後、キュー切替処理部１０５は、そのフローの出力キューとして決定したキューを有する送信キューセット１７０へパケット、パケット情報及びそのパケットが属するフローのＦＩＤを出力する。さらに、パケットの出力とともに、キュー切替処理部１０５は、出力したパケットの出力キューのキューＩＤをパケットの出力先の送信キューセット１７０へ出力する。また、キュー切替処理部１０５は、出力したパケットが属するフローのフローＩＤ及び加算を指示するコマンドをキュー情報管理テーブル１６３へ出力する。

図２１は、実施例５に係る送信キューセットのブロック図である。送信キューセット１７０は、実施例１と同様に、セレクタ７０１、マルチプレクサ７０３、スケジューラ７０４及び複数のキュー７２１～７２３を有する。

セレクタ７０１は、パケット情報、フローＩＤ及びパケットの入力をキュー切替処理部１０５から受ける。さらに、セレクタ７０１は、そのパケットの出力キューを表すキューＩＤの入力をキュー切替処理部１０５から受ける。そして、セレクタ７０１は、指定されたキューＩＤを有するキュー７２０にパケット情報、フローＩＤ及びパケットを出力する。

キュー切替処理部１０５から入力されたキューＩＤで出力キューとして指定されたキュー７２０は、パケット情報、フローＩＤ及びパケットの入力をセレクタ７０１から受ける。そして、キュー７２０は、入力されたパケット情報、フローＩＤ及びパケットを格納する。その後、キュー７２０は、取得タイミングの古い順に保持するパケット情報、フローＩＤ及びパケットをマルチプレクサ７０３へ順次出力していく。さらに、キュー７２０は、自己のキュー長と予め決められた輻輳閾値とを比較し、キュー長が閾値以上の場合、輻輳情報として輻輳発生をキュー情報管理テーブル１６３に登録する。これに対して、キュー長が閾値未満の場合、キュー７２０は、輻輳情報として輻輳未発生をキュー情報管理テーブル１６３に登録する。

輻輳制御部１０９は、各送信キューセット１７１における輻輳を判定するためのキュー長である輻輳判定閾値を有する。そして、輻輳制御部１０９は、各送信キューセット１７１のキュー長を取得する。図１８では、図示の都合上、輻輳制御部１０９と送信キューセット１７１との間の通信経路を示したが、実際には、輻輳制御部１０９は、他の送信キューセット１７０と間にも通信経路を有する。輻輳制御部１０９は、あるキュー７００のキュー長が輻輳判定閾値を超えた場合、そのキュー７００から出力されるパケットに輻輳発生を表すマークを付加する。輻輳制御部１０９がマークを付加することで、スイッチ１００を介してパケットの送受信を行うサーバ２００は、マークにしたがってパケットの送信量を制御して輻輳を解消することができる。

スケジューラ７０４は、各キュー７２０のそれぞれの出力帯域についての帯域指定値を予め有する。この帯域指定地が、「所定値」の一例にあたる。そして、スケジューラ７０４は、各キュー７２０について、空でければ単位時間の出力データ量である出力帯域を算出する。そして、スケジューラ７０４は、あるキュー７２０について、算出した出力帯域が帯域指定値未満の場合、そのキュー７２０からのパケットの出力を決定する。その後、スケジューラ７０４は、出力を決定した複数のキュー７２０に対してマルチプレクサ７０３が出力するパケットの調停を行う。このスケジューラ７０４が、「帯域制御部」の一例にあたる。

マルチプレクサ７０３は、スケジューラ７０４からの指定にしたがって、パケット情報及びパケットを送信ポート１８０へ出力する。さらに、マルチプレクサ７０３は、パケットが属するフローのフローＩＤを、減算を指示するコマンドとともにキュー情報管理テーブル１６３へ出力する。

次に、図２２を参照して、本実施例に係るキュー切替処理部１０５によるキューの切り替え処理の流れについて説明する。図２２は、実施例５に係るキュー切替処理部によるキューの切り替え処理のフローチャートである。

キュー切替処理部１０５は、パケット情報、フローＩＤ、エントリ情報、候補キューＩＤ及び送信ポートＩＤの入力を中継処理部１０２から受ける。そして、キュー切替処理部１０５は、エントリ情報がＦｏｕｎｄか否かを判定する（ステップＳ８０１）。

エントリ情報がＦｏｕｎｄの場合（ステップＳ８０１：肯定）、キュー切替処理部１０５は、候補キューがショートキューであり、且つ、輻輳が発生していないロングキューが存在するか否かを判定する。ここで、輻輳が発生していないロングキューとは、キュー長が輻輳閾値未満のロングキューである（ステップＳ８０２）。候補キューがロングキューである、又は、輻輳が発生していないロングキューが存在しない場合（ステップＳ８０２：否定）、キュー切替処理部１０５は、ステップＳ８０４へ進む。

候補キューがショートキューであり、輻輳が発生していないロングキューが存在する場合（ステップＳ８０２：肯定）、キュー切替処理部１０５は、ロングキューを候補キューとする（ステップＳ８０３）。

次に、キュー切替処理部１０５は、候補キューと現在のキューのキューＩＤが同一か否かにより、キューの切り替えが発生するか否かを判定する（ステップＳ８０４）。

キューの切り替えが発生する場合（ステップＳ８０４：肯定）、キュー切替処理部１０５は、キュー情報管理テーブル１６３における取得したフローＩＤに対応するキューカウンタの値が０か否かを判定する（ステップＳ８０５）。

キューカウンタが０の場合（ステップＳ８０５：肯定）、キュー切替処理部１０５は、パケットの出力キューを候補キューに切り替える（ステップＳ８０６）。

これに対して、キューの切り替えが発生しない場合（ステップＳ８０４：否定）及びキューカウンタが０でない場合（ステップＳ８０５：否定）、キュー切替処理部１０５は、出力キューを現在のキューに維持する（ステップＳ８０７）。

一方、エントリ情報がＦｏｕｎｄでない場合（ステップＳ８０１：否定）、キュー切替処理部１０５は、エントリ情報がＮｅｗか否かを判定する（ステップＳ８０８）。エントリ情報がＮｅｗでない場合（ステップＳ８０８：否定）、すなわち、エントリ情報がＮｏｔｆｏｕｎｄの場合、キュー切替処理部１０５は、ステップＳ８１０に進む。

これに対して、エントリ情報がＮｅｗの場合（ステップＳ８０８：肯定）、キュー切替処理部１０５は、キュー情報管理テーブル１６３に取得したフローＩＤに対応するエントリを作成して作成したエントリを初期化し（ステップＳ８０９）、ステップＳ８１０に進む。

キュー切替処理部１０５は、出力キューを候補キューに設定する（ステップＳ８１０）。

以上に説明したように、本実施例に係るスイッチは、ロングキューの輻輳状態からショートキューを候補キューと判定したパケットをロングキューに回すかショートキューに回すかを判定する。その後、スイッチは、予め決められた帯域幅に抑えられるようにデータを出力させるキューを決定する。これにより、ロングキューの出力レートを高く維持することができ、マイクロバーストなどによる急激な輻輳制御の発生を回避することができる。

次に、実施例６に係るスイッチについて説明する。本実施例に係るスイッチのブロック図も図１８で表される。本実施例に係るスイッチ１００は、輻輳制御を行い、且つ、ＤＲＲ（Deficit Round Robin）を用いてパケットを出力させるキュー７２０のスケジューリングを行うことが実施例５と異なる。以下の説明では、実施例５と同じ各部の機能については説明を省略する。

本実施例に係るキュー情報管理テーブル１６３は、例えば、図６と同様のフォーマットを有する。すなわち、本実施例に係るキュー情報管理テーブル１６３は、輻輳情報を有さなくてもよい。この場合も、キュー情報管理テーブル１６３は、ポート毎にエントリを有してもよい。

そして、本実施例に係るキュー切替処理部１０５は、実施例１と同様の処理を行い、各フローに含まれるパケットの出力キューを決定する。すなわち、キュー切替処理部１０５は、出力キューの決定に各キュー７２０の輻輳状態を考慮しなくてもよい。

さらに、本実施例に係る送信キューセット１７０は、例えば、図７に示す構成を有する。すなわち、本実施例に係る送信キューセット１７０では、キュー７２１は、輻輳状態を判定してキュー情報管理テーブル１６３に登録しなくてもよい。

そして、スケジューラ７０４は、ＤＲＲアルゴリズムを用いて、各キュー７２０の出力帯域が予め指定された割合になるように、パケットを出力させるキュー７２０を選択する。この処理が、「パケットの送信レートが所定の割合になるように制御する」処理の一例にあたる。ここで本実施例では、ＤＤＲアルゴリズムを用いたが、スケジューラ７０４は、各キューの出力帯域を維持するアルゴリズムであれば他のアルゴリズムを用いてもよく、例えば、ＷＲＲ（Weighted Round Robin）やＷＦＱ（Weighted Fair Queuing）などを用いてもよい。

以上に説明したように、本実施例に係るスイッチは、ＤＲＲを用いた帯域制御により、ロングキューにパケットが無い場合に、ショートキューの帯域が制限されずに出力される。これにより、ロングキュー及びショートキューの何れにおいても、データ転送の性能を維持することが可能となる。

図２３は、実施例７に係る情報処理システムのブロック図である。本実施例に係る情報処理システム１は、フロー識別の処理及びフロー判別処理をサーバ２００が行い、スイッチ１００はキュー切替処理を行うことが実施例６と異なる。実施例１と同じ符号を有する各部は特に説明のない限り同じ機能を有する。

サーバ２００は、通信部２２１、フロー判別部２２２、フロー判別テーブル２２３及び受信バッファ２２４を有する。

通信部２２１は、通信相手との間で接続を確立する。そして、通信部２２１は、データの送受信を行いフローを処理する。データ送信時、通信部２２１は、データをフロー判別部２２２へ出力する。

また、通信部２２１は、図示を省略するが、スイッチ１００の送信ポート１８１と接続される。そして、通信部２２１は、送信ポート１８１から出力されたパケットを受信する。受信したパケットにＡＣＫ（Acknowledgement）を含む場合、通信部２２１は、ＡＣＫに対するプロトコル処理を実行する。そして、通信部２２１は、ＡＣＫの受信をフロー判別部２２２へ通知する。また、受信したパケットにデータが含まれる場合、通信部２２１は、データを受信バッファ２２４に格納する。データの送受信完了後、通信部２２１は、接続を切断する。

フロー判別テーブル２２３は、例えば、図２４に示すようなプライオリティとフロー種別との対応を表す情報を有する。プライオリティとは、パケットヘッダのＶＬＡＮ（Virtual Local Area Network）タグに存在するプライオリティのフィールドに登録される値である。図２４は、フロー判別テーブルの一例を表す図である。本実施例では、プライオリティは、０～７の値が存在する。そして、値が３のプライオリティに対応するフロー種別は、転送量の大きいフローを表す「ロング」というフロー種別である。また、値が４のプライオリティに対応するフロー種別は、転送量の小さいフローを表す「ショート」というフロー種別である。それ以外の、値が０～２及び５～７のプライオリティに対応するフロー種別は、「その他」のフロー種別を表す。

フロー判別部２２２は、通信部２２１による通信相手との接続の確立が完了すると、自己が保持するフローの送信量の情報を初期化して０にする。次に、フロー判別部２２２は、送信するパケットを通信部２２１から取得する。次に、フロー判別部２２２は、フローの送信量が予め決められた判別閾値以上か否かを判定する。送信量が判別閾値未満であれば、フロー判別部２２２は、フロー判別テーブル２２３からショートのフローに対応するプライオリティを表す値である「３」を取得する。そして、フロー判別部２２２は、パケットヘッダのＶＬＡＮタグのプライオリティのフィールドに「３」を登録する。

これに対して、送信量が判別閾値以上の場合、フロー判別部２２２は、そのフローに属するパケットの前回送信時において使用したキューがショートキューか否かを判定する。前回の送信時にロングキューを使用した場合、フロー判別部２２２は、フロー判別テーブル２２３からロングのフローに対応するプライオリティを表す値である「４」を取得する。そして、フロー判別部２２２は、パケットヘッダのＶＬＡＮタグのプライオリティのフィールドに「４」を登録する。

これに対して、前回の送信時にショートキューを使用した場合、フロー判別部２２２は、前回のパケット送信に対するＡＣＫの受信の通知を通信部２２１から受けたか否かを判定する。前回のパケット送信に対するＡＣＫの受信の通知を通信部２２１から受けていない場合、パケットがキュー７２０に溜まっている可能性があることからパケットの追い越しを防止するため、フロー判別部２２２は、パケットの送信処理を終了する。

これに対して、前回のパケット送信に対するＡＣＫの受信の通知を通信部２２１から受けた場合、フロー判別部２２２は、パケットがキュー７２０に溜まっている可能性はないと判定する。次に、フロー判別部２２２は、フロー判別テーブル２２３からロングのフローに対応するプライオリティを表す値である「４」を取得する。そして、フロー判別部２２２は、パケットヘッダのＶＬＡＮタグのプライオリティのフィールドに「４」を登録する。

そして、フロー判別部２２２は、プライオリティフィールドに値が設定されたパケットをスイッチ１００へ送信する。さらに、フロー判別部２２２は、フローの送信量にパケット長を加算する。その後、フロー判別部２２２は、そのフローに属する次のパケットの送信の処理に移る。このフロー判別部２２２が、「第１通信装置における送信制御部」の一例にあたる。

スイッチ１００は、受信ポート１１０、中継処理部１０２、キュー切替処理部１０５、輻輳制御部１０９、送信キューセット１７０、送信ポート１８０及び中継テーブル１２１を有する。中継テーブル１２１は、アドレスに対応する送信ポート１８０の情報が登録される。送信ポート１８０の情報には、送信ポート１８０へパケットを出力するキュー７００のキューＩＤや送信ポート１８０の識別情報などが含まれる。

受信ポート１１０は、プライオリティフィールドに値が設定されたパケットをサーバ２２０から受信する。そして、受信ポート１１０は、受信したパケットをフロー判別処理部１０４へ出力する。

フロー判別処理部１０４は、パケットの入力を受信ポート１１０から受ける。そして、フロー判別処理部１０４は、パケットヘッダのプライオリティフィールドに設定された値を取得する。プライオリティフィールドに設定された値が３の場合、フロー判別処理部１０４は、パケットの出力キューをロングキューとする。また、プライオリティフィールドに設定された値が４の場合、フロー判別処理部１０４は、パケットの出力キューをショートキューとする。そして、キュー切替処理部１０５は、出力キューの指定情報とともにパケットを中継処理部１０２へ出力する。

中継処理部１０２は、出力キューの指定情報とともにパケットの入力をフロー判別処理部１０４から受ける。そして、中継処理部１０２は、パケットヘッダから宛先のアドレスを取得する。次に、中継処理部１０２は、取得したアドレスに対応する送信ポート１８０の情報を中継テーブル１２１から取得する。その後、中継処理部１０２は、パケットを送信する送信ポート１８０の情報及び出力キューの指定情報とともにパケットをキュー切替処理部１０５へ出力する。

キュー切替処理部１０５は、送信ポート１８０の情報及び出力キューの指定情報とともにパケットの入力を中継処理部１０２から受ける。そして、キュー切替処理部１０５は、送信ポート１８０の情報で指定された送信キューセット１７０におけるキュー７２０のうち、出力キューの指定情報に応じたキュー７２０へパケットを格納する。

スケジューラ７０４は、ＤＲＲアルゴリズムを用いて、各キュー７２０の出力帯域が予め指定された割合になるように、パケットを出力させるキュー７２０を選択する。ここで本実施例では、ＤＤＲアルゴリズムを用いたが、スケジューラ７０４は、各キューの出力帯域を維持するアルゴリズムであれば他のアルゴリズムを用いてもよく、例えば、ＷＲＲやＷＦＱなどを用いてもよい。マルチプレクサ７０３は、スケジューラ７０４により選択されたキュー７２０からパケットを取得して送信ポート１８０へ出力する。

次に、図２５～２７を参照して、本実施例に係るサーバ２００によるフロー管理処理の流れについて説明する。図２５は、実施例７に係るサーバによるフロー管理の全体的な処理のフローチャートである。図２６は、実施例７に係るサーバによる送信処理のフローチャートである。図２７は、実施例７に係るサーバによる受信処理のフローチャートである。

図２５を参照して、本実施例に係るサーバ２００によるフロー管理処理の全体的な流れを説明する。

通信部２２１は、通信相手との間の接続を確立する（ステップＳ９０１）。

フロー判別部２２２は、フローの送信量の情報を初期化して０にする（ステップＳ９０２）。

次に、フロー判別部２２２は、通信相手にパケットを送信する送信処理を実行する（ステップＳ９０３）。

その後、通信部２２１は、通信相手からパケットを受信する受信処理を実行する（ステップＳ９０４）。

通信部２２１は、通信相手との接続を切断するか否かを判定する（ステップＳ９０５）。接続を切断しない場合（ステップＳ９０５：否定）、フロー管理の処理はステップＳ９０３へ戻る。

これに対して、接続を切断する場合（ステップＳ９０５：肯定）、通信部２２１は、通信相手との接続を切断し通信を終了する（ステップＳ９０６）。これにより、フロー管理の処理も終了する。

次に、図２６を参照して、サーバ２００におけるパケットの送信処理の流れについて説明する。図２６に記載したフローに含まれる各処理は、図２５におけるステップＳ９０３で実行される処理の一例にあたる。

フロー判別部２２２は、通信部２２１からパケットの入力を受けたか否かにより、送信パケットがあるか否かを判定する（ステップＳ９１１）。送信するパケットがない場合（ステップＳ９１１：否定）、フロー判別部２２２は、パケットの送信処理を終了する。

これに対して、送信するパケットがある場合（ステップＳ９１１：肯定）、フロー判別部２２２は、送信量が判別閾値以上か否かを判定する（ステップＳ９１２）。送信量が判別閾値未満の場合（ステップＳ９１２：否定）、フロー判別部２２２は、フロー種別を表す情報としてショートの情報をパケットに付加する（ステップＳ９１３）。

これに対して、送信量が判別閾値以上の場合（ステップＳ９１２：肯定）、フロー判別部２２２は、そのフローに属するパケットの前回送信時において使用したキューがショートキューか否かを判定する（ステップＳ９１４）。前回の送信時にロングキューを使用した場合（ステップＳ９１４：否定）、フロー判別部２２２は、ステップＳ９１６へ進む。

これに対して、前回の送信時にショートキューを使用した場合（ステップＳ９１４：肯定）、フロー判別部２２２は、前回のパケット送信に対するＡＣＫを受信したか否かを判定する（ステップＳ９１５）。前回のパケット送信に対するＡＣＫを受信していない場合（ステップＳ９１５：否定）、フロー判別部２２２は、パケットの送信処理を終了する。

これに対して、前回のパケット送信に対するＡＣＫの受信の通知を通信部２２１から受けた場合（ステップＳ９１５：肯定）、フロー種別を表す情報としてロングの情報をパケットに付加する（ステップＳ９１６）。

次に、フロー判別部２２２は、プライオリティフィールドに値が設定されたパケットをスイッチ１００へ送信する（ステップＳ９１７）。

次に、フロー判別部２２２は、フローの送信量にパケット長を加算する（ステップＳ９１８）。その後、フロー判別部２２２は、ステップＳ９１１に戻る。

次に、図２７を参照して、サーバ２００におけるパケットの受信処理の流れについて説明する。図２７に記載したフローにおける各処理は、図２５におけるステップＳ９０４で実行される処理の一例にあたる。

通信部２２１は、受信パケットがあるか否かを判定する（ステップＳ９２１）。受信パケットがない場合（ステップＳ９２１：否定）、通信部２２１は、パケットの受信処理を終了する。

これに対して、受信パケットがある場合（ステップＳ９２１：肯定）、通信部２２１は、パケットを受信する（ステップＳ９２２）。

次に、通信部２２１は、受信したパケットがＡＣＫを含むパケットであれば、ＡＣＫを含むプロトコル処理を実行する（ステップＳ９２３）。そして、通信部２２１は、ＡＣＫの受信をフロー判別部２２２へ通知する。

次に、通信部２２１は、受信したパケットにデータが含まれる場合、パケットからデータを取得して受信バッファ２２４に格納する（ステップＳ９２４）。その後、通信部２２１は、ステップＳ９２１へ戻る。

以上に説明したように、本実施例に係る情報処理システムは、サーバ側でフローの種別の管理やパケットの追い越し防止の処理を実行し、スイッチ側で輻輳の発生を抑えるキュースケジューリングを実行する。このように、フローの管理処理と輻輳制御の処理をサーバとスイッチで分離しても、ロングキュー及びショートキューの何れにおいても、データ転送の性能を維持することができる。また、本実施例に係る構成の場合、スイッチでは通常の輻輳制御を行うため、特別なスイッチを用意しなくてもよい。そのため、本実施例に係る情報処理システムは導入が容易である。

図２８は、実施例５のスイッチを用いた場合の効果を説明するための図である。グラフ９１は、実施例５のスイッチ１００を用いない場合のマイクロバースト発生時のスループットの変化を表す。また、グラフ９５は、実施例５のスイッチ１００を用いた場合のマイクロバースト発生時のスループットの変化を表す。グラフ９１及び９５ともに縦軸でスループットを表し、横軸で時間を表す。

グラフ９１における線分９２がロングキューにおけるスループットを表す。また、線分９３がショートキューにおけるスループットを表す。そして、線分９４がロングキューとショートキューとを合わせたスループットを表す。

線分９３に示すように、マイクロバーストの発生によりショートキューでは時々スループットが急上昇する。そして、線分９２に示すように、ショートキューにおけるスループットの急上昇に影響を受けて、ロングキューのスループットは、マイクロバースト発生時に降下する。これにより、全体のスループットも、線分９４に示すようにマイクロバースト発生時に低下する。

一方、グラフ９５における線分９６がロングキューにおけるスループットを表す。また、線分９７がショートキューにおけるスループットを表す。そして、線分９８がロングキューとショートキューとを合わせたスループットを表す。

線分９７に示すように、グラフ９１と同様に、マイクロバーストの発生によりショートキューでは時々スループットが急上昇する。しかしながら、ショートキューにおけるスループットの急上昇が発生しても、線分９６に示すように、ロングキューのスループットは影響をほぼ受けずに速度が維持される。この場合、全体のスループットも、線分９８に示すようにマイクロバーストが発生しても速度を維持することができる。ここでは、実施例５のスイッチ１００を例にしたが、実施例６及び７のスイッチ１００でもほぼ同様の効果を得ることが可能である。したがって、実施例５～７で説明したスイッチ１００を用いることで、ＤＣＱＣＮによる輻輳制御を行っても、マイクロバースト発生時における大きな性能低下を回避することができることが分かる。

実施例５～７で説明したスイッチ１００の機能も、例えば、ＬＳＩで実現可能である。例えば、ＬＳＩを用いた記憶装置には、図１８及び２３で例示された中継処理部１０２、フロー識別部１０３、フロー判別処理部１０４及びキュー切替処理部１０５の機能を実現するプログラムを含む各種プログラムが格納される。そして、ＬＳＩを用いた制御回路が、記憶装置から各種プログラムを読み出して実行することで、中継処理部１０２、フロー識別部１０３、フロー判別処理部１０４及びキュー切替処理部１０５の機能を実現する。

また、実施例７で説明したサーバ２００は、ＣＰＵ（Central Processing Unit）及びメモリを有する。メモリには、例えば、図２３で例示した、通信部２２１及びフロー判別部２２２の機能を実現するプログラムを含む各種プログラムが格納される。また、メモリは、受信バッファ２２４の機能を実現する。また、メモリは、フロー判別テーブル２２３を格納する。ＣＰＵは、メモリから各種プログラムを読み出して展開して実行することで、通信部２２１及びフロー判別部２２２の機能を実現する。

以上の各実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）前記フローに関する特徴量を取得する特徴量取得部と、
前記特徴量取得部により取得された前記特徴量を基に前記フローの前記パケットの送信を制御する送信制御部と
を備えたことを特徴とする情報処理装置。

（付記２）前記パケットを格納し、格納した前記パケットを順次出力する複数のキューをさらに備え、
前記送信制御部は、前記特徴量取得部により取得された前記特徴量を基に前記フローの前記パケットを送信するキューを決定し、前記フローの前記パケットを決定した前記キューに送信する
ことを特徴とする付記１に記載の情報処理装置。

（付記３）前記送信制御部は、前記フローの前記パケットが前記キューのいずれにも蓄積されていない場合に、前記フローの前記パケットを決定した前記キューに送信することを特徴とする付記２に記載の情報処理装置。

（付記４）前記送信制御部は、前記特徴量に関する閾値を予め有し、前記フローの前記特徴量が前記閾値以上の場合に第１キューを前記フローの前記パケットを送信するキューと決定し、前記フローの前記特徴量が前記閾値未満の場合に第２キューを前記フローのパケットを送信するキューに決定することを特徴とする付記２又は３に記載の情報処理装置。

（付記５）前記特徴量取得部は、前記特徴量として前記パケットの転送量を取得し、
前記送信制御部は、転送量閾値を予め有し、前記転送量が前記転送量閾値以上の場合に第１キューを前記フローの前記パケットを送信する送信キューと決定し、前記転送量が前記転送量閾値未満の場合に第２キューを前記フローの前記パケットを送信するキューに決定することを特徴とする付記２～４のいずれか一つに記載の情報処理装置。

（付記６）前記パケットの送信レートが所定値以下となるように制御する帯域制御部と、
前記パケットの輻輳を抑制する輻輳制御部とをさらに備え、
前記送信制御部）は、前記特徴量に加えて前記パケットの滞留量を基に、前記パケットを送信するキューを決定する
ことを特徴とする付記１～５のいずれか一つに記載の情報処理装置。

（付記７）前記パケットの送信レートが所定の割合になるように制御する帯域制御部と、
前記パケットの輻輳を抑制する輻輳制御部と
をさらに備えたことを特徴とする付記１～５のいずれか一つに記載の情報処理装置。

（付記８）第１通信装置、第２通信装置との間でパケット処理部を介して通信を行う情報処理システムであって、
前記第１通信装置は、前記第２通信装置を送信先とするパケットを前記パケット処理部を介して送信し、
前記第２通信装置は、前記第１通信装置を送信元とするパケットを前記パケット処理部を介して受信し、
前記パケット処理部は、
前記第１通信装置から送信された前記第２通信装置宛の複数のパケットの送信処理のフローを識別するフロー識別部と、
前記フローに関する特徴量を取得する特徴量取得部と、
前記特徴量取得部により取得された前記特徴量を基に前記フローの前記パケットの前記第２通信装置への送信を制御する送信制御部とを備えた
ことを特徴とする情報処理システム。

（付記９）前記第１通信装置と第２の通信装置との間に設けられたスイッチを備え、
前記スイッチは、前記パケット処理部を備える
ことを特徴とする付記８記載の情報処理システム。

（付記１０）前記第１通信装置と前記第２通信装置との間に設けられたスイッチを備え、
前記第１通信装置は、前記パケット処理部を備え、
前記スイッチは、
前記パケットの送信レートが所定の割合になるように制御する帯域制御部と、
前記パケットの輻輳を抑制する輻輳制御部とを備え、
前記第２通信装置は、前記第１通信装置を送信元とするパケットを前記スイッチから受信する
ことを特徴とする付記８記載の情報処理システム。

（付記１１）複数のパケットを送信する処理のフローを識別し、
前記フローに関する特徴量を取得し、
取得した前記特徴量を基に前記フローの前記パケットの送信を制御する
処理をコンピュータに実行させることを特徴とする情報処理プログラム。

１ 情報処理システム
１００ スイッチ
１０２ 中継処理部
１０３ フロー識別部
１０４ フロー判別処理部
１０５ キュー切替処理部
１０６ データ保持部
１０９ 輻輳制御部
１１０～１１２ 受信ポート
１２１ 中継テーブル
１６１ フロー識別テーブル
１６２ 転送量テーブル
１６３ キュー情報管理テーブル
１７０～１７２ 送信キューセット
１８０～１８２ 送信ポート
１９１ パケットバッファ
１９２ 制御部
２００～２０６ サーバ
２２１ 通信部
２２２ フロー判別部
２２３ フロー判別テーブル
２２４ 受信バッファ
７０１ セレクタ
７０３ マルチプレクサ
７０４ スケジューラ
７２０～７２３ キュー

Claims (9)

1. 複数のパケットが属するフローについて、前記パケットを格納し、格納した前記パケットを順次出力する複数のキューと、
   受信した前記パケットのヘッダ情報を取得して、取得した前記ヘッダ情報を基に前記フローの識別情報を取得し、受信したパケットの数に応じて前記フローの使用頻度を求め、前記識別情報及び前記使用頻度を管理テーブルの前記識別情報に対応する位置に登録し、且つ、前記使用頻度を基に、前記フローの前記パケットが当該フローのパケットを送信するキューとして決定されているキューに残っているか否かを判定し、当該フローのパケットを送信するキューとして決定されているキューに前記フローの前記パケットが残っていない場合、前記フローを前記管理テーブルから削除するフロー識別部と、
   前記フローに関する特徴量を取得する特徴量取得部と、
   前記フローが前記管理テーブルに登録されていない場合、所定キューを前記フローのパケットを送信するキューと決定し、前記フローが前記管理テーブルに登録されている場合、前記特徴量取得部により取得された前記特徴量を基に、前記フローのパケットを送信するキューを決定し、前記フローの前記パケットを決定した前記フローのパケットを送信するキューに格納して送信させる送信制御部と
   を備えたことを特徴とする情報処理装置。
2. 前記送信制御部は、前記フローの前記パケットが前記キューのいずれにも蓄積されていない場合に、前記フローの前記パケットを決定した前記キューに送信することを特徴とする請求項１に記載の情報処理装置。
3. 前記送信制御部は、前記特徴量に関する閾値を予め有し、前記フローの前記特徴量が前記閾値以上の場合に第１キューを前記フローの前記パケットを送信するキューと決定し、前記フローの前記特徴量が前記閾値未満の場合に第２キューを前記フローのパケットを送信するキューに決定することを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記特徴量取得部は、前記特徴量として前記パケットの転送量を取得し、
   前記送信制御部は、転送量閾値を予め有し、前記転送量が前記転送量閾値以上の場合に第１キューを前記フローの前記パケットを送信する送信キューと決定し、前記転送量が前記転送量閾値未満の場合に第２キューを前記フローの前記パケットを送信するキューに決定することを特徴とする請求項１～３のいずれか一つに記載の情報処理装置。
5. 前記パケットの送信レートが所定値以下となるように制御する帯域制御部と、
   前記パケットの輻輳を抑制する輻輳制御部とをさらに備え、
   前記送信制御部は、前記特徴量に加えて前記パケットの滞留量を基に、前記パケットを送信する前記キューを決定する
   ことを特徴とする請求項１～４のいずれか一つに記載の情報処理装置。
6. 前記パケットの送信レートが所定の割合になるように制御する帯域制御部と、
   前記パケットの輻輳を抑制する輻輳制御部と
   をさらに備えたことを特徴とする請求項１～４のいずれか一つに記載の情報処理装置。
7. 前記フロー識別部は、連想メモリに格納された前記管理テーブルに対して前記ヘッダ情報を用いて検索を行うことで前記フローの識別情報を取得する又は前記ヘッダ情報から算出したハッシュ値を用いて前記管理テーブルの検索を行うことで前記フローの識別情報を取得することを特徴とする請求項１～６のいずれか一つに記載の情報処理装置。
8. 第１通信装置、第２通信装置との間でパケット処理部を介して通信を行う情報処理システムであって、
   前記第１通信装置は、前記第２通信装置を送信先とするパケットを前記パケット処理部を介して送信し、
   前記第２通信装置は、前記第１通信装置を送信元とするパケットを前記パケット処理部を介して受信し、
   前記パケット処理部は、
   前記第１通信装置から送信された前記第２通信装置宛の複数のパケットが属するフローについて、前記パケットを格納し、格納した前記パケットを順次出力する複数のキューと、
   受信した前記パケットのヘッダ情報を取得して、取得した前記ヘッダ情報を基に前記フローの識別情報を取得し、受信したパケットの数に応じて前記フローの使用頻度を求め、前記識別情報及び前記使用頻度を管理テーブルの前記識別情報に対応する位置に登録し、且つ、前記使用頻度を基に、前記フローの前記パケットが当該フローのパケットを送信するキューとして決定されているキューに残っているか否かを判定し、当該フローのパケットを送信するキューとして決定されているキューに前記フローの前記パケットが残っていない場合、前記フローを前記管理テーブルから削除するフロー識別部と、
   前記フローに関する特徴量を取得する特徴量取得部と、
   前記フローが前記管理テーブルに登録されていない場合、所定キューを前記フローのパケットを送信するキューと決定し、前記フローが前記管理テーブルに登録されている場合、前記特徴量取得部により取得された前記特徴量を基に、前記フローの前記パケットを送信するキューを決定し、前記フローの前記パケットを決定した前記フローのパケットを送信するキューに格納することで前記第２通信装置へ送信させる送信制御部とを備えた
   ことを特徴とする情報処理システム。
9. 複数のパケットが属するフローについて、受信したパケットのヘッダ情報を取得して、取得した前記ヘッダ情報を基に前記フローの識別情報を取得し、受信したパケットの数に応じて前記フローの使用頻度を求め、前記識別情報及び前記使用頻度を管理テーブルの前記識別情報に対応する位置に登録し、
   前記使用頻度を基に、前記フローの前記パケットが、前記パケットを格納して順次出力する複数のキューのうち当該フローのパケットを送信するキューとして決定されているキューに残っているか否かを判定し、当該フローのパケットを送信するキューとして決定されているキューに前記フローの前記パケットが残っていない場合、前記フローを前記管理テーブルから削除し、
   前記フローに関する特徴量を取得し、
   前記フローが前記管理テーブルに登録されていない場合、所定キューを前記フローのパケットを送信するキューと決定し、前記フローが前記管理テーブルに登録されている場合、取得した前記特徴量を基に、前記フローの前記パケットを送信するキューを決定し、
   前記フローの前記パケットを決定した前記フローの前記パケットを送信するキューに格納して送信させる
   処理をコンピュータに実行させることを特徴とする情報処理プログラム。

Images