(57)【要約】  【課題】  複数のパケットから論理的データストリームを作成する負荷を軽減すること等が可能なＴＣＰ／ＩＰ受信処理回路等を提供する。  【解決手段】  このＴＣＰ／ＩＰ受信処理回路５は、フレーム解析処理部２１と、解析結果データ格納部２２と、ＦＩＦＯバッファメモリ２３と、ＤＭＡ制御部２４と、ＤＭＡ処理部２５とを具備する。フレーム解析処理部２１は、下位レイヤから受け取ったフレームのＣＲＣ検証等を行い、解析結果を解析結果データ格納部２２に書き込むとともに、パケットをＦＩＦＯバッファメモリ２３に書き込む。ＤＭＡ制御部２４は、ＦＩＦＯバッファメモリ２３内のパケットをその宛先である通信端点に対応してメインメモリ９内に形成されたパケット格納領域に転送するように、ＤＭＡ処理部２５を制御する。【選択図】  図１
2006325054.tif 000002
【特許請求の範囲】
【請求項１】
下位レイヤから受け取ったフレームに格納されているパケットを上位レイヤがアクセス可能なメモリに転送するＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）受信処理回路であって、
前記メモリが、所定の通信端点宛ての複数のパケットをそれぞれ格納するための複数のパケット格納領域と、各々が有する第１のポインタによってリンクされている複数のディスクリプタテーブルであって、前記パケット格納領域を指し示すための第２のポインタ及び前記第２のポインタによって指し示される前記パケット格納領域にパケットを書き込むことが可能であるか否かを示すパケット書込み可否情報をそれぞれ有する前記複数のディスクリプタテーブルと、を含む通信端点情報領域を有しており、
下位レイヤから受け取ったフレームに格納されているパケットが前記所定の通信端点宛てのパケットである場合に、前記第１のポインタ及び前記パケット書込み可否情報を利用して前記複数のディスクリプタテーブルの中からパケットを書き込むことが可能な前記パケット格納領域を指し示す１つのディスクリプタテーブルを決定し、下位レイヤから受け取ったフレームに格納されているパケットを当該ディスクリプタテーブル内の前記第２のポインタによって指し示される前記パケット格納領域内に転送する、ＴＣＰ／ＩＰ受信処理回路。
【請求項２】
前記複数のパケット格納領域の各々が、パケットのヘッダを格納するためのヘッダ格納領域と、パケットのペイロードを格納するためのペイロード格納領域と、を含んでおり、
前記第２のポインタが、前記ヘッダ格納領域を指し示す第３のポインタと、前記ペイロード格納領域を指し示す第４のポインタと、を含んでおり、
下位レイヤから受け取ったフレームに格納されているパケットが前記所定の通信端点宛てのパケットである場合に、前記第１のポインタ及び前記パケット書き込み可否情報を利用して前記複数のディスクリプタテーブルの中からパケットを書き込むことが可能な前記パケット格納領域を指し示す１つのディスクリプタテーブルを決定し、下位レイヤから受け取ったフレームに格納されているパケットのヘッダを当該ディスクリプタテーブル内の前記第３のポインタによって指し示される前記ヘッダ格納領域内に転送し、下位レイヤから受け取ったフレームに格納されているパケットのペイロードを当該ディスクリプタテーブル内の前記第４のポインタによって指し示される前記ペイロード格納領域内に転送する、請求項１記載のＴＣＰ／ＩＰ受信処理回路。
【請求項３】
前記複数のパケット格納領域内の前記ペイロード格納領域が、前記メモリ内の連続するアドレスに配置されている、請求項２記載のＴＣＰ／ＩＰ受信処理回路。
【請求項４】
前記複数のディスクリプタテーブルの各々が、前記ヘッダ格納領域に格納可能なヘッダのサイズを表すヘッダ格納領域サイズ情報と、前記ペイロード格納領域に格納可能なペイロードのサイズを表すペイロード格納領域サイズ情報と、を更に含んでおり、
下位レイヤから受け取ったフレームに格納されているパケットが前記所定の通信端点宛てのパケットである場合に、前記第１のポインタ及び前記パケット書き込み可否情報を利用して前記複数のディスクリプタテーブルの中からパケットを書き込むことが可能な前記パケット格納領域を指し示す１つのディスクリプタテーブルを決定し、当該ディスクリプタテーブル内の前記ヘッダ格納領域サイズ情報によって表されるサイズより下位レイヤから受け取ったフレームに格納されているパケットのヘッダのサイズが大きいときに、下位レイヤから受け取ったフレームに格納されているパケットのヘッダの内の当該ディスクリプタテーブル内の前記ヘッダ格納領域に格納可能な部分を当該ディスクリプタテーブル内の前記ヘッダ格納領域に転送し、当該ディスクリプタテーブル内の前記ペイロード格納領域サイズ情報によって表されるサイズより下位レイヤから受け取ったフレームに格納されているパケットのペイロードのサイズが大きいときに、下位レイヤから受け取ったフレームに格納されているパケットのペイロードの内の当該ディスクリプタテーブル内の前記ペイロード格納領域に格納可能な部分を当該ディスクリプタテーブル内の前記ペイロード格納領域に転送する、請求項２又は３記載のＴＣＰ／ＩＰ受信処理回路。
【請求項５】
前記所定の通信端点の論理的データストリームブロックの初期サイズを上位レイヤによって設定可能な減算カウンタを具備し、下位レイヤから受け取ったフレームに格納されているパケットが前記所定の通信端点宛てのパケットである場合に、前記減算カウンタにおいて、下位レイヤから受け取ったフレームに格納されているパケットのペイロードのサイズに相当する値の減算を行い、前記減算カウンタの値が０になったときに、その旨を通知するための制御信号を上位レイヤに出力する、請求項１〜４のいずれか１項記載のＴＣＰ／ＩＰ受信処理装置。
【請求項６】
前記所定の通信端点がＴＣＰ（Transmission Control Protocol）の通信端点である場合に、
前記メモリが、前記所定の通信端点宛てのＲＳＴパケットを格納するためのＲＳＴパケット格納領域と、前記ＲＳＴパケット格納領域を指し示すためのポインタを有するＲＳＴディスクリプタテーブルと、を更に有し、
下位レイヤから受け取ったフレームに格納されているパケットが前記所定の通信端点宛てのＲＳＴパケットである場合に、前記ＲＳＴディスクリプタテーブル内の前記ポインタによって指し示される前記ＲＳＴパケット格納領域内に前記ＲＳＴパケットを転送する、請求項１〜５のいずれか１項記載のＴＣＰ／ＩＰ受信処理回路。
【請求項７】
前記所定の通信端点のシーケンス番号の初期値を上位レイヤによって設定可能な加算カウンタを具備し、下位レイヤから受け取ったフレームに格納されているパケットが前記所定の通信端点宛てのパケットである場合に、当該パケットのＴＣＰヘッダ内のシーケンス番号と前記加算カウンタの値とが一致する場合に、下位レイヤから受け取ったフレームに格納されているパケットを前記メモリに転送するとともに、前記加算カウンタの値をインクリメントする、請求項１〜６のいずれか１項記載のＴＣＰ／ＩＰ受信処理装置。
【請求項８】
前記複数のディスクリプタテーブルの各々が、下位レイヤから受け取ったフレーム又は下位レイヤから受け取ったフレームに格納されているパケットの解析結果を格納するための解析結果格納領域を更に含んでおり、
下位レイヤから受け取ったフレームに格納されているパケットが前記所定の通信端点宛てのパケットである場合に、前記第１のポインタ及び前記パケット書込み可否情報を利用して前記複数のディスクリプタテーブルの中からパケットを書き込むことが可能な前記パケット格納領域を指し示す１つのディスクリプタテーブルを決定し、下位レイヤから受け取ったフレームに格納されているパケットを当該ディスクリプタテーブル内の前記第２のポインタによって指し示される前記パケット格納領域内に転送するとともに、下位レイヤから受け取ったフレーム又は下位レイヤから受け取ったフレームに格納されているパケットの解析結果を当該ディスクリプタテーブル内の前記解析結果格納領域に書き込む、請求項１〜７のいずれか１項記載のＴＣＰ／ＩＰ受信処理回路。
【請求項９】
前記メモリが、複数の通信端点にそれぞれ対応する複数の前記通信端点情報領域を有しており、
下位レイヤから受け取ったフレームに格納されているパケットが前記複数の通信端点のいずれかの通信端点宛てのパケットである場合に、前記複数の通信端点情報領域の中の当該パケットの宛先である通信端点に対応する通信端点情報領域の中のディスクリプタテーブル内で指し示されるパケット格納領域に当該パケットを書き込む、請求項１〜８のいずれか１項記載のＴＣＰ／ＩＰ受信処理回路。
【請求項１０】
前記メモリが、下位レイヤから受け取ったフレームに格納されているパケットのプロトコルが所定のプロトコルでない場合における当該フレーム又は下位レイヤから受け取ったフレームに格納されているパケットが前記複数の通信端点のいずれ宛てでもないパケットである場合における当該パケットを格納するための第２の前記通信端点情報領域を更に有しており、
下位レイヤから受け取ったフレームに格納されているパケットのプロトコルが所定のプロトコルでない場合又は下位レイヤから受け取ったフレームに格納されているパケットが前記複数の通信端点のいずれ宛てでもないパケットである場合に、下位レイヤから受け取ったフレームに格納されているパケットのプロトコルが所定のプロトコルでない場合における当該フレーム又は下位レイヤから受け取ったフレームに格納されているパケットが前記複数の通信端点のいずれ宛てでもないパケットである場合における当該パケットを前記第２の通信端点情報領域の中のディスクリプタテーブル内で指し示されるパケット格納領域に転送する、請求項９記載のＴＣＰ／ＩＰ受信処理回路。
【請求項１１】
請求項１〜１０のいずれか１項記載のＴＣＰ／ＩＰ受信処理回路を具備する半導体集積回路。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）の受信処理を行うためのＴＣＰ／ＩＰ受信処理回路に関する。さらに、本発明は、そのようなＴＣＰ／ＩＰ受信処理回路を具備する半導体集積回路に関する。
【背景技術】
【０００２】
現在、インターネット、ＬＡＮ（Local Area Network）等において、ＴＣＰ／ＩＰと呼ばれる通信プロトコルの階層モデルが広く用いられている。図８は、ＴＣＰ／ＩＰ階層モデルの各レイヤとＩＳＯ（International Organization for Standardization）で制定されたＯＳＩ（Open Systems Interconnection）参照モデルの各レイヤとのおおよその対応関係を示す図である。
【０００３】
ＴＣＰ／ＩＰ階層モデルのネットワークインタフェース層としてはEthernet（登録商標）が、ＴＣＰ／ＩＰ階層モデルのインターネット層としてはＩＰ（Internet Protocol）バージョン４（以下、単に「ＩＰ」という）が、ＴＣＰ／ＩＰ階層モデルのトランスポート層としてはＴＣＰ（Transmission Control Protocol）又はＵＤＰ（User Datagram Protocol）が、広く用いられている。なお、Ethernet（登録商標）は、ＩＥＥＥ８０２．３等に、ＩＰは、ＲＦＣ（Request For Comments）７９１等に、ＴＣＰは、ＲＦＣ７９３等に、ＵＤＰは、ＲＦＣ７６８等に、それぞれ規定されている。
【０００４】
また、ネットワーク管理用のプロトコルとして、ＴＣＰ／ＩＰ階層モデルのインターネット層に相当するＡＲＰ（Address Resolution Protocol）及びＲＡＲＰ（Reverse Address Resolution Protocol）、ＴＣＰ／ＩＰ階層モデルのトランスポート層に相当するＩＣＭＰ（Internet Control Message Protocol）が、広く用いられている。なお、ＡＲＰは、ＲＦＣ８２６等に、ＲＡＲＰは、ＲＦＣ９０３等に、ＩＣＭＰは、ＲＦＣ７９２等に、それぞれ規定されている。
【０００５】
図９は、Ethernet（登録商標）フレーム（以下、単に「フレーム」という）のフォーマットを示す図である。図９に示すように、フレームは、ヘッダと、ペイロードとを有する。なお、フレームが実際にネットワーク上に送信される際には、先頭にプリアンブルが、末尾にＣＲＣ（Cyclic Redundancy Check）を格納したフレームチェックシーケンス（Frame Check Sequence）が、それぞれ付加される。
【０００６】
図１０は、ＩＰパケットのフォーマットを示す図である。図１０に示すように、ＩＰパケットは、ＩＰヘッダと、ＩＰペイロードとを有する。ＩＰパケットは、フレームのペイロード内（図９参照）に格納される。
【０００７】
図１１は、ＡＲＰ、ＲＡＲＰパケットのフォーマットを示す図である。ＡＲＰ、ＲＡＲＰパケットは、フレームのペイロード内（図９参照）に格納される。
【０００８】
図１２は、ＴＣＰパケットのフォーマットを示す図である。図１２に示すように、ＴＣＰパケットは、ＴＣＰヘッダと、ＴＣＰペイロードとを有する。ＴＣＰパケットは、ＩＰパケットのペイロード内（図１０参照）に格納される。
【０００９】
図１３は、ＵＤＰパケットのフォーマットを示す図である。図１３に示すように、ＵＤＰパケットは、ＵＤＰヘッダと、ＵＤＰペイロードとを有する。ＵＤＰパケットは、ＩＰパケットのペイロード内（図１０参照）に格納される。
【００１０】
図１４は、ＩＣＭＰパケットのフォーマットを示す図である。ＩＣＭＰパケットは、ＩＰパケットのペイロード内（図１０参照）に格納される。
【００１１】
従来のＴＣＰ／ＩＰの受信処理においては、ネットワークインタフェース層をハードウェア回路（以下、ＮＩＣ（Network Interface Card）という）で実現し、インターネット層〜アプリケーション層をＣＰＵとソフトウェア（プログラム）で実現する場合が多かった。しかしながら、インターネット層〜アプリケーション層をＣＰＵとソフトウェア（プログラム）で実現する場合、ＣＰＵの負荷が大きいという問題があった。そこで、近年においては、インターネット層及び／又はトランスポート層の一部をハードウェア回路で実現することにより、ＣＰＵの負荷を軽減することが行われるようになってきている。
【００１２】
関連する技術として、下記の特許文献１には、ネットワークアダプタと複数の層を有するプロトコルスタックとを備えたネットワークノードにおいてデータを受信する方法であって、ネットワーク媒体からの着信データパケットを形成するパケットバイトをメモリに転送し、パケットバイトがネットワーク媒体からメモリへ転送される際に着信データパケットの一部を形成するパケットバイトからコードを計算し、該コードをプロトコルスタックに関連するコードチャネルへ転送し、プロトコルスタックの複数の層のうちの第１の層におけるデータパケットから抽出されたデータを受信し、該抽出されたデータをコードチャネルからのコードを使用して検証する、という各ステップを有することを特徴とする方法が掲載されている。
この方法は、パケットがネットワーク媒体からメモリへ転送される際にＴＣＰのチェックサム等を計算することができるものである。
【００１３】
また、下記の特許文献２には、ネットワークに接続され、主記憶装置とネットワークアダプタを有する計算機システムにおいて、ネットワークアダプタによってネットワークから受信されたネットワークパケットを主記憶装置に送る方法であって、(a)ネットワークアダプタによりネットワークパケットのヘッダを主記憶装置中の第1のメモリバッファに置くステップ；(b)ネットワークアダプタによりネットワークパケットに含まれるデータを主記憶装置中の第2のメモリバッファの最初に置くステップを備える方法が掲載されている。
この方法は、着信パケットのヘッダとデータを分離して別々のメモリバッファに入れることができるものである。
【００１４】
ところで、一般に、アプリケーション層において実行されるアプリケーションプログラム（ウェブブラウザプログラム、メールクライアントプログラム等）は、通信端点（ＯＳ（Operating System）上においてＡＰＩ（Application Programming Interface）によって提供される）からパケットを受け取る。この通信端点には、ＯＳによってパケットが供給される。ＯＳは、ＮＩＣからデバイスドライバ（プログラム）経由でパケットを受け取ると、現に存在している通信端点宛てのパケットであるか否かを判定し、現に存在している通信端点宛てのパケットである場合に、パケットを該当する通信端点に供給する。
【００１５】
なお、下記の非特許文献１には、ＩＴＲＯＮにおけるＴＣＰ／ＩＰの通信端点のＡＰＩの仕様が掲載されている。
【００１６】
一般に、ネットワークインタフェース層〜トランスポート層においては、パケットを処理の基本単位としており、通信端点のＡＰＩも、パケットを１つずつアプリケーション層に渡すようにコーディングされている場合が多い。このような場合、アプリケーション層は、通信端点からパケットを１つずつ受け取ることとなる。
【００１７】
しかしながら、アプリケーションプログラムの内部においては、複数のパケットを含む論理的データストリームを処理の基本単位としていることが多い。そのため、アプリケーション層において複数のパケットから論理的データストリームを作成する必要があるが、この作成の負荷は、システム全体で見るとかなり大きなものとなる。
【００１８】
また、ＮＩＣにおいては、ＴＣＰ又はＵＤＰのヘッダ部とＴＣＰ又はＵＤＰのデータ部の分割や、チェックサム検証等が行われている。しかしながら、ＮＩＣによるヘッダ部とデータ部の分割やチェックサム検証等で得られた解析情報が、ＯＳによる現に存在している通信端点宛てのパケットであるか否かの判定において適切に利用されていなかった。
さらに、ＮＩＣ〜ＯＳ又はＡＰＩ〜アプリケーションプログラム（ネットワークインタフェース層〜アプリケーション層）の経路において、フレーム又はパケットのメモリコピーが発生してしまっていた。
【００１９】
【特許文献１】特開平１１−１６８４５１号公報（第１頁、図１）
【特許文献２】特開平６−７８００１号公報（第１頁、図１）
【非特許文献１】Ｅｍｂｅｄｄｅｄ  ＴＣＰ／ＩＰ技術委員会（高田  広章  編）、“ＩＴＲＯＮ  ＴＣＰ／ＩＰ  ＡＰＩ仕様  Ver.1.00.01”、[online]、１９９８年５月１９日、（社）トロン協会  ＩＴＲＯＮ専門委員会、[平成１７年４月１３日検索]、インターネット＜ＵＲＬ：http://www.assoc.tron.org/spec/itron/tcpip-100j.pdf＞
【発明の開示】
【発明が解決しようとする課題】
【００２０】
そこで、上記の点に鑑み、本発明は、複数のパケットから論理的データストリームを作成する負荷を軽減すること等が可能なＴＣＰ／ＩＰ受信処理回路を提供することを目的とする。また、本発明はそのようなＴＣＰ／ＩＰ受信処理回路を具備する半導体集積回路を提供することを更なる目的とする。
【課題を解決するための手段】
【００２１】
以上の課題を解決するため、本発明に係るＴＣＰ／ＩＰ受信処理回路は、下位レイヤから受け取ったフレームに格納されているパケットを上位レイヤがアクセス可能なメモリに転送するＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）受信処理回路であって、メモリが、所定の通信端点宛ての複数のパケットをそれぞれ格納するための複数のパケット格納領域と、各々が有する第１のポインタによってリンクされている複数のディスクリプタテーブルであって、パケット格納領域を指し示すための第２のポインタ及び第２のポインタによって指し示されるパケット格納領域にパケットを書き込むことが可能であるか否かを示すパケット書込み可否情報をそれぞれ有する複数のディスクリプタテーブルと、を含む通信端点情報領域を有しており、下位レイヤから受け取ったフレームに格納されているパケットが所定の通信端点宛てのパケットである場合に、第１のポインタ及びパケット書込み可否情報を利用して複数のディスクリプタテーブルの中からパケットを書き込むことが可能なパケット格納領域を指し示す１つのディスクリプタテーブルを決定し、下位レイヤから受け取ったフレームに格納されているパケットを当該ディスクリプタテーブル内の第２のポインタによって指し示されるパケット格納領域内に転送する。
【００２２】
このＴＣＰ／ＩＰ受信処理回路において、複数のパケット格納領域の各々が、パケットのヘッダを格納するためのヘッダ格納領域と、パケットのペイロードを格納するためのペイロード格納領域と、を含んでおり、第２のポインタが、ヘッダ格納領域を指し示す第３のポインタと、ペイロード格納領域を指し示す第４のポインタと、を含んでおり、下位レイヤから受け取ったフレームに格納されているパケットが所定の通信端点宛てのパケットである場合に、第１のポインタ及びパケット書き込み可否情報を利用して複数のディスクリプタテーブルの中からパケットを書き込むことが可能なパケット格納領域を指し示す１つのディスクリプタテーブルを決定し、下位レイヤから受け取ったフレームに格納されているパケットのヘッダを当該ディスクリプタテーブル内の第３のポインタによって指し示されるヘッダ格納領域内に転送し、下位レイヤから受け取ったフレームに格納されているパケットのペイロードを当該ディスクリプタテーブル内の第４のポインタによって指し示されるペイロード格納領域内に転送するようにしても良い。
【００２３】
また、複数のパケット格納領域内のペイロード格納領域が、メモリ内の連続するアドレスに配置されているようにしても良い。
【００２４】
また、複数のディスクリプタテーブルの各々が、ヘッダ格納領域に格納可能なヘッダのサイズを表すヘッダ格納領域サイズ情報と、ペイロード格納領域に格納可能なペイロードのサイズを表すペイロード格納領域サイズ情報と、を更に含んでおり、下位レイヤから受け取ったフレームに格納されているパケットが所定の通信端点宛てのパケットである場合に、第１のポインタ及びパケット書き込み可否情報を利用して複数のディスクリプタテーブルの中からパケットを書き込むことが可能なパケット格納領域を指し示す１つのディスクリプタテーブルを決定し、当該ディスクリプタテーブル内のヘッダ格納領域サイズ情報によって表されるサイズより下位レイヤから受け取ったフレームに格納されているパケットのヘッダのサイズが大きいときに、下位レイヤから受け取ったフレームに格納されているパケットのヘッダの内の当該ディスクリプタテーブル内のヘッダ格納領域に格納可能な部分を当該ディスクリプタテーブル内のヘッダ格納領域に転送し、当該ディスクリプタテーブル内のペイロード格納領域サイズ情報によって表されるサイズより下位レイヤから受け取ったフレームに格納されているパケットのペイロードのサイズが大きいときに、下位レイヤから受け取ったフレームに格納されているパケットのペイロードの内の当該ディスクリプタテーブル内のペイロード格納領域に格納可能な部分を当該ディスクリプタテーブル内のペイロード格納領域に転送するようにしても良い。
【００２５】
また、所定の通信端点の論理的データストリームブロックの初期サイズを上位レイヤによって設定可能な減算カウンタを具備し、下位レイヤから受け取ったフレームに格納されているパケットが所定の通信端点宛てのパケットである場合に、減算カウンタにおいて、下位レイヤから受け取ったフレームに格納されているパケットのペイロードのサイズに相当する値の減算を行い、減算カウンタの値が０になったときに、その旨を通知するための制御信号を上位レイヤに出力するようにしても良い。
【００２６】
また、所定の通信端点がＴＣＰ（Transmission Control Protocol）の通信端点である場合に、メモリが、所定の通信端点宛てのＲＳＴパケットを格納するためのＲＳＴパケット格納領域と、ＲＳＴパケット格納領域を指し示すためのポインタを有するＲＳＴディスクリプタテーブルと、を更に有し、下位レイヤから受け取ったフレームに格納されているパケットが所定の通信端点宛てのＲＳＴパケットである場合に、ＲＳＴディスクリプタテーブル内のポインタによって指し示されるＲＳＴパケット格納領域内にＲＳＴパケットを転送するようにしても良い。
【００２７】
また、所定の通信端点のシーケンス番号の初期値を上位レイヤによって設定可能な加算カウンタを具備し、下位レイヤから受け取ったフレームに格納されているパケットが所定の通信端点宛てのパケットである場合に、当該パケットのＴＣＰヘッダ内のシーケンス番号と加算カウンタの値とが一致する場合に、下位レイヤから受け取ったフレームに格納されているパケットをメモリに転送するとともに、加算カウンタの値をインクリメントするようにしても良い。
【００２８】
また、複数のディスクリプタテーブルの各々が、下位レイヤから受け取ったフレーム又は下位レイヤから受け取ったフレームに格納されているパケットの解析結果を格納するための解析結果格納領域を更に含んでおり、下位レイヤから受け取ったフレームに格納されているパケットが所定の通信端点宛てのパケットである場合に、第１のポインタ及びパケット書込み可否情報を利用して複数のディスクリプタテーブルの中からパケットを書き込むことが可能なパケット格納領域を指し示す１つのディスクリプタテーブルを決定し、下位レイヤから受け取ったフレームに格納されているパケットを当該ディスクリプタテーブル内の第２のポインタによって指し示されるパケット格納領域内に転送するとともに、下位レイヤから受け取ったフレーム又は下位レイヤから受け取ったフレームに格納されているパケットの解析結果を当該ディスクリプタテーブル内の解析結果格納領域に書き込むようにしても良い。
【００２９】
また、メモリが、複数の通信端点にそれぞれ対応する複数の通信端点情報領域を有しており、下位レイヤから受け取ったフレームに格納されているパケットが複数の通信端点のいずれかの通信端点宛てのパケットである場合に、複数の通信端点情報領域の中の当該パケットの宛先である通信端点に対応する通信端点情報領域の中のディスクリプタテーブル内で指し示されるパケット格納領域に当該パケットを書き込むようにしても良い。
【００３０】
また、メモリが、下位レイヤから受け取ったフレームに格納されているパケットのプロトコルが所定のプロトコルでない場合における当該フレーム又は下位レイヤから受け取ったフレームに格納されているパケットが複数の通信端点のいずれ宛てでもないパケットである場合における当該パケットを格納するための第２の通信端点情報領域を更に有しており、下位レイヤから受け取ったフレームに格納されているパケットのプロトコルが所定のプロトコルでない場合又は下位レイヤから受け取ったフレームに格納されているパケットが複数の通信端点のいずれ宛てでもないパケットである場合に、下位レイヤから受け取ったフレームに格納されているパケットのプロトコルが所定のプロトコルでない場合における当該フレーム又は下位レイヤから受け取ったフレームに格納されているパケットが複数の通信端点のいずれ宛てでもないパケットである場合における当該パケットを第２の通信端点情報領域の中のディスクリプタテーブル内で指し示されるパケット格納領域に転送するようにしても良い。
【００３１】
また、本発明に係る半導体集積回路は、本発明に係るＴＣＰ／ＩＰ受信処理回路を具備する。
【発明を実施するための最良の形態】
【００３２】
以下、図面を参照しながら、本発明の実施の形態について説明する。なお、同一の構成要素については、同一の参照番号で示している。
図１は、本発明の一実施形態としてのＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）受信処理回路を用いたコンピュータの概要を示すブロック図である。このコンピュータ１は、ネットワークＮに接続された物理層処理回路（ＰＨＹ）２と、ＭＡＣ（Media Access Control）処理回路３と、ＭＡＣブリッジ回路４と、本発明の一実施形態としてのＴＣＰ／ＩＰ受信処理回路５と、ＴＣＰ／ＩＰ送信処理回路６と、インタフェース回路７と、ＣＰＵ８と、メインメモリ９と、ＨＤＤ（ハードディスクドライブ）１０と、入力部１１と、表示部１２とを具備する。
【００３３】
本実施形態においては、ＴＣＰ／ＩＰ階層モデルのネットワークインタフェース層がEthernet（登録商標）であるものとし、物理層処理回路２、ＭＡＣ処理回路３、及び、ＭＡＣブリッジ回路４が、ネットワークインタフェース層を担うものとする。物理層処理回路２は、ネットワークＮに接続されており、ＭＡＣ処理回路３は、物理層処理回路２に接続されており、ＭＡＣブリッジ回路４は、ＭＡＣ処理回路３に接続されている。
【００３４】
また、ＴＣＰ／ＩＰ受信処理回路５、ＴＣＰ／ＩＰ送信処理回路６、及び、インタフェース回路７が、インターネット層及びトランスポート層の一部を担うものとする。ＴＣＰ／ＩＰ受信処理回路５及びＴＣＰ／ＩＰ送信処理回路６は、ＭＡＣブリッジ回路４とインタフェース回路７との間にそれぞれ接続されている。
【００３５】
また、ＣＰＵ８、メインメモリ９、ＨＤＤ１０、入力部１１、及び、表示部１２が、ＴＣＰ／ＩＰ階層モデルのインターネット層及びトランスポート層の一部とアプリケーション層を担うものとする。例えば、ＨＤＤ１０には、ＯＳ（オペレーティングシステム）、ＡＰＩ（Application Programming Interface）プログラム、メールクライアントプログラム、ウェブブラウザプログラム等が記録されており、ＣＰＵ８は、メインメモリ９を作業領域として使用しながら、これらのプログラムを実行する。ＣＰＵ８、メインメモリ９、ＨＤＤ１０、入力部１１、及び、表示部１２は、バスＢを介して接続されており、バスＢは、インタフェース回路７に接続されている。
【００３６】
ＴＣＰ／ＩＰ受信処理回路５は、フレーム解析処理部２１と、解析結果データ格納部２２と、ＦＩＦＯ（First-In First-Out）バッファメモリ２３と、ＤＭＡ（Direct Memory Access）制御部２４と、ＤＭＡ処理部２５とを具備する。ＤＭＡ制御部２４は、ＣＰＵ８のＩ／Ｏアドレス空間にマッピングされた複数のレジスタを有する。
【００３７】
図２は、ＤＭＡ制御部２４内の複数のレジスタ及びメインメモリ９の内容の一例を示す図である。
アプリケーション層において通信端点を開設するためのＡＰＩがコールされると、開設された通信端点に対応する１群の領域が、ＡＰＩによりメインメモリ９内に形成される。図２においては、通信端点Ａ（ここでは、プロトコル  ＴＣＰ（Transmission Control Protocol）、自ＩＰアドレス  １９２．１６８．０．１、自ポート番号  ８０、相手ＩＰアドレス  １９２．１６８．０．２、相手ポート番号  ８０とする）に対応する第１群の領域と、通信端点Ｂ（ここでは、プロトコル  ＵＤＰ（User Datagram Protocol）、自ＩＰアドレス  １９２．１６８．０．１、自ポート番号  ６９、相手ＩＰアドレス  １９２．１６８．０．３、相手ポート番号  ６９とする）に対応する第２群の領域が示されている。
【００３８】
第１群の領域は、通信端点Ａ宛てのパケットをそれぞれ格納するための複数のパケット格納領域３１〜３ｍを含んでいる。パケット格納領域３１〜３ｍは、ヘッダ格納領域３１ａ〜３ｍａ及びペイロード格納領域３１ｂ〜３ｍｂをそれぞれ含んでいる。また、第１群の領域は、ヘッダ格納領域３１ａ〜３ｍａ及びペイロード格納領域３１ｂ〜３ｍｂへのポインタをそれぞれ有するディスクリプタテーブル４１〜４ｍを更に含んでいる。
【００３９】
図３は、ディスクリプタテーブル４１〜４ｍのフォーマットを示す図である。図３に示すように、ディスクリプタテーブル４１〜４ｍは、６ワード（本実施形態においては、１ワードは３２ビット幅とする）で構成されている。第１番目のワードは、当該ディスクリプタテーブルによって指し示されるパケット格納領域へのパケット書込みの可否に関する情報を格納するためのパケット書込み可否情報格納領域を含んでいる。パケット書込み可否情報格納領域は、当該ディスクリプタテーブルによって指し示されるパケット格納領域内にパケットが格納されているか否かを示す情報を格納するためのReceivedフィールド、及び当該ディスクリプタテーブルによって指し示されるパケット格納領域が使用可能か否かを示す情報を格納するためのUsableフィールドを含んでいる。
【００４０】
ディスクリプタテーブル４１〜４ｍの第１番目のワードは、当該ディスクリプタテーブルによって指し示されるパケット格納領域内に格納されているパケットの解析結果のレポートを格納するための解析レポート格納領域を更に含んでいる。解析レポート格納領域は、ＴＣＰヘッダ内のＦＩＮフラグ又はＲＳＴフラグ（図１２参照）がセットされているか否かを示す情報を格納するためのＦＩＮ，ＲＳＴフィールド、及びプロトコルの種類（ここでは、ＴＣＰ）を示す情報を格納するためのＰＲＯＴフィールドを含んでいる。
【００４１】
ディスクリプタテーブル４１〜４ｍの第２番目のワードは、当該ディスクリプタテーブルによって指し示されるヘッダ格納領域に格納可能なヘッダの最大サイズを示す情報を格納するためのＭＨＳフィールド（１３ビット幅）を含んでいる。このフィールドの値は、通信端点の開設時に設定される。また、ディスクリプタテーブル４１〜４ｍの第２番目のワードは、当該ディスクリプタテーブルによって指し示されるヘッダ格納領域に格納されているヘッダの実サイズを示す情報を格納するためのＲＨＳフィールド（１３ビット幅）を更に含んでいる。さらに、ディスクリプタテーブル４１〜４ｍの第２番目のワードは、ＲＨＳフィールドの値がＭＨＳフィールドの値より大きいというエラーが生じたことを示す情報を格納するためのＥＨＳフィールドを更に含んでいる。
【００４２】
ディスクリプタテーブル４１〜４ｍの第３番目のワードは、当該ディスクリプタテーブルによって指し示されるペイロード格納領域に格納可能なペイロードの最大サイズを示す情報を格納するためのＭＤＳフィールド（１３ビット幅）を含んでいる。このフィールドの値は、通信端点の開設時に設定される。また、ディスクリプタテーブル４１〜４ｍの第３番目のワードは、当該ディスクリプタテーブルによって指し示されるペイロード格納領域に格納されているペイロードの実サイズを示す情報を格納するためのＲＤＳフィールド（１３ビット幅）を更に含んでいる。さらに、ディスクリプタテーブル４１〜４ｍの第３番目のワードは、ＲＤＳフィールドの値がＭＤＳフィールドの値より大きいというエラーが生じたことを示す情報を格納するためのＥＤＳフィールドを更に含んでいる。
【００４３】
ディスクリプタテーブル４１〜４ｍの第４番目のワードは、次のディスクリプタテーブルを指し示すポインタ（アドレス）を格納するためのＮＰフィールド（３２ビット幅）を含んでいる。このＮＰフィールドにより、複数のディスクリプタテーブルが環状にリンクされている（図２参照）。これにより、パケット格納領域３１〜３ｍは、ＦＩＦＯバッファと同様に利用することが可能である。
【００４４】
ディスクリプタテーブル４１〜４ｍの第５番目のワードは、ヘッダ格納領域を指し示すポインタ（アドレス）を格納するためのＨＰフィールド（３２ビット幅）を含んでいる。
ディスクリプタテーブル４１〜４ｍの第６番目のワードは、ペイロード格納領域を指し示すポインタ（アドレス）を格納するためのＤＰフィールド（３２ビット幅）を含んでいる。
【００４５】
なお、通信端点を開設するためのＡＰＩ（より具体的には、ＡＰＩプログラムを実行するＣＰＵ８）は、ヘッダ格納領域３１ａ〜３ｍａ及びペイロード格納領域３１ｂ〜３ｍｂをそれぞれ異なるサイズにすることができる。ヘッダ格納領域３１ａ〜３ｍａ及びペイロード格納領域３１ｂ〜３ｍｂをそれぞれ異なるサイズとした場合であっても、ヘッダ格納領域３１ａ〜３ｍａ及びペイロード格納領域３１ｂ〜３ｍｂのサイズがディスクリプタテーブル４１〜４ｍのＭＨＳフィールド及びＭＤＳフィールドにそれぞれ設定されるため、ＴＣＰ／ＩＰ受信処理回路５は、ヘッダ格納領域３１ａ〜３ｍａ及びペイロード格納領域３１ｂ〜３ｍｂのサイズを検知することが可能である。
【００４６】
再び図２を参照すると、第１群の領域は、ＴＣＰのコネクションを切断するためのＲＳＴパケット（ＴＣＰヘッダ内のＲＳＴフラグ（図１２参照）がセットされたパケット）を格納するためのパケット格納領域５１を更に含んでいる。パケット格納領域５１は、ヘッダ格納領域５１ａ及びペイロード格納領域５１ｂを含んでいる。また、第１群の領域は、ヘッダ格納領域５１ａ及びペイロード格納領域５１ｂを指し示すディスクリプタテーブル５２を更に含んでいる。ディスクリプタテーブル５２のフォーマットは、図３に示すディスクリプタテーブル４１〜４ｍと同様である。このように、ＲＳＴパケットを格納するためのパケット格納領域５１をパケット格納領域３１〜３ｍと別個に設けることとしているのは、以下の理由による。すなわち、ＴＣＰにおいては、ＲＳＴパケットを受信することでセッションの切断指示を受け取ったことになる。そのため、パケット格納領域３１〜３ｍの全てにパケットが格納されているときに通信端点Ａ宛てのＲＳＴパケットを受信したような場合であっても、受信したＲＳＴパケットを確実にメインメモリ９内に転送及び格納し、アプリケーション層においてＴＣＰのコネクションの切断処理を確実に行うことができるようにし、セッションタイムアウトまで通信端点が機能せず、通信効率に多大な悪影響を及ぼすという事態が生ずる懸念を排除するためである。
【００４７】
さらに、第１群の領域は、通信端点Ａに関する情報を格納するための通信端点条件設定テーブル５３を更に含んでいる。
【００４８】
図４は、通信端点条件設定テーブル５３のフォーマットを示す図である。図４に示すように、通信端点条件設定テーブル５３は、５ワードと、１ハーフワードとで構成されている。第１番目のワードは、通信端点Ａのソース（自）ＩＰアドレスを格納するためのＳＯＵＲＣＥ＿ＩＰフィールド（３２ビット幅）を含んでいる。
【００４９】
通信端点条件設定テーブル５３の第２番目のワードは、通信端点Ａのデスティネーション（相手方）ＩＰアドレスを格納するためのＤＥＳＴ＿ＩＰフィールド（３２ビット幅）を含んでいる。
【００５０】
通信端点条件設定テーブル５３の第３番目のワードは、通信端点Ａのソース（自）ポート番号を格納するためのＳＯＵＲＣＥ＿ＰＮフィールド（１６ビット幅）と、通信端点Ａのデスティネーション（相手方）ポート番号を格納するためのＤＥＳＴ＿ＰＮフィールド（１６ビット幅）とを含んでいる。
【００５１】
通信端点条件設定テーブル５３の第４番目のワードは、通信端点Ａのシーケンス番号を格納するためのＳＥＱフィールド（３２ビット幅）を含んでいる。
【００５２】
通信端点条件設定テーブル５３の第５番目のワードは、通信端点Ａのアクノリッジ番号を格納するためのＡＣＫフィールド（３２ビット幅）を含んでいる。
【００５３】
通信端点条件設定テーブル５３の最後のハーフワードは、通信端点Ａのウィンドウサイズを格納するためのＷＩＮフィールド（１６ビット幅）を含んでいる。
【００５４】
再び図２を参照すると、通信端点Ｂに対応する第２群の領域は、通信端点Ｂ宛てのパケットをそれぞれ格納するための複数のパケット格納領域６１〜６ｎを含んでいる。パケット格納領域６１〜６ｎは、ヘッダ格納領域６１ａ〜６ｎａ及びペイロード格納領域６１ｂ〜６ｎｂをそれぞれ含んでいる。また、第２群の領域は、ヘッダ格納領域６１ａ〜６ｎａ及びペイロード格納領域６１ｂ〜６ｎｂへのポインタをそれぞれ有するディスクリプタテーブル７１〜７ｎと、通信端点Ｂに関する情報を格納するための通信端点条件設定テーブル８３とを更に含んでいる。
【００５５】
通信端点ＢのプロトコルはＵＤＰであり、通信端点Ｂ宛てのＲＳＴパケットというものは存在し得ない。そのため、第２群の領域は、先に説明した第１群の領域内のパケット格納領域５１及びディスクリプタテーブル５２のようなＲＳＴパケットを格納するための領域を含んでいない。
【００５６】
また、通信端点ＢのプロトコルはＵＤＰであり、通信端点Ｂ宛てのＦＩＮパケット、ＲＳＴパケットというものは存在し得ない。そのため、ディスクリプタテーブル７１〜７ｎは、図３に示すディスクリプタテーブル４１〜４ｍとほぼ同様であるが、第１番目のワードのＦＩＮ，ＲＳＴフィールドは不要である。
【００５７】
さらに、通信端点ＢのプロトコルはＵＤＰであり、通信端点Ｂにおいてはシーケンス番号、アクノリッジ番号、及び、ウィンドウサイズというものは存在しない。そのため、第２群の領域内の通信端点条件設定テーブル８３は、図４に示す通信端点条件設定テーブル５３の第１〜第３番目のワードの３ワード（ソースＩＰアドレス、デスティネーションＩＰアドレス、ソースポート番号、及び、デスティネーションポート番号）を有していれば足りる。
【００５８】
一方、ＤＭＡ制御部２４内のレジスタは、ＴＣＰの通信端点のための第１群のレジスタと、ＵＤＰの通信端点のための第２群のレジスタとに分けられている。これら第１及び第２群のレジスタの各々は、ソース（自）ＩＰアドレスを格納するための第１のフィールド、ソース（自）ポート番号を格納するための第２のフィールド、デスティネーション（相手方）ＩＰアドレスを格納するための第３のフィールド、デスティネーション（相手方）ポート番号を格納するための第４のフィールド、及び、第１〜第４のフィールドの値によって特定される通信端点に対応する複数のディスクリプタテーブルの中の１つを指し示すためのポインタ（アドレス）を格納するための第５のフィールドを含んでいる。
【００５９】
先に説明したように、ＤＭＡ制御部２４内のレジスタの各々は、ＣＰＵ８のＩ／Ｏアドレス空間にマッピングされており、ＣＰＵ８からＩ／Ｏとしてアクセス可能である。そして、アプリケーション層において通信端点を開設するためのＡＰＩがコールされると、開設された通信端点に対応するディスクリプタテーブル、パケット格納領域等が、ＡＰＩによりメインメモリ９内に形成されるとともに、開設された通信端点を特定するソース（自）ＩＰアドレス、ソース（自）ポート番号、デスティネーション（相手方）ＩＰアドレス、及び、デスティネーション（相手方）ポート番号、並びに、開設された通信端点に対応する複数のディスクリプタテーブルの中の１つのディスクリプタテーブル（ここでは、先頭のディスクリプタテーブル）を指し示すためのポインタ（アドレス）が、ＡＰＩによりＤＭＡ制御部２４内のレジスタに書き込まれる。
【００６０】
なお、コンピュータ１が、ＴＣＰ又はＵＤＰ以外のトランスポート層のプロトコル（例えば、ＩＣＭＰ（Internet Control Message Protocol）等）、ＩＰバージョン４以外のネットワーク層のプロトコル（例えば、ＡＲＰ（Address Resolution Protocol）、ＲＡＲＰ（Reverse Address Resolution Protocol）、ＩＰバージョン６等）のパケットを受信する場合がある。そのような場合のため、メインメモリ９内には、ＴＣＰ若しくはＵＤＰ以外のトランスポート層のプロトコル又はＩＰバージョン４以外のネットワーク層のプロトコルのパケットを格納するための１群の領域（以下、「ジャンクバッファ」という）が予め用意されている。ジャンクバッファは、ＴＣＰ若しくはＵＤＰ以外のトランスポート層のプロトコル又はＩＰバージョン４以外のネットワーク層のプロトコルのパケットを格納するための複数のパケット格納領域及びこれら複数のパケット格納領域へのポインタをそれぞれ有する複数のディスクリプタテーブルを含んでいる。
【００６１】
図５（ａ）は、メインメモリ９内のジャンクバッファを示す図である。ここでは、ジャンクバッファは、複数のパケット格納領域９１〜９ｐ及びディスクリプタテーブル１０１〜１０ｐを含んでいる。
【００６２】
図５（ｂ）は、ディスクリプタテーブル１０１〜１０ｐのフォーマットを示す図である。図５（ｂ）に示すように、ディスクリプタテーブル１０１〜１０ｐは、６ワードで構成されている。第１番目のワードは、当該ディスクリプタテーブルによって指し示されるパケット格納領域へのパケット書込みの可否に関する情報を格納するためのパケット書込み可否情報格納領域を含んでいる。ここでは、パケット書込み可否情報格納領域は、当該ディスクリプタテーブルによって指し示されるパケット格納領域内にパケットが格納されているか否かを示す情報を格納するためのReceivedフィールド、及び当該ディスクリプタテーブルによって指し示されるパケット格納領域が使用可能か否かを示す情報を格納するためのUsableフィールドを含んでいる。
【００６３】
ディスクリプタテーブル１０１〜１０ｐの第１番目のワードは、当該ディスクリプタテーブルによって指し示されるパケット格納領域内に格納されているパケットの解析結果のレポートを格納するための解析レポート格納領域を含んでいる。ここでは、解析レポート格納領域は、プロトコルの種類を示す情報を格納するためのＰＲＯＴフィールドを含んでいる。
【００６４】
ディスクリプタテーブル１０１〜１０ｐの第２番目のワードは、当該ディスクリプタテーブルによって指し示されるヘッダ格納領域に格納可能なパケットの最大サイズを示す情報を格納するためのＭＳフィールド（１３ビット幅）を含んでいる。このフィールドの値は、初期時に設定される。また、ディスクリプタテーブル１０１〜１０ｐの第２番目のワードは、当該ディスクリプタテーブルによって指し示されるパケット格納領域に格納されているパケットの実サイズを示す情報を格納するためのＲＳフィールド（１３ビット幅）を更に含んでいる。さらに、ディスクリプタテーブル１０１〜１０ｐの第２番目のワードは、ＲＳフィールドの値がＭＳフィールドの値より大きいというエラーが生じたことを示す情報を格納するためのＥＳフィールドを更に含んでいる。
【００６５】
ディスクリプタテーブル１０１〜１０ｐの第３番目のワードは、未使用となっている。  ディスクリプタテーブル１０１〜１０ｐの第４番目のワードは、次のディスクリプタテーブルを指し示すポインタ（アドレス）を格納するためのＮＰフィールド（３２ビット幅）を含んでいる。このＮＰフィールドにより、複数のディスクリプタテーブルが環状にリンクされている（図５（ａ）参照）。これにより、パケット格納領域９１〜９ｐは、ＦＩＦＯバッファと同様に利用することが可能である。
【００６６】
ディスクリプタテーブル１０１〜１０ｐの第５番目のワードは、パケット格納領域を指し示すポインタ（アドレス）を格納するためのＰＰフィールド（３２ビット幅）を含んでいる。
ディスクリプタテーブル１０１〜１０ｐの第６番目のワードは、未使用となっている。
【００６７】
次に、ＴＣＰ／ＩＰ受信処理回路５の動作について説明する。
まず、ＴＣＰ／ＩＰ受信処理回路５内のフレーム解析処理部２１の動作について説明する。図６は、フレーム解析処理部２１の動作を示すフローチャートである。フレーム解析処理部２１は、ネットワークインタフェース層のＭＡＣブリッジ回路４からフレームを受け取ると、図６に示す処理を開始する。
【００６８】
まず、フレーム解析処理部２１は、ＭＡＣブリッジ回路４から受け取ったフレームの末尾に付加されているフレームチェックシーケンス（Frame Check Sequence）内のＣＲＣ（Cyclic Redundancy Check）を用いて、フレームの検証を行う（ステップＳ１１）。そして、フレーム解析処理部２１は、エラーがあると判断した場合には処理をステップＳ１３に移し、エラーが無いと判断した場合には処理をステップＳ１４に移す（ステップＳ１２）。
【００６９】
ステップＳ１２にてフレームにエラーがあると判断した場合、フレーム解析処理部２１は、フレームを廃棄し（ステップＳ１３）、処理を終了する。
【００７０】
ステップＳ１２にてフレームにエラーが無いと判断した場合、フレーム解析処理部２１は、フレームのペイロードに格納されているパケットのプロトコルが所定のプロトコル（本実施形態においては、インターネット層のプロトコルがＩＰ且つトランスポート層のプロトコルがＴＣＰ、インターネット層のプロトコルがＩＰ且つトランスポート層のプロトコルがＵＤＰ、インターネット層のプロトコルがＩＰ且つトランスポート層のプロトコルがＩＣＭＰ、インターネット層のプロトコルがＡＲＰ、又は、インターネット層のプロトコルがＲＡＲＰとする）であるか否かをチェックする。所定のプロトコルであるか否かは、パケットが図１０〜図１４に示すフォーマットに合致するか否かにより判断することが可能である。そして、フレーム解析処理部２１は、フレームのペイロードに格納されているパケットのプロトコルが所定のプロトコルではない（例えば、フレームのペイロードに格納されているパケットのネットワーク層のプロトコルがＩＰバージョン６である場合や、フレームのペイロードに格納されているパケットのネットワーク層のプロトコルがＩＰではあるがトランスポート層のプロトコルがＴＣＰ、ＵＤＰ、又は、ＩＣＭＰ以外のプロトコルである場合等）と判断した場合には処理をステップＳ１５に移し、フレームのペイロードに格納されているパケットのプロトコルが所定のプロトコルであると判断した場合には処理をステップＳ１６に移す（ステップＳ１４）。
【００７１】
ステップＳ１４にてフレームのペイロードに格納されているパケットのプロトコルが所定のプロトコルではないと判断した場合、フレーム解析処理部２１は、フレームをそのままＦＩＦＯバッファメモリ２３に書き込むとともに、フレーム及びプロトコルの解析結果を解析結果データ格納部２２に書き込み（ステップＳ１５）、処理を終了する。なお、ここでＦＩＦＯバッファメモリ２３に書き込まれたフレームは、後に説明するように、メインメモリ９内のジャンクバッファに転送される。そして、ジャンクバッファに転送されたフレームは、ＣＰＵとソフトウェア（プログラム）でインターネット層及びトランスポート層の処理がされることとなる。
【００７２】
ステップＳ１４にてフレームのペイロードに格納されているパケットのプロトコルが所定のプロトコルであると判断した場合、フレーム解析処理部２１は、フレームのペイロードに格納されているパケット内の情報を用いて、パケットの検証を行う（ステップＳ１６）。
【００７３】
例えば、フレームのペイロードに格納されているパケットがＩＰパケット（図１０参照）である場合、フレーム解析処理部２１は、ＩＰヘッダ内の「ヘッダ長」フィールド、「データグラム長」フィールド、及び、「ヘッダ・チェックサム」フィールドの値を用いて、フレームのペイロードに格納されているＩＰパケットの検証を行う。
【００７４】
また、フレームのペイロードに格納されているパケットがＩＰパケットであり且つＩＰパケットのペイロードに格納されているパケットがＴＣＰパケット（図１２参照）である場合、フレーム解析処理部２１は、ＴＣＰヘッダ内の「チェックサム」フィールドの値を用いて、ＴＣＰパケットの検証を更に行う。
【００７５】
また、フレームのペイロードに格納されているパケットがＩＰパケットであり且つＩＰパケットのペイロードに格納されているパケットがＵＤＰパケット（図１３参照）である場合、フレーム解析処理部２１は、ＵＤＰヘッダ内の「パケット長」フィールド及び「チェックサム」フィールドの値を用いて、ＵＤＰパケットの検証を更に行う。
【００７６】
また、フレームのペイロードに格納されているパケットがＩＰパケットであり且つＩＰパケットのペイロードに格納されているパケットがＩＣＭＰパケット（図１４参照）である場合、フレーム解析処理部２１は、ＩＣＭＰヘッダ内の「チェックサム」フィールドの値を用いて、ＩＣＭＰパケットの検証を更に行う。
【００７７】
再び図６を参照すると、フレーム解析処理部２１は、パケットにエラーがあると判断した場合には処理をステップＳ１８に移し、エラーが無いと判断した場合には処理をステップＳ１９に移す（ステップＳ１７）。
【００７８】
ステップＳ１７にてパケットにエラーがあると判断した場合、フレーム解析処理部２１は、パケットを廃棄し（ステップＳ１８）、処理を終了する。
【００７９】
ステップＳ１７にてパケットにエラーが無いと判断した場合、フレーム解析処理部２１は、パケットをＦＩＦＯバッファメモリ２３に書き込むとともに、パケットの解析結果を解析結果データ格納部２２に書き込み（ステップＳ１９）、処理を終了する。
【００８０】
ここで、ＭＡＣブリッジ回路４から受け取ったフレームのペイロードに格納されているパケットのプロトコルがＡＲＰ又はＲＡＲＰである場合、フレーム解析処理部２１は、ＡＲＰパケット又はＲＡＲＰパケットをＦＩＦＯバッファメモリ２３に書き込む。また、ＭＡＣブリッジ回路４から受け取ったフレームのペイロードに格納されているパケットのプロトコルがＩＰである場合、フレーム解析処理部２１は、ＩＰパケットのペイロードに格納されているパケット（本実施形態においては、ＴＣＰパケット、ＵＤＰパケット、又は、ＩＣＭＰパケット）をＦＩＦＯバッファメモリ２３に書き込む。
【００８１】
また、フレーム解析処理部２１が解析結果データ格納部２２に書き込む解析結果には、プロトコル（本実施形態においては、インターネット層のプロトコルがＩＰ且つトランスポート層のプロトコルがＴＣＰ、インターネット層のプロトコルがＩＰ且つトランスポート層のプロトコルがＵＤＰ、インターネット層のプロトコルがＩＰ且つトランスポート層のプロトコルがＩＣＭＰ、インターネット層のプロトコルがＡＲＰ、又は、インターネット層のプロトコルがＲＡＲＰ）、及びパケットのサイズが含まれる。さらに、ＭＡＣブリッジ回路４から受け取ったフレームのペイロードに格納されているパケットのプロトコルが、インターネット層のプロトコルがＩＰ且つトランスポート層のプロトコルがＴＣＰ又はインターネット層のプロトコルがＩＰ且つトランスポート層のプロトコルがＵＤＰである場合には、フレーム解析処理部２１が解析結果データ格納部２２に書き込む解析結果には、ＴＣＰヘッダ又はＵＤＰヘッダのサイズと、ＴＣＰペイロード又はＵＤＰペイロードのサイズと、通信端点を特定するための情報（ソース（自）ＩＰアドレス、ソース（自）ポート番号、デスティネーション（相手）ＩＰアドレス、及び、デスティネーション（相手）ポート番号）とが更に含まれる。なお、ソース（自）ＩＰアドレス及びデスティネーション（相手）ＩＰアドレスは、ＩＰヘッダ（図１０参照）に格納されており、ソース（自）ポート番号及びデスティネーション（相手）ポート番号）は、ＴＣＰヘッダ（図１２参照）又はＵＤＰヘッダ（図１３参照）に格納されている。
【００８２】
なお、フレーム解析処理部２１が、ＣＰＵ８のＩ／Ｏアドレス空間にマッピングされた複数の自動加算カウンタを具備していることとし、ＴＣＰの通信端点の開設時において、ＴＣＰの通信端点のシーケンス番号の初期値が、いずれかの自動加算カウンタにＡＰＩにより書き込まれるようにしても良い。そして、フレーム解析処理部２１が、ＴＣＰの通信端点宛てのパケットが格納されたフレームをＭＡＣブリッジ回路４から受け取った場合に、当該パケット中のシーケンス番号（図１２参照）と自動加算カウンタの値とが一致するときには当該パケットをＦＩＦＯバッファメモリ２３に書き込むとともに自動加算カウンタをインクリメントし、当該パケット中のシーケンス番号と自動加算カウンタの値とが一致しないときには当該パケットを廃棄するようにしても良い。ＴＣＰにおいては、シーケンス番号の一致性を検証することで、パケット到達の順序性と基本的な通信路の安全性を得る。一般に、１つの論理的データストリームは複数の受信パケットで構成される場合が多く、上記のように自動加算カウンタを具備することにより、パケット受信の可否をソフトウェアで行う必要をなくすことが可能となる。
【００８３】
次に、ＴＣＰ／ＩＰ受信処理回路５内のＤＭＡ制御部２４の動作について説明する。図７は、ＤＭＡ制御部２４の動作を示すフローチャートである。
【００８４】
ＤＭＡ制御部２４は、解析結果データ格納部２２に格納されている解析結果の内のプロトコルを参照し、ＦＩＦＯバッファメモリ２３に格納されているパケット等（パケット又はフレーム）がＴＣＰ又はＵＤＰパケットであるか否かをチェックし、ＦＩＦＯバッファメモリ２３に格納されているパケット等がＴＣＰ又はＵＤＰパケットであると判断した場合には処理をステップＳ２２に移し、ＦＩＦＯバッファメモリ２３に格納されているパケット等がＴＣＰ又はＵＤＰパケットではないと判断した場合には処理をステップＳ２４に移す（ステップＳ２１）。
【００８５】
ステップＳ２１にてＦＩＦＯバッファメモリ２３に格納されているパケット等がＴＣＰ又はＵＤＰパケットであると判断した場合、ＤＭＡ制御部２４は、解析結果データ格納部２２に格納されている解析結果の内の通信端点を特定するための情報（ソース（自）ＩＰアドレス、ソース（自）ポート番号、デスティネーション（相手）ＩＰアドレス、及び、デスティネーション（相手）ポート番号）を更に参照し、ＦＩＦＯバッファメモリ２３に格納されているＴＣＰ又はＵＤＰパケットがいずれかの通信端点宛てのものであるか否かをチェックする。具体的には、ＤＭＡ制御部２４内のレジスタには、開設された通信端点を特定するための情報が格納されており（図２参照）、ＤＭＡ制御部２４は、解析結果データ格納部２２に格納されている解析結果の内の通信端点を特定するための情報とレジスタの内容とを照合することにより、ＦＩＦＯバッファメモリ２３に格納されているＴＣＰ又はＵＤＰパケットがいずれかの通信端点宛てのものであるか否かをチェックすることができる。または、ＤＭＡ制御部２４は、解析結果データ格納部２２に格納されている解析結果の内の通信端点を特定するための情報と、メインメモリ９内の通信端点条件設定テーブル５３の内容とを照合することにより、ＦＩＦＯバッファメモリ２３に格納されているＴＣＰ又はＵＤＰパケットがいずれかの通信端点宛てのものであるか否かをチェックすることができる。そして、ＤＭＡ制御部２４は、ＦＩＦＯバッファメモリ２３に格納されているＴＣＰ又はＵＤＰパケットがいずれかの通信端点宛てのものであると判断した場合には処理をステップＳ２３に移し、ＦＩＦＯバッファメモリ２３に格納されているＴＣＰ又はＵＤＰパケットがいずれの通信端点宛てのものでもないと判断した場合には処理をステップＳ２４に移す（ステップＳ２２）。
【００８６】
ステップＳ２２にてＦＩＦＯバッファメモリ２３に格納されているＴＣＰ又はＵＤＰパケットがいずれかの通信端点宛てのものであると判断した場合、ＤＭＡ制御部２４は、ＦＩＦＯバッファメモリ２３に格納されているＴＣＰ又はＵＤＰパケットをＦＩＦＯバッファメモリ２３に格納されているＴＣＰ又はＵＤＰパケットの宛先である通信端点のパケット格納領域にＤＭＡ転送するように、ＤＭＡ処理部２５を制御する（ステップＳ２３）。
【００８７】
具体的には、ＦＩＦＯバッファメモリ２３に格納されているパケットが通信端点Ａ宛てのＴＣＰパケットである場合、ＤＭＡ制御部２４は、ＦＩＦＯバッファメモリ２３に格納されているＴＣＰパケットをパケット格納領域３１〜３ｍ（図２参照）のいずれかに転送するようにＤＭＡ処理部２５を制御する。なお、パケット格納領域３１〜３ｍのいずれをＤＭＡ転送先にするかは、レジスタ内のポインタ（アドレス）からディスクリプタテーブル４１〜４ｍ内のパケット書込み可否情報格納領域（図３参照）を順次参照し、パケットの書込みが可能なパケット格納領域を探すことにより、決定することができる。また、ＤＭＡ転送量（ＤＭＡ転送データサイズ）は、解析結果データ格納部２２に格納されているＴＣＰヘッダサイズ及びＴＣＰペイロードサイズを参照することにより、決定することができる。なお、ＦＩＦＯバッファメモリ２３に格納されているＴＣＰパケットのヘッダ又はペイロードのサイズが転送先のヘッダ格納領域又はペイロード格納領域のサイズ（図３中のＭＨＳフィールド又はＭＤＳフィールドにより検知可能）を超えている場合には、ＤＭＡ制御部２４が、当該パケットのヘッダ又はペイロードの内の転送先のヘッダ格納領域又はペイロード格納領域に格納可能な部分のみをＤＭＡ転送し、当該パケットのヘッダ又はペイロードの内の転送先のヘッダ格納領域又はペイロード格納領域のサイズを超えている部分をＤＭＡ転送しないようにしても良い。
【００８８】
同様に、ＦＩＦＯバッファメモリ２３に格納されているパケットが通信端点Ｂ宛てのＵＤＰパケットである場合、ＤＭＡ制御部２４は、ＦＩＦＯバッファメモリ２３に格納されているＵＤＰパケットをパケット格納領域６１〜６ｎ（図２参照）のいずれかに転送するようにＤＭＡ処理部２５を制御する。なお、パケット格納領域６１〜６ｎのいずれをＤＭＡ転送先にするかは、レジスタ内のポインタ（アドレス）からディスクリプタテーブル７１〜７ｎ内のパケット書込み可否情報格納領域（図３参照）を順次参照し、パケットの書込みが可能なパケット格納領域を探すことにより、決定することができる。また、ＤＭＡ転送量（ＤＭＡ転送データサイズ）は、解析結果データ格納部２２に格納されているＵＤＰヘッダサイズ及びＵＤＰペイロードサイズを参照することにより、決定することができる。なお、ＦＩＦＯバッファメモリ２３に格納されているＵＤＰパケットのヘッダ又はペイロードのサイズが転送先のヘッダ格納領域又はペイロード格納領域のサイズ（図３中のＭＨＳフィールド又はＭＤＳフィールドにより検知可能）を超えている場合には、ＤＭＡ制御部２４が、当該パケットのヘッダ又はペイロードの内の転送先のヘッダ格納領域又はペイロード格納領域に格納可能な部分のみをＤＭＡ転送し、当該パケットのヘッダ又はペイロードの内の転送先のヘッダ格納領域又はペイロード格納領域のサイズを超えている部分をＤＭＡ転送しないようにしても良い。
【００８９】
一方、ステップＳ２１にてＦＩＦＯバッファメモリ２３に格納されているパケット等がＴＣＰ又はＵＤＰパケットでないと判断した場合、又は、ステップＳ２２にてＦＩＦＯバッファメモリ２３に格納されているＴＣＰ又はＵＤＰパケットがいずれの通信端点宛てのものでもないと判断した場合、ＤＭＡ制御部２４は、ＦＩＦＯバッファメモリ２３に格納されているパケット等をジャンクバッファにＤＭＡ転送するように、ＤＭＡ処理部２５を制御する（ステップＳ２４）。ＤＭＡ転送の終了後、ＤＭＡ制御部２４が、ＣＰＵ８にパケット受信通知制御信号を出力し、ＣＰＵ８がパケット等を読み出してソフトウェア（プログラム）でインターネット層及びトランスポート層の処理をすることが可能となる。
【００９０】
なお、ＤＭＡ制御部２４が、ＣＰＵ８のＩ／Ｏアドレス空間にマッピングされた複数の減算カウンタを具備していることとし、通信端点の開設時において、通信端点の論理的データストリームブロック（これは、ウィンドウバッファサイズであっても良い）の初期サイズが、いずれかの減算カウンタにＡＰＩにより書き込まれるようにしても良い。そして、ＤＭＡ制御部２４が、ステップＳ２３において、ＦＩＦＯバッファメモリ２３に格納されているＴＣＰ又はＵＤＰパケットのペイロード部をＦＩＦＯバッファメモリ２３に格納されているＴＣＰ又はＵＤＰパケットの宛先である通信端点のペイロード格納領域にＤＭＡ転送する都度、通信端点に対応する減算カウンタの値をＤＭＡ転送量だけ減算するようにしても良い。そして、ＤＭＡ制御部２４が、減算カウンタが０になるまでＣＰＵ８にパケット受信通知制御信号を出力せず、減算カウンタが０になったときにＣＰＵ８にパケット受信通知制御信号を出力するようにすれば、アプリケーション層は複数の受信パケットで構成される固定長論理データストリームを一括して扱うことができ、ソフトウェアオーバーヘッドの削減（タスクスイッチングや割り込み発生回数の削減等）が可能となる。また、ＤＭＡ制御部２４が、ペイロードの内の減算カウンタの値を超える部分をＤＭＡ転送しないようにしても良い。
【００９１】
以上説明したように、本実施形態によれば、ディスクリプタテーブルをリンクしておくことにより、ＴＣＰ／ＩＰ受信処理回路５がＴＣＰ又はＵＤＰの通信端点宛てのパケットをメインメモリ９内のパケット格納領域に転送することを簡素化でき、アプリケーション層が受信パケットの個数で定義される論理的データストリームブロックを容易に扱うことができる。
【００９２】
また、本実施形態によれば、ＴＣＰ又はＵＤＰの通信端点宛てのパケットのヘッダ及びペイロードを、メインメモリ９内に設けられたヘッダ格納領域及びペイロード格納領域に転送することができる。これにより、アプリケーション層は、１つの通信端点宛ての複数のパケットが存在する場合に、ヘッダを参照することなく、ペイロードのみを自在に利用することができる。このとき、複数のペイロード格納領域を連続するアドレスに配置しておけば、アプリケーション層が複数のペイロードを連続してアクセスすることが容易となる。
【００９３】
また、本実施形態においては、ＴＣＰ又はＵＤＰの通信端点宛てのパケットのヘッダ又はペイロードのサイズが転送先のヘッダ格納領域又はペイロード格納領域のサイズを超えている場合には、当該パケットのヘッダ又はペイロードの内の転送先のヘッダ格納領域又はペイロード格納領域のサイズを超えている部分はＤＭＡ転送されない。従って、仮に第三者が不正なパケットをコンピュータ１に送信し、不正なパケットがＴＣＰ又はＵＤＰの通信端点の設定条件に合致してしまった場合であっても、不正なパケットのヘッダ又はペイロードの内の転送先のヘッダ格納領域又はペイロード格納領域のサイズを超えている部分はＤＭＡ転送されず、不正なパケットによりＯＳ、ＡＰＩ、又は、アプリケーションプログラムのワークエリアが上書きされてしまうことがない。これにより、第三者によるクラッキング等を防止することが可能である。
【００９４】
なお、本実施形態においては、ネットワークインタフェース層としてEthernet（登録商標）を用いることとしているが、他のものを用いるようにしても良い。また、アプリケーション層として、ＨＴＴＰ（Hyper Text Transfer Protocol）等、種々のものを用いることが可能である。
【産業上の利用可能性】
【００９５】
本発明は、ＴＣＰ／ＩＰ受信処理回路において利用可能である。このＴＣＰ／ＩＰ受信処理回路は、パーソナルコンピュータ、携帯電話装置、ＰＤＡ、家庭電気製品（テレビジョン装置、冷蔵庫等）等に利用可能である。
【図面の簡単な説明】
【００９６】
【図１】本発明の実施形態に係るＴＣＰ／ＩＰ受信処理回路を用いたシステムの図。
【図２】図１のメインメモリ９及びＤＭＡ制御部２４のレジスタの内容を示す図。
【図３】図２のディスクリプタテーブルのフォーマットを示す図。
【図４】図２の通信端点条件設定テーブルのフォーマットを示す図。
【図５】図１のメインメモリ９の内容を示す図。
【図６】図１のＴＣＰ／ＩＰ受信処理回路５の動作を示すフローチャート。
【図７】図１のＴＣＰ／ＩＰ受信処理回路５の動作を示すフローチャート。
【図８】ＯＳＩ参照モデルとＴＣＰ／ＩＰ階層モデルとの対応関係を示す図。
【図９】フレームのフォーマットを示す図。
【図１０】ＩＰパケットのフォーマットを示す図。
【図１１】ＡＲＰ、ＲＡＲＰパケットのフォーマットを示す図。
【図１２】ＴＣＰパケットのフォーマットを示す図。
【図１３】ＵＤＰパケットのフォーマットを示す図。
【図１４】ＩＣＭＰパケットのフォーマットを示す図。
【符号の説明】
【００９７】
１  コンピュータ、  ２  物理層処理回路、  ３  ＭＡＣ処理回路、  ４  ＭＡＣブリッジ回路、  ５  ＴＣＰ／ＩＰ受信処理回路、  ６  ＴＣＰ／ＩＰ送信処理回路、  ７  インタフェース回路、  ８  ＣＰＵ、  ９  メインメモリ、  １０  ＨＤＤ、  １１  入力部、  １２  表示部、  ２１  フレーム解析処理部、  ２２  解析結果データ格納部、  ２３  ＦＩＦＯバッファメモリ、  ２４  ＤＭＡ制御部、  ２５  ＤＭＡ処理部
【図１】
2006325054.tif 000003
【図２】
2006325054.tif 000004
【図３】
2006325054.tif 000005
【図４】
2006325054.tif 000006
【図５】
2006325054.tif 000007
【図６】
2006325054.tif 000008
【図７】
2006325054.tif 000009
【図８】
2006325054.tif 000010
【図９】
2006325054.tif 000011
【図１０】
2006325054.tif 000012
【図１１】
2006325054.tif 000013
【図１２】
2006325054.tif 000014
【図１３】
2006325054.tif 000015
【図１４】
2006325054.tif 000016