(57)【要約】【解決手段】ＳＤＮネットワーク（１）において経路保護を実行する方法は、保護接続群を確立し、前記保護接続群はそれぞれ２つのエンドポイントスイッチ（３、５）の間にあり、第１の中間スイッチ群（３、６）の組に沿った動作経路と第２の中間スイッチ（３、６）の組に沿った少なくとも１つの保護経路とを備え、メタデータを前記スイッチ群（３、５、６）に提供し、前記メタデータは保護接続群の前記エンドポイントスイッチ群（３、５）についての情報を前記保護接続群のそれぞれに又は同じ経路をたどる前記保護接続群のグループに割り当てられたユニークな識別子とともに保持し、ローカルポート及び／又はリンクの障害を経験した場合、前記中間スイッチ群（３、６）が前記メタデータを用いて前記ポート及び／又はリンクの障害により影響された前記接続群のエンドポイントスイッチ（３、５）に向けた障害メッセージを生成し、障害メッセージを受信すると、前記エンドポイントスイッチ群（３、５）が影響を受けた前記接続群をそれらの動作経路からそれらの少なくとも１つの保護経路に切り替えることを含む方法。【選択図】図２
2019510422.tif 000002
【特許請求の範囲】
【請求項１】
ＳＤＮネットワーク（１）において経路保護を実行する方法であって、
保護接続群を確立し、前記保護接続群はそれぞれ２つのエンドポイントスイッチ（３、５）の間にあり、第１の中間スイッチ群（３、６）の組に沿った動作経路と第２の中間スイッチ（３、６）の組に沿った少なくとも１つの保護経路とを備え、
メタデータを前記スイッチ群（３、５、６）に提供し、前記メタデータは保護接続群の前記エンドポイントスイッチ群（３、５）についての情報を前記保護接続群のそれぞれに又は同じ経路をたどる前記保護接続群のグループに割り当てられたユニークな識別子とともに保持し、
ローカルポート及び／又はリンクの障害を経験した場合、前記中間スイッチ群（３、６）が前記メタデータを用いて前記ポート及び／又はリンクの障害により影響された前記接続群のエンドポイントスイッチ（３、５）に向けた障害メッセージを生成し、
障害メッセージを受信すると、前記エンドポイントスイッチ群（３、５）が影響を受けた前記接続群をそれらの動作経路からそれらの少なくとも１つの保護経路に切り替えることを含む方法。
【請求項２】
前記メタデータは、ネットワークフロー群に割り当てられた、前記スイッチ群（３、５、６）に各ネットワークフローが保護された接続に属するか保護されていない接続に属するかを知らせる専用フラグを含む、請求項１に記載の方法。
【請求項３】
前記メタデータは保護接続又は同じネットワーク経路をたどる保護接続群のグループを識別するための、保護ＩＤとして示される専用の識別子を含む、請求項１又は２に記載の方法。
【請求項４】
前記メタデータは、保護接続のヘッド又はテールエンドポイントスイッチ（３、５）のアドレス含む、請求項１〜３のいずれかに記載の方法。
【請求項５】
前記メタデータは既存のOpenFlow意味論に統合されている、請求項１〜４のいずれかに記載の方法。
【請求項６】
前記スイッチ群（３、５、６）は、前記メタデータを用いてローカルポート及び／又はリンクの障害により影響された接続群を識別する請求項１〜５のいずれかに記載の方法。
【請求項７】
前記スイッチ群（３、５、６）は前記メタデータを用いてポート及び／又はリンク障害通知メッセージ群を生成しそれらを前記データプレーンを介して前記各ポート及び／又はリンクの障害に影響された保護接続群のエンドポイントスイッチ群（３、５）に向けて送信する、請求項１〜６のいずれかに記載の方法。
【請求項８】
障害通知メッセージは、影響を受けた前記接続の前記ヘッド又はテールエンドポイントスイッチ（３、５）の前記アドレスを宛先アドレスとして、影響を受けた前記接続の保護ＩＤをペイロードとして用いる、請求項３〜７のいずれかに記載の方法。
【請求項９】
特に請求項１〜８のいずれかに記載の方法を実行するためのシステムであって、
複数のスイッチ（３、５、６）と前記複数のスイッチ（３、５、６）の１つ又は複数に接続されたネットワークコントローラ（２）といくつかの保護接続群とを含むＳＤＮネットワーク（１）であって、前記保護接続群はそれぞれ２つのエンドポイントスイッチ（３、５）の間にあり第１の中間スイッチ（３、６）の組に沿った動作経路と第２の中間スイッチ（３、６）の組に沿った少なくとも１つの保護経路とを備えるＳＤＮネットワーク（１）と、
ローカルポート及び／又はリンクの障害を経験した場合、保護接続群の前記エンドポイントスイッチ群（３、５）についての情報を前記保護接続群のそれぞれに又は同じ経路をたどる前記保護接続群のグループに割り当てられたユニークな識別子とともに用いて前記ポート及び／又はリンクの障害により影響された前記接続群のエンドポイントスイッチ（３、５）に向けた障害メッセージ群を生成する前記中間スイッチ（３、６）と、
障害メッセージを受信すると、影響を受けた前記接続群をそれらの動作経路からそれらの少なくとも１つの保護経路に切り替える前記エンドポイントスイッチ（３、５）とを備えるシステム。
【請求項１０】
前記複数のスイッチ（３、５、６）は、前記データプレーンにおいて障害メッセージ群の迅速な伝搬をサポートする転送ルールの組を備えて構成される、
請求項９に記載のシステム。
【請求項１１】
前記複数のスイッチ（３、５、６）の１つ又は複数は、前記スイッチ群（３、５、６）が前記コントローラ（２）から受け取るメッセージ群からの前記メタデータを保持する拡張フィールド群を抽出するエージェント、特にOpenFlowエージェント（７）を備える、請求項９又は１０に記載のシステム。
【請求項１２】
前記複数のスイッチ（３、５、６）の１つ又は複数は、各スイッチ（３、５、６）のローカル出力ポート群と保護接続群のエンドポイントスイッチ群（３、５）との対応付けを保存するためのテーブル（８）を備える、請求項９〜１１のいずれかに記載のシステム。
【請求項１３】
前記複数のスイッチ（３、５、６）の１つ又は複数は、ローカルポート及び／又はリンクの障害に影響された保護接続群を識別し、前記メタデータに基づいて影響を受けた前記接続群のエンドポイントスイッチ群（３、５）に向けたポート及び／又はリンク障害通知メッセージを生成する障害ロジックモジュール（９）を備え、及び／又は
前記複数のスイッチ（３、５、６）の１つ又は複数は、前記データプレーンからポート及び／又はリンク障害通知メッセージ群を抽出し前記メッセージ群を局所的に保護された転送ルールに関連付けるロジックモジュール（１０）を備える、請求項９〜１２のいずれかに記載のシステム。
【請求項１４】
請求項１〜１３のいずれかに記載の方法及び／又はシステムにおいて採用されるように構成されたネットワークスイッチ、特にＳＤＮスイッチ（３、５、６）。
【請求項１５】
請求項１〜１３のいずれかに記載の方法及び／又はシステムにおいて採用されるように構成されたネットワークコントローラ、特にＳＤＮコントローラ（２）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、ＳＤＮネットワークにおいて経路保護を実行する方法及びシステムに関する。
【背景技術】
【０００２】
従来のルーティングプロトコルはネットワークに障害が発生した際転送経路の再計算に依存するため、（１秒未満から数秒の範囲の）遅い収束時間を露呈する。そのような障害スイッチオーバー時間は、５０ｍｓ未満のスイッチオーバー時間を求める場合があるリアルタイムアプリケーションやミッションクリティカルなアプリケーションにとっては受け入れがたい。この問題に取り組むため、分散コントロールプレーンプロトコルへのいくつかの拡張が設計された。代表的な方法の１つは、経路に沿った局所的な保護プリミティブを実現すること、すなわち、ノードとリンクを保護することである（例えば、P. Pan, G. Swallow, A. Atlas: “Fast Reroute Extensions to RSVP-TE for LSP Tunnels”, IETF, Network Working Group, RFC 4090, May 2005を参照）。しかしながら、このような拡張はトポロジーに依存しており、実際、セグメントレベルで動作する。更に、多数の保護セグメントを維持することはスケーラビリティ上の問題となり、保護セグメントに沿ったリソース可用性の問題に対処しない。
【０００３】
一方、分散及び集中コントロールプレーン用のいくつかのエンドツーエンドＬ２経路保護メカニズムは、経路毎のキープアライブメッセージの伝搬に基づくものである（例えば、ITU-T rec. G.8031, G.8032）。しかしながら、このような方法をOpenFlowのような集中コントロールを有するフレキシブル−マッチングアーキテクチャに導入するのは困難である。具体的には、第１に、キープアライブメッセージのパケットヘッダーの適切な値を見つけることは、特に高度に動的な転送状態を有するネットワークにおいてはＮＰ困難な問題である（例えば、P. Peresini, M. Kuzniar, D. Kostic: “Monocle: Dynamic, Fine-Grained Data Plane Monitoring”, CoNEXT’15, Heidelberg, Germany, 2015を参照）。第２に、フロー毎のキープアライブメッセージに対して特定の転送ルールを設定した場合、データプレーン内のフロー数が増加してそのスケーラビリティが制限される。第３に、キープアライブメカニズムは、その効果を減少させ反応時間を遅らせてしまう誤ったスイッチオーバーを防ぐために輻輳耐性を持たなくてはならない。
【０００４】
OpenFlowプロトコルv.1.3.1+は、FastFailoverグループにより実装される局所的障害のための固有のスイッチオーバーメカニズムを有する（OpenFlow Switch Specification, Version 1.3.1 (Wire Protocol 0x04), September 6, 2012, https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/OpenFlow/OpenFlow-spec-v1.3.1.pdf, 特に“5.6 Group Table”の章を参照）。あるスイッチがローカルポートの障害を検出した場合（例えば、隣接スイッチからの光学信号又はキープアライブメッセージを喪失した場合）、保護フローは次のライブのバケット（すなわち、ポート又は論理ポートのグループ）に切り替えられる。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、まず、上記の方法はトポロジーに依存しており、保護接続のエンドポイントスイッチのすぐ近隣において発生するポート及び／又はリンクの障害への反応においてのみ適切に機能する。更に、このメカニズムに従って経路保護を可能にするには、遅いOpenFlowコントロールチャネルを経るＳＤＮコントローラとの対話が必要になり、スイッチオーバー時間はスイッチのアーキテクチャだけでなくＳＤＮコントローラのアーキテクチャにも依存する。実際、転送パイプラインの更新の速度及びOpenFlowメッセージの処理は、ハードウェアベースのスイッチングアーキテクチャの主要なボトルネックの中に含まれている(Roberto Bifulco and Anton Matsiuk: “Towards Scalable SDN Switches: Enabling Faster Flow Table Entries Installation”, Proceedings of the 2015 ACM Conference on Special Interest Group on Data Communication (SIGCOMM ‘15).ACM, New York, NY, USA, 343-344, DOI=http://dx.doi.org/10.1145/2785956.2790008を参照）。また、最近のコントローラアーキテクチャ（例えば、OpenDaylight、ONOS、など）におけるOpenFlow非同期メッセージの処理には通常いくつかの内部モジュール間の対話が必要となるため、スイッチオーバーが遅くなりミッションクリティカルなアプリケーションには受け入れがたいものになる。
【０００６】
従って、本発明の目的は、動作経路から保護経路へのスイッチオーバーが迅速にかつトポロジーに依存しないやり方で実行できるようにＳＤＮネットワークにおいて経路保護を実行する方法及びシステムを改善及び発展させることである。
【課題を解決するための手段】
【０００７】
本発明によれば、上記目的は、ＳＤＮネットワークにおいて経路保護を実行する方法であって、
保護接続群を確立し、前記保護接続群はそれぞれ２つのエンドポイントスイッチの間にあり、第１の中間スイッチ群の組に沿った動作経路と第２の中間スイッチの組に沿った少なくとも１つの保護経路とを備え、
メタデータを前記スイッチ群に提供し、前記メタデータは保護接続群の前記エンドポイントスイッチ群についての情報を前記保護接続群のそれぞれに又は同じ経路をたどる前記保護接続群のグループに割り当てられたユニークな識別子とともに保持し、
ローカルポート及び／又はリンクの障害を経験した場合、前記中間スイッチ群が前記メタデータを用いて前記ポート及び／又はリンクの障害により影響された前記接続群のエンドポイントスイッチに向けた障害メッセージを生成し、
障害メッセージを受信すると、前記エンドポイントスイッチ群が影響を受けた前記接続群をそれらの動作経路からそれらの少なくとも１つの保護経路に切り替えることを含む方法により達成される。
【０００８】
更に、上記目的は、
複数のスイッチと前記複数のスイッチの１つ又は複数に接続されたネットワークコントローラ（２）といくつかの保護接続群とを含むＳＤＮネットワークであって、前記保護接続群はそれぞれ２つのエンドポイントスイッチの間にあり第１の中間スイッチの組に沿った動作経路と第２の中間スイッチの組に沿った少なくとも１つの保護経路とを備えるＳＤＮネットワークと、
ローカルポート及び／又はリンクの障害を経験した場合、保護接続群の前記エンドポイントスイッチ群についての情報を前記保護接続群のそれぞれに又は同じ経路をたどる前記保護接続群のグループに割り当てられたユニークな識別子とともに用いて前記ポート及び／又はリンクの障害により影響された前記接続群のエンドポイントスイッチに向けた障害メッセージ群を生成する前記中間スイッチと、
障害メッセージを受信すると、影響を受けた前記接続群をそれらの動作経路からそれらの少なくとも１つの保護経路に切り替える前記エンドポイントスイッチとを備えるシステムにより達成される。
【０００９】
本発明によれば、上記目的は、動作及び保護経路の集中計算及びプログラミングとネットワーク障害に対する反応のＳＤＮスイッチへの委任を可能にする拡張をメタデータの形でOpenFlowプロトコルなどのＳＤＮネットワークにおいて採用される通信プロトコルに提供することにより達成できることが認識された。これにより、本発明は、保護経路を集中管理しネットワーク障害に対して局所的反応をするＳＤＮネットワークにおける迅速かつトポロジーに依存しない経路保護スイッチオーバーのための方法及びシステムを提供する。本発明を実行することにより、ＳＤＮネットワークにおけるエンドツーエンド保護経路のための障害スイッチオーバー時間が加速される。本発明の実施形態は、局所的なスイッチオーバーメカニズム（例えば、OpenFlow FastFailoverグループ）を用いて経路保護を実行するのに必要なフロー及びリンクの数を減少させる。更に、本発明による方法はトポロジーに依存しないやり方で機能する。
【００１０】
本発明の一実施形態によれば、前記メタデータは、ネットワークフロー群に割り当てられた、前記スイッチ群に各ネットワークフローが保護された接続に属するか保護されていない接続に属するかを知らせる専用フラグを含んでもよい。
【００１１】
本発明の更なる実施形態によれば、前記メタデータは保護接続又は同じネットワーク経路をたどる保護接続群のグループを識別するための、以後保護ＩＤとして示される専用の識別子を含んでもよい。
【００１２】
本発明の更なる実施形態によれば、前記メタデータはまた、保護接続のヘッド又はテールエンドポイントスイッチのアドレスを含んでもよい。
【００１３】
前記メタデータは既存のOpenFlow意味論に統合されていてもよい。
【００１４】
一実施形態によれば、前記スイッチ群は、前記メタデータを用いてローカルポート及び／又はリンクの障害により影響された接続群を識別してもよい。それに基づいて、前記スイッチ群は前記メタデータを用いてポート及び／又はリンク障害通知メッセージ群を生成しそれらを前記データプレーンを介して前記各ポート及び／又はリンクの障害に影響された保護接続群のエンドポイントスイッチ群に向けて送信してもよい。一実施形態によれば、図通知メッセージは、影響を受けた前記接続の前記ヘッド又はテールエンドポイントスイッチの前記アドレスを宛先アドレスとして保持し、影響を受けた前記接続の保護ＩＤをペイロードとして保持するように構成されてもよい。
【００１５】
一実施形態によれば、前記複数のスイッチの１つ又は複数は、前記スイッチ群が前記コントローラから受け取るメッセージ群からの前記メタデータを保持する拡張フィールド群を抽出する、OpenFlowエージェントであってもよいエージェントを備えてもよい。抽出された拡張フィールド群は、スイッチに設けられた特定のテーブル−拡張テーブル−に渡されてもよい。
【００１６】
既に述べたように、一実施形態によれば、前記スイッチ群はまた、前記OpenFlowエージェントから抽出した拡張フィールド群を受け取る拡張テーブルを備えてもよい。具体的に、拡張テーブルには、各スイッチのローカル出力ポート群と保護接続群のエンドポイントスイッチ群との対応付けが保存されてもよい。
【００１７】
一実施形態によれば、前記スイッチ群はまた、ローカルポート及び／又はリンクの障害に影響された保護接続群を識別し、前記メタデータに基づいて影響を受けた前記接続群のエンドポイントスイッチ群に向けたポート及び／又はリンク障害通知メッセージを生成する障害ロジックモジュールを備えてもよい。
【００１８】
一実施形態によれば、前記スイッチ群はまた、前記データプレーンからポート及び／又はリンク障害通知メッセージ群を抽出し前記メッセージ群を局所的に保護された転送ルール群に関連付ける障害ロジックモジュールを備えてもよい。このモジュールは、影響を受けた接続群のエンドポイントスイッチにおいて前記障害修正メッセージ群への反応を可能にするものであり、これらの接続群の保護経路への局所的なローカルスイッチオーバーを実行してもよい。
【００１９】
特に、本発明の実施形態によれば、関連技術における既存のソリューション、例えば、標準的なOpenFlow技術や一般的なＳＤＮスイッチアーキテクチャに対する以下の拡張を検討してもよい。
【００２０】
１）追加のメタデータの生成及び転送ルールを伴うＳＤＮスイッチへの配信を可能にするＳＤＮコントローラロジック及び関連するＳＤＮプロトコルメッセージへの拡張。そのようなメタデータは保護接続のエンドポイントスイッチ及びそれらのユニークな識別子についての情報を含み、保護接続の中間スイッチへの障害通知の移転を意図するものである。
【００２１】
２）追加のメタデータを抽出して各スイッチに局所的に保存しそれを局所的な転送アクションに関連付けることが可能なＳＤＮスイッチへの拡張。
【００２２】
３）ローカルリンク又はポートの障害に反応して保護接続のエンドポイントへ向かう障害通知メッセージを生成し、それらをデータプレーンに注入して迅速なメッセージの伝搬を可能にするＳＤＮスイッチへの拡張。そのために、すなわち、データプレーン内での障害メッセージの迅速な伝搬をサポートするために、スイッチは適当な転送ルールの組を有するように構成されてもよい。
【００２３】
４）接続エンドポイントにおいてデータプレーンから障害通知メッセージを抽出し、それらを局所的に保護された転送ルールに関連付け、保護接続のスイッチオーバーの実行に必要なアクションを実行するＳＤＮスイッチへの拡張。
【００２４】
本発明の内容を有利なやり方で設計し発展させる方法がいくつもある。このため、従属する請求項、及び図示された、例としての本発明の好適な実施形態についての以下の説明を参照されたい。図に補助された本発明の好適な実施形態の説明と関連して、本発明の内容の一般的に好適な実施形態及び更なる進展が説明されよう。
【図面の簡単な説明】
【００２５】
【図１】図１は標準的なOpenFlowローカル保護メカニズムを示すネットワーク例を示す概略図である。
【図２】図２は、本発明の実施形態による保護スイッチングアーキテクチャの一般概念を示す概略図である。
【図３】図３は、本発明の実施形態による１：１保護スキームの実装を示す概略図である。
【図４】図４は、本発明の実施形態による１＋１保護スキームの実装を示す概略図である。
【図５】図５は、本発明の実施形態によるネイバー交換プロトコルの例を示す概略図である。
【図６】図６は、本発明の実施形態によるリングプロテクションスキームの実装を示す概略図である。
【発明を実施するための形態】
【００２６】
図１は、FastFailoverグループによりOpenFlowプロトコルv.1.3.1+に実装された局所的障害のためのスイッチオーバーメカニズムを概略的に示す。このメカニズムによれば、あるスイッチがローカルポートの障害を検出した場合（例えば、隣接スイッチからの光学信号又はキープアライブメッセージを喪失した場合）、保護フローは次のライブバケット（すなわち、ポート又は論理ポートのグループ）に切り替えられる。このメカニズムを説明するため、図１に示された典型的なＳＤＮネットワーク１において、ＳＤＮコントローラ２はマッチ部及びアクション部を含むFlow-modメッセージによりフローを図１にＡ〜Ｅとして示されるＳＤＮスイッチ３に設定する。マッチフィールドは１つ又は複数のパケットヘッダーのエグザクト及び／又はワイルドカードを含んでもよい。アクション部には通常、フローの特定のインターフェースからの転送を含む１つ又は複数の命令が含まれる。図１は、宛先ＩＰアドレスフィールドにマッチするネットワーク10.0.10/24、10.0.20/24間のＬ３転送シナリオのために必要かつ十分な、各スイッチ３のフローテーブル４の内容を示す。
【００２７】
図示の例において、保護接続がＡ、Ｄとして示される２つのエンドポイントスイッチ５の間で確立されており、そこでは動作経路がＢ、Ｃとして示される中間スイッチ６を介しており、保護経路はＥとして示される中間スイッチ６を介している。各FastFailover保護グループは（例えば、Ａ、Ｂ間の）局所的なスイッチポート障害に反応してコントローラ、すなわち、ＳＤＮコントローラ２との対話なしにグループ内の保護ポートを選択することができる。しかしながら、スイッチＢ、Ｃ間のリンクに障害が発生した場合、保護接続のエンドポイントスイッチＡ、Ｄはこの障害に気づかず、その転送経路を切り替えない。ＳＤＮアーキテクチャ内でこのような問題を扱う一般的な方法は、局所的障害を検出しているスイッチに非同期メッセージPort_Status又はPacket-inを用いてコントローラに接触させることである。このメッセージに反応して、コントローラはFlow-modメッセージで保護経路を有効にする。しかしながら、この対話は遅いOpenFlowコントロールチャネルを経るものであり、スイッチオーバー時間はスイッチのアーキテクチャだけでなくＳＤＮコントローラ２のアーキテクチャにも依存する。そのため、スイッチオーバーはトポロジー非依存ではない。また、最近のコントローラアーキテクチャにおけるOpenFlow非同期メッセージの処理は通常いくつかの内部モジュール間の対話を必要とするため、スイッチオーバーは遅くなり、そのようなスイッチオーバーは特定のクリティカルなアプリケーションには受け入れがたい場合がある。
【００２８】
図２は、図１のシナリオとの関連で述べた欠点を克服することができる本発明の一実施形態による保護スイッチングアーキテクチャの一般的概念を概略的に説明する。本実施形態ではＳＤＮコントローラ２とＳＤＮスイッチ群３がOpenFlowプロトコルを用いることにより動作するが、ネットワークプレーン要素のリモートコントロールを可能にする同様の又は匹敵する特徴を持つ他のプロトコルを同様に用いてもよいことを当業者は容易に理解しよう。
【００２９】
動作及び保護経路の集中計算並びに対応するフローのＳＤＮコントローラ２からスイッチングエンジンへの配信を可能にするため、図示の実施形態において、標準的なOpenFlow意味論（特にFlow-modメッセージ構造）は以下の追加フィールドを用いて拡張される。すなわち、「保護フラグ」は各スイッチ３にフローが保護接続の一部か非保護接続の一部かを知らせる。「保護ＩＤ」は各保護接続の、又は特定のヘッド及びテールエンドポイントスイッチ５間の同一の経路をたどる保護接続のグループのユニークで局所的に有意味な識別子である。最後に、アイテム「ヘッド」又は「テール」は保護接続のヘッド又はテールエンドポイントスイッチ５のアドレスである。
【００３０】
上述のOpenFlowの拡張に関して、拡張フィールドは一般的なOpenFlow意味論に従属するため既に設定されたフロー内でOFPFC_MODIFY OpenFlowメッセージにより修正される場合があることに注意すべきである（例えば、保護経路をルート変更又は追加／削除する場合）。また、例えば、適切なフロー毎の統計収集又は保護スイッチオーバーに関するコントローラ２への通知を可能にするために、他のOpenFlowメッセージに対する適切な拡張を必要としてもよい。しかし、そのような拡張は障害のスイッチオーバーロジックに影響を与えることはなく、ここで更に検討はしない。
【００３１】
上記の拡張フィールドは、OpenFlow転送パイプラインのプログラミング抽象に反してはならない。このため、本発明の実施形態によれば、スイッチ３のOpenFlowエージェント７は、図２の（障害通知送信）スイッチ＃２に示されるように、これらのフィールドをFlow-modメッセージから抽出するように構成及び修正される。エージェント７は“保護フラグ”が有効にされた全てのフローを認識し拡張テーブル８を格納する。拡張テーブル８は、キーがFlow-modの転送アクションの出力ポートであり値には保護接続の“保護ＩＤ”と“ヘッド”（又は“テール”）のタプルが含まれるキー値のペアを持つハッシュテーブルとして実装されてもよい。このテーブル８は、例えば、通常「ベアメタル」（又はホワイトボックス）のスイッチングプラットフォームの一部である従来のＲＡＭメモリに保存されてもよい（Opennetlinux: https://opennetlinux.org/を参照）。抽出されたフィールドを持たないFlow-modメッセージはその後、通常のOpenFlowメッセージとして更に処理される。
【００３２】
また、スイッチ群３は更に、ローカルポート（又はリンク）の活性の記録をとり、ポート（又はリンク）に障害が発生した場合、障害を起こしたポートのＩＤをキーとして拡張テーブル８を検索し、影響を受けた接続の値、すなわち、“保護ＩＤ”及び“ヘッド”（又は“テール”）を抽出する特定の障害ロジックモジュール９を含んでもよい。障害ロジック９はスイッチの汎用ＣＰＵ上で実行されてもよく、（一般にOpennetlinux: https://opennetlinux.org/から知られるような）スイッチ３のＯＳの別個のソフトウェアモジュールとして実装されてもよい。障害ロジック９は、抽出された“ヘッド”又は“テール”の値を宛先アドレスとして“保護ＩＤ”をペイロードとして用いて影響を受けた接続のヘッドエンド又はテールエンドに向けた障害メッセージを生成する。このメッセージは、例えば、所定のＬ２／Ｌ３パケットテンプレートを抽出された値で満たすことにより生成することができる。“ヘッド”又は“テール”は任意の種類のＬ２／Ｌ３アドレス（例えば、リモートスイッチの管理又はループバックＩＰアドレス）であってもよく、またメッセージ配信のためのインバンド又はアウトオブバンド管理ネットワークを用いることができる。ヘッドエンド又はテールエンドのスイッチ５へ向かう途中にデータプレーン内に保持しながらメッセージを迅速に配信できるように、特定のユニキャスト又はマルチキャストフローの組を管理ネットワークに予め設定すべきである。このような障害通知の迅速な伝搬により、コントロールプレーンにおける（例えば、レガシー分配プロトコルにおける）ホップ毎の判断と比較して障害スイッチオーバーが加速される。
【００３３】
一度障害メッセージがその宛先（すなわち、各接続のヘッド又はテールエンドポイントスイッチ５）に到達すると、図示された典型的な（障害通知受信）スイッチ＃１に示されるように、データプレーンから抽出されレシーバーフェイルオーバーロジック１０に転送される。この論理１０は単一の拡張モジュール内でセンダーフェイルオーバーロジック９とコロケートされてもよい。レシーバー論理１０は保護経路へ切り替えられる必要のある接続の“保護ＩＤ”を抽出し、ｓｗｉｔｃｈｏｖｅｒ命令を基礎転送パイプラインに送る。このような命令は、例えば、保護フローの出力ポートを修正する局所的に生成されたFlow-modメッセージ、又はFastFailover OpenFlowグループに保護出力ポートに切り替えさせる「バケットダウン」メッセージであってもよい。ただし、後者の場合、フェイルオーバーロジック１０はある範囲の論理バケットを割り当て、個々のパケットを各“保護ＩＤ”に関連付けて接続のスイッチオーバーをローカル物理ポートのスイッチオーバーから独立した状態に維持しなくてはならない。
【００３４】
別の種類の障害メッセージを導入して復帰モードを実行してもよい。このメッセージは、ヘッド又はテールエンドポイントスイッチ５に、レシーバー論理１０にフローを動作経路へ再切り替えさせる復帰動作経路について通知することになる。
【００３５】
本発明の特定の実施形態を詳細に説明する前に、個々のステップの概要を示すために本発明の可能な実装についてより一般的なやり方で説明し、その後それらの特定の実施形態との関連でより詳細に説明する。一般的な実装によれば、以下のステップを実行してもよい。
【００３６】
１）ＳＤＮコントローラ内に動作及び保護経路を見つけるための経路計算メカニズムを定義する。
２）保護接続に保護ＩＤを割り当てる方法を定義する。
３）アドレスと転送フローとの特定の組を割り当ててＳＤＮスイッチにデータプレーンを介して互いに通信するのを可能にする。
４）拡張フィールドでOpenFlowメッセージの意味論を拡張する。
５）OpenFlowメッセージから拡張フィールドを抽出して保存し局所的な転送ルールに関連付けることを可能にする追加のロジックモジュールでＳＤＮスイッチのアーキテクチャを修正する。
６）局所的な障害が起きた場合拡張フィールドを参照することにより影響を受けた保護接続を特定することを可能にするＳＤＮスイッチのアーキテクチャを修正する。
７）障害通知メッセージを生成しかつそのようなメッセージを受け取りそれに反応することを可能にする追加のロジックでＳＤＮスイッチのアーキテクチャを修正する。
【００３７】
図３は、１：１保護スキームを実行する、すなわち、特定の保護経路を独占的に保護接続の特定の動作経路に割り当てる本発明の一実施形態を示す。このような１：１保護スキームは、動作経路に障害が発生した後だけの保護経路に沿ったトラフィックの伝搬を意味する。従って、このようなスキームの要件を満たす必要かつ十分な条件は、保護接続のヘッドエンドポイントスイッチ５において保護スイッチオーバーを実行することである。一方、テールエンドポイントスイッチ５は両経路から並立してトラフィックを受信することができる。障害メッセージは保護接続のヘッドエンドポイントスイッチ５へ転送する必要がある。
【００３８】
図３は、同様の参照符号は同様の構成要素を表す図１と同じネットワークアーキテクチャを示す。具体的には、図３は、本発明の実施形態に従って拡張されたスイッチＡ〜Ｄに設定されたFlow-modsを示す。図３はまた、スイッチＢ、Ｃ間にリンク障害が発生した場合の障害メッセージの伝搬とスイッチオーバーを示す。（中間スイッチＥを含む）保護経路の転送フローは（中間スイッチＢ、Ｃを含む）動作経路に設定されたフローと同じであるため、図３では省略されている。図３に示すように、各スイッチ３のフローテーブル４は、（各フローの宛先ネットワーク又はアドレスを含む）マッチ部と（各フローを転送するためのスイッチ３の出力ポートを指定する）アクション部とを含む。本発明の実施形態により導入されるフローテーブル４の拡張は、スイッチ３にフローが保護された（「Ｐ」）接続か保護されていない（「ｘ」）接続かを知らせるフラグ（「保護フラグ」）、各保護接続のユニークで局所的に有意味な識別子であるか特定のヘッド及びテールエンドポイントスイッチ５の間の同じ経路をたどる保護接続のグループであるＩＤ（「保護ＩＤ」）（図３において、ＩＤ「１」を有する唯一の保護接続に属するフロー、一方、ＩＤ「ｘ」を有する保護されていない接続に属するフロー）、及び保護接続のヘッドエンドポイントスイッチ５のアドレスを指定する「ヘッド」で表される部分を含む。
【００３９】
図３のシナリオはスイッチＢ、Ｃ間のリンク障害を想定している。スイッチＢの見地からは、その出力ポート２が影響を受ける。スイッチＢのフローテーブル４によれば、このポートはヘッドエンドポイントスイッチＡとの保護（フラグ「Ｐ」）接続（保護ＩＤ「１」）に属する宛先dst.ip = 10.0.20.0/24を持つトラフィックを扱うことに関わる。そのため、本発明の一実施形態によれば、（図２に示すような）スイッチＢの内部障害ロジックモジュール９は、抽出されたヘッド「Ａ」を宛先アドレスとし保護ＩＤ「１」をペイロードとして含む障害通知メッセージを生成する。このメッセージはデータプレーンに注入されエンドポイントスイッチＡに送信される。同様に、その出力ポート１がリンク障害の影響を受けている中間スイッチＣは、障害通知メッセージを生成して対応するヘッドエンドポイントスイッチＤに向けて送信する。
【００４０】
スイッチＢの障害通知メッセージは、エンドポイントスイッチＡで受信されると、データプレーンから抽出され（図２に示すような）スイッチＡのレシーバー障害ロジックモジュール１０）に転送される。このとき、本例ではＩＤ「１」を持つ接続である保護経路に切り替えられる必要のある接続の保護ＩＤが抽出される。それらの保護ＩＤに基づいて、障害ロジックモジュール１０は対応するスイッチオーバー命令を生成し基礎転送パイプラインに送る。その結果、スイッチＡのフローテーブル４から分かるように、ＩＤ「１」を持つ接続のトラフィックをネットワーク10.0.20.0/24へ転送するための出力ポートが出力ポート２から出力ポート３へ切り替わる。同様のアクションが、スイッチＣの障害通知メッセージを受信次第エンドポイントスイッチＤによりとられる。
【００４１】
同じ保護経路をＮ個の保護接続の間に割り当てることにより１：１  保護スキームから１：Ｎ保護スキームを端的に引き出してもよいことに注意されたい。ただし、保護経路に沿ったＮ個の全ての接続のためのフローを予め設定する必要があり、（例えば、優先順位と基準を考慮した）スイッチオーバーロジックを（例えば、ＱｏＳマークを優先順位とし利用可能な帯域幅バジェットを基準として）コントローラ側に実装する必要がある。
【００４２】
図４は１＋１保護スキームを実行する本発明の一実施形態を示す。図４も同様の参照符号が同様の構成要素を表す図１、３と同じネットワークアーキテクチャに関係する。
【００４３】
１＋１保護スキームは、動作経路に平行する保護経路に沿ったトラフィックの伝搬を意味する。保護スイッチオーバーがテールエンドポイントスイッチ５で起き、それにより、例えば、スイッチオーバー段階において１：１スキームと比べてパケット損失を減少させる場合がある。このとき、障害メッセージは（図４に示すように）保護接続のテールエンドポイントスイッチ５へ転送される必要がある。この違いは別にして、障害通知メッセージの生成及び送信は基本的に図３に関連して上述した方法に従う。
【００４４】
ただし、（例えば、インバンド管理シグナリングを有する）一部のケースでは、障害通知メッセージがテールエンドポイントスイッチに到達できない場合がある。これは、それらのメッセージが保護された単方向フローと同じ経路を用いる場合があるからである。この問題の第１の回避策は、障害メッセージを伝搬するために管理ネットワークフローが常に反対方向（従って、保護経路）を用いるようにＳＤＮコントローラ２がそれらの管理ネットワークフローを設定することであろう。代替の実施形態では、動作経路に沿ったスイッチ３がネイバー交換プロトコルを起動してもよい。このプロトコルは隣接スイッチのそれぞれに保護フローと隣接インターフェースを離れるそれらのテールについて知らせてもよい。各スイッチ３は隣接スイッチの情報を受信して（障害が発生したポートとは反対の方向に）障害通知メッセージをテールエンドポイントスイッチ５に伝搬する。図５は、（図４の実施形態の）スイッチＢ、Ｃ間で交換される必要がありテールエンドポイントスイッチ５への障害通知を可能にする、本発明の実施形態により拡張されたFlow-modメッセージの一部を示す。
【００４５】
図６はリングプロテクションスキームを実装する本発明の一実施形態を示す。リングプロテクションスキームを、障害スイッチオーバーがヘッドエンドポイントスイッチ５で発生する１：１保護スキームの特定の場合と見なしてもよい。ただし、トポロジー上の制約がある中で、リング内で動作する各スイッチ３がリング内にデータを挿入してもよく、又はそれを２つの方向のいずれかに転送してもよい。リングトポロジーにおける一般的な方法は、図６に示すように、１つの方向（例えば、時計回り）を動作方向（リング）としもう１つの方向を保護方向（リング）として転送を定義することである。適切なスイッチオーバーのために十分な情報には障害の方向と（障害が起きた後の）リング内の“最後のスイッチ”のアドレスが含まれるため、“保護ＩＤ”は省略されてもよい。障害メッセージは、障害を起こしたリンク（又はリングセグメント）に接続されたスイッチ３により全てのスイッチ３の共通アドレスに送られ保護方向に転送される必要がある。各スイッチ３のアドレスは動作リングに沿って昇順に割り当てられる。
【００４６】
各中間スイッチ３内のレシーバー障害ロジックモジュール９は、“最後のスイッチ”のアドレスを、設定された保護フローのテールと比べる。ロジック９は、“テール”＞“最後のスイッチ”である接続のスイッチオーバーを実行する。具体的に、図６は障害がリングトポロジーにおいてスイッチＢ、Ｃ間で発生する例を示す。この例で、各スイッチ３は以下のアクションを実行するように構成される：
【００４７】
−スイッチＢ、Ｃは障害を起こしたリンクに直接接続されているため、局所的なスイッチオーバーを実行する。
−スイッチＢは、保護リングの全体にわたって“最後のスイッチ”＝Ｂである障害修正メッセージを伝搬する。
−スイッチＡは、（“テール”＝Ｃ＞“最後のスイッチ”＝Ｂという事実を考慮して）出力ポート２から出力ポート３へのdst.ip=10.0.20.0/24にマッチするフローのスイッチオーバーを実行する。
−スイッチＤはdst.ip=10.0.20.0/24（“テール”＝Ｃ＞“最後のスイッチ”＝Ｂ）を持つフローのスイッチオーバーを実行し、dst.ip=10.0.10.0/24（“テール”＝Ａ＜“最後のスイッチ”＝Ｂ）の動作経路を維持する。
【００４８】
ここで説明した本発明の変形例や他の実施形態が、本発明が関係し上記の説明や添付の図面に示された内容の恩恵を受ける当業者により想到されよう。従って、本発明は開示された特定の実施形態に限定されるべきではなく、変形例や他の実施形態が添付の特許請求の範囲に含まれることが意図されていると理解すべきである。ここでは特定の用語が使われているが、それらは限定する目的ではなく一般的及び説明的意味で使われている。
【符号の説明】
【００４９】
１  ＳＤＮネットワーク
２  ＳＤＮコントローラ
３  ＳＤＮスイッチ
４  フロー  テーブル
５  エンドポイントスイッチ
６  中間スイッチ
７  OpenFlowエージェント
８  拡張  テーブル
９  障害ロジックモジュール、センダー
１０  障害ロジックモジュール、レシーバー
【図１】
2019510422.tif 000003
【図２】
2019510422.tif 000004
【図３】
2019510422.tif 000005
【図４】
2019510422.tif 000006
【図５】
2019510422.tif 000007
【図６】
2019510422.tif 000008
【国際調査報告】
2019510422.tif 000009