JP4348227B2 - 階層型パケット処理システム、中継装置、サーバ、その方法、及びそのプログラム - Google Patents

Description

本発明は、パケットを中継する際にフィルタ処理するパケット中継技術に関する。

近年、パケット中継装置は不用意な通信をシャットアウトするため高度なフィルタ処理を備える。
なかでもステートフルインスペクションと呼ばれる技術は、ＩＰ層よりも上位の通信セッションの状態を監視することで、パケットの通過許可／不許可をよりきめ細かく制御することができる。

ステートフルインスペクションは、パケット受信の度に、コネクションを認識し、各コネクションの状態を更新し、フィルタ条件とつき合わせてパケットの通過可否を判断する。上記処理はほぼ全てのパケットに対し処理が必要になる反面、パケットの上位レイヤヘッダやペイロード部分の監視、状態管理、パケットのデフラグメント／リフラグメント等、単純なパケット処理に留まらない。このため、ハードウエア化すると装置規模が大きくなってしまう。

そこで、ネットワークプロセッサを用いるという方法も考えられる。しかし、この方法では十分な性能がでない、プログラム可能なメモリにも制限があるなど、事実上の実装が困難であることが証明されている。

一方、サーバとネットワーク接続装置からなる系で、ネットワーク接続装置の中継処理においてパケットの詳細解析を行なう場合、そのパケットをサーバへ振り分けて詳細解析させる技術がある。この技術では先ず始めに、振分先であるサーバを予めポリシーテーブルに認識させておく必要がある。サービス処理部に対してパケットを振り分ける処理振分部は、パケットを受信すると上記ポリシーテーブルに基づき、当該パケットをサービス処理部または所定のサーバへ転送する。この転送により、処理が外部に分散され、ネットワーク接続装置での処理の負担を軽減できる（特許文献１参照）。
特開２００２−３５９６３７号公報

上述したように上記パケットをサーバへ振り分ける技術では、その振分先をポリシーテーブルに指定する。これにより上記処理振分部は、各サービス処理部或いは外部のサーバへ処理を振り分けることが可能になる。

しかし、振り分け先であるサーバが頻繁に移動されたり、該サーバによって提供されるサービスが変えられるなどすると、上記ポリシーテーブルに指定した振り分け先のサーバを指定し直さなければならない。

このため、サーバの追加や変更等に基づく中継装置の調整に多大な手間を生じ、問題であった。
そこで本発明は、サービス処理を行なうサーバの追加・変更等において好適で且つ高速中継処理を実現する階層型パケット処理技術を提供することを目的とする。

本発明は上記課題を解決するために以下のように構成する。
本発明の階層型パケット処理システムの態様一つは、受信パケットを対象にサービス処理を行なって上記受信パケットを中継処理する、中継部とサーバからなることを前提とし、上記中継部は、上記受信パケットを対象にサービス処理を行なう所定のサービス処理部を呼び出す呼出部と、上記呼出部の呼び出しにより、上記受信パケットにサービス処理を行なう第一のサービス処理部と、上記呼出部の呼び出しにより、上記受信パケットに仮想的にサービス処理を行なう第二のサービス処理部と、を有し、上記サーバは、上記第二のサービス処理部が上記呼出部から呼び出されると、上記第二のサービス処理部の代わりに上記受信パケットに対して任意のサービス処理を行なう外部サービス処理部を、有するように構成する。

なお、上記呼出部の呼び出しにより上記第二のサービス処理部が呼び出されると、上記受信パケットは処理依頼キューに一時的にキューイングされ、続く受信パケットに対するサービス処理が上記呼出部によって続いて呼び出されたサービス処理部によって行なわれる、ように構成してもよい。

また、上記外部サービス処理部は、中継部における受信パケットの中継処理で使用されてるＣＰＵが空いた時間を利用して上記サービス処理を行なう、ように構成してもよい。
また、受信パケットに対するコネクション状態を管理するコネクション状態管理部を更に有し、上記外部サービス処理部は、上記受信パケットの上位レイヤの状態を検出し、該上位レイヤの状態の検出結果を基に、上記コネクション状態管理部に管理される上記受信パケットの上記コネクション状態を更新し、上記中継部で受信された同一のコネクションパケットは、上記外部サービス処理部によって更新された上記コネクション状態管理部の上記コネクション状態に基づいてフィルタ処理される、ように構成することが望ましい。

また、上記仮想サービス処理部は、上記受信パケットに対するサービス処理を上記サーバへ振り分けるため、サービス処理を行なうサーバの情報及び該サーバが提供するサービス処理の識別情報とをパケットの種類に応じて管理するサービスリスト管理部を有し、上記サーバは、上記サービスリスト管理部に対し、自己サーバの情報及び該自己サーバが提供するサービス処理の識別子とを転送する転送部を有する、ように構成することが望ましい。

本発明の中継装置の態様一つは、受信パケットを対象にサービス処理を行なって上記受信パケットを中継処理することを前提とし、上記受信パケットを対象にサービス処理を行なう所定のサービス処理部を呼び出す呼出部と、上記呼出部の呼び出しにより、上記受信パケットにサービス処理を行なう第一のサービス処理部と、上記呼出部の呼び出しにより、上記受信パケットに仮想的にサービス処理を行なう第二のサービス処理部と、上記受信パケットの上位レイヤの状態の検出に基づく情報を管理するコネクション状態管理部と、上記第二のサービス処理部が上記呼出部から呼び出されると、受信パケットの内の所定の情報を所定のサーバへ送信する送信部と、上記サーバから送信された情報を受信する受信部と、上記受信した結果を上記受信パケットまたは上記コネクション状態管理部で管理される上記情報に反映する反映部と、同一のコネクションパケットに対し、上記コネクション状態管理部で管理される上記反映後の情報に基づいてフィルタ処理するフィルタ処理部と、を有するように構成する。

なお、上記呼出部の呼び出しにより上記第二のサービス処理部が呼び出されると、上記受信パケットは処理依頼キューに一時的にキューイングされ、続く受信パケットに対するサービス処理が上記呼出部によって続いて呼び出されたサービス処理部によって行なわれる、ように構成してもよい。

また、上記第二のサービス処理部は、上記受信パケットに対するサービス処理を上記サーバへ振り分けるため、サービス処理を行なうサーバの情報及び該サーバが提供するサービス処理の識別情報とをパケットの種類に応じて管理するサービスリスト管理部を有する、ことが望ましい。

本発明のサーバの態様一つは、中継装置で受信されたパケットの内の所定の情報を上記中継装置から受信することを前提とし、コネクションの状態を管理するコネクション状態管理部と、上記パケットの上位レイヤの状態を検出してサービス処理する上位レイヤ検出部と、上記上位レイヤ検出部によって検出された上記パケットの上位レイヤの状態を基に、上記コネクション状態管理部によって管理される上記パケットのコネクション状態を更新するコネクション状態更新部と、上記サービス処理の結果及び上記コネクション状態の更新情報を上記中継装置に送信する送信部と、を有するように構成する。

なお、上記サーバは、サービス処理を行なうサーバの情報及び該サーバが提供するサービス処理の識別情報とをパケットの種類に応じて管理する上記中継装置のサービスリスト管理部に対し、自己サーバの情報及び該自己サーバが提供するサービス処理の識別子とを転送する転送部を有する、ように構成することが望ましい。

本発明の方法の態様一つは、受信パケットを対象にサービス処理を行なって上記受信パケットを中継処理する、中継部とサーバからなる階層型パケット処理システムで行なわれることを前提とし、上記中継部は、上記受信パケットを対象にサービス処理を行なう第一または第二のサービス処理部を呼び出し、上記呼び出しにより第一のサービス処理部が呼び出された場合は、上記受信パケットにサービス処理を行ない、上記呼び出しにより第二のサービス処理部が呼び出された場合は、上記受信パケットに仮想的にサービス処理を行ない、上記サーバは、上記第二のサービス処理部が上記呼び出されると、上記第二のサービス処理部の代わりに上記受信パケットに対して実際にサービス処理を行なう、ようにする。

なお、受信パケットに対するコネクション状態をコネクション状態管理部で管理し、上記サーバは、上記受信パケットの上位レイヤの状態を検出し、該上位レイヤの状態の検出結果を基に、上記コネクション状態管理部に管理される上記受信パケットの上記コネクション状態を更新し、上記中継部は、同一のコネクション受信パケットを、上記更新された上記コネクション状態管理部の上記コネクション状態に基づいてフィルタ処理する、ことが望ましい。

本発明のプログラムの態様一つは、受信パケットを対象にサービス処理を行なって上記受信パケットを中継処理する、中継部とサーバで実行可能なプログラムであって、上記中継部において、上記受信パケットを対象にサービス処理を行なう第一または第二のサービス処理部を呼び出す機能と、上記呼び出しにより第一のサービス処理部が呼び出された場合は、上記受信パケットにサービス処理を行なう機能と、上記呼び出しにより第二のサービス処理部が呼び出された場合は、上記受信パケットに仮想的にサービス処理を行なう機能と、を実現し、上記サーバにおいて、上記第二のサービス処理部が上記呼び出されると、上記第二のサービス処理部の代わりに上記受信パケットに対して実際にサービス処理を行なう機能と、を実現する。

なお、受信パケットに対するコネクション状態をコネクション状態管理部で管理する機能と、上記サーバにおいて、上記受信パケットの上位レイヤの状態を検出する機能と、該上位レイヤの状態の検出結果を基に、上記コネクション状態管理部に管理される上記受信パケットの上記コネクション状態を更新する機能と、上記中継部において、同一のコネクション受信パケットを、上記更新された上記コネクション状態管理部の上記コネクション状態に基づいてフィルタ処理する機能と、を実現することが望ましい。

本発明では、呼出部の呼び出しに応じて、サービス処理をサーバの外部サービス処理部で行なわせる。そしてこの際に、呼出部に対し、中継部で処理を行なっているように見せかけて、実際に処理を行なっているサーバ及びサービス処理の存在を隠蔽する。

このため、上記呼出部からは、上記第二のサービス処理部が何れのサーバで何れのサービス処理を行なわせているか認識できない。よって、仮にサーバや外部サービス処理部のサービス処理に追加・変更等があったとしても、該追加・変更等に基づく呼出部の設定変更は不要となる。

また本発明では、サーバでサービス処理を行なわせる場合、受信パケットを処理依頼キューに一時的に保管し、この間、同一のコネクションの受信パケットを処理するようにしている。

このため、例えば複雑な処理をサーバに行なわせた場合であっても、上記複雑な処理が終わるまで同一のコネクション受信パケットの処理を止める必要がなくなり、同一のコネクション受信パケットを次々と処理できる。

また、サーバで行なわれるサービス処理を、中継部における受信パケットの中継処理で使用されてるＣＰＵが空いた時間を利用して行なうようにする。
このため、サーバで行なうサービス処理よりも中継部で行なう中継処理を優先することが可能になる。

また、本発明では、サーバで行なうサービス処理において、上記受信パケットの上位レイヤの状態を検出し、該上位レイヤの状態の検出結果を基にコネクション状態管理部に管理される上記受信パケットのコネクション状態を更新する。そして、上記中継部で受信された同一のコネクション受信パケットを、上記更新後のコネクション状態に基づいてフィルタ処理させる。

このため、上位レイヤの状態検出に基づくコネクション状態の更新をサーバで行なわせることが可能になり、中継部では単に、上記更新後のコネクション状態を参照するだけでフィルタ処理が行なえる。

また、本発明では、上記受信パケットに対するサービス処理を中継部からサーバへ振り分けるための、サービス処理を行なうサーバの情報及び該サーバが提供するサービス処理の識別情報とをサーバからサービスリストに登録させる。

このため、サーバから、自己サーバの情報及び該自己サーバが提供するサービス処理の識別子とを中継部のサービスリストへ転送することで、中継部によるパケットの振り分け先のサーバを変更できる。

以上より本発明においては、サービス処理を行なうサーバの追加・変更等を行なう場合であってもその変更を容易に行なうことが可能になる。また、中継処理を高速に行なわせることが可能になる。

以下、本発明を実施するための最良の形態を、図面を参照しながら詳細に説明する。
図１は、本発明に適用される階層型パケット処理技術の原理を説明するための図である。本階層型パケット処理技術は、異種または同種のネットワーク間に接続される中継システムにおいて好適に適用される技術であり、受信パケットに対するパケットサービス処理を中継部とサーバとに振り分けて行なわせることによりパケットの高速中継処理を実現させる。

同図は、上記中継部及び上記サーバの、上記パケットサービス処理を行なう処理系の論理ブロック図である。
同図の中継部１には、呼出部１−１、サービス処理部１−２、及び仮想サービス処理部１−３が構成される。また同図のサーバ２には、仮想呼出部２−１、外部サービス処理部２−２が構成される。

上記中継部１の呼出部１−１は、受信パケットに応じてサービス処理部１−２または仮想サービス処理部１−３を呼び出し、サービス処理部１−２または仮想サービス処理部１−３に対し、当該受信パケットに対する各自のサービス処理を互いに独立して実行させる。

上記サービス処理部１−２は、例えばタイマー更新処理やパケット通過／廃棄処理などのパケットｂｙパケット処理を、受信パケットに該当のコネクション状態を管理する後述のコネクション状態管理部を参照しながら当該受信パケットに実行する。

また上記仮想サービス処理部１−３は、当該受信パケットに対するサービス処理の実行を上記サーバ２の仮想呼出部２−１に委託し、更に該仮想呼出部２−１から当該サービス処理の実行結果を受け取ることにより、上記サーバ２で実行されたサービス処理（以下、外部サービス処理と呼ぶ）を、当該仮想サービス処理部２−１であたかも実行したかのうように上記呼出部１−１に見せかける。上記外部サービス処理の好適な例としては、受信パケットの上位レイヤを分析して上記コネクション状態管理部の対応コネクションの状態を更新するステートフル処理が挙げられる。

一方、上記サーバ２の外部サービス処理部２−２は、上記仮想呼出部２−１によって仮想的に呼び出され、上記中継部１の仮想サービス処理部１−３から上記仮想呼出部２−１に委託された外部サービス処理を実際に実行し、その実行結果を仮想呼出部２−１に与える。そして仮想呼出部２−１は、上記中継部１の仮想サービス処理部１−３に対してその実行結果を返す。このとき、上記外部サービス処理として上記ステートフル処理が適用される場合は、上記コネクション状態管理部をサーバ２から更新可能なように構成し、上記コネクション状態管理部の対応個所の更新も行なう。

なお、中継部１から如何なる種類のサービス処理をサーバ２に委託するか、当該サービス処理を如何なるサーバ２へ振り分けるかについての情報登録や登録情報の変更は、サーバ２及び仮想サービス処理部１−３が行なう。

このように本階層型パケット処理の技術によれば、受信パケットに対するサービス処理を中継部１だけでなく、サーバ２に実行させることができる。この場合、特に、中継部１においてパケットｂｙパケット処理を行なわせ、サーバ２においてコネクション状態管理部を更新する複雑で重たい処理（ステートフル処理）を行なわせれば、中継部１でコネクション状態管理部を更新するための上記複雑で重たい処理を行なう必要はなくなる。このため中継部１では、上記コネクション状態管理部を参照して受信パケットの通過／廃棄を決定する、或いはタイマーを更新するなど、単純で軽い処理を行なわせることが可能になる。そして更に、中継部１とサーバ２のサービス処理を互いに独立して行なわせるため、処理時間のかかるサーバ２のサービス処理が終わるのを待つことなく中継部１のサービス処理を次々に受信パケットに対して行なえ、パケット中継が高速になる。また、如何なるサーバ２で如何なる外部サービス処理が実行されようとも、中継部１の呼出部１−１からはある所定のサービス処理に見える仮想サービス処理を呼び出すだけなので、各種サービス処理を呼び出す呼出部１−１の呼び出し設定やパケットｂｙパケット処理を行なう各部や設定を変更することなく、受信パケットに対して実行させる外部サービス処理の種類や当該外部サービス処理を行なうサーバの転送先を変更できる。また、中継部１の呼出部１−１による外部サービスの呼び出しが、あたかもサーバ２の仮想呼出部２−１から行なわれているかのように仮想化させているため、サーバ２の外部サービス処理部２−２も、相対する中継部１の設定変更を意識する必要がない。

そして、特に、上記仮想サービス処理部１−３及びサーバ２の各部の機能をソフトウエアで実現し、パケットｂｙパケット処理を行なう各部をハードウエアで実現することで、パケット中継処理の高速化と、外部サービス処理の設定変更に対する柔軟性とを享受できる。

続いて、上記論理ブロックの実装例を示す。
なお本例では、Ｌｉｎｕｘ（登録商標）において本メカニズムを実装した場合の例を示すこととする。

図２（ａ）は、図１の中継部１の実装例である。
同図によると、上記中継部１は、「ＮＦ＿ＨＯＯＫ」１０−１、パケットｂｙパケット処理カーネル関数を提供するサービス処理部１０−２、及び仮想ボトムハーフ処理部１０−３によって構成することができる。

同図の「ＮＦ＿ＦＯＯＫ」１０−１はカーネル内の機能である。当該「ＮＦ＿ＦＯＯＫ」１０−１は、受信パケットのヘッダ情報或いは、当該受信パケットに対するコネクションの状態が記述された不図示のコネクション状態管理テーブルを参照し、当該受信パケットは、上記サービス処理部１０−２が提供するサービス処理を実行させるものであるか、または上記仮想ボトムハーフ処理部１０−３が提供するサービス処理を実行させるものであるか判定する。

当該判定により、上記サービス処理部１０−２が提供するサービス処理を当該パケットに対して実行させるものである場合は、該当するパケットｂｙパケット処理カーネル関数によって提供される処理を実行させ、その処理結果を得る。また、上記判定結果が、上記仮想ボトムハーフ処理部１０−３が提供するサービス処理（すなわち外部サービス処理）を当該パケットに対して実行させるものである場合は、当該パケットを仮想ボトムハーフ処理部１０−３に渡し、該仮想ボトムハーフ処理部１０−3からサービス処理後のパケットを得る。

サービス処理部１０−２は、パケットｂｙパケット処理カーネル関数が呼び出されると、受信パケットに対し、カーネルに実装された対応処理（例えばタイマー更新やコネクション状態管理テーブルの参照に基づくフィルタリング処理など）を実行する。

仮想ボトムハーフ処理部１０−３は、上記「ＮＦ＿ＦＯＯＫ」１０−１に対し該「ＮＦ＿ＦＯＯＫ」１０−１から渡されたパケットを自身で処理しているかのように見せかけ、その実際の処理をサーバ２に行なわせる。本例では、当該仮想ボトムハーフ処理部１０−３はユーザプロセスとして記述する。従って、仮想ボトムハーフ処理部１０−３には、カーネル内の機能である上記「ＮＦ＿ＦＯＯＫ」１０−１と上記ユーザプロセス間で処理の交換ができるように、カーネルから提供される処理依頼キュー（ip queue）１０−３−１が使用される。また、当該仮想ボトムハーフ処理部１０−３には、更に、上記処理依頼キュー１０−３−１との間で処理を交換するための処理取り出し／書き込み機能１０−３−２と、当該処理（パケットに対する外部サービス処理）の処理依頼を図１のサーバ２に転送するための転送機能１０−３−３とをプロキシスレッドＦＰの形態で備える。

転送機能１０−３−３は、受信パケットに対して実行する外部サービス処理の識別情報や当該外部サービス処理を実行させるサーバ２の情報を書き替え自在に記録したサービスリストを備え、当該サービスリストに基づいて、受信パケットに対する所定の外部サービス処理を所定のサーバ２へ委託する。また、サーバ２から送信された情報（例えばサービスリストの更新情報、外部サービス処理の結果情報など）を受信する。

上記処理取り出し／書き込み機能１０−３−２は、上記処理依頼キュー１０−３−１から処理情報を取り出し、サーバ２で外部サービス処理ができるように処理情報を編集したり、サーバ２から送信された結果情報をこれに対応するパケットに反映させ、反映パケットを上記処理依頼キュー１０−３−１に書き込んだりする。

図２（ｂ）は、図１のサーバ２の実装例である。
同図によると、上記サーバ２は、仮想「ＮＦ＿ＦＯＯＫ」２０−１、「フックボトムハーフ実行カーネル関数」２０−２によって構成することができる。

同図の仮想「ＮＦ＿ＦＯＯＫ」２０−１は、中継部１に対して処理応答（例えば外部サービス処理の処理結果など）を返すための転送機能２０−１−１と、「フックボトムハーフ実行カーネル関数」２０−２によって提供されるサーバ２のカーネル内の処理を呼び出す処理呼出機能ＰとをプロキシスレッドＳＰの態様で備える。そして更に、当該仮想「ＮＦ＿ＦＯＯＫ」２０−１では、上記処理呼出機能Ｐの一部（すなわち同図の処理呼出機能Ｋ）をカーネル内に配置させる。なお、本例では「フックボトムハーフ実行カーネル関数」２０−２においてフックボトムハーフ機能が適用されているが、これは、優先して行なわなければならない処理を優先的にＣＰＵ（中央処理装置）に実行させる機能であり、当該「フックボトムハーフ実行カーネル関数」として登録されている処理は、上記優先処理の終わったタイミング（例えばＣＰＵの空き時間等）に実行される。

上記転送機能２０−１−１は、中継部1から送信された処理依頼を受け付けたり、該処理依頼に対して実行した外部サービス処理の結果を該当する中継部１へ転送する。また、中継部１の転送機能１０−３−３に備えられるサービスリストの更新（外部サービスの種類の追加・削除・変更や当該外部サービスを提供するサーバ情報の追加・削除・変更など）を行なう。

上記処理呼び出し機能Ｐは、システムコールにより、カーネル内の処理呼び出し機能Ｋを介して上記「フックボトムハーフ実行カーネル関数」２０−２を呼び出し、転送機能２０−１−１によって受信した処理依頼に基づく処理を実行させる。そして、その実行結果を受け取ると転送機能２０−１−１に渡す。

なお、上記処理では、適宜、不図示のコネクション状態管理テーブルが更新される。仮に、上記コネクション状態管理テーブルがサーバ２と中継部１にそれぞれ装備されているとすると、上記サーバ２のコネクション状態管理テーブルの更新を基に、サーバ２の転送機能２０−１−１及び中継部１の転送機能１０−３−３を介して中継部１のコネクション状態管理テーブルの同期をとることができる。このように中継部１及びサーバ２のそれぞれにコネクション状態管理テーブルを装備すれば、サーバ２のコネクション状態管理テーブルを状態の書き替え対象とし、中継部１のコネクション管理テーブルを参照やタイマーの更新を対象とする使い分けができる。

また、「フックボトムハーフ実行カーネル関数」２０−２側には、自己のカーネル内の「ＮＦ＿ＦＯＯＫ」から呼ばれたように見せかけることができる。
言うまでもないことだが、上記中継部１及びサーバ２は、それらの独立した処理を共通のＣＰＵで実行させる中継システム（以下、階層型パケット処理システムと呼ぶ）、並びに、異なるＣＰＵで実行させる階層型パケット処理システムに実装できる。特に共通のＣＰＵを持つ階層型パケット処理システムに実装した場合は、上記フックボトムハーフ機能により、中継部１のパケットｂｙパケット処理を優先的にＣＰＵで実行させ、サーバ１の外部サービス処理は上記ＣＰＵの空き時間などを利用して行なわせることができる。

図３は、通信ケーブルを介して接続される異なる装置（中継装置及びサーバ）に上記中継部１とサーバ２を別々に実装した場合の上記階層型パケット処理システムの機能ブロック図である。

本例の継装置３００とサーバ３５０によって構成され、互いに通信ケーブルを介して接続されている。
同図に示される階層型パケット処理システム３０の機能ブロック図では、上記中継装置３００とサーバ３５０が備えている機能を装置３００、３５０毎に分けて示している。同図に示されるように、上記中継装置３００にはカーネル部３０１と同図に破線で囲まれる常駐型プログラム（以下、デーモンと呼ぶこととする）３０２が備えられ、上記サーバ３５０にはカーネル部３５１と同図に破線で囲まれるデーモン３５２が備えられている。

上記デーモン３０２は、同図に示されるように、マウントスレッド３０３、シグナリングスレッド３０４、プロキシスレッド３０５、及び、後述する例えば受信表、振分表、テーブルＩＤなどのサービスリストを備えている。また、上記デーモン３５２も同様な機能を有するスレッド（マウントスレッド３５３、シグナリングスレッド３５４、及びプロキシスレッド３５５）及び、後述の例えば送信表、受信表、テーブルＩＤなどの転送情報（上記サービスリストに対応する情報を含む）を備えている。

上記各マウントスレッド３０３、３５３は、中継装置３００に設定されているパケット取り込み用のネットワークインタフェース（同図のＩＦ１及びＩＦ２）と、サーバ３５０に仮想的に設定させるネットワークインタフェース（同図の仮想ＩＦ１及び仮想ＩＦ２）とのマッピング情報を両装置３００、３５０上に作成するプロセス（マウントプロセス）である。

管理者がサーバ３５０においてマウントコマンド３５６を実行することにより、サーバ３５０のマウント情報３５７の中からＩＦが指定され、そのＩＦに対するマウント要求が中継装置３００に送信される。中継装置３００では管理者が予め中継装置３００においてマウント許可リスト設定コマンド３０６を実行しており、マウント許可リスト３０７にマウントを許可するＩＦを設定している。このため、サーバ３５０から送信されたマウント要求は、上記マウント許可リスト３０７の設定内容（当該ＩＦに対してマウントを許可する、または、許可しないの設定）に基づき、上記マウント要求のあったＩＦに対するマウント許可の応答をサーバ３５０に返信する。このマウントプロセスにより、ＩＦトンネル対応情報が中継装置３００の受信表３０８及びサーバ３５０の送信表３５８に設定され、サーバ３５０上に中継装置３００の実ＩＦが仮想的に作成される。

なお、管理者により上記マウント許可リスト設定コマンド３０６が実行されると、例えば、中継装置３００上のネットワークインタフェースの中で、サーバ３５０の外部サービス処理対象に指定するネットワークインタフェース（同図におけるＩＦ１、ＩＦ２）を後述するフックハンドラに登録しておくことができる。

また、サーバ３５０が複数存在する場合には上記サービスの提供対象とする上記中継装置３００上のネットワークインタフェースを複数のサーバ３５０上の仮想ＩＦへ対応づける必要があるため、上記マウントプロセスでは、上記中継装置３００のネットワークフェースと複数のサーバ３５０の仮想ＩＦとのマッピング情報を、プロセスの持つポート番号を用いて上記中継装置３００の受信表３０８及びサーバ３５０の送信表３５８に設定する。

上記各シグナリングスレッド３０４、３５４は、サーバ３５０で提供する外部サービス処理を中継装置３００から利用できるように設定するためのプロセス（シグナリングプロセス）である。当該シグナリングプロセスでは、中継装置３００上で外部サービス処理が呼び出された時にその処理依頼メッセージを中継装置３００から所定のサーバ３５０へ転送できるようにするために、両装置３００、３５０間にその転送表を設定する。このシグナリングプロセスでは、例えば、管理者が同図のサーバ３５０上でサービス起動コマンド３５９を実行して、サーバ３５０が備える所定のサービスモジュールを中継装置３００から呼びだしできるように起動し、中継装置３００と該中継装置が呼び出すサーバ３５０のサービスモジュールとの対応表を中継装置３００の振分表３０９及びサーバ３５０の受信表３５９に設定する。なお、この処理については後に詳しく説明することにする。

また、デーモン３０２及びデーモン３５２は、それぞれ、テーブルＩＤ３１０及びテーブルＩＤ３６０を備える。これらには、中継装置３００のカーネル部３０１及びサーバ３５０のカーネル部３５１に共に備えられている後述のステートテーブル（上記コネクション状態管理テーブルに一部が対応）の場所が指定されている。

上記プロキシスレッド３０５、３５５は、中継装置３００において後述のコネクショントラッキング処理により検出された特定のパケットをサーバ３５０で処理させたり、中継装置３００及びサーバ３５０の各カーネル部３０１、３５１に実装された後述のステートテーブルを同期させるためのプロセス（プロキシプロセス）である。

上記プロキシスレッド３０５は、カーネル部３０１から上記特定のパケットを受信し、パケットの全てまたは該パケットの内で外部サービス処理に必要な情報（以下、必要情報とする）のみ抽出し、上記マウントプロセス及びシグナリングプロセスにより設定された送信表３０８及び振分表３０９に従って該当サーバ３５０のプロキシスレッド３５５に上記パケットまたは上記必要情報を含む処理依頼メッセージを送信する。一方、上記プロキシスレッド３５５は上記処理依頼メッセージを受け取るとカーネル部３５１にその処理を渡して該当のサービス処理を実行させ、該カーネル部３５１からその処理結果を受け取る。プロキシスレッド３５５は、上記マウントプロセス及びシグナリングプロセスにより設定された送信表３５８及び受信表３５９に従って、その処理結果（例えば、変更情報や、パケットの通過や廃棄を知らせる情報など）を処理応答メッセージとして上記プロキシスレッド３０５に送信する。そして、プロキシスレッド３０５は、カーネル部３０１にその処理結果を返す。また更に、プロキシスレッド３５５は、カーネル部３５１に実装されたステートテーブルの更新を検出すると、上記テーブルＩＤに指定されたプロキシスレッド３０５に対し、テーブル同期メッセージとしてその更新情報を送信し、プロキシスレッド３０５はカーネル３０１内に実装されたステートテーブルの更新を行なう。

次にカーネル部について説明する。
中継装置３００のカーネル部３０１には、パケットの処理経路が太い矢印で示されている。本例の処理経路には５つのフック処理部３１１〜３１５と二つのルーティング処理部３１６（３１６−１、３１６−２）とが実装されている。また更に、フック情報テーブル３１７、フックハンドラ３１８、ステートテーブル３１９、及びフィルタルール３２０が実装されている。

上記フック情報テーブル３１７は、例えばタイマー更新処理やパケットの通過・パケットの廃棄を行なうフィルタ処理など、簡易処理を行なうパケットｂｙパケット処理、或いは複雑な処理をサーバに委託するコネクショントラッキング（またはコントラック）処理（以下では、一部にパケットｂｙパケット処理を含んでいる場合もコネクショントラッキング処理と呼ぶこととする）など、複数の処理を登録することができるテーブルである。同図には、上記処理経路のパケットの取り込み口（同図のＩＦ１）に最も近い位置に示されるフック処理部３１１のフック情報テーブル３１７のみが示されているが、その他の各フック処理部３１２〜３１５に対してもそれぞれフック情報テーブルが備えられている。各フック処理部３１１〜３１５は、各フック処理部３１１〜３１５に対応するフック情報テーブルに登録された処理を受信パケットに対して順じ実行する。

本例では、フック処理部３１１及びフック処理部３１４においてコネクショントラッキング処理を実行するようにフック情報テーブルが設定され、その他のフック処理部３１２、３１３、３１５ではフィルタ処理（同図のルール設定部３２１によって書き替え自由にフィルタリングのポリシーが定義づけされる上記フィルタルール３２０や、セッション状態を管理する後述のステートテーブル３１９を参照し、受信パケットの通過・廃棄を判断する処理）を実行するようにフック情報テーブルが設定されている。

上記フックハンドラ３１８は、上記フック情報テーブル３１７に設定されているコネクショントラッキング処理の際に呼び出される機能であり、当該フックハンドラ３１８に基づいて受信パケットに対するコネクショントラッキング処理を行なう。このコネクショントラッキング処理が実行されると、適宜、上記ステートテーブル３１９が参照される。

なお、特に示されていないが、フック情報テーブルにコネクショントラッキング処理が設定されているフック処理部３１４においても、上記フック処理部３１１と同様な構成をとっている。

また、フック情報テーブルにフィルタ処理が設定されているその他のフック処理部からも、上記ステートテーブル３１９及びフィルタルール３２０を参照できるように構成されている。

上記フック処理部３１１（同様にフック処理部３１４）において上記コネクショントラッキング処理が実行されると、例えば上記パケットｂｙパケット処理が行なわれる場合はタイマ更新を行なったら直ちに先の処理部に当該パケットを渡し、外部委託処理が行なわれる場合は、同図に示される処理依頼キュー（ip queue）３２２に当該パケットをキューイングして処理をサーバ３５０に委託して、当該フック処理部３１１（同様にフック処理部３１４）で次のパケットを受信する。この処理依頼キュー３１１は、カーネル部３０１の機能であり、カーネル部３０１からパケットを借りてきて当該パケットをユーザ空間で取り扱えるようになる仕組みを提供する。

なお、カーネル部３０１の処理依頼キュー３２２とデーモン３０２との通信は、同図のカーネルソケット（ＮＥＴＬＩＮＫ）３２３を介して行なわせる。
また上記にも述べたが、上記ステートテーブル３１９と対になるステートテーブルがサーバ３５０のカーネル部３５１に実装されている。本例では、互いのステートテーブルの同期を実現する仕組みとして、中継装置３００のカーネル部３０１及びサーバ３５０のカーネル部３５１に示されるソケット（ＣＴ−ＮＥＴＬＩＮＫ）３２４によって提供している。

一方、サーバ３５０のカーネル部３５１には、フックボトムハーフ３６１、サービス呼出モジュール３６２、及び、中継装置３００のカーネル部３５１に実装されているステートテーブル３１９と対となるステートテーブル３６３が実装されている。

上記フックボトムハーフ３６１は、ボトムハーフハンドラ（カーネル内で待ち行列に登録されたルーチンを処理する仕組み）を備え、上記サービス呼出モジュール３６２の呼びだしに応じて、該当するサービスモジュールをＣＰＵの空き時間に実行し、その処理結果をサービスモジュールに返す。

また、該実行結果に応じて上記ステートテーブル３６３を更新する。
上記サービス呼出モジュール３６２は、デーモン３５１との通信を同図に示されるカーネルソケット３６４を介して行なう。

なお、同図に示されるソケット（ＣＴ−ＮＥＴＬＩＮＫ）３６５は、先程も説明したが、サーバ３５０のカーネル３５１に実装されるステートテーブル３６３と中継装置３００のカーネル部３０１に実装されるステートテーブル３１９との同期をとるための仕組みである。

上記ステートテーブル３６３は、現在認識されているコネクションの状態を管理するテーブルであり、本例においては、今後コネクション作成が期待されるコネクションの情報を管理する不図示のｅｘｐｅｃｔテーブルと共に用いる。なお、ステートテーブル３１９は単独で用いる。

図４は、上記ステートテーブル３１９、３６３及び、該ステートテーブル３６３と共に用いる図３に不図示の上記ｅｘｐｅｃｔテーブルのテーブル例である。
図４（ａ）は、上記ステートテーブル３６３（または３１９）の一例である。

同図に示されるステートテーブル４００には、コネクションを識別するための「上りtuple」欄４０１に現在認識されているコネクションの識別記号「Ｔ１」が登録され、当該「Ｔ１」のコネクションの属性情報が、「ＳＲＣ ＩＰ」欄４０２、「ＳＲＣ ＰＯＲＴ」欄４０３、「ＤＳＴ ＩＰ」欄４０４、「ＤＳＴ ＰＯＲＴ」欄４０５、「プロトコル種別」欄４０６、「Ｌ３status」欄４０７、「Ｌ４status」欄４０８、「helper」欄４０９、「expecting」欄４１０、「master」欄４１１、及び「timeout」欄４１２に設定されている。

図４（ｂ）は、上記ｅｘｐｅｃｔテーブルの一例である。
同図に示されるｅｘｐｅｃｔテーブル４５０には、当該コネクションを期待した対象が「expecting」欄４５１に登録され、該期待したコネクションの情報が「ＳＲＣ ＩＰ」欄４５２、「ＳＲＣ ＰＯＲＴ」欄４５３、「ＤＳＴ ＩＰ」欄４５４、「ＤＳＴ ＰＯＲＴ」欄４５５、及び「プロトコル種別」欄４５６に設定される。

このｅｘｐｅｃｔテーブル４５０に設定された期待コネクションは、ステートテーブル４００に新たに設定される候補として利用される。
続いて、上記構成の下で行なわれる各処理の流れを図３を参照しながら以下に説明する。

図５は、図３の中継装置３００のカーネル部３０１に示されるパケットの処理経路の処理フローである。以下の説明において図３と対応する個所には、図３の符号を用いて説明する。

ＩＦ１からパケットを受信すると、先ず最初にフック処理部３１１が当該パケットに対し、フック情報テーブル３１７に登録してある処理を順じ実行する（Ｓ５００）。本例ではフック情報テーブル＃１（図３のフック情報テーブル３１７）」にコネクショントラッキング処理が登録されているので、フック処理部３１１は、不図示のフックハンドラ（図３のフックハンドラ３１８）によりコネクショントラッキング処理を実行する。

このコネクショントラッキング処理では、例えば受信パケットの状態や、その受信パケットに対応するセッションの状態に応じて、パケットｂｙパケット処理や外部委託処理が行なわれる。そして、上記パケットｂｙパケット処理や外部委託処理が終了すると続く処理部に送られ、次の受信パケットに対して上記コネクショントラッキング処理を行なう。特に上記外部委託処理が実行された場合は、当該パケットを一時的に処理依頼キュー３２２に渡し、サーバ３５０にその処理を依頼できるので、その間、当該フック処理部３１１は次のパケットを受信して処理を実行できる。よって、続くパケットが外部委託処理を要するものであれば、当該パケットを上記処理依頼キュー３２２に更に保持させることができるので、続く受信パケットの中継処理を円滑に行なえる。なお、外部委託処理が反映されたパケットは、当該外部委託処理の結果が廃棄でなければ当該フック処理部３１１において、フック情報テーブル＃１に登録された残りの処理が実行される。

続いて当該パケットに対する処理はルーティング処理部３１６−１に引き継がれ、該ルーティング処理部３１６−１はルーティングテーブルを検索し（Ｓ５０２）、当該パケットが自局宛てのパケットであるか否かを判定する（Ｓ５０４）。

当該パケットが自局宛てであった場合、当該パケットに対する処理はフック処理部３１２に引き継がれ、該フック処理部３１２は当該パケットに対し、フック情報テーブル３１７に登録してある処理を順じ実行する（Ｓ５０６）。本例では、該フック処理部３１２は、フック情報テーブル＃２に登録されているフィルタ処理を順じ実行する。そして最終的に、許諾されたパケットのみをアプリケーションで受信する（Ｓ５０８）。

一方、ステップＳ５０４で当該パケットが自局宛てでないと判定された場合、当該パケットに対する処理はフック処理部３１３に引き継がれ、該フック処理部３１３は当該パケットに対し、フック情報テーブル３１７に登録してある処理を順じ実行する（Ｓ５１０）。本例では、該フック処理部３１３は、フック情報テーブル＃５に登録されているフィルタ処理を順じ実行する。そして更に、当該パケットに対する処理はフック処理部３１５に引き継がれ、該フック処理部３１５は当該パケットに対し、フック情報テーブル３１７に登録してある処理を順じ実行する（Ｓ５１２）。本例では、該フック処理部３１５は、フック情報テーブル＃４に登録されているフィルタ処理を順じ実行する。そして最終的に、許諾されたパケットのみをＩＦ２へ送信する（Ｓ５１４）。

また、アプリケーションからパケットが送信されると、先ず最初にフック処理部３１４が、当該パケットに対し、フック情報テーブルに登録してある処理を順じ実行する。本例では、フック処理部３１４は、フック情報テーブル＃３に登録されているコネクショントラッキング処理を順じ実行する（Ｓ５１６）。なお、当該コネクショントラッキング処理についてはフック処理部３１１と同等の処理を行なうものであるため、ここでの詳しい説明は省略する。

続いてルーティング処理部３１６−２においてルーティング処理が実行され（Ｓ５１８）、更に、当該パケットに対する処理はフック処理部３１５に引き継がれ、該フック処理部３１５は当該パケットに対し、フック情報テーブル３１７に登録してある処理を順じ実行する（Ｓ５１２）。本例では、該フック処理部３１５は、フック情報テーブル＃４に登録されているフィルタ処理を順じ実行する。そして最終的に、許諾されたパケットのみをＩＦ２へ送信する（Ｓ５１４）。

図６は、シグナリングシーケンスの一例である。
当該シグナリングシーケンスは、サーバ３５０で提供しているサービス処理を中継装置３００側から利用可能なように設定する処理である。

先ず、サーバ３５０でサービス起動コマンド３５９の受付処理を行なう（ＳＳ６００）。
続いて、上記受付処理に基づいてカーネル３５１のサービス呼出モジュール３６２を起動する（ＳＳ６０２）。

更に続いて、カーネル３５１のフックボトムハーフ３６１で提供するサービスモジュールを起動する（ＳＳ６０４）。この処理では、外部サービス処理用としてサービスモジュールをカーネル部３５１に組み込む。

そして、サービスとトンネル番号とを対応付けてから、払い出しを行ない（ＳＳ６０６）、当該サービスの開始を通知するサービス開始通知を中継装置３００に送信する（ＳＳ６０８）。

中継装置３００では、サーバ３５０から上記サービス開始通知を受信すると当該外部サービス処理に対するサービス情報（例えば、外部サービス処理の識別子／当該外部サービス処理が適用されるパケットの種類（例えは送信元アドレスや送信先アドレスなど）／当該外部サービス処理を中継装置３００から委託するサーバ３５０のＩＰアドレスやトンネル番号など）を振分表３０９に登録する（ＳＦ６００）。

更に、例えば外部委託処理の実行の有無を上記フックハンドラ３１８で切り替え設定できるようにしている場合には、該当のパケットを処理依頼キュー３２２に転送するように上記フックハンドラ３１８を設定する（ＳＦ６０２）。

そして、中継装置３５０は、上記サービス開始通知の受け付けをした旨をサービス開始応答としてサーバ３５０に返信する（ＳＦ６０４）。
サーバ３５０では、中継装置３００から上記サービス開始応答を受信すると、当該外部サービス処理の登録結果をコマンドラインに表示する（ＳＳ６１０）。

図７は、上記シグナリングシーケンスにおいてサーバ３５０と中継装置３００間で取り交わされるメッセージの例である。
図７（ａ）はメッセージフォーマットであり、図７（ｂ）は上記サービス開始通知のメッセージ内容の例であり、図７（ｃ）は上記サービス開始応答のメッセージ内容の例である。

図７（ａ）のメッセージフォーマット７００は、「共通ヘッダ」７０１に、各メッセージの送信元機器のＩＰアドレスを格納する「送信元ＩＰアドレス」の欄７０２と、各メッセージの送信先機器のＩＰアドレスを格納する「送信先ＩＰアドレス」の欄７０３と、各メッセージの種別を格納する「種別」の欄７０４と、メッセージ長を格納する「メッセージ長」の欄７０５が構成されている。また、「メッセージ固有部」の欄７０６に、サービスの開始や停止を示す情報を格納する「詳細コード」７０７と、サーバ３５０から中継装置３００に提供する外部サービスの識別情報を格納する「サービスＩＤ」の欄７０８と、サーバ３５０から提供される外部サービスに対する中継装置３００の受け入れ結果を示す情報を格納する「処理結果」７０９の欄が構成されている。

図７（ｂ）に示されるように、サービス開始通知のメッセージ７１０には、上記メッセージフォーマット７００に従って以下の内容を格納する。
上記「送信元ＩＰアドレス」の欄７０２に、当該サービス開始通知メッセージ７１０の送信元機器である「サーバ３５０のＩＰアドレス」を格納し、上記「送信先ＩＰアドレス」の欄７０３に、当該サービス開始通知メッセージ７１０の送信先機器である「中継装置３００のＩＰアドレス」を格納し、上記「種別」の欄７０４に、サービス開始通知を知らせる情報を格納し、上記「メッセージ長」の欄７０５にメッセージ長を格納する。また更に、上記「詳細コード」７０７の欄に、サービスの開始や停止を示す情報を格納し、上記「サービスＩＤ」の欄７０８に、サーバ３５０から中継装置３００に提供する外部サービスの識別情報（外部サービスの識別子や当該外部サービスを適用するパケットの種類）を格納する。なお、上記「処理結果」７０９の欄はサービス開始通知においては未使用である。

図７（ｃ）に示されるように、サービス開始応答のメッセージ７２０には、上記メッセージフォーマット７００に従って以下の内容を格納する。
上記「送信元ＩＰアドレス」の欄７０２に、当該サービス応答通知メッセージ７２０を送信する送信元機器である「中継装置３００のＩＰアドレス」を格納し、上記「送信先ＩＰアドレス」の欄７０３に、当該サービス開始通知メッセージ７１０の送信先機器である「サーバ３５０のＩＰアドレス」を格納し、上記「種別」の欄７０４に、サービス開始の応答を示す情報を格納し、上記「メッセージ長」の欄７０５にメッセージ長を格納する。また更に、上記「詳細コード」７０７の欄に、サービスの開始や停止を示す情報を格納し、上記「サービスＩＤ」の欄７０８に、中継装置３００で利用するサーバ３５０の外部サービスの識別情報を格納し、上記「処理結果」７０９の欄に正常に処理されたかどうかを示す情報を格納する。

図８は、中継装置３００のフック処理部３１１（またはフック処理部３１４）におけるコネクショントラッキング処理の実行時に外部委託処理を行なった場合の、中継装置３００とサーバ３５０におけるパケット処理シーケンスである。

先ず、中継装置３００のフック処理部３１１（またはフック処理部３１４）でパケットを受信する（Ｓ８００）。
続いて、上記フック処理部３１１（またはフック処理部３１４）でのコネクショントラッキング処理の実行により、当該パケットが外部委託処理を行なうべきパケットであるか否かチェックし（Ｓ８０２）、更に、サービス対象ＩＦから受信したパケットであるか否かチェックする（Ｓ８０４）。

何れもＹＥＳである場合、当該パケットを処理依頼キュー３２２に渡し、処理依頼キュー３２２からプロキシスレッド３０５に当該パケットが引き渡される。プロキシスレッド３０５では当該パケットにおいて外部サービス処理に必要な情報（部分パケット情報）を抽出し、当該部分パケット情報及び、受信表３０８及び振分表３０９に登録された情報を基に、処理依頼メッセージを作成する（Ｓ８０６）。この際、送信先となるサーバ３５０のＩＰアドレスが共に同じである場合は、複数の処理依頼をまとめて一つの処理依頼メッセージに格納することもできる。

そして、上記処理依頼メッセージをサーバ３５０へ送信する（Ｓ８０８）。
サーバ３５０では、中継装置３００から送信された上記処理依頼メッセージをプロキシスレッド３５５で受け取ると、当該処理依頼メッセージによって指定されている処理に該当するサービスモジュールをサービス呼出モジュール３６２を介してフックボトムハーフ３６１から呼び出し、例えばＣＰＵの空き時間などを利用して処理を実行させる（Ｓ８１０）。このフックボトムハーフ３６１における処理は、他の処理を優先的に実行させて、それらの処理の空き時間などにフックボトムハーフに登録されるサービスモジュールを実行させる。

続いて、フックボトムハーフ３６１における当該サービスモジュールの処理結果を上記サービス呼出モジュール３６２を介してプロキシスレッド３５５に渡し、その処理結果がステートテーブルを更新するものであればステートテーブル３６３を更新する（Ｓ８１２）。

そして、プロキシスレッド３５５では、当該処理結果及び、送信表３５８及び受信表３５９に登録された情報を基に、処理応答メッセージを作成し、該処理応答メッセージの処理依頼を行なった中継装置３００へ送信する（Ｓ８１４）。この送信により、中継装置３００の処理依頼キュー３２２では、当該処理結果に応じて当該パケットが破棄されたり、当該処理結果が当該パケットに反映されて、元のフック処理部３１１（またはフック処理部３１４）に当該反映後のパケットが返されたりする。

更に、ステートテーブル３６３の更新が行なわれた場合は、当該更新情報を含むテーブル同期メッセージがサーバ３５０で作成され（Ｓ８１６）、該テーブル同期メッセージが中継装置３００へ送信される（８１８）。

中継装置３００は、上記テーブル同期メッセージをサーバ３５０から受け取ると、中継装置３００のステートテーブル３１９に当該更新情報を反映し（Ｓ８２０）、テーブル同期応答メッセージをサーバ３５０に返す（Ｓ８２２）。こうして、互いのステートテーブルの同期をとることができる。

そして、中継装置３００は、パケット中継処理を行なう（Ｓ８２４）。
図９及び図１０に、上記各種のメッセージの例を示す。
図９（ａ）は、上記処理依頼メッセージの例である。

図６のメッセージフォーマットと比較すると、本処理依頼メッセージ９００は、「種別」９０１の欄に処理依頼メッセージを示す情報が格納され、「シーケンス番号」の欄９０２に本処理依頼のシーケンス番号が格納され、「ＭＡＲＫ値」の欄９０３にサービス呼出元識別子が格納される。そして、一つの処理依頼メッセージに対し処理依頼を複数まとめて格納させることができる。

図９（ｂ）は、上記処理応答メッセージの例である。
図６のメッセージフォーマットと比較すると、本処理応答メッセージ９５０は、「種別」９５１の欄に処理応答メッセージを示す情報が格納され、「シーケンス番号」の欄９５２に本処理依頼のシーケンス番号が格納され、「ＭＡＲＫ値」の欄９５３にサービス呼出元識別子が格納される。そして、これまた一つの処理応答メッセージに対し処理応答を複数まとめて格納させることができる。

図１０（ａ）は、上記テーブル同期メッセージの例である。
本テーブル同期メッセージ１０００は、「種別」の欄１００１にテーブル同期メッセージを示す情報が格納され、「サービスＩＤ」の欄１００２に、同期するテーブルを認識するために使用する対象サービスの識別子が格納され、「メッセージタイプ」の欄１００３に更新や削除等のメッセージタイプが格納される。そして、実際の更新情報が「オプション属性」の欄１００４に格納される。

図１０（ｂ）は、上記テーブル同期応答メッセージの例である。
本テーブル同期メッセージ１０５０は、「種別」の欄１０５１にテーブル同期応答メッセージを示す情報が格納され、「サービスＩＤ」の欄１０５２に、同期するテーブルを認識するために使用する対象サービスの識別子が格納され、「処理結果」の欄１０５３に更新の結果（正常や異常など）が格納される。

図１１は、中継装置３５０のフックハンドラ３１８によって実行されるコネクショントラッキング処理の一例である。
フック処理部３１１（またはフック処理部３１４）でパケットを受信し、フック情報テーブル３１７に指定されたコネクショントラッキング処理が呼び出されると、フックハンドラ３１８により以下の処理が実行される。

先ず、当該パケットがフラグメントパケットであるか否かパケットヘッダから判定される（Ｓ１１００）。
当該パケットがフラグメントパケットであると判定された場合、仮想サービス処理部が呼び出され、該仮想サービス処理部に当該パケットに対する処理が引き継がれる（Ｓ１１０２）。上記仮想サービス処理部に対する当該パケット処理の引き継ぎは、当該パケットが処理依頼キュー３２２に渡される事によって行なわれる。

ステップＳ１１００において、当該パケットがフラグメントパケットでないと判定された場合、続いて当該パケットの状態を見るために、先ず、パケットヘッダの「送信元ＩＰアドレス（ＳＲＣ ＩＰ）」、「送信元ポート番号（ＳＲＣ ＰＯＲＴ）」、「送信先ＩＰアドレス（ＤＳＴ ＩＰ）」、及び「送信先ポート番号（ＤＳＴ ＰＯＲＴ）」をキーにステートテーブル３１９が検索される（Ｓ１１０４）。

そして、当該パケットが中継装置３００内で処理できるパケットであるか否かが、当該パケット及び上記ステートテーブル３１９の検索によりヒットした属性情報を基に判定される（Ｓ１１０６）。

本例では、Ｌ３コネクションの状態が「ＩＰＳ＿ＡＳＳＵＲＥＤ」であり、Ｌ４コネクションの状態が「ｅＥＳ」であり、且つＴＣＰ（Transmission Control Protocol）フラグがＳＹＮ／ＦＩＮ／ＲＳＴの何れかでない場合を、中継装置内で処理可能なパケットとする判定基準にしている。よって、これからコネクションを確立しようとするパケット（ＴＣＰフラグがＳＹＮであるパケット）やコネクションを切るパケット（ＴＣＰフラグがＦＩＮであるパケット）などは上記判定基準を満たさないので、このような場合は、仮想サービス処理部が呼び出され、該仮想サービス処理部に当該パケットに対する処理が引き継がれる（Ｓ１１０８）。

一方、上記判定基準を満たすパケットであった場合は、ステートテーブル３１９のセッションをタイマリフレッシュ（タイムアウト値の更新）する（Ｓ１１１０）。
そして当該コネクショントラッキング処理の呼出元へ処理が戻され（Ｓ１１１２）、フック情報テーブルに続く処理があれば当該パケットに対してその処理が実行される。

なお、上記仮想サービス処理部に対して処理が引き継がれた場合は、次のパケットがステップＳ１１００から実行される。
図１２は、上記コネクショントラッキング処理において処理を引き継いだサーバ３５０の、上記コネクショントラキング処理の引継ぎ処理例である。

中継装置３００から処理依頼メッセージを受信すると、先ず、デフラグメント処理の依頼であるか否かを判定する（Ｓ１２００）。
デフラグメント処理であると判定した場合は、上記処理依頼メッセージに格納されている必要情報（フラグメントパケットの全体とすることも可能であるが、本例ではパケット全体またはフラグメントパケットから取り出した必要情報が処理依頼メッセージに格納されているものとする）に対してデフラグメント処理を実行する（Ｓ１２０２）。

そして、当該必要情報に対するデフラグメント処理を終えると、当該必要情報に関する全ての情報のデフラグメント処理が完了したか否か判定し（Ｓ１２０４）、完了していないと判定した場合は、当該必要情報をサーバ３５０で保持し、当該必要情報をサーバ３５０で保持している旨を中継装置３００に対して送信する（Ｓ１２０６）。この処理により、サーバ３５０に保持されている上記必要情報に関連するフラグメントパケットが中継装置３００で受信されると、中継装置３５０から当該サーバ３５０に対してその受信パケットの必要情報が送信され、当該サーバ３５０ではこれらの必要情報に対してデフラグメント処理を繰り返し実行する。そして、例えば予め決めた所定時間内に当該デフラグメント処理対象の全ての必要情報が当該サーバ３５０で受信されることにより、デフラグメント処理が完了する。

そして、ステップＳ１２００においてデフラグメント処理ではないと判定した場合、またはステップＳ１２０４においてデフラグメントが完了したと判定した場合、当該必要情報の属するコネクションを、ステートテーブル３６３から検索する（Ｓ１２０８）。この検索は、当該必要情報に付加された「送信元ＩＰアドレス（ＳＲＣ ＩＰ）」、「送信元ポート番号（ＳＲＣ ＰＯＲＴ）」、「送信先ＩＰアドレス（ＤＳＴ ＩＰ）」、及び「送信先ポート番号（ＤＳＴ ＰＯＲＴ）」をキーに検索できる。

ここでステートテーブル３６３に当該コネクションが登録されているか否かを判定し（Ｓ１２１０）、ない場合は、当該必要情報に含まれているコネクションの属性情報をステートテーブル３６３に新規登録する（Ｓ１２１２）。

ステップＳ１２１０において登録があると判定された場合、或いはステップＳ１２１２においてステートテーブル３６３に新規登録されると、図４（ａ）のステートテーブル４００の「Ｌ３status」欄４０７の設定情報を参考に、当該必要情報のパケットのセッションにおけるイベント特性を決定する（Ｓ１２１４）。例えば、「当該パケットがオリジナル方向であるか」、「当該パケットがリプライ方向であるか」、「パケットが両方向に流れたか」、「期待しているコネクションであるか」、または「速くエクスパイアしてしまわないようにセットしたか」などの設定情報に応じてイベント特性を決め、当該イベント特性をテーブルに設定する。

そして、ＩＣＭＰ（Internet Control Message Protocol）の場合、上記イベント特性が「パケットがリプライ方向の場合に設定される（ＩＰ＿ＣＴ＿ＤＩＲ＿ＲＥＰＬＹ）」であれば当該パケットのコネクションの登録情報をステートテーブル３６３から削除し、それ以外のイベント特性の場合はステートテーブル３６３の当該コネクションのタイマを更新する（Ｓ１２１６）。

また、ＵＤＰ（User Datagram Protocol）の場合、上記「Ｌ３status」欄４０７の設定情報が「パケットが両方向に流れた状態（ＩＰＳ＿ＳＥＥＮ＿ＲＥＰＬＹ）」であれば「ＩＰＳ＿ＡＳＳＵＲＥＤ」を上記「Ｌ３status」欄４０７に設定し、更に当該コネクションのタイマをリフレッシュする。それ以外の場合はステートテーブル３６３の当該コネクションのタイマをリフレッシュする（Ｓ１２１８）。

また、ＴＣＰの場合、ＴＣＰプロトコルの状態遷移表を基に「Ｌ４status」の状態を更新する。
図１３は、「Ｌ４status」の状態変化を示す図である。

図１３（ａ）は、上記イベント特性がオリジナル方向の場合であり、図１３（ｂ）は、上記イベント特性がリプライ方向の場合である。
なお、図１３（ｃ）は、ＴＣＰプロトコルの状態と上図に用いられている略号の対応表である。

図１３（ａ）、図１３（ｂ）は、横軸に「Ｌ４status」の状態変化を示し、縦軸に受信パケットのＴＣＰヘッダのフラグの種類を示している。但し、noneは何れのフラグもセットされていない場合である。

例えば本受信パケットイベント特性がオリジナルであり且つフラグがｓｙｎである場合の「Ｌ４status」の以前の状態が「ｓｓＳ」であったならば、「ｓＥＳ」に更新される。
また、正しい手順の場合はＩＰＳ＿ＡＳＳＵＲＥＤを設定し、それ以外はタイマをリフレッシュする（Ｓ１２２０）。

続いて、ステートテーブル４００の「helper」欄４０９に上位アプリケーションを更新する処理方法が定義してあるか否か判定する（Ｓ１２２２）。
Ｙｅｓの場合、上位アプリケーションの状態を更新する（Ｓ１２２４）。図４（ａ）のステートテーブル４００の例では、「helper」欄４０９に「ftp conntrack」が設定されている。この処理は、ＦＴＰパケットのデータ部分を参照してＦＴＰのデータセッションを検出し、このデータセッションの情報をｅｘｐｅｃｔテーブル４５０に登録する。

ステップＳ１２２２の判定結果がＮｏの場合、またはステップＳ１２２４の処理を終えると、パケットが「reply」の場合はステートテーブル４００の「Ｌ３status」の欄４０７に「パケットが両方向に流れた状態（ＩＰＳ＿ＳＥＥＮ＿ＲＥＰＬＹ）」を示すフラグを追加する（Ｓ１２２６）。

そして、ステートテーブル４００を修正したか否か判定し（Ｓ１２２８）、修正していると判定された場合、当該修正個所の情報を含むテーブル同期メッセージを中継装置へ送信する（Ｓ１２３０）。また修正されていないと判定された場合、処理応答を中継装置へ送信する（Ｓ１２３２）。

以上説明してきた各処理はプログラムの形態で配布することもできる。
その場合、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ、ＤＶＤなどの記録媒体に上記プログラムやファイルを記録させて配布したり、或いは、公衆網等で用いられる伝送媒体を介して、そのプログラムやファイルの一部、若しくは全部を配信するようにしたりすることができる。この場合、それを受け取ったユーザは、ＣＤ−ＲＯＭ装置などの読み取り装置（入出力部の一部）を利用してフロッピー（登録商標）ディスクやＣＤ−ＲＯＭやＤＶＤなどの可搬型記録媒体から上記プログラムやファイルを外部記録部にコピーしたり、コンピュータの通信部を介してインターネットから上記プログラムやファイルを外部記録部にコピーしたりすることができる。そして、ＣＰＵで実行することにより、ユーザのコンピュータ上でも上述した機能を実現できる。

以上より、本発明の実施形態においては、サービス処理を行なうサーバの追加・変更等を行なう場合であってもその変更を容易に行なうことが可能になる。また、中継処理を高速に行なわせることが可能になる。

（付記１） 受信パケットを対象にサービス処理を行なって上記受信パケットを中継処理する、中継部とサーバからなる階層型パケット処理システムであって、上記中継部は、上記受信パケットを対象にサービス処理を行なう所定のサービス処理部を呼び出す呼出部と、上記呼出部の呼び出しにより、上記受信パケットにサービス処理を行なう第一のサービス処理部と、上記呼出部の呼び出しにより、上記受信パケットに仮想的にサービス処理を行なう第二のサービス処理部と、を有し、上記サーバは、上記第二のサービス処理部が上記呼出部から呼び出されると、上記第二のサービス処理部の代わりに上記受信パケットに対して任意のサービス処理を行なう外部サービス処理部を、有する、ことを特徴とする階層型パケット処理システム。

（付記２） 上記呼出部の呼び出しにより上記第二のサービス処理部が呼び出されると、上記受信パケットは処理依頼キューに一時的にキューイングされ、続く受信パケットに対するサービス処理が上記呼出部によって続いて呼び出されたサービス処理部によって行なわれる、ことを特徴とする付記１に記載の階層型パケット処理システム。

（付記３） 上記外部サービス処理部は、中継部における受信パケットの中継処理で使用されてるＣＰＵが空いた時間を利用して上記サービス処理を行なう、ことを特徴とする付記１または２に記載の階層型パケット処理システム。

（付記４） 受信パケットに対するコネクション状態を管理するコネクション状態管理部を更に有し、上記外部サービス処理部は、上記受信パケットの上位レイヤの状態を検出し、該上位レイヤの状態の検出結果を基に、上記コネクション状態管理部に管理される上記受信パケットの上記コネクション状態を更新し、上記中継部で受信された同一のコネクション受信パケットは、上記外部サービス処理部によって更新された上記コネクション状態管理部の上記コネクション状態に基づいてフィルタ処理される、ことを特徴とする付記１乃至３の何れか一つに記載の階層型パケット処理システム。

（付記５） 上記第一のサービス処理部で行なうサービス処理をパケットｂｙパケット処理に限定してハードウエアで構成し、上記外部サービス処理部で行なうサービス処理をソフトウエアで構成する、ことを特徴とする付記１乃至４の何れか一つに記載の階層型パケット処理システム。

（付記６） 上記仮想サービス処理部は、上記受信パケットに対するサービス処理を上記サーバへ振り分けるため、サービス処理を行なうサーバの情報及び該サーバが提供するサービス処理の識別情報とをパケットの種類に応じて管理するサービスリスト管理部を有し、上記サーバは、上記サービスリスト管理部に対し、自己サーバの情報及び該自己サーバが提供するサービス処理の識別子とを転送する転送部を有する、ことを特徴とする付記１乃至５の何れか一つに記載の階層型パケット処理システム。

（付記７） 上記中継部及び上記サーバはそれぞれ、受信パケットに対するコネクション状態を管理するコネクション状態管理部と、上記相互のコネクション状態管理部によって管理される上記コネクション状態を同期する同期部と、を有し、上記サーバは、上記外部サービス処理部に上記受信パケットの上位レイヤの状態を検出させ、該上位レイヤの状態の検出結果を基に、上記コネクション状態管理部に管理される上記受信パケットの上記コネクション状態を更新し、上記中継部で受信された同一のコネクション受信パケットは、上記サーバのコネクション状態管理部の更新後の上記コネクション状態を基に上記同期部によって同期されてなる、上記中継部のコネクション状態管理部の更新後の上記コネクション状態に基づいてフィルタ処理される、ことを特徴とする付記１乃至６の何れか一つに記載の階層型パケット処理システム。

（付記８） 上記中継部は外部サービス処理部で必要な情報のみを受信パケットから取り出して上記サーバへ送信する、ことを特徴とする付記１乃至７の何れか一つに記載の階層型パケット処理システム。

（付記９） 上記中継部は上記サーバへ受信パケットを送信する際に、送信先が同一のサーバである受信パケットを複数まとめて一度に送信する、ことを特徴とする付記１乃至８の何れか一つに記載の階層型パケット処理システム。

（付記１０） 受信パケットを対象にサービス処理を行なって上記受信パケットを中継処理する中継装置であって、上記受信パケットを対象にサービス処理を行なう所定のサービス処理部を呼び出す呼出部と、上記呼出部の呼び出しにより、上記受信パケットにサービス処理を行なう第一のサービス処理部と、上記呼出部の呼び出しにより、上記受信パケットに仮想的にサービス処理を行なう第二のサービス処理部と、上記受信パケットの上位レイヤの状態の検出に基づく情報を管理するコネクション状態管理部と、上記第二のサービス処理部が上記呼出部から呼び出されると、受信パケットの内の所定の情報を所定のサーバへ送信する送信部と、上記サーバから送信された情報を受信する受信部と、上記受信した結果を上記受信パケットまたは上記コネクション状態管理部で管理される上記情報に反映する反映部と、同一のコネクションパケットに対し、上記コネクション状態管理部で管理される上記反映後の情報に基づいてフィルタ処理するフィルタ処理部と、を有することを特徴とする中継装置。

（付記１１） 上記呼出部の呼び出しにより上記第二のサービス処理部が呼び出されると、上記受信パケットは処理依頼キューに一時的にキューイングされ、続く受信パケットに対するサービス処理が上記呼出部によって続いて呼び出されたサービス処理部によって行なわれる、ことを特徴とする付記１０に記載の中継装置。

（付記１２） 上記仮想サービス処理部は、上記受信パケットに対するサービス処理を上記サーバへ振り分けるため、サービス処理を行なうサーバの情報及び該サーバが提供するサービス処理の識別情報とをパケットの種類に応じて管理するサービスリスト管理部を有する、
ことを特徴とする付記１０または１１に記載の中継装置。

（付記１３） 中継装置で受信されたパケットの内の所定の情報を上記中継装置から受信するサーバであって、コネクションの状態を管理するコネクション状態管理部と、上記パケットの上位レイヤの状態を検出してサービス処理する上位レイヤ検出部と、上記上位レイヤ検出部によって検出された上記パケットの上位レイヤの状態を基に、上記コネクション状態管理部によって管理される上記パケットのコネクション状態を更新するコネクション状態更新部と、上記サービス処理の結果及び上記コネクション状態の更新情報を上記中継装置に送信する送信部と、を有することを特徴とするサーバ。

（付記１４） 上記サーバは、サービス処理を行なうサーバの情報及び該サーバが提供するサービス処理の識別情報とをパケットの種類に応じて管理する上記中継装置のサービスリスト管理部に対し、自己サーバの情報及び該自己サーバが提供するサービス処理の識別子とを転送する転送部を有する、ことを特徴とする付記１３に記載のサーバ。

（付記１５） 受信パケットを対象にサービス処理を行なって上記受信パケットを中継処理する、中継部とサーバからなる階層型パケット処理システムで行なわれる方法であって、上記中継部は、上記受信パケットを対象にサービス処理を行なう第一または第二のサービス処理部を呼び出し、上記呼び出しにより第一のサービス処理部が呼び出された場合は、上記受信パケットにサービス処理を行ない、上記呼び出しにより第二のサービス処理部が呼び出された場合は、上記受信パケットに仮想的にサービス処理を行ない、上記サーバは、上記第二のサービス処理部が上記呼び出されると、上記第二のサービス処理部の代わりに上記受信パケットに対して実際にサービス処理を行なう、ことを特徴とする方法。

（付記１６） 上記呼び出しにより上記第二のサービス処理部が呼び出されると、上記受信パケットは処理依頼キューに一時的にキューイングされ、続く受信パケットに対するサービス処理が、続いて呼び出されたサービス処理部によって行なわれる、ことを特徴とする付記１５に記載の方法。

（付記１７） 上記サーバは、上記中継部における受信パケットの中継処理で使用されてるＣＰＵが空いた時間を利用して上記サービス処理を行なう、ことを特徴とする付記１５または１６に記載の方法。

（付記１８） 受信パケットに対するコネクション状態をコネクション状態管理部で管理し、上記サーバは、上記受信パケットの上位レイヤの状態を検出し、該上位レイヤの状態の検出結果を基に、上記コネクション状態管理部に管理される上記受信パケットの上記コネクション状態を更新し、上記中継部は、同一のコネクション受信パケットを、上記更新された上記コネクション状態管理部の上記コネクション状態に基づいてフィルタ処理する、ことを特徴とする付記１５乃至１７の何れか一つに記載の方法。

（付記１９） 上記中継部は、上記受信パケットに対するサービス処理を上記サーバへ振り分けるため、サービス処理を行なうサーバの情報及び該サーバが提供するサービス処理の識別情報とをパケットの種類に応じてサービスリスト管理部で管理し、上記サーバは、上記サービスリスト管理部に対し、自己サーバの情報及び該自己サーバが提供するサービス処理の識別子とを転送する、ことを特徴とする付記１５乃至１８の何れか一つに記載の方法。

（付記２０） 受信パケットを対象にサービス処理を行なって上記受信パケットを中継処理する、中継部とサーバで実行可能なプログラムであって、上記中継部において、上記受信パケットを対象にサービス処理を行なう第一または第二のサービス処理部を呼び出す機能と、上記呼び出しにより第一のサービス処理部が呼び出された場合は、上記受信パケットにサービス処理を行なう機能と、上記呼び出しにより第二のサービス処理部が呼び出された場合は、上記受信パケットに仮想的にサービス処理を行なう機能と、を実現し、上記サーバにおいて、上記第二のサービス処理部が上記呼び出されると、上記第二のサービス処理部の代わりに上記受信パケットに対して実際にサービス処理を行なう機能と、を実現するプログラム。

（付記２１） 上記中継部において、上記呼び出しにより上記第二のサービス処理部が呼び出されると上記受信パケットを処理依頼キューに一時的にキューイングする機能と、同一のコネクション受信パケットに対するサービス処理を上記サービス処理部で行なう機能と、を実現する付記２０に記載のプログラム。

（付記２２） 上記サーバにおいて、上記中継部における受信パケットの中継処理で使用されてるＣＰＵが空いた時間を利用して上記サービス処理を行なう機能を実現する付記２０または２１に記載のプログラム。

（付記２３） 受信パケットに対するコネクション状態をコネクション状態管理部で管理する機能と、上記サーバにおいて、上記受信パケットの上位レイヤの状態を検出する機能と、該上位レイヤの状態の検出結果を基に、上記コネクション状態管理部に管理される上記受信パケットの上記コネクション状態を更新する機能と、上記中継部において、同一のコネクション受信パケットを、上記更新された上記コネクション状態管理部の上記コネクション状態に基づいてフィルタ処理する機能と、を実現する付記２０乃至２２の何れか一つに記載のプログラム。

（付記２４） 上記中継部において、上記受信パケットに対するサービス処理を上記サーバへ振り分けるため、サービス処理を行なうサーバの情報及び該サーバが提供するサービス処理の識別情報とをパケットの種類に応じてサービスリスト管理部で管理する機能と、上記サーバにおいて、上記サービスリスト管理部に対し、自己サーバの情報及び該自己サーバが提供するサービス処理の識別子とを転送する機能と、を実現する付記２０乃至２３の何れか一つに記載のプログラム。

（付記２５） 上記第一のサービス処理部はパケットｂｙパケットの処理を行ない、
上記外部サービス処理部は、ステートフル処理を行なう、
ことを特徴とする付記１乃至９の何れか一つに記載の階層型パケット処理システム。

（付記２６） 上記第一のサービス処理部はパケットｂｙパケットの処理を行なう、ことを特徴とする付記１０乃至１２の何れか一つに記載の中継装置。
（付記２７）上記サーバが上記第二のサービス処理部の代わりに上記受信パケットに対して実際に行なうサービス処理はステートフル処理である、ことを特徴とする付記１５乃至１９の何れか一つに記載の方法。

（付記２８）上記サーバが上記第二のサービス処理部の代わりに上記受信パケットに対して実際に行なうサービス処理はステートフル処理である、ことを特徴とする付記２０乃至２４の何れか一つに記載のプログラム。

本発明に適用される階層型パケット処理技術の原理を説明するための図である。 本発明に適用される階層型パケット処理技術の実装例である。 階層型パケット処理システムの機能ブロック図である。 ステートテーブル３１９、３６３及び、ｅｘｐｅｃｔテーブルのテーブル例である。 中継装置３００のカーネル部３０１に示されるパケット処理経路の処理フローである。 シグナリングシーケンスの一例である。 メッセージの例である。 中継装置３００とサーバ３５０におけるパケット処理シーケンスである。 メッセージの例を示す。 メッセージの例を示す。 中継装置３５０のフックハンドラ３１８によって実行されるコネクショントラッキング処理の一例である。 上記コネクショントラッキング処理において処理を引き継いだサーバ３５０の、上記コネクショントラキング処理の引継ぎ処理例である。 「Ｌ４status」の状態変化を示す図である。

符号の説明

１ 中継部
１−１ 呼出部
１−２ サービス処理部
１−３ 仮想サービス処理部
２ サーバ
２−１ 仮想呼出部
２−２ 外部サービス処理部

Claims (13)

1. 受信パケットを対象にサービス処理を行なって前記受信パケットを中継処理する、中継部と複数のサーバを備えた階層型パケット処理システムであって、
   前記中継部は、
   前記受信パケットを対象にサービス処理を行なう所定のサービス処理部を呼び出す呼出部と、
   前記呼出部の呼び出しにより、前記受信パケットにサービス処理を行なう第一のサービス処理部と、
   前記呼出部の呼び出しにより、前記受信パケットに仮想的にサービス処理を行なう第二のサービス処理部と、
   を有し、
   前記第二のサービス処理部は、前記受信パケットに対するサービス処理を前記複数のサーバの何れかへ振り分けるため、サービス処理を行なうサーバの情報及び該サーバが提供するサービス処理の識別情報をパケットの種類に応じて管理するサービスリスト管理部を有し、
   前記サーバは、
   前記サービスリスト管理部に対し、自己サーバの情報及び該自己サーバが提供するサービス処理の識別情報を転送する転送部と、
   前記第二のサービス処理部が前記呼出部から呼び出されると、前記第二のサービス処理部の代わりに前記受信パケットに対して任意のサービス処理を行なう外部サービス処理部を、
   有する、
   ことを特徴とする階層型パケット処理システム。
2. 前記呼出部の呼び出しにより前記第二のサービス処理部が呼び出されると、前記受信パケットは処理依頼キューに一時的にキューイングされ、続く受信パケットに対するサービス処理が前記呼出部によって続いて呼び出されたサービス処理部によって行なわれる、ことを特徴とする請求項１に記載の階層型パケット処理システム。
3. 前記外部サービス処理部は、中継部における受信パケットの中継処理で使用されているＣＰＵが空いた時間を利用して前記サービス処理を行なう、ことを特徴とする請求項１または２に記載の階層型パケット処理システム。
4. 受信パケットに対するコネクション状態を管理するコネクション状態管理部を更に有し、
   前記外部サービス処理部は、前記受信パケットの上位レイヤの状態を検出し、該上位レイヤの状態の検出結果を基に、前記コネクション状態管理部に管理される前記受信パケットの前記コネクション状態を更新し、
   前記中継部で受信された同一のコネクションパケットは、前記外部サービス処理部によって更新された前記コネクション状態管理部の前記コネクション状態に基づいてフィルタ処理される、
   ことを特徴とする請求項１乃至３の何れか一つに記載の階層型パケット処理システム。
5. 受信パケットを対象にサービス処理を行なって前記受信パケットを中継処理する中継装置であって、
   前記中継装置は、
   前記受信パケットを対象にサービス処理を行なう所定のサービス処理部を呼び出す呼出部と、
   前記呼出部の呼び出しにより、前記受信パケットにサービス処理を行なう第一のサービス処理部と、
   前記呼出部の呼び出しにより、前記受信パケットに仮想的にサービス処理を行なう第二のサービス処理部とを有し、
   前記第二のサービス処理部は、前記受信パケットに対するサービス処理を複数のサーバの何れかへ振り分けるため、サービス処理を行なうサーバの情報及び該サーバが提供するサービス処理の識別情報をパケットの種類に応じて管理するサービスリスト管理部を有し、該サーバから転送される自己サーバの情報及び該自己サーバが提供するサービス処理の識別情報を受信し、前記第二のサービス処理部が前記呼出部から呼び出されると、該第二のサービス処理部の代わりに該サーバにより該受信パケットに対して任意のサービス処理が行なわれることを特徴とする中継装置。
6. 前記受信パケットの上位レイヤの状態の検出に基づく情報を管理するコネクション状態管理部と、
   前記第二のサービス処理部が前記呼出部から呼び出されると、受信パケットの内の所定の情報を所定のサーバへ送信する送信部と、
   前記サーバから送信された情報を受信する受信部と、
   前記受信した結果を前記受信パケットまたは前記コネクション状態管理部で管理される前記情報に反映する反映部と、
   同一のコネクションパケットに対し、前記コネクション状態管理部で管理される前記反映後の情報に基づいてフィルタ処理するフィルタ処理部と、
   をさらに有することを特徴とする請求項５に記載の中継装置。
7. 前記呼出部の呼び出しにより前記第二のサービス処理部が呼び出されると、前記受信パケットは処理依頼キューに一時的にキューイングされ、続く受信パケットに対するサービス処理が前記呼出部によって続いて呼び出されたサービス処理部によって行なわれる、ことを特徴とする請求項５または６に記載の中継装置。
8. 中継装置で受信されたパケットの内の所定の情報を前記中継装置から受信するサーバであって、
   受信パケットに対するサービス処理を複数のサーバの何れかへ振り分けるため、サービス処理を行なうサーバの情報及び該サーバが提供するサービス処理の識別情報をパケットの種類に応じて管理する前記中継装置のサービスリスト管理部に対して、自己サーバの情報及び該自己サーバが提供するサービス処理の識別情報を転送する転送部と、
   前記中継装置において前記受信パケットに仮想的にサービス処理を行なうサービス処理部が呼び出されると、該サービス処理部の代わりに該受信パケットに対して任意のサービス処理を行なう外部サービス処理部と、
   を有することを特徴とするサーバ。
9. コネクションの状態を管理するコネクション状態管理部と、
   前記パケットの上位レイヤの状態を検出してサービス処理する上位レイヤ検出部と、
   前記上位レイヤ検出部によって検出された前記パケットの上位レイヤの状態を基に、前記コネクション状態管理部によって管理される前記パケットのコネクション状態を更新するコネクション状態更新部と、
   前記サービス処理の結果及び前記コネクション状態の更新情報を前記中継装置に送信する送信部と、
   をさらに有することを特徴とする請求項８に記載のサーバ。
10. 受信パケットを対象にサービス処理を行なって前記受信パケットを中継処理する、中継部と複数のサーバを備えた階層型パケット処理システムで行なわれる方法であって、
    前記中継部は、
    前記受信パケットに対するサービス処理を前記複数のサーバの何れかへ振り分けるため、サービス処理を行なうサーバの情報及び該サーバが提供するサービス処理の識別情報をパケットの種類に応じて管理し、
    前記受信パケットを対象にサービス処理を行なう第一または第二のサービス処理部を呼び出し、
    前記呼び出しにより第一のサービス処理部が呼び出された場合は、前記受信パケットにサービス処理を行ない、
    前記呼び出しにより第二のサービス処理部が呼び出された場合は、前記受信パケットに仮想的にサービス処理を行ない、
    前記サーバは、
    前記中継部に対し、自己サーバの情報及び該自己サーバが提供するサービス処理の識別情報を転送し、
    前記第二のサービス処理部が前記呼び出されると、前記第二のサービス処理部の代わりに前記受信パケットに対して実際にサービス処理を行なう、
    ことを特徴とする方法。
11. 受信パケットに対するコネクション状態をコネクション状態管理部で管理し、
    前記サーバは、
    前記受信パケットの上位レイヤの状態を検出し、
    該上位レイヤの状態の検出結果を基に、前記コネクション状態管理部に管理される前記受信パケットの前記コネクション状態を更新し、
    前記中継部は、
    同一のコネクション受信パケットを、前記更新された前記コネクション状態管理部の前記コネクション状態に基づいてフィルタ処理する、
    ことを特徴とする請求項１０に記載の方法。
12. 受信パケットを対象にサービス処理を行なって前記受信パケットを中継処理する、中継部とサーバで実行可能なプログラムであって、
    前記中継部において、
    前記受信パケットに対するサービス処理を複数のサーバの何れかへ振り分けるため、サービス処理を行なうサーバの情報及び該サーバが提供するサービス処理の識別情報をパケットの種類に応じて管理する機能と、
    前記受信パケットを対象にサービス処理を行なう第一または第二のサービス処理部を呼び出す機能と、
    前記呼び出しにより第一のサービス処理部が呼び出された場合は、前記受信パケットにサービス処理を行なう機能と、
    前記呼び出しにより第二のサービス処理部が呼び出された場合は、前記受信パケットに仮想的にサービス処理を行なう機能と、
    を実現し、
    前記サーバにおいて、
    前記中継部に対し、自己サーバの情報及び該自己サーバが提供するサービス処理の識別情報を転送する機能と、
    前記第二のサービス処理部が前記呼び出されると、前記第二のサービス処理部の代わりに前記受信パケットに対して実際にサービス処理を行なう機能と、
    を実現するプログラム。
13. 受信パケットに対するコネクション状態をコネクション状態管理部で管理する機能と、
    前記サーバにおいて、
    前記受信パケットの上位レイヤの状態を検出する機能と、
    該上位レイヤの状態の検出結果を基に、前記コネクション状態管理部に管理される前記受信パケットの前記コネクション状態を更新する機能と、
    前記中継部において、
    同一のコネクション受信パケットを、前記更新された前記コネクション状態管理部の前記コネクション状態に基づいてフィルタ処理する機能と、
    を実現する請求項１２に記載のプログラム。

Images