(57)【特許請求の範囲】
【請求項１】
通信データのヘッダー情報を参照して該通信データの処理を行うヘッダー処理方法において、
階層構造の下位層のヘッダー情報の少なくとも一部を参照データとし、該参照データに比較してデータ量の少ないＩＤ値を前記参照データ対応に第１のテーブルに格納し、上位層のヘッダー情報と前記ＩＤ値との組を第２のテーブルに格納し、
受信した前記通信データの下位層のヘッダー情報の少なくとも一部を参照データとして前記第１のテーブルを検索し、読出した前記ＩＤ値と前記受信した通信データの上位層のヘッダー情報の少なくとも一部とを組として前記第２のテーブルを検索し、該第２のテーブルに格納されている場合は、受信した前記通信データの処理を行う過程を含む
ことを特徴とするヘッダー処理方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ネットワークにおけるデータ通信システムに用いられる伝送制御技術に係り、特に通信データのヘッダー情報を基にシステム内で処理することを許可するヘッダー処理方法に関する。
【０００２】
【従来の技術】
一般的に、ネットワークによるデータ通信システムには、広域通信として代表的なインターネットが知られており、他にも同一構内や同一建物内のような狭い範囲で構築されるＬＡＮ（ｌｏｃａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ）が知られている。
【０００３】
このネットワークの端末間でやり取りされる通信データの先頭部分には、送信先を示すアドレス番号や送信元を示すアドレス番号等の情報からなる下位層のＩＰヘッダーと上位層のＴＣＰヘッダーとが設けられている。このような階層構造のヘッダー情報を通信データの先頭に付加して、ネットワークの伝送経路の制御が行われる。又受信した通信データを、そのヘッダー情報を参照して所定の処理が行われる場合がある。
【０００４】
【発明が解決しようとする課題】
前述したヘッダー処理は、各階層のヘッダー毎にフォーマットや定義（情報ソースの取り扱い）が異なっているため、内蔵や外付けのＣＰＵでソフトウエアにより行われていた。
【０００５】
年々通信されるデータ量は増大してきており、これに伴いヘッダー処理の高速化も望まれている。従って、高速処理が望めない場合には、これがネックとなって通信全体に支障となる可能性がある。また、取り扱いが変わる毎にソフトウエアも大きく変更しなければならないという問題があった。
【０００６】
しかし、例えばヘッダーの各情報を参照して、マッチングを取るといったデータ処理は、ある程度規則的な動作である。従って、ソフトウエアからハードウエアに移行できる可能性がある。通常、ソフトウエアによる処理は、種々の複雑な処理に適用できるといった利点もある反面、ハードウエアの処理に比べて動作が遅くなるという欠点がある。従って、ソフトウエアのみによる高速処理を実現しようとすると、高速処理できる高価なＣＰＵが必要となり、通信コストが高くなってしまう。
【０００７】
また従来、ルックアップテーブルやＣＡＭ（Ｃｏｎｔｅｎｔ−ａｄｄｒｅｓｓａｂｌｅ  ｍｅｍｏｒｙ）で複数の情報を参照する際には、複数の情報をひとかたまりの１データとして一度にＣＡＭへの参照を行っていた。例えば、ネットワークのトラフィック上において、フロー（ＩＰＳＡ，ＤＡ，ＴＣＰ  Ｓｒｃ，ＴＣＰ  Ｄｓｔ）を参照する場合には、マッチングをとるだけでも最低９６ビット、戻り値を要求するのであれば、さらに多くの記憶領域を１つのＣＡＭに要求することになる。これはＣＡＭの実装面積の増加やコスト高に繋がっていた。
【０００８】
そこで本発明は、ネットワークの通信データにおけるヘッダー情報の最初の参照データを容量の少ないＩＤ値に置き換えて、残りの参照データと取り込みのための参照比較を行い、取り込みのヘッダー処理を行うバス幅を減少及び共用させて、ハードウエアの面積削減とハードウエア上の冗長部分を削減し性能を向上させるヘッダー処理方法を提供することを目的とする。
【０００９】
【課題を解決するための手段】
本発明は上記目的を達成するために、本発明のヘッダー処理方法は、通信データのヘッダー情報を参照して該通信データの処理を行うヘッダー処理方法において、階層構造の下位層のヘッダー情報の少なくとも一部を参照データとし、該参照データに比較してデータ量の少ないＩＤ値を前記参照データ対応に第１のテーブルに格納し、上位層のヘッダー情報と前記ＩＤ値との組を第２のテーブルに格納し、受信した前記通信データの下位層のヘッダー情報の少なくとも一部を参照データとして前記第１のテーブルを検索し、読出した前記ＩＤ値と前記受信した通信データの上位層のヘッダー情報の少なくとも一部とを組として前記第２のテーブルを検索し、該第２のテーブルに格納されている場合は、受信した前記通信データの処理を行う過程を含むものである。
【００１０】
以上のような処理過程を含むヘッダー処理方法は、最初の参照データの容量（ビット数）が減じられたＩＤ値により取り込みのための最初の参照比較が行われ、登録されていたならば、そのＩＤ値と残りの参照データを組として、取り込みのための第２の参照比較を行い、ＩＤ値と残りの参照データの組が登録されていた場合には、その通信データの処理が許可される。
【００１１】
【発明の実施の形態】
以下、図面を参照して本発明の実施形態について詳細に説明する。図１には、本発明のデータ処理方法を実現するための第１の実施形態に係るヘッダー処理装置に適用した構成例を示し、具体的には、ヘッダー処理装置を含むアドレスフィルタリングシステムを構築した例である。
【００１２】
このシステムは、ネットワークから通信データが着信するデータ入力部１と、このデータ入力部１内に設けられ、到来した通信データからヘッダー情報を取り出すヘッダー情報取り出し部２と、マッチングした通信データに対してシステムへの取り込み処理を行う制御部３と、後述する複数のヘッダーボックス（ＨＢＯＸ）７が配置されたヘッダーボックス部４及び参照すべきマッチング条件が予め設定されたルックアップテーブル５と、マッチングした通信データを取り込み、所定のデータ処理するホストコンピュータ６とを備えている。
【００１３】
本実施形態におけるヘッダー処理装置は、ヘッダー情報取り出し部２とヘッダーボックス部４とルックアップテーブル５で構成され、ヘッダーボックス部４及びルックアップテーブル５は制御部３内に設けられている。但し、ルックアップテーブル５は、外付けメモリや外付けのＣＡＭ等の記憶部を代用してもよい。尚、本実施形態では、アドレスフィルタリングシステムに適用した例で説明しているが、勿論限定されるものではなく、データから予め定めた特定の情報を抽出して処理を行うデータ処理については、本発明のデータ処理方法を容易に適用することができる。
【００１４】
図２には、１つのヘッダーボックス７に階層的に定義されているレジスタの具体的な一例を示す。第１段の情報処理レジスタとして、「処理開始フラグ」が定義される。第２段の情報処理レジスタとして、「ヘッダー長」が定義される。第３段の情報処理レジスタとして、「次プロトコル」が定義される。第４段の情報処理レジスタとして、「開始｜終了｜テーブル｜処理｜リンク｜処理終了フラグ｜情報登録レジスタ」のように各フィールドに動作や参照すべきテーブルの種類等の指定が定義される。詳しくは、後述する図４にて説明する。ここで示す情報処理レジスタの段数は、処理を行うヘッダーの種類分の数若しくは、ユーザが定義したセグメント単位の数である。
【００１５】
この情報処理レジスタは、ヘッダー処理を行うために、フォーマットが共通化され、取り込みたい通信データのヘッダー中の任意の情報の位置やその情報をどのようにルックアップテーブル５に参照し比較したいか等が定義されている。従って、ヘッダー情報はレジスタの定義内容に従い、この情報を次の情報とリンクするか、この情報だけで比較するか、繋げた情報をまとめて比較するか、比較を行わないかなどの幾通りかの動作のうちの少なくとも１つを実行する。また、情報登録レジスタの定義部分では、レジスタそのものを定義するのではなく、レジスタの位置を示すアドレス情報として扱ってもよい。
【００１６】
次に、図３に示すフローチャートを参照して、本実施形態によるヘッダー処理について説明する。まず、ホストコンピュータ６をユーザが操作して、ヘッダーボックス７の内容を予め登録することで取り込む情報や取り込んだ任意のヘッダー情報に対する動作を定義する（ステップＳ１）。この定義は、変える必要がなければ以前のものを継続して使用し、その都度定義を行わなくともよい。従って、実際にデータ処理させる場合には、以降の処理ルーチンからスタートすることとなる。
【００１７】
次に、実際にネットワークにアクセスしデータ入力部１へ到来した通信データに対して、ヘッダー情報取り出し部２でヘッダー情報を取り出して（ステップＳ２）、そのヘッダー情報がヘッダーボックス７に定義された内容に合致するか否かを判定する（ステップＳ３）。この判定において、合致しない場合には（ＮＯ）、処理を終了する。しかし合致した場合には（ＹＥＳ）、その通信データのヘッダー情報をヘッダーボックス部４へ送出して、該当するヘッダーボックス７若しくは、別途設けたレジスタやＲＡＭからなる別体の記憶ユニット（図示せず）に登録する（ステップＳ４）。
【００１８】
次に、ヘッダーボックス部４内の該当するヘッダーボックス７で定義されている情報処理レジスタの階層順に従った処理を実施する（ステップＳ５）。そして、得られた処理結果をルックアップテーブル５に予め登録されたテーブルを参照させてマッチングをとる（ステップＳ６）。ここでマッチングが取れれば（ＹＥＳ）、マッチングしたことを示すマッチング信号を制御部内のマッチング行う構成部位若しくはホストコンピュータ６に出力する（ステップＳ７）。
【００１９】
以上説明したように本実施形態のヘッダー処理装置によれば、複数段のレジスタからなるヘッダーボックスを処理したいヘッダーの種類毎にそれぞれ設けたり、ユーザが所望する数を設けたりすることができる。従って、ヘッダーボックスの数量を増加させることによりデータ処理の拡張が容易に実現することができ、マルチプロトコルやマルチレイヤ等にも対応させることができる。また、ソフトウエアのみによる処理に比べて、制御部（ＣＰＵ）の処理形態に依存しないため、ヘッダー処理部を動作させるためのソフトウエアやオペレーションソフトに自由度があり、選択範囲が広がる。
【００２０】
さらに、ヘッダーボックスの情報処理レジスタへの設定や書き換えがユーザサイドで容易に行うことができ、各ヘッダー情報の処理に対して、フレキシビリティーが保てる。このフレキシビリティーを保ちつつ、ヘッダーデータの処理をレジスタというハードウエアにより処理を行っているため、従来のソフトウエアのみによる処理に比べて、処理の高速化が実現できる。また、処理の高速化を図るための高性能なＣＰＵを必要とせず、汎用的なレジスタで構成でき、構築のためのコストを低く抑制して実現できる。
【００２１】
次に図４（ａ）には、第２の実施形態に係るデータ処理装置の構成例を示し、ヘッダー処理について説明する。前述した第１の実施形態では、主としてヘッダーボックス部について説明したが本実施形態は、データ処理についてどのように参照するか一例を示して具体的に説明する。尚、本実施形態の構成部位において、前述した図１に示した構成部位と同等の部材には同じ参照符号を付してその説明は省略する。
【００２２】
このヘッダー処理装置は、ヘッダーボックス部４と、２つのルックアップテーブル１１，１２と、これらのテーブルにアクセスするための参照制御部１３とで構成される。ヘッダーボックス部４から取り出された参照すべきテーブル番号信号、処理信号、リンク信号、参照データが参照制御部１３に例えば、２つ設けられた参照スタックレジスタ１４，１５にそれぞれ出力される。
【００２３】
また、参照制御部１３と２つのルックアップテーブル１１，１２とはバス１６を介して接続され、また各テーブルの出力側は、アドレスバス１７に接続してＩＤ値を出力し、及びマッチング信号を出力するバス１８が設けられている。
【００２４】
本実施形態の処理動作について説明するために、図６は、ヘッダー情報の下位層に相当するＩＰヘッダー情報を処理するためのＩＰヘッダーボックスと、上位層に相当するＴＣＰヘッダー情報を処理するためのＴＣＰヘッダーボックスにおける定義の一例を示し、以下図４と図６と共に、図５に示すフローチャートを参照して説明する。
【００２５】
ここで、処理信号（ｐｒｏｃ）は、フラグ状態が“１”の時に、該当するレジスタの登録先アドレスに登録されている内容の比較を行うことを示す信号である。また、リンク信号（ｌｉｎｋ）は、フラグ状態が“１”の時に、登録内容を後に続く情報と連結して比較を行うことを示すものである。処理信号及びリンク信号のフラグ状態が共に“０”の時には、特別に連結した情報の最終比較を行うことを示すものである。具体的には、図４（ａ）に示す参照制御部１３における参照スタックレジスタ１４，１５を参照して説明する。この図において、ヘッダーボックス部４内の情報処理レジスタでｂｙｐｓ：ｌｉｎｋと設定されていた場合には、参照スタックレジスタ１４のシェーディングされている部分に参照データ１４ａが登録されている。そして、次の処理が比較処理（ｐｒｏｃ）であれば、このｂｙｐｓ：ｌｉｎｋの指示によって入力された参照データ１４ａの後に参照データ１４ｂが登録される。尚、この比較処理においては、この時点で比較を行うため、前の情報（参照データ１４ａ）と一緒になり、例えばルックアップテーブル１１に設定されたデータとの比較を行う。
【００２６】
しかし、ｂｙｐｓ：ｌｉｎｋではなく、ｐｒｏｃ：ｎｕｌｌの指示であったならば、この比較処理で終了させて、ＩＤ値を連結するフェーズはないものとする。但し、ｐｒｏｃ：ｎｕｌｌの指示の前にｂｙｐｓ：ｌｉｎｋが存在しないならば、このフィールド内だけの単体の比較処理となる。結果として、このｂｙｐｓ：ｌｉｎｋ→ｐｒｏｃ：ｘｘは、ｐｒｏｃ：ｌｉｎｋ→ｆｉｎａｌ＿ｃｏｍｐと同様な効果が得られるが、参照スタックレジスタを有効活用できるという点が異なっている。即ち、３２ビットの情報処理レジスタで対象となるデータが２種類あり、双方とも１６ビットのデータ量以下で、さらにこれらを１つの情報として扱いたい場合、ルックアップテープが３２ビットをサポートしているならば、ｂｙｐｓ：ｌｉｎｋ→ｐｒｏｃ：ｘｘの方が参照スタックレジスタの容量を有効的に活用する場合には、ルックアップテーブルとは１度の比較で済む。一方、ｐｒｏｃ：ｌｉｎｋ→ｆｉｎａｌ＿ｃｏｍｐの方は、参照データがルックアップテーブルのデータ幅以上になる場合に有効である。
【００２７】
最初に図６に示すように、ＩＰヘッダーボックスとＴＣＰヘッダーボックスの定義を行う（ステップＳ２１）。
【００２８】
次に、実際の処理に移行する。まず、インデックスのフラグが“０”か否かを判定する（ステップＳ２２）。この判定で、“０”であれば（ＹＥＳ）、何ら処理をせずにリターンする。しかし、“０”でなければ（ＮＯ）、処理信号が“０”及びリンク信号が“１”に定義されているか判定する（ステップＳ２３）。
【００２９】
この判定で、処理信号が“０”及びリンク信号が“１”に定義されていれば（ＹＥＳ）、比較処理を行わずにテーブル番号に対応する参照スタックレジスタ１４に参照データを登録する（ステップＳ２４）。尚、次に来る連結した参照データは参照スタックレジスタ１４に先に登録された参照データの末尾に連結して登録される。この登録の後終了する。
【００３０】
一方、ステップＳ２３で処理信号が“０”及びリンク信号が“１”と定義されていなければ（ＮＯ）、次に、処理信号が“１”及びリンク信号が“０”に定義されているか否かを判定する（ステップＳ２５）。この判定で、処理信号が“１”及びリンク信号が“０”と定義されていれば（ＹＥＳ）、この時点で該当する参照データで比較が行なわれＩＤ値は返さない（ステップＳ２６）。前述したように、この参照データは対応する参照スタックレジスタ１４に登録され、登録された値はルックアップテーブル１１に設定されたテーブルとの比較処理が行われる。この後、リターンして同様な処理が行われる。
【００３１】
しかし、ステップＳ２５で、処理信号が“１”及びリンク信号が“０”と定義されてなければ（ＮＯ）、処理信号が“１”及びリンク信号が“１”に定義されているか否かを判定する（ステップＳ２７）。この判定で処理信号が“１”及びリンク信号が“１”と定義されていれば（ＹＥＳ）、比較処理を行い、且つそこで得た戻り値をＩＤ値として、次の参照データに連結させる（ステップＳ２８）。図５に示した場合、デフォルトで参照スタックレジスタ１５をリンク先としているが、ヘッダーボックスにリンク先を明示するフィールドを設けてもよい。
【００３２】
一方、ステップＳ２７で、処理信号が“１”及びリンク信号が“１”に定義されていなければ（ＮＯ）、処理信号が“０”及びリンク信号が“０”として定義されているものとする（ステップＳ２９）。この定義により、ＩＤ値と該当する登録情報とを連結し、該当するテーブルとの比較処理を行う（ステップＳ３０）。連結させたデータの最終比較フェーズである。
【００３３】
以上説明したように、本実施形態によれば、ユーザーは、ヘッダーボックスに設けられた共通フォーマットのレジスタに所望する設定を行うだけで様々なデータ処理方法が設定可能となる。従って、設定変更にあたり、従来のようにソフトウエアの書き換えなどの必要が無い。また本実施形態は、ハードウエアであるレジスタに設定して、動作を予約して処理行うため、高速動処理が可能である。また、設定範囲にある程度の自由度を有しており、データ処理が参照や比較だけでなく、異なる処理にも容易に適用することができる。
【００３４】
次に図７には、第３の実施形態によるヘッダー処理装置の構成例を示し、データ処理について説明する。本実施形態では、主として、データソースの中で特に限定された数だけ参照すればよいデータが参照データの一部として存在した場合に、少なくとも２つに分割してそれぞれに参照する２段式の参照方法である。例えば、ある応用分野では、宛先ＩＰアドレスは特定の何種類かのアドレスしか必要なく、他の参照対象と別個に扱ってよいケースがある。このような場合、宛先ＩＰアドレスは比較情報としては冗長であり、１つにまとめるよりはむしろ通信データを分割して、それぞれに参照した方がルックアップテーブルのリソースが少なくて済む。
【００３５】
このヘッダー処理装置には、バス２０を介して参照制御部２１とルックアップテーブル２２，２３とが接続されている。この参照制御部２１内には、前述したヘッダーボックスにより通信データから取り出された参照データ（送信元ＩＰアドレス：ＩＰＳＡ、送信元ポート番号：ＴＣＰ  Ｓｒｃ、宛先ポート番号：ＴＣＰ  Ｄｓｔ）と、テーブルからの戻り値となるマッチング信号（若しくはＩＤ値）を一時的に格納可能な参照スタックレジスタ２４が設けられている。
【００３６】
また本実施形態におけるルックアップテーブル２２は複数のレジスタからなり、各レジスタは宛先ＩＰアドレス（ＩＰＤｓｔ）が登録されているデータ参照領域と、その宛先ＩＰアドレスに関連づけた戻り値例えばＩＤ値が登録される対応データ格納領域とから構成されているテーブル２５，２６が設けられている。図７においては、２つのテーブルを示しており、データ参照領域には、それぞれ宛先ＩＰアドレス１，２が設定され、対応データ格納領域には戻り値となるＩＤ値（ＩＤ（１），ＩＤ（２））がそれぞれ格納されている。この戻り値は、各情報ソースに一意に決まるよう、ＩＤ値を割り振っている。
【００３７】
また、ルックアップテーブル２３には、例えばテーブル２７が設けられ、前述したＩＤ値と関連づけて、ＩＰ  ＳＡ＋ＴＣＰ  ＳｒｃＰ＋ＴＣＰ  ＤｓｔＰが登録され、場合によってはさらにその他のデータも付加されるように格納されている。尚、参照すべき情報が少ない場合は、レジスタからなるルックアップテーブルで対応できるが、参照するデータ容量が大きい場合には、ＣＡＭのような大容量のメモリを用いればよい。但し、レジスタを用いた場合には、低コストで且つ高速処理となる。レジスタに換わってＣＡＭを用いた場合には、データ参照領域がＣＡＭ領域となり、対応データ格納領域がＲＡＭ領域なる。
【００３８】
このように構成されたヘッダー処理装置における参照動作について、図８のフローチャートを参照して説明する。まず、ネットワーク上から到来するパケット形態の通信データがデータ入力部へ到来して前述した様にヘッダーボックスにより処理され、宛先ＩＰアドレスが抽出される（ステップＳ３１）。
【００３９】
また、この時に宛先ＩＰアドレスに続く参照データ（送信元ＩＰアドレス：ＩＰＳＡ、送信元ポート番号：ＴＣＰ  Ｓｒｃ、宛先ポート番号：ＴＣＰ  Ｄｓｔ）が参照データスタックレジスタ２４に格納される（ステップＳ３２）。そして、ルックアップテーブル２２で宛先ＩＰアドレスが参照されて登録されているか否かを判定する（ステップＳ３３）。
【００４０】
そして、この判定において、その宛先ＩＰアドレスがルックアップテーブル２２に登録されていた場合には（ＹＥＳ）、関連づけて登録されていたＩＤ値が先に参照データが格納されている参照データスタックレジスタ２４に戻り値として、格納される（ステップＳ３４）。
【００４１】
次に、参照データスタックレジスタ２４に格納される参照データとＩＤ値とを一組として、図７に示すテーブル２７に、この組が登録されているか否かを判定する（ステップＳ３５）。この判定においては、ＩＤ値が宛先ＩＰアドレスと交換されたものとなっているため、このような参照は、従来の送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号の４つを参照したことと同等の結果が得られることとなる。ここで、ルックアップテーブル２２のテーブル２５，２６の参照に使われるビット数はそれぞれ３２ビット、ルックアップテーブル２４のテーブル２７の参照に使われるのはＩＤ値が２ビットとすると、合計では、２＋３２＋１６＋１６＝６６ビットである。従って、従来の９６ビットの参照が本実施形態では、６６ビットの参照で同じ効果が得られていることを意味する。
【００４２】
そしてステップＳ３５の判定で、テーブル２７に参照した組が登録されていたならば（ＹＥＳ）、 通信データをシステムに取り込んでもよいことを示唆するマッチング信号を出力する（ステップＳ３６）。しかし、登録されていなければ（ＮＯ）、マッチング信号は出力されない。
【００４３】
以上のことから、前述した実施形態のように、テーブルを一度に参照する場合より少ないビット数で対応することができる。また、通信データ（パケット）の性質上、データが先頭から順に流れてくるため、ルックアップテーブル２２とルックアップテーブル２３の参照フェーズが一致する即ち同時に処理される可能性は非常に低い。
【００４４】
よって、これらのテーブルで比較を行うフェーズは通常分離されているため、前段の３２ビットバスと後段の６６ビットバスは兼用することが可能であり、ハードウェア構成上のバス巾削減の効果も得られる。
【００４５】
また前述したルックアップテーブル２２の最小参照数は１つである。この場合、ＩＤ値は不要であり、最小構成となる。このような構成は、例えば、ホストコンピュータのＴＣＰ／ＩＰの機能を一部ハードウエア化する場合などにおけるＣＡＭやレジスタの参照方法において有効である。これは、ホストコンピュータに割り振られるＩＰアドレスは、通常１個であり、識別のため送信元ＩＰアドレス、宛先ＩＰアドレス、送信元ポート番号、宛先ポート番号の４つの組の情報を比較する場合には、送信元アドレスは、いわば冗長な情報になっているためである。
【００４６】
以上説明したように、本実施形態によれば、参照項目を少なくとも２つに分離して、最初の項目を少ないビット数で表し、残りの項目に付与することにより、参照すべきデータのビット数を少なくすることができ、参照テーブルのリソースを節約させることができる。
【００４７】
また、パケットとして到来する通信データのヘッダー情報は、同時に参照フェーズが一致する即ち同時に処理される可能性が非常に低いため、バスを共有して使用でき、ハードウエアの面積削減が期待できる。ハードウエア上の冗長構成が削減されるため性能向上につながる。
【００４８】
【発明の効果】
以上詳述したように本発明によれば、ネットワークの通信データにおけるヘッダー情報の最初の参照データを容量の少ないＩＤ値に置き換えて、残りの参照データと取り込みのための参照比較を行い、取り込みのヘッダー処理を行うバス幅を減少及び共用させて、ハードウエアの面積削減とハードウエア上の冗長部分を削減し性能を向上させるヘッダー処理方法を提供することができる。
【図面の簡単な説明】
【図１】本発明のデータ処理装置を第１の実施形態に係るヘッダー処理装置に適用した構成例を示す図である。
【図２】ヘッダーボックスの構成例を示す図である。
【図３】第１の実施形態によるヘッダー処理について説明するためのフローチャートである。
【図４】第２の実施形態に係るデータ処理装置の構成例を示す図である。
【図５】第２の実施形態によるヘッダー処理について説明するためのフローチャートである。
【図６】第２の実施形態におけるヘッダーボックスの構成例を示す図である。
【図７】第３の実施形態によるヘッダー処理装置の構成例を示す図である。
【図８】第３の実施形態によるヘッダー処理について説明するためのフローチャートである。
【符号の説明】
１…データ入力部
２…ヘッダー情報取り出し部
３…制御部
４…ヘッダーボックス部
５…ルックアップテーブル
６…ホストコンピュータ
７…ヘッダーボックス（ＨＢＯＸ）
【図１】
0003925049.tif 000002
【図２】
0003925049.tif 000003
【図３】
0003925049.tif 000004
【図４】
0003925049.tif 000005
【図５】
0003925049.tif 000006
【図６】
0003925049.tif 000007
【図７】
0003925049.tif 000008
【図８】
0003925049.tif 000009