JP6635138B2 - 通信ノード、通信システム、更新方法及び更新プログラム - Google Patents

Description

本発明は、通信ノード、通信システム、更新方法及び更新プログラムに関し、特に、受信パケットの処理ルールを定義したフローエントリを更新する通信ノード、通信システム、更新方法及び更新プログラムに関する。

ＯｐｅｎＦｌｏｗ技術は、通信をＥｎｄ−ｔｏ−Ｅｎｄのフロー（ｆｌｏｗ）として捉え、フロー単位で経路制御、障害回復等を行うものである（例えば、特許文献１の段落０００２等）。転送ノードとして機能するＯｐｅｎＦｌｏｗＳｗｉｔｃｈ（ＯＦＳ）は、ＯＦＳを制御するＯｐｅｎＦｌｏｗＣｏｎｔｒｏｌｌｅｒ（ＯＦＣ）との間で、通信用のセキュアチャネル（Ｓｅｃｕｒｅ Ｃｈａｎｎｅｌ）を備える。そして、ＯＦＳは、ＯＦＣから適宜追加または書き換え指示されるフローテーブルに従って動作する。フローテーブルには、フロー毎に、パケットヘッダと照合するルールと、処理内容を定義したアクション（Ａｃｔｉｏｎ）と、フロー統計情報との組が定義される。ここで、ＯＦＳは、通信中継装置の一例であり、ＯＦＣは、通信制御装置の一例である。

また、ＯＦＣは、障害耐性を高めるために、複数台でクラスタ構成により運用されることがある。この場合、一方のＯＦＣを稼働系（ＡＣＴ）、他方のＯＦＣを待機系（ＳＢＹ）とし、稼働系に障害が発生したときには自動的に待機系に切り替わる構成としている。また、障害時ばかりでなく、制御ソフトウェア等を更新するなどのメンテナンスのために、任意のタイミングで稼働系と待機系のＯＦＣを切り替える場合もある。ここで、ＡＣＴ−ＳＢＹ型のクラスタを利用した、サービスを止めずに行うソフトウェアアップデート方式としてローリングアップデート技術がある。ローリングアップデート技術では、稼働系及び待機系のＯＦＣの間で一部のデータが同期されており、待機系でも稼働系と同じ内部イベントを受け取る。そして、先に待機系のソフトウェアを更新し、クラスタの切り替えを行い、その後、切替後の待機系（元の稼働系）のソフトウェアを更新することで、サービスを止めずに双方のソフトウェアの更新を行うものである。

また、ＤＭＴ（Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ Ｔｒｅｅ）ベースのデバイス管理技術としてＯＭＡ−ＤＭ（Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ−Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ）がある（例えば、特許文献２の段落０００４及び０００５等）。

まず、ＤＭＴは、デバイス管理を行うために使用される木構造データである。各ノードの名前は、ＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）として表すことができる。そのため、ネットワーク上デバイス管理サーバや組み込み機器内のデバイス管理アプリは、ＵＲＩを指定することでＤＭＴ内の任意のノードに対して読み書きや実行命令の発行を行うことができる。また、ＤＭＴにノードを動的に追加することも可能である。

また、ＯＭＡ−ＤＭは、３Ｇ携帯電話やＷＩＭＡＸ（Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ）で運用されている遠隔デバイス管理プロトコルの規格である。規格化団体は、ＯＭＡ（Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ）である。ＯＭＡ−ＤＭは、ＤＭＴに相当するＭＯ（Ｍａｎａｇｅｍｅｎｔ Ｏｂｊｅｃｔ）という単位でデバイスの管理を行う。ＯＭＡ−ＤＭが提供する標準ＭＯは、ＦＵＭＯ（遠隔ファームウエア更新）、ＳＣＯＭＯ（遠隔ＳＷ更新）、ＤｉａｇＭｏｎ（遠隔診断）、ＬＡＷＭＯ（遠隔セキュリティーロック）などがある。

また、ＭＤＡ（登録商標）（Ｍｏｄｅｌ Ｄｒｉｖｅｎ Ａｒｃｈｉｔｅｃｔｕｒｅ）とは、モデルとして表現される構造的仕様のガイドラインを提供するソフトウェア開発手法である。ＭＤＡを用いると、ＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）開発ツールを用いて記述されたモデルから、機械語プログラムを自動生成することが可能となる。ＭＤＡを用いた開発ツールとしては、例えば、ＢｒｉｄｇｅＰｏｉｎｔやＲｈａｐｓｏｄｙなどがあり、組み込み系ソフトウェア開発に用いられている。また、ＭＤＡには、ＳＱＬの構文を一部取り入れたアクション記述言語をサポートしたＥｘｅｃｕｔａｂｌｅ ＵＭＬ（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ）という手法がある。

特開２０１２−０４９６７４号公報 特開２０１２−０６３８２６号公報

ここで、ＯＦＳ等の通信ノードにおける受信パケットの処理ルールを定義したフローエントリを既存のプロトコルに従って更新しようとすると、通常のフロー制御の通信への影響が大きくなるおそれがあるという問題点がある。まず、既存のプロトコルに従ってフローエントリを更新するには、ＯＦＣ等の通信制御装置から更新用コマンド（例えばOpenflowの場合、flow_mod）を通信中継装置へ送信する必要がある。しかし、更新用コマンドは、フローエントリの更新単位が限られているため、きめ細かな更新が行えない。そのため、更新内容によっては、通信制御装置と通信ノードの間でフローエントリ間の状態整合処理等の通信量が膨大となり得る。よって、通常のフロー制御の通信への影響が大きくなるおそれがある。

本発明は、このような問題点を解決するためになされたものであり、通信への影響を抑えつつ、受信パケットの処理ルールを定義したフローエントリを更新するための通信ノード、通信システム、更新方法及び更新プログラムを提供することを目的とする。

本発明の第１の態様にかかる通信ノードは、
通信制御装置により制御される通信ノードであって、
受信パケットの処理ルールを定義したフローエントリを記憶する記憶手段と、
前記フローエントリの更新に用いる更新情報を受信する受信手段と、
前記更新情報を用いて前記更新を実行する更新手段と、
を備え、
前記更新手段は、前記通信制御装置から通知される更新指示に従って前記更新を開始し、
前記更新指示は、前記更新を開始するタイミングを示す情報を含む
ことを特徴とする。

本発明の第２の態様にかかる通信システムは、
受信パケットの処理ルールを定義したフローエントリを記憶し、前記フローエントリを用いて当該受信パケットを処理する通信ノードと、
前記通信ノードに対して、前記フローエントリの更新に用いる更新情報を送信する通信制御装置と、
を含み、
前記通信ノードは、前記通信制御装置から通知される更新指示に従って前記フローエントリの更新を開始し、
前記更新指示は、前記更新を開始するタイミングを示す情報を含む
ことを特徴とする。

本発明の第３の態様にかかる更新方法は、
受信パケットの処理ルールを定義したフローエントリの更新方法であって、
前記フローエントリを記憶する記憶手段と、
前記フローエントリの更新に用いる更新情報を用いて前記更新を実行する更新手段と、
を備える通信ノードにおいて、
前記更新情報を受信するステップと、
通信制御装置から通知される更新指示に従って前記更新を開始するステップと、
を含み、
前記更新指示は、前記更新を開始するタイミングを示す情報を含む
ことを特徴とする。

本発明の第４の態様にかかる更新プログラムは、
受信パケットの処理ルールを定義したフローエントリを記憶する記憶手段と、
前記フローエントリの更新に用いる更新情報を受信する受信手段と、
前記更新情報を用いて前記更新を実行する更新手段と、
を備えるコンピュータに、
通信制御装置から通知される更新指示に含まれる前記更新を開始するタイミングに従って前記更新を開始させる
処理を実行させることを特徴とする。

本発明により、通信への影響を抑えつつ、受信パケットの処理ルールを定義したフローエントリを更新するための通信ノード、通信システム、更新方法及び更新プログラムを提供することができる。

本発明の実施の形態１にかかる通信中継装置の構成を示すブロック図である。 本発明の実施の形態１にかかる中継定義情報の更新処理の流れを示すフローチャートである。 本発明の実施の形態２にかかるＯｐｅｎＦｌｏｗネットワークシステムの構成を示すブロック図である。 本発明の実施の形態２にかかる管理サーバ及びＯＦＳの概要構成を示すブロック図である。 本発明の実施の形態２にかかるＯＦＳのハードウェア構成を示すブロック図である。 本発明の実施の形態２にかかるＯＦＳ内のＣＰＵ上で動作するソフトウェア構成の概念図である。 本発明の実施の形態２にかかる更新ソフトウェアの配信処理の流れを説明するためのシーケンス図である。 本発明の実施の形態２にかかるＯＦＣの系切替時におけるＯＦＳのフローテーブル更新処理の流れを説明するためのシーケンス図である。

以下では、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。各図面において、同一要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略する。

＜発明の実施の形態１＞
図１は、本発明の実施の形態１にかかる通信中継装置１００の構成を示すブロック図である。通信中継装置１００は、端末１１と端末１２との間の通信の中継を行う装置である。端末１１と端末１２とは、通信パケット等を、通信中継装置１００を介して送受信する通信装置である。

通信中継装置１００は、記憶部１１０と、取得部１２０と、更新部１３０とを備える。記憶部１１０は、中継定義情報１１１ａ、１１１ｂ、・・・及び１１１ｎと、更新情報１１２とを記憶する記憶装置である。中継定義情報１１１ａ〜１１１ｎは、端末間の通信の中継に関する定義を示す情報である。例えば、通信パケットヘッダと照合するルールと、処理内容を定義したアクション（Ａｃｔｉｏｎ）と、フロー統計情報との組が識別情報と対応付けられたものである。更新情報１１２は、中継定義情報１１１ａ〜１１１ｎのうち２以上（例えば、中継定義情報１１１ａ及び１１１ｂ）を更新するための更新内容の定義を含む情報である。例えば、更新対象の中継定義情報の識別情報や、更新後の中継定義情報の値等である。さらに、更新情報１１２は、中継定義情報１１１ａ〜１１１ｎのうち２以上を更新するための更新指示を含むものであってもよい。

取得部１２０は、更新情報１１２を外部から取得する。また、更新情報１１２に更新指示が含まれていない場合には、取得部１２０は、更新情報１１２とは別に、複数の中継定義情報を更新するための更新指示を取得する。更新部１３０は、更新指示に応じた所定のタイミングにより、更新情報１１２に基づく更新処理を実行する。

図２は、本発明の実施の形態１にかかる中継定義情報の更新処理の流れを示すフローチャートである。まず、通信中継装置１００の記憶部１１０には予め中継定義情報１１１ａ〜１１１ｎが記憶されているものとする。尚、記憶部１１０には少なくとも２以上の中継定義情報が記憶されていればよい。

通信中継装置１００の取得部１２０は、外部から更新情報１１２を取得する（Ｓ１１）。例えば、更新情報１１２には、中継定義情報１１１ａ及び１１１ｂに対する更新内容が含まれるものとする。次に、通信中継装置１００の更新部１３０は、所定のタイミングであるか否かを判定する（Ｓ１２）。所定のタイミングとしては例えば、上記更新指示により設定された時刻、又は、上記更新指示を受け付け又は検出したタイミング等であってもよい。

所定のタイミングでない場合は、所定時間経過後、再度、ステップＳ１２を行う。所定のタイミングと判定された場合、更新部１３０は、更新情報に基づき、例えば、中継定義情報１１１ａ及び１１１ｂを更新する（Ｓ１３）。

このように、本発明の実施の形態１では、複数の中継定義情報の更新情報をまとめて取得し、１回のトリガ（更新タイミング）により更新処理を行うことで、更新のための通信量を抑制できる。つまり、通信中継装置１００に対して外部から各中継定義情報に対する個別の更新命令を逐次、受信することを回避できる。そのため、端末間の通信への影響を抑えつつ、効率的に更新をすることができる。

尚、通信中継装置１００は、他の複数の通信中継装置の間の通信の中継を行うものであってもよい。そのため、上述した中継定義情報は、装置間の通信の中継に関する定義を示す情報といえる。

＜発明の実施の形態２＞
本発明の実施の形態２は、上述した実施の形態１の応用例であり、ＯｐｅｎＦｌｏｗ技術に基づくネットワークシステムを対象とした場合について説明する。但し、本発明は、ＯｐｅｎＦｌｏｗ技術に限定されない。また、以下では、通信中継装置の一例としてＯＦＳ（ＯｐｅｎＦｌｏｗ Ｓｗｉｔｃｈ）、通信中継装置を制御する通信制御装置の一例としてＯＦＣ（ＯｐｅｎＦｌｏｗ Ｃｏｎｔｒｏｌｌｅｒ）を用いる。また、中継定義情報の一例としてＯＦＳに内蔵されるフローテーブルにおける各フローエントリを用いる。但し、通信中継装置、通信中継装置及び中継定義情報の例は、これらに限定されない。

ここで、ＯＦＣがローリングアップデート機能をサポートした場合、下位互換性（ｂａｃｋｗａｒｄ ｃｏｍｐａｔｉｂｉｌｉｔｙ）を保証しなければならない。そのため、過去バージョンの仕様（プロトコルの仕様など）に不十分な点が見つかったとしても、新バージョンで変更できないという問題があった。

例えば、旧仕様のＯＦＣ（旧ＡＣＴ）と新仕様のＯＦＣ（新ＡＣＴ）でｃｏｏｋｉｅの値を変更する場合、クラスタ切り替え後に、ＯＦＣは、各ＯＦＳに対してフローエントリごとにｆｌｏｗ ｍｏｄメッセージを送信する必要がある。ここで、ｃｏｏｋｉｅは、ＯＦＳがフローテーブル内の各フローエントリを識別するための識別情報である。そのため、ＯＦＣのローリングアップデートによりｃｏｏｋｉｅを更新することは、フローエントリのＩＤの変更となるため、ｆｌｏｗ ｍｏｄメッセージを用いる場合には、既存のフローエントリを削除し、かつ、変更後のｃｏｏｋｉｅ値をＩＤとした新規のフローエントリを追加することとなる。そのため、ＯＦＳに多数のフローエントリが登録されている場合、フローエントリ数に比例した多数のｆｌｏｗ ｍｏｄがＯＦＣから送出される。それ故、ＯＦＣとＯＦＳ間の通信接続であるセキュアチャネル（ｓｅｃｕｒｅ ｃｈａｎｎｅｌ、管理ネットワーク）の輻輳状態が発生する可能性がある。

ここで、ｃｏｏｋｉｅは６４ｂｉｔの情報であり、自由な値を設定することができる。そのため、単なるＩＤとしてではなく、ＯＦＣで使用する内部情報などを加えて使用する場合がある。内部情報としては、例えば、フローエントリ種別（Ｂｌｏａｄｃａｓｔ，ＩＰ ｍｕｌｔｉｃａｓｔ，ｕｎｉｃａｓｔ等）等が考えられる。また、現行のＯｐｅｎＦｌｏｗの仕様では、フローエントリの統計情報の取得時に、ｃｏｏｋｉｅ値の他にｃｏｏｋｉｅ ｍａｓｋの指定が可能であり、取得するフローエントリ情報のフィルタリングを行うこともできる。（すなわち、ある特定のフローエントリ種別の情報のみを取得することができる。）

そのため、ＯＦＣのバージョンアップに伴い、内部情報の扱いが変更になり、その結果、フローエントリのうち、内容（照合ルールやアクション等）は一緒であるが、ｃｏｏｋｉｅの値のみ変更になるというケースが考えられる。

さらに、ＯＦＣ側でのフローエントリの書き換えの内容によっては（ｃｏｏｋｉｅ書き換えなど）、上述の通り、フローエントリが一時的に削除されるため、ＯＦＳに接続されている端末間の通信が途切れてしまう可能性もある。

そこで、本発明の実施の形態は、ＯＦＳ内部で保持するフローエントリ等の情報の書き換え処理を、ＯＦＣ主導ではなく、ＯＦＣのクラスタ切り替えの間にＯＦＳ主導で行うものである。本発明の実施の形態の概要の一部としては以下ものが挙げられる。例えば、ＯＦＳは、外部から与えられたトリガによって自らの内部のフローテーブルを編集する機能を有する。そして、ＯＦＳのフローテーブルの制御方式としては、ＯＦＣ側のソフトウェアの更新時にＯＦＳに対して編集処理起動のトリガを与えることによって、ＯＦＳのフローテーブルを更新後のＯＦＣの制御仕様に同期させる。また、そのためにあらかじめ、ＯＦＳに対してフローエントリ更新用のソフトウェアを事前に送信し、ＯＦＳのクラスタフェイルオーバー中の新ＡＣＴに切り替わる間にフローエントリの更新を行うようにしてもよい。

また、ローリングアップデートによるＯＦＣのアップデート後に、ＯＦＣからのフロー設定要求（ｆｌｏｗ ｍｏｄメッセージ）を用いずに、ＯＦＳに設定済みの既存のフローエントリを更新することも可能である。これにより、クラスタ切り替え後のネットワーク負荷を最小限にすることができる。

さらに、ｃｏｏｋｉｅ値の書き換えの場合などには、フローエントリを一旦削除せずに、ＯＦＳ内部で差分のみを書き換えるため、ＯＦＳに接続されている端末間の通信に切断が発生しないという効果も奏する。尚、既存のＯｐｅｎＦｌｏｗプロトコルを使用してｃｏｏｋｉｅを書き換える場合には、上述の通りフローエントリを一回削除しなければならない。

また、上述した実施の形態１から次のように改良しても良い。例えば、上述した図１の更新情報１１２として、中継定義情報（フローエントリ）に対応する新たな識別情報（更新後のｃｏｏｋｉｅ値）を含み、前記更新部は、更新処理により中継定義情報における識別情報を、更新情報に含まれる新たな識別情報へ更新することが望ましい。上述の通り、フローエントリのＩＤ（ｃｏｏｋｉｅ）のみを更新する場合、従来はフローエントリ自体の削除及び新規追加が必要であり、その場合、当該フローエントリに基づく既存の端末間通信が中断されることになっていた。しかし、フローエントリのＩＤのみを更新することにより、端末間の既存の通信を中断することがなくなる。

さらに、前記取得部は、前記複数の中継定義情報の更新内容に応じた更新処理が実装された更新プログラムを前記更新情報として取得し、前記更新部は、前記更新プログラムを前記所定のタイミングに実行することにより、前記更新処理を行うとよい。これにより、既存のプロトコルに依存しない柔軟な（きめ細かな）更新処理を実現できる。また、フローエントリ数にかかわらず、一種類の更新プログラムを送信するだけで実現できるため、更新のための通信量を抑制することができる。

また、前記通信中継装置は、稼働系（ＡＣＴ）と待機系（ＳＢＹ）により冗長構成された複数の通信制御装置（例えば、ＯＦＣ）により制御され、前記更新部は、前記稼働系と前記待機系の切り替え（例えば、ローリングアップデート又は単に、クラスタ切り替え）を前記所定のタイミングとして、前記更新処理を開始することが望ましい。これにより、より早くＯＦＣとの同期を行うことができる。また、系切替中に更新処理が完了しなくても、既存の同期処理（例えば、フローエントリ間の状態整合処理）で残りの更新処理を行うことで、全て既存の同期処理で対応する場合に比べて、通信負荷を低減できる。

さらに、前記更新部は、前記通信制御装置と当該通信中継装置との間の制御のための接続（例えば、セキュアチャネル）が切断されたことを検出した場合を、前記所定のタイミングとして前記更新処理を開始すると良い。このように、ＯＦＣの系切替を自ら検出することで、外部からの指示によらずに更新を開始できる。

さらに、前記取得部は、外部から前記更新処理の開始要求を前記更新指示として取得し、前記更新部は、前記開始要求の取得後に前記接続が切断されたことを検出した場合に、前記更新処理を開始すると良い。これにより、系切替とは無関係な切断時に不必要に更新処理を行うことを防止し、更新開始タイミングを適切に制御できる。

また、前記取得部は、前記所定のタイミングの基準となる時刻情報を前記更新情報に含めて取得し、前記更新部は、前記接続が切断されたことを検出した場合に、前記取得した時刻情報に基づいて前記所定のタイミングであるか否かを判定し、当該所定のタイミングであると判定した場合に、前記更新処理を開始すると良い。これにより、不必要な更新処理を行うことを防止し、更新開始タイミングを適切に制御できる。

さらに、前記通信中継装置は、前記稼働系と前記待機系の切り替えの前に前記更新情報を取得していることが望ましい。これにより、更新の開始時の負荷を低減し、更新処理の迅速な開始を実現できる。

また、本実施の形態２にかかる通信中継装置は、次のように表現することもできる。すなわち、稼働系と待機系により冗長構成された複数の通信制御装置により制御され、端末間の通信の中継に関する定義である中継定義情報を保持し、前記稼働系と前記待機系の切り替えの間に、前記中継定義情報を更新するための更新情報に基づいて、当該中継定義情報の更新処理を開始する。このように、少なくとも更新処理の開始を系切替中とすることで、より早くＯＦＣとの同期を行うことができる。また、系切替中に更新処理が完了しなくても、既存の同期処理（例えば、フローエントリ間の状態整合処理）で残りの更新処理を行うことで、全て既存の同期処理で対応する場合に比べて、通信負荷を低減できる。

さらに、本発明の実施の形態２を通信中継システムとする場合は、次のように表現することもできる。すなわち、通信中継システムは、装置間の通信の中継に関する定義である複数の中継定義情報を保持し、当該中継定義情報に基づいて前記装置間の通信の中継を行う通信中継装置と、前記通信中継装置を制御する通信制御装置と、前記通信中継装置及び前記通信制御装置と接続された管理サーバと、を備え、前記通信制御装置又は前記管理サーバは、前記中継定義情報を更新するための更新情報を前記通信中継装置へ送信し、前記通信中継装置は、前記更新情報を受信し、複数の前記中継定義情報を更新するための指示に応じて、前記更新情報に基づく更新処理を所定のタイミングにより実行する。

続いて、本発明の実施の形態２について以降に具体的に説明する。
図３は、本発明の実施の形態２にかかるＯｐｅｎＦｌｏｗネットワークシステム１の構成を示すブロック図である。ＯｐｅｎＦｌｏｗネットワークシステム１は、端末１１〜１６と、ＯＦＳ３１〜３３と、ＯＦＣ２１及び２２と、管理サーバ４０と、開発端末５０とを備える。ＯＦＣ２１及び２２と、ＯＦＳ３１〜３３と、管理サーバ４０とは、管理ネットワーク上で接続されている。また、開発端末５０は管理サーバ４０と接続されている。尚、開発端末５０と管理サーバ４０との接続を管理ネットワークに加えても構わない。また、ＯＦＳ３１は、端末１１〜１３及びＯＦＳ３２とＯｐｅｎＦｌｏｗネットワーク上で接続されている。ＯＦＳ３２は、ＯＦＳ３１及び３３とＯｐｅｎＦｌｏｗネットワーク上で接続されている。ＯＦＳ３３は、ＯＦＳ３２及び端末１４〜１６とＯｐｅｎＦｌｏｗネットワーク上で接続されている。

ＯＦＣ２１とＯＦＣ２２とは、稼働系（ＡＣＴ）と待機系（ＳＢＹ）により冗長構成（クラスタ構成）された２台の通信制御装置である。図３では、稼働系（ＡＣＴ）をＯＦＣ２２、待機系（ＳＢＹ）をＯＦＣ２１としているが、本発明の実施の形態がこれに限定されないことは勿論である。また、ＯＦＣは３台以上であってもよい。ＯＦＣ２１及び２２のそれぞれは、例えば、ＵＮＩＸ（登録商標）サーバにより実現可能である。また、ＯＦＣ２１及び２２は、共通の仮想ＩＰアドレスが割り当てられている。そのため、ＯＦＳ３１〜３３の側では、ＯＦＣ２１又は２２のいずれが稼働系（ＡＣＴ）であり、待機系（ＳＢＹ）であるかを意識する必要が無い。

ここで、ＡＣＴ側のＯＦＣ２２とＯＦＳ３１〜３３との間は、セキュアチャネルにより接続されている。また、ＳＢＹ側のＯＦＣ２１は、ＯＦＳ３１〜３３のトポロジーやフローテーブル情報などの情報や、各ＯＦＳのポート状態変更通知などのイベントをＡＣＴ側のＯＦＣ２２から取得することができる。そして、ＡＣＴ側のＯＦＣ２２とＳＢＹ側のＯＦＣ２１との制御ソフトウェアのバージョンが等しい場合には、互いのデータが完全に同期される。

管理サーバ４０は、ＯＦＣ２１及び２２とＯＦＳ３１〜３３を管理する。管理サーバ４０は、例えば、ＵＮＩＸサーバにより実現可能である。管理サーバ４０は、各々のＯＦＣとＳＳＨ（Ｓｅｃｕｒｅ ＳＨｅｌｌ）による接続が確立されており、ＵＮＩＸのシェル上で動作するコマンドにより、管理サーバ４０からＯＦＣ２１及び２２のクラスタ切り替えを行うことができる。また、管理サーバ４０は、ＯＭＡ−ＤＭなどの遠隔デバイス管理プロトコルが実装されているＯＭＡ−ＤＭサーバであるものとする。そして、管理サーバ４０は、あらかじめ決められた時刻に、対象となるＡＣＴ側のＯＦＣ２２に対してクラスタ切り替え要求を送信する。また、管理サーバ４０は、クラスタ切り替え要求の送信と同時に、ＯＦＳ３１〜３３に対してソフトウェア更新要求を送信する。

ＯＦＳ３１、３２及び３３は、内部に保存されたフローテーブルに基づいて、端末１１〜１６の間の通信を中継する。ＯＦＳ３１〜３３は、例えば、組み込みＬｉｎｕｘ（登録商標）が実装された組み込み機器である。ＯＦＳ３１〜３３のそれぞれは、管理ネットワーク経由で、ＯＦＣ２１及び２２並びに管理サーバ４０と通信を行うことができる。ＯＦＳ３１〜３３は、例えば、ＯＭＡ−ＤＭなどの組み込み機器向けのデバイス管理プロトコルが実装されているＯＭＡ−ＤＭクライアントが組み込まれているものとする。

ここで、本実施の形態では、ＯＦＳ３１〜３３からＯＦＣ２１及び２２並びに管理サーバ４０に対してＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）コネクションを確立させるものとする。ＴＣＰコネクションの接続のタイミングは、管理ネットワークの接続時（ＯＦＳの起動又は再起動に伴うネットワーク接続や、管理ネットワーク用のイーサーネット（登録商標）ケーブルを動作中のＯＦＳに接続する場合など）、又は、ＯＦＳ内部の設定情報の更新時などが挙げられるが、これらに限定されない。ここで、ＯＦＳとＯＦＣとの間は、セキュアチャネル接続であり、ＯＦＳと管理サーバとの間は、デバイス管理プロトコルのための接続である。

また、ＯＦＳ３１〜３３は、接続を行うＯＦＣのＩＰアドレスを内部設定情報として保持するものとする。さらに、ＯＦＳ３１〜３３は、登録されたＩＰアドレスを持つＯＦＳ接続の有無を定期的に監視する。そして、ＯＦＳ３１〜３３は、対象となるＯＦＣが管理ネットワークに接続されたことを認識すると、当該ＯＦＣに対してセキュアチャネルの接続処理を行う。

また、ＯＦＳ３１〜３３は、ＯＦＣ２１及び２２の系切り替えの間を、フローテーブルの更新処理の開始タイミングとする。すなわち、ＯＦＳ３１〜３３は、ＯＦＣの系切り替えのタイミングで、管理サーバ４０から配信された更新ソフトウェアの実行を行う。但し、フローテーブル内の全エントリの消去などの単純な処理に関しては、管理サーバ４０からのトリガを契機として行うこともできる。この場合は、管理サーバ４０から配信された更新ソフトウェアを用いる必要がない。

端末１１〜１６は、上述した図１の端末１１と端末１２と同等の通信装置である。そのため、端末１１〜１６は、ＯＦＳ３１〜３３を介して互いに通信パケット等の送受信を行う。

開発端末５０は、開発ユーザ等が使用することにより、ＯＦＳ３１〜３３の更新ソフトウェアを生成する装置である。生成された更新ソフトウェアは、管理サーバ４０を介してＯＦＳ３１〜３３へ配信される。ここで、本実施の形態にかかる更新ソフトウェアは、組込み機器である各ＯＦＳ内で高速に書き換え処理を行い、省メモリ化を実現するものである。例えば、当該更新ソフトウェアは、機械語のバイナリコードで実現されたものである。または、当該更新ソフトウェアは、以下のような形態でもよい。例えば、Ｊａｖａ（登録商標）に代表される中間言語、ＬＬＶＭ（Ｌｏｗ Ｌｅｖｅｌ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）のような共通実行環境で実行されるプログラムであるとよい。または、Ｌｕａなどのスクリプト言語やＰｙｔｈｏｎなどのインタプリンタ言語であってもよい。

また、本実施の形態にかかる更新ソフトウェアは、更新対象のフローエントリ及び更新内容が指定されている。更新対象のフローエントリには２以上の指定が可能である。更新内容としては、更新後のｃｏｏｋｉｅ、上述したルール、アクション、又は、フロー統計情報の各値を、フローエントリごとに指定することができる。そして、当該更新ソフトウェアは、更新対象のフローエントリに対して指定された更新内容により更新する処理を含む。

また、当該更新ソフトウェアは、実行を開始する日付及び時刻を示す実行開始時刻情報を含むものであってもよい。または、デバイス管理プロトコル内に実行開始時刻情報を含めても良い。その場合、ＯＦＳ３１〜３３が管理サーバ４０から更新ソフトウェアをダウンロードする際に、併せて、実行開始時刻情報を取得してもよい。

または、開発端末５０は、更新ソフトウェアではなく、各フローエントリの更新内容のデータのみを生成してもよい。更新内容としては、置換対象のフローエントリや、置換対象のｃｏｏｋｉｅ、上述したルール、アクション、又は、フロー統計情報の各値のみであってもよい。その場合、管理サーバ４０は、各ＯＦＳに対して更新内容を配信することとなる。以上のことから、更新ソフトウェア又は更新内容は、上述した実施の形態１の更新情報の一例といえる。

図４は、本発明の実施の形態２にかかる管理サーバ４０及びＯＦＳ３１の概要構成を示すブロック図である。管理サーバ４０は、構成管理機能４０１と、ＯＦＳ制御機能４０２と、ＯＦＳ及び更新ソフトウェア管理機能４０３と、ＯＭＡ−ＤＭサーバ４０４とを備える。構成管理機能４０１は、管理ネットワークに接続されているＯＦＳ３１〜３３の構成情報を管理する。構成管理機能４０１は、デバイス管理プロトコル経由での各ＯＦＳとのネゴシエーションを契機に、ＯＦＳ情報を取得して内部に登録する。

ＯＦＳ及び更新ソフトウェア管理機能４０３は、ＯＦＳ３１〜３３に対して、更新ソフトウェアの配信や更新開始のトリガＭ１を送信する。尚、ＯＦＳ及び更新ソフトウェア管理機能４０３は、更新ソフトウェアの代わりに後述する更新内容のデータ自体を配信してもよい。また、ＯＦＳ及び更新ソフトウェア管理機能４０３は、ＯＦＳ３１〜３３のそれぞれが更新タイミングを検出する場合には、必ずしも更新開始のトリガを送信する必要はない。ＯＦＳ制御機能４０２は、ＯＦＳ及び更新ソフトウェア管理機能４０３からの要求を受けて、ＯＦＣ２１及び２２に対してクラスタ切り替えＭ２を行う。

また、ＯＦＳ及び更新ソフトウェア管理機能４０３は、ＯＦＳ３１〜３３に対して、フローテーブルなどを書き換えるための更新ソフトウェアを事前に配信することが望ましい。ここで、ＯＦＳ及び更新ソフトウェア管理機能４０３は、例えば、深夜などｔｒａｆｆｉｃの少ない時間帯に更新ソフトウェアを配信すると良い。

尚、ＯＦＳ及び更新ソフトウェア管理機能４０３は、更新開始トリガと共に、更新ソフトウェアを配信することもできる。ここで、ＯＦＣの系切り替えの時間は、数十秒を想定している。そのため、更新開始トリガと共に、更新ソフトウェアを配信する場合、系切り替え中に更新処理を開始できない可能性がある。また、系切り替え中に更新処理を開始できたとしても、終了ができない場合には、系切り替え後に大量のパケットインやフローエントリ設定処理などが送信される可能性がある。そのため、系切り替え前後は、管理ネットワークの負荷をできるだけ下げる必要性が高い。よって、更新ソフトウェアを事前に配信する方法が望ましい。

尚、ＯＭＡ−ＤＭサーバ４０４は、上述した通り、組み込み機器向けのデバイス管理プロトコルであるＯＭＡ−ＤＭが実装されたサーバ機能を有する。

ＯＦＳ３１は、テーブル編集機能３１１と、ＯＦＳ更新管理機能３１２と、ＯＭＡ−ＤＭクライアント３１３とを備える。尚、図４では、ＯＦＳ３２及び３３は、ＯＦＳ３１と同等であるため図示及び説明を省略する。テーブル編集機能３１１は、内部のテーブル情報（不図示）（フローテーブル、グループテーブルなど）を編集（更新）する手段である。ここで、テーブル編集機能３１１は、管理サーバ４０から取得した更新ソフトウェアを実行し、当該更新ソフトウェアの処理によりテーブルの所定のフローエントリを書き換える。

また、テーブル編集機能３１１は、管理サーバ４０から取得した更新内容により、指定されたフローエントリの部分的な置換を行う。例えば、更新内容にｃｏｏｋｉｅのみが指定されている場合には、テーブル編集機能３１１は、更新ソフトウェアの実行により、フローエントリのうちｃｏｏｋｉｅのみを更新することができる。当該更新プログラムは、機械語等で作成されているため、ＯＦＳのハードウエアに直接アクセスすることが可能であるため、フローエントリを消さずにｃｏｏｋｉｅ書き換えることが可能である。従って、既存のフローエントリの削除及び新規のフローエントリの追加をする必要がなく、ルールやアクション等に変更がなければ、処理中の端末間の通信が中断されることはない。

さらに、テーブル編集機能３１１は、トリガにより各テーブルの全エントリを消去することや、トリガにより指定されたエントリ、又は、条件に合うエントリを消去するようにしてもよい。

ＯＦＳ更新管理機能３１２は、管理サーバ４０からの配信される更新ソフトウェアや更新内容である更新情報を取得する。また、ＯＦＳ更新管理機能３１２は、管理サーバ４０から更新開始のトリガを受信する。ここで、トリガとしては、プロトコルによる明示的な指示、セキュアチャネルの切断による暗黙的な指示、更新開始時刻の指示、これらの２つ以上の組み合わせ等が挙げられる。

まず、トリガの例としてプロトコルによる明示的な指示は、既存のｆｌｏｗ ｍｏｄメッセージとは異なり、具体的な更新対象のフローエントリの指定は含む必要がなく、最低限、開始の指示が含まれていればよい。そして、外部からフローテーブルの更新開始用のメッセージを、新たにプロトコルに規定することで実現できる。また、例えば、管理サーバ４０がＯＦＣ２１及び２２に対してローリングアップデートの指示（クラスタ切り替えＭ２）を行うと共に、ＯＦＳ３１〜３３に対して更新開始の指示を行っても良い。または、当該トリガと共に、更新ソフトウェア又は更新内容の配信を含めてもよい。

次に、トリガの例としてセキュアチャネルの切断による暗黙的な指示は、通常、ＯＦＣとＯＦＳの間で確立されているＯｐｅｎＦｌｏｗメッセージ送受信可能なセキュアチャネルが切断されたことを契機とするものである。つまり、ＯＦＣのローリングアップデートが行われる場合、系切替前に、当初のＡＣＴ側（旧ＡＣＴ側）のＯＦＣは、各ＯＦＳとのセキュアチャネルを切断する。そして、各ＯＦＳは、セキュアチャネルが切断されたことを検出する。尚、セキュアチャネルの切断の検出については後述する。但し、ＯＦＳからＯＦＣへの片方向通信のみを対象としたセキュアチャネル、つまり、ＳＢＹ側のＯＦＳ専用のｒｅａｄ ｏｎｌｙチャンネルの切断は対象としない。尚、セキュアチャネルは、上述の通りＯＦＣとＯＦＳとの間の管理ネットワーク内の接続を意味する。そのため、セキュアチャネルが切断されても、図３のＯｐｅｎＦｌｏｗネットワーク側の通信（ＯＦＳ側のフローテーブルに登録されているフローエントリにヒットするもの）には影響しない。

続いて、トリガの例として更新開始時刻の指示は、ＯＦＳ３１〜３３がトリガを受信したタイミングで更新を開始するのではなく、受信した更新開始時刻を内部に設定し、当該時刻になった場合に更新を開始するものである。尚、更新開始時刻は、上述した実行開始時刻情報としてもよい。

最後に、トリガの例として上記の組み合わせとは、例えば、更新ソフトウェア等の取得イベントと旧ＡＣＴ側のＯＦＣとのセキュアチャネルの切断検出イベントの２つのイベントの論理積が真になった場合などが挙げられる。さらに、当該２つのイベントの論理積が真になった時刻が上記更新開始時刻と異なる場合、ＯＦＳ３１〜３３は更新処理を開始しないようにしてもよい。例えば、ＯＦＣの系切替が不調な場合には、セキュアチャネルが切断されていない可能性もあり、そのような場合にはＯＦＳの更新処理も開始しないことが望ましいためである。

また、ＯＦＳ３１〜３３は、フローテーブルの更新処理後、つまり、更新ソフトウェアの実行終了後に、切替後の新ＡＣＴのＯＦＣとのセキュアチャネルの接続を確立する。その後、ＯＦＳ３１〜３３は、当該更新ソフトウェアを削除してもよい。

ここで、新ＡＣＴに切り替わるまでにフローテーブルの更新処理が完了しなかった場合は、新ＡＣＴに切り替え後に更新ソフトウェアの実行を中断し、別途、既存の状態整合方式で未完了の更新を行っても構わない。すなわち、新ＡＣＴのＯＦＣは、ＯＦＳから、更新が未完了のフローエントリの情報を逐次読み出し、差分をｆｌｏｗ ｍｏｄメッセージにより設定し直すようにしてもよい。このように、既存の状態整合方式との組み合わせであっても、ＯＦＣからのフローエントリ再設定処理が大幅に減少するため、本発明の実施の形態は有効だと言える。

尚、ＯＭＡ−ＤＭクライアント３１３は、上述した通り、組み込み機器向けのデバイス管理プロトコルであるＯＭＡ−ＤＭが実装されたクライアント機能を有する。

図５は、本発明の実施の形態２にかかるＯＦＳ３１のハードウェア構成を示すブロック図である。ＯＦＳ３１は、ＯｐｅｎＦｌｏｗ制御ＩＣ６１と、ＮＯＲ ＦＬＡＳＨ ＭＥＭＯＲＹ６３と、ＣＰＵ（Central Processing Unit）６４と、イーサネットドライバＩＣ６５と、ＨＤＤ（Hard Disk Drive）６６と、ＳＤＲＡＭ（Synchronous DRAM）６７とを備える。

ＯｐｅｎＦｌｏｗ制御ＩＣ６１は、専用のハードウエアとしてＯＦＳに組み込まれている。ＯｐｅｎＦｌｏｗ制御ＩＣ６１は、フローエントリ設定済みのＯｐｅｎＦｌｏｗネットワーク間の通信を、ＣＰＵを介さず、高速に行うことができる。ここでは、ＯｐｅｎＦｌｏｗ制御ＩＣ６１は、ＡＳＩＣ（Application Specific Integrated Circuit）とＤＳＰ（Digital Signal Processor）とを備える構成とする。

ＯｐｅｎＦｌｏｗ制御ＩＣ６１は、イーサネット制御部６１１と、ＳＲＡＭ（Static Random Access Memory）６１２とを備える。イーサネット制御部６１１は、ポート６０１〜６０３を介してＯＦＳ３２、端末１１及び１２との間のイーサネット通信を制御する。ＳＲＡＭ６１２は、フローテーブル６１３と、グループテーブル６１４とを記憶する。フローテーブル６１３は、複数のフローエントリ６１５を含む。各フローエントリ６１５は、ｃｏｏｋｉｅ６１６その他、ルール、アクション及びフロー統計情報等（不図示）を含む。グループテーブル６１４は、複数のグループエントリ（不図示）を含む。

ＯｐｅｎＦｌｏｗ制御ＩＣ６１と、ＮＯＲ ＦＬＡＳＨ ＭＥＭＯＲＹ６３と、ＣＰＵ６４と、イーサネットドライバＩＣ６５とは、アドレス及びデータバス６２を介して接続されている。ＮＯＲ ＦＬＡＳＨ ＭＥＭＯＲＹ６３は、書き換え可能なＲＯＭ（Read Only Memory）として位置付けられる。ＮＯＲ ＦＬＡＳＨ ＭＥＭＯＲＹ６３は、ブートローダのイメージなどを記憶している。イーサネットドライバＩＣ６５は、管理ネットワークを介してＯＦＣ２１及び２２並びに管理サーバ４０との通信を行う。

ＣＰＵ６４は、Ｉ／Ｏレジスタ設定または、ＤＭＡ転送によりＯｐｅｎＦｌｏｗ制御ＩＣ６１の制御を行う。また、ＣＰＵ６４は、ＯＦＣ２１及び２２とのＯｐｅｎＦｌｌｏｗプロトコルを使用した通信などの処理を行う。さらに、ＣＰＵ６４は、組み込み向けのＳｏＣ（System on a Chip）として実現することができる。また、ＣＰＵ６４は、ＰＬＬが内蔵されるクロックコントローラ（不図示）、ＳＡＴＡ Ｉ／Ｆコントローラ（不図示）やＳＤＲＡＭ Ｉ／Ｆコントローラ（不図示）などの周辺デバイスが内蔵される。そのため、ＣＰＵ６４は、ＳＡＴＡ６８を介してＨＤＤ６６と接続され、ＳＤＲＡＭ／ＩＦ６９を介してＳＤＲＡＭ６７と接続される。ＨＤＤ６６には、組み込みＬｉｎｕｘなどのＯＳのカーネルイメージと、更新ソフトウェアや更新内容が格納される。

また、ＣＰＵ６４は、ＯｐｅｎＦｌｏｗプロトコルの組み立てや解読といった、端末間の通信の中継処理の一部を行う。さらに、ＣＰＵ６４は、管理サーバ４０との通信のための処理も行う。ＣＰＵ６４は、管理サーバ４０から取得した更新ソフトウェア等をＨＤＤ６６に格納する。そして、ＣＰＵ６４は、更新処理を開始するために所定のタイミングであるか否かの判定を行い、所定のタイミングである場合にＨＤＤ６６から更新ソフトウェアを読み込み、実行する。これにより、更新処理が開始される。

図６は、本発明の実施の形態２にかかるＯＦＳ内のＣＰＵ上で動作するソフトウェア構成の概念図である。本発明の実施の形態２にかかるＯＦＳのＯＳとしては、組み込みＬｉｎｕｘ７２が実装されている。ＯｐｅｎＦｌｏｗＳｗｉｔｃｈ制御／管理アプリ７３は、ユーザ空間で動作するＵＮＩＸアプリケーションである。ＯｐｅｎＦｌｏｗＳｗｉｔｃｈ制御／管理アプリ７３は、ＯｐｅｎＦｌｏｗ制御ＩＣ６１の制御処理、ＯｐｅｎＦｌｏｗプロトコルの組み立て及び解読処理、並びに、ＯＦＣとの通信処理などを行う。ＯｐｅｎＦｌｏｗ制御ＩＣ用ドライバ７１は、カーネル空間で動作するカーネルオブジェクトで、ＯｐｅｎＦｌｏｗ制御ＩＣ６１に対するレジスタ制御などを行う。

ＯＦＳ更新アプリ７５は、本発明の実施の形態２の中心的な処理が実装された、ユーザ空間で動作するＵＮＩＸアプリケーションである。ＯＦＳ更新アプリ７５は、管理サーバ４０との通信処理やダウンロードした更新ソフトウェアの管理及び制御などを行う。デバイス管理ライブラリ７６は、ＯＭＡ‐ＤＭなどのデバイス管理プロトコルなどが実装されている。ログフィルタリング処理アプリ７４は、ログフィルタリングルール７７に基づいてログ情報を解析（フィルタリング）し、解析結果をＯＦＳ更新アプリ７５へ通知する。すなわち、ログフィルタリング処理アプリ７４は、ログフィルタリングルール７７に基づいてｓｙｓｌｏｇなどからセキュアチャネルの切断通知を検出し、ＯＦＣとのセキュアチャネルが切断された旨を通知する。ログフィルタリング処理アプリ７４により、ＯｐｅｎＦｌｏｗＳｗｉｔｃｈ制御／管理アプリ７３側に、ＯＦＳ更新アプリ７５に特化したロジックを実装する必要がなくなる。

フローテーブル更新アプリ７８は、図４のテーブル編集機能３１１に相当する機能が実装されたアプリケーションである。ＤＭＴ制御ライブラリ７９１は、ＤＭＴを制御するための共有ライブラリである。ユーザ作成ライブラリ７９２は、各種の共通的な処理を関数化した共有ライブラリである。

ここで、ＯＦＳ３１〜３３は、管理サーバ４０から配信されるフローテーブル更新アプリ７８及びＤＭＴ制御ライブラリ７９を受信し、ＯＦＳ更新アプリ７５により、予め定められたディレクトリへ格納する。さらに、ＯＦＳ３１〜３３は、管理サーバ４０から配信されるカーネルオブジェクト（不図示）も受信できる。また、ＯＦＳ３１〜３３は、管理サーバ４０から新たな更新ソフトウェアを受信した場合、既存のＯＦＳ更新アプリ７５やログフィルタリング処理アプリ７４を新たな更新ソフトウェアにより置換する。

続いて、更新ソフトウェアの配信処理と、その後のＯＦＳ内部のフローテーブル更新処理の実施例について、図７及び図８のシーケンス図を用いて説明する。ここでは、ＯＦＣ及びＯＦＳの全てで、フローエントリのｃｏｏｋｉｅの値のみを更新するものとする。そのため、ここで対象とする更新ソフトウェアは、ＯＦＳのＯｐｅｎＦｌｏｗ制御ＩＣ６１の内部に存在するフローテーブル６１３のｃｏｏｋｉｅフィールド（ｃｏｏｋｉｅ６１６）を直接変更するソフトウェアであるものとする。また、当該更新ソフトウェアは、高速書き換え処理及び組込み機器であるＯＦＳの省メモリ化のため、機械語のバイナリデータであるものとする。但し、上述の通り、更新内容はこれに限定されない。

図７は、本発明の実施の形態２にかかる更新ソフトウェアの配信処理の流れを説明するためのシーケンス図である。ここでは、あらかじめ管理サーバ４０とＯＦＳ３１の間のＴＣＰコネクションが確立されているものとする。また、ＴＣＰコネクションが確立するタイミングは、ＯＦＳの管理ネットワークへの接続時である。そして、当該接続のタイミングでＯＦＳ固有の情報（ＩＰアドレスなど）が、管理サーバ４０に登録されるものとする。

まず、管理サーバ４０は、配信対象のＯＦＳ（例えば、ＯＦＳ３１）に対して更新ソフトウェア配信通知を送信する（Ｓ１０１）。ここで、更新ソフトウェア配信通知は、例えば、ＯＭＡで規定されたｓｙｎｃＭＬ形式のＸＭＬファイルであるが、これに限定されない。そして、更新ソフトウェア配信通知には、更新ソフトウェアが保存されているＵＲＬや更新ソフトウェアのＯＦＳ側での実行開始時刻情報が含まれる。

そして、例えば、ＯＦＳ３１は、管理サーバ４０から更新ソフトウェア配信通知を受信する。次に、ＯＦＳ３１は、更新ソフトウェアのダウンロード要求を管理サーバ４０へ送信する（Ｓ１０２）。具体的には、ＯＦＳ３１は、更新ソフトウェア配信通知に含まれる更新ソフトウェアが保存されているＵＲＬに対して更新ソフトウェアの取得要求を行う。

その後、管理サーバ４０は、ＯＦＳ３１からのダウンロード要求に応じて、更新ソフトウェアをＯＦＳ３１へ送信する（Ｓ１０３）。すなわち、ＯＦＳ３１は、管理サーバ４０から更新ソフトウェアを取得し、ＨＤＤ６６に保存する。また併せて、ＯＦＳ３１は、実行開始時刻情報を取得し、ＨＤＤ６６に保存する。

図８は、本発明の実施の形態２にかかるＯＦＣの系切替時におけるＯＦＳのフローテーブル更新処理の流れを説明するためのシーケンス図である。尚、図８は図７の更新ソフトウェアの配信後であり、ＯＦＳ３１〜３３には更新ソフトウェアが格納済みであるものとする。

まず、管理サーバ４０は、ＡＣＴ側（稼働系）であるＯＦＣ２２に対して、クラスタ切り替え要求コマンドを送信する（Ｓ２０１）。例えば、管理サーバ４０は、ＯＦＣ２２とＳＳＨによるリモート接続を行い、ＵＮＸシェル上で、クラスタ切り替え要求のコマンドを発行する。これにより、クラスタ切り替えの要求を実現できる。

次に、ＡＣＴ側のＯＦＣ２２は、各ＯＦＳとの間のセキュアチャネルを切断する（Ｓ２０２）。具体的には、ＯＦＣ２２は、ＯＦＳ３１〜３３のそれぞれとの間のＴＣＰコネクションを切断する。

続いて、ＡＣＴ側のＯＦＣ２２は、ＳＢＹ側のＯＦＣ２１に対してＡＣＴ遷移要求（メッセージ）を発行する（Ｓ２０３）。これに伴い、ＳＢＹ側のＯＦＣ２１はＡＣＴへの遷移を開始する。また、ＡＣＴ側のＯＦＣ２２は、ＯＳの再起動処理を行う（Ｓ２０５０）。そして、再起動後に、ＯＦＣ２２はＳＢＹ（待機系）として動作する。

ここで、ステップＳ２０２のセキュアチャネルの切断後、各ＯＦＳは、ＯＦＳ更新処理を開始する（Ｓ２０４）。具体的には、まず、各ＯＦＳは、ログフィルタリング処理アプリ７４により自身とＯＦＣ２２との間のセキュアチャネルが切断されたことを検出する。そして、各ＯＦＳのＯＦＳ更新アプリ７５は、既に取得済みの実行開始時刻情報内であることを確認し、更新ソフトウェアの実行を開始する。

そして、各ＯＦＳは、フローテーブルの更新処理を行う（Ｓ２０５１、Ｓ２０５２等）。ここで、更新ソフトウェアに更新内容として各フローエントリのｃｏｏｋｉｅ値のみが設定されている場合、各ＯＦＳは、該当するフローエントリのｃｏｏｋｉｅフィールドのみを直接書き換える。または、各ＯＦＳは、ｃｏｏｋｉｅのみ更新されたフローエントリ情報を新たに追加し、この新フローエントリ追加後に旧フローエントリを削除するようにしてもよい。この場合であっても、フローエントリの更新処理に伴うＯｐｅｎＦｌｏｗネットワークの切断を回避することができる。

ＡＣＴとＳＢＹのクラスタ切り替え後、新ＡＣＴ側であるＯＦＣ２１と新ＳＢＹ側であるＯＦＣ２２との間で、ＯＦＳのトポロジー情報やＯＦＣ内で保有するフローエントリ情報の同期が行われる（Ｓ２０６）。これにより、新ＡＣＴ側であるＯＦＣ２１は、フローエントリのｃｏｏｋｉｅ情報が新しい値に書き換えられる。

その後、各ＯＦＳは、新ＡＣＴ側のＯＦＣ２１との間でセキュアチャネルの接続を確立する（Ｓ２０７）。具体的には、各ＯＦＳは、新ＡＣＴ側のＯＦＣ２１に対してＴＣＰコネクションの接続を行う。

そして、新ＡＣＴのＯＦＣ２１は、各ＯＦＳとの間でフローエントリの状態整合処理を行う（Ｓ２０８）。当該フローエントリの状態整合処理には、ｆｌｏｗ ｍｏｄメッセージ等を用いることができる。そのため、ＯＦＳ側のフローテーブル更新処理が新ＡＣＴの起動までに終了しない場合でも、それ以後の更新処理に状態整合処理を用いることで、ＯＦＣとＯＦＳ間のフローテーブルの状態ずれを防ぐことができる。つまり、ＯＦＳが単独で実行する更新ソフトウェアによる更新処理と、ＯＦＣとの状態整合処理とを組み合わせることでも、同様の効果を得ることができる。そして、この場合でも、更新ソフトウェアによる更新処理においては、ＯＦＣとの通信量は抑制されるため、全ての更新処理を状態整合処理で行う場合に比べて、管理ネットワークの通信量が減少し、端末間の通信の中継への影響を抑えることができる。

このように、本発明の実施の形態２にでは、ＡＣＴとＳＢＹでフローエントリの仕様が異なっていても、ローリングアップデートを行う場合に、クラスタ切り替え後の大量のｆｌｏｗ ｍｏｄの送信を抑えることができる。その理由は、本発明の実施の形態２により、ＯＦＳ側で自律的にフローテーブルの書き換えを行うようになるため、ＯＦＣとの通信がトリガ等の最小限となるからである。

また、仕様変更により、フローエントリのｃｏｏｋｉｅ値などを変更する場合のハードルやリスクが非常に低くなる。本発明の実施の形態２により、ＯＦＣを介さずにＯＦＳ上で、フローエントリ情報を直接上書きしてしまうので、フローエントリが無効になる時間が無くなるからである。

＜その他の発明の実施の形態＞
上述した発明の実施の形態は、フローエントリのｃｏｏｋｉｅ書き換え以外にも、グループテーブルのグループＩＤのリファクタリング（グループエントリの内容へ変更せずにグループＩＤのみ置換する）などにも応用可能である。

尚、上述した実施の形態２では、ＯＦＣのローリングアップデートの場合について説明したが、これに限定されない。例えば、１台のＯＦＣをアップデートするために停止するタイミングを所定のタイミングとしてもよい。さらに、ＯＦＣが二重化されている場合について説明したが、これに限定されない。例えば、通信制御装置が１台で運用されている場合に、当該通信制御装置のメンテナンスに合わせて、通信中継装置内の複数の中継定義情報の更新内容を１つにまとめた更新情報を送信することにより、更新を行うようにしてもよい。

さらに、本発明は上述した実施の形態のみに限定されるものではなく、既に述べた本発明の要旨を逸脱しない範囲において種々の変更が可能であることは勿論である。例えば、上述の実施の形態では、本発明をハードウェアの構成として説明したが、本発明は、これに限定されるものではない。本発明は、任意の処理を、ＣＰＵ（Central Processing Unit）にコンピュータプログラムを実行させることにより実現することも可能である。この場合、コンピュータプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。

非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Read Only Memory）、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、ＤＶＤ（Digital Versatile Disc）、ＢＤ(Blu-ray(登録商標) Disc)、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（Random Access Memory））を含む。また、コンピュータプログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
（付記１）
装置間の通信の中継に関する定義である複数の中継定義情報を記憶する記憶部と、
前記中継定義情報を更新するための更新情報を取得する取得部と、
複数の前記中継定義情報を更新するための更新指示に応じた所定のタイミングにより、前記更新情報に基づく更新処理を実行する更新部と、
を備える通信中継装置。
（付記２）
前記更新情報は、前記中継定義情報に対応する新たな識別情報を含み、
前記更新部は、
前記更新処理により前記中継定義情報における識別情報を、前記更新情報に含まれる新たな識別情報へ更新する
付記１に記載の通信中継装置。
（付記３）
前記取得部は、複数の中継定義情報の更新内容に応じた更新処理が実装された更新プログラムを前記更新情報として取得し、
前記更新部は、前記更新プログラムを前記所定のタイミングに実行することにより、前記更新処理を行う
付記１又は２に記載の通信中継装置。
（付記４）
前記通信中継装置は、稼働系と待機系により冗長構成された複数の通信制御装置により制御され、
前記更新部は、前記稼働系と前記待機系の切り替えを前記所定のタイミングとして、前記更新処理を開始する
付記１乃至３のいずれか１項に記載の通信中継装置。
（付記５）
前記更新部は、
前記通信制御装置と当該通信中継装置との間の制御のための接続が切断されたことを検出した場合を、前記所定のタイミングとして前記更新処理を開始する
付記４に記載の通信中継装置。
（付記６）
前記取得部は、
外部から前記更新処理の開始要求を前記更新指示として取得し、
前記更新部は、前記開始要求の取得後に前記接続が切断されたことを検出した場合に、前記更新処理を開始する
付記５に記載の通信中継装置。
（付記７）
前記取得部は、前記所定のタイミングの基準となる時刻情報を前記更新情報に含めて取得し、
前記更新部は、前記接続が切断されたことを検出した場合に、前記取得した時刻情報に基づいて前記所定のタイミングであるか否かを判定し、当該所定のタイミングであると判定した場合に、前記更新処理を開始する
付記５又は６に記載の通信中継装置。
（付記８）
前記通信中継装置は、
前記稼働系と前記待機系の切り替えの前に前記更新情報を取得している
付記４乃至７のいずれか１項に記載の通信中継装置。
（付記９）
装置間の通信の中継に関する定義である複数の中継定義情報を保持し、当該中継定義情報に基づいて前記装置間の通信の中継を行う通信中継装置と、
前記通信中継装置を制御する通信制御装置と、
前記通信中継装置及び前記通信制御装置と接続された管理サーバと、を備え、
前記通信制御装置又は前記管理サーバは、前記中継定義情報を更新するための更新情報を前記通信中継装置へ送信し、
前記通信中継装置は、
前記更新情報を受信し、
複数の前記中継定義情報を更新するための指示に応じて、前記更新情報に基づく更新処理を所定のタイミングにより実行する、
通信中継システム。
（付記１０）
装置間の通信の中継に関する定義である複数の中継定義情報の更新方法であって、
前記複数の中継定義情報を保持する通信中継装置が、
前記中継定義情報を更新するための更新情報を取得し、
複数の前記中継定義情報を更新するための更新指示に応じた所定のタイミングにより、前記更新情報に基づく更新処理を実行する
中継定義情報の更新方法。
（付記１１）
コンピュータに、
装置間の通信の中継に関する定義である中継定義情報を更新するための更新情報を取得する処理と、
複数の前記中継定義情報を更新するための更新指示に応じた所定のタイミングにより、前記更新情報に基づいて更新する更新処理と、
を実行させる更新プログラム。
（付記１２）
稼働系と待機系により冗長構成された複数の通信制御装置により制御され、
端末間の通信の中継に関する定義である複数の中継定義情報を保持し、
前記稼働系と前記待機系の切り替えの間に、前記複数の中継定義情報のうち２以上を更新するための更新情報に基づいて、当該２以上の中継定義情報の更新処理を開始する
通信中継装置。

１００ 通信中継装置
１１０ 記憶部
１１１ａ、１１１ｂ、・・・１１１ｎ 中継定義情報
１１２ 更新情報
１２０ 取得部
１３０ 更新部
１ ＯｐｅｎＦｌｏｗネットワークシステム
１１〜１６ 端末
２１、２２ ＯＦＣ（Ｏｐｅｎ Ｆｌｏｗ Ｃｏｎｔｒｏｌｌｅｒ）
３１〜３３ ＯＦＳ（Ｏｐｅｎ Ｆｌｏｗ Ｓｗｉｔｃｈ）
４０ 管理サーバ
５０ 開発端末
４０１ 構成管理機能
４０２ ＯＦＳ制御機能
４０３ ＯＦＳ及び更新ソフトウェア管理機能
４０４ ＯＭＡ−ＤＭサーバ
３１１ テーブル編集機能
３１２ ＯＦＳ更新管理機能
３１３ ＯＭＡ−ＤＭクライアント
Ｍ１ ソフトウェア配信、更新開始トリガ
Ｍ２ クラスタ切り替え
Ｍ３ ｓｅｃｕｒｅ ｃｈａｎｎｅｌ切断
６０１〜６０３ ポート
６１ ＯｐｅｎＦｌｏｗ制御ＩＣ
６１１ イーサネット制御部
６１２ ＳＲＡＭ
６１３ フローテーブル
６１４ グループテーブル
６１５ フローエントリ
６１６ ｃｏｏｋｉｅ
６２ アドレス及びデータバス
６３ ＮＯＲ ＦＬＡＳＨ ＭＥＭＯＲＹ
６４ ＣＰＵ
６５ イーサネットドライバＩＣ
６６ ＨＤＤ
６７ ＳＤＲＡＭ
６８ ＳＡＴＡ
６９ ＳＤＲＡＭ／ＩＦ
７１ ＯｐｅｎＦｌｏｗ制御ＩＣ用ドライバ
７２ 組み込みＬｉｎｕｘ
７３ ＯｐｅｎＦｌｏｗＳｗｉｔｃｈ制御／管理アプリ
７４ ログフィルタリング処理アプリ
７５ ＯＦＳ更新アプリ
７６ デバイス管理ライブラリ
７７ ログフィルタリングルール
７８ フローテーブル更新アプリ
７９１ ＤＭＴ制御ライブラリ
７９２ ユーザ作成ライブラリ

Claims (6)

1. 通信制御装置により制御される通信ノードであって、
   受信パケットの処理ルールを定義したフローエントリを記憶する記憶手段と、
   前記通信制御装置の仕様変更のためのアップデートに伴う前記フローエントリの更新に用いる更新情報を外部から受信する受信手段と、
   前記更新情報を用いて前記更新を実行する更新手段と、
   を備え、
   前記更新手段は、前記通信制御装置から通知される更新指示に従って前記更新を開始し、
   前記更新指示は、前記更新を開始するタイミングを示す情報を含む
   ことを特徴とする通信ノード。
2. 前記通信制御装置は冗長構成された通信制御装置であり、
   前記タイミングを示す情報は、前記冗長構成された通信制御装置の稼働系と待機系を切り替える時刻を示す情報である
   ことを特徴とする請求項１に記載の通信ノード。
3. 前記更新情報は、前記フローエントリに含まれる情報を書き換えるための書き換え情報を含み、
   前記更新手段は、前記フローエントリに含まれる情報を、前記書き換え情報に書き換える
   ことを特徴とする請求項１又は２のいずれか一項に記載の通信ノード。
4. 受信パケットの処理ルールを定義したフローエントリを記憶し、前記フローエントリを用いて当該受信パケットを処理する通信ノードと、
   前記通信ノードに対して、自身の仕様変更のためのアップデートに伴う前記フローエントリの更新に用いる更新情報を送信する通信制御装置と、
   を含み、
   前記通信ノードは、前記通信制御装置から通知される更新指示に従って前記フローエントリの更新を開始し、
   前記更新指示は、前記更新を開始するタイミングを示す情報を含む
   ことを特徴とする通信システム。
5. 受信パケットの処理ルールを定義したフローエントリの更新方法であって、
   前記フローエントリを記憶する記憶手段と、
   通信制御装置の仕様変更のためのアップデートに伴う前記フローエントリの更新に用いる更新情報を用いて前記更新を実行する更新手段と、
   を備える通信ノードにおいて、
   前記更新情報を外部から受信するステップと、
   前記通信制御装置から通知される更新指示に従って前記更新を開始するステップと、
   を含み、
   前記更新指示は、前記更新を開始するタイミングを示す情報を含む
   ことを特徴とする更新方法。
6. 受信パケットの処理ルールを定義したフローエントリを記憶する記憶手段と、
   通信制御装置の仕様変更のためのアップデートに伴う前記フローエントリの更新に用いる更新情報を外部から受信する受信手段と、
   前記更新情報を用いて前記更新を実行する更新手段と、
   を備えるコンピュータに、
   前記通信制御装置から通知される更新指示に含まれる前記更新を開始するタイミングに従って前記更新を開始させる
   処理を実行させることを特徴とする更新プログラム。

Images