(57)【特許請求の範囲】
【請求項１】
複数のパケット処理ノードと、前記パケット処理ノードと通信端末との間でパケットを中継するゲートウェイ装置と、前記パケット処理ノードによるパケット転送処理を監視する監視サーバと、を備え、前記複数のパケット処理ノードが円環状の論理ネットワークを形成し、前記監視サーバがシステム内のすべてのゲートウェイ装置の情報、各ゲートウェイ装置に収容されている通信端末の情報および各ゲートウェイ装置が接続されているパケット処理ノードの情報を管理する通信システムであって、
前記パケット処理ノードは、
自身に接続されたゲートウェイ装置の識別情報およびＩＰアドレスと、当該ゲートウェイ装置経由で通信を行う各通信端末の端末識別子と、前記円環状の論理ネットワークにおいて隣接している他のパケット処理ノードの識別情報およびＩＰアドレスとを管理するための情報として、前記監視サーバとの通信結果に応じて適宜更新する経路テーブルを保持し、
自身に接続されたゲートウェイ装置経由で通信端末からパケットを受信した場合、受信したパケットの転送先のＩＰアドレスが前記経路テーブルに登録されていれば、登録されているＩＰアドレスを前記受信したパケットの宛先に設定して転送し、転送先のＩＰアドレスが登録されていなければ、円環状の論理ネットワーク上で隣接している他のパケット処理ノードのＩＰアドレスを前記パケットの宛先に設定して転送するとともに、前記パケットの宛先の通信端末の端末識別子を前記監視サーバに通知して前記パケットの転送先を問い合わせ、
前記監視サーバは、
前記パケット処理ノードからパケットの転送先の問い合わせを受けた場合、通知されてきた端末識別子に基づいて、転送先とするパケット処理ノードを特定し、特定したパケット処理ノードの識別情報およびＩＰアドレスを問い合わせ元のパケット処理ノードへ通知する
ことを特徴とする通信システム。
【請求項２】
前記パケット処理ノードは、
受信パケットの転送先とするパケット処理ノードの問い合わせに対する応答を前記監視サーバから受けた場合、当該応答にて通知されてきた識別情報およびＩＰアドレスに基づいて、前記経路テーブルを更新する
ことを特徴とする請求項１に記載の通信システム。
【請求項３】
前記パケット処理ノードは、
さらに、
円環状の論理ネットワークにおいて隣接していない他のパケット処理ノードからパケットを受信し、なおかつ当該受信パケットの宛先通信端末のＩＰアドレスが前記経路テーブルに登録されていない場合、前記監視サーバに対して、当該宛先通信端末の端末識別子を通知するとともに当該受信パケットの転送先とするパケット処理ノードを問い合わせる
ことを特徴とする請求項１または２に記載の通信システム。
【請求項４】
前記監視サーバは、
前記パケット処理ノードからパケットの転送先とするパケット処理ノードの問い合わせを受けた場合、問い合わせ元のパケット処理ノードの識別情報と、問い合わせ時に通知されてきた端末識別子の通信端末が利用するゲートウェイ装置が接続されているパケット処理ノードの識別情報と、所定の算出式とに基づいて、転送先とするパケット処理ノードを特定する
ことを特徴とする請求項１〜３のいずれか一つに記載の通信システム。
【請求項５】
前記複数のパケット処理ノードの総数をＮ、前記複数のパケット処理ノードそれぞれの識別情報を、前記円環状のネットワークにおける転送経路順に沿って、１，２，３，…，Ｎとした場合、
前記監視サーバは、
問い合わせ時に通知されてきた端末識別子の通信端末が利用するゲートウェイ装置が接続されているパケット処理ノードの識別情報をＡ、問い合わせ元のパケット処理ノードの識別情報をＢとした場合、Ａ＞Ｂであれば「Ａ−Ｂ≧２k」を満たす最大の自然数ｋを求め、一方、Ａ＜Ｂであれば「Ａ−Ｂ＋Ｎ≧２k」を満たす最大の自然数ｋを求め、当該求めた自然数ｋをＫとしたとき、Ｂ＋２K＜Ｎであれば識別情報がＢ＋２Kのパケット処理ノードを転送先に決定し、一方、Ｂ＋２K＞Ｎであれば識別情報がＢ＋２K−Ｎのパケット処理ノードを転送先に決定する
ことを特徴とする請求項４に記載の通信システム。
【請求項６】
複数のパケット処理ノードと、前記パケット処理ノードと通信端末との間でパケットを中継するゲートウェイ装置と、前記パケット処理ノードによるパケット転送処理を監視する監視サーバと、を備え、前記複数のパケット処理ノードが円環状の論理ネットワークを形成し、前記監視サーバがシステム内のすべてのゲートウェイ装置の情報、各ゲートウェイ装置に収容されている通信端末の情報および各ゲートウェイ装置が接続されているパケット処理ノードの情報を管理する通信システムの前記パケット処理ノードであって、
受信したパケットの転送先のＩＰアドレスおよび円環状の論理ネットワーク上で隣接している他のパケット処理ノードのＩＰアドレスが登録された経路テーブルを管理する経路テーブル管理モジュールと、
受信したパケットを前記経路テーブルに従って転送するパケット処理モジュールと、
を備え、
前記パケット処理モジュールは、
自身に接続されたゲートウェイ装置経由で通信端末からパケットを受信した場合、受信したパケットの転送先のＩＰアドレスが前記経路テーブルに登録されていれば、登録されているＩＰアドレスを前記受信したパケットの宛先に設定して転送し、転送先のＩＰアドレスが登録されていなければ、円環状の論理ネットワーク上で隣接している他のパケット処理ノードのＩＰアドレスを前記パケットの宛先に設定して転送するとともに、前記パケットの宛先の通信端末を前記監視サーバに通知して前記パケットの転送先を問い合わせる、
ことを特徴とするパケット処理ノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、初期状態として円環状のネットワークを形成する複数のパケット処理ノードを備えた通信システムに関する。
【背景技術】
【０００２】
近年、多彩な商品の提供や経営効率化などを目的として、大企業同士での合併や、持ち株会社の設立によりグループ企業を統合する事例が相次いでいる。統合の際には、各社が個別に構築管理していた企業内情報ネットワークを新しい組織の下で一本化することが想定される。各社が管理するデータベースの共有や業務サービスの連携が実現するとともに、通信回線やネットワーク機器を集約して運用コストの削減を図ることも可能となるからである。
【０００３】
しかしながら、企業内の情報ネットワークでは機密性が高い情報を取り扱うことが少なくなく、あらゆる通信端末が無秩序に接続されることはセキュリティ面で不適切といえる。そのため、物理的には装置集約によってコスト削減を推し進めつつ、論理的には連携が必要な端末間だけを最小限に接続できるネットワーク構成が求められる。
【０００４】
このような要求に対し特許文献１では「分散型仮想ネットワーク」として、通信グループとユーザを一意に示す識別子を入れてカプセル化したパケットを送受信することで、ネットワークに接続する端末に対して論理的なグループ構成に基づく相互アクセスの機能を実現している。同ネットワークではデータベース管理とルーティングを分散化することによって、耐障害性とスケーラビリティを兼ね備えた仮想ネットワーク通信機能を実現している。
【０００５】
また、非特許文献１では「統制型仮想ネットワーク」として、特許文献１が実現する自律分散性を活かしつつ、企業内情報ネットワークに必要な管理体制を実現する方式を示している。統制型仮想ネットワークはホスト間の接続（論理通信グループ）による「仮想ネットワーク層」、制御機器による「仮想化プラットフォーム層」、ルータやスイッチ等のネットワーク機器による「物理ネットワーク層」の３層からなり、仮想ネットワークを制御するパケット処理ノードと監視サーバは中間の仮想化プラットフォーム層で動作する。
前記非特許文献１に記載の方法により構成されるオーバレイネットワークでは、パケット処理ノードは上位の仮想ネットワーク層から送受信するホスト間のパケットをカプセル化して中継（もしくは廃棄）する機能を提供している。中継転送にはパケット処理ノードごとに割り振られた識別番号（機器ＩＤ）を使用し、パケット処理ノードは、各パケット処理ノードに与えられた識別番号を元に、他のパケット処理ノードへの転送を行うための経路表を作成し保持する。
【０００６】
特許文献１に記載のデータ通信システムでは、大規模なネットワークシステムへの展開を重視し、少ない転送回数で宛先のパケット処理ノードへ到達するために経路を多く保持する構成としている。しかしながら、企業内情報ネットワークにおいては特に初期導入コストの低減を目的として、最初は小規模なネットワークで立ち上げ、後に周辺のシステムを統合する形で拡大していくことが想定される。また、サーバ類を集中的に配置するデータセンタを所有もしくは借用しており、非特許文献１の仮想化プラットフォーム層もデータセンタ内に集約されることが想定される。
【０００７】
このような構成では、転送回数の増加はあまり問題にならない。例えば８台のパケット処理ノードを配置する場合、従来技術による方法（以下、方法１）では平均転送回数が３回（ｌｏｇ２８）であるが、８台を円環状に配置し、隣のノードへ順番に転送する方法（以下、方法２）でも平均転送回数は４回（８／２）であり、大差がない。８台のパケット処理ノードが単一のネットワークに接続されているような構成であれば、パケット処理ノード間の距離が近接しているため、転送遅延の増加も少なくて済む。むしろ、システム規模に比して大きい経路表を維持するためのコストが問題となる。方法１では各ノードが一律に他の３台（ｌｏｇ２８）のノードへの経路を保持しなければならないが、方法２であれば各ノードは他の１台に対する経路があればよい。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００７−１５８５９４号公報
【非特許文献】
【０００９】
【非特許文献１】川上、平井、大越，魚住，「統制型オーバレイネットワークの基本コンセプト」電子情報通信学会ソサイエティ大会  Ｂ−７−１２，２００９
【発明の概要】
【発明が解決しようとする課題】
【００１０】
上述したとおり、前記方法２を適用したネットワークでは、前記方法１を適用したネットワークと比較して経路表のサイズを小さくできるという利点があるが、一方で、ある１組のパケット処理ノード間で多量のトラフィックが発生すると、円環上でその２台のノードに挟まれている他の処理ノードは全て同量のトラフィックを処理しなければならなくなるという問題がある。
【００１１】
例えば、８台のパケット処理ノードをノード＃１〜ノード＃８とし、パケットの転送経路がノード＃１→ノード＃２→ノード＃３→…→ノード＃７→ノード＃８→ノード＃１であるネットワークにおいて、ノード＃１からノード＃５に向けてトラフィックが発生する場合を考える。この場合、ノード＃１はノード＃２に対する経路しかもたないため、宛先に関わらずノード＃２にパケットを転送することしかできない。ノード＃２〜＃４も同様であるから、パケットはノード＃１、＃２、＃３、＃４の順に転送されてノード＃５に到達する。従って、中間のノード＃２〜＃４で自身に関係のないトラフィックを処理するためのリソースが余分に必要となる。
【００１２】
本発明は、上記に鑑みてなされたものであって、経路表のサイズが増加するのを抑えつつネットワーク内の転送処理量を低く抑える通信システムを得ることを目的とする。
【課題を解決するための手段】
【００１３】
上述した課題を解決し、目的を達成するために、本発明は、複数のパケット処理ノードと、前記パケット処理ノードによるパケット転送処理を監視する監視サーバと、を備えた通信システムであって、前記パケット処理ノードは、初期状態においては、他のパケット処理ノードとともに円環状のネットワークを形成し、さらに、自身に接続されたゲートウェイ装置の識別情報およびＩＰアドレスと、当該ゲートウェイ装置経由で通信を行う各通信端末の端末識別子と、前記円環状のネットワークにおいて隣接している他のパケット処理ノードの識別情報およびＩＰアドレスとを管理するための情報として、前記監視サーバとの通信結果に応じて適宜更新する経路テーブルを保持しており、自身に接続されたゲートウェイ装置経由で通信端末からパケットを受信し、なおかつ当該受信パケットの宛先通信端末のＩＰアドレスが前記経路テーブルに登録されていない場合、前記監視サーバに対して、当該宛先通信端末の端末識別子を通知するとともに当該受信パケットの転送先とするパケット処理ノードを問い合わせ、前記監視サーバは、前記複数のパケット処理ノードに接続された各ゲートウェイ装置経由で通信を行うすべての通信端末の端末識別子と、当該通信端末の各々が利用するゲートウェイ装置の識別情報およびＩＰアドレスとを管理するとともに、当該ゲートウェイ装置が接続しているパケット処理ノードの識別情報およびＩＰアドレスを管理しており、前記パケット処理ノードからパケットの転送先とするパケット処理ノードの問い合わせを受けた場合、問い合わせ時に通知されてきた端末識別子に基づいて、転送先とするパケット処理ノードを特定し、特定したパケット処理ノードの識別情報およびＩＰアドレスを問い合わせ元のパケット処理ノードへ通知することを特徴とする。
【発明の効果】
【００１４】
本発明によれば、各パケット処理ノードが管理する経路テーブルのサイズが増大するのを抑えるとともに、各パケット処理ノードが取り扱うトラフィックを低減可能な通信システムを実現できる、という効果を奏する。また、システム導入時の経路管理コストを低減しつつ、将来的なシステム増大に対して柔軟に対応することが可能な通信システムを実現できる、という効果を奏する。
【図面の簡単な説明】
【００１５】
【図１】図１は、本発明にかかる通信システムの構成例を示す図である。
【図２】図２は、パケット処理ノードの構成例を示す図である。
【図３】図３は、ゲートウェイ装置の構成例を示す図である。
【図４】図４は、カプセル化パケットの構成例を示す図である。
【図５】図５は、パケット処理ノードで管理する経路テーブルの一例を示す図である。
【図６】図６は、パケット処理ノードがパケットを転送する処理手順の一例を示したフローチャートである。
【図７】図７は、図１に示した通信システムにおける通信動作の一例を示す図である。
【図８】図８は、実施の形態１の通信システムにおけるパケット処理ノードの動作手順の一例を示す図である。
【図９】図９は、監視サーバに送信する通知パケットの構成例を示す図である。
【図１０】図１０は、監視サーバの構成例を示す図である。
【図１１】図１１は、通信端末管理テーブルの構成例を示す図である。
【図１２】図１２は、ゲートウェイ装置管理テーブルの構成例を示す図である。
【図１３】図１３は、通知パケットを受信した場合に監視サーバが実行する処理手順を示したフローチャートである。
【図１４】図１４は、通知返答パケットの構成例を示す図である。
【図１５】図１５は、パケット処理ノードが通知返答パケットを受信した後の経路テーブルの構成例を示す図である。
【図１６】図１６は、実施の形態２の監視サーバの処理手順を示したフローチャートである。
【図１７】図１７は、パケット処理ノードが通知応答パケットを受けて経路テーブルを更新した場合の転送経路を示す図である。
【図１８】図１８は、実施の形態３のパケット処理ノードの処理手順を示したフローチャートである。
【図１９】図１９は、実施の形態３の通信システムにおけるパケット処理動作の一例を示す図である。
【発明を実施するための形態】
【００１６】
以下に、本発明にかかる通信システムの実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態によりこの発明が限定されるものではない。
【００１７】
実施の形態１．
図１は、本発明にかかる通信システムの構成例を示す図である。この通信システムは、初期状態として論理的に円環（リング）状に配置された複数のパケット処理ノード（パケット処理ノード１1〜１8）と、各パケット処理ノードの状態を監視する監視サーバ２と、パケット処理ノードに接続されたゲートウェイ装置３ａ，３ｂと、ゲートウェイ装置に接続された通信端末４ａ，４ｂとを含んで構成されている。各パケット処理ノードは、時計回りの方向に隣接するパケット処理ノードに対する通信経路１本を持っている（パケットの送信経路が設定されている）。例えば、パケット処理ノード１1は受信したパケットを他のパケット処理ノードに転送する場合、パケット処理ノード１2へ転送する。パケット処理ノード１8は、受信したパケットを転送する場合、パケット処理ノード１1へ転送する。なお、パケット処理ノードの数は８台以外でもよい。また、これ以降の説明においては、個々のパケット処理ノードを区別して説明する必要がない場合、すなわち、全てのパケット処理ノードに共通する事項（構成、動作など）を説明する場合、パケット処理ノード１1〜１8を総称してパケット処理ノード１と記載する。同様に、ゲートウェイ装置３ａとゲートウェイ装置３ｂを区別する必要がない場合、これらをゲートウェイ装置３と記載し、通信端末４ａと通信端末４ｂを区別する必要がない場合、これらを通信端末４と記載する。
【００１８】
監視サーバ２は、パケット処理ノード１およびゲートウェイ装置３を監視対象とするため、各機器への通信経路を持つ。また、各パケット処理ノード１はゲートウェイ装置３を介して通信端末４に接続している。図１ではパケット処理ノード１1および１7にのみゲートウェイ装置３を接続しているが、他のパケット処理ノードにも同様にゲートウェイ装置および通信端末を接続してよい。また、１台のパケット処理ノードに対して２台以上のゲートウェイ装置が接続していてもよい。
【００１９】
図２は、パケット処理ノード１の構成例を示す図である。図示したように、パケット処理ノード１は、内部にネットワークインタフェース１１、経路テーブル管理モジュール１２およびパケット処理モジュール１３を有している。ネットワークインタフェース１１は、他の通信装置、すなわち、他のパケット処理ノード１や監視サーバ２、ゲートウェイ装置３と通信するためのインタフェースである。経路テーブル管理モジュール１２は、外部から受信したパケットの転送経路を示した経路テーブルを管理している。パケット処理モジュール１３は、外部からの受信パケットの解析や外部へ送信するパケットの組み立てなどを行う。
【００２０】
図３は、ゲートウェイ装置３の構成例を示す図である。図示したように、ゲートウェイ装置３は、パケット処理ノード１側に接続するネットワークインタフェース３１と、通信端末４側に接続するネットワークインタフェース３２と、パケット処理ノード１と通信して制御メッセージをやり取りする仮想ネットワーク制御モジュール３３と、通信端末４から受信したパケットをカプセル化してパケット処理ノード１側に送り出すカプセル化モジュール３４とを備える。
【００２１】
図４は、ゲートウェイ装置３が生成するカプセル化パケットの構成例を示す図である。通常のＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）パケットはＩＰヘッダの後にペイロードが続く形式をとるが、カプセル化パケットは、両者の間に送信元端末を示す識別子（送信元端末識別子）および宛先端末を示す識別子（宛先端末識別子）を含む構成となっている。なお、ゲートウェイ装置３は、カプセル化されたパケットを受信した場合、まず、カプセル化を解く処理を行い、その結果得られたパケットを宛先の通信端末に向けて送信する。
【００２２】
図５は、パケット処理ノード１の経路テーブル管理モジュール１２で管理する経路テーブルの一例を示す図である。経路テーブル管理モジュール１２は、ゲートウェイ装置３を介して自身（自パケット処理ノード）に接続している通信端末４について、その端末識別子をキーとして、次に転送するゲートウェイ装置の識別番号（図示した「転送先」に相当）およびＩＰアドレスを記載した経路テーブルを作成して管理する。自身に接続していない（自身に接続されたゲートウェイ装置に接続していない）通信端末宛てのパケットは他のパケット処理ノードに転送するため、経路テーブルの末尾の行には宛先（端末識別子）が＊（任意）、転送先が時計回りの方向に隣接しているパケット処理ノード（図５の例では１2としている）を指すエントリを入れる。
【００２３】
各パケット処理ノード１は、パケットを受信した場合、例えば図６に示した手順に従って受信パケットを処理する。図６は、パケット処理ノード１が経路テーブル管理モジュール１２の経路テーブルを用いてパケットを転送する処理手順の一例を示したフローチャートである。パケット処理ノード１は、パケットを受信すると、まず、パケットに記載された宛先端末識別子を取得する（ステップＳ１１）。次に、表の行数を指定する変数ｎの操作を行い、後述するループ処理のために初期値１を設定する（ステップＳ１２）。次に、経路テーブルのｎ行目にあるエントリの内容を読み出し（ステップＳ１３）、読み出したエントリに記述された端末識別子と上記ステップＳ１１で取得した宛先端末識別子の値を比較する（ステップＳ１４）。比較の結果、両者が一致していれば（ステップＳ１４：Ｙｅｓ）、経路テーブルから得たＩＰアドレス宛てに（上記ステップＳ１３で読み出したエントリに記載されているＩＰアドレス宛てに）パケットを送信し（ステップＳ１５）、処理を終了する。一方、一致していなければ（ステップＳ１４：Ｎｏ）、変数ｎとテーブル全体の行数Ｎを比較する（ステップＳ１６）。比較の結果、ｎ＜Ｎの場合には（ステップＳ１６：Ｎｏ）、ｎに１を加算し（ステップＳ１７）、ステップＳ１３に戻る。一方、ｎ≧Ｎの場合（ステップＳ１６：Ｙｅｓ）テーブルの最終行、すなわち宛先任意の行（端末識別子が“＊”の行）まで検索が済んだと判断し、端末識別子が“＊”となっているエントリに記載されている転送先に対応するパケット処理ノード１宛てにパケットを送信し（ステップＳ１５）、処理を終了する。この図６に示した処理手順は、監視サーバ２を利用せずに受信パケットを処理する動作を示したものである。
【００２４】
図７は、図１に示した通信システムにおける通信動作の一例を示す図であり、具体的には、通信端末４ａを始点、通信端末４ｂを終点とする通信を行う場合のトラフィックの流れを示している。図７においてはパケットが転送される経路を太線で示している。また、パケット処理ノード１が図６に示した手順に従って動作を行った場合のパケット転送経路（監視サーバ２を利用しない場合のパケット転送経路）を示している。
【００２５】
通信端末４ａが通信端末４ｂ宛てにパケットを送信する動作では、まず、通信端末４ａから送信されたパケットはゲートウェイ装置３ａによるカプセル化処理を経てパケット処理ノード１1に到達する。パケット処理ノード１1は、ゲートウェイ装置３ａからカプセル化されたパケットを受信すると、図６に示した手順を実行してパケットを転送する。この転送処理では、まず、経路テーブル（図５参照）に記載されている各端末識別子と受信したパケットの宛先端末識別子（通信端末４ｂの端末識別子）を比較する。しかし、自身に接続されていない通信端末４ｂの端末識別子は経路テーブルに記載されていないため、検索に失敗する。この結果、パケット処理ノード１2への転送を行う。同様に、ゲートウェイ装置３ａでカプセル化された通信端末４ｂ宛てのパケットを受信したパケット処理ノード１2〜１6は、図６に示した手順をそれぞれ実行し、受信したパケットを転送する。そして、通信端末４ｂを接続しているパケット処理ノード１7で初めてゲートウェイ装置３ｂ宛てに転送され、通信端末４ｂにパケットが到達する。
【００２６】
このように、図６に示した手順に従ってパケット処理ノードが動作した場合、複数のパケット処理ノードにより構成された円環状のネットワークをパケットが転送され、パケットの宛先の通信端末がゲートウェイ装置を介して接続されているパケット処理ノードに到達する。しかしながら、このような手順でパケットを処理する場合には、既に説明したように、円環上でパケットの送信元の通信端末および宛先の通信端末が接続しているゲートウェイ装置と直接接続されている２台のパケット処理ノードに挟まれているパケット処理ノード（図７に示した例ではパケット処理ノード１2〜１6となる）は全て同量のトラフィックを処理しなければならないため、リソースの消費量が増大する。そこで、本実施の形態の通信システムにおいて、ゲートウェイ装置３から最初にパケットを受信したパケット処理ノード１（自身に接続しているゲートウェイ装置３からパケットを受信したパケット処理ノード１）は、図６に示した手順に代えて図８に示した手順で受信パケットを処理する。なお、円環上で隣接する他のパケット処理ノード１により転送されたパケットを受信したパケット処理ノード１（例えば、図１に示した通信端末４ａが通信端末４ｂ宛にパケットを送信する場合にはパケット処理ノード１2〜１6が該当する）は、図６に示した手順でパケットを処理する。
【００２７】
図８は、実施の形態１の通信システムにおけるパケット処理ノードの動作手順の一例を示す図であり、パケット処理ノードがゲートウェイ装置から直接受信したパケットを転送する場合の手順を示している。この図８に示した手順は、図６に示した処理手順にステップＳ１８を追加したものである。このステップＳ１８の処理は、ステップＳ１６においてｎ≧Ｎと判断した場合に実行する。具体的には、パケットの転送先が自身（自パケット処理ノード）に接続されているゲートウェイ装置ではない場合に実行する。ステップＳ１８では、転送しようとしているパケット（他のパケット処理ノード１やゲートウェイ装置から受信したパケット）の情報を監視サーバ２に通知することにより、パケットの転送先とするパケット処理ノードを問い合わせる。
【００２８】
図８に示したステップＳ１８の処理の詳細について説明する。図９は、ステップＳ１８の処理（監視サーバへの通知処理）において監視サーバ２に送信する通知パケットの構成例を示す図である。図９に示した通知パケットにおいて、先頭の「送信元ＩＰアドレス」には通知パケットを発信するパケット処理ノード１（通知パケットの送信元のパケット処理ノード１）のＩＰアドレスを、次の「宛先ＩＰアドレス」には監視サーバ２のＩＰアドレスをそれぞれ記載する。次の「プロトコル」はＩＰｖ４ヘッダのプロトコルフィールドを示しており、ＩＰヘッダに続くデータのプロトコルを識別するために用いられる１バイトの数値である。ＩＡＮＡ（Ｉｎｔｅｎｅｔ  Ａｓｓｉｇｎｅｄ  Ｎｕｍｂｅｒｓ  Ａｕｔｈｏｒｉｔｙ）の割り当てでは１３４〜２５４が未使用となっており、これらの未使用の値の中のいずれか１つをシステム全体で一貫的に使用する（図９に示した通知パケットでは、システム全体で一貫的に使用することに予め決定しておいた値をプロトコルフィールドに設定する）。図９の例では０ｘｆｅ（＝２５４）としている。なお、監視サーバ２は、プロトコルフィールドに予め決定しておいた値が設定されたパケットを受信した場合、受信したパケットが通知パケットであり、パケット送信元のパケット処理ノード１からパケットの転送先の問い合わせを受けたと判断する。プロトコルフィールド以降のフィールド（「送信元ＩＰアドレス」から「ペイロード」までの領域）には、図８のステップＳ１５で送信しようとしているパケット（すなわち、通知パケットの送信元パケット処理ノード１が転送しようとしているパケット、図４参照）のコピーを格納する。元のパケットが長くＩＰヘッダ（先頭の「送信元ＩＰアドレス」〜「プロトコル」までの領域）の付加によって分割が起きる場合は、ペイロードの末尾を切り捨てて１パケットに収まるようにする。パケット処理ノード１は、監視サーバ２へ送信した通知パケットに対する応答パケットを受信した場合、応答パケット内の情報に基づいて経路テーブルを更新する。なお、応答パケットの詳細については後述する。
【００２９】
図１０は、監視サーバ２の構成例を示す図である。図示したように、監視サーバ２は、パケット処理ノード１に接続するネットワークインタフェース２１と、後述する通信端末管理テーブルおよびゲートウェイ装置管理テーブルをパケット処理ノードの設定情報として管理する設定情報テーブル管理モジュール２２とを備えている。
【００３０】
図１１は、監視サーバ２の設定情報テーブル管理モジュール２２で管理する通信端末管理テーブルの構成例を示す図である。この通信端末管理テーブルは図５に示した経路テーブルに類似しているが、ゲートウェイ装置３およびパケット処理ノード１を通じて当該ネットワークに接続する全ての通信端末４に関するエントリが記載されている。また、経路テーブルの最終行に配置されていた宛先任意のエントリ（端末識別子が“＊”のエントリ）は存在しない。監視サーバ２は、ネットワーク内の各ゲートウェイ装置に対して、所定のタイミングで、ＩＰアドレス、および接続している通信端末（ゲートウェイ装置に接続されている通信端末）の端末識別子を問い合わせるなどして、通信端末管理テーブルを更新する。また、ネットワーク管理者などが必要な情報を登録して通信端末管理テーブルを更新するようにしてもよい。
【００３１】
図１２は、監視サーバ２の設定情報テーブル管理モジュール２２で管理するゲートウェイ装置管理テーブルの構成例を示す図である。このゲートウェイ装置管理テーブルには、ゲートウェイ装置３ごとに、接続しているパケット処理ノード１の識別番号およびＩＰアドレスが記載されている。すなわち、ゲートウェイ装置３の識別番号（図示した「ゲートウェイ」に相当）に対して、ゲートウェイ装置３に接続しているパケット処理ノード１の識別番号（図示した「ノード」に相当）とＩＰアドレスとが関連付けられて登録されている。このゲートウェイ装置管理テーブルの更新も上述した通信端末管理テーブルの更新と同様に、監視サーバ２がネットワーク内の各パケット処理ノードに問い合わせるなどして更新する、またはネットワーク管理者が必要な情報を登録して更新する。
【００３２】
図１３は、パケット処理モジュール１から通知パケットを受信した場合に監視サーバ２の設定情報テーブル管理モジュール２２が実行する処理手順を示したフローチャートである。監視サーバ２は、通知パケット（図９参照）を受信すると、まず、受信した通知パケットに記載されている宛先端末識別子を取得する（ステップＳ２１）。次に、取得した宛先端末識別子をキーとして通信端末管理テーブル（図１１参照）を検索し、転送先となるゲートウェイ装置の識別番号を取得する（ステップＳ２２）。なお、このステップＳ２２で取得する識別番号は、通信端末管理テーブルの「転送先」の項目に登録されている情報である。更に、ステップＳ２２で取得した識別番号をキーとしてゲートウェイ装置管理テーブル（図１２参照）を検索し、転送先となるパケット処理ノード１の識別番号を取得する（ステップＳ２３）。このステップＳ２３で取得する識別番号は、ゲートウェイ装置管理テーブルの「ノード」の項目に登録されている情報である。最後に、ステップＳ２３で得られたパケット処理ノードの識別番号を、パケットの転送先のパケット処理ノード１の識別番号として、通知元のパケット処理ノード１（通知パケットの送信元パケット処理ノード１）に通知する（ステップＳ２４）。
【００３３】
例えば、図１に示した通信端末４ａが通信端末４ｂ宛てにパケットを送信した場合、パケット処理ノード１1が監視サーバ２に対して通知パケットを送信し、監視サーバ２は、図１３に示した手順を実行し、ステップＳ２４において、パケット処理ノード１7の識別番号をパケット処理ノード１1に通知する。
【００３４】
図１４は、図１３で示したステップＳ２４において、パケット処理ノード１に送信する通知返答パケット（図９に示した通知パケットに対する応答パケットに相当）の構成例を示す図である。図１３に示した通知返答パケットにおいて、「送信元ＩＰアドレス」には監視サーバ２のＩＰアドレスを、「宛先ＩＰアドレス」には通知返答パケットの送信先となるパケット処理ノード１のＩＰアドレスをそれぞれ記載する。「プロトコル」は図９で示したプロトコルフィールドと同じものであり、システム全体で一貫した数値を用いる（図９に示した通知パケット内のプロトコルフィールドと同じ値を設定する）。「宛先端末識別子」には、通知パケットの送信元パケット処理ノード１が送信しようとしていたパケットの宛先端末の識別子を記載し、テーブル検索により得られた送信先ノードの識別番号およびＩＰアドレス（上記ステップＳ２３で取得したパケット処理ノードの識別番号およびＩＰアドレス）を、「ノード識別番号」および「ノードＩＰアドレス」にそれぞれ記載する。
【００３５】
図１５は、パケット処理ノード１が、図１３に示した処理を実行した監視サーバ２からの通知返答を受けた後（通知返答パケットを受信した後）の経路テーブル（更新後の経路テーブル）の構成例を示す図である。監視サーバ２から通知返答パケット（図１４参照）を受信したパケット処理ノード１は、パケットペイロード（図１４に示した「宛先端末識別子」〜「ノードＩＰアドレス」の領域に格納されている情報）を取り出し、端末識別子（宛先端末識別子の領域に格納されていた端末識別子）、転送先識別番号およびＩＰアドレスの組として、図５に示した経路テーブルにエントリ追加する。その結果、図１５に示した更新後の経路テーブルを得る。網掛けの行が追加したエントリとなる。この更新後の経路テーブルを用いて図８に示した処理フローを実行すると、ｎ＝３の場合におけるステップＳ１４の処理において経路テーブルの端末識別子とその前のステップＳ１１で取得した宛先端末識別子が一致し、そのエントリに書かれた転送先であるパケット処理ノード１7へパケットを転送する。これにより、それまでパケットを中継していたパケット処理ノード１2〜１6をスキップしてパケットの宛先の通信端末（この例では通信端末４ｂとなる）に接続されているパケット処理ノード１7に直接送信することが可能となる。
【００３６】
このように、本実施の形態の通信システムにおいては、各パケット処理ノード１が、自身に接続しているゲートウェイ装置からパケットを受信した場合、図８に示した手順に従って動作を行い、経路テーブルに登録されていない通信端末宛のパケットを受信した場合には、転送先とするパケット処理ノードを監視サーバ２に問い合わせ、また、監視サーバ２が図１３に示した手順に従って動作を行い、転送先とするパケット処理ノードを特定して問い合わせ元のパケット処理ノードに通知することとした。これにより、各パケット処理ノードでは、経路テーブルに登録されていない通信端末宛のパケットを新たに受信するごとに、受信したパケットの宛先の通信装置が接続しているパケット処理ノードへの経路が経路テーブルに新たに追加され、経路テーブルが更新される。従って、各パケット処理ノードは、自身に直接接続している第１のゲートウェイ装置経由で通信を行う通信端末が、自身に接続していない第２のゲートウェイ装置経由で通信を行う通信端末宛てにパケットを送信する場合、最初の送信では円環上で隣接しているパケット処理ノードに転送を行い、２回目以降の送信では、第２のゲートウェイ装置に接続しているパケット処理ノードへ直接パケットを送信できるようになる。この結果、円環上の各パケット処理ノードが管理する経路テーブルのサイズが増大するのを抑えるとともに、各パケット処理ノードが取り扱うトラフィックを低減できる。また、システム導入時の経路管理コストを低減しつつ、将来的なシステム増大に対して柔軟に対応することが可能となる。
【００３７】
実施の形態２．
つづいて、実施の形態２を説明する。なお、ネットワーク構成および各装置（パケット処理ノード，監視サーバ，ゲートウェイ装置）の構成は実施の形態１と同様である。
【００３８】
図１６は、実施の形態２の監視サーバの処理手順を示したフローチャートであり、図１３に示したフローチャートに対して、パケット処理ノード１の転送経路を集約するための処理を追加したものである。図１６に示した処理手順を実行する監視サーバ２の設定情報テーブル管理モジュール２２では、パケット処理モジュール１から通知パケット（図９参照）を受信すると、ステップＳ２１およびＳ２２を実行して転送先となるゲートウェイ装置３の識別番号を取得する。次に、実施の形態１で説明したステップＳ２３と同様に、ステップＳ２２で取得した識別番号をキーとして、ゲートウェイ装置管理テーブル（図１２参照）を検索し、その結果取得した、転送先となるパケット処理ノード１の識別番号をＡとする（ステップＳ２３ａ）。次に、通知パケットに含まれている送信元ＩＰアドレスをキーとして、ゲートウェイ装置管理テーブルを検索し、通知パケットの送信元のパケット処理ノード１の識別番号を取得し、Ｂとする（ステップＳ２５）。すなわち、ステップＳ２３ａおよびＳ２５を実行することにより、通知パケットの送信元のパケット処理ノード１の識別番号（Ｂ）、および、通知パケットの送信元のパケット処理ノード１が転送しようとしているパケットの宛先の通信装置が接続しているパケット処理ノードの識別番号（Ａ）を取得する。次に、ＡとＢの間にＡ−Ｂ≧２kの関係が成立する最大の自然数ｋを計算する（ステップＳ２６）。ただし、Ａ＜Ｂの場合には、左辺をＡ−Ｂに識別番号の上限値（円環を構成しているパケット処理ノードの数に相当、図１のネットワーク構成の場合には８となる）を加えた値とする。例えばＡ＝７、Ｂ＝１の場合にはＡ−Ｂ＝６であるからｋ＝２となり、Ａ＝２、Ｂ＝５であればＡ−Ｂ＋８＝５を左辺としてやはりｋ＝２を得る。最後に、識別番号がＢ＋２kとなるパケット処理ノード１を転送先として通知元のパケット処理ノード１（通知パケットの送信元のパケット処理ノード１）に通知返答パケットを送信する（ステップＳ２４ａ）。なお、Ｂ＋２k＞８となる場合には、識別番号がＢ＋２k−８となるパケット処理ノード１を転送先とする。
【００３９】
図１７は、上記手順を用いた場合、すなわち、パケット処理ノード１1が、受信したパケットを他のパケット処理ノードに転送する際に通知パケットを監視サーバ２へ送信し、監視サーバ２からパケット転送先のパケット処理ノードの通知（通知応答パケット）を受けて経路テーブルを更新した場合の転送経路を示す図である（便宜上、監視サーバ２、およびパケット処理ノード１から監視サーバ２への経路を省略してある）。例えば、パケット処理ノード１1〜１8の識別番号を１〜８とした場合、図１６に示した動作において、通知パケットの送信元のパケット処理ノードの識別番号をＢ＝１とすると、Ａ＝５，６，７，８のいずれであってもｋ＝２となることから、パケット処理ノード１1からパケット処理ノード１5〜１8に接続する通信端末への転送は全てパケット処理ノード１5に繋がる経路１７１を経由して転送されることになる。この結果、パケット処理ノード１2や１3、１4がトラフィックを中継する必要がなくなり、さらに、パケット処理ノード１1はパケット処理ノード１6や１7への経路をパケット処理ノード１5宛てに集約できるため、経路管理のコストを低減することが可能になる。
【００４０】
このように、本実施の形態の通信システムにおいて、監視サーバは、パケットの送信元の通信端末からゲートウェイ装置経由でパケットを受信する第１のパケット処理ノードの識別番号と、パケットの宛先の通信装置に対してゲートウェイ装置経由でパケットを転送する第２のパケット処理ノードの識別番号とに基づいて、第１のパケット処理ノードがパケットの転送先とするパケット処理ノードの識別番号を算出することとした。この場合においても、実施の形態１と同様に、円環上の各パケット処理ノードが管理する経路テーブルのサイズが増大するのを抑えるとともに、各パケット処理ノードが取り扱うトラフィックを低減できる。また、システム導入時の経路管理コストを低減しつつ、将来的なシステム増大に対して柔軟に対応することが可能となる。
【００４１】
実施の形態３．
つづいて、実施の形態３を説明する。なお、ネットワーク構成および各装置（パケット処理ノード，監視サーバ，ゲートウェイ装置）の構成は実施の形態１，２と同様である。
【００４２】
図１８は、実施の形態３のパケット処理ノードの処理手順を示したフローチャートであり、図８に示した処理手順にステップＳ１９を追加したものである。このステップＳ１９では、ステップＳ１４で「Ｙｅｓ」と判定した場合に、監視サーバ２へ通知パケットを送信するか否か（転送経路を問い合わせるか否か）を決定する。具体的には、受信したパケットの送信元ＩＰアドレスが識別番号が一つ小さいパケット処理ノード（自ノードに対して送信経路を有している隣接パケット処理ノード、例えば、パケット処理ノード１5に対してパケット処理ノード１4が該当し、パケット処理ノード１1に対してはパケット処理ノード１8が該当する）のものでない場合、すなわち、円環上で隣接しているパケット処理ノードから受信したパケットに該当しない場合（ステップＳ１９：Ｎｏ）、ステップＳ１８を実行して監視サーバに通知（通知パケットを送信）し、これに対する応答を受け取って経路テーブルを更新する。なお、監視サーバ２の処理手順は図１６に示したとおりである（監視サーバ２は実施の形態２で説明した動作を行う）。円環上で隣接するパケット処理ノード（識別番号が一つ小さいパケット処理ノード）から受信したパケットは、経路テーブルに従って、円環上で隣接しているパケット処理ノード（識別番号が一つ大きいパケット処理ノード）またはゲートウェイ装置へ転送する。
【００４３】
図１９は、実施の形態３の通信システムにおけるパケット処理動作の一例を示す図であり、図１８に示した処理手順を適用した場合の転送経路の一例を示している。なお、パケット処理ノード１1〜１8の識別番号が１〜８である場合を想定している。図１８に示した手順に従うと、パケット処理ノード１5はゲートウェイ装置、番号が一つ小さいパケット処理ノード１4のいずれにも該当しないパケット処理ノード１1からのパケットを経路１９１経由で受信するため、監視サーバ２に通知を行う。監視サーバが図１６に示した手順でＡ＝７，Ｂ＝５として計算を行うと、ｋ＝１を得る。これはパケット処理ノード１7への経路であり、パケット処理ノード１5はパケット処理ノード１7への経路１９２を経路テーブルに追加し、パケット処理ノード１6をスキップして直接送信する。
【００４４】
本実施の形態に従えば、同じ通信端末同士が通信を行うごとに、パケット処理ノード間の転送経路が追加されて経路テーブルが更新される。例えば、図１の通信端末４ａから通信端末４ｂ宛にパケットを送信する場合、最初の送信ではパケット処理ノード１1からパケット処理ノード１5への経路（図１９に示した経路１９１）がパケット処理ノード１1で保持している経路テーブルに追加され、２回目の送信ではパケット処理ノード１5からパケット処理ノード１7への経路（図１９に示した経路１９２）がパケット処理ノード１5で保持している経路テーブルに追加される。システム規模が大きい場合（円環を形成しているパケット処理ノードの数が多い場合）には、３回目以降の送信でも同様に、経路テーブルが更新される。
【００４５】
このように、本実施の形態の通信システムにおいて、パケット処理ノードは、パケットを受信した場合に、その転送経路を監視サーバに問い合わせる必要があるか否かを判断し、必要と判断した場合に問い合わせるようにしたので、実施の形態１，２と同様の効果が得られる。また、実施の形態２の場合と比較して、転送回数を少なく抑えることができる。さらに、パケット処理ノードおよび監視サーバの処理負荷が必要以上に増加するのを防止できる。
【００４６】
なお、各実施の形態では、パケット処理ノード１は、自身に接続しているゲートウェイ装置３から受信したパケットの宛先通信端末の端末識別子が経路テーブルに登録されていない場合、パケットの転送先を監視サーバ２に問い合わせるとともに円環上で隣接しているパケット処理ノードに転送を行い、監視サーバ２から通知応答パケットを受信すると経路テーブルを更新することとしたが、経路テーブルの更新が完了するのを待ち（受信パケットの転送先が監視サーバ２から通知されてくるのを待ち）待ってから、受信パケットを転送する（監視サーバ２から通知されてきた転送先のパケット処理ノードに対して転送する）ようにしてもよい。
【産業上の利用可能性】
【００４７】
以上のように、本発明にかかる通信システムは、予め保持しておいた経路テーブルに従って受信パケットを転送するパケット処理ノードを含んだ通信システムに有用であり、特に、システム導入時の経路管理コストを低く抑えつつ将来的なシステム増大に対応可能な通信システムの実現に有用である。
【符号の説明】
【００４８】
１1〜１8  パケット処理ノード
２  監視サーバ
３ａ，３ｂ  ゲートウェイ装置
４ａ，４ｂ  通信端末
１１，２１，３１，３２  ネットワークインタフェース
１２  経路テーブル管理モジュール
１３  パケット処理モジュール
２２  設定情報テーブル管理モジュール
３３  仮想ネットワーク制御モジュール
３４  カプセル化処理モジュール
【図１】
0005601992.tif 000002
【図２】
0005601992.tif 000003
【図３】
0005601992.tif 000004
【図４】
0005601992.tif 000005
【図５】
0005601992.tif 000006
【図６】
0005601992.tif 000007
【図７】
0005601992.tif 000008
【図８】
0005601992.tif 000009
【図９】
0005601992.tif 000010
【図１０】
0005601992.tif 000011
【図１１】
0005601992.tif 000012
【図１２】
0005601992.tif 000013
【図１３】
0005601992.tif 000014
【図１４】
0005601992.tif 000015
【図１５】
0005601992.tif 000016
【図１６】
0005601992.tif 000017
【図１７】
0005601992.tif 000018
【図１８】
0005601992.tif 000019
【図１９】
0005601992.tif 000020