JP5180874B2 - バッファ管理方法、及びパケット通信装置 - Google Patents

Description

本発明は、パケット通信装置に関し、特にパケット、フレームを一時保持するためのバッファの動的なキューサイズ変更が可能なバッファ管理技術に関する。

近年、テレビコンテンツのデジタル化やインタネットでの動画配信サービスの普及により、ネットワーク上で大容量データを通信する需要が高まっている。このため、高速通信を安価に実現できるイーサネット（商標登録、以下同じ）が広く普及している。ＩＰ(Internet Protocol)パケットなどの大容量のユーザデータを送信する場合には、イーサネットでは複数のフレームを連続的（バースト的）に送出する。このようなバーストトラヒックを複数多重するネットワークでは、時にワイヤレートを超過するデータが流入することによりフレームの廃棄が発生する。このため、ＱｏＳ(Quality of Service)を確保するために網の入口でピークレートシェーピングを行い、バースト性を解消する必要がある。この際、シェーパでは設定帯域に応じたフレーム間隔を空けたタイミングで各ユーザフローのフレームを送出するため、ユーザフロー毎にフレームをバッファに格納することが求められる。その実現方法として、一つの物理バッファを複数ユーザで共有する方式（共有バッファ方式：特許文献１）や、一つの物理バッファを仮想的に分割して各フローに割当てる方式（リンクドリスト方式：特許文献２）が一般的に知られている。

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

しかしながら、共有バッファ方式を用いる場合、バッファの使用量はシェーパへの入力帯域に比例することになる。このため、シェーパからの出力帯域が低く設定されているにもかかわらず、シェーパへの入力帯域が非常に大きなユーザフローがある場合、バッファのほとんどを当該ユーザが占領することになり、ユーザ間でＱｏＳの公平性を保てないという課題がある。

一方、リンクドリスト方式を用いる場合、1つの物理的なバッファを等分割し、各フローへ割当てることがもっとも簡単な方法である。しかし、トラヒックのバースト長はシェーパへの入力帯域が大きいほど長くなる可能性が高いため、全ユーザフローのＱｏＳを保証するためには、ワーストケースとなる入力帯域の大きい場合に必要なバッファ量を全フローに割当てなければならなくなる。このため、数百から数千ユーザを収容するようなシェーパの場合、膨大なバッファ量が必要となってしまう。

そこで、運用開始前に、各フローの契約帯域に応じたバッファ量を割当てる方法が考えられるが、運用開始後にユーザ収容数や収容帯域を変更することは頻繁に行われるため、各ユーザフローへのバッファ割当て量はインサービス(フレーム導通中)で変更可能であることが望ましい。しかしながら、リンクドリスト方式ではバッファチェーンをフレーム導通中に変更した場合、以下のような課題がある。まず、バッファを増設した場合には、増設した空の領域からフレームを読み出す可能性があるため、不正なフレームが送出される。さらに、バッファを減設した場合には、減設した領域にライトポインタやリードポインタがある場合には、減設後にポインタが不正な領域を指し示すことになり正常動作が望めない。

本発明の課題は、リンクドリスト方式でバッファ量を変更した場合でも、空の領域からフレームを読み出したりすることなく、正常な動作でバッファ管理を行うことが可能なバッファ管理方法、及びパケット通信装置を提供することにある。

上記の課題を解決するため、本発明においては、リンクドリスト方式のバッファを有するパケット通信装置におけるバッファ管理方法であって、パケット通信装置は、各ユーザフローに対しするリンクドリストバッファを構成するためのチェーン情報とバッファサイズ情報を運用時の領域と更新用の領域の２つの領域で保持し、リンクドリストバッファをリードライトするためのライトポインタ及びリードポインタがリンクドリストバッファを巡回したことを示す巡回情報を保持しており、通常運用中は運用時の領域のチェーン情報とバッファサイズ情報を用いてリンクドリストバッファを構築して、ユーザフローのフレームをリンクドリストバッファにリードライトし、更新用の領域のチェーン情報とバッファサイズ情報が変更されると、巡回情報が、リードポインタ、ライトポインタそれぞれがリンクドリストバッファを一巡したことを示す場合、更新用の領域の更新されたチェーン情報とバッファサイズ情報を、運用中の領域に反映してキューサイズを更新するバッファ管理方法、及びその装置を提供する。

また、パケット通信装置は、リンクドリストバッファに格納されているフレームが無くなったことを契機に、更新用の領域の更新されたチェーン情報とバッファサイズ情報を運用中の領域へ反映してキューサイズを更新する。更に、パケット通信装置は、更新用の領域のチェーン情報とバッファサイズ情報が変更されると、巡回情報が示す巡回の回数に依存して、チェーン情報の更新、あるいはリンクドリストバッファの削除されたバッファ領域の無効化の処理を行う。

すなわち、上記課題を解決するため、本発明のパケット通信装置のシェーパは、リンクドリスト方式によるバッファを有し、各ユーザフローに対してリンクドリスト方式のバッファを構成するためのチェーン情報とバッファサイズ情報を運用時の領域と更新用の領域の２つの領域に保持し、バッファをリードライトするためのポインタがバッファを一巡したことを示すフラグを保持しており、通常運用中はチェーン情報とバッファサイズ情報の運用時の領域の情報を用いてバッファが構築され、各ユーザフローのフレームをバッファにリードライトし、チェーン情報とバッファサイズ情報のそれぞれの更新用の領域が変更されると、リードポインタ、ライトポインタの両方がそれぞれバッファを一巡するか、バッファに格納されているフレームがなくなったことを契機に、更新用の領域の更新されたチェーン情報とバッファサイズ情報を運用中の領域の該当情報とし、キューサイズを動的に変更することが可能な構成とする。

本発明によれば、複数ユーザに対するピークレートシェーピングなど、複数ユーザフロー毎にフレームをバッファに格納することが必要な場合に、フレーム導通中であっても各ユーザが必要なバッファのサイズをフレーム廃棄なく変更可能であるため、ユーザの要望するＱｏＳが頻繁に変わるようなサービスにも柔軟に対応できる。

リンクドリスト方式バッファを有するパケット転送装置の概略ブロック図である。 第１の実施例に係わる、パケット転送装置の概略ブロック図である。 第１の実施例に係わる、通信システムに流れる通信フレームのフォーマットを示す図である。 第１の実施例に係わる、ユーザアクセス装置であるＮＩＦの入力フレームに付加される装置内ヘッダのフォーマットを示す図である。 図２の入力ヘッダ処理部が備えるヘッダ処理テーブルを示す図である。 図２の出力フレームバッファ制御部の一構成を示すブロック図である。 図２の出力フレームバッファ制御部が備えるキュー管理テーブルを示す図である。 図２の出力フレームバッファ制御部が備えるチェーンテーブルを示す図である。 図２の出力フレームバッファ制御部が実行するバッファ書込み処理のフローチャートである。 図２の出力フレームバッファ制御部が実行するライトポインタ更新処理のフローチャートである。 図２の出力フレームバッファ制御部が実行するバッファ読出し処理のフローチャートである。 図２の出力フレームバッファ制御部が実行するリードポインタ更新処理のフローチャートである。 第１の実施例に係わる、リンクドリスト方式バッファの増設の概要の一例を示す図である。 第１の実施例に係わる、リンクドリスト方式バッファの減設の概要の一例を示す図である。 第２の実施例に係わる、図２の出力フレームバッファ制御部が備えるキュー管理テーブルの一例を示す図である。 第２の実施例に係わる、図２の出力フレームバッファ制御部が備えるチェーンテーブルの一例を示す図である。 第２の実施例に係わる、図２の出力フレームバッファ制御部が実行するライトポインタ更新処理のフローチャートである。 第２の実施例に係わる、図２の出力フレームバッファ制御部が実行するリードポインタ更新処理のフローチャートである。 第２の実施例に係わる、リンクドリスト方式バッファの減設の概要の一例を示す図である。

以下、本発明の実施例について図面を参照して説明するが、まずその前提となるリンクドリスト方式バッファを図１に従い説明する。

図１に見るように、リンクドリスト方式バッファでは、物理的なフレームバッファが一定の容量のバンク２００に分割されており、各バンクアドレスに対応してチェーンテーブル２４が存在する。このチェーンテーブル２４には、各バンク２００の接続された次のバンクアドレス２４０が格納されており、この次バンクアドレス２４０を辿っていくことによりリンクドリスバッファのアクセスが可能となる。図１では、フレームバッファのバンク＃１：２００−１、バンク＃３：２００−３、バンク＃Ｎ：２００−Ｎを用いてリンクドリストバッファを構成した例を示す。バンク＃１：２００−１に対応するチェーンテーブル２４の次バンクアドレス２４０−１にはバンク＃３：２００−３と設定されているため、次にバンク＃３：２００−３へのアクセスが可能となる。さらに、バンク＃３：２００−３の次バンクアドレス２４０−３にはバンク＃Ｎ：２００−Ｎが設定されており、バンク＃Ｎ：２００−Ｎの次バンクアドレス２４０−Ｎにはバンク＃１：２００−１が設定されているため、チェーンが一周し、リンクドリストバッファが構成されていることがわかる。本発明は、このバンク２００の個数（キューサイズ）をフレーム導通中（運用中）でも増減可能とするバッファ管理技術を提供するものである。

フレーム導通中（運用中）にキューサイズを変更する第１の実施例の概要を図１３、図１４を用いて説明する。

本実施例のバッファ管理方法では、フレームバッファ２０００中の各バンクに対するチェーン情報構造を示す次バンクアドレスを運用次バンクアドレス２４０２と更新次バンクアドレス２４０３の２面保持し、キューサイズに関しても運用キューサイズ２３０４と更新キューサイズの２３０５の２面保持する。通常時のバッファ管理は運用次バンクアドレス２４０２および運用キューサイズ２３０４を用いており、キューサイズを変更したい場合は更新次バンクアドレス２４０３および更新キューサイズ２３０５を変更する。

図１３はフレームバッファ２０００中のバンクのキューサイズの増設の概要を示した図である。増加前の運用キューサイズ２３０４は４バンクであり、４バンクが接続されたチェーン構造を運用次バンクアドレス２４０２として保持している。これに対して、更新キューサイズ２３０５は６バンクと設定し、チェーン構造も更新次バンクアドレス２４０３のように書き換えている。

一方、図１４はフレームバッファ２０００中のバンクのキューサイズの減設の概要を示した図である。減設前の運用キューサイズ２３０４は６バンクであり、６バンクが接続されたチェーン構造を運用次バンクアドレス２４０２として保持している。これに対して、更新キューサイズ２３０５は４バンクと設定し、チェーン構造も更新次バンクアドレス２４０３のように書き換えている。

図１３および図１４のような状態で、キューサイズの変更開始のトリガを与える（後述するキューサイズ変更完了フラグ２３１１、ＷＰ（Write Pointer）周回フラグ２３０９、ＲＰ(Read Pointer)周回フラグ２３１０を‘０’に設定する）ことで、キューサイズ更新処理が開始され、ライトポインタおよびリードポインタがともに周回した（バッファ２０００の先頭に戻った）ことを検出すると更新次バンクアドレス２４０３を運用次バンクアドレス２４０２にコピー、および更新キューサイズ２３０５を運用キューサイズ２３０４にコピー処理を実施し、このコピー処理が終了（リードポインタに２回目の周回が発生）したことを検出するとキューサイズの増設処理を完了（キューサイズ変更完了フラグ２３１１に‘１’を設定）する。ただし、バッファ２０００からフレームを読み出した結果、バッファ２０００にフレームがなくなった場合には、ライトポインタとリードポインタの周回を待たずに即時キューサイズの変更が可能であるため、各ポインタをバッファの先頭に初期化してしまうことが必要である。この機能がなく、各ポインタの周回のみでキューサイズ更新してしまうと、フレームが全く通らない場合に、キューサイズの変更が完了しないことになってしまう。

このように、本実施例の構成によれば、バッファ２０００のチェーン情報やキューサイズを２面保持し、ライトポインタとリードポインタの周回状況を利用することで、運用中のキューサイズは変更可能となる。

図２は、本実施例のパケット通信装置であるパケット転送装置１０Ｎの一構成例を示すブロック図である。

パケット転送装置１０Ｎは、複数のネットワークインタフェースボード（ＮＩＦ）１０（１０−１〜１０−ｎ）と、これらのＮＩＦに接続されたフレーム中継部１５からなる。

各ＮＩＦ１０は、ＦＰＧＡ(Field Programmable Gate Array)や専用ＡＳＩＣ(Application Specific Integrated Circuit)等で構成され、通信ポートとなる入出力回線インタフェース１１と、処理部、制御部として機能する中央処理部(Central Processing Unit：ＣＰＵ)と、テーブル等を記憶する記憶部であるメモリを備え、通信ポートを介して、他のパケット通信装置と接続されている。本実施例では、入出力回線インタフェース１１は、イーサネット用の回線インタフェースとなっている。

ユーザアクセス装置として機能する各ＮＩＦ１０は、これらの入出力回線インタフェース１１に接続された入力ヘッダ処理部１２と、入力ヘッダ処理部１２に接続された入力フレームバッファ制御部１３を有する。また、各ＮＩＦ１０は、フレーム中継部１５に接続されたＳＷインタフェース１４と、このＳＷインタフェースに接続された出力フレームヘッダ処理部１６と、出力フレームヘッダ処理部１６に接続された出力フレームバッファ制御部１７とを有する。さらに、ＮＩＦ １０は、ＮＩＦの全体ブロックやテーブルを管理、設定するＮＩＦ管理部１８を有する。これら処理部、制御部、管理部は、上記のＣＰＵにおけるプログラム処理によって実現できるため、以下ではこれらの処理機能を実現するＣＰＵを処理部として総称し、主にこの処理部におけるプログラム処理を示すフォローチャートを用いて種々の処理機能を説明する。これらの処理プログラムは図示されない記憶部としてメモリに予め記憶されているか、必要に応じてネットワークを使って導入されることは言うまでもない。

さて、入出力回線インタフェース１１は、入力回線から図３に示すフォーマットの通信フレーム４０を受信すると、図７に示す装置内ヘッダ４１を付加する。

通信フレーム４０は、宛先ＭＡＣアドレス４０１、送信元ＭＡＣアドレス４０２、ＶＬＡＮタグ４０３、後続ヘッダの種類を示すタイプ値４０４からなるＭＡＣヘッダと、ペイロード４０５と、フレームチェックシーケンス（ＦＣＳ）４０６とからなる。

宛先ＭＡＣアドレス４０１と送信元ＭＡＣアドレス４０２には、パケット転送装置１０Ａまたは１０Ｎ、または端末７０のＭＡＣアドレスが設定される。ＶＬＡＮタグ４０３は、フロー識別子となるＶＬＡＮ ＩＤの値（ＶＩＤ♯）を示している。

装置内ヘッダ４１は、出力ネットワークインタフェースボード識別子（ＮＩＦ ＩＤ）４１１と、フローＩＤ４１２と、フレーム長４１３とを示す複数のフィールドとからなっている。このうち、ＮＩＦ ＩＤ４１１は、内部ルーティング情報となっており、フレーム中継部１５は、この内部ルーティング情報に従って、入力フレームを特定のネットワークインタフェースボードの特定のＳＷインタフェースに転送する。

入出力回線インタフェース１１が、受信フレームに装置内ヘッダ４１を付加した時点では、出力ＮＩＦ ＩＤ４１１、フローＩＤ４１２は空欄となっている。これらのフィールドには、入力ヘッダ処理部１２によって有効値が設定される。

入力ヘッダ処理部１２は、ヘッダ処理テ−ブル２１を参照して、各入力フレームの装置内ヘッダ４１にＮＩＦ ＩＤ４１１、フローＩＤ４１２の値を追加する。

図５はヘッダ処理テ−ブル２１の一例を示す構成図である。

ヘッダ処理テ−ブル２１は、ＮＩＦ管理部１８が設定を行うテーブルであり、ＶＬＡＮ ＩＤ２１０１を検索キーとして、タグ処理２１０２と、新ＶＬＡＮ ＩＤ２１０３と、ＣｏＳ(Class of Service)処理２１０４と、新ＣｏＳ２１０５と、出力ＮＩＦ ＩＤ２１０６と、フローＩＤ２１０７、送信元ＭＡＣアドレス２１０８と、宛先ＭＡＣアドレス２１０９とを示すテーブルエントリを検索するためのものである。ここで、タグ処理２１０２は、ＶＬＡＮタグの透過、変換、付与、削除などの処理方法を示し、新ＶＬＡＮ ＩＤ２１０３は、タグ処理２１０２が変換または付与と設定された場合にＶＬＡＮタグに書き込む新たなＶＬＡＮ ＩＤを設定する。また、ＣｏＳ処理２１０４は、ＶＬＡＮタグの中のＣｏＳの変換、コピーなどの処理方法を示し、新ＣｏＳ２１０５は、ＣｏＳ処理２１０４が変換と設定された場合にＶＬＡＮタグに書き込む新たなＣｏＳを設定する。送信元ＭＡＣアドレス２１０８は、入出力回線インタフェース１１がもつＭＡＣアドレスであり、宛先ＭＡＣアドレス２１０９は、上記入出力回線インタフェース１１を介して接続されたフレームの宛先となるパケット転送装置のＭＡＣアドレスを示している。

入力ヘッダ処理部１２は、フレームを受信すると、ヘッダ情報テーブル２１から、入力フレームのＶＬＡＮタグ４０３が示すＶＩＤの値（ＶＩＤ♯）と対応するテーブルエントリを検索し、このテーブルエントリが示すタグ処理２１０２、ＣｏＳ処理２１０５に従ってＶＬＡＮタグ処理を行い、送信元ＭＡＣアドレス２１０８、宛先ＭＡＣアドレス２１０９を適用して、入力フレーム４０のヘッダ処理を行う。さらに、入力ヘッダ処理部１２は、上述のテーブルエントリが示す出力ＮＩＦ ＩＤ２１０６、フローＩＤ２１０７の値を装置内ヘッダ４１に上書きして、入力フレームを入力フレームバッファ制御部１３に転送する。

入力フレームバッファ制御部１３は、入力ヘッダ処理部１２からフレームを受信すると、入力フレームバッファ１９にフレームを格納する。さらに、入力フレームバッファ１９に蓄積されたフレームを読み出し、フレーム間ギャップを調整してＳＷインタフェース１２に送信する。

フレーム中継部１５は、各インタフェースボード（ＮＩＦ）のＳＷインタフェース１４から入力フレームを受け取り、その装置内ヘッダが示す出力ＮＩＦ ＩＤ４１１で特定されるインタフェースボード（ＮＩＦ）のＳＷインタフェース１４に、出力フレームとして転送する。

各ＳＷインタフェース１４が受信した出力フレームは、次々と出力ヘッダ処理部１６に供給される。本実施例では、入力フレームから出力フレームへのフォーマット変換を入力ヘッダ処理部１２で行ったが、このフォーマット変換機能は、出力ヘッダ処理部１６にヘッダ変換に必要な情報を記憶したヘッダ変換テーブル２２を設けて、出力ヘッダ処理部１６で実行するようにしもよい。入力ヘッダ処理部１２でヘッダ変換を行った場合は、出力ヘッダ処理部１６は、ＳＷインタフェース１４から受信した出力フレームをそのまま出力フレームバッファ制御部１７に送信する。

出力フレームバッファ制御部１７は、出力フレームをフロー毎の出力フレームバッファ２０に蓄積する。出力フレームバッファ制御部１７は、蓄積された出力フレームを帯域管理テーブル２５に設定されたフロー毎の帯域情報を用いてシェーピングしながら出力フレームバッファ２０から読出し、入出力回線インタフェース１１に送出する。

入出力回線インタフェース１１は、受信した出力フレームから装置内ヘッダ４１を除去し、図４または図５に示したフォーマットで出力フレームを出力回線に送出する。

図６は図２の出力フレームバッファ制御部１７の一例を示す機能ブロック図である。

出力フレームバッファ制御部１７は、バッファ書込み処理部１７１と、バッファ読出し処理部１７２と、帯域管理部１７３とからなるが、これらは上述したＣＰＵのプログラム処理等で実現できることは言うまでもない。なお、以下、本実施例の説明は出力フレームバッファ制御部の構成に基づき説明するが、本構成は入力フレームバッファ制御部の構成に適用することもできる。この場合、出力ヘッダ制御部１６および出力フレームバッファ２０は、入力ヘッダ処理部１２および入力フレームバッファ１９等、適宜変更されることは言うまでもない。

さて、図６のバッファ書込み処理部１７１は、出力ヘッダ処理部１６からのフレームを受信すると、図９を用いて後ほど詳述するバッファ書込み処理を実施し、フレームをバッファ２０に格納し、格納したフレームのフローＩＤ４１２やフレーム長４１３とフレーム格納通知を帯域管理部１７３に送信する。帯域管理部１７３は、バッファ書込み処理部１７１からこのフレーム格納通知を受信すると、フローＩＤ４１２を用いて帯域管理テーブル２５を検索し、当該フレームの読出しタイミングを決定し、フレーム出力リスト１７３１にフローＩＤ４１２を格納する。フレーム出力リスト１７３１は時刻と各エントリが１対１で対応した構造になっており、このフレーム出力リスト１７３１のどのエントリに登録したかで読み出しタイミングが一意に決定できる。

帯域管理部１７３は、このフレーム出力リスト１７３１の各エントリを一定間隔でリードしフローＩＤ４１２が格納されていればそれを取得し、フレーム送信要求とともにバッファ読出し処理部１７２へ通知する（なお、帯域管理部の処理は本発明と直接関係がないため、詳細は割愛する）。バッファ読出し処理部１７２は、上述のフレーム送信要求を受信するとフレーム送信処理（Ｓ３００）を行い、フレームバッファ２０からフレームを読出し、入出力回線インタフェース１１に出力する。

図９は、バッファ書込み処理部１７１が実行するバッファ書込み処理（Ｓ１００）のフローチャートを示している。

バッファ書込み処理部１７１は、出力ヘッダ処理部１６からフレームを受信すると、受信フレームの装置内ヘッダ４１からフローＩＤ４１２と、フレーム長４１３とを取得し、キュー管理テーブル２３を検索する（Ｓ１０１）。

キュー管理テ−ブル２３は、図７にその一例を示すように、ＮＩＦ１０のＮＩＦ管理部１８が設定を行うテーブルであり、フローＩＤ２３０１を検索キーとして、先頭バンクアドレス２３０２と、Ａ／Ｄ２３０３と、運用キューサイズ２３０４と、更新キューサイズ２３０６と、格納バイト数２３０６と、ライトポインタ２３０７と、リードポインタ２３０８と、ＷＰ周回フラグ２３０９と、ＲＰ周回フラグ２３１０と、キューサイズ変更完了フラグ２３１１とを示すテーブルエントリを検索するためのものである。ここで、先頭バンクアドレス２３０２は、当該フローのリンクドリストバッファの先頭となるバンク２００のアドレスを示し、Ａ／Ｄ２３０３は運用中のキューサイズの増減動作（‘０’：バッファ増設、‘１’：バッファ減設）を示し、運用キューサイズ２３０４は、当該フローの運用するキューサイズを示し、更新キューサイズ２３０５は、当該フローの運用キューサイズを変更する場合の変更後のキューサイズを示し、格納バイト数２３０６は、当該フローのバッファに格納されているバイト数を示し、ライトポインタ２３０７は、当該フローのバッファのライト開始アドレスを示し、リードポインタ２３０８は、当該フローのバッファのリード開始アドレスを示す。ここで、ライトポインタ２３０７およびリードポインタ２３０８の上位Ｘｂｉｔが当該バンク２００のバンクアドレスを示し、下位Ｙｂｉｔがバンク２００内のアドレスを示している。さらに、ＷＰ周回フラグ２３０９は、ライトポインタ２３０８がバッファの先頭バンクアドレスに戻った（周回した）ことを示すフラグであり、ＲＤ周回フラグ２３１０は、リードポインタ２３０９がバッファの先頭バンクアドレスに戻った（周回した）ことを示すフラグであり、キューサイズ変更完了フラグ２３１１は、運用中のキューサイズの変更が完了したことを示す各フィールドである。

図９に戻り、バッファ書込み処理部１７１は、キュー管理テーブル２３を検索し、フィールド情報を取得すると、格納バイト数２３０６＋フレーム長４１３で格納バイト数２３０６を上書きし（Ｓ１０２）、この格納バイト数２３０６が運用キューサイズ２３０４よりも大きいか比較し（Ｓ１０３）、格納バイト数２３０６が運用キューサイズ２３０４を上回っている場合、バッファオーバフローとなり、フレームを廃棄し（Ｓ１０７）、処理終了となる（Ｓ１０８）。一方、比較の結果、格納バイト数２３０６が運用キューサイズ２３０４以下である場合、ライトポインタ２３０７を用いてフレームをバッファに格納し（Ｓ１０４）、ライトポインタ２３０７の更新処理（Ｓ２００）を実施し、更新したライトポインタ２３０７や格納バイト数２３０６をキュー管理テーブル２３へ書込み（Ｓ１０５）、帯域管理部１７３に、格納したフレームのフローＩＤ４１２およびフレーム長４１３とともにフレーム格納通知を送信し（Ｓ１０６）、処理終了となる（Ｓ１０８）。

図１０に図９のライトポインタ更新処理（Ｓ２００）の一例を示す。まず今回のフレーム長４１３分の書込みの結果、バンクの移動になるかどうかを判定し（Ｓ２０１）、バンクの移動がなければライトポインタ２３０７にフレーム長４１３を加算して（Ｓ２０２）、処理終了となる（Ｓ２１６）。一方、上記判定の結果バンクが移動する場合、ライトポインタ２３０７の上位Ｘｂｉｔでチェーンテーブル２４を検索する（Ｓ２０３）。

チェーンテーブル２４は、ＮＩＦ管理部１８が設定を行うテーブルであり、リードポインタ２３０７またはリードポインタ２３０８の上位Ｘｂｉｔのバンクアドレス２４０１を検索キーとして、運用次バンクアドレス２４０２と、更新次バンクアドレス２４０３とを示すテーブルエントリを検索するためのものである。図１３、図１４で説明したように、運用次バンクアドレス２４０２は、運用中のチェーン情報となる次バンクアドレスを示し、更新次バンクアドレス２４０３は、運用キューサイズを変更する場合のチェーンの組み換えが発生する場合の変更後の次バンクアドレスを示す。

バッファ書込み処理部１７１は、チェーンテーブル２４を検索し、チェーン情報を取得した後、キュー管理テーブル２３から取得済みのキューサイズ変更完了フラグ２３１１を検査し（Ｓ２０４）、‘０’（変更未完了）である場合、ＲＰ周回フラグ２３１０を検査し（Ｓ２０５）、‘０’（リードポインタ２３０８未周回）である場合、ＷＰ周回フラグ２３０９を検査し（Ｓ２０６）、‘０’（ライトポインタ２３０７未周回）である場合、運用次バンクアドレス２４０２とフレーム長４１３を用いてライトポインタ２３０７を更新し（Ｓ２０７）、運用次バンクアドレス２４０２とキュー管理テーブル２３から取得済みの先頭バンクアドレス２３０２と比較し（Ｓ２０８）、一致していなければそのまま処理終了となる（Ｓ２１６）。一方、Ｓ２０８において運用次バンクアドレス２４０２と先頭バンクアドレス２３０２が一致した場合、ＷＰ周回フラグ２３０９に‘１’を上書し（Ｓ２０９）、処理終了となる（Ｓ２１６）。

上記のＳ２０６にてＷＰ周回フラグ２３０９が‘１’（ライトポインタ２３０７周回）であれば、更新次バンクアドレス２４０３とフレーム長４１３を用いてライトポインタ２４０７を更新し（Ｓ２１０）、Ａ／Ｄ２３０３を検査し、‘０’（キューサイズ増加）の場合、処理終了となる（Ｓ２１６）。一方、上記のＡ／Ｄ２３０３が‘１’（キューサイズ減設）の場合、更新次バンクアドレス２４０３とキュー管理テーブル２３から取得済みの先頭バンクアドレス２３０２と比較し（Ｓ２１２）、一致していればオーバフローとしてフレームを廃棄し（Ｓ２１３）、処理終了となる（Ｓ２１６）。一方、Ｓ２１２にて更新次バンクアドレス２４０３と先頭バンクアドレス２３０２が一致していなければ、そのまま処理終了となる（Ｓ２１６）。

上記のＳ２０５にてＲＰ周回フラグ２３１０が‘１’（リードポインタ２３０８周回）であれば、更新次バンクアドレス２４０３とフレーム長４１３を用いてライトポインタ２４０７を更新し（Ｓ２１４）、処理終了となる（Ｓ２１６）。

上記のＳ２０４にてキューサイズ変更完了フラグ２３１１が‘１’（変更完了）であれば、運用次バンクアドレス２４０２とフレーム長４１３を用いてライトポインタ２４０７を更新し（Ｓ２１５）、処理終了となる（Ｓ２１６）。

図１１は、バッフ読出し処理部１７２が、帯域管理部１７３からのフレーム送信要求受信に応じて実行するバッファ読出し処理（Ｓ３００）のフローチャートを示している。

フレーム読出し処理部１７２は、フレーム送出要求を受信すると、同時に帯域管理部１７３から出力されるフローＩＤ４１２を用いてキュー管理テーブル２３を検索し（Ｓ３０１）、リードポインタ２３０８を用いてフレームをバッファから読み出して送出開始し（Ｓ３０２）、格納バイト数２３０６から読み出したバッファから読み出したフレーム長４１３を減算し上書きし（Ｓ３０３）、リードポインタ更新処理（Ｓ４００）を行い、更新後のリードポインタ２３０８や格納バイト数２３０６などをキュー管理テーブル２３へ書込み（Ｓ３０４）、処理終了となる（Ｓ３０５）。

図１２に図１１のリードポインタ更新処理（Ｓ４００）の一例を示す。まず、リードポインタ２３０８の上位Ｘｂｉｔのバンクアドレスでチェーンテーブル２４を検索し（Ｓ４０１）、今回のフレーム長４１３分の読出しの結果、バンクの移動になるかどうかを判定し（Ｓ４０２）、バンクの移動がない場合はリードポインタ２３０８にフレーム長４１３を加算して上書きし（Ｓ４０３）、ＲＰ周回フラグ２３１０が‘１’かつキューサイズ完了フラグ２３１１が‘０’かを検査し（Ｓ４０４）、ＲＰ周回フラグ２３１０が‘１’かつキューサイズ完了フラグ２３１１が‘０’でなければそのまま処理を終了する（Ｓ４１４）。

Ｓ４０２にて、今回のフレーム長４１３分の読出しの結果バンクを移動する場合、運用次バンクアドレス２４０２とフレーム長４１３を用いてリードポインタ２３０８を更新し（Ｓ４０５）、ＲＰ周回フラグ２３１０を検査し（Ｓ４０６）、‘０’（リードポインタ２３０８未周回）であれば、上記更新した格納バイト数２３０６を検査し（Ｓ４１２）、‘０’でなければ運用次バンクアドレス２４０２と先頭バンクアドレス２３０２を比較し（Ｓ４０７）、不一致であれば終了する（Ｓ４１４）。一方、運用次バンクアドレス２４０２と先頭バンクアドレス２３０２が一致していれば、リードポインタ２３０８に１回目の周回が発生したためＲＰ周回フラグ２３１０に‘１’を上書きし（Ｓ４０８）、終了する（Ｓ４１４）。

一方、Ｓ４１２にて、格納バイト数２３０６が‘０’（バッファ空）であれば、本バッファのキューサイズ変更を即時有効とするため、ライトポインタ２３０７とリードポインタ２３０８を先頭バンクアドレス２３０２の先頭に設定し、ＲＰ周回フラグ２３１０に‘１’を設定し（Ｓ４１３）、処理を終了する（Ｓ４１４）。ここで、即時キューサイズ変更完了フラグを‘１’としないのは、リードポインタ２３０８がバッファを１回周回してから（ＲＰ周回フラグが‘１’が立ってから）もう一度リードポインタ２３０８が周回するまでの間に、チェーン情報を更新する（運用次バンクアドレス２４０２に更新次バンクアドレス２４０３をコピーする）ためである。

Ｓ４０６にて、ＲＰ周回フラグ２３１０が‘１’（リードポインタ２３０８が１回周回）であれば終了する（Ｓ４１４）。

Ｓ４０４にて、ＲＰ周回フラグ２３１０が‘１’かつキューサイズ完了フラグ２３１１が‘０’であれば、運用次バンクアドレス２４０２に更新次バンクアドレス２４０３をコピーしてチェーンテーブル２４に書き戻し（Ｓ４０９）、運用次バンクアドレス２４０２と先頭バンクアドレス２３０２を比較し（Ｓ４１０）、一致していなければＳ４１２以降の処理を実施する。一方、運用次バンクアドレス２４０２と先頭バンクアドレス２３０２が一致している場合、リードポインタ２３０８に２回目の周回が発生したことになるため、キューサイズ変更完了フラグ２３１１に‘１’（変更完了）を上書きし、運用キューサイズ２３０４に更新キューサイズ２３０５をコピーし（Ｓ４１１）、終了する（Ｓ４１４）。

上記において、運用中のキューサイズを変更する場合、ＮＩＦ管理部１８は、まずチェーンテーブル２４の更新次バンクアドレス２４０３に新たなチェーン情報を設定し、その後、キュー管理テーブル２３の更新キューサイズ２３０５に新たなキューサイズ、Ａ／Ｄ ２３０３に増加（‘０’）または減設（‘１’）を設定し、ＷＰ周回フラグ２３０９、ＲＰ周回フラグ２３１０、キューサイズ変更完了フラグ２３１１にそれぞれ‘０’を設定する。これにより、出力フレームバッファ制御部１７は、ＷＰ周回フラグ２３０９、ＲＰ周回フラグ２３１０、キューサイズ変更完了フラグ２３１１がそれぞれ‘０’であることから、キューサイズの変更処理が必要である事を認識し、上述のフローチャートに従って、キューサイズの更新を行う。ここで、バンクの増減設は、リンクドリストバッファの末尾から行うことが必須であり、さらに先頭バンクアドレス２３０２を含んではならない。

続いて、第二の実施例として、キューサイズが減設された場合に、減設され開放された領域を無効状態にするリンクドリストバッファの管理方法を説明する。本実施例のパケット通信装置の構成は、実施例１の図２と全く同様の構成であるが、チェーンテーブル２４、キュー管理テーブル２３、ライトポインタ更新処理（Ｓ２００）、リードポインタ更新処理（Ｓ４００）が、以下に説明する点で違いを有している。

図１９は、キューサイズが減設された場合に、減設された領域のフレームバッファを開放する方法の概要を示す。

本実施例のリンクドリストバッファにおいて、運用中にキューサイズを減設した場合、バンクのどの領域が解放されたのかを把握し、新たに他のフローにバンクを割当てる場合は、開放されているバンクを使用するように管理する必要がある。このため、図１９のようにフレームバッファ２０００のキューサイズを６バンクから４バンクに減設した場合に、開放した領域（バンク＃５、バンク＃６）を無効状態にすることが求められる。

図１６は、上記のようなバッファの開放を行うために、使用中フラグ２４０４のフィールドを追加したチェーンテーブル２４を示す。

使用中フラグ２４０４は、当該エントリに対応するバンクが使用されているかどうかを示すフラグであり、使用中フラグ‘１’なら当該バンクが使用されていることを示し、‘０’なら開放されていることを示す。

図１５は、上述したバッファの開放を行うために、ＷＰ周回カウンタ２３１２、ＲＰ周回カウンタ２３１３、および無効化フラグ２３１４のフィールドを備えたキュー管理テーブル２３を示す。

上述したバッファの開放を実現するためには、ライトポインタ２３０７とリードポインタ２３０８が1回周回したことを検出し、各ポインタが削減されるバンクに存在しないことをトリガとしてチェーン情報を更新するだけでなく、もう一回周回させることにより、削減されたバンク領域の使用中フラグ２４０４を‘１’から‘０’に設定し、バンクを開放することが求められる。このため、ＷＰ周回フラグ２３０９、ＲＰ周回フラグ２３１０に代え、ライトポインタ２３０７とリードポインタ２３０８の周回数をカウントするＷＰ周回カウンタ２３１２およびＲＰ周回カウンタ２３１３を有する。さらに、図１９に示される通り、開放するバンク領域は、バッファの途中からバンクの末尾までであるため、二回目の周回時にバッファの開放処理を開始した情報として無効化フラグ２３１４が必要である。

図１７は、図９、１０のライトポインタ更新処理（Ｓ２００）の代わりにバッファ書込み部１７１にて行う、バッファ開放処理を加えたライトポインタ更新処理（Ｓ５００）の内容を示す。

図１７に示すライトポインタ更新処理（Ｓ５００）では、まず今回のフレーム長４１３分の書込みの結果バンクを移動になるかどうかを判定し（Ｓ５０１）、バンクの移動がなければライトポインタ２３０７にフレーム長４１３を加算して（Ｓ５０２）、処理終了となる（Ｓ５１６）。一方、上記判定の結果バンクが移動する場合、ライトポインタ２３０７の上位Ｘｂｉｔで図１６のチェーンテーブル２４を検索する（Ｓ５０３）。

上記チェーンテーブル２４を検索し、チェーン情報を取得した後、図１５のキュー管理テーブル２３から取得済みのキューサイズ変更完了フラグ２３１１を検査し（Ｓ５０４）、‘０’（変更未完了）である場合、ＲＰ周回カウンタ２３１３を検査し（Ｓ５０５）、“２”未満である場合、ＷＰ周回カウンタ２３１２を検査し（Ｓ５０６）、“２”未満である場合、運用次バンクアドレス２４０２とフレーム長４１３を用いてライトポインタ２３０７を更新し（Ｓ５０７）、運用次バンクアドレス２４０２とキュー管理テーブル２３から取得済みの先頭バンクアドレス２３０２と比較し（Ｓ５０８）、一致していなければそのまま処理終了となる（Ｓ５１６）。一方、Ｓ５０８において運用次バンクアドレス２４０２と先頭バンクアドレス２３０２が一致した場合、ＷＰ周回カウンタ２３１２を‘１’カウントアップし（Ｓ５０９）、処理終了となる（Ｓ５１６）。

上記のＳ５０６にてＷＰ周回カウンタ２３１２が“２”以上であれば、更新次バンクアドレス２４０３とフレーム長４１３を用いてライトポインタ２４０７を更新し（Ｓ５１０）、Ａ／Ｄ２３０３を検査し、‘０’（キューサイズ増加）の場合、処理終了となる（Ｓ５１６）。一方、Ａ／Ｄ２３０３が‘１’（キューサイズ減設）の場合、更新次バンクアドレス２４０３とキュー管理テーブル２３から取得済みの先頭バンクアドレス２３０２と比較し（Ｓ５１２）、一致していればオーバフローとしてフレームを廃棄し（Ｓ５１３）、処理終了となる（Ｓ５１６）。一方、Ｓ５１２にて更新次バンクアドレス２４０３と先頭バンクアドレス２３０２が一致してば、そのまま処理終了となる（Ｓ５１６）。

上記Ｓ５０５にてＲＰ周回カウンタ２３１３が“２”以上であれば、更新次バンクアドレス２４０３とフレーム長４１３を用いてライトポインタ２４０７を更新し（Ｓ５１４）、処理終了となる（Ｓ５１６）。

上記のＳ５０４にてキューサイズ変更完了フラグ２３１１が‘１’（変更完了）であれば、運用次バンクアドレス２４０２とフレーム長４１３を用いてライトポインタ２４０７を更新し（Ｓ５１５）、処理終了となる（Ｓ５１６）。

図１８は、図１１、１２に示したリードポインタ更新処理（Ｓ４００）の代わりにバッファ読出し部１７２にて行う、バッファ開放処理を加えたリードポインタ更新処理（Ｓ６００）の内容を示す。

図１８に示すリードポインタ更新処理（Ｓ６００）では、リードポインタ２３０８の上位Ｘｂｉｔのバンクアドレスで図１６のチェーンテーブル２４を検索し（Ｓ６０１）、今回のフレーム長４１３分の読出しの結果バンクを移動になるかどうかを判定し（Ｓ６０２）、バンクの移動がない場合はリードポインタ２３０８にフレーム長４１３を加算して上書きし（Ｓ６０３）、ＲＰ周回カウンタ２３１３が“２”以上かつキューサイズ完了フラグ２３１１が‘０’かを検査し（Ｓ６０４）、ＲＰ周回カウンタ２３１３が“２”以上かつキューサイズ完了フラグ２３１１が‘０’でなければそのまま処理を終了する（Ｓ６２３）。

Ｓ６０２にて、今回のフレーム長４１３分の読出しの結果バンクを移動する場合、運用次バンクアドレス２４０２とフレーム長４１３を用いてリードポインタ２３０８を更新し（Ｓ６０５）、ＲＰ周回カウンタ２３１３が“２”以上またはキューサイズ完了フラグ２３１１が‘１’かを検査し（Ｓ６０６）、ＲＰ周回カウンタ２３１３が“２”以上またはキューサイズ完了フラグ２３１１が‘１’でなければ、上記更新した格納バイト数２３０６を検査し（Ｓ６０７）、‘０’（バッファ空）であれば、本バッファのキューサイズ変更を即時有効とするため、ライトポインタ２３０７とリードポインタ２３０８を先頭バンクアドレス２３０２の先頭に設定し、ＷＰ周回カウンタ２３１２に“２”、ＲＰ周回カウンタ２３１３に‘１’を設定する（Ｓ６０８）。ここで、即時キューサイズ変更完了フラグを‘１’、ＲＰ周回フラグを“２”としないのは、リードポインタ２３０８がバッファを１回周回してから（ＲＰ周回カウンタ２３１３が‘１’となってから）もう一度リードポインタ２３０８が周回するまでの間に、チェーンテーブル２４の使用中フラグ２４０４を‘０’としバッファを開放し、さらにもう一度リードポインタ２３０８が周回する（二回転から三回転）までの間に、チェーン情報を更新（運用次バンクアドレス２４０２に更新次バンクアドレス２４０３をコピーする）するためである。

上述の処理後、または上記Ｓ６０７にて格納バイト数２３０６が‘０’でなければ、ＲＰ周回カウンタ２３１３を検査し（Ｓ６０９）、‘０’であれば運用次バンクアドレス２４０２と先頭バンクアドレス２３０２を比較し（Ｓ６１０）、不一致であれば終了する（Ｓ６２３）。一方、運用次バンクアドレス２４０２と先頭バンクアドレス２３０２が一致していれば、リードポインタ２３０８に１回目の周回が発生したためＲＰ周回カウンタ２３１３を‘１’カウントアップし（Ｓ６１１）、Ａ／Ｄ ２３０３を検査し（Ｓ６１２）、‘０’（キューサイズ減設）であればそのまま終了する（Ｓ６２３）。一方、Ａ／Ｄ ２３０３が‘１’（キューサイズ増設）であれば、ＷＰ周回カウンタ２３１２およびＲＰ周回カウンタ２３１３に“２”を設定し、無効化フラグ２３１４に‘１’を設定し、終了する（Ｓ６２３）。これは、キューサイズ増設の場合は、バッファ開放処理は行う必要がないためである。ただし、チェーン情報の更新処理は必要であるため、キューサイズ変更完了フラグ２３１１は‘１’には設定しない。

Ｓ６０９にて、ＲＰ周回カウンタ２３１３が‘１’（リードポインタ２３０８が１回周回）であれば、無効化フラグ２３１４を検査し（Ｓ６１４）、‘０’であれば運用次バンクアドレス２４０２と更新次バンクアドレス２４０３を比較し（Ｓ６１５）、一致していれば終了する（Ｓ６２３）。一方、運用次バンクアドレス２４０２と更新次バンクアドレス２４０３を比較し不一致であれば、バッファ開放処理を開始するため無効化フラグ２３１４に‘１’を設定し、終了する（Ｓ６２３）。

Ｓ６１４にて、無効化フラグ２３１４が‘１’であれば、バッファ開放処理中であるため、リードポインタ２３０８の上位Ｘｂｉｔのバンクアドレスに対応する図１６のチェーンテーブル２４の使用中フラグ２４０４を‘０’（開放）し（Ｓ６１７）、更新次バンクアドレス２４０３と先頭バンクアドレス２３０２を比較し（Ｓ６１８）、不一致であれば終了する（Ｓ６２３）。一方、更新次バンクアドレス２４０３と先頭バンクアドレス２３０２が一致していれば、リードポインタ２３０８に２回目の周回が発生したためＲＰ周回カウンタ２３１３を‘１’カウントアップし（Ｓ６１９）、終了する（Ｓ６２３）。

上記のＳ６０６にて、ＲＰ周回カウンタ２３１３が“２”以上またはキューサイズ完了フラグ２３１１が‘１’であれば、そのまま終了する（Ｓ６２３）。

Ｓ６０４にて、ＲＰ周回カウンタ２３１３が“２”以上かつキューサイズ完了フラグ２３１１が‘０’であれば、運用次バンクアドレス２４０２に更新次バンクアドレス２４０３をコピーしてチェーンテーブル２４に書き戻し（Ｓ２０）、運用次バンクアドレス２４０２と先頭バンクアドレス２３０２を比較し（Ｓ６２１）、一致していなければ終了する（Ｓ６２３）。一方、運用次バンクアドレス２４０２と先頭バンクアドレス２３０２が一致している場合、リードポインタ２３０８に３回目の周回が発生したことになるため、キューサイズ変更完了フラグ２３１１に‘１’（変更完了）を上書きし、運用キューサイズ２３０４に更新キューサイズ２３０５をコピーし（Ｓ６２２）、終了する（Ｓ６２３）。

ここで、運用中のキューサイズを変更する場合、ＮＩＦ管理部１８は、まずチェーンテーブル２４の更新次バンクアドレス２４０３に新たなチェーン情報を設定し、その後、キュー管理テーブル２３の更新キューサイズ２３０５に新たなキューサイズ、Ａ／Ｄ ２３０３に増加（‘０’）または減設（‘１’）を設定し、ＷＰ周回カウンタ２３１２、ＲＰ周回カウンタ２３１３、無効化フラグ２３１４、キューサイズ変更完了フラグ２３１１にそれぞれ‘０’を設定する。これにより、出力フレームバッファ制御部１７は、ＷＰ周回カウンタ２３１２、ＲＰ周回カウンタ２３１３、無効化フラグ２３１４、キューサイズ変更完了フラグ２３１１がそれぞれ‘０’であることから、キューサイズの変更処理が必要である事を認識し、上記フローチャートに従って、キューサイズの更新を行う。ここで、バンクの増減設は、リンクドリストバッファの末尾から行うことが必須であり、さらに先頭バンクアドレス２３０２を含んではならない。

本発明は、パケット通信システムに関し、特にユーザ拠点に設置されるアクセス装置の遠隔制御を行う際の制御経路冗長化が可能なパケット通信装置として有用である。

１０…ネットワークインタフェースボード（ＮＩＦ）
１１…入出力回線ＩＦ（ポート）
１２…入出力ヘッダ処理部
１３…入力フレームバッファ制御部
１４…ＳＷ ＩＦ
１５…フレーム中継部
１６…出力ヘッダ処理部
１７…出力フレームバッファ制御部
１７１…バッファ書込み処理部
１７２…バッファ読出し処理部
１７３…帯域管理部
１７３１…フレーム出力リスト
１８…ＮＩＦ管理部
１９…入力フレームバッファ
２０…出力フレームバッファ
２００、２０００…フレームバッファ
２１…ヘッダ処理テーブル
２２…ヘッダ変換テーブル
２３…キュー管理テーブル
２３０４…運用キューサイズ
２３０５…更新キューサイズ
２４…チェーンテーブル
２５…帯域管理テーブル
２４０２…運用次バンクアドレス
２４０３…更新次バンクアドレス
４０…入力フレーム
４１…装置内ヘッダ。

Claims (15)

1. リンクドリスト方式のバッファを有するパケット通信装置におけるバッファ管理方法であって、
   前記パケット通信装置は、
   各ユーザフローに対しするリンクドリストバッファを構成するためのチェーン情報とバッファサイズ情報を運用時の領域と更新用の領域の２つの領域で保持し、
   前記リンクドリストバッファをリードライトするためのライトポインタ及びリードポインタが前記リンクドリストバッファを巡回したことを示す巡回情報を保持しており、
   通常運用中は前記運用時の領域の前記チェーン情報と前記バッファサイズ情報を用いて前記リンクドリストバッファを構築して、前記ユーザフローのフレームを前記リンクドリストバッファにリードライトし、
   前記更新用の領域の前記チェーン情報と前記バッファサイズ情報が変更されると、前記巡回情報が、前記リードポインタ、前記ライトポインタそれぞれが前記リンクドリストバッファの先頭に戻ったことを示した場合、前記更新用の領域の変更された前記チェーン情報と前記バッファサイズ情報を、前記運用中の領域に反映してキューサイズを更新する、
   ことを特徴とするバッファ管理方法。
2. 請求項１に記載のバッファ管理方法であって、
   前記パケット通信装置は、
   前記リンクドリストバッファに格納されている前記フレームが無くなったことを契機に、
   前記更新用の領域の変更された前記チェーン情報と前記バッファサイズ情報を前記運用中の領域へ反映し、前記キューサイズを更新する、
   ことを特徴とするバッファ管理方法。
3. 請求項１に記載のバッファ管理方法であって、
   前記パケット通信装置は、
   前記更新用の領域の前記チェーン情報と前記バッファサイズ情報が変更されると、前記巡回情報が示す巡回の回数に依存して、前記チェーン情報の更新、あるいは前記リンクドリストバッファの削除されたバッファ領域の無効化の処理を行う、
   ことを特徴とするバッファ管理方法。
4. 請求項１記載のバッファ管理方法であって、
   前記パケット通信装置は、
   前記キューサイズの更新が前記キューサイズの削減の場合に、前記キューサイズが更新される前のバッファオーバフロー判定に、変更された前記チェーン情報を使用する、
   ことを特徴とするバッファ管理方法。
5. 請求項３に記載のバッファ管理方法であって、
   前記パケット通信装置は、
   前記リンクドリストバッファの使用中を示す使用中フラグを保持し、無効化された前記バッファ領域に対応する前記使用中フラグを変更する、
   ことを特徴とするバッファ管理方法。
6. リンクドリスト方式によるバッファを有し、ユーザフローに対してリンクドリストバッファを構成して前記ユーザフローを処理するパケット通信装置であって、
   処理部と記憶部とインタフェース部とを備え、
   前記記憶部は、
   前記インタフェース部からの前記ユーザフロー各々に対して前記リンクドリストバッファを構成するためのチェーン情報とバッファサイズ情報をそれぞれ保持する運用時の領域と更新用の領域と、前記リンクドリストバッファをリードライトした結果、前記リンクドリストバッファを巡回したことを示す巡回情報を保持する領域とを有し、
   前記処理部は、
   通常運用中は前記運用時の領域の前記チェーン情報と前記バッファサイズ情報を用いて前記リンクドリストバッファを構築して、前記ユーザフローのフレームを前記リンクドリストバッファにリードライトし、
   前記更新用の領域の前記チェーン情報と前記バッファサイズ情報が変更されると、前記リンクドリストバッファのリードライトそれぞれが前記リンクドリストバッファの先頭に戻った場合に、前記更新用の領域の変更された前記チェーン情報と前記バッファサイズ情報を前記運用中の領域に書込む、
   ことを特徴とするパケット通信装置。
7. 請求項６記載のパケット通信装置において、
   前記処理部は、
   前記リンクドリストバッファに格納されている前記ユーザのフレームがなくなった場合に、前記更新用の領域の変更された前記チェーン情報とバッファサイズ情報を、前記運用中の領域に書込む、
   ことを特徴とするパケット通信装置。
8. 請求項６記載のパケット通信装置において、
   前記巡回情報は、前記リンクドリストバッファのリードライトの巡回回数を示し、
   前記処理部は、
   前記更新用の領域の前記チェーン情報と前記バッファサイズ情報が変更されると、前記巡回回数に基づき、前記チェーン情報の更新、あるいは前記リンクドリストバッファの削除されたバッファ領域の無効化の処理を行う、
   ことを特徴とするパケット通信装置。
9. 請求項６のパケット通信装置において、
   前記処理部は、
   前記更新用の領域の更新された前記チェーン情報とバッファサイズ情報の前記運用中の領域への書込みにより、キューサイズが減設された場合に、前記キューサイズが減設される前のバッファオーバフロー判定に、変更された前記チェーン情報を使用する、
   ことを特徴とするパケット通信装置。
10. 請求項８のパケット通信装置において、
    前記処理部は、
    前記リンクドリストバッファの使用中を示すフラグを保持し、無効化された前記バッファ領域に対応する前記フラグを変更するよう制御する、
    ことを特徴とするパケット通信装置。
11. 各ユーザフローのフレームを順次、出力フレームバッファに書込み読出す出力フレームバッファ制御部と記憶部とを備えるパケット通信装置であって、
    前記記憶部は、
    前記出力フレームバッファに前記ユーザフロー各々に対してリンクドリストバッファを構成するため、運用時用および更新用のチェーン情報を保持するチェーンテーブルと、運用時用および更新用のバッファサイズ情報と前記リンクドリストバッファをリードライトするためのライトポインタおよびリードポインタが前記リンクドリストバッファを巡回したことを示す巡回情報とを保持するキュー管理テーブルとを記憶し、
    前記出力フレームバッファ制御部は、
    通常運用中は前記運用時用の前記チェーン情報と前記バッファサイズ情報を用いて前記リンクドリストバッファを構築することにより、前記ユーザフローのフレームを前記リンクドリストバッファにリードライトし、
    前記更新用の前記チェーン情報と前記バッファサイズ情報が変更された場合、前記巡回情報に基づき、前記ライトポインタおよび前記リードポインタそれぞれが前記リンクドリストバッファの先頭に戻ったことを検出したことを契機に、前記更新用の前記チェーン情報と前記バッファサイズ情報を前記運用時用の前記チェーン情報と前記バッファサイズ情報として、キューサイズを変更する、
    ことを特徴とするパケット通信装置。
12. 請求項１１記載のパケット通信装置において、
    前記出力フレームバッファ制御部は、
    前記リンクドリストバッファに格納されている前記ユーザフローのフレームがなくなった場合に、前記更新用の領域の前記チェーン情報と前記バッファサイズ情報を前記運用中用の前記チェーン情報と前記バッファサイズ情報として、前記キューサイズを変更する、
    ことを特徴とするパケット通信装置。
13. 請求項１１記載のパケット通信装置において、
    前記巡回情報は前記ライトポインタおよび前記リードポインタの巡回回数であり、
    前記出力フレームバッファ制御部は、
    前記更新用の前記チェーン情報と前記バッファサイズ情報それぞれが変更され場合、前記巡回回数に基づき、前記運用中用の前記チェーン情報及び前記バッファサイズ情報の更新処理、あるいは前記リンクドリストバッファから削除されたバッファ領域の無効化処理を行う、
    ことを特徴とするパケット通信装置。
14. 請求項１１記載のパケット通信装置であって、
    前記出力フレームバッファ制御部は、
    前記キューサイズが減設された場合に、前記キューサイズが変更される前のバッファオーバフロー判定に、前記更新用に更新された前記チェーン情報を使用する、
    ことを特徴とするパケット通信装置。
15. 請求項１３記載のパケット通信装置であって、
    前記記憶部に記憶された前記チェーンテーブルは、前記リンクドリストバッファの前記バッファ領域の使用中か否かを示す使用中フラグを保持し、
    前記出力フレームバッファ制御部は、
    無効化された前記バッファ領域に対応する前記使用中フラグを変更するよう制御する、
    ことを特徴とするパケット通信装置。

Images