JPH11112576A - インターネットワーク装置のコネクション制御方法 - Google Patents

Abstract

(57)【要約】 【課題】高速なネットワークにおいて、ＴＣＰによるフ
ロー制御により制限される回線使用率の低下を防ぐ。 【解決手段】インターネットワーク装置（ルータ）３０
７，３０８は、隣接ホスト３０１，３０２，３０４，３
０５との通信相手となるホストとの間のＴＣＰコネクシ
ョンを監視し、ＴＣＰのフロー制御による回線使用率の
低下を検出すると、相手ホストに代って隣接ホストに対
して受信確認セグメントを送ることにより、相手ホスト
との間に生じる遅延時間を克服する。また、ルータ３０
７，３０８は、隣接ホストから送信されたデータをメモ
リ内に保存し、相手ホストの再送要求に対してメモリ内
のデータを用いて再送応答する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、複数のネットワー
クを相互に接続して、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓ
ｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔ
ｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を実装したインターネ
ット装置において、高い回線使用率を実現するコネクシ
ョン制御方法に関する。

【０００２】

【従来の技術】ある端末の最上位層のアプリケーション
レイヤで生成された通信メッセージは、下位層のＴＣＰ
レイヤおよびインターネットプロトコル（以下、ＩＰと
記す）レイヤに伝達され、自端末と相手端末の各ドライ
バを介して送受信を行い、相手端末のＩＰレイヤから上
位層のＴＣＰレイヤに伝達され、さらにアプリケーショ
ンレイヤに伝達されることにより、アプリケーション相
互間で通信が行われる。この場合、送受信両端末の間を
メッセージが経由する他の端末では、ドライバからＩＰ
レイヤまでしかメッセージは伝達されることはない。従
って、ＩＰは信頼性のないデータグラム（ＩＰデータ単
位）の配送しか提供していない。この場合のホストーホ
スト間の信頼性は、ＩＰの上位レイヤに位置するＴＣＰ
が行う。ＴＣＰは、上位のアプリケーションレイヤに対
してコネクションオリエンテッド（接続指向型）なサー
ビスを提供し、通信の信頼性を保証する。ＴＣＰは、通
信の信頼性確保のためにチェックサムによるパケットエ
ラーのチェックやシーケンス番号を用いた正当な順序性
の確保及び重複の排除を行うのみならず、データ転送の
際には受信確認を行い、必要な場合には再送等の手段を
用いて信頼性のあるサービスを提供するように努力す
る。ＴＣＰは、さらにフロー制御により相手が送信する
ことができるデータ量のコントロールを行い、受信側が
処理可能な範囲内での通信を行うと同時に、スロースタ
ートアルゴリズムによるネットワーク内で起こる輻輳の
回避を行う。

【０００３】ＴＣＰのフロー制御は、スライドする送信
ウィンドウに基づいて行われる。このウィンドウ制御を
用いることにより、送信側が確認をすることなく複数の
データスリームを連続して送信することが可能となり、
その結果、スループットを向上させることができる。Ｔ
ＣＰは、本来、エンドーエンド間のプロトコルであっ
て、送信側及び受信側の双方でのみ動作し、中継経路中
のインターネットワーク装置等では動作しない。中継経
路中のＴＣＰ制御機能に関する従来の技術としては、例
えばパケッティア社のＰａｃｋｅｔＳｈａｐｅｒがあ
る。この装置は、送信側と受信側の間に入って、双方間
のＴＣＰ制御パケットを奪い取り、その代りとなるＴＣ
Ｐ制御パケットを渡すことにより、帯域幅のコントロー
ルを行い、バースト的に発生するトラフィックの分散を
行うことにより、一定のサービスの品質（ＱｏＳ：Ｑｕ
ａｒｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）を確保することが
可能となる。また、例えば特開平８−３３９３５４号
公報に記載のネットワーク分散処理システムでは、シス
テム間通信もシステム内通信と同じように、分散共有メ
モリ経由で行うことを基本とし、システム間で共通の分
散共有メモリ空間を共有させる。送信プロセッサモジュ
ールの分散メモリカップラが通信の方向を判断し、各プ
ロトコルに合わせて送信側と受信側の共有メモリの同一
アドレスロケーション間でコピーを行うことにより、Ｗ
ＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）を経由し
たシステム間通信のソフトウェアオーバヘッドを削減
し、処理効率を向上させることができる。

【０００４】

【発明が解決しようとする課題】前述の従来技術で
は、低速回線を用いた場合において、バースト的に発生
するトラフィックの分散を主目的としているため、高速
回線を用いたときに起こるＴＣＰのフロー制御によるデ
ータ送信効率の低減を抑制することはできない。ＴＣＰ
ヘッダのウィンドウフィールドは、１６ビット長しかな
いため、受信確認なしに一度に送ることができるデータ
のサイズは、約６万５千バイトに制限される。これは少
なくとも約６万５千バイトにつき１回は受信確認のやり
取りが行われ、その度毎に送信が中断することを意味し
ている。この制限は、ネットワークの帯域幅は狭いとき
やラウンドトリップ遅延が小さいときには殆んど問題に
はならないが、十分な帯域幅が確保された高速なネット
ワークの場合やラウンドトリップ遅延が大きな場合に
は、ウィンドウサイズがネックになるため帯域を十分に
活用することができない。ＴＣＰの最近の実装において
は、ウィンドウスケールオプションを用いてウィンドウ
サイズの倍率を指定することが可能になっているが、古
いＴＣＰの実装や安易なＴＣＰの実装ではこのオプショ
ンを用いることはできない。また、ウィンドウスケール
オプションを用いた場合においても、最大ウィンドウサ
イズは約１万６千バイトに制限されるため、将来出現す
るであろう超高速なネットワークにおいては、やはりウ
ィンドウサイズがネックになりうる。このように、ＴＣ
Ｐはフロー制御を行うことにより、信頼性のあるエンド
ーエンドの通信を確保するが、フロー制御が制限にな
り、十分に回線の帯域を活用することができないという
問題があった。そこで、本発明の目的は、このような従
来の課題を解決し、ラウンドトリップ遅延の大きい高速
なネットワークにおいても、ウィンドウサイズによる送
信ネックを抑制し、回線の使用効率を向上させることが
可能なインターネットワーク装置のコネクション制御方
法を提供することにある。

【０００５】

【課題を解決するための手段】上記目的を達成するた
め、本発明によるインターネットワーク装置のコネクシ
ョン制御方法では、複数のネットワークを相互に接続
し、ＴＣＰ／ＩＰを実装したネットワーク層レイヤ３の
ＩＰパケットの中継処理を行うインターネットワーク装
置において、インターネットワーク装置から直接配送さ
れるネットワークに接続される隣接ホストと、その隣接
ホストとの通信相手となる相手ホストとの間で行われる
ＴＣＰコネクションを監視し、ＴＣＰのフロー制御によ
る回線使用率の低下を検出するとともに、前記フロー制
御により回線使用率が低下している場合には、相手ホス
トの代りに隣接ホストに対して受信確認セグメントを送
ることにより、相手ホストとの間に生じる遅延時間を克
服する。また、前記ＴＣＰのフロー制御による回線使用
率の低下を検出する場合に、ＴＣＰコネクションに関連
する回線の帯域幅、インターネットワーク装置自身にお
いて計算される回線使用率、ＲＳＶＰによる帯域予約状
況、及び隣接ホストと相手ホストとの間のラウンドトリ
ップ遅延時間、隣接ホストと相手ホストとの間で合意さ
れたウィンドウサイズから、ＴＣＰのフロー制御による
回線使用率低下を検出する。さらに、隣接するホストか
らその相手ホストへ送信されるＴＣＰセグメントの信頼
性を保証するため、隣接するホストから送信されるデー
タセグメントをメモリに保存し、隣接ホストとの間の順
序制御及びエラーチェックを行い、エラー発生時には隣
接ホストへの再送要求を行い、相手ホストからの再送要
求に対しては、保存したメモリ内のデータを用いて再送
要求に応答する。

【０００６】

【発明の実施の形態】以下、本発明の動作原理及びその
実施例を、図面により詳細に説明する。 （動作原理）本発明においては、送信ホストに隣接する
インターネットワーク装置がＴＣＰコネクションを監視
し、各時刻における回線使用率が最適となるようにＴＣ
Ｐ受信確認パケットを相手受信ホストの代りに送出する
ことにより、ウィンドウサイズの制限を克服する。通
常、インターネットワーク装置の中継処理は、ネットワ
ーク層レイヤ３のみで行われる。インターネットワーク
装置は自身が保持しているレイヤ３（ＩＰレベル）の中
継処理テーブルの情報を基に受信したデータパケットを
どのインターフェースから送出すべきかを判断し、該当
するインターフェースに向けて送出する。本発明では、
インターネットワーク装置は受信したデータパケットを
一旦ＩＰの上位層であるＴＣＰレベルまで押し上げ、イ
ンターネットワーク装置を経由するＴＣＰコネクション
の監視を行う。ＴＣＰコネクションを検出できない場合
には、再びＩＰレベルまでデータパケットが戻され、通
常のＩＰレベルでの中継処理を行う。インターネットワ
ーク装置を経由するコネクションを検出した場合、その
インターネットワーク装置は、上記コネクションに関し
て以下の条件が成立するか否かの検証を行う。 （条件１）データ送信側ホストは自身と隣接しているか
否か、（つまり、自身から直接配送のネットワーク上に
送信側ホストが接続されているか否か） （条件２）ＴＣＰコネクションの関連する回線の帯域
幅、帯域予約状況、ラウンドトリップ遅延時間、ウィン
ドウサイズからＴＣＰの最大スループットを計算し、こ
のＴＣＰコネクションに関連した回線の持つ帯域を有効
に使用することができないか否か、

【０００７】上記各条件のいずれかでも成立しない場合
には、データパケットは再びＩＰレベルまで落されて、
通常の中継処理を行う。また、上記各条件が両方とも成
立した場合には、本発明におけるインターネットワーク
装置は、このコネクション用のバッファを用意し、以
後、このコネクションに関連するデータパケットをこの
バッファに保存するとともに、再びＩＰレイヤまでデー
タパケットを戻し、通常のデータ中継処理を行う。デー
タパケットのバッファリングが開始された後に行われる
送信側、受信側双方のＴＣＰ制御（データ転送以外のＴ
ＣＰセグメントの送受信）はインターネットワーク装置
が肩代りして行う。つまり、送信側からのＴＣＰ制御は
インターネットワーク装置がそのＴＣＰ制御に対する応
答（さも、受信ホストからの応答であるかのように振舞
う）を行い、また受信側からのＴＣＰ制御はインターネ
ットワーク装置がその応答（さも、送信側からの応答で
あるかのように振舞う）を行う。また、必要な場合に
は、インターネットワーク装置側からＴＣＰ制御を送信
または受信側に対してそれぞれの相手になり代って行
う。上記処理を行うことにより、データセグメント送信
後の受信確認待ち時間をラウンドトリップ時間からイン
ターネットワーク装置と隣接する送信側ホスト間の２点
間の送信時間に短縮することが可能になり、ＴＣＰのフ
ロー制御による回線使用率低下を抑制することが可能に
なる。

【０００８】データのバッファリングは、ＴＣＰの信頼
性を保証するために必要である。例えば、インターネッ
トワーク装置から受信側ホストに到達するまでの間に、
送信データが何等かの理由によりデータ化けが起り、受
信側ホストがチェックサムエラーを検出した場合を考え
る。このとき、受信側ホストのＴＣＰは再送要求を送信
側ホストに送出する。しかし、この時点で、このデータ
に対する受信確認セグメントは既にインターネットワー
ク装置から送信ホストに送られており、送信側ホストの
ＴＣＰは送信ウィンドウを次へと移しているため、この
受信側からの要求に対処することはできない。このよう
な事態に備えて、このインターネットワーク装置ではＴ
ＣＰバッファリングを行い、保存してあるデータを用い
て受信側からの再送に対処する。受信ホストからの再送
要求に対して自身に保存してあるデータを基にして行う
ということは、バッファに保存されるデータの信頼性が
保証されている必要がある。バッファ内のデータの信頼
性を保証するために、このインターネットワーク装置
は、バッファをベースとしたＴＣＰ処理（順序制御、エ
ラー処理等）を行う。例えば、送信側から送られたＴＣ
Ｐセグメントにおいてチェックサムエラーがあった場合
には、それを受けたインターネットワーク装置は再送要
求を送信ホストに要求を出し、正しいデータが保存され
るように努力する。上記のことを実現するためには、イ
ンターネットワーク装置にＴＣＰを実装する必要があ
る。本来、インターネットワーク装置はネットワークレ
イヤ３以下でのみ動作し、その上位層まで関知すること
はないため、ＩＰの上位層であるＴＣＰの実装は必須で
はない。しかし、インターネットワーク装置の保守用に
ｔｅｌｅｎｅｔやｆｔｐのようなアプリケーションが必
要になる場合が多く、殆んどのインターネットワーク装
置にはＴＣＰが実装されている。そのため、本発明を実
現するために既存のプロトコルスタックを改造するだけ
で、容易に実現できる。また、データの送信側及び受信
側双方のプロトコルスタックの変更も必要なく、送信側
に隣接するインターネットワーク装置のソフトウェアの
変更のみで実現が可能である。

【０００９】（実施例）図１は、本発明が適用されるル
ータ装置（インターネットワーク装置）のモジュール構
成図である。本発明のルータ装置は、通信を中継する機
能を有し、自身で送信および受信は行わない。ルータ装
置は、パケットの中継処理やＴＣＰの制御等のソフトウ
ェア処理を行う主プロセッサ（ＣＰＵ）１０１と、動作
するソフトウェアをロードする目的の他に各種通信制御
のバッファとして用いられる主記憶装置（メモリ）１０
２と、このルータ装置上で動作させる制御ソフトウェア
や構成定義情報を格納するためのディスク装置１０３
と、複数の各種通信回線を制御するための回線制御機構
１０５，１０６とから構成され、各装置は装置内バス１
０４により接続されている。ここで構成定義情報は、ル
ーティングプロトコルに関する情報やアドレス情報等が
登録されている。ルータ装置は、電源が投入されると、
ディスク装置１０３から制御ソフトウェアが主記憶装置
１０２にロードされ、このソフトウェアが主プロセッサ
１０１により処理される。制御ソフトウェアは、ディス
ク装置１０３内に格納されている構成定義情報を読み込
み、各種回線制御装置を動作させるとともに構成定義情
報に従ったパケット中継処理を行う。

【００１０】図２は、図１のルータ装置上で動作するソ
フトウェアの構成図である。通信の制御を行うソフトウ
ェアは、図２に示す階層構造を形成している。最下層レ
イヤには、各種の異なる通信回線制御装置を制御するた
めのドライバ部２０１があり、その上位層には、ＩＰデ
ータグラムの中継処理、その他のＩＰ処理を行うＩＰ処
理部２０２と、ＣＳＭＡ／ＣＤ（Ｃａｒｒｉｅｒ Ｓｅ
ｎｓｅ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ ｗｉｔｈ
Ｃｏｌｌｉｓｉｏｎ Ｄｅｔｅｃｔｉｏｎ）方式のＬＡ
Ｎ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）におい
て、ＩＰアドレスとハードウェアアドレスとの間の対応
付けを行うＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉ
ｏｎ Ｐｒｏｔｏｃｏｌ）処理部２０３と、システム間
の種々の調停のため制御コードをやり取りするためのＩ
ＣＭＰ（ＩｎｔｅｒｎｅｔＣｏｎｔｒｏｌ Ｍｅｓｓａ
ｇｅ Ｐｒｏｔｏｃｏｌ）処理部２０４と、実時間処理
の必要な通信に対して帯域を予約するためのプロトコル
であるＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔ
ｉｏｎ Ｐｒｏｔｏｃｏｌ）を処理するためのＲＳＶＰ
処理部２０５とが設けられる。さらにその上位層には、
それぞれＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔ
ｒｏｌ Ｐｒｏｔｏｃｏｌ）、ＵＤＰ（Ｕｓｅｒ Ｄａ
ｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）を処理するためのＴ
ＣＰ処理部２０６およびＵＤＰ処理部２０７と、このル
ータ装置間を経由するＴＣＰコネクションを監視し、ウ
ィンドウサイズによる通信ネックとなる場合に代替受信
確認セグメントを送出して帯域幅の有効活用を行うコネ
クション制御部２０８とが設けられる。なお、ＴＣＰは
コネクションを張って接続するのに対して、ＵＤＰはコ
ネクションを張らずに制御セグメントを送出するのみで
ある。さらに、最上位層には、他のルータ装置との経路
情報のやり取りを行い、ＩＰ処理部２０２が参照する経
路情報テーブルを更新するルーティング処理部２０９
と、アプリケーションプログラムであるｆｔｐ（ｆｉｌ
ｅ ｔｒａｎｓｆｅｒｐｒｏｔｏｃｏｌ）と、ｔｅｌｎ
ｅｔとが設けられる。

【００１１】図３は、本発明のルータ装置を用いたネッ
トワーク構成例を示す図である。図３において、３０７
及び３０８が、上記構成を持つ本発明のルータ装置であ
る。２台のパーソナルコンピュータ（以下、ＰＣ）３０
１，３０２及びルータ装置３０７は、１００Ｍビット／
秒の帯域幅を持つＬＡＮ３０３により接続され、また同
様に２台のワークステーション（以下、ＷＳ）３０４，
３０５とルータ装置３０８も１００Ｍビット／秒のＬＡ
Ｎ３０６により接続される。２台のルータ装置３０７と
３０８の間は、ＡＴＭスイッチ群により構成されるＡＴ
Ｍネットワーク網３０９に接続され、１５５Ｍビット／
秒の帯域が確保されるが、ルータ装置間の距離は非常に
離れており（例えば、東京ーサンノゼ間）、ネットワー
クの遅延は非常に大きいものとする。ＰＣ３０２のＴＣ
Ｐはウィンドウスケールオプションを実装しておらず、
そのため最大ウィンドウサイズは６５５３６バイトであ
るとする。いま、図３のＰＣ３０１とＷＳ３０４の間で
ビデオ会議アプリケーションを用いた通信を行っている
ものとする。このアプリケーションは、ＲＳＶＰを用い
て３０Ｍバイト／秒の帯域予約を行っているものとす
る。このビデオ会議アプリケーションはエンドーエンド
間の通信にＵＤＰを用いているため、ＴＣＰのコネクシ
ョンは存在しないものとする。この時、ＰＣ３０２とＷ
Ｓ３０５の間において、ＴＣＰの上位アプリケーション
であるｆｔｐを用いたファイル転送を行う場合を考え
る。

【００１２】図４は、図３におけるＷＳ３０５からＰＣ
３０２へデータ転送する際の通常の通信シーケンスチャ
ートである。ここでは、通常のＴＣＰを用いてデータ転
送している場合を示している。先ず、ｐｈａｓｅ１で
は、ＷＳ３０５からＰＣ３０２に対してシーケンス２６
３０００〜３２８５３６のデータセグメントの送信を行
い、ｐｈａｓｅ２においてＰＣ３０２からＷＳ３０５に
対してｐｈａｓｅ１で受信したデータの受信確認及び次
に行われるｐｈａｓｅ３のウィンドウサイズ６５５３６
バイトの指定を行っている。同様に、ｐｈａｓｅ３で
は、次の６５５３６バイトのセグメントの送信を行い、
ｐｈａｓｅ４でその確認を行っている。図４の右側に示
したＴｔ及びＴｄはそれぞれ６５５３６バイトを送信す
るのに要した時間と、ネットワークのラウンドトリップ
遅延時間を示している。このように、ＰＣ３０２とＷＳ
３０５の間には有効な帯域幅が７０Ｍビット／秒存在す
る。すなわち、ＰＣ３０１とＷＳ３０４との間では、Ｌ
ＡＮの１００Ｍビット／秒の帯域予約をＲＳＶＰを用い
て行っているので、ＰＣ３０２とＷＳ３０５の間の通信
にはその帯域を差し引いた残りの帯域のみで行う必要が
あり、実際に使用できるのは１００Ｍビット／秒から３
０Ｍビット／秒を引いた値となる。さらに、Ｔｄの遅延
が存在するため、７０Ｍビット／秒のうちの（Ｔｔ／Ｔ
ｄ）×１００％しかデータ転送には用いられない。この
例のように、高速なネットワークで、かつ遅延時間が大
きいときほど、ウィンドウサイズの制限がネットワーク
の回線使用率に重大な影響を及ぼす結果になる。

【００１３】図５は、本発明の一実施例を示す代理受信
確認を行う場合の通信シーケンスチャートである。前述
のように、高速なネットワークで、かつ遅延時間が大き
い場合には、ウィンドウサイズの制限がネットワークの
回線使用率に大きな影響を及ぼす。この問題を克服する
ため、本発明においては、送信側に隣接するルータ装置
３０８がＴＣＰの受信確認セグメントをＰＣ３０２の代
りに発行し、ＷＳ３０５に送ることにより遅延時間によ
る回線使用率の低下を抑制する。図５において、ルータ
装置３０８はｗｓ３０５とＰＣ３０２とのＴＣＰコネク
ションを監視し、回線の帯域幅を効率的に使用するよう
にルータ装置３０８がＰＣ３０２の代りにＷＳ３０５に
対して受信確認セグメントを発行すると同時に、ＰＣ３
０２からＷＳ３０５に対して送信されてくる受信確認セ
グメントを削除する。図５に示すように、ルータ装置３
０８がＰＣ３０２の代りに受信確認をＷＳ３０５に送る
ことにより、ルータ装置３０８とＰＣ３０２との間の送
受信遅延を取り除くことが可能となるので、高いスルー
プットを得ることができる。

【００１４】本発明のルータ装置は、ＴＣＰのウィンド
ウサイズの制限により回線の持つ帯域幅を有効に使用す
ることができない場合においてのみ代理で受信確認セグ
メントの発行を行い、その他の場合にはこの処理を行わ
ない。ルータ装置３０８は、１００Ｍビット／秒の帯域
幅を持つＬＡＮインタフェースと１５５Ｍビット／秒の
帯域幅を持つＡＴＭインタフェースの２つのインタフェ
ースを装備しており、ここではそれぞれｌａｎ、ａｔｍ
と表現することにする。ｌａｎ及びａｔｍインタフェー
スの有効な帯域幅Ｂ１及びＢ２は、それぞれ次式
（１）、次式（２）で表わされる。 Ｂ１＝Ｂａｔｍ×（Ｒａ／１００）−Ｂｒ ・・・・・・・・・・（１） Ｂ２＝Ｂｌａｎ×（Ｒｌ／１００）−Ｂｒ ・・・・・・・・・・（２） ここで、Ｂａｔｍ及びＢｌａｎはそれぞれのインタフェ
ースが持つ帯域幅、Ｒａ及びＲｌはそれぞれＡＴＭ及び
ＬＡＮインタフェースの回線使用率、またＢｒはルータ
装置において割り当てられたＲＳＶＰによる予約帯域を
示す。ＷＳ３０５からＰＣ３０２への通信時には、ｌａ
ｎ，ａｔｍ双方のインタフェースを使用するため、この
通信に有効な帯域幅Ｂｂは次式（３）で表現できる。 Ｂｂ＝ｍｉｎ（Ｂ１，Ｂ２） ・・・・・・・・・・・・・・・・・（３）

【００１５】一方、ＷＳ３０５とＰＣ３０２の間のラウ
ンドトリップ遅延時間をＴ、またＷＳ３０５とＰＣ３０
２の間で合意したウィンドウサイズをＷとすると、この
ＴＣＰコネクションでの最大スループットＢｗは次式
（４）で表わされる。 Ｂｗ＝Ｗ／Ｔ ・・・・・・・・・（４） ここで、ウィンドウサイズＷはウィンドウスケールオプ
ションを考慮した値であっても差し支えない。もし、前
式（４）のＢｗより前式（３）のＢｂの方が大きい場合
には、ＴＣＰのウィンドウサイズによる回線使用制限が
発生していることになる。一方、Ｂｂの方がＢｗより大
きい場合には、ＴＣＰのウィンドウサイズによる回線使
用制限よりむしろ有効帯域幅がネックになっていると言
える。そのためにルータ装置３０８では、ＷＳ３０５と
ＰＣ３０２との間のＴＣＰコネクションを監視し、ルー
タ装置が持っているその時点の回線使用率及び帯域予約
状況から次式（５）を算出し、式（５）が真になる場合
にのみ代理受信確認応答処理を行う。 （Ｂｂ＞Ｂｗ） ・・・・・・・・（５） これまでに述べた隣接するルータ装置による代理受信確
認による方法は、ＷＳ３０５からＰＣ３０２へのデータ
送信で全てエラーがなく届いたときのみ有効に機能す
る。しかし、ルータ装置３０８からＰＣ３０２へのデー
タ送信過程で新ータにエラーが発生した場合には、回復
する方法がない。すなわち、ＷＳ３０５は、ルータ装置
３０８から受信確認セグメントを受信した後に、ＰＣ３
０２からの再送要求が届いても、混乱してしまうと予想
される。ここでＷＳ３０５は、先に受信した受信確認セ
グメントをＰＣ３０２から来たものであると思っている
からである。このため、本発明においては、ルータ装置
３０８がデータのバッファリングを行い、ＰＣ３０２か
らの再送要求に対応できるようにする必要がある。

【００１６】図６は、本発明の他の実施例を示す再送要
求に対処したシーケンスチャートである。図６では、Ｗ
Ｓ３０５からシーケンス番号２６３００から３２８５３
６までのＴＣＰセグメントが送信され、ルータ装置３０
８からＰＣ３０２までの間にエラーがあったセグメント
のみの再送要求を行っている。しかし、このデータに対
する受信確認セグメントの送出は、ルータ装置３０８か
らＷＳ３０５に対して既に行われているため、ＷＳ３０
５に対して再送要求を送ることはＴＣＰの動作に矛盾が
起ってしまう。このような問題を解決するために、本発
明においては、ルータ装置３０８はＷＳ３０５から送ら
れる全てのデータをルータ装置３０８上のメモリ１０２
に保存し、ＰＣ３０２からの再送要求時にはこの保存さ
れたデータを参照して再送要求に応答する。このデータ
は、ＰＣ３０２からのこのデータに対する受信確認セグ
メントが送られてくるまでメモリ１０２内に保存され
る。

【００１７】一旦、ＰＣ３０２から再送要求が届くと、
ルータ装置３０８は自身に貯えられたＷＳ３０５からの
データを用いてそれまでに行われた通信の復旧を行い、
復旧が終了するまでＷＳ３０５には受信確認セグメント
の送出は行わない。復旧処理が完了した時点で、ルータ
装置３０８はＷＳ３０５に対して受信確認セグメントの
送出を行い、通信を再開させる。このように、ルータ装
置３０８はＷＳ３０５とＰＣ３０２間のＴＣＰコネクシ
ョンにおいて行われるデータを自身のメモリ内に保存す
ることにより、再送要求に対応させている。しかし、こ
れはルータ装置３０８内のメモリに保存されるデータに
エラーがないこと、そして順序が正しいことを前提とし
ている。このことを保証するために、ルータ装置３０８
は通常のＴＣＰによるデータ転送と同様のことをＷＳ３
０５との間で行い、保存するデータの妥当性を保証す
る。例えば、ＷＳ３０５からＰＣ３０２宛に送信された
データセグメントにエラーを見つけた場合には、ルータ
装置３０８はそのままＰＣ３０２に対してデータを渡さ
ずに、ＷＳ３０５に対して再送要求を行い、エラーの修
復を行う。また、順序通りに届かなかったデータセグメ
ントに対しては、自身のメモリ内においてデータ順序の
再構成を行う。

【００１８】図６では、ＷＳ３０５からルータ装置３０
８にはデータ１〜５を正常に転送したので、ルータ装置
３０８はメモリにデータ１〜５をバッファリングすると
ともに、ＰＣ３０２に対して転送するとともに、ルータ
装置３０８からＷＳ３０５に対して代理受信確認を行
う。しかし、ルータ装置３０８とＰＣ３０２との通信経
路中にエラーが発生したため、ＰＣ３０２からデータ４
について再送要求が返送された。その時点では、ＷＳ３
０５からデータ６〜１０の送信が終了し、ルータ装置３
０８から代理受信確認が返送されている。そして、ＷＳ
３０５からはデータ１１〜１５がルータ装置３０８に対
して転送されている。ルータ装置３０８は、このデータ
１１〜１５をメモリに格納する。ルータ装置３０８は、
その時点で以降の代理受信確認を中止し、ＰＣ３０２に
対してメモリに保存していたデータ４をＰＣ３０２に再
送する。ＰＣ３０２からＡｃｋ６が返送されると、ルー
タ装置３０８は次のデータ６〜１０までをメモリから取
り出して送信する。ＰＣ３０２からＡｃｋ１１が返送さ
れると、ルータ装置３０８はメモリに保存しているデー
タ１１〜１５をＰＣ３０２に転送する。ＰＣ３０２から
Ａｃｋ１６が返送されると、ルータ装置３０８はメモリ
にデータが残っていないため、その時点でＷＳ３０５に
対して代理受信確認を行う（Ａｃｋ１６）。

【００１９】図７は、本発明の一実施例を示すルータ装
置のパケット中継処理のフローチャートである。このフ
ローは、図１に示したルータ装置のＬＡＮ回線制御機構
１０５及びＡＴＭ回線制御機構１０６からＣＰＵ１０１
へのハードウェア割り込み処理により起動される（ＳＴ
ＡＲＴ）。図３におけるＬＡＮ３０６からのデータ受信
により、図２に示すルータ装置３０８のＬＡＮドライバ
部２０１がＬＡＮフレームの受信処理を行い（ステップ
７０１）、そのデータをＩＰ処理部２０２に渡す。ＩＰ
データグラムを受けたＩＰ処理部２０２はＩＰの受信処
理を行い（ステップ７０２）、中継処理を行う前に上位
レイヤであるＴＣＰ制御部２０６に引き渡す。このＴＣ
Ｐ処理部２０６が本発明におけるＴＣＰコネクション制
御を行う部分である。ＴＣＰ制御部２０６はコネクショ
ンの監視を行い、ＴＣＰコネクション制御が有効な場合
においてのみバッファリング、ＴＣＰの肩代り処理を行
う（ステップ７０３）。バッファリングや肩代り処理を
行った後、ＩＰ処理部２０２に渡し、ＩＰ中継処理を行
い（ステップ７０４）、さらにＬＡＮドライバ部２０１
に引き渡して、送信処理を行う（ステップ７０５）。一
方、ＴＣＰコネクション制御が必要ない場合には、再び
ＩＰ処理部２０２にＩＰデータグラムが戻され、ルーテ
ィングテーブルの情報をもとにＩＰ中継処理を行い（ス
テップ７０４）、適切なインタフェースからＩＰデータ
グラムが送出される（ステップ７０５）。

【００２０】図８は、図７におけるＴＣＰ制御部の詳細
フローチャートである。ＴＣＰ制御部２０６では、先ず
ＴＣＰのデータであるか否かを判断し（ステップ８０
１）、隣接ホストからの送信であるか否かのチェックを
行う（ステップ８０２）。どちらかが該当しない場合に
は、ＴＣＰコネクション制御を行わずにそのままＩＰデ
ータグラムの中継処理に戻す（ステップ８１１）。どち
らにも該当する場合には、既にコネクション制御を行っ
ているか否かを判別し（ステップ８０３）、コネクショ
ン開始前のものであれば、コネクション確立用のＴＣＰ
セグメントであるか否かの検査を行う（ステップ８０
４）。その結果、コネクション確立用のＴＣＰ制御セグ
メントである場合には、前式（５）つまり（Ｂｂ＞Ｂ
ｗ）の判定を行い（ステップ８０５）、真の場合にはコ
ネクションの登録及び監視を開始する（ステップ８０
６）。一方、既にコネクションの登録が行われていた場
合には（ステップ８０３）、データのバッファリングを
行った後（ステップ８０７）、このバッファをベースと
した代替えＴＣＰ処理を行う（ステップ８０８）。この
バッファベースのＴＣＰ処理では、これまでに述べた代
理ＴＣＰ受信セグメントの送出やバッファ内の順序制
御、再送要求、再送要求に対する代理応答等が行われ
る。ＴＣＰ処理が終了した後、必要なデータをＩＰ送信
処理に渡し（ステップ８０９）、不要になったバッファ
内のデータの削除を行い、バッファを開放して処理を終
了する（ステップ８１０）。

【００２１】

【発明の効果】以上説明したように、本発明によれば、
送受信を行うホストのプロトコルスタックを変更するこ
となく、高速なネットワークにおいてＴＣＰによるフロ
ー制御により制限される回線使用率の低下を防ぐことが
でき、高いスループットを得ることができる

【図面の簡単な説明】

【図１】本発明が適用されるルータ装置のハードウェア
構成図である。

【図２】図１におけるルータ装置のソフトウェア構成図
である。

【図３】本発明が適用されるネットワーク構成例を示す
図である。

【図４】本発明を使用しない通常のＴＣＰ動作のシーケ
ンスチャートである。

【図５】本発明の一実施例を示す代理受信確認動作のシ
ーケンスチャートである。

【図６】本発明の他の実施例を示す再送発生時の動作シ
ーケンスチャートである。

【図７】本発明のルータ装置における中継処理のフロー
チャートである。

【図８】図７におけるＴＣＰ制御部の処理フローチャー
トである。

【符号の説明】

１０１…ＣＰＵ、１０２…メモリ、１０３…ディスク、
１０４…内部バス、１０５…ＬＡＮ回線制御機構、１０
６…ＡＴＭ回線制御機構、２０１…ＬＡＮ回線制御機構
ドライバ部、ＡＴＭ回線制御機構ドライバ部、２０２…
ＩＰ処理部、２０３…ＡＲＰ処理部、２０４…ＩＣＭＰ
処理部、２０５…ＲＳＶＰ処理部、２０６…ＴＣＰ処理
部、２０７…ＵＤＰ処理部、２０８…コネクション制御
部、２０９…ルーティング処理部、３０１，３０２…Ｐ
Ｃ、３０４，３０５…ＷＳ、３０７，３０８…ルータ装
置、３０９…ＡＴＭ網、３０３，３０６…ＬＡＮ。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 新 善文 神奈川県海老名市下今泉810番地 株式会 社日立製作所オフィスシステム事業部内 (72)発明者 迫田 博幸 神奈川県秦野市堀山下１番地 株式会社日 立インフォメーションテクノロジー内

Claims (3)

【特許請求の範囲】
1. 【請求項１】 複数のネットワークを相互に接続し、Ｔ
   ＣＰ／ＩＰを実装したネットワーク層レイヤ３のＩＰパ
   ケットの中継処理を行うインターネットワーク装置のコ
   ネクション制御方法において、 前記インターネットワーク装置は、中継受信したデータ
   パケットをＩＰの上位層のＴＣＰレベルに渡し、 該ＴＣＰレベルで該インターネットワーク装置を経由す
   るＴＣＰコネクションの監視を行い、 経由するＴＣＰコネクションを検出した場合、データ送
   信側ホストが自身と隣接しており、かつＴＣＰのフロー
   制御による回線使用率が低下しているときには、データ
   受信側ホストに代って隣接する前記データ送信側ホスト
   に対して受信確認セグメントを送ることを特徴とするイ
   ンターネットワーク装置のコネクション制御方法。
2. 【請求項２】 請求項１に記載のインターネットワーク
   装置のコネクション制御方法において、 前記インターネットワーク装置は、ＴＣＰのフロー制御
   による回線使用率低下を検出するために、ＴＣＰコネク
   ションに関連する回線の帯域幅、インターネットワーク
   装置自身で計算される回線使用率、ＲＳＶＰによる帯域
   予約状況、及び隣接ホストとの間のラウンドトリップ遅
   延時間、ならびに隣接ホストと相手ホストとの間で合意
   されたウィンドウサイズから検出することを特徴とする
   インターネットワーク装置のコネクション制御方法。
3. 【請求項３】 請求項１に記載のインターネットワーク
   装置のコネクション制御方法において、 前記インターネットワーク装置は、隣接するホストから
   その相手ホストへ送信されるＴＣＰセグメントの信頼性
   を保証するため、該隣接するホストに受信確認セグメン
   トを送るとともに、該隣接するホストから送信されるデ
   ータセグメントをメモリに保存し、 該隣接ホストとの間の順序制御及びエラーチェックを行
   い、エラー時には該隣接ホストへの再送要求を行い、 前記相手ホストからの再送要求に対しては、保存したメ
   モリ内のデータを用いて該再送要求に応答することを特
   徴とするインターネットワーク装置のコネクション制御
   方法。