(57)【要約】【課題】トランスポート層まで含めたプロトコルスタックを厳密に評価できる評価方法等を提供する。【解決手段】  テストプロセスのアルゴリズムに応じたコマンドを、評価実施機器２から評価対象機器１に実装されたコマンド解析手段１４に向けて発行する。コマンド解析手段１４において、コマンドに応じたＡＰＩを、ＴＯＥ１１に向けて発行する。コマンド解析手段１４がＴＯＥ１１からコマンドに対応するイベントを受け取ると、コマンド解析手段１４から評価対象機器２に向けて当該イベントに応じたレスポンスを送信する。評価実施機器２において、レスポンスに基づいてＴＯＥ１１の評価を行う。【選択図】図１
2009104223.tif 000002
【特許請求の範囲】
【請求項１】
評価実施機器を用いて評価対象機器にテストプロセスを実行させることで、前記評価対象機器に実装されたトランスポート層を含むプロトコルスタックを評価する評価方法において、
前記テストプロセスのアルゴリズムに応じたコマンドを、前記評価実施機器から前記評価対象機器に実装されたコマンド解析手段に向けて発行するステップと、
前記コマンド解析手段において、前記コマンドに応じたＡＰＩを、前記プロトコルスタックに向けて発行するステップと、
前記コマンド解析手段が前記プロトコルスタックから前記コマンドに対応するイベントを受け取ると、前記コマンド解析手段から前記評価対象機器に向けて当該イベントに応じたレスポンスを送信するステップと、
前記評価実施機器において、前記レスポンスに基づいて前記プロトコルスタックの評価を行うステップと、
を備えることを特徴とするプロトコルスタックの評価方法。
【請求項２】
前記コマンドを発行するステップでは、前記レスポンスを送信するステップにより送信された前記レスポンスの受信の有無または受信された前記レスポンスに応じて、次に発行するコマンドを変更することを特徴とする請求項１に記載のプロトコルスタックの評価方法。
【請求項３】
前記コマンドおよびレスポンスの送受信は、前記評価対象機器および前記評価実施機器間のネットワークとは別の専用回線を用いて実行することを特徴とする請求項１または２に記載のプロトコルスタックの評価方法。
【請求項４】
前記レスポンスには、通信先のアドレスまたはポート番号が含まれることを特徴とする請求項１〜３のいずれか１項に記載のプロトコルスタックの評価方法。
【請求項５】
前記トランスポート層はＴＣＰであることを特徴とする請求項１〜４のいずれか１項に記載のプロトコルスタックの評価方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、評価実施機器を用いて評価対象機器にテストプロセスを実行させることで、前記評価対象機器に実装されたトランスポート層を含むプロトコルスタックを評価する評価方法等に関する。
【背景技術】
【０００２】
ＴＣＰプロトコルスタックは、ＴＣＰ（トランスポート層）の下層にＩＰｖ６（ネットワーク層）、データ層、物理層が順次、スタックされて構成される。
【０００３】
ネットワーク層であるＩＰｖ６の評価では、ＯＳＩ参照モデルのネットワーク層部分までが評価対象である。ＴＯＥ（TCP Offload Engine）はトランスポート層までをサポートするデバイスであり、ネットワーク層までの処理はＴＯＥ内部の処理となる。そのため、評価対象機器には多機能なアプリケーションが存在する必要がなく、複数のテストシナリオに対して１種類のタスク（ＴＯＥ基本タスク）が存在すればよい。
【０００４】
ＩＰｖ６はネットワークでの通信をＴＣＰ等の上位層へ提供するプロトコルであり、ＩＰｖ６スタックの評価では、アプリケーションに殆ど依存しない。そのため、機器間でやり取りされるＩＰｖ６パケットを観測することで大部分の評価ができる。
【０００５】
ＴＡＨＩプロジェクトでテストツールやテストシナリオ等がフリーで提供されているため、ＴＡＨＩツールを動かすコンピュータを１台用意することで、ＩＰｖ６プロトコルスタックを厳密に評価することができる。また、ＴＡＨＩツールは評価の判定までが自動化されている。
【０００６】
トランスポート層であるＴＣＰは状態を持つプロトコルで”CLOSE”→”ESTABLISH”→”CLOSE”へと状態が遷移する。
【０００７】
ＴＣＰでは、コネクションの確立から切断までの状態遷移や、データの送受信を開始するトリガーはアプリケーションが行う必要があるため、ＴＣＰはアプリケーションとの関係が密接である。ＴＣＰでは各処理ごとにＡＰＩ（Application Program Interface）が存在し、ＡＰＩは全部で５種類ある。サーバアプリケーションの場合は４種類のＡＰＩを組み合わせることで動作するが、このＡＰＩを組み合わせる順番、ＡＰＩの返り値による処理の分岐や繰り返し、ＡＰＩ発行タイミング等のアルゴリズムはアプリケーションによって任意である。
【特許文献１】特開２００２−２２３２６３号公報
【特許文献２】特開２００３−０６７２７０号公報
【特許文献３】特開２００３−２８３５９４号公報
【特許文献４】特開２００５−２２３４１７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
ＴＣＰを評価する場合、下記の問題がある。
（１）ＴＰＣスタックは、既に実績のある出来合いのものを購入する場合が多いため、通常の評価では特定のアプリケーションに限定して行う。しかし、新たなＴＯＥのためにＴＣＰスタックを新規開発する場合、厳密な評価が必要となるがＴＡＨＩツールのような汎用性があるＴＣＰ用の評価ツールが存在しない。
（２）ＴＣＰはノードの持つソースなどによって、固有のパラメータ（バッファサイズなど）や挙動（スライディング・ウィンドウなど）がある。
（３）ＴＣＰはアプリケーションがトリガーになって状態遷移するため、アプリケーションとＴＯＥとのインタラクションであるＴＣＰ用のＡＰＩの処理も重要な評価対象となる。そのため、パケット単位だけでは評価ができない。また、アルゴリズムはアプリケーションによって任意であるため、評価用に様々なアプリケーションを用意する必要がある。
（４）ＴＣＰは、アプリケーションにＡＰＩをコールされ、対向ノードとのＴＣＰパケット送受信によって状態遷移する。そのため、ＡＰＩを含めて厳密に評価するには、アプリケーションと対向ノード側の評価プロセス間で同期を取る必要がある。
（５）評価対象機器には様々なアルゴリズムのアプリケーションが必要なため、手軽に分岐処理や繰り返し処理等ができるシェルスクリプト相当の機能が使えることが望ましい。しかし、評価対象機器が組み込み機器の場合、ファイルシステムやシェル機能がある高機能なＯＳを搭載することが困難である。また、メモリに制約があるため、１つのプログラムで様々なアルゴリズムのアプリケーションを用意することも難しい。
【０００９】
本発明の目的は、トランスポート層まで含めたプロトコルスタックを厳密に評価できる評価方法等を提供することにある。
【課題を解決するための手段】
【００１０】
本発明のプロトコルスタックの評価方法は、評価実施機器を用いて評価対象機器にテストプロセスを実行させることで、前記評価対象機器に実装されたトランスポート層を含むプロトコルスタックを評価する評価方法において、前記テストプロセスのアルゴリズムに応じたコマンドを、前記評価実施機器から前記評価対象機器に実装されたコマンド解析手段に向けて発行するステップと、前記コマンド解析手段において、前記コマンドに応じたＡＰＩを、前記プロトコルスタックに向けて発行するステップと、前記コマンド解析手段が前記プロトコルスタックから前記コマンドに対応するイベントを受け取ると、前記コマンド解析手段から前記評価対象機器に向けて当該イベントに応じたレスポンスを送信するステップと、前記評価実施機器において、前記レスポンスに基づいて前記プロトコルスタックの評価を行うステップと、を備えることを特徴とする。
この評価方法によれば、テストプロセスのアルゴリズムに応じたコマンドを、前記評価実施機器から前記評価対象機器に実装されたコマンド解析手段に向けて発行し、コマンド解析手段から評価対象機器に向けてイベントに応じたレスポンスを送信し、評価実施機器において、上記レスポンスに基づいてプロトコルスタックの評価を行うので、トランスポート層まで含めたプロトコルスタックを厳密に評価できる。
【００１１】
前記コマンドを発行するステップでは、前記レスポンスを送信するステップにより送信された前記レスポンスの受信の有無または受信された前記レスポンスに応じて、次に発行するコマンドを変更してもよい。
【００１２】
前記コマンドおよびレスポンスの送受信は、前記評価対象機器および前記評価実施機器間のネットワークとは別の専用回線を用いて実行してもよい。
【００１３】
前記レスポンスには、通信先のアドレスまたはポート番号が含まれてもよい。
【００１４】
前記トランスポート層はＴＣＰであってもよい。
【発明の効果】
【００１５】
本発明のプロトコルスタックの評価方法によれば、テストプロセスのアルゴリズムに応じたコマンドを、前記評価実施機器から前記評価対象機器に実装されたコマンド解析手段に向けて発行し、コマンド解析手段から評価対象機器に向けてイベントに応じたレスポンスを送信し、評価実施機器において、上記レスポンスに基づいてプロトコルスタックの評価を行うので、トランスポート層まで含めたプロトコルスタックを厳密に評価できる。
【発明を実施するための最良の形態】
【００１６】
以下、図１〜図４を参照して、本発明によるプロトコルスタックの評価方法の実施形態について説明する。
【００１７】
図１は、本発明の評価方法が適用される評価対象機器および評価実施機器の構成を機能的に示すブロック図である。
【００１８】
図１に示すように、組込み機器である評価対象機器１には、ＴＯＥ（TCP Offload Engine）１１およびＴＯＥ１１にアクセスするためのＡＰＩ（Application Program Interface）を格納するアクセスライブラリ１２が実装されている。ＴＯＥ１１は、物理層、データリンク層、ネットワーク層としてのＩＰｖ６、およびトランスポート層としてのＴＣＰからなるプロトコルスタックにより構成される。
【００１９】
また、本実施形態の評価方法では、ＴＯＥ１１を評価するための機能として、コマンド解析タスク１４が評価対象機器１に実装されている。
【００２０】
一方、評価実施機器２には、下層から順に、物理層、データリンク層、ネットワーク層としてのＩＰｖ６、およびトランスポート層としてのＴＣＰからなるプロトコルスタック２１と、プロトコルスタック２１に対しテストプロセスに応じた要求を行うＴＣＰテストツール部２２と、テストプロセスに従って、評価対象機器１との間でコマンドおよびレスポンスのやり取りを行うアルゴリズム解析機能２３と、が実装されている。ＴＣＰテストツール部２２およびアルゴリズム解析機能２３は、評価実施機器２に実装されるプログラムにより実現できる。
【００２１】
図１に示すように、評価対象機器１および評価実施機器２は、イーサネット（登録商標）等のネットワーク３を介して互いに通信可能とされている。また、評価対象機器１のコマンド解析タスク１４および評価実施機器２のアルゴリズム解析機能２３は、通信回線３とは別のシリアルライン４により接続される。
【００２２】
アルゴリズム解析機能２３は、シリアルライン４上へコマンドを発行するとともに評価対象機器１からのレスポンスを受け取る。アルゴリズム解析機能２３は、テストプロセスとして記述された手順でコマンドを発行し、レスポンスの値によって処理の分岐や繰り返し処理ができる機能を有する。例えば、「Tera Term」（商標名）のマクロ機能などを利用できる。
【００２３】
テストプロセスは、ＴＣＰアルゴリズムを組み合わせて記述される。図２は、テストプロセスのアルゴリズムを例示するフローチャートである。
【００２４】
図２のステップＳ１では、ＴＣＰアルゴリズムの一部である「Passive-Open」コマンドを発行する。ステップＳ２では、所定のタイミングでＴＣＰオープン要求を受けたことを示すレスポンスが受信されたか否か判断する。判断が肯定されればステップＳ３へ進み、判断が否定されればステップＳ７へ進む。
【００２５】
ステップＳ３では、ＴＣＰアルゴリズムの一部である「データ受信」コマンドを発行する。ステップＳ４では、所定のタイミングでデータ受信が完了したことを示すレスポンスが受信されたか否か判断する。判断が肯定されればステップＳ５へ進み、判断が否定されればステップＳ７へ進む。
【００２６】
ステップＳ５では、ＴＣＰアルゴリズムの一部である「データ送信」コマンドを発行する。ステップＳ６では、所定のタイミングでデータ送信が完了したことを示すレスポンスが受信されたか否か判断する。判断が肯定されればステップＳ３へ戻り、判断が否定されればステップＳ７へ進む。
【００２７】
ステップＳ７では、ＴＣＰアルゴリズムの一部である「クローズ」コマンドを発行し、処理を終了する。この場合には、ＴＯＥ１１は「CLOSED」状態に遷移することになる。
【００２８】
次に、テストシナリオに即して、評価対象機器１のＴＯＥ１１を評価する際の動作手順について説明する。
【００２９】
図３は、ＴＣＰアルゴリズムの一部である「パッシブオープン」のテスト手順例を示すフローチャートである。ステップＳ１１〜ステップＳ１４は、評価対象機器１のコマンド解析タスク１４の動作手順を、ステップＳ２１〜ステップＳ２４は、評価実施機器２のアルゴリズム解析機能２３の動作手順を、それぞれ示している。
【００３０】
図３のステップＳ１１では、評価対象機器１のコマンド解析タスク１４は、シリアルライン４上で評価実施機器２からのコマンドを待ち受け、コマンドを受け取るとステップＳ１２へ進む。ステップＳ１２では、アクセスライブラリ１２からステップＳ１１で受け取ったコマンドに対応するＡＰＩを発行する。これにより、ＴＯＥ１１は発行されたＡＰＩによって「Passive-Open」待ち状態（「LISTEN」状態）に遷移する。
【００３１】
ステップＳ１３では、ＴＯＥ１１からのイベントを待つ。
【００３２】
ＴＯＥ１１は、対向ノードである評価実施機器２からネットワーク３上でＴＣＰオープン要求を受信し、正常にハンドシェークが完了しコネクションが確立すると、アクセスライブラリ１２を経由してコマンド解析タスク１４に向けて「Passive-Open」イベントを通知する。またＴＣＰオープン要求を受信すると、ＴＯＥ１１は「SYN RCVD」状態から「ESTABLISH」状態へと、内部処理により状態遷移する。コマンド解析タスク１４がアクセスライブラリ１２を経由してＴＯＥ１１から「Passive-Open」イベントを受け取ると、ステップＳ１４へ進む。
【００３３】
ステップＳ１４では、コマンド解析タスク１４は「Passive-Open」が成功したことを文字列で示すレスポンスをシリアルライン４上に出力し、ステップＳ１１へ戻る。このレスポンスには、接続先（評価実施機器２）のＩＰアドレスおよびポート番号が含まれる。
【００３４】
一方、評価実施機器２のアルゴリズム解析機能２３は、図３のステップＳ２１において「Passive-Open」コマンドをシリアルライン４経由で発行する。発行されたコマンドがコマンド解析タスク１４により受信されると、上記のようにステップＳ１１の判断が肯定される。
【００３５】
次に、ステップＳ２２では、アルゴリズム解析機能２３は、ネットワーク３上でＴＣＰオープン要求を行う。
【００３６】
ステップＳ２３では、評価対象機器１および評価実施機器２の間で正常にＴＣＰコネクションが確立する（ＴＯＥ１１は「ESTABLISH」状態に遷移する）のを待って、ステップＳ２４へ進む。
【００３７】
ステップＳ２４では、シリアルライン３上に表示されるレスポンスを確認し、処理を終了する。このレスポンスは、ステップＳ１４で出力されるレスポンスに対応する。ここでは、レスポンスに含まれるＩＰアドレス、ポート番号を確認し、これらが正しい（評価実施機器２のＩＰアドレス、ポート番号を示している）ことを確認する。レスポンスが受信できない場合、あるいはレスポンスが正しくない場合には、クローズコマンドを発行する（図２のステップＳ７）ことになる。このように、ステップＳ２４は分岐処理（ステップＳ２）のための判断処理として用いられる。
【００３８】
「パッシブオープン」以外のテスト手順も同様に実行され、分岐処理（ステップＳ２、ステップＳ４、ステップＳ６）を挟んで、順次、各コマンドについてのテストが実行される。
【００３９】
このように、図３に示すような手順を繰り返すことで、図２に示すテストプロセスのアルゴリズムが実行される。
【００４０】
以上のように、本実施形態の評価方法によれば、ＴＡＨＩツールによる評価と同様の手順でＴＣＰを評価できる。
【００４１】
また、本実施形態によれば、使用するアプリケーションを機能豊富なコンピュータを使用できる評価実施機器側で記述し実行できる。このため、リソースに制約がある評価対象機器側には解析タスク１４のみを実装すれば足りる。したがって、コマンドを受け付けてＡＰＩを発行しレスポンスを返すだけのシンプルなプログラムを用意すればよく、アプリケーションごとにプログラムを改変する必要がなくなる。また、単一のプログラムで解析タスク１４を構成できるため、評価対象機器側へプログラムをロードする時間が短縮できる。
【００４２】
また、コマンド解析機能２３による評価手順では、評価結果に基づく分岐処理（ステップＳ２、ステップＳ４、ステップＳ６）が可能であるため、評価実施機器上でアルゴリズムを記述することで、評価対象機器側の様々なアプリケーションを模擬できる。
【００４３】
また、評価対象機器側でＡＰＩの発行を指示するコマンドを発行し、そのレスポンスを受け取る手順をとることにより、ＡＰＩをコールするタイミングを正確に制御でき、ＡＰＩの発行タイミングと評価実施機器のプロセスとの間で同期が取れる。このため、厳密な評価が可能となる。
【００４４】
さらに、評価に必要な評価対象機器側のＴＣＰアルゴリズムと、評価対象機器との間で送受信されるＴＣＰパケットとを、評価実施機器側の一箇所へ集約できるため、受信されるパケットの正当性等を評価実施機器側で照合して評価できる。
【００４５】
図４は、評価実施機器２に様々な評価対象機器に対応可能なＴＣＰアルゴリズムおよびＴＣＰデータを格納した例を示している。このように、ＴＣＰデータを評価実施機器２の側で保有することで、パケット評価の自動化等の拡張ができる。また、ノード固有の挙動を評価実施機器２の側で吸収できる。
【００４６】
図４の例では、ＴＣＰアルゴリズムとして共通アルゴリズムおよびノード固有アルゴリズムを格納している。共通アルゴリズムはＴＣＰで共通で定義されているアルゴリズムである。例えば３ウェイハンドシェークの手順などが該当する。ノード固有アルゴリズムは、ノード固有の挙動をアルゴリズム化したものである。例えばスライディングウィンドウ動作などが該当する。これらのアルゴリズムを組み合わせることで、種々の評価対象機器の評価に必要なテストプロセスを得ることができる。
【００４７】
また、図４の例では、ＴＣＰデータとして共通データおよびノード固有データを格納している。共通データはＴＣＰで共通で定義されているデータである。例えばＴＣＰフラグなどが該当する。ノード固有データは、ノード固有のデータである。例えばポート番号、ＩＰアドレス、バッファサイズなどが該当する。これらのデータを用いて通信を実行し、あるいは通信データを照合することで、種々の評価対象機器に対し、広範な評価を実施できる。
【００４８】
上記実施形態では、組込み機器を評価対象機器とした場合について例示したが、同様なＡＰＩ仕様の機器であれば、同様の評価を実施できる。
【００４９】
本発明のプロトコルスタックの評価方法によれば、テストプロセスのアルゴリズムに応じたコマンドを、前記評価実施機器から前記評価対象機器に実装されたコマンド解析手段に向けて発行し、コマンド解析手段から評価対象機器に向けてイベントに応じたレスポンスを送信し、評価実施機器において、上記レスポンスに基づいてプロトコルスタックの評価を行うので、トランスポート層まで含めたプロトコルスタックを厳密に評価できる。
【００５０】
以上説明したように、  本発明のプロトコルスタックの評価方法によれば、テストプロセスのアルゴリズムに応じたコマンドを、前記評価実施機器から前記評価対象機器に実装されたコマンド解析手段に向けて発行し、コマンド解析手段から評価対象機器に向けてイベントに応じたレスポンスを送信し、評価実施機器において、上記レスポンスに基づいてプロトコルスタックの評価を行うので、トランスポート層まで含めたプロトコルスタックを厳密に評価できる。
【００５１】
本発明の適用範囲は上記実施形態に限定されることはない。本発明は、評価実施機器を用いて評価対象機器にテストプロセスを実行させることで、前記評価対象機器に実装されたトランスポート層を含むプロトコルスタックを評価する評価方法および当該プロトコルスタックを評価する評価方法を実行するプログラムに対し、広く適用することができる。
【図面の簡単な説明】
【００５２】
【図１】本発明の評価方法が適用される評価対象機器および評価実施機器の構成を機能的に示すブロック図。
【図２】テストプロセスのアルゴリズムを例示するフローチャート。
【図３】ＴＣＰアルゴリズムの一部である「パッシブオープン」のテスト手順例を示すフローチャート。
【図４】評価実施機器に様々な評価対象機器に対応可能なＴＣＰアルゴリズムおよびＴＣＰデータを格納した例を示すブロック図。
【符号の説明】
【００５３】
１      評価対象機器
２      評価実施機器
１１    ＴＯＥ（プロトコルスタック）
１４    コマンド解析手段
【図１】
2009104223.tif 000003
【図２】
2009104223.tif 000004
【図３】
2009104223.tif 000005
【図４】
2009104223.tif 000006