(57)【要約】【課題】ウィンドウサイズをヘッダに持つプロトコルのパケットの通信において、パケットのフラグメンテーションの発生を低減する通信制御方法、ゲートウェイ、および、記録媒体を提供する。【解決手段】異なるネットワークあるいは通信回線を接続するゲートウェイにおいて、ウインドウサイズを含むヘッダを有するパケットを転送する際に、パケットの転送するに先立ち、転送先の通信媒体のＭＴＵを調査する手段と、転送元の通信媒体のＭＴＵを調査する手段と、前記調査の値をもとに転送するパケットのヘッダのウインドウサイズを修正する手段を有する。従って、ウインドウサイズをＭＴＵより小さい適当な値に修正したとすると、ウインドウサイズを修正されたパケットを受信した端末は、前記パケットに返信する際にパケットサイズをウインドウサイズ以下とするため、パケットのフラグメンテーションを低減することが可能となる。【選択図】        図１
2004328220.tif 000002
【特許請求の範囲】
【請求項１】
異なるネットワークあるいは通信回線を接続するゲートウェイにおける通信制御方法であって、
ウィンドウサイズを含むヘッダを有するプロトコルのパケットを転送する際に、
受信したパケットを転送するに先立ち、
転送先のネットワークあるいは通信回線の最大転送単位（ＭＴＵ）を調査するステップと、
転送元のネットワークあるいは通信回線の最大転送単位（ＭＴＵ）を調査するステップと、
前記転送するパケットのヘッダを解析しウィンドウサイズを得るステップと、
前記ウィンドウサイズが前記両者のＭＴＵより大きい場合にウィンドウサイズをいずれのＴＭＵより小さな値に修正するステップを有することを特徴とする通信制御方法。
【請求項２】
異なるネットワークあるいは通信回線を接続するゲートウェイにおける通信制御方法であって、
ウィンドウサイズを含むヘッダを有するプロトコルのパケットを転送する際に、
受信したパケットを転送するに先立ち、
転送先のネットワークあるいは通信回線の最大転送単位（ＭＴＵ）を調査するステップと、
転送元のネットワークあるいは通信回線の最大転送単位（ＭＴＵ）を調査するステップと、
前記転送元のＭＴＵが前記転送先のＭＴＵより小さい場合に前記転送するパケットのヘッダを解析しウィンドウサイズを得るステップと、
前記ウィンドウサイズが前記転送元のＭＴＵより大きい場合にウィンドウサイズを前記転送元のＭＴＵより小さな値に修正するステップを有することを特徴とする通信制御方法。
【請求項３】
ゲートウェイに接続されているネットワークあるいは通信回線の構成の変化を検出した場合に、
前記構成の変化したネットワークあるいは通信回線に関するＭＴＵ情報を破棄するステップを有することを特徴とする請求項１〜２記載の通信制御方法。
【請求項４】
上記プロトコルはＴＣＰ／ＩＰであることを特徴とする請求項１〜３記載の通信制御方法。
【請求項５】
上記ネットワークの一つはＩＥＥＥ１３９４で構成されていることを特徴とする請求項１〜４記載の通信制御方法。
【請求項６】
異なるネットワークあるいは通信回線を接続するゲートウェイであって、
ウィンドウサイズを含むヘッダを有するプロトコルのパケットを転送する際に、
受信したパケットを転送するに先立ち、
転送先のネットワークあるいは通信回線の最大転送単位（ＭＴＵ）を調査する手段と、
転送元のネットワークあるいは通信回線の最大転送単位（ＭＴＵ）を調査する手段と、
前記転送するパケットのヘッダを解析しウィンドウサイズを得る手段と、
前記ウィンドウサイズが前記両者のＭＴＵより大きい場合にウィンドウサイズをいずれのＴＭＵより小さな値に修正する手段を有することを特徴とするゲートウェイ。
【請求項７】
異なるネットワークあるいは通信回線を接続するゲートウェイであって、
ウィンドウサイズを含むヘッダを有するプロトコルのパケットを転送する際に、
受信したパケットを転送するに先立ち、
転送先のネットワークあるいは通信回線の最大転送単位（ＭＴＵ）を調査する手段と、
転送元のネットワークあるいは通信回線の最大転送単位（ＭＴＵ）を調査する手段と、
前記転送元のＭＴＵが前記転送先のＭＴＵより小さい場合に前記転送するパケットのヘッダを解析しウィンドウサイズを得る手段と、
前記ウィンドウサイズが前記転送元のＭＴＵより大きい場合にウィンドウサイズを前記転送元のＭＴＵより小さな値に修正する手段を有することを特徴とする通信制御方法。
【請求項８】
ゲートウェイに接続されているネットワークあるいは通信回線の構成の変化を検出する手段と、
構成の変化を検出した場合に前記構成の変化したネットワークあるいは通信回線に関するＭＴＵ情報を破棄する手段を有することを特徴とする請求項６〜７記載のゲートウェイ。
【請求項９】
上記プロトコルはＴＣＰ／ＩＰであることを特徴とする請求項６〜８記載のゲートウェイ。
【請求項１０】
上記ネットワークの一つはＩＥＥＥ１３９４で構成されていることを特徴とする請求項６〜９記載のゲートウェイ。
【請求項１１】
異なるネットワークあるいは通信回線を接続するゲートウェイにおけるプログラムを記録した記録媒体であって、
ウィンドウサイズを含むヘッダを有するプロトコルのパケットを転送する際に、
受信したパケットを転送するに先立ち、
転送先のネットワークあるいは通信回線の最大転送単位（ＭＴＵ）を調査するステップと、
転送元のネットワークあるいは通信回線の最大転送単位（ＭＴＵ）を調査するステップと、
前記転送するパケットのヘッダを解析しウィンドウサイズを得るステップと、
前記ウィンドウサイズが前記両者のＭＴＵより大きい場合にウィンドウサイズをいずれのＴＭＵより小さな値に修正するステップを有するプログラムを記録したことを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項１２】
異なるネットワークあるいは通信回線を接続するゲートウェイにおけるプログラムを記録した記録媒体であって、
ウィンドウサイズを含むヘッダを有するプロトコルのパケットを転送する際に、
受信したパケットを転送するに先立ち、
転送先のネットワークあるいは通信回線の最大転送単位（ＭＴＵ）を調査するステップと、
転送元のネットワークあるいは通信回線の最大転送単位（ＭＴＵ）を調査するステップと、
前記転送元のＭＴＵが前記転送先のＭＴＵより小さい場合に前記転送するパケットのヘッダを解析しウィンドウサイズを得るステップと、
前記ウィンドウサイズが前記転送元のＭＴＵより大きい場合にウィンドウサイズを前記転送元のＭＴＵより小さな値に修正するステップを有するプログラムを記録したことを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項１３】
ゲートウェイに接続されているネットワークあるいは通信回線の構成の変化を検出した場合に、
前記構成の変化したネットワークあるいは通信回線に関するＭＴＵ情報を破棄するステップを有するプログラムを記録したことを特徴とする請求項１１〜１２記載のコンピュータ読み取り可能な記録媒体。
【請求項１４】
上記プロトコルはＴＣＰ／ＩＰであることを特徴とする請求項１１〜１３記載のコンピュータ読み取り可能な記録媒体。
【請求項１５】
上記ネットワークの一つはＩＥＥＥ１３９４で構成されていることを特徴とする請求項１１〜１４記載のコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、動的に最大転送単位（ＭＴＵ）が変化するインターフェース、例えばＩＥＥＥ１３９４を用いたネットワークと、他のネットワークを接続し、ウィンドウサイズを含むヘッダを有するプロトコル、例えばＴＣＰ／ＩＰで通信する際の、通信制御方法、ゲートウェイ、および、記録媒体に関するものである。
【０００２】
【従来の技術】
従来から、異なる媒体同士のネットワーク同士を接続し相互通信を行うには、ゲートウェイ、あるいは、ルータと呼ばれるような機器で両ネットワークを接続し、前記ゲートウェイが、送信先のネットワークに適するようにパケットを変換することによって行われてきた。
【０００３】
例えば、オフィスや家庭で、コンピュータなどの通信機能を持つ電子機器を接続し、ネットワークを構築する際は、イーサネット（Ｒ）（Ｒ）、ファストイーサネット（Ｒ）（Ｒ）と呼ばれるインターフェースで、プロトコルはＴＣＰ／ＩＰ用いる場合が多い。
【０００４】
この場合において、上記ネットワークをＩＳＤＮ回線などの異なる通信媒体を用いて外部のネットワークと接続する場合や、ＩＥＥＥ１３４９により構築されたネットワークと接続する場合は、イーサネット（Ｒ）（Ｒ）とはパケット形態が異なるためゲートウェイを介して接続しなければならない。
【０００５】
ゲートウェイは転送するデータの形式を変換する役割を担うが、その変換作業は、パケット形式の変換とパケットサイズの変換に大きくわけることができる。
【０００６】
パケット形式の変換とは、転送するパケットを受信した際に、転送元の媒体に固有のヘッダを取り除き、送信する際に転送先の媒体に固有のヘッダを付加することである。
【０００７】
パケットサイズの変換とは、転送先の媒体の最大転送単位（ＭＴＵ：  Ｍａｘｉｍｕｍ  Ｔｒａｎｓｆｅｒ  Ｕｎｉｔ）より転送するパケットサイズが大きい場合に必要が生じる。この場合には、ゲートウェイは転送するパケットを、転送先媒体のＭＴＵ以下のサイズに複数のパケットに分割して送信する。この動作はフラグメンテーション（Ｆｒａｇｍｅｎｔａｔｉｏｎ）と呼ばれる。
【０００８】
ところが、フラグメンテーションを行うには、転送するパケットをバッファに保存し、転送するサイズ毎にデータを取り出し、受信側でパケットを再構築できるような情報を付加してから転送しなければならず、オーバーヘッドが発生する。
【０００９】
このため、フラグメンテーションを避ける手法として特開平５−２２３４５号公報は、ネットワークにつながる各装置のルーティングテーブルを拡張し、パケットが途中経由するネットワークの最小ＭＴＵを記録し、パケットを送信する際は前記ルーティングテーブルを参照し、常に最適なパケットサイズを選択することにより、パケットのフラグメンテーションを抑止する方法を提案した。
【００１０】
また、特開２０００−１２４９５０号公報には、各端末がＭＴＵ通知手段を備え、パケットの送信を要求するアプリケーションが、送信に先立ち、ＭＴＵ通知手段を通じて物理媒体のＭＴＵを知ることにより最適なデータ長で転送できる手法が記載されている。
【００１１】
一方、上記２つの広報とは目的が異なるが、特開平５−９１１４４号公報には、パケットを中継するゲートウェイの通信用バッファのオーバフローを低減するために、バッファサイズを管理する手段と、パケットヘッダのウィンドウサイズを解析する手段を備え、空きバッファサイズに合わせてウィンドウサイズを修正する手法が記載されている。
【００１２】
この手法を用いることにより、このゲートウェイを通してパケットを受信した端末は、そのパケットに対する返信をする際には、修正されたウィンドウサイズ以下のサイズのパケットを送ることになり、ゲートウェイでのバッファオーバフローを回避することができることになる。
【００１３】
【発明が解決しようとしている課題】
前述の特開平５−２２３４５、および、特開２０００−１２４９５０号公報は、各端末が事前に通信経路の最小のＭＴＵを知ることができることを前提としている。しかし、送信先の端末までに複数のゲートウェイを通過しなければならない場合や、ＩＥＥＥ１３９４の様に接続順序や接続形態によってＭＴＵが異なるような通信媒体を利用する場合は非常に困難となる。
【００１４】
また、これらの手法は端末に新たな装置、あるいは、ソフトウエアを組み込まねばならず、既にネットワークにつながっている多くの端末に対しては機能せず、汎用性に乏しい。
【００１５】
一方の特開平５−９１１４４号公報の手法では、ゲートウェイを通過するパケットのウィンドウサイズを修正することでパケットサイズをコントロールしているため、既存の端末を接続した場合においても機能する。
【００１６】
しかし、上記手法はゲートウェイのバッファの空きサイズに応じて、パケットサイズをコントロールし、バッファオーバフローを抑制するのが目的である。そのため、転送元のネットワークと転送先のネットワーク間でＭＴＵの差が存在する場合には、当該ゲートウェイにおいて、パケットのフラグメンテーションが生じ、通信効率が低下する可能性がある。
【００１７】
本発明の目的は、前記従来の問題点を解消し、従来の通信機器が接続されたネットワーク間をつなぐゲートウェイにおいて、パケットのフラグメンテーションを抑制し、また、前記ネットワークがＩＥＥＥ１３９４の様な動的にＭＴＵが変化するような場合であっても機能するような通信制御方法、および、ゲートウェイ、記録媒体を提供することである。
【００１８】
【課題を解決するための手段】
上記目的を達成するため、本出願に係る第一の発明は、異なるネットワークを接続するゲートウェイにおいて、ウィンドウサイズを含むヘッダを有するパケットを転送する際に、受信したパケットを転送するに先立ち、転送先の通信媒体のＭＴＵを調査する手段と、転送元の通信媒体のＭＴＵを調査する手段と、前記調査の値を元に転送するパケットのヘッダのウィンドウサイズフィールドを修正する手段を有することを特徴とする。
【００１９】
また、好ましくは当該ゲートウェイに接続されているネットワークの構成の変化を検出する手段と、前記構成の変化したネットワークに関するＭＴＵ情報を破棄する手段を有することを特徴とする。
【００２０】
上記構成において、ウィンドウサイズをＭＴＵから必要なヘッダサイズを引いた値以下に修正したとすると、ウィンドウサイズを修正されたパケットを受信した端末は、前記パケットに返信する際に、パケットサイズを前記修正されたウィンドウサイズ以下とするため、パケットのフラグメンテーションを低減することが可能となる。
【００２１】
【発明の実施の形態】
以下に、添付図面を参照して本発明の好ましい実施の形態について詳細に説明する。
【００２２】
（第一の実施例）
図４に、本発明のゲートウェイを用いたネットワークの接続形態の例を示す。この図では端末３〜５が接続されたネットワーク２と、端末７〜９が接続されたネットワーク６が、ゲートウェイ１を介して接続されている。端末３〜５が端末７〜９にパケットを送信したい場合や、端末７〜９が端末３〜７にパケットを送信したい場合はゲートウェイ１へパケットの中継を依頼することになる。
【００２３】
ネットワーク２及びネットワーク６の具体的な接続形態や、接続可能な端末数は各ネットワークで使用する通信媒体により決定さる。また、ネットワーク２とネットワーク６の通信媒体は同じである必要はなく、むしろ、異なる場合の方が本発明の効果が得られる。
【００２４】
本実施例では、ネットワーク２にイーサネット（Ｒ）（Ｒ）を利用し、ネットワーク６にＩＥＥＥ１３９４を利用した場合について説明する。これは、イーサネット（Ｒ）（Ｒ）は現在ＬＡＮで最も一般的に利用されている通信媒体であり、ＩＥＥＥ１３９４は将来的に利用の拡大が見込まれるだけでなくＭＴＵについて様々な制限があり、本発明の通信制御方法およびゲートウェイが効果的に機能するため、本発明の実施例として適切であると考えられるからである。
【００２５】
また、ゲートウェイ１に接続できるネットワークの数は、必ずしも２つであるわけではなく、より多くのネットワークを接続可能であり、接続数の制限は本発明によるものではなく、ゲートウェイに利用するハードウエア等の別の要因によるものである。
【００２６】
本発明では、これらのネットワークで送受信されるパケットのヘッダは、ウィンドウサイズフィールドを含んでいる必要がある。本実施例では、プロトコルとしてＴＣＰ／ＩＰを利用した場合について説明する。その他のプロトコルの場合においても、ウィンドウサイズフィールドが存在するならば、容易に適用できる。
【００２７】
図５にＴＣＰパケットの形式を示す。この図のＤａｔａフィールド１２は送信するデータを表し、前記データを除いた部分はＴＣＰヘッダと呼ばれ、このデータを扱うアプリケーションの特定、送信順序のコントロール、到達確認などに利用するデータを含んだフィールドを含んでいる。またＷｉｎｄｏｗフィールド１０は、送信側の受信可能なデータサイズを示している。
【００２８】
このＷｉｎｄｏｗフィールドは、本発明で言うウィンドウサイズに相当する。一般にこのフィールドには、そのパケットを送信したアプリケーションが、受信可能なバイト数がセットされ、その値は利用する媒体のＭＴＵとは無相関である。前記パケットを受信した端末は、返信用データとして前記ウィンドウサイズ以下のデータを用意する。
【００２９】
その他のフィールドの説明に関してはＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）発行のＲＦＣ７９３を参照すると良い。
【００３０】
図６にＩＰパケットの形式を示す。ＴＣＰ／ＩＰで通信を行う場合には、この図のＤａｔａフィールド１３の部分に図４のＴＣＰパケットが納められる。前記Ｄａｔａフィールド１２を除いた部分は、ＩＰヘッダと呼ばれ、送信元および送信先の端末のＩＰアドレスや、Ｄａｔａフィールドに含まれているデータのプロトコル、あるいはＩＰパケット全体のサイズなどを含んでいる。各フィールドの詳細はＩＥＴＦ発行のＲＦＣ７９１を参照すると良い。
【００３１】
図７はイーサネット（Ｒ）（Ｒ）で送受信されるパケット、すなわち、イーサネット（Ｒ）（Ｒ）フレームの形式を示している。Ｄａｔａフィールド１３には送信するデータが納められ、ＴＣＰ／ＩＰで利用するときには図５のＩＰパケットがこの部分に収納される。Ｄａｔａフィールド以前の部分は、イーサネット（Ｒ）（Ｒ）ヘッダと呼ばれ、送信先の端末のイーサネット（Ｒ）（Ｒ）アドレス、送信元の端末のイーサネット（Ｒ）（Ｒ）アドレス、データの種類が含まれ、Ｄａｔａフィールド以後の部分はイーサネット（Ｒ）（Ｒ）フレームの送信誤りを検出するためのチェックサムである。
【００３２】
図８にＩＥＥＥ１３９４のアシンクロナスパケットの形式を示す。ＩＥＥＥ１３９４を通信媒体としてＩＰパケットを送信するＩＰ  ｏｖｅｒ  １３９４を標準化したＲＦＣ２７３４では、ＩＰパケットを単一の端末に送信する場合（ＩＰＵｎｉｃａｓｔ）はアシンクロナスパケット（ブロックライトパケット）を利用することが推奨されている。Ｄａｔａフィールド１４には送信するデータが納められ、ＴＣＰ／ＩＰで利用するときには図５のＩＰパケットが、図８のカプセル化ヘッダ（後述）を伴って、この部分に収納される。Ｄａｔａフィールド以前の部分は、ＩＥＥＥ１３９４アシンクロナスパケットのヘッダで送信先の情報などを含んでいる。Ｄａｔａフィールド以後の部分は、Ｄａｔａフィールドの送信誤りを検出するための数値である。
【００３３】
図９はＩＰ  ｏｖｅｒ  １３９４で利用されるカプセル化ヘッダを示している。ＩＰパケットをＩＥＥＥ１３９４のパケットを用いて送信する場合は、このヘッダは図７のＤａｔａフィールドの先頭に格納され、それに続きＩＰパケットが納められる。カプセル化ヘッダはＩＰパケットの分割状態に応じて３種類あるが、ここでは分割されていないＩＰパケットが含まれていることを示すカプセル化ヘッダを示す。その他の形式に関してはＩＥＴＦ発行のＲＦＣ２７３４を参照すると良い。
【００３４】
図１０にＩＰ  ｏｖｅｒ  １３９４で利用されるＡＲＰパケット（１３９４ＡＲＰパケット）で利用されるデータの形式を示す。ＩＰ  ｏｖｅｒ  １３９４では、ＩＰパケットを送信するに先立ち、１３９４ＡＲＰパケットをブロードキャストして送信先の端末についての情報を収集する。特に、ｓｓｐｄフィールド１５は、転送可能な速度を表す数値がセットされる。
【００３５】
図１１及び図１２は、送信データからそれぞれイーサネット（Ｒ）（Ｒ）フレームとＩＥＥＥ１３９４パケットが構築されていく様子を示している。データに対し、順次ヘッダが加えられていくのは上記の説明の通りである。
【００３６】
一般にイーサネット（Ｒ）ではＭＴＵが１５００バイトとなっている。これは図１１の２１が示している部分が１５００バイト以下であると言うことである。つまり、ＴＣＰ／ＩＰで一度に送信できるデータサイズは、１５００バイトからＩＰヘッダとＴＣＰヘッダのサイズを引いた値である。
【００３７】
一方、ＩＥＥＥ１３９４では、一度に送信できるデータサイズはそのパケットの転送速度によって決まり、１００Ｍｂｐｓモードで５１２バイト、２００Ｍｂｐｓモードで１０２４バイト、４００Ｍｂｐｓモードで２０４８バイトの転送が可能である。すなわち、図１２の２８の示す部分が前記バイト数以下と言うことであり、ＴＣＰ／ＩＰで一度に送信できるデータサイズは、前記バイト数からＩＰヘッダ、ＴＣＰヘッダ、カプセル化ヘッダのサイズを引いた値である。
【００３８】
次に、フローチャートを用いて本発明の通信制御方法およびゲートウェイの動作の詳細を説明する。
【００３９】
図１は転送すべきパケットを受信した場合の、本発明の通信制御方法およびゲートウェイの動作の流れを示している。
【００４０】
ステップＦ１−１では、転送すべきパケットを受信する。転送すべきパケットとは、物理的なアドレス（例えば、イーサネット（Ｒ）（Ｒ）フレームの送信先イーサネット（Ｒ）（Ｒ）アドレスや、ＩＥＥＥ１３９４アシンクロナスパケットの送信先ノードＩＤ）が自分宛であるが、送信先ＩＰアドレスが自分宛でないようなパケットである。
【００４１】
ステップＦ１−２では、上記受信したパケットの送信先ＩＰアドレスから転送先の端末と、転送に利用するインターフェースを決定する。この作業は経路情報を記したルーティングテーブルと呼ばれる情報を参照することにより行われ、これは通常のゲートウェイの動作と同じである。
【００４２】
ステップＦ１−３では、上記パケットの送信元とゲートウェイ間の通信媒体のＭＴＵを調査する。
【００４３】
ステップＦ１−４では、上記ステップとは逆に、転送先（送信先）とゲートウェイ間の通信媒体のＭＴＵを調査する。
【００４４】
ステップＦ１−３およびＦ１−４のＭＴＵ調査は、通信媒体がイーサネット（Ｒ）（Ｒ）であれば固定値であるので直ちに求められ、ＩＥＥＥ１３９４であれば通信相手によりＭＴＵが異なるため、それまでの通信情報から得るか、１３９４ＡＲＰ（ＲＦＣ  ２７３４参照）により得る。また、バスマネージャのスピードマップも利用可能である。ここで調べた情報は、再び利用する可能性があるため保存しておくのが望ましいが、その場合には、ＩＥＥＥ１３９４のバスリセットを検出した場合は保存していた情報を破棄する必要がある（図３）。これはＩＥＥＥ１３９４のバスリセットは、ネットワークの構成が変化した場合などに発生するため、バスリセット前後でＭＴＵが変化している可能性があるためである。
【００４５】
ステップＦ１−５では、受信したパケットのヘッダを解析し、ウィンドウサイズを示すフィールドの値を読み取る。
【００４６】
ステップＦ１−６では、上記のステップＦ１−３とステップＦ１−４で調査したＭＴＵ値と、ステップＦ１−５で読み取ったウィンドウサイズの値を比較する。ステップＦ１−３とステップＦ１−４で調査したＭＴＵの値の最小値よりウィンドウサイズの方が大きい場合はステップＦ１−７へ、小さい場合はステップＦ１−９へ進む。
【００４７】
ステップＦ１−７では、上記パケットのヘッダのウィンドウサイズをステップＦ１−３とステップＦ１−４で調査したＭＴＵの値の最小値より小さい適当な値に書き換える。適当な値とは、ＭＴＵが小さい方の通信媒体で一度に遅れるデータサイズより小さければ良い。このことにより、このパケットに対する返信データは必然的に小さくなりフラグメンテーションが発生しなくなる。
【００４８】
ステップＦ１−８では、ヘッダやデータにチェックサムある場合は、Ｆ１−７でパケットの内容を変更したのでチェックサムを再計算して、整合性を持たせる。
【００４９】
ステップＦ１−９では、上記変更済のパケット、あるいは、変更する必要がなかったパケットを通常の手順で転送する。これは、通常のゲートウェイが行う作業と同一である。
【００５０】
図３には、ＩＥＥＥ１３９４のバスリセット等の通信媒体からの割り込みが発生した場合の処理の流れを示す。
【００５１】
ステップＦ３−１では、割り込みが生じたネットワークの、ステップＦ１−３あるいはステップＦ１−４で調査し保存したＭＴＵを破棄する。これは、割り込みの前後でネットワークの構成が変化し、ＭＴＵ情報とネットワークの構成が合わなくなる可能性があるためである。
【００５２】
ステップＦ３−２では、従来の割り込み処理を行う。例えば割り込みが生じたネットワークがＩＥＥＥ１３９４ならば、１３９４ＡＲＰ情報のクリアや、分割送受信中のパケットの破棄などである。
【００５３】
次に、ある端末がゲートウェイを介して接続された端末にリクエストを送信し、データを受信する場合の動作例を示し、本発明を実施した場合の効果を示す。本実施例では、リクエストする端末とゲートウェイ間は２００ＭｂｐｓのＩＥＥＥ１３９４で接続され、ゲートウェイとデータを返信する端末間はイーサネット（Ｒ）（Ｒ）で接続されているとする。また、リクエストに必要なデータサイズは１００バイト、返信するデータは２０００バイトとし、イーサネット（Ｒ）（Ｒ）のＭＴＵは１５００バイトとする。受信側の端末は十分大きな受信バッファを持っているため、リクエストを送信する際はウィンドウサイズを５０００バイトとして送信するとする。
【００５４】
図１４に、従来のゲートウェイを利用した場合の動作例を示す。この動作例は、端末２９がゲートウェイ３０を介して端末３１にデータをリクエストし、データを受信する際の動作概要を示している。
【００５５】
まず、端末２９はリクエストを送信する為にＩＥＥＥ１３９４パケット３２を用意し、ゲートウェイ３０に送信する。上記の仮定よりリクエストに必要なデータサイズは端末２９とゲートウェイ３０間のＭＴＵより小さいので一つのパケットとして送信される。
【００５６】
ゲートウェイ３０は上記ＩＥＥＥ１３９４パケット３２を受信（３３）し、転送するためにＩＥＥＥ１３９４ヘッダを取り除き、イーサネット（Ｒ）（Ｒ）ヘッダを付加してイーサネット（Ｒ）（Ｒ）フレーム３４を構成し、端末３１へ送信する。
【００５７】
端末３１は、イーサネット（Ｒ）フレーム３４を受信（３５）し、リクエストを受け取る。受け取ったリクエストに対し、返信する２０００バイトのデータ３６を用意する。端末３１とゲートウェイ３０間のイーサネット（Ｒ）のＭＴＵは１５００バイトであり、前記２０００バイトのデータは一度に送信できないので、複数に分割した後送信する。ここでは数値を簡単にするため、ＩＰヘッダなどのサイズを無視して、１５００バイトのパケット３７と５００バイトのパケット４４に分割して返信する。
【００５８】
ゲートウェイ３０は、上記パケット３７を受信（３８）し、転送するためにＩＥＥＥ１３９４パケットを構築するが、２００ＭｂｐｓのＩＥＥＥ１３９４のＭＴＵは１０２４バイトであるため、１５００バイトのパケットを送信することができない。そこで、複数に分割し、ＩＥＥＥ１３９４パケットとした後、送信する。ここでは数値を簡単にするため、ＩＰヘッダなどのサイズを無視して、１０００バイトのパケット３９と５００バイトのパケット４０に分割して返信する。
【００５９】
端末３０は、１０００バイトのパケット４１と５００バイトのパケット４２を受信し、これらのパケットのデータを組み合わせて１５００バイトのデータ４３を得る。この時点で、パケット３７が端末３１から端末２９に送信されたことになる。
【００６０】
さらに、ゲートウェイは、上記パケット４４を受信（４５）し、転送するためにＩＥＥＥ１３９４パケットを構築する。このパケットは５００バイトであり、分割せずに送信できるので単独のＩＥＥＥ１３９４パケット（４６）に変換され送信される。
【００６１】
端末２９は、上記パケット４６を受信（４７）し、そのデータと以前に得たデータ４３を組み合わせることにより、２０００バイトのデータ４８を得る。この時点で、端末３１が用意したデータ３６が全て送信できたことになる。
【００６２】
この動作に対し、図１３では、本発明を実施した場合の動作概要を示す。これは送受信するパケットが経由するゲートウェイが、本発明によるゲートウェイである他は同じ条件での動作概要である。
【００６３】
まず、図１４の場合と同様に、端末４９はリクエストを含んだパケット５２をゲートウェイ５０へ送信する。
【００６４】
ゲートウェイ５０は、上記パケット受信（５３）し、図１のフローチャートに従い処理をする。具体的には、端末４９とゲートウェイ５０間のＭＴＵが１０２４バイトであるので、パケット５３のウィンドウサイズを書き換えた後、イーサネット（Ｒ）フレーム５４に変換する。ここでは、書き換え後のウィンドウサイズは１０００バイトであるとする。
【００６５】
端末５０は、イーサネット（Ｒ）フレーム５４を受信（５５）し、リクエストを受け取る。受け取ったリクエストに対し、返信する２０００バイトのデータ５６を用意する。端末５１とゲートウェイ５０間のイーサネット（Ｒ）のＭＴＵは１５００バイトであるが、受信したリクエスト５５に含まれているウィンドウサイズが１０００バイトであるため、前記２０００バイトのデータは一度に送信できないので、複数に分割した後送信する。ここでは、数値を簡単にするため、ＩＰヘッダなどのサイズを無視して１０００バイトのパケット５７とパケット６１に分割して返信する。
【００６６】
ゲートウェイ５０は、上記パケット５７を受信（５８）し、転送するためにＩＥＥＥ１３９４パケットを構築する。このパケットは１０００バイトであり、２００ＭｂｐｓのＩＥＥＥ１３９４のＭＴＵより小さいので、分割されることなくＩＥＥＥ１３９４パケット５９に変換され送信される。
【００６７】
端末４８は、上記パケット５９を受信（６０）し、パケット５６が端末５０から端末４８に送信されたことになる。
【００６８】
さらに、ゲートウェイは、上記パケット６１を受信（６２）し、転送するためにＩＥＥＥ１３９４パケットを構築する。このパケットも１０００バイトであり、２００ＭｂｐｓのＩＥＥＥ１３９４のＭＴＵより小さいので、分割されることなくＩＥＥＥ１３９４パケット６３に変換され送信される。
【００６９】
端末４８は、上記パケット６３を受信（６４）し、そのデータと以前に受信したデータを組み合わせることにより、２０００バイトのデータ６６を得る。この時点で、端末５０が用意したデータ５５が全て送信できたことになる。
【００７０】
図１３と図１４を比較すると、ゲートウェイでのパケットのフラグメンテーションが抑制されており、本発明が効果的に機能していることが分かる。
【００７１】
（第二の実施例）
図２は転送すべきパケットを受信した場合の、本発明の通信制御方法およびゲートウェイの動作の流れを示している。図２とはウィンドウサイズ修正の条件が異なっている。
【００７２】
ステップＦ２−１からステップＦ２−４まではそれぞれステップＦ１−１からステップＦ１−４と同じである。
【００７３】
ステップＦ２−５では、ステップＦ２−３とステップＦ２−４で調査したＭＴＵの値を比較し、ステップＦ２−３で得た値（送信元とのＭＴＵ）が小さい場合は、ステップＦ２−６へ進み、それ以外の場合はウィンドウサイズの修正は行わず、ステップＦ２−１０へ進みパケットの転送を行う。
【００７４】
これは、転送先とのＭＴＵが小さい場合には、返信されてくるパケットはＭＴＵの小さい経路を通るので事前に小さいパケットとして返信されてくるため、ウィンドウサイズを修正して返信されてくるパケットサイズを縮小する必要がないためである。
【００７５】
転送先のＭＴＵが転送元のＭＴＵより大きい場合は、第一の実施例と同様にウィンドウサイズの修正を行わなければならない。
【００７６】
また、ＩＥＥＥ１３９４のバスリセットの様な通信媒体からの割り込みが発生した場合は、第一の実施例と同様に、図３の処理を行う。
【００７７】
【発明の効果】
以上説明したように、本出願に係る第一の発明によれば、ネットワーク間を接続するゲートウェイにおいて、前記ゲートウェイを介して点おうされるパケットが、転送元のネットワークと転送先のネットワークのＭＴＵに差があることによって生じるＭＴＵを低減できるという効果がある。
【００７８】
同時に、ＩＥＥＥ１３９４のバスリセットなどの、ネットワークからのＭＴＵが変化する可能性がある割り込みに応じた処理を行うことにより、ＭＴＵが動的に変化するネットワークを利用する場合においても上記効果は有効である。
【００７９】
また、本出願の発明によれば、ネットワークに接続されている各端末は、何ら特別な装置あるいは処理を付加しなくとも、本発明のゲートウェイ、通信制御方法、および、記録媒体は上記効果を生じる。
【図面の簡単な説明】
【図１】本発明の処理の例を表すフローチャートである。
【図２】本発明の処理の例を表す別のフローチャートである。
【図３】割り込み処理の場合のフローチャートである。
【図４】ネットワークの接続形態の例である。
【図５】ＴＣＰパケットの構成を示す図である。
【図６】ＩＰパケットの構成を示す図である。
【図７】イーサネット（Ｒ）フレームの構成を表す図である。
【図８】ＩＥＥＥ１３９４アシンクロナスパケットの構成を表す図である。
【図９】ＩＰ  ｏｖｅｒ  １３９４で利用されるカプセル化ヘッダの構成を表す図である。
【図１０】ＩＰ  ｏｖｅｒ  １３９４で利用される１３９４ＡＲＰパケットの構成を表す図である。
【図１１】イーサネット（Ｒ）フレームが構築される様子を表す図である。
【図１２】ＩＥＥＥ１３９４アシンクロナスパケットが構築される様子を表す図である。
【図１３】本発明のゲートウェイを用いた場合の動作例である。
【図１４】従来のゲートウェイを用いた場合の動作例である。
【符号の説明】
１  本発明のゲートウェイである。
２  本発明のゲートウェイと接続されているネットワークである。
３〜５  ネットワーク２に接続されている端末である。
６  本発明のゲートウェイと接続されているネットワークである。
７〜９  ネットワーク６に接続されている端末である。
１０  ＴＣＰヘッダのウィンドウフィールドである。
１１  ＩＰヘッダのパケット長を表すフィールドである。
１３  ＩＥＥＥ１３９４アシンクロナスヘッダのデータサイズを表すフィールドである。
１４  最大転送速度がセットされる１３９４ＡＲＰパケットのフィールドである。
１５  送信するデータである。
１６  ＴＣＰヘッダである。
１７  ＩＰヘッダである。
１８  イーサネット（Ｒ）ヘッダである。
１９  ＭＴＵ以下でならなければならない範囲である。
２０  イーサネット（Ｒ）のチェックサムである。
２１  信するデータである。
２２  ＴＣＰヘッダである。
２３  ＩＰヘッダである。
２４  ＩＰ  ｏｖｅｒ  １３９４のカプセルかヘッダである。
２５  ＩＥＥＥ１３９４アシンクロナスヘッダである。
２６  データ部分のチェックサムである。
２７  ＭＴＵ以下でならなければならない範囲である。
２８  リクエストを発しデータを受信する端末である。
２９  従来のゲートウェイである。
３０  リクエストを受けデータを返信する端末である。
３１〜３２  リクエストのＩＥＥＥ１３９４パケットである。
３３〜３４  リクエストのイーサネット（Ｒ）フレームである。
３５  返信するデータである。
３６〜３７  返信データを分割してできたイーサネット（Ｒ）フレームである。
３８〜４１  ３７のデータをさらに分割してできたＩＥＥＥ１３９４パケットである。
４２  ４０と４１から再構築されたデータである。
４３〜４４  返信データを分割してできたイーサネット（Ｒ）フレームである。
４５〜４６  ４４を変換したＩＥＥＥ１３９４パケットである。
４７  ４２と４６から再構築されたデータで３５と等しいデータである。
４８  リクエストを発しデータを受信する端末である。
４９  本発明のゲートウェイである。
５０  リクエストを受けデータを返信する端末である。
５１〜５２  リクエストのＩＥＥＥ１３９４パケットである。
５３〜５４  リクエストのイーサネット（Ｒ）フレームである。
５５  返信するデータである。
５６〜５７  返信データを分割してできたイーサネット（Ｒ）フレームである。
５８〜５９  ５７を変換したＩＥＥＥ１３９４パケットである。
６１〜６２  返信データを分割してできたイーサネット（Ｒ）フレームである。
６３〜６４  ６２を変換したＩＥＥＥ１３９４パケットである。
６６  ６０と６４から再構築されたデータで６６と等しいデータである。
【図１】
2004328220.tif 000003
【図２】
2004328220.tif 000004
【図３】
2004328220.tif 000005
【図４】
2004328220.tif 000006
【図５】
2004328220.tif 000007
【図６】
2004328220.tif 000008
【図７】
2004328220.tif 000009
【図８】
2004328220.tif 000010
【図９】
2004328220.tif 000011
【図１０】
2004328220.tif 000012
【図１１】
2004328220.tif 000013
【図１２】
2004328220.tif 000014
【図１３】
2004328220.tif 000015
【図１４】
2004328220.tif 000016