(57)【要約】【課題】第一の課題は、帯域制御手段と連携してTCP等のコネクションを識別し、識別したTCP等のコネクションごとに確認応答を代行するパケット転送装置を提供することにある。第二の課題は、通信端末と接続するネットワークのエッジ部に配置するだけでTCP等のスループットを向上することが可能な、TCP等のコネクションにおける確認応答を代行するパケット転送装置を提供することにある。【解決手段】第一の課題を解決する為の手段として、帯域制御手段から通知される帯域遵守フロー識別結果を元に該確認応答代行送信手段が確認応答代行の要否を判断するTCPフロー等の識別手段を備えたパケット転送装置を提供する。第二の課題を解決する為の手段として、格納したパケットを確認応答を行わないプロトコルに変換する手段と変換したパケットを対向するネットワークエッジに配置したパケット転送装置へ送信する手段を備えたパケット転送装置を提供する。【選択図】図１
2006261873.tif 000002
【特許請求の範囲】
【請求項１】
受信したパケットに対する転送処理を行う転送処理部と、
上記パケットに対する選別処理を行う選別処理部と、
上記パケットに対する帯域制御を行う帯域制御部と、
上記選別処理の結果に従い上記パケットを保持する記憶部と、
上記記憶部に格納した上記パケットに対する確認応答を代行して上記パケットの送信元へ送信する送受信部とを備え、一定時間内に上記パケットに対する確認応答が上記パケットの送信先から受信できない場合には、上記パケットを再送するパケット転送装置であって、
上記選別処理部は、上記帯域制御部における帯域遵守フロー識別結果に基づいて、上記確認応答の代行の要否を決定し、
上記送受信部は、上記選別処理部で上記確認応答の代行が必要と決定された上記パケットに対して上記確認応答を代行して上記パケットの送信元へ送信するパケット転送装置。
【請求項２】
請求項１記載のパケット転送装置であって、
さらに上記確認応答の代行を行わないフローを特定する情報を記憶しており、
上記選別処理部は、上記確認応答の代行の要否を決定する際に、さらに上記情報にも基づいて、要否を決定することを特徴とするパケット転送装置。
【請求項３】
請求項１記載のパケット転送装置であって、
さらに上記確認応答の代行を行うフローを特定する情報を記憶しており、
上記選別処理部は、上記確認応答の代行の要否を決定する際に、さらに上記情報にも基づいて、要否を決定することを特徴とするパケット転送装置。
【請求項４】
受信したパケットに対する転送処理を行う転送処理部と、
上記パケットに対する選別処理を行う選別処理部と、
上記選別処理の結果に従い上記パケットを保持する記憶部と、
上記記憶部に格納した上記パケットに対する確認応答を代行して上記パケットの送信元へ送信する送受信部とを備えたパケット転送装置であって、
上記記憶部に保持したバケットを確認応答を必要としないプロトコルのパケットに変換して送信先に向けて転送するパケット転送装置。
【請求項５】
請求項４記載のパケット転送装置であって、
さらに上記確認応答の代行を行わないフローを特定する情報を記憶しており、
上記選別処理部は、上記確認応答の代行の要否を決定する際に上記情報に基づいて要否を決定することを特徴とするパケット転送装置。
【請求項６】
請求項４記載のパケット転送装置であって、
さらに上記パケットに対する帯域制御を行う帯域制御部を有し、
上記選別処理部は、上記帯域制御部における帯域遵守フロー識別結果に基づいて、上記確認応答の代行の要否を決定することを特徴とするパケット転送装置。
【請求項７】
請求項４記載のパケット転送装置であって、
さらに上記確認応答の代行を行うフローを特定する情報を記憶しており、
上記選別処理部は、上記確認応答の代行の要否を決定する際に、さらに上記情報にも基づいて、要否を決定することを特徴とするパケット転送装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを構成するパケット転送装置とそのパケット転送制御方式に関する。特にパケット転送装置等の転送制御方式において、TCP（Transmission Control Protocol）（非特許文献１参照。）やSCTP（Stream Control Transmission Protocol）（非特許文献５参照。）等の確認応答を必要とする転送制御方式に従ったパケット転送制御方式の当該プロトコルヘッダ情報を利用するパケット転送装置とそのパケット転送制御方式に関する。
【背景技術】
【０００２】
イーサネット（イーサネットは登録商標）により構成されるネットワークの応用範囲は拡大しており、ストレージエリアネットワーク（SAN）へも応用され始めている。また、ギガビットイーサネットや10ギガビットイーサネット等、規格上のデータ転送速度は高速化してきた。そこで、TCPあるいはSCTP等の確認応答を必要とするプロトコル（以下、TCP等とする。）上の制限による実効的なデータ転送速度の問題が顕在化してくる。
【０００３】
TCP等の動作詳述は、非特許文献２あるいは非特許文献５に記載されている。ここでは、TCPコネクション確立動作とデータ転送状態の動作について説明する。
図３にTCP等に従った通信端末間のTCPコネクションにおけるパケット交換とTCPの制御情報の交換方式について示す。サーバ201とストレージ装置221が通信を行う場合を例として説明する。
サーバ201は、接続要求として、TCPのSYNフラグを設定したパケット（SYNパケット）をストレージ装置221に対して送信する。
【０００４】
ストレージ装置221は、サーバからSYNパケットを受信した確認応答として、ACKフラグを設定したパケット（ACKパケット）をサーバ201に送信する。同時にストレージ装置221は、ストレージ装置221からサーバ201への接続要求として、そのACKパケットにSYNフラグを設定することも行う。ここで、サーバ201が、ストレージ装置221からのSYNパケットを受信した確認応答として、ACKパケットをストレージ装置221に送信し、TCPコネクションが確立する。
【０００５】
TCPコネクションが確立すると、サーバ201とストレージ装置221とはデータ転送状態となる。データ転送状態では、通信端末がお互いに、送信側がデータを送信し、受信側がデータの送達確認応答をACKパケットで行う。ここでは簡単の為に、ストレージ装置221からサーバ201へ送信するデータのみがある場合を例とした。
【０００６】
TCP等による通信では、データを送信する側（この場合ストレージ装置221）は、確認応答が到着するまで次の送信データの送出を待機する為、データ送出時刻と確認応答到着時刻の差であるラウンドトリップタイム（RTT）は、送信データを送出可能な速度の上限を決める要因となる。また、確認応答が到着するまでに予め送信できるデータの量をウィンドウと呼ぶが、このウィンドウも送出可能な速度の上限を決める要因となる。
【０００７】
これらのパラメータを調整してTCP等のデータ転送スループットを向上するための従来技術として、送信側端末と受信側端末間にTCP等のコネクションを中継する装置を置き、受信側からの確認応答を待つことなく、確認応答を代行して送信することで、RTTを小さくでき、端末間でのデータ転送スループットを向上する方式がある。例えば、特許文献１に開示されているパケット中継装置や、非特許文献3、非特許文献４に開示されているTCPオーバレイネットワークなどである。
【０００８】
TCPコネクションを中継する装置は、ネットワーク上のスイッチやルータとして配置する。スイッチ211による確認応答の代行について、図４を用いて説明する。TCPコネクションが確立しデータ転送状態になると、ストレージ装置221からサーバ201へ送信されたデータに対する確認応答をスイッチ211がサーバ201に代行して送信する。この場合、ストレージ装置221はサーバ201からの確認応答を待つことなく、ウィンドウに従った量のデータを送信することができる。これを図３の場合と比べると、ウィンドウとRTTは同じであるが、TCPのデータ転送スループットを向上することができる。
以下では、TCP等のコネクションにおける確認応答を代行するパケット転送装置を、TCP等代行装置と呼ぶ。
【０００９】
【特許文献１】特開２００３−３２２９５号公報
【００１０】
【非特許文献１】J. Postel, “Transmission Control Protocol”, Request for Coments 793, 1981.
【非特許文献２】W. Stevens, “TCP/IP Illustrated, Volume1: The Protocols”, Addison-Wesley,1994.
【非特許文献３】村瀬勉、下西英之、長谷川洋平、“TCPオーバレイネットワークの提案”、電子情報通信学会ソサエティ大会、2002．
【非特許文献４】牧一之進、長谷川剛、村田正行、村瀬勉、“TCPオーバレイネットワークにおけるTCPコネクション分割機構の性能解析”、電子情報通信学会、IN03-198、2004．
【非特許文献５】R. Stewart, Q. Xie,  K. Morneault, C. Sharp, H. Schwarzbauer, T.Taylor, I. Rytina, M. Kalla, L. Zhang V. Paxson, “Stream Control Transmission Protocol”, Request for Coments 2960, 2000.
【発明の開示】
【発明が解決しようとする課題】
【００１１】
従来のパケット転送装置では、確認応答を代行するTCP等のコネクションについて、通過するパケットを到着順に順次処理しており、確認応答の代行が必要な一連のパケットの群であるフロー（以下、送信元や宛先等が同一であり、同一のファイルデータ等を分割したパケットの群をフローと呼ぶ。）の効果的な選別処理手段を持つことが成されていなかった。ネットワークに配置されるルータやスイッチ等、フローが集約される装置では、記憶手段の容量やフローの処理能力などの制約から、全てのフローを処理することは困難となる。
【００１２】
従って、本発明が解決しようとする第一の課題は、多数のTCP等のフローから、確認応答を代行するフローを選び出し、ギガビットイーサネット等のネットワークインタフェースのスループットを損ねることなく処理を行うTCP等代行装置を提供することである。
【００１３】
また、従来のTCP代行装置がTCPコネクションを分割し、TCPのRTTを分割する方法では、TCP代行装置の効果を最大化するためには、通信端末間のRTTを等分割するようにTCP代行装置を配置する必要があった。実際にはネットワークのエッジ部には比較的配置し易いが、ネットワークの内部の適当な位置には配置が困難であった。
本発明が解決しようとする第二の課題は、ネットワークのエッジ部に配置することで、TCP等のスループットを向上することが可能なTCP等代行装置を提供することである。
【課題を解決するための手段】
【００１４】
本発明では、第一の課題を解決する為の手段として、パケットの帯域制御手段と転送パケットを格納する記憶手段と、該記憶手段に格納したパケットに対してパケットデータの解析手段と確認応答代行送信手段を備えたパケット転送装置に対して、
該帯域制御手段から通知される帯域遵守フロー識別結果を元に該確認応答代行送信手段が確認応答代行の要否を判断するフロー識別手段を提供する。
【００１５】
また本発明では、第二の課題を解決する為の手段として、パケット転送装置に、転送パケットを格納する記憶手段と、該記憶手段に格納したパケットに対してパケットデータの解析手段とを備えた上で、
格納したパケットをUDP等の確認応答を行わないプロトコルに変換する手段と
変換したパケットを対向するネットワークのエッジに配置したTCP等代行装置へ送信する手段を備えることで、TCP等のスループットを向上できる手段を提供することにある。
【発明の効果】
【００１６】
ここまでに述べた手段を備えることで、本発明によるパケット転送装置では、通信端末間のTCP等のコネクションを分割するために確認応答を代行するTCP等のフローを識別できるようになる。その結果、フローのスループットを向上させ、回線帯域を有効に利用できるようになる。
【００１７】
また、TCP等代行装置間をコネクションの確認応答が必要ない通信方式とすることで、比較的配置し易いネットワークのエッジ部へTCP等代行装置を配置するだけで、TCPフロー等、確認応答が必要なフローのスループットを向上できるようになる。
【実施例１】
【００１８】
以下、本発明の第1の実施例について図面を参照して説明する。
初めに本発明を適用するネットワークの構成と、本発明による通信の方式を説明する。
ファイルサーバなどの計算機（サーバ）が、ストレージエリアネットワーク(SAN)を通じて、ストレージ装置とファイルデータの転送を行う場合を例とする。
【００１９】
図2に、パケット転送装置を用いたストレージネットワークの構成例を示す。ストレージ装置とサーバがスイッチによりそれぞれ接続されている。この時、ストレージネットワークは、広域イーサネットを含んでいてもよい。
【００２０】
サーバ201から、ストレージ装置221に対しファイルの読み出しを行う場合のTCPの動作を説明する。SCTP等のTCP以外のプロトコルでも同様の構成、動作となることから、本発明の実施例では、以下TCPを例にして説明する。
【００２１】
前提として通信端末にはそれぞれIPアドレスが割当てられているとする。TCPでは、通信端末間で交渉して、TCPコネクションを確立して通信を行う。この場合の通信端末とは、サーバ201とストレージ装置221のそれぞれを指す。通信端末であるサーバ201やストレージ装置221の上では、通信を行う複数のプログラムが動作するので、それらを区別する識別子として、TCPポート番号が割当てられる。
【００２２】
TCPコネクションは、一方の通信端末のネットワークアドレス（IPアドレス）とTCPポート番号、他方の通信端末のIPアドレスとTCPポートにより識別される。
通信端末同士が通信する場合に、送信側の通信端末から受信側の通信端末に、一つのファイルを構成する複数のパケットが送受信される時、それらのパケットは、TCPの場合は、宛先IPアドレスと送信元IPアドレスと宛先ポートと送信元ポート等の識別子の組を同一としている。このような通信プロトコルの宛先情報や送信元情報により一連のパケットと識別されるパケットの群をフローと呼ぶ。本実施例では、TCPの場合に宛先IPアドレスと送信元IPアドレス、および宛先ポートと送信元ポートをそれぞれ入れ替えたフローを互いに対向フローと呼ぶことにする。
【００２３】
確立したTCPコネクションでは、送信側は、送信データと送信データ量を表すTCPのシーケンス番号を送信する。受信側では、受信を確認したデータ量を表すために、受信している最新のシーケンス番号を確認応答番号として受信側から送信側へ逆向きに送信する。この逆向きの送信は、受信側から送信側への対向フローがある場合は、そのヘッダに重畳される。対向フローがない場合は、TCPヘッダのみを持つ対向フローを生成し送信される。
【００２４】
次に本発明を実施する為に必要なパケット転送装置の構成について説明する。
図５は、本発明によるパケット転送装置の機能ブロック構成例を示したブロック図である。本発明のパケット転送装置は、入力回線インタフェースと出力回線インタフェースと受信パケットに対して転送処理を行うパケット転送部と装置全体を制御する制御部と、パケット転送部と連携してパケット宛先検索を行うパケット検索制御部を持つ。前記パケット検索制御部には経路テーブルを備えている。また、前記パケット検索制御に連携したパケット記憶手段としてTCP転送制御部を備える。
【００２５】
また回線インタフェースには、帯域制御部を備える。帯域制御部は入力回線インタフェースと出力回線インタフェースのどちらかあるいは両方に備えてもよい。入力帯域制御部は受信するパケットの到着時刻を記録しパケットの到着時刻の間隔から入力回線の帯域を監視する手段を持つため、入力回線の設定帯域を超過したパケットが属するフローをTCP転送制御部に通知することができる。
【００２６】
出力帯域制御部は、送信するパケットの送信時刻を管理し出力回線の帯域を制御する手段を持つため、出力回線の設定帯域を超過したパケットが属するフローをTCP転送制御部に通知することできる。
ここで、入力回線インタフェースと出力回線インタフェースは、同一の基板上に実装されることが多いが、ここではパケット処理の流れ図を簡便化するため、機能的に分割して示した。
【００２７】
ここで、図７に通信に用いるパケット構造を示す。パケットは、OSI（Open System Interconnection）参照モデルの各レイヤのプロトコルに対応した階層化されたヘッダ情報とデータから構成される。具体的には、レイヤ2ヘッダ、レイヤ３ヘッダ、レイヤ４ヘッダデータ等から構成される。レイヤ２プロトコルとしては、Ethernet（Ethernetは登録商標）、ATM（Asynchronous Transfer Mode）、MPLS（Multi-Protocol Label Switching）等のプロトコルを用いることができる。レイヤ３のプロトコルとしては、Internet Protocol version 4（IPv4)、Internet Protocol version6（IPv6）等のプロトコルを用いることができる。レイヤ４のプロトコルとしては、TCP（Transmission Control Protocol）やUDP（User Datagram Protocol）等のプロトコルを用いることができる。
【００２８】
図８に、レイヤ２ヘッダの一例として、Ethernet version2(v2)フレームのヘッダフィールドを示す。Ethernet v2フレームヘッダには、フィールドとして、フレームの開始を示すプリアンブル/SFD、レイヤ2での宛先端末のMAC（Media Access Control）アドレス（宛先MACアドレス）、レイヤ2での送信元端末のMACアドレス（送信元MACアドレス）、レイヤ３のプロトコルを示すタイプ等がそれぞれヘッダフィールドとして定義されている。
【００２９】
図９は、レイヤ３ヘッダの一例として、IPv4データグラムのヘッダフィールドを示す。IPv4ヘッダには、フィールドとして、パケットの転送品質を示すToS、レイヤ４のプロトコルを示すプロトコル、送信元端末のIPアドレス(送信元IPアドレス)、宛先端末のIPアドレス（宛先IPアドレス）等がそれぞれヘッダフィールドとして定義されている。
【００３０】
図10は、レイヤ３ヘッダの一例として、IPv6データグラムのヘッダフィールドを示す。IPv6ヘッダには、フィールドとして、パケットの転送品質を示すクラス、このヘッダが階層的に格納する次のヘッダ種別を示す次ヘッダ番号、送信元端末のIPアドレス(送信元IPアドレス)、宛先端末のIPアドレス（宛先IPアドレス）等がそれぞれヘッダフィールドとして定義されている。
【００３１】
図11は、レイヤ４ヘッダの一例として、TCPセグメントのヘッダフィールドを示す。TCPヘッダには、フィールドとして、アプリケーション等の上位レイヤがTCPセグメントを識別する為の送信元ポート番号、宛先ポート番号、TCPの通信状態を示すTCPフラグ等がそれぞれヘッダフィールドとして定義されている。
【００３２】
図12にTCPフラグの詳細を示す。TCPフラグは、受信端末が緊急にアプリケーションに受信データを渡すことを指示する緊急フラグ（URG）、受信端末がデータを受信したことを送信端末へ通知する確認応答フラグ（ACK）、送信端末および受信端末において遅滞無くデータをアプリケーションへ渡すことを指示するフラグ（PUSH）、TCPコネクションのリセットを支持するフラグ（RST）、コネクションの終了を支持するフラグ（FIN）、コネクションの確立を指示するフラグ（SYN）の6つのフラグからなる。
【００３３】
図13は、レイヤ４ヘッダの一例として、UDPセグメントのヘッダフィールドを示す。UDPヘッダには、フィールドとして、アプリケーション等の上位レイヤがUDPセグメントを識別する為の送信元ポート番号、宛先ポート番号、チェックサム等がそれぞれヘッダフィールドとして定義されている。
【００３４】
図14は、フロー識別の条件を示す図である。
フロー識別は、レイヤ2ヘッダフィールドとレイヤ3ヘッダフィールドとレイヤ４ヘッダフィールドの情報を組み合わせるなどして、そのパケットのフロー識別を行いフロー番号の設定を行う。例えば、レイヤ２ヘッダフィールドでは、宛先MACアドレス、送信元MACアドレスなどが用いられ、レイヤ３ヘッダフィールドでは、宛先IPアドレス、送信元IPアドレス、上位プロトコル等が用いられ、また、レイヤ４ヘッダフィールドでは、宛先TCPポート、送信元TCPポート等が用いられる。
図14に示した構成例では、宛先IPアドレス、送信元IPアドレス、上位プロトコル、宛先TCPポート、送信元TCPポートを識別条件としている。
【００３５】
図１は、TCP転送制御部の構成例を示すブロック図である。
TCP転送制御部は、フロー識別部とTCPバッファ制御部とTCPバッファとTCPバッファ管理テーブルとTCP再送制御部と代行確認応答発生部と確認応答対向フロー識別部と確認応答代行判断テーブル制御部と確認応答代行判断テーブルから構成される。
【００３６】
本発明のパケット転送装置において、TCPコネクションの確認応答を代行可能とする方式について、図15から図19を用いて説明する。
フロー識別部では、パケット転送部から転送されたパケットのヘッダ構成を解析する。TCPヘッダを持つパケットが入力されるとTCPデータパケットか確認応答パケットかを判断する。TCPデータ部を持つパケットがTCPデータパケットである。TCPフラグのACKフラグが有効なパケットが確認応答パケットである。
TCPデータパケットの場合は、図18のフローチャートに従い、確認応答を代行するかどうかを判断する。
【００３７】
図15は、確認応答代行許可テーブルの構成例である。
フロー識別部は、TCPデータパケットに対しては、前記のヘッダフィールドの該当部分を図15に示した確認応答代行制御テーブルの確認応答代行許可テーブルに保持した値と比較することにより、検索結果を得る。検索結果には入力帯域の遵守を示す判定フラグと、出力帯域の遵守を示す判定フラグが設定されている。帯域を遵守しているフローを確認応答代行するフローとして識別する。また、確認応答代行するフローの識別は、パケットのTOSフィールドの優先度により識別してもよい。
【００３８】
TOSフィールドの優先度により識別する場合、本装置と回線により接続された外部装置により帯域制御を行い、その結果を受け取る構成を採ることも可能である。
また確認応答の代行の要否を示すフラグも設定されているので、入力されたパケットが許可フローであり確認応答代行を行うか、不許可なので通常転送を行うかを判定する。
【００３９】
図16は、確認応答代行不要テーブルの構成例である。
フロー識別部は、確認応答代行の不要フローであるかどうかを判別するために、前記のヘッダフィールドの該当部分を図16に示した確認応答代行不要テーブルに保持した値と比較することにより、検索結果を得る。検索結果には入力帯域の遵守を示す判定フラグと、出力帯域の遵守を示す判定フラグが設定されている場合がある。帯域を遵守していないフローを確認応答代行しないフローとして識別する。また、確認応答代行しないフローの識別は、パケットのTOSフィールドの優先度により識別してもよい。
TOSフィールドの優先度により識別する場合、本装置と回線により接続された外部装置により帯域制御を行い、その結果を受け取る構成を採ることも可能である。
【００４０】
TCPバッファ制御部は、図17に示したTCPバッファ管理テーブルを確認しTCPバッファがある設定値よりも少ない場合は、TCPバッファが枯渇したとみなし、このパケットの確認応答代行を中止し、このパケットの属するフローを確認応答代行不要テーブルに設定したり、あるいはこのパケットの属するフローを確認応答代行許可テーブルから削除したりすることにより、パケットを通常転送とすることができる。TCPバッファが枯渇している場合は、このパケットの確認応答代行を中止し、パケットを通常転送とする。
入力されたパケットの確認応答代行を行う場合は、図17に示したTCPバッファ管理テーブルに登録し、確認応答代行を開始する。
【００４１】
図17は、TCPバッファ管理テーブルの構成例である。TCPバッファ制御部は、受信回線インタフェース内のパケットメモリからパケット転送部で複製されたパケットデータをフロー識別部から受信して、TCPバッファに記憶し、バッファアドレスをTCPバッファ管理テーブルに登録する。
【００４２】
代行不要と登録されていれば、通常転送と判断する。通常転送と判断された際に、既にTCPバッファ管理テーブルに登録されているフローは、確認応答代行中止処理を行い、TCPバッファの開放を行う。
また、確認応答パケットの場合は、図19のフローチャートに従い、確認応答を代行したフローのTCP制御を行う。
【００４３】
フロー識別部は、確認応答パケットに対しては、そのパケットを確認応答識別部に送る。確認応答識別部では、受信した確認応答パケットの対向フローがTCPバッファ管理テーブルに登録されているかどうかを判断する。登録されている場合は、確認応答を代行したパケットをTCPバッファに保持しているのでTCP制御部により確認応答を受け取ったTCPパケットとしてバッファ開放処理を行う。
【００４４】
ここまでに述べた手段を備えることで、本発明によるパケット転送装置では、サーバとストレージ装置間のTCPコネクションを分割するために確認応答を代行するTCPフローを識別できるようになり、その結果、ネットワークの回線の帯域とTCPフローの利用帯域の状況に応じて、利用可能な帯域に余裕がある回線上のTCPフローのスループットを向上させ、回線帯域を有効に利用できるようになる。
【実施例２】
【００４５】
本発明の第２の実施例について図面を参照して説明する。
第２の実施例では、図2に示したネットワーク構成において、サーバ202とストレージ装置222が通信を行う場合を例として説明する。第１の実施例と同様に、用いる通信プロトコルがSCTP等のTCP以外のプロトコルでも同様の構成、動作となることから、本発明の実施例では、以下TCPを例にして説明する。
【００４６】
図6は、TCP転送制御部の別の構成例である。図1の構成例に加えて、プロトコル変換部とプロトコル変更フロー識別テーブルを備える。
第１の実施例のパケット転送装置の構成に対して、TCP転送制御部を図6に示した構成に変更することで、TCP代行装置間のパケットデータの変換をUDPカプセル化処理の方式とした実施例である。
【００４７】
サーバ202がストレージ装置222に対して、TCPコネクションを確立する場合、サーバ202側のネットワークエッジに配置されたスイッチ212とストレージ装置222側のネットワークエッジに配置されたスイッチ213を通過するものとする。
【００４８】
TCPコネクションが確立すると、スイッチ213は、TCPデータパケットに対し、フローテーブルに登録されたプロトコル変換を示すフローエントリーを検索し、検索結果からスイッチ212へ送信する為のパケットヘッダ情報を得る。さらにスイッチ213は、ストレージ装置からのTCPデータパケットに新たなパケットヘッダを付加してUDPパケットに変換し、スイッチ212へ送信する。さらにスイッチ213では、スイッチ212からの確認応答がない為、確認応答を代行したパケットのTCPバッファへの登録は行わない。この時、UDPパケットをスイッチ213からスイッチ212へ送信するネットワークは、エラー訂正符号などを利用して送達時の通信エラーを回避する手段を備えていてもよい。
【００４９】
通信エラー回避手段を備えることで、スイッチ間のデータ転送時に生じるパケットロスによるデータ転送の遅れを低減でき、データ通信の高速化が可能となる。
スイッチ212は、フローテーブルに登録されたプロトコル変換を示すフローエントリーを検索し、スイッチ213が付加したUDPヘッダなどのパケットヘッダを取り外して、ストレージ装置が送信したTCPデータパケットを受信する。スイッチ212は、実施例１の場合と同様にTCPバッファに登録し、TCP代行装置とし、ストレージ装置が送信した元のTCPコネクションのパケットをサーバ202に送信する。
【００５０】
ここまでに述べた手段を備えることで、本発明によるパケット転送装置では、TCP代行装置間をTCPコネクションの確認応答が必要ない通信方式とすることで、比較的配置し易いネットワークのエッジ部へTCP代行装置を配置するだけで、TCPフローのスループットを向上できるようになる。
【産業上の利用可能性】
【００５１】
通信事業者、あるいは通信ネットワークを利用する他の分野の事業者が利用するパケット中継装置に対して利用可能な装置管理技術の一つである。
【図面の簡単な説明】
【００５２】
【図１】本発明のTCP転送制御部の機能ブロック構成を示す概念図。
【図２】本発明のパケット転送装置を用いたネットワーク構成を示す概念図。
【図３】TCP等に従ったコネクションにおけるパケットと制御情報の交換方式の概念図。
【図４】従来方式のTCP代行装置によるTCPスループット向上方式を適用したTCPコネクションにおけるパケットと制御情報の交換方式の概念図。
【図５】本発明のパケット転送装置の機能ブロック構成を示す概念図。
【図６】本発明のTCP転送制御部の機能ブロック構成を示す概念図。
【図７】通信に用いるパケット構造を示した構成図。
【図８】レイヤ２ヘッダの一例であるEthernet v2フレームのヘッダフィールド構成図。
【図９】レイヤ３ヘッダの一例であるIPv4データグラムのヘッダフィールド構成図。
【図１０】レイヤ３ヘッダの一例であるIPv6データグラムのヘッダフィールド構成図。
【図１１】レイヤ４ヘッダの一例であるTCPセグメントのヘッダフィールド構成図。
【図１２】TCPヘッダフィールドのフラグフィールド構成図。
【図１３】レイヤ４ヘッダの一例であるUDPセグメントのヘッダフィールド構成図。
【図１４】フロー選別に用いるヘッダフィールドの構成図。
【図１５】確認応答代行許可テーブルの構成例を示す図。
【図１６】確認応答代行不要テーブルの構成例を示す図。
【図１７】TCPバッファ管理テーブルの構成例を示す図。
【図１８】TCPデータパケットの処理の実施例を示す流れ図。
【図１９】TCP確認応答パケットの処理の実施例を示す流れ図。
【図２０】本発明のTCP等代行装置によるTCPスループット向上方式を適用したTCPコネクションにおけるパケットと制御情報の交換方式の概念図。
【図２１】プロトコル変更フロー識別テーブルの構成例を示す図。
【図１】
2006261873.tif 000003
【図２】
2006261873.tif 000004
【図３】
2006261873.tif 000005
【図４】
2006261873.tif 000006
【図５】
2006261873.tif 000007
【図６】
2006261873.tif 000008
【図７】
2006261873.tif 000009
【図８】
2006261873.tif 000010
【図９】
2006261873.tif 000011
【図１０】
2006261873.tif 000012
【図１１】
2006261873.tif 000013
【図１２】
2006261873.tif 000014
【図１３】
2006261873.tif 000015
【図１４】
2006261873.tif 000016
【図１５】
2006261873.tif 000017
【図１６】
2006261873.tif 000018
【図１７】
2006261873.tif 000019
【図１８】
2006261873.tif 000020
【図１９】
2006261873.tif 000021
【図２０】
2006261873.tif 000022
【図２１】
2006261873.tif 000023