JP2019165339A - 経路制御装置、経路制御方法、およびプログラム - Google Patents

Abstract

【課題】独自通信路を使用して通信すべきクラウド上に配置したサーバと、イントラネット上の情報端末との通信を仲介する経路制御装置において、クラウド上のサーバ宛のパケットを適切に独自通信路へ経路制御する簡易な手段を提供する。【解決手段】経路制御装置は、パケットの宛先のアドレスに対して、該パケットの送信経路を規定する送信ルールを含む経路制御ルールにしたがって、パケットを送信する経路を第１の通信路と、クラウド上のサーバとの通信に使用する第２の通信路との間で切り替える経路制御機構と、宛先のアドレスに対応する送信ルールが経路制御ルールに登録されていないパケットを検出する検出機構と、検出されたパケットの宛先を検証する検証機構と、検証機構による検証結果に基づいて、第２の通信路を介する新しい送信ルールを経路制御ルールに登録するルール生成機構と、を有する。【選択図】図１

Description

本発明は、経路制御装置、経路制御方法、およびプログラムに関する。

従来、ＩｏＴといわれる自動認識や自動制御、遠隔測定などのためのコンピュータシステムが、ＯＡのみならずＦＡ・産業機器やヘルスケア・医療機器にも適用されるようになってきている。

このようなコンピュータシステムは、ネットワーク化され、従来はオンプレミスとして限定的なイントラネット環境で運用されていた。近年では、Ａｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅｓ（アマゾンウェブサービス（ＡＷＳ））をはじめとしたクラウドコンピューティングサービス（ウェブサービス）の発達とＩｏＴの流れと共に、情報収集用のサーバをクラウド上に配置して機器情報を蓄積したり、遠隔地間通信の中継ポイントとしてクラウドを経由したりする構成も普及し始めている。

例えば、クラウド上に情報収集サーバを配置する場合、イントラネット側にプロキシ機能を備えた仲介装置を置くことで、イントラネット内に配置されている情報収集対象端末との通信を効率化できる。この仲介装置は、一般にはイントラネット内に敷設されたＬＡＮ（ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）を用いて通信するが、イントラネットのセキュリティポリシーによってはインターネット接続が禁止されている場合がある。その場合は、仲介装置自身が独自に通信路を備えることで、インターネット接続を実現する方法がある。

クラウド上の情報収集サーバとの通信に独自通信路を用いる場合、機器情報の収集はイントラネット、情報収集サーバとの通信は独自通信路として経路制御する必要がある。情報収集サーバとの通信に独自通信路を用いる場合、一般的には、情報収集サーバのＩＰアドレスを調べておき、仲介装置のルーティングルール（静的ルール）に登録しておくことで経路制御が可能となる。

しかしながら、一般的に、ＡＷＳなどのクラウドサービスでは有料オプションとして固定ＩＰサービスを利用しない場合、サーバのＵＲＬは複数のＩＰアドレスと対応することになり、その内の任意の値が応答される。このため、クラウドサービスへの通信を独自通信路にルーティングする制御を、サーバのＩＰアドレスを、仲介装置のルーティングルール（静的ルート）に登録しておくことにより行うのは困難である。

これは、クラウドサービスシステムが返す複数のＩＰアドレス群を網羅するように、ルーティングルールを登録できるようにするのが難しいためである。また、クラウドサービスシステムが返す任意のＩＰアドレスの内の一つを固定的にルーティングルールに登録する対応をした場合、クラウドサービスシステムが返すＩＰアドレスは永続的に変わらないことは保障されていないため、その対応は暫定的なものとなり、クラウドサービスシステムが返すＩＰアドレスが変化した場合には対応できなくなる。

本発明は、上記に鑑みてなされたものであって、クラウド上に配置したサーバと、イントラネット上の情報端末との通信を仲介し、クラウド上に配置したサーバとの通信に独自通信路を使用する経路制御装置において、任意にＩＰアドレスが変化するクラウド上のサーバ宛のパケットを適切に独自通信路へ経路制御する簡易な手段を提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明の経路制御装置は、パケットの宛先のアドレスに対して、該パケットの送信経路を規定する送信ルールを含む経路制御ルールにしたがって、パケットを送信する経路を第１の通信路と、クラウド上のサーバとの通信に使用する第２の通信路との間で切り替える経路制御機構と、宛先のアドレスに対応する送信ルールが経路制御ルールに登録されていないパケットを検出する検出機構と、検出機構によって検出されたパケットの宛先を検証する検証機構と、検証機構による検証結果に基づいて、第２の通信路を介する新しい送信ルールを経路制御ルールに登録するルール生成機構と、を有することを特徴とする。

本発明によれば、クラウド上に配置したサーバと、イントラネット上の情報端末との通信を仲介し、クラウド上に配置したサーバとの通信に独自通信路を使用する経路制御装置において、任意にＩＰアドレスが変化するクラウド上のサーバ宛のパケットを適切に独自通信路へ経路制御する簡易な手段を提供することができる。

図１は、実施形態のシステムを模式的に示すブロック図である。 図２は、図１のシステムの仲介装置のハードウェア構成を模式的に示すブロック図である。 図３は、仲介装置の構成と信号の流れを模式的に示す機能構成図である。 図４は、仲介装置の動作の一例を示すフローチャートである。 図５は、変形例のシステムを模式的に示すブロック図である。

以下、図面を参照して本発明の実施形態について説明する。

本実施形態は、クラウド上にサーバを配置し、イントラネット上に情報端末を配置し、サーバと情報端末との通信を仲介する経路制御装置の一例としての仲介装置を配置し、仲介装置はサーバとの通信に独自通信路（独自回線）を使用する通信システムにおいて、任意にＩＰアドレスが変化するクラウド上のサーバ宛のパケットを適切に独自通信路へ経路制御（ルーティング）する簡易な手段を提供するものである。

図１は、本実施形態のシステムを示す模式的なブロック図である。このシステムは、イーサネット（登録商標）などのＬＡＮを含むイントラネットが構築されている顧客システム１を含んでいる。

リモートアクセスシステムである顧客システム１は、クラウド上に構築したセンターシステム３と、イントラネット側とのコミュニケーションを仲介するプロキシ機能を備えた仲介装置２０を有している。仲介装置２０には、情報端末として、プリンタ１１、ネットワーク機能を備えたホワイトボード１２、プロジェクタ（ＰＪＳ）１３などがイントラネットを介して接続されている。また、仲介装置２０は、ルータ（ＦＷ）１４に接続され、ルータ１４にはＰＣ１５が接続されている。

仲介装置２０は、顧客システム１におけるイントラネットのセキュリティポリシーにより、センターシステム３との通信を、ルータ１４とインターネットを介して行うのではなく、独自通信路を介して行う。これは、例えば、セキュリティ要件等の都合による運用の制約によるものである。

本実施形態では、仲介装置２０は、独自通信路として、３Ｇ回線であるキャリア回線２を用いる。キャリア回線２のサーバ２ａとセンターシステム３とは、ＩＰ−ＶＰＮを介して接続される。

なお、独自通信路は、３Ｇ回線に限られることはなく、３Ｇ、ＬＴＥ、ＬＰＷＡなどのイントラネットとは物理的に異なる通信インターフェースや、イントラネット上に構築したＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）のような仮想プライベートネットワークであってよい。

センターシステム３は、クラウド上に構築されたものであり、複数の情報収集サーバ３ａを有し、センターシステム３に対するＤＮＳリクエストに対して、いずれかの情報収集サーバ３ａのＩＰアドレスを返す。このため、センターシステム３からのレスポンスにおけるＩＰアドレスは、任意に変化する。

仲介装置２０は、例えば、ＰＣまたはアプライアンスボックス（小型の専用端末）上のアプリケーションにより実現され、例えば、図２に示すようなハードウェア構成を有している。すなわち、この構成では、ＣＰＵ２１と、ＲＡＭ２２やＲＯＭ２３などの記憶装置がバス２６によって接続されており、記憶装置に記憶されたプログラムであるアプリケーションをＣＰＵ２１が実行することにより、後述するような各種の機能部が実現される。また、仲介装置２０は、イントラネットを介した通信のための第１のインターフェース２４と、独自通信路を介した通信のための第２のインターフェース２５を有している。

次に、図３，４を参照して、仲介装置２０の動作について説明する。図３は、仲介装置２０の構成と信号の流れを模式的に示す機能構成図、図４は、仲介装置２０の動作の一例を示すフローチャートである。

仲介装置２０の情報収集プロキシ３０は、イントラネット内に配置されたプリンタ１１やプロジェクタ１３などの機器から機器情報を収集している。以下では、この収集したデータを、情報収集プロキシ３０からセンターシステム３へ送信するシナリオについて説明する。

情報収集プロキシ３０は、イントラネット内に配置された機器から機器情報を収集するために自身に登録されたＤＮＳ６０を利用して宛先（ＩＰアドレス）を解決して、機器と通信する。このＤＮＳ６０はイントラネット内用に割り当てられたものであり、イントラネット内のアドレス解決を実現している。

ただし、このＤＮＳ６０はインターネット側の名前解決を保証してくれない。このため、本実施形態では、仲介装置２０は、クラウド上の情報収集サーバ３ａのアドレス解決（ＵＲＬ→ＩＰアドレス）のために、クラウドサーバ用のＤＮＳ７０を利用する。例えば、３Ｇ回線の場合、ＳＩＭ契約しているプロバイダからＤＮＳ情報を割り当ててもらうことが可能であり、このＤＮＳを利用することが考えられる。

情報収集プロキシ３０は、適度に情報を蓄積すると、情報収集サーバ３ａへデータのアップロードを行う。このとき、仲介装置２０は、情報収集サーバ３ａのＩＰアドレスへは、前述のように、独自通信路を用いて通信する。

このために、仲介装置２０は、情報収集プロキシ３０からの通信経路を、イントラネット（第１の通信路）側と独自通信路（第２の通信路）側との間で切り替える経路制御スイッチ４０を有している。また、仲介装置２０は、経路制御スイッチ４０を制御する経路制御コントローラ５０を有している。

次に、図４のフローチャートを参照して動作について説明する。まず、情報収集プロキシ３０が通信パケットを経路制御スイッチ４０に送るに当たり、経路制御スイッチ４０の経路制御機構４１は、ステップＳ１で、ＤＮＳリクエストを受信する。すると、ステップＳ２で、経路制御機構４１は、ＤＮＳリクエストを、ＤＮＳ６０に送り、ステップＳ３で、ＤＮＳ６０のレスポンスパケットを抽出する。

そして、ステップＳ４で、経路制御機構４１は、ＤＮＳレスポンスに基づいて、ＤＮＳレスポンスエラーの有無を判定する。ＤＮＳレスポンスにエラーが無い場合には、ステップＳ９に進む。一方、ＤＮＳレスポンスにエラーがある場合には、ステップＳ５に進む。

ステップＳ５では、経路制御機構４１が、経路制御コントローラ５０へ問い合わせる。経路制御コントローラ５０では、ＤＮＳ代理機能を有する宛先検証機構５１が、経路制御機構４１からの問い合わせに応じて、第２のＤＮＳサーバとしての、クラウドサーバ用のＤＮＳ７０にＤＮＳリクエストを送信する。

次に、ステップＳ６で、宛先検証機構５１は、ＤＮＳレスポンスに基づいて、ＤＮＳレスポンスエラーの有無を判定する。ステップＳ６で、宛先検証機構５１が、ＤＮＳレスポンスエラーがあると判定した場合には、ステップＳ１２に進み、ＤＮＳレスポンスを情報収集プロキシ３０に応答して、処理を終了する。ステップＳ６で、宛先検証機構５１が、ＤＮＳレスポンスエラーが無いと判定した場合には、ステップＳ７へ進む。

ステップＳ７では、経路制御機構４１が、ステップＳ５でのＤＮＳ応答に基づいて、経路制御スイッチ４０の経路制御ルールを参照し、ＤＮＳ応答でのＩＰアドレスに対応する送信ルール（ルーティングルール）が、経路制御ルールに登録されていないと判定した場合には、経路制御コントローラ５０のルール生成機構５２が、新しい送信ルールを生成する。このように、経路制御機構４１は、ルール不明のパケット、すなわち、送信ルールが経路制御ルールに登録されていない宛先へのパケットを検出する検出機構として機能する。経路制御ルールは、パケットの宛先のＩＰアドレスに対して、当該パケットの送信経路を規定する送信ルールを含んでいる。

次に、ステップＳ８で、ルール生成機構５２が、新しい送信ルールを経路制御ルールに登録する。これにより、経路制御ルールに、クラウド上の情報収集サーバ３ａに対応する送信ルールとして、独自通信路を介した送信経路を選択するルールが登録される。

その後、ステップＳ９に進み、ステップＳ９では、ＤＮＳレスポンスが経路制御機構４１から情報収集プロキシ３０に応答される。そして、経路制御機構４１は、ステップＳ１０で、ＤＮＳレスポンスを受け取った情報収集プロキシ３０から送信パケットを受信する。そして、経路制御機構４１は、ステップＳ１１で、経路制御ルールに登録された送信ルールにしたがって、データを送信する。

この際、送信するデータのパケットが、イントラネット内のアドレス宛てであれば、経路制御ルールには、イントラネットを介する送信ルールが、永続的に保持する静的な送信ルールとして保持されている。そこで、経路制御機構４１は、この送信ルールにしたがって、イントラネットを介してパケットを送信する。

一方、送信するデータのパケットが、クラウド上の情報収集サーバ３ａ宛てである場合、経路制御機構４１は、ステップＳ８で追加された送信ルールにしたがって、パケットを送信する。これにより、ラウド上の情報収集サーバ３ａ宛てのパケットは、独自通信路を介して送信される。

なお、上記では、情報収集プロキシ３０から、パケットを送信する例を示したが、例えば、プリンタ１１からパケットが送信された場合も同様のルーティング処理を行い、イントラネットと独自通信路との間で、適切に送信経路を切り替えてパケットを送信することができる。

以上説明したように、本実施形態によれば、クラウド上のセンターシステム３への、独自通信路を介して送信すべきデータを送信する際、経路制御機構４１により、対応する送信ルールが経路制御スイッチ４０の経路制御ルールに登録されているか否かを検出し、登録されていない場合には、新たに送信ルールを登録し、フィードバックする。これにより、対応するＩＰアドレスが変化するクラウド上のシステムへのパケットに対して、送信ルールを動的に制御して、適切に、独自通信路へ経路制御することができる。なお、ルール生成機構５２によって動的に追加した送信ルールは、その登録情報の鮮度を維持するために一定時間で削除することが好ましい。

この際、本実施形態では、情報収集プロキシ３０には修正を加えず、上述のような経路制御機構４１や経路制御コントローラ５０を設けることにより、独自通信路を介したクラウド上のシステムへの通信を可能とすることができる。このため、適用が容易である。

すなわち、ＵＲＬのＩＰアドレスを解決してから、ルーティング設定を更新するというメカニズムを仲介装置２０の通信アプリケーションに搭載する手段も考えられるが、以下のデメリットが考えられる。
・開発済みの仲介装置自体のプログラムを修正するのは困難である。すなわち、仲介装置をイントラネット専用として設計してしまっている場合、後から独自回線に対応するようにするには既存設計を大きく変更することになる。このため、開発工数が過大となったり、品質が低下したりする恐れがある。また、独自通信路に関する専門的な技術と、複雑な経路制御に関する知識も必要であり、技術的ハードルも高い。したがって、仲介装置上のサービスアプリを改変せずに別のモジュールを追加することで独自通信路への経路制御を実現することが望ましい。
・通信処理毎にルーティング設定を更新するのは非効率である。また定期的にやると、その周期によっては誤送信する懸念がある
・通信アプリケーションが複数ある場合、それぞれで該当のメカニズムを動作させるのは冗長である。

したがって、本実施形態におけるように、既存の装置を改良するのではなく、既存のモジュールに対する外部モジュールにより、任意にＩＰアドレスが変化するクラウド上のサーバ宛のパケットの、独自通信路へ経路制御を実現することが望ましい。

また、一般的なＤＮＳの名前解決メカニズムでは、一つ目のＤＮＳサーバへの問い合わせにおいて、リクエストが成立した場合は、名前解決の成否にかかわらず、名前解決のプロセスが終了してしまう。つまり、図４のステップＳ５のクラウドサーバ用のＤＮＳ７０への問い合わせは発生しない。そのため、イントラネット用ＤＮＳで名前解決できないクラウド上のサーバとは通信ができない。一方、本実施形態では、ステップＳ４で、ＤＮＳリクエストの名前解決失敗を検出してクラウドサーバ用のＤＮＳ７０への問い合わせを自動生成して実施している。そのＤＮＳレスポンスは情報収集プロキシ３０へ転送される。これにより、情報収集プロキシ３０はクラウド用のＤＮＳ７０の存在を意識せずに名前解決が可能となっている。

また、ステップＳ５において、名前解決できた場合、その宛先のパケットは独自回線へルーティングする必要がある。しかし、デフォルトゲートウェイはイントラネット用に向いており、そのままでは独自回線へルーティングできない。そこで、本実施形態では、ステップＳ７でルーティングルールを生成してステップＳ７でルーティングルールを適用する。そのため、クラウド上のサーバのＵＲＬに対するＩＰアドレスが変動した場合でも、動的にルーティングルールを追加することができ、独自回線へのルーティングが可能となっている。

本実施形態の仲介装置２０における上記のような処理は、上記のようなＣＰＵ２１を備えるコンピュータにプログラムを実行させることにより実現することができる。この場合、このプログラムにより、上記のような制御が実現される。そして、このプログラムは、インストール可能な形式または実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等のコンピュータで読み取り可能な記録媒体に記録されて提供することができる。

また、上記のプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。また、上記のプログラムをインターネット等のネットワーク経由で提供または配布するように構成しても良い。

また、上記のプログラムを、ＲＯＭ２３等に予め組み込んで提供するように構成してもよい。

本実施の形態の仲介装置で実行されるプログラムは、上述した各部（経路制御機構４１、宛先検証機構５１、ルール生成機構５２など）を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ２１（プロセッサ）が記憶媒体からプログラムを読み出して実行することにより上記各部が主記憶装置であるＲＡＭ２２上にロードされ、生成されるようになっている。

なお、上述の実施形態は一例であり、本発明の範囲内で種々の変更が可能である。

例えば、上述の実施形態では、情報収集プロキシ３０、経路制御スイッチ４０、経路制御コントローラ５０を仲介装置２０の内部に配置しているが、これらは、同一の装置内に配置する必要はなく、別々の装置に配置してもよい。

また、経路制御スイッチ４０と、経路制御コントローラ５０とは、互いに異なるネットワークノードに配置し、１つの経路制御コントローラ５０が、複数の経路制御スイッチ４０に対応するようにしてもよい。それによって、設置や運用の手間を低減することができる。

また、上述の実施形態において、情報収集プロキシ３０はイントラネットと、クラウド上のシステムの双方に通信する必要のあるアプリケーションの例であり、必ずしも情報収集機能を有する装置でなくてもよい。

ここで、他の適用例について、図５を参照して説明する。図５は、ＬＡＮにより構成されたイントラネットと、クラウド上のシステムである管理システム１７０との双方に通信する、上述の実施形態の経路制御装置（仲介装置２０）の構成を適用可能な管理仲介装置１１０，１３２と、管理仲介機能付機器１３３を含む遠隔管理システムの全体構成を示すブロック図である。

図５の遠隔管理システムにおいて、顧客システム１６０ａは、顧客先に設置されているシステムである。顧客システム１６０ａにおいて、管理仲介装置１１０は、ＬＡＮにより、管理対象システム１３０に接続されている。管理対象システム１３０には、例えば、加工機、搬送機、検査機等の複数の産業機械１３１ａやセンサ１３１ｂ（撮像装置、集音装置等）の機器が含まれる。管理仲介装置１１０は、各機器内に設けてあるファームウェアを、インターネット接続を利用して更新するファームウェア更新機能を備えている。

同様に、顧客システム１６０ｃは、他の顧客先に設置されているシステムである。顧客システム１６０ｃにおいて、管理仲介装置１１０は、ＬＡＮにより、複数の管理対象システム１３０に接続されている。 このうち、１つの管理対象システム１３０には、例えば、加工機、搬送機、検査機等の複数の産業機械１３１ａやセンサ１３１ｂ（撮像装置、集音装置等）の機器と、管理仲介装置１１０と同様のファームウェア更新機能を備えている管理仲介装置１３２が含まれる。

図５の例では、管理対象システム１３０が複数の産業機械１３１ａやセンサ１３１ｂと、１つの管理仲介装置１３２を含む構成を示しているが、さらに他の機器を含んで構成してもよい。この顧客システム１６０ｃでは、１台の管理仲介装置１１０を設置しただけでは負荷が大きくなるため、１つの管理対象システム１３０内の各産業機械１３１ａやセンサ１３１ｂとのファームウェア更新のための機能は管理仲介装置１３２に割当て、外部の管理システム１７０との独自通信路を介した接続を利用した、複数の管理対象システム１３０の遠隔管理を集中的に行う機能を管理仲介装置１１０に割当てた構成としている。

同様に、顧客システム１６０ｂは、さらに別の顧客先に設置されているシステムである。顧客システム１６０ｂにおいては、管理仲介機能付機器１３３（産業機械１３３ａやセンサ１３３ｂ）がＬＡＮに接続されている。 管理仲介機能付機器１３３は、管理仲介装置１１０と同様のファームウェア更新機能を備える産業機械１３３ａやセンサ１３３ｂである。

図５のように構成された顧客システム１６０ａ，１６０ｂ，１６０ｃは、その内部から外部の管理システム１７０に独自通信路を介して接続される。この管理システム１７０が、独自通信路を利用して、各管理対象システム１３０の遠隔管理を実施する。

管理システム１７０および管理仲介装置１１０は、一般的なコンピュータ要素を含んで構成されている。 即ち、少なくとも、プログラム処理を実行するＣＰＵと、このＣＰＵがプログラム処理に用いるＲＡＭ、ＲＯＭ、大容量記憶装置等の記憶手段と、モデムやネットワークインタフェース等の通信手段とを含んで構成されている。

当該管理システムにおける被管理装置は、産業機械に限られず、画像形成装置、ネットワーク家電、自動販売機、医療機器、産業機械、電源装置、空調システム、ガス・水道・電気等の計量システム等に通信機能を持たせた機器であってよい。

例えば、産業機械としては、加工装置、検査装置、搬送装置、ピッキング装置、などが挙げられる。また、これら機器の周辺に設置され機器の状態を把握するための撮像装置や集音装置であってもよい。産業機械は、当該機器の識別情報、当該機器の稼働状況や異常動作の有無、消耗品の交換時期に関する情報、当該機器による検査結果等を、データ形式又は画像形式等の種々の情報伝達手段を用いて管理装置に送信する。

また、例えば、医療機器としては、眼底検査装置、Ｘ線検査装置、血圧計、体脂肪計、視力計、ペースメーカなどが挙げられる。医療機器は、当該機器の識別情報、当該機器の稼働状況や異常動作の有無、当該機器による測定結果等を、データ形式又は画像形式等の種々の情報伝達手段を用いて管理装置に送信する。

２０ 仲介装置
４０ 経路制御スイッチ
４１ 経路制御機構
５０ 経路制御コントローラ
５１ 宛先検証機構
５２ ルール生成機構

特開２０１７‐１３５５０８公報

Claims (5)

1. パケットの宛先のアドレスに対して、該パケットの送信経路を規定する送信ルールを含む経路制御ルールにしたがって、パケットを送信する経路を第１の通信路と、クラウド上のサーバとの通信に使用する第２の通信路との間で切り替える経路制御機構と、
   宛先のアドレスに対応する送信ルールが前記経路制御ルールに登録されていないパケットを検出する検出機構と、
   前記検出機構によって検出された前記パケットの宛先を検証する検証機構と、
   前記検証機構による検証結果に基づいて、前記第２の通信路を介する新しい送信ルールを前記経路制御ルールに登録するルール生成機構と、
   を有する経路制御装置。
2. 前記ルール生成機構は、登録した前記送信ルールを一定時間で削除する、請求項１に記載の経路制御装置。
3. 前記経路制御機構として、複数の制御機構を含み、
   前記複数の制御機構と、該複数の制御機構に対応する１つの前記ルール生成機構とが、互いに異なるネットワークノードに配置されている、請求項１または２に記載の経路制御装置。
4. パケットの宛先のアドレスに対して、該パケットの送信経路を規定する送信ルールを含む経路制御ルールにしたがって、パケットを送信する経路を第１の通信路と、クラウド上のサーバとの通信に使用する第２の通信路との間で切り替えるステップと、
   宛先のアドレスに対応する送信ルールが前記経路制御ルールに登録されていないパケットを検出するステップと、
   検出された前記パケットの宛先を検証するステップと、
   前記宛先の検証結果に基づいて、前記第２の通信路を介する新しい送信ルールを前記経路制御ルールに登録するステップと、
   を有する経路制御方法。
5. パケットの宛先のアドレスに対して、該パケットの送信経路を規定する送信ルールを含む経路制御ルールにしたがって、パケットを送信する経路を第１の通信路と、クラウド上のサーバとの通信に使用する第２の通信路との間で切り替えるステップと、
   宛先のアドレスに対応する送信ルールが前記経路制御ルールに登録されていないパケットを検出するステップと、
   検出された前記パケットの宛先を検証するステップと、
   前記宛先の検証結果に基づいて、前記第２の通信路を介する新しい送信ルールを前記経路制御ルールに登録するステップと、
   をコンピュータに実行させるためのプログラム。

Images