はじめに
1
農災のような緊急時には，被災地域で通常の何倍にも及ぶ通信が集中することで輻轢が発生し，ネットワークの機能が著しく低下してしまうといった問題が生じる。緊急災害時には，ネットワークによる情報提供が最も重要であるにも関わらず、これが機能しなくなる事は致命的である。現状のネットワーク制御では、経路を二重化し、一方の経路で障害が発生したら、もう一方の経路に切り替えるといった単純な障害対策の経路制御や，トラフィックの急増が予想される場合に，回線やサーバを事前に増強するといった制御しか行われていない．これは予測が極めて困難な緊急災害時においては対応が難しい。さらに、膨大で多種多様なデータが飛び交うようになった現代のネットワークでは，人が状況を目で見て判断する静的な制御では限界となってきた.そこで，本研究では細かい条件に応じた複雑で動的な制御を迅速に行うため，SDN(Software-Defined Net- working)やOpenFlowプロトコルを用いて，ソフトウェアによる自動ネットワーク制御を行う。また，アプリケーションごとに緊急度の優先順位をつけるなどといった，より細かい制御を行うため，DPN(Deeply Programmable Network)の概念をも適用し，研究の新規性を保証する。本研究は外部情報より障害を検知したと仮定し，それをトリガとして，トラフィックの最適化をアプリケーション別に自動で行う。高度なネットワークトラフィック制御手法の提案を行う.これにより,緊急災害時等でもユーザが安定して情報ヘアクセスできるシステムの構築を目指す.
2　提案システムの概要
本研究の提案システムの概要を図１に示す。動作は以下の通りである.図1:本研究の提案システムの概要(1)トポロジ検出と監視スイッチのポートの接続状況を検出するアプリケーションを動かし、トポロジ情報の検出を行う.また，通常時において，トラフィックモニタによりネットワークに異常がないかの監視を行う. (2)リンクのコスト値更新Twitterで検知した障害情報に従い，スイッチ問を結ぶリンクのコスト値を更新する。 (3)最適経路探索更新されたコスト値を用いて，ダイクストラ法で最適経路を探索する。 (4)経路再設定決定された最適経路に経路を再設定する.また，これら一連の動作の自動化を行った．以上の提案システムをSDNやDPN環境で構築する。 2.1節で具体的な例を交えつつ，その工程を説明する．
2.1 研究方針
上で提案したシステムを以下の環境において検証する。 (1)PC上のMininet仮想環境(SDNの検証) ②ローカルのFLARE実機環境(DPNの検証)まず，(1)のSDN環境における提案システムを，スイッチが３つのメッシュトポロジの場合(図2)で説明する.各スイッチに一つずつホストが接続されているが，この図では省略している。また，ホスト１からホスト２へとパケットが送信されているとする。図2:  SDN環境における提案システムの例通常時のトポロジ検出によりコントローラはスイッチのトポロジ情報を保持している．この場合スイッチ3つが各スイッチ全てに繋がっており，それぞれのリンクのコスト値はデフォルトで１と設定される．ここで， s1-s2の経路で障害を検知したと仮定すると，s1-s2間のリンクのコスト値をトラフィック量に基づき10に更新する.そして，ダイクストラ法を実行すると，コスト最小の経路を探索するため，最適経路はコスト値2であるs1-s3-s2の経路と決定され，経路が再設定される。ここで、コスト値が小さいということは带域が大きいということを示す. ②のDPN環境では，①で可能な制御に加え，図3や図４のような制御も可能になる。FLAREスイッチを用いたDPN環境では，仮想スイッチの組み合わせでスライスと呼ばれる仮想ネットワークを作成することができる。よって，図３のように，複数の仮想ネットワークをスライスとして構築しておき，特定の条件が満たされた場合に，スライスの切換えを行う事によって最適な経路を選択することができる.図3:  DPN環境におけるスライスの切替さらに，図４のように，緊急災害時において，現場の状況を伝えたり情報交換を行ったりするためのアプリケーションについては優先的にパケットを通し，エンターテインメント目的のトラフィックには制約をかけるなどといった制御も実現可能になる.
3
Mininetを用いた制御プログラムの開発
今回，OpenFlowフレームワークの一つであるMininetエミュレータを使用し、PC上の仮想環境で、実機実験の前に検証実験を行った．この実験の環境を表１に示す.

3.1    Mininetにおける実験
上記の環境で，3OVSノードのメッシュトポロジを作成し，以下の５つの動作を確認した. (1)  REST-APIを使った手動経路切替えREST-APIを用いて，h1-s1-s2-h2の経路と，h1- s1-s3-s2-h2の２つの経路の切替スクリプトを作成し実行した. (2)トポロジ検出コントローラがトポロジを検出できるよう, REST-APIでトポロジ検出アプリケーションを作成した。 (3)トポロジ情報にコスト値を付加(2)で検出したトポロジ情報に，コスト値を付加するスクリプトを作成した。 (4)最適経路探索コスト値ををもとに，ダイクストラ法による最適経路探索を行うアプリケーションを作成した. (5) 障害イベントによる自動経路切替え以上により，例えばh1-s1-s2-h2の経路に何か障害イベントが発生したことを仮定してコスト値を変更すると，自動的にh1-s1-s3-s2-h2のs3を経由する経路に切替えることを確認した.動作イメージは図５の通りである.
4   FLARE実機実験
本研究では，図６のような物理構成で実機実験を行う．４台のFLAREスイッチ各々に，端末がぶら下がる形である。FLARE CentralはFLARE管理用のサーバである．このFLARE Centralサーバ上にコントローラを置いた、コントローラで4台のFLAREスイッチを制御し，様々なトラフィック制御モデルを検討する.現段階では，Mininetで開発したOpenFlowのスクリプトをそのまま乗せて，3.1節に示した実験と同等な実験をこのFLARE実機環境で行うことができた.
まとめと今後の課題
5
繁急災害時に外部情報より障害を検知したと仮定し、その情報をトリガとして，ネットワークトラフィックの最適化をアプリケーション毎に自動で行う，高度なネットワークトラフィック制御システムを提案した.現時点では，MininetエミュレータとローカルのFLARE実機上で，OpenFlowを用いた経路切替制御を自動で行うスクリプトを作成し、動作を確認した。今後は，FLARE実機上でDPNを生かした制御の検証を行った後，広域なネットワークテストベッドであるJGN-X  (Japan Gigabit Network第４世代）上で実際に運用されているシステムに近い状況で検証していく今後の課題としては，さらに複雑なトポロジになった際に，この提案システムが正確に挙動するのか検証すると共に，より良い最適経路探索モデルを模索し，評価を行いたい.本研究を進めるにあたって，東京大学の中尾彰宏先生，山本周氏，工学院大学の山口実靖先生より大変有用なアドバイスをいただきました．深く感謝いたします. [1]柳田晴香,中尾彰宏,山本周,山口実矯,小口正人：「DPN環境におけるコンテキストに基づいたネットワーク制御方式」, DEIM2015, E1-3, 2015年３月発表予定