JP2015524237A - ネットワーク管理 - Google Patents

Abstract

【課題】ネットワークとの情報のやりとりに含まれる複雑さを緩和可能にした方法を提供し、その他の方法、装置およびシステムも提供する。【解決手段】ネットワークで用いられるネットワーク装置により実行される方法であって、ネットワークトポロジおよびネットワーク利用を検出し、アプリケーションからの要求を受信し、ネットワークトポロジおよびネットワーク利用から得られるネットワーク状態情報を用いて経路設定要求を決定し、経路設定要求を、インストールするルールに翻訳するものである。【選択図】図１

Description

本願は、２０１２年１０月５日に出願され、「フローセンス：オープンフロー・ネットワークのためのネットワーク管理装置」とタイトルされた米国仮出願６１／７１００８８の内容を全て含み、その利益を主張する。

本発明は、ネットワーク管理、特に、ソフトウェア定義ネットワークのための管理に関する。

ソフトウェア定義ネットワークは、スイッチおよびルータ（これらを簡単にスイッチと称する）のようなネットワークデバイスにおいて、制御装置と呼ばれる、論理的に集中化された装置に制御プレーンを移動することによって、データプレーン（パケット転送を実行する）と制御プレーン（パケットをどこに転送するかを決定する）を分離する。制御装置は、一連のＡＰＩを利用してスイッチにコマンドを発行する（例えば、転送テーブルエントリの追加、削除、変更や、状態の読み込み）。最もポピュラーで、ネットワーク制御とデータプレーンとの間のそのような通信プロトコルがオープンフローである。オープンフローは、ネットワークをきめ細かに制御可能にするが、低いレベルにあって、ネットワークからの高レベルの要求を有するアプリケーションに適していない。例えば、分散アプリケーションは、端点間の経路について終端間制約を有し、経路が制約（例えば、スイッチのリストを通り抜ける等）に合うことを満たす必要があるという、低いレベルの特性について自身を関与しようとしない（如何に関与するかを知ろうとしない）。そのため、アプリケーションがいかにネットワークと情報のやりとりを欲し、知ろうとしているか（ソケットインタフェースに類似の簡単なインタフェース）と、相互作用（複雑で、低いレベル）を実行するために用いられるオープンフロー・プロトコルとの間に食い違いがある。

先行研究では、パケット転送ポリシーを表現するためにオープンフロー（例えば、フレネティック、ネットコア）の上に高レベルのプログラミング言語を作り上げている。これらの取り組みは、オープンフロー転送ルール生成を最適化することと、異なるアプリケーションからのルールを同期させることを目的としている。しかしながら、これらはネットワークオペレータを対象としており、ネットワークとの情報のやりとりに含まれる複雑さを緩和するものではない。

我々は、フローセンスと呼ばれる、ネットワーク（例えば、オープンフロー・ネットワーク）のためのネットワーク管理装置を開発した。フローセンスは、簡単なＡＰＩを利用してアプリケーションと情報をやりとりし、アプリケーション要求をオープンフロー・ルールに翻訳し、これらのルールをオープンフロー・スイッチにインストールする。フローセンスは、ネットワークの変更（例えば、指定された帯域幅を伴う、２つの端点間の経路をインストールする）、またはネットワークの監視のためのアプリケーション要求を受け付ける。これらの要求に応えるために、フローセンスは、オープンフローを利用して継続的に収集した、ネットワーク（例えば、トポロジ、リンク利用）の状態の更新を維持する。オープンフロー・スイッチにルールをインストールするために、フローセンスは、スイッチにインストールするルールの数を最適化するルールエンジンを維持する。フローセンスは、オープンフロー・ネットワークに、簡単だが表現豊かなインタフェースを提供する。

先行技術文献

［１］A Compiler and Run-time System for Network Programming Languages, Christopher Monsanto, Nate Foster, Rob Harrison, David Walker, POPL 2012.

［２］Frenetic: A Network Programming Language, Nate Foster, Rob Harrison, Michael J. Freedman, Christopher Monsanto, Jennifer Rexford, Alec Story, David Walker, ICFP 2011.

［３］OpenFlow-based server load balancing gone wild, Richard Wang, Dana Butnariu, Jennifer Rexford, Hot-ICE 2011.

本願発明の目的はネットワークとの情報のやりとりに含まれる複雑さを緩和することである。

本願発明の一側面は、ネットワークで用いられるネットワーク装置により実行される方法を含む。その方法は、ネットワークトポロジおよびネットワーク利用を検出し、アプリケーションからの要求を受信し、ネットワークトポロジおよびネットワーク利用から得られるネットワーク状態情報を用いて経路設定要求を決定し、経路設定要求を、インストールするルールに翻訳する処理を含む。

本願発明の他の一側面は、コンピュータに処理を実行させるためのプログラムを格納する、一時的でないコンピュータ読み取り可能な記録媒体を含む。その処理は、ネットワークトポロジおよびネットワーク利用を検出し、アプリケーションからの要求を受信し、ネットワークトポロジおよびネットワーク利用から得られるネットワーク状態情報を用いて経路設定要求を決定し、経路設定要求を、インストールするルールに翻訳する処理を含む。

さらに、本願発明の他の一側面は、ネットワークで用いられるネットワーク装置を含む。そのネットワーク装置は、ネットワークトポロジおよびネットワーク利用を検出する検出手段と、アプリケーションからの要求を受信し、ネットワークトポロジおよびネットワーク利用から得られるネットワーク状態情報を用いて経路設定要求を決定する決定手段と、経路設定要求を、インストールするルールに翻訳するルール提供手段と、を有する。

図１はフローセンスのシステム構造を表す。

図２はフローセンスの機能性を表す。

図３はルール集約を表す。

図４はフローセンスによって実行される処理を表す。

フローセンスは、分散アプリケーションが基本的なネットワークと情報をやりとりするときに直面する複雑さを低減する。それは、オープンフロー・ネットワーク上にアプリケーションを展開するための障壁を大幅に下げ、その結果、オープンフロー自体の展開を促進する。

フローセンスのシステム構造を図１に示す。

フローセンスは、例えば、３つの構成要素：検出モジュール１２０、決定エンジン１０４、およびルールエンジン１１４を有する。検出モジュール１２０は、例えば、スイッチ間のトポロジと各リンクの利用を含む、オープンフロー１２６の現在の状態を監視するために受動検出１２２と能動検出１２４を用いる。決定エンジン１０４は、検出モジュール１２０と連絡することで継続的に更新する、ネットワークのマップ１１２を維持し、簡単だが表現豊かなＡＰＩを用いてアプリケーション１０２から問い合わせを受け付け、それらを経路設定要求または監視要求に翻訳する。決定エンジンは、主な仕事がそのような要求をオープンフロー・ルールに翻訳してルールをスイッチにインストールするルールエンジン１１４に、経路要求を転送する。決定エンジン１０４は、内部で監視要求を処理するが、必要ならきめ細かな測定のための要求を検出モジュール１２０に送ることができる。

図２に示すフローチャートはフローセンスの機能を示す。

以下に、フローセンスの各構成要素を詳しく説明する。

手順１：図１および図２におけるネットワーク検出１２０

この手順では、各リンクのトポロジと利用を求めることによってネットワーク１２６の状態を推測する。それは、要求によりまたは一定間隔で、ネットワーク１２６の状態を決定エンジン１０４に通知する。手順１．１でトポロジ検出について説明し、手順１．２で利用検出について説明する。

手順１．１：図２におけるネットワークトポロジ検出２０２

この手順では、スイッチ間のリンクを推測するための、各スイッチからのリンク・レイヤー・ディスカバリー・プロトコル（ＬＬＤＰ）パケット（標準書ＩＥＥＥ ８０２．１ ＡＢにおいて規格された）の送信、また、１つの端点がどのスイッチに接続されているかを推測するために各スイッチにインストールされたオープンフロー・ルールを調べることによって、物理的なネットワークトポロジを推測する。

手順１．２：図２におけるネットワーク利用検出２０４

各リンクにおけるネットワーク利用を監視するために、能動方法および受動方法を用いる。

手順１．２．１（能動方法）：ポーリングスイッチ

その手順では、リードステート・オープンフロー・メッセージを用いて各スイッチにおける利用カウンタを絶えず収集する。このメッセージに対する返答は問合せ対象のスイッチポート（他のスイッチと接続されるリンクに対応する）において転送されるバイトの数を含む。そのネットワーク検出モジュールは、スイッチの全てまたはスイッチのサブセットにおける収集間隔を変更するための要求を決定エンジンから受け付けてもよい。

手順１．２．２（受動方法）：キャプチャリング制御メッセージ

継続的にスイッチから収集することはネットワークの付帯的コストの観点で負荷になるので、その手順では、利用を推測するために制御トラフィックの受動監視にも頼る。具体的には、それは、フローエントリが期限切れになったスイッチによってもたらされるフローリムーブド・メッセージを捕捉することである。フローリムーブド・メッセージは、適合しなくなった、エントリの生存時間とバイトの数についての情報を含む。多数のフローリムーブド・メッセージからデータを収集することによって、特定したリンクにおける利用を見積もることが可能である。

手順２：決定エンジン１０４

この手順では、アプリケーションから要求を受信し、手順１から得られるネットワーク状態の情報を用いてそれらの要求を満たすようにする。そのアプリケーションは以下のＡＰＩを用いて要求を指定する。

ＡＰＩは、例えば、３つの構成要素を有する。ユニットはアプリケーションが要求している端点の組を表す。この手順においては、アプリケーションはＩＰアドレスの観点で端点を指定したと仮定する。ＩＰアドレスは、インターネット上で最も一般的なアドレス指定だからである。しかしながら、我々の手順では、ＭＡＣアドレスのような、端点を指定する他の方法を考慮しても同様に処理を行う。動作はアプリケーションがネットワークから何を要求しているかを表す。それは、（１）端点間に新しい経路を設定する、（２）現存する設定経路を監視する、または（３）端点間の設定経路を除去する、のいずれでもよい。最後に、目的は各動作に関連する性質を表す。我々は３つの目的を考えた。「接続性」は２つの端点間に経路を生成すること、または経路が存在するかを監視することを試みるものであり、「性能」は性能制約（例えば、帯域幅）を満たす経路を生成すること、または設定経路の性能を監視することを試みるものであり、「ポリシー」は指定されたミドルボックスを横断する経路を生成すること、または設定経路におけるミドルボックスのリストを戻すことである。もし動作が「監視」であるなら、アプリケーションは監視頻度も指定してもよい。

決定エンジンは、手順１からネットワーク状態を継続的に読み取り、アプリケーションからの問合せに関する決定に用いるネットワークマップを維持する。

決定エンジンは、例えば、４つの構成要素：図１および図２における端点分析１０４、経路分析１０８、監視１０６およびルーティング１１０を有する。

手順２．１：図１および図２における端点分析１０４

この手順の目的は端点がそのネットワーク上のどこに配置されているか検出することである。これは、アプリケーションが指定した、一組の端点間の設定経路を検出するとともに、設定経路を監視または経路を新たに生成するために重要である。端点ＩＰ（宛先としての）に適合するルールをもつスイッチから端点分析を開始し、幾通りかの方法に進む。

Ａ）そのルールの動作が出力ポートへの転送であると、対応するリンクを監視する。そのリンクがトポロジにあるなら、そのリンクの宛先スイッチを選択し、その処理を繰り返す。そのリンクがトポロジにないなら、それが端点につながると結論し、その端点が現在のスイッチと接続されていると予測する。

Ｂ）そのルールの動作が出力ポートへの転送以外であると、宛先としての端点ＩＰに適合するルールを所持する、トポロジにおける他のスイッチを選択し、最初から繰り返す。

手順２．２：図１および図２における経路分析１０８

この手順の目的はアプリケーションによって指定された端点間における現在の経路を見つけることである。第１の端点（送信元）に接続されたスイッチから始め、２つの端点間のトラフィックに適合する、最も指定に合ったルールを探す。そのようなルールが存在し、かつその動作が出力ポートへの転送であるなら、その出力ポートに接続された隣接するスイッチを選択し、繰り返す。そのルールの動作が出力ポートへの転送ではない、または端点間のトラフィックに適合するルールがないなら、端点間に経路がないとみなす。

手順２．３：図１および図２における監視１０６

この手順は、端点間の経路を監視するものであり、アプリケーションから経路監視の要求があった場合（動作「監視」が指定されることにより）に限り起動される。アプリケーションの要求における目的値によって、この手順では、端点間（目的＝「接続性」）に経路が存在するか確認し、経路（目的が「帯域幅」または「待ち時間」）の性能値または経路（目的が「ポリシー」）の既知のミドルボックスのリストを返信する。経路の帯域幅を求めるために、その手順では、手順２．２で得られた経路を取り、その経路における全てのリンクにまたがる最大利用を返信する。経路のためのミドルボックスのリストを生成するために、その手順では、その経路上の全てのスイッチを検査し、スイッチまたは制御装置以外のデバイスへの転送動作を伴う全てのルールを識別する。

手順２．４：図１および図２におけるルーティング１１０

この手順では、問合せの「目的」の欄において、アプリケーションによって指定された要求を満たす２つの端点間の経路を見つける。多数のルーティングアルゴリズムを支持する。問合せ目的が「接続性」であるなら、その手順では、ダイクストラ最短経路アルゴリズムを用いて端点間の最小ホップ数を伴う経路を見つけ出す。問合せ目的が「帯域幅」であるなら、その最短経路アルゴリズムを実行し、必要最低帯域幅を有しないリンクを許可しない。ミドルボックスを意識したルーティングについて、ネットワークにおいて各ミドルボックスがどこに所属しているかを判定するために、はじめに、手順２．１に記述された端点分析を使用する。そして、２つの選択肢を検討する。ミドルボックスの順番が厳格であるなら、ノード（例えば、（ＩＰ１，ミドルボックス１）、（ミドルボックス１，ミドルボックス２）など）の中間組毎にその最短経路アルゴリズムを実行し、そして、得られた経路をつなぎ合わせる。その順番が厳格でないなら、ミドルボックスに接続される全てのスイッチを横断する経路を見つけるまで、または経路がなくなるまで、端点間の最短経路アルゴリズムを実行する。

この手順の結果は端点間のトラフィックが横断しなければならないスイッチのリストである。決定エンジンはこのリストをルールエンジンに送る。

手順３：図１および図２におけるルールエンジン１１４

ルールエンジンは、一組の端点（すなわち、ＩＰアドレス）と端点間のトラフィックが横断する（すなわち、経路）スイッチのリストとを決定エンジンから受け取り、各スイッチにおいて経路を実行するオープンフロー・ルールを生成する。この手順は、例えば、２つの構成要素：ルール管理およびルールインストールを有する。

手順３．１：図１および図２におけるルール管理１１６

この手順の目的は、各スイッチにインストールするルールを最適化することである。各スイッチにインストールされるルールのセットは、２つの性質：網羅性と簡潔さを満足しなければならない。第１に、ルールは、できる限り現存のおよび次のトラフィックを取り扱うとともに、スイッチにおけるパケット処理を維持するものでなければならない。次期のトラフィックに一致するルールがないなら、スイッチは、追加ネットワークと処理負荷を生じる制御装置に連絡をしなければならない。第２に、スイッチのメモリは限られているので、各スイッチにおけるルールの数は最小化すべきであり、可能な限りマイクロフロー・ルールの代わりにワイルドカード・ルールが用いられるべきである。

この手順の本質は、多くのルールが多様な経路におけるトラフィックに適合する１つのより一般的なルールに集約されることである。より特別なルール群を１つの一般的なルールに置き換えることによって、網羅性を犠牲にすることなく、ルールセット（すなわち、スイッチ上で少ないルール）の簡潔性を向上させることができる。

ルール保持のために２分木を使用する。２分木はＩＰアドレスおよびＩＰ先頭部分を表す自然な形である。各ノードは、ＩＰ先頭部分に対応し、根に近いノードほどより短い先頭部分を表す。葉ノードは完全なＩＰアドレスを表す。各スイッチについて、ルール管理装置は、２つの３２階層のツリー：送信元ツリーと宛先ツリーを維持する。ルール最適化処理は、以下のように実行される。

１）決定エンジンから端点組とスイッチのリストを読み出す。

２）要求が経路設定であるなら、各スイッチについて、端点間のトラフィックに適合するオープンフロー・ルールを生成する。そのルールは適合部分（そのルールにしたがうパケットを識別するために使用される）と動作部分（これらのパケットの送り先を識別するために使用される）とを有する。要求が経路削除であるなら、リスト内の全てのスイッチにおける端点間のトラフィックに適合する全ての存在するルールを見つけ出す。

３）各ルール、各スイッチについて：ルールに関連する、各ツリーにおけるノードを見つけ出し、送信元ツリーの根と適合における送信元のＩＰアドレスまたは先頭部分の頭から始めて、ＩＰアドレスにおける次のビットが０ならそのツリーの左に進み、次のビットが１ならそのツリーの右に進み、階層の深さが先頭部分のサイズよりも高くなるときに停止し、要求が経路設定なら、現在のノードにルールを関連づけ、要求が経路削除なら、ルールを非活性化し、宛先ツリー／宛先ＩＰについて処理を繰り返し、続いて、各スイッチおよび各ルールについて繰り返す。

４）ルールを集約または分割する。

ツリーに新しいルールを追加した後、存在するルールセットの簡潔化を図るために、ルール集約を実行する。削除（例えば、集約の一部のルールを削除すると、集約されたルールは不適当になるかもしれない）の後、さらにルールの訂正を図るために、ルール分割を実行する。

手順３．１．１：図４におけるルール集約４０４

この手順では、スイッチのメモリにおける記憶空間を節約するためにより一般的なルールにルールを集約する。それは、以下のように実行する。

１）新しく追加されたルール（送信元および宛先のツリー）の先祖を根にしたサブツリーにおける全ての葉から始めて、各葉に関連する全てのルールを識別する。

２）同じ動作（ステップ１で識別したルールセットからの）を伴う全てのルールを取り出し、各動作についてルールセットを生成する。

３）濃度が予め指定された閾値より低い、全てのルールセット（ステップ２からの）を捨てる。

４）各動作について、送信元および宛先のツリーにおいて、その関連するルールセットを比較し、セット間の共通部分を取り出す。

５）各動作セットにおける全てのルールを一般的なルールに置き換え、この操作を実行するために、その動作セットにおける全てのルールを非活性化にマークし、ステップ１からサブツリーの根ノードにその一般的なルールを追加する。

ルール集約を図３に示す。

手順３．１．２：図４におけるルール分割４０６

この手順では、集約されたルールを、それを構成するルールに分割する。それは、以下のように実行する。

１）送信元および宛先のツリーの両方から集約されたルールを除去する。

２）集約されたルールの部分であった各ルールについて、ツリーからそれを取り除くような経路削除要求を受けてそれが明確に除去されるのでなければ、ツリーにそれを追加し、他の集約ルールへの上書きを引き起こすものでないときに限って集約が許可される変化と同時に、手順３．１からステップ２、３および４に続くツリーにルールを追加する。

手順３．２：図１および図２におけるルールインストール１１８

この手順では、送信元と宛先のツリーの各組において全ての能動的ルール取り出し、オープンフロー・プロトコルを用いてスイッチにそれらをインストールする。

手順２（端点分析および経路分析）と手順３（ルール管理）が組み合わされると、例えば、これらは、やり取りするアプリケーションのための、拡張可能で、簡単で、表現豊かな管理フレームワークを提供し、オープンフロー・ネットワークを変える。これは、既存のアプローチ、つまりオープンフロー・ルール生成の改善を図っているが、ネットワークとのやり取りの複雑さを抑制しないアプローチとは、異なる。フローセンスは、ネットワークとのやり取りのために簡単なインタフェースを提供し、決定エンジン内の相互作用の複雑さを隠す。拡張性のために、それは、スイッチにインストールされたルールの量と管理チャネル上の制御トラフィックの量を最適化するためにルール集約を実行する。

図４はフローセンスについての処理を示す。手順１、１．１〜１．２、２、２．１〜２．４、３、３．１および３．２は図２に示したこれらの手順と同様である。図４は入力４０２と出力４０４を明確に示す。入力４０２は、端点間への経路のインストールまたは端点間の経路の監視をアプリケーションが要求することによってもたらされる。出力４０８において、アプリケーションから要求された経路は、例えば、オープンフロー・ルールによって実行される。監視の要求があると、監視値がアプリケーションに戻される。

上記は、説明的で例示的な各事項であると理解されるべきであり、限定されるものではなく、上述した発明のスコープは、詳細な説明から決定されるべきではなく、むしろ、特許法にて許容される十分な範囲に従って解釈されるようなクレームから決定されるべきである。ここに示され記述された複数の実施形態は本発明の原理の単なる例示であり、当業者は本発明のスコープおよび趣旨から逸脱することなく種々の変形を実施し得ることが理解されるべきである。当業者は、本発明のスコープおよび趣旨から逸脱することなく他の様々な特徴の組み合わせを実行することができる。

Claims (16)

1. ネットワークで用いられるネットワーク装置により実行される方法であって、
   ネットワークトポロジおよびネットワーク利用を検出し、
   アプリケーションからの要求を受信し、
   前記ネットワークトポロジおよび前記ネットワーク利用から得られるネットワーク状態情報を用いて経路設定要求を決定し、
   前記経路設定要求を、インストールするルールに翻訳する、方法。
2. 請求項１に記載された方法において、さらに、
   前記ネットワークトポロジおよび前記ネットワーク利用から得られるネットワーク状態情報を用いて監視要求を決定する、方法。
3. 請求項１に記載された方法において、
   前記ネットワークはソフトウェア定義ネットワークまたはオープンフロー・ネットワークを有する、方法。
4. 請求項１に記載された方法において、さらに、
   ネットワーク検出によってネットワークマップを維持し、
   経路設定要求および監視要求のうち、少なくとも１つを決定するために前記ネットワークマップを利用する、方法。
5. 請求項１に記載された方法において、
   前記ネットワークトポロジの検出は、
   各スイッチからのＬＬＤＰ（Link Layer Discovery Protocol）パケットの送信によって物理的なネットワークトポロジを予測し、
   各スイッチにインストールされた存在するルールを調べる処理を有する、方法。
6. 請求項１に記載された方法において、
   前記ネットワーク利用の検出は、
   各スイッチの利用カウンタを収集する処理を有する、方法。
7. 請求項１に記載された方法において、
   前記ネットワーク利用の検出は、
   フローエントリが期限切れになったスイッチによってもたらさせるメッセージを捕捉する処理を有する、方法。
8. 請求項１に記載された方法において、
   経路設定要求および監視要求のうち、少なくとも１つの決定は、
   端点が前記ネットワークのどこに配置されているかを検出し、
   前記アプリケーションによって指定された一組の端点間の現在の経路を探し、
   前記アプリケーションが経路監視を要求している場合、前記一組の端点間の現在の経路を監視し、
   前記一組の端点間に、前記アプリケーションから受信した要求を満たす経路を探し、
   前記経路設定要求を行う処理を有し、
   前記経路設定要求は、前記一組の端点間のトラフィックが横断するスイッチのリストを有する、方法。
9. 請求項８に記載された方法において、
   前記経路設定要求の翻訳は、
   前記一組の端点とスイッチの前記リストを読み出し、
   前記要求が経路設定の場合、
   前記一組の端点間のトラフィックに適合するルールを生成し、
   前記ルールに関連するノードを探し、
   前記ノードと前記ルールを関連づける処理を含み、
   前記要求が経路削除の場合、
   前記一組の端点間のトラフィックに適合する既存のルールを見つけ、
   前記既存のルールを不活性化する処理を含む、方法。
10. 請求項９に記載された方法において、
    前記経路設定要求の翻訳は、さらに、
    前記ルールを集約する処理を有する、方法。
11. 請求項９に記載された方法において、
    前記経路設定要求の翻訳は、さらに、
    前記ルールを分割する処理を有する、方法。
12. 請求項８に記載された方法において、
    前記経路設定要求の翻訳は、
    スイッチにルールをインストールする処理を有する、方法。
13. コンピュータに処理を実行させるためのプログラムを格納する、一時的でないコンピュータ読み取り可能な記録媒体であって、
    前記処理は、
    ネットワークトポロジおよびネットワーク利用を検出し、
    アプリケーションからの要求を受信し、
    前記ネットワークトポロジおよび前記ネットワーク利用から得られるネットワーク状態情報を用いて経路設定要求を決定し、
    前記経路設定要求を、インストールするルールに翻訳する処理を含む、記録媒体。
14. 請求項１３に記載の一時的でないコンピュータ読み取り可能な記録媒体において、
    前記処理は、さらに、
    前記ネットワークトポロジおよび前記ネットワーク利用から得られるネットワーク状態情報を用いて監視要求を決定する処理を含む、記録媒体。
15. ネットワークで用いられるネットワーク装置であって、
    ネットワークトポロジおよびネットワーク利用を検出する検出手段と、
    アプリケーションからの要求を受信し、前記ネットワークトポロジおよび前記ネットワーク利用から得られるネットワーク状態情報を用いて経路設定要求を決定する決定手段と、
    前記経路設定要求を、インストールするルールに翻訳するルール提供手段と、
    を有するネットワーク装置。
16. 請求項１５に記載されたネットワーク装置において、
    前記決定手段は、さらに、前記ネットワークトポロジおよび前記ネットワーク利用から得られるネットワーク状態情報を用いて監視要求を決定する、ネットワーク装置。

Images