JP2012157056A - プロトコルエミュレータ - Google Patents

Abstract

【課題】ユーザーが再コンパイルを要することなく新たな能力をプロトコルエミュレーションスイーツに付加することが可能であり、ユーザーからはシステムのシームレスな部分であるように見えるようにした、新たなシステムを提供する。
【解決手段】プロトコルエミュレーション・システム２００は、一般フォーマットを用いてプロトコルメッセージ内にフィールドを記述する少なくとも１つの記述と、少なくとも１つの記述を機械読み取り可能なテンプレートへと変換するアプリケーションと、テンプレートに基づいてプロトコルメッセージを作成するプロトコル有限状態機械と、を有する。
【選択図】図２

Description

本発明は、プロトコルエミュレータに関する。

ルータ等のネットワークデバイスは、誤送信や重大エラーを最小限に抑えられるように徹底的にテストされるものである。市場には様々なテスト機器が出回っており、その中には本願の譲受人であるアジレント・テクノロジー社（Agilent Technologies）から出されているＲＯＵＴＥＲ ＴＥＳＴＥＲも含まれる。これらのテスト機器は、代表的にはシミュレーションされた様々な入力に対するルータ応答をモニタするものである。

ルーティング処理を簡単に述べると、ノードが可能な全宛先への経路を探すことである。ルーティングは第一層（物理層）から上の全てに存在する。しかしながら、多くの人々がよく知るルーティングは、第三層（ネットワーク層）で生じているものであり、本願においては第三層の、より具体的にはインターネットプロトコル（ＩＰ）ルーティングのみを指すものとする。ルータはテーブルを使ってどこにパケットを送信するかを決定する。これらのテーブルの更新は、ルーティングプロトコルが実施する機能である。

ルーティングプロトコルは、世界中のルータ間でのルーティング情報の交換し、各ルータの異種だが概ね整合性のあるルーティングテーブルを通じてネットワークの共通認識を提供するのを促進する。ルーティングテーブルは、サイズに関わりなくルータがネットワーク上の各宛先へと達する上で必要となる全ての情報を記憶している。ネットワークにおけるルーティングテーブルには、情報を配信する為に使われる様々なルーティングプロトコルがあり、その中にはＢＧＰ、ＯＳＰＦ、ＲＩＰ及びＩＳＩＳが含まれる。ルータのパフォーマンスを改善する為に古いプロトコルはしばしば拡張され、そして新たなプロトコルが作られ続けている。一般に、新たなプロトコルはまず、機器製造業者により開発されるもので、事実上の所有権を発生するものである。当該業界の標準化組織が後にそのプロトコルを採用することも多い。

周知のルータテスタは、ネットワーク上に存在する実データの典型であるデータのうち特別に作成した「テストパケット」を用いて、ネットワークトラヒックをシミュレートする。テストパケットは被検ネットワークを介してネットワークデバイスへと送られる。トラヒックシミュレータ・システム（ＲＯＵＴＥＲ ＴＥＳＴＥＲを含む）により試験されるパラメータとしては、ルーティング検証、負荷下でのクオリティ・オブ・サービス（ＱｏＳ）レベルの達成度、他のデバイスとの相互作用の適正度が含まれる。これらのいわゆる「パケットブラスター」と呼ばれるものの多くは、更にネットワークデバイスがどれだけプロトコルに即していられるかの能力をプロトコルに準じてメッセージを形成・伝送することによりテストすることもできるものである。そのようなメッセージはプロトコルメッセージとして知られている。

図１はトラヒックシミュレータ・テストシステム１００のブロック図である。より具体的には、トラヒックシミュレータ・テストシステム１００は、アジレント・テクノロジー社が提供しているＲＯＵＴＥＲ ＴＥＳＴＥＲを概略的に示したものである。しかしながらＲＯＵＴＥＲ ＴＥＳＴＥＲは、ルータテストシステムの一例にしか過ぎないものであり、具体的にはエンタープライズ、メトロ／エッジ、コアルーティング、及び光ネットワークデバイスの性能を検証する為に、マルチポートトラヒック生成、プロトコルエミュレーション（Protocol Emulation）、及び解析テストシステムとして発表されているものである。このシステムは一般に、この例においてはルータ１０４である被検システムに接続される複数のプロトコルエミュレーションカード１０２ｎを有する。プロトコルエミュレーションカード１０２ｎの各々は、一般にプロセッサ、関連メモリ、及びＩ／Ｏを有する。例えばウィンドウ環境を走らせるＰＣのようなコンピュータ１０６が、プロトコルエミュレーションカード１０２ｎを制御している。コンピュータ１０６は、グラフィカルユーザーインターフェースのようなインターフェース１０８に応答する。

プロトコルエミュレーションカード１０２ｎが生成するテストパケット及びプロトコルメッセージは、業界における多くの標準化組織が定義するような通信プロトコルのルールと解釈に基づいて構築される。一般に、任意の所定のプロトコルに関連するプロトコルメッセージの大部分は、ルータ間のハンドシェーキング（hand shaking、初期接続手順）のプロセスにおいて利用される。ハンドシェーキングプロセスが定義済み状態（defined state）になると、殆どのルータ及びプロトコルエミュレータは有限状態機械（finite state machine）を使って様々なプロトコルメッセージに応答する。

トラヒックシミュレータ・テストシステムに関する現在のソフトウエアアーキテクチャにおいては、グラフィカルユーザーインターフェース、記述（scripting）ＡＰＩ、コンフィギュレーション及び制御コンポーネント、並びにプロトコル状態機械自体を含むプロトコルエミュレーション・ソリューションのうち全ての部分をハードコーディング（hard-coding）しなければならない。各プロトコルに要求されるハードコーディングには、大量のコード生成に多大な人的資源が投入される結果となっている。

新たなプロトコル又は拡張の導入ペースが速くなると、テストスイーツをタイムリーに提供することがますます困難なものとなる。プロトコルエミュレーションへの新たな変更又は追加は、それぞれにソースコードの修正と、その後の再コンパイル処理を要することになる。プロトコルテスタの顧客は、しばしば未発表プロトコル又は拡張のテストを促進する為にプロトコルエミュレーションの変更能力を要求する。これを実現するには、そのような変更がシステム再コンパイル処理を要することなくできなければならない。

いくつかの既存のプロトコルエミュレータには、プロトコルメッセージに付加できるユーザー定義オブジェクトの使用を通じていくらかのカスタマイズが可能なものもある。しかしながら、このようなカスタマイズは１６進数コードで行われるもので、ユーザーは時に難解なコードに精通していなければならない。更に、そのように定義されたオブジェクトは固定であり、即ちネットワークを活性化するプロセスの間に変えることができないものである。オブジェクトはメインプロトコルメッセージの拡張に限定されており、このことはメッセージ本体の変更ができないことを意味している。

現在、外部からソフトウエアへとコンフィギュレーションすることができる汎用システムを設計する試みがされている。その一例は、この参照により本願に含まれる同時係属中の特許文献１に記載されており、これは外部ＸＭＬプロトコル記述を利用して汎用ＰＤＵ符号化／復号化エンジンを駆動するものである。

米国特許出願第１０／２６６，５０７号明細書

よって本発明の発明者は、ユーザーが再コンパイルを要することなく新たな能力をプロトコルエミュレーションスイーツに付加することが可能であり、ユーザーからはシステムのシームレスな部分であるように見えるようにした新たな装置及び方法に対する必要性を認識するものである。

本発明は、一般的なフォーマットを用いてプロトコルメッセージ内にフィールドを記述する少なくとも１つの記述（description）と、少なくとも１つの記述を機械読み取り可能なテンプレートへと変換するアプリケーションと、テンプレートに基づいてプロトコルメッセージを作成するプロトコル有限状態機械と、を有するプロトコルエミュレーション・システムを提供する。

本発明によれば、ユーザーが再コンパイルを要することなく新たな能力をプロトコルエミュレーションスイーツに付加することが可能である。

プロトコルエミュレーションテストシステムのブロック図である。 本発明の推奨される実施例に基づいてプロトコルメッセージを構築する為のアーキテクチャのブロック図である。 本発明の一実施例に基づいて構築されたグラフィカルユーザーインターフェースの画面を示す図である。

以下の本発明の実施例の詳細説明を添付図と共に参照することにより、本発明を理解することができる。

以下の説明において、要素に隣接する小文字ｎは、明細書中で要素符号に隣接する非イタリック体の文字を用いて表される特定の要素ではなく、非特定的に要素を表すものである。または修飾文字をつけたその符号で説明した全ての事例の一般的な集合を表すものである。

以下、本発明の実施例を参照するが、これらは添付図に描かれているもので、全ての図を通じて同様の符号は同様の要素を表すものである。以下に示す本発明の方法に準じた説明は、コンピュータ読み取り可能媒体、関連プロセッサ、データ生成・取得カード等の中におけるデータビット処理のルーチン及び記号により実現することができる。本願においても一般的にも、ルーチンと言う場合、所望の結果を導き出すステップ又は動作の順序であると理解されるものであり、「プログラム」、「オブジェクト」、「機能」、「サブルーチン」及び「手順」という語を含むものである。これらの説明及び表現は、当業者が他の当業者にその作用の本質を効果的に伝える為に使用する手段である。便宜上、「ネットワーク」という語は、以下の説明及び請求項においては、データのテストパケットを使用してテストすることが可能な、通信ネットワーク、ネットワークデバイス、他の通信デバイス、及び通信システムのいずれか１つ又は複数の態様を意味する語として扱うものとする。

方法を構成する実施例は、Ａｇｉｌｅｎｔ ＲＯＵＴＥＲ ＴＥＳＴＥＲと同様の構成を持つルータテスタに実現されるものとして説明するが、しかしながら本願に記載の方法は様々なルータテスタのいずれにおいても作動することができるものである。より明確に言えば、本願に示す方法はいずれの特定のデバイスにも固有に関係するものではなく、むしろ本願における教示内容に基づいて様々なデバイスを利用することができるものである。特に本願に記載した、あるデバイスから他のデバイスへとデータを伝送する為の方法は、ルータテスタ機能に関連して説明してはいるものの、これはデータコミュニケーション分野に広く適用することができるものである。本願に記載した機能を実施する機械には、アジレント・テクノロジー社、ヒューレット・パッカード社（Hewlett Packard）及びテクトロニクス社（Tektronix, Inc.）やその他の通信機器製造企業により製造されるものが含まれる。

本願に記載のソフトウエアに関しては、当業者であれば本願にまとめた手順を実施するソフトウエアを作成する為のプラットフォーム及び言語には様々なものが存在することは周知である。本発明の実施例は、Ｃ^＋＋を含む数あるＣ言語のいずれを利用しても実現することができるものである。しかしながら、当業者には同じく周知のように、厳格なプラットフォーム及び言語の選択は、実際に構築されるシステムの詳細により決まるものであり、あるタイプのシステムにはうまく適合するものであっても、他のシステムにとっては非効率的である場合もある。また、本願に記載のルーチン及び計算は、コンピュータ上のソフトウエアにより実行されるものとは限られず、これはハードウエアプロセッサにより実現されるものであっても良い。例えば、ルーチン及び計算は、ＡＳＩＣＳ或いはＦＧＰＡ中のＨＤＬ（Hardware Design Language、ハードウエア記述言語）で様々なデザインツールを用いて実現することも可能である。

本願出願者は、プロトコルエミュレーションのある部分は一般的な手法での定義に向いている一方で、他の構成要素はスケーラビリティとパフォーマンスという観点からハードコード化されるのにより一層適していると判断している。一般的な手法で定義することができる部分のオンサイト・カスタマイゼーション（on-site customization）を可能とすることにより、顧客はプロトコルエミュレーションに更なる制御性とテスト拡張能力を得ることになるのである。顧客のインタラクションを促進する為に、一般定義部分を、例えばＸＭＬのような読み取りが容易なファイル・フォーマットで提供することができる。このようなＸＭＬファイルは、ＸＭＬで記述された情報への変更を閲覧することができるグラフィカルインターフェースの形成に使用することができる。この情報は、特定のプロトコルエミュレーションの有限状態機械による理解が可能な定義を構築する為に使用される。

図２は、本発明の推奨される実施例に基づいてプロトコルメッセージを構築する為のプロトコルエミュレーション・システム２００のブロック図である。このアーキテクチャ２００は一般に、ホスト２０２とプロトコルエミュレータ２０４とを含んでいる。ホスト２０２は、アプリケーション２０８と共にグラフィカルユーザーインターフェース２０６に応答するコンピュータとして実現されることが一般的である。図２においては複数のアプリケーション２０８ｎが示されているが、本発明の厳密な実現例に応じて、アプリケーション２０８ｎは、単一のアプリケーション、または任意数のアプリケーションとして物理的に又は論理的に実現され得る。プロトコルエミュレータ２０４は一般に、プロトコルメッセージを生成する為に少なくとも１つのテンプレート２１２に応答するプロトコル有限状態機械２１０を含んでいる。コンピュータ２０２は一般に、プロトコルエミュレータ２０４へと命令を供給するクライアントとして働き、プロトコルエミュレータ２０４は一般にコンピュータ２０２の命令に応答するサーバとして働く。

プロトコルメッセージ記述（description）２１５は、ホスト２０２または遠隔ロケーションに局所的に記憶されており、選択されたプロトコルメッセージタイプおよび付随のプロトコルパラメータ・オプションに関するフィールドおよびフィールド関係（field relationship）の全てまたは一部についての少なくとも１つの記述２１５を含んでいる。プロトコルメッセージ記述２１５ｎは、一般的なフォーマット（例えばフィールド記述２１５のフォーマットがプロトコル毎に異なることがない）でプロトコルデータユニット全体又はその一部を表している。プロトコルメッセージ記述２１５が有利であるとされるメッセージ例は、ＢＧＰ４更新メッセージ、ＯＳＰＦリンクステート更新パケット、ＩＳＩＳリンクステート・パケット、ＲＩＰ更新メッセージ、ＬＤＰラベル・マッピング・メッセージ、ＲＳＶＰパス・メッセージ、ＰＩＭジョイン・オア・レジスターメッセージ（PIM Join or Register Message）、ＩＧＭＰメンバーシップ・リポートを含む。

所定プロトコルのプロトコルメッセージ記述２１５ｎは、そのプロトコルに関わる一般的属性を持つプロトコル記述子（descriptor）から始まり、次にそのプロトコルに基づいて生成されるメッセージ中に存在し得るフィールドを各々が記述する複数のフィールド記述子が続く。フィールド記述子は様々な属性情報を含む場合もある。

例えば、そのフィールドに関係する値でフルネームを指定することにより表示することができる。値自体に関しては、長さ、フォーマット及び初期値といった属性を提供することができる。プロトコルメッセージ記述２１５の利便性を更に強化する為に、あるフィールドの値をメッセージ（プロトコルメッセージ記述２１５に基づいて構築される）の複写毎にどのように変化させるかについての命令を設けることができる。特定メッセージ中に繰り返されるフィールドの場合、そのフィールドの値をインスタンス毎にどのように変化させるかが提供されるのである。例えば、増分値を設けることにより一連のネットワーク到達可能性表示子（network reachability indicators）の各々におけるＩＰ値プレフィクス（prefix、接頭部）を調節することができる。

ＸＭＬが記述言語として使用された場合、記述子はタグにより実現されており、これは階層構造が提供されることになるように既知の方法でネストさせる（nest、入れ子にする）ことができる。このような階層構造は、データ構造を通じた迅速で簡単なナビゲーションを提供するグラフィカルユーザーインターフェースの動的作成を助けるものである。

プロトコルメッセージ記述子２１５は、参照により本願に含まれる特許文献１の一般的教示内容に基づいて形成することができる。表１は、ＢＧＰ４更新メッセージ向けのプロトコル定義例を含んでいる。表１に示したデータ構造は、プロトコルメッセージ記述２１５ｎをＸＭＬで表した例を示すものであり、当業者であれば、ここから他のメッセージ用の他のプロトコル定義及び他のプロトコルを作成する為の構造と目的を抽出することが可能である。

新たなプロトコルエミュレーションを作成する為に、アプリケーション２０８ｎは要求されたプロトコルメッセージ記述２１５ｎを取得し、これらをプロトコル参照モデル（protocol reference model）２１４へとロードする。参照モデル２１４は一般に、全ての選択されたプロトコルメッセージ記述２１５ｎに含まれるフィールドを記述するオブジェクト等のデータ構造を持っている。モデルは各プロトコルメッセージ記述２１５ｎを、例えばｅｘｐａｔのようなパブリックドメインＸＭＬパーサー（parser）ソフトウエアを使って構文解析することにより構築することができる。プロトコル参照モデル２１４が構築されると、インスタンス２１６ｎが生成され、ユーザー指定値及び命令を実装される。

インスタンス２１６ｎにより記憶された値を編集する場合、インスタンス２１６ｎはＧＵＩ２０６へと送られる。代わりに、ＧＵＩ２０６がインスタンス２１６ｎの作成を要求しても良い。いずれの場合においても、ＧＵＩ２０６はプロトコル参照モデル２１４中の選択フィールド、プロトコルメッセージ記述２１５ｎ又はインスタンス２１６ｎに基づいてグラフィカルディスプレイを形成する。推奨される実施例においては、ＧＵＩ２０６はプロトコルメッセージ記述２１５が示すネストデータ構造を模倣したツリーを構築して実装している。

図３は、本発明の一実施例に基づいて構成されたグラフィカルユーザーインターフェース２０６のスクリーンを示している。図３に示したような画面を生成するには、例えばプロトコル参照モデル２１４の内容が分析されて表示フィールドとそのフォーマットが識別される。図３に示した例においては、階層データ構造が生成され、エントリ又は表示フィールドを実装されており、ここで各フィールドはツリーのノードである。こうして構成されたツリー構造は、データノードがそれらの記述子に基づいてフォーマットされている従来の階層的表示として表現することができる。

図３に示した例においては、ユーザーが開始値（starting value）、終了値（ending value）、計数値（count）、及びステップ（step）を含む表示フィールドの特定の属性を調節することができ、プロトコルメッセージ記述２１５ｎ（又はより適正にはインスタンス２１６ｎ）の内容に基づいてフィールド毎の制御が可能となっている。例えば、そのフィールドの値が固定（又は他のフィールドに依存するもの）であることを特記する為にある属性を付加することができる。ユーザーがノードを見直してそのユーザーが使用することができるノードを調整すると、グラフィカルユーザーインターフェース２０６はその調整インスタンス２１６ｎをアプリケーション２０８ｎへと戻す。するとアプリケーション２０８ｎはその調整されたインスタンス２１６ｎに基づいてテンプレート２１２ｎを構築するのである。

テンプレート２１２は、プロトコルメッセージの作成に関するプロトコル有限状態機械２１０に対する一群の命令である。プロトコル有限状態機械２１０に使用される、現在ハードコーディングされた命令に対応するように、このテンプレート２１２にはバイナリ（又は１６進）フォーマットを使用するのが有益である。このようにすれば、現行のプロトコル有限状態機械はテンプレートと相互作用させる為の変更において、要求を小さくすることができる。図２を見ると、グラフィカルユーザーインターフェース２０６又はアプリケーション２０８ｎのいずれかを、プロトコルメッセージ記述２１５のコンパイラとして働くように構築することができる。テンプレート２１２は一般に、表２に示した３つの区分を持っている。

テンプレート２１２は一般に、非反復データから成る第一の部分（共通部分（Common Part）と称する）と、異なる値の同様にフォーマットされたデータの反復部分から成る第二の部分（反復部分（Repeating Part）と称する）を含んでいる。各テンプレート２１２ｎは、多数のメッセージを生成可能な基準メッセージ記述を表す。各テンプレート２１２ｎは共通部分を持っており、そして反復部分を持つ場合もある。共通部分は生成されたメッセージのシーケンス全体にわたって異なるフィールドを持つ場合がある。代表的には、共通部分は、トポロジーデータのメッセージヘッダおよび共通属性を表す。ＢＧＰにおいては、更新メッセージの共通部分はメッセージヘッダと経路属性を含む場合がある。反復部分は単一メッセージ中で何度か繰り返されるべきフィールド群を記述している。反復フィールドの１つ以上は、反復毎に定義された様式で変化するものであっても良い。反復部分は一般に、ネットワークトポロジーデータを表している。ＢＧＰにおいては、反復部分には通知すべき何千ものネットワークプレフィクスが含まれる場合がある。

図２に戻るが、各インスタンス２１６はプロトコル要素（protocol element）のベクター（vector）として記憶される。テンプレート２１２はベクターのバイト・ストリング（byte-string）を符号化することにより形成することができる。バイト・ストリングは、プロトコル要素のベクター内で各使用可能フィールドのバイナリ値を連結することにより符号化することができる。ベクター表現（vector representation）と符号化表現（encoded representation）の両方を記憶することが有利な場合がある。このような場合、ＧＵＩ２０６がベクター中の要素を操作すること（例えば値の変更、フィールドのイネーブル（enable）又はディスエーブル（disable））によりインスタンス２１６を更新する場合、対応するバイト・ストリングが更新される。ベクター中のいずれの要素にもフィールド変更子（field modifier）を適用することができる。このフィールド変更子はオフセット、フィールド幅、開始値、増分値又は計数値としてバイト・ストリングに対して符号化することができる。テンプレート２１２は一般に、符号化されたバイト・ストリングを付随したフィールド変更子の一群を含んでいる。

実現可能なオプションとしては、テンプレートが何らかのセッション中に使用されるべきか否かを示すフラグ（又は他のデータ構造）を利用することがあげられる。この場合、いずれかの所定テンプレート２１２ｎのフラグが設定されると、このテンプレート２１２ｎがプロトコル有限状態機械２１０により使用され、メッセージが生成される。フラグはテンプレートの一部であっても、或いはレジスター又はテーブル等の他所に維持されるものであっても良い。

動作中、プロトコル有限状態機械２１０は最初のハンドシェーク処理（initial handshake operation）を実施する。適正な時点において、プロトコル有限状態機械２１０は使用可能なテンプレート（オプションによっては、ＯＮフラグのついているものに限られる）をアクセスし、テンプレートに基づいてメッセージの構築を開始する。

プロトコルメッセージ記述２１５は、フィルタとしての利用にも適している。システム２００のようなプロトコルエミュレーション・システムのユーザーは、一般にそのシステムへと伝送されてくるトラヒックを見たいものである。しかしながら、このようなトラヒックの量は非常に多く、メッセージ又はメッセージの部分のトラヒック全てにソートをかけることは大変である場合も考えられる。プロトコルメッセージ記述２１５利用の利点の一つは、入って来るメッセージストリームに適用して関心あるメッセージ又はメッセージ部分を識別することができるフィルタ定義のベースとして、これらが非常に素晴らしいものであるという点である。

本発明の一実施例によれば、プロトコルメッセージ記述２１５はフィルタ２１７の形成に利用される。フィルタの構築には様々な方法を使用することができる。推奨される実施例においては、選択されたプロトコルメッセージ記述２１５ｎがプロトコル参照モデル２１４へとロードされ、ＧＵＩ２０６を通じて変更用にユーザーへと表示される。ユーザーは、メッセージがフィルタ処理される使用可能フィールドの各々に値を与える。それらの値は、メッセージを取り込む（例えばそのメッセージが保存される）のか、或いはメッセージをフィルタする（例えばそのメッセージが破棄される）のかを指定するものとすることができる。フィルタ２１７は、そのメッセージを取り込む場合に保存すべきメッセージの部分（すなわち「フラグメント（fragment、断片）」）を識別する為に構築されるものである。テンプレート２１２の場合、ＧＵＩ２０６及び／又はアプリケーション２０８ｎは、供給されたデータ（プロトコルメッセージ記述２１５と一緒に供給されたもの）に基づいてフィルタ２１７ｎを作成し、このフィルタ２１７ｎを保存用にプロトコルエミュレータ２０４へと送る。実際のフィルタ２１６の構造がプロトコルエミュレータの実用例と選択されたフィルタアルゴリズムに応じて変化するように、いずれのフィルタアルゴリズムを利用しても良い。

動作中、フィルタ２１６がプロトコル有限状態機械２１０への入力データに適用される。フィルタ後に取り込まれたメッセージ又はそのフラグメントは、フラグメント取得データベース２１８中に記憶される。フラグメント取得データベース２１８はプロトコルエミュレータ２０４から離れているものでもローカルなものでも良い。

フラグメント取得データベース２１８は取得したデータを取得レコード群として機械読取可能なフォーマットで記憶する。データベース２１８は、関連するフラグメントタイプ記述子を持つ単一の又は様々なフラグメントタイプを含むものとすることができる。人が読み取ることができる形式でフラグメントを提示する為に、アプリケーション２０８ｎはプロトコル参照モデル２１４を利用して、フラグメントのバイナリデータを一群のフィールド記述、値及びフォーマットルールへと復号化する。ＧＵＩ２０６はグラフィック形式でそのフラグメントの内容をユーザーへと提示するものである。代わりに、アプリケーションプログラミングインターフェース（ＡＰＩ）を構築することにより、このデータベースへのアクセスをいずれのアプリケーションからも可能とすることもできる。

本発明の特定の実施例を図示し、説明して来たが、当業者には明らかなように、本願請求項及びこれに類するものに定義されている本発明の原理及び理念から離れることなく、これらの実施例に変更を加えることが可能であることは言うまでもない。

例えば、プロトコルメッセージ記述２１５の利用は定義されたプロトコルエミュレーションの拡張を促進するものである。表３は、表２に示したフィールド定義にマルチキャストＩＰｖ６向けの拡張を加えたものである。

ＧＵＩ２０６は、プロトコルメッセージ記述２１５に基づいて動的にグラフィック表示を作成するようにプログラムすることができるものである為、新たに定義されたプロトコルメッセージ記述２１５ｎへのユーザーインターフェースを作る為の更なるプログラミングは必要としないものである。更に、新たなプロトコルメッセージ記述２１５ｎに定義されたいずれかの複写動作が、プロトコルメッセージ記述２１５をテンプレート２１２へと変換するソフトウエア中に定義されていると仮定した場合、プロトコル有限状態機械２１０において新たな符号化処理は必要としない。

１００ プロトコルエミュレーション・システム ２０８ｎ アプリケーション ２１０ 有限状態機械 ２１５ｎ 記述

Claims (20)

1. 一般的なフォーマットを用いてプロトコルメッセージ内にフィールドを記述する少なくとも１つの記述と、
   前記少なくとも１つの記述を機械読み取り可能なテンプレートへと変換するアプリケーションと、
   前記テンプレートに基づいてプロトコルメッセージを作成するプロトコル有限状態機械と、
   を有するプロトコルエミュレーション・システム。
2. 前記一般的なフォーマットがＸＭＬを含む、請求項１に記載のプロトコルエミュレーション・システム。
3. 前記プロトコルメッセージがルータとのハンドシェーク処理で用いられる、請求項１に記載のプロトコルエミュレーション・システム。
4. 前記少なくとも１つの記述が複数の記述を含む、請求項１に記載のプロトコルエミュレーション・システム。
5. 前記アプリケーションが前記少なくとも１つの記述を基準モデルへと変換する、請求項１に記載のプロトコルエミュレーション・システム。
6. ユーザーに前記記述のグラフィック表現を提示して前記記述内に含まれる値に対する変更を受け取るグラフィカルユーザーインターフェースを更に有し、
   前記アプリケーションが、前記基準モデルのインスタンスを生成し、該インスタンスに前記グラフィカルユーザーインターフェースから受け取った値を代入する、
   請求項５に記載のプロトコルエミュレーション・システム。
7. 前記アプリケーションが前記インスタンスを前記機械読取可能なテンプレートへと変換する、請求項６に記載のプロトコルエミュレーション・システム。
8. 前記テンプレートが１６進法で符号化される、請求項１に記載のプロトコルエミュレーション・システム。
9. 前記記述をフィルタへと変換するアプリケーションを更に有し、
   該フィルタは前記プロトコルエミュレーション・システムにより受信された複数のメッセージのフィルタ処理に用いられる、
   請求項１に記載のプロトコルエミュレーション・システム。
10. プロトコルエミュレータを制御する方法であって、
    前記プロトコルエミュレータを制御する為にデータ構造の記述を作成するステップを有し、
    前記記述は複数のプロトコルに一般的な言語を用いて形成されており、
    前記記述を用いて前記データ構造の基準モデルを作成するステップと、
    少なくとも幾つかのユーザー提供データで前記基準モデルのインスタンスを作成するステップと、
    前記インスタンスを用いて、前記プロトコルエミュレータがプロトコルメッセージを作成する為に応答するテンプレートを作成するステップと、
    前記テンプレートを前記プロトコルエミュレータへと伝送するステップと、
    を有する方法。
11. 前記記述を作成するステップが、データ構造を記述するＸＭＬファイルを作成することを含む、請求項１０に記載の方法。
12. 前記記述が、少なくとも１つの値をプロトコルメッセージの複数のコピーにわたってどのように変化させるかについての命令を含む、請求項１０に記載の方法。
13. 前記記述が、該記述中の他の値に基づく値を含む、請求項１０に記載の方法。
14. 前記記述を作成するステップが、前記データを階層方式で記述することを含む、請求項１０に記載の方法。
15. 前記データ構造の記述を作成するステップが、値を保持する為のフィールド、他のフィールド、又はフィールドの属性を定義することを含む、請求項１０に記載の方法。
16. 前記属性が、前記フィールドのフルネーム、前記フィールドの長さ、前記フィールドの表示フォーマット、シーケンス命令、及び要素に関する適正値の範囲を含む、請求項１５に記載の方法。
17. 前記記述に基づいてフィルタを作成するステップと、
    前記フィルタを用いて前記プロトコルエミュレーション・システムにより受信された複数のメッセージをフィルタ処理するステップと、
    を更に有する請求項１０に記載の方法。
18. プロトコルエミュレータを制御する方法であって、
    前記プロトコルエミュレータにより使用される少なくとも１つのメッセージのＸＭＬ記述を作成するステップと、
    前記記述のグラフィック表示をユーザーへ提示するステップと、
    前記ユーザーが前記記述の複数のフィールド内の値を調整するのを許可するステップと、
    前記記述及びユーザーにより調整された前記値に基づいて、プロトコル有限状態機械を制御するテンプレートを作成するステップと、
    を有する方法。
19. 前記ユーザーが一連のメッセージにおいて少なくとも１つのフィールドをメッセージ毎にどのように変化させるかを指定するのを許可するステップと、
    少なくとも１つのフィールドをメッセージ毎にどのように変化させるかについての命令を前記テンプレートに含めるステップと、
    を更に有する請求項１８に記載の方法。
20. 前記記述の複数のフィールド内のフィルタ値を前記ユーザーに設定させるステップと、
    前記記述及び前記ユーザーに設定させたフィルタ値に基づいてフィルタを作成するステップと、
    前記フィルタを利用して前記プロトコルエミュレーション・システムが受信した複数のメッセージをフィルタ処理するステップと、
    を更に有する請求項１８に記載の方法。

Images