(57)【特許請求の範囲】
【請求項１】
コンピュータネットワーク上の接続点を通過するすべてのパケットを検査するパケット・モニタであって：
（ａ）前記接続点に結合され、前記接続点を通過するパケットを受領するよう構成されたパケット捕捉装置；
（ｂ）前記パケット捕捉装置に結合され、受領されたパケットの選択された部分を抽出し、前記選択された部分の少なくとも一部の識別関数を出力するよう構成されたパーサ・サブシステムであって、前記パーサ・サブシステムの動作は前記パケットが従うプロトコルの一つまたは複数に依存する、パーサ・サブシステム；
（ｃ）受領されたパケットが属しうる以前遭遇した会話フローのゼロ個以上のフローエントリを含むデータベースを格納するメモリであって、会話フローはパケットの一つまたは複数のシーケンスを含み、フローエントリは、以前に遭遇した会話フローの認識状態を含む、メモリ；
（ｄ）前記パケット捕捉装置に結合され、前記識別関数を使って受領されたパケットが前記フローエントリ・データベース中にフローエントリがある会話フローに属するかどうかを探索し、受領されたパケットがフローエントリがある会話フローに属する場合、受領されたパケットについてのフローの認識状態を得るよう構成された探索エンジン；
（ｅ）前記探索エンジンに結合され、受領されたパケットが前記フローエントリ・データベースにフローエントリをもつ以前に遭遇した会話フローに属さない場合、受領されたパケットについての新たなフローについて前記フローエントリ・データベースに新規フローエントリを記憶するよう構成された状態記憶機構であって前記新規フローエントリは前記新たなフローの初期状態および前記新たなフローの識別情報を含み、
（ｆ）前記探索エンジンおよび前記状態決定機構に結合され、前記パケットが既存のフローからである場合には前記フローの最後に遭遇した状態から始めて前記フローの状態について指定されている任意の状態動作を実行し、前記パケットがすでに遭遇した会話フローからのものでない場合には前記新規フローの前記初期状態について要求される任意の状態動作を実行するよう構成された状態プロセッサ、とを有しており、
前記状態プロセッサが実行するよう構成されている可能な状態動作の組は、受け付けられたパケットにおける一つまたは複数のパターンを検索することを含む、
パケット・モニタ。
【請求項２】
請求項１記載のパケット・モニタであって、前記パケット捕捉装置、前記状態プロセッサおよび前記探索エンジンに結合されたバッファをさらに有し、前記バッファは、受領されたパケットの少なくとも選択された部分を受け入れるよう構成されており、
前記状態プロセッサは、前記パケットの開始範囲内の未知の位置で始めて、前記パケットにおける第１参照ストリングを検索するよう構成された探索装置を含む、
パケット・モニタ。
【請求項３】
請求項２記載のパケット・モニタであって、
前記第１参照ストリングはＮＲ個のユニットを有し、前記探索装置は前記パケット内の一組の開始位置のうちの任意のものからの前記第１参照ストリングを含む前記パケットの内容中の一組の参照ストリングの任意のものを検索するよう構成されており、前記探索装置は、第１参照ストリングの前記ＮＲ個のユニットを受信するよう構成された第１参照レジスタ；
直列に結合され前記パケットからのパケットデータを受信する１つ以上のターゲットデータレジスタ；および
第１の複数の比較器群であって、前記開始点の各々に一つの比較器群が対応し、特定の開始位置からの比較器群は、前記第１参照レジスタの各ユニットと前記特定の開始位置から始まる前記ターゲットデータレジスタのＮＲ個のユニットとに結合され、前記第１参照レジスタ内容と、前記特定の開始位置から始まる前記ターゲットデータレジスタのＮＲ個の連続するユニットの対応する内容とを比較する第１の複数の比較器群；
を有し、各比較器群は対応する異なる開始位置から始まる前記ターゲットデータの中で前記第１参照ストリングの一致の有無を示すよう動作し，前記第１の複数の比較器群は、前記開始位置のうちの任意のもので始まる前記ターゲットデータレジスタ内に前記第１参照ストリングが含まれているか否かを並列に示すよう動作する、
パケット・モニタ。
【請求項４】
１組の可能な開始位置が、Nstart個の位置を含み、前記１つ以上のターゲットデータレジスタが前記パケットデータの少なくともＮＲ＋Nstart−１個のユニットを受信するよう直列に結合され、前記第１の複数の比較器群が、Nstart個の開始位置各々について１つの比較器群でNstart個の比較器群を含む請求項３記載のパケット・モニタ。
【請求項５】
NRは１６バイトであり、前記ターゲットデータレジスタの各々はNstartバイトをもち、前記探索装置は第一のターゲットデータレジスタ内の任意のところで始まるマッチを示すよう動作する、請求項３または４記載のパケット・モニタ。
【請求項６】
前記ターゲットデータレジスタの各々は、データのNstart個のユニットを保持する請求項３ないし５のうちいずれか一項記載のパケット・モニタ。
【請求項７】
前記パケットデータのNstart個のユニットが前記ターゲットデータレジスタ内に１クロックサイクルでクロック入力されるように前記ターゲットデータレジスタが動作し、前記第１の複数の比較器群は、前記第１参照ストリングが、Nstart個の開始位置の何れかにおいて開始する前記パケット中にあるか否かを１クロックサイクルで示すよう動作する、請求項４記載のパケット・モニタ。
【請求項８】
前記探索装置がオフセットNoffsetを特定するための手段を有し、第１の動作クロックサイクルの間は前記第１のNoffset個の開始位置が無視され、前記第１の複数の比較器群は、前記第１参照ストリングが、最初のNoffset個の開始位置の後に始まる前記第１データレジスタのNstart−Noffset個の開始位置のいずれかで始まるパケット領域中にあるか否かを、前記第１クロックサイクルで示し、以後のクロックサイクルにおいて総てのNstart個の開始位置が処理され、１つ以上のクロックサイクルにおいて、前記探索装置が、最初のNoffset個のユニット以外の任意の場所で始まるパケットデータ中に前記第１参照ストリングがあるか否かを示すよう動作する、請求項５記載のパケット・モニタ。
【請求項９】
１つ以上の更なる参照ストリングのＮＲ個のユニットを受信する１つ以上の更なる参照レジスタ；および
1つ以上の更なる複数の比較器群であって、対応する複数の開始位置のそれぞれについて一つの比較器群があり、前記更なる複数のうちの各特定の比較器群が、対応する更なる参照レジスタの各ユニットと前記特定の比較器群の開始位置から始まる前記データレジスタのＮＲ個のユニットとに結合され、対応する更なる参照レジスタ内容と、前記特定の比較器群の開始位置から始まる前記ターゲットデータレジスタのＮＲ個ユニットとを比較する1つ以上の更なる複数の比較器群；
を更に有し、前記探索装置が、前記開始位置のうち任意のものから始まる前記ターゲットデータレジスタの内容中において、ＮＲ個のユニットの前記第１又は更なる参照ストリングのうちの任意のものを探索するよう動作する、請求項３ないし６のうちいずれか一項記載のパケット・モニタ。
【請求項１０】
各比較器群がＮＲ個の隣接する比較器を有し、各比較器は参照ユニット入力、パケットデータユニット入力および一致を示す出力を有し、前記参照およびターゲットデータ入力が一致し先行する比較器の出力が一致を示す場合に比較器の出力がアサートされるように、各比較器は先行する比較器の出力に結合される請求項３ないし９のうちいずれか一項記載のパケット・モニタ。
【請求項１１】
各比較器群はＮＲ個の隣接する比較器を有し、各比較器は参照ユニット入力、パケットデータユニット入力、イネーブル入力および一致を示す出力を有し、前記参照およびパケットデータ入力が一致し前記イネーブル入力がアサートされる場合に比較器の出力がアサートされ、
特定の開始位置に関する特定の比較器群に対して、隣接する比較器の参照入力が前記参照レジスタの隣接するユニットに結合され、隣接する比較器のパケットデータ入力が、特定の開始位置から始まるターゲットデータレジスタの隣接するユニットに結合され、その比較器群の第1の比較器がイネーブルされ、各比較器のイネーブル入力が先行する比較器の出力に結合され、参照ストリングのＮＲ個のユニットおよび前記パケットデータのＮＲ個のユニットが合致する場合に、最後の比較器の出力がアサートされる請求項３ないし９のうちいずれか一項記載のパケット・モニタ。
【請求項１２】
前記複数の比較器群の最後の比較器出力が、前記パケット中に前記参照ストリングの一致が生じたか否かおよびその場所を示す出力を有する優先選択器に結合される請求項１１記載のパケット・モニタ。
【請求項１３】
前記ユニットがバイトである請求項３ないし１２のうちいずれか一項記載のパケット・モニタ。
【請求項１４】
ＮＲが１６バイトである請求項３ないし１３のうちいずれか一項記載のパケット・モニタ。
【請求項１５】
請求項２記載のパケット・モニタであって、前記探索装置がパケットデータ内でＮＲ個のユニットからなる参照ストリングを探索するよう構成されており、前記探索装置が：
入力のＮＲ個の対と、前記入力のＮＲ個の対の各対の一致を示す出力とを有する第１のＮＲユニット比較器；
前記参照ストリングの値を示し行列の第１の軸を定めるＮＲ個の参照ストリング接続部と、前記パケットデータの値を示し前記第１の軸に垂直な行列の第２の軸を定める、前記パケットデータの第１の開始位置から始まり終了位置で終了するＮＲ個のターゲットデータ接続部；
を有し、前記パケットデータのＮＲ個のターゲットデータ接続部が、前記ＮＲ個の参照ストリングの接続部と比較されるように、前記第１の比較器が前記行列の対角線に沿って並べられる、
パケット・モニタ。
【請求項１６】
前記探索装置が、前記行列における前記ターゲットデータ接続部に平行に且つ隣接して、且つ前記終了位置から始まる１つ以上の付加的な接続部；および
前記付加的な接続部の各々について及びそれらに対応する付加的なＮＲユニット比較器であって、各付加的な比較器は前記第１比較器に平行であり且つ前記行列の中で前記付加的な接続部に向けてシフトされる付加的なＮＲユニット比較器；
を有し、各付加的な比較器が、前記参照ストリングを、異なる開始点から始まる前記ターゲットデータのＮＲ個のユニットの連続する値の異なる組と比較する請求項１５記載のパケット・モニタ。
【請求項１７】
前記探索装置が、１つ以上の更なるＮＲユニット比較器群；および
前記更なるＮＲユニット比較器群に対応する更なる接続部群であって、前記更なる接続部が１つ以上の付加的な行列を定め、前記第１軸に沿う更なる接続部群の各々が、前記第１の軸に沿う１つ以上の対応する更なる参照ストリングの値を示し、ＮＲ個の接続部が前記第２の軸に沿う前記ターゲットデータの値を示す、更なる接続部群；
を有し、付加的な比較器群の各々が、前記参照ストリングのうち対応するものと、異なる開始位置から始まる前記ターゲットデータのＮＲ個の隣接する値の異なる組を比較する請求項１５または１６記載のパケット・モニタ。
【請求項１８】
前記状態プロセッサは、前記接続点を通過するすべてのパケットの内容をリアルタイムで処理するよう構成されている、請求項１ないし１７のうちいずれか一項記載のパケット・モニタ。
【請求項１９】
前記状態プロセッサがプログラム可能である、請求項１ないし１８のうちいずれか一項記載のパケット・モニタ。
【請求項２０】
前記状態プロセッサに結合された状態パターン／動作メモリをさらに有し、前記状態パターン／動作メモリが状態パターンおよび／または状態動作のデータベースを記憶するよう構成されている、請求項１ないし１９のうちいずれか一項記載のパケット・モニタ。
【発明の詳細な説明】
【技術分野】
【０００１】
［発明の分野］
本発明は、コンピュータ・ネットワークに関し、特に、データ・ネットワーク内で通信されるパケットのリアル・タイムにおける明確化に関し、プロトコルおよびアプリケーション・プログラムに従う分類を包含する。
【０００２】
［関連出願の相互参照］
本願は、本発明の譲受人であるＡＰＰＴＩＴＵＤＥ，Ｉｎｃ．に譲渡された１９９９年６月３０日に出願された“METHOD  AND  APPARATUS  FOR  MONITORING  TRAFFIC  IN  A  NETWORK”と題する発明者Ｄｉｅｔｚ等による米国仮特許出願番号６０／１４１，９０３に関連する。
【０００３】
［著作権に関する記述］
本件特許書類の明細書の部分は著作物的保護を受けるものを包含する。著作権者は、特許商標庁の特許ファイル又は記録において行われるような特許書類または特許明細書に関する他人による複写再生について異議を唱えないが、他の場合については著作権に関するいかなる権利をも留保するものとする。
【背景技術】
【０００４】
［本発明の背景］
ネットワーク活動監視に関する必要性が従来から切望されている。しかしながら、この要請は、最近普及しているインターネットおよび他のインターネットによって特に切望されるようになっている――「インターネット」は複数の相互接続されたネットワークであり、より大きな単独のネットワークを形成するものである。ネットワーク上で１つ又はそれ以上のサーバからサービスを受けるクライアントの集合として使用されるネットワークの成長とともに、それらサービスの利用を監視（モニタ）することおよびそれらを評価することが可能であることが一層重要である。例えばどのサービス（すなわちアプリケーション・プログラム）が利用されているか、誰がそれらを使用しているか、どの程度の頻度でアクセスされているかおよびどの程度の期間であるかのような客観的情報は、これらのネットワークの保守および継続的動作において非常に重要である。特に、リアル・タイムでネットワーク利用に関する報告を作成するために、選択されたユーザが遠隔的にネットワークにアクセスすることが可能であることが重要である。同様に、リアル・タイムのネットワーク監視の要請も存在し、これは、選択されたユーザに対して、ネットワークまたはサイトに生じた問題を報知する警告を提供することができるものである。
【０００５】
ある従来の監視方法は、ログ・ファイルを使用する。この方法では、選択されたネットワーク活動は、ログ・ファイルを参照することによって回顧的に分析することが可能であり、それらはネットワーク・サーバまたはゲートウエイによって維持される。ログ・ファイル監視は、サーバまたはゲートウエイに関する統計値を判定するために、そのデータにアクセスし（「自身の」）その内容にアクセスしなければならない。しかしながらこの手法にはいくつかの問題がある。先ず、ログ・ファイル情報はリアル・タイムの使用に役立つ地図を提供しない；第２に、ログ・ファイル探索は完全な情報を提供しない。この方法は、多数のネットワーク装置およびサーバにより維持されるログに基づいており、これは、その情報が精錬(refining)および相互作用に委ねられる必要がある。また、いくつかの情報は、ログ・ファイル入力を形成するために、ゲートウエイ又はサーバに対して単純に利用可能なものではない。
【０００６】
例えばそのような場合は、NetMeeting（登録商標）(ワシントン州レッドモンドのマイクロソフト・コーポレーション)の会議に関する情報であり、２つのコンピュータがネットワーク上で直接的に接続され、そのデータをサーバ又はゲートウエイから決して覗くことができないものである。
【０００７】
ログ・ファイルを形成することの他の欠点は、そのプロセスが、イネーブルされるネットワーク素子のデータ・ログ特性を必要とし、その装置における実質的な負荷を与え、ネットワーク・パフォーマンスの低下を招く。さらに、ログ・ファイルは急速に大きくなり、それらを格納する標準的な手段はなく、大量の保守を必要とする。
【０００８】
Netflow
【外１】
【０００９】
0005517821.tif 000002
（カリフォルニア州サンノゼのシスコ・システムズ，インコーポレーテッド），ＲＭＯＮ２および他のネットワークは、ネットワークのリアル・タイム監視に利用可能であるが、アプリケーション内容の可視性に欠如し、ネットワーク階層レベルの情報提供が制約される。
【００１０】
パケットが分析されパターン・フィルタが適用されるパターン・マッチング・パーサ技術(pattern-matching  parser  technique)も知られているが、これらも、パケットを検査することが可能なプロトコル・スタック内の深度(deep)がどの程度であるかについて制約を受ける。
【００１１】
いくつかの従来のパケット監視は、パケットを接続フローに分類する。用語「接続フロー」は、単独の接続を含む総てのパケットを記述するために一般に使用される。他方、会話フロー(conversational  flow)は、例えばクライアントによって要求されるサーバにおけるアプリケーションの実行のような活動の結果として、ある方向に交換される一連のパケットである。接続フローだけでなく、会話フローを識別して分類することが望まれる。その理由は、ある会話フローは１以上の接続を含み、あるものはクライアントおよびサーバの間で１以上のパケット交換(exchange)をも含むためである。これは、ＲＰＣ，ＤＣＯＭＰおよびＳＡＰのようなクライアント／サーバ・プロトコルを利用する場合に特に顕著であり、これらは、任意のサービスの利用に先立ってそのサービスの設定および定義を可能にするものである。
【００１２】
そのような場合の例は、サービス広告プロトコル(SAP:  Service  Advertising  Protocol)、サービスおよびネットワークに付随するサービスのアドレスを識別するために使用されるネットウエア（ユタ州プロボのノベル・システムズ）プロトコルである。当初の交換では、クライアントはＳＡＰ要求を印刷サービス用のサーバへ送る。その後サーバは、サーバ上の印刷サービスとしての特定のアドレス例えばＳＡＰ＃５を識別するＳＡＰ返答を送る。このような応答を利用して、例えばサーバ情報として知られるルータ内のテーブルを更新することができる。この返答を覗いたクライアントおよび（サービス情報テーブルを有するルータを介して）そのテーブルにアクセスしたクライアントは、この特定のサーバに関してＳＡＰ＃５が印刷サービスであることを知る。したがって、サーバ上でデータを印刷するために、そのようなクライアントは印刷サービスのための要求を要せず、ＳＡＰ＃５を特定して印刷すべきデータを単に送信すればよい。先の交換と同様に、印刷すべきデータの送信も、クライアントおよびサーバ間の交換を含むが、第２の接続を要し、したがって当初の交換とは独立である。分離した会話交換の可能性を除去するため、第１の交換を第２の交換に「仮想接続する」(virtually  concatenate)すなわちリンクすることが可能なネットワーク・パケット・モニタが望まれる。クライアントが同じであれば、２つのパケット交換は同一の会話フローの一部として正しく同一視される。
分離したフローを導出する他のプロトコルは、遠隔手順呼出(RPC:  Remote  Procedure  Call)；かつてネットワークＯＬＥと呼ばれていた分散要素オブジェクト・モデル(DCOM:  Distributed  Component  Object  Model)（ワシントン州レッドモンドのマイクロソフト・コーポレーション）；および共通オブジェクト要求ブローカ構造(CORBA:  Common  Object  Request  Broker  Architecture)を含む。ＲＰＣはサン・マイクロシステムズ（カリフォルニア州パロアルト）によるプログラム・インターフェースであり、あるプログラムが遠隔下装置内の他のプログラムを利用することを許容する。ＣＯＲＢＡに対するマイクロソフトのものであるＤＣＯＭは、遠隔的な呼出し手順を定め、それ自身がソフトウエア・モジュールに包含されるオブジェクトが、ネットワークを通じて遠隔的に実行されることを許容する。配信されるオブジェクト間で通信するオブジェクト管理グループからの規格であるＣＯＲＢＡは、ネットワーク内での存否によらず、異なるプラットフォームで走る異なるプログラミング言語で記述されたプログラム（オブジェクト）を実行する方法を提供する。
【００１３】
したがって、要請されるネットワーク監視は、重いトラフィックのネットワークにおける総てのユーザ・セッションを継続的に分析することを可能にするものである。そのような監視は、ネットワーク上の任意の点を通過する総ての情報の（すなわち、ネットワーク内の任意の場所を通過する総てのパケットおよびパケット・ストリームの）遠隔的な検出、特徴付け、分析および捕捉を妨害的でなく可能にするものである。総てのパケットが検出され分析されるだけでなく、これらのパケットの各々について、ネットワーク監視はプロトコル（例えば、http,  ftp,  H.323,  VPN等）、プロトコルにおけるアプリケーション／利用（例えば、音声、映像、データ、リアル・タイム・データ等）、および各アプリケーションまたはアプリケーション・コンテキスト(context)内でのエンド・ユーザの利用形態（例えば、選択されたオプション、配信されたサービス、持続期間、日時、要求されたデータ等）を判別する。また、ネットワーク・モニタは、ログ・ファイルのようなサーバ所有情報(server  resident  information)を当てにするべきではない。ネットワーク活動を客観的に測定および分析する手段は、ネットワーク管理者またはインターネット・サービス・プロバイダ（ＩＳＰ）のようなユーザが；収集され分析されたデータ形式を特別に仕立て上げ；リアル・タイム分析を請け負い；およびネットワークの問題の通知を適宜受信することを許容するものである。
【００１４】
先のＳＡＰの例を再考すると、本発明の１つの特徴は、そのサーバにおける印刷サービスに関連付けられた第２の交換を正しく識別し、クライアントが同一でなかった場合でさえもそのような交換が認識される。本発明の従来のネットワーク・モニタとの相違は、同一の会話フローに属する分離したフローを認識する能力を有する点である。
【００１５】
ネットワーク通信を監視する際のデータ値は、多くの発明によって認識されていた。Chiu,  et  al.は、“APPARATUS  AND  METHOD  FOR  REAL-TIME  MONITORING  OF  NETWORK  SESSIONS  AND  A  LOCAL  AREA  NETWORK”と題する米国特許第５，１０１，４０２号（以下、「４０２特許」という。）において、通信ネットワークにおけるセッション段階での情報を収集する方法を開示している。４０２特許は、特定の形式のパケットに対して固定的な位置を特定し、パケットのセッションを識別するための情報を抽出する。例えば、ＤＥＣネット・パケットが現れる場合、４０２特許は、パケットのセッションを識別するために、そのパケット内で６つのフィールド（６つの場所）で調査する。他方、ＩＰパケットが現れる場合、ＩＰパケットについて６つの異なる位置の異なる組が特定される。プロトコルが増加するにつれて、セッションを判別するために総ての可能な監視場所を明確に特定することは、ますます困難になる。同様に、新たなプロトコル又はアプリケーションを追加することも困難である。本発明では、検査された位置および任意のパケットから抽出された情報は、パケットの特定の形式に関するパケット内の情報に基づいて適応的に判定される。識別用署名(シグネチャ[signature])を形成するために何を見るかおよびどこを見るかの固定的な定義付けは存在しない。本発明のモニタの実現は、例えば、かつてのイーサーネット・タイプ２（又はバージョン２）ＤＩＸ（ディジタル・インテル・ゼロックス）パケットとは異なる仕方で、ＩＥＥＥ８０２．３パケットを取り扱うよう適応する。
【００１６】
４０２特許のシステムは、セッション層まで認識することが可能である。本発明では、任意の特定のプロトコルに関し、検査されるレベル数が変化する。更に、本発明は、要求されたレベルまで一意に特定するのに充分な任意のレベルまで検査することが可能であり、（ＯＳＩモデルでの）アプリケーション・レベルまでずっと検査することさえも可能である。
【００１７】
他の従来のシステムも知られている。Ｐｈａｅｌは、“NETWORK  MONITORING  DEVICE  AND  SYSTEM”と題する米国特許５，４１５，５８０においてランダムに選択されたパケットのみを処理するネットワーク活動モニタを開示する。Ｎａｋａｍｕｒａは、“MONITORING  SYSTEM  OF  NETWORK”と題する米国特許４，８９１，６３９においてネットワーク監視システムを教示する。Ｒｏｓｓ，ｅｔ  ａｌ．は、“METHOD  AND  APPARATUS  FOR  ANALYSIS  NETWORK”と題する米国特許５，２４７，５１７においてネットワーク活動を分析および監視する方法および装置を教示する。ＭｃＣｒｅｅｎｒｙ，ｅｔ  ａｌ．は、“APPARATUS  AND  METHOD  OF  ANALYZING  INTERNET  ACTIVITY”と題する米国特許５．７８７，２５２においてインターネット・プロトコル・レベル層でパケット・データをデコードするインターネット活動モニタを開示する。ＭｃＣｒｅｅｒｙの方法は、ＩＰパケットをデコードする。各パケットに関するデコード動作を通じて処理が進行し、認識前後の両者のフローについて処理オーバーヘッドを利用する。本発明のモニタのある実装においては、フロー毎に対して署名が設定され、そのフローの将来のパケットが容易に認識されるようにする。フロー内に新たなフローが到着すると、認識処理は最後に離脱した所から開始可能であり、フローの新たなパケットを認識するための新たな署名が形成される。
【００１８】
ネットワーク分析器は、多くの様々なプロトコルを解析することが可能である。ベース・レベルにおいて、ディジタル通信で使用される多くの規格が存在し、その規格は、イーサーネット，ＨＤＬＣ，ＩＳＤＮ，ラップＢ(Lap  B)，ＡＴＭ，Ｘ．２５，フレームリレー，ディジタル・データ・サービス，ファイバ配信データ・インターフェース(FDDI:  Fiber  Distributed  Data  Interface)，Ｔ１等を含む。これらの規格の多くは、異なるパケットおよび／またはフレーム・フォーマットを使用する。例えば、データはＡＴＭおよびフレーム・リレー・システムにおいては、５３オクテット（すなわち、バイト）の固定長パケット形式（「セル」と呼ばれる）で送信される。同じペイロード(payload)情報に関して他のプロトコルによって使用されるパケットにおいて、例えば、フレーム・リレー規格またはイーサーネット・プロトコルを利用する会話フローにおいて含まれうる情報を形成するために、いくつかのそのようなセルが必要である。
【００１９】
異なるパケットまたはフレーム・フォーマットを解析することの可能なネットワーク・モニタのために、そのモニタは、異なるプロトコルに従い異なるアプリケーションに関係する情報を搬送する各パケットに関して、プロトコル特有作業を実行することが可能である必要がある。例えば、そのモニタは、異なるフォーマットのパケットを、フィールドに分解し、それらの異なるフィールドに包含されるデータを理解することが可能である必要がある。可能なパケット・フォーマット又は形式の数が増加するにつれて、これら異なるパケット・フォーマットを分解するために必要な論理回路量も増加する。
【００２０】
従来存在したネットワーク・モニタは、個々のパケットを分解し、様々なフィールドにおける情報を捜し、パケットを識別するための署名を形成するために使用する。Ｃｈｉｕ等は、“APPRATUS  AND  METHOD  FOR  REAL-TIME  MONITORING  OF  NETWORK  SESSIONS  AND  A  LOCAL  AREA  NETWORK.”と題する米国特許５，１０１，４０２においてコンピュータ・ネットワークにおけるセッション・レベルでの情報収集方法を述べている。この特許では、特定形式のパケットに関して特定された固定位置が存在する。たとえば、ＤＥＣネット・パケットが現れる場合に、Ｃｈｉｕのシステムは、パケット内で６つの特定のフィールドにおいて（６つの位置で）監視し、パケットのセッションを識別する。他方、ＩＰパケットが現れる場合は、６つの位置の異なる組が検査される。このシステムは、プロトコル層までの最低レベルのみ監視する。次のレベルを特定した各フィールドに関する固定位置が存在する。プロトコルが増加すると、セッションを判定するための総ての可能な監視位置を明確に特定することは、一層困難になる。同様に、新たなプロトコル又はアプリケーションを追加することも困難になる。
【００２１】
特定形式のパケットについて、任意のパケットから抽出される位置および情報を適応的に判別することが望まれている。こうして、署名を形成するための探索対象および探索場所のプロトコルに依存し、パケット内容に依存した定義を利用して、最適な署名が決定される。
【００２２】
必要とされているネットワーク・モニタは、異なるプロトコル又は異なるアプリケーション・プログラムについて仕立てられる又は適合されることの可能なものである。また、新たなプロトコルおよび新たなアプリケーション・プログラムを受け入れることが可能なネットワーク監視も必要とされる。新たなプロトコル、および新たなアプリケーションを含む新しいレベルを特定する手段も必要とされる。プロトコル特有作業(protocol  specific  operation)を記述する機構も必要とされており、これは例えば、パケットに適切な情報が何であるかそしてデコードされる必要のあるパケットを含み、分解(parser)作業および抽出(extract)作業を特定することを含む。パケットに対して実行する状態作業を記述する機構も必要とされており、そのパケットはフローを更に認識するためにフロー認識の特定の状態におけるものである。
【００２３】
夫々のパケットを単にカウントするのではなく、ネットワーク内の節点を通るパケットの統計値を収集することは有利である。会話フローに関するフロー・エントリ(flow  entry)において統計的な測定値を維持することによって、本願実施例は、特定のメトリック(metric)がリアル・タイムで収集されることを可能にする。さもなくば不可能であろう。例えば、会話における各々の交換について、フロー全体に基づく双方向の会話に関連したメトリック（計量）を維持することが望まれる。フローの状態を維持することによって、本願実施例は、フローの状態に関連する所定のメトリックを決定可能にする。
【００２４】
統計的メトリックを利用する従来のネットワーク・トラフィク・モニタの多くは、端点およびセッションの終点に関連する統計値のみを収集する。このような従来使用されていたメトリックの例は、パケット数、バイト数、セッション接続時間、セッション休止時間〔タイムアウト〕、セッションおよび転送応答時間等を含む。これらの総ては、単独のパケットにおける事象に直接的に関連し得る事象を取り扱う。これら従来のシステムは、フローの諸パケットの完全なシーケンス又はネットワークにおける同一フローのいくつかの分離したシーケンスに関連するいくつかの重要なパフォーマンス・メトリックを収集することができない。
【００２５】
アプリケーション・データ・パケットについての時間基準メトリックは重要である。そのようなメトリックは、総てのタイムスタンプおよび関連するデータが格納され以降の分析のための転送される場合に、決定されることが可能である。しかしながら、高速ネットワークを通じて１秒あたり数千ないし数百万の会話に直面する場合、それら総てのデータを格納することはたとえ圧縮されるとしても、膨大な処理、メモリおよびダウンロード時間の管理となり、実用的でない。
【００２６】
したがって、フロー内のパケットから蓄積された統計測定値に基づく時間基準メトリックを維持および報告することが望まれている。
【００２７】
ネットワーク・データは、１サンプルとしてではなく母集団として適切にモデル化される。したがって総てのデータが処理されることを要する。アプリケーション・プロトコルの性質に起因して、いくつかのパケットの単なるサンプリングは、フローに関する良好な測定値を提供しない。データが伝送される追加的なポートまたはどのアプリケーションが実行されるかを指定するもののように、ほんの１つの重要なパケットが失われることで、有効なデータを喪失してしまう。
【００２８】
したがって、フローにおける全パケットから蓄積された統計的測定値に基づく時間基準メトリックを維持および報告することも望まれている。
【００２９】
一連の事象に関するメトリックを判別することも望まれている。その適切な例は、相対的なジッタ(relative  jitter)である。ある方向における１つのパケットの終点から、同一方向における同一署名を有する他のパケットまでの時間の測定は、通常のジッタに関するデータを収集する。この種のジッタ・メトリックは、パケット・ネットワークにおける広範な信号品質を測定するには良好である。しかし、パケットのクラスタにおいて転送されるペイロードまたはデータ項目に特異的ではない。
【００３０】
パケットがシステムに参入する際の高速性に起因して、本願実施例はキャッシュを利用する。キャッシュ・システムにおいてヒット率を最大化させることが望まれる。
【００３１】
典型的な従来のキャッシュ・システムは、マイクロプロセッサ・システムへおよびそこからのメモリ・アクセスを促進させるために使用される。このような従来のシステムにおいては、ヒット率を最大化させるように探索（ルックアップ）を予言する様々な機構が利用可能である。例えば従来のキャッシュは、命令キャッシュ探索およびデータ・キャッシュ探索の両者を予測するために、先取り機構(lookahead  mechanism)を利用することが可能である。このような先取り機構は、パケット監視アプリケーション用のキャッシュ・サブシステムには利用できない。新たなパケットがそのモニタに入ると、例えば探索エンジンからの次のキャッシュ・アクセスは、最後のキャッシュ探索のものと全く異なる会話フローに対するものであり、その次のパケットが所属するフローが何であるかを事前に知る術がない。
【００３２】
したがって、パケット・モニタでの使用に適したキャッシュ・サブシステムが当該技術分野で望まれている。このようなキャッシュ・システムの１つの好ましい特性は、キャッシュ置換が必要とされる場合に最も長く未使用であるフロー・エントリを置換するLRU(least  recently  used)置換方針である。最も長く未使用であるフロー・エントリを置換するのが好ましいのは、最近のパケットに続くパケットは、おそらく同一のフローに所属するであろうからである。したがって、新しいパケットの署名は最近使用したフロー・レコード（記録）に合致する可能性が高い。逆に、最も長く未使用であるフロー・エントリに関連するパケットが近いうちに到着する可能性は高くない。
【００３３】
しばしばハッシュ(hash)を利用して探索を促進させる。そのようなハッシュは諸エントリをデータベース内でランダムに拡散させうる。この場合、連想式の(associative)キャッシュが好ましい。
【００３４】
ＬＲＵ置換方針を含む連想式のキャッシュ・システムが望まれている。
【００３５】
パケット・モニタがフローの状態を維持すること、およびフローに関連するアプリケーション・プログラムを判定するプロセスを先に進めるために必要な任意の状態処理を実行することが好ましい。したがって、アプリケーションごとにそれらを分類するために新規および既存のフロー両者を分析する状態プロセッサが望まれている。
【００３６】
状態プロセッサに求められる一般的動作の１つは、１組の既知のストリングのうちの１つの存在に関してパケット内容を探索することである。そのような識別は、会話フローのアプリケーション内容を識別するプロセスを先に進めるために有用でありうる。例えば、ｈｔｔｐプロトコルに関連するパケットのユニフォーム資源ロケータ(URL:  uniform  resource  locator)を探索することが好ましいことがありうる。あるいは、プロトコル又はプロトコルの諸側面を識別する特定のストリング(string)を探索する必要がある場合があり、例えばそのストリングは、“port”,  “get”,  “post”等を含む。これらのストリングはパケット内にあり、ストリングの種類およびストリングが所属するパケット内の場所はしばしば未知である。
【００３７】
多くの一般的な処理システムでは、実装される１組の命令は汎用的な性質を有する。総ての処理システムは、命令およびプログラム・カウンタの分析および取り扱いに関する典型的な命令セットを有する。これらの命令は、ジャンプ(Jump)、コール(Call)およびリターン(Return)を含む。さらに、これら同一の処理システムは、レジスタおよびメモリ・ロケーションを分析および取り扱うための適切な命令を有する。これらの命令は、インクリメント(Increment)、デクリメント(Decrement)、移動(Move)、比較(Compare)および論理的演算(Logical  manipulation)を含む。
【００３８】
状態プロセッサは、そのような基本的な標準命令セットを有するが、そのような標準的な命令セットを利用して、目標データ・ストリーム内の１つ又はそれ以上の既知のストリングの探索を実行することは、極めて長時間を要し、高速のパケット到着に対応できなくなることがありうる。したがって、いくつかの特定の探索機能を実行することの可能なプロセッサを有することが望ましく、その探索機能は、非常に高速にネットワークにおけるパケットの内容およびその中のデータを評価するために要求されるものである。
【００３９】
特に、状態プロセッサの一部とすることが可能であって、特定された参照ストリングを探して目標データ・ストリームを高速に探索することの可能な探索装置が望まれている。更に、そのような探索を実行する探索装置を動作させる命令を取り扱うプログラム可能なプロセッサが望まれている。
【００４０】
ネットワーク・モニタにおいてそのようなプロセッサを利用すると、そのモニタがスケーリング可能になり、任意のネットワーク速度要請に対して対応可能になる。
【発明の概要】
【発明が解決しようとする課題】
【００４１】
［要約］
様々な実施例において、本発明は以下の目的および利点の１つ又はそれ以上を達成し得るネットワーク・モニタを提供する。
【００４２】
・クライアントおよびサーバの間で交換する総てのパケットを認識し、各自のクライアント／サーバ・アプリケーションに分類すること。
【００４３】
・総てのプロトコル階層において、ネットワーク内の任意の地点を方向を問わず通過する会話フローを認識および分類すること。
【００４４】
・ネットワークを通じて交換される個々のパケットに従って、クライアントおよびサーバ間の接続およびフロー進行を判定すること。
【００４５】
・ネットワーク資源を要求する現在の混合したクライアント／サーバ・アプリケーションに従って、ネットワークの実行性〔パフォーマンス〕の調整を支援すること。
【００４６】
・ネットワーク資源を利用して、混合したクライアント／サーバ・アプリケーションに対して適切な統計値を維持すること。
【００４７】
・クライアント／サーバ・ネットワーク会話フローに対する特定のアプリケーションによって使用されるパケットの特殊なシーケンスの発生を報告すること。
【００４８】
本発明の実施形態の他の側面は次のとおり。
・クライアントおよびサーバ間で交換されたパケットの各々を適切に分析し、会話フローの各々の現在の状態に適切な情報を維持すること。
【００４９】
・新たなアプリケーションがクライアント／サーバ・マーケットに参入するにつれて仕立てる又は適合させることが可能な柔軟な処理システムを提供すること。
【００５０】
・個々のアプリケーションによって分類されるようなクライアント／サーバ・ネットワークにおける会話フローに適切な統計値を維持すること。
【００５１】
・特定の識別子を報告すること。その識別子は、特定のクライアント／サーバ・ネットワーク会話フローに関して、特定のアプリケーションを利用して一連のパケットを識別するために他のネットワーク用の装置で使用されうる。
【００５２】
概して本発明の実施例は従来の問題点および欠点を克服するものである。
【課題を解決するための手段】
【００５３】
以下に説明するように、一実施例は、方向を問わずネットワークの任意の地点を通過するパケットの各々を分析し、クライアントおよびサーバ間で通信するために使用する実際のアプリケーションを導出する。ネットワークを通じて実行するいくつかの同時に並存する重複したアプリケーションであって、独立して非同期であるものが存在し得る。
【００５４】
本願実施例のモニタは、それらがネットワーク上で見受けられるように個々のパケットの各々を良好に分類する。パケットの内容は分解され、選択された部分は署名（キーとも呼ばれる）に組み立てられ、署名は、同一の会話フローの更なるパケットを識別し、例えば更にフローを分析し、最終的にはアプリケーション・プログラムを認識するために使用されうる。キーは選択された部分の関数（ファンクション）であり、好適実施例では、その関数は選択された部分の結合したもの〔連結〕である。好適実施例は、任意の会話フローの状態を形成および記憶し、該状態は、ネットワークを通じて個々のパケットおよび会話フロー全体の間の関係によって決定される。この手法におけるフローの状態を記憶することによって、本実施例は会話フローのコンテキストを判別し、その判別されるコンテキストには、関連するアプリケーション・プログラムおよび時間のようなパラメータ、会話フローの長さ、データ・レート等が含まれる。
【００５５】
モニタには柔軟性があり、クライアント／サーバ・ネットワークに関して開発された将来のアプリケーションに適合し得る。新しいプロトコルおよびプロトコルの組み合わせは、高レベルのプロトコル記述言語で書かれたファイルをコンパイルすることによって組み込ませることが可能である。
【００５６】
本願実施例のモニタは、用途特定集積回路（ＡＳＩＣ）またはフィールド・プログラム可能なゲート・アレイ（ＦＰＧＡ）で実現されるのが好ましい。一実施例では、モニタは、パケットからの署名を形成する分解サブシステムを有する。さらにモニタは、分解サブシステムからの署名を受信する分析サブシステムを有する。
【００５７】
メディア・アクセス・コントローラ（ＭＡＣ）、または分割および再構成モジュールのようなパケット捕捉装置は、モニタの分解サブシステムに対してパケットを提供するために使用される。
【００５８】
ハードウエア実現手段では、分解サブシステムは２つの部分を有し、それらはパターン分析および認識エンジン（ＰＲＥ）および抽出エンジン（スライサ）である。ＰＲＥは各パケットを解釈し、特に、パターン・データベースに従って各パケットにおける個々のフィールドを解釈する。
【００５９】
異なる層に存在し得る異なるプロトコルは、リンクされたノードの１つ又はそれ以上のツリーのノードと考えることができる。パケット形式はツリーのルートである。各プロトコルは、親ノードまたは端末ノードの何れかである。親ノードは、プロトコルを、より高位の階層レベルのものであることが可能である他のプロトコル（子プロトコル）に結合（リンク）する。例えばイーサーネット・パケット（ルート・ノード）はイーサー形式パケットであり――イーサー形式／バージョン２およびＤＩＸ（ディジタル・インテル・ゼロックス・パケット）とも呼ばれる――またはＩＥＥＥ８０３．２パケットである。ＩＥＥＥ８０２．３パケットについて続けると、子ノードの１つがＩＰプロトコルでありえ、そのＩＰプロトコルの子の１つがＴＣＰプロトコルでありうる。
【００６０】
パターン・データベースは、パケットの異なるヘッダおよびそれらの内容に関する記述、およびそれらがツリー内で異なるノードにどのように関連するかに関する記述を包含する。ＰＲＥは可能な限り遠くまでそのツリーをたどる。ノードがより深いレベルへのリンクを含まない場合、パターン・マッチングが完了したと宣言される。プロトコルはいくつかの親の子になり得る点に留意を要する。可能な親／子ツリーの各々に関して一意的なノードが生成されるならば、そのパターン・データベースは極めて大きくなってしまうであろう。本願ではその代わりに、子ノードが複数の親に関して共用され、パターン・データベースをコンパクトにする。
【００６１】
最後に、プロトコル認識のみが必要とされる場合には、ＰＲＥはそれ自身において使用されることもできる。
【００６２】
認識された各プロトコルについて、スライサはパケットから重要なパケット要素を抽出する。これらはそのパケットに関する署名（すなわち、キー）を形成する。スライサは、既知のフローのデータベースからのこの署名を有するフローを迅速に識別するためにハッシュをも生成することが好ましい。
【００６３】
パケットのフロー署名、ハッシュおよび少なくともペイロードの一部は、分析サブシステムに伝達される。ハードウエアの実施例において、分析サブシステムは、分解サブシステムからのパケットの部分を受信し、処理中の署名を格納する一体化フロー・キー・バッファ（ＵＦＫＢ）と、以前に遭遇した会話フローに関するフロー・レコードのデータベースを探索し、署名が既存のフローからのものであるか否かを判別する探索／更新エンジン（ＬＵＥ）と、状態処理を実行する状態プロセッサ（ＳＰ）と、新たなフローをフローのデータベースに挿入するフロー挿入および削除エンジン（ＦＩＤＥ）と、フローのデータベースを格納するメモリと、フロー・データベースを包含するメモリにアクセスする速度を向上させるキャッシュとを有する。ＬＵＥ，ＳＰおよびＦＩＤＥは総てＵＦＫＢに結合され、およびキャッシュに結合される。
【００６４】
一体化フロー・キー・バッファは、分析サブシステムにおける分析のために、パケットのフロー署名、ハッシュ、および少なくともペイロードの一部を包含する。パケット署名は、一体化フロー署名バッファに存在するが、クライアント／サーバ会話フローに含まれるパケットのアプリケーション・プログラム内容の識別性を更に明確にするために、多くの作業を実行することが可能である。分析サブシステムの特定のハードウエア実施例において、いくつかのフローが並列に処理され、並列に分析される総てのパケットからの複数のフロー署名は、１つのＵＦＫＢ内に維持されうる。
【００６５】
分解サブシステムからのパケットに対するパケット分析プロセスにおける第１ステップは、既知のパケット・フロー署名の現在のデータベースにおけるインスタンスを探索することである。探索／更新エンジン（ＬＵＥ）は、最初にハッシュを利用し、後にフロー署名を利用してこのタスクを実行する。この探索はキャッシュ内で実行され、キャッシュ内に一致する署名のフローがない場合は、探索エンジンはメモリ内のフロー・データベースからフローの抽出を試行する。以前に遭遇したフローに関するフロー・エントリは好ましくは状態情報を有し、これは状態プロセッサ内で使用され、その状態に関して定められた任意の動作を実行し、次の状態を判別する。典型的な状態動作（状態作業）（state  operation）は、ＵＦＫＢ内に格納されたパケットのペイロードにおける１つ又はそれ以上の既知の参照ストリングを探索することでありうる。
【００６６】
ＬＵＥによる探索処理が完了すると、このパケット・フロー署名に関して一体化フロー署名バッファ構造内に、既存のものか新規のものかを区別するフラグが設定される。既存のフローに関して、フロー・エントリはＬＵＥの計算要素によって更新され、１つまたはそれ以上のフローの統計的測定値を格納するために使用されるフロー・エントリ・データベースにおけるカウンタに値を加算する。カウンタは、フローについてのネットワーク利用メトリックを判定するために使用される。
【００６７】
パケット・フロー署名が探索された後であって、現在のフロー署名の内容がデータベース内におけるものであると、状態プロセッサはパケット・ペイロードの分析を開始することが可能であり、このパケットのアプリケーション・プログラム要素が何であるかを更に明確にする。状態プロセッサの正確な動作およびそれにより実行される機能は、会話フローのストリームにおける現在のパケット・シーケンスに依存して変化し得る。状態プロセッサは、同一のフロー署名とともに見られた以前のパケットから格納された次の論理動作へ移行する。このパケットに対して処理が必要な場合は、状態プロセッサは状態命令のデータベースからのその状態に関する命令を実行し、それ以上処理がなくなるまで又は処理を要する命令がなくなるまで続けられる。
【００６８】
好適実施例では、状態プロセッサ機能は、新たなアプリケーション・プログラムを分析し、ならびにそのようなアプリケーションを使うことから生じうる新たなパケットのシーケンスおよび状態を分析するようプログラム可能である。
【００６９】
特定のパケット・フロー署名に関する探索プロセスの間に、フローが、動作中のデータベースに挿入されることを要求される場合は、フロー挿入および削除エンジン（ＦＩＤＥ）が開始される。状態プロセッサはまた、新たなフロー署名を生成し、フロー挿入および削除エンジンに対して、新規項目としてデータベースに新規フローを加えることを命令することが可能である。
【００７０】
好適なハードウエア実施例では、ＬＵＥ、状態プロセッサおよびＦＩＤＥの各々は他の２つのエンジンには依存しないで動作する。
【００７１】
本発明の他の特徴は、フローに関するメトリックを収集することである。説明される状態プロセッサを利用すると、状態プロセッサは特定のデータ・ペイロードを探索することが可能であるので、説明される本願実施例のモニタは、特定のデータ・ペイロードに総てが関連する、フローにおけるパケット群に対して、同一のジッタ・メトリック(jitter  metric)を収集するようプログラムされることが可能である。このことは、本願システムが、１組のパケットに関連する特徴の形式に対して一層適切なメトリックを提供することを可能にする。概してこれは、ネットワークにおけるシステムの実行性を評価する場合に、単独のパケットに関するメトリックよりも好ましいものである。
【００７２】
特に、モニタ・システムは、会話フローの任意の状態におけるメトリックの任意の形式を維持するようプログラムされることが可能である。また、モニタは任意の地点においてその状態にプログラムされた実際の統計値を有し得る。これは、本実施例のモニタ・システムが、特定の状態またはパケットのシーケンスに関連するメトリックだけでなく、ネットワーク利用度および実行性に関連するメトリックを収集可能にする。
【００７３】
状態に関してのみ収集されることが可能である特定のメトリックのいくつかは、ある方向におけるトラフィックのグループに関連する事象（イベント）、一方向又は双方向の通信シーケンスの状態に関連する事象、特定のシーケンスにおける特定のアプリケーションに関するパケットの交換に関連する事象である。これは、１組のメトリックに対してフローの状態を関連させ得るエンジンを必要とするメトリックの僅かな例に過ぎない。
【００７４】
さらに、モニタは、会話フローにおける特定のアプリケーションに対するより大きな可視性を提供するので、モニタは、アプリケーション又はサービスの形式に特有なメトリックを収集するようプログラムされることが可能である。言い換えれば、フローが、オラクル・データベース・サーバ(Oracle  Database  server)に関するものである場合に、本願実施例のモニタは、ある処理を完了するために必要なパケット数を収集することが可能である。状態およびアプリケーション分類の両者に関してのみ、この種のメトリックがネットワークから導出され得る。
【００７５】
モニタは多様なメトリックの組を収集するようプログラムされることが可能であるので、システムは、多くの環境下で必要とされるメトリックのデータソースとして利用可能である。特に、メトリックを利用して、特定のアプリケーション群に関するトラフィック・フローの特徴および実行性を監視および分析し得る。他の実現手段では、特定のトラフィック・フローおよびトラフィック・フローに関する事象のための課金および返金に関するメトリックを包含することが可能である。更に他の実現手段では、問題解決および容量計画に有効であって関心のあるアプリケーションおよびサービスに直接的に関連するメトリックを提供するようプログラムされることが可能である。
【００７６】
本願の更なる特徴は、パケットの各々または総てに基づいてサービス・メトリックの特徴を判別することである。
【００７７】
コンピュータ・ネットワークにおける接続点を通過するパケットのフローを分析する方法および監視装置が開示され、サービス・メトリックのそのような特徴も分析される。この方法は、パケット捕捉装置からパケットを受信し、以前に遭遇した会話フローに関するフロー・エントリを含むフロー・エントリ・データベースを探索する。探索は、受信したパケットが既存のフローのものであるか否かを判別する。各々および総てのパケットが処理される。パケットが既存のフローのものである場合、本方法は、既存のフローのフロー・エントリを更新し、これにはフロー・エントリにおいて維持される１つ又はそれ以上の統計的測定値を格納することが含まれる。パケットが新規のフローである場合は、本方法は、フロー・エントリ・データベースにおいて新規のフローに関する新たなエントリを格納し、これにはフロー・エントリ内に維持される１つ又はそれ以上の統計的測定値を格納することが含まれる。統計的測定値はフローに関連するメトリックを決定するために使用される。メトリックは、ベース・メトリックとすることが可能であり、このベース・メトリックに基づいてサービス品質メトリックが判定され、あるいはこのベース・メトリックがサービス品質メトリックであってもよい。
【００７８】
外部メモリにおける１つ又はそれ以上の要素を探索する連想式キャッシュ・メモリも開示される。キャッシュ・システムは、外部メモリに結合される１組のキャッシュ・メモリ要素と、アドレスおよびキャッシュ・メモリ要素の１つに対するポインタを含む１組の内容アドレス・メモリ・セル（ＣＡＭ）とを有し、入力がＣＡＭセルにおけるアドレスと同一である場合にＣＡＭが一致出力をアサートするような入力を有する一致回路を有する。特定のＣＡＭが指示するキャッシュメモリ要素がどれであるかは、時間と共に変化する。好適実施例では、ＣＡＭは最上部から最下部への順序で接続され、最下部ＣＡＭは最も長く未使用であるキャッシュ・メモリ要素を指示する。
【００７９】
コンピュータ・ネットワークにおける接続点を通過するパケットの内容を処理するプロセッサも開示される。プロセッサは、パケットの内容における参照ストリングを探索するための１つ又はそれ以上の比較器を有する探索装置を有する。プロセッサは、その接続点を通過する総てのパケットの内容についてリアル・タイムで処理する。一実施例では、プロセッサはプログラム可能であって命令セットを有し、その命令セットは、パケットのある範囲内の未知の位置から開始するパケット中の特定の参照ストリングを探索することを、探索装置に要求する命令を含む。
【００８０】
プロセッサで使用され得る探索装置の実施例も開示される。探索装置は、ターゲット(target)データ内における１組の開始位置の内の１つから開始するターゲット・データにおいて、ＮＲユニットの参照ストリングを探索するよう構成される。探索装置は、参照ストリングのＮＲ個のユニットを受信するよう構成される参照レジスタと、ターゲット・データを受信するよう直列に結合された１つ又はそれ以上のターゲット・データ・レジスタと、複数の比較器群とを有し、１つの比較器群は開始位置の各々に対応する。特定の開始位置の比較器群は、参照レジスタの各ユニット、および該特定の開始位置から始まるターゲット・データ・レジスタのＮＲ個のユニットに結合され、参照レジスタの内容と、該特定の開始位置から始まるターゲット・データ・レジスタのＮＲ個の隣接するユニットの内の対応する内容とを比較する。各比較器群は、対応する様々な開始位置から始まるターゲット・データにおける第１参照ストリングの一致の有無を示す。第１の複数の比較器群は、任意の開始位置から始まるターゲット・データ・レジスタに第１参照ストリングが含まれるか否かを並列に示す。
【図面の簡単な説明】
【００８１】
【図１】本発明のネットワーク形態における機能ブロック図であり、接続点を通過するパケットを分析するためにモニタが接続されている。
【図２】いくつかのパケットおよびそれらのフォーマット例を表現する図であり、例示として、監視および分析されるネットワークにおいてクライアントおよびサーバの間の会話フローの開始時に交換されうるものである。この例および本願実施例に関する１対のフロー署名も図示されている。いくつかの可能なフロー署名を示し、これらはパケットを分析するプロセスにおいて、および分離したアプリケーション・パケット交換を生じる特定のサーバ・アプリケーションを認識するプロセスにおいて生成および使用されることが可能である。
【図３】図１に示すパケット・モニタとして動作することが可能な本発明のプロセス形態の機能ブロック図である。このプロセスは、ソフトウエア又はハードウエアで実装されることが可能である。
【図４】高レベルのプロトコル言語コンパイルおよび最適化プロセスのフローチャートであり、一例において、本発明の諸バージョンに従ってパケットを監視するためのデータを生成するために使用されうる。
【図５】本発明のパケット・モニタの実施例において分解装置〔パーサ〕の一部として使用されるパケット分解〔パース〕プロセスのフローチャートである。
【図６】本発明のパケット・モニタの実施例において分解装置の一部として使用されるパケット要素抽出プロセスのフローチャートである。
【図７】本発明のパケット・モニタの実施例において分解装置の一部として使用されるフロー署名形成プロセスのフローチャートである。
【図８】本発明のパケット・モニタの実施例において分析器の一部として使用されるモニタ探索および更新プロセスのフローチャートである。
【図９】本願パケット・モニタによって認識されうる例示的なサン・マイクロシステムズ遠隔手順呼出アプリケーションのフローチャート例である。
【図１０】パターン認識器および抽出器を含むハードウエア分解サブシステムの機能ブロック図であり、本発明のパケット・モニタの実施例における分解モジュールの一部を形成することが可能である。
【図１１】本発明のパケット・モニタの実施例の一部を形成することが可能な状態プロセッサを含むハードウエア分析器の機能ブロック図である。
【図１２】本発明のパケット・モニタの実施例における分析器の一部を形成することが可能なフロー挿入および削除プロセスの機能ブロック図である。
【図１３】本発明のパケット・モニタの実施例における分析器の一部を形成することが可能な状態処理プロセスのフローチャートである。
【図１４】図１に示すパケット・モニタとして動作することが可能な本発明のプロセス形態の機能ブロック図である。このプロセスは、ソフトウエアで実装されることが可能である。
【図１５】図３（および図１０，図１１）のパケット・モニタが、マイクロプロセッサのようなプロセッサを利用してネットワーク上でどのように動作するかを示す機能ブロック図である。
【図１６】本発明の一側面による署名を形成するために抽出されうるイーサーネット・パケットおよびいくつかの要素の上位層（ＭＡＣ）の例である。
【図１７Ａ】図１６のイーサーネット・パケットのイーサーネット形式のヘッダおよび本発明の一側面による署名を形成するために抽出されうるいくつかの要素の例である。
【図１７Ｂ】図１６および図１７Ａに示される例えばイーサー形式パケットのＩＰパケットおよび本発明の一側面による署名を形成するために抽出されうるいくつかの要素の例である。
【図１８Ａ】本発明の一実施例による分解システムで使用されるパターン、分解および抽出データベースの諸要素を格納するために使用可能な３次元構造である。
【図１８Ｂ】本発明の他の実施例による分解システムで使用されるパターン、分解および抽出データベースの諸要素を格納する他の形である。
【図１９】図１１の分析器サブシステムの状態プロセッサ要素のブロック図である。
【図２０】図１１の分析器サブシステムのサーチ・エンジン要素のブロック図である。
【図２１】サーチ・エンジンの個々の４つの探索モジュールのデータフロー・ブロック図である。
【図２２Ａ】サーチ・エンジン・コアのブロック図である。
【図２２Ｂ】複数の入力を他の複数の入力と比較するコアの比較要素を示す。
【図２３Ａ】入力コアの実装の詳細を示す。
【図２３Ｂ】コアの比較要素を示す。
【図２４】本願のコンパイル側面による図２０に図示されるようなコンパイル・プロセスによって共にコンパイルされる様々なＰＤＬファイル・モジュールを示す。
【図２５】本願のある側面による高レベルの言語ファイルをコンパイルするプロセスのフローチャートである。
【図２６】図１１の分析器サブシステムのキャッシュ・サブシステム１１１５のキャッシュ・メモリ部のブロック図である。
【図２７】キャッシュ・サブシステムのキャッシュ・メモリ・コントローラおよびキャッシュＣＡＭコントローラのブロック図である。
【図２８】キャッシュ・サブシステム１１１５のＣＡＭアレイの実現例のブロック図である。
【発明を実施するための形態】
【００８２】
［好適実施例の詳細な説明］
本発明は、詳細な好適実施例を参照することによって一層理解されるであろうが、特定の実施例に本発明を限定すべきではなく、それら実施例は説明目的のためにのみ供されている。各実施例は、添付図面と共に説明される。
本明細書は、ハードウエア図および信号名を含む記述を包含する。多くの場合においてそれらの名称は充分に説明的であるが、しかしながらそうでない場合は、本願の動作および実践を理解するためには信号名は必ずしも必要でない。
【００８３】
［ネットワークにおける動作］
図１は、全体的な参照番号１００で参照される本発明によるシステム例を表現する。システム１００は、様々なコンピュータ間でパケット（例えばＩＰデータグラム(datagram)）を通信するコンピュータ・ネットワーク１０２を有し、例えばクライアント１０４−１０７およびサーバ１１０，１１２の間で行われる。このネットワークは概略的に示され、いくつかのネットワークノードを雲として表現し、その雲の内側にリンクが示される。モニタ１０８は、本発明の一形態に従って、両方向にその接続点１２１を通過するパケットを調査し、各パケットが関連するアプリケーション・プログラムが何であるかを明確にすることが可能である。モニタ１０８は、サーバ１１０のネットワーク・インターフェース１１６とネットワークとの間のパケット（すなわちデータグラム）を調査する。また、モニタは、ネットワーク内の他の場所に配置されることも可能であり、例えば、ネットワーク１０２およびクライアント１０４のインターフェース１１８の間の接続点１２３、またはネットワーク１０２内のどこかの接続点１２５で概念的に示されるような他の場所が可能である。ネットワーク上の位置１２３におけるネットワーク・パケット捕捉装置は図示されておらず、これは、ネットワーク上の物理情報をモニタ１０８への入力用パケットに変換するものである。このようなパケット捕捉装置は一般的なものである。
【００８４】
要求される通信を確立および維持するために、ネットワークによって様々なプロトコル、例えばＴＣＰ／ＩＰ等が使用される。例えばクライアント１０４（クライアント１）によって実行されるアプリケーション・プログラムがサーバ１１０（サーバ２）上で実行される別のアプリケーション・プログラムに通信するような、任意のネットワーク活動は、ネットワーク１０２を介するパケットのシーケンスの交換(exchange)を引き起こし、そのシーケンスはそれぞれのプログラムおよびネットワーク・プロトコルの性質を表すものである。このような性質は個々のパケットの段階（レベル）では完全に明らかにはされない。特定のアプリケーション・プログラムを認識するために必要な情報を充分に得るために、モニタ１０８によって多くのパケットを分析する必要がある。パケットは分解される必要があり、様々なプロトコルのコンテキストで分析され、例えばＩＳＯの層構造にされたネットワーク・モデルに従う形式のパケットについては、アプリケーション・セッション層プロトコルを通じた転送である。
【００８５】
通信プロトコルは階層化され、プロトコル・スタックとして言及されることもある。国際標準化機構(ISO:  International  Standardization  Organization)は、一般的なモデルを定義し、通信プロトコル層を設計するための枠組み（フレームワーク）を提供する。以下のテーブル形式で示されるモデルは、既存の通信プロトコルの機能を理解するための参考として供される。
【００８６】
【表１】
0005517821.tif 000003
異なる通信プロトコルはＩＳＯモデルの異なるレベルを使用する、またはＩＳＯモデルに類似するが厳密には従わないところの階層化されたモデルを使用する。所定の層におけるプロトコルは、他の層で使用されるプロトコルに対して可視的ではない。例えば、アプリケーション層（レベル７）は、通信を意図するソース・コンピュータ（レベル２−３）を識別することはできない。
【００８７】
いくつかの通信技術において、「フレーム」なる用語は、ＯＳＩ層２において包含されたデータのことを指し、目的地アドレス、フロー制御用の制御ビット、データまたはペイロードおよび誤り検査用の巡回冗長検査(CRC:  cyclic  redundancy  check)データを含む。「パケット」なる用語は、一般にＯＳＩ層３において包含されるデータのことを指す。ＴＣＰ／ＩＰの世界では、「データグラム(datagram)」なる用語も使用される。本明細書において、「パケット」なる用語は、パケット、データグラム、フレームおよびセルを包含することを意図する。一般に、パケット・フォーマットまたはフレーム・フォーマットは、ネットワークを通じた通信に関して、様々なフィールドおよびヘッダを利用してデータがどのように包含されるかを示す。例えば、データ・パケットは一般に、パケットの開始および終了を区別するヘッダおよびフッタだけでなく、あて先アドレス・フィールド、長さフィールド、誤り訂正コード（ＥＣＣ）フィールドまたは巡回冗長検査（ＣＲＣ）フィールドを含む。「パケット・フォーマット」および「フレーム・フォーマット」なる用語は、「セル・フォーマット」としても言及され、概して同義語である。
【００８８】
モニタ１０８は、分析のために接続点１２１を通過するパケット総てを監視する。しかしながら、プロトコルの全レベルを認識するのに有用な同じ情報を総てのパケットが搬送しているわけではない。例えば、特定のアプリケーションに関連する会話フローにおいて、そのアプリケーションは、サーバに形式Ａのパケットを送出させるが、他のアプリケーションもそうするであろう。ただ、その特定のアプリケーション・プログラムは常に形式Ａのパケットに続いて形式Ｂのパケットを送出し、他のアプリケーション・プログラムはそうでないという場合には、そのアプリケーションの会話フローのパケットを認識するために、モニタは、形式Ａのパケットに関連する形式Ｂのパケットに合致するパケットを認識するために利用可能である。そのようなことが形式Ａのパケットの後に認識される場合、その特定のアプリケーション・プログラムの会話フローがモニタ１０８に対して自身を明らかにしはじめたことになる。
【００８９】
アプリケーション・プログラムに関連するものとして会話フローが識別される前に、更なるパケットが調査される必要があることがありうる。典型的には、モニタ１０８は、同時に、他のアプリケーションに関連する会話フローの一部である他のパケット交換を識別することの部分的な完了状態にもある。モニタ１０８の１つの性質は、フローの状態を維持する能力である。フローの状態は、そのフローにおける先行する総ての事象の指標であり、例えばＩＳＯモデル・プロトコル・レベルのようなプロトコル・レベル総ての内容の認識に導く。本発明の他の特徴は、パケットの抽出された特徴部分の署名を形成することであり、これは同一フローに属するパケットを迅速に識別するために使用可能である。
【００９０】
モニタ１０８の現実世界のユーザにおいて、モニタ１０８の接続点を通過するネットワーク１０２上のパケット数は、１秒当たり１００万を超え得る。したがって、モニタは各パケットを分析および分類すること、および接続点を通じて通過するフローの状態を維持することのためにほとんど時間を費やすことができない。したがって、モニタ１０８は、その分類に寄与しない各パケットの重要でない部分の総てを判別する。しかし、どのフローに所属するかに依存しておよびフローの状態に依存して、判別する部分は各パケットに対して異なるであろう。
【００９１】
パケット形式の判別、ひいては関連するアプリケーション・プログラムの実行が生成するパケットに基づく関連するアプリケーション・プログラムの判別は、モニタ１０８における多段階工程である。たとえば第１レベルでは、いくつかのアプリケーション・プログラムがみな第１種のパケットを生成する。第１の「署名(signature)」は、パケットの選択された部分から生成され、モニタ１０８が、同一フローに属するパケットを効率的に識別できるようにする。ある場合にあっては、そのパケット形式は、会話フローにおけるそのようなパケットを生成したアプリケーションを、モニタが識別できる程度に充分に特徴的である。そのアプリケーションに関するトラフィックにおいて生成される総ての将来的なパケットを効率的に識別するために、その署名が利用可能である。
【００９２】
他の場合にあっては、その第１のパケットは会話フローを分析するプロセスを開始するだけであり、関連するアプリケーション・プログラムを識別するためにさらなるパケットが必要である。このような場合、第２形式の以降のパケット（ただし、同一の会話フローに潜在的に所属している）は、その署名を利用することによって認識される。そのような第２レベルにおいて、数個のアプリケーション・プログラムのみが、そのような第２パケット形式を生成可能な会話フローを有するであろう。分類過程（プロセス）におけるこのレベルにおいて、そのようなパケット形式のシーケンスを導出するアプリケーション・プログラムの集合に属しないアプリケーション・プログラムの総ては、これら２つのパケットを含む会話フローを分類するプロセスにおいて排除される。プロトコルおよび可能なアプリケーションに関する既知のパターンに基づいて、その会話フローにおいて後続しうる任意の将来的なパケットを認識可能にする署名が生成される。
【００９３】
こうしてアプリケーションは判別されることがありうるが、あるいは、判別は第２レベルの署名を利用して第３レベルの分析に進む必要があり得る。したがって各パケットに関して、モニタはパケットを分解し、署名を生成して、その署名が以前遭遇したフローを識別したか、あるいは同一の会話フローに属する将来のパケットを認識するために使用されるかを判別する。リアル・タイムで、パケットは、以前に遭遇したパケットのシーケンス（状態）およびそのような過去のシーケンスが種々のアプリケーションに関連する会話フローにおいて生成しうる可能な将来の諸シーケンスのコンテキストにおいて分析される。将来のパケットを判別するための新たな署名も生成される。この分析のプロセスはアプリケーションが識別されるまで続く。すると、生成された最後の署名は、同一会話フローに関連する将来的なパケットを効率的に判別するために使用されうる。そのような構成は、モニタ１０８が、検査する必要のある毎秒数百万のパケットを適切に処理することを可能にする。
【００９４】
本発明の他の特徴は、立ち聞き機能(Eavesdropping)を追加することである。立ち聞きが可能な本発明の他の実施例では、モニタ１０８がネットワーク１０２内のある地点を通るアプリケーション・プログラムの実行をいったん認識すると（たとえばクライアント１０５またはサーバ１１０によるアプリケーションの実行に起因して）、そのモニタはメッセージをネットワーク上のある汎用プロセッサに送信し、そのプロセッサは、ネットワーク上で同一の場所から同一のパケットを入力可能であり、その後プロセッサはアプリケーション・プログラムの実行可能なコピーをロードし、ネットワークを通じて交換される内容を読み取るためにそれを使用する。言い換えれば、モニタ１０８がアプリケーション・プログラムの認識を達成すると、立ち聞きが可能になる。
【００９５】
［ネットワーク・モニタ］
図３は、コンピュータのハードウエア及び／又はソフトウェアで実装されることが可能な、本発明の実施例におけるネットワーク・パケット・モニタ３００を示す。このシステム３００は、図１のモニタ１０８と同様である。調査されるパケット３０２は、例えば、ネットワーク１０２（図１）内の場所１２１におけるパケット捕捉装置からのもので、そのパケットは、例えばその性質を判別する試みにおいて評価される。その性質とは、例えばそのパケットを生成したサーバ・アプリケーションが何であるかを含む複数階層モデルにおけるプロトコル情報全てである。
【００９６】
パケット捕捉装置は一般的なインターフェースであり、特定のネットワーク（イーサーネット、フレームリレー、ＡＴＭ等）に従って、物理信号を変換し、それらをビットおよびパケットにデコードする。この捕捉装置は、モニタ１０８に対して、捕捉したパケットのネットワークの形式またはパケットの形式を知らせる。
【００９７】
ここに示される特徴は：（１）異なる形式のパケットにおいて生じる必要のある作業が何であるかを生成するためのモニタの初期化――コンパイラおよび最適化装置３１０によって達成される，（２）パケットの処理――分解および選択した部分の抽出――を行って識別する署名を生成すること――分解サブシステム３０１によって達成される，および（３）パケットの分析――分析器３０３によって達成される。
【００９８】
コンパイラおよび最適化装置３１０の目的は、プロトコル特有情報を分解サブシステム３０１および分析サブシステム３０３に提供することである。初期化はモニタの動作に先立って行われ、新たなプロトコルが付加されるべき場合にのみ再度行われる必要がある。
【００９９】
フローは、ネットワークにおける２つのアドレスの間で交換されるパケットのストリームである。各プロトコルに関し、あて先（受領者）、発信元（送信者）等のような既知のいくつかのフィールドが存在し、これらおよび他のフィールドは、フローを識別するためにモニタ３００において使用される。チェックサムのようなフローを識別するには重要でない他のフィールドも存在し、それらの部分は識別の際に使用されない。
【０１００】
分解システム３０１は、パターン認識過程３０４を使用してパケットを調査し、パケットを分解し（parse）、パケット３０２内に存在する各プロトコル層に対してプロトコル形式および関連するヘッダを判別する。抽出過程３０６は分解サブシステム３０１においてパケット３０２から特徴部分（署名情報）を抽出する。分解用のパターン情報および例えば抽出マスクのような関連する抽出動作の両者は、コンパイラおよび最適化装置３１０によって充足される分解パターン構造及び抽出作業データベース（分解／抽出データベース）３０８から供給される。
【０１０１】
プロトコル記述言語（ＰＤＬ）ファイル３３６は、任意の階層で生じる全プロトコルのパターンおよび状態の両者を記述し、ヘッダ情報の解釈方法、パケットヘッダ情報に基づいて次の階層におけるプロトコルを判別する方法、フローを、最終的にはアプリケーションおよびサービスを識別する目的でどの情報を抽出するか、を含む。階層選択データベース３３８はモニタによって取り扱われる特定の階層構造、すなわち、任意の階層レベルにおいてどのプロトコルの上においてどのプロトコルが走るかを記述する。３３６および３３８の結合は、パケット内の情報のデコード、分析および理解をどのように行うか、更には情報がどのように階層化されるかを記述する。この情報はコンパイラおよび最適化装置３１０に入力される。
【０１０２】
コンパイラおよび最適化装置３１０が動作すると、２組の内部データ構造が生成される。第１のものは、分解／抽出作業３０８の組である。このパターン構造は、分解情報を含み、パケットのヘッダにおいて何が認識されるかを記述し；抽出作業では、合致したパターンに基づいてパケットから、パケットのどの要素が抽出されるかである。したがって、分解／抽出作業のデータベース３０８は、パケット内で使用されるプロトコルを示すパケット内のデータから、一つまたは複数のプロトコル依存抽出作業の組をどのようにして決定するかを記述する情報を含む。
【０１０３】
コンパイラ３１０によって構築される他方の内部データ構造は、状態パターンおよびプロセス３２６の組である。これらは種々の会話フローで生じる異なる状態および状態遷移と、会話フローを分析するタスクを進めるために会話フローの任意の状態において実行されることを要する状態動作（例えば、調査される必要のあるパターンおよび形成される必要のある新規の署名である）である。
【０１０４】
ＰＤＬファイルのコンパイルおよび階層選択は、モニタ３００に対してパケットの処理を開始するために必要な情報を提供する。他の実施例にあっては、データベース３０８，３２６の１つ又はそれ以上の内容は、マニュアルその他の方法で生成される。いくつかの実施例において、階層化選択情報は、明示的な記述というよりはむしろ内在的なものである。例えば、あるプロトコル用のＰＤＬファイルは子プロトコルを含むので、親プロトコルも判別されうる。
【０１０５】
好適実施例にあっては、捕捉装置からのパケット３０２は、パケット・バッファに入力される。パターン認識過程３０４は、パターン分析および認識（ＰＡＲ：pattern  analysis  and  recognition）エンジンによって実行され、パケットにおけるパターンを分析および認識する。特に、ＰＡＲはヘッダにおいて次のプロトコル・フィールドを見出し、ヘッダの長さを判別し、プロトコル・ヘッダの所定の形式に関する他の所定のタスクを実行しうる。この例としては、ディジタル・インテル・ゼロックス（ＤＩＸ）パケットとも呼ばれるかつての形式２（又はバージョン２）イーサーネット・パケットからＩＥＥＥ８０２．３（イーサーネット）パケットを区別するための形式および長さの比較である。ＰＡＲは、パターン構造および抽出作業データベース３０８を利用して、そのプロトコルに関連する次のプロトコルおよびパラメータを識別し、次のプロトコル層の分析を可能にする。パターンまたは１組のパターンが識別されると、それ／それらは１組のゼロ個以上の抽出作業に関連付けられる。これら抽出作業は（命令および関連するパラメータの形式で）、パケットの選択された部分を抽出する抽出および情報識別（ＥＩＩ：extracting  and  information  identifying）エンジンによって実装される抽出プロセス３０６に引き渡され、該選択された部分は、フローの一部としてパケットを認識するために必要なパケットからの識別情報を含む。抽出された情報はシーケンス内に置かれ、ブロック３１２で処理されてこのフローに関して特有のフロー署名（「キー」とも呼ばれる）を形成する。フロー署名は、そのパケットで使用されるプロトコルに依存する。いくつかのプロトコルについては、抽出される成分は発信元およびあて先アドレスを含みうる。たとえば、イーサーネット・フレームは、より良いフロー署名を形成する際に有用である端点アドレスを有する。したがって、署名は典型的にはクライアントおよびサーバ・アドレスの対を含む。このフローの一部である又は一部となり得る更なるパケットを認識するためにその署名が利用される。
【０１０６】
好適実施例にあっては、フロー・キーの形成は、ハッシュ関数(hash  function)を利用して署名のハッシュを生成することを含む。そのようなハッシュを利用する場合の目的は一般的なものであり、効率的な探索のためにデータベースを通じて署名で識別されるフロー・エントリを拡散するためである。生成されたハッシュはハッシュ・アルゴリズムに準拠することが好ましく、そのようなハッシュ生成は当該技術分野でよく知られている。
【０１０７】
一実施例にあっては、分解器（parser）は、パケットからのデータ――分解レコード（parser  record）――を引き渡す。分解レコードは署名（すなわちパケットの選択された部分）、ハッシュ、およびパケット自身を含み、パケットからの更なるデータを要する任意の状態処理を可能にする。分解サブシステムの改善実施例は、ある所定の構造を有し、署名、ハッシュ、分解レコードにおけるフィールドのいくつかに関連するいくつかのフラグ、および分解サブシステムが例えば状態処理のような更なる処理用に必要とされうると判断したパケットのペイロードの一部を含む分解レコードを生成してもよい。
【０１０８】
他の実施例では、パケットの選択された部分の連結以外の何らかの関数を利用して、識別する署名を作成してもよい。例えば、連結された選択された部分の何らかの「要約〔ダイジェスト〕関数(digest  function)」を利用することが可能である。
【０１０９】
分解レコードは探索プロセス３１４に引き渡され、そのシステムが既に遭遇した既知フローのレコードの内部データ記憶において探索し、その特定のパケットが既知フローに属するか否かを判定し（３１６において）、それは既知フローのデータベース３２４においてそのフローに一致するフロー・エントリの存否によって示される。
【０１１０】
分解レコードは、一体化フロー・キー・バッファ(UFKB:  unified  flow  key  buffer)と呼ばれるバッファに入力される。ＵＦＫＢはフローについてのデータを格納し、そのデータ構造は分解レコードと同様であるが、修正されることの可能なフィールドを含む。特に、ＵＦＫＢレコード・フィールドの一つは、パケット・シーケンス番号を格納し、他のものは状態処理３２８を実装する状態プロセッサに対するプログラム・カウンタの形の状態情報で満たされる。
【０１１１】
同一署名を有するレコードが既に存在するか否かの判定は、探索エンジン（ＬＵＥ：lookup  engine）によって実行される。探索エンジンは、新たなＵＫＦＢレコードを取得し、合致する既知フローがあるか否かを探索するためにＵＫＦＢレコード内のハッシュを利用する。特定の実施例において、既知フローのデータベース３２４は、外部メモリ内にある。キャッシュがデータベース３２４に付随する。ＬＵＥによる既知レコードの探索は、ハッシュを利用してキャッシュにアクセスすることによって実行され、キャッシュ内にそのエントリが存在しない場合には、そのエントリは（やはりハッシュを利用して）外部メモリにおいて探索される。
【０１１２】
フロー・エントリ・データベース３２４はフロー・エントリを格納し、フロー・エントリは、フローを更新するためのパケットからの一意的なフロー署名、状態情報および抽出情報ならびにそのフローに関する１つまたはそれ以上の統計値を含む。各エントリはフローを完全に記述する。データベース３２４は、いくつかのビン(bin)に組織化され、ビンはＮで記される数のフロー・エントリ（フロー・エントリを各々のバケット(bucket)と呼ぶこともある）を含み、好適実施例ではＮは４である。バケット（すなわちフロー・エントリ）は、分解サブシステム３０１からのパケットのハッシュ（すなわち、ＵＦＫＢレコードにおけるハッシュ）を通じてアクセスされる。ハッシュは、フローをデータベースにわたって拡散し、エントリの高速探索を可能にし、バケットを浅くすることを許容する。設計者は、モニタに取り付けられるメモリ量に基づいて、バケット深さＮと、使用されるハッシュ・データ値のビット数を採択する。例えば、一実施例において、各フロー・エントリは１２８バイト長であり、１２８ｋのフロー・エントリに対して１６Ｍバイトが必要とされる。１６ビット・ハッシュを利用するとバケットあたり２つのフロー・エントリを与える。経験的に、これが大半の事例について十分であることが示されている。他の実施例は２５６バイト長のフロー・エントリを利用する。
【０１１３】
本稿では、データベース３２４へのアクセスが記述される際は、そうでないとの記述があるか文脈から明らかでない限り、常に、そのアクセスはキャッシュを介して行われる。
【０１１４】
署名に合致するフロー・エントリがない場合は、すなわちその署名が新たなフローに関するものである場合、プロトコルおよび状態識別プロセス３１８は、更にその状態およびプロトコルを判別する。すなわち、プロセス３１８はプロトコルを判定し、そのプロトコルについてのフローについての状態シーケンスにおいてそのパケットが所属する位置を判定する。識別プロセス３１８は、抽出された情報を利用し、状態パターンおよびプロセスのデータベース３２６を参照する。プロセス３１８の後には、このパケットに対して状態プロセッサによって実行される必要のある状態動作３２８がもしあれば続く。
【０１１５】
パケットが、データベース３２４（例えばキャッシュ）において合致するフロー・エントリを有すると見出されると、プロセス３２０は、探索されたフロー・エントリから、そのフロー署名の状態処理による更なる分類の要否を判定する。不要であればプロセス３２２はフロー・エントリ・データベース３２４（例えばキャッシュを通じて）においてフロー・エントリを更新する。更新には、そのフロー・エントリにおいて格納される１つ又はそれ以上の統計測定値を更新することが含まれる。本実施例では、統計測定値はフロー・エントリにおけるカウンタに格納される。
【０１１６】
状態処理が必要とされる場合は、状態プロセス３２８が起動される。状態プロセッサ３２８は、そのフローの状態に関して特定された任意の状態動作を実行し、その状態を次の状態に更新し、これは状態パターンおよびプロセス・データベース３２６から取得される１組の状態命令に従って行われる。
【０１１７】
状態プロセッサ３２８は、プロトコル・スタックの全レベルを分析し、最終的にはアプリケーションによって（ＩＳＯモデルのレベル７）フローを分類するために、新規のおよび既存のフローの両者を分析する。これは、所定の状態遷移規則および状態プロセッサ命令データベース３２６において特定されるような状態動作に基づいて、状態から状態へ処理を進めることによって行われる。状態遷移規則は、典型的には、検査と、それに続いて検査結果が真である場合に進むべき次の状態を含む。動作は、状態プロセッサが特定の状態にある場合に実行される動作であり、例えば状態遷移規則を適用するために必要とされる量を評価するためのものである。状態プロセッサは各々の規則および各々の状態プロセスを通じて処理を進め、検査結果が真であるまたは実行する検査が存在しなくなるまで行われる。
【０１１８】
一般に、１組の状態動作は、パケットに関するゼロ個以上の動作でありえ、その動作の実行は、識別を完了する前にシステムを抜け出させる状態に置くことがありうるが、可能性としては、何の状態であるかおよび次に、すなわちそのフローの次のパケットに遭遇したときにどの状態プロセスが実行される必要があるかについてより多くを知っている。例として、ある特定の状態における状態プロセス（１組の状態動作）は、次の状態の将来の認識パケットに関する新規の署名を形成することが可能である。
【０１１９】
フローの状態を維持し、新規フローが以前に遭遇したフローからの情報を利用して設定されうることを知ることによって、ネットワーク・トラフィック・モニタ３００は、（ａ）フローの単独パケットでのプロトコル判別および（ｂ）フローの複数パケットでのプロトコル判別を提供する。モニタ３００は、サーバ通知形式フローで生じる１つ又はそれ以上の分離した部分フローからでさえもアプリケーション・プログラムを認識することが可能である。従来のモニタにとっては関連のないフローであると思われうるものが、本願モニタにより、フロー署名を使って、以前に遭遇した部分フローに関連する部分フローであると認識されうる。
【０１２０】
こうして、状態プロセッサ３２８は第１の状態動作をこの特定のフロー・エントリに適用する。プロセス３３０は、更なる動作がこの状態に関して実行される必要があるか否かを決定する。必要であれば、分析器はブロック３３０および３２８の間でループを繰り返し、更なる状態動作をその特定のパケットに対して適用し、これら総ての動作が完了するまで行われる、すなわちその状態におけるそのパケットに関してそれ以上動作が存在しなくなるまで行われる。プロセス３３２は、フローを充分に特徴付けるために、この形式のフローに関して分析されるべき更なる状態が存在するか否かを、フローの状態およびプロトコルに従って決定する。存在しない場合は、会話フローが現在充分に特徴付けられ、プロセス３３４がそのフローに関する会話フローの分類を完成させる。
【０１２１】
特定の実施例において、状態プロセッサ３２８は、ジャンプ・テーブル（ジャンプ・ベクトル）へのオフセット(offset)として、分解によって認識された最終プロトコルを利用することによって状態処理を開始する。ジャンプ・テーブルは、状態パターンおよびプロセス・データベース３２６におけるそのプロトコルに関して使用する状態プロセッサ命令を見出す。ほとんどの命令は、一体化フロー・キー・バッファにおける何か、すなわちそのエントリが存在するならば既知フローのデータベース３２４におけるフロー・エントリを検査する。状態プロセッサはビットを検査し、比較を行い、加算し、または減算して検査を実行しなければならないことがありうる。例えば、状態プロセッサにより実行される共通の動作は、ＵＦＫＢのペイロード部分における１つ又はそれ以上のパターンを探索することである。
【０１２２】
分類におけるステップ３２２において、分析器はそのフローが終了状態におけるものであるか否かを決定する。終了状態におけるものでない場合は、フロー・エントリはステップ３２２においてそのフロー・エントリに関して更新される（新たなフローの場合は作成される。）。
【０１２３】
さらに、フローが既知であり、３２２において後のパケットを利用して処理されるべき更なる状態が存在することが判明した場合は、フロー・エントリはプロセス３２２で更新される。
【０１２４】
また、フロー・エントリは分類の完了後に更新され、この充分に分析された会話フローに属するように、そのフローに属する任意の更なるパケットがそれらの署名により容易に識別されるようにする。
【０１２５】
したがって更新の後、データベース３２４は、発生した会話フロー総ての組を含む。
【０１２６】
図３に示す本発明の実施例は、フロー・エントリを自動的に維持し、一形態にあっては状態を格納する。図３のモニタは、パケットの特徴部分――署名――を生成し、その特徴部分はフローを認識するために使用可能である。フロー・エントリはそれらの署名により識別されアクセスされる。パケットが既知フローからのものであると識別されると、フローの状態が知られ、その知識は、異なるプロトコルおよびアプリケーション夫々に関してリアル・タイムで状態遷移分析が実行されることを可能にする。複雑な分析にあっては、ますます多くのパケットが調査されるにつれて状態遷移をたどっていく。同一会話フローの一部である将来のパケットは、以前に到達した状態から状態分析を続けさせる。対象とするアプリケーションに関連する充分なパケットが処理されると、最後の認識状態が最終的に達成され、すなわち会話フローを完全に特徴付けるために状態分析が１組の状態をたどったことになる。その最後の状態に関する署名は、同一会話フローの新たな入来パケットの各々が、リアル・タイムで個々に認識されることを可能にする。
【０１２７】
このようにして、本発明の重要な利点の１つが実現される。状態遷移の特定の組が初めてたどられ、最終状態で終了すると、ショート・カット認識パターン――署名――が生成され、その会話フローに関する総ての新規入来パケットのキーとなる。署名の検査は、単純な動作を包含し、ネットワークにおいて高パケット・レートで連続的に監視することを可能にする。
【０１２８】
改善された実施例では、いくつかの状態分析器が並列して動作し、多数のプロトコルおよびアプリケーションが検査される。総ての既知のプロトコルおよびアプリケーションは、状態遷移の特有の組を少なくとも１つ有し、そのような遷移を眺めることにより一意的に識別することが可能である。
【０１２９】
各々の新しい会話フローが始まると、フローを認識する署名は自動的に動作中に生成され、会話フローにおける更なるパケットに遭遇すると、署名が更新され、潜在的なアプリケーションに関する状態遷移の組の状態は、そのフローに関する状態遷移規則に従って更に遷移する。フローに関する新たな状態は、１つまたはそれ以上の潜在的なアプリケーションに関する状態遷移の組に関連するものであり、認識を容易にするために以前に遭遇した状態の記録（レコード）に付加され、フロー内で新たなパケットに遭遇した際に引き出される。
【０１３０】
［動作の詳細］
図４は、コンパイル・プロセスを含む初期化システム４００の概略図を示す。これは初期化の一部であり、パターン構造および抽出作業データベース３０８と、状態命令データベース３２８を生成する。このような初期化はオフラインでまたは中央位置から行われ得る。
【０１３１】
異なる層に存在し得る異なるプロトコルは、リンクされたノードの１つ又はそれ以上のツリーのノードと考えることができる。パケット形式はそのツリーのルート（根）である（レベル０）。各プロトコルは、親(parent)ノードまたは端末ノードの何れかである。親ノードは、プロトコルをより高位の階層レベルにおけるものであり得る他のプロトコル（子プロトコル）に結び付ける（リンクする）。こうして、プロトコルはゼロ個以上の子(children)を有する。例えばイーサーネット・パケットは、いくつかの変形形態を有し、各々が実質的に同じである基本フォーマットを有する。イーサーネット・パケット（ルートまたは０レベル・ノード）はイーサー形式パケット――イーサーネット形式／バージョン２およびＤＩＸ（ディジタル・インテル・ゼロックス・パケット）とも呼ばれる――またはＩＥＥＥ８０３．２パケットである。ＩＥＥＥ８０２．３パケットに関して続けると、子ノードの１つがＩＰプロトコルであることがあり得、そのＩＰプロトコルの子の１つがＴＣＰプロトコルであることがあり得る。
【０１３２】
図１６は、情報に関する完全なイーサーネット・フレーム（すなわちパケット）のヘッダ１６００（ベース・レベル１）を示し、あて先のメディア・アクセス・コントロール・アドレス（Ｄｓｔ  ＭＡＣ  １６０２）およびソース・メディア・アクセス・コントロール・アドレス（Ｓｒｃ  ＭＡＣ  １６０４）を含む。また、図１６は、特徴〔シグネチャ〕を抽出するためのＰＤＬファイルで特定される情報の（全部ではなく）一部をも示す。
【０１３３】
図１７Ａは、イーサー形式パケット１７００の次のレベル（レベル２）に関するヘッダ情報を示す。イーサー形式パケット１７００に関し、次の階層レベルを示すパケットからの有意な情報は、次のレベルに関する子認識パターンを含む２バイト形式フィールド１７０２である。残りの情報１７０４に影が付されているのは、このレベルに対しては有意でないからである。リスト１７１２は、イーサー形式パケットに対する可能な子を示し、どの子認識パターンがオフセット１２に見出されるかによって示される。図１７Ｂは可能な次のレベルの１つのヘッダの構造を示し、ＩＰプロトコルに対するものである。ＩＰプロトコルの可能な子は、テーブル１７５２に示されている。
【０１３４】
一実施例においてコンパイル・プロセス３１０によって生成されるパターン、分析および抽出データベース（パターン認識データベースすなわちＰＲＤ）３０８は、３次元形式構造の形であり、次のプロトコルに関するパケット・ヘッダの迅速な探索を提供する。図１８Ａはそのような３Ｄ表現１８００を示す（これは２Ｄ表現のインデックスが付された集合(indexed  set)として考えることが可能である。）。３Ｄ構造の圧縮された形式が好ましい。
【０１３５】
データベース３０８で使用されるデータ構造の他の形態は図１８Ｂに描かれている。図１８Ａの３Ｄ構造と同様に、このデータ構造は、パターン認識プロセス３０４によって実行される迅速な探索を可能にし、これはアドレス・リンク計算を実行するのではなくメモリ内の場所を指し示すことによって行われる。この代替実施例では、ＰＲＤ３０８が２つの部分を有する。当該モニタにとって既知のプロトコル各々に関するエントリを有する単独プロトコル・テーブル１８５０（ＰＴ）と、既知のプロトコルおよびそれらの子を識別するために使用される一連の探索テーブル１８７０（ＬＵＴ）である。プロトコル・テーブルは、そのプロトコルに関連するパケット中のヘッダ情報を評価するためにパターン分析および認識プロセス３０４（ＰＲＥ１００６によって実装される）によって必要とされるパラメータと、そのパケット・ヘッダを処理するための抽出プロセス３０６（スライサ１００７によって実装される）によって必要とされるパラメータとを含む。子が存在する場合、ＰＴは、子プロトコルを判定するために、ヘッダにおけるどのバイトを評価するかを記述する。特に、各ＰＴ入力はヘッダ長、子に対するオフセット、スライサ命令およびいくつかのフラグを有する。
【０１３６】
ヘッダ・フィールドにおいて特定の「子認識コード」を見出し、ＬＵＴの一つまたは複数をインデックスするためにこれらのコードを利用することによってパターンマッチングが行われる。各ＬＵＴエントリは、認識されたプロトコルを示す値、プロトコルが部分的に認識されたことを示すためのコード（更なるＬＵＴ探索が必要である）、それが端末ノードであることを示すコード、およびヌル(null)エントリを示すためのヌル・コード、の４つの値のうちの１つを有することのできるノード・コードを有する。探索用の次のＬＵＴも、ＬＵＴ探索から返される。
【０１３７】
コンパイル・プロセスが図４において説明される。プロトコル記述ファイルの形のソース・コード情報は、４０２として示される。この特定の実施例において、高レベルのデコード記述は、１組のプロトコル記述ファイル３３６（各プロトコルに付き１つ）と、モニタが取り扱うことの可能な特定の階層（プロトコルのツリーの組）を記述する１組のパケット階層選択部３３８を含む。
【０１３８】
コンパイラ４０３は、その記述をコンパイルする。１組のパケット分解および抽出作業４０６が生成され（４０４）、状態処理プロセス３２８を実装する状態プロセッサに対する命令の形で１組のパケット状態命令および動作４０７が生成される（４０５）。分析器によって認識されるアプリケーションおよびプロトコルの各形式に対するデータ・ファイルは、パターン、分解および抽出データベース４０６から、分解および抽出エンジンのメモリ・システムにダウンロードされる（分解プロセス５００の記述および図５；抽出プロセス６００の記述および図６；および分解サブシステム・ハードウエアの記述および図１０を参照のこと）。また、分析器によって認識されるアプリケーションおよびプロトコルの各形式に対するデータ・ファイルは、状態プロセッサ命令データベース４０７から状態プロセッサへダウンロードされる（状態プロセッサ１１０８の記述および図１１を参照のこと）。
パケット分解および抽出動作を生成することは、３次元構造（ある実施例）又はＰＲＤに対する総ての探索テーブルを構築および結びつける（リンクする）点に留意すべきである。
【０１３９】
可能なプロトコル・ツリーおよびサブツリーの膨大な数のため、コンパイラ・プロセス４００は、どの子が共通の親を共有するかを見つけるためにツリーおよびサブツリーを比較する最適化を含む。ＬＵＴの形で実装されると、このプロセスは、複数のＬＵＴから単独のＬＵＴを生成することが可能である。最適化プロセスは更に、ＰＲＤのデータを格納するために必要なスペースを減少させるコンパクト化プロセスを含む。
【０１４０】
コンパクト化の例として、各々がプロトコルを表現する２Ｄ構造の集合として考えることが可能な図１８Ａの３Ｄ構造を考察する。一実施例において、いくつかの親を有しうるプロトコルごとに唯１つのアレイを利用することによってスペースの節約を可能にするため、パターン分析サブプロセスは「現在ヘッダ」ポインタを保持する。３Ｄ構造における各プロトコル２Ｄアレイに関する各々の位置（オフセット）インデックスは、特定のプロトコルに関するヘッダの先頭から始まる相対的な位置である。更に、２次元配列の各々はまばらである。最適化の次のステップは、総ての２Ｄアレイを他の総ての２Ｄアレイに対して検査し、どれがメモリを共有し得るかを見出す。これら２Ｄアレイの多くは、各々が少数の有効エントリを有するに過ぎないという意味で疎な分布をもつ（sparsely  populated）。したがって次に「折り重ね(folding)」のプロセスを利用して、任意の当初の２Ｄアレイの識別性を喪失することなしに（すなわち、総ての２Ｄアレイが論理的には存在し続ける）、２以上の２Ｄアレイを一体の物理的な２Ｄアレイに統合する。折り重ねは、所定の条件に適合する限りはそのツリーにおけるそれらの場所には無関係に、任意の２Ｄアレイの間で起こり得る。個々のエントリが互いに衝突しない限り、複数のアレイが単独のアレイに統合されうる。折り重ね数が、各要素を当初のアレイに関連付けるために使用される。図１８Ｂの他の実施例において同様な折り重ねプロセスがＬＵＴ１８５０の集合に対して使用可能である。
【０１４１】
ステップ４１０において、分析器は初期化されており、認識を行う準備ができている。
【０１４２】
図５は実際の分解サブシステム３０１がどのように機能するかについてのフローチャートを示す。５０１から始まり、ステップ５０２においてパケット３０２がパケット・バッファに入力される。ステップ５０３はパケット３０２から次の（最初は第１の）パケット成分をロードする。パケット成分は各パケット３０２から一度に一要素抽出される。検査が行われ（５０４）、パケット成分のロード動作５０３の成否を判定し、パケット内にさらに処理すべきものがあったか否かを判定する。なければ、総ての成分がロードされたことを通知し、分解システム３０１はパケット署名（５１２）を形成する――次の段階（図６）。
【０１４３】
５０３において成分が良好にロードされると、ノードおよびプロセッサがパターン、分解および抽出データベース３０８から取得され（５０５）、そのノードに対する１組のパターンおよびプロセスを提供し、ロードされたパケット成分に適用する。分解サブシステム３０１は検査を行い（５０６）、パターン・ノード取得動作５０５が良好に完了したか否かを判定し、ステップ５０５でロードされるパターン・ノードがあったか否かを判定する。なければステップ５１１で次のパケット成分へ進む。存在する場合は、５０３で抽出された成分に対して、ノードおよびパターン・マッチング・プロセスが５０７で行われる。５０７におけるパターンの一致は（検査５０８によって示される）、分解サブシステム３０１が分解要素内でノードを見出し；分解サブシステム３０１がステップ５０９へ進み要素を抽出することを意味する。
【０１４４】
ノード・プロセスをその成分に適用しても一致（検査５０８）が得られない場合は、分解サブシステム３０１は、パターン・データベース３０８から次のパターンに進み（５１０）、次のノードおよびプロセスを取得するためにステップ５０５へ進む。このように、５０８と５０５の間には「パターン適用」ループがある。分解サブシステム３０１が総てのパターンを完了し、一致または不一致を得ると、分解サブシステム３０１は次の成分へ進む（５１１）。
【０１４５】
入力パケット３０２から総てのパケット成分がロードされ処理されると、パケットのロードは（検査５０４で示されるように）失敗し、分解サブシステム３０１は、図６で説明されるパケット署名を形成するための処理に進む。
【０１４６】
図６は、パケット署名を形成するための情報を抽出するフローチャートである。６０１においてフローは始まり、これは図５の出口５１３である。この時点において、分解サブシステム３０１は完備なパケット成分およびバッファで利用可能なパターン・ノードを有する（６０２）。ステップ６０３で図５のパターン分析プロセスからの利用可能なパケット成分をロードする。ロードが完了し（検査６０４）、他のパケット成分が存在していた場合は、分解サブシステム３０１は、６０２におけるパターン・ノード成分から受信した抽出およびプロセス要素を６０５において取得する。取得が成功し（検査６０６）、適用すべき抽出要素が存在することを示す場合は、分解サブシステム３０１はステップ６０７において、パターン・ノードから受信した抽出命令に基づいて、抽出プロセスをパケット成分に適用する。これは、パケット成分から要素を除去および節約する。
【０１４７】
ステップ６０８において、分解サブシステム３０１は、その成分から更に抽出すべきものがあるか否かを検査し、なければ、分解サブシステム３０１は６０３に戻り、直ちに次のパケット成分をロードし、処理を繰り返す。存在する場合は、分解サブシステム３０１は次のパケット成分に進む。その後新たなパケット成分がステップ６０３でロードされる。分解サブシステム３０１は６０８および６０３の間のループを通じて動作する際、更に抽出すべきものが存在する場合には同一のパケット成分に対して、またはそれ以上抽出すべきものが存在しない場合は別のパケット成分に対して、更なる抽出プロセスが適用される。
【０１４８】
特定のパケットに関するパターンおよび抽出データベース３０８における情報に従って、抽出プロセスは署名を形成し、次々に成分を抽出する。次のパケット成分のロード動作が失敗すると（検査６０４で）、総ての成分が抽出されている。形成された署名は、署名バッファにロードされ（６１０）、署名生成プロセスを完了させるために分解サブシステム３０１は図７に進む。
【０１４９】
図７を参照すると、プロセスは７０１から始まる。署名バッファおよびパターン・ノード要素が利用可能である（７０２）。分解サブシステム３０１は次のパターン・ノード要素をロードする。ロードが成功し（検査７０４）、更なるノードが存在することを示す場合は、分解サブシステム３０１は７０５において、要素データベース内のパターン・ノードにおいて見出されるハッシュ要素に基づいて、署名バッファ要素をハッシュする(hash)。７０６において結果の署名およびハッシュが一緒にされる。７０７において、分解サブシステム３０１は、７０３でロードした次のパケット成分へ進む。
【０１５０】
７０３から７０７へのループは、要素のパターンがそれ以上存在しなくなるまで続く。要素のパターンの総てがハッシュされると、分解サブシステム３０１のプロセス３０４，３０６および３１２は完了する。分解サブシステム３０１は、分析サブシステム３０３によって使用される署名を生成した。
【０１５１】
分解レコードが分析器にロードされ、特に、ＵＦＫＢレコードの形式でＵＦＫＢにロードされ、これは分解レコードに類似するが１つ又はそれ以上の異なるフィールドを有する。
【０１５２】
図８は、探索動作３１４を実行する探索／更新エンジン（ＬＵＥ）の動作を記述するフロー図である。このプロセスは、署名、ハッシュおよびペイロードの少なくとも一部を含む分解レコードを利用して図７からの８０１から始まる。８０２において、これらの要素は、バッファにおけるＵＦＫＢエントリの形式で示される。ＬＵＥすなわち探索エンジン３１４は、フロー・エントリに関するハッシュから「レコード・ビン番号(record  bin  number)」を計算する。ビンは、各々がフロー・エントリを有する１つ又はそれ以上の「バケット(bucket)」を有する。好適実施例では１ビン当たり４つのバケットを有する。
【０１５３】
好適なハードウエア例はキャッシュを有するので、図８のフローチャートにおけるレコードへの総てのデータ・アクセスは、キャッシュに対して又はキャッシュからのものとして開始される。
【０１５４】
８０４では、そのシステムは、ハッシュを利用するビンから、バケットを求めてキャッシュを探索する。キャッシュがビン番号からのバケットを良好に返し、更なるバケットがビン内に存在することを示す場合は、探索／更新エンジンは現在の署名（ＵＫＦＢエントリの署名）をバケット内のもの（すなわちフロー・エントリの署名）と比較する。署名が一致すると（検査８０８）、（キャッシュ内の）そのレコードは、ステップ８１０において、「処理中」としてマークされタイムスタンプが付加される。ステップ８１１は、ＵＦＫＢに対して、８０２におけるＵＦＫＢエントリが「発見」のステータス（状態）を有することを示す。「発見」の指示は、状態プロセッサ３２８がそのＵＦＫＢ要素の処理を開始可能にする。好適なハードウエア例は、１つ又はそれ以上の状態プロセッサを有し、探索／更新エンジンと共に並列して動作可能である。
【０１５５】
好適実施例では、分析された総てのパケットに対して計算機によって１組の統計的作業が実行される。統計的作業は、フローに関連するパケットの計数；フローのパケットのサイズに関する統計値を決定すること；例えばタイムスタンプを利用して各方向におけるパケットどうしの相違に関する統計値をまとめること（コンパイル）；および同一方向におけるパケットのタイムスタンプの統計的な関係を決定することのうちの１つ又は複数を含む。統計的な指標は、フロー・エントリにおいて維持される。他の統計的指標もコンパイルされ得る。フローの多くの異なる側面を分析するために、統計処理コンポーネントによって、これらの統計値が単独で又は結合されて利用される。これは、統計的指標からネットワーク利用メトリックを判定することを含み、例えば、そのアプリケーションに対して情報を転送するネットワークの能力を把握する。このような分析は、会話のサービスの質の測定、そのネットワークにおいてアプリケーションがどの程度良好に実行されているかの測定、アプリケーションによって消費されるネットワーク資源の測定等を可能にする。
【０１５６】
そのような分析を行うために、探索／更新エンジンは、ステップ８１２における（キャッシュ内の）フロー・エントリの一部である１つ又はそれ以上のカウンタを更新する。プロセスは８１３で終了する。本実施例では、カウンタはフローの全パケット、時間、および最後のタイムスタンプから現在のタイムスタンプまでの時間差を含む。
【０１５７】
ビンのバケットが署名の一致を与えない場合がある（検査８０８）。この場合は、８０９における分析器は、そのビンに対する次のバケットに移動する。ステップ８０４はそのビンから次のバケットを求めてキャッシュを探索する。探索／更新エンジンはそのビンのバケットを探索し続け、８０８で一致が得られるまで、又は作業８０４が不成功（検査８０５）となり、ビン内にそれ以上バケットが存在せず、一致が見出されなかったことを示すまで続く。
【０１５８】
一致が見出されなかった場合は、パケットは新たなフロー（以前に遭遇していないもの）に所属する。８０６において、システムは、そのパケットについての一体化フロー・キー・バッファにおけるレコードが新しいことを指示し、８１２においてそのキャッシュ内のフロー・エントリを更新することによって、そのパケットに対する統計的更新作業が実行される。更新作業は８１３で終了する。フロー挿入／削除エンジン（ＦＩＤＥ）は、（再びキャッシュを通じて）このフローに関する新たなレコードを形成する。
【０１５９】
こうして、更新／探索エンジンは、そのパケットに対するＵＦＫＢエントリが「新規」の状態または「発見」の状態を有する形で処理を終了する。
【０１６０】
上記のシステムは、２以上のフロー・エントリが合致することの可能なハッシュを利用する。単独のフロー・エントリに対応する、より長いハッシュが利用されることも可能である。そのような場合には、図８のフローチャートはさらに簡潔化される。
【０１６１】
［ハードウエア・システム］
システム内でデータが流れる個々のハードウエア要素が夫々図１０および図１１に関連して説明される。以下、図３の本願実施例の特定のハードウエアを説明するが、図３のフローは、１つ又はそれ以上の汎用プロセッサ上を走るソフトウエアでも実行可能であり、あるいは部分的にハードウエアで実現されることも可能であることは当業者に明らかであろう。ソフトウエアで実行可能な本願の実施例は図１４に示される。ハードウエア例（図１０および図１１）は１秒当たり１００万パケットに及ぶ場合でも動作可能であるが、図１４のソフトウエア・システムは、より遅いネットワークに適している。当業者にとって、プロセッサが高速化されるにつれて更なるシステムがソフトウエアで実現可能であることは明らかであろう。
【０１６２】
図１０は、ハードウエアで実現されるような分解サブシステム（３０１，ここではサブシステム１０００として示される）を描いている。メモリ１００１は、パターン認識データベース・メモリであり、以後分析されるパターンがそこに格納される。メモリ１００２は抽出作業データベース・メモリであり、抽出命令がそこに格納される。１００１および１００２両者は、図３の内部データ構造３０８に対応する。典型的には、システムはマイクロプロセッサ（図示せず）によって初期化され、その時点でこれらのメモリは、内部バス１００３および１００４を介してホスト・インターフェース・マルチプレクサおよび制御レジスタ１００５を通じてロードされる。１００１および１００２の内容は、図３のコンパイル・プロセス３１０により取得されるのが好ましい。
【０１６３】
分解システムへのパケットは１０１２を介して、分解入力バッファ・メモリ１００８に入り、これは入力バッファ・インターフェース・コントローラ１０２２を制御する制御信号１０２１，１０２３を利用して行われる。バッファ１００８およびインターフェース・コントローラ１０２２は、パケット捕捉装置（図示せず）に結合する。バッファ捕捉装置はパケット開始信号１０２１を生成し、インターフェース制御１０２２は次のパケット信号（すなわちデータを受信する準備完了信号）１０２３を生成し、分解入力バッファ・メモリ１００８へのデータ・フローを制御する。パケットが、バッファ・メモリ１００８へのロードを開始すると、パターン認識エンジン（ＰＲＥ）１００６は、図３のブロック３０４で説明した入力バッファ・メモリにおける動作を実行する。すなわち、プロトコル形式、およびパケットに存する各プロトコル階層に関するヘッダが判定される。
【０１６４】
パケットが包含するプロトコルを認識するために、ＰＲＥはデータベース１００１、およびバッファ１００８内のパケットを探索する。一実施例では、データベース１００１は一連のリンクされた探索テーブルを含む。各探索テーブルは８ビットのアドレス指定を使う。第１探索テーブルは常にアドレス０におけるものである。パターン認識エンジンは、制御レジスタからのベース・パケット・オフセットを利用して比較を開始する。この値は現在のオフセット・ポインタ（ＣＯＰ）にロードされる。パターン認識エンジンは、分解入力バッファからベース・パケット・オフセットにおけるバイトを読み取り、それを第１探索テーブルへのアドレスとして利用する。
【０１６５】
各探索テーブルは、他の探索テーブルにリンクするワードを返す、または端末フラグを返す。探索テーブルが認識事象(recognition  event)を引き起こす場合、データベースはスライサのための命令も返す。最終的にＣＯＰに加える値も返す。
【０１６６】
ＰＲＥ１００６は比較エンジンを含む。比較エンジンは、プロトコル形式フィールドを検査する第１ステージを有し、それが８０２．３パケットであるか、およびフィールドが長さとして取り扱われるべきか否かを判定する。長さでない場合は、プロトコルは第２ステージで検査される。第１ステージは、プログラム可能でない唯一のプロトコルのレベルである。第２ステージは、将来のプロトコル付加のために定義された２つの完全な１６ビット対応の内容アドレス可能なメモリ(CAM:  content  addressable  memory)を有する。
【０１６７】
ＰＲＥがパターンを認識するときはいつでも、抽出エンジン（「スライサ」とも呼ばれる）１００７用の命令を生成する。認識されたパターンおよび命令は抽出エンジン１００７に送付され、分解レコードを形成するためにパケットから情報を抽出する。こうして、抽出エンジンの動作が、図３のブロック３０６，３１２において実行される。命令は、抽出命令ポインタの形でＰＲＥ１００６からスライサ１００７に送付され、抽出エンジン１００７に、抽出作業データベース・メモリ（すなわち、スライサ命令データベース）１００２においてどこでその命令を見出すべきかを知らせる。
【０１６８】
ＰＲＥ１００６がプロトコルを認識すると、抽出器に対してプロトコル識別子およびプロセス・コードの両者を出力する。プロトコル識別子はフロー署名に追加され、プロセス・コードは命令データベース１００２からの第１命令を取得するために使用される。命令は、長さだけでなく、オペレーション・コードおよび通常はソースおよびあて先オフセットを含む。オフセットおよび長さはバイト単位である。典型的な動作は、移動(MOVE)命令である。この命令はスライサ１００７に対して、入力バッファ１００８から出力バッファ１０１０へ修正なしにデータのｎバイトをコピーするよう告げる。抽出器はバイトごとのバレル・シフタ(byte-wise  barrel  shifter)を有し、移動されるバイトがフロー署名に包含され得るようにする。抽出器はＨＡＳＨと呼ばれる他の命令を包含する。この命令は抽出器に対して、入力バッファ１００８からＨＡＳＨ生成器へコピーするよう告げる。
【０１６９】
これらの命令は、入力バッファ・メモリ内のパケットの選択された要素を抽出し、分解出力バッファ・メモリ１０１０へデータを転送するためのものである。いくつかの命令はハッシュも生成する。
【０１７０】
抽出エンジン１００７およびＰＲＥは、パイプラインとして動作する。すなわち、抽出エンジン１００７は、ＰＲＥ１００６によって既に処理された入力バッファ１００８内のデータに対する抽出作業を実行する一方、更なる（すなわちあとに到着する）パケット情報がＰＲＥ１００６によって同時に分解される。これは、パケットの高速到着レートに対応するのに充分な高速処理を可能にする。
署名を形成するために使用したパケットの選択された部分総てが抽出されると、分解出力バッファ・メモリ１０１０にハッシュがロードされる。更なる分析のために必要とされるパケットからの任意の付加的なペイロードも包含される。分解出力メモリ１０１０は、分析インターフェース制御１０１１により分析サブシステムとのインターフェース機能を行う。ひとたびパケットの情報の全てが分解出力バッファ・メモリ１０１０内にあると、データ準備完了信号１０２５が分析インターフェース制御によってアサートされる。分析準備完了信号１０２７がアサートされると、分解サブシステム１０００からのデータは、１０１３を通じて分析サブシステムに移動させられる。
【０１７１】
図１１は、分析サブシステムに関するハードウエア要素およびデータ・フローを示し、図３の分析サブシステム３０３の機能を実行する。分析器は動作に先立って初期化され、初期化は、コンパイル・プロセス３１０で生成される状態処理情報を、状態プロセッサ命令データベース（ＳＰＩＤ）メモリ１１０９とも呼ばれる状態処理用のデータベース・メモリにロードすることを含む。
【０１７２】
分析サブシステム１１００は、分析ホスト・インターフェース・コントローラ１１１８を利用するホスト・バス・インターフェース１１２２を有し、この分析ホスト・インターフェース・コントローラ１１１８はキャッシュ・システム１１１５へアクセス可能である。キャッシュ・システムは、システムの状態プロセッサ１１０８へのおよびそこからの双方向アクセス機能を有する。状態プロセッサ１１０８は、ホスト・バス・インターフェース１１２２を介して与えられる情報に基づいて状態プロセッサ命令データベース・メモリ１１０９の初期化を受け持つ。
【０１７３】
ＳＰＩＤ１１０９がロードされると、分析サブシステム１１００は分解レコードを受信し、これは、分解装置から一体化フロー・キー・バッファ（ＵＦＫＢ）１１０３へ到来するパケット署名およびペイロードより成る。ＵＦＫＢは、ＵＦＫＢレコードを維持するよう構成されたメモリより成る。ＵＦＫＢレコードは本質的には分解レコードであり；ＵＦＫＢは、処理された又は処理中のパケットのレコードを有する。さらに、ＵＦＫＢは、修正可能なステータス・フラグとして機能する１つまたはそれ以上のフィールドを提供し、異なるプロセスを同時に走らせることを可能にする。
【０１７４】
３つのプロセス・エンジンが同時に走り、ＵＦＫＢ１１０３内のレコードにアクセスする。その３つとは：探索／更新エンジン（ＬＵＥ）１１０７，状態プロセッサ（ＳＰ）１１０８，およびフロー挿入および除去エンジン（ＦＩＤＥ）１１１０である。これらの各々は、１つ又はそれ以上の有限状態マシン(FSM:  finite  state  machine)によって実装される。有限状態マシンおよび一体化フロー・キー・バッファ１１０３の間で双方向のアクセスが存在する。ＵＦＫＢレコードは、パケット・シーケンス番号を格納するフィールド、および状態処理３２８を実装する状態プロセッサ１１０８に対するプログラム・カウンタの形の状態情報が満たされた別のフィールドを含む。任意のエントリに対するＵＦＫＢのステータス・フラグは、ＬＵＥが終了したこと、およびＬＵＥが状態プロセッサにそのエントリの処理を転送することを含む。ＬＵＥ終了インジケータは、ＬＵＥに対する次のエントリが何であるかを示すためにも使用される。状態プロセッサが現在のフローに関して終了したことを示し、および状態プロセッサに対する次のエントリが何であるかを示すフラグも提供される。また、状態プロセッサが、ＵＦＫＢエントリの処理をフロー挿入および削除エンジンに転送することを示すフラグも提供される。
【０１７５】
新たなＵＦＫＢレコードは最初にＬＵＥ１１０７によって処理される。ＬＵＥ１１０７によって処理されたレコードは、状態プロセッサ１１０８によって処理されてもよい。ＵＦＫＢレコード・データは、状態プロセッサ１１０８によって処理された後に、あるいはＬＵＥのみによって処理された後に、フロー挿入／削除エンジン１１１０によって処理されてもよい。特定のエンジンが一体化フロー・キー・バッファ・エントリを処理するために適用されたか否かは、完了時にエンジンによってセットされる状態フィールドによって判別される。一実施例にあっては、ＵＦＫＢエントリにおけるステータス・フラグは、エントリが新規なのか既存のものかを示す。他の実施例では、ＬＵＥは、そのエントリを処理のために状態プロセッサに渡すためのフラグを発行し、新規レコードに要求される動作がＳＰ命令に包含される。
【０１７６】
各ＵＫＦＢエントリは３つ総てのエンジンで処理される必要はない点に留意すべきである。さらに、いくつかのＵＫＦＢエントリは、特定のエンジンで複数回処理される必要もあり得る。
【０１７７】
これら３つのエンジンの各々は、キャッシュ・エンジンを含むキャッシュ・サブシステム１１１５に対する双方向アクセス機能を有する。キャッシュ１１１５は、システム内の５つの異なる場所においておよびそこから流れる情報を有するように設計される。その５つの場所とは：上記３つのエンジン、一体化メモリ・コントローラ（ＵＭＣ）１１１９およびメモリ・インターフェース１１２３を介する外部メモリ、ならびに分析ホスト・インターフェースおよび制御装置（ＡＣＩＣ）１１１８およびホスト・インターフェース・バス（ＨＩＢ）１１２２を介するマイクロプロセッサである。分析マイクロプロセッサ（又は専用論理プロセッサ）は、キャッシュ内にデータを直接的に挿入および修正することが可能である。
【０１７８】
キャッシュ・サブシステム１１１５は、１組の内容アドレス指定可能なメモリ・セル（ＣＡＭ）を有する連想式の(associative)キャッシュであり、各メモリ・セルは、アドレス部と、キャッシュされたフロー・エントリを含むキャッシュ・メモリ（例えばＲＡＭ）を指すポインタ部とを有する。ＣＡＭは、上位ＣＡＭから下位ＣＡＭの順序のスタックとして並べられる。下位のＣＡＭのポインタは、最も長く未使用である(LRU:  least  recently  used)キャッシュ・メモリ・エントリを指す。キャッシュ・ミスが生じると常に、下位ＣＡＭにより示されるキャッシュ・メモリの内容は、フロー・エントリ・データベース３２４からのフロー・エントリによって置換される。これは最も最近使用されたエントリとなり、最下位ＣＡＭの内容は最上位ＣＡＭに移動させられ、総てのＣＡＭ内容がシフト・ダウンされる。したがって、キャッシュは、真のＬＲＵ置換方針を利用する連想式のキャッシュである。
【０１７９】
ＬＵＥ１１０７は先ずＵＦＫＢを処理し、基本的には図３のブロック３１４，３１６の動作を実行する。信号がＬＵＥに対して提供され、「新規」のＵＦＫＢエントリが利用可能であることを通知する。ＬＵＥはＵＦＫＢエントリ内でハッシュを利用し、キャッシュから４つまでのバケットの一致するビンを読み込む。キャッシュ・システムは一致するビンを取得しようとする。一致するビンがそのキャッシュ内にない場合は、キャッシュ１１１５はＵＭＣ１１１９に対して、外部メモリから一致するビンを取得するよう要求する。
【０１８０】
ハッシュを利用してフロー・エントリが見出された場合に、ＬＵＥ１１０７は各バケットを探索し、その署名を利用してＵＦＫＢエントリの署名と比較し、一致が現れるまで又はそれ以上バケットがなくなるまで継続される。
【０１８１】
一致が得られない場合、すなわちキャッシュがキャッシュからフロー・エントリのビンを提供するのに失敗した場合、タイムスタンプがＵＦＫＢレコードのフロー・キーで設定され、プロトコル識別および状態判定が、初期化中にコンパイル・プロセス３１０によってロードされたテーブルを利用してなされ、そのレコードに対するステータスは、ＬＵＥがそのレコードを処理したことを示すよう設定され、ＵＦＫＢエントリが状態処理を開始する準備が整っていることの指示がなされる。識別および状態判定はプロトコル識別子を生成し、これは好適実施例では状態プロセッサに対する「ジャンプ・ベクトル」であり、このＵＦＫＢエントリについてＵＦＫＢによって維持され、状態プロセッサによって、その特定のプロトコルに対する状態処理を開始するために使用される。例えば、ジャンプ・ベクトルは、その状態を処理するためにサブルーチンへジャンプする。
【０１８２】
一致が得られ、ＵＦＫＢエントリのパケットが以前に遭遇したフローに関するものである場合は、計算コンポーネントは、タイムスタンプを含む格納された１つ又はそれ以上の統計的指標をフロー・エントリに加える。さらに、最後に格納されたタイムスタンプからの時間差が格納されてもよく、パケット・カウントが更新されてもよい。フロー・エントリから得られるフローの状態は、データベース３２４のフロー・エントリに格納されたプロトコル識別子を調べることによって調査される。その値が、それ以上の分類を要しないことを示す場合は、そのレコードに対してステータスが設定され、ＬＵＥがそのレコードを処理し終えたことを示す。好適実施例では、プロトコル識別子は、プロトコルを状態処理するためのサブルーチンへの状態プロセッサ用のジャンプ・ベクトルであり、ゼロであるジャンプ・ベクトルによって好適実施例において更なる分類を要しないことが示される。プロトコル識別子が更なる処理を示す場合は、ＵＦＫＢエントリが状態処理を開始する準備が整っていることが示され、およびそのレコードに対するステータスは、ＬＵＥがそのレコードを処理し終えたことを知らせるよう設定される。
【０１８３】
状態プロセッサ１１０８は、ＬＵＥが完了した後にＵＦＫＢエントリに従ってキャッシュ・システム内で情報を処理する。状態プロセッサ１１０８は状態プロセッサ・プログラム・カウンタＳＰＰＣを含み、初期化中にコンパイラ・プロセス３１０によってロードされた状態プロセッサ命令データベース１１０９におけるアドレスを生成する。ＳＰＩＤアドレスを生成する命令ポインタ（ＳＰＩＰ）も含む。命令ポインタは、インクリメントされ、又は条件分岐を支援するジャンプ・ベクトル・マルチプレクサからロードされることが可能である。ＳＰＩＰは以下の３つのソースの１つからロードされることが可能である：（１）ＵＦＫＢからのプロトコル識別子，（２）目下デコードされる命令からの直近の（immediate）ジャンプ・ベクトル，（３）状態プロセッサ内に含まれる算術論理ユニット（ＳＰＡＬＵ）によって提供される値である。
【０１８４】
既知のプロトコル識別子に関してフロー・キーがＬＵＥによってＵＦＫＢ内に配置された後に、プログラム・カウンタは分解装置によって認識された最後のプロトコルに関して初期化される。この最初の命令は、デコードされたプロトコルを解析するサブルーチンへのジャンプである。
【０１８５】
状態プロセッサＡＬＵ（ＳＰＡＬＵ）は、状態プロセッサ命令を実装するために必要な算術、論理およびストリング比較(String  Compare)機能の総てを有する。ＳＰＡＬＵの主要ブロックは：ＡおよびＢレジスタ、命令デコードおよび状態マシン、ストリング参照メモリ、サーチ・エンジン、出力データ・レジスタおよび出力制御レジスタである。
【０１８６】
サーチ・エンジンは目標サーチ・レジスタ・セット、参照サーチ・レジスタ・セット、および２つのオペランドを排他的ＯＲ演算することによって比較する比較ブロックを含む。
【０１８７】
ＵＦＫＢがプログラム・カウンタを設定した後に、１つ又はそれ以上の状態作業のシーケンスが状態プロセッサ１１０８で実行され、この特定のパケットに対するフロー・キー・バッファ・エントリにおけるものであるパケットを更に分析する。
【０１８８】
図１３は、状態プロセッサ１１０８の動作を記述する。状態プロセッサは１３０１において、処理されるべき一体化フロー・キー・バッファ・エントリと共に入力される。ＵＦＫＢエントリは新規であるか、または見出された（既存の）フロー・エントリに対応する。ＵＦＫＢエントリは１３０１において一体化フロー・キー・バッファ１１０３から取得される。１３０３において、ＵＦＫＢエントリに対するプロトコル識別子を利用して、状態プロセッサの命令カウンタを設定する。状態プロセッサ１１０８は、分解サブシステム３０１によって認識された最後のプロトコルをジャンプ・テーブル内でのオフセットとして利用してそのプロセスを開始する。ジャンプ・テーブルは、そのプロトコルを利用するための命令へ導くものである。多くの命令は、一体化フロー・キー・バッファ内の何か、または存在する場合はフロー・エントリを検査する。状態プロセッサ１１０８は、検査を実行するため、ビットの検査、比較の実行、加算または減算を行う必要がある場合がある。
【０１８９】
１３０４において、状態プロセッサ命令データベース・メモリ１１０９から第１の状態プロセッサ命令が取得される。状態プロセッサは、１つ又はそれ以上の取得した動作（１３０４）を実行する。本実施例では、各々単独の状態プロセッサ命令は、非常に基本的なものであり（例えば、移動、比較等）、多くのそのような命令が各一体化フロー・キー・バッファ・エントリに対して実行される必要がある。状態プロセッサの１つの特徴は、ＵＦＫＢエントリのペイロード部分において、１つ又はそれ以上（４つまで）の参照ストリングを探索する機能である。これは、特定の探索命令に応答して、状態プロセッサの探索エンジン・コンポーネントによって実行される。
【０１９０】
１３０７において、検査が行われ、そのパケットに関して更に実行されるべき命令の存否を判別する。存在すれば、１３０８において、システムは次の命令を取得するために状態プロセッサ命令ポインタ（ＳＰＩＰ）を設定する。ＳＰＩＰは、現在デコードされている命令における直近のジャンプ・ベクトルによって、又は処理中のＳＰＡＬＵによって提供される値によって設定可能である。
【０１９１】
次に行われる命令が、実行のために取得される（１３０４）。１３０４と１３０７の間の状態処理ループは、行われるべき命令がなくなるまで続く。
【０１９２】
この段階において、特定のパケットに対する処理が最終的な状態になったか否かについて、１３０９で検査が行われる。すなわち、分析器はその特定のパケットだけでなく、そのパケットが属するフロー全体についても処理を行い、そのフローは完全に決定されている。このフローに関して処理すべき状態がそれ以上存在しない場合、１３１１においてプロセッサは処理を最終化する。いくつかの最終状態は、例えば低レベル接続識別子から接続が消滅する場合に、システムにフローを除去するよう告げるところの状態を適切に設ける必要がある。この場合において、１３１１において、フロー・エントリにおいてフロー除去状態が設定され保存される。フロー除去状態は、除去命令が存在しないことを意味するＮＯＰ（ノー・オペレーション）命令でもあり得る。
【０１９３】
ひとたびこのフローについて特定されているような適切なフロー除去命令（ＮＯＰ又はそれ以外）が設定および保存されると、プロセスは１３１３で終了する。状態プロセッサ１１０８は今や、処理を行うための他の一体化フロー・キー・バッファ・エントリを取得することが可能である。
【０１９４】
１３０９において、このフローに関する処理が完了していないと判断されると、１３１０においてシステムは状態プロセッサ命令ポインタを、現在のフロー・エントリに保存する。それは、次にＬＲＥ１１０７がそのフローに合致するＵＦＫＢ内のパケットを見出したときに実行される次の動作となる。このプロセッサは今や、１３１３において、その特定の一体化フロー・キー・バッファ・エントリの処理から抜け出す。
【０１９５】
状態処理は、一体化フロー・キー・バッファ１１０３内の情報およびそのキャッシュにおけるフロー・エントリを更新する。状態プロセッサが処理を終了すると、そのエントリに対してＵＦＫＢにおいて、状態プロセッサが終了したというフラグが設定される。さらに、フローのデータベースにフローが挿入され又はフローのデータベースからフローが削除される必要がある場合は、そのフロー署名およびパケット・エントリに関してフロー挿入／削除エンジン１１１０に制御が渡される。これは、状態プロセッサがそのＵＦＫＢエントリに関するＵＦＫＢ内の他のフラグを設定して、状態プロセッサがそのエントリの処理をフロー挿入および削除エンジンに引き渡すことを示すことによって行われる。
【０１９６】
フロー挿入および削除エンジン１１１０は、フロー・エントリ・データベースを維持することを受け持つ。特に、フロー・データベースにおいて新たなフローを生成するため、および再利用できるようデータベースからフローを削除するためである。
【０１９７】
フロー挿入のプロセスは、図１２に関して説明される。フローは、ハッシュ値によってバッケトのビンにグループ化される。このエンジンが処理するＵＦＫＢエントリは、新規であってもよいし、そうでない場合は状態プロセッサが生成される必要性を通知したものである。図１２は新規のエントリが生成される場合を示す。会話レコード・ビン（４つのレコードに関して４つのバケットを含むことが好ましい）が１２０３で取得される。これはＵＦＫＢのハッシュに合致するビンであり、よってこのビンはＬＵＥによって既にＵＦＫＢエントリを探索したものであり得る。１２０４において、ＦＩＤＥ１１１０は、レコード・ビン／バケットがキャッシュ・システム１１１５で維持されるように要求する。１２０５において、キャッシュ・システム１１１５が、ビン／バケットが空であることを示す場合は、ステップ１２０７でフロー署名を（ハッシュと共に）バケットに挿入し、そのバケットはタイムスタンプを利用してキャッシュ１１１５のキャッシュ・エンジンにおいて「使用済み」にマークされ、プロセスの間維持される。１２０９において、ＦＩＤＥ１１１０は、ビンおよびバケット・レコード・フロー署名をそのパケットと比較し、要素の総てがレコードを完了するのに適切であることを確認する。１２１１において、システムは、キャッシュ・システム（および外部メモリ）においてレコード・ビンおよびバケットを「処理中」としておよび「新規」としてマークする。１２１２において、フロー・レコードに関する最初の統計定期指標がキャッシュ・システムに設定される。好適実施例ではこれは統計値を維持するために使用されるカウンタ群をクリアし、および特定のフローに対して見出される第１パケットに関し、分析器によって要求される統計処理のための他の手続きを実行してもよい。
【０１９８】
ステップ１２０５に戻って、バケットが空でなければ、ＦＩＤＥ１１１０は、キャッシュ・システム内の特定のビンに関する次のバケットを要求する。成功すると、１２０７，１２０９，１２１１および１２１２の処理が該次のバケットに対して繰り返される。１２０８において有効なバケットが存在しない場合は、パケットに関する一体化フロー・キー・バッファ・エントリが「ドロップ(drop)」として設定され、システム内にはバケットが残っていないので、システムはその特定のパケットを処理できないことを示す。プロセスは１２１３で終了する。ＦＩＤＥ１１１０は、ＵＦＫＢに対して、フロー挿入および削除作業がこのＵＦＫＢエントリについて完了したことを示す。これはＵＦＫＢに次のＵＦＫＢレコードをＦＩＤＥに提供させる。
【０１９９】
特定のパケットおよびそのフロー署名にアクセスしこれを管理することを要求される総てのエンジンによって一体化フロー・キー・バッファ・エントリに対して一群の作業が実行されると、一体化フロー・キー・バッファ・エントリは「完了」としてマークされる。この要素は、分解および抽出システムから到来する次のパケットおよびフロー署名に対して、分解インターフェースによって使用される。
【０２００】
総てのフロー・エントリは外部メモリ内に維持され、いくつかはキャッシュ１１１５に維持される。キャッシュ・システム１１１５は、フロー・データベースにアクセスし、メモリ・インターフェース１１２３の反対側に存するデータ構造を理解できる程度にインテリジェント化されている。探索／更新エンジン１１０７は、更なる処理のために、キャッシュ・システムが特定のフロー又はフローの「バケット」を一体化メモリ・コントローラ１１１９からキャッシュ・システムへ引き出すことを要求することが可能である。探索／更新エンジンの要求を利用して見出されると、状態プロセッサ１１０８は、キャッシュ・システムで見出された情報に対して動作することが可能であり、一体化フロー・キー・バッファ１１０３内の情報に基づいて要求された場合に、フロー挿入／削除エンジン１１１０はキャッシュ・システムにおいて新たなエントリを生成することが可能である。キャッシュは、メモリ・インターフェース１１２３および一体化メモリ・コントローラ１１１９を通じて、メモリから、要求された情報を取り出し、メモリ・コントローラ１１１９を通じてメモリ内で要求された情報を更新する。
【０２０１】
特定のハードウエア実装についての図１１のモジュールの外部の、システムのコンポーネントに対するいくつかのインターフェースが存在する。これらは、汎用インターフェースとして設計されるホスト・バス・インターフェース１１２２を含み、マイクロプロセッサまたはマルチプレクサ（ＭＵＸ）システムのような任意の種類の外部処理システムと共に動作することが可能である。したがって、図１１および図１２の全体的なトラフィック分類システムを、他の処理システムに結合して、分類システムを管理し、システムが収集したデータを抽出することが可能である。
【０２０２】
メモリ・インターフェース１１２３は、フロー・エントリを格納するための所望の様々なメモリ・システムとインターフェースを行うよう設計される。一般的なダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ），同期式ＤＲＡＭ，同期グラフィック・メモリ（ＳＧＲＡＭ），スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）等のような異なる形式のメモリ・システムを利用することが可能である。
【０２０３】
図１０はいくつかの「一般的な」インターフェースも包含する。パケット入力インターフェース１０１２が存在し、これは、入力バッファ・インターフェース制御１０２２の信号と並んで動作する。これらは、パケット情報を分解装置に供給することが可能な任意の種類の汎用システムに関して利用可能であるように設計される。他の汎用インターフェースは、ホスト・インターフェース・マルチプレクサおよび制御レジスタ１００５からおよびそこへのパイプ１０３１，１０３３のインターフェースである。これは、分解システムを、例えばマイクロプロセッサ又は他の種類の外部ロジックのような外部システムによって管理可能にし、および外部システムが分解装置をプログラムするか他の仕方で分解装置を制御することを可能にする。
【０２０４】
本発明のこの側面の好適実施例は、ＶＨＤＬまたはベリログ(Verilog)のようなハードウエア記述言語（ＨＤＬ）で記述される。該好適実施例は、単独チップ・システムとして使用可能であるように、あるいは例えばネットワーク内でトラフィックを形成および分析することに関係した目的で設計される他の汎用システムに統合されるように、ＨＤＬで設計および生成される。ベリログ又はＨＤＬによる実装は、ハードウエアを記述する１つの方法に過ぎない。
【０２０５】
あるハードウエア実装によれば、図１０，図１１に示される要素は、６つのフィールド・プログラム可能なゲート・アレイ（ＦＰＧＡ）の組で実現される。これらのＦＰＧＡの境界は以下のとおりである。図１０の分解サブシステムは２つのＦＰＧＡとして実現され；１つのＦＰＧＡはブロック１００６，１００８，１０１２，一部の１００５およびメモリ１００１を含む。第２のＦＰＧＡは、１００２，１００７，１０１３，１０１１，一部の１００５を含む。図１１を参照すると、一体化探索バッファ１１０３が単独のＦＰＧＡとして実現されている。状態プロセッサ１１０８および一部の状態プロセッサ命令データベース・メモリ１１０９は別のＦＰＧＡである。状態プロセッサ命令データベース・メモリ１１０９の一部は外部ＳＲＡＭ内に維持される。探索／更新エンジン１１０７およびフロー挿入／削除エンジン１１１０は別のＦＰＧＡ内である。第６のＦＰＧＡは、キャッシュ・システム１１１５，一体化メモリ制御１１１９，および分析ホスト・インターフェースおよび制御１１１８を含む。
【０２０６】
ＦＰＧＡのような用途特定集積回路（ＡＳＩＣ）の集合としてではなく、１つ又はそれ以上のＶＬＳＩ装置としてシステムを実現することが可能な点に留意すべきである。将来的に装置密度が増加し続け、ゆくゆくは完全なシステムが、大きなシングル・チップ装置の部分ユニット（コア）を形成するようになることも予想される。
【０２０７】
［本発明の動作］
図１５は、ネットワーク・モニタ３００がネットワーク１０２内でどのようにしてトラフィックを分析するために使用されるかの例を示す。パケット捕捉装置１５０２は、ネットワーク１０２上の接続点１２１から総てのパケットを捕捉し、両方向における地点１２１を通過する全パケットがモニタ３００に供給される。モニタ３００は、フロー署名を判別する分解サブシステム３０１と、各パケットのフロー署名を分析する分析サブシステム３０３とを有する。メモリ３２４を利用して、モニタ３００で判別および更新されたフローのデータベースを格納する。例えば汎用コンピュータのような任意のプロセッサであり得るホスト・コンピュータ１５０４は、メモリ３２４内のフローを分析するために使用される。従来と同様に、ホスト・コンピュータ１５０４は、ホスト・メモリ１５０６として示される例えばＲＡＭのようなメモリを有する。更に、ホストはディスクを含むことも可能である。ある応用例では、システムがＲＭＯＮプローブとして動作可能であり、ホスト・コンピュータは、ネットワーク１０２に接続されるネットワーク・インターフェース・カード１５１０に結合される。
【０２０８】
本発明の好適実施例は、任意的な簡単ネットワーク管理プロトコル(SNMP:  Simple  Network  Management  Protocol)実装によってサポートされる。図１５は、どのようにして、例えば、ネットワーク・インターフェース・カードを利用してＲＭＯＮ情報をネットワークに送るＲＭＯＮプローブを実現するかを説明する。商用のＳＮＭＰ手段も利用可能であり、そのような手段の利用は、本願の好適実施例を任意のプラットフォームに移植するプロセスを簡潔にできる。
【０２０９】
更に、ＭＩＢコンパイラが利用可能である。ＭＩＢコンパイラは、専用のＭＩＢ拡張(proprietary  MIB  extension)の生成および保守を非常に簡潔にする。
【０２１０】
［パケット明瞭化の例］
モニタ３００は、特に分析器３０３は、パケット交換に関して状態分析を実行することが可能であり、これは一般に「サーバ通知（server  announcement）」形式の交換として言及される。サーバ通知は、複数のクライアントから同時にアクセスされることの可能な複数のアプリケーションに関し、サーバ間における通信を容易にするために使用されるプロセスである。多くのアプリケーションは、サーバ通知プロセスを、単独ポート又はソケットを多くのアプリケーションおよびサービスに多重化する手段として使用する。この種の交換に関し、メッセージがブロードキャスト又はマルチキャストの手法でネットワーク上で伝送され、サーバおよびアプリケーションを通知し、ネットワーク内の総ての局(station)がこれらのメッセージを受信およびデコードしうる。そのメッセージは、特定のサーバに関する特定のアプリケーションを通信するために適切な接続点を、局が導出することを可能にする。サーバ通知の手法を利用して、特定のアプリケーションは、ＩＰプロトコル・スイートにおけるようなＴＣＰ又はＵＤＰソケット又はポートの形のサービス・チャネルの利用、またはノベル(Novell)ＩＰＸプロトコル・スイートにおけるようなＳＡＰの利用を通信する。
【０２１１】
分析器３０３は、パケット交換の「イン・ストリーム分析」(in-stream  analysis)を実行することも可能である。「イン・ストリーム分析」の方法は、一次的又は二次的な認識プロセスとして利用される。一次プロセスとしてのイン・ストリーム分析は、詳細な情報の抽出を支援し、特定のアプリケーションおよびアプリケーション・コンポーネントの両者を更に認識するために使用される。イン・ストリーム分析の好適な例は、ウェブ・ベースのアプリケーションである。例えば、一般的に使用されるポイントキャスト・ウェブ情報アプリケーションは、このプロセスを利用して認識可能であり；ポイントキャスト・サーバおよびクライアントの間の初期接続の最中に、特定のキー・トークン(key  token)がデータ交換において存在し、これはポイントキャストを認識するために生成される署名になる。
【０２１２】
イン・ストリーム分析プロセスは、サーバ通知プロセスと組み合わせることも可能である。多くの場合、イン・ストリーム分析は別の認識プロセスを増強する。サーバ通知とイン・ストリーム分析を結合させる例は、ＳＡＰおよびＢＡＡＮのような商用アプリケーションに見受けられる。
【０２１３】
「セッション・トラック〔追跡〕」は、クライアント／サーバ・パケット交換においてアプリケーションを追跡するための一次プロセスの１つとしても知られる。セッションを追跡するプロセスは、所定のソケット又はポート番号に対する初期接続を要する。この通信方法は、多様なトランスポート階層プロトコルにおいて使用される。ＩＰプロトコルのＴＣＰおよびＵＤＰ転送プロトコルにおいて最もよく見受けられる。
【０２１４】
セッション追跡の最中において、クライアントは、特定のポート又はソケット番号を利用してサーバに要求を行う。最初の要求は、サーバに、クライアントとサーバの間でデータの残りを交換するためのＴＣＰまたはＵＤＰポートを形成させる。次いで、サーバは、この新たに形成されたポートを使ってクライアントの要求に返答する。クライアントがサーバに接続するために使用した当初のポートは、このデータ交換中に再び使用されることはないであろう。
【０２１５】
セッション追跡の一例は、自明ファイル転送プロトコル(TFTP:  Trivial  File  Transfer  Protocol)であり、これはディレクトリ又はパスワードの機能を有しないＴＣＰ／ＩＰ  ＦＴＰプロトコルの一種である。ＴＦＴＰのクライアント／サーバ交換プロセスの間、パケット交換を開始するために特定のポート（ポート番号６９）が常に使用される。従って、クライアントが通信のプロセスを開始するとき、ＵＤＰポート６９に対して要求がなされる。サーバがこの要求を受信すると、新たなポート番号がサーバ上に形成される。サーバはその新たなポートを利用してクライアントに返答する。この例で明らかなことは、ＴＦＴＰを認識するために、ネットワーク・モニタ３００は、クライアントからの初期の要求を分析し、それについての署名を生成するということである。モニタ３００はその署名を利用して返答を認識する。モニタ３００は、キー・ポート情報を利用してサーバからの返答を分析し、それを利用して、データ交換の残余のパケットを監視するための署名を形成する。
【０２１６】
ネットワーク・モニタ３００は、ネットワークにおける特定の接続の現状を理解することも可能である。アプリケーションを正しく識別するために、接続指向の交換は、状態追跡からしばしば恩恵を得る。具体例は、クライアントとサーバの間で情報を送信する信頼できる手段を提供する、一般的なＴＣＰ転送プロトコルである。データ交換が開始されると、同期メッセージに関するＴＣＰリクエストが送出される。このメッセージは特定のシーケンス番号を含み、このシーケンス番号がサーバからの受取確認を追跡するために使用される。サーバが同期リクエストを受取確認すると、クライアントおよびサーバ間でデータが交換されうる。通信がもはや必要でなくなると、クライアントはサーバに対して終了または完了メッセージを送信し、サーバはこの終了リクエストを、そのリクエストからのシーケンス番号を含む返答をもって、受取確認する。このような接続指向の交換の状態は、様々な形式の接続および保守メッセージに関連する。
【０２１７】
［サーバ通知例］
サーバ通知プロトコルの個別的な方法には様々なものがある。しかし、根底にある基本は同様なものである。典型的なサーバ通知メッセージが、ネットワークにおいて１つ又はそれ以上のクライアントに送出される。この形式の通知メッセージは、特定の内容を有し、本願の他の実施例ではシステム内のフロー・エントリのデータベース内でサルベージおよび維持される。通知は１つ又はそれ以上の局(station)に送られるので、そのサーバとの将来的なパケット交換に関わるクライアントは、通知された情報が知られていることを想定し、本願のモニタもある側面では同様のことを想定する。
【０２１８】
サン(Sun)ＲＰＣは、サン・マイクロシステムズ，インコーポレーション（カリフォルニア州パロアルト）による遠隔手順呼び出し（ＲＰＣ）という、あるプログラムが遠隔装置における他のプログラムのサービスを利用できるようにするプログラミング・インターフェースの実装である。ここで、サンＲＰＣ例を利用して、モニタ３００がどのようにしてサーバ通知を捕捉するかを説明する。
【０２１９】
サーバまたは手続きの使用を希望する遠隔プログラム又はクライアントは、ＲＰＣプロトコルが利用可能な接続を確立する必要がある。
【０２２０】
サンＲＰＣプロトコルを走らせる各サーバは、ポート・マッパと呼ばれるプロセスおよびデータベースを維持しなければならない。ポート・マッパは、サンＲＰＣプログラムまたはアプリケーションと、ＴＣＰまたはＵＤＰソケット又はポート（ＴＣＰまたはＵＤＰ実装について）との間の直接的な関連付けを形成する。アプリケーション又はプログラム番号は、ＩＣＡＮＮ（割当名称および番号に関するインターネット企業，www.icann.org）によって割り当てられる３２ビットの固有の識別子である。ＩＣＡＮＮは、インターネットの諸プロトコルに関する膨大な数のパラメータ（ポート番号、ルータ・プロトコル、マルチキャスト・アドレス等）を管理する。サンＲＰＣサーバにおける各ポート・マッパは、特定のリクエストまたは差し向けられた通知を利用することによって、固有のプログラム番号と特定の転送ソケットとの間のマッピングを提供することが可能である。ＩＣＡＮＮによれば、ポート番号１１１がサンＲＰＣに割り当てられる。
【０２２１】
例として、所定のＵＤＰ又はＴＣＰソケットにおいてサーバ（例えば、図１の１１０として示されるサーバ２）に対してクライアント（例えば、図１の１０６として示されるクライアント３）が特定の要求を行うことを考察する。サンＲＰＣサーバ上のポート・マッパ・プロセスがリクエストを受信すると、特定のマッピングが差し向けられた返答においてクライアントに返される。
【０２２２】
１．クライアント（図１のクライアント３，１０６）は、ポート１１１において、ＲＰＣ拘束探索要求(rpcBindLookup)を利用して、ＴＣＰパケットをサーバ２（図１の１１０）に送信する。ＴＣＰ又はＵＤＰポート１１１はサンＲＰＣに常に関連付けられている。この要求は、プログラム（プログラム識別子として）、バージョンを特定し、プロトコル（ＵＤＰまたはＴＣＰ）を特定し得る。
【０２２３】
２．サーバ２（図１の１１０）は、その要求からプログラム識別子およびバージョン識別子を抽出する。サーバは、このパケットがＴＣＰ転送を利用して到来し、何らのプロトコルも指定されていないという事実も使って、その返答でＴＣＰプロトコルを使う。
【０２２４】
３．サーバ１１０は、ＲＰＣ拘束探索要求を利用してＴＣＰパケットをポート番号１１１へ送信する。返答は、将来のやりとりがその特定のＲＰＣプログラム識別子（例えばプログラム‘プログラム’）および使用するためのプロトコル（ＵＤＰまたはＴＣＰ）に関して受け入れられる特定のポート番号（例えば、ポート番号‘ポート’）を含む。
番号‘ポート’がもはやプログラム‘プログラム’に関連しなくなるまで、今後ポート番号‘ポート’が利用されるたびに、パケットがアプリケーション・プログラム‘プログラム’に関連付けられるのが好ましい。フロー・エントリおよび署名を形成することによってネットワーク・モニタ３００は、交換を思い出すための機構を有し、ポート番号‘ポート’を利用する将来のパケットが、ネットワーク・モニタによってアプリケーション・プログラム‘プログラム’と関連付けられるようにする。
サンＲＰＣ拘束探索要求および返答に加えて、たとえば‘プログラム’である特定のプログラムが、例えば番号‘ポート’の特定のポート番号に関連付けられうる他の方法も存在する。１つは、アプリケーション・サービスとポート番号との間の特定の関連付けのブロードキャスト通知によるものであり、サンＲＰＣポート・マッパ通知と呼ばれる。他のものは、たとえば同一のサーバ２であるサーバが、ＲＰＣポート・マッパ返答を用いて、ポートマッパ割当を要求する例えばクライアント１であるクライアントに対して返信する場合のものである。たとえばクライアント２である他のクライアントは、この要求をひょんなことから見ることがあり、そして、その特定のサーバ２に対してポート番号‘ポート’がアプリケーション・サービス‘プログラム’に関連付けられることを知る。ネットワーク・モニタ３００は、ポート番号‘ポート’を利用するサーバ２に対する任意のパケットを、アプリケーション・プログラム‘プログラム’と関連付けることが可能であることが好ましい。
【０２２５】
図９は、サン遠隔手順呼出に関する図３のモニタ３００におけるいくつかの動作のデータフロー９００を表現する。クライアント１０６（例えば図１のクライアント３）が、ネットワークへのインターフェース１１８を通じて、サーバ１１０（例えば図１のサーバ２）へ、サーバのネットワークへのインターフェース１１６を通じて通信を行っているとする。さらに、遠隔手順呼出を利用してサーバ１１０と通信を行うことを仮定する。データ・フロー９００における１つの経路は、ステップ９１０から始まり、遠隔手順呼出の拘束探索要求がクライアント１０６から発行され、サーバ状態生成ステップ９０４で終了する。このようなＲＰＣ拘束探索要求は、使用する‘プログラム’，‘バージョン’および‘プロトコル’，例えばＴＣＰまたはＵＤＰに関する値を含む。ネットワーク・モニタ３００におけるサンＲＰＣ分析のためのプロセスは、以下の特徴を含む：
・プロセス９０９：‘プログラム’，‘バージョン’および‘プロトコル’（ＴＣＰまたはＵＤＰ）の抽出。サンＲＰＣを示すところの１１１であるＴＣＰまたはＵＤＰポート（プロセス９０９）の抽出。
【０２２６】
・プロセス９０８：サンＲＰＣパケットのデコード。ＩＤに関するＲＰＣ形式フィールドの検査。値がポート・マッパであれば、対になるソケットを保存する（すなわち、あて先アドレスについてはdest、ソース・アドレスについてはsrc）。ポートのデコードおよびマッピング，ソケット／アドレス・キーと一緒にポートの保存。マッパ・パケットにつき２以上の対が存在し得る。署名の形成（例えばキー）。フロー・エントリがデータベー３２４で形成される。要求の保存はこれで完了する。
【０２２７】
後に、サーバ（プロセス９０７）は、ＲＰＣ拘束探索返答を発行する。パケット・モニタ３００は、そのパケットから署名を抽出し、以前格納したフローからそれを認識する。モニタはプロトコル・ポート番号を取得し（９０６）、リクエストを探索する（９０５）。新たな署名（すなわち、キー）が形成され、サーバ状態の形成（９０４）は、そのフロー・エントリ・データベースにおける新たな署名によって識別されるエントリとして格納される。その署名は今や、サーバに関連するパケットを識別するために使用されうる。
【０２２８】
サーバ状態生成ステップ９０４は、拘束探索要求／返答の対だけでなく、９０１として示されるＲＰＣ返答ポート・マッパ・パケット又は９０２として示されるＲＰＣ通知ポート・マッパからも到達可能である。遠隔手順呼出プロトコルは、特定のアプリケーション・サービスを提供可能であることを通知し得る。クライアントおよびサーバの間で交換が起こる際に、本願実施例は分析できることが好ましく、ネットワークにおけるサービスの通知を受信した局を追跡できることが好ましい。
【０２２９】
ＲＰＣ通知ポート・マッパ通知９０２は、同報通信（ブロードキャスト）である。これは、様々なクライアントに同様な動作群を実行させ、例えば、その通知から取得した情報を保存させる。ＲＰＣ返答ポート・マッパ・ステップ９０１は、ポート・マッパ・リクエストに対する返答におけるものであり、これもブロードキャストされる。これは総てのサービス・パラメータを含む。
【０２３０】
こうして、モニタ３００は、特定のサービス‘プログラム’に関連するフローの後の分類に対するそのような状態の総てを形成および保存する。
【０２３１】
図２は、モニタ３００が、サンＲＰＣの例において、署名およびフロー状態をどのようにして形成するかを示す。例えばサン・マイクロシステムズ遠隔手順呼出プロトコルにおいて、複数のパケット２０６−２０９が交換される。本発明の方法実施例は、１対のフロー署名「署名１」２１０と「署名２」２１２を、パケット２０６，２０７において見出された情報から生成し、パケット２０６、２０７は、本実施例ではサンＰＲＣ拘束探索要求および返答にそれぞれ対応する。
【０２３２】
まず、サンＲＰＣ拘束探索要求を考察する。パケット２０６が、クライアント３からサーバ２へ伝送されたリクエストに対応すると仮定する。このパケットは、本発明により署名を形成する際に使用される重要な情報を含む。ソースおよびあて先ネットワーク・アドレスは、各パケットの最初の２つのフィールドを占有し、パターン・データベース３０８におけるパターンに従って、フロー署名（図２のキー１の２３０として示される）もこれら２つのフィールドを含み、分解サブシステム３０１は署名、キー１（２３０）にこれら２つのフィールドを含める。図２において、アドレスがクライアント１０６（２０２としても示される）を識別する場合、図中で使用されるラベルは「Ｃ１」である。アドレスがサーバ１１０（サーバ２０４としても示される）を識別する場合、図中で使用されるラベルは「Ｓ１」である。パケット２０６における最初の２つのフィールド２１４，２１５は「Ｓ１」および「Ｃ１」である。なぜならパケット２０６はサーバ１１０から提供され、クライアント１０６に向けられているからである。本実施例では、「Ｓ１」はアドレス「Ｃ１」より数値的には小さいアドレスであると仮定している。第３のフィールド「ｐ１」２１６は、ＴＣＰ，ＵＤＰ等のような使用される特定のプロトコルを識別する。
【０２３３】
パケット２０６において、第４フィールド２１７および第５フィールド２１８は、使用されるポート番号を通信するために使用される。会話方向が、ポート番号フィールドがどこであるかを決定する。フィールド２１７の斜線パターンはソース・ポート・パターンを識別するために使用され、フィールド２１８のハッシュ(hash)パターンはあて先ポート・パターンを識別するために使用される。その順序がクライアント・サーバ・メッセージの方向を示す。「ｉ１」２１９で記される第６フィールドは、クライアントによってサーバーから要求される要素である。「ｓ１ａ」２２０で記される第７フィールドは、クライアントによってサーバ１１０から要求されるサービスである。続く第８フィールド「ＱＡ」２２１（疑問符（question  mark）のため）は、クライアント１０６がアプリケーション「ｓ１ａ」にアクセスするために使用するものを知りたがっていることを示す。第１０フィールド「ＱＰ」２２３は、クライアントが、特定のアプリケーションに対して使用すべきプロトコルが何であるかを示すことをサーバに対して望んでいることを示す。
【０２３４】
パケット２０６は、例えばサーバ２に対するＲＰＣ拘束探索要求のようなパケット交換のシーケンスを開始する。これは、総てのパケットと同様、充分に定義されたフォーマットに従い、よく知られたサービス接続識別子（サンＲＰＣを示すポート１１１）でサーバ１１０に送信される。
【０２３５】
パケット２０７は、サーバからクライアント１０６へ返答において最初に送信されるパケットである。これは、要求パケット２０６の結果としてのＲＰＣ拘束探索返答である。
【０２３６】
パケット２０７は、１０個のフィールド２２４−２３３を含む。あて先およびソース・アドレスはフィールド２２４，２２５において担持され、たとえばそれぞれ「Ｃ１」および「Ｓ１」で示される。ここでは順序が逆になっている点に留意すべきである。なぜなら、クライアント・サーバ・メッセージの方向が、サーバ１１０からクライアント１０６に向かうからである。プロトコル「ｐ１」が、フィールド２２６において示されるように、使用される。要求「ｉ１」はフィールド２２９にある。アプリケーション・ポート番号およびフィールド２３３におけるプロトコル「ｐ２」に対しては、値が埋められている。
この交換の結果として形成されるフロー署名およびフロー状態について説明する。パケット・モニタ３００がクライアントからのリクエスト・パケット２０６を見出すと、パターンおよび抽出作業データベース３０８に従って、第１フロー署名２１０が分解サブシステム３０１内で形成される。この署名２１０は、あて先およびソース・アドレス２４０，２４１を含む。本発明の側面の１つは、会話の方向がどうであれ、特定の順序でフロー・キーが一貫して形成されることである。これを達成するためにいくつかの機構が使用される。特定の実施例では、数値的に高いアドレスの前に常に数値的に低いアドレスが配置される。そのような最小から最大への順序を利用して、探索動作に対して署名およびハッシュの最良の分散が得られる。したがってこの場合、「Ｓ１」＜「Ｃ１」を仮定しているので、順序はアドレス「Ｓ１」にクライアント・アドレス「Ｃ１」が続くというものである。署名を形成するために使われる次のフィールドは、パケット２０６のフィールド２１６から抽出したプロトコル・フィールド２４２であり、従ってプロトコル「ｐ１」である。署名のために使用される次のフィールドはフィールド２４３であり、これは、パケット２０６の斜交線を付けたパターンのフィールド２１８からのあて先ソース・ポート番号を含む。このパターンは、パケットのペイロードにおいて認識され、パケット又はパケットのシーケンスがフローとしてどのように存在するかを導出する。実際には、これらはＴＣＰポート番号またはＴＣＰポート番号の組み合わせであり得る。サンＲＰＣの例の場合、斜交線の部分は、ｐ１に対するＵＤＳのポート番号群を表現し、このフローを認識するために使用される（例えばポート１１１）。ポート１１１は、これがサンＲＰＣであることを示す。サンＲＰＣ拘束探索のようないくつかのアプリケーションは、分解レベルで直接的に判別可能である（「既知」）。この場合、署名、キー１は、「ａ１」（サンＰＲＣ拘束探索）で記される既知のアプリケーションを指し、状態プロセッサがより複雑な認識作業に進むべきところの次の状態が、状態「ｓｔＤ」と記され、フロー・エントリのフィールド２４５に位置される。
サンＰＲＣ拘束探索返答が捕捉されると、再びフロー署名が分解装置によって形成される。このフロー署名はキー１に一致する。したがって、署名が分解サブシステム３０１から分析サブシステム３０３に入ると、完全なフロー・エントリが得られ、そのフロー・エントリは状態「ｓｔＤ」を示す。状態プロセッサ命令データベース３２６における状態「ｓｔＤ」に関する動作が、状態プロセッサに対して、図２のキー２（２１２）として示されるような新たなフロー署名を形成および格納するよう命令する。状態プロセッサによって形成されたこのフロー署名は、あて先およびソース・アドレス２５０，２５１を含み、これらのアドレスはサーバに対する「Ｓ１」の後に（数値的に高いアドレスの）クライアント「Ｃ１」が続いたものである。プロトコル・フィールド２５２は、返答パケットから取得された例えば「ｐ２」のような使用されるプロトコルを定める。フィールド２５３は、やはり返答パケットから取得される認識パターンを含む。この場合、アプリケーションはサンＲＰＣであり、フィールド２５４はこのアプリケーション「ａ２」を示す。次の状態フィールド２５５は、例えば状態「ｓｔ１」であるような、状態プロセッサがより複雑な認識作業に進むべきところの次の状態を定める。この特定の実施例ではこれが最終状態である。こうして、キー２は、アプリケーション「ａ２」に何らかの形で関連したパケットを認識するために使用されうる。そのような２つのパケット２０８，２０９が、各方向に付き１つ示されている。これらは、当初の拘束探索要求において要求された特定のアプリケーション・サービスを利用し、署名、キー２が各々の場合において形成されるので各々は認識される。
【０２３７】
２つのフロー署名２１０，２１２は常にあて先およびソース・アドレス・フィールドを、サーバ「Ｓ１」の後にクライアント「Ｃ１」が続くような順序にする。特定のフロー署名において、これらのアドレスが最初に生成されるとき、これらの値は自動的に満たされる。好ましくは、フロー署名およびハッシュを最良に分散させるために、最小から最大への順序で、フロー署名の多くの集合がルック・アップ・テーブルに維持される。
【０２３８】
その後、クライアントおよびサーバは、例えばリクエスト・パケット２０８および応答パケット２０９で表現されるようないくつかのパケットを交換する。クライアント１０６はパケット２０８を送信し、これらのパケットは、１対のフィールド２６０，２６１においてあて先およびソース・アドレスＳ１およびＣ１を有する。フィールド２６２は「ｐ２」としてプロトコルを定め、フィールド２６３はあて先ポート番号を定める。
【０２３９】
いくつかのネットワーク・サーバ・アプリケーション認識作業は、非常に簡単なので、パケットを生成したアプリケーションを正確に指定可能にするために単一の状態遷移しか必要としない場合がある。そうでない場合は、既知の所定の上昇(climb)を行うために、状態から状態へ状態遷移のシーケンスが起こる。
【０２４０】
この例について比較的単純なサン・マイクロシステムズ遠隔手順呼出拘束探索要求命令が実行される場合に、どんなパケット交換シーケンスが生じるかを予め定めることによって、アプリケーション「ａ２」の認識のためのフロー署名は自動的に設定される。これよりも更に複雑な交換は、３個以上のフロー署名および対応する状態を生成する。各々の認識は、フィールド２５５における「ｓｔ１」のような「最終」安定状態に到達するまでにたどるべき複雑な状態遷移図を設定することを含みうる。これら総てを利用して、将来、特定のアプリケーションを認識するための最終的な一組のフロー署名を形成する。
【０２４１】
［状態プロセッサの詳細］
状態プロセッサ１１０８は、アプリケーションによって分類するために、新規のおよび既存のフローの両者を分析する。開発者によって定められた規則に基づいて、状態から状態へ進行することによってこれを行う。規則は、検査と、それに続く、検査が真である場合に進むべき次の状態である。検査が真である、又は実行する状態がなくなるまで、状態プロセッサ１１０８は各規則を経て進行する。状態プロセッサ１１０８は、分解サブシステム１０００によって認識された最終プロトコルを、ジャンプ・テーブル（ジャンプ・ベクトル）内へのオフセットとして使うことによってプロセスを開始する。ジャンプ・テーブルはそのプロトコルに対して使用する命令に我々を案内する。多くの命令は、一体化フロー・キー・バッファ１１０３又は存在するならばフロー・エントリにおける何かを検査する。状態プロセッサ１１０８は、検査を実行するためのビットの検査、比較の実行、加算又は減算を行う必要があることがある。
【０２４２】
多くの一般的な処理システムでは、実行される命令群は汎用の性質を有する。すべての処理システムは、命令およびプログラム・カウンタの分析および処理に関連する命令群を有するのが一般的である。これらの命令は、ジャンプ、コールおよびリターンを含む。さらに、これら同一の処理システムは、レジスタおよびメモリ・ロケーションを分析および取り扱うための適切な命令を有する。これらの命令は、インクリメント、デクリメント、移動、比較および論理的演算を含む。
【０２４３】
好適実施例の状態プロセッサ１１０８もそのような標準的な基本命令群を有する。しかしながら、好適実施例の状態プロセッサ１１０８は、いくつかの非常に特殊な関数を有する。それらの関数は、ネットワーク上のパケットの内容およびパケット内のデータを評価するために必要なものである。これらの目的に対応するために好適実施例の状態プロセッサにより実行される４つの特殊な関数がある。これらのうち２つは、特定の形のテキスト要素を解釈して数学的および数値的なフォーマットに翻訳するために設計された特殊な変換命令である。これらの命令は、ＡＨ２Ｂ（ＡＳＣＩＩ  １６進から２進）およびＡＤ２Ｄ（ＡＳＣＩＩ  １０進から２進）である。これらの命令は、シングル・サイクルの性質を有する。これらの命令は新規であり、好適実施例の状態プロセッサによって実行される関数の高速処理特性を提供する。
【０２４４】
システムを高速化して分類の目的に対応させるために、状態プロセッサに提供されたいくつかの他の特殊な関数が存在する。これらの関数は、主に、ストリングのシーケンスを探索し、位置特定し、分析し、および評価することを取り扱う。これらのストリングは、フォーマットされていたりされていなかったりする。
【０２４５】
主な高レベル命令は、In_FindおよびIn_Find_CONTINUE命令であり、状態プロセッサの一部である探索装置（サーチ・エンジン）によって実行される。これらの関数および探索装置は、状態プロセッサ１１０８が、モニタ３００に送られたパケットからペイロード内容を同時に探索できるようにするように設計される。これは、モニタが、スケーリングして任意のネットワーク速度の要請に対応することを可能にする。
【０２４６】
状態プロセッサは、プロセッサ１１０８として図１９に示される。これは、コンパイル・プロセス３１０の一部としてホストＣＰＵによって満たされている場合の状態プロセッサ命令データベース（ＳＰＩＤ）からの命令を実行する。ＳＰ１１０８は、いくつかのサブブロックを含み、プログラム・カウンタ１９０３（ＳＰＰＣ），制御ブロック１９０５（ＳＰＣＢ），算術演算論理ユニット１９０７（ＳＰＡＬＵ），アドレス発生器およびデータ・バス・マルチプレクサ（Ｍｕｘｅｓ）を含み、様々なソースから様々なあて先へのデータの移動を可能にする。２つのアドレス発生器は、ＵＦＫＢを指定するＳＰフロー・キー・アドレス発生器１９１１（ＳＰＦＫＡＧ）と、キャッシュ・サブシステム１１１５を指定するＳＰフロー・エントリ・アドレス発生器（ＳＰＦＥＡＧ）である。ＳＰ１１０８は、４つのデータ・マルチプレクサを有し、それらは：ＳＰＡＬＵデータＭｕｘＡ１９１９，ＳＰＡＬＵデータＭｕｘＢ１９２１，ＳＰＵＦＫＢデータＭｕｘ１９１５，およびＳＰキャッシュ・データＭｕｘ１９１７である。これらのマルチプレクサは、状態プロセッサ１１０８内の様々なブロック内のデータの移動、およびＵＦＫＢ１１０３およびキャッシュ・サブシステム１１１５へのおよびそこからのデータの移動を支援する。
【０２４７】
ＳＰ制御ブロック１９０５は、ＳＰＩＤ１１０９から生じる命令をデコードし、それらを様々なフィールドに分けて状態プロセッサ１１０８を制御する。ＳＰＣＢ１９０５の主な機能は、命令デコードと信号生成である。命令の２つのクラスが存在する。１つはＳＰＣＢによって完全に実行されるものであり、１つは部分的に又は完全に実行するためにＳＰＡＬＵ１９０７に送られるものである。ＳＰ命令のいくつかは、以下に説明される。
【０２４８】
命令が、ＳＰＡＵＬ１９０７に渡される必要のある場合、ＳＰＣＢ１９０５は命令をデコードし、ＳＰＡＬＵ１９０７命令コードをバス上に供給し、「進行」信号をアサートする。
【０２４９】
例えば移動又はジャンプのような命令が、ＳＰＣＢ１９０５によって完全に実行される場合は、ＳＰＣＢは、ＳＰプログラム・カウンタ１９０３，ＳＰアドレス発生器１９１１および／または１９１３，およびＳＰマルチプレクサに対する適切な制御信号を生成し、その特殊な移動またはジャンプ命令を実行する。
【０２５０】
ＳＰＩＤ１１０９におけるワードは、４０ビット長であり、命令コードに依存してＳＰＣＢ１９０５によっていくつかのフィールドに区分される。１つのフィールドは命令コードである。ＳＰＩＤワードにおける残余のビットは、同行する命令に依存して様々なフィールドに区分される。たとえば、ＳＰ１１０８は、ジャンプ、コール、待機、および条件コードとジャンプ・アドレスが後に続く待機ＲＪの命令を実行することが可能である。ＳＰ１１０８は、定数値が後に続く直接移動命令(Move  Immediate  Instruction)を実行することが可能である。さらに、ＳＰ１１０８は、ロードされるべきアドレスが後に続くロード・アドレス生成命令を実行することが可能である。命令フィールドをデコードする場合に、ＳＰＣＢは、包含されたデコードＰＡＬから制御信号の組み合わせを生成する。これらの制御信号は、様々なマルチプレクサを選択し、データ移動を容易にし、および様々なレジスタ内の値をロードするストローブ（strobe）信号を生成することを促進する。
【０２５１】
プログラム・カウンタＳＰＰＣ１９０３は、状態プロセッサ命令データベースに対するアドレスを生成する。これは、ＳＰＩＤ１１０９アドレスを生成する命令ポインタを含む。命令ポインタは、インクリメントされ得るし、また、条件分岐機能を支援するジャンプ・ベクトル・マルチプレクサからロードされ得る。命令ポインタは、次の３つのソースの１つからロードされ得る。それは：（１）ＵＦＫＢからのプロトコル識別子，（２）目下デコードされた命令からの直接ジャンプ・ベクトル(immediate  jump  vector)，または（３）ＳＰＡＬＵ１９０７により供給される値である。
【０２５２】
既知のプロトコル識別子を利用してＬＵＥによってＵＦＫＢ内にフロー署名が設けられた後に、プログラム・カウンタ１９０３は、分解サブシステムにより認識された最後のプロトコルを利用して初期化される。この第１の命令は、デコードされたプロトコルを分析するサブルーチンへのジャンプである。
【０２５３】
ジャンプ直接命令を支援するために、プログラム・カウンタはジャンプ・ベクトルを利用してＳＰＣＢ１９０５から入力フィールドを選択し、ジャンプ・ベクトルを利用して命令ポインタをロードする。
状態プロセッサＡＬＵ１９０７は、状態プロセッサ命令を実装するために必要な算術機能、論理機能およびストリング比較機能のすべてを含む。ＳＰＡＬＵ１９０７の主要なブロックは：ＡレジスタおよびＢレジスタ、命令デコードおよび状態マシン、参照ストリング・メモリ、探索エンジン１９３０、出力データ・レジスタおよび出力制御レジスタである。
【０２５４】
状態プロセッサＡＬＵ探索エンジン１９３０（ＳＰＡＬＵ＿ＳＥ）は、目標探索レジスタ・セット，参照探索レジスタ・セットおよび比較ブロックを含む。探索エンジン１９３０は、目標となる領域中の任意の場所にある所定数（本実施例では４つ）までの参照ストリングを探索することが可能であり、そして、参照ストリングの１つが見出された場合には、どの参照ストリングかとその参照ストリングの目標領域での位置を返す。
【０２５５】
フロー・キー・アドレス発生器１９１１は、状態プロセッサ１１０８が一体化フロー・キー・バッファ内でアクセスしている場所に対するアドレスを生成する。ＳＰＦＫＡＧの主要ブロックは、フロー・キー・アドレス・ポインタ・レジスタと、アドレスを生成するＲＯＭデコードである。
【０２５６】
フロー・キー・アドレス発生器１９１１は、状態プロセッサ１１０８がキャッシュ・サブシステム１１１５においてフロー・エントリにアクセスするところのアドレスを提供する。フロー・エントリが存在する場合、ハッシュからの上位アドレス・ビットは、フロー・データベース３２４内のバケットを探索するために使用される。中位ビットは、見出されたバケット・エントリから生じる。低位ビットは、状態プロセッサ１１０８が使用しているオフセットから生じる。
【０２５７】
ＳＰＦＫＡＧの主要ブロックは、フロー・キー・ポインタ・レジスタと、アドレスを発生するＲＯＭデコードである。
【０２５８】
状態プロセッサＵＦＫＢデータＭｕｘ１９１５は、ＵＦＫＢに向けられたデータ・ソースを選択する。これは、３つのデータ・ソースの内の１つをＵＦＫＢにマルチプレクスする。３つのソースは、ＡＬＵ出力データ・バス，キャッシュ出力データ・バスおよびＳＰＣＢデータである。選択信号は２ビット信号である。
【０２５９】
状態プロセッサ・キャッシュ・データＭｕｘ１９１７は、キャッシュ・サブシステムへ向かう４つのデータ・ソースから、キャッシュ・サブシステムに向けられたデータ・ソースを選択する。４つのソースは：ＡＬＵ出力データ・バス，ＵＦＫＢデータ・バスの低位ビット，ＵＦＫＢデータ・バスの上位ビットおよびＳＰＣＢデータである。選択信号は２ビット信号である。１６ビット移動を可能にするため、ＳＰＭＵＸＣＡは、キャッシュ・サブシステムの低位および上位１６ビットに対する情報を提供する２つの１６ビット・マルチプレクサを組み込む。
【０２６０】
状態プロセッサＳＬＵデータＭｕｘＡ１９１９は、ＵＦＫＢに向けられたデータ・ソースを選択し、３つの３２ビット・データ・ソースの１つをＡＬＵのＡ側にマルチプレクスする。３つのソースは、キャッシュ・サブシステム・データ・バス，ＵＦＫＢデータ・バスの低位３２ビットおよびＵＦＫＢデータ・バスの上位３２ビットである。選択信号は２ビット信号である。
【０２６１】
状態プロセッサＳＬＵデータＭｕｘＢ１９１９は、ＳＰＡＬＵのＢ側に向けられたデータ・ソースを選択し、２つの３２ビット・データ・ソースの１つをＡＬＵのＢ側にマルチプレクスする。２つのソースは、キャッシュ・サブシステム・データ・バスおよびＳＰＣＢデータ・ワードである。選択信号は１ビット信号である。
【０２６２】
［状態プロセッサ命令の説明］
以下、状態プロセッサ１１０８で利用可能ないくつかの命令を説明する。典型的には状態プロセッサにアセンブラは与えられない点に留意すべきである。なぜなら、典型的にはエンジニアはこのプロセッサ用のコードを書く必要がないからである。コンパイラが、コードを書き込み、それをプロトコル・リスト（ＰＤＬファイル）で定められたプロトコルに基づいて状態プロセッサ命令データベースにロードする。
【０２６３】
テーブルは実施例１および実施例２の２つの実施例に分けられ、後者は、実施例１の命令のより複雑なバージョンおよび追加的な命令を含む一層複雑な実施例である。
【０２６４】
【表２】
0005517821.tif 000004
【０２６５】
【表３】
0005517821.tif 000005
これらの命令いくつかについて更に説明する。
【０２６６】
［移動］(Move)
移動命令セットは、異なる大きさのワードをソースからあて先へ移動することを取り扱う特殊な移動命令を含む。移動命令のセットは、ワード・サイズが常に合致することを保障するように開発され、３２ビットおよび１６ビット移動命令を含む。
【０２６７】
移動命令が移動させるデータは：直近のデータからＳＰＡＬＵＢレジスタへ、直近のデータからキャッシュ・サブシステムへ、直近のデータからＵＦＫＢへ、ＳＰＡＬＵ出力からＵＦＫＢへ、ＳＰＡＬＵ出力からキャッシュ・サブシステムへ、キャッシュからＵＦＫＢへ、キャッシュからＳＰＡＬＵＡレジスタへ、キャッシュからＳＰＡＬＵＢレジスタへ、ＵＦＫＢからキャッシュ・サブシステムへ、およびＵＦＫＢからＳＰＡＬＵＡレジスタへのものである。
【０２６８】
［比較］(In_Compare)
比較命令は、ＡＬＵ１９０７が比較動作を実行し、一致したストリング情報による合致信号を返すように命令する。比較動作は、最初のキャラクタがＵＦＫＢ内の既知の位置にある目標データと、参照ストリング・メモリ内の既知の参照ストリングとを比較する。この命令の実行に先立って、ＳＰＵＦＫＢアドレス発生器１９１１は、目標キャラクタを指すアドレスをロードされる。ＡＬＵ参照メモリ内のある位置（ロケーション）が、比較用の参照キャラクタのリストを保持する。
【０２６９】
［アスキー１０進から２進］(ASCII  Decimal  to  Binary)
この命令は、１０進値を表現するアスキー・コード・ストリングの位置を引き渡す。その結果は、２進の等価な値である。これは１サイクルで実行される。
【０２７０】
［アスキー１６進から２進］(ASCII  Hex  to  Binary)
この命令は、１６進値を表現するアスキー・コード・ストリングの位置を引き渡す。その結果は、２進の等価な値である。これは１サイクルで実行される。
［イン・ファインド］(In_Find)
［継続イン・ファインド］(In_Find_Continue)
これらの命令は、探索エンジン１９３０の更なる説明において説明される。
【０２７１】
［探索エンジンおよび探索エンジンを呼び出すＳＰ命令］
モニタ３００の１つの特徴は、パケットの一つ一つ総てをリアル・タイムで分析する能力である。ネットワーク・トラフィックは非常に高速に動きうる。状態プロセッサ１１０７の仕事（タスク）の１つは、１つ又はそれ以上の既知のデータ・ストリングを探索することである。このような探索は、ＵＦＫＢレコードに対して、例えばレコードのペイロードの部分において実行される。探索は、レコードの既知の部分におけるものであり得るし、またはＵＦＫＢレコードのペイロード部分のどこかというようなレコードの未知の部分におけるものでもあり得る。さらに、探索は極めて高速に行われることを要することがありうる。
【０２７２】
状態プロセッサＡＬＵは、そのような探索を実行するための探索エンジンＳＰＡＬＵ＿ＳＥ１９３０を有する。探索エンジン１９３０は、ＵＦＫＢ内の目標領域において４つまでの参照ストリングを探索することが可能であり、そして並列して、（１）４つのストリングの内のどれかが目標（ターゲット）内のどこかで見出されたか否か、（２）どのストリングが見出されたか、および（３）目標内のどこでストリングが見出されたかを示す。
【０２７３】
探索エンジンは、以下の状態プロセッサ命令を実行する機能を有する。
【０２７４】
［イン・ファインド］(In_Find)
イン・ファインド命令は、ＡＬＵ探索エンジンに情報を提供し、探索動作を実行し、一致したストリング情報と、ストリングが見出されたターゲット内の位置に従って一致信号を返す。
【０２７５】
命令フォーマットは以下のとおりである：
イン・ファインド（In_Find）［参照ストリング・アレイ・アドレス］，［ＵＦＫＢバイト・オフセット］，［範囲］
【０２７６】
【表４】
0005517821.tif 000006
【０２７７】
【表５】
0005517821.tif 000007
探索が完了すると、探索終了ビットがアサートされる。探索結果に基づいて、一致ビットがアサート又はリセットされる。ＡＬＵ＿データ・バスと呼ばれるＡＬＵ内のバスは、以下の情報を有する：
・ジャンプ_ベクトル［１５：０］−参照ストリング・アレイに格納されたベクトルであり、参照ストリングが見出された場合に状態プロセッサがどの命令に（例えばサブルーチンへ）ジャンプするかを示す。
【０２７８】
・ストリング・コード［１：０］−どの参照ストリングが見出されたかを示すコードであり、４つの参照ストリング実装については０，１，２または３である。
【０２７９】
フロー・キー・バッファ内でストリングが見出された場所は維持される。これは、ＵＦＫＢワード・アドレスと、見出したターゲット・ストリングの第１キャラクタのバイト位置との組み合わせである。
【０２８０】
探索が終了するのは、いずれかの参照ストリングが初めて発見された場合、または探索範囲の全体において一致が得られなかった場合である。
【０２８１】
以下の例を考察する。ＵＦＫＢのペイロード領域において参照ストリングを探索し、ペイロードのバイト位置５において探索を開始し、バイト位置１００において探索を終了するものとする。参照ストリングは位置００５０ｈにあるものとする。この事例の命令フォーマットは、次のようにすることができる：
In_Load_FKAG,  payload  address
In_Find,  0050(16),  5,  60(16)
範囲は、１００−５＋１＝９６＝６０（１６）となる。
【０２８２】
位置１２（１６）から位置２Ａ（１６）を探索する第２の事例を考察する。以下の状態プロセッサ命令がこれを達成する。
【０２８３】
In_Load_FKAG  02(16)
In_Find  [Reference  String  Address],  2,  19(16)
２Ａ（１６）−１２（１６）＝１９（１６）となる点に留意すべきである。
【０２８４】
［継続イン・ファインド］(In_Find_Continue)
この命令は、イン・ファインド命令に続き、最後のストリングが見出されたその位置から始まる探索（Find）動作を実行するようＡＬＵ探索エンジン１９３０に告げ、一致ストリング情報および目標ストリングが見出された位置に従って一致信号を返す。この命令の目的は、新規の参照ストリングに対して、先の探索が終了した場所から始まる探索を支援することである。したがって、探索エンジンはその以前の探索が終了した位置を覚えているのでオフセットは供給されない。
【０２８５】
命令フォーマットは次のとおりである：
継続インファインド（In_Find_Continue）［参照ストリング・アレイ・アドレス］，［０］，［範囲］
【０２８６】
【表６】
0005517821.tif 000008
例として、ＵＦＫＢのペイロード領域においてストリング（ストリングＡ）を探索し（イン・ファインド）、ペイロードのバイト位置５において探索を開始し、バイト位置１００において探索を終了するものとする。参照ストリング（ストリングＡ）は位置００５０（１６）にあるものとする。第１参照ストリングを見出した後に、続く３０（１６）バイトにおける新規のストリング（ストリングＢ）を探索し続けるものとする。ストリングＢは位置００８０ｈにあるものとする。
この事例の命令フォーマットは、次のようにすることができる：
In_Load_FKAG,  payload  address
In_Find,  0050(16),  5,  60(16)
・・・
In_Find_Continue,  0080(16),  5,  30(16)
範囲は、１００−５＋１＝９６＝６０（１６）となる。
【０２８７】
図２０は、探索エンジン（ＳＰＡＬＵ＿ＳＥ）１９３０の全体ブロック図であり、ＡＬＵ１９０７の一部であり、ＡＬＵ１９０７で発行されたイン・ファインドおよび継続イン・ファインド命令を実行する。イン・ファインド命令はＵＦＫＢの領域を探索し、ターゲット（ＵＦＫＢ）領域における４つまでの可能性ある参照ストリングを探索する。参照ストリングはＡＬＵ参照ストリング・メモリに格納される。
【０２８８】
図２０に示されるように、探索エンジンは以下のコンポーネントに結合される：
（ａ）ＡＬＵストリング参照メモリ２００３であって、そこに参照ストリングが格納される。
【０２８９】
（ｂ）ＳＰＡＬＵデータＭｕｘＡ１９１９であって、そこを通じて参照ストリングに一致すべき目標データ２０１１が供給される。これは、ＳＰ＿ＵＦＫＢデータＭｕｘ１９１５を利用して、イン・ファインド命令の実行中にＵＦＫＢに結合される。
【０２９０】
（ｃ）ＳＰＡＬＵデータＭｕｘＢ１９２１であって、そこを通じて命令コードが供給され、その命令コードは探索を開始するための「進行」信号ＳＰＡＬＵＧＯ２００５を含む。
【０２９１】
（ｄ）状態プロセッサ・フロー・キー・アドレス発生器１９１１であって、ＵＦＫＢをインクリメントおよびデクリメントするために使用される。
【０２９２】
（ｅ）状態プロセッサ・プログラム・カウンタ１９０３であって、探索の結果が報告される。
【０２９３】
システムはクロック信号ＣＬＫ２００１によって動作し、リセット信号によってリセットされうる。命令デコード・ブロックＳＥ＿ＩＮＳＴ２００９は、イン・ファインドおよび継続イン・ファインド命令用の命令コードをデコードし、ＳＰＡＬＵＧＯ信号２００５の活性化に際して探索エンジンを起動する。探索エンジンはＳＰＭｕｘＢ１９２１出力バス２００７およびＳＰＡＬＵＧＯ信号２００５を継続的に監視し、イン・ファインドおよび継続イン・ファインド命令を検出する。探索エンジン１９３０の動作中に、エンジンは、ＳＰＭＵＸＡ１９１９を通じてＵＦＫＢ１１０３からワード・サイズの目標データ２０１１を受信する。同様に、参照ストリング・メモリ２００３の適切なアドレスからの参照信号は、ＳＰ＿データ＿ＲＭＢ２０１３として到着する。
【０２９４】
イン・ファインドまたは継続イン・ファインド命令が発行されると、探索エンジン参照ロード（ＳＥ＿ロード）モジュール２０１５は、参照ストリング・レジスタの「準備(priming)」を行うことを受け持つ。これは、参照ストリング・メモリ２００３から参照ストリング・アレイを取得し、それを解釈し、参照ストリング・レジスタにその情報をロードする。
【０２９５】
処理状態において、ＳＥ−ＬＯＡＤモジュール２０１５はまず、参照メモリ２００３の開始位置から第１ワードをロードする。この開始位置は、命令の発行に先立って適切な位置に設定されていると想定する。ストリング数およびストリングの大きさがロードされると、ロード・プロセスは参照ストリング総てのロードを続行する。インクリメント参照信号２０２５は、そこから参照ストリングがロードされているところの参照メモリをインクリメントする。ストリングのロード中には、ロード_キー_終了信号２０１７はアサートされない。最後の参照ストリングの最後のワードがロードされ、探索_エンジン_モジュール２０３０に対して次のクロックからの探索開始を通知するとき、ロード_キー信号２０１９がパルス入力される。ロード_キー_終了信号２０１７は次のクロック・サイクルでアサートされ、ジャンプ・ベクトル２０２１は、参照メモリ２００３から同時にロードされる。
【０２９６】
探索エンジン・インクリメント／制御モジュール（ＳＥ＿ＩＮＣ）２０２３は、ＵＦＫＢから探索エンジンに新たなワードを提供するために、フロー・キー・アドレス発生器１９１１をインクリメントすることを受け持つ。これは、探索エンジン・モジュールからの見出された信号を監視し、結果を報告する。ＳＥ＿ＩＮＣ２０２３は、真の終了アドレスを計算することも受け持ち、イン・ファインド命令において供給された範囲に基づいて、最終ワード内で検査されるべき最終バイトを判別する。
【０２９７】
ＳＥ−４探索モジュール２０３０は、４つのストリングを同時に探索するために４つの探索エンジンを有する。エンジンは、４つの参照ストリングの各々に対して、ストリングの存否およびストリングが見出された場所を示す発見信号２０３１および位置信号２０３３を出力する。
【０２９８】
ＳＥ＿ＩＮＣ２０２３によるＳＰＡＬＵ_終了信号２０３５のアサートは、探索が完了したことを示す。ＳＰＡＬＵ_一致信号２０３７が同時にアサートされる場合は、探索成功である。この探索成功により、ＳＰＡＬＵ_データ・バス２０３９において、参照ストリングを見出した探索エンジン番号と共にジャンプ・ベクトルを搬送することになる。
【０２９９】
本発明の１つの特徴は、探索の迅速性である。ＵＦＫＢでＮ個のワードの任意の場所を探索するために命令が発行された時から、ＳＰＡＬＵ_終了２０３５がアサートされるまでの最長時間は、探索が成功する場合は、Ｎクロック・サイクルと、事前ロードおよびポインタ調整のための付加的なクロック・サイクル数とを加えたものである。本実施例ではこの付加的なオーバーヘッドは１１クロック・サイクルである。従って、各々の余分なワードはほんの１クロック・サイクルしか要しない。
【０３００】
図２１は、４つの単独探索モジュールを有するＳＥ_４探索モジュール２０３０を示す。他の実施例では、より多くの単独探索モジュールを有し、４つより多くの参照ストリングを同時に探索可能にしてもよい。４つの探索エンジン・モジュールの各々は同一物であるので、１つのモジュール２１０３のみを説明する。
【０３０１】
単独探索モジュールの各々２１０３は、単独の参照ストリング探索を実行する。このモジュールの複数の複製を利用することによって、共通のソース・バッファ（ＵＦＫＢ）において複数の相異なる参照ストリングを探索することが可能である。このモジュールは、コア比較行列ブロック２１０５（探索エンジン・コア）および状態マシンＳＥ＿ＳＭ２１０７を有する。探索エンジン・コア２１０５は、ＮＲ個の単位（本実施例では１６ビット）までの参照ストリングを、３つの８バイト・ワード（一度に１ワードで、３つの連続したサイクルにおいてロードされる）のターゲット・ストリングと比較することが可能である。各クロック・サイクルの間に、単独の探索モジュール２１０３は、第１ワードの８バイトの何れかから開始するターゲット中の任意の位置において参照ストリングを探索する。参照ストリング・バイトの各々は、そのバイトを検査するか否かを示す検査ビットと共に付加される。検査ビットがアサートされると、対応するバイト検査が無効にされる。６４ビット・ワード（８バイト）がパイプライン方式で３つのレジスタにロードされると、それらが取り出された２クロック・サイクル後に、比較動作が行われる。
探索が成功した場合は、ソース（ＵＦＫＢ）アドレス・ポインタは調整される必要がある。探索が成功した場合は、一致信号２１１１がアクティブになり、参照ストリングの第１バイトの位置が、位置バス２１１３上に置かれる。ＳＥ＿ＳＭ状態マシン２１０７は、クロック・サイクル毎にいくつかの仕事を実行する。状態マシン２１０７には３つの状態がある：リセット、アイドルおよびプロセスである。アイドル状態では、状態マシン２１０７は、ＳＥ_ロード・モジュール２０１５からの信号を待ち受け、プロセス状態に切り替わる。プロセス状態における第１クロック・サイクルの間に、一致が発生すると、その位置がバイト・オフセット２１１５に対して検査される。バイト・オフセットがその位置よりも大きい場合は、それは無視され、すなわち「発見」はアサートされない。同様に、それが検査すべき最終ワードである場合は、終了オフセット・バイトがその位置に関して検査され、その位置が範囲２１１７で検査される最終バイトより大きい場合は、「発見」は無視される。そうでない場合は、一致が探索エンジン・コア２１０５によって見出されると、発見信号がアサートされ、その位置がラッチされ、ＳＥ＿ＩＮＣモジュール２０２３に転送される。
【０３０２】
ここで図２２Ａを参照する。探索エンジン・コア２１０５は、探索エンジン・モジュールのコア比較行列〔マトリクス〕である。これは、目標ストリングにおいてＮＲユニットの参照信号の探索を行う。参照〔リファレンス〕軸およびターゲット軸がある。参照軸にはレジスタがあり、一般にＮＲ個のユニットのストリングである参照ストリングを保持する。本実施例では１ユニットは１バイトであり、ＮＲは１６であるが、他の参照ストリング・サイズを探索するために他のユニット（単位）および行列に容易に修正可能である。ターゲット・データはワードとして組織化されている。ターゲット軸は、各々がターゲット・データの１ワードを保持する一連の１ワード・レジスタ群として並べられる。ワードは１クロック・サイクルでレジスタにクロック入力される。したがって、ターゲット・データの第１ワードは３サイクルでターゲット軸にクロック入力される。
【０３０３】
探索エンジン・コア２１０５は、少なくとも１つのＮＲユニット比較器を有し、各ＮＲユニット比較器がＮＲ個の入力対と、ＮＲ個の入力対の各対の一致を示す出力とを有する。このような比較器の１つ２２０３が図２２Ｂに示される。入力対は、（２２０７−１，２２０９−１），（２２０７−２，２２０９−２），．．．，（２２０７−ＮＲ，２２０９−ＮＲ）として示される。出力は２２１１である。図２２Ａは、２２０３−１，２２０３−２，．．．，２２０３−ＮＳＴＡＲＴのラベルの付された多数（例えばＮＳＴＡＲＴ個）の比較器を示す。任意の１つの比較器を考察すると、探索エンジン・コアは、参照軸に沿って参照ストリングの値を示すＮＲ個の接続と、ターゲット軸に沿うターゲット・データの値を示すＮＲ個の接続とを含む接続の行列を含み、ターゲット・データ接続はターゲット・データの第１の開始位置から始まり、終了位置において終了する。参照およびターゲット軸が互いに垂直に配向される場合に、いずれの比較器も行列の対角線に沿って配向され、ターゲット・データのＮＲ個の接続が前記参照ストリングと比較されるようにして、比較器は接続される。各比較器はターゲット軸上で異なる位置から開始する。我々の実装では各ワードは８バイトの長さであり、比較器の数ＮＳＴＡＲＴはワード・サイズと同じであり、比較器はターゲット軸上の連続する諸位置で始まる。したがって、１クロック・サイクルにおいて、探索エンジン・コア２１０５は、第１ワードの任意の位置から始まる参照ストリングを見出すことが可能である。ターゲット・ストリングがワード境界をまたぐ場合でも、探索エンジン・コアは依然としてそのワードを自動的に見出す点に留意すべきである。
【０３０４】
比較器の出力は、ＮＳＴＡＲＴ入力の優先エンコーダに入力され、この優先エンコーダがストリングが見出された場合にＮＳＴＡＲＴ個の比較器のうちのいずれがそのストリングを見出したかを示す。これは、その位置を提供する。
【０３０５】
動作時にあっては、データがロードされた後、第１クロック・サイクルにおいて、状態マシン２１０７は、最初の若干数の比較器で見出されるかもしれないストリングを無視する。その比較器数はオフセットによって示される。以降のそれぞれのクロック・サイクルにおいて、最初のＮＳＴＡＲＴ個の位置のどこかで始まるならば、探索エンジン・コア２１０５は参照ストリングを見出すであろう。したがって、多数のクロック・サイクルにおいて、探索エンジン・コア２１０５はターゲット・データのどこかで参照ストリングを見出すであろう。
【０３０６】
図２３Ａは入力コアの実装をより詳細に示す。この実装は任意の１組の開始位置における参照ストリングを見出すためのものである。この実装は、参照ストリングの１つのＮＲ個のユニットを受信する参照レジスタ２２０３と、ターゲット・データを受信するために直列に接続されたターゲット・データ・レジスタ群２２０５と、複数の比較器セットとを有し、開始位置の各々に対応する一つの比較器セットがあり、特定の開始位置の比較器セットは、参照レジスタの各々のユニット（本実施例では各バイト）およびその特定の開始位置から始まる諸ターゲット・データ・レジスタのＮＲ個の入力（本実施例ではバイト）に接続され、第１参照レジスタの内容と、その特定の開始位置から始まるターゲット・データ・レジスタのＮＲ個のユニットを比較する。各比較器セットは、その対応する異なる開始位置から始まるターゲット・データにおける第１参照ストリングの一致の存否を示す。可能な開始位置のセットはＮＳＴＡＲＴ個の異なる位置を含みうる。これらの位置は連続していてもしていなくてもよく、連続している場合は、１つ又はそれ以上のターゲット・データ・レジスタが、ターゲット・データの少なくともＮＲ＋ＮＳＴＡＲＴ−１個のユニットを受信するよう直列に結合されている。このように、ＮＳＴＡＲＴ個の開始位置の各々について１つの比較器セットの、ＮＳＴＡＲＴ個の比較器セットが存在する。
【０３０７】
各比較器セットはＮＲ個の連続する（隣接する）比較器を有する。そのような比較器の１つ２３１３が図２３Ｂに示されており、参照入力、ターゲット入力、イネーブル入力および一致を示す出力を有し、参照およびターゲット入力が一致してイネーブル入力がアサートされた場合に、比較器２３１３の出力がアサートされる。特定の開始位置に関する特定の比較器のセットに関し、連続する比較器の参照入力は参照レジスタの連続するユニットに結合され、連続する比較器のターゲット・データ入力は、その特定の開始位置に始まる諸ターゲット・データ・レジスタの連続するユニットに結合され、そのセットの第１比較器がイネーブルされ、各比較器のイネーブル入力が先行する比較器の出力に結合され、参照ストリングのＮＲ個のユニットおよびターゲット・データのＮＲ個のユニットが合致する場合に最後の比較器の出力がアサートされる。
【０３０８】
このようにして、状態プロセッサは、（ＵＦＫＢに格納された）パケットの領域内の未知の位置におけるストリングを非常に高速に見出すことが可能である。
【０３０９】
［キャッシュ・サブシステム］
図１１を再び参照する。キャッシュ・サブシステム１１１５は、探索更新エンジン（ＬＵＥ）１１０７と、状態プロセッサ（ＳＰ）１１０８と、フロー挿入／削除エンジン（ＦＩＤＥ）１１１０に接続されている。キャッシュ１１１５は、メモリ１１２３に格納されたフロー・エントリ・データベースのフロー・エントリ群を維持し、これは一体化メモリ・コントローラ１１１９を通じてメモリ１１２３に接続される。本発明の一実施例によれば、キャッシュ内のこれらのエントリは次にアクセスそうなものである。
【０３１０】
キャッシュ・システムにおいてヒット率を最大化させることが望ましい。一般的な従来のキャッシュ・システムは、マイクロプロセッサ・システムへおよびそこからのメモリ・アクセスを促進させるために使用される。ヒット率を最大化できるよう探索を予測するための多くの機構が従来のそのようなシステムにおいて利用可能である。例えば従来のキャッシュは、先読み機構を利用して、命令キャッシュ探索およびデータ・キャッシュ探索の両方を予測する。そのような先読み機構は、キャッシュ・サブシステム１１１５のパケット監視の用途には利用可能でない。新たなパケットがモニタ３００に入る場合に、例えばＬＵＥ１１０７からの次のキャッシュ・アクセスは、最後のキャッシュ探索とは全く異なるフローに対するものであることがありうる。そして次のパケットが所属するフローが何であるかをそれ以前に知る術がない。
【０３１１】
本発明の一形態でのキャッシュ・システムは、キャッシュ置換が必要とされる場合に最も長く未使用である（ＬＲＵ）フロー・エントリを置換する。最も長く未使用であるフロー・エントリを置換するのが好ましいのは、最近のパケットに続くパケットは同じフローに属するであろうからである。したがって新規のパケットの署名は最近使用したフロー・レコードに一致するであろう。逆に、最も長く未使用であるフロー・エントリに関連するパケットが、直後に到着する可能性は高くないであろう。
【０３１２】
さらに、フロー・エントリに対して作用する例えばＬＵＥ１１０７のようなエンジンの１つが、あるフロー・エントリに対する動作を完了した後に、同一のまたは別のエンジンが同一のフロー・エントリを間もなく使用する可能性が高い。したがって、最近使用したエントリがキャッシュに残っていることを保証することが好ましい。
【０３１３】
本発明によるキャッシュ・システムの特徴は、最も最近使用した（ＭＲＵ）フロー・エントリが可能な場合はいつでもキャッシュ内に保持されることである。一般に、同一フローのパケットはバーストで到来するので、およびＭＲＵフロー・エントリは分析システムにおける別のエンジンによって要求される可能性が高いので、ＭＲＵフロー・エントリがキャッシュ内に残っている可能性を高めることは、キャッシュ内でフロー・レコードを見出す可能性を高めることになり、キャッシュ・ヒット率を向上させる。
【０３１４】
この本願発明のキャッシュの他の特徴は、内容アドレス可能なメモリ・セル（ＣＡＭ）のセットを利用する連想式メモリを有することである。ＣＡＭはアドレスを含み、このアドレスは、本実施例ではメモリ・セルより成るキャッシュ・メモリ（例えばデータＲＡＭ）における対応するフロー・エントリに関連したハッシュ値である。一実施例では、各メモリ・セルはページである。各ＣＡＭはキャッシュ・メモリ・ページに対するポインタも含む。したがってＣＡＭ内容は、アドレスと、キャッシュ・メモリに対するポインタである。ハッシュはＣＡＭの一致回路入力に与えられ、ハッシュがＣＡＭ内のハッシュに一致する場合は、ヒットがあることを示す一致信号がアサートされる。ＣＡＭポインタは、フロー・エントリのキャッシュ・メモリにおけるページ番号（すなわちアドレス）を指す。
【０３１５】
各ＣＡＭはキャッシュ・アドレス入力、キャッシュ・ポインタ入力、およびキャッシュ内容出力を含み、ＣＡＭのアドレス部分およびポインタ部分の入力および出力を行う。
【０３１６】
特定のキャッシュ・メモリ例では、１つのバケットにおける複数ページに複数のフロー・エントリを格納し、すなわち、単独のフロー・エントリを格納することができる。ポインタはキャッシュ・メモリにおけるページ番号である。一例にあっては、各ハッシュ値がＮフロー・エントリのビンに対応する（例えば、この例における好適実施例では４バケット）。他の実装では、各ハッシュ値は単一のフロー・レコードを指し、すなわちビンおよびバケット・サイズが対応する。簡単のため、キャッシュ１１１５を説明する際に、この第２の実装を想定している。
【０３１７】
さらに、従来のように、一致出力信号をキャッシュ・メモリ内の対応するロケーションに提供し、それによりリード〔読み出し〕又はライト〔書き込み〕動作が、そのＣＡＭによって指定されるキャッシュ・メモリ内のロケーションに関して行われうる。
【０３１８】
本願の特徴の１つは、連想性と真のＬＲＵ置換方針との結合を達成することである。このために、キャッシュ・システム１１１５のＣＡＭは、最上部ＣＡＭと最下部ＣＡＭをもち、ある順序になっているＣＡＭスタック（ＣＡＭアレイとも）と呼ばれるものに組織化される。最上部ＣＡＭから始まる各ＣＡＭのアドレスおよびポインタ出力は、最下部に至るまで、次のキャッシュのアドレスおよびポインタ入力に接続される。
【０３１９】
本実施例では、キャッシュをアドレスするためにハッシュが使用される。ハッシュはＣＡＭアレイに入力され、入力ハッシュに一致するアドレスを有するＣＡＭが、ヒットを示す一致出力をアサートする。キャッシュ・ヒットが存在すると、そのヒットを出したＣＡＭの内容（アドレスおよびキャッシュ・メモリに対するポインタを含む）は、スタックの最上部ＣＡＭに置かれる。ヒットを出したＣＡＭより上のＣＡＭのＣＡＭ内容（キャッシュ・アドレスおよびキャッシュ・メモリ・ポインタ）は、ギャップを埋めるために下にシフトされる。
【０３２０】
ミスが生じた場合は、新たなフロー・レコードが、最下部ＣＡＭによって指定されるキャッシュ・メモリ要素に置かれる。その最下部より上の全ＣＡＭ内容は、１つシフト・ダウンされ、新たなハッシュ値および新たなフロー・エントリのキャッシュ・メモリに対するポインタが、ＣＡＭスタックの最上部ＣＡＭに置かれる。
【０３２１】
このようにして、最も長く未使用であるキャッシュ内容が最下部ＣＡＭによって指定され、最も最近利用されたキャッシュ内容が最上部ＣＡＭによって指定されるようにして、ＣＡＭは使用の最新性(recentness)に従って並べられる。
【０３２２】
さらに、従来のＣＡＭベースのキャッシュとは異なり、ＣＡＭ内のアドレスと、それが指定するキャッシュ・メモリ要素との間に固定的な関係はない。キャッシュ・メモリのページに対するＣＡＭの関係は、時間と共に変化する。例えば、ある瞬間に、スタック内の第５ＣＡＭがキャッシュ・メモリ内のある特定のページに対するポインタを有し、その後に、同一の第５ＣＡＭが異なるキャッシュ・メモリ・ページを指定し得る。
【０３２３】
一実施例にあっては、ＣＡＭアレイは３２個のＣＡＭを有し、キャッシュ・メモリは３２個のメモリ・セル（例えばメモリ・ページ）を有し、各ＣＡＭ内容によって１つのページが指定される。ＣＡＭは、アレイ内の最上部ＣＡＭにＣＡＭ０を、最下部ＣＡＭにＣＡＭ３１を対応させ、ＣＡＭ０，ＣＡＭ１，．．．，ＣＡＭ３１と番号付けされるとする。
【０３２４】
ＣＡＭアレイは状態マシンとして実装されるＣＡＭコントローラによって制御され、キャッシュ・メモリは、これも状態マシンとして実装されるキャッシュ・メモリ・コントローラによって制御される。そのようなコントローラに対する必要性、およびそれらを状態マシンとしてまたは他の形で実装する方法は、この動作説明により当業者には明らかであろう。これらのコントローラと、一体化メモリ・コントローラのような他のコントローラとの混乱を避けるため、この２つのコントローラはそれぞれＣＡＭ状態マシンおよびメモリ状態マシンと呼ぶ。
【０３２５】
キャッシュの状態がキャッシュが満たされているというものである一例を考察する。さらに、ＣＡＭスタックの内容（アドレスおよびキャッシュ・メモリに対するポインタ）およびキャッシュ・メモリの各ページ番号アドレスにおけるキャッシュ・メモリの内容は、以下の表に示されるものとする。
【０３２６】
【表７】
0005517821.tif 000009
これは、ＣＡＭ４がハッシュ値であるハッシュ４を含むことおよび将来それに一致すること、ハッシュ４に関する探索はキャッシュ・メモリにおいて一致を得てアドレス・ページ４を生成するということである。さらに、キャッシュ・メモリにおけるページ４は、フロー・エントリ，エントリ４を含み、これは、この標記において、ハッシュ値のハッシュ４に一致するフロー・エントリである。この表は、ハッシュ０がハッシュ１より最近使用され、ハッシュ１はハッシュ２より最近多く使用され、以下同様であり、ハッシュ３１は最も長く未使用であるハッシュ値であることも示している。ＬＵＥ１１０７はハッシュ値のハッシュ３１に関し、一体化フロー・キー・バッファ１１０３からエントリを取得するとする。ＬＵＥはＣＡＭアレイを通じてキャッシュ・サブシステムを探索する。ＣＡＭ３１はヒットを得て、そのヒットのページ番号すなわちページ３１を返す。キャッシュ・サブシステムは今や、ＬＵＥ１１０７に対して、供給したハッシュ値がヒットを生み出したことを示し、ハッシュ３１に対応するフロー・エントリ、すなわちフロー３１を含むキャッシュ・メモリのページ３１に対するポインタを提供する。ＬＵＥはアドレス・ページ３１においてキャッシュ・メモリからフロー・エントリ、フロー３１を取り出す。好適実施例では、キャッシュの探索は１クロック・サイクルを要するに過ぎない。
【０３２７】
ハッシュ３１の値は、最も最近使用したハッシュ値である。したがって、本願キャッシュ・システムのある側面により、最も最近使用したエントリがＣＡＭスタックの最上部に置かれる。こうして、ハッシュ３１は（ページ３１を示す）ＣＡＭ０に置かれる。さらに、ハッシュ３０が現在のＬＲＵハッシュ値であり、よってＣＡＭ３１に移動させられる。その次に最も長く未使用であるハッシュ値のハッシュ２９は、ＣＡＭ３０に移動させられ、以下同様に続く。こうして、ＭＳＵエントリが最上部ＣＡＭに置かれた後に、全ＣＡＭ内容が下にシフトされる。好適実施例では、ＣＡＭエントリに関するシフト・ダウンは、１クロック・サイクルを要する。こうして、探索し、利用の最近さに従った順序を維持するようＣＡＭアレイを並べ替える。以下のテーブルは、ＣＡＭアレイの新しい内容およびキャッシュ・メモリの（不変な）内容を示す。
【０３２８】
【表８】
0005517821.tif 000010
この例を続けると、いくらかの時間経過後、ＬＵＥ１００７がハッシュ値のハッシュ５を探索するものとする。これは、キャッシュ・メモリのページ５を指すＣＡＭ６におけるヒットを生成する。１クロック・サイクルで、キャッシュ・サブシステム１１１５は、ＬＵＥ１００７にヒットの指示を提供し、キャッシュ・メモリにおけるフロー・エントリに対するポインタを提供する。最も最近のエントリはハッシュ５であり、従って、ハッシュ５とキャッシュ・メモリ・アドレス・ページ６がＣＡＭ０に入力される。残りのＣＡＭの内容は、ハッシュ５を包含していたエントリを含めてみな１つだけシフト・ダウンされる。すなわち、ＣＡＭ７，ＣＡＭ８，．．．，ＣＡＭ３１は不変のままである。ＣＡＭアレイ内容および不変のキャッシュ・メモリ内容は、今では以下のテーブルに示されるようなものである。
【０３２９】
【表９】
0005517821.tif 000011
キャッシュ・ヒットの場合、ＣＡＭアレイは、最上部ＣＡＭに最も最近に使用したハッシュ値がくるように、利用の最新さの順序で、使用したハッシュ値を常に維持する。
【０３３０】
キャッシュ・ヒットが生じた場合のキャッシュ・サブシステムの動作について、引き続き上記の例を参照して説明する。（例えばＬＵＥ１１０７から）ハッシュ値のハッシュ４３が探索されるものと仮定する。ＣＡＭアレイは「ミス」を生成し、外部メモリ内のハッシュを利用する探索を行わせる。この個別的な実施例の具体的な動作は、ＣＡＭ状態マシンがメモリ状態マシンに取得メッセージ(GET  message)を送出し、一体化メモリ・コントローラ（ＵＭＣ）１１１９を介してそのハッシュを使用するメモリ探索を行わせる。だが、ＣＡＭアレイ内でミスが生じた場合のメモリ探索を行う他の手段についても、当業者に明らかであろう。
【０３３１】
フロー・エントリ・データベース３２４（すなわち外部メモリ）における探索は、ヒットまたはミスになる。フロー・エントリのデータベース３２４が、ハッシュ値のハッシュ４３に一致するエントリを有しないと仮定すると、メモリ状態マシンは、ＣＡＭ状態マシンに対してミスを示し、ＣＡＭ状態マシンはＬＵＥ１００７に対してミスを示す。一方、ハッシュ値のハッシュ４３に一致するフロー・エントリ――エントリ４３――がデータベース３２４内に存在すると仮定すると、この場合は、そのフロー・エントリはキャッシュにロードされる。
【０３３２】
本発明の更なる特徴によれば、最下部ＣＡＭエントリＣＡＭ３１は、キャッシュ・メモリ内で常にＬＲＵアドレスを指示する。このように、真のＬＲＵ置換方針の実装は、そのＬＲＵキャッシュ・メモリ・エントリをフラッシュ・アウトし(flush  out)、最下部ＣＡＭにより指示されるＬＲＵキャッシュ・メモリ・ロケーションに新規エントリを挿入することを含む。ＣＡＭエントリは、指示されるキャッシュ・メモリ要素におけるエントリの新たなハッシュ値を反映するよう修正される。ハッシュ値のハッシュ４３はＣＡＭ３１に置かれ、フロー・エントリ、エントリ４３はＣＡＭ３１によって指示されるキャッシュ・ページ内に置かれる。ＣＡＭアレイおよびその変更したキャッシュ・メモリの内容は以下のとおりである。
【０３３３】
【表１０】
0005517821.tif 000012
挿入されたエントリはＭＲＵフロー・エントリである点に留意すべきである。したがって、ＣＡＭ３１の内容は、ＣＡＭ０に移動させられ、それまで上部の３０個のＣＡＭ内にあった内容は下に動かされ、それにより再び、最下部ＣＡＭはＬＲＵキャッシュ・メモリ・ページを指示する。
【０３３４】
【表１１】
0005517821.tif 000013
既存のフロー・エントリの取得のためにキャッシュ・サブシステム１１１５を介してデータベース３２４のエントリを探索することに加えて、ＬＵＥ，ＳＰまたはＦＩＤＥエンジンは、キャッシュを介してフロー・エントリを更新することも可能である。したがって、更新されたフロー・エントリであるエントリがキャッシュ内に存在し得る。このような更新されたエントリが外部メモリ内のフロー・エントリ・データベース３２４に書き込まれるまでは、そのフロー・エントリは「ダーティ(dirty)」と呼ばれる。キャッシュ・システムにおいて一般的であるようにして、キャッシュ内でダーティ・エントリを指示するための機構が設けられる。例えば、データベース３２４内で対応するエントリが更新されるまでは、ダーティ・エントリはフラッシュアウトされないようにすることが可能である。
【０３３５】
この最後の事例において、キャッシュ内のエントリが動作（作業）によって修正されたとする。すなわち、ハッシュ４３はＭＲＵのＣＡＭ０内にあり、ＣＡＭ０は適切にページ３０を指示するが、キャッシュのページ３０における情報であるエントリ４３は、データベース３２４内のエントリ４３には対応しない。すなわち、キャッシュ・ページのページ３０の内容はダーティである。今やデータベース３２４を更新する必要がある。このことは、ダーティ・エントリのバック・アップ(backing  up)またはクリーニング(cleaning)と呼ばれる。
【０３３６】
キャッシュ・システムで一般的であるように、ダーティ・フラグを利用して、キャッシュ・メモリ・エントリがダーティであることを知らせる指標がある。好適実施例では、キャッシュ・メモリ内で各ワードについてダーティ・フラグが存在する。
【０３３７】
本願キャッシュ・システムの他の特徴は、キャッシュ・メモリ内容のクリーニングであり、キャッシュ・メモリ内で最初にフラッシュアウトされる可能性の最も高いエントリに従って行われる。本願実施例のＬＲＵキャッシュでは、キャッシュ・メモリ・エントリのクリーニングは、利用の最新さとは逆の順序で進行する。したがって、最も使われそうもないＬＲＵページが最初にクリーニングされ、これらは最初にフラッシュされる可能性の高いエントリである。
【０３３８】
本実施例では、メモリ状態マシンは、アイドルであるときはいつでも、最新さとは逆の順序で、すなわちＣＡＭアレイの下部から始めてＣＡＭアレイを走査するようプログラムされ、ダーティ・フラグを探索する。ダーティ・フラグが見出されると、キャッシュ・メモリ内容は、外部メモリにおけるデータベース３２４にバックアップされる。
【０３３９】
ひとたびキャッシュ・メモリのページがクリーニングされると、依然として必要とされる場合に備えてキャッシュ内で維持される点に留意すべきである。更なるキャッシュ・メモリ・ページが必要とされる場合にのみ、そのページはフラッシュされる。新たなメモリ・ページが必要とされるまでは、対応するＣＡＭも不変である。こうして、クリーン・エントリを含むキャッシュ・メモリ内容総ての効率的な探索が可能になる。さらに、キャッシュ・メモリ・エントリがフラッシュされるときはいつでも、そのエントリがクリーンであることを保証するためにまず検査が行われる。エントリがダーティである場合は、そのエントリをフラッシュするのに先立ってバックアップされる。
【０３４０】
キャッシュ・サブシステム１１１５は、１度に２つの読み込み（リード）転送を行うことが可能である。１度に３以上のリード要求が活性化されると、キャッシュは以下の特定の順序で対応する：
（１）ＬＲＵダーティ・ライト・バック。ダーティである場合に、キャッシュは最も長く未使用であるキャッシュ・メモリ・エントリを書き戻し、キャッシュ・ミスに関する取得用のスペースが常に存在するようにする。
【０３４１】
（２）探索および更新エンジン１１０７。
【０３４２】
（３）状態プロセッサ１１０８。
【０３４３】
（４）フロー挿入および削除エンジン１１１０。
【０３４４】
（５）分析ホスト・インターフェースおよび制御１１１８。
【０３４５】
（６）ＬＲＵ−１からのダーティ・ライト・バック。ほかに処理中のものが存在しなければ、キャッシュ・エンジンはダーティ・エントリを外部メモリに書き戻す。
【０３４６】
図２６はキャッシュ・サブシステム１１１５のキャッシュ・メモリ要素２６００を示す。キャッシュ・メモリ・サブシステム２６００は、キャッシュ・メモリのページ用の双方向〔デュアル〕ポート・メモリのバンク２６０３を有する。本願実施例では、３２ページある。メモリの各ページは双方向ポート対応である。すなわち、各々がアドレスおよびデータ入力を有する２組の入力ポートおよび２組の出力ポートを有し、入力および出力ポートの１組は、一体化メモリ・コントローラ（ＵＭＣ）１１１９に結合され、フロー・エントリ・データベース３２４のために使用される外部メモリからキャッシュ・メモリに対して書き込み、および該外部メモリに対して該キャッシュ・メモリから読み出す。出力線２６０９のうちどれがＵＭＣ１１１９に結合されるかは、キャッシュ・システム１１１５のＣＡＭメモリ・サブシステム部分からのキャッシュ・ページ選択信号を利用して、マルチプレクサ２６１１によって選択される。データベース３２４からのキャッシュ・メモリの更新は、ＵＭＣからのキャッシュ・データ信号２６１７およびキャッシュ・アドレス信号２６１５を利用する。
キャッシュ・メモリから、および探索／更新エンジン（ＬＵＥ）１１０７、状態プロセッサ（ＳＰ）またはフロー挿入／削除エンジン（ＦＩＤＥ）からキャッシュ・メモリへのデータ探索および更新は、キャッシュ・メモリ・ページ２６０３の他の入力および出力ポートを使用する。入力選択マルチプレクサ２６０５のバンクおよび１組の出力選択マルチプレクサ２６０７は、選択信号群２６１９を利用して入力および出力エンジンを夫々選択する。
【０３４７】
図２７は、ＣＡＭアレイ２７０５およびメモリ状態マシン２７０３に結合されたキャッシュＣＡＭ状態マシン２７０１を、各要素の間で受け渡される信号のいくつかとともに示す。各信号名は説明的であり、状態マシンとしてまたは他の仕方でこれらのコントローラを実現する方法は、上記の説明から明らかであろう。
【０３４８】
ＣＡＭアレイの上記の動作説明は、そのようなＣＡＭアレイを設計するために当業者にとって充分であり、１例を示す図２８のようにそのような多くの設計も可能である。前の図面に戻る。ＣＡＭアレイ２７０５は、ＣＡＭメモリのページ当たり１つのＣＡＭ、例えばＣＡＭ［７］（２８０７）を有する。探索ポートまたは更新ポートは、ＬＵＥ，ＳＰまたはＦＩＤＥのいずれがキャッシュ・システムにアクセスしているかに依存する。探索に関する入力データは、典型的にはハッシュであり、ＲＥＦ−ＤＡＴＡ２８０３として示される。キャッシュのロード、更新または取戻(evicting)は、選択マルチプレクサ２８０９を利用してＣＡＭ入力データを選択する信号２８０５を利用して行われ、そのようなデータはヒット・ページまたはＬＲＵページである（本願一形態では最下部ＣＡＭ）。５から３２へのデコーダ２８１１を通じてロードがなされる。アレイ内での総てのＣＡＭに対するＣＡＭ探索の結果は、ヒット２８１５およびどのＣＡＭ番号２８１７がヒットを生じたかを出力する３２−５ローからハイへの３２から５へのエンコーダ２８１３に供給される。ＣＡＭヒット・ページ２８１９はＭＵＸ２８２１の出力であり、そのヒットを引き出したＣＡＭの信号２８１７によって選択される入力および出力としての各ＣＡＭのＣＡＭデータを有する。ダーティ・エントリの保守は、ＣＡＭ状態マシン２７０１に結合される更新ポートに基づくものと同様に実行される。ＭＵＸ２８２３は全ＣＡＭのデータ入力および走査入力２８２７を有する。ＭＵＸ２８２３はダーティ・データ２８２５を引き出す。
【０３４９】
［パターン分解および抽出データベース・フォーマット］
異なる階層に存在し得る異なるプロトコルは、リンクされたノードの１つまたはそれ以上のツリーのノードとして考えることができる。パケット形式はツリーのルート（ベース・レベルと呼ばれる）である。各プロトコルは、次の階層の何らかの他のプロトコルの親ノードであるかまたは端末ノードであるかの何れかである。親ノードは、プロトコルを、より高位の階層レベルに位置し得る他のプロトコル（子プロトコル）にリンクする。このように、プロトコルはゼロ個以上の子をもちうる。
【０３５０】
ツリー構造に関する例として、イーサーネット・パケットを考察する。子ノードの１つはＩＰプロトコルであり得、ＩＰプロトコルの子の１つはＴＣＰプロトコルであり得る。ＩＰの他の子は、ＵＤＰプロトコルであり得る。
【０３５１】
パケットは、使用された各プロトコルに関する少なくとも１つのヘッダを有する。パケット内で使用された特定のプロトコルの子プロトコルは、その特定のプロトコルのヘッダ内のあるロケーションにおける内容によって示される。子を特定するパケットの内容は、子認識パターンの形式である。
【０３５２】
ネットワーク分析器は多くの様々なプロトコルを分析可能であることが好ましい。ベース・レベルにおいて、ディジタル・テレコミュニケーションで使用される多数のパケット形式が存在し、特に、イーサーネット，ＨＤＬＣ，ＩＳＤＮ，ＬａｐＢ，ＡＴＭ，Ｘ．２５，フレーム・リレー，ディジタル・データ・サービス，ファイバ配信データ・インターフェース（ＦＤＤＩ），およびＴ１がある。これらパケット形式の多くは異なるパケットおよび／またはフレーム・フォーマットを使用する。例えば、データはＡＴＭおよびフレーム・リレー・システムにおいては、５３オクテット（すなわちバイト）長である固定長パケット（「セル」と呼ばれる）の形で送信され；いくつかのそのようなセルが、他の形式の単独パケットに包含されうる情報を形成するために必要とされ得る。
【０３５３】
パケットなる用語は、パケット、データグラム、フレームおよびセルを包含することが意図されている点に留意すべきである。一般に、パケット・フォーマットまたはフレーム・フォーマットは、ネットワークを通じた伝送のために様々なフィールドおよびヘッダを用いてデータがどのように包含されるかを示す。例えば、データ・パケットは典型的には、パケットの開始および終了を識別するヘッダおよびフッタだけでなく、アドレスあて先フィールド、長さフィールド、エラー訂正コード（ＥＣＣ）フィールドまたは巡回冗長チェック（ＣＲＣ）フィールドをも含む。「パケット・フォーマット」、「フレーム・フォーマット」および「セル・フォーマット」なる用語は、概して同義語である。
【０３５４】
パケット・モニタ３００は、様々なプロトコルを分析することが可能であり、パケットに対して様々なプロトコル特有の動作を実行することが可能であり、プロトコルのプロトコル・ヘッダは、親プロトコルまたはそのパケットで使用されたプロトコルに依存して異なるロケーションに位置している。パケット・モニタは、パケットの内容に従って、様々なプロトコルに適応する。パケットから抽出された位置および情報は、パケットの特定の形式に対して適応的に判定される。例えば、フロー署名を形成するために、探索するものまたは探索する場所についての固定的な定義はない。Ｃｈｉｕ等による米国特許第５，１０１，４０２号で説明されているようないくつかの従来のシステムでは、パケットの特定の形式に関して特定された固定的な位置が存在する。プロトコルの増加に伴って、そのセッションを判別するために探索するする総ての可能な場所を特定することはますます困難になる。同様に、新規プロトコルまたはアプリケーションを追加することは困難である。本発明では、プロトコルに関する階層数は可変であり、レベル体系において我々が至りたいレベルと同程度に高く、（ＯＳＩモデルにおける）アプリケーション層に至るまでずっと、一義的に識別するのに充分である任意の数である。
【０３５５】
同一のプロトコルであっても異なる変形体がある。イーサーネット・パケットは例えばいくつかの既知の変形体があり、各々は実質的に同一の基本フォーマットを有する。イーサーネット・パケット（ルート・ノード）は、イーサー形式パケット――イーサーネット形式／バージョン２およびディジタル・インテル・ゼロックス・パケット（ＤＩＸ）とも呼ばれる――またはＩＥＥＥイーサーネット（ＩＥＥＥ８０３.ｘ）パケットである。モニタはイーサーネット・プロトコルの総ての形式を処理可能であることが好ましい。イーサー形式プロトコルに関しては、子プロトコルを指示する内容は、１つのローケーション内にあるが、ＩＥＥＥ形式に関しては、子プロトコルは他のロケーションで特定される。子プロトコルは子認識パターンによって指示される。
【０３５６】
図１６は、完全なイーサーネット情報フレーム（すなわちパケット）のヘッダ１６００（ベース・レベル１）を示し、あて先メディア・アクセス・コントロール・アドレス（ＤｓｔＭＡＣ１６０２）およびソース・メディア・アクセス・コントロール・アドレス（ＳｒｃＭＡＣ１６０４）を含む。図１６にはまた、署名を抽出するためのＰＤＬファイルで特定される情報の一部（全部ではない）も示されている。そのような情報は、分解機構および抽出作業データベース３０８で特定される。これは、ＤｓｔＭＡＣ情報１６０６の６バイトおよびＳｒｃＭＡＣ情報１６１０の６バイトの形式で、このレベルにおけるヘッダ情報全てを含む。また、それぞれハッシュのソースおよびあて先アドレス成分も特定される。ＤｓｔＭＡＣアドレスからの２バイトＤｓｔハッシュ１６０８およびＳｒｃＭＡＣアドレスからの２バイトＳｒｃハッシュ１６１２も示されている。最後に、次の階層レベルに関連する情報のためのヘッダが始まる場所に関する情報が含まれる（１６１４）。この場合、次の階層レベル（レベル２）情報は、パケット・オフセット１２から開始する。
【０３５７】
図１７Ａは、イーサー形式パケット１７００に対する次のレベル（レベル２）のためのヘッダ情報を示す。
【０３５８】
イーサー形式パケット１７００に関し、次の階層レベルを指示する当該パケットからの有意な情報は、次のレベルに対する子認識パターンを含む２バイト形式フィールドである。残余の情報１７０４に影が付されているのは、このレベルに有意でないからである。リスト１７１２は、イーサー形式パケットに対する可能な子を示し、どの子認識パターンがオフセット１２に見出されるかで示している。
【０３５９】
また、分解レコードに対して使用され、次のヘッダ情報を位置特定するための抽出部分の一部も示されている。分解レコードの署名部分は、抽出された部分１７０２を含む。この情報からの１バイト・ハッシュ成分１７１０も含まれる。
【０３６０】
オフセット・フィールド１７１０は、次のレベルの情報へ進むためすなわち次の階層レベルのヘッダの開始を位置特定するためのオフセットを提供する。イーサー形式パケットに関して、次の階層ヘッダの開始はフレームの開始から１４バイトである。
【０３６１】
他のパケット形式は異なるようにして配置される。例えば、ＡＴＭシステムでは、各ＡＴＭパケットは、５オクテット「ヘッダ」セグメントの後に４８オクテット「ペイロード」セグメントを含む。ＡＴＭセルのヘッダ・セグメントは、ペーロード・セグメントに含まれるデータのルーティングに関する情報を含む。ヘッダ・セグメントはトラフィック制御情報も含む。ヘッダ・セグメントの８または１２ビットは、仮想経路識別子（ＶＰＩ）を含み、ヘッダ・セグメントの１６ビットは仮想チャネル識別子（ＶＣＩ）を含む。各ＡＴＭ交換機はＶＰＩおよびＶＣＩビットにより表現された抽象的なルーティング情報を、物理または論理ネットワーク・リンクのアドレスに翻訳し、適切に各ＡＴＭセルをルーティングする。
【０３６２】
図１７Ｂは可能な次のレベルの１つのヘッダの構造を示し、ＩＰプロトコルに対するものである。ＩＰプロトコルの可能な子は、テーブル１７５２に示されている。ヘッダは、親プロトコルに依存して異なる位置（Ｌ３）から始まる。署名のために抽出されるフィールドの一部、および次のレベルのヘッダが当該パケット内で開始する場所の指標も図１７Ｂに包含される。
【０３６３】
図１６，図１７Ａおよび図１７Ｂに示される情報は、ＰＤＬファイル形式でモニタに対して指定され、コンパイルされてパターン構造および抽出作業のデータベース３０８に取り込まれる。
【０３６４】
分解サブシステム３０１は、データベース３０８に格納された情報に基づいてパケット・ヘッダ・データに関する動作を実行する。プロトコルに関連するデータは、ツリー形式に組織化されたものとして考えることが可能であるので、分解サブシステムにおいて、ツリー形式で当初組織化されたデータを通じて探索することが必要である。リアル・タイム動作が好ましいので、そのような探索を迅速に行う必要がある。
【０３６５】
ツリーとして組織化された情報を効率的に格納するためのデータ構造は既知である。そのような格納効率のよい手段は、典型的には、データ・ノードに対するポインタを判別する算術計算を要する。したがって、そのような格納効率のよいデータ構造を利用する探索は、本願の用途にとってはあまりに多くの時間を費やしてしまう。したがって、迅速な探索を可能にする何らかの形式でプロトコル・データを格納することが好ましい。
【０３６６】
本発明の他の特徴によれば、データベース３０８は、メモリに格納され、パケットに対して実行されるプロトコル特有の動作を格納するためのデータ構造を有する。特に、分解サブシステム３０１におけるパターン認識プロセス３０４および抽出プロセス３０６で使用されるパターン分解および抽出データベース３０８に情報を格納するために、圧縮された表現が利用される。データ構造の内容を指す１つまたはそれ以上の指標群を利用することによって、子プロトコル関連情報を迅速に位置特定するためにデータ構造が組織化される。データ構造エントリは有効性の指標も含む。子プロトコルの位置特定および識別は、有効なエントリが見出されるまでデータ構造を指示していくことを含む。パターン認識エンジン（ＰＲＥ）１００６によって使用されるプロトコル情報を格納するためのデータ構造を利用することは、分解サブシステム３０１が迅速な探索を行うことを可能にする。
【０３６７】
一実施例にあっては、データ構造は３次元構造の形である。この３次元構造は、典型的には２次元構造の集合としてメモリに格納され、３Ｄ構造の３次元のうち１つの次元は、特定の２Ｄアレイに対する指標〔インデックス〕として使用される。これは、データ構造に対する第１指標を形成する。
【０３６８】
図１８Ａはそのような３Ｄ表現１８００を示す（２Ｄ表現のインデックスが付された集合(indexed  set)として考えることが可能である）。このデータ構造の３つの次元は以下のとおりである：
１．タイプ識別子［１：Ｍ］。これは、特定のレベルにおけるプロトコルの形式を識別する識別子である。例えば、０１はイーサーネット・フレームを示す。６４はＩＰを、１６はＩＥＥＥ形式イーサーネット・パケットを示す、などである。パケット分解装置が取り扱うことの可能なプロトコル数に依存して、Ｍを大きな数とすることが可能であり；更なるプロトコルを分析する能力がモニタ３００に付加されたりして、Ｍを時間と共に変化させることも可能である。３Ｄ構造が２Ｄ構造の集合として考えられる場合には、タイプＩＤは特定の２Ｄ構造に対する指標である。
【０３６９】
２．サイズ［１：６４］。パケット内で対象とするフィールドの大きさである。
【０３７０】
３．ロケーション［１：５１２］。いくつかのオクテット（バイト）として表現される、パケット内のオフセット位置である。
【０３７１】
これらロケーションの任意の１つにおいて、有効データが存在したりしなかったりする。典型的には、３ＤアレイのサイズはＭ＊６４＊５１２であり、非常に大きくなり得る。例えばＭは１００００でありうる。これは、多くのエントリが空（すなわち無効）のまばらな３Ｄ行列である。
【０３７２】
各アレイ・エントリは、内容の性質を示す「ノード・コード」を有する。このノード・コードは４値のうちの１つを有する：（１）「プロトコル」ノード・コードであって、既知のプロトコルが次の（すなわち、子）プロトコルとして認識されたことをパターン認識プロセス３０４に対して示す；（２）「端末」ノード・コードであって、目下探索しているプロトコルに関して子プロトコルが存在せず、そのノードがプロトコル・ツリーにおける最終ノードであることを示す；（３）「ヌル」（「フラッシュ」とも呼ばれる）ノード・コードであって、有効なエントリが存在しないことを示す。
【０３７３】
好適実施例では、可能な子および他の情報が初期化によってデータ構造内にロードされ、その初期化はＰＤＬファイル３３６および階層選択３３８に基づくコンパイル・プロセス３１０を含む。プロトコルを表現するデータ構造内の任意のエントリに、以下の情報が含まれる。
【０３７４】
（ａ）次に探索する子のリスト（タイプＩＤとして）。例えば、イーサーネット形式２に関して、子はイーサー形式である（図１７の１７１２において示されるようなＩＰ，ＩＰＸ等）。これらの子は、タイプ〔形式〕・コードにコンパイルされる。ＩＰに関するコードは６４であり、ＩＰＸに関するものは８３である、など。
【０３７５】
（ｂ）リスト中のＩＤの各々について、子認識パターンのリストであって、比較されることを要しないもの。例えば、リスト中の６４：０８００（１６）は、タイプＩＤ６４である子（これはＩＰプロトコルである）に対して、探索する値が０８００（１６進）であることを示す。リスト中の８３：８１３７（１６）は、タイプＩＤ８３である子（これはＩＰＸプロトコルである）に対して、探索する値が８１３７（１６進）であることを示す。等々。
【０３７６】
（ｃ）フローに関する識別署名を構築するために実行する抽出動作。使用されるフォーマットは、（オフセット、長さ、フロー_署名_値_識別子）であり、フロー_署名_値_識別子は抽出したエントリがその署名において進行する場所を示し、実行されるべき作業（ＡＮＤ，ＯＲ等）が何であるかを含む。ハッシュ・キー要素も存在する場合は、例えば、それに関する情報が包含される。例えば、イーサー形式パケットに関し、２バイト形式（図１７Ａの１７０６）が署名に使用される。さらに、この形式の１バイト・ハッシュ（図１７Ａの１７０８）が包含される。さらに、子プロトコルはオフセット１４から始まる点に留意すべきである。
【０３７７】
付加的な項目は「折り重ね(fold)」でありうる。折り重ねを利用して、３Ｄ構造の格納の要件を減少させる。各プロトコルＩＤに関する各々の２Ｄアレイは要素をもつものがまばらなので、個々のエントリが互いに衝突しない限り、複数のアレイが単独の２Ｄアレイに組み合わされてもよい。その際、折り重ね数が各要素を関連付けるために使用される。所与の探索に関し、その探索の折り重ね数は、折り重ね数エントリに一致しなければならない。折り重ねについてはのちに更に説明する。
【０３７８】
イーサーネットの場合、次のプロトコル・フィールドは長さを示し、分解装置に対して、ＩＥＥＥ形式パケットであることを告げ、次のプロトコルが他の場所にあることを告げる。通常は、次のプロトコル・フィールドは、その次すなわち子プロトコルを識別する値を包含する。
【０３７９】
分解サブシステムに関するエントリ・ポイントは、仮想ベース階層(virtual  base  layer)と呼ばれ、例えばパケット形式のような可能な第１子を含む。高レベル・プロトコル記述言語（ＰＤＬ）で書かれた例示的な１組のプロトコルがここに含まれる。その組はＰＤＬファイルを含み、総ての可能なエントリ・ポイント（すなわち仮想ベース）を記述するファイルは、virtual.pdlと呼ばれる。イーサーネット示す１つの子０１のみがこのファイルに存在する。したがって、本事例はイーサーネット・パケットのみを処理することが可能である。実際には、複数のエントリ・ポイントが存在し得る。
【０３８０】
一実施例にあっては、パケット捕捉装置は捕捉したモニタ３００に入力されるパケット総てについて、パケットの形式を示すヘッダを提供する。このヘッダを利用して、分解サブシステムに対する仮想ベース階層エントリ・ポイントを判別する。このように、ベース階層おいてでさえも、分解サブシステムはパケットの形式を識別することが可能である。
【０３８１】
はじめに、捕捉装置によって供給されるヘッダにおいて取得された仮想ベースの子から探索が始まる。この例の場合、これはＩＤ値０１を有し、これはイーサーパケットに関する、３Ｄ構造全体における２Ｄアレイである。
【０３８２】
パターン分析プロセス３０４を実装するハードウエア（たとえば図１０のパターン認識エンジン（ＰＲＥ）１００６）は、プロトコルＩＤ０１を有する２Ｄアレイに関して子（もし存在すれば）を判別するために探索する。３Ｄデータ構造を利用する好適実施例では、ハードウエアＰＲＥ１００６は、同時に４つまでの長さ（すなわちサイズ）に関して探索する。プロセス３０４は４つの長さのグループで探索する。プロトコルＩＤ０１から開始し、探索される３Ｄロケーションの最初の２つの組は、以下のとおりである。
【０３８３】
（１，１，１）  （１，１，２）  ．．．
（１，２，１）  （１，２，２）
（１，３，１）  （１，３，２）
（１，４，１）  （１，４，２）
探索の各段階において、分析プロセス３０４はパケットおよび３Ｄデータ構造を調査し、一致の存否を調べる（ノード・コードを調べることによって）。たとえばノード・コードを利用して、有効なデータ見出されなかった場合は、そのサイズがインクリメントされ（最大で４）、その後オフセットもインクリメントされる。
【０３８４】
この例を続けると、パターン分析プロセス３０４が１，２，１２において何かを発見したとする。これは、プロトコルＩＤ値０１（イーサーネット）に関し、次の（子）プロトコルに関連しうる２バイト（オクテット）長の当該パケット内の情報が存在することを、プロセス３０４が見出すということである。例えばこの情報は、子認識パターンとして表現されるそのプロトコルに関する子についてのものでありうる。パケットのその部分にありうる可能な子認識パターンのリストは、データ構造から取得される。
【０３８５】
イーサーネット・パケット構造は２つのフレーバ(flavor)があり、イーサー形式パケットとより新しいＩＥＥＥ形式であり、子を識別するパケット位置は両者で異なる。イーサー形式パケットに対して子を示す位置は、ＩＥＥＥ形式に対しては「長さ」を示し、イーサーネット・パケットについて、「次のプロトコル」位置が値であるか長さであるかについて判定が行われる（これは、「長さ」作業と呼ばれる）。長さ作業の成功が０５ＤＣ（１６）以下の内容によって示される場合は、これはＩＥＥＥ形式イーサーネット・フレームである。この場合は、子認識パターンはそれ以外の場所で探索される。そうでない場合は、その場所が子を示す値を含む。
エントリが値（例えば子プロトコルＩＤについての値）または長さ（子プロトコルを判別するための更なる分析を示す）であるこの機能は、イーサーネット・パケットに対してだけ使用されるが、将来的には他のパケットにも最終的には応用され得る。したがって、ＰＤＬファイルでマクロの形式のこの機能は、そのような将来的なパケットがデコードされることを可能にする。
【０３８６】
この例を続けると、長さ作業が成功しなかったと仮定する。この場合、我々はイーサー形式パケットを有し、次のプロトコル・フィールド（子認識パターンを含む）は、図１７Ａにおけるパケット・フィールド１７０２として示されるようなオフセット１２から始まる２バイトの長さである。これは、図１７Ａにおけるテーブル１７１２内に示されるイーサー形式の子の１つである。ＰＲＥはそのデータ構造内の情報を使用して、見出した２バイト子認識パターンに関してＩＤコードが何であるかを検査する。例えば、子認識パターンが０８００（１６進）である場合は、プロトコルはＩＰである。子認識パターンが０ＢＡＤ（１６進）である場合は、プロトコルはＶＩＰ（ＶＩＮＥＳ）である。
【０３８７】
他の実施例において、総ての子認識パターンおよびそれらの対応するプロトコルＩＤを含む別個のテーブルを維持することも可能である。
【０３８８】
この例を続けると、１，２，１２における子認識パターンがＩＰを示す０８００（１６）であると仮定する。ＩＰプロトコルに関するＩＤコードは６４（１０）である。イーサー形式の例を続けると、分解装置がプロトコルに関する可能な子の１つに一致すると――今の例ではプロトコル形式が６４というＩＤを有するＩＰであるとすると――分解装置は次のレベルに対する探索を継続する。ＩＤが６４であり、長さは未知であり、オフセットは１４バイト（形式についての１２オフセットに、形式の長さ２を加えたもの）以上であることがわかっており、よって、３Ｄ構造の探索はパケット・オフセット１４における位置（６４，１）から始まる。パケット・オフセット１４で（６４，２）において、中身のあるノードが見出される。ヘッダの詳細は図１７Ｂの１７５０に示される。可能な子はテーブル１７５２に示される。
【０３８９】
あるいは、（１，２，１２）において長さ１２１１（１０）が存在していたとする。これは、ＩＥＥＥ形式イーサーネット・フレームであることを示し、ＩＥＥＥ形式イーサーネット・フレームならその形式を他の場所に格納している。ＰＲＥは同一レベルで、ただしＩＥＥＥ形式のイーサーネット・フレームのものである新たなＩＤに対して、その探索を継続する。ＩＥＥＥイーサーネット・パケットはプロトコルＩＤ１６を有し、よって、ＰＲＥは、パケット・オフセット１４から始まるＩＤ１６を利用して３次元空間の探索を継続する。
【０３９０】
本実施例では、パケット・オフセット１４における（１６，２）において「プロトコル」ノード・コードが存在し、次のプロトコルが子認識パターン０８００（１６）によって特定されると仮定する。これは、その子がタイプＩＤ６４を有するＩＰプロトコルであることを示す。こうして、パケット・オフセット１６における（６４，１）から探索が続く。
【０３９１】
［圧縮］
上述したように、３Ｄデータ構造は非常に大きく、要素がまばらに散在する。例えば、各ロケーションに３２バイト格納されているとすると、長さはＭ＊６４＊５１２＊３２バイトになり、これはＭメガバイトである。もしＭ＝１００００ならば、これは約１０ギガバイトになる。データベース３０８を格納するための分解サブシステムに１０Ｇバイトのメモリを含めることは現実的ではない。したがって、好適実施例では、データを格納する圧縮された形式が使用される。圧縮は、コンパイル・プロセス３１０の最適化要素によって実行されることが好ましい。
【０３９２】
データ構造がまばらであることに留意する。異なる実施例では、異なる圧縮手法を利用して、データ構造の散在性を活用してもよい。一実施例では、多次元ラン・レングス・エンコードを修正して利用する。
【０３９３】
他の実施例では、より少数の２次元構造を利用して情報を格納し、その情報は、その手法を利用しなかったならば巨大な３次元構造となっていたであろうものである。この第２の手法が好適実施例で使用される。
【０３９４】
図１８Ａは、３Ｄアレイ１８００がどのようにして各プロトコル（すなわち、プロトコルＩＤの各々の値）に対して１つの２Ｄアレイからなる１組の２Ｄアレイとして考えられるかを示す。２Ｄアレイは、Ｍ個のプロトコルＩＤに至るまでの１８０２−１，１８０２−２，．．．，１８０２−Ｍとして示される。１つのテーブル・エントリは１８０４として示される。テーブルにおけるギャップは、各２Ｄ構造テーブルが典型的には大きいことを図示するためのものである。
【０３９５】
可能なプロトコルを表現する１組のツリーを考察する。各ノードはプロトコルを表現し、プロトコルは子を有するか又は末端のプロトコルである。ツリーのベース（ルート）は子としての総てのパケット形式を有する。他のノードは、レベル１からツリーの最終的な末端ノードへの様々なレベルにおける、ツリー内のノードを形成する。こうして、ベース・ノードにおける１つの要素は参照ノードＩＤ１であり、ベース・ノードにおける他の要素は参照ノードＩＤ２であり、以下同様である。ツリー内においてルートからツリーをたどってゆくと、ツリー内で、同一のノードが次に参照されるような複数の場所が生じ得る。これは、例えばテルネット(Telnet)のようなアプリケーション・プロトコルがＴＣＰまたはＵＤＰのようないくつかの転送接続において走っている場合に生じ得る。テルネット・ノードを繰り返すのではなく、いくつかの親を有し得る１つのノードのみがパターン・データベース３０８内で表現される。これによりスペースの急増を抑制することができる。
【０３９６】
図１８Ａにおける各２Ｄ構造はプロトコルを表現する。いくつかの親をもち得るプロトコルにつき１つのみのアレイを使用することによってスペースを節約可能にするために、本願一実施例において、パターン分析サブプロセスが「現在のヘッダ」ポインタを維持する。３Ｄ構造における各プロトコル２Ｄアレイに対する各ロケーション（オフセット）指標は、その特定のプロトコルに対するヘッダ先頭ではじまる相対位置である。
【０３９７】
２次元アレイの各々はまばらである。最適化の次のステップは、他の総ての２Ｄアレイに対して２Ｄアレイを総て検査し、どれがメモリを共有し得るかを見出すことである。これら２Ｄアレイの多くはまばらに要素をもつ、つまり、各々が少数の有効エントリを有するに過ぎないことが多い。したがって次に「折り重ね」のプロセスを利用して、当初の２Ｄアレイのうちどのアレイの識別性も喪失することなしに、２以上の２Ｄアレイを一体の物理的な２Ｄアレイに統合する（すなわち、総ての２Ｄアレイが論理的には存在し続ける）。折り重ねは、所定の条件に適合する限りはそのツリーにおけるそれらの場所には無関係に、任意の２Ｄアレイの間で起こり得る。
【０３９８】
２つの２Ｄアレイが折り重ねの対象であると仮定する。第１の２ＤアレイをＡとし、第２の２ＤアレイをＢとする。両２Ｄアレイは部分的に要素をもつので、２ＤアレイＢは２ＤアレイＡと組み合わせることが可能である。ただし、これら二つの２Ｄアレイの個々の要素が同一の２Ｄロケーションの衝突を起こさない場合に限る。折り重ね可能であれば、２ＤアレイＢの有効エントリが２ＤアレイのＡの有効エントリに組み合わせられ、一体の２Ｄアレイが生じる。しかしながら、当初の２ＤアレイＡのエントリと２ＤアレイＢのエントリとが識別可能であることが必要である。たとえば、２ＤアレイＢによって表現されるプロトコルの親プロトコルが、２ＤアレイＢのプロトコルＩＤを参照したい場合に、２ＤアレイＡも参照しなければならない。しかしながら、当初の２ＤアレイＢに存在していたエントリのみがその探索に関して有効なエントリである。このため、任意の所与の２Ｄアレイにおける各要素は、折り重ね番号でタグが付される。当初のツリーが生成されるとき、総ての２Ｄアレイにおける総ての要素が折り重ね値ゼロで初期化される。そして、２ＤアレイＢが２ＤアレイＡと折り重ねられると、２ＤアレイＢの総ての有効な要素は、２ＤアレイＡ内の対応する場所に複製され、２ＤアレイＡ内のどの要素とも異なる折り重ね数が与えられる。例えば、２ＤアレイＡおよび２ＤアレイＢの両者がそのツリーにおける当初の２Ｄアレイであったとすると（すなわち、前もって折り重ねられていない）、折り重ねの後、総ての２ＤアレイＡエントリは、依然として折り重ね数０を有するが、２ＤアレイＢエントリは今や総て折り重ね数１を有する。２ＤアレイＢが２ＤアレイＡに折り重ねられた後、２ＤアレイＢの親は、それらの子の２Ｄアレイの物理的な位置における変化、および予測される折重ね値における付随する変化を通知される必要がある。
【０３９９】
２つの２Ｄアレイの個々の要素が同一の２Ｄアレイ・ロケーションに関して衝突しない限り、折り重ねプロセスは、既に折り重ねられた２つの２Ｄアレイの間でも起こり得る。上述したように、２ＤアレイＢ内の有効な要素の各々は、２ＤアレイＡの要素から区別可能に割り当てられた折り重ね数を有する必要がある。これは、２ＤアレイＡに吸収される際に総ての２ＤアレイＢ折り重ね数に固定値を加えることによって達成される。この固定値は、当初の２ＤアレイＡにおける最大の折り重ね数より１つ大きいものである。任意の所与の２Ｄアレイの折り重ね数がその２Ｄアレイにのみ関連するものであり、諸２Ｄアレイのツリー全体にわたって関連するものではないことを留意しておくことは重要である。
【０４００】
折り重ねの要件を満たす候補がなくなるまで、この折り重ねプロセスは２つの２Ｄアレイの総ての組み合わせの間で試みられることができる。これを行うことによって、２Ｄアレイの総数は顕著に減少させられる。
【０４０１】
折り重ねが行われるときはいつでも、３Ｄ構造（すなわち総ての２Ｄアレイ）は、他のアレイに折り重ねられる２Ｄアレイの親を求めて探索される必要がある。単独の２Ｄアレイを識別するプロトコルＩＤに以前マッピングされたマッチング・パターンは、その２ＤアレイＩＤおよび次の折り重ね数（すなわち、予測される折り重ね）に置換される必要がある。
【０４０２】
圧縮されたデータ構造において、各々の有効なエントリは、そのエントリに関する折り重ね数、および付加的にその子の予測される折り重ね数を有する。
【０４０３】
データベース３０８で使用されたデータ構造の他の実施例が図１８Ｂに描かれている。上述した３Ｄ構造と同様に、パターン認識プロセス３０４により実行される探索を迅速に行うことが可能であり、これは、アドレス・リンク計算を実行するのではなくメモリ内の場所を指示することによって行われる。図１８Ａのものと同様に、この構造は、ハードウエアで実現するのに適しており、例えば図１０のパターン認識エンジン（ＰＲＥ）１００６を利用して実現される。
【０４０４】
プロトコル・テーブル（ＰＴ）と呼ばれるテーブル１８５０は、モニタ３００にとって既知の各プロトコルに関するエントリを有し、各プロトコルのいくつかの特徴を含み、その特徴には、次のプロトコル（子認識パターン）を特定するフィールドがヘッダのどこで見出され得るかについての記述、次のプロトコル・フィールドの長さ、ヘッダ長およびタイプを示すフラグ、１つ又はそれ以上のスライサ命令が含まれ、そのスライサは、その階層レベルでそのプロトコルにおけるそのパケットに関してのキー要素およびハッシュ要素を形成することが可能である。
【０４０５】
任意のプロトコルに関し、１つ又はそれ以上の探索テーブル（ＬＵＴ）も存在する。この実施例に関するデータベース３０８は、１組のＬＵＴ１８７０も含む。各ＬＵＴは、パケット内で次のプロトコル・フィールドから抽出される子認識パターンの１バイトによって指示される２５６個のエントリを有する。そのようなプロトコル仕様は数バイトの長さを有し、いくつかのＬＵＴ１８７０が任意のプロトコルを探索するために必要である。
【０４０６】
各ＬＵＴのエントリは、有効性を含む内容の性質を示す２ビットの「ノード・コード」を有する。このノード・コードは４値のうちの１つを有する：（１）「プロトコル」ノード・コードであって、既知のプロトコルが認識されたことをパターン認識エンジン１００６に対して示す；（２）「中間」ノード・コードであって、複数バイト・プロトコル・コードが部分的に認識され、一連のＬＵＴを共に連結することを許容することを示す；（３）「端末」ノード・コードであって、目下探索しているプロトコルに関して子が存在せず、そのノードがプロトコル・ツリーにおける最終ノードであることを示す；（４）「ヌル」（「フラッシュ」または「無効」とも呼ばれる）ノード・コードであって、有効なエントリが存在しないことを示す。
【０４０７】
ノード・コードに加えて、各ＬＵＴエントリは、次のＬＵＴ数、次のプロトコル数（プロトコル・テーブル１８５０を探索するため）、ＬＵＴエントリの折り重ね、および予想される次の折り重ねを包含する。３Ｄ表現の圧縮形式を実現する実施例におけるものと同様に、折り重ねを利用して、ＬＵＴの組に関する格納の要件を減少させる。ＬＵＴ１８７０はまばらに散在しているので、個々のエントリが互いに衝突しない限り、複数のＬＵＴが単独のＬＵＴに統合され得る。その際、折り重ね数を利用して、各要素を、その当初のＬＵＴと関連付ける。
【０４０８】
所与の探索に関し、探索の折り重ね数は、探索テーブルにおける折り重ね数に一致する必要がある。予測される折り重ねは以前の探索テーブルから得られる（「次の予測折り重ね」フィールド）。本実施例では５ビットを利用して折り重ね数を表現し、３２個までのテーブルを１つのテーブルに折り重ねることを可能にする。
【０４０９】
図１８Ｂのデータ構造を利用する場合において、パケットが分解装置に到着するとき、仮想ベースが前置されているまたは知られている。仮想ベース・エントリは、パケット認識エンジンに対して、そのパケットにおける第１子認識パターンを見出す場所を告げる。パターン認識エンジンは、パケットから子認識パターン・バイトを抽出し、それらを仮想ベース・テーブル（第１ＬＵＴ）へのアドレスとして使用する。この方法により特定された次のＬＵＴにおいて探索されたエントリが、仮想ベース・エントリにおいて特定された予測される次の折り重ね値に一致する場合、その探索は有効と見なされる。そしてそのノード・コードが調査される。それが中間ノードである場合は、ＬＵＴ探索から得られる次のテーブル・フィールドは、アドレスの最上位の諸ビットとして使用される。次の予測される折り重ね数はエントリから抽出される。パターン認識エンジン１００６は、子認識パターンからの次のバイトを次のＬＵＴ探索のために使用する。
【０４１０】
末端コードが見出されるまで、ＰＲＥの動作は続く。次の（最初はベース階層とする）プロトコルは、プロトコル・テーブル１８５０内で探索され、ＰＲＥ１００６に対して、（分解サブシステム１０００の入力バッファ・メモリ１００８内の）パケット内のどのフィールドを利用して、フィールドのサイズを含む次のプロトコルの子認識パターンを取得するかについての情報を提供する。子認識パターン・バイトは入力バッファ・メモリ１００８から取得される。子認識パターンを形成するバイト数も今や既知である。
【０４１１】
プロトコル・コード・バイトの第１バイトは、次のＬＵＴにおける探索に使用される。ＬＵＴ探索結果がプロトコル・ノードまたは末端ノードを示すノード・コードになった場合、次のＬＵＴおよび次の予測折り重ね数が設定され、プロトコル・テーブル１８５０への指標として、ＬＵＴ探索からの「次のプロトコル」が利用される。これは、スライサ１００７に命令を提供し、次のプロトコルに対するフィールドを取得するパケット内の場所を提供する。末端コードに到達することによって示されるように、総てのフィールド（すなわちプロトコル）を処理完了するまで、ＰＲＥ１００６は続く。
【０４１２】
子認識パターンがテーブルに関して検査される場合に、予測される折り重ねが常に存在する点に留意すべきである。予測される折り重ねがテーブル内の折り重ね情報に一致する場合は、それを利用して次に何をするかを決定する。折り重ね数が不一致であれば、最適化装置は終了させられる。
【０４１３】
他の実施例では異なるサイズのＬＵＴを利用可能であり、その場合、異なる量の子認識パターンによってＬＵＴを指標〔インデックス〕することが可能である点に留意すべきである。
【０４１４】
本願実施例は、４バイトまでの子認識パターンを許容する。４バイトを超える子認識パターンは特殊な場合として取り扱われる。
【０４１５】
好適実施例では、コンパイラ・プロセス３１０によってデータベースが生成される。コンパイラ・プロセスは、プロトコル間の総てのリンクの単独のプロトコル・テーブルを最初に形成する。リンクは、親および子プロトコル間の接続から構成される。各プロトコルはゼロまたはそれ以上の子を有し得る。プロトコルが子である場合、親プロトコル、子プロトコル、子認識パターンおよび子認識パターン・サイズより成るリンクが形成される。コンパイラは先ず２バイトより長い子認識パターンを抽出する。これらは高々数個しか存在しないので、別個に取り扱われる。次に、子認識パターン・サイズ２を有する各リンクに対してサブ・リンクが形成される。
【０４１６】
総てのリンクは２５６個のエントリのＬＵＴに形成される。
【０４１７】
そして最適化が実行される。最適化の第１ステップは、他の総てのテーブルに対してテーブルの総てを検査することであり、テーブルを共有し得るものを見出す。このプロセスは、上述した２次元アレイについてと同様であるが、まばらな探索テーブルに関するものである点が異なる。
【０４１８】
初期化プロセスの一部は（例えばコンパイラ・プロセス３１０）、命令を含むデータ項目、ソース・アドレス、あて先アドレスおよび長さを利用して、スライサ命令データベースをロードする。スライサ命令を送出する場合のＰＲＥ１００６は、その命令をオフセットとしてスライサ命令データベースに送出する。命令またはＯｐコードは、そのスライサに対して、入来パケットから何を抽出するかおよびそれをフロー署名中のどこにおくかを告げる。フロー署名の所定のフィールドへの書き込みは、自動的にハッシュを生成する。その命令はまた、スライサに対して、所定のプロトコルの接続状態をどのように判定するかを告げる。
【０４１９】
他の実施例では、ＰＤＬファイルをコンパイルすること以外によりパターン、分解および抽出データベースを生成することが可能である。
【０４２０】
［コンパイル・プロセス］
コンパイル・プロセス３１０を詳細に説明する。このプロセス３１０は、分解パターンおよび抽出データベース３０８を生成することを含み、このデータベースがパケットを分解するためおよび識別する情報を抽出するために必要な情報を分解サブシステム３０１に提供する。プロセス３１０は、状態プロセス命令データベース３２６を生成することも含み、これは状態プロセス動作３２８で実行される必要がある状態プロセスを提供する。
【０４２１】
コンパイラへの入力は、生じ得るプロトコルの各々を記述する１組のファイルを含む。これらのファイルは、高レベル言語である便利なプロトコル記述言語（ＰＤＬ）におけるものである。ＰＤＬは、新たなプロトコル、および新たなアプリケーションを含む新たなレベルを特定するために使用される。ＰＤＬは、コンピュータ・ネットワークで使用されうるパケットの形式の相違およびプロトコルには依存しない。１組のＰＤＬファイルを利用して、パケットに関連する情報は何であるか、およびデコードされる必要のあるパケットを記述する。ＰＤＬは更に状態分析作業を特定するために使用される。したがって分解サブシステムおよび分析サブシステムは、様々な種類のヘッダ、階層および要素に対して適合しおよび適合させられ、例えば固有の署名を形成するために抽出または評価される必要がある。
【０４２２】
各々のパケット形式および各々のプロトコルに対して１つのファイルが存在する。したがって、イーサーネット・パケットに対してＰＤＬファイルが存在し、フレーム・リレー・パケットに対してＰＤＬファイルが存在する。ＰＤＬファイルは１つ又はそれ以上のデータベースを形成するためにコンパイルされ、該データベースが、モニタ３００がパケット上で様々なプロトコル特有動作を実行することを可能にし、この場合において、プロトコルのプロトコル・ヘッダは、親プロトコルまたはパケットで使用されるプロトコルに依存して異なるロケーションに位置する。したがって、パケット・モニタはパケットの内容に従って異なるプロトコルに適合する。特に、分解サブシステム３０１は、パケットの異なる形式に対してデータの異なる形式を抽出することが可能である。例えば、モニタは、ヘッダ情報をデコードすることを含めてイーサーネット・パケットを解釈する手法、およびヘッダ情報をデコードすることを含めてフレーム・リレー・パケットを解釈する手法も把握することが可能である。
【０４２３】
１組のＰＤＬファイルは例えば一般的なイーサーネット・パケット・ファイルを含み得る。また、例えばＩＥＥＥイーサーネット・ファイルのような各変形イーサーネット・ファイルに対するＰＤＬファイルも包含される。
【０４２４】
プロトコルに対するＰＤＬファイルは、コンパイル・プロセス３１０で必要とされる情報を提供し、データベース３０８を生成する。該データベースは、フロー署名のために当該パケットのどのプロトコル特有要素を抽出するか、フロー署名を形成するための該要素の使用方法，パケット内でのそれらの要素の探索場所，任意の子プロトコルに関する探索場所，および探索する子認識パターンが何であるかのうちの一つまたは複数を含む情報を分解および／または抽出する方法を分解サブシステムに通知する。いくつかのプロトコルに関して、抽出した要素はソースおよびあて先アドレスを含み、ＰＤＬファイルは、キーを形成するためにこれらのアドレスを利用する順序を含み得る。例えば、イーサーネット・フレームは、一層良好なフロー署名を形成する際に有益な終了点アドレスを含む。したがって、イーサーネット・パケットに対するＰＤＬファイルは、ソースおよびあて先アドレスを抽出するために分解サブシステムがどのようであるかについての情報を含み、その情報は、それらのアドレスの場所および大きさがどうであるかを含む。フレーム・リレー・ベース階層では、例えば、フローをよりよく識別することを支援する特定の終了点アドレスが存在せず、よって、パケットのこれらの形式に関しては、ＰＤＬファイルは、分解サブシステムに終了点アドレスを抽出させる情報を含まない。
【０４２５】
いくつかのプロトコルは接続に関する情報も含む。ＴＣＰはそのようなプロトコルの１例である。このようなプロトコルは全パケットに存在する接続識別子を利用する。このようなプロトコルに関するＰＤＬファイルは、これらの識別子が何であるか、それらがどこにあるか、およびそれらの長さはどれくらいかについての情報を含む。ＴＣＰの例では、例えばＩＰを通じて走っているとすると、それらはポート番号である。ＰＤＬファイルは、接続および分離に適用する状態の存否および可能な子が何であるかについての情報も含む。これらの階層の各々において、パケット・モニタ３００は、パケットに関してより多くのことを学習する。接続識別子を利用して、パケット・モニタ３００は、特定のパケットが特定のフローの一部であることを識別することが可能である。いったんフローが識別されると、システムは現在の状態および適用する状態が何であるかを判別し、その適用する状態は、接続又は分離を取り扱い、これら特定のパケットに至るまでの次の階層において存在する。
【０４２６】
好適実施例で使用される特定のＰＤＬに関して、ＰＤＬファイルは、各々がパケットにおける特定のストリングのビット又はバイトを夫々規定するゼロ又はそれ以上のフィールド・ステートメント(FIELD  statement)を含みうる。ＰＤＬファイルは更に、規定されたいくつかのフィールドを互いに結び付けるために使用されるゼロ又はそれ以上のグループ・ステートメント(GROUP  statement)を含みうる。そのような結び付けられたフィールドの集合をグループと呼ぶ。ＰＤＬファイルは更に、プロトコルのヘッダ内におけるフィールドおよびグループの順序を夫々規定するゼロ又はそれ以上のプロトコル・ステートメント(PROTOCOL  statement)を含みうる。ＰＤＬファイルは更に、アドレス、プロトコル形式およびポート番号がパケット中のどこにあるかを記述することによってフローを夫々規定するゼロ又はそれ以上のフロー・ステートメント(FLOW  statement)を含みうる。フロー・ステートメントは、そのプロトコルの子フローが状態作業を利用してどのように判定されるかの記述を含む。関連するステート〔状態〕は、フローのより多くのパケットが分析されるにつれて、学習した新しい状態を管理および維持するために使用されうる状態作業を有しうる。
【０４２７】
図２４は、ＩＰの上でＴＣＰで実行するイーサーネット・パケットの階層構造に関するＰＤＬファイル群を示す。Common.pdl（２４０３）は、共通するプロトコル定義、すなわち様々なネットワーク・プロトコルにおいて共通して使用されるフィールドに関するいくつかのフィールド定義を含む。Flows.pdl（２４０５）は一般的なフロー定義を含むファイルである。Virtual.pdl（２４０７）は、使用される仮想ベース階層に関する定義を含むＰＤＬファイルである。Ethernet.pdl（２４１１）はイーサーネット・パケットに関する定義を含むＰＤＬファイルである。イーサー形式かＩＥＥＥ形式かのイーサーネット・ファイルに関する決定はここで記述される。それがイーサー形式であれば、その選択がEithertype.pdl（２４１３）からなされる。他の実施例では、イーサー形式選択定義は、同じイーサーネット・ファイル２４１１におけるものでありうる。典型的な実装では、他のイーサー形式に関するＰＤＬファイルが包含されるであろう。IP.pdl（２４１５）は、インターネット・プロトコルに関するパケット定義を含むＰＤＬファイルである。TCP.pdl（２４１７）は、この場合はＩＰプロトコルに関する転送サービスであるところの転送制御プロトコルに関するパケット定義を含むＰＤＬファイルである。プロトコル情報を抽出することに加えて、ＴＣＰプロトコル定義ファイルは、状態の処理のための接続の識別プロセスにおいて役立つ。典型的なファイル群では、ユーザ・データグラム・プロトコル（ＵＤＰ）定義のためのUDP.pdlファイルも存在し得る。RPC.pdl（２４１９）は、遠隔手順呼出に関するパケット定義を含むＰＤＬファイルである。
【０４２８】
NFS.pdl（２４２１）は、ネットワーク・ファイル・システムのためのパケット定義を含むＰＤＬファイルである。モニタ３００が遭遇しうる総てのプロトコルに関し、他のＰＤＬファイルも典型的には包含され得る。
【０４２９】
コンパイル・プロセス３１０への入力は、対象とする総てのプロトコルに関する１組のＰＤＬファイル（例えば図２４の諸ファイル）である。プロセス３１０への入力は、データグラム階層選択３３８として図３に示される階層情報も含みうる。階層選択情報は、プロトコルの階層構造――任意の特定のプロトコルの上にどんなプロトコル（単数または複数）がありうるか――を記述する。例えば、ＩＰはイーサーネット上を走り、および他の多くの形式のパケット上をも走りうる。ＴＣＰはＩＰの上を走りうる。ＵＤＰもＩＰの上を走りうる。階層情報があらわに含まれていない場合は、それは内在的(inherent)であり；ＰＤＬファイルは子プロトコルを含み、これが階層情報を提供する。
【０４３０】
コンパイル・プロセス３１０は図２５に示される。コンパイラはＰＤＬソース・ファイルをスクラッチ・パッド・メモリ(scratch  pad  memory)にロードし（ステップ２５０３）、正しいシンタックス(syntax)に関してファイルを検討する（分解ステップ２５０５）。完了すると、コンパイラは総ての分解要素を含む中間ファイルを生成する（ステップ２５０７）。この中間ファイルは、「コンパイル・プロトコル言語」(CPL:  Compiled  Protocol  Language)と呼ばれる形式におけるものである。ＣＰＬ命令は、固定階層フォーマットを有し、各階層およびある階層に対するツリー全体にとって必要とされる総てのパターン、抽出物および状態を含む。ＣＰＬファイルはプロトコル数およびプロトコル定義を含む。各プロトコルに関するプロトコル定義は、１つ又はそれ以上のプロトコル名、プロトコルＩＤ、ヘッダ部分、グループ識別部分、任意の特定の階層に関する部分、通知部分、ペイロード部分、子の部分および状態の部分を包含し得る。ＣＰＬファイルは最適化装置によって利用され、モニタ３００で使用される最終的なデータベースを生成する。コンパイル・プロセス３１０の他の実現手段は、異なる形式の中間出力を行うこと、または中間出力を全く使用せずに最終的なデータベースを直接的に生成することを包含し得るのは当業者にとって明白であろう。
【０４３１】
分解要素が生成された後は、コンパイラはフロー署名要素を形成する（ステップ２５０９）。これは、ＣＰＬにおける抽出作業を生み出し、これはフロー署名（およびハッシュ・キー）を形成するためおよび階層間のリンクのために各ＰＤＬモジュールに関する各レベル（２００９）で必要とされる。
【０４３２】
フロー署名動作が完了すると、ＰＤＬコンパイラは、各ＰＤＬモジュールからペイロード要素を抽出するために必要とされる動作を生成する（ステップ２５１１）。これらのペイロード要素は、処理中において、高位の階層における他のＰＤＬモジュールにおける状態で使用される。
【０４３３】
最後の段階は、各ＰＤＬモジュールで必要とされる状態動作を生成することである。状態動作は、ＰＤＬファイルからコンパイルされ、後の使用のために（２０１３）ＣＰＬ形式で生成される。
【０４３４】
ＣＰＬファイルは、モニタ３００によって使用される最終的なデータベースを生成する最適化装置を通じて使用される。
【０４３５】
［プロトコル定義言語（ＰＤＬ）参照ガイド］（バージョンＡ０．０２）
ここに含まれるものは、ページ記述言語（ＰＤＬ）に関する参照ガイド（「ガイド」）であり、本発明の一形態において、これは分解および分析サブシステムで使用されるデータベースの自動生成を可能にし、新規のおよび修正されたプロトコルおよびアプリケーションを包含する能力をモニタに与える。
【０４３６】
［著作権に関する記述］
本件特許書類の明細書の部分は著作物的保護を受けるものを包含する。著作権者（かつてテクニカリ・エリート，インク．(Technically  Elite,  Inc.)であったカリフォルニア州のアプティチュード，インク．(Apptitude,  Inc.)）は、特許商標庁の特許ファイル又は記録において行われるような特許書類または特許明細書に関する他人による複写再生について異議を唱えないが、他の場合については著作権に関するいかなる権利をも留保するものとする。
【０４３７】
著作権
【外２】
【０４３８】
0005517821.tif 000014
１９９７−１９９９  アプティチュード，インク．（旧テクニカリ・エリート，インク．）。権利総ての留保。
１．  はじめに
本発明に関するプロトコル定義言語（ＰＤＬ）は、ネットワーク・プロトコルおよびプロトコル・ヘッダ内の全フィールドを記述するために使用される特定目的の言語である。
【０４３９】
このガイドにおいて、他の形式の記述と混乱の虞がなければ、プロトコル記述（ＰＤＬファイル）をＰＤＬまたは規則と言及する。
【０４４０】
ＰＤＬは、Ｃプログラム言語およびＰＥＲＬスクリプト言語のデータ構造定義の部分に類似する形式および組織の両者を利用する。ＰＤＬはネットワーク・パケット・コンタクトをデコードするために使用される言語から導出されるので、著者はパケット・デコードの要請と言語フォーマットとを混在させた。このため、表現豊かな言語となり、パケット内容およびフローを表現するために必要な詳細情報を記述するのに非常に容易で適切である。
【０４４１】
１．１  要約
ＰＤＬは、非手続的な(non-procedural)第４世代言語（４ＧＬ）である。これは、行う方法(how)を記述することなしに、行う必要のあることを記述することを意味する。どのように行うか(how)の詳細はコンパイラおよびコンパイル・プロトコル・レイアウト（ＣＰＬ）最適化ユーティリティに隠されている。
【０４４２】
さらに、どのフィールドがアドレス・フィールドであるか、プロトコル形式フィールドがどれであるか等を定義することによって、ネットワーク・フローを記述するために使用される。
【０４４３】
いったんＰＤＬファイルが書かれると、それはネットスコープ・コンパイラ(nsc:  Netscope  complier)を利用してコンパイルされ、メーターフロー・データベース(MeterFlow.db)およびネットスコープ・データベース(Netscope.db)を生成する。メータフロー・データベースはフロー定義を含み、ネットスコープ・データベースはプロトコル・ヘッダ定義を含む。
【０４４４】
これらのデータベースは、次のようなプログラムによって利用される：フロー・キー（フロー署名とも呼ばれる）を作成するmfkeys；ＣＰＬフォーマットにおけるフロー定義を作成するmfcpl；総ての既知のプロトコルのサンプル・パケットを作成するmfpkts；およびSnifferTMおよびtcpdumpファイルをデコードするnetscope等である。
【０４４５】
１．２  ガイド規約
本ガイドを通じて以下の規約が使用される。
【０４４６】
原文明細書における小文字のクーリエ(courier)・タイプフェースは、Ｃコード具体例または関数名を示す。関数はそれらの後に括弧が付され［function()］、変数はちょうどそれらの名称として記載され［variables］、そして構造名は“struct”の接頭辞が記載される［struct  packet］。
【０４４７】
原文明細書におけるイタリック体はファイル名を示す（例えば、mworks/base/h/base.h）。ファイル名は通常は分散のルート・ディレクトリに対して記載される。
【０４４８】
定数は１０進法で表現され、もしそうでなければ１６進数のＣ言語標記“0x...”で記載される。
【０４４９】
２つのハイフン(--)に続くＰＤＬファイルにおける任意の線上の内容を、コンパイラは無視する。すなわち、それらはコメントである。
【０４５０】
２．  プログラム構造
メータフローＰＤＬはデコードし、フロー・セットはステートメントの空でない(non-empty)シーケンスである。メータフローＰＤＬで利用可能なステートメントまたは定義の基本形式が４つ存在する：
フィールド，
グループ，
プロトコルおよび
フロー
である。
【０４５１】
２．１  フィールド定義
フィールド定義は、パケット中のビットまたはバイトの特定のストリングを定めるために使用される。フィールド定義は以下のフォーマットを有する：
Name  FIELD
SYNTAX  Type  [{Enum}]
DISPLAY-HINT  “FormatString”
LENGTH  “Expression”
FLAGS  FieldFlags
ENCAP  FieldName  [,  FieldName2]
LOOKUP  LookupType  [Filename]
ENCODING  EncodingType
DEFAULT  “value”
DESCRIPTION  “Description”
フィールド〔FIELD〕およびシンタックス〔SYNTAX〕・ラインのみが要求される。他のラインの総ては属性ラインであり、フィールドに関する特殊な性質を定める。属性ラインは選択的であり、順序を問わず出現し得る。以下、属性ラインの各々を更に説明する：
２．１．１  シンタックス形式〔SYNTAX  Type〕［｛Enums｝］
この属性は形式(Type)を定め、その形式が、ＩＮＴ，バイトストリング，ビットストリングまたはＳＮＭＰシーケンス形式である場合は、そのフィールドに関して列挙された値である。目下定義されている形式は以下のとおりである：
【０４５２】
【表１２】
0005517821.tif 000015
２．１．２  ディスプレイ-ヒント“フォーマットストリング”〔DISPLAY-HINT  “FormatString”〕
この属性は、フィールドの値がどのようにして表示されるかを特定するためのものである。現在使用可能なフォーマットは、以下のとおりである：
【０４５３】
【表１３】
0005517821.tif 000016
２．１．３  長さ“表現”〔LENGTH  “Expression”〕
この属性はフィールドの長さを決定するための表現を定める。表現は算術的であり、参照されるフィールド名に＄を付加することによって、パケット中の他のフィールドの値に言及することが可能である。例えば、tcpHeaderLenが現在のパケットに関して定められた他のフィールドである場合に、“($tcpHeaderLen*4)-20”は、有効な表現である。
【０４５４】
２．１．４  フラグ  フィールドフラグ〔FLAGS  FieldFlags〕
この属性はフィールドに関するいくつかの特殊なフラグを定める。現在使用可能なフィールドフラグは、以下のとおりである：
【０４５５】
【表１４】
0005517821.tif 000017
２．１．５  エンキャップ  フィールド名［,フィールド名２］〔ENCAP  FieldName  [,  FieldName2]〕
この属性は、１つのパケットが他のものの中にどのようにして包含されるかを定める。フィールド名のフィールドの値によって、どのパケットであるかが決定される。フィールド名を利用しても何らのパケットも発見されなかった場合は、フィールド名２が試行される。
【０４５６】
２．１．６  探索  探索形式［ファイル名］〔LOOKUP  LookupType  [Filename]〕
この属性は、特定のフィールド値に対する名称を探索する方法を定める。現在使用可能な探索形式は、以下のとおりである：
【０４５７】
【表１５】
0005517821.tif 000018
２．１．７  エンコード  エンコード形式〔ENCODING  EncodingType〕
この属性は、フィールドがどのようにしてエンコードされるかを定める。現在のところ唯一使用可能なエンコード形式は、ＡＳＮ．１によって定められる基本エンコード規則(BER:  Basic  Encode  Rules)である。
【０４５８】
２．１．８  デフォルト“値”〔DEFAULT  “value”〕
この属性は、このプロトコルのサンプル・パケットを生成する場合に、そのフィールドに対して使用されるデフォルト値を定める。
【０４５９】
２．１．９  記述  “記述”〔DESCRIPTION  “Description”〕
この属性は、フィールドの記述を定める。これは情報提供の目的のためにのみ使用される。
【０４６０】
２．２  グループ定義
グループ定義は、いくつかの関連するフィールドを共に結びつけるために使用される。グループ定義は以下のフォーマットを有する：
Name  GROUP
LENGTH  “Expression”
OPTIONAL  “Condition”
SUMMARIZE  “Condition”:“FormatString”[
“Condition”:“FormatString”...]
DESCRIPTION  “Description”
::=  {  Name=FieldOrGroup  [,
Name=FieldOrGroup...]}
グループ〔GROUP〕および：：＝ラインのみが要求される。他の総てのラインは属性ラインであり、グループに関する特殊な性質を定める。属性ラインは選択的であり、順序を問わず出現し得る。以下、各属性ラインを更に説明する：
２．２．１  長さ“表現”〔LENGTH  “Expression”〕
この属性はグループの長さを決定するための表現を定める。表現は算術的であり、参照されるフィールド名に＄を付加することによって、パケット中の他のフィールドの値に言及することが可能である。例えば、tcpHeaderLenが現在のパケットに関して定められた他のフィールドである場合に、“($tcpHeaderLen*4)-20”は、有効な表現である。
【０４６１】
２．２．２  選択“条件”〔OPTIONAL  “Condition”〕
この属性は、グループの存否を判定するための条件を定める。有効な条件は、以降の条件部分で定められる。
【０４６２】
２．２．３  要約“条件”：“フォーマットストリング”［“条件”：“フォーマットストリング”］〔SUMMARIZE  “Condition”:“FormatString”[“Condition”;“FormatString”...]〕
この属性は、詳細モードにおいて、グループがどのようにして表示されるかを定める。異なるフォーマット（フォーマットストリング）が、各条件に関して特定され得る。有効な条件は、以降の条件部分で定められる。＄を有するフィールド名で処理を進めることによってフォーマットストリング内において任意のフィールド値が参照され得る。フィールド名に加えて、いくつかの他の特殊な＄キーワードが存在する：
【０４６３】
【表１６】
0005517821.tif 000019
２．２．４  記述“記述”〔DESCRIPTION  “Description”〕
この属性は、グループの記述を定める。これは情報提供の目的のためにのみ使用される。
【０４６４】
２．２．５  ：：＝｛名称＝フィールドＯｒグループ［，名称＝フィールドＯｒグループ］｝〔::=  {  Name=FieldOrGroup  [,Name=FieldOrGroup...]}〕
この属性は、グループ内でのフィールドおよびサブグループの順序を定める。
【０４６５】
２．３  プロトコル定義
プロトコル定義は、そのプロトコル・ヘッダにおけるフィールドおよびグループの順序を定めるために使用される。プロトコル定義は以下のフォーマットを有する：
Name  PROTOCOL
SUMMARIZE  “Condition”:“FormatString”[
“Condition”;“FormatString”...]
DESCRIPTION  “Description”
REFERENCE  “Reference”
::={Name=FieldOrGroup  [,
Name=FieldOrGroup...]}
プロトコル〔PROTOCOL〕および：：＝ラインのみが要求される。他の総てのラインは属性ラインであり、プロトコルに関する特殊な性質を定める。属性ラインは選択的であり、順序を問わず出現し得る。以下、各属性ラインを更に説明する：
２．３．１  要約“条件”：“フォーマットストリング”［“条件”：“フォーマットストリング”］〔SUMMARIZE  “Condition”:“FormatString”[“Condition”:“FormatString”...]〕
この属性は、要約モードにおいて、プロトコルがどのようにして表示されるかを定める。異なるフォーマット（フォーマットストリング）が、各条件に関して特定され得る。有効な条件は、以降の条件部分で定められる。＄を有するフィールド名で処理を進めることによってフォーマットストリング内において任意のフィールド値が参照され得る。フィールド名に加えて、いくつかの他の特殊な＄キーワードが存在する：
【０４６６】
【表１７】
0005517821.tif 000020
２．３．２  記述“記述”〔DESCRIPTION  “Description”〕
この属性はプロトコルの記述を定める。これは情報提供目的のためにのみ使用される。
２．３．３  参照“参照”〔REFERENCE  “Reference”〕
この属性はプロトコルフォーマットを決定するために使われる参照素材を定義する。これは情報提供目的のためにのみ使用される。
【０４６７】
２．３．４  ：：＝｛名称＝フィールドＯｒグループ［，名称＝フィールドＯｒグループ］｝〔::={Name=FieldOrGroup  [,Name=FieldOrGroup...]}〕
この属性は、プロトコル内でのフィールドおよびグループの順序を定める。
【０４６８】
２．４  フロー定義
フロー定義は、アドレス、プロトコル形式およびポート番号が、パケット中のどこにあるかを記述することによって、ネットワーク・フローを定めるために使用される。フロー定義は以下のフォーマットを有する：
Name  FLOW
HEADER  {Option  [,  Option...]}
DLC-LAYER  {Option  [,  Option...]}
NET-LAYER  {Option  [,  Option...]}
CONNECTION  {Option  [,  Option...]}
PAYLOAD  {Option  [,  Option...]}
CHILDREN  {Option  [,  Option...]}
STATE-BASED
STATES  “Definitions”
フロー〔FLOW〕・ラインのみが要求される。他の総てのラインは属性ラインであり、フローに関する特殊な性質を定める。属性ラインは選択的であり、順序を問わず出現し得る。しかし、少なくとも１つの属性ラインが存在することを要する。以下、各属性ラインを更に説明する：
２．４．１  ヘッダ｛オプション，［，オプション］｝〔HEADER  {Option  [,  Option...]}〕
この属性は、プロトコル・ヘッダの長さを記述するために使用される。現在使用可能なオプションは、以下のとおりである：
【０４６９】
【表１８】
0005517821.tif 000021
２．４．２  ＤＬＣ−階層｛オプション，［，オプション］｝〔DLC-LAYER  {Option  [,  Option...]}〕
プロトコルがデータ・リンク階層プロトコルである場合、この属性がそれを記述する。現在使用可能なオプションは、以下のとおりである：
【０４７０】
【表１９】
0005517821.tif 000022
２．４．３  ネット階層｛オプション，［，オプション］｝〔NET-LAYER  {Option  [,  Option...]}〕
プロトコルがネットワーク階層プロトコルである場合に、この属性がそれを記述する。現在使用可能なオプションは、以下のとおりである：
【０４７１】
【表２０】
0005517821.tif 000023
２．４．４  接続｛オプション，［，オプション］｝〔CONNECTION  {Option  [,  Option...]}〕
プロトコルが接続指向の(connection-oriented)プロトコルである場合に、この属性は、接続がどのようにして確立されおよび消滅させられるかを記述する。現在使用可能なオプションは、以下のとおりである：
【０４７２】
【表２１】
0005517821.tif 000024
２．４．５  ペイロード｛オプション，［，オプション］｝〔PAYLOAD  {Option  [,  Option...]}〕
この属性は、分析における後の使用のために格納されるこの種のパケットからのペイロードがいくらであるかを記述する。現在使用可能なオプションは、以下のとおりである：
【０４７３】
【表２２】
0005517821.tif 000025
２．４．６  子｛オプション，［，オプション］｝〔CHILDREN  {Option  [,  Option...]}〕
この属性は、子プロトコルがどのようにして決定されるかを記述する。現在使用可能なオプションは、以下のとおりである：
【０４７４】
【表２３】
0005517821.tif 000026
２．４．７  状態ベース〔STATE-BASED〕
この属性は、フローが状態ベース・フローであることを示す。
【０４７５】
２．４．８  状態“定義”〔STATES  “Definitions”〕
この属性は、プロトコルの子フローが状態を利用してどのように決定されるかを記述する。これらの状態がどのようにして定められるかについては、以下の状態定義の部分を参照されたい。
【０４７６】
２．５  条件
条件は、オプション〔OPTIONAL〕および要約〔SUMMARIZE〕の属性と共に使用され、以下の要素より成ることが可能である：
【０４７７】
【表２４】
0005517821.tif 000027
値および値２は、フィールド参照（＄が先行するファイル名）または定数値の何れかとすることが可能である。（ＡＮＤおよびＯＲを利用した）複合的な状態ステートメントは、現在は使用することはできない。
【０４７８】
２．６  状態定義〔state  definitions〕
ネットワーク上を走る多くのアプリケーションは、複数の状態の利用を通じて、トラフィックを分類する複雑な方法を利用する。ネットワークから導出されたトラフィックから学習した状態を管理および維持するために状態定義が使用される。
【０４７９】
状態定義の基本フォーマットは以下のとおりである：
StateName:  Operand  Parameters  [Operand  Parameters...]
特定のフローの様々な状態が、以下のオペランドを利用して記述される：
２．６．１  チェック接続(CHECKCONNECT)，オペランド
接続に関する検査。接続されるとオペランドを実行する。
【０４８０】
２．６．２  ゴートゥー・ステート(GOTO  state)
現在のパケットを利用して、その状態へ向かう。
【０４８１】
２．６．３  ネクスト・ステート(Next  state)
次のパケットを利用して、その状態へ向かう。
【０４８２】
２．６．４  デフォルト  オペランド
他の総てのオペランドが失敗した場合に、そのオペランドを実行する。
【０４８３】
２．６．５  子プロトコル
子プロトコルにジャンプし、その子において（存在すれば）状態ベース処理を実行する。
【０４８４】
２．６．６  待機  パケット数，オペランド１，オペランド２(WAIT  numPackets,  operand1,  operand2)
特定されたパケット数だけ待機する。特定された数のパケットが受信されると、オペランド１が実行される。パケットは受信されたが、特定されたパケット数に満たない場合は、オペランド２が実行される。
【０４８５】
２．６．７  一致‘ストリング’重みオフセットＬＦ−オフセット範囲ＬＦ−範囲，オペランド(MATCH‘string’weight  offset  LF−offset  range  LF−range,  operand)
パケット内でストリングを探索し、発見されるとオペランドを実行する。
【０４８６】
２．６．８  定数  番号オフセット範囲，オペランド(CONSTANT  number  offset  range,  operand)
パケット内で定数に関する検査を行い、発見されるとオペランドを実行する。
【０４８７】
２．６．９  抽出ＩＰ  オフセットあて先，オペランド(EXTRACTIP  offset  destination,  operand)
パケットからＩＰアドレスを抽出し、オペランドを実行する。
【０４８８】
２．６．１０  抽出ポート  オフセットあて先，オペランド(EXTRACTPORT  offset  destination,  operand)
パケットからポート番号を抽出し、オペランドを実行する。
【０４８９】
２．６．１１  再方向付けフロー生成，オペランド(CREATEREDIRECTEDFLOW,  operand)
再方向付けされたフローを作成し、オペランドを実行する。
【０４９０】
３．ＰＤＬ規則の具体例
以下、ＰＤＬ規則ファイルのいくつかの具体例を示す。
【０４９１】
３．１  イーサーネット
以下、イーサーネットに関するＰＤＬの具体例を示す。
【０４９２】
【数１】
0005517821.tif 000028
３．２  ＩＰバージョン４
ＩＰプロトコルに関するＰＤＬの具体例を示す。
【０４９３】
【数２】
0005517821.tif 000029
【０４９４】
【数３】
0005517821.tif 000030
３．３  ＴＣＰ
ＴＣＰプロトコルに関するＰＤＬの具体例を示す。
【０４９５】
【数４】
0005517821.tif 000031
３．４  ＨＴＴＰ（状態に関連するもの）
ＨＴＴＰプロトコルに関するＰＤＬの具体例を示す。
【０４９６】
【数５】
0005517821.tif 000032
【０４９７】
【数６】
0005517821.tif 000033
【０４９８】
【数７】
0005517821.tif 000034
［メトリックを維持するためのフロー情報の再利用］
各フローのフロー・エントリは、そのフローに関する１組の統計的測定値を含み、そのフローにおける全パケット数、到着時間、および最後の到着からの時間差を含む。
【０４９９】
図３を再び参照する。状態プロセッサ３２８は、フローの状態に関して、例えばそのフローに関してそれまで識別されていた特定のプロトコルに関して、定められた動作を実行する。本発明の一形態では、フローに関する１つ又はそれ以上のメトリックの組が、フロー・エントリに含まれる１つ又はそれ以上の統計的測定値を利用してしばしば判定され得る。そのようなメトリック判定は、例えば、状態プロセッサ命令およびパターン・データベース３２６内の命令を実行する状態プロセッサによって実行され得る。そして、このようなメトリックは、分析サブシステムによって、モニタに接続されたホスト・コンピュータに送出される。あるいは、そのようなメトリック判定は、フロー・エントリ・データベース３２４に接続されたプロセッサによって実行され得る。図１０に示される好適なハードウエア手段では、分析ホスト・インターフェースおよび制御１１１８が、キャッシュ・システム１１１５を通じてフロー・エントリ・レコードにアクセスし、ホスト・バス・インターフェースを通じてプロセッサに出力するよう形成される。その後プロセッサはベース・メトリックの報告を行い得る。
【０５００】
図１５は、モニタ・システムがホスト・コンピュータ１５０４を利用してどのように構築されるかを表す。モニタ３００は、ホスト・コンピュータ１５０４にメトリックをしばしば送出し、ホスト・コンピュータ１５０４はその分析の一部を実行する。
【０５０１】
以下の部分は、ＱＯＳメトリックを提供することによって、サービス品質(QOS:  Quality  of  Service)を監視するために、本発明のモニタがどのようにして使用されるかを説明する。
【０５０２】
［サービス品質トラフィック統計値（メトリック）］
この次の部分は、本発明の一形態に従ってサービス品質（ＱＯＳ）メトリックに関して適用される共通構造を定める。また、ＱＯＳを支援するために本願実施例で判定され得る「元来の」（又は「基本の」）メトリックの組を定義する。ベース・メトリックは、状態プロセッサの一部として又はモニタ３００に接続されたプロセッサによって判定され、ＱＯＳメトリックはホスト・コンピュータ１５０４によって基本メトリックから判定される。このような分担の理由は、完全なＱＯＳメトリックは計算が複雑であり、その計算には、平方根や、リアル・タイムで利用可能なより多くの演算資源を要する他の関数を包含するためである。基本の関数は、リアル・タイムで計算することが容易であるよう選択され、それらに基づいて完全なＱＯＳメトリックが決定され得る。本発明の範疇において関数の他の分担を行うことも可能である。
【０５０３】
そのようなメトリック判定は、例えば、状態プロセッサ命令およびパターン・データベース３２６内の命令を実行する状態プロセッサによって実行され得る。そして、基本メトリックは、分析サブシステムによって、マイクロプロセッサまたはモニタに接続された論理回路に送出される。あるいは、そのようなメトリック判定は、フロー・エントリ・データベース３２４に接続されたマイクロプロセッサ（又は他の論理回路）によって実行され得る。図１０および図１１に示される好適なハードウエア手段では、そのようなマイクロプロセッサが、分析ホスト・インターフェースおよび制御１１１８を介してキャッシュ・システム１１１５に接続される。これらの要素はキャッシュ・システム１１１５を通じてフロー・エントリ・レコードにアクセスするよう形成され、マイクロプロセッサが基本メトリックを決定することおよび報告することを可能にする。
【０５０４】
ＱＯＳメトリックは、以下のメトリック・グループに分解される。それらの名称は説明的である。このリストは網羅的なものではなく、他のメトリックを利用することも可能である。以下のＱＯＳメトリックは、クライアント−サーバ（ＣＳ）およびサーバ−クライアント（ＳＣ）メトリックを包含する。
【０５０５】
ＣＳトラフィックおよびＳＣトラフィックのようなトラフィック・メトリック。
【０５０６】
ＣＳトラフィックおよびＣＳトラフィックのようなジッタ・メトリック。
【０５０７】
ＣＳ交換応答タイム開始-開始，ＣＳ交換応答タイム終了-開始，ＣＳ交換応答タイム開始-終了，ＳＣ交換応答タイム開始-開始，ＳＣ交換応答タイム終了-開始，およびＳＣ交換応答タイム開始-終了のような交換応答メトリック。
【０５０８】
ＣＳ処理応答タイム開始-開始，ＣＳアプリケーション応答タイム終了-開始，ＣＳアプリケーション応答タイム開始-終了，ＳＣ処理応答タイム開始-開始，ＳＣアプリケーション応答タイム終了-開始，およびＳＣアプリケーション応答タイム開始-終了のような処理応答メトリック。
【０５０９】
接続確立、接続自然終了(ConnectionGracefulTermination)および接続タイムアウト終了のような接続メトリック。
【０５１０】
ＣＳ接続再送信、ＳＣ接続再送信、ＣＳ接続不良およびＳＣ接続不良のような接続シーケンス・メトリック。
【０５１１】
接続ウインドウ・メトリック、ＣＳ接続ウインドウ、ＳＣ接続ウインドウ、ＣＳ接続フローズン・ウインドウ、ＳＣ接続フローズン・ウインドウ、ＣＳ接続クローズ・ウインドウ、およびＳＣ接続クローズ・ウインドウ。
【０５１２】
［ＱＯＳ基本メトリック］
データのグループを表現する最も簡易な手段は、サブレンジ（部分的範囲）における周波数分布によるものである。好適実施例では、そのサブレンジ(subrange)を形成する場合においていくつかの規則がある。第１に、その範囲を知る必要がある。第２に、サブレンジの大きさが判定される必要がある。サブレンジの大きさは固定されているのが好ましいが、他の実施例においてサブレンジの大きさを可変にすることも可能である。
【０５１３】
完全な周波数分布を判定することは、多くの計算労力を要する。このため、好適実施例では、所在するデータ要素の各々に関し、総和関数によって判定されるメトリックを使用する。
【０５１４】
プロセスを報告するメトリックは、有益な統計的測定値を計算するために使用され得るデータを提供する。一実施例にあっては、プロセスを報告するメトリックは、その状態に従ってしばしば実行される状態プロセスの一部であり、他の実施例では、プロセスを報告するメトリックは、フロー・レコードにアクセスするマイクロコンピュータによってしばしば実行される。好ましくは、プロセスを報告するメトリックは、基本メトリックを提供し、最終的なＱＯＳメトリック計算がホスト・コンピュータ１５０４によって実行される。リアル・タイムの状態プロセスを簡易にすることに加えて、この手法におけるタスクの分担は、尺度変更可能なメトリックを提供する。例えば、２つの区間からの基本メトリックが、より大きな区間に関するメトリックに組み合わせられる。
【０５１５】
例として、データの総和がデータの要素数によって除算される算術平均を考察する。
【０５１６】
【数８】
0005517821.tif 000035
プロセスを報告するメトリックによって提供される２つの基本メトリックは、ｘの総和と、要素数Ｎである。ホスト・コンピュータ１５０４は、除算を実行して平均を得る。更に、２つの区間に対する２組の基本メトリックが、ｘの総和を加算することによって、および要素数を加算して組み合わせられた総和および要素数を求めることによって組み合わせられる。そして、平均化の数式処理が同様に行われる。
【０５１７】
基本メトリックは、利用可能なデータ量を最大化するよう選択される一方、メトリックを格納するのに必要なメモリ量を最小化し、メトリックを生成するのに必要な処理条件を最小化する。基本メトリックは、メトリック・データ構造に提供され、５つの符号なし(unsigned)整数値を含む。
【０５１８】
・Ｎ    メトリックに関するデータ点のカウント数。
【０５１９】
・ΣＸ    メトリックに関するデータ点の値の総和。
【０５２０】
・Σ（Ｘ２）    メトリックに関するデータ点の値の二乗の総和。
【０５２１】
・Ｘｍａｘ    メトリックに関するデータ点の最大値。
【０５２２】
・Ｘｍｉｎ    メトリックに関するデータ点の最小値。
【０５２３】
メトリックは、ある時間間隔にわたる事象を記述するために使用される。基本メトリックは、フロー・エントリで維持される統計的測定値から決定される。総ての事象を蓄積し、その期間の終点においてカウントする必要はない。基本メトリックは、隣接する区間を結合することによって容易に尺度変更可能なように設計され得る。
【０５２４】
隣接する時間間隔に関する基本メトリックを結合する際に、以下の規則が適用される。
【０５２５】
・Ｎ          ΣＮ
・ΣＸ        Σ（ΣＸ）
・Σ（Ｘ２）    Σ（Σ（Ｘ２））
・Ｘｍａｘ    ＭＡＸ（Ｘｍａｘ）
・Ｘｍｉｎ    ＭＡＸ（Ｘｍｉｎ）
上記５つの値に加えて、好適実施例のデータ構造には「トレンド(trend)」インジケータが含まれる。これは、列挙タイプによって提供される。その理由は、トレンド情報を生成する好適な方法は、その区間に対する最初の第１の値を、その区間に対する最後の値から減算することによって行われるためである。その結果生じる数の符号のみが、例えば、トレンドの指標を判別するための内容を有する。
【０５２６】
基本メトリックに対して実行されうる典型的な処理は、以下のものを含む：
【０５２７】
【数９】
0005517821.tif 000036
・トレンド情報  これは対象となる区間どうしの間のトレンド、およびある区間内におけるトレンドであり得る。対象となる区間どうしの間のトレンドは、管理アプリケーション関数である。典型的には、管理局は、報告された区間の平均に傾向するであろう。１区間内のトレンドは、列挙タイプとして与えられ、その区間内の最初の値を最後のものから減算し、その符号値に基づいてトレンドを割り当てることによって容易に提供することができる。
【０５２８】
［他の実施例］
１つ又はそれ以上の以下の様々なデータ要素が、メトリックの様々な実現化において包含される。
【０５２９】
・デルタ（値の差）の総和。トレンド列挙は、この簡易な計算に基づくことが可能である。
【０５３０】
・デルタ値の絶対値の総和。これは、ある区間における全体的な動きの測定値を提供する。
【０５３１】
・正のデルタ値の総和および負のデルタ値の総和。これらの各々を関連するカウントおよび最大値を利用して展開すると、非常に有益な情報が得られる。
【０５３２】
・スキュー(skew)の統計的測定値は、Σ（Ｘ３）を既存のメトリックに加えることによって得ることが可能である。
【０５３３】
・尖度(kurtosis)の統計的測定値は、Σ（Ｘ３）およびΣ（Ｘ４）を既存のメトリックに加えることによって得ることが可能である。
【０５３４】
・データであって、そのデータを通る最小二乗線の傾斜を計算するためのデータ。
【０５３５】
［トラフィック・メトリック］
［ＣＳトラフィック］
［定義］
このメトリックは、所与のアプリケーションに関する特定のクライアント-サーバ対又は特定のサーバとそのクライアント総ての何れかに対して、測定されるトラフィック量に関する情報を含む。
【０５３６】
この情報はやや重複しており、標準規格、ＲＭＯＮＩＩ，ＡＬ／ＮＬ行列テーブルで見出され得る。これはアプリケーションに役立つようにここに包含され、ＱＯＳ分析を実行する際に、異なる関数ＲＭＯＮ領域にアクセスする必要性を回避することによって、改善された実行性の恩恵を与える。
【０５３７】
［メトリック仕様］
【０５３８】
【表２５】
0005517821.tif 000037
［ＳＣトラフィック］
［定義］
このメトリックは、所与のアプリケーションに関する特定のクライアント-サーバ対又は特定のサーバとそのクライアント総ての何れかに対して、測定されるトラフィック量に関する情報を含む。
【０５３９】
この情報はやや重複しており、標準規格、ＲＭＯＮＩＩ，ＡＬ／ＮＬ行列テーブルで見出され得る。これはアプリケーションに役立つようにここに包含され、ＱＯＳ分析を実行する際に、異なる関数ＲＭＯＮ領域にアクセスする必要性を回避することによって、改善された実行性の恩恵を与える。
【０５４０】
［メトリック仕様］
【０５４１】
【表２６】
0005517821.tif 000038
［ジッタ・メトリック］
［ＣＳジッタ］
［定義］
このメトリックは、所与のアプリケーションに関する特定のクライアント-サーバ対又は特定のサーバとそのクライアント総ての何れかに対して、データ・パケットに関して測定されるジッタ（例えば、パケット間ギャップ）に関する情報を含む。特に、ＣＳジッタは、クライアントからサーバへのデータ・メッセージに関するジッタを測定する。
【０５４２】
データ・メッセージは、クライアントからサーバへ、第１転送プロトコル・データ・パケット／ユニット（ＴＰＤＵ）を利用して始まり、他の方向の第１の後続データ・パケットによって一線を画す（すなわち終了する。）。クライアント-サーバ・パケット間ギャップは、そのメッセージ内のデータ・パケット間で測定される。本願実施例では、このメトリックの測定値内で認証が考慮されていない。
【０５４３】
再送信またはデータ・パケット不良に関する測定値も考慮されない。クライアントからサーバへのデータ・メッセージにおける最終パケットと、同一方向における次のメッセージの第１パケットとの間の間隔は、パケット間ギャップとしては解釈されない。
【０５４４】
［メトリック仕様］
【０５４５】
【表２７】
0005517821.tif 000039
［ＳＣジッタ］
［定義］
このメトリックは、所与のアプリケーションに関する特定のクライアント-サーバ対又は特定のサーバとそのクライアント総ての何れかに対して、データ・パケットに関して測定されるジッタ（例えば、パケット間ギャップ）に関する情報を含む。特に、ＳＣジッタは、クライアントからサーバへのデータ・メッセージに関するジッタを測定する。
【０５４６】
データ・メッセージは、サーバからクライアントへ、第１転送プロトコル・データ・パケット／ユニット（ＴＰＤＵ）を利用して始まり、他の方向の第１の後続データ・パケットによって一線を画す（すなわち終了する。）。サーバ-クライアント・パケット間ギャップは、そのメッセージ内のデータ・パケット間で測定される。本願実施例では、このメトリックの測定値内で認証が考慮されていない。
【０５４７】
［メトリック仕様］
【０５４８】
【表２８】
0005517821.tif 000040
［交換応答メトリック］
［ＣＳ交換応答タイム開始-開始］
［定義］
このメトリックは、所与のアプリケーションに関する特定のクライアント-サーバ対又は特定のサーバとそのクライアント総ての何れかに対して、データ・パケットに関して測定された転送段階の応答時間に関する情報を含む。具体的には、ＣＳ交換応答タイム開始-開始は、クライアントからサーバへのデータ・メッセージの開始と、サーバからクライアントへの後続応答データ・メッセージの開始との間の応答時間を測定する。
【０５４９】
クライアントからサーバへのデータ・メッセージは、クライアントからサーバへ、第１転送プロトコル・データ・パケット／ユニット（ＴＰＤＵ）を利用して始まり、他の方向の第１の後続データ・パケットによって一線を画す（すなわち終了する。）。クライアントからサーバへのデータ・メッセージの開始と、サーバからクライアントへのデータ・メッセージの開始との間の合計時間は、このメトリックを利用して測定される。このメトリックの測定値内で認証が考慮されていない点に留意を要する。
【０５５０】
また、再送信またはデータ・パケット不良に関する測定値も考慮されない。
【０５５１】
［メトリック仕様］
【０５５２】
【表２９】
0005517821.tif 000041
［ＣＳ交換応答タイム終了-開始］
［定義］
このメトリックは、所与のアプリケーションに関する特定のクライアント-サーバ対又は特定のサーバとそのクライアント総ての何れかに対して、データ・パケットに関して測定された転送段階の応答時間に関する情報を含む。具体的には、ＣＳ交換応答タイム終了-開始は、クライアントからサーバへのデータ・メッセージの終了と、サーバからクライアントへの後続応答データ・メッセージの開始との間の応答時間を測定する。
【０５５３】
クライアントからサーバへのデータ・メッセージは、クライアントからサーバへ、第１転送プロトコル・データ・パケット／ユニット（ＴＰＤＵ）を利用して始まり、他の方向の第１の後続データ・パケットによって一線を画す（すなわち終了する。）。クライアントからサーバへのデータ・メッセージの終了と、サーバからクライアントへのデータ・メッセージの開始との間の合計時間は、このメトリックを利用して測定される。このメトリックの測定値内で認証が考慮されていない点に留意を要する。
【０５５４】
また、再送信またはデータ・パケット不良に関する測定値も考慮されない。
【０５５５】
［メトリック仕様］
【０５５６】
【表３０】
0005517821.tif 000042
［ＣＳ交換応答タイム開始-終了］
［定義］
このメトリックは、所与のアプリケーションに関する特定のクライアント-サーバ対又は特定のサーバとそのクライアント総ての何れかに対して、データ・パケットに関して測定された転送段階の応答時間に関する情報を含む。具体的には、ＣＳ交換応答タイム終了-開始は、クライアントからサーバへのデータ・メッセージの開始と、サーバからクライアントへの後続応答データ・メッセージの終了との間の応答時間を測定する。
【０５５７】
クライアントからサーバへのデータ・メッセージは、クライアントからサーバへ、第１転送プロトコル・データ・パケット／ユニット（ＴＰＤＵ）を利用して始まり、他の方向の第１の後続データ・パケットによって一線を画す（すなわち終了する。）。他の方向（例えば、サーバからクライアントへ）における応答メッセージの終了は、クライアントからサーバへの次のメッセージの第１データ・パケットに先立って、メッセージの最終データによって定められる。クライアントからサーバへのデータ・メッセージの開始と、サーバからクライアントへのデータ・メッセージの終了との間の合計時間は、このメトリックを利用して測定される。このメトリックの測定値内で認証が考慮されていない点に留意を要する。
【０５５８】
また、再送信またはデータ・パケット不良に関する測定値も考慮されない。
【０５５９】
［メトリック仕様］
【０５６０】
【表３１】
0005517821.tif 000043
［ＳＣ交換応答タイム開始-開始］
［定義］
このメトリックは、所与のアプリケーションに関する特定のクライアント-サーバ対又は特定のサーバとそのクライアント総ての何れかに対して、データ・パケットに関して測定された転送段階の応答時間に関する情報を含む。具体的には、ＳＣ交換応答タイム開始-開始は、サーバからクライアントへのデータ・メッセージの開始と、クライアントからサーバへの後続応答データ・メッセージの開始との間の応答時間を測定する。
【０５６１】
サーバからクライアントへのデータ・メッセージは、サーバからクライアントへ、第１転送プロトコル・データ・パケット／ユニット（ＴＰＤＵ）を利用して始まり、他の方向の第１の後続データ・パケットによって一線を画す（すなわち終了する。）。サーバからクライアントへのデータ・メッセージの開始と、クライアントからサーバへのデータ・メッセージの開始との間の合計時間は、このメトリックを利用して測定される。このメトリックの測定値内で認証が考慮されていない点に留意を要する。
【０５６２】
また、再送信またはデータ・パケット不良に関する測定値も考慮されない。
【０５６３】
［メトリック仕様］
【０５６４】
【表３２】
0005517821.tif 000044
［ＳＣ交換応答タイム終了-開始］
［定義］
このメトリックは、所与のアプリケーションに関する特定のクライアント-サーバ対又は特定のサーバとそのクライアント総ての何れかに対して、データ・パケットに関して測定された転送段階の応答時間に関する情報を含む。具体的には、ＳＣ交換応答タイム終了-開始は、サーバからクライアントへのデータ・メッセージの終了と、クライアントからサーバへの後続応答データ・メッセージの開始との間の応答時間を測定する。
【０５６５】
サーバからクライアントへのデータ・メッセージは、サーバからクライアントへ、第１転送プロトコル・データ・パケット／ユニット（ＴＰＤＵ）を利用して始まり、他の方向の第１の後続データ・パケットによって一線を画す（すなわち終了する。）。サーバからクライアントへのデータ・メッセージの終了と、クライアントからサーバへのデータ・メッセージの開始との間の合計時間は、このメトリックを利用して測定される。このメトリックの測定値内で認証が考慮されていない点に留意を要する。
【０５６６】
また、再送信またはデータ・パケット不良に関する測定値も考慮されない。
【０５６７】
［メトリック仕様］
【０５６８】
【表３３】
0005517821.tif 000045
［ＳＣ交換応答タイム開始-終了］
［定義］
このメトリックは、所与のアプリケーションに関する特定のクライアント-サーバ対又は特定のサーバとそのクライアント総ての何れかに対して、データ・パケットに関して測定された転送段階の応答時間に関する情報を含む。具体的には、ＳＣ交換応答タイム終了-開始は、サーバからクライアントへのデータ・メッセージの開始と、サーバからクライアントへの後続応答データ・メッセージの終了との間の応答時間を測定する。
【０５６９】
サーバからクライアントへのデータ・メッセージは、サーバからクライアントへ、第１転送プロトコル・データ・パケット／ユニット（ＴＰＤＵ）を利用して始まり、他の方向の第１の後続データ・パケットによって一線を画す（すなわち終了する。）。他の方向（例えば、サーバからクライアントへ）における応答メッセージの終了は、サーバからクライアントへの次のメッセージの第１データ・パケットに先立って、メッセージの最終データによって定められる。サーバからクライアントへのデータ・メッセージの開始と、クライアントからサーバへのデータ・メッセージの終了との間の合計時間は、このメトリックを利用して測定される。このメトリックの測定値内で認証が考慮されていない点に留意を要する。
【０５７０】
また、再送信またはデータ・パケット不良に関する測定値も考慮されない。
【０５７１】
［メトリック仕様］
【０５７２】
【表３４】
0005517821.tif 000046
［処理応答メトリック］
［ＣＳ処理応答タイム開始-開始］
［定義］
このメトリックは、所与のアプリケーションに関する特定のクライアント-サーバ対又は特定のサーバとそのクライアント総ての何れかに対して、アプリケーション処理に関して測定されたアプリケーション段階の応答時間に関する情報を含む。具体的には、ＣＳ処理応答タイム開始-開始は、クライアントからサーバへのアプリケーション処理の開始と、サーバからクライアントへの後続処理応答の開始との間の応答時間を測定する。
【０５７３】
クライアントからサーバへの処理は、クライアントからサーバへ、処理要求の第１転送プロトコル・データ・パケット／ユニット（ＴＰＤＵ）を利用して始まり、処理要求に応答する第１の後続データ・パケットによって一線を画す（すなわち終了する。）。クライアントからサーバへの処理要求の開始と、サーバからクライアントへの実際の処理応答の開始との間の合計時間は、このメトリックを利用して測定される。
【０５７４】
このメトリックは、「最善の努力(best-effort)」の測定値と考えられる。このメトリックを実現するシステムは、論理的処理に関する特定のアプリケーション定義を利用して、要求および応答の開始および終了を行うために「最善の努力」をするべきである。このメトリックに関する最低レベルの支援は、このメトリックを、ＣＳ交換応答タイム開始-開始に等しくする。
【０５７５】
［メトリック仕様］
【０５７６】
【表３５】
0005517821.tif 000047
［ＣＳアプリケーション応答タイム終了-開始］
［定義］
このメトリックは、所与のアプリケーションに関する特定のクライアント-サーバ対又は特定のサーバとそのクライアント総ての何れかに対して、アプリケーション処理に関して測定されたアプリケーション段階の応答時間に関する情報を含む。具体的には、ＣＳアプリケーション応答タイム終了-開始は、クライアントからサーバへのアプリケーション処理の終了と、サーバからクライアントへの後続処理応答の開始との間の応答時間を測定する。
【０５７７】
クライアントからサーバへの処理は、クライアントからサーバへ、処理要求の第１転送プロトコル・データ・パケット／ユニット（ＴＰＤＵ）を利用して始まり、処理要求に応答する第１の後続データ・パケットによって一線を画す（すなわち終了する。）。クライアントからサーバへの処理要求の終了と、サーバからクライアントへの実際の処理応答の開始との間の合計時間は、このメトリックを利用して測定される。
【０５７８】
このメトリックは、「最善の努力(best-effort)」の測定値と考えられる。このメトリックを実現するシステムは、論理的処理に関する特定のアプリケーション定義を利用して、要求および応答の開始および終了を行うために「最善の努力」をするべきである。このメトリックに関する最低レベルの支援は、このメトリックを、ＣＳ交換応答タイム終了-開始に等しくする。
【０５７９】
［メトリック仕様］
【０５８０】
【表３６】
0005517821.tif 000048
［ＣＳアプリケーション応答タイム開始-終了］
［定義］
このメトリックは、所与のアプリケーションに関する特定のクライアント-サーバ対又は特定のサーバとそのクライアント総ての何れかに対して、アプリケーション処理に関して測定されたアプリケーション段階の応答時間に関する情報を含む。具体的には、ＣＳアプリケーション応答タイム開始-終了は、クライアントからサーバへのアプリケーション処理の開始と、サーバからクライアントへの後続処理応答の終了との間の応答時間を測定する。
【０５８１】
クライアントからサーバへの処理は、クライアントからサーバへ、処理要求の第１転送プロトコル・データ・パケット／ユニット（ＴＰＤＵ）を利用して始まり、処理要求に応答する第１の後続データ・パケットによって一線を画す（すなわち終了する。）。他の方向（例えば、サーバからクライアントへ）における処理応答の終了は、クライアントからサーバへの次の処理要求の第１データに先立って、処理応答の最終データによって定められる。クライアントからサーバへの処理要求の開始と、サーバからクライアントへの実際の処理応答の終了との間の合計時間は、このメトリックを利用して測定される。
【０５８２】
このメトリックは、「最善の努力(best-effort)」の測定値と考えられる。このメトリックを実現するシステムは、論理的処理に関する特定のアプリケーション定義を利用して、要求および応答の開始および終了を行うために「最善の努力」をするべきである。このメトリックに関する最低レベルの支援は、このメトリックを、ＣＳ交換応答タイム開始-終了に等しくする。
【０５８３】
［メトリック仕様］
【０５８４】
【表３７】
0005517821.tif 000049
［ＳＣ処理応答タイム開始-開始］
［定義］
このメトリックは、所与のアプリケーションに関する特定のクライアント-サーバ対又は特定のサーバとそのクライアント総ての何れかに対して、アプリケーション処理に関して測定されたアプリケーション段階の応答時間に関する情報を含む。具体的には、ＳＣ処理応答タイム開始-開始は、サーバからクライアントへのアプリケーション処理の開始と、クライアントからサーバへの後続処理応答の開始との間の応答時間を測定する。
【０５８５】
サーバからクライアントへの処理は、サーバからクライアントへ、処理要求の第１転送プロトコル・データ・パケット／ユニット（ＴＰＤＵ）を利用して始まり、処理要求に応答する第１の後続データ・パケットによって一線を画す（すなわち終了する。）。サーバからクライアントへの処理要求の開始と、クライアントからサーバへの実際の処理応答の開始との間の合計時間は、このメトリックを利用して測定される。
【０５８６】
このメトリックは、「最善の努力(best-effort)」の測定値と考えられる。このメトリックを実現するシステムは、論理的処理に関する特定のアプリケーション定義を利用して、要求および応答の開始および終了を行うために「最善の努力」をするべきである。このメトリックに関する最低レベルの支援は、このメトリックを、ＳＣ交換応答タイム開始-開始に等しくする。
【０５８７】
［メトリック仕様］
【０５８８】
【表３８】
0005517821.tif 000050
［ＳＣアプリケーション応答タイム終了-開始］
［定義］
このメトリックは、所与のアプリケーションに関する特定のクライアント-サーバ対又は特定のサーバとそのクライアント総ての何れかに対して、アプリケーション処理に関して測定されたアプリケーション段階の応答時間に関する情報を含む。具体的には、ＳＣアプリケーション処理応答タイム終了-開始は、サーバからクライアントへのアプリケーション処理の終了と、クライアントからサーバへの後続処理応答の開始との間の応答時間を測定する。
【０５８９】
サーバからクライアントへの処理は、サーバからクライアントへ、処理要求の第１転送プロトコル・データ・パケット／ユニット（ＴＰＤＵ）を利用して始まり、処理要求に応答する第１の後続データ・パケットによって一線を画す（すなわち終了する。）。サーバからクライアントへの処理要求の終了と、クライアントからサーバへの実際の処理応答の開始との間の合計時間は、このメトリックを利用して測定される。
【０５９０】
このメトリックは、「最善の努力(best-effort)」の測定値と考えられる。このメトリックを実現するシステムは、論理的処理に関する特定のアプリケーション定義を利用して、要求および応答の開始および終了を行うために「最善の努力」をするべきである。このメトリックに関する最低レベルの支援は、このメトリックを、ＳＣ交換応答タイム終了-開始に等しくする。
【０５９１】
［メトリック仕様］
【０５９２】
【表３９】
0005517821.tif 000051
［ＳＣアプリケーション応答タイム開始-終了］
［定義］
このメトリックは、所与のアプリケーションに関する特定のクライアント-サーバ対又は特定のサーバとそのクライアント総ての何れかに対して、アプリケーション処理に関して測定されたアプリケーション段階の応答時間に関する情報を含む。具体的には、ＳＣアプリケーション処理応答タイム開始-終了は、サーバからクライアントへのアプリケーション処理の開始と、クライアントからサーバへの後続処理応答の終了との間の応答時間を測定する。
【０５９３】
サーバからクライアントへの処理は、サーバからクライアントへ、処理要求の第１転送プロトコル・データ・パケット／ユニット（ＴＰＤＵ）を利用して始まり、処理要求に応答する第１の後続データ・パケットによって一線を画す（すなわち終了する。）。他の方向（例えば、サーバからクライアントへ）における処理応答の終了は、サーバからクライアントへの次の処理要求の第１データに先立って、処理応答の最終データによって定められる。サーバからクライアントへの処理要求の開始と、クライアントからサーバへの実際の処理応答の終了との間の合計時間は、このメトリックを利用して測定される。
【０５９４】
このメトリックは、「最善の努力(best-effort)」の測定値と考えられる。このメトリックを実現するシステムは、論理的処理に関する特定のアプリケーション定義を利用して、要求および応答の開始および終了を行うために「最善の努力」をするべきである。このメトリックに関する最低レベルの支援は、このメトリックを、ＳＣ交換応答タイム開始-終了に等しくする。
【０５９５】
［メトリック仕様］
【０５９６】
【表４０】
0005517821.tif 000052
［接続メトリック］
［接続確立］
［定義］
このメトリックは、所与のアプリケーションに関する特定のクライアント-サーバ対又は特定のサーバとそのクライアント総ての何れかに対して、転送段階の接続確立に関する情報を含む。具体的には、「接続確立」はクライアントからサーバに設定された接続数を測定する。この情報は本質的には以下のものを含む：
・良好に確立された転送接続数。
【０５９７】
・確立される接続の設定時間。
【０５９８】
・同時に接続される接続の最大数。
【０５９９】
・接続確立の失敗数（タイムアウトまたは拒否によるもの）。
【０６００】
「現在確立された転送接続の数」は、「接続自然終了」および「接続タイムアウト終了」のメトリックと共に、このメトリックから以下のようにして導出される。
【０６０１】
現在接続数：＝＝「良好に接続された数」
−「自然に終了した数」
−「タイムアウトにより終了した数」
接続の設定時間は、第１転送段階，接続確立要求（すなわち、ＳＹＮ，ＣＲ−ＴＰＤＵ等）およびその接続で交換された第１データ・パケットの間の時間差として定められる。
【０６０２】
［メトリック仕様］
【０６０３】
【表４１】
0005517821.tif 000053
［接続自然終了］
［定義］
このメトリックは、所与のアプリケーションに関する特定のクライアント-サーバ対又は特定のサーバとそのクライアント総ての何れかに対して、転送段階の接続で自然に終了したものに関する情報を含む。具体的には、「接続自然終了」は、接続数および接続時間合計の両者において自然に終了した接続を測定する。この情報は本質的には以下のものを含む：
・自然に終了した転送接続数。
【０６０４】
・自然に終了した接続の継続時間（ライフタイム）。
【０６０５】
［メトリック仕様］
【０６０６】
【表４２】
0005517821.tif 000054
［接続タイムアウト終了］
［定義］
このメトリックは、所与のアプリケーションに関する特定のクライアント-サーバ対又は特定のサーバとそのクライアント総ての何れかに対して、転送段階の接続で自然に終了してないもの（例えば、タイムアウト）に関する情報を含む。具体的には、「接続タイムアウト終了」は、接続数および接続時間合計の両者において、以前設定されたおよびタイムアウトになった接続を測定する。この情報は本質的には以下のものを含む：
・タイムアウトになった転送接続数。
【０６０７】
・タイムアウトで終了した接続の継続時間（ライフタイム）。
【０６０８】
このメトリックの継続時間の要素は、「最善の努力」の測定値と考えられる。独立したネットワーク監視装置は、ネットワークが接続タイムアウト状態を実際に検出するのがいつであるかを真に知ることはできず、したがって、接続タイムアウトが実際に生じるのがいつであるかを推察または推定する必要がある。
【０６０９】
［メトリック仕様］
【０６１０】
【表４３】
0005517821.tif 000055
［接続シーケンス・メトリック］
［ＣＳ接続再送信］
［定義］
このメトリックは、所与のアプリケーションに関する特定のクライアント-サーバ対又は特定のサーバとそのクライアント総ての何れかに対して、転送段階の接続の健全性(health)に関する情報を含む。具体的には、「ＣＳ接続再送信」は、確立される接続のライフタイムにおける実際の事象の数を測定し、その事象は、クライアントからサーバへのデータ・ベアリング(data-bearing)ＰＤＵ（パケット）転送が再送信された事象である。
【０６１１】
ネットワーク監視装置によって見られるような再送信事象は、そのネットワークで観測されるＴＰＤＵの「重複した」出現を示す。
【０６１２】
［メトリック仕様］
【０６１３】
【表４４】
0005517821.tif 000056
［ＳＣ接続再送信］
［定義］
このメトリックは、所与のアプリケーションに関する特定のクライアント-サーバ対又は特定のサーバとそのクライアント総ての何れかに対して、転送段階の接続の健全性(health)に関する情報を含む。具体的には、「ＳＣ接続再送信」は、確立される接続のライフタイムにおける実際の事象の数を測定し、その事象は、サーバからクライアントへのデータ・ベアリング(data-bearing)ＰＤＵ（パケット）転送が再送信された事象である。
【０６１４】
ネットワーク監視装置によって見られるような再送信事象は、そのネットワークで観測されるＴＰＤＵの「重複した」出現を示す。
【０６１５】
［メトリック仕様］
【０６１６】
【表４５】
0005517821.tif 000057
［ＣＳ接続不良］
［定義］
このメトリックは、所与のアプリケーションに関する特定のクライアント-サーバ対又は特定のサーバとそのクライアント総ての何れかに対して、転送段階の接続の健全性(health)に関する情報を含む。具体的には、「ＣＳ接続不良」は、確立される接続のライフタイムにおける実際の事象の数を測定し、その事象は、クライアントからサーバへのデータ・ベアリング(data-bearing)ＰＤＵ（パケット）転送が、シーケンス順序外れとして検出されたものである。
【０６１７】
再送信（又は重複）は、不良の事象とは異なるものと考えられ、ＣＳ接続再送信メトリックでは別々に追跡される。
【０６１８】
［メトリック仕様］
【０６１９】
【表４６】
0005517821.tif 000058
［ＳＣ接続不良］
［定義］
このメトリックは、所与のアプリケーションに関する特定のクライアント-サーバ対又は特定のサーバとそのクライアント総ての何れかに対して、転送段階の接続の健全性(health)に関する情報を含む。具体的には、「ＳＣ接続不良」は、確立される接続のライフタイムにおける実際の事象の数を測定し、その事象は、クライアントからサーバへのデータ・ベアリング(data-bearing)ＰＤＵ（パケット）転送が、シーケンス順序外れとして検出されたものである。
【０６２０】
再送信（又は重複）は、不良の事象とは異なるものと考えられ、ＳＣ接続再送信メトリックでは別々に追跡される。
【０６２１】
［メトリック仕様］
【０６２２】
【表４７】
0005517821.tif 000059
［接続ウインドウ・メトリック］
［ＣＳ接続ウインドウ］
［定義］
このメトリックは、所与のアプリケーションに関する特定のクライアント-サーバ対又は特定のサーバとそのクライアント総ての何れかに対して、転送段階の接続のウインドウ(window)に関する情報を含む。具体的には、「ＣＳ接続ウインドウ」は、確立された接続ライフタイムにおける転送段階の認証数、およびクライアントからサーバへのそれらの相対的な大きさを測定する。
【０６２３】
データＴＰＤＵ（パケット）の数は、そのメトリックの異なる認証数、およびクライアントからサーバへのトラフィック全体によって推定される（例えば上記のＣＳトラフィック）。接続確立および終了ＴＰＤＵに起因して、この計算において僅かな誤差が生じ得るが、致命的なものではない。
【０６２４】
［メトリック仕様］
【０６２５】
【表４８】
0005517821.tif 000060
［ＳＣ接続ウインドウ］
［定義］
このメトリックは、所与のアプリケーションに関する特定のクライアント-サーバ対又は特定のサーバとそのクライアント総ての何れかに対して、転送段階の接続のウインドウ(window)に関する情報を含む。具体的には、「ＳＣ接続ウインドウ」は、確立された接続ライフタイムにおける転送段階の認証数、およびサーバからクライアントへのそれらの相対的な大きさを測定する。
【０６２６】
データＴＰＤＵ（パケット）の数は、そのメトリックの異なる認証数、およびクライアントからサーバへのトラフィック全体によって推定される（例えば上記のＳＣトラフィック）。接続確立および終了ＴＰＤＵに起因して、この計算において僅かな誤差が生じ得るが、致命的なものではない。
【０６２７】
［メトリック仕様］
【０６２８】
【表４９】
0005517821.tif 000061
［ＣＳ接続フローズン・ウインドウ］
［定義］
このメトリックは、所与のアプリケーションに関する特定のクライアント-サーバ対又は特定のサーバとそのクライアント総ての何れかに対して、転送段階の接続のウインドウ(window)に関する情報を含む。具体的には、「ＣＳ接続ウインドウ」は、確立された接続ライフタイムにおけるクライアントからサーバへの転送段階の認証の数を測定し、そのライフタイムではデータを有効に認証するが、
・上側のウインドウ端を増加させることに失敗し、または
・上側のウインドウ端を減少させる。
【０６２９】
［メトリック仕様］
【０６３０】
【表５０】
0005517821.tif 000062
［ＳＣ接続フローズン・ウインドウ］
［定義］
このメトリックは、所与のアプリケーションに関する特定のクライアント-サーバ対又は特定のサーバとそのクライアント総ての何れかに対して、転送段階の接続のウインドウ(window)に関する情報を含む。具体的には、「ＳＣ接続ウインドウ」は、確立された接続ライフタイムにおけるサーバからクライアントへの転送段階の認証の数を測定し、そのライフタイムではデータを有効に認証するが、
・上側のウインドウ端を増加させることに失敗し、または
・上側のウインドウ端を減少させる。
【０６３１】
［メトリック仕様］
【０６３２】
【表５１】
0005517821.tif 000063
［ＣＳ接続クローズ・ウインドウ］
［定義］
このメトリックは、所与のアプリケーションに関する特定のクライアント-サーバ対又は特定のサーバとそのクライアント総ての何れかに対して、転送段階の接続のウインドウ(window)に関する情報を含む。具体的には、「ＣＳ接続ウインドウ」は、確立された接続ライフタイムにおけるクライアントからサーバへの転送段階の認証の数を測定し、そのライフタイムでは認証／シーケンス・ウインドウを完全に閉じている。
【０６３３】
［メトリック仕様］
【０６３４】
【表５２】
0005517821.tif 000064
［ＳＣ接続クローズ・ウインドウ］
［定義］
このメトリックは、所与のアプリケーションに関する特定のクライアント-サーバ対又は特定のサーバとそのクライアント総ての何れかに対して、転送段階の接続のウインドウ(window)に関する情報を含む。具体的には、「ＳＣ接続ウインドウ」は、確立された接続ライフタイムにおけるサーバからクライアントへの転送段階の認証の数を測定し、そのライフタイムでは認証／シーケンス・ウインドウを完全に閉じている。
【０６３５】
［メトリック仕様］
【０６３６】
【表５３】
0005517821.tif 000065
本願実施例は、必要な認証パターンおよび状態遷移進行手続を利用して自動的にフロー署名を生成する。それらは分解規則に従ってパケットを分析することにより生じ、また、探索するための状態遷移も引き起こす。任意の階層におけるアプリケーションおよびプロトコルは、パケットのシーケンスの状態分析を通じて認識される。
【０６３７】
当業者は、コンピュータ・ネットワークを利用して、電話，「インターネット」無線機，ページャ等のようなネットワーク機器を含む多くの異なる形式の装置を接続する。ここで使用されるコンピュータなる用語は、そのような装置の総てを包含し、ここで使用されるコンピュータ・ネットワークなる用語は、そのようなコンピュータのネットワークを含む。
【０６３８】
以上本発明は提示された好適実施例に関して説明されてきたが、本願を限定するものとして解釈されるべきではない。上記の説明を読んだ後の当業者にとって、様々な代替案および修正が疑いもなく明白である。したがって、特許請求の範囲は、本発明の精神および範囲に属する総ての代替案および修正を包含するものとして解釈されるべきである。
【０６３９】
原出願である特願２００１−５０７２１４の当初の請求項を下記に記載しておく。
［請求項１］  コンピュータ・ネットワークにおける接続点を介して通過するパケットをリアル・タイムで検査するパケット・モニタであって、前記パケットは、前記接続点に結合されたパケット捕捉装置を介して前記パケット・モニタに提供され、前記パケット・モニタは：
（ａ）  前記パケット捕捉装置からのパケットを受け入れるように形成されたパケット・バッファ・メモリ；
（ｂ）  パケット内で使用される少なくとも１つのプロトコルを前記パケット中のデータからどのように判定するかを記述する情報を含む分解／抽出作業のデータベースを格納するよう形成される分解／抽出作業メモリ；
（ｃ）  前記パケット・バッファおよび前記パケット／抽出作業メモリに結合される分解サブシステムであって、前記分解サブシステムは、前記バッファによって受け入れられた前記パケットを検査し、前記受け入れられたパケットの選択された部分を抽出し、前記受け入れられたパケットが会話フローの一部であることを識別するのに充分な前記選択された部分の関数を有するよう形成されるところの分解サブシステム；
（ｄ）  前記モニタが遭遇した会話フローに関する複数のフロー・エントリを含むフロー・エントリ・データベースを格納するメモリ；
（ｅ）  前記分解サブ・システムおよび前記フロー・エントリ・データベースに結合され、前記受け入れられたパケットの前記選択された部分の少なくとも一部を使用して、前記受け入れられたパケットの会話フロー・シーケンスに関するエントリが前記フロー・エントリ・データベース内に存在するか否かを判別するよう形成される探索エンジン；
（ｆ）  パケットの特定の会話フロー・シーケンスに起因する特定のパターン遷移の進行が、前記特定の会話フロー・シーケンスが特定のアプリケーション・プログラムの作業に関連付けられることを示し、その進行中にゼロ又はそれ以上の所定の状態作業を実行する各々の状態に遭遇するように、所定の状態遷移パターン群および状態作業を格納するよう形成された状態パターン／作業メモリ；
（ｇ）  前記状態パターン／作業メモリおよび前記探索エンジンに結合されるプロトコル／状態識別機構であって、プロトコル／状態識別エンジンは、前記パケットの前記会話フローの前記プロトコルおよび状態を判別するよう形成されるプロトコル／状態識別機構；および
（ｈ）  前記フロー・エントリ・データベース，前記プロトコル／状態識別エンジン，および前記状態パターン／作業メモリに結合される状態プロセッサであって、前記状態プロセッサは、前記パケットの前記フローの前記プロトコルおよび状態に関する前記状態パターン／作業メモリ内で特定された任意の状態作業を実行するよう形成された状態プロセッサ；
を有し、前記状態作業の実行は、前記パケットの前記会話フロー・シーケンスにどのアプリケーション・プログラムが関連するかを識別するプロセスを進め、前記状態プロセッサが前記フロー・エントリを更新する場合には前記受け入れられたパケットに対して実行する状態作業がなくなるまで、又は前記分析の結果が通知される場合には前記フローの分析がそれ以上要求されないことを示す最終状態に到達するまで、前記状態プロセッサが一連の状態または状態作業を通じて処理を行うことを特徴とするパケット・モニタ。
［請求項２］  前記フロー・エントリが前記フローの前記状態を含み、前記探索エンジンが前記受け入れられた前記フローに対するフロー・エントリを発見した場合に、前記プロトコル／状態識別機構が、前記フロー・エントリから前記パケットの前記状態を判定することを特徴とする請求項１記載のパケット・モニタ。
［請求項３］  前記分解サブシステムが前記選択された部分からハッシュを作成する機構を含み、前記ハッシュは前記フロー・エントリ・データベースを探索するために前記探索エンジンによって使用され、前記ハッシュは前記フロー・エントリ・データベース内に前記フロー・エントリが広まるように設計されることを特徴とする請求項１記載のパケット・モニタ。
［請求項４］  更に、前記分解／抽出作業メモリに結合されるコンパイラ・プロセッサを有する請求項１記載のパケット・モニタであって、前記コンパイラ・プロセッサはコンパイル・プロセスを実行するよう形成され、そのコンパイル・プロセスは：
前記モニタが遭遇するパケットで使用され得る前記プロトコルを記述する高レベル・プロトコル記述言語の命令を受信し、および
該プロトコル記述言語命令を、前記分解／抽出作業メモリ内に初期化される複数の分解／抽出作業に翻訳する
ことを特徴とする請求項１記載のパケット・モニタ。
［請求項５］  前記プロトコル記述言語命令が、１つ又はそれ以上のアプリケーションプログラム群と、アプリケーション・プログラムに関連する特定の会話フロー・シーケンスに起因して生じる前記状態遷移パターン／作業との間の対応関係を記述し、前記コンパイラ・プロセッサが前記状態パターン／作業メモリにも結合され、前記コンパイル・プロセスが、更に、前記プロトコル記述言語命令を、前記状態パターン／作業メモリ内に初期化される複数の状態パターン又は状態作業に翻訳することを特徴とする請求項４記載のパケット・モニタ。
［請求項６］  更に：
前記フロー・エントリ・データベースから、アクセスされやすいフロー・エントリ群への高速アクセスを提供するために、前記探索エンジンおよび前記フロー・エントリ・データベースにおよびそれらの間に結合されたキャッシュ・メモリを有することを特徴とする請求項１記載のパケット・モニタ。
［請求項７］  前記キャッシュが、少なくとも最近最も少なく使用したキャッシュ・メモリに関連するものとして機能することを特徴とする請求項６記載のパケット・モニタ。
［請求項８］  前記キャッシュが、少なくとも最近最も少なく使用したキャッシュ・メモリに関連するものとして機能し、スタックとして形成されたアドレス可能なメモリ内容を有することを特徴とする請求項７記載のパケット・モニタ。
［請求項９］  フローに関する１つ又はそれ以上の統計的測定値が各フロー・エントリに含まれ、前記パケット・モニタが、更に：
前記受け入れられたフロー・エントリ内の前記統計的測定値を更新する計算機を有することを特徴とする請求項１記載のパケット・モニタ。
［請求項１０］  フローの前記アプリケーション・プログラムが決定される場合に、前記アプリケーションおよび前記統計的測定値から決定されたものに関連する１つ又はそれ以上のネットワーク利用メトリックが、ネットワーク・パフォーマンスを監視するユーザに提供されることを特徴とする請求項９記載のパケット・モニタ。
［請求項１１］  コンピュータ・ネットワーク上の接続点を介して通過するパケットを検査する方法であって、各パケットは１つ又はそれ以上のプロトコルに従うものであり、当該方法は：
（ａ）  パケット捕捉装置からパケットを受信する段階；
（ｂ）  前記パケットに関して１つ又はそれ以上の分解／抽出作業を実行し、前記パケットの選択された部分の関数より成る分解レコードを作成する段階；
（ｃ）  以前に遭遇した会話フローに関するゼロ又はそれ以上のフロー・エントリより成るフロー・エントリ・データベースを探索する段階であって、該探索は、前記選択されたパケット部分の少なくとも一部を利用し、前記パケットが既存のフローのものであるか否かを判定するところの段階；
（ｄ）  前記パケットが既存のフローのものである場合は、前記パケットを発見された既存のフローに属するものとして分類する段階；および
（ｅ）  前記パケットが新たなフローのものである場合は、新規フロー・エントリを利用して識別される将来のパケットに関する識別情報を含む前記フロー・エントリ・データベース内に、前記新たなフローのための新規フロー・エントリを格納する段階；
より成り、前記分解／抽出作業が、前記パケットが従う１つ又はそれ以上のプロトコルに依存することを特徴とする方法。
［請求項１２］  前記接続点を介して通過する各パケットが、リアル・タイムで検査されることを特徴とする請求項１１記載の方法。
［請求項１３］  前記パケットを発見された既存のフローに属するものとして分類する段階が、既存のフロー・エントリのフロー・エントリを更新する段階より成ることを特徴とする請求項１１記載の方法。
［請求項１４］  前記の更新が、既存のフロー・エントリのフロー・エントリに含まれた１つまたはそれ以上の統計的測定値を格納することを特徴とする請求項１３記載の方法。
［請求項１５］  前記１つまたはそれ以上の統計的測定値が、前記フローに関する全パケット数，時間，および最終に入力された時点から現時点までの時間差より成る群から選択された測定値を含むことを特徴とする請求項１４記載の方法。
［請求項１６］  前記パケットの選択された部分の前記関数が、前記選択された部分を含み将来のパケットを識別し得るところの署名を作成し、前記探索作業は前記署名を使用し、前記新規のまたは更新されたフロー・エントリに含まれる識別情報が、将来のパケットを識別するための署名であることを特徴とする請求項１１記載の方法。
［請求項１７］  前記パケットの前記プロトコルの少なくとも１つがソースおよびあて先アドレスを使用し、前記パケットの前記選択された部分が前記ソースおよびあて先アドレスを含むことを特徴とする請求項１１記載の方法。
［請求項１８］  同一フローのパケットに関する前記選択された部分の前記関数が、前記パケットの方向とは独立したものであることを特徴とする請求項１７記載の方法。
［請求項１９］  前記ソースおよびあて先アドレスが、選択された部分の前記関数において前記アドレスの数値的な値の順序によって決定される順序で並べられることを特徴とする請求項１８記載の方法。
［請求項２０］  選択された部分の前記関数において、数値的に低いアドレスが数値的に高いアドレスの前に並べられることを特徴とする請求項１９記載の方法。
［請求項２１］  前記フロー・エントリ・データベースの探索が、選択されたパケット部分のハッシュを利用することを特徴とする請求項１１記載の方法。
［請求項２２］  前記分解／抽出作業が、分解／抽出作業のデータベースによるものであり、前記データベースは、前記パケットで使用されたプロトコルを示す前記パケット内のデータからの抽出作業に依存して、１つ又はそれ以上のプロトコル群をどのように判定するかを示す情報を含むことを特徴とする請求項１１記載の方法。
［請求項２３］  段階（ｄ）が、前記パケットが既存のフローのものである場合に、前記フローの最後に遭遇した状態を求め、前記フローの最後に遭遇した状態から始まる前記フローの前記状態に関して特定された状態作業を実行し；および前記段階（ｅ）が、前記パケットが新たなフローのものである場合は、前記新たなフローの初期状態に関して要求される状態作業を実行することを特徴とする請求項１１記載の方法。
［請求項２４］  フローに関して各々受信したパケットの状態処理が、前記フローの前記アプリケーション・プログラムの識別を進行させることを特徴とする請求項２３記載の方法。
［請求項２５］  前記状態作業が、前記フロー・エントリを更新することを含み、前記フロー・エントリを利用して識別される将来のパケットに関する識別情報を格納することを含むことを特徴とする請求項２３記載の方法。
［請求項２６］  フローに関して各々受信したパケットの状態処理が、前記フローの前記アプリケーション・プログラムの識別を進行させることを特徴とする請求項２５記載の方法。
［請求項２７］  前記状態作業が、１つ又はそれ以上の参照ストリングの存在に関する前記分解レコードを探索することを特徴とする請求項２５記載の方法。
［請求項２８］  状態作業に依存してプロトコルのデータベースを利用してプログラム可能な状態プロセッサによって、前記状態作業が実行されることを特徴とする請求項２５記載の方法。
［請求項２９］  コンピュータ・ネットワーク上の接続点を介して通過するパケットを検査するパケット・モニタであって、各パケットは１つ又はそれ以上のプロトコルに従い、当該パケット・モニタは：
（ａ）  前記接続点に結合され、前記接続点を介して通過するパケットを受信するよう形成されたパケット捕捉装置；
（ｂ）  前記パケット捕捉装置からのパケットを受け入れるように結合および形成された入力バッファ・メモリ；
（ｃ）  前記入力バッファ・メモリに結合されおよびスライサを有する分解サブシステムであって、前記分解サブシステムは、前記受け入れられたパケットの選択された部分を抽出し、前記選択された部分を含む分解レコードを出力するよう形成される分解サブシステム；
（ｄ）  以前遭遇した会話フローに関するゼロまたはそれ以上のフロー・エントリを含むデータベースを格納するメモリ；
（ｅ）  前記分解サブシステムの出力およびフロー・エントリ・メモリに結合され、特定のパケットの分解レコードが前記分解サブシステムにより出力されるところの特定のパケットがフロー・エントリに一致するか否かを探索するように形成される探索エンジンであって、前記の探索は、選択されたパケット部分を利用して、前記パケットが既存のフローのものであるか否かを判定するところの探索エンジン；および
（ｆ）  前記フロー・エントリ・メモリおよび前記探索エンジンに結合され、前記フロー・エントリ・データベース内でフロー・エントリを作成するよう形成されるフロー挿入エンジンであって、前記フロー・エントリが、新規フロー・エントリを利用して識別される将来のパケットに関する識別情報を含むフロー挿入エンジン；
を有し、前記探索エンジンが、前記パケットが既存のフローのものである場合は、前記パケットを発見された既存のフローに属するものとして分類し、前記パケットが新たなフローのものである場合は、前記フロー挿入エンジンが、前記新規フロー・エントリを利用して識別される将来のパケットに関する識別情報を含む前記フロー・エントリ・データベース内に前記新たなフローのための新規フロー・エントリを格納し、
前記分解サブシステムの動作は、前記パケットが従う１つ又はそれ以上のプロトコルに依存することを特徴とするパケット・モニタ。
［請求項３０］  接続点を介して通過する各パケットが、前記パケット・バッファによってアクセスされ、前記モニタによってリアル・タイムで検査されることを特徴とする請求項２９記載のモニタ。
［請求項３１］  前記探索エンジンが、前記の探索が成功した場合に既存のフローの前記フロー・エントリを更新することを特徴とする請求項２９記載のモニタ。
［請求項３２］  更に、前記選択された部分からハッシュを作成する機構を含み、前記ハッシュは前記探索エンジンに対する特定のパケットの前記入力に含まれ、前記ハッシュは前記フロー・データベースを探索するために前記探索エンジンによって使用されることを特徴とする請求項２９記載のモニタ。
［請求項３３］  更に、分解／抽出作業のデータベースを含むメモリを有し、分解／抽出作業データベースは前記分解サブシステムに結合され、前記分解／抽出作業は、前記分解／抽出作業データベースから探索された１つ又はそれ以上の分解／抽出作業によるものであることを特徴とする請求項２９記載のモニタ。
［請求項３４］  分解／抽出作業の前記データベースが、前記パケットで使用されるプロトコルを指示するパケット内のデータからの抽出作業に依存して、１つ又はそれ以上のプロトコル群をどのように判定するかを記述する情報を含むことを特徴とする請求項３３記載のモニタ。
［請求項３５］  更に、前記分解サブシステムの前記出力ならびに前記探索エンジンおよび前記フロー挿入エンジンに結合されるフロー・キー・バッファ（ＵＦＫＢ）を含み、分解モニタの出力は前記ＵＦＫＢを通じて前記探索エンジンに結合され、前記フロー挿入エンジンが前記ＵＦＫＢを通じて前記探索エンジンに結合されることを特徴とする請求項２９記載のモニタ。
［請求項３６］  更に、前記探索エンジンおよび前記フロー・エントリ・データベース・メモリに結合され、前記パケットが既存のパケットからのものである場合に、前記フローの最後に遭遇した状態から始まるフローの状態に関して特定される状態作業を実行し、前記パケットが既存のパケットからのものである場合に、新たなフローの初期状態に要求される状態作業を実行するよう形成される状態プロセッサを有することを特徴とする請求項２９記載のモニタ。
［請求項３７］  前記状態プロセッサが実行するよう形成されるところの１組の可能な状態作業が、パケット部分内の１つ又はそれ以上のパターンを探索することを含むことを特徴とする請求項２９記載のモニタ。
［請求項３８］  前記状態プロセッサがプログラム可能であり、前記モニタが前記状態プロセッサに結合された状態パターン／作業メモリを更に含み、前記状態メモリは、状態パターン／作業に依存してプロトコルのデータベースを格納するよう形成されることを特徴とする請求項３６記載のモニタ。
［請求項３９］  前記ＵＦＫＢおよび前記フロー・エントリ・データベース・メモリに結合され、前記パケットが既存のパケットからのものである場合に、前記フローの最後に遭遇した状態から始まるフローの状態に関して特定される状態作業を実行し、前記パケットが既存のパケットからのものである場合に、新たなフローの初期状態に要求される状態作業を実行するよう形成される状態プロセッサを有することを特徴とする請求項３５記載のモニタ。
［請求項４０］  前記状態作業が、前記フロー・エントリを更新することを含み、前記フロー・エントリを利用して識別される将来のパケットに関する識別情報を格納することを含むことを特徴とする請求項３６記載のモニタ。
［請求項４１］  更に、前記分解／抽出作業メモリに結合されるコンパイラ・プロセッサを有し、前記コンパイラ・プロセッサはコンパイル・プロセスを実行するよう形成され、そのコンパイル・プロセスは：
前記モニタが遭遇するパケットで使用され得る前記プロトコルおよびその任意の子プロトコルを記述する高レベル・プロトコル記述言語の命令を受信し、および
該プロトコル記述言語命令を、前記分解／抽出作業メモリ内に初期化される複数の分解／抽出作業に翻訳する
ことを特徴とする請求項２９記載のパケット・モニタ。
［請求項４２］  更に、前記分解／抽出作業メモリに結合されるコンパイラ・プロセッサを有し、前記コンパイラ・プロセッサはコンパイル・プロセスを実行するよう形成され、そのコンパイル・プロセスは：
１つ又はそれ以上のアプリケーションプログラム群と、アプリケーション・プログラムに関連する特定の会話フロー・シーケンスに起因して生じる前記状態遷移パターン／作業との間の対応関係を記述する高レベル・プロトコル記述言語の命令を受信し、および
該プロトコル記述言語命令を、前記分解／抽出作業メモリ内に初期化される複数の状態パターンおよび状態作業に翻訳する
ことを特徴とする請求項３８記載のパケット・モニタ。
［請求項４３］  前記フロー・エントリ・データベースから、アクセスされやすいフロー・エントリ群への高速アクセスを提供するために、前記探索エンジンおよび前記フロー・エントリ・データベース・メモリにおよびそれらの間に結合されたキャッシュサブシステムを有することを特徴とする請求項２９記載のパケット・モニタ。
［請求項４４］  前記キャッシュ・サブシステムが、１つ又はそれ以上のアドレス可能なメモリ・セル（ＣＡＭ）の内容を示す連合キャッシュ・サブシステムであることを特徴とする請求項４３記載のパケット・モニタ。
［請求項４５］  前記キャッシュ・サブシステムが、最少使用キャッシュ・メモリであり、キャッシュが、最近最も少なく使用されたキャッシュ・エントリを更新する機会を失うことを特徴とする請求項４４記載のパケット・モニタ。
［請求項４６］  各フロー・エントリが前記フローに関する１つ又はそれ以上の統計的測定値含み、前記モニタが、更に、前記受け入れられたパケットの前記フロー・エントリにおける少なくとも１つの統計定期測定値を更新する計算機を有することを特徴とする請求項２９記載のパケット・モニタ。
［請求項４７］  前記１つまたはそれ以上の統計的測定値が、前記フローに関する全パケット数，時間，および最後に入力された時点から現時点までの時間差より成る群から選択された測定値を含むことを特徴とする請求項４６記載のパケット・モニタ。
［請求項４８］  前記フローのフロー・エントリにおける１つ又はそれ以上の前記統計的測定値から、前記フローに関する１つ又はそれ以上のネットワーク利用メトリックを判定するよう形成された統計プロセッサを更に有することを特徴とする請求項４６記載のパケット・モニタ。
［請求項４９］  フロー・エントリ・データベースが複数のビンに組織化され、各々がＮ個のフロー・エントリを有し、前記ビンは、前記選択されたパケット部分に基づいて分解サブシステムによって作成されたハッシュ・データ値を介してアクセスされ、Ｎが１つ又はそれ以上であることを特徴とする請求項２９記載のモニタ。
［請求項５０］  前記ハッシュ・データ値は、複数のフロー・エントリを前記フロー・エントリ・データベース内に広めるために使用され、フロー・エントリの高速探索および浅いバケットことを可能にすることを特徴とする請求項４９記載のモニタ。
［請求項５１］  前記状態プロセッサが新しいおよび既存のフローの両者を分析し、それらをアプリケーションにより分類し、１組の所定の規則に基づいて状態ごとに進行することを特徴とする請求項３６記載のモニタ。
［請求項５２］  前記探索エンジンが、前記分解サブシステムから分解レコードが到着すると直ちに処理を開始することを特徴とする請求項２９記載のモニタ。
［請求項５３］  前記探索エンジンが、フロー・キーが前記状態プロセッサに送られるべきか否かを検査するフロー状態エントリを提供し、前記フローに対してプロトコル識別子を出力することを特徴とする請求項３６記載のモニタ。
［請求項５４］  コンピュータ・ネットワーク上の接続点を介して通過するパケットを検査する方法であって、当該方法は：
（ａ）  パケット捕捉装置からパケットを受信する段階；
（ｂ）  分解／抽出作業のデータベースに従って、前記パケットに関して１つ又はそれ以上の分解／抽出作業を実行し、前記パケットの選択された部分の関数より成る分解レコードを作成する段階であって、分解／抽出作業のデータベースは、前記パケットで使用されるプロトコルを示すパケット内のデータからの抽出作業に依存して、１つ又はそれ以上のプロトコルをどのように判定するかについての情報を含むところの段階；
（ｃ）  以前に遭遇した会話フローに関するゼロ又はそれ以上のフロー・エントリより成るフロー・エントリ・データベースを探索する段階であって、該探索は、前記選択されたパケット部分の少なくとも一部を利用し、前記パケットが既存のフローのものであるか否かを判定するところの段階；
（ｄ）  前記パケットが既存のフローのものである場合に、前記フローの最後に遭遇した状態を求め、前記フローの最後に遭遇した状態から始まる前記フローの前記状態に関して特定された状態作業を実行し；および
（ｅ）  前記パケットが新たなフローのものである場合は、前記新たなフローの初期状態に関して要求される状態作業を実行し、新規フロー・エントリを利用して識別される将来のパケットに関する識別情報を含む前記フロー・エントリ・データベース内に、前記新たなフローのための新規フロー・エントリを格納する段階；
より成ることを特徴とする方法。
［請求項５５］  前記状態の少なくとも１つに関して特定された状態作業の１つが、前記フロー・エントリを更新することを含み、前記フロー・エントリを利用して識別される将来のパケットに関する情報を識別することを含むことを特徴とする請求項５４記載の方法。
［請求項５６］  前記状態の少なくとも１つに関して特定された状態作業の１つが、少なくとも１つの参照ストリングに関して前記パケットの内容を探索することを特徴とする請求項５４記載の方法。
［請求項５７］  前記状態の少なくとも１つに関して特定された状態作業の１つが、前記フローに関して識別される将来のパケットに関する新規フロー・エントリを作成することを含み、前記新規フロー・エントリが、前記フローに関して識別される将来のパケットに関する識別情報を含むことを特徴とする請求項５５記載の方法。
［請求項５８］  更に、前記選択されたパケット部分から署名を形成する段階より成り、前記探索作業は前記署名を使用し、前記新規のまたは更新されたフロー・エントリに含まれる識別情報が、将来のパケットを識別するための署名であることを特徴とする請求項５４記載の方法。
［請求項５９］  前記状態作業が、状態作業に依存するプロトコルのデータベースによるものであることを特徴とする請求項５４記載の方法。
［請求項６０］  コンピュータ・ネットワーク上の接続点を介して通過するパケットに関するプロトコル特有作業を実行する方法であって、当該方法は：
（ａ）  前記パケットを受信する段階；
（ｂ）  階層モデルに従う複数のプロトコルに関する１組のプロトコル記述を受信する段階であって、特定の階層レベルにおける特定のプロトコルに関するプロトコル記述は：
（ｉ）  前記特定のプロトコルのゼロ又はそれ以上の子プロトコルであって、前記パケットは、前記特定のプロトコルの特定の子プロトコルに対して、前記特定の子プロトコルに関連する前記パケットにおける１つ又はそれ以上の場所における情報を含むところの子プロトコル，
（ｉｉ）  前記特定のプロトコルの子プロトコルに関連する情報が格納される前記パケット内の１つ又はそれ以上の場所，および
（ｉｉｉ）  前記特定の階層レベルにおける特定のプロトコルに関して、前記パケットに対して実行されるゼロ又はそれ以上のプロトコル特有作業
を有するところの段階；および
（ｃ）  前記パケットの基本プロトコルおよび前記パケットで使用される前記プロトコルの子に基づく前記１組のプロトコル記述によって特定される前記パケットに対して前記プロトコル特有作業を実行する段階；
より成ることを特徴とする方法。
［請求項６１］  プロトコル特有作業を実行する段階（ｃ）が、前記子の任意の子に関して繰り返し行われることを特徴とする請求項６０記載の方法。
［請求項６２］  当該方法がパケットの内容に従って様々なプロトコルに適合するように、段階（ｃ）で実行されるプロトコル特有作業が前記パケットの内容に依存することを特徴とする請求項６０記載の方法。
［請求項６３］  更に：
メモリ内にデータベースを格納する段階より成り、前記データベースは、前記１組のプロトコル記述から生成され、可能なプロトコルに関する情報を含むデータ構造を有し、任意のプロトコルに対して子プロトコル関連情報を探索するように組織化され、前記データ構造の内容は１つ又はそれ以上の１組の指標によって指示され、前記データベース・エントリは有効性の指示を含む指標値の特定の組によって指示され、
前記子プロトコル関連情報は子認識パターンを含み、
前記プロトコル特有作業を実行する段階（ｃ）が、ベース階層から始まる特定のプロトコル階層レベルにおいて、前記子フィールドに関する前記特定のプロトコルにおける前記パケットを探索し、該探索は、有効なエントリが見出されるまで前記データ構造を指示することを含み、および
これにより前記データ構造が、前記指標の組を利用して高速探索されるように形成されることを特徴とする請求項６０記載の方法。
［請求項６４］  前記プロトコル記述が、プロトコル記述言語で提供され、前記方法が更に：
前記データベースを作成するためにＰＤＬ記述をコンパイルする段階；
より成ることを特徴とする請求項６３記載の方法。
［請求項６５］  前記データ構造が１組のアレイより成り、各アレイは、各プロトコルに対して少なくとも１つのアレイの第１指標によって識別され、各アレイは更に、子プロトコル関連情報が格納される前記パケット内の場所である第２指標によって指示され、前記データ構造における有効なエントリの探索が、前記パケット内の前記場所を提供し、識別されたプロトコルに関する子認識パターンを見出すことを特徴とする請求項６３記載の方法。
［請求項６６］  各アレイが更に、子プロトコル関連情報が格納される前記パケット内の領域の大きさである第３指標によって指示され、前記データ構造における有効なエントリの探索が、前記パケットにおける前記場所および前記領域の大きさを提供し、前記子認識パターンを見出すことを特徴とする請求項６５記載の方法。
［請求項６７］  前記データ構造における有効エントリの散在性を利用した圧縮手法に従って前記データ構造が圧縮されることを特徴とする請求項６６記載の方法。
［請求項６８］  前記圧縮手法が、競合する共通エントリを有しない２つ又はそれ以上のアレイを結合させることを特徴とする請求項６７記載の方法。
［請求項６９］  前記データ構造が１組のテーブルを有し、各テーブルは、各プロトコルに対して少なくとも１つのテーブルの第１指標によって識別され、各テーブルは更に、前記子認識パターンである第２指標によって指示され、前記データ構造は更に、各プロトコルに対して、子プロトコル関連情報が格納される前記パケット内の場所を提供するテーブルを含み、前記データ構造における有効なエントリの探索が、前記パケット内の前記場所を提供し、識別されたプロトコルに関する子認識パターンを見出すことを特徴とする請求項６３記載の方法。
［請求項７０］  テーブルの前記組における有効エントリの散在性を利用した圧縮手法に従って前記データ構造が圧縮されることを特徴とする請求項６９記載の方法。
［請求項７１］  前記圧縮手法が、競合する共通エントリを有しない２つ又はそれ以上のテーブルを結合させることを特徴とする請求項７０記載の方法。
［請求項７２］  前記プロトコル特有作業が、前記パケットに関する１つ又はそれ以上の分解および抽出作業を含み、前記パケットの選択された部分を抽出し、会話フローに属するものとして前記パケットを識別するために前記選択された部分の関数を形成することを特徴とする請求項６０記載の方法。
［請求項７３］  前記プロトコル記述が、プロトコル記述言語で提供されることを特徴とする請求項６０記載の方法。
［請求項７４］  更に：
データベースを作成し、前記データベースをメモリ内に格納するためにＰＤＬ記述をコンパイルする段階より成り、前記データベースは、前記１組のプロトコル記述から生成され、可能なプロトコルに関する情報を含むデータ構造を有し、任意のプロトコルに対して子プロトコル関連情報を探索するように組織化され、前記データ構造の内容は１つ又はそれ以上の１組の指標によって指示され、前記データベース・エントリは有効性の指示を含む指標値の特定の組によって指示され、
前記子プロトコル関連情報は子認識パターンを含み、
前記プロトコル特有作業を実行する段階が、ベース階層から始まる特定のプロトコル階層レベルにおいて、前記子フィールドに関する前記特定のプロトコルにおける前記パケットを探索し、該探索は、有効なエントリが見出されるまで前記データ構造を指示することを含み、および
これにより前記データ構造が、前記指標の組を利用して高速探索されるように形成されることを特徴とする請求項７３記載の方法。
［請求項７５］  更に：
以前に遭遇した会話フローに関するゼロ又はそれ以上のフロー・エントリより成るフロー・エントリ・データベースを探索する段階であって、該探索は、前記選択されたパケット部分の少なくとも一部を利用し、前記パケットが既存のフローのものであるか否かを判定するところの段階；
前記パケットが既存のフローのものである場合は、前記パケットを発見された既存のフローに属するものとして分類する段階；および
前記パケットが新たなフローのものである場合は、新規フロー・エントリを利用して識別される将来のパケットに関する識別情報を含む前記フロー・エントリ・データベース内に、前記新たなフローのための新規フロー・エントリを格納する段階；
より成り、前記分解および抽出作業が、ゼロ又はそれ以上のパケット・ヘッダに依存することを特徴とする請求項７２記載の方法。
［請求項７６］  前記プロトコル特有作業が、更に、前記パケットの前記フローの前記状態の関数である１つ又はそれ以上の状態処理作業を含むことを特徴とする請求項７２記載の方法。
［請求項７７］  前記プロトコル特有作業が、前記パケットの前記フローの前記状態の関数である１つ又はそれ以上の状態処理作業を含むことを特徴とする請求項６０記載の方法。
［請求項７８］  コンピュータ・ネットワーク上の接続点を介して通過するパケットのフローを分析する方法であって、当該方法は：
（ａ）  パケット捕捉装置からパケットを受信する段階；
（ｂ）  以前に遭遇した会話フローに関するゼロ又はそれ以上のフロー・エントリより成るフロー・エントリ・データベースを探索する段階であって、該探索は、受信したパケットが既存のフローのものであるか否かを判定するところの段階；
（ｄ）  前記パケットが既存のフローのものである場合は、前記フロー・エントリに維持される１つ又はそれ以上の統計的測定値を格納することを含めて、前記既存のフローの前記フロー・エントリを更新する段階；および
（ｅ）  前記パケットが新たなフローのものである場合は、前記フロー・エントリに維持される１つ又はそれ以上の統計的測定値を格納する前記フロー・エントリ・データベース内に、前記新たなフローのための新規フロー・エントリを格納する段階；
より成り、前記接続点を介して通過する全パケットが前記パケット捕捉装置によって受信されることを特徴とする方法。
［請求項７９］  更に：
前記パケットから識別部分を抽出する段階より成り、
前記探索が、前記識別部分の関数を利用することを特徴とする請求項７８記載の方法。
［請求項８０］  各段階が、前記接続点を介して通過する各パケットに対して、リアル・タイムで実行されることを特徴とする請求項７８記載の方法。
［請求項８１］  前記１つまたはそれ以上の統計的測定値が、前記フローに関する全パケット数，時間，および最後に入力された時点から現時点までの時間差より成る群から選択された測定値を含むことを特徴とする請求項７８記載の方法。
［請求項８２］  更に、前記フロー・エントリの１つ又はそれ以上の前記統計的測定値から、フロー・エントリの前記フローに関連する１つ又はそれ以上のメトリックを報告する段階より成ることを特徴とする請求項７８記載の方法。
［請求項８３］  前記メトリックが１つ又はそれ以上のサービス品質（ＱＯＳ）メトリックを含むことを特徴とする請求項８４記載の方法。
［請求項８４］  前記の報告が時々行われ、前記１つ又はそれ以上のメトリックが、最終報告時点からの時間間隔に関連する基本メトリックであることを特徴とする請求項８２記載の方法。
［請求項８５］  更に、前記基本メトリックから１つ又はそれ以上のサービス品質（ＱＯＳ）メトリックを計算する段階より成ることを特徴とする請求項８４記載の方法。
［請求項８６］  隣接する時間間隔に関するメトリックが結合され、結合された間隔に対するメトリックを判定し得るように、前記１つ又はそれ以上のメトリックが尺度変更可能であるように選択されることを特徴とする請求項８４記載の方法。
［請求項８７］  段階（ｄ）が、前記パケットが既存のフローのものである場合に、前記フローの最後に遭遇した状態を求め、前記フローの最後に遭遇した状態から始まる前記フローの前記状態に関して特定された状態作業を実行し；および前記段階（ｅ）が、前記パケットが新たなフローのものである場合は、前記新たなフローの初期状態に関して要求される状態作業を実行することを特徴とする請求項７８記載の方法。
［請求項８８］  更に、前記フロー・エントリの１つ又はそれ以上の前記統計的測定値から、フロー・エントリの前記フローに関連する１つ又はそれ以上のメトリックを報告する段階より成ることを特徴とする請求項８７記載の方法。
［請求項８９］  前記の報告が時々行われ、前記１つ又はそれ以上のメトリックが、最終報告時点からの時間間隔に関連する基本メトリックであることを特徴とする請求項８８記載の方法。
［請求項９０］  前記の報告が、前記フローの前記状態に関する前記状態作業の一部であることを特徴とする請求項８９記載の方法。
［請求項９１］  前記状態作業が、前記フロー・エントリを更新することを含み、前記フロー・エントリを利用して識別される将来のパケットに関する識別情報を格納することを特徴とする請求項８７記載の方法。
［請求項９２］  更に、更なるパケットを受信する段階より成り、フローに関する各受信したパケットの状態処理が、前記フローの前記アプリケーション・プログラムの識別を進行させることを特徴とする請求項９１記載の方法。
［請求項９３］  前記フローの状態に関連する１つ又はそれ以上のメトリックが、前記フローの状態に関して特定された状態作業の一部として判定されることを特徴とする請求項９２記載の方法。
［請求項９４］  コンピュータ・ネットワーク上の接続点を介して通過するパケットを検査するパケット・モニタであって、各パケットは１つ又はそれ以上のプロトコルに従い、当該パケット・モニタは：
（ａ）  前記接続点に結合され、前記接続点を介して通過するパケットを受信するように結合されるパケット捕捉装置；
（ｂ）  受信したパケットが所属する以前遭遇した会話フローに関する１つ又はそれ以上のフロー・エントリより成るデータベースを格納するメモリ；
（ｃ）  前記パケット捕捉装置に結合され、受信したパケットが前記フロー・エントリ・データベース内のフロー・エントリに属するか否かを探索し、前記パケットが既存のフローのものである場合は、前記フロー・エントリに維持される１つ又はそれ以上の統計的測定値を格納することを含めて、前記既存のフローの前記フロー・エントリを更新し、および前記パケットが新たなフローのものである場合は、前記フロー・エントリに維持される１つ又はそれ以上の統計的測定値を格納する前記フロー・エントリ・データベース内に、前記新たなフローのための新規フロー・エントリを格納するように形成される分析サブシステム；
を有することを特徴とするパケット・モニタ。
［請求項９５］  更に：
パケット捕捉装置および分析サブシステムに結合され、受信したパケットから識別情報を抽出するよう形成される分解サブシステム；
を有し、各フロー・エントリは前記フロー・エントリに含まれる識別情報によって識別され、キャッシュの探索は、抽出した識別情報の関数を使用することを特徴とする請求項９４記載のパケット・モニタ。
［請求項９６］  前記１つまたはそれ以上の統計的測定値が、前記フローに関する全パケット数，時間，および最後に入力された時点から現時点までの時間差より成る群から選択された測定値を含むことを特徴とする請求項９６記載のパケット・モニタ。
［請求項９７］  前記フローのフロー・エントリにおける１つ又はそれ以上の前記統計的測定値から、前記フローに関する１つ又はそれ以上のメトリックを判定するよう形成された統計プロセッサを更に有することを特徴とする請求項９４記載のパケット・モニタ。
［請求項９８］  前記統計プロセッサが、前記１つ又はそれ以上のメトリックを時々判定および報告することを特徴とする請求項９７記載のパケット・モニタ。
［請求項９９］  コンピュータ・ネットワーク上の接続点を介して通過するパケットを検査するパケット・モニタであって、各パケットは１つ又はそれ以上のプロトコルに従い、当該パケット・モニタは：
（ａ）  前記接続点に結合され、前記接続点を介して通過するパケットを受信するよう形成されるパケット捕捉装置；
（ｂ）  受信したパケットが所属する以前遭遇した会話フローに関する１つ又はそれ以上のフロー・エントリより成るデータベースを格納するメモリ；
（ｃ）  前記フロー・エントリ・データベース・メモリに結合され、前記フロー・エントリ・データベースから、フロー・エントリの高速アクセスを提供するキャッシュ・サブシステム；および
（ｄ）  前記パケット捕捉装置および前記キャッシュ・サブシステムに結合され、受信したパケットが前記フロー・エントリ・データベース内のフロー・エントリに属するか否かを探索するよう形成され、前記の探索は前記キャッシュ・サブシステム内で行われるところの探索エンジン；
を有することを特徴とするパケット・モニタ。
［請求項１００］  更に：
パケット捕捉装置および探索エンジンに結合される分解サブシステムであって、前記捕捉装置が前記分解サブシステムを介して前記探索エンジンに結合され、前記分解サブシステムは受信したパケットから識別情報を抽出するよう形成される分解サブシステム；
を有し、各フロー・エントリは前記フロー・エントリに含まれる識別情報によって識別され、キャッシュの探索は、抽出した識別情報の関数を使用することを特徴とする請求項９９記載のパケット・モニタ。
［請求項１０１］  前記キャッシュ・サブシステムが、１つ又はそれ以上の内容アドレス可能なメモリ・セル（ＣＡＭ）を含む連合キャッシュ・メモリであることを特徴とする請求項１００記載のパケット・モニタ。
［請求項１０２］  前記キャッシュ・サブシステムが：
（ｉ）  前記フロー・エントリ・データベース・メモリに結合された１組のキャッシュ・メモリ要素であって、各キャッシュ・メモリ要素はフロー・エントリを入力するための入力ポートを含み、前記フロー・エントリ・データベースのフロー・エントリを格納するよう形成される１組のキャッシュ・メモリ要素；
（ｉｉ）  上部ＣＡＭから下部ＣＡＭへの接続の順序に従って接続された１組の内容アドレス可能なメモリ・セル（ＣＡＭ）であって、各ＣＡＭが、前記キャッシュ・メモリ要素の１つに対するアドレスおよびポインタを含み、および各ＣＡＭが：
入力を有する一致回路であって、前記入力がＣＡＭセル内のアドレスと同一である場合にＣＡＭが一致出力をアサートし、アサートされた一致出力はヒットを示すところの一致回路，
アドレスおよびポインタを受け入れるように形成されたＣＡＭ入力，および
ＣＡＭアドレス出力およびＣＡＭポインタ出力
を含むところの１組の内容アドレス可能なメモリ・セル；
（ｉｉｉ）  前記ＣＡＭの組に結合されるＣＡＭコントローラ；および
（ｉｖ）  前記ＣＡＭコントローラ，前記キャッシュ・メモリの組および前記フロー・エントリ・メモリに結合されたメモリ・コントローラ
を含み、前記ＣＡＭセルの一致回路入力が前記探索エンジンに結合され、前記一致回路入力への入力が、前記入力に等しいアドレスを含む任意のＣＡＭセルにおいて一致出力を生じさせ、および
前記ＣＡＭコントローラが、特定のＣＡＭが指示するキャッシュ・メモリ要素が時間と共に変化するように形成されることを特徴とする請求項１００記載のパケット・モニタ。
［請求項１０３］  前記下部ＣＡＭが最近最も少なく利用したキャッシュ・メモリ要素を指示するように、前記ＣＡＭコントローラが形成されることを特徴とする請求項１０２記載のパケット・モニタ。
［請求項１０４］  前記上部ＣＡＭから始まる各ＣＡＭのアドレスおよびポインタ出力が、次のＣＡＭのアドレスおよびポインタ入力に結合され、次のＣＡＭの最後は下部ＣＡＭであり、キャッシュ・ヒットが起こった場合に、そのヒットを引き起こしたＣＡＭのアドレスおよびポインタの内容はスタックの上部ＣＡＭに配置され、アサートされた一致出力を引き出したＣＡＭより上側のＣＡＭのアドレスおよびポインタの内容はシフト・ダウンされるように、下部ＣＡＭによって指示される最近最も少なく使用したキャッシュ・メモリ要素および上部ＣＡＭによって指示される最近最も多く使用したキャッシュ・メモリ要素を利用した利用の最新性に基づいてＣＡＭが順序付けられるように、前記ＣＡＭコントローラが形成されることを特徴とする請求項１０３記載のパケット・モニタ。
［請求項１０５］  外部メモリの１つ又はそれ以上の要素を探索するキャッシュ・システムであって：
（ａ）  前記外部メモリに結合された１組のキャッシュ・メモリ要素であって、各キャッシュ・メモリ要素は前記外部メモリの要素を入力するための入力ポートを含み、前記外部メモリの要素の入力を格納するよう形成される１組のキャッシュ・メモリ要素；
（ｂ）  上部ＣＡＭから下部ＣＡＭへの接続の順序に従って接続された１組の内容アドレス可能なメモリ・セル（ＣＡＭ）であって、各ＣＡＭが、前記キャッシュ・メモリ要素の１つに対するアドレスおよびポインタを含み、および各ＣＡＭが：
（ｉ）  入力を有する一致回路であって、前記入力がＣＡＭセル内のアドレスと同一である場合にＣＡＭが一致出力をアサートし、アサートされた一致出力はヒットを示すところの一致回路，
（ｉｉ）  アドレスおよびポインタを受け入れるように形成されたＣＡＭ入力，および
（ｉｉｉ）  ＣＡＭアドレス出力およびＣＡＭポインタ出力
を含むところの１組の内容アドレス可能なメモリ・セル；
（ｃ）  前記ＣＡＭの組に結合されるＣＡＭコントローラ；および
（ｄ）  前記ＣＡＭコントローラ，前記キャッシュ・メモリの組および前記外部メモリに結合されたメモリ・コントローラ
を含み、前記一致回路入力への入力が、前記入力に等しいアドレスを含む任意のＣＡＭセルにおいて一致出力を生じさせるように、前記ＣＡＭセルの一致回路入力が結合され、および
前記ＣＡＭコントローラが、特定のＣＡＭが指示するキャッシュ・メモリ要素が時間と共に変化するように形成されることを特徴とするキャッシュ・システム。
［請求項１０６］  前記下部ＣＡＭが最近最も少なく利用したキャッシュ・メモリ要素を指示するように、前記ＣＡＭコントローラが形成され、前記ＣＡＭコントローラは、最近最も少なく利用したキャッシュ・メモリ要素が、処理される第１メモリ要素であるような最少利用置換手法を実現するよう形成されることを特徴とする請求項１０５記載のキャッシュ・システム。
［請求項１０７］  前記上部ＣＡＭから始まる各ＣＡＭのアドレスおよびポインタ出力が、次のＣＡＭのアドレスおよびポインタ入力に結合され、次のＣＡＭの最後は下部ＣＡＭであり、キャッシュ・ヒットが起こった場合に、そのヒットを引き起こしたＣＡＭのアドレスおよびポインタの内容はスタックの上部ＣＡＭに配置され、アサートされた一致出力を引き出したＣＡＭより上側のＣＡＭのアドレスおよびポインタの内容はシフト・ダウンされるように、下部ＣＡＭによって指示される最近最も少なく使用したキャッシュ・メモリ要素および上部ＣＡＭによって指示される最近最も多く使用したキャッシュ・メモリ要素を利用した利用の最新性に基づいてＣＡＭが順序付けられるように、前記ＣＡＭコントローラが形成されることを特徴とする請求項１０６記載のキャッシュ・システム。
［請求項１０８］  最初に処理されるキャッシュ・メモリ・エントリである最近最も少なく利用したエントリを利用して、キャッシュ・メモリ要素の置換が、利用の最新性とは逆の順序に従って行われることを特徴とする請求項１０７記載のキャッシュ・システム。
［請求項１０９］  各メモリ要素がメモリのページであることを特徴とする請求項１０５記載のキャッシュ・システム。
［請求項１１０］  各キャッシュ・メモリ要素が、それがダーティであるか否かの指標と共に提供され、前記ＣＡＭコントローラは、前記のダーティな内容を前記外部メモリにバック・アップすることによって、ダーティ・キャッシュ・メモリ要素をクリーニングするように形成されることを特徴とする請求項１０５記載のキャッシュ・システム。
［請求項１１１］  ＬＲＵ置換手法に従ってキャッシュ内容が置換される必要が生じるまで、キャッシュ・メモリ要素の内容がクリーニング後も維持されることを特徴とする請求項１１０記載のキャッシュ・システム。
［請求項１１２］  各キャッシュ・メモリ要素が、それがダーティであるか否かの指標と共に提供され、前記ＣＡＭコントローラは、前記のダーティな内容を前記外部メモリにバック・アップすることによって、ダーティ・キャッシュ・メモリ要素をクリーニングするように形成されることを特徴とする請求項１０６記載のキャッシュ・システム。
［請求項１１３］  前記ＣＡＭコントローラが、前記キャッシュ・メモリ要素の内容を置換するのに先立って、ダーティ・キャッシュ・メモリ要素をクリーニングするよう形成されることを特徴とする請求項１１２記載のキャッシュ・システム。
［請求項１１４］  前記ＣＡＭコントローラが、前記キャッシュ・メモリ要素の内容を置換するのに先立って、ダーティ・キャッシュ・メモリ要素をクリーニングするよう形成されることを特徴とする請求項１１３記載のキャッシュ・システム。
［請求項１１５］  各キャッシュ・メモリ要素が、それがダーティであるか否かの指標と共に提供され、前記ＣＡＭコントローラは、前記のダーティな内容を前記外部メモリにバック・アップすることによって、利用の最新性とは逆の順序で、ダーティ・キャッシュ・メモリ要素をクリーニングするように形成されることを特徴とする請求項１０７記載のキャッシュ・システム。
［請求項１１６］  利用の最新性とは逆の順序のクリーニングが、前記キャッシュ・コントローラがアイドルのときはいつでも自動的に行われることを特徴とする請求項１１５記載のキャッシュ・システム。
［請求項１１７］  外部メモリの１つ又はそれ以上の要素を探索するキャッシュ・システムであって：
（ａ）  前記外部メモリに結合された１組のキャッシュ・メモリ要素であって、各キャッシュ・メモリ要素は前記外部メモリの要素を入力するための入力ポートを含み、前記外部メモリの要素の入力を格納するよう形成される１組のキャッシュ・メモリ要素；および
（ｂ）  キャッシュ・メモリ要素の１つに対するアドレスおよびポインタを含む１組の内容アドレス可能なメモリ・セル（ＣＡＭ）であって、前記入力がＣＡＭセル内のアドレスと同一である場合にＣＡＭが一致出力をアサートする入力を有する一致回路を含むところの１組の内容アドレス可能なメモリ・セル；
を有し、特定のＣＡＭが指示するキャッシュ・メモリ要素が時間と共に変化することを特徴とするキャッシュ・システム。
［請求項１１８］  ＣＡＭが上部から下部への順序で結合され、下部ＣＡＭが最近最も少なく利用したキャッシュ・メモリ要素を指示することを特徴とする請求項１１７記載のキャッシュ・システム。
［請求項１１９］  コンピュータ・ネットワーク上の接続点を介して通過する総てのパケットを検査するパケット・モニタであって、当該パケット・モニタは：
（ａ）  前記接続点に結合され、前記接続点を介して通過するパケットを受信するよう形成されるパケット捕捉装置；および
（ｂ）  受信したパケットが所属する以前遭遇した会話フローに関する１つ又はそれ以上のフロー・エントリより成るデータベースを格納するメモリ；
（ｃ）  前記パケット捕捉装置に結合され、受信したパケットが前記フロー・エントリ・データベースに属するか否かを探索するように、および前記パケットがフロー・エントリに属する場合に前記受信したパケットに対して前記フローの状態を判定するように形成される探索エンジン；
（ｄ）  前記探索エンジンに結合され、前記受信したパケットが前記フロー・エントリ・データベース内のフローに属しない場合に、フローの状態を判定する状態判定機構；および
（ｅ）  前記探索エンジンおよび前記状態判定機構に結合され、前記パケットが既存のパケットからのものである場合に、前記フローの最後に遭遇した状態から始まるフローの状態に関して特定される状態作業を実行し、前記パケットが既存のパケットからのものである場合に、新たなフローの初期状態に要求される状態作業を実行するよう形成される状態プロセッサ；
を有することを特徴とするパケット・モニタ。
［請求項１２０］  状態プロセッサが実行するよう形成される１組の可能な状態作業が、パケット部分における１つ又はそれ以上のパターンを探索することを含む特徴とする請求項１１９記載のモニタ。
［請求項１２１］  前記モニタが、前記接続点を通過する総てのパケットをリアル・タイムで処理することを特徴とする請求項１２０記載のモニタ。
［請求項１２２］  前記状態プロセッサがプログラム可能であり、前記モニタが更に前記状態プロセッサに結合した状態パターン／作業メモリを含み、前記状態作業メモリが状態パターン／作業のデータベースを格納することを特徴とする請求項１２０記載のモニタ。
［請求項１２３］  前記パケット捕捉装置，前記状態プロセッサおよび前記探索エンジンに結合されるバッファを更に有し、前記バッファは前記受信したパケットの少なくとも選択された部分を受け入れるよう形成されることを特徴とする請求項１１９記載のモニタ。
［請求項１２４］  前記状態プロセッサが、バッファ内容の中でＮＲユニットの参照ストリングを探索するよう形成された探索装置を含み、当該探索装置が：
（ｉ）  第１参照ストリングの前記ＮＲユニットを受信するよう形成された第１参照ストリング・レジスタ；
（ｉｉ）  直列に結合され、前記バッファに結合された１つ又はそれ以上のターゲット・データ・レジスタであって、前記ターゲット・データ・レジスタは前記バッファからその内容を受信するよう形成される１つ又はそれ以上のターゲット・データ・レジスタ；および
（ｉｉｉ）  第１の複数の比較器群であって、ある比較器群は前記ターゲット・データ・レジスタ内の各々の開始点に対応し、特定の開始位置からの比較器群が、前記第１参照レジスタの各ユニットと前記特定の開始位置から始まる前記ターゲット・データ・レジスタのＮＲユニットとに結合され、前記第１参照レジスタ内容と、前記特定の開始位置から始まる前記ターゲット・データ・レジスタのＮＲ個の隣接するユニットの対応する内容とを比較するところの第１の複数の比較器群；
を有し、各比較器群が、その対応する異なる開始位置から始まる前記ターゲット・データの中で前記第１参照ストリングの一致の有無を示し，
これにより、前記第１の複数の比較器群が、任意の開始位置で始まる前記ターゲット・データ・レジスタ内に前記第１参照ストリングが含まれているか否かを並列に示すことを特徴とする請求項１２３記載のモニタ。
［請求項１２５］  コンピュータ・ネットワーク上の接続点を介して通過するパケットの内容を処理するよう形成されたプロセッサであって、当該プロセッサは：
（ａ）  前記接続点を介して通過する各パケットの前記内容の少なくとも一部を受信するバッファ；
（ｂ）  前記状態プロセッサに対する命令群の内の１つ又はそれ以上の命令を含むメモリ；
（ｃ）  前記バッファに結合される算術論理装置（ＡＬＵ）；
（ｄ）  前記ＡＬＵおよび前記命令メモリに結合され命令をデコードする制御ブロック；および
（ｅ）  前記命令メモリおよび前記ＡＬＵに結合され、前記メモリ内の処理を行う次の状態プロセッサ命令を示すプログラム・カウンタ；
を有し、前記ＡＬＵは、パケットの内容の中で参照ストリングを探索する１つ又はそれ以上の比較器より成る探索装置を含むことを特徴とするプロセッサ。
［請求項１２６］  前記状態プロセッサが、前記接続点を介して通過する全パケットの内容をリアル・タイムで処理することを特徴とする請求項１２５記載のプロセッサ。
［請求項１２７］  前記命令群が、前記ＡＬＵ内の前記探索装置に対して、前記パケットの範疇で未知の位置から始まるパケット中の特定の参照ストリングを探索することを求める命令を含むことを特徴とする請求項１２５記載のプロセッサ。
［請求項１２８］  前記探索装置が、パケットの内容中の任意の参照ストリングを探索し、前記命令群が、前記ＡＬＵ内の前記探索装置に対して、前記パケットの範疇で未知の位置から始まるパケット中の特定の参照ストリングを探索することを求める命令を含むことを特徴とする請求項１２５記載のプロセッサ。
［請求項１２９］  前記ターゲット・データ内の任意の開始位置から始まるターゲット・データ中のＮＲユニットの参照ストリングを探索するよう形成された探索装置であって、当該探索装置は：
（ａ）  第１参照ストリングの前記ＮＲユニットを受信するよう形成された第１参照レジスタ；
（ｂ）  直列に結合され前記ターゲット・データを受信する１つ又はそれ以上のターゲット・データ・レジスタ；および
（ｃ）  第１の複数の比較器群であって、ある比較器群は前記開始点の各々に対応し、特定の開始位置からの比較器群が、前記第１参照レジスタの各ユニットと前記特定の開始位置から始まる前記ターゲット・データ・レジスタのＮＲユニットとに結合され、前記第１参照レジスタ内容と、前記特定の開始位置から始まる前記ターゲット・データ・レジスタのＮＲ個の隣接するユニットの対応する内容とを比較するところの第１の複数の比較器群；
を有し、各比較器群が、その対応する異なる開始位置から始まる前記ターゲット・データの中で前記第１参照ストリングの一致の有無を示し，
これにより、前記第１の複数の比較器群が、任意の開始位置で始まる前記ターゲット・データ・レジスタ内に前記第１参照ストリングが含まれているか否かを並列に示すことを特徴とする探索装置。
［請求項１３０］  １組の可能な開始位置が、Ｎｓｔａｒｔ個の位置を含み、前記１つ又はそれ以上のターゲット・データ・レジスタが直列に結合され前記ターゲット・データの少なくともＮＲ＋Ｎｓｔａｒｔ−１個のユニットを受信し、前記第１の複数の比較器群が、Ｎｓｔａｒｔ個の比較器群、Ｎｓｔａｒｔ個の開始位置の各々に関する１つの比較器群を含むことを特徴とする請求項１２９記載の探索装置。
［請求項１３１］  前記ターゲット・データ・レジスタの各々は、データのＮｓｔａｒｔ個のユニットを保持することを特徴とする請求項１３０記載の探索装置。
［請求項１３２］  前記ターゲット・データのＮｓｔａｒｔユニットが前記ターゲット・データ・レジスタ内に１クロック・サイクルでクロック入力され、前記第１の複数の比較器群が、前記第１参照ストリングが、Ｎｓｔａｒｔ個の開始位置の何れかにおいて開始するターゲット領域中のものであるか否かを１クロック・サイクルで示すことを特徴とする請求項１３１記載の探索装置。
［請求項１３３］  更に、オフセットＮｏｆｆｓｅｔを特定するための機構を有し、第１の動作クロック・サイクルにおいて、前記第１の複数の比較器群が、前記第１参照ストリングが、第１Ｎｏｆｆｓｅｔ開始位置の後に始まる前記第１データの任意のＮｓｔａｒｔ−Ｎｏｆｆｓｅｔ開始位置で始まるターゲット・データ領域中のものであるか否かを、前記第１クロック・サイクルで示すように第１のＮｏｆｆｓｅｔ開始位置が無視され、以後のクロック・サイクルにおいて総てのＮｓｔａｒｔ開始位置が処理され，
１つ又はそれ以上のクロック・サイクルにおいて、前記探索装置が、第１のＮｏｆｆｓｅｔユニット以外の任意の場所で始まるターゲット・データ中に前記第１参照ストリングがあるか否かを示すことを特徴とする請求項１３２記載の探索装置。
［請求項１３４］  各比較器群が、ＮＲ個の隣接する比較器を有し、各比較器は参照ユニット入力，ターゲット・ユニット入力および一致を示す出力を有し、前記参照およびターゲット・データ入力が一致し先行する比較器の出力が一致を示す場合に比較器の出力がアサートされるように、各比較器は先行する比較器の出力に結合されることを特徴とする請求項１２９記載の探索装置。
［請求項１３５］  更に：
（ｄ）  １つ又はそれ以上の更なる参照ストリングのＮＲユニットを受信する１つ又はそれ以上の更なる参照レジスタ；および
（ｅ）  1つ又はそれ以上の更なる複数の比較器群であって、対応する複数の開始位置の各々について１つの比較器群があり、更なる複数のうちの特定の比較器群の各々が、対応する更なる参照レジスタの各ユニットと前記特定の比較器群の開始位置から始まる前記データ・レジスタのＮＲユニットとに結合され、対応する更なる参照レジスタ内容と、前記特定の比較器群の開始位置から始まる前記ターゲット・データ・レジスタのＮＲ個ユニットとを比較するところの1つ又はそれ以上の更なる複数の比較器群；
を有し、前記探索装置が、任意の開始位置から始まる前記ターゲット・データ・レジスタの内容において、ＮＲユニットの前記第１又は更なる参照ストリングを探索することを特徴とする請求項１２９記載の探索装置。
［請求項１３６］  各比較器群が、ＮＲ個の隣接する比較器を有し、各比較器は参照ユニット入力，ターゲット・データ・ユニット入力および一致を示す出力を有し、前記参照およびターゲット・データ入力が一致し先行する比較器の出力が一致を示す場合に比較器の出力がアサートされるように、各比較器は先行する比較器の出力に結合されることを特徴とする請求項１３５記載の探索装置。
［請求項１３７］  各比較器群が、ＮＲ個の隣接する比較器を有し、各比較器は参照ユニット入力，ターゲット・データ・ユニット入力，イネーブル入力および一致を示す出力を有し、前記参照およびターゲット・データ入力が一致しイネーブル入力がアサートされる場合に比較器の出力がアサートされ、
特定の開始位置に関する特定の比較器群に対して、隣接する比較器の参照入力が前記参照レジスタの隣接するユニットに結合され、隣接する比較器のターゲット・データ入力が、特定の開始位置から始まるターゲット・データ・レジスタの隣接するユニットに結合され、第1の比較器群がイネーブルされ、各比較器のイネーブル入力が先行する比較器の出力に結合され、参照ストリングのＮＲユニットおよび前記ターゲット・データのＮＲユニットが合致する場合に、最後の比較器の出力がアサートされることを特徴とする請求項１２９記載の探索装置。
［請求項１３８］  １ユニットが１バイトであることを特徴とする請求項１２９記載の探索装置。
［請求項１３９］  前記比較器群の最終比較出力が、前記ターゲット・データ中に前記参照ストリングの一致が生じたか否かおよびその場所を示す出力を有する優先選択器に結合されることを特徴とする請求項１３７記載の探索装置。
［請求項１４０］  ＮＲが１６バイトであることを特徴とする請求項１３８記載の探索装置。
［請求項１４１］  ＮＲが１６バイトであり、データ・レジスタの各々がＮｓｔａｒｔバイトであり、前記探索装置が前記第１データ・レジスタ内の何れかから開始して一致を示すことを特徴とする請求項１３０記載の探索装置。
［請求項１４２］  ターゲット・データストリーム内のＮＲユニットの参照ストリングを探索するよう形成された探索装置であって、当該探索装置は：
（ａ）  入力のＮＲ個の対、および前記入力のＮＲ個の対の各対の一致を示す出力を有する第１のＮＲユニットの比較器；
（ｂ）  前記参照ストリングの値を示し行列の第１軸を定めるＮＲ個の接続部であって、さらにＮＲ個の接続部は、前記第１の軸に垂直な行列の第２の軸を定める前記ターゲット・データの値を示し、ターゲット・データ接続部は、前記ターゲット・データの第１の開始位置から始まり、終了位置で終了するところのＮＲ個の接続部；
を有し、前記ターゲット・データのＮＲ個の接続部が、ＮＲ個の参照ストリングの接続部と比較されるように、第１の比較器が前記行列の対角線に沿って方向付けられることを特徴とする探索装置。
［請求項１４３］  更に：
１つ又はそれ以上の並列に隣接する付加的な接続部であって、前記行列において前記ターゲット・データ接続部に隣接し、前記終了位置から開始するところの接続部；および
前記付加的なターゲット・データ接続部の各々に対して及びそれらに対応する付加的なＮＲユニットの比較器であって、各付加的な比較器は前記第１比較器に並列しており、前記行列において前記付加的なターゲット接続部に向かってシフトされるところの付加的なＮＲユニットの比較器；
を有し、各付加的な比較器が、前記参照ストリングを、異なる開始点から始まる前記ターゲット・データのＮＲユニット連続値の異なる組と比較することを特徴とする請求項１４２記載の探索装置。
［請求項１４４］  更に：
１つ又はそれ以上のＮＲユニットの更なる比較器群；および
ＮＲユニットの更なる比較器群に対応する更なる比較器群であって、前記更なる接続部が１つ又はそれ以上の行列を定め、前記第１軸に沿う更なる接続部の各々が、前記第１軸に沿う更なる参照ストリングに対応する１つ又はそれ以上の値を示し、ＮＲ個の接続部が前記第２軸に沿う前記ターゲット・データの値を含むところの更なる比較器群；
を有し、付加的な比較器群の各々が、前記参照ストリングの対応するものと、異なる開始位置から開始するターゲット・データのＮＲ個の隣接する値の異なる組を比較することを特徴とする請求項１４３記載の探索装置。
【０６４０】
本願の可能な態様を下記に記載しておく。
［態様１］コンピュータネットワーク上の接続点を通過するパケットを検査する方法であって、各パケットは１つ又は複数のプロトコルに従うものであり、当該方法は：
パケット捕捉装置からパケットを受信する段階；
前記パケットに関して少なくとも１つの分解作業及び／又は少なくとも１つの抽出作業を実行し、前記パケットの選択された部分の関数を有する分解レコードを作成する段階であって、前記分解及び／又は抽出作業の少なくとも１つは前記パケットが従う前記プロトコルの１つまたは複数に依存する段階；
以前に遭遇したゼロ個以上の会話フローのフローエントリを有するフローエントリデータベースを探索する段階であって、該探索は、前記選択されたパケット部分の少なくとも一部を利用し、前記パケットが既存のフローのものであるか否かを判定する段階；
前記パケットが既存のフローのものであった場合、前記パケットを発見された既存のフローに属するものとして分類し、前記フローの状態を判別し、該フローの状態について指定されたゼロ個以上の状態作業を実行する段階；および
前記パケットが新たなフローのものであった場合、前記フローエントリデータベース内に、前記新たなフローのための新規フローエントリであって、将来のパケットが該新規フローエントリに関するものであると識別されるための識別情報を含む新規フローエントリを記憶する段階；
を有する方法。
［態様２］
前記少なくとも１つの分解及び／又は抽出作業を実行する段階が、前記パケットにおいてあるプロトコルが使用されていることを示す前記パケット中のデータから１以上のプロトコルに依存する一群の抽出作業をどのように決定するかについての情報を含む分解及び抽出作業のデータベースに従って行われ、
新規フローエントリを記憶する前記段階は、前記パケットが新たなフローのものであった場合、前記新たなフローの初期状態に関して要求されるゼロ個以上の分析を実行する態様１記載の方法。
［態様３］前記状態の少なくとも１つに関して指定された状態作業の１つが、前記フローエントリを更新することを含み、前記フローエントリは、将来のパケットが前記フローエントリ関するものであると識別されるための識別情報を含む態様２記載の方法。
［態様４］前記状態の少なくとも１つに関して指定された状態作業の１つが、少なくとも１つの参照ストリングがあるかどうか前記パケットの内容を探索することを含む、態様２記載の方法。
［態様５］前記状態の少なくとも１つに関して指定された状態作業の１つが、将来のパケットがそのフローのものであると識別されるための新規フローエントリを作成することを含み、前記新規フローエントリは、将来のパケットが前記フローエントリに関するものであると識別されるための識別情報を含む、態様３記載の方法。
［態様６］前記選択されたパケット部分から署名を形成する段階を更に有し、前記探索作業は前記署名を使用し、前記新規の又は更新されたフローエントリに含まれる識別情報が、将来のパケットを識別するための署名である態様２記載の方法。
［態様７］前記状態作業が、プロトコルに依存する状態作業のデータベースによるものである態様２記載の方法。
［態様８］前記接続点を通過する各パケットが、リアルタイムで検査される態様１記載の方法。
［態様９］前記パケットを発見された既存のフローに属するものとして分類する段階が、前記既存のフローのフローエントリを更新する段階を有する態様１記載の方法。
［態様１０］前記の更新が、前記既存のフローのフローエントリに含まれた１つまたは複数の統計的指標を格納することを含む、態様９記載の方法。
［態様１１］前記１つまたは複数の統計的指標が、前記フローに関するパケット総数，時間，および最後に入力された時点から現時点までの時間差を含む群から選択された指標を含む態様１０記載の方法。
［態様１２］前記パケットの選択された部分の前記関数が、前記選択された部分を含み且つ将来のパケットを識別可能である署名を作成し、前記探索作業は前記署名を使用し、前記新規のまたは更新されたフローエントリに含まれる識別情報が、将来のパケットを識別するための署名である態様１記載の方法。
［態様１３］前記パケットの前記プロトコルの少なくとも１つがソースおよびあて先アドレスを使用し、前記パケットの前記選択された部分が前記ソースおよびあて先アドレスを含む態様１記載の方法。
［態様１４］同一フローの複数のパケットについての前記選択された部分の前記関数が、前記パケットの方向とは独立したものである態様１３記載の方法。
［態様１５］前記パケットの選択された部分の関数が該選択されたパケット部分を含む署名を形成し、前記ソースおよびあて先アドレスが、選択された部分の前記関数において前記アドレスの数値的な値の順序で決定される順序で並べられる態様１４記載の方法。
［態様１６］選択された部分の前記関数によって形成された署名の中で、数値的に低いアドレスが数値的に高いアドレスの前に並べられる態様１５記載の方法。
［態様１７］前記フローエントリデータベースの探索が、選択されたパケット部分のハッシュを利用する態様１記載の方法。
［態様１８］少なくとも１つの前記分解及び／又は抽出作業が、分解及び／又は抽出作業のデータベースによるものであり、前記データベースは、前記パケットで使用されたプロトコルを示す前記パケット内のデータから、１つ又は複数のプロトコルに依存した一群の抽出作業をどのように決定するかを示す情報を含む態様１記載の方法。
［態様１９］パケットを分類する前記段階が、前記パケットが既存のフローのものであった場合、前記フローの最後に遭遇した状態を求め、前記フローの最後に遭遇した状態から始めて前記フローの前記状態に関して特定された状態作業を実行し；および新規フローエントリを記憶する前記段階が、前記パケットが新たなフローのものであった場合、前記新たなフローの初期状態に要求されるゼロ個以上の状態作業を実行することを含む態様１記載の方法。
［態様２０］
特定の会話フロー・シーケンスが特定のアプリケーションプログラムの動作に関連付けられており、あるフローについての受信したパケット各々の状態処理は、どのアプリケーションプログラムが該フローに関連付けられているかの識別を先に進める態様１９記載の方法。
［態様２１］前記状態作業が、前記フローエントリを更新することを含み、将来のパケットが前記フローエントリに関するものであると識別されるための識別情報を格納することを含む態様１９記載の方法。
［態様２２］あるフローについての受信したパケット各々の状態処理が、前記フローのアプリケーションプログラムを識別することを先に進める態様２１記載の方法。
［態様２３］前記状態作業が、１つ又は複数の参照ストリングが存在するかどうかに関して前記分解レコードを探索する態様１９記載の方法。
［態様２４］前記状態作業が、プロトコルに依存する状態作業のデータベースに従って、プログラム可能な状態プロセッサにより実行される態様１９記載の方法。
［態様２５］前記パケットを分類する段階は、前記パケットが既存のフローのものであった場合、前記既存のフローのフローエントリを更新することを含み、該更新は前記フローエントリにおいて維持される１つ又は複数の統計的測定値を格納することを含み、新規フローエントリを記憶する前記段階は、前記パケットが新たなフローのものであった場合、前記新規フローエントリに１つ又は複数の統計的測定値を格納することを含み、前記接続点を通過する全パケットが前記パケット捕捉装置によって受信される態様１記載の方法。
［態様２６］前記パケットから識別部分を抽出する段階を更に含み、前記探索が、前記識別部分の関数を利用する態様２５記載の方法。
［態様２７］各段階が、前記接続点を通過する各パケットに対して、リアルタイムで実行される態様２５記載の方法。
［態様２８］前記１つまたは複数の統計的指標が、前記フローに関するパケット総数，時間，および最後に入力された時点から現時点までの時間差を含む群から選択された指標を含む態様２５記載の方法。
［態様２９］あるフローエントリのフローに関連する１つ又は複数のメトリックを、前記フローエントリの前記統計的指標の１つ又は複数から報告する段階を更に有する態様２５記載の方法。
［態様３０］前記メトリックが１つ又は複数のサービス品質メトリックを含む態様２９記載の方法。
［態様３１］前記の報告が時々行われ、前記１つ又は複数のメトリックが、最終報告時点からの時間間隔に関連する基本メトリックである態様２９記載の方法。
［態様３２］前記基本メトリックから１つ又は複数のサービス品質メトリックを計算する段階を更に有する態様３１記載の方法。
［態様３３］連続する複数の時間間隔からのメトリックが結合されて結合された間隔に対するメトリック各々を決定しうるように、前記１つ又は複数のメトリックがスケーラブルであるように選択される態様３１記載の方法。
［態様３４］会話フローが初期状態を含む状態を有し、フローのフローエントリは、該フローの状態について状態作業を一切含まないか又は該フローの状態について実行すべき１以上の状態作業を含み、前記パケットを分類する前記段階は、前記パケットが既存のフローのものであった場合、前記フローの最後に遭遇した状態を求め、前記フローの最後に遭遇した状態から始めて前記フローの前記状態について指定されたゼロ個以上の状態作業を実行することを含み；新規フローエントリを記憶する前記段階は、前記パケットが新たなフローのものであった場合、前記新たなフローの初期状態に要求されるゼロ個以上の状態作業を実行することを含む、態様２５記載の方法。
［態様３５］あるフローエントリのフローに関連する１つ又は複数のメトリックを、前記フローエントリの前記統計的指標の１つ又は複数から報告する段階を更に有する態様３４記載の方法。
［態様３６］前記の報告が時々行われ、前記１つ又は複数のメトリックが、最終報告時点からの時間間隔に関連する基本メトリックである態様３５記載の方法。
［態様３７］前記の報告が、前記フローの前記状態についての前記状態作業の一部である態様３６記載の方法。
［態様３８］前記状態作業が、前記フローエントリを更新することを含み、将来のパケットが前記フローエントリのものであると識別されるための識別情報を格納することを含む態様３４記載の方法。
［態様３９］更なるパケットを受信する段階を更に有し、あるフローについての受信したパケット各々の状態処理が、前記フローのアプリケーションプログラムを識別することを先に進める態様３８記載の方法。
［態様４０］前記フローの状態に関連する１つ又は複数のメトリックが、前記フローの状態について指定された状態作業の一部として判定される態様３９記載の方法。
［態様４１］コンピュータネットワーク上の接続点を通過するパケットを検査するパケットモニタであって、各パケットは１つ又は複数のプロトコルに従い、当該パケットモニタは：
前記接続点に結合され、前記接続点を通過するパケットを受信するよう構成されたパケット捕捉装置であって、パケットを受け入れるように結合および構成された入力バッファメモリを含むパケットモニタ；
前記入力バッファメモリに結合されおよびスライサを有する分解サブシステムであって、前記分解サブシステムは、受け入れられた前記パケットの選択された部分を抽出し、前記選択された部分を含む分解レコードを出力するよう構成され、前記分解サブシステムの動作は前記パケットの従う１以上のプロトコルに依存する分解サブシステム；
ゼロ個以上の以前遭遇した会話フローのフローエントリを含むデータベースを格納するメモリであって、各フローエントリは、該フローエントリに含まれている識別情報によって確認され、会話フローは１以上の状態を有するメモリ；
前記分解サブシステムの出力および前記メモリに結合され、前記分解サブシステムから出力される分解レコードに対応する特定のパケットに対して、フローエントリデータベース中に一致するフローエントリがあるか否かを探索するように構成された探索エンジンであって、前記探索は、選択されたパケット部分の少なくとも一部を利用して、前記パケットが既存のフローのものであるか否かを判定する探索エンジン；および
前記メモリおよび前記探索エンジンに結合され、前記フローエントリデータベース内でフローエントリを作成するよう構成されたフロー挿入エンジンであって、前記フローエントリは、将来のパケットが新規フローエントリのものであると識別されるための識別情報を含むフロー挿入エンジン；および
前記フローの状態について指定されたゼロ個以上の状態作業を実行するよう構成された状態プロセッサ；
を有し、前記探索エンジンは、前記パケットが既存のフローのものであった場合、前記パケットを発見された既存のフローに属するものとして分類し、前記フロー挿入エンジンは、前記パケットが新たなフローのものであった場合、該新たなフローの新規フローエントリを前記フローエントリデータベースに格納し、前記新規フローエントリは、将来のパケットが該新規フローエントリのものであると識別されるための識別情報を含む、
パケットモニタ。
［態様４２］パケットにおいて使用される前記プロトコルの少なくとも１つを前記パケット中のデータからどのように判定するかを記述する情報を含む抽出作業および分解作業のデータベースを格納する分解及び抽出作業メモリ；
一群の所定の状態遷移パターン及び状態作業を格納する状態パターン及び作業メモリであって、特定の会話フロー・シーケンスのパケットが特定の遷移パターンをたどることは、該特定の会話フロー・シーケンスが特定のアプリケーションプログラムの動作に関連付けられていることを示し、前記パターンをたどることのうちで各状態を訪れることは、１以上の所定の状態作業がある場合に、該状態についての所定の１以上の状態作業を実行することを含む、状態パターン及び作業メモリ；
前記状態パターン又は作業メモリに及び前記探索エンジンに結合され、前記パケットの前記会話フローのプロトコル及び状態を判別するよう構成されたプロトコル及び状態識別手段；
を有し、前記状態プロセッサは、前記フローエントリデータベースに、前記プロトコル及び状態識別手段に、並びに前記状態パターン及び作業メモリに結合され、前記状態プロセッサは、パケットのフローのプロトコル及び状態に関して前記状態パターン及び作業メモリで指定されているゼロ個以上の状態動作を実行するよう構成され、
前記分解サブシステムは前記パターン及び抽出作業メモリにも結合され、前記状態プロセッサは、パケットの会話フロー・シーケンスにどのアプリケーションプログラムが関連付けられているかを識別するプロセスを先に進める状態動作を実行し、前記状態プロセッサは、受け入れたパケットについて実行する状態作業が一切なくなるまで、一連の状態及び状態作業を通じて動作を進め、フローエントリを更新する、或いは前記状態プロセッサは、フローのそれ以上の分析が不要であることを示す最終状態に至るまで、一連の状態及び状態作業を通じて動作を進め、分析結果を通知する
態様４１記載のパケットモニタ。
［態様４３］前記フローエントリが前記フローの前記状態を含み、前記プロトコル及び状態識別手段は、前記探索エンジンが、受け入れられたパケットのフローのフローエントリを発見した場合に、前記フローエントリから前記パケットの前記状態を判定する態様４２記載のパケットモニタ。
［態様４４］前記分解サブシステムが前記選択された部分からハッシュを作成する手段を含み、前記探索エンジンは前記ハッシュを利用して前記フローエントリデータベースを探索するよう構成されており、前記ハッシュは前記フローエントリデータベース内に前記フローエントリを分散するように設計される態様４２記載のパケットモニタ。
［態様４５］前記分解及び抽出作業メモリに結合されたコンパイラプロセッサを更に有し、前記コンパイラプロセッサはコンパイルプロセスを実行するよう形成され、前記コンパイルプロセスは：
前記モニタが遭遇するパケットにおいて使用されうる前記プロトコルを記述する高レベルのプロトコル記述言語の命令を受信すること、および該プロトコル記述言語命令を複数の分解又は抽出作業、或いは、分解及び抽出作業両方に翻訳することを含み、それらの分解及び／又は抽出作業が前記分解及び抽出作業メモリ中に初期化される、態様４２記載のパケットモニタ。
［態様４６］前記プロトコル記述言語命令が、１つ又は複数のアプリケーションプログラム群と、アプリケーションプログラムに関連する特定の会話フロー・シーケンスの結果として生じる前記状態遷移パターン及び作業との間の対応関係をも記述し、前記コンパイラプロセッサは前記状態パターン及び作業メモリにも結合され且つコンパイルプロセスを実行して前記プロトコル記述言語命令を、前記状態パターン及び作業メモリ内に初期化される複数の状態パターン及び状態作業に翻訳する態様４５記載のパケットモニタ。
［態様４７］更に：
前記フローエントリデータベースの中でアクセスされやすいフローエントリ群への高速アクセスを提供するために、前記探索エンジンと前記フローエントリデータベースの間でそれらに結合されたキャッシュメモリを更に有する態様４２記載のパケットモニタ。
［態様４８］前記キャッシュが、完全連想式の、最長未使用時間に基づくキャッシュメモリとして機能するよう構成されている、態様４７記載のパケットモニタ。
［態様４９］前記キャッシュが、完全連想式の、最長未使用時間に基づくキャッシュメモリとして機能するよう構成されており、スタックとして構成された内容アドレス可能なメモリを有する態様４８記載のパケットモニタ。
［態様５０］前記フロー挿入エンジンが、各フローエントリ中にフローに関する１つ又は複数の統計的指標を格納するよう構成され、当該パケットモニタは、受け入れたパケットのフローエントリ中の前記統計的指標を更新する計算機を更に有する態様４２記載のパケットモニタ。
［態様５１］フローの前記アプリケーションプログラムが決定される場合に、前記アプリケーションに関連するおよび前記統計的指標から決定された１つ又は複数のネットワーク利用メトリックが、ネットワークパフォーマンスを監視するユーザに提供される態様５０記載のパケットモニタ。
［態様５２］前記入力バッファメモリは、前記接続点を通過する各パケットを受け入れるよう構成され、前記分解サブシステムは各パケットをリアルタイムで検査するよう構成される、態様４１記載のパケットモニタ。
［態様５３］前記探索エンジンは、探索が成功した場合に既存のフローの前記フローエントリを更新するよう構成されている、態様４１記載のパケットモニタ。
［態様５４］前記分解サブシステムは、前記選択された部分からハッシュを作成し且つ前記探索エンジンに対する特定のパケットについての入力に前記ハッシュを含めるよう構成され、前記探索エンジンは、前記ハッシュを用いて前記フローエントリデータベースを探索するよう構成されている、態様４１記載のパケットモニタ。
［態様５５］分解作業及び抽出作業のデータベースを含むメモリを更に有し、前記分解及び抽出データベースメモリは前記分解サブシステムに結合され、前記分解サブシステムは、分解及び抽出データベースから探索された１以上の作業に従って、前記分解作業及び／又は抽出作業を実行するよう構成されている、態様４１記載のパケットモニタ。
［態様５６］分解及び抽出作業の前記データベースが、前記パケットにおいて使用されるプロトコルを指示する前記パケット内のデータから、１つ以上のプロトコル依存性の抽出作業の群をどのように決定するかを記述する情報を含んでいる、態様５５記載のパケットモニタ。
［態様５７］前記分解サブシステムの前記出力に、前記探索エンジンにおよび前記フロー挿入エンジンに結合されたフローキーバッファを更に含み、前記分解サブシステムの前記出力は前記フローキーバッファを介して前記探索エンジンに結合され、前記フロー挿入エンジンは前記フローキーバッファを介して前記探索エンジンに結合される態様４１記載のパケットモニタ。
［態様５８］前記状態プロセッサは、前記探索エンジンおよび前記フローエントリデータベースメモリに結合され、前記パケットが既存のフローからのものであった場合、前記フローの最後に遭遇した状態から始めてフローの状態について指定されたゼロ個以上の状態作業を実行し、前記パケットが既存のフローからのものであった場合、新たなフローの初期状態に要求されるゼロ個以上の状態作業を実行するよう構成される、態様４１記載のパケットモニタ。
［態様５９］前記状態プロセッサが実行するよう構成されている状態作業が、パケット部分内の１つ以上のパターンを探索することを含む態様５８記載のパケットモニタ。
［態様６０］前記状態プロセッサはプログラム可能であり、前記分解サブシステムは前記状態プロセッサに結合された状態パターン及び作業メモリを更に含み、前記状態パターン及び作業メモリは、プロトコル依存性の状態パターン及び作業のデータベースを格納する態様５８記載のパケットモニタ。
［態様６１］前記フローキーバッファにおよび前記フローエントリデータベースメモリに結合された状態プロセッサを更に含み、該状態プロセッサは、前記パケットが既存のフローからのものであった場合、前記フローの最後に遭遇した状態から始めてフローの状態について指定されるゼロ個以上の状態作業を実行し、前記パケットが既存のフローからのものであった場合、新たなフローの初期状態に要求されるゼロ個以上の状態作業を実行するよう構成される、態様５７記載のパケットモニタ。
［態様６２］前記状態作業が、前記フローエントリを更新することを含み、前記フローエントリが、将来のパケットが前記フローエントリのものであると識別されるための識別情報を含む、態様５８記載のパケットモニタ。
［態様６３］前記分解及び抽出作業メモリに結合されたコンパイラプロセッサを更に有し、前記コンパイラプロセッサはコンパイルプロセスを実行するよう構成され、該コンパイルプロセスは：
前記モニタが遭遇するパケットにおいて使用されうる前記プロトコルおよびそのゼロ個以上の子プロトコルを記述する高レベルのプロトコル記述言語の命令を受信し、および
該プロトコル記述言語命令を、前記分解及び抽出作業メモリ中に初期化される複数の分解又は抽出作業或いは複数の分解及び抽出作業の双方に翻訳することを含む、態様４１記載のパケットモニタ。
［態様６４］前記分解及び抽出作業メモリに結合されたコンパイラプロセッサを更に有し、前記コンパイラプロセッサはコンパイルプロセスを実行するよう構成され、該コンパイルプロセスは：
１つ以上のアプリケーションプログラムの群と、アプリケーションプログラムに関連する特定の会話フロー・シーケンスの結果として生じる前記状態遷移パターン及び作業との間の対応関係を記述する高レベルのプロトコル記述言語の命令を受信し、および
該プロトコル記述言語命令を、前記状態パターン及び作業メモリ中に初期化される複数の状態パターンおよび状態作業に翻訳することを含む、態様６０記載のパケットモニタ。
［態様６５］前記フローエントリデータベースから、アクセスされやすいフローエントリ群への高速アクセスを行うよう構成された、前記探索エンジンおよび前記フローエントリデータベースメモリの間でそれらに結合されたキャッシュサブシステムを更に有する態様４１記載のパケットモニタ。
［態様６６］前記キャッシュサブシステムが、１つ以上の内容アドレス可能なメモリセルを含む連想式キャッシュサブシステムである態様６５記載のパケットモニタ。
［態様６７］前記キャッシュサブシステムが、最長未使用時間に基づくキャッシュメモリであり、キャッシュミスが、最も長く未使用であるキャッシュエントリを更新する態様６６記載のパケットモニタ。
［態様６８］前記フロー挿入エンジンが、前記フローに関する１つ以上の統計的指標と共に各フローエントリを格納し、前記分解サブシステムは、受け入れたパケットの前記フローエントリ中の統計的指標の少なくとも１つを更新する計算機を更に有する態様４１記載のパケットモニタ。
［態様６９］前記１つ以上の統計的指標が、前記フローに関するパケット総数，時間，および最後に入力された時点から現時点までの時間差を含む群から選択された指標を含む態様６８記載のパケットモニタ。
［態様７０］フローエントリにおける前記統計的指標の１つまたは複数から、前記フローに関する１つ以上のネットワーク利用メトリックを判定するよう構成された統計プロセッサを更に有する態様６８記載のパケットモニタ。
［態様７１］前記フローエントリデータベースが複数のビンに組織化され、複数のビン各々が１つ以上のフローエントリを有し、前記分解サブシステムは、前記選択されたパケット部分に基づいてハッシュデータ値を作成するよう構成され、前記探索エンジンは、作成されたハッシュデータ値を介して前記ビンにアクセスするよう構成されている、態様４１記載のパケットモニタ。
［態様７２］前記分解サブシステムは、比較的浅いバケットが作成され、前記探索エンジンによる探索が比較的高速に行われるよう、複数のフローエントリを前記フローエントリデータベースにわたって分散させるような仕方でハッシュデータ値を作成するよう構成されている、態様７１記載のパケットモニタ。
［態様７３］前記状態プロセッサが新しいフローおよび既存のフローの両者をアプリケーションにより分類するために分析するよう構成され、１組の所定の規則に基づいて状態から状態に進む態様５８記載のパケットモニタ。
［態様７４］前記探索エンジンが、前記分解サブシステムから分解レコードが到着すると直ちに処理を開始するよう構成されている、態様４１記載のパケットモニタ。
［態様７５］前記探索エンジンは、フロー状態エントリを検査してフローキーが前記状態プロセッサに送られるべきか否かを確認するよう構成されており、前記フローについてのプロトコル識別子を出力するよう構成されている、態様５８記載のパケットモニタ。
［態様７６］前記探索エンジンは、前記パケットが既存のフローのものであった場合、該フローエントリで維持されている１以上の統計的指標を格納するよう構成されており、前記フロー挿入エンジンは、前記パケットが新たなフローのものであった場合、前記フローエントリで維持されている１つ以上の統計的指標を格納するよう構成されている、態様４１記載のパケットモニタ。
［態様７７］前記分解サブシステムは、受信したパケットから識別情報を抽出するよう構成されており、前記探索エンジンは抽出された識別情報の関数を用いて探索を行うよう構成されている、態様７６記載のパケットモニタ。
［態様７８］前記１つ以上の統計的指標が、前記フローに関するパケット総数，時間，および最後に入力された時点から現時点までの時間差を含む群から選択された指標を含む態様７６記載のパケットモニタ。
［態様７９］フローに関する１つ以上のメトリックを、前記フローのフローエントリにおける前記統計的指標の一つ又は複数から決定する統計プロセッサを更に有する態様７６記載のパケットモニタ。
［態様８０］前記統計プロセッサが、前記１つ以上のメトリックを時々決定および報告するよう構成されている、態様７９記載のパケットモニタ。
［態様８１］前記データベースを格納する前記メモリに及び前記探索エンジンに結合されたキャッシュサブシステムを更に有し、前記キャッシュサブシステムは前記フローエントリデータベースのフローエントリに高速にアクセスするよう構成されている態様４１記載のパケットモニタ。
［態様８２］前記探索エンジンは前記分解サブシステムを介して前記パケット捕捉装置に結合され、前記分解サブシステムは受信したパケットから識別情報を抽出するよう構成され、各フローエントリは前記フローエントリに含まれる識別情報によって識別され、前記探索エンジンは、抽出した識別情報の関数を使用して前記キャッシュサブシステムを探索するよう構成されている、態様８１記載のパケットモニタ。
［態様８３］前記キャッシュサブシステムが、１つ以上の内容アドレス可能なメモリセルを含む連想式キャッシュサブシステムである態様８２記載のパケットモニタ。
［態様８４］前記キャッシュサブシステムが：
フローエントリデータベースメモリに結合された１組のキャッシュメモリ要素であって、各キャッシュメモリ要素はフローエントリを入力するための入力ポートを含み、前記フローエントリデータベースのフローエントリを格納するよう構成されている、１組のキャッシュメモリ要素；
内容アドレス可能なメモリセルと呼ばれ、最上部の内容アドレス可能なメモリセルから最下部の内容アドレス可能なメモリセルへの接続の順序に従って接続された１組の内容アドレス可能なメモリセルであって、内容アドレス可能なメモリセル各々は、前記キャッシュメモリ要素の１つに対するアドレスおよびポインタを含み且つ内容アドレス可能なメモリセル各々は：
入力を有する一致回路であって、前記入力がその内容アドレス可能なメモリセル内のアドレスと同一であった場合に、その内容アドレス可能なメモリセルが一致出力をアサートし、アサートされた一致出力はヒットを示す一致回路、
アドレスおよびポインタを受け入れるよう構成された内容アドレス可能なメモリセル入力、および
内容アドレス可能なメモリセルのアドレス出力および内容アドレス可能なメモリセルのポインタ出力
を含む１組の内容アドレス可能なメモリセル；
前記内容アドレス可能なメモリセルの組に結合される内容アドレス可能なメモリセル・コントローラ；および
前記内容アドレス可能なメモリセル・コントローラに、前記キャッシュメモリの組におよび前記フローエントリメモリに結合されたメモリコントローラ；
を含み、前記内容アドレス可能なメモリセルの一致回路入力が前記探索エンジンに結合され、前記一致回路入力への入力が、前記入力に等しいアドレスを含むゼロ個以上の内容アドレス可能なメモリセルにおいて一致出力を生じさせ、
前記内容アドレス可能なメモリセル・コントローラは、特定の内容アドレス可能なメモリセルが指示するキャッシュメモリ要素が時間と共に変化するように構成される態様８２記載のパケットモニタ。
［態様８５］前記最下部の内容アドレス可能なメモリセルが最も長く未使用であるキャッシュメモリ要素を指すように、前記内容アドレス可能なメモリセル・コントローラが構成される態様８４記載のパケットモニタ。
［態様８６］前記最上部の内容アドレス可能なメモリセルから始まる内容アドレス可能なメモリセル各々のアドレスおよびポインタ出力が、次の内容アドレス可能なメモリセルのアドレスおよびポインタ入力に結合され、最後の次の内容アドレス可能なメモリセルは最下部の内容アドレス可能なメモリセルであり、キャッシュヒットが起こった場合に、ヒットを引き起こした内容アドレス可能なメモリセルのアドレスおよびポインタ内容がスタックの最上部の内容アドレス可能なメモリセルに入れられ、アサートされた一致出力を生成した内容アドレス可能なメモリセルより上の内容アドレス可能なメモリセルのアドレスおよびポインタ内容は下にシフトされ、最も長く未使用であるキャッシュメモリ要素が最下部の内容アドレス可能なメモリセルによって指示され最も最近使用したキャッシュメモリ要素が最上部の内容アドレス可能なメモリセルによって指示されるよう利用の最近さに従って内容アドレス可能なメモリセルが順序付けられるように、前記アドレス可能なコンテンツメモリセルコントローラが構成される態様８５記載のパケットモニタ。
［態様８７］前記探索エンジンに結合され、前記探索エンジンによる探索の結果が前記受信したパケットがあるフローエントリに属するというものである場合にフローの状態を判定し、前記受信したパケットが前記フローエントリデータベース内のフローに属していなかった場合に初期状態を設定するよう構成された状態判定手段を更に有し；
前記状態プロセッサは、前記探索エンジンにおよび前記状態判定手段に結合され、前記パケットが既存のフローからのものであった場合に、前記フローの最後に遭遇した状態から始めて前記フローの状態について指定されたゼロ個以上の状態作業を実行し、前記パケットが既存のフローからのものであった場合に、新たなフローの初期状態に要求されるゼロ個以上の状態作業を実行する態様４１記載のパケットモニタ。
［態様８８］前記状態プロセッサが実行するよう構成されている１組の可能な状態作業が、パケット部分における１つ以上のパターンを探索することを含む態様８７記載のパケットモニタ。
［態様８９］前記分解サブシステムが、前記接続点を通過する総てのパケットをリアルタイムで処理する態様８８記載のパケットモニタ。
［態様９０］前記状態プロセッサがプログラム可能であり、前記分解サブシステムが前記状態プロセッサに結合された状態パターン及び作業メモリを更に含み、前記状態作業メモリが状態パターン及び作業のデータベースを格納する態様８７記載のパケットモニタ。
［態様９１］前記パケット捕捉装置，前記状態プロセッサおよび前記探索エンジンに結合されるバッファを更に有し、前記バッファは前記受信したパケットの少なくとも選択された部分を受け入れるよう構成されている、態様８７記載のパケットモニタ。
［態様９２］前記状態プロセッサが、バッファ内容の中にＮＲ個のユニットからなる参照ストリングを探索するよう構成された探索装置を含み、当該探索装置は：
第１参照ストリングの前記ＮＲ個のユニットを受信するよう構成された第１参照ストリングレジスタ；
直列に結合され且つ前記バッファに結合された１つ以上のターゲットデータレジスタであって、前記ターゲットデータレジスタは前記バッファから内容を受信するよう構成されている１つ以上のターゲットデータレジスタ；および
第１の複数の比較器群であって、前記ターゲットデータレジスタ内の１組の開始位置の各々に一つの比較器群が対応し、特定の開始位置の比較器群が、前記第１参照レジスタの各ユニットと前記特定の開始位置から始まる前記ターゲットデータレジスタのＮＲ個のユニットとに結合され、前記第１参照レジスタ内容と、前記特定の開始位置から始まる前記ターゲットデータレジスタのＮＲ個の連続するユニットの対応する内容とを比較する第１の複数の比較器群；
を有し、各比較器群は、対応する異なる開始位置から始まる前記ターゲットデータの中での前記第１参照ストリングの一致の有無を示し、前記第１の複数の比較器群は、前記開始位置のうち任意のもので始まる前記ターゲットデータレジスタに前記第１参照ストリングが含まれているか否かを並列的に示す態様９１記載のパケットモニタ。
［態様９３］コンピュータネットワーク上の接続点を通過するパケットに対してプロトコル固有の作業を実行する方法であって、当該方法は：
前記パケットを受信する段階；
階層モデルに従う複数のプロトコルに関する１組のプロトコル記述を受信する段階であって、特定の階層レベルにおける特定のプロトコルに関するプロトコル記述は：
前記特定のプロトコルの少なくとも１つの子プロトコルが存在する場合に、該特定のプロトコルのその１つ以上の子プロトコルを含み、前記パケットは、前記特定のプロトコルのゼロ個以上の特定の子プロトコルについて、前記特定の子プロトコルに関連する前記パケット中の１つ以上の場所に情報を含み、
前記プロトコル記述は、前記特定のプロトコルのゼロ個以上の子プロトコルに関連する情報が格納される前記パケット内の１つ以上の場所を含み，および
前記プロトコル記述は、少なくとも１つのプロトコル固有の実行すべき作業が存在する場合に、前記特定の階層レベルにおける特定のプロトコルに関して、前記パケットに対して実行されるべき１つ以上のプロトコル固有の作業を含むところの段階；および
前記パケットの基本プロトコルおよび前記パケットで使用される前記プロトコルの子に基づく前記１組のプロトコル記述によって特定される前記パケットに対する前記プロトコル固有の作業を実行する段階；
を有する方法。
［態様９４］プロトコル固有の作業を実行する段階が、前記子に対するゼロ個以上の子に関して繰り返し実行される態様９３記載の方法。
［態様９５］当該方法がパケットの内容に従って様々なプロトコルに適応するように、プロトコル固有の作業を実行する段階で実行されるプロトコル固有の作業が前記パケットの内容に依存する態様９３記載の方法。
［態様９６］メモリ内にデータベースを格納する段階を更に有し、前記データベースは、前記１組のプロトコル記述から生成され、可能なプロトコルに関する情報を含むデータ構造を有し、任意のプロトコルに対して子プロトコル関連情報を探索するために組織され、前記データ構造の内容は１つ以上のインデックスの組によって指示され、前記データベースエントリは有効性の指示を含むインデックス値の特定の組によって指示され、
前記子プロトコル関連情報は子認識パターンを含み、前記プロトコル特有作業を実行する段階は、基本階層から始まる任意の特定のプロトコル階層レベルにおいて、前記子フィールドに関する前記特定のプロトコルにおける前記パケットを探索し、該探索は、有効なエントリが見出されるまで前記データ構造を指示することを含み、前記データ構造は前記インデックスの組を使った高速検索用に構成されている、態様９３記載の方法。
［態様９７］前記プロトコル記述がプロトコル記述言語で用意され、前記方法が、前記データベースを作成するためにプロトコル記述言語の記述をコンパイルする段階を更に有する態様９６記載の方法。
［態様９８］前記データ構造が、各プロトコルに対して少なくとも１つのアレイの１組のアレイを有し、各アレイは第１インデックスによって識別され、各アレイは、子プロトコル関連情報が格納される前記パケット内の場所である第２インデックスによって更に指示され、前記データ構造における有効なエントリを見出すことが、識別されたプロトコルに関する子認識パターンを見出すために前記パケット内の前記場所を与える、態様９６記載の方法。
［態様９９］各アレイは子プロトコル関連情報が格納される前記パケット内の領域の大きさである第３インデックスによって更に指示され、前記データ構造における有効なエントリを見出すことは、前記子認識パターンを見出すために前記パケットにおける前記場所および前記領域の大きさを与えることを特徴とする態様９８記載の方法。
［態様１００］前記データ構造における有効エントリのまばらさ(sparseness)を利用した圧縮手法に従って前記データ構造が圧縮される態様９９記載の方法。
［態様１０１］前記圧縮手法が、競合する共通エントリを有しない２つ以上のアレイを結合する態様１００記載の方法。
［態様１０２］前記データ構造が各プロトコルに対して少なくとも１つのテーブルの１組のテーブルを有し、各テーブルは、第１インデックスによって識別され、各テーブルは更に、前記子認識パターンである第２インデックスによって指示され、前記データ構造は、各プロトコルに対して、子プロトコル関連情報が格納される前記パケット内の場所を与えるテーブルを更に含み、前記データ構造における有効なエントリを見出すことが、識別されたプロトコルに関する子認識パターンを見出すために前記パケット内の前記場所を与える態様９６記載の方法。
［態様１０３］テーブルの前記組における有効エントリのまばらさを利用した圧縮手法に従って前記データ構造が圧縮される態様１０２記載の方法。
［態様１０４］前記圧縮手法が、競合する共通エントリを有しない２つ以上のテーブルを結合する態様１０３記載の方法。
［態様１０５］前記プロトコル固有の作業が、前記パケットの選択された部分を抽出し、会話フローに属するものとして前記パケットを識別するために前記選択された部分の関数を形成するための前記パケットに対する１つ以上の分解および抽出作業を含む、態様９３記載の方法。
［態様１０６］前記プロトコル記述が、プロトコル記述言語で用意される態様９３記載の方法。
［態様１０７］プロトコル記述言語の記述をコンパイルしてデータベースを作成し、前記データベースをメモリ内に格納する段階を更に有し、前記データベースは、前記１組のプロトコル記述から生成され、可能なプロトコルに関する情報を含むデータ構造を有し、任意のプロトコルに対して子プロトコル関連情報を探索するように組織され、前記データ構造の内容は１つ以上のインデックスの組によって指示され、前記データベースエントリは有効性の指示を含むインデックス値の特定の組によって指示され、
前記子プロトコル関連情報は子認識パターンを含み、
前記プロトコル固有の作業を実行する段階は、基本階層から始まる任意の特定のプロトコル階層レベルにおいて、前記子フィールドに関する前記特定のプロトコルにおける前記パケットを探索し、該探索は、有効なエントリが見出されるまで前記データ構造を指示することを含み、前記データ構造は、前記インデックスの組を利用して高速探索されるよう構成される、態様１０６記載の方法。
［態様１０８］以前に遭遇した会話フローに関する少なくとも１つフローエントリをフローエントリデータベースが含む場合に、ゼロ個以上のフローエントリを、以前に遭遇した会話フロー各々について少なくとも１つのフローエントリで含むフローエントリデータベースを探索する段階であって、該探索は、前記選択されたパケット部分の少なくとも一部を利用し、前記パケットが既存のフローエントリに一致するか否かを判定する段階；
前記パケットが既存のフローのものであった場合、前記パケットを発見された既存のフローに属するものとして分類する段階；および
前記パケットが新たなフローのものであった場合、前記新たなフローのための新規フローエントリであって、将来のパケットが該新規フローエントリのものであると識別されるための識別情報を含む新規フローエントリを、フローエントリデータベースに格納する段階；
を有し、前記分解および抽出作業が、少なくとも１つのパケットヘッダの内容に依存しない、或いはゼロ個以上のパケットヘッダの内容に依存する態様１０５記載の方法。
［態様１０９］前記プロトコル固有の作業が、更に、前記パケットの前記フローの前記状態の関数である１つ以上の状態処理作業を含む態様１０５記載の方法。
［態様１１０］前記プロトコル固有の作業が、前記パケットの前記フローの前記状態の関数である１つ以上の状態処理作業を含む態様９３記載の方法。
［態様１１１］コンピュータネットワーク上の接続点を通過するパケットの内容を処理するプロセッサであって：
前記接続点を通過する各パケットの前記内容の少なくとも一部を受信するバッファ；
状態プロセッサに対する命令群のうちの１つ以上の命令を含むメモリ；
前記バッファに結合された算術論理装置；
前記算術論理装置に及び前記命令メモリに結合され、命令をデコードする制御ブロック；及び
前記命令メモリに及び前記算術論理装置に結合され、前記メモリ内の処理すべき次の状態プロセッサ命令を示すプログラムカウンタ；
を有し、前記算術論理装置は、パケットの内容の中で参照ストリングを探索する１つ以上の比較器を有する探索装置を含むプロセッサ。
［態様１１２］前記状態プロセッサが、前記接続点を通過する全パケットの内容をリアルタイムで処理するよう構成されている、態様１１１記載のプロセッサ。
［態様１１３］前記命令群が、前記算術論理装置の前記探索装置を呼び出し、前記パケットの或る範囲内における未知の位置から始まる前記パケット中の特定の参照ストリングを探索させる命令を含む態様１１１記載のプロセッサ。
［態様１１４］前記探索装置が、パケットの内容中で、一群の参照ストリングのうちの任意のものを探索するよう構成され、前記命令群が、前記探索装置を呼び出し、前記パケットの或る範囲内における未知の位置から始まる、前記パケット中の、特定の一群の参照ストリングのうちの任意のものを探索させる命令を含む態様１１１記載のプロセッサ。
［態様１１５］ターゲットデータ内の一群の開始位置のうちの任意のものから始まる前記ターゲットデータ中のＮＲ個のユニットからなる参照ストリングを探索する探索装置であって：
第１参照ストリングの前記ＮＲ個のユニットを受信するよう構成された第１参照レジスタ；
直列に結合され前記ターゲットデータを受信する１つ以上のターゲットデータレジスタ；および
第１の複数の比較器群であって、前記開始点の各々に一つの比較器群が対応し、特定の開始位置からの比較器群は、前記第１参照レジスタの各ユニットと前記特定の開始位置から始まる前記ターゲットデータレジスタのＮＲ個のユニットとに結合され、前記第１参照レジスタ内容と、前記特定の開始位置から始まる前記ターゲットデータレジスタのＮＲ個の連続するユニットの対応する内容とを比較する第１の複数の比較器群；
を有し、各比較器群は対応する異なる開始位置から始まる前記ターゲットデータの中で前記第１参照ストリングの一致の有無を示すよう動作し，前記第１の複数の比較器群は、前記開始位置のうちの任意のもので始まる前記ターゲットデータレジスタ内に前記第１参照ストリングが含まれているか否かを並列に示すよう動作する、
探索装置。
［態様１１６］１組の可能な開始位置が、Nstart個の位置を含み、前記１つ以上のターゲットデータレジスタが前記ターゲットデータの少なくともＮＲ＋Nstart−１個のユニットを受信するよう直列に結合され、前記第１の複数の比較器群が、Nstart個の開始位置各々について１つの比較器群でNstart個の比較器群を含む態様１１５記載の探索装置。
［態様１１７］前記ターゲットデータレジスタの各々は、データのNstart個のユニットを保持する態様１１６記載の探索装置。
［態様１１８］前記ターゲットデータのNstart個のユニットが前記ターゲットデータレジスタ内に１クロックサイクルでクロック入力されるように前記ターゲットデータレジスタが動作し、前記第１の複数の比較器群は、前記第１参照ストリングが、Nstart個の開始位置の何れかにおいて開始するターゲット領域中にあるか否かを１クロックサイクルで示すよう動作する、態様１１７記載の探索装置。
［態様１１９］オフセットNoffsetを特定するための手段を更に有し、第１の動作クロックサイクルの間は前記第１のNoffset個の開始位置が無視され、前記第１の複数の比較器群は、前記第１参照ストリングが、最初のNoffset個の開始位置の後に始まる前記第１データレジスタのNstart−Noffset個のの開始位置のいずれかで始まるターゲット領域中にあるか否かを、前記第１クロックサイクルで示し、以後のクロックサイクルにおいて総てのNstart個のの開始位置が処理され、１つ以上のクロックサイクルにおいて、前記探索装置が、最初のNoffset個のユニット以外の任意の場所で始まるターゲットデータ中に前記第１参照ストリングがあるか否かを示すよう動作する、態様１１８記載の探索装置。
［態様１２０］各比較器群がＮＲ個の隣接する比較器を有し、各比較器は参照ユニット入力、ターゲットユニット入力および一致を示す出力を有し、前記参照およびターゲットデータ入力が一致し且つ先行する比較器の出力が一致を示す場合に比較器の出力がアサートされるように、各比較器は先行する比較器の出力に結合される態様１１５記載の探索装置。
［態様１２１］１つ以上の更なる参照ストリングのＮＲ個のユニットを受信する１つ以上の更なる参照レジスタ；および
1つ以上の更なる複数の比較器群であって、対応する複数の開始位置のそれぞれについて一つの比較器群があり、前記更なる複数のうちの各特定の比較器群が、対応する更なる参照レジスタの各ユニットと前記特定の比較器群の開始位置から始まる前記データレジスタのＮＲ個のユニットとに結合され、対応する更なる参照レジスタ内容と、前記特定の比較器群の開始位置から始まる前記ターゲットデータレジスタのＮＲ個ユニットとを比較する1つ以上の更なる複数の比較器群；
を更に有し、前記探索装置が、前記開始位置のうち任意のものから始まる前記ターゲットデータレジスタの内容中において、ＮＲ個のユニットの前記第１又は更なる参照ストリングのうちの任意のものを探索するよう動作する、態様１１５記載の探索装置。
［態様１２２］各比較器群がＮＲ個の隣接する比較器を有し、各比較器は参照ユニット入力、ターゲットデータユニット入力および一致を示す出力を有し、前記参照およびターゲットデータ入力が一致し先行する比較器の出力が一致を示す場合に比較器の出力がアサートされるように、各比較器は先行する比較器の出力に結合される態様１２１記載の探索装置。
［態様１２３］各比較器群はＮＲ個の隣接する比較器を有し、各比較器は参照ユニット入力、ターゲットデータユニット入力、イネーブル入力および一致を示す出力を有し、前記参照およびターゲットデータ入力が一致し前記イネーブル入力がアサートされる場合に比較器の出力がアサートされ、
特定の開始位置に関する特定の比較器群に対して、隣接する比較器の参照入力が前記参照レジスタの隣接するユニットに結合され、隣接する比較器のターゲットデータ入力が、特定の開始位置から始まるターゲットデータレジスタの隣接するユニットに結合され、その比較器群の第1の比較器がイネーブルされ、各比較器のイネーブル入力が先行する比較器の出力に結合され、参照ストリングのＮＲ個のユニットおよび前記ターゲットデータのＮＲ個のユニットが合致する場合に、最後の比較器の出力がアサートされる態様１１５記載の探索装置。
［態様１２４］１ユニットが１バイトである態様１１５記載の探索装置。
［態様１２５］前記複数の比較器群の最後の比較器出力が、前記ターゲットデータ中に前記参照ストリングの一致が生じたか否かおよびその場所を示す出力を有する優先選択器に結合される態様１２３記載の探索装置。
［態様１２６］ＮＲが１６バイトである態様１２４記載の探索装置。
［態様１２７］ＮＲが１６バイトであり、データレジスタの各々がNstartバイトであり、前記探索装置が前記第１データレジスタ内の任意の場所から始まる一致を示すよう動作する態様１１６記載の探索装置。
［態様１２８］ターゲットデータストリーム内でＮＲ個のユニットからなる参照ストリングを探索するよう構成された探索装置であって：
入力のＮＲ個の対と、前記入力のＮＲ個の対の各対の一致を示す出力とを有する第１のＮＲユニット比較器；
前記参照ストリングの値を示し行列の第１の軸を定めるＮＲ個の接続部と、前記ターゲットデータの値を示し前記第１の軸に垂直な行列の第２の軸を定める、前記ターゲットデータの第１の開始位置から始まり終了位置で終了するＮＲ個の接続部；
を有し、前記ターゲットデータのＮＲ個の接続部が、前記ＮＲ個の参照ストリングの接続部と比較されるように、前記第１の比較器が前記行列の対角線に沿って並べられる、
探索装置。
［態様１２９］前記行列における前記ターゲットデータ接続部に平行に且つ隣接して、且つ前記終了位置から始まる１つ以上の付加的な接続部；および
前記付加的な接続部の各々について及びそれらに対応する付加的なＮＲユニット比較器であって、各付加的な比較器は前記第１比較器に平行であり且つ前記行列の中で前記付加的な接続部に向けてシフトされる付加的なＮＲユニット比較器；
を有し、各付加的な比較器が、前記参照ストリングを、異なる開始点から始まる前記ターゲットデータのＮＲ個のユニットの連続する値の異なる組と比較する態様１２８記載の探索装置。
［態様１３０］１つ以上の更なるＮＲユニット比較器群；および
前記更なるＮＲユニット比較器群に対応する更なる接続部群であって、前記更なる接続部が１つ以上の付加的な行列を定め、前記第１軸に沿う更なる接続部群の各々が、前記第１の軸に沿う１つ以上の対応する更なる参照ストリングの値を示し、ＮＲ個の接続部が前記第２の軸に沿う前記ターゲットデータの値を示す、更なる接続部群；
を有し、付加的な比較器群の各々が、前記参照ストリングのうち対応するものと、異なる開始位置から始まる前記ターゲットデータのＮＲ個の隣接する値の異なる組を比較する態様１２９記載の探索装置。
［態様１３１］外部メモリの１つ以上の要素を探索するキャッシュシステムであって：
前記外部メモリに結合された１組のキャッシュメモリ要素であって、各キャッシュメモリ要素は前記外部メモリの要素を入力するための入力ポートを含み、前記外部メモリの要素の入力を格納する１組のキャッシュメモリ要素；
上部のアドレス可能なコンテンツメモリセルから下部のアドレス可能なコンテンツメモリセルへの接続の順序に従って接続された１組のアドレス可能なコンテンツメモリセルであって、アドレス可能なコンテンツメモリセル各々が、前記キャッシュメモリ要素の１つに対するアドレスおよびポインタを含み、アドレス可能なコンテンツメモリセル各々は：
入力を有する一致回路であって、前記入力がアドレス可能なコンテンツメモリセルのアドレスと同一である場合にアドレス可能なコンテンツメモリセルが一致出力をアサートし、アサートされた一致出力はヒットを示す一致回路，
アドレスおよびポインタを受け入れるアドレス可能なコンテンツメモリセル，および
アドレス可能なコンテンツメモリセルのアドレス出力およびアドレス可能なコンテンツメモリセルのポインタ出力
を含む１組のアドレス可能なコンテンツメモリセル；
前記アドレス可能なコンテンツメモリセルの組に結合されたアドレス可能なコンテンツメモリセルコントローラ；および
前記アドレス可能なコンテンツメモリセルコントローラ，前記キャッシュメモリの組および前記外部メモリに結合されたメモリコントローラ
を含み、前記一致回路入力への入力が、前記入力に等しいアドレスを含む任意のアドレス可能なコンテンツメモリセルで一致出力を生じさせるように、前記アドレス可能なコンテンツメモリセルの一致回路入力が結合され、および
前記アドレス可能なコンテンツメモリセルコントローラが、特定のＣＡＭが指示するキャッシュメモリ要素が時間と共に変化するキャッシュシステム。
［態様１３２］前記下部のアドレス可能なコンテンツメモリセルが最も長く未使用であるキャッシュメモリ要素を指示するように、前記ＣＡＭコントローラが形成され、前記アドレス可能なコンテンツメモリセルコントローラは、最も長く未使用であるキャッシュメモリ要素が、処理される第１メモリ要素であるようにアドレス可能なコンテンツメモリセルコントローラが形成される態様１３１記載のキャッシュシステム。
［態様１３３］前記上部のアドレス可能なコンテンツメモリセルから始まるアドレス可能なコンテンツメモリセル各々のアドレスおよびポインタ出力が、次のアドレス可能なコンテンツメモリセルのアドレスおよびポインタ入力に結合され、次のアドレス可能なコンテンツメモリセルの内の最後が下部のアドレス可能なコンテンツメモリセルであり、キャッシュヒットが起こった場合に、ヒットを引き起こしたＣＡＭのアドレスおよびポインタの内容はスタックの上部のアドレス可能なコンテンツメモリセルに配置され、アサートされた一致出力を引き出したアドレス可能なコンテンツメモリセルより上側のＣＡＭのアドレスおよびポインタの内容はシフトダウンされ、下部のアドレス可能なコンテンツメモリセルよって指示される最も長く未使用であるキャッシュメモリ要素と共におよび上部のアドレス可能なコンテンツメモリセルによって指示される最も長く未使用であるキャッシュメモリ要素と共に、最近の利用度に従ってアドレス可能なコンテンツメモリセルが順序付けられる態様１３２記載のキャッシュシステム。
［態様１３４］最初に処理されるキャッシュメモリエントリである最も長く未使用であるエントリと共に、キャッシュメモリ要素の置換が、利用の最新性とは逆の順序に従って行われるように、アドレス可能なコンテンツメモリセルコントローラが形成される態様１３３記載のキャッシュシステム。
［態様１３５］各メモリ要素がメモリのページである態様１３１記載のキャッシュシステム。
［態様１３６］各キャッシュメモリ要素は、それがダーティであるか否かの指標と共に用意され、前記アドレス可能なコンテンツメモリセルコントローラは、前記のダーティな内容を前記外部メモリにバックアップすることによって、ダーティキャッシュメモリ要素をクリーニングする特徴とする態様１３１記載のキャッシュシステム。
［態様１３７］最も長く未使用であることを指針にする置換法に従って、キャッシュ内容が置換される必要が生じるまで、キャッシュメモリ要素の内容がクリーニング後も維持される態様１３６記載のキャッシュシステム。
［態様１３８］各キャッシュメモリ要素は、それがダーティであるか否かの指標と共に用意され、前記アドレス可能なコンテンツメモリセルコントローラは、前記のダーティな内容を前記外部メモリにバックアップすることによって、ダーティキャッシュメモリ要素をクリーニングする特徴とする態様１３２記載のキャッシュシステム。
［態様１３９］前記アドレス可能なコンテンツメモリセルコントローラが、前記キャッシュメモリ要素の内容を置換するのに先立って、ダーティキャッシュメモリ要素をクリーニングする態様１３８記載のキャッシュシステム。
［態様１４０］前記アドレス可能なコンテンツメモリセルコントローラが、前記キャッシュメモリ要素の内容を置換するのに先立って、ダーティキャッシュメモリ要素をクリーニングする態様１１９記載のキャッシュシステム。
［態様１４１］各キャッシュメモリ要素は、それがダーティであるか否かの指標と共に用意され、前記アドレス可能なコンテンツメモリセルコントローラは、前記のダーティな内容を前記外部メモリにバックアップすることによって、利用の最新性とは逆の順序で、ダーティキャッシュメモリ要素をクリーニングする態様１３３記載のキャッシュシステム。
［態様１４２］前記アドレス可能なコンテンツメモリセルコントローラがアイドルのときはいつでも、アドレス可能なコンテンツメモリセルコントローラは、利用の最新性とは逆の順序で自動的にクリーニングを進める態様１４１記載のキャッシュシステム。
［態様１４３］外部メモリの１つ以上の要素を探索するキャッシュシステムであって：
前記外部メモリに結合された１組のキャッシュメモリ要素であって、各キャッシュメモリ要素は前記外部メモリの要素を入力するための入力ポートを含み、外部メモリ要素に入力を格納する１組のキャッシュメモリ要素；および
キャッシュメモリ要素の１つに対するアドレスおよびポインタを含む１組のアドレス可能なコンテンツメモリセルであって、前記入力がアドレス可能なコンテンツメモリセルのアドレスと同一である場合にアドレス可能なコンテンツメモリセルが一致出力をアサートする入力を有する一致回路を含む１組の内容アドレス可能なメモリセル；
を有し、特定のアドレス可能なコンテンツメモリセルの指示するキャッシュメモリ要素が時間と共に変化するキャッシュシステム。
［態様１４４］アドレス可能なコンテンツメモリセルが上部から下部への順序で結合され、下部のアドレス可能なコンテンツメモリセルは最も長く未使用であるキャッシュメモリ要素を指示する態様１４３記載のキャッシュシステム。
【図１】
0005517821.tif 000066
【図２】
0005517821.tif 000067
【図３】
0005517821.tif 000068
【図４】
0005517821.tif 000069
【図５】
0005517821.tif 000070
【図６】
0005517821.tif 000071
【図７】
0005517821.tif 000072
【図８】
0005517821.tif 000073
【図９】
0005517821.tif 000074
【図１０】
0005517821.tif 000075
【図１１】
0005517821.tif 000076
【図１２】
0005517821.tif 000077
【図１３】
0005517821.tif 000078
【図１４】
0005517821.tif 000079
【図１５】
0005517821.tif 000080
【図１６】
0005517821.tif 000081
【図１７Ａ】
0005517821.tif 000082
【図１７Ｂ】
0005517821.tif 000083
【図１８Ａ】
0005517821.tif 000084
【図１８Ｂ】
0005517821.tif 000085
【図１９】
0005517821.tif 000086
【図２０】
0005517821.tif 000087
【図２１】
0005517821.tif 000088
【図２２Ａ】
0005517821.tif 000089
【図２２Ｂ】
0005517821.tif 000090
【図２３Ａ】
0005517821.tif 000091
【図２３Ｂ】
0005517821.tif 000092
【図２４】
0005517821.tif 000093
【図２５】
0005517821.tif 000094
【図２６】
0005517821.tif 000095
【図２７】
0005517821.tif 000096
【図２８】
0005517821.tif 000097