(57)【要約】  ネットワーク通信機器において、各転送フレームに優先性を持たせた転送及び廃棄の処理を実現した上で、転送先装置の輻輳を防止するための帯域制限を行う。具体的には、優先度毎にバケットを設け、優先度に従った量のトークンを補充する。更に、それらのバケット評価の前に、共有バケットを１つ設ける。一定周期毎に、優先度毎に設けたバケット内に存在するトークンを全て共有バケットへ譲与する。共有バケットの深さを超えてあふれたトークンは廃棄する。共有バケットのトークンが存在する限り、フレームの優先度に関わらず全てのフレームを平等に評価し、転送する。共有バケットのトークンがない場合、優先的制限へと切り替え、各優先度バケットを評価する。当該フレームの優先度と対応するバケットを確認し、トークンが存在する場合はフレームの転送処理を行う。トークンがない場合はフレームの廃棄処理を行う。
2013073639.tif 000002
【特許請求の範囲】
【請求項１】
コントローラからの制御に従って、受信したフレームをフローとして一律に制御するためのルールとアクションとが定義されたフローエントリを、フローテーブルに登録する手段と、
前記コントローラ宛となるフレームに対して、全てのフレームに対応する共有バケットと、フレームの優先度毎に対応する優先度バケットを設ける手段と、
受信したフレームを、前記コントローラ宛か否かを評価し、前記コントローラ宛となったフレームに対して、前記共有バケットを評価する手段と、
前記共有バケットの評価の結果、転送フレームの優先的帯域制限を行う場合、当該フレームの優先度と対応する優先度バケットを評価し、転送か廃棄かを決定する手段と
を具備する
ネットワーク通信装置。
【請求項２】
請求項１に記載のネットワーク通信装置であって、
受信するフレームの優先度毎に、バケットを設ける手段と、
前記優先度毎に設けたバケットに、優先度に従った量のトークンを補充する手段と、
前記優先度毎に設けたバケットの評価の前に、前記共有バケットを１つ設ける手段と、
一定周期毎に、その時点で前記優先度毎に設けたバケット内に存在するトークンを全て前記共有バケットへ渡す手段と、
前記共有バケットの容量の限度を超えてトークンがあふれた場合、あふれたトークンを廃棄する手段と、
前記共有バケット内のトークンが存在する限り、受信したフレームの優先度に関わらず、全てのフレームを平等に評価し、転送する手段と、
前記共有バケット内のトークンが存在しない場合、優先的制限へと切り替え、前記優先度毎に設けたバケットの評価を行い、受信したフレームの優先度と対応するバケット内にトークンが存在するか確認する手段と、
受信したフレームの優先度と対応するバケット内にトークンが存在する場合、受信したフレームの転送処理を行う手段と、
受信したフレームの優先度と対応するバケット内にトークンが存在しない場合は、受信したフレームの廃棄処理を行う手段と
を更に具備する
ネットワーク通信装置。
【請求項３】
請求項１又は２に記載のネットワーク通信装置であって、
到着したフレームを、フローテーブルの検索に掛ける手段と、
当該フレームがフローエントリにヒットしたか確認する手段と、
当該フレームがフローエントリにヒットした場合、当該フローエントリのアクションが前記コントローラ宛の転送であるか確認する手段と、
当該フローエントリのアクションが前記コントローラ宛の転送以外のアクションである場合、当該アクションに従ったフレームの処理を行う手段と、
当該フレームがフローエントリにヒットせず、未知のフレームであることを前記コントローラに通知する処理を行う場合、或いは、当該フレームがフローエントリにヒットし、当該フローエントリのアクションが前記コントローラ宛の転送の場合、前記共有バケット内のトークンの量を計り、前記共有バケット内にトークンが存在するか確認する手段と、
前記共有バケット内にトークンが存在しない場合、前記優先度毎に設けられたバケット内にトークンが存在するか確認する手段と、
前記共有バケット内にトークンが存在する場合、或いは、前記共有バケット内にトークンが存在せず、当該フレームの優先度バケット内にトークンが存在する場合、前記コントローラ宛のフレームの転送を行う手段と、
前記共有バケット内にトークンが存在する場合、転送されたフレームの量に対応するトークンを、前記共有バケットから減算処理する手段と、
当該フレームの優先度バケット内にトークンが存在する場合、転送されたフレームの量に対応するトークンを、当該優先度バケットから減算処理する手段と、
前記共有バケット内にトークンが存在せず、当該フレームの優先度バケット内にもトークンが存在しない場合、当該フレームを廃棄処理する手段と
を更に具備する
ネットワーク通信装置。
【請求項４】
ネットワーク通信装置により実施される転送フレーム優先的帯域制限方法であって、
コントローラからの制御に従って、受信したフレームをフローとして一律に制御するためのルールとアクションとが定義されたフローエントリを、フローテーブルに登録することと、
前記コントローラ宛となるフレームに対して、全てのフレームに対応する共有バケットと、フレームの優先度毎に対応する優先度バケットを設けることと、
受信したフレームを、前記コントローラ宛か否かを評価し、前記コントローラ宛となったフレームに対して、前記共有バケットを評価することと、
前記共有バケットの評価の結果、転送フレームの優先的帯域制限を行う場合、当該フレームの優先度と対応する優先度バケットを評価し、転送か廃棄かを決定することと
を含む
転送フレーム優先的帯域制限方法。
【請求項５】
請求項４に記載の転送フレーム優先的帯域制限方法であって、
受信するフレームの優先度毎に、バケットを設けることと、
前記優先度毎に設けたバケットに、優先度に従った量のトークンを補充することと、
前記優先度毎に設けたバケットの評価の前に、前記共有バケットを１つ設けることと、
一定周期毎に、その時点で前記優先度毎に設けたバケット内に存在するトークンを全て前記共有バケットへ渡すことと、
前記共有バケットの容量の限度を超えてトークンがあふれた場合、あふれたトークンを廃棄することと、
前記共有バケット内のトークンが存在する限り、受信したフレームの優先度に関わらず、全てのフレームを平等に評価し、転送することと、
前記共有バケット内のトークンが存在しない場合、優先的制限へと切り替え、前記優先度毎に設けたバケットの評価を行い、受信したフレームの優先度と対応するバケット内にトークンが存在するか確認することと、
受信したフレームの優先度と対応するバケット内にトークンが存在する場合、受信したフレームの転送処理を行うことと、
受信したフレームの優先度と対応するバケット内にトークンが存在しない場合は、受信したフレームの廃棄処理を行うことと
を更に含む
転送フレーム優先的帯域制限方法。
【請求項６】
請求項４又は５に記載の転送フレーム優先的帯域制限方法であって、
到着したフレームを、フローテーブルの検索に掛けることと、
当該フレームがフローエントリにヒットしたか確認することと、
当該フレームがフローエントリにヒットした場合、当該フローエントリのアクションが前記コントローラ宛の転送であるか確認することと、
当該フローエントリのアクションが前記コントローラ宛の転送以外のアクションである場合、当該アクションに従ったフレームの処理を行うことと、
当該フレームがフローエントリにヒットせず、未知のフレームであることを前記コントローラに通知する処理を行う場合、或いは、当該フレームがフローエントリにヒットし、当該フローエントリのアクションが前記コントローラ宛の転送の場合、前記共有バケット内のトークンの量を計り、前記共有バケット内にトークンが存在するか確認することと、
前記共有バケット内にトークンが存在しない場合、前記優先度毎に設けられたバケット内にトークンが存在するか確認することと、
前記共有バケット内にトークンが存在する場合、或いは、前記共有バケット内にトークンが存在せず、当該フレームの優先度バケット内にトークンが存在する場合、前記コントローラ宛のフレームの転送を行うことと、
前記共有バケット内にトークンが存在する場合、転送されたフレームの量に対応するトークンを、前記共有バケットから減算処理することと、
当該フレームの優先度バケット内にトークンが存在する場合、転送されたフレームの量に対応するトークンを、当該優先度バケットから減算処理することと、
前記共有バケット内にトークンが存在せず、当該フレームの優先度バケット内にもトークンが存在しない場合、当該フレームを廃棄処理することと
を更に含む
転送フレーム優先的帯域制限方法。
【請求項７】
コントローラからの制御に従って、受信したフレームをフローとして一律に制御するためのルールとアクションとが定義されたフローエントリを、フローテーブルに登録するステップと、
前記コントローラ宛となるフレームに対して、全てのフレームに対応する共有バケットと、フレームの優先度毎に対応する優先度バケットを設けるステップと、
受信したフレームを、前記コントローラ宛か否かを評価し、前記コントローラ宛となったフレームに対して、前記共有バケットを評価するステップと、
前記共有バケットの評価の結果、転送フレームの優先的帯域制限を行う場合、当該フレームの優先度と対応する優先度バケットを評価し、転送か廃棄かを決定するステップと
をネットワーク通信装置に実行させるためのプログラムを格納した
記憶媒体。
【請求項８】
請求項７に記載の記憶媒体であって、
受信するフレームの優先度毎に、バケットを設けるステップと、
前記優先度毎に設けたバケットに、優先度に従った量のトークンを補充するステップと、
前記優先度毎に設けたバケットの評価の前に、前記共有バケットを１つ設けるステップと、
一定周期毎に、その時点で前記優先度毎に設けたバケット内に存在するトークンを全て前記共有バケットへ渡すステップと、
前記共有バケットの容量の限度を超えてトークンがあふれた場合、あふれたトークンを廃棄するステップと、
前記共有バケット内のトークンが存在する限り、受信したフレームの優先度に関わらず、全てのフレームを平等に評価し、転送するステップと、
前記共有バケット内のトークンが存在しない場合、優先的制限へと切り替え、前記優先度毎に設けたバケットの評価を行い、受信したフレームの優先度と対応するバケット内にトークンが存在するか確認するステップと、
受信したフレームの優先度と対応するバケット内にトークンが存在する場合、受信したフレームの転送処理を行うステップと、
受信したフレームの優先度と対応するバケット内にトークンが存在しない場合は、受信したフレームの廃棄処理を行うステップと
を更にネットワーク通信装置に実行させるためのプログラムを格納した
記憶媒体。
【請求項９】
請求項７又は８に記載の記憶媒体であって、
到着したフレームを、フローテーブルの検索に掛けるステップと、
当該フレームがフローエントリにヒットしたか確認するステップと、
当該フレームがフローエントリにヒットした場合、当該フローエントリのアクションが前記コントローラ宛の転送であるか確認するステップと、
当該フローエントリのアクションが前記コントローラ宛の転送以外のアクションである場合、当該アクションに従ったフレームの処理を行うステップと、
当該フレームがフローエントリにヒットせず、未知のフレームであることを前記コントローラに通知する処理を行う場合、或いは、当該フレームがフローエントリにヒットし、当該フローエントリのアクションが前記コントローラ宛の転送の場合、前記共有バケット内のトークンの量を計り、前記共有バケット内にトークンが存在するか確認するステップと、
前記共有バケット内にトークンが存在しない場合、前記優先度毎に設けられたバケット内にトークンが存在するか確認するステップと、
前記共有バケット内にトークンが存在する場合、或いは、前記共有バケット内にトークンが存在せず、当該フレームの優先度バケット内にトークンが存在する場合、前記コントローラ宛のフレームの転送を行うステップと、
前記共有バケット内にトークンが存在する場合、転送されたフレームの量に対応するトークンを、前記共有バケットから減算処理するステップと、
当該フレームの優先度バケット内にトークンが存在する場合、転送されたフレームの量に対応するトークンを、当該優先度バケットから減算処理するステップと、
前記共有バケット内にトークンが存在せず、当該フレームの優先度バケット内にもトークンが存在しない場合、当該フレームを廃棄処理するステップと
を更にネットワーク通信装置に実行させるためのプログラムを格納した
記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク通信装置に関し、特にネットワーク通信装置において転送フレームを優先的に帯域制限する方法に関する。
【背景技術】
【０００２】
従来のネットワーク機器は、外部から負荷分散や片寄等、柔軟性に富んだ制御ができないという問題があった。このため、ネットワークの規模が大きくなると、システムとしての挙動の把握と改善が困難になり、設計や構成変更には多大なコストを伴うことが問題であった。【０００３】
こうした課題を解決するための技術として、ネットワーク機器のパケット転送機能と経路制御機能を分離する手法が考えられている。例えば、パケット転送機能をネットワーク機器が担当し、制御機能をネットワーク機器の外部に分離した制御装置が担当することで、制御装置がパケットの転送を集中して管理することができ、柔軟性に富んだネットワークを構築することが可能になる。【０００４】
［ＣＤ分離型ネットワークの説明］
機能を分離した集中管理型のネットワークの１つとして、コントロールプレーン側の制御装置からデータプレーン側のノード装置を制御するＣＤ（Ｃ：コントロールプレーン／Ｄ：データプレーン）分離型ネットワークが提案されている。【０００５】
ＣＤ分離型ネットワークの一例として、コントローラからスイッチを制御してネットワークの経路制御を行うオープンフロー（ＯｐｅｎＦｌｏｗ）技術を利用したオープンフローネットワークが挙げられる。オープンフロー技術の詳細については、非特許文献１に記載されている。なお、オープンフローネットワークは一例に過ぎない。【０００６】
［オープンフローネットワークの説明］
オープンフローネットワークでは、ＭＡＣアドレスやＩＰアドレス、ポート番号などの組み合わせによって決定される一連の通信を「フロー」として定義し、フロー単位で経路制御、障害回復、負荷分散、最適化を行う。【０００７】
オープンフローネットワークでは、制御装置に相当するオープンフローコントローラ（ＯＦＣ：ＯｐｅｎＦｌｏｗ  Ｃｏｎｔｒｏｌｌｅｒ）が、ノード装置に相当するオープンフロースイッチ（ＯＦＳ：ＯｐｅｎＦｌｏｗ  Ｓｗｉｔｃｈ）の経路制御に関するフローテーブルを操作することにより、オープンフロースイッチの挙動を制御する。【０００８】
コントローラとスイッチの間は、専用線やＳＳＬ（Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔ  Ｌａｙｅｒ）等により保護された通信路である「セキュアチャンネル」セキュアチャンネル（Ｓｅｃｕｒｅ  Ｃｈａｎｎｅｌ）により接続されている。コントローラとスイッチとは、セキュアチャンネルを介して、オープンフロー規約（ＯｐｅｎＦｌｏｗ  Ｐｒｏｔｏｃｏｌ）に準拠したオープンフローメッセージ（ＯｐｅｎＦｌｏｗ  Ｍｅｓｓａｇｅ）を送受信する。【０００９】
オープンフローネットワークにおけるスイッチとは、オープンフローネットワークを形成し、コントローラの制御下にあるエッジスイッチ（Ｅｄｇｅ  Ｓｗｉｔｃｈ）及びコアスイッチ（Ｃｏｒｅ  Ｓｗｉｔｃｈ）のことである。なお、エッジスイッチは、オープンフローネットワークと別のネットワークとの境界に位置するスイッチである。また、コアスイッチは、オープンフローネットワーク内でパケット（ｐａｃｋｅｔ）の中継に使うスイッチである。オープンフローネットワークにおいて、コントローラは、経路上のスイッチのフローテーブルを操作することにより、入力側エッジスイッチ（Ｉｎｇｒｅｓｓ）でのパケットの受信（流入）から出力側エッジスイッチ（Ｅｇｒｅｓｓ）でのパケットの送信（流出）までの一連の流れを制御することができる。【００１０】
パケットは、フレーム（ｆｒａｍｅ）と読み替えても良い。パケットとフレームの違いは、プロトコルが扱うデータの単位（ＰＤＵ：Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  Ｕｎｉｔ）の違いに過ぎない。パケットは、「ＴＣＰ／ＩＰ」（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）のＰＤＵである。一方、フレームは、「イーサネット（登録商標）」（Ｅｔｈｅｒｎｅｔ）のＰＤＵである。【００１１】
フローテーブルとは、フローとして扱うパケットを特定するための判別条件（ルール）と、パケットがルールに適合（マッチ）した回数を示す統計情報と、パケットに対して行うべき処理内容（アクション）の組を定義したフローエントリ（Ｆｌｏｗ  ｅｎｔｒｙ）の集合である。【００１２】
フローエントリのルールは、パケットのヘッダ領域（フィールド）に含まれる各プロトコル階層の情報のいずれか又は全てを用いた様々な組み合わせにより定義され、区別可能である。各プロトコル階層の情報の例として、送信先アドレス（Ｄｅｓｔｉｎａｔｉｏｎ  Ａｄｄｒｅｓｓ）、送信元アドレス（Ｓｏｕｒｃｅ  Ａｄｄｒｅｓｓ）、送信先ポート（Ｄｅｓｔｉｎａｔｉｏｎ  Ｐｏｒｔ）、送信元ポート（Ｓｏｕｒｃｅ  Ｐｏｒｔ）等が考えられる。なお、上記のアドレスには、ＭＡＣアドレス（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ａｄｄｒｅｓｓ）やＩＰアドレス（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ  Ａｄｄｒｅｓｓ）を含むものとする。また、上記に加えて、入口ポート（Ｉｎｇｒｅｓｓ  Ｐｏｒｔ）の情報も、フローエントリのルールとして使用可能である。また、フローエントリのルールとして、フローとして扱うパケットのヘッダ領域の値の一部（又は全部）を、正規表現やワイルドカード「＊」等で表現したものを設定することもできる。【００１３】
フローエントリのアクションは、「パケットを特定のポートに出力／転送する」、「パケットを破棄／廃棄する（削除する）」、「パケットのヘッダを書き換える」といった動作を示す。例えば、スイッチは、フローエントリのアクションに出力ポートの識別情報（出力ポート番号等）が示されていれば、これに該当するポートにパケットを出力し、出力ポートの識別情報が示されていなければ、パケットを破棄する。或いは、スイッチは、フローエントリのアクションにヘッダ情報が示されていれば、当該ヘッダ情報に基づいてパケットのヘッダを書き換える。【００１４】
スイッチは、フローエントリのルールに適合するパケット群（パケット系列）に対して、フローエントリのアクションを実行する。具体的には、スイッチは、パケットを受信すると、フローテーブルから、受信パケットのヘッダ情報に適合するルールを持つフローエントリを検索する。検索の結果、受信パケットのヘッダ情報に適合するルールを持つフローエントリが見つかった場合、当該フローエントリの統計情報を更新すると共に、受信パケットに対して、当該フローエントリのアクションとして指定された動作を実施する。一方、検索の結果、受信パケットのヘッダ情報に適合するルールを持つフローエントリが見つからなかった場合、当該受信パケットを最初のパケット（ｆｉｒｓｔ  ｐａｃｋｅｔ）と判断し、制御チャネルを介して、オープンフローネットワークにおけるコントローラに対して、受信パケット（又はそのコピー）を転送し、受信パケットの送信元・送信先（宛先）等に基づいたパケットの経路計算を要求し、応答としてフローエントリの設定用メッセージを受信し、フローテーブルを更新する。【００１５】
なお、フローテーブルには、低い優先度で、全てのパケットのヘッダ情報に適合するルールを持つデフォルトエントリが登録されている。受信パケットに適合するフローエントリが他に見つからなかった場合、受信パケットは、このデフォルトエントリに適合する。デフォルトエントリのアクションは、「コントローラへの当該受信パケットの問い合わせ情報の送信」である。【００１６】
［オープンフローネットワークの課題］
通常、オープンフローネットワークシステムにおいては、コントローラとスイッチは「１：Ｎ（多）」の接続関係にあることが多い。【００１７】
したがって、コントローラは、多数のスイッチから非制御要求を受け取ることもあるため、その処理能力の限界を超える可能性がある。【００１８】
コントローラが処理能力の限界を超えて処理不能状態になると、各スイッチは制御機能を失い、各スイッチを経由するネットワークが断絶してしまうため、スイッチ側からもコントローラの処理能力の限界を考慮して要求を行う必要があった。【００１９】
また、コントローラの処理能力を保護することに加えて、スイッチ自身の処理能力を保護する必要もあった。【００２０】
したがって、コントローラの処理能力の保護と、スイッチの処理能力の保護との両面から、コントローラとスイッチ間の帯域制限が必要であった。【００２１】
但し、コントローラとスイッチ間の帯域制限については、メッセージの種別によって、オープンフロー機能としての目的や重要度が異なるため、優先的に行う必要がある。【００２２】
優先制御においては、低優先のフレームが無転送状態になることも避けなければならないという課題もあった。【００２３】
［関連技術］
関連する技術として、特許文献１（特開２００５−２４４４１７号公報）に帯域制御装置、帯域制御方法、及び帯域制御プログラムが開示されている。この関連技術では、帯域制限処理部が、トークンバケット（ｔｏｋｅｎ  ｂｕｃｋｅｔ）に残存する残存トークン量Ｘを記憶する。トークン量監視部が、記憶された残存トークン量と最大バーストトークン量とを比較する。優先制御部が、その比較結果に基づいて帯域保証型通信に割り当てられた通信回線容量をベストエフォート型通信に割り当てる。【００２４】
なお、バケット（ｂｕｃｋｅｔ）とは、バケツのことであり、転送すべきネットワークトラフィックを集積する抽象化されたコンテナである。
【先行技術文献】
【特許文献】
【００２５】
【特許文献１】特開２００５−２４４４１７号公報
【非特許文献】
【００２６】
【非特許文献１】“ＯｐｅｎＦｌｏｗ  Ｓｗｉｔｃｈ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ，  Ｖｅｒｓｉｏｎ  １．０．０”，［ｏｎｌｉｎｅ］，Ｄｅｃｅｍｂｅｒ  ３１，２００９，インターネット（ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｏｐｅｎｆｌｏｗｓｗｉｔｃｈ．ｏｒｇ／ｄｏｃｕｍｅｎｔｓ／ｏｐｅｎｆｌｏｗ−ｓｐｅｃ−ｖ１．０．０．ｐｄｆ）
【発明の概要】
【００２７】
ネットワーク通信装置において、転送先装置の輻輳を防止するための帯域制限を行う場合、各転送フレームに優先性を持たせた転送及び廃棄の処理を実現することが課題である。
【００２８】
また、従来の優先制御方式であるＰＱ（Ｐｒｉｏｒｉｔｙ  Ｑｕｅｕｉｎｇ）のように、高い優先度のフレームを大量に受信した場合、低優先のフレームが全く転送されないという問題を解決する必要がある。
【００２９】
一応、上記の問題に対応したＷＦＱ（Ｗｅｉｇｈｔｅｄ  Ｆａｉｒ  Ｑｕｅｕｉｎｇ）や、ＣＢＷＦＱ（Ｃｌａｓｓ−Ｂａｓｅｄ  Ｗｅｉｇｈｔｅｄ  Ｆａｉｒ  Ｑｕｅｕｉｎｇ）等の方式は存在する。しかし、これらの方式は、優先度別に複数設けられたサブキュー（ｓｕｂ  ｑｕｅｕｅ）に詰まれたフレームを優先的に転送制御する方式であり、サブキューのためのメモリリソースが必要であるため、実装においてリソース配分の問題がある。
【００３０】
更に、装置が輻輳していない時には、フレームの優先度に関わらず平等に転送を行い、平等なバースト転送も許容すると好適である。
【００３１】
本発明の目的は、上記の課題を解決した上で、転送先装置の輻輳を防止するために帯域制限を行うネットワーク通信装置を提供することである。
【００３２】
本発明に係るネットワーク通信装置は、コントローラからの制御に従って、受信したフレームをフローとして一律に制御するためのルールとアクションとが定義されたフローエントリを、フローテーブルに登録するオープンフロー処理部２１と、コントローラ宛となるフレームに対して、全てのフレームに対応する共有バケットと、フレームの優先度毎に対応する優先度バケットを設けるバケット設置部と、受信したフレームを、コントローラ宛か否かを評価し、コントローラ宛となったフレームに対して、共有バケットを評価する共有バケット評価部２３と、共有バケットの評価の結果、転送フレームの優先的帯域制限を行う場合、当該フレームの優先度と対応する優先度バケットを評価し、転送か廃棄かを決定する優先度バケット評価部２４とを具備する。
【００３３】
本発明に係る転送フレーム優先的帯域制限方法は、ネットワーク通信装置により実施される転送フレーム優先的帯域制限方法であって、コントローラからの制御に従って、受信したフレームをフローとして一律に制御するためのルールとアクションとが定義されたフローエントリを、フローテーブルに登録することと、コントローラ宛となるフレームに対して、全てのフレームに対応する共有バケットと、フレームの優先度毎に対応する優先度バケットを設けることと、受信したフレームを、コントローラ宛か否かを評価し、コントローラ宛となったフレームに対して、共有バケットを評価することと、共有バケットの評価の結果、転送フレームの優先的帯域制限を行う場合、当該フレームの優先度と対応する優先度バケットを評価し、転送か廃棄かを決定することとを含む。
【００３４】
本発明に係るプログラムは、上記の転送フレーム優先的帯域制限方法における処理を、ネットワーク通信装置に実行させるためのプログラムである。なお、本発明に係るプログラムは、記憶装置や記憶媒体に格納することが可能である。
【００３５】
高優先のフレームが大量に到着した場合でも、各バケットには時間毎に優先度に従った一定量のトークンが補充されるため、低優先のバケットにおいてフレームが無転送状態に陥ることはない。また、優先度に関わらず、各バケットの余っていたトークンは一定周期後に全て共有バケットに補充されるため、共有バケットにて転送フレームの平等転送ができる。フレームは到着順に評価され、トークンの使用有無により即時に転送か廃棄か、という判断がされる。優先度別のサブキューを設ける必要がなく、同時に帯域制限が可能である。
【図面の簡単な説明】
【００３６】
【図１】オープンフローネットワークシステムの構成例を示す図である。
【図２】本発明における優先的帯域制限について説明するための概念図である。
【図３】共有バケットにトークンが存在する事例について説明するための図である。
【図４】優先度バケットにトークンが存在する事例について説明するための図である。
【図５】いずれのバケットにもトークンが存在しない事例について説明するための図である。
【図６】本発明に係るスイッチ（ネットワーク通信装置）の動作を示すフローチャートである。
【図７】共有バケットにトークンが存在する場合のフレーム処理について説明するための図である。
【図８】優先度バケットにトークンが存在する場合のフレーム処理について説明するための図である。
【図９】いずれのバケットにもトークンが存在しない場合のフレーム処理について説明するための図である。
【図１０】本発明に係るスイッチ（ネットワーク通信装置）の基本的な構成例を示す図である。
【図１１】本発明に係るスイッチ（ネットワーク通信装置）の詳細な構成例を示す図である。
【発明を実施するための形態】
【００３７】
本発明は、ＣＤ分離型ネットワークシステムを対象としている。ここでは、ＣＤ分離型ネットワークシステムの１つであるオープンフローネットワークシステムを例に説明する。但し、実際には、オープンフローネットワークシステムに限定されない。
【００３８】
＜実施形態＞
以下に、本発明の実施形態について添付図面を参照して説明する。
【００３９】
［システム構成］
図１に示すように、オープンフローネットワークシステムは、コントローラ１０と、スイッチ２０（２０−ｉ、ｉ＝１〜ｎ：ｎは任意）を含む。
【００４０】
コントローラ１０は、サーバ装置であり、スイッチ２０（２０−ｉ、ｉ＝１〜ｎ）の各々に対して、受信フレームの優先度付けを行う。ここでは、コントローラ１０は、受信フレームの振る舞いが既定されたフローエントリに、優先度情報を付加し、スイッチ２０（２０−ｉ、ｉ＝１〜ｎ）の各々に設定する。
【００４１】
スイッチ２０（２０−ｉ、ｉ＝１〜ｎ）の各々は、ネットワーク通信装置であり、コントローラ１０宛として流入するフレームに対して、優先的帯域制限を行う。スイッチ２０（２０−ｉ、ｉ＝１〜ｎ）の各々は、コントローラ１０宛として流入したフレームを、規定された複数の優先度で分ける。
【００４２】
ここでは、スイッチ２０（２０−ｉ、ｉ＝１〜ｎ）の各々は、フレーム受信時に、フローエントリが登録されているフローテーブルにおいてフレームを評価する。スイッチ２０（２０−ｉ、ｉ＝１〜ｎ）の各々は、優先度が設定されている場合、その優先度に従って、受信フレームの転送制限を行う。
【００４３】
なお、スイッチ２０（２０−ｉ、ｉ＝１〜ｎ）のうち、コントローラ１０にフレームを転送する処理を行うのは、入力側エッジスイッチに相当するスイッチのみでも良い。すなわち、オープンフローネットワークの外部から最初にフレームを受信したスイッチ２０が、本発明の主な対象となる。無論、コアスイッチに相当するスイッチも、コントローラ１０にフレームを転送する処理を行うことは可能であるため、本発明の対象としても良い。
【００４４】
本発明における優先的帯域制限は、トークンバケット（ｔｏｋｅｎ  ｂｕｃｋｅｔ）方式を採用し実現するものである。
【００４５】
本実施形態においては、スイッチ２０（２０−ｉ、ｉ＝１〜ｎ）の１つであり、フレームを受信したスイッチ２０は、コントローラ１０宛となるフレームに対して、１つの共有バケット（優先度に依存しない共通のバケット）と、複数の優先度バケット（優先度別のバケット）を設ける。これらのバケットでは、トークン量とバケットの評価のみ行うものとする。これらのバケットを、評価のための行列や受信から送信までのバッファ（ｂｕｆｆｅｒ）やキュー（ｑｕｅｕｅ）として使用することはない。本実施形態においては、スイッチ２０は、受信バッファからフレームを取り出し、当該フレームに対応するいずれかのバケットにトークンが存在するか確認する。いずれかのバケットにトークンが存在する場合、送信バッファにフレームを転送する。いずれのバケットにもトークンが存在しない場合、廃棄処分にする。トークンやバケットの評価において、フレームがバッファリングされることはない。
【００４６】
まず、フレームを受信したスイッチ２０は、受信したフレームを、コントローラ１０宛か否かを評価し、コントローラ１０宛となったフレームに対して、共有バケットを評価する。
【００４７】
フレームを受信したスイッチ２０は、共有バケットに十分なトークンがない場合、そのフレームの優先度と対応する優先度バケットを評価し、転送か廃棄かを決定する。
【００４８】
［ハードウェアの例示］
以下に、本発明に係るコントローラ１０、及びスイッチ２０（２０−ｉ、ｉ＝１〜ｎ）の各々を実現するための具体的なハードウェアの例について説明する。
【００４９】
コントローラ１０の例として、ＰＣ（パソコン）、アプライアンス（ａｐｐｌｉａｎｃｅ）、シンクライアントサーバ、ワークステーション、メインフレーム、スーパーコンピュータ等の計算機を想定している。なお、コントローラ１０は、端末やサーバに限らず、中継機器や周辺機器でも良い。また、コントローラ１０は、計算機等に搭載される拡張ボードや、物理マシン上に構築された仮想マシン（ＶＭ：Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ）でも良い。
【００５０】
スイッチ２０（２０−ｉ、ｉ＝１〜ｎ）の各々の例として、ネットワークスイッチ（ｎｅｔｗｏｒｋ  ｓｗｉｔｃｈ）、ルータ（ｒｏｕｔｅｒ）、プロキシ（ｐｒｏｘｙ）、ゲートウェイ（ｇａｔｅｗａｙ）、ファイアウォール（ｆｉｒｅｗａｌｌ）、ロードバランサ（ｌｏａｄ  ｂａｌａｎｃｅｒ：負荷分散装置）、帯域制御装置（ｐａｃｋｅｔ  ｓｈａｐｅｒ）、セキュリティ監視制御装置（ＳＣＡＤＡ：Ｓｕｐｅｒｖｉｓｏｒｙ  Ｃｏｎｔｒｏｌ  Ａｎｄ  Ｄａｔａ  Ａｃｑｕｉｓｉｔｉｏｎ）、ゲートキーパー（ｇａｔｅｋｅｅｐｅｒ）、基地局（ｂａｓｅ  ｓｔａｔｉｏｎ）、アクセスポイント（ＡＰ：Ａｃｃｅｓｓ  Ｐｏｉｎｔ）、通信衛星（ＣＳ：Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｓａｔｅｌｌｉｔｅ）、或いは、複数の通信ポートを有する計算機等が考えられる。また、物理マシン上に構築された仮想マシン（ＶＭ）により実現される仮想スイッチでも良い。
【００５１】
上記のようなコントローラ１０、及びスイッチ２０（２０−ｉ、ｉ＝１〜ｎ）の各々は、プログラムに基づいて駆動し所定の処理を実行するプロセッサと、当該プログラムや各種データを記憶するメモリと、ネットワークとの通信に用いられるインターフェースによって実現される。
【００５２】
上記のプロセッサの例として、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）、ネットワークプロセッサ（ＮＰ：Ｎｅｔｗｏｒｋ  Ｐｒｏｃｅｓｓｏｒ）、マイクロプロセッサ（ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ）、マイクロコントローラ（ｍｉｃｒｏｃｏｎｔｒｏｌｌｅｒ）、或いは、専用の機能を有する半導体集積回路（ＬＳＩ：Ｌａｒｇｅ  Ｓｃａｌｅ  Ｉｎｔｅｇｒａｔｉｏｎ）等が考えられる。
【００５３】
上記のメモリの例として、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ  Ｅｒａｓａｂｌｅ  ａｎｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）やフラッシュメモリ等の半導体記憶装置、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）やＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）等の補助記憶装置、又は、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｋ）等のリムーバブルディスクや、ＳＤメモリカード（Ｓｅｃｕｒｅ  Ｄｉｇｉｔａｌ  ｍｅｍｏｒｙ  ｃａｒｄ）等の記憶媒体（メディア）等が考えられる。また、バッファ（ｂｕｆｆｅｒ）やレジスタ（ｒｅｇｉｓｔｅｒ）等でも良い。或いは、ＤＡＳ（Ｄｉｒｅｃｔ  Ａｔｔａｃｈｅｄ  Ｓｔｏｒａｇｅ）、ＦＣ−ＳＡＮ（Ｆｉｂｒｅ  Ｃｈａｎｎｅｌ  −  Ｓｔｏｒａｇｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、ＮＡＳ（Ｎｅｔｗｏｒｋ  Ａｔｔａｃｈｅｄ  Ｓｔｏｒａｇｅ）、ＩＰ−ＳＡＮ（ＩＰ  −  Ｓｔｏｒａｇｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等を用いたストレージ装置でも良い。
【００５４】
なお、上記のプロセッサ及び上記のメモリは、一体化していても良い。例えば、近年では、マイコン等の１チップ化が進んでいる。したがって、電子機器等に搭載される１チップマイコンが、上記のプロセッサ及び上記のメモリを備えている事例も考えられる。
【００５５】
上記のインターフェースの例として、ネットワーク通信に対応した基板（マザーボード、Ｉ／Ｏボード）やチップ等の半導体集積回路、ＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）等のネットワークアダプタや同様の拡張カード、アンテナ等の通信装置、接続口（コネクタ）等の通信ポート等が考えられる。
【００５６】
また、ネットワークの例として、インターネット、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、無線ＬＡＮ（Ｗｉｒｅｌｅｓｓ  ＬＡＮ）、ＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、バックボーン（Ｂａｃｋｂｏｎｅ）、ケーブルテレビ（ＣＡＴＶ）回線、固定電話網、携帯電話網、ＷｉＭＡＸ（ＩＥＥＥ  ８０２．１６ａ）、３Ｇ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ）、専用線（ｌｅａｓｅ  ｌｉｎｅ）、ＩｒＤＡ（Ｉｎｆｒａｒｅｄ  Ｄａｔａ  Ａｓｓｏｃｉａｔｉｏｎ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、シリアル通信回線、データバス等が考えられる。
【００５７】
なお、コントローラ１０、及びスイッチ２０（２０−ｉ、ｉ＝１〜ｎ）の各々の内部の構成要素は、モジュール（ｍｏｄｕｌｅ）、コンポーネント（ｃｏｍｐｏｎｅｎｔ）、或いは専用デバイス、又はこれらの起動（呼出）プログラムでも良い。
【００５８】
但し、実際には、これらの例に限定されない。
【００５９】
［優先的帯域制限］
以下に、本発明における優先的帯域制限について詳細に説明する。
【００６０】
スイッチ２０（２０−ｉ、ｉ＝１〜ｎ）の１つであり、フレームを受信したスイッチ２０は、２種類のトークンバケットを用いて受信フレームの帯域制限評価及び優先度評価を行う。
【００６１】
まず、フレームを受信したスイッチ２０は、フレームの優先度毎に、バケットを設ける。
【００６２】
フレームを受信したスイッチ２０は、優先度毎に設けたバケットに、優先度に従った量のトークンを補充する。
【００６３】
更に、フレームを受信したスイッチ２０は、それらのバケット評価の前に、共有バケットを１つ設ける。
【００６４】
図２に示すように、フレームを受信したスイッチ２０は、ある一定周期毎に、その時点で優先度毎に設けたバケット内に存在するトークンを全て共有バケットへ渡す。
【００６５】
但し、共有バケットの深さ（容量）は、装置のバースト転送許容量に固定されている。フレームを受信したスイッチ２０は、共有バケットの深さ（容量）の限度を超えてトークンがあふれた場合、あふれたトークンを廃棄する。
【００６６】
図３に示すように、フレームを受信したスイッチ２０は、共有バケット内のトークンが存在する限り、フレームの優先度に関わらず、全てのフレームを平等に評価し、転送する。
【００６７】
フレームを受信したスイッチ２０は、共有バケット内のトークンがない場合には、後段階である優先的制限へと切り替え、優先度毎に設けたバケットの評価を行う。
【００６８】
図４に示すように、フレームを受信したスイッチ２０は、優先的制限へと切り替えた際、それぞれのフレームについて、フロー識別時に決定された優先度と対応するバケットを確認して、当該優先度と対応するバケット内にトークンが存在する場合に転送処理する。
【００６９】
図５に示すように、フレームを受信したスイッチ２０は、優先度バケット内にもトークンがない場合は、フレームの廃棄処理を行う。
【００７０】
なお、フレームを受信したスイッチ２０は、高優先のフレームが大量に到着した場合でも、各優先度バケットに対して、一定時間毎に優先度に従った一定量のトークンを補充する。そのため、全ての優先度バケットにおいて、一定時間毎に一定量のトークンが補充されることになり、低優先のバケットにおいてもフレームが無転送状態に陥ることはない。
【００７１】
また、フレームを受信したスイッチ２０は、一定周期後に、フレームの優先度に関わらず、各優先度バケット内のトークンを全て共有バケットに補充する。そのため、一定周期毎に、共有バケット内のトークンが存在することになり、フレームの優先度に関わらず、全てのフレームを平等に評価し、転送することができる。
【００７２】
フレームを受信したスイッチ２０は、フレームを到着順に評価し、トークンの使用有無により、即時に、転送か廃棄かを判断する。
【００７３】
フレームを受信したスイッチ２０は、優先度別のサブキュー（ｓｕｂ  ｑｕｅｕｅ）を設ける必要がなく、同時に帯域制限が可能である。
【００７４】
［スイッチ動作］
図６を参照して、本発明におけるスイッチの動作について説明する。
【００７５】
（１）ステップＳ１０１
スイッチ２０（２０−ｉ、ｉ＝１〜ｎ）のうち、いずれかのスイッチは、到着したフレームを受信する。
【００７６】
（２）ステップＳ１０２
フレームを受信したスイッチ２０は、当該フレームを、フローテーブルの検索に掛ける。すなわち、フレームを受信したスイッチ２０は、当該フレームについて、フローテーブルの検索を行う。
【００７７】
（３）ステップＳ１０３
フレームを受信したスイッチ２０は、当該フレームがフローエントリにヒットしたか確認する。
【００７８】
（４）ステップＳ１０４
フレームを受信したスイッチ２０は、当該フレームがフローエントリにヒットした場合（ステップＳ１０３でＹｅｓ）、そのフローエントリのアクションがコントローラ１０宛の転送であるか確認する。
【００７９】
（５）ステップＳ１０５
フレームを受信したスイッチ２０は、当該フレームがフローエントリにヒットしたとしても、そのフローエントリのアクションがコントローラ１０宛の転送以外のアクションである場合（ステップＳ１０４でＮｏ）、アクションに従ったフレームの処理を行うため、本発明の動作の対象にはならない。すなわち、通常のオープンフローネットワークシステムにおけるフレームの処理を行う。
【００８０】
また、フレームを受信したスイッチ２０は、当該フレームがフローエントリにヒットせず、未知のフレームであることをコントローラ１０に通知するオープンフロー独自の処理を行う場合（ステップＳ１０３でＮｏ）、コントローラ１０宛のフレーム処理のため、本発明の動作の対象となり、共有バケットと優先度バケットの評価を行う。
【００８１】
また、フレームを受信したスイッチ２０は、当該フレームがフローエントリにヒットし、そのフローエントリのアクションがコントローラ１０宛の転送の場合（ステップＳ１０４でＹｅｓ）も同様に、本発明の動作の対象となり、共有バケットと優先度バケットの評価を行う。
【００８２】
（６）ステップＳ１０６
フレームを受信したスイッチ２０は、当該フレームがフローエントリにヒットせず、未知のフレームであることをコントローラ１０に通知するオープンフロー独自の処理を行う場合（ステップＳ１０３でＮｏ）、或いは、当該フレームがフローエントリにヒットし、そのフローエントリのアクションがコントローラ１０宛の転送の場合（ステップＳ１０４でＹｅｓ）、共有バケット内のトークンの量を計り、共有バケット内にトークンが存在するか確認する。
【００８３】
（７）ステップＳ１０７
フレームを受信したスイッチ２０は、共有バケット内にトークンが存在しない場合（ステップＳ１０６でＮｏ）、優先度毎に設けられたバケット内にトークンが存在するか確認する。
【００８４】
（８）ステップＳ１０８
フレームを受信したスイッチ２０は、共有バケット内にトークンが存在する場合（ステップＳ１０６でＹｅｓ）、或いは、共有バケット内にトークンが存在せず、当該フレームの優先度バケット内にトークンが存在する場合（ステップＳ１０７でＹｅｓ）、コントローラ１０宛のフレームの転送を行う。
【００８５】
このとき、図７に示すように、フレームを受信したスイッチ２０は、共有バケット内にトークンが存在する場合、転送されたフレームの量に対応するトークンを、共有バケットから減算処理する。
【００８６】
また、図８に示すように、フレームを受信したスイッチ２０は、当該フレームの優先度バケット内にトークンが存在する場合、転送されたフレームの量に対応するトークンを、当該優先度バケットから減算処理する。
【００８７】
（９）ステップＳ１０９
フレームを受信したスイッチ２０は、共有バケット内にトークンが存在せず、当該フレームの優先度バケット内にもトークンが存在しない場合（ステップＳ１０７でＮｏ）、当該フレームを廃棄処理する。
【００８８】
すなわち、図９に示すように、フレームを受信したスイッチ２０は、共有バケット及び優先度バケットの両方の評価で、トークンが確保されていなかった場合、当該フレームを廃棄処理する。
【００８９】
フレームを受信したスイッチ２０は、優先度バケットに、一定時間毎に、優先度に従って重み付けされた量のトークンを補充する。
【００９０】
すなわち、トークンの補充量は、優先度バケット毎に異なる。
【００９１】
このとき、優先度バケットに補充されたトークンの総量は、フレームを受信したスイッチ２０がコントローラ１０に転送できる最大転送量と一致している。
【００９２】
フレームを受信したスイッチ２０は、優先度バケットへのトークンの補充後、一定時間毎に、全ての優先度バケット内のトークンを全て無条件で共有バケットに譲与することで、共有バケットにトークンを補充する。
【００９３】
但し、共有バケットの深さ（容量）は最大バースト転送量と一致しているため、フレームを受信したスイッチ２０は、深さ（容量）以上のトークンを共有バケットに補充することはなく、余ったトークンについては廃棄する。
【００９４】
フレームを受信したスイッチ２０は、空となった優先度バケットに対しては、規定時間後に、再度重み付けされた量のトークンを補充する。
【００９５】
すなわち、フレームを受信したスイッチ２０は、全ての優先度バケットが空になってから、優先度バケットへのトークンの補充を行う。フレームを受信したスイッチ２０は、優先度バケットを空にするタイミングと規定量補充するタイミングを周期的に管理し、繰り返す。
【００９６】
但し、図２に示すように、共有バケットの補充については、共有バケットが空である必要はない。
【００９７】
［効果の説明］
本発明では、最終評価となる優先度バケットに補充される最大量が、装置最大転送量として規定されており、補充前に一度全ての優先度バケットを空にするという動作から、どの時点においても、最大転送量を超えることがない。そのため、ＱｏＳとしての帯域制御ではなく、転送先装置の処理能力や受信許容範囲を超えないように保護することができる。
【００９８】
また、優先制御の点でいえば、ＷＦＱに似た効果が期待されるが、周期的に優先度バケットのトークンが共有バケットに集約され、共有バケットの範囲内であればフレーム種別に関わらず平等にバースト転送を許容できるというトークンバケット方式の性質的効果も同時に実現可能である。
【００９９】
なお、従来のトークンバケット方式は、帯域制限や優先制御のためのものではなく、帯域量を測定するものである。
【０１００】
一方、本発明では、トークンバケット方式を応用し、優先度毎にバケットを設けることによって優先的帯域制限を実現している。そのため、優先度バケットでは全てのバケットにトークンの補充がなされるので、全ての優先度の帯域保証が可能であり、低優先度のフレームに関しても帯域を保証することができる。
【０１０１】
更に、本発明では、フレームの優先度クラス分別において、従来の優先制御方式のように、優先度別にフレームを格納するためのバッファを設ける必要がないため、メモリリソースが節約でき、実装が容易である。
【０１０２】
＜付記＞
本発明に係るスイッチ２０（２０−ｉ、ｉ＝１〜ｎ）の各々は、以下の付記のように記載することも可能である。但し、実際には、以下の記載例に限定されない。ここでは、記載の簡略化のため、スイッチ２０（２０−ｉ、ｉ＝１〜ｎ）の各々を、「スイッチ２０」と表記する。
【０１０３】
［付記１］
図１０を参照して、本発明に係るスイッチ２０の基本的な構成例について説明する。
【０１０４】
本発明に係るスイッチ２０は、オープンフロー処理部２１と、バケット設定部２２と、共有バケット評価部２３と、優先度バケット評価部２４を備える。
【０１０５】
オープンフロー処理部２１は、コントローラ１０からの制御に従って、受信したフレームをフローとして一律に制御するためのルールとアクションとが定義されたフローエントリを、フローテーブルに登録する。
【０１０６】
バケット設定部２２は、コントローラ１０宛となるフレームに対して、全てのフレームに対応する共有バケットと、フレームの優先度毎に対応する優先度バケットを設ける。
【０１０７】
共有バケット評価部２３は、受信したフレームを、コントローラ１０宛か否かを評価し、コントローラ１０宛となったフレームに対して、共有バケットを評価する。
【０１０８】
優先度バケット評価部２４は、共有バケットの評価の結果、転送フレームの優先的帯域制限を行う場合、当該フレームの優先度と対応する優先度バケットを評価し、転送か廃棄かを決定する。
【０１０９】
［付記２］
図１１を参照して、本発明に係るスイッチ２０の詳細な構成例について説明する。
【０１１０】
なお、図１０と共通する内容については、説明を省略する。
【０１１１】
バケット設定部２２は、優先度バケット設定部２１１と、共有バケット設定部２２２を備える。
【０１１２】
優先度バケット設定部２２１は、受信するフレームの優先度毎に、バケットを設ける。
【０１１３】
共有バケット設定部２２２は、優先度毎に設けたバケットの評価の前に、共有バケットを１つ設ける。
【０１１４】
本発明に係るスイッチ２０は、更に、トークン処理部２５を備える。
【０１１５】
トークン処理部２５は、トークン補充部２５１と、トークン移転部２５２と、トークン廃棄部２５３を備える。
【０１１６】
トークン補充部２５１は、優先度毎に設けたバケットに、優先度に従った量のトークンを補充する。
【０１１７】
トークン移転部２５２は、一定周期毎に、その時点で優先度毎に設けたバケット内に存在するトークンを全て共有バケットへ渡す。
【０１１８】
トークン廃棄部２５３は、共有バケットの容量の限度を超えてトークンがあふれた場合、あふれたトークンを廃棄する。
【０１１９】
共有バケット評価部２３は、共有バケット内のトークンが存在する限り、受信したフレームの優先度に関わらず、全てのフレームを平等に評価し、転送する。
【０１２０】
優先度バケット評価部２４は、共有バケット内のトークンが存在しない場合、優先的制限へと切り替え、優先度毎に設けたバケットの評価を行い、受信したフレームの優先度と対応するバケット内にトークンが存在するか確認する。優先度バケット評価部２４は、確認した結果、受信したフレームの優先度と対応するバケット内にトークンが存在する場合、受信したフレームの転送処理を行う。また、優先度バケット評価部２４は、受信したフレームの優先度と対応するバケット内にトークンが存在しない場合は、受信したフレームの廃棄処理を行う。
【０１２１】
［付記３］
図１０及び図１１を参照して、上記の構成について更に詳細に説明する。
【０１２２】
オープンフロー処理部２１は、到着したフレームをフローテーブルの検索に掛け、当該フレームがフローエントリにヒットしたか確認する。オープンフロー処理部２１は、当該フレームがフローエントリにヒットした場合、当該フローエントリのアクションがコントローラ１０宛の転送であるか確認する。オープンフロー処理部２１は、当該フローエントリのアクションがコントローラ１０宛の転送以外のアクションである場合、当該アクションに従ったフレームの処理を行う。
【０１２３】
共有バケット評価部２３は、当該フレームがフローエントリにヒットせず、未知のフレームであることをコントローラ１０に通知する処理を行う場合、或いは、当該フレームがフローエントリにヒットし、当該フローエントリのアクションがコントローラ１０宛の転送の場合、共有バケット内のトークンの量を計り、共有バケット内にトークンが存在するか確認する。
【０１２４】
優先度バケット評価部２４は、共有バケット内にトークンが存在しない場合、優先度毎に設けられたバケット内にトークンが存在するか確認する。
【０１２５】
オープンフロー処理部２１は、共有バケット内にトークンが存在する場合、或いは、共有バケット内にトークンが存在せず、当該フレームの優先度バケット内にトークンが存在する場合、コントローラ１０宛のフレームの転送を行う。
【０１２６】
共有バケット評価部２３は、共有バケット内にトークンが存在する場合、転送されたフレームの量に対応するトークンを、共有バケットから減算処理する。
【０１２７】
優先度バケット評価部２４は、当該フレームの優先度バケット内にトークンが存在する場合、転送されたフレームの量に対応するトークンを、当該優先度バケットから減算処理する。
【０１２８】
オープンフロー処理部２１は、共有バケット内にトークンが存在せず、当該フレームの優先度バケット内にもトークンが存在しない場合、当該フレームを廃棄処理する。
【０１２９】
［付記４］
なお、上記の構成は、プログラムに基づいて駆動し所定の処理を実行するプロセッサと、当該プログラムや各種データを記憶するメモリと、ネットワークとの通信に用いられるインターフェースによって実現される。
【０１３０】
＜備考＞
以上、本発明の実施形態を詳述してきたが、実際には、上記の実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の変更があっても本発明に含まれる。
【０１３１】
なお、本出願は、日本出願番号特願２０１１−２５０１９１に基づく優先権を主張するものであり、日本出願番号特願２０１１−２５０１９１における開示内容は引用により本出願に組み込まれる。
【図１】
2013073639.tif 000003
【図２】
2013073639.tif 000004
【図３】
2013073639.tif 000005
【図４】
2013073639.tif 000006
【図５】
2013073639.tif 000007
【図６】
2013073639.tif 000008
【図７】
2013073639.tif 000009
【図８】
2013073639.tif 000010
【図９】
2013073639.tif 000011
【図１０】
2013073639.tif 000012
【図１１】
2013073639.tif 000013
【国際調査報告】
2013073639.tif 000014
2013073639.tif 000015