(57)【要約】【構成】スイッチ１６ａ〜１６ｎの各々は、ＯＳＩ参照モデルのアプリケーション層に対応するＡＬＭ(Application Layer Multicast)方式がパケット配信方式として指定されたとき、自律的にパケット転送を行う。コントローラＰＣ１４は、ＯＳＩ参照モデルのデータリンク層およびネットワーク層に対応するＯＦＭ(Open Flow Multicast)方式がパケット配信方式として指定されたとき、スイッチ１６ａ〜１６ｎにパケット転送経路を設定する。サーバＰＣ１２ａ〜１２ｚはＡＬＭ方式に対応してオーバレイネットワークをなし、サーバＰＣ１２ａ〜１２ｚの各々はスイッチ１６ａ〜１６ｎを介してパケットを送受信する。また、サーバＰＣ１２ａ〜１２ｚは、スイッチ１６ａ〜１６ｎにおけるパケット転送状況を参照して、ＡＬＭ方式およびＯＦＭ方式の間でパケット配信方式を切り替える。【効果】耐障害性を維持しつつ効率的にパケットをやり取りすることができる。【選択図】図１
2015154210.tif 000002
【特許請求の範囲】
【請求項１】
ＯＳＩ参照モデルの上位層に対応する第１マルチキャスト方式がパケット配信方式として指定されたとき各々が自律的にパケット転送を行う複数のスイッチ、
前記ＯＳＩ参照モデルの下位層に対応する第２マルチキャスト方式が前記パケット配信方式として指定されたとき前記複数のスイッチにパケット転送経路を設定するコントローラ、および
前記第１マルチキャスト方式に対応してオーバレイネットワークをなし、各々が前記複数のスイッチを介してパケットを送受信する複数のサーバを備える通信ネットワークシステムであって、
前記複数のサーバは、前記複数のスイッチにおけるパケット転送状況を参照して前記第１マルチキャスト方式および前記第２マルチキャスト方式の間で前記パケット配信方式を切り替える、通信ネットワークシステム。
【請求項２】
前記第１マルチキャスト方式はピアツーピア技術を前提とし、
前記第２マルチキャスト方式はＯｐｅｎＦｌｏｗ技術を前提とする、請求項１記載の通信ネットワークシステム。
【請求項３】
前記複数のサーバ間で送受信されるパケットは出版／購読型モデルで送受信されるトピックに相当する、請求項１または２記載の通信ネットワークシステム。
【請求項４】
前記上位層はアプリケーション層に相当し、前記下位層はデータリンク層および／またはネットワーク層に相当する、請求項１ないし３のいずれかに記載の通信ネットワークシステム。
【請求項５】
前記パケット転送状況を定義するパラメータは、単位時間当たりの転送パケット数、転送パケットの総数、転送パケットの遅延時間、および転送パケットの宛先の総数の少なくとも一部を含む、請求項１ないし４のいずれかに記載の通信ネットワークシステム。
【請求項６】
前記複数のサーバは、複数のユーザをそれぞれ代理する複数の第１エージェント、および前記コントローラを代理する単一の第２エージェントを実装する、請求項１ないし５のいずれかに記載の通信ネットワークシステム。
【請求項７】
前記第２エージェントは前記複数の第１エージェントのいずれか１つと通信を行って前記パケット転送状況を検出し、
前記コントローラは前記第２エージェントと連携して前記パケット転送経路を前記複数のスイッチに設定する、請求項６記載の通信ネットワークシステム。
【請求項８】
ＯＳＩ参照モデルの上位層に対応する第１マルチキャスト方式がパケット配信方式として指定されたとき各々が自律的にパケット転送を行う複数のスイッチ、および前記ＯＳＩ参照モデルの下位層に対応する第２マルチキャスト方式が前記パケット配信方式として指定されたとき前記複数のスイッチにパケット転送経路を設定するコントローラとともに通信ネットワークシステムを形成し、かつ前記第１マルチキャスト方式に対応してオーバレイネットワークをなし、各々が前記複数のスイッチを介してパケットを送受信する複数のサーバに、
前記複数のスイッチにおけるパケット転送状況を参照して前記第１マルチキャスト方式および前記第２マルチキャスト方式の間で前記パケット配信方式を切り替えさせるようにした、パケット配信制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、通信ネットワークシステムに関し、特にマルチキャスト方式でパケットを配信する、通信ネットワークシステムに関する。この発明はまた、このような通信ネットワークシステムにおいてパケットの配信を制御する、パケット配信制御方法に関する。
【背景技術】
【０００２】
この種のシステムの一例が、特許文献１に開示されている。この背景技術によれば、マルチキャストデータパケットが受信されると、受信したマルチキャストデータパケットのヘッダに埋め込まれた宛先ＭＡＣアドレスに基づいて索引値が取得され、取得された索引値を使用して出力ポート系列が決定される。受信したマルチキャストデータパケットは、決定された出力ポート系列に示されるポートから出力される。このようなパケット転送処理は、或る具体例ではＯｐｅｎＦｌｏｗ技術を使用して実装され、他の具体例では既存のイーサネット（登録商標）環境に実装される。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１３−５５６４２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ＯｐｅｎＦｌｏｗ技術に従うマルチキャスト転送はＯＳＩ参照モデルのレイヤ２またはレイヤ３に対応するため、複数のスイッチの接続状態を俯瞰してパケット転送経路を設定することができる。ただし、複数のスイッチの接続状態を俯瞰したパケット転送経路の設定は、耐障害性（ロバスト性）に弱いという特性を伴う。
【０００５】
また、既存のイーサネット（登録商標）環境で採用されるピアツーピア技術に従うマルチキャスト転送では、複数のスイッチの各々が自律的にパケット転送を行うため、耐障害性の高いネットワークを実現することができる。ただし、ピアツーピア技術はＯＳＩ参照モデルのレイヤ７に対応するため、複数のスイッチの接続状態を把握することができず、スイッチ間での無駄なパケットのやり取りが発生するおそれがある。
【０００６】
それゆえに、この発明の主たる目的は、耐障害性を維持しつつ効率的にパケットをやり取りすることができる、通信ネットワークシステムおよびパケット配信制御方法を提供することである。
【課題を解決するための手段】
【０００７】
この発明に従う通信ネットワークシステム(10：実施例で相当する参照符号。以下同じ)は、ＯＳＩ参照モデルの上位層に対応する第１マルチキャスト方式がパケット配信方式として指定されたとき各々が自律的にパケット転送を行う複数のスイッチ(16a~16n)、ＯＳＩ参照モデルの下位層に対応する第２マルチキャスト方式がパケット配信方式として指定されたとき複数のスイッチにパケット転送経路を設定するコントローラ(14)、および第１マルチキャスト方式に対応してオーバレイネットワークをなし、各々が複数のスイッチを介してパケットを送受信する複数のサーバ(12a~12z)を備える通信ネットワークシステムであって、複数のサーバは、複数のスイッチにおけるパケット転送状況を参照して第１マルチキャスト方式および第２マルチキャスト方式の間でパケット配信方式を切り替える。
【０００８】
好ましくは、第１マルチキャスト方式はピアツーピア技術を前提とし、第２マルチキャスト方式はＯｐｅｎＦｌｏｗ技術を前提とする。
【０００９】
好ましくは、複数のサーバ間で送受信されるパケットは出版／購読型モデルで送受信されるトピックに相当する。
【００１０】
好ましくは、上位層はアプリケーション層に相当し、下位層はデータリンク層および／またはネットワーク層に相当する。
【００１１】
好ましくは、パケット転送状況を定義するパラメータは、単位時間当たりの転送パケット数、転送パケットの総数、転送パケットの遅延時間、および転送パケットの宛先の総数の少なくとも一部を含む。
【００１２】
好ましくは、複数のサーバは、複数のユーザをそれぞれ代理する複数の第１エージェント、およびコントローラを代理する単一の第２エージェントを実装する。
【００１３】
さらに好ましくは、第２エージェントは複数の第１エージェントのいずれか１つと通信を行ってパケット転送状況を検出し、コントローラは第２エージェントと連携してパケット転送経路を複数のスイッチに設定する。
【００１４】
この発明に従うパケット配信制御方法は、ＯＳＩ参照モデルの上位層に対応する第１マルチキャスト方式がパケット配信方式として指定されたとき各々が自律的にパケット転送を行う複数のスイッチ(16a~16n)、およびＯＳＩ参照モデルの下位層に対応する第２マルチキャスト方式がパケット配信方式として指定されたとき複数のスイッチにパケット転送経路を設定するコントローラ(14)とともに通信ネットワークシステム(10)を形成し、かつ第１マルチキャスト方式に対応してオーバレイネットワークをなし、各々が複数のスイッチを介してパケットを送受信する複数のサーバ(12a~12z)に、複数のスイッチにおけるパケット転送状況を参照して第１マルチキャスト方式および第２マルチキャスト方式の間でパケット配信方式を切り替えさせるようにした、パケット配信制御方法である。
【発明の効果】
【００１５】
第１マルチキャスト方式では、複数のスイッチの各々が自律的にパケット転送を行うため、耐障害性の高いネットワークを実現することができる。ただし、第１マルチキャスト方式はＯＳＩ参照モデルの上位層に対応するため、複数のスイッチの接続状態を把握することができず、スイッチ間での無駄なパケットのやり取りが発生するおそれがある。
【００１６】
これに対して、第２マルチキャスト方式はＯＳＩ参照モデルの下位層に対応するため、複数のスイッチの接続状態を俯瞰してパケット転送経路を設定することで、スイッチ間での無駄なメッセージのやり取りを抑制することができる。ただし、複数のスイッチの接続状態を俯瞰したパケット転送経路の設定は、耐障害性に弱いという特性を伴う。
【００１７】
そこで、この発明では、複数のスイッチを介したパケット転送状況を参照して第１マルチキャスト方式および第２マルチキャスト方式の間でパケット配信方式を切り替えるようにしている。これによって、耐障害性を維持しつつ効率的にパケットをやり取りすることができる。
【００１８】
この発明の上述の目的，その他の目的，特徴および利点は、図面を参照して行う以下の実施例の詳細な説明から一層明らかとなろう。
【図面の簡単な説明】
【００１９】
【図１】この発明の一実施例の構成を示すネットワーク図である。
【図２】データセンタに設置される複数のサーバＰＣ、複数のスイッチおよび単一のコントローラＰＣの接続状態および各サーバＰＣに実装された各種プログラムの一例を示す図解図である。
【図３】（Ａ）はＡＬＭ方式に従うパケット転送動作の一部を示す図解図であり、（Ｂ）はＯＦＭ方式に従うパケット転送動作の一部を示す図解図である。
【図４】ＯＦＭ方式に従うパケット転送動作の他の一部を示す図解図である。
【図５】ユーザエージェントおよびコントローラエージェントの動作の一部を示すフロー図である。
【図６】ユーザエージェントおよびコントローラエージェントの動作の他の一部を示すフロー図である。
【図７】ユーザエージェントおよびコントローラエージェントの動作のその他の一部を示すフロー図である。
【図８】ユーザエージェントおよびコントローラエージェントの動作のさらにその他の一部を示すフロー図である。
【図９】ユーザエージェントおよびコントローラエージェントの動作の他の一部を示すフロー図である。
【図１０】ユーザエージェントおよびコントローラエージェントの動作のその他の一部を示すフロー図である。
【図１１】ユーザエージェントおよびコントローラエージェントの動作のさらにその他の一部を示すフロー図である。
【発明を実施するための形態】
【００２０】
図１を参照して、この実施例の通信ネットワークシステム（以下では、適宜「本システム」と呼ぶ）１０は、データセンタに設けられ、複数のサーバＰＣ１２ａ〜１２ｚと、各々がパケット転送機能を有する複数のスイッチ１６ａ〜１６ｎと、ＯｐｅｎＦｌｏｗ技術を採用するコントローラＰＣ１４とによって形成される。また、サーバＰＣ１２ａ〜１２ｚは、複数のユーザによってそれぞれ操作される複数のクライアントＰＣ２０ａ〜２０ｍに、既存のＩＰネットワーク３０を介して接続される。なお、ＯｐｅｎＦｌｏｗ技術とは、スタンフォード大学が中心となっている「ＯｐｅｎＦｌｏｗスイッチングコンソーシアム」によって提唱されたネットワーク制御技術である。
【００２１】
ＩＰネットワーク３０は、ＩＰアドレスによって相互に通信可能である。クライアントＰＣ２０ａ〜２０ｍの各々は、Ｐ４Ｐ(Provider Portal for application)，ＣＤＮ(Content Delivery Network)，負荷分散技術等で利用されている方式により、サーバＰＣ１２ａ〜１２ｚのいずれか１つをアクセス先として決定する。
【００２２】
クライアントＰＣ２０ａ〜２０ｍ上では、Ｗｅｂブラウザやモバイル端末向けアプリケーションなどのクライアントプログラムが動作する。また、クライアントＰＣ２０ａ〜２０ｍは、ＨＴＴＰ，ＷｅｂＳｏｃｋｅｔ，ＸＭＰＰなど、ＩＰネットワーク３０で利用可能なプロトコルにより、サーバＰＣ１２ａ〜１２ｚ上のアプリケーションサーバプログラムと通信する。なお、ＨＴＴＰにより通信する場合は、ＡｊａｘやＣｏｍｅｔ等によるプッシュ型通信が可能である。
【００２３】
スイッチ１６ａ〜１６ｎは、ＡＬＭ(Application Layer Multicast)方式に対応して自律的にパケット転送を実行し、ＯＦＭ(Open Flow Multicast)方式に対応してコントローラＰＣ１４の集中制御の下でパケット転送を実行する。ここで、ＡＬＭ方式はＯＳＩ参照モデルのアプリケーション層に対応する一方、ＯＦＭ方式はＯＳＩ参照モデルのデータリンク層およびネットワーク層に対応する（パケット転送の詳細は後述）。なお、ＩＰネットワーク３０もまたＯＳＩ参照モデルのデータリンク層およびネットワーク層に対応し、対応する層という点ではＯＦＭ方式と共通する。
【００２４】
図２を参照して、サーバＰＣ１２ａ〜１２ｚの各々には、本システムでパケット転送を実行するためのプロセスが存在する。このプロセス上では、構造化オーバレイネットワーク機能およびエージェント機能を提供するピアツーピアミドルウェアのピアが動作する。このプロセス上ではまた、クライアントＰＣ２０ａ〜２０ｍに同時にサービスを提供するアプリケーションサーバプログラムが動作する。なお、１台のサーバＰＣ上で複数のピアを動作させるようにしてもよい。
【００２５】
サーバＰＣ１２ａ上のピアには、クライアントＰＣ２０ａのユーザを代理するユーザエージェントＵＡ１と、クライアントＰＣ２０ｂのユーザを代理するユーザエージェントＵＡ２とが配置される。サーバＰＣ１２ｂ上のピアには、クライアントＰＣ２０ｃのユーザを代理するユーザエージェントＵＡ３が配置される。サーバＰＣ１２ｃ上のピアには、クライアントＰＣ２０ｄのユーザを代理するユーザエージェントＵＡ４と、クライアントＰＣ２０ｅのユーザを代理するユーザエージェントＵＡ５とが配置される。
【００２６】
こうして配置された各ユーザエージェントは、複数の属性を保持することができる。ピア上には自己に配置されたユーザエージェントを管理するテーブルが設けられ、ユーザエージェント上には自己が保持する属性のテーブルが設けられる。
【００２７】
各ピアは、構造化オーバレイネットワークであるＭＫＳＧ(Multi-key Skip Graph)を利用する（ＭＫＳＧの詳細は、「小西、他５名、“単一ノードに複数キーを保持可能とするＳｋｉｐ Ｇｒａｐｈ拡張”、情報処理学会論文誌、ｖｏｌ．４９、Ｎｏ．９、３２２３−３２３３、２００８年９月」を参照）。各ユーザエージェントの属性は、ＭＫＳＧ上にキー値として登録される。登録されるキー値は線形順序集合とされる。
【００２８】
ＭＫＳＧには、隣接するキー値を持つピアへの経路表が保持される。また、ＭＫＳＧでは、隣接していないキー値を持つピアの一部をランダムに選択し、経路表に保持することでアクセスの効率を高めている。ＭＫＳＧでは、指定したキー値（属性）を持つユーザエージェントに対してメッセージを送ることができる。ピアは、キー値（属性）を含むメッセージを受け取ると、その属性を持つユーザエージェントにメッセージを配送する。
【００２９】
メッセージは、一方向メッセージ送信以外に要求・応答形式もサポートしている。同じプロセス上で呼び出すと、ローカルメソッド呼び出しに変換される。同じキー値を持つユーザエージェントが複数存在する場合は、同時に複数のユーザエージェントにメッセージが送信される。この送信方式がＡＬＭ方式と呼ばれる。
【００３０】
なお、ユーザエージェントはピア間を移動できるため、遠隔からメソッドを呼び出すだけでなく、遠隔のユーザエージェントをローカルに呼び寄せてからメソッドを呼び出すこともできる。
【００３１】
ＯＦＭ方式に関連して、コントローラＰＣ１４に設けられたコントロールプログラムは、アプリケーションから制御するためのＡＰＩを提供する。ここでは、双方向のＲＥＳＴ(REpresentational State Transfer)を想定する。なお、ＲＥＳＴは、ＨＴＴＰを用いたＲＰＣ(Remote Procedure Call)に近い簡易なサービスインタフェースを指す。
【００３２】
サーバＰＣ１２ｂ上のピアには、コントローラＰＣ１４を代理するコントローラエージェントＯＦＧａｔｅが固定的に配置される。コントローラエージェントＯＦＧａｔｅは、特殊な属性を保持しており、上述したＲＥＳＴインタフェースを操作できる。ユーザエージェントＵＡ３からコントローラエージェントＯＦＧａｔｅへの処理依頼はエージェントＡＰＩによって実現される。
【００３３】
ＯＦＭ方式に従うパケット転送動作をスイッチ１６ａ〜１６ｎに要求するとき、コントローラＰＣ１４は、パケット転送経路（フローエントリ）をスイッチ１６ａ〜１６ｎに設定する。なお、対象パケットにマッチするフローエントリが存在しない場合に、対象パケットをスイッチ１６ａ〜１６ｎから受け取り、対象パケットの転送を改めてスイッチ１６ａ〜１６ｎに指示するようにしてもよい。
【００３４】
ＯＦＭ方式において、サーバＰＣ１２ａ〜１２ｚの間では、ＯｐｅｎＦｌｏｗデータプレーンネットワークを用いてＩＰによる通信が可能である。また、コントローラＰＣ１４とスイッチ１６ａ〜１６ｎとの間では、ＯｐｅｎＦｌｏｗコントロールプレーンネットワークを用いて相互に通信可能である。また、サーバＰＣ１２ｂは、サーバ・コントローラネットワークを用いてコントローラＰＣ１４と通信可能である。このような送信方式がＯＦＭ方式と呼ばれる。
【００３５】
なお、ＯｐｅｎＦｌｏｗデータプレーンネットワーク，ＯｐｅｎＦｌｏｗコントロールプレーンネットワークおよびサーバ・コントローラネットワークは、ＶＬＡＮ等の仮想ネットワーク技術を用いて部分的に同居させてもよい。この場合、コントローラエージェントＯＦＧａｔｅの配置は、ネットワーク障害等に応じて動的に変化させることができる。
【００３６】
本システムでは、トピックベースのＰｕｂ／Ｓｕｂモデル（出版／購読型モデル）を想定する。各ユーザエージェントは、受信したいトピックを各々が示す１または２以上の属性を有する。図２によれば、ユーザエージェントＵＡ１はトピック属性として“ＴＰ１”を有し、ユーザエージェントＵＡ２はトピック属性として“ＴＰ２”および“ＴＰ３”を有し、ユーザエージェントＵＡ３はトピック属性として“ＴＰ１”および“ＴＰ２”を有する。また、ユーザエージェントＵＡ４はトピック属性として“ＴＰ１”を有し、ユーザエージェントＵＡ５はトピック属性として“ＴＰ１”および“ＴＰ４”を有する。
【００３７】
Ｐｕｂ／Ｓｕｂモデルでは、キー値としてトピック属性を指定してメッセージを送信すると、指定されたトピック属性を有するユーザエージェントにメッセージが配信される。たとえば、ユーザエージェントＵＡ１が“ＴＰ１”を指定したメッセージを送信すると、このメッセージはユーザエージェントＵＡ３，ＵＡ４およびＵＡ５に配信される。
【００３８】
なお、トピック属性を指定してメッセージを送信するユーザエージェントを“パブリッシャ”と呼び、メッセージ（トピック）を購読するユーザエージェントを“サブスクライバ”と呼ぶ。
【００３９】
上述のように、クライアントＰＣ２０ａ〜２０ｍの各々は、ＨＴＴＰ，ＷｅｂＳｏｃｋｅｔ，ＸＭＰＰ等のプロトコルでアプリケーションサーバプログラムにアクセスする。アプリケーションサーバプログラムは、１または２以上のクライアントＰＣをホストし、ユーザエージェントのＡＰＩを利用してユーザエージェントにアクセスする。
【００４０】
図３（Ａ）および図３（Ｂ）を参照して、ＡＬＭ方式に従うパケット転送動作とＯＦＭ方式に従うパケット転送動作の相違を説明する。
【００４１】
サーバＰＣ１２ａのユーザエージェントＵＡ１がＡＬＭ方式でユーザＰＣ１２ｂ〜１２ｃのユーザエージェントＵＡ３〜ＵＡ５にメッセージを送信する場合、スイッチ１６ａ〜１６ｎは、自律的にパケット転送経路を決定する。ＡＬＭ方式は、ＯＳＩ参照モデルのアプリケーション層に対応し、下位層の接続状態を考慮しないため、パケット転送経路によっては、図３（Ａ）に示すように下位層のスイッチ間を無駄に往復する場合がある。
【００４２】
つまり、サーバＰＣ１２ａのユーザエージェントＵＡ１がトピック属性“ＴＰ１”を有するメッセージを送信すると、このメッセージは、サーバＰＣ１２ｃのユーザエージェントＵＡ４〜ＵＡ５に配信され、その後にサーバＰＣ１２ｂのユーザエージェントＵＡ３に配信される可能性がある。このとき、スイッチ１６ａおよび１６ｂの間でのメッセージの無駄な往復が発生する。
【００４３】
これに対して、サーバＰＣ１２ａのユーザエージェントＵＡ１がＯＦＭ方式でユーザＰＣ１２ｂ〜１２ｃのユーザエージェントＵＡ３〜ＵＡ５にメッセージを送信する場合は、コントローラＰＣ１４が集中的にパケット転送経路をスイッチ１６ａ〜１６ｎに設定する。ＯＦＭ方式は、ＯＳＩ参照モデルのデータリンク層およびネットワーク層に対応し、下位層の接続状態を考慮してパケット転送経路を構築するため、図３（Ｂ）のように最適なパケット転送が実現される。
【００４４】
つまり、サーバＰＣ１２ａのユーザエージェントＵＡ１がトピック属性“ＴＰ１”を有するメッセージを送信すると、このメッセージは、サーバＰＣ１２ｂのユーザエージェントＵＡ３およびサーバＰＣ１２ｃのユーザエージェントＵＡ４〜ＵＡ５に並列的に配信される。
【００４５】
したがって、パケット転送の効率性の点では、ＯＦＭ方式がＡＬＭ方式に優れる。しかし、上述のように、スイッチ１６ａ〜１６ｎが自律的にパケット転送経路を設定するＡＬＭ方式と、コントローラＰＣ１４が集中的にパケット転送経路をスイッチ１６ａ〜１６ｎに設定するＯＦＭ方式とでは、耐障害性に差が現れる。つまり、耐障害性の点では、ＡＬＭ方式がＯＦＭ方式に優れることになる。
【００４６】
このようにＡＬＭ方式およびＯＦＭ方式の各々には一長一短があることから、本システムでは、ＯＦＭピアリストを前提として作成されたＯＦＳマップとパケット転送状況を示すモニタリング情報とを参照して、パケット配信方式がＡＬＭ方式とＯＦＭ方式との間で切り替えられる。ＯＦＭ方式に切り替えられたときは、ＯＦＭピアリストおよびＯＦＳマップを参照してＯＦＭネットワークが構築される。
【００４７】
ＯＦＭピアリストとは、ＯＦＭ方式で配信可能なトピックを購読しているユーザエージェントが配置されたピアのリストである。リストアップすべきユーザエージェントは、ＡＬＭ方式でサブスクライバに「ＩＰアドレス・ポート」を問い合わせることで把握できる。また、ＯＦＭピアリストは、モニタリング情報の収集と同様な方式で収集できる。収集されたＯＦＭピアリストは、コントローラエージェントＯＦＧａｔｅを経由してコントローラＰＣ１４に受け渡される。
【００４８】
ＯＦＳマップとは、スイッチ１６ａ〜１６ｎのうちＯＦＭピアリストに登録されたピア間の下位層に位置するスイッチの接続構成を示すマップである。パケットイン時の新規アドレスの登録ならびにＬＬＤＰを用いたネットワーク構成の収集手法等をコントローラＰＣ１４側で用いることで、物理的な構成が把握できる。ＯＦＳマップは、コントローラＰＣ１４がＯＦＭネットワークを構築するときに利用される。なお、スイッチ１６ａ〜１６ｎのスイッチング動作を示す動的な情報をＯＦＳマップに含めるようにしてもよい。
【００４９】
モニタリング情報は、単位時間あたりのメッセージ配信数，総メッセージ数，メッセージ転送遅延（平均値、分散値），サブスクライバ数などをパラメータとして有し、定期的に記録・更新される。メッセージ数や遅延は配信方式で区別できるため、各配信方式で配信されたメッセージ数はサブスクライバにおいて集計できる。また、サブスクライバ数やＯＦＭピアリストはオーバレイネットワーク内で集計し、ひいてはパブリッシャで集計できる。
【００５０】
なお、ＯＦＭピアリスト，ＯＦＳマップおよびモニタリング情報は、事前に定義された周期でパブリッシャまたはコントローラエージェントＯＦＧａｔｅによって収集される。
【００５１】
ピアは、ＡＬＭ方式でメッセージを受信した場合、ＭＫＳＧ（ピアの経路表）に従ってメッセージを転送する必要があるが、ＯＦＭ方式でメッセージを受信する場合は自身が宛先ピアとなり、転送が不要となる。このため、各ピアは、パケットがＡＬＭ方式およびＯＦＭ方式のいずれに従って配信されたかを識別する必要がある。また、ＯＦＭ方式では、パケット転送経路を構築する際（フローエントリを記述する際）に、マルチキャスト配信を行うパケットを識別するための情報がフロー情報（ＩＰアドレス、ポート番号、プロトコル番号等）に含まれている必要がある。
【００５２】
これを踏まえて、コントローラエージェントＯＦＧａｔｅは、ＯＦＭネットワークを構築するときに、コントローラＰＣ１４と協働してＯＦＭアドレスを生成する。生成されたＯＦＭアドレスは、ＩＰアドレスとポート番号の組で表現される（図４参照）。
【００５３】
各ピアは、ＯＦＭ方式で配信されたメッセージを受信するための「ＩＰアドレス，ポート番号」の組を“待ち受けアドレス”として保持する。待ち受けアドレスは、パケット配信方式の切り替えに関係なく固定的に保持される。また、待ち受けアドレスの値はＯＦＭアドレスの値とは相違し、ＯＦＭアドレスから待ち受けアドレスへの変換はＯｐｅｎＦｌｏｗのルールに従って実行される。
【００５４】
図４によれば、サーバＰＣ１２ａに実装されたピアの待ち受けアドレスは「１９２．１６８．１．２３：１０００１」であり、サーバＰＣ１２ｂに実装されたピアの待ち受けアドレスは「１９２．１６８．２．３１：１０００２」であり、サーバＰＣ１２ｃに実装されたピアの待ち受けアドレスは「１９２．１６８．３．４５：１００００」である。また、コントローラエージェントＯＦＧａｔｅによって生成されたＯＦＭアドレスは、「２２８．５．６．７：７８９」である。
【００５５】
ユーザエージェントＵＡ１がＯＦＭ方式でユーザエージェントＵＡ３〜ＵＡ４に送信するメッセージには、ＯＦＭアドレスとして「２２８．５．６．７：７８９」が記述される。このＯＦＭアドレスがＯｐｅｎＦｌｏｗのルールに従って「１９２．１６８．２．３１：１０００２」および「１９２．１６８．３．４５：１００００」に変換され、これによってメッセージがサーバＰＣ１２ｂおよび１２ｃのピアに配信される。
【００５６】
なお、各ピアは、ＡＬＭアドレスおよびＯＦＭアドレスを同時に待ち受けし、ＡＬＭ方式で配信されたメッセージおよびＯＦＭ方式で配信されたメッセージを同時に受信することができる。これは、ＯＦＭネットワークの構築時から独立してパブリッシャ側の任意のタイミングでパケット配信方式を切り替えることができることを意味する。また、配信されたメッセージにはトピック属性が記述されているため、ピアは、このトピック属性に基づいて配信先のサブスクライバを特定する。
【００５７】
上述のように、ＯＦＭアドレスは、コントローラエージェントＯＦＧａｔｅとコントローラＰＣ１４との協働で生成される。詳しくは、コントローラエージェントＯＦＧａｔｅは、上述したＲＥＳＴ ＡＰＩ（ＮｏｒｔｈｂｏｕｎｄＡＰＩをＲＥＳＴで実装したもの）を用いてコントローラＰＣ１４に対してＯＦＭアドレスの生成を依頼する。このとき、ＯＦＭピアリストがコントローラエージェントＯＦＧａｔｅからコントローラＰＣ１４に受け渡される。
【００５８】
コントローラＰＣ１４は、ＯＦＭアドレスを生成するときにＯＦＭネットワークを構築する。ＯＦＭネットワークは、ＯＦＭアドレスが記述されたパケットが到着した場合にＯＦＭピアリスト上のピアに配信する転送ルールに従って構成される。コントローラＰＣ１４は、ＯＦＭネットワークに適合するようにスイッチ１６ａ〜１６ｎにパケット転送経路を設定する。
【００５９】
ＯＦＭ方式で配信可能なパブリッシャが対象トピックをサブスクライバに配信するとき、パブリッシャとコントローラエージェントＯＦＧｔａｔｅとの連携によって図５〜図７に示す処理が実行される。
【００６０】
まず図５に示すステップＳ１で、切り替え周期が到来したか否かがパブリッシャによって判別される。判別結果がＮＯであればトピックを配信する処理（図８参照）に移行し、判別結果がＹＥＳであればステップＳ３に進む。ステップＳ３では、各種情報（ＯＦＭピアリスト，ＯＦＳマップ，モニタリング情報）の収集方式がパブリッシャ収集方式およびＯＦＧａｔｅ収集方式のいずれであるかが、パブリッシャによって判別される。収集方式がパブリッシャ収集方式であればステップＳ５に進み、収集方式がＯＦＧａｔｅ収集方式であればステップＳ１１に進む。
【００６１】
ステップＳ５に進んだ場合、パブリッシャは他のユーザエージェントに問い合わせを発行して各種情報を収集する。ステップＳ７では、対象トピックについてＯＦＭネットワークを構築するための条件Ａが満足されたか否かを、収集した各種情報（特に、ＯＦＳマップおよびモニタリング情報）に基づいて判別する。判別結果がＮＯであれば図６のステップＳ２１に進み、判別結果がＹＥＳであればステップＳ１５に進む。ステップＳ１５に進む場合、収集された各種情報は、パブリッシャからコントローラエージェントＯＦＧａｔｅに受け渡される。
【００６２】
ステップＳ１１に進んだ場合は、コントローラエージェントＯＦＧａｔｅが各ユーザエージェントに問い合わせを発行して各種情報を収集する。ステップＳ１３では、対象トピックについてＯＦＭネットワークを構築するための条件Ａが満足されたか否かを、収集した各種情報に基づいて判別する。判別結果がＮＯであれば図６のステップＳ２５に進み、判別結果がＹＥＳであればステップＳ１５に進む。
【００６３】
ステップＳ１５では、ＯＦＭネットワークが構築済みであるか否かがコントローラエージェントＯＦＧａｔｅによって判別される。判別結果がＹＥＳであればそのままステップＳ１９に進み、判別結果がＮＯであればステップＳ１７の処理を経てステップＳ１９に進む。ステップＳ１７においてコントローラエージェントＯＦＧａｔｅは、コントローラＰＣ１４と協働してＯＦＭネットワークを構築する。構築にあたっては、各種情報を形成するＯＦＭピアリストおよびＯＦＳマップが参照される。
【００６４】
ＯＦＭネットワークの構築に伴って生成されたＯＦＭアドレスは、ステップＳ１９でコントローラエージェントＯＦＧａｔｅからユーザエージェントに引き渡される。引き渡しが完了すると、コントローラエージェントＯＦＧａｔｅは図６のステップＳ２５に進む。
【００６５】
ユーザエージェントは、ステップＳ１９での引き渡しに応答してステップＳ９の処理を実行する。ステップＳ９では、対象トピックに関連付けてＯＦＭアドレスキャッシュを記録する。記録が完了すると、図６のステップＳ２１に進む。
【００６６】
図６のステップＳ２１では、パブリッシャは、対象トピックを購読するメンバー（ＯＦＭ方式でトピックを購読するサブスクライバ）が更新されたか否かを判別する。判別結果がＮＯであれば図７のステップＳ３５に進み、判別結果がＹＥＳであればステップＳ２７に進む。各種情報は、ステップＳ２７への移行に伴ってパブリッシャからコントローラエージェントＯＦＧａｔｅに引き渡される。ステップＳ２５では、対象トピックを購読するメンバーが更新されたか否かがコントローラエージェントＯＦＧａｔｅによって判別される。判別結果がＮＯであれば図７のステップＳ３９に進み、判別結果がＹＥＳであればステップＳ２７に進む。
【００６７】
ステップＳ２７では、対象トピックを購読するメンバーがいなくなったか否かが、コントローラエージェントＯＦＧａｔｅによって判別される。判別結果がＹＥＳであれば、ステップＳ２９でＯＦＭネットワークを削除する。判別結果がＮＯであれば、ステップＳ３１に進み、ＯＦＭピアリストおよびＯＦＳマップに合わせてＯＦＭネットワークを再構築する。ステップＳ３３では、ＯＦＭネットワークの削除によるＯＦＭアドレスの消失、或いは再構築されたＯＦＭネットワークに対応するＯＦＭアドレスをパブリッシャに通知する。通知が完了すると、図７のステップＳ３９に進む。
【００６８】
ステップＳ３３による通知に応答して、パブリッシャは、ステップＳ２３でＯＦＭアドレスキャッシュを削除または更新する。削除または更新が完了すると、パブリッシャは図７のステップＳ３５に進む。
【００６９】
ステップＳ３５では、対象トピックについてＯＦＭネットワークを削除するための条件Ｂが満足されたか否かを、上述の要領で収集した各種情報に基づいて判別する。判別結果がＮＯであればトピックを配信する処理（図８参照）に移行し、判別結果がＹＥＳであステップＳ４１に進む。各種情報は、ステップＳ４１への移行に伴ってパブリッシャからコントローラエージェントＯＦＧａｔｅに引き渡される。
【００７０】
ステップＳ３９では、対象トピックについてＯＦＭネットワークを削除するための条件Ｂが満足されたか否かが、コントローラエージェントＯＦＧａｔｅによって判別される。この判別も、上述の要領で収集した各種情報に基づいて実行される。判別結果がＹＥＳであればステップＳ４１に進み、ＯＦＭネットワークが存在するか否かを判別する。判別結果がＮＯであればそのままステップＳ４５に進む一方、判別結果がＹＥＳであればステップＳ４３でＯＦＭネットワークを削除してからステップＳ４５に進む。
【００７１】
ステップＳ４５ではＯＦＭアドレスの削除をパブリッシャに通知する。パブリッシャは、コントローラエージェントＯＦＧａｔｅからの通知に応答して、ステップＳ３７で対象トピックについてのＯＦＭアドレスキャッシュを削除する。削除が完了すると、トピックを配信する処理（図８参照）に移行する。
【００７２】
図８を参照して、パブリッシャは、ＯＦＭアドレスキャッシュが存在するか否かをステップＳ４７で判別する。判別結果がＹＥＳであれば、ＯＦＭ方式がパケット配信方式として指定されているとみなし、ステップＳ４９に進む。これに対して、判別結果がＮＯであれば、ＡＬＭ方式がパケット配信方式として指定されているとみなし、ステップＳ５１に進む。ステップＳ４９では対象トピックをＯＦＭ方式で配信し、ステップＳ５１では対象トピックをＡＬＭ方式で配信する。
【００７３】
なお、図５〜図８の処理では、各種情報の収集方式がパブリッシャ収集方式である場合、パブリッシャは、各種情報を収集する処理と対象トピックを配信する処理とを別々に実行する。しかし、これでは、収集のためのメッセージ送信と対象トピックの送信の二度手間になる。対象トピックに各種情報要求を記述し、対象トピックの配信に対する応答としてサブスクライバから各種情報を収集するようにしてもよい。ＡＬＭ方式とＯＦＭ方式との間での配信方式の切り替えは、こうして収集された各種情報を参照して実行される。これによって、各種情報の収集のための特別のメッセージ送信が不要となり、パブリッシャの負担が軽減される。
【００７４】
コントローラエージェントＯＦＧａｔｅはまた、パブリッシャによる対象トピックの配信動作とは独立して、ＯＦＭユーザエージェントとの連携によって図９〜図１１に示す処理を実行する。まず、既定のモニタリング周期が到来したか否かを図９に示すステップＳ６１で判別し、各種情報の収集方式がＯＦＧａｔｅ収集方式であるか否かをステップＳ６３で判別する。ステップＳ６１またはＳ６３の判別結果がＮＯであれば他のいずれかの状態に遷移し、ステップＳ６１およびＳ６３の判別結果がいずれもＹＥＳであればステップＳ６５に進む。
【００７５】
ステップＳ６５では、各ユーザエージェントに問い合わせを発行して各種情報を収集する。ステップＳ６７では、対象トピックについてＯＦＭネットワークを構築するための条件Ａが満足されたか否かを、収集した各種情報に基づいて判別する。判別結果がＮＯであれば図１０のステップＳ７７に進み、判別結果がＹＥＳであればステップＳ６９に進む。
【００７６】
ステップＳ６９では、ＯＦＭネットワークが構築済みであるか否かを判別する。判別結果がＹＥＳであればそのままステップＳ７３に進み、判別結果がＮＯであればステップＳ７１の処理を経てステップＳ７３に進む。ステップＳ７１では、コントローラＰＣ１４と協働してＯＦＭネットワークを構築する。構築にあたっては、各種情報を形成するＯＦＭピアリストおよびＯＦＳマップが参照される。
【００７７】
ＯＦＭネットワークの構築に伴って生成されたＯＦＭアドレスは、ステップＳ７３でコントローラエージェントＯＦＧａｔｅからユーザエージェントに引き渡される。引き渡しが完了すると、コントローラエージェントＯＦＧａｔｅは図１０のステップＳ７７に進む。ユーザエージェントは、ステップＳ７３での引き渡しに応答してステップＳ７５の処理を実行する。ステップＳ７５では、対象トピックに関連付けてＯＦＭアドレスキャッシュを記録する。記録が完了すると、図１０のステップＳ８７に進む。
【００７８】
図１０のステップＳ７７では、対象トピックを購読するメンバーが更新されたか否かを判別する。判別結果がＮＯであれば図１１のステップＳ８９に進み、判別結果がＹＥＳであればステップＳ７９に進む。ステップＳ７９では、対象トピックを購読するメンバーがいなくなったか否かを判別する。
【００７９】
判別結果がＹＥＳであれば、ステップＳ８１でＯＦＭネットワークを削除する。判別結果がＮＯであれば、ステップＳ８３に進み、ＯＦＭピアリストおよびＯＦＳマップに合わせてＯＦＭネットワークを再構築する。ステップＳ８５では、ＯＦＭネットワークの削除によるＯＦＭアドレスの消失、或いは再構築されたＯＦＭネットワークに対応するＯＦＭアドレスをユーザエージェントに通知する。通知が完了すると、図１１のステップＳ８９に進む。
【００８０】
ステップＳ８５による通知に応答して、ユーザエージェントは、ステップＳ８７でＯＦＭアドレスキャッシュを削除または更新する。削除または更新が完了すると、ユーザエージェントは図１１のステップＳ９７に進む。
【００８１】
図１１のステップＳ８９では、対象トピックについてＯＦＭネットワークを削除するための条件Ｂが満足されたか否かを判別する。この判別も、上述の要領で収集した各種情報に基づいて実行される。判別結果がＮＯであれば他のいずれかの状態に遷移し、判別結果がＹＥＳであればステップＳ９１でＯＦＭネットワークが存在するか否かを判別する。ＯＦＭネットワークが存在しなければそのままステップＳ９５に進む一方、ＯＦＭネットワークが存在すればステップＳ９３でＯＦＭネットワークを削除してからステップＳ９５に進む。
【００８２】
ステップＳ９５では、ＯＦＭアドレスの削除をユーザエージェントに通知する。ユーザエージェントは、コントローラエージェントＯＦＧａｔｅからの通知に応答して、ステップＳ９７で対象トピックについてのＯＦＭアドレスキャッシュを削除する。
【００８３】
以上の説明から分かるように、スイッチ１６ａ〜１６ｎの各々は、ＯＳＩ参照モデルのアプリケーション層に対応するＡＬＭ方式がパケット配信方式として指定されたとき、自律的にパケット転送を行う。コントローラＰＣ１４は、ＯＳＩ参照モデルのデータリンク層およびネットワーク層に対応するＯＦＭ方式がパケット配信方式として指定されたとき、スイッチ１６ａ〜１６ｎにパケット転送経路を設定する。サーバＰＣ１２ａ〜１２ｚはＡＬＭ方式に対応してオーバレイネットワークをなし、サーバＰＣ１２ａ〜１２ｚの各々はスイッチ１６ａ〜１６ｎを介してパケットを送受信する。また、サーバＰＣ１２ａ〜１２ｚは、スイッチ１６ａ〜１６ｎにおけるパケット転送状況を参照して、ＡＬＭ方式およびＯＦＭ方式の間でパケット配信方式を切り替える。
【００８４】
ＡＬＭ方式では、スイッチ１６ａ〜１６ｎの各々が自律的にパケット転送を行うため、耐障害性の高いネットワークを実現することができる。ただし、ＡＬＭ方式はＯＳＩ参照モデルの上位層に対応するため、スイッチ１６ａ〜１６ｎの接続状態を把握することができず、スイッチ１６ａ〜１６ｎ間での無駄なパケットのやり取りが発生するおそれがある。
【００８５】
これに対して、ＯＦＭ方式はＯＳＩ参照モデルの下位層に対応するため、スイッチ１６ａ〜１６ｎの接続状態を俯瞰してパケット転送経路を設定することで、スイッチ１６ａ〜１６ｎ間での無駄なメッセージのやり取りを抑制することができる。ただし、スイッチ１６ａ〜１６ｎの接続状態を俯瞰したパケット転送経路の設定は、耐障害性に弱いという特性を伴う。
【００８６】
そこで、この実施例では、スイッチ１６ａ〜１６ｎを介したパケット転送状況を参照してＡＬＭ方式およびＯＦＭ方式の間でパケット配信方式を切り替えるようにしている。これによって、耐障害性を維持しつつ効率的にパケットをやり取りすることができる。
【符号の説明】
【００８７】
１０  …通信ネットワークシステム
１２ａ〜１２ｚ  …サーバＰＣ
１４  …コントローラＰＣ
１６ａ〜１６ｎ  …スイッチ
３０  …ＩＰネットワーク
２０ａ〜２０ｍ  …クライアントＰＣ
【図１】
2015154210.tif 000003
【図２】
2015154210.tif 000004
【図３】
2015154210.tif 000005
【図４】
2015154210.tif 000006
【図５】
2015154210.tif 000007
【図６】
2015154210.tif 000008
【図７】
2015154210.tif 000009
【図８】
2015154210.tif 000010
【図９】
2015154210.tif 000011
【図１０】
2015154210.tif 000012
【図１１】
2015154210.tif 000013