(57)【要約】【課題】複数のネットワークエレメントを分散的に制御する複数のコントローラ間の負荷の偏りを効率的に低減できるようにする。【解決手段】複数のネットワークエレメント（ＮＥ）４−１〜４−Ｎを複数のコントローラＣｉ（ｉは２以上の整数）で分散的に制御する。当該制御において、各コントローラＣｉがそれぞれ管理するＮＥ４−１〜４−Ｎ毎に、当該ＮＥ４と、当該ＮＥ４−１〜４−Ｎを管理するコントローラＣｉと、の間の通信に応じた処理量の特性を示す属性情報を取得する。取得した属性情報に基づいて、個々のコントローラＣｉが管理対象とするＮＥ４−１〜４−Ｎの割り当てを制御する。【選択図】図１
2016219859.tif 000002
【特許請求の範囲】
【請求項１】
複数のネットワークエレメントを複数のコントローラで分散的に制御するシステムにおいて前記複数のコントローラの中から選択された第１のコントローラであって、
前記第１のコントローラが管理するネットワークエレメント毎に得られる、当該ネットワークエレメントと前記第１のコントローラとの間の通信に応じた処理量の特性を示す属性情報に基づいて、前記第１のコントローラによる管理対象とするネットワークエレメントの選択を制御する選択制御部を備えた、コントローラ。
【請求項２】
前記選択制御部は、
前記第１のコントローラが管理する前記ネットワークエレメント毎に、当該ネットワークエレメントと前記第１のコントローラとの間で単位時間あたりに送受信される信号量を測定する測定部と、
前記測定部による測定結果を前記属性情報として用いて、前記第１のコントローラによる管理対象とするネットワークエレメントを変更する変更部と、を備えた、請求項１に記載のコントローラ。
【請求項３】
前記変更部は、
前記第１のコントローラが管理する前記ネットワークエレメントの中で、前記測定された前記信号量が相対的に多いネットワークエレメントを、前記変更の候補から除外する、請求項２に記載のコントローラ。
【請求項４】
前記変更部は、
前記第１のコントローラが管理する前記ネットワークエレメントの中で、前記変更の候補から除外された前記ネットワークエレメント以外のいずれかを、前記信号量と同種の信号量の過去の総量が相対的に少ない第２のコントローラの管理対象に変更する、請求項３に記載のコントローラ。
【請求項５】
前記変更部は、
前記各コントローラの中に最大負荷と最小負荷との差分が閾値を超えるコントローラが存在し、且つ、前記各コントローラ間で管理する前記ネットワークエレメントの数の差分が所定範囲に収まっている場合に、前記測定結果に基づいた前記変更を実施する、請求項２に記載のコントローラ。
【請求項６】
前記変更の候補から除外される前記ネットワークエレメントは、前記第１のコントローラが管理対象とする前記ネットワークエレメント毎に測定された前記信号量の総量のうち、閾値以上の割合を占める信号量が測定されたネットワークエレメントである、請求項３に記載のコントローラ。
【請求項７】
前記属性情報は、前記ネットワークエレメントが、ネットワークトポロジにおいてエッジに位置するかコアに位置するかを示す情報である、請求項１に記載のコントローラ。
【請求項８】
複数のネットワークエレメントを複数のコントローラで分散的に制御するシステムにおける前記各コントローラを制御する制御装置であって、
前記各コントローラがそれぞれ管理するネットワークエレメント毎に得られる、当該ネットワークエレメントと、当該ネットワークエレメントを管理するコントローラと、の間の通信に応じた処理量の特性を示す属性情報に基づいて、個々の前記コントローラが管理対象とするネットワークエレメントの割り当てを制御する、コントローラの制御装置。
【請求項９】
複数のネットワークエレメントを複数のコントローラで分散的に制御する制御方法であって、
前記各コントローラがそれぞれ管理するネットワークエレメント毎に、当該ネットワークエレメントと、当該ネットワークエレメントを管理するコントローラと、の間の通信に応じた処理量の特性を示す属性情報を取得し、
前記属性情報に基づいて、個々の前記コントローラが管理対象とするネットワークエレメントの割り当てを制御する、制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書に記載する技術は、コントローラ、コントローラの制御装置、及び、制御方法に関する。
【背景技術】
【０００２】
ソフトウェアでネットワーク全体の挙動を制御するＳＤＮ（Software Defined Networking）技術が注目されている。ＳＤＮを実現する一手法として、オープンフロー（OpenFlow, OF）（登録商標）と呼ばれる技術あるいはプロトコルが知られている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１３−３０８６３号公報
【特許文献２】特開２０１４−１３５６１４号公報
【特許文献３】特表２０１４−５０２７９６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ＯＦを適用したネットワークにおいて、複数のネットワーク機器を複数のコントローラにて分散的に制御することがある。ここで、コントローラの負荷に基づいた単純な負荷分散制御でコントローラ間の負荷を分散しようとしても、負荷の偏りがなかなか解消されず、負荷分散制御が収束しないことがある。
【０００５】
１つの側面では、本明細書の記載する技術の目的の１つは、複数のネットワークエレメントを分散的に制御する複数のコントローラ間の負荷の偏りを効率的に低減することにある。
【課題を解決するための手段】
【０００６】
１つの側面において、コントローラは、複数のネットワークエレメントを複数のコントローラで分散的に制御するシステムにおいて前記複数のコントローラの中から選択された第１のコントローラであってよい。第１のコントローラは、選択制御部を備えてよい。選択制御部は、第１のコントローラが管理するネットワークエレメント毎に得られる、当該ネットワークエレメントと第１のコントローラとの間の通信に応じた処理量の特性を示す属性情報に基づいて、第１のコントローラによる管理対象とするネットワークエレメントの選択を制御してよい。
【０００７】
また、１つの側面において、コントローラの制御装置は、複数のネットワークエレメントを複数のコントローラで分散的に制御するシステムにおける前記各コントローラを制御する制御装置であってよい。当該制御装置は、前記各コントローラがそれぞれ管理するネットワークエレメント毎に得られる、当該ネットワークエレメントと、当該ネットワークエレメントを管理するコントローラと、の間の通信に応じた処理量の特性を示す属性情報に基づいて、個々の前記コントローラが管理対象とするネットワークエレメントの割り当てを制御してよい。
【０００８】
更に、１つの側面において、複数のネットワークエレメントを複数のコントローラで分散的に制御する制御方法は、前記各コントローラがそれぞれ管理するネットワークエレメント毎に、当該ネットワークエレメントと、当該ネットワークエレメントを管理するコントローラと、の間の通信に応じた処理量の特性を示す属性情報を取得し、前記属性情報に基づいて、個々の前記コントローラが管理対象とするネットワークエレメントの割り当てを制御してよい。
【発明の効果】
【０００９】
１つの側面として、複数のネットワークエレメントを分散的に制御する複数のコントローラ間の負荷の偏りを効率的に低減できる。
【図面の簡単な説明】
【００１０】
【図１】一実施形態に係る通信システムの構成例を示すブロック図である。
【図２】図１に例示した通信システムの動作例を説明するための図である。
【図３】（Ａ）及び（Ｂ）は、図１に例示したオープンフローコントローラ（ＯＦＣ）を成すコントローラ間の負荷分散制御の一例を説明するための図である。
【図４】（Ａ）及び（Ｂ）は、図１に例示したＯＦＣを成すコントローラ間の負荷分散制御の一例を説明するための図である。
【図５】図１に例示したＯＦＣの構成例を示すブロック図である。
【図６】図１及び図５に例示したＯＦＣの動作例を示すフローチャートである。
【図７】（Ａ）及び（Ｂ）は、図１に例示したＯＦＣを成すコントローラ毎の負荷情報の計算例を説明するための図である。
【図８】図６に続くＯＦＣの動作例を示すフローチャートである。
【図９】図８に例示したスイッチ管理台数の不均衡判定処理の一例を説明するための図である。
【図１０】図８に続くＯＦＣの動作例を示すフローチャートである。
【図１１】（Ａ）〜（Ｃ）は、図１に例示したＯＦＣを成すコントローラ毎の処理量情報の一例を示す図である。
【図１２】（Ａ）〜（Ｃ）は、図１に例示したＯＦＣを成すコントローラ毎の処理量情報（スイッチ管理元変更後）の一例を示す図である。
【図１３】（Ａ）及び（Ｂ）は、図１に例示したＯＦＣを成すコントローラ毎の管理対象スイッチの情報の一例を示す図である。
【図１４】図１及び図５に例示したＯＦＣの動作例を示すフローチャートである。
【図１５】図１及び図５に例示したＯＦＣの動作例を示すフローチャートである。
【図１６】図１及び図５に例示したＯＦＣの動作例を示すフローチャートである。
【図１７】図１及び図５に例示したＯＦＣとの比較例を説明するための図である。
【図１８】図１及び図５に例示したＯＦＣとの比較例を説明するための図である。
【発明を実施するための形態】
【００１１】
以下、図面を参照して実施の形態を説明する。ただし、以下に説明する実施形態は、あくまでも例示であり、以下に明示しない種々の変形や技術の適用を排除する意図はない。また、以下に説明する各種の例示的態様は、適宜に組み合わせて実施しても構わない。なお、以下の実施形態で用いる図面において、同一符号を付した部分は、特に断らない限り、同一若しくは同様の部分を表す。
【００１２】
図１は、一実施形態に係る通信システムの構成例を示すブロック図である。図１に示す通信システム１は、例示的に、ネットワーク２と、コントローラ３と、を備えてよい。
【００１３】
例示的に、ネットワーク２は、ＳＤＮをサポートするネットワークであってよく、コントローラ３は、オープンフロープロトコル（ＯＦＰ）をサポートするオープンフローコントローラ（ＯＦＣ）であってよい。ＯＦＣ３は、ネットワークコントローラの一例である。
【００１４】
ネットワーク２には、ネットワークエレメント（ＮＥ）の一例として、複数のネットワーク機器４−１〜４−Ｎ（Ｎは２以上の整数）が備えられてよい。図１には、Ｎ＝１０の例を示している。ネットワーク機器４−ｋ（ｋは、１〜Ｎのいずれか）は、ＯＦＰをサポートするネットワークスイッチであってよい。
【００１５】
ＯＦＰをサポートする「ネットワークスイッチ」は、「ＯＦスイッチ（ＯＦ−ＳＷ）」と称してよい。「ＯＦスイッチ４−ｋ」を区別しなくてよい場合は、「ＯＦスイッチ４」又は「スイッチ４」と略称してよい。ＯＦスイッチ４によって形成されたネットワーク２は、「ＯＦネットワーク２」と言い換えてもよい。
【００１６】
ＯＦＣ３は、例示的に、ＯＦネットワーク２を形成する複数のＯＦスイッチ４を集中的に制御することが可能である。別言すると、ネットワーク２は、単一のＯＦＣ３によって集中的に全体の動作が制御されてよい。
【００１７】
例えば、ＯＦＣ３は、ＯＦスイッチ４のそれぞれと通信可能に接続されて、ＯＦスイッチ４間の通信を制御してよい。ＯＦＣ３とＯＦスイッチ４との間の接続には、ＴＣＰ（Transmission Control Protocol）やＴＬＳ（Transport Layer Security）が適用されてよい。別言すると、ＯＦＣ３とＯＦスイッチ４との間には、ＴＣＰやＴＬＳの「セッション」が設定、確立されてよい。
【００１８】
ＯＦスイッチ４間の通信は、例示的に、データプレーンにおけるデータの転送であり、「データフロー」又は単に「フロー」と称してもよい。「フロー」で転送されるデータは、パケットデータであってよい。パケットデータは、単に「パケット」と略称してよい。
【００１９】
ＯＦネットワーク２におけるフローの経路は、「データパス」と称されてよい。「データパス」は、ＯＦスイッチ４のそれぞれに割り当てられた「データパス識別子」（data path ID）を基に識別されてよい。
【００２０】
ＯＦＣ３は、ＯＦスイッチ４間のフローを一元的に管理、制御してよい。例えば、ＯＦＣ３は、ＯＦスイッチ４が記憶するフローテーブルのエントリを一元的に管理、制御してよい。
【００２１】
ＯＦスイッチ４間のフローを制御するために、ＯＦＣ３は、ＯＦネットワーク４のトポロジ情報を検出してよい。トポロジ情報は、ＯＦネットワーク２におけるＯＦスイッチ４間の接続関係を識別可能にする情報の一例である。トポロジ情報を基に、ＯＦネットワーク２についての経路計算等がＯＦＣ３において実施されてよい。
【００２２】
例えば、ＯＦＣ３は、ＯＦネットワーク２のトポロジ情報を基に、ＯＦネットワーク２全体としての省電力化を図る経路制御（「省電力経路制御」と略称してよい。）等の、高度なトラフィックエンジニアリングを実現できる。
【００２３】
また、ＯＦＣ３による制御の単位を「フロー」とし、既存のレイヤ構造を有する、いずれのネットワークの組み合わせにおいてもデータの流れを「フロー」で表現することよって、レイヤに依存しない通信制御が可能となる。
【００２４】
なお、「ＯＦ」は、ＯＦＰ等の特有のプロトコルを処理してネットワークを制御する技術の一例である。これに対し、「ＳＤＮ」は、ＯＦの概念を既存のネットワークプロトコルにまで拡大して、ＯＦＰをサポートしていないＮＥでも制御を可能にする技術の一例である。
【００２５】
次に、図２を参照して、通信システム１の動作例を説明する。ＯＦスイッチ４は、それぞれ、「フローテーブル」を有している。「フローテーブル」には、「フロー」単位に、「ルール」と、「ルール」に関連付けられた「アクション」と、が登録されてよい。
【００２６】
ＯＦスイッチ４にパケットが入力されると、ＯＦスイッチ４は、「フローテーブル」を参照し、「フローテーブル」に登録されている「ルール」にマッチした「アクション」を実行する。
【００２７】
入力パケットに対応する「ルール」が「フローテーブル」に未登録であった場合、ＯＦスイッチ４は、ＯＦＣ３宛に「ルール」を問い合わせるメッセージを送信してよい。当該メッセージは、「パケットイン（Packet-in）メッセージ」又は単に「パケットイン」と称されてよい。パケットインに、問い合わせ対象の入力パケットが含められてよい。パケットインは、ＯＦスイッチ４がＯＦＣ３宛に送信する信号の一例である。
【００２８】
ＯＦＣ３は、ＯＦスイッチ４からパケットインを受信すると、受信したパケットインに含まれているパケットに対応する「ルール」を、パケットインの送信元ＯＦスイッチ４に送信する。「ルール」の送信には、フロー変更（flow modification, FlowMod）メッセージが用いられてよい。フロー変更メッセージは、ＯＦＣ３がＯＦスイッチ４宛に送信する信号の一例である。
【００２９】
ＯＦスイッチ４は、ＯＦＣ３からフロー変更メッセージが受信されると、当該メッセージに設定されている「ルール」を「フローテーブル」に設定、登録する。「ルール」の「フローテーブル」への登録後に、ＯＦＣ３は、パケットインで受信したパケットを「パケットアウト（Packet-out）」と呼ばれるメッセージにてＯＦスイッチ４へ送信してよい。パケットアウトも、ＯＦＣ３がＯＦスイッチ４宛に送信する信号の一例である。
【００３０】
このように、ＯＦＣ３は、パケットインに対応する経路を決定し、決定した経路に位置するＯＦスイッチ４に対してフロー変更メッセージによって「ルール」の設定を行なう。「ルール」には、例示的に、マッチ条件（match rules）が記述され、マッチ条件に対して「アクション」が指定される。「アクション」には、入力パケットの転送に限らず、その他の動作が指定されてもよい。例えば、入力パケットの特定のヘッダフィールドを書き換える動作が「アクション」において指定されてもよい。
【００３１】
ＯＦＣ３が、ＯＦスイッチ４の動作を集中的に管理、制御することで、個々のＯＦスイッチ４は、高度な処理を自律的に実施してなくて済むので、単純で安価に構成できる。ただし、ＯＦＣ３による集中的な制御では、ネットワーク規模が拡大してＯＦスイッチ４の数が多くなると、ＯＦＣ３に、過度な負荷がかかり得る。
【００３２】
そこで、複数のコントローラで「クラスタ」を形成し、論理的には１つのコントローラとして動作する「分散ネットワークコントローラ」を、ＯＦＣ３に適用することが検討されている。非限定的な一例として、図１には、３つのコントローラＣ１，Ｃ２及びＣ３の「クラスタ」で１つのＯＦＣ３が構成された例を示している。
【００３３】
「クラスタ」を形成する個々のコントローラは、便宜的に、「エレメントコントローラ」あるいは「コントローラコンポーネント」と称してよい。例示的に、サーバ等のコンピュータが、エレメントコントローラに該当してよい。エレメントコントローラの数は、３つに限られず、２つでもよいし、４つ以上でもよい。
【００３４】
図１に例示するＯＦＣ３は、「分散ネットワークコントローラ」の一例であり、「コントローラクラスタ３」と称してもよい。コントローラクラスタ３は、各スイッチ４からは論理的な１つのコントローラとして認識される。
【００３５】
コントローラクラスタ３を成す複数のエレメントコントローラＣｉ（ｉは２以上の整数）によって、ＯＦスイッチ４の管理（「制御」と称してもよい。）が分担されてよい。したがって、図１に例示する通信システム１は、複数のスイッチ４を複数のコントローラＣｉで分散的に制御するシステムの一例である。
【００３６】
図１において、エレメントコントローラＣ１は、例示的に、ＯＦスイッチ４−１〜４−３の管理を担当してよい。エレメントコントローラＣ２は、例示的に、ＯＦスイッチ４−４〜４−７の管理を担当してよい。エレメントコントローラＣ３は、例示的に、ＯＦスイッチ４−８〜４−１０の管理を担当してよい。
【００３７】
なお、図１において、「ＳＷｉｊ」は、コントローラ番号「ｉ」のエレメントコントローラＣｉが管理を担当する、スイッチ番号「ｊ」のＯＦスイッチ４であることを表している。「ｊ」は、１以上の整数であってよい。
【００３８】
例えば、「ＳＷ１１」，「ＳＷ１２」及び「ＳＷ１３」は、それぞれ、エレメントコントローラＣ１が管理を担当するスイッチ番号「１」〜「３」のＯＦスイッチ４であることを表している。
【００３９】
同様に、「ＳＷ２１」，「ＳＷ２２」，「ＳＷ２３」及び「ＳＷ２４」は、それぞれ、エレメントコントローラＣ２が管理を担当するスイッチ番号「１」〜「４」のＯＦスイッチ４であることを表している。
【００４０】
また、「ＳＷ３１」，「ＳＷ３２」及び「ＳＷ３３」は、それぞれ、エレメントコントローラＣ３が管理を担当するスイッチ番号「１」〜「３」のＯＦスイッチ４であることを表している。
【００４１】
なお、コントローラ番号（ｉ）は、エレメントコントローラＣｉの識別情報の一例であると捉えてよく、スイッチ番号（ｊ）は、ＯＦスイッチ４の識別情報の一例であると捉えてよい。
【００４２】
ＯＦＣ３に、「コントローラクラスタ」として構成された「分散ネットワークコントローラ」を適用することで、ＯＦＣ３のスケーラビリティや耐障害性を向上できる。ただし、ＯＦＣ３を成す複数のエレメントコントローラＣｉの一部に、負荷（load）が偏るケースが生じ得る。
【００４３】
「負荷」は、エレメントコントローラＣｉが管理するＯＦスイッチ４の台数や、エレメントコントローラの負荷等に基づいて判断、決定されてよい。エレメントコントローラＣｉの負荷は、エレメントコントローラＣｉの動作を司るＣＰＵ（Central Processing Unit）等のプロセッサの使用率や、エレメントコントローラＣｉが動作に応じてアクセスするモリの使用率等に基づいて判断、決定されてよい。
【００４４】
複数のエレメントコントローラＣｉ間で負荷の偏りが無くなるか低減されるように、ＯＦＣ３において負荷分散制御を実施することで、ＯＦＣ３の安定的な運用が可能になる。負荷分散制御の一例としては、負荷を軽減したいエレメントコントローラＣｉが管理しているＯＦスイッチ４の一部を、相対的に低負荷の他のエレメントコントローラＣｉの管理対象に変更する制御が挙げられる。
【００４５】
なお、エレメントコントローラＣｉが管理対象とするＯＦスイッチ４を変更することは、ＯＦスイッチ４の管理元を変更すること、と言い換えてもよい。管理元が変更される前のＯＦスイッチ４を管理対象にしていたコントローラＣｉは、便宜的に、「変更元コントローラＣｉ」と称してよい。
【００４６】
当該ＯＦスイッチ４の新たな管理元となるコントローラＣｘ（ｘは、ｉがとり得る整数のうち、ｉとは異なる整数である。）は、便宜的に、「変更先コントローラＣｘ」と称してよい。「変更元コントローラ」は、「第１のコントローラ」の一例であり、「変更先コントローラ」は、「第２のコントローラ」の一例である。
【００４７】
しかし、上述のような負荷分散制御を、単純に個々のコントローラＣｉの負荷に基づいて実施しても、負荷分散が成功せず、なかなか負荷分散が収束しないケースが発生し得る。非限定的な一例として、以下の２つのケースが考えられる。
【００４８】
（ケース１）
管理元のコントローラＣｉを変更したＯＦスイッチ４についての処理が、変更元コントローラＣｉの負荷の大きな要因でなかった場合、変更元コントローラＣｉの負荷は、あまり軽減されない。そのため、再度の負荷分散制御が必要になることがある。例えば、コントローラＣｉの負荷を監視していても、どのＯＦスイッチ４についての処理が原因で当該コントローラＣｉの負荷が高くなっているのかを判別できないため、当該「ケース１」が生じ得る。
【００４９】
図３（Ａ）及び図３（Ｂ）に、負荷分散が成功しない「ケース１」の一例を模式的に示す。なお、コントローラＣｉの負荷は、例示的に、ＣＰＵ使用率やメモリ使用率に基づいて「０．０〜１．０」の範囲の数値として計算されるものと仮定する。
【００５０】
図３（Ａ）に例示するように、コントローラＣ１，Ｃ２，Ｃ３の負荷が、それぞれ、「０．８，０．３，０．２」であり、負荷に偏りが生じているとする。ここで、負荷分散制御によって、例えば、最大負荷（０．８）のコントローラＣ１が管理元の「ＳＷ１１」，「ＳＷ１２」及び「ＳＷ１３」のうちのいずれか１つ（例えば、「ＳＷ１１」）を、最小負荷（０．２）のコントローラＣ３による管理に変更する。
【００５１】
仮に、「ＳＷ１１」についての処理負荷が「０．０２」であり、コントローラＣ１の負荷の大きな要因でなかった場合、図３（Ｂ）に例示するように、変更元コントローラＣ１の負荷は「０．７８」となり、変更先コントローラＣ３の負荷は「０．２２」となる。したがって、変更元コントローラＣ１の負荷は軽減されず、再度の負荷分散制御が必要になる。
【００５２】
（ケース２）
「ケース１」とは逆に、管理元のコントローラＣｉを変更したＯＦスイッチ４についての処理が当該コントローラＣｉの負荷の大きな要因であった場合、変更先コントローラＣｘの負荷が高くなり過ぎてしまうことがある。この場合も、再度の負荷分散制御が必要になり得る。
【００５３】
図４（Ａ）及び図４（Ｂ）に、負荷分散が成功しない「ケース２」の一例を模式的に示す。図４（Ａ）及び図４（Ｂ）は、図３（Ａ）及び図３（Ｂ）に例示した「ケース１」のように負荷分散が成功しなかった場合に、再度（２回目）の負荷分散制御が実施されるケースを例示している。
【００５４】
図４（Ａ）に例示するように、「ケース１」での１回目の負荷分散制御によって、コントローラＣ１，Ｃ２，Ｃ３の負荷が、それぞれ、「０．７８，０．３，０．２２」になっていると仮定する。２回目の負荷分散制御において、例えば、最大負荷（０．７８）のコントローラＣ１が管理元の「ＳＷ１２」を、最小負荷（０．２２）のコントローラＣ３による管理に変更する。
【００５５】
ここで、仮に「ＳＷ１２」についての処理負荷が「０．５８」であり、コントローラＣ１の負荷の大きな要因であった場合、図４（Ｂ）に例示するように、変更元コントローラＣ１の負荷は「０．２」と大きく軽減される。しかし、変更先コントローラＣ３の負荷が、「０．８」と大きく上昇してしまうため、再度、コントローラＣ１〜Ｃ３間に負荷の偏りが生じる。そのため、再度の負荷分散制御が必要になる。
【００５６】
以上のような「ケース１」及び「ケース２」の発生を防止あるいは抑制するために、本実施形態では、コントローラＣｉ間の負荷の偏りを効率的に低減して負荷分散制御を迅速に収束できるようにする。負荷分散制御の迅速な収束によって、ＯＦＣ３の安定的な運用が可能となり、ひいては、ネットワーク２の安定的な運用を実現できる。
【００５７】
例えば、本実施形態のＯＦＣ３は、例示的に、どのスイッチ４についてのどのような処理が、エレメントコントローラＣｉの負荷の要因になっているかを判定する。負荷要因の「判定」は、「識別」又は「特定」と称してもよい。
【００５８】
負荷要因の判定を可能にするため、ＯＦＣ３は、個々のコントローラＣｉと、個々のコントローラＣｉが管理対象とする各スイッチ４と、の間の通信に応じた処理量の特性を示す情報を、スイッチ毎に記憶媒体に記憶してよい。当該情報は、便宜的に、スイッチ４の「属性情報」、「特性情報」あるいは「詳細情報」と称してよい。
【００５９】
「属性情報」の一例は、個々のスイッチ４からＯＦＣ３宛に送信される信号（例えば、パケットイン）の数である。パケットインの数が、スイッチ４毎に記憶媒体に記録されてよい。「属性情報」の他の一例は、ＯＦＣ３が個々のスイッチ４宛に送信する信号（例えば、フロー変更メッセージやパケットアウト）の数である。フロー変更メッセージやパケットアウトの数が、スイッチ４毎に記憶媒体に記録されてよい。記憶媒体には、フラッシュメモリや、ハードディスクドライブ（ＨＤＤ）、ソリッドステートドライブ（ＳＳＤ）等を適用してよい。
【００６０】
パケットインの数は、ＯＦＣ３が個々のスイッチ４からの要求や問い合わせに応じた処理の実行に関わる処理量を表す指標の一例であると捉えてもよい。例えば、データプレーンで新しい通信が発生したことに起因して、スイッチ４からＯＦＣ３宛にパケットインが送信される。フロー変更メッセージやパケットアウトの数は、ＯＦＣ３が個々のスイッチ４に対して実施する制御に関わる処理量を表す指標の一例であると捉えてもよい。
【００６１】
通常時において、ＯＦＣ３は、記録したスイッチ４毎の「属性情報」を参照せずに、コントローラＣｉ毎の負荷を監視してよい。これにより、スイッチ４の「詳細情報」である「属性情報」をＯＦＣ３が頻繁にアクセスすることによるＯＦＣ３の処理負荷の上昇を回避あるいは抑制できる。
【００６２】
ＯＦＣ３は、負荷監視において、コントローラＣｉ間の負荷に偏りが生じていることを検出すると、「詳細情報」にアクセスしてよい。例えば、負荷に偏りが生じているコントローラＣｉ間で、管理しているスイッチ４の台数が同じであるか、実質的に同じであると判断してよければ、ＯＦＣ３は、「詳細情報」にアクセスして「詳細情報」を確認してよい。
【００６３】
ＯＦＣ３は、「詳細情報」を基に、相対的に負荷の高いコントローラＣｉの負荷要因となっている特定のスイッチ４の有無を確認してよい。
【００６４】
例えば、単位時間あたりにＯＦＣ３が送信したトータルのフロー変更メッセージ数のうち、特定の割合以上（例えば、６０％以上）のフロー変更メッセージ数が送信先となっているスイッチ４が存在することがある。このようなスイッチ４の存在が確認されれば、ＯＦＣ３は、当該スイッチ４を「フロー変更（FlowMod）多」のスイッチ４として特定してよい。パケットアウトについても同様でよい。
【００６５】
パケットインについても同様に、単位時間あたりに受信したトータルのパケットイン数のうち、特定の割合以上（たとえば６０％以上）のパケットイン数が送信元となっているスイッチ４が存在することがある。このようなスイッチ４の存在が確認されれば、ＯＦＣ３は、当該スイッチ４を「パケットイン多」のスイッチ４として特定してよい。
【００６６】
なお、「スイッチ４の特定」は、「スイッチ４の識別」又は「スイッチ４の判定」と言い換えてもよい。また、「フロー変更メッセージ数」及び「パケットイン数」は、「メッセージ数」と総称してもよい。
【００６７】
「メッセージ数」に応じた数又は量の処理がコントローラＣｉによって実施されるから、「メッセージ数」は、「メッセージ処理数」又は「メッセージ処理量」と言い換えてもよい。
【００６８】
したがって、「フロー変更メッセージ数」及び「パケットイン数」は、それぞれ、「フロー変更メッセージ処理数（又は処理量）」及び「パケットイン処理数（又は処理量）」と言い換えられてよい。「メッセージ」は、「信号」の一例であり、「データ」と言い換えられてもよい。
【００６９】
上述のごとく「フロー変更多」や「パケットイン多」のスイッチ４を特定できれば、ＯＦＣ３は、特定したスイッチ４を、管理元コントローラＣｉを変更するスイッチ候補から除外してよい。
【００７０】
その理由は、当該スイッチ４の管理元を変更すると、既述の「ケース２」のように、変更先コントローラＣｘの負荷が高くなり過ぎる可能性があるからである。
【００７１】
なお、エレメントコントローラＣｉが管理を担当する各スイッチ４についての処理量に偏りが無ければ、ＯＦＣ３は、上述したスイッチ４の特定は実施しなくても構わない。ＯＦＣ３は、例えば、相対的に高負荷のコントローラＣｉが管理しているスイッチ数が減るように、いずれかのスイッチ４の管理元コントローラＣｉを変更してよい。
【００７２】
変更先コントローラＣｘを選ぶ際には、ＯＦＣ３は、変更先コントローラＣｘが管理しているスイッチ４の「属性情報」を確認してよい。例えば、現在（又は過去に）「パケットイン多」のスイッチ４、あるいは、現在（又は過去に）「フロー変更多」のスイッチ４が、管理元を変更するスイッチ候補になることがある。
【００７３】
この場合、ＯＦＣ３は、次表１に例示するように、変更先コントローラＣｘにおいて過去に「パケットイン多」であったスイッチ４の有無、及び、「フロー変更多」であったスイッチ４の有無をチェックしてよい。
【００７４】
【表１】
2016219859.tif 000003
【００７５】
例えば、過去に「パケットイン多」であったスイッチ４を、現在（又は過去に）「パケットイン多」のスイッチ４を管理するコントローラＣｉの管理対象に変更すると、当該変更先コントローラＣｉで処理するパケットインが多くなり過ぎる可能性がある。
【００７６】
また、過去に「フロー変更多」であったスイッチ４を、現在（又は過去に）「フロー変更多」のスイッチ４を管理するコントローラＣｉの管理担当に変更すると、当該変更先コントローラＣｉで処理するフロー変更メッセージが多くなり過ぎる可能性がある。
【００７７】
そのため、ＯＦＣ３は、過去に「パケットイン多」又は「フロー変更多」であったスイッチ４を相対的に多く管理するコントローラＣｉを、変更先コントローラの候補から除外してよい。あるいは、ＯＦＣ３は、そのようなコントローラＣｉが変更先コントローラＣｘに選ばれにくくなるように、コントローラＣｉに対して選択の優先度や重み付けを付与してもよい。
【００７８】
別言すると、ＯＦＣ３は、現在又は過去にコントローラＣｉの負荷上昇の要因となったスイッチ４の新たな管理元に、過去に負荷の高い状況を経験したコントローラＣｉが、選ばれないか選ばれにくくなるように、変更先コントローラＣｉの選択を制御してよい。
【００７９】
例えば、ＯＦＣ３は、現在又は過去のパケットイン数やフロー変更メッセージ数の処理量がなるべく少ないコントローラＣｉを、変更先コントローラＣｉに優先的に選んでよい。なお、現在の負荷が相対的に低いコントローラＣｉは、現在においてパケットインやフロー変更メッセージの処理数も少ないはずであると判断してよい。
【００８０】
このようなスイッチ４の属性情報に基づく変更先コントローラＣｉの選択制御によって、スイッチ管理元の変更後に、変更先コントローラＣｉの特定のメッセージ処理、例えばパケットイン処理またはフロー変更メッセージ処理が多くなり過ぎることを防止あるいは抑制できる。したがって、変更先コントローラＣｉが過負荷に陥ることを防止あるいは抑制できる。
【００８１】
例えば、以下の２つのケースを想定してみる。
【００８２】
（ケース１）２台のスイッチ４のフロー変更メッセージ（Flowmod）処理数がいずれもどちらも「１０」（合計で「２０」）であり、パケットイン処理数がいずれも「２００」（合計で４００）である。
【００８３】
（ケース２）２台のスイッチ４の１つは、フロー変更メッセージ処理数が「２００」であり、パケットイン処理数が「１０」である。もう１つのスイッチ４は、フロー変更メッセージ処理数が「１０」であり、パケットイン処理数が「２００」である。
【００８４】
ケース１では、２つのスイッチ４を管理するコントローラＣｉにとって、フロー変更メッセージ処理数は「２０」であり、パケットイン処理数は「４００」である。
【００８５】
これに対し、ケース２では、フロー変更メッセージ処理数が「２１０」であり、パケットイン処理数は「２１０」である。フロー変更メッセージ処理とパケットイン処理とは別の処理であるため、合計値としてはいずれも「４２０」であり同じであるが、ケース１よりもケース２の方が、特定の処理に集中していない状況であり、コントローラＣｉの負荷はより分散されているといえる。
【００８６】
したがって、表１に例示したようなスイッチ４の属性情報に基づく変更先コントローラＣｉの選択制御を実施することで、フロー変更メッセージ処理とパケットイン処理との一方に処理負荷が偏ることを回避あるいは抑制することができる。
【００８７】
なお、ＯＦＣ３は、メッセージ処理数に代えて（あるいは追加して）、ネットワーク２のトポロジにおけるスイッチ４の位置（例えば、エッジ又はコア）を確認して、管理元コントローラＣｉを変更するスイッチ４を選ぶようにしてもよい。
【００８８】
例えば、ネットワーク２の「エッジ」は、新たなパケットが流入する「入り口」に相当するため、「エッジ」に位置するスイッチ４（「エッジスイッチ４」と称してよい。）は、ＯＦＣ３宛に送信するパケットイン数が多くなる傾向にある。
【００８９】
これに対し、「エッジ」には相当しない、ネットワーク２の「コア」に位置するスイッチ４（「コアスイッチ４」と称してよい。）は、ネットワーク２の中心に位置するほど、当該コアスイッチ４を経由する経路数がエッジスイッチ４よりも増える傾向にある。そのため、コアスイッチ４は、経路設定のためにＯＦＣ３から投入されるフロー変更メッセージ数が、エッジスイッチ４よりも多くなる傾向にある。
【００９０】
したがって、ＯＦＣ３は、スイッチ４のネットワーク２における位置に応じた、メッセージ種別毎のメッセージ数の傾向を基に、管理元コントローラＣｉを変更する対象のスイッチ４を選定してよい。
【００９１】
例えば、スイッチ４毎に、「エッジスイッチ」であるか「コアスイッチ」であるかを示す情報がＯＦＣ３において記憶されてよい。当該情報は、便宜的に、「スイッチ毎種別情報」と称してよい。「スイッチ毎種別情報」は、スイッチ４の「属性情報」の一例である、と捉えてもよい。
【００９２】
（ＯＦＣ３の構成例）
以下、上述したようなエレメントコントローラＣｉ間の負荷分散制御を実現するＯＦＣ３の構成例について、図５を参照して説明する。なお、「エレメントコントローラＣｉ間の負荷分散制御」は、スイッチ４毎の「属性情報」に基づいた、管理元コントローラＣｉを変更するスイッチ４の選択制御と、変更先コントローラＣｉの選択制御と、を含む概念であってよい。
【００９３】
図５は、ＯＦＣ３の構成例を示すブロック図である。図５に例示するように、ＯＦＣ３は、エレメントコントローラＣｉと、エレメントコントローラＣｉに対応した処理モジュール３１−ｉと、メッセージ処理部３２と、コントローラアプリケーション３３と、記憶部３４及び３５と、を備えてよい。なお、処理モジュール３１−ｉを区別しなくてよい場合は、単に「処理モジュール３１」と表記することがある。
【００９４】
処理モジュール３１−ｉは、対応するエレメントコントローラＣｉと通信可能に接続されて、当該エレメントコントローラＣｉと、当該エレメントコントローラＣｉが管理するスイッチ４のいずれかと、の間の通信に応じた処理を担当する。
【００９５】
また、処理モジュール３１−ｉのそれぞれは、メッセージ処理部３２との間で情報を送受信することが可能であり、記憶部３４及び３５にアクセスして情報を書き込んだり読み出したりすることも可能である。
【００９６】
処理モジュール３１−ｉは、エレメントコントローラＣｉによる管理対象とするスイッチ４の選択（あるいは割当）を制御する選択制御部の一例である。
【００９７】
なお、処理モジュール３１−ｉにおいて実現される後述の機能（「機能」は後述するように「プロセス」として生成されてもよい。）の一部又は全部は、対応するエレメントコントローラＣｉに含まれていてもよい。例えば、処理モジュール３１−ｉの後述する機能やプロセスの一部又は全部が、エレメントコントローラＣｉを司る機能やプロセスに統合されていてもよい。
【００９８】
メッセージ処理部３２は、各処理モジュール３１−ｉとコントローラアプリ３３との間で送受信される、パケットインやフロー変更メッセージ等のメッセージを処理する。
【００９９】
例えば、メッセージ処理部３２は、処理モジュール３１−ｉのいずれかからパケットインを受信すると、パケットインの処理要求をコントローラアプリケーション３３に発行する。
【０１００】
メッセージ処理部３２は、コントローラアプリケーション３３から、パケットインの処理要求に対する処理結果の一例として、フロー変更メッセージの設定情報を受信する。当該設定情報の受信に応じて、メッセージ処理部３２は、当該設定情報を設定するスイッチ４の管理元コントローラＣｉの処理モジュール３１−ｉに送信する。
【０１０１】
例えば、「ＳＷ１２」、「ＳＷ２１」、「ＳＷ２２」、及び、「ＳＷ３１」に対するフロー変更メッセージであれば、メッセージ処理部３２は、コントローラＣ１、Ｃ２及びＣ３に対応する処理モジュール３１−１〜３１−３に、それぞれ、以下の設定情報を渡す。
【０１０２】
Ｃ１対応の処理モジュール３１−１：「ＳＷ１２」用の設定情報
Ｃ２対応の処理モジュール３１−２：「ＳＷ２１」及び「ＳＷ２２」用の設定情報
Ｃ３対応の処理モジュール３１−３：「ＳＷ３１」用の設定情報
【０１０３】
コントローラアプリケーション３３は、上述のように、メッセージ処理部３２からの処理要求に応じた処理を実施して、処理結果をメッセージ処理部３２に返信する。
【０１０４】
処理モジュール３１−ｉのそれぞれは、図５に例示するように、パケット処理部３１１と、負荷分散部３１２と、コントローラ−スイッチ対応付け制御部３１３と、を備えてよい。
【０１０５】
パケット処理部３１１は、エレメントコントローラＣｉが送受信するメッセージ（パケットインやフロー変更メッセージ等）を処理し、また、メッセージの処理量をカウントすることが可能である。
【０１０６】
そのため、パケット処理部３１１は、例示的に、パケットイン（Packet-in）処理部３１１１と、フロー変更メッセージ（FlowMod）処理部３１１２と、処理量カウント部３１１３と、を備えてよい。
【０１０７】
パケットイン処理部３１１１は、例示的に、対応するコントローラＣｉからパケットインを受信すると、受信したパケットインの内容をメッセージ処理部３２に送信する。
【０１０８】
フロー変更メッセージ処理部３１１２は、例示的に、メッセージ処理部３２から受信した、フロー変更メッセージに設定する情報を基に、フロー変更メッセージを生成して、対応するコントローラＣｉに送信する。
【０１０９】
処理量カウント部３１１３は、コントローラＣｉが管理するスイッチ４毎に、当該スイッチ４とコントローラＣｉとの間で単位時間あたりに送受信される信号量を測定する測定部の一例である。処理量カウント部３１１３によるカウント（測定）結果が、スイッチ４の「属性情報」として用いられてよい。
【０１１０】
例示的に、処理量カウント部３１１３は、パケットイン処理部３１１１で処理されたパケットインの処理数をスイッチ４毎にカウントしてよい。また、処理量カウント部３１１３は、例示的に、フロー変更メッセージ処理部３１１２で処理されたフロー変更メッセージの処理数をスイッチ４毎にカウントしてよい。なお、処理量カウント部３１１３は、パケットアウトの処理数をスイッチ４毎にカウントしてもよい。
【０１１１】
パケット処理部３１１は、処理量カウント部３１１３でカウントされたスイッチ４毎のパケットイン処理数及びフロー変更メッセージ処理数を、例えば記憶部３５に記憶してよい。スイッチ４毎のパケットイン処理数及びフロー変更メッセージ処理数は、「スイッチ毎処理量情報」の一例である。「スイッチ毎処理量情報」は、コントローラＣｉに対応する処理モジュール３１−ｉのそれぞれにおいて得られる。
【０１１２】
なお、記憶部３５には、「スイッチ毎処理量情報」と共に、コントローラＣｉ毎の負荷情報が記憶されてよい。コントローラＣｉの負荷情報は、負荷分散部３１２によって監視されて記憶部３５に記憶されてよい。そのため、記憶部３５は、便宜的に「負荷情報記憶部３５」と称してもよい。また、記憶部３５には、スイッチ４毎に「エッジスイッチ」であるか「コアスイッチ」であるかを示す情報（スイッチ毎種別情報）が記憶されてもよい。
【０１１３】
記憶部３４には、コントローラＣｉとスイッチ４との対応付け（「関連付け」と言い換えてもよい。）を示す情報が記憶されてよい。「対応付けを示す情報」は、例示的に、どのコントローラＣｉがどのスイッチ４を管理対象としているかを示す情報であり、便宜的に、「コントローラ対スイッチ対応情報」と称してよい。そのため、記憶部３４は、便宜的に、「コントローラ対スイッチ対応情報記憶部３４」と称してもよい。
【０１１４】
なお、記憶部３４及び３５は、図５に例示するように個別の記憶部（あるいは記憶装置）であってもよいし、１つの記憶部（あるいは記憶装置）のエレメントや記憶領域に該当してもよい。記憶部３４及び３５の一方又は双方は、ＯＦＣ３の外部機器に備えられていてもよい。
【０１１５】
処理モジュール３１−ｉの負荷分散部３１２は、例示的に、記憶部３４及び３５に記憶された情報を基に、コントローラＣｉ間の負荷の偏りが低減されるように、コントローラＣｉとスイッチ４との対応付けを制御してよい。そのため、負荷分散部３１２は、「ロードバランサ３１２」と称してもよい。「対応付けの制御」は、コントローラ−スイッチ対応付け制御部３１３と連携して実施されてよい。
【０１１６】
「対応付け」を制御することは、個々のコントローラＣｉが管理対象とするスイッチ４の選択を制御すること、と捉えてもよいし、各コントローラＣｉが管理対象とするスイッチ４の割り当て（又は振り分け）を制御すること、と捉えてもよい。
【０１１７】
ロードバランサ３１２は、図５に例示するように、管理台数不均衡チェック部３１２１と、高負荷スイッチ判定部３１２２と、を備えてよい。
【０１１８】
管理台数不均衡チェック部３１２１は、例示的に、記憶部３４に記憶された「コントローラ対スイッチ対応情報」を基に、コントローラＣｉ間で管理しているスイッチ４の台数に偏り（別言すると、不均衡）が生じているか否かをチェックする。
【０１１９】
高負荷スイッチ判定部３１２１は、例示的に、記憶部３５に記憶された「スイッチ毎処理情報」を基に、既述のように、或る閾値以上の処理量を占めるスイッチ４（便宜的に「高負荷スイッチ４」と称してよい。）を判定、特定する。
【０１２０】
コントローラ−スイッチ対応付け制御部３１３（以下「対応付け制御部３１３」と略称することがある。）は、ロードバランサ３１２と連携して、コントローラＣｉとスイッチ４との対応付けを制御する。
【０１２１】
例えば、対応付け制御部３１３は、ロードバランサ３１２と連携して、どのスイッチ４の管理元を、どのコントローラＣｉに設定するかを決定し、当該決定に応じて記憶部３４の「コントローラ対スイッチ対応情報」を更新する。
【０１２２】
なお、対応付け制御部３１３は、「コーディネータ３１３」又は「コーディネートシステム３１３」と称してもよい。コーディネータ３１３は、ロードバランサ３１２の一機能として、ロードバランサ３１２に組み込まれていてもよい。
【０１２３】
各処理モジュール３１−ｉは、記憶部３４の「コントローラ対スイッチ対応情報」に従って、コントローラＣｉに対応付けられたスイッチ４の管理や制御を実施する。したがって、「コントローラ対スイッチ対応情報」が更新によって変更されれば、結果的に、スイッチ４の管理元コントローラＣｉが変更される。
【０１２４】
別言すると、対応付け制御部３１３（又は、ロードバランサ３１２及び対応付け制御部３１３）は、スイッチ４の「属性情報」を基に、コントローラＣｉによる管理対象とするスイッチ４を変更する変更部の一例である。
【０１２５】
なお、「コントローラＣｉ間の負荷分散制御」は、各処理モジュール３１−ｉのうち、リーダに選定された１つの処理モジュール（「リーダモジュール」と称してよい。）３１−ｉが実施する設定でよい。
【０１２６】
複数の処理モジュール３１−ｉがパラレルに負荷分散制御を実施する設定にすると、処理モジュール３１−ｉ間の通信や調停制御等が生じて、負荷分散制御が複雑化するおそれがあるためである。リーダモジュール３１−ｉの選定は、ランダムでよい。
【０１２７】
また、上述した処理モジュール３１−ｉ及びメッセージ処理部３２は、例示的に、ＣＰＵ等の演算能力を備えたプロセッサが、記憶媒体に記憶されたプログラムやデータを読み取って動作することで生成される「プロセス」であってよい。演算能力を備えた「プロセッサ」は、「プロセッサ回路」又は「プロセッサデバイス」と称してもよいし、「コンピュータ」と称してもよい。
【０１２８】
したがって、処理モジュール３１−ｉ及びメッセージ処理部３２は、それぞれ便宜的に、「処理モジュールプロセス３１−ｉ」及び「メッセージ処理プロセス３２」と称されてもよい。「プロセス」の実行によって、上述した負荷分散制御を実施可能なＯＦＣ３としての機能が具現される、と捉えてよい。
【０１２９】
ＯＦＣ３において上述した負荷分散制御を具現する「プロセス」を生成可能なプログラムは、便宜的に、「負荷分散制御プログラム」と称してよい。「プログラム」は、「アプリケーション」又は「ソフトウェア」と称されてもよい。
【０１３０】
「負荷分散制御プログラム」を改変して「プロセス」を増やしたり減らしたりすることで、例えば、処理モジュール３１−ｉを増やしたり減らすことが容易に可能であるため、ＯＦＣ３が扱う処理の負荷変動に柔軟に対応することが可能になる。
【０１３１】
「負荷分散制御プログラム」は、記憶媒体に記憶された形態で提供されてもよいし、有線又は無線の通信回線を介して提供（別言すると、「ダウンロード」）されてもよい。例えば、フラッシュメモリ等の記憶媒体に記憶された「負荷分散制御プログラム」が、記憶部３４又は３５にインストールされてよい。また、サーバからダウンロードした「負荷分散制御プログラム」が、記憶部３４又は３５にインストールされてよい。
【０１３２】
負荷分散制御プログラムを実行するプロセッサは、エレメントコントローラＣｉに搭載されたＣＰＵ等のプロセッサとは個別のプロセッサであってもよいし、いずれかのエレメントコントローラＣｉに搭載されたプロセッサと共用でもよい。
【０１３３】
なお、処理モジュール３１−ｉ及びメッセージ処理部３２は、個別のハードウェアにて実現されてもよい。また、処理モジュール３１−ｉ及びメッセージ処理部３２は、独立したソフトウェアによって実現されてよい。
【０１３４】
処理モジュール３１−ｉを実現するソフトウェアと、メッセージ処理部３２を実現するソフトウェアと、は、サーバ等の同じコンピュータにインストールされてもよいし、異なるコンピュータにインストールされて、個々のコンピュータにおいて動作してもよい。
【０１３５】
（動作例）
以下、本実施形態のＯＦＣ３の動作例として「エレメントコントローラＣｉ間の負荷分散制御」に着目した処理について、図６〜図１６を参照して説明する。
【０１３６】
図６に例示するように、リーダに選定された処理モジュール３１−ｉ（以下、単に「リーダモジュール３１」と称することがある。）は、ロードバランサ３１２によって、負荷情報記憶部３５から、コントローラＣｉ毎の負荷情報を読み出す（処理Ｐ１１）。
【０１３７】
なお、コントローラＣｉ毎の負荷情報は、例示的に、各コントローラＣｉに対応する処理モジュール３１−ｉのそれぞれで計算されてよく、その計算結果がそれぞれ負荷情報記憶部３５に記憶されてよい。
【０１３８】
負荷情報は、例示的に、コントローラＣｉのＣＰＵ使用率やメモリ使用量、スイッチ管理台数等の情報を基にして計算されてよい。例えば、ＣＰＵ使用率がＸ［％］であり、コントローラＣｉのメモリ使用量がＹ［％］であると仮定する。
【０１３９】
また、或るコントローラＣｉのスイッチ管理台数が、ｎ台（ｎは１以上の整数）であり、ＯＦＣ３全体として管理する総スイッチ台数が、ｍ台（ｍは２以上の整数）であると仮定し、管理割合Ｒ＝ｎ／ｍとする。なお、管理割合Ｒは、総スイッチ数ｍのうち個々のコントローラＣｉが管理するスイッチ管理台数ｎの割合を表す。
【０１４０】
この場合、負荷情報Ｌは、以下の数式（１）によって計算されてよい。
Ｌ＝（Ｗａ×Ｘ＋Ｗｂ×Ｙ）／１００＋Ｗｃ×Ｒ  …（１）
なお、「Ｗａ」，「Ｗｂ」，「Ｗｃ」は、それぞれ、「Ｘ」，「Ｙ」，「Ｒ」についての重み係数を表し、Ｗａ＋Ｗｂ＋Ｗｃ＝１を満たす定数である。
【０１４１】
非限定的な一例として、図７（Ａ）に示すように、［Ｗａ，Ｗｂ，Ｗｃ］＝［０．２，０．２，０．６］であり、総スイッチ台数ｍ＝１００台であると仮定する。この場合に、図７（Ｂ）に「負荷パターンＡ」に例示するように、Ｘ＝２０［％］、Ｙ＝２０［％］、ｎ＝２０［台］であると、Ｌ＝（０．２×２０＋０．２×２０）／１００＋０．６×７０／１００＝０．５となる。
【０１４２】
同様に、図７（Ｂ）の「負荷パターンＢ」に例示するように、Ｘ＝２０［％］、Ｙ＝７０［％］、ｎ＝２０［台］であると、Ｌ＝（０．２×２０＋０．２×７０）／１００＋０．６×２０／１００＝０．３となる。
【０１４３】
また、図７（Ｂ）の「負荷パターンＣ」に例示するように、Ｘ＝７０［％］、Ｙ＝２０［％］、ｎ＝２０［台］であると、Ｌ＝（０．２×７０＋０．２×２０）／１００＋０．６×２０／１００＝０．３となる。
【０１４４】
なお、図７（Ｂ）の「負荷パターンＤ」に例示するように、負荷情報「Ｌ」は、仮に、Ｘ＝１００［％］、Ｙ＝１００［％］、ｎ＝１００［台］のときに、Ｌ＝１になる数値である。
【０１４５】
負荷情報Ｌの計算に用いる、ＣＰＵ使用率（Ｘ）、メモリ使用量（Ｙ）、及び、管理割合（Ｒ）の重み係数は、例示的に、コントローラＣｉのＣＰＵ性能や搭載メモリサイズに応じて決定されてよい。
【０１４６】
また、負荷情報Ｌは、ＣＰＵ使用率（Ｘ）、メモリ使用量（Ｙ）、及び、管理割合（Ｒ）の３つのパラメータのいずれか２つの重み付けによって計算されてもよいし、いずれか１つのパラメータ単独で計算されてもよい。
【０１４７】
図６に戻り、ロードバランサ３１２は、例えば高負荷スイッチ判定部３１２２によって、コントローラＣｉ毎の負荷情報Ｌ（Ｃｉ）に、上限閾値よりも大きい負荷情報と、下限閾値よりも小さい負荷情報と、の双方が存在するか否かを判定する（処理Ｐ１２）。別言すると、ロードバランサ３１２は、各コントローラＣｉの中に最大負荷と最小負荷との差分が閾値（上限閾値と下限閾値との差分）を超えるコントローラが存在するか否かを判定する。
【０１４８】
仮に、現在のコントローラＣ１，Ｃ２，Ｃ３毎の負荷情報Ｌ（Ｃｉ）が、［Ｌ（Ｃ１），Ｌ（Ｃ２），Ｌ（Ｃ３）］＝［０．８，０．３，０．２］であり、上限閾値ＴＨ１＝０．７であり、下限閾値ＴＨ２＝０．３であるとする。
【０１４９】
本例では、上限閾値ＴＨ１＝０．７を超える負荷情報Ｌ（Ｃ１）＝０．８のコントローラＣ１が存在し、且つ、下限閾値ＴＨ２＝０．３を下回る負荷情報Ｌ（Ｃ３）＝０．２のコントローラＣ３が存在する。
【０１５０】
したがって、ロードバランサ３１２は、コントローラＣ１〜Ｃ３間に負荷情報の偏りが有ると判定する（処理Ｐ１２のＹＥＳルートから処理Ｐ１３）。当該偏り判定は、例示的に、高負荷スイッチ判定部３１２２によって実施されてよい。
【０１５１】
なお、処理Ｐ１２において、上限閾値ＴＨ１よりも大きい負荷情報と、下限閾値ＴＨ２よりも小さい負荷情報と、の双方が存在しなければ、ロードバランサ３１２は、負荷情報の偏りは無いと判定して処理を終えてよい（処理Ｐ１２のＮＯルートから処理Ｐ１４）。
【０１５２】
ロードバランサ３１２は、「負荷情報に偏り有り」との判定に応じて、図８に例示するように、例えば管理台数不均衡チェック部３１２１によって、記憶部３４から、コントローラＣｉ毎のコントローラ対スイッチ対応情報を読み出してよい（処理Ｐ１５）。
【０１５３】
管理台数不均衡チェック部３１２１は、読み出したコントローラＣｉ毎のコントローラ対スイッチ対応情報を基に、コントローラＣｉが管理するスイッチ台数（便宜的に「管理スイッチ台数」と称してよい。）に不均衡が有るか否かをチェックする（処理Ｐ１６）。
【０１５４】
例えば、管理台数不均衡チェック部３１２１は、管理割合Ｒ＝ｎ／ｍを算出し、コントローラＣｉの台数（別言すると、「ｉ」がとり得る数の最大値）をＱとおいて、管理割合の平均値Ｒａｖ＝１／Ｑを求める。
【０１５５】
そして、管理台数不均衡チェック部３１２１は、管理割合Ｒが、非限定的な一例として、（Ｒａｖ）×０．８＜Ｒ＜（Ｒａｖ）×１．２を満たす範囲にあれば、不均衡が無いと判定し、範囲外であれば、不均衡が有ると判定してよい。
【０１５６】
例えば、コントローラＣｉの台数ＱがＱ＝３であると仮定すると、管理割合の平均値Ｒａｖは、１／３であるから、「不均衡無し」と判定する管理割合Ｒの範囲は、０．２７＜Ｒ＜０．４となる。別言すると、管理台数不均衡チェック部３１２１は、各コントローラＣｉ間で管理するスイッチ台数の差分が所定範囲に収まっているか否かを判定する。
【０１５７】
ここで、総スイッチ台数ｍ＝１００であり、３台のコントローラＣ１，Ｃ２，Ｃ３が、それぞれ、２０台、３０台、５０台のスイッチ４を管理していると仮定すると、コントローラＣ１，Ｃ２，Ｃ３の管理割合Ｒ（Ｃ１），Ｒ（Ｃ２），Ｒ（Ｃ３）は、それぞれ、以下のとおりとなる。
【０１５８】
Ｒ（Ｃ１）＝２０／１００＝０．２
Ｒ（Ｃ２）＝３０／１００＝０．３
Ｒ（Ｃ３）＝５０／１００＝０．５
【０１５９】
したがって、管理台数不均衡チェック部３１２１は、図９に例示するように、コントローラＣ１，Ｃ２，Ｃ３のスイッチ管理台数が、それぞれ、「不均衡」、「均衡」、「不均衡」である、と判定してよい。
【０１６０】
コントローラＣｉの負荷情報に偏りが有ると判定されたにも関わらずコントローラＣｉ間にスイッチ管理台数の不均衡が無いと判定されると（処理Ｐ１６でＮＯの場合）、ロードバランサ３１２は、記憶部３５からスイッチ毎処理量情報を読み出す（処理Ｐ１７）。当該処理Ｐ１７は、既述の「詳細情報」の読み出しに相当すると捉えてよい。
【０１６１】
スイッチ毎処理量情報の読み出しは、例示的に、高負荷スイッチ判定部３１２２によって実施されてよい。読み出したスイッチ毎処理情報には、例示的に、処理量カウント部３１１３によってカウントされた、各スイッチ４のパケットイン及びフロー変更メッセージの処理数を示す情報が含まれる。
【０１６２】
高負荷スイッチ判定部３１２２は、図１０に例示するように、読み出したスイッチ毎処理量情報を基に、「不均衡有り」と判定されたコントローラＣｉが管理するスイッチ４の中に、特定の高負荷スイッチ４が存在するか否かを判定する（処理Ｐ１９）。
【０１６３】
高負荷スイッチ４であるか否かの判定は、例えば、スイッチ毎処理量情報において、パケットインやフロー変更メッセージの処理数が相対的に多いか否かを判定することで行なってよい。
【０１６４】
例えば、「不均衡有り」と判定されたコントローラＣｉに対応する処理モジュール３１−ｉが単位時間あたりにトータルで処理するパケットイン及びフロー変更メッセージの処理数を、それぞれ、「Pin(tot)」及び「Fmod(tot)」で表す。
【０１６５】
更に、「不均衡有り」と判定されたコントローラＣｉが管理を担当する個々のスイッチ４が単位時間あたりに処理するパケットイン及びフロー変更メッセージの処理数を、それぞれ、「Pin(SWk)」及び「Fmod(SWk)」で表す。なお、「ＳＷｋ」の「ｋ」は、スイッチ番号を表す。
【０１６６】
高負荷スイッチ判定部３１２２は、判定閾値を仮に「０．６」として、以下の式（２）を満たすスイッチ番号ｋのスイッチ４が、高負荷スイッチ４であると判定してよい（処理Ｐ２０）。
［Pin(SWk)＋Fmod(SWk)］／［Pin(tot)＋Fmod(tot)］＞０．６  …（２）
【０１６７】
別言すると、高負荷スイッチ判定部３１２２は、個々の処理モジュール３１−ｉ全体の６０［％］を超える処理量のパケットイン及びフロー変更メッセージを処理するスイッチ４を高負荷スイッチ４であると判定してよい。
【０１６８】
非限定的な一例として、図１１（Ａ）〜図１１（Ｃ）に、それぞれ、コントローラＣ１〜Ｃ３についてのスイッチ毎処理情報の一例を示す。図１１（Ａ）〜図１１（Ｃ）において、「Packet-in」がスイッチ４から処理モジュール３１−ｉに入力されるパケットインの処理数を表し、「FlowMod」が処理モジュール３１−ｉからスイッチ４へ出力されるフロー変更メッセージの処理数を表している。また、括弧内の数値は、それぞれの処理数についての過去の最大値を表す。
【０１６９】
本例では、コントローラＣ１〜Ｃ３のスイッチ管理台数は、ほぼ均等（３台か４台）であるため、管理台数不均衡チェック部３１２１において、スイッチ管理台数に不均衡は無い（図８の処理Ｐ１６でＮＯ）と判定される。
【０１７０】
当該判定に応じて、高負荷スイッチ判定部３１２２は、スイッチ毎処理情報を参照すると、コントローラＣ１についてのパケットイン処理量が「６７」と多く、そのうち「ＳＷ１２」についてのパケットイン処理量が９０％を占めていることを識別する。
【０１７１】
したがって、高負荷スイッチ判定部３１２２は、コントローラＣ１についての総パケットイン処理量の６０％を超える「ＳＷ１２」を「パケットイン多」の「高負荷スイッチ４」と判定する。
【０１７２】
高負荷スイッチ「ＳＷ１２」は、「パケットイン多」であるため、当該高負荷スイッチ「ＳＷ１２」の管理元を他のコントローラＣ２又はＣ３に変更してしまうと、変更先の他のコントローラＣ２又はＣ３の負荷が高くなり過ぎる可能性がある。そのため、高負荷スイッチ３１２２は、高負荷スイッチ「ＳＷ１２」を管理元の変更が許容されるスイッチ候補から除外してよい（図１０の処理Ｐ２１）。
【０１７３】
ロードバランサ３１２は、対応付け制御部３１３と連携して、「ＳＷ１２」を除いた、コントローラＣ１が管理する「ＳＷ１１」及び「ＳＷ１３」について、コントローラＣ１よりも負荷の低い他のコントローラＣ２又はＣ３に管理元を変更する（処理Ｐ２２）。
【０１７４】
ここで、管理元の変更先は、コントローラＣ２及びＣ３のうち、負荷情報が「０．２」と最も低いコントローラＣ３に決定してもよいが、ロードバランサ３１２は、スイッチ毎処理量情報における過去の最大値を参照して、変更先コントローラＣｘを決定してよい。
【０１７５】
例えば、ロードバランサ３１２の対応付け制御部３１３は、図１１（Ａ）に例示したコントローラＣ１のスイッチ毎処理量情報において括弧内の数値で表される過去の最大値を参照する。
【０１７６】
管理元変更候補の「ＳＷ１１」及び「ＳＷ１３」についてのパケットイン処理量（Pin）の過去の最大値は、それぞれ、「４０」及び「６０」であり、合計すると、トータルの最大値「１５０」の６０％を占める。したがって、対応付け制御部３１３は、「ＳＷ１２」及び「ＳＷ１３」は過去に「パケットイン多」であったスイッチ４である、と判定してよい。
【０１７７】
これに対して、「ＳＷ１１」及び「ＳＷ１３」についてのフロー変更メッセージ処理量（Fmod）の過去の最大値は、それぞれ、「１０」及び「５」であり、合計すると、トータルの最大値「３０」の５０％である。６０％未満であるので、対応付け制御部３１３は、「ＳＷ１２」及び「ＳＷ１３」は過去に「フロー変更少」であったスイッチ４である、と判定してよい。
【０１７８】
対応付け制御部３１３は、図１１（Ｂ）及び図１１（Ｃ）に例示したコントローラＣ１のスイッチ毎処理量情報を基に、コントローラＣ２及びＣ３がそれぞれ管理するスイッチ４についても、同様にして、過去の最大値を確認してよい。
【０１７９】
例えば、図１１（Ｂ）から、コントローラＣ２については、トータルのパケットイン処理量の過去の最大値が「０」であるのに対し、トータルのフロー変更メッセージ処理量の過去の最大値が「１１０」であることが確認される。
【０１８０】
また、図１１（Ｃ）から、コントローラＣ３については、トータルのパケットイン処理量の過去の最大値が「１１０」であるのに対し、トータルのフロー変更メッセージ処理量の過去の最大値が「２５」であることが確認される。
【０１８１】
ここで、「ＳＷ１１」及び「ＳＷ１３」の管理元を、現状で負荷が最も低いコントローラＣ３に変更すると、パケットイン処理量の過去の最大値の合計が「４０＋５０＋１１０」＝「２００」となる。
【０１８２】
仮に、コントローラＣｉ毎のトータルのメッセージ処理量の過去の最大値として許容される上限値が「２００」であると仮定すると、コントローラＣ３についてのパケットイン処理が破綻する可能性がある。したがって、対応付け制御部３１３は、コントローラＣ３を「ＳＷ１１」及び「ＳＷ１３」の新たな管理元コントローラ候補から除外してよい。
【０１８３】
一方、「ＳＷ１１」及び「ＳＷ１３」の管理元を、現状で２番目に負荷が低いコントローラＣ２に変更すると、図１２（Ｂ）に例示するように、パケットイン処理量の過去の最大値は「４０＋５０＋０」＝「９０」となる。また、図１２（Ｂ）に例示するように、フロー変更メッセージ処理量の過去の最大値は、「１０＋５＋１１０」＝「１２５」となる。
【０１８４】
対応付け制御部３１３は、過去の最大値「９０」及び「１２５」のいずれも上限値（仮に「２００」）に対して十分なマージンがあると判定して、「ＳＷ１１」及び「ＳＷ１３」の新たな管理元をコントローラＣ２に決定してよい。
【０１８５】
当該決定に応じて、対応付け制御部３１３は、高負荷スイッチと判定された「ＳＷ１２」を除く、「ＳＷ１１」及び「ＳＷ１３」をコントローラＣ２に対応付けるよう、記憶部３４のコントローラ対スイッチ対応情報を更新する（図１０の処理Ｐ２２）。
【０１８６】
これにより、コントローラＣ１が管理しているスイッチ４の中で、管理元の変更候補から除外された「ＳＷ１２」以外の「ＳＷ１１」及び「ＳＷ１３」が、同種のメッセージ数の過去の総量が相対的に少ないコントローラＣ２の管理対象に変更される。なお、管理元がコントローラＣ２に変更されるスイッチ４は、「ＳＷ１１」及び「ＳＷ１３」のいずれか一方のみでもよい。
【０１８７】
図１３（Ａ）及び図１３（Ｂ）に、コントローラ対スイッチ対応情報の更新例を示す。図１３（Ａ）は、更新前のコントローラ対スイッチ対応情報の一例を示し、図１に例示した管理状態での対応情報の一例である。
【０１８８】
図１３（Ｂ）は、更新後のコントローラ対スイッチ対応情報の一例を示している。図１３（Ｂ）の例では、高負荷スイッチ「ＳＷ１２」を除いた２台のスイッチ「ＳＷ１１」及び「ＳＷ１３」が、いずれも、コントローラＣ２に対応付けを変更されている。
【０１８９】
これにより、高負荷スイッチ「ＳＷ１２」の管理元はコントローラＣ１のままで変更されず、他のスイッチ「ＳＷ１１」及び「ＳＷ１３」は、管理元がコントローラＣ１からコントローラＣ２に変更される。
【０１９０】
図１２（Ａ）〜図１２（Ｃ）に、管理元変更後の、コントローラＣ１〜Ｃ３のスイッチ毎処理量情報の一例を示す。図１２（Ａ）に例示するように、コントローラＣ１の負荷情報は、「ＳＷ１１」及び「ＳＷ１３」が管理から外れたことによって、例えば「０．８」から「０．６」に低下する。
【０１９１】
また、図１２（Ｂ）に例示するように、コントローラＣ２の負荷情報は、「ＳＷ１１」及び「ＳＷ１３」が新たに管理に加わったことにより、例えば「０．３」から「０．４」に上昇する。コントローラＣ３については管理するスイッチ４に変更が無いため、図１２（Ｃ）に例示するように、コントローラＣ３の負荷情報「０．２」に変わりは無い。
【０１９２】
負荷情報は、コントローラＣ１〜Ｃ３間で完全には均等ではないものの、上限閾値ＴＨ１＝０．７を超えるコントローラＣｉが存在しなくなるので、図６の処理Ｐ１２において、再度、「偏り有り」（ＹＥＳ）と判定されないレベルになる。
【０１９３】
なお、図８の処理Ｐ１６においてスイッチ管理台数に不均衡が有ると判定された場合（ＹＥＳの場合）、ロードバランサ３１２は、相対的に負荷の高いコントローラＣｉの要因が上述したような特定のスイッチ４によるものではないと判定してよい（処理Ｐ１８）。
【０１９４】
この場合、ロードバランサ３１２は、例えば図１０に示すように、対応付け制御部３１３と連携して、通常の負荷分散ロジックに従い、コントローラ対スイッチ対応情報を更新して、コントローラＣｉとスイッチ４との対応付けを制御してよい（処理Ｐ２３）。
【０１９５】
「通常の負荷分散ロジック」とは、例示的に、スイッチ毎処理量情報を参照せずに、コントローラＣｉ間の負荷情報が均衡するように、コントローラＣｉとスイッチ４との対応付けを制御するロジックであってよい。
【０１９６】
「通常の負荷分散ロジック」では、スイッチ毎処理量情報を参照しない代わりに、ＣＰＵ使用率（Ｘ）、メモリ使用量（Ｙ）、管理割合（Ｒ）等のパラメータを基にして負荷情報が算出されてよい。
【０１９７】
（スイッチ毎の過去の処理量に関する情報を更新する動作例）
次に、図１４を参照して、スイッチ４毎の過去の処理量に関する情報を更新する動作例について説明する。当該更新の動作例は、既述のパケットイン処理量やフロー変更メッセージ処理量の「過去の最大値」を更新する動作の一例に相当すると捉えてよい。
【０１９８】
図１４に例示するフローチャートは、例えば図５に示したパケット処理部３１１の処理量カウント部３１１３によって実行されてよい。処理量カウント部３１１３は、パケットイン処理部３１１１でのパケットイン処理数と、フロー変更メッセージ処理部３１１２でのフロー変更メッセージ処理数と、をカウントする（処理Ｐ３１）。
【０１９９】
処理量カウント部３１１３は、パケットイン処理数及びフロー変更メッセージのそれぞれについて、単位時間毎にカウント値を合計する（処理Ｐ３２）。処理量カウント部３１１３は、カウント値の合計を例えば負荷情報記憶部３５に記憶する。その際、カウント値の合計によって、スイッチ毎処理量情報における現在のパケットイン処理数及びフロー変更メッセージ処理数が更新される（処理Ｐ３３）。
【０２００】
また、処理量カウント部３１１３は、負荷情報記憶部３５から、スイッチ毎処理量情報のうち、過去のパケットイン処理数及びフロー変更メッセージ処理数の各最大値を読み出す（処理Ｐ３４）。
【０２０１】
そして、処理量カウント部３１１３は、処理Ｐ３２でパケットイン処理数及びフロー変更メッセージ処理数のそれぞれについて得られた現在の合計カウント値と、読み出した過去の最大値と、を比較する（処理Ｐ３５）。
【０２０２】
比較の結果、現在の合計カウント値が過去の最大値よりも大きければ（処理Ｐ３５でＹＥＳの場合）、処理量カウント部３１１３は、負荷情報記憶部３５におけるスイッチ毎処理量情報のうち、対応する最大値を現在の合計カウント値で更新する（処理Ｐ３６）。
【０２０３】
一方、現在の合計カウント値が過去の最大値以下であれば（処理Ｐ３５でＮＯの場合）、処理量カウント部３１１３は、過去の最大値の更新は実施せずに、更新処理を終了してよい。
【０２０４】
以上のようにして、処理モジュール３１−ｉは、負荷情報記憶部３５における、メッセージ処理を、最新の情報に更新、維持できる。
【０２０５】
（過去の最大値に基づく変更先コントローラの選択制御例）
次に、図１５を参照して、過去の最大値に基づく変更先コントローラの選択制御例について説明する。図１５のフローチャートに例示する処理Ｐ４１〜Ｐ５２は、図１０に例示した処理Ｐ２１の、より詳細な処理例に相当すると捉えてよい。
【０２０６】
図１５に例示するように、ロードバランサ３１２は、図１０の処理Ｐ２０で判定された高負荷スイッチ４を除く、高負荷コントローラＣｉが管理するスイッチ４について、スイッチ毎処理量情報を参照する（処理Ｐ４１）。
【０２０７】
そして、ロードバランサ３１２は、参照したスイッチ毎処理量情報において、当該スイッチ４が、過去に「フロー変更多」のスイッチ４であったか否かを判定する（処理Ｐ４２）。なお、当該スイッチ４は、管理元のコントローラＣｉを変更する候補のスイッチ４に相当し、便宜的に「候補スイッチ４」と称してよい。
【０２０８】
判定の結果、候補スイッチ４が過去に「フロー変更多」であれば（処理Ｐ４２でＹＥＳの場合）、ロードバランサ３１２は、更に、候補スイッチ４が過去に「パケットイン多」のスイッチ４であったか否かを判定してよい（処理Ｐ４３）。
【０２０９】
候補スイッチが過去に「パケットイン多」であれば（処理Ｐ４３でＹＥＳの場合）、ロードバランサ３１２は、候補スイッチ４が、フロー変更メッセージ及びパケットイン共に処理量の多い傾向にあると判定してよい（処理Ｐ４４）。
【０２１０】
当該判定に応じて、ロードバランサ３１２は、候補スイッチ４の管理元を、低負荷の候補コントローラＣｉのいずれかに決定してよい（処理Ｐ４５）。
【０２１１】
一方、候補スイッチ４が過去に「パケットイン多」ではなければ（処理Ｐ４３でＮＯの場合）、ロードバランサ３１２は、候補スイッチ４がフロー変更メッセージ処理量の多い傾向にあると判定してよい（処理Ｐ４６）。
【０２１２】
当該判定に応じて、ロードバランサ３１２は、低負荷の候補コントローラＣｉのうち、過去のトータルのフロー変更メッセージ処理数が多いコントローラＣｉを、候補スイッチ４の新たな管理元コントローラ候補から除外してよい（処理Ｐ４７）。
【０２１３】
これにより、フロー変更メッセージ処理数の多い傾向にある候補スイッチ４の管理元が、過去のトータルのフロー変更メッセージ処理数が多いコントローラＣｉに変更されてしまうことを抑止できる。
【０２１４】
一方、処理Ｐ４２において、候補スイッチ４が過去に「フロー変更多」でなければ（ＮＯの場合）、ロードバランサ３１２は、更に、候補スイッチ４が過去に「パケットイン多」であったか否かを判定してよい（処理Ｐ４８）。
【０２１５】
判定の結果、候補スイッチ４が過去に「パケットイン多」であれば（処理Ｐ４８でＹＥＳの場合）、ロードバランサ３１２は、候補スイッチ４がパケットイン処理量の多い傾向にあるスイッチ４であると判定してよい（処理Ｐ４９）。
【０２１６】
当該判定に応じて、ロードバランサ３１２は、低負荷の候補コントローラＣｉのうち、過去のトータルのパケットイン処理数が多いコントローラＣｉを、候補スイッチ４の新たな管理元コントローラ候補から除外してよい（処理Ｐ５０）。
【０２１７】
これにより、パケットイン処理数の多い傾向にある候補スイッチ４の管理元が、過去のトータルのパケットイン処理数が多いコントローラＣｉに変更されてしまうことを抑止できる。
【０２１８】
一方、処理Ｐ４８において候補スイッチ４が過去に「パケットイン多」でなければ（ＮＯの場合）、ロードバランサ３１２は、候補スイッチ４が、フロー変更メッセージ及びパケットイン共に処理量の多い傾向には無いと判定してよい（処理Ｐ５１）。
【０２１９】
当該判定に応じて、ロードバランサ３１２は、候補スイッチ４の管理元を、低負荷の候補コントローラＣｉのいずれかに決定してよい（処理Ｐ５２）。
【０２２０】
以上のようにして、ロードバランサ３１２は、メッセージ処理数の過去の最大値に基づいて、変更先コントローラＣｘを適切に選択することができる。
【０２２１】
（候補スイッチの位置に応じた変更先コントローラの選択制御例）
次に、図１６を参照して、候補スイッチ４が、「エッジスイッチ」に相当するか、「コアスイッチ」に相当するかに応じて、変更先コントローラＣｉの選択が制御される例について説明する。なお、図１６に例示する処理Ｐ６１〜Ｐ６６は、図１０に例示した処理Ｐ２１の変形例に相当すると捉えてよい。
【０２２２】
図１６に例示するように、ロードバランサ３１２は、図１０の処理Ｐ２０で判定された高負荷スイッチ４を除く、高負荷コントローラＣｉが管理する候補スイッチ４について、記憶部３５に記憶されたスイッチ毎種別情報を参照する（処理Ｐ６１）。
【０２２３】
そして、ロードバランサ３１２は、参照したスイッチ毎種別情報が「コアスイッチ」を示すか「エッジスイッチ」を示すかを確認する（処理Ｐ６２）。確認の結果、「コアスイッチ」であれば（処理Ｐ６２でＹＥＳの場合）、ロードバランサ３１２は、候補スイッチ４が、フロー変更メッセージ処理数の多い傾向にあると判定してよい（処理Ｐ６３）。
【０２２４】
当該判定に応じて、ロードバランサ３１２は、低負荷の候補コントローラＣｉのうち、「コアスイッチ」の管理台数が相対的に多いコントローラＣｉを、「コアスイッチ」である候補スイッチ４の新たな管理元コントローラ候補から除外してよい（処理Ｐ６４）。
【０２２５】
これにより、フロー変更メッセージ処理数の多い傾向にある候補コアスイッチ４の管理元が、「コアスイッチ」の管理台数が相対的に多いコントローラＣｉに変更されてしまうことを抑止できる。
【０２２６】
一方、処理Ｐ６２において、参照したスイッチ毎種別情報が「エッジスイッチ」を示していれば（ＮＯの場合）、ロードバランサ３１２は、「エッジスイッチ」である候補スイッチ４が、パケットイン処理数の多い傾向にあると判定してよい（処理Ｐ６５）。
【０２２７】
当該判定に応じて、ロードバランサ３１２は、低負荷の候補コントローラＣｉのうち、「エッジスイッチ」の管理台数が相対的に多いコントローラＣｉを、「エッジスイッチ」たる候補スイッチ４の新たな管理元コントローラ候補から除外してよい（処理Ｐ６６）。
【０２２８】
これにより、パケットイン処理数の多い傾向にある候補エッジスイッチ４の管理元が、「エッジスイッチ」の管理台数が相対的に多いコントローラＣｉに変更されてしまうことを抑止できる。
【０２２９】
以上の処理Ｐ６１〜Ｐ６６によって、ロードバランサ３１２は、例えば、コントローラＣｉ間で、なるべく「エッジスイッチ」及び「コアスイッチ」の管理台数が均衡化されるように、コントローラＣｉとスイッチ４との対応付けを変更することが可能になる。
【０２３０】
例えば図１において、コントローラＣ１〜Ｃ３の管理する各スイッチ４の種別（エッジ又はコア）が、次表２に例示するとおりであると仮定する。
【表２】
2016219859.tif 000004
【０２３１】
表２の例では、コントローラＣ１及びＣ３が管理するエッジスイッチ４はそれぞれ３台であり、コントローラＣ２が管理するエッジスイッチ４は０台である。したがって、ロードバランサ３１２は、６台のエッジスイッチ４のいずれかを、管理元を変更するスイッチ候補に選んだ場合、新たな管理元に、なるべくコントローラＣ２が選ばれるように動作してよい。
【０２３２】
また、表２の例において、コントローラＣ１及びＣ３が管理するコアスイッチ４はいずれも０台であり、コントローラＣ２が管理するコアスイッチ４は４台である。したがって、ロードバランサ３１２は、４台のコアスイッチ４のいずれかを、管理元を変更するスイッチ候補に選んだ場合、新たな管理元に、なるべくコントローラＣ１又はＣ３が選ばれるように動作してよい。
【０２３３】
このようにして、コントローラＣｉ間で、管理するエッジスイッチ４及びコアスイッチ４の台数が均衡化されるように、ロードバランサ３１２は、コントローラＣｉとスイッチ４との対応付けを制御してよい。
【０２３４】
以上のように、上述した実施形態によれば、コントローラＣｉの単純な負荷監視に基づく負荷分散制御では負荷分散がうまく収束しない既述の「ケース１」や「ケース２」の発生を抑止あるいは抑制できる。
【０２３５】
例えば、負荷がコントローラＣｉ間を行ったり来たりして、コントローラＣｉ間の負荷の偏りがなかなか解消されなかったり、特定のコントローラＣｉの負荷がいつまでも低減されなかったりすることを抑止あるいは抑制できる。
【０２３６】
したがって、負荷分散が収束するまでの制御回数や時間を低減することができる。例えば、コントローラＣｉの単純な負荷監視に基づく負荷分散制御では、収束までに５〜１０回程度の制御を試行しなければならない可能性があるのに対し、上述した実施形態によれば、負荷分散制御の収束までの制御回数を１〜２回程度に抑えることが見込める。よって、ＯＦＣ３の安定的な運用が可能となり、ネットワーク２の安定的な運用を実現できる。
【０２３７】
なお、図５に例示したＯＦＣ３は、コントローラＣｉのそれぞれに対して（あるいは、コントローラＣｉ内）に個別に処理モジュール３１−ｉが備えられているが、処理モジュール３１−ｉは、各エレメントコントローラＣｉに共通でもよい。
【０２３８】
例えば、各エレメントコントローラＣｉに共通の処理モジュール（便宜的に「共通処理モジュール」と称してよい。）が、集中的に、上述したコントローラＣｉ間の負荷分散制御を実施してもよい。
【０２３９】
例示的に、「共通処理モジュール」は、コントローラＣｉのそれぞれから、パケットインやフロー変更メッセージ等のメッセージ処理量の通知を受けて、上述したコントローラＣｉ間の負荷分散制御を実施してもよい。当該「共通処理モジュール」は、「コントローラＣｉの制御装置」に相当すると捉えてよい。
【０２４０】
別言すると、スイッチ４の「属性情報」に基づいて、どのスイッチ４をどのコントローラＣｉの管理対象にするかの判断や決定は、選択された処理モジュール３１−ｉ（又は、コントローラＣｉ）で実施してもよいし、各コントローラＣｉに共通の制御装置で実施してもよい。
【０２４１】
（その他）
なお、負荷分散技術の１つに、「サーバ」の負荷分散技術がある。「サーバの負荷分散技術」では、例えば図１７に模式的に示すように、複数のサービスサーバ（例えば、ウェブサーバ）Ｓの負荷を、ロードバランサＬＢによって分散制御する。
【０２４２】
例えば、ロードバランサＬＢは、ユーザのリクエストを受信すると、各サーバＳの負荷に基づいて、どのサーバＳにリクエストを渡すかを決定し、決定したサーバＳに受信したリクエストを渡す。これにより、ユーザのリクエストに応じた処理負荷を、複数のサーバＳに分散することが可能となる。
【０２４３】
複数のサーバＳで負荷分散するロジックとしては、複数のサーバＳに対して順番に処理を渡す「ラウンドロビン方式」や、サーバＳ毎に、オープンなセッション数を管理しておき、最もセッション数の少ないサーバＳに処理を渡す方式等が考えられる。
【０２４４】
ＬＢは、大量のリクエストを送信するヘビーユーザが存在した場合、その大量のリクエストに応じたセッションを、均等に複数サーバＳに振り分ける。したがって、ＬＢは、どのユーザが送信したリクエストであるかを識別することなく、セッションを均等に複数サーバＳに振り分けることで、負荷分散を実現する。
【０２４５】
このようなサーバの負荷分散技術を単純にＯＦＣ３のようなネットワークコントローラに適用することを検討してみる。例えば、ユーザをスイッチ４に置き換え、複数のサーバＳを複数のエレメントコントローラに置き換えて、負荷分散が可能であるかを検討してみる。
【０２４６】
この場合、どのスイッチ４が送信したメッセージであるかを識別せずに、複数のエレメントコントローラのいずれかにメッセージを渡そうとすると、スイッチ４とエレメントコントローラとの間の関連付け（セッション）を頻繁に変更しなければならなくなる。
【０２４７】
しかし、関連付けを頻繁が変更されてしまうと、制御が複雑かつ不安定になってしまう。そのため、セッション毎に別のエレメントコントローラにメッセージを振り分けることは、ネットワークコントローラの安定稼動の観点から好ましくない。
【０２４８】
結果として、図１８に模式的に例示するように、ヘビーユーザに相当するような特定の高負荷スイッチ（ＳＷ）が存在した場合に、その処理を複数のエレメントコントローラ（Ｃ）で分担できない。
【０２４９】
そのため、特定のエレメントコントローラの負荷が高まってしまうことが避けられない。したがって、サーバの負荷分散技術を単純にネットワークコントローラに適用しても適切な負荷分散を実現できない。
【符号の説明】
【０２５０】
１  通信システム
２  ネットワーク
３  コントローラ（ＯＦＣ）
３１−ｉ  処理モジュール
３１１  パケット処理部
３１１１  パケットイン処理部
３１１２  フロー変更処理部
３１１３  処理量カウント部
３１２  負荷分散部（ロードバランサ）
３１２１  管理台数不均衡チェック部
３１２２  高負荷スイッチ判定部
３１３  コントローラ−スイッチ対応付け制御部
３２  メッセージ処理部
３３  コントローラアプリケーション
３４，３５  記憶部
４−１〜４−Ｎ  ネットワークエレメント（ネットワークスイッチ）
Ｃｉ  エレメントコントローラ
【図１】
2016219859.tif 000005
【図２】
2016219859.tif 000006
【図３】
2016219859.tif 000007
【図４】
2016219859.tif 000008
【図５】
2016219859.tif 000009
【図６】
2016219859.tif 000010
【図７】
2016219859.tif 000011
【図８】
2016219859.tif 000012
【図９】
2016219859.tif 000013
【図１０】
2016219859.tif 000014
【図１１】
2016219859.tif 000015
【図１２】
2016219859.tif 000016
【図１３】
2016219859.tif 000017
【図１４】
2016219859.tif 000018
【図１５】
2016219859.tif 000019
【図１６】
2016219859.tif 000020
【図１７】
2016219859.tif 000021
【図１８】
2016219859.tif 000022