帯域制御方法及び帯域制御装置
【課題】 収容する複数ユーザフローに対して契約帯域を超過したフレームを通信キャリア網へ送信することを抑制し、出力競合が発生する場合でも各ユーザフローの契約帯域分のフレームを送信する。
【解決手段】 ネットワークに接続される通信装置であって、フレームを受信する入力インタフェースと、入力インタフェースで受信したフレームを保持する出力フレームバッファと、入力インタフェースで受信したフレームの読み出し要求通知タイミングをフロー毎に制御する複数の帯域制御部と、複数の帯域制御部から通知される各フローの前記フレーム読み出し要求に基づいて、フレームの読み出しタイミングを決定する出力スケジューラと、出力スケジューラから通知されるタイミングでフレームを出力する出力インタフェースと、を備え、帯域制御部は、フロー毎に保持されるトークン値に基づいて該フローの読み出し要求を出力スケジューラに通知するかしないかを判定し、出力フレームバッファのフレームの蓄積量に基づいて、トークン値の加減算量を決定する。
【解決手段】 ネットワークに接続される通信装置であって、フレームを受信する入力インタフェースと、入力インタフェースで受信したフレームを保持する出力フレームバッファと、入力インタフェースで受信したフレームの読み出し要求通知タイミングをフロー毎に制御する複数の帯域制御部と、複数の帯域制御部から通知される各フローの前記フレーム読み出し要求に基づいて、フレームの読み出しタイミングを決定する出力スケジューラと、出力スケジューラから通知されるタイミングでフレームを出力する出力インタフェースと、を備え、帯域制御部は、フロー毎に保持されるトークン値に基づいて該フローの読み出し要求を出力スケジューラに通知するかしないかを判定し、出力フレームバッファのフレームの蓄積量に基づいて、トークン値の加減算量を決定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケット網の帯域制御に関する帯域制御の方法に関する。
【背景技術】
【０００２】
大容量で安価なイーサネット（商標登録、以下同じ）の普及に伴い、イーサネット専用線サービスが増加している。専用線サービスは高い信頼性が要求される通信サービスであり、専用線サービスを提供するキャリアは、ＳＬＡ（Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ）において規定する帯域を保証する必要がある。
【０００３】
近年のイーサネット専用線サービスでは、通信装置が複数ユーザを論理多重することでシステム構築コストを削減している。ユーザサイトへ接続する専用装置（ユーザアクセス装置）が回線内に複数ユーザフローを収容し、さらに中継装置がユーザアクセス装置を複数多重することで、サービスに必要な通信装置の数は減少する。
【０００４】
イーサネット専用線サービスを提供する通信キャリアは、通信キャリア網のエッジに位置するユーザアクセス装置が収容する各々のユーザフローに対して契約帯域を通信キャリア網内で割当てる。ユーザサイトから通信キャリア網のエッジに位置するユーザアクセス装置へ流入するトラフィックは，平均帯域が契約帯域以下であっても，瞬間的に契約帯域を超過したトラフィックとなる場合がある。この契約帯域を超過したトラフィックが複数のユーザサイトから通信キャリア網に流入すると、通信キャリア網内の中継装置の回線容量を超過し、通信キャリア網内でフレーム廃棄が発生する可能性がある。通信キャリアは、各ユーザフローに対して契約帯域分の通信帯域を通信キャリア網内で保証するためには、通信キャリア網へ流入する各ユーザフローのトラフィックの帯域を常に契約帯域以下に抑える必要がある。尚、通信キャリアはユーザサイト内（すなわち、ユーザ端末とユーザアクセス装置間の）の帯域の変動は保証しない。
【０００５】
通信キャリアは、通信キャリア網内に流入する各ユーザフローのトラフィックの帯域を契約帯域以下に抑えるため、ユーザアクセス装置にシェーパを実装する。ユーザアクセス装置がシェーパを実装することにより通信キャリア網内でのフレーム廃棄確率が小さくなることは、待ち行列理論などで一般的に知られている。
【０００６】
フロー毎に帯域を制御するため、トークンバケツアルゴリズムを用いてシェーパを実現することが特許文献１に開示されている。トークンバケツアルゴリズムは、設定された帯域に対応する速度で帯域制御カウンタ（トークン）を加算し、送信するフレーム長分のトークンが蓄積されていればフレームを送信し、フレーム長分のトークンを減算する。特許文献１では、ユーザトラフィックを複数フローに分類し、フロー毎にバケツの深さを持たせ、各フローの帯域を各フローのトークンバケツアルゴリズムにより制御することが開示されている。これにより、各フローのフレームの送信間隔を平滑化し、送信帯域を制御することを目的としている。 ユーザアクセス装置は、複数ユーザフローを収容する場合は出力競合が発生するため、各ユーザフローのフレームを送信する順番を制御（スケジューリング）する必要がある。各トークンバケツアルゴリズムは、自身が帯域を制御するユーザフローのフレームを送信する際、他ユーザフローのフレームが送信中である場合はフレーム送信を待合わせる必要がある。出力競合はユーザアクセス装置内部の問題であり、ユーザアクセス装置は各ユーザフローの送信可能な帯域が契約帯域を下回らないように保証する必要がある。
【０００７】
そのため、トークンバケツアルゴリズムにおいて、トークンバケツの深さまでトークンの蓄積を可能とし、他ユーザフローのフレーム送信を待合わせる際もトークンを加算する。他ユーザフローのフレームが送信された後、蓄積したトークンに応じて待合わせたフレームを連続送信する。未来時間で待合わせた帯域を補うことで、出力競合が生じる場合でも契約帯域分のフレーム送信を可能とする。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００９−１４７８７４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、トークンバケツの深さまで常にトークンを蓄積すると、単一フローのユーザフレームが通信装置に断続的に到着し、他フローとの出力競合がない場合、通信装置は、蓄積されているトークン量分、単一フローのフレームを連続して送信する。したがって、各フローの契約帯域を超過したトラフィックが通信装置から送信されるという問題があった。 本発明は、前述した問題に鑑みてなされたものであり、収容する複数ユーザフローに対して、他フローとの出力競合が発生した場合には、出力競合で待ち合わせた分の各ユーザフローの契約帯域分のフレームを送信可能としつつ、他フローとの出力競合が発生していない場合には、各フローの契約帯域以下でフレームを送出する帯域制御装置及び帯域制御方法を提供することを目的とする。
以上では、トークンバケツアルゴリズムを用いて説明したが、リーキーバケツアルゴリズムを用いた場合も、他フローとの出力競合が生じた場合に待ち合わせた分の各ユーザフローの契約帯域分のフレームを送信可能とするためには、トークンが一定量以下であればフレームを送信可能とし、トークンを一定量よりも減算できるようにすることが必要となるが、常にトークンを一定量よりも減算できるようにすると、他フローとの出力競合が発生していない場合には、減算されたトークンにより各フローの契約帯域以上でフレームを送出することとなる問題がある。
【課題を解決するための手段】
【００１０】
本発明の代表的な一例を示せば以下のとおりである。すなわち、
ネットワークに接続される通信装置であって、フレームを受信する入力インタフェースと、前記入力インタフェースで受信したフレームを保持する出力フレームバッファと、前記入力インタフェースで受信したフレームの読み出し要求通知タイミングをフロー毎に制御する複数の帯域制御部と、前記複数の帯域制御部から通知される各フローの前記フレーム読み出し要求に基づいて、前記フレームの読み出しタイミングを決定する出力スケジューラと、前記出力スケジューラから通知されるタイミングで前記フレームを出力する出力インタフェースと、を備え、前記帯域制御部は、フロー毎に保持されるトークン値に基づいて該フローの読み出し要求を出力スケジューラに通知するかしないかを判定し、前記出力フレームバッファのフレームの蓄積量に基づいて、前記トークン値の加減算量を決定することを特徴とする。
【発明の効果】
【００１１】
本発明の一実施形態によれば、帯域制御装置は、収容する複数ユーザフローに対して契約帯域を超過したフレームを通信キャリア網へ送信することを抑制し、出力競合が発生する場合でも各ユーザフローの契約帯域分のフレームを送信することができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の第１の実施形態のネットワークシステムの例を示す説明図である。
【図２】本発明の帯域制御装置を通過する前後でのフレーム量の変動を示す図である。
【図３】本発明の第１の実施形態の帯域制御装置の構成を示すブロック図である。
【図４】本発明の第１の実施形態の帯域制御装置の通信フレームに付加される装置内ヘッダのフォーマットの一例を示す説明図である。
【図５】本発明の第１の実施形態の通信フレームのフォーマットの一例を示す説明図である。
【図６】本発明の第１の実施形態の出力フレームバッファ制御部の構成を示すブロック図である。
【図７】本発明の第１の実施形態のバッファ管理レジスタ情報を示す説明図である。
【図８】本発明の第１の実施形態のバッファ書込み処理部が実行するバッファ書込み処理を示すフローチャートである。
【図９】本発明の第１の実施形態のバッファ読出し処理部が実行するバッファ読出し処理を示すフローチャートである。
【図１０】本発明の第１の実施形態の帯域制御部の構成を示すブロック図である。
【図１１】本発明の第１の実施形態の帯域制御部が実行する帯域制御処理を示すフローチャートである。
【図１２】本発明の第１の実施形態の帯域制御方法の概要を示す説明図である。
【図１３】本発明の第２の実施形態の帯域制御装置の構成を示すブロック図である。
【図１４】本発明の第２の実施形態のバッファ管理テーブルを示す説明図である。
【図１５】本発明の第２の実施形態の出力フレームバッファ制御部の構成を示すブロック図である。
【図１６】本発明の第２の実施形態のバッファ書込み処理部が実行するバッファ書込み処理を示すフローチャートである。
【図１７】本発明の第２の実施形態のバッファ読出し処理部が実行するバッファ読出し処理を示すフローチャートである。
【図１８】本発明の第２の実施形態の帯域制御部の構成を示すブロック図である。
【図１９】本発明の第２の実施形態の帯域制御部が実行する帯域制御処理を示すフローチャートである。
【図２０】本発明の第３の実施形態の帯域制御装置の構成を示すブロック図である。
【図２１】本発明の第３の実施形態の出力フレームバッファ制御部の構成を示すブロック図である。
【図２２】本発明の第３の実施形態のバッファ書込み処理部が実行するバッファ書込み処理を示すフローチャートである。
【図２３】本発明の第３の実施形態の帯域制御部の構成を示すブロック図である。
【図２４】本発明の第３の実施形態の帯域制御部が実行する帯域制御処理を示すフローチャートである。
【図２５】本発明の第３の実施形態の帯域制御方法の概要を示す説明図である。
【図２６】本発明の第４の実施形態の帯域制御部の構成を示すブロック図である。
【図２７】本発明の第４の実施形態の帯域制御部が実行する帯域制御処理を示すフローチャートである。
【図２８】本発明の第４の実施形態の帯域制御方法の概要を示す説明図である。
【発明を実施するための形態】
【００１３】
以下、本発明の実施例について、図面を参照して説明する。
【００１４】
＜実施形態１＞
以下、本発明の第１の実施形態について図１から図１２を用いて説明する。なお、以下に述べる第１の実施形態は本発明の実施形態の一つであって、本発明を制限するものではない。
【００１５】
図１は、本発明の第１の実施形態の通信装置を適用するネットワークシステムの例を示す説明図である。
【００１６】
通信キャリア網は、中継装置102-1〜102-n、及び、ユーザアクセス装置(帯域制御装置)101-1〜101-nを備える。中継装置102-1〜102-nは、中継網を構成し、複数のユーザアクセス装置101-1〜101-nを収容する。本発明の第１の実施形態のユーザアクセス装置（帯域制御装置）は、通信キャリア網の端点に設置され、ユーザサイトに設置されたユーザ装置103-1〜nを収容する。ユーザ装置から送信されるフローは、ＳＷ、ユーザアクセス装置（帯域制御装置）、中継装置、対向のユーザアクセス装置、を介して対向のユ-ザ装置に送信される。
【００１７】
通信キャリアは、ユーザアクセス装置（帯域制御装置）が収容する各々のユーザフローに対して契約帯域を割当てる。ユーザサイトから通信キャリア網へ流入するトラフィックは，平均帯域が契約帯域以下であっても，瞬間的に契約帯域を超過したトラフィックとなる。この様子を図２Ａに示した。ユーザ装置103-1から送出される１ユーザフローの送出帯域の時間変化を示す。契約帯域は、図１に示した通信キャリア網内でユーザ装置103-1から送出されるフローに対する契約帯域である。
【００１８】
本願では、帯域制御装置は、以下で説明する帯域制御部（シェーパ）を実装し、各ユーザフローの契約帯域に応じてフレームの送信間隔を平滑化する。
【００１９】
以下に、本発明の帯域制御装置における通信フレームについて説明する。
【００２０】
図５は、本発明の第１の実施形態の通信フレームのフォーマットの一例を示す説明図である。
【００２１】
通信フレーム５は、宛先ＭＡＣアドレス５０１、送信元ＭＡＣアドレス５０２、ＶＬＡＮヘッダ５０３、イーサタイプ値５０４、ペイロード５０５、及び、フレームチェックシーケンス（ＦＣＳ）５０６を含む。宛先ＭＡＣアドレス５０１及び送信元ＭＡＣアドレス５０２には、帯域制御装置１０１、または端末のＭＡＣアドレスが設定される。ＶＬＡＮヘッダ５０３には、フローの識別子となるＶＬＡＮ ＩＤが設定される。
以下に、帯域制御装置１０１の構成について説明する。
【００２２】
図３は、本発明の第１の実施形態の帯域制御装置の構成を示すブロック図である。
【００２３】
帯域制御装置１０１は、複数のネットワークインタフェースボード（ＮＩＦ）（３００−１〜３００−Ｍ）、それぞれのＮＩＦ３００に接続されたスイッチ部３０６を備える。
【００２４】
各ＮＩＦ３００は、通信ポートとなる入出力回線インタフェース３０１、スイッチ部３０６に接続されたＳＷインタフェース３０５、論理回路３５０、及びＮＩＦ管理部１３１１を備える。帯域制御装置１０１は、これらの入出力回線インタフェース３０１を介して、他の装置と接続されている。第１の実施形態では、入出力回線インタフェース３０１は、イーサネット用の回線インタフェースである。
【００２５】
論理回路３５０は、これらの入出力回線インタフェース３０１に接続された入力ヘッダ処理部３０２、入力ヘッダ処理部３０２に接続された入力フレームバッファ制御部３０３、ＳＷインタフェース３０５に接続された出力ヘッダ処理部３０７、出力ヘッダ処理部３０７に接続された出力フレームバッファ制御部１３０８、及び、設定レジスタ３１２を備える。
【００２６】
入出力回線インタフェース３０１は、受信した通信フレーム５に装置内ヘッダ４を付加する。
【００２７】
図４は、入出力回線インタフェース３０１が受信したフレームに付加する装置内ヘッダのフォーマットの一例を示す説明図である。装置内ヘッダ４は、出力ネットワークインタフェースボード識別子（出力ＮＩＦ ＩＤ）４０１、フローＩＤ４０２、及び、フレーム長４０３を含む。このうち、出力ＮＩＦ ＩＤ４０１は、内部ルーティング情報となっており、スイッチ部３０６は、この内部ルーティング情報に従い、入力フレームを特定のネットワークインタフェースボードの特定のＳＷインタフェースに転送する。
【００２８】
入出力回線インタフェース３０１が受信した通信フレーム５に装置内ヘッダ４を付加した時点では、出力ＮＩＦ ＩＤ４０１、フローＩＤ４０２は空欄である。出力ＮＩＦ ＩＤ４０１、及び、フローＩＤ４０２には、入力ヘッダ処理部３０２によって値が設定される。
【００２９】
入力ヘッダ処理部３０２は、受信フレームの５０３に基づいて各入力フレーム（装置内ヘッダ４が付与された通信フレーム５）のフローを識別し、識別されたフローに応じてＶＬＡＮタグの処理を実行し、装置内ヘッダ４に出力ＮＩＦ ＩＤ４０１、及び、フローＩＤ４０２を追加する。ＶＬＡＮタグの処理とは、ＶＬＡＮタグの透過、変換、付与及び削除である。
【００３０】
入力ヘッダ処理部３０２は、ＶＬＡＮタグの処理において、宛先ＭＡＣアドレス５０１及び送信元ＭＡＣアドレス５０２を、入出力回線インタフェース３０１に設定される値で上書きしてもよいし、フロー毎に登録しておいた値で上書きしてもよい。
【００３１】
ＶＬＡＮタグを処理し、装置内ヘッダ４に出力ＮＩＦ ＩＤ４０１及びフローＩＤ４０２を追加した後、入力ヘッダ処理部３０２は、入力フレームを入力フレームバッファ制御部３０３に転送する。
【００３２】
入力フレームバッファ制御部３０３は、入力ヘッダ処理部３０２から入力フレームを受信すると、入力フレームバッファ３０４にフレームを格納する。さらに、入力フレームバッファ３０４に格納されたフレームを読み出し、フレーム間ギャップを調整してＳＷインタフェース３０５に送信する。
【００３３】
スイッチ部３０６は、各ＮＩＦ３００のＳＷインタフェース３０５から入力フレームを受信した後、受信した入力フレームの転送先である出力ＮＩＦ ＩＤ４０１を特定する。次に、スイッチ部３０６は、受信した入力フレームを、出力フレームとして、特定されたＮＩＦ３００に対応するＳＷインタフェース３０５に転送する。
【００３４】
ＳＷインタフェース３０５は、受信した出力フレームを出力ヘッダ処理部３０７に転送する。第１の実施形態では、入力ヘッダ処理部３０２が入力フレームから出力フレームへのフォーマット変換を実行したが、代わりに、出力ヘッダ処理部３０７がフォーマット変換を実行してもよい。なお、入力ヘッダ処理部３０２においてフォーマット変換（ヘッダ変換）がなされている場合には、出力ヘッダ処理部３０７は、ＳＷインタフェース３０５から受信した出力フレームをそのまま出力フレームバッファ制御部１３０８に転送する。
【００３５】
出力フレームバッファ制御部１３０８は、出力フレームをフロー毎の出力フレームバッファ３１０に蓄積する。出力フレームバッファ制御部１３０８は、格納された出力フレームをバッファ管理レジスタ１３０９に設定されたフロー毎の情報を用いてシェーピングしながら出力フレームバッファ３１０から読出し、入出力回線インタフェース３０１に送出する。
【００３６】
入出力回線インタフェース３０１は、出力フレームから装置内ヘッダ４を除去した後、図５に示すフォーマットで出力フレームを他の装置へ転送する。
【００３７】
ＮＩＦ管理部１３１１は、設定レジスタ３１２を制御する。設定レジスタ３１２は、各ブロックのレジスタ値を設定する。
【００３８】
図６は、本発明の第１の実施形態の出力フレームバッファ制御部の構成を示すブロック図である。
【００３９】
出力フレームバッファ制御部１３０８は、フロー制御部１６０４、及び、出力スケジューラ６０５を備える。
【００４０】
また、フロー制御部１６０４は、バッファ書込み処理部１６０１、バッファ読出し処理部１６０２、帯域制御部１６０３、バッファ管理レジスタ１３０９、及び、出力フレームバッファ３１０から構成される。
【００４１】
バッファ書込み処理部１６０１は、出力ヘッダ処理部３０７からのフレームを受信すると、後述するバッファ書込み処理Ｓ１７５０を実施する。バッファ書込み処理部１６０１は、フレームを受信すると、フレームの内部ヘッダのフローＩＤ４０２に基づいてフローを識別し、自フロー制御部で処理すべきフレームであった場合、フレームを出力フレームバッファ３１０に格納し、バッファ管理レジスタ１３０９を更新する。 帯域制御部１６０３は、後述する帯域制御処理Ｓ１９５０を実施し、送信要求を出力スケジューラ６０５に送信する。
【００４２】
出力スケジューラ６０５は、各フロー制御部（１６０４−１〜Ｎ）の帯域制御部１６０３から送信要求を受信すると、読出すフレームをスケジューリングする。出力スケジューラ６０５は、送信要求を各フロー制御部（１６０４−１〜Ｎ）のバッファ読出し処理部１６０２に送信し、バッファ読出し処理部１６０２から受信したフレームを入出力回線インタフェース３０１に送出する。
【００４３】
バッファ読出し処理部１６０２は、出力スケジューラ６０５からフレーム送信要求を受信すると、後述するバッファ読出し処理Ｓ１８５０を実施する。バッファ読出し処理部１６０２は、出力フレームバッファ３１０から読出したフレームを出力スケジューラ６０５に送信し、バッファ管理レジスタ１３０９を更新し、読出通知、及び、読出フレーム長通知を帯域制御部１６０３に送信する。
【００４４】
図７は、本発明の第１の実施形態のバッファ管理レジスタ情報を示す説明図である。
バッファ管理レジスタ１３０９は、バッファ管理レジスタ情報３０として、バッファサイズ：３００１、格納フレーム数：３００２、格納バイト数：３００３、ライトポインタ３００４、及び、リードポインタ３００５を備える。ここで、バッファサイズ３００１は、運用するバッファサイズを示し、格納フレーム数３００２は、バッファに格納されているフレーム数を示し、格納バイト数３００３は、バッファに格納されているバイト数を示し、ライトポインタ３００４は、バッファのライト開始アドレスを示し、リードポインタ３００５は、バッファのリード開始アドレスを示す。
以下に、バッファ書込み処理部１６０１が実行するバッファ書込み処理（Ｓ１７５０）について説明する。
【００４５】
図８は、本発明の第１の実施形態のバッファ書込み処理部が実行するバッファ書込み処理を示すフローチャートである。
【００４６】
バッファ書込み処理部１６０１は、出力ヘッダ処理部３０７からフレームを受信する（Ｓ１７００）と、装置内ヘッダ４からフローＩＤ４０２、及び、フレーム長４０３を取得する（Ｓ１７０１）。
【００４７】
次に、バッファ書込み処理部１６０１は、取得したフローＩＤ４０２が設定レジスタ３１２から設定されたフローＩＤと同一であるか否かを判定する（Ｓ１７０２）。
【００４８】
Ｓ１７０２において、取得したフローＩＤ４０２が設定されたフローＩＤと同一である場合、バッファ管理レジスタ１３０９から、バッファサイズ３００１、ライトポインタ３００４、格納フレーム数３００２、及び、格納バイト数３００３を取得する（Ｓ１７０３）。
【００４９】
次に、バッファ書込み処理部１６０１は、取得した格納バイト数３００３とフレーム長４０３を足し合わせた値と、バッファサイズ３００１を比較する（Ｓ１７０４）。
【００５０】
Ｓ１７０４において、取得した格納バイト数３００３とフレーム長４０３を足し合わせた値がバッファサイズ３００３以下である場合、ライトポインタ３００４、格納フレーム数３００２、及び、格納バイト数３００３を更新し、出力フレームバッファ３１０にフレームを送出し、前記各更新値をバッファ管理レジスタ１３０９に設定し（Ｓ１７０５）、処理を終了する（Ｓ１７０７）。
【００５１】
また、Ｓ１７０２において、取得したフローＩＤ４０２が設定されたフローＩＤと同一でない場合、処理対象外フローのフレームを示しており、フレームを廃棄し（Ｓ１７０６）、処理を終了する（Ｓ１７０７）。
【００５２】
また、Ｓ１７０４において、取得した格納バイト数３００３とフレーム長４０３を足し合わせた値がバッファサイズ３００１より大きい場合、バッファがオーバーフローすることを示しており、フレームを廃棄し（Ｓ１７０６）、処理を終了する（Ｓ１７０７）。
【００５３】
次に、バッファ読出し処理部１６０２が実行するバッファ読出し処理（Ｓ１８５０）について説明する。
【００５４】
図９は、本発明の第１の実施形態のバッファ読出し処理部が実行するバッファ読出し処理を示すフローチャートである。
【００５５】
バッファ読出し処理部１６０２は、出力スケジューラ６０５からフレーム送信要求を受信する（Ｓ１８００）と、バッファ管理レジスタ１３０９から、リードポインタ３００５、格納フレーム数３００２、及び、格納バイト数３００３を取得する（Ｓ１８０１）。
【００５６】
次に、リードポインタ３００５、格納フレーム数３００２、及び、格納バイト数３００３を更新し、出力フレームバッファ３１０から出力スケジューラ６０５へフレームを送信し、前記各更新値をバッファ管理レジスタ１３０９に設定し（Ｓ１８０２）、処理を終了する（Ｓ１８０４）。
【００５７】
一方、バッファ読出し処理部１６０２は、Ｓ１８０２と同時に、帯域制御部１６０３に読出通知、及び、読出フレーム長通知を送信し（Ｓ１８０３）、処理を終了する（Ｓ１８０４）。
【００５８】
図１０は、本発明の第１の実施形態の帯域制御部の構成を示すブロック図である。
【００５９】
帯域制御部１６０３は、トークン量保持部７０１、トークン減算部７０２、トークン加算部７０３、トークン加算量保持部７０４、蓄積トークン量制御部７０５、最大蓄積トークン量制御部７０６、フレーム有無判定部７０７、トークン量判定部７０８、及びトークン判定量保持部７０９を備える。
【００６０】
トークン量保持部７０１は、トークンバケツアルゴリズムに用いられるパラメータ（トークンバケツに蓄積されるトークン量）を保持する。トークン量保持部７０１に蓄積されるトークン量は、送信フレーム長（読出フレーム長）に基づいて減算され、一定時間に一定量が加算される。トークン量保持部７０１が加算（蓄積）可能なトークン量は、蓄積トークン量制御部７０５により制御される。
【００６１】
トークン減算部７０２は、出力フレームバッファ３１０から読み出されたフレーム長に基づいて、トークン量保持部７０１から、読出フレーム長に対応する量のトークンを減算する。
【００６２】
トークン加算部７０３は、一定タイミングで一定量のトークンを加算する。具体的には、トークン加算部７０３は、トークン加算信号（例えば、クロック信号）が入力されると、トークン加算量保持部７０４に保持された量のトークンを加算する。
【００６３】
トークン加算量保持部７０４は、定期的に加算されるトークン量を保持しており、この定期的に加算されるトークン量は、設定レジスタ３１２により設定される。
【００６４】
蓄積トークン量制御部７０５は、バッファ管理レジスタ１３０９の格納フレーム数３００２に基づいて、トークン量保持部７０１が加算するトークン量を制御する。本発明の第１の実施形態では、格納フレーム数が１以上の場合は最大蓄積トークン量保持部７０６に設定された値、格納フレーム数が０の場合はトークン判定量保持部７０９に設定された値を、蓄積トークン量制御部７０５がトークン量保持部７０１を制御する値とする。
【００６５】
最大蓄積トークン量保持部７０６は、トークン量保持部７０１で加算できる最大のトークン量（バケツの深さ）を保持しており、バケツの深さは、設定レジスタ３１２により設定される。
【００６６】
フレーム有無判定部７０７は、格納フレーム数３００２が０より大きいか否かを判定し、トークン量判定部７０８に通知する。
【００６７】
トークン量判定部７０８は、フレーム有無判定部７０７より格納フレーム数３００２が０より大きいことを通知された場合、トークン量保持部７０１に蓄積されるトークン量（トークン量）とトークン判定量保持部７０９が保持するトークン量（一定量）の大小を判定し、（トークン量）≧（一定量）であれば出力スケジューラ６０５にフレームの送信要求を出す。
【００６８】
トークン判定量保持部７０９は、トークン量判定部７０８が出力スケジューラ６０５へ送信要求を行うか否かの基準となるトークン量（一定量）を保持しており、この一定量は、設定レジスタ３１２により設定される。
【００６９】
以下に、帯域制御部１６０３が実行する帯域制御処理（Ｓ１９５０）について説明する。
【００７０】
図１１は、本発明の第１の実施形態の帯域制御部１６０３が実行する帯域制御処理を示すフローチャートである。
【００７１】
トークン加算部７０３は、一定タイミングでトークン加算信号が入力されると処理を開始する。（Ｓ１９００）、トークン加算部７０３は、トークン加算量保持部７０４が保持する一定トークン量を、トークン量保持部７０１に加算する（Ｓ１９０１）。この一定タイミングで一定量加算するトークンが各フローの契約帯域に相当する。一定量は、ＮＩＦ管理部１３１１が制御する設定レジスタ３１２から設定される。
【００７２】
次に、蓄積トークン量制御部７０５は、バッファ管理レジスタ１３０９から格納フレーム数３００２を取得し、取得した格納フレーム数３００２が０より大きいか否かを判定する（Ｓ１９０２）。
【００７３】
Ｓ１９０２において、格納フレーム数３００２が０より大きい場合、蓄積トークン量制御部７０５は、トークン量保持部７０１が保持するトークン量が、最大蓄積トークン量保持部７０６が保持するバケツの深さより大きいか否かを判定する（Ｓ１９０３）。
Ｓ１９０３において、トークン量保持部７０１が保持するトークン量がバケツの深さより大きくない場合、Ｓ１９０７の処理に進む。一方、トークン量がバケツの深さより大きい場合は、蓄積トークン量制御部７０５は、トークン量保持部７０１が保持するトークン量をバケツの深さの値に設定し（Ｓ１９０４）、Ｓ１９０７の処理に進む。バケツの深さは、ＮＩＦ管理部１３１１から設定されるものである。ここで、Ｓ１９０４において、トークン量をバケツの深さの値に設定することにより、バケツの深さに相当する蓄積フレーム数以上のバースト送信を発生させない。
【００７４】
次に、トークン量判定部７０８は、トークン量保持部７０１が保持するトークン量が、トークン判定量保持部７０９が保持する一定量以上であるか否かを判定する（Ｓ１９０７）。
【００７５】
Ｓ１９０７において、トークン量保持部７０１が保持するトークン量が一定量以上である場合、トークン量判定部７０８は出力スケジューラ６０５に送信要求を送信し（Ｓ１９０８）、Ｓ１９１０の処理に進む。ここで、一定量以上である場合は、フレームを送信するトークン量（送信権）を保持しているため、トークン量判定部７０８は、トークン量を監視しているフローのフレーム読み出しが可能であると判断し、出力スケジューラ６０５に送信要求を送信する。
【００７６】
一方、Ｓ１９０２において、格納フレーム数３００２が０である場合、蓄積トークン量制御部７０５は、トークン量保持部７０１が保持するトークン量が、トークン判定量保持部７０９が保持する一定量より大きいか否かを判定する（Ｓ１９０５）。
Ｓ１９０５において、トークン量が一定量より大きい場合、蓄積トークン量制御部７０５は、トークン量保持部７０１が保持するトークン量を一定量に設定し（Ｓ１９０６）、Ｓ１９１０の処理に進む。第１の実施形態においては、この格納フレーム数３００２が０である場合にトークン量を一定量に設定することによって、送信するフレームが無い場合にトークン加算は一定量までとなり、フレームが断続的に到着した場合でも、フレームの送信間隔を平滑化し、契約帯域を超過したフレームの送信を抑制する。
【００７７】
また、Ｓ１９０５において、トークン量が一定量以下の場合、Ｓ１９１０の処理に進む。
【００７８】
また、Ｓ１９０７において、トークン量が一定量以上でない場合は、Ｓ１９１０の処理に進む。
【００７９】
トークン減算部７０２は、バッファ読出し処理部１６０２からの読出通知があるか否かを判定する（Ｓ１９１０）。
【００８０】
Ｓ１９１０において、読出通知がない場合、処理を終了する（Ｓ１９１２）。一方、読出通知がある場合、トークン減算部７０２は、バッファ読出し処理部１６０２からの読出フレーム長分のトークン量を、トークン量保持部７０１から減算し（Ｓ１９１１）、処理を終了する（Ｓ１９１２）。
【００８１】
尚、図１０及び図１１では、格納フレーム数３００２が０であるか否かによって、トークンの加算上限値を変更するとしたが、格納フレーム数がある一定数を超えた場合にトークンの加算上限値を変更することとしてもよい。
【００８２】
図１２は、図１１で説明した本発明の第１の実施形態の帯域制御部１６０３が実行する帯域制御処理による、トークンバケツのトークン量の変化及びフレームの制御状態を示す説明図である。
【００８３】
本発明の帯域制御部では、フロー毎に設定された契約帯域に対応する速度でトークンを加算する。トークンが一定量になるとフレーム送信が可能であり、フレームを送信するとフレーム長分のトークンを減算する（Ｔ２１１）。これにより、フレーム到着タイミングに対して、理想送信タイミングを決定する。図２では、簡単化のため、フレームが固定長である場合を示しており、このため理想送信タイミングは一定となる。理想タイミングとは、他フローの影響を受けずに契約帯域で送信する場合のタイミングである。
【００８４】
フレームがフロー制御部に到着すると、バッファ書き込み処理Ｓ１７５０を実行し、バッファ管理レジスタ１３０９の格納フレーム数を１加算して、フレームを出力フレームバッファ３１０に格納する。フレームを送信する際（実送信）、バッファ読み出し処理Ｓ１８５０を実行し、バッファ管理レジスタ１３０９の格納フレーム数を１減算して、フレームを出力フレームバッファ３１０から読出す。
【００８５】
他フローと出力競合が発生した場合、すなわち、図１１のＳ１９１０で読み出し通知がない場合、該フローのフレーム送信を理想タイミングで実現できず、出力スケジューラからの読出通知を受信するまで該フローのフレームの送信を待合わせる必要がある。そのため、本発明の帯域制御部は、バッファ管理レジスタ１３０９から取得する格納フレーム数が１以上の場合はバケツの深さまでトークンを加算可能とする。これにより、他ユーザフローのフレーム送信後、他フローのフレーム送信の間に蓄積したトークンに応じて待合わせたフレームを連続送信することができ、契約帯域分のフレームを送信可能とする。
【００８６】
この様子を図１２を用いて説明する。Ｔ２１２では、トークンは一定量に達しているが出力スケジューラからの読出通知を受領していないため、フレームを読み出すことが出来ない状態である。図１１のＳ１９０２、１９０３、１９０７、Ｓ１９０８、Ｓ１９０８、Ｓ１９１０、Ｓ１９１２の判断となる場合である。Ｓ１９０３において、トークン量よりもバケツの深さが大きいためトークン量をバケツの深さに設定するなどのトークン量の制限は行わない。この場合、Ｔ２１２のタイミングで実送信２０６は実行されていない。これは、他ユーザフロー送信２０７で示す通り、他ユーザフローのフレームを読み出しているためである。Ｔ２１２の後、出力スケジューラから読出通知を受領するＴ２１３までトークン量がバケツの深さより大きくならない限りトークンを蓄積する（Ｓ１９０３）。Ｔ２１３で出力スケジューラから読出通知を受領すると、一定量のトークンがバケツに保持されているためフレームを読み出す。さらにＴ２１４で出力スケジューラから読出通知を受領すると、このタイミングでも一定量のトークンが蓄積されているためフレームを読み出す。これはＴ２１２からＴ２１３の間もトークンを蓄積していたためである。これにより、Ｔ２１４の実送信２０６に示すように、Ｔ２１２で待ち合わせた帯域分をＴ２１４で読み出すことができる。
【００８７】
一方、格納フレーム数が０である場合は、トークン加算は一定量までとする。フレームが断続的に到着した場合、瞬間的に契約帯域を超過したフレームが到着するため、トークン加算を一定量までとすることにより、フレームが断続的に到着した場合でも、フレームの送信間隔を平滑化し、契約帯域を超過したフレームの送信を抑制する。この様子を図１２を用いて説明する。Ｔ２１５から、トークンが一定値に達するＴ２１６に至るまでは一定量のトークンが加算される。しかしながら、Ｔ２１６においては、格納フレーム数は０であり（Ｓ１９０２からＳ１９０５）、Ｔ２１７でフレームを受信し格納フレーム数が１となるまでは、Ｓ１９０５の判定においてトークンが一定量より大きくなるため、Ｓ１９０６にて、トークンが一定値に設定される。従って、Ｔ２１８のタイミングでフレームを受信しても、畜積されたトークン量は一定量より少ないためＴ２１９のタイミングまでフレームは送信されず、契約帯域を超過したフレームの送信を抑制することができる。
【００８８】
以上により、図１のユーザ装置103-1から送信された図２Ａに示すフローは、帯域制御装置による制御によって、図２Ｂに示す通り、フレームの送信間隔を平滑化され、契約帯域を超過したフレームの送信は抑制される。
従って、第１の実施形態によれば、帯域制御装置は、収容する複数ユーザフローに対して契約帯域を超過したフレームを通信キャリア網へ送信することを抑制し、出力競合が発生する場合でも各ユーザフローの契約帯域分のフレームを送信することができる。
【００８９】
＜実施形態２＞
以下、本発明の第２の実施形態について図１３から図１９を用いて説明する。
【００９０】
第１の実施形態では、帯域制御部１６０３は、バッファ管理レジスタ１３０９の格納フレーム数３００２が０である場合に、トークンが一定量より大きければトークンを一定量に設定した。第２の実施形態では、帯域制御部６０３は、フレーム有フラグが１であり、かつ、トークンが一定量以上である場合に、バッファ書込み処理部６０１からのフレーム初到着通知があればトークンを一定量に設定する。
【００９１】
図１３は、本発明の第２の実施形態の帯域制御装置の構成を示すブロック図である。
【００９２】
第２の実施形態の帯域制御装置３は、図３に示す第１の実施形態の帯域制御装置１０１と、バッファ管理レジスタ１３０９を含まず、バッファ管理テーブル３０９を含む点で、出力フレームバッファ制御部３０８、及び、ＮＩＦ管理部３１１の処理が異なる。
【００９３】
出力フレームバッファ制御部３０８は、出力フレームをフロー毎の出力フレームバッァ３１０に蓄積する。出力フレームバッファ制御部３０８は、格納された出力フレームをバッファ管理テーブル３０９に設定されたフロー毎の情報を用いてシェーピングしながら出力フレームバッファ３１０から読出し、入出力回線インタフェース３０１に送出する。
ＮＩＦ管理部３１１は、バッファ管理テーブル３０９及び設定レジスタ３１２を制御する。
【００９４】
図１４は、本発明の第２の実施形態のバッファ管理テーブルを示す説明図である。
【００９５】
バッファ管理テーブル３０９は、フローＩＤ：１００１を検索キーとして、バッファサイズ：１００２、格納フレーム数：１００３、格納バイト数：１００４、ライトポインタ１００５、及び、リードポインタ１００６を検索する。ここで、バッファサイズ１００２は、当該フローの運用するバッファサイズを示し、格納フレーム数１００３は、当該フローのバッファに格納されているフレーム数を示し、格納バイト数１００４は、当該フローのバッファに格納されているバイト数を示し、ライトポインタ１００５は、当該フローのバッファのライト開始アドレスを示し、リードポインタ１００６は、当該フローのバッファのリード開始アドレスを示す。
【００９６】
図１５は、本発明の第２の実施形態の出力フレームバッファ制御部の構成を示すブロック図である。
【００９７】
出力フレームバッファ制御部３０８は、フロー制御部６０４、及び、出力スケジューラ６０５を備える。
【００９８】
また、フロー制御部６０４は、バッファ書込み処理部６０１、バッファ読出し処理部６０２、帯域制御部６０３、及び、出力フレームバッファ３１０から構成される。
【００９９】
バッファ書込み処理部６０１は、出力ヘッダ処理部３０７からのフレームを受信すると、後述するバッファ書込み処理Ｓ７５０を実施する。バッファ書込み処理部６０１は、フレームを受信すると、フローを識別し、該当するフレームであった場合、フレームを出力フレームバッファ３１０に格納し、バッファ管理テーブル３０９を更新し、フレーム有フラグ、フレーム初到着を帯域制御部６０３に通知する。
【０１００】
帯域制御部６０３は、後述する帯域制御処理Ｓ９５０を実施し、送信要求を出力スケジューラ６０５に送信する。
【０１０１】
出力スケジューラ６０５は、各フロー制御部（６０４−１〜Ｎ）の帯域制御部６０３から送信要求を受信すると、読出すフレームをスケジューリングする。出力スケジューラ６０５は、送信要求を各フロー制御部（６０４−１〜Ｎ）のバッファ読出し処理部６０２に送信し、バッファ読出し処理部６０２から受信したフレームを入出力回線インタフェース３０１に送出する。
【０１０２】
バッファ読出し処理部６０２は、出力スケジューラ６０５からフレーム送信要求を受信すると、後述するバッファ読出し処理Ｓ８５０を実施する。バッファ読出し処理部６０２は、出力フレームバッファ３１０から読出したフレームを出力スケジューラ６０５に送信し、バッファ管理テーブル３０９を更新し、読出通知、及び、読出フレーム長通知を帯域制御部６０３に送信し、フレーム有フラグを帯域制御部６０３に通知する。
【０１０３】
以下に、バッファ書込み処理部６０１が実行するバッファ書込み処理（Ｓ７５０）について説明する。
【０１０４】
図１６は、本発明の第２の実施形態のバッファ書込み処理部が実行するバッファ書込み処理を示すフローチャートである。
【０１０５】
バッファ書込み処理部６０１は、出力ヘッダ処理部３０７からフレームを受信する（Ｓ７００）と、装置内ヘッダ４からフローＩＤ４０２、及び、フレーム長４０３を取得する（Ｓ７０１）。
【０１０６】
次に、バッファ書込み処理部６０１は、取得したフローＩＤ４０２が設定レジスタ３１２から設定されたフローＩＤと同一であるか否かを判定する（Ｓ７０２）。
【０１０７】
Ｓ７０２において、取得したフローＩＤ４０２が設定されたフローＩＤと同一である場合、取得したフローＩＤ４０２を用いてバッファ管理テーブル３０９を検索し、バッファサイズ１００２、ライトポインタ１００５、格納フレーム数１００３、及び、格納バイト数１００４を取得する（Ｓ７０３）。
【０１０８】
次に、バッファ書込み処理部６０１は、取得した格納バイト数１００４とフレーム長４０３を足し合わせた値と、バッファサイズ１００２を比較する（Ｓ７０４）。
【０１０９】
Ｓ７０４において、取得した格納バイト数１００４とフレーム長４０３を足し合わせた値がバッファサイズ１００２以下である場合、ライトポインタ１００５、格納フレーム数１００３、及び、格納バイト数１００４を更新し、出力フレームバッファ３１０にフレームを送出し、前記各更新値をバッファ管理テーブル３０９に格納し（Ｓ７０５）、処理を終了する（Ｓ７１０）。
【０１１０】
一方、バッファ書込み処理部６０１は、Ｓ７０５と同時に、帯域制御部６０３にフレーム有フラグを１として通知する（Ｓ７０６）。
バッファ書込み処理部６０１は、バッファ管理テーブル３０９から取得した格納フレーム数１００３が０であるか否かを判定する（Ｓ７０７）。
【０１１１】
Ｓ７０７において、格納フレーム数１００３が０である場合、帯域制御部６０３にフレーム初到着を通知し（Ｓ７０８）、処理を終了する（Ｓ７１０）。
【０１１２】
一方、格納フレーム数１００３が０でない場合、処理を終了する（Ｓ７１０）。
【０１１３】
また、Ｓ７０４において、取得した格納バイト数１００４とフレーム長４０３を足し合わせた値がバッファサイズ１００２より大きい場合、バッファがオーバーフローすることを示しており、フレームを廃棄し（Ｓ７０９）、処理を終了する（Ｓ７１０）。
【０１１４】
また、Ｓ７０２において、取得したフローＩＤ４０２が設定されたフローＩＤと同一でない場合、処理対象外フローのフレームを示しており、フレームを廃棄し（Ｓ７０９）、処理を終了する（Ｓ７１０）。
【０１１５】
次に、バッファ読出し処理部６０２が実行するバッファ読出し処理（Ｓ８５０）について説明する。
【０１１６】
図１７は、本発明の第２の実施形態のバッファ読出し処理部が実行するバッファ読出し処理を示すフローチャートである。
【０１１７】
バッファ読出し処理部６０２は、出力スケジューラ６０５からフレーム送信要求を受信する（Ｓ８００）と、設定レジスタ３１２から設定されたフローＩＤを用いてバッファ管理テーブル３０９を検索し、リードポインタ１００６、格納フレーム数１００３、及び、格納バイト数１００４を取得する（Ｓ８０１）。
【０１１８】
次に、リードポインタ１００６、格納フレーム数１００３、及び、格納バイト数１００４を更新し、出力フレームバッファ３１０から出力スケジューラ６０５へフレームを送信し、前記各更新値をバッファ管理テーブル３０９に格納し（Ｓ８０２）、処理を終了する（Ｓ８０６）。
【０１１９】
一方、バッファ読出し処理部６０２は、Ｓ８０２と同時に、帯域制御部６０３に読出通知を送信し、読出フレーム長を通知する（Ｓ８０３）。
【０１２０】
バッファ読出し処理部６０２は、バッファ管理テーブル３０９から取得した格納フレーム数１００３が１より大きいか否かを判定する（Ｓ８０４）。
【０１２１】
Ｓ８０４において、格納フレーム数１００３が１より大きい場合、処理を終了する（Ｓ８０６）。
【０１２２】
一方、Ｓ８０４において、格納フレーム数１００３が１より大きくない場合、帯域制御部６０３にフレーム有フラグを０として通知し（Ｓ８０５）、処理を終了する（Ｓ８０６）。
【０１２３】
図１８は、本発明の第２の実施形態の帯域制御部の構成を示すブロック図である。
【０１２４】
第２の実施形態の帯域制御部６０３は、図１０に示す第１の実施形態の帯域制御部１６０３と比較し、トークン量保持部１７０１、蓄積トークン量制御部１７０５、及び、トークン量判定部１７０８の処理が異なる。
【０１２５】
トークン量保持部１７０１は、トークンバケツアルゴリズムに用いられるパラメータ（トークンバケツに蓄積されるトークン量）を保持する。トークン量保持部１７０１に蓄積されるトークン量は、送信フレーム長（読出フレーム長）に基づいて減算され、一定時間に一定量が加算される。トークン量保持部１７０１が加算（蓄積）可能なトークン量は、蓄積トークン量制御部１７０５により制御される。
【０１２６】
蓄積トークン量制御部１７０５は、最大蓄積トークン量保持部７０６に設定された値を、トークン量保持部１７０１を制御する値とする。ただし、フレーム有フラグ＝‘１’かつフレーム初到着通知がある場合は、トークン判定量保持部７０９に設定された値を、蓄積トークン量制御部１７０５がトークン量保持部１７０１を制御する値に設定する。
トークン量判定部１７０８は、バッファ書込み処理部６０１からのフレーム有フラグ＝‘１’の場合、トークン量保持部１７０１に蓄積されるトークン量（トークン量）とトークン判定量保持部７０９が保持するトークン量（一定量）の大小を判定し、（トークン量）≧（一定量）であれば出力スケジューラ６０５にフレームの送信要求を出す。 以下に、帯域制御部６０３が実行する帯域制御処理（Ｓ９５０）について説明する。
【０１２７】
図１９は、本発明の第２の実施形態の帯域制御部が実行する帯域制御処理を示すフローチャートである。
【０１２８】
トークン加算部７０３は、一定タイミングでトークン加算信号が入力されると処理を開始し（Ｓ９００）、トークン加算量保持部７０４が保持する一定トークン量を、トークン量保持部１７０１に加算する（Ｓ９０１）。
【０１２９】
次に、トークン量保持部１７０１が保持するトークン量が、最大蓄積トークン量保持部７０６が保持するバケツの深さより大きいか否かを判定する（Ｓ９０２）。Ｓ９０２において、トークン量保持部１７０１が保持するトークン量がバケツの深さより大きくない場合、Ｓ９０４の処理に進む。一方、トークン量がバケツの深さより大きい場合は、蓄積トークン量制御部１７０５は、トークン量保持部１７０１が保持するトークンをバケツの深さの値に設定し（Ｓ９０３）、Ｓ９０４の処理に進む。
【０１３０】
トークン量判定部１７０８は、バッファ書込み処理部６０１からのフレーム有フラグが‘１’であり、かつ、トークン量保持部１７０１が保持するトークン量が、トークン判定量保持部７０９が保持する一定量以上であるか否かを判定する（Ｓ９０４）。
【０１３１】
Ｓ９０４において、フレーム有フラグが‘１’であり、かつ、トークン量保持部１７０１が保持するトークンが一定量以上である場合、トークン量判定部１７０８は出力スケジューラ６０５に送信要求を送信する（Ｓ９０５）。
【０１３２】
次に、蓄積トークン量制御部１７０５は、バッファ書込み処理部６０１からのフレーム初到着通知があるか否かを判定する（Ｓ９０６）。
【０１３３】
Ｓ９０６において、フレーム初到着通知がない場合、Ｓ９０９の処理に進む。また、フレーム初到着通知がある場合は、蓄積トークン量制御部１７０５は、トークン量保持部１７０１が保持するトークン量を一定量に設定し（Ｓ９０７）、Ｓ９０９の処理に進む。第２の実施形態においては、このフレーム初到着通知がある場合にトークンを一定量に設定することによって、送信するフレームが無い場合にトークン加算は一定量までとすることと同じになり、フレームが断続的に到着した場合でも、フレームの送信間隔を平滑化し、契約帯域を超過したフレームの送信を抑制する。
【０１３４】
一方、Ｓ９０４において、フレーム有フラグが１であり、かつ、トークン量保持部１７０１が保持するトークンが一定量以上でない場合は、Ｓ９０９の処理に進む。
【０１３５】
次に、トークン減算部７０２は、バッファ読出し処理部６０２からの読出通知があるか否かを判定する（Ｓ９０９）。
【０１３６】
Ｓ９０９において、読出通知がない場合、処理を終了する（Ｓ９１１）。一方、読出通知がある場合、トークン減算部７０２は、バッファ読出し処理部６０２からの読出フレーム長分のトークン量を、トークン量保持部１７０１から減算し（Ｓ９１０）、処理を終了する（Ｓ９１１）。
【０１３７】
尚、第２の実施形態の帯域制御処理による、トークンバケツのトークン量の変化及びフレームの制御状態は実施形態１で説明した図１２と同様であるが、Ｔ２１６からＴ２１７に至るまでのトークン量の変化が異なる。
【０１３８】
第２の実施形態の帯域制御部６０３は、バケツの深さまでトークンを加算可能とする。これにより、Ｔ２１０からＴ２１５に至るまでのトークン量の変化は実施形態１と同じであり、他ユーザフローのフレーム送信後、他フローのフレーム送信の間に蓄積したトークンに応じて待合わせたフレームを連続送信することができ、契約帯域分のフレームを送信可能とする。
【０１３９】
ただし、フレーム有フラグ＝‘１’であり、かつフレーム初到着通知がある場合は、トークン加算を一定量までとする。トークン加算を一定量までとすることにより、実施形態１と同様に、フレームが断続的に到着した場合でも、フレームの送信間隔を平滑化し、契約帯域を超過したフレームの送信を抑制する。この様子を図１２を用いて説明する。
【０１４０】
Ｔ２１５から、トークンが一定値に達するＴ２１６に至るまでは一定トークンが加算される。また、Ｔ２１６からＴ２１７に至るまでも、バケツの深さを越えない範囲で、一定トークンが加算される。Ｔ２１７においては、トークン量が一定量以上かつフレーム有フラグ＝‘１’であり、かつフレーム初到着通知があるため（Ｓ９０４からＳ９０６）、Ｓ９０７にて、トークンが一定値に設定される。従って、実施形態１と同様に、Ｔ２１８のタイミングでフレームを受信しても、畜積されたトークン量は一定量より少ないためＴ２１９のタイミングまでフレームは送信されず、契約帯域を超過したフレームの送信を抑制することができる。
【０１４１】
以上説明したように、第２の実施形態によれば、第１の実施形態の効果と同様に、帯域制御装置は、収容する複数ユーザフローに対して契約帯域を超過したフレームを通信キャリア網へ送信することを抑制し、出力競合が発生する場合でも各ユーザフローの契約帯域分のフレームを送信することができる。
【０１４２】
＜実施形態３＞
以下、本発明の第３の実施形態について図２０から図２５を用いて説明する。
【０１４３】
第１及び第２の実施形態では、トークンの加算値が一定量になるとフレーム送信が可能であるとした。第３の実施形態では、送信するフレーム長分のトークンが加算されるとフレーム送信が可能であるとする。
【０１４４】
図２０は、本発明の第３の実施形態の帯域制御装置の構成を示すブロック図である。
【０１４５】
第３の実施形態の帯域制御装置２３は、図３に示す第１の実施形態の帯域制御装置１０１と、出力フレームバッファ制御部２３０８の処理が異なる。
【０１４６】
図２１は、本発明の第３の実施形態の出力フレームバッファ制御部の構成を示すブロック図である。
【０１４７】
出力フレームバッファ制御部２３０８は、フロー制御部２６０４、及び、出力スケジューラ６０５を備える。
【０１４８】
また、フロー制御部２６０４は、バッファ書込み処理部２６０１、バッファ読出し処理部２６０２、帯域制御部２６０３、バッファ管理レジスタ１３０９、及び、出力フレームバッファ３１０から構成される。
【０１４９】
バッファ書込み処理部２６０１は、出力ヘッダ処理部３０７からのフレームを受信すると、後述するバッファ書込み処理Ｓ２７５０を実施する。バッファ書込み処理部２６０１は、フレームを受信すると、フローを識別し、該当するフレームであった場合、フレームを出力フレームバッファ３１０に格納し、バッファ管理レジスタ１３０９を更新する。
【０１５０】
帯域制御部２６０３は、後述する帯域制御処理Ｓ２９５０を実施し、送信要求を出力スケジューラ６０５に送信する。
【０１５１】
書込フレーム長格納キュー２６０９は、後述するバッファ書込み処理Ｓ２７５０において、バッファ書込み処理部２６０１から通知される書込フレーム長の情報を格納する。
【０１５２】
出力スケジューラ６０５は、各フロー制御部（２６０４−１〜Ｎ）の帯域制御部２６０３から送信要求を受信すると、読出すフレームをスケジューリングする。出力スケジューラ６０５は、送信要求を各フロー制御部（２６０４−１〜Ｎ）のバッファ読出し処理部２６０２に送信し、バッファ読出し処理部２６０２から受信したフレームを入出力回線インタフェース３０１に送出する。
【０１５３】
バッファ読出し処理部２６０２は、第１の実施形態のバッファ読出し処理部１６０２と同様であり、出力スケジューラ６０５からフレーム送信要求を受信すると、前述のバッファ読出し処理Ｓ１８５０を実施する。バッファ読出し処理部２６０２は、出力フレームバッファ３１０から読出したフレームを出力スケジューラ６０５に送信し、バッファ管理レジスタ１３０９を更新し、読出通知、及び、読出フレーム長通知を帯域制御部２６０３に送信する。
【０１５４】
以下に、バッファ書込み処理部２６０１が実行するバッファ書込み処理（Ｓ２７５０）について説明する。
【０１５５】
図２２は、本発明の第３の実施形態のバッファ書込み処理部が実行するバッファ書込み処理を示すフローチャートである。
【０１５６】
バッファ書込み処理部２６０１は、出力ヘッダ処理部３０７からフレームを受信する（Ｓ２７００）と、装置内ヘッダ４からフローＩＤ４０２、及び、フレーム長４０３を取得する（Ｓ２７０１）。
【０１５７】
次に、バッファ書込み処理部２６０１は、取得したフローＩＤ４０２が設定レジスタ３１２から設定されたフローＩＤと同一であるか否かを判定する（Ｓ２７０２）。
【０１５８】
Ｓ２７０２において、取得したフローＩＤ４０２が設定されたフローＩＤと同一である場合、バッファ管理レジスタ１３０９から、バッファサイズ３００１、ライトポインタ３００４、格納フレーム数３００２、及び、格納バイト数３００３を取得する（Ｓ２７０３）。
【０１５９】
次に、バッファ書込み処理部２６０１は、取得した格納バイト数３００３とフレーム長４０３を足し合わせた値と、バッファサイズ３００１を比較する（Ｓ２７０４）。
【０１６０】
Ｓ２７０４において、取得した格納バイト数３００３とフレーム長４０３を足し合わせた値がバッファサイズ３００３以下である場合、ライトポインタ３００４、格納フレーム数３００２、及び、格納バイト数３００３を更新し、出力フレームバッファ３１０にフレームを送出し、前記各更新値をバッファ管理レジスタ１３０９に設定し（Ｓ２７０５）、処理を終了する（Ｓ２７１０）。
【０１６１】
一方、バッファ書込み処理部２６０１は、Ｓ２７０５と同時に、帯域制御部２６０３に書込フレーム長を通知する（Ｓ２７０６）。
【０１６２】
バッファ書込み処理部２６０１は、バッファ管理レジスタ１３０９から取得した格納フレーム数３００２が０であるか否かを判定する（Ｓ２７０７）。
【０１６３】
Ｓ２７０７において、格納フレーム数３００２が０である場合、帯域制御部２６０３にフレーム初到着を通知し（Ｓ２７０８）、処理を終了する（Ｓ２７１０）。
【０１６４】
一方、格納フレーム数３００２が０でない場合、処理を終了する（Ｓ２７１０）。
【０１６５】
また、Ｓ２７０２において、取得したフローＩＤ４０２が設定されたフローＩＤと同一でない場合、処理対象外フローのフレームを示しており、フレームを廃棄し（Ｓ２７０９）、処理を終了する（Ｓ２７１０）。
【０１６６】
また、Ｓ２７０４において、取得した格納バイト数３００３とフレーム長４０３を足し合わせた値がバッファサイズ３００３より大きい場合、バッファがオーバーフローすることを示しており、フレームを廃棄し（Ｓ２７０９）、処理を終了する（Ｓ２７１０）。
【０１６７】
バッファ読出し処理部２６０２が実行するバッファ読出し処理は、第１の実施形態のバッファ読出し処理部が実行するバッファ読出し処理（Ｓ１８５０）と同じである。
【０１６８】
図２３は、本発明の第３の実施形態の帯域制御部の構成を示すブロック図である。
【０１６９】
第３の実施形態の帯域制御部２６０３は、図１０に示す第１の実施形態の帯域制御部１６０３と比較し、トークン量保持部２７０１、蓄積トークン量制御部２７０５、及び、トークン量判定部２７０８の処理が異なる。また、トークン判定量保持部７０９を含まず、書込フレーム長格納キュー２６０９を所持する。
【０１７０】
トークン量保持部２７０１は、トークンバケツアルゴリズムに用いられるパラメータ（トークンバケツに蓄積されるトークン量）を保持する。トークン量保持部２７０１に蓄積されるトークン量は、送信フレーム長（読出フレーム長）に基づいて減算され、一定時間に一定量が加算される。トークン量保持部２７０１が加算（蓄積）可能なトークン量は、蓄積トークン量制御部２７０５により制御される。
【０１７１】
蓄積トークン量制御部２７０５は、最大蓄積トークン量保持部７０６に設定された値を、トークン量保持部２７０１を制御する値とする。ただし、フレーム初到着通知がある場合は、書込フレーム長格納キュー２６０９から取得したフレーム長の値を、蓄積トークン量制御部２７０５がトークン量保持部２７０１を制御する値に設定する。
【０１７２】
トークン量判定部２７０８は、フレーム有無判定部７０７より格納フレーム数３００２が０より大きいことを通知された場合、トークン量保持部２７０１に蓄積されるトークン量（トークン量）と蓄積トークン量制御部２７０５から通知されるフレーム長の大小を判定し、（トークン量）≧（フレーム長）であれば出力スケジューラ６０５にフレームの送信要求を出す。
【０１７３】
書込フレーム長格納キュー２６０９は、バッファ書込み処理部２６０１から通知される書込フレーム長の情報を格納する。また、蓄積トークン量制御部２７０５へ格納したフレーム長の情報を通知する。
【０１７４】
図２４は、本発明の第３の実施形態の帯域制御部が実行する帯域制御処理を示すフローチャートである。
【０１７５】
トークン加算部７０３は、一定タイミングでトークン加算信号が入力されると処理を開始し（Ｓ２９００）、トークン加算量保持部７０４が保持する一定トークン量を、トークン量保持部２７０１に加算する（Ｓ２９０１）。
【０１７６】
次に、トークン量保持部２７０１が保持するトークン量が、最大蓄積トークン量保持部７０６が保持するバケツの深さより大きいか否かを判定する（Ｓ２９０２）。
【０１７７】
Ｓ２９０２において、トークン量保持部２７０１が保持するトークンがバケツの深さより大きくない場合、Ｓ２９０４の処理に進む。一方、トークンがバケツの深さより大きい場合は、蓄積トークン量制御部２７０５は、トークン量保持部２７０１が保持するトークンをバケツの深さの値に設定し（Ｓ２９０３）、Ｓ２９０４の処理に進む。
【０１７８】
次に、書込フレーム長格納キュー２６０９は、バッファ書込み処理部２６０１から書込フレーム長の通知があるか否かを判定する（Ｓ２９０４）。
【０１７９】
Ｓ２９０４において、書込フレーム長の通知がない場合、Ｓ２９０６の処理に進む。一方、書込フレーム長の通知がある場合、書込フレーム長格納キュー２６０９は、通知された書込フレーム長を書込フレーム長格納キューへ格納し（Ｓ２９０５）、Ｓ２９０６の処理に進む。
【０１８０】
次に、蓄積トークン量制御部２７０５は、バッファ書込み処理部２６０１からのフレーム初到着通知があるか否か、あるいは、バッファ管理レジスタの格納フレーム数３００２が０であり、かつバッファ読出し処理部２６０２からの読出通知があるか否かを判定する（Ｓ２９０６）。
【０１８１】
Ｓ２９０６において、バッファ書込み処理部２６０１からのフレーム初到着通知がない場合、かつ、バッファ管理レジスタの格納フレーム数３００２が０であり、かつバッファ読出し処理部２６０２からの読出通知がない場合、Ｓ２９１１の処理に進む。
【０１８２】
一方、Ｓ２９０６において、バッファ書込み処理部２６０１からのフレーム初到着通知がある場合、あるいは、バッファ管理レジスタの格納フレーム数３００２が０であり、かつバッファ読出し処理部２６０２からの読出通知がある場合、蓄積トークン量制御部２７０５は、書込フレーム長格納キュー２６０９からフレーム長を取得し、トークン量保持部２７０１を制御する値（フレーム長）として設定する（Ｓ２９０７）。
【０１８３】
次に、蓄積トークン量制御部２７０５は、バッファ書込み処理部２６０１からのフレーム初到着通知であったか否かを判定する（Ｓ２９０８）。
【０１８４】
Ｓ２９０８において、フレーム初到着通知ではない場合、Ｓ２９１１の処理に進む。一方、フレーム初到着通知である場合、蓄積トークン量制御部２７０５は、トークン量保持部２７０１が保持するトークン量がフレーム長以上であるか否かを判定する（Ｓ２９０９）。
【０１８５】
Ｓ２９０９において、トークンがフレーム長以上でない場合、Ｓ２９１１の処理に進む。一方、トークンがフレーム長以上である場合、蓄積トークン量制御部２７０５は、トークン量保持部２７０１が保持するトークンをフレーム長分に設定し（Ｓ２９１０）、Ｓ２９１１の処理に進む。
【０１８６】
第３の実施形態においては、バッファ書込み処理部２６０１からのフレーム初到着通知ある場合、トークンが演算フレーム長以上であれば、トークンを演算フレーム長分に設定する。後述するＳ２９１４の処理において、フレームを読み出す際にフレーム長分のトークンを減算するため、蓄積されたトークンを全て使用することと同様になる。これにより、フレームが断続的に到着した場合でも、フレームの送信間隔を平滑化し、契約帯域を超過したフレームの送信を抑制する。
【０１８７】
次に、蓄積トークン量制御部２７０５は、バッファ管理レジスタの格納フレーム数３００２が０より大きく、かつトークン量保持部２７０１が保持するトークン量が、蓄積トークン量制御部２７０５から通知されるフレーム長以上であるか否かを判定する（Ｓ２９１１）。
【０１８８】
Ｓ２９１１において、バッファ管理レジスタの格納フレーム数３００２が０より大きく、かつトークン量保持部２７０１が保持するトークンがフレーム長以上である場合、蓄積トークン量制御部２７０５はスケジューラに送信要求を送出し（Ｓ２９１２）、Ｓ２９１３の処理に進む。一方、バッファ管理レジスタの格納フレーム数３００２が０より大きく、かつトークンがフレーム長以上でない場合、Ｓ２９１３の処理に進む。
【０１８９】
次に、トークン減算部７０２は、バッファ読出し処理部２６０２からの読出通知があるか否かを判定する（Ｓ２９１３）。
【０１９０】
Ｓ２９１３において、読出通知がない場合、処理を終了する（Ｓ２９１５）。一方、読出通知がある場合、トークン減算部７０２は、バッファ読出し処理部２６０２から通知される読出フレーム長分のトークン量を、トークン量保持部２７０１から減算し（Ｓ２９１４）、処理を終了する（Ｓ２９１５）。
【０１９１】
図２５は本発明の第３の実施形態の帯域制御部のトークンバケツのトークン量の変化とフレームの制御タイミングを示す説明図である。
【０１９２】
第３の実施形態の帯域制御部では、フロー毎に設定された契約帯域に対応する速度でトークンを加算する。送信するフレーム長分のトークンが加算されるとフレーム送信が可能であり、フレームを送信するとフレーム長分のトークンを減算する（Ｔ２２１１）。これにより、フレーム到着タイミングに対して、理想送信タイミングを決定する。図２５では、簡単化のため、フレームが固定長である場合を示しており、このため理想送信タイミングは一定となる。理想タイミングとは、他フローの影響を受けずに契約帯域で送信する場合のタイミングである。
【０１９３】
尚、第３の実施形態の帯域制御処理による、トークンバケツのトークン量の変化及びフレームの制御状態は、フレーム長が固定である場合は実施形態１で説明した図１２と同様であるが、Ｔ２２１６からＴ２２１７に至るまでのトークン量の変化が異なる。
【０１９４】
第３の実施形態の帯域制御部２６０３は、バケツの深さまでトークンを加算可能とする。これにより、Ｔ２２１０からＴ２２１５に至るまでのトークン量の変化は、実施形態１と同様であり、他ユーザフローのフレーム送信後、他フローのフレーム送信の間に蓄積したトークンに応じて待合わせたフレームを連続送信することができ、契約帯域分のフレームを送信可能とする。
【０１９５】
ただし、フレーム初到着通知がある場合は、トークン加算をフレーム長分までとする。トークン加算をフレーム長分までとすることにより、初到着したフレームを読み出す際にフレーム長分のトークンを減算するため、蓄積されたトークンを全て使用することと同様になる。これにより、実施形態１と同様に、フレームが断続的に到着した場合でも、フレームの送信間隔を平滑化し、契約帯域を超過したフレームの送信を抑制する。この様子を図２５を用いて説明する。
【０１９６】
Ｔ２２１５から、トークンが送信フレーム長に達するＴ２２１６に至るまでは一定トークンが加算される。また、Ｔ２２１６からＴ２２１７に至るまでも、バケツの深さを越えない範囲で、一定トークンが加算される。Ｔ２２１７においては、フレーム初到着通知があり、かつトークンがフレーム長分以上あるため（Ｓ２９０８からＳ２９０９）、Ｓ２９１０にて、トークンがフレーム長分に設定される。従って、実施形態１と同様に、Ｔ２２１８のタイミングでフレームを受信しても、畜積されたトークン量はフレーム長分より少ないためＴ２２１９のタイミングまでフレームは送信されず、契約帯域を超過したフレームの送信を抑制することができる。
【０１９７】
以上説明したように、第３の実施形態によれば、第１の実施形態の効果と同様に、帯域制御装置は、収容する複数ユーザフローに対して契約帯域を超過したフレームを通信キャリア網へ送信することを抑制し、出力競合が発生する場合でも各ユーザフローの契約帯域分のフレームを送信することができる。
【０１９８】
＜実施形態４＞
以下、本発明の第４の実施形態について図２６から図２８を用いて説明する。
【０１９９】
第１、第２及び第３の実施形態ではトークンバケツアルゴリズムを用いたが、第４の実施形態では、トークンを減算する方法であるリーキーバケツアルゴリズムを用いる。
【０２００】
第４の実施形態の帯域制御装置の構成は実施形態１で説明した図３と同じである。また、第４の実施形態の出力フレームバッファ制御部の構成も実施形態１で説明した図６と同じであるが、帯域制御部の構成は異なる。
【０２０１】
図２６は、本発明の第４の実施形態の帯域制御部の構成を示すブロック図である。
【０２０２】
帯域制御部４６０３は、トークン量保持部４７０１、トークン加算部７０２、トークン減算部４７０３、トークン減算量保持部４７０４、蓄積トークン量制御部４７０５、フレーム有無判定部４７０７、トークン量判定部４７０８、及びトークン判定量保持部４７０９を備える。
【０２０３】
トークン量保持部４７０１は、トークンバケツアルゴリズムに用いられるパラメータ（トークンバケツに蓄積されるトークン量）を保持する。トークン量保持部４７０１に蓄積されるトークン量は、送信フレーム長（読出フレーム長）に基づいて加算され、一定時間に一定量が減算される。トークン量保持部４７０１が保持するトークン量は、蓄積トークン量制御部４７０５により制御される。
【０２０４】
トークン加算部４７０２は、出力フレームバッファ３１０から読み出されたフレーム長に基づいて、トークン量保持部４７０１から、読出フレーム長に対応する量のトークンを加算する。
【０２０５】
トークン減算部４７０３は、一定タイミングで一定量のトークンを加算する。具体的には、トークン減算部４７０３は、トークン減算信号（例えば、クロック信号）が入力されると、トークン減算量保持部４７０４に保持された量のトークンを減算する。
【０２０６】
トークン減算量保持部４７０４は、定期的に減算されるトークン量を保持しており、設定レジスタ３１２により設定される。
【０２０７】
蓄積トークン量制御部４７０５は、バッファ管理レジスタ１３０９の格納フレーム数３００２に基づいて、トークン量保持部４７０１が保持するトークン量を制御する。本発明の第４の実施形態では、格納フレーム数が１以上の場合は０（最低値）、格納フレーム数が０の場合はトークン判定量保持部４７０９に設定された値を、蓄積トークン量制御部７０５がトークン量保持部４７０１を制御する値とする。
【０２０８】
フレーム有無判定部４７０７は、格納フレーム数３００２が０より大きいか否かを判定し、トークン量判定部４７０８に通知する。
【０２０９】
トークン量判定部４７０８は、フレーム有無判定部４７０７より格納フレーム数３００２が０より大きいことを通知された場合、トークン量保持部４７０１が保持するトークン量（トークン量）とトークン判定量保持部４７０９が保持するトークン量（一定量）の大小を判定し、（トークン量）≦（一定量）であれば出力スケジューラ６０５にフレームの送信要求を出す。
【０２１０】
トークン判定量保持部４７０９は、トークン量判定部７０８が出力スケジューラ６０５へ送信要求を行うか否かの基準となるトークン量（一定量）を保持しており、設定レジスタ３１２により設定される。
【０２１１】
以下に、帯域制御部４６０３が実行する帯域制御処理（Ｓ４９５０）について説明する。
【０２１２】
図２７は、本発明の第４の実施形態の帯域制御部が実行する帯域制御処理を示すフローチャートである。
【０２１３】
トークン減算部４７０３は、一定タイミングでトークン減算信号が入力されると処理を開始し（Ｓ４９００）、トークン減算量保持部４７０４が保持する一定トークン量を、トークン量保持部４７０１から減算する（Ｓ４９０１）。この一定タイミングで一定量減算するトークンが各フローの契約帯域に相当する。一定量は、ＮＩＦ管理部１３１１が制御する設定レジスタ３１２から設定される。
【０２１４】
次に、蓄積トークン量制御部４７０５は、バッファ管理レジスタ１３０９から格納フレーム数３００２を取得し、取得した格納フレーム数３００２が０より大きいか否かを判定する（Ｓ４９０２）。
【０２１５】
Ｓ４９０２において、格納フレーム数３００２が０より大きい場合、蓄積トークン量制御部４７０５は、トークン量保持部４７０１が保持するトークン量が０より小さいか否かを判定する（Ｓ４９０３）。
Ｓ４９０３において、０より小さくない場合、Ｓ４９０７の処理に進む。一方、トークン量が０より小さい場合は、蓄積トークン量制御部４７０５は、トークン量保持部４７０１が保持するトークン量を０に設定し（Ｓ４９０４）、Ｓ４９０７の処理に進む。
【０２１６】
次に、トークン量判定部４７０８は、トークン量保持部４７０１が保持するトークン量が、トークン判定量保持部７０９が保持する一定量以下であるか否かを判定する（Ｓ４９０７）。
【０２１７】
Ｓ４９０７において、トークン量保持部４７０１が保持するトークン量が一定量以下である場合、トークン量判定部４７０８は出力スケジューラ６０５に送信要求を送信し（Ｓ４９０８）、Ｓ４９１０の処理に進む。ここで、一定量以下である場合、トークン量判定部４７０８がトークン量を監視しているフローのフレーム読み出しが可能であると判断することにより、一定量から０まで減算されるトークン量に応じたフレームの連続送信が可能となる。
【０２１８】
一方、Ｓ４９０２において、格納フレーム数３００２が０である場合、蓄積トークン量制御部４７０５は、トークン量保持部４７０１が保持するトークン量が、トークン判定量保持部４７０９が保持する一定量より小さいか否かを判定する（Ｓ４９０５）。
Ｓ４９０５において、トークン量が一定量より小さい場合、蓄積トークン量制御部４７０５は、トークン量保持部４７０１が保持するトークン量を一定量に設定し（Ｓ４９０６）、Ｓ４９１０の処理に進む。第４の実施形態においては、この格納フレーム数３００２が０である場合にトークン量の減算を一定量までと設定することによって、フレームが断続的に到着した場合でも、フレームの送信間隔を平滑化し、契約帯域を超過したフレームの送信を抑制する。また、Ｓ４９０５において、トークン量が一定量以上の場合、Ｓ４９１０の処理に進む。
【０２１９】
また、Ｓ４９０７において、トークン量が一定量以下でない場合は、Ｓ４９１０の処理に進む。
【０２２０】
トークン加算部４７０２は、バッファ読出し処理部１６０２からの読出通知があるか否かを判定する（Ｓ４９１０）。
【０２２１】
Ｓ４９１０において、読出通知がない場合、処理を終了する（Ｓ４９１２）。一方、読出通知がある場合、トークン加算部４７０２は、バッファ読出し処理部１６０２からの読出フレーム長分のトークン量を、トークン量保持部４７０１に加算し（Ｓ４９１１）、処理を終了する（Ｓ４９１２）。
【０２２２】
尚、図２６及び図２７では、格納フレーム数３００２が０であるか否かによって、トークンの減算下限値を変更するとしたが、格納フレーム数がある一定数を超えた場合にトークンの減算下限値を変更することとしてもよい。
図２８は、図２７で説明した本発明の第４の実施形態の帯域制御部４６０３が実行する帯域制御処理による、トークンバケツのトークン量の変化及びフレームの制御状態を示す説明図である。
本発明の帯域制御部では、フロー毎に設定された契約帯域に対応する速度でトークンを減算する。トークンが一定量になるとフレーム送信が可能であり、フレームを送信するとフレーム長分のトークンを加算する（Ｔ４２１１）。これにより、フレーム到着タイミングに対して、理想送信タイミングを決定する。図２８では、簡単化のため、フレームが固定長である場合を示しており、このため理想送信タイミングは一定となる。理想タイミングとは、他フローの影響を受けずに契約帯域で送信する場合のタイミングである。
フレームがフロー制御部に到着すると、バッファ書き込み処理Ｓ１７５０を実行し、バッファ管理レジスタ１３０９の格納フレーム数を１加算して、フレームを出力フレームバッファ３１０に格納する。フレームを送信する際（実送信）、バッファ読み出し処理Ｓ１８５０を実行し、バッファ管理レジスタ１３０９の格納フレーム数を１減算して、フレームを出力フレームバッファ３１０から読出す。
他フローと出力競合が発生した場合、すなわち、図２７のＳ４９１０で読み出し通知がない場合、該フローのフレーム送信を理想タイミングで実現できず、出力スケジューラからの読出通知を受信するまで該フローのフレームの送信を待合わせる必要がある。そのため、本発明の帯域制御部は、バッファ管理レジスタ１３０９から取得する格納フレーム数が１以上の場合は、一定量を下回り０までトークンを減算可能とする。これにより、他ユーザフローのフレーム送信後、他フローのフレーム送信の間に減算したトークンに応じて待合わせたフレームを連続送信することができ、契約帯域分のフレームを送信可能とする。
この様子を図２８を用いて説明する。Ｔ４２１２では、トークンは一定量まで減算されているが出力スケジューラからの読出通知を受領していないため、フレームを読み出すことが出来ない状態である。図２７のＳ４９０２、４９０３、４９０７、Ｓ４９０８、Ｓ４９１０、Ｓ４９１２の判断となる場合である。Ｓ４９０３において、０よりもトークン量が大きいためトークン量を０に設定するなどのトークン量の設定は行わない。この場合、Ｔ４２１２のタイミングで実送信４２０６は実行されていない。これは、他ユーザフロー送信４２０７で示す通り、他ユーザフローのフレームを読み出しているためである。Ｔ４２１２の後、出力スケジューラから読出通知を受領するＴ４２１３までトークン量が０より小さくならない限りトークンを減算する（Ｓ４９０３）。Ｔ４２１３で出力スケジューラから読出通知を受領すると、一定量以下のトークンがバケツに保持されているためフレームを読み出す。さらにＴ４２１４で出力スケジューラから読出通知を受領すると、このタイミングでもトークンは一定量以下であるためフレームを読み出す。これはＴ４２１２からＴ４２１３の間もトークンを減算していたためである。これにより、Ｔ４２１４の実送信４２０６に示すように、Ｔ４２１２で待ち合わせた帯域分をＴ４２１４で読み出すことができる。
一方、格納フレーム数が０である場合は、トークン減算は一定量までとする。フレームが断続的に到着した場合、瞬間的に契約帯域を超過したフレームが到着するため、トークン減算を一定量までとすることにより、フレームが断続的に到着した場合でも、フレームの送信間隔を平滑化し、契約帯域を超過したフレームの送信を抑制する。
この様子を図２８を用いて説明する。Ｔ４２１５から、トークンが一定値に達するＴ４２１６に至るまでは一定量のトークンが減算される。しかしながら、Ｔ４２１６においては、格納フレーム数は０であり（Ｓ４９０２からＳ４９０５）、Ｔ４２１７でフレームを受信し格納フレーム数が１となるまでは、Ｓ４９０５の判定においてトークンが一定量より小さくなるため、Ｓ４９０６にて、トークンが一定値に設定される。従って、Ｔ４２１８のタイミングでフレームを受信しても、畜積されたトークン量は一定量より大きいためＴ４２１９のタイミングまでフレームは送信されず、契約帯域を超過したフレームの送信を抑制することができる。
【０２２３】
従って、第４の実施形態によれば、帯域制御装置は、収容する複数ユーザフローに対して契約帯域を超過したフレームを通信キャリア網へ送信することを抑制し、出力競合が発生する場合でも各ユーザフローの契約帯域分のフレームを送信することができる。
【０２２４】
また、第４の実施形態では、第１の実施形態のトークンバケツアルゴリズムを用いた場合に対するトークンの減算モデルを示したが、第２の実施形態のトークンバケツアルゴリズムを用いた場合に対するトークンの減算モデルとして、フレーム有フラグが１であり、かつ、トークンが一定量より小さい場合に、バッファ書込み処理部６０１からのフレーム初到着通知があればトークンを一定量に設定するとしてもよい。また、第３の実施形態のトークンバケツアルゴリズムを用いた場合に対するトークンの減算モデルとして、バケツの最大値から送信するフレーム長分のトークンが減算されるとフレーム送信が可能であるとし、トークンがバケツの最大値からフレーム長分以上に減算されている場合に、バッファ書込み処理部２６０１からのフレーム初到着通知がある場合は、トークンをバケツの最大値からフレーム長分減算された値に設定するとしてもよい。
【符号の説明】
【０２２５】
３ 帯域制御装置
４ 装置内ヘッダ
５ 通信フレーム
２３ 帯域制御装置
１０１ 帯域制御装置
３００ ネットワークインタフェースボード
３０１ 入出力回線インタフェース
３０２ 入力ヘッダ処理部
３０３ 入力フレームバッファ制御部
３０４ 入力フレームバッファ
３０５ ＳＷインタフェース
３０６ スイッチ部
３０７ 出力ヘッダ処理部
３０８ 出力フレームバッファ制御部
３０９ バッファ管理テーブル
３１０ 出力フレームバッファ
３１１ ＮＩＦ管理部
３１２ 設定レジスタ
３５０ 論理回路
４０１ 出力ネットワークインタフェースボード識別子
４０２ フローＩＤ
４０３ フレーム長
５０１ 宛先ＭＡＣアドレス
５０２ 送信元ＭＡＣアドレス
５０３ ＶＬＡＮヘッダ
５０４ イーサタイプ値
５０５ ペイロード
５０６ フレームチェックシーケンス
６０１ バッファ書込み処理部
６０２ バッファ読出し処理部
６０３ 帯域制御部
６０４ フロー制御部
６０５ 出力スケジューラ
７０１ トークン量保持部
７０２ トークン減算部
７０３ トークン加算部
７０４ トークン加算量保持部
７０５ 蓄積トークン量制御部
７０６ 最大蓄積トークン量保持部
７０７ フレーム有無判定部
７０８ トークン量判定部
７０９ トークン判定量保持部１００１ フローＩＤ
１００２ バッファサイズ
１００３ 格納フレーム数
１００４ 格納バイト数
１００５ ライトポインタ
１００６ リードポインタ
１３０８ 出力フレームバッファ制御部
１３０９ バッファ管理レジスタ
１３１１ ＮＩＦ管理部
１６０１ バッファ書込み処理部
１６０２ バッファ読出し処理部
１６０３ 帯域制御部
１６０４ フロー制御部
１７０１ トークン量保持部
１７０５ 蓄積トークン量制御部
１７０８ トークン量判定部２３０８ 出力フレームバッファ制御部
２６０１ バッファ書込み処理部
２６０２ バッファ読出し処理部
２６０３ 帯域制御部
２６０４ フロー制御部
２６０９ 書込フレーム長格納キュー
２７０１ トークン量保持部
２７０５ 蓄積トークン量制御部
２７０８ トークン量判定部
３００１ バッファサイズ
３００２ 格納フレーム数
３００３ 格納バイト数
３００４ ライトポインタ
３００５ リードポインタ
４６０３ 帯域制御部
４７０１ トークン量保持部
４７０２ トークン加算部
４７０３ トークン減算部
４７０４ トークン減算量保持部
４７０５ 蓄積トークン量制御部
４７０７ フレーム有無判定部
４７０８ トークン量判定部
４７０９ トークン判定量保持部
【技術分野】
【０００１】
本発明は、パケット網の帯域制御に関する帯域制御の方法に関する。
【背景技術】
【０００２】
大容量で安価なイーサネット（商標登録、以下同じ）の普及に伴い、イーサネット専用線サービスが増加している。専用線サービスは高い信頼性が要求される通信サービスであり、専用線サービスを提供するキャリアは、ＳＬＡ（Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ）において規定する帯域を保証する必要がある。
【０００３】
近年のイーサネット専用線サービスでは、通信装置が複数ユーザを論理多重することでシステム構築コストを削減している。ユーザサイトへ接続する専用装置（ユーザアクセス装置）が回線内に複数ユーザフローを収容し、さらに中継装置がユーザアクセス装置を複数多重することで、サービスに必要な通信装置の数は減少する。
【０００４】
イーサネット専用線サービスを提供する通信キャリアは、通信キャリア網のエッジに位置するユーザアクセス装置が収容する各々のユーザフローに対して契約帯域を通信キャリア網内で割当てる。ユーザサイトから通信キャリア網のエッジに位置するユーザアクセス装置へ流入するトラフィックは，平均帯域が契約帯域以下であっても，瞬間的に契約帯域を超過したトラフィックとなる場合がある。この契約帯域を超過したトラフィックが複数のユーザサイトから通信キャリア網に流入すると、通信キャリア網内の中継装置の回線容量を超過し、通信キャリア網内でフレーム廃棄が発生する可能性がある。通信キャリアは、各ユーザフローに対して契約帯域分の通信帯域を通信キャリア網内で保証するためには、通信キャリア網へ流入する各ユーザフローのトラフィックの帯域を常に契約帯域以下に抑える必要がある。尚、通信キャリアはユーザサイト内（すなわち、ユーザ端末とユーザアクセス装置間の）の帯域の変動は保証しない。
【０００５】
通信キャリアは、通信キャリア網内に流入する各ユーザフローのトラフィックの帯域を契約帯域以下に抑えるため、ユーザアクセス装置にシェーパを実装する。ユーザアクセス装置がシェーパを実装することにより通信キャリア網内でのフレーム廃棄確率が小さくなることは、待ち行列理論などで一般的に知られている。
【０００６】
フロー毎に帯域を制御するため、トークンバケツアルゴリズムを用いてシェーパを実現することが特許文献１に開示されている。トークンバケツアルゴリズムは、設定された帯域に対応する速度で帯域制御カウンタ（トークン）を加算し、送信するフレーム長分のトークンが蓄積されていればフレームを送信し、フレーム長分のトークンを減算する。特許文献１では、ユーザトラフィックを複数フローに分類し、フロー毎にバケツの深さを持たせ、各フローの帯域を各フローのトークンバケツアルゴリズムにより制御することが開示されている。これにより、各フローのフレームの送信間隔を平滑化し、送信帯域を制御することを目的としている。 ユーザアクセス装置は、複数ユーザフローを収容する場合は出力競合が発生するため、各ユーザフローのフレームを送信する順番を制御（スケジューリング）する必要がある。各トークンバケツアルゴリズムは、自身が帯域を制御するユーザフローのフレームを送信する際、他ユーザフローのフレームが送信中である場合はフレーム送信を待合わせる必要がある。出力競合はユーザアクセス装置内部の問題であり、ユーザアクセス装置は各ユーザフローの送信可能な帯域が契約帯域を下回らないように保証する必要がある。
【０００７】
そのため、トークンバケツアルゴリズムにおいて、トークンバケツの深さまでトークンの蓄積を可能とし、他ユーザフローのフレーム送信を待合わせる際もトークンを加算する。他ユーザフローのフレームが送信された後、蓄積したトークンに応じて待合わせたフレームを連続送信する。未来時間で待合わせた帯域を補うことで、出力競合が生じる場合でも契約帯域分のフレーム送信を可能とする。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００９−１４７８７４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、トークンバケツの深さまで常にトークンを蓄積すると、単一フローのユーザフレームが通信装置に断続的に到着し、他フローとの出力競合がない場合、通信装置は、蓄積されているトークン量分、単一フローのフレームを連続して送信する。したがって、各フローの契約帯域を超過したトラフィックが通信装置から送信されるという問題があった。 本発明は、前述した問題に鑑みてなされたものであり、収容する複数ユーザフローに対して、他フローとの出力競合が発生した場合には、出力競合で待ち合わせた分の各ユーザフローの契約帯域分のフレームを送信可能としつつ、他フローとの出力競合が発生していない場合には、各フローの契約帯域以下でフレームを送出する帯域制御装置及び帯域制御方法を提供することを目的とする。
以上では、トークンバケツアルゴリズムを用いて説明したが、リーキーバケツアルゴリズムを用いた場合も、他フローとの出力競合が生じた場合に待ち合わせた分の各ユーザフローの契約帯域分のフレームを送信可能とするためには、トークンが一定量以下であればフレームを送信可能とし、トークンを一定量よりも減算できるようにすることが必要となるが、常にトークンを一定量よりも減算できるようにすると、他フローとの出力競合が発生していない場合には、減算されたトークンにより各フローの契約帯域以上でフレームを送出することとなる問題がある。
【課題を解決するための手段】
【００１０】
本発明の代表的な一例を示せば以下のとおりである。すなわち、
ネットワークに接続される通信装置であって、フレームを受信する入力インタフェースと、前記入力インタフェースで受信したフレームを保持する出力フレームバッファと、前記入力インタフェースで受信したフレームの読み出し要求通知タイミングをフロー毎に制御する複数の帯域制御部と、前記複数の帯域制御部から通知される各フローの前記フレーム読み出し要求に基づいて、前記フレームの読み出しタイミングを決定する出力スケジューラと、前記出力スケジューラから通知されるタイミングで前記フレームを出力する出力インタフェースと、を備え、前記帯域制御部は、フロー毎に保持されるトークン値に基づいて該フローの読み出し要求を出力スケジューラに通知するかしないかを判定し、前記出力フレームバッファのフレームの蓄積量に基づいて、前記トークン値の加減算量を決定することを特徴とする。
【発明の効果】
【００１１】
本発明の一実施形態によれば、帯域制御装置は、収容する複数ユーザフローに対して契約帯域を超過したフレームを通信キャリア網へ送信することを抑制し、出力競合が発生する場合でも各ユーザフローの契約帯域分のフレームを送信することができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の第１の実施形態のネットワークシステムの例を示す説明図である。
【図２】本発明の帯域制御装置を通過する前後でのフレーム量の変動を示す図である。
【図３】本発明の第１の実施形態の帯域制御装置の構成を示すブロック図である。
【図４】本発明の第１の実施形態の帯域制御装置の通信フレームに付加される装置内ヘッダのフォーマットの一例を示す説明図である。
【図５】本発明の第１の実施形態の通信フレームのフォーマットの一例を示す説明図である。
【図６】本発明の第１の実施形態の出力フレームバッファ制御部の構成を示すブロック図である。
【図７】本発明の第１の実施形態のバッファ管理レジスタ情報を示す説明図である。
【図８】本発明の第１の実施形態のバッファ書込み処理部が実行するバッファ書込み処理を示すフローチャートである。
【図９】本発明の第１の実施形態のバッファ読出し処理部が実行するバッファ読出し処理を示すフローチャートである。
【図１０】本発明の第１の実施形態の帯域制御部の構成を示すブロック図である。
【図１１】本発明の第１の実施形態の帯域制御部が実行する帯域制御処理を示すフローチャートである。
【図１２】本発明の第１の実施形態の帯域制御方法の概要を示す説明図である。
【図１３】本発明の第２の実施形態の帯域制御装置の構成を示すブロック図である。
【図１４】本発明の第２の実施形態のバッファ管理テーブルを示す説明図である。
【図１５】本発明の第２の実施形態の出力フレームバッファ制御部の構成を示すブロック図である。
【図１６】本発明の第２の実施形態のバッファ書込み処理部が実行するバッファ書込み処理を示すフローチャートである。
【図１７】本発明の第２の実施形態のバッファ読出し処理部が実行するバッファ読出し処理を示すフローチャートである。
【図１８】本発明の第２の実施形態の帯域制御部の構成を示すブロック図である。
【図１９】本発明の第２の実施形態の帯域制御部が実行する帯域制御処理を示すフローチャートである。
【図２０】本発明の第３の実施形態の帯域制御装置の構成を示すブロック図である。
【図２１】本発明の第３の実施形態の出力フレームバッファ制御部の構成を示すブロック図である。
【図２２】本発明の第３の実施形態のバッファ書込み処理部が実行するバッファ書込み処理を示すフローチャートである。
【図２３】本発明の第３の実施形態の帯域制御部の構成を示すブロック図である。
【図２４】本発明の第３の実施形態の帯域制御部が実行する帯域制御処理を示すフローチャートである。
【図２５】本発明の第３の実施形態の帯域制御方法の概要を示す説明図である。
【図２６】本発明の第４の実施形態の帯域制御部の構成を示すブロック図である。
【図２７】本発明の第４の実施形態の帯域制御部が実行する帯域制御処理を示すフローチャートである。
【図２８】本発明の第４の実施形態の帯域制御方法の概要を示す説明図である。
【発明を実施するための形態】
【００１３】
以下、本発明の実施例について、図面を参照して説明する。
【００１４】
＜実施形態１＞
以下、本発明の第１の実施形態について図１から図１２を用いて説明する。なお、以下に述べる第１の実施形態は本発明の実施形態の一つであって、本発明を制限するものではない。
【００１５】
図１は、本発明の第１の実施形態の通信装置を適用するネットワークシステムの例を示す説明図である。
【００１６】
通信キャリア網は、中継装置102-1〜102-n、及び、ユーザアクセス装置(帯域制御装置)101-1〜101-nを備える。中継装置102-1〜102-nは、中継網を構成し、複数のユーザアクセス装置101-1〜101-nを収容する。本発明の第１の実施形態のユーザアクセス装置（帯域制御装置）は、通信キャリア網の端点に設置され、ユーザサイトに設置されたユーザ装置103-1〜nを収容する。ユーザ装置から送信されるフローは、ＳＷ、ユーザアクセス装置（帯域制御装置）、中継装置、対向のユーザアクセス装置、を介して対向のユ-ザ装置に送信される。
【００１７】
通信キャリアは、ユーザアクセス装置（帯域制御装置）が収容する各々のユーザフローに対して契約帯域を割当てる。ユーザサイトから通信キャリア網へ流入するトラフィックは，平均帯域が契約帯域以下であっても，瞬間的に契約帯域を超過したトラフィックとなる。この様子を図２Ａに示した。ユーザ装置103-1から送出される１ユーザフローの送出帯域の時間変化を示す。契約帯域は、図１に示した通信キャリア網内でユーザ装置103-1から送出されるフローに対する契約帯域である。
【００１８】
本願では、帯域制御装置は、以下で説明する帯域制御部（シェーパ）を実装し、各ユーザフローの契約帯域に応じてフレームの送信間隔を平滑化する。
【００１９】
以下に、本発明の帯域制御装置における通信フレームについて説明する。
【００２０】
図５は、本発明の第１の実施形態の通信フレームのフォーマットの一例を示す説明図である。
【００２１】
通信フレーム５は、宛先ＭＡＣアドレス５０１、送信元ＭＡＣアドレス５０２、ＶＬＡＮヘッダ５０３、イーサタイプ値５０４、ペイロード５０５、及び、フレームチェックシーケンス（ＦＣＳ）５０６を含む。宛先ＭＡＣアドレス５０１及び送信元ＭＡＣアドレス５０２には、帯域制御装置１０１、または端末のＭＡＣアドレスが設定される。ＶＬＡＮヘッダ５０３には、フローの識別子となるＶＬＡＮ ＩＤが設定される。
以下に、帯域制御装置１０１の構成について説明する。
【００２２】
図３は、本発明の第１の実施形態の帯域制御装置の構成を示すブロック図である。
【００２３】
帯域制御装置１０１は、複数のネットワークインタフェースボード（ＮＩＦ）（３００−１〜３００−Ｍ）、それぞれのＮＩＦ３００に接続されたスイッチ部３０６を備える。
【００２４】
各ＮＩＦ３００は、通信ポートとなる入出力回線インタフェース３０１、スイッチ部３０６に接続されたＳＷインタフェース３０５、論理回路３５０、及びＮＩＦ管理部１３１１を備える。帯域制御装置１０１は、これらの入出力回線インタフェース３０１を介して、他の装置と接続されている。第１の実施形態では、入出力回線インタフェース３０１は、イーサネット用の回線インタフェースである。
【００２５】
論理回路３５０は、これらの入出力回線インタフェース３０１に接続された入力ヘッダ処理部３０２、入力ヘッダ処理部３０２に接続された入力フレームバッファ制御部３０３、ＳＷインタフェース３０５に接続された出力ヘッダ処理部３０７、出力ヘッダ処理部３０７に接続された出力フレームバッファ制御部１３０８、及び、設定レジスタ３１２を備える。
【００２６】
入出力回線インタフェース３０１は、受信した通信フレーム５に装置内ヘッダ４を付加する。
【００２７】
図４は、入出力回線インタフェース３０１が受信したフレームに付加する装置内ヘッダのフォーマットの一例を示す説明図である。装置内ヘッダ４は、出力ネットワークインタフェースボード識別子（出力ＮＩＦ ＩＤ）４０１、フローＩＤ４０２、及び、フレーム長４０３を含む。このうち、出力ＮＩＦ ＩＤ４０１は、内部ルーティング情報となっており、スイッチ部３０６は、この内部ルーティング情報に従い、入力フレームを特定のネットワークインタフェースボードの特定のＳＷインタフェースに転送する。
【００２８】
入出力回線インタフェース３０１が受信した通信フレーム５に装置内ヘッダ４を付加した時点では、出力ＮＩＦ ＩＤ４０１、フローＩＤ４０２は空欄である。出力ＮＩＦ ＩＤ４０１、及び、フローＩＤ４０２には、入力ヘッダ処理部３０２によって値が設定される。
【００２９】
入力ヘッダ処理部３０２は、受信フレームの５０３に基づいて各入力フレーム（装置内ヘッダ４が付与された通信フレーム５）のフローを識別し、識別されたフローに応じてＶＬＡＮタグの処理を実行し、装置内ヘッダ４に出力ＮＩＦ ＩＤ４０１、及び、フローＩＤ４０２を追加する。ＶＬＡＮタグの処理とは、ＶＬＡＮタグの透過、変換、付与及び削除である。
【００３０】
入力ヘッダ処理部３０２は、ＶＬＡＮタグの処理において、宛先ＭＡＣアドレス５０１及び送信元ＭＡＣアドレス５０２を、入出力回線インタフェース３０１に設定される値で上書きしてもよいし、フロー毎に登録しておいた値で上書きしてもよい。
【００３１】
ＶＬＡＮタグを処理し、装置内ヘッダ４に出力ＮＩＦ ＩＤ４０１及びフローＩＤ４０２を追加した後、入力ヘッダ処理部３０２は、入力フレームを入力フレームバッファ制御部３０３に転送する。
【００３２】
入力フレームバッファ制御部３０３は、入力ヘッダ処理部３０２から入力フレームを受信すると、入力フレームバッファ３０４にフレームを格納する。さらに、入力フレームバッファ３０４に格納されたフレームを読み出し、フレーム間ギャップを調整してＳＷインタフェース３０５に送信する。
【００３３】
スイッチ部３０６は、各ＮＩＦ３００のＳＷインタフェース３０５から入力フレームを受信した後、受信した入力フレームの転送先である出力ＮＩＦ ＩＤ４０１を特定する。次に、スイッチ部３０６は、受信した入力フレームを、出力フレームとして、特定されたＮＩＦ３００に対応するＳＷインタフェース３０５に転送する。
【００３４】
ＳＷインタフェース３０５は、受信した出力フレームを出力ヘッダ処理部３０７に転送する。第１の実施形態では、入力ヘッダ処理部３０２が入力フレームから出力フレームへのフォーマット変換を実行したが、代わりに、出力ヘッダ処理部３０７がフォーマット変換を実行してもよい。なお、入力ヘッダ処理部３０２においてフォーマット変換（ヘッダ変換）がなされている場合には、出力ヘッダ処理部３０７は、ＳＷインタフェース３０５から受信した出力フレームをそのまま出力フレームバッファ制御部１３０８に転送する。
【００３５】
出力フレームバッファ制御部１３０８は、出力フレームをフロー毎の出力フレームバッファ３１０に蓄積する。出力フレームバッファ制御部１３０８は、格納された出力フレームをバッファ管理レジスタ１３０９に設定されたフロー毎の情報を用いてシェーピングしながら出力フレームバッファ３１０から読出し、入出力回線インタフェース３０１に送出する。
【００３６】
入出力回線インタフェース３０１は、出力フレームから装置内ヘッダ４を除去した後、図５に示すフォーマットで出力フレームを他の装置へ転送する。
【００３７】
ＮＩＦ管理部１３１１は、設定レジスタ３１２を制御する。設定レジスタ３１２は、各ブロックのレジスタ値を設定する。
【００３８】
図６は、本発明の第１の実施形態の出力フレームバッファ制御部の構成を示すブロック図である。
【００３９】
出力フレームバッファ制御部１３０８は、フロー制御部１６０４、及び、出力スケジューラ６０５を備える。
【００４０】
また、フロー制御部１６０４は、バッファ書込み処理部１６０１、バッファ読出し処理部１６０２、帯域制御部１６０３、バッファ管理レジスタ１３０９、及び、出力フレームバッファ３１０から構成される。
【００４１】
バッファ書込み処理部１６０１は、出力ヘッダ処理部３０７からのフレームを受信すると、後述するバッファ書込み処理Ｓ１７５０を実施する。バッファ書込み処理部１６０１は、フレームを受信すると、フレームの内部ヘッダのフローＩＤ４０２に基づいてフローを識別し、自フロー制御部で処理すべきフレームであった場合、フレームを出力フレームバッファ３１０に格納し、バッファ管理レジスタ１３０９を更新する。 帯域制御部１６０３は、後述する帯域制御処理Ｓ１９５０を実施し、送信要求を出力スケジューラ６０５に送信する。
【００４２】
出力スケジューラ６０５は、各フロー制御部（１６０４−１〜Ｎ）の帯域制御部１６０３から送信要求を受信すると、読出すフレームをスケジューリングする。出力スケジューラ６０５は、送信要求を各フロー制御部（１６０４−１〜Ｎ）のバッファ読出し処理部１６０２に送信し、バッファ読出し処理部１６０２から受信したフレームを入出力回線インタフェース３０１に送出する。
【００４３】
バッファ読出し処理部１６０２は、出力スケジューラ６０５からフレーム送信要求を受信すると、後述するバッファ読出し処理Ｓ１８５０を実施する。バッファ読出し処理部１６０２は、出力フレームバッファ３１０から読出したフレームを出力スケジューラ６０５に送信し、バッファ管理レジスタ１３０９を更新し、読出通知、及び、読出フレーム長通知を帯域制御部１６０３に送信する。
【００４４】
図７は、本発明の第１の実施形態のバッファ管理レジスタ情報を示す説明図である。
バッファ管理レジスタ１３０９は、バッファ管理レジスタ情報３０として、バッファサイズ：３００１、格納フレーム数：３００２、格納バイト数：３００３、ライトポインタ３００４、及び、リードポインタ３００５を備える。ここで、バッファサイズ３００１は、運用するバッファサイズを示し、格納フレーム数３００２は、バッファに格納されているフレーム数を示し、格納バイト数３００３は、バッファに格納されているバイト数を示し、ライトポインタ３００４は、バッファのライト開始アドレスを示し、リードポインタ３００５は、バッファのリード開始アドレスを示す。
以下に、バッファ書込み処理部１６０１が実行するバッファ書込み処理（Ｓ１７５０）について説明する。
【００４５】
図８は、本発明の第１の実施形態のバッファ書込み処理部が実行するバッファ書込み処理を示すフローチャートである。
【００４６】
バッファ書込み処理部１６０１は、出力ヘッダ処理部３０７からフレームを受信する（Ｓ１７００）と、装置内ヘッダ４からフローＩＤ４０２、及び、フレーム長４０３を取得する（Ｓ１７０１）。
【００４７】
次に、バッファ書込み処理部１６０１は、取得したフローＩＤ４０２が設定レジスタ３１２から設定されたフローＩＤと同一であるか否かを判定する（Ｓ１７０２）。
【００４８】
Ｓ１７０２において、取得したフローＩＤ４０２が設定されたフローＩＤと同一である場合、バッファ管理レジスタ１３０９から、バッファサイズ３００１、ライトポインタ３００４、格納フレーム数３００２、及び、格納バイト数３００３を取得する（Ｓ１７０３）。
【００４９】
次に、バッファ書込み処理部１６０１は、取得した格納バイト数３００３とフレーム長４０３を足し合わせた値と、バッファサイズ３００１を比較する（Ｓ１７０４）。
【００５０】
Ｓ１７０４において、取得した格納バイト数３００３とフレーム長４０３を足し合わせた値がバッファサイズ３００３以下である場合、ライトポインタ３００４、格納フレーム数３００２、及び、格納バイト数３００３を更新し、出力フレームバッファ３１０にフレームを送出し、前記各更新値をバッファ管理レジスタ１３０９に設定し（Ｓ１７０５）、処理を終了する（Ｓ１７０７）。
【００５１】
また、Ｓ１７０２において、取得したフローＩＤ４０２が設定されたフローＩＤと同一でない場合、処理対象外フローのフレームを示しており、フレームを廃棄し（Ｓ１７０６）、処理を終了する（Ｓ１７０７）。
【００５２】
また、Ｓ１７０４において、取得した格納バイト数３００３とフレーム長４０３を足し合わせた値がバッファサイズ３００１より大きい場合、バッファがオーバーフローすることを示しており、フレームを廃棄し（Ｓ１７０６）、処理を終了する（Ｓ１７０７）。
【００５３】
次に、バッファ読出し処理部１６０２が実行するバッファ読出し処理（Ｓ１８５０）について説明する。
【００５４】
図９は、本発明の第１の実施形態のバッファ読出し処理部が実行するバッファ読出し処理を示すフローチャートである。
【００５５】
バッファ読出し処理部１６０２は、出力スケジューラ６０５からフレーム送信要求を受信する（Ｓ１８００）と、バッファ管理レジスタ１３０９から、リードポインタ３００５、格納フレーム数３００２、及び、格納バイト数３００３を取得する（Ｓ１８０１）。
【００５６】
次に、リードポインタ３００５、格納フレーム数３００２、及び、格納バイト数３００３を更新し、出力フレームバッファ３１０から出力スケジューラ６０５へフレームを送信し、前記各更新値をバッファ管理レジスタ１３０９に設定し（Ｓ１８０２）、処理を終了する（Ｓ１８０４）。
【００５７】
一方、バッファ読出し処理部１６０２は、Ｓ１８０２と同時に、帯域制御部１６０３に読出通知、及び、読出フレーム長通知を送信し（Ｓ１８０３）、処理を終了する（Ｓ１８０４）。
【００５８】
図１０は、本発明の第１の実施形態の帯域制御部の構成を示すブロック図である。
【００５９】
帯域制御部１６０３は、トークン量保持部７０１、トークン減算部７０２、トークン加算部７０３、トークン加算量保持部７０４、蓄積トークン量制御部７０５、最大蓄積トークン量制御部７０６、フレーム有無判定部７０７、トークン量判定部７０８、及びトークン判定量保持部７０９を備える。
【００６０】
トークン量保持部７０１は、トークンバケツアルゴリズムに用いられるパラメータ（トークンバケツに蓄積されるトークン量）を保持する。トークン量保持部７０１に蓄積されるトークン量は、送信フレーム長（読出フレーム長）に基づいて減算され、一定時間に一定量が加算される。トークン量保持部７０１が加算（蓄積）可能なトークン量は、蓄積トークン量制御部７０５により制御される。
【００６１】
トークン減算部７０２は、出力フレームバッファ３１０から読み出されたフレーム長に基づいて、トークン量保持部７０１から、読出フレーム長に対応する量のトークンを減算する。
【００６２】
トークン加算部７０３は、一定タイミングで一定量のトークンを加算する。具体的には、トークン加算部７０３は、トークン加算信号（例えば、クロック信号）が入力されると、トークン加算量保持部７０４に保持された量のトークンを加算する。
【００６３】
トークン加算量保持部７０４は、定期的に加算されるトークン量を保持しており、この定期的に加算されるトークン量は、設定レジスタ３１２により設定される。
【００６４】
蓄積トークン量制御部７０５は、バッファ管理レジスタ１３０９の格納フレーム数３００２に基づいて、トークン量保持部７０１が加算するトークン量を制御する。本発明の第１の実施形態では、格納フレーム数が１以上の場合は最大蓄積トークン量保持部７０６に設定された値、格納フレーム数が０の場合はトークン判定量保持部７０９に設定された値を、蓄積トークン量制御部７０５がトークン量保持部７０１を制御する値とする。
【００６５】
最大蓄積トークン量保持部７０６は、トークン量保持部７０１で加算できる最大のトークン量（バケツの深さ）を保持しており、バケツの深さは、設定レジスタ３１２により設定される。
【００６６】
フレーム有無判定部７０７は、格納フレーム数３００２が０より大きいか否かを判定し、トークン量判定部７０８に通知する。
【００６７】
トークン量判定部７０８は、フレーム有無判定部７０７より格納フレーム数３００２が０より大きいことを通知された場合、トークン量保持部７０１に蓄積されるトークン量（トークン量）とトークン判定量保持部７０９が保持するトークン量（一定量）の大小を判定し、（トークン量）≧（一定量）であれば出力スケジューラ６０５にフレームの送信要求を出す。
【００６８】
トークン判定量保持部７０９は、トークン量判定部７０８が出力スケジューラ６０５へ送信要求を行うか否かの基準となるトークン量（一定量）を保持しており、この一定量は、設定レジスタ３１２により設定される。
【００６９】
以下に、帯域制御部１６０３が実行する帯域制御処理（Ｓ１９５０）について説明する。
【００７０】
図１１は、本発明の第１の実施形態の帯域制御部１６０３が実行する帯域制御処理を示すフローチャートである。
【００７１】
トークン加算部７０３は、一定タイミングでトークン加算信号が入力されると処理を開始する。（Ｓ１９００）、トークン加算部７０３は、トークン加算量保持部７０４が保持する一定トークン量を、トークン量保持部７０１に加算する（Ｓ１９０１）。この一定タイミングで一定量加算するトークンが各フローの契約帯域に相当する。一定量は、ＮＩＦ管理部１３１１が制御する設定レジスタ３１２から設定される。
【００７２】
次に、蓄積トークン量制御部７０５は、バッファ管理レジスタ１３０９から格納フレーム数３００２を取得し、取得した格納フレーム数３００２が０より大きいか否かを判定する（Ｓ１９０２）。
【００７３】
Ｓ１９０２において、格納フレーム数３００２が０より大きい場合、蓄積トークン量制御部７０５は、トークン量保持部７０１が保持するトークン量が、最大蓄積トークン量保持部７０６が保持するバケツの深さより大きいか否かを判定する（Ｓ１９０３）。
Ｓ１９０３において、トークン量保持部７０１が保持するトークン量がバケツの深さより大きくない場合、Ｓ１９０７の処理に進む。一方、トークン量がバケツの深さより大きい場合は、蓄積トークン量制御部７０５は、トークン量保持部７０１が保持するトークン量をバケツの深さの値に設定し（Ｓ１９０４）、Ｓ１９０７の処理に進む。バケツの深さは、ＮＩＦ管理部１３１１から設定されるものである。ここで、Ｓ１９０４において、トークン量をバケツの深さの値に設定することにより、バケツの深さに相当する蓄積フレーム数以上のバースト送信を発生させない。
【００７４】
次に、トークン量判定部７０８は、トークン量保持部７０１が保持するトークン量が、トークン判定量保持部７０９が保持する一定量以上であるか否かを判定する（Ｓ１９０７）。
【００７５】
Ｓ１９０７において、トークン量保持部７０１が保持するトークン量が一定量以上である場合、トークン量判定部７０８は出力スケジューラ６０５に送信要求を送信し（Ｓ１９０８）、Ｓ１９１０の処理に進む。ここで、一定量以上である場合は、フレームを送信するトークン量（送信権）を保持しているため、トークン量判定部７０８は、トークン量を監視しているフローのフレーム読み出しが可能であると判断し、出力スケジューラ６０５に送信要求を送信する。
【００７６】
一方、Ｓ１９０２において、格納フレーム数３００２が０である場合、蓄積トークン量制御部７０５は、トークン量保持部７０１が保持するトークン量が、トークン判定量保持部７０９が保持する一定量より大きいか否かを判定する（Ｓ１９０５）。
Ｓ１９０５において、トークン量が一定量より大きい場合、蓄積トークン量制御部７０５は、トークン量保持部７０１が保持するトークン量を一定量に設定し（Ｓ１９０６）、Ｓ１９１０の処理に進む。第１の実施形態においては、この格納フレーム数３００２が０である場合にトークン量を一定量に設定することによって、送信するフレームが無い場合にトークン加算は一定量までとなり、フレームが断続的に到着した場合でも、フレームの送信間隔を平滑化し、契約帯域を超過したフレームの送信を抑制する。
【００７７】
また、Ｓ１９０５において、トークン量が一定量以下の場合、Ｓ１９１０の処理に進む。
【００７８】
また、Ｓ１９０７において、トークン量が一定量以上でない場合は、Ｓ１９１０の処理に進む。
【００７９】
トークン減算部７０２は、バッファ読出し処理部１６０２からの読出通知があるか否かを判定する（Ｓ１９１０）。
【００８０】
Ｓ１９１０において、読出通知がない場合、処理を終了する（Ｓ１９１２）。一方、読出通知がある場合、トークン減算部７０２は、バッファ読出し処理部１６０２からの読出フレーム長分のトークン量を、トークン量保持部７０１から減算し（Ｓ１９１１）、処理を終了する（Ｓ１９１２）。
【００８１】
尚、図１０及び図１１では、格納フレーム数３００２が０であるか否かによって、トークンの加算上限値を変更するとしたが、格納フレーム数がある一定数を超えた場合にトークンの加算上限値を変更することとしてもよい。
【００８２】
図１２は、図１１で説明した本発明の第１の実施形態の帯域制御部１６０３が実行する帯域制御処理による、トークンバケツのトークン量の変化及びフレームの制御状態を示す説明図である。
【００８３】
本発明の帯域制御部では、フロー毎に設定された契約帯域に対応する速度でトークンを加算する。トークンが一定量になるとフレーム送信が可能であり、フレームを送信するとフレーム長分のトークンを減算する（Ｔ２１１）。これにより、フレーム到着タイミングに対して、理想送信タイミングを決定する。図２では、簡単化のため、フレームが固定長である場合を示しており、このため理想送信タイミングは一定となる。理想タイミングとは、他フローの影響を受けずに契約帯域で送信する場合のタイミングである。
【００８４】
フレームがフロー制御部に到着すると、バッファ書き込み処理Ｓ１７５０を実行し、バッファ管理レジスタ１３０９の格納フレーム数を１加算して、フレームを出力フレームバッファ３１０に格納する。フレームを送信する際（実送信）、バッファ読み出し処理Ｓ１８５０を実行し、バッファ管理レジスタ１３０９の格納フレーム数を１減算して、フレームを出力フレームバッファ３１０から読出す。
【００８５】
他フローと出力競合が発生した場合、すなわち、図１１のＳ１９１０で読み出し通知がない場合、該フローのフレーム送信を理想タイミングで実現できず、出力スケジューラからの読出通知を受信するまで該フローのフレームの送信を待合わせる必要がある。そのため、本発明の帯域制御部は、バッファ管理レジスタ１３０９から取得する格納フレーム数が１以上の場合はバケツの深さまでトークンを加算可能とする。これにより、他ユーザフローのフレーム送信後、他フローのフレーム送信の間に蓄積したトークンに応じて待合わせたフレームを連続送信することができ、契約帯域分のフレームを送信可能とする。
【００８６】
この様子を図１２を用いて説明する。Ｔ２１２では、トークンは一定量に達しているが出力スケジューラからの読出通知を受領していないため、フレームを読み出すことが出来ない状態である。図１１のＳ１９０２、１９０３、１９０７、Ｓ１９０８、Ｓ１９０８、Ｓ１９１０、Ｓ１９１２の判断となる場合である。Ｓ１９０３において、トークン量よりもバケツの深さが大きいためトークン量をバケツの深さに設定するなどのトークン量の制限は行わない。この場合、Ｔ２１２のタイミングで実送信２０６は実行されていない。これは、他ユーザフロー送信２０７で示す通り、他ユーザフローのフレームを読み出しているためである。Ｔ２１２の後、出力スケジューラから読出通知を受領するＴ２１３までトークン量がバケツの深さより大きくならない限りトークンを蓄積する（Ｓ１９０３）。Ｔ２１３で出力スケジューラから読出通知を受領すると、一定量のトークンがバケツに保持されているためフレームを読み出す。さらにＴ２１４で出力スケジューラから読出通知を受領すると、このタイミングでも一定量のトークンが蓄積されているためフレームを読み出す。これはＴ２１２からＴ２１３の間もトークンを蓄積していたためである。これにより、Ｔ２１４の実送信２０６に示すように、Ｔ２１２で待ち合わせた帯域分をＴ２１４で読み出すことができる。
【００８７】
一方、格納フレーム数が０である場合は、トークン加算は一定量までとする。フレームが断続的に到着した場合、瞬間的に契約帯域を超過したフレームが到着するため、トークン加算を一定量までとすることにより、フレームが断続的に到着した場合でも、フレームの送信間隔を平滑化し、契約帯域を超過したフレームの送信を抑制する。この様子を図１２を用いて説明する。Ｔ２１５から、トークンが一定値に達するＴ２１６に至るまでは一定量のトークンが加算される。しかしながら、Ｔ２１６においては、格納フレーム数は０であり（Ｓ１９０２からＳ１９０５）、Ｔ２１７でフレームを受信し格納フレーム数が１となるまでは、Ｓ１９０５の判定においてトークンが一定量より大きくなるため、Ｓ１９０６にて、トークンが一定値に設定される。従って、Ｔ２１８のタイミングでフレームを受信しても、畜積されたトークン量は一定量より少ないためＴ２１９のタイミングまでフレームは送信されず、契約帯域を超過したフレームの送信を抑制することができる。
【００８８】
以上により、図１のユーザ装置103-1から送信された図２Ａに示すフローは、帯域制御装置による制御によって、図２Ｂに示す通り、フレームの送信間隔を平滑化され、契約帯域を超過したフレームの送信は抑制される。
従って、第１の実施形態によれば、帯域制御装置は、収容する複数ユーザフローに対して契約帯域を超過したフレームを通信キャリア網へ送信することを抑制し、出力競合が発生する場合でも各ユーザフローの契約帯域分のフレームを送信することができる。
【００８９】
＜実施形態２＞
以下、本発明の第２の実施形態について図１３から図１９を用いて説明する。
【００９０】
第１の実施形態では、帯域制御部１６０３は、バッファ管理レジスタ１３０９の格納フレーム数３００２が０である場合に、トークンが一定量より大きければトークンを一定量に設定した。第２の実施形態では、帯域制御部６０３は、フレーム有フラグが１であり、かつ、トークンが一定量以上である場合に、バッファ書込み処理部６０１からのフレーム初到着通知があればトークンを一定量に設定する。
【００９１】
図１３は、本発明の第２の実施形態の帯域制御装置の構成を示すブロック図である。
【００９２】
第２の実施形態の帯域制御装置３は、図３に示す第１の実施形態の帯域制御装置１０１と、バッファ管理レジスタ１３０９を含まず、バッファ管理テーブル３０９を含む点で、出力フレームバッファ制御部３０８、及び、ＮＩＦ管理部３１１の処理が異なる。
【００９３】
出力フレームバッファ制御部３０８は、出力フレームをフロー毎の出力フレームバッァ３１０に蓄積する。出力フレームバッファ制御部３０８は、格納された出力フレームをバッファ管理テーブル３０９に設定されたフロー毎の情報を用いてシェーピングしながら出力フレームバッファ３１０から読出し、入出力回線インタフェース３０１に送出する。
ＮＩＦ管理部３１１は、バッファ管理テーブル３０９及び設定レジスタ３１２を制御する。
【００９４】
図１４は、本発明の第２の実施形態のバッファ管理テーブルを示す説明図である。
【００９５】
バッファ管理テーブル３０９は、フローＩＤ：１００１を検索キーとして、バッファサイズ：１００２、格納フレーム数：１００３、格納バイト数：１００４、ライトポインタ１００５、及び、リードポインタ１００６を検索する。ここで、バッファサイズ１００２は、当該フローの運用するバッファサイズを示し、格納フレーム数１００３は、当該フローのバッファに格納されているフレーム数を示し、格納バイト数１００４は、当該フローのバッファに格納されているバイト数を示し、ライトポインタ１００５は、当該フローのバッファのライト開始アドレスを示し、リードポインタ１００６は、当該フローのバッファのリード開始アドレスを示す。
【００９６】
図１５は、本発明の第２の実施形態の出力フレームバッファ制御部の構成を示すブロック図である。
【００９７】
出力フレームバッファ制御部３０８は、フロー制御部６０４、及び、出力スケジューラ６０５を備える。
【００９８】
また、フロー制御部６０４は、バッファ書込み処理部６０１、バッファ読出し処理部６０２、帯域制御部６０３、及び、出力フレームバッファ３１０から構成される。
【００９９】
バッファ書込み処理部６０１は、出力ヘッダ処理部３０７からのフレームを受信すると、後述するバッファ書込み処理Ｓ７５０を実施する。バッファ書込み処理部６０１は、フレームを受信すると、フローを識別し、該当するフレームであった場合、フレームを出力フレームバッファ３１０に格納し、バッファ管理テーブル３０９を更新し、フレーム有フラグ、フレーム初到着を帯域制御部６０３に通知する。
【０１００】
帯域制御部６０３は、後述する帯域制御処理Ｓ９５０を実施し、送信要求を出力スケジューラ６０５に送信する。
【０１０１】
出力スケジューラ６０５は、各フロー制御部（６０４−１〜Ｎ）の帯域制御部６０３から送信要求を受信すると、読出すフレームをスケジューリングする。出力スケジューラ６０５は、送信要求を各フロー制御部（６０４−１〜Ｎ）のバッファ読出し処理部６０２に送信し、バッファ読出し処理部６０２から受信したフレームを入出力回線インタフェース３０１に送出する。
【０１０２】
バッファ読出し処理部６０２は、出力スケジューラ６０５からフレーム送信要求を受信すると、後述するバッファ読出し処理Ｓ８５０を実施する。バッファ読出し処理部６０２は、出力フレームバッファ３１０から読出したフレームを出力スケジューラ６０５に送信し、バッファ管理テーブル３０９を更新し、読出通知、及び、読出フレーム長通知を帯域制御部６０３に送信し、フレーム有フラグを帯域制御部６０３に通知する。
【０１０３】
以下に、バッファ書込み処理部６０１が実行するバッファ書込み処理（Ｓ７５０）について説明する。
【０１０４】
図１６は、本発明の第２の実施形態のバッファ書込み処理部が実行するバッファ書込み処理を示すフローチャートである。
【０１０５】
バッファ書込み処理部６０１は、出力ヘッダ処理部３０７からフレームを受信する（Ｓ７００）と、装置内ヘッダ４からフローＩＤ４０２、及び、フレーム長４０３を取得する（Ｓ７０１）。
【０１０６】
次に、バッファ書込み処理部６０１は、取得したフローＩＤ４０２が設定レジスタ３１２から設定されたフローＩＤと同一であるか否かを判定する（Ｓ７０２）。
【０１０７】
Ｓ７０２において、取得したフローＩＤ４０２が設定されたフローＩＤと同一である場合、取得したフローＩＤ４０２を用いてバッファ管理テーブル３０９を検索し、バッファサイズ１００２、ライトポインタ１００５、格納フレーム数１００３、及び、格納バイト数１００４を取得する（Ｓ７０３）。
【０１０８】
次に、バッファ書込み処理部６０１は、取得した格納バイト数１００４とフレーム長４０３を足し合わせた値と、バッファサイズ１００２を比較する（Ｓ７０４）。
【０１０９】
Ｓ７０４において、取得した格納バイト数１００４とフレーム長４０３を足し合わせた値がバッファサイズ１００２以下である場合、ライトポインタ１００５、格納フレーム数１００３、及び、格納バイト数１００４を更新し、出力フレームバッファ３１０にフレームを送出し、前記各更新値をバッファ管理テーブル３０９に格納し（Ｓ７０５）、処理を終了する（Ｓ７１０）。
【０１１０】
一方、バッファ書込み処理部６０１は、Ｓ７０５と同時に、帯域制御部６０３にフレーム有フラグを１として通知する（Ｓ７０６）。
バッファ書込み処理部６０１は、バッファ管理テーブル３０９から取得した格納フレーム数１００３が０であるか否かを判定する（Ｓ７０７）。
【０１１１】
Ｓ７０７において、格納フレーム数１００３が０である場合、帯域制御部６０３にフレーム初到着を通知し（Ｓ７０８）、処理を終了する（Ｓ７１０）。
【０１１２】
一方、格納フレーム数１００３が０でない場合、処理を終了する（Ｓ７１０）。
【０１１３】
また、Ｓ７０４において、取得した格納バイト数１００４とフレーム長４０３を足し合わせた値がバッファサイズ１００２より大きい場合、バッファがオーバーフローすることを示しており、フレームを廃棄し（Ｓ７０９）、処理を終了する（Ｓ７１０）。
【０１１４】
また、Ｓ７０２において、取得したフローＩＤ４０２が設定されたフローＩＤと同一でない場合、処理対象外フローのフレームを示しており、フレームを廃棄し（Ｓ７０９）、処理を終了する（Ｓ７１０）。
【０１１５】
次に、バッファ読出し処理部６０２が実行するバッファ読出し処理（Ｓ８５０）について説明する。
【０１１６】
図１７は、本発明の第２の実施形態のバッファ読出し処理部が実行するバッファ読出し処理を示すフローチャートである。
【０１１７】
バッファ読出し処理部６０２は、出力スケジューラ６０５からフレーム送信要求を受信する（Ｓ８００）と、設定レジスタ３１２から設定されたフローＩＤを用いてバッファ管理テーブル３０９を検索し、リードポインタ１００６、格納フレーム数１００３、及び、格納バイト数１００４を取得する（Ｓ８０１）。
【０１１８】
次に、リードポインタ１００６、格納フレーム数１００３、及び、格納バイト数１００４を更新し、出力フレームバッファ３１０から出力スケジューラ６０５へフレームを送信し、前記各更新値をバッファ管理テーブル３０９に格納し（Ｓ８０２）、処理を終了する（Ｓ８０６）。
【０１１９】
一方、バッファ読出し処理部６０２は、Ｓ８０２と同時に、帯域制御部６０３に読出通知を送信し、読出フレーム長を通知する（Ｓ８０３）。
【０１２０】
バッファ読出し処理部６０２は、バッファ管理テーブル３０９から取得した格納フレーム数１００３が１より大きいか否かを判定する（Ｓ８０４）。
【０１２１】
Ｓ８０４において、格納フレーム数１００３が１より大きい場合、処理を終了する（Ｓ８０６）。
【０１２２】
一方、Ｓ８０４において、格納フレーム数１００３が１より大きくない場合、帯域制御部６０３にフレーム有フラグを０として通知し（Ｓ８０５）、処理を終了する（Ｓ８０６）。
【０１２３】
図１８は、本発明の第２の実施形態の帯域制御部の構成を示すブロック図である。
【０１２４】
第２の実施形態の帯域制御部６０３は、図１０に示す第１の実施形態の帯域制御部１６０３と比較し、トークン量保持部１７０１、蓄積トークン量制御部１７０５、及び、トークン量判定部１７０８の処理が異なる。
【０１２５】
トークン量保持部１７０１は、トークンバケツアルゴリズムに用いられるパラメータ（トークンバケツに蓄積されるトークン量）を保持する。トークン量保持部１７０１に蓄積されるトークン量は、送信フレーム長（読出フレーム長）に基づいて減算され、一定時間に一定量が加算される。トークン量保持部１７０１が加算（蓄積）可能なトークン量は、蓄積トークン量制御部１７０５により制御される。
【０１２６】
蓄積トークン量制御部１７０５は、最大蓄積トークン量保持部７０６に設定された値を、トークン量保持部１７０１を制御する値とする。ただし、フレーム有フラグ＝‘１’かつフレーム初到着通知がある場合は、トークン判定量保持部７０９に設定された値を、蓄積トークン量制御部１７０５がトークン量保持部１７０１を制御する値に設定する。
トークン量判定部１７０８は、バッファ書込み処理部６０１からのフレーム有フラグ＝‘１’の場合、トークン量保持部１７０１に蓄積されるトークン量（トークン量）とトークン判定量保持部７０９が保持するトークン量（一定量）の大小を判定し、（トークン量）≧（一定量）であれば出力スケジューラ６０５にフレームの送信要求を出す。 以下に、帯域制御部６０３が実行する帯域制御処理（Ｓ９５０）について説明する。
【０１２７】
図１９は、本発明の第２の実施形態の帯域制御部が実行する帯域制御処理を示すフローチャートである。
【０１２８】
トークン加算部７０３は、一定タイミングでトークン加算信号が入力されると処理を開始し（Ｓ９００）、トークン加算量保持部７０４が保持する一定トークン量を、トークン量保持部１７０１に加算する（Ｓ９０１）。
【０１２９】
次に、トークン量保持部１７０１が保持するトークン量が、最大蓄積トークン量保持部７０６が保持するバケツの深さより大きいか否かを判定する（Ｓ９０２）。Ｓ９０２において、トークン量保持部１７０１が保持するトークン量がバケツの深さより大きくない場合、Ｓ９０４の処理に進む。一方、トークン量がバケツの深さより大きい場合は、蓄積トークン量制御部１７０５は、トークン量保持部１７０１が保持するトークンをバケツの深さの値に設定し（Ｓ９０３）、Ｓ９０４の処理に進む。
【０１３０】
トークン量判定部１７０８は、バッファ書込み処理部６０１からのフレーム有フラグが‘１’であり、かつ、トークン量保持部１７０１が保持するトークン量が、トークン判定量保持部７０９が保持する一定量以上であるか否かを判定する（Ｓ９０４）。
【０１３１】
Ｓ９０４において、フレーム有フラグが‘１’であり、かつ、トークン量保持部１７０１が保持するトークンが一定量以上である場合、トークン量判定部１７０８は出力スケジューラ６０５に送信要求を送信する（Ｓ９０５）。
【０１３２】
次に、蓄積トークン量制御部１７０５は、バッファ書込み処理部６０１からのフレーム初到着通知があるか否かを判定する（Ｓ９０６）。
【０１３３】
Ｓ９０６において、フレーム初到着通知がない場合、Ｓ９０９の処理に進む。また、フレーム初到着通知がある場合は、蓄積トークン量制御部１７０５は、トークン量保持部１７０１が保持するトークン量を一定量に設定し（Ｓ９０７）、Ｓ９０９の処理に進む。第２の実施形態においては、このフレーム初到着通知がある場合にトークンを一定量に設定することによって、送信するフレームが無い場合にトークン加算は一定量までとすることと同じになり、フレームが断続的に到着した場合でも、フレームの送信間隔を平滑化し、契約帯域を超過したフレームの送信を抑制する。
【０１３４】
一方、Ｓ９０４において、フレーム有フラグが１であり、かつ、トークン量保持部１７０１が保持するトークンが一定量以上でない場合は、Ｓ９０９の処理に進む。
【０１３５】
次に、トークン減算部７０２は、バッファ読出し処理部６０２からの読出通知があるか否かを判定する（Ｓ９０９）。
【０１３６】
Ｓ９０９において、読出通知がない場合、処理を終了する（Ｓ９１１）。一方、読出通知がある場合、トークン減算部７０２は、バッファ読出し処理部６０２からの読出フレーム長分のトークン量を、トークン量保持部１７０１から減算し（Ｓ９１０）、処理を終了する（Ｓ９１１）。
【０１３７】
尚、第２の実施形態の帯域制御処理による、トークンバケツのトークン量の変化及びフレームの制御状態は実施形態１で説明した図１２と同様であるが、Ｔ２１６からＴ２１７に至るまでのトークン量の変化が異なる。
【０１３８】
第２の実施形態の帯域制御部６０３は、バケツの深さまでトークンを加算可能とする。これにより、Ｔ２１０からＴ２１５に至るまでのトークン量の変化は実施形態１と同じであり、他ユーザフローのフレーム送信後、他フローのフレーム送信の間に蓄積したトークンに応じて待合わせたフレームを連続送信することができ、契約帯域分のフレームを送信可能とする。
【０１３９】
ただし、フレーム有フラグ＝‘１’であり、かつフレーム初到着通知がある場合は、トークン加算を一定量までとする。トークン加算を一定量までとすることにより、実施形態１と同様に、フレームが断続的に到着した場合でも、フレームの送信間隔を平滑化し、契約帯域を超過したフレームの送信を抑制する。この様子を図１２を用いて説明する。
【０１４０】
Ｔ２１５から、トークンが一定値に達するＴ２１６に至るまでは一定トークンが加算される。また、Ｔ２１６からＴ２１７に至るまでも、バケツの深さを越えない範囲で、一定トークンが加算される。Ｔ２１７においては、トークン量が一定量以上かつフレーム有フラグ＝‘１’であり、かつフレーム初到着通知があるため（Ｓ９０４からＳ９０６）、Ｓ９０７にて、トークンが一定値に設定される。従って、実施形態１と同様に、Ｔ２１８のタイミングでフレームを受信しても、畜積されたトークン量は一定量より少ないためＴ２１９のタイミングまでフレームは送信されず、契約帯域を超過したフレームの送信を抑制することができる。
【０１４１】
以上説明したように、第２の実施形態によれば、第１の実施形態の効果と同様に、帯域制御装置は、収容する複数ユーザフローに対して契約帯域を超過したフレームを通信キャリア網へ送信することを抑制し、出力競合が発生する場合でも各ユーザフローの契約帯域分のフレームを送信することができる。
【０１４２】
＜実施形態３＞
以下、本発明の第３の実施形態について図２０から図２５を用いて説明する。
【０１４３】
第１及び第２の実施形態では、トークンの加算値が一定量になるとフレーム送信が可能であるとした。第３の実施形態では、送信するフレーム長分のトークンが加算されるとフレーム送信が可能であるとする。
【０１４４】
図２０は、本発明の第３の実施形態の帯域制御装置の構成を示すブロック図である。
【０１４５】
第３の実施形態の帯域制御装置２３は、図３に示す第１の実施形態の帯域制御装置１０１と、出力フレームバッファ制御部２３０８の処理が異なる。
【０１４６】
図２１は、本発明の第３の実施形態の出力フレームバッファ制御部の構成を示すブロック図である。
【０１４７】
出力フレームバッファ制御部２３０８は、フロー制御部２６０４、及び、出力スケジューラ６０５を備える。
【０１４８】
また、フロー制御部２６０４は、バッファ書込み処理部２６０１、バッファ読出し処理部２６０２、帯域制御部２６０３、バッファ管理レジスタ１３０９、及び、出力フレームバッファ３１０から構成される。
【０１４９】
バッファ書込み処理部２６０１は、出力ヘッダ処理部３０７からのフレームを受信すると、後述するバッファ書込み処理Ｓ２７５０を実施する。バッファ書込み処理部２６０１は、フレームを受信すると、フローを識別し、該当するフレームであった場合、フレームを出力フレームバッファ３１０に格納し、バッファ管理レジスタ１３０９を更新する。
【０１５０】
帯域制御部２６０３は、後述する帯域制御処理Ｓ２９５０を実施し、送信要求を出力スケジューラ６０５に送信する。
【０１５１】
書込フレーム長格納キュー２６０９は、後述するバッファ書込み処理Ｓ２７５０において、バッファ書込み処理部２６０１から通知される書込フレーム長の情報を格納する。
【０１５２】
出力スケジューラ６０５は、各フロー制御部（２６０４−１〜Ｎ）の帯域制御部２６０３から送信要求を受信すると、読出すフレームをスケジューリングする。出力スケジューラ６０５は、送信要求を各フロー制御部（２６０４−１〜Ｎ）のバッファ読出し処理部２６０２に送信し、バッファ読出し処理部２６０２から受信したフレームを入出力回線インタフェース３０１に送出する。
【０１５３】
バッファ読出し処理部２６０２は、第１の実施形態のバッファ読出し処理部１６０２と同様であり、出力スケジューラ６０５からフレーム送信要求を受信すると、前述のバッファ読出し処理Ｓ１８５０を実施する。バッファ読出し処理部２６０２は、出力フレームバッファ３１０から読出したフレームを出力スケジューラ６０５に送信し、バッファ管理レジスタ１３０９を更新し、読出通知、及び、読出フレーム長通知を帯域制御部２６０３に送信する。
【０１５４】
以下に、バッファ書込み処理部２６０１が実行するバッファ書込み処理（Ｓ２７５０）について説明する。
【０１５５】
図２２は、本発明の第３の実施形態のバッファ書込み処理部が実行するバッファ書込み処理を示すフローチャートである。
【０１５６】
バッファ書込み処理部２６０１は、出力ヘッダ処理部３０７からフレームを受信する（Ｓ２７００）と、装置内ヘッダ４からフローＩＤ４０２、及び、フレーム長４０３を取得する（Ｓ２７０１）。
【０１５７】
次に、バッファ書込み処理部２６０１は、取得したフローＩＤ４０２が設定レジスタ３１２から設定されたフローＩＤと同一であるか否かを判定する（Ｓ２７０２）。
【０１５８】
Ｓ２７０２において、取得したフローＩＤ４０２が設定されたフローＩＤと同一である場合、バッファ管理レジスタ１３０９から、バッファサイズ３００１、ライトポインタ３００４、格納フレーム数３００２、及び、格納バイト数３００３を取得する（Ｓ２７０３）。
【０１５９】
次に、バッファ書込み処理部２６０１は、取得した格納バイト数３００３とフレーム長４０３を足し合わせた値と、バッファサイズ３００１を比較する（Ｓ２７０４）。
【０１６０】
Ｓ２７０４において、取得した格納バイト数３００３とフレーム長４０３を足し合わせた値がバッファサイズ３００３以下である場合、ライトポインタ３００４、格納フレーム数３００２、及び、格納バイト数３００３を更新し、出力フレームバッファ３１０にフレームを送出し、前記各更新値をバッファ管理レジスタ１３０９に設定し（Ｓ２７０５）、処理を終了する（Ｓ２７１０）。
【０１６１】
一方、バッファ書込み処理部２６０１は、Ｓ２７０５と同時に、帯域制御部２６０３に書込フレーム長を通知する（Ｓ２７０６）。
【０１６２】
バッファ書込み処理部２６０１は、バッファ管理レジスタ１３０９から取得した格納フレーム数３００２が０であるか否かを判定する（Ｓ２７０７）。
【０１６３】
Ｓ２７０７において、格納フレーム数３００２が０である場合、帯域制御部２６０３にフレーム初到着を通知し（Ｓ２７０８）、処理を終了する（Ｓ２７１０）。
【０１６４】
一方、格納フレーム数３００２が０でない場合、処理を終了する（Ｓ２７１０）。
【０１６５】
また、Ｓ２７０２において、取得したフローＩＤ４０２が設定されたフローＩＤと同一でない場合、処理対象外フローのフレームを示しており、フレームを廃棄し（Ｓ２７０９）、処理を終了する（Ｓ２７１０）。
【０１６６】
また、Ｓ２７０４において、取得した格納バイト数３００３とフレーム長４０３を足し合わせた値がバッファサイズ３００３より大きい場合、バッファがオーバーフローすることを示しており、フレームを廃棄し（Ｓ２７０９）、処理を終了する（Ｓ２７１０）。
【０１６７】
バッファ読出し処理部２６０２が実行するバッファ読出し処理は、第１の実施形態のバッファ読出し処理部が実行するバッファ読出し処理（Ｓ１８５０）と同じである。
【０１６８】
図２３は、本発明の第３の実施形態の帯域制御部の構成を示すブロック図である。
【０１６９】
第３の実施形態の帯域制御部２６０３は、図１０に示す第１の実施形態の帯域制御部１６０３と比較し、トークン量保持部２７０１、蓄積トークン量制御部２７０５、及び、トークン量判定部２７０８の処理が異なる。また、トークン判定量保持部７０９を含まず、書込フレーム長格納キュー２６０９を所持する。
【０１７０】
トークン量保持部２７０１は、トークンバケツアルゴリズムに用いられるパラメータ（トークンバケツに蓄積されるトークン量）を保持する。トークン量保持部２７０１に蓄積されるトークン量は、送信フレーム長（読出フレーム長）に基づいて減算され、一定時間に一定量が加算される。トークン量保持部２７０１が加算（蓄積）可能なトークン量は、蓄積トークン量制御部２７０５により制御される。
【０１７１】
蓄積トークン量制御部２７０５は、最大蓄積トークン量保持部７０６に設定された値を、トークン量保持部２７０１を制御する値とする。ただし、フレーム初到着通知がある場合は、書込フレーム長格納キュー２６０９から取得したフレーム長の値を、蓄積トークン量制御部２７０５がトークン量保持部２７０１を制御する値に設定する。
【０１７２】
トークン量判定部２７０８は、フレーム有無判定部７０７より格納フレーム数３００２が０より大きいことを通知された場合、トークン量保持部２７０１に蓄積されるトークン量（トークン量）と蓄積トークン量制御部２７０５から通知されるフレーム長の大小を判定し、（トークン量）≧（フレーム長）であれば出力スケジューラ６０５にフレームの送信要求を出す。
【０１７３】
書込フレーム長格納キュー２６０９は、バッファ書込み処理部２６０１から通知される書込フレーム長の情報を格納する。また、蓄積トークン量制御部２７０５へ格納したフレーム長の情報を通知する。
【０１７４】
図２４は、本発明の第３の実施形態の帯域制御部が実行する帯域制御処理を示すフローチャートである。
【０１７５】
トークン加算部７０３は、一定タイミングでトークン加算信号が入力されると処理を開始し（Ｓ２９００）、トークン加算量保持部７０４が保持する一定トークン量を、トークン量保持部２７０１に加算する（Ｓ２９０１）。
【０１７６】
次に、トークン量保持部２７０１が保持するトークン量が、最大蓄積トークン量保持部７０６が保持するバケツの深さより大きいか否かを判定する（Ｓ２９０２）。
【０１７７】
Ｓ２９０２において、トークン量保持部２７０１が保持するトークンがバケツの深さより大きくない場合、Ｓ２９０４の処理に進む。一方、トークンがバケツの深さより大きい場合は、蓄積トークン量制御部２７０５は、トークン量保持部２７０１が保持するトークンをバケツの深さの値に設定し（Ｓ２９０３）、Ｓ２９０４の処理に進む。
【０１７８】
次に、書込フレーム長格納キュー２６０９は、バッファ書込み処理部２６０１から書込フレーム長の通知があるか否かを判定する（Ｓ２９０４）。
【０１７９】
Ｓ２９０４において、書込フレーム長の通知がない場合、Ｓ２９０６の処理に進む。一方、書込フレーム長の通知がある場合、書込フレーム長格納キュー２６０９は、通知された書込フレーム長を書込フレーム長格納キューへ格納し（Ｓ２９０５）、Ｓ２９０６の処理に進む。
【０１８０】
次に、蓄積トークン量制御部２７０５は、バッファ書込み処理部２６０１からのフレーム初到着通知があるか否か、あるいは、バッファ管理レジスタの格納フレーム数３００２が０であり、かつバッファ読出し処理部２６０２からの読出通知があるか否かを判定する（Ｓ２９０６）。
【０１８１】
Ｓ２９０６において、バッファ書込み処理部２６０１からのフレーム初到着通知がない場合、かつ、バッファ管理レジスタの格納フレーム数３００２が０であり、かつバッファ読出し処理部２６０２からの読出通知がない場合、Ｓ２９１１の処理に進む。
【０１８２】
一方、Ｓ２９０６において、バッファ書込み処理部２６０１からのフレーム初到着通知がある場合、あるいは、バッファ管理レジスタの格納フレーム数３００２が０であり、かつバッファ読出し処理部２６０２からの読出通知がある場合、蓄積トークン量制御部２７０５は、書込フレーム長格納キュー２６０９からフレーム長を取得し、トークン量保持部２７０１を制御する値（フレーム長）として設定する（Ｓ２９０７）。
【０１８３】
次に、蓄積トークン量制御部２７０５は、バッファ書込み処理部２６０１からのフレーム初到着通知であったか否かを判定する（Ｓ２９０８）。
【０１８４】
Ｓ２９０８において、フレーム初到着通知ではない場合、Ｓ２９１１の処理に進む。一方、フレーム初到着通知である場合、蓄積トークン量制御部２７０５は、トークン量保持部２７０１が保持するトークン量がフレーム長以上であるか否かを判定する（Ｓ２９０９）。
【０１８５】
Ｓ２９０９において、トークンがフレーム長以上でない場合、Ｓ２９１１の処理に進む。一方、トークンがフレーム長以上である場合、蓄積トークン量制御部２７０５は、トークン量保持部２７０１が保持するトークンをフレーム長分に設定し（Ｓ２９１０）、Ｓ２９１１の処理に進む。
【０１８６】
第３の実施形態においては、バッファ書込み処理部２６０１からのフレーム初到着通知ある場合、トークンが演算フレーム長以上であれば、トークンを演算フレーム長分に設定する。後述するＳ２９１４の処理において、フレームを読み出す際にフレーム長分のトークンを減算するため、蓄積されたトークンを全て使用することと同様になる。これにより、フレームが断続的に到着した場合でも、フレームの送信間隔を平滑化し、契約帯域を超過したフレームの送信を抑制する。
【０１８７】
次に、蓄積トークン量制御部２７０５は、バッファ管理レジスタの格納フレーム数３００２が０より大きく、かつトークン量保持部２７０１が保持するトークン量が、蓄積トークン量制御部２７０５から通知されるフレーム長以上であるか否かを判定する（Ｓ２９１１）。
【０１８８】
Ｓ２９１１において、バッファ管理レジスタの格納フレーム数３００２が０より大きく、かつトークン量保持部２７０１が保持するトークンがフレーム長以上である場合、蓄積トークン量制御部２７０５はスケジューラに送信要求を送出し（Ｓ２９１２）、Ｓ２９１３の処理に進む。一方、バッファ管理レジスタの格納フレーム数３００２が０より大きく、かつトークンがフレーム長以上でない場合、Ｓ２９１３の処理に進む。
【０１８９】
次に、トークン減算部７０２は、バッファ読出し処理部２６０２からの読出通知があるか否かを判定する（Ｓ２９１３）。
【０１９０】
Ｓ２９１３において、読出通知がない場合、処理を終了する（Ｓ２９１５）。一方、読出通知がある場合、トークン減算部７０２は、バッファ読出し処理部２６０２から通知される読出フレーム長分のトークン量を、トークン量保持部２７０１から減算し（Ｓ２９１４）、処理を終了する（Ｓ２９１５）。
【０１９１】
図２５は本発明の第３の実施形態の帯域制御部のトークンバケツのトークン量の変化とフレームの制御タイミングを示す説明図である。
【０１９２】
第３の実施形態の帯域制御部では、フロー毎に設定された契約帯域に対応する速度でトークンを加算する。送信するフレーム長分のトークンが加算されるとフレーム送信が可能であり、フレームを送信するとフレーム長分のトークンを減算する（Ｔ２２１１）。これにより、フレーム到着タイミングに対して、理想送信タイミングを決定する。図２５では、簡単化のため、フレームが固定長である場合を示しており、このため理想送信タイミングは一定となる。理想タイミングとは、他フローの影響を受けずに契約帯域で送信する場合のタイミングである。
【０１９３】
尚、第３の実施形態の帯域制御処理による、トークンバケツのトークン量の変化及びフレームの制御状態は、フレーム長が固定である場合は実施形態１で説明した図１２と同様であるが、Ｔ２２１６からＴ２２１７に至るまでのトークン量の変化が異なる。
【０１９４】
第３の実施形態の帯域制御部２６０３は、バケツの深さまでトークンを加算可能とする。これにより、Ｔ２２１０からＴ２２１５に至るまでのトークン量の変化は、実施形態１と同様であり、他ユーザフローのフレーム送信後、他フローのフレーム送信の間に蓄積したトークンに応じて待合わせたフレームを連続送信することができ、契約帯域分のフレームを送信可能とする。
【０１９５】
ただし、フレーム初到着通知がある場合は、トークン加算をフレーム長分までとする。トークン加算をフレーム長分までとすることにより、初到着したフレームを読み出す際にフレーム長分のトークンを減算するため、蓄積されたトークンを全て使用することと同様になる。これにより、実施形態１と同様に、フレームが断続的に到着した場合でも、フレームの送信間隔を平滑化し、契約帯域を超過したフレームの送信を抑制する。この様子を図２５を用いて説明する。
【０１９６】
Ｔ２２１５から、トークンが送信フレーム長に達するＴ２２１６に至るまでは一定トークンが加算される。また、Ｔ２２１６からＴ２２１７に至るまでも、バケツの深さを越えない範囲で、一定トークンが加算される。Ｔ２２１７においては、フレーム初到着通知があり、かつトークンがフレーム長分以上あるため（Ｓ２９０８からＳ２９０９）、Ｓ２９１０にて、トークンがフレーム長分に設定される。従って、実施形態１と同様に、Ｔ２２１８のタイミングでフレームを受信しても、畜積されたトークン量はフレーム長分より少ないためＴ２２１９のタイミングまでフレームは送信されず、契約帯域を超過したフレームの送信を抑制することができる。
【０１９７】
以上説明したように、第３の実施形態によれば、第１の実施形態の効果と同様に、帯域制御装置は、収容する複数ユーザフローに対して契約帯域を超過したフレームを通信キャリア網へ送信することを抑制し、出力競合が発生する場合でも各ユーザフローの契約帯域分のフレームを送信することができる。
【０１９８】
＜実施形態４＞
以下、本発明の第４の実施形態について図２６から図２８を用いて説明する。
【０１９９】
第１、第２及び第３の実施形態ではトークンバケツアルゴリズムを用いたが、第４の実施形態では、トークンを減算する方法であるリーキーバケツアルゴリズムを用いる。
【０２００】
第４の実施形態の帯域制御装置の構成は実施形態１で説明した図３と同じである。また、第４の実施形態の出力フレームバッファ制御部の構成も実施形態１で説明した図６と同じであるが、帯域制御部の構成は異なる。
【０２０１】
図２６は、本発明の第４の実施形態の帯域制御部の構成を示すブロック図である。
【０２０２】
帯域制御部４６０３は、トークン量保持部４７０１、トークン加算部７０２、トークン減算部４７０３、トークン減算量保持部４７０４、蓄積トークン量制御部４７０５、フレーム有無判定部４７０７、トークン量判定部４７０８、及びトークン判定量保持部４７０９を備える。
【０２０３】
トークン量保持部４７０１は、トークンバケツアルゴリズムに用いられるパラメータ（トークンバケツに蓄積されるトークン量）を保持する。トークン量保持部４７０１に蓄積されるトークン量は、送信フレーム長（読出フレーム長）に基づいて加算され、一定時間に一定量が減算される。トークン量保持部４７０１が保持するトークン量は、蓄積トークン量制御部４７０５により制御される。
【０２０４】
トークン加算部４７０２は、出力フレームバッファ３１０から読み出されたフレーム長に基づいて、トークン量保持部４７０１から、読出フレーム長に対応する量のトークンを加算する。
【０２０５】
トークン減算部４７０３は、一定タイミングで一定量のトークンを加算する。具体的には、トークン減算部４７０３は、トークン減算信号（例えば、クロック信号）が入力されると、トークン減算量保持部４７０４に保持された量のトークンを減算する。
【０２０６】
トークン減算量保持部４７０４は、定期的に減算されるトークン量を保持しており、設定レジスタ３１２により設定される。
【０２０７】
蓄積トークン量制御部４７０５は、バッファ管理レジスタ１３０９の格納フレーム数３００２に基づいて、トークン量保持部４７０１が保持するトークン量を制御する。本発明の第４の実施形態では、格納フレーム数が１以上の場合は０（最低値）、格納フレーム数が０の場合はトークン判定量保持部４７０９に設定された値を、蓄積トークン量制御部７０５がトークン量保持部４７０１を制御する値とする。
【０２０８】
フレーム有無判定部４７０７は、格納フレーム数３００２が０より大きいか否かを判定し、トークン量判定部４７０８に通知する。
【０２０９】
トークン量判定部４７０８は、フレーム有無判定部４７０７より格納フレーム数３００２が０より大きいことを通知された場合、トークン量保持部４７０１が保持するトークン量（トークン量）とトークン判定量保持部４７０９が保持するトークン量（一定量）の大小を判定し、（トークン量）≦（一定量）であれば出力スケジューラ６０５にフレームの送信要求を出す。
【０２１０】
トークン判定量保持部４７０９は、トークン量判定部７０８が出力スケジューラ６０５へ送信要求を行うか否かの基準となるトークン量（一定量）を保持しており、設定レジスタ３１２により設定される。
【０２１１】
以下に、帯域制御部４６０３が実行する帯域制御処理（Ｓ４９５０）について説明する。
【０２１２】
図２７は、本発明の第４の実施形態の帯域制御部が実行する帯域制御処理を示すフローチャートである。
【０２１３】
トークン減算部４７０３は、一定タイミングでトークン減算信号が入力されると処理を開始し（Ｓ４９００）、トークン減算量保持部４７０４が保持する一定トークン量を、トークン量保持部４７０１から減算する（Ｓ４９０１）。この一定タイミングで一定量減算するトークンが各フローの契約帯域に相当する。一定量は、ＮＩＦ管理部１３１１が制御する設定レジスタ３１２から設定される。
【０２１４】
次に、蓄積トークン量制御部４７０５は、バッファ管理レジスタ１３０９から格納フレーム数３００２を取得し、取得した格納フレーム数３００２が０より大きいか否かを判定する（Ｓ４９０２）。
【０２１５】
Ｓ４９０２において、格納フレーム数３００２が０より大きい場合、蓄積トークン量制御部４７０５は、トークン量保持部４７０１が保持するトークン量が０より小さいか否かを判定する（Ｓ４９０３）。
Ｓ４９０３において、０より小さくない場合、Ｓ４９０７の処理に進む。一方、トークン量が０より小さい場合は、蓄積トークン量制御部４７０５は、トークン量保持部４７０１が保持するトークン量を０に設定し（Ｓ４９０４）、Ｓ４９０７の処理に進む。
【０２１６】
次に、トークン量判定部４７０８は、トークン量保持部４７０１が保持するトークン量が、トークン判定量保持部７０９が保持する一定量以下であるか否かを判定する（Ｓ４９０７）。
【０２１７】
Ｓ４９０７において、トークン量保持部４７０１が保持するトークン量が一定量以下である場合、トークン量判定部４７０８は出力スケジューラ６０５に送信要求を送信し（Ｓ４９０８）、Ｓ４９１０の処理に進む。ここで、一定量以下である場合、トークン量判定部４７０８がトークン量を監視しているフローのフレーム読み出しが可能であると判断することにより、一定量から０まで減算されるトークン量に応じたフレームの連続送信が可能となる。
【０２１８】
一方、Ｓ４９０２において、格納フレーム数３００２が０である場合、蓄積トークン量制御部４７０５は、トークン量保持部４７０１が保持するトークン量が、トークン判定量保持部４７０９が保持する一定量より小さいか否かを判定する（Ｓ４９０５）。
Ｓ４９０５において、トークン量が一定量より小さい場合、蓄積トークン量制御部４７０５は、トークン量保持部４７０１が保持するトークン量を一定量に設定し（Ｓ４９０６）、Ｓ４９１０の処理に進む。第４の実施形態においては、この格納フレーム数３００２が０である場合にトークン量の減算を一定量までと設定することによって、フレームが断続的に到着した場合でも、フレームの送信間隔を平滑化し、契約帯域を超過したフレームの送信を抑制する。また、Ｓ４９０５において、トークン量が一定量以上の場合、Ｓ４９１０の処理に進む。
【０２１９】
また、Ｓ４９０７において、トークン量が一定量以下でない場合は、Ｓ４９１０の処理に進む。
【０２２０】
トークン加算部４７０２は、バッファ読出し処理部１６０２からの読出通知があるか否かを判定する（Ｓ４９１０）。
【０２２１】
Ｓ４９１０において、読出通知がない場合、処理を終了する（Ｓ４９１２）。一方、読出通知がある場合、トークン加算部４７０２は、バッファ読出し処理部１６０２からの読出フレーム長分のトークン量を、トークン量保持部４７０１に加算し（Ｓ４９１１）、処理を終了する（Ｓ４９１２）。
【０２２２】
尚、図２６及び図２７では、格納フレーム数３００２が０であるか否かによって、トークンの減算下限値を変更するとしたが、格納フレーム数がある一定数を超えた場合にトークンの減算下限値を変更することとしてもよい。
図２８は、図２７で説明した本発明の第４の実施形態の帯域制御部４６０３が実行する帯域制御処理による、トークンバケツのトークン量の変化及びフレームの制御状態を示す説明図である。
本発明の帯域制御部では、フロー毎に設定された契約帯域に対応する速度でトークンを減算する。トークンが一定量になるとフレーム送信が可能であり、フレームを送信するとフレーム長分のトークンを加算する（Ｔ４２１１）。これにより、フレーム到着タイミングに対して、理想送信タイミングを決定する。図２８では、簡単化のため、フレームが固定長である場合を示しており、このため理想送信タイミングは一定となる。理想タイミングとは、他フローの影響を受けずに契約帯域で送信する場合のタイミングである。
フレームがフロー制御部に到着すると、バッファ書き込み処理Ｓ１７５０を実行し、バッファ管理レジスタ１３０９の格納フレーム数を１加算して、フレームを出力フレームバッファ３１０に格納する。フレームを送信する際（実送信）、バッファ読み出し処理Ｓ１８５０を実行し、バッファ管理レジスタ１３０９の格納フレーム数を１減算して、フレームを出力フレームバッファ３１０から読出す。
他フローと出力競合が発生した場合、すなわち、図２７のＳ４９１０で読み出し通知がない場合、該フローのフレーム送信を理想タイミングで実現できず、出力スケジューラからの読出通知を受信するまで該フローのフレームの送信を待合わせる必要がある。そのため、本発明の帯域制御部は、バッファ管理レジスタ１３０９から取得する格納フレーム数が１以上の場合は、一定量を下回り０までトークンを減算可能とする。これにより、他ユーザフローのフレーム送信後、他フローのフレーム送信の間に減算したトークンに応じて待合わせたフレームを連続送信することができ、契約帯域分のフレームを送信可能とする。
この様子を図２８を用いて説明する。Ｔ４２１２では、トークンは一定量まで減算されているが出力スケジューラからの読出通知を受領していないため、フレームを読み出すことが出来ない状態である。図２７のＳ４９０２、４９０３、４９０７、Ｓ４９０８、Ｓ４９１０、Ｓ４９１２の判断となる場合である。Ｓ４９０３において、０よりもトークン量が大きいためトークン量を０に設定するなどのトークン量の設定は行わない。この場合、Ｔ４２１２のタイミングで実送信４２０６は実行されていない。これは、他ユーザフロー送信４２０７で示す通り、他ユーザフローのフレームを読み出しているためである。Ｔ４２１２の後、出力スケジューラから読出通知を受領するＴ４２１３までトークン量が０より小さくならない限りトークンを減算する（Ｓ４９０３）。Ｔ４２１３で出力スケジューラから読出通知を受領すると、一定量以下のトークンがバケツに保持されているためフレームを読み出す。さらにＴ４２１４で出力スケジューラから読出通知を受領すると、このタイミングでもトークンは一定量以下であるためフレームを読み出す。これはＴ４２１２からＴ４２１３の間もトークンを減算していたためである。これにより、Ｔ４２１４の実送信４２０６に示すように、Ｔ４２１２で待ち合わせた帯域分をＴ４２１４で読み出すことができる。
一方、格納フレーム数が０である場合は、トークン減算は一定量までとする。フレームが断続的に到着した場合、瞬間的に契約帯域を超過したフレームが到着するため、トークン減算を一定量までとすることにより、フレームが断続的に到着した場合でも、フレームの送信間隔を平滑化し、契約帯域を超過したフレームの送信を抑制する。
この様子を図２８を用いて説明する。Ｔ４２１５から、トークンが一定値に達するＴ４２１６に至るまでは一定量のトークンが減算される。しかしながら、Ｔ４２１６においては、格納フレーム数は０であり（Ｓ４９０２からＳ４９０５）、Ｔ４２１７でフレームを受信し格納フレーム数が１となるまでは、Ｓ４９０５の判定においてトークンが一定量より小さくなるため、Ｓ４９０６にて、トークンが一定値に設定される。従って、Ｔ４２１８のタイミングでフレームを受信しても、畜積されたトークン量は一定量より大きいためＴ４２１９のタイミングまでフレームは送信されず、契約帯域を超過したフレームの送信を抑制することができる。
【０２２３】
従って、第４の実施形態によれば、帯域制御装置は、収容する複数ユーザフローに対して契約帯域を超過したフレームを通信キャリア網へ送信することを抑制し、出力競合が発生する場合でも各ユーザフローの契約帯域分のフレームを送信することができる。
【０２２４】
また、第４の実施形態では、第１の実施形態のトークンバケツアルゴリズムを用いた場合に対するトークンの減算モデルを示したが、第２の実施形態のトークンバケツアルゴリズムを用いた場合に対するトークンの減算モデルとして、フレーム有フラグが１であり、かつ、トークンが一定量より小さい場合に、バッファ書込み処理部６０１からのフレーム初到着通知があればトークンを一定量に設定するとしてもよい。また、第３の実施形態のトークンバケツアルゴリズムを用いた場合に対するトークンの減算モデルとして、バケツの最大値から送信するフレーム長分のトークンが減算されるとフレーム送信が可能であるとし、トークンがバケツの最大値からフレーム長分以上に減算されている場合に、バッファ書込み処理部２６０１からのフレーム初到着通知がある場合は、トークンをバケツの最大値からフレーム長分減算された値に設定するとしてもよい。
【符号の説明】
【０２２５】
３ 帯域制御装置
４ 装置内ヘッダ
５ 通信フレーム
２３ 帯域制御装置
１０１ 帯域制御装置
３００ ネットワークインタフェースボード
３０１ 入出力回線インタフェース
３０２ 入力ヘッダ処理部
３０３ 入力フレームバッファ制御部
３０４ 入力フレームバッファ
３０５ ＳＷインタフェース
３０６ スイッチ部
３０７ 出力ヘッダ処理部
３０８ 出力フレームバッファ制御部
３０９ バッファ管理テーブル
３１０ 出力フレームバッファ
３１１ ＮＩＦ管理部
３１２ 設定レジスタ
３５０ 論理回路
４０１ 出力ネットワークインタフェースボード識別子
４０２ フローＩＤ
４０３ フレーム長
５０１ 宛先ＭＡＣアドレス
５０２ 送信元ＭＡＣアドレス
５０３ ＶＬＡＮヘッダ
５０４ イーサタイプ値
５０５ ペイロード
５０６ フレームチェックシーケンス
６０１ バッファ書込み処理部
６０２ バッファ読出し処理部
６０３ 帯域制御部
６０４ フロー制御部
６０５ 出力スケジューラ
７０１ トークン量保持部
７０２ トークン減算部
７０３ トークン加算部
７０４ トークン加算量保持部
７０５ 蓄積トークン量制御部
７０６ 最大蓄積トークン量保持部
７０７ フレーム有無判定部
７０８ トークン量判定部
７０９ トークン判定量保持部１００１ フローＩＤ
１００２ バッファサイズ
１００３ 格納フレーム数
１００４ 格納バイト数
１００５ ライトポインタ
１００６ リードポインタ
１３０８ 出力フレームバッファ制御部
１３０９ バッファ管理レジスタ
１３１１ ＮＩＦ管理部
１６０１ バッファ書込み処理部
１６０２ バッファ読出し処理部
１６０３ 帯域制御部
１６０４ フロー制御部
１７０１ トークン量保持部
１７０５ 蓄積トークン量制御部
１７０８ トークン量判定部２３０８ 出力フレームバッファ制御部
２６０１ バッファ書込み処理部
２６０２ バッファ読出し処理部
２６０３ 帯域制御部
２６０４ フロー制御部
２６０９ 書込フレーム長格納キュー
２７０１ トークン量保持部
２７０５ 蓄積トークン量制御部
２７０８ トークン量判定部
３００１ バッファサイズ
３００２ 格納フレーム数
３００３ 格納バイト数
３００４ ライトポインタ
３００５ リードポインタ
４６０３ 帯域制御部
４７０１ トークン量保持部
４７０２ トークン加算部
４７０３ トークン減算部
４７０４ トークン減算量保持部
４７０５ 蓄積トークン量制御部
４７０７ フレーム有無判定部
４７０８ トークン量判定部
４７０９ トークン判定量保持部
【特許請求の範囲】
【請求項１】
ネットワークに接続される通信装置であって、
フレームを受信する入力インタフェースと、
前記入力インタフェースで受信したフレームを保持する出力フレームバッファと、
前記入力インタフェースで受信したフレームの読み出し要求通知タイミングをフロー毎に制御する複数の帯域制御部と、
前記複数の帯域制御部から通知される各フローの前記フレーム読み出し要求に基づいて、前記フレームの読み出しタイミングを決定する出力スケジューラと、
前記出力スケジューラから通知されるタイミングで前記フレームを出力する出力インタフェースと、を備え、
前記帯域制御部は、
フロー毎に保持されるトークン値に基づいて該フローの読み出し要求を出力スケジューラに通知するかしないかを判定し、前記出力フレームバッファのフレームの蓄積量に基づいて、前記トークン値の加減算量を決定することを特徴とする通信装置。
【請求項２】
前記帯域制御部は、
前記フロー毎のトークン量を保持するトークン量保持部と、
前記フロー毎に周期的に一定量のトークンを前記トークン量保持部に加算するトークン加算部と、
前記トークン量保持部で保持されるトークン量に基づいて該フローの読み出し要求を出力スケジューラに通知するかしないかを判定するトークン量判定部と、
前記出力インタフェースから前記出力フレームバッファに保持されたフレームが読み出されると、前記トークン量保持部のトークンを減算するトークン減算部と、
前記出力フレームバッファのフレームの蓄積量に基づいて、前記トークン値の加算量を決定する蓄積トークン量制御部と、を備えることを特徴とする通信装置。
【請求項３】
請求項２に記載の通信装置であって、
前記トークン量判定部は、
前記フロー毎に設定される規定の値以上トークン量保持部にトークンが蓄積されている場合に、前記出力スケジューラに読み出し要求を通知することを特徴とする通信装置。
【請求項４】
請求項２に記載の通信装置であって、
前記蓄積トークン量制御部は、
前記出力フレームバッファにフレームが格納されているか否かによって、前記トークン量保持部に加算するトークン値の加算上限値を変更することを特徴とする通信装置。
【請求項５】
請求項２に記載の通信装置であって、
前記蓄積トークン量制御部は、
前記出力フレームバッファにフレームが格納されていない場合に前記一定量以上トークンを加算しないことを特徴とする通信装置。
【請求項６】
請求項２記載の通信装置であって、
前記蓄積トークン量制御部は、
前記出力フレームバッファにフレームが格納されていないときのトークン量の加算上限値を、前記出力フレームバッファにフレームが格納されているときのトークン量の加算上限値より小さい値に設定することを特徴とする通信装置。
【請求項７】
請求項２に記載の通信装置であって、
前記蓄積トークン量制御部は、
前記出力フレームバッファにフレームが格納されていないときに新たに出力フレームバッファにフレームを格納した場合に、前記トークンバケツのトークン値を、請求項３に記載の規定の値のトークン値に設定することを特徴とする通信装置。
【請求項８】
請求項２に記載の通信装置であって、
前記蓄積トークン量制御部は、
前記出力フレームバッファにフレームが格納されていないときに新たに出力フレームバッファにフレームを格納した場合に、前記新たに格納されたフレームのフレーム長に応じたトークンよりも多く前記トークンバケツで保持されるトークン値を減算することを特徴とする通信装置。
【請求項９】
請求項２に記載の通信装置であって、
前記トークン加算部は、
フローの契約帯域に応じて周期的に一定量のトークンを加算することを特徴とする通信装置。
【請求項１０】
請求項１に記載の通信装置であって、
前記フロー毎のトークン量を保持するトークン量保持部と、
前記フロー毎に周期的に一定量のトークンを前記トークン量保持部に加算するトークン加算部と、
次に読み出し要求を通知すべきフレームのフレーム長に応じたトークン値分以上トークンバケツにトークンを保持している場合に該フローの読み出し要求を出力スケジューラに通知するトークン量判定部と、
前記出力インタフェースから前記出力フレームバッファに保持されたフレームが読み出されると、前記トークン量保持部のトークンを減算するトークン減算部と、
前記出力フレームバッファのフレームの蓄積量に基づいて、前記トークン値の加算量を決定する蓄積トークン量制御部と、を備えることを特徴とする通信装置。
【請求項１１】
請求項８に記載の通信装置であって、
前記蓄積トークン量制御部は、
前記出力フレームバッファにフレームが格納されていないときに新たに出力フレームバッファにフレームを格納した場合に、前記トークンバケツのトークン値を、前記新たに格納されたフレームのフレーム長に応じたトークン値に設定することを特徴とする通信装置。
【請求項１２】
請求項８に記載の通信装置であって、
前記蓄積トークン量制御部は、
前記出力フレームバッファにフレームが格納されていないときに新たに出力フレームバッファにフレームを格納した場合に、前記新たに格納されたフレームのフレーム長に応じたトークンよりも多く前記トークンバケツで保持されるトークン値を減算することを特徴とする通信装置。
【請求項１３】
請求項１の通信装置であって、
前記帯域制御部は、
前記フロー毎のトークン量を保持するトークン量保持部と、
前記フロー毎に周期的に一定量のトークンを前記トークン量保持部から減算するトークン減算部と、
前記トークン量保持部で保持されるトークン量に基づいて該フローの読み出し要求を出力スケジューラに通知するかしないかを判定するトークン量判定部と、
前記出力インタフェースから前記出力フレームバッファに保持されたフレームが読み出されると、前記トークン量保持部のトークンを加算するトークン加算部と、
前記出力フレームバッファのフレームの蓄積量に基づいて、前記トークン値の減算量を決定する蓄積トークン量制御部と、を備えることを特徴とする通信装置。
【請求項１４】
請求項１１に記載の通信装置であって、
前記トークン量判定部は、
前記フロー毎に設定される規定の値以下トークン量保持部にトークンが蓄積されている場合に、前記出力スケジューラに読み出し要求を通知することを特徴とする通信装置。
【請求項１５】
請求項１１に記載の通信装置であって、
前記蓄積トークン量制御部は、
前記出力フレームバッファにフレームが格納されているか否かによって、前記トークン量保持部から減算するトークン値の減算下限値を変更することを特徴とする通信装置。
【請求項１６】
請求項１１に記載の通信装置であって、
前記蓄積トークン量制御部は、
前記出力フレームバッファにフレームが格納されていない場合に前記一定量よりトークンを減算しないことを特徴とする通信装置。
【請求項１７】
請求項１１記載の通信装置であって、
前記蓄積トークン量制御部は、
前記出力フレームバッファにフレームが格納されていないときのトークン量の減算下限値を、前記出力フレームバッファにフレームが格納されているときのトークン量の減算下限値より大きい値に設定することを特徴とする通信装置。
【請求項１８】
受信したフレームの送出タイミングを通信装置において制御する帯域制御方法であって、
受信する複数のフローをフロー毎に出力フレームバッファに格納するステップと、
前記フロー毎に保持されるトークン値に基づいて該フローの読み出し要求を出力スケジューラに通知するかしないかを判定するステップと、
前記出力フレームバッファのフレームの蓄積量に基づいて、前記トークン値の加減算量を決定するステップと、を含む帯域制御方法。
【請求項１９】
前記フロー毎のトークン量をトークン量保持部で保持するステップと、
前記フロー毎に周期的に一定のトークンを前記トークン量保持部に加算するステップと、
前記トークン保持部で保持されるトークン量に基づいて該フローの読み出し要求を出力スケジューラに通知するステップと、
前記フローが読み出されると前記トークン量保持部のトークンを減算するステップと、
前記出力フレームバッファのフレームの蓄積量に基づいて、前記トークン値の加減算量を決定するステップと、を有する請求項１６に記載の帯域制御方法。
【請求項２０】
前記出力フレームバッファにフレームが格納されているか否かによって、前記トークン量保持部に加算するトークン値の加算上限値を変更するステップを有する請求項１７に記載の帯域制御方法。
【請求項２１】
前記出力フレームバッファにフレームが格納されていない場合に前記一定量以上トークンを加算しないステップを有する請求項１７に記載の帯域制御方法。
【請求項２２】
前記出力フレームバッファにフレームが格納されていないときのトークン量の加算上限値を、前記出力フレームバッファにフレームが格納されているときのトークン量の加算上限値より小さい値に設定するステップを有する請求項１７に記載の帯域制御方法。
【請求項１】
ネットワークに接続される通信装置であって、
フレームを受信する入力インタフェースと、
前記入力インタフェースで受信したフレームを保持する出力フレームバッファと、
前記入力インタフェースで受信したフレームの読み出し要求通知タイミングをフロー毎に制御する複数の帯域制御部と、
前記複数の帯域制御部から通知される各フローの前記フレーム読み出し要求に基づいて、前記フレームの読み出しタイミングを決定する出力スケジューラと、
前記出力スケジューラから通知されるタイミングで前記フレームを出力する出力インタフェースと、を備え、
前記帯域制御部は、
フロー毎に保持されるトークン値に基づいて該フローの読み出し要求を出力スケジューラに通知するかしないかを判定し、前記出力フレームバッファのフレームの蓄積量に基づいて、前記トークン値の加減算量を決定することを特徴とする通信装置。
【請求項２】
前記帯域制御部は、
前記フロー毎のトークン量を保持するトークン量保持部と、
前記フロー毎に周期的に一定量のトークンを前記トークン量保持部に加算するトークン加算部と、
前記トークン量保持部で保持されるトークン量に基づいて該フローの読み出し要求を出力スケジューラに通知するかしないかを判定するトークン量判定部と、
前記出力インタフェースから前記出力フレームバッファに保持されたフレームが読み出されると、前記トークン量保持部のトークンを減算するトークン減算部と、
前記出力フレームバッファのフレームの蓄積量に基づいて、前記トークン値の加算量を決定する蓄積トークン量制御部と、を備えることを特徴とする通信装置。
【請求項３】
請求項２に記載の通信装置であって、
前記トークン量判定部は、
前記フロー毎に設定される規定の値以上トークン量保持部にトークンが蓄積されている場合に、前記出力スケジューラに読み出し要求を通知することを特徴とする通信装置。
【請求項４】
請求項２に記載の通信装置であって、
前記蓄積トークン量制御部は、
前記出力フレームバッファにフレームが格納されているか否かによって、前記トークン量保持部に加算するトークン値の加算上限値を変更することを特徴とする通信装置。
【請求項５】
請求項２に記載の通信装置であって、
前記蓄積トークン量制御部は、
前記出力フレームバッファにフレームが格納されていない場合に前記一定量以上トークンを加算しないことを特徴とする通信装置。
【請求項６】
請求項２記載の通信装置であって、
前記蓄積トークン量制御部は、
前記出力フレームバッファにフレームが格納されていないときのトークン量の加算上限値を、前記出力フレームバッファにフレームが格納されているときのトークン量の加算上限値より小さい値に設定することを特徴とする通信装置。
【請求項７】
請求項２に記載の通信装置であって、
前記蓄積トークン量制御部は、
前記出力フレームバッファにフレームが格納されていないときに新たに出力フレームバッファにフレームを格納した場合に、前記トークンバケツのトークン値を、請求項３に記載の規定の値のトークン値に設定することを特徴とする通信装置。
【請求項８】
請求項２に記載の通信装置であって、
前記蓄積トークン量制御部は、
前記出力フレームバッファにフレームが格納されていないときに新たに出力フレームバッファにフレームを格納した場合に、前記新たに格納されたフレームのフレーム長に応じたトークンよりも多く前記トークンバケツで保持されるトークン値を減算することを特徴とする通信装置。
【請求項９】
請求項２に記載の通信装置であって、
前記トークン加算部は、
フローの契約帯域に応じて周期的に一定量のトークンを加算することを特徴とする通信装置。
【請求項１０】
請求項１に記載の通信装置であって、
前記フロー毎のトークン量を保持するトークン量保持部と、
前記フロー毎に周期的に一定量のトークンを前記トークン量保持部に加算するトークン加算部と、
次に読み出し要求を通知すべきフレームのフレーム長に応じたトークン値分以上トークンバケツにトークンを保持している場合に該フローの読み出し要求を出力スケジューラに通知するトークン量判定部と、
前記出力インタフェースから前記出力フレームバッファに保持されたフレームが読み出されると、前記トークン量保持部のトークンを減算するトークン減算部と、
前記出力フレームバッファのフレームの蓄積量に基づいて、前記トークン値の加算量を決定する蓄積トークン量制御部と、を備えることを特徴とする通信装置。
【請求項１１】
請求項８に記載の通信装置であって、
前記蓄積トークン量制御部は、
前記出力フレームバッファにフレームが格納されていないときに新たに出力フレームバッファにフレームを格納した場合に、前記トークンバケツのトークン値を、前記新たに格納されたフレームのフレーム長に応じたトークン値に設定することを特徴とする通信装置。
【請求項１２】
請求項８に記載の通信装置であって、
前記蓄積トークン量制御部は、
前記出力フレームバッファにフレームが格納されていないときに新たに出力フレームバッファにフレームを格納した場合に、前記新たに格納されたフレームのフレーム長に応じたトークンよりも多く前記トークンバケツで保持されるトークン値を減算することを特徴とする通信装置。
【請求項１３】
請求項１の通信装置であって、
前記帯域制御部は、
前記フロー毎のトークン量を保持するトークン量保持部と、
前記フロー毎に周期的に一定量のトークンを前記トークン量保持部から減算するトークン減算部と、
前記トークン量保持部で保持されるトークン量に基づいて該フローの読み出し要求を出力スケジューラに通知するかしないかを判定するトークン量判定部と、
前記出力インタフェースから前記出力フレームバッファに保持されたフレームが読み出されると、前記トークン量保持部のトークンを加算するトークン加算部と、
前記出力フレームバッファのフレームの蓄積量に基づいて、前記トークン値の減算量を決定する蓄積トークン量制御部と、を備えることを特徴とする通信装置。
【請求項１４】
請求項１１に記載の通信装置であって、
前記トークン量判定部は、
前記フロー毎に設定される規定の値以下トークン量保持部にトークンが蓄積されている場合に、前記出力スケジューラに読み出し要求を通知することを特徴とする通信装置。
【請求項１５】
請求項１１に記載の通信装置であって、
前記蓄積トークン量制御部は、
前記出力フレームバッファにフレームが格納されているか否かによって、前記トークン量保持部から減算するトークン値の減算下限値を変更することを特徴とする通信装置。
【請求項１６】
請求項１１に記載の通信装置であって、
前記蓄積トークン量制御部は、
前記出力フレームバッファにフレームが格納されていない場合に前記一定量よりトークンを減算しないことを特徴とする通信装置。
【請求項１７】
請求項１１記載の通信装置であって、
前記蓄積トークン量制御部は、
前記出力フレームバッファにフレームが格納されていないときのトークン量の減算下限値を、前記出力フレームバッファにフレームが格納されているときのトークン量の減算下限値より大きい値に設定することを特徴とする通信装置。
【請求項１８】
受信したフレームの送出タイミングを通信装置において制御する帯域制御方法であって、
受信する複数のフローをフロー毎に出力フレームバッファに格納するステップと、
前記フロー毎に保持されるトークン値に基づいて該フローの読み出し要求を出力スケジューラに通知するかしないかを判定するステップと、
前記出力フレームバッファのフレームの蓄積量に基づいて、前記トークン値の加減算量を決定するステップと、を含む帯域制御方法。
【請求項１９】
前記フロー毎のトークン量をトークン量保持部で保持するステップと、
前記フロー毎に周期的に一定のトークンを前記トークン量保持部に加算するステップと、
前記トークン保持部で保持されるトークン量に基づいて該フローの読み出し要求を出力スケジューラに通知するステップと、
前記フローが読み出されると前記トークン量保持部のトークンを減算するステップと、
前記出力フレームバッファのフレームの蓄積量に基づいて、前記トークン値の加減算量を決定するステップと、を有する請求項１６に記載の帯域制御方法。
【請求項２０】
前記出力フレームバッファにフレームが格納されているか否かによって、前記トークン量保持部に加算するトークン値の加算上限値を変更するステップを有する請求項１７に記載の帯域制御方法。
【請求項２１】
前記出力フレームバッファにフレームが格納されていない場合に前記一定量以上トークンを加算しないステップを有する請求項１７に記載の帯域制御方法。
【請求項２２】
前記出力フレームバッファにフレームが格納されていないときのトークン量の加算上限値を、前記出力フレームバッファにフレームが格納されているときのトークン量の加算上限値より小さい値に設定するステップを有する請求項１７に記載の帯域制御方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【公開番号】特開２０１２−６０２０３（Ｐ２０１２−６０２０３Ａ）
【公開日】平成２４年３月２２日（２０１２．３．２２）
【国際特許分類】
【出願番号】特願２０１０−１９８４５９（Ｐ２０１０−１９８４５９）
【出願日】平成２２年９月６日（２０１０．９．６）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２４年３月２２日（２０１２．３．２２）
【国際特許分類】
【出願日】平成２２年９月６日（２０１０．９．６）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]