JP4724634B2 - データ受信装置及びデータ受信方法 - Google Patents

データ受信装置及びデータ受信方法 Download PDF

Info

Publication number
JP4724634B2
JP4724634B2 JP2006268067A JP2006268067A JP4724634B2 JP 4724634 B2 JP4724634 B2 JP 4724634B2 JP 2006268067 A JP2006268067 A JP 2006268067A JP 2006268067 A JP2006268067 A JP 2006268067A JP 4724634 B2 JP4724634 B2 JP 4724634B2
Authority
JP
Japan
Prior art keywords
packet
header
checksum
reception
fragmented
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2006268067A
Other languages
English (en)
Other versions
JP2008092082A (ja
Inventor
和彦 森村
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Priority to JP2006268067A priority Critical patent/JP4724634B2/ja
Publication of JP2008092082A publication Critical patent/JP2008092082A/ja
Application granted granted Critical
Publication of JP4724634B2 publication Critical patent/JP4724634B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、データ受信装置及びデータ受信方法に関し、IPフラグメントされた複数のIPパケットを受信し再組立するデータ受信装置に関する。
従来、TCP/IP(Transmission Control Protocol/Internet Protcol)やUDP/IP(User Datagram Protocol/Internet Protcol)等のプロトコルを用いたネットワークが利用されている。当該ネットワークの場合、RFC791ではIPレイヤにおける1パケット(Packet)あたりのペイロードを65535オクテット(1オクテット(Octet)=8ビット(bit))まで定義できる仕様となっている。また、IP層の下位層にあたるIEEE802.3で定義されているイーサネット(登録商標)では、1パケットとして送出できる最大送信ユニット(Maximum Transfer Unit:MTU)は1500オクテットとされている。
有限のネットワーク帯域をネットワークに接続されたステーション間で公平にシェアして使用するためには、1パケットのサイズを制限して特定のステーションによる帯域圧迫の影響を避けることが一般的である。
上述したようにIEEE802.3イーサネット(登録商標)においてはMTUは1500オクテット、電話回線によるダイアルアップ接続においてはMTUは576オクテットに設定される場合が多い。また、FDDIにおいてはMTUは4352オクテットに設定され、1Gbps〜10Gbpsのイーサネット(登録商標)においてはMTUを大きく設定して広帯域の優位性を引き出す場合がある。このようにMTUは実装される物理層等によって異なっている。
MTUが1500オクテットのイーサネット(登録商標)ネットワークに属しているステーションAが、ステーションBに1500オクテットのパケットを送出する経路上にMTUが576オクテットのネットワークを介する図9に示すようなパスを構成する。この場合、ネットワークCにデータグラムを送出する際にネットワークを相互に接続するルータがIPパケットを断片化(フラグメント)することにより相互のネットワーク接続を確保する。
図12及び図13は、IPフラグメントを説明する図である。
図9に示すように、ネットワークAに属するホストAとネットワークBに属するホストBとがネットワークCを介して接続され、ネットワークA及びネットワークBのMTUを1500オクテット、ネットワークCのMTUを576オクテットとする。ホストA及びホストBはそれぞれの属するネットワークのMTUが1500オクテットであるため、MTUが1500オクテットのUDP/IPデータグラムを発行している。ホストAがホストBに対してMTUが1500オクテットのTCP(UDP)/IPデータグラムを送出した場合、ルータAはネットワークCにMTUが1500オクテットのIPデータグラムをネットワークCに送付することはできない。このため、図12に示すように3つのIPデータグラムに分割する。
最初にルータAから送出されるIPパケットはUDPヘッダ付のIP長576オクテットである。このIPフラグメントパケットには、後続のIPフラグメントパケットの存在を示すフラグがあり、ルータAはこのフラグの値により、後続フラグメントパケットの存在を示すことができる。IPv4の場合は、Moreフラグメントフラグ(MFフラグ)を‘1’に、IPv6の場合は、Mフラグを‘0’とすることで後続パケットの存在を示すことができる。なお、図12では、IPv4を例にしている。また、IPv4パケットのヘッダには、IPデータグラムに与えられるユニークな識別子(ID:Identification)を格納するフィールドがある。ネットワークの途中でIPデータグラムが断片化、すなわちフラグメントされた場合には、同一のIDをもつフラグメントパケットを再構成することで元のIPデータグラムを再組立することができる。IPv6パケットがフラグメントされる場合は別のフラグメントヘッダがIPv6ヘッダの後に付与される。フラグメント前のIPv6パケットのヘッダには、IPv4ヘッダのようなIDは付与されないが、パケットの断片化を行う装置が元のIPv6パケットにIDを付与し、フラグメントヘッダにIDを格納する。IPv4と同様に、同一のIDをもつフラグメントパケットを再構成することで元のIPデータグラムを再組立することができる。
2番目に送出されるIPパケットは最初に送出されたIPパケットと同じIDが付与され、IP長は同じく最大の576オクテットであり、MFフラグが‘1’で、オフセット値に576という値が付与されている。このオフセット値はフラグメントされたIPパケットの元のIPパケットにおけるアドレスを示している。3番目に送出されるIPパケットはMFフラグを‘0’とすることで、これより後続のIPフラグメントパケットがないことを示しており、オフセット値が1152、IP長は348オクテットとなっている。
上述したように最初から3番目のIPフラグメントパケットは全て同じIDを持っているため元は同一のIPパケットであることが受信側で判定することが可能である。このようにしてルータAにより3つに断片化したIPパケットはネットワークCによりルータBに伝送され、ルータBはホストBにフラグメントされたままの状態のIPパケットを送る。ホストBではフラグメントされたIPパケットをメモリ上に受信し、Moreフラグメントフラグとオフセット値により元のIPパケットを組立てる。ネットワークの状態によっては図13に示すように最終フラグメント(MFフラグが0)のパケットが先に到着したり、データグラムの領域が重複している場合がある。これらのことを考慮してホストBはデータグラムを組み立てなければいけないため、一旦全ての受信フレームをメモリ上に展開し、受信フレーム単位でオフセットアドレスが昇順になるようにソートを実行する。
次に、オフセットが0となっているデータグラムの先頭から、とぎれることなく最終フレームまで組み立てられれば受信完了となる。途中、フラグメントフレームでデータ領域が重複することがあるが、重複領域はどちらかのフレームのデータを無視することで1つのデータグラムを作成する。IPv4においては、このように重複領域が生じるフラグメントを許容しているために、フラグメントオフセットとデータ長の値を検証して再組立する必要がある。IPv6においても経路中でパケットの複製が生じて、複数回同一のフラグメントパケットを受信する可能性もある。
また、IPの上位層であるUDP、TCP、及びICMPではデータグラム全体にわたるチェックサムが求められているので、再組立後にデータグラムを読み込んでインターネットチェックサムの算出を行う。そして、チェックサムによる検証に整合すると全フラグメントパケットによる再組立されたIPデータグラムの受信が完了する。
特開平5−327771号公報
しかしながら、上記IPフラグメント受信方法では以下のような問題点があった。すなわち、複数のIPフラグメントパケットから構成されるTCP又はUDPパケットはヘッダ情報としてチェックサムフィールドを有しており、TCP(UDP)チェックサムの整合性を以て当該パケットの有効性の判定を行っている。このチェックサムを算出するためにはIPヘッダの一部から構成されるIP擬似ヘッダと、TCP(UDP)ヘッダ、そしてペイロードを4オクテット単位での1の補数和、即ちRFC1071で定義されるインターネットチェックサムを算出する必要がある。この算出のために再組立を行ったメモリ上からヘッダ、ペイロード情報を再度読み出して算出していた。また、フラグメントを再組立するために一旦全てのフラグメントパケットを受信して蓄積し、並べ替えを行い、データグラムを再組立するという工程を経るため、IPフラグメントパケットを生じるネットワークにおいては受信性能が著しく劣ってしまう。
本発明の目的は、IPパケットのフラグメント受信による性能低下を低減することにある。
上記目的を達成するために、請求項1記載のデータ受信装置は、メディアアクセスコントロール層より上位のプロトコルを受信するデータ受信装置であって、データリンク層の処理を行うデータリンク層処理手段と、ネットワーク層及びトランスポート層のプロトコル解析を行うプロトコル解析手段と、受信したパケットを保存する受信バッファと、前記受信バッファの前段にパケットのチェックサムを算出するチェックサム算出手段と、前記データリンク層処理手段からの処理情報と前記プロトコル解析手段からの解析情報とから前記断片化されたIPパケットの書き込みアドレス情報を生成するアドレス情報生成手段と、断片化されたIPパケットの受信済領域を管理する管理手段と、断片化されたIPパケットの受信処理において、前記アドレス生成装置が生成したアドレスに基づき前記受信バッファにパケットを書き込む書き込み手段と、を有し、前記チェックサム算出手段は、前記チェックサムの算出を前記管理手段により管理される重複受信済領域を除外して行うことを特徴とする。
請求項7記載のデータ受信方法は、メディアアクセスコントロール層より上位のプロトコルを受信するデータ受信方法であって、データリンク層の処理を行うデータリンク層処理ステップと、ネットワーク層及びトランスポート層のプロトコル解析を行うプロトコル解析ステップと、受信したIPパケットを保存する保存ステップと、前記断片化されたIPパケットのチェックサムを算出するとチェックサム算出ステップと、前記データリンク層処理ステップの処理情報と前記プロトコル解析ステップの解析情報とから前記断片化されたIPパケットの書き込みアドレス情報を生成するアドレス情報生成ステップと、前記断片化されたIPパケットの受信済領域を管理する管理ステップと、受信した断片化されたIPパケットを前記アドレス情報生成ステップで生成した書き込みアドレス情報に基づいて書き込む書き込みステップを有し、前記チェックサム算出ステップは、前記チェックサムの算出を前記管理ステップにより管理される重複受信済領域を除外して行うことを特徴とする。
本発明によれば、IPパケットのフラグメント受信による性能低下を低減することができる。
以下、本発明の実施の形態について図面を参照しながら説明する。
まず、本発明の実施の形態に係るIPフラグメントパケット受信装置を含むデータ受信装置について説明する。
図1は、本発明の実施の形態に係るIPフラグメントパケット受信装置を含むデータ受信装置100の構成を概略的に示すブロック図である。
MAC(Media Access Controller)受信装置101は、PHY(図示しない)からの信号を受信し、イーサネット(登録商標)パケットを送出する。MAC/De−Framer102は、MAC受信装置101からイーサネット(登録商標)パケットを受信し、MACヘッダのタイプフィールドを解析し、MACヘッダを取り除く。ARP受信キュー103は、ARP(アドレス解決プロトコル)の受信時にARPパケットを蓄積し且つコマンドの解析を行う。TCP(UDP)/IP/De−Framer104は、TCP(UDP)/IPパケットのフレームを受信し、ヘッダ情報を各プロトコルの解析装置に送出すると共に、パケット情報を送出する。
チェックサム算出装置110は、複数のIP識別に対応する。タイマ装置111は、各IP/IDに対応する。デリミタチェッカ113は、IPフラグメントパケットを受信した場合、フラグメントされた受信領域を確認し且つフラグメントパケットの受信終了を検出する。タイマ装置114は、複数のIP/IDが異なるフラグメントに対応する。アドレス生成装置115は、受信したパケットの書き込みアドレスを生成する。受信パケットフィルタ116は、受信したパケットバッファ上のパケットを受信バッファに書き込み、判定を行う。MACヘッダ受信解析装置105は、MAC/De−Framer102から送られたMACヘッダを解析する。IPv4ヘッダ受信解析装置106、IPv6ヘッダ受信解析装置107、UDPヘッダ受信解析装置108、TCPヘッダ受信解析装置109は、夫々、IPv4ヘッダ、IPv6ヘッダ、UDPヘッダ、TCPヘッダを解析する。TCP(UDP)チェックサム算出装置112は、ペイロード部と疑似ヘッダ部のチェックサム判定を行う。受信パケットバッファ117は、チェックサム算出装置110を通過したパケットを蓄積する。受信バッファ118は、フラグメントされた複数のパケットを組み立てたパケットが書き込まれる。
まず、フラグメントされていないパケットの受信の際の動作について説明する。
PHY(図示しない)で受信したイーサネット(登録商標)パケットはMAC受信装置101に入力され、FCS(Frame Check Sequence)によりフレームが検証される。MAC受信装置101では算出したFCSとパケットの末尾について送られてきたFCSとを比較し、同じ値であれば後段のMAC/De−Framer102に入力され、異なる値であれば受信パケットは壊れたものとして廃棄する。
MAC/De−Framer102は図4に示すイーサネット(登録商標)ヘッダについて解析を行う。イーサネット(登録商標)ヘッダではデータリンク層における解析を行うことができる。
図4は、IEEE802.3のイーサネット(登録商標)におけるMACフレームフォーマットを説明する図である。
図4に示すフォーマットにおいて、MTUが定義している長さとはMACヘッダが示すペイロードであるMACクライアントデータにPAD(パディング)を加えたものであり、その長さは最小で46オクテット、最大で1500オクテットとしている。ペイロードにはMACヘッダがその先頭に付与され、さらにその先頭にキャリア検出用のプリアンブルとSFD(フレーム開始検出用のスタートフレームデリミタ)が付き、末端にFCS(Frame Check Sequence)が4オクテット付与される。FCSはプリアンブル、SFD、FCS、及びEXTENSIONを除いたソースアドレスからパディングまでを対象に4オクテットの巡回助長検査を施した符号で、算出の対象となった領域における誤り検出を行うことができる。
MACヘッダは、宛先MACアドレス、送信元MACアドレス、Length/Typeの3つのフィールドから構成されている。MACアドレスは先頭の3オクテットはベンダコードと呼ばれ、製造元を認識するコードで、末尾3オクテットは製品毎に固有の番号として割り振られる。
続いてLength/Typeフィールドは、図4に示したように値によってLengthとして使用される場合と、Typeとして用いられる場合がある。MAC/De−Framer102は、Lengthとして用いられるパケットを受信した場合は、後続のデータグラムのプロトコルの解析を停止し、そのまま受信バッファに送る処理を行う。この動作の詳細は後述する。Type=0x0806の場合はARP(Address Resolution Protocol)であるため、受信したパケットはARP受信キュー103に送られる。ARP受信キュー103に送られたパケットはarpパケット内のコマンドを解析し、“reply”コマンド或いは“response”コマンドを受信した旨を通知する。
一方、MAC/De−Framer102に送られたパケットが0x0800=IPv4或いは0x86dd=IPv6のTypeフィールドであった場合はイーサネット(登録商標)ヘッダの上位層がIPv4ヘッダ、IPv6ヘッダであることを示している。この場合、MAC/De−Framer102は、受信したパケットのイーサネット(登録商標)ヘッダを取り除いた上で後段のTCP(UDP)/IP/De−Framer104に送出し、取り除いたイーサネット(登録商標)ヘッダはMACヘッダ受信解析装置105に送出する。
TCP(UDP)/IP/De−Framer104ではIPヘッダ以降の各層のヘッダを各ヘッダ解析器に入力し、IPヘッダ以降のパケットを後段のチェックサム算出装置110に送出する。まず、TCP(UDP)/IP/De−Framer104はMACヘッダ受信解析装置105が解析した結果に基づき、IPv4パケット、IPv6パケット若しくはそれ以外のパケットであるかを判定する。IPパケットでない場合はそれ以上の解析は行わずに後段に送出される。
TCP(UDP)/IP/De−Framer104は受信したパケットがIPv4パケットの場合は、IPv4ヘッダ受信解析装置106にヘッダ部分を送出する。
図5は、MAC層の上位層に位置するIP層におけるIPv4ヘッダフォーマットを説明する図である。
IPv4ヘッダは最小で20オクテットで構成され、必要に応じてオプションが付加される。オプションが32オクテット単位にならなければパディングが加えられて32オクテット単位に揃えられる。IPヘッダの先頭にはバージョンを示す4ビットのフィールドがあり、IPv4の場合は“0100=4”が示される。続いて4ビットのヘッダ長が4オクテット単位で示される。一般的にIPv4ではオプションが用いられることは少ないためここでは最小のヘッダ長である20オクテットが示される。4オクテット単位で表現するため“0101”が与えられる。オプションが付加された場合IPv4の最大ヘッダ長はヘッダ長フィールドが“1111”になった場合の60オクテットとなる。
続いて、Type Of ServiceフィールドにはIETFのRFC1340やRFC1349等で示されるようにそのパケットがネットワーク上でどのようなサービスを受けるべきかが示される。次に、全データ長には自身のIPヘッダを含んだIPパケットの全長が示される。当該全データ長は16ビットで表現されていることからIPデータグラムの最大長は65535オクテットということになる。IdentificationはIPデータグラムに与えられるユニークなIDである。ネットワークの途中でIPデータグラムが断片化、すなわちフラグメントされた場合に同一のIDをもつフラグメントパケットを再構成することで元のIPデータグラムを再組立することができる。フラグ、及びフラグメントオフセットは経路上においてIPをフラグメントする場合に用いるフィールドである。Time To Liveフィールドはデータが通過することができるルータ数の限界を示す。プロトコルフィールドはIPパケットの上層に位置するプロトコル種別を示している。また、ヘッダチェックサムにはIPヘッダ部分のみのインターネットチェックサムが与えられる。そして、送出元IPアドレス、宛先IPアドレスが各々示され、IPヘッダが構成される。
また、TCP(UDP)/IP/De−Framer104は受信したパケットがIPv6パケットの場合はIPV6ヘッダが32オクテットであることが予め決められているので32オクテットのみをIPv6ヘッダ受信解析装置107に送出する。
図6のIPv6ヘッダフォーマットを示す。図6(A)は、IPv6ヘッダフォーマットを説明する図であり、図6(B)は、フラグメントヘッダフォーマットを説明する図である。
図6(A)に示すように、IPv6のヘッダフォーマットは上述したIPv4のヘッダフォーマットと比較するといくらか単純化されている。先頭に4ビットのバージョン番号があり、バージョンは‘6’なので“0110=6”が与えられる。トラフィッククラスはQoS(Quality of Service)のための優先度の識別に用いられる。フローラベルはルータ制御を要求するラベル付けのためのフィールドである。
ペイロード長は、IPv4と異なりペイロード長がIPヘッダを含まずIPv6の拡張ヘッダ長さを含む。Next Headerは、IPv6ヘッダに続くヘッダのタイプを示している。IPv6における拡張ヘッダの他、UDPやTCPが続く場合においても、このNext Headerで識別することができる。Hop Limitは、IPv4におけるTime To Liveに相当し、ルータ越えの制限を示す。但し、Hop Limitの値としての255は特別な値でルータ越えが禁止されていることを示す。そして、送信元のアドレスと宛先のアドレスとが各々128ビットで与えられる。
フラグメントされる場合は別のフラグメントヘッダがIPv6ヘッダの後に付与される。IPv4の場合と同様にフラグメントオフセットは断片化データのオフセット値を示しており、Mフラグはフラグメントされた最後のデータグラムであるかを示している。Mフラグが‘0’であれば後続のフラグメントデータがあることを示しており、‘1’であれば最終のフラグメントデータグラムであることを示している。そして、フラグメントヘッダの最後にID(Identification)が付与される。使用方法はIPv4の場合と同一であるが、元のIPv6ヘッダにIDが付与されていないので断片化を行う送信元、若しくはルータが使用されていないIDを選択して決定する必要がある。
IPパケットのペイロードの構成はIPv4であればプロトコルフィールド、IPv6の場合はNext HeaderフィールドにTCP若しくはUDPプロトコルであることが記されている。TCP(UDP)/IP/De−Framer104は、TCPが続く場合はTCPヘッダ(図7(B))のヘッダデータ長フィールドからヘッダ長を読み出し、TCPヘッダをTCPヘッダ受信解析装置109に入力する。UDPの場合はUDPヘッダが8オクテットに限定されているので(図7(A))IPヘッダに続く8オクテットをUDPヘッダ受信解析装置108に入力する。
一方、IPヘッダ以降のペイロードはチェックサム算出装置110でペイロードチェックサムの算出を行うとともに受信パケットバッファ117に蓄積される。IPヘッダの部分はペイロードチェックサムから除外されるため、TCP、若しくはUDPヘッダ以降のペイロードを含む全パケットに渡り4オクテット毎のチェックサムが算出される。IPヘッダ部のチェックサムはIPv4で用いるヘッダチェックサムの他、TCP(UDP)等のトランスポート層のチェックサムの算出に必要な擬似ヘッダを作成してチェックサムを算出する必要がある。
図8(A)は、IPv4における疑似ヘッダのフォーマットを説明する図であり、図8(B)は、IPv6における疑似ヘッダのフォーマットを説明する図である。
IPv4、IPv6の疑似ヘッダはネットワーク層であるIPv4ヘッダ、IPv6ヘッダの情報を元に作成される。そのため、各受信解析装置にヘッダが入力される際にこれらの疑似ヘッダのチェックサムを算出し、トランスポート層のチェックサムであるTCP(UDP)チェックサム算出装置112へ入力する。TCP(UDP)チェックサム算出装置112においてペイロード部と疑似ヘッダ部のチェックサムがOK/NGの判定を受信パケットフィルタ116に入力する。受信パケットフィルタ116には他にもIPv4のヘッダチェックサム等の情報が集められ、受信バッファに送出するパケットかどうかの判断を行う。一方、IPv4ヘッダの全データ長、又はIPv6ヘッダのペイロード長フィールドより受信パケット全体の長さが算出され、アドレス生成装置115に入力される。また、アドレス生成装置115には事前に受信バッファエリア情報としてパケットが受信されるバッファのアドレス情報が入力されている。アドレス生成装置115は、この受信パケット長とアドレス情報を元に受信バッファ118に書き込みアドレスを出力する。それに同期して受信パケットバッファから受信パケット情報を受信バッファに書き込むことができる。以上のように動作することでネットワーク層とトランスポート層とからなるパケットの受信が行われる。
次に、IPフラグメントされた複数のパケット受信の際の動作について説明する。
上記のようにIPフラグメントされていた場合はIPヘッダのフィールドの内、IPv4であれば“フラグ(Flags)”フィールド、IPv6の場合は“Next Header”がフラグメントを示していた場合IPフラグメントであることが判断される。IPフラグメントパケットであるときは、IPv4ヘッダ受信解析装置106或いはIPv6ヘッダ受信解析装置107においてフラグメント情報としてオフセットアドレスとデータ長情報がデリミタチェッカ113にIPヘッダの識別情報と共に入力される。オフセットアドレスはIPv4のフラグメントオフセットフィールドから、IPv6であればフラグメントヘッダのフラグメントオフセットフィールドから参照される。データ長情報はIPv4であれば全データ長、IPv6であればペイロード長から参照される。このようにして入力されたデリミタ情報はフラグメントパケットの受信領域が示されている。
図2は、図1におけるデリミタチェッカ113の構成を概略的に示すブロック図である。
図2において、デリミタチェッカ113は、シフトレジスタ201と、デリミタ入力レジスタ202と、比較器203と、重複受信領域出力レジスタ204と、最終受信ポインタ保存メモリ205とを備える。また、デリミタチェッカ113は、受信開始ポインタレジスタ206と、受信終了ポインタレジスタ207と、比較器208と、フラグメント受信完了判断装置209とを備える。
次に、上述したデリミタチェッカ113の詳細な動作について説明する。
まず、IPヘッダにおける全データ長(又はIPv6におけるペイロード長+IPヘッダ長)とフラグメントオフセット情報に基づいて、フラグメント全体におけるフラグメントパケットの位置情報を算出する。デリミタの下位(図2におけるPointer−i)はフラグメントオフセットフィールドを参照することにより与えられる。他方のデリミタの上位(図2におけるPointer−j)はフラグメントオフセット+ペイロード長を算出することにより与えられる。このようにして第1のデリミタがデリミタ入力レジスタ202に入力されると、まず、シフトレジスタ201にデリミタが入力される。入力されたデリミタは比較器208で比較されるが、フラグメント受信が完了していないのでフラグメント受信完了判断装置209からはフラグメント受信完了通知は出力されない。
続いて、第2のフラグメントパケットを受信し、次いで第2のデリミタがデリミタ入力レジスタ202に入力されると、同じIPIDであることを検知した上で先に入力した第1のデリミタとの比較が比較器203において実行される。この比較において、受信領域の重複が検出された場合(図3(E)〜(I))は重複受信領域出力レジスタ204より重複領域が出力される。また、受信領域の書き込み結合が行われ、受信開始ポインタレジスタ206及び受信終了ポインタレジスタ207の比較が行われフラグメント受信完了の通知が行われる。
一方、入力したデリミタのうち、Moreフラグメントフラグが立っておらず、フラグメントオフセットに有意の値が入っているフラグメントパケットから算出したPointer−jの値をEnd−Pointerとして最終受信ポインタ保存メモリ205に入力する。以降、複数のフラグメントパケットを受信し、シフトレジスタ201の値が図3(J)に示すような最終状態になった場合にフラグメント受信完了判断装置209よりフラグメント受信完了通知が出力される。また、この際に受信終了ポインタレジスタ207にある値がフラグメント再組立後のIPパケット長となるため、このレジスタ値も同時に出力する。
デリミタチェッカ113がフラグメント受信の際に上述のように動作することにより重複受信領域があるフラグメントパケットを受信するとチェックサム算出装置110に重複領域を通知する。そのため、フラグメントを再組立した状態におけるペイロード部のチェックサムの算出が可能となる。チェックサム算出装置110は複数備えられ、同時にいくつものIPフラグメントの組立が可能となっている。もし、ネットワーク経路上で一部のフラグメントパケットが大きく遅延した場合、タイマ装置111、114により時間を監視し、一定以上の時間遅延に関してはパケットを喪失したものとして同じIP識別を持つパケットを全て放棄する。これは受信バッファ118、チェックサム算出器、デリミタチェッカ等のリソースを長期間使用させないようにするためである。
フラグメント組立用のタイマを60秒に設定したとすると、最後のIPフラグメントパケットを受信してから60秒を経過するとそれまで受信したフラグメントパケットを全て廃棄する。チェックサム算出装置110を通過したパケットは受信パケットバッファ117に蓄積され、IPヘッダチェックサムの可否判断を行い整合性があれば受信バッファ118へ蓄積される。このときのアドレス情報は予め設定された受信バッファ領域情報をアドレス生成装置115に入力し、さらにデリミタチェッカ113に与えられたデリミタ情報を元に書き込みアドレスを決定する。このようにして決められたアドレスにIPフラグメントパケットを書き込むことにより受信バッファ118にはペイロードが直接組み立てられる。
このようにして全てのフラグメントの受信が完了すると、デリミタチェッカ113によりフラグメント受信完了通知が出力され、受信バッファ118にはTCPヘッダ以降の全てのペイロード、そして先頭フラグメントにおけるIPヘッダが書き込まれている。このときのIPヘッダのフィールド内の全データ長のみが再組立後のIPパケットに対するヘッダ値として誤っている。従って、デリミタチェッカ113より出力されたペイロード長からIPv4であれば全データ長を算出し、IPv6であればそのままペイロード長として全データ長として書き換える。このようにして再組立されたパケットの内、TCP(UDP)ヘッダにおけるチェックサムの検証を行うためにIPヘッダとTCP(UDP)ヘッダのみを再度ヘッダ解析装置に送出する。この際に再送出されるのはIPヘッダ部のみであるのでパケット全体と比較するとごく少量であることを類推することは難しくない。再送出されたヘッダ情報はIPヘッダ解析装置においては疑似ヘッダ部のチェックサムの算出を行い、TCP(UDP)チェックサム装置112に入力される。それと同時に同じIP識別から算出されたチェックサムをチェックサム算出装置110からTCP(UDP)チェックサム装置112に入力し、ヘッダ部とペイロード部の最終的なチェックサムの検査が終了する。この結果は受信パケットフィルタ116を通して受信されたIPフラグメントパケットの整合性の結果として出力される。
上述したように、本実施の形態によれば、フラグメントされたIPパケットの受信において、IPフラグメントパケットの受信と同時に受信領域を確認しながらペイロード部のチェックサム及びIPパケットの再組立を行う。そして、全てのフラグメントパケット受信完了を検出するとIPヘッダによる疑似ヘッダを作成し、疑似ヘッダのチェックサムを算出し、先のペイロード部のチェックサムと疑似ヘッダのチェックサムからトランスポート層のチェックサムによる検証を行う。このようにすることで、フラグメントパケット受信から再組立パケットの検証まで完了する時間を短縮でき、高速に処理することができる。
また、本発明の目的は、以下の処理を実行することによって達成される。即ち、上述した実施の形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ(またはCPUやMPU等)が記憶媒体に格納されたプログラムコードを読み出す処理である。
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施の形態の機能を実現することになり、そのプログラムコード及び該プログラムコードを記憶した記憶媒体は本発明を構成することになる。
また、プログラムコードを供給するための記憶媒体としては、次のものを用いることができる。例えば、フロッピー(登録商標)ディスク、ハードディスク、光磁気ディスク、CD−ROM、CD−R、CD−RW、DVD−ROM、DVD−RAM、DVD−RW、DVD+RW、磁気テープ、不揮発性のメモリカード、ROM等である。または、プログラムコードをネットワークを介してダウンロードしてもよい。
また、コンピュータが読み出したプログラムコードを実行することにより、上記実施の形態の機能が実現される場合も本発明に含まれる。加えて、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているOS(オペレーティングシステム)等が実際の処理の一部または全部を行い、その処理によって前述した実施の形態の機能が実現される場合も含まれる。
更に、前述した実施の形態の機能が以下の処理によって実現される場合も本発明に含まれる。即ち、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPU等が実際の処理の一部または全部を行う場合である。
本発明の実施の形態に係るIPフラグメントパケット受信装置を含むデータ受信装置の構成を概略的に示すブロック図である。 図1におけるデリミタチェッカの構成を概略的に示すブロック図である。 図2のデリミタチェッカの動作を説明する図である。 IEEE802.3のイーサネット(登録商標)におけるMACフレームフォーマットを説明する図である。 MAC層の上位層に位置するIP層におけるIPv4ヘッダフォーマットを説明する図である。 (A)は、IPv6ヘッダフォーマットを説明する図であり、(B)は、フラグメントヘッダフォーマットを説明する図である。 (A)は、UDPヘッダフォーマットを説明する図であり、(B)は、TCPヘッダフォーマットを説明する図である。 (A)は、IPv4における疑似ヘッダのフォーマットを説明する図であり、(B)は、IPv6における疑似ヘッダのフォーマットを説明する図である。 IPフラグメントが発生するネットワークの構成の一例を概略的に示すブロック図である。 メモリ上に展開された受信フレームを説明する図である。 メモリ上に展開され、ソートが実行された受信フレームを説明する図である。 IPフラグメントを説明する図である。 IPフラグメントを説明する図である。
符号の説明
100 データ受信装置
101 MAC受信装置
102 MAC/De−Framer
103 ARP受信キュー
104 TCP(UDP)/IP/De−Framer
105 MACヘッダ受信解析装置
106 IPv4ヘッダ受信解析装置
107 IPv6ヘッダ受信解析装置
108 UDPヘッダ受信解析装置
109 TCPヘッダ受信解析装置
110 チェックサム算出装置
111,114 タイマ装置
112 TCP(UDP)チェックサム算出装置
113 デリミタチェッカ
115 アドレス生成装置
116 受信パケットフィルタ
117 受信パケットバッファ
118 受信バッファ
201 シフトレジスタ
202 デリミタ入力レジスタ
203,208 比較器
204 重複受信領域出力レジスタ
205 最終受信ポインタ保存メモリ
206 受信開始ポインタレジスタ
207 受信終了ポインタレジスタ
209 フラグメント受信完了判断装置

Claims (7)

  1. メディアアクセスコントロール層より上位のプロトコルを受信するデータ受信装置であって、
    データリンク層の処理を行うデータリンク層処理手段と、
    ネットワーク層及びトランスポート層のプロトコル解析を行うプロトコル解析手段と、
    受信したパケットを保存する受信バッファと、
    前記受信バッファの前段にパケットのチェックサムを算出するチェックサム算出手段と、
    前記データリンク層処理手段からの処理情報と前記プロトコル解析手段からの解析情報とから前記断片化されたIPパケットの書き込みアドレス情報を生成するアドレス情報生成手段と、
    断片化されたIPパケットの受信済領域を管理する管理手段と、
    断片化されたIPパケットの受信処理において、前記アドレス生成装置が生成したアドレスに基づき前記受信バッファにパケットを書き込む書き込み手段と、を有し、
    前記チェックサム算出手段は、前記チェックサムの算出を前記管理手段により管理される重複受信済領域を除外して行うことを特徴とするデータ受信装置。
  2. さらに、前記断片化されたIPパケットの内、先端若しくは後端のIPパケットから再組立IPパケットの長さを算出する再組立IPパケット長算出手段を備え、
    前記書き込み手段は、前記受信バッファに保存されるIPパケットのIPヘッダの全長フィールドに当該算出された再組立IPパケットの長さを書き込むことを特徴とする請求項1記載のデータ受信装置。
  3. さらに、前記断片化されたIPパケットの内、先端若しくは後端のIPパケットからペイロード部分の長さを算出するペイロード長算出手段を備え、
    前記書き込み手段は、前記受信バッファに保存されるIPヘッダのペイロード長フィールドに当該算出されたペイロード部分の長さを書き込むことを特徴とする請求項1記載のデータ受信装置。
  4. 前記管理手段は、前記断片化されたIPパケットの受信完了を通知する通知手段を備え、
    該通知手段が当該受信完了を通知する場合、前記プロトコル解析手段は当該断片化されたIPパケットを再組立したIPパケットの内、IPヘッダ又はTCPヘッダ若しくはUDPヘッダのチェックサム整合性検証を行うことを特徴とする請求項1乃至3のいずれか1項に記載のデータ受信装置。
  5. 前記チェックサム算出手段は、前記算出したチェックサムの内、ペイロード部のチェックサムを用いて前記トランスポート層のチェックサムの算出を行うことを特徴とする請求項1乃至4のいずれか1項に記載のデータ受信装置。
  6. 前記チェックサム算出格納手段は前記チェックサムの算出をIPヘッダの領域を除外して行うことを特徴とする請求項1乃至5のいずれか1項に記載のデータ受信装置。
  7. メディアアクセスコントロール層より上位のプロトコルを受信するデータ受信方法であって、
    データリンク層の処理を行うデータリンク層処理ステップと、
    ネットワーク層及びトランスポート層のプロトコル解析を行うプロトコル解析ステップと、
    受信したIPパケットを保存する保存ステップと、
    前記断片化されたIPパケットのチェックサムを算出するチェックサム算出ステップと、
    前記データリンク層処理ステップの処理情報と前記プロトコル解析ステップの解析情報とから前記断片化されたIPパケットの書き込みアドレス情報を生成するアドレス情報生成ステップと、
    前記断片化されたIPパケットの受信済領域を管理する管理ステップと、
    受信した断片化されたIPパケットを前記アドレス情報生成ステップで生成した書き込みアドレス情報に基づいて書き込む書き込みステップとを有し、
    前記チェックサム算出ステップは、前記チェックサムの算出を前記管理ステップにより管理される重複受信済領域を除外して行うことを特徴とするデータ受信方法。
JP2006268067A 2006-09-29 2006-09-29 データ受信装置及びデータ受信方法 Expired - Fee Related JP4724634B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2006268067A JP4724634B2 (ja) 2006-09-29 2006-09-29 データ受信装置及びデータ受信方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2006268067A JP4724634B2 (ja) 2006-09-29 2006-09-29 データ受信装置及びデータ受信方法

Publications (2)

Publication Number Publication Date
JP2008092082A JP2008092082A (ja) 2008-04-17
JP4724634B2 true JP4724634B2 (ja) 2011-07-13

Family

ID=39375791

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006268067A Expired - Fee Related JP4724634B2 (ja) 2006-09-29 2006-09-29 データ受信装置及びデータ受信方法

Country Status (1)

Country Link
JP (1) JP4724634B2 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009278364A (ja) 2008-05-14 2009-11-26 Canon Inc パケット受信装置及びその処理方法
JP2010166244A (ja) * 2009-01-14 2010-07-29 Nippon Telegraph & Telephone East Corp パケットロス判定装置及びパケットロス判定方法
JP7423223B2 (ja) * 2019-08-30 2024-01-29 キヤノン株式会社 通信装置

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4156568B2 (ja) * 2004-06-21 2008-09-24 富士通株式会社 通信システムの制御方法、通信制御装置、プログラム
JP4401910B2 (ja) * 2004-09-10 2010-01-20 キヤノン株式会社 データ通信装置及びデータ通信方法
JP4612821B2 (ja) * 2004-09-10 2011-01-12 キヤノン株式会社 通信制御装置及び方法
JP2007215013A (ja) * 2006-02-10 2007-08-23 Canon Inc プロトコル処理装置及びプロトコル処理方法

Also Published As

Publication number Publication date
JP2008092082A (ja) 2008-04-17

Similar Documents

Publication Publication Date Title
KR100910818B1 (ko) 비-macsec 노드들을 통해 macsec 패킷들을터널링하기 위한 방법 및 시스템
US7853691B2 (en) Method and system for securing a network utilizing IPsec and MACsec protocols
US8473632B2 (en) Packet receiving apparatus and processing method for the same
US7286536B2 (en) Method and system for early header compression
US20080101241A1 (en) Ethernet OAM at intermediate nodes in a PBT network
WO2016000513A1 (zh) 更新业务流报文的处理方式的方法及装置
WO2004112326A1 (ja) パケット転送方法及び装置
WO2013044827A1 (zh) 一种跟踪路由测试方法、系统、装置及设备
WO2021088813A1 (zh) 报文封装方法及装置、报文解封装方法及装置
US9961147B2 (en) Communication apparatus, information processor, communication method, and computer-readable storage medium
US7733865B2 (en) Communication apparatus and method
JP4724634B2 (ja) データ受信装置及びデータ受信方法
WO2022142390A1 (zh) 报文封装、解封装方法、装置、存储介质及电子装置
JP5200755B2 (ja) 無線基地局、無線通信システム、パス接続方法およびプログラム
US20090210770A1 (en) Method, system and computer program product for end to end error checking in ethernet
US7436776B2 (en) Communication test device
US20230327983A1 (en) Performance measurement in a segment routing network
WO2014116409A1 (en) Method and system for using extension headers to support protocol stack migration
JP7035771B2 (ja) パケット取得装置、パケット取得方法、およびパケット取得プログラム
US20080320162A1 (en) Method and System for Minimum Frame Size Support for a Communication Protocol Encapsulated Over Ethernet
US8045523B2 (en) Method and apparatus for performing media independent handover
US8010877B2 (en) Communication apparatus, communication control method, and computer product
Templin The Subnetwork Encapsulation and Adaptation Layer (SEAL)
Ekman Automobile Control Systems: Transition from Controller Area Networks to Ethernets
CN111432046A (zh) 一种网络重复地址检测方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20090925

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20110304

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110405

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110411

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140415

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees