JP5626214B2 - 通信システム、ノード、制御サーバ、通信方法およびプログラム - Google Patents

Description

本発明は、通信システム、ノード、制御サーバ、通信方法およびプログラムに関し、特に、ネットワークに配置されたノードによりパケットを転送して通信を実現する通信システム、ノード、制御サーバ、通信方法およびプログラムに関する。

ネットワークに配置されたルータやスイッチ等のノードに、プログラムを実行させる技術としてアクティブネットワークが知られている（非特許文献１参照）。特許文献１には、事前のシグナリングにより、ネットワークのノードにアクティブコードを配置するシグナリング制御ユニットを備えるアクティブネットワークが開示されている。

特許文献２には、異なるパケットリングを経由するパケットフローに対し、異なるパケットリングで一貫したサービスクラスを適用できるようにした光通信システムが開示されている。この光通信システムのノード装置は、他パケットリングから到着したパケットに付加されたリング間ヘッダ情報に含まれるリング間サービスクラスの情報を抽出し、この抽出されたリング間サービスクラスの情報に基づきパケットリング間で設定されるリング間サービスクラスとリング内サービスクラスとの対応関係を記録したテーブルを参照して到着したパケットに設定すべきリング内サービスクラスを決定し、この決定したリング内サービスクラスの情報を含むリング内ヘッダ情報を到着したパケットに付加する。

また、ＩＰ網等における経路制御を行う方式として、ソースルーティングという手法が知られている。非特許文献２に規定されているとおり、ソースルーティングでは、中継するルータのＩＰアドレスを指定することによって実現される。

非特許文献３に示すとおり、近年、オープンフロー（ＯｐｅｎＦｌｏｗ）という技術が提案されている。オープンフローは、通信をエンドツーエンドのフローとして捉え、フロー単位で経路制御、障害回復、負荷分散、最適化を行うものである。転送ノードとして機能するオープンフロースイッチは、オープンフローコントローラとの通信用のセキュアチャネルを備え、オープンフローコントローラから適宜追加または書き換え指示されるフローテーブルに従って動作する。フローテーブルには、フロー毎に、パケットヘッダと照合するルール（ＦｌｏｗＫｅｙ）と、処理内容を定義したアクション（Ａｃｔｉｏｎ）と、フロー統計情報（Ｓｔａｔｓ）との組が定義される（図６参照）。

図２９に、非特許文献４に定義されているアクション名とアクションの内容を例示する。ＯＵＴＰＵＴは、指定ポート（インタフェース）に出力するアクションである。ＳＥＴ＿ＶＬＡＮ＿ＶＩＤからＳＥＴ＿ＴＰ＿ＤＳＴは、パケットヘッダーのフィールドを修正するアクションである。

例えば、オープンフロースイッチは、最初のパケット（ｆｉｒｓｔ ｐａｃｋｅｔ）を受信すると、フローテーブルから、受信パケットのヘッダ情報に適合するルール（ＦｌｏｗＫｅｙ）を持つエントリを検索する。検索の結果、受信パケットに適合するエントリが見つかった場合、オープンフロースイッチは、受信パケットに対して、当該エントリのアクションフィールドに記述された処理内容を実施する。一方、前記検索の結果、受信パケットに適合するエントリが見つからなかった場合、オープンフロースイッチは、セキュアチャネルを介して、オープンフローコントローラに対して受信パケットを転送し、受信パケットの送信元・送信先に基づいたパケットの経路の決定を依頼し、これを実現するフローエントリを受け取ってフローテーブルを更新する。

特表２００６−５１３６７１号公報 特開２００８−２３６６５２号公報

David L. Tennenhouseほか４名、"A Survey of Active Network Research", IEEE Communications Magazine, Vol.35, No.1, pp.80-86, January 1997 IETF，RFC791"INTERNET PROTOCOL" Nick McKeownほか７名、"OpenFlow: Enabling Innovation in Campus Networks"、［online］、［平成21年8月27日検索］、インターネット〈URL：http://www.openflowswitch.org//documents/openflow-wp-latest.pdf〉 "OpenFlow Switch Specification" Version 0.9.0. (Wire Protocol 0x98) ［平成21年8月27日検索］ 、インターネット〈URL：http://www.openflowswitch.org/documents/openflow-spec-v0.9.0.pdf〉

上記特許文献１、２及び非特許文献１〜４の全開示内容はその引用をもって本書に繰込み記載する。

以下に本発明による関連技術の分析を与える。

非特許文献３のオープンフロー（ＯｐｅｎＦｌｏｗ）という技術によれば、各スイッチに、フローの特徴に応じた処理内容（アクション）を選択・実行させるためのフローテーブルを配置し、適宜書き換える必要がある。きめ細かな経路制御や品質確保などを実行する場合、このフローテーブルに上記マッチングルールの数に等しいエントリが必要となり、スイッチの負荷およびコントローラ側の管理負担が増大してしまうことが考えられる。

非特許文献１や特許文献１のアクティブネット方式によれば、上記のようなテーブルを用いずに、所望のノードに特定の処理を実行させることができるが、非特許文献３のようなフロー制御を行うスイッチに適用した場合、各スイッチにプログラムライブラリを備えるか、パケットにプログラムそのものを含ませる必要がある。これでは、可能な限り転送ノードの制御機能を簡略化し、コントローラに集中させる非特許文献３の特長が失われかねない。

本発明は、上記した事情に鑑みてなされたものであって、その目的とするところは、ネットワークに配置されたノードの制御機能を簡略化するという要求を満たしつつ、各ノードが受信パケットに応じた処理を行わせる際に参照させるテーブルそのもの、あるいは、そのエントリ数を削減できる構成および方法を提供することにある。

本発明の第１の視点によれば、パケットの転送経路の少なくとも一部を構成する、第１及び第２のノードを含む複数のノードを備え、前記第１のノードは、受信パケットの所定領域を、前記第１のノードと前記第２ノードとを中継する中継ノードで実行されるパケット処理に関する情報に置換する第１の手段を含み、前記第２のノードは、前記パケット処理に関する情報に置換された前記所定領域を復元する第２の手段を含む通信システムが提供される。

本発明の第２の視点によれば、データ転送ネットワークに配置され、前記データ転送ネットワークの転送経路上の個々のノードが実行すべき処理を並べて構成された処理列を含むヘッダが付加されたパケットの、前記処理列に従って自装置が実行すべき処理を実行するノードが提供される。

本発明の第３の視点によれば、パケットの転送経路の少なくとも一部を構成する、第１及び第２のノードを含む複数のノードを制御する制御装置であって、前記第１及び第２のノードに通知する指示を生成する第１の手段と、前記第１のノードに対して、受信パケットの所定領域を、前記第１のノードと前記第２ノードとを中継する中継ノードで実行されるパケット処理に関する情報に置換するための指示を送信し、前記第２のノードに対して、前記パケット処理に関する情報に置換された前記所定領域を復元するための指示を送信する第２の手段と、を備える制御装置が提供される。

本発明の第４の視点によれば、パケットの転送経路の少なくとも一部を構成する、第１及び第２のノードを含む複数のノードを含む通信システムにおいて、前記第１のノードが、受信パケットの所定領域を、前記第１のノードと前記第２のノードとを中継する中継ノードで実行されるパケット処理に関する情報に置換し、前記第２のノードが、前記パケット処理に関する情報に置換された前記所定領域を復元する通信方法が提供される。

本発明の第５の視点によれば、パケットの転送経路の少なくとも一部を構成する、第１及び第２のノードを含む複数のノードを制御する制御装置に実行させる制御プログラムであって、前記第１及び第２のノードに通知する指示を生成する処理と、前記第１のノードに対して、受信パケットの所定領域を、前記第１のノードと前記第２ノードとを中継する中継ノードで実行されるパケット処理に関する情報に置換するための指示を送信する処理と、前記第２のノードに対して、前記パケット処理に関する情報に置換された前記所定領域を復元するための指示を送信する処理と、を前記制御装置に実行させる制御プログラムが提供される。なお、このプログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。即ち、本発明は、コンピュータプログラム製品として具現することも可能である。

本発明によれば、ネットワークに配置されたノードの制御機能を簡略化するという要求を満たしつつ、各ノードに備えるテーブルそのもの、あるいは、そのエントリ数を削減した構成で種々の処理を行わせることが可能になる。その理由は、データ転送ネットワークの転送経路上の個々のノードが実行すべき処理を並べて構成された処理列を含むヘッダを入力パケットに付加し、前記データ転送ネットワークの転送経路上の個々のノードに、前記入力パケットに付加されたヘッダ内の処理列に従って自装置が実行すべき処理を実行させるように構成したことにある。

本発明の概要を説明するための図である。 本発明の第１の実施形態の構成を表した図である。 本発明の第１の実施形態のノードの詳細構成を表した図である。 本発明の第１の実施形態の制御サーバの詳細構成を表した図である。 本発明の第１の実施形態の制御サーバのフローエントリデータベースの構成を表した図である。 図５のフローキー（ＦｌｏｗＫｅｙ；マッチングキー）を説明するための図である。 本発明の第１の実施形態のノードの動作を表したフローチャートである。 アクションヘッダ（アクション列）の付加の一態様を説明するための図である。 アクションヘッダ（アクション列）の具体的態様を説明するための図である。 本発明の第１の実施形態の制御サーバの動作を表したフローチャートである。 本発明の第１の実施形態のノードおよび制御サーバの動作シーケンス（新規フロー受信時）を表した図である。 本発明の第１の実施形態のノードおよび制御サーバの別の動作シーケンス（新規フロー受信時）を表した図である。 本発明の第１の実施形態のノードの別の動作例（新規フロー受信時）を表したフローチャートである。 本発明の第１の実施形態のノードおよび制御サーバの別の動作シーケンス（新規フロー受信時）を表した図である。 本発明の第１の実施形態の全体動作を説明するための図である。 図１４の続図である。 図１５の続図である。 本発明の第１の実施形態のノードにおいて行われる息継ぎ動作を説明するための図である。 本発明の第１の実施形態のノードにおいて行われる息継ぎ動作の別の例を説明するための図である。 本発明の第２の実施形態の構成を表した図である。 本発明の第２の実施形態の制御サーバのフローエントリデータベースの構成を表した図である。 本発明の第２の実施形態のノードにおいて行われる息継ぎ動作の別の例を説明するための図である。 本発明の第３の実施形態のアクションヘッダ（アクション列）の付加（埋め込み）の一態様を説明するための図である。 アクションヘッダ（アクション列）を埋め込んだフレームフォーマットの例である。 本発明の第３の実施形態の全体動作を説明するための図である。 本発明の第４の実施形態を説明するための図である。 本発明の第５の実施形態の全体動作を説明するための図である。 本発明の第６の実施形態の全体動作を説明するための図である。 アクション名とアクションの内容を例示した図である。

１０、１０ａ〜１０ｆ 通信ノード
１１ サーバ通信部
１２ フローテーブル管理部
１３ フローテーブル
１４ 転送処理部
１５ テーブル検索部
１６ アクション列設定部
１７ アクション抽出部
１８ アクション実行部
２０、２０ａ〜２０ｆ 制御サーバ
２１ フローエントリデータベース（フローエントリＤＢ）
２２ トポロジ管理部
２３ 経路・アクション計算部
２４ フローエントリ管理部
２５ ノード通信部
３０ 通信ノード

はじめに、本発明の概要について説明する。本発明の通信システムのノードは、受信パケットに付加されたアクションヘッダ内のアクション列（処理列）から、自装置が実行すべき処理を特定し、実行する機能を有している。

ここで、前記アクションヘッダは、データ転送ネットワークの転送経路上の個々のノードが実行すべき処理を並べたものである。個々のアクションとしては、例えば、（１）ヘッダ内の宛先／送信元ＩＰアドレス、宛先／送信元ＭＡＣアドレス（ヘッダ）、ＶＬＡＮ Ｔａｇ値を指定値に変更する、（２）パケットをドロップ（廃棄）する、（３）パケットを複数の指定ポート（インタフェース）から出力する（Ｏｕｔｐｕｔ）、などを定義することができる（図２９および非特許文献４の４頁−６頁「３．３・Ａｃｔｉｏｎｓ」、「Ｔａｂｌｅ５」参照）。図１の例では、受信パケットは、ＩＤ＝１のノードのポート＃５、ＩＤ＝２のノードのポート＃２、ＩＤ＝３のノードのポート＃３の順に送信されることになる。

このように、アクションヘッダを付加したパケットを出力させることで、次々に指定した経路上のノードに処理を行わせることが可能になる。従って、冒頭に述べたアクティブネットのように個々のノードにアクティブコードを送信等することは不要であり、また、経路上のノード内のフローテーブルへのエントリの追加処理等も不要となる。

なお、上記アクションヘッダの付加は、最初にパケットを受信したノードに実行させればよい。アクションヘッダ内のアクション列（処理列）は、外部の制御サーバなどに問い合わせて取得することとしてもよいし、当該ノード内に予め記憶されているアクション列（処理列）を埋め込むものとしてもよい。また、アクションヘッダの削除は、当該経路の終端となるノードに行わせればよい。

［第１の実施形態］
続いて、本発明の第１の実施形態について図面を参照して詳細に説明する。図２は、本発明の第１の実施形態に係る通信システムを示す図である。図２を参照すると、３つのノード１０と、制御サーバ２０と、ノード１０を経由して通信する通信ノード３０が示されている。なお、図２の例では、３つのノード１０と、制御サーバ２０と、２つの通信ノード３０を示しているが、それぞれの数は、あくまで例示であり、それぞれ任意の数とすることができる。

図３は、ノード１０の詳細構成を表した図である。図３を参照すると、ノード１０は、制御サーバ３０と通信するサーバ通信部１１と、フローテーブル１３を管理するフローテーブル管理部１２と、転送処理部１４とを備えて構成される。

さらに、転送処理部１４は、ユーザトラフィックとして受信したパケットに付加されているアクションヘッダから、自装置が実行すべきアクションを取り出して、アクション実行部１８に出力するアクション抽出部１７と、受信パケットにアクションヘッダが付加されていなかった場合に、フローテーブル１３を検索し、その結果をアクション列設定部１６に出力するテーブル検索部１５と、前記テーブル検索部１５にて検索されたエントリの自ノード以外のノードで実行すべきアクション列をアクションヘッダとして受信パケットに付加するアクション列設定部１６と、受信パケットに対し、アクション抽出部１７から出力されたアクション（自装置が実行すべきアクション）を実行するアクション実行部１８とを備えて構成される。また、アクション列設定部１６は、テーブル検索部１５によるフローテーブル１３の検索の結果、該当するエントリが無かった場合に制御サーバ２０に付加すべきアクション列を問い合わせる処理を行う。

本発明のノード１０は、オープンフロースイッチに、上記アクション抽出部１７およびアクション列設定部１６を追加した構成にて実現することも可能である。

図４は、制御サーバ２０の詳細構成を表した図である。図４を参照すると、制御サーバ２０は、フローエントリを格納したフローエントリデータベース（フローエントリＤＢ）２１と、ノード通信部２５を介して収集されたノード１０の接続関係に基づいてネットワークトポロジ情報を構築するトポロジ管理部２２と、トポロジ管理部２２にて構築されたネットワークトポロジ情報に基づいてパケットの転送経路および該転送経路上のノード１０に実行させるアクション列を求める経路・アクション計算部２３と、経路・アクション計算部２３にて計算された結果をフローエントリとしてフローエントリＤＢ２１に登録し、ノード１０からのフローエントリの追加または更新要求に応えるフローエントリ管理部２４と、ノード１０との通信を行うノード通信部２５とを備えて構成される。なお、ノード１０に対して追加または更新を指示したフローエントリを保持する必要が無い場合、フローエントリデータベース（フローエントリＤＢ）２１は省略することが可能である。また、フローエントリデータベース（フローエントリＤＢ）２１を別途外部サーバ等に設ける構成も採用可能である。

図５は、フローエントリＤＢ２１に格納されるフローエントリの例である。図５を参照すると、各エントリは、ＤＰＩＤ（データパスＩＤ）と、ＦｌｏｗＫｅｙ（フローキー；マッチングキー）と、Ａｃｔｉｏｎｓ（アクション列）とから構成される。図５の例では、ＡというＦｌｏｗＫｅｙ（フローキー；マッチングキー）に適合するパケットに、「Output to Port #9 by DPID 1／Output to Port #6 by DPID 2／Output to Port #1 by DPID 3」というアクション列が付与される。

図６は、ＦｌｏｗＫｅｙ（マッチングキー）のフィールド構成を示す図である。例えば、宛先アドレス（ＩＰ ＤＡ）が特定のサーバであるパケットを受信したノード１０にＡｃｔｉｏｎｓフィールド（可変長）に定義したアクションを実行させることが可能になる。同様に例えば、特定のポート（Ｉｎ Ｐｏｒｔ）から入力されたパケットについてＡｃｔｉｏｎｓフィールド（可変長）に定義したアクションを実行させることが可能になる。

制御サーバ２０は、オープンフローコントローラの上記フローエントリＤＢ２１の構成あるいはノード１０に対して追加または変更を指示するフローエントリの内容を変更することにより実現することも可能である。

続いて、上記したノード１０および制御サーバ３０の動作について説明する。図７は、上記ノード１０の動作を表したフローチャートである。図７を参照すると、ノード１０は、通信ノード３０や他のノード１０からパケットを受信すると（ステップＳ００１）、受信パケットのアクションヘッダから自装置が実行すべきアクションを抽出する（ステップＳ００２）。

前記アクションの抽出の結果、アクションを抽出できた場合（ステップＳ００３のＮｏ）、ノード１０は、自装置が実行すべきアクションを実行する（ステップＳ００９）。

一方、前記アクションの抽出の結果、アクションを抽出できなかった場合（ステップＳ００３のＹｅｓ）、ノード１０は、フローテーブル１３に、受信したパケットに適合するフローエントリがあるか否かを検索する（ステップＳ００４）。

前記フローテーブル１３の検索の結果、受信したパケットに適合するフローエントリが発見された場合（ステップＳ００５のＹｅｓ）、ノード１０は、自身が実行すべきアクションを抽出した上で（ステップＳ００８）、見つかったフローエントリのアクション列をアクションヘッダとして、受信パケットヘッダに付加する（ステップＳ００９）。例えば、受信したパケットがあるフローエントリＤＢ２１に登録済みのパケットの後続パケットであるような場合、上記のように前記フローテーブル１３からの検索結果を用いて、自身が実行すべきアクションの抽出とアクションヘッダの作成・付加が行われる。

一方、前記フローテーブル１３の検索の結果、受信したパケットに適合するフローエントリが見つからなかった場合（ステップＳ００５のＮｏ）、ノード１０は、受信パケットまたは受信パケットの一部を制御サーバ２０に送信し、アクション列の作成を要求する（ステップＳ００６）。

制御サーバ２０からアクション列を受信すると、ノード１０は、受信したフローエントリをフローテーブル１３に登録する（ステップＳ００７）。その後、ノード１０は、制御サーバ２０からパケット出力指示を受信する（ステップＳ０１１）。前記パケット出力指示がフローテーブルの検索指示を伴う場合（ステップＳ０１２のＹｅｓ）、ノード１０は、当該パケットに適合するフローエントリがあるか否かを再度検索し（ステップＳ００４−２）、自身が実行すべきアクションの抽出（ステップＳ００８）と、得られたアクション列をアクションヘッダとして受信パケットヘッダに付加する処理を行う（ステップＳ００９）。また、前記パケット出力指示がフローテーブルの検索指示でなく、当該パケットに対し実行すべきアクション（即ち、アクション列の付加と指定ポートからの出力）を伴う場合も同様に、当該アクションに従って、自身が実行すべきアクションの抽出（ステップＳ００８）と、得られたアクション列をアクションヘッダとして受信パケットヘッダに付加する処理を行う（ステップＳ００９）。

最後に、ノード１０は、自装置が実行すべきアクションを実行する（ステップＳ０１０）。

ここで、上記ステップＳ００９におけるアクション列の付加方法について説明する。本実施形態では、図８に示すように、受信したパケットの先頭にアクションヘッダを追加（カプセル化）することによってアクションヘッダを付加しているものとする。その他、アクション列を受信パケットのヘッダに埋め込む方法を採ることもできるが、これは第３の実施形態として説明する。

アクション列は、各ノード１０がそれぞれ実行すべきアクションを特定できる形態のものであれば、特に限定されない。例えば、図９（ａ）のように、各ノード１０が、適当なデリミタや別途設けたＬｅｎｇｔｈフィールド等に基づいて先頭から順番にアクションを取り出す構成を取ることができる。例えば、図９（ｂ）のように、各ノード１０が、先頭のポインタビットをインクリメント（１だけ加算）しながら、アクションを実行していく構成を取ることもできる。図９の（ａ）、（ｂ）いずれの場合もノード＃２は、ポート＃２から次ホップのノード＃３にパケットを転送し、ノード＃３は、ポート＃９から次ホップにパケットを転送していくことになる。

また、図９（ｃ）に示すように、各ノードのＩＤと実行すべきアクションを組にしたアクション列を用いることもできる。図９の（ｃ）の場合、ＩＤ：Ｂを持つノード＃２は、アクションヘッダ中の自装置のＩＤ：Ｂが付された「Ｂ２」を取り出し、ポート＃２から次ホップのノード＃３にパケットを転送し、ＩＤ：Ｃを持つノード＃３は、アクションヘッダ中の自装置のＩＤ：Ｃが付された「Ｃ９」を取り出し、ポート＃９から次ホップにパケットを転送していくことになる。このようなアクション列の場合、アクションの記載順序が、転送経路上のノードの順序と一致していなくともよく、その都度アクションヘッダを書き換えなくとも各ノード１０が自装置で実行すべきアクションを特定することが可能となる。

さらには、図９（ｄ）に示すように、各ノード１０についてそれぞれアクションヘッダ中のアクションを取り出すべき領域を決めておく方法を採ることもできる。図９の（ｄ）の場合、アクションヘッダのビット０−３からアクションを取り出すことが定められたノード＃２は、「２」を取り出し、ポート＃２から次ホップのノード＃３にパケットを転送し、アクションヘッダのビット４−９からアクションを取り出すことが定められたノード＃３は、「９」を取り出し、ポート＃９から次ホップにパケットを転送していくことになる。このようなアクション列の場合も、アクションの順序が、転送経路上のノードの順序と一致していなくともよく、その都度アクションヘッダを書き換えなくとも各ノード１０が自装置で実行すべきアクションを特定することが可能となる。

図１０は、上記制御サーバ２０の動作を表したフローチャートである。図１０を参照すると、制御サーバ２０は、上記図７のステップＳ００６のように、ノード１０からアクション列の作成要求を受け取ると（ステップＳ１０１）、トポロジ管理部２２にて構築されたネットワークトポロジ情報を取得し、パケットの転送経路を計算する（ステップＳ１０２）。

前記パケットの転送経路を計算の結果、経路を作成できない、経路上のノードが故障している等の理由により、転送できない場合（ステップＳ１０３のＮｏ）を除き、制御サーバ２０は、前記計算された転送経路に対応するアクションを計算し（ステップＳ１０４）、アクション列を生成する（ステップＳ１０５）。例えば、ＤＰＩＤ＃１のノード１０から、ＤＰＩＤ＃２のノード１０、ＤＰＩＤ＃３のノード１０という経路が求められている場合、「Output to Port #9 by DPID 1／Output to Port #6 by DPID 2／Output to Port #1 by DPID 3」というアクション列が生成される。

次に、アクション列の生成が完了すると、制御サーバ２０は、後続するパケットのマッチング判定するためのＦｌｏｗＫｅｙ（マッチングキー）を生成し、受信パケットに、前記計算したアクション列を設定しなさいという情報および当該受信パケットを受信したノードが実行すべきアクションとの２つの情報が定義されたフローエントリを生成する（ステップＳ１０６）。最後に、制御サーバ２０は、アクション列の要求元のノード１０にフローエントリを送信した後（ステップＳ１０７）、ノード１０がパケットをバッファしていない場合（ステップＳ１０８のＮｏ）、パケットの出力指示を行う（ステップＳ１０９）。このパケットの出力指示は、出力すべきパケット（受信パケット）と、当該パケットに対し実行すべきアクション（アクションヘッダを付加して指定ポートから出力処理）とを指示すること、あるいは、出力すべきパケット（受信パケット）と、フローテーブルの検索を指示することによって行われる。なお、ノード１０がパケットをバッファしている場合（ステップＳ１０８のＹｅｓ）、後記図１３、図１４で説明するようにパケットの送信は省略される。

図１１は、上記通信ノードＡから送出されたパケット（受信パケット）に基づいて、新しいフローエントリが登録され、当該パケット（受信パケット）が次ホップに転送されるまでの流れを表したシーケンス図である。

上述したとおり、ノード１０は、受信したパケットにアクションヘッダが付加されていないと判断すると、すでにフローエントリ作成済みのフローであるかどうかフローテーブル１３の検索を行う（図７のステップＳ００４に同じ）。この時点では、フローテーブル１３に該当するエントリは登録されていないため、ノード１０は、制御サーバ２０に対し、アクション列の作成を要求する（図７のステップＳ００６に同じ）。

前記アクション列の作成要求を受けた制御サーバ２０は、上述したように、受信パケットの転送経路およびアクション列を計算し、前記受信パケットに、前記計算したアクション列を設定しなさいという情報および当該受信パケットを受信したノードが実行すべきアクションとの２つの情報を持つフローエントリを生成する（図１０のステップＳ１０２からＳ１０６に同じ）。

上述したとおり、フローエントリを受信したノード１０は、フローエントリをフローテーブル１３に登録する（図７のステップＳ００７に同じ）。

その後、制御サーバ２０からパケット出力指示を受信すると、ノード１０は、自身が実行すべきアクションを抽出し（図７のステップＳ００８に同じ）、さらに、受信したパケットにアクションヘッダを付加して（図７のステップＳ００９に同じ）、指定ポートから出力する（図７のステップＳ０１０に同じ）。

図１２は、図１１の動作シーケンスを変形したものである。図１１の動作シーケンスとの相違点は、制御サーバ２０がフローエントリの送信後、図１０のステップＳ１０９のパケット出力指示において、出力すべきパケット（受信パケット）と、アクションとしてフローテーブルの検索を指示する点である。

前記指示を受けたノード１０は、受信パケットをキーとして、フローテーブルの検索を再度実行する（図１２のステップＳ００４−２）。先のステップＳ００７にて、フローエントリの登録を行っているため、受信パケットに対応するフローエントリが検索される。ノード１０は、受信パケットに、前記フローエントリから自身が実行すべきアクションを抽出し（図７のステップＳ００８に同じ）、アクションヘッダを付加して（図７のステップＳ００９に同じ）、指定ポートから出力する（図７のステップＳ０１０に同じ）。

さらに、ノード１０のパケットのバッファ機能がある場合、図７のフローチャートは、図１３のフローチャートに置き換えられ、図１１の動作シーケンスは、図１３のシーケンスに置き換えられる。図７のフローチャートおよび図１１の動作シーケンスと、図１３のフローチャートおよび図１４の動作シーケンスとの相違点は、パケット保存処理（ステップＳ０２１）と、パケット取り出し処理（ステップＳ０２２）が追加され、制御サーバ２０からのパケット出力指示が省略されている点である。図１３、図１４の例では、ノード１０から制御サーバ２０へのアクション列作成要求に、受信パケットを格納したバッファＩＤを添付しておき、制御サーバ２０からノード１０へのフローエントリ送信時に、前記受信したバッファＩＤを添付することで、ノード１０は、フローエントリ登録後（ステップＳ００７）、指定されたバッファＩＤから受信パケットを取り出し（ステップＳ０２２）、自身が実行すべきアクションの抽出およびアクションヘッダの付加を行って（ステップＳ００８−Ｓ００９）、指定ポートから出力している（ステップＳ０１０）。

図１５〜図１７を参照して、ここまで説明した一連の動作を整理して説明する。通信ノードＡが通信ノードＢに宛てて、ヘッダＸを持つパケットを送信すると（図１５の（１））、パケットを受信したノード＃１は、自装置のフローテーブルを検索するが該当するエントリが無いため、制御サーバ２０にそのパケットに対応するアクション列生成を要求する（図１５の（２）Packet-In）。

制御サーバ２０は、ノード＃１から送信されたパケットに対応するアクション列（Ａｃｔｓ）および適切なマッチングキー（Ｘ）を設定したフローエントリを生成し、ノード＃１に返送する（図１５の（４）FlowMod（Add））。

図１６は、ノード＃１がフローエントリをフローテーブルに登録した状態を示している。この状態で、制御サーバ２０が、ノード＃１にパケット出力指示を出すと（図１６の（５）Packet-Out）、ノード＃１は、受信パケットにアクションヘッダ（Ａｃｔｓ）を付加してノード＃２に転送する（図１６の（６））。

ノード＃２は、アクションヘッダ（Ａｃｔｓ）に含まれる自身が実行すべきアクションを読み出してポート＃５から前記受信パケットを出力する。ノード＃２から出力されたパケットは、ノード＃３に入力される。

ノード＃３は、アクションヘッダ（Ａｃｔｓ）に含まれる自身が実行すべきアクションを読み出してアクションヘッダ（Ａｃｔｓ）を削除した上でポート＃９から前記受信パケットを出力する。ノード＃３から出力されたパケットは、通信ノードＢに入力される（図１６の（７））。

その後は、図１７に示すように、通信ノードＡが通信ノードＢに宛てて、後続するパケットを送信すると（図１７の（８））、パケットを受信したノード＃１は、制御サーバ２０に問い合わせることなく、自装置のフローテーブルを検索し、該当するエントリのアクション列からアクションヘッダを生成してノード＃２に送信する（図１７の（９））。その後は、ノード＃２、ノード＃３の順にパケットが転送され、最後に、通信ノードＢに到達する（図１７の（１０））。

なお、経路が長い場合や、アクションヘッダの長さに制約がある場合、経路の途中のノードにアクションヘッダを取得させる必要が生じることがある（この動作を「息継ぎ処理」という。）。この場合、図１８に示すように、途中のノードに、アクション列の生成要求を行わせ（図１８の（１）Packet-In）、後続するノードに実行させるアクション列を取得させて、アクションヘッダを付加させればよい。

制御サーバ２０は、経路およびアクション列の計算時に、上記息継ぎ処理が必要となるノードを求めることができる。上記息継ぎ処理は、その必要が生じたときに行うだけでなく、事前に該当するノードにフローエントリを送信することによっても実現できる。

例えば、図１９に示すように、制御サーバ２０がアクション列の生成要求を受けた際に（図１９の（１）Packet-In）、ノード＃１だけでなく（図１９の（２）FlowMod）、ノード＃ｎ−１にもフローエントリを送信してしまうことができる（図１９の（３）FlowMod）。

［第２の実施形態］
続いて、本発明の第２の実施形態について図面を参照して詳細に説明する。図２０は、本発明の第２の実施形態に係る通信システムを示す図である。図２に示した第１の実施形態との相違点は、各ノード１０ａが、アクションテーブルを備えており、アクションテーブルのポインタを指示することによりアクションを特定できるようになっている点である。

図２１は、本発明の第２の実施形態の制御サーバ２０ａのフローエントリＤＢに格納されるフローエントリの例である。図２１を参照すると、各エントリは、ＤＰＩＤ（データパスＩＤ）と、ＦｌｏｗＫｅｙ（フローキー；マッチングキー）と、アクションを実行すべきのノードおよびそのアクションテーブルのポインタとから構成される。

本実施形態によれば、アクションヘッダのサイズあるいはアクションヘッダに収容するアクションの数を増やすことが可能となる。もちろん、本実施形態においても、図２２に示すように、経路途中のノード１０ａに息継ぎ処理を行わせることが可能である。例えば、図２２のノード＃ｎ−１で息継ぎ処理が必要であることが判っている場合は以下のとおりとなる。まず、ノード＃ｎ−１のアクションテーブルに、受信パケットに、後続ノード＃ｎ以下に実行させるアクション列を記載したアクションヘッダを付加して送信する旨のアクションを格納しておく。そして、ノード＃ｎ−１に当該アクションを実行させるポインタが入ったアクションヘッダが入力されるようにすればよい。

［第３の実施形態］
続いて、本発明の第３の実施形態について図面を参照して詳細に説明する。上記第１、第２の実施形態では、アクションヘッダは受信パケットの先頭に追加する形で付加するものとして説明したが（図８参照）、図２３に示すように、受信パケットのヘッダの一部を書き換える態様を採ることも可能である。

図２４は、受信パケットのＭＡＣ ＤＡフィールド一部にアクション列を格納した場合のフレームフォーマットを示す図である。ＭＡＣ ＤＡフィールドの先頭から７、８ビット目（または１オクテット目の下位２ビット）を除く４６ビットをアクション列の格納領域とした場合を考える。各ノードの出力ポートが最大６４ポートだとすると、ポートは６ビットで一意に特定できる。従って、図９の（ａ）のように、ポートだけを並べる形式ならば最大７個のアクションを収容することが可能になる。また、図９（ｃ）に示すように、各ノードのＩＤを付加する場合には、例えば、各ノードのＩＤの長さを８ビットとすると、最大３個のアクションを収容することが可能になる。なお、図２４の例では、ＭＡＣ ＤＡフィールドを用いているが、ＭＡＣ ＳＡフィールドやその他フィールドを用いてもよい。さらに、ＭＡＣ ＤＡフィールドとＭＡＣ ＳＡフィールドを連続して用いてしまってもよい。この場合、上記した収容可能なアクションの数はそれぞれ増大する。

上記のようにＭＡＣ ＤＡフィールドを利用してアクション列を埋め込む場合、最終ホップでＭＡＣ ＤＡフィールドを復元する動作が必要になる。以下、図２５を参照して、本実施形態の動作を説明する。通信ノードＡが通信ノードＢに宛てて、ヘッダＸを持つパケットを送信すると（図２５の（１））、パケットを受信したノード＃１は、自装置のフローテーブルを検索するが該当するエントリが無いため、制御サーバ２０ｂにそのパケットに対応するアクション列生成を要求する（図２５の（２）Packet-In）。

制御サーバ２０ｂは、ノード＃１から送信されたパケットのマッチングキー（Ｘ）およびヘッダをアクション列入りヘッダ（Ｘ’）に置き換えるアクションを設定したフローエントリを生成し、ノード＃１に返送する（図２５の（４）FlowMod（Add））。また、制御サーバ２０ｂは、アクション列入りヘッダ（Ｘ’）を元のヘッダ（Ｘ）に復元してから所定ポートに出力するアクションを設定したフローエントリを生成し、経路の最終ホップとなるノード＃３に送信する（図２５の（５）FlowMod（Add））。

その後、制御サーバ２０ｂが、ノード＃１に対し、ヘッダをアクション列入りヘッダ（Ｘ’）としたパケットのパケット出力指示を出すと（図２５の（６）Packet-Out）、ノード＃１は、受信パケットをノード＃２に転送する（図２５の（７））。

ノード＃２は、アクション列入りヘッダ（Ｘ’）に含まれる自身が実行すべきアクションを読み出してポート＃５から前記受信パケットを出力する。ノード＃２から出力されたパケットは、ノード＃３に入力される。

ノード＃３は、アクション列入りヘッダ（Ｘ’）に対応するフローエントリを取り出して、アクション列入りヘッダ（Ｘ’）を元のヘッダ（Ｘ）に復元した後で、ポート＃９から前記復元後のパケットを出力する。ノード＃３から出力されたパケットは、通信ノードＢに入力される。

その後は、図２５に示すように、通信ノードＡが通信ノードＢに宛てて、後続するパケットを送信すると（図２５の（９））、パケットを受信したノード＃１は、制御サーバ２０ｂに問い合わせることなく、自装置のフローテーブルを検索し、該当するエントリの内容に従い、アクション列入りヘッダ（Ｘ’）を付加したパケットをノード＃２に送信する（図２５の（１０））。その後は、ノード＃２、ノード＃３の順にパケットが転送され、最後に、通信ノードＢに到達する（図２５の（１１））。

以上のような本実施形態によれば、第１の実施形態と比べて、アクションヘッダの分だけオーバーヘッドを低減することが可能になる。

また、本実施形態と、第２の実施形態とを組み合わせることも可能であり、例えば、図２５のように、各ノードのアクションテーブル上のアクションを指示するポインタを用いることとすれば、一ヘッダに、より多くのアクションを収容することが可能になる。この場合の最終ホップにおけるヘッダの復元は、ノード＃３のアクションテーブルにヘッダ（Ｘ’）をヘッダ（Ｘ）に戻すアクションを格納しておき、ノード＃３に当該アクションを示すポインタ（００ｘ５）を指示してやればよい。

上記ヘッダ復元処理は、種々の方法により実現することができる。例えば、図２７に示すように、最終ホップのノード＃３のフローテーブルに、次のアクションを実行させるフローエントリを追加することができる。まず、（１２）Ｘ’からＩＰ ＤＡ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｄｅｓｔｉｎａｔｉｏｎ Ａｄｄｒｅｓｓ）を取得し、（１３）Ｉｎ Ｐｏｒｔ以外のポートにＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ） Ｒｅｑｕｅｓｔを送信し、（１４）ＩＰ ＤＡに該当するＭＡＣ ＤＡを取得する。（１５）取得したＭＡＣ ＤＡを用いてヘッダを復元した後、（１６）ＭＡＣ ＤＡの受信ポートにパケットを送信する。

また例えば、ＭＡＣ ＳＡフィールドをアクション列の格納に用いていない場合には、図２８に示すように、ＭＡＣ ＤＡフィールドの内容（００：００：００：００：００：０１）を、ＭＡＣ ＳＡフィールドに退避させた後に、ＭＡＣ ＤＡフィールドにアクション列を格納し、最終ホップのノード＃３に、ＭＡＣ ＳＡフィールドの内容を用いてＭＡＣ ＤＡフィールドを書き戻してやるアクションを実行させる方法も用いることができる。なお、図２８の例では、ＭＡＣ ＳＡフィールドにアドレス（００：００：００：００：００：０２）を入れているが、この値は適当な値でかまわない。

なお、アクション列の収容先としては、図２４の例に限られず、ＭＡＣ ＳＡフィールド、ＶＡＮ＿ＩＤ（ＶＩＤ）、Ｔｙｐｅ等のその他のフィールドを用いることもできる。またこのほか、上位レイヤのヘッダやデータ領域等の予め定めた位置にアクション列を収容する態様も採用可能である。

以上、本発明の好適な実施形態を説明したが、本発明は、上記した実施形態に限定されるものではなく、本発明の基本的技術的思想を逸脱しない範囲で、更なる変形・置換・調整を加えることができる。上記した実施形態の制御サーバ２０、２０ａ〜２０ｆは、専用のサーバとして実現することもでき、ノード１０、１０ａ〜１０ｆとしては、上記オープンフロースイッチのほか、ＩＰ網におけるルータ、ＭＰＬＳ（Ｍｕｌｔｉ−Ｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ）網におけるＭＰＬＳスイッチにて実現することができる。その他、サーバがネットワーク内のノードを集中管理するようなネットワークであれば、本発明を適用することが可能である。

また、本発明の動作からも明らかなように、アクション列を設定するアクション列設定部１６は、経路の始点となる入り口ノード（例えば、図１８のノード＃１）と、息継ぎ処理を行うノード（例えば、図１８のノード＃ｎ−１）にあればよい。従って、ネットワーク内のどのノードが、入り口ノードと息継ぎ処理を行うノードに該当するかが判っている場合には、アクション列設定部１６を省略することが可能である。

本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の請求の範囲（クレーム）の枠内において、種々の開示要素の多様な組み合せないし選択が可能である。

データセンタなどの商用ネットワークでは、ＱｏＳ（Ｑｕｏｒｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）や、負荷分散のため、宛先アドレス、送信元アドレス、使用プロトコルといった様々な条件により、パケットの転送経路を厳密に制御する必要がある。本発明によれば、少なくとも中間の息継ぎ処理を要しないノードのフローテーブルが不要となり、また、フローテーブルが必要となるノードにおいても、そのエントリ数を削減することが可能となる。したがって、本発明はデータセンタなどの商用ネットワークへ好適に適用可能である。

Claims (22)

1. パケットの転送経路の少なくとも一部を構成する、第１及び第２のノードを含む複数のノードを備え、
   前記第１のノードは、受信パケットの所定領域を、前記第１のノードと前記第２ノードとを中継する中継ノードで実行されるパケット処理に関する情報に置換する第１の手段を含み、
   前記第２のノードは、前記パケット処理に関する情報に置換された前記所定領域を復元する第２の手段を含む
   ことを特徴とする通信システム。
2. 前記第１の手段は、当該受信パケットのヘッダに含まれる情報に基づいて前記パケット処理に関する情報を取得する
   ことを特徴とする請求項１に記載の通信システム。
3. 前記第１の手段は、前記パケット処理に関する情報が前記受信パケットに含まれていない場合、当該受信パケットのヘッダに含まれる情報に基づいて前記パケット処理に関する情報を取得する
   ことを特徴とする請求項２に記載の通信システム。
4. 前記第１の手段は、前記第１のノードが実行すべきパケット処理に関する情報が前記受信パケットに含まれていない場合、当該受信パケットのヘッダに含まれる情報に基づいて前記パケット処理に関する情報を取得する
   ことを特徴とする請求項３に記載の通信システム。
5. 前記複数のノードを制御する制御装置を更に備え、
   前記第１のノードに対して前記受信パケットの前記所定領域を前記パケット処理に関する情報に置換するための指示を送信する
   ことを特徴とする請求項１または２に記載の通信システム。
6. 前記第１の手段は、前記制御装置に対して、前記パケット処理に関する情報に関する問い合わせを行う第５の手段を含む
   ことを特徴とする請求項５に記載の通信システム。
7. 前記第１の手段は、前記第１のノードが実行すべきパケット処理が前記受信パケットに含まれておらず、かつ、当該受信パケットのヘッダに含まれる情報から前記パケット処理に関する情報を取得できない場合、前記問い合わせを行う
   ことを特徴とする請求項６に記載の通信システム。
8. 前記制御装置は、
   前記問い合わせに応じて、当該第１のノードに対して、受信パケットの所定領域を前記パケット処理に関する情報に置換するための指示を送信し、
   前記第２のノードに対して、前記パケット処理に関する情報に置換された前記所定領域を復元するための指示を送信する
   ことを特徴とする請求項６又は７に記載の通信システム。
9. 前記第１の手段は、前記所定領域を、前記中継ノードが有するパケット処理リストから各ノードが実行するパケット処理を特定するための識別情報に置換可能である
   ことを特徴とする請求項１乃至８のいずれか１項に記載の通信システム。
10. 前記パケット処理に関する情報は、前記パケット処理に関する情報から前記中継ノードが実行するパケット処理を特定するためのポインタによって記述されている
    ことを特徴とする請求項１乃至８のいずれか１項に記載の通信システム。
11. 前記中継ノードは、前記パケット処理に関する情報に対応する１つ以上のパケット処理を実行した後、前記受信パケットに含まれる前記パケット処理に関する情報を更新する
    ことを特徴とする請求項１乃至８のいずれか１項に記載の通信システム。
12. 前記パケット処理に関する情報は、前記パケット処理を実行するノードの順番で並べられており、前記パケット処理に関する情報に従って、パケットが前記中継ノードに転送されていく
    ことを特徴とする請求項１乃至８のいずれか１項に記載の通信システム。
13. 前記パケット処理に関する情報は、前記パケット処理を実行するノードと対応付けて記載されており、前記中継ノードが、前記識別情報から自装置に対応付けられたパケット処理を抽出して実行する
    ことを特徴とする請求項１乃至８のいずれか１項に記載の通信システム。
14. パケットの転送経路の少なくとも一部を構成する、第１及び第２のノードを含む複数のノードを制御する制御装置であって、
    前記第１及び第２のノードに通知する指示を生成する第１の手段と、
    前記第１のノードに対して、受信パケットの所定領域を、前記第１のノードと前記第２ノードとを中継する中継ノードで実行されるパケット処理に関する情報に置換するための指示を送信し、前記第２のノードに対して、前記パケット処理に関する情報に置換された前記所定領域を復元するための指示を送信する第２の手段と、
    を備えることを特徴とする制御装置。
15. 前記第２の手段は、
    前記第１のノードからの問い合わせに応じて、前記第１のノードに対して前記所定領域を前記パケット処理に関する情報に置換するための指示を送信し、
    前記第２のノードに対して前記パケット処理に関する情報に置換された前記所定領域を復元するための指示を送信する
    ことを特徴とする請求項１４に記載の制御装置。
16. 前記第１の手段は、前記中継ノードで実行されるパケット処理を決定する
    ことを特徴とする請求項１４又は１５に記載の制御装置。
17. 前記第１の手段は、前記パケット処理を実行するノードの順番で並べられており、前記パケット処理に関する情報に従って、パケットが前記中継ノードに転送されていくように当該パケット処理に関する情報を作成する
    ことを特徴とする請求項１６に記載の制御装置。
18. 前記第１の手段は、前記パケット処理を実行する前記中継ノードとパケット処理と対応付けて記述され、前記パケット処理に関する情報から前記中継ノードが自装置に対応付けられたパケット処理を抽出して実行できるよう当該パケット処理に関する情報を作成する
    ことを特徴とする請求項１６に記載の制御装置。
19. 前記第２の手段は、前記第１のノードに対して、前記所定領域を、前記中継ノードが有するパケット処理リストから各ノードが実行するパケット処理を特定するための識別情報に置換するための指示を送信する
    ことを特徴とする請求項１４乃至１７のいずれか１項に記載の制御装置。
20. パケットの転送経路の少なくとも一部を構成する、第１及び第２のノードを含む複数のノードを含む通信システムにおいて、
    前記第１のノードが、受信パケットの所定領域を、前記第１のノードと前記第２のノードとを中継する中継ノードで実行されるパケット処理に関する情報に置換し、
    前記第２のノードが、前記パケット処理に関する情報に置換された前記所定領域を復元する
    ことを特徴とする通信方法。
21. パケットの転送経路の少なくとも一部を構成する、第１及び第２のノードを含む複数のノードを制御する制御方法であって、
    前記第１及び第２のノードに通知する指示を生成し、
    前記第１のノードに対して、受信パケットの所定領域を、前記第１のノードと前記第２ノードとを中継する中継ノードで実行されるパケット処理に関する情報に置換するための指示を送信し、
    前記第２のノードに対して、前記パケット処理に関する情報に置換された前記所定領域を復元するための指示を送信する、
    ことを特徴とする制御方法。
22. パケットの転送経路の少なくとも一部を構成する、第１及び第２のノードを含む複数のノードを制御する制御装置に実行させる制御プログラムであって、
    前記第１及び第２のノードに通知する指示を生成する処理と、
    前記第１のノードに対して、受信パケットの所定領域を、前記第１のノードと前記第２ノードとを中継する中継ノードで実行されるパケット処理に関する情報に置換するための指示を送信する処理と、
    前記第２のノードに対して、前記パケット処理に関する情報に置換された前記所定領域を復元するための指示を送信する処理と、を前記制御装置に実行させる
    ことを特徴とする制御プログラム。

Images