(57)【特許請求の範囲】
【請求項１】
第一の端末に対する第一のネットワークインターフェースと第二の端末に対する第二のネットワークインターフェースとの間でレイヤー２のフレームを転送するブリッジ装置において、
前記第一の端末のレイヤー３のアドレスと前記第二の端末のレイヤー３のアドレスとを対応付けて記憶するアドレス記憶手段と、
前記第一のネットワークインターフェースの最大転送ユニット（ＭＴＵ）の値又は前記第二のネットワークインターフェースの最大転送ユニット（ＭＴＵ）の値のいずれかに変更が生じたことを検出するＭＴＵ変更検出手段と、
前記変更が検出されたネットワークインターフェースに対してレイヤー２のフレームを送信した端末を前記アドレス記憶手段から特定し、該端末に対して変更後の最大転送ユニットよりも大きなサイズを有するＩＣＭＰエコー要求パケットを送信するＩＣＭＰ送信手段と、
前記ＩＣＭＰエコー要求に対するＩＣＭＰエコー応答パケットを受信するＩＣＭＰ受信手段と、を具備し、
前記ＩＣＭＰ送信手段は、前記ＩＣＭＰエコー応答パケットに応じてＩＣＭＰパケットを送信するブリッジ装置。
【請求項２】
前記第一のネットワークインターフェースの最大転送ユニットの値および前記第二のネットワークインターフェースの最大転送ユニットの値をそれぞれ記憶するＭＴＵ記憶手段と、
前記ＭＴＵ変更検出手段によりＭＴＵの値の変更を検出したら、該ＭＴＵの変更後の値により前記ＭＴＵ記憶手段を更新するＭＴＵ更新手段とをさらに具備する請求項１に記載のブリッジ装置。
【請求項３】
第一の端末に対する第一のネットワークインターフェースと第二の端末に対する第二のネットワークインターフェースとの間でレイヤー２のフレームを転送するブリッジ装置の作動方法において、
前記第一の端末のレイヤー３のアドレスと前記第二の端末のレイヤー３のアドレスとを対応付けてアドレス記憶手段に記憶するステップと、
前記第一のネットワークインターフェースの最大転送ユニット（ＭＴＵ）の値又は前記第二のネットワークインターフェースの最大転送ユニット（ＭＴＵ）の値のいずれかに変更が生じたことを検出するステップと、
前記変更が検出されたネットワークインターフェースに対してレイヤー２のフレームを送信した端末を前記アドレス記憶手段から特定し、該端末に対して変更後の最大転送ユニットよりも大きなサイズを有するＩＣＭＰエコー要求パケットを送信するステップと、
前記ＩＣＭＰエコー要求に対するＩＣＭＰエコー応答パケットを受信するステップと、
前記ＩＣＭＰエコー応答パケットに応じて前記ＩＣＭＰパケットを送信するステップと、
を具備するブリッジ装置の作動方法。
【請求項４】
前記第一のネットワークインターフェースの最大転送ユニットの値および前記第二のネットワークインターフェースの最大転送ユニットの値をそれぞれＭＴＵ記憶手段に記憶するステップと、
前記ＭＴＵの値の変更を検出したら、該ＭＴＵの変更後の値により前記ＭＴＵ記憶手段を更新するステップとをさらに具備する請求項３に記載のブリッジ装置の作動方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰネットワークに適用されるブリッジ装置及びブリッジ装置の制御方法に関する。
【背景技術】
【０００２】
パケットの送受信によるエンド・ツー・エンド（End-to-End）型の通信を行うインターネットプロトコル（Internet Protocol）では、通信を行っている両端の端末で扱えるパケットサイズは基本的には自由（ただし最大サイズは６５５３５）である。しかし、ＩＰパケットはイーサネット（登録商標）やＰＰＰ（Point-to-Point Protocol）といったデータリンク層の上で交換されることから、必然的に、パケットのサイズをデータリンク層で送信可能なサイズの最大数に合わせておくことがもっとも効率よい転送であるといえる。このパケットのサイズのことをＭＴＵ（Maximum Transfer Unit;最大転送ユニット）という。
【０００３】
通常、イーサネットの場合においてＭＴＵの値は１５００であり、ＩＰ通信を行う場合はこのＭＴＵ１５００で通信が行われる。例えば、イーサネットで接続されたＬＡＮであれば、どの端末もＭＴＵ１５００で通信することがもっとも効率のよい状態である。なお、この１５００という値は通常は変わらないので、イーサネットを延長するために用いられるブリッジやスイッチングハブといった機器はＭＴＵについて特に処理をしない。ＭＴＵを超えるサイズのＩＰパケットはＩＰ層でフラグメント処理されるが、ブリッジやハブといった機器はＩＰの処理を行う機器ではないので、これらの機器が処理可能なサイズ以上のパケットは廃棄されることになる。
【０００４】
宅内やＳＯＨＯ(Small Office Home Office)ならびに一般のオフィスにおけるネットワーク環境の充実と、ブロードバンドネットワーク、公衆の無線インターネット接続のインフラの普及に伴い、外出先から安全にインターネットを通じて、これら宅内やＳＯＨＯならびにオフィスに接続したいという要求が高まっている。通常、ＭＴＵは一律に揃っていることを仮定してもよいが、遠隔のネットワークと同じＩＰセグメントで通信を行うためにトンネリングを行うような場合、ＭＴＵは変わる可能性がある。「トンネリング」とは、一般に、ＩＰパケット（又はイーサネットフレームなど）をさらに別のＩＰパケットに包んで転送する技術の総称であり、Ｌ３ＶＰＮ(Layer 3 Virtual Private Network)，Ｌ２ＶＰＮ(Layer 2 Virtual Private Network)といった技術が知られる。Ｌ２ＶＰＮについては、より具体的な技術としてＬ２ＴＰ(Layer 2 Tunneling Protocol)，ＭＰＬＳ(Multi Protocol Label Switching)などがある。
【０００５】
キャリアがオフィス向けに（遠隔のオフィス間などを接続するために）提供するＬ２ＶＰＮ，Ｌ３ＶＰＮを用いたサービスでは、キャリア側でＭＴＵを一定するような運用が一応はなされてはいるものの、ＭＴＵに関して次のような問題点がある。
【０００６】
Ｌ２ＶＰＮ，Ｌ３ＶＰＮを実現するには、ＩＰパケットのペイロード部分にトンネルしたいものを包めば良いのであるが、包み方については様々なフォーマットが考えられる。そのフォーマットによってＭＴＵが変わることがある。例えばＩＰｓｅｃというＩＰの通信路を暗号化する仕組みを適用することによって、ＭＴＵは変わる可能性がある。ＭＴＵの値を幾つに合わせれば良いかは一概には定めることができず、そのための指針も存在しない。
【０００７】
このようなＭＴＵの問題を解決するために、従来、以下の二つの方法が考えられている。
【０００８】
（１）ＭＴＵが変わったことを隠すという方法
例えばＳｏｆｔＥｔｈｅｒと呼ばれるソフトウェアが知られている（下記非特許文献１参照）。このソフトウェアは、ＭＴＵを超えるパケットをすべてフラグメント処理するものであり、他の端末にＭＴＵを意識させない代わりに性能を犠牲にしている。
【０００９】
（２）ＭＴＵが変わったことを通知するという方法
この方法のメリットは、フラグメント処理をしないことである（例えば、非特許文献２参照）。フラグメント処理には、送信パケット量の増大、処理負担の増大、パケットが消失したときの処理負担（廃棄するのか、どのくらい待つのかなどを判定する処理）といったデメリットが多いからである。
【非特許文献１】インターネット＜URL:http://www.softether.com/jp/overview/typeoflan.aspx＞
【非特許文献２】Kent, C. and J. Mogul, "Fragmentation considered harmful", Proc. SIGCOMM '87 vol. 17, No. 5, October 1987.，＜インターネット＜URL:http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf＞
【発明の開示】
【発明が解決しようとする課題】
【００１０】
例えば遠隔の機器から宅内の機器に対しＶＰＮを構成して接続する場合に、上述したようにＭＴＵが変化することがある。
【００１１】
具体的には、経路の状況変化に応じてトンネルが作り直され、そのＭＴＵが動的に変化する。この場合、ブリッジ装置により仮想的に延長されたセグメントにおいて、一方の物理的なセグメントと、ブリッジ装置を介した他方の物理的なセグメントとの間でＭＴＵの値が一致しなくなる場合が起こり得る。宅内のＬＡＮに接続される機器（通常、パーソナルコンピュータ、ネット家電機器、ブロードバンドルータ等が想定される）のすべてにおいてＭＴＵが同一でなければ、それぞれの機器で正常な通信ができないことから、ＶＰＮが再構成されたことに伴い変更されたＭＴＵは何らかの方法で各機器に通知される必要がある。
【００１２】
ここで、ＭＴＵの変更のたびに、関係するすべての機器間においてＭＴＵの値が同一となるよう、例えば手動で変更することが自明の策として考えられる。また、ＭＴＵの変更を示す情報をネットワーク内で伝播させる独自のプロトコルを定義し運用してもよい。
【００１３】
しかしながら、組み込み機器なども含め多数にのぼる機器のすべてについて上記のような作業を実施することは事実上困難である。また、独自のプロトコルを定義して運用する場合についても、多岐にわたる機器ベンダーがこれに対応することは事実上困難である。
【００１４】
本発明は、汎用性を損なうことなくＭＴＵの動的な変更に対応することのできるブリッジ装置及びブリッジ装置の制御方法を提供することを目的とする。
【課題を解決するための手段】
【００１５】
本発明の一観点に係るブリッジ装置は、第一の端末に対する第一のネットワークインターフェースと第二の端末に対する第二のネットワークインターフェースとの間でレイヤー２のフレームを転送するブリッジ装置において、前記第一の端末のレイヤー３のアドレスと前記第二の端末のレイヤー３のアドレスとを対応付けて記憶するアドレス記憶手段と、前記第一のネットワークインターフェースの最大転送ユニット（ＭＴＵ）の値又は前記第二のネットワークインターフェースの最大転送ユニット（ＭＴＵ）の値のいずれかに変更が生じたことを検出するＭＴＵ変更検出手段と、前記変更が検出されたネットワークインターフェースに対してレイヤー２のフレームを送信した端末を前記アドレス保持手段から特定し、該端末に対してＩＣＭＰエラーパケットを送信するＩＣＭＰ送信手段とを具備する。
【発明の効果】
【００１６】
本発明によれば、汎用性を損なうことなくＭＴＵの動的な変更に対応することのできるブリッジ装置及びブリッジ装置の制御方法を提供できる。
【発明を実施するための最良の形態】
【００１７】
以下、図面を参照しながら本発明の実施形態を説明する。
【００１８】
図１は本発明の実施形態に係るブリッジ装置が適用されたネットワークを示す図である。同図に示すように、端末Ａに対しブリッジ装置１を介して端末Ｂ〜端末Ｅが接続されている。
【００１９】
ブリッジ装置１は、端末Ａから端末Ｂ〜端末Ｅのいずれかに対して送信されたフレームを転送処理し、あるいは逆に、端末Ｂ〜端末Ｅのいずれかから端末Ａに対して送信されたフレームを転送処理する。このようなブリッジとしての基本機能を実現するため、ブリッジ装置１はＭＡＣアドレス学習部２と、Ｌ２ブリッジフレーム転送処理部３とを有する。
【００２０】
ＭＡＣアドレス学習部２は、例えばＩＥＥＥ８０２．１Ｄの仕様に基づいたＭＡＣアドレス学習を行う。Ｌ２ブリッジフレーム転送処理部３は、ＩＥＥＥ８０２．１Ｄの仕様に基づいたブリッジフォワーディング処理を行う。また、本実施形態に係るブリッジ装置１は、次に説明する機能拡張部分に対する問い合わせも行う。
【００２１】
図２は、図１に示したブリッジ装置における機能拡張部分を示すブロック図である。同図に示すように、本発明の実施形態に係るブリッジ装置１は、図１に示した構成要素に加え、ＭＴＵ判定部４０と、ＩＣＭＰ処理部５０と、ＭＴＵ保持部６と、ＩＰ送信元・宛先保持部７とを備える。ＭＴＵ判定部４０は、ＭＴＵ変更検出部４１と、ＭＴＵ更新部４２とを備える。
【００２２】
ＭＴＵ判定部４０は、ＭＡＣアドレス学習部２によりＩＥＥＥ８０２．１Ｄの仕様に基づいたＭＡＣアドレスの学習がなされる際に、同時に、当該ネットワークに接続された機器に対応するネットワークインターフェースごとのＭＴＵの値を取得し、ＭＴＵ保持部６に記憶させる。ＭＴＵの値をいかにして取得するかについて本発明は特定の手法に限定されるものではないが、例えば、ＭＴＵ判定部４０のＭＴＵ変更検出部４１がＩＣＭＰ処理部５０内のＭＴＵ値取得部５１に対してＭＴＵの値の取得を指示する。これに応じてＭＴＵ値取得部５１は例えばＩＣＭＰに基づくパスＭＴＵ検出（path MTU discovery）機能によりネットワーク内の各機器のＭＴＵの値を取得する。
【００２３】
ＭＴＵ変更検出部４１は、ＭＴＵ値取得部５１を通じてＭＴＵの値が取得されると、以前に取得され、ＭＴＵ保持部６に既に記憶されているＭＴＵの値と比較することにより、ＭＴＵの値に変更が生じたか否かを検出する。ＭＴＵ更新部４２は、ＭＴＵの値に変更が生じたことがＭＴＵ変更検出部４１により検出されたことを受けて、ＭＴＵ保持部６が保持するＭＴＵの値を更新する。
【００２４】
Ｌ２ブリッジフレーム転送処理部３は、このＭＴＵ保持部６が保持しているＭＴＵの値を参照し、転送しようとしているフレームのサイズと比較することにより、当該フレームを転送すべきか、それともＩＣＭＰ／フラグメント処理をすべきかの判断をする。
【００２５】
ＩＣＭＰ処理部５０のＭＴＵ値取得部５１は、上述したパスＭＴＵ検出機能を実装している。ＩＣＭＰのパスＭＴＵ検出については、ＩＰｖ４ではＲＦＣ１１９１に定義され、ＩＰｖ６ではＲＦＣ１９８１に定義されている。概略手順としては、ＩＰパケットにＤＦフラグ（フラグメント禁止フラグ）をセットし、ＭＴＵサイズを様々に変化させて該ＩＰパケットを送信する。これに応じて返答されてくるＩＣＭＰ宛先不達（ICMP destination unreachable）メッセージを受信し、該メッセージにセットされているＭＴＵ値を得る。
【００２６】
ＩＣＭＰ処理部５０のＩＣＭＰメッセージ送信部５２は、転送先のネットワークインターフェースのＭＴＵの値が、転送しようとしているフレームよりも小さい場合に、該転送しようとしているフレームの転送元に対してＩＣＭＰメッセージを送信する。
【００２７】
また、ＩＣＭＰ処理部５０のＩＣＭＰメッセージ送信部５２は、ＭＴＵ判定部４０によりＭＴＵの変更が検出されると、後述する幾つかの手順のいずれかに従い、ＩＣＭＰパケットをフレームの送信元に対して送信する。ＩＰ送信元・宛先保持部７は、当該ブリッジ装置１が転送を行うフレームの送信元ＩＰアドレス（レイヤー３アドレス）と宛先ＩＰアドレスとを対応付けて記憶している。ＩＣＭＰメッセージ送信部５２は、ＭＴＵの値に変更が生じたネットワークインターフェースに対して以前に転送を行ったことがある送信元のＩＰアドレスの一覧をＩＰ送信元・宛先保持部７から求める。このＩＰアドレスの一覧に記載された機器に対し、ブリッジ装置１から、ＭＴＵの変更を通知するためのＩＣＭＰパケットを送信する。
【００２８】
以上のように構成されたブリッジ装置は、ネットワークにおいてＭＴＵの値が動的に変更される場合に好適である。
【００２９】
ここで、ＭＴＵの動的な変更について説明する。
【００３０】
図１のネットワークにおいて、レイヤー２（Ｌ２）をレイヤー３（Ｌ３）でカプセル化し、これによりレイヤー２をエミュレートする場合を考える。図３は、Ｌ２のエミュレートを行う場合のパケットフォーマットを示している。Ｌ２のエミュレートを行う場合、カプセル化のためのヘッダ分Ｈだけ最大ペイロードＰは削減され、レイヤー２のＭＴＵが削減されることになる。このようにエミュレートされたレイヤー２をＩＥＥＥ８０２．１Ｄに基づいてブリッジする際には、ブリッジ装置１はＭＴＵが違うことを意識しなければならない。例えばＭＴＵ１５００とＭＴＵ１４５４との間のＬ２ブリッジを考える。ＭＴＵ１４５５以上のフレームはＬ２ブリッジではフォワードされず破棄される。このとき、フレームが破棄されたことはレイヤー３には通知されない。
【００３１】
レイヤー２をエミュレートしたネットワークインターフェースのブリッジについてＭＴＵの観点から述べると、レイヤー３でレイヤー２をエミュレートする場合、エミュレートされたレイヤー２のＭＴＵはレイヤー３を運ぶレイヤー２のＭＴＵに依存して変化する可能性がある。例えば図４に示すように、ユーザからみたレイヤー２のうち、エミュレートされたレイヤー２は実際にはインターネット上での経路の変化などにより、そのＭＴＵが変ってしまう可能性がある。
【００３２】
図５はこれをより詳しく示したものである。図５に示すように、レイヤー２をエミュレートしているレイヤー３を運ぶレイヤー２のＭＴＵの変化により、エミュレートされているレイヤー２のＭＴＵも影響を受ける可能性がある。また、レイヤー２ブリッジの管理者が、エミュレートしているレイヤー２のＭＴＵを変更することも（レイヤー３を運ぶレイヤー２のＭＴＵの値と矛盾しない限り）可能である。
【００３３】
このようなＭＴＵの動的に変更に対し、本実施形態のブリッジ装置１は以下の手順例１又は２を実行するよう構成されており、汎用性を損なうことなく対応することができる。
【００３４】
（手順例１）
図６は本実施形態のブリッジ装置によるＭＴＵ判定処理の手順例１を示すフローチャートである。この手順例１は、エミュレートするＬ２のＭＴＵが変更された際にＩＣＭＰエラーパケットを送信するというものである。
【００３５】
まず、エミュレートしているＬ２のＭＴＵの値がＭＴＵ値取得部５１により取得される（ステップＳ１）。ここで、ＭＴＵ変更検出部４１によりＭＴＵの変更が検出され、具体的には、現在のＭＴＵの値が以前の値よりも小さくなったか否かが判定される（ステップＳ２）。現在のＭＴＵの値が以前の値よりも小さくなった場合、ＩＣＭＰ処理部５０は、当該Ｌ２を使用して最近通信が行われたか否かをＩＰ送信元・宛先保持部７を参照することにより判定する（ステップＳ３）。具体的には、ＭＴＵの変更されたネットワークインターフェースに対してかつて転送を行ったことがあるＩＰアドレスの一覧をＩＣＭＰメッセージ送信部５２がＩＰ送信元・宛先保持部７から取得する。
【００３６】
ＩＣＭＰメッセージ送信部５２は、ＩＰ送信元・宛先保持部７から取得したＩＰアドレスの一覧に記載の送信元に対し、プロトコルの種別に応じてＩＣＭＰエラーパケット（ICMP error）を送信する。例えばＩＰアドレスの一覧に記載のある送信元がＩＰｖ６を用いている場合、この送信元に対してＩＣＭＰｖ６エラー（Too Big）パケットを送信する（ステップＳ４）。あるいは、ＩＰアドレスの一覧に記載のある送信元がＩＰｖ４を用いている場合、この送信元に対してＩＣＭＰｖ４エラー（Fragment Needed）パケットを送信する（ステップＳ５）。
【００３７】
通知を受けた送信元では、ＩＣＭＰエラーパケットのレイヤー３の処理によって再送等の判定を行うことができる。
【００３８】
（手順例２）
図７は本実施形態のブリッジ装置によるＭＴＵ判定処理の手順例２を示すフローチャートである。この手順例２は、エミュレートするＬ２のＭＴＵが変更された際にＩＣＭＰエコー要求パケットを送るというものである。
【００３９】
まず、エミュレートしているＬ２のＭＴＵの値がＭＴＵ値取得部５１により取得される（ステップＳ２１）。ここで、ＭＴＵ変更検出部４１によりＭＴＵの変更が検出され、具体的には、現在のＭＴＵの値が以前の値よりも小さくなったか否かが判定される（ステップＳ２２）。現在のＭＴＵの値が以前の値よりも小さくなった場合、ＩＣＭＰ処理部５０は、当該Ｌ２を使用して最近通信が行われたか否かをＩＰ送信元・宛先保持部７を参照することにより判定する（ステップＳ２３）。具体的には、ＭＴＵの変更されたネットワークインターフェースに対してかつて転送を行ったことがあるＩＰアドレスの一覧をＩＣＭＰメッセージ送信部５２がＩＰ送信元・宛先保持部７から取得する。
【００４０】
ＩＣＭＰメッセージ送信部５２は、ＩＰ送信元・宛先保持部７から取得したＩＰアドレスの一覧に記載の送信元に対し、プロトコルの種別に応じてＩＣＭＰエコー要求パケット（ICMP echo request）を送信する。このＩＣＭＰエコー要求パケットは、変更されたＭＴＵよりもサイズが大きいものとする。
【００４１】
例えばＩＰアドレスの一覧に記載のある送信元がＩＰｖ６を用いている場合、この送信元に対して、変更されたＭＴＵよりもサイズが大きいＩＣＭＰｖ６のエコー要求パケットを送信する（ステップＳ２４）。あるいは、ＩＰアドレスの一覧に記載のある送信元がＩＰｖ４を用いている場合、この送信元に対して、ＩＣＭＰｖ６のエコー要求パケットを送信する（ステップＳ２５）。
【００４２】
この結果、ＩＣＭＰエコー要求パケットを受信した端末から同じ大きさのＩＣＭＰエコー応答パケット（ICMP echo reply）が返信される。このＩＣＭＰエコー応答パケットは、Ｌ２ブリッジフレーム転送処理部３を経てＩＣＭＰ処理部５０により処理され、最終的にはＩＣＭＰエラーパケットが送信されることになる。
【００４３】
以上説明した本発明の実施形態によれば、ＩＣＭＰを利用していることから汎用性を損なうことなく、ＭＴＵの動的な変更に対応することができるようになる。なお、ＭＴＵの値が動的に変化する場合として、図８に示すような場合も考えられる。これは、ＩＳＰ（インターネットサービスプロバイダ）Ｂを通る経路から、例えば何らかの障害により、ＩＳＰＡを通る経路へパケットの経路が変わり、その結果、Ｌ２ＶＰＮのトンネルが再構築され、該Ｌ２ＶＰＮのトンネルのＭＴＵが変化する場合である。変更されたＭＴＵは、上述した実施形態の仕組みにより宅内・オフィスネットワークに通知することができる。
【００４４】
また、手作業でＭＴＵを変えてしまうようなオペレーションが発生した場合、ネットワーク管理者等にＭＴＵの変更の旨を通知することも好ましい。
【００４５】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【図面の簡単な説明】
【００４６】
【図１】本発明の実施形態に係るブリッジ装置が適用されたネットワークを示す図
【図２】本発明の実施形態に係るブリッジ装置の主要部を示すブロック図
【図３】Ｌ２のエミュレートを行う場合のパケットフォーマットの一例を示す図
【図４】エミュレートされたレイヤー２のＭＴＵを示す図
【図５】エミュレートされたレイヤー２のＭＴＵを詳細に示す図
【図６】ＭＴＵに変更が生じた際の手順例１を示すフローチャート
【図７】ＭＴＵに変更が生じた際の手順例２を示すフローチャート
【図８】Ｌ２ＶＰＮ接続を行う際のＭＴＵが変化する場合を示す図
【符号の説明】
【００４７】
１…ブリッジ装置（Ｌ２ブリッジ）；
２…ＭＡＣアドレス学習部；
３…Ｌ２ブリッジフレーム転送処理部；
４０…ＭＴＵ判定部；
４１…ＭＴＵ変更検出部；
４２…ＭＴＵ更新部；
５０…ＩＣＭＰ処理部；
５１…ＭＴＵ値取得部；
５２…ＩＣＭＰメッセージ送信部；
６…ＭＴＵ保持部；
７…ＩＰ送信元・宛先保持部
【図１】
0004776330.tif 000002
【図２】
0004776330.tif 000003
【図３】
0004776330.tif 000004
【図４】
0004776330.tif 000005
【図５】
0004776330.tif 000006
【図６】
0004776330.tif 000007
【図７】
0004776330.tif 000008
【図８】
0004776330.tif 000009