JP6237102B2 - 管理装置、管理装置の制御方法及びプログラム - Google Patents

Description

本発明は、管理装置、管理装置の制御方法及びプログラムに関し、特に、装置間の通信を中継定義情報に基づき中継する通信中継装置を管理する管理装置、管理装置の制御方法及びプログラムに関する。

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

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

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

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

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

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

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

ところで、ＯＦＳ等の通信中継装置における通信を中継するための定義である中継定義情報を既存のプロトコルに従って更新しようとすると、通常のフロー制御の通信への影響が大きくなるおそれがある。その理由は、既存のプロトコルに基づく更新用コマンドは、中継定義情報の更新単位が限られているためである。そのため、きめ細かな更新が行えず、更新内容によっては、通信制御装置と通信中継装置の間でフローエントリ間の状態整合処理等の通信量が膨大となり得る。よって、通常のフロー制御の通信への影響が大きくなるおそれがある。

本発明は、このような問題点を解決するためになされたものであり、通信への影響を抑えつつ、通信中継装置の中継定義情報を更新するための更新情報の生成及び配付を行う管理装置、管理装置の制御方法及びプログラムを提供することを目的とする。

本発明の第１の態様にかかる管理装置は、
装置間の通信の中継に関する複数の中継定義情報が制御装置により設定される通信中継装置で用いられ、複数の前記中継定義情報を更新するための更新情報を生成する更新情報生成部と、
前記更新情報を前記通信中継装置に対して送付する送付部と、
を備える。

本発明の第２の態様にかかる管理装置の制御方法は、
装置間の通信の中継に関する複数の中継定義情報が制御装置により設定される通信中継装置で用いられ、複数の前記中継定義情報を更新するための更新情報を生成し、
前記更新情報を前記通信中継装置に対して送付する。

本発明の第３の態様にかかるプログラムは、
装置間の通信の中継に関する複数の中継定義情報が制御装置により設定される通信中継装置で用いられ、複数の前記中継定義情報を更新するための更新情報を生成する更新情報生成処理と、
前記更新情報を前記通信中継装置に対して送付する送付処理と、
をコンピュータに実行させる。

本発明により、通信への影響を抑えつつ、通信中継装置の中継定義情報を更新するための更新情報の生成及び配付を行う管理装置、管理装置の制御方法及びプログラムを提供することができる。

本発明の実施の形態１にかかる通信中継装置の構成を示すブロック図である。 本発明の実施の形態１にかかる中継定義情報の更新処理の流れを示すフローチャートである。 本発明の実施の形態２にかかるＯｐｅｎＦｌｏｗネットワークシステムの構成を示すブロック図である。 本発明の実施の形態２にかかる管理サーバ及びＯＦＳの概要構成を示すブロック図である。 本発明の実施の形態２にかかるＯＦＳのハードウェア構成を示すブロック図である。 本発明の実施の形態２にかかるＯＦＳ内のＣＰＵ上で動作するソフトウェア構成の概念図である。 本発明の実施の形態２にかかる更新ソフトウェアの配信処理の流れを説明するためのシーケンス図である。 本発明の実施の形態２にかかるＯＦＣの系切替時におけるＯＦＳのフローテーブル更新処理の流れを説明するためのシーケンス図である。 本発明の実施の形態３にかかる管理装置の構成を示すブロック図である。 本発明の実施の形態３にかかるプログラム生成装置の構成を示すブロック図である。 本発明の実施の形態３にかかるプログラム生成処理の流れを示すフローチャートである。 本発明の実施の形態５にかかるプログラム生成装置のハードウェア構成を示すブロック図である。 本発明の実施の形態５にかかる更新プログラムの生成の概念を説明する図である。 本発明の実施の形態５にかかるＯｐｅｎＦｌｏｗ ｓｗｉｔｃｈのＤＭＴ図の例を示す図である。 本発明の実施の形態５にかかるＤＭＴ状態遷移図の例を示す図である。 本発明の実施の形態５にかかるｃｏｏｋｉｅ変換ファイルの例を示す図である。 本発明の実施の形態５にかかる更新プログラムをＯＦＳ上での実行した場合のシーケンス図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図５は、本発明の実施の形態２にかかるＯＦＳ３１のハードウェア構成を示すブロック図である。ＯＦＳ３１は、ＯｐｅｎＦｌｏｗ制御ＩＣ６１と、ＮＯＲ ＦＬＡＳＨ ＭＥＭＯＲＹ６３と、ＣＰＵ（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）８０１と、ＲＡＭ（Random Access Memory）８０２と、ＲＯＭ（Read Only Memory）８０３と、ＩＦ部８０４と、ハードディスク８０５とを備える。

また、ハードディスク８０５は、不揮発性記憶装置である。ハードディスク８０５は、ＯＳ８０５１、統合開発環境８０５２、変換ルール８０５３及びライブラリ８０５４等を予め格納しているものとする。

統合開発環境８０５２は、後述するモデル作成ツール、モデルコンパイラ、モデル検証ツール及びコンパイラ／リンカ等を含む。但し、コンパイラ／リンカは含まなくても良い。統合開発環境８０５２は、発明の実施の形態４にかかるプログラム生成プログラムを含み、ＧＵＩによりＤＭＴによる構成情報（例えば、後述するＤＭＴ図）及びノード状態情報（例えば、後述する状態遷移図）等であるＤＭＴモデルの設計を支援するためのソフトウェアである。そして、統合開発環境８０５２は、ＤＭＴモデルから更新プログラムを生成する。つまり、統合開発環境８０５２は、モデルコンパイラによりＤＭＴモデルからソースコードへ変換し、その後ｇｃｃなどのコンパイラ／リンカによって機械語のバイナリであるユーザ作成アプリに変換される。

変換ルール８０５３は、ＤＭＴモデルからソースコードへ変換するためのルールを定義したファイルである。そのため、モデルコンパイラは変換ルール８０５３に基づいてＤＭＴモデルをソースコードへ変換する。尚、変換ルール８０５３は、非常に複雑なスクリプトであるため基本的には開発ツールベンダが提供するが、ユーザが独自の修正を入れたものを用いることもできる。さらに、機種毎に複数の変換ルール８０５３を用意することで、単一のＤＭＴモデルで複数の機種向けのソースコードを生成することが可能である。

ライブラリ８０５４は、フローテーブルの更新処理に用いられる各種ライブラリ関数、クラスライブラリ、ＡＰＩ等のプログラムモジュールである。ライブラリ８０５４は、上述した更新処理モジュール８１１の一例を含む。また、ライブラリ８０５４は、開発ツールベンダが提供するＤＭＴ制御ライブラリ（上述したＤＭＴ制御ライブラリ７９１を含む）や、ユーザが必要に応じて作成するユーザ作成ライブラリ（上述したユーザ作成ライブラリ７９２を含む）を含む。ＤＭＴ制御ライブラリは、ＤＭＴに割り当てられたノード（フローテーブルなど）を制御するためのライブラリである。ユーザ作成ライブラリは、複雑なロジックが実装された関数群であり、ユーザがＣ／Ｃ＋＋言語などを使用して通常の開発において作成する。これにより、モデルの振る舞いとロジックを分離することが実現できる。尚、ライブラリ８０５４は、予めＯＦＳへ配信しておいてもよい。

ＣＰＵ８０１は、プログラム生成装置８００ａにおける各種処理、ＲＡＭ８０２、ＲＯＭ８０３、ＩＦ部８０４及びハードディスク８０５へのアクセス等を制御する。ＩＦ部８０４は、上述した管理サーバ４０との通信を行う。

プログラム生成装置８００ａは、ＣＰＵ８０１が、ＲＡＭ８０２、ＲＯＭ８０３又はハードディスク８０５に格納されたＯＳ８０５１、統合開発環境８０５２等を読み込み、実行する。これにより、プログラム生成装置８００ａは、構成情報生成部８２０、ノード状態情報生成部８３０、プログラム生成部８４０、更新情報生成部等として機能し、更新プログラムを生成することができる。

図１３は、本発明の実施の形態５にかかる更新プログラムの生成の概念を説明する図である。統合開発環境８５は、上述した統合開発環境８０５２がＣＰＵ８０１により実行されている状態を機能ブロックとして示したものである。統合開発環境８５は、モデル作成ツール８５１と、モデルコンパイラ８５２と、コンパイラ／リンカ８５３とを含む。

モデル作成ツール８５１は、ユーザによる入力８６０に応じてＤＭＴモデルであるＤＭＴ図８６１及び状態遷移図８６２並びにｃｏｏｋｉｅ変換定義８６３を生成する。ユーザによる入力８６０には、要素をノードへの割り当て、ノードの選択、状態及び当該状態におけるアクション記述、更新値等を含む。例えば、モデル作成ツール８５１は、ユーザからの特定の要素における更新値の入力に応じて、ＣＳＶファイルなどの変換ルール定義ファイル（後述するｃｏｏｋｉｅ変換定義等）を生成する。また、モデル作成ツール８５１は、状態遷移図には、変換ルール定義ファイルを読み込み、更新を行う更新処理モジュールの呼び出しを設定する。そのため、ユーザは、ｃｏｏｋｉｅなどの新旧パラメータを記述するだけで、更新処理を実装することができる。

モデルコンパイラ８５２は、ＤＭＴ図８６１、状態遷移図８６２及びｃｏｏｋｉｅ変換定義８６３を読み込み、変換ルール８６４に基づいてソースコードへ変換してソースプログラム８６５として出力する。尚、変換ルール８６４をＯＦＳの機種ごとに複数備えることにより、一つのＤＭＴモデル及び一つのモデルコンパイラ８５２により、複数種類のＯＦＳに応じた変換ルール８６４を用いることで、複数種類のソースプログラム８６５を生成することができる。または、モデルコンパイラ８５２をＯＦＳの機種ごとに複数備えることにより、一つのＤＭＴモデルから複数種類のＯＦＳに応じたモデルコンパイルを用いることで、複数種類のソースプログラム８６５を生成することができる。そのため、統合開発環境８０５２は、変換ルール定義ファイルとＭＤＡのアクション記述言語を用いてＯＦＳの機械語バイナリ又はＪａｖａ（登録商標）などの中間言語の自動生成を行うものである。

コンパイラ／リンカ８５３は、ソースプログラム８６５から機械語のバイナリであるオブジェクトプログラム８６６へ変換して出力する。ここで、オブジェクトプログラム８６６は、ユーザ作成アプリ８６６１及び必要なライブラリ８６６２を含むものとしているが、最低限ユーザ作成アプリ８６６１を含めばよい。

図１４は、本発明の実施の形態５にかかるＯｐｅｎＦｌｏｗ ｓｗｉｔｃｈのＤＭＴ図８６１の例を示す図である。ＤＭＴ図８６１は、ツリー構造で表現され、ＯｐｅｎＦｌｏｗにおけるフローテーブルやグループテーブル、そして各テーブルに含まれる要素（フローエントリ、テーブルＩＤ、ｃｏｏｋｉｅ、マッチ条件、アクション等）が階層的にノードに割り当てられている。そのため、各ノードはＵＲＬのような形式で一意に特定することができ、参照することができる。例えば、ＤＭＴノードｃｏｏｋｉｅは、“./openflow/flow_table/flow_entry/cookie”という形式で表現することができる。

図１５は、本発明の実施の形態５にかかるＤＭＴ状態遷移図８６２の例を示す図である。ＤＭＴノードの状態遷移図８６２には、各ノードにおける状態毎にアクション記述言語によるＤＭＴの振る舞いを定義することができる。ここで使用されるアクション記述言語は、Executable UML向けのものを改良したものである。

図１５の状態遷移図８６２は、フローテーブルに対するＤＭＴノード“flow entry”に対する振る舞いを記述した例であり、フローテーブルが持つ全フローエントリのｃｏｏｋｉｅを置換するという処理が記述されている。ＤＭＴノード８６２０は、状態遷移図８６２がノード”flow entry”を対象とすることを定義している。ここで、ＤＭＴノード８６２０は、ＤＭＴ図８６１に基づき、ｓｙｎｃＭＬでのｌｏｃａｌ ＵＲＩの表現方法である”./openflow/flow_table/flow_ entry”という形式で表現している。

イベント８６２１は、「ソフト更新開始イベント」の定義である。そして、イベント８６２１には、ソフト更新開始イベントの開始可能な時間帯を示す開始時間情報が設定されている。ここで、開始時間情報は、ユーザによる入力８６０に含まれており、モデル作成ツール８５１が状態遷移図８６２に設定する。

状態８６２２は、「ｃｏｏｋｉｅ値変換中」状態の定義である。ＤＭＴノードのflow entry状態が、本状態になると、処理８６２３及び８６２４においてアクション記述言語で記述された処理が実行される。ここで、状態８６２２まで遷移する処理を具体的に説明すると次のようになる。例えば、ＯＦＳがsecure channel切断などを検出すると、ソフト更新開始イベントが発生する。そして、当該イベントが開始時間情報の範囲を満たせば、ＤＭＴノードflow_entryが「ｃｏｏｋｉｅ値変換中」状態８６２２に遷移することとなる。一方、トリガが発生したとしても開始時間情報の範囲外であれば、本イベントは無効、つまり状態８６２２には遷移しないこととなる。

処理８６２３は、ＣＳＶファイルを使用してｃｏｏｋｉｅを変換する処理が記述されている。具体的には、Ofutil::cookie_converter()というライブラリ関数を呼び出す処理が記述されている。Ofutil::cookie_converter()は、ｃｏｏｋｉｅ変換定義８６３のＣＳＶファイルに基づいて、ｃｏｏｋｉｅを書き換える関数であり、例えば、ＤＭＴ制御ライブラリに定義されているものとする。よって、64bitのフローエントリのIDであるｃｏｏｋｉｅの上位16bitを、ＣＳＶファイルを使用して置換する処理を示す。

処理８６２４は、新ｃｏｏｋｉｅにmatch条件から計算されるhash値を挿入する処理が記述されている。具体的には、OfUserFuncs::calc_hash()というライブラリ関数を呼び出す処理が記述されている。OfUserFuncs::calc_hash()は、フローエントリのmatch条件からhash値を求める関数であり、例えば、ユーザ作成ライブラリに定義されているものとする。

尚、OfUserFuncs::calc_hash()などのユーザ作成ライブラリに含まれるユーザ定義関数は、アクション記述言語や他のスクリプト言語で作成することができる。複雑なロジックの場合は、C/C++言語などを用いて、通常の開発の手順で作成することもできる。C/C++言語などで作成された場合、これらの関数は共有ライブラリ化され、ＤＭＴのモデルから呼び出すことができる。つまりこれは、モデルの振る舞いと複雑なロジックを完全に分離できるということを表している。

また、特定のフローエントリのインスタンスを取得したい場合は、下記のように記述することができる。下記の例は、ＤＭＴノード”flow_table”に対して、ｃｏｏｋｉｅの値が0のフローエントリのみ選択する場合の表現方法である。
Select flow_info from flow_entry where this.flow_entry.cookie_id = 0

このように、状態遷移図８６２では、ＤＭＴの全インスタンス（この場合は、全フローエントリ）を対象として更新処理が行われることが定義されている。この更新処理は、ライブラリ８０５４に含まれているため、ユーザが“全フローエントリに対してXXを行う”という処理を明示的に記述する必要は無く、更新処理の具体的な実装の知識も不要となる。

図１６は、本発明の実施の形態５にかかるｃｏｏｋｉｅ変換定義８６３であるｃｏｏｋｉｅ変換ファイルの例を示す図である。ｃｏｏｋｉｅ変換定義８６３は、ＣＳＶ形式の変換表である。ｃｏｏｋｉｅ変換定義８６３は、新旧のｃｏｏｋｉｅ種別が定義されている。状態遷移図８６２内で、アクション記述言語を用いて、関連するライブラリ関数（ＤＭＴ制御ライブラリ関数等）の呼び出しを記述するだけで、ｃｏｏｋｉｅの置換が可能となる。そのため、ＤＭＴモデルから、機械的な変換処理をロジックから切り離すことができる。

図１７は、本発明の実施の形態５にかかる更新プログラムをＯＦＳ上での実行した場合のシーケンス図である。前提として、本発明の実施の形態５にかかるプログラム生成装置８００ａにより生成されたバイナリ形式の更新プログラム（ＯＦＳ更新アプリ７５、フローテーブル更新アプリ７８及びユーザ作成ライブラリ７９２）が、ＯＦＳに配信済みであるものとする。また、ＯＦＳのフローテーブルに、３個のフローエントリが登録されているものとする。尚、ログフィルタリング処理アプリ７４、ＤＭＴ制御ライブラリ７９１及びＯｐｅｎＦｌｏｗＳｗｉｔｃｈ制御／管理アプリ７３は、図６に示したものと同等であるものとする。また、この例では、図１５のmatch条件からhash値を生成するロジックがＣ言語で作成されており、ｇｃｃを用いたビルド作業によりユーザー作成ライブラリ７９２が生成されている。

まず、ログフィルタリング処理アプリ７４は、セキュアチャネルの切断を検出し、ＯＦＳ更新アプリ７５へセキュアチャネルの切断通知を送信する（Ｓ４０１）。次に、ＯＦＳ更新アプリ７５は、有効なＤＭＴノードのインスタンスを検索および実行開始時刻情報の比較を行う（Ｓ４０２）。ここでは、セキュアチャネルの切断通知の時刻が実行開始時刻情報の範囲内であるものとする。

そして、ＯＦＳ更新アプリ７５は、ＯｐｅｎＦｌｏｗＳｗｉｔｃｈ制御／管理アプリ７３を参照し、全フローエントリ情報を取得する（Ｓ４０３）。その後、まず、ＯＦＳ更新アプリ７５は、ＤＭＴノード“ｆｌｏｗ ｅｎｔｒｙ １”を実行する（Ｓ４１１）。具体的には、ＤＭＴノード“ｆｌｏｗ ｅｎｔｒｙ １”についてフローテーブル更新アプリ７８を呼び出す。フローテーブル更新アプリ７８は、ＤＭＴ制御ライブラリ７９１を呼び出し、ｃｏｏｋｉｅの全置換を行わせる（Ｓ４１２）。続いて、フローテーブル更新アプリ７８は、ユーザ作成ライブラリ７９２を呼び出し、ｍａｔｃｈ条件からｈａｓｈ値を取得する（Ｓ４１３）。その後、フローテーブル更新アプリ７８は、ｃｏｏｋｉｅの置換を行う（Ｓ４１４）。以後、ＯＦＳ更新アプリ７５は、同様に、ＤＭＴノード“ｆｌｏｗ ｅｎｔｒｙ ２”を実行し（Ｓ４２１〜Ｓ４２４）、ＤＭＴノード“ｆｌｏｗ ｅｎｔｒｙ ３”を実行する（Ｓ４３１〜Ｓ４３４）。

このように、本発明の実施の形態５により、開発者でない保守部門のサービスエンジニアでも、ＯＦＳの更新ソフトウェアを作成できる。その理由は、本発明の実施の形態５にかかる統合開発環境８５を用いて作成することによりモデルの振る舞いとロジックを分離できるからである。そして、複雑なロジックについてのみ、開発部門に開発を依頼すればよくなり、開発効率が高まる。

また、ＯＦＳ固有のシステム依存部分（プログラミング言語、ＯＳなど）やハードウェアに関する知識の習得が不要となる。また、コーディング工程も簡略化できる。その理由は、本発明の実施の形態５によりＤＭＴのモデルからソースコードが自動生成され、さらにＤＭＴに対する読み書きのみで、フローテーブルやＯｐｅｎＦｌｏｗ制御ＩＣへのレジスタアクセスが実現でき、ソースコードも自動生成されるからである。さらに、各々の機種向けのモデルコンパイラを用意しておけば、単一のＤＭＴモデルで、複数の機種に対応したＯＦＳの更新プログラムも作成できる。

また、本発明の実施の形態５では、フローテーブル内のパラメータなどのＯＦＳの内部パラメータや機能をＤＭＴ内のノードに割り当てることにより、ユーザは、MDAのアクション記述言語(executable UMLのaction記述言語)などにより容易に更新処理を定義することができる。そして、モデルコンパイラ経由でC/C++などのＮａｔｉｖｅ言語や中間言語のソースコードに変換するものである。

このため、従来のＭＤＡ技術とは異なり、ユーザは、ＤＭＴのノード単位で、ソフトウェア書き換え開始のイベントを受けた場合のアクションを記述するだけでよく、更新プログラムを作成する難易度を下げることができる。

また、本発明の実施の形態５では、ソフトウェア更新開始イベントに実行開始時刻情報を設定する。これにより、更新処理の開始タイミングを制御することができる。

さらに、変換表を参照してｃｏｏｋｉｅの種別変換を行うライブラリ（更新処理モジュール）を予め作成しておくことで、新旧のｃｏｏｋｉｅ種別変換などに関しては変換表(ＣＳＶファイルなど)を記述しておけばよくなる。そして、アクション記述言語からサポートするライブラリを呼ぶだけで、容易に新旧パラメータの変換が可能となる。よって、この点においても更新プログラムを作成する難易度を下げることができる。

また、モデルコンパイラを複数用意すれば、単一のモデル記述から複数の機種のＯＦＳのバイナリプログラムを生成でき、複数の機種のＯＦＳに対応することが可能となる。

また、本発明の実施の形態５は、抽象化されたＤＭＴのモデル記述から、ＯＦＳの更新ソフトウェアのバイナリを自動生成することができる。このとき、ユーザは、ＤＭＴのノードに関連する部分のみ記述するだけでよく、更新プログラム全体のモデル記述を行う必要がない。

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

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

さらに、本発明は上述した実施の形態のみに限定されるものではなく、既に述べた本発明の要旨を逸脱しない範囲において種々の変更が可能であることは勿論である。例えば、上述の実施の形態では、本発明をハードウェアの構成として説明したが、本発明は、これに限定されるものではない。本発明は、任意の処理を、ＣＰＵ（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 (7)

1. 装置間の通信の中継に関する複数の中継定義情報が制御装置により設定される通信中継装置で用いられ、複数の前記中継定義情報を更新するための更新情報を生成する更新情報生成部と、
   前記更新情報を前記通信中継装置に対して送付する送付部と、
   前記中継定義情報に対する更新処理が定義された更新処理モジュールを記憶する記憶部と、
   を備え、
   前記更新情報生成部は、
   前記中継定義情報に含まれる複数の要素のそれぞれを複数のノードにより定義した構成情報を生成する構成情報生成部と、
   前記複数のノードのうち更新対象の要素に対応するノードの状態と、当該状態において前記更新処理モジュールを呼び出す処理を定義したノード状態情報を生成するノード状態情報生成部と、
   前記構成情報及び前記ノード状態情報に基づいて、前記複数の中継定義情報を更新するための前記更新処理モジュールを有し、前記通信中継装置で実行されるプログラムを、前記更新情報として生成するプログラム生成部と、
   を備える管理装置。
2. 前記更新情報生成部は、
   前記更新対象の要素における更新値の入力を受け付け、当該更新値を含めて前記更新情報を生成し、
   前記更新処理モジュールは、前記更新情報から抽出した更新値を用いた前記更新処理が定義されている
   請求項１に記載の管理装置。
3. 前記ノード状態情報生成部は、
   前記プログラムを開始可能な時間帯を示す開始時間情報の入力を受け付け、
   前記定義した状態へ遷移するための条件として前記開始時間情報を設定して、前記ノード状態情報を生成する
   請求項１又は２に記載の管理装置。
4. 前記記憶部は、前記構成情報及び前記ノード状態情報から前記プログラムへ変換するためのルールを前記通信中継装置の種類ごとに定義した複数の変換ルールをさらに記憶し、
   前記プログラム生成部は、前記複数の変換ルールの中から、前記更新対象の通信中継装置の種類に応じた変換ルールを選択し、当該選択した変換ルールに基づいて前記プログラムを生成する
   請求項１乃至３のいずれか１項に記載の管理装置。
5. 前記構成情報及び前記ノード状態情報から前記プログラムへ変換を行う複数のモデルコンパイラを、前記通信中継装置の種類ごとに備え、
   前記プログラム生成部は、前記複数のモデルコンパイラの中から、前記更新対象の前記通信中継装置の種類に応じたモデルコンパイラを選択し、当該選択したモデルコンパイラにより変換して前記プログラムを生成する
   請求項１乃至３のいずれか１項に記載の管理装置。
6. 装置間の通信の中継に関する複数の中継定義情報が制御装置により設定される通信中継装置で用いられ、複数の前記中継定義情報を更新するための更新情報を生成し、
   前記更新情報を前記通信中継装置に対して送付し、
   前記更新情報の生成において、
   前記中継定義情報に含まれる複数の要素のそれぞれを複数のノードにより定義した構成情報を生成し、
   前記複数のノードのうち更新対象の要素に対応するノードの状態と、当該状態において、前記中継定義情報に対する更新処理が定義された更新処理モジュールを呼び出す処理を定義したノード状態情報を生成し、
   前記構成情報及び前記ノード状態情報に基づいて、前記複数の中継定義情報を更新するための前記更新処理モジュールを有し、前記通信中継装置で実行されるプログラムを、前記更新情報として生成する、
   管理装置の制御方法。
7. 装置間の通信の中継に関する複数の中継定義情報が制御装置により設定される通信中継装置で用いられ、複数の前記中継定義情報を更新するための更新情報を生成する更新情報生成処理と、
   前記更新情報を前記通信中継装置に対して送付する送付処理と、
   をコンピュータに実行させ、
   前記更新情報生成処理は、
   前記中継定義情報に含まれる複数の要素のそれぞれを複数のノードにより定義した構成情報を生成する構成情報生成処理と、
   前記複数のノードのうち更新対象の要素に対応するノードの状態と、当該状態において、前記中継定義情報に対する更新処理が定義された更新処理モジュールを呼び出す処理を定義したノード状態情報を生成するノード状態情報生成処理と、
   前記構成情報及び前記ノード状態情報に基づいて、前記複数の中継定義情報を更新するための前記更新処理モジュールを有し、前記通信中継装置で実行されるプログラムを、前記更新情報として生成するプログラム生成処理と、を含む
   プログラム。

Images