JP4269176B2 - セッション中継装置及び中継方法 - Google Patents

Description

本発明はセッション中継装置及びそれに用いるセッション中継方法に関し、特にＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）セッション間でデータの中継を行う装置に関する。

一般的に、通信アプリケーションにおいては、送信端末と受信端末との間で通信セッションを確立し、確立したセッション上で通信を行う。しかしながら、送信端末と受信端末との間の伝播遅延時間が非常に長い場合、もしくは有線と無線とのように特性の異なるネットワークを横断して通信する場合には、送信端末と受信端末との間の通信のスループットが低下する。

この問題を解決するための方法としては、下記の文献１〜３に開示されているような方式が存在する。この方式では、送信端末と受信端末との間を一つのセッションで通信を行うのではなく、送信端末と受信端末との間に中継装置を設置する。そして、送信端末から中継装置へのセッションと中継装置から受信端末へのセッションの２つのセッション間でデータの中継を行うことによって通信が行われる。

［文献１］特開平１１−２５２１７９号公報
［文献２］特開２００２−２８１１０４号公報
［文献３］ｊａｙ Ｂａｋｒｅ ａｎｄ Ｂ．Ｒ．Ｂａｄｒｉｎａｔｈ，“Ｉ−ＴＣＰ；Ｉｎｄｉｒｅｃｔ ＴＣＰ ｆｏｒ Ｍｏｂｉｌｅ Ｈｏｓｔ”，Ｄｅｐａｒｔｍｅｎｔ ｏｆ Ｃｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅ Ｒｕｔｇｅｒｓ Ｕｎｉｖｅｒｓｉｔｙ，ＤＳＣ−ＴＲ−３１４，１９９４（ｈｔｔｐ：／／ｗｗｗ．ｉｔ．ｉｉｔｂ．ａｃ．ｉｎ／ｉｔ６４４／ｐａｐｅｒｓ／ｉ−ｔｃｐ．ｐｄｆ）
中継装置においては、伝播遅延時間が非常に長い場合でもスループットを低下させないために、大きな送信バッファを持つことが有効であることが知られている。しかしながら、大きな送信バッファを持った場合、特にＴＣＰのスロースタート（Ｓｌｏｗ Ｓｔａｒｔ）時において、パケットがバースト的に出力されるためにネットワークの輻輳を発生させ、結果としてスループットの低下を招く場合がある。

このような問題を解決する方法としては、下記の文献４に開示されているような、ＴＣＰセッションからバースト的にパケットを出力しないように出力するパケットの間隔を調整する方法がある。

［文献４］Ａ．Ａａｇａｒｗａｌ，Ｓ．Ｓａｖａｇｅ，ａｎｄ Ｔ．Ａｎｄｅｒｓｏｎ．“Ｕｎｄｅｒｓｔａｎｄｉｎｇ ｔｈｅ Ｐｅｒｆｏｒｍａｎｃｅ ｏｆ ＴＣＰ Ｐａｃｉｎｇ”，ｉｎ ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ＩＥＥＥ ＩＮＦＯＣＯＭ´２０００
また、他の方法としては、ＴＣＰセッションからの出力パケットをキューイングしてスケジューラで出力制御を行うことによって、任意の帯域でのパケット出力が可能となり、他のＴＣＰセッションのスループットを制限し、特定のセッションのスループットを向上させることも可能である。

セッションの中継を行う場合、最も問題となることは、一般的にＴＣＰセッションの処理において処理負荷が高く、高速な中継処理が難しいという問題がある。また、ＴＣＰセッションからのパケット出力間隔を調整する場合には、処理負荷がさらに高くなる。

上記のＴＣＰセッションの処理を高速化する方式としては、以下に示すような方式が存在する。第１の方式としては、ＯＳ（Ｏｐｅｒａｔｉｏｎ Ｓｙｓｔｅｍ）のカーネルとアプリケーションプログラムとの間のデータ転送にゼロコピー方式を用いることによって、中継装置の処理負荷を下げる方式がある。この第１の方式では、実際にデータの送受信処理を行うカーネルプログラムと、データの中継処理を行うアプリケーションプログラムとの間で、データの受け渡しを行う際、物理的なデータのコピーを行わず、ページマッピングによる仮想的なデータの移動を行う。

第２の方式としては、中継処理を行う際、再送制御のみを行う方式がある。この第２の方式では、中継装置でセッションの終端を行わず、送受信端末間で１本のセッションを設定する。そして、中継装置においては送信端末から受信したパケットを受信端末へと出力する際、単にパケットを転送するだけでなく、パケットを中継装置内に保存しておく。

中継装置では受信端末から送信端末に返されるＡＣＫ（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）パケットを監視し、もし中継装置と受信端末との間でパケット廃棄を検出すると、保存しておいたパケットを受信端末に出力することで、送信端末からのパケットの再送を防ぎ、パケット廃棄による送信端末と受信端末との間のスループットの低下を防いでいる。

この第２の方式では、セッション間の中継処理を行わず、再送処理を行うのみであり、中継処理を行う場合に比べて中継装置の負荷を下げることができる。

第３の方式としては、中継の必要が無いセッションの中継処理を行わず、中継を行う必要があるセッションのみ中継処理を行うことで、中継装置の処理負荷を下げる方式がある。例えば、この方式としては、下記の文献５に開示されているような、セッションのスループットを計測し、中継処理を行うことで、スループットが向上するセッションのみを選択して中継処理を行う方式がある。

［文献５］特開平１１−１１２５７６号公報
また、上記の方式としては、下記の文献６に開示されているように、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）のリクエストを送信する際に中継処理を行わず、データ転送を行う際のみ中継処理を行う方式がある。

［文献６］特開２００２−３１２２６１号公報
上述した従来のセッション中継方式では、第１の方式の場合、データコピー以外の処理負荷も高いという問題がある。ＴＣＰ ｐａｃｉｎｇ方式やスケジューラによる出力制御を行う場合、ＴＣＰの処理負荷に加えて、パケット出力制御の負荷が加わるため、全体の処理負荷が高くなる。

また、ＴＣＰセッションの中継だけではなく、例えばｉＳＣＳＩ（ｉｎｔｅｒｎｅｔ Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）のような上位レイヤプロトコルの中継処理を行う場合、さらに上位レイヤでの輻輳制御に基づくパケット出力制御が加わり、さらに処理負荷が高くなる。特に、中継するセッション数が多い場合には、セッション間でパケットの出力制御を行う処理の負荷が高くなる。

さらに、従来のセッション中継方式では、第１の方式の場合、パケット長に制限があるという問題がある。ＴＣＰレイヤとアプリケーションとの間でページマッピングによる仮想的なデータの移動を行うためには、ＣＰＵ（中央処理装置）のページサイズとパケット長とが一致している必要がある。

一般的に、セッション中継装置は送受信端末とは独立して存在し、送信端末及び受信端末が用いるパケット長を予め想定しておくことはできないため、帯域制御装置のページサイズと異なるパケット長を用いる送信端末及び受信端末に対しては、ゼロコピーによる処理負荷低減が期待できない。

一方、従来のセッション中継方式では、第２の方式の場合、パケット廃棄以外の要因によるスループット低下を改善することができないという問題がある。セッションの中継処理を行う場合には、セッション中継装置では送信端末からのパケット受信に対してすぐさま送信端末に対して受信確認のためのＡＣＫパケットを返送するが、この第２の方式では受信端末が送信端末に対してＡＣＫパケットを返すのみであり、セッション中継装置自身はＡＣＫパケットを返さない。そのため、伝播遅延が大きな環境では第２の方式によるスループット向上の効果が小さい。

また、従来のセッション中継方式では、第３の方式の場合、中継する必要のあるセッション数が多い場合に処理負荷が軽減されないという問題がある。

そこで、本発明の目的は上記の問題点を解消し、中継するセッション数が多く、パケットの出力制御を行う場合でも、高速にセッション間の中継処理を行うことができるセッション中継装置及びそれに用いるセッション中継方法を提供することにある。

本発明による他のセッション中継装置は、送信端末に向けたセッションと受信端末に向けたセッションとの間でデータの中継を行うことで前記受信端末と前記受信端末との間の通信を実現するセッション中継装置であって、
前記送信端末に向けたセッションからのデータを受信する受信セッション処理手段と、前記受信端末に向けたセッションへとデータを送信する送信セッション処理手段と、前記送信端末へと出力するデータを一時蓄えておく送信バッファと、前記送信バッファからのパケット出力を制御するパケットスケジューラと、前記パケットスケジューラの制御に応答して前記送信バッファに蓄えられたデータを出力制御する出力制御手段とを備え、
前記送信セッション処理手段において当該レイヤで出力が許可されているデータ量を計算し、これに基づいて前記パケットスケジューラが前記パケット出力を制御している。

本発明のセッション中継装置は、送信端末に向けたセッションと受信端末に向けたセッションとの間でデータの中継を行うことで前記送信端末と前記受信端末との間の通信を実現するセッション中継装置において、
複数のレイヤに対応して設けられ、かつ、前記送信端末に向けたセッションからのデータを受信する受信セッション処理手段と、
複数のレイヤに対応して設けられ、かつ、前記受信端末に向けたセッションへとデータを送信する送信セッション処理手段と、
前記送信端末へと出力するデータを一時蓄えておく送信バッファと、
前記複数のレイヤのうちの１つのレイヤに対応して設けられ、前記送信バッファからのパケット出力を制御するパケットスケジューラと、
前記パケットスケジューラの制御に応答して前記送信バッファに蓄えられたデータを出力制御する出力制御手段とを有し、
前記パケットスケジューラが対応するレイヤとは異なる少なくとも１つのレイヤに対応して設けられた前記送信セッション処理手段が、出力が許可されているデータ量を計算し、これに基づいて前記パケットスケジューラが前記パケット出力を制御することを特徴とする。

本発明のセッション中継方法は、送信端末に向けたセッションと受信端末に向けたセッションとの間でデータの中継を行うことで前記送信端末と前記受信端末との間の通信を実現するセッション中継装置のセッション中継方法において、
前記セッション中継装置側で行われる、
複数のレイヤに対応して設けられた受信セッション処理手段が前記送信端末に向けたセッションからのデータを受信する受信セッションステップと、
複数のレイヤに対応して設けられた送信セッション処理手段が前記受信端末に向けたセッションへとデータを送信する送信セッションステップと、
前記送信端末へと出力するデータを送信バッファに一時蓄えておくステップと、
前記複数のレイヤのうち１つのレイヤに対応して設けられたパケットスケジューラが前記送信バッファからのパケット出力を制御するステップと、
前記パケットスケジューラの制御に応答して前記送信バッファに蓄えられたデータを出力制御手段にて出力制御するステップとを有し、
前記送信セッションステップにおいては、前記パケットスケジューラが対応するレイヤとは異なる少なくとも１つのレイヤに対応して設けられた前記送信セッション処理手段が、出力が許可されているデータ量を計算し、前記送信バッファからのパケット出力を制御するステップにおいては、該計算されたデータ量に基づいて前記パケットスケジューラが前記パケット出力を制御することを特徴とする。

本発明による別のセッション中継方法は、送信端末に向けたセッションと受信端末に向けたセッションとの間でデータの中継を行うことで前記送信端末と前記受信端末との間の通信を実現するセッション中継装置のセッション中継方法であって、前記セッション中継装置側に、複数のレイヤ各々において前記送信端末に向けたセッションからのデータを受信する受信セッション処理と、前記複数のレイヤ各々において前記受信端末に向けたセッションへとデータを送信する送信セッション処理と、前記送信端末へと出力するデータを送信バッファに一時蓄えておく処理と、前記送信バッファからのパケット出力をパケットスケジューラにて制御する処理とを備え、前記送信セッション処理各々において当該レイヤで出力が許可されているデータ量を計算し、前記複数のレイヤ全てで共通に許可されるデータ量に基づいて前記パケットスケジューラが前記パケット出力を制御している。

すなわち、本発明のセッション中継装置は、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）レイヤにおいてパケット出力の制御を行わず、ＴＣＰレイヤでパケット出力のための制御情報を生成するのみとし、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）レイヤにおいてパケットスケジューラを用いてパケット出力の制御を行う。

また、本発明のセッション中継装置では、ｉＳＣＳＩ（ｉｎｔｅｒｎｅｔ Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）のような上位レイヤプロトコルにおける輻輳制御に関しても、制御情報の作成のみを上位レイヤで行い、実際のパケット出力制御にはＩＰレイヤのパケットスケジューラを用いる。

これによって、本発明のセッション中継装置では、複数のレイヤにおけるデータ出力制御を統合することができるため、パケット出力に関する処理負荷を軽減することが可能となる。

さらに、本発明のセッション中継装置では、アプリケーションへのデータコピーを行わないため、ページマッピングによるデータの移動の必要がない。すなわち、受信パケットはＴＣＰレイヤやその他の上位レイヤ、アプリケーションの受信バッファに格納されることなく、またＴＣＰレイヤやその他の上位レイヤ、アプリケーションの送信バッファに格納に格納されることもなく、直接ＩＰレイヤの送信バッファに格納される。そのため、本発明のセッション中継装置では、セッション中継装置内のデータの移動は発生せず、ページマッピングによるデータの移動の必要がない。

さらにまた、本発明のセッション中継装置では、中継処理をパケットの再送制御にのみを行うのではなく、セッションを一旦終端して完全な中継処理を行っているため、パケット廃棄以外の要因によるスループット低下を改善することが可能となる。

本発明のセッション中継装置では、セッション間の中継処理を高速化することで、中継セッション数が多い場合でも高速に処理を行うことが可能となる。

図１は、本発明の第１の実施形態によるセッション中継装置を含む伝送システムの構成を示すブロック図である。 図２は、本発明の第１の実施形態によるセッション中継装置の構成を示すブロック図である。 図３は、図２のパケットスケジューラの構成を示すブロック図である。 図４は、本発明の第１の実施形態によるセッション中継装置の動作を示すフローチャートである。 図５は、本発明の第１の実施形態によるセッション中継装置の動作を示すフローチャートである。 図６は、図３に示すパケットスケジューラの動作を示すフローチャートである。 図７は、送信待ちバイト数を示す模式図である。 図８は、本発明の第２の実施形態によるパケットスケジューラの構成を示すブロック図である。 図９は、本発明の第３の実施形態によるセッション中継装置の構成を示すブロック図である。 図１０は、本発明の第４の実施形態によるセッション中継装置の構成を示すブロック図である。 図１１は、本発明の第４の実施形態における送信待ちバイト数を説明する模式図である。 図１２は、本発明の第５の実施形態によるセッション中継装置の構成を示すブロック図である。 図１３は、本発明の第５の実施形態によるセッション中継装置（送信端末）及びセッション中継装置（受信端末）の間のデータの流れを示すブロック図である。

次に、本発明の実施の形態について図面を参照して説明する。
（第１の実施形態）
図１は本発明の第１の実施形態によるセッション中継装置１を含む伝送システムの構成を示すブロック図である。図１において、本実施形態によるセッション中継装置１はセッション識別部１１と、セッション中継部１２−１〜１２−Ｎと、出力制御部１４とから構成され、受信端末２及び送信端末３に接続されている。

まず、送信端末３から受信端末２へデータを送る場合、送信端末３からのデータパケットはセッション中継部１２−１の受信セッション処理部（図示せず）で処理され、その結果、ＡＣＫ（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）パケットが送信端末３へと返信される。

セッション中継部１２−１の受信セッション処理部で受取られたデータはセッション中継部１２−１の送信セッション処理部（図示せず）へと送られ、ここから受信端末２へとデータパケットが送信される。これに対して、受信端末２が返信したＡＣＫパケットはセッション中継部１２−１の送信セッション処理部で処理される。

同様に、受信端末２から送信端末３へデータを送る場合、受信端末２からのデータパケットはセッション中継部１２−２の受信セッション処理部（図示せず）で処理され、その結果、ＡＣＫパケットが受信端末２へと返信される。

セッション中継部１２−２の受信セッション処理部で受取られたデータはセッション中継部１２−２の送信セッション処理部（図示せず）へと送られ、ここから送信端末３へとデータパケットが送信される。これに対して、送信端末３が返信したＡＣＫパケットはセッション中継部１２−２の送信セッション処理部で処理される。

図２は本発明の第１の実施形態によるセッション中継装置の構成を示すブロック図である。図２において、セッション中継装置１はセッション識別部１１と、セッション中継部１２−１〜１２−Ｎと、パケットスケジューラ１３と、出力制御部１４とから構成されている。

セッション識別部１１は到着したパケットが属するセッションを決定する。セッション中継部１２−１〜１２−Ｎは送信端末３とのセッションと受信端末２とのセッションとの間で中継を行う。パケットスケジューラ１３は各セッション中継部１２−１〜１２−Ｎからのパケット出力を制御する。出力制御部１４はパケットスケジューラ１３からの指示に基づいて各セッション中継部１２−１〜１２−Ｎからのパケット出力を行う。

また、セッション中継部１２−１は受信端末２へとデータを送信するセッションの処理を行う送信セッション処理部１２１−１と、受信したデータを送信終了まで蓄えておく送信バッファ１２２−１と、送信端末３からデータを受信するセッションの処理を行う受信セッション処理部１２３−１とから構成されている。尚、図示していないが、セッション中継部１２−２〜１２−Ｎの構成は上記のセッション中継部１２−１の構成と同様である。

図３は図２のパケットスケジューラ１３の構成を示すブロック図である。図３において、パケットスケジューラ１３はリスト振り分け部１３１と、状態更新部１３２と、状態変数保存部１３３と、リセット制御部１３４と、送信可能リスト１３５と、送信待ちリスト１３６とから構成されている。

送信可能リスト１３５はパケット出力が可能なセッションの識別子を保持し、送信待ちリスト１３６は送信待ち状態にあるセッションの識別子を保持する。リスト振り分け部１３１はデータパケットセッションの識別子もしくはＡＣＫパケットを受信したセッションの識別子を送信可能リスト１３５もしくは送信待ちリスト１３６に振り分ける。

状態更新部１３２は送信可能リスト１３５からセッションの識別子を取出して出力制御部１４に通知し、かつ該セッションの状態を更新する。状態変数保存部１３３は各セッションの状態を保持し、リセット制御部１３４は送信待ちリスト１３６で管理されているセッションの識別子を送信可能リスト１３５へと移動させる。

ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）セッションでは、通常、送信端末３と受信端末２との間の双方向の通信を行う。そのため、本実施形態においては、一組の送信端末３及び受信端末２に対して２つのセッション中継部を使用するものとし、夫々の方向へのデータ通信に対しては夫々対応するセッション中継部を使用する。

したがって、セッション中継部１２−１〜１２−Ｎは複数の送信端末３及び受信端末２の組に対して夫々２つずつ用意され、セッション中継部１２−１〜１２−Ｎ各々は夫々の送信端末３からのセッションから対応する受信端末２へのセッションへと、もしくは夫々の受信端末２からのセッションから対応する送信端末３へのセッションへとデータを中継する処理を行う。

尚、ＴＣＰセッションにおいては、ある方向のデータパケットとその反対方向へのＡＣＫパケットとが１つのパケット上に統合される場合があるが（ＡＣＫのｐｉｇｇｙ ｂａｃｋ）、本実施形態では説明を簡単化するために、このような動作に関しての説明については省略する。

図４及び図５は本発明の第１の実施形態によるセッション中継装置１の動作を示すフローチャートであり、図６は図３に示すパケットスケジューラ１３の動作を示すフローチャートである。これら図１〜図６を参照して本発明の第１の実施形態によるセッション中継装置１の動作について説明する。

本実施形態によるセッション中継装置１にパケットが入力された時（図４ステップＳ１）、セッション識別部１１はパケットのヘッダを参照し、送信元ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレス、送信先ＩＰアドレス、第四層プロトコル番号、送信元第四層ポート番号、送信先第四層ポート番号等に基づいて、パケットが属するセッションを決定する（図４ステップＳ２）。

セッション識別部１１はパケットがデータパケットであれば（図４ステップＳ３）、対応するセッション中継部１２−１〜１２−Ｎの受信セッション処理部１２３−１〜１２３−Ｎ（受信セッション処理部１２３−２〜１２３−Ｎは図示せず）へと渡す（図４ステップＳ４）。

また、セッション識別部１１はパケットがＡＣＫパケットであれば（図４ステップＳ３）、対応するセッション中継部１２−１〜１２−Ｎの送信セッション処理部１２１−１〜１２１−Ｎ（送信セッション処理部１２１−２〜１２１−Ｎは図示せず）へと渡す（図４ステップＳ１０）。

受信セッション処理部１２３−１〜１２３−Ｎでは入力されたデータパケットをシーケンス番号順に並べ替えて送信バッファ１２２−１〜１２２−Ｎ（送信バッファ１２２−２〜１２２−Ｎは図示せず）へと格納する（図４ステップＳ５）。また、受信セッション処理部１２３−１〜１２３−Ｎは受信したデータパケットが正しいシーケンス番号を持つものであれば（図４ステップＳ６）、すなわち連続して受信しているデータの最後尾のシーケンス番号と連続していれば、送信端末３に対してデータの受信確認及び広告ウインドサイズを通知するために、ＡＣＫパケットを出力制御部１４を通して返送する（図４ステップＳ７）。

さらに、受信セッション処理部１２３−１〜１２３−Ｎは連続して受信した最後のパケットのシーケンス番号を基にＡＣＫパケット（重複ＡＣＫパケット）を返送し、送信端末３に対してパケットの未到着を通知する。

上記の処理に関しては、ＴＣＰ／ＩＰ Ｉｌｌｕｓｔｒａｔｅｄ，Ｖｏｌｕｍｅ １：Ｔｈｅ Ｐｒｏｔｏｃｏｌｓ，Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ，１９９４，ＩＳＢＮ ０−２０１−６３３４６−９（以下、文献７とする）に詳しく記載されているので、その説明については詳述しない。

ＡＣＫパケットは生成された後、すぐさま出力制御部１４から出力されるか、もしくは対応する逆方向のセッションの送信バッファ１２２−１〜１２２−Ｎに格納され、逆方向のセッションのデータパケットとともに、パケットスケジューラ１３の指示で出力される。

また、受信セッション処理部１２３−１〜１２３−Ｎでは、連続して受信しているデータの最後尾のシーケンス番号をパケットスケジューラ１３へと通知する（図４ステップＳ８）。

送信セッション処理部１２１−１〜１２１−Ｎでは入力されたＡＣＫパケットを基に輻輳ウインドサイズの変更を行い（図４ステップＳ９）、ＡＣＫパケットが重複ＡＣＫでなければ受信が確認されたデータを送信バッファ１２２−１〜１２２−Ｎから消去し（図５ステップＳ１２，Ｓ１３）、重複ＡＣＫであれば必要に応じてデータの再送処理を行う（図５ステップＳ１２，Ｓ１１）。尚、この処理に関しても上記の文献７に詳しく記載されているので、その説明については詳述しない。

送信セッション処理部１２１−１〜１２１−Ｎは受信したＡＣＫパケットに記されている広告ウインドと、更新した輻輳ウインドとをパケットスケジューラ１３に通知する（図５ステップＳ１５）。また、送信セッション処理部１２１−１〜１２１−Ｎは再送がタイムアウトした場合（図５ステップＳ１４）、受信確認済みの最後のシーケンス番号も通知する（図５ステップＳ１６）。

尚、本実施形態ではパケットスケジューラ１３からパケット出力の指示があった時にのみパケットの出力を行うため、ここでは重複ＡＣＫを受信した時にすぐさまパケットの再送を行うのではなく、次に出力すべきパケットとして再送するパケットのシーケンス番号を記憶しておくのみである。

送信バッファ１２２−１〜１２２−Ｎからのパケット出力は、パケットスケジューラ１３からの指示に基づいて行われる。パケットスケジューラ１３からパケット出力の指示があると、出力制御部１４は送信バッファ１２２−１〜１２２−Ｎからパケットを１つ取出して出力回線に出力し、出力したパケットのパケット長をパケットスケジューラ１３に通知する。

送信バッファ１２２−１〜１２２−Ｎから出力するパケットは、再送処理を行う場合に記憶しておいたシーケンス番号のパケットであり、さもなければ未送信のパケットのうち最もシーケンス番号の小さいパケットである。

尚、該セッションがＴＣＰセッションでなければ、受信セッション処理部１２３−１〜１２３−Ｎでは受信したパケットをそのまま到着順に送信バッファ１２２−１〜１２２−Ｎに格納するのみである。送信セッション処理部１２１−１〜１２１−ＮではＡＣＫパケットを受信せず、パケットスケジューラ１３に対しては送信バッファ１２２−１〜１２２−Ｎのキュー長を広告ウインド及び輻輳ウインドとして通知することで、送信バッファ１２２−１〜１２２−Ｎにパケットがある限り、パケットスケジューラ１３にパケット出力を要求し続ける。

パケットスケジューラ１３では、状態変数保存部１３３において、セッション毎に、割り当てウエイト、送信可能バイト数、送信待ちバイト数の３つのパラメータを保持する。

割り当てウエイトは該セッションに割り当てられたウエイトである。パケットスケジューラ１３は一定周期、あるいはパケット送信可能なセッションがなくなる毎にリセットを行い（図６ステップＳ２６，Ｓ２７）、このリセット１周期内に送信可能なバイト数が割り当てウエイトである。

送信可能バイト数は現時点から次のリセットまでに送信可能なバイト数であり、初期値は割り当てウエイトであって（図６ステップＳ２１）、パケットを出力する毎にパケット長分だけ減算される（図６ステップＳ２２，Ｓ２３）。

送信待ちバイト数はＴＣＰセッションの場合、ＴＣＰレイヤが送信許可したシーケンス番号から既にパケットスケジューラ１３が送信を行ったシーケンス番号を引いたものであり、ｍｉｎ（連続して受信しているデータの最後尾のシーケンス番号＋１、受信端末が示した広告ウインド、該セッションの輻輳ウインド）−送信済みシーケンス番号となる。ＴＣＰセッションでない場合、送信待ちバイト数は送信バッファ１２２−１〜１２２−Ｎ内のキュー長である。

図７は送信待ちバイト数を示す模式図である。図７において、パケット出力が可能なセッション、すなわち送信可能バイト数と送信待ちバイト数とがともに１あるいはＭＳＳ（Ｍａｘｉｍｕｍ Ｓｅｇｍｅｎｔ Ｓｉｚｅ）以上のセッションの識別子は送信可能リスト１３５で管理され（図６ステップＳ２４，Ｓ２５）、送信可能バイト数がリセットされた後にパケット出力が可能となるセッション、すなわち送信待ちバイト数が１あるいはＭＳＳ以上あるが、送信可能バイト数が１あるいはＭＳＳ未満であるセッションの識別子は送信待ちリスト１３６で管理される（図６ステップＳ２７〜Ｓ２９）。

次に、図３を参照してパケットスケジューラ１３の動作について説明する。リスト振り分け部１３１はセッション中継部１２−１〜１２−Ｎから、送信端末３から連続して受信している最後尾のシーケンス番号や、受信端末２から受信した広告ウインド、更新した輻輳ウインドを受取ると、図７に示すようにして送信待ちバイト数を更新する。

また、リスト振り分け部１３１は出力制御部１４において再送タイマがタイムアウトした際にも、送信済みシーケンス番号を受信確認済みのシーケンス番号まで戻し、送信待ちバイト数を更新する。リスト振り分け部１３１は更新前の送信待ちバイト数が１あるいはＭＳＳ未満であれば、該セッションの識別子はまだ送信可能リスト１３５あるいは送信待ちリスト１３６で管理されていないため、更新後の送信待ちバイト数及び送信可能バイト数を基に該セッションの識別子を送信可能リスト１３５あるいは送信待ちリスト１３６に新たに格納する。

状態更新部１３２は送信可能リスト１３５の先頭から送信可能なセッションの識別子を１つ取出し、これを出力制御部１４に通知してパケット出力を行わせる。その後、状態更新部１３２は送信済みシーケンス番号に出力したパケット長を加算した後送信待ちバイト数を更新し、送信可能バイト数から出力したパケット長を減算する。

状態更新部１３２は送信待ちバイト数及び送信可能バイト数にしたがって、改めて該セッションの識別子を送信可能リスト１３５あるいは送信待ちリスト１３６に格納する。すなわち、状態更新部１３２は送信待ちバイト数及び送信可能バイト数がともに１あるいはＭＳＳ以上であれば送信可能リスト１３５に格納し、送信待ちバイト数が１あるいはＭＳＳ以上であるが送信可能バイト数が１あるいはＭＳＳ未満であれば送信待ちリスト１３６に格納する。

状態更新部１３２は送信可能リスト１３５が空になれば、全てのセッションの送信可能バイト数をリセット、すなわち送信可能バイト数に割り当てウエイトを加え、もし送信可能バイト数が割り当てウエイト以上となれば送信可能バイト数を割り当てウエイトの値とする［送信可能バイト数＝ｍｉｎ（送信可能バイト数＋割り当てウエイト，割り当てウエイト）］。

この処理によって、送信待ち状態にあったセッションは全て送信可能な状態に変化するため、送信待ちリスト１３６で管理されていたセッションを全て送信可能リスト１３５へと移動する。

このリセット処理を行う前に、もし送信可能バイト数が１あるいはＭＳＳ未満ではなく、かつ該セッションの送信バッファ１２２−１〜１２２−Ｎ内に送信待ちのデータがあれば、該セッションからの出力帯域に余裕はあるが、送信セッション処理部１２１−１〜１２１−ＮにおいてＴＣＰ制御によって送信を止められている状態であるとする。

この場合には、将来の送信再開に備えて帯域を蓄えておくため、送信可能バイト数と割り当てウエイトとの和が割り当てウエイトを超えた場合でも、ある一定値までは送信可能バイト数を蓄えておく［送信可能バイト数＝ｍｉｎ（送信可能バイト数＋割り当てウエイト，送信可能バイト数上限値）］。

上述したように、本実施形態では、中継するパケットが受信時の送信バッファ１２２−１〜１２２−Ｎへの格納と、送信時の送信バッファ１２２−１〜１２２−Ｎからの取出しの際にのみ移動するため、データ移動のオーバヘッドが小さい。また、ＴＣＰレイヤからの情報を用いたパケットスケジューラ１３によってパケット出力制御を行うため、送信セッション処理部１２１−１〜１２１−Ｎが直接パケット出力するよりも、少ない処理負荷で帯域制御を行いながらのパケット出力を行うことができる。
（第２の実施形態）
本発明の第２の実施形態によるセッション中継装置の構成は図２に示す本発明の第１の実施形態によるセッション中継装置１の構成と同様である。

図８は本発明の第２の実施形態によるパケットスケジューラの構成を示すブロック図である。図８において、本発明の第２の実施形態によるパケットスケジューラ１６は割り当てウエイト変更部１６１及び制御パラメータ変更部１６２を加えた以外は図３に示す本発明の第１の実施形態と同様の構成となっており、同一構成要素には同一符号を付してある。また、同一構成要素の動作は本発明の第１の実施形態と同様である。

この図８を参照して本発明の第２の実施形態によるパケットスケジューラ１６の動作について説明する。ここでは、本発明の第１の実施形態によるパケットスケジューラ１３との相違点のみを説明する。

本実施形態によるセッション中継装置では、パケットスケジューラ１６内の制御パラメータ変更部１６２が割り当てウエイトとして設定した帯域にしたがって該セッションのＴＣＰ制御パラメータの値を動的に変更している。すなわち、制御パラメータ変更部１６２は該セッションの送信可能バイト数が割り当てウエイトよりも大きい予め設定した値よりも大きくなれば、ＴＣＰ制御によってデータ出力が制限されていると判断し、該セッションがより多くの帯域でデータ出力が可能となるように、該セッションのＴＣＰ制御パラメータの値を変更する。

但し、ＴＣＰ制御パラメータを変更しても該セッションのデータ出力帯域が増加しない場合、あるいは再送タイムアウトが一定頻度以上で発生する場合には、ネットワークの輻輳を防止するため、ＴＣＰパラメータの変更を停止する。

また、該セッションの送信可能バイト数が予め設定した別の値よりも小さくなれば、ＴＣＰ制御によるデータ出力をパケットスケジューラ１６の割り当てウエイトによる帯域まで減少させるため、該セッションのＴＣＰ制御パラメータの値を変更する。

前者の場合には、非輻輳時の輻輳ウインドを上げ幅を大きくしたり、輻輳時の輻輳ウインド下げ率を小さくしたりするが、後者の場合にはこの前者の場合とは逆の処理を行う。

また、本実施形態によるセッション中継装置では、パケットスケジューラ１６内の割り当てウエイト変更部１６１が現在送信可能な帯域にしたがって動的に割り当てウエイトを変更させている。すなわち、割り当てウエイト変更部１６１では該セッションの送信可能バイト数が割り当てウエイトよりも大きい予め設定した値よりも大きくなれば、割り当てウエイトで設定した帯域でのデータ出力が不可能であると判断し、割り当てウエイトを一時的に減少させる。

その後、割り当てウエイト変更部１６１は送信可能バイト数が予め設定した別の値よりも小さくなれば、割り当てウエイトを元の値まで順次増加させる。また、割り当てウエイト変更部１６１はセッション中継部１２−１〜１２−Ｎから通知される該セッションの輻輳ウインド及び往復伝播遅延時間計測値を基に該セッションが送信可能な帯域を計算する。

さらに、割り当てウエイト変更部１６１はこの計算値と割り当てウエイトによる帯域設定値がある一定閾値以上異なれば、割り当てウエイトによる帯域設定値が上記の計算値となるように割り当てウエイトを一時的に変更する。
（第３の実施形態）
図９は本発明の第３の実施形態によるセッション中継装置の構成を示すブロック図である。図９において、本発明の第３の実施形態によるセッション中継装置は、セッション中継部１５−１〜１５−Ｎに受信レート制御部１５１−１〜１５１−Ｎ（受信レート制御部１５１−２〜１５１−Ｎは図示せず）を設けた以外は図２に示す本発明の第１の実施形態によるセッション中継装置と同様の構成となっており、同一構成要素には同一符号を付してある。また、同一構成要素の動作は本発明の第１の実施形態と同様である。尚、受信レート制御部１５１−１〜１５１−Ｎは送信端末３からの受信レートを制御する。

この図９を参照して本発明の第３の実施形態によるセッション中継装置の動作について説明するが、ここでは、上述した本発明の第１の実施形態との相違点のみを説明する。

本実施形態によるセッション中継装置では、送信バッファ１２２−１〜１２２−Ｎの空き容量がなくなると、受信セッション処理部１２３−１〜１２３−Ｎが送信端末３に対して広告ウインドサイズが０であることを通知し、これに応じて送信端末３はデータの送信を停止する。

本発明の第１の実施形態では、その後、送信バッファ１２２−１〜１２２−Ｎに空き容量ができたとしても、送信端末３がウインド検査のためのパケットを出力してくるまでは、送信再開のためのＡＣＫを出力することができない。

これに対して、本実施形態では、パケットスケジューラ１３がパケット出力の指示を行った際、受信レート制御部１５１−１ではパケット出力後の送信バッファ１２２−１〜１２２−Ｎの空き容量を検査し、もしこれが１あるいはＭＳＳ以上であれば、送信端末３に対してすばやい送信再開を促すためにＡＣＫパケットを生成する。

また、受信レート制御部１５１−１〜１５１−Ｎでは送信バッファ１２２−１〜１２２−Ｎの空き容量、あるいはその平均値が予め設定したある値以上になれば、送信バッファ１２２−１〜１２２−Ｎの空き容量がなくなることを防ぐために、送信端末３に対して送信帯域の低下を指示する。

これは、例えば、送信側に返送するＡＣＫパケットを重複ＡＣＫとすることや、受信パケットを廃棄すること、ＡＣＫパケットにＥＣＮ（Ｅｘｐｌｉｃｉｔ Ｃｏｎｇｅｓｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ）ビットを設定すること、ＡＣＫパケットを遅延させること、ＡＣＫパケットの広告ウインドを一時的に小さく書換えること等で可能である。
（第４の実施形態）
図１０は本発明の第４の実施形態によるセッション中継装置の構成を示すブロック図である。図１０において、本発明の第４の実施形態によるセッション中継装置は、送信ｉＳＣＳＩ（ｉｎｔｅｒｎｅｔ Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）制御部１７１−１〜１７１−Ｎ（送信ｉＳＣＳＩ制御部１７１−２〜１７１−Ｎは図示せず）及び受信ｉＳＣＳＩ制御部１７２−１〜１７２−Ｎ（受信ｉＳＣＳＩ制御部１７２−２〜１７２−Ｎは図示せず）をセッション中継部１７−１〜１７−Ｎに設けた以外は上述した本発明の第３の実施形態によるセッション中継装置と同様の構成となっており、同一構成要素には同一符号を付してある。また、同一構成要素の動作は本発明の第３の実施形態によるセッション中継装置と同様である。

送信ｉＳＣＳＩ制御部１７１−１〜１７１−Ｎは受信端末２への送信レートに対してｉＳＣＳＩレイヤの輻輳制御情報を反映させる。受信ｉＳＣＳＩ制御部１７２−１〜１７２−Ｎは送信端末３からの受信レートに対してｉＳＣＳＩレイヤの輻輳制御情報を反映させる。

この図１０を参照して本発明の第４の実施形態によるセッション中継装置の動作について説明する。ここでは、本発明の第４の実施形態における本発明の第３の実施形態との相違点のみを説明する。

ｉＳＣＳＩレイヤにおいては、受信端末２から送信端末３に対して、受信端末２が受信可能なデータ量を通知するＲ２Ｔ（Ｒｅａｄｙ−Ｔｏ−Ｔｒａｎｓｆｅｒ）パケットを送信することで、送信端末３と受信端末２との間で転送制御を行う。

そこで、本実施形態では、送信ｉＳＣＳＩ制御部１７１−１〜１７１−Ｎが受信端末２からＲ２Ｔパケットを受信すると、このＲ２Ｔパケットを受信端末２に送らず、本実施形態によるセッション中継装置にてＲ２Ｔパケット受信時に出力を行ったデータの最後のシーケンス番号を記憶しておく。

送信ｉＳＣＳＩ制御部１７１−１〜１７１−Ｎは前回記憶しておいたシーケンス番号に、今回受信したＲ２Ｔパケットの送信可能データ量を加えたものを、ｉＳＣＳＩレイヤで送信可能なデータ量としてパケットスケジューラ１３に通知する。

パケットスケジューラ１３では送信待ちバイト数を、ＴＣＰレイヤが送信許可したデータ量とｉＳＣＳＩレイヤが許可したデータ量との最小値とする。すなわち、図１１に示すように、送信待ちバイト数＝ｍｉｎ（連続して受信しているデータの最後尾のシーケンス番号＋１，受信端末が示した広告ウインド，該セッションの輻輳ウインド，前回Ｒ２Ｔパケットを受信した際のシーケンス番号＋今回受信したＲ２Ｔパケットの送信可能データ量）−送信済みシーケンス番号となる。

受信ｉＳＣＳＩ制御部１７２−１〜１７２−Ｎではパケットスケジューラ１３がパケット出力の指示を行った際に、パケット出力後の送信バッファ１２２−１〜１２２−Ｎの空き容量を検査し、もしこれが予め定められ一定値以上であれば、送信端末３に対して送信バッファの空き容量をＲ２Ｔパケットとして送信する。

上述したように、本実施形態では送信端末３と受信端末２との間でｉＳＣＳＩレイヤの輻輳制御を行うのではなく、セッション中継装置でｉＳＣＳＩレイヤの輻輳制御を中継することで、ｉＳＣＳＩレイヤにおいてもＴＣＰセッションを中継するのと同様のスループットの向上を図ることができる。
（第５の実施形態）
図１２は本発明の第５の実施形態によるセッション中継装置の構成を示すブロック図である。図１２において、本発明の第５の実施形態によるセッション中継装置はセッション識別部１１と、セッション送信部４１−１〜４１−Ｎと、セッション受信部４２−１〜４２−Ｎと、パケットスケジューラ１３と、出力制御部１４とから構成されている。

セッション識別部１１は到着したパケットが属するセッションを決定し、セッション送信部４１−１〜４１−Ｎは受信端末へのセッションのデータ送信処理を行い、セッション受信部４２−１〜４２−Ｎは受信端末へのセッションからのデータ受信処理を行う。

パケットスケジューラ１３は各セッション送信部４１−１〜４１−Ｎからのパケット出力を制御する。出力制御部１４はパケットスケジューラ１３からの指示に基づいて各セッション送信部４１−１〜４１−Ｎからのパケット出力を行う。

また、セッション送信部４１−１〜４１−Ｎは送信セッション処理部４１１−１〜４１１−Ｎ（送信セッション処理部４１１−２〜４１１−Ｎは図示せず）と、送信データ生成部４１２−１〜４１２−Ｎ（送信データ生成部４１２−２〜４１２−Ｎは図示せず）と、送信バッファ４１３−１〜４１３−Ｎ（送信バッファ４１３−１〜４１３−Ｎは図示せず）とから構成されている。

送信データ生成部４１３−１〜４１３−Ｎはアプリケーションプログラムからの送信データを送信バッファ４１３−１〜４１３−Ｎへと格納する。送信バッファ５−６−１は送信するデータを一時蓄えておく。送信セッション処理部４１１−１〜４１１−Ｎは受信端末へとデータを送信するセッションの処理を行う。

セッション受信部４２−１〜４２−Ｎは受信セッション処理部４２１−１〜４２１−Ｎ（受信セッション処理部４２１−２〜４２１−Ｎは図示せず）と、受信バッファ４２２−１〜４２２−Ｎ（受信バッファ４２２−２〜４２２−Ｎは図示せず）と、受信データ処理部４２３−１〜４２３−Ｎとから構成されている。

受信セッション処理部４２１−１〜４２１−Ｎは受信端末からのデータの受信処理を行い、受信バッファ４２２−１〜４２２−Ｎは受信したデータを一時蓄えておく。受信データ処理部４２３−１〜４２３−Ｎは受信バッファ５−１４−１からアプリケーションへ受信データを受け渡す。

ＴＣＰセッションでは、通常、送信端末と受信端末との間の双方向の通信を行うため、本実施形態では、一組の送信端末及び受信端末に対してそれぞれ１つのセッション送信部４１−１〜４１−Ｎ及びセッション受信部４２−１〜４２−Ｎを使用する。本実施形態においては、セッション中継装置が送信端末あるいは受信端末を兼ねている。

図１３は本発明の第５の実施形態によるセッション中継装置（送信端末）及びセッション中継装置（受信端末）の間のデータの流れを示すブロック図である。図１３において、セッション中継装置（送信端末）４−２からセッション中継装置（受信端末）４−１へデータを送る場合、セッション中継装置（送信端末）４−２のセッション送信部４１−１−２から出力されたデータパケットはセッション中継装置（受信端末）４−１のセッション受信部４２−１−１で受信処理が行われる。その結果、生成されたＡＣＫパケットはセッション中継装置（送信端末）４−２のセッション送信部４１−１−２へと返送される。

また、セッション中継装置（受信端末）４−１からセッション中継装置（送信端末）４−２へデータを送る場合、セッション中継装置（受信端末）４−１のセッション送信部４１−１−１から出力されたデータパケットはセッション中継装置（送信端末）４−２のセッション受信部４２−１−２で受信処理が行われる。その結果、生成されたＡＣＫパケットはセッション中継装置（受信端末）４−１のセッション送信部４１−１−１へと返送される。

次に、図１２を参照して本発明の第５の実施形態の動作について説明する。まず、送信端末から受信端末へのデータ転送に関して説明する。

アプリケーションプログラムが出力した送信データは送信データ生成部４１２−１〜４１２−Ｎによって送信バッファ４１３−１〜４１３−Ｎへと書込まれる。送信セッション処理部４１１−１〜４１１−Ｎは送信バッファ４１３−１〜４１３−Ｎから受信端末へのデータ送信処理を行う。この処理は上述した本発明の第１の実施形態と同様であるため、その説明を省略する。

ここで、パケットスケジューラ１３は送信待ちバイト数を計算する際に、連続して受信しているデータの最後尾のシーケンス番号の代わりに、アプリケーションプログラムから受取ったデータの最後のシーケンス番号を用いる。

次に、受信端末から送信端末へのデータ転送に関して説明する。受信セッション処理部４２１−１〜４２−１Ｎでは受信端末から送信されたデータの受信処理を行い、正しく受取ることができたデータを受信バッファ４２２−１〜４２２−Ｎに格納する。

この受信処理は格納するバッファが送信バッファではなく受信バッファである点を除いて、上述した本発明の第１の実施形態と同様であるため、その説明を省略する。受信バッファ４２２−１〜４２２−Ｎに書込まれたデータは、受信データ処理部４２３−１〜４２３−Ｎによって取出されてアプリケーションプログラムへと渡される。

このように、本発明は、複数のレイヤにおける輻輳制御処理に関して、輻輳制御情報の作成のみをそれぞれのレイヤで行い、パケット出力制御処理をＩＰレイヤのスケジューラに集約することで、セッション中継処理の高速化を実現することができる。

また、本発明は、複数のレイヤの受信バッファ及び送信バッファをＩＰレイヤの送信バッファに集約することによって、バッファ間でのデータ移動をなくし、セッション中継処理の高速化を実現することができる。

Claims (36)

1. 送信端末に向けたセッションと受信端末に向けたセッションとの間でデータの中継を行うことで前記送信端末と前記受信端末との間の通信を実現するセッション中継装置において、
   複数のレイヤに対応して設けられ、かつ、前記送信端末に向けたセッションからのデータを受信する受信セッション処理手段と、
   複数のレイヤに対応して設けられ、かつ、前記受信端末に向けたセッションへとデータを送信する送信セッション処理手段と、
   前記送信端末へと出力するデータを一時蓄えておく送信バッファと、
   前記複数のレイヤのうちの１つのレイヤに対応して設けられ、前記送信バッファからのパケット出力を制御するパケットスケジューラと、
   前記パケットスケジューラの制御に応答して前記送信バッファに蓄えられたデータを出力制御する出力制御手段とを有し、
   前記パケットスケジューラが対応するレイヤとは異なる少なくとも１つのレイヤに対応して設けられた前記送信セッション処理手段が、出力が許可されているデータ量を計算し、これに基づいて前記パケットスケジューラが前記パケット出力を制御することを特徴とするセッション中継装置。
2. 前記パケットスケジューラは、ＩＰレイヤに対応して設けられていることを特徴とする請求項１記載のセッション中継装置。
3. 前記受信セッション処理手段は、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）セッションからのデータ受信処理を行い、
   前記送信セッション処理手段は、前記ＴＣＰセッションへのデータ出力処理を行い、ＴＣＰウインドフロー制御によって決定される出力可能なデータ量を前記パケットスケジューラに通知し、
   前記パケットスケジューラは、通知されたデータ量を基にスケジューリング処理を行う請求項１または２に記載のセッション中継装置。
4. 前記パケットスケジューラは、前記セッションに割り当てられた帯域及び帯域比率を少なくとも含む通信資源割り当て方針と、前記送信セッション処理手段から通知された送信可能データ量と、前記送信バッファ内に蓄えられているデータ量とを基にパケット出力を行うセッションを決定し、前記セッション各々からのデータ出力を制御する請求項１または２に記載のセッション中継装置。
5. 前記パケットスケジューラは、前記セッション各々における未使用の通信資源を蓄えておく蓄積手段をさらに備え、前記通信資源が必要になった際に前記蓄積手段に蓄えておいた通信資源を用いて通信を行う請求項１または２に記載のセッション中継装置。
6. 前記パケットスケジューラは、前記送信バッファ内に出力すべきデータがあり、前記出力制御手段からの出力許可データ量の制限によって未使用となった前記通信資源の帯域のみを前記蓄積手段に蓄えておくことを特徴とする請求項５記載のセッション中継装置。
7. 前記送信セッションの制御パラメータを動的に変更する手段をさらに備え、前記パケットスケジューラからのデータ出力状況に応じて前記制御パラメータを変更する請求項１または２に記載のセッション中継装置。
8. 前記セッションの未使用帯域が大きくなった時に当該セッションの制御パラメータを当該セッションからの出力帯域が小さくなる方向に変更し、前記セッションの未使用帯域が小さくなった時に当該セッションの制御パラメータを当該セッションからの出力帯域が大きくなる方向に変更し、前記制御パラメータの変更によって輻輳が発生した時に前記制御パラメータの変更を停止する請求項７記載のセッション中継装置。
9. 前記セッション各々に割り当てた帯域及び帯域比率を少なくとも含む通信資源割り当て量を動的に変更する手段をさらに備え、
   前記パケットスケジューラからのデータ出力状況及び前記出力制御手段から通知される送信可能データ量に応じて前記制御パラメータを変更する請求項８記載のセッション中継装置。
10. 前記セッションの未使用帯域が大きくなった時に当該セッションの割り当て資源を減少させ、前記セッションの未使用帯域が小さくなった時に当該セッションの割り当て資源をその初期値を上限として増加させるとともに、前記出力制御手段から通知される送信可能データ量及びその平均のいずれかによって前記割り当て資源を増減する請求項９記載のセッション中継装置。
11. 前記送信端末からのセッションの送信処理を制御する帯域、送信可否、送信可能データ量を少なくとも含む送信制御情報を制御する受信レート制御手段を含み、前記送信バッファの空き容量及び前記パケットスケジューラからの情報に応じて前記送信端末への送信制御情報の変更及び生成のいずれかを行う請求項１または２に記載のセッション中継装置。
12. 前記パケットスケジューラからのパケット出力情報を受信する手段と、パケット出力によって変更された前記送信バッファの空き容量を調べる手段とをさらに備え、パケット出力後に前記送信バッファの空き容量が一定量以上となった時に前記送信端末に対して送達確認パケットを送信して送信再開を促す請求項１１記載のセッション中継装置。
13. 前記送信バッファの空き容量及びその平均の少なくとも一方を調べる手段をさらに備え、前記空き容量に応じて前記送信端末に対して送信帯域の減少を指示する請求項１１記載のセッション中継装置。
14. 送信端末に向けたセッションと受信端末に向けたセッションとの間でデータの中継を行うことで前記送信端末と前記受信端末との間の通信を実現するセッション中継装置において、
    複数のレイヤに対応して設けられかつ前記送信端末に向けたセッションからのデータを受信する受信セッション処理手段と、
    前記複数のレイヤに対応して設けられかつ前記受信端末に向けたセッションへとデータを送信する送信セッション処理手段と、
    前記送信端末へと出力するデータを一時蓄えておく送信バッファと、
    前記送信バッファからのパケット出力を制御するパケットスケジューラとを有し、
    前記送信セッション処理手段各々において当該レイヤで出力が許可されているデータ量を計算し、前記複数のレイヤ全てで共通に許可されるデータ量に基づいて前記パケットスケジューラが前記パケット出力を制御することを特徴とするセッション中継装置。
15. 前記レイヤとして輻輳制御を行うレイヤのひとつとしてｉＳＣＳＩ（ｉｎｔｅｒｎｅｔ Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）レイヤを含み、当該ｉＳＣＳＩレイヤにおいて前記受信端末から受信する受信可能データ量を基に送信可能データ量を決定する請求項１４記載のセッション中継装置。
16. 前記パケットスケジューラからのパケット出力情報を受信する手段と、
    パケット出力によって変更された前記送信バッファの空き容量を調べる手段とをさらに備え、
    パケット出力後に前記送信バッファの空き容量が一定量以上となった時に前記送信端末に対して前記受信可能データ量を生成して送信再開を促す請求項１４記載のセッション中継装置。
17. 前記受信セッション処理手段は、受信したパケットを前記送信バッファに直接格納し、前記送信バッファから直接出力する請求項１または２に記載のセッション中継装置。
18. アプリケーションプログラムから前記送信バッファへとデータの書込みを行い、受信したデータを前記アプリケーションプログラムへと渡す請求項１または２に記載のセッション中継装置。
19. 送信端末に向けたセッションと受信端末に向けたセッションとの間でデータの中継を行うことで前記送信端末と前記受信端末との間の通信を実現するセッション中継装置のセッション中継方法において、
    前記セッション中継装置側で行われる、
    複数のレイヤに対応して設けられた受信セッション処理手段が前記送信端末に向けたセッションからのデータを受信する受信セッションステップと、
    複数のレイヤに対応して設けられた送信セッション処理手段が前記受信端末に向けたセッションへとデータを送信する送信セッションステップと、
    前記送信端末へと出力するデータを送信バッファに一時蓄えておくステップと、
    前記複数のレイヤのうち１つのレイヤに対応して設けられたパケットスケジューラが前記送信バッファからのパケット出力を制御するステップと、
    前記パケットスケジューラの制御に応答して前記送信バッファに蓄えられたデータを出力制御手段にて出力制御するステップとを有し、
    前記送信セッションステップにおいては、前記パケットスケジューラが対応するレイヤとは異なる少なくとも１つのレイヤに対応して設けられた前記送信セッション処理手段が、出力が許可されているデータ量を計算し、前記送信バッファからのパケット出力を制御するステップにおいては、該計算されたデータ量に基づいて前記パケットスケジューラが前記パケット出力を制御することを特徴とするセッション中継方法。
20. 前記パケットスケジューラは、ＩＰレイヤに対応して設けられていることを特徴とする請求項１９記載のセッション中継方法。
21. 前記受信セッションステップは、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）セッションからのデータ受信処理を行うステップを備え、
    前記送信セッションステップは、前記ＴＣＰセッションへのデータ出力処理を行い、ＴＣＰウインドフロー制御によって決定される出力可能なデータ量を前記パケットスケジューラに通知することで、前記パケットスケジューラが通知されたデータ量を基にスケジューリング処理を行うステップを備える請求項１９または２０に記載のセッション中継方法。
22. 前記パケットスケジューラが、前記セッションに割り当てられた帯域及び帯域比率を少なくとも含む通信資源割り当て方針と、前記送信セッション処理手段から通知された送信可能データ量と、前記送信バッファ内に蓄えられているデータ量とを基にパケット出力を行うセッションを決定し、前記セッション各々からのデータ出力を制御するステップをさらに備える請求項１９または２０に記載のセッション中継方法。
23. 前記パケットスケジューラには前記セッション各々における未使用の通信資源を蓄えておく蓄積手段が含まれ、
    前記パケットスケジューラにおいて前記通信資源が必要になった際に前記蓄積手段に蓄えておいた通信資源を用いて通信を行うステップをさらに備えた請求項１９または２０に記載のセッション中継方法。
24. 前記パケットスケジューラが、前記送信バッファ内に出力すべきデータがあり、前記出力制御手段からの出力許可データ量の制限によって未使用となった前記通信資源の帯域のみを前記蓄積手段に蓄えておくステップをさらに備えた請求項２３記載のセッション中継方法。
25. 前記送信セッションの制御パラメータを動的に変更する手段が、前記パケットスケジューラからのデータ出力状況に応じて前記制御パラメータを変更するステップをさらに備えた請求項１９または２０に記載のセッション中継方法。
26. 前記セッションの未使用帯域が大きくなった時に当該セッションの制御パラメータを当該セッションからの出力帯域が小さくなる方向に変更し、前記セッションの未使用帯域が小さくなった時に当該セッションの制御パラメータを当該セッションからの出力帯域が大きくなる方向に変更し、前記制御パラメータの変更によって輻輳が発生した時に前記制御パラメータの変更を停止するステップをさらに備えた請求項２５記載のセッション中継方法。
27. 前記セッション各々に割り当てた帯域及び帯域比率を少なくとも含む通信資源割り当て量を動的に変更する手段が、前記パケットスケジューラからのデータ出力状況及び前記出力制御手段から通知される送信可能データ量に応じて前記制御パラメータを変更するステップをさらに備えた請求項２６記載のセッション中継方法。
28. 前記セッションの未使用帯域が大きくなった時に当該セッションの割り当て資源を減少させ、前記セッションの未使用帯域が小さくなった時に当該セッションの割り当て資源をその初期値を上限として増加させるとともに、前記出力制御手段から通知される送信可能データ量及びその平均のいずれかによって前記割り当て資源を増減するステップをさらに備えた請求項２７記載のセッション中継方法。
29. 前記送信端末からのセッションの送信処理を制御する帯域、送信可否、送信可能データ量を少なくとも含む送信制御情報を制御する受信レート制御手段が、前記送信バッファの空き容量及び前記パケットスケジューラからの情報に応じて前記送信端末への送信制御情報の変更及び生成のいずれかを行うステップをさらに備えた請求項１９から請求項２７のいずれか記載のセッション中継方法。
30. パケット出力後に前記送信バッファの空き容量が一定量以上となった時に前記送信端末に対して送達確認パケットを送信して送信再開を促すステップをさらに備えた請求項２９記載のセッション中継方法。
31. 前記送信バッファの空き容量及びその平均の少なくとも一方を調べる手段で調べられた前記空き容量に応じて前記送信端末に対して送信帯域の減少を指示するステップをさらに備えた請求項３０記載のセッション中継方法。
32. 送信端末に向けたセッションと受信端末に向けたセッションとの間でデータの中継を行うことで前記送信端末と前記受信端末との間の通信を実現するセッション中継装置のセッション中継方法において、
    前記セッション中継装置側に、
    複数のレイヤ各々において前記送信端末に向けたセッションからのデータを受信する受信セッションステップと、
    前記複数のレイヤ各々において前記受信端末に向けたセッションへとデータを送信する送信セッションステップと、
    前記送信端末へと出力するデータを送信バッファに一時蓄えておくステップと、
    前記送信バッファからのパケット出力をパケットスケジューラにて制御するステップとを備え、
    前記送信セッション処理各々において当該レイヤで出力が許可されているデータ量を計算し、前記複数のレイヤ全てで共通に許可されるデータ量に基づいて前記パケットスケジューラが前記パケット出力を制御することを特徴とするセッション中継方法。
33. 前記レイヤとして輻輳制御を行うレイヤのひとつとしてｉＳＣＳＩ（ｉｎｔｅｒｎｅｔ Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）レイヤを含み、
    当該ｉＳＣＳＩレイヤにおいて前記受信端末から受信する受信可能データ量を基に送信可能データ量を決定するステップをさらに備えた請求項３２記載のセッション中継方法。
34. パケット出力後に前記送信バッファの空き容量が一定量以上となった時に前記送信端末に対して前記受信可能データ量を生成して送信再開を促すステップをさらに備えた請求項３２記載のセッション中継方法。
35. 前記受信セッションステップは、受信したパケットを前記送信バッファに直接格納し、前記送信バッファから直接出力するステップをさらに備えた請求項１９または２０に記載のセッション中継方法。
36. アプリケーションプログラムから前記送信バッファへとデータの書込みを行い、受信したデータを前記アプリケーションプログラムへと渡すステップをさらに備えた請求項１９または２０に記載のセッション中継方法。

Images