JP2009219065A - プロトコル処理装置及び処理方法 - Google Patents

Abstract

【課題】複数のレイヤプロトコル処理を統一的に実行できるようにし、処理の効率化を図る。
【解決手段】情報処理装置（プロトコル処理装置）１は、各レイヤプロトコルにおける情報領域を指し示すものとして、プロトコルの種別毎にタグを定義し、前記各レイヤプロトコルのタグに対する処理手順を共通フォーマットにて管理し、同一の演算器２０上で処理する構成（タグ抽出部１０、識別タグ情報データベース１２、演算機２０、フォーマットシート２１）となっている。
【選択図】図１

Description

この発明は、プロトコル処理装置及び処理方法に係り、詳しくは、複数のレイヤプロトコルのデータを処理するプロトコル処理装置及び処理方法に関する。

従来、レイヤ構造を持つ通信プロトコルの処理は、レイヤ別に閉じた処理機構を備え、レイヤ毎のプロトコル処理を実現している。しかしながら、レイヤ毎に処理機構を備える構成では、処理装置の小型化、処理速度の高速化を図ることは困難であるので、近年のネットワーク処理においては、従来のレイヤ毎に処理が閉じている形態に代えて、複数のレイヤを横断的に見て、データ処理を決定する形態、すなわち、クロスレイヤプロセッシング（マルチレイヤプロセッシング）が出現してきている。

クロスレイヤプロセッシング（クロスレイヤプロトコル処理）は、ブリッジ及びルータを一体化させたマルチレイヤスイッチに代表されるような、データリンク層（レイヤ２）とネットワーク層（レイヤ３）を複合的に扱うことからはじまり、その処理対象はトランスポート層（レイヤ４）処理へと拡大している。

これらのレイヤ２からレイヤ４のプロトコルにおいては、ヘッダ及びペイロード内に種々の情報領域がパケット又はフレームの先頭からの固定位置に配置されている。これらの情報領域のデータを複数使用して、パケット分類、データのルーティング、通過判定（フィルタリング）を行っている（例えば、特許文献１参照）。

ＴＣＰ/ＩＰ（Transmission Control Protocol/Internet Protocol）であれば、ＩＰレイヤ（レイヤ３）の送信元ＩＰアドレス、宛先ＩＰアドレス、プロトコル、ＴＣＰレイヤ（レイヤ４）の送信元ポート番号、宛先ポート番号の５種類のＩＰパケットヘッダフィールド、ＴＣＰパケットヘッダフィールドを同時に識別して、ＴＣＰのコネクションを識別する処理がファイヤウォール装置等で実行されている。

さらに、レイヤ４以下の情報に加えて、レイヤ５以上のアプリケーションレイヤの情報までも含めて、データ処理を行うクロスレイヤプロセッシングも出現してきている。

アプリケーションレイヤの処理の一例として、トランスポート層（レイヤ４）上で動作するプロトコル処理がある。例えば、ＳＩＰ(Session Initiate Protocol)や、ＳＭＴＰ(Simple Mail Transfer Protocol)、ＨＴＴＰ(HyperText Transfer Protocol)等である。これらアプリケーションレイヤのプロトコルには、プロトコル上の処理指示語であるメソッド（特許文献３）やメソッドに対する応答であるレスポンス、及びレスポンスコードがＡＳＣＩＩコードで記載されると同時に、その出現箇所がレイヤ４プロトコルのペイロード（上位レイヤプロトコルペイロード）内部で自由に配置されるものがある。

さらに、他の例として、上記プロトコルによって転送される構造化データ形式としてＸＭＬ (eXtensible Markup Language)やＨＴＭＬ（HyperText Markup Language）等がある。ＸＭＬやＨＴＭＬは、マークアップ言語の一種であり、文書内のデータ記述に関する指示文字列として“タグ”を有している。このタグによって、種々の情報、当該情報の種別、当該情報の領域が指定されている。

クロスレイヤプロセッシングでは、レイヤ２からレイヤ４までのプロトコルにおける情報領域の検知、解釈処理、及びＳＩＰ、ＨＴＴＰ、ＳＭＴＰ等のレイヤ５以上レイヤ７までのアプリケーションレイヤにおけるプロトコルでの処理指示語であるメソッド、レスポンス、レスポンスコード等の検知、解釈処理、及びＸＭＬ等のマークアップ言語におけるタグ、及びタグにて指定される内容の検知、及び構造解析処理を行うことが必要となる。

ネットワーク装置においては、レイヤ３又はレイヤ４までの処理を専用のハードウェアにて実施する構成が取られることがある。また、ネットワーク装置においては、レイヤ３又はレイヤ４までの処理を専用に行うネットワークプロセッサ(Network Processor Unit: NPU)が利用されるケースも多い。ネットワークプロセッサでは演算対象として、主として、ネットワークデータのヘッダ部分を対象としており、汎用ＣＰＵコアや専用命令を搭載したＲＩＳＣ（Reduced Instruction Set Computer: 縮小命令セットコンピュータ）によって実現されている。

また、従来、レイヤ４以上の処理はネットワーク端点である端末、サーバにて実施されることが一般的であり、その処理には汎用的な中央処理演算器（Central Processor Unit ＣＰＵ）が使用されることが一般的である。ネットワーク内の中間に配置されるネットワーク装置でレイヤ４以上の処理を実施する場合、汎用ＣＰＵや、汎用ＣＰＵと専用ハードウェアの組み合わせで実現する。

特許文献３では、ルータやレイヤ２−３スイッチのようなパケット中継装置において、従来からあるＡＳＩＣによるレイヤ２と３のルーティング及び低レイヤのパケットのフィルタリングで中継することが決定されたパケットに対して、さらにＡＳＩＣやネットワークプロセッサによる高レイヤのフィルタリング機能をレイヤ毎やパケットの解析内容に応じて複数用意してパケット中継処理を行い、マルチレイヤでの高速パケット処理方法を提供する方法が記載されている。

しかしながら、特許文献３ではレイヤ２からレイヤ４までの処理と、レイヤ５以上の処理は別々のＡＳＩＣやネットワークプロセッサ等の処理ブロックにて処理されており、処理回路が増大する、という課題があった。

特許文献４では、ネットワーク処理用途のマルチコアＣＰＵ（１チップに複数のＣＰＵコアが内蔵されているＣＰＵ）の構成が記載されている。
しかしながら、特許文献４では、レイヤ２からレイヤ４までの処理と、レイヤ５以上の処理を統一的に行う方法についての開示はなされていない。

特許文献１では、例としてＭＰＬＳ（Multi-Protocol Label Switch）とＩＰの２つの異なるレイヤ処理を統合して実行しており、処理結果が同じフォーマットで表現されてヘッダコントローラで処理される処理構成が記載されている。

また、特許文献２では、複数のレイヤのプロトコル処理で、２階層以上のプロトコルでも可能で、異なる階層の個別処理機能も同一のメソッド名で呼び出す事が可能な方法が記載されている。
しかしながら、特許文献１、特許文献２はいずれも、いずれもプロトコルのヘッダ情報の格納位置が固定的に判明している場合について言及しており、ＨＴＭＬやＸＭＬのタグのように出現位置が固定的でない場合のレイヤプロトコルを含む場合についての処理についての開示はなされておらず、統合して処理を行うことはできない。
特開２００１−２５１３５１ 特開平０８−１９５７８３ 特開２００３−３０４２９３ 特表２００７−５００８８６

上記のように、レイヤ２からレイヤ７までの複数のレイヤプロトコルを同時に処理する従来の装置において、次のような問題点があった。
第一の問題点は、従来型のレイヤ毎に処理部を設ける構成では、複数のレイヤを横断的に処理する場合に、その情報領域検出が多様であり、処理が非効率になる、ことである。
各レイヤプロトコルに含まれる情報とそのフォーマットは、当該プロトコルの策定時に独立に決定されている。このため、複数のレイヤを横断的に処理するに当たっては、情報構造に差異が有り、レイヤ間での統一的な処理を実現する上での処理オーバーヘッドが発生してしまう。
例えば、レイヤ２、３、４にそれぞれイーサネット（登録商標）、ＩＰ、ＵＤＰ（User Datagram Protocol）を使用しているパケットネットワーク上をＳＩＰのデータが転送されている場合、レイヤ２からレイヤ４までは、そのデータ構造を把握するためにパケット先頭からのデータ位置にて該当するフィールドを認識するが、ＵＤＰ上のＳＩＰにおいてはメソッド（INVITE、ACK、REGISTER等）は行頭又は／及び行頭から続く空白文字（スペース、タブ、改行コード）に続いて出現する特定の単語を検知することで認識する。このように、ヘッダ情報やメソッド等の情報領域の識別方法がプロトコルによって異なる。
それゆえ、レイヤ４までで検知した情報をレイヤ５以上の情報と統合して処理を実施することが容易ではない。

第二の問題点は、各レイヤでの情報のフォーマットの差異に加えて、実施される処理に相違があり、共通的な処理手順及び処理手順記法が、確立されていないことである。とりわけ、各レイヤプロトコルのフォーマットの整合性確認や情報抽出の処理が統一されておらず、処理が非効率である。それゆえ、各レイヤで個別に処理回路を保有するか、レイヤ別の固有な処理手順記法を用いて処理を記載する必要があり、各レイヤ処理を統合して実施することは、容易ではない。

この発明は、上述の事情に鑑みてなされたもので、複数のレイヤプロトコル処理を統一的に実行することができ、それゆえ、処理装置の小型化・簡素化、及び処理速度の高速化を図ることができるプロトコル処理装置及び処理方法を提供することを目的としている。

上記課題を解決するために、この発明の第１の構成は、複数のレイヤプロトコル処理を統一的に実行するクロスレイヤプロトコル処理装置に係り、各レイヤプロトコルにおける情報領域を指し示すものとして、プロトコルの種別毎にタグを定義し、複数のレイヤプロトコルにおける上記各タグを共通フォーマットで管理する手段を備えてなることを特徴としている。

また、この発明の第２の構成は、複数のレイヤプロトコル処理を統一的に実行するクロスレイヤプロトコル処理方法に係り、各レイヤプロトコルにおける情報領域を指し示すものとして、プロトコルの種別毎にタグを定義し、複数のレイヤプロトコルにおける上記各タグを共通フォーマットで管理することを特徴としている。

この発明の構成によれば、タグによる情報形式の共通化により、複数のレイヤプロトコル処理を統一的に実行することができる。このため、処理装置の小型化・簡素化、及び処理速度の高速化（処理の効率化）を図ることができる装置及び方法を提供することを目的としている。

まず、この発明の実施形態の概要について説明する。
この発明の実施形態であるプロトコル処理装置は、複数のレイヤプロトコル処理を統一的に実行するために、各レイヤプロトコルにおける情報領域を指し示すものとして、プロトコルの種別毎にタグを定義し（図２の識別タグ情報データベース１２）、上記各レイヤプロトコルの上記タグに対する処理手順を共通フォーマット（図１のフォーマットシート２１）にて管理する手段を備えて構成されている。
上記複数のレイヤプロトコル処理には、少なくとも、レイヤ４以下のプロトコル処理と、レイヤ５以上のプロトコル処理とが含まれている。

識別タグ情報データベース１２及びフォーマットシート２１は外部から設定可能である。この実施形態では、各レイヤプロトコルにおけるタグを識別し抽出するタグ抽出手段が付加されている（図１のタグ抽出部１０）。
上記タグ抽出手段は、上記タグが明示的に指定される構造化データ形式で記述されたデータが入力されたときは、該タグと該タグにより指定される情報領域であるタグ内容を抽出する機能を有している。
上記タグ抽出手段は、ＸＭＬ(eXtensible Markup Language)又はＨＴＭＬ（HyperText Markup Language）のようにブラケット＜＞でタグが明示的に指定される構造化データ形式で記述されたデータが入力されたときは、上記タグと上記タグにより指定される情報領域である上記タグ内容を抽出する（図２のタグ抽出コア部１１）。

また、上記タグ抽出手段は、ブラケット＜＞でタグが明示的に指定されていないプロトコルデータが入力されたときは、上記タグと上記タグ内容を、行頭又は／及び行頭から続く空白文字（スペース、タブ、改行コード）に続いて出現する特定の単語と、該特定の単語に続いて出現する文字列（改行コード等で終了位置を指定する）で識別し、抽出する機能を有している。
上記タグ抽出手段は、ＳＩＰ(Session Initiate Protocol)データ、ＳＭＴＰ(Simple Mail Transfer Protocol)データ又はＨＴＴＰ(HyperText Transfer Protocol)データが入力されたときは、上記タグと上記タグ内容を、行頭又は／及び行頭から続く空白文字（スペース、タブ、改行コード）に続いて出現する特定の単語と、該特定の単語に続いて出現する文字列（改行コード等で終了位置を指定する）で識別し、抽出する（図２のタグ抽出コア部１１）。

また、上記タグ抽出手段は、パケットデータが入力されたときは、上記タグと上記タグ内容を、上記パケットデータの先頭からの位置情報にて情報領域を識別し、抽出する機能も有している。レイヤ４以下のプロトコルに多く見られるが、この場合、位置情報を取得する手段を設け（図２のカウンタ１３）、取得した位置情報から情報領域を特定し、該当領域に対応するタグ名を付与する（図２のタグ抽出コア部１１）。

また、この実施形態では、各レイヤプロトコルのタグに対する処理手順として、各レイヤプロトコルの指定されたタグに対するタグ情報の整合性確認処理、入力データから指定された上記タグのタグ内容を抽出する処理、抽出した上記タグ内容の検索処理、及び検索処理結果の出力処理を順次実施する処理手順実施手段（図１の演算器２０、フォーマットシート２１、パターン検索制御部３０、パターン検索部３１）も備えている。
上記処理手順実施手段は、上記タグ情報の整合性確認処理を実施する際には、ＸＭＬのスキーマチェックの少なくとも一部を利用する。
抽出タグの検索処理実施手段は、タグ検索処理を実施する部位に内包される検索対象データが外部から設定可能である（図１のパターン検索部３１）。

この実施形態による第１の効果は、タグ抽出手段（タグ抽出部１０）におけるタグの共通化により、タグ抽出手段（タグ抽出部１０）及び処理手順実施手段（演算器２０）におけるタグ処理回路の共通化による回路量削減である。その理由は、この実施形態では、ＸＭＬ、ＨＴＭＬのタグ情報や、ＳＩＰ、ＨＴＴＰ、ＳＭＴＰのメソッド、メソッドに対するレスポンス、及びレスポンスコード、パケットヘッダのフィールドを、共通的な“タグ”として、データ内にて識別した上で抽出している。また、パケットヘッダフィールドやパケットペイロードフィールドのようにタグ名が陽にない場合はタグ名を付与することで明示的に指定可能とすることで、タグの処理の共通化を行っている。これにより、情報処理装置１内部にてタグによる情報の取り扱いが共通化されるためである。
第２の効果は、タグによる情報形式の共通化（共通フォーマット化）により、処理手順実施手段（演算器２０及びフォーマットシート２１）における処理手順が共通化され、これによる処理回路の簡略化や、複数の処理回路を統合することによる回路規模削減である。
第３の効果は、タグによる情報形式の共通化（共通フォーマット化）により、フォーマットシート２１に格納する処理指示方法が統一化されることにより、処理指示情報が簡便になることである。

実施形態１

以下、図面を参照して、この発明の実施形態について詳細に説明する。
図１は、この発明の一実施形態である情報処理装置の電気的構成を概略示すブロック図である。この実施形態の情報処理装置１は、図１に示すように、タグ抽出部１０と、演算器２０と、フォーマットシート２１と、パターン検索制御部３０と、パターン検索部３１とから概略構成され、この情報処理装置１に外部から入力データ２とプロトコル情報３が入力されると、構成各部１０、２０、２１、３０、３１が動作して後述の処理が実行され、外部へ出力データ４と処理結果５が出力される。

ここで、入力データ２としては、通信用のパケットデータや、プロトコルの特定済であるパケットデータ列、ＴＣＰのデータストリーム等のパケット列から再生された上位プロトコルのデータストリーム等を挙げることができる。上記通信用のパケットデータとしては、例えば、イーサネットフレームやＩＰパケット、ＴＣＰ／ＵＤＰパケット等を挙げることができる。また、上記データストリームとしては、例えば、ＳＩＰ(Session Initiate Protocol)データや、ＳＭＴＰ(Simple Mail Transfer Protocol)データ、ＨＴＴＰ(HyperText Transfer Protocol)データ、また、上記のプロトコルによって転送されるＸＭＬ(eXtensible Markup Language)データ等を挙げることができる。

上記プロトコル情報３は、入力データ２が属する１つ又は複数のプロトコルを示す情報からなっている。
例えば、入力データ２がイーサネットフレームであるときは、プロトコル情報３として“イーサネット”が情報処理装置１に示される。また、入力データ２がイーサネットフレームで、内部にＩＰv４（Internet Protocol version ４）パケット、さらに、その内部にＴＣＰ、さらに、その内部にＳＩＰデータが含まれていると判明しているときは、プロトコル情報３として、“イーサネット、ＩＰv４、ＴＣＰ、ＳＩＰ”が情報処理装置１に示されるように構成されても良い。

上記出力データ４は、入力データ２と同種のデータが出力される。もちろん、情報処理装置１内の処理によって、入力データ２が加工され、データの一部が変換されていても良い。
上記処理結果５は、情報処理装置１内の処理にて明らかになる結果である。結果の例としては、入力したパケットデータが属している１つ又は複数のプロトコル情報、ＴＣＰやＵＤＰパケットが属する一連のパケット列を識別するフローの識別子、入力データ２に対するフォーマットチェックの結果（適合／非適合）、入力データ２に対する通過判定（通過／廃棄）、入力データ２に対する出力方路情報（スイッチ、ルータにおける出力物理ポート番号）等を挙げることができる。

上記タグ抽出部１０は、情報処理装置１に入力される入力データ２とプロトコル情報３とから、該当プロトコルにおけるタグ情報１５の識別と抽出、及び入力データ２に内包される上位レイヤプロトコルの識別を行い、演算器２０に入力データ２と識別抽出されたタグ情報１５とを通知する。
ここで、タグ情報１５とは、入力データ２に含まれる情報領域であり、例えば、ＸＭＬ、ＨＴＭＬ（HyperText Markup Language）等のように、ブラケット＜＞で囲まれて示される要素名（これを「タグ」と呼ぶ）とタグで指定される内容（これを「タグ内容」と呼ぶ）とから構成される。
なお、この実施形態では、ブラケット＜＞を使用していないプロトコルにおいても、例えば、ＨＴＴＰにおけるメソッド(GET、HEAD、PUT等)、メソッド及びメソッドに対するレスポンスに含まれるヘッダとヘッダ内の値、レスポンスとレスポンスコード等もタグとタグ内容とから構成されるタグ情報と見なすことができる。
ＳＩＰにおいても、メソッド（INVITE、ACK、REGISTER等）、メソッド及びメソッドに対するレスポンスとレスポンスコード、もタグとタグ内容としてタグ情報と見なすことができる。

要するに、行頭又は／及び行頭から続く空白文字（スペース、タブ、改行コード）に続いて出現する特定の単語と、特定の単語に続いて出現する文字列（改行コード等で終了位置を指定する）は、タグとタグ内容として、ここで言うタグ情報と見なすことができる。

さらに、パケットのヘッダ内のフィールドも、タグ情報と見なすことができる。この場合、タグ（要素名）は入力データ２上に陽には現れないものの、プロトコル規定上の名称をタグと見なせば良い。パケットヘッダフィールドは、パケットのフォーマット規定に従いパケットの先頭からのバイト位置及びビット位置と、バイト長及びビット長にて識別可能である。

例えば、イーサネットフレームの第１３バイト（ネットワークバイトオーダーでのイーサネットフレームの先頭バイト（宛先MACアドレスに属する）を第１バイトとする）から出現する２バイトのフィールドは、イーサネット（登録商標）におけるＬｅｎｇｔｈ/Ｔｙｐｅフィールドである。これを、タグ名称「イーサネット/Ｔｙｐｅ」と考えることができる。当該イーサネットフレームが上位プロトコルとしてＩＰv４パケットを収容している場合、Ｔｙｐｅフィールドには０８００（１６進表記）が設定されている。したがって、タグ名称「イーサネット/Ｔｙｐｅ」のタグ内容は０８００（１６進表記）となる。

上記演算器２０は、予め蓄積してあるフォーマットシート２１のフォーマット情報に基づいて、タグ抽出部１０から供給される入力データ２とタグ情報１５とを検査し、該当フォーマットとの整合性確認、及び、フォーマットシート２１に記載の情報により指定された１つ又は複数のタグの値の抽出処理、及び、抽出した１つ又は複数のタグの値の検索処理等を実施して、情報処理装置１の外部に、出力データ４及び処理結果５を出力する。
演算器２０は、フォーマットシート２１の内容に基づいて、処理変更が可能であれば、中央処理演算器（ＣＰＵ; Central Processor Unit）でも良いし、専用シーケンス回路、また、他の実現可能な回路構成であっても良い。

上記フォーマットシート２１は、演算器２０にて実施する入力データ２及びタグ情報１５の整合性確認、及び抽出するタグの情報、抽出したタグの検索処理指示を記載したデータベースである。このフォーマットシート２１には、各プロトコルの整合性確認を行うために、構成されるタグの名称やフォーマットの情報等が共通形式にて記載されていて、また、抽出するタグ、抽出したタグの検索処理指示も共通形式にて記載されている。例えば、ＸＭＬにおけるＸＭＬ Ｓｃｈｅｍａ表記又は上記ＸＭＬ Ｓｃｈｅｍａ表記を拡張した形式、又はバイナリデータとしての構造体形式を共通形式として好適に用いることができる。

上記パターン検索制御部３０は、演算器２０から指示があると、指定されたパターンの検索処理をパターン検索部３１に対して命令し、パターン検索部３１からの検索結果を演算器２０に応答する。

パターン検索部３１は、パターン検索制御部３０からの指示に従って、指定されたパターンの検索処理を実施し、検索結果をパターン検索制御部３０に応答する。上記パターン検索部３１は、例えば、ＴＣＡＭ(Ternary Content Addressable Memory)、検索専用ハードウェア回路、又は／及び検索専用プロセッサ等から構成され、１つ又は複数の検索キーでの検索を実施すると共に、ＬＰＭ（Longest Prefix Match）や、Ｅｘａｃｔ Ｍａｔｃｈや、複数フィールドによる複合一致検索処理等を実施する。

図２は、情報処理装置１を構成するタグ抽出部１０の電気的構成を概略示すブロック図である。
タグ抽出部１０は、図２に示すように、タグ抽出コア部１１と、識別タグ情報データベース１２と、カウンタ１３とから概略構成される。
上記タグ抽出コア部１１は、識別タグ情報データベース１２を参照して、入力データ２からタグ情報１５を識別し、入力データ２と共に識別したタグ情報１５を出力する。

ここで、入力データ２として、例えば、ＸＭＬ、ＨＴＭＬのようにブラケット（＜＞）でタグを指定しているデータが入力されたときは、タグ抽出コア部１１は、ブラケット及びタグ名によって、入力データ２からタグを識別する。

また、入力データ２として、例えば、ＳＩＰやＨＴＴＰ、ＳＭＴＰ等のデータのようにブラケット＜＞を使用していないデータが入力されたときは、タグ抽出コア部１１は行頭又は行頭から続く空白文字（スペース、タブ、改行コード）に続いて出現する特定の単語と、当該特定の単語に続いて出現する文字列をタグ情報として識別する。

また、入力データ２として、パケットで、パケットヘッダやペイロード内のバイト位置又はビット位置によって、フィールドが特定される類のデータが入力されたときは、タグ抽出コア部１１は、カウンタ１３からの位置情報を使用して、入力データ２からのバイト位置、ビット位置を特定して、位置情報をタグ識別に使用する。

上記識別タグ情報データベース１２は、入力データ２のプロトコル毎に識別されるタグが記載されている。
上記カウンタ１３は、入力データ２のバイトカウント、ビットカウントを行い、入力データ２の位置情報としてカウンタ値を出力し、当該出力結果は、入力データ２としてパケットが入力されたときに、タグ抽出コア部１１で使用される。

タグ抽出部１０は、タグ検索処理が可能である限り、例えば、ＴＣＡＭや、抽出専用ハードウェア回路(パターン検知エンジン)、又は／及び抽出専用プロセッサ又は中央処理演算器等から構成されても良い。

次に、図３、図４及び図５を参照して、この実施形態の情報処理装置の動作について説明する。
図３は、同情報処理装置１（図１及び図２）の各部が実行するデータ処理動作手順を概略示すフローチャートである。情報処理装置１は、まず、ステップＳＰ２０１において、識別タグ情報データベース１２への識別タグ情報の登録、フォーマットシート２１へのデータ登録、及びパターン検索部３１へのデータ登録を行う。ステップＳＰ２０１のデータ登録の詳細については、図４を参照して後述する。次に、ステップＳＰ２０２において、外部から入力データ２と、プロトコル情報３とを入力する。次に、ステップＳＰ２０３へ進み、タグ抽出部１０において、タグ抽出コア部１１は、入力データ２から、プロトコル情報３に基づいて、識別タグ情報データベース１２を参照して、タグ情報１５の識別及び抽出を行う。

ここで、データ内にタグ名が陽に現れないもののパケットヘッダやペイロード内のバイト位置又はビット位置によってタグを特定できる入力データ２が入力されたときは、タグ抽出コア部１１は、入力データ２とカウンタ１３にて計測する位置情報を使用して、タグの識別及び抽出を行う。
また、タグ名が陽に現れるデータ形式（例えば、ＸＭＬやＨＴＭＬ、ＳＩＰやＨＴＴＰ、ＳＭＴＰ等）の入力データ２が入力されたときは、タグ抽出コア部１１は明示されているタグ名を使用してタグの識別及び抽出を行う。抽出したタグ情報は、入力データ２と共に演算器２０に出力する。

ステップＳＰ２０４において、演算器２０は、入力データ２及びタグ抽出部１０にて抽出されたタグ情報１５に対して、フォーマットシート２１に従っての処理を実行する。演算器２０の処理が完了すると、一連のデータ処理動作手順（ステップＳＰ２０１−ＳＰ２０４）が終了する。ステップＳＰ２０４の演算器２０の処理実行の詳細については、図５を参照して後述する。

図４は、ステップＳＰ２０１（図３）のデータ登録手順を示すフローチャートである。
情報処理装置１は、まず、ステップＳＱ３０１において、タグ抽出部１０（図２）内の識別タグ情報データベース１２に、タグ抽出部１０で識別及び抽出されるタグ情報１５を登録する。次に、ステップＳＱ３０２において、情報処理装置１内のフォーマットシート２１（図１）へのデータ登録を実施する。データ登録は、以下の４項目［１］−［４］を実施する。

［１］フォーマットの整合性確認を行うデータを、フォーマットシート２１に登録する。フォーマットシート２１に登録するフォーマット整合性確認用データは、例えば、情報処理装置１の入力データ２から入力されるデータがＸＭＬデータであるときは、ＸＭＬＳｃｈｅｍａ等のスキーマチェックを実施するためのタグ情報を登録する。また、入力データ２から入力されるデータがＳＩＰ、ＨＴＴＰ、ＳＭＴＰ等の非ＸＭＬ系データであるときは、タグ情報とタグのフォーマットの情報を登録する。入力データ２から入力されるデータがパケットデータであるときは、パケットヘッダ内のフィールドとしてパケットの先頭バイトからの位置で特定されるフィールドのフィールド名とフィールド値を“タグ”と定義しているので、そのタグ情報とタグのフォーマットの情報を登録する。検証対象とする上記ＸＭＬタグ、又は非ＸＭＬ系データ系のタグ、又はパケット系データのタグ、の登録形式は共通形式を使用する。

［２］入力されるデータから抽出するタグを、フォーマットシート２１に登録する。抽出対象とする上記ＸＭＬタグ、又は非ＸＭＬ系データ系のタグ、又はパケット系データのタグ、の登録形式は共通形式を使用する。
［３］パターン検索部（図１）３１にて検索するタグを、フォーマットシート２１に登録する。検索対象とする上記ＸＭＬタグ、又は非ＸＭＬ系データ系のタグ、又はパケット系データのタグの登録形式は、共通形式を使用する。
［４］情報処理装置１から出力する出力データ４及び処理結果５を、フォーマットシート２１に登録する。出力対象とするデータの登録形式は、タグと同様の共通形式を使用する。

次に、ステップＳＱ３０３において、演算器２０内で入力データ２から抽出したタグによる検索対象のデータを、パターン検索部３１に登録する。
例えば、宛先ＩＰアドレスによるパケット転送の出力物理ポートを検索する目的のときは、ＩＰアドレスを検索キーとして、出力物理ポート番号を検索結果として登録する。他の検索キーの登録例としては、ＳＩＰのＳＩＰ-ＵＲＬや、ＨＴＴＰのＵＲＬ等がある。以上で、データ登録（ステップＳＰ２０１）の詳細な処理が完了する。

図５は、演算器２０のフォーマットシート２１に従っての処理実行（ステップＳＰ２０４（図３））の詳細な手順を示すフローチャートである。
まず、演算器２０は、ステップＳＲ４０１において、フォーマットシート２１に従って、入力データのフォーマットチェックを実施する。
このフォーマットチェックでは、入力データ２が従っているプロトコルにおいて、必要なタグが全て入力されること、存在が許容されているタグのみが入力データ２に含まれていること、を確認する。ここで、ＸＭＬの場合はスキーマによるチェックを行う。ＨＴＭＬ、ＨＴＴＰ、ＳＭＴＰ、ＳＩＰ等、又はタグ名が入力データに含まれていない場合でも、ステップＳＰ２０３で実施したタグ情報の識別及び抽出にて陽になっているタグに対して、ＸＭＬのスキーマチェックと同様のチェックを実施する。

ＸＭＬで記述される構造化データと比較して、ＳＩＰ, ＨＴＴＰ, ＳＭＴＰのメソッド及びレスポンスといった非構造化データやパケットのヘッダフィールド又はペイロードフィールドにおける検証ルールが簡易な場合、ＸＭＬのタグ情報正当性確認方法の部分集合による確認方法で実施する。

次に、演算器２０は、ステップＳＲ４０２へ進み、フォーマットシート２１に従って、入力データ２から指定された１つ又は複数のタグのタグ内容の抽出を実施する。
ステップＳＲ４０１、ＳＲ４０２における入力データのチェック及びタグ内容抽出は、入力データ単位の逐次の状態遷移管理によって実施可能である。

次に、演算器２０は、ステップＳＲ４０３へ進み、フォーマットシート２１に従って、抽出タグ内容の検索処理を実施する。実施に当たって、演算器２０内にて実施しても良いし、パターン検索制御部３０及びパターン検索部３１を使用しても良い。抽出したタグ内容による検索処理の結果は、演算器２０に収容される。

次に、演算器２０は、ステップＳＲ４０４へ進み、フォーマットシート２１に従って、抽出タグ内容の検索結果を使用して、処理結果５を情報処理装置１の外部に出力する。以上でステップＳＰ２０４の詳細な処理が完了する。

上記したように、この実施形態の構成によれば、ＸＭＬ、ＨＴＭＬのタグ情報や、ＳＩＰ、ＨＴＴＰ、ＳＭＴＰのメソッド、メソッドに対するレスポンス、及びレスポンスコード、パケットヘッダのフィールドを、共通的な“タグ”として、データ内にて識別した上で抽出している。

また、パケットヘッダフィールドやパケットペイロードフィールドのようにタグ名が陽にない場合はタグ名を付与することで明示的に指定可能とすることで、タグの処理の共通化を行っている。これにより情報処理装置１内部にてタグによる情報の取り扱いが共通化され、処理回路の共通化による回路量削減の効果がある。

また、タグによる情報形式の共通化により、演算器２０及びフォーマットシート２１における処理手順が共通化される。これにより、ＸＭＬのスキーマチェックによるタグ情報正当性確認方法を他のデータ形式から抽出したタグ情報の正当性確認方法にも適用可能となり、処理手順の共通化による処理回路の簡略化や、複数の処理回路を統合することによる回路規模削減の効果がある。また、フォーマットシート２１に格納する処理指示方法の統一化により、処理指示情報の簡便化の効果がある。

さらに、一般にＸＭＬで記述される構造化データと比較して、ＳＩＰ、ＨＴＴＰ、ＳＭＴＰのメソッド及びレスポンスといった非構造化データやパケットのヘッダフィールド又はペイロードフィールドにおける検証ルールは、相対的に簡易なケースが多い。このため、ＸＭＬのタグ情報正当性確認方法の部分集合で対応できる。

以上、この発明の実施形態を図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計の変更等があってもこの発明に含まれる。

この発明は、ネットワークにおけるパケット処理装置、とりわけ複数のレイヤプロトコルを横断的に処理する装置におけるパケット処理装置にも、適用できる。マルチレイヤスイッチやファイヤウォール装置、負荷分散装置、ゲートウェイ装置、音声パケットのゲートウェイ装置であるボーダー・ゲートウェイ・ファンクション (Border Gateway Function)、ＧＧＳＮ（Gateway GPRS (General Packet Radio Service) Service Node）、ＳＧＳＮ（Serving GPRS Service Node）等にも適用できる。

この発明の一実施形態である情報処理装置の電気的構成を示すブロック図である。 同情報処理装置を構成するタグ抽出部の電気的構成を詳細に示すブロック図である。 同情報処理装置の各部が実行するデータ処理動作手順を概略示すフローチャートである。 データ処理動作手順におけるデータ登録手順（ステップＳＰ２０１）を詳細に示すフローチャートである。 同情報処理装置を構成する演算器の処理手順を詳細に示すフローチャートである。

符号の説明

１ 情報処理装置（プロトコル処理装置）
２ 入力データ
３ プロトコル情報
４ 出力データ
５ 処理結果
１０ タグ抽出部（タグ抽出手段）
１１ タグ抽出コア部
１２ 識別タグ情報データベース（共通フォーマットで管理する手段、データベース）
１３ カウンタ
１５ データ及びタグ情報
２０ 演算器
２１ フォーマットシート（共通フォーマットにて管理する手段、共通フォーマット）
３０ パターン検索制御部
３１ パターン検索部

Claims (26)

1. 複数のレイヤプロトコル処理を統一的に実行するプロトコル処理装置であって、
   各レイヤプロトコルにおける情報領域を指し示すものとして、プロトコルの種別毎にタグを定義し、複数のレイヤプロトコルにおける前記各タグを共通フォーマットで管理する手段を備えてなることを特徴するプロトコル処理装置。
2. 複数のレイヤプロトコル処理を統一的に実行するプロトコル処理装置であって、
   各レイヤプロトコルにおける情報領域を指し示すものとして、プロトコルの種別毎にタグを定義し、前記各レイヤプロトコルの前記タグに対する処理手順を前記共通フォーマットにて管理する手段を備えてなることを特徴とするプロトコル処理装置。
3. 前記複数のレイヤプロトコル処理には、少なくとも、レイヤ４以下のプロトコル処理と、レイヤ５以上のプロトコル処理とが含まれていることを特徴とする請求項１又は２記載のプロトコル処理装置。
4. 入力データのプロトコル毎に識別される前記タグを記載するデータベースが、内設又は外設されていることを特徴とする請求項１又は２記載のプロトコル処理装置。
5. 前記共通フォーマットは外部からの設定が可能であることを特徴とする請求項１又は２記載のプロトコル処理装置。
6. 前記各レイヤプロトコルにおける前記タグを識別し抽出するタグ抽出手段が付加されていることを特徴とする請求項１又は２記載のプロトコル処理装置。
7. 前記タグ抽出手段は、前記タグが明示的に指定される構造化データ形式で記述されたデータが入力されたときは、該タグと該タグにより指定される情報領域であるタグ内容を抽出する機能を有していることを特徴とする請求項６記載のプロトコル処理装置。
8. 前記タグ抽出手段は、前記タグが明示的に指定されていないプロトコルデータが入力されたときは、前記タグと前記タグ内容を、行頭又は／及び行頭から続く空白文字に続いて出現する特定の単語と、該特定の単語に続いて出現する文字列で識別し、抽出する機能を有していることを特徴とする請求項６記載のプロトコル処理装置。
9. 前記タグ抽出手段は、パケットデータが入力されたときは、前記タグと前記タグ内容を、前記パケットデータの先頭からの位置情報にて情報領域を識別し、抽出する機能を有していることを特徴とする請求項６記載のプロトコル処理装置。
10. 前記タグ抽出手段は、ＸＭＬ(eXtensible Markup Language)又はＨＴＭＬ（HyperText Markup Language）で記述されたデータが入力されたときは、前記タグと前記タグにより指定される情報領域である前記タグ内容を抽出することを特徴とする請求項７記載のプロトコル処理装置。
11. 前記タグ抽出手段は、ＳＩＰ(Session Initiate Protocol)データ、ＳＭＴＰ(Simple Mail Transfer Protocol)データ又はＨＴＴＰ(HyperText Transfer Protocol)データが入力されたときは、前記タグと前記タグ内容を、行頭又は／及び行頭から続く空白文字に続いて出現する特定の単語と、該特定の単語に続いて出現する文字列で識別し、抽出することを特徴とする請求項８記載のプロトコル処理装置。
12. 前記タグ抽出手段は、前記パケットデータの情報領域を識別して抽出する機能として、データの位置情報を取得する手段を備えていることを特徴とする請求項９記載のプロトコル処理装置。
13. 前記各レイヤプロトコルの前記タグに対する前記処理手順として、各レイヤプロトコルの指定されたタグに対するタグ情報の整合性確認処理、入力データから指定された前記タグのタグ内容を抽出する処理、抽出した前記タグ内容の検索処理、及び検索処理結果の出力処理を順次実施する処理手順実施手段を備えていることを特徴とする請求項２記載のプロトコル処理装置。
14. 前記処理手順実施手段は、前記タグ情報の整合性確認処理を実施する際には、ＸＭＬのスキーマチェックの少なくとも一部を利用することを特徴とする請求項１３記載のプロトコル処理装置。
15. 前記抽出タグの検索処理実施手段は、タグ検索処理を実施する際に利用される検索対象データを外部から設定できることを特徴とする請求項１３記載のプロトコル処理装置。
16. 複数のレイヤプロトコル処理を統一的に実行するプロトコル処理方法であって、
    各レイヤプロトコルにおける情報領域を指し示すものとして、プロトコルの種別毎にタグを定義し、
    複数のレイヤプロトコルにおける前記各タグを共通フォーマットで管理することを特徴するプロトコル処理方法。
17. 複数のレイヤプロトコル処理を統一的に実行するプロトコル処理方法であって、
    各レイヤプロトコルにおける情報領域を指し示すものとして、プロトコルの種別毎にタグを定義し、
    前記各レイヤプロトコルの前記タグに対する処理手順を前記共通フォーマットにて管理することを特徴とするプロトコル処理方法。
18. 前記複数のレイヤプロトコル処理には、少なくとも、レイヤ４以下のプロトコル処理と、レイヤ５以上のプロトコル処理とが含まれていることを特徴とする請求項１６又は１７記載のプロトコル処理方法。
19. 前記各レイヤプロトコルにおける前記タグを識別し抽出するタグ抽出処理が付加されていることを特徴とする請求項１６又は１７記載のプロトコル処理方法。
20. 前記タグ抽出処理では、前記タグが明示的に指定される構造化データ形式で記述されたデータが入力されたときは、該タグと該タグにより指定される情報領域であるタグ内容を抽出することを特徴とする請求項１９記載のプロトコル処理方法。
21. 前記タグ抽出処理では、前記タグが明示的に指定されていないプロトコルデータが入力されたときは、前記タグと前記タグ内容を、行頭又は／及び行頭から続く空白文字に続いて出現する特定の単語と、該特定の単語に続いて出現する文字列で識別し、抽出することを特徴とする請求項１９記載のプロトコル処理方法。
22. 前記タグ抽出処理では、パケットデータが入力されたときは、前記タグと前記タグ内容を、パケットデータの先頭からの位置情報にて情報領域を識別し、抽出することを特徴とする請求項１９記載のプロトコル処理方法。
23. 前記タグ抽出処理では、ＸＭＬ(eXtensible Markup Language)又はＨＴＭＬ（HyperText Markup Language）で記述されたデータが入力されたときは、前記タグと前記タグにより指定される情報領域である前記タグ内容を抽出することを特徴とする請求項２０記載のプロトコル処理方法。
24. 前記タグ抽出処理では、ＳＩＰ(Session Initiate Protocol)データ、ＳＭＴＰ(Simple Mail Transfer Protocol)データ又はＨＴＴＰ(HyperText Transfer Protocol)データが入力されたときは、前記タグと前記タグ内容を、行頭又は／及び行頭から続く空白文字に続いて出現する特定の単語と、該特定の単語に続いて出現する文字列で識別し、抽出することを特徴とする請求項２１記載のプロトコル処理方法。
25. 前記各レイヤプロトコルの前記タグに対する前記処理手順として、各レイヤプロトコルの指定されたタグに対するタグ情報の整合性確認処理、入力データから指定された前記タグのタグ内容を抽出する処理、抽出した前記タグ内容の検索処理、及び検索処理結果の出力処理を順次実施することを特徴とする請求項１７記載のプロトコル処理方法。
26. 前記タグ情報の整合性確認処理を実施する際には、ＸＭＬのスキーマチェックの少なくとも一部を利用することを特徴とする請求項２５記載のプロトコル処理方法。

Images