JPWO2014142256A1 - 通信システム、制御装置、通信方法およびプログラム - Google Patents

Abstract

本発明は、通信種別によってマッチングルールを変更可能とした装置、システムを提供する。通信の種類に応じてフローエントリのマッチングルールを決定する手段を備えた制御装置と、前記制御装置から設定されたフローエントリとの照合に基づいて受信パケットを処理する通信装置と備える。

Description

（関連出願についての記載）
本発明は、日本国特許出願：特願２０１３−０５１８６３号（２０１３年０３月１４日出願）の優先権主張に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
本発明は、通信システム、制御装置、通信装置、通信方法およびプログラムに関する。

近年、集中制御型のネットワークアーキテクチャが提案されている。集中制御型のネットワークアーキテクチャの例として、オープンフロー（ＯｐｅｎＦｌｏｗ）という技術がある（特許文献１、非特許文献１、２等参照）。

＜オープンフロー（ＯｐｅｎＦｌｏｗ）＞
オープンフローは、通信をエンドツーエンドのフローとして捉え、フロー単位で経路制御、障害回復、負荷分散、最適化を行う。例えば非特許文献２等に仕様化されているオープンフロースイッチ（ＯｐｅｎＦｌｏｗ Ｓｗｉｔｃｈ：「ＯＦＳ」と略記される）は、制御装置に相当するオープンフローコントローラ（ＯｐｅｎＦｌｏｗ Ｃｏｎｔｒｏｌｌｅｒ：「ＯＦＣ」と略記される）との通信用のセキュアチャネルを備えている。ＯＦＳは、ＯＦＣから追加または書き換えが適宜指示されるフローテーブルを備え、例えば受信パケットに関して設定されたフローテーブルに従って動作する。

＜フローテーブル＞
図７は、フローテーブルの１つのフローエントリ１２０の情報を模式的に例示した図である。フローテーブルには、フロー毎に、受信パケットのヘッダの所定の情報と照合するマッチングルール（照合欄：Ｍａｔｃｈ Ｆｉｅｌｄ）（ヘッダフィールド）と、マッチングルールに照合した時の処理内容（動作）を定義したアクション（Ａｃｔｉｏｎｓ）と、パケット転送数やエラー等のフロー統計情報（Ｃｏｕｎｔｅｒｓ）と、の組（エントリ）がフロー毎に定義される。フローは、例えばレイヤ１（Ｌ１：物理ポート等）、レイヤ２（Ｌ２：ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ））、レイヤ３（Ｌ３：ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ））、レイヤ４（Ｌ４：ポート番号）等の各レイヤの任意のアドレス／識別子の組み合わせで識別、特定される。ルールの取り扱いポリシー（アクション）に従い、エンド・ツー・エンド（end-to-end）で最適な経路を選択して転送することをフロースイッチングという。

ＯＦＳは、パケットを受信すると、自身のフローテーブルから、該受信パケットのヘッダ情報に適合するマッチングルール（図７の「Ｍａｔｃｈ Ｆｉｅｌｄ」）を持つエントリを検索する。検索の結果、受信パケットに適合するエントリ（フローエントリ）が見つかった場合、ＯＦＳは、フロー統計情報（図７の「Ｃｏｕｎｔｅｒｓ」）を更新するとともに、該受信パケットに対して、該フローエントリのアクションフィールド（図７の「Ａｃｔｉｏｎｓ」）に記述された処理内容（例えば指定ポートからのパケット送信、フラッディング、廃棄等）を実施する。

＜パケットイン（Ｐａｃｋｅｔ−Ｉｎ）＞
一方、検索の結果、受信パケットに適合するエントリ（フローエントリ）が見つからなかった場合、ＯＦＳは、セキュアチャネルを介してＯＦＣに当該受信パケットを転送し（Ｐａｃｋｅｔ−Ｉｎメッセージ）、ＯＦＣに対して、当該受信パケットの送信元・送信先に基づいたパケットの経路の決定を依頼する。このＰａｃｋｅｔ−Ｉｎメッセージを受け、ＯＦＣは、ネットワークトポロジ情報に基づき、経路計算を行い、フローエントリを生成する。ＯＦＣは、計算した経路上のＯＦＳに対して、該フローテーブルを更新するためのメッセージ（フローモディファイ（ＦｌｏｗＭｏｄｉｆｙ）メッセージ）を送信する。ＯＦＳは、ＯＦＣで決定したパケットの経路に対応するフローエントリ情報を、該ＯＦＣからのＦｌｏｗＭｏｄｉｆｙ）メッセージにて受け取り、フローテーブルを更新する。このように、ＯＦＳにおけるフローエントリ情報に基づくパケット転送処理を、ＯＦＣ側で一元的に管理している。

国際公開第２００８／０９５０１０号

Ｎｉｃｋ ＭｃＫｅｏｗｎほか７名、"ＯｐｅｎＦｌｏｗ： Ｅｎａｂｌｉｎｇ Ｉｎｎｏｖａｔｉｏｎ ｉｎ Ｃａｍｐｕｓ Ｎｅｔｗｏｒｋｓ，"［ｏｎｌｉｎｅ］、［平成２４年１０月３１日検索］、インターネット〈ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｏｐｅｎｆｌｏｗｓｗｉｔｃｈ．ｏｒｇ／／ｄｏｃｕｍｅｎｔｓ／ｏｐｅｎｆｌｏｗ−ｗｐ−ｌａｔｅｓｔ．ｐｄｆ〉 "ＯｐｅｎＦｌｏｗ Ｓｗｉｔｃｈ Ｓｐｅｃｉｆｉｃａｔｉｏｎ" Ｖｅｒｓｉｏｎ １．１．０ Ｉｍｐｌｅｍｅｎｔｅｄ（Ｗｉｒｅ Ｐｒｏｔｏｃｏｌ ０ｘ０２） ［平成２４年１０月３１日検索］、インターネット〈ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｏｐｅｎｆｌｏｗｓｗｉｔｃｈ．ｏｒｇ／ｄｏｃｕｍｅｎｔｓ／ｏｐｅｎｆｌｏｗ−ｓｐｅｃ−ｖ１．１．０．ｐｄｆ〉

関連技術の問題点について、図８、図９を参照して説明する。図８を参照すると、例えば、通信システム（プロトタイプ例）は、ＯＦＣ１１０、ＯＦＳ１２１、１２２、１２３、通信端末１３１、１３２、サーバ（Ｓｅｒｖｅｒ）１４１、１４２、ルータ１５０を備えている。サーバ１４１、１４２は、Ａｃｔｉｖｅ（稼動）／Ｓｔａｎｄｂｙ（待機）の冗長構成とされる。例えばＡｃｔｉｖｅ状態のサーバに障害が発生して処理の続行が不可能になると、Ｓｔａｎｄｂｙ状態のサーバを稼働させて障害が発生したサーバで行っていた処理の引き継ぎを行う。以下の説明では、サーバ１４１がＡｃｔｉｖｅ状態に、サーバ１４２がＳｔａｎｄｂｙ状態に遷移しているものとする。なお、通信端末、ＯＦＳの数等に特に制限はない。

＜サーバ〜サーバ間通信＞
図９を参照して、図８の通信システム（プロトタイプ例）における、サーバ１４１とサーバ１４２間での通信時の経路制御処理、通信端末１３１および通信端末１３２の通信時の経路制御処理について説明する。まず、サーバ（Ｓｅｒｖｅｒ）１４１〜サーバ１４２間の通信時の経路制御処理について説明する。なお、処理を説明する文の括弧内の番号は、図９に模式的に示したシーケンスの番号に対応する。

Ａｃｔｉｖｅ状態のサーバ１４１は、Ｓｔａｎｄｂｙ状態のサーバ１４２へのアクセスを開始するために、データパケットを送信する（１）。ＯＦＳ１２３は、サーバ１４１からのデータパケットを受信する。ＯＦＳ１２３において、受信したデータパケットのフローは設定されていず（該データパケットに対応するフローエントリがフローテーブルに設定されていない）、新規フローである。このため、ＯＦＳ１２３は、ＯＦＣ１１０に対して、Ｐａｃｋｅｔ−Ｉｎメッセージを送信し、受信したデータパケットに対する経路設定を要求する（２）。

ＯＦＳ１２３からのＰａｃｋｅｔ−Ｉｎメッセージを受信したＯＦＣ１１０は、通信可能と判断すると、サーバ１４１〜サーバ１４２間の経路を計算する。そして、ＯＦＣ１１０は、ＯＦＳ１２３に対して、フローテーブルを更新するためのメッセージ（フローモディファイ（ＦｌｏｗＭｏｄｉｆｙ）メッセージ：「ＦｌｏｗＭｏｄ」と略記される）を送信する（３）。ＯＦＣ１１０からのＦｌｏｗＭｏｄメッセージを受信したＯＦＳ１２３は、サーバ１４１〜サーバ１４２間通信を実現するためのフローエントリをフローテーブルに設定する。その際、サーバ間の通信は、重要であり、きめ細かく通信状態を管理するために、マッチングルール（受信パケットのヘッダ情報と照合されるフローエントリのＭａｔｃｈ Ｆｉｅｌｄ）として、例えばＯｐｅｎＦｌｏｗで指定可能なＬ２〜Ｌ４の全てのパラメータを指定するものとする。

ＯＦＣ１１０は、パケットアウト（Ｐａｃｋｅｔ−Ｏｕｔ）メッセージをＯＦＳ１２３に転送し（４）、ＯＦＳ１２３に対して、パケットの転送を指示する。Ｐａｃｋｅｔ−Ｏｕｔメッセージを受信したＯＦＳ１２３は、番号１のシーケンスでサーバ１４１から受け取り、ＯＦＳ１２３内に記憶保持しているデータパケットをサーバ１４２に転送する（５）。サーバ１４２は、ＯＦＳ１２３を介して、サーバ１４１に対してデータパケットを転送する（６）。すなわち、サーバ１４１〜サーバ１４２間の通信用の経路が設定されると、サーバ１４１とサーバ１４２は、該経路を介して、通信を開始する。

＜通信端末〜サーバ間通信＞
さらに図９を参照して、通信端末１３１の通信時の経路制御処理について説明する。通信端末１３１は、サーバ１４１へのアクセスを開始するために、データパケットを送信する（７）。

ＯＦＳ１２１は、通信端末１３１から送信されたデータパケットを受信する。ＯＦＳ１２１において、該データパケットのフローは設定されていず、新規フローである。このため、ＯＦＳ１２１は、ＯＦＣ１１０に対してＰａｃｋｅｔ−Ｉｎメッセージを送信し（８）、受信したデータパケットに対する経路設定を要求する。

ＯＦＣ１１０は、通信可能と判断すると、通信端末１３１〜サーバ１４１間の経路を計算する。ＯＦＣ１１０は、該経路上のＯＦＳに対してそれぞれＦｌｏｗＭｏｄメッセージを送信し（９−１〜９−３）、通信端末１３１〜サーバ１４１間の通信を実現するためのフローエントリを、通信経路上のＯＦＳ１２１、１２２、１２３のそれぞれのフローテーブルに設定する。その際、サーバ１４１、１４２間の通信でマッチングルールとして、例えばＯｐｅｎＦｌｏｗで指定可能なＬ２〜Ｌ４までの全てのパラメータを指定している。このため、この通信端末１３１〜サーバ１４１間の通信においても、ＯＦＳ１２１、１２２、１２３には、同じマッチングルール（Ｌ２〜Ｌ４までの全てのパラメータを指定したルール）を用いる。

ＯＦＣ１１０は、パケットアウト（Ｐａｃｋｅｔ−Ｏｕｔ）メッセージをＯＦＳ１２１に送信し（１０）、パケットの転送を指示する。Ｐａｃｋｅｔ−Ｏｕｔメッセージを受け取ったＯＦＳ１２１は、番号７のシーケンスで通信端末１３１から受け取りＯＦＳ１２１内に保持していたデータパケットを、ＯＦＳ１２２、ＯＦＳ１２３を介して、サーバ１４１に転送する（１１）。通信端末１３１〜サーバ１４１間の通信用の経路が設定されると、通信端末１３１はサーバ１４１と通信（データパケットの転送）を開始する（１２）。

＜別の通信端末〜サーバ間通信＞
その後、別の通信端末１３２がサーバ１４１と通信する場合、図９に、シーケンス番号１２から１８として示したように、通信端末１３１〜サーバ１４１間の通信時のシーケンス番号７から１１までの動作と同じ処理が行われる。すなわち、ＯＦＣ１１０は、ＯＦＳ１２１からのＰａｃｋｅｔ−Ｉｎメッセージを受けると（１４）、通信端末１３２〜サーバ１４１間の経路を計算し、該経路上のＯＦＳ１２１、１２２、１２３に対してそれぞれＦｌｏｗＭｏｄメッセージを送信し（１５−１〜１５−３）、通信端末１３２〜サーバ１４１間の通信を実現するためのフローエントリを、通信経路上のＯＦＳ１２１、１２２、１２３のそれぞれのフローテーブルに設定する。ＯＦＣ１１０は、パケットアウト（Ｐａｃｋｅｔ−Ｏｕｔ）メッセージをＯＦＳ１２１に送信し（１６）、パケットの転送を指示する。Ｐａｃｋｅｔ−Ｏｕｔメッセージを受け取ったＯＦＳ１２１は、番号１３のシーケンスで通信端末１３２から受け取りＯＦＳ１２１内に保持していたデータパケットを、ＯＦＳ１２２、ＯＦＳ１２３を介してサーバ１４１に転送する（１７）。通信端末１３２〜サーバ１４１間の通信用の経路が設定されると、通信端末１３２はサーバ１４１と通信（データパケットの転送）を開始する（１８）。

以下の分析は、本発明によって与えられたものである。

ＯｐｅｎＦｌｏｗのような集中制御型のネットワークアーキテクチャにおいては、通信が例えばサーバ〜サーバ間通信であるか、あるいは通信端末〜サーバ間通信であるか等のように、通信種別によって、マッチングルールを変更することはできない。

このため、例えば、ＯＦＳ等の通信装置において、設定されるフローエントリの数が過剰に増加する、という問題がある。

別の観点では、同様の理由で、ＯＦＣ等の制御装置の処理負荷が過剰に増えることになる。したがって、通信種別によって、マッチングルールを変更できるようにする必要がある。

本発明は、上記課題に鑑みて創案されたものであって、例えば通信種別によって、フローエントリに設定するマッチングルールを変更可能とする制御装置、システム、通信方法およびプログラムを提供することにある。

開示される発明のいくつかのの関連する側面の一つ（視点１）によれば、通信の種類に応じてフローエントリのマッチングルールを決定するマッチングルール管理部を備えた制御装置と、
前記制御装置から設定されたフローエントリとの照合に基づいて受信パケットを処理する通信装置と、を備えた通信システムが提供される。

さらに別の側面の１つ（視点２）によれば、通信の種類に応じて、フローエントリのマッチングルールを決定するマッチングルール管理部を備え、フローエントリとの照合に基づいて受信パケットを処理する通信装置に対して前記フローエントリを設定する、制御装置が提供される。

さらに別の側面の１つ（視点３）によれば、制御装置が、通信の種類に応じて、フローエントリのマッチングルールを決定し、
通信装置が、前記制御装置から設定されたフローエントリとの照合に基づいて受信パケットを処理する、通信方法が提供される。

さらに別の側面の１つ（視点４）によれば、通信の種類に応じて、フローエントリのマッチングルールを決定する処理と、
フローエントリとの照合に基づいて受信パケットを処理する通信装置に対して前記フローエントリを設定する処理と、を制御装置のコンピュータに実行させるプログラムが提供される。

さらに別の側面の１つ（視点５）によれば、上記視点４に係るプログラムを記録したコンピュータ読み出し可能な媒体（non-transitory machine readable medium: semiconductor memory device, magnetic/optical disk）が提供される。

本発明によれば、通信種別によってフローエントリに設定するマッチングルールを変更することができる。

実施形態１、２の通信システムの構成を例示する図である。 実施形態１、２の経路制御機能の構成を例示する図である。 実施形態１におけるマッチングルール管理部のマッチングルール決定用の情報テーブルを例示する図である。 実施形態１、２における経路制御の動作シーケンスを例示する図である。 実施形態２におけるマッチングルール管理部のマッチングルール決定用の情報テーブルを例示する図である。 実施形態２におけるマッチングルール管理部のマッチングルール決定用の情報テーブルを例示する図である。 オープンフロースイッチに設けられたフローテーブルが保持する情報（フローエントリ）を例示する図である。 通信システムの構成の一例を例示する図である。 図８の通信システムの動作シーケンスを例示する図である。 実施形態の構成を例示する図である。

本発明の概要を説明する。以下の説明で用いる参照符号は、専ら理解を助けるための例示であり、本発明を図示の態様に限定するものと解釈すべきものでない。いくつかの好ましい形態の１つによれば、図１０を参照すると、通信の種類（特に制限されないが、例えば、サーバ機能通信間であるか、通信端末〜サーバ機能間通信であるか等の種別）に応じて、フローエントリ（処理規則：「パケット転送ルール」ともいう）のマッチングルール（照合規則）を決定するマッチングルール管理部（２０１）を備えた制御装置（１０Ａ）と、前記制御装置（１０Ａ）から設定されたフローエントリ（処理規則）との照合に基づいて受信パケットを処理する通信装置（２０Ａ）と、を備える。

前記マッチングルール管理部（２０１）は、通信の種類に応じて、マッチングルールを生成するための生成規則であるフロー粒度を決定する構成としてもよい。

前記マッチングルール管理部（２０１）において、前記フローの粒度を決定するにあたり、前記フローの粒度のパラメータとして、
完全一致を示すエグザクト（ｅｘａｃｔ）と、
任意のパタンにマッチするワイルドカード（ｗｉｌｄｃａｒｄ）と、
所定のリスト（特に制限されないが、例えば図６のｗｅｌｌ−ｋｎｏｗｎポートのポート番号のリスト）に該当する値（例えば後述する実施形態では、レイヤ４（L4）のポート番号）が存在する（登録されている場合）場合、当該値、すなわち、エグザクト（ｅｘａｃｔ）とし、存在しない場合には、ワイルドカード（ｗｉｌｄｃａｒｄ）とする参照型パラメータと、のうちの少なくとも一つを含む。

本発明の好ましい形態の１つにおいて、前記マッチングルール管理部（２０１）において、フローの粒度を決定できなかった際に、デフォルトのフロー粒度を用いる構成としてもよい。

制御装置（１０Ａ）において、通信の種類に応じて、フローエントリのマッチングルールを決定する処理と、フローエントリを通信装置に設定する処理を、制御装置（１０Ａ）を構成するコンピュータ上で実行するプログラムで実行するようにしてもよい。この場合、記憶媒体（半導体メモリ、磁気／光ディスク等）に記憶されたプログラムをコンピュータの主記憶等に読み出して実行することで、上記手段が実現される。

［第１の実施形態］
図１を参照すると、実施の形態１の通信システムは、フローを特定するための照合規則と、前記照合規則に適用する処理内容とを対応付けたパケット転送ルールに従って、受信パケットを処理する複数のパケット転送機能２１、２２、２３と、パケット転送機能２１、２２、２３にパケット転送ルールを設定する経路制御機能１０と、を含む。この通信システムには、サーバ機能４１、４２と、ルータ５０が接続している。通信端末３１〜３２は、ルータ５０を介して通信システムにアクセスする。通信端末３１、３２およびサーバ機能４１、４２は、それぞれ同一のサブネット（サブネット長は２４ビット）に属しているものとする。なお、パケット転送機能、通信端末、サーバ機能等の数は図１の数に制限されるものでないことは勿論である。

＜経路制御機能の一構成例＞
図２は、図１の経路制御機能１０の構成を例示した図である。図２を参照すると、経路制御機能１０は、パケット転送機能２１〜２３（ノード）との通信を行うノード通信部１１と、制御メッセージ処理部１２と、経路・アクション計算部１３と、パケット転送機能管理部１４と、トポロジ管理部１５と、通信端末位置管理部１６と、パケット転送ルール管理部１７Ａと、マッチングルール管理部１８と、を備えている。各部はそれぞれ次のように動作する。

制御メッセージ処理部１２は、パケット転送機能２１〜２３から受信した制御メッセージを解析して、経路制御機能１０内の該当する処理手段に制御メッセージ情報を引き渡す。

経路・アクション計算部１３は、通信端末位置管理部１６で管理されている通信端末の位置情報と、トポロジ管理部１５にて構築されたトポロジ情報と、に基づいて、パケットの転送経路上のパケット転送機能に実行させるアクションを求める。また、経路・アクション計算部１３は、パケット転送ルールを、パケット転送機能（図１の２１／２２／２３）に設定する際には、パケット転送ルールに設定する、マッチングルールを、マッチングルール管理部１８に問い合わせる。

パケット転送機能管理部１４は、経路制御機能１０によって制御されているパケット転送機能の能力（例えば、ポートの数や種類、サポートするアクションの種類など）を管理する。

トポロジ管理部１５は、ノード通信部１１を介して収集されたパケット転送機能の接続関係に基づいてネットワークトポロジ情報を構築する。

通信端末位置管理部１６は、通信システムに接続している通信端末（図１の３１／３２）の位置を特定するための情報を管理する。本実施形態では、通信端末の通信システムへの接続点を識別する情報としてＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスを、通信端末の位置を特定するための情報として、通信端末が接続しているパケット転送機能（図１では２１）を識別する情報とそのポートの情報を使用する。ただし、通信端末の通信システムへの接続点を識別する情報は、ＭＡＣアドレスに制限されるものでなく、他の情報を用いても良い。

パケット転送ルール管理部１７Ａは、どのパケット転送機能（図１の２１／２２／２３）に、どのようなパケット転送ルールが設定されているかを管理する。具体的には、パケット転送ルール管理部１７Ａは、経路・アクション計算部１３で計算された結果を、パケット転送ルールとしてパケット転送ルールデータベース（ＤＢ）１７Ｂに登録し、パケット転送機能（図１の２１／２２／２３）に対して、パケット転送ルールを設定する。また、パケット転送ルール管理部１７Ａは、パケット転送機能（図１の２１／２２／２３）からのパケット転送ルール削除通知などにより、パケット転送機能（図１の２１／２２／２３）に設定されているパケット転送ルールに変更が生じたことが通知された場合に、該変更に対応してパケット転送ルールＤＢ１７Ｂに登録されている情報（パケット転送ルール）をアップデートする。

＜マッチングルール管理用の情報テーブル：ｅｘａｃｔ／ｗｉｌｄｃａｒｄ＞
マッチングルール管理部１８は、パケット転送ルールに設定するマッチングルールを決定する。図３を参照して、マッチングルール管理部１８の管理情報について説明する。図３は、マッチングルール管理部１８で管理するマッチングルール決定用の情報テーブルの一例を例示する図である。この情報テーブルは、エントリＩＤ（ｅｎｔｒｙ＃１、entryｅｎｔｒｙ＃２、・・・等）で識別される各エントリに対して、検索ルールとフロー粒度とを含む。検索ルールは、パケット転送ルールに含まれるマッチングルール（図７のMatch Field）と同様に、パケット転送ルールを設定しようとしている通信が、図３のテーブルのどのエントリにヒットするかを検索するために用いる情報である。フロー粒度は、マッチングルールを生成するための生成規則である。

図３の各エントリにおいて、入力ポートはＬ１（物理層）、送信元ＭＡＣアドレスから、宛先ＭＡＣアドレス、Ｅｔｈｅｒ Ｔｙｐｅ（Ｅｔｈｅｒｎｅｔ（登録商標） Ｔｙｐｅ）、ＶＬＡＮ（Ｖｉｒｔｕａｌ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）ＩＤ、ＶＬＡＮ ＰＣＰ（Ｐｒｉｏｒｉｔｙ Ｃｏｄｅ Ｐｏｉｎｔ：フロー優先度）まではＬ２、ＴＯＳ（Ｔｙｐｅ ｏｆ Ｓｅｒｖｉｃｅ）、ＩＰプロトコル、送信元ＩＰアドレス、宛先ＩＰアドレスがＬ３に対応し、宛先ＭＡＣアドレスはＬ２（ＭＡＣ）スイッチング、宛先ＩＰアドレスはＬ３（ＩＰ）ルーティングの転送制御に用いられる。送信元ポート番号（送信元Ｌ４ポート番号）と宛先ポート番号（宛先Ｌ４ポート番号）はＬ４のポート番号（例えばＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）やＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）のポート番号）である。

図３の例において、エントリＩＤ：ｅｎｔｒｙ＃１は、図１のサーバ機能４１〜サーバ機能４２間通信等、サーバ機能間の通信用のエントリである。エントリＩＤ：ｅｎｔｒｙ＃２とｅｎｔｒｙ＃３は、図１の通信端末３１〜サーバ機能４１間等、通信端末〜サーバ機能間の通信に用いるエントリである。

エントリＩＤ：ｅｎｔｒｙ＃１の検索ルールでは、
・Ｅｔｈｅｒ Ｔｙｐｅが１６進（０ｘは１６進を表す）の０８００（＝ＩＰｖ４）、
・送信元ＩＰアドレス、宛先ＩＰアドレスが、それぞれサーバ機能（例えば図１の４１、４２）のサブネットであり、
・上記以外の他のフィールドは全て「ｗｉｌｄｃａｒｄ」である。一方、エントリＩＤ：ｅｎｔｒｙ＃１のフロー粒度は、いずれのフィールドも「ｅｘａｃｔ」に設定されている。ＩＰアドレスについては、送信元ＩＰアドレス、宛先ＩＰアドレスで指定されるサーバ機能のサブネットはＩＰアドレスの上位３２ビット（／３２）とされ、１つのサブネットに１つサーバ（ホスト）となる。

エントリＩＤ：ｅｎｔｒｙ＃２、ｅｎｔｒｙ＃３の検索ルールでは、
・Ｅｔｈｅｒ Ｔｙｐｅが１６進の０８００（＝ＩＰｖ４）、
・送信元ＩＰアドレス、宛先ＩＰアドレスが、それぞれ通信端末とサーバ機能（例えば図１の３１と４１）のサブネットであり、
・上記以外の他のフィールドは「ｗｉｌｄｃａｒｄ」である。エントリＩＤ：ｅｎｔｒｙ＃２、ｅｎｔｒｙ＃３のフロー粒度は、
・入力ポート、
・送信元ＭＡＣアドレス、
・宛先ＭＡＣアドレス、
・Ｅｔｈｅｒ Ｔｙｐｅ、
・ＩＰプロトコル
がいずれも「ｅｘａｃｔ」に設定されている。また、ＩＰアドレスについては、エントリＩＤ：ｅｎｔｒｙ＃２では、送信元ＩＰアドレスで指定される通信端末のサブネットは、プレフィックスで指定される２４、すなわちＩＰアドレス（３２ビット）の上位２４ビットとされ、宛先ＩＰアドレスで指定されるサーバ機能のサブネットは、ＩＰアドレスの上位３２ビット（／３２）とされ、１つのサブネットに１つサーバ（ホスト）となる。一方、エントリＩＤ：ｅｎｔｒｙ＃３では、送信元ＩＰアドレスで指定されるサーバ機能のサブネットはＩＰアドレスの上位３２ビット、宛先ＩＰアドレスで指定される通信端末のサブネットはＩＰアドレスの上位２４ビットとされる。

なお、上記した構成のうち、経路制御機能１０にて、パケット転送ルールを保持する必要が無い場合、パケット転送ルールＤＢ１７Ｂは省略することが可能である。また、パケット転送ルールＤＢ１７Ｂを、別途、外部サーバ等に設ける構成としてもよい。

上記のような経路制御機能１０は、例えば、非特許文献１のＯＦＣをベースに、上記マッチングルール管理部１８を追加することで実現するようにしてもよい。パケット転送機能２１〜２３は、各々、ＯＦＳに実装してもよい。

パケット転送機能２１〜２３の各々は、パケットを受信すると、パケット転送ルールを格納するパケット転送ルールテーブル（パケット転送機能２１〜２３がそれぞれ具備する）から、受信したパケットに適合するマッチングキーを持つパケット転送ルールを探し出し、当該パケット転送ルールに関連付けられたアクション（図７のActions）に規定されている動作（例えば、特定のポートへの転送、フラッディング、廃棄など）を実施する。

＜サーバ機能４１〜サーバ機能４２間の通信時の動作＞
次に、図４を参照して、本実施形態の全体の動作について詳細に説明する。以下では、サーバ機能４１〜サーバ機能４２間の通信時の経路制御処理と、通信端末３１および通信端末３２の通信時の経路制御処理について説明する。なお、以下の説明において、処理を説明する文の括弧内の番号は、図４に模式的に示したシーケンスの番号に対応する。まず、サーバ機能４１〜サーバ機能４２間の通信時の経路制御処理について説明する。サーバ機能４１は、サーバ機能４２へのアクセスを開始するために、データパケットを送信する（１）。

パケット転送機能２３は、サーバ機能４１からのデータパケットを受信する。パケット転送機能２３において、受信した当該データパケットのフローは設定されていず、新規フローである。このため、パケット転送機能２３は、経路制御機能１０に新規フロー発生通知メッセージを送信し（２）、受信した当該データパケットに対する経路設定を要求する。

新規フロー発生通知メッセージを受信した経路制御機能１０は、通信可能と判断すると、サーバ機能４１〜サーバ機能４２間の経路を計算し、経路設定変更指示メッセージをパケット転送機能２３に送信し（３）、サーバ機能４１〜サーバ機能４２間通信を実現するためのエントリを、通信経路上のパケット転送機能２３のパケット転送ルールテーブルに設定する。その際、経路制御機能１０のマッチングルール管理部１８にて、図３に示した情報テーブルを検索し、該当するマッチングルール決定用のエントリを検索する。マッチングルール管理部１８において、今回のサーバ機能４１〜サーバ機能４２間の通信経路に対して、図３のエントリＩＤ：ｅｎｔｒｙ＃１がヒットする。そこで、経路制御機能１０は、マッチングルールとして指定可能なＬ２〜Ｌ４までの全てのパラメータを指定する。

パケット転送機能２３は、経路設定変更指示メッセージの受信に応答して、設定したパケット転送ルールテーブルに従い、番号１のシーケンスで受信したデータパケットをサーバ機能４２に転送する（４）。

サーバ機能４１〜サーバ機能４２間の通信用の経路が設定されると、サーバ機能４１はサーバ機能４２と通信を開始する（５）。

＜通信端末３１〜サーバ機能４１間の通信時の動作＞
続いて、通信端末３１の通信時の経路制御処理について説明する。通信端末３１は、サーバ機能４１へのアクセスを開始するために、データパケットを送信する（６）。

パケット転送機能２１は、通信端末３１から送信されたデータパケットを受信する。パケット転送機能２１において、受信した当該データパケットのフローは設定されていず、新規フローである。このため、パケット転送機能２１は、経路制御機能１０に対して、新規フロー発生通知メッセージを送信し（７）、受信した当該データパケットに対する経路設定を要求する。新規フロー発生通知メッセージを受信した経路制御機能１０は、通信可能と判断すると、通信端末３１〜サーバ機能４１間の経路を計算する。経路制御機能１０は、経路設定変更指示メッセージを、パケット転送機能２１、２２、２３に送信し（８−１〜８−３）、通信端末３１〜サーバ機能４１間の通信を実現するためのエントリを、通信経路上のパケット転送機能２１、２２、２３のパケット転送ルールテーブルに設定する。その際、マッチングルール管理部１８にて、図３に示した情報テーブルを検索し、該当するマッチングルール決定用のエントリを検索する。マッチングルール管理部１８において、今回の通信に対して、通信端末３１→サーバ機能４１の向きでは、エントリＩＤ：ｅｎｔｒｙ＃２がヒットし、逆方向のサーバ機能４１→通信端末３１では、エントリＩＤ：ｅｎｔｒｙ＃３がヒットする。

そこで、経路制御機能１０は、マッチングルールとして、サーバ〜サーバ間通信のエントリよりも、ワイルドカード（ｗｉｌｄｃａｒｄ）の指定箇所を増やしたものを使用する。例えば図３のエントリＩＤ：ｅｎｔｒｙ＃２、ｅｎｔｒｙ＃３のフロー粒度では、
・ＶＬＡＮ ＩＤ、
・ＶＬＡＮ ＰＣＰ、
・ＴｏＳ、
・送信元Ｌ４ポート番号、
・宛先Ｌ４ポート番号
の各フィールドが「ｗｉｌｄｃａｒｄ」に設定され、通信端末のサブネットマスクのプレフィックス２４（ＩＰアドレス上位２４ビット）等、サーバ機能４１〜サーバ機能４２間通信よりもマッチング条件が緩和されている。

パケット転送機能２1は、経路設定変更指示メッセージの受信に応答して、設定したパケット転送ルールテーブルに従い、番号６のシーケンスで受信し記憶保持しているデータパケットを、パケット転送機能２２、２３を介して、サーバ機能４１に転送する（９）。

通信端末３１〜サーバ機能４１間の通信用の経路が設定されると、通信端末３１は、サーバ機能４１と通信を開始する（１０）。

＜通信端末３２〜サーバ機能４１間の通信時の動作＞
その後、通信端末３２がサーバ機能４１と通信する際に、必要なパケット転送ルール（フローテーブル）が、通信端末３１〜サーバ機能４１間での通信時に既に設定されている。このため、パケット転送機能２１、２２、２３に対するパケット転送ルールの新たな設定処理は不要となる。

＜比較例との対比＞
これに対して、図８と図９を参照して説明したプロトタイプ例では、通信端末３２がサーバ機能４１と通信する際に、パケット転送ルールの新たな設定処理が必要とされる。すなわち、図９を参照して説明したように、通信端末１３１〜サーバ１４１間の通信において、ＯＦＳ１２１、１２２、１２３には、サーバ１４１〜サーバ１４２間通信と同じマッチングルール（例えばＬ２〜Ｌ４までの全てのパラメータを指定したルール）を用いており、通信端末１３２〜サーバ１４１間の通信に対して、新たなフローエントリのＯＦＳ１２１〜１２３への設定処理が行われる（図９のシーケンス番号１５−１〜１５−３のＦｌｏｗＭｏｄ参照）。このため、ＯＦＳで保持するフローエントリ数が増大する。

フローエントリのマッチングルールにおいてフローを細粒度で扱う場合、パケット転送機能等が保持すべきフローエントリ数が膨大となるが、本実施形態によれば、通信の種別に対応したフロー粒度でフローエントリのマッチングルールの設定を可能としている。その結果、本実施形態によれば、パケット転送機能において、保持するフローエントリ数が過剰に増大することを回避可能としている。また、経路制御機能等の制御装置において、処理負荷が過剰に増大することを抑制可能としている。

本実施の形態では、経路制御機能１０において、図３の情報テーブルを検索した際に、全ての検索でエントリがヒットしていたが、必ずしもヒットする必要はない（情報テーブルの検索の結果、受信パケットのヘッダの所定情報と照合する検索ルール（エントリ）が見つかることを、「ヒット」という）。その場合、デフォルトのフロー粒度を予め決めておき、ヒットしない場合には、デフォルトのフロー粒度を使用するようにしてもよい。

［第２の実施形態］
前記第１の実施形態では、フロー粒度の各パラメータをマッチングルールで指定するか否かのパラメータとして、「ｅｘａｃｔ」と「ｗｉｌｄｃａｒｄ」の２種類を用いている。本実施形態では、「ｅｘａｃｔ」と「ｗｉｌｄｃａｒｄ」に加えて、新たに、「リスト参照型のパラメータ」を用いることで、より柔軟にマッチングルールを決定可能としている。本実施形態の通信システムの構成は、図１の前記実施形態１と同一である。以下では、本実施形態について、前記実施形態１との相違点について説明し、同一部分の説明は省略する。

本実施形態の経路制御機能１０の基本構成は、図２に示した前記実施形態１と同一であるが、マッチングルール管理部１８が管理する情報テーブルが、前記実施形態１の情報テーブル（図３）と相違している。

＜マッチング管理用の情報テーブル：ｗｅｌｌ−ｋｎｏｗｎ＞
図５と図６に、本実施形態の経路制御機能１０におけるマッチングルール管理部１８が管理する情報テーブルの例を示す。図５は、パケット転送ルールに設定するマッチングルールを決定するための規則を特定するための情報テーブルである。図５に示すように、情報テーブルは、各エントリに対して、検索ルールとフロー粒度を備えている。前記実施形態１との相違点は、フロー粒度に「ｗｅｌｌ−ｋｎｏｗｎ」というパラメータを追加したことである（図５の例では、エントリＩＤ：ｅｎｔｒｙ＃２およびｅｎｔｒｙ＃３の送信元Ｌ４ポート番号と宛先Ｌ４ポート番号の各フィールドで使用されている）。

図６は、図５において、サービス名、ｅｘａｃｔ指定対象のＬ４タイプ（ＴＣＰ、ＵＤＰ等）とポート番号を管理するテーブルを例示する図である。図６には、ｗｅｌｌ−ｋｎｏｗｎポート番号の一例が示されている。ｆｔｐ（ｆｉｌｅ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ）−ｄａｔａ（ファイル転送（データ本体））はポート番号２０、ｆｔｐ（ファイル転送（コントロール））はポート番号２１、ｓｓｈ（シェル（セキュアシェル）：ＴＣＰ、ＵＤＰ）はポート番号２２、ｔｅｌｎｅｔはポート番号２３、ｈｔｔｐ（ｈｙｐｅｒｔｅｘｔ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ）は８０である（その他、メール送受信のｓｍｔｐ（ｓｉｍｐｌｅ ｍａｉｌ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ）のポート番号は２５等、よく知られたポートは他にもあるが省略する）。

マッチングルールを管理する図５の情報テーブルにおいて、あるフィールドのフロー粒度が「ｗｅｌｌ−ｋｎｏｗｎ」が指定されていた場合（図５の例では、エントリＩＤ：ｅｎｔｒｙ＃２、＃３の送信元Ｌ４ポート番号や宛先Ｌ４ポート番号等のＬ４ポート番号のフィールドのフロール粒度が「ｗｅｌｌ−ｋｎｏｗｎ」に指定されている）、Ｌ４ポート番号が、図６のテーブルに登録されているポート番号である場合には、該当フィールドの検索ルールのパラメータを「ｅｘａｃｔ」と指定する。一方、図６のテーブルに登録されていない場合には、該当フィールドの検索ルールのパラメータを「ｗｉｌｄｃａｒｄ」とする。特に制限されないが、経路制御機能１０において、Ｌ４ポート番号等は、例えばＰａｃｋｅｔ−Ｉｎに含まれるパケット等から取得するようにしてもよい。

本実施形態によれば、ｈｔｔｐやｆｔｐなどＬ４ポート番号の一方のみが固定化され、他方はトランザクション毎にランダムな番号が使われる通信を、アプリケーション種別などの通信毎に、フロー粒度を設定しつつ、図５の情報テーブルのエントリ数を過剰に増やすことなく、収容することができる。

本実施の形態では、リスト参照型のパラメータを使うフィールドとして、Ｌ４ポート番号のみを例に挙げて説明したが、かかる構成に制限されるものでなく、例えば、Ｅｔｈｅｒ ＴｙｐｅやＩＰプロトコルなど、他のフィールドに用いても良い。

以上、本発明の各実施形態を説明したが、本発明は、上記した実施形態に限定されるものではなく、更なる変形・置換・調整を加えることができる。

なお、図７のフローエントリに、さらにＥｘｐｉｒｅ Ｒｕｌｅ（失効規則）等を設けてもよい。

なお、上記の特許文献および非特許文献の各開示を、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態の変更・調整が可能である。また、本発明の請求の範囲の枠内において種々の開示要素の多様な組み合わせ、ないし選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得る各種変形、修正を含むことは勿論である。

１０ 経路制御機能
１０Ａ 制御装置
１１ ノード通信部
１２ 制御メッセージ処理部
１３ 経路・アクション計算部
１４ パケット転送機能管理部
１５ トポロジ管理部
１６ 通信端末位置管理部
１７Ａ パケット転送ルール管理部
１７Ｂ パケット転送ルールデータベース（ＤＢ）
１８ マッチングルール管理部
２０Ａ 通信装置
２１〜２３ パケット転送機能
３１〜３２ 通信端末
４１〜４２ サーバ機能
５０ ルータ
１０１ マッチングルール決定手段
１１０ ＯｐｅｎＦｌｏｗ Ｃｏｎｔｒｏｌｌｅｒ（ＯＦＣ）
１２０ フローエントリ
１２１〜１２３ ＯｐｅｎＦｌｏｗ Ｓｗｔｉｃｈ（ＯＦＳ）
１３１〜１３２ 通信端末
１４１〜１４２ サーバ
１５０ ルータ
２０１ マッチングルール管理部

Claims (10)

1. 通信の種類に応じて、フローエントリのマッチングルールを決定するマッチングルール管理部を備えた制御装置と、
   前記制御装置から設定された前記フローエントリとの照合に基づいて受信パケットを処理する通信装置と、
   を備えた、ことを特徴とする通信システム。
2. 前記マッチングルール管理部が、前記通信の種類に応じて、前記マッチングルールを生成するための生成規則であるフローの粒度を決定する、ことを特徴とする請求項１に記載の通信システム。
3. 前記マッチングルール管理部において、前記フローの粒度のパラメータとして、
   完全一致を示すエグザクト（ｅｘａｃｔ）と、
   任意のパタンにマッチするワイルドカード（ｗｉｌｄｃａｒｄ）と、
   所定のリストに該当する値が存在する場合、エグザクトとし、存在しない場合には、ワイルドカードとする参照型パラメータと、
   のうちの少なくとも一つを含む、ことを特徴とする請求項２に記載の通信システム。
4. 前記マッチングルール管理部において、前記フローの粒度が決定できない場合に、デフォルトのフローの粒度を用いる、ことを特徴とする請求項２又は３に記載の通信システム。
5. 通信の種類に応じて、フローエントリのマッチングルールを決定するマッチングルール管理部を備え、フローエントリとの照合に基づいて受信パケットを処理する通信装置に対して前記フローエントリを設定する、ことを特徴とする制御装置。
6. 前記マッチングルール管理部が、通信の種類に応じて、前記マッチングルールを生成するための生成規則であるフローの粒度を決定する手段を含む、ことを特徴とする請求項５に記載の制御装置。
7. 前記マッチングルール管理部において前記フローの粒度のパラメータとして、
   完全一致を示すエグザクト（ｅｘａｃｔ）と、
   任意のパタンにマッチするワイルドカード（ｗｉｌｄｃａｒｄ）と、
   所定のリストに該当する値が存在する場合、エグザクトとし、存在しない場合には、ワイルドカードとする参照型パラメータと、
   のうちの少なくとも一つを含む、ことを特徴とする請求項５又は６に記載の制御装置。
8. 前記マッチングルール管理部において、前記フローの粒度が決定できない場合に、デフォルトのフローの粒度を使用する、ことを特徴とする請求項５乃至７のいずれか１項に記載の制御装置。
9. 制御装置が、通信の種類に応じて、フローエントリのマッチングルールを決定し、
   通信装置が、前記制御装置から設定されたフローエントリとの照合に基づいて受信パケットを処理する、ことを特徴とする通信方法。
10. 通信の種類に応じて、フローエントリのマッチングルールを決定する処理と、
    フローエントリとの照合に基づいて受信パケットを処理する通信装置に対して前記フローエントリを設定する処理と、
    を制御装置のコンピュータに実行させるプログラム。

Images