JP2017022579A - 通信システム、通信ノード、および通信システムにおける代替処理方法 - Google Patents

Abstract

【課題】障害が発生した機能を他のデータセンタで再開させる際、他のデータセンタを収容する通信ノードに該機能の再開を認識させる。【解決手段】複数の仮想マシンVMを備え、仮想マシン上で所定の機能SFを実行するサーバ装置を含むデータセンタと、データセンタを収容し、受信したパケットを該パケットの記載事項に従って他の通信ノードあるいは仮想マシンに転送して所定の機能を実行させる通信ノードと、通信ノードやデータセンタを管理する管理装置と、を含む通信システムである。通信ノードは、所定の機能について死活監視をしており、所定の機能が停止していると判断した場合、所定の機能を実行する仮想マシンへ転送すべきパケットを他のデータセンタを収容する他の全通信ノードへ転送（Flooding）すると共に、所定の機能が停止したことを管理装置へ通知する。【選択図】図７Ｂ

Description

本発明は、通信システムの高可用性に関し、更に詳しくは、通信装置内データベース更新時間の短縮方法に関する。

本技術分野の背景技術として、ファイアウォール、ロードバランサ等のService Function（SF）を、汎用サーバ内の仮想マシン（VM: Virtual Machine）上で実現するNFV（Network Function Virtualization）が存在する。NFVのユースケースとして、フロー毎に適用するSFを柔軟に組み替え可能とするService Function Chaining（SFC）が提唱され、IETF（Internet Engineering Task Force）で標準化に向けた議論が為されている。

図１は、ユーザ端末８０−１〜８０-Ｎを、通信システム１０を介して、コンテンツサーバ９０−１〜９０−２に接続するシステムの構成図である。図１へ示すように、SF６０をデータセンタ（DC）３０内のVM５０に集約するSFCでは、入力パケットのヘッダ情報に基づいてSFCドメイン境界ノード（CL: Classifier）２０−Ａ，２０−Ｄが、フローを分類する。ドメイン境界ノードCL２０−Ａ，２０−Ｄは、フロー毎に適用するSF６０のchaining状態（適用されるSFの連鎖）を示す識別子（Path ID）やSFCドメイン内の経由SF数に基づく情報（SF Index）等のマッピングを伴うパケットのカプセル化処理を実行する。その後、カプセル化処理を施したパケットをDC収容ノード（SFF: Service Function Forwarder）２０−Ｂ，２０−Ｃに向けて転送する。

SFF２０−Ｂ，２０−Ｃは、CL２０−Ａ，２０−Ｄでoriginalパケット（送信元の例: ユーザ端末８０、コンテンツサーバ９０）に付加されたヘッダの内、SFC専用ヘッダ（NSH: Network Service Header）記載のPath IDとSF Indexに基づいてトラフィックを転送する。即ちSFF２０−Ｂ，２０−Ｃは、パケットのアドレス情報を用いないトラフィック転送を実施する（非特許文献１参照）。図１の通信ノード２０−Ａ及び２０−Ｄは、基本的にはCLの機能を備えるものだが、SFFの機能も備えることが可能である。通信ノード２０−Ｂ及び２０−Ｃは、SFFの機能を備えている。

上記のようなトラフィック転送では、DC３０内にて、VM５０のトラブル等により当該VM上の実行SF６０が停止状態に陥った際、SFCドメイン１００を構成するSFF装置内のトラフィック転送用データベース（SFF-Table）更新に関し、OSI参照モデルにおけるデータリンク層やネットワーク層のプロトコルは作用しない。上記のような状態が生じた場合への備えとして、予めバックアップ用のSF６０を稼働させると共にSFF-Tableへ迂回路情報を設定し、サービス寸断時間の縮減を図る手法が提案されている（非特許文献２参照）。

更に、NFVの標準化を推進しているETSI（European Telecommunications Standards Institute）では、仮想ネットワークにおける通信路VNFFG°(Virtualized°Network°Function°Forwarding°Graph)°に関して、トポロジの変更を想定した通信路(Path)の構成要素を定義している（非特許文献４）。

P. Quinn，et al.，"Network Service Header，"draft-quinn-sfc-nsh-05.txt，IETF Internet Draft，January 2015 T. Kang，et al.，"Failover for Service Function Chaining，"draft-kang-sfc-failover-01.txt，IETF Internet Draft， October 2014 P. Quinn， et al.，"Generic Protocol Extension for VXLAN"，draft-quinn-vxlan-gpe-03.txt，IETF Internet Draft，July 2014 "ETSI GS NFV-MAN 001 v1.1.1 (2014-12)，"ETSI GROUP SPECIFICATION，http://www.etsi.org/deliver/etsi_gs/NFV-MAN/001_099/001/01.01.01_60/gs_NFV-MAN001v010101p.pdf

非特許文献２では、迂回路未設定時に障害発生SFをバイパスさせることで通信途絶を回避し、End-to-Endの通信をサポートする。しかし、現用系と待機系の間で同期処理が必要なセッション状態を管理するSF（例えばNAT: Network Address Translation）に関しては対象外で、通信途絶状態が生じる。障害発生後の対処はドメイン管理者に委ねる為、通信途絶状態からの回復に要する時間は管理者次第である。また、障害発生SFをSFCドメイン内の異なるDCで再開させる場合、迂回路の設定等を管理者に委ねる為、設定ミスによる通信途絶状態が継続する可能性を排除できない問題を抱えている（管理者の負荷抑制も考慮されていない）。

非特許文献４では、フロー毎に適用するSFのchaining(Path)をDescriptorとして定義しているが、複数PathのDescriptor定義間のマイグレーション手段には言及していない。

以上から、本発明の目的は、上記課題の解決に向け、障害発生SFを他のDCで再開させる際、前記他のDCを収容するSFFにSFの再開を認識させることに加え、SFCドメインを構成する各SFFにSFF-Tableを素早く自動で更新させる方式を提供することである。

上記課題を解決するために、本願は上記課題を解決する手段を複数含んでいるが、その一例を挙げるならば、複数の仮想マシン（VM）を備え、仮想マシン上で所定の機能（SF）を実行するサーバ装置を含むデータセンタと、データセンタを収容し、受信したパケットをパケットの記載事項に従って他の通信ノードあるいは仮想マシンに転送して所定の機能を実行させる通信ノード（SFF）と、通信ノードやデータセンタを管理する管理装置と、を含む通信システムである。このシステムでは、通信ノードは、所定の機能について死活監視をしており、所定の機能が停止（あるいは機能不全等）していると判断した場合、所定の機能を実行する仮想マシンへ転送すべきパケットを他のデータセンタを収容する他の複数の通信ノードへ転送（Flooding）すると共に、所定の機能が停止したことを管理装置へ通知する。

さらに好ましい態様では、他の通信ノードは、Floodingパケットを受信すると、収容する他のデータセンタ内のサーバ装置が備える仮想マシンに対してパケットを転送（Flooding）する。

別の好ましい態様では、管理装置は、通知を受信すると、所定の機能を実行すべき仮想マシンを管理対象のデータセンタ内から特定し、特定された仮想マシンに所定の機能を実行させる。

別の好ましい態様では、特定された仮想マシンは、通信ノードから転送されたパケットに対して所定の機能を実行して、通信ノードに応答する。通信ノードは、応答を受信することにより所定の機能が復旧したと判断し、復旧したことを通知するメッセージを自身以外の通信ノードへ送信し、メッセージを受信したノードが、メッセージ記載内容に基づいて自装置内の状態を更新する。

本発明の他の一側面は、管理装置と、仮想マシン上で所定の機能を実行する複数のデータセンタと、データセンタの其々に対応付けられる複数の通信ノードを備える通信システムにおける、通信ノードである。この通信ノードは、入出力部と、処理部と、記憶部を備える。処理部は、受信したパケットをパケットの内容に基づいて他の通信ノードあるいは仮想マシンに送信して所定の機能を実行させる送信部と、自分が対応付けられるデータセンタの所定の機能の死活監視を行う監視部と、所定の機能が停止していると判断した場合、所定の機能を実行する仮想マシンへ送信すべきパケットを、他のデータセンタに対応付けられる他の複数の通信ノードへFloodingパケットとして転送する転送部と、所定の機能が停止したことを管理装置へ通知する通知部とを有する。

本発明の他の一側面は、複数のデータセンタと通信ノードを含む通信システムであって、複数の第１の仮想マシンを備え、受信したパケットに基づいて該第１の仮想マシン上で所定の機能を実行する第１のデータセンタと、第１のデータセンタを収容し、受信したパケットを他の通信ノードあるいは第１の仮想マシンに送信する第１の通信ノードと、複数の第２の仮想マシンを備え、受信したパケットに基づいて該第２の仮想マシン上で所定の機能を実行する第２のデータセンタと、第２のデータセンタを収容し、受信したパケットを他の通信ノードあるいは第２の仮想マシンに送信する第２の通信ノードと、通信ノードおよびデータセンタを管理する管理装置と、を備える通信システムにおける代替処理方法である。この方法では、第１の通信ノードが、第１の仮想マシンのいずれかが所定の機能の実行に支障があるとき、第１の仮想マシンへ送信すべきパケットを第２の通信ノードへFloodingパケットとして転送すると共に、所定の機能の実行に支障があることを管理装置へ通知する第１のステップと、第２の通信ノードが、受信したFloodingパケットを、第２の仮想マシンへ転送する第２のステップと、管理装置が、実行に支障が生じた所定の機能を代行させるべき通信システム内の他の仮想マシンに、機能の実行開始を指示する第３のステップと、第２の通信ノードが、第２の仮想マシンのいずれかが実行開始の指示により、Floodingパケットに基づいて所定の機能を実行した結果を、第１の通信ノードに送信する第４のステップと、を実行する。

本発明のさらに具体的な形態では、第２のデータセンタと第２のノードを複数組備える。

本発明の構成を採ることにより、特にDCを跨ったSFの移動に関し、通信システムに存在するSFFやCLが備えるトラフィック転送用のデータベースを管理者に更新させる方式と比べて高速に更新可能となり、通信システムの高可用化を提供可能となる。

通信システム１０と通信システムに接続される装置の構成図 通信ノード２０−Ａが備えるフロー分類用データベースの構成例の表図 通信ノード２０−Ａ、２０−Ｄにて生成されるouterヘッダの構成例の概念図 通信ノード２０−Ｂが備えるサービス分類用データベースの構成例の表図（その１） 通信ノード２０−Ｄが備えるフロー分類用データベースの構成例の表図 SFCを適用されたEnd-to-End通信の概略図 SFCを適用されたEnd-to-End通信のシーケンス図 DCを収容する通信ノード２０−ＢによるVM死活監視の概略図 SFCを適用されたEnd-to-End通信の障害発生時におけるシーケンス図（その１） VMトラブル等に起因する通信途絶状態の概略図 DCを収容する通信ノード２０−Ｂによる管理装置７０へ対するVMトラブル発生の旨を通知するメッセージ送付の概略図 通信ノード２０−Ｂが備えるサービス分類用データベースの構成例の表図（その２） SFCドメインFloodingの概略図 DC内Floodingの概略図 通信ノード２０−Ｃが備えるFloodingパケット用データベースの構成例の表図 管理装置７０からVM-C2に対するSF起動指示の概略図 SF-B2の再開によるEnd-to-End通信復旧を示す概略図 通信ノード２０−ＣによるSF-B2開始を通知するメッセージ送付の概略図 SFCを適用されたEnd-to-End通信の障害発生時におけるシーケンス図（その２） 通信ノード２０−Ｃが備えるFloodingパケット用データベース及びサービス分類用データベースの構成例の表図（その１） 通信ノード２０−Ｂが備えるサービス分類用データベースの構成例の表図（その３） 復旧したEnd-to-End通信の概略図 通信ノード２０−Ｂによる特定パケットの次転送先を通知するメッセージ送付の概略図 通信ノード２０−Ｃが備えるFloodingパケット用データベース及びサービス分類用データベースの構成例の表図（その２） 最適化されたEnd-to-End通信の概略図 SFCドメイン内の各通信ノード２０が、パケットの転送に用いるデータベースを更新したことを伝える為のメッセージを、（事後に）管理装置へ通知する概略図 本発明の実施例の通信ノードを説明するブロック図

実施の形態について、図面を用いて詳細に説明する。ただし、本発明は以下に示す実施の形態の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。

以下に説明する発明の構成において、同一部分又は同様な機能を有する部分には同一の符号を異なる図面間で共通して用い、重複する説明は省略することがある。

本明細書等における「第１」、「第２」、「第３」などの表記は、構成要素を識別するために付するものであり、必ずしも、数または順序を限定するものではない。また、構成要素の識別のための番号は文脈毎に用いられ、一つの文脈で用いた番号が、他の文脈で必ずしも同一の構成を示すとは限らない。また、ある番号で識別された構成要素が、他の番号で識別された構成要素の機能を兼ねることを妨げるものではない。

図面等において示す各構成の位置、大きさ、形状、範囲などは、発明の理解を容易にするため、実際の位置、大きさ、形状、範囲などを表していない場合がある。このため、本発明は、必ずしも、図面等に開示された位置、大きさ、形状、範囲などに限定されない。

本明細書で引用した刊行物、特許および特許出願は、そのまま本明細書の説明の一部を構成する。

本明細書において単数形で表される構成要素は、特段文脈で明らかに示されない限り、複数形を含むものとする。

＜１．システム構成例＞
ここでは、従来技術との比較を容易にする為，本発明を、主に通信ネットワーク上でパケット中継を担う図１の通信システム１０に適用した場合について説明する。パケット中継とは、通信ネットワークを流れるパケットを受信し、受信パケットの経路を決定する動作をいう。但し、本発明の効果を奏する限り、適用する装置、パケットの種類は此れに限られない。

図１は、本発明による通信システム１０と通信システムに接続される装置の構成図である。ユーザ端末８０−１〜８０−Ｎを、通信システム１０を介して、コンテンツサーバ９０−１〜９０−２に接続している。

通信システム１０は、受信したパケットの記載情報に基づいて該パケットを送信する通信ノード２０−ｉ（ｉ＝Ａ〜Ｄ）と、少なくとも１台以上のサーバ装置を含むデータセンタ（DC）３０−ｉ（ｉ＝Ｂ〜Ｃ）と、複数の仮想マシン（VM）５０を備えて仮想マシン上で所定の機能（SF）６０を実行するサーバ装置４０−ｉ（ｉ＝Ｂ〜Ｃ）と、通信ノード２０やデータセンタ３０を管理する管理装置７０とから構成される。

通信システム１０から管理装置７０を除いたドメインを、SFC（Service Function Chaining）ドメイン１００と呼ぶことにする。

SFCドメイン１００を構成する要素について説明する。SFCドメイン１００の始点では、このドメインに入力されたパケットを分類し、柔軟に組み替え可能な前記SFを適用させる。具体的には、ドメイン境界に配置される通信ノード２０（図１の通信ノード２０−Ａ、２０−Ｄが該当）にて、入力パケット（後述するoriginalパケット４００）に対し、SFCドメイン１００内におけるSF通過順序を示すNSHを含んだouterヘッダ３００を付加するか否かを判定する。付加する場合、入力パケットにouterヘッダ３００を付加してからSFCドメイン１００内へ送信する。付加しない場合は入力パケットにouterヘッダ３００を付加しないで転送する。

図２は、通信ノード２０−Ａ、２０−Ｄが備えるフロー分類用データベース２１０の構成例である。通信ノード２０−Ａ及び２０−Ｄでは、SFCドメイン１００の外から入力されるパケットを分類する際、フロー分類用データベース２１０を検索する。このフロー分類用データベース２１０は、CL装置内におけるトラフィック転送用のデータベース（CL-Table）に対応する。本実施例では、CL-Tableの高速自動更新も対象とすることができる。

フロー分類用データベース２１０は、入力されたフロー情報２１０１に対して、Path ID及びSF Index２１０２、パケット送信先情報２１０３を検索可能としている。

検索を実行した結果、検索キーに一致する比較条件（図２では、一般的に用いられる5-tupleを例示）が存在する場合、検索結果を用いてouterヘッダを生成する。一致する条件が存在しない場合、当該パケットを廃棄するのが適当である。

検索結果には、前述のNSHを構成する為のPath ID及びSF Index２１０２、パケット送信先情報（次転送先装置MACアドレス、トンネル終点IPv4アドレス、送信I/F）及びその他の情報（ユーザ識別子）２１０３を含む。フロー分類用データベース２１０では、トンネル終点IPv4アドレスとして、SFCドメイン１００を構成する各ノード２０のIPv4アドレスを用いる。

図３に、通信ノード２０−Ａ、２０−Ｄにて、フロー分類用データベース２１０を検索した結果を用いて生成される、outerヘッダ３００の例を示す。outerヘッダ３００は、非特許文献１と非特許文献３に記載されるNSH等のタグを用いて表現している。

Outerヘッダ３００のMACアドレス３１０は、フロー分類用データベース２１０記載のパケット送信先情報に含まれる次転送先装置のMACアドレスを宛先MACアドレスとし、通信ノード２０−Ａ或いは２０−ＤのMACアドレスを送信元MACアドレスとし、type値としてIPv4を示す値を設定することで構成される。

OuterヘッダのIPv4ヘッダ３２０は、フロー分類用データベース２１０記載のパケット送信先情報に含まれるトンネル終点IPv4アドレスを宛先IPv4アドレスとし、通信ノード２０−Ａ或いは２０−ＤのIPv4アドレスを送信元IPv4アドレスとし、protocol番号としてUDP（User Datagram Protocol）を示す値を設定することで構成される（他のIPv4ヘッダ構成要素については省略する）。通信ノード２０−Ａ或いは２０−Ｄでは、トンネル終点IPv4アドレスとして、ＤＣ３０を収容する通信ノード２０−Ｂ及び２０−Ｃを用いるのが適当である。

OuterヘッダのUDPヘッダ３３０では、宛先ポート番号（UDPの上位プロトコル）としてNSHと親和性の高いVxLANを示す4789を用いる。送信元ポート番号は任意である為4789としても良い（他のUDPヘッダ構成要素については省略する）。

OuterヘッダのVxLANヘッダ３４０は、フロー分類用データベース２１０に記載されるその他の情報に含まれるユーザ識別子（VNI: VxLAN Network Identifier）を用い、Next Protocol（＝上位プロトコル）としてNSHを示す値（非特許文献３参照）を設定することで構成される（他のVxLANヘッダ構成要素については省略する）。

OuterヘッダのNSH３５０は、フロー分類用データベース２１０記載されるPath ID及びSF Indexと、Next Protocol（＝上位プロトコル、originalパケット４００の種別）とから構成される。Next Protocolには、IPv4を示す値を設定する。

通信ノード２０−Ａ、２０−Ｄは、以上を踏まえてouterヘッダ３００を生成し、originalパケット４００をカプセル化する。そして、カプセル化後、パケット送信先情報に記載の送信I/Fからカプセル化パケットを送出する。また、SFCドメイン１００の境界に存在する通信ノード２０−Ａ及び２０−Ｄは、SFCドメイン１００内でSFが全て適用されたパケットをデカプセル化し、デカプセル化処理が施されたoriginalパケット４００をユーザ端末８０或いはコンテンツサーバ９０に転送する役割も担う（詳細は後述）。

図４は通信ノード２０−Ｂ、２０−Ｃが備えるサービス分類用データベース２２０の構成例（その１）である。

通信ノード２０−Ｂ及び２０−Ｃでは、SFCドメイン内から入力されるパケットの中継を実施する。上述したように、通信ノード２０−Ｂ及び２０−Ｃは、カプセル化パケットのouterヘッダ３００に記載されるNSH３５０中の、Path ID及びSF Indexに基づいてパケット中継を実施する。

SFCドメイン内からパケットが入力されると、カプセル化パケット４００内のPath ID及びSF Indexを検索キーとして、サービス分類用データベース２２０の検索を実施する。Path ID及びSF Indexは、outerヘッダ３００のＮＳＨ３５０に格納されている。このサービス分類用データベース２２０は、上述のSFF-Tableに対応する。

検索を実行した結果、検索キーに一致する比較条件２２０１が存在する場合、検索結果を用いてouterヘッダ生成する。一致する条件が存在しない場合、当該パケットを廃棄するのが適当である。

検索結果には、パケット送信先情報（次転送先装置MACアドレス、トンネル終点IPv4アドレス、送信I/F）２２０２を含む。サービス分類用データベース２２０では、トンネル終点IPv4アドレスとして、SFCドメイン１００を構成する各ノード２０のIPv4アドレス、或いは当該SFFが収容するＤＣ３０内の仮想マシン(VM)５０のIPv4アドレスを用いる（outerヘッダ３００のMACアドレスとIPv4アドレスを更新する）。

図１のサーバ装置４０では、複数の仮想マシン（VM）５０を構成し、各VM５０上にてSF６０を実行させる。SFCドメイン１００内のSF６０は、図３のouterヘッダ３００を認識し、originalパケット４００に対して必要な処理を実行する。

詳述すると、SF６０は上記SFF２０から送信されたカプセル化パケットの受信後、outerヘッダ３００の内側に存在するoriginalパケット４００を抽出し、実行可能な処理を抽出したoriginalパケット４００に適用する。適用後、originalパケット４００にouterヘッダ３００を付加し、サーバ装置４０を収容するSFF２０に対して返送する。

このときSF６０は、返送する為に、outerヘッダ３００のMACヘッダ３１０及びIPv4ヘッダ３２０の送信元アドレスと宛先アドレスの入れ替えを実施する（TTLの減算は実施しない）。またSF６０は、originalパケット４００に対する処理の終了後、NSH３５０内のSF Indexの値を１だけ減算する。

SF６０でのサービス適用後にSFF（通信ノード２０）へ返送されたカプセル化パケットは、再度サービス分類用データベース２２０検索を実施し、一致する条件が存在する場合は検索結果に従ってパケットを転送する。

通信ノード２０では、SF Index＝1のカプセル化パケットを受信した場合、SFCドメイン内で当該パケットに適用すべきSFが全て終了済と判断し、outerヘッダ３００を削除し、originalパケット４００に対する通常のIPv4パケット転送処理を実施する。即ち、originalパケット４００をSFCドメイン外に送信する。

図５は通信ノード２０−Ｄが備えるフロー分類用データベースの構成例である。

通常のIPv4パケット転送を実行する場合には、図２のフロー分類用データベース２１０検索の際、Path ID及びSF Indexの項目２１０２がnoneとなっているエントリに比較条件を一致させる為の設定が必要である。また、通信ノード２０−Ａ及び２０−Ｄにてデカプセル化を実行させる為の設定（SF Index＝1のカプセル化パケットを、通信ノード２０−Ａ及び２０−Ｄで受信させること）が必要である。

通信ノード２０やサーバ装置４０等に対する各種設定は、管理装置７０から実行することができる。管理装置７０は、通信ノード２０内の各種データベースに対する設定や、サーバ装置４０内のVM稼動状態（含、VM上で実行中のSF種別）等の管理を担う。これらの管理の為に、管理装置７０は、SFCリソース管理領域を確保する。

＜２．End-to-End通信の実行例＞
図６Ａと図６Ｂを参照し、SFCドメイン１００を通過するトラフィック（送信元: ユーザ端末８０−１、宛先: コンテンツサーバ９０−１）の処理に関して、詳細に説明する。

図６Ａは図１の構成において、本実施例のSFCを適用されたEnd-to-End通信の概念図である。

図６Ｂは本実施例のSFCを適用されたEnd-to-End通信のシーケンス図である。

この例は図６Ａに示されるように、ユーザ端末８０−１からのデータが、通信ノード２０−Ａ，通信ノード２０−Ｂを経由してサーバ装置４０−ＢのＶＭ−Ｂ１，ＶＭ−Ｂ２で処理され、通信ノード２０−Ｄからコンテンツサーバ９０−１に送信される例である。

ここでは最初に、ユーザ端末８０−１から通信ノード２０−Ａに入力されたパケットの例を説明する（図６ＢのステップＳ３００）。

通信ノード２０−Ａでは、originalパケット４００の記載情報に基づき、図２のフロー分類用データベース２１０を検索する。検索の結果、5-tuple-Aと合致する場合、送信先情報として得られる通信ノード２０−Ｂとの間でトンネルを構成する為のouterヘッダ３００を生成する。このとき、Path ID＝100でSF Index＝3という検索結果が得られる為、これらの値をNSH３５０内のフィールドにマッピングする（他のouterヘッダ３００構成要素については省略する）。通信ノード２０−Ａは、originalパケット４００にouterヘッダ３００を付加した後、カプセル化パケットを通信ノード２０−Ｂへ向けて送信する（ステップＳ３０１）。

通信ノード２０−Ｂでは、通信ノード２０−Ａから送信されたカプセル化パケットを受信すると、このカプセル化パケットがSFCドメイン内でSFを適用させるべきパケットか否かを確認する。具体的には、カプセル化部分がouterヘッダ３００の形態となっているか否かを確認する。但し、SF Index＝0のパケットは廃棄する。outerヘッダ３００が付加されたパケットである場合、Path ID及びSF Indexの値に基づき、図４のサービス分類用データベース２２０を検索する（outerヘッダ３００が付加されたパケットでは無い場合、通常のIPルーティングを実施）。このカプセル化部分を構成するNSHはPath ID＝100、SF Index＝3である為、検索結果として送信先が仮想マシンVM-B1であることが分かる。この検索結果には、VM-B1のアドレス情報等が含まれる為、このアドレス情報を用いてouterヘッダ３００のMACヘッダ３１０及びIPv4ヘッダ３２０を更新する（SFFは、他の通信ノード２０へ対するトンネリング処理に加えて、VM６０へ対するトンネリング処理も実施する）。更新後、検索結果に含まれる送信回線からVM-B1に向けて送出する（ステップＳ３０２）。

VM-B1では、VM上で機能を実行するSF-B1が、カプセル化パケット（Path ID＝100、SF Index＝3）からoriginalパケット４００に対する機能を適用後、SF Index＝2としたカプセル化パケットを通信ノード２０−Ｂに返送する（ステップＳ３０３）。

VM-B1からカプセル化パケット（Path ID＝100、SF Index＝2）を返送された通信ノード２０−Ｂは、再度サービス分類用データベース２２０を検索し、カプセル化パケットに上述のステップＳ３０２と同様の処理を施し、送信先と判明したVM-B2へ送信する（ステップＳ３０４）。

VM-B2では、上述したVM-B1と同様に、VM上で機能を実行するSF-B2が、カプセル化パケット（Path ID＝100、SF Index＝2）からoriginalパケット４００に対する機能を適用後、SF Index＝1としたカプセル化パケットを通信ノード２０−Ｂに返送する（ステップＳ３０５）。

VM-B2からカプセル化パケット（Path ID＝100、SF Index＝1）を返送された通信ノード２０−Ｂは、再度図４に示すサービス分類用データベース２２０を検索し、カプセル化パケットに上述のステップＳ３０２と同様の処理を施した上で、通信ノード２０−Ｄへ送信する（ステップＳ３０６）。

通信ノード２０−Ｄでは、SF Index＝1のカプセル化パケットを受信すると、SFCドメイン１００内で当該パケットに適用すべきSFが全て終了済と判断し、outerヘッダ３００を削除し、originalパケット４００に記載の宛先IPv4アドレスを検索キーとして、図５に記載のフロー分類用データベース２１０を検索する。検索の結果、5-tuple-Dと合致する場合、送信先情報として得られるコンテンツサーバ９０−１のMACアドレスを用いて、originalパケット４００に付加すべきＭＡＣヘッダを生成し、このMACヘッダをoriginalパケット４００に付加してから、送信先情報として得られる送信回線からoriginalパケット４００を送出する（ステップＳ３０７）。

以上のように、図６Ａに示す経路で、ユーザ端末８０−１からコンテンツサーバ９０−１へのトラフィック中継が実行される。

コンテンツサーバ９０−１では、ユーザ端末８０−１から送信されたoriginalパケット４００に記載のリクエスト要求等に応じる為の応答を、ユーザ端末８０−１に送信する（コンテンツサーバ９０−１からユーザ端末８０−１へのトラフィック中継に関しては省略する）。

＜３．障害時の対応例＞
ここまで通信システム１０を構成する装置と、その動作に関して触れたが、ここから図７Ａや図７Ｂなどを参照しながらDC３０内におけるVM障害（含、SF障害）の検知と対応方式に関して説明する。ここでは、障害が発生したVM上のSFを、SFCドメイン１００内の他のDC３０にて再開させることを前提とする（DC30-Bにおける全VM上でSFが実行される一方、DC30-CではVM上でSFが実行されていないVMが存在する）。

図７ＡはDCを収容する通信ノード２０−ＢによるVM死活監視の概略図である。

図７Ｂは障害時の対応例を示すシーケンス図（その１）である。

図８はVMトラブル等に起因する通信途絶状態の概略図である。

図９はDCを収容する通信ノード２０−Ｂによる管理装置７０へ対するVMトラブル発生の旨を通知するメッセージ送付の概略図である。

図１０は通信ノード２０−Ｂが備えるサービス分類用データベースの構成例（その２）である。

図７Ａ、図７Ｂへ示すように、通信ノード２０の内、DC３０を収容する通信ノード（例: 通信ノード２０−Ｂ）は、収容DC内の各VMへ対して定期的に死活監視を実施する（図７ＢステップＳ４００）。

ここで、何らかの理由で例えばVM-B2から応答が得られなくなった場合、図８に示すような通信途絶の状態に陥る。通信ノード２０−Ｂは、図９へ示すように、VM-B2から応答が得られなくなった直後、管理装置７０に対し、VM-B2の死活監視が出来なくなったことを伝える為のメッセージを通知する（図７ＢステップＳ４０１）。

この通知の発行後、通信ノード２０−ＢはSF-B2がSFCドメイン１００内で再開されることを予期し、SFCドメイン１００を構成する複数の通信ノード２０に対してVM-B2宛のトラフィックをFloodingする為、自装置内のサービス分類データベース２２０を更新する（図１０参照）。

図１１へ示すように、この更新の結果、図４ではVM-B2宛扱いのカプセル化パケット（Path ID＝100、SF Index＝2）を、SFCドメイン内の全ての通信ノード２０に対して送信する（図７ＢステップＳ４０２、これをSFCドメインFloodingと呼ぶ）。

このとき、SF-B2が再開される可能性がある仮想マシンは、現状他の機能を実行している等の理由で機能の代替ができない仮想マシンを除いた、全ての仮想マシンである。従って、機能の代替可能性がない仮想マシンはFlooding対象から除いてもよい。ただし、システムの構成例としては、仮想マシンの状態に係らず、ドメイン内の全ての仮想マシンまたは通信ノードにFloodingすることが、制御上は簡単である。

このFloodingパケットには、SF-B2が再開されるまでの暫定的なFloodingであることを示すマーキングをouterヘッダ３００に埋め込む。尚、通信ノード２０−Ｂでは、Path ID＝100且つSF Index＝3のカプセル化パケットはVM-B1へ送信する。通信ノード２０−Ｂは、このFloodingパケットをDC30-Bに向けて送信しない。送信しない理由は、何らかの理由でVM-B2が再起動され、SF-B2が再開することを防ぐ為である（VM-B2は、障害原因が特定されるまで再起動しない）。FloodingパケットをDC30-B内のVMに向けて送信しないことにより、（何らかの理由でVM-B2が再起動され）SF-B2が意図せずSFCドメイン１００内に複数存在する状態となっても問題ない状況を構築可能である。

管理装置７０は、自己が管轄するドメイン内の各サーバ装置４０の稼働状況を把握している。管理装置７０では、上記メッセージの受信後、SF-B2が停止状態に陥っていると判定し、SFCドメイン１００内のVM５０の内、SF-B2を実行させるVMの候補として、例えばSFを実行させていないVMを自装置内のSFCリソース管理領域から読み出す。そして、VM使用率の低いサーバ装置４０内のVMに対し、VM-B2上で動作していたSF-B2を動作させる為のトリガを掛ける（本実施例では、VM-C2に対してトリガを掛ける）。

図１２へ示すように、通信ノード２０−Ｂから送信された上記SFCドメインFloodingパケットを受信した通信ノード２０−Ｃは、収容するDC内のSF未使用VMに対して上記SFCドメインFloodingパケットを転送する（図７ＢステップＳ４０３、これをDC内Floodingと呼ぶ）。

DC内Floodingを実施する理由は、SF-B2がDC30-C内のVMで再開された場合、素早くEnd-to-Endの通信を復旧させる為である。このとき、通信ノード２０−Ｃでは、（SF-B2がDC30-C内のVMで再開された場合に備えて）FloodingパケットをDC30内のVMへFloodingさせ、このFloodingパケットがDC30内のVM上で再開するSF-B2によって処理された際、End-to-End通信の復旧に向けたデータベースを設ける必要がある。そこで、図４に示したようなサービス分類データベース２２０に加えて、図１３へ示すようなFloodingパケット用データベース２３０を構成する（図１３では、サービス分類データベース２２０を省略する）。

図１３は、通信ノード２０−Ｃが備えるFloodingパケット用データベースの構成例である。

Floodingパケット用データベース２３０は、通信ノード２０−Ｂから送信された上記Floodingパケットを、通信ノード２０−ＣがＤＣ３０−Ｃ収容のSF未稼働VMに対してFloodingさせる為のものである。Floodingパケット用データベース２３０は、カプセル化パケット（Path ID＝100、SF Index＝2）中継用のエントリと、DC30内のVM上で動作するSF-B2によって処理されたカプセル化パケット（Path ID＝100、SF Index＝1）を通信ノード２０−Ｂへ転送する為のエントリとから構成される。ここで、Floodingパケット用データベース２３０における上記通信ノード２０−Ｂへ転送する為のエントリを設ける理由は、Floodingパケットの送信元が通信ノード２０−Ｂであり、通信ノード２０−Ｂがカプセル化パケット（Path ID＝100、SF Index＝1）をデカプセル化させる通信ノード２０−Ｄ（CL）に関する情報（送信先情報）を保持している為である。

図１４は、管理装置７０からVM-C2に対するSF起動指示の概略図である。前述のVM-C2は、図１４へ示すような管理装置７０によってSF-B2起動を促すトリガ（図７ＢステップＳ４０４）を掛けられた後、SF-B2を起動する。起動後のSF-B2は、Floodingパケット（Path ID＝100、SF Index＝2）にSFを適用し、SF Indexを１だけ減算したカプセル化パケット（Path ID＝100、SF Index＝1）を通信ノード２０−Ｃへ送出する（図７ＢステップＳ４０５）。

図１５は、SF-B2の再開によるEnd-to-End通信復旧を示す概略図である。上記カプセル化パケットの宛先までの到達経路は図１５に示すとおりである。

VM-C2からカプセル化パケット（Path ID＝100、SF Index＝1）を返送された通信ノード２０−Ｃは、図１３のFloodingパケット用データベース２３０を参照し、当該カプセル化パケット（Path ID＝100、SF Index＝1）のMACヘッダ３１０及びIPv4アドレス３２０を更新し、通信ノード２０−Ｂへ向けて送信する（図７ＢステップＳ４０６）。

図１６Ａは、通信ノード２０−ＣによるSF-B2開始を通知するメッセージ送付の概略図である。

図１６Ｂは、図７Ｂの続きであり、障害時の対応例を示すシーケンス図（その２）である。

図１７は、通信ノード２０−Ｃが備えるFloodingパケット用データベース及びサービス分類用データベースの構成例（その１）である。

図１６Ａと図１６Ｂへ示すように、また、通信ノード２０−Ｃは、SF-B2が開始した（即ち、Path ID＝100且つSF Index＝2のカプセル化パケットが収容DC内で処理可能になった）ことを伝える為のメッセージをSFCドメイン内の通信ノード２０及び管理装置７０へ通知する（図１６ＢステップＳ４０７）。

このとき更に、通信ノード２０−Ｃは、Flooding用データベース２３０から有意なエントリをサービス分類用データベース２２０にコピーし、Flooding用データベース２３０の全エントリを初期化する（図１７参照）。これにより、通信ノード２０−Ｃは、DC内Floodingを停止する。

通信ノード２０−Ｃから送信されたカプセル化パケット（Path ID＝100、SF Index＝1）を受信した通信ノード２０−Ｂは、図１０のサービス分類用データベース２２０を検索し、検索結果（送信先: 通信ノード２０−Ｄ）を用いてMACヘッダ３１０及びIPv4ヘッダ３２０を更新し、当該カプセル化パケットを通信ノード２０−Ｄへ送信する（図１６ＢステップＳ４０８）。

図１８は、通信ノード２０−Ｂが備えるサービス分類用データベースの構成例（その３）を示す。通信ノード２０−Ｂは、通信ノード２０−Ｃから発行されたSF-B2開始メッセージ受信の際、図１８へ示すように、サービス分類データベース２２０を更新する（以後、SFCドメインFloodingを停止する）。詳述すると、SFCドメイン１００内の全通信ノード２０は、通信ノード２０−Ｃから発行されたメッセージ（Path ID＝100且つSF Index＝2のカプセル化パケットが通信ノード２０−Ｃ収容DC内で処理可能）受信の際、Path ID＝100且つSF Index＝2であるカプセル化パケットを取り扱うDCが通信ノード２０−Ｃに収容されていると判断する。そして、該当するデータベース（フロー分類用データベース２１０、サービス分類データベース２２０）内エントリの送信先情報パラメータを、図１８のように更新する。

図１９に、この更新によるユーザ端末８０−１からコンテンツサーバ９０−１へのトラフィック経路を示す。通信ノード２０−Ｃからコンテンツサーバ９０−１までの経路に２つの通信ノード２０−Ｂ及び２０−Ｄを通過する必要があり、ネットワーク利用効率の面で有効とは言えない状態になる。そこで、通信ノード２０−Ｂは、自装置のサービス分類データベース２２０を更新後、SFCドメイン１００内の全通信ノード２０に対し、Path ID＝100且つSF Index＝1であるカプセル化パケットの次転送先が通信ノード２０−Ｄであることを伝える為のメッセージを通知しても良い（図１６ＢステップＳ４０９）。

図２０は、通信ノード２０−ＢからSFCドメイン１００内の全通信ノード２０に対し、次転送先を伝える為のメッセージを通知している状態である。

また、通信ノード２０−Ｂから発行された前記メッセージを受信した通信ノード２０−Ｃは、このメッセージに従って自装置内のサービス分類データベース２２０を、更新しても良い。

図２１は、このメッセージに従って更新された、サービス分類データベース２２０の例である。例えば通信ノード２０−Ｃでは、比較条件100，1の場合の送信先として、通信ノードＢ（図１７参照）を通信ノードＤに変更する。

図２２は、この更新が実行された場合におけるユーザ端末８０−１からコンテンツサーバ９０−１へのトラフィック経路を示す。図１９のように一度通信ノード２０−Ｂを経由することなく、直接通信ノード２０−Ｄに送信される。

図２３は、SFCドメイン内の各通信ノード２０が、パケットの転送に用いるデータベースを更新したことを伝える為のメッセージを、（事後に）管理装置へ通知する概略図である。 SFCドメイン１００内の全通信ノード２０は、上述した更新の実行後、図２３へ示すように、自装置内のデータベース（フロー分類用データベース２１０、サービス分類データベース２２０）内エントリの送信先情報パラメータを更新したことを伝える為のメッセージを通知する（図１６ＢステップＳ４１０）。管理装置７０は、前記メッセージに基づいてSFCドメインのリソース管理領域を更新する。

以上の構成を採ることにより、上述した課題を克服する通信システム１０が提供可能となる。

本実施例では、End-to-End通信の復旧を高速化させる為、Flooding（SFCドメインFlooding、DC内Flooding）と、通信ノード２０から管理装置７０へ対する事後報告（各通信ノードにおけるデータベース内エントリのパラメータ更新）とを用いた。FloodingによってSFCドメイン１００内の通信回線の利用効率は低下する。しかし、管理装置７０の集中管理によってデータベース更新を指示させる方式よりも、SFCドメイン１００内の各通信ノード２０による分散処理に要する時間の方が短いと判断し、Flooding（SFCドメイン内Flooding、DC内Flooding）及び管理装置７０への事後報告方式を採用した。

＜４．通信ノードの構成例＞
図２４は、上記で説明した通信システム１０で用いる通信ノード２０の構成を示すブロック図である。通信ノード２０は、データパケットの送受信を行う公知の通信ノードを基本にしているが、スイッチや入出力ポート等、通信装置として公知の構成は省略し、本実施例で追加される特有の部分を主に以下説明する。なお、図１に示される通信ノード２０−Ａ、Ｂ，Ｃ，Ｄは同一構成としてもよいし、役割に応じて必要な構成のみを備えるようにしてもよい。

通信ノード２０は基本的に処理装置２４１、入出力装置２４２、および記憶装置２４３を備える。処理装置２４１は、記憶装置２４３に格納されるソフトウェアによる制御により、送信部２４４、監視部２４５、転送部２４６、通知部２４７等の処理機能を実行する。なお、ソフトウェアで構成した機能と同等の機能は、FPGA（Field Programmable Gate Array）、ASIC（Application Specific Integrated Circuit）などのハードウエアでも実現できる。

記憶装置２４３は、磁気ディスク(HDD）や不揮発性または揮発性の半導体メモリで構成することができ、用途に応じて複数種類備えてもよい。記憶装置２４３は、ソフトウェアの他、図２、図４、図５、図１０、図１３、図１７、図１８、図２１等に示したテーブルをデータとして格納する。これらのテーブルは、処理装置２４１からのリード・ライトが可能である。処理装置２４１は、受信したデータパケットの内容とこれらのテーブルに基づいて、データパケットの送信先を決定することができる。

入出力装置２４２は公知の構成により、他の通信ノード２０やサーバ装置４０との間で、データを送受信する機能を備える。また、ディスプレイやキーボード等のユーザインタフェースを備えてもよい。

処理装置２４１において、送信部２４４は、入出力装置２４２を介して受信したパケットを、パケットの内容に基づいて他の通信ノード２０あるいはサーバ装置４０の仮想マシンに送信する制御を行う。

図１の通信ノード２０−Ｂの機能を説明する。監視部２４５は、自分が収容するサーバ装置２４２（あるいはその上の仮想マシン）が所定の機能を実行しているか否かを監視する死活監視を行う(図７Ａ参照）。死活監視処理は、既に述べたように、入出力装置２４２を介して、定期的にサーバ装置２４２と信号をやり取りすることで実現することができる。

転送部２４６は、監視部２４５が、サーバ装置で所定の機能が停止（または異常）状態に陥っていると判断した場合、その所定の機能を実行する仮想マシンへ送信すべきパケットを、他のデータセンタを収容する他の複数の通信ノードへ、Floodingパケットとして転送する（図１１参照）。この動作は、処理装置２４１が、記憶装置２４２内のサービス分類用データベース２２０を、図１０のように書き換え、転送部２４６がサービス分類用データベース２２０を参照して送信先を決定することにより実現される。

また、送信部２４４は、サービス分類用データベース２２０を参照して送信先を決定することにより、機能が停止していると判断した仮想マシンへは、所定の機能を実行させるためのパケットを送信しない。通知部２４７は所定の機能が停止したことを、入出力装置２４２を介して管理装置７０へ通知する(図９参照）。

また、送信部２４４は、後述するように、通信システム１０内の他の通信ノード（例えば２０−Ｃ）から代行処理結果を受信した際に、その代行処理結果のヘッダ情報に対応する次転送先を伝える為のメッセージを、通信システム内の全通信ノードに対し通知する(図２０参照）。なお、上記の送信部２４４、転送部２４６、通知部２４７は、一部または全部を物理的に同一の構成として、送信部２４４、転送部２４６、通知部２４７の各機能を兼ねるようにしてもよい。例えば、ソフトウェアの同一のサブルーチンを、各機能で共用してもよい。

図１の通信ノード２０−Ｃの機能を説明する。送信部２４４は、通信システム１０内の他の通信ノード２０からFloodingパケットを受信した際に、自装置に対応付けられるデータセンタの全ての仮想マシンへFloodingパケットを転送する(図１２参照）。このとき、SFを割り当てられていない仮想マシンに限定して転送してもよい。この動作は、処理装置２４１が記憶装置２４２内のFloodingパケット用データベース２３０を、図１３のように作成し、送信部２４６がFloodingパケット用データベース２３０を参照して送信先を決定することにより実現される。

通信ノード２０−Ｃが、管理装置７０から、自装置に対応付けられるデータセンタのいずれかの仮想マシンへ起動を促すトリガを受信した場合(図１４参照）、当該仮想マシンは、機能が停止している仮想マシンに代わって、Floodingパケットを処理する。

通信ノード２０−Ｃの送信部２４４は、Floodingパケットが転送され、かつ、起動を促された仮想マシンにより所定の機能を実行された結果を代行処理結果として通信ノード２０−Ｂに送信する(図１５参照）。この処理は、処理装置２４１が記憶装置２４２内のサービス分類用データベース２２０を図１７のように変更し、送信部２４４がサービス分類用データベース２２０を参照して送信先を決定することにより実現される。また、通知部２４７は、管理装置７０や他の通信ノード２０に対して、SFの再開を通知する（図１６Ａ参照）。

以上の制御のための構成は、単体のコンピュータで構成してもよいし、あるいは、入力装置、出力装置、処理装置、記憶装置の任意の部分が、ネットワークで接続された他のコンピュータで構成されてもよい。

本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることが可能である。また、各実施例の構成の一部について、他の実施例の構成の追加・削除・置換をすることが可能である。

１０ 通信システム
２０ 通信ノード
３０ データセンタ（DC）
４０ サーバ装置
５０ 仮想マシン（VM）
６０ Service Function（SF）
７０ 管理装置
８０ ユーザ端末
９０ コンテンツサーバ
１００ SFCドメイン
３００ outerヘッダ
４００ original IPv4パケット（含、ペイロード）

Claims (15)

1. 複数の仮想マシンを備え、前記仮想マシン上で所定の機能を実行するサーバ装置を含むデータセンタと、
   前記データセンタを収容し、受信したパケットを該パケットの記載事項に従って他の通信ノードあるいは前記仮想マシンに転送して前記所定の機能を実行させる通信ノードと、
   前記通信ノードおよびデータセンタを管理する管理装置と、
   を含む通信システムであって、
   前記通信ノードは、
   前記所定の機能について死活監視をしており、前記所定の機能に異常があると判断した場合、前記所定の機能を実行する前記仮想マシンへ転送すべきパケットを他のデータセンタを収容する他の複数の通信ノードへFloodingパケットとして転送すると共に、前記所定の機能に異常があることを前記管理装置へ通知することを特徴とする通信システム。
2. 前記通信ノードが、
   前記Floodingパケットを、前記所定の機能に異常があると判断された仮想マシンを除き、前記管理装置が管理するデータセンタ内の仮想マシンのうち、少なくとも前記所定の機能を代理実行できる仮想マシン全てへ転送することを特徴とする請求項１に記載の通信システム。
3. 前記他の通信ノードが、
   前記Floodingパケットを受信すると、収容する前記他のデータセンタ内のサーバ装置が備える複数の仮想マシンに対して前記パケットを転送することを特徴とする請求項２に記載の通信システム。
4. 前記管理装置が、
   前記通知を受信すると、前記所定の機能を代理実行すべき仮想マシンを管理対象の前記データセンタ内から特定し、特定された仮想マシンに前記所定の機能を実行させることを特徴とする請求項３に記載の通信システム。
5. 前記特定された仮想マシンが、
   前記通信ノードから転送された前記Floodingパケットに対して前記所定の機能を実行して、自己が属するデータセンタを収容する前記他の通信ノードに応答することを特徴とする請求項４に記載の通信システム。
6. 前記他の通信ノードが、
   自己が収容するデータセンタの前記特定された仮想マシンから前記応答を受信することにより、前記所定の機能が復旧したと判断し、復旧したことを通知するメッセージを自身以外の通信ノードへ送信することを特徴とする請求項５に記載の通信システム。
7. 前記メッセージを受信した通信ノードが、
   前記メッセージ記載内容に基づいて自装置内の状態を更新することを特徴とする請求項６に記載の通信システム。
8. 管理装置と、仮想マシン上で所定の機能を実行する複数のデータセンタと、前記データセンタの其々に対応付けられる複数の通信ノードを備える通信システムにおける、前記通信ノードであって、
   前記通信ノードは、入出力部と、処理部と、記憶部を備え、
   前記処理部は、
   受信したパケットを該パケットの内容に基づいて他の通信ノードあるいは前記仮想マシンに送信して前記所定の機能を実行させる送信部と、
   自分が対応付けられる前記データセンタの前記所定の機能の死活監視を行う監視部と、
   前記所定の機能が停止していると判断した場合、前記所定の機能を実行する前記仮想マシンへ送信すべきパケットを、他のデータセンタに対応付けられる他の複数の通信ノードへFloodingパケットとして転送する転送部と、
   前記所定の機能が停止したことを前記管理装置へ通知する通知部と、
   を有する通信ノード。
9. 前記送信部は、
   前記所定の機能が停止していると判断した仮想マシンへは、前記所定の機能を実行させるためのパケットを送信しない、
   請求項８記載の通信ノード。
10. 前記送信部は、
    前記通信システムの他の通信ノードから前記Floodingパケットを受信した際に、自装置に対応付けられるデータセンタの複数の仮想マシンへ前記Floodingパケットを転送する、
    請求項８記載の通信ノード。
11. 前記送信部は、
    前記管理装置から、自装置に対応付けられるデータセンタのいずれかの仮想マシンへ起動を促すトリガを受信した場合、該トリガを前記データセンタに転送することに加え、前記Floodingパケットを転送し、かつ、前記起動を促された仮想マシンにより前記所定の機能を実行された結果を代行処理結果として前記他の通信ノードに送信する、
    請求項１０記載の通信ノード。
12. 前記送信部は、
    前記通信システムの他の通信ノードから前記代行処理結果を受信した場合に、当該代行処理結果のヘッダ情報に対応する次転送先を伝える為のメッセージを、前記通信システム内の自己以外の全通信ノードに対し通知する、
    請求項１１記載の通信ノード。
13. 複数のデータセンタと通信ノードを含む通信システムであって、
    複数の第１の仮想マシンを備え、受信したパケットに基づいて該第１の仮想マシン上で所定の機能を実行する第１のデータセンタと、
    前記第１のデータセンタを収容し、受信したパケットを他の通信ノードあるいは前記第１の仮想マシンに送信する第１の通信ノードと、
    複数の第２の仮想マシンを備え、受信したパケットに基づいて該第２の仮想マシン上で所定の機能を実行する第２のデータセンタと、
    前記第２のデータセンタを収容し、受信したパケットを他の通信ノードあるいは前記第２の仮想マシンに送信する第２の通信ノードと、
    前記通信ノードおよびデータセンタを管理する管理装置と、
    を備える通信システムにおける代替処理方法であって、
    前記第１の通信ノードが、前記第１の仮想マシンのいずれかが前記所定の機能の実行に支障があるとき、当該第１の仮想マシンへ送信すべきパケットを前記第２の通信ノードへFloodingパケットとして転送すると共に、所定の機能の実行に支障があることを前記管理装置へ通知する第１のステップと、
    前記第２の通信ノードが、受信した前記Floodingパケットを、前記第２の仮想マシンへ転送する第２のステップと、
    前記管理装置が、前記実行に支障が生じた所定の機能を代行させるべき前記通信システム内の他の仮想マシンに、当該機能の実行開始を指示する第３のステップと、
    前記第２の通信ノードが、前記第２の仮想マシンのいずれかが前記実行開始の指示により、前記Floodingパケットに基づいて前記所定の機能を実行した結果を、前記第１の通信ノードに送信する第４のステップと、
    を実行する通信システムにおける代替処理方法。
14. 前記通信システムは、通信システム外部との送受信を行い、受信したパケットを他の通信ノードに送信する第３の通信ノードを備え、
    前記第３の通信ノードが、前記通信システム外部から受信したパケットに対して、当該パケットのフロー情報に基づいて、前記通信システム内で適用される前記所定の機能の連鎖を示す識別子であるPath IDと、前記通信システム内で経由する前記所定の機能の数に基づくSF Indexをヘッダとして付加する第５のステップと、
    を実行し、
    前記第１及び第２の通信ノードは、前記Path IDとSF Indexを検索キーとして、次送信先情報を検索するサービス分類用データベースを備え、当該サービス分類用データベースにより、パケットの送信先を決定する、
    請求項１３記載の通信システムにおける代替処理方法。
15. 前記第１のステップにおいて、前記第１の通信ノードは、前記サービス分類用データベースの次送信先情報を、所定の機能の実行に支障がある前記第１の仮想マシンから、Floodingを示す情報に書換え、
    前記第２のステップにおいて、前記第２の通信ノードは、受信した前記Floodingパケットの前記Path IDとSF Indexに対する次送信先情報として第２の仮想マシンを指定するとともに、前記第２の仮想マシンを経由したパケットに対する次送信先情報として前記第１の通信ノードを指定するFloodingパケット用データベースを生成し、
    前記第４のステップにおいて、前記第２の通信ノードは、前記Floodingパケット用データベースの一部を前記サービス分類用データベースにコピーし、
    前記第２の通信ノードは、前記第２の仮想マシンのいずれかが前記実行開始の指示により、前記所定の機能の実行を開始したことを他の前記通信ノードおよび前記管理装置に通知する第６のステップを実行し、
    前記第１の通信ノードは、前記所定の機能の実行を開始した通知を受けた際に、前記サービス分類用データベースの次送信先情報を、Floodingを示す情報から前記第２の通信ノードを示す情報に書き換える第７のステップを実行する、
    請求項１４記載の通信システムにおける代替処理方法。

Images