JP5801175B2

JP5801175B2 - パケット通信装置および方法

Info

Publication number: JP5801175B2
Application number: JP2011275959A
Authority: JP
Inventors: 通貴奥野; 武己矢崎
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2011-12-16
Filing date: 2011-12-16
Publication date: 2015-10-28
Anticipated expiration: 2031-12-16
Also published as: US8868998B2; JP2013126244A; US20130159806A1

Description

本発明は、パケット通信に関し、特に、応答確認型の通信プロトコルを利用し、ネットワーク障害の影響をネットワーク末端のクライアントやサーバから隠蔽する技術に関する。

クラウドコンピューティングの普及により、WAN(Wide Area Network)などのネットワークを経由してTCP/IP(Transmission Control Protocol/Internet Protocol)通信でデータセンタのサーバ上のアプリケーションを利用する情報処理形態が増加している。WANには様々な形態があるが、企業業務での利用を考慮するとVPN(Virtual Private Network)や専用線等の帯域保証や障害時の高速な別経路への切替えのサポート等がなされた高品質なネットワークが利用されるようになってきている。

例えば、MPLS−TP(Multi Protocol Label Switching Transport Profile)やリングプロトコルを利用した専用線サービスでは、サービス利用者に対し、現用系および予備系のエンドツウエンド(end−to−end)の通信経路を予め設定して、普段は現用系のパスを利用する。そして、ネットワーク障害時には50ms程度で高速に通信経路を切替えることでネットワークのダウンタイムを最小化することが可能である。

しかしながら、こうした高品質ネットワークを利用したとしても、ユーザのアプリケーションは、ネットワーク障害発生時に通信経路切替で生じる50ms以上の遅延が生じ、操作が停止したり画面表示速度が低下したりする等の応答性の劣化が生じる。これは、ネットワーク障害時に大量のデータパケット、応答のためのACK(Acknowledge)パケットが消失し、TCP/IP通信でのTCP層において、タイムアウトを待って再度通信処理を繰り返すことに由来する。タイムアウト時間は、例えば、3秒程度とされている。

本技術分野の背景技術である特許文献１には、課題として「通信遮断による連続したパケットロスに対して、遮断の回復後、すみやかに通信が再開できると共に、簡易な構成で低コストなパケット通信方法及び提案ノードを提供する。」ことが記載されている。

そして、解決手段として、「通信遮断の後に通信が回復すると、通信遮断回復検知部２７で検知し、演算部２８において算出した最適な回数、擬似的に重複した確認応答をＡＣＫ送信部２５から送信する。同時に、通常は広告受信ウィンドウサイズを過小に広告すると共に、回復時にそのサイズを増加させて広告する。」と記載されている。

また、特許文献２には、課題として「ネットワーク内に不要なトラフィックを発生させない簡単な構成のパケット通信装置を提供する。」ことが記載されている。

その解決手段として、「ARPパケットの送信周期を第１の周期(生存確認の周期)に設定して、ARP送信タイミングを待つ(ステップS2)。送信タイミングではARPパケットを送信する(ステップS3)。以後、ARP応答があった場合はステップＳ７に移り、ARP応答がない場合はステップS5に進む(ステップS4)。ステップS5ではデータの送受信を停止し、送信周期を第２の周期(回復検出の周期)に設定して(ステップS6)、ステップS2に戻る。ステップS7においてデータの送受信停止中でないときは制御の流れをステップS2に戻し、データの送受信停止中であればステップS8に進む。ステップS8ではデータの送受信停止処置を解除して送信周期を第１の周期に戻し、ステップS2に戻る(ステップS9)。」ことが記載されている。

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

しかしながら、特許文献１、２の構成においては、網障害が発生した場合、端末自身がパケットを再送することを想定しているため、網障害時に端末への障害の影響の波及を防止することができないという課題がある。

本発明の目的は、上記の課題を解決し、ネットワーク障害時にネットワークを輻輳等から守るために不要なパケット送信を停止し、ネットワーク障害が回復後に、すみやかに通信を再開し、クライアントやサーバなどの端末に対し、パケットロスを認識させずに済ますことのできるパケット通信装置および方法を提供することにある。

上記の目的を達成するため、本発明においては、複数の第一のネットワーク間を接続し、応答確認型の通信プロトコルによるデータ通信を行う第二のネットワークの末端に配置されるパケット通信装置であって、ネットワークインタフェース部と、処理部とを備え、処理部は、ネットワークインタフェース部を介して、第一のネットワーク間の通信をインタセプトして、データパケットをバッファリングし、第一のネットワークに配置される端末装置に対し、代理となって応答パケット、および、データパケットを転送し、第二のネットワークに対して任意のパケットフローに属するデータパケットを送信中、第二のネットワークからのパケットフローに属する応答パケットの受信が、任意のパケットフロー毎に設定した通信停止検出時間以上途絶えた場合に、第二のネットワークへのパケットフローに属するデータパケット送信を停止し、データパケット送信停止直後に、応答パケット未受信のパケットフローのデータパケットの先頭1個を、再送試行周期で第二のネットワークへ再送し、第二のネットワークから応答パケットを受信した時点で、前記パケットフローに属する、応答パケットを未受信の残りのデータパケットを再送する構成のパケット通信装置を提供する。

また、上記の目的を達成するため、本発明においては、複数の第一のネットワーク間を接続し、応答確認型の通信プロトコルによるデータ通信を行う第二のネットワークの末端に配置されるパケット通信装置であって、ネットワークインタフェース部と、処理部とを備え、処理部は、ネットワークインタフェース部を介して、第一のネットワーク間の通信をインタセプトして、データパケットをバッファリングし、第一のネットワークに配置される端末装置に対し、代理となって応答パケット、および、データパケットを転送し、第二のネットワークに対して任意のパケットフローに属するデータパケットを送信中、第二のネットワークからのパケットフローに属する応答パケットの受信が、任意のパケットフロー毎に設定した通信停止検出時間以上途絶えた場合に、第二のネットワークへのパケットフローに属するデータパケット送信を停止し、第二のネットワークから、第二のネットワークの障害発生、或いは障害からの回復を通知する障害通知パケットを受信する迄、或いは受信した後の、所定期間の間、前記パケットフローに属するデータパケットの送信停止を継続し、その後、前記パケットフローに属する、応答パケットを未受信のデータパケットを再送する構成のパケット通信装置を提供する。

更に、上記の目的を達成するため、本発明においては、複数の第一のネットワーク間を接続し、応答確認型の通信プロトコルによるデータ通信を行う第二のネットワークの末端に配置されるパケット通信装置のパケット通信方法であって、第一のネットワーク間の通信をインタセプトして、データパケットをバッファリングし、第一のネットワークに配置される端末装置に対し、代理となって応答パケット、および、データパケットを転送するステップと、第二のネットワークに対して任意のパケットフローに属するデータパケットを送信中、第二のネットワークからのパケットフローに属する応答パケットの受信が、任意のパケットフロー毎に設定した通信停止検出時間以上途絶えた場合に、第二のネットワークへのパケットフローに属するデータパケット送信を停止するステップと、データパケット送信停止直後に、前記パケットフローに属する、応答パケット未受信のデータパケットの先頭1個を、再送試行周期で第二のネットワークへ再送するステップと、第二のネットワークから応答パケットを受信した時点で、前記パケットフローに属する、応答パケットを未受信の残りのデータパケットを再送するステップを備えるパケット通信方法を提供する。

本発明によれば、応答確認型の通信プロトコルを利用したネットワークの障害の回復直後に、消失したパケットを復元すると共にネットワーク内での通信を迅速に再開させ、ネットワーク末端のクライアントやサーバに対し、ネットワーク障害による通信のパケットロスを生じないようにすることができる。

更に、障害発生からの１００ミリ秒未満程度で回復できる高信頼なネットワークで採用した場合、ネットワーク障害時でもクライアント等がネットワーク経由でサーバを利用するアプリケーションの応答性の悪化を避けることが可能となる。

各実施例に係る、システム構成の一例を示す図である。第１の実施例に係る、障害発生時のパケット転送処理例のフローチャートを示す図である。第１の実施例に係る、障害発生時のパケット転送処理例の説明図である。第１の実施例に係る、通信装置の一構成例を示す図である。第１の実施例に係る、状態テーブルの一構成例を示す図である。ＴＣＰ／ＩＰパケットの一構成を示す図である。第１の実施例に係る、通信装置のパケット処理例のフローチャートを示す図である。従来のシステム構成例を示す図である。従来の通信装置における障害発生時のパケット転送処理例のフローチャートを示す図である。従来の障害発生時のパケット転送処理例の説明図である。通信装置を介した障害発生時のパケット転送処理例の説明図である。各実施例に係る、システム構成例での障害発生例を示す図である。第２の実施例に係る、障害発生通知パケットを利用した場合のパケット転送処理例のフローチャートを示す図である。第２の実施例に係る、障害発生通知パケットを利用した場合のパケット転送処理例の説明図である。第２の実施例に係る、障害発生通知パケットを利用した場合のパケット転送処理例２の説明図である。第２の実施例に係る、MPLS−TPでの障害発生通知パケットの構成例を示す図である。第２の実施例に係る、Ethernet OAM(Operations, Administration, Maintenance)での障害発生通知パケットの構成例を示す図である。第３の実施例に係る、障害発生時のパケット転送処理例の説明図である。

以下、本発明の実施形態の例を添付図面に基づき説明する。各図における同一符号は同一物あるいは相当物を示す。説明の都合上、符号に添え字を追加して区別することがある。また、各種のネットワークに接続されるパソコン端末等のクライアント、当該クライアントが通信するデータセンタ、或いはデータセンタのサーバを総称し、便宜上、端末装置と呼ぶ場合がある。

まず、図１に各実施例が適用されるシステム構成の一例を示す。システム構成例として、ユーザ拠点では、パソコン端末等の複数のクライアント１０が第一のネットワークであるLAN（Local Area Network）３０−１を介して、第二のネットワークであるWAN(Wide Area Network)４０に接続される。同様に、データセンタでは、複数のサーバ２０が第一のネットワークであるLAN３０−２やLAN３０−３を介して、第二のネットワークであるWAN４０に接続される。LAN３０とWAN４０は、後述の実施例で説明する通信装置１００を介して接続される。WAN４０の中には、パケット転送用の複数のスイッチやルータが存在するが、本例では簡単のために4台のルータA４１、ルータB４２、ルータC４３、ルータD４４で構成されるものとする。本明細書において、第一のネットワークとは、LANに代表される端末装置に接続されるネットワークを、第二のネットワークとは、複数の第一のネットワークを相互に接続するWANに代表される広域のネットワークを示している。

ユーザは、例えば、クライアント１０のいずれかを利用し、あるアプリケーションＡをいずれかのサーバ２０上で動作させる。その際、クライアント１０とサーバ２０の間では、LAN３０−１、通信装置１００−１、ルータA４１、ルータB４２、ルータD４４、通信装置１００−２、LAN３０−２を経由する点線で示す通信１８０が発生するものとする。

同じく、クライアント１０のいずれかを利用し、別のアプリケーションＢをいずれかのサーバ２０で動作させる場合、LAN３０−１、通信装置１００−１、ルータA４１、ルータC４３、通信装置１００−３、LAN３０−３を経由する点線で示す通信１８１が発生するものとする。

ここで、図１２に示すように、WAN４０において、ルータB４２を含む通信経路で障害が発生したとする。この場合、通信１８１は障害の影響を受けないが、通信１８０は障害の影響を受ける。障害を契機に該当する通信経路は現用系から予備系の通信経路に切り替わり、結果として通信１８０は、ルータB４２の代わりにルータC４３を経由する通信１８２となる。

この際に、例えば、上述したMPLS−TPやリングプロトコルを利用した高品質なWAN専用線サービスでは、50ms程度での高速な通信経路の切替えを実現し、ネットワークのダウンタイムを最小化することが可能である。

しかしながら、こうした既存の高品質ネットワークサービスを利用したとしても、ユーザのアプリケーションは、ネットワーク障害発生時に通信経路切替で生じる50ms以上の遅延が生じ、操作が停止したり画面表示速度が低下したりする等の応答性の劣化が生じる。

この原因は、図１０に示すように、既存のネットワーク構成において、クライアント１０とサーバ２０の間で障害が生じた場合、標準的に用いられるTCP/IP通信のTCP層でデータを送信するためのデータパケット、前記データの応答（到着確認）のためのACKパケットが通信経路切替の間に消失してしまうことにある。尚、図１０で示す通信は、図８で示す、通信装置１００が存在しない場合の通信１８３である。

図１０に示す例の場合、データパケット送信側のクライアント１０は、データパケットA、B、C、D、E、F、G、H、I、J、Kの送信２２０を行うが、障害によってデータパケット、および、その応答パケットであるACKパケットが消失する。クライアント１０は、TCPの制御方法に則り、送信したデータパケットのACKパケットを待つが、該当するACKパケットが到着しない場合、再送タイムアウト２２１で指定された時間だけ、該当するデータパケットに対する再送処理ができず、ひたすら待機してしまう。例えばWindows（登録商標）では、再送タイムアウト２２１のデフォルト値は3秒とされている。

図９に示すように、既存のネットワーク構成においては、この際の動作としては、該当パケットの属するパケットフローに関して、再送タイムアウト２２１（例として3秒）を設定し（Ｓ４０１）、データ送信中、該当パケットに関するACKパケット未受信時間が再送タイムアウト２２１を超えると（Ｓ４０２でYES）、同データパケットを再送し、該当データパケットの再送タイムアウト値２２１を2倍に増加させ（Ｓ４０３）、尚もACKパケットが再送タイムアウト２２１を超えても到着しなければ、更に該当データパケットの再送タイムアウト値を2倍に増加させる（Ｓ４０４→Ｓ４０３）。ACKパケットがあれば、再送タイムアウト２２１をデフォルト値に戻すという動作を行う。

ここで、WAN４０が高信頼なネットワークであれば、こうした再送タイムアウト２２１よりも十分短い時間２２２で障害から復旧し通信経路切替が行われる。しかしながら、クライアント１０からの該当データパケットの再送信２５０は、障害復旧時間２２２よりも長い再送タイムアウト２２１を待たねばならず、結果として、再送信２５０以降の更なるデータ送信がどんどん遅れてしまい、ユーザアプリケーションの応答性劣化が生じる。

そのため、例えば図１１に示すように、クライアント１０とサーバ２０の間に通信装置１００をペアで配置し、この通信装置１００によって任意の二地点間、具体的には、クライアント１０とサーバ２０の間の通信をインタセプト（傍受）してバッファリングし、代理応答や代理転送する手段を設けることが必要となるが、それだけでは解決されない。なぜなら、図１１に示すネットワーク構成では、前記のクライアント１０の再送タイムアウト２２１を、通信装置１００−１の再送タイムアウト９０に代理させたにすぎず、やはり、再送信２５０は通信装置１００−１の再送タイムアウト９０後にしか行われないためである。

先に説明した課題を解決するためには、再送信２５０をWAN４０の障害復旧に合わせて迅速に行う必要がある。ただし、単純に再送信２５０を愚直に繰り返す方法では、障害が発生し、輻輳しやくすなっているネットワークを更に輻輳させ、ネットワークの利用効率を悪化させるため、通信の当事者のみならず、他の通信利用者へも悪影響を及ぼしてしまうため、避けねばならない。

そこで、こうした課題を解消するため、以下に説明する各実施例で提供するパケット通信装置では、ネットワーク障害時にネットワークを輻輳等から守るために不要なパケット送信を停止でき、ネットワーク障害が回復後に、すみやかに通信を再開でき、またはクライアントやサーバなどの端末に対し、パケットロスを認識させない、という効果の少なくとも一を奏する。

本実施例では、ネットワーク障害時にネットワークを輻輳等から守るために不要なパケット送信を停止できる例、ネットワーク障害が回復後に、すみやかに通信を再開できる例と、クライアントやサーバなどの端末に対し、パケットロスを認識させずに済ますことができる例を、図１のシステム構成図に加え、図２のフローチャート、図３のパケットの流れ図を用いて説明する。

本実施例を適用した通信装置１００は、WAN４０の周辺の拠点毎（LAN３０毎）に少なくとも1台ずつ配置される。例えば、図１のシステム構成の例では三つの拠点を例示しており、ユーザ側拠点に通信装置１００−１が、二つの独立したデータセンタ側拠点に通信装置１００−２、通信装置１００−３がそれぞれ配置されている。WAN４０は、単一通信事業者が提供する単一ネットワークであることが望ましいが、単一通信事業者が提供する複数のネットワークであったり、複数の通信事業者が提供する複数のネットワークであったりしてもかまわない。いずれの場合も、図２のフローチャートのS３０１のステップで示すように、通信装置１００は、対向となる別の通信装置１００毎に、図３に示した通信停止検出時間８０と再送試行周期８１の初期値を設定し、利用する。尚、対向となる通信装置１００毎は、別の言い方をすると、対向となる拠点間のパケットフロー毎でもある。

前記の通信停止検出時間８０とは、送信側の通信装置１００がネットワーク障害発生を擬似的に検出するまでの時間として、パケットフロー毎に設定される値である。通信停止検出時間８０の初期値としては、該当する通信装置１００間のWAN４０で想定される平均的な障害回復時間が設定されることが望ましい。例えば、５０msで障害から回復できるネットワークを利用する場合は、５０msと設定することが望ましい。

本実施例では、図３に示すように、ネットワーク障害発生の有無を、送信側の通信装置１００からの送信データパケットに対する応答であるACKパケットが、送信側の通信装置１００自身に連続して届かないことで判断する。応答パケットであるACKパケットが届かない事象は、WAN４０でのパケット消失によって生じるが、これは、一時的な輻輳によるものとネットワーク障害によるものに分けて考えることができる。

一時的な輻輳は、WAN４０でのクロスポイントにおいて複数の入力が同時に同一の出力を目指す場合や、WAN４０で高速回線から低速回線に通信をのせかえる場合、WAN４０でのルータやスイッチなどの通信装置がワイヤレートでパケット処理を行えない場合などに生じ、１パケットからバースト的に複数パケットが消失する。ネットワーク障害は、回線切断やルータ、スイッチなどの通信装置の故障、電源遮断などによって生じ、一時的な輻輳よりも多量のパケットがバースト的に消失する。前記の通信停止検出時間８０に、例として示したような適切な値を設定することで、一時的な輻輳とネットワーク障害の区別が容易になる。

また、再送試行周期８１とは、WAN４０でネットワーク障害発生後に、ネットワークが復旧したか否かを調査するために提供する検査パケット兼実データパケットを、繰り返し試行転送する時間間隔として設定される値である。再送試行周期８１の初期値としては、通信停止検出時間８０よりも小さい値、かつ、通信装置１００からの通常のパケット転送間隔よりも大きい値であることが望ましい。例えば、１０msなどが設定例として挙げられる。

また、再送試行周期８１は、優先度によって調整してもよい。例えば、優先度を高く設定したいパケットフロー（コネクション）に対しては、優先度の低いパケットフロー（コネクション）に比べてネットワーク障害回復検出を早くするために、再送試行周期８１を小さい値に設定してもよい。一例として優先度を高く設定したいパケットフローに対しては１０ms、優先度の低いパケットフローに対しては２０msや３０msなど１０msより大きい値とすることが設定例として挙げられる。

図３を利用し、本実施例のパケット転送処理の説明を続ける。クライアント１０は、サーバ２０との間でTCPのSYNパケット２１１、SYN/ACKパケット２１３、ACKパケット２１５を送受することで、アプリケーション実行のためのTCP/IPセッションのコネクション２１０を確立する。

この際、クライアント側の通信装置１００−１、サーバ側の通信装置１００−２は、対向装置として配置され、前記コネクション確立に仲介する。その仲介処理の中で、通信装置１００−１から通信装置１００−２へのSYNパケット２１１転送の応答として、通信装置１００−２は通信装置１００−１へ擬似的なSYN/ACKパケット２１２を返信する。通信装置１００−１は、SYNパケット２１１転送後に、前記擬似的なSYN/ACKパケット２１２を受信するまでの時間をWAN４０のRTT(Round Trip Time、往復通信遅延)として計測する。同様に、通信装置１００−２から通信装置１００−１へのSYN/ACKパケット２１３転送の応答として、通信装置１００−１は通信装置１００−２へ擬似的なACKパケット２１４を返信する。通信装置１００−２は、SYN/ACKパケット２１３転送後に、前記擬似的なACKパケット２１４を受信するまでの時間をWAN４０のRTT(Round Trip Time、往復通信遅延)として計測する。これは、図２のフローチャートのS３０２のステップに相当する。

通信装置１００は、RTTを計測後、通信停止検出時間８０の初期値とRTTの値を比較し、通信停止検出時間８０の初期値が前記RTTよりも小さい場合、通信停止検出時間８０の値をRTT、もしくはRTTに調整値を加えた値で更新する。調整値は、RTTの計測誤差を必要に応じて修正する値であり、数msから１０ms程度である。そうでない場合は、通信停止検出時間８０の値は初期値のまま利用する。この更新は、RTTが十分小さい場合は、WAN４０で想定される平均的な障害回復時間を通信停止検出時間８０として利用し、RTTが大きい場合は、ネットワークの障害の検出から回復までもRTT時間程度要すると考えられるため、RTTを通信停止検出時間８０として利用することを意味する。

例えば、通信停止検出時間８０の初期値が５０msで、RTTが２０msであった場合、通信停止検出時間８０を５０msのまま利用する。また、例えば、通信停止検出時間８０の初期値が５０msで、RTTが１００msであった場合、通信停止検出時間８０を１００msに更新する。これは、図２のフローチャートのS３０３→S３０４のステップに相当する。

なお、前記のRTTは、必ずしもコネクションの確立時の値に限る必要はない。コネクション確立後のデータ転送の際に計測した値を用いたり、または、コネクション確立時およびデータ転送時双方で計測して、その平均値や、極端に大きい値を排除した平均値、最小値などを用いたりしてもよい。

クライアント１０、サーバ２０間でコネクションが確立されると、両者の間でのデータ通信が始まる。本例では、クライアント１０がサーバ２０へ向かってデータ転送を行う例を示す。クライアント１０は、データパケットA、B、C、D、E、F、G、H、I、J、Kの送信２２０を行う。通信装置１００−１は、これらのデータパケットを受信するとクライアント１０に対し、点線で示す応答のACKパケットをそれぞれサーバ２０に代わって返信する。一方で、受信したデータパケットをWAN４０上で対向装置となる通信装置１００−２へ向けて転送する。

本実施例を適用した通信装置１００−１は、対向装置となる通信装置１００−２からの転送データパケットに対して、該当データの一部が輻輳などによって消失した場合、それまでに到着しているデータに対するACKと同じ応答シーケンス番号を持つACKパケット、すなわち、重複ACKを受け取ると、しかるべき再送制御を行う。この再送制御には、同じ応答シーケンス番号を持つ重複ACKを３個検出すると、該当シーケンス番号を持つデータパケット以降を再送するファストリトランスミッションがある。この他、重複ACKのオプションフィールドに既到着のデータパケットのシーケンス番号を付与して通知するSelective ACKや、未到着データパケットのシーケンス番号を通知するNegative ACKなどを利用した再送等もある。これは、図２のフローチャートのS３０５→S３０６のステップに相当する。ただし、図３の動作例では、この状況は発生していない。

図３では、データパケット転送の際に、図１２に示すようにWAN４０のルータB４２を含む経路で障害が発生し、障害復旧時間２２２においてWAN４０のルータC４３を含む経路で障害回復したとしている。この障害が発生すると、図１の点線１８０で示す通信が影響を受け、図１２に示すように代替経路１８２を利用して障害回復するまで、該当する通信でネットワーク上に送信された、また、送信されるデータパケット、ACKパケットが、消失する。

本実施例における通信装置１００−１は、対向装置となる通信装置１００−２からの転送データパケットに対するACKが、図３に示すように通信停止検出時間８０を超えるまで検出されないと、障害が発生したものと判断し、それ以降のデータパケットの送信を停止する。これは、図２のフローチャートのS３０７→S３０８→S３０９→S３１０のステップに相当する。なお、本例では、便宜上、クライアント１０からサーバ２０方向へのデータ転送、逆方向へのACK転送を例示しているが、逆方向に行われるデータ転送、ACK転送に対しても同様の処理が適用できる。

通信装置１００−１は、データパケット転送停止後、ネットワークが障害から回復したか否かを、ACK未受信の先頭データパケットのみを再送試行周期８１ごとに単発で送信し、そのACKパケットが到着するかどうかによって検査する。ACKパケットが到着すれば、ネットワークが障害から回復したと判断できる。また、単発のデータパケットを検査に利用することで、ネットワークの輻輳を最小限に抑制することができ、また、このパケットが単なる検査パケットでないことから、最速でデータを目的地に届けることができる。これは、図２のフローチャートのS３１１→S３１２のステップに相当する。

図３の例では、通信停止検出時間８０を超えたあと、通信装置１００−１は、それまでにACKパケットが到着していないデータパケットCを単発で通信装置１００−２に向けて送信する。再送試行周期８１−１経過後にACKパケットが到着していないため、再度データパケットC２４１−１を単発で送信する。更に、再送試行周期８１−２経過後にもACKパケットが到着していないため、再度データパケットC２４１−２を単発で送信する。更に、再送試行周期８１−３経過後にACKパケットが到着していないため、再度データパケットC２４１−３を単発で送信する。

なお、本実施例では、障害発生後のネットワークの輻輳を避けるために、試行的に単発でデータパケットを送信しているが、変形例として複数のデータパケットを送信してもよい。ただし、その場合でも、極力ネットワークの輻輳を避けるためには、複数個を試行送信する場合でも、初回は単発で送信し、繰り返し数が増すたびに同一数のデータパケット、または直前よりも１以上増加させたデータパケットを試行的に送信するほうが望ましい。

障害復旧時間２２２で示すように、ネットワークが障害から回復した後は、前記のように試行的に単発で送信したデータパケットに対してACKパケットが到着するようになる。本実施例では、このACKパケットの到着をもってネットワーク障害からの回復と判断し、それまでACKパケットが到着していない後続のすべてのデータパケットの再送を行う。

なお、この後続のすべてのデータパケットの再送を開始した直後にも、ほぼ再送試行周期８１おきに、試行的に送信したデータパケットの重複ACKパケットが複数個到着しうる。または、障害の発生タイミングによっては、試行的に送信したデータパケットより後続であるはずのデータパケットのうち既に通信装置１００−２に届いているデータパケットの重複ACKパケットが複数個到着しうる。いずれにしても、ネットワーク障害からの回復後に最初に届く重複ACKと同一の重複ACKが複数個届きうる。

従来の再送制御によれば、同一の重複ACK３個で再送を行うファストリトランスミッションや重複ACKに付随するSelective ACKやNegative ACKに基づく再送が行われるが、本実施例では、ネットワーク障害からの回復後に最初に届く重複ACKと同一の重複ACKに対しては、該当データは既に到着しているはずであるため、該当するデータパケットの再送を行わない、すなわち、重複ACKを無視する制御を行う。ここまでの制御は、図２のフローチャートのS３１２→S３１３のステップに相当する。

図３の例で通信装置１００−１では、再送試行周期８１が経過する前にACKパケット２４３−２が到着したため、ネットワーク障害から回復したと判断し、試行データパケットCの後続のデータパケットDからの転送２５０を実行する。データパケットCを試行的に複数回送信しているため、データパケットDの転送後２５０でもデータパケットCに対する重複ACK２４３−３が到着しうるが、ACKパケットが返ってきた時点でデータパケットCは到着していることが自明であるため、この重複ACK２４３−３は無視するように制御する。

このようにしてデータ転送を続け、データ転送が終了すれば、コネクションの切断を行う。図２のフローチャートのS３１４のステップに相当する。

本実施例によれば、ネットワーク障害回復後に迅速に通信装置１００−１が保持しているデータパケットを対向となる通信装置１００−２へ転送できるため、通信装置１００−１のパケットバッファが溢れにくくなり、結果として、クライアント１０は、ネットワーク障害の影響を受けることなく、更なる後続のデータ送信２６０を継続でき、アプリケーションの応答性劣化を避けることができるようになる。

次に、図４の通信装置の構成図と、図５の状態テーブルの構成図、図６のTCP/IPパケット構成図、図７のフローチャートを利用して、本実施例の通信装置１００の一構成例を説明する。

本実施例の通信装置は、任意のLAN間の通信をインタセプトして、データパケットをバッファリングし、LANに配置される端末装置に対し、対向する端末装置の代理となって応答パケット、および、データパケットを転送する手段と、WANに対して任意のパケットフローに属するデータパケットを送信中、WANからのパケットフローに属する応答パケットの受信が、通信停止検出時間として任意のパケットフロー毎に設定した所定の期間以上途絶えた場合に、WANへのパケットフローに属するデータパケット送信を停止する手段と、データパケット送信停止直後に、応答パケット未受信のパケットフローのデータパケットの先頭1個を再送試行周期として設定した所定の間隔でWANへ再送する手段と、WANから応答パケットを受信した時点で、応答パケットを未受信の残りのパケットフローに属するデータパケットをすべて再送する手段を備えることが必要である。

そこで、図４に示すように、通信装置１００は、少なくとも、ネットワークインタフェース部である、LAN側との通信を行うためのLAN側インタフェース１０１、WAN側との通信を行うためのWAN側インタフェース１０２と、パケットの転送処理を行うためのパケット転送処理部１０３を従来のルータやスイッチ同様に備え、加えて、より高度な通信処理を行うためのLAN側受信パケット検査部１１０、LAN側パケットバッファ１１１、LAN側パケット送信部１１２、LAN側タイマ群１１３、WAN側受信パケット検査部１２０、WAN側パケットバッファ１２１、WAN側パケット送信部１２２、WAN側タイマ群１２３、状態テーブル１３０を備える。

なおこのような通信装置は、ネットワークインタフェース部、各種のプログラムを処理する処理部である中央処理部(Central Processing Unit：CPU)、テーブルやバッファとして機能する記憶部としてのメモリを備えた通常のコンピュータで実現可能である。処理部は、パケットの転送処理を行うためのパケット転送処理部１０３、LAN側受信パケット検査部１１０、LAN側パケット送信部１１２、WAN側受信パケット検査部１２０、WAN側パケット送信部１２２の機能を実現する。更には、LAN側タイマ群１１３とWAN側タイマ群１２３も、処理部がメモリを利用してソフトウェア的に実現することも可能である。

図６は、TCP/IP通信に利用されるパケットの主要なフィールド構成を示す図である。TCP/IPであるため、パケットは、L3(Layer3)に、たとえばIPv4(Internet Protocol version4)、L4(Layer4)にTCPを用いる。L2(Layer2)は特に限定されるわけではないが、標準的な例としてイーサネット（登録商標）を利用しているものとする。

このとき、パケットのL2ヘッダ１４０の主要なフィールドとして、宛先MAC(Media Access Control)アドレスDA１４１、送信元MAC(Media Access Control)アドレスSA１４２、L3プロトコル種類を示すTYPE１４３、L2トレイラとしてフレームチェックシーケンスFCS１４４が挙げられる。また、L3ヘッダ１５０の主要なフィールドとして、送信元IPアドレスSIP１５１、宛先IPアドレスDIP１５２、L4プロトコル種類を示すPROTOCOL１５３が挙げられる。また、L4ヘッダ１６０の主要なフィールドとして、送信元ポートSPORT１６１、宛先ポートDPORT１６２、シーケンスナンバーSQN１６３、応答番号ACKN１６４、SYNやACKなどのフラグとして利用するためのコードビット１６５、オプション１６６が挙げられる。そして、実際にこのパケットが運ぶデータであるペイロード１７０が続く。

パケット転送処理部１０３は、受信パケットのヘッダの指定のフィールドを参照してLAN側インタフェース１０１、WAN側インタフェース１０２、LAN側受信パケット検査部１１０、WAN側受信パケット検査部１２０、いずれかへパケットを転送する。

本実施例では、WAN４０のネットワーク障害をクライアント１０やサーバ２０に対して隠蔽したい通信のうち、LAN側からWAN側へ送るべきものはLAN側受信パケット検査部１１０へ転送する。同じく、WAN側からLAN側へ送るべきものはWAN側受信パケット検査部１２０へ転送する。一方で、WAN４０のネットワーク障害をクライアント１０やサーバ２０に対して特に隠蔽する必要のない通信に関しては、LAN側からWAN側へ送るべきものはWAN側インタフェース１０２へ転送する。同じく、WAN側からLAN側へ送るべきものはLAN側インタフェース１０１へ転送する。

これらの転送の際、どの部位へ転送するかを決定するために、基本的には図６に示すパケットのSIP１５１、DIP１５２、PROTOCOL１５３、SPORT１６１、DPORT１６２の5情報(5タプル)を利用する。これらの5情報により、パケットの送受信ペア、及び、利用アプリケーション、L4通信プロトコル種類を特定できる。この5情報は、本実施例の通信装置１００の運用者が該当する通信装置１００へ直接設定しても良いし、プログラム等により状況に応じて変化させても良い。

本実施例の通信装置１００は、図７のフローチャートで示すように、LAN側インタフェース１０１からパケットを受信すると（Ｓ１）、パケット転送処理部１０３にて同パケットの判定処理を行う。結果がWAN４０のネットワーク障害をクライアント１０やサーバ２０に対して隠蔽したい通信でなければ、WAN側インタフェースへパケットを転送する（Ｓ２→Ｓ６）。結果がWAN４０のネットワーク障害をクライアント１０やサーバ２０に対して隠蔽したい通信であれば、同パケットをLAN側受信パケット検査部１１０へ転送する（Ｓ２→Ｓ３）。

LAN側受信パケット検査部１１０では、受信パケットが応答パケットであればLAN側パケット送信部１１２へ通知する。受信パケットがデータパケットであれば、同パケットをLAN側パケットバッファ１１１へ転送しつつ、同パケットを受信した応答をLAN側パケット送信部１１２へ転送する（Ｓ４）。そして、WAN側パケット送信部１２２がパケットを図２のフローチャートに示す制御フローに従い転送する（Ｓ５）。同じく、応答をLAN側パケット送信部が、LAN側で利用される標準的なTCP通信処理の制御フローに従って転送する（同じくＳ５）。

LAN側でもパケット消失が生じる可能性があるが、確率的には、一時的な輻輳による場合が多数を占める。このため、重複ACKに対する従来のファストリトランスミッションやSelective ACK等による制御で迅速なパケット再送が可能である。ネットワーク障害による場合もあり、その場合には、従来のタイムアウト処理が必要で、そのためにコネクション（フロー）毎にLAN側タイマ群１１３の中のタイマを用いる。

また、通信装置１００は、WAN側インタフェース１０２からパケットを受信すると（Ｓ１１）、パケット転送処理部１０３にて同パケットの判定処理を行う。結果がWAN４０のネットワーク障害をクライアント１０やサーバ２０に対して隠蔽したい通信でなければ、LAN側インタフェースへパケットを転送する（Ｓ１２→Ｓ１６）。結果がWAN４０のネットワーク障害をクライアント１０やサーバ２０に対して隠蔽したい通信であれば、同パケットをWAN側受信パケット検査部１２０へ転送する（Ｓ１２→Ｓ１３）。

WAN側受信パケット検査部１２０では、受信パケットが応答パケットであればWAN側パケット送信部１１３へ通知する。受信パケットがデータパケットであれば、同パケットをWAN側パケットバッファ１２１へ転送しつつ、同パケットを受信した応答をWAN側パケット送信部１２２へ転送する（Ｓ１４）。そして、LAN側パケット送信部１１２がパケットをLAN側で利用される標準的なTCP通信処理の制御フローに従って転送する（Ｓ１５）。同じく、応答をWAN側パケット送信部が、図２のフローチャートに示す制御フローに従い転送する（同じくＳ１５）。

WAN側では、一時的な輻輳やネットワーク障害によるパケット消失がLAN側よりも発生しやすい。ネットワーク障害の場合に利用するタイマはコネクション（フロー）毎にWAN側タイマ群１２３の中のタイマを用いる。例えば、あるデータパケットを送信後にタイマをスタートさせる。データパケットを送信するたびに、タイマをクリア、再スタートさせる。応答となるACKパケットがあれば、タイマをクリア、停止させる。ACKパケットが返ってこない場合、タイマはカウントを続けるため、その値がタイムアウト設定値９０を超えるとタイムアウトと判定できる。

また、データパケットを送信後、RTT程度の時間経過後にACKパケット到着が始まるが、ひとたび、ACKパケット受信が無くなると、タイマをクリア、スタートさせる。以後、ACKパケットを受信するたびに、タイマのクリア、スタートを繰り返し、最後に送信したデータに対するACKパケットが返ってきたら、タイマをクリア、停止する。この間、ACKパケットが未到着の場合、前記タイマの値が通信停止検出期間８０を超えると、通信装置１００からのパケット送信を停止する。そのあとの再送試行周期８１のカウントも、WAN側タイマ群１２３のタイマを同様に利用する。また、WAN４０のRTT計測にもWAN側タイマ群１２３のタイマを利用する。図３の例では、通信装置１００−１はSYNパケット２１１送信時にタイマをクリア、スタートさせ、擬似SYN/ACKパケット２１２受信時のタイマの値を往復通信遅延（RTT）とすればよい。

図５に本実施例の状態テーブル１３０の構成要素の一例を示す。状態テーブル１３０は、検索キー５０、LAN側TCP状態６０、WAN側TCP状態７０のフィールドを備える。検索キー５０は、先に説明したパケットのSIP１５１、DIP１５２、PROTOCOL１５３、SPORT１６１、DPORT１６２の5情報を記録し、同一の5情報を持つ入力パケットを、同一パケットフロー（同一コネクション）として分類する。識別する種類がTCPのみと明らかな場合は、PROTOCOL１５３はTCPを示す番号で自明のため、残りのSIP１５１、DIP１５２、SPORT１６１、DPORT１６２の4情報を検索キー５０としても良い。

LAN側TCP状態６０のフィールドは、例えば、プロトコル状態６１、受信データSEN６２、送信末尾SEN６３、ACK受信済SEN６４、タイムアウト設定値６５で構成する。

プロトコル状態６１は、LAN側のTCP状態、例えば、コネクション確立中でSYNパケット受信直後や、SYN/ACKパケットを送信してACKパケット待ち、コネクション確立済み、などの状態を示す。受信データSEN６２は、受信したデータパケットの最後のシーケンス番号を示す。本例では省略しているが、Selective ACKやNegative ACKなどの制御を行う場合は、このほかに、歯抜け状態のデータパケットのシーケンス番号も管理する。送信末尾SEN６３は、送信したデータパケットの最終シーケンス番号を示す。ACK受信済SEN６４は、送信したデータパケットのうちACKパケットを受信しているところまでを示す。タイムアウト設定値６５は、タイムアウト値を示す。

WAN側TCP状態７０のフィールドは、例えば、プロトコル状態７１、受信データSEN７２、送信末尾SEN７３、ACK受信済SEN７４、タイムアウト設定値９０、通信停止検出時間８０、再送試行周期８１で構成する。

プロトコル状態７１は、WAN側のTCP状態、例えば、コネクション確立中でSYNパケット受信直後や、SYN/ACKパケットを送信してACKパケット待ち、コネクション確立済み、などの状態を示す。受信データSEN７２は、受信したデータパケットの最後のシーケンス番号を示す。本例では省略しているが、Selective ACKやNegative ACKなどの制御を行う場合は、このほかに、歯抜け状態のデータパケットのシーケンス番号も管理する。送信末尾SEN７３は、送信したデータパケットの最終シーケンス番号を示す。ACK受信済SEN７４は、送信したデータパケットのうちACKパケットを受信しているところまでを示す。タイムアウト設定値９０は、タイムアウト値を示す。通信停止検出時間８０、再送試行周期８１は、前出の説明の通りである。

以上、実施例１により、ネットワーク障害時にネットワークを輻輳等から守るために不要なパケット送信を停止できる。また、実施例１によると、ネットワーク障害が回復後に、すみやかに通信を再開できる。また、実施例１によると、クライアントやサーバなどの端末に対し、パケットロスを認識させずに済ますことができる。本実施例では標準的に用いられるTCP/IP通信のTCPを前提に説明を行ったが、送信したデータに対して応答を確認する手段を利用する応答確認型の通信プロトコルによる通信であれば、同様に適用することができる。

実施例２では、WAN４０に高信頼なネットワークを採用した場合の障害発生時に通知される障害通知パケットを活用して、実施例１よりも高速に障害で消失したパケットを再送するための通信装置および方法の実施例を説明する。なお、本実施例における、障害通知パケットは、ネットワーク障害発生を通知する障害発生通知パケット、或いはネットワーク障害からの回復を通知する障害回復通知パケットの何れか少なくとも一方を意味することとする。

高信頼なネットワークを実現する技術の一つにMPLS−TPが挙げられる。MPLS−TPの特徴機能の一つに、OAM(Operation Administration and Maintenance)と呼ぶネットワークの保守運用機能がある。具体的には、接続性の確認/監視を行うCC(Continuity Check)/CV(Connectivity Verification)、接続試験のためのLB(LoopBack)、TST(TeST)、高速警報転送のためのAIS(Alarm Indication Signal)、RDI(Remote Defect Indicator)、ネットワークの遅延測定、廃棄率性能測定のためのDM(Delay Measurement)、LM(Loss Measurement)等である。

MPLS−TPでは、パスプロテクションと呼ぶ手法により、ネットワークのEnd to Endで現用系と予備系の通信経路をあらかじめ設定し、現用系の通信経路が利用不能となる障害が発生した場合に、障害発生部位を持つMPLS−TPルータ、もしくは、障害が発生してダウンしたMPLS−TPルータに隣接するMPLS−TPルータは、障害発生通知パケット（AISパケット）を周囲に通知する。障害発生通知パケットがMPLS−TPネットワークの末端まで到達すると予備系の通信経路に自動的に切り替わる。

WAN４０にMPLS−TPを利用した場合、図１、図１２でルータA４１、ルータB４２、ルータC４３、ルータD４４として示した装置はMPLS−TPルータになる。また、このMPLS−TPのWAN４０に接続されるLAN３０−１やLAN３０−２、LAN３０−３には、Ethernet（登録商標）OAM装置と呼ばれる、OAM機能が搭載されたネットワーク終端装置が置かれる。

図１２に示したように、ルータB４２においてルータD４４側のインタフェースで障害が発生すると、ルータB４２は障害発生通知パケットをルータA４１に通知する。ルータA４１にこの通知が届くと図１の点線１８０で示されている通信経路は、図１２の点線１８２で示されている通信経路へと切り替えが行われる。同時に障害発生通知パケットは通信装置１００−１を経由してLAN３０−１のEthernet OAM装置にも通知される。

障害発生通知パケット自体は、該当する障害箇所が復旧しない限り一定周期（例えば１秒周期）で通知され続けるが、パスプロテクション機能により現用系の通信経路から予備系の通信経路に切り替わった後は、それまで予備系であった通信経路が新たな通信経路となるため、障害を起こしている通信経路から発せられる障害発生通知パケットは新たな通信経路とは無関係であるため無視することになる。

一般に、MPLS−TPネットワークの末端に位置する通信装置１００が、MPLS−TPネットワークから受信した障害発生通知パケットをEthernet OAM装置に通知する際には、MPLS−TPネットワーク、すなわち、WAN４０の障害はパスプロテクションの機能により回復しているとみなすことができる。すなわち、通信装置１００にとっては、前記障害発生通知パケットはネットワーク障害からの回復を意味するパケットとして扱うことが可能である。そこで、本実施例２では、この障害発生通知パケットを利用して、ネットワーク障害回復を検出、迅速にデータパケットの再送を行う。

ここで、図１３のフローチャート、図１４の動作例を利用して、本実施例における、障害発生通知パケットを活用した高速データパケット再送方法に関して説明する。図１４で、WAN４０で障害が発生するまでは実施例１と同じ動作であるため説明を省略する。WAN４０で障害が発生すると、障害を検出した装置が障害発生通知パケット２７０を周囲に通知する。WAN４０で障害が発生しているため、通信装置１００−１には障害が生じている通信経路からのACKパケット返信がなくなり、その期間が通信停止検出時間８０に達するかどうかの検査を開始する。

通信装置１００−１は、障害発生通知パケット２７０を検出すると、自身が扱うパケットフロー（コネクション）のいずれに障害の影響があるか判定するために、十分長いと判断できる所定期間、ACKパケットがないパケットフロー（コネクション）はどれであるか検査する。具体的には、この所定期間とは、前記の通信停止検出時間８０の1/2以上の間、ACKパケット返信がないかどうかをパケットフロー毎に検査する。前記の通信停止検出時間８０の1/2以上の間、ACKパケット返信がない場合、該当パケットフローのデータパケット送信を一旦停止したのち、即座にACKパケット未受信のデータパケット以降をすべて再送する。尚、前記の所定期間とは、十分長いと期間と判断できればよいため、必ずしも通信停止検出時間８０の1/2以上である必要はない。状況に応じて1/3や2/3など、他の値の期間としても良い。これは、図１３のフローチャートでS３０８→S３２０→S３２１に相当する。この操作により、実施例１よりも高速に障害で消失したパケットの再送を実現することができる。

一方で、障害発生通知パケット２７０を検出していても、ACKパケット返信があるパケットフロー（コネクション）の場合、例えば、図１や図１２の点線１８１で示す通信経路の通信である場合と考えることができ、一時的な輻輳によるパケット消失であったと判断できるため、そのままデータパケットの送信や、重複ACKパケットに対する部分的なデータパケット再送を行う。これは、図１３のフローチャートでS３０８→S３２０→S３２２→S３１４→S３０５→S３０６→S３０７→S３０８に相当する。

また、場合によっては、図１５に示すように、前記の通信停止検出時間８０の間ACKパケット返信がなく、かつ、障害発生通知パケット２７０も検出できない状態も存在する。この場合、実施例１と同様に、ACKパケット未検出開始時点から通信停止検出時間８０後に該当パケットフロー（コネクション）に対するデータパケット送信を停止する。続いて、実施例１と同様にACKパケット未受信の先頭データパケットを試行的に単発で再送する。

再送試行周期８１が経過する前に障害発生通知パケット２７０を検出すれば、検出直後、即座にACKパケット未受信のデータパケット以降をすべて再送する。これは、図１３のフローチャートでS３０８→S３２０→S３２２→S３１０→S３１１→S３２３→S３１３に相当する。

再送試行周期８１が経過しても障害発生通知パケット２７０を検出できなければ、実施例１と同様に、再度、再送試行周期８１後にACKパケット未受信の先頭データパケットを試行的に単発で再送する。そして、次の再送試行周期８１が経過する前に障害発生通知パケット２７０が検出できるかどうか、また、ACKパケットがあるかどうかを調べ、いずれかが検出できれば即座にACKパケット未受信のデータパケット以降をすべて再送（図１３のフローチャートでS３１１→S３２３→S３１３、および、S３１１→S３２３→S３１２→S３１３）、検出できなければ再度同じ検出操作を繰り返す（図１３のフローチャートでS３１１→S３２２→S３１２→S３１１）。

いずれにしても、実施例２のこうした操作により、実施例１よりも高速に障害で消失したパケットの再送を実現することができる。

なお、こうした操作を実現するための通信装置１００の構成は、実施例１と同様の図４の構成で実現できる。ただし、パケット転送処理部１０３、WAN側受信パケット検査部１２０に次の処理ができるように機能を追加する。この機能の追加は、先に説明した処理部が実行するプログラムの追加で実現可能である。

まず、パケット転送処理部１０３には、WAN側インタフェース１０２から通知される障害発生通知パケット２７０を認識し、WAN側受信パケット検査部１２０へ転送する機能を追加する。通信装置１００がMPLS−TPのネットワークのエンドポイントとするのであれば、パケット転送処理部１０３にはLAN３０側からのパケットにMPLSのラベル（Shimヘッダ）を追加・削除する機能、および、MPLS−TPネットワーク内における障害発生通知パケット２７０のフォーマットを識別する機能を持たせる。通信装置１００がMPLS−TPネットワークのエンドポイント外部とするのであれば、パケット転送処理部１０３にはEthernet区簡における障害発生通知パケット２７０のフォーマットを識別する機能を持たせる。

図１６に、MPLS−TPネットワーク内における障害発生通知パケット２７０の例を示す。障害発生通知パケット２７０は、通常のイーサネットのL2ヘッダと同一のDA１４１、SA１４２、TYPE１４３を備え、そのTYPEの中身に、上位プロトコルがMPLSであることを示す値（例えば、0x8847）が入る。なお、VLANを利用している場合は、SA１４２とTYPE１４３の間にVLANタグのフィールドが追加される。TYPE１４３に続き、MPLSのShimヘッダ１７１が入り、OAMフレームであることを示す0x1の固定値とバージョン番号のフィールド１７２、チャネルタイプフィールド１７３、メッセージフィールド１７４があり、メッセージフィールドの値が１であることによって障害発生通知パケット（AIS）であることを示す。このほか詳細なOAM情報がその他OAM情報フィールド１７５で管理される。

また、図１７に、MPLS−TPネットワーク外部のEthernet区間における障害発生通知パケット２７０の構成を示す。障害発生通知パケット２７０は、通常のイーサネットのL2ヘッダと同一のDA１４１、SA１４２、TYPE１４３を備える。なお、VLANを利用している場合は、SA１４２とTYPE１４３の間にVLANタグのフィールドが追加される。TYPE１４３に続き、管理単位（Maintenance Entity）グループを識別するためのMEGレベル１４５、バージョン番号１４６、制御コード１４７、フラグ１４８などに続きOAM情報１４９のフィールドが用意される。OAM情報１４９に記載されている値によって、障害発生通知パケット２７０であるか否かを区別することができる。

いずれの場合も、通信装置１００のパケット転送処理部１０３は、レイヤ２．５、または、レイヤ２相当で障害発生通知パケット２７０を検出し、WAN側受信パケット検査部１２０へ転送する。WAN側受信パケット検査部１２０は、障害発生通知パケット２７０を受信すると、図１３のフローチャートのS３２０やS３２２として示しているように、通信停止検出時間８０の経過後、もしくは、再送試行周期８１の期間内にレイヤ４での制御となるACK未受信のデータパケットの再送を行う制御機能を追加する。

以上のように、実施例２では、通信装置１００にMPLS装置としての機能およびMPLS−TPの障害発生通知パケット２７０を検出しデータパケットの再送を行うための機能、もしくは、Ethernet OAMの障害発生通知パケット２７０を検出しデータパケットの再送を行うための機能を追加することで、実施例１に比べて高速に（より短い時間で）障害で消失したパケットを再送するための通信装置および方法を提供することができる。

本実施例では障害通知パケットが障害発生通知パケットであることを前提に説明を行ったが、ネットワークが障害から回復したことを通知する障害回復通知パケットを利用することができる場合、上述してきた本実施例の障害発生通知パケットを障害回復通知パケットとして扱うことで同様の効果を得ることができる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したのであり、必ずしも説明の全ての構成を備えるものに限定されものではない。

また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることが可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、それぞれの機能を実現するプログラムを実行することによりソフトウェアで実現する場合を例示して説明したが、各機能を実現するプログラム、テーブル、ファイル等の情報はメモリのみならず、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体におくことができるし、必要に応じてネットワーク等を介してダウンロード、インストロールすることも可能である。

以上上述した本明細書においては、特許請求の範囲の請求項各項に記載の発明以外の発明が種々開示されている。その一例は、下記の通りである。

例１．複数の第一のネットワーク間を接続し、応答確認型の通信プロトコルによるデータ通信を行う第二のネットワークの末端に配置されるパケット通信装置のパケット通信方法であって、前記第一のネットワーク間の通信をインタセプトして、データパケットをバッファリングし、前記第一のネットワークに配置される端末装置に対し、代理となって応答パケット、および、データパケットを転送するステップと、前記第二のネットワークに対して任意のパケットフローに属するデータパケットを送信中、前記第二のネットワークからの前記パケットフローに属する応答パケットの受信が、任意の前記パケットフロー毎に設定した通信停止検出時間以上途絶えた場合に、前記第二のネットワークへの前記パケットフローに属するデータパケット送信を停止するステップと、前記第二のネットワークから、前記第二のネットワークの障害発生、或いは障害からの回復を通知する障害通知パケットを受信する迄、或いは受信した後の、所定期間の間、前記応答パケットを未受信の、前記パケットフローのデータパケットを再送するステップを備える、ことを特徴とするパケット通信方法。

例１に記載のパケット通信方法であって、
前記応答パケット未受信の所定期間が、前記通信停止検出時間を経過している前記パケットフローに対し、前記第二のネットワークへの前記パケットフローに属するデータパケット送信を停止するステップと、前記データパケット送信停止直後に、応答パケット未受信の前記パケットフローのデータパケットの先頭1個を再送試行周期として設定した所定の間隔で前記第二のネットワークへ再送するステップと、前記第二のネットワークから応答パケットを受信した時点、または、前記障害通知パケットを受信した時点で、前記応答パケットを未受信の残りの前記パケットフローに属するデータパケットを再送するステップを更に備えることを特徴とするパケット通信方法。

実施例３では、図１においてクライアント１０、サーバ２０間でデータ通信中に通信装置１００−１や通信装置１００−２が障害を起こした場合でも、転送中のデータの整合性を維持するための通信装置および方法の実施例を説明する。

図３で説明したデータパケット転送では、TCP/IPセッションのコネクション２１０を確立後、通信装置１００−１は、クライアント１０からデータパケットを受け取るたびに、該当するデータパケット（例えば、データパケットA、B、C、、、）に対する応答パケット（ACKパケット。例えばACK A、ACK B、ACK C、、、）を返信する。同様に、通信装置１００−２は通信装置１００−１に対し、また、サーバ２０は通信装置１００−２に対して該当するデータパケットに対する応答パケットを返信する。

この方法では、クライアント１０が送信したデータパケット全てがサーバ２０へ到着する前に通信装置１００−１や通信装置１００−２が障害で停止してしまった場合、実際にはデータ転送が完了していないにもかかわらず、クライアント１０は全てのACKパケットを受領済であるため、クライアント１０とサーバ２０の間でデータの不整合が生じてしまう。

この問題に対処するために、通信装置１００では、あるデータパケット到着後、次のデータパケット到着時から1パケット分ずらしてACKパケットを返信し始め、かつ、該当データの最後のデータパケットがサーバ２０へ到着後、サーバ２０から返信されるACKパケットを通信装置１００がクライアント１０へ返信する方法がある。この方法により、通信中に通信装置１００で障害が発生するとクライアント１０は正常にデータ転送を終了できなかったことを検知できるため、クライアント１０のTCPレイヤが再度、該当するデータパケットの再送を行ったり、クライアント１０の上位アプリケーションがデータ転送異常の場合の処理を行ったりすることで、クライアント１０とサーバ２０のデータの不整合を避けることができる。

前記方法を実施例１に適用したパケット転送処理例の説明図を図１８に示す。図３との差分は、通信装置１００−１が、クライアント１０からのデータパケット転送２２０に対し、１パケット分ずらしてACKパケットを返信し始めていることである。同様に、通信装置１００−２は、通信装置１００−１からのデータパケット転送に対し、１パケット分ずらしてACKパケットを返信し始めていることである。サーバ２０の通信装置１００−２に対するACKパケット返信は図３と変わりない。

また、図１８では、図３と同じタイミングで障害が発生した場合、ACKパケットAまでが通信装置１００−２から通信装置１００−１に届く。このとき、通信装置１００−１は、通信停止検出期間８０が経過した後、再送を試行するための再送パケットとして図３より１パケット分前のパケットに相当するデータパケットBを利用する。また、この例では、データパケットKまでがクライアント１０が送信したいデータだとした場合、データパケットKがサーバ２０に到着した段階でサーバ２０が通信装置１００−２へ返信するACKパケットKを、通信装置１００−２が通信装置１００−１へ返信する。同じく、通信装置１００−１が前記ACKパケットKをクライアント１０へ返信する。それ以外の操作は、実施例１と同じである。

この方法により、ネットワーク障害の回復直後に消失したパケットを復元、またTCP/IP通信を迅速に再開させ、実効的なパケットロスを回避させつつ、通信装置１００が障害を起こした際にも、クライアント１０とサーバ２０のデータの不整合を避けることができる。

以上の実施形態によると、ネットワーク障害時にネットワークを輻輳等から守るために不要なパケット送信を停止できる。また、上述の実施形態によると、ネットワーク障害が回復後に、すみやかに通信を再開できる。また、上述の実施形態によると、クライアントやサーバなどの端末に対し、パケットロスを認識させずに済ますことができる。以上の実施形態により、通信装置１００が障害を起こした場合でも、転送中のクライアント１０とサーバ２０の間でのデータの整合性を維持するパケット通信装置および方法に関して説明した。

１０クライアント
２０サーバ
３０ LAN
４０ WAN
８０通信停止検出時間
８１再送試行周期
９０タイムアウト周期
１００通信装置
１０１ LAN側インタフェース
１０２ WAN側インタフェース
１０３パケット転送処理部
１１０ LAN側受信パケット検査部
１１１ LAN側パケット送信部
１１２ LAN側タイマ群
１２０ WAN側受信パケット検査部
１２１ WAN側パケット送信部
１２２ WAN側タイマ群
１３０状態テーブル

Claims

複数の第一のネットワーク間を接続し、応答確認型の通信プロトコルによるデータ通信を行う第二のネットワークの末端に配置されるパケット通信装置であって、
ネットワークインタフェース部と、処理部とを備え、
前記処理部は、
前記ネットワークインタフェース部を介して、前記第一のネットワーク間の通信をインタセプトして、データパケットをバッファリングし、
前記第一のネットワークに配置される端末装置に対し、代理となって応答パケット、および、データパケットを転送し、
前記第二のネットワークに対して任意のパケットフローに属するデータパケットを送信中、前記第二のネットワークからの前記パケットフローに属する応答パケットの受信が、任意の前記パケットフロー毎に設定した通信停止検出時間以上途絶えた場合に、前記第二のネットワークへの前記パケットフローに属するデータパケット送信を停止し、
前記データパケット送信停止後に、前記パケットフローに属する、応答パケット未受信のデータパケットの先頭1個を、任意の前記パケットフロー毎に設定した再送試行周期で前記第二のネットワークへ再送し、
前記第二のネットワークから応答パケットを受信した時点で、応答パケットを未受信の残りの前記パケットフローに属するデータパケットを再送する、
ことを特徴とするパケット通信装置。
請求項１に記載のパケット通信装置であって、
前記処理部は、
任意のパケットフロー毎設定した前記通信停止検出時間が、前記パケットフローを中継する前記第二のネットワーク両端の二台の当該パケット通信装置間の往復通信遅延よりも小さい場合、前記通信停止検出時間を前記往復通信遅延で更新する、
ことを特徴とするパケット通信装置。
請求項２に記載のパケット通信装置であって、
前記処理部は、
前記往復通信遅延を、前記パケットフローのコネクション確立時に計測した値、
前記パケットフローのコネクション確立後のデータパケット転送時に計測した値の平均値或いは最小値、または、
前記コネクション確立時及び前記コネクション確立後のデータパケット転送時に計測した値の平均値或いは最小値、を利用して算出する、
ことを特徴とするパケット通信装置。
請求項１に記載のパケット通信装置であって、
前記処理部は、
前記データパケット送信停止後に、前記第二のネットワークへ再送するデータパケットの個数を、複数個、または、初回再送時は１個としその後の再送のたびに増加する、
ことを特徴とするパケット通信装置。
請求項１に記載のパケット通信装置であって、
前記処理部は、
前記パケットフロー毎に優先度を少なくとも高、低の二種類以上設定し、高優先と設定した前記パケットフローに対しては、低優先と設定した前記パケットフローに適用する前記再送試行周期よりも短い前記再送試行周期に設定する、
ことを特徴とするパケット通信装置。
請求項１に記載のパケット通信装置であって、
前記処理部は、
前記第二のネットワークへ前記データパケット送信停止後、前記パケットフローに属する、前記応答パケット未受信の前記データパケットを再送し、前記第二のネットワークから前記データパケットの応答パケットを受信した後に受信する、同一データパケットに対する重複応答パケットを受信しても、前記重複応答パケットに対するデータパケットの再送処理を実施しない、
ことを特徴とするパケット通信装置。
複数の第一のネットワーク間を接続し、応答確認型の通信プロトコルによるデータ通信を行う第二のネットワークの末端に配置されるパケット通信装置であって、
ネットワークインタフェース部と、処理部とを備え、
前記処理部は、
前記ネットワークインタフェース部を介して、前記第一のネットワーク間の通信をインタセプトして、データパケットをバッファリングし、
前記第一のネットワークに配置される端末装置に対し、代理となって応答パケット、および、データパケットを転送し、
前記第二のネットワークに対して任意のパケットフローに属するデータパケットを送信中、前記第二のネットワークからの前記パケットフローに属する応答パケットの受信が、任意の前記パケットフロー毎に設定した通信停止検出時間以上途絶えた場合に、前記第二のネットワークへの前記パケットフローに属するデータパケット送信を停止し、
前記第二のネットワークから、前記第二のネットワークの障害発生、或いは障害からの回復を通知する障害通知パケットを受信した後、前記パケットフローに属する、前記応答パケットを未受信のデータパケットを再送する、
ことを特徴とするパケット通信装置。
複数の第一のネットワーク間を接続し、応答確認型の通信プロトコルによるデータ通信を行う第二のネットワークの末端に配置されるパケット通信装置のパケット通信方法であって、
前記第一のネットワーク間の通信をインタセプトして、データパケットをバッファリングし、前記第一のネットワークに配置される端末装置に対し、代理となって応答パケット、および、データパケットを転送するステップと、
前記第二のネットワークに対して任意のパケットフローに属するデータパケットを送信中、前記第二のネットワークからの前記パケットフローに属する応答パケットの受信が、任意の前記パケットフロー毎に設定した通信停止検出時間以上途絶えた場合に、前記第二のネットワークへの前記パケットフローに属するデータパケット送信を停止するステップと、
前記データパケット送信停止後に、前記パケットフローに属する、応答パケット未受信のデータパケットの先頭1個を、任意の前記パケットフロー毎に設定した再送試行周期で前記第二のネットワークへ再送するステップと、
前記第二のネットワークから応答パケットを受信した時点で、前記パケットフローに属する、応答パケットを未受信の残りのデータパケットを再送するステップを備える、
ことを特徴とするパケット通信方法。
請求項８に記載のパケット通信方法において、
前記任意のパケットフロー毎に設定した前記通信停止検出時間が、前記パケットフローを中継する前記第二のネットワークの両端間の往復通信遅延よりも小さい場合、前記通信停止検出時間を前記往復通信遅延で更新する、
ことを特徴とするパケット通信方法。
請求項８に記載のパケット通信方法において、
前記往復通信遅延は、前記パケットフローのコネクション確立時に計測した値、
前記パケットフローのコネクション確立後のデータパケット転送時に計測した値の平均値或いは最小値、または、
前記コネクション確立時及び前記コネクション確立後のデータパケット転送時に計測した値の平均値或いは最小値、を利用する、
ことを特徴とするパケット通信方法。
請求項８に記載のパケット通信方法において、
前記データパケット送信停止後に、前記第二のネットワークへ再送するデータパケットの個数を、複数個、または、初回再送時は１個としその後の再送のたびに増加する、
ことを特徴とするパケット通信方法。
請求項８に記載のパケット通信方法において、
前記パケットフロー毎に優先度を少なくとも高、低の二種類以上設定し、高優先と設定した前記パケットフローに対しては、低優先と設定した前記パケットフローに適用する前記再送試行周期よりも短い前記再送試行周期に設定する、
ことを特徴とするパケット通信方法。
請求項９に記載のパケット通信方法において、
前記第二のネットワークへ前記データパケット送信停止後、前記応答パケット未受信の前記パケットフローの前記データパケットを再送し、前記第二のネットワークから前記データパケットの応答パケットを受信した後に受信する同一データパケットに対する重複応答パケットを受信しても、前記重複応答パケットに対するデータパケットの再送処理を実施しない、
ことを特徴とするパケット通信方法。
請求項９に記載のパケット通信方法において、
前記第二のネットワークから、前記第二のネットワークの障害発生、或いは障害からの回復を通知する障害通知パケットを受信した後、前記パケットフローに属する、前記応答パケットを未受信のデータパケットを再送する、
ことを特徴とするパケット通信方法。