JP2008042892A - ネットワーク監視システムとその動作方法 - Google Patents
ネットワーク監視システムとその動作方法 Download PDFInfo
- Publication number
- JP2008042892A JP2008042892A JP2007165587A JP2007165587A JP2008042892A JP 2008042892 A JP2008042892 A JP 2008042892A JP 2007165587 A JP2007165587 A JP 2007165587A JP 2007165587 A JP2007165587 A JP 2007165587A JP 2008042892 A JP2008042892 A JP 2008042892A
- Authority
- JP
- Japan
- Prior art keywords
- packet
- session
- data
- protocol
- kamal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/18—Protocol analysers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【課題】ネットワーク監視システムにおける処理性能、スケーラビリティの向上を図る。
【解決手段】ハードウェアベースのネットワーク監視システムとする。該システムは、パケット処理エンジン及び／またはセッションレベル解析のためのアプリケーション層プロセッサを有する。そのパケットエンジンは、（ａ）パケットをスニフしてトラフィックを解析するネットワークプロセッサと、（ｂ）パケット処理のためのコアエンジンであって、プロトコルレベルとアプリケーションレベルとにおいてプロトコル解析データを構成するためにプロトコルを抽出する手段と、パケットのプロトコルベースの解析手段とを有するコアエンジンとを有するパケット処理エンジンを有する。また、アプリケーション層プロセッサは、（ａ）すべてのセッションを抽出し、セッションデータを構成する手段と、（ｂ）パケットセッションベースを解析する手段とを有する。
【選択図】図１３
【解決手段】ハードウェアベースのネットワーク監視システムとする。該システムは、パケット処理エンジン及び／またはセッションレベル解析のためのアプリケーション層プロセッサを有する。そのパケットエンジンは、（ａ）パケットをスニフしてトラフィックを解析するネットワークプロセッサと、（ｂ）パケット処理のためのコアエンジンであって、プロトコルレベルとアプリケーションレベルとにおいてプロトコル解析データを構成するためにプロトコルを抽出する手段と、パケットのプロトコルベースの解析手段とを有するコアエンジンとを有するパケット処理エンジンを有する。また、アプリケーション層プロセッサは、（ａ）すべてのセッションを抽出し、セッションデータを構成する手段と、（ｂ）パケットセッションベースを解析する手段とを有する。
【選択図】図１３
Description
本発明は、ネットワークデータトラフィック（ｎｅｔｗｏｒｋ ｄａｔａ ｔｒａｆｆｉｃ）解析とパケットセッションレベル（ｐａｃｋｅｔ ｓｅｓｓｉｏｎ ｌｅｖｅｌ）の解析のためのネットワーク監視システムと該システムの動作方法に関する。
従来、我々は ｓｏｆ から ｅｏｆ まで１つのパケットを集めるためにそして次にきまった通話手順にもどるソフトウェアの開発をすることが出来ます、通話手順がプロトコルを解析するために順番に通話手順を呼びだすことが出来る。ソフトウェアはプログラミングを容易に出来る範囲内では有用である。以下に、我々はパケット解析のためのソフトウェア解決を提供する。ハードウェア解決として、ネットワークから來入するすべてのｑｕａｄ−ｏｃｔｅｔを調べてそして決断する、次のｑｕａｄ−ｏｃｔｅｔが到着する前に。我々の本発明はソフトウェアソリューションとして多くの工程が共通のリソースを共有して真に併用処理する集合体の構造を動作させなければならない。
本発明の一目的は、ネットワークプロセッサチップの並列処理その他の特殊な機能を利用して、ハードウェアソリューションのアイデアに基づく新規なソリューションにより、上記の限界を克服することである。
本発明の他の目的は、真の同様な構造体を動作させるためにそして共通なリソースを共有する範囲で処理を行なうことである。
本発明の更なる目的は、全二重のリアルタイムネットワークトラフィック（ｒｅａｌ−ｔｉｍｅ ｎｅｔｗｏｒｋ ｔｒａｆｆｉｃ）用の監視システムを提供することである。
本発明の他の目的は、中核となるネットワークのリアルタイムＩＰデータ（ｒｅａｌ−ｔｉｍｅ ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ ｄａｔａ）解析を提供するリアルタアイムの能力を提供することである。
本発明のさらに別の目的は、マイクロエンジンコードの革新的なアーキテクチャ（ａｒｃｈｉｔｅｃｔｕｒｅ）、各マイクロエンジン（ｍｉｃｒｏｅｎｇｉｎｅ）間のデータの流れ、各マイクロエンジンとＡＲＭコア（ＡＲＭ ｃｏｒｅ）間のデータの流れにより、高性能とスケーラビリティを提供することである。
本発明のさらに別の目的は、マイクロエンジンレベルにおいてパケットの再組み立てをするシステムを提供することである。
本発明のさらに別の目的は、上記の要求を満たすネットワーク監視システムを提供することである。
本発明のさらに別の目的は、上記の要求を満たすパケット処理エンジンとアプリケーション層プロセッサを提供することである。
本発明のさらに別の目的は、前記監視システムを用いて監視及び解析する方法を提供することである。
本発明のさらに別の目的は、監視及び解析のためのソフトウェアを提供することである。
上記目的の少なくとも１つを達成するために、本発明の一態様では、ネットワークデータトラフィックを監視するためのハードウェアベースのネットワーク監視システムを提供する。該システムは、
（ｉ）パケット処理エンジンであって、
（ａ）パケットをスニフしてトラフィックを解析するネットワークプロセッサと、
（ｂ）パケット処理のためのコアエンジンであって、
・プロトコルレベルとアプリケーションレベルとにおいてプロトコル解析データを構成するためにプロトコルを抽出する手段と、
・前記パケットのプロトコルベースの解析手段を有するコアエンジンとを有するパケット処理エンジン、及び／または、
（ｉｉ）セッションレベル解析のためのアプリケーション層プロセッサであって、
（ａ）すべてのセッションを抽出し、セッションデータを構成する手段と、
（ｂ）前記パケットセッションベース解析をする手段を有するアプリケーション層プロセッサとを有する。
（ｉ）パケット処理エンジンであって、
（ａ）パケットをスニフしてトラフィックを解析するネットワークプロセッサと、
（ｂ）パケット処理のためのコアエンジンであって、
・プロトコルレベルとアプリケーションレベルとにおいてプロトコル解析データを構成するためにプロトコルを抽出する手段と、
・前記パケットのプロトコルベースの解析手段を有するコアエンジンとを有するパケット処理エンジン、及び／または、
（ｉｉ）セッションレベル解析のためのアプリケーション層プロセッサであって、
（ａ）すべてのセッションを抽出し、セッションデータを構成する手段と、
（ｂ）前記パケットセッションベース解析をする手段を有するアプリケーション層プロセッサとを有する。
本発明の他の一態様では、ネットワークデータトラフィックを監視するハードウェアベースの方法を提供する。該方法は、
ａ．パケットをスニフする段階と、
ｂ．フラグメンテーションと再組立のために前記スニフされたパケットをチェックする段階と、
ｃ．前記チェックされたパケットのプロトコルを解析する段階と、
ｄ．前記解析されたパケットをホストメモリに保存する段階と、
ｅ．前記保存されたパケットからセッションを生成する段階と、
ｆ．前記セッションを解析して分離する段階と、
ｇ．前記分離したセッションを前記ホストメモリにアップロードする段階とを有する。
ａ．パケットをスニフする段階と、
ｂ．フラグメンテーションと再組立のために前記スニフされたパケットをチェックする段階と、
ｃ．前記チェックされたパケットのプロトコルを解析する段階と、
ｄ．前記解析されたパケットをホストメモリに保存する段階と、
ｅ．前記保存されたパケットからセッションを生成する段階と、
ｆ．前記セッションを解析して分離する段階と、
ｇ．前記分離したセッションを前記ホストメモリにアップロードする段階とを有する。
本発明の更なる局面に従って、パケットを分析するためにマイクロエンジンコードのアーキテクチャとデータがそれぞれのマイクロエンジンの間にパケットを分析するために使用されるこれらのマイクロエンジンのそれぞれとＡＲＭコアにデータが流入したり流れ出したりする機能を提供する、上記の通りにそれぞれのマイクロエンジンの間にマイクロエンジンのアーキテクチャが流入すると言いました、マイクロエンジンのアーキテクチャに同じ様に集積されているパイプライン方式を併用して開発することが出来る。
本発明の主要な具体化は、ネットワークデータトラフィックを監視することのためのネットワーク監視システムを基本としたハードウェアである、パケットをスニフ（ｓｎｉｆｆ）するための、そしてトラフィックを解析するためのネットワークプロセッサで構成されている。アプリケーションレベルとプロトコルレベルにおけるプロトコル分析データを構築するためにプロトコルの抽出をする手段、パケットのプロトコルを基本とした解析のための手段、セッションレベル解析用のアプリケーション層プロセッサ、すべてのセッションの抽出とセッションデータを構築するための手段、パケットのセッションベース（ｓｅｓｓｉｏｎ−ｂａｓｅ）の分析の手段等である。
下記に本発明の具体化されたものを列記する。
・ネットワークプロセッサがＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｆａｃｅ）を使って主要システムに付加されたこと。
・ネットワークプロセッサによってＰＣＩのマスターとスレーブの役割を努めるように設定されること。
・パケット処理エンジンはシステムにおけるルックアップテーブル（ｌｏｏｋｕｐ ｔａｂｌｅ）を使い自由に選択することが出来るコンテントアドレサブルメモリ（Ｃｏｎｔｅｎｔ Ａｄｄｒｅｓｓａｂｌｅ Ｍｅｍｏｒｙ）を持っている。
・パケット処理エンジンが中核となるネットワークでリアルタイムＩＰデータ分析情報を提供するリアルタイムの処理能力を持っている。
・ネットワークプロセッサがＲＤＲＡＭ（Ｒａｍｂｕｓ ｄｕａｌ ｒａｔｅ ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）のチャネンルをコントロールするためのコントローラを持っている。
・ネットワークプロセッサが４チャネンルのためのＱＤＲ（Ｑｕａｄ ｄａｔａ ｒａｔｅ）スタティックなランダムアクセスメモリコントローラ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ ｃｏｎｔｒｏｌｌｅｒ）を持っている。
・ネットワークプロセッサの４番目のチャネンルは選択が自由なＴＣＡＭ（Ｔｅｒｎａｒｙ Ｃｏｎｔｅｎｔ Ａｄｄｒｅｓｓａｂｌｅ Ｍｅｍｏｒｙ）プロセッサに付くＱＤＲへ合図する動作を助ける。
・ネットワークプロセッサがスイッチを通して來入するネットワーク内のパケットを常にスニフ（ｓｎｉｆｆ）し、そしてその逆も同様に行う。
・ネットワークプロセッサは媒体とスイッチ構造のインターフェイスを使ってポート（ｐｏｒｔ）に接続する。
・中核となる該エンジンの８／１２のマイクロエンジンとＡＲＭコアエンジンから構成されている。
・ネットワークプロセッサの周波数はオンチップフェーズロックループ（ｏｎ−ｃｈｉｐ Ｐｈａｓｅ ｌｏｃｋ ｌｏｏｐ）によって生成される。
・ＵＡＲＴ（Ｕｎｉｖｅｒｓａｌ Ａｓｙｎｃｈｒｏｎｏｕｓ Ｒｅｃｅｉｖｅｒ Ｔｒａｎｓｍｉｔｔｅｒ）が該パケット処理エンジンのデバッギング（ｄｅｂｕｇｇｉｎｇ）目的と開発のために使用される。
・ネットワークプロセッサはバスインターフェイス（Ｂｕｓ ｉｎｔｅｒｆａｃｅ）を使ってＵＡＲＴに付けられる。
・類似のデータベースが他のアプリケーションプロトコルを使ったセッションのために構築される。
・セッションレベル分析は、ボード（基板）上のメモリが十分ではない場合に自動的にホストメモリを使う。
・ＰＣＩインターフェイスを使ったホスシステムに付けられたセッションレベルアナライザインターフェイスである。
・マイクロエンジンがＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）、ＵＤＰ（Ｕｓｅｒ Ｄａｔａ Ｐｒｏｔｏｃｏｌ）、ＨＴＴＰ （Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、ＳＭＴＰ／ＰＯＰ３（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ／Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐｒｏｔｏｃｏｌ ３） 、ＲＴＰ（Ｒｅａｌ−Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）、ＳＩＰ （Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、Ｈ．３２３ （ｒｅａｌ−ｔｉｍｅ ｖｏｉｃｅ ａｎｄ ｖｉｄｅｏ ｃｏｎｆｅｒｅｎｃｉｎｇ ｏｖｅｒ ｐａｃｋｅｔ ｎｅｔｗｏｒｋｓ）、 ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）、Ｔｅｌｎｅｔ、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ） 、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ） 等のパケットの解析を可能にすることである。
・ネットワークデータトラフィックを監視する方法として、該方法を構成している手順であると言いました、パケットをスニフ（ｓｎｉｆｆ）して、フラグメント（ｆｒａｇｍｅｎｔａｔｉｏｎ）するためにスニフした後のパケットを確認して再び組み立てる、そしてプロトコルのために確認後のパケットを分析する、そしてホストメモリに分析されたパケットを保管する、そして該保管パケットからセッションをつくる、そして分析して、該分析の結果でセッションに分けられる、そして該ホストメモリに分けられたセッションとしてアップロードされる。
・パケット処理を全二重で行う。
・パケットはフラグメントされてそして該パケットの身分を確認する場所を使ってデフラグメント（ｄｅ−ｆｒａｇｍｅｎｔ）される。
・ソースＩＰ（Ｓｏｕｒｃｅ ＩＰ）、デスティネーションＩＰ（Ｄｅｓｔｉｎａｔｉｏｎ ＩＰ）、プロトコルフィールド（Ｐｒｏｔｏｃｏｌ ｆｉｅｌｄ）、データロード（ｄａｔａ ｌｏａｄ）、パケットカウンタ（ｐａｃｋｅｔ ｃｏｕｎｔｅｒ）、パケットサイズ（ｐａｃｋｅｔ ｓｉｚｅ）、タイムスタンプ （ｔｉｍｅ ｓｔａｍｐ）、ソースＭＡＣアドレス（Ｓｏｕｒｃｅ ＭＡＣ Ａｄｄｒｅｓｓ）、デスティネーションＭＡＣアドレス（Ｄｅｓｔｉｎａｔｉｏｎ ＭＡＣ Ａｄｄｒｅｓｓ）、ソースポート（ｓｏｕｒｃｅ ｐｏｒｔ）、デスティネーションポート（ｄｅｓｔｉｎａｔｉｏｎ ｐｏｒｔ）、ＴＣＰコントロールフラグ（ ＴＣＰ ｃｏｎｔｒｏｌ ｆｌａｇｓ）、ＴＣＰタイプサービス（ＴＣＰ ｔｙｐｅ ｏｆ ｓｅｒｖｉｃｅ）を使ってパケットを分析している。
・データベースを更新する、そしてタイムスタンプを付けてホストメモリにアップロードする。
・ホストシステムのメモリは該基板上のメモリあるいは該システムのハードディスクの双方である。
・ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）、ＵＤＰ （Ｕｓｅｒ Ｄａｔａ Ｐｒｏｔｏｃｏｌ）、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、ＳＭＴＰ／ＰＯＰ３（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ／Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐｒｏｔｏｃｏｌ ３）、
ＲＴＰ（Ｒｅａｌ−Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）、ＳＩＰ （Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、Ｈ．３２３（ｒｅａｌ−ｔｉｍｅ ｖｏｉｃｅ ａｎｄ ｖｉｄｅｏ ｃｏｎｆｅｒｅｎｃｉｎｇ ｏｖｅｒ ｐａｃｋｅｔ ｎｅｔｗｏｒｋｓ）、ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）、Ｔｅｌｎｅｔ、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ） 、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）から構成されている群れから選択されたプロトコルに対応したパケットに分ける。
・ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）は、要求方法、ウエッブサイト名、ＵＲＬ、コンテントタイプ（ｃｏｎｔｅｎｔ ｔｙｐｅ）をセッションの開始と終了のタイムスタンプから分けて構成されて抽出された情報とともに分離される。
・ＳＭＴＰ／ＰＯＰ３セッションはユーザー名、パスワード、送られてきた先（ｆｒｏｍ）、送られる先（ｔｏ）、主題、添付ファイル等の抽出された情報と一緒に分けられる。
・“キープアライブ”（ｋｅｅｐ ａｌｉｖｅ）パラメータといっしょにネットワークトラフィックは単一セッションとして処理され、そして多数のセッションは別個のセッションとして扱われる。
・検索、集約、図とテーブルを示すことを助けするためのファイルのインデックスを付けることそしてクエリ／クエリスクリプト／言語の作業を助けるためのファイルのインデックスを付けることを行う。
・セッションは該システムのインデックスファイル（ｉｎｄｅｘ ｆｉｌｅ）とデータファイル（ｄａｔｅ ｆｉｌｅ）と呼ばれる２つの部分で保管される。
・インデックスファイルが固定長レコードで出来ていると言いました、データファイル内のネットワークから入ってきたオリジナルパケットデータ（ｒａｗ ｐａｃｋｅｔ ｄａｔａ）が記録する通信のためのポインターからだけで出来ており、ネットワークから入来するオリジナルパケットデータから出来ているわけではない。
・該データファイルは可変長レコードから出来ている、そして可変長であるネットワークから入来する実際のオリジナルパケットデータを含む。
・上記の処理方法としてプロトコルとセッションレベルと両方のプロトコルにおいてパケット分析を実行する。
・処理方法はコンテントマッチ（ｃｏｎｔｅｎｔ ｍａｔｃｈ）とフィルター基準を基本としたパケットの集合体を提供する。
・処理方法はハードウェアレベルにおいてオンザフライ（ｏｎ ｔｈｅ ｆｌｙ）基準を実施する。本発明の他の具体化は、パケットフラグメント（ｆｒａｇｍｅｎｔ）のデフラグメント（ｄｅ−ｆｒａｇｍｅｎｔ）を実施して再度組み立てられたパケットとしてパケットの分析を行う。
・不完全なセッションは利用可能な範囲で利用して、それぞれのパケットとすべてのパケットが確実に利用できるようにする。
・当該方法はネットワークのトラフィックの起源を追跡する。
・トラフィックの起源はＭＡＣアドレスのソースとセッションの送り先を使って識別される、セッションの開始及び終了時刻、そして一意的タグ（ｕｎｉｑｕｅ ｔａｇ）は処理エンジンとアプリケーション層プロセッサボードに割り当てられた。
・パケットの分析はマイクロエンジンのアーキテクチャによって実行される。
・マイクロエンジンのアーキテクチャに統合されたパイプライン方式の特徴を可能にする。
・パケットの正当性を返すこととコントロールプログラムに対するフラグメント処理はマイクロエンジンによって実施される。
・パケット処理エンジンボード（以降同じくＫＡＭＡＬと称される）は強力な全二重のパケットを処理するエンジンである、インテルのＩＸＰシリーズネットワークプロセッサはネットワークプロトコル分析をするために構成することが出来る、そしてユーザー定義に基づいたフィルター基準に従ってパケットの集合体をつくる、そしてリアルタイム（ｒｅａｌ−ｔｉｍｅ）で１００Ｍｂｐｓあるいは１Ｇｂｐｓまたは１００Ｍｂｐｓと１Ｇｂｐｓの両方のモードでアプリケーション層の分析を行う。
プロトコルレベルとアプリケーションレベルにおいてリアルタイムに起きる、そして該システムは特にネットワークセキュリティのような敏感なアプリケーションと広範囲なＬＡＮ／ＷＡＮ環境を超えたネットワーク上でパケットをスニフ（ｓｎｉｆｆ）することを要求されるネット監視とそれぞれのパケットとすべてのパケットはそれぞれのアプリケーションとすべてのアプリケーションと同じように種々のフィールドに展開することが出来る。
下記に本発明の具体化されたものを列記する。
・ネットワークプロセッサがＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｆａｃｅ）を使って主要システムに付加されたこと。
・ネットワークプロセッサによってＰＣＩのマスターとスレーブの役割を努めるように設定されること。
・パケット処理エンジンはシステムにおけるルックアップテーブル（ｌｏｏｋｕｐ ｔａｂｌｅ）を使い自由に選択することが出来るコンテントアドレサブルメモリ（Ｃｏｎｔｅｎｔ Ａｄｄｒｅｓｓａｂｌｅ Ｍｅｍｏｒｙ）を持っている。
・パケット処理エンジンが中核となるネットワークでリアルタイムＩＰデータ分析情報を提供するリアルタイムの処理能力を持っている。
・ネットワークプロセッサがＲＤＲＡＭ（Ｒａｍｂｕｓ ｄｕａｌ ｒａｔｅ ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）のチャネンルをコントロールするためのコントローラを持っている。
・ネットワークプロセッサが４チャネンルのためのＱＤＲ（Ｑｕａｄ ｄａｔａ ｒａｔｅ）スタティックなランダムアクセスメモリコントローラ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ ｃｏｎｔｒｏｌｌｅｒ）を持っている。
・ネットワークプロセッサの４番目のチャネンルは選択が自由なＴＣＡＭ（Ｔｅｒｎａｒｙ Ｃｏｎｔｅｎｔ Ａｄｄｒｅｓｓａｂｌｅ Ｍｅｍｏｒｙ）プロセッサに付くＱＤＲへ合図する動作を助ける。
・ネットワークプロセッサがスイッチを通して來入するネットワーク内のパケットを常にスニフ（ｓｎｉｆｆ）し、そしてその逆も同様に行う。
・ネットワークプロセッサは媒体とスイッチ構造のインターフェイスを使ってポート（ｐｏｒｔ）に接続する。
・中核となる該エンジンの８／１２のマイクロエンジンとＡＲＭコアエンジンから構成されている。
・ネットワークプロセッサの周波数はオンチップフェーズロックループ（ｏｎ−ｃｈｉｐ Ｐｈａｓｅ ｌｏｃｋ ｌｏｏｐ）によって生成される。
・ＵＡＲＴ（Ｕｎｉｖｅｒｓａｌ Ａｓｙｎｃｈｒｏｎｏｕｓ Ｒｅｃｅｉｖｅｒ Ｔｒａｎｓｍｉｔｔｅｒ）が該パケット処理エンジンのデバッギング（ｄｅｂｕｇｇｉｎｇ）目的と開発のために使用される。
・ネットワークプロセッサはバスインターフェイス（Ｂｕｓ ｉｎｔｅｒｆａｃｅ）を使ってＵＡＲＴに付けられる。
・類似のデータベースが他のアプリケーションプロトコルを使ったセッションのために構築される。
・セッションレベル分析は、ボード（基板）上のメモリが十分ではない場合に自動的にホストメモリを使う。
・ＰＣＩインターフェイスを使ったホスシステムに付けられたセッションレベルアナライザインターフェイスである。
・マイクロエンジンがＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）、ＵＤＰ（Ｕｓｅｒ Ｄａｔａ Ｐｒｏｔｏｃｏｌ）、ＨＴＴＰ （Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、ＳＭＴＰ／ＰＯＰ３（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ／Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐｒｏｔｏｃｏｌ ３） 、ＲＴＰ（Ｒｅａｌ−Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）、ＳＩＰ （Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、Ｈ．３２３ （ｒｅａｌ−ｔｉｍｅ ｖｏｉｃｅ ａｎｄ ｖｉｄｅｏ ｃｏｎｆｅｒｅｎｃｉｎｇ ｏｖｅｒ ｐａｃｋｅｔ ｎｅｔｗｏｒｋｓ）、 ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）、Ｔｅｌｎｅｔ、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ） 、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ） 等のパケットの解析を可能にすることである。
・ネットワークデータトラフィックを監視する方法として、該方法を構成している手順であると言いました、パケットをスニフ（ｓｎｉｆｆ）して、フラグメント（ｆｒａｇｍｅｎｔａｔｉｏｎ）するためにスニフした後のパケットを確認して再び組み立てる、そしてプロトコルのために確認後のパケットを分析する、そしてホストメモリに分析されたパケットを保管する、そして該保管パケットからセッションをつくる、そして分析して、該分析の結果でセッションに分けられる、そして該ホストメモリに分けられたセッションとしてアップロードされる。
・パケット処理を全二重で行う。
・パケットはフラグメントされてそして該パケットの身分を確認する場所を使ってデフラグメント（ｄｅ−ｆｒａｇｍｅｎｔ）される。
・ソースＩＰ（Ｓｏｕｒｃｅ ＩＰ）、デスティネーションＩＰ（Ｄｅｓｔｉｎａｔｉｏｎ ＩＰ）、プロトコルフィールド（Ｐｒｏｔｏｃｏｌ ｆｉｅｌｄ）、データロード（ｄａｔａ ｌｏａｄ）、パケットカウンタ（ｐａｃｋｅｔ ｃｏｕｎｔｅｒ）、パケットサイズ（ｐａｃｋｅｔ ｓｉｚｅ）、タイムスタンプ （ｔｉｍｅ ｓｔａｍｐ）、ソースＭＡＣアドレス（Ｓｏｕｒｃｅ ＭＡＣ Ａｄｄｒｅｓｓ）、デスティネーションＭＡＣアドレス（Ｄｅｓｔｉｎａｔｉｏｎ ＭＡＣ Ａｄｄｒｅｓｓ）、ソースポート（ｓｏｕｒｃｅ ｐｏｒｔ）、デスティネーションポート（ｄｅｓｔｉｎａｔｉｏｎ ｐｏｒｔ）、ＴＣＰコントロールフラグ（ ＴＣＰ ｃｏｎｔｒｏｌ ｆｌａｇｓ）、ＴＣＰタイプサービス（ＴＣＰ ｔｙｐｅ ｏｆ ｓｅｒｖｉｃｅ）を使ってパケットを分析している。
・データベースを更新する、そしてタイムスタンプを付けてホストメモリにアップロードする。
・ホストシステムのメモリは該基板上のメモリあるいは該システムのハードディスクの双方である。
・ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）、ＵＤＰ （Ｕｓｅｒ Ｄａｔａ Ｐｒｏｔｏｃｏｌ）、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、ＳＭＴＰ／ＰＯＰ３（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ／Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐｒｏｔｏｃｏｌ ３）、
ＲＴＰ（Ｒｅａｌ−Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）、ＳＩＰ （Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、Ｈ．３２３（ｒｅａｌ−ｔｉｍｅ ｖｏｉｃｅ ａｎｄ ｖｉｄｅｏ ｃｏｎｆｅｒｅｎｃｉｎｇ ｏｖｅｒ ｐａｃｋｅｔ ｎｅｔｗｏｒｋｓ）、ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）、Ｔｅｌｎｅｔ、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ） 、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）から構成されている群れから選択されたプロトコルに対応したパケットに分ける。
・ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）は、要求方法、ウエッブサイト名、ＵＲＬ、コンテントタイプ（ｃｏｎｔｅｎｔ ｔｙｐｅ）をセッションの開始と終了のタイムスタンプから分けて構成されて抽出された情報とともに分離される。
・ＳＭＴＰ／ＰＯＰ３セッションはユーザー名、パスワード、送られてきた先（ｆｒｏｍ）、送られる先（ｔｏ）、主題、添付ファイル等の抽出された情報と一緒に分けられる。
・“キープアライブ”（ｋｅｅｐ ａｌｉｖｅ）パラメータといっしょにネットワークトラフィックは単一セッションとして処理され、そして多数のセッションは別個のセッションとして扱われる。
・検索、集約、図とテーブルを示すことを助けするためのファイルのインデックスを付けることそしてクエリ／クエリスクリプト／言語の作業を助けるためのファイルのインデックスを付けることを行う。
・セッションは該システムのインデックスファイル（ｉｎｄｅｘ ｆｉｌｅ）とデータファイル（ｄａｔｅ ｆｉｌｅ）と呼ばれる２つの部分で保管される。
・インデックスファイルが固定長レコードで出来ていると言いました、データファイル内のネットワークから入ってきたオリジナルパケットデータ（ｒａｗ ｐａｃｋｅｔ ｄａｔａ）が記録する通信のためのポインターからだけで出来ており、ネットワークから入来するオリジナルパケットデータから出来ているわけではない。
・該データファイルは可変長レコードから出来ている、そして可変長であるネットワークから入来する実際のオリジナルパケットデータを含む。
・上記の処理方法としてプロトコルとセッションレベルと両方のプロトコルにおいてパケット分析を実行する。
・処理方法はコンテントマッチ（ｃｏｎｔｅｎｔ ｍａｔｃｈ）とフィルター基準を基本としたパケットの集合体を提供する。
・処理方法はハードウェアレベルにおいてオンザフライ（ｏｎ ｔｈｅ ｆｌｙ）基準を実施する。本発明の他の具体化は、パケットフラグメント（ｆｒａｇｍｅｎｔ）のデフラグメント（ｄｅ−ｆｒａｇｍｅｎｔ）を実施して再度組み立てられたパケットとしてパケットの分析を行う。
・不完全なセッションは利用可能な範囲で利用して、それぞれのパケットとすべてのパケットが確実に利用できるようにする。
・当該方法はネットワークのトラフィックの起源を追跡する。
・トラフィックの起源はＭＡＣアドレスのソースとセッションの送り先を使って識別される、セッションの開始及び終了時刻、そして一意的タグ（ｕｎｉｑｕｅ ｔａｇ）は処理エンジンとアプリケーション層プロセッサボードに割り当てられた。
・パケットの分析はマイクロエンジンのアーキテクチャによって実行される。
・マイクロエンジンのアーキテクチャに統合されたパイプライン方式の特徴を可能にする。
・パケットの正当性を返すこととコントロールプログラムに対するフラグメント処理はマイクロエンジンによって実施される。
・パケット処理エンジンボード（以降同じくＫＡＭＡＬと称される）は強力な全二重のパケットを処理するエンジンである、インテルのＩＸＰシリーズネットワークプロセッサはネットワークプロトコル分析をするために構成することが出来る、そしてユーザー定義に基づいたフィルター基準に従ってパケットの集合体をつくる、そしてリアルタイム（ｒｅａｌ−ｔｉｍｅ）で１００Ｍｂｐｓあるいは１Ｇｂｐｓまたは１００Ｍｂｐｓと１Ｇｂｐｓの両方のモードでアプリケーション層の分析を行う。
プロトコルレベルとアプリケーションレベルにおいてリアルタイムに起きる、そして該システムは特にネットワークセキュリティのような敏感なアプリケーションと広範囲なＬＡＮ／ＷＡＮ環境を超えたネットワーク上でパケットをスニフ（ｓｎｉｆｆ）することを要求されるネット監視とそれぞれのパケットとすべてのパケットはそれぞれのアプリケーションとすべてのアプリケーションと同じように種々のフィールドに展開することが出来る。
該システムはネットワークに接続する２ギガビットのＰＨＹポート（Ｐｈｙｓｉｃａｌ ｐｏｒｔ）を持っている。該ネットワーク上のトラフィックのすべてのパケットは中核となるエンジンに配達される。該エンジンはインテルのアドバンスドネットワークプロセッサであるＩＸＰ２４００／ＩＸＰ２８００を使って実行される。中核となるエンジンはフラグメントされたパケットとのデフラグメントを行いそしてパケットの解析を行う。該分析データはＰＣＩインターフェイスを使ってパケットとともにホストメモリに保管される。
パケット処理エンジンの特徴
１．１Ｇｂｐｓ までのリアルタイムギガビットネットワークトラフィックをサポートする。 効率的なリソースを使うためにサポートされた最大の稼動スピードは１００Ｍｂｐｓ／１Ｇｂｐｓで実行することが出来る。
２．完全にパケットの再度組み立てを行う。
３．ユーザーによりフィルター基準を定義した該内容と同じ集合体。該フィルター基準はパケット内の正しいパラメータと一致することに基づいている。例えば、ＩＰアドレス、ポート番号等のようにパケット内にあるように。
４．音声、ビデオとオーディオデータのためのペイロードタイプを含む内容分析。
５．ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）の設定範囲： ビットマスキング（ｂｉｔ ｍａｓｋｉｎｇ）をフィルター基準として使用してＩＰの 範囲を指定することが可能である、例えば１９２．１６８．１．６４から１９２．１６８．１．１２７。
６．タイムスタンプ（ｔｉｍｅ ｓｔａｍｐ）：時間−分−秒−ミリセカンド−マイクロセカンドを使ってのそれぞれの ＩＰ パケットのためのタイムスタンプ。
７．プロトコル（ｐｒｏｔｏｃｏｌｓ）− ＫＡＭＡＬは次のプロトコルの解析を可能にする：ＴＣＰ、ＵＤＰ、ＨＴＴＰ、ＳＭＴＰ／ＰＯＰ３、ＲＴＰ、ＳＩＰ、Ｈ．３２３、ＶｏＩＰ、ＩＣＭＰ、Ｔｅｌｎｅｔ、ＦＴＰ 、ＤＮＳ 。
８． ＰＣＩインターフェイスのボード（基板）に対する要求。
９．定義されたフィルターのためにそして、動的にどんなプラットホーム（Ｗｉｎｄｏｗｓ（登録商標）又はＬｉｎｕｘ）上でもコンフィギュレーションパラメータ（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｐａｒａｍｅｔｅｒｓ）のためのＧＵＩインターフェイスの開発用にＣ言語を呼び出すことが可能な機能。
パケット処理エンジンは、強力な全二重で動作するアプリケーションレベルネットワーク処理エンジンである、インテルのＩＸＰシリーズネットワークプロセッサの周りに構築されてそしてリアルタイムで１００Ｍｂｐｓと１Ｇｂｐｓモードの両方あるいは１００Ｍｂｐｓ と１Ｇｂｐｓモードのアプリケーション層の分析が出来る。
パケット処理エンジンの特徴
１．１Ｇｂｐｓ までのリアルタイムギガビットネットワークトラフィックをサポートする。 効率的なリソースを使うためにサポートされた最大の稼動スピードは１００Ｍｂｐｓ／１Ｇｂｐｓで実行することが出来る。
２．完全にパケットの再度組み立てを行う。
３．ユーザーによりフィルター基準を定義した該内容と同じ集合体。該フィルター基準はパケット内の正しいパラメータと一致することに基づいている。例えば、ＩＰアドレス、ポート番号等のようにパケット内にあるように。
４．音声、ビデオとオーディオデータのためのペイロードタイプを含む内容分析。
５．ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）の設定範囲： ビットマスキング（ｂｉｔ ｍａｓｋｉｎｇ）をフィルター基準として使用してＩＰの 範囲を指定することが可能である、例えば１９２．１６８．１．６４から１９２．１６８．１．１２７。
６．タイムスタンプ（ｔｉｍｅ ｓｔａｍｐ）：時間−分−秒−ミリセカンド−マイクロセカンドを使ってのそれぞれの ＩＰ パケットのためのタイムスタンプ。
７．プロトコル（ｐｒｏｔｏｃｏｌｓ）− ＫＡＭＡＬは次のプロトコルの解析を可能にする：ＴＣＰ、ＵＤＰ、ＨＴＴＰ、ＳＭＴＰ／ＰＯＰ３、ＲＴＰ、ＳＩＰ、Ｈ．３２３、ＶｏＩＰ、ＩＣＭＰ、Ｔｅｌｎｅｔ、ＦＴＰ 、ＤＮＳ 。
８． ＰＣＩインターフェイスのボード（基板）に対する要求。
９．定義されたフィルターのためにそして、動的にどんなプラットホーム（Ｗｉｎｄｏｗｓ（登録商標）又はＬｉｎｕｘ）上でもコンフィギュレーションパラメータ（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｐａｒａｍｅｔｅｒｓ）のためのＧＵＩインターフェイスの開発用にＣ言語を呼び出すことが可能な機能。
パケット処理エンジンは、強力な全二重で動作するアプリケーションレベルネットワーク処理エンジンである、インテルのＩＸＰシリーズネットワークプロセッサの周りに構築されてそしてリアルタイムで１００Ｍｂｐｓと１Ｇｂｐｓモードの両方あるいは１００Ｍｂｐｓ と１Ｇｂｐｓモードのアプリケーション層の分析が出来る。
該処理は、プロトコルレベルとアプリケーションレベルにおいてリアルタイムで起きます、該システムは種々の分野で実装することが出来る、特に広範囲なＬＡＮ／ＷＡＮ 環境の向こう側にパケットをスニフ（ｓｎｉｆｆ）することを必要とするネットワークセキュリティとネット監視に対する敏感なアプリケーションのための種々の分野で実装することが出来る。
ＫＡＭＡＬによって該ホストにアップロードされたプロトコルの分析された結果のパケットは該ホストのハードディスクに保管される。該ホストのハードディスクに保管されたパケットはハードディスクからホストによって ＰＣＩインターフェイスを経由してアプリケーション層（ａｐｐｌｉｃａｔｉｏｎ ｌａｙｅｒ）プロセッサ（これ以降同じく ＧＵＬＡＢと称される）ボード（基板）にアップロードされる。
ＧＵＬＡＢは該パケットが属するセッション情報に従ってこれらのパケットをセッションに分ける。分離された該セッションが完全である途端にセッションレベルにおいて組み立てられた該パケットはセッション情報とタイムスタンプ（ｔｉｍｅｓｔａｍｐ）、オリジネター（ｏｒｉｇｉｎａｔｏｒ）とパケットの総数、他とともにホストに戻される。
図１３に示す通りに本発明の機能をネットワークシステムに構築した構成を表する。
図１３にあるように例として、ネットワーク１０を含むローカルエリアネットワーク（ＬＡＮ）２１と２２に複数のパーソナルコンピュータ、ワークステーションと、あるいはサーバーのそれぞれが接続している。ＬＡＮ２２は事実上のＬＡＮを含む。ＬＡＮ２１と２２はスイッチングハブ２５と直接的に接続している（ＬＡＮ２１の場合には）、そしてローカルＨＵＢ２４（ＬＡＮ２２の場合には）に間接的に接続している。ＬＡＮ２１と２２は正当に評価されて、ＬＡＮ２１、２２はスイチングＨＵＢ２５と無線接続されている。スイッチングＨＵＢ２５はＬＡＮ内の機器からはあらゆる非認証されたパーティーには接続ルーター２８を通ってファイアウォール２７に接続することが出来る。ＬＡＮ２１と２２の範囲にあるパーソナルコンピュータと、あるいはワークステーションのユーザーは、インターネットからルーター２８を通って接続出来る能力を持っている。
図１３にあるように例として、ネットワーク１０を含むローカルエリアネットワーク（ＬＡＮ）２１と２２に複数のパーソナルコンピュータ、ワークステーションと、あるいはサーバーのそれぞれが接続している。ＬＡＮ２２は事実上のＬＡＮを含む。ＬＡＮ２１と２２はスイッチングハブ２５と直接的に接続している（ＬＡＮ２１の場合には）、そしてローカルＨＵＢ２４（ＬＡＮ２２の場合には）に間接的に接続している。ＬＡＮ２１と２２は正当に評価されて、ＬＡＮ２１、２２はスイチングＨＵＢ２５と無線接続されている。スイッチングＨＵＢ２５はＬＡＮ内の機器からはあらゆる非認証されたパーティーには接続ルーター２８を通ってファイアウォール２７に接続することが出来る。ＬＡＮ２１と２２の範囲にあるパーソナルコンピュータと、あるいはワークステーションのユーザーは、インターネットからルーター２８を通って接続出来る能力を持っている。
図１３の通りに、ＴＡＰ２６はスイチングＨＵＢ２５とファイアウォール２７との間でネットワーク１０を形成している、そしてネットワーク１０を通してスイッチングＨＵＢ２５とルーター２８との間ですべてのデータが流れている。データはＴＡＰ２６によりいつでも取り込むことができる、該データは具体的な本発明としてサーバー７０内に配置されたＫＡＭＡＬ３０とＧＵＬＡＢ５０に流れる。ＫＡＭＡＬ３０はパケットをスニフしてネットワーク層のプロトコルとアプリケーション層のプロトコル（Ｓ−１）からＭＡＣアドレスとともにパケットデータを取り込む。ＫＡＭＡＬはタイムスタンプとＫＡＭＡＬ自身の持つＫＡＭＡＬである事を証明する情報を付加する。コンテントマッチングの処理後にあるいはもしくは、プロトコル解析、それぞれのプロトコルに対する通信パケットの集合体をホストメモリ４０にアップロードする、たとえばサーバー７０（Ｓ−２）にあるハードディスクのように。パケットの集合体は構成の作法に従ってシーケンシャルにアップロードされる。ＫＡＭＡＬ３０によってアップロードされたパケットの集合体はＧＵＬＡＢ５０（Ｓ−３）にセッション情報とともに組み立てられてダウンロードされる、そして組み立てられたセッションパケットはホストメモリ４０（Ｓ−４）に送られる。具体例によれば、ダウンロードと ＧＵＬＡＢ５０によるアセンプリはパケットの事前に決定された量の後に行なわれてＫＡＭＡＬ３０ によってホストメモリ４０ にアップロードされる。上記の手順を以下に詳細に説明する。
上記の配置の通りにＫＡＭＡＬ３０ とＧＵＬＡＢ５０ が共にプロトコルレベルとアプリケーションレベルにおいてリアルタイムでプロトコルパケットをモニターしてそして、パケットのセッションベースの解析を行なうことによってモニターされたプロトコルパケットを再構築することが出来る。
ＫＡＭＡＬ３０によってパケットとＧＵＬＡＢ５０により再度構成されパケットは図１３に見られる通りに該ホストメモリ４０に保管されるためにアップロードされる、そして該処理は正当に評価されるＫＡＭＡＬ３０により取り込まれたパケットとＧＵＬＡＢ５０ によって再構築されたパケットが サーバー７０でそして／あるいはから供給された異なったホストメモリでアップロードされる（保管）ことが理解される。
セッションアナライザの特徴
１．すべてのセッションの抽出とセッションデータの構築を行うことが出来る。
２．不完全なセッションがそれぞれのパケットとすべてのパケットが確実に実施することが出来るように利用可能な程度に同じくコンパイルされる。
３．ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）は、要求方法、ウエッブサイト名、ＵＲＬ、コンテントタイプ（ｃｏｎｔｅｎｔ ｔｙｐｅ）をセッションの開始と終了のタイムスタンプから分けられて、構成されて抽出された情報とともに分離される。
４．ＰＯＰ３／ＳＭＴＰは、”ｕｓｅｒ ｎａｍｅ” “ｐａｓｓｗｏｒｄ” “ｆｒｏｍ” “ ｔｏ” “ｓｕｂｊｅｃｔ” ａｔｔａｃｈｅｄ ｆｉｌｅ ｎａｍｗ／ｓ”のような情報から組み立てられている。
５． 類似したデータベースはその他のアプリケーションプロトコルのために組み立てられる。
６．“キープアライブ”（Ｋｅｅｐ ａｌｉｖｅ）”と多数のセッションは適切に処理される。
７．ＫＡＭＡＬから抽出されたすべてのパラメータと同じくソースＩＰ（ｓｏｕｒｃｅ ＩＰ）、デスティネーションＩＰ（ｄｅｓｔｉｎａｔｉｏｎ ＩＰ）、ＭＡＣアドレス（ＭＡＣ ａｄｄｒｅｓｓ）、ソースポート（ｓｏｕｒｃｅ ｐｏｒｔ）、デスティネーションポート（ｄｅｓｔｉｎａｔｉｏｎ ｐｏｒｔ）等も有用な情報として抽出されて使用される。
８．検索、ソート、集約、グラフとチャートのテーブルの表示の手助けをするためにファイルにインデックスを付けることを行うそして該インデックスを付けたことが、クエリ／クエリスクリプト／言語等のサポートをする。
イントロダクション
該書類はＫＡＭＡＬハードウェアデザインについて要約したものである。それはＫＡＭＡＬの機能について要約記述を持ったシステム概要とハードウェアブロック図を持っている仕様とソフトウェアフローチャートを含む。
システムの概要
この分野のＫＡＭＡＬと一緒のすべてのシステムは図２で例証される。
ＫＡＭＡＬは２つの独立した１０／１００／１０００ベースＴＡＰ（ｔｅｓｔ ｐｏｉｎｔ）によってネットワークと接続されているそしてそれは順番にトラフィックが分析される必要があるネットワークサブシステムに接続している。ＫＡＭＡＬはイーサネット（登録商標）パケット（Ｅｔｈｅｒｎｅｔ（登録商標） ｐａｃｋｅｔ）を集めてアルゴリズムによりＰＣＩインターフェイスを経由してホストメモリにアップロードされてテーブル内に結果を保管する。ＫＡＭＡＬはＫＡＭＡＬの代わりとなるホスト上でＷｉｎｄｏｗｓ（登録商標）／Ｌｉｎｕｘ ＯＳベースの環境で動作するＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）を使ってコントロールすることが出来る。本発明の目的で、ＫＡＭＡＬはＷｉｎｄｏｗｓ（登録商標）環境でＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）によりコントロールされる。ＫＡＭＡＬはＰＣＩ インターフェイスを使って主装置に付けられるインテルの ＩＸＰ２４００／ＩＸＰ２８００ネットワークプロセッサをベースとしたギガビットネットワークの監視装置である。当該ギガビットネットワークの監視装置は、ルーターから ＬＡＮまでにくるネットワーク内のパケットをスニフして、そして必要条件に従ってトラフィックを分析する。ＫＡＭＡＬの動作はＧＵＩを使って構成することが出来る。すべての集められたデータと解析されたデータはアプリケーションによってあらゆる処理をするために確かなファイル形式にされてＰＣＩインターフェイスを使ってホストメモリにアップロードされる。
システム構成
次のブロック図は仕様を理解するためのシステムのハイレベルの流れを示す。
図３：ＫＡＭＡＬ：機能的なブロック図、
図３で、入来パケットはフラグメントされて、そしてＲＦＣ７９１に従ってデフラグメントされる、デフラグメントされたパケットはパケットのプロトコルフィールド（ｐｒｏｔｏｃｏｌ ｆｉｅｌｄ）とタイムスタンプ（ｔｉｍｅｓｔａｍｐ）を使って分析される。 分析されたデータはホストメモリに保管される。ＫＡＭＡＬのハードウェアを使ってリアルタイムにてデータを分析することが上記同様に可能である。これはＫＡＭＡＬ自身の上に適切なハードウェアを実装することによってＫＡＭＡＬがオンザフライ（ｏｎ ｔｈｅ ｆｌｙ）で入来パケットを監視することを意味する。
システムの機能的なブロック図
ＫＡＭＡＬの高度なレベルでハードウェアを実現していることが図４に示されている。
当該システムはネットワークに接続する中核となるエンジンにパケットを届ける２ギガビットの ＰＨＹポートを持っている。このエンジンはＩＸＰ２４００／ＩＸＰ２８００、インテルからのアドバンスネットワークプロセッサを使って実行される。該中核エンジンはフラグメントされたパケットのデフラグメンテーションとパケットの解析を行う。図４に示すように分析されたデータはホストメモリにパケットとともにＰＣＩインターフェイスを使って保管される。
機能的な要求仕様：
ＫＡＭＡＬのサポートされている特徴
・１００Ｍｂｐｓ／１Ｇｂｐｓ以上の全二重のリアルタイムネットワークトラフィックをサポートしている。
・パケットの完全デフラグメンテーションを行う。
・プロトコルの集合体モジュールを形成している。
・音声、ビデオ、オーディオのためのペイロードタイプ（ＰＡＹＬＯＡＤ ＴＹＰＥ）を持っている内容分析を行う。
・リアルタイム能力：ＫＡＭＡＬは核となるネットワークでリアルタイムＩＰデータ分析情報を提供する。
・オペレーティングシステム：ＲｅｄＨａｔ Ｌｉｎｕｘがはじめにサポーした。Ｓｕｓｅ Ｌｉｎｕｘ 、Ｔｉｍｅｓｙｓ ＯＳのサポートを行う。
・タイムスタンプ：時間−分−秒−ミリセカンド−マイクロセカンドを使ってそれぞれのＩＰパケットのためのタイムスタンプの付加を行う。
・プロトコル：ＫＡＭＡＬは次のプロトコルの分析を可能にしている。
ＫＡＭＡＬ３０によってパケットとＧＵＬＡＢ５０により再度構成されパケットは図１３に見られる通りに該ホストメモリ４０に保管されるためにアップロードされる、そして該処理は正当に評価されるＫＡＭＡＬ３０により取り込まれたパケットとＧＵＬＡＢ５０ によって再構築されたパケットが サーバー７０でそして／あるいはから供給された異なったホストメモリでアップロードされる（保管）ことが理解される。
セッションアナライザの特徴
１．すべてのセッションの抽出とセッションデータの構築を行うことが出来る。
２．不完全なセッションがそれぞれのパケットとすべてのパケットが確実に実施することが出来るように利用可能な程度に同じくコンパイルされる。
３．ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）は、要求方法、ウエッブサイト名、ＵＲＬ、コンテントタイプ（ｃｏｎｔｅｎｔ ｔｙｐｅ）をセッションの開始と終了のタイムスタンプから分けられて、構成されて抽出された情報とともに分離される。
４．ＰＯＰ３／ＳＭＴＰは、”ｕｓｅｒ ｎａｍｅ” “ｐａｓｓｗｏｒｄ” “ｆｒｏｍ” “ ｔｏ” “ｓｕｂｊｅｃｔ” ａｔｔａｃｈｅｄ ｆｉｌｅ ｎａｍｗ／ｓ”のような情報から組み立てられている。
５． 類似したデータベースはその他のアプリケーションプロトコルのために組み立てられる。
６．“キープアライブ”（Ｋｅｅｐ ａｌｉｖｅ）”と多数のセッションは適切に処理される。
７．ＫＡＭＡＬから抽出されたすべてのパラメータと同じくソースＩＰ（ｓｏｕｒｃｅ ＩＰ）、デスティネーションＩＰ（ｄｅｓｔｉｎａｔｉｏｎ ＩＰ）、ＭＡＣアドレス（ＭＡＣ ａｄｄｒｅｓｓ）、ソースポート（ｓｏｕｒｃｅ ｐｏｒｔ）、デスティネーションポート（ｄｅｓｔｉｎａｔｉｏｎ ｐｏｒｔ）等も有用な情報として抽出されて使用される。
８．検索、ソート、集約、グラフとチャートのテーブルの表示の手助けをするためにファイルにインデックスを付けることを行うそして該インデックスを付けたことが、クエリ／クエリスクリプト／言語等のサポートをする。
イントロダクション
該書類はＫＡＭＡＬハードウェアデザインについて要約したものである。それはＫＡＭＡＬの機能について要約記述を持ったシステム概要とハードウェアブロック図を持っている仕様とソフトウェアフローチャートを含む。
システムの概要
この分野のＫＡＭＡＬと一緒のすべてのシステムは図２で例証される。
ＫＡＭＡＬは２つの独立した１０／１００／１０００ベースＴＡＰ（ｔｅｓｔ ｐｏｉｎｔ）によってネットワークと接続されているそしてそれは順番にトラフィックが分析される必要があるネットワークサブシステムに接続している。ＫＡＭＡＬはイーサネット（登録商標）パケット（Ｅｔｈｅｒｎｅｔ（登録商標） ｐａｃｋｅｔ）を集めてアルゴリズムによりＰＣＩインターフェイスを経由してホストメモリにアップロードされてテーブル内に結果を保管する。ＫＡＭＡＬはＫＡＭＡＬの代わりとなるホスト上でＷｉｎｄｏｗｓ（登録商標）／Ｌｉｎｕｘ ＯＳベースの環境で動作するＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）を使ってコントロールすることが出来る。本発明の目的で、ＫＡＭＡＬはＷｉｎｄｏｗｓ（登録商標）環境でＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）によりコントロールされる。ＫＡＭＡＬはＰＣＩ インターフェイスを使って主装置に付けられるインテルの ＩＸＰ２４００／ＩＸＰ２８００ネットワークプロセッサをベースとしたギガビットネットワークの監視装置である。当該ギガビットネットワークの監視装置は、ルーターから ＬＡＮまでにくるネットワーク内のパケットをスニフして、そして必要条件に従ってトラフィックを分析する。ＫＡＭＡＬの動作はＧＵＩを使って構成することが出来る。すべての集められたデータと解析されたデータはアプリケーションによってあらゆる処理をするために確かなファイル形式にされてＰＣＩインターフェイスを使ってホストメモリにアップロードされる。
システム構成
次のブロック図は仕様を理解するためのシステムのハイレベルの流れを示す。
図３：ＫＡＭＡＬ：機能的なブロック図、
図３で、入来パケットはフラグメントされて、そしてＲＦＣ７９１に従ってデフラグメントされる、デフラグメントされたパケットはパケットのプロトコルフィールド（ｐｒｏｔｏｃｏｌ ｆｉｅｌｄ）とタイムスタンプ（ｔｉｍｅｓｔａｍｐ）を使って分析される。 分析されたデータはホストメモリに保管される。ＫＡＭＡＬのハードウェアを使ってリアルタイムにてデータを分析することが上記同様に可能である。これはＫＡＭＡＬ自身の上に適切なハードウェアを実装することによってＫＡＭＡＬがオンザフライ（ｏｎ ｔｈｅ ｆｌｙ）で入来パケットを監視することを意味する。
システムの機能的なブロック図
ＫＡＭＡＬの高度なレベルでハードウェアを実現していることが図４に示されている。
当該システムはネットワークに接続する中核となるエンジンにパケットを届ける２ギガビットの ＰＨＹポートを持っている。このエンジンはＩＸＰ２４００／ＩＸＰ２８００、インテルからのアドバンスネットワークプロセッサを使って実行される。該中核エンジンはフラグメントされたパケットのデフラグメンテーションとパケットの解析を行う。図４に示すように分析されたデータはホストメモリにパケットとともにＰＣＩインターフェイスを使って保管される。
機能的な要求仕様：
ＫＡＭＡＬのサポートされている特徴
・１００Ｍｂｐｓ／１Ｇｂｐｓ以上の全二重のリアルタイムネットワークトラフィックをサポートしている。
・パケットの完全デフラグメンテーションを行う。
・プロトコルの集合体モジュールを形成している。
・音声、ビデオ、オーディオのためのペイロードタイプ（ＰＡＹＬＯＡＤ ＴＹＰＥ）を持っている内容分析を行う。
・リアルタイム能力：ＫＡＭＡＬは核となるネットワークでリアルタイムＩＰデータ分析情報を提供する。
・オペレーティングシステム：ＲｅｄＨａｔ Ｌｉｎｕｘがはじめにサポーした。Ｓｕｓｅ Ｌｉｎｕｘ 、Ｔｉｍｅｓｙｓ ＯＳのサポートを行う。
・タイムスタンプ：時間−分−秒−ミリセカンド−マイクロセカンドを使ってそれぞれのＩＰパケットのためのタイムスタンプの付加を行う。
・プロトコル：ＫＡＭＡＬは次のプロトコルの分析を可能にしている。
・ＴＣＰ
・ＵＤＰ
・ＨＴＴＰ
・ＳＭＴＰ／ＰＯＰ３
・ＲＴＰ
・ＳＩＰ
・Ｈ．３２３
・ＶｏＩＰ
・ＩＣＭＰ
・Ｔｅｌｎｅｔ
・ＦＴＰ
・ＤＮＳ
・ＫＡＭＡＬはＰＣＩの要求に対応している。
・Ｗｉｎｄｏｗｓ（登録商標）あるいはＬｉｎｕｘのようなプラットホームでも動的に定義されたコンフィグレーションパラメータ（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｐａｒａｍｅｔｅｒ）に対してＧＵＩインターフェイス（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）の開発のためにＣ言語が呼び出し可能な機能。
・システムインターフェイス
・ハードウェアインターフェイス
インテルの ＩＸＰ２８００ を使っているＫＡＭＡＬのより詳細なブロック図を図５に示す。該ボード（基板）はＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、フラッシュ（ｆｌａｓｈ）メモリと他のチップのような資産を持っている。該ボードはシステムの開発のためとプロセッサ上のＯＳと同様にソースコードをロードするために同じく１０／１００Ｍｂｐｓ のイーサネット（登録商標）とＵＡＲＴポートを持っている。該ボードはシステムのルックアップテーブルとして使うことができるオプションのＣＡＭ（ｃｏｎｔｅｎｔ ａｄｄｒｅｓｓ ｍｅｍｏｒｙ）を持っている。インテルのＩＸＰ２４００／ＩＸＰ２８００は８／１２のマイクロエンジンと１つのＡＲＭコアを持っている。パケット処理はマイクロエンジンを使って行われる（１ＧＨｚ から２．４ＧＨｚで使用できる可変クロック）。ＡＲＭコアはシステムコントロールのためにＬｉｎｕｘ ＯＳを持ってそして遅いパス機能のために使うことが出来る。インテル ＩＸＰ２４００／ＩＸＰ２８００ネットワークプロセッサは無制限のプログラミングフレキシビリティを提供することによって完全な内容の早い実装を可能にする、そしてコードの再利用と高性能な処理をする。該ネットワークプロセッサはＯＣ−３からＯＣ−１９２までの通常の広範囲で、基板上のスピードの範囲にたいするサポートを必要とする多種多様なＷＡＮとＬＡＮアプリケーションをサポートする。高性能でスケーラブルな革新的なマイクロエンジンアーキテクチャを通してソフトウェアにパイプライン方式の特徴を可能にするマルチ−スレッド（ｍｕｌｔｉ−ｔｈｒｅａｄｅｄ）分配キャシュアーキテクチャによって達成される。利用可能な設定された標準的な特徴のほかにＩＸＰ２４００／ＩＸＰ２８００が２／１０Ｇｂｉｔ／ｓ．で安全なネットワークトラフィックで機能性を統合する。これは安全なネットワーク装置を事前の設計を可能にして、そして電力消費と、ボードの持つ資産とシリコンへの投資に低い全体的なシステムコストをもたらす結果となる。
■１２個の統合化されたマイクロエンジン
・最高１．４ＧＨｚで動作
・マイクロエンジン毎に４つあるいは８つのスレッド（ｔｈｒｅａｄｓ）に構成可能
・マイクロエンジン毎にローカルメモリの６４０のＤｗｏｒｄｓ
・シングルサイクルルックアップを持ったマイクロエンジン毎に１６項目のＣＡＭ
・次の隣のバスが隣接したマイクロエンジンにアクセスする
・マイクロエンジン毎のＣＲＣユニット
・マイクロエンジン毎に８Ｋの命令制御記憶装置
・一般化されたスレドのために合図することをサポート
■統合化されたインテルＸＳｃａｌｅコア
・最高７００ＭＨｚで動作
・高性能なローパワーの３２ｂｉｔエンベデッドＲＩＳＣプロセッサ
・３２Ｋｂｙｔｅ命令キャッシュ
・３２Ｋｂｙｔｅデータキャッシュ
■３つのインダストリアル標準ＲＤＲＡＭインターフェイス
・２．１Ｇｂｙｔｅ／ｓのピークバンド幅
・８００ＭＨｚそして１０６６ＭＨｚ のＲＤＲＡＭ
・エラー訂正コード（ＥＣＣ）
・インテルＸＳｃａｌｅコア、マイクルエンジン、そしてＰＣＩからのアドレスができる
■インダストリアル標準な３２ビットＱＤＲＳＲＡＭインターフェイス用に
・１．９Ｇｂｙｔｅ／チャンネル毎
・最高２３３ＭＨｚまでのＳＲＡＭ
・リンクリストとリングオペレーションに対するハードウェアサポート
・アトミックビットオペレーション
・アトミックアリスマティックをサポート
・ インンテルＸＳｃａｌｅコア、マイクロエンジンそしてＰＣＩからのアドレスできる
■統合化されたメディアスイッチ構造インターフェイス
・ユニダイレクショナル１６ｂｕｉｌｄｓデータインターフェイス
・チャンネル毎に最高５００ＭＨｚ
・ＳＰＩ−４あるいはＣＳＩＸプロトコルのために別に構成可能
■インダストリアル標準ＰＣＩバス
・ＰＣＩローカルバス仕様、６４ｂｉｔ ６６ＭＨｚのＩ／Ｏ用バージョン２．２インターフェイス
■追加の統合化された特徴
・ハードウェアハッシュユニット（４８、６４、と１２８ビット）
・１６Ｋｂｙｔｅのスクラッチパッドメモリ
・デバッギングのためのシルアルＵＡＲＴ ポート
・８本の多目的 Ｉ／Ｏ ピン
・４の３２ｂｉｔタイマー
■１３５６のボールＦＣＢＧＡ パッケージ
・３７．５ｍｍ ｘ ３７．５ｍｍ寸法
・１ｍｍ半田付けボールピッチ
ＩＸＰ２４００／ＩＸＰ２８００オペレーションフリケンシィとＫＡＭＡＬのためのインターフェイスのバス幅はまだ完了されるはずである。
ＲＤＲＡＭ
インテルＩＸＰ２８００ ネットワークプロセッサは３つのＲａｍｂｕｓＤＲＡＭ（ＲＤＲＡＭ）チャネルのためにコントローラを持っている。コントローラのそれぞれが独立してそれ自身のＲＤＲＡＭにアクセスしてそして同時に他のコントローラ（すなわちそれらは１つのより広いメモリとして稼働していません）で動作することが出来る。ＤＲＡＭが高密度の、高いバンド幅ストレッジを供給して、そしてしばしばデータバッファのために使われる。６４、１２８、２５６そして５１２ＭＢのＤＲＡＭサイズ、そして１ＧＢが支援される。しかしながらＫＡＭＡＬはチャネンル毎に最高２５６ＭＢのＲＤＲＡＭを使用するかも知れない。
ＱＲＤＳＲＡＭとＴＣＡＭ
ＩＸＰ２８００が４チャネルのために４つの独立したＳＲＡＭコントローラを持っている。 それぞれのチャネルが最高６４ＭｂｙｔｅのＳＲＡＭをサポートする。イングレスネットワークプロセッサの４番目のチャネルは同じく合図してＱＤＲに付着するオプションのターナリコンテントアドレスメモリ（Ｔｅｒｎａｒｙ Ｃｏｎｔｅｎｔ Ａｄｄｒｅｓｓ Ｍｅｍｏｒｙ）コプロセッサをサポートする。 もしアプリケーションがそれらを使う必要がないならどれかあるいはすべてのコントローラがそこに居ることがないままにしておくことが出来る。ＳＲＡＭはマイクロエンジン、インテルＸＳｃａｌｅコアとＰＣＩユニット（外部のバスマスタとＤＭＡ）によりアクセス可能である。
フラッシュメモリシステムで使われたフラッシュメモリはＩＸＰ２４００／ＩＸＰ２８００ の遅いポートを利用する。遅いポートは８ｂｉｔ非同期データバス以外の何ものでもない。フラッシュメモリは１６ＭＢサイズであろう。
ＰＣＩ インターフェイス
ＰＣＩコントローラは６４ｂｉｔ、６６ＭＨｚ有能なＰＣＩローカルバス仕様、インテルＩＸＰ２４００／ＩＸＰ２８００へのバージョン２．２のインターフェイスを提供する。 それは３２ｂｉｔの、そして／あるいは３３ＭＨｚ の ＰＣＩコントロ−ラに同じく互換性がある。 ＰＣＩコントローラは次の機能を提供する：
・目標アクセス（ＳＲＡＭ、ＤＲＡＭとＣＳＲｓへの外部バスマスターアクセス）
・マスターアクセス（マイクロエンジンがＰＣＩターゲットデバイスのアクセスをするかあるいはインテルＸＳｃａｌｅ コア）
・２ ＤＭＡチャネッル
・ＰＣＩ 調停者
ネットワークプロセッサはそれが ＰＣＩ リセットシグナルを提供するところあるいはＡＤＤ−Ｉｎ装置としてそれが ＰＣＩリセットシグナルをチップリセットとして使用するＰＣＩの中心的な機能（独立したシステムとして使うために）の役を務めるように設定することが出来る。
ＰＨＹインターフェイス
図５に示されるようにメディアとスイッチ構成（ＭＳＦ）インターフェイスはインテルＩＸＰ２４００／ＩＸＰ２８００ネットワークプロセッサを物理層装置（ＰＨＹ）と接続する。
ＵＡＲＴと１０／１００Ｍｂｐｓのイーサネット（登録商標）
これらのインターフェイスは開発段階にフィールドオペレーション上と同様にＫＡＭＡＬの開発とデバッギング目的の用途で使用出来る。 ＵＡＲＴはＲＳ−２３２標準。
クロックモジュール
ＩＸＰ２４００／ＩＸＰ２８００ネットワークプロセッサに関する速い周波数は選択可能な乗数によってリファレンス周波数を増やすＰＬＬ がボード（基板）上のＬＶＤＳ 発振器によって提供した ｏｎ−ｃｈｉｐ（周波数１００ＭＨｚ）によって生成される。 乗数限界は１６と４８の間の倍数である、それで ＰＬＬ は（１００ＭＨｚの参考周波数で）１．６ＧＨｚ から４．８ＧＨｚのクロックを生成することが出来る。
パワーモジュール
パワーモジュールがホストシステムからＰＣＩバスから３．３ｖのリファレンスパワーをとるそして適当なパワーコンバーターとレギレータをシステムに異なったモジュールとチップセットのための異なった電圧のセットを得るために使用する。
ソフトウェアインターフェイス
図６に示されるようにソフトウェアスタック（ｓｏｆｔｗａｒｅ ｓｔａｃｋ）はマイクロエンジンを通して入ってくるイーサネット（登録商標）フレームを処理する。すべてのパケット処理と分析は同じくマイクロエンジンによって実施される。ＩＸＰ２４００／ＩＸＰ２８００（ＡＲＭプロセッサ）コアは組み込みがたＬｉｎｕｘ ＯＳを持っている。これは全部のインターフェイスと入出力関連のタスクとそれらのデバイス・ドライバを処理する。ＯＳは同じくホストインターフェイスとＧＵＩ関連のタスクを処理する。パケットがプロセッサに入って来る途端にそれは分解されるかあるいは、必要とされるようにデフラグメントされてマイクロエンジンにおいて分析されてそして次にＸＳｃａｌｅコアに転送される。ＸＳｃａｌｅはホストメモリにＰＣＩインターフェイスを経由してすべての適切なデータを転送してそして保管する。図７に示すＫＡＭＡＬのための基本的なソフトウェアフローチャート。
基本的なアルゴリズム：
１．ネットワークインターフェイスからパケットを取り込むためにパケットをスニフ（ｓｎｉｆｆ）する。
２．フラグメンテーションビト（ｆｒａｇｍｅｎｔａｔｉｏｎ ｂｉｔ）の部分を調べる。 もし調べて該フラグメンテーションビトがセットされることが出来るならすべてのフラグメントされたパケットを集めて、該システム内の身元確認場所を使ってデフラグメントする。 それから第４番目ステップに進む。
３．もしデフラグメントビット（ｆｒａｇｍｅｎｔａｔｉｏｎ ｂｉｔ）が設定されなければ第４番目ステップに進む。
４．ソース ＩＰ（ｓｏｕｒｃｅ ＩＰ） 、デスティネーションＩＰ（ｄｅｓｔｉｎａｔｉｏｎ ＩＰ） プロトコルフィールド（ｐｒｏｔｏｃｏｌ ｆｉｅｌｄ）、データロード（ｄａｔａ ｌｏａｄ）を使っているパケットを分析する。
５．データベースを更新してタイムスタンプを付けてホストシステムメモリに更新したデータベースをアップロードして、そして同じくパケットを該ホストメモリに保管する。
アップロードする必要が示されたファイルのマトリックス、
・ＵＤＰ
・ＨＴＴＰ
・ＳＭＴＰ／ＰＯＰ３
・ＲＴＰ
・ＳＩＰ
・Ｈ．３２３
・ＶｏＩＰ
・ＩＣＭＰ
・Ｔｅｌｎｅｔ
・ＦＴＰ
・ＤＮＳ
・ＫＡＭＡＬはＰＣＩの要求に対応している。
・Ｗｉｎｄｏｗｓ（登録商標）あるいはＬｉｎｕｘのようなプラットホームでも動的に定義されたコンフィグレーションパラメータ（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｐａｒａｍｅｔｅｒ）に対してＧＵＩインターフェイス（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）の開発のためにＣ言語が呼び出し可能な機能。
・システムインターフェイス
・ハードウェアインターフェイス
インテルの ＩＸＰ２８００ を使っているＫＡＭＡＬのより詳細なブロック図を図５に示す。該ボード（基板）はＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、フラッシュ（ｆｌａｓｈ）メモリと他のチップのような資産を持っている。該ボードはシステムの開発のためとプロセッサ上のＯＳと同様にソースコードをロードするために同じく１０／１００Ｍｂｐｓ のイーサネット（登録商標）とＵＡＲＴポートを持っている。該ボードはシステムのルックアップテーブルとして使うことができるオプションのＣＡＭ（ｃｏｎｔｅｎｔ ａｄｄｒｅｓｓ ｍｅｍｏｒｙ）を持っている。インテルのＩＸＰ２４００／ＩＸＰ２８００は８／１２のマイクロエンジンと１つのＡＲＭコアを持っている。パケット処理はマイクロエンジンを使って行われる（１ＧＨｚ から２．４ＧＨｚで使用できる可変クロック）。ＡＲＭコアはシステムコントロールのためにＬｉｎｕｘ ＯＳを持ってそして遅いパス機能のために使うことが出来る。インテル ＩＸＰ２４００／ＩＸＰ２８００ネットワークプロセッサは無制限のプログラミングフレキシビリティを提供することによって完全な内容の早い実装を可能にする、そしてコードの再利用と高性能な処理をする。該ネットワークプロセッサはＯＣ−３からＯＣ−１９２までの通常の広範囲で、基板上のスピードの範囲にたいするサポートを必要とする多種多様なＷＡＮとＬＡＮアプリケーションをサポートする。高性能でスケーラブルな革新的なマイクロエンジンアーキテクチャを通してソフトウェアにパイプライン方式の特徴を可能にするマルチ−スレッド（ｍｕｌｔｉ−ｔｈｒｅａｄｅｄ）分配キャシュアーキテクチャによって達成される。利用可能な設定された標準的な特徴のほかにＩＸＰ２４００／ＩＸＰ２８００が２／１０Ｇｂｉｔ／ｓ．で安全なネットワークトラフィックで機能性を統合する。これは安全なネットワーク装置を事前の設計を可能にして、そして電力消費と、ボードの持つ資産とシリコンへの投資に低い全体的なシステムコストをもたらす結果となる。
■１２個の統合化されたマイクロエンジン
・最高１．４ＧＨｚで動作
・マイクロエンジン毎に４つあるいは８つのスレッド（ｔｈｒｅａｄｓ）に構成可能
・マイクロエンジン毎にローカルメモリの６４０のＤｗｏｒｄｓ
・シングルサイクルルックアップを持ったマイクロエンジン毎に１６項目のＣＡＭ
・次の隣のバスが隣接したマイクロエンジンにアクセスする
・マイクロエンジン毎のＣＲＣユニット
・マイクロエンジン毎に８Ｋの命令制御記憶装置
・一般化されたスレドのために合図することをサポート
■統合化されたインテルＸＳｃａｌｅコア
・最高７００ＭＨｚで動作
・高性能なローパワーの３２ｂｉｔエンベデッドＲＩＳＣプロセッサ
・３２Ｋｂｙｔｅ命令キャッシュ
・３２Ｋｂｙｔｅデータキャッシュ
■３つのインダストリアル標準ＲＤＲＡＭインターフェイス
・２．１Ｇｂｙｔｅ／ｓのピークバンド幅
・８００ＭＨｚそして１０６６ＭＨｚ のＲＤＲＡＭ
・エラー訂正コード（ＥＣＣ）
・インテルＸＳｃａｌｅコア、マイクルエンジン、そしてＰＣＩからのアドレスができる
■インダストリアル標準な３２ビットＱＤＲＳＲＡＭインターフェイス用に
・１．９Ｇｂｙｔｅ／チャンネル毎
・最高２３３ＭＨｚまでのＳＲＡＭ
・リンクリストとリングオペレーションに対するハードウェアサポート
・アトミックビットオペレーション
・アトミックアリスマティックをサポート
・ インンテルＸＳｃａｌｅコア、マイクロエンジンそしてＰＣＩからのアドレスできる
■統合化されたメディアスイッチ構造インターフェイス
・ユニダイレクショナル１６ｂｕｉｌｄｓデータインターフェイス
・チャンネル毎に最高５００ＭＨｚ
・ＳＰＩ−４あるいはＣＳＩＸプロトコルのために別に構成可能
■インダストリアル標準ＰＣＩバス
・ＰＣＩローカルバス仕様、６４ｂｉｔ ６６ＭＨｚのＩ／Ｏ用バージョン２．２インターフェイス
■追加の統合化された特徴
・ハードウェアハッシュユニット（４８、６４、と１２８ビット）
・１６Ｋｂｙｔｅのスクラッチパッドメモリ
・デバッギングのためのシルアルＵＡＲＴ ポート
・８本の多目的 Ｉ／Ｏ ピン
・４の３２ｂｉｔタイマー
■１３５６のボールＦＣＢＧＡ パッケージ
・３７．５ｍｍ ｘ ３７．５ｍｍ寸法
・１ｍｍ半田付けボールピッチ
ＩＸＰ２４００／ＩＸＰ２８００オペレーションフリケンシィとＫＡＭＡＬのためのインターフェイスのバス幅はまだ完了されるはずである。
ＲＤＲＡＭ
インテルＩＸＰ２８００ ネットワークプロセッサは３つのＲａｍｂｕｓＤＲＡＭ（ＲＤＲＡＭ）チャネルのためにコントローラを持っている。コントローラのそれぞれが独立してそれ自身のＲＤＲＡＭにアクセスしてそして同時に他のコントローラ（すなわちそれらは１つのより広いメモリとして稼働していません）で動作することが出来る。ＤＲＡＭが高密度の、高いバンド幅ストレッジを供給して、そしてしばしばデータバッファのために使われる。６４、１２８、２５６そして５１２ＭＢのＤＲＡＭサイズ、そして１ＧＢが支援される。しかしながらＫＡＭＡＬはチャネンル毎に最高２５６ＭＢのＲＤＲＡＭを使用するかも知れない。
ＱＲＤＳＲＡＭとＴＣＡＭ
ＩＸＰ２８００が４チャネルのために４つの独立したＳＲＡＭコントローラを持っている。 それぞれのチャネルが最高６４ＭｂｙｔｅのＳＲＡＭをサポートする。イングレスネットワークプロセッサの４番目のチャネルは同じく合図してＱＤＲに付着するオプションのターナリコンテントアドレスメモリ（Ｔｅｒｎａｒｙ Ｃｏｎｔｅｎｔ Ａｄｄｒｅｓｓ Ｍｅｍｏｒｙ）コプロセッサをサポートする。 もしアプリケーションがそれらを使う必要がないならどれかあるいはすべてのコントローラがそこに居ることがないままにしておくことが出来る。ＳＲＡＭはマイクロエンジン、インテルＸＳｃａｌｅコアとＰＣＩユニット（外部のバスマスタとＤＭＡ）によりアクセス可能である。
フラッシュメモリシステムで使われたフラッシュメモリはＩＸＰ２４００／ＩＸＰ２８００ の遅いポートを利用する。遅いポートは８ｂｉｔ非同期データバス以外の何ものでもない。フラッシュメモリは１６ＭＢサイズであろう。
ＰＣＩ インターフェイス
ＰＣＩコントローラは６４ｂｉｔ、６６ＭＨｚ有能なＰＣＩローカルバス仕様、インテルＩＸＰ２４００／ＩＸＰ２８００へのバージョン２．２のインターフェイスを提供する。 それは３２ｂｉｔの、そして／あるいは３３ＭＨｚ の ＰＣＩコントロ−ラに同じく互換性がある。 ＰＣＩコントローラは次の機能を提供する：
・目標アクセス（ＳＲＡＭ、ＤＲＡＭとＣＳＲｓへの外部バスマスターアクセス）
・マスターアクセス（マイクロエンジンがＰＣＩターゲットデバイスのアクセスをするかあるいはインテルＸＳｃａｌｅ コア）
・２ ＤＭＡチャネッル
・ＰＣＩ 調停者
ネットワークプロセッサはそれが ＰＣＩ リセットシグナルを提供するところあるいはＡＤＤ−Ｉｎ装置としてそれが ＰＣＩリセットシグナルをチップリセットとして使用するＰＣＩの中心的な機能（独立したシステムとして使うために）の役を務めるように設定することが出来る。
ＰＨＹインターフェイス
図５に示されるようにメディアとスイッチ構成（ＭＳＦ）インターフェイスはインテルＩＸＰ２４００／ＩＸＰ２８００ネットワークプロセッサを物理層装置（ＰＨＹ）と接続する。
ＵＡＲＴと１０／１００Ｍｂｐｓのイーサネット（登録商標）
これらのインターフェイスは開発段階にフィールドオペレーション上と同様にＫＡＭＡＬの開発とデバッギング目的の用途で使用出来る。 ＵＡＲＴはＲＳ−２３２標準。
クロックモジュール
ＩＸＰ２４００／ＩＸＰ２８００ネットワークプロセッサに関する速い周波数は選択可能な乗数によってリファレンス周波数を増やすＰＬＬ がボード（基板）上のＬＶＤＳ 発振器によって提供した ｏｎ−ｃｈｉｐ（周波数１００ＭＨｚ）によって生成される。 乗数限界は１６と４８の間の倍数である、それで ＰＬＬ は（１００ＭＨｚの参考周波数で）１．６ＧＨｚ から４．８ＧＨｚのクロックを生成することが出来る。
パワーモジュール
パワーモジュールがホストシステムからＰＣＩバスから３．３ｖのリファレンスパワーをとるそして適当なパワーコンバーターとレギレータをシステムに異なったモジュールとチップセットのための異なった電圧のセットを得るために使用する。
ソフトウェアインターフェイス
図６に示されるようにソフトウェアスタック（ｓｏｆｔｗａｒｅ ｓｔａｃｋ）はマイクロエンジンを通して入ってくるイーサネット（登録商標）フレームを処理する。すべてのパケット処理と分析は同じくマイクロエンジンによって実施される。ＩＸＰ２４００／ＩＸＰ２８００（ＡＲＭプロセッサ）コアは組み込みがたＬｉｎｕｘ ＯＳを持っている。これは全部のインターフェイスと入出力関連のタスクとそれらのデバイス・ドライバを処理する。ＯＳは同じくホストインターフェイスとＧＵＩ関連のタスクを処理する。パケットがプロセッサに入って来る途端にそれは分解されるかあるいは、必要とされるようにデフラグメントされてマイクロエンジンにおいて分析されてそして次にＸＳｃａｌｅコアに転送される。ＸＳｃａｌｅはホストメモリにＰＣＩインターフェイスを経由してすべての適切なデータを転送してそして保管する。図７に示すＫＡＭＡＬのための基本的なソフトウェアフローチャート。
基本的なアルゴリズム：
１．ネットワークインターフェイスからパケットを取り込むためにパケットをスニフ（ｓｎｉｆｆ）する。
２．フラグメンテーションビト（ｆｒａｇｍｅｎｔａｔｉｏｎ ｂｉｔ）の部分を調べる。 もし調べて該フラグメンテーションビトがセットされることが出来るならすべてのフラグメントされたパケットを集めて、該システム内の身元確認場所を使ってデフラグメントする。 それから第４番目ステップに進む。
３．もしデフラグメントビット（ｆｒａｇｍｅｎｔａｔｉｏｎ ｂｉｔ）が設定されなければ第４番目ステップに進む。
４．ソース ＩＰ（ｓｏｕｒｃｅ ＩＰ） 、デスティネーションＩＰ（ｄｅｓｔｉｎａｔｉｏｎ ＩＰ） プロトコルフィールド（ｐｒｏｔｏｃｏｌ ｆｉｅｌｄ）、データロード（ｄａｔａ ｌｏａｄ）を使っているパケットを分析する。
５．データベースを更新してタイムスタンプを付けてホストシステムメモリに更新したデータベースをアップロードして、そして同じくパケットを該ホストメモリに保管する。
アップロードする必要が示されたファイルのマトリックス、
上記のマトリックスはどんな入力ででも増すことができＩＰパケットのどんなフィールドにでも属する。
例えば、
・ソースポート（ｓｏｕｒｃｅ ｐｏｒｔ）、デスティネーションポート（ｄｅｓｔｉｎａｔｉｏｎ ｐｏｒｔ）
・ＴＴＬ（ｔｉｍｅ ｔｏ ｌｉｖｅ）
・データ長（ｄａｔａ ｌｅｎｇｔｈ）、等。
ＧＵＬＡＢ
イントロダクション
ＧＵＬＡＢはホストシステムとコミュニケーションをするためにＰＣＩインターフェイスを利用するためのボードとして付加された。ＧＵＬＡＢはＫＡＭＡＬによって処理された後に（例えばホストシステムのメモリ／ハードディスク装置で）ホストシステムに保管されたパケットを受け入れる、そしてパケットのセッションベースの分析を行う。セッションに従ってパケットを分ける、特定のセッションに属するすべてのパケットを編集した後に該パケットはこれらのセッションのそれぞれに分けられてホストにアップロードする。フィールドのシステムは図８に示す。
ＲＤＲＡＭメモリマネージメント
ＧＵＬＡＢはオプションとして最高３ＧＢまでのボード上のメモリを持っている。図９に示すようＲＡＭは配置されるべきである。当該ボード上のメモリの内で最初の１２８ＭＢメモリはオペーレションシステム、ソフトウェア、スクラッチデータ等のために利用されるであろう、どのユーザーがアクセスを持たないであろうかにかかわらず。当該基板上のメモリの内で残っている２９４４ＭＢは種々のセッションの間に配置される。セッションの数とそれぞれのセッションに割り当てられたメモリはユーザーから入力されるそしてセッションベースの分析のための ＲＤＲＡＭ はそれに応じて分割されるであろう。
ＧＵＬＡＢ のオペレーション
ＰＣＩインターフェイスのみを持っているホストシステムへの ＧＵＬＡＢのインターフェイス。 オリジナルパケット（ｒａｗ ｐａｃｋｅｔ）がこのＰＣＩインターフェイスを経由してホストから ＧＵＬＡＢに送られる。
ＧＵＬＡＢはセッションに基づいてこれらのパケットを分けてＰＣＩインターフェイスを経由してホストに戻って分離したパケットデータを書く。１つのシナリオは、ＫＡＭＡＬによってホストにアップロードされたプロトコルによって分析されたパケットは、ホストのハードディスクに保管される。保管された該パケットはハードディスクからホストによってＰＣＩインターフェイスを経由してＧＵＬＡＢにアップロードされる。ＧＵＬＡＢは該パケットが属するセッションに従ってこれらのパケットを分ける。セッションが完全である途端に上記のパケットはセッションレベルにおいて組み立てられたこれらすべてのパケットはタイムスタンプ、オリジネータとパケットカウンタ他のようなセッション情報とともにホストにアップロードされる。 例が下図１０に示す。
概要背景
ＫＡＭＡＬはギガビットレベルの全二重のパケット処理エンジンである。ＧＵＬＡＢは典型的にＫＡＭＡＬの出力を使うセッションレベル分析器である。ＫＡＭＡＬはＫＡＭＡＬとＧＵＬＡＢに変形したものである。
ＫＡＭＡＬ１：プロトコルレベルの分析を行う。
ＫＡＭＡＬ２：フィルター基準とコンテントマッチ（ｃｏｎｔｅｎｔ ｍａｔｃｈ）に基づいて集合体をつくる。
ＫＡＭＡＬ １
概観
図１はパケット処理エンジンソフトウェアの典型的なシナリオを示す。
ソフトウェアの主な部品：
１．ボード上のアプリケーションソフトウェア
ａ．ネットワークインターフェイス
ｉ．ＭＡＣ初期化
ｉｉ．ＵＡＲＴ初期化
ｉｉｉ．ＭＡＣのための動的な構成（もしあるとしたら）
ｂ．パケットプロセッサ
ｉ．ＩＰパケットの立証（ＩＰｖ４のための）
ｉｉ．フラグメントの立証
ｉｉｉ． パケットの再組み立て
ｉｖ． プロトコルの分析
ｖ． テーブルを形成する
ｃ．メモリインターフェイス
ｉ． ＲＤＲＡＭメモリマネジャ
ｉｉ．ＳＲＡＭメモリマネジャ
ｄ．ホストインターフェイ
ｉ． 構成
ｉｉ． パケットのダウンロード
ｉｉｉ． テーブルのダウンロード
ｅ．デバッグモニターインターフェイス（ｄｅｂｕｇ ｍｏｎｉｔｏｒ ｉｎｔｅｒｆａｃｅ）（もし利用可能であれば）
２．ホストソフトウェア
ａ．ＰＣＩデバイス・ドライバー
ｉ．ＫＡＭＡＬを見つける
ｉｉ． 初期化
ｉｉｉ． システムの日時設定
ｉｖ．Ｔｉｍｅ ｔｏ ｌｉｖｅ設定
ｖ． テーブルダウンロードの間隔の設定
ｖｉ．タグを読む
ｖｉｉ．パケットを読む
ｂ．ソケット・インターフェイス
ｉ．ソケットを作る
ｉｉ．束ねる
ｉｉｉ．聴き取る
ｉｖ． 受け入れる
ｖ． 読み取る
ｖｉ． 書き取る
正しいネットワークフォーマット（ｂｉｇ ｅｎｄｉａｎ）。 絶対的に必要とされないなら変換を避けてコーディングスタンダード命名法で必ず区別する。（例えば、すべての小さいエンディアンは ｌｅ＿ｘｘｘ 名を持つことが出来る）。
マイクロエンジンの並列処理性能を利用する
ＰＣＩ：ＰＣＩ の取り扱いは低いレベルで使われるべきである。モジュールは最適化された方法のマルチチャンネルＤＭＡ転送、マスターモードデータ転送、割り込みの取り扱いと基本的なデータ転送を含む。
Ｌｉｎｕｘのエンタープライズ版：ＰＣＩドライバとＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ） ライブラリモジュールはＬｉｎｕｘ ＯＳの３２と６４ｂｉｔバージュンが使用出来る。
ＩＸＰ２４００／ＩＸＰ２８００チップ上にＬｉｎｕｘ ＯＳをポーティングする。
Ｉｘｆ１１０４ＭＡＣのためのデバイス・ドライバ
ＭＡＣプログラミング
ｉｄｔｔ用のデバイス・ドライバ
ＴＣＡＭプログラミング
チップ上のＰＣＩのためのデバイス・ドライバ
ボード上とホストのコミュニケーション
來入するパケットのＩＸＰ２４００／ＩＸＰ２８００マイクロエンジンレベルでの取り扱い
マイクロエンジンレベルでのＰＣＩの取り扱い
マイクロエンジンレベルでのメモリインターフェイスの取り扱い
オンチップメモリにリソース割り当てを行うためのメモリマネージャ（異なったモジュールからの多数のメモリの同時の接続要求の取り扱い）
マルチスレッド（ｍｕｌｔｉ−ｔｈｒｅａｄｉｎｇ）の使用法、プロセスの同期化、ＸＳＣＡＬアーキテクチャとマイクロエンジンの力を利用するためのＩＸＰ２４００／ＩＸＰ２８００チッププログラミング。
パケットプロセッサ
ｖｉｉ． ＩＰパケッとの立証：
上記のルーチンは最初のマイクロエンジン（ＭＥ１．）上で動作する。パケットあるいはフラグメントが受け取られるときは、順番に当該機能を呼び出すｉｘｐ を中断させます。ＩＰパケットヘッダはＩＰｖ４パケットであるかを調べるために検証する。 当該ステータスは主のＡＲＭプロセッサに送られる。
ｖｉｉｉ． フラグメントの立証：
フラグメントビット（ｆｒａｇｍｅｎｔ ｂｉｔ）が設定されるか確かめる。 確かめた後に、その状況に応じてメモリマネージャに該ステータスを通知する、プロトコル分析、パケット記憶装置とホストへの転送がＩＸＰ２４００／ＩＸＰ２８００プロセッサの内部で行われなければならない。
ＫＡＭＡＬハードウェアを使ってネットワークの監視をするハードウェアソリューション。それ故に、ＫＡＭＡＬは平行してＩＸＰ２４００／ＩＸＰ２８００チップの他の特別な特徴を利用してハードウェアソリューションとして構築される必要がある。
多くのプロセスが真の平行したアーキテクチャ上で動作して共通のリソースを共有しなければならないのでＫＡＭＡＬの発明は一層のハードウェア（ＶＨＤＬ又はＶｅｒｉｌｏｇ−ＨＤＬプラットホーム上で開発する）の解決となる。
ここで示すパケット取り扱いのフロント−エンドとＰＣＩドライバは典型的な例である。伝統的に通話の定められた手順がプロトコルを分析するために順番に定められた手順を呼び出すことができるように、我々はｓｏｆからｅｏｆまで、そして次に「リターン」から「呼び出し手順」まで１つのパケットを集めるためのソフトウェアを開発することが出来る。しかしながら、当該ハードウェアソリューションとしては、我々がすべての入ってくるｑｕａｄ−ｏｃｔｅｔｓは調べる必要がある、そして次のｑｕａｄ−ｏｃｔｅｔｓが到着する前に決断しなければならない。当該手順がＰＣＩインターフェイスを持った場合に行なわれる手順である。すべてのＫＡＭＡＬの発明はＫＡＭＡＬがハードウェアプラットホームであると同様に開発を行なうべきである。ソフトウェアで該システムを開発する場合はプログラミングを行なう容易さの範囲にだけでは有効であるが。
それぞれのマイクロエンジンは図１１に示されるように事前割り当てされたアプリケーションプロトコルを調べる、そしてアプリケーションに関係する抽出されたパラメータは該プロトコルを使って、該コントロールプログラムの結果を該マイクロエンジンに報告する。すべてのモジュールが誤った（ｆｌａｓｈ）値を返す場合と、あるいは真（ｔｒｕｅ）を返す場合がある、真を返したモジュールが真である。もう１つのマイクロエンジン（ＭＥ１．）が今までにフラグメントステイタスとパケットの正当性を返している。 データの一部が構造化するように該アプリケーションにとって特殊であって抽出されるパラメータは下記に文書化される。
ＫＡＭＡＬデータアップロードフォーマット
ＫＡＭＡＬデータアップロードフォーマット
／＊ ＫＡＭＡＬ ＳＴＲＵＣＴＵＲＥＳ ＊／
ｓｔｒｕｃｔ ＫＡＭＡＬ＿ＦＩＸＥＤ＿ＨＥＡＤＥＲ＿ＦＯＲＭＡＴ
｛
ｕｎｓｉｇｎｅｄ ｃｈａｒ ＫＡＭＡＬ＿ＩＤ＿ＳＴＲＩＮＧ［５］；
上記が示す当該ボードの認識。常に ＫＡＭＡＬのための文字列には“ＫＡＭＡＬ”を含んでいる。ＧＵＬＡＢのためには“ＧＵＬＡＢ”を含んでいる。
ｕｎｓｉｇｎｅｄ ｃｈａｒ ＫＡＭＡＬ＿ＶＥＲＳＩＯＮ＿ＳＴＲＩＮＧ［２］；
上記が示すＫＡＭＡＬバージョン番号。 最新バーションは００番号である。
ｕｎｓｉｇｎｅｄ ｃｈａｒ ＫＡＭＡＬ＿ＲＥＬＥＡＳＥ＿ＳＴＲＩＮＧ［２］；
上記が示すＫＡＭＡＬリリース番号： 最新版は０．９番です（バージョン０．９）
ｕｎｓｉｇｎｅｄ ｃｈａｒ ＫＡＭＡＬ＿ＰＫＴ＿ＴＹＰＥ＿ＩＤＥＮＴＩＦＩＥＲ；
上記が示すレコードタイプ 、
０ ＝ レコードはプロトコル解析テーブル列（ぴったりあった列）
１＝ レコードはオリジナルパケットデータ（レイヤーＩＩ）
ｕｎｓｉｇｎｅｄ ｓｈｏｒｔ ｔｏｔａｌ＿ｌｅｎｇｔｈ；
上記が示すレコードの全長、
ぴったりあった列レコードのために：
レコードヘッダのサイズ（２８） ＋ ぴったりあった列のサイズ（１５２） ＝１８０
オリジナルパケットデータレコードのために：
レコードヘッダのサイズ（２８ ）＋ レイヤＩＩオリジナルパケットデータ変数＝ 変数
ｕｎｓｉｇｎｅｄ ｌｏｎｇ ＫＡＭＡＬ＿ＢＯＡＲＤ＿ＴＡＧ；
上記が示すパケットを処理したユニークなＫＡＭＡＬタグ．
ｕｎｓｉｇｎｅｄ ｌｏｎｇ ｐａｃｋｅｔ＿ｃｏｕｎｔｅｒ；
上記が示す連続的なパケット番号
ｓｔｒｕｃｔ ｔｉｍｅｖａｌ ｅｐｏｃｈ＿ｔｉｍｅ＿ｓｔａｍｐ；
上記の＜ｓｙｓ／ｔｉｍｅ．ｈ＞に定義されたと同様に構造的な時間値に関するパケット到着を示す６４ｂｉｔのタイムスタンプ。
−３２ｂｉｔ：エポック（ｅｐｏｃｈ）を開始することからの秒数
−３２ｂｉｔ：エポック（ｅｐｏｃｈ）を開始することからのマイクロセカンドの数
｝ ＿＿ａｔｔｒｉｂｕｔｅ＿＿（（＿＿ｐａｃｋｅｄ＿＿））；
ｓｔｒｕｃｔ ｍａｃ＿ａｄｄｒｅｓｓ＿ｆｏｒｍａｔ
｛
ｕｎｓｉｇｎｅｄ ｃｈａｒ ｍａｃ＿ａｄｄｒｅｓｓ［６］；
｝ ＿＿ａｔｔｒｉｂｕｔｅ＿＿（（＿＿ｐａｃｋｅｄ＿＿））；
ｓｔｒｕｃｔ ＫＡＭＡＬ＿ｉｐ＿ｄｅｔａｉｌｓ＿ｆｏｒｍａｔ
｛
ｓｔｒｕｃｔ ｍａｃ＿ａｄｄｒｅｓｓ＿ｆｏｒｍａｔ ＫＡＭＡＬ＿ｅｔｈ＿ｓｒｃ＿ｍａｃ＿ａｄｄｒｅｓｓ；
ｓｔｒｕｃｔ ｍａｃ＿ａｄｄｒｅｓｓ＿ｆｏｒｍａｔ ＫＡＭＡＬ＿ｅｔｈ＿ｄｓｔ＿ｍａｃ＿ａｄｄｒｅｓｓ；
ｕｎｓｉｇｎｅｄ ｃｈａｒ ＫＡＭＡＬ＿ｔｙｐｅ＿ｏｆ＿ｓｅｒｖｉｃｅ；
ｕｎｓｉｇｎｅｄ ｃｈａｒ ＫＡＭＡＬ＿ｉｐ＿ｐｒｏｔｏｃｏｌ；
ｕｎｓｉｇｎｅｄ ｓｈｏｒｔ ＫＡＭＡＬ＿ｉｐ＿ｐａｃｋｅｔ＿ｌｅｎｇｔｈ；
ｕｎｓｉｇｎｅｄ ｌｏｎｇ ＫＡＭＡＬ＿ｉｐ＿ｓｏｕｒｃｅ＿ｉｐ＿ａｄｄｒｅｓｓ；
ｕｎｓｉｇｎｅｄ ｌｏｎｇ ＫＡＭＡＬ＿ｉｐ＿ｄｅｓｔｉｎａｔｉｏｎ＿ｉｐ＿ａｄｄｒｅｓｓ；
｝ ＿＿ａｔｔｒｉｂｕｔｅ＿＿（（＿＿ｐａｃｋｅｄ＿＿））；
ｓｔｒｕｃｔ ＫＡＭＡＬ＿ｔｃｐ＿ｄｅｔａｉｌｓ＿ｆｏｒｍａｔ
｛
ｕｎｓｉｇｎｅｄ ｓｈｏｒｔ ＫＡＭＡＬ＿ｔｃｐ＿ｓｏｕｒｃｅ＿ｐｏｒｔ；
ｕｎｓｉｇｎｅｄ ｓｈｏｒｔ ＫＡＭＡＬ＿ｔｃｐ＿ｄｅｓｔｉｎａｔｉｏｎ＿ｐｏｒｔ；
ｕｎｓｉｇｎｅｄ ｃｈａｒ ＫＡＭＡＬ＿ｔｃｐ＿ｃｏｎｔｒｏｌ＿ｆｌａｇｓ；
ｕｎｓｉｇｎｅｄ ｃｈａｒ ＫＡＭＡＬ＿ａｐｐｌｉｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｔｙｐｅ；
上記がテーブル表すフィールドは（ＫＡＭＡＬ＿ａｐｐｌｉｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｓｔｒｉｎｇに送られる）抽出された情報のタイプを表すコードを含む。アプリケーションプロトコルに依存する。
例：
アプリケーションタイプ フィールド ＫＡＭＡＬ＿ａｐｐｌｉｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｓｔｒｉｎｇ
ＨＴＴＰ １ ウェブサイトのアドレッス
ＰＯＰＳメール １ メールユーザー番号
ＳＭＴＰメール １ 誰にメールを送ったのかのメールの身元確認番号
誰から受け取ったメールであるかを識別する身元確認番号
ＦＴＰ １ ログギングした場合の確認番号
ｕｎｓｉｇｎｅｄ ｓｈｏｒｔ ＫＡＭＡＬ＿ｔｃｐ＿ａｐｐｌｉｃａｔｉｏｎ＿ｐｒｏｔｏｃｏｌ；
上記はアプリケーションレベルプロトコルを示す２ｂｙｔｅのコードです。
例：ＨＴＴＰのための８０、ｓｓｌ―ｈｔｔｐｓのための４４３、ＰＯＰ３メールのための１１１０、ＳＭＴＰ メールのための２５。
｝ ＿＿ａｔｔｒｉｂｕｔｅ＿＿（（＿＿ｐａｃｋｅｄ＿＿））；
ｓｔｒｕｃｔ ＫＡＭＡＬ＿ａｐｐｌｉｃａｔｉｏｎ＿ａｎａｌｙｓｉｓ＿ｆｏｒｍａｔ
｛
ｕｎｓｉｇｎｅｄ ｃｈａｒ ＫＡＭＡＬ＿ａｐｐｌｉｃａｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｔｅｘｔ［４０］；
上記が示す空（ＮＵＬＬ）で終えたアプリケーションプロトコルのテキスト記述。
例： ＨＴＴＰ、ｓｓｌ−ｈｔｔｐｓ、ＰＯＰ３メール、ＳＭＴＰメール。
［次のバージュン（ｖ１．０１）でこのフィールドは削除されます。アプリケーションはクライアントＧＵＩの当該フィールドにテーブル表示されるために ＫＡＭＡＬ＿ｔｃｐ＿ａｐｐｌｉｃａｔｉｏｎ＿ｐｒｏｔｏｃｏｌをデコードすることが出来る。使用するコードが標準化されるまでベータバージョンでコードはＫＡＭＡＬによってデコードされて通信する列はこのフィールドに送られる］
ｕｎｓｉｇｎｅｄ ｃｈａｒ ＫＡＭＡＬ＿ａｐｐｌｉｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｓｔｒｉｎｇ［８０］；
空（ＮＵＬＬ）で終わった記述が列に含まれている場合はパケットのパラメータを抽出したものである。
例： ウエッブサイトアドレス、ユーザー身元確認、誰に送られたのかを示す電子メールの身元確認、誰から送られてきたのか示す電子メールの身元確認。
｝ ＿＿ａｔｔｒｉｂｕｔｅ＿＿（（＿＿ｐａｃｋｅｄ＿＿））；
ｓｔｒｕｃｔ ＫＡＭＡＬ＿ｐａｔ＿ｒｏｗ＿ｆｏｒｍａｔ
｛
ｓｔｒｕｃｔ ＫＡＭＡＬ＿ｉｐ＿ｄｅｔａｉｌｓ＿ｆｏｒｍａｔ ＫＡＭＡＬ＿ｉｐ＿ｄｅｔａｉｌｓ；
ｓｔｒｕｃｔ ＫＡＭＡＬ＿ｔｃｐ＿ｄｅｔａｉｌｓ＿ｆｏｒｍａｔ ＫＡＭＡＬ＿ｔｃｐ＿ｄｅｔａｉｌｓ；
ｓｔｒｕｃｔ ＫＡＭＡＬ＿ａｐｐｌｉｃａｔｉｏｎ＿ａｎａｌｙｓｉｓ＿ｆｏｒｍａｔ ａｐｐｌｉｃａｔｉｏｎ＿ａｎａｌｙｓｉｓ；
｝ ＿＿ａｔｔｒｉｂｕｔｅ＿＿（（＿＿ｐａｃｋｅｄ＿＿））；
ＫＡＭＡＬ
データを設定する： ＫＡＭＡＬ／ＧＵＬＡＢボードのタイムスタンプを設定する。
データを取得する： 上記のＫＡＭＡＬ／ＧＵＬＡＢボードの当該日付／時間を返す。
フィルターテーブルを読む：ＫＡＭＡＬ−ＩＩで全部のフィルターテーブルを読む
フィルターテーブルをアップロードする：ＫＡＭＡＬ−ＩＩ で新しいフィルターテーブルをつくる
１つのフィルター列を読む：ＫＡＭＡＬ−ＩＩ で１つのフィルター列を読む
１つのフィルター列をセットする：ＫＡＭＡＬ−ＩＩ で１つのフィルター列を修正する
１つのフィルター列を加える：ＫＡＭＡＬ−ＩＩ で新しいフィルター列を加える
１つのフィルター列を削除する：ＫＡＭＡＬ−ＩＩで新しいフィルター列を削除する
ＫＡＭＡＬタグを取得する
プロトコルテーブを取得する
プロトコルテーブルを加える
プロトコルテーブルを削除する
デフォルト設定に設定する
大部分のＫＡＭＡＬの呼び出しが内部使用のためにあります、そしてＧＵＬＡＢセッション分析インターフェイスが ｍｓｓ のために必要とされるように以下にＧＵＬＡＢ ボードについてのより詳細な説明に入りました。
ＧＵＬＡＢボード
ＧＵＬＡＢ ボードの初期化：
当該ボードを初期化するために使用できる。仮にＧＵＬＡＢボードは既に誰かによってｉｎｉｔ値が他のプログラムによって構成を設定されたならば、そしてもし最新のプログラムが該ｉｎｉｔ値をリセットすることを望むならば、該関数を呼び出すことが出来る。この関数に対して呼び出しが行なわれる時、ＧＵＬＡＢボードの機能は工場設定時と同じように初期化される。
アプリケーションテーブルをセットする：
当該機能はどのアプリケーションが分析されるはずであるかを決定するために使われるテーブルをＧＵＬＡＢ ボードに作る。このテーブルはいくつかの列から出来ている。 該テーブル内のそれぞれの列がアプリケーションタイプ、アプリケーションのテキストテーブルから出来ていて、そしてフラグをたてることを可能にする。
例として、
＃ＡＰＰＬＩＣＡＴＩＯＮ＿ＮＵＭＢＥＲ ＡＰＰＬＩＣＡＴＩＯＮ＿ＮＡＭＥ ＥＮＡＢＬＥ／ＤＩＳＡＢＬＥ
１ ＨＴＴＰ １
２ ＳＭＴＰ １
３ ＲＴＰ ０
ｅｎａｂｌｅ／ｄｉｓａｂｌｅフィールドが“１”の値は上記の通りにこのタイプのアプリケーションのためのセッションが組み立てられるために必要となる。該フィールがゼロ“０”を示す場合は上記の通りにこのタイプのアプリケーションのためのセッションが組み立てられる必要がないことを示す。
アプリケーションテーブルを取得する：
すべてのアプリケーションテーブルとともに当該アプリケーションに付いているｅｎａｂｌｅ／ｄｉｓａｂｌｅ状態を読む。
アプリケーション列の詳細：
将来の拡張のためには、新しいアプリケーションプロトコルを定義することが予想される、そして加えられるかあるいは削除されることもありえる。
アプリケーション列を加える：
将来の拡張のために。 将来、それは新しいアプリケーションプロトコルを定義することが予想される、そして加えられるかあるいは削除することも出来る。
アプリケーション列をセットする：
アプリケーションテーブルのアプリケーション列をｅｎａｂｌｅにするかあるいはｄｉｓａｂｌｅにするためには、１つのアプリケーションのためにセッション分析をｅｎａｂｌｅにするか、あるいはｄｉｓａｂｌｅにする該機能を使う。
アプリケーション列を取得する：
アプリケーション列とｅｎａｂｌｅ／ｄｉｓａｂｌｅの状態を読む。この機能はアプリケーションのテキストの記述とｅｎａｂｌｅ／ｄｉｓａｂｌｅのフラグの状態を読む。
ファイル名ベースをセットする：
ＧＵＬＡＢは種々のフォーマットでデータベースをつくることが出来る。例えば、毎日、毎週、あるいは毎月それぞれのアプリケーションタイプのために別個のファイルをつくることが出来る。 該機能を呼び出すアプリケーションを使ってＧＵＬＡＢが異なったファイルをつくる基本となるファイル名を提供することが出来るようにする。
実行可能なフォーマットが下に示される。
ＳｅｔＦｉｌｅｎａｍｅＢａｓｅ （ｉｎｔ ＡＰＰＬＩＣＡＴＩＯＮ＿ＴＹＰＥ， ｉｎｔ ＭＥＴＨＯＤ＿ＴＹＰＥ， ｕｎｓｉｇｎｅｄ ｃｈａｒ ＊ｂａｓｅ＿ｓｔｒｉｎｇ［］）：
下記は実行例である。
ＳｅｔＦｉｌｅｎａｍｅＢａｓｅ （ ＳＭＴＰ＿ＡＰＰＬＩＣＡＴＩＯＮ， ＭＯＮＴＨ＿ＷＩＳＥ， “ｍｓｓ＿ｓｍｔｐ＿ｓｅｓｓｉｏｎｓ＿”， ＧＵＬＡＢ＿ＭＯＮＴＨ＿ＳＴＲＩＮＧ， ”＿２００６”， ＮＵＬＬ）；
下記の列のようなファイルをつくる。
ｍｓｓ＿ｓｍｔｐ＿ｓｅｓｓｉｏｎｓ＿ＪＵＮ＿２００６．ｇｌｂ
ｍｓｓ＿ｓｍｔｐ＿ｓｅｓｓｉｏｎｓ＿ＪＵＬ＿２００６．ｇｌｂ
下記の関数に従う呼び出し機能が少し異なったファイルタイプをつくる。
ＳｅｔＦｉｌｅｎａｍｅＢａｓｅ （ ＳＭＴＰ＿ＡＰＰＬＩＣＡＴＩＯＮ， ＭＯＮＴＨ＿ＷＩＳＥ， “ｍｓｓ＿ｓｍｔｐ＿ｓｅｓｓｉｏｎｓ＿”， ＧＵＬＡＢ＿ＭＯＮＴＨ＿ＮＵＭＥＲＩＣＡＬ， ”＿２００６”， ＮＵＬＬ）；
ｍｓｓ＿ｓｍｔｐ＿ｓｅｓｓｉｏｎｓ＿０６＿２００６．ｇｌｂ
ｍｓｓ＿ｓｍｔｐ＿ｓｅｓｓｉｏｎｓ＿０７＿２００６．ｇｌｂ
下記に他の例を示す。
ＳｅｔＦｉｌｅｎａｍｅＢａｓｅ （ＡＬＬ＿ＡＰＰＬＩＣＡＴＩＯＮＳ， ＤＡＴＥ＿ＭＯＮＴＨ＿ＷＩＳＥ， “ｍｓｓ＿ａｐｐｌｉｃａｔｉｏｎ＿ｓｅｓｓｉｏｎｓ＿２００６”， ＧＵＬＡＢ＿ＭＯＮＴＨ＿ＤＡＴＥ＿ ＮＵＭＥＲＩＣＡＬ， ＮＵＬＬ）；
Ｗｉｌｌ ｃｒｅａｔｅ
ｍｓｓ＿ａｐｐｌｉｃａｔｉｏｎ＿ｓｅｓｓｉｏｎｓ＿２００６０６０１．ｇｌｂ
ｍｓｓ＿ａｐｐｌｉｃａｔｉｏｎ＿ｓｅｓｓｉｏｎｓ＿２００６０６０２．ｇｌｂ
ｍｓｓ＿ａｐｐｌｉｃａｔｉｏｎ＿ｓｅｓｓｉｏｎｓ＿２００６０６３０．ｇｌｂ
ｅｔｃ
ファイル名ベースを取得する：
現在使用中のファイル名を基本としたタイプを返す 。
所定のアプリケーション用のファイル名を取得する：
将来使用するために、不完全なセッションの分析をすることを計画した。
ＧＵＬＡＢタグを取得する：
ＧＵＬＡＢの一意的なタグを返す。ファイル名を基本としたかあるいは分析テーブルをつくるために使うことが出来る。
ＧＵＬＡＢデータアップロードフォーマット
−３２ｂｉｔ：エポック（ｅｐｏｃｈ）を開始することからのマイクロセカンドの数
｝ ＿＿ａｔｔｒｉｂｕｔｅ＿＿（（＿＿ｐａｃｋｅｄ＿＿））；
ｓｔｒｕｃｔ ｍａｃ＿ａｄｄｒｅｓｓ＿ｆｏｒｍａｔ
｛
ｕｎｓｉｇｎｅｄ ｃｈａｒ ｍａｃ＿ａｄｄｒｅｓｓ［６］；
｝ ＿＿ａｔｔｒｉｂｕｔｅ＿＿（（＿＿ｐａｃｋｅｄ＿＿））；
ｓｔｒｕｃｔ ＫＡＭＡＬ＿ｉｐ＿ｄｅｔａｉｌｓ＿ｆｏｒｍａｔ
｛
ｓｔｒｕｃｔ ｍａｃ＿ａｄｄｒｅｓｓ＿ｆｏｒｍａｔ ＫＡＭＡＬ＿ｅｔｈ＿ｓｒｃ＿ｍａｃ＿ａｄｄｒｅｓｓ；
ｓｔｒｕｃｔ ｍａｃ＿ａｄｄｒｅｓｓ＿ｆｏｒｍａｔ ＫＡＭＡＬ＿ｅｔｈ＿ｄｓｔ＿ｍａｃ＿ａｄｄｒｅｓｓ；
ｕｎｓｉｇｎｅｄ ｃｈａｒ ＫＡＭＡＬ＿ｔｙｐｅ＿ｏｆ＿ｓｅｒｖｉｃｅ；
ｕｎｓｉｇｎｅｄ ｃｈａｒ ＫＡＭＡＬ＿ｉｐ＿ｐｒｏｔｏｃｏｌ；
ｕｎｓｉｇｎｅｄ ｓｈｏｒｔ ＫＡＭＡＬ＿ｉｐ＿ｐａｃｋｅｔ＿ｌｅｎｇｔｈ；
ｕｎｓｉｇｎｅｄ ｌｏｎｇ ＫＡＭＡＬ＿ｉｐ＿ｓｏｕｒｃｅ＿ｉｐ＿ａｄｄｒｅｓｓ；
ｕｎｓｉｇｎｅｄ ｌｏｎｇ ＫＡＭＡＬ＿ｉｐ＿ｄｅｓｔｉｎａｔｉｏｎ＿ｉｐ＿ａｄｄｒｅｓｓ；
｝ ＿＿ａｔｔｒｉｂｕｔｅ＿＿（（＿＿ｐａｃｋｅｄ＿＿））；
ｓｔｒｕｃｔ ＫＡＭＡＬ＿ｔｃｐ＿ｄｅｔａｉｌｓ＿ｆｏｒｍａｔ
｛
ｕｎｓｉｇｎｅｄ ｓｈｏｒｔ ＫＡＭＡＬ＿ｔｃｐ＿ｓｏｕｒｃｅ＿ｐｏｒｔ；
ｕｎｓｉｇｎｅｄ ｓｈｏｒｔ ＫＡＭＡＬ＿ｔｃｐ＿ｄｅｓｔｉｎａｔｉｏｎ＿ｐｏｒｔ；
ｕｎｓｉｇｎｅｄ ｃｈａｒ ＫＡＭＡＬ＿ｔｃｐ＿ｃｏｎｔｒｏｌ＿ｆｌａｇｓ；
ｕｎｓｉｇｎｅｄ ｃｈａｒ ＫＡＭＡＬ＿ａｐｐｌｉｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｔｙｐｅ；
上記がテーブル表すフィールドは（ＫＡＭＡＬ＿ａｐｐｌｉｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｓｔｒｉｎｇに送られる）抽出された情報のタイプを表すコードを含む。アプリケーションプロトコルに依存する。
例：
アプリケーションタイプ フィールド ＫＡＭＡＬ＿ａｐｐｌｉｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｓｔｒｉｎｇ
ＨＴＴＰ １ ウェブサイトのアドレッス
ＰＯＰＳメール １ メールユーザー番号
ＳＭＴＰメール １ 誰にメールを送ったのかのメールの身元確認番号
誰から受け取ったメールであるかを識別する身元確認番号
ＦＴＰ １ ログギングした場合の確認番号
ｕｎｓｉｇｎｅｄ ｓｈｏｒｔ ＫＡＭＡＬ＿ｔｃｐ＿ａｐｐｌｉｃａｔｉｏｎ＿ｐｒｏｔｏｃｏｌ；
上記はアプリケーションレベルプロトコルを示す２ｂｙｔｅのコードです。
例：ＨＴＴＰのための８０、ｓｓｌ―ｈｔｔｐｓのための４４３、ＰＯＰ３メールのための１１１０、ＳＭＴＰ メールのための２５。
｝ ＿＿ａｔｔｒｉｂｕｔｅ＿＿（（＿＿ｐａｃｋｅｄ＿＿））；
ｓｔｒｕｃｔ ＫＡＭＡＬ＿ａｐｐｌｉｃａｔｉｏｎ＿ａｎａｌｙｓｉｓ＿ｆｏｒｍａｔ
｛
ｕｎｓｉｇｎｅｄ ｃｈａｒ ＫＡＭＡＬ＿ａｐｐｌｉｃａｔｉｏｎ＿ｐｒｏｔｏｃｏｌ＿ｔｅｘｔ［４０］；
上記が示す空（ＮＵＬＬ）で終えたアプリケーションプロトコルのテキスト記述。
例： ＨＴＴＰ、ｓｓｌ−ｈｔｔｐｓ、ＰＯＰ３メール、ＳＭＴＰメール。
［次のバージュン（ｖ１．０１）でこのフィールドは削除されます。アプリケーションはクライアントＧＵＩの当該フィールドにテーブル表示されるために ＫＡＭＡＬ＿ｔｃｐ＿ａｐｐｌｉｃａｔｉｏｎ＿ｐｒｏｔｏｃｏｌをデコードすることが出来る。使用するコードが標準化されるまでベータバージョンでコードはＫＡＭＡＬによってデコードされて通信する列はこのフィールドに送られる］
ｕｎｓｉｇｎｅｄ ｃｈａｒ ＫＡＭＡＬ＿ａｐｐｌｉｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｓｔｒｉｎｇ［８０］；
空（ＮＵＬＬ）で終わった記述が列に含まれている場合はパケットのパラメータを抽出したものである。
例： ウエッブサイトアドレス、ユーザー身元確認、誰に送られたのかを示す電子メールの身元確認、誰から送られてきたのか示す電子メールの身元確認。
｝ ＿＿ａｔｔｒｉｂｕｔｅ＿＿（（＿＿ｐａｃｋｅｄ＿＿））；
ｓｔｒｕｃｔ ＫＡＭＡＬ＿ｐａｔ＿ｒｏｗ＿ｆｏｒｍａｔ
｛
ｓｔｒｕｃｔ ＫＡＭＡＬ＿ｉｐ＿ｄｅｔａｉｌｓ＿ｆｏｒｍａｔ ＫＡＭＡＬ＿ｉｐ＿ｄｅｔａｉｌｓ；
ｓｔｒｕｃｔ ＫＡＭＡＬ＿ｔｃｐ＿ｄｅｔａｉｌｓ＿ｆｏｒｍａｔ ＫＡＭＡＬ＿ｔｃｐ＿ｄｅｔａｉｌｓ；
ｓｔｒｕｃｔ ＫＡＭＡＬ＿ａｐｐｌｉｃａｔｉｏｎ＿ａｎａｌｙｓｉｓ＿ｆｏｒｍａｔ ａｐｐｌｉｃａｔｉｏｎ＿ａｎａｌｙｓｉｓ；
｝ ＿＿ａｔｔｒｉｂｕｔｅ＿＿（（＿＿ｐａｃｋｅｄ＿＿））；
ＫＡＭＡＬ
データを設定する： ＫＡＭＡＬ／ＧＵＬＡＢボードのタイムスタンプを設定する。
データを取得する： 上記のＫＡＭＡＬ／ＧＵＬＡＢボードの当該日付／時間を返す。
フィルターテーブルを読む：ＫＡＭＡＬ−ＩＩで全部のフィルターテーブルを読む
フィルターテーブルをアップロードする：ＫＡＭＡＬ−ＩＩ で新しいフィルターテーブルをつくる
１つのフィルター列を読む：ＫＡＭＡＬ−ＩＩ で１つのフィルター列を読む
１つのフィルター列をセットする：ＫＡＭＡＬ−ＩＩ で１つのフィルター列を修正する
１つのフィルター列を加える：ＫＡＭＡＬ−ＩＩ で新しいフィルター列を加える
１つのフィルター列を削除する：ＫＡＭＡＬ−ＩＩで新しいフィルター列を削除する
ＫＡＭＡＬタグを取得する
プロトコルテーブを取得する
プロトコルテーブルを加える
プロトコルテーブルを削除する
デフォルト設定に設定する
大部分のＫＡＭＡＬの呼び出しが内部使用のためにあります、そしてＧＵＬＡＢセッション分析インターフェイスが ｍｓｓ のために必要とされるように以下にＧＵＬＡＢ ボードについてのより詳細な説明に入りました。
ＧＵＬＡＢボード
ＧＵＬＡＢ ボードの初期化：
当該ボードを初期化するために使用できる。仮にＧＵＬＡＢボードは既に誰かによってｉｎｉｔ値が他のプログラムによって構成を設定されたならば、そしてもし最新のプログラムが該ｉｎｉｔ値をリセットすることを望むならば、該関数を呼び出すことが出来る。この関数に対して呼び出しが行なわれる時、ＧＵＬＡＢボードの機能は工場設定時と同じように初期化される。
アプリケーションテーブルをセットする：
当該機能はどのアプリケーションが分析されるはずであるかを決定するために使われるテーブルをＧＵＬＡＢ ボードに作る。このテーブルはいくつかの列から出来ている。 該テーブル内のそれぞれの列がアプリケーションタイプ、アプリケーションのテキストテーブルから出来ていて、そしてフラグをたてることを可能にする。
例として、
＃ＡＰＰＬＩＣＡＴＩＯＮ＿ＮＵＭＢＥＲ ＡＰＰＬＩＣＡＴＩＯＮ＿ＮＡＭＥ ＥＮＡＢＬＥ／ＤＩＳＡＢＬＥ
１ ＨＴＴＰ １
２ ＳＭＴＰ １
３ ＲＴＰ ０
ｅｎａｂｌｅ／ｄｉｓａｂｌｅフィールドが“１”の値は上記の通りにこのタイプのアプリケーションのためのセッションが組み立てられるために必要となる。該フィールがゼロ“０”を示す場合は上記の通りにこのタイプのアプリケーションのためのセッションが組み立てられる必要がないことを示す。
アプリケーションテーブルを取得する：
すべてのアプリケーションテーブルとともに当該アプリケーションに付いているｅｎａｂｌｅ／ｄｉｓａｂｌｅ状態を読む。
アプリケーション列の詳細：
将来の拡張のためには、新しいアプリケーションプロトコルを定義することが予想される、そして加えられるかあるいは削除されることもありえる。
アプリケーション列を加える：
将来の拡張のために。 将来、それは新しいアプリケーションプロトコルを定義することが予想される、そして加えられるかあるいは削除することも出来る。
アプリケーション列をセットする：
アプリケーションテーブルのアプリケーション列をｅｎａｂｌｅにするかあるいはｄｉｓａｂｌｅにするためには、１つのアプリケーションのためにセッション分析をｅｎａｂｌｅにするか、あるいはｄｉｓａｂｌｅにする該機能を使う。
アプリケーション列を取得する：
アプリケーション列とｅｎａｂｌｅ／ｄｉｓａｂｌｅの状態を読む。この機能はアプリケーションのテキストの記述とｅｎａｂｌｅ／ｄｉｓａｂｌｅのフラグの状態を読む。
ファイル名ベースをセットする：
ＧＵＬＡＢは種々のフォーマットでデータベースをつくることが出来る。例えば、毎日、毎週、あるいは毎月それぞれのアプリケーションタイプのために別個のファイルをつくることが出来る。 該機能を呼び出すアプリケーションを使ってＧＵＬＡＢが異なったファイルをつくる基本となるファイル名を提供することが出来るようにする。
実行可能なフォーマットが下に示される。
ＳｅｔＦｉｌｅｎａｍｅＢａｓｅ （ｉｎｔ ＡＰＰＬＩＣＡＴＩＯＮ＿ＴＹＰＥ， ｉｎｔ ＭＥＴＨＯＤ＿ＴＹＰＥ， ｕｎｓｉｇｎｅｄ ｃｈａｒ ＊ｂａｓｅ＿ｓｔｒｉｎｇ［］）：
下記は実行例である。
ＳｅｔＦｉｌｅｎａｍｅＢａｓｅ （ ＳＭＴＰ＿ＡＰＰＬＩＣＡＴＩＯＮ， ＭＯＮＴＨ＿ＷＩＳＥ， “ｍｓｓ＿ｓｍｔｐ＿ｓｅｓｓｉｏｎｓ＿”， ＧＵＬＡＢ＿ＭＯＮＴＨ＿ＳＴＲＩＮＧ， ”＿２００６”， ＮＵＬＬ）；
下記の列のようなファイルをつくる。
ｍｓｓ＿ｓｍｔｐ＿ｓｅｓｓｉｏｎｓ＿ＪＵＮ＿２００６．ｇｌｂ
ｍｓｓ＿ｓｍｔｐ＿ｓｅｓｓｉｏｎｓ＿ＪＵＬ＿２００６．ｇｌｂ
下記の関数に従う呼び出し機能が少し異なったファイルタイプをつくる。
ＳｅｔＦｉｌｅｎａｍｅＢａｓｅ （ ＳＭＴＰ＿ＡＰＰＬＩＣＡＴＩＯＮ， ＭＯＮＴＨ＿ＷＩＳＥ， “ｍｓｓ＿ｓｍｔｐ＿ｓｅｓｓｉｏｎｓ＿”， ＧＵＬＡＢ＿ＭＯＮＴＨ＿ＮＵＭＥＲＩＣＡＬ， ”＿２００６”， ＮＵＬＬ）；
ｍｓｓ＿ｓｍｔｐ＿ｓｅｓｓｉｏｎｓ＿０６＿２００６．ｇｌｂ
ｍｓｓ＿ｓｍｔｐ＿ｓｅｓｓｉｏｎｓ＿０７＿２００６．ｇｌｂ
下記に他の例を示す。
ＳｅｔＦｉｌｅｎａｍｅＢａｓｅ （ＡＬＬ＿ＡＰＰＬＩＣＡＴＩＯＮＳ， ＤＡＴＥ＿ＭＯＮＴＨ＿ＷＩＳＥ， “ｍｓｓ＿ａｐｐｌｉｃａｔｉｏｎ＿ｓｅｓｓｉｏｎｓ＿２００６”， ＧＵＬＡＢ＿ＭＯＮＴＨ＿ＤＡＴＥ＿ ＮＵＭＥＲＩＣＡＬ， ＮＵＬＬ）；
Ｗｉｌｌ ｃｒｅａｔｅ
ｍｓｓ＿ａｐｐｌｉｃａｔｉｏｎ＿ｓｅｓｓｉｏｎｓ＿２００６０６０１．ｇｌｂ
ｍｓｓ＿ａｐｐｌｉｃａｔｉｏｎ＿ｓｅｓｓｉｏｎｓ＿２００６０６０２．ｇｌｂ
ｍｓｓ＿ａｐｐｌｉｃａｔｉｏｎ＿ｓｅｓｓｉｏｎｓ＿２００６０６３０．ｇｌｂ
ｅｔｃ
ファイル名ベースを取得する：
現在使用中のファイル名を基本としたタイプを返す 。
所定のアプリケーション用のファイル名を取得する：
将来使用するために、不完全なセッションの分析をすることを計画した。
ＧＵＬＡＢタグを取得する：
ＧＵＬＡＢの一意的なタグを返す。ファイル名を基本としたかあるいは分析テーブルをつくるために使うことが出来る。
ＧＵＬＡＢデータアップロードフォーマット
ｓｔｒｕｃｔ ＧＵＬＡＢ＿ＦＩＸＥＤ＿ＨＥＡＤＥＲ＿ＦＯＲＭＡＴ
｛
ｕｎｓｉｇｎｅｄ ｃｈａｒ ＧＵＬＡＢ＿ＩＤ＿ＳＴＲＩＮＧ［５］；
ボードの認識。常に ＧＵＬＡＢのために列に“ＧＵＬＡＢ”を含む。
ｕｎｓｉｇｎｅｄ ｃｈａｒ ＧＵＬＡＢ＿ＶＥＲＳＩＯＮ＿ＳＴＲＩＮＧ［２］；
ＧＵＬＡＢバーション番号
ｕｎｓｉｇｎｅｄ ｃｈａｒ ＧＵＬＡＢ＿ＲＥＬＥＡＳＥ＿ＳＴＲＩＮＧ［２］；
ＧＵＬＡＢリリース番号
ｕｎｓｉｇｎｅｄ ｃｈａｒ ＧＵＬＡＢ＿ＰＫＴ＿ＴＹＰＥ＿ＩＤＥＮＴＩＦＩＥＲ；
レコードタイプ、
０＝ レコード、はセッション解析テーブル列（ちょうどあてはまる列）
１＝ レコード、はセッションデータ列
ｕｎｓｉｇｎｅｄ ｓｈｏｒｔ ｔｏｔａｌ＿ｌｅｎｇｔｈ；
レコードの全長、
列記録の設定のために：
ヘッダレコードのサイズ ＋ 設定する列のサイズ
オリジナルパケトデータレコードのために：
レコードヘッダサイズ（２８） ＋ オリジナルセッションデータサイズ（変数）
ｕｎｓｉｇｎｅｄ ｌｏｎｇ ＧＵＬＡＢ＿ＢＯＡＲＤ＿ＴＡＧ；
パケットを処理したユニークなＧＵＬＡＢボードタグ
ｕｎｓｉｇｎｅｄ ｌｏｎｇ ｓｅｓｓｉｏｎ＿ｃｏｕｎｔｅｒ；
連続的なセッション番号
｝ ＿＿ａｔｔｒｉｂｕｔｅ＿＿（（＿＿ｐａｃｋｅｄ＿＿））；
ｓｔｒｕｃｔ ＧＵＬＡＢ＿ｓｅｓｓｉｏｎ＿ｄｅｔａｉｌｓ＿ｆｏｒｍａｔ
｛
ｓｔｒｕｃｔ ｔｉｍｅｖａｌ ｓｔａｒｔ＿ｅｐｏｃｈ＿ｔｉｍｅ＿ｓｔａｍｐ；
＜ｓｙｓ／ｔｉｍｅｈ＞に定義されたと同様に定義された構造的な時間値の条件におけるセッション開始の６４ｂｉｔタイムスタンプ。
―３２ｂｉｔ：エポック開始らの秒数
−３２ｂｉｔ：エポック開始からのマイクロセカンド数
ｓｔｒｕｃｔ ｔｉｍｅｖａｌ ｅｎｄ＿ｅｐｏｃｈ＿ｔｉｍｅ＿ｓｔａｍｐ；
＜ｓｙｓ／ｔｉｍｅｈ＞に定義されたと同様に定義された構造的な時間値の条件におけるセッション終了の６４ｂｉｔタイムスタンプ。
−３２ｂｉｔ：エポック開始からのマイクロセカンド数
ｓｔｒｕｃｔ ｔｉｍｅｖａｌ ｅｎｄ＿ｅｐｏｃｈ＿ｔｉｍｅ＿ｓｔａｍｐ；
＜ｓｙｓ／ｔｉｍｅｈ＞に定義されたと同様に定義された構造的な時間値の条件におけるセッション終了の６４ｂｉｔタイムスタンプ。
―３２ｂｉｔ：エポック開始らの秒数
−３２ｂｉｔ：エポック開始からのマイクロセカンド数
長期に無署名な場合 ｎｏ＿ｏｆ＿ｐａｃｋｅｔｓ
１つのＧＵＬＡＢセッションをつくるために組み立てられた個別のパケットの番号を含む。
長期に無署名な場合 ｓｅｓｓｉｏｎ＿ｄａｔａ＿ｓｉｚｅ
セッションを構成するｂｙｔｅの合計数を含んでいる。
長期にｃｈａｒに無署名な場合 ＧＵＬＡＢ＿ａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅ；
このフィールドにはアプリケーションのタイプを示すコードを含む。
例：
アプリケーションタイプ フィールド
ＨＴＴＰ １
ＰＯＰ３ ２
ＳＭＴＰ ３
ＦＴＰ ４
Ｐａｄｄｉｎｇ ｂｙｔｅｓ
｝ ＿＿ａｔｔｒｉｂｕｔｅ＿＿（（＿＿ｐａｃｋｅｄ＿＿））；
ｓｔｒｕｃｔ ＧＵＬＡＢ＿ａｐｐｌｉｃａｔｉｏｎ＿ｉｎｆｏｒｍａｔｉｏｎ
｛
ｃｈａｒに無署名な場合 ＊ＫＡＭＡＬ＿ｐｏｉｎｔｅｒ＿ｔｏ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｓｔｒｉｎｇ［ＴＢＤ］［ＴＢＤ］；
それぞれのアプリケーション記述列の差し引き計算値、空“ＮＵＬＬ”のポインターを持っているリストの終わり。
−３２ｂｉｔ：エポック開始からのマイクロセカンド数
長期に無署名な場合 ｎｏ＿ｏｆ＿ｐａｃｋｅｔｓ
１つのＧＵＬＡＢセッションをつくるために組み立てられた個別のパケットの番号を含む。
長期に無署名な場合 ｓｅｓｓｉｏｎ＿ｄａｔａ＿ｓｉｚｅ
セッションを構成するｂｙｔｅの合計数を含んでいる。
長期にｃｈａｒに無署名な場合 ＧＵＬＡＢ＿ａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅ；
このフィールドにはアプリケーションのタイプを示すコードを含む。
例：
アプリケーションタイプ フィールド
ＨＴＴＰ １
ＰＯＰ３ ２
ＳＭＴＰ ３
ＦＴＰ ４
Ｐａｄｄｉｎｇ ｂｙｔｅｓ
｝ ＿＿ａｔｔｒｉｂｕｔｅ＿＿（（＿＿ｐａｃｋｅｄ＿＿））；
ｓｔｒｕｃｔ ＧＵＬＡＢ＿ａｐｐｌｉｃａｔｉｏｎ＿ｉｎｆｏｒｍａｔｉｏｎ
｛
ｃｈａｒに無署名な場合 ＊ＫＡＭＡＬ＿ｐｏｉｎｔｅｒ＿ｔｏ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｓｔｒｉｎｇ［ＴＢＤ］［ＴＢＤ］；
それぞれのアプリケーション記述列の差し引き計算値、空“ＮＵＬＬ”のポインターを持っているリストの終わり。
長期にｃｈａｒに無署名な場合 ＫＡＭＡＬ＿ａｐｐｌｉｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｓｔｒｉｎｇ［ＴＢＤ］［ＴＢＤ］；
空（ＮＵＬＬ）で終わった列がパケットの抽出されたパラメータを含む、
例：ＳＭＴＰのために、
ＦＲＯＭ， ＴＯ， Ｆｒｏｍ， Ｔｏ， Ｃｃ， Ｓｕｂｊｅｃｔ， ａｔｔａｃｈｍｅｎｔ ｆｉｌｅ ｎａｍｅｓ
ＨＴＴＰのために、
ＨＴＴＰ ｒｅｑｕｅｓｔ， Ｗｅｂｓｉｔｅ， ｕｒｌ， Ｃｏｎｔｅｎｔ−Ｔｙｐｅ
｝ ＿＿ａｔｔｒｉｂｕｔｅ＿＿（（＿＿ｐａｃｋｅｄ＿＿））；
ｓｔｒｕｃｔ ＧＵＬＡＢ＿ｓａｔ＿ｒｏｗ＿ｆｏｒｍａｔ
｛
ｓｔｒｕｃｔ ＧＵＬＡＢ＿ｓｅｓｓｉｏｎ＿ｄｅｔａｉｌｓ＿ｆｏｒｍａｔ
ＧＵＬＡＢ＿ｓｅｓｓｉｏｎ＿ｄｅｔａｉｌｓ；
ｓｔｒｕｃｔ ＧＵＬＡＢ＿ａｐｐｌｉｃａｔｉｏｎ＿ｉｎｆｏｒｍａｔｉｏｎ
ＧＵＬＡＢ＿ａｐｐｌｉｃａｔｉｏｎ＿ｉｎｆｏｒｍａｔｉｏｎ；
｝ ＿＿ａｔｔｒｉｂｕｔｅ＿＿（（＿＿ｐａｃｋｅｄ＿＿））；
ＧＵＬＡＢデータとインデックスファイル構造
１．ＫＡＭＡＬから受け取ったすべてのパケットはＧＵＬＡＢによって処理される。
２．不完全なセッションは可能なかぎりに組み立てられる、そしてこれらの不完全なセッションデータは同じく別にタグを付けられたファイルに保管される。
３．最終バージョンは要求されるようにすべてのプロトコル分析機能を持つ。
要求されるＲＴＰ、ＳＩＰ、Ｈ．３２３、ＶｏＩＰ、ＩＣＭＰ、Ｔｅｌｎｅｔ、ＦＴＰ、ＤＮＳのセッションから抽出されたどのようなパラメータに対しても分析する。
４．“キープアライブ”を持っているＨＴＴＰ セッションと多くのセッションが適切に ＧＵＬＡＢ によって処理される。
５．複数のメールが異なったセッションとして処理される。
６．ＫＡＭＡＬとＧＵＬＡＢボードがインストールされるとデバイス・ドライバはＬｉｎｕ
ＯＳのもとで稼動する。ＧＵＬＡＢのためのデバイス・ドライバとホストのハードディスク・ドライバは完全に結ばれている。従って、複数の部分にコピーされているセッションデータのオーバーヘッドを避けることが出来る。
７．ＧＵＬＡＢはアプリケーション毎に１つのファイルをつくります。加えるにすべての“不完全なセッション”を集めるために同じく１つのファイルをつくります。ハイレベルな詳細は次の通りである。
空（ＮＵＬＬ）で終わった列がパケットの抽出されたパラメータを含む、
例：ＳＭＴＰのために、
ＦＲＯＭ， ＴＯ， Ｆｒｏｍ， Ｔｏ， Ｃｃ， Ｓｕｂｊｅｃｔ， ａｔｔａｃｈｍｅｎｔ ｆｉｌｅ ｎａｍｅｓ
ＨＴＴＰのために、
ＨＴＴＰ ｒｅｑｕｅｓｔ， Ｗｅｂｓｉｔｅ， ｕｒｌ， Ｃｏｎｔｅｎｔ−Ｔｙｐｅ
｝ ＿＿ａｔｔｒｉｂｕｔｅ＿＿（（＿＿ｐａｃｋｅｄ＿＿））；
ｓｔｒｕｃｔ ＧＵＬＡＢ＿ｓａｔ＿ｒｏｗ＿ｆｏｒｍａｔ
｛
ｓｔｒｕｃｔ ＧＵＬＡＢ＿ｓｅｓｓｉｏｎ＿ｄｅｔａｉｌｓ＿ｆｏｒｍａｔ
ＧＵＬＡＢ＿ｓｅｓｓｉｏｎ＿ｄｅｔａｉｌｓ；
ｓｔｒｕｃｔ ＧＵＬＡＢ＿ａｐｐｌｉｃａｔｉｏｎ＿ｉｎｆｏｒｍａｔｉｏｎ
ＧＵＬＡＢ＿ａｐｐｌｉｃａｔｉｏｎ＿ｉｎｆｏｒｍａｔｉｏｎ；
｝ ＿＿ａｔｔｒｉｂｕｔｅ＿＿（（＿＿ｐａｃｋｅｄ＿＿））；
ＧＵＬＡＢデータとインデックスファイル構造
１．ＫＡＭＡＬから受け取ったすべてのパケットはＧＵＬＡＢによって処理される。
２．不完全なセッションは可能なかぎりに組み立てられる、そしてこれらの不完全なセッションデータは同じく別にタグを付けられたファイルに保管される。
３．最終バージョンは要求されるようにすべてのプロトコル分析機能を持つ。
要求されるＲＴＰ、ＳＩＰ、Ｈ．３２３、ＶｏＩＰ、ＩＣＭＰ、Ｔｅｌｎｅｔ、ＦＴＰ、ＤＮＳのセッションから抽出されたどのようなパラメータに対しても分析する。
４．“キープアライブ”を持っているＨＴＴＰ セッションと多くのセッションが適切に ＧＵＬＡＢ によって処理される。
５．複数のメールが異なったセッションとして処理される。
６．ＫＡＭＡＬとＧＵＬＡＢボードがインストールされるとデバイス・ドライバはＬｉｎｕ
ＯＳのもとで稼動する。ＧＵＬＡＢのためのデバイス・ドライバとホストのハードディスク・ドライバは完全に結ばれている。従って、複数の部分にコピーされているセッションデータのオーバーヘッドを避けることが出来る。
７．ＧＵＬＡＢはアプリケーション毎に１つのファイルをつくります。加えるにすべての“不完全なセッション”を集めるために同じく１つのファイルをつくります。ハイレベルな詳細は次の通りである。
ＧＵＬＡＢセッションは下記のインデックスファイルとデータファイルの２つの部分に保管される。
インデックスファイル
データファイル
上記の１．は、“ＧＵＬＡＢ インデックスファイル”と呼ばれる固定長記録から出来ている、オリジナルパケットデータを含むが、“ＧＵＬＡＢデータファイル”（上記のデータファイル）は通信したオリジナルパケットデータへのポインターから出来ているだけが記録されている。
上記２．には“ＧＵＬＡＢデータファイル”と呼ばれるタイプは可変長記録から出来ている、そして実際のオリジナルパケットを含む（可変長なものである）。
上記１．のインデックスファイルが検索、ソート、収集してグラフィックとテーブルを表示することに使用出来る、そしてクエリ／クエリスクリプト／言語のサポートをするために使うことが出来る。
上記２．データファイルは、データの実際のアクセスに対応した上記１．インデックスファイルを通して直接アクセスすることが出来る実際のオリジナルパケットで出来ている。
上記１．データフィールドにとって特殊な部分は青色で表示する、そして２．データファイルの特殊な部分は赤色でテーブルに表示する。
１０ ネットワーク
２１、２２ ローカルエリアネットワーク
２５ スイッチングハブ
２６ ＴＡＰ
２７ ファイアウォール
２８ ルーター
３０ ＫＡＭＡＬ
５０ ＧＵＬＡＢ
７０ サーバー
２１、２２ ローカルエリアネットワーク
２５ スイッチングハブ
２６ ＴＡＰ
２７ ファイアウォール
２８ ルーター
３０ ＫＡＭＡＬ
５０ ＧＵＬＡＢ
７０ サーバー
Claims (22)
- ネットワークデータトラフィックを監視するためのハードウェアベースのネットワーク監視システムであって、
（ｉ）パケット処理エンジンであって、
（ａ）パケットをスニフしてトラフィックを解析するネットワークプロセッサと、
（ｂ）パケット処理のためのコアエンジンであって、
・プロトコルレベルとアプリケーションレベルとにおいてプロトコル解析データを構成するためにプロトコルを抽出する手段と、
・前記パケットのプロトコルベースの解析手段を有するコアエンジンとを有するパケット処理エンジン、及び／または、
（ｉｉ）セッションレベル解析のためのアプリケーション層プロセッサであって、
（ａ）すべてのセッションを抽出し、セッションデータを構成する手段と、
（ｂ）前記パケットセッションベース解析をする手段を有するアプリケーション層プロセッサとを有するネットワーク監視システム。 - セッションレベルアナライザは、オンボードメモリが十分ではないとき、自動的にホストメモリを使用する、請求項１に記載のネットワーク監視システム。
- セッションレベルアナライザはＰＣＩインターフェイスを用いてホストシステムとインターフェイスする、請求項１に記載のネットワーク監視システム。
- 前記マイクロエンジンはＴＣＰ、ＵＤＰ、ＨＴＴＰ、ＳＭＴＰ／ＰＯＰ３、ＲＴＰ、ＳＩＰ、Ｈ．３２３、ＶｏＩＰ、ＩＣＭＰ、Ｔｅｌｎｅｔ、ＦＴＰ、ＤＮＳパケットのうち少なくとも１つを解析可能である、請求項１に記載のネットワーク監視システム。
- ネットワークデータトラフィックを監視するハードウェアベースの方法であって、
ａ．パケットをスニフする段階と、
ｂ．フラグメンテーションと再組立のために前記スニフされたパケットをチェックする段階と、
ｃ．前記チェックされたパケットのプロトコルを解析する段階と、
ｄ．前記解析されたパケットをホストメモリに保存する段階と、
ｅ．前記保存されたパケットからセッションを生成する段階と、
ｆ．前記セッションを解析して分離する段階と、
ｇ．前記分離したセッションを前記ホストメモリにアップロードする段階とを有する方法。 - パケットは識別フィールドを用いてフラグメント化及びデフラグメントされる、請求項５に記載の方法。
- 前記パケットは、ソースＩＰ、デスティネーションＩＰ、プロトコルフィールド、データロード、パケットカウンタ、パケットサイズ、タイムスタンプ、ソースＭＡＣアドレス、デスティネーションＭＡＣアドレス、ソースポート、デスティネーションポート、ＴＣＰコントロールフラグ及びＴＣＰタイプのサービスを用いて解析される、請求項５に記載の方法。
- 前記方法はデータベースを更新し、それを前記ホストメモリにタイムスタンプを付してアップロードする、請求項５に記載の方法。
- 前記方法は前記パケットを、ＴＣＰ、ＵＤＰ、ＨＴＴＰ、ＳＭＴＰ／ＰＯＰ３、ＲＴＰ、ＳＩＰ、Ｈ．３２３、ＶｏＩＰ、ＩＣＭＰ、Ｔｅｌｎｅｔ、ＦＴＰ、ＤＮＳよりなる群から選択されたプロトコルに分離する、請求項５に記載の方法。
- 前記ＨＴＴＰセッションは、前記セッションの開始時刻及び終了時刻以外にリクエスト方法、ウェブサイト名、ＵＲＬ、コンテンツタイプにより分離される、請求項５に記載の方法。
- 前記ＳＭＴＰ／ＰＯＰ３セッションは、ユーザー名、パスワード、ｆｒｏｍ、ｔｏ、サブジェクト、添付ファイル名よりなる抽出情報により分離される、請求項５に記載の方法。
- 「キープアライブ」パラメータを有するネットワークトラフィックは単一セッションとして処理され、複数セッションは別々のセッションとして処理される、請求項５に記載の方法。
- 前記方法は、検索、ソート、集約、グラフとチャートの表示、及びクエリ／クエリスクリプト／言語のサポートを支援するために、ファイルにインデックスを付ける、請求項５に記載の方法。
- 前記セッションはインデックスファイルとデータファイルの２つのセグメントとして保存される、請求項５に記載の方法。
- 前記インデックスファイルは固定長レコードを有し、生パケット（オリジナルパケット）データは含まず、前記データファイル中の対応する生パケットデータレコードへのポイントを有する、請求項１４に記載の方法。
- 前記データファイルは可変長レコードを有し、実際の可変長の生パケット（オリジナルパケット）データを含む、請求項１４に記載の方法。
- 前記方法はフィルター基準及びコンテンツマッチに基づきパケットを集約する、請求項１４に記載の方法。
- 前記方法はハードウェアレベルにおいてオンザフライでフィルター基準を実行する、請求項１４に記載の方法。
- 前記方法は、フラグメント化されたパケットのデフラグメントと、再組み立てされたパケットに基づきパケットの解析を行う、請求項１４に記載の方法。
- 不完全なセッションも取得できるかぎり蓄積され、一つ一つのパケットを確実に捕捉する、請求項１４に記載の方法。
- 前記方法はネットワーク中のトラフィックの始点をたどる、請求項１４に記載の方法。
- 前記トラフィックの始点は、前記セッション（ｓｅｓｓｉｏｎ）のソース（ｓｏｕｒｃｅ）及びデスティネーション（ｄｅｓｔｉｎａｔｉｏｎ）のＭＡＣアドレス、前記セッションの開始及び終了時刻、及び処理エンジンとアプリケーション層プロセッサカードに割り当てられた一意的タグを用いて特定される、請求項２１に記載の方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP06253291A EP1871038B1 (en) | 2006-06-23 | 2006-06-23 | Network protocol and session analyser |
| EP06253291.6 | 2006-06-23 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2008042892A true JP2008042892A (ja) | 2008-02-21 |
| JP5167501B2 JP5167501B2 (ja) | 2013-03-21 |
Family
ID=36845422
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007165587A Expired - Fee Related JP5167501B2 (ja) | 2006-06-23 | 2007-06-22 | ネットワーク監視システムとその動作方法 |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US8144609B2 (ja) |
| EP (1) | EP1871038B1 (ja) |
| JP (1) | JP5167501B2 (ja) |
| DE (1) | DE602006014667D1 (ja) |
Families Citing this family (32)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20090041013A1 (en) * | 2007-08-07 | 2009-02-12 | Mitchell Nathan A | Dynamically Assigning A Policy For A Communication Session |
| US20090041014A1 (en) * | 2007-08-08 | 2009-02-12 | Dixon Walter G | Obtaining Information From Tunnel Layers Of A Packet At A Midpoint |
| US20090259577A1 (en) * | 2008-04-10 | 2009-10-15 | Cisco Technology, Inc. | Providing Billing Instructions Associated With a New Protocol in a Network Environment |
| US8438269B1 (en) | 2008-09-12 | 2013-05-07 | At&T Intellectual Property I, Lp | Method and apparatus for measuring the end-to-end performance and capacity of complex network service |
| US7829118B1 (en) | 2009-07-30 | 2010-11-09 | Carbylan Biosurgery, Inc. | Modified hyaluronic acid polymer compositions and related methods |
| FR2949934B1 (fr) * | 2009-09-09 | 2011-10-28 | Qosmos | Surveillance d'une session de communication comportant plusieurs flux sur un reseau de donnees |
| KR101286647B1 (ko) * | 2009-11-30 | 2013-08-23 | 한국전자통신연구원 | 세션 관리 방법 |
| US9191284B2 (en) | 2010-10-28 | 2015-11-17 | Avvasi Inc. | Methods and apparatus for providing a media stream quality signal |
| US9032427B2 (en) * | 2010-10-28 | 2015-05-12 | Avvasi Inc. | System for monitoring a video network and methods for use therewith |
| US9037743B2 (en) | 2010-10-28 | 2015-05-19 | Avvasi Inc. | Methods and apparatus for providing a presentation quality signal |
| US8683568B1 (en) * | 2011-09-22 | 2014-03-25 | Emc Corporation | Using packet interception to integrate risk-based user authentication into online services |
| CN102761538B (zh) * | 2012-04-27 | 2014-10-22 | 南大傲拓科技江苏有限公司 | 应用于多种通讯接口网关的通信共享数据区设计管理方法 |
| US10366101B2 (en) | 2014-04-15 | 2019-07-30 | Splunk Inc. | Bidirectional linking of ephemeral event streams to creators of the ephemeral event streams |
| US10700950B2 (en) | 2014-04-15 | 2020-06-30 | Splunk Inc. | Adjusting network data storage based on event stream statistics |
| US10693742B2 (en) | 2014-04-15 | 2020-06-23 | Splunk Inc. | Inline visualizations of metrics related to captured network data |
| US10360196B2 (en) | 2014-04-15 | 2019-07-23 | Splunk Inc. | Grouping and managing event streams generated from captured network data |
| US9762443B2 (en) | 2014-04-15 | 2017-09-12 | Splunk Inc. | Transformation of network data at remote capture agents |
| US11086897B2 (en) | 2014-04-15 | 2021-08-10 | Splunk Inc. | Linking event streams across applications of a data intake and query system |
| US9838512B2 (en) | 2014-10-30 | 2017-12-05 | Splunk Inc. | Protocol-based capture of network data using remote capture agents |
| US10462004B2 (en) | 2014-04-15 | 2019-10-29 | Splunk Inc. | Visualizations of statistics associated with captured network data |
| US11281643B2 (en) | 2014-04-15 | 2022-03-22 | Splunk Inc. | Generating event streams including aggregated values from monitored network data |
| US10523521B2 (en) | 2014-04-15 | 2019-12-31 | Splunk Inc. | Managing ephemeral event streams generated from captured network data |
| US10127273B2 (en) | 2014-04-15 | 2018-11-13 | Splunk Inc. | Distributed processing of network data using remote capture agents |
| US9923767B2 (en) | 2014-04-15 | 2018-03-20 | Splunk Inc. | Dynamic configuration of remote capture agents for network data capture |
| KR101610715B1 (ko) * | 2014-06-11 | 2016-04-08 | 한국전자통신연구원 | 단방향 데이터 송수신 시스템 및 방법 |
| US9596253B2 (en) | 2014-10-30 | 2017-03-14 | Splunk Inc. | Capture triggers for capturing network data |
| US10334085B2 (en) | 2015-01-29 | 2019-06-25 | Splunk Inc. | Facilitating custom content extraction from network packets |
| US10404732B2 (en) | 2016-06-14 | 2019-09-03 | Sdn Systems, Llc | System and method for automated network monitoring and detection of network anomalies |
| US10644983B2 (en) * | 2017-07-28 | 2020-05-05 | Cisco Technology, Inc. | Control plane analytics and policing |
| CN111294383B (zh) * | 2019-12-30 | 2023-01-31 | 欧普照明股份有限公司 | 物联网服务管理系统 |
| CN111651789B (zh) * | 2020-06-05 | 2023-04-14 | 北京明朝万达科技股份有限公司 | 一种基于扫描系统的多线程安全批量反馈的方法及装置 |
| CN112291207B (zh) * | 2020-10-16 | 2022-11-25 | 武汉中科通达高新技术股份有限公司 | 一种前端设备目录获取方法及装置 |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH01256248A (ja) * | 1988-04-06 | 1989-10-12 | Hitachi Ltd | 階層化プロトコル並列処理装置 |
| JPH09511105A (ja) * | 1993-12-24 | 1997-11-04 | ニューブリッジ ネットワークス コーポレイション | パケット系ネットワーク用探索エンジン |
| JP2001203691A (ja) * | 2000-01-19 | 2001-07-27 | Nec Corp | ネットワークトラフィック監視システム及びそれに用いる監視方法 |
| JP2002281086A (ja) * | 2001-03-19 | 2002-09-27 | Kddi Corp | トラヒック監視方法およびシステム |
| WO2005027539A2 (en) * | 2003-09-10 | 2005-03-24 | Fidelis Security Systems | High-performance network content analysis platform |
| JP2005513957A (ja) * | 2001-12-28 | 2005-05-12 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | ネットワークルーチング装置を自動的に構成する方法 |
Family Cites Families (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5101402A (en) * | 1988-05-24 | 1992-03-31 | Digital Equipment Corporation | Apparatus and method for realtime monitoring of network sessions in a local area network |
| US6263444B1 (en) * | 1997-03-11 | 2001-07-17 | National Aerospace Laboratory Of Science & Technology Agency | Network unauthorized access analysis method, network unauthorized access analysis apparatus utilizing the method, and computer-readable recording medium having network unauthorized access analysis program recorded thereon |
| US7284070B2 (en) * | 1997-10-14 | 2007-10-16 | Alacritech, Inc. | TCP offload network interface device |
| US7263558B1 (en) * | 1999-09-15 | 2007-08-28 | Narus, Inc. | Method and apparatus for providing additional information in response to an application server request |
| SG143052A1 (en) * | 2000-05-12 | 2008-06-27 | Niksun Inc | Security camera for a network |
| US7362707B2 (en) * | 2001-07-23 | 2008-04-22 | Acme Packet, Inc. | System and method for determining flow quality statistics for real-time transport protocol data flows |
| US7650634B2 (en) * | 2002-02-08 | 2010-01-19 | Juniper Networks, Inc. | Intelligent integrated network security device |
| US20030196081A1 (en) * | 2002-04-11 | 2003-10-16 | Raymond Savarda | Methods, systems, and computer program products for processing a packet-object using multiple pipelined processing modules |
| US7885803B2 (en) * | 2003-05-28 | 2011-02-08 | Alcatel-Lucent Usa Inc. | System and method for simulating traffic loads in packetized communication networks |
| GB2402845A (en) * | 2003-06-14 | 2004-12-15 | Agilent Technologies Inc | Service usage records for mobile data communications |
| US7463590B2 (en) * | 2003-07-25 | 2008-12-09 | Reflex Security, Inc. | System and method for threat detection and response |
| US7535851B2 (en) * | 2003-08-26 | 2009-05-19 | Finisar Corporation | Discovering diagnostic port functionality in a distributed system |
| US20050141430A1 (en) * | 2003-12-30 | 2005-06-30 | Borkowski Nancy S. | Monitoring network information |
| WO2005071923A1 (en) * | 2004-01-20 | 2005-08-04 | Intrusic, Inc | Systems and methods for monitoring data transmissions to detect a compromised network |
| US7660248B1 (en) * | 2004-01-23 | 2010-02-09 | Duffield Nicholas G | Statistical, signature-based approach to IP traffic classification |
| EP1716668B1 (en) * | 2004-01-27 | 2010-08-11 | Actix Limited | Monitoring system for a mobile communication network for traffic analysis using a hierarchical approach |
| US7594011B2 (en) * | 2004-02-10 | 2009-09-22 | Narus, Inc. | Network traffic monitoring for search popularity analysis |
| US7379930B2 (en) * | 2004-02-25 | 2008-05-27 | Ricoh Company, Ltd. | Confidential communications executing multifunctional product |
-
2006
- 2006-06-23 DE DE602006014667T patent/DE602006014667D1/de active Active
- 2006-06-23 EP EP06253291A patent/EP1871038B1/en not_active Expired - Fee Related
-
2007
- 2007-06-20 US US11/821,534 patent/US8144609B2/en not_active Expired - Fee Related
- 2007-06-22 JP JP2007165587A patent/JP5167501B2/ja not_active Expired - Fee Related
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH01256248A (ja) * | 1988-04-06 | 1989-10-12 | Hitachi Ltd | 階層化プロトコル並列処理装置 |
| JPH09511105A (ja) * | 1993-12-24 | 1997-11-04 | ニューブリッジ ネットワークス コーポレイション | パケット系ネットワーク用探索エンジン |
| JP2001203691A (ja) * | 2000-01-19 | 2001-07-27 | Nec Corp | ネットワークトラフィック監視システム及びそれに用いる監視方法 |
| JP2002281086A (ja) * | 2001-03-19 | 2002-09-27 | Kddi Corp | トラヒック監視方法およびシステム |
| JP2005513957A (ja) * | 2001-12-28 | 2005-05-12 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | ネットワークルーチング装置を自動的に構成する方法 |
| WO2005027539A2 (en) * | 2003-09-10 | 2005-03-24 | Fidelis Security Systems | High-performance network content analysis platform |
| JP2007507763A (ja) * | 2003-09-10 | 2007-03-29 | フィデリス・セキュリティー・システムズ | 高性能のネットワーク内容解析プラットフォーム |
Also Published As
| Publication number | Publication date |
|---|---|
| US8144609B2 (en) | 2012-03-27 |
| JP5167501B2 (ja) | 2013-03-21 |
| EP1871038B1 (en) | 2010-06-02 |
| DE602006014667D1 (de) | 2010-07-15 |
| EP1871038A1 (en) | 2007-12-26 |
| US20080002595A1 (en) | 2008-01-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5167501B2 (ja) | ネットワーク監視システムとその動作方法 | |
| CN108400909B (zh) | 一种流量统计方法、装置、终端设备和存储介质 | |
| US20200228433A1 (en) | Computer-readable recording medium including monitoring program, programmable device, and monitoring method | |
| US9876701B1 (en) | Arrangement for efficient search and retrieval of indexes used to locate captured packets | |
| Moore et al. | Architecture of a network monitor | |
| US10691748B2 (en) | Methods and apparatus to process call packets collected in a communications network | |
| US20120182891A1 (en) | Packet analysis system and method using hadoop based parallel computation | |
| US9210090B1 (en) | Efficient storage and flexible retrieval of full packets captured from network traffic | |
| US9838454B2 (en) | Policy-based payload delivery for transport protocols | |
| US9356844B2 (en) | Efficient application recognition in network traffic | |
| JP2009510815A (ja) | サーチ前のパケットのリアセンブル方法及びシステム | |
| JP2004172917A (ja) | パケット検索装置及びそれに用いるパケット処理検索方法並びにそのプログラム | |
| Kim et al. | ONTAS: Flexible and scalable online network traffic anonymization system | |
| Vormayr et al. | Why are my flows different? a tutorial on flow exporters | |
| US10965600B2 (en) | Metadata extraction | |
| Plagemann et al. | Using data stream management systems for traffic analysis–a case study– | |
| US20090074008A1 (en) | Multiple packet UDP data transfers | |
| JP2006338415A (ja) | データベースシステムに接続せずにデータベースシステムをモニタリングする方法 | |
| Get’man et al. | Data representation model for in-depth analysis of network traffic | |
| WO2024105892A1 (ja) | 変換装置、変換方法及び変換プログラム | |
| CN116192463B (zh) | 一种数据过滤方法、装置、电子设备及存储介质 | |
| Hall | Multi-layer network monitoring and analysis | |
| Lhotka | Deliverable DJ2. 2.2 v1: User and Test Report on the Netflow Probe | |
| Chitpinityon et al. | Achieving 100 Gb/s URL filtering with cots multi-core systems | |
| Chen et al. | Research on network business identification technology based on IP packets |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20100608 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20110930 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20120313 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20120514 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20120828 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20121029 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20121113 |
|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A711 Effective date: 20121203 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20121203 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20121203 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 5167501 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20160111 Year of fee payment: 3 |
|
| R154 | Certificate of patent or utility model (reissue) |
Free format text: JAPANESE INTERMEDIATE CODE: R154 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |