(57)【特許請求の範囲】
【請求項１】
パケットが属する仮想ネットワークに対応する識別子に基づいてパケットを転送するための第一のエントリをコアスイッチに送信する第一の手段と、
パケットを識別するための識別ルールと、当該識別ルールで識別される受信パケットが属する仮想ネットワークに対応する前記識別子を当該受信パケットに付与する指示とを含む第二のエントリを、前記コアスイッチで構成されるネットワークの端点に設けられたエッジスイッチに対して予め送信可能な第二の手段と
を含むネットワークシステム。
【請求項２】
前記第二の手段は、前記識別子が付与された受信パケットを復元する指示を含むエントリを、前記エッジスイッチに対して予め送信する
ことを特徴とする請求項１のネットワークシステム。
【請求項３】
前記第二の手段は、前記エッジスイッチに仮想マシンが接続されたことに応じて、パケットを識別するための識別ルールと、当該識別ルールで識別される受信パケットが属する仮想ネットワークに対応する前記識別子を当該受信パケットに付与する指示とを含む第二のエントリを、前記エッジスイッチに対して予め送信する
ことを特徴とする請求項１または２のネットワークシステム。
【請求項４】
パケットが属する仮想ネットワークに対応する識別子に基づいてパケットを転送するための第一のエントリをコアスイッチに送信する第一の手段と、
パケットを識別するための識別ルールと、当該識別ルールで識別される受信パケットが属する仮想ネットワークに対応する前記識別子を当該受信パケットに付与する指示とを含む第二のエントリを、前記コアスイッチで構成されるネットワークの端点に設けられたエッジスイッチに対して予め送信可能な第二の手段と
を含むコントローラ。
【請求項５】
前記第二の手段は、前記識別子が付与された受信パケットを復元する指示を含むエントリを、前記エッジスイッチに対して予め送信する
ことを特徴とする請求項４のコントローラ。
【請求項６】
前記第二の手段は、前記エッジスイッチに仮想マシンが接続されたことに応じて、パケットを識別するための識別ルールと、当該識別ルールで識別される受信パケットが属する仮想ネットワークに対応する前記識別子を当該受信パケットに付与する指示とを含む第二のエントリを、前記エッジスイッチに対して予め送信する
ことを特徴とする請求項４または５のコントローラ。
【請求項７】
パケットが属する仮想ネットワークに対応する識別子に基づいてパケットを転送するための第一のエントリをコアスイッチに送信し、
パケットを識別するための識別ルールと、当該識別ルールで識別される受信パケットが属する仮想ネットワークに対応する前記識別子を当該受信パケットに付与する指示とを含む第二のエントリを、前記コアスイッチで構成されるネットワークの端点に設けられたエッジスイッチに対して予め送信する
ことを特徴とする通信方法。
【請求項８】
前記識別子が付与された受信パケットを復元する指示を含むエントリを、前記エッジスイッチに対して予め送信する
ことを特徴とする請求項７の通信方法。
【請求項９】
前記エッジスイッチに仮想マシンが接続されたことに応じて、パケットを識別するための識別ルールと、当該識別ルールで識別される受信パケットが属する仮想ネットワークに対応する前記識別子を当該受信パケットに付与する指示とを含む第二のエントリを、前記エッジスイッチに対して予め送信する
ことを特徴とする請求項７または８の通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークシステムに関し、特にネットワークシステムの経路制御方法に関する。
【背景技術】
【０００２】
外部のコントローラ（コントロールプレーン）からスイッチや端末等（ユーザプレーン）を制御する方式をＣＵ（Ｃ：コントロールプレーン／Ｕ：ユーザプレーン）分離型アーキテクチャと呼ぶ。このようなＣＵ分離型アーキテクチャに基づく構成のネットワークをＣＵ分離型ネットワークと呼ぶ。
【０００３】
ＣＵ分離型ネットワークの一例として、コントローラからスイッチを制御してネットワークの経路制御を行うオープンフロー（ＯｐｅｎＦｌｏｗ）技術を利用したオープンフローネットワークが挙げられる。なお、オープンフローネットワークは一例に過ぎない。
【０００４】
［オープンフローネットワークの説明］
オープンフローネットワークでは、ＯＦＣ（ＯｐｅｎＦｌｏｗ  Ｃｏｎｔｒｏｌｌｅｒ）等のコントローラが、ＯＦＳ（ＯｐｅｎＦｌｏｗ  Ｓｗｉｔｃｈ）等のスイッチのフローテーブルを操作することによりスイッチの挙動を制御する。
【０００５】
フローテーブルとは、所定のマッチ条件（ルール）に適合するパケット（通信データ）に対して行うべき所定の処理内容（アクション）を定義したエントリ（ｅｎｔｒｙ）が登録されたテーブルである。パケットは、フレームと読み替えても良い。ルールに適合するパケット群（パケット系列）をフロー（Ｆｌｏｗ）と呼ぶ。
【０００６】
フローのルールは、パケットの各プロトコル階層のヘッダ領域（フィールド）に含まれる宛先アドレス（ＤＡ：Ｄｅｓｔｉｎａｔｉｏｎ  Ａｄｄｒｅｓｓ）、送信元アドレス（ＳＡ：Ｓｏｕｒｃｅ  Ａｄｄｒｅｓｓ）、宛先ポート（ＤＰ：Ｄｅｓｔｉｎａｔｉｏｎ  Ｐｏｒｔ）、送信元ポート（ＳＰ：Ｓｏｕｒｃｅ  Ｐｏｒｔ）のいずれか又は全てを用いた様々な組み合わせにより定義され、区別可能である。なお、上記のアドレスには、ＭＡＣアドレス（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ａｄｄｒｅｓｓ）やＩＰアドレス（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ  Ａｄｄｒｅｓｓ）を含むものとする。また、上記に加えて、入口ポート（Ｉｎｇｒｅｓｓ  Ｐｏｒｔ）の情報も、フローのルールとして使用可能である。
【０００７】
フローのアクションは、通常、所定の転送先へのパケット転送である。無論、フローのアクションとして、パケット破棄を指定することも可能である。
【０００８】
オープンフローネットワークでは、通常、スイッチは、該当するエントリがないパケットを受信した場合、コントローラに対して、当該パケットについての問い合わせ（エントリ要求）を送信する。通常、スイッチは、当該パケットについての問い合わせとして、当該パケットをコントローラに転送する。
【０００９】
オープンフローネットワークでは、通常、コントローラは、セキュアチャネル（Ｓｅｃｕｒｅ  Ｃｈａｎｎｅｌ）接続で、管理下にあるスイッチと接続されている。コントローラは、管理下にあるスイッチからパケットについての問い合わせを受けた場合、当該パケット群（フロー）の経路（パス）を計算し、この経路に基づき、当該スイッチのフローテーブルに、「当該パケット群（フロー）を所定の転送先へ転送する」という旨のエントリを登録する。このとき、コントローラは、当該エントリをフローテーブルに登録するための制御メッセージを、スイッチに対して送信する。
【００１０】
オープンフロー技術の詳細については、非特許文献１、２に記載されている。
【先行技術文献】
【非特許文献】
【００１１】
【非特許文献１】“ＴｈｅＯｐｅｎＦｌｏｗＳｗｉｔｃｈＣｏｎｓｏｒｔｉｕｍ”＜ｈｔｔｐ：／／ｗｗｗ．ｏｐｅｎｆｌｏｗｓｗｉｔｃｈ．ｏｒｇ／＞
【非特許文献２】“ＯｐｅｎＦｌｏｗＳｗｉｔｃｈＳｐｅｃｉｆｉｃａｔｉｏｎＶｅｒｓｉｏｎ１．０．０（ＷｉｒｅＰｒｏｔｏｃｏｌ０ｘ０１）Ｄｅｃｅｍｂｅｒ３１，２００９”＜ｈｔｔｐ：／／ｗｗｗ．ｏｐｅｎｆｌｏｗｓｗｉｔｃｈ．ｏｒｇ／ｄｏｃｕｍｅｎｔｓ／ｏｐｅｎｆｌｏｗ−ｓｐｅｃ−ｖ１．０．０．ｐｄｆ＞
【発明の概要】
【００１２】
オープンフロー技術において、スイッチのフローテーブルにエントリを登録する方式は、大きく「Ｐｒｏａｃｔｉｖｅ型」と、「Ｒｅａｃｔｉｖｅ型」の２つの方式に分けられる。
【００１３】
「Ｐｒｏａｃｔｉｖｅ型」では、コントローラが「事前に」（データ通信が始まる前に）所定のパケット群（フロー）の経路（パス）を計算し、スイッチのフローテーブルにエントリを登録する。すなわち、ここでいう「Ｐｒｏａｃｔｉｖｅ型」とは、コントローラが自発的に行う「事前のエントリ登録」を指す。
【００１４】
「Ｒｅａｃｔｉｖｅ型」では、コントローラが「スイッチから１ｓｔパケット（該当エントリがない新規のパケット）についての問い合わせを受けた際に」当該パケット群（フロー）の経路を計算し、スイッチのフローテーブルにエントリを登録する。すなわち、ここでいう「Ｒｅａｃｔｉｖｅ型」とは、実際のデータ通信時に、コントローラがスイッチからの問い合わせに応じて行う「リアルタイムのエントリ登録」を指す。
【００１５】
オープンフローネットワークでは、基本的に、コントローラがスイッチから１ｓｔパケットについての問い合わせを受けた際に当該受信パケットに関するエントリを登録する「Ｒｅａｃｔｉｖｅ型」が中心となっている。
【００１６】
しかし、実際のハードウェア（ＨＷ）では、フローテーブルの処理頻度を軽減し性能の問題を解決するためには、「Ｐｒｏａｃｔｉｖｅ型」が好適であると考えられる。例えば、大量の１ｓｔパケットがコントローラに到着しても処理し切れるようにするためには、Ｐｒｏａｃｔｉｖｅ型の方が好適であると考えられる。但し、実際には、完全なＰｒｏａｃｔｉｖｅ型にするとエントリ数が膨大になると考えられるため、一部をＲｅａｃｔｉｖｅ型にすることにより、エントリ数の制約から逃れるといったことも考えられる。
【００１７】
また、「Ｐｒｏａｃｔｉｖｅ型」を用いれば、通信開始前にフローを定義できるため、Ｎｉｍｄａ等のウィルスによる大量フロー発生問題や、不明なパケットによる不正アクセス等が回避可能になると考えられる。
【００１８】
従って、オープンフローネットワークにおいて、「Ｐｒｏａｃｔｉｖｅ型」を実現するための具体的な方式が求められる。
【００１９】
本発明に係るネットワークシステムは、複数のスイッチと、コントローラとを含む。複数のスイッチの各々は、自身のフローテーブルに登録されたエントリのルールに適合する受信パケットに対し、エントリに定義されたアクションに従った動作を行う。コントローラは、複数のスイッチによって形成されるネットワークの物理トポロジに応じて計算された経路に固有の識別子をルールとし、所定の出力ポートからの出力をアクションとしたエントリを、複数のスイッチ間において通信が開始される前に、各スイッチに登録する。
【００２０】
本発明に係る経路制御方法では、複数のスイッチの各々において、自身のフローテーブルに登録されたエントリのルールに適合する受信パケットに対し、エントリに定義されたアクションに従った動作を行う。また、コントローラにおいて、複数のスイッチによって形成されるネットワークの物理トポロジに応じて計算された経路に固有の識別子をルールとし、所定の出力ポートからの出力をアクションとしたエントリを、複数のスイッチ間において通信が開始される前に、各スイッチに登録する。
【００２１】
本発明に係るプログラムは、上記の経路制御方法におけるコントローラの動作を、計算機に実行させるためのプログラムである。なお、本発明に係るプログラムは、記憶装置や記憶媒体に格納することが可能である。
【００２２】
これにより、オープンフローネットワークにおいて、「Ｐｒｏａｃｔｉｖｅ型」を実現し、ハードウェア（ＨＷ）の性能の問題を解決することができる。
【図面の簡単な説明】
【００２３】
【図１】本発明に係るネットワークシステムの構成例を示す図である。
【図２】トポロジ検知の際の処理を説明するための図である。
【図３】ステーション検知（ＡＲＰリクエスト（要求）利用）の際の処理を説明するための図である。
【図４】ステーション検知（ＡＲＰリプライ（応答）利用）の際の処理を説明するための図である。
【図５】エントリ登録完了後のデータ通信の際の処理を説明するための図である。
【図６】コントローラへのパケットの問い合わせの際の処理を説明するための図である。
【発明を実施するための形態】
【００２４】
本発明は、ＣＵ分離型ネットワークを対象としている。ここでは、ＣＵ分離型ネットワークの１つであるオープンフローネットワークを例に説明する。但し、実際には、オープンフローネットワークに限定されない。
【００２５】
＜第１実施形態＞
以下に、本発明の第１実施形態について添付図面を参照して説明する。
【００２６】
［基本構成］
図１に示すように、本発明に係るネットワークシステムは、スイッチ１０（１０−ｉ、ｉ＝１〜ｎ：ｎはスイッチ台数）と、コントローラ２０を含む。
【００２７】
スイッチ１０（１０−ｉ、ｉ＝１〜ｎ）、及びコントローラ２０は、オープンフローネットワークを形成する。スイッチ１０（１０−ｉ、ｉ＝１〜ｎ）は、オープンフローネットワークにおけるノード（ｎｏｄｅ）である。
【００２８】
［スイッチ］
スイッチ１０（１０−ｉ、ｉ＝１〜ｎ）は、内部にフローテーブルを持ち、コントローラ２０からフローテーブルに登録されたエントリに従って、パケットを転送する。
【００２９】
［コントローラ］
コントローラ２０は、トポロジ（ｔｏｐｏｌｏｇｙ：ネットワークの接続形態）検知を行い、ネットワークを構成するスイッチ１０（１０−ｉ、ｉ＝１〜ｎ）を検知し、フロー毎の経路（パス）を計算する。これにより、コントローラ２０は、ネットワークを構成する全てのスイッチの識別情報（スイッチＩＤ、ＭＡＣアドレス等）、及び各スイッチの接続形態を認識し、各スイッチの次段のスイッチを特定する。
【００３０】
ここでは、コントローラ２０は、通信が開始される前に、各スイッチのスイッチＩＤ（６４ビット）と独自に定義したノードＩＤ（１６ビット）とを１対１で対応付ける。但し、ビット数は一例に過ぎない。すなわち、コントローラ２０は、各スイッチにノードＩＤを割り当てる。また、コントローラ２０は、端末接続可能なエッジスイッチ間の経路を計算し、当該経路上の中継用スイッチであるコアスイッチ（Ｃｏｒｅ）の各々のフローテーブルに、「受信パケットの宛先情報の領域の少なくとも一部に所定のノードＩＤが記載されていれば、当該受信パケットを（所定の出力ポートから）次段のスイッチに転送する」という旨のＣｏｒｅエントリ（中継用エントリ）を登録する。すなわち、コアスイッチは、受信パケットの宛先情報の領域に記載されたノードＩＤをマッチ条件（ルール）として、転送の可否を判断する。無論、コントローラ２０は、ノードＩＤに加えて、受信パケットの宛先情報の領域に記載された他の情報もマッチ条件（ルール）として指定するようにしても良い。
【００３１】
なお、実際には、コントローラ２０は、コアスイッチ（Ｃｏｒｅ）の各々のフローテーブルに、「（ノードＩＤに関わらず、）当該受信パケットを（所定の出力ポートから）次段のスイッチに転送する」という旨のＣｏｒｅエントリを登録することも可能である。この場合、コアスイッチ（Ｃｏｒｅ）は、無条件で、受信パケットを次段のスイッチに転送する。
【００３２】
また、コントローラ２０は、ステーション検知（端末検知）を行い、端末３０（３０−ｊ、ｊ＝１〜ｍ：ｍは端末台数）を検知し、端末の宛先情報（ＭＡＣアドレス等）、及び接続形態を認識し、端末とユーザＩＤとを１対１で対応付ける。すなわち、コントローラ２０は、各端末にユーザＩＤを割り当てる。このとき、コントローラ２０は、端末３０（３０−ｊ、ｊ＝１〜ｍ）が接続されたエッジスイッチも検知する。
【００３３】
また、コントローラ２０は、通信が開始される前に、エッジスイッチのフローテーブルに、「受信パケットの宛先情報の領域の少なくとも一部に、当該エッジスイッチのノードＩＤと、配下の端末のユーザＩＤが記載されていれば、当該受信パケットの宛先情報を当該端末宛に戻し、当該受信パケットを当該端末に転送する」という旨のＥｇｒｅｓｓエントリ（出力用エントリ）を登録する。
【００３４】
ここで、配下の端末のユーザＩＤをマッチ条件（ルール）としたのは、配下の端末が複数存在する場合もあるからである。また、エッジスイッチのノードＩＤと端末のユーザＩＤとの組み合わせをマッチ条件（ルール）としているため、エッジスイッチ間で重複したユーザＩＤを使用することが可能になる。但し、同一のエッジスイッチの配下の端末の各々に対しては、重複したユーザＩＤを使用することはできない。
【００３５】
また、コントローラ２０は、入力側エッジスイッチ（Ｉｎｇｒｅｓｓ）のフローテーブルに、「所定のパケットを受信した際、宛先情報を検索のキーとして使用し、受信パケットの宛先情報の領域の少なくとも一部に、出力側エッジスイッチ（Ｅｇｒｅｓｓ）のノードＩＤと、宛先となる端末のユーザＩＤとを記載して次段のスイッチに転送する」という旨のＩｎｇｒｅｓｓエントリ（入力用エントリ）を登録する。ここで、上記の「所定のパケット」は、「所定のマッチ条件（ルール）に適合するパケット」と読み替えても良い。本発明では、入力側エッジスイッチ（Ｉｎｇｒｅｓｓ）が最初にフローを特定するため、Ｉｎｇｒｅｓｓエントリには、通常のオープンフローと同様のパケットマッチングルールと、適合したパケットに対する上記のアクションが定義されることになる。
【００３６】
［Ｉｎｇｒｅｓｓエントリ登録のタイミング］
なお、コントローラ２０が入力側エッジスイッチのフローテーブルにエントリを登録するタイミングとしては、「通信が開始される前」（事前登録）と、「実際の通信時」（リアルタイム登録）の２つが考えられる。
【００３７】
「通信が開始される前」（事前登録）の場合、コントローラ２０は、通信が開始される前に、予め所定のパケットの転送先となる端末（宛先候補端末）を決定する。そして、コントローラ２０は、通信が開始される前に、入力側エッジスイッチとなり得るエッジスイッチのフローテーブルに、「所定のパケットを受信した際、宛先情報を検索のキーとして使用し、受信パケットの宛先情報の領域の少なくとも一部に、当該宛先候補端末が接続されたエッジスイッチのノードＩＤと、当該宛先候補端末のユーザＩＤとを記載して次段のスイッチに転送する」という旨のＩｎｇｒｅｓｓエントリを登録する。本実施形態では、この事例について説明する。
【００３８】
「実際の通信時」（リアルタイム登録）の場合、コントローラ２０は、送信元の端末からパケットを受信した入力側エッジスイッチから当該受信パケットについての問い合わせを受け取ると、当該受信パケット群（フロー）の経路を計算し、この経路に基づき、当該入力側エッジスイッチのフローテーブルに、「所定のパケットを受信した際、宛先情報を検索のキーとして使用し、受信パケットの宛先情報の領域の少なくとも一部に、当該宛先候補端末が接続されたエッジスイッチのノードＩＤと、当該宛先候補端末のユーザＩＤとを記載して次段のスイッチに転送する」という旨のＩｎｇｒｅｓｓエントリを登録する。この事例については、第２実施形態にて説明する。
【００３９】
［経路の指定］
更に、各スイッチの次段のスイッチが複数存在する場合（経路が複数の場合）、コントローラ２０は、経路毎に冗長ＩＤを定義する。次段のスイッチの各々はそれぞれの経路上に存在するため、次段のスイッチの各々と冗長ＩＤとが対応付けられる。コントローラ２０は、コアスイッチ（Ｃｏｒｅ）のフローテーブルに、「受信パケットの宛先情報の領域の少なくとも一部に（所定のノードＩＤと）冗長ＩＤが記載されていれば、当該受信パケットを当該冗長ＩＤに対応する次段のスイッチに転送する」という旨のＣｏｒｅエントリを登録する。また、コントローラ２０は、入力側エッジスイッチのフローテーブルに、「所定のパケットを受信した際、宛先情報を検索のキーとして使用し、受信パケットの宛先情報の領域の少なくとも一部に、出力側エッジスイッチのノードＩＤと、冗長ＩＤと、宛先となる端末のユーザＩＤとを記載して次段のスイッチに転送する」という旨のＩｎｇｒｅｓｓエントリを登録する。冗長ＩＤは、出力側エッジスイッチのノードＩＤの一部でも良い。例えば、ノードＩＤの領域の先頭又は末尾の数ビット（ｂｉｔ）を、冗長ＩＤの領域として使用しても良い。
【００４０】
［ハードウェアの例示］
スイッチ１０（１０−ｉ、ｉ＝１〜ｎ）の例として、ネットワークスイッチ（ｎｅｔｗｏｒｋ  ｓｗｉｔｃｈ）、ルータ（ｒｏｕｔｅｒ）、プロキシ（ｐｒｏｘｙ）、ゲートウェイ（ｇａｔｅｗａｙ）、ファイアウォール（ｆｉｒｅｗａｌｌ）、ロードバランサ（ｌｏａｄ  ｂａｌａｎｃｅｒ：負荷分散装置）、帯域制御装置（ｐａｃｋｅｔ  ｓｈａｐｅｒ）、セキュリティ監視制御装置（ＳＣＡＤＡ：Ｓｕｐｅｒｖｉｓｏｒｙ  Ｃｏｎｔｒｏｌ  Ａｎｄ  Ｄａｔａ  Ａｃｑｕｉｓｉｔｉｏｎ）、ゲートキーパー（ｇａｔｅｋｅｅｐｅｒ）、基地局（ｂａｓｅ  ｓｔａｔｉｏｎ）、アクセスポイント（ＡＰ：Ａｃｃｅｓｓ  Ｐｏｉｎｔ）、通信衛星（ＣＳ：Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｓａｔｅｌｌｉｔｅ）、或いは、複数の通信ポートを有する計算機等が考えられる。また、スイッチ１０（１０−ｉ、ｉ＝１〜ｎ）は、物理マシン上に構築された仮想スイッチでも良い。
【００４１】
コントローラ２０及び端末３０（３０−ｊ、ｊ＝１〜ｍ）の各々の例として、ＰＣ（パソコン）、アプライアンス（ａｐｐｌｉａｎｃｅ）、シンクライアント端末／サーバ、ワークステーション、メインフレーム、スーパーコンピュータ等の計算機を想定している。また、コントローラ２０及び端末３０（３０−ｊ、ｊ＝１〜ｍ）は、物理マシン上に構築された仮想マシン（ＶＭ）でも良い。
【００４２】
なお、端末３０（３０−ｊ、ｊ＝１〜ｍ）の各々は、携帯電話機、スマートフォン、スマートブック、カーナビ（カーナビゲーションシステム）、携帯型ゲーム機、家庭用ゲーム機、携帯型音楽プレーヤー、ハンディターミナル、ガジェット（電子機器）、双方向テレビ、デジタルチューナー、デジタルレコーダー、情報家電（ｉｎｆｏｒｍａｔｉｏｎ  ｈｏｍｅ  ａｐｐｌｉａｎｃｅ）、ＯＡ（Ｏｆｆｉｃｅ  Ａｕｔｏｍａｔｉｏｎ）機器等でも良い。また、端末３０（３０−ｊ、ｊ＝１〜ｍ）の各々は、車両や船舶、航空機等の移動体に搭載されていても良い。
【００４３】
図示しないが、スイッチ１０（１０−ｉ、ｉ＝１〜ｎ）の各々、コントローラ２０、及び端末３０（３０−ｊ、ｊ＝１〜ｍ）の各々は、プログラムに基づいて駆動し所定の処理を実行するプロセッサと、当該プログラムや各種データを記憶するメモリと、ネットワークに接続するための通信用インターフェースによって実現される。
【００４４】
上記のプロセッサの例として、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）、マイクロプロセッサ（ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ）、マイクロコントローラ、或いは、専用の機能を有する半導体集積回路（ＩＣ：Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）等が考えられる。
【００４５】
上記のメモリの例として、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ  Ｅｒａｓａｂｌｅ  ａｎｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）やフラッシュメモリ等の半導体記憶装置、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）やＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）等の補助記憶装置、又は、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｋ）等のリムーバブルディスクや、ＳＤメモリカード（Ｓｅｃｕｒｅ  Ｄｉｇｉｔａｌ  ｍｅｍｏｒｙ  ｃａｒｄ）等の記憶媒体（メディア）等が考えられる。
【００４６】
なお、上記のプロセッサ及び上記のメモリは、一体化していても良い。例えば、近年では、マイコン等の１チップ化が進んでいる。従って、電子機器等に搭載される１チップマイコンが、プロセッサ及びメモリを備えている事例が考えられる。
【００４７】
上記の通信用インターフェースの例として、ネットワーク通信に対応した基板（マザーボード、Ｉ／Ｏボード）やチップ等の半導体集積回路、ＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）等のネットワークアダプタや同様の拡張カード、アンテナ等の通信装置、接続口（コネクタ）等の通信ポート等が考えられる。
【００４８】
また、ネットワークの例として、インターネット、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、無線ＬＡＮ（Ｗｉｒｅｌｅｓｓ  ＬＡＮ）、ＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、バックボーン（Ｂａｃｋｂｏｎｅ）、ケーブルテレビ（ＣＡＴＶ）回線、固定電話網、携帯電話網、ＷｉＭＡＸ（ＩＥＥＥ  ８０２．１６ａ）、３Ｇ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ）、専用線（ｌｅａｓｅ  ｌｉｎｅ）、ＩｒＤＡ（Ｉｎｆｒａｒｅｄ  Ｄａｔａ  Ａｓｓｏｃｉａｔｉｏｎ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、シリアル通信回線、データバス等が考えられる。
【００４９】
スイッチ１０（１０−ｉ、ｉ＝１〜ｎ）の各々、コントローラ２０、及び端末３０（３０−ｊ、ｊ＝１〜ｍ）の各々の内部の構成要素は、モジュール（ｍｏｄｕｌｅ）、コンポーネント（ｃｏｍｐｏｎｅｎｔ）、或いは専用デバイス、又はこれらの起動（呼出）プログラムでも良い。
【００５０】
但し、実際には、これらの例に限定されない。
【００５１】
［トポロジ検知］
図２を参照して、トポロジ検知の際の処理について説明する。
【００５２】
コントローラ２０は、ＬＬＤＰ（Ｌｉｎｋ  Ｌａｙｅｒ  Ｄｉｓｃｏｖｅｒｙ  Ｐｒｏｔｏｃｏｌ）によって、ネットワークの物理トポロジを検知する。ＬＬＤＰとは、制御フレームを送受信することにより定期的に隣接する装置情報を収集するためのプロトコルである。
【００５３】
事前に、管理者端末等から、スイッチ１０（１０−ｉ、ｉ＝１〜ｎ）の各々に、内向き／外向きのコンフィグ（Ｃｏｎｆｉｇｕｒａｔｉｏｎ：設定情報）を設定する。或いは、コントローラ２０が、セキュアチャネル（Ｓｅｃｕｒｅ  Ｃｈａｎｎｅｌ）接続で、管理下にあるスイッチ１０（１０−ｉ、ｉ＝１〜ｎ）の各々に、内向き／外向きのコンフィグを投入するようにしても良い。
【００５４】
「内向きのコンフィグ」とは、ネットワークの内側との通信用の設定情報である。「外向きのコンフィグ」とは、ネットワークの外側との通信用の設定情報である。
【００５５】
スイッチ１０（１０−ｉ、ｉ＝１〜ｎ）の各々は、内向き／外向きのコンフィグを、ポート（Ｐｏｒｔ）のステータス情報（ＰｏｒｔＳｔａｔ）として格納する。初期設定（ｄｅｆａｕｌｔ）では、スイッチ１０（１０−ｉ、ｉ＝１〜ｎ）の各々は、内向きのコンフィグを、ポートのステータス情報（ＰｏｒｔＳｔａｔ）として格納している。
【００５６】
コントローラ２０は、事前にスイッチ１０（１０−ｉ、ｉ＝１〜ｎ）に内向き／外向きの設定があるため、トポロジを検知するスピードが速くなる。
【００５７】
コントローラ２０は、トポロジを検知して、スイッチ１０（１０−ｉ、ｉ＝１〜ｎ）の各々が持つポートのそれぞれについて、ポートのステータス情報（ＰｏｒｔＳｔａｔ）を収集して、スイッチ１０（１０−ｉ、ｉ＝１〜ｎ）の各々が持つポートが内向きか外向きかを判断する。
【００５８】
コントローラ２０は、ポートのステータス情報において、内向きと明示的な設定のあるポートを「内向きポート」（Ｉｎｓｉｄｅ  Ｐｏｒｔ）と認識する。また、コントローラ２０は、ポートのステータス情報において、外向きと明示的な設定のあるポートを「外向きポート」（Ｏｕｔｓｉｄｅ  Ｐｏｒｔ）と認識する。
【００５９】
コントローラ２０は、内向きポート、及び外向きと明示的な設定のないポート（未設定ポート等）に対して、ＬＬＤＰの制御フレームを送信する。そして、コントローラ２０は、ＬＬＤＰの制御フレームに対する応答から、ネットワークの物理トポロジを検知し、トポロジ情報を作成する。
【００６０】
このとき、コントローラ２０は、管理下にあるスイッチ１０（１０−ｉ、ｉ＝１〜ｎ）の各々のスイッチＩＤを取得し、各スイッチ１０（１０−ｉ、ｉ＝１〜ｎ）のスイッチＩＤと、ノードＩＤとを対応付ける。このとき、ノードＩＤを対応付けるのは、外向きポートが存在するスイッチ（エッジスイッチ）のみでも良い。ここでは、スイッチＩＤとして、「ＤＰＩＤ：＃１〜＃６」を示している。なお、実際には、「ＤＰＩＤ：＃１〜＃６」をそのままノードＩＤとして使用することも可能である。
【００６１】
また、ノードＩＤは、サブノードＩＤと、冗長ＩＤを含むものとする。サブノードＩＤは、スイッチを特定するためのノードＩＤの実質的な本体である。サブノードＩＤは、単体でスイッチを特定することが可能な識別情報でも良い。或いは、サブノードＩＤは、冗長ＩＤと組み合わせることで、スイッチを一意に特定するためのノードＩＤを形成するものでも良い。冗長ＩＤは、経路を特定するための識別情報である。各スイッチ１０（１０−ｉ、ｉ＝１〜ｎ）は、この冗長ＩＤに基づいて、次段のスイッチに転送するためのポートを決定し、当該ポートから受信パケットを送出するようにしても良い。なお、実際には、冗長ＩＤは、ノードＩＤとの関連性が保たれており、冗長ＩＤとして特定可能であれば、別の領域に格納されていても良い。
【００６２】
コントローラ２０は、外向きポートが存在するスイッチ（エッジスイッチ）間の経路を計算し、当該経路上にあるコアスイッチ（Ｃｏｒｅ）のフローテーブルに、「受信パケットの宛先情報の領域の少なくとも一部に所定のノードＩＤ（外向きポートが存在するエッジスイッチのノードＩＤ）が記載されていれば、当該受信パケットを当該経路上の次段のスイッチに転送する」という旨のＣｏｒｅエントリを登録する。すなわち、コアスイッチは、受信パケットの宛先情報の領域に記載されたノードＩＤをマッチ条件（ルール）として、転送の可否を判断する。無論、コントローラ２０は、ノードＩＤに加えて、受信パケットの宛先情報の領域に記載された他の情報（ＶＴＮＩＤ、ユーザＩＤ等）もマッチ条件（ルール）として指定するようにしても良い。
【００６３】
なお、実際には、コントローラ２０は、コアスイッチ（Ｃｏｒｅ）の各々のフローテーブルに、「（ノードＩＤに関わらず、）当該受信パケットを（所定の出力ポートから）次段のスイッチに転送する」という旨のＣｏｒｅエントリを登録することも可能である。この場合、コアスイッチ（Ｃｏｒｅ）は、無条件で、受信パケットを次段のスイッチに転送する。受信パケットの転送の可否については、入力側エッジスイッチ（Ｉｎｇｒｅｓｓ）や出力側エッジスイッチ（Ｅｇｒｅｓｓ）で判断することになる。
【００６４】
ここでは、コントローラ２０は、外向きポートが存在する全てのスイッチ間の経路を計算し、当該経路上にあるコアスイッチ（Ｃｏｒｅ）のフローテーブルに、上記のようにＣｏｒｅエントリを登録する。
【００６５】
［エントリの構成例］
以下に、エントリの構成例について説明する。
エントリは、「Ｐｏｒｔ」、「ＤＡ」（Ｄｅｓｔｉｎａｔｉｏｎ  Ａｄｄｒｅｓｓ）、「ＳＡ」（Ｓｏｕｒｃｅ  Ａｄｄｒｅｓｓ）、「ＯＰｏｒｔ」（Ｏｕｔｐｕｔ  Ｐｏｒｔ）、「Ｍｏｄ」（Ｍｏｄｉｆｙ）等のデータ格納領域を含む。
【００６６】
「Ｐｏｒｔ」は、受信パケットの入力ポートを示す情報の格納領域である。「ＤＡ」は、受信パケットの宛先情報の格納領域である。「ＳＡ」は、受信パケットの送信元情報の格納領域である。「ＯＰｏｒｔ」は、受信パケットの出力ポートを示す情報の格納領域である。「Ｍｏｄ」は、受信パケットに対して行う処理を定義した情報の格納領域である。
【００６７】
「Ｐｏｒｔ」、「ＤＡ」、及び「ＳＡ」は、マッチ条件（ルール）に該当する。また、「ＯＰｏｒｔ」及び「Ｍｏｄ」は、処理内容（アクション）に該当する。
【００６８】
「ＤＡ」に格納される「ＩＤ群」とは、「ノードＩＤ」、「ＶＴＮＩＤ」、「ユーザＩＤ」等の情報である。「ノードＩＤ」は、出力側エッジスイッチとなるスイッチ（外向きポートが存在するノード）を特定するための識別情報の格納領域である。「ＶＴＮＩＤ」は、ＶＴＮ（Ｖｉｒｔｕａｌ  Ｔｅｎａｎｔ  Ｎｅｔｗｏｒｋ）等の、外向きポートが存在するスイッチ間の経路を通過するパケット群（フロー）が属するＶＮ（Ｖｉｒｔｕａｌ  Ｎｅｔｗｏｒｋ）の識別情報の格納領域である。「ユーザＩＤ」は、宛先となる端末（外向きポートが存在するスイッチに接続された／接続され得る端末）を特定するためのユーザＩＤの識別情報である。端末とユーザＩＤとの対応付けは、以下に説明する「ステーション検知」において行う。
【００６９】
［ステーション検知］
図３、図４を参照して、ステーション検知の際の処理について説明する。
【００７０】
コントローラ２０は、端末がアドレス解決のために送信するＡＲＰ（Ａｄｄｒｅｓｓ  Ｒｅｓｏｌｕｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）の制御フレームを利用して、ステーション検知を行う。
【００７１】
なお、ＡＲＰの制御フレームは一例に過ぎない。例えば、ＤＨＣＰ（Ｄｙｎａｍｉｃ  Ｈｏｓｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）等の制御フレームでも良い。また、実際には、制御フレームに限定されない。
【００７２】
ここでは、端末３０−１を「端末Ａ」とし、端末３０−２を「端末Ｂ」とする。
【００７３】
（１）ＡＲＰ＿Ｒｅｑ（ＡＲＰリクエスト（Ｒｅｑｕｅｓｔ：要求））を利用
図３に示すように、端末Ａから端末Ｂに対して通信する際に、端末ＢのＭＡＣアドレスがわからず、端末ＢのＩＰアドレスだけがわかっている場合、端末Ａは、端末Ｂのアドレスを解決するためのＡＲＰ＿Ｒｅｑ（ＡＲＰリクエスト）をブロードキャストで送信する。
【００７４】
端末Ａが接続されたエッジスイッチ１０−１は、セキュアチャネル（Ｓｅｃｕｒｅ  Ｃｈａｎｎｅｌ）接続で、コントローラ２０宛にＡＲＰ＿Ｒｅｑ（ＡＲＰリクエスト）を転送する。このとき、コントローラ２０は、ＡＲＰプロキシ（ＡＲＰ  Ｐｒｏｘｙ）として動作する。
【００７５】
コントローラ２０は、端末Ａが接続されたエッジスイッチ１０−１からＡＲＰ＿Ｒｅｑ（ＡＲＰリクエスト）を受信した際、ＡＲＰ＿Ｒｅｑ（ＡＲＰリクエスト）の送信元情報から端末ＡのＭＡＣアドレス（及びＩＰアドレス）を取得し、端末ＡにユーザＩＤを割り当てる。すなわち、端末ＡのＭＡＣアドレス（及びＩＰアドレス）と、ユーザＩＤとを対応付ける。
【００７６】
コントローラ２０は、端末Ａが接続されたエッジスイッチ１０−１のフローテーブルに、「受信パケットの宛先情報の領域の少なくとも一部に（当該エッジスイッチのノードＩＤと）配下の端末ＡのユーザＩＤが記載されていれば、当該受信パケットの宛先情報を端末ＡのＭＡＣアドレス宛に戻し、当該受信パケットを端末ＡのＭＡＣアドレス宛に転送する」という旨のＥｇｒｅｓｓエントリを登録する。
【００７７】
コントローラ２０は、ＡＲＰプロキシ（ＡＲＰ  Ｐｒｏｘｙ）として、ターゲット（Ｔａｒｇｅｔ）となる端末Ｂのアドレス解決をするため、セキュアチャネル（Ｓｅｃｕｒｅ  Ｃｈａｎｎｅｌ）接続で、管理下にあるスイッチ１０（１０−ｉ、ｉ＝１〜ｎ）の各々に対して、ＡＲＰ＿Ｒｅｑ（ＡＲＰリクエスト）をブロードキャストで送信する。このとき、ＡＲＰ＿Ｒｅｑ（ＡＲＰリクエスト）の送信元ＭＡＣアドレスは、端末ＡのＭＡＣアドレスである。
【００７８】
端末Ｂが接続されたエッジスイッチ１０−６は、ブロードキャストで送信されたＡＲＰ＿Ｒｅｑ（ＡＲＰリクエスト）を端末Ｂに転送する。
【００７９】
ここでは、説明の簡略化のため、端末Ｂのみを宛先端末として説明しているが、他の宛先端末が接続されたエッジスイッチについても、上記と同様の処理を行う。
【００８０】
（２）ＡＲＰ＿Ｒｅｐ（ＡＲＰリプライ（Ｒｅｐｌｙ：応答））を利用
図４に示すように、端末Ｂは、ＡＲＰ＿Ｒｅｑ（ＡＲＰリクエスト）に対する応答として、端末Ａ宛にＡＲＰ＿Ｒｅｐ（ＡＲＰリプライ）を送信する。
【００８１】
端末Ｂが接続されたエッジスイッチ１０−６は、セキュアチャネル（Ｓｅｃｕｒｅ  Ｃｈａｎｎｅｌ）接続で、コントローラ２０宛にＡＲＰ＿Ｒｅｐ（ＡＲＰリプライ）を転送する。このとき、コントローラ２０は、ＡＲＰプロキシ（ＡＲＰ  Ｐｒｏｘｙ）として動作する。
【００８２】
コントローラ２０は、端末Ｂが接続されたエッジスイッチ１０−６からＡＲＰ＿Ｒｅｐ（ＡＲＰリプライ）を受信した際、ＡＲＰ＿Ｒｅｐ（ＡＲＰリプライ）の送信元情報から端末ＢのＭＡＣアドレス（及びＩＰアドレス）を取得し、端末ＢにユーザＩＤを割り当てる。すなわち、端末ＢのＭＡＣアドレス（及びＩＰアドレス）と、ユーザＩＤとを対応付ける。
【００８３】
コントローラ２０は、端末Ｂが接続されたエッジスイッチ１０−６のフローテーブルに、「受信パケットの宛先情報の領域の少なくとも一部に（当該エッジスイッチのノードＩＤと）配下の端末ＢのユーザＩＤが記載されていれば、当該受信パケットの宛先情報を端末ＢのＭＡＣアドレス宛に戻し、当該受信パケットを端末ＢのＭＡＣアドレス宛に転送する」という旨のＥｇｒｅｓｓエントリを登録する。
【００８４】
この時点で、コントローラ２０は、端末Ａと端末Ｂとの間の通信が可能であると判断し、端末Ａが接続されたエッジスイッチ１０−１のフローテーブルに、「端末Ｂ宛のパケットを受信した場合、当該受信パケットの宛先情報の領域の少なくとも一部に、ＩＤ群（端末Ｂが接続されたエッジスイッチのノードＩＤと、当該フローのＶＴＮＩＤと、端末ＢのユーザＩＤ）を記載して次段のスイッチに転送する」という旨のＩｎｇｒｅｓｓエントリを登録することも可能である。このエントリ登録方式は「Ｐｒｏａｃｔｉｖｅ型」（事前にＩｎｇｒｅｓｓエントリを登録する方式）である。
【００８５】
コントローラ２０は、ＡＲＰプロキシ（ＡＲＰ  Ｐｒｏｘｙ）として、端末ＡにＡＲＰ＿Ｒｅｐ（ＡＲＰリプライ）を転送するため、セキュアチャネル（Ｓｅｃｕｒｅ  Ｃｈａｎｎｅｌ）接続で、端末Ａが接続されたエッジスイッチ１０−１に対して、ＡＲＰ＿Ｒｅｐ（ＡＲＰリプライ）を送信する。このとき、ＡＲＰ＿Ｒｅｐ（ＡＲＰリプライ）の送信元ＭＡＣアドレスは、端末ＢのＭＡＣアドレスである。
【００８６】
端末Ａが接続されたエッジスイッチ１０−１は、コントローラ２０から受信したＡＲＰ＿Ｒｅｐ（ＡＲＰリプライ）を端末Ａに転送する。
【００８７】
端末Ａは、ＡＲＰ＿Ｒｅｑ（ＡＲＰリクエスト）に対する応答として受信したＡＲＰ＿Ｒｅｐ（ＡＲＰリプライ）から、端末ＢのＭＡＣアドレスを取得する。
【００８８】
［エントリ登録完了後のデータ通信］
図５を参照して、エントリ登録完了後のスイッチ間でのＩＰパケット等の通信の際の処理について説明する。
【００８９】
この時点では、スイッチ間の全てのスイッチに対して、必要なエントリ登録は完了しているものとする。すなわち、コントローラ２０の作業は完了している。
【００９０】
まず、端末Ａは、宛先となる端末ＢのＭＡＣアドレス（及びＩＰアドレス）を、パケットの宛先情報の領域に記載し、端末Ｂ宛のパケットを送信する。
【００９１】
端末Ａが接続されたエッジスイッチ１０−１は、入力ポート１で端末Ｂ宛のパケットを受信すると、自身のフローテーブルに当該受信パケットと適合するエントリが登録されているか確認する。
【００９２】
端末Ａが接続されたエッジスイッチ１０−１は、自身のフローテーブルに、「端末Ｂ宛のパケットを受信した場合、当該受信パケットの宛先情報の領域の少なくとも一部に、ＩＤ群（端末Ｂが接続されたエッジスイッチ１０−６のノードＩＤと、当該フローのＶＴＮＩＤと、端末ＢのユーザＩＤ）を記載して次段のスイッチに転送する」という旨のＩｎｇｒｅｓｓエントリが登録されているため、受信パケットの宛先情報の領域の少なくとも一部に、当該ＩＤ群を記載して次段のスイッチに転送する。ここでは、エッジスイッチ１０−１は、受信パケットの宛先情報に記載されている端末ＢのＭＡＣアドレスをＩＤ群に変更（宛先情報にＩＤ群を上書き）し、当該変更後のパケット（以下、ＩＤ化パケット）を、出力ポート２に転送し、出力ポート２から次段のスイッチ１０−２に転送する。
【００９３】
エッジスイッチ１０−２は、入力ポート３でＩＤ化パケットを受信すると、自身のフローテーブルに当該ＩＤ化パケットと適合するエントリが登録されているか確認する。
【００９４】
エッジスイッチ１０−２は、自身のフローテーブルに、「受信パケットの宛先情報の領域の少なくとも一部にエッジスイッチ１０−６のノードＩＤが記載されていれば、当該受信パケットを（所定の出力ポートから）次段のスイッチに転送する」という旨のＣｏｒｅエントリが登録されているため、当該ＩＤ化パケットを、出力ポート４に転送し、出力ポート４から次段のスイッチ１０−３に転送する。なお、エッジスイッチ１０−２は、出力ポート４と出力ポート５のいずれに転送するかは、当該Ｃｏｒｅエントリの「ＯＰｏｒｔ」の値を基に決定する。
【００９５】
このとき、エッジスイッチ１０−２は、当該ＩＤ化パケットに冗長ＩＤが含まれている場合、冗長ＩＤの値を検索キーとして、該当するＣｏｒｅエントリを検索する。
【００９６】
エッジスイッチ１０−３は、入力ポート１０でＩＤ化パケットを受信すると、自身のフローテーブルに当該ＩＤ化パケットと適合するエントリが登録されているか確認する。
【００９７】
エッジスイッチ１０−３は、自身のフローテーブルに、「受信パケットの宛先情報の領域の少なくとも一部にエッジスイッチ１０−６のノードＩＤが記載されていれば、当該受信パケットを（所定の出力ポートから）次段のスイッチに転送する」という旨のＣｏｒｅエントリが登録されているため、当該ＩＤ化パケットを、出力ポート１２に転送し、出力ポート１２から次段のスイッチ１０−６に転送する。
【００９８】
エッジスイッチ１０−６は、入力ポート１３でＩＤ化パケットを受信すると、自身のフローテーブルに当該ＩＤ化パケットと適合するエントリが登録されているか確認する。
【００９９】
端末Ｂが接続されたエッジスイッチ１０−６は、自身のフローテーブルに、「受信パケットの宛先情報の領域の少なくとも一部に（当該エッジスイッチ１０−６のノードＩＤと）配下の端末ＢのユーザＩＤが記載されていれば、当該受信パケットの宛先情報を端末ＢのＭＡＣアドレス宛に戻し、当該受信パケットを端末ＢのＭＡＣアドレス宛に転送する」という旨のＥｇｒｅｓｓエントリが登録されているため、当該ＩＤ化パケットの宛先情報の領域に記載されているＩＤ群を、端末ＢのＭＡＣアドレス宛に変更（宛先情報に端末ＢのＭＡＣアドレスを上書き）し、当該変更後のパケット（元の受信パケット）を、出力ポート１４に転送し、出力ポート１４から端末Ｂに転送する。
【０１００】
なお、上記では、宛先情報の領域として、「ＭＡＣアドレス領域」を例に説明しているが、実際には「ＩＰアドレス領域」でも良い。すなわち、「宛先アドレスの領域」であれば良い。
【０１０１】
＜第２実施形態＞
以下に、本発明の第２実施形態について説明する。
本実施形態では、ステーション検知の際ではなく、スイッチ間でのＩＰパケット等の通信を開始した際に、入力側エッジスイッチのフローテーブルに「Ｉｎｇｒｅｓｓエントリ」を登録する事例について説明する。
【０１０２】
ここでは、図３に示すステーション検知（ＡＲＰリクエスト利用）により、エッジスイッチに「Ｅｇｒｅｓｓエントリ」を登録する処理のみ実施した状態、或いは、図４に示すステーション検知（ＡＲＰリプライ利用）の際に、エッジスイッチに「Ｉｎｇｒｅｓｓエントリ」を登録する処理を実施していない状態を想定している。
【０１０３】
［パケットの問い合わせ］
図６を参照して、データ通信開始時のパケットの問い合わせの際の処理について説明する。
【０１０４】
コントローラ２０は、セキュアチャネル（Ｓｅｃｕｒｅ  Ｃｈａｎｎｅｌ）接続で、管理下にあるスイッチから受信パケットについての問い合わせを受けた場合に、応答としてＩｎｇｒｅｓｓエントリを登録する。
【０１０５】
まず、端末Ａは、宛先となる端末ＢのＭＡＣアドレス（及びＩＰアドレス）を、パケットの宛先情報の領域に記載し、端末Ｂ宛のパケットを送信する。
【０１０６】
端末Ａが接続されたエッジスイッチ１０−１は、端末Ｂ宛のパケットを受信すると、自身のフローテーブルに当該パケットと適合するエントリが登録されているか確認する。この時点では、端末Ａが接続されたエッジスイッチ１０−１には、当該パケットと適合するエントリ（Ｉｎｇｒｅｓｓエントリ）は登録されていないため、端末Ａが接続されたエッジスイッチ１０−１は、セキュアチャネル（Ｓｅｃｕｒｅ  Ｃｈａｎｎｅｌ）接続で、コントローラ２０宛に端末Ｂ宛のパケットを転送する。
【０１０７】
コントローラ２０は、端末Ｂ宛のパケットの宛先情報から端末ＢのＭＡＣアドレス（及びＩＰアドレス）を取得し、自身が保持しているトポロジ情報及びステーション情報から、端末ＢのユーザＩＤと、端末Ｂが接続されたエッジスイッチ１０−６のノードＩＤを特定する。
【０１０８】
コントローラ２０は、端末Ａが接続されたエッジスイッチ１０−１のフローテーブルに、「端末Ｂ宛のパケットを受信した場合、当該受信パケットの宛先情報の領域の少なくとも一部に、ＩＤ群（端末Ｂが接続されたエッジスイッチのノードＩＤと、当該フローのＶＴＮＩＤと、端末ＢのユーザＩＤ）を記載して次段のスイッチに転送する」という旨のＩｎｇｒｅｓｓエントリを登録する。このエントリ登録方式は「Ｒｅａｃｔｉｖｅ型」（最初のパケット到着時にＩｎｇｒｅｓｓエントリを登録する方式）である。
【０１０９】
＜各実施形態の関係＞
なお、上記の各実施形態は、組み合わせて実施することも可能である。例えば、本発明に係るネットワークシステムにおいて、第１実施形態に対応するスイッチと、第２実施形態に対応するスイッチが混在していても良い。また、複数のＶＴＮが存在する場合、ＶＴＮ毎に実施形態を別々にしても良い。
【０１１０】
＜付記＞
上記の実施形態の一部又は全部は、以下の付記のように記載することも可能である。但し、実際には、以下の記載例に限定されない。
【０１１１】
［付記１：システム構成］
それぞれが、自身のフローテーブルに登録されたエントリのルールに適合する受信パケットに対し、前記エントリに定義されたアクションに従った動作を行う複数のスイッチと、
前記複数のスイッチによって形成されるネットワークの物理トポロジに応じて計算された経路に固有の識別子をルールとし、所定の出力ポートからの出力をアクションとしたエントリを、複数のスイッチ間において通信が開始される前に、前記各スイッチに登録するコントローラと
を含む
ネットワークシステム。
【０１１２】
［付記２：Ｃｏｒｅエントリ登録］
付記１に記載のネットワークシステムであって、
前記コントローラは、
通信開始前のトポロジ検知の際、前記各スイッチに内向き及び外向きの設定情報を投入し、前記各スイッチのポート情報を収集するポート情報収集部と、
前記各スイッチのポート情報を基に、内向きポートと外向きポートとを特定し、エッジスイッチとコアスイッチとを特定するスイッチ特定部と、
内向きポート、及び外向きと明示的な設定のないポートに対して、隣接スイッチ情報を収集するための制御フレームを送信する制御フレーム送出部と、
前記制御フレームに対する応答から、ネットワークの物理トポロジを検知し、トポロジ情報を作成するトポロジ情報作成部と、
前記各スイッチに、前記固有の識別子としてノードＩＤを対応付けるノードＩＤ割り当て処理部と、
外向きポートが存在するスイッチ間の経路を計算し、コアスイッチのフローテーブルに、受信パケットの宛先情報の領域にエッジスイッチのノードＩＤが記載されている場合は次段のスイッチに当該受信パケットを転送する旨の中継用エントリを登録する中継用エントリ登録部と
を具備する
ネットワークシステム。
【０１１３】
［付記３：送信側のＥｇｒｅｓｓエントリ登録］
付記２に記載のネットワークシステムであって、
前記コントローラは、
通信開始前のステーション検知の際、送信元端末からのＡＲＰ要求を基に、前記送信元端末の宛先情報を特定する送信元端末特定部と、
前記送信元端末に、前記固有の識別子としてユーザＩＤを対応付ける送信元ユーザＩＤ割り当て処理部と、
前記送信元端末が接続されたエッジスイッチのフローテーブルに、受信パケットの宛先情報の領域に当該エッジスイッチのノードＩＤ及び前記送信元端末のユーザＩＤが記載されている場合は、当該受信パケットの宛先情報の領域に前記送信元端末の宛先情報を記載し、前記送信元端末に当該受信パケットを転送する旨の出力用エントリを登録する送信元端末側出力用エントリ登録部と
を更に具備する
ネットワークシステム。
【０１１４】
［付記４：受信側のＥｇｒｅｓｓエントリ登録］
付記３に記載のネットワークシステムであって、
前記コントローラは、
通信開始前のステーション検知の際、宛先端末からのＡＲＰ応答を基に、前記宛先端末の宛先情報を特定する宛先端末特定部と、
前記宛先端末に、前記固有の識別子としてユーザＩＤを対応付ける宛先ユーザＩＤ割り当て処理部と、
前記宛先端末が接続されたエッジスイッチのフローテーブルに、受信パケットの宛先情報の領域に当該エッジスイッチのノードＩＤ及び前記宛先端末のユーザＩＤが記載されている場合は、当該受信パケットの宛先情報の領域に前記宛先端末の宛先情報を記載し、前記宛先端末に当該受信パケットを転送する旨の出力用エントリを登録する宛先端末側出力用エントリ登録部と
を更に具備する
ネットワークシステム。
【０１１５】
［付記５：送信側のＩｎｇｒｅｓｓエントリ登録（Ｐｒｏａｃｔｉｖｅ型）］
付記４に記載のネットワークシステムであって、
前記コントローラは、
通信開始前のステーション検知の際、前記宛先端末からのＡＲＰ応答を基に、前記送信元端末と前記宛先端末との間の通信が可能であると判断する通信可否判断部と、
前記送信元端末が接続されたエッジスイッチのフローテーブルに、前記宛先端末宛のパケットを受信した場合、当該受信パケットの宛先情報の領域の少なくとも一部に、前記宛先端末が接続されたエッジスイッチのノードＩＤ及び前記宛先端末のユーザＩＤを記載して次段のスイッチに転送する旨の入力用エントリを登録する送信元端末側入力用エントリ登録部と
を更に具備する
ネットワークシステム。
【０１１６】
［付記６：送信側のＩｎｇｒｅｓｓエントリ登録（Ｒｅａｃｔｉｖｅ型）］
付記４に記載のネットワークシステムであって、
前記コントローラは、
通信が開始された際、前記送信元端末が接続されたエッジスイッチからのパケットの問い合わせを基に、前記送信元端末と前記宛先端末との間の通信が可能であると判断する通信可否判断部と、
前記送信元端末が接続されたエッジスイッチのフローテーブルに、前記宛先端末宛のパケットを受信した場合、当該受信パケットの宛先情報の領域の少なくとも一部に、前記宛先端末が接続されたエッジスイッチのノードＩＤと前記宛先端末のユーザＩＤを記載して次段のスイッチに転送する旨の入力用エントリを登録する送信元端末側入力用エントリ登録部と
を更に具備する
ネットワークシステム。
【０１１７】
以上、本発明の実施形態を詳述してきたが、実際には、上記の実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の変更があっても本発明に含まれる。
【０１１８】
なお、本出願は、日本出願番号２０１１−００５１３７に基づく優先権を主張するものであり、日本出願番号２０１１−００５１３７における開示内容は引用により本出願に組み込まれる。
【図１】
0005594552.tif 000002
【図２】
0005594552.tif 000003
【図３】
0005594552.tif 000004
【図４】
0005594552.tif 000005
【図５】
0005594552.tif 000006
【図６】
0005594552.tif 000007