JP2015032932A - キャリア網における経路制御システム及び方法 - Google Patents

Abstract

【課題】 通常のIPルーティングでは実現できない、複数のNWサービス機能への経路制御を可能にする。
【解決手段】 本発明のフロー制御装置は、エッジルータがパケットに付与するためのフロー情報を生成し、フローテーブルに格納し、ユーザごとのフローテーブルの内容をエッジルータに送信する。エッジルータは、フロー情報を取得して一時記憶手段に格納し、パケットが転送されると、一時記憶手段のフローテーブルの内容に基づいて、ルールのマッチングを行い、パケットの処理方法に基づいて、当該パケットが経由すべきNWサービス機能を示す識別子を該パケットのヘッダに付与してトンネル技術を用いて転送する。サーバは、エッジルータから受信したパケットに付与されたヘッダの情報に基づいて振り分け、パケットからヘッダを取り除いて、該ヘッダが示すNWサービス機能に対応するVMに転送する。
【選択図】 図１

Description

本発明は、キャリア網における経路制御システム及び方法に係り、特に、ネットワークサービス機能が仮想化されたキャリア網において複数のネットワークサービス機能への経路制御を行うためのキャリア網における経路制御システム及び方法に関する。

サーバの仮想化技術により、従来は専用ハードウェアで実装されていたDPI(Deep Packet Inspection)やファイアウォール、キャッシュといったネットワークサービス機能（以下、「NWサービス機能」と記す）を、汎用サーバ上の仮想マシン（VM: Virtual Machine）として実現する検討が進んでいる（例えば、非特許文献１参照）。汎用サーバでNWサービス機能を実現することにより、専用ハードウェアに比べて装置コストの低減が見込めるほか、専用ハードウェアの開発が不要になることから、新サービスの迅速な開発・導入が実現できると期待されている。また、異なるNWサービス機能を、同一の汎用サーバで実現することで、NWサービス機能間のリソース共有が可能となり、需要や負荷状況に応じたリソース再配分によるリソース利用の効率化を図ることができる。

一方、NWサービス機能の仮想化のメリットを効果的に引き出すためには、ネットワーク側での制御を連動させる必要がある。従来のように、NWサービス機能が専用ハードウェアで実現されている場合には、ユーザのトラフィックの経路上に専用ハードウェアを設置し、ユーザのトラフィックに対する処理を実施していた。しかし、NWサービス機能が仮想化されると、それらを実現する汎用サーバは、データセンタ内に設置されることが想定される。通常のインターネット接続サービスやIPTVサービスなどでは、データセンタを経由するルートを通ることはないため、NWサービス機能を活用するためには、必要なトラフィックをデータセンタに設置された汎用サーバに引き込む必要がある。また、一般に、ユーザごとに契約しているサービスが異なることが想定されるため、ユーザごとのトラフィックを識別した上で、必要なユーザのトラフィックのみを、データセンタに設置された汎用サーバにルーティングする必要がある。さらには、複数のサービスを契約している場合、それらのサービスを提供する複数のNWサービス機能を経由する経路制御も必要となる。

このような経路制御を実現する技術としてOpenFlow（例えば、非特許文献２参照）がある。OpenFlowでは、予め定義したルールにマッチするトラフィックを「フロー」として認識し、フローごとに定められたアクション（転送、廃棄等の制限）を実行することができる。この特徴を利用し、例えば、ユーザ単位のトラフィックをフローと定義し、あるNWサービス機能を契約しているユーザのトラフィックだけをデータセンタ内の汎用サーバまで引き込む制御が可能である。しかし、これを実現するためには、経路上の全てのサーバに対して、フローのルールとアクションのセットを定義しなくてはならない。キャリア網規模でユーザ単位にこのような制御を実現しようとすると、ルータやスイッチに定義するルールの数がボトルネックとなり、現実的ではない。

"Network Function Virtualization - An Introduction, Benefits, Enablers, Challenges & Call for Action -", URL http://portal.etsi.org/NFV/NFV_White_Paper. pdf, 2013年5月30日検索 "Software-Defined Networking: The New Norm for Networks"(ONF white Paper), Open Network Foundation, April 13, 2012, URL: http://www.opennetworking. org/image/stories/downloads/sdn-resources/white-paper/wp-sdn/newnorm.pdf. 2013年5月30日検索

上記のようにNWサービス機能が仮想化されたキャリア網において、個々のユーザが契約するサービスに対応する１または複数のNWサービス機能に対して、ユーザのトラフィックを引き込むための経路制御技術が必要となる。これを実現するためには、これらのNWサービス機能は、ユーザの通信先となるインターネット上のサーバ等と、ユーザ端末の間に位置して何らかの機能を提供するものであるため、宛先IPアドレスしか参照しないIPルーティングによる制御は不可能である。機能面では、OpenFlowのように、自由にルータとアクションを設定できる技術が候補となるが、キャリア網全体でOpenFlowを適用するとルールの数が膨大となるなど、スケーラビリティの課題がある。

本発明は、上記の点に鑑みなされたもので、通常のIPルーティングでは実現できない、複数のNWサービス機能への経路制御を可能とするキャリア網における経路制御システム及び方法を提供することを目的とする。

一態様によれば、キャリア網のコアネットワーク、インターネット、データセンタ拠点、ユーザ端末を接続するエッジルータと、該データセンタ拠点に存在し、異なるネットワーク（NW）サービス機能を有する複数の仮想マシンを有するサーバと、フロー制御装置とを有するキャリア網におけるリソース制御システムであって、
前記フロー制御装置は、
前記エッジルータがパケットに付与するためのルールとパケットの処理方法を含むフロー情報を生成し、フロー情報記憶手段に格納するフローテーブル生成手段と、
ユーザごとの前記フロー情報記憶手段の内容を前記エッジルータに送信するフロー情報通知手段と、
を有し、
前記エッジルータは、
前記フロー制御装置から前記フロー情報記憶手段の内容を取得して一時記憶手段に格納するフロー情報受信手段と、
パケットが転送されると、前記一時記憶手段の内容に基づいて、ルールのマッチングを行い、前記パケットの処理方法に基づいてパケットに、当該パケットが経由すべきNWサービス機能を示す識別子を該パケットのヘッダに付与してトンネル技術を用いて転送する第１の転送手段と、
を有し、
前記サーバは、
前記エッジルータから受信した前記パケットに付与された前記ヘッダの識別子に基づいていずれかの仮想マシンに振り分ける仮想マシン振り分け手段と、
前記パケットから前記ヘッダの識別子を取り除いて、該ヘッダが示すNWサービス機能に対応する仮想マシンに転送するヘッダ除去手段と、
前記仮想マシンからパケットが転送された場合に、前記ヘッダの識別子を該パケットに再度付与し、カプセル化技術を用いて宛先に転送する第２の転送手段と、を有するリソース制御システムが提供される。

一態様によれば、キャリア網の入口にあるエッジルータにおいて、転送されたパケットがどのユーザ宛てのものかを識別して、パケットのヘッダに経由すべきNWサービス機能を示す識別子を付与し、IPトンネル技術を用いてNWサービス機能に対してパケットを転送することにより、NWサービス機能が仮想化され、汎用サーバ上で動作する状況において、ユーザのパケットの経路上には存在しない複数のNWサービス機能を経由する制御を実施できるようになる。

また、キャリア網の入口にあたるエッジルータでは、ユーザ単位のフローを識別する処理を実施するが、他のエッジルータやサーバ等では、ユーザ単位のフローを識別する重い処理を実施しなくてもよいため、大規模なキャリア網において、スケーラビリティを担保できる。

本発明の一実施の形態におけるネットワークの構成例である。 本発明の一実施の形態におけるNWサービス機能テーブルの構成例である。 本発明の一実施の形態におけるユーザ処理テーブルの構成例である。 本発明の一実施の形態におけるフロー制御コントローラの構成例である。 本発明の一実施の形態におけるフローテーブルの構成例である。 本発明の一実施の形態におけるエッジルータの構成例である。 本発明の一実施の形態におけるサーバの構成例である。 本発明の一実施の形態における動作のシーケンスチャート（その１）である。 本発明の一実施の形態における動作のシーケンスチャート（その２）である。 本発明の一実施の形態における動作のシーケンスチャート（その３）である。

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

本発明では、パケット自体に、そのパケットが経由すべきＮＷサービス機能を示す識別子を付与する。次に、経由するNWサービス機能へは、トンネル内でパケットをカプセル化するGRE等のIPトンネル技術を用いてパケットを転送することにより、キャリアのコア網は既存のIP網のままで対応できる。一方、NWサービス機能を実現するVMでは、識別子が付与されたパケットを解釈できないため、ハイパーバイザ上で動作する仮想ルータにおいて、識別子を付与したパケットを解釈し、識別子を外した上でVMに転送する機能を設ける。

本実施の形態では、コアネットワークにおけるトンネル技術としてIPトンネル（GREトンネル）を利用するが、エッジルータ間をフルメッシュに接続可能なトンネル技術であれば、MPLS(Multi Protocol Label Switching)等の他の技術でもよい。また、識別子として、独自に定義した「ラベル」を利用するが、MPLSラベルやIPアドレス等の既存のＩＤとなるものを、そのまま識別子として利用しても良い。

図１は、本発明の一実施の形態におけるネットワーク構成例を示す。

キャリアのコアネットワーク１には、インターネット２、データセンタ拠点３、及び、ユーザ端末４が接続されている。また、コアネットワーク１には、エッジルータ５とコアルータ６が存在し、エッジルータ５は、コアネットワーク１とインターネット２、データセンタ拠点３、ユーザ端末４をそれぞれ接続する。コアルータ６は、エッジルータ５との間の通信を担う。また、データセンタ拠点３内には、ゲートウェイルータ７、L2SW(Layer 2 Switch )８、サーバ９が存在する。このうち、サーバ９は、NWサービス機能を実現するリソースを提供するものであり、CPUやメモリ、ストレージ、ネットワークプロセッサなどを搭載するいわゆる、コンピューティング資源である。さらに、コアネットワーク１には、本発明の各種別制御を実現するために必要となるNWサービス機能テーブル１０、ユーザ処理テーブル１１、フロー制御コントローラ１２が存在する。

上記の構成のうち、本発明のポイントとなるテーブルやサーバ、フロー制御コントローラ等について説明する。

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

NWサービス機能テーブル１０は、各NWサービス機能を提供するVMが、どのNWサービス機能を提供しているか（NWサービス機能種別１０２）と、どのサーバに収容されているか（サーバアドレス１０３）、の情報を保持するテーブルである。なお、ラベル１０１は、ネットワーク全体でVMに一意に割り当てられた識別子である。

＜ユーザ処理テーブル１１＞
図３は、本発明の一実施の形態におけるユーザ処理テーブルの構成例である。

ユーザ処理テーブル１１は、ネットワークに収容されている各ユーザ（ユーザID３０１で識別）のパケットについて、どのNWサービス機能を、どのような順序で経由すべきかの処理順序（処理順序情報３０２）を格納するテーブルである。一般的には、このテーブルは、ユーザが契約するサービスを追加したり、変更したりする場合にアップデートされる。

＜フロー制御コントローラ１２＞
図４は、本発明の一実施の形態におけるフロー制御コントローラの構成例である。

フロー制御コントローラ１２は、NWサービス機能テーブル１０とユーザ処理テーブル１１の内容を取得し、各ユーザのパケットに付与する識別子の情報を生成した上で、フロー情報として、エッジルータ５に通知する。

フロー制御コントローラ１２は、フローテーブル生成部４０１、フローテーブル４０２、フロー情報通知部４０３から構成される。

フローテーブル生成部４０１は、NWサービス機能テーブル１０とユーザ処理テーブル１１の内容を取得し、これらのテーブルの情報に基づいて、エッジルータ５が用いるパケットに付与する識別子を生成し、フローテーブル４０２に格納する。

フロー情報通知部４０３は、エッジルータ５に対してユーザごとのフローテーブル４０２の情報を通知する。

図５は、本発明の一実施の形態におけるフローテーブルの構成例である。

フローテーブル４０２は、１エントリ（図５の１行に対応）で、１つのエッジルータ５が処理する１つのフローの処理内容を保持する。エッジルータID５０１は、該当のエントリがどのエッジルータのものであるかを示す。ルール５０２は、どのパケットにマッチするかの条件の定義であり、アクション５０３は、ルール５０２にマッチしたパケットに対する処理を示す。

＜エッジルータ５＞
図６は、本発明の一実施の形態におけるエッジルータの構成例である。

エッジルータ５は、基本的には一般的なエッジルータやスイッチを想定するが、ここでは、本発明の特徴的な機能のみを示す。

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

＜サーバ９＞
図７は、本発明の一実施の形態におけるサーバの構成例である。

当該サーバ９は、NWサービス機能をVMとして収容するサーバであり、一般的な仮想化されたサーバと同じように、ハイパーバイザ７０２の上で、複数のVM７０１が動作する構成である。本実施の形態において特徴的なところは、ハイパーバイザ７０２上に仮想ルータ７０３を配置し、その内部に、ラベルキャッシュ７０５とVM振り分け部７０６を有する点である。ラベルキャッシュ７０５は、NWサービス機能テーブル１０と同じ構成であり、そのコピーをサーバ９のラベルキャッシュ７０５で保持する。VM振り分け部７０６は、外部からNIC(Network Interface Card）７０４を通して入力されたパケットのヘッダを解析し、ヘッダに付与されているラベルから各サーバのNIC７０４に付与されているサーバアドレスをラベルキャッシュ７０５を参照して取得し、そのパケットをどのVM７０１に振り分けるかを決めた上で、一時的にヘッダを取り除いてVM７０１に転送する。このとき、取り除いたヘッダをメモリに格納しておく。逆に、VM７０１からパケットが転送されてきたら、VM振り分け部７０６でヘッダを再び付与し、次の転送するNWサービス機能を保持するサーバを宛先IPアドレスとしたIPヘッダでカプセル化して送信する。

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

図８は、本発明の一実施の形態における動作のシーケンスチャート（その１）であり、フロー制御コントローラ１２がフローテーブル４０２を生成し、エッジルータ５に送信するまでの手順を示す。

まず、本実施の形態で仮定するNWサービス機能テーブル１０とユーザ処理テーブル１１の内容を説明する。NWサービス機能テーブル１０は、図２に示す内容になっているものとする。図２では、データセンタ拠点３ａにあるサーバＲ１にDPIとファイアウォールの機能が存在する。また、データセンタ拠点３ｂにあるサーバＲ２にキャッシュ機能、サーバＲ３にDPI機能が存在する。これらの情報は、一般には、キャリアがNW設計情報として入力するものであり、VMを追加、削除したり、あるいは、VMを別のサーバに移動したりした際に更新される（ステップ１）。

一方、ユーザ処理テーブル１１は、図３に示す内容であると仮定する。ユーザＡは、ファイアウォールとキャッシュのサービスを契約しており、この順にパケットを処理する。ユーザＢはDPIのみを契約している。これらの情報は、ユーザの新規契約や契約変更を機に更新される（ステップ２）。

次に、フロー制御コントローラ１２は、NWサービス機能テーブル１０の情報とユーザ処理テーブル１１の情報をそれぞれ収集する（ステップ３，４）。

その後、フロー制御コントローラ１２は、以下のようにフローテーブル４０２を生成する。

ここでは、ユーザＡの例で説明する。

ユーザ処理テーブル１１（図２）のユーザＡの行（ユーザIDがＡの行）を参照すると、インターネット２から入ってきたパケットを、ファイアウォール、キャッシュの順に転送し、最後のユーザＡに送信するという処理順序が記載されている。したがって、NWサービス機能テーブル１０を参照し、ファイアウォール機能を示すラベルである＃１１と、キャッシュ機能を示すラベルである＃２１を、＃１１、＃２１の順で、パケットに付与するアクションを記載する。

さらに、最初の転送先となるファイアウォールが存在するサーバ９のアドレス（＃Ｒ１）をNWサービス機能テーブル１０（図２）から取得し、＃Ｒ１を宛先IPアドレスとするIPヘッダでカプセル化するというアクションを記載する。なお、ルールについては、ユーザＡのパケットであることが識別できればよいため、宛先IPアドレスがユーザＡのアドレス（＃ａ）と等しいという条件のみでよい。このようにしてフローテーブル４０２（図５）のユーザＡの行を生成する。

ユーザＢに対するフローテーブル４０２も同様に生成すると、図５の２行目のようになる。

なお、図２のNWサービス機能テーブル１０を見ると、DPI機能に関しては、サーバＲ１とサーバＲ３に存在することがわかるが、このような場合にどちらを選択するかについては、何らかの方法で決める必要がある。例えば、ユーザＢが収容されているエッジルータ５になるべく近いサーバを選択する、あるいは、負荷状況が小さいサーバを優先的に選択する、といった方式が考えられる。

最後に、フロー制御コントローラ１２は、生成したフローテーブル４０２を、エッジルータ５に送信する（ステップ６）。送信する先は、下りパケットであればインターネット２等からキャリア網に流入するエッジルータ５（Ｅ１１）、上りパケットであれば、ユーザを収容しているエッジルータ５（Ｅ１）である。本実施の形態では、インターネットからユーザ宛ての下りパケットの例を示しているので、インターネット２からキャリア網の入り口に当たるエッジルータ"Ｅ１１"に送信する。

一方、NWサービス機能テーブル１０は、テーブルの内容を、各サーバ９に送信する（ステップ７）。NWサービス機能テーブル１０の情報を受信したサーバ９は、ラベルキャッシュ７０５に当該情報をそのまま格納する。

図９は、本発明の一実施の形態における動作のシーケンスチャート（その２）、図１０は、本発明の一実施の形態における動作のシーケンスチャート（その３）であり、実際のパケットの流れを示す。

インターネット２からユーザＡ宛のパケット（宛先IP=#a）がエッジルータ５（Ｅ１１）に入ってくると（ステップ１１）、エッジルータ５（Ｅ１１）は、自身のフローキャッシュ６０２を参照する。ここでは、フローキャッシュ６０２の内容は、図５のフローテーブル４０２と同様である。フローキャッシュ６０２に複数あるエントリのうち、ルールが合致するものを検索すると、１行目の（宛先IP＝#a）のルールが該当する。アクションを参照すると、「ラベル＃１２、＃２１を付与、宛先IP=#R1のIPヘッダでカプセル化して送信」とあるため、パケットにラベル＃１２、＃２１を付与した上で、宛先IPアドレスを＃Ｒ１に設定したIPヘッダでカプセル化し、転送する（ステップ１２）。

コアネットワーク１内は、カプセル化されたIPパケットのIPヘッダを参照して、通常のIPフォワーディングで転送され、やがて当該パケットはサーバ９（Ｒ1）に到達する（ステップ１３）。

サーバ９（Ｒ１）内の詳細な処理手順については図１０を用いて説明する。

サーバ９（Ｒ１）にパケットが到達すると、仮想ルータ７０３がそれを受信する（ステップ２１）。仮想ルータ７０３では、一時的にパケットに付与されているヘッダ情報を削除し（ステップ２２）、削除したヘッダ情報をメモリ（図示せず）内に保持した上で、適切なVM７０１にパケットを転送する（ステップ２３）。ここで、メモリ内の一時的に削除したヘッダ情報に含まれるラベルを参照することで、転送先のVMを選択することができる。パケットを受信したVM７０１は、パケットに対して処理を実施し（ステップ２４）、仮想ルータ７０３にパケットを返送する（ステップ２５）。VM７０１からパケットを受信した仮想ルータ７０３は、先の転送先を決めるために、メモリ内に保存したヘッダ情報のラベルのうち、先頭ラベル（先ほど転送したVM７０１を示すラベル）を削除し、２番目のラベルを参照する。２番目のラベルは＃２１であるが、サーバ９（Ｒ１）内にはラベル＃２１に相当するVMは存在しないため、別のサーバへパケットを転送する必要がある。転送先のサーバのアドレスを取得するため、仮想ルータ７０３は、ラベルキャッシュ７０５をラベルに基づいて検索する（ステップ２６）。

ラベルキャッシュ７０５の内容は、NWサービス機能テーブル１０のコピーであるため、図２と同様である。図２においては、ラベル＃２１で検索すると、３行目が該当し、サーバアドレスは＃Ｒ２と記載されていることがわかる（ステップ２７）。そこで、仮想ルータ７０３は、先頭のラベル（＃１２）を除去した残りのラベルをパケットに付与し、さらに、次の転送先であるサーバＲ２のアドレス＃Ｒ２を宛先IPアドレスとするIPヘッダでカプセル化して（ステップ２８）、ネットワークに転送する（ステップ２９）。

上記のサーバ９の処理実行後、図９の処理に戻り、ステップ１４以降のパケットの手順を説明する。

サーバ９（Ｒ１）からパケットが送信されると（ステップ１４）、次の宛先となるサーバ９（Ｒ２）まで転送される（ステップ１５）。サーバ９（Ｒ２）においても、さきほどのサーバ９（Ｒ１）と同様の処理を（図１０と同様の処理）を実施する。但し、サーバ９（Ｒ２）の処理では、先頭のラベルを除去すると、ラベルがなくなってしまう。このような場合には、これ以上経由すべきNWサービス機能がないことを示しているため、図１０のステップ２８の処理は実施せず、元のパケットのままで転送する（ステップ１６）。

最後にパケットはユーザＡの端末４に到着する（ステップ１７）。

ここまでの説明でわかるように、キャリア網の入口にあたるエッジルータ５（Ｅ１１）以外のエッジルータ５（Ｅ１，Ｅ１２，Ｅ１３）、コアルータ６、データセンタ拠点３ａ、３ｂ内のゲートウェイルータ７、L2SW８は、単なるIP転送処理だけを実施すればよく、ユーザを意識した処理は不要である点が本発明の特徴である。

なお、本実施の形態では、NWサービス機能を収容するサーバ内の仮想ルータに、ラベルやカプセル化の処理機能を持たせたが、これをエッジルータに実装してもよい。その場合には、カプセル化するIPヘッダの宛先アドレスは、サーバ９ではなく、エッジルータ５となる。このとき、サーバ９では、例えば、データセンタ拠点３内でVM単位にVLANを設定して、エッジルータとサーバ間を接続する一般的なデータセンタの通信形態となる。この場合サーバ９では、VMに対してVLANを設定しておくだけでよく、特別な処理を必要としない。

上記のように、本発明によれば、通常のIPルーティングでは実現できない、複数のNWサービス機能への経路制御が可能となる。また、キャリア網の入口となるエッジルータ等でのみ、パケットのフローを識別すればよいため、OpenFlowのようにパケットが経由するノード全てにフローのステートを保持させる必要がなくなり、スケーラビリティが向上する。

上記の実施の形態におけるフロー制御コントローラ１２、エッジルータ５、サーバ９の各動作をプログラムとして構築し、フロー制御コントローラ、エッジルータ、サーバとして利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることが可能である。

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

１ コアネットワーク
２ インターネット
３ データセンタ拠点
４ ユーザ端末
５ エッジルータ
６ コアルータ
７ ゲートウェイルータ
８ L2SW
９ サーバ
１０ NWサービス機能テーブル
１１ ユーザ処理テーブル
１２ フロー制御コントローラ
１０１ ラベル
１０２ NWサービス機能種別
１０３ サーバアドレス
３０１ ユーザＩＤ
３０２ 処理順序情報
４０１ フローテーブル生成部
４０２ フローテーブル
４０３ フロー情報通知部
５０１ エッジルータID
５０２ ルール
５０３ アクション
６０１ フローテーブル受信部
６０２ フローキャッシュ
６０３ ネットワークインタフェース
６０４ スイッチファブリック
７０１ VM(NWサービス機能)
７０２ ハイパーバイザ
７０３ 仮想ルータ
７０４ NIC(Network Interface Card)
７０５ ラベルキャッシュ
７０６ VM振り分け部

Claims (6)

1. キャリア網のコアネットワーク、インターネット、データセンタ拠点、ユーザ端末を接続するエッジルータと、該データセンタ拠点に存在し、異なるネットワーク（NW）サービス機能を有する複数の仮想マシンを有するサーバと、フロー制御装置とを有するキャリア網におけるリソース制御システムであって、
   前記フロー制御装置は、
   前記エッジルータがパケットに付与するためのルールとパケットの処理方法を含むフロー情報を生成し、フロー情報記憶手段に格納するフローテーブル生成手段と、
   ユーザごとの前記フロー情報記憶手段の内容を前記エッジルータに送信するフロー情報通知手段と、
   を有し、
   前記エッジルータは、
   前記フロー制御装置から前記フロー情報記憶手段の内容を取得して一時記憶手段に格納するフロー情報受信手段と、
   パケットが転送されると、前記一時記憶手段の内容に基づいて、ルールのマッチングを行い、前記パケットの処理方法に基づいてパケットに、当該パケットが経由すべきNWサービス機能を示す識別子を該パケットのヘッダに付与してトンネル技術を用いて転送する第１の転送手段と、
   を有し、
   前記サーバは、
   前記エッジルータから受信した前記パケットに付与された前記ヘッダの識別子に基づいていずれかの仮想マシンに振り分ける仮想マシン振り分け手段と、
   前記パケットから前記ヘッダの識別子を取り除いて、該ヘッダが示すNWサービス機能に対応する仮想マシンに転送するヘッダ除去手段と、
   前記仮想マシンからパケットが転送された場合に、前記ヘッダの識別子を該パケットに再度付与し、カプセル化技術を用いて宛先に転送する第２の転送手段と、
   を有することを特徴とするキャリア網におけるリソース制御システム。
2. 前記仮想マシンごとに一意に付与されるラベルと、前記サーバ内の仮想マシンごとのNWサービス機能種別と、該仮想マシンがどのサーバに収容されているかのサーバアドレス情報を格納したNWサービス機能記憶手段と、
   ユーザごとのパケットのNWサービス機能の処理順序情報を格納したユーザ処理記憶手段と、を含み、
   前記フロー制御装置の前記フローテーブル生成手段は、
   前記ユーザ処理記憶手段の前記処理順序情報に基づいて、前記NWサービス機能記憶手段の前記ラベル、前記NWサービス機能種別からアクションを生成し、該NWサービス機能記憶手段の前記サーバアドレスを宛先として前記フロー情報記憶手段に格納する手段を含む
   請求項１記載のキャリア網におけるリソース制御システム。
3. 前記サーバは、
   前記パケットに付与されている前記ヘッダの情報を削除し、削除した該ヘッダの情報を一時的に保持し、転送先の仮想マシンを選択する際に、一時的に保持されている該ヘッダの情報に含まれるラベルを参照する仮想ルータを含む
   請求項１記載のキャリア網におけるリソース制御システム。
4. キャリア網のコアネットワーク、インターネット、データセンタ拠点、ユーザ端末を接続するエッジルータと、該データセンタ拠点に存在し、異なるネットワーク(NW)サービス機能を有する複数の仮想マシンを有するサーバと、フロー制御装置とを有するシステムにおけるリソース制御方法であって、
   前記フロー制御装置が、
   前記エッジルータがパケットに付与するためのルールとパケットの処理方法を含むフロー情報を生成し、フロー情報記憶手段に格納するフローテーブル生成ステップと、
   前記フロー制御装置が、ユーザごとの前記フロー情報記憶手段の内容を前記エッジルータに送信するフロー情報通知ステップと、
   を行い、
   前記エッジルータが、
   前記フロー制御装置から前記フロー情報記憶手段の内容を取得して一時記憶手段に格納するフロー情報受信ステップと、
   パケットが転送されると、前記一時記憶手段の内容に基づいて、ルールのマッチングを行い、前記パケットの処理方法に基づいてパケットに、当該パケットが経由すべきNWサービス機能を示す識別子を該パケットのヘッダに付与してトンネル技術を用いて転送する第１の転送ステップと、
   を行い
   前記サーバが、
   前記エッジルータから受信した前記パケットに付与された前記ヘッダの識別子に基づいていずれかの仮想マシンに振り分ける仮想マシン振り分けステップと、
   前記パケットから前記ヘッダの識別子を取り除いて、該ヘッダが示すNWサービス機能に対応する仮想マシンに転送するヘッダ除去ステップと、
   前記仮想マシンからパケットが転送された場合に、前記ヘッダの識別子を該パケットに再度付与し、カプセル化技術を用いて宛先に転送する第２の転送ステップと、
   を行うことを特徴とするキャリア網におけるリソース制御方法。
5. 前記仮想マシンごとに一意に付与されるラベルと、前記サーバ内の仮想マシンごとのNWサービス機能種別と、該仮想マシンがどのサーバに収容されているかのサーバアドレス情報を格納したNWサービス機能記憶手段と、
   ユーザごとのパケットのNWサービス機能の処理順序情報を格納したユーザ処理記憶手段と、を含むフロー制御装置が、
   前記フローテーブル生成において、
   前記ユーザ処理記憶手段の前記処理順序情報に基づいて、前記NWサービス機能記憶手段の前記ラベル、前記NWサービス機能種別からアクションを生成し、該NWサービス機能記憶手段の前記サーバアドレスを宛先として前記フローテーブルに格納する
   請求項４記載のキャリア網におけるリソース制御方法。
6. 前記サーバが、前記パケットに付与されている前記ヘッダの情報を削除し、削除した該ヘッダの情報を一時的に保持し、転送先の仮想マシンを選択する際に、一時的に保持されている該ヘッダの情報に含まれるラベルを参照する
   請求項４記載のキャリア網におけるリソース制御方法。

Images