(57)【要約】【課題】  いわゆるジャンボフレームを用いた通信で、ネットワーク管理者による設定を不要とし、効率の良い通信を行えるようにしたＩＰ通信装置およびそのシステムを構成する。【解決手段】  フレームサイズ検査部１２がフレームサイズを検査し、受信部１１で受信したＭＡＣフレームのフレームサイズが取扱い可能な最大フレームサイズを超えている時、ＣＰＵ１３は、そのＭＡＣフレームの一部に含まれている送信元のＩＰアドレスを抽出し、送信部１４を介してその送信元へＩＣＭＰエラーを返信する。  これにより、送信元では直ちに経路ＭＴＵ探索を実行し、ジャンボフレーム通信時のブラックホールの発生を防止する。【選択図】  図４
2007082126.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介してデータの送受信を行う送受信手段と、
受信したデータのフレームサイズが前記送受信手段によって取扱可能な最大フレームサイズを超えているか否かを検査する手段と、前記最大フレームサイズを超えているとき、前記受信したフレームに含まれる送信元の情報を抽出するとともに、前記最大フレームサイズをＭＴＵとしてメッセージ部分に含むＩＣＭＰエラーを前記送信元へ返信する手段と、
を備えたＩＰ通信装置。
【請求項２】
ネットワークを介してデータの送受信を行う送受信手段、受信したデータのフレームサイズが前記送受信手段によって取扱可能な最大フレームサイズを超えているか否かを検査する手段、および前記最大フレームサイズを超えているとき、前記受信したフレームに含まれる送信元の情報を抽出するとともに、前記最大フレームサイズをＭＴＵとしてメッセージ部分に含むＩＣＭＰエラーを前記送信元へ返信する手段、を有するＩＰ通信装置と、
ＩＣＭＰエラーを受信したときに経路ＭＴＵ探索を実行する手段を有するＩＰ通信装置と、
を備えたＩＰ通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明はＩＰパケットの通信を行うＩＰ通信装置およびＩＰ通信システムに関するものである。
【背景技術】
【０００２】
レイヤ３（ネットワーク層）のプロトコルであるＩＰ（Internet Protocol）（非特許文献１参照）では、イーサネット（登録商標）をはじめとするレイヤ２（データリンク層）の多様なプロトコルに格納できるようにＭＴＵ（Maximum Transmission Unit）という概念を用意している。このＭＴＵとはレイヤ２のプロトコルに格納できる最大データ長のことである。
【０００３】
ＩＰパケット（ＩＰデータグラム）の最大長は６５５３５オクテットと規定されているが、例えばそれをＭＡＣフレームに格納する時には、イーサネット（登録商標）の最大フレームサイズすなわちＭＴＵである１５００オクテットに分割して格納することになる。
【０００４】
レイヤ２のプロトコルはイーサネット（登録商標）に限らず幾つかのプロトコルが存在するので、ＭＴＵの値についても多様であり、インターネット環境では複数のレイヤ２プロトコルがＩＰパケットを格納することが考えられる。ＭＴＵの大きなレイヤ２からＭＴＵの小さなレイヤ２にＩＰパケットを載せ替える時、ＩＰパケットを複数のＩＰパケットに分割することになる。これをフラグメントという。このようなフラグメントが生じると、ＩＰパケットの数が増え、各ＩＰパケットにはヘッダが付されているので、転送すべきトータルのデータ量が多くなることになり、全体の通信効率が低下する。そのため、ノード（ホスト）間で通信を行う、その２つのノードとそのノード間の経路中に存在する他のノードのうち最も小さなＭＴＵに合わせてＩＰパケットを分割すると最も効率化が図れる。このようなパケットの分割は当初ルータが行っていたが、ルータに負担が掛かり過ぎるので、後にパケットの分割を送信元のホストが行うようになった。そのために、通信経路での最も短いＭＴＵを検知するための方法である「経路ＭＴＵ探索」という手法が用いられる（非特許文献２参照）。
【０００５】
図１はその経路ＭＴＵ探索について示している。この図１に示すように、経路ＭＴＵ探索は次の手順で行われる。
【０００６】
（１）まず送信元のホストはＩＰヘッダ中の分割禁止フラグをセットする。
（２）ＩＰパケットを送信する。
図１の例ではパケット長１５００のパケットを送信する。
（３）ＭＴＵを超えるパケットが送られてきたとき、ルータは分割せずにパケットを破棄する。
（４）宛先到達不能な場合、ＩＣＭＰ（Internet Control Message Protocol）エラーを送信元ホストＨ１へ通知する。
この例ではルータＲ１とルータＲ２の間の経路は例えば電話回線であって、ＭＴＵ＝５７６である。そのためルータＲ１は送信元ホストＨ１からのパケット長１５００のパケットを破棄し、ＩＣＭＰの到達不能メッセージを送信元ホストＨ１へ通知する。このＩＣＭＰエラーのメッセージには、ルータＲ１から先の経路のＭＴＵが５７６であることを示す情報が含まれている。
（５）通知されたＭＴＵのサイズのパケットを再送信する。
この例では、送信元ホストＨ１は、そのＭＴＵを５７６に変更し、パケット長５７６オクテットのＩＰパケットを再び宛先ホストＨ２へ送信する。送信元ホストＨ１から宛先ホストＨ２までの経路のＭＴＵは５７６以上であるので、宛先ホストＨ２へパケットが到達することになる。
この例では１回のＩＣＭＰの到達不能メッセージの受信によって経路ＭＴＵ探索が完了したが、一般的には、パケットが宛先ホストに到達するまで（ＩＣＭＰエラーの通知が無くなるまで）上記（２）〜（５）を繰り返す。
【０００７】
図２は上記経路ＭＴＵ探索が完了した後、送信元ホストＨ１と宛先ホストＨ２間でのＩＰパケットの分割と再構築について示している。上述の例では送信元ホストＨ１から宛先ホストＨ２までの最小ＭＴＵが５７６オクテットであるので、送信元ホストＨ１はパケット長１５００オクテットのパケットをパケット長５７６オクテットの２つのパケットとパケット長３４８の合計３つパケットに分割して、３度にわたって宛先ホストＨ２へ送信する。宛先ホストＨ２ではこの３つのパケットに含まれているパケットを元に戻す（再構築する）。
【非特許文献１】ＲＦＣ７９１、[online]、［平成１７年９月８日検索］、インターネット＜http://www.ietf.org/rfc/rfc791.txt＞
【非特許文献２】ＲＦＣ１１９１、[online]、［平成１７年９月８日検索］、インターネット＜http://www.ietf.org/rfc/rfc1191.txt＞
【発明の開示】
【発明が解決しようとする課題】
【０００８】
一方、イーサネット（登録商標）では、その規格で規定されている最大フレームサイズ（１５００オクテット）を超えるフレームサイズを、通信の効率化のために使用されるようになってきている。このような１５００オクテットを超えるＭＡＣフレームのことをジャンボフレームと呼ぶ。
【０００９】
ところが、これらのジャンボフレームは、イーサネット（登録商標）本来のＭＴＵが１５００オクテットであるところ、それより大きなフレームサイズとして利用してＭＴＵを拡大するものである。このようなジャンボフレームには明確な規格が存在せず、ＭＴＵについてもメーカーや製品毎にバラバラであるのが実情である。
【００１０】
そのため、それらの様々なフレームサイズで通信を行おうとする装置間で相互接続を行うために、ネットワーク管理者はそれぞれの装置のＭＴＵを調べ、通信経路上での最小のＭＴＵがその通信経路で用いられるように個々の装置を手動で設定する必要があった。このような手動での設定は手間が掛かるばかりでなく、設定ミスによって通信ができなくなるといった事態も起こりうる。
【００１１】
例えば自身の扱えるフレームサイズより大きなフレームを受信した時に、その装置はレイヤ２（データリンク層）でそのフレームを単に破棄するだけである。そのため、フレームを送った装置側では、フレームを送信したまま、その返事が得られないといういわゆるブラックホール状態となってしまう。このようなブラックホールの対策として、ブラックホールが発生した時に前記経路ＭＴＵ探索アルゴリズムを援用して、ＭＴＵを小さくしたＭＡＣフレームを再送するという手法がＲＦＣ２９２３で提案されている。
【００１２】
しかしながら、このブラックホールによる経路ＭＴＵ探索は、上記の返事が得られないという状況を判断するためにタイムアウトを待ってから経路ＭＴＵ探索を起動するので、通常の経路ＭＴＵ探索に比べると、それが起動されるまでの時間が長く掛かる。
【００１３】
また、通常の経路ＭＴＵ探索では、前述したように、ＩＣＭＰエラーを返信するノードがＩＣＭＰエラー中に参考となるＭＴＵを記入しているので、その情報を基に経路ＭＴＵを調べることができるが、ブラックホールによって起動された経路ＭＴＵ探索では、送信元にとって参考にできる情報がなく、そのために言わば手探りでＭＴＵを小さくしてみるといった方法を採らざるをえない。
【００１４】
例えば図３に示す例で、ＭＴＵ＝９０００オクテットの送信元ホストＨ１からＭＴＵ＝７０００オクテットの宛先ホストＨ２に対して送信する場合を考える。送信元ホストＨ１から宛先ホストＨ２に対してフレームサイズ９０００オクテットのパケット送信した場合、途中のスイッチングハブＳＨは単にＭＡＣフレームを転送するだけであるので、宛先ホストＨ２はフレームサイズ９０００オクテットのＭＡＣフレームを受け取る際、それはサイズオーバであるので、宛先ホストＨ２ではそのフレームをレイヤ２がそのまま破棄するだけである。
【００１５】
送信元ホストＨ１は一定時間待っても返事が返って来ないので、ＭＴＵを例えば半分にし、フレームサイズを４５００オクテットのＭＡＣフレームを再送する。このフレームサイズは宛先ホストＨ２のＭＴＵ＝７０００オクテットより小さいので、宛先ホストＨ２はそれを受け取って処理することになる。
【００１６】
ところが本来ＭＴＵ＝７０００オクテットで通信可能な宛先ホストＨ２に対してＭＵＴ＝４５００オクテットで通信を行うので効率が悪くなってしまう。仮にフレームサイズの縮小の度合いを小さくして何度も試行すれば、より適切なフレームサイズにたどりつくが、そのための試行回数が増え、通信効率がやはり低下するという問題が生じる。
【００１７】
そこで、この発明の目的は、上述の問題を解消して、いわゆるジャンボフレームを用いた通信で、ネットワーク管理者による設定を不要として効率の良い通信を行えるようにしたＩＰ通信装置を提供することにある。
【課題を解決するための手段】
【００１８】
この発明のＩＰ通信装置は、ネットワークを介してデータの送受信を行う送受信手段と、受信したデータのフレームサイズが前記送受信手段によって取扱可能な最大フレームサイズを超えているか否かを検査する手段と、前記最大フレームサイズを超えているとき、前記受信したフレームに含まれる送信元の情報を抽出するとともに、前記最大フレームサイズをＭＴＵとしてメッセージ部分に含むＩＣＭＰエラーを前記送信元へ返信する手段とを備えたことを特徴としている。
【００１９】
また、この発明のＩＰ通信システムは、ネットワークを介してデータの送受信を行う送受信手段、受信したデータのフレームサイズが前記送受信手段によって取扱可能な最大フレームサイズを超えているか否かを検査する手段、および前記最大フレームサイズを超えているとき、前記受信したフレームに含まれる送信元の情報を抽出するとともに、前記最大フレームサイズをＭＴＵとしてメッセージ部分に含むＩＣＭＰエラーを前記送信元へ返信する手段、を有するＩＰ通信装置と、
ＩＣＭＰエラーを受信したときに経路ＭＴＵ探索を実行する手段を有するＩＰ通信装置と、
を備えたことを特徴としている。
【発明の効果】
【００２０】
受信したデータのフレームサイズが取扱い可能な最大フレームサイズを超えている時、その受信したフレームに含まれている送信元の情報を基にＩＣＭＰエラーを送信元へ返信するようにし、またＩＣＭＰエラーに前記最大フレームサイズをＭＴＵとして含むようにしたため、レイヤ２（データリンク層）でのフレームサイズオーバというエラーをネットワーク層でのＩＰパケットの到達に関するエラーとして送信元は検知可能となり、また、送信元は宛先までの経路に適するＭＴＵが検知可能となる。
【００２１】
また、上記ＩＣＭＰエラーを受信した時、経路ＭＴＵ探索が実行されて、その結果、送信されるフレームサイズが上記ＩＣＭＰエラーを返したＩＰ通信装置のＭＴＵに収まる値に設定されるので、ブラックホールが生じることなく、適切な経路ＭＴＵを迅速に定めることができ、通信の効率化が図れる。
【発明を実施するための最良の形態】
【００２２】
この発明に係るＩＰ通信装置およびＩＰ通信システムについて図４〜図８を基に説明する。
図４はＩＰ通信装置の構成を示すブロック図である。図４において受信部１１はイーサネット（登録商標）の信号を受信し、所定ビット長までＭＡＣフレームをバッファリングする。フレームサイズ検査部１２は、受信部１１で受信されたＭＡＣフレームのサイズが上記バッファに収まったか否か、すなわち予め定められた最大フレームサイズを超えているか否かを検査する。ＣＰＵ１３は受信部１１で受信されバッファリングされたデータを解析して所定の処理を行う。例えばレイヤ２（データリンク層）ではＭＡＣヘッダ、データ部分、ＦＣＳ部分の抽出を行って、誤り検出を行う。レイヤ３（ネットワーク層）では、ＭＡＣフレームのデータ部分すなわちＩＰパケットからＩＰヘッダとペイロード（データ部分）を抽出する。レイヤ４（トランスポート層）では、ＩＰパケット内のペイロードすなわちＴＣＰセグメントからＴＣＰヘッダとデータ部分を抽出する。それより上位の層についても、例えばＴＣＰセグメントから抽出したＴＣＰを使うアプリケーションのデータを基に所定の処理を行う。
【００２３】
また、ＣＰＵ１３は送信部１４に対してイーサネット（登録商標）を介して送信すべきＭＡＣフレームを出力する。送信部１４は、そのＭＡＣフレームをイーサネット（登録商標）上へ送出する。
【００２４】
また、ＣＰＵ１３はフレームサイズ検査部１２が最大フレームサイズを超えたことを検知した時、後述するようにＩＣＭＰエラーを作成し、送信部１４から送信する。
【００２５】
図５は上記ＭＡＣフレームとＩＰパケットとの関係を示している。ＭＡＣフレームは、ＭＡＣヘッダ、データ、ＦＣＳから構成される。ＭＡＣヘッダには宛先ＭＡＣアドレス、送信元ＭＡＣアドレス、フレームタイプ等が含まれている。ＩＰパケットはＩＰヘッダとペイロードから構成され、ＩＰヘッダには送信元ＩＰアドレス、宛先ＩＰアドレス、ペイロード長が含まれている。
【００２６】
図６は上記ＩＣＭＰエラーのパケットについて示している。ＩＣＭＰエラーのパケットはＩＰヘッダとＩＣＭＰメッセージからなり、ＩＣＭＰメッセージには一般的にはエラーの内容（原因）を識別するための情報とエラーになったＩＰパケットの前半部分を含んでいる。しかし、フレームサイズが最大フレームサイズを超えている場合に作成するＩＣＭＰエラーの場合、ＩＰパケットの全体は抽出できないので、受信したＭＡＣフレーム内のデータからＩＰパケットの必要部分を抽出してＩＣＭＰメッセージを構成することになる。
【００２７】
図７・図８は、上記ＩＰ通信装置を複数含むＩＰ通信システムにおいて、送信元となるＩＰ通信装置と経路途中のＩＰ通信装置または宛先となるＩＰ通信装置について、図４に示したＩＰ通信装置のＣＰＵ１３の処理内容を示す図である。
【００２８】
図７は、経路途中のＩＰ通信装置または宛先となるＩＰ通信装置のＣＰＵ１３の処理内容を示すフローチャートである。図４に示したフレームサイズ検査部１２によるフレームサイズ検査がＮＧの場合（受信したフレームサイズが取扱い可能な最大フレームサイズを超えている場合）、受信部１１内のバッファに溜まっているＭＡＣフレームの一部（前半部分）から送信元のＩＰアドレスを抽出し、ＩＣＭＰエラーをその送信元へ返信する（Ｓ１→Ｓ２→Ｓ３）。このＩＣＭＰエラーは、図６に示したＩＰヘッダ部分に上記送信元ＩＰアドレスと自身（ＩＰ通信装置）のＩＰアドレスを含み、ＩＣＭＰメッセージ内には、ＩＰｖ４（Internet Protocol Version 4）の場合、タイプ＝３（到達不能エラー）、コード＝４（フラグメントエラー）を入れる。また、ＩＰｖ６（Internet Protocol Version 6）の場合、Packet Too Bigのコードを入れる。また、ＩＣＭＰメッセージ内には、ＩＰ通信装置自身がレイヤ２で取扱可能な最大フレームサイズを適正なＭＴＵとして入れる。
【００２９】
フレームサイズ検査部１２によるフレームサイズ検査がＯＫの場合（受信したフレームサイズが取扱い可能な最大フレームサイズに収まる場合）、そのＭＡＣフレームに対する通常の処理を行う（Ｓ４）。
【００３０】
図８は、送信元ＩＰ通信装置のＣＰＵ１３の処理内容を示すフローチャートである。図８の（Ａ）に示すように、上記ＩＣＭＰエラーを受信した場合、経路ＭＴＵ探索を実行する（Ｓ１１→Ｓ１２）。（Ｂ）はこの経路ＭＴＵ探索の処理手順を示すフローチャートである。まずＭＴＵをＩＰ通信装置自身の最大値に設定し（Ｓ２１）、ＩＰヘッダ中の分割禁止フラグを１にセットして（Ｓ２２）、宛先へ送信しようとするＩＰパケットを送出する（Ｓ２３）。
【００３１】
経路途中のＩＰ通信装置または宛先となるＩＰ通信装置が、そのＭＴＵを超えるＭＡＣフレームを受けると、図７のステップＳ３に示した宛先到達不能な旨のＩＣＭＰエラーを送信元のＩＰ通信装置へ返信するので、この送信元のＩＰ通信装置はそのＩＣＭＰエラーを受ける。この場合、そのＩＣＭＰエラーのメッセージに含まれているＭＴＵを読み取って、そのＭＴＵでＩＰパケットをフラグメントし、宛先へ再送信する（Ｓ２４→Ｓ２５→Ｓ２２→Ｓ２３）。
上記宛先到達不能な旨のＩＣＭＰエラーを受信しなくなるまで以上の処理を繰り返す。このようにして宛先までの経路に適正なＭＴＵを求める。
【００３２】
なお、ＩＰ通信システムを構成する複数のＩＰ通信装置は、通常送信元ノードになる場合と経路途中のノードまたは宛先のノードになる場合があるので、図７に示したフレームサイズの検査およびＩＣＭＰエラーの返信を行う手段と、図８に示した経路ＭＴＵ探索を行う手段の両方を備えている。その場合、図７のフレームサイズ正常時のステップＳ４での処理内容の１つが、図８に示したＩＣＭＰエラー受信時の経路ＭＴＵ探索処理ということになる。
【００３３】
また、図８に示した例ではＩＣＭＰエラーを受信したとき、それがトリガーとなって改めて経路ＭＴＵ探索を実行するので、この経路ＭＴＵ探索でもう一度ＩＣＭＰエラーを受信することになる。しかし、上述したとおり、ＭＴＵを超えるＭＡＣフレームを受けた際に送信元へ通知するＩＣＭＰエラーには適正なＭＴＵが含まれているので、送信元ＩＰ通信装置は、この最初のＩＣＭＰエラーを受信した時点で自身のＭＴＵを上記適正なＭＴＵに設定し、経路ＭＴＵ探索を省略するように構成してもよい。
【図面の簡単な説明】
【００３４】
【図１】経路ＭＴＵ探索の処理を示す図である。
【図２】ＩＰパケットのフラグメントについて示す図である。
【図３】ジャンボフレームの通信時のフレームサイズの変化の例を示す図である。
【図４】この発明の実施形態に係るＩＰ通信装置の構成を示すブロック図である。
【図５】ＩＰパケットとＭＡＣフレームの関係を示す図である。
【図６】ＩＣＭＰパケットの構成を示す図である。
【図７】受信データが最大フレームサイズを超える場合と超えない場合とでの処理内容を示すフローチャートてある。
【図８】ＩＣＭＰエラーを受信した時の処理内容を示すフローチャートである。
【符号の説明】
【００３５】
１０−ＩＰ通信装置
【図１】
2007082126.tif 000003
【図２】
2007082126.tif 000004
【図３】
2007082126.tif 000005
【図４】
2007082126.tif 000006
【図５】
2007082126.tif 000007
【図６】
2007082126.tif 000008
【図７】
2007082126.tif 000009
【図８】
2007082126.tif 000010