(57)【特許請求の範囲】
【請求項１】
レイヤ２ネットワークのホスト間の通信をレイヤ３ネットワークにオーバーレイする通信装置であって、
前記通信装置は、レイヤ３ネットワークにおける複数の通信経路について、前記通信経路毎の第１のＭＴＵ長を管理するＭＴＵ管理情報を保持し、前記複数の通信経路はそれぞれＩＰアドレスによって示され、
前記通信装置は、前記レイヤ２ネットワークのホスト間の通信を前記複数の通信経路を介してオーバーレイする場合に付加する情報に基づき第２のＭＴＵ長を求め、
前記通信装置は、前記ＭＴＵ管理情報を参照して、前記ホストから受信したパケットの宛先ＭＡＣアドレスに対応する宛先ＩＰアドレスに関連付けられている第１のＭＴＵ長を決定し、
前記通信装置は、前記パケットに前記付加する情報を付加後のパケット長が前記宛先ＩＰアドレスに関連付けられている第１のＭＴＵ長を超えていた場合に、前記パケットを送信してきたホストに対し、前記パケットの宛先ＩＰアドレスを送信元ＩＰアドレスに、前記パケットの送信元ＩＰアドレスを宛先ＩＰアドレスにそれぞれ設定したメッセージによって、前記第２のＭＴＵ長を前記ホストに通知することを特徴とする通信装置。
【請求項２】
請求項１に記載の通信装置であって、
前記メッセージは、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ  Ｐｒｏｔｏｃｏｌ）のフォーマットに基づいて作成したメッセージであることを特徴とする通信装置。
【請求項３】
請求項１又は２に記載の通信装置であって、
前記第２のＭＴＵ長は、前記第１のＭＴＵ長から、前記付加する情報を減算した値であることを特徴とする通信装置。
【請求項４】
請求項１、２又は３に記載の通信装置であって、
前記通信装置は、前記レイヤ３ネットワークを介して前記第１のＭＴＵ長に関する情報を受信すると、前記第１のＭＴＵ長を更新することを特徴とする通信装置。
【請求項５】
請求項１、２又は３に記載の通信装置であって、
前記第１のＭＴＵ長は、予め設定された値であることを特徴とする通信装置。
【請求項６】
レイヤ２ネットワークのホスト間の通信をレイヤ３ネットワークにオーバーレイする通信方法であって、
ＭＴＵ管理情報を参照して、前記ホストから受信したパケットの宛先ＭＡＣアドレスに対応する宛先ＩＰアドレスに関連付けられている第１のＭＴＵ長を決定し、
前記ＭＴＵ管理情報は、レイヤ３ネットワークにおける複数の通信経路について、前記通信経路毎の第１のＭＴＵ長を管理し、前記複数の通信経路はそれぞれＩＰアドレスによって示され、
前記レイヤ２ネットワークのホスト間の通信を前記複数の通信経路を介してオーバーレイする場合に付加する情報に基づき前記パケットの第２のＭＴＵ長を求め、
前記パケットに前記付加する情報を付加後のパケット長が前記宛先ＩＰアドレスに関連付けられている第１のＭＴＵ長を超えていた場合に、前記パケットを送信してきたホストに対し、前記パケットの宛先ＩＰアドレスを送信元ＩＰアドレスに、前記パケットの送信元ＩＰアドレスを宛先ＩＰアドレスにそれぞれ設定したメッセージによって、前記第２のＭＴＵ長を前記ホストに通知することを特徴とする通信方法。
【請求項７】
請求項６に記載の通信方法であって、
前記メッセージは、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ  Ｐｒｏｔｏｃｏｌ）のフォーマットに基づいて作成したメッセージであることを特徴とする通信方法。
【請求項８】
請求項６又は７に記載の通信方法であって、
前記第２のＭＴＵ長は、前記第１のＭＴＵ長から、前記付加する情報を減算した値であることを特徴とする通信方法。
【請求項９】
請求項６、７又は８に記載の通信方法であって、
前記レイヤ３ネットワークを介して前記第１のＭＴＵ長に関する情報を受信すると、前記第１のＭＴＵ長を更新することを特徴とする通信方法。
【請求項１０】
請求項６、７又は８に記載の通信方法であって、
前記第１のＭＴＵ長は、予め設定された値であることを特徴とする通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置および通信方法に関し、特に、レイヤ３ネットワークへレイヤ２ネットワークのオーバーレイを行う通信装置および通信方法に関する。
【背景技術】
【０００２】
近年、ネットワークの仮想化によるサーバの集約・統合、クラウド化などにより、データセンターなどにおいて複数のテナント（ユーザー組織やそのシステム）を大規模かつ効率的に収容するインフラへの要望が高まっている。複数のテナントを大規模かつ効率的に収容するインフラを実現する方法の１つとして、既存のレイヤ３ネットワーク上に論理的なレイヤ２ネットワークを構築するオーバーレイ方法がある。オーバーレイ方法はレイヤ２のイーサネット（登録商標）フレームをレイヤ３のＩＰパケットにカプセル化するトンネル通信を仮想スイッチ間で行う。このようなオーバーレイ方法にはＶＸＬＡＮ（Ｖｉｒｔｕａｌ  Ｅｘｔｅｎｓｉｂｌｅ  ＶＬＡＮ）、ＧＲＥ（Ｇｅｎｅｒｉｃ  Ｒｏｕｔｉｎｇ  Ｅｎｃａｐｓｕｌａｔｉｏｎ）等がある。
【０００３】
オーバーレイ等の仮想ネットワークにより、企業やグループ等の利用者毎にネットワークを区別して管理する通信システムとして、特許文献１に開示されたような技術がある。オーバーレイ等の仮想ネットワークを利用する場合に、パケットのＭＴＵ（Ｍａｘｉｍｕｍ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｕｎｉｔ）を調整することで、カプセル化処理を実行すべきパケット数を調整し、性能ボトルネックが改善される可能性もあるが、コンピューティングユニットがＶＰＮ（Ｖｉｒｔｕａｌ  Ｐｒｉｖａｔｅ  Ｎｅｔｗｏｒｋ）に接続する度に、ネットワーク接続機器が、ネットワーク制御装置に、ＶＰＮに対応するＭＴＵを問合せると、ＭＴＵの問合せにより生じるボトルネックが問題になる。
【０００４】
特許文献１は、この性能ボトルネックを低減することを目的としたもので、通信データを複数のパケットにより送信するコンピューティングユニットと、仮想ネットワークを介して前記パケットを伝送するためのパケット処理を実行する通信ユニットとを備える通信システムにおいて、コンピューティングユニットは、複数のパケットサイズの候補から、通信ユニットに送信する送信パケットの転送経路に関する情報に基づいて選択されたパケットサイズにより、送信パケットのサイズを調整する技術が開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】ＷＯ２０１４／０５００９１（特表２０１５−５３３０４５号公報）
【発明の概要】
【発明が解決しようとする課題】
【０００６】
引用文献１に記載された発明は、コンピューティングユニットがＶＰＮ（Ｖｉｒｔｕａｌ  Ｐｒｉｖａｔｅ  Ｎｅｔｗｏｒｋ）に接続する度に行ってしまうＭＴＵの問合せを低減することを目的とした発明であり、フラグメントを抑止することは目的としていない。
【０００７】
例えば、イーサネット（登録商標）フレームにより通信を行うレイヤ２ネットワークをレイヤ３ネットワークにオーバーレイを行う場合には、通常、仮想スイッチにおいてカプセル化処理を行う際に、ホストから送信されたイーサネット（登録商標）
フレームに対してトンネル用のカプセル化ヘッダー情報を付加する。このため、ホストが送信するフレームは、ホストに設定された通信経路のＭＴＵ長を超えていなくても、仮想スイッチにおいてヘッダー情報を付加することで通信経路のＭＴＵ長を超えてしまい、仮想スイッチにおいてパケットのフラグメントが発生する場合がある。フラグメントとは、ネットワーク上で一度に送信するできるパケット長であるＭＴＵをオーバーした際、元のパケットをＭＴＵに収まるように分割して送信することである。
【０００８】
このように、ホストが、仮想スイッチなどの通信装置においてトンネル用のカプセル化ヘッダー情報が付加されることを知らずに、通信経路のＭＴＵ長のフレームを送信してくると、そのようなフレームを受信する度に、通信装置は、ヘッダー情報付加後のフレームに対してフラグメント処理を行う必要が生じ、通信装置においてパケットの分割・再構築を頻繁に繰り返すため通信装置の処理負荷が増大してしまい通信装置の性能が低下する恐れがある。また、パケットを分割するためパケット数の増加によりパケット転送効率が低下する恐れがある。また、分割したパケットのいずれかが破損した場合はパケットの再構築が不可能となる。さらには、パケット分割禁止（パケット内のＤＦ（Ｄｏｎ’ｔ Ｆｒａｇｍｅｎｔ）ビットが有効）の場合には、通信装置においてフラグメント処理が行えずにパケットの転送が行えない結果となる。しかし、レイヤ３ネットワークにレイヤ２ネットワークをオーバーレイしている場合には、通信装置においてカプセル化ヘッダー情報が付加されるためにＭＴＵを超えてパケットが送信できないということをホストが知る手段がなく、ホストから見ると何度フレームを送信しても相手側に届かない原因を知ることができない。
【０００９】
このような問題を回避するためには、ネットワーク環境構築時に、通信装置のすべての通信経路に対して予めさまざまなケースを想定してＭＴＵを設定しておくという構築方法もあるが、ネットワークの構築を複雑化し難しくする要因となってしまう。
【００１０】
フラグメントを避ける別の方法として、レイヤ３ネットワーク上のＭＴＵを増やすことが考えられるが、公共的なネットワークの場合、ＭＴＵ変更はリスクが高い。また、一般的なイーサネット（登録商標）環境の場合、レイヤ２ネットワーク内の通信装置はジャンボフレームに対応していることが必要となる場合もある。
【００１１】
一方、レイヤ３ネットワーク上のＭＴＵを変更せずにＭＴＵをオーバーしないようにパケット長を減らす場合、通信経路毎にＭＴＵが異なるため、ネットワーク管理者・利用者に、通信経路毎にＭＴＵの管理を行わせるとネットワーク管理者・利用者の負担が大きくなる。
【００１２】
本発明は、上記課題を解決するためになされたもので、レイヤ２ネットワークからレイヤ３ネットワークへオーバーレイする場合に、ネットワーク管理者・利用者の負担を増やすことなく通信装置におけるフラグメントを防ぐことを目的とする。
【課題を解決するための手段】
【００１３】
上記課題を解決するために、本発明は一例として、レイヤ２ネットワークのホスト間の通信をレイヤ３ネットワークにオーバーレイする通信装置において、レイヤ３ネットワークにおける複数の通信経路について、通信経路毎の第１のＭＴＵ長を管理するとともに、レイヤ２ネットワークのホスト間の通信を複数の通信経路を介してオーバーレイする場合に付加する情報に基づき第２のＭＴＵ長を求め、求めた第２のＭＴＵ長をホストに通知するようにしたものである。
【００１４】
また、通信装置においてホストから受信したパケットに付加する情報を付加後のパケット長が第１のＭＴＵ長を超えていた場合に、パケットを送信してきたホストに対し、第２のＭＴＵ長を通知するようにしたものである。
【００１５】
また、より詳しくは、第２のＭＴＵ長を、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ  Ｐｒｏｔｏｃｏｌ）のフォーマットに基づいて作成したメッセージに含めて通知するようにしたものである。
【００１６】
また、第２のＭＴＵ長は、第１のＭＴＵ長から、前記付加する情報を減算した値としたものである。
【発明の効果】
【００１７】
本発明によれば、レイヤ２ネットワークからレイヤ３ネットワークへオーバーレイする際、ネットワーク管理者・利用者の負担を増やすことなく通信装置におけるフラグメントを防ぐことができる。
【図面の簡単な説明】
【００１８】
【図１】レイヤ２ネットワークからレイヤ３ネットワークへオーバーレイする通信ネットワークの構成を説明する図である。
【図２】本発明の一実施例における通信装置の構成を説明する図である。
【図３】本発明の一実施例におけるオーバーレイネットワークのホスト間通信の処理を説明するシーケンス図である。
【図４】本発明の一実施例における通信装置のＭＴＵ管理部の処理を説明するフローチャートである。
【図５】本発明の一実施例における通信装置のＭＴＵ管理部の処理を説明するフローチャートである。
【図６】本発明の一実施例におけるパケット編集結果ログを示す図である。
【図７】本発明の一実施例におけるＭＴＵ管理テーブルを示す図である。
【図８】本発明の一実施例におけるＭＡＣアドレステーブルを示す図である。
【発明を実施するための形態】
【００１９】
以下、本発明の実施の形態について、図１〜図６を用いて説明する。なお、実質同一部位には、同じ参照番号を振り、説明は繰り返さない。
【００２０】
図１は、レイヤ２ネットワークからレイヤ３ネットワークへオーバーレイする通信ネットワークの構成を説明する図である。
図１を参照してレイヤ２ネットワークからレイヤ３ネットワークへオーバーレイする構成を説明する。
図１は、レイヤ２ネットワーク１２０からレイヤ３ネットワーク１３０へオーバーレイする通信ネットワークを示しており、レイヤ２ネットワークのホスト１０１−１〜ホスト１０１−ｎと通信装置１１１が、レイヤ３ネットワークをオーバーレイすることで、通信装置１１２およびホスト１０２−１〜ホスト１０２−ｎを有するレイヤ２ネットワークと接続されている。
【００２１】
ホスト１０１と通信装置１１１、ホスト１０２と通信装置１１２は共に接続されており、レイヤ２ネットワーク１２０に属している。通信装置１１１はレイヤ３ネットワーク１３０を介して送信先の通信装置１１２と接続されている。
【００２２】
ホスト１０１および１０２は、それぞれ通信装置１１１および通信装置１１２と通信をするＰＣ（パーソナル・コンピューター）などのコンピューター装置である。通信装置１１１は仮想スイッチなどのレイヤ３ネットワーク１３０へのゲートウェイ装置である。通信装置１１１、通信装置１１２は、レイヤ３ネットワーク１３０を介してホスト１０１、１０２から受信したフレームを送信先の通信装置１１２に転送する。なお、通信装置１１１および１１２は、レイヤ３ネットワーク１３０を介する際、オーバーレイ方式を用いてトンネル通信を行う。
【００２３】
図２は、本発明の一実施例における通信装置の構成を説明する図である。
図２を参照して、通信装置１１１の構成を説明する。図１の通信装置１１２も同様の構成である。
通信装置１１１は、パケット通信部２００、通信制御部２４０、パケット編集部２１０、ＭＴＵ管理部２２０、ＭＴＵ管理テーブル２５０、ＭＡＣアドレステーブル２６０、およびパケット編集結果ログ２３０から構成されている。
【００２４】
パケット通信部２００はパケット送受信を行う。
通信制御部２４０は通信に関する制御、例えばスイッチやルータの基本動作の制御に該当する制御を行う。通信制御部２４０はパケットが送受信されたときにＭＡＣアドレステーブル２６０の作成・更新を行う。
【００２５】
図８に、本発明の一実施例におけるＭＡＣアドレステーブルを示す。
ＭＡＣアドレステーブル２６０の構成は、図８に示す通りであり、ＭＡＣアドレス８００、Ｌ３ネットワーク側ＩＰアドレス８１０、ホスト側ポート番号８２０、ホスト側ＶＬＡＮ ＩＤ８３０で構成される。ＭＡＣアドレステーブル２６０はＭＴＵ管理テーブル２５０を作成するときに参照するテーブルである。
【００２６】
図２に戻り、パケット編集部２１０は、パケット通信部２００が受信したパケットについて、内容の参照、および編集を行う。また、パケットをカプセル化する場合、適用されるオーバーレイ方式に基づいたヘッダー情報を付加および削除する。また、パケット長が対象経路のＭＴＵ長を超えた場合にＩＣＭＰプロトコル（Ｉｎｔｅｒｎｅｔ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ  Ｐｒｏｔｏｃｏｌ）のフォーマットに基づくエラーメッセージを作成して送信するとともに送信したエラーメッセージの内容をパケット編集結果ログ２３０へ登録する処理も行う。
【００２７】
ＭＴＵ管理部２２０は通信経路毎に、対象経路のＭＴＵ長を管理するＭＴＵ管理テーブル２５０の作成・更新を行うとともに、ＭＴＵ管理テーブル２５０で管理されている通信経路毎のＭＴＵ長と、パケット編集部２１０においてパケットに追加されるヘッダー長に基づいて、受信したパケットが満たすべきＭＴＵ長（ホスト１０１、１０２からの送信パケットが満たすべきＭＴＵ長）を計算する。
【００２８】
図７に、本発明の一実施例におけるＭＴＵ管理テーブルの構成を示す。
ＭＴＵ管理テーブル２５０の構成は、図７に示す通りであり、宛先ＩＰアドレス７１０はパケットに保持されている宛先ＭＡＣアドレスを用いて、ＭＡＣアドレステーブル２６０から該当するＭＡＣアドレス８００を検索してそのＭＡＣアドレス８００に対応するＬ３ネットワーク側ＩＰアドレス８１０を抽出し、宛先ＩＰアドレス７１０に登録する。ＭＴＵ長７２０は対象経路のＭＴＵ長を登録する。通信経路上のＭＴＵの内、最小のものを調べる既存技術としてＰａｔｈ  ＭＴＵ  Ｄｉｓｃｏｖｅｒｙ（ＲＦＣ１１９１）（以降、ＰＭＴＵＤと記載する）がある。ＭＴＵ管理部２２０は、対象経路のＭＴＵ長についてＰＭＴＵＤによるＭＴＵ長の通知があればＭＴＵ長７２０を更新する。また、パケット通信部２００を介して受信したパケット長にパケット編集部２１０において追加されるヘッダー長を加えたパケット長と、対象経路のＭＴＵ長を比較する。
【００２９】
図３は、本発明の一実施例におけるオーバーレイネットワークのホスト間通信の処理を説明するシーケンス図である。
図３を参照して、図１の通信ネットワークにおけるホスト１（１０１）、ホスト２（１０２）間通信の処理シーケンスを説明する。なお、ホスト１（１０１）、通信装置１（１１１）、通信装置２（１１２）およびホスト２（１０２）のそれぞれの通信経路のＭＴＵ長は例として１５００Ｂｙｔｅとする。
【００３０】
ホスト１（１０１）がホスト２（１０２）へパケット転送する場合、まず通信装置１（１１１）へパケットが送信される（３００）。通信装置１（１１１）は、ＭＴＵ管理テーブルを参照し、受信したパケットのパケット長にカプセル化に必要なヘッダー長を足したサイズと、通信経路のＭＴＵ長を比較する（３１０）。比較した結果、受信したパケットのパケット長にカプセル化に必要なヘッダー長を足したサイズが、通信経路のＭＴＵ長より大きければ、ＩＣＭＰプロトコルのフォーマットに従ったメッセージを作成して、ホスト１（１０１）からの送信パケットが満たすべきＭＴＵ長を埋め込んだエラーメッセージをホスト１（１０１）へ通知する（３２０）。詳細について図４に示し、後述する。
ホスト１（１０１）は受け取ったエラーメッセージから抽出したホスト１（１０１）からの送信パケットが満たすべきＭＴＵ長にパケット長をあわせて、通信装置１（１１１）へパケットを再送する（３３０）。
【００３１】
通信装置１（１１１）は、ホスト１（１０１）から受信したパケットのパケット長が、そのパケットの送信先の通信経路のＭＴＵ長を超えていなければ（３４０）、パケットのカプセル化処理を行い（３５０）、通信装置２（１１２）へパケットが送信する（３６０）。通信装置２（１１２）でも処理３１０、処理３４０と同様に、ＭＴＵ管理テーブルを参照して通信経路を介して通信装置１（１１１）から受信したパケットのパケット長とそのパケットの通信経路のＭＴＵ長を比較し（３７０）、パケット長が通信経路のＭＴＵ長を超えていなければカプセル化処理（３５０）で付加した情報を削除し（３８０）、ホスト２（１０２）へパケットを送信する（３９０）。
【００３２】
図４は、本発明の一実施例における通信装置のＭＴＵ管理部の処理を説明するフローチャートである。
図４を参照して、通信装置１１１または通信装置１１２のＭＴＵ管理部２２０における受信パケット長にパケット編集部２１０で付加するヘッダー情報を追加後のパケット長と通信経路のＭＴＵ長の比較、および受信パケット長にパケット編集部２１０で付加するヘッダー情報を追加後のパケット長が通信経路のＭＴＵ長をオーバーする時のパケット編集部２１０のエラー通知の処理フローを説明する。
【００３３】
ＭＴＵ管理部２２０は、まず、図7に示すＭＴＵ管理テーブル２５０から受信パケットの宛先ＩＰアドレスに該当する通信経路のＭＴＵ長を抽出する（Ｓ４００）。
ＭＴＵ管理部２２０は、受信したパケットのパケット長と、パケット編集部２１０でパケットのカプセル化を行う際に追加する必要があるヘッダー長を足したサイズと抽出したＭＴＵ長を比較して（Ｓ４１０）、受信したパケットのパケット長とヘッダー長を足したサイズが抽出した通信経路のＭＴＵ長以下であれば、そのままパケットを転送可能とする（Ｓ４２０）。
【００３４】
ＭＴＵ管理部２２０において、受信したパケットのパケット長とヘッダー長を足したサイズが、抽出した通信経路のＭＴＵ長より大きいと判断した場合には、パケット編集部２１０は、ＩＣＭＰプロトコルのフォーマットを用いて、ホスト１（１０１）へエラーメッセージを通知する。パケット編集部２１０は、ＩＣＭＰプロトコルのフォーマットを用いて、以下のようなエラーメッセージを作成する。まず、ＩＣＭＰのＴｙｐｅフィールドには３（Ｄｅｓｔｉｎａｔｉｏｎ  Ｕｎｒｅａｃｈａｂｌｅ）、Ｃｏｄｅフィールドには４（Ｆｒａｇｍｅｎｔａｔｉｏｎ  ｎｅｅｄｅｄ  ａｎｄ  Ｄｏｎ’ｔ  Ｆｒａｇｍｅｎｔ  ｗａｓ  ｓｅｔ）を設定する。Ｎｅｘｔ−Ｈｏｐ  ＭＴＵフィールドには通信装置１（１１１）のＭＴＵ管理テーブル２５０に格納された該当する通信経路のＭＴＵ長から、パケット編集部２１０においてパケットのカプセル化に必要なヘッダー長を引いたパケット長を、ホスト１（１０１）に通知する、ホスト１（１０１）が満たすべきＭＴＵ長として算出し、設定する。
【００３５】
通信装置１（１１１）のパケット編集部（２１０）がＩＣＭＰプロトコルのフォーマットを用いて作成したエラーメッセージにより、ホスト１（１０１）は、送信したパケットが、ＭＴＵ長（ホスト１（１０１）の送信パケットが満たすべきＭＴＵ長）をオーバーしていたことが分かり、ホスト１（１０１）は、ホスト１（１０１）の送信パケットが満たすべきＭＴＵ長を超えないパケット長にすることが可能となる。さらに、パケット編集部２１０は、このＩＣＭＰプロトコルのフォーマットを用いたエラーメッセージのＩＰヘッダーの送信元ＩＰアドレスフィールドにホスト２（１０２）のＩＰアドレスを設定することで、ホスト１（１０１）はあたかもホスト２（１０２）から通知を受け取ったみなし、経路途中にある通信装置（１１１）をレイヤ３の装置として見せないように隠蔽することが可能となる（Ｓ４３０）。最後に、パケット編集部２１０は、パケット編集結果ログ２３０に送信したエラーメッセージの内容を登録する（Ｓ４４０）。パケット編集結果ログ２３０の詳細については図６に示し、後述する。
【００３６】
なお、図４のＳ４００のＭＴＵ長は、ＭＴＵ管理テーブル２５０からパケットの宛先ＩＰアドレスに該当する通信経路のＭＴＵ長を抽出するのではなく、予め固定値を設定することも可能である。通信経路のＭＴＵ長を固定値とすることで、通信経路に設定されているＭＴＵ長を抽出する処理が不要となり、通信装置（１１１）の処理効率が向上される。
【００３７】
図５は、本発明の一実施例における通信装置のＭＴＵ管理部の処理を説明するフローチャートである。
図５に通信経路のＭＴＵ長を固定値とした処理フローを示し、説明する。
ＭＴＵ長は固定値を設定する（Ｓ５００）。固定値については、例えば通信装置（１１１）のコンフィグレーションなどに設定させることが可能である。以降のＳ５１０からＳ５４０の動作については、図４のＳ４１０からＳ４４０と同じである。
【００３８】
図６は、本発明の一実施例におけるパケット編集結果ログを示す図である。
図６を参照して、パケット編集結果ログ２３０の構成を説明する。
日時６００はパケット編集結果ログ２３０に登録した日付と時間、パケット長６１０は通信装置（１１１）に送信されたパケットのパケット長、カプセル化ヘッダー長６２０はパケットのカプセル化に必要なヘッダー長、ＭＴＵ長６３０はパケット送信先経路のＭＴＵ長、送信元ＩＰアドレス６４０は図４のＳ４３０にて設定した送信元ＩＰアドレス、宛先ＩＰアドレス６５０は図４のＳ４３０にて設定した宛先ＩＰアドレス、Ｎｅｘｔ−Ｈｏｐ  ＭＴＵ長６６０は図４のＳ４３０にて設定したＮｅｘｔ−Ｈｏｐ  ＭＴＵ長（ホストの送信パケットが満たすべきＭＴＵ長）を登録する。これらのログ情報はネットワーク上で何かしらの不具合が発生した際に、原因解析の情報として利用することが可能である。
【００３９】
以上説明した実施例による効果としては、以下が挙げられる。
通信経路上のＭＴＵの内、最小のものを調べる既存技術としてＰａｔｈ  ＭＴＵ  Ｄｉｓｃｏｖｅｒｙ（ＲＦＣ１１９１）（ＰＭＴＵＤ）があるが、オーバーレイネットワークのレイヤ２ネットワークの通信装置に対しては、本来ＰＭＴＵＤを用いることができない。しかし、本発明においては、上記構成とすることにより、ホストに対してホストが送信するパケットが満たすべきＭＴＵ長を通知することができる。
【００４０】
また、本発明は、通信経路のＭＴＵ長そのものではなく、トンネル用カプセル化ヘッダー情報の付加分を考慮したＭＴＵ長を、ホストが送信するパケットが満たすべきＭＴＵ長としてホストに通知することで、通信装置におけるパケットのフラグメントを防ぐことが可能になる。
【００４１】
ＭＴＵ長をホストに通知する際、パケットの送信元ＩＰアドレスを送信先ホストのＩＰアドレスに設定することで、ホストからみると経路途中にある通信機器の存在を表面化させずに、オーバーレイ方式によるメリットを生かしたまま、ホストに対してホストが送信するパケットが満たすべきＭＴＵ長を通知することができる。
【００４２】
また、パケットの編集結果を保存することで、不具合が発生した際の解決手段に備えることが可能となる。
【符号の説明】
【００４３】
１０１、１０２・・・ホスト
１１１、１１２・・・通信装置
１２０・・・レイヤ２ネットワーク
１３０・・・レイヤ３ネットワーク
２００・・・パケット通信部
２１０・・・パケット編集部
２２０・・・ＭＴＵ管理部
２３０・・・パケット編集結果ログ
２４０・・・通信制御部
２５０・・・ＭＴＵ管理テーブル
２６０・・・ＭＡＣアドレステーブル
【図１】
0006718739.tif 000002
【図２】
0006718739.tif 000003
【図３】
0006718739.tif 000004
【図４】
0006718739.tif 000005
【図５】
0006718739.tif 000006
【図６】
0006718739.tif 000007
【図７】
0006718739.tif 000008
【図８】
0006718739.tif 000009