JP4648182B2 - パケット中継システム - Google Patents

Description

本発明は、パケット中継システムに関し、特にパケットのフィルタ処理を行ってパケット中継通信を行うパケット中継システムに関する。

近年、ブロードバンドネットワークの普及や無線技術の進歩に伴って、映像や音楽などの様々なアプリケーションが利用できるようになり、ネットワーク運用の重要性はますます増加している。この反面、情報通信ネットワークは、絶えず不正アクセスなどの攻撃にさらされており、ネットワークセキュリティの向上が求められている。

通常、ネットワークを不正アクセスから守る機構としては、フィルタリング機能が一般に用いられている。これは、ネットワーク上を送られてきたパケットを検査して、通過させるかどうかを判断し、不正なパケットを見つけた場合には廃棄することでセキュリティを確保する仕組みである。また、フィルタリングを行うことで、不要なパケットが中継されなくなるので、トラフィックの軽減を図ることも可能になる。

パケット中継装置（ルータなど）にフィルタ設定を行う場合、例えば、プロトコル毎のフィルタ設定（ＨＴＴＰ（Hypertext Transfer Protocol）のパケットのみ許可するなど）、パケットの受信ポートや送信元端末のアドレスなどを条件としたフィルタ設定などを行って、レイヤ２〜４の情報を用いてパケット単位でのフィルタ処理が行われる。

パケット中継装置は、通常、固定容量のフィルタテーブルを有し、フィルタテーブル上に設定されたフィルタ・ルールのパラメータ情報と、パケットヘッダ情報とのマッチングによりフィルタ処理を実施する。

図２２はフィルタテーブルを持つルータを示す図である。フィルタ処理の簡単な例を示している。ルータ１００は、フィルタテーブル１１０を有する。フィルタテーブル１１０には、受信ポート、送信元ＭＡＣ（Media Access Control）アドレス、フィルタ結果の項目がある。

ここで、ルータ１００は、端末５から送信されたパケットをポートＰ１１で受信したとすると、この場合は、フィルタテーブル１１０からフィルタ結果がpermitと設定されているので、所定の宛先へパケットを中継送信する。また、パケットをポートＰ１２で受信した場合は、フィルタテーブル１１０からフィルタ結果がdenyと設定されているので、ルータ１００でこのパケットは廃棄される。

従来のパケットフィルタ技術としては、ルータ内の複数のネットワークインタフェースがそれぞれ分散してフィルタ処理とルーティング処理を行う技術が提案されている（例えば、特許文献１）。
特開平６−９７９６５号公報（段落番号〔０００８〕〜〔００１２〕，第１図）

ネットワーク上に配置されたルータでは、上述のようなフィルタテーブル１１０を使ってフィルタ処理を行うが、近年のネットワークの巨大化・複雑化に伴い、設定したいフィルタのルールやエントリ数は増加してきているため、装置のテーブル容量が不足するケースが増えつつある。

テーブル容量不足の対策としては、単純にはメモリ増設があるが、これは追加設備コストを招くことになる。また、別の対策としては、テーブルリソースに空きがある別ルータにフィルタ設定を行い、その別ルータにパケットを転送して、フィルタ処理を代行させる手法が考えられる。

図２３はフィルタ処理を別ルータに依頼してパケット中継を行う場合の図である。ルータ１００で端末６へパケット中継する際に、ルータ１００でフィルタ処理を実行できない場合、ルータ１００は、パケット転送経路上のルータ１０１にフィルタ処理を依頼する。そして、ルータ１０１において、フィルタ結果が通過可能であると判断されると、ルータ１０１から最終宛先である端末６までパケットを送信する。

しかし、この方法では、フィルタの依頼先ルータ１０１が、最終宛先端末６までの経路上にあるルータに限定されるので、フィルタ処理の依頼可否がネットワーク・トポロジの転送経路によって制限を受けてしまうといった問題があった（ルータ１０１が依頼元ルータ１００に近接していても、ルータ１０１と端末６がネットワーク上接続していなければ、ルータ１０１にフィルタ処理を依頼できない）。

また、ルータ１０１にフィルタ処理を依頼して、フィルタ結果が中継可能と判断されたならば、一旦依頼元ルータ１００へパケットを返信して、元の依頼元ルータ１００から最終宛先である端末６までパケットを送信するようにすることも考えられる。

しかし、従来のパケット中継ネットワークにおいては、フィルタ処理を代行するルータ１０１では、依頼元ルータ１００の固有情報によるフィルタができなかった。すなわち、パケットのフィルタ処理では、フィルタのキーとして、フィルタ設定対象の装置上の固有情報であるパケットの受信元／送信先のポート番号などが必要であるが、レイヤ２、３の機能にはこれら装置固有情報を他ルータへ転送する機能がないため、従来のパケット中継方式では、依頼元ノード固有情報によるフィルタができなかった。

また、従来のパケット中継ネットワークでは、フィルタ処理代行側のルータ１０１から依頼元ルータ１００へパケットの折り返しができないといった問題があった。すなわち、フィルタ処理を他ルータに依頼する際には、受信パケットヘッダを書き換えずにルータ１０１に転送できる必要があるが、レイヤ２、３の機能には、パケットの経路上にないルータ宛にパケットを転送する機能はない。

仮に、強制的に転送及びフィルタ依頼ができたとしても、その場合、ルータ１０１は、受信パケットのＭＡＣ−ＤＡが自局宛でないため、レイヤ２中継を行い、受信ポートに折り返すことになる。

通常、レイヤ２中継処理フローでは、受信ポート＝送信ポートの場合、パケットLoop防止を目的としたDynamic Filtering機能によりパケット廃棄がなされてしまうため、ルータ１００においてもDynamic Filteringが働き、結局、依頼元ルータ１００への折り返しができないことになる。

一方、上記の従来技術（特開平６−９７９６５号公報）は、ルータ内のフィルタリングテーブルによって、フィルタ処理を行っているが、テーブル容量が不足して、フィルタ処理を該当ルータで実行不可能になった場合の対策については何ら考慮されてはいない。

本発明はこのような点に鑑みてなされたものであり、自ノードでフィルタ処理ができない場合に、他ノードでのフィルタ処理を実行可能にしてパケット転送を行うことで、パケット中継の通信品質の向上を図ったパケット中継システムを提供することを目的とする。

上記課題を解決するために、パケットの中継処理を行うパケット中継システムが提供される。パケット中継システムは、受信パケットのフィルタ処理を他の中継装置へ代行させる依頼パケットを送信する依頼パスの識別子と、該受信パケットのフィルタ処理の条件とが対応付けて記憶された記憶部と、受信パケットのフィルタ処理を前記他の中継装置へ代行させる依頼パケットを送信する依頼パスを構築し、前記他の中継装置で該フィルタ処理が代行された後の返信パケットを受信する返信パスを構築するパス構築部と、受信パケットについて、前記他の中継装置へフィルタ処理を代行させる依頼が必要か否かを判別するフィルタ状態判別部と、判別により、依頼が必要であれば、受信パケットに前記依頼パスの識別子を挿入して依頼パケットを生成するフィルタ処理依頼部と、前記依頼パスを介して、前記他の中継装置に前記依頼パケットを送信する依頼元送信部と、を備える中継装置と、前記依頼パスを介して、前記中継装置から前記依頼パケットを受信する受信部と、受信した前記依頼パケットに挿入された前記依頼パスの識別子に対応するフィルタ処理の条件が中継許可か否かを判別するフィルタ代行処理部と、前記フィルタ処理の条件が中継許可の場合、前記依頼パケットから前記依頼パスの識別子を削除し、前記返信パスの識別子を挿入して返信パケットを生成するフィルタ返信部と、前記返信パスを介して、前記中継装置に前記返信パケットを送信する代行側送信部と、を備える他の中継装置とを備える。

パスをあらかじめ構築して、パスの識別子をフィルタ代行処理のキーにし、他の中継装置にフィルタ処理を依頼して、パケット中継を行うことにより、誤認識のないフィルタ代行処理が可能になる。

以下、本発明の実施の形態を図面を参照して説明する。図１はパケット中継システムの原理図である。パケット中継システム１は、依頼元パケット中継装置１ａと代行側パケット中継装置１ｂを有し、パケットのフィルタ処理を行ってネットワーク上でパケットの中継通信を行うシステムである。

なお、説明の都合上、依頼元パケット中継装置１ａと代行側パケット中継装置１ｂとをそれぞれ別々に示しているが、実際にはネットワーク上の１つのノード（ルータなど）が、依頼元パケット中継装置１ａと代行側パケット中継装置１ｂの両方の機能を有しているものであってもよい。

依頼元パケット中継装置１ａは、パス構築部１１、フィルタ状態依頼元判別部１４ａ、フィルタ処理依頼部１６ａ、依頼元送信部１２ａ、パケット更新部１２−２、ポートデコード部１９ａから構成される。

パス構築部１１は、受信パケットのフィルタ処理を他装置へ依頼して代行させる際に、代行候補へフィルタ処理を代行させるパケットを送信するための依頼パスＰ１をあらかじめ構築し、かつ代行候補でフィルタ処理が代行された後のパケットを受信するための返信パスＱ１をあらかじめ構築する。

フィルタ状態依頼元判別部１４ａは、受信パケットに対して、他装置へフィルタ処理を代行させるための依頼要、不要、または代行済のいずれかを判別する。このとき、依頼要であれば、代行装置（代行側パケット中継装置１ｂ）へパケットを送信する際の依頼側宛先ポートと、依頼パスＰ１の識別子（ｐ１とする）とを取得する。

フィルタ処理依頼部１６ａは、フィルタ処理対象のパケットに依頼パス識別子ｐ１を挿入して、フィルタ処理依頼パケットを生成する。依頼元送信部１２ａは、依頼側宛先ポートから代行装置へ向けて、フィルタ処理依頼パケットの送信処理を行う。

パケット更新部１２−２は、受信パケットがフィルタ状態依頼元判別部１４ａによってフィルタ処理が代行済と判別された場合は、パケットに挿入されている返信パス識別子（ｑ１とする）を削除し、ヘッダ情報を更新して通常のパケット中継を行う。

代行側パケット中継装置１ｂは、フィルタ状態代行側判別部１４ｂ、代行側フィルタテーブルＴ７−２、フィルタ代行処理部１７ｂ、フィルタ返信部１８ｂ、代行側送信部１２ｂから構成される。

フィルタ状態代行側判別部１４ｂは、依頼パス識別子ｐ１が挿入されたフィルタ処理代行パケットを受信した場合に、フィルタ処理の代行要、不要を判別する。このとき、代行要であれば、依頼元パケット中継装置１ａへパケットを送信する際の代行側宛先ポートと、返信パス識別子（ｑ１とする）とを取得する。

代行側フィルタテーブルＴ７−２は、受信パケットのフィルタ処理の条件（フィルタ・ルール）が設定される。フィルタ代行処理部１７ｂは、フィルタ処理の代行を行う場合、依頼パス識別子ｐ１をキーにして、代行側フィルタテーブルＴ７−２を検索し、フィルタ処理依頼パケットが中継許可か廃棄かを判別する。

フィルタ返信部１８ｂは、中継許可の場合、フィルタ処理依頼パケットから依頼パス識別子ｐ１を削除して、返信パス識別子ｑ１を挿入してフィルタ処理代行パケットを生成する。代行側送信部１２ｂは、代行側宛先ポートから依頼元パケット中継装置１ａへ向けて、フィルタ処理代行パケットの折り返し送信処理を行う。

次に依頼元パケット中継装置１ａと代行側パケット中継装置１ｂの機能を有するパケット中継装置の構成について説明する。図２はパケット中継装置の構成を示す図である。
パケット中継装置１０は、ネットワークに配置されるルータなどのノードであって、テーブル管理部Ｔ、パス構築部１１、パケット受信部１２−１、宛先決定部１３、フィルタ状態判別部１４、フィルタ処理部１５ａ、フィルタ処理依頼部１６ａ、フィルタ代行処理部１７ｂ、フィルタ返信部１８ｂ、ポートデコード部１９ａ、パケット更新部１２−２、パケット送信部１２−３から構成される。なお、図１と同じ構成要素には同一符号を付けて説明は省略する。

テーブル管理部Ｔは、図１に示した代行側フィルタテーブルＴ７−２を含み、また、代行側フィルタテーブルＴ７−２以外にも、フィルタ処理やパケット中継処理に必要な各種のテーブルを保存管理する（保存管理される具体的なテーブルは図５〜図１０に示す）。パケット受信部１２−１は、パケットの受信処理を行う。宛先決定部１３は、受信パケットの次ノードへ中継するための宛先を決定する（レイヤ２またはレイヤ３の宛先決定処理を基本に行うが、ＴＣＰやＵＤＰのポート番号に応じて宛先を決める形態であってもよい）。

フィルタ状態判別部１４は、図１に示したフィルタ状態依頼元判別部１４ａとフィルタ状態代行側判別部１４ｂを含む。自装置がフィルタ処理を周辺装置に依頼する側になった場合は、フィルタ状態依頼元判別部１４ａの機能が動作し、自装置がフィルタ処理を代行する側になった場合は、フィルタ状態代行側判別部１４ｂの機能が動作する。

ポートデコード部１９ａは、代行フィルタ処理後に返信されてきたパケットが、元々どのポートで受信したものであったのかを知るために、返信用パス識別子にもとづいて、受信ポート番号をデコードする。パケット送信部１２−３は、図１に示した依頼元送信部１２ａと代行側送信部１２ｂを含み、パケットの送信処理を行う。

なお、パケット更新部１２−２においては、パケットの中継パターンがマルチキャストであれば、パケットの複製を行った後に、レイヤ３中継情報に関するヘッダ更新を行い、レイヤ２中継情報に関しては、宛先ポートと受信ポートとが一致する場合は、そのパケットは廃棄する処理を行う（このような処理を行うフィルタリングを以降Dynamic Filteringと呼ぶ）。

ここで、パケット中継装置１０は、パス構築部１１によって、事前に依頼パスＰ１及び返信パスＱ１を構築しておく。その後、パケットを受信すると、宛先を決定し、フィルタ状態判別部１４によって、該当パケットに関する以下に示す（ａ）〜（ｄ）の処理を実行する。

（ａ）他ノードへのフィルタ処理の依頼が不要な場合：
パケット中継装置１０は、通常のフィルタ処理を行った上で、フィルタ結果がpermit（中継許可）であれば、ヘッダ情報の更新処理を行ってパケット送信し、フィルタ結果がdeny（中継禁止）であればパケットを廃棄する。

（ｂ）他ノードへのフィルタ処理の依頼が必要な場合：
パケット中継装置１０は、フィルタ処理依頼部１６ａの動作によって、依頼先ノード宛に依頼パス経由でパケットを送信する。ただしこの場合、宛先決定部１３で求めた宛先情報を、フィルタ状態判別部１４で求めた依頼先情報（依頼側宛先ポート及び依頼パス識別子）で上書きして送信する。

（ｃ）フィルタ処理の代行を行う場合：
パケット中継装置１０は、フィルタ代行処理部１７ｂの動作によって、パケット中の各種ヘッダ及びパケット中に埋め込まれた依頼パス識別子を使ってパケットフィルタ処理を行う。

そして、フィルタ結果がpermit（中継許可）であれば、フィルタ返信部１８ｂにより、依頼元ノード宛に返信パス経由でパケットを送信する。ただしこの場合、宛先決定部１３で求めた宛先情報を、フィルタ状態判別部１４で求めた返信先情報（代行側宛先ポート及び返信パス識別子）で上書きして送信する。

また、フィルタ結果がdeny（中継禁止）であれば、パケットを廃棄する（フィルタ代行処理した結果、不正パケットであると認識した場合は、依頼元へわざわざ返信せずに、代行装置側で廃棄する）。

（ｄ）他ノードでフィルタ代行処理されたパケットを受信した場合：
パケット中継装置１０は、ポートデコード部１９ａにより依頼時の受信ポート情報をデコードした上で、マルチキャスト中継の場合は、パケット更新部１２−２によりマルチキャスト時のパケット複製、レイヤ３中継時のヘッダ更新、レイヤ２中継時のDynamic Filteringなどを行い、宛先決定部１３が導出した宛先にもとづきパケットを送信する。

次にパケット中継システム１を適用したネットワーク構成の一例を説明する。図３はネットワーク構成を示す図である。ネットワーク２は、ノードＲ１〜Ｒ５と、ユーザＶＬＡＮ（Virtual Local Area Network）１〜５と、サーバ２１、２２とから構成される。

構成機器の接続関係は、端末ｔ１〜ｔ３と端末ｔ４〜ｔ６は、ユーザＶＬＡＮ１に含まれ、端末ｔ１〜ｔ３は、ノードＲ１のポート番号Ｐ１ａ−１のポート（以下、ポートＰ１ａ−１と記す）と接続し、端末ｔ４〜ｔ６は、ノードＲ１のポートＰ１ａ−２と接続する。

端末ｔ７、ｔ８と端末ｔ９は、ユーザＶＬＡＮ２に含まれ、端末ｔ７、ｔ８は、ノードＲ１のポートＰ１ｂ−１と接続し、端末ｔ９は、ノードＲ１のポートＰ１ｂ−２と接続する。端末ｔ１０は、ユーザＶＬＡＮ４に含まれ、端末ｔ１０は、ノードＲ２のポートＰ２ａと接続する。

ユーザＶＬＡＮ３は、ノードＲ１のポートＰ１ｄと接続し、また、ノードＲ３、Ｒ４と接続する。ユーザＶＬＡＮ５は、ノードＲ２のポートＰ２ｄと接続し、また、ノードＲ５と接続する。サーバ２１は、ノードＲ３と接続し、サーバ２２は、ノードＲ５と接続する。ノードＲ１のポートＰ１ｃとノードＲ２のポートＰ２ｃが接続する。なお、ユーザＶＬＡＮ１〜５のＶＬＡＮ−ＩＤはそれぞれ、ＶＬＡＮ−ＩＤ＝１〜５である。

一方、ノードＲ１〜Ｒ５はそれぞれ、パケット中継装置１０の機能を有しており、またこの例では、フィルタ処理の依頼元をノードＲ１とし、フィルタ処理を代行するのがノードＲ２とする。

ノードＲ１のパス構築部１１は、事前に、ノードＲ１のポートＰ１ｃとノードＲ２のポートＰ２ｃをつなぐパスに依頼パス（依頼ＶＬＡＮ）を設定し、また、そのパスに返信パス（返信ＶＬＡＮ）を設定する（依頼パス及び返信パスとして、独立なＶＬＡＮを構築したが、依頼用と返信用で同じパスを共用してもよい）。

また、依頼ＶＬＡＮのＶＬＡＮ−ＩＤはｐ１、返信ＶＬＡＮのＶＬＡＮ−ＩＤはｑ１とし、以下、依頼ＶＬＡＮ−ｐ１、返信ＶＬＡＮ−ｑ１とも表記する（依頼ＶＬＡＮ及び返信ＶＬＡＮに付けるＩＤ値は、ネットワーク内に存在するＶＬＡＮのＩＤと重複しないＩＤ値を選択する）。

なお、ネットワーク２内のすべてのＶＬＡＮはIEEE802.1Qで規定するものであり、ユーザＶＬＡＮ１はタグ無しのポートＶＬＡＮ（ポート番号によってＶＬＡＮを識別）であり、依頼ＶＬＡＮ−ｐ１、返信ＶＬＡＮ−ｑ１はタグＶＬＡＮ（ＶＬＡＮ−ＩＤによってＶＬＡＮを識別）で運用するものとする。また、ネットワーク２に表記したポートＰ１ｂ−２等のパケット中継用のポートは、物理ポートでもよいし、リンクアグリゲーション等によりいくつかの物理ポートを束ねた論理ポートであってもよい。

ここで、ノードＲ１〜Ｒ５は、すべて同機能スペックを有し、また、ブルータ機能を有するものとする。すなわち、パケットの宛先ＭＡＣアドレスが自装置ＭＡＣアドレスと一致する場合はレイヤ３（ＩＰ：Internet Protocol）、不一致の場合はレイヤ２にてパケットの中継を行うものとする。ＭＡＣアドレスについては、ノードＲ１はＭＡＣ１、ノードＲ２はＭＡＣ２とする（ノードをブルータとしたのは一例であり、レイヤ２、３のどちらかの機能のみ有する装置であってもよい）。

次にフィルタ処理依頼元ノードのフィルタテーブルと、ネットワーク２で行うフィルタ処理の定義の想定について説明する。図４はフィルタテーブルを示す図である。フィルタテーブルＴ０−１は、ノードＲ１でフィルタ処理を依頼する前のフィルタ条件が示されたフィルタテーブルであり、受信ポート、受信ＶＬＡＮ−ＩＤ、送信元ＭＡＣ（アドレス）、フィルタ結果の項目から構成される。

ノードＲ１は、受信したパケットの受信ポート、受信ＶＬＡＮ−ＩＤ、送信元ＭＡＣをキーにして、フィルタテーブルＴ０−１を検索し、該当パケットが中継可能か廃棄かを判別する。

例えば、受信パケットの受信ポート＝Ｐ１ａ−１、受信ＶＬＡＮ−ＩＤ＝１、送信元ＭＡＣ＝端末ｔ１ならば、フィルタ結果＝permitなので、このパケットは中継する。また、受信パケットの受信ポート＝Ｐ１ａ−１、受信ＶＬＡＮ−ＩＤ＝１であっても、送信元ＭＡＣが端末ｔ１〜ｔ３のいずれでもない場合は、フィルタ結果＝denyなので、このパケットは廃棄する。

ここで、ノードＲ１の収容端末数が多く、フィルタ定義数がフィルタテーブルＴ０−１に収まりきらず（図では、ポートＰ１ｂ−２に関する受信パケットのフィルタ定義をするためのエントリがテーブル上足りないとする）、一方でノードＲ２の収容端末が少なく、ノードＲ２のフィルタテーブルには空きがあるとして、ノードＲ１のポートＰ１ｂ−２から受信したパケットを、ノードＲ２でフィルタ処理を代行させることを想定とする。

次にノードＲ１、Ｒ２それぞれのテーブル管理部Ｔで管理される各種のテーブルについて説明する。図５〜図７はテーブルを示す図である。図５〜図７では、ノードＲ１において、ネットワーク２でパケット中継及びフィルタ処理を行う際に必要なテーブルを示している。これらのテーブルは、ノードＲ１のテーブル管理部Ｔで保存管理される。

テーブルの概要を説明すると、ポートＶＬＡＮテーブルＴ１−１は、受信ポートと受信ＶＬＡＮ−ＩＤの対応関係を示すテーブルである（ＶＬＡＮタグが付加されていないパケットから、受信ＶＬＡＮを認識する際に参照するテーブルである）。

ＶＬＡＮメンバテーブルＴ２−１は、受信ＶＬＡＮ−ＩＤに対応する受信ポートグループを示すテーブルであり、各ＶＬＡＮに対してメンバとなるポート番号を括り付けるテーブルである。図では、ＶＬＡＮ−ｐ１とＶＬＡＮ−ｑ１をキーとするエントリが追加されている。

ルーティングテーブルＴ３−１は、宛先ＩＰアドレスに対する次ホップＩＰアドレスの関係を示すテーブルであり、ＡＲＰ（Address Resolution Protocol）テーブルＴ４−１は、ＩＰアドレスからＭＡＣアドレスを求めるためのテーブルである。また、学習テーブルＴ５−１は、受信ＶＬＡＮ−ＩＤと宛先ＭＡＣアドレスから宛先ポートを求めるテーブルである。

フィルタ状態判別テーブルＴ６−１は、受信パケットに関するフィルタ処理の依頼要、不要、代行要、代行済の判別、及び依頼先情報／返信先情報を格納するテーブルである。図では、ＶＬＡＮ−ｐ１、ＶＬＡＮ−ｑ１に関するエントリが追加されている。

フィルタテーブルＴ７−１は、フィルタ処理の定義が設定されたテーブルであり、ポートデコードテーブルＴ８−１は、フィルタ代行後、返信パケットを受信したノードＲ１が、受信ポートをＰ１ｂ−２としたDynamic Filteringを行うためのテーブルであり、返信時のＶＬＡＮ−ＩＤを元の受信ポートに対応付けるためのテーブルである。

図８〜図１０はテーブルを示す図である。図８〜図１０では、ノードＲ２において、ネットワーク２でパケット中継及びフィルタ処理を行う際に必要なテーブルを示している。これらのテーブルは、ノードＲ２のテーブル管理部Ｔで保存管理される。

ノードＲ２のフィルタテーブルＴ７−２（図１で示した代行側フィルタテーブルＴ７−２に該当）は、本来のノードＲ２で行うフィルタ定義の他に、ノードＲ１の代行用のフィルタ定義（代行用エントリ）が記載されている。

また、ノードＲ２がフィルタ処理の代行を行う場合、ノード固有情報（受信ポート番号など）でフィルタテーブルＴ７−２を検索するのではなく、依頼用ＶＬＡＮのＩＤをフィルタのキーとして検索するようにＶＬＡＮ−ｐ１を設定する。その他のテーブルの概略はノードＲ１と同じなので説明は省略する。なお、上記で示したノードＲ１、Ｒ２で管理される各種テーブルの設定値は、ネットワーク管理者からコマンド操作によって任意に与えることが可能である。

次にネットワーク２上でパス構築（ＶＬＡＮ設定）及びテーブル設定が完了した後のノードＲ１、Ｒ２の動作について説明する。図１１は中継ノードの処理フローを示す図である。（Ａ）〜（Ｃ）は、フィルタ処理を依頼・代行させるフローであり、（Ａ）はノードＲ１にてフィルタを依頼するフロー、（Ｂ）はノードＲ２にてフィルタを代行するフロー、（Ｃ）はノードＲ１にて代行パケットを本来の宛先に送信するフローである。また、（Ｄ）は、ノードＲ１にてフィルタ処理を行うフローである。

最初に、ノードＲ１内で通常のフィルタ処理を行う（Ｄ）の場合について、構成要素毎に動作を説明する。
いま、ノードＲ１が、ポートＰ１ａ−１から、下記の情報を持つＩＰパケットを受信したものとする。

・送信元ＭＡＣ＝端末ｔ１、宛先ＭＡＣ＝ＭＡＣ−１(ユニキャスト)、ＶＬＡＮタグ無し、宛先ＩＰ＝サーバ２１
（パケット受信部１２−１）
パケット受信部１２−１は、受信ＶＬＡＮ−ＩＤの決定と、中継レイヤの判別を行う。

・受信ＶＬＡＮ−ＩＤ決定：
受信パケットが、ＶＬＡＮタグ無しパケットであれば、ポートＶＬＡＮテーブルＴ１−１を参照して受信ＶＬＡＮを決定し、ＶＬＡＮタグありパケットであればパケット中のＶＬＡＮ−ＩＤを受信ＶＬＡＮと認識する。ここではポートＶＬＡＮテーブルＴ１−１のＰ１ａ−１エントリを参照した結果、受信ＶＬＡＮ−ＩＤ＝１と認識する。

また、ＶＬＡＮメンバテーブルＴ２−１を受信ＶＬＡＮ−ＩＤで参照し、受信ポートＰ１ａ−１が該当ＶＬＡＮ（ＶＬＡＮ−ＩＤ＝１）に所属するため、受信対象パケットとして認識する。もしもメンバ以外のポートから受信した場合はパケットを廃棄する。

・中継レイヤ判別：
パケットの宛先ＭＡＣアドレス及びＩＰアドレスを参照して、中継レイヤを以下の（１）、（２）のように識別する。

（１）宛先ＭＡＣアドレスがマルチキャストを示す場合
宛先ＭＡＣアドレス＝01:00:5e:0x:xx:xx：ＩＰマルチキャスト
宛先ＭＡＣアドレス≠01:00:5e:0x:xx:xx：レイヤ２マルチキャスト
01:00:5e:0x:xx:xxは、上位２５ビットが、１６進で固定値“01:00:5e:0”であることを示す。

（２）宛先ＭＡＣアドレスがマルチキャストでない場合
宛先ＭＡＣアドレス＝自装置ＭＡＣ時：ＩＰユニキャスト
宛先ＭＡＣアドレス≠自装置ＭＡＣ時：レイヤ２ユニキャスト
なお、宛先ＭＡＣアドレスがマルチキャストかどうかは、ＭＡＣアドレスの上位８ビット目＝１か否かで判別する。ここではノードＲ１の自装置ＭＡＣアドレス＝ＭＡＣ−１とし、ＩＰユニキャストの処理対象が認識されたものとする。

（宛先決定部１３）
レイヤ３の宛先決定部１３により宛先を決定する。ルーティングテーブルＴ３−１及びＡＲＰテーブルＴ４−１の検索の結果、次ホップノード＝ノードＲ３と認識し、各種送信パラメタ（宛先ポート、送信ＶＬＡＮ−ＩＤ、宛先ＭＡＣ）を獲得する。

（フィルタ状態判別部１４）
フィルタ状態判別テーブルＴ６−１の検索の結果、２番目のエントリにヒットし、フィルタ依頼不要と判別する。もしもフィルタ結果＝denyであれば、パケットを廃棄する。

（パケット更新部１２−２、パケット送信部１２−３）
パケット更新部１２−２は、ＩＰ／ＭＡＣのヘッダ更新を行い、パケット送信部１２−３は、ヘッダ更新されたＩＰパケットをノードＲ３宛に送信する。

次に第１の実施の形態として、ユニキャスト中継時にフィルタ処理の依頼及び代行を行う場合の図１１の（Ａ）〜（Ｃ）の動作について順に構成要素毎に説明する。
（Ａ）ノードＲ１にてフィルタを依頼するフロー：
いま、ノードＲ１が、ポートＰ１ｂ−２から、下記ＩＰパケットを受信したものとする。

・送信元ＭＡＣ＝端末ｔ９、宛先ＭＡＣ＝ＭＡＣ−１(ユニキャスト)、ＶＬＡＮタグ無し、宛先ＩＰ＝サーバ２１
（パケット受信部１２−１）
受信ＶＬＡＮ−ＩＤ＝２と認識し、ＶＬＡＮメンバテーブルＴ２−１を受信ＶＬＡＮ−ＩＤで参照し、受信ポートＰ１ｂ−２が該当ＶＬＡＮに所属するため、受信対象として認識する。また、ＩＰユニキャストの処理対象と認識する。

（宛先決定部１３）
レイヤ３の宛先決定部１３により宛先を決定する。ルーティングテーブルＴ３−１及びＡＲＰテーブルＴ４−１の検索の結果、次ホップノード＝ノードＲ３と認識し、各種送信パラメタ（宛先ポート、送信ＶＬＡＮ−ＩＤ、宛先ＭＡＣ）を獲得する。

（フィルタ状態判別部１４）
フィルタ状態判別テーブルＴ６−１の検索の結果、４番目のエントリにヒットし、フィルタ依頼要と判別する。また依頼先ノード情報（宛先ポート＝Ｐ１ｃ、送信ＶＬＡＮ−ＩＤ＝ＶＬＡＮ−ｐ１）とヘッダ操作情報（タグ挿入）を獲得する（Ｐ１ｃは依頼側宛先ポートであり、ＶＬＡＮ−ｐ１は依頼パス識別子である）。

この時点で宛先決定部１３により獲得した各種送信パラメタ（宛先ポート、送信ＶＬＡＮ−ＩＤ、宛先ＭＡＣ）の情報は消滅し、フィルタ状態判別テーブルＴ６−１の検索により獲得した上記の依頼先ノード情報で上書きされる。

（フィルタ処理依頼部１６ａ）
フィルタ状態判別テーブルＴ６−１から得られた情報にしたがい、パケットに、フィルタ依頼用パスの識別子を挿入する。具体的には、パケット中にＶＬＡＮ−ｐ１をＶＬＡＮタグとして挿入する（パケットフォーマットは後述する）。

（パケット送信部１２−３）
フィルタ状態判別テーブルＴ６−１から得られた情報にしたがい、宛先ポートＰ１ｃからパケットを送信する。

（Ｂ）ノードＲ２にてフィルタ処理を代行するフロー：
ノードＲ２は、ポートＰ２ｃから、下記ＩＰパケットを受信する。
・送信元ＭＡＣ＝端末ｔ９、宛先ＭＡＣ＝ＭＡＣ−１、ＶＬＡＮ−ＩＤ＝ＶＬＡＮ−ｐ１（タグＶＬＡＮ）、宛先ＩＰ＝サーバ２１
（パケット受信部１２−１）
受信ＶＬＡＮ−ＩＤ＝ＶＬＡＮ−ｐ１と認識する。ＶＬＡＮメンバテーブルＴ２−１を受信ＶＬＡＮ−ＩＤで参照し、受信ポートＰ２ｃが該当ＶＬＡＮに所属するため、受信対象として認識する。レイヤ２ユニキャスト処理対象と認識する。

（宛先決定部１３）
レイヤ２の宛先決定部１３により宛先を決定する。この場合、学習テーブルＴ５−２の検索を行うがミスヒットするので、さらにＶＬＡＮメンバテーブルＴ２−２を参照し、宛先ポート群情報を得る。

（フィルタ状態判別部１４）
フィルタ状態判別テーブルＴ６−２の検索の結果、１番目のエントリにヒットし、フィルタ代行要と判別する。フィルタ代行要と判別した時点で、宛先決定部１３で得られた宛先情報は全て無効化される。また返信先ノード情報（宛先ポート＝Ｐ２ｃ、送信ＶＬＡＮ−ＩＤ＝ＶＬＡＮ−ｑ１）とヘッダ操作情報（タグ置換）を獲得する（Ｐ２ｃは代行側宛先ポートであり、ＶＬＡＮ−ｑ１は返信パス識別子である）。

したがって、この時点で宛先決定部１３により獲得した各種送信パラメタ情報は消滅し、フィルタ状態判別テーブルＴ６−２の検索により獲得した返信先ノード情報で上書きされる。

（フィルタ代行処理部１７ｂ）
フィルタ代行処理部１７ｂは、フィルタのキーとして受信ポート番号（Ｐ２ｃ）は使用せず、依頼用ＶＬＡＮのＶＬＡＮ−ＩＤ（ＶＬＡＮ−ｐ１）を使って、フィルタテーブルＴ７−２の検索を行う。フィルタテーブルＴ７−２の検索により、３エントリ目にヒットするので、フィルタ結果＝permitと判断する。

ここで、もしも、ノードＲ２で受信した際のポート番号（Ｐ２ｃ）をフィルタ代行処理のキーにしてしまうと、受信ポート番号（Ｐ２ｃ）から受信したパケットのノードＲ２における本来のフィルタ処理ができなくなってしまう。したがって、ノードＲ２では、ノードＲ１のフィルタ処理の代行を行う場合は、フィルタのキーとして受信ポート番号（Ｐ２ｃ）は使用せず、ＶＬＡＮ−ＩＤ（ＶＬＡＮ−ｐ１）を使って、フィルタテーブルＴ７−２の検索を行うことで、ノードＲ１のフィルタ代行処理を実現可能とする。

（フィルタ返信部１８ｂ）
フィルタ返信部１８ｂは、フィルタ状態判別テーブルＴ６−２から得られた情報にしたがい、パケット中のＶＬＡＮタグ中のＶＬＡＮ−ＩＤを、ＶＬＡＮ−ｑ１で置換する（ＶＬＡＮ−ｐ１を削除してＶＬＡＮ−ｑ１を挿入する）。

（パケット送信部１２−３）
フィルタ状態判別テーブルＴ６−２から得られた情報にしたがい、宛先ポートＰ２ｃからパケットを送信する（通常のレイヤ２中継と異なり、Dynamic Filteringを行わない）。

（Ｃ）ノードＲ１にて代行パケットを本来の宛先に送信するフロー：
ノードＲ１は、ポートＰ１ｃから、下記ＩＰパケットを受信する。
・送信元ＭＡＣ＝端末ｔ９、宛先ＭＡＣ＝ＭＡＣ−１、ＶＬＡＮ−ＩＤ＝ＶＬＡＮ−ｑ１（タグＶＬＡＮ）、宛先ＩＰ＝サーバ２１
（パケット受信部１２−１）
受信ＶＬＡＮ−ＩＤ＝ＶＬＡＮ−ｑ１と認識する。ＶＬＡＮメンバテーブルを受信ＶＬＡＮ−ＩＤで参照し、受信ポートＰ１ｃが該当ＶＬＡＮに所属するため、受信対象として認識する。ＩＰユニキャスト処理対象と認識する。

（宛先決定部１３）
レイヤ３の宛先決定部１３により宛先を決定する。ルーティングテーブルＴ３−１及びＡＲＰテーブルＴ４−１の検索の結果、次ホップノード＝ノードＲ３と認識し、各種送信パラメタ（宛先ポート、送信ＶＬＡＮ−ＩＤ、宛先ＭＡＣ）を獲得する。

（フィルタ状態判別部１４）
フィルタ状態判別テーブルＴ６−１の検索の結果、１番目のエントリにヒットし、フィルタ代行済と判別する。また、ヘッダ操作情報（タグ削除）を獲得する。

（ポートデコード部１９ａ）
ポートデコードテーブルＴ８−１を返信用ＶＬＡＮ−ＩＤ値であるＶＬＡＮ−ｑ１により参照し、受信ポート番号Ｐ１ｂ−２を得る。

（パケット更新部１２−２、パケット送信部１２−３）
パケット更新部１２−２は、フィルタ状態判別テーブルＴ６−１から得られた情報にしたがい、パケット中のフィルタ返信用ＶＬＡＮタグ（ＶＬＡＮ−ｑ１）を削除した後、中継レイヤに応じたヘッダ更新を行い、パケット送信部１２−３によってパケットが送信される。

以上の動作によって、別ノードにおけるフィルタ処理後にパケット中継伝送を行うことが可能になる。また、依頼先ノード情報及び返信先ノード情報で上書きされたパケットの通信をノードＲ１、Ｒ２間で行うので、フィルタ処理の依頼・代行時には、Dynamic Filtering機能が働くことがなく、ノードＲ２からノードＲ１へ折り返し送信されても、フィルタ処理されたパケットの廃棄がノードＲ１で行われることはない。

なお、上記の動作内容をパケット中継装置の動作フローチャートとしてまとめた図を図１２、図１３に示す。図中の（Ａ）〜（Ｃ）は図１１の（Ａ）〜（Ｃ）に該当する。詳細は上述したので説明は省略する。

次にフィルタ処理依頼なしの場合とフィルタ処理依頼ありの場合とにおけるパケットの流れについて説明する。図１４はフィルタ処理依頼なしの場合のパケットの流れを示す図である。フィルタ処理依頼なしの場合、ノードＲ１からノードＲ３宛にパケットを送信する際は、パケットにはＭＡＣ＿ＤＡ（ＭＡＣ宛先アドレス）、ＭＡＣ＿ＳＡ（ＭＡＣ送信元アドレス）を含むヘッダ情報が挿入され、このパケットがノードＲ１→ノードＲ３へ流れる。

図１５はフィルタ処理依頼ありの場合のパケットの流れを示す図である。ノードＲ１からノードＲ２へフィルタ処理を依頼し、ノードＲ２から返信されたパケットをノードＲ３へ送信する場合を示している。

ノードＲ１からノードＲ２へフィルタ処理を依頼する際は、パケットにＶＬＡＮ−ＩＤ＝ＶＬＡＮ−ｐ１を挿入して送信する。ノードＲ２でフィルタ代行処理をしてノードＲ１へ返信する際は、パケットからＶＬＡＮ−ｐ１を削除してＶＬＡＮ−ｑ１を挿入して送信する。ノードＲ１からノードＲ３宛にパケットを送信する際は、ＶＬＡＮ−ｑ１を削除して、通常のＭＡＣ＿ＤＡ、ＭＡＣ＿ＳＡを含むヘッダ情報が挿入されたパケットを送信する。

次にパケットフォーマットについて説明する。図１６はパケットフォーマットを示す図である。元パケットは、ＦＣＳ（Frame Check Sequence）、Ｌ３データ、Ｆｒａｍｅ Ｔｙｐｅ、ＭＡＣ ＤＡ／ＳＡから構成される。

フィルタ処理の依頼時パケットは、Ｆｒａｍｅ ＴｙｐｅとＭＡＣ ＤＡ／ＳＡの間に４バイトのＶＬＡＮタグが挿入される。このＶＬＡＮタグには、ＶＬＡＮ−ｐ１のＶＬＡＮ−ＩＤが含まれる。

フィルタ処理代行後の返信時パケットは、Ｆｒａｍｅ ＴｙｐｅとＭＡＣ ＤＡ／ＳＡの間に４バイトのＶＬＡＮタグが挿入される。このＶＬＡＮタグには、ＶＬＡＮ−ｑ１のＶＬＡＮ−ＩＤが含まれる。

なお、ＶＬＡＮタグは、ＶＬＡＮ−ＩＤ（１２ビット）、ＣＦＩ（Canonical Format Indicator：１ビット）、Ｐｒｉｏｒｉｔｙ（３ビット）、ＴＰＩＤ（Ｔ０g protocol identifier：１６ビット）から構成される。

図１７はパケットフォーマットを示す図である。ノードＲ１において受信したパケットがすでにＶＬＡＮタグが挿入されている場合には、元のＶＬＡＮタグの手前に重ねる形で、フィルタ処理を代行させるためのＶＬＡＮタグを図に示すように挿入する（ＶＬＡＮタグが２段挿入された形になる）。

次に第２の実施の形態として、マルチキャスト中継時におけるフィルタ処理の依頼及び代行の動作について図１１の（Ａ）〜（Ｃ）の順に説明する。
（Ａ）ノードＲ１にてフィルタを依頼するフロー
いま、ノードＲ１が、ポートＰ１ｂ−２から、下記ＩＰパケットを受信したものとする。

送信元ＭＡＣ＝端末ｔ９、宛先ＭＡＣ＝01.00.5e.1.2.3、ＶＬＡＮタグ無し、送信元ＩＰ＝ＩＰ＿端末ｔ９、宛先ＩＰ＝235.1.2.3（ＩＰマルチキャスト）
（パケット受信部１２−１）
受信ＶＬＡＮ−ＩＤ＝２と認識する。ＶＬＡＮメンバテーブルＴ２−１を受信ＶＬＡＮ−ＩＤで参照し、受信ポートＰ１ｂ−２が該当ＶＬＡＮに所属するため、受信対象として認識する。宛先ＭＡＣアドレスから、ＩＰマルチキャスト処理対象と認識する。

（宛先決定部１３）
宛先決定部１３は、マルチキャスト用ルーティングテーブルを検索する。図１８はマルチキャスト用ルーティングテーブルを示す図である。マルチキャスト用ルーティングテーブルＴ９−１の検索の結果、宛先ポート＝Ｐ１ｃ、Ｐ１ｄ、Ｐ１ｂ−１、Ｐ１ｂ−２それぞれへの出力時の中継レイヤの情報を獲得する。また、レイヤ３中継時には送信ＶＬＡＮ−ＩＤも獲得する。なお、マルチキャスト用ルーティングテーブルＴ９−１もテーブル管理部Ｔで管理されるテーブルである。

（フィルタ状態判別部１４）
フィルタ依頼要と判別し、宛先決定部１３により獲得した各種送信パラメタ情報は消滅し、フィルタ状態判別テーブルＴ６−１の検索により獲得した依頼先ノード情報で上書きされる。

（フィルタ処理依頼部１６ａ、パケット送信部１２−３）
ＶＬＡＮ−ｐ１をＩＤとしたＶＬＡＮタグ付きパケットをノードＲ２に送信する。
（Ｂ）ノードＲ２にてフィルタ処理を代行するフロー
ノードＲ２は、ポートＰ２ｃから、下記ＩＰパケットを受信する。

送信元ＭＡＣ＝端末ｔ９、宛先ＭＡＣ＝01.00.5e.1.2.3、ＶＬＡＮ−ＩＤ＝ＶＬＡＮ−ｐ１（タグＶＬＡＮ）、送信元ＩＰ＝ＩＰ＿端末ｔ９、宛先ＩＰ＝235.1.2.3（ＩＰマルチキャスト）
（パケット受信部１２−１）
受信ＶＬＡＮ−ＩＤ＝ＶＬＡＮ−ｐ１と認識する。ＶＬＡＮメンバテーブルＴ２−２を受信ＶＬＡＮ−ＩＤで参照し、受信ポートＰ２ｃが該当ＶＬＡＮに所属するため、受信対象として認識する。宛先ＭＡＣアドレスから、ＩＰマルチキャスト処理対象と認識する。

（宛先決定部１３、フィルタ状態判別部１４、フィルタ代行処理部１７ｂ、フィルタ返信部１８ｂ、パケット送信部１２−３）
第１の実施の形態と同様に、フィルタ代行処理を行い、ノードＲ１にパケットを返信する。

（Ｃ）ノードＲ１にて代行パケットを本来の宛先に送信するフロー
ノードＲ１は、ポートＰ１ｃから、下記ＩＰパケットを受信する。
送信元ＭＡＣ＝端末ｔ９、宛先ＭＡＣ＝01.00.5e.1.2.3、ＶＬＡＮ−ＩＤ＝ＶＬＡＮ−ｑ１（タグＶＬＡＮ）、送信元ＩＰ＝ＩＰ＿端末ｔ９、宛先ＩＰ＝235.1.2.3（ＩＰマルチキャスト）
（パケット受信部１２−１）
受信ＶＬＡＮ−ＩＤ＝ＶＬＡＮ−ｑ１と認識する。ＶＬＡＮメンバテーブルＴ２−１を受信ＶＬＡＮ−ＩＤで参照し、受信ポートＰ１ｃが該当ＶＬＡＮに所属するため、受信対象として認識する。宛先ＭＡＣアドレスから、ＩＰマルチキャスト処理対象と認識する。

（宛先決定部１３）
マルチキャスト用ルーティングテーブルＴ９−１の検索の結果、宛先ポート＝Ｐ１ｃ、Ｐ１ｄ、Ｐ１ｂ−１、それぞれへの出力時の中継レイヤ、及びレイヤ３中継時には送信ＶＬＡＮ−ＩＤも獲得する。

（フィルタ状態判別部１４）
フィルタ状態判別テーブルＴ６−１の検索の結果、１番目のエントリにヒットし、フィルタ代行済と判別する。また、ヘッダ操作情報を獲得する。

（ポートデコード部１９ａ）
ポートデコードテーブルＴ８−１を返信用ＶＬＡＮ−ＩＤ値であるＶＬＡＮ−ｑ１により参照、受信ポート番号Ｐ１ｂ−２を得る。

（パケット更新部１２−２、パケット送信部１２−３）
パケット更新部１２−２は、まずフィルタ状態判別テーブルＴ６−１から得られた情報にしたがい、パケット中のフィルタ返信用ＶＬＡＮタグを削除する。以降の処理は、返信用ＶＬＡＮ−ＩＤ値から受信ポートをデコードする以外は、通常のパケット中継の更新処理と同じである。

すなわち、宛先ポートＰ１ｃ、Ｐ１ｄ、Ｐ１ｂ−１、Ｐ１ｂ−２へマルチキャストするためにパケットを複製した後、宛先決定部１３でレイヤ３中継と判別したＰ１ｃ、Ｐ１ｄ宛成分については、ＩＰ／ＭＡＣのヘッダ更新を行い、パケット送信部１２−３によりパケットを送信する。

また、レイヤ２中継と判別したＰ１ｂ−１、Ｐ１ｂ−２宛成分については、ポートデコード部１９ａで得られた受信ポートＰ１ｂ−２と送信ポートの比較を行い、結果が一致した場合はパケットを廃棄し、不一致時はパケット送信部１２−３によりパケットをそのまま送信する（Dynamic Filtering処理）。以上の動作により、別ノードへのフィルタ処理依頼・代行が可能になる。

次に第３の実施の形態として、フィルタのキーを受信ポート、送信ポート、送信元ＭＡＣとした際の動作について説明する（送信ポートをあらたなフィルタキーとして含めている）。なお、想定フローはマルチキャスト中継とする。また、マルチキャスト中継時のパケット複製は、第２の実施の形態では、折り返し後のノードＲ１で行っていたが、第３の実施の形態では折り返し前で行うこととする（パケット複製した後にノードＲ２へ送信してフィルタ処理を依頼する）。

（行いたいフィルタ定義の想定）
フィルタのキーは、（受信ポート、送信ポート、送信元ＭＡＣ）とする。図４に示したフィルタテーブルＴ０−１において、ネットワーク管理者は、ノードＲ１のエントリ不足を認識し、ノードＲ１において（受信ポート＝ポートＰ１ｂ−２、送信ポート＝ポートＰ１ｄ）のパケットに関し、ノードＲ２でパケットフィルタ処理を代行させるようなシステム構築を考えたものと想定する。

なお、図１９にはノードＲ１のフィルタ状態判別テーブルＴ６ａ−１、フィルタテーブルＴ７ａ−１を示し、図２０にはノードＲ２のフィルタ状態判別テーブルＴ６ａ−２、フィルタテーブルＴ７ａ−２を示す。テーブルは基本的には図５〜図１０と同じであり、差分のみ図１９、図２０に示してある。

（ネットワーク管理者による事前設定）
パス構築部１１による設定は、まず、ノードＲ１とノードＲ２の間に、（受信ポートＰ１ｂ−２、送信ポートＰ１ｄ、中継レイヤ＝レイヤ３）を対応付けたフィルタ依頼用ＶＬＡＮ及び返信用ＶＬＡＮを構築する。また、ＶＬＡＮメンバテーブルは、第２の実施の形態で使用したＶＬＡＮメンバテーブルＴ２−１、Ｔ２−２と同じものを使い、フィルタ状態判別テーブルＴ６ａ−１、Ｔ６ａ−２は、第２の実施の形態で使用したフィルタ状態判別テーブルＴ６−１、Ｔ６−２に対し、送信ポートが追加されたテーブルとなる。また、代行済み時に関する連想データには、受信ＶＬＡＮ−ＩＤ値に対応する宛先情報を、ヘッダ更新のレイヤ情報も格納する。

一方、ポートデコードテーブルは不要とする。ポートデコードテーブルが不要な理由は、第３の実施の形態では、マルチキャスト時のパケット複製及びDynamic Filteringを行うのが依頼先ノードＲ２への転送前であり、ノードＲ２からの返信後に受信ポートをデコードする必要がないためである。

次にノードＲ２のフィルタテーブルＴ７ａ−２に対し、フィルタ代行処理用の設定を行う。ここでは、本来ノード固有情報である受信ポート、送信ポートの代わりに、依頼用ＶＬＡＮ−ｐ１をフィルタのキーとして設定する。図中でＶＬＡＮ−ｐ１をキーとするエントリが上記コマンドにより追加されたエントリである。

次に運用時のパケット処理フローについて説明する。
（Ａ）ノードＲ１にてフィルタ処理を依頼するフロー
いま、ノードＲ１が、ポートＰ１ｂ−２から、下記ＩＰパケットを受信したものとする。

送信元ＭＡＣ＝端末ｔ９、宛先ＭＡＣ＝01.00.5e.1.2.3、ＶＬＡＮタグ無し、送信元ＩＰ＝ＩＰ＿端末ｔ９、宛先ＩＰ＝235.1.2.3（ＩＰマルチキャスト）
（パケット受信部１２−１）
受信ＶＬＡＮ−ＩＤ＝２と認識する。ＶＬＡＮメンバテーブルＴ２−１を受信ＶＬＡＮ−ＩＤで参照し、受信ポートＰ１ｂ−２が該当ＶＬＡＮに所属するため、受信対象として認識する。宛先ＭＡＣアドレスから、ＩＰマルチキャスト処理対象と認識する。

（宛先決定部１３）
マルチキャスト用ルーティングテーブルＴ９−１の検索の結果、宛先ポート＝Ｐ１ｃ、Ｐ１ｄ、Ｐ１ｂ−１、Ｐ１ｂ−２、それぞれへの出力時の中継レイヤ、及びレイヤ３中継時には送信ＶＬＡＮ−ＩＤの各情報を獲得する。

（フィルタ状態判別部１４）
宛先決定部１３で求まった各送信ポートと受信ポートの対によりフィルタ状態判別テーブルＴ６ａ−１を検索し、（受信ポート＝Ｐ１ｂ−２、送信ポート＝Ｐ１ｄ）についてフィルタ依頼要と判別される。

（パケット更新部１２−２）
ノードＲ２への転送に先立ち、パケットの複製及びDynamic Filtering処理を行う。その結果、Ｐ１ｃ、Ｐ１ｄ、Ｐ１ｂ−１宛のパケットが３つ生成される。

・Ｐ１ｃ、Ｐ１ｂ−１宛パケット：フィルタ、ヘッダ更新の後に送信される。
・Ｐ１ｄ宛パケット：フィルタ処理依頼部１６ａ及びパケット送信部１２−３での処理を実行する。

（フィルタ処理依頼部１６ａ、パケット送信部１２−３）
第２の実施の形態と同様に、ＶＬＡＮ−ｐ１をＩＤとしたＶＬＡＮタグ付きパケットをノードＲ２に送信する。

（Ｂ）ノードＲ２にてフィルタ処理を代行するフロー
ノードＲ２は、ポートＰ２ｃから、下記ＩＰパケットを受信する。
送信元ＭＡＣ＝端末ｔ９、宛先ＭＡＣ＝01.00.5e.1.2.3、ＶＬＡＮ−ＩＤ＝ＶＬＡＮ−ｐ１（タグＶＬＡＮ）、送信元ＩＰ＝ＩＰ＿端末ｔ９、宛先ＩＰ＝235.1.2.3（ＩＰマルチキャスト）
（パケット受信部１２−１）
受信ＶＬＡＮ−ＩＤ＝ＶＬＡＮ−ｐ１と認識する。ＶＬＡＮメンバテーブルＴ２−２を受信ＶＬＡＮ−ＩＤで参照し、受信ポートＰ２ｃが該当ＶＬＡＮに所属するため、受信対象として認識する。宛先ＭＡＣアドレスから、ＩＰマルチキャスト処理対象と認識する。

（宛先決定部１３、フィルタ状態判別部１４、フィルタ代行処理部１７ｂ、フィルタ返信部１８ｂ、パケット送信部１２−３）
第１の実施の形態と同様に、フィルタ代行処理を行い、ノードＲ１にパケットを返信する。

（Ｃ）ノードＲ１にて代行パケットを本来の宛先に送信するフロー
ノードＲ１は、ポートＰ１ｃから、下記ＩＰパケットを受信する。
送信元ＭＡＣ＝端末ｔ９、宛先ＭＡＣ＝01.00.5e.1.2.3、ＶＬＡＮ−ＩＤ＝ＶＬＡＮ−ｑ１（タグＶＬＡＮ）、送信元ＩＰ＝ＩＰ＿端末ｔ９、宛先ＩＰ＝235.1.2.3（ＩＰマルチキャスト）
（パケット受信部１２−１）
受信ＶＬＡＮ−ＩＤ＝ＶＬＡＮ−ｑ１と認識する。ＶＬＡＮメンバテーブルＴ２−１を受信ＶＬＡＮ−ＩＤで参照し、受信ポートＰ１ｃが該当ＶＬＡＮに所属するため、受信対象として認識する。宛先ＭＡＣアドレスから、ＩＰマルチキャスト処理対象と認識する。

（宛先決定部１３）
マルチキャスト用ルーティングテーブルＴ９−１の検索の結果、宛先ポート＝Ｐ１ｃ、Ｐ１ｄ、Ｐ１ｂ−１、それぞれへの出力時の中継レイヤ、及びレイヤ３中継時には送信ＶＬＡＮ−ＩＤの各情報を獲得する。

（フィルタ状態判別部１４）
フィルタ状態判別テーブルＴ６ａ−１の検索の結果、１番目のエントリにヒットし、フィルタ代行済と判別される。この時点で宛先決定部１３により獲得した各種送信パラメタ情報は消滅し、フィルタ状態判別テーブルＴ６ａ−１の検索により獲得した依頼先ノード情報で上書きされる。

また、ヘッダ操作情報を獲得する。フィルタ状態判別テーブルＴ６ａ−１から、このパケットは、フロー（Ａ）にて複製されたパケットのうち、ポートＰ１ｄ宛のレイヤ３パケットであること、及び送信ＶＬＡＮ−ＩＤ値も認識する。

（パケット更新部１２−２、パケット送信部１２−３）
パケット更新部１２−２は、まずフィルタ状態判別テーブルＴ６ａ−１から得られた情報にしたがい、パケット中のフィルタ返信用ＶＬＡＮタグを削除する。次に、フィルタ状態判別テーブルＴ６ａ−１がレイヤ３パケットであることを示しているので、ヘッダ更新を行った上で、パケット送信部１２−３は、パケットを送信する。以上の動作により、別ノードへのフィルタ依頼が可能となる。

次に第１〜第３の実施の形態における追加内容について以下の（１）〜（４）について説明する。
（１）パス構築部１１では、ＶＬＡＮタグを使って依頼パス及び返信パスを構築していたが、ＩＰトンネルのように、その他のトンネルプロトコルを使ったパスであってもよい。また、パスのＩＤ値は、既存のプロトコルヘッダに埋め込まず、独自ヘッダに埋め込む形でもよい。

図２１は独自ヘッダを有するパケットフォーマットを示す図である。元パケットをカプセル化して、独自ヘッダ、ＩＰヘッダ、ＭＡＣヘッダが付加されている。このように、フィルタ処理依頼元ノードとフィルタ処理代行側ノード間に確立するパスにレイヤ３以上のトンネルプロトコルを使うことにより、フィルタ処理依頼元ノードとフィルタ処理代行側ノード間に他ルータが存在しても本発明の適用が可能となり、適用対象のネットワーク形態を広めることができる（フィルタ処理依頼元ノードとフィルタ処理代行側ノード間に、ＶＬＡＮパスを確立する場合には、フィルタ処理依頼元ノードとフィルタ処理代行側ノードとの間には、他ルータなどのノードが存在しないことが必要であるが、トンネリングの場合には、他ルータなどのノードの存在が許容される）。

（２）フィルタ処理依頼部１６ａは、依頼パス識別子の他に、少なくともパケットの受信時間を含むログ情報も挿入してフィルタ処理依頼パケットを生成してもよい。同様に、フィルタ返信部１８ｂは、返信パス識別子の他に、少なくともフィルタ処理依頼パケットの受信時間を含むログ情報も挿入してフィルタ処理代行パケットを生成してもよい。時間情報が挿入されたヘッダフォーマットを図２１の独自ヘッダフォーマットパターン２に示す。このような時間情報が記されることで、ネットワーク管理に使用することが可能になる。

（３）フィルタ返信部１８ｂは、返信パス識別子の他に、フィルタ代行処理部１７ｂが代行側フィルタテーブルＴ７−２を検索した際にヒットしたエントリ番号も挿入してフィルタ処理代行パケットを生成してもよい。このようにすることで、代行側パケット中継装置でのフィルタ代行処理によってパケットが廃棄された場合、廃棄されたフィルタリング定義をネットワーク管理者が認識することが可能になる。

（４）第１〜第３の実施の形態において、ノードＲ１のフィルタエントリが不足し、ノードＲ２へフィルタ処理を依頼する場合、ノードＲ１のフィルタ状態依頼元判別部１４ａ及びテーブル管理部Ｔでは、一連のソフトウェア・プログラムによって、自律的にフィルタエントリの不足を察知し、テーブルが空いているノード及び使われてないパスの番号（ＶＬＡＮ−ＩＤ値など）を見つけて、各ノードのテーブル設定を行うものである（ネットワーク管理者によるマニュアル設定も可）。

（付記１） パケットの中継通信を行うパケット中継システムにおいて、
受信パケットのフィルタ処理を他装置へ依頼して代行させる際に、代行候補へフィルタ処理を代行させるパケットを送信するための依頼パスを構築し、かつ代行候補でフィルタ処理が代行された後のパケットを受信するための返信パスを構築するパス構築部と、受信パケットに対して、他装置へフィルタ処理を代行させるための依頼要、不要、または代行済のいずれかを判別し、依頼要であれば、代行装置へパケットを送信する際の依頼側宛先ポートと、前記依頼パスの識別子と、を取得するフィルタ状態依頼元判別部と、パケットに依頼パス識別子を挿入して、フィルタ処理依頼パケットを生成するフィルタ処理依頼部と、前記依頼側宛先ポートから代行装置へ向けて、前記フィルタ処理依頼パケットの送信処理を行う依頼元送信部と、フィルタ処理代行パケットを受信して、前記フィルタ処理代行パケットが前記フィルタ状態依頼元判別部によってフィルタ処理が代行済と判別された場合は、パケットに挿入されている返信パス識別子を削除し、ヘッダ情報を更新してパケット中継を行うパケット更新部と、から構成される依頼元パケット中継装置と、
前記依頼パス識別子が挿入された前記フィルタ処理依頼パケットを受信した場合に、フィルタ処理の代行要、不要を判別し、代行要であれば、前記依頼元パケット中継装置へパケットを送信する際の代行側宛先ポートと、前記返信パス識別子と、を取得するフィルタ状態代行側判別部と、受信パケットのフィルタ処理の条件が設定された代行側フィルタテーブルと、フィルタ処理の代行を行う場合、前記依頼パス識別子をキーにして、前記代行側フィルタテーブルを検索し、前記フィルタ処理依頼パケットが中継許可か廃棄かを判別するフィルタ代行処理部と、中継許可の場合、前記フィルタ処理依頼パケットから前記依頼パス識別子を削除して、前記返信パス識別子を挿入して前記フィルタ処理代行パケットを生成するフィルタ返信部と、前記代行側宛先ポートから前記依頼元パケット中継装置へ向けて、前記フィルタ処理代行パケットの折り返し送信処理を行う代行側送信部と、から構成される代行側パケット中継装置と、
を有することを特徴とするパケット中継システム。

（付記２） 前記依頼元パケット中継装置は、前記フィルタ処理代行パケットを受信した場合、前記返信パス識別子をデコードして、フィルタ処理依頼前の受信パケットの最初の受信ポート番号を求めるポートデコード部をさらに有することを特徴とする付記１記載のパケット中継システム。

（付記３） 前記パス構築部は、前記依頼パス及び前記返信パスとして、ＶＬＡＮによるパスまたはＩＰトンネルによるパスを構築することを特徴とする付記１記載のパケット中継システム。

（付記４） 前記フィルタ処理依頼部は、前記依頼パス識別子の他に、少なくともパケットの受信時間を含むログ情報を挿入して前記フィルタ処理依頼パケットを生成し、前記フィルタ返信部は、前記返信パス識別子の他に、少なくとも前記フィルタ処理依頼パケットの受信時間を含むログ情報を挿入して前記フィルタ処理代行パケットを生成することを特徴とする付記１記載のパケット中継システム。

（付記５） 前記代行側パケット中継装置でのフィルタ代行処理によってパケットが廃棄された場合、廃棄されたフィルタリング定義をネットワーク管理者が認識できるように、前記フィルタ返信部は、前記返信パス識別子の他に、前記フィルタ代行処理部が前記代行側フィルタテーブルを検索した際にヒットしたエントリ番号も挿入して前記フィルタ処理代行パケットを生成することを特徴とする付記１記載のパケット中継システム。

（付記６） パケットの中継通信を行うパケット中継装置において、
受信パケットのフィルタ処理を他装置へ依頼して代行させる際に、代行候補へフィルタ処理を代行させるパケットを送信するための依頼パスを構築し、かつ代行候補でフィルタ処理が代行された後のパケットを受信するための返信パスを構築するパス構築部と、
受信パケットに対して、他装置へフィルタ処理を代行させるための依頼要、不要、または代行済のいずれかを判別し、依頼要であれば、代行装置へパケットを送信する際の依頼側宛先ポートと、前記依頼パスの識別子と、を取得するフィルタ状態依頼元判別部と、
パケットに依頼パス識別子を挿入して、フィルタ処理依頼パケットを生成するフィルタ処理依頼部と、
前記依頼側宛先ポートから代行装置へ向けて、前記フィルタ処理依頼パケットの送信処理を行う依頼元送信部と、
前記依頼パス識別子が挿入された前記フィルタ処理依頼パケットを受信した場合に、フィルタ処理の代行要、不要を判別し、代行要であれば、前記依頼元パケット中継装置へパケットを送信する際の代行側宛先ポートと、返信パス識別子と、を取得するフィルタ状態代行側判別部と、
受信パケットのフィルタ処理の条件が設定された代行側フィルタテーブルと、
フィルタ処理の代行を行う場合、前記依頼パス識別子をキーにして、前記代行側フィルタテーブルを検索し、前記フィルタ処理依頼パケットが中継許可か廃棄かを判別するフィルタ代行処理部と、
中継許可の場合、前記フィルタ処理依頼パケットから前記依頼パス識別子を削除して、前記返信パス識別子を挿入してフィルタ処理代行パケットを生成するフィルタ返信部と、
前記代行側宛先ポートから前記依頼元パケット中継装置へ向けて、前記フィルタ処理代行パケットの折り返し送信処理を行う代行側送信部と、
前記フィルタ処理代行パケットを受信し、前記フィルタ処理代行パケットが前記フィルタ状態依頼元判別部によってフィルタ処理が代行済と判別された場合は、パケットに挿入されている前記返信パス識別子を削除し、ヘッダ情報を更新してパケット中継を行うパケット更新部と、
を有することを特徴とするパケット中継装置。

（付記７） 前記フィルタ処理代行パケットを受信した場合、前記返信パス識別子をデコードして、フィルタ処理依頼前の受信パケットの最初の受信ポート番号を求めるポートデコード部をさらに有することを特徴とする付記６記載のパケット中継装置。

（付記８） 前記パス構築部は、前記依頼パス及び前記返信パスとして、ＶＬＡＮによるパスまたはＩＰトンネルによるパスを構築することを特徴とする付記６記載のパケット中継装置。

（付記９） 前記フィルタ処理依頼部は、前記依頼パス識別子の他に、少なくともパケットの受信時間を含むログ情報も挿入して前記フィルタ処理依頼パケットを生成し、前記フィルタ返信部は、前記返信パス識別子の他に、少なくとも前記フィルタ処理依頼パケットの受信時間を含むログ情報も挿入して前記フィルタ処理代行パケットを生成することを特徴とする付記６記載のパケット中継装置。

（付記１０） フィルタ代行処理によってパケットが廃棄された場合、廃棄されたフィルタリング定義をネットワーク管理者が認識できるように、前記フィルタ返信部は、前記返信パス識別子の他に、前記フィルタ代行処理部が前記代行側フィルタテーブルを検索した際にヒットしたエントリ番号も挿入して前記フィルタ処理代行パケットを生成することを特徴とする付記６記載のパケット中継装置。

パケット中継システムの原理図である。 パケット中継装置の構成を示す図である。 ネットワーク構成を示す図である。 フィルタテーブルを示す図である。 テーブルを示す図である。 テーブルを示す図である。 テーブルを示す図である。 テーブルを示す図である。 テーブルを示す図である。 テーブルを示す図である。 中継ノードの処理フローを示す図である。 パケット中継装置の動作フローチャートを示す図である。 パケット中継装置の動作フローチャートを示す図である。 フィルタ処理依頼なしの場合のパケットの流れを示す図である。 フィルタ処理依頼ありの場合のパケットの流れを示す図である。 パケットフォーマットを示す図である。 パケットフォーマットを示す図である。 マルチキャスト用ルーティングテーブルを示す図である。 フィルタ状態判別テーブルとフィルタテーブルを示す図である。 フィルタ状態判別テーブルとフィルタテーブルを示す図である。 独自ヘッダを有するパケットフォーマットを示す図である。 フィルタテーブルを持つルータを示す図である。 フィルタ処理を別ルータに依頼してパケット中継を行う場合の図である。

符号の説明

１ パケット中継システム
１ａ 依頼元パケット中継装置
１１ パス構築部
１４ａ フィルタ状態依頼元判別部
１６ａ フィルタ処理依頼部
１２−２ パケット更新部
１２ａ 依頼元送信部
１ｂ 代行側パケット中継装置
１２ｂ 代行側送信部
１４ｂ フィルタ状態代行側判別部
１７ｂ フィルタ代行処理部
１８ｂ フィルタ返信部
Ｔ７−２ 代行側フィルタテーブル
Ｐ１ 依頼パス
Ｑ１ 返信パス
ｐ１ 依頼パス識別子
ｑ１ 返信パス識別子

Claims (9)

1. パケットの中継処理を行うパケット中継システムにおいて、
   受信パケットのフィルタ処理を他の中継装置へ代行させる依頼パケットを送信する依頼パスの識別子と、該受信パケットのフィルタ処理の条件とが対応付けて記憶された記憶部と、受信パケットのフィルタ処理を前記他の中継装置へ代行させる依頼パケットを送信する依頼パスを構築し、前記他の中継装置で該フィルタ処理が代行された後の返信パケットを受信する返信パスを構築するパス構築部と、受信パケットについて、前記他の中継装置へフィルタ処理を代行させる依頼が必要か否かを判別するフィルタ状態判別部と、判別により、依頼が必要であれば、受信パケットに前記依頼パスの識別子を挿入して依頼パケットを生成するフィルタ処理依頼部と、前記依頼パスを介して、前記他の中継装置に前記依頼パケットを送信する依頼元送信部と、を備える中継装置と、
   前記依頼パスを介して、前記中継装置から前記依頼パケットを受信する受信部と、受信した前記依頼パケットに挿入された前記依頼パスの識別子に対応するフィルタ処理の条件が中継許可か否かを判別するフィルタ代行処理部と、前記フィルタ処理の条件が中継許可の場合、前記依頼パケットから前記依頼パスの識別子を削除し、前記返信パスの識別子を挿入して返信パケットを生成するフィルタ返信部と、前記返信パスを介して、前記中継装置に前記返信パケットを送信する代行側送信部と、を備える他の中継装置と、
   を備えることを特徴とするパケット中継システム。
2. 前記中継装置は、前記返信パケットを受信した場合、前記返信パスの識別子をデコードして、フィルタ処理依頼前の受信パケットの最初の受信ポート番号を求めるポートデコード部をさらに有することを特徴とする請求項１記載のパケット中継システム。
3. 前記パス構築部は、前記依頼パス及び前記返信パスとして、ＶＬＡＮによるパスまたはＩＰトンネルによるパスを構築することを特徴とする請求項１記載のパケット中継システム。
4. 前記フィルタ処理依頼部は、前記依頼パスの識別子の他に、少なくともパケットの受信時間を含むログ情報を挿入して前記依頼パケットを生成し、前記フィルタ返信部は、前記返信パスの識別子の他に、少なくとも前記依頼パケットの受信時間を含むログ情報を挿入して前記返信パケットを生成することを特徴とする請求項１記載のパケット中継システム。
5. 前記他の中継装置でのフィルタ代行処理によってパケットが廃棄された場合、廃棄されたフィルタリング定義をネットワーク管理者が認識できるように、前記フィルタ返信部は、前記返信パスの識別子の他に、前記フィルタ代行処理部が、受信パケットのフィルタ処理の条件が設定されたフィルタテーブルを検索した際にヒットしたエントリ番号も挿入して前記返信パケットを生成することを特徴とする請求項１記載のパケット中継システム。
6. 前記フィルタ処理依頼部は、マルチキャストパケットの受信時には、パケットを複製し、複製したパケットに前記依頼パスの識別子を付けて、各パケットの送信ポート毎に前記他の中継装置へ処理依頼を行うことを特徴とする請求項１記載のパケット中継システム。
7. 受信パケットのフィルタ処理を他の中継装置へ代行させる中継装置において、
   受信パケットのフィルタ処理を前記他の中継装置へ代行させる依頼パケットを送信する依頼パスの識別子と、該受信パケットのフィルタ処理の条件とが対応付けて記憶された記憶部と、
   受信パケットのフィルタ処理を前記他の中継装置へ代行させる依頼パケットを送信する依頼パスを構築し、前記他の中継装置で該フィルタ処理が代行された後の返信パケットを受信する返信パスを構築するパス構築部と、
   受信パケットについて、前記他の中継装置へフィルタ処理を代行させる依頼が必要か否かを判別するフィルタ状態判別部と、
   判別により、依頼が必要であれば、受信パケットに前記依頼パスの識別子を挿入して依頼パケットを生成するフィルタ処理依頼部と、
   前記依頼パスを介して、前記他の中継装置に前記依頼パケットを送信する依頼元送信部と、
   前記他の中継装置によって、前記依頼パスを介した前記依頼パケットが受信され、受信された前記依頼パケットに挿入された前記依頼パスの識別子に対応するフィルタ処理の条件が中継許可か否かが判別され、前記フィルタ処理の条件が中継許可の場合、前記依頼パケットから前記依頼パスの識別子が削除され、前記返信パスの識別子が挿入されて返信パケットが生成され、前記返信パスを介して送信された前記返信パケットを受信する受信部と、
   を有することを特徴とする中継装置。
8. パケットの中継処理をコンピュータに実行させるパケット中継処理プログラムにおいて、
   前記コンピュータに、
   受信パケットのフィルタ処理を他の中継装置へ代行させる依頼パケットを送信する依頼パスの識別子と、該受信パケットのフィルタ処理の条件とを対応付けて記憶し、
   受信パケットのフィルタ処理を前記他の中継装置へ代行させる依頼パケットを送信する依頼パスを構築し、前記他の中継装置で該フィルタ処理が代行された後の返信パケットを受信する返信パスを構築し、
   受信パケットについて、前記他の中継装置へフィルタ処理を代行させる依頼が必要か否かを判別し、
   判別により、依頼が必要であれば、受信パケットに前記依頼パスの識別子を挿入して依頼パケットを生成し、
   前記依頼パスを介して、前記他の中継装置に前記依頼パケットを送信し、
   前記依頼パスを介して、前記中継装置から前記依頼パケットを受信し、
   受信した前記依頼パケットに挿入された前記依頼パスの識別子に対応するフィルタ処理の条件が中継許可か否かを判別し、
   前記フィルタ処理の条件が中継許可の場合、前記依頼パケットから前記依頼パスの識別子を削除し、前記返信パスの識別子を挿入して返信パケットを生成し、
   前記返信パスを介して、前記中継装置に前記返信パケットを送信する、
   処理を実行させることを特徴とするパケット中継処理プログラム。
9. パケット中継方法において、
   受信パケットのフィルタ処理を他の中継装置へ代行させる依頼パケットを送信する依頼パスの識別子と、該受信パケットのフィルタ処理の条件とを対応付けて記憶し、
   受信パケットのフィルタ処理を前記他の中継装置へ代行させる依頼パケットを送信する依頼パスを構築し、前記他の中継装置で該フィルタ処理が代行された後の返信パケットを受信する返信パスを構築し、
   受信パケットについて、前記他の中継装置へフィルタ処理を代行させる依頼が必要か否かを判別し、
   判別により、依頼が必要であれば、受信パケットに前記依頼パスの識別子を挿入して依頼パケットを生成し、
   前記依頼パスを介して、前記他の中継装置に前記依頼パケットを送信し、
   前記依頼パスを介して、前記中継装置から前記依頼パケットを受信し、
   受信した前記依頼パケットに挿入された前記依頼パスの識別子に対応するフィルタ処理の条件が中継許可か否かを判別し、
   前記フィルタ処理の条件が中継許可の場合、前記依頼パケットから前記依頼パスの識別子を削除し、前記返信パスの識別子を挿入して返信パケットを生成し、
   前記返信パスを介して、前記中継装置に前記返信パケットを送信する、
   ことを特徴とするパケット中継方法。

Images