JP5860423B2 - キャリア網仮想化システム及び方法 - Google Patents

Description

本発明は、キャリア網仮想化システム及び方法に係り、特に、キャリア網の仮想化を実現するためのキャリア網仮想化システム及び方法に関する。

現在のキャリア網、特に固定網においては、インターネットアクセスやIPTV、VPN(Virtual Private Network)などのネットワークサービスを提供するための機能（以下、「ネットワークサービス機能」と記す）が、エッジルータや専用のアプライアンスといった形態で実装されている。一方、現状のキャリア網は、IPネットワークとして構成されており、前述のエッジルータやアプライアンスへの経路制御に、OSPF(Open Shortest Path First)やBGP(Border Gateway Protocol)といったルーティングプロトコルが利用されている。

一般に、IPのルーティングプロトコルでは、複数のユーザのトラフィックをまとめたフロー（アグリゲートフロー）に対して経路制御を実施する。これまでのトリプルプレイサービスのように、全てのユーザに一律に同じサービスを提供する場合には、このような経路制御手法で問題はなかった。

しかしながら、インターネットユーザの増加により、ユーザ層が幅広くなり、個々のユーザのニーズが多様化してきており、ユーザ毎にカスタマイズされたサービスを提供する必要性が高まっている。例えば、あるユーザＡにはDPI(Deep Packet Inspection)機能を用いたセキュリティサービスを提供し、別のユーザＢにはコンテンツキャッシュの機能を提供するといった具合である。このようにユーザ毎にカスタマイズされたサービスを提供しようとすると、ユーザＡのパケットはDPI装置に引き込むが、ユーザＢのパケットはDPI装置ではなくコンテンツキャッシュ装置に引き込むといったように、ユーザごとに異なる経路制御が必要となる。全国規模のネットワークでは、数百万単位のユーザを収容する必要があり、既存のIPルーティングプロトコルで制御することは困難であると考えられる。

このような状況において、データセンタでの利用が始まっているOpenFlowの技術（例えば、非特許文献１参照）を、キャリア網に適用する検討がなされている。OpenFlowは予め定義したフローの単位で経路制御を実現することができるため、ユーザごとのトラフィックをフローとして定義することで、前述のようにユーザ毎に経路制御を柔軟に変えることができる。しかしながら、現在のOpenFlowは、まずデータセンタをターゲットに開発された技術であり、キャリア網規模でのユーザ数（数百万〜数千万）規模に適用しようとすると、フローの情報を保持するハードウェアの制約があるため、現在のキャリアのIP網を全てOpenFlowで置き換えることは現実的ではない。

ところで、データセンタではサーバの仮想化技術が進展しており、クラウドサービスとして商用展開が進んでいる。前述のネットワークサービス機能も、汎用CPUやメモリ、ストレージ、ネットワークプロセッサなど、既存のサーバと同じようなコンピューティングリソースで実装されており、将来は仮想化されることが期待できる。ネットワークサービス機能が仮想化された場合には、サーバ仮想化の仮想マシン（VM： Virtual Machine）と同様に、物理的な装置の配置の制約を受けずに、適切なコンピューティングリソースのある場所へ移動することも考えられる。これをネットワークから見た場合、IPアドレスやMACアドレス等の同一のＩＤで識別されるネットワークサービス機能が、地理的に移動することに他ならない。移動したネットワークサービス機能に対して、同一のID宛のパケットを届けるには、移動体で適用されているような移動管理の技術が必要になる。しかしながら、前述のOpenFlowは移動管理の機能を持っていない。

"Software-Defined Networking: The New Norm for Networks," ONF White Paper, Open Network Foundation, April 13, 2012, URL: http://www.opennetworking.org/images/stories/downloads/white-papers/wp-sdn-newnorm.pdf

上記のように、キャリア網において、個々のユーザのニーズに応じて、提供するサービスを柔軟に変えるためには、個々のユーザごとのフローに対して経路制御が可能なOpenFlowのような技術が必要になるが、現在のOpenFlowはデータセンタ規模を対象とした技術であり、キャリアの広域ネットワークへの適用は困難である。また、将来、ネットワークサービス機能が仮想化された場合には、その位置を管理して適切にパケットを届ける移動管理機能が必要なるが、現在のOpenFlowには移動管理の機能がない。

本発明は、上記の点に鑑みなされたもので、従来では困難であったキャリアの広域ネットワークへの適用を可能とし、ネットワークサービス機能が仮想化され、その位置が変更されるような場合であっても、パケットを転送することが可能なキャリア網仮想化システム及び方法を提供することを目的とする。

上記の課題を解決するため、本発明（請求項１）は、コアネットワーク内にエッジルータ間をフルメッシュに接続可能なトンネルを有するキャリア網を仮想化するキャリア網の仮想化システムであって、
前記コアネットワークに接続された複数のエッジルータと、
データセンタ拠点内に配置され、ネットワークサービス機能を実現するための物理リソースと、
前記エッジルータがパケットを転送する宛先及びパケットの処理方法を示すアクションを有するフローテーブルを作成し、該エッジルータに通知するフロー制御コントローラと、
を有し、
前記エッジルータは、
前記フロー制御コントローラから前記フローテーブルの情報を取得して格納するフローキャッシュと、
パケットが転送されてくると、前記フローキャッシュを参照して該パケットを、前記アクションに応じてカプセル化またはデカプセル化し、エッジルータ間に確立されたトンネルを介して前記ルールに示される宛先に転送する転送手段と、を有し、
前記フロー制御コントローラは、
物理リソースがどのエッジルータの配下にあるかを示すリソーステーブル、ユーザの契約情報に基づいて、どのサービスについて処理するのかを示すユーザ処理テーブルと、どの物理リソースにどのネットワークサービス機能を割り当てているかを示すサービス機能テーブルを取得し、該リソーステーブル、該ユーザ処理テーブル、該サービス機能テーブルの情報に基づいて、前記フローテーブルを生成するテーブル生成手段と、
前記サービス機能が第１の物理リソースから第２の物理リソースに移動した場合に、移動情報に基づいて前記リソーステーブルと前記サービス機能テーブルを更新する手段と、
前記更新された前記リソーステーブルと前記サービス機能テーブルの情報を取得し、更新された部分に該当するフローテーブルのエントリを更新するテーブル更新手段と、
を有する。

上述のように、本発明によれば、従来のOpenFlowでは困難であったキャリアの広域ネットワークへの適用ができるようになると共に、ネットワークサービス機能が仮想化され、その位置が変更されるような状況においても、ユーザ毎に契約しているネットワークサービス機能を経て、パケットを転送することができるようになる。

本発明が適用されるネットワーク構成を説明するための図である。 本発明の一実施の形態におけるサービス機能テーブルの構成図である。 本発明の一実施の形態におけるリソーステーブルの構成図である。 本発明の一実施の形態におけるユーザ処理テーブルの構成図である。 本発明の一実施の形態におけるフロー制御コントローラの構成図である。 本発明の一実施の形態におけるフローテーブルの構成図である。 本発明の一実施の形態におけるエッジルータの構成図である。 本発明の一実施の形態におけるフローテーブルの生成手順のシーケンスチャートである。 本発明の一実施の形態におけるパケットの転送手順のシーケンスチャートである。 本発明の一実施の形態におけるフローテーブルの更新手順のシーケンスチャートである。 本発明の一実施の形態におけるサービス機能テーブルとリソーステーブルの更新を説明するための図である。 本発明の一実施の形態におけるフローテーブルの更新を説明するための図である。

以下、図面と共に本発明の実施の形態を説明する。

最初に、本発明の概要を説明する。

本発明は、キャリアの広域ネットワークへの入口にあたるエッジルータにおいて、ユーザ単位やサービス単位に定義されたフローを、その宛先に応じて、エッジルータ間に確立されたトンネルに転送することで、広域ネットワーク中では個々のフローを意識しない経路制御を実現する。これにより、ネットワークのエッジ部分（エッジルータより外側）では、ユーザ単位やフロー単位の細かな制御を実現しつつ、広域ネットワークを介してもスケーラビリティを確保できる。

また、個々のフローをトンネルにマッピングする際に、そのフローの宛先となるネットワークサービス機能の位置を考慮する。具体的には、ネットワークサービス機能がどのエッジルータに接続されている拠点に配置されているかの情報をネットワーク側で保持し、ネットワークサービス機能が移動した場合には、前述の情報を更新し、フローを転送するトンネルを変更できるようにすることで、ネットワークサービス機能が配備されている位置が変わっても、正常に通信ができるようになる。

本実施の形態では、コアネットワーク１内のトンネル技術として、IPトンネル（GRE（Generic Routing Encapsulationトンネル等）を想定するが、エッジルータ間をフルメッシュに接続可能なトンネル技術であればMPLS（Multi Protocol Label Switching）など他の技術でもよい。

図１は、本発明が適用されるネットワーク構成を説明するための図である。

キャリアのコアネットワーク１には、ISP(Internet Services Provider)２、CSP（Contents Service Provider）３、及びデータセンタ拠点４ａ、４ｂ、４ｃが接続されている。また、ISP２とCSP３はインターネット５に接続されている。コアネットワーク１はコアルータ７が相互に接続され、エッジルータ６間の通信を担う。

コアネットワーク１には、ユーザ端末８ａ、８ｂがエッジルータ６を介して接続される。ユーザ端末８は、スマートフォン、ＰＣ、モバイルルータ、ホームゲートウェイ等、なんでもよい。また、データセンタ拠点４内には、ネットワークサービス機能を実現するためのリソースである物理リソース９が存在する。これらは、CPUやメモリ、ストレージ、ネットワークプロセッサなどの所謂コンピューティング資源である。また、ネットワークを制御するためのデータベース（テーブル）や装置としてサービス機能テーブル１０、リソーステーブル１１、ユーザ処理テーブル１２、フロー制御コントローラ１３がある。これらの詳細は後述する。

次に、図２〜図７を用いて、各テーブルや装置の構成を説明する。

図２は、本発明の一実施の形態におけるサービス機能テーブルの構成を示す。

サービス機能テーブル１０は、どの物理リソース９に、どのネットワークサービス機能を割り当てているのかの対応関係を保持するテーブルである。サービス機能テーブル１０は、サービス機能種別１０１（例えば、DPIやパケットカウンタ等）、サービス機能ID１０２，リソースID１０３から構成される。サービス機能ID１０２は、そのネットワークサービス機能を一意に識別するためのＩＤである。リソースID１０３は、物理リソース９に一意に付与されたIDであり、該当するネットワークサービス機能が、どの物理リソース９に対応付けられているかを示すものである。リソースID１０３としては、サーバなどのIPアドレスが利用できるが、単一の物理サーバを仮想化して複数のネットワークサービス機能で共用する場合には、個々の仮想化された仮想マシン(VM: Virtual Machine)のIDを付与する。仮想マシンのIDとしては、例えば、その仮想マシンを収容している物理サーバのIPアドレス＋VMのID（IPアドレスやMACアドレス、VLAN-IDなど、ネットワーク側から一意にVMが特定できるID）を利用することができる。

図３は、本発明の一実施の形態におけるリソーステーブルの構成を示す。

リソーステーブル１１は、それぞれの物理リソース９が、どのエッジルータ６に接続されているかを示すテーブルである。リソーステーブル１１は、個々の物理リソースに割り当てられたIDであるリソースID２０１と、エッジルータID２０２から構成される。

図４は、本発明の一実施の形態におけるユーザ処理テーブルの構成を示す。

ユーザ処理テーブル１２は、各ユーザがどのサービスを契約しているかに応じて、ユーザのパケットを、どのような順番でどのネットワークサービス機能に転送するかを示す情報を格納する。ユーザ処理テーブル１２は、個々のユーザに一意に割り当てられたユーザID３０１、どのサービスの処理を示すかのサービス３０２（例えば、インターネットやIPTV）、該ユーザ、該サービスのパケットの処理順序を示す処理３０３から構成される。なお、処理３０３の作成手順については、本発明の対象外とするが、一般的にはキャリアが保持する顧客データベース（図示せず）の情報から、各サービスに必要なネットワークサービス機能を、必要な順番で通るように作成すればよい。

図５は、本発明の一実施の形態におけるフロー制御コントローラの構成を示す。

フロー制御コントローラ１３は、サービス機能テーブル１０、リソーステーブル１１、ユーザ処理テーブル１２の内容を取得し、これらの情報からフローテーブルを作成し、エッジルータ６に通知する役割を担う。フローテーブル生成部４０１は、上記の３つのテーブルからフローテーブル４０２を生成する機能を持つ。フローテーブル４０２は、フローテーブル生成部４０１が生成したフローテーブルを保持するデータベースである。フロー情報通知部４０３は、フローテーブル４０２の情報を、各エッジルータ６に通知する機能である。

図６は、本発明の一実施の形態におけるフローテーブルの構成を示す。

フローテーブル４０２は、１エントリ（図６の１行に相当）で、１つのエッジルータ６が処理する１つのフローの処理内容を保持する。エッジルータID５０１は、該当エントリがどのエッジルータのものであるかを示す。ルール５０２は、フローとして認識すべきパケットを特定するためのルールを示すものである。転送されてきたパケットのパケットヘッダの情報や、そのパケットが転送されてきたポート番号（入力ポート番号）などがルールとして記述される。複数のルールを記載することもでき、その場合にはAND条件によりマッチングが行われる。アクション５０３は、ルール５０２にマッチしたパケットをどのように処理するかを示す。主要なアクションとしては、特定ポート番号から転送する、カプセル化した上で、特定の宛先に転送する、などがあるが、一般的なスイッチやルータが実現可能なものであればなんでもよい。

図７は、本発明の一実施の形態におけるエッジルータの構成を示す。

エッジルータ６は、基本的には一般的なエッジルータやスイッチを想定するが、ここでは、本発明に特徴的な機能のみを示す。フローテーブル受信部６０１は、フロー制御コントローラ１３から通知されるフローテーブル４０２の情報を受信し、フローキャッシュ６０２に格納する。フローキャッシュ６０２は、フロー制御コントローラ１３から通知されたフローテーブル４０２の情報をそのまま保持するためのテーブルである。フローキャッシュ６０２の情報は、ネットワークインタフェース６０３内の高速なメモリに転送され、実際にパケットが転送されてきた際に、ルールのマッチングを行い、そのパケットの処理方法（アクション）を決めるための情報となる。ネットワークインタフェース６０３上で処理方法が決定されたパケットは、スイッチファブリック６０４を経由して、別のネットワークインタフェースに転送され、そこからネットワークへ出力される。

次に、図８〜図１１を用いて本発明の動作を説明する。

図８は、本発明の一実施の形態におけるフローテーブルの生成手順のシーケンスチャートであり、フローテーブル４０２を生成し、エッジルータ６に通知するまでの動作を示している。ユーザが通信を実施する前に、ネットワーク側で予め実施する動作である。

まず、ユーザ契約情報などから、ユーザ処理テーブル１２を生成する（ステップ１）。同様にネットワーク設計などの情報からリソーステーブルを生成する（ステップ２）。リソーステーブル１１は、前述のとおり、サーバ等の物理リソース９がどの拠点（どのエッジルータ６の配下）にあるかを示すテーブルであるため、物理的なネットワーク設計情報などから容易に生成可能である。また、同様に、ネットワーク設計などから、サービス機能テーブル１０を生成する（ステップ３）。サービス機能テーブル１０は、どの物理リソースに、どのネットワークサービス機能を割り当てているのかを保持するテーブルであり、その割り当ては、サービスの種類や各サービスを契約しているユーザ数などを考慮して決めるものである。

ユーザ処理テーブル１２、リソーステーブル１１、サービス機能テーブル１０が生成されたら、フロー制御コントローラ１３は、これらの情報を収集する（ステップ４〜６）。フロー制御コントローラ１３は、これらの情報から、フローテーブル４０２を生成する（ステップ７）。以下にフローテーブルの生成例を示す。

前提として、サービス機能テーブル１０、及び、リソーステーブル１１は、それぞれ図２、図３に示すようになっているとする。これらは、前述のとおり、ネットワーク設計等の情報から生成されるものである。ここで、ユーザAのユーザ処理テーブルが図４のとおり与えられ、ユーザAのインターネットサービスのパケットを制御するためのフローテーブルを生成する手順は次のようになる。

まず、図４のユーザ処理テーブル１２を見ると、ISP(リソースID=S11)から転送されてきたパケットを、物理リソースS2aに割り当てられているDPI（Deep Packet Inspection）機能に転送すべきことがわかる。図３のリソーステーブル１１を見ると、ISP２は、E11のエッジルータ６に、リソースS2aはE13のエッジルータ６に接続されていることがわかるため、E11のエッジルータが受信したパケットをエッジルータE13に転送しなくてはならない。従って、エッジルータE11において、ユーザA宛のパケット（宛先IPアドレスがユーザAの＃a）を、エッジルータE13に転送する、というフローエントリ（フローテーブル４０２の１行分）を設定することになる（図６の１行目）。ここで、本発明においては、コアネットワーク１内のコアルータ７では、個々のフローを意識させないため、GREによりカプセル化した上で、エッジルータE13に転送する。そのため、図６の１行目のアクションが、カプセル化した上で、宛先エッジルータE13に転送する、という記載になっている。エッジルータE13では、転送されてきたパケットの宛先（カプセル化された外側のIPヘッダのアドレス）が自分（E13）であり、内側の元のパケットがユーザA宛のもの（宛先IPアドレスがユーザAの＃a）であれば、物理リソースS2aに転送する（図６の２行目）。その後、物理リソースS2aでDPIによる処理を受けたパケットを、リソースIDがS1bの物理リソースにあるパケットカウンタカウンタ機能へ転送する必要がある。物理リソースS1bは、リソーステーブル１１（図３）によるとエッジルータE14の拠点にあることがわかるため、エッジルータE13が、先ほどと同様にカプセル化した上で、エッジルータE14にパケットを送信するためのフローエントリを追加する（図６の３行目）。以下、同様に、ユーザAが収容されているエッジルータE1まで転送されるようにフローエントリを生成する。

なお、図６には、ユーザAのインターネットサービスのフローエントリしか記載していないが、実際には、全てのユーザの全てのサービスのパケットを制御するためのフローエントリが記載されている。

このようにして、フローエントリが生成されたら、フロー制御コントローラ１３は、各エッジルータ６にフローエントリを通知する（ステップ８）。フローエントリを受信したエッジルータ６は、フローキャッシュ６０２にフローエントリを格納し、また、同時に、ネットワークインタフェースに存在する高速なメモリにフローエントリを書き込む。

図９を用いて、実際のパケットの流れを説明する。

図９は、本発明の一実施の形態におけるパケットの転送手順のシーケンスチャートである。

ここでは、ユーザAのインターネットサービスのパケットが、インターネット（ISP）からユーザAに届くまでの流れを示すが、他の逆向きのパケットや、別のサービスのパケットでも同様である。なお、図９において、楕円の印は、各エッジルータ６での処理を実施する箇所を示している。

まず、ISPからパケットが転送されてくると、パケットを受信したエッジルータE11は、受信したパケットのヘッダと自身のフローキャッシュ６０２を比較する。フローキャッシュ６０２には図６のエッジルータIDが"E11"となっているエントリが記載されている。パケットの宛先がルール５０２によりユーザA宛（＃a宛て）であるため、このエントリ（図６の1行目）がマッチし、そのアクション５０３としてカプセル化した上で、エッジルータE13宛に送信することが記載されている。そのため、エッジルータE11は、新たにIPヘッダを付与し、その宛先アドレスをエッジルータのアドレス"E13"に設定した上でコアネットワーク１に送信する（ステップ１１）。

そのパケットを受信したエッジルータE13は、同様にフローキャッシュ６０２を参照すると、図６の2行目のエントリ（宛先IP=E13（カプセル化）、宛先IP=#a）が該当するため、そのアクション５０３として、カプセル化を外し（デカプセル化）、物理リソースS2aに転送する（ステップ１２）。

物理リソースS2aにはDPI機能が割り当てられており、ユーザA宛てのパケットに対してDPI処理を実施する。DPI処理の例としては、セキュリティのチェックや、アプリケーションに対する帯域制御などがあるが、ここでは、何らかの制御を受けたとしても、パケット自体の転送は継続される。すなわち、パケットを廃棄するような処理は実施されないと仮定する。

物理リソースS2aで処理を受けたパケットは、エッジルータE13に戻され、再びエッジルータE13は自身のフローキャッシュ６０２を参照する。ここでは、図６の3行目（宛先IP=#a）が該当する。そのエントリのアクション５０３として、カプセル化してエッジルータE14宛に送信すると記載されているため、エッジルータE13は、パケットIPヘッダを付与し、その宛先アドレスを"E14"に設定した上で、コアネットワーク１に送信する（ステップ１３）。

以下同様に、パケットを受信したエッジルータE14は、フローキャッシュ６０２を参照し、図６の4行目に指定されたアクション５０３にデカプセル化が指定されているため、デカプセル化した上で、物理リソースS1bに送信する（ステップ１４）。物理リソースS1bでパケットカウント処理（パケット数、データ量のカウント）を実施された後、再びエッジルータE14にパケットが戻されると、当該パケットに基づいてフローテーブル４０２の、図６の行目を参照し、アクション５０３に基づいて、カプセル化した上でエッジルータE1に送信する（ステップ１５）。

最後に、パケットを受信したエッジルータE1は、フローキャッシュ６０２を参照し、図６の5行目に指定されたアクション５０３に基づいてデカプセル化した上で、ユーザAにパケットを送信する（ステップ１６）。

このように、フロー制御コントローラ１３で生成されたフローテーブル４０２（実際には、フローテーブル４０２の情報を受信したエッジルータが保持するフローキャッシュ６０２であるが、内容は同じ）に沿って、決められたアクションを実施することで、ISP２から受信したパケットを、DPIとパケットカウントの処理を実施した上で、ユーザAまで転送することができる。なお、図９のパケット転送手順では、エッジルータ間の転送の詳細については省略したが、前述のように、コアネットワーク１を転送する際には、別のIPヘッダによりカプセル化され、次に転送すべきエッジルータのアドレスが宛先として設定されているため、コアネットワーク１内のコアルータ７は、カプセル化された外側のIPヘッダのみを参照してパケットを転送すればよい。コアルータ７のルーティングテーブル（図示せず）は、通常のIPネットワークと同様にOSPF(Open Shortest Path First)やBGP(Border Gateway Protocol)などの既存のルーティングプロトコルで生成されていればよい。また、本実施の形態では、カプセル化の技術として、別のIPヘッダを付与するIPカプセル化（GREやIP in IP等）を想定したが、MPLSなどでもよい。その場合も、本実施の形態の変更は殆どなく、カプセル化やデカプセル化の対象が、IPヘッダではなく、MPLSなどの別のヘッダになるだけである。

最後に、図１０〜図１２を用いて、物理リソースに割り当てられていたネットワークサービス機能を、別の物理リソースに移動した場合の処理手順の例を示す。

ここでは、物理リソースS2aに割り当てられていたDPI機能を、新たな物理リソースであるS1cに移動したと仮定し、その移動によってフローテーブルが変更されるまでの処理手順を示す。

図１０は、本発明の一実施の形態におけるフローテーブルの更新手順のシーケンスチャートである。

まず、ネットワーク設計情報などの変更がリソーステーブル１１とサービス機能テーブル１０に通知され、それに伴って、リソーステーブル１１とサービス機能テーブル１０が更新される。ここでは、図１１（A）に示すように、まずサービス機能テーブル１０の、リソースID（物理リソース）がS2aのEPI機能（図１１（A）の２行目）を更新し、リソースIDを新たに割り当てた物理リソースS1cに変更する（ステップ１０１）。また、新たな物理リソースS1cが、エッジルータE11に接続されていることを示す情報を、図１１（B）の５行目に示すように、リソーステーブル１１に追加する（ステップ１０２）。

次に、フロー制御コントローラ１３は、更新されたリソーステーブル情報とサービス機能テーブル情報を受信（ステップ１０３〜１０４）し、フローテーブル４０２を更新する。図１２に更新後のフローテーブルを示す。本実施の形態では、リソースS2aに割り当てられていたDIP機能をS1cに移動したため、元のフローテーブルでリソースIDがS2aのDPI機能への転送に関わるフローエントリを検索して更新する。具体的には、エッジルータE11が受信したパケットをエッジルータE13に接続されている物理リソースS2aに転送することが記載されていた箇所を、代わりに物理リソースS1cへの転送に変更する。物理リソースS1cはエッジルータE11、すなわち、ISPからパケットを受信したエッジルータ自身に接続されているため、そのまま物理リソースS1cに転送するように変更する（図１２の１行目）。また、同様に、物理リソースS1cでDPI処理を施されたパケットをエッジルータE11が受信し、エッジルータE14に転送する行を追加する（図１２の２行目）。

このように、ネットワークサービス機能が、別の物理リソースへ移動した場合には、リソーステーブルとサービス機能テーブルを更新し、その変更部分に該当するフローエントリを更新することで、物理リソースが移動しても、パケットの転送経路もそれに応じて自動的に変更することができる。

なお、本実施の形態では、サービス機能種別として、DPI、パケットカウンタ、キャッシュを例として挙げたが、他のサービス機能、例えば、BRAS(Broadband Remote Access Server)機能、ファイアウォール、NAT(Network Address Translation)機能などでも同様に適用可能である。

なお、本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。

１ コアネットワーク
２ ISP
３ CSP
４、４ａ，４ｂ データセンタ拠点
５ インターネット
６ エッジルータ
７ コアルータ
８，８ａ、８ｂ ユーザ端末
９ 物理リソース
１０ サービス機能テーブル
１１ リソーステーブル
１２ ユーザ処理テーブル
１３ フロー制御コントローラ
１０１ サービス機能種別
１０２ サービス機能ＩＤ
１０３ リソースＩＤ
２０１ リソースＩＤ
２０２ エッジルータＩＤ
３０１ ユーザＩＤ
３０２ サービス
３０３ 処理
４０１ フローテーブル生成部
４０２ フローテーブル
４０３ フロー情報通知部
５０１ エッジルータＩＤ
５０２ ルール
５０３ アクション
６０１ フローテーブル受信部
６０２ フローキャッシュ
６０３ ネットワークインタフェース
６０４ スイッチファブリック

Claims (2)

1. コアネットワーク内にエッジルータ間をフルメッシュに接続可能なトンネルを有するキャリア網を仮想化するキャリア網の仮想化システムであって、
   前記コアネットワークに接続された複数のエッジルータと、
   データセンタ拠点内に配置され、ネットワークサービス機能を実現するための物理リソースと、
   前記エッジルータがパケットを転送する宛先及びパケットの処理方法を示すアクションを有するフローテーブルを作成し、該エッジルータに通知するフロー制御コントローラと、
   を有し、
   前記エッジルータは、
   前記フロー制御コントローラから前記フローテーブルの情報を取得して格納するフローキャッシュと、
   パケットが転送されてくると、前記フローキャッシュを参照して該パケットを、前記アクションに応じてカプセル化またはデカプセル化し、エッジルータ間に確立されたトンネルを介して前記フローテーブルのルールに示される宛先に転送する転送手段と、
   を有し、
   前記フロー制御コントローラは、
   物理リソースがどのエッジルータの配下にあるかを示すリソーステーブル、ユーザの契約情報に基づいて、どのサービスについて処理するのかを示すユーザ処理テーブルと、どの物理リソースにどのネットワークサービス機能を割り当てているかを示すサービス機能テーブルを取得し、該リソーステーブル、該ユーザ処理テーブル、該サービス機能テーブルの情報に基づいて、前記フローテーブルを生成するテーブル生成手段と、
   前記サービス機能が第１の物理リソースから第２の物理リソースに移動した場合に、移動情報に基づいて前記リソーステーブルと前記サービス機能テーブルを更新する手段と、
   前記更新された前記リソーステーブルと前記サービス機能テーブルの情報を取得し、更新された部分に該当するフローテーブルのエントリを更新するテーブル更新手段と、
   を有することを特徴とするキャリア網の仮想化システム。
2. コアネットワーク内にエッジルータ間をフルメッシュに接続可能なトンネルを有するキャリア網を仮想化するキャリア網の仮想化方法であって、
   前記コアネットワークに接続された複数のエッジルータと、
   データセンタ拠点内に配置され、ネットワークサービス機能を実現するための物理リソースと、
   前記エッジルータがパケットを転送する宛先及びパケットの処理方法を示すアクションを有するフローテーブルを作成し、該エッジルータに通知するフロー制御コントローラと、
   を有するシステムにおいて、
   前記エッジルータは、
   前記フロー制御コントローラから前記フローテーブルの情報を取得してフローキャッシュに格納するフローテーブル格納ステップと、
   パケットが転送されてくると、前記フローキャッシュを参照して該パケットを、前記アクションに応じてカプセル化またはデカプセル化し、エッジルータ間に確立されたトンネルを介して前記フローテーブルのルールに示される宛先に転送する転送ステップと、
   を行い、
   前記フロー制御コントローラにおいて、
   物理リソースがどのエッジルータの配下にあるかを示すリソーステーブル、ユーザの契約情報に基づいて、どのサービスについて処理するのかを示すユーザ処理テーブルと、どの物理リソースにどのネットワークサービス機能を割り当てているかを示すサービス機能テーブルを取得し、該リソーステーブル、該ユーザ処理テーブル、該サービス機能テーブルの情報に基づいて、前記フローテーブルを生成するテーブル生成ステップと、
   前記サービス機能が第１の物理リソースから第２の物理リソースに移動した場合に、移動情報に基づいて前記リソーステーブルと前記サービス機能テーブルを更新する手段と、
   前記更新された前記リソーステーブルと前記サービス機能テーブルの情報を取得し、更新された部分に該当するフローテーブルのエントリを更新するテーブル更新ステップと、
   を行うことを特徴とするキャリア網の仮想化方法。

Images