JP2007150641A - パケット通信装置及びネットワークシステム - Google Patents

Abstract

【課題】ネットワークへの新規サービス導入コストを低減する。
【解決手段】本発明のパケット通信装置は、ノード識別子と拡張モジュール識別子の組み合わせをエントリとする、新規サービスを提供するための拡張モジュールのネットワーク内の配備状態を管理する外部モジュール管理テーブルを持ち、高位レイヤパケット処理の対象フローを受信するとこの外部モジュール管理テーブルに基づいて拡張モジュールを備えるノードへこのフローを転送し、複数の本発明のパケット通信装置で拡張モジュールを共有する。
【選択図】図１

Description

本発明は、ネットワークの機能拡張性を高めるためのルータ及びスイッチのアーキテクチャに関する。

IPネットワークは、その普及に伴い、その上で様々なネットワークサービスが利用されている。ネットワークサービスの多様化・複雑化により、トンネリングのためのパケットのカプセル化や暗号化、フィルタリング等、様々なパケット処理が必要となる。このようなパケット処理を実行可能とする際、サービス導入の容易性を高めるため、加入者の作業負荷の抑制が必要となる。

このため、端末側ではなくネットワーク側でパケット処理を実行することで新規ネットワークサービスの利用を可能にするアプローチが取られる。このアプローチの例として、ネットワークのエッジに位置するノードに拡張機能モジュールを配備可能とし、新規に導入するネットワークサービスで必要とするパケット処理機能をモジュールとしてノードに配備する、モジュール型ノードの例がある。

ここでノードとは、ルータとスイッチ、ルータとスイッチの機能を併せ持つレイヤ３スイッチを含む、複数のネットワークインターフェースを持ち、それらに入力されたパケットまたはフレームを適切なネットワークインターフェースから出力する装置である。

モジュール型ノードの例では、ノードがパケット転送機能部内にフロー管理テーブルを持ち、フロー条件の合致するエントリがテーブル内に存在するフローを受信した場合、そのエントリに記載された内部アドレスの値に基づいて、パケット転送機能部がノード内部のモジュールへフローを転送する。

モジュール型ノードは、基本機能部から拡張モジュールへ転送されたパケットに対して、ファイアウォールを実現するためのフィルタリングや、VPNを実現するためのカプセル化やカプセル化解除処理を拡張モジュール上で実行する。そして、拡張モジュール上、あるいは拡張モジュールから回線インターフェースへ転送した後に回線インターフェース上で、これらの処理による加工後のパケットに対して宛先検索処理を実行し、その結果に従って次宛先ノードへ転送する。

モジュール型ノードは、このような形で高位レイヤパケット処理機能を拡張モジュールの形でノード上に配備可能である。したがって、ネットワークへの新機能導入に際し、ノードシステム全体や全ての回線インターフェースを交換することなく、拡張モジュールを導入するだけで新機能を利用した新たなネットワークサービスをユーザに提供可能となる。これにより、新たなネットワークサービスをネットワークに導入する際の初期コストを低く抑えられる効果がある。

非特許文献1の拡張モジュールは、モジュール型の構成を持つノードに対応した拡張モジュールの1つであり、ネットワーク上でファイアウォールサービスを実現するものである。この拡張モジュールの導入により、管理者はノード内の各ポートでのファイアウォール機能の利用を指定可能となる。

シスコシステムズ株式会社、製品情報No.2484、Catalyst 6500シリーズサービスモジュール、http://www.cisco.com/japanese/warp/public/3/jp/product/hs/switches/cat6500/modules/service/service.shtml

モジュール型ノードとその拡張モジュールを利用した新規ネットワークサービスの導入では、初期導入コストの低減が課題である。ネットワーク内の全ての範囲をサービス適用範囲としてネットワークサービスの提供を開始する場合、サービス適用対象となるトラフィックを全て捕捉できるよう、ネットワーク内の多数のノードに拡張機能モジュールを導入する必要がある。モジュール型ノードを利用してネットワークサービスを新規に導入する場合、新規サービスの提供範囲と初期投資額がトレードオフの関係にある。通信事業者が初期投資を抑えるために拡張モジュールの配備数を少なくすると、サービスの提供可能範囲が狭くなるという問題点がある。

本発明の第一の目的は、上記の問題点を改善し、ネットワークへの拡張モジュール配備数を抑えながら、広範囲に新規サービスを適用可能なノードを提供することである。

また本発明の第二の目的は、拡張モジュール配備によるネットワークへの新規サービス導入時に管理者の設定作業を低減し、運用管理コストを低減させられるノードを提供することである。

また本発明の第三の目的は、利用者の増加に合わせてネットワーク内の高位レイヤパケット処理機能の処理能力を柔軟に増加させられるノードを提供することである。

本発明の第一の目的を達成するために、本発明では複数のノードがネットワーク内の同一のノード上の拡張モジュールを共有する。本発明のノードは、ネットワーク内のノードに配備された拡張モジュールの情報を保持する外部モジュール管理テーブルを備える。本発明のノードは、受信した高位レイヤパケット処理の対象となるフローがどのノードで転送されるべきかをこの外部モジュール管理テーブルを検索することで調べ、該当する拡張モジュールを配備したノードが存在する場合はそのノードにフローを転送する。このように拡張モジュールを共有することでネットワークでのサービスにおいて、特にサービス開始時に必要となる拡張モジュールの配備数を少なくし、初期投資額を抑制できる。

本発明の第二の目的を達成するために本発明のノードは、拡張モジュールが配備されるとネットワーク内の他のノードへ自身の識別子と共に拡張モジュールの種別識別子を広告する。また本発明のノードは、ネットワーク内の他のノードから広告されたこの情報を収集して拡張モジュール配備情報を自動的に構築する。これにより、ネットワーク内のノードへの拡張モジュール配備時に、各ノードへパケット処理機能種別毎の転送先アドレスを自動的に設定でき、運用コストを低減できる。

本発明の第三の目的を達成するために本発明のノードは、同一のモジュール種別である複数の拡張モジュールがそれぞれに配備された複数のノードを転送先として利用する。ネットワーク内に配備された本発明のノードは、高位レイヤパケット処理の対象であるフローを受信すると、ネットワーク内にある複数の転送先ノードからいずれかを選択して転送先ノードとして利用する。これにより、サービス適用対象ユーザが増加するのに応じてネットワーク内の高位レイヤパケット処理能力を柔軟に増加させられる。

ネットワーク内で必要となるだけのパケット処理能力を配備できる。これにより、ネットワーク内の全てのモジュールに拡張機能モジュールを導入する場合と比較して、ネットワークサービスの新規導入に伴う拡張モジュールの導入コストを抑制できる。

以下、本発明を実施するための最良の形態について、図面を用いて詳細に説明する。

図１は、本発明の第1の実施の形態のノードを含むネットワーク構成図である。図１は企業内のネットワークを表す。

本発明の複数のノード１、２が互いに接続されるとともに、それぞれコアルータ３とも接続され、コアルータ３を介して外部ネットワーク６へ接続されている。前記本発明の複数のノードはそれぞれ端末群４を収容している。ユーザはこの企業内のネットワーク５を介してユーザの端末から外部ネットワークへのアクセスが可能となる。

前記本発明のノード１、２はレイヤ３スイッチとして動作し、収容する端末のうち、同一ネットワークセグメントに属する端末間でEthernet（登録商標）フレーム及びMACフレームを転送するブリッジングと、異なるネットワークセグメントに属する端末間でIPパケットを転送するルーティングとを実行する。

前記本発明のノード１及びノード２には、それぞれルータID192.168.0.1及びルータID192.168.64.1が設定されている。また、コアルータ３にはルータID192.168.128.1が設定されている。各ルータのこれらのルータIDはそれぞれのルータ自身の回線インターフェースまたはVLAN、ループバックインターフェースに対して割り当てられたIPアドレスのいずれかを利用する。

前記ルータIDは、ネットワーク内の前記本発明のノード１及びノード２のルーティングテーブル上にその経路エントリが作成される。この経路エントリは、管理者により静的経路として設定されるか、あるいは動的経路制御プロトコルにより自動的に設定される。コアルータとノード１、ノード２のルーティングテーブルは、転送されるパケットがネットワーク５の中で経由するルータの数が最小となるように設定されている。すなわち、端末からノード２に入力された、外部ネットワーク内のホストを宛先とするIPパケットは、ノード１を経由せず、ノード２からコアルータへ直接出力される。

前記本発明のノードには、ネットワークの管理者が拡張モジュールを導入できる。この拡張モジュールは、前記本発明のノードで転送するユーザからの、あるいはユーザへのフレームあるいはパケットに対してファイアウォールのためのフィルタリング処理や、VPN用のトンネル作成のためのカプセル化／カプセル化解除処理等のパケット処理機能を実行する。

本発明のノードの第1の実施の形態では、前記拡張モジュールとしてURLフィルタリングモジュールを例にとり、ネットワーク内の本発明のノード１にこのURLフィルタリングモジュール１２を導入した例を示す。前記URLフィルタリングモジュール１２は、ユーザからのHTTPメッセージのうち、あらかじめ設定されたアクセス不許可サイトを宛先とするものをフィルタリングする。

図２は、図１に示したノード１とノード２の間の通信シーケンスである。ノード１には、初期状態では拡張モジュールは導入されていない。管理者は、ノード１とノード２が起動し、それらの初期化作業が終わった後にノード１にURLフィルタリングモジュール１２を導入する。ノード１は、このURLフィルタリングモジュール１２の導入を検知し、ネットワーク５内の他のノードにURLフィルタリングモジュール１２の追加を広告する。

図３は、第１の実施の形態のノード１からノード２へ送信される拡張モジュール追加メッセージ40のフォーマットの例を示す。拡張モジュール追加メッセージ40は、IPヘッダとUDPヘッダに続き、拡張モジュール追加メッセージであることを示すメッセージ種別フィールド401、メッセージ長フィールド402、ノードIDフィールド403、モジュール種別フィールド404、フロー条件フィールド405を持つ。

図４は、第1の実施の形態のノード１の機能ブロック図の例である。ノード１は、回線インターフェース11上にパケット／フレーム転送機能111とフロー検出機能112と内部モジュール管理テーブル113とフロー管理テーブル114とを備える。

またノード１は、拡張機能部12上にURLフィルタリング機能121を備える。

またノード１は、制御部13上に内部モジュール管理テーブル131と外部モジュール管理テーブル132と構成定義133とモジュール管理機能134とフロー管理機能135と構成定義管理機能136とを備える。

図５は、第1の実施の形態のノード１のブロック図の例である。ノード１は回線インターフェース11とURLフィルタリングモジュール12、制御部13とを内部スイッチ14で接続することで構成する。

ノード１は制御部13をCPUと入出力装置、外部記憶装置、メモリ、内部スイッチインターフェースにより構成し、制御部13内のメモリ上には、内部モジュール管理テーブル131、外部モジュール管理テーブル132、構成定義133、モジュール管理機能134、フロー管理機能135、構成定義管理機能136とが格納されている。

図６は、第1の実施の形態のノード１の内部モジュール管理テーブル131の構成の例である。前記内部モジュール管理テーブル131は、拡張モジュールの内部アドレスと自ノードの拡張機能モジュールの機能種別、およびフロー種別を定義する条件をそのエントリとする。このテーブルにより、ノード１上の拡張モジュールを管理する。

拡張モジュールの内部アドレスは、ノード１内部で一意に設定され、内部スイッチを介してデータを拡張モジュールに送受信するために用いられるアドレスである。回線インターフェース13または拡張モジュール12は、ノード１内部の拡張モジュール12または回線インターフェース13へデータを送信する際、この内部アドレスをヘッダに付与して内部スイッチ14にデータを送信する。

図７は、第1の実施の形態のノード２の外部モジュール管理テーブル132の構成である。前記外部モジュール管理テーブル132は、ネットワーク５内で一意なノードIDと自ノードの拡張機能モジュールの機能種別、及びフロー種別を定義する条件とをそのエントリとする。ノード２は、外部モジュール管理テーブル132により、ネットワーク５内の他のノード上の拡張モジュールを管理する。

図８は、前記URLフィルタリングモジュール12を導入した第1の実施の形態のノード1が起動して初期化作業を進める時のモジュール管理機能134の動作フローである。モジュール管理機能部134は、起動して初期化処理を開始すると、内部モジュール管理テーブル131及び外部モジュール管理テーブル132を初期化する。続いてモジュール管理機能部134は、ノード内に拡張モジュール12が存在するか否かを検索し、拡張モジュール12が存在する場合はモジュール情報を取得してその内容に基づき内部モジュール管理テーブル131を更新し、ネットワーク内の他のノードへモジュールの追加を広告し、拡張モジュール12が存在しない場合は初期化処理を終了する。

ノード１からネットワーク５内へ拡張モジュール12の追加を広告する際、ノード１のモジュール管理機能部134は、パケット／フレーム転送機能部111を介して、前記拡張モジュール追加メッセージ40を送信する。

ノードID 403は、ネットワーク５内の他のノードから到達可能なIPアドレスであり、ノード１の回線インターフェースあるいはループバックインターフェースに設定されているいずれかのIPアドレスから選択される。ここではノードID 192.168.0.1が格納される。拡張モジュールのモジュール種別404は、文字列または数値で拡張モジュールの種別を表したものである。ここではモジュール種別URLフィルタリングが格納される。拡張モジュールへの転送フロー条件405は、管理者が拡張モジュールへ転送するフローの条件をノード２に設定せずに拡張モジュールを有効化した場合に、ノード２のパケット／フレーム転送機能部からノード１の拡張モジュールへ転送されるフローの条件を表す。ここでは、TCPの宛先ポート番号が80であるHTTPパケットがノード２からノード１の拡張モジュールへ転送されるよう設定されている。
（拡張モジュール追加広告を送信したノードの動作）
図９は、管理者が稼働中の本発明のノード１へ拡張モジュール12を導入した際の、本発明のノード１の機能ブロック間の通信を示す。ノード１に導入された拡張モジュール12は、バスが持つハードウェアによる割り込み機能あるいは拡張モジュール12上に実装されるソフトウェアによる割り込み機能を利用して、ノード１の制御部13へ自身の追加を通知する。あるいは、拡張モジュール12を配備するインターフェースに対して制御部13が定期的にメッセージを送信し、拡張モジュール12がこのメッセージに返信することで、ノード１は拡張モジュール12の導入を動的に検知する。

モジュール管理機能134は、拡張モジュール12からの通知によりその導入を検知すると、内部モジュール管理テーブル113、131を拡張モジュール12に合わせて更新するとともに、ネットワーク５内の他のノードへ、拡張モジュール追加メッセージ40に拡張モジュール12の導入を広告する。

さらに、モジュール管理機能部134は、内部モジュール管理テーブル131の更新とその更新したエントリのアドレスをフロー管理機能部135へ通知し、フロー管理テーブル114の更新を要求する。

図１０は、管理者が稼働中のノード1へ拡張モジュール12を導入した際の、ノード１のモジュール管理機能部134の動作フローを示す。モジュール管理機能部134は、拡張モジュール12の導入に伴う割り込みにより、モジュール追加処理を開始する。モジュール追加処理を開始したモジュール管理機能部134は、割り込みを受信すると新規導入モジュールからモジュール種別及びフロー検出条件を取得し、拡張モジュール12の配備されたインターフェースの内部アドレスとこのモジュール種別及びフロー検出条件を用いて内部モジュール管理テーブル131を更新する。

図１１は、拡張モジュール12の導入に伴い、モジュール管理機能部134により更新されたノード１の内部モジュール管理テーブル131の例を示す。内部スイッチ14の内部アドレス0x04を持つポートにURLフィルタリングモジュール12が接続されていることを表すエントリが追加されている。

図１０のフローに戻ると、続いてモジュール管理機能部134は、前記エントリに新たに設定した内容をパケット／フレーム転送機能111を介して前記拡張モジュール追加メッセージ40によりネットワーク内の他のノードへ広告する。モジュール管理機能部134は、モジュール追加の情報をネットワーク内の他ノードに通知した後、内部モジュール管理テーブル131の更新と、更新された内部モジュール管理テーブル131のアドレスまたはエントリ番号とをフロー管理機能部135に通知する。
（拡張モジュール追加広告を受信したノードの動作）
図１２は、新規に拡張モジュール12を導入したノード1からの拡張モジュール追加メッセージ40を受信したノード2の機能ブロック間の通信の様子を表す。パケット／フレーム転送機能部111は、受信した拡張モジュール追加メッセージ40をモジュール管理機能部134に内部転送する。モジュール管理機能部134はこの拡張モジュール追加メッセージ40を解析して外部モジュール管理テーブル132を必要に応じて更新し、フロー管理機能部135へ拡張モジュールの追加を通知する。

ノード２のブロック構成は、図５に示したノード１の場合と同様である。

図１３は、ノード2がノード１から拡張モジュール追加メッセージ40を受信した際の、モジュール管理機能部134の動作フローである。上記ネットワーク内のノード2のモジュール管理機能部134は、回線インターフェース11を介して上記ノード1から拡張モジュール12の新規導入広告を受信し、その内容に従って自身の外部モジュール管理テーブル132を更新する。
モジュール管理機能部134は、外部モジュール管理テーブル132の更新が完了すると、フロー管理機能部135へモジュール管理テーブルの更新を通知する。この時モジュール管理機能部134は、内部モジュール管理テーブル131と外部モジュール管理テーブル132のどちらが更新されたかを示す識別子と、モジュール管理テーブル上で変更されたエントリのアドレスを通知する。

図１４は、拡張モジュール12の新規導入広告を受けて更新された外部モジュール管理テーブル132の例を示す。外部モジュール管理テーブルには、ノード1のルータID 192.168.0.1とモジュール種別 URLフィルタリング、フロー条件HTTPが格納される。

図１５は、拡張モジュールを配備した本発明のノードがネットワーク内のルータあるいはスイッチへモジュール更新情報を広告する動作を示す。ネットワーク内のルータあるいはスイッチは、リンク状態型ルーティングプロトコルあるいはSTP、LLDP等のパケットを受信すると、このパケットに格納されたモジュール情報を抽出し、このモジュール情報を自身の外部モジュール管理テーブルへ反映させる。

拡張モジュール12aを配備したルータ1aがネットワーク内の他のルータ2aに拡張モジュール12aの配備を広告する場合、既存のリンク状態型ルーティングプロトコルに新たなリンク状態広告種別を定義し、モジュールの追加あるいは削除に伴いこの新たに定義したリンク状態広告種別を指定したリンク状態広告をネットワーク内に広告することで、本発明を実施できる。リンク状態型ルーティングプロトコルの例として、OSPF (Open Shortest Path First)及びIS-IS (Intermediate System-to-Intermediate System)が挙げられる。

本発明のルータ1aがOSPFを用いて拡張モジュール12aの追加あるいは削除をネットワーク内に広告する場合、モジュール更新情報を格納するためのOpaque LSA (Link State Advertisement)の構造をリンク状態広告中に新たに定義し、OSPFによる経路制御情報のネットワーク内への広告と合わせ、モジュール更新情報を広告することで本発明を実施できる。

また、本発明をスイッチ1bに適用する場合、モジュール更新情報を格納するためのBPDU(Bridge Protocol Data Unit)の構造をリンク状態広告中に新たに定義し、IEEE802.1D STP (Spanning Tree Protocol)でのリンク情報の交換と合わせ、モジュール更新情報を広告することで本発明を実施できる。

あるいは、本発明をスイッチ1bに適用する場合、モジュール更新情報を格納するためのLDPDU (Link Discovery Protocol)の構造をリンク状態広告中に新たに定義し、LLDP (Link Layer Discovery Protocol)での装置情報の交換と合わせ、モジュール更新情報を広告することで本発明を実施できる。

管理者は、ノード1の拡張モジュール12上に実装されたURLフィルタリング機能121を、ノード2の入力フローに適用するか否かを、ノード2の構成定義133へ設定する。

図１６は、管理者がURLフィルタリングモジュール12の利用開始をノード1に設定する際の、本発明のノード１の機能ブロック間の通信の流れを示す。構成定義管理機能部136は、管理者から入力があると、この入力内容に従い構成定義133上の高位レイヤパケット処理サービス利用設定を更新する。そして、この変更の発生をフロー管理機能部135へ通知する。

フロー管理機能部135は、構成定義管理機能部136からのこの通知を受け、内部モジュール管理テーブル131と外部モジュール管理テーブル132、構成定義133の情報に基づいてパケット転送機能部11上のフロー管理テーブル114を必要に応じて更新する。

図１７は、拡張モジュールでのパケット処理の対象フローを定義したノード2の構成定義133の例を示す。構成定義133はXML形式により記述され、パケット処理の対象となるフローを<flow>要素により定義している。パケット処理の対象フローの条件を指定するため、構成定義133中の<flow>要素は<interface>要素により対象インターフェースを、さらに<interface>要素中の<ip>要素と<tcp>要素によりそれぞれIPアドレスとTCP/UDPのポート番号を条件として指定する。また、構成定義133は、<flow>要素で定義した各フローへ適用するパケット処理を<service>要素により定義する。<service>要素中の<type>属性によりパケット処理種別を指定し、このパケット処理の対象とするフローを表す<flow>要素を一つまたは複数含む<flows>要素を<service>要素中に記述する。

ノード2の構成定義133には、インターフェースeth0を通る宛先ポート番号が80番のTCPパケットと、インターフェースeth1を通る、宛先ホストがproxy.aaa.co.jpで宛先ポート番号が8080番のTCPパケットとが拡張モジュールによるパケット処理の対象フローとして定義され、これらの二通りのフローに対して拡張モジュールがURLフィルタリング処理を実行するよう、指定されている。
（構成定義投入／更新時の動作）
図１８は、管理者がノード2の構成定義を新規に投入、あるいは更新した後に構成定義管理機能部136がフロー管理機能部135へ構成定義133の更新通知を送信した場合の、フロー管理機能部135の該当モジュール検索処理のフローチャートを示す。

フロー管理機能部135は、構成定義管理機能部136から構成定義133の更新通知を受信すると該当モジュール検索処理を開始する。フロー管理機能部135は、まず構成定義133中のパケット処理適用フロー指定を解析する。

フロー管理機能部135は、構成定義133中に指定されたパケット処理を提供可能な拡張モジュールがネットワーク内に配備されているか、まず内部モジュール管理テーブルを検索する。検索の結果、該当するエントリが内部モジュール管理テーブル131上に存在した場合、そのエントリに格納されたIDで示されるノード内の拡張モジュールへフローを内部転送するよう、フロー管理テーブル114を更新し、該当モジュール検索処理を終了する。

フロー管理機能部135は、該当エントリが内部モジュール管理テーブル131上に存在しなかった場合、続いて外部モジュール管理テーブル132を検索する。検索の結果該当エントリが存在した場合、そのエントリに格納されたIPアドレスで示される外部ノード1へ、カプセル化してフローを転送するよう、フロー管理テーブル114を更新し、該当モジュール検索処理を終了する。

このようにして構成定義内でパケット処理の適用を指定し、拡張モジュールを配備したノードからの拡張モジュール情報の広告を受けることで、自動的にネットワーク内に配備された拡張モジュールのリソースを複数のノードから共有できる。管理者は、自身が設定している内容がどのノードで実行されているかを意識することなく、透過的にネットワーク内の拡張モジュールを利用できる。

フロー管理機能部135は、外部モジュール管理テーブル132上にも該当エントリが存在しなかった場合、管理者の設定用インターフェースに対してエラーメッセージを表示し、該当モジュール検索処理を終了する。
（モジュール情報更新時の動作）
図１９は、本発明の第１の実施の形態のノード１にURLフィルタリングモジュール12が導入され、ノード１の内部モジュール管理テーブル131が更新された場合のノード１内の機能ブロック間の通信を表す。

ノード１のフロー管理機能部135は、モジュール管理機能部134から内部モジュール管理テーブル131が更新されたことを通知されると、フロー管理テーブル更新判定処理を行い、内部モジュール管理テーブル131と構成定義133を参照し、これらに基づいてフロー管理テーブル114を更新する。

図２０は、本発明の第１の実施の形態のノード１において、ノード１内部への拡張モジュールの追加によりモジュール管理機能部134がフロー管理機能部135へ内部モジュール管理テーブルの更新を通知した場合の、フロー管理機能部135によるフロー管理テーブル更新判定処理のフローチャートを示す。

ノード１のモジュール管理機能部134は、内部モジュール管理テーブル131上の更新されたエントリのアドレスのリストを、フロー管理機能部135へ通知する。この内部モジュール管理テーブル更新情報の通知では、更新エントリのアドレスをリストとしてではなく、1エントリずつ通知しても良い。

ノード１のフロー管理機能部135は、内部モジュール管理テーブル131の更新通知をモジュール管理機能部134から受信すると、フロー管理テーブル更新判定処理を開始する。フロー管理機能部135は、この通知に含まれる情報に基づいて内部モジュール管理テーブル131から更新エントリを読み出す（Ｓ１４０）。

フロー管理機能部135は、更新エントリのモジュール種別をキーとして構成定義を検索し、処理種別が新規導入拡張モジュールと一致するエントリがあるかを判定する（Ｓ１４１）。この判定の結果、処理種別が一致するエントリが構成定義中に存在しない場合、フロー管理機能部135は、内部モジュール追加時のフロー管理テーブル更新判定処理を終了する。

前記判定の結果、処理種別が一致するエントリが構成定義中に存在する場合、フロー管理機能部135は、外部モジュール管理テーブル132上に同一のパケット処理種別を持つエントリが存在するかを調べ（Ｓ１４２）、存在する場合は、該当エントリを外部モジュール管理テーブル132上から削除し（Ｓ１４３）、存在しない場合はそのまま次のステップへ進む。
フロー管理機能部135は、フロー条件を構成定義133中の該当エントリに格納されているプロトコルあるいはIPアドレスで表される条件とし、転送先種別を内部、転送先アドレスを拡張モジュール12の内部アドレスとして、パケット処理の対象フローがノード１上の拡張モジュールへ転送されるようにフロー管理テーブル114を更新する（Ｓ１４４）。

図２１は、ノード1へのURLフィルタリングモジュール導入後にノード1のモジュール管理機能部134及びフロー管理機能部135により更新された、ノード1のフロー管理テーブル114aを示す。ノード1のフロー管理テーブル114aには、構成定義中133に指定されたフロー条件としてHTTP、転送先種別として内部、転送先アドレスとして内部アドレス0x01が格納されたエントリが作成される。

図２２は、本発明の第１の実施の形態のノード１にURLフィルタリングモジュール12が導入され、ノード２の外部モジュール管理テーブル132が更新された場合のノード２内の機能ブロック間の通信を表す。

ノード２のフロー管理機能部135は、モジュール管理機能部134から外部モジュール管理テーブル132が更新されたことを通知されると、フロー管理テーブル更新判定処理を行い、外部モジュール管理テーブル132と構成定義133を参照し、これらに基づいてフロー管理テーブル114を更新する。

図２３は、本発明の第１の実施の形態のノード２において、ノード１への拡張モジュールの追加によりモジュール管理機能部134がフロー管理機能部135へ外部モジュール管理テーブルの更新を通知した場合の、フロー管理機能部135によるフロー管理テーブル更新判定処理のフローチャートを示す。

ノード２のモジュール管理機能部134は、外部モジュール管理テーブル132上の更新されたエントリのアドレスのリストを、フロー管理機能部135へ通知する。この外部モジュール管理テーブル更新情報の通知では、更新エントリのアドレスをリストとしてではなく、1エントリずつ通知しても良い。

ノード２のフロー管理機能部135は、外部モジュール管理テーブル132の更新通知をモジュール管理機能部134から受信すると、フロー管理テーブル更新判定処理を開始する。フロー管理機能部135は、この通知に含まれる情報に基づいて外部モジュール管理テーブル132から更新エントリを読み出す（Ｓ１５０）。

ノード２のフロー管理機能部135は、内部モジュール管理テーブル131を検索し、更新エントリと同じパケット処理種別を含むエントリが存在するかを判定する（Ｓ１５１）。この判定の結果、パケット処理種別が同一のエントリが内部モジュール管理テーブル131に存在する場合、フロー管理機能部135は、風呂管理テーブル更新判定処理を終了する。フロー管理機能部135は、判定の結果、パケット処理種別が同一のエントリが存在しない場合、更新エントリと同一種別のパケット処理の利用指定が構成定義中に存在するかを判定する（Ｓ１５２）。この判定の結果、構成定義中に利用指定が存在しない場合、そのままフロー管理テーブル更新判定処理を終了する。利用指定が存在する場合、ノード１上の拡張モジュールへパケット処理対象フローを転送するよう、フロー管理テーブル114を更新し（Ｓ１５３）、フロー管理テーブル更新判定処理を終了する。

図２４は、ノード1へのURLフィルタリングモジュール12導入後にノード2のモジュール管理機能部134及びフロー管理機能部135により更新された、ノード2のフロー管理テーブル114bを示す。ノード2のフロー管理テーブル114bには、構成定義133中に指定されたフロー条件としてHTTP、転送先種別として外部、転送先アドレスとしてノード1のノード識別子であるIPアドレス192.168.0.1が格納されたエントリが作成される。

図２５は、本発明の複数の第1の実施の形態のノード間でのパケット転送の流れを示す。端末4からWebサーバへHTTP要求を含むパケット41が送信されると、まず、端末4のデフォルトゲートウェイであるルータID192.168.64.1のノード2がこのパケットを受信する。ノード2のレイヤ3スイッチ転送機能部21は、受信したIPパケット41のIPヘッダ、TCPヘッダあるいはUDPヘッダを解析する。ノード2では、URLフィルタリング機能の適用が構成定義上で有効化されているため、ノード2のレイヤ3スイッチ転送機能部21は、ノード間転送用ヘッダ420でIPパケット41をカプセル化したパケット42をノード1へ転送する。

ノード1は、HTTP要求を含むその内部に含むカプセル化されたIPパケット42をノード2から受信する。ノード1のレイヤ3スイッチ転送機能部11は、IPパケット42にさらに内部転送用ヘッダ431を付与した内部転送用パケット43をノード1上のURLフィルタリングモジュール12へ転送する。URLフィルタリングモジュール12は、内部転送用パケット43の内部に含まれるHTTP要求を解析し、URLあるいは宛先IPアドレスに基づいてこのパケット43を転送あるいは廃棄する。

図２６は、本発明の複数の第1の実施の形態のノード間での、拡張モジュール12を配備したノード1での高位レイヤパケット処理を実行した後の、ノード1からノード2へカプセル化ヘッダ450を付与してパケット45を返信する場合のノード間のパケットの流れを示す。

ノード1のURLフィルタリングモジュール12が受信Web要求に対してアクセス許可／不許可判定を実行し、その結果アクセス許可と判定された場合、URLフィルタリングモジュール12は、受信パケット43の内部ヘッダ431を書き換えて内部ヘッダ460を持つパケット44をレイヤ3スイッチ転送機能部11へノード内部で転送する。URLフィルタリングモジュール12でのアクセス許可／不許可判定の結果、不許可判定の場合、URLフィルタリングモジュール12はWeb要求を含む内部転送パケット43を廃棄する。

ノード1のパケット転送機能部11は、URLフィルタリングモジュールから受信したパケット44のカプセル化ヘッダ420を解析し、ノード2への返信用のカプセル化ヘッダ450を作成する。パケット転送機能部11は、内部転送パケット44の内部転送用ヘッダ460を除去すると共に、カプセル化ヘッダ420を新たに作成したこのカプセル化ヘッダ450に変更し、転送元のノード2へ返信パケット45を送信する。

パケット転送元のノード2は、転送先のノード1からカプセル化されたIPパケット45を受信すると、このカプセル化ヘッダ450を削除し、ペイロード部分のパケット46の次宛先を検索し、該当インターフェースからパケット46を次宛先のコアルータ3へ転送する。

図２７と図２８は、それぞれ本発明の複数の第1の実施の形態のノード間でパケットが転送される時と、転送先のノード内部でレイヤ3スイッチ転送機能部から拡張モジュールへとパケットが転送される時のパケットのフォーマットを示す。

図２７に示すノード間のパケット転送時のパケット42は、ノード2が端末4から受信したIPパケット41の先頭にモジュール種別423を付与し、さらにUDPヘッダ422と、宛先をノード1のルータ識別子192.168.0.1、送信元をノード2のルータ識別子192.168.64.1としたIPヘッダ421を付与した形となる。

図２８に示す転送先ノード内部でのパケット転送時のパケット43は、図２４に示すノード間転送時のパケット42に、宛先内部アドレス4311を0x04、送信元内部アドレス4312を0x01とした、ノード内部の転送用ヘッダ431を付与した形となる。

図２５または図２６に示す、URLフィルタリングモジュールを配備したノード1が高位レイヤパケット処理の対象であるパケットの転送元のノード2に高位レイヤ処理の完了したパケットを返信する場合、URLフィルタリングモジュールからパケット転送機能部へ内部転送するパケット44は、図２８に示す内部ヘッダ431の宛先内部アドレス4311がノード2と接続されている回線インターフェースの内部アドレス0x01、送信元内部アドレス4312がURLフィルタリングモジュールの内部アドレス0x04となる。

また、ノード1からノード2への返信時には、図２７に示す転送用パケット42において先頭側のIPヘッダ421の宛先アドレスに192.168.64.1を、送信元アドレスに192.168.0.1を、UDPヘッダ422の宛先ポート番号にノード2からノード1への送信時の送信元ポート番号を格納し、この送信元ポート番号をノード間転送プロトコルの返信メッセージを表す識別子とする。

前記ノード間転送プロトコルの返信メッセージを表す識別子は、ネットワーク内で固定値を定義して用いても良い。また、フロー検出機能部112あるいはパケット転送機能部111がノード2からの転送メッセージ作成時に動的に識別子を割り当ててノード2のメモリ上に保持し、高位レイヤ処理を実行したノード1からの返信メッセージのヘッダ内の識別子をその都度ノード2のメモリ上に保持した識別子と比較することで返信メッセージと判断しても良い。

また、ここではUDPヘッダ422内の宛先ポート番号の形でノード間転送プロトコルの返信メッセージであることを特定する例を示したが、返信メッセージを表す識別子としてTCPヘッダの宛先ポート番号あるいはIPヘッダのプロトコル番号を用いてもよい。

ノード間転送プロトコルのメッセージであることを表すためにIPヘッダのプロトコル番号をネットワーク内で1つ定義して用いる場合、IPヘッダに続く固定長のフィールドを用意し、あらかじめ定義した転送あるいは返信を表す識別子をこのフィールドに格納してもよい。

転送元のノード2は、端末4からパケット41を受信すると、そのパケット41が構成定義上133で高位レイヤ処理パケット処理の対象に指定されている場合、図２７に示した、IPヘッダ421及びUDPヘッダ422、モジュール種別フィールド423からなるノード間転送用ヘッダを付加し、拡張モジュールを配備したノード1へこの転送用ヘッダを付与したパケット42を転送する。

図２９は、ノード2が端末4から高位レイヤ処理の対象であるパケットを受信した場合の、ノード2の機能ブロック間の通信の様子を示す。ノード2が端末4からパケット41を受信すると、ノード2のパケット転送機能部はフレームバッファへ受信パケットを格納し、TCPパケットヘッダあるいはUDPパケットヘッダを含むこのパケット41のヘッダをフロー検出機能部112へ送信する。

ノード2のフロー検出機能部112は、パケット転送機能部111から受信したパケットヘッダをキーとしてフロー管理テーブル114上の条件が合致するエントリを検索する。その検索結果から処理内容を判定し、処理種別及び転送先種別、転送先アドレスの組み合わせをパケット転送機能部111へ返信する。

ここでは、ノード2が端末4からWeb要求を表すTCPパケットを受信したとする。ノード2のフロー管理テーブル114bにはフロー条件がHTTP、転送先種別が外部、転送先アドレスが192.168.0.1（ノード1）であるエントリ1141bが存在している。この場合、パケット転送機能部111から受信したパケットヘッダは、フロー管理テーブル114b中のこのエントリ1141bのフロー条件と合致する。フロー検出機能部112は、処理種別を高位レイヤパケット処理、転送先種別を外部、転送先アドレスを192.168.0.1（ノード1）とした判定結果をパケット転送機能部111へ返信する。

フロー検出機能部112から判定結果を受信したパケット転送機能部111は、転送先種別が外部のため、転送先アドレスを格納したIPヘッダ421及びUDPヘッダ422を作成してこれらのヘッダによりパケット41をカプセル化し、URLフィルタリングモジュールを配備したノード1へ転送する。
ノード1は、受信した高位レイヤパケット処理対象のパケット42の通過可否をURLフィルタリングモジュール上で判定し、通過が許可されるパケットは転送元のノード2へ返信し、通過が拒否されるパケットはURLフィルタリングモジュール上で廃棄する。

図３０は、ノード1がノード2から高位レイヤ処理対象パケットを受信した場合の、ノード1の機能ブロック間の通信の様子を示す。

ノード1のパケット転送機能部111は、その回線インターフェースを介してノード2から高位レイヤ処理の対象であるパケット42を受信する。ノード1のパケット転送機能部111は受信したパケット42のUDPヘッダ422及びモジュール種別フィールド423も含むヘッダ部分をノード1内部のフロー検出機能部112へ送信する。

ノード1のパケット転送機能部111からヘッダを受信したノード1のフロー検出機能部112は、UDPヘッダ422の宛先ポート番号がノード間で高位レイヤ処理対象パケットを転送するためのプロトコルを表す番号かを判定する。

この判定の結果、UDPヘッダ422の宛先ポート番号がノード間で高位レイヤ処理対象パケットを転送するためのプロトコルを表す番号である場合、フロー検出機能部112は、UDPヘッダ422に続くモジュール種別フィールド423を読み込み、このモジュール種別フィールド423に格納されているモジュール種別を表す識別子をキーとして、内部モジュール管理テーブル131を検索する。

この検索の結果、内部モジュール管理テーブル131上にモジュール種別が合致するエントリ1141aが存在する場合は、フロー検出機能部112は、このエントリ1141aの転送先アドレスフィールドに格納されているアドレス0x11を読み出す。そして、フロー検出機能部112は、パケット転送機能部111へ高位レイヤパケット処理の指示と内部転送の指示、転送先の内部アドレスとを通知する。

パケット転送機能部111は、フロー検出機能部112から高位レイヤパケット処理の指示と内部転送の指示、転送先の内部アドレスとを通知されると、通知された転送先内部アドレスを宛先とし、パケットを受信した回線インターフェースの内部アドレスを送信元とする、図２８中に示される内部転送ヘッダ431を作成する。パケット転送機能部111は、受信した高位レイヤ処理対象パケット42にこの内部転送ヘッダ431を付与し、URLフィルタリングモジュールへパケット43を送信する。

URLフィルタリング機能部は、パケット転送機能部111から高位レイヤ処理の対象であるパケット43を受信すると、パケット43中に含まれるHTTPメッセージ中に含まれるホスト名、あるいはIPヘッダのアドレスに基づき、パケット43の通過許可／不許可を判定する。

URLフィルタリング機能部121は、この判定の結果通過許可となったパケット43の内部転送ヘッダ431及びノード間転送用ヘッダ420を除去して新たにノード間転送ヘッダ及び内部転送ヘッダを順に付与したパケット44をパケット転送機能部111へ送信する。

そして、パケット転送機能部111は、URLフィルタリング機能部121から通過許可パケット44を受信すると、このパケット44に付与されていた内部転送ヘッダ460を削除する。そして、内部転送ヘッダ460を削除したパケット44のUDPヘッダの送信元ポート番号を宛先ポート番号フィールドに書き込む。そして、IPアドレス及びポート番号を入れ替えたこのパケット45をノード2に送信する。

図２６に示すように、ノード2は、ノード1から通過判定済みパケット45を受信する。ノード2の機能ブロック間の通信の流れは、ノード2が端末4から受信したHTTP要求を含むTCPパケット41をノード1へ転送する場合（図２９）と同様なため、図２９に沿って説明する。

ノード2のパケット転送機能部111は、回線インターフェースを介してノード1からノード間転送ヘッダを付与された通過判定済みパケット45を受信する。パケット転送機能部111は、受信したパケット45のうち、IPヘッダ421及びUDPヘッダ422、モジュール種別識別子423を含むノード間転送ヘッダ、及びそれに続くHTTP要求を含むIPパケットのIPヘッダまでを、フロー検出機能部112へ通知する。

フロー検出機能部112は、パケット転送機能部111から受信した前記ヘッダがUDPヘッダを含むかどうかを調べ、UDPヘッダを含む場合は、その宛先ポート番号がノード間転送プロトコルの返信メッセージを表す識別子と一致するかを調べ、一致する場合は、パケット転送機能部111へ、カプセル化の解除と、通常のIPルーティングによるコアルータへの転送を通知する。

パケット転送機能部111は、フロー検出機能部112からの通知を受け、パケット45のカプセル化ヘッダを削除し、コアルータへ転送する。

図３１は、図２９で示したノード2が回線インターフェースを介して収容する端末4からパケットを受信する場合、あるいは図３０で示した、ノード1が回線インターフェースを介してネットワーク内の他のノードからパケットを受信する場合のパケット転送機能部111の動作フローを示す。

パケット転送機能部111は、回線インターフェースでパケットを受信すると転送処理を開始し、受信パケットからヘッダを抽出してフロー検出機能部112へ送信し、フロー検出機能部112からの通知を受信する。このフロー検出機能部112からの通知に含まれる処理種別が高位レイヤ処理の実行を表す場合、続く転送先種別の判定に進む。高位レイヤ処理の実行が指示されていない場合は、受信パケットに対して通常のルーティング処理を実行する。続く転送先種別の判定では、フロー検出機能部112からの通知に含まれる転送先種別が内部転送を表している場合、フロー検出機能部112から通知された転送先内部アドレスを格納した転送用内部ヘッダを受信パケットに付与して拡張モジュール12へこのパケットを転送し、転送処理を終了する。フロー検出機能部112からの通知に含まれる転送先種別が外部転送の場合は、フロー検出機能部112から通知されるノード間転送用ヘッダを受信パケットに付与して、フロー検出機能部112から通知される転送先ノードへ転送し、転送処理を終了する。

上述した実施例では、拡張モジュールを配備した本発明のノードがネットワーク内に一つだけ存在する例を示した。これに対して実際のネットワークでは、ネットワークでの端末収容数の増加に伴い、拡張モジュールの処理能力が不足する場合が考えられる。従って、端末収容数の増加に応じて複数の拡張モジュールで負荷を分散可能なノード及びシステムの提供が効果的となる。以下、この実施例について図面を用いて説明する。

図３２は、同一のサービスを提供可能な拡張モジュールを持つノードが複数配備されているネットワークの例を示す。
ノード2aあるいは2b内にパケット処理を実行可能な拡張モジュールが配備されていないが、対象のパケット処理を実行可能なノード1a及びノード1bがネットワーク内に複数存在する構成を取る。

ノード2a及びノード2bは、前述した実施例に置ける外部フロー管理テーブルに代わり、ノードIDとモジュール種別、フロー条件、拡張モジュールの負荷状態をエントリとする外部モジュール管理テーブルを備える。

また、ノード2a及びノード2bは、前述した実施例と同様、HTTPパケットを対象としたフィルタリングを実行するような構成定義が指定されている。

図３３は、内部モジュール管理テーブル131の例を示す。内部モジュール管理テーブル131の各エントリは、前述した実施例の場合のフィールドに加え、拡張モジュールの負荷状態を格納するためのフィールド1311を持つ。この負荷状態フィールド1311には、自ノードに配備された拡張モジュールの負荷状態を定期的に取得して格納する。

図３４は、外部モジュール管理テーブル132の例を示す。外部モジュール管理テーブル132の各エントリは、前述した実施例の場合のフィールドに加え、ネットワーク内のノードに配備された拡張モジュールの負荷状態を格納するためのフィールド1321を持つ。この負荷状態フィールド1321は、ネットワーク内の他のノードからの定期的な広告を契機として更新される。

ノード2aあるいは2bは、端末4からパケットを受信すると、入力フローがモジュールでのパケット処理の対象で、モジュール管理テーブル上に該当フローを処理可能な該当モジュールを配備したノードが複数ある場合、内部モジュール管理テーブル及び外部モジュール管理テーブル内に格納された負荷状態に基づいて、ノード1a及びノード1bに対して分散して入力フローを転送する。

図３５は、ノード1aあるいは1bとノード2aあるいは2bとの間のメッセージシーケンスの例を示す。

ノード1a及び1bは、前述した実施例と同様に、拡張モジュールが配備されると拡張モジュール追加メッセージをネットワーク内のノードに広告する。ノード2aあるいは2bは、ノード1aあるいは1bから受信した拡張モジュール追加メッセージに基づいて外部フロー管理テーブルを更新する。

ノード1a及び1bは、一定時間ごとに拡張モジュールの負荷状態を測定し、ノードIDとモジュール種別にこの測定結果を加えて格納した拡張モジュール情報メッセージをノード2a及び2bに送信する。

ノード2a及び2bは、ノード1aあるいは1bから拡張モジュール情報メッセージを受信すると、自身が外部モジュール管理テーブル内で、ノードIDとモジュール種別が合致するエントリを検索する。該当するエントリが外部モジュール管理テーブル上に存在した場合、ノード2aあるいは2bは、ノード1aあるいは1bから受信した拡張モジュール情報メッセージ中の負荷状態フィールド中の値で、外部モジュール管理テーブル上の該当するエントリの負荷状態フィールドを更新する。

前述した実施例と同様に、ノード2a及び2bのモジュール管理機能部134は、外部モジュール管理テーブル132を更新すると、フロー管理機能部135へ外部モジュール管理テーブル132の更新を通知する。フロー管理機能部135は、外部モジュール管理テーブル132に新しいエントリが追加された場合、モジュール種別が該当するサービスの適用が構成定義133中で指定されていれば、該当フローを転送するように、フロー管理テーブル114を更新する。

また、ノード2a及び2bのモジュール管理機能部134は、外部モジュール管理テーブル132に含まれる各エントリの負荷状態フィールド1322が更新された場合、パケット処理適用対象フローの転送先を再度計算し、フロー管理テーブル114を更新する。

上述した例では、ノード2a及び2bが一定時間ごとに拡張モジュールの負荷状態をネットワーク内に広告するが、ノード2a及び2bが拡張モジュールの負荷状態に閾値を設け、モジュールの負荷状態がこの閾値を越えた場合にのみ、拡張モジュールの負荷状態をネットワーク内へ広告しても良い。このように閾値を設けることで、ネットワーク内への不要な拡張モジュール情報の広告を抑制できる。

また、ノード2a及び2bがノード1aあるいは1bからの拡張モジュール情報の要求メッセージに返信する形で、拡張モジュールの負荷状態をノード1aあるいは1bに通知しても良い。
（モジュール情報更新時の動作）
図３６は、ネットワーク内のノード1bへの拡張モジュール12bの配備に伴い、ノード2aの外部モジュール管理テーブル132が更新された際の、フロー管理機能部135の転送先モジュール検索処理のフローチャートを示す。

フロー管理機能部135は、モジュール管理機能部134から外部モジュール管理テーブル132の更新通知を受信すると、転送先モジュール検索処理を開始する。フロー管理機能部135は、まず外部モジュール管理テーブル132上で更新されたエントリ1323を読み込み、このエントリのモジュール12bを転送先モジュールとして仮選択する。

次に、構成定義133中にモジュール12bのモジュール種別（URLフィルタリング）の利用指定があるかを検索し、検索の結果利用指定がない場合は、転送先モジュール検索処理を終了する。構成定義133中に利用指定がある場合は、内部モジュール管理テーブル131内に同一種別で低負荷のエントリが存在するかを調べ、存在する場合はその内部モジュールを転送先モジュールとして仮選択する。ここでは内部モジュール管理テーブル131にエントリが存在しないため、外部モジュール管理テーブル132中のエントリ1323が転送先モジュールとして選択されたままである。

続いて、外部モジュール管理テーブル132内に同一種別の低負荷のエントリが存在するかを調べ、存在する場合はその外部モジュールを転送先モジュールとして選択する。ここでは、エントリ1322の負荷状態がエントリ1323の負荷状態よりも低いため、エントリ1322のモジュールが転送先モジュールとして選択される。

（構成定義投入／更新時の動作）
図３７は、管理者がノード2aあるいは2bの構成定義を投入あるいは更新した場合のノード2aあるいは2bのフロー管理機能部135の動作のフローチャートを示す。

管理者がノード2aあるいはノード2bの構成定義133を投入あるいは更新すると、ノード2aあるいは2bのフロー管理機能部135はフロー指定処理を開始する。フロー管理機能部135は、まず構成定義133を解析し、用いられる拡張モジュールのモジュール種別を取得する。続いてフロー管理機能部135は、取得したこのモジュール種別をキーとして内部モジュール管理テーブル131及び外部モジュール管理テーブル132を検索し、複数のエントリが該当する場合は、これらのエントリのうち低負荷のエントリを選択して転送先とする。フロー管理機能部135は、選択した転送先に基づいてフロー管理テーブル114を更新し、フロー指定処理を終了する。

上記実施例では、ノード1a及び1b上の拡張モジュールの負荷状態に基づいてノード2a及び2bで受信したフローのそれぞれの転送先ノードを決定した。ここで、拡張モジュールの負荷状態ではなく、ノード2a及び2bからノード1a及び1bそれぞれへの到達所要時間に基づいてノード2a及び2bで受信したフローのそれぞれの転送先ノードを決定することもできる。この場合、ノード2a及び2bで受信したフローは、それぞれの最近傍ノードに転送される。これにより、ノード2a及び2bからノード1aあるいは1bへの転送の所要時間を最小限とし、サービス品質の低下を抑える効果がある。

図３８は、本発明をスイッチで実施した場合の実施の形態の例を示す。

ユーザ端末を収容する複数のスイッチ8aから8eをネットワークラックに配備し、それらの間をカスケード接続する。スイッチ8aにはURLフィルタリングモジュール81を配備し、ユーザ端末からのWeb要求のうち、あらかじめ設定されたURL以外へのWeb要求を含むTCPパケットを全て廃棄する。

カスケード接続されたスイッチ8aから8eは、スイッチ8aに配備されたURLフィルタリングモジュール81を共有する。管理者は、これらのスイッチ8aから8eまでの構成定義133に、図１７に示すように、URLフィルタリングモジュール81の利用を有効化する設定を記述する。

図１に示したレイヤ3スイッチでの実施の形態の場合と同様に、ネットワークラック内のスイッチ8bから8eは、受信したフレームのうち、構成定義133で指定されたフロー条件に該当するフレームを、スイッチ8aに転送する。スイッチ8aは受信フレームを解析して他のノードからのノード間転送フレームである場合は、内部転送用ヘッダ431を付与してこのフレームをURLフィルタリングモジュール81へ内部転送する。
企業ネットワークのようにネットワーク機器の設置面積に制約が存在する場合に、このようにカスケード接続した複数のスイッチ間で拡張モジュールを共有することで、拡張モジュールによる新規サービスを利用しながら、拡張モジュールの機器コストを抑えると共に、必要な設置面積を低減して収容密度の低下を最低限に抑えられる効果がある。

本実施の形態では、図６に示す外部モジュール管理テーブル132の作成に際し、拡張モジュールを配備したスイッチ8aが持つMACアドレスを転送先アドレスに指定する。

図３９は、本実施の形態においてスイッチ間で高位レイヤパケット処理対象のMACフレームを転送する場合の、スイッチ間転送用フォーマットを示す。

スイッチ8bから8eが高位レイヤパケット処理対象フローをスイッチ8aへ転送する場合、転送用フレーム92は、前記実施例の図２４に示すノード間転送ヘッダのIPヘッダ421とUDPヘッダ422、モジュール識別子423の組み合わせを、MACヘッダ921とモジュール種別識別子922の組み合わせに置き換えた形となる。このMACヘッダ921は、宛先MACアドレスをスイッチ8aのMACアドレスに、送信元MACアドレスを転送元スイッチのアドレスにし、プロトコル種別をフロー転送の識別子とする。

スイッチ8a内でのURLフィルタリングモジュールへのフレームの転送時に用いられる内部転送用ヘッダには、前記実施例の図２８に示した内部転送用ヘッダ431と同様の形式を用い、内部転送用ヘッダ431には転送先内部アドレス4311と送信元内部アドレス4312を格納する。

図４０は、稼働中の本発明のノード1へ拡張モジュール12を導入した際、あるいは本発明のノード1へ拡張モジュール12を配備して起動した際、前記実施例に示したモジュール更新情報をネットワーク内の他のノードへ通知するための、他の実施の形態を表す。

図４０に示す実施の形態では、モジュール更新情報配布サーバ7を、ネットワーク内に配置する。モジュール更新情報配布サーバ7は、SNMPマネージャ71と、モジュール更新情報管理機能72と、ノード管理データベース73を持つ。ノード管理データベース73は、ネットワーク内に配備されているノードのうち、本発明のノードの識別子のリストを格納する。

また、ノード1の制御部13は、SNMPエージェントをその内部に持ち、モジュール更新情報配布サーバ7上のSNMPマネージャ71へSNMPトラップを発行する。

ネットワーク内には本発明のノード2が配備されている。ノード2は稼働状態とする。前記ノード1を起動すると、ノード1は、あらかじめ設定されたモジュール更新情報配布サーバ7のアドレスへ、ノード構成情報75を通知する。ノード1は、このノード構成情報75の通知にSNMPトラップを用いる。

あるいは、その変数バインドにノード1のアドレスを含めた、ノードの起動を表すSNMPトラップを定義する。ノード1がモジュール更新情報配布サーバ7へノードの起動を通知した後に、モジュール更新情報配布サーバ7がSNMPによるMIB情報の取得により、ノード1がモジュール更新情報の配布対象のノードであることを認識し、ノード1のアドレスをノード管理データベース73へ加える形としても良い。

管理者がノード1へ拡張モジュール12を導入すると、ノード1は、あらかじめ設定されたモジュール更新情報配布サーバのアドレスを宛先として、前記モジュール更新情報76を通知する。

モジュール更新情報配布サーバ7上のSNMPマネージャ71は、ノード1から受信したSNMPトラップがモジュール更新情報であるかを判定し、モジュール更新情報である場合、SNMPトラップメッセージからモジュール更新情報76を抽出し、モジュール更新情報管理機能72へ通知する。

モジュール更新情報管理機能72は、SNMPマネージャ71からモジュール更新情報76を受信すると、ネットワーク内に配備された本発明のノードのアドレスのリストをノード管理データベース74から読み込み、モジュール更新情報76の送信元のノード以外のこのリストに含まれる全てのノードへ、モジュール更新情報76を配布する。この例では、モジュール更新情報配布サーバ7は、ノード2へモジュール更新情報76を配布する。

モジュール更新情報76を受信したノード2は、図１２に示した場合と同様に動作する。

本発明は、モジュール型の構造を持ち、ファイアウォールサービスやVPNサービスを実現するための高位レイヤパケット処理機能を拡張モジュールで実現する、ルータ及びスイッチに関するものであり、情報通信業界で利用される。

本発明のノードを配備したネットワークシステムの例。 本発明のノードへの拡張モジュールの導入時の、ノード間のシーケンスの例。 本発明のノード間で送受信される拡張モジュール追加メッセージの例。 本発明のノードの機能ブロックの例。 本発明のノードの構成の例。 本発明のノードが備える内部モジュール管理テーブルの例。 本発明のノードが備える外部モジュール管理テーブルの例。 本発明のノードのモジュール管理機能部の初期化フローの例。 本発明のノードへの拡張モジュール導入時の、機能ブロック間の通信の例。 本発明のノードへの拡張モジュール導入時の、モジュール管理機能の動作フローの例。 本発明のノードへの拡張モジュール導入後の内部モジュール管理テーブルの例。 本発明のノードへの拡張モジュール導入時の、ネットワーク内の他のノードの機能ブロック間の通信の例。 本発明のノードへの拡張モジュール導入後の、ネットワーク内の他のノードのモジュール管理機能部の動作フローの例。 本発明のノードへの拡張モジュール導入後の、ネットワーク内の他のノードの外部モジュール管理テーブルの例。 本発明のノードへの拡張モジュール導入時の、ネットワーク内の他のノードへのモジュール更新情報広告の他の実施方法の概要。 本発明のノードへの管理者による構成定義の投入あるいは更新時の、機能ブロック間の通信の例。 管理者が本発明のノードへ投入する構成定義の例。 管理者が本発明のノードの構成定義を更新した場合のフロー管理機能部の動作フローの例。 本発明のノードへの拡張モジュール導入後の、機能ブロック間の通信の例。 本発明のノードへの拡張モジュール導入後の、フロー管理機能部の動作フローの例。 本発明のノードへの拡張モジュール導入後の、本発明のノードのフロー管理テーブルの例。 ネットワーク内の本発明のノードへの拡張モジュール導入後の、ノードの機能ブロック間の通信の例。 ネットワーク内の本発明のノードへの拡張モジュール導入後の、フロー管理機能部の動作フローの例。 本発明のノードへの拡張モジュール導入後の、ネットワーク内の他のノードのフロー管理テーブルの例。 本発明のノードが受信パケットを拡張モジュールを配備した本発明のノードに転送する場合のネットワークシステムの動作の概要。 拡張モジュールを配備した本発明のノードが本発明のノードに受信パケットを返信する場合のネットワークシステムの動作の概要。 本発明のノード間で受信フローを転送する場合のパケットフォーマットの例。 拡張モジュールを配備した本発明のノードでパケットを内部転送する場合のパケットフォーマットの例。 本発明のノードが端末からパケットを受信した場合の機能ブロック間の通信の例。 拡張モジュールを配備した本発明のノードがネットワーク内の他のノードから転送されたパケットを受信する場合の機能ブロック間の通信の例。 本発明のノードがパケットを受信した場合の、パケット／フレーム転送機能部の動作フローの例。 拡張モジュールを配備した本発明のノードがネットワーク内に複数配備されている場合の、ネットワーク構成とノード間パケット転送の概要。 拡張モジュールを配備した本発明のノードがネットワーク内に複数配備されている場合の、内部モジュール管理テーブルの例。 拡張モジュールを配備した本発明のノードがネットワーク内に複数配備されている場合の、外部モジュール管理テーブルの例。 拡張モジュールを配備した本発明のノードがネットワーク内に複数配備されている場合の、本発明のノード間のシーケンスの例。 拡張モジュールを配備した本発明のノードがネットワーク内に複数存在可能な場合の、モジュール管理情報の動作フローの例。 拡張モジュールを配備した本発明のノードがネットワーク内に複数存在可能な場合の、フロー管理機能部の動作フローの例。 本発明のスイッチを配備したネットワークシステムの例。 本発明のスイッチ間で高異例や処理対象パケットを転送するための、転送用パケットのパケットフォーマットの例。 本発明のノードによるモジュール更新情報の広告を管理サーバにより実現する実施例のネットワークの例。

符号の説明

1,2 ノード
3 コアルータ
12 URLフィルタリングモジュール
113 転送機能部上の内部モジュール管理テーブル
114 フロー管理テーブル
131 制御部上の内部モジュール管理テーブル
132 外部モジュール管理テーブル
133 構成定義
134 モジュール管理機能
135 フロー管理機能
136 構成定義管理機能。

Claims (17)

1. 他のパケット通信装置と接続され、1つまたは複数の回線インターフェースと、内部スイッチと、メモリと、拡張モジュールを導入可能なインターフェースとを備え、該回線インターフェースへの入力フローのうち所定のフローを上記拡張モジュールへ転送して該拡張モジュール上で処理可能なパケット通信装置であって、上記メモリ上に、上記拡張モジュールの内部アドレスと、該拡張モジュールの種別と、該拡張モジュールで処理するフローの条件との組み合わせをエントリとする内部モジュール管理テーブルと、
   所定の転送先に転送すべきフローの条件と、該転送先の種別の識別子と、該転送先のアドレスとの組み合わせをエントリとするフロー管理テーブルとを備え、
   上記回線インターフェースは、上記他のパケット転送装置から、パケットを受信すると、上記内部モジュール管理テーブルの検索により、該パケットが上記拡張モジュールでの処理対象であるかを調べ、処理対象である場合は前記拡張モジュールへ該パケットを内部転送し、かつ、上記拡張モジュールでパケット処理を施した該パケットを上記他のパケット通信装置へ返信することを特徴とするパケット通信装置。
2. 上記メモリ上に記憶された構成定義と、構成定義管理機能とを備え、
   上記構成定義上で拡張モジュールの利用の有無を指定可能な請求項1に記載のパケット通信装置。
3. 拡張モジュールを備えた他のパケット通信装置と接続され、回線インターフェースとCPUとメモリと入出力インターフェースと、これらを接続する内部スイッチあるいは内部バスを備えたパケット通信装置であって、上記メモリ上に、上記他のパケット通信装置の識別子と上記拡張モジュールの種別、及び該拡張モジュールで処理するフローの条件との組み合わせをエントリとする、外部モジュール管理テーブルと、所定の転送先に転送すべきフローの条件と該転送先の種別の識別子と、該転送先のアドレスとの組み合わせをエントリとするフロー管理テーブルとを備え、上記回線インターフェースは、回線インターフェースで受信したパケットのうち、上記外部モジュール管理テーブル上のエントリとフロー条件が合致するパケットを、上記他のパケット転送装置へ転送することを特徴とするパケット通信装置。
4. 上記メモリ上に記憶された構成定義と、構成定義管理機能とを備え、上記構成定義上で拡張モジュールの利用の有無を指定可能な請求項３に記載のパケット通信装置。
5. ネットワーク内に請求項1に記載のパケット通信装置と、請求項３に記載のパケット通信装置とを備え、請求項３に記載のパケット通信装置で受信したパケットに対して、請求項1に記載のパケット通信装置内の上記拡張モジュールでパケット処理を施すことを特徴とするネットワークシステム。
6. 上記拡張モジュールの追加あるいは削除が発生すると、上記内部モジュール管理テーブルを更新し、さらに拡張モジュール追加あるいは拡張モジュール削除を表す識別子と、自装置を表す識別子と、該拡張モジュールの機能種別を表す識別子との組み合わせをエントリとする拡張モジュール更新情報を、ネットワーク内の他のパケット通信装置へ送信することを特徴とする請求項1に記載のパケット通信装置。
7. OSI参照モデルのレイヤ3で定義されるリンク状態型ルーティングプロトコルの広告メッセージに上記拡張モジュール更新情報を格納してネットワーク内の他のパケット通信装置へ送信することを特徴とする請求項６に記載のパケット通信装置。
8. OSI参照モデルのレイヤ2で定義されるIEEE802.1D STP (Spanning Tree Protocol)のプロトコルメッセージに上記拡張モジュール更新情報を格納してネットワーク内の他のパケット通信装置へ送信することを特徴とする請求項６に記載のパケット通信装置。
9. OSI参照モデルのレイヤ2で定義されるIEEE802.1AB LLDP (Link Layer Discovery Protocol)のプロトコルメッセージに上記拡張モジュール更新情報を格納してネットワーク内の他のパケット通信装置へ送信することを特徴とする請求項６に記載のパケット通信装置。
10. ネットワーク内の他のパケット通信装置から該他のパケット通信装置の識別子と、該他のパケット通信装置への拡張モジュールの追加をを表す識別子と、該追加された拡張モジュールの機能種別とをエントリとする拡張モジュール追加メッセージを受信すると、上記外部モジュール管理テーブルを更新し、
    さらに上記構成定義を検査して、上記追加された拡張モジュールと拡張モジュールの種別が同一種別のエントリがあれば、該エントリの転送指定を満たすように上記フロー管理テーブルを更新することを特徴とする請求項４に記載のパケット通信装置。
11. 請求項６に記載のパケット通信装置と請求項１０に記載のパケット通信装置とをネットワーク内に備え、
    請求項６に記載のパケット通信装置への上記拡張モジュールの配備に伴い請求項１０に記載のパケット通信装置内の上記外部モジュール管理テーブルを更新することを特徴とするネットワークシステム。
12. 自装置内の上記拡張モジュールの負荷状態を取得し、該拡張モジュールの負荷状態をネットワーク内の他のパケット通信装置に送信することを特徴とする請求項６に記載のパケット通信装置。
13. あらかじめ設定された閾値を越えた場合に上記拡張モジュールの負荷状態をネットワーク内の他のパケット通信装置に送信することを特徴とする請求項１２に記載のパケット通信装置。
14. 上記外部モジュール管理テーブルの各エントリには、さらに上記拡張モジュールの負荷状態が格納されており、
    受信フローごとの転送先を上記外部モジュール管理テーブル上の同一の拡張モジュール種別を持つ各エントリの上記負荷状態をもとに決定することを特徴とする請求項１０に記載のパケット通信装置。
15. 複数の請求項１２に記載のパケット通信装置と、請求項１４に記載のパケット通信装置とをネットワーク内に備え、
    上記請求項１４に記載のパケット通信装置が上記複数の請求項１２に記載のパケット通信装置のうちどのパケット通信装置へ受信フローを転送するかを、上記請求項１２に記載のパケット通信装置内の上記拡張モジュールの負荷状態に応じて、選択することを特徴とするネットワークシステム。
16. 上記外部モジュール管理テーブルの各エントリには、さらに到達所要時間が格納されており、
    受信フローごとの転送先を上記外部モジュール管理テーブル上の同一の拡張モジュール種別を持つ各エントリの上記到達所要時間をもとに決定することを特徴とする請求項６に記載のパケット通信装置。
17. 複数の請求項１に記載のパケット通信装置と、請求項１６に記載のパケット通信装置とをネットワーク内に備え、
    上記請求項１６に記載のパケット通信装置が上記複数の請求項１に記載のパケット通信装置のうちどのパケット通信装置へ受信フローを転送するかを、上記請求項１６に記載のパケット通信装置から上記複数の請求項１に記載のパケット通信装置のそれぞれまでの上記到達所要時間に応じて選択することを特徴とするネットワークシステム。
    

Images