(57)【要約】【課題】  本発明は他装置とのバッファ共有方法及び装置に関し、装置交換することなしにフレームバッファメモリの拡張が可能な他装置とのバッファ共有方法及び装置を提供することを目的としている。【解決手段】  フレームを受信する受信部２と、フレームを一時的に記憶するフレームバッファ１と、フレームを格納したフレームバッファ３のポインタを管理するバッファポインタ管理部３と、フレームヘッダからフレームの送信先を求めるプロトコル処理部４と、前記プロトコル処理部４及び送信部６への優先制御を行なうためのキューイング機能を持つＱoＳスケジューラ部５と、フレーム送信を行なう送信部６と、前記プロトコル処理部４と接続され、フレーム回避テーブルを記憶するアドレステーブル７と、前記プロトコル処理部４に対してテーブル書き換えモードのオン／オフを制御するフレーム回避管理部８と、を具備して構成される【選択図】    図３
2005210385.tif 000002
【特許請求の範囲】
【請求項１】
通常時に自装置のポートＡで受信されたフレームがポートＢから送信されている状態で、輻輳が発生してフレームバッファメモリの残量が所定の閾値より少なくなった場合、特定のＶＬＡＮ  タグを挿入してポートＣの他装置宛に変更してフレームを送信すると共に、フレーム回避先装置宛にポーズフレームを送信し（ステップ１）、
自装置のフレームバッファメモリの残量が閾値よりも多くなった場合、輻輳を解除し、輻輳元のポーズフレームを解除し、他装置に預けたフレームを受信し、フレーム回避前にフレームバッファメモリに保持されていたフレームを送信終了した後に、前記回避していたフレームのタグを解除し、本来送信されるポートＢ宛てに送信する（ステップ２）
ことを特徴とする他装置とのバッファ共有方法。
【請求項２】
フレームを受信し、ポインタの割り当てを行なう受信部と、
フレームを一時的に記憶するフレームバッファメモリと、
フレームを格納したフレームバッファメモリのポインタを管理するバッファポインタ管理部と、
フレームヘッダからフレームの送信先を求めるプロトコル処理部と、
前記プロトコル処理部及び送信部への優先制御を行なうためのキューイング機能を持つＱoＳスケジューラ部と、
フレームヘッダの書き替え及びフレーム送信及びポーズフレームの送信を行なう送信部と、
前記プロトコル処理部と接続され、少なくともフレーム回避テーブルを記憶するアドレステーブルと、
前記送信部に対してポーズフレーム送信を命令する他、前記プロトコル処理部に対してテーブル書き換えモードのオン／オフを制御するフレーム回避管理部と、
を具備して構成される他装置とのバッファ共有装置。
【請求項３】
前記プロトコル処理部は、自装置に戻ってきたフレームからＶＬＡＮ  タグを削除し、ＶＬＡＮタグが削除されたフレームを前記送信部から本来の装置宛に送信することを特徴とする請求項２記載の他装置とのバッファ共有装置。
【請求項４】
現用系装置と待機系装置との台数の比率がＭ：Ｎ（Ｍ，Ｎは整数）の構成において、回避先として設定された送信ポートの中でポーズフレームを受信していないポートの内、ポート番号が一番若いポートに送信することを特徴とする請求項２記載の他装置とのバッファ共有装置。
【請求項５】
前記プロトコル処理部のプロトコル識別によって、フレームの回避可／不可を選択可能とすることを特徴とする請求項２記載のバッファ共有装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は他装置とのバッファ共有方法及び装置に関し、更に詳しくは受信したデータを一時的にバッファに格納してから送信する、ストア＆フォワード方式の伝送装置の電送方法に関する。特に、コールドスタンバイタイプの多重化構成ネットワークにおいて、待機系のバッファメモリをフルに利用可能とすることが可能な他装置とのバッファ共有方法及び装置に関する。ここで、コールドスタンバイとは、二重化された装置であって、その一方の装置にデータが格納されていても他方の装置はデータを格納せず、一方の装置から動作開始指示があって初めてデータの格納を開始するようにしたシステムのことをいう。
【背景技術】
【０００２】
データ伝送システムでは、データ送信側とデータ受信側とのデータ伝送速度の差を調整するためにバッファメモリ（以下単にバッファという）が設けられるのが通常である。従来のデータ伝送システムとしては、オンチップバスを用いたＬＳＩシステムにおいて、バス上の転送が、転送先のモジュールのバッファ状態ににより待たされることを防止するために、バス上に一時的に転送データを格納できる転送バッファを用いる技術が知られている（例えば特許文献１参照）
図１１は従来システムの概念図である。図において、１はデータ伝送装置、１ａは該データ伝送装置内に設けられたバッファメモリである。図では、＃１の伝送装置１から＃２の伝送装置１側にデータを伝送する場合を示している。＃１のデータ伝送装置１から送信されたフレームデータは一旦バッファメモリ１ａに格納される。そして、必要に応じてバッファメモリ１ａから読み出されて、次のデータ伝送装置にデータが伝送されるか、或いは当該伝送装置で出力される。
【特許文献１】国際公開番号ＷＯ００／５１００５号公報（図１及びその説明）
【発明の開示】
【発明が解決しようとする課題】
【０００３】
前述した従来の技術では、データ伝送先のデータ伝送装置１のバッファメモリ１ａが、ネットワークの輻輳等で一杯になると、以降は入力されてきたフレームを廃棄してしまう。このような不具合を防止するためにポーズフレームを用いたフロー制御が行なわれる。このフロー制御は、図１１に示すようにデータ伝送先側の＃２のデータ伝送装置１のバッファメモリ１ａが満杯になると、該＃２のデータ伝送装置１は、相手方の＃１のデータ伝送装置１に対してフレームデータの送信を停止するように依頼するポーズフレームを送出する。その間、送信元の＃１のデータ伝送装置１からのデータ伝送は停止される。
【０００４】
このように、従来の技術では、データ伝送先のバッファメモリが満杯になると、それ以降のフレームデータは廃棄されてしまう。また、フロー制御のためにポーズフレームを出すと、それ以降、そのポーズフレームを受けたデータ伝送装置からのデータは一切伝送されなくなり、ネットワークのパフォーマンスが低下してしまう。また、多重化構成時の待機系装置は、そのリソースが全く使用されないという問題がある。
【０００５】
企業・教育機関等のネットワーク装置においては、フレーム廃棄を起こさないような高信頼性が求められており、バッファメモリの大容量化が非常に重要である。フルワイヤー性能（装置に入力されたフレームデータを全部出力できる能力のこと）をサポートするネットワーク装置では、スループットの帯域に合わせたフレームバッファメモリ帯域が必要であるが、メモリインタフェースが高速になればなるほど、増設可能な設計とするのが困難になり、またメモリ価格も上昇する。バッファメモリが増設不可能として設計された装置では、メモリ容量を増やそうとすると、装置交換しか方法がなく、ユーザに大きなコスト負担を強いるものとなる。
【０００６】
本発明はこのような課題に鑑みてなされたものであって、装置交換することなしにフレームバッファメモリ（フレームデータを一時的に保持するバッファメモリのこと）の拡張が可能な他装置とのバッファ共有方法及び装置を提供することを目的としている。
【課題を解決するための手段】
【０００７】
（１）請求項１記載の発明は、以下の通りである。図１は本発明方法の原理ブロック図である。本発明は、通常時に自装置のポートＡで受信されたフレームがポートＢから送信されている状態で、輻輳が発生してフレームバッファメモリ残量が所定の閾値より少なくなった場合、特定のＶＬＡＮ  タグを挿入してポートＣの他装置宛に変更してフレームを送信すると共に、フレーム回避先装置宛にポーズフレームを送信し（ステップ１）、
輻輳が解除された場合、輻輳発生元のポーズフレームを解除し、自装置のフレームバッファメモリの残量が閾値よりも多くなった場合、他装置に預けたフレームを受信し、フレーム回避前にフレームバッファメモリに保持されていたフレームを送信終了した後に、前記回避していたフレームのタグを解除し、本来送信されるポートＢ宛てに送信することを特徴とする
（２）請求項２記載の発明は、フレームを受信し、ポインタの割り当てを行なう受信部と、フレームを一時的に記憶するフレームバッファメモリと、フレームを格納したフレームバッファメモリのポインタを管理するバッファポインタ管理部と、フレームヘッダからフレームの送信先を求めるプロトコル処理部と、前記プロトコル処理部及び送信部への優先制御を行なうためのキューイング機能を持つＱoＳスケジューラ部と、フレームヘッダの書き替え及びフレーム送信及びポーズフレームの送信を行なう送信部と、前記プロトコル処理部と接続され、少なくともフレーム回避テーブルを記憶するアドレステーブルと、前記送信部に対してポーズフレーム送信を命令する他、前記プロトコル処理部に対してテーブル書き換えモードのオン／オフを制御するフレーム回避管理部と、を具備して構成されることを特徴としている。
（３）請求項３記載の発明は、前記プロトコル処理部４は、自装置に戻ってきたフレームからＶＬＡＮ  タグを削除し、ＶＬＡＮタグが削除されたフレームを前記送信部６から本来の装置宛に送信することを特徴とする。
（４）請求項４記載の発明は、現用系装置と待機系装置との台数の比率がＭ：Ｎ（Ｍ，Ｎは整数）の構成において、回避先として設定された送信ポートの中でポーズフレームを受信していないポートの内、ポート番号が一番若いポートに送信することを特徴とする。
（５）請求項５記載の発明は、この発明において、前記プロトコル処理部４のプロトコル識別によって、フレームの回避可／不可を選択可能とすることを特徴とする。
（６）また、この発明において、他装置に回避させたフレームとその前後のフレームのシーケンスを識別し、前記ＱoＳスケジューラ部５において、キュー毎に停止オン／オフフラグを持ち、フレームのシーケンスによってオン／オフを切り替えることを特徴とする。
【発明の効果】
【０００８】
（１）請求項１記載の発明によれば、装置交換することなしにフレームバッファメモリの拡張が可能な他装置とのバッファ共有方法を提供することができる。
（２）請求項２記載の発明によれば、装置交換することなしにフレームバッファメモリの拡張が可能な他装置とのバッファ共有装置を提供することができる。
（３）請求項３記載の発明によれば、回避先装置に退避されていたフレームを受けて、本来の装置宛にフレームを送信することができる。
（４）請求項４記載の発明によれば、回避先装置のポートの内、一番若い装置に送信することで、複数の回避先装置のフレームバッファメモリ（メモリバッファ）を全て活用可能になる。
（５）請求項５記載の発明によれば、プロトコル種別によっては、一定時間以上のフレーム遅延を許可しないようにすることができる。
（６）また、この発明によれば、ＱoＳスケジューラ部において、キュー毎に停止オン／オフフラグを持ち、フレームのシーケンスによってオン／オフを切り替えることができる。
【発明を実施するための最良の形態】
【０００９】
以下、図面を参照して本発明の実施の形態例を詳細に説明する。図２は輻輳発生時の本発明の動作フローの概念を示す図である。図において、１０は自装置、１１は他装置である。自装置１０及び他装置１１のバッファの使用量（網掛け部分）は、図に示すようなものであるものとする。
１．通常時
通常時には、ポートＡから入ってきたフレームは、ポートＢから送信される。バッファ使用量は、図に示すように少ない。
２．輻輳発生時
輻輳が発生して自装置１０の使用バッファ量が図に示すように満杯となったものとする。なお、本発明を適用するための閾値をバッファ使用量に対して設けておき、バッファフレーム残量が閾値よりも少なくなった時に、本発明を適用するようにしてもよい。この時、自装置１０はポートＣから他の装置１１にフレームを送信＋転送する（ポートＢ宛てで回避が許可されたフレームのみ）。同時に、自装置１０はループが形成されることを防止するため、他装置１１に対してポーズフレームを送信する。
【００１０】
この場合において、フレームを送信する際は、自装置に戻ってくるように設定がなされる。この設定は、特定のＶＬＡＮタグを挿入し、他装置に送信するように動的な定義変更がなされる。他装置１１では、その特定ＶＬＡＮタグ付きフレームは受信ポートと同じポートに戻すように設定される。また、ループが形成されることを防止するために、自装置１０から他装置１１に宛ててポーズフレームが送信される。これにより、他装置１１からフレームが自装置１０側に送信されることはなくなる（図示しない装置からもポートＢに対してポーズフレームが与えられる）。
３．輻輳解除後
この場合には、輻輳発生元のポーズフレーム解除に伴い、自装置にバッファリングされていたフレームがポートＢから送信される。そして、フレーム残量が閾値よりも少なくなった場合、他装置宛のポーズフレームを解除する。そして、他装置１１から預けていたフレームを受信する。そして、フレーム回避前にバッファリングされていたフレームが送信し終わった後に、回避していたフレームのタグが解除され、本来送信されるポートＢ宛に送信する。最後に、他装置１１にフレームを回避させた以降に受信されたフレームを送信する。
【００１１】
このように構成すれば、装置交換することなしにフレームバッファメモリの拡張が可能な他装置とのバッファ共有方法を提供することができる。また、このように構成すれば、回避先装置に退避されていたフレームを受けて、本来の装置宛にフレームを送信することができる。
【００１２】
図３は本発明の一実施の形態例を示すブロック図である。図において、１はフレームを一時的に記憶するフレームバッファメモリ、２はフレームを受信し、ポインタの割り当てやポーズフレームの送信を行なう受信部、３はフレームを格納したフレームバッファメモリ１のポインタを管理するバッファポインタ管理部、４はフレームヘッダからフレームの送信先を求めるプロトコル処理部、５は前記プロトコル処理部４及び送信部６への優先制御を行なうためのキューイング機能を持つＱoＳスケジューラ部、６はフレームヘッダの書き替え及びフレーム送信を行なう送信部、７は前記プロトコル処理部４と接続され、少なくともフレーム回避テーブルを記憶するアドレステーブル、８は前記送信部６に対してポーズフレーム送信を命令する他、前記プロトコル処理部４に対してテーブル書き換えモードのオン／オフを制御するフレーム回避管理部である。
【００１３】
この図において、フレーム回避先となる待機系装置は２装置存在し、ポート８及び９の先に繋がっているものとする。また、輻輳の発生例として、ポート０先の装置において輻輳が発生し、受信部ポート０がポーズフレームを受信しているものとする。このように構成された装置の動作を説明すれば、以下の通りである。
【００１４】
図４はフレームバッファメモリとバッファポインタの関係を示す図である。図において、図３と同一のものは、同一の符号を付して示す。図において、２はバッファポインタ管理部３からの使用可能ポインタ割り当て信号を受けると共に入力フレームを受ける受信部、１はフレームを格納するフレームバッファメモリ、６はフレームバッファメモリ１からの送信先が決定されたフレームデータを受けて出力フレームを出力する送信部、３は送信部６からのフレーム出力後の空きポインタの返却信号を受けるバッファポインタ管理部である。このように構成された回路の動作を説明すれば、以下の通りである。
【００１５】
この図において、受信部２に入力したフレームはバッファポインタ管理部３から割り当てられたポインタアドレスを元にフレームバッファメモリ１に書き込まれる。また、送信部６からフレームが出力され、再び使用可能となるポインタがバッファポインタ管理部３に返却される。これにより、フレームバッファメモリ１の使用量は、ポインタ使用量としてバッファポインタ管理部３で管理される。
【００１６】
ここで、輻輳が発生し、フレームバッファメモリポインタ使用量（バッファメモリの使用量）が予め設定されている閾値を超えた場合、バッファポインタ管理部３からフレーム回避管理部８（図３参照）へ閾値オーバー情報が伝達される。
【００１７】
図５は輻輳発生時のフレーム回避管理部８の動作説明図である。図において、図３と同一のものは、同一の符号を付して示す。図において、３はバッファポインタ管理部、８はバッファポインタ管理部３からの閾値オーバー情報を受けるフレーム回避管理部、６はフレーム回避管理部８からのフレーム回避先待機系へポーズフレーム送信要求を受ける送信部、４はフレーム回避管理部８からのフレーム回避テーブル書き換え、フレーム回避検索モードオン信号を受けるプロトコル処理部、７は該プロトコル処理部４からのフレーム回避テーブル書き換え信号を受けるアドレステーブルである。このように構成された回路の動作を説明すれば、以下の通りである。
【００１８】
フレーム回避管理部８は、バッファポインタ管理部３からの閾値オーバー情報を受け取ると、予め設定されているフレーム回避テーブル（詳細後述）と共に、プロトコル処理部４へフレーム回避検索モードオン指示とフレーム回避テーブル書き換えを通知し、テーブルの書き換えが行なわれ、フレーム回避テーブルの検索が有効となる。
【００１９】
ＱｏＳ（Ｑｕａｌｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）制御を有する本装置において、通常ＩＰｖ４（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ  ｖｅｒｓｉｏｎ４）フレームは、ＩＰｖ４ルーティング検索（何処のポートに送信するかの宛先検索）及びＩＰｖ４キュー検索（各々優先制御付けされている何処のキューにエンキューするかの検索）が行なわれるが、フレーム回避モードオンの場合、更にテーブル回避テーブル検索が追加される。
【００２０】
図６は回避モードオフ時（通常時）のＩＰｖ４フレームによるプロトコル処理部検索例を示す図である。図において、２０はＩＰｖ４ルーティングテーブル、２１はＩＰｖ４キューテーブルである。これらテーブルは、アドレステーブル７に格納される。ＩＰｖ４ルーティングテーブル２０は検索キーと検索結果から構成されている。検索キーはＩＰ  ＤＡに対応し、検索結果は送信ポートに対応する。ＩＰｖ４キューテーブル２１は検索キーと検索結果から構成されている。検索キーは、プロトコルと、ＴＣＰ／ＵＤＰ  ＳＰと、ＴＣＰ／ＵＤＰ  ＤＰと、ＩＰ  ＳＡと、ＩＰ  ＤＡとから構成されている。検索結果はキュー番号に対応している。
【００２１】
通常時、フレームはルーティングテーブル２０とキューテーブル２１を検索し、検索結果の送信ポート宛として検索結果のキュー番号にキューイングされる。この例では、送信ポート宛のフレームがキュー番号３，４にキューイングされる。
【００２２】
図７は回避モードオン時（輻輳発生時）のＩＰｖ４フレームによるプロトコル処理部検索例を示す図である。図において、２０はＩＰｖ４ルーティングテーブル、２１はＩＰｖ４キューテーブル、２２はフレーム回避テーブルである。ＩＰｖ４ルーティングテーブル２０とＩＰｖ４キューテーブル２１は図６に示すものと同じである。フレーム回避テーブル２２は、検索キーと検索結果からなる。検索キーは、送信ポートとキュー番号とから構成され、検索結果は送信ポートと送信ＶＩＤとから構成される。
【００２３】
図６，図７において、ＩＰ  ＳＡは送信元ＩＰアドレス、ＩＰ  ＤＡは宛先ＩＰアドレス、ＴＣＰ／ＵＤＰ  ＳＰはＴＣＰ／ＵＤＰ送信元ポート番号、ＴＣＰ／ＵＤＰ  ＤＰはＴＣＰ／ＵＤＰ宛先ポート番号、キュー番号は優先制御用のキュー番号である。送信ＶＩＤは回避フレームに付加するＶＬＡＮ  ＩＤである。
【００２４】
図６，図７において、通常時はＩＰ  ＤＡを検索キーとして宛先（送信ポート）が検索され、さらにフレーム送信の優先制御を行なうためのプロトコル種別、ＴＣＰ／ＵＤＰの受信、送信ポート番号等から、エンキュー先の検索が行なわれる。これに輻輳が発生してフレーム回避モードがオンとなる。更に、フレーム回避テーブル２２も検索され、対象フレームのみ送信ポートの再検索が行なわれる。
【００２５】
これによって、回避モードオン以降の送信ポート０宛の特定のフレームはプロトコル処理部４で宛先検索された結果、待機系のポート９宛＋ＶＬＡＮ  Ｔａｇ（ＶＩＤ＝４００１）が付加される。特定のフレームとは、フレーム回避テーブル２２においてキュー番号により特定可能であるので、その前段の検索であるＩＰｖ４キューテーブル２１によって識別可能なフレーム種別は全て、回避可能／不可能を選択可能となる。
【００２６】
また、本発明では回避先装置は複数装置をサポートするが、その選択はポーズフレームを受信していないポートの内、ポート番号が最も若いポートに送信する。図５のフレーム回避管理部８中のフレーム回避テーブルデータに登録されている回避先送信ポートは、待機系装置の８，９であり、その両ポートからポーズフレームを受信していない（待機系装置のバッファに余裕がある）場合は、ポート番号の若い８がフレーム回避先となり、ポート８からポーズフレームを受信している回避先をポート９に変更する。このようにすれば、回避先装置のフレームバッファメモリを全て活用可能になる。
【００２７】
更に、両待機系装置からポーズフレームを受信している場合は、回避先無しとしてフレーム回避テーブル２２が空きとなり、回避モードがオンであっても回避テーブル検索にヒットしないので、フレームは回避されない。
【００２８】
更に、フレームのループ防止のため、同時にフレーム回避管理部８から送信部６へポーズフレーム送信要求が送られ、送信部６側のポート８からポーズフレームを送信する。
【００２９】
回避先の待機系装置の設定は、現用系から特定ＶＬＡＮ  Ｔａｇフレームを受信した場合、送信元へリダイレクトするように設定するだけで、特別な機能は必要としない。これにより、現用系：待機系＝Ｎ：１のように、回避元装置が複数存在することをサポートする。このようにすれば、回避先装置のフレームバッファメモリを全て使用可能になる。
【００３０】
ポート０先の装置の輻輳解除後、受信部２のポート０のポーズフレーム受信が停止すると、フレーム回避モードがオンになる前にフレームバッファメモリ１に蓄積されていたポート０宛フレームの送信が再開される。ポート０宛のフレームが疎通し始めることにより、フレームバッファメモリ１を占有していたポート０宛のバッファポインタが解放されていき、ポインタ使用量閾値をアンダーする。
【００３１】
図８，図９はそれ以後のフレーム回避管理部８及びＱｏＳスケジューラ部５の動作を示す図である。図８は輻輳解除時のフレーム回避管理部８の動作説明図、図９はＱｏＳスケジューラの動作説明図である。図９の上図はＱｏＳスケジューラの通常動作、下図は回避フレーム受付時のＱｏＳスケジューラの動作を示している。
【００３２】
図９の上図はＱｏＳスケジューラ部５の動作を示しているが、本発明ではフレームシーケンスを保証するため（回避させたフレームを追い越さないように）通常ルート（受信したフレームをそのまま送信）とフレーム回避先から送信する場合で使用するキューを独立させることとする（図９の下図）。
【００３３】
図９において、通常のＱｏＳスケジューラ部の動作は、プロトコル処理部４で検索されたキュー番号にそのフレームのポインタをエンキューする。各キューは、送信の優先度付けされている。送信部６では、優先度処理されたポインタを送信部６宛にデキューする。一方、回避フレーム受付時のＱｏＳスケジューラ部の動作は、各キューにおいて、通常時のキューと回避先から戻ってきたフレームのキューがある時、キューＮｏ．ｂがエンキューされている間は、キューＮｏ．ａはデキュー停止とする。
【００３４】
フレーム回避モードがオフとなるバッファポインタ使用量の閾値をアンダーすると（図８のＣ１）、これを契機にＱｏＳスケジューラ部５の、フレーム回避に切り替わる前のキュー（ポート０宛でフレーム回避可のキュー、図ではＮｏ．ａ）の状態を監視する（図８のＣ２）。回避が始まる前のフレームが全て送信され、キューＮｏ．ａが空になると、
・キューＮｏ．ａのデキュー停止（回避させたフレームをそれ以後のフレームが追い越さないため）
・プロトコル処理部４へフレーム回避検索モードの停止指示
・ポーズフレームの停止要求（回避させていたフレームの受信）
が実行される（図８のＣ３，Ｃ４，Ｃ５）
回避させたＶＩＤ＝４００１のＶＬＡＮ  Ｔａｇ付フレームは、プロトコル処理部４においてＶＬＡＮ  Ｔａｇが削除され、送信元は本来送信されるポート０宛、エンキュー先はキューＮｏ．ｂとする。次に、キューＮｏ．ｂの監視を始め、回避フレームが全て送信され、キューＮｏ．ｂが空になることを確認（図８のＣ６）後、キューＮｏ．ａでのデキューを再開する（図８のＣ７）。
【００３５】
以上の動作により、
１．輻輳発生後のバッファに蓄積されたフレーム
２．他装置に回避させたフレーム
３．フレーム回避後に装置に入ってきたフレーム
のフレームシーケンスを保証する。回避させていたフレームを全て送信終了後の状態をもって通常状態とする。この形態例によれば、ＱｏＳスケジューラ部において、キュー毎に停止オン／オフフラグを持ち、フレームのシーケンスによってオン／オフを切り替えることができる。
【００３６】
また、本発明によれば、プロトコル処理部４のプロトコル識別によって、フレームの回避可／不可を選択可能とすることができる。これによれば、プロトコル種別によっては、一定時間以上のフレーム遅延を許可しないようにすることができる。
【００３７】
図１０は装置内のフレームフロー例を示す図である。破線より左側は通常動作、右側はバッファメモリ閾値オーバーの場合の動作を示す。先ず、受信部２でフレームを受信する（Ｓ１）。次に、受信部２で受信したフレームをフレームバッファメモリ１に格納する（Ｓ２）。次に、フレームバッファメモリ１からヘッダ情報をプロトコル処理部４に通知する（Ｓ３）。
【００３８】
次に、プロトコル処理部４はフレーム回避モードがオンであるかどうかチェックする（Ｓ４）。フレーム回避モードがオンである場合には、プロトコル処理部４で通常検索、フレーム回避テーブル２２を検索する（Ｓ５）。次に、回避可フレーム種別をチェックする（Ｓ６）。回避可の場合は、送信ポートを指定してＶＬＡＮＴａｇ情報を送信部６へ送信する（Ｓ７）。そして、送信部６より所定のポートからフレームを送信する（Ｓ８）。
【００３９】
ステップＳ４において、フレーム回避モードがオンでない場合（通常動作の場合）、プロトコル処理部４で通常検索を行なう（Ｓ９）。次に、ＱｏＳスケジューラ部５でデキュー停止であるかどうかチェックする（Ｓ１０）。ステップＳ６で回避不可の場合もステップＳ１０に入る。ステップＳ１０でデキュー停止状態が解除された場合には、送信ポートを指定し、ヘッダ書き替え情報を送信部６に通知する（Ｓ１１）。そして、送信部６より所定のポートからフレーム送信を行なう（Ｓ１２）。
【００４０】
以上、詳細に説明したように、本発明によれば、装置交換すること無しにフレームバッファメモリの拡張が可能となり、システムのパフォーマンスの向上が可能となる。また、その適用例としてコールドスタンバイの多重化構成を挙げたが、この構成では待機系のフレームバッファメモリはまったく使用されておらず、現用系と待機系間のネットワーク帯域も使用されていないことから、フレーム回避の効果的な運用を行なうことができる。また、多重化構成時の待機系装置が実際に稼働する例は、現用系の障害発生時とメンテナンス時しか存在せず、トータルの運用期間から見ると非常に少なく、待機系装置を有効に活用することが可能となる。
【００４１】
（付記１）  通常時に自装置のポートＡで受信されたフレームがポートＢから送信されている状態で、輻輳が発生してフレームバッファメモリの残量が所定の閾値より少なくなった場合、特定のＶＬＡＮ  タグを挿入してポートＣの他装置宛に変更してフレームを送信すると共に、フレーム回避先装置宛にポーズフレームを送信し（ステップ１）、
自装置のフレームバッファメモリの残量が閾値よりも多くなった場合、輻輳を解除し、輻輳元のポーズフレームを解除し、他装置に預けたフレームを受信し、フレーム回避前にフレームバッファメモリに保持されていたフレームを送信終了した後に、前記回避していたフレームのタグを解除し、本来送信されるポートＢ宛てに送信する（ステップ２）
ことを特徴とする他装置とのバッファ共有方法。
【００４２】
（付記２）  フレームを一時的に記憶するフレームバッファメモリと、
フレームを受信し、ポインタの割り当てを行なう受信部と、
フレームを格納したフレームバッファメモリのポインタを管理するバッファポインタ管理部と、
フレームヘッダからフレームの送信先を求めるプロトコル処理部と、
前記プロトコル処理部及び送信部への優先制御を行なうためのキューイング機能を持つＱoＳスケジューラ部と、
フレームヘッダの書き替え及びフレーム送信及びポーズフレームの送信を行なう送信部と、
前記プロトコル処理部と接続され、少なくともフレーム回避テーブルを記憶するアドレステーブルと、
前記受信部に対してポーズフレーム送信を命令する他、前記プロトコル処理部に対してテーブル書き換えモードのオン／オフを制御するフレーム回避管理部と、
を具備して構成される他装置とのバッファ共有装置。
【００４３】
（付記３）  前記プロトコル処理部は、自装置に戻ってきたフレームからＶＬＡＮ  タグを削除し、ＶＬＡＮタグが削除されたフレームを前記送信部から本来の装置宛に送信することを特徴とする付記２記載の他装置とのバッファ共有装置。
【００４４】
（付記４）  現用系装置と待機系装置との台数の比率がＭ：Ｎ（Ｍ，Ｎは整数）の構成において、回避先として設定された送信ポートの中でポーズフレームを受信していないポートの内、ポート番号が一番若いポートに送信することを特徴とする付記２記載の他装置とのバッファ共有装置。
【００４５】
（付記５）  前記プロトコル処理部のプロトコル識別によって、フレームの回避可／不可を選択可能とすることを特徴とする付記２記載のバッファ共有装置。
【００４６】
（付記６）  他装置に回避させたフレームとその前後のフレームのシーケンスを識別し、前記ＱoＳスケジューラにおいて、キュー毎に停止オン／オフフラグを持ち、フレームのシーケンスによってオン／オフを切り替えることを特徴とする付記２記載の他装置とのバッファ共有装置。
【図面の簡単な説明】
【００４７】
【図１】本発明方法の原理を示すフローチャートである。
【図２】輻輳発生時の本発明の動作フローの概念を示す図である。
【図３】本発明の一実施の形態例を示すブロック図である。
【図４】フレームバッファメモリとバッファポインタの関係を示す図である。
【図５】輻輳発生時のフレーム回避管理部の動作説明図である。
【図６】回避モードオフ時（通常時）のＩＰｖ４フレームによるプロトコル処理部検索例を示す図である。
【図７】回避モードオン（輻輳発生時）時のＩＰｖ４フレームによるプロトコル処理部検索例を示す図である。
【図８】輻輳解除時のフレーム回避管理部の動作説明図である。
【図９】ＱｏＳスケジューラの動作説明図である。
【図１０】装置内のフレームフロー例を示す図である。
【図１１】従来システムの概念図である。
【符号の説明】
【００４８】
１  フレームバッファメモリ
２  受信部
３  バッファポインタ管理部
４  プロトコル処理部
５  ＱｏＳスケジューラ部
６  送信部
７  アドレステーブル
８  フレーム回避管理部
【図１】
2005210385.tif 000003
【図２】
2005210385.tif 000004
【図３】
2005210385.tif 000005
【図４】
2005210385.tif 000006
【図５】
2005210385.tif 000007
【図６】
2005210385.tif 000008
【図７】
2005210385.tif 000009
【図８】
2005210385.tif 000010
【図９】
2005210385.tif 000011
【図１０】
2005210385.tif 000012
【図１１】
2005210385.tif 000013