JP4222353B2

JP4222353B2 - Ｉｐ通信装置およびｉｐ通信システム

Info

Publication number: JP4222353B2
Application number: JP2005270626A
Authority: JP
Inventors: 良太広瀬
Original assignee: Yamaha Corp
Current assignee: Yamaha Corp
Priority date: 2005-09-16
Filing date: 2005-09-16
Publication date: 2009-02-12
Anticipated expiration: 2025-09-16
Also published as: CN1933486B; JP2007082126A; CN1933486A; US20070076618A1

Description

この発明はＩＰパケットの通信を行うＩＰ通信装置およびＩＰ通信システムに関するものである。

レイヤ３（ネットワーク層）のプロトコルであるＩＰ（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のコードを入れる。また、ＩＣＭＰメッセージ内には、ＩＰ通信装置自身がレイヤ２で取扱可能な最大フレームサイズを適正なＭＴＵとして入れる。

フレームサイズ検査部１２によるフレームサイズ検査がＯＫの場合（受信したフレームサイズが取扱い可能な最大フレームサイズに収まる場合）、そのＭＡＣフレームに対する通常の処理を行う（Ｓ４）。

図８は、送信元ＩＰ通信装置のＣＰＵ１３の処理内容を示すフローチャートである。図８の（Ａ）に示すように、上記ＩＣＭＰエラーを受信した場合、経路ＭＴＵ探索を実行する（Ｓ１１→Ｓ１２）。（Ｂ）はこの経路ＭＴＵ探索の処理手順を示すフローチャートである。まずＭＴＵをＩＰ通信装置自身の最大値に設定し（Ｓ２１）、ＩＰヘッダ中の分割禁止フラグを１にセットして（Ｓ２２）、宛先へ送信しようとするＩＰパケットを送出する（Ｓ２３）。

経路途中のＩＰ通信装置または宛先となるＩＰ通信装置が、そのＭＴＵを超えるＭＡＣフレームを受けると、図７のステップＳ３に示した宛先到達不能な旨のＩＣＭＰエラーを送信元のＩＰ通信装置へ返信するので、この送信元のＩＰ通信装置はそのＩＣＭＰエラーを受ける。この場合、そのＩＣＭＰエラーのメッセージに含まれているＭＴＵを読み取って、そのＭＴＵでＩＰパケットをフラグメントし、宛先へ再送信する（Ｓ２４→Ｓ２５→Ｓ２２→Ｓ２３）。
上記宛先到達不能な旨のＩＣＭＰエラーを受信しなくなるまで以上の処理を繰り返す。このようにして宛先までの経路に適正なＭＴＵを求める。

なお、ＩＰ通信システムを構成する複数のＩＰ通信装置は、通常送信元ノードになる場合と経路途中のノードまたは宛先のノードになる場合があるので、図７に示したフレームサイズの検査およびＩＣＭＰエラーの返信を行う手段と、図８に示した経路ＭＴＵ探索を行う手段の両方を備えている。その場合、図７のフレームサイズ正常時のステップＳ４での処理内容の１つが、図８に示したＩＣＭＰエラー受信時の経路ＭＴＵ探索処理ということになる。

また、図８に示した例ではＩＣＭＰエラーを受信したとき、それがトリガーとなって改めて経路ＭＴＵ探索を実行するので、この経路ＭＴＵ探索でもう一度ＩＣＭＰエラーを受信することになる。しかし、上述したとおり、ＭＴＵを超えるＭＡＣフレームを受けた際に送信元へ通知するＩＣＭＰエラーには適正なＭＴＵが含まれているので、送信元ＩＰ通信装置は、この最初のＩＣＭＰエラーを受信した時点で自身のＭＴＵを上記適正なＭＴＵに設定し、経路ＭＴＵ探索を省略するように構成してもよい。

経路ＭＴＵ探索の処理を示す図である。ＩＰパケットのフラグメントについて示す図である。ジャンボフレームの通信時のフレームサイズの変化の例を示す図である。この発明の実施形態に係るＩＰ通信装置の構成を示すブロック図である。ＩＰパケットとＭＡＣフレームの関係を示す図である。ＩＣＭＰパケットの構成を示す図である。受信データが最大フレームサイズを超える場合と超えない場合とでの処理内容を示すフローチャートてある。ＩＣＭＰエラーを受信した時の処理内容を示すフローチャートである。

符号の説明

１０−ＩＰ通信装置

Claims

ネットワークを介してＭＡＣフレームの送受信を行う送受信手段と、
受信したＭＡＣフレームをバッファリングし、該バッファリングしたＭＡＣフレームのデータリンク層でのＭＡＣフレームサイズが前記送受信手段によって取扱可能な最大フレームサイズを超えているか否かを、該バッファリングしたＭＡＣフレームがバッファに収まったか否かによって検査する手段と、
前記最大ＭＡＣフレームサイズを超えているとき、前記バッファリングしたＭＡＣフレームに含まれるネットワーク層の送信元の情報を抽出するとともに、前記最大ＭＡＣフレームサイズをＭＴＵとしてメッセージ部分に含む、ネットワーク層でのＩＣＭＰエラーを前記送信元へ返信する手段と、
を備えたＩＰ通信装置。
ネットワークを介してＭＡＣフレームの送受信を行う送受信手段、受信したＭＡＣフレームをバッファリングし、該バッファリングしたＭＡＣフレームのデータリンク層でのＭＡＣフレームサイズが前記送受信手段によって取扱可能な最大フレームサイズを超えているか否かを、該バッファリングしたＭＡＣフレームがバッファに収まったか否かによって検査する手段、および前記最大ＭＡＣフレームサイズを超えているとき、前記バッファリングしたＭＡＣフレームに含まれるネットワーク層の送信元の情報を抽出するとともに、前記最大ＭＡＣフレームサイズをＭＴＵとしてメッセージ部分に含む、ネットワーク層でのＩＣＭＰエラーを前記送信元へ返信する手段、を有するＩＰ通信装置と、
ＩＣＭＰエラーを受信したときに経路ＭＴＵ探索を実行する手段を有するＩＰ通信装置と、
を備えたＩＰ通信システム。