JP4986265B2 - 通信装置、その動作方法、及び動作プログラム - Google Patents

Description

本発明は、パケットの中継およびプロトコルの終端を行う通信装置、その動作方法、及び動作プログラムに関し、とくにパケット等の処理を行うソフトウェアがコンポーネント化された通信装置及びその通信ソフトウェア構成方法に関する。

従来、この種の通信装置で用いる通信ソフトウェアは、ひとかたまりのものとして実装され、それらの一部を取り外して他の実装と入れ替えたり、あるいは該ソフトウェアの詳細な構成を意識せずに通信の追加機能を提供するソフトウェアを実装したりすることは想定されていなかった。

しかし、近年では通信機能が多様化して通信ソフトウェアの複雑さが増しており、さらに通信ソフトウェア開発が短期間化しており、機能毎にコンポーネントを個別に開発して組み合わせる構成が必要とされてきている。

たとえば、非特許文献１に示す"STREAMS"では、データの送受信処理を複数の層に分けて定義し、各層の処理をモジュールとして個別に実装できるよう、層間のインタフェースを定義する構成を採用している。さらに各層の連結順序は、固定ではなく、アプリケーションが自由に連結して使うことができるようになっている。

これを利用すれば、複雑なプロトコル処理をモジュールに分割して実装して、各モジュールの複雑さを低減したり、また、特定のモジュールだけを入れ替えたりすることにより、システム全体を変更しなくても機能の拡張や更新が可能になる。

また、非特許文献２に示す"click modular router"では、より細粒度でモジュールを記述し、それを組み合わせられるようになっている。

同文献によれば、通信ソフトウェアのコンポーネントをオブジェクト指向言語により記述できるようにし、インタフェースを基底クラスにて宣言することでコンポーネントの構成を規定し、それを拡張することでコンポーネントが実装できるようになっている。また、コンポーネントの接続を記述してノードを表現する言語が定義されており、コンポーネントを接続して容易にノードを構成できるようになっている。
ユーレッシュ・ヴァハリ（Uresh Vahalia）著、徳田英幸、外３名訳、「最前線ＵＮＩＸ（登録商標）のカーネル」、第１７章 ＳＴＲＥＡＭＳ、株式会社ピアソン・エデュケーション、２０００年５月、ｐ．６４３-６９０ Robert Morris、外３名、"The Click Modular Router", In Proceedings of the 17th ACM Symposium on Operating Systems Principles(SOSP '99), （米）, December 1999, p.217-231

従来の方式では、プロトコル処理を行う各モジュールの連結順をあらかじめ設定などにより与えておく必要があるため、複雑で動的に構成が変わる可能性のあるモジュール群の管理に手間がかかる。たとえば、あるプロトコルのモジュールが不具合の修正や機能追加などにより更新された場合、古いモジュールを切り離して新しいモジュールを繋ぎ直す処理を行う必要がある。

上記のシステムでは、次のような制約がある。
（１）アプリケーションや設定プログラムが繋ぎ変え処理を明示的に行う必要がある。
（２）繋ぎ変えをしている間はパケット処理を停止しなければならない。

本発明の目的は、プロトコル処理を行う各モジュールの処理順をあらかじめ設定により与えなくとも、処理対象のパケット等に応じて必要なモジュールを自動的に連結して、パケットを処理できるような通信装置を提供することにある。

上記目的を達成するため、本発明に係る通信装置は、プロトコル処理を行う複数のモジュールの集合により構成されるネットワークプロトコルソフトウェアをコンピュータに実行させる通信装置であって、プロトコルを実装する各モジュール毎に所定のメタ情報を保持するメタ情報保持手段と、前記メタ情報および処理対象パケットから前記各モジュールの連結順を計算する計算手段とを有することを特徴とする。

前記メタ情報は、前記各モジュール毎に前記処理対象パケットのパケット処理の該非を判定する規則と、前記パケット処理の該非判定に必要とする該非判定済のモジュール情報と、前記処理対象パケットに付加して他のモジュールの該非判定に供するための情報とを有し、前記計算手段は、前記処理対象パケットに対して前記規則に従い前記各モジュールが処理可能かどうかの該非判定を行い、可能と判定された場合、前記他のモジュールの該非判定に供するための情報を前記処理対象パケットへ付加し、前記パケット処理の該非判定に必要とする該非判定済のモジュール情報と、パケットのデータ及び前記処理対象パケットに付加される他のモジュールの該非判定に供するための情報を用いて、前記処理対象パケットの全部分につき前記該非判定の結果処理可能となった前記各モジュールの連結順を出力してもよい。

また本発明に係る通信装置は、プロトコル処理を行う複数のモジュールの集合により構成される通信装置であって、前記複数のモジュール毎に所定のメタ情報を個別に保持する手段と、処理対象のパケットと、前記複数のモジュールに個別に保持された前記メタ情報とに基づいて、前記複数のモジュール間でのパケット処理順を決定する処理順決定手段と、決定された前記パケット処理順の情報を前記パケットに添付する添付手段と、前記パケットに添付した前記パケット処理順の情報に基づいて、前記モジュールが前記パケットの伝播先を決定する手段とを備えることを特徴とする。

本発明において、前記パケットと、前記複数のモジュールに個別に保持されたメタ情報とに基づいて、前記複数のモジュール毎に前記パケットの少なくともヘッダの情報を処理可能なモジュールかどうかの該非判定を行う手段を有し、前記処理順決定手段は、前記該非判定の結果、前記複数のモジュールのうち前記パケットの少なくともヘッダの情報を処理可能なモジュールを特定し、特定されたモジュールの識別情報を順番に連結して前記複数のモジュール間でのパケット処理順として決定し、前記添付手段は、前記複数のモジュール間でのパケット処理順として決定された情報を前記パケットに添付し、前記パケットに添付された情報の順番に従い前記パケットが前記複数のモジュールのうち該当するモジュールへ受け渡され、当該モジュールの前記伝播先を決定する手段が前記パケットの伝播先を決定してもよい。

本発明において、前記複数のモジュールを介して通信を行うアプリケーションソフトウェアと、前記複数のモジュールと前記アプリケーションソフトウェアとの間に接続される送信アプリケーションプログラムインタフェース（ＡＰＩ）および受信アプリケーションプログラムインタフェース（ＡＰＩ）と、前記送信ＡＰＩから前記複数のモジュール間でのパケット処理順を決定する手段を呼び出す手段とをさらに備えてもよい。

本発明において、前記複数のモジュールを格納するモジュールリポジトリとの間で通信を行う手段と、前記複数のモジュールのメタ情報のみを当該複数のモジュールと分離して保持する手段と、前記メタ情報により前記複数のモジュールのうち所定のモジュールがパケット処理に必要と判断したときは、該当モジュールを前記モジュールリポジトリより取得する手段と、前記複数のモジュールのうち不要となったモジュールを前記通信装置上から削除する手段とをさらに備えてもよい。

本発明において、前記複数のモジュール間でのパケット処理順の情報をキャッシュへ格納して保持する手段と、前記キャッシュの情報を検索して前記複数のモジュール間でのパケット処理順を決定する手段とをさらに備えてもよい。

本発明において、前記モジュールリポジトリに格納された前記モジュールが更新された場合、当該モジュールの更新を検知する手段と、前記モジュールの更新時に更新後のモジュールを取得し、新規のセッションについては更新後のモジュールを適用し、更新前のモジュールが処理している既存セッションについては更新前のモジュールを適用する手段とをさらに備えてもよい。

本発明に係る通信装置の動作方法は、プロトコル処理を行う複数のモジュールの集合により構成されるネットワークプロトコルソフトウェアをコンピュータに実行させる通信装置の動作方法であって、前記複数のモジュール毎に所定のメタ情報を個別に保持するステップと、処理対象のパケットと、前記複数のモジュールに個別に保持された前記メタ情報とに基づいて、前記複数のモジュール間でのパケット処理順を決定するステップと、決定された前記パケット処理順の情報を前記パケットに添付するステップと、前記パケットに添付した前記パケット処理順の情報に基づいて、前記モジュールが前記パケットの伝播先を決定するステップとを有することを特徴とする。

本発明に係る通信装置の動作プログラムは、プロトコル処理を行う複数のモジュールの集合により構成されるネットワークプロトコルソフトウェアをコンピュータに実行させる通信装置の動作プログラムであって、コンピュータに、前記複数のモジュール毎に所定のメタ情報を個別に保持するステップと、処理対象のパケットと、前記複数のモジュールに個別に保持された前記メタ情報とに基づいて、前記複数のモジュール間でのパケット処理順を決定するステップと、決定された前記パケット処理順の情報を前記パケットに添付するステップと、前記パケットに添付した前記パケット処理順の情報に基づいて、前記モジュールが前記パケットの伝播先を決定するステップとを実行させることを特徴とする。

本発明によれば、プロトコル処理を行う各モジュールの処理順をあらかじめ設定により与えなくとも、処理対象のパケット等に応じて必要なモジュールを自動的に連結して、パケットを処理できるような通信装置を提供することができる。

本発明の第１の実施例に係る通信装置の全体構成を示すブロック図である。 第１の実施例において、Ｅｔｈｅｒｎｅｔ受信処理モジュールのメタ情報の記述（定義）例を説明する図である。 第１の実施例において、ＩＰｖ４パケット受信処理モジュールのメタ情報の記述（定義）例を説明する図である。 第１の実施例において、ＵＤＰデータグラム受信処理モジュールのメタ情報の記述（定義）例を説明する図である。 図２〜図４に示すプロトコルモジュールのメタ情報を用いて伝搬経路計算を行う場合のサンプルパケットを含むＥｔｈｅｒｎｅｔフレームを説明する図である。 図５に示すＥｔｈｅｒｎｅｔフレームをプロトコルヘッダとペイロードに分解したものを説明する図である。 図２〜図４に示すプロトコルモジュールのメタ情報を用いて伝搬経路計算を行う場合のパケット受信部により受信データに添付されるメタデータを説明する図である。 図２に示すＥｔｈｅｒｎｅｔフレーム受信処理モジュールのメタ情報を用いて受信データに添付されるメタ情報を説明する図である。 図３に示すＩＰパケット受信処理モジュールのメタ情報を用いて受信データに添付されるメタ情報を説明する図である。 図４に示すＵＤＰデータグラム受信処理モジュールのメタ情報を用いて受信データに添付されるメタ情報を説明する図である。 図２〜図４に示すプロトコルモジュールのメタ情報を用いて伝搬経路計算を行った結果得られるモジュール連結順を説明する図である。 第１の実施例において、ＩＰｖ４パケット受信処理モジュールによるプロトコル処理を行う場合のモジュールに受け渡される受信データを説明する図である。 本発明の第２の実施例に係る通信装置の全体構成を示すブロック図である。 第２の実施例において、通信装置によるＵＤＰ送信処理を行う場合のアプリケーションにより用意されるデータを説明する図である。 第２の実施例において、通信装置によるＵＤＰ送信処理を行う場合の送信コンテキストを説明する図である。 第２の実施例において、通信装置によるＵＤＰ送信処理で送信データに付加されるメタデータを説明する図である。 本発明の第３の実施例に係る通信装置の全体構成を示すブロック図である。 本発明の第４の実施例に係る通信装置の全体構成を示すブロック図である。

符号の説明

１００、２００、４００ 通信装置
１１０−１…１１０−ｘ、２１０−１…２１０−ｘ、４１０−１…４１０−ｘ パケット受信部
１２０、２３０、４２０ モジュール検索情報付与部
１３０、２４０、４３０ 伝搬経路制約計算部
１４０−１〜１４０−ｎ、２５０−１…２５０−ｎ、３１０−１…３１０−ｎ、４４０−１…４１０−ｎ プロトコルモジュール
１４１、４４１ 次モジュール検索部
１４２、４４２ メタ情報保持部
１５０−１…１５０−ｙ、２２０−１…２２０−ｙ、４５０−１…４５０−ｙ パケット送信部
２６０−１…２５０−ｐ 送信ＡＰＩ
２７０−１…２７０−ｑ 受信ＡＰＩ
２７０−１…２５０−ｒ アプリケーション
３００ モジュールリポジトリ
３３０ モジュール検索部
４３１ 伝播経路高速検索部
４３２ 伝播経路キャッシュ

次に、本発明を実施するための最良の形態について図面を参照して詳細に説明する。

本実施の形態による通信装置は、プロトコルを実装する各モジュール毎に所定のメタ情報を保持するメタ情報保持手段と、該メタ情報および処理対象パケットからモジュールの連結順を計算する計算手段とを有する構成を採用している。メタ情報には、（１）各モジュールがプロトコルスタック上で提供できるサービスの種類、（２）各モジュールが処理対象パケットのパケット処理の該非を判定する規則、（３）各モジュールがパケット処理の該非判定に必要とする該非判定済のモジュール情報がそれぞれ含まれる。

このような構成を採用し、前記計算手段が処理対象パケットに対して前記（２）の規則により各モジュールが該非判定を行って、前記（１）の情報を処理対象パケットへ付加し、前記（３）の情報をパケットから取得しながら、パケットの全部分について該非判定ができるような連結順を出力する。

これによれば、モジュールの連結順をあらかじめ与えることなく、処理対象パケットに応じてモジュールを適切に連結する機構を有する通信装置（パケット処理装置）を提供できる。その理由は、各モジュールが、自身の前に置かれるべきモジュールの特徴情報、自身の後に続くべきモジュールに与えるべき特徴情報、自身が処理できるパケットの特徴情報を保持しているため、これらがすべて満たされるモジュールの連結順を入力パケットから決定できるためである。

本実施の形態では、上記の構成に加えて、さらに、モジュール構成を採用しないソフトウェアも、同装置の一部として利用することができる。これは、プロトコルモジュールとその他のソフトウェアの間に送受信ＡＰＩ（Application Program Interface：アプリケーションプログラムインタフェース）が用意され、モジュール化されたプロトコル部分の構成が他のソフトウェアに対して隠蔽されているためである。

本実施の形態では、上記の構成に加えて、さらに、モジュールを自動的に装置に追加・削除することで自動的に資源を有効に利用し、機能更新・追加を行う通信装置（処理装置）を提供できる。これは、下記の特徴により、資源が無駄に消費されないためである。

（１）到着したパケットの処理に必要なモジュールをネットワーク経由で取得できる。

（２）不要になったモジュールを装置から削除することにより、パケットの到着に応じて必要なモジュールを常に保持できる。

（３）パケットの処理に必要ないモジュールを削除できる。

本実施の形態では、上記の構成に加えて、さらに、プロトコル処理を高速に行える通信装置を提供できる。これは、あるフローに属するなどの決まったパターンに従う一連のパケットに対して、その最初のパケットのモジュール処理順をキャッシュに保持しておき、後続のパケットの処理順をそのキャッシュから検索して決定するため、高速に処理内容を決定できるためである。

本実施の形態では、上記の構成に加えて、さらに、無停止かつ無設定でモジュールを更新する通信装置を提供できる。これは、第３及び第４の通信装置の機能を使って、機能が更新されたモジュールを自動的に取得し、さらに、機能が更新される前に開設されたフローのパケットは更新前のモジュールが処理するようにキャッシュにモジュール処理順を保持し、機能が更新された後に開設されたフローのパケットは、更新後のモジュールが処理するように、同様にキャッシュにモジュール処理順を保持することにより、いずれのフローについても、処理を中断させることなく、パケット処理を新しいモジュールが行うように切り替えることができるためである。

以下、図面を参照して、本発明の種々の実施例について説明する。

図１は、本発明の第１の実施例の構成を示すブロック図である。

図１を参照すると、本実施例による通信装置１００は、機能上、ひとつ以上のパケット受信部１１０−１…１１０−ｘと、モジュール検索情報付与部１２０と、伝搬経路制約計算部１３０と、ひとつ以上のプロトコルモジュール（以下、モジュールと略称する）１４０−１…１４０−ｎと、ひとつ以上のパケット送信部１５０−１…１５０−ｙとからなる。

パケット受信部１１０−１…１１０−ｘは、モジュール検索情報付与部１２０に接続されている。モジュール検索情報付与部１２０は、伝搬経路制約計算部１３０と、モジュール１４０−１…１４０−ｎにそれぞれ接続されている。伝搬経路制約計算部１３０は、この他にモジュール１４０−１…１４０−ｘに接続されている。モジュール１４０−１…１４０−ｎは、この他にパケット送信部１５０−１…１５０−ｘに接続されている。

パケット受信部１１０−１…１１０−ｘは、装置１００外部と本実施例の構成により実現する通信ソフトウェアのインタフェースとして、受信パケットのデータ（以下「受信データ」と記す）をモジュール検索情報付与部１２０へ渡す機能を持つ。

パケット送信部１５０−１…１５０−ｙは、装置１００外部と本実施例の構成により実現する通信ソフトウェアのインタフェースとして、モジュール１４０−１…１４０−ｎが他の装置宛に作成した送信データ（以降「送信パケット」と記す）を装置１００外へ送出する機能を持つ。

モジュール１４０−１…１４０−ｎは、通信プロトコルのひとつを実装するソフトウェアコンポーネントであって、受信したデータの処理や他の通信装置へ送信する送信データの作成などを行う。なお、通信プロトコルは、例えばコンピュータの持つべき通信機能を階層構造に分割したＯＳＩ（Open Systems Interconnection）参照モデルに基づく全７層（下位レイヤから上位レイヤへ、物理層、データリンク層、ネットワーク層、トランスポート層、セッション層、プレゼンテーション層、アプリケーション層から成る）にそれぞれ対応する処理モジュールから構成される。或は、ＯＳＩ参照モデルをベースに構築されたＴＣＰ／ＩＰ（Internet Protocol/Transmission Control Protocol）プロトコル群に基づく全４層（下位レイヤから上位レイヤへ、ネットワークインタフェース層、インターネット層、トランスポート層、アプリケーション層から成る）にそれぞれ対応する処理モジュールから構成される。このうち、物理層及びデータリンク層（ネットワークインタフェース層）の処理モジュールとして、Ｅｔｈｅｒｎｅｔ（登録商標）等が、ネットワーク層（インターネット層）の処理モジュールとして、ＩＰ（Internet Protocol）等が、トランスポート層の処理モジュールとして、ＵＤＰ（User Datagram Protocol）やＴＣＰ（Transmission Control Protocol）等がそれぞれ含まれる。本実施例のモジュール１４０−１…１４０−ｎは、これらの通信プロトコルを成すＥｔｈｅｒｎｅｔ、ＩＰ、ＵＤＰ等の処理モジュールとして実装されている。

モジュール検索情報付与部１２０は、受信データに対して所定の手順により受信データの処理に必要なモジュールを検索するための情報（モジュール検索情報）を付与する。

伝搬経路制約計算部１３０は、受信データと各モジュール１４０−１…１４０−ｎのメタ情報（後述参照）より、受信データの処理に必要なモジュール１４０−１…１４０−ｎおよびその処理順を決定する。

モジュール１４０−１…１４０−ｎは、機能上、プロトコル処理部（非図示）と、次モジュール検索部１４１と、メタ情報保持部１４２とを有している。

プロトコル処理部では、モジュール検索情報付与部１２０または他のモジュール１４０−１…１４０−ｎから受け渡された受信データを該当モジュール１４０−１…１４０−ｎが実装するプロトコルにしたがって処理する。

次モジュール検索部１４１は、受信データに添付されたモジュール検索情報に基づき、次に処理すべきモジュール１４０−１…１４０−ｎを決定し、該モジュール１４０−１…１４０−ｎが処理したデータをそのモジュール１４０−１…１４０−ｎへ引き渡す機能を持つ。

メタ情報保持部１４２は、モジュール１４０−１…１４０−ｎのメタ情報を保持するもので、そのメタ情報として、モジュール１４０−１…１４０−ｎが処理できる受信データの種類、モジュール１４０−１…１４０−ｎの処理に必要な前提条件、モジュール１４０−１…１４０−ｎの処理により受信データになされる変更などのモジュール１４０−１…１４０−ｎの特徴情報が付与されている。

メタ情報保持部１４２に保持されるメタ情報には、たとえば次のようなものが含まれる。

（１）このメタ情報には、モジュール１４０−１…１４０−ｎが受信データを処理すべきかどうかを判断するための条件（処理対象判定条件）が含まれる。たとえば、ＩＰｖ４受信処理の場合には、先頭４ビットが0010であるかどうか、下位レイヤごとに該当レイヤの上位層がＩＰであるかどうか、下位レイヤがＥｔｈｅｒｎｅｔの場合にはプロトコル番号が0x0800であるかどうか、上位レイヤがＩＰ−ｉｎ−ＩＰの場合にはプロトコル番号が４であるかどうか、ＩＰヘッダチェックサムが正しい値であるかどうかの各判定条件が含まれる。

（２）このメタ情報には、受信データに添付されたモジュール１４０−１…１４０−ｎの処理に必要なメタ情報が含まれる。たとえば、ＩＰｖ４受信処理の場合には、下位レイヤのヘッダの位置を示すオフセット情報が含まれる。

（３）このメタ情報には、モジュール１４０−１…１４０−ｎが受信データを処理する場合に、処理後に受信データに添付されるであろうメタ情報が含まれる。たとえば、ＩＰｖ４受信処理の場合には、次レイヤのプロトコル番号の情報と、ＩＰヘッダ長が含まれる。

（４）このメタ情報には、該当モジュール１４０−１…１４０−ｎの識別に有用なメタ情報が含まれる。たとえば、モジュール１４０−１…１４０−ｎの作成日時や作成者等、モジュール１４０−１…１４０−ｎの配布元のＵＲＬ（Uniform Resource Locator）等が含まれる。

図２〜図４に、モジュール１４０−１…１４０−ｎの例として、Ｅｔｈｅｒｎｅｔフレーム受信処理モジュール、ＩＰｖ４パケット受信処理モジュール、ＵＤＰデータグラム受信処理モジュールを対象とし、それぞれのモジュール１４０−１…１４０−ｎのメタ情報をコンピュータで処理できるように定義するための完全な記述例を示す。ここで、メタ情報の表現や項目は、本例に制約されるものではない。

図２〜図４を参照すると、メタ情報は、モジュール１４０−１…１４０−ｎごとにタグで記述される要素の入れ子構造にて表現される。すなわち、図２〜図４の例では、各モジュール１４０−１…１４０−ｎのメタ情報は、＜メタデータ＞タグで示される要素からなり、そのなかに＜必要情報＞、＜処理対象判定＞、および＜添付情報＞タグで示される要素が含まれる。これらは、各々上述したメタ情報の含有項目に該当する。

まず、図２に示すＥｔｈｅｒｎｅｔフレーム受信処理モジュールのメタ情報について説明する。

図２の例では、＜メタデータ＞タグで示される要素は、Ｅｔｈｅｒｎｅｔ受信処理モジュール（モジュール名＝"Ethernet受信"）のバージョン１（バージョン＝"１"）のメタ情報であることを示している。このうち、＜必要情報＞タグ内に含まれる文字列"オフセット"は、Ｅｔｈｅｒｎｅｔ受信処理モジュールが受信データを処理するには、該当受信データに"オフセット"で示されるメタ情報が添付されている必要があることを示している。

また、＜処理対象判定＞タグ内に含まれる要素のうち、＜and＞および＜or＞タグは、条件の論理積および論理和をそれぞれ取るための記述である。図２の例では、＜and＞タグ内に＜or＞タグと、＜添付情報＞タグとが含まれ、それぞれのタグ内に条件が記述されている。すなわち、＜or＞タグ内には、＜byte-data＞タグ内に示される受信データの処理オフセット位置から６バイト目（オフセット＝"６"）からの６バイト（長さ＝"６"）の値が0x00004cd738a3と一致するかどうかという条件と、＜bit-data＞タグ内に示される受信データの処理オフセット位置から４８ビット目（オフセット＝"４８"）が１であるかどうかという条件とのＯＲ条件が記述されている。また、＜添付情報＞タグ内には、ペイロード情報で示されるメタ情報が受信データに添付されており（key＝"ペイロード情報"）、かつ、そのメタ情報の値が＜プロトコル＞タグ内に含まれる文字列"Ethernet"であるかどうかという条件である。従って、図２の例では、＜or＞タグ内の＜byte-data＞および＜bit-data＞タグにそれぞれ記述されている条件のＯＲ条件（第１の条件）と、＜添付情報＞タグ内に記述されている条件（第２の条件）とのＡＮＤ条件、すなわち第１の条件と第２の条件の両方を満たすかどうかが、処理対象判定条件であることを示している。

さらに、＜添付情報＞タグ内に含まれる要素のうち、＜プロトコルヘッダ オフセット＝"０" 長さ＝"１４"／＞は、"プロトコルヘッダ"で示されるメタ情報として、処理対象データの先頭から１４バイト分の受信データを添付することを示している。

また、＜オフセット 演算＝"加算"＞１４＜／オフセット＞は、受信データに添付された"オフセット"で示されるメタ情報の数値に、整数値１４を加算することを示している。

また、＜ペイロード情報＞タグ内に含まれる要素は、"ペイロード情報"で示されるメタ情報として、＜プロトコル＞タグで示される要素を添付することを示している。すなわち、その内容は、＜switch＞タグ内で設定条件に応じて"プロトコル"を選択可能に記述されている。図２の例では、＜byte-data オフセット＝"１２" 長さ＝"２"／＞は、処理対象データの先頭から１２バイト目からの２バイトの値を意味し、その値が、0x0800であれば（case value="0x0800"）、ＩＰとし、0x0806であれば（case value="0x0806"）、ＡＲＰ（Address Resolution Protocol）とする、ということを示している。

次に、図３に示すＩＰｖ４パケット受信処理モジュールのメタ情報について説明する。

図３の例では、＜メタデータ＞タグで示される要素は、ＩＰｖ４受信処理モジュール（モジュール名＝"IPv4受信"）のバージョン１（バージョン＝"１"）のメタ情報であることを示している。このうち、＜必要情報＞タグ内に含まれる文字列"オフセット"および"ペイロード情報"は、ＩＰｖ４受信処理モジュールが受信データを処理するには、該当受信データに"オフセット"および"ペイロード情報"で示されるメタ情報が添付されている必要があることを示している。

また、＜処理対象判定＞タグ内に含まれる要素のうち、＜and＞タグは、条件の論理積を取るための記述である。図３の例では、＜and＞タグ内に＜bit-data＞と、＜添付情報＞タグとが含まれ、それぞれのタグ内に条件が記述されている。すなわち、＜bit-data＞タグ内には、受信データの処理オフセット位置から０ビット目（オフセット＝"０"）からの４ビット（長さ＝"４"）の値が0010と一致するかどうかという条件が記述されている。また、＜添付情報＞タグ内には、ペイロード情報で示されるメタ情報が受信データに添付されており（key＝"ペイロード情報"）、かつ、そのメタ情報の値が＜プロトコル＞タグ内に含まれる文字列"IP"であるかどうかという条件である。従って、図３の例では、＜bit-data＞タグにそれぞれ記述されている条件（第１の条件）と、＜添付情報＞タグ内に記述されている条件（第２の条件）とのＡＮＤ条件、すなわち第１の条件と第２の条件の両方を満たすかどうかが、処理対象判定条件であることを示している。

さらに、＜添付情報＞タグ内に含まれる要素のうち、＜プロトコルヘッダ オフセット＝"０" 長さ＝"２０"／＞は、"プロトコルヘッダ"で示されるメタ情報として、処理対象データの先頭から２０バイト分の受信データを添付することを示している。

また、＜オフセット 演算＝"加算"＞＜bit-data オフセット＝"４" 長さ＝"４" シフト＝"４"／＞＜／オフセット＞は、受信データに添付された"オフセット"で示されるメタ情報の数値に、受信データの処理オフセット位置から４ビット目からの４ビットの値を加算することを示している。

また、＜ペイロード情報＞タグ内に含まれる要素は、"ペイロード情報"で示されるメタ情報として、＜プロトコル＞タグで示される要素を添付することを示している。すなわち、その内容は、＜switch＞タグ内で設定条件に応じて"プロトコル"を選択可能に記述されている。図３の例では、＜byte-data オフセット＝"９" 長さ＝"１"／＞は、処理対象データの先頭から９バイト目からの１バイトの値を意味し、その値が、0x01であれば（case value="0x01"）、ＩＣＭＰ（Internet Control Message Protocol）とし、0x04であれば（case value="0x04"）、ＩＰ−ｉｎ−ＩＰとし、0x06であれば（case value="0x06"）、ＴＣＰとし、0x11であれば（case value="0x11"）、ＵＤＰとし、0x46であれば（case value="0x46"）、ＩＰｖ６−ｏｖｅｒ−ＩＰとするということを示している。

次に、図４に示すＵＤＰデータグラム受信処理モジュールのメタ情報について説明する。

図４の例では、＜メタデータ＞タグで示される要素は、ＵＤＰ受信処理モジュール（モジュール名＝"UDP受信"）のバージョン１（バージョン＝"１"）のメタ情報であることを示している。このうち、＜必要情報＞タグ内に含まれる文字列"オフセット"および"ペイロード情報"は、Ｅｔｈｅｒｎｅｔ受信処理モジュールが受信データを処理するには、該当受信データに"オフセット"および"ペイロード情報"で示されるメタ情報が添付されている必要があることを示している。

また、＜処理対象判定＞タグ内には、＜添付情報＞タグが含まれ、そのタグ内に条件が記述されている。すなわち、＜添付情報＞タグ内には、ペイロード情報で示されるメタ情報が受信データに添付されており（key＝"ペイロード情報"）、かつ、そのメタ情報の値が＜プロトコル＞タグ内に含まれる文字列"UDP"であるかどうかという処理対象判定条件が記述されている。

さらに、＜添付情報＞タグ内に含まれる要素のうち、＜プロトコルヘッダ オフセット＝"０" 長さ＝"８"／＞は、"プロトコルヘッダ"で示されるメタ情報として、処理対象データの先頭から８バイト分の受信データを添付することを示している。

また、＜オフセット演算＝"加算"＞８＜／オフセット＞は、受信データに添付された"オフセット"で示されるメタ情報の数値に、整数値８を加算することを示している。

また、＜ペイロード情報＞タグ内に含まれる要素は、"ペイロード情報"で示されるメタ情報として、＜始端点＞、＜終端点＞、＜長さ＞タグで示される要素を添付することを示している。すなわち、＜始端点＞タグで示される要素は、処理対象データの先頭（オフセット＝"０"）から２バイト（長さ＝"２"）分の受信データである。また、＜終端点＞タグで示される要素は、処理対象データの先頭（オフセット＝"０"）から２バイト（長さ＝"２"）分の受信データである。さらに、＜長さ＞タグで示される要素は、処理対象データの４バイト目（オフセット＝"０"）から２バイト（長さ＝"２"）分の受信データである。

上記のメタデータで示されるモジュールが受信データの処理対象として判定された場合、上記の添付情報が、受信データに対して付加あるいは更新される。

これらメタ情報は、完全にモジュール１４０−１…１４０−ｎの連結順を決定できるだけの詳細なものである必要はない。メタ情報からモジュール１４０−１…１４０−ｎの処理順が決定できないときは、実際に受信データがモジュール１４０−１…１４０−ｎのプロトコル処理部にて処理された結果、次のモジュール１４０−１…１４０−ｎが決定される。

また、これらのメタ情報は、処理判定に必要なオフセット値やヘッダ内の特定フィールドの値などを直接記述しているが、実用的なシステムにする上では、プロトコルの仕様書などで定義されるヘッダフィールドの名前などを、メタ情報定義に利用できるよう、糖衣構文を定めても良い。

たとえば、上記の例で言えば、Ｅｔｈｅｒｎｅｔフレーム受信処理モジュールのメタ情報の処理対象判定条件内に記載された、＜byte-data オフセット＝"６" 長さ＝"６"＞0x00004cd738a3＜/byte-data＞という記述を、＜EtherDest＞0x00004cd738a3＜/EtherDest＞等と書けるようにしてもよい。

次に、本実施例の全体動作について詳細に説明する。

まず、パケットが本通信装置１００のいずれかのパケット受信部１１０−１…１１０−ｘにより受信されると、パケット受信部１１０−１…１１０−ｘは、到達したパケットに、該当パケット受信部１１０−１…１１０−ｘの識別子と、該当パケット受信部１１０−１…１１０−ｘに接続する伝送デバイスを区別するための情報をメタ情報として添付する。該パケットである受信データは、パケット受信部１１０−１…１１０−ｘからモジュール検索情報付与部１２０へ受け渡される。

次いで、モジュール検索情報付与部１２０では、受け渡された受信データをさらに伝搬経路制約計算部１３０へ受け渡す。

次いで、伝搬経路制約計算部１３０では、パケットを適切に処理できるようにモジュール１４０−１…１４０−ｎが順に並ぶよう、受け渡された受信データと、メタ情報保持部１４２に保持されている各モジュール１４０−１…１４０−ｎのメタ情報とに基づいて、後述の手順により計算を行う。

すなわち、伝搬経路制約計算部１３０は、受信データと、受信データにパケット受信部１１０−１…１１０−ｘが添付したメタ情報を、各モジュールのメタ情報の条件に順に適用し、適合するモジュール１４０−１…１４０−ｎを順に拾い出す処理を行う。

各モジュール１４０−１…１４０−ｎのメタ情報に含まれる処理対象判定条件には、他のモジュール１４０−１…１４０−ｎが受信データに添付する情報の有無を含めることができる。このため、モジュール１４０−１…１４０−ｎ間に依存関係を持たせることができる。このモジュール１４０−１…１４０−ｎ間の依存関係は、受信データの内容などにより該データへ添付するメタ情報を変えることで動的に変更できる。

これにより、モジュール間に新しい機能をもったモジュールを差し挟んで処理を行わせたい場合等に、従来では、モジュール化された通信ソフトウェアであっても、モジュールの連結グラフの再構成などが必要だったが、本方式では、メタ情報を適切に記述した新しいモジュールを装置に追加するだけでよい。このため、静的に結合されたプロトコルモジュール群により構成される通信ソフトウェアよりもモジュールの入れ替えや機能の変更を容易に行える。

次に、図５〜図１１を参照して、Ｅｔｈｅｒｎｅｔ、ＩＰ、およびＵＤＰを実装した通信装置１００により上記モジュール連結順を決定する処理の具体例を説明する。

図５〜図１１の例では、パケット受信部１１０−１…１１０−ｘは、Ｅｔｈｅｒｎｅｔに接続していることを仮定している。その場合、パケット受信部１１０−１…１１０−ｘは、受信したデータがＥｔｈｅｒｎｅｔのフレームであることをあらかじめ知っているため、受信データに、図７に示すようにＥｔｈｅｒｎｅｔプロトコルのデータであることを示すペイロード情報をメタ情報として添付する。また同様に処理オフセット０も添付する。

これらの情報と、Ｅｔｈｅｒｎｅｔ受信処理モジュールのメタ情報とから、モジュール１４０−１…１４０−ｎのうちＥｔｈｅｒｎｅｔ受信処理モジュールが処理対象になることがわかる。また、他のモジュール１４０−１…１４０−ｎはいずれも処理対象にならないこともわかる。これらより、この受信データを最初に処理すべきはＥｔｈｅｒｎｅｔ受信処理モジュールである。

次いで、Ｅｔｈｅｒｎｅｔ受信処理モジュールは、受信データの添付情報を更新して、図８で示される情報を添付する。この受信データとメタデータより、同様に処理対象判定を行えば、次に処理対象になるモジュール１４０−１…１４０−ｎは、ＩＰｖ４受信処理モジュールである。

次いで、ＩＰｖ４受信処理モジュールは、受信データの添付情報を更新して、図９で示される情報を添付する。この受信データとメタデータより、同様に処理対象判定を行えば、次に処理対象になるモジュール１４０−１…１４０−ｎは、ＵＤＰ受信処理モジュールである。

次いで、ＵＤＰ受信処理モジュールは、受信データの添付情報を更新して、図１０で示される情報を添付する。この受信データとメタデータより、同様に処理対象判定を行えば、次に処理対象になるモジュール１４０−１…１４０−ｎがないことがわかる。

上記の手順により、伝送経路制約計算部１３０は、受け渡された受信データに対してそれを処理するモジュール１４０−１…１４０−ｎの並び順（モジュール連結順）を決定する。本例では、図１１に示すように、その並び順は、先頭のものから順に、Ｅｔｈｅｒｎｅｔ受信処理モジュール、ＩＰｖ４受信処理モジュール、ＵＤＰ受信処理モジュールとなる。この並び順をモジュール検索情報付与部１２０へ伝達する。

ここで、Ｅｔｈｅｒｎｅｔフレームを受信してからモジュール連結順を決定するまでの処理の流れについて説明する。

（１）まず、パケット受信部１１０−１…１１０−ｘは、図５に示すサンプルのパケットを含むＥｔｈｅｒｎｅｔフレームを受信する。このＥｔｈｅｒｎｅｔフレームは、図６に示すようにプロトコルヘッダとペイロードとから構成される。このＥｔｈｅｒｎｅｔフレーム受信後、パケット受信部１１０−１…１１０−ｘは、その受信データに図７に示すメタデータの要素を添付する。図７の例では、そのメタデータの要素として、"ペイロード情報"で示される"プロトコル"に記述された"Ｅｔｈｅｒｎｅｔ"が含まれる。

（２）そして、パケット受信部１１０−１…１１０−ｘは、上記メタデータの要素が添付された受信データを伝播経路制約計算部１３０に渡す。

（３）すると、伝播経路制約計算部１３０は、上記受信データおよびこれに添付された上記メタデータの要素が、各モジュール１４０−１…１４０−ｎのメタ情報保持部４４２に格納されているメタ情報の"処理対象判定条件"にマッチ（適合）するかどうかを検査し、その適合検査結果により、マッチしているモジュール１４０−１…１４０−ｎを特定する。本例では、マッチするモジュール１４０−１…１４０−ｎは、Ｅｔｈｅｒｎｅｔ受信処理モジュールのみとなる。これは、図７に示すメタデータの"ペイロード情報"内の"プロトコル"にＥｔｈｅｒｎｅｔが記述され、これとメタ情報内の"処理判定条件"とがマッチするモジュール１４０−１…１４０−ｎは、Ｅｔｈｅｒｎｅｔ受信処理モジュールしかないためである。

（４）特定されたＥｔｈｅｒｎｅｔ受信処理モジュールは、自身のメタ情報保持部４４２に格納されているメタ情報の"添付情報"（図２参照）に従い、図８に示すメタ情報の要素を受信データに添付し、その添付情報を更新する。図８の例では、メタ情報の要素として、"プロトコルヘッダ"、"オフセット"、"ペイロード情報"で示される要素が添付される。このうち、"プロトコルヘッダ"の要素は、処理対象データの先頭から１４バイト分の値（0x0003476a8b990004cd738a30800）である。また、"オフセット"の要素は、１４であり、"ペイロード情報"内の"プロトコル"の要素はＩＰである。

（５）次いで、伝播経路制約計算部１３０は、上記受信データおよびこれに添付及び更新された上記メタ情報の要素が、各モジュール１４０−１…１４０−ｎのメタ情報保持部４４２に格納されているメタ情報の"処理対象判定条件"にマッチ（適合）するかどうかを検査し、その適合検査結果により、マッチしているモジュール１４０−１…１４０−ｎを特定する。本例では、マッチするモジュールは、ＩＰ受信処理モジュールのみとなる。これは、図８に示す"ペイロード情報"内の"プロトコル"にＩＰが記述され、これとメタ情報内の"処理判定条件"とがマッチするモジュール１４０−１…１４０−ｎはＩＰしかなく、さらに受信データの先頭４ビットが0010（IPv4）であるためである。

（６）特定されたＩＰｖ４受信処理モジュールは、自身のメタ情報保持部４４２に格納されているメタ情報の"添付情報"（図３参照）に従い、図９に示すメタ情報の要素を受信データに添付する。図９の例では、メタ情報の要素として、"プロトコルヘッダ"、"オフセット"、"ペイロード情報"で示される要素が添付される。このうち、"プロトコルヘッダ"の要素は、処理対象データの先頭から２０バイト分の値（0x4500005c9f1a000040115725c0a80180c0a80181）である。また、"オフセット"の要素は、３４であり、"ペイロード情報"内の"プロトコル"の要素はＵＤＰである。

（７）次いで、伝播経路制約計算部１３０は、上記受信データおよびこれに添付及び更新された上記メタ情報の要素が、各モジュール１４０−１…１４０−ｎのメタ情報保持部４４２に格納されているメタ情報の"処理対象判定条件"にマッチ（適合）するかどうかを検査し、その適合検査結果により、マッチしているモジュール１４０−１…１４０−ｎを特定する。本例では、マッチするモジュールはＵＤＰ受信処理モジュールのみとなる。これは、図９に示す"ペイロード情報"内の"プロトコル"にＵＤＰが記述され、これとメタ情報内の"処理判定条件"とがマッチするモジュール１４０−１…１４０−ｎはＵＤＰしかないためである。

（８）次いで、特定されたＵＤＰ受信処理モジュールは、自身のメタ情報保持部４４２に格納されているメタ情報の"添付情報"（図４参照）に従い、図１０に示すメタ情報の要素を受信データに添付する。図１０の例では、メタ情報の要素として、"プロトコルヘッダ"、"オフセット"、"ペイロード情報"で示される要素が添付される。このうち、"プロトコルヘッダ"の要素は、処理対象データの先頭から８バイト分の値（0xffd83584004845af）である。また、"オフセット"の要素は、４２であり、"ペイロード情報"内の"始端点"の要素は0xffd8、"終端点"の要素は0x3584、"長さ"の要素は0x0048である。

（９）次いで、伝播経路制約計算部１３０は、上記受信データおよびこれに添付及び更新された上記メタ情報の要素が、各モジュール１４０−１…１４０−ｎのメタ情報保持部４４２に格納されているメタ情報の"処理対象判定条件"にマッチ（適合）するかどうかを判断し、その結果により、マッチしているモジュール１４０−１…１４０−ｎを特定する。本例では、これ以上マッチするモジュールはない。

（１０）上記より、伝播経路制約計算部１３０は、図１１に示すモジュール連結順を最終的に作成する。図１１の例では、モジュール連結順は、＜モジュール検索情報＞タグで記述され、その並び順が先頭のものから順に、Ｅｔｈｅｒｎｅｔ受信処理モジュール、ＩＰｖ４受信処理モジュール、ＵＤＰ受信処理モジュールとなっている。

モジュール検索情報付与部１２０では、伝達されたモジュール１４０−１…１４０−ｎの並び順であるモジュール連結順の情報を受信データにメタ情報として添付する。次に、その並び順の先頭にあるモジュール１４０−１…１４０−ｎ（本例ではＥｔｈｅｒｎｅｔ受信処理モジュールが該当する。）の情報を取出し、該当モジュール１４０−１…１４０−ｎへ受信データを受け渡す。

さらに、上記の受信データを受け取ったモジュール１４０−１…１４０−ｎは、自身のプロトコル処理部により、該受信データをそのモジュール１４０−１…１４０−ｎが実装するプロトコル処理手順にしたがって処理する。このプロトコル処理は、たとえば、プロトコルごとのノード状態の変更をはじめ、ヘッダやペイロードの書き換え、プロトコル処理に関するメタ情報のパケットへの添付などである。

たとえば、ＩＰｖ４受信処理モジュールによるプロトコル処理の場合は、次のようになる。なお、ここに記載した処理は、非特許文献（Ｇ．Ｒ．ライト、外１名著，徳田英幸、外１名訳、「詳解ＴＣＰ／ＩＰ ｖｏｌ．２ 実装」、株式会社ピアソン・エデュケーション、２００２年１２月）の第８章の記述に基づいている。

ここでは、パケット受信部１１０−１…１１０−ｘがＥｔｈｅｒｎｅｔフレームを受信し、モジュール１４０−１…１４０−ｎのうちＥｔｈｅｒｎｅｔ受信処理モジュールによる処理が正常に完了し、図１２に示す受信データがＩＰｖ４受信処理モジュールに受け渡された場合を考える。

（１）この場合には、ＩＰ受信処理モジュールは、まず、Ｅｔｈｅｒｎｅｔ受信処理モジュールから受け渡された受信データのうち添付されたメタ情報に記述されている処理オフセットからのデータを読み込む。図１２の例では、処理オフセットとして受信データの先頭から１４バイト目（図８の"オフセット"の値参照）の0x4500からのデータが読み込まれる。

（２）次いで、ＩＰ受信処理モジュールは、読み込まれた受信データの先頭４ビット（バージョン番号）が0100であること確認する。

（３）次いで、ＩＰ受信処理モジュールは、読み込まれた受信データの５−８ビット目（上記の場合0011）を４倍してヘッダ長を得て、そのヘッダ長が仕様の定める範囲に収まっており、かつ受信データの残り長より短いことを確認する。

（４）次いで、ＩＰ受信処理モジュールは、読み込まれた受信データの１０−１１バイト目に格納されたヘッダチェックサムを検査する。

（５）次いで、ＩＰ受信処理モジュールは、読み込まれた受信データの３−４バイト目に格納されているパケット全長が受信データ長以下であること確認する。

（６）次いで、ＩＰ受信処理モジュールは、ＩＰオプションがあれば処理する。

（７）次いで、ＩＰ受信処理モジュールは、インタフェースアドレスとパケットの宛先アドレスを照合する等して、このパケットを自ノードで受信できるかどうか検査する（本例では、受信できる場合が該当する。）

（８）次いで、ＩＰ受信処理モジュールは、パケットがフラグメントされていれば、リアセンブル処理を行う。

以上のようなモジュール１４０−１…１４０−ｎによるプロトコル処理が終わると、モジュール１４０−１…１４０−ｎ内の次モジュール検索部１４２は、受信データのメタ情報から該データの次処理を行うモジュール１４０−１…１４０−ｎを決定する。このときの処理手順を以下に示す。

（１）まず、次モジュール検索部１４２は、メタ情報に次処理モジュール１４０−１…１４０−ｎが記録されていれば、該モジュール１４０−１…１４０−ｎへ該パケットを受け渡す。

（２）次モジュール検索部１４２は、自身のモジュール１４０−１…１４０−ｎによるプロトコル処理により、メタ情報とは異なる次処理モジュール１４０−１…１４０−ｎが決定されたときは、そのプロトコル処理により決定される次処理モジュール１４０−１…１４０−ｎへ受け渡す。

（３）次モジュール検索部１４２は、次処理モジュール１４０−１…１４０−ｎがないときは、該パケット処理を終了して、次のパケットの処理まで待機する。

（４）次モジュール検索部１４２は、処理済データを送出する必要があれば、該データをパケット送信部１５０−１…１５０−ｙへ受け渡す。

（５）次モジュール検索部１４２は、次処理が決定できなければ、パケットを破棄し、破棄する場合にあらかじめ定められた処理を行う。

上記のモジュール１４０−１…１４０−ｎによるプロトコル処理は、受信データの処理が終わるか、いずれかのモジュール１４０−１…１４０−ｎが該データをパケット送信部１５０−１…１５０−ｙへ受け渡すまで続く。そして、処理済データがパケット送信部１５０−１…１５０−ｙに受け渡されると、該パケット送信部１５０−１…１５０−ｙは、接続されたデータリンクへ該データをパケットとして送出して処理を終える。

ここで、上記メタ情報の適合検査では、受信データの中で処理対象のモジュール１４０−１…１４０−ｎを決められない部分が発生しうる。たとえば、ＥＳＰ（Encapsulated Security Payload）（S. Kent, 外１名, "IP Encapsulating Security Payload (ESP)", RFC2406, Nov, 1998参照）を含む受信データは、ＥＳＰヘッダに後続するペイロード部分が暗号化されているため、該当暗号部分を復号しないかぎりＥＳＰの後続部分の処理内容は決められない。このような場合は、ＥＳＰ受信モジュールまでの処理順を決めておき、ＥＳＰモジュールで受信データを処理した後、復号されたペイロードに含まれるプロトコル情報より、次のモジュールを決定するようにしてもよい。

上記のような場合や、メタ情報の記述が受信データの処理順を決定できるほど十分に詳細ではない場合は、可能な範囲でモジュールの連結順を決めておく。このとき、あらかじめ決められた連結順の最後まで受信データ処理が到達したらば、実際に受信データがモジュールのプロトコル処理部にて処理された結果から、次のモジュールが決定される。

あるいは、プロトコル処理上、あらかじめ次処理モジュールが予測できるような場合には、ディフォルトの次処理モジュールの情報をモジュールのメタ情報に含めておくこともできる。この場合、次処理モジュールが受信データから決定できなければ、上記ディフォルト次処理モジュールを採用して処理を行う。もし、実際に受信データを処理して、ディフォルトモジュールとは異なるモジュールによる処理が必要になれば、後者のモジュールに優先して受信データを受け渡せば良い。

次に、本発明の第２の実施例を説明する。本実施例は、第１の実施例の構成に加え、モジュール化していないアプリケーションを含む構成を採用している。

第１の実施例の通信装置では、受信および送信データの処理に使われるすべてのソフトウェアが、本発明の方式によるモジュールとして存在していることを仮定している。この仮定を満たすには、既成の通信アプリケーションなどを本方式にあわせてモジュール構成に書き換える必要があることになる。これは、書き換え作業のコストがかかるうえ、書き換えに伴って新たな不具合が混入するリスクもあるなど、好ましくない場合もある。これを解決するには、本方式の通信ソフトウェアと本方式によらないソフトウェアとの間にインタフェースを用意して、本方式の構成を他のソフトウェアに対して隠蔽すればよい。本実施例は、その点を踏まえ構成されている。

図１３は、本実施例の構成を示すブロック図である。図１３を参照すると、本実施例による通信装置２００では、第１の実施例の構成に加えて、一つ以上の送信ＡＰＩ２６０−１…２６０−ｐおよび受信ＡＰＩ２７０−１…２７０−ｑと、一つ以上のアプリケーションソフトウェア（以下、アプリケーションと略称する）２８０−１…２８０−ｒとが追加されている。

アプリケーション２８０−１…２８０−ｒは、各々、利用する送信ＡＰＩ２６０−１…２６０−ｐおよび受信ＡＰＩ２７０−１…２７０−ｑと接続している。送信ＡＰＩ２６０−１…２６０−ｐは、モジュール検索情報付与部２３０と接続している。受信ＡＰＩ２７０−１…２７０−ｑは、各モジュール２５０−１…２５０−ｎと接続している。

アプリケーション２８０−１…２８０−ｒは、その一例として、ソケットＡＰＩを利用するような、ＨＴＴＰ（Hyper Text Transfer Protocol）、ＳＩＰ（Session Initiation Protocol）などのアプリケーションが考えられる。ただし、アプリケーション２８０−１…２８０−ｒの種類は、上記の例に限られるものではなく、モジュール２５０−１…２５０−ｎを通じて他のノードあるいは他のアプリケーションと通信するものであれば、何れのソフトウェアでもよい。

次に、本実施例の動作について説明する。

まず、外部から受信したパケットは、第１の実施例と同様に処理されるが、本実施例では、モジュール２５０−１…２５０−ｎの処理が終わったあと、パケット送信部２２０−１…２２０−ｙではなく、受信ＡＰＩ２７０−１…２７０−ｑへ受け渡される場合が追加されている。受信ＡＰＩ２７０−１…２７０−ｑへ受け渡された受信データは、さらに受信対象アプリケーション２８０−１…２８０−ｒに渡されて処理される。

次いで、アプリケーション２８０−１…２８０−ｒが送信するデータは、送信ＡＰＩ２６０−１…２６０−ｐに受け渡される。送信ＡＰＩ２６０−１…２６０−ｐは、送信相手などのアプリケーション２８０−１…２８０−ｒが指定した情報をメタデータとして送信データに付与し、送信データをモジュール検索情報付与部２３０へ渡す。

次いで、モジュール検索情報付与部２３０では、与えられた送信データとメタデータより該当データを処理すべきモジュール２５０−１…２５０−ｎを並べ、メタ情報として送信データに付与して、モジュール検索情報付与部２３０へ送信データを戻す。以降、先頭のモジュール２５０−１…２５０−ｎから送信データを処理することで、該当送信データが処理される。

次に、図１４〜図１６を参照して、本実施例によるＵＤＰデータグラムの具体的な送信処理について説明する。この例では、アプリケーション２８０−１…２８０−ｒからＵＤＰ送信を行う場合である。

（１）まず、アプリケーション２８０−１…２８０−ｒは、図１４に示す送信ＵＤＰデータを用意する。

（２）次いで、アプリケーション２８０−１…２８０−ｒは、図１５に示す送信ＵＤＰデータの送信コンテキストとして、送信先アドレスとポート番号を用意する。

（３）次いで、アプリケーション２８０−１…２８０−ｒは、用意したデータを送信ＡＰＩ２６０−１…２６０−ｐに渡す。

（４）次いで、送信ＡＰＩ２６０−１…２６０−ｐは、アプリケーション２８０−１…２８０−ｒからのデータをモジュール検索情報付与部２３０へ渡す。

（５）次いで、モジュール検索情報付与部２３０が図１５に示す送信ＵＤＰデータの送信コンテキストから図１６に示すメタデータを作成してパケットに付加する。

（６）以後、受信時と同様の手順により処理する。

以上のように、本実施例では、アプリケーション２８０−１…２８０−ｒが、送信ＵＤＰデータに利用プロトコルとエンドポイントの情報を付与して、送信ＡＰＩ２６０−１…２６０−ｐに渡すと、送信ＡＰＩ２６０−１…２６０−ｐは、該当メタ情報を使って利用モジュール２５０−１…２５０−ｎを決定するようになっている。

なお、本実施例では、アプリケーションがＵＤＰを使うことをメタデータにより指定している場合を説明したが、本発明はこれに限定されず、もっと抽象的なメタデータを用いるような構成も考えられる。

たとえば、ＳＯＡＰ（例えば、Simple Object Access Protocol (SOAP) 1.1, W3C Note 08 May 2000, http://www.w3.org/TR/2000/NOTE-SOAP-20000508/参照）によりリモートノードに置かれたオブジェクトのメソッドを呼び出す場合、リモートノードへＳＯＡＰメッセージを伝送するための通信プロトコルにはとくに制限はない。このため、ＳＯＡＰメッセージにてＲＰＣを行うアプリケーションは、呼び出し先アプリケーションのＵＲＬのみを指定し、伝送路の選択はプロトコルモジュールにまかせても良い。このような場合、プロトコルモジュールは名前解決や到達性の情報などに基づき、適切な伝送プロトコルを選択する。

次に、本発明の第３の実施例を説明する。本実施例は、メタ情報だけを手元に置いておく構成について適用したものである。

第１の実施例では、全てのモジュールが通信装置内にあらかじめ存在していることを仮定していた。しかし、通信装置によっては、搭載されるメモリ等が少ないために、利用する可能性のあるモジュールをすべて保持することが困難なものもある。たとえば、小規模オフィス向け小型ルータや、テレビ受像機等の家電製品に通信機能を提供するセットトップボックス、携帯電話端末などの装置がこれに該当する。

このような装置では、資源の利用を節約するため、次のように必要なモジュールをネットワーク経由で取得し、不要になったら該当モジュールや利用資源を削除する手段を設けることが有効である。すなわち、通信に利用する可能性のあるモジュールのメタ情報のみを装置内に保持しておき、到着したパケットの処理に該当モジュールが必要であることが伝搬経路制約計算により分かった時点で、該当モジュールをネットワーク経由で取得することにより必要なモジュールを動的に取得できるようにする。

そこで、本実施例は、第１の実施例に加え、前記モジュールをネットワークより取得する手段を備えた構成としている。

図１７に本実施例の構成を示す。図１７において、本実施例の通信装置１００が接続されるネットワーク上には、モジュールリポジトリ３００が設置されている。モジュールリポジトリ３００は、本実施例の通信装置１００が利用するモジュール３１０を全部保持していて、通信装置１００からの要求に応じてモジュール３１０…３２０を通信装置１００へ送る機能を持つ。

モジュールリポジトリ３００は、単一のサーバにて構成できるのはもちろんのこと、複数のサーバで分散してモジュールを保持する構成も考えられる。また、各通信装置自身が、他の通信装置からの要求に応じて、自身が保持しているモジュール３１０…３２０を要求元へコピーできるようにし、通信装置全体でモジュールリポジトリ３００の機能を持つようにする構成も考えられる。複数の装置でモジュールリポジトリ３００を実現する場合には、モジュール３１０…３２０の所在を検索して取得できるような、検索システムを別途用意する必要がある。この検索システムは、モジュール３１０…３２０のメタ情報をキーとしてモジュールを特定する処理を行う。検索を高速にするため、たとえば、３２ビット整数などの、メタ情報を一意に識別するための短い識別子をメタ情報に含めても良い。

各通信装置１００には、モジュール管理部３９０を用意する。モジュール管理部３９０は、装置１００内に保持しているモジュール１４０−１…１４０−ｎの一覧を保持しており、モジュールリポジトリ３００と通信する手段を備えている。

モジュール管理部３９０は、伝搬経路制約計算部１３０が決定した利用モジュール情報を検査し、装置１００内のモジュール１４０−１…１４０−ｎに存在しないモジュールがあれば、モジュールリポジトリ３００から該当モジュール３１０…３２０を取得する。これにより、必要なモジュールを動的に取得する機能を実現できる。

さらに、資源が不足しているときなどに、当面利用する見込みがないモジュールが装置１００内にある場合は、該当モジュールや、該当モジュールが利用する資源を一時的に削除できるようにする。このようなモジュール削除手段は、次のようにすれば構成できる。

通信装置１００内にモジュール利用監視部を用意する。モジュール利用監視部は、装置内にあるモジュールの利用情報を収集し、不要なモジュールを決定するための情報をまとめる。モジュール利用情報には、たとえば、過去一定時間の受信データ処理回数、メモリ使用量、ＣＰＵ時間使用量がある。

また、通信装置１００内の資源の利用度合いを監視する資源監視部を用意する。さらに、上記モジュール利用情報と資源の利用度合いから、モジュールの保持優先度を決定するモジュール管理部を別途用意する（モジュール追加用のモジュール管理部と実装上は、単一にしても良いが、機能は異なる）。このモジュール管理部は、システムの資源の利用量とモジュールの利用頻度などの情報から、所定の規則にしたがって破棄すべきモジュールを決定する。破棄すべきモジュールがある場合は、該当モジュールや、そのモジュールが保持するデータを装置から削除する。

本実施例によれば、以上のように構成することで、必要なモジュールを入れ替えながら処理を継続することができるため、少ない資源で多くの機能を実現する装置を提供できる。

次に、本発明の第４の実施例を説明する。本実施例は、モジュール連結順をキャッシュしておく構成について適用したものである。

第１の実施例では、モジュール連結順をパケット受信毎に毎回計算している。こうすると、パケット処理の効率が著しく低下する場合も想定される。そこで、本実施例では、これを避けるため、たとえば、フローを開設するパケットについて、モジュール連結順を一度計算したら、該当連結順をキャッシュしておき、その後該フローに属するパケットが到着したら、同パケットについては該当連結順にしたがって処理するよう、第１の実施例を変更している。

図１８は、本実施例の構成を示すブロック図である。同図に示す本実施例のパケット処理装置４００は、伝搬経路制約計算部４３０内に、伝搬経路キャッシュ４３２と、伝搬経路高速検索部４３１とを備えている。

この構成により、パケットの受信により、伝搬経路制約計算部４３０がメタ情報に基づくモジュール連結順の計算を行うと、所定の条件を満たす場合には該当モジュール連結順を伝搬経路キャッシュ４３１内に保持しておく。次回以降、パケットを受信して、伝搬経路制約計算部４３０がモジュール連結順を決定するときには、該当キャッシュをパケットのヘッダの所定部分をキーとして検索し、検索にヒットしたキャッシュのエントリに記録されたモジュール処理順を、モジュール検索情報付与部４２０へ返戻する。

上記のモジュール連結順をキャッシュに格納する条件として、例えばＴＣＰコネクションが開設されるパケット（ＳＹＮフラグが含まれている）を送受信処理する場合は、たとえば"Ｅｔｈｅｒｎｅｔ受信"、"ＩＰｖ４受信"、"ＴＣＰ受信"のようなモジュール検索情報が生成される。また、この条件にマッチするキーとしては、例えばＴＣＰ端点を識別する情報、すなわちローカル側とリモート側のＩＰアドレスおよびポート番号をキャッシュ検索条件として保持する。

上記の例で格納されたモジュール連結順について、キャッシュを検索するときに使われるパケットのヘッダ情報の部位は、例えばＩＰヘッダの送信元および宛先アドレスと、ＴＣＰヘッダの送信元および宛先ポートとである。送信パケットについては、送信元がローカル側、受信パケットについては、送信元がリモート側として上記キャッシュ検索条件を検査し、マッチするエントリがあれば、そのキャッシュに格納されたモジュール検索情報を利用する。

従って、本実施例によれば、モジュールの処理順が同一順であるようなパケットが継続して到着することが予測できる場合には、該当条件を満たすパケットを処理するときに該当処理に使ったモジュール処理順の情報をキャッシュへ格納して保持し、次回以降のパケット処理では該当キャッシュを検索し、処理の該非判定を行わずにモジュールの処理順を決定することが可能になる。

次に、本発明の第５の実施例を説明する。本実施例は、無停止／無設定でモジュールを入れ替える構成について適用したものである。

あるプロトコルを実装するモジュールが、不具合の修正や機能追加などにより更新される場合がある。このような場合に、モジュールの更新を無停止かつ無設定にて行えないと、モジュールの更新時にサービスがいったん中断したり、設定作業のためにユーザーやメンテナンス担当者が時間を費やしたりしなければならない。

そこで、本実施例では、無停止かつ無設定のモジュール更新が行えるように構成している。この場合、更新前と更新後のモジュールのメタ情報は、同一であっても良いし、機能追加がある場合などはメタ情報に追加機能を示す識別情報を入れても良い。

また、本実施例では、フロー毎に、第４の実施例で説明したキャッシュ情報を用意しておく。該当キャッシュは、利用するモジュールの識別子をあらかじめ保持しておく。キャッシュにマッチしたパケットについては、フローが開設された時点のモジュールが使われ続ける。一方、新しく開設されるフローについては、新規に伝搬経路制約計算が行われるため、同一機能をもつ新旧のモジュールがある場合は、新しいほうのモジュールが使われる。

このようにして、本実施例では、新しいモジュールを装置に追加するだけで、パケット処理を中断させずにモジュールの更新が実現できる。

さらに、第３の実施例と組み合わせると、更新されたモジュールを明示的に個々の通信装置へ追加する作業も省略できる。更新モジュールをモジュールリポジトリへ追加すると、メタ情報で検索できるモジュールは更新済のものになる。また、各通信装置のモジュール管理部に、所定の時点で、装置内に存在するモジュールの更新を検査する機能を追加する。上記所定の時点は、具体的には、たとえば毎日の早朝の通信量の少ない時間などや、通信量があらかじめ定めた閾値を下回った時などである。

モジュール監理部は、モジュールリポジトリから検索できるモジュールが装置内にあるモジュールよりも新しいなど、更新されていることを検知した場合には、該モジュールを取得する。

本実施例によれば、以上のように構成することで、新しいモジュールをモジュールリポジトリへ追加すれば、通信装置にはいっさい設定を行うことなく、モジュールを更新することができる。

本発明は、ＩＰネットワークを構成するパケット中継装置、プロトコル終端装置などに適用できる。とくに、機能が複雑で今後更新が予想される機器に対して本発明を適用すると有効である。具体的には、セキュリティ機能を提供するファイアウォール装置、侵入検知装置、コンテンツフィルタなどや、家電製品などにネットワーク機能を提供する家庭用のセットトップボックスなどが考えられる。

Claims (15)

1. プロトコル処理を行う複数のモジュールの集合により構成される通信装置であって、
   プロトコルを実装する各モジュール毎に所定のメタ情報を保持するメタ情報保持手段と、
   前記メタ情報および処理対象パケットから前記各モジュールの連結順を計算する計算手段とを有することを特徴とする通信装置。
2. 前記メタ情報は、前記各モジュール毎に前記処理対象パケットのパケット処理の該非を判定する規則と、前記パケット処理の該非判定に必要とする該非判定済のモジュール情報と、前記処理対象パケットに付加して他のモジュールの該非判定に供するための情報とを有し、
   前記計算手段は、前記処理対象パケットに対して前記規則に従い前記各モジュールが処理可能かどうかの該非判定を行い、可能と判定された場合、前記他のモジュールの該非判定に供するための情報を前記処理対象パケットへ付加し、前記パケット処理の該非判定に必要とする該非判定済のモジュール情報と、パケットのデータ及び前記処理対象パケットに付加される他のモジュールの該非判定に供するための情報を用いて、前記処理対象パケットの全部分につき前記該非判定の結果処理可能となった前記各モジュールの連結順を出力することを特徴とする請求項１記載の通信装置。
3. プロトコル処理を行う複数のモジュールの集合により構成される通信装置であって、
   前記複数のモジュール毎に所定のメタ情報を個別に保持する手段と、
   処理対象のパケットと、前記複数のモジュールに個別に保持された前記メタ情報とに基づいて、前記複数のモジュール間でのパケット処理順を決定する処理順決定手段と、
   決定された前記パケット処理順の情報を前記パケットに添付する添付手段と、
   前記パケットに添付した前記パケット処理順の情報に基づいて、前記モジュールが前記パケットの伝播先を決定する手段とを備えることを特徴とする通信装置。
4. 請求項３記載の通信装置であって、
   前記パケットと、前記複数のモジュールに個別に保持されたメタ情報とに基づいて、前記複数のモジュール毎に前記パケットの少なくともヘッダの情報を処理可能なモジュールかどうかの該非判定を行う手段を有し、
   前記処理順決定手段は、前記該非判定の結果、前記複数のモジュールのうち前記パケットの少なくともヘッダの情報を処理可能なモジュールを特定し、特定されたモジュールの識別情報を順番に連結して前記複数のモジュール間でのパケット処理順として決定し、
   前記添付手段は、前記複数のモジュール間でのパケット処理順として決定された情報を前記パケットに添付し、
   前記パケットに添付された情報の順番に従い前記パケットが前記複数のモジュールのうち該当するモジュールへ受け渡され、当該モジュールの前記伝播先を決定する手段が前記パケットの伝播先を決定することを特徴とする通信装置。
5. 請求項４記載の通信装置であって、
   前記複数のモジュールを介して通信を行うアプリケーションソフトウェアと、
   前記複数のモジュールと前記アプリケーションソフトウェアとの間に接続される送信アプリケーションプログラムインタフェース（ＡＰＩ）および受信アプリケーションプログラムインタフェース（ＡＰＩ）と、
   前記送信ＡＰＩから前記複数のモジュール間でのパケット処理順を決定する手段を呼び出す手段とをさらに備えたことを特徴とする通信装置。
6. 請求項４記載の通信装置であって、
   前記複数のモジュールを格納するモジュールリポジトリとの間で通信を行う手段と、
   前記複数のモジュールのメタ情報のみを当該複数のモジュールと分離して保持する手段と、
   前記メタ情報により前記複数のモジュールのうち所定のモジュールがパケット処理に必要と判断したときは、該当モジュールを前記モジュールリポジトリより取得する手段と、
   前記複数のモジュールのうち不要となったモジュールを前記通信装置上から削除する手段とをさらに備えることを特徴とする通信装置。
7. 請求項４記載の通信装置であって、
   前記複数のモジュール間でのパケット処理順の情報をキャッシュへ格納して保持する手段と、
   前記キャッシュの情報を検索して前記複数のモジュール間でのパケット処理順を決定する手段とをさらに備えることを特徴とする通信装置。
8. 請求項６記載の通信装置であって、
   前記モジュールリポジトリに格納された前記モジュールが更新された場合、当該モジュールの更新を検知する手段と、
   前記モジュールの更新時に更新後のモジュールを取得し、新規のセッションについては更新後のモジュールを適用し、更新前のモジュールが処理している既存セッションについては更新前のモジュールを適用する手段とをさらに備えることを特徴とする通信装置。
9. プロトコル処理を行う複数のモジュールの集合により構成される通信装置の動作方法であって、
   前記複数のモジュール毎に所定のメタ情報を個別に保持するステップと、
   処理対象のパケットと、前記複数のモジュールに個別に保持された前記メタ情報とに基づいて、前記複数のモジュール間でのパケット処理順を決定する処理順決定ステップと、
   決定された前記パケット処理順の情報を前記パケットに添付する添付ステップと、
   前記パケットに添付した前記パケット処理順の情報に基づいて、前記モジュールが前記パケットの伝播先を決定するステップとを有することを特徴とする通信装置の動作方法。
10. 請求項９記載の通信装置の動作方法であって、
    前記パケットと、前記複数のモジュールに個別に保持されたメタ情報とに基づいて、前記複数のモジュール毎に前記パケットの少なくともヘッダの情報を処理可能なモジュールかどうかの該非判定を行うステップを含み、
    前記処理順決定ステップでは、前記該非判定の結果、前記複数のモジュールのうち前記パケットの少なくともヘッダの情報を処理可能なモジュールを特定し、特定されたモジュールの識別情報を順番に連結して前記複数のモジュール間でのパケット処理順として決定し、
    前記添付ステップでは、前記複数のモジュール間でのパケット処理順として決定された情報を前記パケットに添付し、
    前記伝播先を決定するステップでは、前記パケットに添付された情報の順番に従い前記パケットが前記複数のモジュールのうち該当するモジュールへ受け渡され、当該モジュールが前記パケットの伝播先を決定することを特徴とする通信装置の動作方法。
11. 請求項１０記載の通信装置の動作方法であって、
    前記複数のモジュールと、モジュール化されていないアプリケーションソフトウェアとの間に接続された送信アプリケーションプログラムインタフェース（ＡＰＩ）および受信ＡＰＩにより、前記複数のモジュールを介して前記アプリケーションソフトウェアが通信を行うステップと、
    前記送信ＡＰＩから前記複数のモジュール間でのパケット処理順を決定する機構を呼び出すステップとをさらに有することを特徴とする通信装置の動作方法。
12. 請求項１０記載の通信装置の動作方法であって、
    前記複数のモジュールを格納するモジュールリポジトリとの間で通信を行うステップと、
    前記複数のモジュールのメタ情報のみを当該複数のモジュールと分離して保持するステップと、
    前記メタ情報により前記複数のモジュールのうち所定のモジュールがパケット処理に必要と判断したときは、該当モジュールを前記モジュールリポジトリより取得するステップと、
    前記複数のモジュールのうち不要となったモジュールを前記通信装置上から削除することを特徴とする通信装置の動作方法。
13. 請求項１０記載の通信装置の動作方法であって、
    前記複数のモジュール間でのパケット処理順の情報をキャッシュへ格納して保持するステップと、
    前記キャッシュの情報を検索して前記複数のモジュール間でのパケット処理順を決定するステップとをさらに有することを特徴とする通信装置の動作方法。
14. 請求項１２記載の通信装置の動作方法であって、
    前記モジュールリポジトリに格納された前記モジュールが更新された場合、当該モジュールの更新を検知するステップと、
    前記モジュールの更新時に更新後のモジュールを取得し、新規のセッションについては更新後のモジュールを適用し、更新前のモジュールが処理している既存セッションについては更新前のモジュールを適用するステップとをさらに有することを特徴とする通信装置の動作方法。
15. プロトコル処理を行う複数のモジュールの集合により構成される通信装置の動作プログラムであって、
    コンピュータに、
    前記複数のモジュール毎に所定のメタ情報を個別に保持するステップと、
    処理対象のパケットと、前記複数のモジュールに個別に保持された前記メタ情報とに基づいて、前記複数のモジュール間でのパケット処理順を決定するステップと、
    決定された前記パケット処理頃の情報を前記パケットに添付するステップと、
    前記パケットに添付した前記パケット処理順の情報に基づいて、前記モジュールが前記パケットの伝播先を決定するステップとを実行させることを特徴とする通信装置の動作プログラム。

Images