JPWO2007052764A1 - セッション中継装置およびセッション中継方法 - Google Patents

Abstract

セグメントの再構成・分割を行うことなく、送信元から再送されたデータパケットを送信先へ確実に送信するセッション中継装置を提供する。送信するセグメントの順番を示すシーケンス番号が付与されたパケットによりデータが送受信される端末間に配置されるセッション中継装置１１０であって、送信側の端末との間に開設される第１のセッションと、受信側の端末との間に開設される第２のセッションとの間でパケットデータの中継を行うセッション中継部１１０−３を有する。セッション中継部１１０−３は、上記送信側の端末から再送セグメントを受信すると、該受信した再送セグメントのセグメントサイズで上記第２のセッションの最大セグメントサイズを更新し、該受信した再送セグメントを上記受信側の端末に向けて送信する。

Description

本発明は、セッション間でデータを中継するセッション中継装置に関する。

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

上記の問題を解決する方法として、送受信端末間の通信を一つのセッションで行うのではなく、送受信端末間に中継装置を設置し、送信端末から中継装置へのセッションと中継装置から受信端末へのセッションの２つのセッション間でデータの中継を行う方法が知られている。このようなセッション中継方式の一例として、非特許文献１（Ajay Bakre and B.R.Badrinath、“I-TCP; Indirect TCP for Mobile Host”、 Department of Computer Science Rutgers University、 DSC-TR-314、 1994）に記載の「Ｉｎｄｉｒｅｃｔ ＴＣＰ」や、特許文献１（特許第３４４８４８１号公報）、特許文献２（特許第３４８２０９１号公報）および特許文献３（特許第３４９４６１０号公報）に記載の通信方式がある。

以下に、ＴＣＰを用いたセッション通信例を説明する。なお、通常のＴＣＰの動作に関しては、非特許文献２（Jon Postel、”Transmission Control Protocol”、IETF、RFC 793、1981）や非特許文献３（W. Richard Stevens、“TCP/IP Illustrated、 Volume 1: The Protocols、 Addison-Wesley”、1994、ISBN 0-201-63346-989）に詳しく記載されている。

図１に、送信端末側および受信端末側の両方から透過的にセッション中継できるようにした両側透過型のセッション中継器を示す。図１を参照すると、両側透過型のセッション中継装置３２−０は、ネットワークからのパケットが入力されるパケット入力部３２−１と、ネットワーク上にパケットを出力するパケット出力部３２−２と、セッションを終端して中継するセッション中継部３２−３と、セッション中継部３２−３のセッション状態を記憶するセッション状態記憶部３２−４と、セッションパケットであるか否かを判断するセッション判定部３２−５と、セッション中継するか否かを判断するセッション中継判定部３２−６と、セッション開始パケットを監視するセッション開始処理監視部３２−７とを備える。

パケット入力部３２−１は、ネットワークからパケットを受け取る処理を行う。セッション判定部３２−５は、パケット入力部３２−１からの入力パケットがセッションパケットであるか否かを判断する。入力パケットがセッションパケットであれば、セッション判定部３２−５は、その入力パケットをセッション中継判定部３２−６に渡す。入力パケットがセッション以外のパケットであれば、セッション判定部３２−５は、その入力パケットをパケット出力部３２−２に渡す。

セッション中継判定部３２−６は、セッション判定部３２−５からのセッションパケットが、セッション状態記憶部３２−４に登録されているセッションにおけるパケットであり、かつ、セッション開始・応答パケットより後に送信されたパケットであるか否かを判断する。この条件が成立した場合は、セッション中継判定部３２−６は、セッション判定部３２−５からのセッションパケットをセッション中継部３２−３へ渡す。条件が成立しない場合は、セッション中継判定部３２−６は、セッション判定部３２−５からのセッションパケットをセッション開始処理監視部３２−７へ渡す。

セッション開始処理監視部３２−７は、セッション開始パケットを受け取ると、受信シーケンス番号（受信端末から受信すべきシーケンス番号）及び送信シーケンス番号（送信端末に対して送信すべきシーケンス番号）を確定せずに仮に作成したセッション情報を登録し、セッション開始・応答パケットを受け取ると、仮に作成したセッション情報中の受信シーケンス番号及び送信シーケンス番号を確定する。セッション開始処理監視部３２−７の処理が終わった後、セッション判定部３２−５からのセッションパケットはパケット出力部３２−２に渡される。

セッション中継部３２−３は、セッション状態記憶部３２−４に格納されたセッション状態に基づいてセッション中継処理を行い、更新されたセッション状態をセッション状態記憶部３２−４に記憶し、セッション中継判定部３２−６からのパケットをパケット出力部３２−２に渡す。パケット出力部３２−２は、供給されたパケットをネットワーク上に出力する処理を行う。

図１に示したセッション中継装置におけるＴＣＰを用いたセッションについて説明する。ＴＣＰを用いたセッションでは、セッション開始パケットおよびセッション開始・応答パケットはそれぞれＳＹＮパケットおよびＳＹＮ・ＡＣＫパケットとする。

図２は、図１に示したセッション中継器３２−０を備えるネットワーク構成のブロック図である。図３は、図２に示したネットワーク構成におけるセッション中継器３２−０によるＴＣＰ中継のシーケンス図である。図３に示す例は、ＩＰアドレスＡを持つ送信端末１０からＩＰアドレスＢを持つ受信端末２０のポート番号８０へデータを転送する場合のシーケンス動作である。

最初に、送信端末１０が、受信端末２０に対してコネクション開始ＳＹＮパケットを送信する。このコネクション開始ＳＹＮパケットは、送信元ＩＰアドレス「Ａ」、送信元ポート番号「ｘ」、シーケンス番号「１」、宛先ＩＰアドレス「Ｂ」、宛先ポート番号「８０」といった情報を含む。

経路途中にあるセッション中継装置３２−０では、送信端末１０からのコネクション開始ＳＹＮパケットがパケット入力部３２−１に供給される。パケット入力部３２−１は、供給されたＳＹＮパケットをセッション判定部３２−５に渡す。セッション判定部３２−５は、パケット入力部３２−１からのパケットがセッションパケットであると判断し、そのパケットをセッション中継判定部３２−６に渡す。セッション中継判定部３２−６は、セッション判定部３２−５から受け取ったパケットがセッション状態記憶部３２−４に登録されているセッションに対応するものではないと判断し、受け取ったパケットをセッション開始処理監視部３２−７に渡す。

セッション開始処理監視部３２−７は、セッション中継判定部３２−６から受け取ったパケットがセッション開始（ＳＹＮ）パケットであると判断し、セッション状態記憶部１−４に対してセッションの登録を行うとともに、セッション中継を開始して、受け取ったパケットをパケット出力部３２−２に渡す。このとき、すくなくとも受信端末２０への送信シーケンス番号と送信端末１０からの受信シーケンス番号がセッション状態記憶部３２−４に登録される。この２つのシーケンス番号は、セッション開始（ＳＹＮ）パケットのシーケンス番号で初期化される。この段階で登録されるセッションの情報は、送信端末１０への送信シーケンス番号と受信端末２０からの受信シーケンス番号がいずれも確定していないため、セッション情報全体としては、不完全なものである。

セッション開始処理監視部３２−７からパケットを受け取ったパケット出力部１−２は、その受け取ったパケットを受信端末２０に向けてネットワーク上に送出する。このとき、セッション中継装置３２−０の前後で、ＳＹＮパケット内のパケットの情報が異なることはない。

受信端末２０は、セッション中継装置３２−０からＳＹＮパケットを受け取ると、送信端末１０へ向けてＳＹＮ・ＡＣＫパケットを返す。

経路途中にあるセッション中継装置３２−０では、受信端末２０からのＳＹＮ・ＡＣＫパケットがパケット入力部３２−１に供給される。パケット入力部３２−１は、ＳＹＮ・ＡＣＫパケットをセッション判定部３２−５に渡す。セッション判定部３２−５は、パケット入力部３２−１から受け取ったパケットがセッションパケットであると判断し、受け取ったパケットをセッション中継判定部３２−６に渡す。セッション中継判定部３２−６は、セッション判定部３２−５から受け取ったパケットが、セッション状態記憶部１−４に登録されているセッションに対応するものであり、セッション開始・応答（ＳＹＮ・ＡＣＫ）パケットより後のパケットではないと判断し、受け取ったパケットをセッション開始処理監視部３２−７に渡す。

セッション開始処理監視部３２−７は、セッション中継判定部３２−６から受け取ったパケットが、セッション開始（ＳＹＮ）パケットではなく、セッション開始・応答パケット（ＳＹＮ・ＡＣＫ）パケットであると判断して、セッション状態記憶部３２−４におけるセッション情報を更新するとともに、セッション中継を開始して、受け取ったパケットをパケット出力部１−２に渡す。このとき、送信端末１０への送信シーケンス番号と受信端末２０からの受信シーケンス番号が更新される。この２つのシーケンス番号は、セッション開始・応答（ＳＹＮ・ＡＣＫ）パケットのシーケンス番号で初期化される。

セッション開始処理監視部３２−７からパケットを受け取ったパケット出力部３２−２は、その受け取ったパケットを送信端末１０に向けてネットワーク上に送出する。このとき、セッション中継装置３２−０の前後で、ＳＹＮ・ＡＣＫパケット内のパケットの情報が異なることはない。

その後、セッション中継装置３２−０では、セッション中継部３２−３によってＳＹＮ・ＡＣＫパケットに対するＡＣＫパケットを受信端末２０へ返す。こうして、セッション中継装置３２−０により、送信端末１０および受信端末２０との間にセッションが開設される。

セッション開設後、通信経路上になんらかの障害が発生した場合には、ＩＣＭＰ（Internet control massage Protocol）を用いた状態通知が行われる。ＩＣＭＰの動作に関しては、非特許文献３や非特許文献４（Jon Postel、”INTERNET CONTROL MESSAGE PROTOCOL”、IETF、RFC 792、1981）に詳しく記載されている。

途中経路にＭＴＵ(最大転送単位)が異なる区間が存在する場合、ＩＰヘッダに「Don't Fragment（フラグメント不可）」フラグが立っていると、フラグメント化することができずにデータが転送されないという問題があった。この問題を解決する方法として、非特許文献５（J.Mogul、S.Deering、”Path MTU discovery”、IETF、RFC 1191、1990）には、Path MTU discoveryと呼ばれる手法が提案されている。

図４に、ICMP Destination Unreachable（到達不可）・フラグメント要求メッセージのパケット構成を示し、図５に、ICMP Destination Unreachable（到達不可）・フラグメント要求メッセージに含まれる、エラーを起こしたペット部分の構成を示す。Path MTU discovery手法は、ＭＴＵの異なる区間が存在するルータにおいて、「Don’t Fragment」フラグが立っているためにフラグメント化することができず、データの転送を行うことができない場合に、図４に示すようなICMP Destination Unreachable（到達不可）・フラグメント要求メッセージに、次のホップのＭＴＵを入れて、送信元に通知することにより、送信元の端末がＭＳＳ(最大セグメントサイズ)を下げてセグメントを再転送するという手法である。図４に示した「Internet Header + 64 bits of Original Data Datagram」には、エラーを起こしたパケットのうち、図５に示した情報が含まれる。

通信経路上にＭＴＵが異なる複数の区間が存在する場合は、それら区間における最小のＭＴＵが検出されるまで、送信元に対してＩＣＭＰによりＭＴＵを通知してＭＳＳを下げる作業が繰り返し行われる。そして、最も小さいＭＴＵが検出された時点で、送信元と送信先の間で通信が可能となる。同様な手法が、特許文献４（特開２００３−１８２１６号公報）に記載されている。

図６は、図１および図２に示した両側透過型のセッション中継装置を有するネットワーク装置におけるPath MTU Discoveryに基づく動作を説明するための図である。以下、図６を参照して、Path MTU Discoveryに基づく動作を、ＴＣＰを例に説明する。この例では、ＩＰ、ＴＣＰのヘッダサイズの合計は４０バイトとしている。

ＳＹＮの処理の後、送信端末４２１(アドレス:Ａ、ポート:ｘ)が、受信端末４２３(アドレス:Ｂ、ポート:８０)に向けて、セグメントサイズが１４６０バイト、パケットサイズが１５００バイトのデータを送る。送信端末４２１から出力されたデータは、ルータ４２２(アドレス:Ｃ)に供給される。送信端末４２１からのデータを受信したルータ４２２は、次のホップが「ＭＴＵ＝５００」の区間であるため、ICMP Destination Unreachable・フラグメント要求メッセージに、次のホップのＭＴＵを入れて送信端末４２１に向けて送る。ルータ４２２からのICMP Destination Unreachable・フラグメント要求メッセージは送信端末４２１に供給される。

送信端末４２１は、フラグメント要求メッセージに応じてセグメントサイズを４６０バイト、パケットサイズを５００バイトとしてデータを受信端末４２３に向けて再送する。ルータ４２２は、送信端末４２１からの再送データのパケットサイズが５００バイトであるため、送信端末４２１からの再送データを受信端末４２３へ送信する。この結果、受信端末４２３に再送データのパケットが届き、送信端末４２１と受信端末４２３の間で、引き続きデータのやり取りを行うことが可能となる。

しかしながら、従来の両側透過型のセッション中継装置においては、Path MTU discoveryに基づく動作が実行された場合に、以下のような問題が生じる。

図７は、従来の両側透過型のセッション中継装置における、ＴＣＰを用いた場合のPath MTU Discovery問題を説明するための図である。図７に示す例では、送信端末４３１と受信端末４３４の間にセッション中継装置４３２が配置され、さらに受信端末４３４とセッション中継装置４３２の間にルータ４３３が配置されている。送信端末４３１からルータ４３３への経路のＭＴＵは１５００とされ、ルータ４３３から受信端末４３４への経路のＭＴＵは５００とされている。ＩＰ、ＴＣＰのヘッダサイズの合計は４０バイトとしている。

送信端末４３１が、受信端末４３４に向けて、シーケンス番号１-１４６０、パケットサイズ１５００バイトのデータを送る。経路の途中にあるセッション中継装置４３２は、ＡＣＫを終端して、送信端末４３１に返す。その後、セッション中継装置４３２は、受信端末４３４に向けてシーケンス番号１-１４６０のデータを送る。

セッション中継装置４３２から送出されたシーケンス番号１-１４６０は、ＭＴＵ=５００区間の直前に配置されたルータ４３３に供給される。ルータ４３３は、パケットサイズ１５００バイトのデータを転送することはできないため、送信端末４３１に向けてICMP Destination Unreachable・フラグメント要求メッセージ(ＭＴＵ＝５００)を送る。

セッション中継装置４３２は、ＩＣＭＰパケットを素通しにするため、ルータ４３３からのICMP Destination Unreachable・フラグメント要求メッセージ(ＭＴＵ＝５００)は、そのままの形で送信端末４３１に届く。送信端末４３１は、ICMP Destination Unreachable・フラグメント要求メッセージ(ＭＴＵ＝５００)に従って、送信するパケットサイズを５００バイトに下げたシーケンス番号１５０１-１９６０のデータを受信端末４３４に向けて送信する。

セッション中継装置４３２では、受信側から応答パケットを未だ受け取っていないため、パケットサイズが１５００バイトの、シーケンス番号１-１４６０のパケットを再送し続ける。このため、送信端末４３１からのシーケンス番号１５０１-１９６０のデータは送信されることなくセッション中継装置４３２内に蓄積され、シーケンス番号１５０１-１９６０のデータをルータ４３３から先に送ることができない。ルータ４３３は、セッション中継装置４３２から再送されたシーケンス番号１-１４６０のパケットを受信するたびに、再び送信端末４３１に向けてICMP Destination Unreachable・フラグメント要求メッセージ(ＭＴＵ＝５００)を送る。

上述のように、セッション中継装置４３２は、受信側からの応答パケットを受け取るまでは、シーケンス番号１-１４６０のパケットをパケットサイズが１５００バイトのままで再送し続けるため、送信端末４３１から最大セグメントサイズを小さくしたシーケンス番号１５０１-１９６０のデータを受信しても、その受信したデータをルータ４３３に向けて送出することはない。この結果、セッション中継装置４３２に、送信端末４３１からのデータが溜まってしまい、最終的には通信が完全に止まってしまう。

なお、送信端末４３１に、ICMP Destination Unreachable・フラグメント要求メッセージ内のエラーを起こしたヘッダ情報にあるセッション情報のシーケンス番号の不整合性をチェックする機能を持たせることが可能である。しかし、この場合は、通知されたシーケンス番号が送信確認済みになっているシーケンス番号であるため、送信端末４３１は、ICMP Destination Unreachable・フラグメント要求メッセージを受信しても、送信するパケットサイズを下げることはない。

また、特許文献３には、ＩＣＭＰのエラーパケットを、両側で透過的なＴＣＰ中継器で終端させる手法が記載されている。しかし、この場合は、ＴＣＰ中継器において、セグメントの再構成・分割を行う必要があるため、処理コストが大きくなるという問題がある。

本発明の目的は、上記のPath MTU discoveryに基づく動作の問題を解決し、セグメントの再構成・分割を行うことなく、送信元から再送されたデータパケットを送信先へ確実に送信することのできる、処理コストの低いセッション中継装置を提供することにある。

上記目的を達成するため、本発明は、送信するセグメントの順番を示すシーケンス番号が付与されたパケットによりデータが送受信される端末間に配置され、送信側の端末との間に開設される第１のセッションと、受信側の端末との間に開設される第２のセッションとの間で、前記パケットにより送信されたデータの中継を行うセッション中継装置であって、前記第１および第２のセッションの情報を保持するセッション状態保持部と、前記第１のセッションを通じて前記パケットを受信すると、前記セッション状態保持部に保持されたセッション情報を参照して、該受信したパケットのセグメントが、前記第１のセッションを通じてすでに受信してあるパケットのセグメントとシーケンス番号が同じで、セグメントサイズが異なる再送セグメントであるか否かを判断するセグメント再送判定部と、前記セグメント再送判定部で前記受信したパケットのセグメントが再送セグメントであると判断された場合に、該再送セグメントを前記第２のセッションを通じて送信するセグメント再送部とを有する。この場合、第２のセッションの最大セグメントサイズは、送信側の端末から受信した再送セグメントのセグメントサイズでを更新されてもよく、また、第２のセッションを通じて受信したフラグメント要求メッセージ内の最大転送単位に基づいて更新されてもよい。

上記の本発明のセッション中継装置によれば、送信元からの再送セグメントは送信先に向けて送出されるので、従来のような、再送セグメントがセッション中継装置に蓄積されて、通信が止まってしまう、という問題は生じない。

また、再送セグメントは、送信元においてセグメントの分割がなされているので、セグメントの再構成・分割を行う必要もない。

本発明によれば、送信端末からの再送セグメントは、フラグメント要求メッセージを送出した中継装置に向けて必ず送信されるので、通信不能に陥ることなく、送信端末と受信端末の間で安定した通信状態を維持することができる、という効果がある。

また、Path MTU discoveryが働いても、送信端末側で、フラグメント化要求エラーメッセージに応じて、Path MTUにあったパケットに不整合なく分割されて送出され、セッション中継装置において、そのような分割を行う必要がないので、処理コストを最小限に抑えたセッション中継が可能となる、という効果がある。

従来の両側透過型セッション中継器の構成を示すブロック図である。 図１に示すセッション中継器を備えるネットワーク構成を示すブロック図である。 図２に示すネットワーク構成におけるセッション中継器によるＴＣＰ中継のシーケンス動作を説明するための図である ICMP Destination Unreachable（到達不可）・フラグメント要求メッセージのパケット構成を説明するための図である。 ICMP Destination Unreachable（到達不可）・フラグメント要求メッセージに含まれる、エラーを起こしたペット部分の構成を説明するための示す図である。 従来の両側透過型のセッション中継装置におけるPath MTU Discoveryに基づく動作を説明するための図である。 従来の両側透過型のセッション中継装置における、ＴＣＰを用いた場合のPath MTU Discovery問題を説明するための図である。 本発明の第１の実施形態であるセッション中継装置の構成を示すブロック図である。 図８に示すセッション中継装置を備えたネットワーク構成を示すブロック図である。 図８に示すセッション中継部のセッション中継処理部の構成を示すブロック図である。 図８に示す送信確認パケット転送・終端判定部の構成を示すブロック図である。 図８に示すセッション中継部の動作を説明するためのフローチャートである。 図８に示す送信確認パケット転送・終端判定部の動作を説明するためのフローチャートである。 本発明の第２の実施形態であるセッション中継装置の構成を示すブロック図である。 図１４に示すセッション中継装置を備えたネットワーク構成を示すブロック図である。 図１４に示すセッション中継部のセッション中継処理部の構成を示すブロック図である。 図１４に示す送信確認パケット転送・終端判定部の構成を示すブロック図である。 図１４に示すセッション中継部の動作を説明するためのフローチャートである。 図１６に示すＳＭＳＳ送出シーケンス番号算出部の動作を説明するためのフローチャートである。 図１６に示すＭＴＵチェック部の動作を説明するためのフローチャートである。 図１４に示す送信確認パケット転送・終端判定部の動作を説明するためのフローチャートである。 本発明の第３の実施形態であるセッション中継装置の構成を示すブロック図である。 図２２に示すセッション中継装置を備えたネットワーク構成を示すブロック図である。 図２２に示すセッション中継部の構成を示すブロック図である。 図２２に示すフラグメント要求メッセージ転送部の構成を示すブロック図である。 図２２に示す送信確認パケット転送・終端判定部の構成を示すブロック図である。 図２２に示すセッション中継部の動作を説明するためのフローチャートである。 図２４に示すＳＭＳＳ送出シーケンス番号算出部の動作を説明するためのフローチャートである。 図２２に示す送信確認パケット転送・終端判定部の動作を説明するためのフローチャートである。 セグメントを破棄する場合の手順を示すフローチャートである。 セグメントを破棄せずに送信端末に送信する場合の手順を示すフローチャートである。

符号の説明

１１０ セッション中継装置
１１０−１ パケット入力部
１１０−３ セッション中継部
１１０−４ パケット出力部
１１０−５ パケット入力部
１１０−６ セッションパケット判定部
１１０−７ 送信確認受信部
１１０−８ セッション状態保持部
１１０−９ 送信確認パケット転送・終端判定部
１１０−１０ 送信確認送信部
１１０−１１ パケット出力部
１１０−１２ エラー報告プロトコル終端部
１１０−１３ フラグメント要求メッセージ転送部

次に、本発明を実施するための最良の形態について図面を参照にして詳細に説明する。

本発明は、送信するセグメントの順番を示すシーケンス番号が付与されたパケットによりデータが送受信される端末間に配置され、送信側の端末との間に開設される第１のセッションと、受信側の端末との間に開設される第２のセッションとの間で、パケットにより送信されたデータの中継を行うセッション中継装置であって、第１および第２のセッションの情報を保持するセッション状態保持部を備え、第１のセッションを通じてパケットを受信すると、セッション状態保持部に保持されたセッション情報を参照して、該受信したパケットのセグメントが、第１のセッションを通じてすでに受信してあるパケットのセグメントとシーケンス番号が同じで、セグメントサイズが異なる再送セグメントであるか否かを判断し、再送セグメントであると判断した場合に、第２のセッションの最大セグメントサイズを変更して、再送セグメントを第２のセッションを通じて送信するように構成されていることを特徴とする。

送信側の端末は、送信端末、ルータ、セッション中継装置などである。受信側の端末は、受信端末、ルータ、セッション中継装置などである。セッション状態保持部は、送信端末と受信端末を接続する複数のネットワークそれぞれにおけるセッションの情報を保持することが可能である。第２のセッションの最大セグメントサイズは、再送セグメントのセグメントサイズで更新してもよく、また、フラグメント要求メッセージ内の「次のホップの最大転送単位」に基づいて更新してもよい。

以下、第１の実施形態として、セッションの最大セグメントサイズを再送セグメントのセグメントサイズにより更新する形態を、第２、第３の実施形態として、セッションの最大セグメントサイズをフラグメント要求メッセージ内の「次のホップの最大転送単位」に基づいて更新する形態をそれぞれ挙げて、本発明の構成を具体的に説明する。

（第１の実施形態）
図８は、本発明の第１の実施形態であるセッション中継装置の構成を示すブロック図である。図９は、図８に示すセッション中継装置を備えたネットワーク構成を示すブロック図である。

図９に示すネットワーク構成では、送信端末１０と受信端末２０の間に中継装置４０が配置され、さらに送信端末１０と中継装置４０の間にセッション中継装置１１０が配置されている。中継装置４０は、例えばルータである。ここでは、送信端末１０から受信端末２０へデータを送る場合に、セッション中継装置１１０がデータの中継を実現する場合を想定して具体的な処理を説明する。説明の簡単化のために、セッション開設に必要な処理および構成は省略し、また、セッションのデータは一方向に流れるものとする。セッション開設処理は、図１に示したセッション中継装置における動作で説明したとおりである。

図８を参照すると、セッション中継装置１１０の主要部は、パケット入力部１１０−１、セッション中継部１１０−３、パケット出力部１１０−４、パケット入力部１１０−５、セッションパケット判定部１１０−６、送信確認受信部１１０−７、セッション状態保持部１１０−８、送信確認パケット転送・終端判定部１１０−９、送信確認送信部１１０−１０、パケット出力部１１０−１１、エラー報告プロトコル終端部１１０−１２およびフラグメント要求メッセージ転送部１１０−１３からなる。

パケット入力部１１０−１は、送信端末１０からのパケットが入力される。セッション中継部１１０−３は、パケット入力部１１０−１に入力されたパケットのセッション中継処理を行う。パケット出力部１１０−４は、セッション中継部１１０−３からのパケットを受信端末２０に向けて出力する。

パケット入力部１１０−５は、受信端末２０からのパケットが入力される。セッションパケット判定部１１０−６は、パケット入力部１１０−５に入力されたパケットがセッションパケットであるか否かを判定する。セッションパケットであると判断されたパケットは、セッションパケット判定部１１０−６から送信確認受信部１１０−７に供給される。セッションパケットでないと判断されたパケットは、セッションパケット判定部１１０−６からエラー報告プロトコル終端部１１０−１２に供給される。

送信確認受信部１１０−７は、受信端末２０から送出された、セッションの応答パケットである送信確認パケットを、パケット入力部１１０−５およびセッションパケット判定部１１０−６を通じて受信する。セッション状態保持部１１０−８は、セッション中継部１１０−３によって中継されたセッションの状態を保持する。

送信確認パケット転送・終端判定部１１０−９は、送信確認受信部１１０−７で受信された送信確認パケットに対して、転送するか、終端して通常のセッション中継処理を行うかの判断を行う。送信確認送信部１１０−１０は、送信確認パケットを送信端末１０へ送る。パケット出力部１１０−１１は、供給されたパケットを送信端末１０に出力する。エラー報告プロトコル終端部１１０−１２は、エラー報告プロトコルを終端する。フラグメント要求メッセージ転送部１１０−１３は、エラー報告プロトコルのフラグメント要求メッセージをエラー報告プロトコル終端部１１０−１２から抜きだして送信端末１０へ送出する。

図８に示したセッション中継装置１１０では、送信端末１０から送出されたパケットはパケット入力部１１０−１を介してセッション中継部１１０−３に供給される。セッション中継部１１０−３は、パケット入力部１１０−１からパケットが入力されると、その入力されたパケットのセッション中継処理を行う。

図１０に、セッション中継部１１０−３のセッション中継処理部の構成を示す。図１０を参照すると、セッション中継処理部は、パケット入力部１１０−１からのパケットをバッファリングするバッファリング部１１０−３−１、バッファリングされたセグメントがセグメントサイズを変えて再送されたものであるか否かを判断するセグメント再送判定部１１０−３−２、セグメントサイズを変えて再送されたセグメントである場合に、セッションの最大セグメントサイズ(以下、ＳＭＳＳと記す)を更新するＳＭＳＳ更新部１１０−３−３、セグメントサイズを変えて再送されたセグメントを再送するセグメント再送部１１０−３−４、セグメントサイズを変えて再送されたものでないセグメントに対して通常の中継処理を行う通常セッション中継部１１０−３−５を有する。

セッション中継部１１０−３では、セグメント再送判定部１１０−３−２によって、送信端末１０からのセグメントがセグメントサイズを変えて再送されてきたものか否かが判断される。セグメントサイズを変えて再送されてきたセグメントである場合は、セグメント再送部１１０−３−４により、その再送セグメントが、無条件もしくは再送を含む任意のタイミングで受信端末２０に向けて送出される。ここで、「セグメントサイズを変えて再送」とは、開始シーケンス番号が同じで、セグメントサイズが異なる再送セグメントを指す。「再送を含む任意のタイミング」とは、一定時間またはランダムな時間によって規定されるタイミングである。セグメント再送判定部１１０−３−２の判定条件に、再送セグメントが受信端末２０に未到達である、という条件、または、再送セグメントサイズがＳＭＳＳ以下である、という条件を加えてもよく、また、これら条件の双方を満たす、という条件を加えてもよい。

また、セッション中継部１１０−３では、バッファリングされたセグメントがセグメントサイズを変えて再送されてきたものである場合に、ＳＭＳＳ更新部１１０−３−３により、ＳＭＳＳがその再送セグメントサイズに更新される。ＳＭＳＳ更新の条件として、送信確認済みの最大セグメントサイズが、セッション状態保持部１１０−８に登録されている、セッション開設時にネゴシエーションされた最大セグメントサイズに満たない場合という条件を加えてもよい。また、送出されたパケットの時刻スタンプとそのセグメントサイズをセッション状態保持部１１０−８に保持するようにしてもよい。

なお、ＳＭＳＳの初期値は、セッションの開設時に受信端末２０に通知したセグメントサイズとする。送信確認済みの最大セグメントサイズは、具体的には、送信確認パケット内の送信確認シーケンス番号の増加量の最大値で与えられる。例えば、第１から第４の送信確認パケットを順次受信した場合で、第１の送信確認パケットの送信確認シーケンス番号が０、第２の送信確認パケットの送信確認シーケンス番号が５００、第３の送信確認パケットの送信確認シーケンス番号が１５００、第４の送信確認パケットの送信確認シーケンス番号が２２５０である場合は、第２、第３、第４の送信確認パケットにおける送信確認シーケンス番号の増加量はそれぞれ５００、１０００、７５０となる。この場合の送信確認済みの最大セグメントサイズは１０００となる。

また、図８に示したセッション中継装置１１０では、受信端末２０または中継装置４０から送出されたパケットはパケット入力部１１０−５を通じてセッションパケット判定部１１０−６に供給される。セッションパケット判定部１１０−６では、パケット入力部１１０−５からパケットが入力されると、その入力されたパケットがセッション状態保持部１１０−８に登録されているセッションパケットであるか否かが判断される。入力されたパケットがセッションパケットである場合は、セッションパケット判定部１１０−６は、入力されたパケット（送信確認パケット）を送信確認受信部１１０−７に渡す。入力されたパケットがセッションパケットでない場合は、セッションパケット判定部１１０−６は、入力されたパケット（エラー報告プロトコル）をエラー報告プロトコル終端部１１０−１２に渡す。

セッションパケット判定部１１０−６から送信確認受信部１１０−７にセッションパケット（送信確認パケット）が供給された場合は、送信確認パケット転送・終端判定部１１０−９が、その送信確認パケットをパケット出力部１１０−１１に転送するか、送信確認パケットを終端して通常のセッション中継を行うかの判断を行う。

図１１に、送信確認パケット転送・終端判定部１１０−９の主要部を示す。図１１を参照すると、送信確認パケット転送・終端判定部１１０−９は、ＳＭＳＳに基づいて送信確認パケットの終端開始を判断する送信確認パケット終端判定部１１０−９−１と、送信確認パケットを転送する送信確認パケット転送部１１０−９−２と、通常のセッション中継処理を開始し、送信確認パケットの転送を止める送信確認パケット終端開始部１１０−９−３とを備える。

送信確認パケット終端判定部１１０−９−１は、未確認の送信シーケンス番号（送信端末との間に開設されるセッションの開始パケットのシーケンス番号に対応する）と受信端末２０からの送信確認パケットの送信確認シーケンス番号の差分（送信確認済みの最大セグメントサイズに対応する）を取り、このシーケンス番号差分がＳＭＳＳのｎ倍（ＳＭＳＳの倍数で与えられる設定値）に達するか否かを判断する。セッションプロトコルとして代表的なＴＣＰにおいて、送信確認パケットは、設定によって、受信パケット１個につき１個送られてくる、もしくは、受信パケット２個につき１個送られてくる（所謂、遅延応答）。実装によっては、送信確認パケットは、受信パケットｎ（ｎは自然数）個につき１個送られてくるという場合もある。したがって、「ＳＭＳＳのｎ倍」のｎは、遅延応答の有無により異なる。

セッション開設直後およびシーケンス番号の差分がＳＭＳＳのｎ倍に達するまでの間は、送信確認パケット転送部１１０−９−２が、送信確認受信部１１０−７からの送信確認パケットをパケット出力部１１０−１１に転送し、送信確認送信部１１０−１０は、送信確認パケットの送出を行わない。シーケンス番号の差分がＳＭＳＳのｎ倍に達した後は、送信確認パケット転送部１１０−９−２による送信確認パケットの転送は実行されず、送信確認パケット終端開始部１１０−９−３が、送信確認受信部１１０−７からの送信確認パケットを終端して、送信確認送信部１１０−１０による送信確認パケットの送信を開始させる。なお、ＳＭＳＳが時刻スタンプと関連付けられてセッション状態保持部１１０−８に格納されている場合は、受信端末２０からの送信確認パケット内の時刻スタンプに基づいてセッション状態保持部１１０−８からその時刻スタンプと関連付けられたＳＭＳＳの値を取得し、その取得したＳＭＳＳの値をシーケンス番号差分の代わりに使っても良い。

セッションパケット判定部１１０−６からエラー報告プロトコル終端部１１０−１２にパケット（エラー報告プロトコル）が供給された場合は、エラー報告プロトコル終端部１１０−１２にて、エラー報告プロトコルが終端される。そして、フラグメント要求メッセージ転送部１１０−１３が、エラー報告プロトコルのフラグメント要求メッセージをエラー報告プロトコル終端部１１０−１２から抜きだして送信端末１０へ送出する。

次に、本実施形態のセッション中継装置の動作を具体的に説明する。図１２に、送信端末１０から受信端末２０への通信方向での、本実施形態のセッション中継装置の動作を示し、図１３に、受信端末２０から送信端末１０への通信方向での、本実施形態のセッション中継装置の動作を示す。

まず、図１２を参照して、セッション開設処理が終わった直後に送信端末１０からデータパケットが来た場合のセッション中継装置１１０の動作を説明する。

セッション開設直後は、送信確認パケット転送部１１０−９−２が、送信確認受信部１１０−７からの送信確認パケットをパケット出力部１１０−１１に転送し、送信確認送信部１１０−１０は送信確認パケットの送出を行わない。

パケット入力部１１０−１から入力されたデータパケットは、セッション中継部１１０−３に供給される。セッション中継部１１０−３では、供給されたパケットがバッファリング部１１０−３−１にてバッファリングされて保持される（ステップＡ１０１）。次いで、セグメント再送判定部１１０−３−２が、バッファリング部１１０−３−１に保持されたセグメントがセグメントサイズの異なる再送セグメントであるか否かを判断する。この段階では、バッファリング部１１０−３−１に保持されたセグメントはセグメントサイズの異なる再送セグメントでないため、ステップＡ１０２の判断は、「いいえ」となる。

ステップＡ１０２の判断が「いいえ」となると、通常セッション中継部１１０−３−５にて、通常のセッション中継処理が行われる（ステップＡ１０５）。この通常のセッション中継処理では、バッファリング部１１０−３−１に保持されたセグメントがパケット出力部１１０−４から受信端末２０へ向けて出力される。

セッション中継装置１１０から受信端末２０へ向けて送出されたセグメントは、中継装置４０に受信される。中継装置４０は、受信したセグメントのサイズがＭＴＵより大きな場合は、エラー報告プロトコルのフラグメント要求メッセージを送信端末１０に向けて送出する。このエラー報告プロトコルのフラグメント要求メッセージは、セッション中継装置１１０にて受信される。

次に、図１３を参照して、中継装置４０からのエラー報告プロトコルのフラグメント要求メッセージを受信した場合の、セッション中継装置１１０の動作を説明する。

受信端末２０側からのパケットがパケット入力部１１０−５に入力される（ステップＡ２０１）。パケット入力部１１０−５に入力されたパケットはセッションパケット判定部１１０−６に供給され、セッションパケット判定部１１０−６において、その入力パケットがセッションパケットであるか否かの判断が行われる（ステップＡ２０２）。ここでは、受信端末２０側からのパケットは、中継装置４０が送信端末１０に対して送出したエラー報告プロトコルのフラグメント要求メッセージであるので、ステップＡ２０２の判断は「いいえ」となる。

ステップＡ２０２の判断が「いいえ」となると、セッションパケット判定部１１０−６は、パケット入力部１１０−５からの入力パケットをエラー報告プロトコル終端部１１０−１２に渡し、エラー報告プロトコル終端部１１０−１２にて、その入力パケットがエラー報告プロトコルであるか否かの判断が行われる（ステップＡ２０３）。ここでは、入力パケットは、中継装置４０が送信端末１０に対して送出したエラー報告プロトコルのフラグメント要求メッセージであるので、ステップＡ２０３の判断は「はい」となる。

ステップＡ２０３の判断が「はい」となると、エラー報告プロトコル終端部１１０−１２はパケット入力部１１０−５からの入力パケットをフラグメント要求メッセージ転送部１１０−１３に渡し、フラグメント要求メッセージ転送部１１０−１３にて、供給されたパケットがフラグメント要求メッセージであるか否かの判断が行われる（ステップＡ２０４）。ここでは、エラー報告プロトコル終端部１１０−１２に供給されたパケットはフラグメント要求メッセージであるので、ステップＡ２０４の判断は「はい」となる。

ステップＡ２０４の判断が「はい」となると、フラグメント要求メッセージ転送部１１０−１３は、エラー報告プロトコルのフラグメント要求メッセージをエラー報告プロトコル終端部１１０−１２から抜きだしてパケット出力部１１０−１１を通じて送信端末１０へ送出する(ステップＡ２０５)。

セッション中継装置１１０からフラグメント要求メッセージを受信した送信端末１０は、その受信したフラグメント要求メッセージに従い、セグメントサイズを低くしたパケットを受信端末２０に向けて再送する。

次に、図１２を参照して、送信端末１０からセグメントサイズを低くしたパケットが来た場合の、セッション中継装置１１０の動作を説明する。

送信端末１０からのパケットはパケット入力部１１０−１からセッション中継部１１０−３に供給される。セッション中継部１１０−３では、供給されたパケットがバッファリング部１１０−３−１にてバッファリングされて保持される（ステップＡ１０１）。次いで、セグメント再送判定部１１０−３−２が、バッファリング部１１０−３−１に保持されたセグメントがセグメントサイズの異なる再送セグメントであるか否かを判断する。この段階では、バッファリング部１１０−３−１に保持されたセグメントはセグメントサイズの異なる再送セグメントであるため、ステップＡ１０２の判断は「はい」となる。

ステップＡ１０２の判断が「はい」となると、ＳＭＳＳ更新部１１０−３−３がＳＭＳＳをその再送セグメントサイズで更新する（ステップＡ１０３）。そして、セグメント再送部１１０−３−４が、再送セグメントをパケット出力部１１０−４を通じて、無条件もしくは再送を含む任意のタイミングで受信端末に向けて送信する（ステップＡ１０４）。

セグメント再送部１１０−３−４により送信された再送セグメントのサイズは、中継装置４０が送信元に対して返したフラグメント要求メッセージ通りのサイズとなっているため、再送セグメントは中継装置４０を通過して受信端末２０に到達する。受信端末２０は、再送セグメントを受信すると、送信確認パケットを送信端末１０に向けて送信する。この送信確認パケットは、中継装置４０を介してセッション中継装置１１０にて受信される。

次に、図１３を参照して、受信端末２０から送信確認パケットを受信した場合の、セッション中継装置１１０の動作を説明する。

受信端末２０側からのパケットがパケット入力部１１０−５に入力される（ステップＡ２０１）。パケット入力部１１０−５に入力されたパケットはセッションパケット判定部１１０−６に供給され、セッションパケット判定部１１０−６において、その入力パケットがセッションパケットであるか否かの判断が行われる（ステップＡ２０２）。ここでは、受信端末２０側からのパケットは、送信確認パケットであるので、ステップＡ２０２の判断は「はい」となる。

ステップＡ２０２の判断が「はい」となると、送信確認受信部１１０−７が、送信確認受信処理を行う(ステップＡ２０６)。次いで、送信確認パケット終端判定部１１０−９−１が、送信確認済みの最大セグメントサイズを算出し（ステップＡ２０７）、その算出した送信確認済みの最大セグメントがＳＭＳＳのｎ倍（ｎは自然数）であるか否かを判断する（ステップＡ２０８）。このフローでは、遅延応答は行われていないため、送信済み確認パケットは、設定によって、受信パケット１個につき１個、受信側から返ってくる。よって、このステップＡ２０８では、ステップＡ２０７で算出した送信確認済みの最大セグメントはＳＭＳＳの１倍であるか否かの判断が行われる。送信確認済みの最大セグメントはＳＭＳＳの１倍であるので、ステップＡ２０８の判断は「はい」となる。

ステップＡ２０８の判断が「はい」となると、送信確認パケット終端開始部１１０−９−２が、受信したパケットに対して送信確認パケットを送出する送信確認処理の開始を送信確認送信部１１０−１０に伝える(ステップＡ２０９)。その後、受信側からの送信確認パケットは終端され、送信端末１０には転送されない。このようにして、受信側からの送信確認パケットはセッション中継器１１０で終端され、送信確認送信部１１０−１０による送信確認パケットの送信端末１０への送信処理が開始されることになる。

以上説明した本実施形態のセッション中継装置によれば、送信端末１０からの再送セグメントは、必ず中継装置４０に向けて送信される。よって、通信不能に陥ることなく、送信端末１０と受信端末２０の間で安定した通信状態を維持することができる。

また、本実施形態のセッション中継装置によれば、セッション開設直後は、受信側からの送信確認パケットをそのまま送信端末に転送するようになっているので、セッション中継装置において、送信端末からのパケットのオーバーフローによるデッドロックを回避することができる。

（第２の実施形態）
図１４は、本発明の第２の実施形態であるセッション中継装置の構成を示すブロック図である。図１５は、図１４に示すセッション中継装置を備えたネットワーク構成を示すブロック図である。

図１５に示すネットワーク構成では、送信端末１０と受信端末２０の間に中継装置４０が配置され、さらに送信端末１０と中継装置４０の間にセッション中継装置１２０が配置されている。送信端末１０、受信端末２０および中継装置４０は、図９に示したネットワーク構成と同様のものである。前述の第１の実施形態の場合と同様、ここでも、送信端末１０から受信端末２０へデータを送る場合に、セッション中継装置１２０がデータの中継を実現する場合を想定して具体的な処理を説明する。説明の簡単化のために、セッション開設に必要な処理および構成は省略し、また、セッションのデータは一方向に流れるものとする。セッション開設処理は、図１に示したセッション中継装置における動作で説明したとおりである。

図１４を参照すると、本実施形態のセッション中継装置１２０は、送信端末１０からのパケットが入力されるパケット入力部１２０−１、パケット入力部１２０−１からのパケットのセッション中継処理を行うセッション中継部１２０−３、セッション中継部１２０−３からのパケットを受信端末２０側へ出力するパケット出力部１２０−４、受信端末２０側からのパケットが入力されるパケット入力部１２０−５、パケット入力部１２０−５からのパケットがセッションパケットであるか否かを判定するセッションパケット判定部１２０−６、セッションの応答パケットである送信確認パケットを受信する送信確認受信部１２０−７、セッションの状態を保持するセッション状態保持部１２０−８、送信確認パケットを転送するか、送信確認パケットを終端して通常のセッション中継を行うかを判断する送信確認パケット転送・終端判定部１２０−９、送信確認パケットを送信端末１０側へ送る送信確認送信部１２０−１０、送信端末１０に向けてパケットを出力するパケット出力部１２０−１１、エラー報告プロトコルを終端するエラー報告プロトコル終端部１２０−１２、エラー報告プロトコルのフラグメント要求メッセージをエラー報告プロトコル終端部１２０−１２から抜きだして送信端末１０へ送出するフラグメント要求メッセージ転送部１２０−１３、フラグメント要求メッセージ転送部１２０−１３から通知された最大転送単位を記憶する最大転送単位記憶部１２０−１４を有する。

セッション中継装置１２０では、送信端末１０から送出されたパケットはパケット入力部１２０−１を介してセッション中継部１２０−３に供給される。セッション中継部１２０−３は、パケット入力部１２０−１からパケットが入力されると、その入力されたパケットのセッション中継処理を行う。

図１６に、セッション中継部１２０−３のセッション中継処理部の構成を示す。図１６を参照すると、セッション中継処理部１２０−３は、ＭＴＵチェック部１２０−３−０、バッファリング部１２０−３−１、セグメント再送判定部１２０−３−２、セグメント再送部１２０−３−３、通常セッション中継部１２０−３−４およびＳＭＳＳ送出シーケンス番号算出部１２０−３−５からなる。

ＭＴＵチェック部１２０−３−０は、セッション状態保持部１２０−８に保持されている、パケット入力部１２０−１を通じて入力されたパケットに関するセッション情報と、最大転送単位記憶部１２０−１４に格納されている、送信先以上の情報に対応するＭＴＵとを参照して、ＳＭＳＳを更新する。ここで、「送信先以上の情報」とは、送信先の情報または送信先および送信元の各情報を指す。セッションプロトコルとして代表的なＴＣＰの場合、送信先の情報は、（Ａ−１）送信アドレス、（Ａ−２）送信先ポートという情報を含み、送信元の情報は、（Ａ−３）送信元アドレス、（Ａ−４）送信元ポートという情報を含む。この場合における「送信先以上の情報」は、少なくとも（Ａ−１）の情報を含むものであって、以下のような９個の組み合わせのいずれかである。
（１）（Ａ−１）の情報のみ。
（２）（Ａ−１）＋（Ａ−２）の情報。
（３）（Ａ−１）＋（Ａ−２）＋（Ａ−３）の情報。
（４）（Ａ−１）＋（Ａ−２）＋（Ａ−３）＋（Ａ−４）の情報
（５）（Ａ−１）＋（Ａ−３）の情報。
（７）（Ａ−１）＋（Ａ−４）の情報。
（８）（Ａ−１）＋（Ａ−２）＋（Ａ−４）の情報。
（９）（Ａ−１）＋（Ａ−３）＋（Ａ−４）の情報。

バッファリング部１２０−３−１は、パケット入力部１２０−１からのパケットをバッファリングする。セグメント再送判定部１２０−３−２は、バッファリング部１２０−３−１にバッファリングされたセグメントがセグメントサイズを変えて再送されたものか否かを判断する。セグメント再送部１２０−３−３は、サイズを変えて再送されたセグメントを再送する。通常セッション中継部１２０−３−４は、サイズを変えて再送されたものでないセグメントを中継する。ＳＭＳＳ送出シーケンス番号算出部１２０−３−５は、ＳＭＳＳと等しい最小シーケンス番号を算出・更新する。ここで、「ＳＭＳＳと等しい最小シーケンス番号」とは、ＴＣＰの場合、ＴＣＰのセグメントサイズがＳＭＳＳに初めて達したときのシーケンス番号を指す。具体的には、ＳＭＳＳが１４００バイトの場合で、
・シーケンス番号＝１、セグメントサイズ＝５００
・シーケンス番号＝１０１、セグメントサイズ＝５００
・シーケンス番号＝６０１、セグメントサイズ＝１０００
・シーケンス番号＝１６０１、セグメントサイズ＝１４００
・シーケンス番号＝３００１、セグメントサイズ＝４４０１
というセグメントがやり取りされた場合は、「ＳＭＳＳと等しい最小シーケンス番号」は「シーケンス番号＝１６０１」となる。

上記のように構成されたセッション中継部１２０−３では、セグメント再送判定部１２０−３−２にて、送信端末１０からのセグメントがセグメントサイズを変えて再送されてきたものか否かが判断される。そして、セグメントサイズを変えて再送されてきたものである場合は、セグメント再送部１２０−３−４が、その再送セグメントを、無条件もしくは再送を含む任意のタイミングで、受信端末２０に向けて送出する。ここで、「セグメントサイズを変えて再送」とは、開始シーケンス番号が同じで、セグメントサイズが異なる再送セグメントを指す。セグメント再送判定部１２０−３−２の判定条件に、再送セグメントが受信端末２０に未到達である、という条件、または、再送セグメントサイズがＳＭＳＳ以下である、という条件を加えてもよく、また、これら条件の双方を満たす、という条件を加えてもよい。

また、セッション中継部１２０−３では、ＳＭＳＳ送出シーケンス番号算出部１２０−３−５により、送出セグメントサイズがＳＭＳＳと等しい場合のセグメントサイズで最小の送信シーケンス番号(以後、最大送出セグメントに対応する最小シーケンス番号)がセッション状態保持部１２０−８に格納される。更新の条件として、送信確認済み最大セグメントサイズが、セッション状態保持部１２０−８に登録されている、セッション開設時にネゴシエーションされた最大セグメントサイズに満たない場合という条件を加えてもよい。

送出セグメントサイズがＳＭＳＳと等しい場合のセグメントサイズで最小の送信シーケンス番号の格納動作を以下に簡単に説明する。

例えば、中継装置４０の先の経路のＭＴＵが１０００で、送信端末１０が、１５００バイトのデータを、９６０バイトのセグメントと、５４０バイトのセグメントの２つセグメントで送信する場合（この場合のヘッダサイズは４０バイト）、送信端末１０からは、９６０バイトのセグメントを含むパケット（シーケンス番号「１」）と、５４０バイトのセグメントを含むパケット（シーケンス番号「２」）とが順次送出される。セッション中継部１２０−３において、最初のパケット（シーケンス番号「１」）が受信されると、９６０バイトのセグメントがバッファリングされ、ＳＭＳＳは９６０バイトになるように更新される。そして、バッファリングされた９６０バイトのセグメントが、受信端末に向けて送出される。この動作において、送出セグメントサイズはＳＭＳＳと等しくなる。

次いで、２番目のパケット（シーケンス番号「２」）が受信されると、５４０バイトのセグメントがバッファリングされるが、ＳＭＳＳは９６０のままとされる。これは、ＳＭＳＳの更新タイミングは、ＭＴＵが更新されるタイミングであるためである。そして、バッファリングされた５４０バイトのセグメントが、受信端末２０に向けて送出される。

上記の２つのパケット受信の動作において、送出セグメントサイズがＳＭＳＳと等しい場合のセグメントサイズで最小の送信シーケンス番号は、最初のパケット（シーケンス番号「１」）の受信動作の場合における送信シーケンス番号「１」とされ、セッション状態保持部１２０−８には、送信シーケンス番号「１」が格納される。

また、図１４に示したセッション中継装置１２０では、受信端末２０または中継装置４０から送出されたパケットは、パケット入力部１２０−５を通じてセッションパケット判定部１２０−６に供給される。セッションパケット判定部１２０−６では、パケット入力部１２０−５から入力されたパケットがセッション状態保持部１２０−８に登録されているセッションパケットであるか否かが判断される。入力されたパケットがセッションパケットである場合は、セッションパケット判定部１２０−６は、入力されたパケット（送信確認パケット）を送信確認受信部１２０−７に渡す。入力されたパケットがセッションパケットでない場合は、セッションパケット判定部１２０−６は、入力されたパケット（エラー報告プロトコル）をエラー報告プロトコル終端部１２０−１２に渡す。

セッションパケット判定部１２０−６から送信確認受信部１２０−７にセッションパケット（送信確認パケット）が供給された場合は、送信確認パケット転送・終端判定部１２０−９が、送信確認パケットをパケット出力部１２０−１１に転送するか、送信確認パケットを終端して通常のセッション中継を行うかの判断を行う。

図１７に、送信確認パケット転送・終端判定部１２０−９の主要部を示す。図１７を参照すると、送信確認パケット転送・終端判定部１２０−９は、ＳＭＳＳに基づいて送信確認パケットの終端開始を判断する送信確認パケット終端判定部１２０−９−１と、送信確認パケットを転送する送信確認パケット転送部１２０−９−２と、通常のセッション中継処理を開始し、送信確認パケットの転送を止める送信確認パケット終端開始部１２０−９−３とを備える。

送信確認パケット終端判定部１２０−９−１は、受信端末２０からの送信確認パケットの送信確認済みの最大シーケンス番号Ｎ１が最大送出セグメントに対応する最小シーケンス番号Ｎ２以上になったか否かの判断（Ｎ１≧Ｎ２かの判断）を行う。セッション開設直後は、最大シーケンス番号Ｎ１は最小シーケンス番号Ｎ２に未だ達していない（Ｎ１＜Ｎ２）ので、送信確認パケット転送部１２０−９−２が、送信確認受信部１２０−７からの送信確認パケットをパケット出力部１２０−１１に転送し、送信確認送信部１２０−１０は、送信確認パケットの送出を行わない。最大シーケンス番号Ｎ１は最小シーケンス番号Ｎ２に達した後（Ｎ１≧Ｎ２）は、送信確認パケット転送部１２０−９−２による送信確認パケットの転送は実行されず、送信確認パケット終端開始部１２０−９−３が、受信側からの送信確認パケットを終端して、送信確認送信部１２０−１０による送信確認パケットの送信を開始させる。

セッションパケット判定部１２０−６からエラー報告プロトコル終端部１２０−１２にパケット（エラー報告プロトコル）が供給された場合は、エラー報告プロトコル終端部１２０−１２にて、エラー報告プロトコルが終端される。そして、フラグメント要求メッセージ転送部１２０−１３が、エラー報告プロトコルのフラグメント要求メッセージをエラー報告プロトコル終端部１２０−１２から抜きだして送信端末１０へ送出するとともに、その抜き出したフラグメント要求メッセージ内の「次のホップの最大転送単位」を読み出し、最大転送単位記憶部１２０―１４に格納されている送信先以上の情報ごとの最大転送単位の情報をその読み出した「次のホップの最大転送単位」で更新する。ここで、「フラグメント要求メッセージ内の最大転送単位」とは、例えばＴＣＰ／ＩＰであれば、図４中の「Next-HOP MTU」を指す。また、「送信先以上の情報」は、図４中の「Internet Header + 64 bits of Original Data Datagram」内の情報であり、図５中の最低「Destination Address」を含む、「Source Address」、「Source Port」、「Destination Port」の情報を指す。

セッション中継器１２０−３では、セッション中継中のセッションの「送信先以上の情報」をキーとして最大転送単位記憶部１２０−１４を検索して、最大転送単位記憶部１２０−１４内の最大転送単位が更新されているか否かが判断される。最大転送単位が更新されている場合は、更新後の最大転送単位に基づいてＳＭＳＳを更新する。具体的には、あるセッションが、「Src Addr: 192.168.11」、「Src Port: 1234」、「Dst Addr:192.168.2.1」、「Dst Prot: 5001」であり、送信先以上の情報が、「Dst Addr」のみである場合、最大転送単位記憶部１２０−１４を「192.168.2.1」をキーとして最大転送単位を検索する。最大転送単位記憶部１２０−１４内の「192.168.2.1」の最大転送単位が変更されていた場合は、変更後の情報によりＳＭＳＳを更新する。ＳＭＳＳの更新では、例えば「最大転送単位」−「ヘッダサイズ」とする更新が行われる。セッション中継器１２０−３において、ヘッダの付け替えを行い、送信端末１０側の受信ヘッダサイズと受信端末２０側の送信ヘッダサイズが異なる場合は、「ヘッダサイズ」はそれら受信ヘッダサイズおよび送信ヘッダサイズの最大値とされる。

ＭＴＵとセグメントサイズの関係は、ＭＴＵ≧「ヘッダサイズ」＋「セグメントサイズ」となっており、ヘッダサイズは、通信の開設時のヘッダサイズで決まる。経路全体のＭＴＵが１０００バイトで、送信端末１０側の受信ヘッダサイズが５０バイトで、受信端末２０側の送信ヘッダサイズが６０バイトである場合、送信端末１０側からのＳＭＳＳは９４０バイトとされる。この場合、送信端末１０側からのセグメントが９５０バイトのときは、セッション中継器１２０−３によるヘッダ付け替えにより、受信端末２０側へのパケットサイズが１０１０バイトとなって経路全体のＭＴＵを超えてしまい、通信を行うことができないために、ＳＭＳＳが９５０バイトとされることはない。反対に、経路全体のＭＴＵが１０００バイトで、送信端末１０側の受信ヘッダサイズが６０バイトで、受信端末２０側の送信ヘッダサイズが５０バイトである場合、送信端末１０側からのＳＭＳＳは９４０バイトとされる。この場合、送信端末１０側からのセグメントが９５０バイトのときは、パケットサイズが１０１０バイトとなって経路全体のＭＴＵを超えてしまい、その結果、パケットが中継器に到達しないため、ＳＭＳＳが９５０バイトとされることはない。

次に、本実施形態のセッション中継装置の動作を具体的に説明する。図１８に、送信端末１０から受信端末２０への通信方向での、本実施形態のセッション中継装置の動作を示し、図１９に、ＳＭＳＳ送出シーケンス番号算出処理の動作を示す。また、図２０に、ＭＴＵチェック処理の動作を示し、図２１に、受信端末２０から送信端末１０への通信方向での、本実施形態のセッション中継装置の動作を示す。

まず、図１８を参照して、セッション開設処理が終わった直後に送信端末１０からデータパケットが来た場合のセッション中継装置１２０の動作を説明する。

セッション開設直後は、送信確認パケット転送部１２０−９−２が、送信確認受信部１２０−７からの送信確認パケットをパケット出力部１２０−１１に転送し、送信確認送信部１２０−１０は送信確認パケットの送出行わない。この段階におけるＳＭＳＳは、セッション開設時にネゴシエーションされた最大セグメントサイズである。送信先の情報ごとのＭＴＵは、通常のパケットの最大サイズである。

送信端末１０から送出されたパケットは、パケット入力部１２０−１を通じてセッション中継部１２０−３に供給される（ステップＢ１０１）。セッション中継部１２０−３では、送信端末１０からパケットが入力されると、ＭＴＵチェック部１２０−３−０にてＭＴＵチェック処理が行われ（ステップＢ１０２）、供給されたパケットがバッファリング部１２０−３−１にてバッファリングされて保持される（ステップＢ１０３）。

ＭＴＵチェック部１２０−３−０によるＭＴＵチェック処理では、図２０に示すように、まず、送信先の情報ごとのＭＴＵが減少したか否かの判断が行われる（ステップＢ３０１）。この段階では、ＭＴＵは未だ減少していないため、ステップＢ２０１の判断は「いいえ」となり、ＭＴＵチェック処理は終了する。

送信端末１０からのパケットがバッファリング部１２０−３−１にてバッファリングされて保持されると、次いで、セグメント再送判定部１２０−３−２が、バッファリング部１２０−３−１に保持されたセグメントがセグメントサイズの異なる再送セグメントであるか否かを判断する（ステップＢ１０４）。この段階では、バッファリング部１２０−３−１に保持されたセグメントはセグメントサイズの異なる再送セグメントでないため、ステップＢ１０４の判断は「いいえ」となる。

ステップＢ１０４の判断が「いいえ」となると、通常セッション中継部１２０−３−４にて、通常のセッション中継処理が行われる（ステップＢ１０９）。この通常のセッション中継処理では、バッファリング部１２０−３−１に保持されたパケットセグメントがパケット出力部１２０−４に出力される。そして、パケット出力部１２０−４に出力されるパケットに対して、ＳＭＳＳ送出シーケンス番号算出処理部１２０−３−５にて、ＳＭＳＳ送出シーケンス番号算出処理が行われる(ステップＢ１０７)。

ステップＢ１０７のＳＭＳＳ送出シーケンス番号算出処理では、図１９に示すように、まず、送出セグメントサイズがＳＭＳＳに等しいか否かの判断が行われる（ステップＢ２０１）。この段階では、送出セグメントサイズがＳＭＳＳと等しいため、ステップＢ２０１の判断は「はい」となる。ステップＢ２０１の判断が「はい」となると、続いて、セグメントサイズに対応した最初のＳＭＳＳ送出シーケンス番号であるか否かの判断が行われる（ステップＢ２０２）。この段階では、セグメントサイズに対応した最初のＳＭＳＳ送出シーケンス番号であるので、ステップＢ２０２の判断は「はい」となる。ステップＢ２０２の判断が「はい」となると、次いで、ＳＭＳＳ送出シーケンス番号を送出シーケンス番号で更新する処理を行う（ステップＢ２０３）。

上述のようにしてステップＢ１０７のＳＭＳＳ送出シーケンス番号算出処理が行われた後、パケット出力部１２０−４から受信端末２０側へパケットが出力される（ステップＢ１０８）。

セッション中継装置１２０から受信端末２０へ向けて送出されたセグメントは、中継装置４０に受信される。中継装置４０は、受信したセグメントのサイズがＭＴＵより大きな場合は、エラー報告プロトコルのフラグメント要求メッセージを送信端末１０に向けて送出する。このエラー報告プロトコルのフラグメント要求メッセージは、セッション中継装置１２０にて受信される。

次に、図２１を参照して、中継装置４０からのエラー報告プロトコルのフラグメント要求メッセージを受信した場合の、セッション中継装置１２０の動作を説明する。

受信端末２０側からのパケットがパケット入力部１２０−５に入力される（ステップＢ４０１）。パケット入力部１２０−５に入力されたパケットはセッションパケット判定部１２０−６に供給され、セッションパケット判定部１２０−６において、その入力パケットがセッションパケットであるか否かの判断が行われる（ステップＢ４０２）。この段階では、受信端末２０側からのパケットは、中継装置４０が送信端末１０に対して送出したエラー報告プロトコルのフラグメント要求メッセージであるので、ステップＢ４０２の判断は「いいえ」となる。

ステップＢ４０２の判断が「いいえ」となると、セッションパケット判定部１２０−６はパケット入力部１２０−５からの入力パケットをエラー報告プロトコル終端部１２０−１２に渡し、エラー報告プロトコル終端部１２０−１２にて、その入力パケットがエラー報告プロトコルであるか否かの判断が行われる（ステップＢ４０３）。この段階では、入力パケットは、中継装置４０が送信端末１０に対して送出したエラー報告プロトコルのフラグメント要求メッセージであるので、ステップＢ４０３の判断は「はい」となる。

ステップＢ４０３の判断が「はい」となると、エラー報告プロトコル終端部１２０−１２はパケット入力部１２０−５からの入力パケットをフラグメント要求メッセージ転送部１２０−１３に渡し、フラグメント要求メッセージ転送部１２０−１３にて、エラー報告プロトコル終端部１２０−１２に供給されたパケットがフラグメント要求メッセージであるか否かの判断が行われる（ステップＢ４０４）。この段階では、エラー報告プロトコル終端部１２０−１２に供給されたパケットはフラグメント要求メッセージであるので、ステップＢ４０４の判断は「はい」となる。

ステップＢ４０４の判断が「はい」となると、フラグメント要求メッセージ転送部１２０−１３は、エラー報告プロトコルのフラグメント要求メッセージをエラー報告プロトコル終端部１２０−１２から抜き出し、その抜き出したフラグメント要求メッセージ内の最大転送単位に基づいて、最大転送単位記憶部１２０−１４に格納されている、送信先以上の情報ごとの最大転送単位を更新する（ステップＢ４１０）。そして、フラグメント要求メッセージ転送部１２０−１３は、抜き出したフラグメント要求メッセージをパケット出力部１２０−１１を通じて送信端末１０へ送出する(ステップＢ４０５)。

セッション中継装置１２０からフラグメント要求メッセージを受信した送信端末１０は、その受信したフラグメント要求メッセージに従い、セグメントサイズを低くしたパケットを受信端末２０に向けて再送する。

次に、図１８を参照して、送信端末１０からセグメントサイズを低くしたパケットが来た場合の、セッション中継装置１２０の動作を説明する。

送信端末１０からのデータパケットは、パケット入力部１２０−１からセッション中継部１２０−３に供給される（ステップＢ１０１）。セッション中継部１２０−３では、送信端末１０からパケットが入力されると、ＭＴＵチェック部１２０−３−０にてＭＴＵチェック処理が行われ（ステップＢ１０２）、供給されたパケットがバッファリング部１２０−３−１にてバッファリングされて保持される（ステップＢ１０３）。

ＭＴＵチェック部１２０−３−０によるＭＴＵチェック処理では、図２０に示すように、まず、送信先の情報ごとのＭＴＵが減少したか否かの判断が行われる（ステップＢ３０１）。この段階では、ＭＴＵは減少しているため、ステップＢ２０１の判断は「はい」となる。ステップＢ２０１の判断が「はい」となると、続いて、ＳＭＭＳを［「ＭＴＵ」−「ヘッダサイズ」］の値とする。その後、ＭＴＵチェック処理を終了する。

送信端末１０からのパケットがバッファリング部１２０−３−１にてバッファリングされて保持されると、次いで、セグメント再送判定部１２０−３−２が、バッファリング部１２０−３−１に保持されたセグメントがセグメントサイズの異なる再送セグメントであるか否かを判断する（ステップＢ１０４）。この段階では、バッファリング部１２０−３−１に保持されたセグメントはセグメントサイズの異なる再送セグメントであるため、ステップＢ１０４の判断は「はい」となる。

ステップＢ１０４の判断が「はい」となると、セグメント再送部１２０−３−３が、無条件もしくは再送を含む任意のタイミングで、バッファリング部１２０−３−１に保持されたパケットセグメントをパケット出力部１２０−４に出力する(ステップＢ１０６)。そして、パケット出力部１２０−４に出力されるパケットに対して、ＳＭＳＳ送出シーケンス番号算出処理部１２０−３−５にて、ＳＭＳＳ送出シーケンス番号算出処理が行われる(ステップＢ１０７)。

ステップＢ１０７のＳＭＳＳ送出シーケンス番号算出処理では、図１９に示すように、まず、送出セグメントサイズがＳＭＳＳに等しいか否かの判断が行われる（ステップＢ２０１）。この段階では、送出セグメントサイズがＳＭＳＳと等しいため、ステップＢ２０１の判断は「はい」となる。ステップＢ２０１の判断が「はい」となると、続いて、セグメントサイズに対応した最初のＳＭＳＳ送出シーケンス番号であるか否かの判断が行われる（ステップＢ２０２）。この段階では、セグメントサイズに対応した最初のＳＭＳＳ送出シーケンス番号であるので、ステップＢ２０２の判断は「はい」となる。ステップＢ２０２の判断が「はい」となると、次いで、ＳＭＳＳ送出シーケンス番号を送出シーケンス番号で更新する処理を行う（ステップＢ２０３）。

上述のようにしてステップＢ１０７のＳＭＳＳ送出シーケンス番号算出処理が行われた後、パケット出力部１２０−４から受信端末２０側へパケットが出力される（ステップＢ１０８）。

上記パケット出力部１２０−４から送信された再送セグメントのサイズは、中継装置４０が送信元に対して返したフラグメント要求メッセージ通りのサイズとなっているため、再送セグメントは中継装置４０を通過して受信端末２０に到達する。受信端末２０は、再送セグメントを受信すると、その応答パケットである送信確認パケットを送信端末１０に向けて送信する。この送信確認パケットは、中継装置４０を介してセッション中継装置１２０にて受信される。

次に、図２１を参照して、受信端末２０から送信確認パケットを受信した場合の、セッション中継装置１２０の動作を説明する。

受信端末２０側からのパケットがパケット入力部１２０−５に入力される（ステップＢ４０１）。パケット入力部１２０−５に入力されたパケットはセッションパケット判定部１２０−６に供給され、セッションパケット判定部１２０−６において、その入力パケットがセッションパケットであるか否かの判断が行われる（ステップＢ４０２）。この段階では、受信端末２０側からのパケットは、受信端末２０が送信端末１０に向けて送信した送信確認パケット（セッションパケット）であるので、ステップＢ４０２の判断は「はい」となる。

ステップＢ４０２の判断が「はい」となると、セッションパケット判定部１２０−６はパケット入力部１２０−５からの入力パケットを送信確認受信部１２０−７に渡し、送信確認受信部１２０−７にて送信確認受信処理が行われる(ステップＢ４０６)。次いで、送信確認パケット終端判定部１２０−９−１が、［「送信確認済みの最大シーケンス番号」≧「最大送出セグメントに対応する最小シーケンス番号」］の条件を満たすか否かの判断を行う（ステップＢ４０８）。この段階では、その条件を満たすので、送信確認パケット終端開始部１２０−９−２が、送信確認処理の開始を送信確認送信部１２０−１０に伝える(ステップＢ４０９)。その後、送信確認パケットは、送信端末１０には転送されない。
この結果、送信確認パケットはセッション中継器１２０で終端されることになる。

上述した第２の実施形態のセッション中継装置においても、第１の実施形態の場合と同様、送信端末１０からの再送セグメントは、必ず中継装置４０に向けて送信される。よって、通信不能に陥ることなく、送信端末１０と受信端末２０の間で安定した通信状態を維持することができる。

また、セッション開設直後は、受信側からの送信確認パケットをそのまま送信端末に転送するようになっているので、セッション中継装置において、送信端末からのパケットのオーバーフローによるデッドロックを回避することができる。

（第３の実施形態）
図２２は、本発明の第３の実施形態であるセッション中継装置の構成を示すブロック図である。図２３は、図２２に示すセッション中継装置を備えたネットワーク構成を示すブロック図である。

図２２に示すネットワーク構成では、送信端末１０と受信端末２０の間に中継装置４０が配置され、さらに送信端末１０と中継装置４０の間にセッション中継装置１３０が配置されている。送信端末１０、受信端末２０および中継装置４０は、前述の第１および第２の実施形態におけるネットワーク構成と同様のものである。本実施形態でも、送信端末１０から受信端末２０へデータを送る場合に、セッション中継装置１３０がデータの中継を実現する場合を想定して具体的な処理を説明する。説明の簡単化のために、セッション開設に必要な処理および構成は省略し、また、セッションのデータは一方向にながれるものとする。セッション開設処理は、図１に示したセッション中継装置における動作で説明したとおりである。

図２２を参照すると、本実施形態のセッション中継装置１３０は、送信端末１０からのパケットが入力されるパケット入力部１３０−１、パケット入力部１３０−１からのパケットのセッション中継処理を行うセッション中継部１３０−３、セッション中継部１３０−３からのパケットを受信端末２０側へ出力するパケット出力部１３０−４、受信端末２０側からのパケットが入力されるパケット入力部１３０−５、パケット入力部１３０−５からのパケットがセッションパケットであるか否かを判定するセッションパケット判定部１３０−６、セッションの応答パケットである送信確認パケットを受信する送信確認受信部１３０−７、セッションの状態を保持するセッション状態保持部１３０−８、送信確認パケットを転送するか、送信確認パケットを終端して通常のセッション中継を行うかを判断する送信確認パケット転送・終端判定部１３０−９、送信確認パケットを送信端末１０側へ送る送信確認送信部１３０−１０、送信端末１０に向けてパケットを出力するパケット出力部１３０−１１、エラー報告プロトコルを終端するエラー報告プロトコル終端部１３０−１２、エラー報告プロトコルのフラグメント要求メッセージをエラー報告プロトコル終端部１３０−１２から抜きだして送信端末１０へ送出するフラグメント要求メッセージ転送部１３０−１３、フラグメント要求メッセージ転送部１３０−１３から通知された最大転送単位を記憶する最大転送単位記憶部１３０−１４を有する。

本実施形態のセッション中継装置１３０は、セッション中継部１３０−３およびフラグメント要求メッセージ転送部１３０−１３の構成が異なる以外は、上述の第２の実施形態のものと基本的に同じである。

図２４に、セッション中継部１３０−３の構成を示す。図２４を参照すると、セッション中継部１３０−３は、パケット入力部１３０−１からのパケットをバッファリングするバッファリング部１３０−３−１、パケット入力部１３０−１にバッファリングされたセグメントがセグメントサイズを変えて再送されたものか否かを判断するセグメント再送判定部１３０−３−２、サイズを変えて再送されたセグメントを再送するセグメント再送部１３０−３−３、サイズを変えて再送されたものでないセグメントを中継する通常セッション中継部１３０−３−４、ＳＭＳＳと等しい最小シーケンス番号を算出・更新するＳＭＳＳ送出シーケンス番号算出手順１３０−３−５を備える。

セッション中継部１３０−３では、セグメント再送判定部１３０−３−２により、送信端末１０からのセグメントがセグメントサイズを変えて再送されてきたものか否かが判断される。送信端末１０からのセグメントがセグメントサイズを変えて再送されてきたものである場合は、セグメント再送部１３０−３−４により、無条件もしくは再送を含む任意のタイミングで、その再送セグメントのパケットが受信端末２０に向けて送出される。ここで、「セグメントを変えて再送」とは、開始シーケンス番号が同じで、セグメントサイズが異なる再送セグメントを指す。セグメント再送判定部１３０−３−２の判定条件に、再送セグメントが受信端末２０に未到達である、という条件、または、再送セグメントサイズがＳＭＳＳ以下である、という条件を加えてもよく、また、これら条件の双方を満たす、という条件を加えてもよい。

また、セッション中継部１３０−３では、ＳＭＳＳ送出シーケンス番号算出部１３０−３−５により、送出セグメントサイズがＳＭＳＳと等しい場合のセグメントサイズで最小の送信シーケンス番号(以後、最大送出セグメントに対応する最小シーケンス番号)がセッション状態保持部１３０−８に格納される。更新の条件として、送信確認済み最大セグメントサイズが、セッション状態保持部１３０−８に登録されたセッション開設時にネゴシエーションされた最大セグメントサイズに満たない場合という条件を加えてもよい。

図２５に、フラグメント要求メッセージ転送部１３０−１３の構成を示す。図２５を参照すると、フラグメント要求メッセージ転送部１３０−１３は、フラグメント要求メッセージ判定部１３０−１３−１、セッション検索部１３０−１３−２、ＳＭＳＳ更新部１３０−１３−３、通知ＭＴＵ更新部１３０−１３−４を備える。なお、この通知ＭＴＵ更新部１３０−１３−４は設けなくてもよい。

フラグメント要求メッセージ判定部１３０−１３−１は、エラー報告プロトコル終端部１３０−１２からのエラー報告プロトコルがフラグメント要求メッセージであるか否かを判定する。フラグメント要求メッセージであれば、セッション検索部１３０−１３−２が、メッセージ内のエラーパケットヘッダにあるポート番号を含む送信先・受信先の情報に基づいてセッション状態保持部１３０−８内の情報を検索する。セッション情報を検索する際には、セキュリティを高めるため、［「シーケンス番号が受信端末２０からの送信確認パケットの送信確認済みの最大シーケンス番号」≦「エラーパケットヘッダにある送信シーケンス番号」≦「送信済みの送信シーケンス番号の最大値」］という条件を満たすか否かのチェックを入れてもよい。

ＳＭＳＳ更新部１３０−１３−３は、フラグメント要求メッセージ内の「次のホップの最大転送単位」を読み出し、中継中のセッションのＳＭＳＳを［「次のホップの最大転送単位」−「ヘッダサイズ」］値としてセッション状態保持部１３０−８に保持されたＳＭＳＳを更新する。このヘッダサイズは、送信端末１０側と受信端末２０側でヘッダサイズが異なる場合、二つのヘッダサイズの最大値となる。「最大転送単位」は、最大転送単位記憶部１３０−１４に格納される。通知ＭＴＵ更新部１３０−１３−４がない場合は、ＳＭＳＳ更新部１３０−１３−３は、フラグメント要求メッセージをパケット出力１３０−１１へ出力する。

通知ＭＴＵ更新部１３０−１３−４は、送信端末１０側と受信端末２０側でヘッダサイズが異なる場合に、送信端末に通知するフラグメント要求メッセージ内の最大転送単位からヘッダサイズを差し引いた値を通知する。

図２６に、送信確認パケット転送・終端判定部１３０−９の主要部を示す。図２６を参照すると、送信確認パケット転送・終端判定部１３０−９は、ＳＭＳＳに基づいて送信確認パケットの終端開始を判断する送信確認パケット終端判定部１３０−９−１と、送信確認パケットを転送する送信確認パケット転送部１３０−９−２と、通常のセッション中継処理を開始し、送信確認パケットの転送を止める送信確認パケット終端開始部１３０−９−３とを備える。

送信確認パケット終端判定部１３０−９−１は、受信端末２０からの送信確認パケットの送信確認済みの最大シーケンス番号が最大送出セグメントに対応する最小シーケンス番号に達するか否かを判断する。セッション開設直後は、送信確認パケット転送部１３０−９−２は、送信確認受信部１３０−７からの送信確認パケットをパケット出力部１３０−１１に転送し、送信確認送信部１３０−１０は、送信確認パケットの送出を行わない。送信確認済みの最大シーケンス番号が最大送出セグメントに対応する最小シーケンス番号に達した後は、送信確認パケット転送部１３０−９−２による送信確認パケットの転送は実行されず、送信確認パケット終端開始部１３０−９−３が受信側からの送信確認パケットを終端して、送信確認送信部１３０−１０による送信確認パケットの送信を開始させる。

次に、本実施形態のセッション中継装置の動作を具体的に説明する。図２７に、送信端末１０から受信端末２０への通信方向での、本実施形態のセッション中継装置の動作を示し、図２８に、ＳＭＳＳ送出シーケンス番号算出処理の動作を示す。また、図２９に、受信端末２０から送信端末１０への通信方向での、本実施形態のセッション中継装置の動作を示す。

まず、図２７を参照して、セッション開設処理が終わった直後に送信端末１０からデータパケットが来た場合のセッション中継装置１３０の動作を説明する。

セッション開設直後は、送信確認パケット転送部１３０−９−２が、送信確認受信部１３０−７からの送信確認パケットをパケット出力部１３０−１１に転送し、送信確認送信部１３０−１０は送信確認パケットの送出行わない。この段階におけるＳＭＳＳは、セッション開設時にネゴシエーションされた最大セグメントサイズである。

送信端末１０から送出されたパケットは、パケット入力部１３０−１を通じてセッション中継部１３０−３に供給される（ステップＣ１０１）。セッション中継部１３０−３では、送信端末１０からパケットが入力されると、供給されたパケットがバッファリング部１３０−３−１にてバッファリングされて保持される（ステップＣ１０２）。

送信端末１０からのパケットがバッファリング部１３０−３−１にてバッファリングされて保持されると、次いで、セグメント再送判定部１３０−３−２が、バッファリング部１３０−３−１に保持されたセグメントがセグメントサイズの異なる再送セグメントであるか否かを判断する（ステップＣ１０３）。この段階では、バッファリング部１３０−３−１に保持されたセグメントはセグメントサイズの異なる再送セグメントでないため、ステップＣ１０３の判断は「いいえ」となる。

ステップＣ１０３の判断が「いいえ」となると、通常セッション中継部１３０−３−４にて、通常のセッション中継処理が行われる（ステップＣ１０７）。この通常のセッション中継処理では、バッファリング部１３０−３−１に保持されたパケットセグメントが最初のセグメントであるため、その保持されたパケットセグメントがパケット出力部１３０−４に出力される。そして、パケット出力部１３０−４に出力されるパケットに対して、ＳＭＳＳ送出シーケンス番号算出処理部１３０−３−５にて、ＳＭＳＳ送出シーケンス番号算出処理が行われる(ステップＣ１０５)。

ステップＣ１０５のＳＭＳＳ送出シーケンス番号算出処理では、図２８に示すように、まず、送出セグメントサイズがＳＭＳＳに等しいか否かの判断が行われる（ステップＣ２０１）。この段階では、送出セグメントサイズがＳＭＳＳと等しいため、ステップＣ２０１の判断は「はい」となる。ステップＣ２０１の判断が「はい」となると、続いて、セグメントサイズに対応した最初のＳＭＳＳ送出シーケンス番号であるか否かの判断が行われる（ステップＣ２０２）。この段階では、セグメントサイズに対応した最初のＳＭＳＳ送出シーケンス番号であるので、ステップＣ２０２の判断は「はい」となる。ステップＣ２０２の判断が「はい」となると、次いで、ＳＭＳＳ送出シーケンス番号を送出シーケンス番号で更新する処理を行う（ステップＣ２０３）。

上述のようにしてステップＣ１０５のＳＭＳＳ送出シーケンス番号算出処理が行われた後、パケット出力部１３０−４から受信端末２０側へパケットが出力される（ステップＣ１０６）。

セッション中継装置１３０から受信端末２０へ向けて送出されたセグメントは、中継装置４０に受信される。中継装置４０は、受信したセグメントのサイズがＭＴＵより大きな場合は、エラー報告プロトコルのフラグメント要求メッセージを送信端末１０に向けて送出する。このエラー報告プロトコルのフラグメント要求メッセージは、セッション中継装置１３０にて受信される。

次に、図２９を参照して、中継装置４０からのエラー報告プロトコルのフラグメント要求メッセージを受信した場合の、セッション中継装置１３０の動作を説明する。

受信端末２０側からのパケットがパケット入力部１３０−５に入力される（ステップＣ４０１）。パケット入力部１３０−５に入力されたパケットはセッションパケット判定部１３０−６に供給され、セッションパケット判定部１３０−６において、その入力パケットがセッションパケットであるか否かの判断が行われる（ステップＣ４０２）。この段階では、受信端末２０側からのパケットは、中継装置４０が送信端末１０に対して送出したエラー報告プロトコルのフラグメント要求メッセージであるので、ステップＣ４０２の判断は「いいえ」となる。

ステップＣ４０２の判断が「いいえ」となると、セッションパケット判定部１３０−６は、パケット入力部１３０−５からの入力パケットをエラー報告プロトコル終端部１３０−１２に渡し、エラー報告プロトコル終端部１３０−１２にて、その入力パケットがエラー報告プロトコルであるか否かの判断が行われる（ステップＣ４０３）。この段階では、入力パケットは、中継装置４０が送信端末１０に対して送出したエラー報告プロトコルのフラグメント要求メッセージであるので、ステップＣ４０３の判断は「はい」となる。

ステップＣ４０３の判断が「はい」となると、エラー報告プロトコル終端部１３０−１２はパケット入力部１３０−５からの入力パケットをフラグメント要求メッセージ転送部１３０−１３に渡し、フラグメント要求メッセージ転送部１３０−１３にて、フラグメント要求メッセージ判定部１３０−１３−１が、エラー報告プロトコル終端部１３０−１２に供給されたパケットがフラグメント要求メッセージであるか否かの判断が行われる（ステップＣ４０４）。この段階では、エラー報告プロトコル終端部１３０−１２に供給されたパケットはフラグメント要求メッセージであるので、ステップＣ４０４の判断は「はい」となる。

ステップＣ４０４の判断が「はい」となると、フラグメント要求メッセージ転送部１３０−１３は、エラー報告プロトコルのフラグメント要求メッセージをエラー報告プロトコル終端部１３０−１２から抜き出し、その抜き出したフラグメント要求メッセージ内の最大転送単位およびヘッダサイズの情報に基づいて、セッション状態保持部１３０−８に保持された、セッションごとのＳＭＳＳを更新する（ステップＣ４０５）。このＳＭＳＳ更新処理では、ＳＭＳＳは［「最大転送単位」−「ヘッダサイズ」］の値に更新される。ＳＭＳＳ更新後、フラグメント要求メッセージ転送部１３０−１３は、抜き出したフラグメント要求メッセージをパケット出力部１３０−１１を通じて送信端末１０へ送出する(ステップＣ４０６)。

セッション中継装置１３０からフラグメント要求メッセージを受信した送信端末１０は、その受信したフラグメント要求メッセージに従い、セグメントサイズを低くしたパケットを受信端末２０に向けて再送する。

次に、図２７を参照して、送信端末１０からセグメントサイズを低くしたパケットが来た場合の、セッション中継装置１３０の動作を説明する。

送信端末１０からのデータパケットは、パケット入力部１３０−１からセッション中継部１３０−３に供給される（ステップＣ１０１）。セッション中継部１３０−３では、送信端末１０から供給されたパケットがバッファリング部１３０−３−１にてバッファリングされて保持される（ステップＣ１０２）。

送信端末１０からのパケットがバッファリング部１３０−３−１にてバッファリングされて保持されると、次いで、セグメント再送判定部１３０−３−２が、バッファリング部１３０−３−１に保持されたセグメントがセグメントサイズの異なる再送セグメントであるか否かを判断する（ステップＣ１０３）。この段階では、バッファリング部１３０−３−１に保持されたセグメントはセグメントサイズの異なる再送セグメントであるため、ステップＣ１０３の判断は「はい」となる。

ステップＣ１０３の判断が「はい」となると、セグメント再送部１３０−３−３が、無条件もしくは再送を含む任意のタイミングで、バッファリング部１３０−３−１に保持されたパケットセグメントをパケット出力部１３０−４に出力する(ステップＣ１０４)。そして、パケット出力部１３０−４に出力されるパケットに対して、ＳＭＳＳ送出シーケンス番号算出処理部１３０−３−５にて、ＳＭＳＳ送出シーケンス番号算出処理が行われる(ステップＣ１０５)。

ステップＣ１０５のＳＭＳＳ送出シーケンス番号算出処理では、図２８に示すように、まず、送出セグメントサイズがＳＭＳＳに等しいか否かの判断が行われる（ステップＣ２０１）。この段階では、送出セグメントサイズがＳＭＳＳと等しいため、ステップＣ２０１の判断は「はい」となる。ステップＣ２０１の判断が「はい」となると、続いて、セグメントサイズに対応した最初のＳＭＳＳ送出シーケンス番号であるか否かの判断が行われる（ステップＣ２０２）。この段階では、セグメントサイズに対応した最初のＳＭＳＳ送出シーケンス番号であるので、ステップＣ２０２の判断は「はい」となる。ステップＣ２０２の判断が「はい」となると、次いで、ＳＭＳＳ送出シーケンス番号を送出シーケンス番号で更新する処理を行う（ステップＣ２０３）。

上述のようにしてステップＣ１０７のＳＭＳＳ送出シーケンス番号算出処理が行われた後、パケット出力部１３０−４から受信端末２０側へパケットが出力される（ステップＣ１０６）。

上記パケット出力部１３０−４から送信された再送セグメントのサイズは、中継装置４０が送信元に対して返したフラグメント要求メッセージ通りのサイズとなっているため、再送セグメントは中継装置４０を通過して受信端末２０に到達する。受信端末２０は、再送セグメントを受信すると、その応答パケットである送信確認パケットを送信端末１０に向けて送信する。この送信確認パケットは、中継装置４０を介してセッション中継装置１３０にて受信される。

次に、図２９を参照して、受信端末２０から送信確認パケットを受信した場合の、セッション中継装置１３０の動作を説明する。

受信端末２０側からのパケットがパケット入力部１３０−５に入力される（ステップＣ４０１）。パケット入力部１３０−５に入力されたパケットはセッションパケット判定部１３０−６に供給され、セッションパケット判定部１３０−６において、その入力パケットがセッションパケットであるか否かの判断が行われる（ステップＣ４０２）。この段階では、受信端末２０側からのパケットは、受信端末２０が送信端末１０に向けて送信した送信確認パケット（セッションパケット）であるので、ステップＣ４０２の判断は「はい」となる。

ステップＣ４０２の判断が「はい」となると、セッションパケット判定部１３０−６はパケット入力部１３０−５からの入力パケットを送信確認受信部１３０−７に渡し、送信確認受信部１３０−７にて送信確認受信処理が行われる(ステップＣ４０７)。次いで、送信確認パケット終端判定部１３０−９−１が、［「送信確認済みの最大シーケンス番号」≧「最大送出セグメントに対応する最小シーケンス番号」］の条件を満たすか否かの判断を行う（ステップＣ４０８）。この段階では、その条件を満たすので、送信確認パケット終端開始部１３０−９−２が、送信確認処理の開始を送信確認送信部１３０−１０に伝える(ステップＣ４０９)。その後、受信側からの送信確認パケットは、送信端末１０には転送されない。この結果、受信側からの送信確認パケットはセッション中継器１３０で終端され、送信確認送信部１３０−１０による送信確認パケットの送信が開始されることになる。

上述した第３の実施形態のセッション中継装置においても、第１の実施形態の場合と同様、送信端末１０からの再送セグメントは、必ず中継装置４０に向けて送信される。よって、通信不能に陥ることなく、送信端末１０と受信端末２０の間で安定した通信状態を維持することができる。

また、セッション開設直後は、受信側からの送信確認パケットをそのまま送信端末に転送するようになっているので、セッション中継装置において、送信端末からのパケットのオーバーフローによるデッドロックを回避することができる。

以上説明した第１乃至第３の実施形態の構成および動作は、本発明の一例であり、適宜変更することが可能である。例えば、第１の実施形態において、送信確認パケット転送・終端判定部が、第２および第３の実施形態における送信確認パケット転送・終端判定部による送信確認パケットの転送・終端の判定と同様な判定を行うようにしてもよい。反対に、第２および第３の実施形態において、送信確認パケット転送・終端判定部が、第１の実施形態における送信確認パケット転送・終端判定部による送信確認パケットの転送・終端の判定と同様な判定を行うようにしてもよい。

また、第２および第３の実施形態において、セッション中継器にて、セグメントサイズがＳＭＳＳより大きいかのチェックを行って、セグメントサイズがＳＭＳＳより大きい場合に、そのセグメントは破棄するようにしてもよい。図３０に、セグメントを破棄する場合の手順を示し、図３１に、セグメントを破棄せずに送信端末に送信する場合の手順を示す。

セグメントを破棄する場合の処理は、図３０に示すように、送信端末１０が受信端末２０に向けてパケットサイズが１５００バイトのデータを送ると、そのデータはセッション中継装置１３０を介して中継装置４０に到達する。中継装置４０は、受信したセグメントのサイズがＭＴＵ（＝５００）より大きいため、エラー報告プロトコルのフラグメント要求メッセージ（次のホップの最大転送単位は５００という情報を含む）を送信端末１０に向けて送出する。このエラー報告プロトコルのフラグメント要求メッセージは、セッション中継装置１３０にて受信される。セッション中継装置１３０では、このフラグメント要求メッセージの受信後に、送信端末１０から受信端末２０に向けて送出されたパケットサイズが１５００バイトのデータを受信した場合は、その受信データを破棄する。これにより、中継装置４０からエラー報告プロトコルのフラグメント要求メッセージが送信端末１０に向けて送信される回数は１回で済むことになる。

一方、セグメントを破棄せずに送信端末に送信する場合は、図３１に示すように、セッション中継装置１３０は、フラグメント要求メッセージの受信後に、送信端末１０から受信端末２０に向けて送出されたパケットサイズが１５００バイトのデータを受信した場合は、その受信データを受信端末２０側のネットワークに送出するため、エラー報告プロトコルのフラグメント要求メッセージが中継装置４０から送信端末１０に向けて何回も送信されることになる。このようにフラグメント要求メッセージが無駄に送信されてしまう。

また、第１から第３の実施形態では、受信端末側からのエラー報告プロトコルを終端することとしたが、ネットワーク層以下の中継となるパケットのうち、受信端末側からのエラー報告プロトコルのフラグメント要求メッセージを抜き出す処理を行っても問題ない。

また、第１から第３の実施形態では、片方向の通信例で説明したが、双方向の通信であっても問題ない。

また、第１から第３の実施形態では、送信端末、受信端末、中継装置およびセッション中継端末装置がそれぞれ１つとされたネットワーク構成について説明したが、送信端末、受信端末、中継装置およびセッション中継端末装置の数は特にこれに制限されるものではない。

以上、セッション中継器を例に発明の特徴を説明したが、本発明は、その特徴を有するのであれば、他の通信システムに適用することも可能である。例えば、セッションをＴＣＰとし、エラー報告プロトコルをエラー報告するＩＣＭＰおよびフラグメント要求メッセージをICMP Destination Unreachable Messageのフラグメント化要求、送信確認パケットをＴＣＰのＡＣＫパケット、送信シーケンス番号をＴＣＰのシーケンス番号、ヘッダサイズをＩＰ・ＴＣＰのヘッダサイズの総和、セグメント分割禁止フラグをＩＰのDon’t Fragmentフラグと置き換えることで、本発明をＴＣＰ／ＩＰ上で実施することが可能である。

本発明は、ＴＣＰ中継器といった用途に適用できる他、プロキシ，暗号化装置といったセッション中継器の用途にも適用可能である。

Claims (14)

1. 送信するセグメントの順番を示すシーケンス番号が付与されたパケットによりデータが送受信される端末間に配置され、送信側の端末との間に開設される第１のセッションと、受信側の端末との間に開設される第２のセッションとの間で、前記パケットにより送信されたデータの中継を行うセッション中継装置であって、
   前記第１および第２のセッションの状態を保持するセッション状態保持部と、
   前記第１のセッションを通じて前記パケットを受信すると、前記セッション状態保持部に保持されたセッション状態情報を参照して、該受信したパケットのセグメントが、前記第１のセッションを通じてすでに受信してあるパケットのセグメントとシーケンス番号が同じで、セグメントサイズが異なる再送セグメントであるか否かを判断するセグメント再送判定部と、
   前記セグメント再送判定部で前記受信したパケットのセグメントが再送セグメントであると判断された場合に、該再送セグメントを前記第２のセッションを通じて送信するセグメント再送部とを有するセッション中継装置。
2. 前記セグメント再送判定部で前記受信したパケットのセグメントが再送セグメントであると判断された場合に、該再送セグメントのセグメントサイズで前記第２のセッションの最大セグメントサイズを更新するセッション最大セグメントサイズ更新部をさらに有する、請求の範囲１に記載のセッション中継装置。
3. 前記受信側の端末に向けて中継した前記パケットのデータのセグメントを分割する旨のフラグメント要求メッセージを前記第２のセッションを通じて受信すると、該受信したフラグメント要求メッセージを前記第１のセッションを通じて前記送信側の端末に向けて送信するとともに、該受信したフラグメント要求メッセージ内に含まれる次ホップの最大転送単位を読み取るフラグメント要求メッセージ転送部と、
   前記フラグメント要求メッセージ転送部で読み取った次ホップの最大転送単位が格納される最大転送単位記憶部と、
   前記最大転送単位記憶部に格納された最大転送単位が、該最大転送単位より小さい最大転送単位に更新されると、該更新された最大転送単位に基づいて前記第２のセッションの最大セグメントサイズを更新する最大転送単位チェック部とをさらに有する、請求の範囲１に記載のセッション中継装置。
4. 前記受信側の端末に向けて中継した前記パケットのデータのセグメントを分割する旨のフラグメント要求メッセージを前記第２のセッションを通じて受信すると、該受信したフラグメント要求メッセージを前記第１のセッションを通じて前記送信側の端末に向けて送信するとともに、該受信したフラグメント要求メッセージ内に含まれる次ホップの最大転送単位を読み取り、該読み取った次ホップの最大転送単位に基づいて前記第２のセッションの最大セグメントサイズを更新するフラグメント要求メッセージ転送部をさらに有する、請求の範囲１に記載のセッション中継装置。
5. 前記受信側の端末に向けて中継した前記第１のセッションの開始パケットに対する応答である送信確認パケットを前記第２のセッションを通じて受信する送信確認受信部と、
   前記送信確認受信部で受信した送信確認パケットに対して、該送信確認パケットを転送するか、該送信確認パケットを終端するかの判断を行う送信確認パケット転送・終端判定部と、
   前記送信確認パケット転送・終端判定部で前記送信確認パケットを終端する旨の判断がなされた場合に、前記開始パケットに対する新たな送信確認パケットを生成して前記送信側の端末へ送る送信確認送信部とをさらに有し、
   前記セッション状態保持部は、前記開始パケットの送信シーケンス番号と、前記受信側の端末から受信した送信確認パケットの送信確認シーケンス番号とを前記セッション状態情報として保持し、
   前記送信確認パケット転送・終端判定部は、前記送信シーケンス番号と前記送信確認シーケンス番号の差分で与えられる送信確認済みの最大セグメントサイズが、前記第２のセッションの最大セグメントサイズの倍数で与えられる設定値より小さい場合は、前記送信確認パケットを前記第１のセッションを通じて前記送信側の端末に向けて転送し、前記シーケンス番号の差分が前記設定値に達した場合は、前記送信確認パケットを終端する、請求の範囲１から４のいずれかに記載のセッション中継装置。
6. 前記受信側の端末に向けて中継した前記第１のセッションの開始パケットに対する応答である送信確認パケットを前記第２のセッションを通じて受信する送信確認受信部と、
   前記送信確認受信部で受信した送信確認パケットに対して、該送信確認パケットを転送するか、該送信確認パケットを終端するかの判断を行う送信確認パケット転送・終端判定部と、
   前記送信確認パケット転送・終端判定部で前記送信確認パケットを終端する旨の判断がなされた場合に、前記開始パケットに対する新たな送信確認パケットを生成して前記送信側の端末へ送る送信確認送信部と、
   前記受信側の端末に向けて中継したパケットの送出セグメントサイズが前記第２のセッションの最大セグメントサイズに達したときのシーケンス番号を算出する最小シーケンス番号算出部とをさらに有し、
   前記セッション状態保持部は、前記開始パケットの送信シーケンス番号と、前記受信側の端末から受信した送信確認パケットの送信確認シーケンス番号を前記セッション状態情報として保持し、
   前記送信確認パケット転送・終端判定部は、前記送信シーケンス番号と前記送信確認シーケンス番号の差分で与えられる送信確認済みの最大セグメントサイズが、前記最小シーケンス番号算出部で算出したシーケンス番号より小さい場合は、前記送信確認パケットを前記第１のセッションを通じて前記送信側の端末に向けて転送し、前記送信確認済みの最大セグメントサイズが前記算出したシーケンス番号に達した場合は、前記送信確認パケットを終端する、請求の範囲１から４のいずれかに記載のセッション中継装置。
7. 前記第１および第２のセッションがＴＣＰである、請求の範囲１から６のいずれかに記載のセッション中継装置。
8. 前記フラグメント要求メッセージが、エラーを通知するＩＣＭＰのメッセージである、請求の範囲３または４に記載のセッション中継装置。
9. 前記送信確認パケットがＴＣＰのＡＣＫパケットである、請求の範囲５または６に記載のセッション中継装置。
10. 送信するセグメントの順番を示すシーケンス番号が付与されたパケットによりデータが送受信される端末間に配置され、送信側の端末との間に開設される第１のセッションと、受信側の端末との間に開設される第２のセッションとの間で、前記パケットにより送信されたデータの中継を行うセッション中継装置において行われるセッション中継方法であって、
    前記第１および第２のセッションの情報をセッション状態保持部に保持する第１のステップと、
    前記第１のセッションを通じて前記パケットを受信すると、前記セッション状態保持部に保持されたセッション状態情報を参照して、該受信したパケットのセグメントが、前記第１のセッションを通じてすでに受信してあるパケットのセグメントとシーケンス番号が同じで、セグメントサイズが異なる再送セグメントであるか否かを判断する第２のステップと、
    前記第２のステップで前記受信したパケットのセグメントが再送セグメントであると判断された場合に、該再送セグメントを前記第２のセッションを通じて送信する第３のステップとを含むセッション中継方法。
11. 前記第３のステップは、前記第２のステップで前記受信したパケットのセグメントが再送セグメントであると判断された場合に、該再送セグメントのセグメントサイズで前記第２のセッションの最大セグメントサイズを更新するステップを含む、請求の範囲１０に記載のセッション中継方法。
12. 前記第３のステップは、前記受信側の端末に向けて中継した前記パケットのデータのセグメントを分割する旨のフラグメント要求メッセージを前記第２のセッションを通じて受信すると、該受信したフラグメント要求メッセージ内に含まれる次ホップの最大転送単位を読み取り、該読み取った最大転送単位に基づいて前記第２のセッションの最大セグメントサイズを更新するステップを含む、請求の範囲１０に記載のセッション中継方法。
13. 前記受信側の端末に向けて中継した前記第１のセッションの開始パケットに対する応答である送信確認パケットを前記第２のセッションを通じて受信する第４のステップと、
    前記セッション状態保持部に保持されたセッション状態情報から、前記開始パケットの送信シーケンス番号と、前記受信側の端末から受信した送信確認パケットの送信確認シーケンス番号とを取得し、該取得したシーケンス番号の差分を求める第５のステップと、
    前記第５のステップで求めたシーケンス番号の差分で与えられる送信確認済みの最大セグメントサイズが、前記第２のセッションの最大セグメントサイズの倍数で与えられる設定値より小さい場合は、前記第４のステップで受信した送信確認パケットを前記送信側の端末に向けて転送し、前記送信確認済みの最大セグメントサイズが前記設定値以上である場合は、前記第４のステップで受信した送信確認パケットを終端し、前記開始パケットに対する新たな送信確認パケットを生成して前記送信側の端末へ送る第６のステップとをさらに含む、請求の範囲１０から１２のいずれかに記載のセッション中継方法。
14. 前記受信側の端末に向けて中継した前記第１のセッションの開始パケットに対する応答である送信確認パケットを前記第２のセッションを通じて受信する第４のステップと、
    前記セッション状態保持部に保持されたセッション状態情報から、前記開始パケットの送信シーケンス番号と、前記受信側の端末から受信した送信確認パケットの送信確認シーケンス番号とを取得し、該取得したシーケンス番号の差分を求める第５のステップと、
    前記受信側の端末に向けて中継したパケットの送出セグメントサイズが前記第２のセッションの最大セグメントサイズに達したときのシーケンス番号を算出する第６のステップと、
    前記第５のステップで求めたシーケンス番号の差分で与えられる送信確認済みの最大セグメントサイズが、前記第６のステップで算出したシーケンス番号より小さい場合は、前記第４のステップで受信した送信確認パケットを前記送信側の端末に向けて転送し、前記送信確認済みの最大セグメントサイズが前記算出したシーケンス番号以上である場合は、前記第４のステップで受信した送信確認パケットを終端し、前記開始パケットに対する新たな送信確認パケットを生成して前記送信側の端末へ送る第７のステップとをさらに含む、請求の範囲１０から１２のいずれかに記載のセッション中継方法。

Images