(57)【要約】      （修正有）【課題】ネットワーク監視システムにおける処理性能、スケーラビリティの向上を図る。【解決手段】ハードウェアベースのネットワーク監視システムとする。該システムは、パケット処理エンジン及び／またはセッションレベル解析のためのアプリケーション層プロセッサを有する。そのパケットエンジンは、（ａ）パケットをスニフしてトラフィックを解析するネットワークプロセッサと、（ｂ）パケット処理のためのコアエンジンであって、プロトコルレベルとアプリケーションレベルとにおいてプロトコル解析データを構成するためにプロトコルを抽出する手段と、パケットのプロトコルベースの解析手段とを有するコアエンジンとを有するパケット処理エンジンを有する。また、アプリケーション層プロセッサは、（ａ）すべてのセッションを抽出し、セッションデータを構成する手段と、（ｂ）パケットセッションベースを解析する手段とを有する。【選択図】図１３
2008042892.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークデータトラフィックを監視するためのハードウェアベースのネットワーク監視システムであって、
（ｉ）パケット処理エンジンであって、
（ａ）パケットをスニフしてトラフィックを解析するネットワークプロセッサと、
（ｂ）パケット処理のためのコアエンジンであって、
・プロトコルレベルとアプリケーションレベルとにおいてプロトコル解析データを構成するためにプロトコルを抽出する手段と、
・前記パケットのプロトコルベースの解析手段を有するコアエンジンとを有するパケット処理エンジン、及び／または、
（ｉｉ）セッションレベル解析のためのアプリケーション層プロセッサであって、
（ａ）すべてのセッションを抽出し、セッションデータを構成する手段と、
（ｂ）前記パケットセッションベース解析をする手段を有するアプリケーション層プロセッサとを有するネットワーク監視システム。
【請求項２】
セッションレベルアナライザは、オンボードメモリが十分ではないとき、自動的にホストメモリを使用する、請求項１に記載のネットワーク監視システム。
【請求項３】
セッションレベルアナライザはＰＣＩインターフェイスを用いてホストシステムとインターフェイスする、請求項１に記載のネットワーク監視システム。
【請求項４】
前記マイクロエンジンはＴＣＰ、ＵＤＰ、ＨＴＴＰ、ＳＭＴＰ／ＰＯＰ３、ＲＴＰ、ＳＩＰ、Ｈ．３２３、ＶｏＩＰ、ＩＣＭＰ、Ｔｅｌｎｅｔ、ＦＴＰ、ＤＮＳパケットのうち少なくとも１つを解析可能である、請求項１に記載のネットワーク監視システム。
【請求項５】
ネットワークデータトラフィックを監視するハードウェアベースの方法であって、
ａ．パケットをスニフする段階と、
ｂ．フラグメンテーションと再組立のために前記スニフされたパケットをチェックする段階と、
ｃ．前記チェックされたパケットのプロトコルを解析する段階と、
ｄ．前記解析されたパケットをホストメモリに保存する段階と、
ｅ．前記保存されたパケットからセッションを生成する段階と、
ｆ．前記セッションを解析して分離する段階と、
ｇ．前記分離したセッションを前記ホストメモリにアップロードする段階とを有する方法。
【請求項６】
パケットは識別フィールドを用いてフラグメント化及びデフラグメントされる、請求項５に記載の方法。
【請求項７】
前記パケットは、ソースＩＰ、デスティネーションＩＰ、プロトコルフィールド、データロード、パケットカウンタ、パケットサイズ、タイムスタンプ、ソースＭＡＣアドレス、デスティネーションＭＡＣアドレス、ソースポート、デスティネーションポート、ＴＣＰコントロールフラグ及びＴＣＰタイプのサービスを用いて解析される、請求項５に記載の方法。
【請求項８】
前記方法はデータベースを更新し、それを前記ホストメモリにタイムスタンプを付してアップロードする、請求項５に記載の方法。
【請求項９】
前記方法は前記パケットを、ＴＣＰ、ＵＤＰ、ＨＴＴＰ、ＳＭＴＰ／ＰＯＰ３、ＲＴＰ、ＳＩＰ、Ｈ．３２３、ＶｏＩＰ、ＩＣＭＰ、Ｔｅｌｎｅｔ、ＦＴＰ、ＤＮＳよりなる群から選択されたプロトコルに分離する、請求項５に記載の方法。
【請求項１０】
前記ＨＴＴＰセッションは、前記セッションの開始時刻及び終了時刻以外にリクエスト方法、ウェブサイト名、ＵＲＬ、コンテンツタイプにより分離される、請求項５に記載の方法。
【請求項１１】
前記ＳＭＴＰ／ＰＯＰ３セッションは、ユーザー名、パスワード、ｆｒｏｍ、ｔｏ、サブジェクト、添付ファイル名よりなる抽出情報により分離される、請求項５に記載の方法。
【請求項１２】
「キープアライブ」パラメータを有するネットワークトラフィックは単一セッションとして処理され、複数セッションは別々のセッションとして処理される、請求項５に記載の方法。
【請求項１３】
前記方法は、検索、ソート、集約、グラフとチャートの表示、及びクエリ／クエリスクリプト／言語のサポートを支援するために、ファイルにインデックスを付ける、請求項５に記載の方法。
【請求項１４】
前記セッションはインデックスファイルとデータファイルの２つのセグメントとして保存される、請求項５に記載の方法。
【請求項１５】
前記インデックスファイルは固定長レコードを有し、生パケット（オリジナルパケット）データは含まず、前記データファイル中の対応する生パケットデータレコードへのポイントを有する、請求項１４に記載の方法。
【請求項１６】
前記データファイルは可変長レコードを有し、実際の可変長の生パケット（オリジナルパケット）データを含む、請求項１４に記載の方法。
【請求項１７】
前記方法はフィルター基準及びコンテンツマッチに基づきパケットを集約する、請求項１４に記載の方法。
【請求項１８】
前記方法はハードウェアレベルにおいてオンザフライでフィルター基準を実行する、請求項１４に記載の方法。
【請求項１９】
前記方法は、フラグメント化されたパケットのデフラグメントと、再組み立てされたパケットに基づきパケットの解析を行う、請求項１４に記載の方法。
【請求項２０】
不完全なセッションも取得できるかぎり蓄積され、一つ一つのパケットを確実に捕捉する、請求項１４に記載の方法。
【請求項２１】
前記方法はネットワーク中のトラフィックの始点をたどる、請求項１４に記載の方法。
【請求項２２】
前記トラフィックの始点は、前記セッション（ｓｅｓｓｉｏｎ）のソース（ｓｏｕｒｃｅ）及びデスティネーション（ｄｅｓｔｉｎａｔｉｏｎ）のＭＡＣアドレス、前記セッションの開始及び終了時刻、及び処理エンジンとアプリケーション層プロセッサカードに割り当てられた一意的タグを用いて特定される、請求項２１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークデータトラフィック（ｎｅｔｗｏｒｋ  ｄａｔａ  ｔｒａｆｆｉｃ）解析とパケットセッションレベル（ｐａｃｋｅｔ  ｓｅｓｓｉｏｎ  ｌｅｖｅｌ）の解析のためのネットワーク監視システムと該システムの動作方法に関する。
【背景技術】
【０００２】
従来、我々は  ｓｏｆ  から  ｅｏｆ  まで１つのパケットを集めるためにそして次にきまった通話手順にもどるソフトウェアの開発をすることが出来ます、通話手順がプロトコルを解析するために順番に通話手順を呼びだすことが出来る。ソフトウェアはプログラミングを容易に出来る範囲内では有用である。以下に、我々はパケット解析のためのソフトウェア解決を提供する。ハードウェア解決として、ネットワークから來入するすべてのｑｕａｄ−ｏｃｔｅｔを調べてそして決断する、次のｑｕａｄ−ｏｃｔｅｔが到着する前に。我々の本発明はソフトウェアソリューションとして多くの工程が共通のリソースを共有して真に併用処理する集合体の構造を動作させなければならない。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
本発明の一目的は、ネットワークプロセッサチップの並列処理その他の特殊な機能を利用して、ハードウェアソリューションのアイデアに基づく新規なソリューションにより、上記の限界を克服することである。
【０００４】
本発明の他の目的は、真の同様な構造体を動作させるためにそして共通なリソースを共有する範囲で処理を行なうことである。
【０００５】
本発明の更なる目的は、全二重のリアルタイムネットワークトラフィック（ｒｅａｌ−ｔｉｍｅ  ｎｅｔｗｏｒｋ  ｔｒａｆｆｉｃ）用の監視システムを提供することである。
【０００６】
本発明の他の目的は、中核となるネットワークのリアルタイムＩＰデータ（ｒｅａｌ−ｔｉｍｅ  ｉｎｔｅｒｎｅｔ  ｐｒｏｔｏｃｏｌ  ｄａｔａ）解析を提供するリアルタアイムの能力を提供することである。
【０００７】
本発明のさらに別の目的は、マイクロエンジンコードの革新的なアーキテクチャ（ａｒｃｈｉｔｅｃｔｕｒｅ）、各マイクロエンジン（ｍｉｃｒｏｅｎｇｉｎｅ）間のデータの流れ、各マイクロエンジンとＡＲＭコア（ＡＲＭ  ｃｏｒｅ）間のデータの流れにより、高性能とスケーラビリティを提供することである。
【０００８】
本発明のさらに別の目的は、マイクロエンジンレベルにおいてパケットの再組み立てをするシステムを提供することである。
【０００９】
本発明のさらに別の目的は、上記の要求を満たすネットワーク監視システムを提供することである。
【００１０】
本発明のさらに別の目的は、上記の要求を満たすパケット処理エンジンとアプリケーション層プロセッサを提供することである。
【００１１】
本発明のさらに別の目的は、前記監視システムを用いて監視及び解析する方法を提供することである。
【００１２】
本発明のさらに別の目的は、監視及び解析のためのソフトウェアを提供することである。
【００１３】
上記目的の少なくとも１つを達成するために、本発明の一態様では、ネットワークデータトラフィックを監視するためのハードウェアベースのネットワーク監視システムを提供する。該システムは、
（ｉ）パケット処理エンジンであって、
（ａ）パケットをスニフしてトラフィックを解析するネットワークプロセッサと、
（ｂ）パケット処理のためのコアエンジンであって、
・プロトコルレベルとアプリケーションレベルとにおいてプロトコル解析データを構成するためにプロトコルを抽出する手段と、
・前記パケットのプロトコルベースの解析手段を有するコアエンジンとを有するパケット処理エンジン、及び／または、
（ｉｉ）セッションレベル解析のためのアプリケーション層プロセッサであって、
（ａ）すべてのセッションを抽出し、セッションデータを構成する手段と、
（ｂ）前記パケットセッションベース解析をする手段を有するアプリケーション層プロセッサとを有する。
【００１４】
本発明の他の一態様では、ネットワークデータトラフィックを監視するハードウェアベースの方法を提供する。該方法は、
ａ．パケットをスニフする段階と、
ｂ．フラグメンテーションと再組立のために前記スニフされたパケットをチェックする段階と、
ｃ．前記チェックされたパケットのプロトコルを解析する段階と、
ｄ．前記解析されたパケットをホストメモリに保存する段階と、
ｅ．前記保存されたパケットからセッションを生成する段階と、
ｆ．前記セッションを解析して分離する段階と、
ｇ．前記分離したセッションを前記ホストメモリにアップロードする段階とを有する。
【００１５】
本発明の更なる局面に従って、パケットを分析するためにマイクロエンジンコードのアーキテクチャとデータがそれぞれのマイクロエンジンの間にパケットを分析するために使用されるこれらのマイクロエンジンのそれぞれとＡＲＭコアにデータが流入したり流れ出したりする機能を提供する、上記の通りにそれぞれのマイクロエンジンの間にマイクロエンジンのアーキテクチャが流入すると言いました、マイクロエンジンのアーキテクチャに同じ様に集積されているパイプライン方式を併用して開発することが出来る。
【発明を実施するための最良の形態】
【００１６】
本発明の主要な具体化は、ネットワークデータトラフィックを監視することのためのネットワーク監視システムを基本としたハードウェアである、パケットをスニフ（ｓｎｉｆｆ）するための、そしてトラフィックを解析するためのネットワークプロセッサで構成されている。アプリケーションレベルとプロトコルレベルにおけるプロトコル分析データを構築するためにプロトコルの抽出をする手段、パケットのプロトコルを基本とした解析のための手段、セッションレベル解析用のアプリケーション層プロセッサ、すべてのセッションの抽出とセッションデータを構築するための手段、パケットのセッションベース（ｓｅｓｓｉｏｎ−ｂａｓｅ）の分析の手段等である。
下記に本発明の具体化されたものを列記する。
・ネットワークプロセッサがＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｆａｃｅ）を使って主要システムに付加されたこと。
・ネットワークプロセッサによってＰＣＩのマスターとスレーブの役割を努めるように設定されること。
・パケット処理エンジンはシステムにおけるルックアップテーブル（ｌｏｏｋｕｐ  ｔａｂｌｅ）を使い自由に選択することが出来るコンテントアドレサブルメモリ（Ｃｏｎｔｅｎｔ  Ａｄｄｒｅｓｓａｂｌｅ  Ｍｅｍｏｒｙ）を持っている。
・パケット処理エンジンが中核となるネットワークでリアルタイムＩＰデータ分析情報を提供するリアルタイムの処理能力を持っている。
・ネットワークプロセッサがＲＤＲＡＭ（Ｒａｍｂｕｓ  ｄｕａｌ  ｒａｔｅ  ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ）のチャネンルをコントロールするためのコントローラを持っている。
・ネットワークプロセッサが４チャネンルのためのＱＤＲ（Ｑｕａｄ  ｄａｔａ  ｒａｔｅ）スタティックなランダムアクセスメモリコントローラ（ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ  ｃｏｎｔｒｏｌｌｅｒ）を持っている。
・ネットワークプロセッサの４番目のチャネンルは選択が自由なＴＣＡＭ（Ｔｅｒｎａｒｙ  Ｃｏｎｔｅｎｔ  Ａｄｄｒｅｓｓａｂｌｅ  Ｍｅｍｏｒｙ）プロセッサに付くＱＤＲへ合図する動作を助ける。
・ネットワークプロセッサがスイッチを通して來入するネットワーク内のパケットを常にスニフ（ｓｎｉｆｆ）し、そしてその逆も同様に行う。
・ネットワークプロセッサは媒体とスイッチ構造のインターフェイスを使ってポート（ｐｏｒｔ）に接続する。
・中核となる該エンジンの８／１２のマイクロエンジンとＡＲＭコアエンジンから構成されている。
・ネットワークプロセッサの周波数はオンチップフェーズロックループ（ｏｎ−ｃｈｉｐ  Ｐｈａｓｅ  ｌｏｃｋ  ｌｏｏｐ）によって生成される。
・ＵＡＲＴ（Ｕｎｉｖｅｒｓａｌ  Ａｓｙｎｃｈｒｏｎｏｕｓ  Ｒｅｃｅｉｖｅｒ  Ｔｒａｎｓｍｉｔｔｅｒ）が該パケット処理エンジンのデバッギング（ｄｅｂｕｇｇｉｎｇ）目的と開発のために使用される。
・ネットワークプロセッサはバスインターフェイス（Ｂｕｓ  ｉｎｔｅｒｆａｃｅ）を使ってＵＡＲＴに付けられる。
・類似のデータベースが他のアプリケーションプロトコルを使ったセッションのために構築される。
・セッションレベル分析は、ボード（基板）上のメモリが十分ではない場合に自動的にホストメモリを使う。
・ＰＣＩインターフェイスを使ったホスシステムに付けられたセッションレベルアナライザインターフェイスである。
・マイクロエンジンがＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）、ＵＤＰ（Ｕｓｅｒ  Ｄａｔａ  Ｐｒｏｔｏｃｏｌ）、ＨＴＴＰ  （Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）、ＳＭＴＰ／ＰＯＰ３（Ｓｉｍｐｌｅ  Ｍａｉｌ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ／Ｐｏｓｔ  Ｏｆｆｉｃｅ  Ｐｒｏｔｏｃｏｌ  ３）  、ＲＴＰ（Ｒｅａｌ−Ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）、ＳＩＰ  （Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）、Ｈ．３２３  （ｒｅａｌ−ｔｉｍｅ  ｖｏｉｃｅ  ａｎｄ  ｖｉｄｅｏ  ｃｏｎｆｅｒｅｎｃｉｎｇ  ｏｖｅｒ  ｐａｃｋｅｔ  ｎｅｔｗｏｒｋｓ）、  ＶｏＩＰ（Ｖｏｉｃｅ  ｏｖｅｒ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ  Ｐｒｏｔｏｃｏｌ）、Ｔｅｌｎｅｔ、ＦＴＰ（Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）  、ＤＮＳ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ）  等のパケットの解析を可能にすることである。
・ネットワークデータトラフィックを監視する方法として、該方法を構成している手順であると言いました、パケットをスニフ（ｓｎｉｆｆ）して、フラグメント（ｆｒａｇｍｅｎｔａｔｉｏｎ）するためにスニフした後のパケットを確認して再び組み立てる、そしてプロトコルのために確認後のパケットを分析する、そしてホストメモリに分析されたパケットを保管する、そして該保管パケットからセッションをつくる、そして分析して、該分析の結果でセッションに分けられる、そして該ホストメモリに分けられたセッションとしてアップロードされる。
・パケット処理を全二重で行う。
・パケットはフラグメントされてそして該パケットの身分を確認する場所を使ってデフラグメント（ｄｅ−ｆｒａｇｍｅｎｔ）される。
・ソースＩＰ（Ｓｏｕｒｃｅ  ＩＰ）、デスティネーションＩＰ（Ｄｅｓｔｉｎａｔｉｏｎ  ＩＰ）、プロトコルフィールド（Ｐｒｏｔｏｃｏｌ  ｆｉｅｌｄ）、データロード（ｄａｔａ  ｌｏａｄ）、パケットカウンタ（ｐａｃｋｅｔ  ｃｏｕｎｔｅｒ）、パケットサイズ（ｐａｃｋｅｔ  ｓｉｚｅ）、タイムスタンプ  （ｔｉｍｅ  ｓｔａｍｐ）、ソースＭＡＣアドレス（Ｓｏｕｒｃｅ  ＭＡＣ  Ａｄｄｒｅｓｓ）、デスティネーションＭＡＣアドレス（Ｄｅｓｔｉｎａｔｉｏｎ  ＭＡＣ  Ａｄｄｒｅｓｓ）、ソースポート（ｓｏｕｒｃｅ  ｐｏｒｔ）、デスティネーションポート（ｄｅｓｔｉｎａｔｉｏｎ  ｐｏｒｔ）、ＴＣＰコントロールフラグ（  ＴＣＰ  ｃｏｎｔｒｏｌ  ｆｌａｇｓ）、ＴＣＰタイプサービス（ＴＣＰ  ｔｙｐｅ  ｏｆ  ｓｅｒｖｉｃｅ）を使ってパケットを分析している。
・データベースを更新する、そしてタイムスタンプを付けてホストメモリにアップロードする。
・ホストシステムのメモリは該基板上のメモリあるいは該システムのハードディスクの双方である。
・ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）、ＵＤＰ  （Ｕｓｅｒ  Ｄａｔａ  Ｐｒｏｔｏｃｏｌ）、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）、ＳＭＴＰ／ＰＯＰ３（Ｓｉｍｐｌｅ  Ｍａｉｌ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ／Ｐｏｓｔ  Ｏｆｆｉｃｅ  Ｐｒｏｔｏｃｏｌ  ３）、
ＲＴＰ（Ｒｅａｌ−Ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）、ＳＩＰ  （Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）、Ｈ．３２３（ｒｅａｌ−ｔｉｍｅ  ｖｏｉｃｅ  ａｎｄ  ｖｉｄｅｏ  ｃｏｎｆｅｒｅｎｃｉｎｇ  ｏｖｅｒ  ｐａｃｋｅｔ  ｎｅｔｗｏｒｋｓ）、ＶｏＩＰ（Ｖｏｉｃｅ  ｏｖｅｒ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ  Ｐｒｏｔｏｃｏｌ）、Ｔｅｌｎｅｔ、ＦＴＰ（Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）  、ＤＮＳ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ）から構成されている群れから選択されたプロトコルに対応したパケットに分ける。
・ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）は、要求方法、ウエッブサイト名、ＵＲＬ、コンテントタイプ（ｃｏｎｔｅｎｔ  ｔｙｐｅ）をセッションの開始と終了のタイムスタンプから分けて構成されて抽出された情報とともに分離される。
・ＳＭＴＰ／ＰＯＰ３セッションはユーザー名、パスワード、送られてきた先（ｆｒｏｍ）、送られる先（ｔｏ）、主題、添付ファイル等の抽出された情報と一緒に分けられる。
・“キープアライブ”（ｋｅｅｐ  ａｌｉｖｅ）パラメータといっしょにネットワークトラフィックは単一セッションとして処理され、そして多数のセッションは別個のセッションとして扱われる。
・検索、集約、図とテーブルを示すことを助けするためのファイルのインデックスを付けることそしてクエリ／クエリスクリプト／言語の作業を助けるためのファイルのインデックスを付けることを行う。
・セッションは該システムのインデックスファイル（ｉｎｄｅｘ  ｆｉｌｅ）とデータファイル（ｄａｔｅ  ｆｉｌｅ）と呼ばれる２つの部分で保管される。
・インデックスファイルが固定長レコードで出来ていると言いました、データファイル内のネットワークから入ってきたオリジナルパケットデータ（ｒａｗ  ｐａｃｋｅｔ  ｄａｔａ）が記録する通信のためのポインターからだけで出来ており、ネットワークから入来するオリジナルパケットデータから出来ているわけではない。
・該データファイルは可変長レコードから出来ている、そして可変長であるネットワークから入来する実際のオリジナルパケットデータを含む。
・上記の処理方法としてプロトコルとセッションレベルと両方のプロトコルにおいてパケット分析を実行する。
・処理方法はコンテントマッチ（ｃｏｎｔｅｎｔ  ｍａｔｃｈ）とフィルター基準を基本としたパケットの集合体を提供する。
・処理方法はハードウェアレベルにおいてオンザフライ（ｏｎ  ｔｈｅ  ｆｌｙ）基準を実施する。本発明の他の具体化は、パケットフラグメント（ｆｒａｇｍｅｎｔ）のデフラグメント（ｄｅ−ｆｒａｇｍｅｎｔ）を実施して再度組み立てられたパケットとしてパケットの分析を行う。
・不完全なセッションは利用可能な範囲で利用して、それぞれのパケットとすべてのパケットが確実に利用できるようにする。
・当該方法はネットワークのトラフィックの起源を追跡する。
・トラフィックの起源はＭＡＣアドレスのソースとセッションの送り先を使って識別される、セッションの開始及び終了時刻、そして一意的タグ（ｕｎｉｑｕｅ  ｔａｇ）は処理エンジンとアプリケーション層プロセッサボードに割り当てられた。
・パケットの分析はマイクロエンジンのアーキテクチャによって実行される。
・マイクロエンジンのアーキテクチャに統合されたパイプライン方式の特徴を可能にする。
・パケットの正当性を返すこととコントロールプログラムに対するフラグメント処理はマイクロエンジンによって実施される。
・パケット処理エンジンボード（以降同じくＫＡＭＡＬと称される）は強力な全二重のパケットを処理するエンジンである、インテルのＩＸＰシリーズネットワークプロセッサはネットワークプロトコル分析をするために構成することが出来る、そしてユーザー定義に基づいたフィルター基準に従ってパケットの集合体をつくる、そしてリアルタイム（ｒｅａｌ−ｔｉｍｅ）で１００Ｍｂｐｓあるいは１Ｇｂｐｓまたは１００Ｍｂｐｓと１Ｇｂｐｓの両方のモードでアプリケーション層の分析を行う。
プロトコルレベルとアプリケーションレベルにおいてリアルタイムに起きる、そして該システムは特にネットワークセキュリティのような敏感なアプリケーションと広範囲なＬＡＮ／ＷＡＮ環境を超えたネットワーク上でパケットをスニフ（ｓｎｉｆｆ）することを要求されるネット監視とそれぞれのパケットとすべてのパケットはそれぞれのアプリケーションとすべてのアプリケーションと同じように種々のフィールドに展開することが出来る。
【００１７】
該システムはネットワークに接続する２ギガビットのＰＨＹポート（Ｐｈｙｓｉｃａｌ  ｐｏｒｔ）を持っている。該ネットワーク上のトラフィックのすべてのパケットは中核となるエンジンに配達される。該エンジンはインテルのアドバンスドネットワークプロセッサであるＩＸＰ２４００／ＩＸＰ２８００を使って実行される。中核となるエンジンはフラグメントされたパケットとのデフラグメントを行いそしてパケットの解析を行う。該分析データはＰＣＩインターフェイスを使ってパケットとともにホストメモリに保管される。
パケット処理エンジンの特徴
１．１Ｇｂｐｓ  までのリアルタイムギガビットネットワークトラフィックをサポートする。  効率的なリソースを使うためにサポートされた最大の稼動スピードは１００Ｍｂｐｓ／１Ｇｂｐｓで実行することが出来る。
２．完全にパケットの再度組み立てを行う。
３．ユーザーによりフィルター基準を定義した該内容と同じ集合体。該フィルター基準はパケット内の正しいパラメータと一致することに基づいている。例えば、ＩＰアドレス、ポート番号等のようにパケット内にあるように。
４．音声、ビデオとオーディオデータのためのペイロードタイプを含む内容分析。
５．ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）の設定範囲：  ビットマスキング（ｂｉｔ  ｍａｓｋｉｎｇ）をフィルター基準として使用してＩＰの  範囲を指定することが可能である、例えば１９２．１６８．１．６４から１９２．１６８．１．１２７。
６．タイムスタンプ（ｔｉｍｅ  ｓｔａｍｐ）：時間−分−秒−ミリセカンド−マイクロセカンドを使ってのそれぞれの  ＩＰ  パケットのためのタイムスタンプ。
７．プロトコル（ｐｒｏｔｏｃｏｌｓ）−  ＫＡＭＡＬは次のプロトコルの解析を可能にする：ＴＣＰ、ＵＤＰ、ＨＴＴＰ、ＳＭＴＰ／ＰＯＰ３、ＲＴＰ、ＳＩＰ、Ｈ．３２３、ＶｏＩＰ、ＩＣＭＰ、Ｔｅｌｎｅｔ、ＦＴＰ  、ＤＮＳ  。
８．  ＰＣＩインターフェイスのボード（基板）に対する要求。
９．定義されたフィルターのためにそして、動的にどんなプラットホーム（Ｗｉｎｄｏｗｓ（登録商標）又はＬｉｎｕｘ）上でもコンフィギュレーションパラメータ（ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｐａｒａｍｅｔｅｒｓ）のためのＧＵＩインターフェイスの開発用にＣ言語を呼び出すことが可能な機能。
パケット処理エンジンは、強力な全二重で動作するアプリケーションレベルネットワーク処理エンジンである、インテルのＩＸＰシリーズネットワークプロセッサの周りに構築されてそしてリアルタイムで１００Ｍｂｐｓと１Ｇｂｐｓモードの両方あるいは１００Ｍｂｐｓ  と１Ｇｂｐｓモードのアプリケーション層の分析が出来る。
【００１８】
該処理は、プロトコルレベルとアプリケーションレベルにおいてリアルタイムで起きます、該システムは種々の分野で実装することが出来る、特に広範囲なＬＡＮ／ＷＡＮ  環境の向こう側にパケットをスニフ（ｓｎｉｆｆ）することを必要とするネットワークセキュリティとネット監視に対する敏感なアプリケーションのための種々の分野で実装することが出来る。
【００１９】
ＫＡＭＡＬによって該ホストにアップロードされたプロトコルの分析された結果のパケットは該ホストのハードディスクに保管される。該ホストのハードディスクに保管されたパケットはハードディスクからホストによって  ＰＣＩインターフェイスを経由してアプリケーション層（ａｐｐｌｉｃａｔｉｏｎ  ｌａｙｅｒ）プロセッサ（これ以降同じく  ＧＵＬＡＢと称される）ボード（基板）にアップロードされる。
【００２０】
ＧＵＬＡＢは該パケットが属するセッション情報に従ってこれらのパケットをセッションに分ける。分離された該セッションが完全である途端にセッションレベルにおいて組み立てられた該パケットはセッション情報とタイムスタンプ（ｔｉｍｅｓｔａｍｐ）、オリジネター（ｏｒｉｇｉｎａｔｏｒ）とパケットの総数、他とともにホストに戻される。
【００２１】
図１３に示す通りに本発明の機能をネットワークシステムに構築した構成を表する。
図１３にあるように例として、ネットワーク１０を含むローカルエリアネットワーク（ＬＡＮ）２１と２２に複数のパーソナルコンピュータ、ワークステーションと、あるいはサーバーのそれぞれが接続している。ＬＡＮ２２は事実上のＬＡＮを含む。ＬＡＮ２１と２２はスイッチングハブ２５と直接的に接続している（ＬＡＮ２１の場合には）、そしてローカルＨＵＢ２４（ＬＡＮ２２の場合には）に間接的に接続している。ＬＡＮ２１と２２は正当に評価されて、ＬＡＮ２１、２２はスイチングＨＵＢ２５と無線接続されている。スイッチングＨＵＢ２５はＬＡＮ内の機器からはあらゆる非認証されたパーティーには接続ルーター２８を通ってファイアウォール２７に接続することが出来る。ＬＡＮ２１と２２の範囲にあるパーソナルコンピュータと、あるいはワークステーションのユーザーは、インターネットからルーター２８を通って接続出来る能力を持っている。
【００２２】
図１３の通りに、ＴＡＰ２６はスイチングＨＵＢ２５とファイアウォール２７との間でネットワーク１０を形成している、そしてネットワーク１０を通してスイッチングＨＵＢ２５とルーター２８との間ですべてのデータが流れている。データはＴＡＰ２６によりいつでも取り込むことができる、該データは具体的な本発明としてサーバー７０内に配置されたＫＡＭＡＬ３０とＧＵＬＡＢ５０に流れる。ＫＡＭＡＬ３０はパケットをスニフしてネットワーク層のプロトコルとアプリケーション層のプロトコル（Ｓ−１）からＭＡＣアドレスとともにパケットデータを取り込む。ＫＡＭＡＬはタイムスタンプとＫＡＭＡＬ自身の持つＫＡＭＡＬである事を証明する情報を付加する。コンテントマッチングの処理後にあるいはもしくは、プロトコル解析、それぞれのプロトコルに対する通信パケットの集合体をホストメモリ４０にアップロードする、たとえばサーバー７０（Ｓ−２）にあるハードディスクのように。パケットの集合体は構成の作法に従ってシーケンシャルにアップロードされる。ＫＡＭＡＬ３０によってアップロードされたパケットの集合体はＧＵＬＡＢ５０（Ｓ−３）にセッション情報とともに組み立てられてダウンロードされる、そして組み立てられたセッションパケットはホストメモリ４０（Ｓ−４）に送られる。具体例によれば、ダウンロードと  ＧＵＬＡＢ５０によるアセンプリはパケットの事前に決定された量の後に行なわれてＫＡＭＡＬ３０  によってホストメモリ４０  にアップロードされる。上記の手順を以下に詳細に説明する。
【００２３】
上記の配置の通りにＫＡＭＡＬ３０  とＧＵＬＡＢ５０  が共にプロトコルレベルとアプリケーションレベルにおいてリアルタイムでプロトコルパケットをモニターしてそして、パケットのセッションベースの解析を行なうことによってモニターされたプロトコルパケットを再構築することが出来る。
ＫＡＭＡＬ３０によってパケットとＧＵＬＡＢ５０により再度構成されパケットは図１３に見られる通りに該ホストメモリ４０に保管されるためにアップロードされる、そして該処理は正当に評価されるＫＡＭＡＬ３０により取り込まれたパケットとＧＵＬＡＢ５０  によって再構築されたパケットが  サーバー７０でそして／あるいはから供給された異なったホストメモリでアップロードされる（保管）ことが理解される。
セッションアナライザの特徴
１．すべてのセッションの抽出とセッションデータの構築を行うことが出来る。
２．不完全なセッションがそれぞれのパケットとすべてのパケットが確実に実施することが出来るように利用可能な程度に同じくコンパイルされる。
３．ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）は、要求方法、ウエッブサイト名、ＵＲＬ、コンテントタイプ（ｃｏｎｔｅｎｔ  ｔｙｐｅ）をセッションの開始と終了のタイムスタンプから分けられて、構成されて抽出された情報とともに分離される。
４．ＰＯＰ３／ＳＭＴＰは、”ｕｓｅｒ  ｎａｍｅ”  “ｐａｓｓｗｏｒｄ”  “ｆｒｏｍ”  “  ｔｏ”  “ｓｕｂｊｅｃｔ”  ａｔｔａｃｈｅｄ  ｆｉｌｅ  ｎａｍｗ／ｓ”のような情報から組み立てられている。
５．  類似したデータベースはその他のアプリケーションプロトコルのために組み立てられる。
６．“キープアライブ”（Ｋｅｅｐ  ａｌｉｖｅ）”と多数のセッションは適切に処理される。
７．ＫＡＭＡＬから抽出されたすべてのパラメータと同じくソースＩＰ（ｓｏｕｒｃｅ  ＩＰ）、デスティネーションＩＰ（ｄｅｓｔｉｎａｔｉｏｎ  ＩＰ）、ＭＡＣアドレス（ＭＡＣ  ａｄｄｒｅｓｓ）、ソースポート（ｓｏｕｒｃｅ  ｐｏｒｔ）、デスティネーションポート（ｄｅｓｔｉｎａｔｉｏｎ  ｐｏｒｔ）等も有用な情報として抽出されて使用される。
８．検索、ソート、集約、グラフとチャートのテーブルの表示の手助けをするためにファイルにインデックスを付けることを行うそして該インデックスを付けたことが、クエリ／クエリスクリプト／言語等のサポートをする。
イントロダクション
該書類はＫＡＭＡＬハードウェアデザインについて要約したものである。それはＫＡＭＡＬの機能について要約記述を持ったシステム概要とハードウェアブロック図を持っている仕様とソフトウェアフローチャートを含む。    
システムの概要
この分野のＫＡＭＡＬと一緒のすべてのシステムは図２で例証される。
ＫＡＭＡＬは２つの独立した１０／１００／１０００ベースＴＡＰ（ｔｅｓｔ  ｐｏｉｎｔ）によってネットワークと接続されているそしてそれは順番にトラフィックが分析される必要があるネットワークサブシステムに接続している。ＫＡＭＡＬはイーサネット（登録商標）パケット（Ｅｔｈｅｒｎｅｔ（登録商標）  ｐａｃｋｅｔ）を集めてアルゴリズムによりＰＣＩインターフェイスを経由してホストメモリにアップロードされてテーブル内に結果を保管する。ＫＡＭＡＬはＫＡＭＡＬの代わりとなるホスト上でＷｉｎｄｏｗｓ（登録商標）／Ｌｉｎｕｘ  ＯＳベースの環境で動作するＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）を使ってコントロールすることが出来る。本発明の目的で、ＫＡＭＡＬはＷｉｎｄｏｗｓ（登録商標）環境でＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）によりコントロールされる。ＫＡＭＡＬはＰＣＩ  インターフェイスを使って主装置に付けられるインテルの  ＩＸＰ２４００／ＩＸＰ２８００ネットワークプロセッサをベースとしたギガビットネットワークの監視装置である。当該ギガビットネットワークの監視装置は、ルーターから  ＬＡＮまでにくるネットワーク内のパケットをスニフして、そして必要条件に従ってトラフィックを分析する。ＫＡＭＡＬの動作はＧＵＩを使って構成することが出来る。すべての集められたデータと解析されたデータはアプリケーションによってあらゆる処理をするために確かなファイル形式にされてＰＣＩインターフェイスを使ってホストメモリにアップロードされる。
システム構成
次のブロック図は仕様を理解するためのシステムのハイレベルの流れを示す。
図３：ＫＡＭＡＬ：機能的なブロック図、
図３で、入来パケットはフラグメントされて、そしてＲＦＣ７９１に従ってデフラグメントされる、デフラグメントされたパケットはパケットのプロトコルフィールド（ｐｒｏｔｏｃｏｌ  ｆｉｅｌｄ）とタイムスタンプ（ｔｉｍｅｓｔａｍｐ）を使って分析される。  分析されたデータはホストメモリに保管される。ＫＡＭＡＬのハードウェアを使ってリアルタイムにてデータを分析することが上記同様に可能である。これはＫＡＭＡＬ自身の上に適切なハードウェアを実装することによってＫＡＭＡＬがオンザフライ（ｏｎ  ｔｈｅ  ｆｌｙ）で入来パケットを監視することを意味する。  
システムの機能的なブロック図
ＫＡＭＡＬの高度なレベルでハードウェアを実現していることが図４に示されている。
当該システムはネットワークに接続する中核となるエンジンにパケットを届ける２ギガビットの  ＰＨＹポートを持っている。このエンジンはＩＸＰ２４００／ＩＸＰ２８００、インテルからのアドバンスネットワークプロセッサを使って実行される。該中核エンジンはフラグメントされたパケットのデフラグメンテーションとパケットの解析を行う。図４に示すように分析されたデータはホストメモリにパケットとともにＰＣＩインターフェイスを使って保管される。
機能的な要求仕様：
ＫＡＭＡＬのサポートされている特徴
・１００Ｍｂｐｓ／１Ｇｂｐｓ以上の全二重のリアルタイムネットワークトラフィックをサポートしている。
・パケットの完全デフラグメンテーションを行う。
・プロトコルの集合体モジュールを形成している。
・音声、ビデオ、オーディオのためのペイロードタイプ（ＰＡＹＬＯＡＤ  ＴＹＰＥ）を持っている内容分析を行う。
・リアルタイム能力：ＫＡＭＡＬは核となるネットワークでリアルタイムＩＰデータ分析情報を提供する。
・オペレーティングシステム：ＲｅｄＨａｔ  Ｌｉｎｕｘがはじめにサポーした。Ｓｕｓｅ  Ｌｉｎｕｘ  、Ｔｉｍｅｓｙｓ  ＯＳのサポートを行う。
・タイムスタンプ：時間−分−秒−ミリセカンド−マイクロセカンドを使ってそれぞれのＩＰパケットのためのタイムスタンプの付加を行う。
・プロトコル：ＫＡＭＡＬは次のプロトコルの分析を可能にしている。
【００２４】
・ＴＣＰ
・ＵＤＰ
・ＨＴＴＰ
・ＳＭＴＰ／ＰＯＰ３
・ＲＴＰ
・ＳＩＰ
・Ｈ．３２３
・ＶｏＩＰ
・ＩＣＭＰ  
・Ｔｅｌｎｅｔ
・ＦＴＰ
・ＤＮＳ
・ＫＡＭＡＬはＰＣＩの要求に対応している。
・Ｗｉｎｄｏｗｓ（登録商標）あるいはＬｉｎｕｘのようなプラットホームでも動的に定義されたコンフィグレーションパラメータ（ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｐａｒａｍｅｔｅｒ）に対してＧＵＩインターフェイス（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）の開発のためにＣ言語が呼び出し可能な機能。
・システムインターフェイス
・ハードウェアインターフェイス
インテルの  ＩＸＰ２８００  を使っているＫＡＭＡＬのより詳細なブロック図を図５に示す。該ボード（基板）はＲＡＭ（ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ）、フラッシュ（ｆｌａｓｈ）メモリと他のチップのような資産を持っている。該ボードはシステムの開発のためとプロセッサ上のＯＳと同様にソースコードをロードするために同じく１０／１００Ｍｂｐｓ  のイーサネット（登録商標）とＵＡＲＴポートを持っている。該ボードはシステムのルックアップテーブルとして使うことができるオプションのＣＡＭ（ｃｏｎｔｅｎｔ  ａｄｄｒｅｓｓ  ｍｅｍｏｒｙ）を持っている。インテルのＩＸＰ２４００／ＩＸＰ２８００は８／１２のマイクロエンジンと１つのＡＲＭコアを持っている。パケット処理はマイクロエンジンを使って行われる（１ＧＨｚ  から２．４ＧＨｚで使用できる可変クロック）。ＡＲＭコアはシステムコントロールのためにＬｉｎｕｘ  ＯＳを持ってそして遅いパス機能のために使うことが出来る。インテル  ＩＸＰ２４００／ＩＸＰ２８００ネットワークプロセッサは無制限のプログラミングフレキシビリティを提供することによって完全な内容の早い実装を可能にする、そしてコードの再利用と高性能な処理をする。該ネットワークプロセッサはＯＣ−３からＯＣ−１９２までの通常の広範囲で、基板上のスピードの範囲にたいするサポートを必要とする多種多様なＷＡＮとＬＡＮアプリケーションをサポートする。高性能でスケーラブルな革新的なマイクロエンジンアーキテクチャを通してソフトウェアにパイプライン方式の特徴を可能にするマルチ−スレッド（ｍｕｌｔｉ−ｔｈｒｅａｄｅｄ）分配キャシュアーキテクチャによって達成される。利用可能な設定された標準的な特徴のほかにＩＸＰ２４００／ＩＸＰ２８００が２／１０Ｇｂｉｔ／ｓ．で安全なネットワークトラフィックで機能性を統合する。これは安全なネットワーク装置を事前の設計を可能にして、そして電力消費と、ボードの持つ資産とシリコンへの投資に低い全体的なシステムコストをもたらす結果となる。
■１２個の統合化されたマイクロエンジン
・最高１．４ＧＨｚで動作
・マイクロエンジン毎に４つあるいは８つのスレッド（ｔｈｒｅａｄｓ）に構成可能
・マイクロエンジン毎にローカルメモリの６４０のＤｗｏｒｄｓ
・シングルサイクルルックアップを持ったマイクロエンジン毎に１６項目のＣＡＭ
・次の隣のバスが隣接したマイクロエンジンにアクセスする
・マイクロエンジン毎のＣＲＣユニット
・マイクロエンジン毎に８Ｋの命令制御記憶装置
・一般化されたスレドのために合図することをサポート
■統合化されたインテルＸＳｃａｌｅコア
・最高７００ＭＨｚで動作
・高性能なローパワーの３２ｂｉｔエンベデッドＲＩＳＣプロセッサ
・３２Ｋｂｙｔｅ命令キャッシュ
・３２Ｋｂｙｔｅデータキャッシュ
■３つのインダストリアル標準ＲＤＲＡＭインターフェイス
・２．１Ｇｂｙｔｅ／ｓのピークバンド幅
・８００ＭＨｚそして１０６６ＭＨｚ  のＲＤＲＡＭ
・エラー訂正コード（ＥＣＣ）
・インテルＸＳｃａｌｅコア、マイクルエンジン、そしてＰＣＩからのアドレスができる
■インダストリアル標準な３２ビットＱＤＲＳＲＡＭインターフェイス用に
・１．９Ｇｂｙｔｅ／チャンネル毎
・最高２３３ＭＨｚまでのＳＲＡＭ
・リンクリストとリングオペレーションに対するハードウェアサポート
・アトミックビットオペレーション
・アトミックアリスマティックをサポート
・  インンテルＸＳｃａｌｅコア、マイクロエンジンそしてＰＣＩからのアドレスできる
■統合化されたメディアスイッチ構造インターフェイス
・ユニダイレクショナル１６ｂｕｉｌｄｓデータインターフェイス
・チャンネル毎に最高５００ＭＨｚ
・ＳＰＩ−４あるいはＣＳＩＸプロトコルのために別に構成可能
■インダストリアル標準ＰＣＩバス
・ＰＣＩローカルバス仕様、６４ｂｉｔ  ６６ＭＨｚのＩ／Ｏ用バージョン２．２インターフェイス
■追加の統合化された特徴
・ハードウェアハッシュユニット（４８、６４、と１２８ビット）
・１６Ｋｂｙｔｅのスクラッチパッドメモリ
・デバッギングのためのシルアルＵＡＲＴ  ポート
・８本の多目的  Ｉ／Ｏ  ピン
・４の３２ｂｉｔタイマー
■１３５６のボールＦＣＢＧＡ  パッケージ
・３７．５ｍｍ  ｘ  ３７．５ｍｍ寸法
・１ｍｍ半田付けボールピッチ
ＩＸＰ２４００／ＩＸＰ２８００オペレーションフリケンシィとＫＡＭＡＬのためのインターフェイスのバス幅はまだ完了されるはずである。  
ＲＤＲＡＭ
インテルＩＸＰ２８００  ネットワークプロセッサは３つのＲａｍｂｕｓＤＲＡＭ（ＲＤＲＡＭ）チャネルのためにコントローラを持っている。コントローラのそれぞれが独立してそれ自身のＲＤＲＡＭにアクセスしてそして同時に他のコントローラ（すなわちそれらは１つのより広いメモリとして稼働していません）で動作することが出来る。ＤＲＡＭが高密度の、高いバンド幅ストレッジを供給して、そしてしばしばデータバッファのために使われる。６４、１２８、２５６そして５１２ＭＢのＤＲＡＭサイズ、そして１ＧＢが支援される。しかしながらＫＡＭＡＬはチャネンル毎に最高２５６ＭＢのＲＤＲＡＭを使用するかも知れない。
ＱＲＤＳＲＡＭとＴＣＡＭ  
ＩＸＰ２８００が４チャネルのために４つの独立したＳＲＡＭコントローラを持っている。  それぞれのチャネルが最高６４ＭｂｙｔｅのＳＲＡＭをサポートする。イングレスネットワークプロセッサの４番目のチャネルは同じく合図してＱＤＲに付着するオプションのターナリコンテントアドレスメモリ（Ｔｅｒｎａｒｙ  Ｃｏｎｔｅｎｔ  Ａｄｄｒｅｓｓ  Ｍｅｍｏｒｙ）コプロセッサをサポートする。  もしアプリケーションがそれらを使う必要がないならどれかあるいはすべてのコントローラがそこに居ることがないままにしておくことが出来る。ＳＲＡＭはマイクロエンジン、インテルＸＳｃａｌｅコアとＰＣＩユニット（外部のバスマスタとＤＭＡ）によりアクセス可能である。  
フラッシュメモリシステムで使われたフラッシュメモリはＩＸＰ２４００／ＩＸＰ２８００  の遅いポートを利用する。遅いポートは８ｂｉｔ非同期データバス以外の何ものでもない。フラッシュメモリは１６ＭＢサイズであろう。
ＰＣＩ  インターフェイス
ＰＣＩコントローラは６４ｂｉｔ、６６ＭＨｚ有能なＰＣＩローカルバス仕様、インテルＩＸＰ２４００／ＩＸＰ２８００へのバージョン２．２のインターフェイスを提供する。  それは３２ｂｉｔの、そして／あるいは３３ＭＨｚ  の  ＰＣＩコントロ−ラに同じく互換性がある。  ＰＣＩコントローラは次の機能を提供する：
・目標アクセス（ＳＲＡＭ、ＤＲＡＭとＣＳＲｓへの外部バスマスターアクセス）
・マスターアクセス（マイクロエンジンがＰＣＩターゲットデバイスのアクセスをするかあるいはインテルＸＳｃａｌｅ  コア）
・２  ＤＭＡチャネッル
・ＰＣＩ  調停者
ネットワークプロセッサはそれが  ＰＣＩ  リセットシグナルを提供するところあるいはＡＤＤ−Ｉｎ装置としてそれが  ＰＣＩリセットシグナルをチップリセットとして使用するＰＣＩの中心的な機能（独立したシステムとして使うために）の役を務めるように設定することが出来る。
ＰＨＹインターフェイス
図５に示されるようにメディアとスイッチ構成（ＭＳＦ）インターフェイスはインテルＩＸＰ２４００／ＩＸＰ２８００ネットワークプロセッサを物理層装置（ＰＨＹ）と接続する。
ＵＡＲＴと１０／１００Ｍｂｐｓのイーサネット（登録商標）
これらのインターフェイスは開発段階にフィールドオペレーション上と同様にＫＡＭＡＬの開発とデバッギング目的の用途で使用出来る。  ＵＡＲＴはＲＳ−２３２標準。
クロックモジュール
ＩＸＰ２４００／ＩＸＰ２８００ネットワークプロセッサに関する速い周波数は選択可能な乗数によってリファレンス周波数を増やすＰＬＬ  がボード（基板）上のＬＶＤＳ  発振器によって提供した  ｏｎ−ｃｈｉｐ（周波数１００ＭＨｚ）によって生成される。  乗数限界は１６と４８の間の倍数である、それで  ＰＬＬ  は（１００ＭＨｚの参考周波数で）１．６ＧＨｚ  から４．８ＧＨｚのクロックを生成することが出来る。
パワーモジュール
パワーモジュールがホストシステムからＰＣＩバスから３．３ｖのリファレンスパワーをとるそして適当なパワーコンバーターとレギレータをシステムに異なったモジュールとチップセットのための異なった電圧のセットを得るために使用する。
ソフトウェアインターフェイス
図６に示されるようにソフトウェアスタック（ｓｏｆｔｗａｒｅ  ｓｔａｃｋ）はマイクロエンジンを通して入ってくるイーサネット（登録商標）フレームを処理する。すべてのパケット処理と分析は同じくマイクロエンジンによって実施される。ＩＸＰ２４００／ＩＸＰ２８００（ＡＲＭプロセッサ）コアは組み込みがたＬｉｎｕｘ  ＯＳを持っている。これは全部のインターフェイスと入出力関連のタスクとそれらのデバイス・ドライバを処理する。ＯＳは同じくホストインターフェイスとＧＵＩ関連のタスクを処理する。パケットがプロセッサに入って来る途端にそれは分解されるかあるいは、必要とされるようにデフラグメントされてマイクロエンジンにおいて分析されてそして次にＸＳｃａｌｅコアに転送される。ＸＳｃａｌｅはホストメモリにＰＣＩインターフェイスを経由してすべての適切なデータを転送してそして保管する。図７に示すＫＡＭＡＬのための基本的なソフトウェアフローチャート。
基本的なアルゴリズム：
１．ネットワークインターフェイスからパケットを取り込むためにパケットをスニフ（ｓｎｉｆｆ）する。
２．フラグメンテーションビト（ｆｒａｇｍｅｎｔａｔｉｏｎ  ｂｉｔ）の部分を調べる。  もし調べて該フラグメンテーションビトがセットされることが出来るならすべてのフラグメントされたパケットを集めて、該システム内の身元確認場所を使ってデフラグメントする。  それから第４番目ステップに進む。
３．もしデフラグメントビット（ｆｒａｇｍｅｎｔａｔｉｏｎ  ｂｉｔ）が設定されなければ第４番目ステップに進む。
４．ソース  ＩＰ（ｓｏｕｒｃｅ  ＩＰ）  、デスティネーションＩＰ（ｄｅｓｔｉｎａｔｉｏｎ  ＩＰ）  プロトコルフィールド（ｐｒｏｔｏｃｏｌ  ｆｉｅｌｄ）、データロード（ｄａｔａ  ｌｏａｄ）を使っているパケットを分析する。
５．データベースを更新してタイムスタンプを付けてホストシステムメモリに更新したデータベースをアップロードして、そして同じくパケットを該ホストメモリに保管する。
アップロードする必要が示されたファイルのマトリックス、
【００２５】
【表１】
2008042892.tif 000003
上記のマトリックスはどんな入力ででも増すことができＩＰパケットのどんなフィールドにでも属する。
例えば、
・ソースポート（ｓｏｕｒｃｅ  ｐｏｒｔ）、デスティネーションポート（ｄｅｓｔｉｎａｔｉｏｎ  ｐｏｒｔ）
・ＴＴＬ（ｔｉｍｅ  ｔｏ  ｌｉｖｅ）
・データ長（ｄａｔａ  ｌｅｎｇｔｈ）、等。
ＧＵＬＡＢ  
イントロダクション
ＧＵＬＡＢはホストシステムとコミュニケーションをするためにＰＣＩインターフェイスを利用するためのボードとして付加された。ＧＵＬＡＢはＫＡＭＡＬによって処理された後に（例えばホストシステムのメモリ／ハードディスク装置で）ホストシステムに保管されたパケットを受け入れる、そしてパケットのセッションベースの分析を行う。セッションに従ってパケットを分ける、特定のセッションに属するすべてのパケットを編集した後に該パケットはこれらのセッションのそれぞれに分けられてホストにアップロードする。フィールドのシステムは図８に示す。
ＲＤＲＡＭメモリマネージメント
ＧＵＬＡＢはオプションとして最高３ＧＢまでのボード上のメモリを持っている。図９に示すようＲＡＭは配置されるべきである。当該ボード上のメモリの内で最初の１２８ＭＢメモリはオペーレションシステム、ソフトウェア、スクラッチデータ等のために利用されるであろう、どのユーザーがアクセスを持たないであろうかにかかわらず。当該基板上のメモリの内で残っている２９４４ＭＢは種々のセッションの間に配置される。セッションの数とそれぞれのセッションに割り当てられたメモリはユーザーから入力されるそしてセッションベースの分析のための  ＲＤＲＡＭ  はそれに応じて分割されるであろう。
ＧＵＬＡＢ  のオペレーション
ＰＣＩインターフェイスのみを持っているホストシステムへの  ＧＵＬＡＢのインターフェイス。  オリジナルパケット（ｒａｗ  ｐａｃｋｅｔ）がこのＰＣＩインターフェイスを経由してホストから  ＧＵＬＡＢに送られる。  
ＧＵＬＡＢはセッションに基づいてこれらのパケットを分けてＰＣＩインターフェイスを経由してホストに戻って分離したパケットデータを書く。１つのシナリオは、ＫＡＭＡＬによってホストにアップロードされたプロトコルによって分析されたパケットは、ホストのハードディスクに保管される。保管された該パケットはハードディスクからホストによってＰＣＩインターフェイスを経由してＧＵＬＡＢにアップロードされる。ＧＵＬＡＢは該パケットが属するセッションに従ってこれらのパケットを分ける。セッションが完全である途端に上記のパケットはセッションレベルにおいて組み立てられたこれらすべてのパケットはタイムスタンプ、オリジネータとパケットカウンタ他のようなセッション情報とともにホストにアップロードされる。  例が下図１０に示す。
概要背景
ＫＡＭＡＬはギガビットレベルの全二重のパケット処理エンジンである。ＧＵＬＡＢは典型的にＫＡＭＡＬの出力を使うセッションレベル分析器である。ＫＡＭＡＬはＫＡＭＡＬとＧＵＬＡＢに変形したものである。
ＫＡＭＡＬ１：プロトコルレベルの分析を行う。
ＫＡＭＡＬ２：フィルター基準とコンテントマッチ（ｃｏｎｔｅｎｔ  ｍａｔｃｈ）に基づいて集合体をつくる。
ＫＡＭＡＬ  １
概観
図１はパケット処理エンジンソフトウェアの典型的なシナリオを示す。
ソフトウェアの主な部品：
１．ボード上のアプリケーションソフトウェア
ａ．ネットワークインターフェイス
ｉ．ＭＡＣ初期化
ｉｉ．ＵＡＲＴ初期化
ｉｉｉ．ＭＡＣのための動的な構成（もしあるとしたら）
ｂ．パケットプロセッサ
ｉ．ＩＰパケットの立証（ＩＰｖ４のための）
ｉｉ．フラグメントの立証
ｉｉｉ．  パケットの再組み立て
ｉｖ．  プロトコルの分析
ｖ．  テーブルを形成する
ｃ．メモリインターフェイス
ｉ．  ＲＤＲＡＭメモリマネジャ
ｉｉ．ＳＲＡＭメモリマネジャ
ｄ．ホストインターフェイ
ｉ．  構成
ｉｉ．  パケットのダウンロード
ｉｉｉ．  テーブルのダウンロード
ｅ．デバッグモニターインターフェイス（ｄｅｂｕｇ  ｍｏｎｉｔｏｒ  ｉｎｔｅｒｆａｃｅ）（もし利用可能であれば）
２．ホストソフトウェア
ａ．ＰＣＩデバイス・ドライバー
ｉ．ＫＡＭＡＬを見つける
ｉｉ．  初期化
ｉｉｉ．  システムの日時設定
ｉｖ．Ｔｉｍｅ  ｔｏ  ｌｉｖｅ設定
ｖ．  テーブルダウンロードの間隔の設定
ｖｉ．タグを読む
ｖｉｉ．パケットを読む
ｂ．ソケット・インターフェイス
ｉ．ソケットを作る
ｉｉ．束ねる
ｉｉｉ．聴き取る
ｉｖ．  受け入れる
ｖ．  読み取る
ｖｉ．  書き取る
正しいネットワークフォーマット（ｂｉｇ  ｅｎｄｉａｎ）。  絶対的に必要とされないなら変換を避けてコーディングスタンダード命名法で必ず区別する。（例えば、すべての小さいエンディアンは  ｌｅ＿ｘｘｘ  名を持つことが出来る）。
マイクロエンジンの並列処理性能を利用する
ＰＣＩ：ＰＣＩ  の取り扱いは低いレベルで使われるべきである。モジュールは最適化された方法のマルチチャンネルＤＭＡ転送、マスターモードデータ転送、割り込みの取り扱いと基本的なデータ転送を含む。
Ｌｉｎｕｘのエンタープライズ版：ＰＣＩドライバとＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）  ライブラリモジュールはＬｉｎｕｘ  ＯＳの３２と６４ｂｉｔバージュンが使用出来る。
ＩＸＰ２４００／ＩＸＰ２８００チップ上にＬｉｎｕｘ  ＯＳをポーティングする。
Ｉｘｆ１１０４ＭＡＣのためのデバイス・ドライバ
ＭＡＣプログラミング
ｉｄｔｔ用のデバイス・ドライバ
ＴＣＡＭプログラミング
チップ上のＰＣＩのためのデバイス・ドライバ
ボード上とホストのコミュニケーション
來入するパケットのＩＸＰ２４００／ＩＸＰ２８００マイクロエンジンレベルでの取り扱い
マイクロエンジンレベルでのＰＣＩの取り扱い
マイクロエンジンレベルでのメモリインターフェイスの取り扱い
オンチップメモリにリソース割り当てを行うためのメモリマネージャ（異なったモジュールからの多数のメモリの同時の接続要求の取り扱い）
マルチスレッド（ｍｕｌｔｉ−ｔｈｒｅａｄｉｎｇ）の使用法、プロセスの同期化、ＸＳＣＡＬアーキテクチャとマイクロエンジンの力を利用するためのＩＸＰ２４００／ＩＸＰ２８００チッププログラミング。
パケットプロセッサ
ｖｉｉ．  ＩＰパケッとの立証：
上記のルーチンは最初のマイクロエンジン（ＭＥ１．）上で動作する。パケットあるいはフラグメントが受け取られるときは、順番に当該機能を呼び出すｉｘｐ  を中断させます。ＩＰパケットヘッダはＩＰｖ４パケットであるかを調べるために検証する。  当該ステータスは主のＡＲＭプロセッサに送られる。
ｖｉｉｉ．  フラグメントの立証：
フラグメントビット（ｆｒａｇｍｅｎｔ  ｂｉｔ）が設定されるか確かめる。  確かめた後に、その状況に応じてメモリマネージャに該ステータスを通知する、プロトコル分析、パケット記憶装置とホストへの転送がＩＸＰ２４００／ＩＸＰ２８００プロセッサの内部で行われなければならない。
ＫＡＭＡＬハードウェアを使ってネットワークの監視をするハードウェアソリューション。それ故に、ＫＡＭＡＬは平行してＩＸＰ２４００／ＩＸＰ２８００チップの他の特別な特徴を利用してハードウェアソリューションとして構築される必要がある。
多くのプロセスが真の平行したアーキテクチャ上で動作して共通のリソースを共有しなければならないのでＫＡＭＡＬの発明は一層のハードウェア（ＶＨＤＬ又はＶｅｒｉｌｏｇ−ＨＤＬプラットホーム上で開発する）の解決となる。  
ここで示すパケット取り扱いのフロント−エンドとＰＣＩドライバは典型的な例である。伝統的に通話の定められた手順がプロトコルを分析するために順番に定められた手順を呼び出すことができるように、我々はｓｏｆからｅｏｆまで、そして次に「リターン」から「呼び出し手順」まで１つのパケットを集めるためのソフトウェアを開発することが出来る。しかしながら、当該ハードウェアソリューションとしては、我々がすべての入ってくるｑｕａｄ−ｏｃｔｅｔｓは調べる必要がある、そして次のｑｕａｄ−ｏｃｔｅｔｓが到着する前に決断しなければならない。当該手順がＰＣＩインターフェイスを持った場合に行なわれる手順である。すべてのＫＡＭＡＬの発明はＫＡＭＡＬがハードウェアプラットホームであると同様に開発を行なうべきである。ソフトウェアで該システムを開発する場合はプログラミングを行なう容易さの範囲にだけでは有効であるが。
【００２６】
それぞれのマイクロエンジンは図１１に示されるように事前割り当てされたアプリケーションプロトコルを調べる、そしてアプリケーションに関係する抽出されたパラメータは該プロトコルを使って、該コントロールプログラムの結果を該マイクロエンジンに報告する。すべてのモジュールが誤った（ｆｌａｓｈ）値を返す場合と、あるいは真（ｔｒｕｅ）を返す場合がある、真を返したモジュールが真である。もう１つのマイクロエンジン（ＭＥ１．）が今までにフラグメントステイタスとパケットの正当性を返している。  データの一部が構造化するように該アプリケーションにとって特殊であって抽出されるパラメータは下記に文書化される。
ＫＡＭＡＬデータアップロードフォーマット
【００２７】
【表２】
2008042892.tif 000004
／＊  ＫＡＭＡＬ  ＳＴＲＵＣＴＵＲＥＳ  ＊／
ｓｔｒｕｃｔ  ＫＡＭＡＬ＿ＦＩＸＥＤ＿ＨＥＡＤＥＲ＿ＦＯＲＭＡＴ
｛
ｕｎｓｉｇｎｅｄ  ｃｈａｒ           ＫＡＭＡＬ＿ＩＤ＿ＳＴＲＩＮＧ［５］；
上記が示す当該ボードの認識。常に  ＫＡＭＡＬのための文字列には“ＫＡＭＡＬ”を含んでいる。ＧＵＬＡＢのためには“ＧＵＬＡＢ”を含んでいる。
ｕｎｓｉｇｎｅｄ  ｃｈａｒ           ＫＡＭＡＬ＿ＶＥＲＳＩＯＮ＿ＳＴＲＩＮＧ［２］；
上記が示すＫＡＭＡＬバージョン番号。  最新バーションは００番号である。
ｕｎｓｉｇｎｅｄ  ｃｈａｒ           ＫＡＭＡＬ＿ＲＥＬＥＡＳＥ＿ＳＴＲＩＮＧ［２］；
上記が示すＫＡＭＡＬリリース番号：  最新版は０．９番です（バージョン０．９）
ｕｎｓｉｇｎｅｄ  ｃｈａｒ           ＫＡＭＡＬ＿ＰＫＴ＿ＴＹＰＥ＿ＩＤＥＮＴＩＦＩＥＲ；
上記が示すレコードタイプ  、
０  ＝  レコードはプロトコル解析テーブル列（ぴったりあった列）
１＝  レコードはオリジナルパケットデータ（レイヤーＩＩ）
ｕｎｓｉｇｎｅｄ  ｓｈｏｒｔ  ｔｏｔａｌ＿ｌｅｎｇｔｈ；
上記が示すレコードの全長、
ぴったりあった列レコードのために：
レコードヘッダのサイズ（２８）  ＋  ぴったりあった列のサイズ（１５２）  ＝１８０
オリジナルパケットデータレコードのために：
レコードヘッダのサイズ（２８  ）＋  レイヤＩＩオリジナルパケットデータ変数＝  変数
ｕｎｓｉｇｎｅｄ  ｌｏｎｇ      ＫＡＭＡＬ＿ＢＯＡＲＤ＿ＴＡＧ；
上記が示すパケットを処理したユニークなＫＡＭＡＬタグ．
ｕｎｓｉｇｎｅｄ  ｌｏｎｇ      ｐａｃｋｅｔ＿ｃｏｕｎｔｅｒ；
上記が示す連続的なパケット番号
ｓｔｒｕｃｔ  ｔｉｍｅｖａｌ  ｅｐｏｃｈ＿ｔｉｍｅ＿ｓｔａｍｐ；
上記の＜ｓｙｓ／ｔｉｍｅ．ｈ＞に定義されたと同様に構造的な時間値に関するパケット到着を示す６４ｂｉｔのタイムスタンプ。
【００２８】
−３２ｂｉｔ：エポック（ｅｐｏｃｈ）を開始することからの秒数
−３２ｂｉｔ：エポック（ｅｐｏｃｈ）を開始することからのマイクロセカンドの数
｝  ＿＿ａｔｔｒｉｂｕｔｅ＿＿（（＿＿ｐａｃｋｅｄ＿＿））；
ｓｔｒｕｃｔ  ｍａｃ＿ａｄｄｒｅｓｓ＿ｆｏｒｍａｔ
｛
ｕｎｓｉｇｎｅｄ  ｃｈａｒ  ｍａｃ＿ａｄｄｒｅｓｓ［６］；
｝  ＿＿ａｔｔｒｉｂｕｔｅ＿＿（（＿＿ｐａｃｋｅｄ＿＿））；
ｓｔｒｕｃｔ  ＫＡＭＡＬ＿ｉｐ＿ｄｅｔａｉｌｓ＿ｆｏｒｍａｔ
｛
ｓｔｒｕｃｔ      ｍａｃ＿ａｄｄｒｅｓｓ＿ｆｏｒｍａｔ  ＫＡＭＡＬ＿ｅｔｈ＿ｓｒｃ＿ｍａｃ＿ａｄｄｒｅｓｓ；
ｓｔｒｕｃｔ      ｍａｃ＿ａｄｄｒｅｓｓ＿ｆｏｒｍａｔ  ＫＡＭＡＬ＿ｅｔｈ＿ｄｓｔ＿ｍａｃ＿ａｄｄｒｅｓｓ；
ｕｎｓｉｇｎｅｄ  ｃｈａｒ      ＫＡＭＡＬ＿ｔｙｐｅ＿ｏｆ＿ｓｅｒｖｉｃｅ；
ｕｎｓｉｇｎｅｄ  ｃｈａｒ      ＫＡＭＡＬ＿ｉｐ＿ｐｒｏｔｏｃｏｌ；
ｕｎｓｉｇｎｅｄ  ｓｈｏｒｔ      ＫＡＭＡＬ＿ｉｐ＿ｐａｃｋｅｔ＿ｌｅｎｇｔｈ；
ｕｎｓｉｇｎｅｄ  ｌｏｎｇ      ＫＡＭＡＬ＿ｉｐ＿ｓｏｕｒｃｅ＿ｉｐ＿ａｄｄｒｅｓｓ；
ｕｎｓｉｇｎｅｄ  ｌｏｎｇ      ＫＡＭＡＬ＿ｉｐ＿ｄｅｓｔｉｎａｔｉｏｎ＿ｉｐ＿ａｄｄｒｅｓｓ；
｝  ＿＿ａｔｔｒｉｂｕｔｅ＿＿（（＿＿ｐａｃｋｅｄ＿＿））；
ｓｔｒｕｃｔ  ＫＡＭＡＬ＿ｔｃｐ＿ｄｅｔａｉｌｓ＿ｆｏｒｍａｔ
｛
ｕｎｓｉｇｎｅｄ  ｓｈｏｒｔ      ＫＡＭＡＬ＿ｔｃｐ＿ｓｏｕｒｃｅ＿ｐｏｒｔ；
ｕｎｓｉｇｎｅｄ  ｓｈｏｒｔ      ＫＡＭＡＬ＿ｔｃｐ＿ｄｅｓｔｉｎａｔｉｏｎ＿ｐｏｒｔ；
ｕｎｓｉｇｎｅｄ  ｃｈａｒ      ＫＡＭＡＬ＿ｔｃｐ＿ｃｏｎｔｒｏｌ＿ｆｌａｇｓ；
ｕｎｓｉｇｎｅｄ  ｃｈａｒ      ＫＡＭＡＬ＿ａｐｐｌｉｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｔｙｐｅ；
上記がテーブル表すフィールドは（ＫＡＭＡＬ＿ａｐｐｌｉｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｓｔｒｉｎｇに送られる）抽出された情報のタイプを表すコードを含む。アプリケーションプロトコルに依存する。
例：
アプリケーションタイプ  フィールド    ＫＡＭＡＬ＿ａｐｐｌｉｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｓｔｒｉｎｇ
ＨＴＴＰ                        １    ウェブサイトのアドレッス
ＰＯＰＳメール                  １        メールユーザー番号
ＳＭＴＰメール                  １        誰にメールを送ったのかのメールの身元確認番号
誰から受け取ったメールであるかを識別する身元確認番号
ＦＴＰ                    １        ログギングした場合の確認番号
ｕｎｓｉｇｎｅｄ  ｓｈｏｒｔ      ＫＡＭＡＬ＿ｔｃｐ＿ａｐｐｌｉｃａｔｉｏｎ＿ｐｒｏｔｏｃｏｌ；
上記はアプリケーションレベルプロトコルを示す２ｂｙｔｅのコードです。
例：ＨＴＴＰのための８０、ｓｓｌ―ｈｔｔｐｓのための４４３、ＰＯＰ３メールのための１１１０、ＳＭＴＰ  メールのための２５。
｝  ＿＿ａｔｔｒｉｂｕｔｅ＿＿（（＿＿ｐａｃｋｅｄ＿＿））；
ｓｔｒｕｃｔ  ＫＡＭＡＬ＿ａｐｐｌｉｃａｔｉｏｎ＿ａｎａｌｙｓｉｓ＿ｆｏｒｍａｔ
｛
ｕｎｓｉｇｎｅｄ  ｃｈａｒ      ＫＡＭＡＬ＿ａｐｐｌｉｃａｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｔｅｘｔ［４０］；
上記が示す空（ＮＵＬＬ）で終えたアプリケーションプロトコルのテキスト記述。
例：  ＨＴＴＰ、ｓｓｌ−ｈｔｔｐｓ、ＰＯＰ３メール、ＳＭＴＰメール。
［次のバージュン（ｖ１．０１）でこのフィールドは削除されます。アプリケーションはクライアントＧＵＩの当該フィールドにテーブル表示されるために  ＫＡＭＡＬ＿ｔｃｐ＿ａｐｐｌｉｃａｔｉｏｎ＿ｐｒｏｔｏｃｏｌをデコードすることが出来る。使用するコードが標準化されるまでベータバージョンでコードはＫＡＭＡＬによってデコードされて通信する列はこのフィールドに送られる］
ｕｎｓｉｇｎｅｄ  ｃｈａｒ      ＫＡＭＡＬ＿ａｐｐｌｉｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｓｔｒｉｎｇ［８０］；
空（ＮＵＬＬ）で終わった記述が列に含まれている場合はパケットのパラメータを抽出したものである。
例：  ウエッブサイトアドレス、ユーザー身元確認、誰に送られたのかを示す電子メールの身元確認、誰から送られてきたのか示す電子メールの身元確認。
｝  ＿＿ａｔｔｒｉｂｕｔｅ＿＿（（＿＿ｐａｃｋｅｄ＿＿））；
ｓｔｒｕｃｔ  ＫＡＭＡＬ＿ｐａｔ＿ｒｏｗ＿ｆｏｒｍａｔ
｛
ｓｔｒｕｃｔ  ＫＡＭＡＬ＿ｉｐ＿ｄｅｔａｉｌｓ＿ｆｏｒｍａｔ    ＫＡＭＡＬ＿ｉｐ＿ｄｅｔａｉｌｓ；
ｓｔｒｕｃｔ  ＫＡＭＡＬ＿ｔｃｐ＿ｄｅｔａｉｌｓ＿ｆｏｒｍａｔ    ＫＡＭＡＬ＿ｔｃｐ＿ｄｅｔａｉｌｓ；
ｓｔｒｕｃｔ  ＫＡＭＡＬ＿ａｐｐｌｉｃａｔｉｏｎ＿ａｎａｌｙｓｉｓ＿ｆｏｒｍａｔ  ａｐｐｌｉｃａｔｉｏｎ＿ａｎａｌｙｓｉｓ；
｝  ＿＿ａｔｔｒｉｂｕｔｅ＿＿（（＿＿ｐａｃｋｅｄ＿＿））；
ＫＡＭＡＬ
データを設定する：  ＫＡＭＡＬ／ＧＵＬＡＢボードのタイムスタンプを設定する。
データを取得する：  上記のＫＡＭＡＬ／ＧＵＬＡＢボードの当該日付／時間を返す。
フィルターテーブルを読む：ＫＡＭＡＬ−ＩＩで全部のフィルターテーブルを読む
フィルターテーブルをアップロードする：ＫＡＭＡＬ−ＩＩ  で新しいフィルターテーブルをつくる
１つのフィルター列を読む：ＫＡＭＡＬ−ＩＩ  で１つのフィルター列を読む
１つのフィルター列をセットする：ＫＡＭＡＬ−ＩＩ  で１つのフィルター列を修正する
１つのフィルター列を加える：ＫＡＭＡＬ−ＩＩ  で新しいフィルター列を加える
１つのフィルター列を削除する：ＫＡＭＡＬ−ＩＩで新しいフィルター列を削除する
ＫＡＭＡＬタグを取得する
プロトコルテーブを取得する
プロトコルテーブルを加える
プロトコルテーブルを削除する
デフォルト設定に設定する
大部分のＫＡＭＡＬの呼び出しが内部使用のためにあります、そしてＧＵＬＡＢセッション分析インターフェイスが  ｍｓｓ  のために必要とされるように以下にＧＵＬＡＢ  ボードについてのより詳細な説明に入りました。
ＧＵＬＡＢボード
ＧＵＬＡＢ  ボードの初期化：
当該ボードを初期化するために使用できる。仮にＧＵＬＡＢボードは既に誰かによってｉｎｉｔ値が他のプログラムによって構成を設定されたならば、そしてもし最新のプログラムが該ｉｎｉｔ値をリセットすることを望むならば、該関数を呼び出すことが出来る。この関数に対して呼び出しが行なわれる時、ＧＵＬＡＢボードの機能は工場設定時と同じように初期化される。
アプリケーションテーブルをセットする：
当該機能はどのアプリケーションが分析されるはずであるかを決定するために使われるテーブルをＧＵＬＡＢ  ボードに作る。このテーブルはいくつかの列から出来ている。  該テーブル内のそれぞれの列がアプリケーションタイプ、アプリケーションのテキストテーブルから出来ていて、そしてフラグをたてることを可能にする。
例として、
＃ＡＰＰＬＩＣＡＴＩＯＮ＿ＮＵＭＢＥＲ      ＡＰＰＬＩＣＡＴＩＯＮ＿ＮＡＭＥ      ＥＮＡＢＬＥ／ＤＩＳＡＢＬＥ
１                                  ＨＴＴＰ                        １
２                                  ＳＭＴＰ                        １
３                                  ＲＴＰ                          ０
ｅｎａｂｌｅ／ｄｉｓａｂｌｅフィールドが“１”の値は上記の通りにこのタイプのアプリケーションのためのセッションが組み立てられるために必要となる。該フィールがゼロ“０”を示す場合は上記の通りにこのタイプのアプリケーションのためのセッションが組み立てられる必要がないことを示す。
アプリケーションテーブルを取得する：
すべてのアプリケーションテーブルとともに当該アプリケーションに付いているｅｎａｂｌｅ／ｄｉｓａｂｌｅ状態を読む。
アプリケーション列の詳細：
将来の拡張のためには、新しいアプリケーションプロトコルを定義することが予想される、そして加えられるかあるいは削除されることもありえる。
アプリケーション列を加える：
将来の拡張のために。  将来、それは新しいアプリケーションプロトコルを定義することが予想される、そして加えられるかあるいは削除することも出来る。
アプリケーション列をセットする：
アプリケーションテーブルのアプリケーション列をｅｎａｂｌｅにするかあるいはｄｉｓａｂｌｅにするためには、１つのアプリケーションのためにセッション分析をｅｎａｂｌｅにするか、あるいはｄｉｓａｂｌｅにする該機能を使う。
アプリケーション列を取得する：
アプリケーション列とｅｎａｂｌｅ／ｄｉｓａｂｌｅの状態を読む。この機能はアプリケーションのテキストの記述とｅｎａｂｌｅ／ｄｉｓａｂｌｅのフラグの状態を読む。
ファイル名ベースをセットする：
ＧＵＬＡＢは種々のフォーマットでデータベースをつくることが出来る。例えば、毎日、毎週、あるいは毎月それぞれのアプリケーションタイプのために別個のファイルをつくることが出来る。  該機能を呼び出すアプリケーションを使ってＧＵＬＡＢが異なったファイルをつくる基本となるファイル名を提供することが出来るようにする。  
実行可能なフォーマットが下に示される。
ＳｅｔＦｉｌｅｎａｍｅＢａｓｅ  （ｉｎｔ  ＡＰＰＬＩＣＡＴＩＯＮ＿ＴＹＰＥ，  ｉｎｔ  ＭＥＴＨＯＤ＿ＴＹＰＥ，  ｕｎｓｉｇｎｅｄ  ｃｈａｒ  ＊ｂａｓｅ＿ｓｔｒｉｎｇ［］）：
下記は実行例である。
ＳｅｔＦｉｌｅｎａｍｅＢａｓｅ  （  ＳＭＴＰ＿ＡＰＰＬＩＣＡＴＩＯＮ，  ＭＯＮＴＨ＿ＷＩＳＥ，  “ｍｓｓ＿ｓｍｔｐ＿ｓｅｓｓｉｏｎｓ＿”，  ＧＵＬＡＢ＿ＭＯＮＴＨ＿ＳＴＲＩＮＧ，  ”＿２００６”，  ＮＵＬＬ）；  
下記の列のようなファイルをつくる。
ｍｓｓ＿ｓｍｔｐ＿ｓｅｓｓｉｏｎｓ＿ＪＵＮ＿２００６．ｇｌｂ
ｍｓｓ＿ｓｍｔｐ＿ｓｅｓｓｉｏｎｓ＿ＪＵＬ＿２００６．ｇｌｂ
下記の関数に従う呼び出し機能が少し異なったファイルタイプをつくる。
ＳｅｔＦｉｌｅｎａｍｅＢａｓｅ  （  ＳＭＴＰ＿ＡＰＰＬＩＣＡＴＩＯＮ，  ＭＯＮＴＨ＿ＷＩＳＥ，  “ｍｓｓ＿ｓｍｔｐ＿ｓｅｓｓｉｏｎｓ＿”，  ＧＵＬＡＢ＿ＭＯＮＴＨ＿ＮＵＭＥＲＩＣＡＬ，  ”＿２００６”，  ＮＵＬＬ）；
ｍｓｓ＿ｓｍｔｐ＿ｓｅｓｓｉｏｎｓ＿０６＿２００６．ｇｌｂ
ｍｓｓ＿ｓｍｔｐ＿ｓｅｓｓｉｏｎｓ＿０７＿２００６．ｇｌｂ
下記に他の例を示す。
ＳｅｔＦｉｌｅｎａｍｅＢａｓｅ  （ＡＬＬ＿ＡＰＰＬＩＣＡＴＩＯＮＳ，  ＤＡＴＥ＿ＭＯＮＴＨ＿ＷＩＳＥ，  “ｍｓｓ＿ａｐｐｌｉｃａｔｉｏｎ＿ｓｅｓｓｉｏｎｓ＿２００６”，  ＧＵＬＡＢ＿ＭＯＮＴＨ＿ＤＡＴＥ＿  ＮＵＭＥＲＩＣＡＬ，  ＮＵＬＬ）；  
Ｗｉｌｌ  ｃｒｅａｔｅ
ｍｓｓ＿ａｐｐｌｉｃａｔｉｏｎ＿ｓｅｓｓｉｏｎｓ＿２００６０６０１．ｇｌｂ
ｍｓｓ＿ａｐｐｌｉｃａｔｉｏｎ＿ｓｅｓｓｉｏｎｓ＿２００６０６０２．ｇｌｂ
ｍｓｓ＿ａｐｐｌｉｃａｔｉｏｎ＿ｓｅｓｓｉｏｎｓ＿２００６０６３０．ｇｌｂ
ｅｔｃ
ファイル名ベースを取得する：
現在使用中のファイル名を基本としたタイプを返す  。
所定のアプリケーション用のファイル名を取得する：
将来使用するために、不完全なセッションの分析をすることを計画した。
ＧＵＬＡＢタグを取得する：
ＧＵＬＡＢの一意的なタグを返す。ファイル名を基本としたかあるいは分析テーブルをつくるために使うことが出来る。
ＧＵＬＡＢデータアップロードフォーマット
【００２９】
【表３】
2008042892.tif 000005
ｓｔｒｕｃｔ  ＧＵＬＡＢ＿ＦＩＸＥＤ＿ＨＥＡＤＥＲ＿ＦＯＲＭＡＴ
｛
ｕｎｓｉｇｎｅｄ  ｃｈａｒ      ＧＵＬＡＢ＿ＩＤ＿ＳＴＲＩＮＧ［５］；
ボードの認識。常に  ＧＵＬＡＢのために列に“ＧＵＬＡＢ”を含む。
ｕｎｓｉｇｎｅｄ  ｃｈａｒ      ＧＵＬＡＢ＿ＶＥＲＳＩＯＮ＿ＳＴＲＩＮＧ［２］；
ＧＵＬＡＢバーション番号
ｕｎｓｉｇｎｅｄ  ｃｈａｒ      ＧＵＬＡＢ＿ＲＥＬＥＡＳＥ＿ＳＴＲＩＮＧ［２］；
ＧＵＬＡＢリリース番号
ｕｎｓｉｇｎｅｄ  ｃｈａｒ      ＧＵＬＡＢ＿ＰＫＴ＿ＴＹＰＥ＿ＩＤＥＮＴＩＦＩＥＲ；
レコードタイプ、
０＝  レコード、はセッション解析テーブル列（ちょうどあてはまる列）
１＝  レコード、はセッションデータ列
ｕｎｓｉｇｎｅｄ  ｓｈｏｒｔ      ｔｏｔａｌ＿ｌｅｎｇｔｈ；
レコードの全長、
列記録の設定のために：
ヘッダレコードのサイズ  ＋  設定する列のサイズ
オリジナルパケトデータレコードのために：
レコードヘッダサイズ（２８）  ＋  オリジナルセッションデータサイズ（変数）
ｕｎｓｉｇｎｅｄ  ｌｏｎｇ      ＧＵＬＡＢ＿ＢＯＡＲＤ＿ＴＡＧ；
パケットを処理したユニークなＧＵＬＡＢボードタグ
ｕｎｓｉｇｎｅｄ  ｌｏｎｇ      ｓｅｓｓｉｏｎ＿ｃｏｕｎｔｅｒ；
連続的なセッション番号
｝  ＿＿ａｔｔｒｉｂｕｔｅ＿＿（（＿＿ｐａｃｋｅｄ＿＿））；
ｓｔｒｕｃｔ  ＧＵＬＡＢ＿ｓｅｓｓｉｏｎ＿ｄｅｔａｉｌｓ＿ｆｏｒｍａｔ
｛
ｓｔｒｕｃｔ  ｔｉｍｅｖａｌ  ｓｔａｒｔ＿ｅｐｏｃｈ＿ｔｉｍｅ＿ｓｔａｍｐ；
＜ｓｙｓ／ｔｉｍｅｈ＞に定義されたと同様に定義された構造的な時間値の条件におけるセッション開始の６４ｂｉｔタイムスタンプ。
【００３０】
―３２ｂｉｔ：エポック開始らの秒数
−３２ｂｉｔ：エポック開始からのマイクロセカンド数
ｓｔｒｕｃｔ  ｔｉｍｅｖａｌ  ｅｎｄ＿ｅｐｏｃｈ＿ｔｉｍｅ＿ｓｔａｍｐ；
＜ｓｙｓ／ｔｉｍｅｈ＞に定義されたと同様に定義された構造的な時間値の条件におけるセッション終了の６４ｂｉｔタイムスタンプ。
【００３１】
―３２ｂｉｔ：エポック開始らの秒数
−３２ｂｉｔ：エポック開始からのマイクロセカンド数
長期に無署名な場合      ｎｏ＿ｏｆ＿ｐａｃｋｅｔｓ
１つのＧＵＬＡＢセッションをつくるために組み立てられた個別のパケットの番号を含む。
長期に無署名な場合        ｓｅｓｓｉｏｎ＿ｄａｔａ＿ｓｉｚｅ  
セッションを構成するｂｙｔｅの合計数を含んでいる。
長期にｃｈａｒに無署名な場合    ＧＵＬＡＢ＿ａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅ；
このフィールドにはアプリケーションのタイプを示すコードを含む。
例：
アプリケーションタイプ    フィールド
ＨＴＴＰ                          １
ＰＯＰ３                          ２
ＳＭＴＰ                          ３
ＦＴＰ                            ４
Ｐａｄｄｉｎｇ  ｂｙｔｅｓ
｝  ＿＿ａｔｔｒｉｂｕｔｅ＿＿（（＿＿ｐａｃｋｅｄ＿＿））；
ｓｔｒｕｃｔ  ＧＵＬＡＢ＿ａｐｐｌｉｃａｔｉｏｎ＿ｉｎｆｏｒｍａｔｉｏｎ
｛
ｃｈａｒに無署名な場合  ＊ＫＡＭＡＬ＿ｐｏｉｎｔｅｒ＿ｔｏ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｓｔｒｉｎｇ［ＴＢＤ］［ＴＢＤ］；
それぞれのアプリケーション記述列の差し引き計算値、空“ＮＵＬＬ”のポインターを持っているリストの終わり。
【００３２】
長期にｃｈａｒに無署名な場合  ＫＡＭＡＬ＿ａｐｐｌｉｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｓｔｒｉｎｇ［ＴＢＤ］［ＴＢＤ］；
空（ＮＵＬＬ）で終わった列がパケットの抽出されたパラメータを含む、
例：ＳＭＴＰのために、
ＦＲＯＭ，  ＴＯ，  Ｆｒｏｍ，  Ｔｏ，  Ｃｃ，  Ｓｕｂｊｅｃｔ，  ａｔｔａｃｈｍｅｎｔ  ｆｉｌｅ  ｎａｍｅｓ
ＨＴＴＰのために、
ＨＴＴＰ  ｒｅｑｕｅｓｔ，  Ｗｅｂｓｉｔｅ，  ｕｒｌ，  Ｃｏｎｔｅｎｔ−Ｔｙｐｅ
｝  ＿＿ａｔｔｒｉｂｕｔｅ＿＿（（＿＿ｐａｃｋｅｄ＿＿））；
ｓｔｒｕｃｔ  ＧＵＬＡＢ＿ｓａｔ＿ｒｏｗ＿ｆｏｒｍａｔ
｛
ｓｔｒｕｃｔ  ＧＵＬＡＢ＿ｓｅｓｓｉｏｎ＿ｄｅｔａｉｌｓ＿ｆｏｒｍａｔ
ＧＵＬＡＢ＿ｓｅｓｓｉｏｎ＿ｄｅｔａｉｌｓ；
ｓｔｒｕｃｔ  ＧＵＬＡＢ＿ａｐｐｌｉｃａｔｉｏｎ＿ｉｎｆｏｒｍａｔｉｏｎ
ＧＵＬＡＢ＿ａｐｐｌｉｃａｔｉｏｎ＿ｉｎｆｏｒｍａｔｉｏｎ；
｝  ＿＿ａｔｔｒｉｂｕｔｅ＿＿（（＿＿ｐａｃｋｅｄ＿＿））；
ＧＵＬＡＢデータとインデックスファイル構造
１．ＫＡＭＡＬから受け取ったすべてのパケットはＧＵＬＡＢによって処理される。
２．不完全なセッションは可能なかぎりに組み立てられる、そしてこれらの不完全なセッションデータは同じく別にタグを付けられたファイルに保管される。
３．最終バージョンは要求されるようにすべてのプロトコル分析機能を持つ。
要求されるＲＴＰ、ＳＩＰ、Ｈ．３２３、ＶｏＩＰ、ＩＣＭＰ、Ｔｅｌｎｅｔ、ＦＴＰ、ＤＮＳのセッションから抽出されたどのようなパラメータに対しても分析する。
４．“キープアライブ”を持っているＨＴＴＰ  セッションと多くのセッションが適切に  ＧＵＬＡＢ  によって処理される。
５．複数のメールが異なったセッションとして処理される。
６．ＫＡＭＡＬとＧＵＬＡＢボードがインストールされるとデバイス・ドライバはＬｉｎｕ
ＯＳのもとで稼動する。ＧＵＬＡＢのためのデバイス・ドライバとホストのハードディスク・ドライバは完全に結ばれている。従って、複数の部分にコピーされているセッションデータのオーバーヘッドを避けることが出来る。
７．ＧＵＬＡＢはアプリケーション毎に１つのファイルをつくります。加えるにすべての“不完全なセッション”を集めるために同じく１つのファイルをつくります。ハイレベルな詳細は次の通りである。
【００３３】
【表４】
2008042892.tif 000006
【００３４】
【表５】
2008042892.tif 000007
【００３５】
【表６】
2008042892.tif 000008
ＧＵＬＡＢセッションは下記のインデックスファイルとデータファイルの２つの部分に保管される。
インデックスファイル
データファイル
上記の１．は、“ＧＵＬＡＢ  インデックスファイル”と呼ばれる固定長記録から出来ている、オリジナルパケットデータを含むが、“ＧＵＬＡＢデータファイル”（上記のデータファイル）は通信したオリジナルパケットデータへのポインターから出来ているだけが記録されている。
【００３６】
上記２．には“ＧＵＬＡＢデータファイル”と呼ばれるタイプは可変長記録から出来ている、そして実際のオリジナルパケットを含む（可変長なものである）。
【００３７】
上記１．のインデックスファイルが検索、ソート、収集してグラフィックとテーブルを表示することに使用出来る、そしてクエリ／クエリスクリプト／言語のサポートをするために使うことが出来る。
【００３８】
上記２．データファイルは、データの実際のアクセスに対応した上記１．インデックスファイルを通して直接アクセスすることが出来る実際のオリジナルパケットで出来ている。
【００３９】
上記１．データフィールドにとって特殊な部分は青色で表示する、そして２．データファイルの特殊な部分は赤色でテーブルに表示する。
【図面の簡単な説明】
【００４０】
【図１】本発明のパケット処理エンジンの典型的な開発のシナリオを示す。
【図２】本発明のフィールドパケット処理エンジン（ｆｉｅｌｄ−ｐａｃｋｅｔ  ｐｒｏｃｅｓｓｉｎｇ  ｅｎｇｉｎｅ）のシステムを示す。
【図３】本発明のパケット処理エンジンの機能的なブロック図である。
【図４】本発明のパケット処理エンジンの高度なハードウェアブロック図である。
【図５】本発明のネットワークプロセッサを使ったハードウェアブロック図である。
【図６】本発明のパケット処理エンジンソフトウェアスタック図である。
【図７】本発明のパケット処理エンジンのための基本的なソフトウェアフローチャートを示す。
【図８】本発明のセッションアナライザ（ｓｅｓｓｉｏｎ  ａｎａｌｙｚｅｒ）を示す。
【図９】本発明のフィールドセッションアナライザ（ｆｉｅｌｄ−ｓｅｓｓｉｏｎ  ａｎａｌｙｚｅｒ）システムを示す。
【図１０】本発明の  ＲＤＲＡＭ  メモリマップ（ｍｅｍｏｒｙ  ｍａｐ）を示す。
【図１１】本発明のセッションアナライザの動作を示す。
【図１２】本発明の  マイクロエンジン  アーキテクチャを示す。
【図１３】本発明のパケット処理エンジンとセッションアナライザが本発明よって実行されるネットワークを示す。
【符号の説明】
【００４１】
１０  ネットワーク
２１、２２  ローカルエリアネットワーク
２５  スイッチングハブ
２６  ＴＡＰ
２７  ファイアウォール
２８  ルーター
３０  ＫＡＭＡＬ
５０  ＧＵＬＡＢ
７０  サーバー
【図１】
2008042892.tif 000009
【図２】
2008042892.tif 000010
【図３】
2008042892.tif 000011
【図４】
2008042892.tif 000012
【図５】
2008042892.tif 000013
【図６】
2008042892.tif 000014
【図７】
2008042892.tif 000015
【図８】
2008042892.tif 000016
【図９】
2008042892.tif 000017
【図１０】
2008042892.tif 000018
【図１１】
2008042892.tif 000019
【図１２】
2008042892.tif 000020
【図１３】
2008042892.tif 000021
【外国語明細書】
2008042892.tif 000022
2008042892.tif 000023
2008042892.tif 000024
2008042892.tif 000025
2008042892.tif 000026
2008042892.tif 000027
2008042892.tif 000028
2008042892.tif 000029
2008042892.tif 000030
2008042892.tif 000031
2008042892.tif 000032
2008042892.tif 000033
2008042892.tif 000034
2008042892.tif 000035
2008042892.tif 000036
2008042892.tif 000037
2008042892.tif 000038
2008042892.tif 000039
2008042892.tif 000040
2008042892.tif 000041
2008042892.tif 000042
2008042892.tif 000043
2008042892.tif 000044
2008042892.tif 000045
2008042892.tif 000046
2008042892.tif 000047
2008042892.tif 000048
2008042892.tif 000049
2008042892.tif 000050
2008042892.tif 000051
2008042892.tif 000052
2008042892.tif 000053
2008042892.tif 000054
2008042892.tif 000055
2008042892.tif 000056
2008042892.tif 000057
2008042892.tif 000058
2008042892.tif 000059
2008042892.tif 000060
2008042892.tif 000061
2008042892.tif 000062
【図１】
2008042892.tif 000063
【図２】
2008042892.tif 000064
【図３】
2008042892.tif 000065
【図４】
2008042892.tif 000066
【図５】
2008042892.tif 000067
【図６】
2008042892.tif 000068
【図７】
2008042892.tif 000069
【図８】
2008042892.tif 000070
【図９】
2008042892.tif 000071
【図１０】
2008042892.tif 000072
【図１１】
2008042892.tif 000073
【図１２】
2008042892.tif 000074
【図１３】
2008042892.tif 000075