JPWO2014168164A1 - ネットワーク検証装置、ネットワーク検証方法及びプログラム - Google Patents

Abstract

ネットワークの網羅的な検証の効率向上に貢献する。ネットワーク検証装置は、検証対象のネットワークの構成及びネットワークに含まれる機器の動作モデルを定義した検証情報の入力を受け付ける検証情報入力部と、前記検証情報を用いたモデル検査において、前記ネットワークに接続された端末からのパケットの内容を具体的に扱わずに状態遷移を行い、かつ、次状態の状態探索前に探索要否確認部に対し、各状態の過去の遷移経路に関する情報を送り、前記次状態の探索を省略可能か否かを問い合わせながらモデル検査を行うモデル検査実行部と、前記モデル検査実行部から受け取った状態の過去の遷移経路に関する情報に基づいて、前記次状態の探索が省略可能か否かを判断し、前記状態の探索が省略可能か否かを応答する探索要否確認部と、前記モデル検査実行部の出力に基づき、検証の結果を出力する検証結果出力部と、を備える。

Description

［関連出願についての記載］
本発明は、日本国特許出願：特願２０１３−０８１８８６号（２０１３年 ４月１０日出願）に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
本発明は、ネットワーク検証装置、ネットワーク検証方法及びプログラムに関し、特に、検証対象のネットワークをモデル化して検証を行うネットワーク検証装置、ネットワーク検証方法及びプログラムに関する。

ネットワークの運用管理に関して、ＯｐｅｎＦｌｏｗという技術が注目されている（非特許文献１、２参照）。ＯｐｅｎＦｌｏｗは、Ｓｏｆｔｗａｒｅ−Ｄｅｆｉｎｅｄ Ｎｅｔｗｏｒｋ（以下、「ＳＤＮ」）の概念を実現する技術としても注目されている。ＳＤＮは、ネットワーク制御をプログラマブルな方法で一元管理するという、ネットワークの分野の新たなパラダイムであり、特にＯｐｅｎＦｌｏｗは、ネットワーク運用の自動化・効率化・省電力化等、様々な期待を集めている。

一方で、ＯｐｅｎＦｌｏｗでは、ネットワーク制御の柔軟性が増す分、それに伴う不具合の発生が懸念されている。例えば開発者の考慮漏れや、複数のプログラムを組み合わせたことによる不具合が多くなる。そのためＯｐｅｎＦｌｏｗネットワークの安定運用には、そのネットワークが安全なものかを事前に検証することが重要となる。例えば、非特許文献３には、モデル検査によりＯｐｅｎＦｌｏｗネットワークの状態探索を行う“ＮＩＣＥ”というツールが開示されている。非特許文献３によると、“ＮＩＣＥ”は、ＯｐｅｎＦｌｏｗコントローラのプログラムを記号実行し、すべてのコードパスを実行するためのパケットの代表値の集合を求め、それを用いて状態探索を行っている。

Ｎｉｃｋ ＭｃＫｅｏｗｎほか７名、"ＯｐｅｎＦｌｏｗ： Ｅｎａｂｌｉｎｇ Ｉｎｎｏｖａｔｉｏｎ ｉｎ Ｃａｍｐｕｓ Ｎｅｔｗｏｒｋｓ"、［ｏｎｌｉｎｅ］、［平成２５（２０１３）年３月２５日検索］、インターネット〈URL: http://www.openflow.org/documents/openflow-wp-latest.pdf〉 "ＯｐｅｎＦｌｏｗ Ｓｗｉｔｃｈ Ｓｐｅｃｉｆｉｃａｔｉｏｎ" Ｖｅｒｓｉｏｎ １．０．０． （Ｗｉｒｅ Ｐｒｏｔｏｃｏｌ ０ｘ０１）、［ｏｎｌｉｎｅ］、［平成２５（２０１３）年３月２５日検索］、インターネット〈ＵＲＬ：https://www.opennetworking.org/images/stories/downloads/specification/openflow-spec-v1.0.0.pdf〉 Ｍａｒｃｏ Ｃａｎｉｎｉほか４名、"Ａ ＮＩＣＥ Ｗａｙ ｔｏ Ｔｅｓｔ ＯｐｅｎＦｌｏｗ Ａｐｐｌｉｃａｔｉｏｎｓ"、［ｏｎｌｉｎｅ］、［平成２５（２０１３）年３月２５日検索］、インターネット〈URL: http://infoscience.epfl.ch/record/170618/files/nsdi-final.pdf〉

以下の分析は、本発明によって与えられたものである。非特許文献３に代表される手法の問題点は、現実的なコスト（時間及びマシンリソース）で、ＯｐｅｎＦｌｏｗネットワークの主要な動作を網羅的に検証できないこと、あるいは、（現実的なコストでできないため）網羅的な検証をしないことである。

例えば、非特許文献３が開示している技術では、ＯｐｅｎＦｌｏｗコントローラのプログラムのすべてのコードパスを網羅する検証を行うが、前記プログラムが影響を与えるＯｐｅｎＦｌｏｗネットワークの動作（ＯｐｅｎＦｌｏｗスイッチによる通信パケットの転送動作等）を網羅する検証は行われない。そのため、ＯｐｅｎＦｌｏｗネットワークの主要な動作に関わる不具合が検出できない可能性がある。

上記の問題点は、非特許文献１、２のＯｐｅｎＦｌｏｗに固有のものではなく、ＳＤＮと呼ばれるネットワークに共通するものといえる。

本発明は、ＳＤＮに代表されるネットワークの網羅的な検証の効率向上に貢献できるネットワーク検証装置、プログラム及び方法を提供することを目的とする。

第１の視点によれば、検証対象のネットワークの構成及びネットワークに含まれる機器の動作モデルを定義した検証情報の入力を受け付ける検証情報入力部と、前記検証情報を用いたモデル検査において、前記ネットワークに接続された端末からのパケットの内容を具体的に扱わずに状態遷移を行い、かつ、次状態の状態探索前に探索要否確認部に対し、各状態の過去の遷移経路に関する情報を送り、前記次状態の探索を省略可能か否かを問い合わせながらモデル検査を行うモデル検査実行部と、前記モデル検査実行部から受け取った状態の過去の遷移経路に関する情報に基づいて、前記次状態の探索が省略可能か否かを判断し、前記状態の探索が省略可能か否かを応答する探索要否確認部と、前記モデル検査実行部の出力に基づき、検証の結果を出力する検証結果出力部と、を備えるネットワーク検証装置が提供される。

第２の視点によれば、検証対象のネットワークの構成及びネットワークに含まれる機器の動作モデルを定義した検証情報の入力を受け付けるステップと、前記検証情報を用いて、前記ネットワークに接続された端末からのパケットの内容を具体的に扱わずに状態遷移を行って、モデル検査を行うステップと、前記モデル検査の結果に基づいて前記検証対象のネットワークの検証結果を出力するステップと、を含み、前記モデル検査における次状態の状態探索前に、各状態の過去の遷移経路に関する情報に基づいて、前記次状態の探索が省略可能か否かを判断し、省略可能と判断した状態の探索を省略することを特徴とするネットワーク検証方法が提供される。本方法は、検証対象のネットワークのモデル検査を行う装置（ネットワーク検証装置）という、特定の機械に結びつけられている。

第３の視点によれば、検証対象のネットワークの構成及びネットワークに含まれる機器の動作モデルを定義した検証情報の入力を受け付ける処理と、前記検証情報を用いて、前記ネットワークに接続された端末からのパケットの内容を具体的に扱わずに状態遷移を行って、モデル検査を行う処理と、前記モデル検査の結果に基づいて前記検証対象のネットワークの検証結果を出力する処理と、さらに、前記モデル検査における次状態の状態探索前に、各状態の過去の遷移経路に関する情報に基づいて、前記各状態の探索が省略可能か否かを判断し、省略可能と判断した状態の探索を省略する処理とを、コンピュータに実行させるプログラムが提供される。なお、このプログラムは、コンピュータが読み取り可能な（非トランジエントな）記憶媒体に記録することができる。即ち、本発明は、コンピュータプログラム製品として具現することも可能である。

本発明によれば、ＳＤＮに代表されるネットワークの網羅的な検証の効率向上に貢献することが可能となる。

本発明の一実施形態の構成を示す図である。 本発明の第１の実施形態のネットワーク検証装置の構成を示す図である。 本発明の第１の実施形態のネットワーク検証装置に入力されるネットワークの構成情報（トポロジ情報）の一例を示す図である。 非特許文献２のＯｐｅｎＦｌｏｗスイッチの動作モデルの一例である。 非特許文献２のＯｐｅｎＦｌｏｗコントローラの動作モデルの一例である。 本発明の第１の実施形態のネットワーク検証装置で用いる端末の動作モデルの記述形式の一例を示す図である。 本発明の第１の実施形態のネットワーク検証装置で用いる制約充足問題の一例を示す図である。 本発明の第１の実施形態のネットワーク検証装置の動作を示す図である。 本発明の第１の実施形態のネットワーク検証装置によるモデル検査を表したサンプルコードである。 図９と等価のフローチャートである。 参考例として示すモデル検査を表したサンプルコードである。 図６の一行目のパケットに対応する制約情報の例を示す図である。 本発明の第１の実施形態のネットワーク検証装置のモデル検査においてスイッチ側に保持されているフローエントリのマッチングルールの例と、このマッチングルールへのヒットによる状態遷移時の制約情報の例を示す図である。 本発明の第１の実施形態のネットワーク検証装置のモデル検査においてスイッチ側に保持されているフローエントリのマッチングルールの例と、Ｐａｃｋｅｔ−Ｉｎメッセージの送信時の制約情報の例を示す図である。 本発明の第１の実施形態のネットワーク検証装置のモデル検査で用いるコントローラにおけるプログラム実行による動作ステップの例と、この動作ステップに対応する制約情報の例を示す図である。 本発明の第１の実施形態のネットワーク検証装置のモデル検査における遷移先状態の導出処理を説明するための図である。 本発明の第２の実施形態において想定するネットワーク機器の動作モデルの一例である。 本発明の第３の実施形態のネットワーク検証装置の構成を示す図である。

はじめに本発明の一実施形態の概要について図面を参照して説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、本発明を図示の態様に限定することを意図するものではない。

本発明は、その一実施形態において、図１に示すように、検証対象のネットワークの構成及びネットワークに含まれる機器の動作モデルを定義した検証情報の入力を受け付ける検証情報入力部１１と、前記検証情報を用いたモデル検査を行うモデル検査実行部１２と、探索要否確認部１３と、前記モデル検査実行部の出力に基づき、検証の結果を出力する検証結果出力部１４と、を備えるネットワーク検証装置にて実現できる。

より具体的には、モデル検査実行部１２は、前記検証情報を用いたモデル検査において、前記ネットワークに接続された端末からのパケットの内容を具体的に扱わずに状態遷移を行う。さらに、モデル検査実行部１２は、パケットの内容を具体的に扱わないことに対する措置として、次状態の状態探索前に、探索要否確認部１３に対し、各状態の過去の遷移経路に関する情報を送り、前記次状態の探索を省略可能か否かを問い合わせながらモデル検査を行う。ここで、「状態の過去の遷移経路」とは、ある「状態」がその状態に至るまでに遷移した１つ以上の「状態」によって構成される経路をいう。

一方、探索要否確認部１３は、前記モデル検査実行部から受け取った状態の過去の遷移経路に関する情報に基づいて、前記次状態の探索が省略可能か否かを判断し、前記状態の探索が省略可能か否かを応答する。

以上のように構成することにより、このネットワーク検証装置は、パケットの内容を具体的に扱わずにモデル検査を行い、その際に不要な状態については探索を省略する。これにより、効率よく網羅的な検証を実行することが可能となる

［第１の実施形態］
続いて、検証対象のネットワークが非特許文献１、２のＯｐｅｎＦｌｏｗにより制御されるネットワークであることを前提とした本発明の第１の実施形態について図面を参照して詳細に説明する。

［構成の説明］
図２は、本発明の第１の実施形態のネットワーク検証装置の構成を示す図である。図２を参照すると、入力装置から検証情報を受け付けてモデル検査実行部１２に送る検証情報入力部１１と、探索要否確認部１３と相互に情報をやり取りしてモデル検査を実行し、そのモデル検査の結果を、検証結果出力部１４に送るモデル検査実行部１２と、記憶装置に記憶された内容を参照して状態の探索要否を判断する探索要否確認部１３と、出力装置に検証結果を出力する検証結果出力部１４と、を含んだネットワーク検証装置１が示されている。

検証情報入力部１１は、ネットワークを構成する全ての端末・スイッチ・コントローラの接続関係と、前記端末・コントローラの各動作モデルと、前記ネットワークが満たすべきプロパティと、を定義した検証情報Ｄ１１（図８参照）を入力として受け付け、モデル検査実行部１２に受け渡す。

図３は、検証情報入力部１１が受け付ける端末、スイッチ及びコントローラの接続関係を表したトポロジ情報の一例である。例えば、一行目のエントリは、スイッチ１（ｓｗｉｔｃｈ１）と、ホスト１（ｈｏｓｔ１）とが接続されていることを示している。図３のトポロジ情報は、同一のコントローラ（ｃｏｎｔｒｏｌｌｅｒ１）に接続されている２つのスイッチが互いに接続され、かつ、それぞれホスト（ｈｏｓｔ１、ｈｏｓｔ２）に接続されているという構成を表している。なお、前記接続関係の記述形式は、上記図３に示す形式に限られるものではない。

続いて、「動作モデル」について説明する。本発明の第１の実施形態では、前記ネットワークは非特許文献２のＯｐｅｎＦｌｏｗにより制御されるものであり、前記スイッチ・コントローラはＯｐｅｎＦｌｏｗの仕様に則っていることを前提とする。

そのため、前記スイッチの動作仕様は図４に示すとおりとなる。即ち、スイッチは、通信パケットの受信を待ち（ステップＳＳ１）、スイッチ自身にインストール済みのフローエントリの中から、受信した通信パケットに適用可能なマッチング条件を持つエントリを探す（ステップＳＳ２）。ここで、適用可能なフローエントリがあればそのアクションフィールドの内容を実行し（ステップＳＳ３）、適用可能なフローエントリがなければ前記通信パケットをコントローラに転送すると共に処理内容を問い合わせる（ステップＳＳ４）。コントローラに処理内容を問い合わせた場合、コントローラの応答を待ち（ステップＳＳ５）、応答内容に応じて処理を実行する（ステップＳＳ６）。以上を繰り返す、というものとし、それを前提に全体の処理が実行される。

検証入力部に入力される前記コントローラの動作モデルはＯｐｅｎＦｌｏｗの仕様に則っているものとし、ＯｐｅｎＦｌｏｗメッセージを受信した場合にどのような動作を実行するかをイベントハンドラとして定義するものであるとする。例えば、Ｐａｃｋｅｔ−Ｉｎメッセージ（スイッチからの問い合わせ）の受信をイベントとする動作（ハンドラ）の定義を含むものである（例えば、図５参照）。ＯｐｅｎＦｌｏｗメッセージの種類に応じてそれぞれ個別に動作モデルを定義することとするが、全種類に対して前記動作モデルを用意する必要はなく、あるＯｐｅｎＦｌｏｗメッセージに対応する動作モデルが定義されていない場合には、ＯｐｅｎＦｌｏｗ仕様で規定されているデフォルトの動作を定義した動作モデルが与えられたものとして処理する。

前記端末の動作モデルは、どのような内容のパケットをどこに送信するか、を動作の単位とした動作シーケンスとして定義されているものとする。定義されるべきパケットの内容は、ＯｐｅｎＦｌｏｗのマッチングフィールドに指定可能なものであり、例えばパケットの宛先ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレス等である。パケットの内容の定義は部分的であってもよく、例えば宛先ＭＡＣアドレスのみ定義されていてもよい。前記端末の動作モデルの記述形式は、機械的に処理可能であればその形式は限定されないが、例えば図６に示すような形式で記述することが考えられる。図６の例では、端末の送信パケットの一部（ヘッダ）を定義している。例えば、図６の一行目のエントリは、送信元ＩＰアドレスを１９２．１６８．１．２とし、宛先ＩＰアドレスを１９２．１６８．１．３とし、ＴＣＰの宛先ポート番号を８０８０とするパケットを、ポート１から送信する動作を示している。

前記動作モデルは、ネットワークに含まれる個々の端末及びコントローラについてそれぞれ個別に定義される。ただし、同一の動作を行うもの同士については、同一の動作モデルを参照することで個別の定義を省略してもよい。動作モデルの記述形式は、機械的に処理可能であればその形式は限定されない。例えば状態遷移図や特定のプログラミング言語等で書かれていてもよい。また、ここではＯｐｅｎＦｌｏｗ １．０．０に則っているものとして説明するが、ネットワーク検証装置が適切に対応できるのであれば、その他のバージョンのＯｐｅｎＦｌｏｗ仕様に則っていても問題ない。

また、検証情報Ｄ１１において、前記プロパティは必ずしも定義されていなくてよい。前記プロパティが定義されていない場合、典型的なプロパティを検証することとし、以降はネットワーク検証装置全体が、検証情報Ｄ１１に前記典型的なプロパティが定義されているかのように動作する。

モデル検査実行部１２は、検証情報入力部１１から受け渡された検証情報Ｄ１１を用いてモデル検査を実行し、前記プロパティの成否と、前記プロパティが満たされない場合にはそれを示す反例と、を含む検証結果Ｄ１２を出力し、検証結果出力部１４に受け渡す。また、モデル検査実行部１２は、各状態の探索の要否の判断に必要な制約情報Ｄ１３を保持し、状態探索の際、探索対象の状態の制約情報Ｄ１３を探索要否確認部１３に受け渡し、探索が必要か否かの確認を依頼する。

探索要否確認部１３は、制約充足問題生成部１３１と、制約充足問題解決部１３２と、を含む。

制約充足問題生成部１３１は、モデル検査実行部１２から受け渡された制約情報Ｄ１３から、探索対象の状態が過去に通った探索経路が実際に起こり得るか否かを判定するための制約充足問題Ｄ１４を生成する。

制約充足問題解決部１３２は、制約充足問題Ｄ１４を解き、解を求める。解が求まった場合、前記遷移経路は実際に起こり得るため、モデル検査実行部１２に対し、「探索が必要」という回答を返す。一方、解が求まらない場合、前記遷移経路は実際には起こり得ないため、制約充足問題解決部１３２は、モデル検査実行部１２に対し、「探索は不要」という回答を返す。

ここで、「制約充足問題」について説明する。制約充足問題Ｄ１４は、制約充足問題解決部１３２の入力形式で記述される。例えば、制約充足問題解決部１３２がＳＭＴ（Ｓａｔｉｓｆｉａｂｉｌｉｔｙ Ｍｏｄｕｌｏ Ｔｈｅｏｒｉｅｓ）ソルバのＹｉｃｅｓ（Ｖｅｒ． １．０．３７）を用いる場合、制約充足問題は、図７に示すように記述される。

また、制約情報Ｄ１３は、それそのものが制約充足問題Ｄ１４であってもよい。例えば、モデル検査実行部１２が状態探索時に、状態に保持させる制約情報Ｄ１３を制約充足問題解決部１３２の入力言語の形式で保持させ、そのような制約情報Ｄ１３が探索要否確認部に受け渡される構成になっていてもよい。その場合、制約充足問題生成部１３１は不要となるため探索要否確認部１３から除外し、モデル検査実行部１２が探索要否確認部１３に問い合わせる際、直接制約充足問題解決部１３２に制約情報Ｄ１３（＝制約充足問題Ｄ１４）を渡すようにすればよい。

検証結果出力部１４は、モデル検査実行部１２の出力である検証結果Ｄ１２をディスプレイ等に適切な形で出力する。

なお、図２に示したネットワーク検証装置１の各部（処理手段）は、ネットワーク検証装置を構成するコンピュータに、そのハードウェアを用いて、上記した各処理を実行させるコンピュータプログラムにより実現することができる。

［動作の説明］
続いて、本発明の第１の実施形態の動作について詳細に説明する。図８は、本発明の第１の実施形態のネットワーク検証装置の動作を示す図である。図８を参照すると、ユーザは、検証情報Ｄ１１を作成し、検証情報入力部１１に入力する（ステップＳ１１）。

モデル検査実行部１２は、検証情報入力部１１に入力された検証情報Ｄ１１を用いてモデル検査を実行し、プロパティの成否と、前記プロパティが満たされない場合にはそれを示す反例と、を含む検証結果Ｄ１２を生成し、検証結果出力部１４に受け渡す（ステップＳ１２）。前記モデル検査において、モデル検査実行部１２は、パケットの具体的な内容を保持せず、その内容に依存しない形で状態遷移を行う。ただし、モデル検査実行部１２は、その遷移の際に満たされるべき制約を制約情報Ｄ１３として遷移先の状態に保持させる。状態は、その状態に至るまでの過去のすべての遷移（遷移経路）についてその制約情報を保持する。

前記状態探索を行う際、探索が必要か否か（遷移経路が実際に起こり得るか否か）を判断するため、モデル検査実行部１２は、探索要否確認部１３に対し、状態が持つ制約情報Ｄ１３を送り、探索の要否を問い合わせる（ステップＳ１３）。探索要否確認部１３から「探索が必要」という回答が返ってきた場合、モデル検査実行部１２は、次状態の探索を行い、「探索は不要」という回答が返ってきた場合、次状態の探索を省略する。

ここで、ネットワーク検証装置１の上記モデル検査の基本動作について、図９に示すサンプルコード及びこのサンプルコードと等価の図１０のフローチャートを参照しながら説明する。

図９（図１０）を参照すると、まず、モデル検査実行部１２は、検証対象の状態遷移モデルの初期状態を生成し（ステップＳ１２１）、探索状態の集合とする（ステップＳ１２２）。

次に、モデル検査実行部１２は、探索候補状態の集合から状態を１つ選んで取り出す（ステップＳ１２３）。モデル検査実行部１２は、その状態が探索済みであるか否かを確認し、探索済みであればステップＳ１２３に戻る（ステップＳ１２４）。

一方、抽出した状態が探索済みでなければ、モデル検査実行部１２は、探索要否確認部１３に対し、前記状態を探索すべきか否かを問い合わせ、探索すべきでなければステップＳ１２３に戻る（ステップＳ１３１）。一方、探索要否確認部１３から探索すべきとの回答が得られた場合、モデル検査実行部１２は、前記状態がプロパティを満たすか否かを確認し、満たしていなければ反例付きの検証結果Ｄ１２を生成してモデル検査を終了する（ステップＳ１２５）。

一方、前記状態がプロパティを満たしている場合、モデル検査実行部１２は、前記状態から遷移可能な次状態を計算し（ステップＳ１２６−１）、計算の結果得られたすべての状態を探索状態の集合に追加する（ステップＳ１２７）。

モデル検査実行部１２は、前記探索状態の集合が空になるまで、ステップＳ１２３からＳ１２７（ステップＳ１３１を含む）を繰り返す。

図１１は、一般的なモデル検査の基本動作を表したサンプルコードである。図９と図１１を比較すると分かるように、一般的なモデル検査には状態を探索すべきか否かを確認するステップＳ１３１に相当する手順が存在しない。

本実施形態のネットワーク検証装置１のモデル検査においては、パケットの内容を具体的に扱わないため、実際には起こり得ない遷移経路を通った（探索が不要な）状態を生成してしまう場合があるが、探索要否確認部１３への問い合わせ（ステップＳ１３１）を行うことで探索が不要な状態を探索することなくモデル検査を行うことができる（一般的なモデル検査との相違点の１）。

また、本実施形態のネットワーク検証装置１のモデル検査においては、パケットの内容を具体的に扱わずにＯｐｅｎＦｌｏｗネットワークのモデル検査を行うため、状態から遷移可能な次状態を計算するステップＳ１２６−１の内容も一般的なモデル検査のアルゴリズムとは異なる（一般的なモデル検査との相違点の２）。以下、ステップＳ１２６−１の詳細な動作について説明する。

ネットワーク検証装置１のモデル検査における「状態」の定義について説明する。状態は、（Ｔ，Ｓ，Ｃ，Ｒ，Ｐ，Ｍ，Ｑ）の七つの要素の組として定義される。Ｔは端末の集合であり、Ｔの要素ｔ（ｔ∈Ｔ）は、端末ｔの動作モデルとして定義されている動作シーケンス中のどの動作を次に行うかを表す変数ｓｖを持つ。Ｓはスイッチの集合であり、Ｓの要素ｓ（ｓ∈Ｓ）はスイッチにインストールされているフローエントリの集合を表す変数Ｅを持つ。Ｅの要素ｅ（ｅ∈Ｅ）はフローエントリであり、マッチングルール（マッチ条件）の内容を表す値ｍｒとアクションフィールドの内容を表す値ａｆにより（ｍｒ， ａｆ）の組として定義される。Ｃはコントローラの集合であり、Ｃの要素ｃ（ｃ∈Ｃ）は、コントローラｃの各動作モデルが大域的に扱う変数の集合を表す変数Ｖと、コントローラｃの動作モデル（イベントハンドラ）に関する情報の集合を表す変数Ｈを持つ。Ｖの要素ｖ（ｖ∈Ｖ）は、コントローラの動作モデルが大域的に扱う変数の１つであり、変数の名前を表す値ｖｎとその変数の値を表す値ｖｖにより（ｖｎ，ｖｖ）の組として定義される。Ｈの要素ｈ（ｈ∈Ｈ）は、イベントハンドラの名前を表す値ｈｎとそのイベントハンドラの実行回数を表す値ｈｃにより（ｈｎ，ｈｃ）の組として定義される。Ｒは制約情報の集合であり、Ｒの要素ｒ（ｒ∈Ｒ）は、個々の制約情報を表す。Ｐはパケットの集合であり、Ｐの要素ｐ（ｐ∈Ｐ）は、パケットのＩＤを表す変数ｉｄを持つ。ＭはＯｐｅｎＦｌｏｗメッセージの集合であり、Ｍの要素ｍ（ｍ∈Ｍ）は、ＯｐｅｎＦｌｏｗメッセージの内容を表す変数ｍｖを持つ。Ｑは通信ポートの集合であり、Ｑの要素ｑ（ｑ∈Ｑ）は、パケット及びＯｐｅｎＦｌｏｗメッセージを格納するＦＩＦＯ（Ｆｉｒｓｔ Ｉｎ， Ｆｉｒｓｔ Ｏｕｔ）キューにより実現される通信ポートである。以上がネットワーク検証装置１のモデル検査における状態の定義である。このうち、ｃ（ｃ∈Ｃ）が持つ変数Ｈと、ｐ（ｐ∈Ｐ）が持つ変数ｉｄ以外は、検証対象であるＯｐｅｎＦｌｏｗネットワークの様子を表すためのものである。一方、前記変数Ｈと変数ｉｄはネットワーク検証装置１によるモデル検査を実行するために補助的に用意した情報である。これらについては、実際にこれらを使用した状態遷移の例の説明で詳しく述べる。

次に、ネットワーク検証装置１のモデル検査における「状態遷移」の定義について説明する。ネットワーク検証装置１のモデル検査における状態遷移は、検証対象のＯｐｅｎＦｌｏｗネットワーク内に存在する端末、スイッチ及びコントローラのいずれかが、特定の単位の動作を実行することでネットワークの状態が変化する様子を表すものとする。特定の単位の動作とは、具体的には以下の６種類である。
１． 端末のパケット送信
２． 端末のパケット受信
３． スイッチのフローエントリ適用
４． スイッチのＰａｃｋｅｔ−Ｉｎメッセージ送信
５． スイッチのＯｐｅｎＦｌｏｗメッセージ受信
６． コントローラのプログラム実行

前記１〜６の動作のいずれかを実行することで、モデル検査実行部１２は、ある状態から遷移可能な状態を計算し（ステップＳ１２６−１）、探索状態の集合に追加する（ステップＳ１２７）。ある状態において複数の状態遷移が可能な場合、モデル検査実行部１２は、そのいずれかを実行した結果の状態をそれぞれ計算し（ステップＳ１２６−１）、それらすべてを探索状態の集合に追加する（ステップＳ１２７）。以下、前記６種類の動作についてそれぞれ詳しく説明する。

（１）端末のパケット送信による状態遷移について説明する。モデル検査実行部１２のモデル検査において、端末は、検証情報Ｄ１１に含まれる前記端末自身の動作モデルの実行がすべて完了していない場合、前記動作モデルにおいて定義されているパケット送信動作のうち、前記端末が持つ変数ｓｖにより表されるパケット送信動作を実行することが可能である。端末のパケット送信による状態遷移では、モデル検査実行部１２は、まず端末ｔ（ｔ∈Ｔ）が送信するパケットｐを生成してパケットの集合Ｐに追加し、パケットｐにＩＤを割り振る（ｐの変数ｉｄに特定の値を代入する）。このとき、割り振るＩＤとして、モデル検査実行部１２は、パケットの集合Ｐを参照し、既存のパケットと重複しない（パケットを一意に特定できる）ＩＤを割り振る。なお、パケットＩＤは、パケットを一意に特定できれば、どのような方法で割り振ってもよい。例えば、最初に割り振るＩＤを整数値の１とし、次に２、３、・・・と割り振る値を１ずつ増加させていく方法でＩＤを割り振る方法が考えられる（以降はそのようにＩＤを割り振るものとして説明する）。

次に、モデル検査実行部１２は、前記動作モデルにおいて定義されている、送信するパケットの内容を参照し、パケットｐがその内容を満たすことを表す制約情報ｒを生成して制約情報の集合Ｒに追加する。図１２は、図６の１行目のパケット送信動作を実行する際、送信されるパケットのＩＤが１である場合に追加される制約情報を示す。前記パケットのＩＤは、制約情報がどのパケットの内容を限定するものなのかを特定するために割り振っており、図１２に示すように、制約情報内で用いられる変数名に前記パケットのＩＤを付与（図１２の「ｐｉｄ１＿」の部分が該当）することで、制約情報がどのパケットの内容を限定するものか特定できるようにしている。ただし、制約情報の保持形式は、機械的に処理可能であり制約充足問題解決部に入力する制約充足問題Ｄ１４を生成するのに充分な情報を含んでいれば、図１２に示すものに限定されず、他の形式でもよい。最後に、モデル検査実行部１２は、パケットｐを送信先に対応する通信ポートｑ（ｑ∈Ｑ）に格納する。前記送信先に対応する通信ポートｑは、検証情報Ｄ１１に含まれる、ネットワークを構成する端末、スイッチ及びコントローラの接続関係から導出する。以降の通信ポートへのパケットあるいはＯｐｅｎＦｌｏｗメッセージの格納処理においては、モデル検査実行部１２は、図３に示した接続関係に基づいて適切な通信ポートを導出するものとする。

以上の手順の結果得られる次状態を、端末のパケット送信による遷移先状態とする。特定の端末が特定の状態において実行可能なパケット送信動作はたかだか１つ（前記端末が持つ変数ｓｖにより表されるもののみ）なので、特定の端末のパケット送信動作により得られる遷移先状態はたかだか１つである。

（２）次に、端末のパケット受信による状態遷移について説明する。モデル検査実行部１２のモデル検査において、端末は、自身のパケット受信用通信ポートにパケットが１つ以上格納されている場合、パケット受信動作を実行することが可能である。端末のパケット送信による状態遷移では、パケットが１つ以上格納されている端末ｔ（ｔ∈Ｔ）のパケット受信用通信ポートｑ（ｑ∈Ｑ）から、ｑに格納された時期が最も古いパケットｐ（ｐ∈Ｐ）を１つ取り出し、捨てる。その結果得られる状態を、端末のパケット受信による遷移先状態とする。特定の端末が特定の状態において実行可能なパケット受信動作の数は、たかだか前記端末のパケット受信用通信ポートの数だけなので（前記端末のすべてのパケット受信用通信ポートにパケットが格納されている場合）、特定の端末のパケット送信動作により得られる遷移先状態の数は、たかだか前記端末のパケット受信用通信ポートの数だけである。

（３）次に、スイッチのフローエントリ適用による状態遷移について説明する。モデル検査実行部１２のモデル検査において、スイッチは、自身のパケット受信用通信ポートにパケットが１つ以上格納されている場合、フローエントリ適用動作を実行することが可能である。スイッチのフローエントリ適用動作では、まずパケットが１つ以上格納されているスイッチｓ（ｓ∈Ｓ）のパケット受信用通信ポートｑ（ｑ∈Ｑ）から、ｑに格納された時期が最も古いパケットｐ（ｐ∈Ｐ）を１つ取り出す。次に、モデル検査実行部１２は、適用するフローエントリｅ（ｅ∈Ｅ）を１つ選ぶ。そして、取り出したパケットｐのｉｄと選んだフローエントリｅのマッチングルールｍｒの内容を参照し、取り出したパケットｐがマッチングルールｍｒの内容を満たすことを表す制約情報ｒを生成して制約情報Ｒに追加する。

例えば、スイッチｓが図１３上部に示すマッチングルールを持つフローエントリを有している場合、取り出したパケットｐのＩＤが１であり、図１３上部のマッチングルールＭａｔｃｈｉｎｇＲｕｌｅ１を定義しているフローエントリを適用するのであれば、モデル検査実行部１２は、図１３下部に示すような制約情報を生成して制約情報の集合Ｒに追加する。最後に、選んだフローエントリｅのアクションフィールドａｆに定義された動作を実行する。ここで、アクションフィールドａｆにパケットｐの内容変更動作（Ｍｏｄｉｆｙ−Ｆｉｅｌｄ）が定義されている場合、パケットｐに新しいＩＤを割り振り、その後でパケットｐが前記内容変更動作後の内容を満たすことを表す制約情報ｒを生成して制約情報の集合Ｒに追加する。これは、パケットの内容に変更が生じると以前の制約情報が無関係になり、変更前と変更後の制約情報で不整合が生じ得るため、異なるパケットとして扱うことで不整合の発生を防ぐための処理である。以上の手順の結果得られる状態を、スイッチのフローエントリ適用による遷移先状態とする。特定のスイッチが特定の状態において特定のパケットに対し実行可能なフローエントリ適用動作の数は、たかだか前記スイッチが持つフローエントリの数だけなので、特定のスイッチが特定の状態において実行可能なフローエントリ適用動作の数は、たかだか前記スイッチが持つフローエントリの数×前記スイッチのパケット受信用ポートの数だけである（前記スイッチのすべてのパケット受信用通信ポートにパケットが格納されている場合）。よって、特定のスイッチのフローエントリ適用動作により得られる遷移先状態の数は、たかだか前記スイッチが持つフローエントリの数×前記スイッチのパケット受信用ポートの数だけである。

（４）次に、スイッチのＰａｃｋｅｔ−Ｉｎメッセージ（ＯｐｅｎＦｌｏｗメッセージの１つ）送信による状態遷移について説明する。モデル検査実行部１２のモデル検査において、スイッチは、自身のパケット受信用通信ポートにパケットが１つ以上格納されている場合、Ｐａｃｋｅｔ−Ｉｎメッセージ送信動作を実行することが可能である。スイッチのＰａｃｋｅｔ−Ｉｎメッセージ送信動作では、まずパケットが１つ以上格納されているスイッチｓ（ｓ∈Ｓ）のパケット受信用通信ポートｑ（ｑ∈Ｑ）から、ｑに格納された時期が最も古いパケットｐ（ｐ∈Ｐ）を１つ取り出す。次に、パケットｐはスイッチｓが持つ全てのフローエントリｅ（ｅ∈Ｅ）のマッチングルールｍｒを満たさないことを表す制約情報ｒを生成して制約情報の集合Ｒに追加する。

例えば、スイッチｓが図１４上部に示すマッチングルールを持つフローエントリを保持し、取り出したパケットｐのＩＤが１であるならば、モデル検査実行部１２は、図１４下部に示すような制約情報を生成して制約情報の集合Ｒに追加する。最後に、モデル検査実行部１２は、パケットｐの情報を含めたＰａｃｋｅｔ−Ｉｎメッセージをコントローラに対応する通信ポートｑ（ｑ∈Ｑ）に格納する。その結果得られる状態を、スイッチのＰａｃｋｅｔ−Ｉｎメッセージ送信による遷移先状態とする。特定のスイッチが特定の状態において実行可能なＰａｃｋｅｔ−Ｉｎメッセージ送信動作の数は、たかだか前記スイッチのパケット受信用ポートの数だけなので（前記スイッチのすべてのパケット受信用通信ポートにパケットが格納されている場合）、特定のスイッチのＰａｃｋｅｔ−Ｉｎメッセージ送信動作により得られる遷移先状態の数は、たかだか前記スイッチのパケット受信用ポートの数だけである。

（５）次に、スイッチのＯｐｅｎＦｌｏｗメッセージ受信による状態遷移について説明する。モデル検査実行部１２のモデル検査において、スイッチは、自身のＯｐｅｎＦｌｏｗメッセージ受信用通信ポートにＯｐｅｎＦｌｏｗメッセージが１つ以上格納されている場合、ＯｐｅｎＦｌｏｗメッセージ受信動作を実行することが可能である。スイッチのＯｐｅｎＦｌｏｗメッセージ受信動作では、まずＯｐｅｎＦｌｏｗメッセージが１つ以上格納されているスイッチｓ（ｓ∈Ｓ）のＯｐｅｎＦｌｏｗメッセージ受信用通信ポートｑ（ｑ∈Ｑ）から、ｑに格納された時期が最も古いＯｐｅｎＦｌｏｗメッセージｍ（ｍ∈Ｍ）を１つ取り出す。次に、モデル検査実行部１２は、ＯｐｅｎＦｌｏｗメッセージｍの内容ｍｖを参照し、ＯｐｅｎＦｌｏｗの仕様に則ってｍｖに対応する動作を実行する。その結果得られる状態を、スイッチのＯｐｅｎＦｌｏｗメッセージ受信による遷移先状態とする。特定のスイッチが特定の状態において実行可能なＯｐｅｎＦｌｏｗメッセージ受信動作の数は、たかだか前記スイッチのＯｐｅｎＦｌｏｗメッセージ受信用ポートの数だけなので（前記スイッチのすべてのＯｐｅｎＦｌｏｗメッセージ受信用通信ポートにＯｐｅｎＦｌｏｗメッセージが格納されている場合）、特定のスイッチのＯｐｅｎＦｌｏｗメッセージ受信動作により得られる遷移先状態の数は、たかだか前記スイッチのＯｐｅｎＦｌｏｗメッセージ受信用ポートの数だけである。

（６）次に、コントローラのプログラム実行による状態遷移について説明する。モデル検査実行部１２のモデル検査において、コントローラは、自身のＯｐｅｎＦｌｏｗメッセージ受信用通信ポートにＯｐｅｎＦｌｏｗメッセージが１つ以上格納されている場合、プログラム実行動作を実行することが可能である。コントローラのプログラム実行動作では、まずＯｐｅｎＦｌｏｗメッセージが１つ以上格納されているコントローラｃ（ｃ∈Ｃ）のＯｐｅｎＦｌｏｗメッセージ受信用通信ポートｑ（ｑ∈Ｑ）から、ｑに格納された時期が最も古いＯｐｅｎＦｌｏｗメッセージｍ（ｍ∈Ｍ）を１つ取り出す。次に、ＯｐｅｎＦｌｏｗメッセージｍの内容ｍｖを参照し、検証情報Ｄ１１に含まれるコントローラｃの動作モデルにおいて定義されているイベントハンドラのうち、ｍｖに対応するものを実行する（定義されていない場合はＯｐｅｎＦｌｏｗ仕様で規定されているデフォルトの動作を実行する）。前記イベントハンドラの実行においては、イベントハンドラの動作ステップ（例えば状態遷移図における遷移アクションやプログラミング言語におけるステートメント等、最小の動作単位）毎に、前記動作ステップの内容を満たすことを表す制約情報を生成して制約情報の集合Ｒに追加する。ただし、前記動作ステップにおいて変数の参照及び代入が行われる場合、生成する制約情報においては、イベントハンドラのｈｎとｈｃとを参照して変数名にイベントハンドラの名前と実行回数とを付与し、かつ単一代入になるように変数名を置き換える。例えば、図１５上部に示す動作ステップ列に対して、前記動作ステップ列を含むイベントハンドラの名前がｐａｃｋｅｔＩｎでありその実行回数が３回（目）である場合、モデル検査実行部１２は、図１５下部に示すように変数名を置き換えた制約情報をそれぞれ生成して制約情報の集合Ｒに追加する。

なお、上記変数名の置き換えは、制約情報がどの変数の内容を利用あるいは限定するものなのかを特定するために行っている。図１５の例では、変数名で、制約情報がどの変数の内容を利用あるいは限定するものか特定できるようにしている。ただし、制約情報の保持形式は、機械的に処理可能であり制約充足問題解決部に入力する制約充足問題Ｄ１４を生成するのに充分な情報を含んでいればよく、図１５に示すものに限定されない。以上の手順の結果得られる状態を、コントローラのプログラム実行による遷移先状態とする。ただし、ＯｐｅｎＦｌｏｗメッセージｍの内容ｍｖが特定のパケットの内容を参照するもの（Ｐａｃｋｅｔ−Ｉｎメッセージ等）である場合、前記イベントハンドラを単純に実行するのではなく、参照するパケットｐの内容は不特定のものとして扱いイベントハンドラの記号実行を行い、その結果得られる状態すべてを、コントローラのプログラム実行による遷移先状態とする。つまり、パケットｐの内容に応じてイベントハンドラの実行結果が変わる場合、それらの結果すべてを遷移先状態として導出するということである。例えば図１６に示すように、パケットの内容（図１６では宛先ＴＣＰポート番号）に応じて分岐先が変わる（結果としてイベントハンドラの実行結果も変わる）場合、それぞれの分岐先（図１６ではｉｆ文のｔｈｅｎ節とｅｌｓｅ節）に分岐して個別にイベントハンドラの実行を進め、実行が完了した結果から得られる状態をすべて遷移先状態として導出する。一般に、パケットの内容に依存するイベントハンドラの分岐は１箇所とは限らないため、そのような分岐が複数存在する場合、その全ての分岐を網羅する形でイベントハンドラの実行を行い（つまり記号実行を行い）遷移先状態を導出する。また、特定のパケットの内容を参照するイベントハンドラの記号実行における動作ステップにおいてパケットｐの内容を変更する場合、スイッチにおけるパケットの内容変更動作と同様に、パケットｐに新しいＩＤを割り振り、その後でパケットｐが前記内容変更動作後の内容を満たすことを表す制約情報ｒを生成して制約情報の集合Ｒに追加する。以上の手順の結果得られる状態すべてを、コントローラのプログラム実行による遷移先状態とする。

モデル検査実行部１２のモデル検査において、ある状態から遷移可能な状態（遷移先状態）を計算する動作（図９（図１０）のステップＳ１２６−１）は、以上の６種類の状態遷移を、ネットワークを構成する端末、スイッチ及びコントローラのそれぞれについて計算することで実現される。

再度、図８を参照すると、探索要否確認部１３は、まず制約充足問題生成部１３１が、モデル検査実行部１２からの問い合わせを受け付け、その際に受け渡された制約情報Ｄ１３から制約充足問題Ｄ１４を生成する（図８のステップＳ１４）。次に制約充足問題解決部１３２が、制約充足問題Ｄ１４を解くことでその解の有無Ｄ１５を求める（図８のステップＳ１５）。制約充足問題解決部１３２は、モデル検査実行部１２に対し、解の有無Ｄ１５に応じて探索の要否Ｄ１６を受け渡す（図８のステップＳ１６）。

より具体的には、制約充足問題生成部１３１は、制約情報Ｄ１３を制約充足問題解決部１３２の入力形式に変換することで、制約充足問題Ｄ１４を生成する。例えば、図１２に示す制約情報Ｄ１３を、図７に示す制約充足問題Ｄ１４（ＳＭＴソルバＹｉｃｅｓのＶｅｒ． １．０．３７の入力形式）に変換する処理が行われる。図１２及び図７を対比すれば明らかなとおり、制約情報Ｄ１３を予め制約充足問題Ｄ１４の形式と類似の形式で保持しておけば、その変換は容易である。例えば、図１２及び図７に示す例では、制約情報Ｄ１３に予約語ｄｅｆｉｎｅによる変数の宣言部分（図７の上３行）を追加し、予約語ａｓｓｅｒｔを用いて制約情報を制約式として宣言するだけで（図７の下３行）変換可能である。制約充足問題解決部１３２は、制約充足問題Ｄ１４を解き、その解の有無Ｄ１５を求める。解が存在する場合、制約充足問題解決部１３２は、モデル検査実行部１２に対し、探索の要否Ｄ１６として「探索が必要」という回答を返し、解が存在しない場合、探索の要否Ｄ１６として「探索は不要」という回答を返す。モデル検査実行部１２は、探索の要否Ｄ１６として、「探索が必要」という回答が返ってくれば次状態の探索（図９（図１０）のステップＳ１２５以降）を行い、「探索は不要」という回答が返ってくれば状態の探索を行わず、図９（図１０）のステップＳ１２３に戻る。

検証結果出力部１４は、モデル検査実行部１２の出力である、プロパティの成否と、プロパティが満たされない場合にはそれを示す反例と、を含む検証結果Ｄ１２を出力する（ステップＳ１７）。

ユーザは、ステップＳ１７で出力された結果を確認する（ステップＳ１８）。

以上説明したように、本実施形態によれば、ＯｐｅｎＦｌｏｗネットワークの網羅的な検証が効率的に実施可能になり、不具合を漏れなく検出することができる。その理由は、検証対象であるＯｐｅｎＦｌｏｗネットワークのモデル検査を行う際、ネットワーク検証装置１が、ＯｐｅｎＦｌｏｗネットワークを往来するパケットの具体的な内容を保持せず、その内容に依存しない形で状態遷移を行うようにしたためである。これにより、ＯｐｅｎＦｌｏｗネットワーク内の端末が送信するパケットの内容の違いを考慮する必要がなく、効率的なモデル検査が実施可能である。また、パケットの内容を具体的に扱わないことで、実際には起こり得ない遷移経路を通った（探索が不要な）状態を生成してしまう場合があるが、これは前記状態遷移の際に、前記状態遷移が実際に起こり得るか否かの判断に必要な制約情報を状態に保持させ、探索要否確認部１３で前記制約情報を用いて状態の過去の遷移経路が実際に起こり得るか否かを確認し、実際に起こり得る遷移経路を通った（探索が必要な）状態のみ探索する。これにより、次状態の探索が不要な状態を省略してモデル検査が実施することが可能となっている。

続いて、ＯｐｅｎＦｌｏｗネットワーク以外のネットワークの検証動作を行う本発明の第２の実施形態について図面を参照して詳細に説明する。以下、前記第１の実施形態と同様の部分は省略し、異なる部分についてのみ説明する。

［構成の説明］
再度、図２を参照して、本発明の第２の実施形態の構成について詳細に説明する。本発明の第２の実施形態の検証情報入力部１１は、ネットワークを構成する端末及びネットワーク機器の接続関係と、前記端末の動作モデルと、前記ネットワークが満たすべきプロパティと、を定義した検証情報Ｄ１１を入力として受け付ける。端末の動作モデルは、第１の実施形態におけるものと同様のものを用いることができる。図１７は、本発明の第２の実施形態において想定するネットワーク機器の動作モデルの一例である。図１７の例では、ネットワーク機器は、通信パケットＰの受信を待ち（ステップＳＮ１）、パケットを受信すると、自装置に設定・実装済みのエントリの中から、受信パケットＰの宛先等に適合するエントリを探し（ステップＳＮ２）、受信パケットの宛先等に適合するエントリがあれば、そのエントリに定められた処理内容を実行する（ステップＳＮ３）。一方、受信パケットＰの宛先等に適合するエントリがない場合、ネットワーク機器は、デフォルトの動作として設定・実装されている処理を実行する（ステップＳＮ４）。ネットワーク機器は、以上を繰り返す、という動作を包含する。また、本実施形態においても、検証情報Ｄ１１に、前記プロパティは必ずしも定義されていなくてよい。前記プロパティが定義されていない場合、典型的なプロパティを検証することとし、以降はネットワーク検証装置全体が、検証情報Ｄ１１に前記典型的なプロパティが定義されているかのように動作する。

［動作の説明］
次に、本発明の第２の実施形態の動作について詳細に説明する。本発明の第２の実施形態の動作において、本発明の第１の実施形態の動作と異なる点は、モデル検査実行部１２におけるモデル検査の状態及び遷移の定義のみである。その他の部位の動作及びモデル検査実行部１２におけるモデル検査の基本動作（図９（図１０）に相当する部分）は第１の実施形態と同様であるので省略する。

はじめに、ネットワーク検証装置１のモデル検査における「状態」の定義について説明する。本実施形態における「状態」は、（Ｔ，Ｎ，Ｒ，Ｐ，Ｑ）の五つの要素の組として定義される。Ｔは端末の集合であり、Ｔの要素ｔ（ｔ∈Ｔ）は、端末ｔの動作モデルとして定義されている動作シーケンス中のどの動作を次に行うかを表す変数ｓｖを持つ。

Ｎはネットワーク機器の集合であり、Ｎの要素ｎ（ｎ∈Ｎ）は、ネットワーク機器に設定・実装されている処理エントリの集合を表す変数Ｅを持つ。Ｅの要素ｅ（ｅ∈Ｅ）は、パケット処理エントリであり、適用条件を表す値ｍｒと適用処理の内容を表す値ａｆにより（ｍｒ， ａｆ）の組として定義される。

Ｒは制約情報の集合であり、Ｒの要素ｒ（ｒ∈Ｒ）は、個々の制約情報を表す。

Ｐはパケットの集合であり、Ｐの要素ｐ（ｐ∈Ｐ）は、パケットのＩＤを表す変数ｉｄを持つ。

Ｑは通信ポートの集合であり、Ｑの要素ｑ（ｑ∈Ｑ）は、パケットを格納するＦＩＦＯ（Ｆｉｒｓｔ Ｉｎ， Ｆｉｒｓｔ Ｏｕｔ）キューにより実現される通信ポートである。以上がネットワーク検証装置２のモデル検査における状態の定義である。このうち、ｐ（ｐ∈Ｐ）が持つｉｄ以外は検証対象であるネットワークの様子を表すためのものである。一方、前記ｉｄはネットワーク検証装置１によるモデル検査を実行するために補助的に用意した情報である。これらの違いについては、実際にこれらを使用した状態遷移の例の説明で詳しく述べる。

続いて、本実施形態のネットワーク検証装置１のモデル検査における状態遷移の定義について説明する。ネットワーク検証装置１のモデル検査における状態遷移は、検証対象のネットワーク内に存在する端末及びネットワーク機器のいずれかが、特定の単位の動作を実行することでネットワークの状態が変化する様子を表すものとする。特定の単位の動作とは、具体的には以下の４種類である。
１． 端末のパケット送信
２． 端末のパケット受信
３． ネットワーク機器のデフォルトでない処理エントリ適用
４． ネットワーク機器のデフォルトの処理エントリ適用

前記動作のいずれかを実行することで、ある状態から遷移可能な状態を計算し（図９（図１０）のステップＳ１２６−１）、探索状態の集合に追加する（図９（図１０）のステップＳ１２７）。ある状態において複数の状態遷移が可能な場合は、そのいずれかを実行した結果の状態をそれぞれ計算し（ステップＳ１２６−１）、それらすべてを探索状態の集合に追加する（ステップＳ１２７）。以上の４種類の動作のうち、端末のパケット送信と端末のパケット受信は第１の実施形態で述べたものと同様なので、以下では残り２種類の動作についてそれぞれ詳しく説明する。

はじめに、ネットワーク機器のデフォルトでない処理エントリ適用による状態遷移について説明する。モデル検査実行部１２のモデル検査において、ネットワーク機器は、自身のパケット受信用通信ポートにパケットが１つ以上格納されている場合、デフォルトでない処理エントリ適用動作を実行することが可能である。ネットワーク機器のデフォルトでない処理エントリ適用動作では、モデル検査実行部１２は、まずパケットが１つ以上格納されているネットワーク機器ｎ（ｎ∈Ｎ）のパケット受信用通信ポートｑ（ｑ∈Ｑ）から、ｑに格納された時期が最も古いパケットｐ（ｐ∈Ｐ）を１つ取り出す。次に、モデル検査実行部１２は、前記パケットｐに適用する処理エントリｅ（ｅ∈Ｅ）を１つ選ぶ。そして、モデル検査実行部１２は、取り出したパケットｐのｉｄと選んだ処理エントリｅの適用条件ｍｒの内容を参照し、取り出したパケットｐが適用条件ｍｒの内容を満たすことを表す制約情報ｒを生成して制約情報Ｒに追加する。最後に、モデル検査実行部１２は、選んだ処理エントリｅの適用処理ａｆに定義された動作を実行する。ここで、適用処理ａｆにパケットｐの内容変更動作が定義されている場合、パケットｐに新しいＩＤを割り振り、その後でパケットｐが前記内容変更動作後の内容を満たすことを表す制約情報ｒを生成して制約情報の集合Ｒに追加する。以上の手順の結果得られる状態を、ネットワーク機器のデフォルトでない処理エントリ適用による遷移先状態とする。特定のネットワーク機器が特定の状態において特定のパケットに対し実行可能なデフォルトでない処理エントリ適用動作の数は、たかだか前記ネットワーク機器が持つデフォルトでない処理エントリの数だけなので、特定のネットワーク機器が特定の状態において実行可能なデフォルトでない処理エントリ適用動作の数は、たかだか前記ネットワーク機器が持つデフォルトでない処理エントリの数×前記ネットワーク機器のパケット受信用ポートの数だけである（前記ネットワーク機器のすべてのパケット受信用通信ポートにパケットが格納されている場合）。よって、特定のネットワーク機器のデフォルトでない処理エントリ適用動作により得られる遷移先状態の数は、たかだか前記ネットワーク機器が持つデフォルトでない処理エントリの数×前記ネットワーク機器のパケット受信用ポートの数だけである。

次に、ネットワーク機器のデフォルトの処理エントリ適用による状態遷移について説明する。モデル検査実行部１２のモデル検査において、ネットワーク機器は、自身のパケット受信用通信ポートにパケットが１つ以上格納されている場合、デフォルトの処理エントリ適用動作を実行することが可能である。ネットワーク機器のデフォルトの処理エントリ適用動作では、モデル検査実行部１２は、まずパケットが１つ以上格納されているネットワーク機器ｎ（ｎ∈Ｎ）のパケット受信用通信ポートｑ（ｑ∈Ｑ）から、ｑに格納された時期が最も古いパケットｐ（ｐ∈Ｐ）を１つ取り出す。次に、モデル検査実行部１２は、パケットｐが、ネットワーク機器ｎが持つすべての処理エントリｅ（ｅ∈Ｅ）の適用条件ｍｒを満たさないことを表す制約情報ｒを生成して制約情報の集合Ｒに追加する。最後に、モデル検査実行部１２は、デフォルトの処理エントリｅの適用処理ａｆに定義された動作を実行する。ここで、適用処理ａｆにパケットｐの内容変更動作が定義されている場合、モデル検査実行部１２は、パケットｐに新しいＩＤを割り振り、その後でパケットｐが前記内容変更動作後の内容を満たすことを表す制約情報ｒを生成して制約情報の集合Ｒに追加する。以上の手順の結果得られる状態を、ネットワーク機器のデフォルトの処理エントリ適用による遷移先状態とする。特定のネットワーク機器が特定の状態において実行可能なデフォルトの処理エントリ適用動作の数は、たかだか前記ネットワーク機器のパケット受信用ポートの数だけなので（前記ネットワーク機器のすべてのパケット受信用通信ポートにパケットが格納されている場合）、特定のネットワーク機器のデフォルトの処理エントリ適用動作により得られる遷移先状態の数は、たかだか前記ネットワーク機器のパケット受信用ポートの数だけである。

本発明の第２の実施形態におけるモデル検査実行部１２のモデル検査において、ある状態から遷移可能な状態（遷移先状態）を計算する動作（図９（図１０）のステップＳ１２６−１）は、以上の４種類の状態遷移を、ネットワークを構成する端末及びネットワーク機器のそれぞれについて計算することで実現される。

以上説明したように、本実施形態によれば、ＯｐｅｎＦｌｏｗネットワーク以外のネットワークについても、効率的に網羅的な検証を実施し、不具合を漏れなく検出することができる。その理由は、本実施形態においても、ネットワークを往来するパケットの具体的な内容を保持せず、その内容に依存しない形で状態遷移を行うようにしたことと、探索が不要な状態を探索することなくモデル検査を実施するようにしたことにある。

［第３の実施形態］
続いて、上記第１、第２の実施形態のユーザインタフェースに改良を加えた本発明の第３の実施形態について図面を参照して詳細に説明する。以下、前記第１の実施形態と同様の部分は省略し、異なる部分についてのみ説明する。

［構成の説明］
図１８は、本発明の第３の実施形態のネットワーク検証装置の構成を示す図である。本実施形態の検証情報入力部３１は、検証情報受付部３１１と、検証情報雛形提供部３１２と、を含む。検証情報受付部３１１は、ネットワークを構成する端末、スイッチ及びコントローラの接続関係と、前記端末及びコントローラの各動作モデルと、前記ネットワークが満たすべきプロパティと、を定義した検証情報Ｄ１１を入力として受け付ける。

検証情報雛形提供部３１２は、ユーザから検証情報の入力を受け付ける際、検証情報Ｄ１１の一部あるいは全部について典型的な雛形（テンプレート）を提供し、ユーザが前記雛形を選択することで、それを検証情報Ｄ１１の一部あるいは全部として利用し、検証情報受付部３１１に入力することが可能な機能を備える。

［動作の説明］
ユーザは、図８のステップＳ１１において、検証情報Ｄ１１を作成する際、検証情報雛形提供部３１２から所望の雛形をいくつか選択し、それらを用いて検証情報Ｄ１１を完成させ、検証情報受付部３１１に入力する。もちろん、第１の実施形態と同様に、ユーザが雛形を全く用いずに検証情報Ｄ１１を作成して入力してもよい。その他の動作は、本発明の第１の実施形態と同様のため省略する。

以上のように、本実施形態によれば、ネットワーク検証装置を利用する際の、ユーザの検証情報Ｄ１１の作成に要する負担を軽減することができる。さらに、本実施形態によれば、前記ユーザの負担軽減の結果として、検証全体の効率を向上させることもできる。もちろん、本実施形態の構成は、ＯｐｅｎＦｌｏｗネットワーク以外のネットワークを検証する第２の実施形態の構成にも適用できる。

以上、本発明の各実施形態を説明したが、本発明は、上記した実施形態に限定されるものではなく、本発明の基本的技術的思想を逸脱しない範囲で、更なる変形・置換・調整を加えることができる。例えば、各図面に示した装置の構成は、本発明の理解を助けるための一例であり、これらの図面に示した構成に限定されるものではない。

最後に、本発明の好ましい形態を要約する。
［第１の形態］
（上記第１の視点によるネットワーク検証装置参照）
［第２の形態］
第１の形態のネットワーク検証装置において、
前記検証情報には、端末、ＯｐｅｎＦｌｏｗスイッチ及びＯｐｅｎＦｌｏｗコントローラを含むネットワークの構成情報と、前記端末及び前記ＯｐｅｎＦｌｏｗコントローラの動作モデルが定義されているネットワーク検証装置。
［第３の形態］
第１又は第２の形態のネットワーク検証装置において、
前記探索要否確認部は、
前記状態の過去の遷移経路を通る際に満たされるべき制約に関する情報（制約情報）を前記モデル検査実行部から受け取り、前記制約情報から制約充足問題を生成する制約充足問題生成部と、
前記制約充足問題の解を求めることで、前記遷移経路が実際に起こり得るか否かを判断し、前記状態の探索が必要か否かを確認する制約充足問題解決部と、
を備えるネットワーク検証装置。
［第４の形態］
第１から第３いずれか一の形態のネットワーク検証装置において、
前記検証情報の一部として、前記検証対象のネットワークが満たすべきプロパティを、ユーザが定義して入力することが可能であるネットワーク検証装置。
［第５の形態］
第１から第４いずれか一の形態のネットワーク検証装置において、
前記検証情報入力部は、
ユーザに対し、前記検証情報の一部あるいは全部について典型的な内容を定めた雛形を提供し、
前記雛形の選択により、前記検証情報の少なくとも一部の入力を受け付けるネットワーク検証装置。
［第６の形態］
（上記第２の視点によるネットワーク検証方法参照）
［第７の形態］
（上記第３の視点によるプログラム参照）
なお、上記第６、第７の形態は、第１の形態と同様に、第２〜第５の形態に展開することが可能である。

なお、上記の非特許文献の各開示を、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の全開示の枠内において種々の開示要素（各請求項の各要素、各実施形態ないし実施例の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。

１、１Ａ、３ ネットワーク検証装置
１１、３１ 検証情報入力部
１２ モデル検査実行部
１３ 探索要否確認部
１４ 検証結果出力部
１３１ 制約充足問題生成部
１３２ 制約充足問題解決部
３１１ 検証情報受付部
３１２ 検証情報雛形提供部

Claims (9)

1. 検証対象のネットワークの構成及びネットワークに含まれる機器の動作モデルを定義した検証情報の入力を受け付ける検証情報入力部と、
   前記検証情報を用いたモデル検査において、前記ネットワークに接続された端末からのパケットの内容を具体的に扱わずに状態遷移を行い、かつ、次状態の状態探索前に探索要否確認部に対し、各状態の過去の遷移経路に関する情報を送り、前記次状態の探索を省略可能か否かを問い合わせながらモデル検査を行うモデル検査実行部と、
   前記モデル検査実行部から受け取った状態の過去の遷移経路に関する情報に基づいて、前記次状態の探索が省略可能か否かを判断し、前記状態の探索が省略可能か否かを応答する探索要否確認部と、
   前記モデル検査実行部の出力に基づき、検証の結果を出力する検証結果出力部と、を備えるネットワーク検証装置。
2. 前記検証情報には、端末、ＯｐｅｎＦｌｏｗスイッチ及びＯｐｅｎＦｌｏｗコントローラを含むネットワークの構成情報と、前記端末及び前記ＯｐｅｎＦｌｏｗコントローラの動作モデルが定義されている請求項１のネットワーク検証装置。
3. 前記探索要否確認部は、
   前記状態の過去の遷移経路を通る際に満たされるべき制約に関する情報（制約情報）を前記モデル検査実行部から受け取り、前記制約情報から制約充足問題を生成する制約充足問題生成部と、
   前記制約充足問題の解を求めることで、前記遷移経路が実際に起こり得るか否かを判断し、前記状態の探索が必要か否かを確認する制約充足問題解決部と、
   を備えることを特徴とする請求項１又は２に記載のネットワーク検証装置。
4. 前記検証情報の一部として、前記検証対象のネットワークが満たすべきプロパティを、ユーザが定義して入力することが可能である請求項１から３のいずれか一に記載のネットワーク検証装置。
5. 前記検証情報入力部は、
   ユーザに対し、前記検証情報の一部あるいは全部について典型的な内容を定めた雛形を提供し、
   前記雛形の選択により、前記検証情報の少なくとも一部の入力を受け付ける請求項１から４のいずれか一に記載のネットワーク検証装置。
6. 検証対象のネットワークの構成及びネットワークに含まれる機器の動作モデルを定義した検証情報の入力を受け付けるステップと、
   前記検証情報を用いて、前記ネットワークに接続された端末からのパケットの内容を具体的に扱わずに状態遷移を行って、モデル検査を行うステップと、
   前記モデル検査の結果に基づいて前記検証対象のネットワークの検証結果を出力するステップと、を含み、
   前記モデル検査における次状態の状態探索前に、各状態の過去の遷移経路に関する情報に基づいて、前記次状態の探索が省略可能か否かを判断し、省略可能と判断した状態の探索を省略することを特徴とするネットワーク検証方法。
7. 前記状態の過去の遷移経路を通る際に満たされるべき制約に関する情報（制約情報）を前記モデル検査実行部から受け取り、前記制約情報から制約充足問題を生成するステップと、
   前記制約充足問題の解を求めることで、前記遷移経路が実際に起こり得るか否かを判断し、前記状態の探索が省略可能か否かを確認するステップとを用いて、
   前記状態の探索が省略可能か否かを判断する請求項６のネットワーク検証方法。
8. 検証対象のネットワークの構成及びネットワークに含まれる機器の動作モデルを定義した検証情報の入力を受け付ける処理と、
   前記検証情報を用いて、前記ネットワークに接続された端末からのパケットの内容を具体的に扱わずに状態遷移を行って、モデル検査を行う処理と、
   前記モデル検査の結果に基づいて前記検証対象のネットワークの検証結果を出力する処理と、さらに、
   前記モデル検査における次状態の状態探索前に、各状態の過去の遷移経路に関する情報に基づいて、前記各状態の探索が省略可能か否かを判断し、省略可能と判断した状態の探索を省略する処理とを、コンピュータに実行させるプログラム。
9. 前記状態の過去の遷移経路を通る際に満たされるべき制約に関する情報（制約情報）を前記モデル検査実行部から受け取り、前記制約情報から制約充足問題を生成する処理と、
   前記制約充足問題の解を求めることで、前記遷移経路が実際に起こり得るか否かを判断し、前記状態の探索が省略可能か否かを確認する処理とを用いて、
   前記状態の探索が省略可能であるか否かを判断する請求項８のプログラム。

Images