(57)【要約】      （修正有）【課題】処理のオーバヘッドを削減できる分類器、通信装置、及び通信方法を提供する。【解決手段】通信装置は、少なくとも１つのプロトコル処理部２と、分類器５と、を備える。プロトコル処理部２は、受信したパケットに所定のプロトコル処理を実行する。分類器５は、パケットの分類情報に基づいて、パケットに対して実行するプロトコル処理を特定し、特定された前記プロトコル処理を実行するプロトコル処理部２に、パケットと、付加情報と、を通知する。付加情報は、特定されたプロトコル処理を実行するために利用される。【選択図】図１
2017059897.tif 000002
【特許請求の範囲】
【請求項１】
受信したパケットに所定のプロトコル処理を実行する少なくとも１つのプロトコル処理部を備えた通信装置において、
前記パケットの分類情報に基づいて、前記パケットに対して実行する前記プロトコル処理を特定し、特定された前記プロトコル処理を実行する前記プロトコル処理部に、前記パケットと、特定された前記プロトコル処理を実行するために利用される付加情報と、を通知する
分類器。
【請求項２】
前記付加情報又は前記付加情報の識別子を、ディスクリプタ、前記パケットの処理済み領域、前記パケットを格納するバッファの空き領域、及び前記プロトコル処理部のレジスタのいずれか１つに記載することにより、前記付加情報を前記プロトコル処理部に通知する
請求項１に記載の分類器。
【請求項３】
前記パケットに対して実行する前記プロトコル処理が複数特定された場合、特定された複数の前記プロトコル処理をそれぞれ実行する複数の前記プロトコル処理部に、前記プロトコル処理部が実行する前記プロトコル処理に応じた前記付加情報をそれぞれ通知する請求項１又は請求項２に記載の分類器。
【請求項４】
前記パケットに対して実行する前記プロトコル処理が複数特定された場合、前記各プロトコル処理部に、前記プロトコル処理部毎の前記付加情報を通知する
請求項１乃至請求項３のいずれか１項に記載の分類器。
【請求項５】
前記パケットに対して実行する前記プロトコル処理が複数特定された場合、前記各プロトコル処理部に、前記各プロトコル処理部の前記付加情報を一括して通知する
請求項１乃至請求項４のいずれか１項に記載の分類器。
【請求項６】
前記パケットに対して実行する前記プロトコル処理が複数特定された場合、前記プロトコル処理部への前記付加情報の通知と、前記プロトコル処理部による前記プロトコル処理と、が繰り返される
請求項１乃至請求項５のいずれか１項に記載の分類器。
【請求項７】
前記分類情報は、前記パケットのヘッダに含まれる情報及び前記ヘッダに含まれる情報から計算されたハッシュ値の少なくとも１つである
請求項１乃至請求項６のいずれか１項に記載の分類器。
【請求項８】
前記付加情報は、ＴＣＰ管理情報、ＴＣＢに含まれる情報、及びＰＣＢに含まれる情報の少なくとも１つである
請求項１乃至請求項７のいずれか１項に記載の分類器。
【請求項９】
請求項１乃至請求項８のいずれか１項に記載の分類器と、
少なくとも１つの前記プロトコル処理部と、
前記分類情報と前記付加情報とを対応付けたエントリを記憶する記憶部と、
を備え、
前記分類器は、前記パケットの前記分類情報に基づいて、前記記憶部に記憶された前記エントリの中から前記パケットと対応する前記エントリを探索し、前記パケットと対応する前記エントリを発見した場合、発見した前記エントリに含まれる前記付加情報を前記プロトコル処理部に通知する
通信装置。
【請求項１０】
前記プロトコル処理部は、前記分類器から通知された前記パケットに対して、前記分類器から通知された前記付加情報を利用して前記プロトコル処理を実行する
請求項９に記載の通信装置。
【請求項１１】
前記パケットを処理するプロセッサを備え、
前記分類器は、前記パケットと対応する前記エントリを発見できなかった場合、前記パケットを前記プロセッサに通知し、
前記プロセッサは、通知された前記パケットを処理する
請求項９又は請求項１０に記載の通信装置。
【請求項１２】
前記プロセッサは、前記パケットを処理する過程で得られた前記パケットの分類情報と前記付加情報とに基づいて、前記エントリを生成する
請求項９乃至請求項１１のいずれか１項に記載の通信装置。
【請求項１３】
複数の前記プロトコル処理部を備え、
前記エントリは、前記付加情報に対応付けられた、前記プロトコル処理部を特定する識別子を含む
請求項９乃至請求項１２のいずれか１項に記載の通信装置。
【請求項１４】
複数の前記プロトコル処理部を備え、
前記エントリは、前記プロトコル処理部毎に設けられたテーブルに格納される
請求項９乃至請求項１２のいずれか１項に記載の通信装置。
【請求項１５】
複数の前記プロトコル処理を実行可能な汎用プロトコル処理部を備える
請求項９乃至請求項１４のいずれか１項に記載の通信装置。
【請求項１６】
前記エントリは、前記付加情報に対応付けられた、前記汎用プロトコル処理部が実行する前記プロトコル処理を特定する識別子を含む
請求項１５に記載の通信装置。
【請求項１７】
前記分類器は、前記汎用プロトコル処理部が実行する前記プロトコル処理の変更が終了するまで、前記パケットを前記プロセッサに通知し、前記パケットを前記プロセッサに処理させる
請求項１５又は請求項１６に記載の通信装置。
【請求項１８】
前記分類器は、同一の前記分類情報を有する前記パケットを所定回数以上受信した場合、前記パケットを前記汎用プロトコル処理部に通知する
請求項１５乃至請求項１７のいずれか１項に記載の通信装置。
【請求項１９】
パケットに所定のプロトコル処理を実行する少なくとも１つのプロトコル処理部を備えた通信装置において、
前記パケットの分類情報に基づいて、前記パケットに対して実行する前記プロトコル処理を特定する工程と、
特定された前記プロトコル処理を実行する前記プロトコル処理部に、前記パケットと、特定された前記プロトコル処理を実行するために利用される付加情報と、を通知する工程と、
前記プロトコル処理部により、前記パケットに前記プロトコル処理を実行する工程と、
を備える通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、分類器、通信装置、及び通信方法に関する。
【背景技術】
【０００２】
従来、ネットワークから受信したパケットを分類器で分類し、分類結果に応じたマルチコアプロセッサの所定のコアやスレッドに処理を実行させる技術が知られている。分類器によるパケットの分類方法として、パケットのヘッダを走査して得られた各フィールドの値や、各フィールドの値から生成されたハッシュ値を用いる方法が提案されている。
【０００３】
上記従来の技術によれば、パケットの分類処理を高速化し、かつ、処理を特定のコアに集中させることが可能となり、パケットの効率的な処理を実現できる。しかしながら、従来の分類器は、分類処理に特化しており、後段の処理との連携が考慮されていなかった。このため、分類器でパケットのヘッダを走査したにも関わらず、後段の処理で再びヘッダの走査を行う必要があった。このような処理のオーバヘッドは、処理効率を低下させる原因となった。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特表２００５−５０７２１２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
処理のオーバヘッドを削減できる分類器、通信装置、及び通信方法を提供する。
【課題を解決するための手段】
【０００６】
一実施形態に係る通信装置は、少なくとも１つのプロトコル処理部と、分類器と、を備える。プロトコル処理部は、受信したパケットに所定のプロトコル処理を実行する。分類器は、パケットの分類情報に基づいて、パケットに対して実行するプロトコル処理を特定し、特定された前記プロトコル処理を実行するプロトコル処理部に、パケットと、付加情報と、を通知する。付加情報は、特定されたプロトコル処理を実行するために利用される。
【図面の簡単な説明】
【０００７】
【図１】第１実施形態に係る通信装置のハードウェア構成の一例を示す図。
【図２】図１の通信装置の論理的な接続関係を示す図。
【図３】図１の通信装置のパケット受信時の動作を示すフローチャート。
【図４】第１実施形態におけるエントリの一例を示す図。
【図５】第２実施形態に係る通信装置の論理的な接続関係を示す図。
【図６】通信装置が受信するパケットの一例を示す図。
【図７】第２実施形態におけるエントリの一例を示す図。
【図８】第２実施形態におけるエントリの他の例を示す図。
【図９】図８のエントリの変形例を示す図。
【図１０】図８のエントリの変形例を示す図。
【図１１】第２実施形態における第１の通知方法の一例を示す図。
【図１２】第２実施形態における第１の通知方法の他の例を示す図。
【図１３】第２実施形態における第２の通知方法の一例を示す図。
【図１４】図５の通信装置のパケット受信時の動作を示すフローチャート。
【図１５】複数のプロトコル処理部によるプロトコル処理の一例を示すフローチャート。
【図１６】複数のプロトコル処理部によるプロトコル処理の他の例を示すフローチャート。
【図１７】プロセッサによる複数のプロトコル処理の一例を示すフローチャート。
【図１８】第３実施形態係る通信装置の論理的な接続関係を示す図。
【図１９】第３実施形態におけるエントリの一例を示す図。
【図２０】第３実施形態におけるエントリの他の例を示す図。
【発明を実施するための形態】
【０００８】
以下、本発明の実施形態について図面を参照して説明する。
【０００９】
（第１実施形態）
第１実施形態に係る通信装置について、図１〜図４を参照して説明する。図１は、本実施形態に係る通信装置のハードウェア構成の一例を示す図である。図１に示すように、この通信装置は、プロセッサ１と、プロトコル処理部２と、ＲＡＭ３と、通信Ｉ／Ｆ４と、分類器５と、ＬＵＴＲＡＭ６と、を備える。
【００１０】
プロセッサ１は、ＲＡＭ３上の各種のプログラムを実行し、通信装置全体の制御や、通信装置が受信したパケットの処理を実行する。プロセッサ１が実行するパケット処理には、プロトコル処理部２が実行するプロトコル処理が含まれる。
【００１１】
プロトコル処理部２は、通信装置が受信したパケットに対して、ＴＣＰ、ＩＰ、ＵＤＰなどの所定のプロトコル処理を実行する。プロトコル処理部２は、プロトコル処理に最適化された専用のプロセッサであってもよいし、所定のプロトコル処理を実現するプログラムを実行するように設定された、プロセッサ１と同様のプロセッサであってもよい。プロトコル処理部２は、例えば、ＴＣＰオフロードエンジン（ＴＯＥ）であるが、これに限られない。
【００１２】
ＲＡＭ３は、プロセッサ１やプロトコル処理部２が実行するプログラムや、通信装置が受信したパケットなどを格納する。ＲＡＭ３は、プロセッサ１やプロトコル処理部２に利用される。ＲＡＭ３として、例えば、ＳＲＡＭ、ＤＲＡＭ、ＲｅＲＡＭ、ＰＣＲＡＭ、ＭＲＡＭなどを使用できる。
【００１３】
通信Ｉ／Ｆ（インターフェース）４は、通信装置とネットワークとを接続する。通信Ｉ／Ｆ４は、ネットワークからパケットを受信し、受信したパケットをＲＡＭ３に格納する。また、通信Ｉ／Ｆ４は、受信したパケットを分類器５に通知する。
【００１４】
分類器５は、通信装置が受信したパケットを、パケットの処理内容、パケットを処理する処理部（プロセッサ１又はプロトコル処理部２）、及び処理の優先度などの分類情報に従って分類する。
【００１５】
具体的には、分類器５は、各パケットを、プロトコル処理部２で処理できるパケットか判定する。分類器５は、プロトコル処理部２で処理できると判定したパケットを、付加情報と共にプロトコル処理部２に通知する。プロトコル処理部２に通知されたパケットは、プロトコル処理部２によりプロトコル処理される。また、分類器５は、プロトコル処理部２で処理できないと判定したパケットを、プロセッサ１に通知する。プロセッサ１に通知されたパケットは、プロセッサ１によりパケット処理される。付加情報及び分類情報について、詳しくは後述する。
【００１６】
ＬＵＴＲＡＭ６は、分類器５が使用するエントリを格納したルックアップテーブル（以下、「ＬＵＴ」という）を記憶する記憶部である。各エントリには、分類情報と、分類情報に応じた付加情報又はその識別子と、が含まれる。各エントリは、プロセッサ１により生成される。分類器５は、ＬＵＴＲＡＭ６上のＬＵＴを参照して、パケットを分類する。
【００１７】
ＬＵＴＲＡＭ６は、分類器５が高速に参照可能なように構成されるのが好ましい。ＬＵＴＲＡＭ６として、例えば、ＳＲＡＭ、ＤＲＡＭ、ＲｅＲＡＭ、ＰＣＲＡＭ、ＭＲＡＭや、これらを記憶素子として使用する連想メモリ（ＣＡＭ：Content Addressable Memory）などを使用できる。
【００１８】
なお、図１の例では図示されていないが、通信装置は、ＨＤＤやＳＳＤなどの補助記憶装置を備えてもよい。
【００１９】
次に、本実施形態に係る通信装置の動作について、図２及び図３を参照して説明する。図２は、図１の通信装置の論理的な接続関係を示した図である。また、図３は、図１の通信装置のパケット受信時の動作を示すフローチャートである。
【００２０】
図３に示すように、通信Ｉ／Ｆ４は、ネットワークを介してパケットを受信すると、受信したパケットをＲＡＭ３に格納する（ステップＳ１）。パケットは、ＤＭＡ等の方式を用いてＲＡＭ３に格納される。
【００２１】
次に、通信Ｉ／Ｆ４は、受信したパケットを分類器５に通知する（ステップＳ２）。パケットの通知は、受信したパケットの一部又は全部を分類器５に渡すことにより行なわれてもよいし、ＲＡＭ３上に格納されたパケットの識別子（アドレスやポインタなど）を分類器５に通知することにより行なわれてもよい。パケットの識別子を通知することにより、パケットを渡す場合に比べて、通信Ｉ／Ｆ４から分類器５に通知する情報量を削減できる。
【００２２】
通信Ｉ／Ｆ４からパケットを通知された分類器５は、まず、通知されたパケットを走査し（ステップＳ３）、パケットの分類情報を取得する。
【００２３】
ここで、分類情報について説明する。分類情報とは、パケットに対するプロトコル処理を特定するための情報のことである。同一の分類情報を有するパケットは、通信装置により同一の処理を実行される。
【００２４】
分類情報として、例えば、パケットのＩＰヘッダやＴＣＰヘッダに含まれる情報（送信元ＩＰアドレス、宛先ＩＰアドレス、プロトコルの種類、送信元ポート番号、及び宛先ポート番号など）が利用される。
【００２５】
また、分類情報として、ＩＰヘッダやＴＣＰヘッダに含まれる情報以外の情報を利用することもできる。例えば、分類情報は、他のヘッダ領域（ＴＯＳフィールド、フローラベルフィールド、フラグなど）に含まれる情報であってもよいし、ＴＣＰヘッダよりも後に格納されるアプリケーションデータの全部又は一部（例えば、先頭からの長さで特定される部分）であってもよいし、アプリケーションプロトコルを解釈して得られる特定のフィールド（ＨＴＴＰのＵＲＬやＵｓｅｒ−Ａｇｅｎｔなど）に含まれる情報であってもよいし、ＶＬＡＮタグ、パケット又はフレームに付与された何らかのラベル、ＭＡＣアドレス、プロトコルフィールド、及びＶＰＮコネクションを特定する識別子などであってもよいし、これらの情報の組み合わせであってもよい。さらに、分類情報は、上記の情報から計算されたハッシュ値であってもよい。
【００２６】
分類器５は、パケットの走査により得られた分類情報に基づいて、ＬＵＴを探索する（ステップＳ４）。すなわち、ＬＵＴの中から、パケットと対応するエントリを探索する。パケットと対応するエントリとは、パケットの分類情報と合致する分類情報を含むエントリのことである。
【００２７】
分類器５は、ＬＵＴを探索した結果、パケットと対応するエントリを発見した場合（ステップＳ５のＹＥＳ）、そのパケットはプロトコル処理部２により処理できると判定し、パケット及び付加情報をプロトコル処理部２に通知する（ステップＳ６）。
【００２８】
ここで、付加情報について説明する。付加情報とは、プロトコル処理部２が、パケットをプロトコル処理するために必要な情報のことである。付加情報は、例えば、ＴＣＰ管理情報であるＴＣＢ（TCP Control Block）及びＰＣＢ（Protocol Control Block）に含まれる情報であるが、これに限られない。ＴＣＢには、例えば、ＴＣＰの状態、シーケンス番号やＡＣＫの番号、最大セグメントサイズ、輻輳ウィンドウサイズ、フラグ、及び送受信バッファへのポインタなどの情報が含まれる。また、ＰＣＢには、例えば、送信データ数、送信パケット数、受信データ数、受信パケット数、送信エラーパケット数、及び受信エラーパケット数などの情報が含まれる。
【００２９】
なお、分類器５が通知する付加情報は、ＴＣＢやＰＣＢと同様のデータ構造を有してもよいし、異なるデータ構造を有してもよい。
【００３０】
付加情報の通知は、付加情報自体をプロトコル処理部２に渡すことにより行なわれてもよい。この場合、ＬＵＴＲＡＭ６の各エントリには、各エントリの分類情報に対応する付加情報が含まれる。分類器５は、エントリに含まれる付加情報をプロトコル処理部２に渡すことにより、付加情報を通知すればよい。
【００３１】
また、付加情報の通知は、ＲＡＭ３上に格納された付加情報の識別子（アドレスやポインタなど）をプロトコル処理部２に通知することにより行なわれてもよい。この場合、ＬＵＴＲＡＭ６の各エントリには、各エントリの分類情報に対応する付加情報の識別子が含まれる。分類器５は、エントリに含まれる付加情報をプロトコル処理部２に通知することにより、付加情報を通知すればよい。
【００３２】
なお、必ずしもＬＵＴＲＡＭ６の各エントリから直接付加情報を特定する必要はない。例えば、ＬＵＴＲＡＭ６のエントリを構成する全部又は一部のフィールドに対応するハッシュ値と、このハッシュ値に対応づけられた付加情報と、で構成される付加情報テーブルを、ＬＵＴＲＡＭ６又はＲＡＭ３に格納する。そして、分類器５が、格納された付加情報テーブルを検索し、パケットに対応する付加情報を特定し、特定された付加情報を通知すればよい。
【００３３】
付加情報に複数の情報が含まれる場合には、分類器５は、各情報の識別子をプロトコル処理部２に通知すればよい。付加情報の識別子を通知することにより、付加情報自体を渡す場合に比べて、分類器５からプロトコル処理部２へ通知する情報量を削減できる。
【００３４】
より詳細には、分類器５は、ディスクリプタを用いてパケットや付加情報を通知することができる。この場合、分類器５は、パケット又はその識別子と、付加情報又はその識別子と、を格納したディスクリプタを生成し、生成したディスクリプタをプロトコル処理部２に通知すればよい。
【００３５】
また、分類器５は、パケットの処理済み領域を用いて付加情報を通知することができる。例えば、プロトコル処理部２がＴＣＰ／ＩＰのプロトコル処理を実行する場合、プロトコル処理部２に通知されるパケットのＭＡＣヘッダは処理済みと考えられる。この場合、分類器５は、パケットのＭＡＣヘッダ（例えば、送信元ＭＡＣアドレスや宛先ＭＡＣアドレスの領域など）に、付加情報又はその識別子を格納し、格納したパケットをプロトコル処理部２に渡せばよい。
【００３６】
さらに、分類器５は、パケットを格納するバッファの未使用領域を用いて付加情報を通知することができる。例えば、パケットを格納したバッファが固定長である場合、バッファの先頭又は後尾に未使用領域が存在する可能性がある。分類器５は、このような未使用領域に、付加情報又はその識別子を格納し、格納したバッファをプロトコル処理部２に渡せばよい。
【００３７】
またさらに、分類器５は、プロトコル処理部２のレジスタを用いて通知することができる。この場合、分類器５は、プロトコル処理部２のレジスタに、パケット又はその識別子と、付加情報又はその識別子と、を直接書き込めばよい。なお、一般に、レジスタの容量は小さいため、分類器５は、パケット及び付加情報の識別子だけを書き込むのが好ましい。
【００３８】
なお、分類器５は、パケット及び付加情報を、プロトコル処理部２に同様の方法で通知してもよいし、それぞれ異なる方法で通知してもよい。パケット及び付加情報の通知方法は、上記の中から任意に選択可能である。
【００３９】
分類器５からパケット及び付加情報を通知されたプロトコル処理部２は、通知された付加情報を用いて、通知されたパケットに対するプロトコル処理を実行する（ステップＳ７）。プロトコル処理部２は、分類器５から付加情報自体を渡された場合には、その付加情報を利用すればよい。また、プロトコル処理部２は、分類器５から付加情報の識別子を通知された場合には、識別子により特定されるＲＡＭ３上の領域を読み込み、付加情報を取得すればよい。プロトコル処理の際に得られた各種のデータは、ＲＡＭ３に格納される。プロトコル処理部２がプロトコル処理を実行した後、通信装置による処理は終了する。
【００４０】
一方、分類器５は、ＬＵＴを探索した結果、パケットと対応するエントリを発見できなかった場合（ステップＳ５のＮＯ）、そのパケットはプロトコル処理部２により処理できないと判定し、パケットをプロセッサ１に通知する（ステップＳ８）。
【００４１】
分類器５からパケットを通知されたプロセッサ１は、通知されたパケットに応じたプログラムを実行し、パケット処理を実行する（ステップＳ９）。
【００４２】
ここで、プロセッサ１によるパケット処理について、プロセッサ１がＴＣＰ／ＩＰのプロトコル処理を実行する場合を例に説明する。プロセッサ１がＴＣＰ／ＩＰのプロトコル処理を実行する場合、プロセッサ１は、パケットのＩＰヘッダを走査して、パケットの宛先ＩＰアドレスが自ノードに割当てられたＩＰアドレスに合致するかの判定や、ＩＰチェックサムが適切かどうかの判定などを行う。
【００４３】
通知されたパケットが自ノード宛てのパケットでない場合や、ＩＰチェックサムが適切でない場合には、プロセッサ１はプロトコル処理を終了する（図示省略）。
【００４４】
一方、通知されたパケットが自ノード宛てのパケットであり、かつ、ＩＰチェックサムが適切であった場合、プロセッサ１は、ＩＰヘッダに続く上位層の処理を実行する。ここでは、上位層のヘッダとして、ＴＣＰヘッダが付加されているものとする。
【００４５】
この場合、プロセッサ１は、ＴＣＰヘッダを走査して、送信元ポート番号及び宛先ポート番号の特定や、ＴＣＰチェックサムが適切かどうかの判定などを行う。通知されたパケットのＴＣＰチェックサムが適切でない場合、プロセッサ１は、プロトコル処理を終了する（図示省略）。
【００４６】
一方、ＴＣＰチェックサムが適切であった場合、プロセッサ１は、ＲＡＭ３を走査し、特定された送信元ポート番号及び宛先ポート番号と合致する付加情報（ＴＣＰ管理情報など）を探索する。
【００４７】
特定された送信元ポート番号及び宛先ポート番号と合致する付加情報を発見した場合、プロセッサ１は、発見した付加情報を用いてプロトコル処理を継続し、プロトコル処理されたパケット（アプリケーションのデータ）を、ＴＣＰ／ＩＰを利用するアプリケーションに通知する。
【００４８】
一方、特定された送信元ポート番号及び宛先ポート番号と合致する付加情報を発見できなかった場合、プロセッサ１は、受信したパケットは新たな通信に対応するパケットであると判定し、受信したパケットに応じた付加情報を作成し、作成した付加情報をＲＡＭ３に格納する。
【００４９】
続いて、プロセッサ１は、ステップＳ９で実行したパケット処理を、プロトコル処理部２が実行可能か判定する（ステップＳ１０）。プロセッサ１は、例えば、プログラム中で特定の処理や関数が実行されたか否かに基づいて、パケット処理をプロトコル処理部２が実行可能か否か判定することができる。この場合、プログラム中の特定の処理や関数に、プロトコル処理部２で実行可能か否かを示す情報を予め付与しておけばよい。
【００５０】
また、プロセッサ１は、受信したパケットから特定されたポート番号などの情報や生成された付加情報から、プロトコル処理部２で実行可能か否かを判断する処理を実行してもよい。このような処理として、プロセッサ１は、例えば、受信したパケットが特定の宛先ポート番号を有するか否かを判定する処理や、プロトコル処理部２が対応しないオプションフィールドが含まれていないことを確認する処理などを実行してもよい。
【００５１】
プロトコル処理部２がパケット処理を実行できないと判定された場合（ステップＳ１０のＮＯ）、通信装置による処理は終了する。
【００５２】
一方、プロトコル処理部２がパケット処理を実行できると判定された場合（ステップＳ１０のＹＥＳ）、プロセッサ１は、ＲＡＭ３に格納されたパケットの付加情報と分類情報とに基づいて、新たなエントリを生成し、生成したエントリをＬＵＴＲＡＭ６に記憶されたＬＵＴに追加する（ステップＳ１１）。
【００５３】
プロセッサ１は、分類情報と付加情報とを対応付けてエントリを生成してもよいが、分類情報と付加情報の識別子とを対応付けてエントリを生成するのが好ましい。これにより、分類情報と付加情報とを対応付けてエントリを生成する場合に比べて、ＬＵＴに格納されるエントリの情報量を削減することができる。
【００５４】
なお、ＲＡＭ３に格納された付加情報や分類情報の形式と、エントリに含まれる付加情報や分類情報の形式と、は同じであってもよいし、異なってもよい。また、プロセッサ１は、生成された新たなエントリをＲＡＭ３に格納してもよいし、しなくてもよい。さらに、プロセッサ１は、エントリをＲＡＭ３に格納する場合には、分類情報を省略して格納してもよい。
【００５５】
図４は、ＬＵＴに格納されたエントリの一例を示す図である。図４の例では、各エントリにおいて、分類情報と、付加情報の識別子（ＩＤ）と、が対応付けられている。図４のエントリの分類情報には、送信元ＩＰアドレス（ｓｒｃ  ＩＰ）、宛先ＩＰアドレス（ｄｓｔ  ＩＰ）、プロトコルの種類（Ｐｒｏｔｏｃｏｌ）、送信元ポート番号（ｓｒｃ  Ｐｏｒｔ）、及び宛先ポート番号（ｄｓｔ  Ｐｏｒｔ）が含まれる。
【００５６】
ここで、図４の１行目のエントリに対応するパケットＸを、通信Ｉ／Ｆ４が受信した場合を例に、通信装置の動作について具体的に説明する。
【００５７】
通信Ｉ／Ｆ４は、パケットＸを受信すると、パケットＸをＲＡＭ３に格納し（ステップＳ１）、パケットＸの識別子を分類器５に通知する（ステップＳ２）。分類器５は、通知された識別子に基づいて、ＲＡＭ３に格納されたパケットＸを走査し（ステップＳ３）、パケットＸの分類情報（ＩＰ_ｓ１，ＩＰ_ｄ１，Ｐ１，Ｐｒｔ_ｓ１，Ｐｒｔ_ｄ１）を取得し、取得したパケットＸの分類情報に基づいてＬＵＴを探索する（ステップＳ４）。
【００５８】
ＬＵＴに図４の１行目のエントリが格納されている場合、このエントリが、パケットＸに対応するエントリとして発見される（ステップＳ５のＹＥＳ）。したがって、分類器５は、パケットＸの識別子と、図４の１行目のエントリに含まれる付加情報の識別子（ＣＩＤ１）と、をプロトコル処理部２に通知する（ステップＳ６）。
【００５９】
プロトコル処理部２は、通知された識別子（ＣＩＤ１）により特定される付加情報をＲＡＭ３から取得し、取得した付加情報を利用して、パケットＸに対してプロトコル処理を実行する（ステップＳ７）。
【００６０】
一方、ＬＵＴに図４の１行目のエントリが格納されていない場合、パケットＸに対応するエントリは発見されない（ステップＳ５のＮＯ）。したがって、分類器５は、パケットＸの識別子をプロセッサ１に通知する（ステップＳ８）。プロセッサ１は、通知されたパケットＸに対して所定のパケット処理を実行する（ステップＳ９）。プロセッサ１によるパケット処理により得られたパケットＸの付加情報は、ＲＡＭ３に格納される。
【００６１】
プロセッサ１によるパケット処理が、プロトコル処理部２により実行できない場合（ステップＳ１０のＮＯ）、通信装置による処理は終了する。
【００６２】
一方、プロセッサ１によるパケット処理が、プロトコル処理部２により実行できる場合（ステップＳ１０のＹＥＳ）、プロセッサ１は、ＲＡＭ３に格納した付加情報の識別子（ＣＩＤ１）と、パケットＸの分類情報（ＩＰ_ｓ１，ＩＰ_ｄ１，Ｐ１，Ｐｒｔ_ｓ１，Ｐｒｔ_ｄ１）と、を対応付けたエントリを生成し、ＬＵＴに格納する。格納されるエントリは、図４の１行目のエントリに相当する。
【００６３】
以降、パケットＸと同じ分類情報を有するパケットは、分類器５によりプロトコル処理部２に通知され、プロトコル処理部２によりプロトコル処理を実行される。
【００６４】
以上説明した通り、本実施形態に係る通信装置によれば、プロトコル処理部２は、プロトコル処理に必要な付加情報を分類器５から通知される。このため、プロトコル処理部２は、付加情報を取得するためにパケットを走査することなく、プロトコル処理を実行できる。したがって、本実施形態によれば、分類器５及びプロトコル処理部２がそれぞれパケットを走査する、という処理のオーバヘッドを削減することができる。これにより、プロトコル処理部２によるプロトコル処理に要する時間を短縮できる。
【００６５】
また、本実施形態によれば、プロトコル処理部２がプロトコル処理を実行できないパケットは、プロセッサ１によりパケット処理される。すなわち、プロトコル処理部２は、プロトコル処理を実行できないパケットを入力された場合の例外処理を行なわなくてよい。これにより、本実施形態によれば、プロトコル処理部２によるプロトコル処理から、例外処理を削減することができる。
【００６６】
プロトコル処理部２がＴＯＥのような専用の回路により構成される場合、プロトコル処理を削減することにより、プロトコル処理部２の回路規模を小型化することができる。この結果、通信装置の小型化や低消費電力化が可能となる。
【００６７】
なお、本実施形態において、ＬＵＴに格納されたエントリは、一連の通信が終了した後、削除される。通信の終了には、正常終了及び異常終了が含まれる。正常終了は、例えば、ＴＣＰにおけるＦＩＮフラグがセットされたパケットを交換した場合に相当する。異常終了は、例えば、ＴＣＰにおけるＲＳＴフラグがセットされたパケットが通知された場合に相当する。通信の終了は、プロセッサ１やプロトコル処理部２により検出すればよい。
【００６８】
なお、通信が、ＴＣＰ以外のプロトコルで行われており、かつ、通信終了が明示的に行われる場合（例えば、通信終了時までに交換するパケットの長さが事前に通信装置に通知されている場合）には、上記と同様に、通信の終了が検出した後、エントリを削除すればよい。
【００６９】
また、通信終了が明示的に行われない場合（例えば、ＵＤＰのように通信がステートレスで実行される場合）には、プロトコル処理部２で処理されるパケットを、所定時間以上受信できない場合に、通信は終了したものとして、エントリを削除すればよい。
【００７０】
さらに、ＬＵＴに格納可能なエントリ数に上限がある場合、エントリが上限に達しないように、ＬＵＴ格納されたエントリは、所定時間毎に削除されてもよいし、置換されてもよい。ＬＵＴに格納されたエントリは、例えば、ＬＲＵ（Least Recently Used）、ＬＦＵ（Least Frequently Used）、ＦＩＦＯ（First In First Out）などの一般的な置換アルゴリズムを利用して置換すればよい。
【００７１】
（第２実施形態）
第２実施形態に係る通信装置について、図５〜図１７を参照して説明する。本実施形態では、プロトコル処理部２を複数備える通信装置について説明する。図５は、本実施形態に係る通信装置の論理的な接続関係を示す図である。図５の例では、通信装置は、３つのプロトコル処理部２Ａ，２Ｂ，２Ｃを備えるが、本実施形態において、通信装置は、プロトコル処理部２を２つ又は４つ以上備えてもよい。
【００７２】
本実施形態に係る通信装置の動作は、基本的には第１実施形態と同様である。ただし、本実施形態では、分類器５の動作と、ＬＵＴに格納されるエントリ及びその参照方法と、が第１実施形態とは異なる。
【００７３】
まず、分類器５の動作について説明する。第１実施形態では、分類器５は、パケットをプロセッサ１及びプロトコル処理部２のいずれで処理するか判定した。これに対して、本実施形態では、分類器５は、パケットをプロセッサ１及びプロトコル処理部２Ａ〜２Ｃのいずれで処理するか判定する。
【００７４】
また、第１実施形態では、分類器５はパケットの通知を１回だけ行った。これに対して、本実施形態では、分類器５は、パケットの通知を複数回行い得る。これは、一般に、プロトコルが階層構造を有するため、１つのパケットに対して、複数のプロトコル処理部２がプロトコル処理を実行できる可能性があるためである。
【００７５】
ここで、分類器５の動作について、具体的に説明する。以下では、通信装置が図６に示すパケットＹを受信した場合を例に説明する。図６に示すように、パケットＹは、ＩＰヘッダ、ＩＰｓｅｃヘッダ、Ｌ２ＴＰｖ３ヘッダを有する。また、プロトコル処理部２Ａは暗号処理エンジン、プロトコル処理部２Ｂはトンネル処理エンジン、プロトコル処理部２ＣはＴＣＰエンジンであるものとする。
【００７６】
通信装置がパケットＹを受信すると、分類器５は、ＲＡＭ３に格納されたパケットＹを走査し、パケットＹの分類情報を取得し、パケットＹと対応するエントリを探索する。分類器５は、パケットＹと、プロトコル処理部２Ａが利用する付加情報と、をプロトコル処理部２Ａに通知する。
【００７７】
ここで通知される付加情報は、例えば、ＩＰｓｅｃの処理に必要なＳＡ（Security Association）を特定するＳＰＩ（Security Parameters Index）である。なお、この時点では、パケットの一部又は全部が暗号化されているため、Ｌ２ＴＰｖ３ヘッダ以降の情報は取得できない。また、分類器５は、パケットＹに対応するエントリを発見できない場合には、第１実施形態と同様、パケットＹをプロセッサ１に通知する。
【００７８】
パケットＹを通知されたプロトコル処理部２Ａは、通知された付加情報を利用して、パケットＹに対して復号処理を実行する。これにより、パケットＹは、Ｌ２ＴＰｖ３のパケットとなる。プロトコル処理部２Ａは、復号したパケットＹを分類器５に通知する。
【００７９】
次に、プロトコル処理部２Ａから通知された分類器５は、プロトコル処理部２Ａによる処理されたパケットＹと、プロトコル処理部２Ｂが利用する付加情報と、をプロトコル処理部２Ｂに通知する。ここで通知される付加情報は、例えば、Ｌ２ＴＰｖ３のトンネル管理情報（セッションＩＤなど）を識別する情報である。
【００８０】
パケットＹを通知されたプロトコル処理部２Ｂは、通知された付加情報を利用して、パケットＹを処理する。すなわち、プロトコル処理部２Ｂは、Ｌ２ＴＰｖ３トンネルに従って、パケットＹのカプセル化を解除する。プロトコル処理部２Ｂは、カプセル化を解除したパケットＹを分類器５に通知する。
【００８１】
さらに、プロトコル処理部２Ｂから通知された分類器５は、プロトコル処理部２Ｂにより処理されたパケットＹを、プロセッサ１に通知する。パケットＹを通知されたプロセッサ１は、パケットＹが自ノード宛か判定する。プロセッサ１は、パケットＹが自ノード宛でない場合、パケットＹを宛先ノードに送信してもよいし、処理を終了してもよい。なお、パケットＹが自ノード宛かの判定は、分類器５が行ってもよい。
【００８２】
このように、本実施形態において、分類器５は、通信装置５が受信したパケットを、各プロトコル処理部２に応じた付加情報と共に、各プロトコル処理部２に複数回通知する。
【００８３】
分類器５は、パケットを通知するプロトコル処理部２を、例えば、通知の回数（プロトコル処理部２による処理の回数）に応じて決定すればよい。
【００８４】
処理の回数は、分類器５が管理してもよいし、分類器５及び各プロトコル処理部２により共同で管理されてもよい。処理の回数の管理方法として、例えば、分類器５がプロトコル処理部２にパケット及び付加情報を通知する際に、処理の回数を示すカウンタを含むディスクリプタをプロトコル処理部２に通知する方法が考えられる。プロトコル処理部２がパケットを処理する毎に、カウンタを変更（インクリメント又はデクリメント）させることにより、処理の回数を把握することができる。カウンタの変更は、分類器５又はパケットを処理したプロトコル処理部２が実行すればよい。
【００８５】
なお、以上では、プロトコル処理部２Ａ，２ＢがＩＰｓｅｃ及びＬ２ＴＰｖ３をそれぞれ処理する場合について説明したが、本実施形態において、各プロトコル処理部２が処理するプロトコルの組合せは任意である。このような組み合わせとして、例えば、ＩＰｓｅｃ（トランスポートモード）とＴＣＰ、ＧＲＥとＩＰｖ６データグラム、ＴＣＰとＳＳＬ／ＴＬＳ、及びＵＤＰとＤＴＬＳなどの組合せが挙げられる。
【００８６】
次に、本実施形態におけるエントリについて説明する。
【００８７】
図７は、本実施形態におけるエントリの一例を示す図である。図７の例では、付加情報毎に、その付加情報を利用するプロトコル処理部２の識別子が対応付けられている。各エントリには、パケットの分類情報（ｓｒｃ  ＩＰ、ｄｓｔ  ＩＰ、Ｐｒｏｔｏｃｏｌ、ｓｒｃ  Ｐｏｒｔ、ｄｓｔ  Ｐｏｒｔ）と、１回目〜３回目にパケットを処理するプロトコル処理部２の識別子（ＰＲＯＣ１〜ＰＲＯＣ３）と、１回目〜３回目に通知する付加情報の識別子（ＩＤ１〜ＩＤ３）と、が含まれる。
【００８８】
例えば、図７の１行目のエントリは、ＰＲＯＣ１が２Ｂ、ＩＤ１がＣＩＤ１_１、ＰＲＯＣ２が２Ａ、ＩＤ２がＣＩＤ１_２、ＰＲＯＣ３及びＩＤ３が空値である。これは、このエントリに対応するパケットは、１回目にプロトコル処理部２Ｂによりプロトコル処理され、２回目にプロトコル処理部２Ａによりプロトコル処理されることを示している。また、プロトコル処理部２Ｂに通知される付加情報の識別子はＣＩＤ１_１であり、プロトコル処理部２Ａに通知される付加情報の識別子はＣＩＤ１_２である。
【００８９】
例えば、図７の１行目のエントリと対応するパケットを通信装置が受信した場合、分類器５は、まず、図７の１行目のエントリを参照して、プロトコル処理部２Ｂにパケット及び付加情報の識別子（ＣＩＤ１_１）を通知する。
【００９０】
次に、プロトコル処理部２Ｂからパケットを通知された分類器５は、所定の領域に格納された１行目のエントリを再び参照し、プロトコル処理部２Ａにパケット及び付加情報の識別子（ＣＩＤ１_２）を通知する。
【００９１】
図７の１行目のエントリには、３回目に処理するプロトコル処理部２のＩＤ及び付加情報の識別子が設定されていないため、プロトコル処理部２Ａがパケットを処理した後、通信装置によるパケットの処理は終了する。
【００９２】
このように、本実施形態では、同一のエントリが繰り返し参照されるため、分類器５は、ＬＵＴを探索して発見したパケットと対応するエントリを、ＬＵＴＲＡＭ６の所定の領域（キャッシュエントリなど）に格納するのが好ましい。これにより、同一のエントリを参照するために、繰り返しＬＵＴを探索する必要がなくなるため、処理のオーバヘッドを削減できる。
【００９３】
図８は、本実施形態におけるエントリの他の例を示す図である。図８のエントリは、図７のエントリと対応している。図８の例では、ＬＵＴは、プロトコル処理部２毎に設けられている。各ＬＵＴのエントリには、パケットの分類情報（ｓｒｃ  ＩＰ、ｄｓｔ  ＩＰ、Ｐｒｏｔｏｃｏｌ、ｓｒｃ  Ｐｏｒｔ、ｄｓｔ  Ｐｏｒｔ）と、各プロトコル処理部２に通知する付加情報の識別子（ＩＤ）と、が含まれている。
【００９４】
例えば、プロトコル処理部２ＡのＬＵＴの１行目のエントリは、ＩＤがＣＩＤ１_２である。また、プロトコル処理部２ＢのＬＵＴの１行目のエントリは、ＩＤがＣＩＤ１_１である。
【００９５】
図８のエントリを利用する場合、分類器５は、処理の回数に応じて参照するＬＵＴを選択し、選択したＬＵＴの中からパケットの分類情報に合致するエントリを探索してもよい。
【００９６】
なお、ＩＰｓｅｃの例やトンネルプロトコルの例の場合、最初に分類器５が認識できた識別情報と、プロトコル処理後に認識できた識別情報と、が異なる場合がある。例えばＩＰｓｅｃの場合、復号されることでＩＰｓｅｃに関するヘッダが無くなり、平文のパケットが参照できるようになる。これにより、例えば、ＴＣＰヘッダやＵＤＰヘッダが参照できるようになる。
【００９７】
図８のエントリは、このような状況に対して、１つの受信パケットに対して参照されるエントリが１つになるように構成されてもよいし、識別情報の変更に合わせて、異なるエントリが参照されるように構成されてもよい。１つの受信パケットに対して参照されるエントリが１つになるようにエントリを構成する場合、処理回数などによって識別に用いるフィールドを調整すればよい。
【００９８】
図９は、図８の変化形である。図９の例では、パケットの処理段階に応じて変化し得る分類情報ではなく、通信装置全体でユニークであり、かつ、パケットフォーマットに依存しない識別子ＦＩＤが利用されている。
【００９９】
例えば、識別子ＦＩＤは、分類器５がパケットのヘッダなどを参照して設定すればよい。また、設定された識別子ＦＩＤは、プロトコル処理に影響されないパケットの領域に格納されてもよいし、分類器５と各プロトコル処理部２との間で、パケットと共にやり取りされる情報（ディスクリプタなど）に含まれてもよい。
【０１００】
図９の例では、識別子ＦＩＤは、各ＬＵＴに共通しているが、図１０に示すように、各ＬＵＴで共通していなくてもよい。図１０の例では、識別子ＦＩＤは、パケットのフォーマットに依存せず、かつ、各プロトコル処理部２でユニークな値である。
【０１０１】
なお、図７のエントリは、パケットを処理するプロトコル処理部２の順番を含むため、分類器５は、パケットの処理回数に応じて、パケットをどのプロトコル処理部２に通知するか判定できる。しかしながら、図８〜図１０のエントリは、図７のエントリと異なり、パケットを処理するプロトコル処理部２の順番を含まない。このため、分類器５は、ＬＵＴを参照しても、パケットをどのプロトコル処理部２に通知してよいのか判断できない。
【０１０２】
そこで、図８〜図１０のエントリを利用する場合には、分類器５は、パケットを通知するプロトコル処理部２を、パケットを参照して選択することが考えられる。例えば、分類器５は、パケットのプロトコルフィールドを参照して、プロトコル処理部２を選択してもよいし、パケットのヘッダ領域を解析してプロトコル処理部２を選択してもよい。
【０１０３】
また、分類器５がプロトコル処理部２を選択する代わりに、各エントリの分類情報に処理の回数を追加してもよい。これにより、分類器５は、処理の回数に応じた適切なエントリを探索することができる。
【０１０４】
以上説明した本実施形態におけるエントリは、第１実施形態と同様の方法で生成される。すなわち、プロセッサ１が、対応するエントリが無いパケットを処理し、処理の過程で得られたパケットの分類情報及び付加情報に基づいて、エントリを生成し、ＬＵＴに格納する。
【０１０５】
本実施形態において、プロセッサ１が実行するパケット処理は、予め各プロトコル処理部２が実行可能な部分を特定されている。したがって、プロセッサ１は、実行したパケット処理に対応するプロトコル処理部２毎にエントリを生成することができる。
【０１０６】
例えば、図７の１行目のエントリに対応するパケットをプロセッサ１がパケット処理した場合、プロセッサ１は、プロトコル処理部２Ｂが実行可能なプロトコル処理と、プロトコル処理部２Ａが実行可能なプロトコル処理と、を実行する。
【０１０７】
そして、プロセッサ１は、パケットの分類情報と、１回目に処理するプロトコル処理部２Ｂの識別子（２Ｂ）と、プロトコル処理部２Ｂが利用する付加情報の識別子（ＣＩＤ１_１）と、２回目に処理するプロトコル処理部２Ａの識別子（２Ａ）と、プロトコル処理部２Ａが利用する付加情報の識別子（ＣＩＤ１_２）と、を含むエントリ（すなわち、図７の１行目のエントリ）を生成する。
【０１０８】
図７の形式のエントリの場合、プロセッサ１は、全てのパケット処理が終了した後で、エントリを生成してもよいし、いずれかのプロトコル処理部２が実行可能な処理が終了する毎にエントリを更新してもよい。
【０１０９】
また、図８〜図１０の形式の場合には、プロセッサ１は、いずれかのプロトコル処理部２が実行可能な処理が終了する度に、各プロトコル処理部２のＬＵＴにエントリを追加すればよい。
【０１１０】
ここで、分類器５による付加情報の通知方法について、図１１〜図１３を参照して具体的に説明する。以下では、２つの通知方法について説明する。
【０１１１】
第１の方法として、複数の付加情報を１つずつ通知する方法が考えられる。この方法では、分類器５は、各プロトコル処理部２に通知するディスクリプタに、各プロトコル処理部２が利用する付加情報の識別子を記載する。各プロトコル処理部２は、通知された付加情報の識別子に基づいて付加情報を取得し、パケットをプロトコル処理し、処理後のパケットを分類器５に通知すればよい。
【０１１２】
第１の方法において、処理を終了するタイミングは、処理の回数に応じて判定することができる。具体的には、分類器５は、ディスクリプタに処理の回数を示すカウンタを記載し、プロトコル処理部２が処理する度に、カウンタを変更し、カウンタが終了回数になったか判定すればよい。上述の通り、カウンタの変更は、プロトコル処理部２から通知された分類器５が行なってもよいし、パケットを処理したプロトコル処理部２が行なってもよい。
【０１１３】
終了回数は、パケットに対応するエントリから取得できる。図７の形式のエントリの場合、終了回数は、各エントリに含まれるプロトコル処理部２の識別子の数である。例えば、図７の１行目のエントリには、プロトコル処理部２の識別子が２つ含まれるため、このエントリに対応するパケットの終了回数は２回である。
【０１１４】
また、図８〜図１０の形式のエントリの場合、終了回数は、パケットに対応するエントリの数である。例えば、図８の１行目のエントリに対応するパケットの場合、このパケットに対応するエントリは２つあるため、終了回数は２回である。
【０１１５】
また、処理を終了するタイミングの判定は、プロトコル処理部２が行なってもよい。このような方法として、処理の終了又は継続を示すフラグを用いる方法が考えられる。分類器５が、ディスクリプタなどにフラグを記載し、ディスクリプタを通知されたプロトコル処理部２が、フラグに応じて処理を終了するか判定すればよい。フラグは、処理の回数に応じて分類器５が変更すればよい。
【０１１６】
なお、第１の方法では、分類器５は、処理の回数やフラグと共に、パケットを次に処理するプロトコル処理部２のＩＤや、参照するエントリを特定する情報などを、ディスクリプタに記載してもよい。これにより、分類器５がエントリを探索したり参照したりする処理のオーバヘッドを削減することができる。
【０１１７】
図１１は、第１の方法の一例を示す図である。図１１の例では、分類器５は、１回目に、パケット及びディスクリプタを、プロトコル処理部２Ｂに通知している。ディスクリプタには、プロトコル処理部２Ｂの識別子（ＰＲＯＣ＝２Ｂ）と、付加情報の識別子（ＩＤ＝ＣＩＤ１_２）と、が記載され、継続フラグ（ＣＯＮＴ＝Ｙ）が立っている。継続フラグ（ＣＯＮＴ＝Ｙ）は、処理の継続を示す。
【０１１８】
分類器５から通知されたプロトコル処理部２Ｂは、付加情報の識別子ＣＩＤ１_２に基づいて付加情報を取得し、プロトコル処理を実行する。継続フラグが立っているため、プロトコル処理部２Ｂは、処理後のパケットを分類器５に通知する。
【０１１９】
分類器２は、２回目に、パケット及びディスクリプタを、プロトコル処理部２Ａに通知している。ディスクリプタには、プロトコル処理部２Ａの識別子（ＰＲＯＣ＝２Ａ）と、付加情報の識別子（ＩＤ＝ＣＩＤ１_１）と、が記載され、継続フラグはクリア（ＣＯＮＴ＝Ｎ）されている。継続フラグのクリア（ＣＯＮＴ＝Ｎ）は、処理の終了を示す。
【０１２０】
分類器５から通知されたプロトコル処理部２Ａは、付加情報の識別子ＣＩＤ１_１に基づいて付加情報を取得し、プロトコル処理を実行する。継続フラグはクリアされているため、プロトコル処理部２Ａは、処理後のパケットを分類器５に通知せず、処理を終了している。
【０１２１】
なお、図１１の例では、分類器５と各プロトコル処理部２との間で、パケットがやりとりされているが、パケットの代わりに、パケットの識別子が通知されてもよい。パケットの識別子は、例えば、ディスクリプタに記載すればよい。ディスクリプタを通知されたプロトコル処理部２は、ディスクリプタに記載されたパケットの識別子に基づいてパケットを取得することができる。
【０１２２】
また、図１１の例では、分類器５とプロトコル処理部２との間で、ディスクリプタがやりとりされているが、ディスクリプタは、ＲＡＭ３上に格納されていてもよい。分類器５や各プロトコル処理部２は、ＲＡＭ３上に確保された特別な領域をキューとして扱い、保存されているディスクリプタを順次参照すればよい。
【０１２３】
なお、分類器５は、ディスクリプタの存在を各プロトコル処理部２に通知するために、各プロトコル処理部２のレジスタや、割り込み信号を利用してもよい。これらの方法は、実装に応じて適切な方法を選択すればよい。
【０１２４】
また、ディスクリプタをＲＡＭ３に格納する場合、ディスクリプタの書き込み先によって対応するプロトコル処理部２が特定される。このため、ディスクリプタには、プロトコル処理部２の識別子（ＰＲＯＣ）は記載されなくてもよい。
【０１２５】
以上説明した第１の方法は、ディスクリプタの代わりに、パケットを利用しても実現できる。分類器５は、付加情報の識別子、処理回数、フラグなどの情報を、処理により影響されないパケットの空き領域（処理済み領域や未使用領域）に記載して、プロトコル処理部２に通知すればよい。
【０１２６】
図１２は、パケットの空き領域を利用した第１の方法の他の例を示す図である。図１２の例では、パケットの宛先ＭＡＣアドレス（Ｄｓｔ  ＭＡＣ  Ａｄｄｒ）に付加情報の識別子が記載されている。パケットを通知されたプロトコル処理部２は、パケットを参照することにより、付加情報の識別子などの情報を取得することができる。
【０１２７】
第２の方法として、複数の付加情報を一括して通知する方法が考えられる。この方法では、分類器５は、各プロトコル処理部２に通知するディスクリプタに、複数のプロトコル処理部２がそれぞれ利用する付加情報の識別子を一括して記載する。分類器５は、付加情報の識別子と共に、各プロトコル処理部２の識別子をディスクリプタに記載してもよい。各プロトコル処理部２は、通知されたディスクリプタから、自ノードが利用する付加情報の識別子を選択する。そして、プロトコル処理部２は、選択した付加情報の識別子に基づいて付加情報を取得し、パケットをプロトコル処理し、処理後のパケットを分類器５に通知すればよい。
【０１２８】
図７の形式のエントリがＬＵＴに格納されている場合、分類器５は、エントリに含まれる付加情報の識別子（ＩＤ１〜ＩＤ３）を、一括してディスクリプタに記載すればよい。また、図８〜図１０の形式のエントリが各ＬＵＴに格納されている場合、分類器５は、パケットを走査して、パケットが対応する複数のエントリを特定し、各エントリに含まれる付加情報の識別子を、一括してディスクリプタに記載すればよい。
【０１２９】
ディスクリプタに複数のプロトコル処理部２のＩＤ及び付加情報の識別子を記載する方法として、プロトコル処理部２のＩＤ及び付加情報の識別子を単純に並べて記載する方法や、プロトコル処理の順番を考慮して、プロトコル処理部２のＩＤ及び付加情報の識別子をスタック状に並べて記載する方法などが考えられる。
【０１３０】
各プロトコル処理部２は、自ノードが利用する付加情報の識別子を、ディスクリプタに記載されたプロトコル処理部２の識別子を参照して選択してもよいし、分類器５から別途通知されてもよい。また、分類器５は、各プロトコル処理部２が利用すべき付加情報の識別子が何番目かを示す番号をディスクリプタに記載してもよい。
【０１３１】
図１３は、第２の通知方法の一例を示す図である。図１３の例では、分類器５からプロトコル処理部２に通知するディスクリプタに、プロトコル処理部２のＩＤ及び付加情報の識別子が、処理の順番に従ってスタック状に並べて記載されている。また、ディスクリプタには、プロトコル処理部２が利用すべき付加情報の識別子が何番目に記載されているかを示す番号（ＣＯＵＮＴ）が記載されている。図１３の例では、プロトコル処理部２Ｂは、ＣＯＵＮＴが１であるため、ディスクリプタに記載された１番目の付加情報の識別子（ＣＩＤ１_２）に基づいて付加情報を取得する。
【０１３２】
ディスクリプタに記載された番号ＣＯＵＮＴは、分類器５がプロトコル処理部２から処理後のパケットを通知される度に変更してもよいし、処理を終了したプロトコル処理部２が変更してもよい。
【０１３３】
プロトコル処理部２が番号ＣＯＵＮＴを変更する場合には、プロトコル処理部２は、処理後のパケットを分類器５に返さなくてもよい。この場合、プロトコル処理部２は、変更された番号に記載された識別子により特定されるプロトコル処理部２に、処理後のパケットを通知すればよい。
【０１３４】
例えば、図１３の例では、プロトコル処理部２Ｂが１回目の処理を終了した後、番号ＣＯＵＮＴを２に変更する。プロトコル処理部２Ｂは、ディスクリプタの２番目に記載されたプロトコル処理部２の識別子（２Ａ）を参照して、処理後のパケットをプロトコル処理部２Ａに通知すればよい。
【０１３５】
なお、各プロトコル処理部２は、ディスクリプタの１番目に記載された付加情報の識別子を参照してもよい。この場合、分類器５は、プロトコル処理部２からパケットを通知される度に、処理の回数に応じて付加情報の識別子の順番を並べ替えることにより可能となる。また、第２の方法は、第１の方法と同様に、ディスクリプタの代わりに、パケットの空き領域を利用しても実現可能である。
【０１３６】
次に、本実施形態に係る通信装置の動作について、図１４〜図１７を参照して説明する。図１４は、本実施形態に係る通信装置のパケット受信時の動作を示すフローチャートである。図１４のフローチャートステップＳ１〜Ｓ５，Ｓ８は、図３と同様である。
【０１３７】
本実施形態では、分類器５がパケットと対応するエントリを発見した場合（ステップＳ５のＹＥＳ）、複数のプロトコル処理部２によるプロトコル処理が実行される（ステップＳ１２）。また、分類器５がパケットと対応するエントリを発見できず（ステップＳ５のＮＯ）、分類器５がプロセッサ１にパケットを通知した場合、プロセッサ１が複数のパケット処理を実行する（ステップＳ１３）。以下、ステップＳ１２，Ｓ１３について説明する。
【０１３８】
図１５は、複数のプロトコル処理部２によるプロトコル処理の一例を示すフローチャートである。図１５のフローチャートは、図１４のステップＳ１２に相当する。図１５の処理では、付加情報の識別子は、１つずつ通知される。以下では、エントリは、図７の形式であるものとする。
【０１３９】
まず、分類器５は、カウンタｉを１に設定する（ステップＳ１２０１）。
【０１４０】
次に、分類器５は、パケットに対応するエントリからｉ番目の付加情報の識別子（ＩＤｉ）を抽出する（ステップＳ１２０２）。
【０１４１】
続いて、分類器５は、抽出した付加情報の識別子を含むディスクリプタを生成する（ステップＳ１２０３）。このディスクリプタには、図１１のように、フラグＣＯＮＴが設定される。
【０１４２】
そして、分類器５は、パケットに対応するエントリにｉ＋１番目のプロトコル処理部２（ＰＲＯＣｉ＋１）があるか判定する（ステップＳ１２０４）。分類器５は、ＰＲＯＣｉ＋１がある場合（ステップＳ１２０４のＹＥＳ）、ディスクリプタのＣＯＮＴをＹに設定する（ステップＳ１２０５）。一方、分類器５は、ＰＲＯＣｉ＋１がない場合（ステップＳ１２０４のＮＯ）、ディスクリプタのフラグＣＯＮＴを終了フラグＮに設定する（ステップＳ１２０６）。その後、分類器５は、ｉ番目のプロトコル処理部２（ＰＲＯＣｉ）にディスクリプタを通知する（ステップＳ１２０７）
【０１４３】
分類器５から通知されたプロトコル処理部２は、ディスクリプタに含まれる付加情報の識別子を用いて付加情報を取得し、パケットに対してプロトコル処理を実行する（ステップＳ１２０８）。
【０１４４】
プロトコル処理部２は、プロトコル処理後、ディスクリプタのフラグＣＯＮＴが終了フラグＹか判定する（ステップＳ１２０９）。プロトコル処理部２は、ＣＯＮＴ＝Ｙの場合（ステップＳ１２０９のＹＥＳ）、カウンタｉを変更し（ステップＳ１２１０）、処理後のパケットを分類器５に通知する。なお、カウンタｉの変更は、分類器５が行なってもよい。
【０１４５】
一方、プロトコル処理部２は、ＣＯＮＴ＝Ｎの場合（ステップＳ１２０９のＮＯ）、処理を終了する。これにより、複数のプロトコル処理部２によるプロトコル処理が終了する。
【０１４６】
例えば、通信装置が図７の１行目のエントリに対応するパケットを受信した場合、分類器５は、カウンタｉを１に設定し（ステップＳ１２０１）、付加情報の識別子ＣＩＤ１_１を抽出し（ステップＳ１２０１）、識別子ＣＩＤ１_１を含むディスクリプタを生成する（ステップＳ１２０３）。
【０１４７】
図７の１行目のエントリにはＰＲＯＣ２があるため（ステップＳ１２０４のＹＥＳ）、分類器５は、ディスクリプタのＣＯＮＴをＹに設定し（ステップＳ１２０５）、ディスクリプタをプロトコル処理部２Ｂに通知する（ステップＳ１２０７）。
【０１４８】
プロトコル処理部２Ｂは、識別子ＣＩＤ１_１に基づいてＲＡＭ３から付加情報を取得し、パケットをプロトコル処理する（ステップＳ１２０８）。プロトコル処理部２Ｂが通知されたディスクリプタのＣＯＮＴはＹであるため（ステップＳ１２０９のＹＥＳ）、プロトコル処理部２Ｂは、カウンタｉを変更し（ステップＳ１２１０）、処理後のパケットを分類器５に通知する。
【０１４９】
プロトコル処理部２Ｂから通知された分類器５は、付加情報の識別子ＣＩＤ１_２を抽出し（ステップＳ１２０２）、識別子ＣＩＤ１_２を含むディスクリプタを生成する（ステップＳ１２０３）。
【０１５０】
図７の１行目のエントリにはＰＲＯＣ３がないため（ステップＳ１２０４のＮＯ）、分類器５は、ディスクリプタのフラグＣＯＮＴを終了フラグＮに設定し（ステップＳ１２０６）、ディスクリプタをプロトコル処理部２Ａに通知する（ステップＳ１２０７）。
【０１５１】
プロトコル処理部２Ａは、識別子ＣＩＤ１_２に基づいてＲＡＭ３から付加情報を取得し、パケットをプロトコル処理する（ステップＳ１２０８）。プロトコル処理部２Ａが通知されたディスクリプタのフラグＣＯＮＴは終了フラグＮであるため（ステップＳ１２０９のＮＯ）、プロトコル処理部２Ａは、プロトコル処理の終了後、処理を終了する。
【０１５２】
このように、付加情報を１つずつ通知することで、複数のプロトコル処理部２によるプロトコル処理を実行することができる。
【０１５３】
図１６は、複数のプロトコル処理部２によるプロトコル処理の他の例を示すフローチャートである。図１６のフローチャートは、図１４のステップＳ１２に相当する。図１６の処理では、付加情報の識別子は一括して通知される。以下では、エントリは、図７の形式であるものとする。
【０１５４】
まず、分類器５は、カウンタｉを１に設定する（ステップＳ１２１１）。次に、分類器５は、パケットに対応するエントリからｉ番目の付加情報の識別子（ＩＤｉ）及びプロトコル処理部（ＰＲＯＣｉ）を抽出する（ステップＳ１２１２）。
【０１５５】
続いて、分類器５は、抽出した付加情報の識別子及びプロトコル処理部２をディスクリプタに追加し（ステップＳ１２１３）、カウンタｉを変更する（ステップＳ１２１４）。
【０１５６】
そして、分類器５は、パケットに対応するエントリにｉ番目のプロトコル処理部２（ＰＲＯＣｉ）があるか判定する（ステップＳ１２１５）。ＰＲＯＣｉがある場合（ステップＳ１２１５のＹＥＳ）、処理はステップＳ１２１２に戻る。
【０１５７】
一方、ＰＲＯＣｉがない場合（ステップＳ１２１５のＮＯ）、分類器５は、カウンタｊを１に設定し（ステップＳ１２１６）、ディスクリプタをｊ番目のプロトコル処理部２（ＰＲＯＣｊ）に通知する（ステップＳ１２１７）。
【０１５８】
ディスクリプタを通知されたプロトコル処理部２は、ディスクリプタのｊ番目の付加情報の識別子に基づいて付加情報を取得し、パケットをプロトコル処理し（ステップＳ１２１８）、カウンタｊを変更する（ステップＳ１２１９）。
【０１５９】
その後、プロトコル処理部２は、ディスクリプタにｊ番目のプロトコル処理部２（ＰＲＯＣｊ）があるか判定する（ステップＳ１２２０）。ＰＲＯＣｊがある場合（ステップＳ１２２０のＹＥＳ）、処理はステップＳ１２１７に戻る。一方、ＰＲＯＣｊがない場合（ステップＳ１２２０のＮＯ）、処理は終了する。
【０１６０】
例えば、通信装置が図７の１行目のエントリに対応するパケットを受信した場合、分類器５は、カウンタｉを１に設定し（ステップＳ１２１１）、１番目の付加情報の識別子ＣＩＤ１_１及びプロトコル処理部２のＩＤ（２Ｂ）を抽出し（ステップＳ１２１２）、ディスクリプタに追加し（ステップＳ１２１３）、カウンタｉを変更する（ステップＳ１２１４）。
【０１６１】
図７の１行目のエントリにはＰＲＯＣ２があるため（ステップＳ１２１５のＹＥＳ）、分類器５は、２番目の付加情報の識別子ＣＩＤ１_１及びプロトコル処理部２のＩＤ（２Ａ）を抽出し（ステップＳ１２１２）、ディスクリプタに追加し（ステップＳ１２１３）、カウンタｉを変更する（ステップＳ１２１４）。
【０１６２】
図７の１行目のエントリにはＰＲＯＣ３がないため（ステップＳ１２１５のＮＯ）、カウンタｊを１に設定し（ステップＳ１２１６）、ディスクリプタをプロトコル処理部２Ｂに通知する（ステップＳ１２１７）。
【０１６３】
ディスクリプタを通知されたプロトコル処理部２Ｂは、ディスクリプタに記載された１番目の付加情報の識別子ＣＩＤ１_２に基づいて、ＲＡＭ３から付加情報を取得し、パケットをプロトコル処理し（ステップＳ１２１８）、カウンタｊを変更する（ステップＳ１２１９）。
【０１６４】
ディスクリプタには、２番目のプロトコル処理部２のＩＤがあるため（ステップＳ１２２０のＹＥＳ）、プロトコル処理部２Ｂは、処理後のパケット及びディスクリプタを、２番目のプロトコル処理部２Ａに通知する（ステップＳ１２１７）。
【０１６５】
通知されたプロトコル処理部２Ａは、ディスクリプタに記載された２番目の付加情報の識別子ＣＩＤ１_１に基づいて、ＲＡＭ３から付加情報を取得し、パケットをプロトコル処理し（ステップＳ１２１８）、カウンタｊを変更する（ステップＳ１２１９）。
【０１６６】
ディスクリプタには、３番目のプロトコル処理部２のＩＤがないため（ステップＳ１２２０のＮＯ）、プロトコル処理部２Ａは、パケットをプロトコル処理後、処理を終了する。
【０１６７】
このように、付加情報を一括して通知することで、複数のプロトコル処理部２によるプロトコル処理を実行することができる。
【０１６８】
図１７は、プロセッサ１による複数のプロトコル処理の一例を示すフローチャートである。図１７のフローチャートは、図１４のステップＳ１３に相当する。図１７の処理では、１つのプロトコル処理が実行される毎に、エントリが更新される。
【０１６９】
まず、プロセッサ１は、カウンタｉを１に設定する（ステップＳ１３０１）。
【０１７０】
次に、プロセッサ１は、ｉ番目に実行するプロトコル処理を特定し（ステップＳ１３０２）、特定したｉ番目のプロトコル処理を実行する（ステップＳ１３０３）。
【０１７１】
プロセッサ１は、プロトコル処理を実行後、対応するプロトコル処理部２、すなわち、ｉ番目のプロトコル処理を実行可能なプロトコル処理部２があるか判定する（ステップＳ１３０４）。
【０１７２】
対応するプロトコル処理部２がない場合（ステップＳ１３０４のＮＯ）、処理はステップＳ１３０８に進む。一方、対応するプロトコル処理部２がある場合（ステップＳ１３０４のＹＥＳ）、プロセッサ１は、対応するプロトコル処理部２が利用する付加情報を特定する（ステップＳ１３０５）。
【０１７３】
プロセッサ１は、特定した付加情報の識別子と、対応するプロトコル処理部２のＩＤとを、パケットに対応するエントリに追加することで、エントリを更新する（ステップＳ１３０６）。パケットに対応するエントリがない場合には、プロセッサ１は、パケットの分類情報を含むエントリを作成した後、作成したエントリに付加情報の識別子及びプロトコル処理部２のＩＤを追加する。
【０１７４】
プロセッサ１は、更新したエントリを、ＬＵＴＲＡＭ６に記憶されたＬＵＴに追加し、ＬＵＴを更新する（ステップＳ１３０７）。
【０１７５】
そして、プロセッサ１は、パケットに対する全てのプロトコル処理を終了したか判定する（ステップＳ１３０８）。全てのプロトコル処理が終了していない場合（ステップＳ１３０９）、プロセッサ１は、カウンタｉを変更する（ステップＳ１３０９）。その後、処理はステップＳ１３０２に戻る。
【０１７６】
一方、全てのプロトコル処理を終了した場合（ステップＳ１３０８のＹＥＳ）、プロセッサ１は処理を終了する。これにより、プロセッサ１による複数のプロトコル処理が終了する。
【０１７７】
なお、図１７の例では、プロセッサ１は、１つのプロトコル処理を実行する度に、エントリを更新しているが、全てのプロトコル処理を実行した後で、エントリをまとめて更新してもよい。
【０１７８】
以上説明した通り、本実施形態に係る通信装置によれば、分類器５は、複数のプロトコル処理部２に付加情報をそれぞれ通知することができる。したがって、通信装置が複数のプロトコル処理部２を備える場合であっても、第１実施形態と同様に、処理のオーバヘッドを削減し、プロトコル処理部２によるプロトコル処理に要する時間を短縮できる。
【０１７９】
なお、本実施形態においても、第１実施形態と同様、ＬＵＴに格納されたエントリは、一連の通信が終了した後、削除される。ただし、図８〜図１０の形式のエントリを利用する場合、終了した通信に応じた一部のプロトコル処理部２に対応するエントリだけが削除されてもよい。
【０１８０】
このような場合として、あるプロトコルによる通信（接続）を、他の複数のプロトコルによる通信（接続）が同時に利用する場合が挙げられる。例えば、ＴＣＰ接続及びその上で動作する複数のＨＴＴＰ接続や、ＵＤＰ接続及びその上で動作する複数のＶＰＮ接続などが考えられる。このような場合には、通信が終了した他のプロトコルに対応するエントリだけを削除すればよい。
【０１８１】
（第３実施形態）
第３実施形態に係る通信装置について、図１８〜図２０を参照して説明する。上述の各実施形態では、プロトコル処理部２は、実行するプロトコル処理の内容が予め決まっていた。これに対して、本実施形態では、通信装置が、汎用のプロトコル処理部２を備える場合について説明する。
【０１８２】
図１８は、本実施形態に係る通信装置の論理的な接続関係を示す図である。図１８に示すように、この通信装置は、記憶部７を備える。また、プロトコル処理部２Ｃの代わりに、汎用プロトコル処理部２Ｘを備える。他の構成は、第２実施形態と同様である。
【０１８３】
汎用プロトコル処理部２Ｘは、汎用のプロトコル処理部２である。汎用プロトコル処理部２Ｘは、実行するプロトコル処理が予め定められた専用のプロトコル処理部２Ａ，２Ｂとは異なり、実行するプロトコル処理が予め定められておらず、複数のプロトコル処理を実行可能である。
【０１８４】
汎用プロトコル処理部２Ｘは、実行するソフトウェアを変更したり、動的再構成プロセッサやＦＰＧＡのように、ハードウェアの実行ロジックを変更したりすることにより、複数のプロトコル処理を実行する。なお、通信装置は、汎用のプロトコル処理部２を複数備えてもよい。
【０１８５】
記憶部７は、汎用プロトコル処理部２Ｘが利用する記憶部である。記憶部７は、汎用プロトコル処理部２Ｘが実行するソフトウェアやロジックの構成データなどを格納する。記憶部７は、プロセッサ１が利用する記憶部（例えば、ＲＡＭ３）と共用であってもよいし、汎用プロトコル処理部２Ｘに専用の記憶部であってもよい。また、専用の記憶部と共用の記憶部とにより記憶部７が構成されてもよい。
【０１８６】
ここで、本実施形態におけるエントリについて説明する。本実施形態において、汎用プロトコル処理部２Ｘが対応するエントリには、汎用プロトコル処理部２Ｘが実行するプロトコル処理を特定する情報（以下、「プログラム識別子」という）と、特定されたプロトコル処理において必要となる付加情報と、が含まれる。プログラム識別子は、プロトコル処理で利用される付加情報に対応付けられる。
【０１８７】
プログラム識別子には、汎用プロトコル処理部２Ｘが実行するプログラム、関数、及びＡＰＩ（Application Programming Interface）などを特定する識別子が含まれる。プログラムを特定するプログラム識別子として、例えば、プログラム名、プログラムが格納されたファイル名、プログラムのエントリポイント（プログラムが格納された記憶部７のアドレス）などが利用される。また、関数を特定するプログラム識別子として、関数名や関数のエントリポイントなどが利用される。さらに、ＡＰＩを特定するプログラム識別子として、ＡＰＩ名やＡＰＩのエントリポイントなどが利用される。
【０１８８】
図１９は、本実施形態におけるエントリの一例を示す図である。図１９のエントリは、第１実施形態における図７のエントリに対応している。図１９の例では、各エントリに、ＰＲＯＧ１，ＰＲＯＧ２というフィールドが追加されている。このフィールドには、プログラム識別子が格納される。例えば、図１９の２行目のエントリは、ＰＲＯＣ２が２Ｘ、ＩＤ２がＣＩＤ２_２、ＰＲＯＧ２がＰｒ２_２である。これは、汎用プロトコル処理部２Ｘが、識別子ＣＩＤ２_２で特定される付加情報を用いて、プログラム識別子Ｐｒ２_２で特定されるプロトコル処理を実行することを示している。
【０１８９】
図２０は、本実施形態におけるエントリの他の例を示す図である。図２０のエントリは、第１実施形態における図８のエントリに対応している。図２０のプロトコル処理部２Ａ，２ＢのＬＵＴは、図８と同様である。図２０の例では、プロコトル処理部２ＸのＬＵＴに、ＰＲＯＧというフィールドが追加されている。このフィールドには、プログラム識別子が格納される。例えば、図２０の汎用プロトコル処理部２Ｘの１行目のエントリは、ＩＤがＣＩＤ２_２、ＰＲＯＧがＰｒ２_２である。これは、汎用プロトコル処理部２Ｘが、識別子ＣＩＤ２_２で特定される付加情報を用いて、プログラム識別子Ｐｒ２_２で特定されるプロトコル処理を実行することを示している。
【０１９０】
エントリに格納されたプログラム識別子は、付加情報の識別子と共に、分類器５により、汎用プロトコル処理部２Ｘに通知される。分類器５は、ディスクリプタやパケットの空き領域を利用して、プログラム識別子を通知することができる。プログラム識別子の通知方法は、付加情報の識別子の通知方法と同様であってもよいし、異なってもよい。
【０１９１】
本実施形態において、プログラム識別子は、プロセッサ１が実行するパケット処理に対応付けてＲＡＭ３に格納されているのが好ましい。具体的には、プロセッサ１が実行するパケット処理を特定する識別子と、対応するプログラム識別子と、を含むエントリが、ＲＡＭ３に格納されているのが好ましい。これにより、プロセッサ１は、汎用プロトコル処理部２Ｘが実行可能なプロトコル処理を実行した場合、そのプロトコル処理に対応するプログラム識別子を取得し、ＬＵＴのエントリにプログラム識別子を追加することができる。
【０１９２】
ここで、本実施形態に係る通信装置のパケット受信時の動作について説明する。本実施形態におけるパケット受信時の動作は、第２実施形態とほぼ同様である。ただし、汎用プロトコル処理部２Ｘが実行するプロトコル処理を変更する場合の動作が、第２実施形態とは異なる。
【０１９３】
これは、汎用プロトコル処理部２Ｘのプロトコル処理が変更される場合、汎用プロトコル処理部２Ｘは、新しくプログラムをロードしたり、実行回路を書き換えたりする必要があり、処理にオーバヘッドが生じるためである。このオーバヘッドは、処理効率の低下や、汎用プロトコル処理部２Ｘによるプロトコル処理の遅延の原因となる。
【０１９４】
そこで、本実施形態では、通信装置は、汎用プロトコル処理部２Ｘが実行するプロトコル処理を変更する際の遅延を抑制するように動作する。具体的には、以下のような動作が考えられる。
【０１９５】
ここで、汎用プロトコル処理部２Ｘが現在実行しているプロトコル処理をプロトコル処理Ａ、汎用プロトコル処理部２Ｘが実行可能な他のプロトコル処理をプロトコル処理Ｂとする。通信装置が、対応するエントリのないパケットを受信した場合、このパケットは、分類器５によりプロセッサ１に通知され、プロセッサ１により処理される。プロセッサ１は、パケットに対してプロトコル処理Ｂを実行した場合、プロトコル処理Ｂに対応するプログラム識別子を汎用プロトコル処理部２Ｘに通知する。そして、プログラム識別子を通知された汎用プロトコル処理部２Ｘは、プロトコル処理Ｂを実行する準備をする。すなわち、汎用プロトコル処理部２Ｘは、通知されたプログラム識別子に応じたプログラムのロードや、実行回路の書き換えを行う。なお、汎用風呂とこる処理部２Ｘへのプログラム識別子の通知は、分類器５が行なってもよい。
【０１９６】
分類器５は、汎用プロトコル処理部２Ｘの準備が終了するまで、上記のパケットと同じ分類情報のパケットを、プロセッサ１により処理させる。準備の終了は、汎用プロトコル処理部２Ｘから分類器５に通知されてもよい。また、準備が終了するまでの時間が予め設定され、ＬＵＴＲＡＭ６やＲＡＭ３に格納されていてもよい。
【０１９７】
分類器５は、汎用プロトコル処理部２Ｘの準備が終了した後、上記のパケットと同じ分類情報のパケットを、汎用プロトコル処理部２Ｘに通知する。そして、汎用プロトコル処理部２Ｘは、通知されたパケットに対してプロトコル処理Ｂを実行する。
【０１９８】
このような動作により、パケットの処理の待ち時間が生じなくなるため、汎用プロトコル処理部２Ｘが実行するプロトコル処理を変更する際の遅延を抑制することができる。
【０１９９】
なお、以上の説明では、プロトコル処理Ｂを実行されるパケットを１つ受信した時点で、汎用プロトコル処理部２Ｘは、プロトコル処理Ｂを実行するための準備を開始しているが、準備を開始するタイミングはこれに限られない。例えば、汎用プロトコル処理部２Ｘは、プロトコル処理Ｂを実行されるパケットを、通信装置が連続して所定回数受信したタイミングで準備を開始してもよい。これにより、汎用プロトコル処理部２Ｘが実行するプロトコル処理を変更する回数を減らし、プロトコル処理の変更に起因する遅延を抑制することができる。
【０２００】
以上説明した通り、本実施形態に係る通信装置によれば、分類器５は、汎用の汎用プロトコル処理部２Ｘに、汎用プロトコル処理部２Ｘが実行するプロトコル処理に応じた付加情報を通知することができる。したがって、通信装置が汎用の汎用プロトコル処理部２Ｘを備える場合であっても、第１実施形態と同様に、処理のオーバヘッドを削減し、プロトコル処理部２によるプロトコル処理に要する時間を短縮できる。
【０２０１】
なお、本発明は上記各実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記各実施形態に開示されている複数の構成要素を適宜組み合わせることによって種々の発明を形成できる。また例えば、各実施形態に示される全構成要素からいくつかの構成要素を削除した構成も考えられる。さらに、異なる実施形態に記載した構成要素を適宜組み合わせてもよい。
【符号の説明】
【０２０２】
１：プロセッサ、２：プロトコル処理部、３：ＲＡＭ、４：通信Ｉ／Ｆ、５：分類器、６：ＬＵＴＲＡＭ、７：記憶部
【図１】
2017059897.tif 000003
【図２】
2017059897.tif 000004
【図３】
2017059897.tif 000005
【図４】
2017059897.tif 000006
【図５】
2017059897.tif 000007
【図６】
2017059897.tif 000008
【図７】
2017059897.tif 000009
【図８】
2017059897.tif 000010
【図９】
2017059897.tif 000011
【図１０】
2017059897.tif 000012
【図１１】
2017059897.tif 000013
【図１２】
2017059897.tif 000014
【図１３】
2017059897.tif 000015
【図１４】
2017059897.tif 000016
【図１５】
2017059897.tif 000017
【図１６】
2017059897.tif 000018
【図１７】
2017059897.tif 000019
【図１８】
2017059897.tif 000020
【図１９】
2017059897.tif 000021
【図２０】
2017059897.tif 000022