JP5601992B2 - 通信システムおよびパケット処理ノード - Google Patents

通信システムおよびパケット処理ノード Download PDF

Info

Publication number
JP5601992B2
JP5601992B2 JP2010262472A JP2010262472A JP5601992B2 JP 5601992 B2 JP5601992 B2 JP 5601992B2 JP 2010262472 A JP2010262472 A JP 2010262472A JP 2010262472 A JP2010262472 A JP 2010262472A JP 5601992 B2 JP5601992 B2 JP 5601992B2
Authority
JP
Japan
Prior art keywords
packet
packet processing
processing node
destination
monitoring server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2010262472A
Other languages
English (en)
Other versions
JP2012114714A (ja
Inventor
肇 平井
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mitsubishi Electric Corp
Original Assignee
Mitsubishi Electric Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mitsubishi Electric Corp filed Critical Mitsubishi Electric Corp
Priority to JP2010262472A priority Critical patent/JP5601992B2/ja
Publication of JP2012114714A publication Critical patent/JP2012114714A/ja
Application granted granted Critical
Publication of JP5601992B2 publication Critical patent/JP5601992B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)

Description

本発明は、初期状態として円環状のネットワークを形成する複数のパケット処理ノードを備えた通信システムに関する。
近年、多彩な商品の提供や経営効率化などを目的として、大企業同士での合併や、持ち株会社の設立によりグループ企業を統合する事例が相次いでいる。統合の際には、各社が個別に構築管理していた企業内情報ネットワークを新しい組織の下で一本化することが想定される。各社が管理するデータベースの共有や業務サービスの連携が実現するとともに、通信回線やネットワーク機器を集約して運用コストの削減を図ることも可能となるからである。
しかしながら、企業内の情報ネットワークでは機密性が高い情報を取り扱うことが少なくなく、あらゆる通信端末が無秩序に接続されることはセキュリティ面で不適切といえる。そのため、物理的には装置集約によってコスト削減を推し進めつつ、論理的には連携が必要な端末間だけを最小限に接続できるネットワーク構成が求められる。
このような要求に対し特許文献1では「分散型仮想ネットワーク」として、通信グループとユーザを一意に示す識別子を入れてカプセル化したパケットを送受信することで、ネットワークに接続する端末に対して論理的なグループ構成に基づく相互アクセスの機能を実現している。同ネットワークではデータベース管理とルーティングを分散化することによって、耐障害性とスケーラビリティを兼ね備えた仮想ネットワーク通信機能を実現している。
また、非特許文献1では「統制型仮想ネットワーク」として、特許文献1が実現する自律分散性を活かしつつ、企業内情報ネットワークに必要な管理体制を実現する方式を示している。統制型仮想ネットワークはホスト間の接続(論理通信グループ)による「仮想ネットワーク層」、制御機器による「仮想化プラットフォーム層」、ルータやスイッチ等のネットワーク機器による「物理ネットワーク層」の3層からなり、仮想ネットワークを制御するパケット処理ノードと監視サーバは中間の仮想化プラットフォーム層で動作する。
前記非特許文献1に記載の方法により構成されるオーバレイネットワークでは、パケット処理ノードは上位の仮想ネットワーク層から送受信するホスト間のパケットをカプセル化して中継(もしくは廃棄)する機能を提供している。中継転送にはパケット処理ノードごとに割り振られた識別番号(機器ID)を使用し、パケット処理ノードは、各パケット処理ノードに与えられた識別番号を元に、他のパケット処理ノードへの転送を行うための経路表を作成し保持する。
特許文献1に記載のデータ通信システムでは、大規模なネットワークシステムへの展開を重視し、少ない転送回数で宛先のパケット処理ノードへ到達するために経路を多く保持する構成としている。しかしながら、企業内情報ネットワークにおいては特に初期導入コストの低減を目的として、最初は小規模なネットワークで立ち上げ、後に周辺のシステムを統合する形で拡大していくことが想定される。また、サーバ類を集中的に配置するデータセンタを所有もしくは借用しており、非特許文献1の仮想化プラットフォーム層もデータセンタ内に集約されることが想定される。
このような構成では、転送回数の増加はあまり問題にならない。例えば8台のパケット処理ノードを配置する場合、従来技術による方法(以下、方法1)では平均転送回数が3回(log8)であるが、8台を円環状に配置し、隣のノードへ順番に転送する方法(以下、方法2)でも平均転送回数は4回(8/2)であり、大差がない。8台のパケット処理ノードが単一のネットワークに接続されているような構成であれば、パケット処理ノード間の距離が近接しているため、転送遅延の増加も少なくて済む。むしろ、システム規模に比して大きい経路表を維持するためのコストが問題となる。方法1では各ノードが一律に他の3台(log8)のノードへの経路を保持しなければならないが、方法2であれば各ノードは他の1台に対する経路があればよい。
特開2007−158594号公報
川上、平井、大越,魚住,「統制型オーバレイネットワークの基本コンセプト」電子情報通信学会ソサイエティ大会 B−7−12,2009
上述したとおり、前記方法2を適用したネットワークでは、前記方法1を適用したネットワークと比較して経路表のサイズを小さくできるという利点があるが、一方で、ある1組のパケット処理ノード間で多量のトラフィックが発生すると、円環上でその2台のノードに挟まれている他の処理ノードは全て同量のトラフィックを処理しなければならなくなるという問題がある。
例えば、8台のパケット処理ノードをノード#1〜ノード#8とし、パケットの転送経路がノード#1→ノード#2→ノード#3→…→ノード#7→ノード#8→ノード#1であるネットワークにおいて、ノード#1からノード#5に向けてトラフィックが発生する場合を考える。この場合、ノード#1はノード#2に対する経路しかもたないため、宛先に関わらずノード#2にパケットを転送することしかできない。ノード#2〜#4も同様であるから、パケットはノード#1、#2、#3、#4の順に転送されてノード#5に到達する。従って、中間のノード#2〜#4で自身に関係のないトラフィックを処理するためのリソースが余分に必要となる。
本発明は、上記に鑑みてなされたものであって、経路表のサイズが増加するのを抑えつつネットワーク内の転送処理量を低く抑える通信システムを得ることを目的とする。
上述した課題を解決し、目的を達成するために、本発明は、複数のパケット処理ノードと、前記パケット処理ノードによるパケット転送処理を監視する監視サーバと、を備えた通信システムであって、前記パケット処理ノードは、初期状態においては、他のパケット処理ノードとともに円環状のネットワークを形成し、さらに、自身に接続されたゲートウェイ装置の識別情報およびIPアドレスと、当該ゲートウェイ装置経由で通信を行う各通信端末の端末識別子と、前記円環状のネットワークにおいて隣接している他のパケット処理ノードの識別情報およびIPアドレスとを管理するための情報として、前記監視サーバとの通信結果に応じて適宜更新する経路テーブルを保持しており、自身に接続されたゲートウェイ装置経由で通信端末からパケットを受信し、なおかつ当該受信パケットの宛先通信端末のIPアドレスが前記経路テーブルに登録されていない場合、前記監視サーバに対して、当該宛先通信端末の端末識別子を通知するとともに当該受信パケットの転送先とするパケット処理ノードを問い合わせ、前記監視サーバは、前記複数のパケット処理ノードに接続された各ゲートウェイ装置経由で通信を行うすべての通信端末の端末識別子と、当該通信端末の各々が利用するゲートウェイ装置の識別情報およびIPアドレスとを管理するとともに、当該ゲートウェイ装置が接続しているパケット処理ノードの識別情報およびIPアドレスを管理しており、前記パケット処理ノードからパケットの転送先とするパケット処理ノードの問い合わせを受けた場合、問い合わせ時に通知されてきた端末識別子に基づいて、転送先とするパケット処理ノードを特定し、特定したパケット処理ノードの識別情報およびIPアドレスを問い合わせ元のパケット処理ノードへ通知することを特徴とする。
本発明によれば、各パケット処理ノードが管理する経路テーブルのサイズが増大するのを抑えるとともに、各パケット処理ノードが取り扱うトラフィックを低減可能な通信システムを実現できる、という効果を奏する。また、システム導入時の経路管理コストを低減しつつ、将来的なシステム増大に対して柔軟に対応することが可能な通信システムを実現できる、という効果を奏する。
図1は、本発明にかかる通信システムの構成例を示す図である。 図2は、パケット処理ノードの構成例を示す図である。 図3は、ゲートウェイ装置の構成例を示す図である。 図4は、カプセル化パケットの構成例を示す図である。 図5は、パケット処理ノードで管理する経路テーブルの一例を示す図である。 図6は、パケット処理ノードがパケットを転送する処理手順の一例を示したフローチャートである。 図7は、図1に示した通信システムにおける通信動作の一例を示す図である。 図8は、実施の形態1の通信システムにおけるパケット処理ノードの動作手順の一例を示す図である。 図9は、監視サーバに送信する通知パケットの構成例を示す図である。 図10は、監視サーバの構成例を示す図である。 図11は、通信端末管理テーブルの構成例を示す図である。 図12は、ゲートウェイ装置管理テーブルの構成例を示す図である。 図13は、通知パケットを受信した場合に監視サーバが実行する処理手順を示したフローチャートである。 図14は、通知返答パケットの構成例を示す図である。 図15は、パケット処理ノードが通知返答パケットを受信した後の経路テーブルの構成例を示す図である。 図16は、実施の形態2の監視サーバの処理手順を示したフローチャートである。 図17は、パケット処理ノードが通知応答パケットを受けて経路テーブルを更新した場合の転送経路を示す図である。 図18は、実施の形態3のパケット処理ノードの処理手順を示したフローチャートである。 図19は、実施の形態3の通信システムにおけるパケット処理動作の一例を示す図である。
以下に、本発明にかかる通信システムの実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態によりこの発明が限定されるものではない。
実施の形態1.
図1は、本発明にかかる通信システムの構成例を示す図である。この通信システムは、初期状態として論理的に円環(リング)状に配置された複数のパケット処理ノード(パケット処理ノード11〜18)と、各パケット処理ノードの状態を監視する監視サーバ2と、パケット処理ノードに接続されたゲートウェイ装置3a,3bと、ゲートウェイ装置に接続された通信端末4a,4bとを含んで構成されている。各パケット処理ノードは、時計回りの方向に隣接するパケット処理ノードに対する通信経路1本を持っている(パケットの送信経路が設定されている)。例えば、パケット処理ノード11は受信したパケットを他のパケット処理ノードに転送する場合、パケット処理ノード12へ転送する。パケット処理ノード18は、受信したパケットを転送する場合、パケット処理ノード11へ転送する。なお、パケット処理ノードの数は8台以外でもよい。また、これ以降の説明においては、個々のパケット処理ノードを区別して説明する必要がない場合、すなわち、全てのパケット処理ノードに共通する事項(構成、動作など)を説明する場合、パケット処理ノード11〜18を総称してパケット処理ノード1と記載する。同様に、ゲートウェイ装置3aとゲートウェイ装置3bを区別する必要がない場合、これらをゲートウェイ装置3と記載し、通信端末4aと通信端末4bを区別する必要がない場合、これらを通信端末4と記載する。
監視サーバ2は、パケット処理ノード1およびゲートウェイ装置3を監視対象とするため、各機器への通信経路を持つ。また、各パケット処理ノード1はゲートウェイ装置3を介して通信端末4に接続している。図1ではパケット処理ノード11および17にのみゲートウェイ装置3を接続しているが、他のパケット処理ノードにも同様にゲートウェイ装置および通信端末を接続してよい。また、1台のパケット処理ノードに対して2台以上のゲートウェイ装置が接続していてもよい。
図2は、パケット処理ノード1の構成例を示す図である。図示したように、パケット処理ノード1は、内部にネットワークインタフェース11、経路テーブル管理モジュール12およびパケット処理モジュール13を有している。ネットワークインタフェース11は、他の通信装置、すなわち、他のパケット処理ノード1や監視サーバ2、ゲートウェイ装置3と通信するためのインタフェースである。経路テーブル管理モジュール12は、外部から受信したパケットの転送経路を示した経路テーブルを管理している。パケット処理モジュール13は、外部からの受信パケットの解析や外部へ送信するパケットの組み立てなどを行う。
図3は、ゲートウェイ装置3の構成例を示す図である。図示したように、ゲートウェイ装置3は、パケット処理ノード1側に接続するネットワークインタフェース31と、通信端末4側に接続するネットワークインタフェース32と、パケット処理ノード1と通信して制御メッセージをやり取りする仮想ネットワーク制御モジュール33と、通信端末4から受信したパケットをカプセル化してパケット処理ノード1側に送り出すカプセル化モジュール34とを備える。
図4は、ゲートウェイ装置3が生成するカプセル化パケットの構成例を示す図である。通常のIP(Internet Protocol)パケットはIPヘッダの後にペイロードが続く形式をとるが、カプセル化パケットは、両者の間に送信元端末を示す識別子(送信元端末識別子)および宛先端末を示す識別子(宛先端末識別子)を含む構成となっている。なお、ゲートウェイ装置3は、カプセル化されたパケットを受信した場合、まず、カプセル化を解く処理を行い、その結果得られたパケットを宛先の通信端末に向けて送信する。
図5は、パケット処理ノード1の経路テーブル管理モジュール12で管理する経路テーブルの一例を示す図である。経路テーブル管理モジュール12は、ゲートウェイ装置3を介して自身(自パケット処理ノード)に接続している通信端末4について、その端末識別子をキーとして、次に転送するゲートウェイ装置の識別番号(図示した「転送先」に相当)およびIPアドレスを記載した経路テーブルを作成して管理する。自身に接続していない(自身に接続されたゲートウェイ装置に接続していない)通信端末宛てのパケットは他のパケット処理ノードに転送するため、経路テーブルの末尾の行には宛先(端末識別子)が*(任意)、転送先が時計回りの方向に隣接しているパケット処理ノード(図5の例では12としている)を指すエントリを入れる。
各パケット処理ノード1は、パケットを受信した場合、例えば図6に示した手順に従って受信パケットを処理する。図6は、パケット処理ノード1が経路テーブル管理モジュール12の経路テーブルを用いてパケットを転送する処理手順の一例を示したフローチャートである。パケット処理ノード1は、パケットを受信すると、まず、パケットに記載された宛先端末識別子を取得する(ステップS11)。次に、表の行数を指定する変数nの操作を行い、後述するループ処理のために初期値1を設定する(ステップS12)。次に、経路テーブルのn行目にあるエントリの内容を読み出し(ステップS13)、読み出したエントリに記述された端末識別子と上記ステップS11で取得した宛先端末識別子の値を比較する(ステップS14)。比較の結果、両者が一致していれば(ステップS14:Yes)、経路テーブルから得たIPアドレス宛てに(上記ステップS13で読み出したエントリに記載されているIPアドレス宛てに)パケットを送信し(ステップS15)、処理を終了する。一方、一致していなければ(ステップS14:No)、変数nとテーブル全体の行数Nを比較する(ステップS16)。比較の結果、n<Nの場合には(ステップS16:No)、nに1を加算し(ステップS17)、ステップS13に戻る。一方、n≧Nの場合(ステップS16:Yes)テーブルの最終行、すなわち宛先任意の行(端末識別子が“*”の行)まで検索が済んだと判断し、端末識別子が“*”となっているエントリに記載されている転送先に対応するパケット処理ノード1宛てにパケットを送信し(ステップS15)、処理を終了する。この図6に示した処理手順は、監視サーバ2を利用せずに受信パケットを処理する動作を示したものである。
図7は、図1に示した通信システムにおける通信動作の一例を示す図であり、具体的には、通信端末4aを始点、通信端末4bを終点とする通信を行う場合のトラフィックの流れを示している。図7においてはパケットが転送される経路を太線で示している。また、パケット処理ノード1が図6に示した手順に従って動作を行った場合のパケット転送経路(監視サーバ2を利用しない場合のパケット転送経路)を示している。
通信端末4aが通信端末4b宛てにパケットを送信する動作では、まず、通信端末4aから送信されたパケットはゲートウェイ装置3aによるカプセル化処理を経てパケット処理ノード11に到達する。パケット処理ノード11は、ゲートウェイ装置3aからカプセル化されたパケットを受信すると、図6に示した手順を実行してパケットを転送する。この転送処理では、まず、経路テーブル(図5参照)に記載されている各端末識別子と受信したパケットの宛先端末識別子(通信端末4bの端末識別子)を比較する。しかし、自身に接続されていない通信端末4bの端末識別子は経路テーブルに記載されていないため、検索に失敗する。この結果、パケット処理ノード12への転送を行う。同様に、ゲートウェイ装置3aでカプセル化された通信端末4b宛てのパケットを受信したパケット処理ノード12〜16は、図6に示した手順をそれぞれ実行し、受信したパケットを転送する。そして、通信端末4bを接続しているパケット処理ノード17で初めてゲートウェイ装置3b宛てに転送され、通信端末4bにパケットが到達する。
このように、図6に示した手順に従ってパケット処理ノードが動作した場合、複数のパケット処理ノードにより構成された円環状のネットワークをパケットが転送され、パケットの宛先の通信端末がゲートウェイ装置を介して接続されているパケット処理ノードに到達する。しかしながら、このような手順でパケットを処理する場合には、既に説明したように、円環上でパケットの送信元の通信端末および宛先の通信端末が接続しているゲートウェイ装置と直接接続されている2台のパケット処理ノードに挟まれているパケット処理ノード(図7に示した例ではパケット処理ノード12〜16となる)は全て同量のトラフィックを処理しなければならないため、リソースの消費量が増大する。そこで、本実施の形態の通信システムにおいて、ゲートウェイ装置3から最初にパケットを受信したパケット処理ノード1(自身に接続しているゲートウェイ装置3からパケットを受信したパケット処理ノード1)は、図6に示した手順に代えて図8に示した手順で受信パケットを処理する。なお、円環上で隣接する他のパケット処理ノード1により転送されたパケットを受信したパケット処理ノード1(例えば、図1に示した通信端末4aが通信端末4b宛にパケットを送信する場合にはパケット処理ノード12〜16が該当する)は、図6に示した手順でパケットを処理する。
図8は、実施の形態1の通信システムにおけるパケット処理ノードの動作手順の一例を示す図であり、パケット処理ノードがゲートウェイ装置から直接受信したパケットを転送する場合の手順を示している。この図8に示した手順は、図6に示した処理手順にステップS18を追加したものである。このステップS18の処理は、ステップS16においてn≧Nと判断した場合に実行する。具体的には、パケットの転送先が自身(自パケット処理ノード)に接続されているゲートウェイ装置ではない場合に実行する。ステップS18では、転送しようとしているパケット(他のパケット処理ノード1やゲートウェイ装置から受信したパケット)の情報を監視サーバ2に通知することにより、パケットの転送先とするパケット処理ノードを問い合わせる。
図8に示したステップS18の処理の詳細について説明する。図9は、ステップS18の処理(監視サーバへの通知処理)において監視サーバ2に送信する通知パケットの構成例を示す図である。図9に示した通知パケットにおいて、先頭の「送信元IPアドレス」には通知パケットを発信するパケット処理ノード1(通知パケットの送信元のパケット処理ノード1)のIPアドレスを、次の「宛先IPアドレス」には監視サーバ2のIPアドレスをそれぞれ記載する。次の「プロトコル」はIPv4ヘッダのプロトコルフィールドを示しており、IPヘッダに続くデータのプロトコルを識別するために用いられる1バイトの数値である。IANA(Intenet Assigned Numbers Authority)の割り当てでは134〜254が未使用となっており、これらの未使用の値の中のいずれか1つをシステム全体で一貫的に使用する(図9に示した通知パケットでは、システム全体で一貫的に使用することに予め決定しておいた値をプロトコルフィールドに設定する)。図9の例では0xfe(=254)としている。なお、監視サーバ2は、プロトコルフィールドに予め決定しておいた値が設定されたパケットを受信した場合、受信したパケットが通知パケットであり、パケット送信元のパケット処理ノード1からパケットの転送先の問い合わせを受けたと判断する。プロトコルフィールド以降のフィールド(「送信元IPアドレス」から「ペイロード」までの領域)には、図8のステップS15で送信しようとしているパケット(すなわち、通知パケットの送信元パケット処理ノード1が転送しようとしているパケット、図4参照)のコピーを格納する。元のパケットが長くIPヘッダ(先頭の「送信元IPアドレス」〜「プロトコル」までの領域)の付加によって分割が起きる場合は、ペイロードの末尾を切り捨てて1パケットに収まるようにする。パケット処理ノード1は、監視サーバ2へ送信した通知パケットに対する応答パケットを受信した場合、応答パケット内の情報に基づいて経路テーブルを更新する。なお、応答パケットの詳細については後述する。
図10は、監視サーバ2の構成例を示す図である。図示したように、監視サーバ2は、パケット処理ノード1に接続するネットワークインタフェース21と、後述する通信端末管理テーブルおよびゲートウェイ装置管理テーブルをパケット処理ノードの設定情報として管理する設定情報テーブル管理モジュール22とを備えている。
図11は、監視サーバ2の設定情報テーブル管理モジュール22で管理する通信端末管理テーブルの構成例を示す図である。この通信端末管理テーブルは図5に示した経路テーブルに類似しているが、ゲートウェイ装置3およびパケット処理ノード1を通じて当該ネットワークに接続する全ての通信端末4に関するエントリが記載されている。また、経路テーブルの最終行に配置されていた宛先任意のエントリ(端末識別子が“*”のエントリ)は存在しない。監視サーバ2は、ネットワーク内の各ゲートウェイ装置に対して、所定のタイミングで、IPアドレス、および接続している通信端末(ゲートウェイ装置に接続されている通信端末)の端末識別子を問い合わせるなどして、通信端末管理テーブルを更新する。また、ネットワーク管理者などが必要な情報を登録して通信端末管理テーブルを更新するようにしてもよい。
図12は、監視サーバ2の設定情報テーブル管理モジュール22で管理するゲートウェイ装置管理テーブルの構成例を示す図である。このゲートウェイ装置管理テーブルには、ゲートウェイ装置3ごとに、接続しているパケット処理ノード1の識別番号およびIPアドレスが記載されている。すなわち、ゲートウェイ装置3の識別番号(図示した「ゲートウェイ」に相当)に対して、ゲートウェイ装置3に接続しているパケット処理ノード1の識別番号(図示した「ノード」に相当)とIPアドレスとが関連付けられて登録されている。このゲートウェイ装置管理テーブルの更新も上述した通信端末管理テーブルの更新と同様に、監視サーバ2がネットワーク内の各パケット処理ノードに問い合わせるなどして更新する、またはネットワーク管理者が必要な情報を登録して更新する。
図13は、パケット処理モジュール1から通知パケットを受信した場合に監視サーバ2の設定情報テーブル管理モジュール22が実行する処理手順を示したフローチャートである。監視サーバ2は、通知パケット(図9参照)を受信すると、まず、受信した通知パケットに記載されている宛先端末識別子を取得する(ステップS21)。次に、取得した宛先端末識別子をキーとして通信端末管理テーブル(図11参照)を検索し、転送先となるゲートウェイ装置の識別番号を取得する(ステップS22)。なお、このステップS22で取得する識別番号は、通信端末管理テーブルの「転送先」の項目に登録されている情報である。更に、ステップS22で取得した識別番号をキーとしてゲートウェイ装置管理テーブル(図12参照)を検索し、転送先となるパケット処理ノード1の識別番号を取得する(ステップS23)。このステップS23で取得する識別番号は、ゲートウェイ装置管理テーブルの「ノード」の項目に登録されている情報である。最後に、ステップS23で得られたパケット処理ノードの識別番号を、パケットの転送先のパケット処理ノード1の識別番号として、通知元のパケット処理ノード1(通知パケットの送信元パケット処理ノード1)に通知する(ステップS24)。
例えば、図1に示した通信端末4aが通信端末4b宛てにパケットを送信した場合、パケット処理ノード11が監視サーバ2に対して通知パケットを送信し、監視サーバ2は、図13に示した手順を実行し、ステップS24において、パケット処理ノード17の識別番号をパケット処理ノード11に通知する。
図14は、図13で示したステップS24において、パケット処理ノード1に送信する通知返答パケット(図9に示した通知パケットに対する応答パケットに相当)の構成例を示す図である。図13に示した通知返答パケットにおいて、「送信元IPアドレス」には監視サーバ2のIPアドレスを、「宛先IPアドレス」には通知返答パケットの送信先となるパケット処理ノード1のIPアドレスをそれぞれ記載する。「プロトコル」は図9で示したプロトコルフィールドと同じものであり、システム全体で一貫した数値を用いる(図9に示した通知パケット内のプロトコルフィールドと同じ値を設定する)。「宛先端末識別子」には、通知パケットの送信元パケット処理ノード1が送信しようとしていたパケットの宛先端末の識別子を記載し、テーブル検索により得られた送信先ノードの識別番号およびIPアドレス(上記ステップS23で取得したパケット処理ノードの識別番号およびIPアドレス)を、「ノード識別番号」および「ノードIPアドレス」にそれぞれ記載する。
図15は、パケット処理ノード1が、図13に示した処理を実行した監視サーバ2からの通知返答を受けた後(通知返答パケットを受信した後)の経路テーブル(更新後の経路テーブル)の構成例を示す図である。監視サーバ2から通知返答パケット(図14参照)を受信したパケット処理ノード1は、パケットペイロード(図14に示した「宛先端末識別子」〜「ノードIPアドレス」の領域に格納されている情報)を取り出し、端末識別子(宛先端末識別子の領域に格納されていた端末識別子)、転送先識別番号およびIPアドレスの組として、図5に示した経路テーブルにエントリ追加する。その結果、図15に示した更新後の経路テーブルを得る。網掛けの行が追加したエントリとなる。この更新後の経路テーブルを用いて図8に示した処理フローを実行すると、n=3の場合におけるステップS14の処理において経路テーブルの端末識別子とその前のステップS11で取得した宛先端末識別子が一致し、そのエントリに書かれた転送先であるパケット処理ノード17へパケットを転送する。これにより、それまでパケットを中継していたパケット処理ノード12〜16をスキップしてパケットの宛先の通信端末(この例では通信端末4bとなる)に接続されているパケット処理ノード17に直接送信することが可能となる。
このように、本実施の形態の通信システムにおいては、各パケット処理ノード1が、自身に接続しているゲートウェイ装置からパケットを受信した場合、図8に示した手順に従って動作を行い、経路テーブルに登録されていない通信端末宛のパケットを受信した場合には、転送先とするパケット処理ノードを監視サーバ2に問い合わせ、また、監視サーバ2が図13に示した手順に従って動作を行い、転送先とするパケット処理ノードを特定して問い合わせ元のパケット処理ノードに通知することとした。これにより、各パケット処理ノードでは、経路テーブルに登録されていない通信端末宛のパケットを新たに受信するごとに、受信したパケットの宛先の通信装置が接続しているパケット処理ノードへの経路が経路テーブルに新たに追加され、経路テーブルが更新される。従って、各パケット処理ノードは、自身に直接接続している第1のゲートウェイ装置経由で通信を行う通信端末が、自身に接続していない第2のゲートウェイ装置経由で通信を行う通信端末宛てにパケットを送信する場合、最初の送信では円環上で隣接しているパケット処理ノードに転送を行い、2回目以降の送信では、第2のゲートウェイ装置に接続しているパケット処理ノードへ直接パケットを送信できるようになる。この結果、円環上の各パケット処理ノードが管理する経路テーブルのサイズが増大するのを抑えるとともに、各パケット処理ノードが取り扱うトラフィックを低減できる。また、システム導入時の経路管理コストを低減しつつ、将来的なシステム増大に対して柔軟に対応することが可能となる。
実施の形態2.
つづいて、実施の形態2を説明する。なお、ネットワーク構成および各装置(パケット処理ノード,監視サーバ,ゲートウェイ装置)の構成は実施の形態1と同様である。
図16は、実施の形態2の監視サーバの処理手順を示したフローチャートであり、図13に示したフローチャートに対して、パケット処理ノード1の転送経路を集約するための処理を追加したものである。図16に示した処理手順を実行する監視サーバ2の設定情報テーブル管理モジュール22では、パケット処理モジュール1から通知パケット(図9参照)を受信すると、ステップS21およびS22を実行して転送先となるゲートウェイ装置3の識別番号を取得する。次に、実施の形態1で説明したステップS23と同様に、ステップS22で取得した識別番号をキーとして、ゲートウェイ装置管理テーブル(図12参照)を検索し、その結果取得した、転送先となるパケット処理ノード1の識別番号をAとする(ステップS23a)。次に、通知パケットに含まれている送信元IPアドレスをキーとして、ゲートウェイ装置管理テーブルを検索し、通知パケットの送信元のパケット処理ノード1の識別番号を取得し、Bとする(ステップS25)。すなわち、ステップS23aおよびS25を実行することにより、通知パケットの送信元のパケット処理ノード1の識別番号(B)、および、通知パケットの送信元のパケット処理ノード1が転送しようとしているパケットの宛先の通信装置が接続しているパケット処理ノードの識別番号(A)を取得する。次に、AとBの間にA−B≧2kの関係が成立する最大の自然数kを計算する(ステップS26)。ただし、A<Bの場合には、左辺をA−Bに識別番号の上限値(円環を構成しているパケット処理ノードの数に相当、図1のネットワーク構成の場合には8となる)を加えた値とする。例えばA=7、B=1の場合にはA−B=6であるからk=2となり、A=2、B=5であればA−B+8=5を左辺としてやはりk=2を得る。最後に、識別番号がB+2kとなるパケット処理ノード1を転送先として通知元のパケット処理ノード1(通知パケットの送信元のパケット処理ノード1)に通知返答パケットを送信する(ステップS24a)。なお、B+2k>8となる場合には、識別番号がB+2k−8となるパケット処理ノード1を転送先とする。
図17は、上記手順を用いた場合、すなわち、パケット処理ノード11が、受信したパケットを他のパケット処理ノードに転送する際に通知パケットを監視サーバ2へ送信し、監視サーバ2からパケット転送先のパケット処理ノードの通知(通知応答パケット)を受けて経路テーブルを更新した場合の転送経路を示す図である(便宜上、監視サーバ2、およびパケット処理ノード1から監視サーバ2への経路を省略してある)。例えば、パケット処理ノード11〜18の識別番号を1〜8とした場合、図16に示した動作において、通知パケットの送信元のパケット処理ノードの識別番号をB=1とすると、A=5,6,7,8のいずれであってもk=2となることから、パケット処理ノード11からパケット処理ノード15〜18に接続する通信端末への転送は全てパケット処理ノード15に繋がる経路171を経由して転送されることになる。この結果、パケット処理ノード12や13、14がトラフィックを中継する必要がなくなり、さらに、パケット処理ノード11はパケット処理ノード16や17への経路をパケット処理ノード15宛てに集約できるため、経路管理のコストを低減することが可能になる。
このように、本実施の形態の通信システムにおいて、監視サーバは、パケットの送信元の通信端末からゲートウェイ装置経由でパケットを受信する第1のパケット処理ノードの識別番号と、パケットの宛先の通信装置に対してゲートウェイ装置経由でパケットを転送する第2のパケット処理ノードの識別番号とに基づいて、第1のパケット処理ノードがパケットの転送先とするパケット処理ノードの識別番号を算出することとした。この場合においても、実施の形態1と同様に、円環上の各パケット処理ノードが管理する経路テーブルのサイズが増大するのを抑えるとともに、各パケット処理ノードが取り扱うトラフィックを低減できる。また、システム導入時の経路管理コストを低減しつつ、将来的なシステム増大に対して柔軟に対応することが可能となる。
実施の形態3.
つづいて、実施の形態3を説明する。なお、ネットワーク構成および各装置(パケット処理ノード,監視サーバ,ゲートウェイ装置)の構成は実施の形態1,2と同様である。
図18は、実施の形態3のパケット処理ノードの処理手順を示したフローチャートであり、図8に示した処理手順にステップS19を追加したものである。このステップS19では、ステップS14で「Yes」と判定した場合に、監視サーバ2へ通知パケットを送信するか否か(転送経路を問い合わせるか否か)を決定する。具体的には、受信したパケットの送信元IPアドレスが識別番号が一つ小さいパケット処理ノード(自ノードに対して送信経路を有している隣接パケット処理ノード、例えば、パケット処理ノード15に対してパケット処理ノード14が該当し、パケット処理ノード11に対してはパケット処理ノード18が該当する)のものでない場合、すなわち、円環上で隣接しているパケット処理ノードから受信したパケットに該当しない場合(ステップS19:No)、ステップS18を実行して監視サーバに通知(通知パケットを送信)し、これに対する応答を受け取って経路テーブルを更新する。なお、監視サーバ2の処理手順は図16に示したとおりである(監視サーバ2は実施の形態2で説明した動作を行う)。円環上で隣接するパケット処理ノード(識別番号が一つ小さいパケット処理ノード)から受信したパケットは、経路テーブルに従って、円環上で隣接しているパケット処理ノード(識別番号が一つ大きいパケット処理ノード)またはゲートウェイ装置へ転送する。
図19は、実施の形態3の通信システムにおけるパケット処理動作の一例を示す図であり、図18に示した処理手順を適用した場合の転送経路の一例を示している。なお、パケット処理ノード11〜18の識別番号が1〜8である場合を想定している。図18に示した手順に従うと、パケット処理ノード15はゲートウェイ装置、番号が一つ小さいパケット処理ノード14のいずれにも該当しないパケット処理ノード11からのパケットを経路191経由で受信するため、監視サーバ2に通知を行う。監視サーバが図16に示した手順でA=7,B=5として計算を行うと、k=1を得る。これはパケット処理ノード17への経路であり、パケット処理ノード15はパケット処理ノード17への経路192を経路テーブルに追加し、パケット処理ノード16をスキップして直接送信する。
本実施の形態に従えば、同じ通信端末同士が通信を行うごとに、パケット処理ノード間の転送経路が追加されて経路テーブルが更新される。例えば、図1の通信端末4aから通信端末4b宛にパケットを送信する場合、最初の送信ではパケット処理ノード11からパケット処理ノード15への経路(図19に示した経路191)がパケット処理ノード11で保持している経路テーブルに追加され、2回目の送信ではパケット処理ノード15からパケット処理ノード17への経路(図19に示した経路192)がパケット処理ノード15で保持している経路テーブルに追加される。システム規模が大きい場合(円環を形成しているパケット処理ノードの数が多い場合)には、3回目以降の送信でも同様に、経路テーブルが更新される。
このように、本実施の形態の通信システムにおいて、パケット処理ノードは、パケットを受信した場合に、その転送経路を監視サーバに問い合わせる必要があるか否かを判断し、必要と判断した場合に問い合わせるようにしたので、実施の形態1,2と同様の効果が得られる。また、実施の形態2の場合と比較して、転送回数を少なく抑えることができる。さらに、パケット処理ノードおよび監視サーバの処理負荷が必要以上に増加するのを防止できる。
なお、各実施の形態では、パケット処理ノード1は、自身に接続しているゲートウェイ装置3から受信したパケットの宛先通信端末の端末識別子が経路テーブルに登録されていない場合、パケットの転送先を監視サーバ2に問い合わせるとともに円環上で隣接しているパケット処理ノードに転送を行い、監視サーバ2から通知応答パケットを受信すると経路テーブルを更新することとしたが、経路テーブルの更新が完了するのを待ち(受信パケットの転送先が監視サーバ2から通知されてくるのを待ち)待ってから、受信パケットを転送する(監視サーバ2から通知されてきた転送先のパケット処理ノードに対して転送する)ようにしてもよい。
以上のように、本発明にかかる通信システムは、予め保持しておいた経路テーブルに従って受信パケットを転送するパケット処理ノードを含んだ通信システムに有用であり、特に、システム導入時の経路管理コストを低く抑えつつ将来的なシステム増大に対応可能な通信システムの実現に有用である。
1〜18 パケット処理ノード
2 監視サーバ
3a,3b ゲートウェイ装置
4a,4b 通信端末
11,21,31,32 ネットワークインタフェース
12 経路テーブル管理モジュール
13 パケット処理モジュール
22 設定情報テーブル管理モジュール
33 仮想ネットワーク制御モジュール
34 カプセル化処理モジュール

Claims (6)

  1. 複数のパケット処理ノードと、前記パケット処理ノードと通信端末との間でパケットを中継するゲートウェイ装置と、前記パケット処理ノードによるパケット転送処理を監視する監視サーバと、を備え、前記複数のパケット処理ノードが円環状の論理ネットワークを形成し、前記監視サーバがシステム内のすべてのゲートウェイ装置の情報、各ゲートウェイ装置に収容されている通信端末の情報および各ゲートウェイ装置が接続されているパケット処理ノードの情報を管理する通信システムであって、
    前記パケット処理ノードは、
    身に接続されたゲートウェイ装置の識別情報およびIPアドレスと、当該ゲートウェイ装置経由で通信を行う各通信端末の端末識別子と、前記円環状の論理ネットワークにおいて隣接している他のパケット処理ノードの識別情報およびIPアドレスとを管理するための情報として、前記監視サーバとの通信結果に応じて適宜更新する経路テーブルを保持し、
    自身に接続されたゲートウェイ装置経由で通信端末からパケットを受信した場合、受信したパケットの転送先のIPアドレスが前記経路テーブルに登録されていれば、登録されているIPアドレスを前記受信したパケットの宛先に設定して転送し、転送先のIPアドレスが登録されていなければ、円環状の論理ネットワーク上で隣接している他のパケット処理ノードのIPアドレスを前記パケットの宛先に設定して転送するとともに、前記パケットの宛先の通信端末の端末識別子を前記監視サーバに通知して前記パケットの転送先を問い合わせ、
    前記監視サーバは
    記パケット処理ノードからパケットの転送先の問い合わせを受けた場合、通知されてきた端末識別子に基づいて、転送先とするパケット処理ノードを特定し、特定したパケット処理ノードの識別情報およびIPアドレスを問い合わせ元のパケット処理ノードへ通知する
    ことを特徴とする通信システム。
  2. 前記パケット処理ノードは、
    受信パケットの転送先とするパケット処理ノードの問い合わせに対する応答を前記監視サーバから受けた場合、当該応答にて通知されてきた識別情報およびIPアドレスに基づいて、前記経路テーブルを更新する
    ことを特徴とする請求項1に記載の通信システム。
  3. 前記パケット処理ノードは、
    さらに、
    円環状の論理ネットワークにおいて隣接していない他のパケット処理ノードからパケットを受信し、なおかつ当該受信パケットの宛先通信端末のIPアドレスが前記経路テーブルに登録されていない場合、前記監視サーバに対して、当該宛先通信端末の端末識別子を通知するとともに当該受信パケットの転送先とするパケット処理ノードを問い合わせる
    ことを特徴とする請求項1または2に記載の通信システム。
  4. 前記監視サーバは、
    前記パケット処理ノードからパケットの転送先とするパケット処理ノードの問い合わせを受けた場合、問い合わせ元のパケット処理ノードの識別情報と、問い合わせ時に通知されてきた端末識別子の通信端末が利用するゲートウェイ装置が接続されているパケット処理ノードの識別情報と、所定の算出式とに基づいて、転送先とするパケット処理ノードを特定する
    ことを特徴とする請求項1〜のいずれか一つに記載の通信システム。
  5. 前記複数のパケット処理ノードの総数をN、前記複数のパケット処理ノードそれぞれの識別情報を、前記円環状のネットワークにおける転送経路順に沿って、1,2,3,…,Nとした場合、
    前記監視サーバは、
    問い合わせ時に通知されてきた端末識別子の通信端末が利用するゲートウェイ装置が接続されているパケット処理ノードの識別情報をA、問い合わせ元のパケット処理ノードの識別情報をBとした場合、A>Bであれば「A−B≧2k」を満たす最大の自然数kを求め、一方、A<Bであれば「A−B+N≧2k」を満たす最大の自然数kを求め、当該求めた自然数kをKとしたとき、B+2K<Nであれば識別情報がB+2Kのパケット処理ノードを転送先に決定し、一方、B+2K>Nであれば識別情報がB+2K−Nのパケット処理ノードを転送先に決定する
    ことを特徴とする請求項に記載の通信システム。
  6. 複数のパケット処理ノードと、前記パケット処理ノードと通信端末との間でパケットを中継するゲートウェイ装置と、前記パケット処理ノードによるパケット転送処理を監視する監視サーバと、を備え、前記複数のパケット処理ノードが円環状の論理ネットワークを形成し、前記監視サーバがシステム内のすべてのゲートウェイ装置の情報、各ゲートウェイ装置に収容されている通信端末の情報および各ゲートウェイ装置が接続されているパケット処理ノードの情報を管理する通信システムの前記パケット処理ノードであって、
    受信したパケットの転送先のIPアドレスおよび円環状の論理ネットワーク上で隣接している他のパケット処理ノードのIPアドレスが登録された経路テーブルを管理する経路テーブル管理モジュールと、
    受信したパケットを前記経路テーブルに従って転送するパケット処理モジュールと、
    を備え、
    前記パケット処理モジュールは、
    自身に接続されたゲートウェイ装置経由で通信端末からパケットを受信した場合、受信したパケットの転送先のIPアドレスが前記経路テーブルに登録されていれば、登録されているIPアドレスを前記受信したパケットの宛先に設定して転送し、転送先のIPアドレスが登録されていなければ、円環状の論理ネットワーク上で隣接している他のパケット処理ノードのIPアドレスを前記パケットの宛先に設定して転送するとともに、前記パケットの宛先の通信端末を前記監視サーバに通知して前記パケットの転送先を問い合わせる、
    ことを特徴とするパケット処理ノード。
JP2010262472A 2010-11-25 2010-11-25 通信システムおよびパケット処理ノード Expired - Fee Related JP5601992B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2010262472A JP5601992B2 (ja) 2010-11-25 2010-11-25 通信システムおよびパケット処理ノード

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2010262472A JP5601992B2 (ja) 2010-11-25 2010-11-25 通信システムおよびパケット処理ノード

Publications (2)

Publication Number Publication Date
JP2012114714A JP2012114714A (ja) 2012-06-14
JP5601992B2 true JP5601992B2 (ja) 2014-10-08

Family

ID=46498430

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010262472A Expired - Fee Related JP5601992B2 (ja) 2010-11-25 2010-11-25 通信システムおよびパケット処理ノード

Country Status (1)

Country Link
JP (1) JP5601992B2 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110753364B (zh) * 2019-10-29 2023-09-05 咪咕音乐有限公司 网络监控方法、系统、电子设备和存储介质
US20230155918A1 (en) 2020-03-17 2023-05-18 Nec Corporation Logical network construction system, gateway device, controller, and logicalnetwork construction method

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2087667A4 (en) * 2006-11-27 2015-03-04 Ericsson Telefon Ab L M METHOD AND SYSTEM FOR PROVIDING A ROUTING ARCHITECTURE FOR OVERLAY NETWORKS
CN102349268B (zh) * 2009-03-09 2015-11-25 日本电气株式会社 OpenFlow通信系统和OpenFlow通信方法

Also Published As

Publication number Publication date
JP2012114714A (ja) 2012-06-14

Similar Documents

Publication Publication Date Title
CN103534993B (zh) 连接低功率网络域的标签交换路由选择方法和装置
JP6544401B2 (ja) パケット転送装置、制御装置、通信システム、通信方法及びプログラム
CN104170331A (zh) 用于vxlan的l3网关
US9258209B2 (en) System and method for layer 3 proxy routing
US7818434B2 (en) Mobile server with multiple service connections
JPH0522345A (ja) 最大転送単位の最適値管理決定方式
WO2018195229A1 (en) Packet forwarding mechanism
WO2014087591A1 (ja) 通信システム、制御装置、通信制御方法、転送制御方法及び転送制御プログラム
WO2011140838A1 (zh) 一种m2m平台通信系统和方法
JPWO2014132967A1 (ja) 通信システム、スイッチ、制御装置、制御用チャネルの構築方法及びプログラム
CN105812257A (zh) 业务链路由管理系统及其使用方法
JP5438624B2 (ja) 通信システム、制御サーバ、フロー制御方法およびそのプログラム
WO2010109767A1 (ja) データ同期システム、データ同期方法、及び同期管理サーバ
JP5601992B2 (ja) 通信システムおよびパケット処理ノード
JP6379702B2 (ja) データ転送システム、データ転送サーバ、データ転送方法、および、プログラム
JP4599429B2 (ja) 通信システム及び通信方法
JP2006174399A (ja) グループ内通信方法、システム及び記録媒体
CN104780203A (zh) 一种基于弹性云的多点接入方法
CN104639417B (zh) 一种advpn隧道绑定公网链路的方法和装置
WO2015145953A1 (ja) 通信端末、通信方法及びプログラムを格納する記憶媒体
JP4369882B2 (ja) ルーティング方法、および、ネットワークシステム
JP2007150641A (ja) パケット通信装置及びネットワークシステム
JP3887301B2 (ja) フレーム転送ネットワーク
WO2009052626A1 (en) Mobile server with multiple service connections
JP6296736B2 (ja) 経路制御装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20130830

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20140411

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20140422

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140605

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20140722

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140819

R150 Certificate of patent or registration of utility model

Ref document number: 5601992

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees