平成 27年度

学士学位論文

OpenFlowを用いた災害時における仮設

ネットワーク環境の実現

Realization of temporary network environment in

disaster using OpenFlow

1160353 別役速斗

指導教員 横山和俊

2016年 2月 26日

高知工科大学 情報学群

要 旨

OpenFlowを用いた災害時における仮設ネットワーク環境の

実現

別役速斗

震災など，大規模災害発生時には被災状況を把握し救助活動を行う必要がある．しかし，

震災時には電気や情報通信インフラが途絶え，救助活動に情報システムを利用することが困

難である．救助活動に情報システムを利用するためには被災現場での仮設ネットワーク環境

の構築が必要である．災害現場で仮設ネットワーク環境を構築するためには，ネットワーク

機器に小型で可搬性に優れたものを利用する必要がある．また，傷害情報などの緊急度の高

い情報を優先的に転送するための機能が必要となる．

本論文ではこれらの要件を基に，ネットワーク機器として Raspberry Piを使用し，QoS

機能を実現するために OpenFlow を使用した仮設ネットワーク環境を検討し，実現性を検

証した．また，検討環境の有効性を評価するために評価実験を行った．その結果，被災状況

の送受信に関しては問題ない性能であることを確認した．これにより，Raspberry Pi及び

OpenFlowを使用した仮設ネットワーク環境は被災現場での情報交換において十分に実用性

があると考えられる．

キーワード OpenFlow, Raspberry Pi, SDN, QoS

– i –

Abstract

Realization of temporary network environment in disaster

using OpenFlow

Hayato Becchaku

When a large-scale disaster occurs, it is necessary to collect disaster information

quickly for rescue operation. However, it is dificult to use information systems, since

electricity and networks are not available.

The purpose of this research to verify the feasibility to construct the temporary

networks in the affected areas. The temporary networks have to satisfy two require-

ments. One is that network equipment are small and light due to carry easily. The

other is that temporary networks are to have the prototype of temporary networks. We

use Raspberry Pi as small and light equipment, and use OpenFlow to control priority

of the transfer. We evaluated the throughput of prototype system, and overhead of pri-

ority setting. Experimental results show that the prototype system achieved the good

performance to use in the affected areas.

key words OpenFlow, Raspberry Pi, SDN, QoS

– ii –

目次

第 1章 はじめに 1

1.1 研究背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 問題点の解決方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

第 2章 仮設ネットワーク環境の検討 4

2.1 仮設ネットワーク環境への要件 . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 仮設ネットワーク環境実現の方針 . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1 Raspberry Pi概要 . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.2 Ryu概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.3 Open vSwitch概要 . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Ryuでの QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

第 3章 仮設ネットワーク環境の実装 11

3.1 プロトタイプ構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 QoS機能プログラム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2.1 プログラム概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2.2 初期化処理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2.3 パケット解析処理 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2.4 HTTPリクエスト処理 . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3 Ryuアプリケーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

第 4章 評価 19

4.1 評価項目 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2 Raspberry Piを利用した際の性能評価 . . . . . . . . . . . . . . . . . . . 19

4.2.1 評価内容 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

– iii –

目次

4.2.2 評価環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2.3 結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2.4 考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.3 帯域制御機能の動作確認 . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.3.1 評価内容 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.3.2 評価環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.3.3 結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.4 帯域切り替えに掛かる時間の評価 . . . . . . . . . . . . . . . . . . . . . . 23

4.4.1 評価内容 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.4.2 評価環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.4.3 結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.4.4 考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

第 5章 おわりに 28

謝辞 29

参考文献 30

– iv –

図目次

1.1 仮設ネットワーク環境の概要図 . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 仮設ネットワークの構成図 . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Ryu SDN Framework概要図 . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1 プロトタイプ構成図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.1 通信帯域の比較結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2 毎秒毎のパケット転送量の比較結果 . . . . . . . . . . . . . . . . . . . . . . 21

4.3 帯域制御機能の動作確認結果 . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.4 帯域切り替えに掛かる時間結果 . . . . . . . . . . . . . . . . . . . . . . . . 27

– v –

表目次

2.1 仮設ネットワーク環境に求められる要件 . . . . . . . . . . . . . . . . . . . 5

2.2 使用するハードウェア，及びソフトウェア . . . . . . . . . . . . . . . . . . 9

2.3 Raspberry Piのモデルによる仕様の違い . . . . . . . . . . . . . . . . . . . 9

3.1 プロトタイプ構成におけるハードウェア . . . . . . . . . . . . . . . . . . . 12

4.1 評価環境の性能情報 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2 Queueの設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.3 QoSルールの設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

– vi –

第 1章

はじめに

1.1 研究背景

震災など，大規模災害発生時には被害状況を把握する必要がある．しかし，震災時は地震

や津波の影響による長時間停電や通信設備の被害が発生する [1]．そのため，電気や情報通

信インフラが途絶え，被災情報の共有に情報システムを利用する事が困難となる [2][3]．そ

のため，救助活動に情報システムを利用するには被災現場での仮設ネットワーク環境の構築

が必要となる．

被災現場で救助活動を被災現場で仮設ネットワーク環境を構築する際，一刻も早く救助活

動を開始できるよう迅速な環境構築が求められる [4]．迅速な仮設ネットワーク環境の構築

を行うために，救助隊員がネットワーク機器を所持，搬送，設置する状況を想定する必要が

ある．そのため，ネットワーク機器は小型で可搬性に優れたものである必要がある．

このような仮設ネットワーク環境の利用方法として，動画や音声による被災情報の送受信

が考えられる．また，被災情報の共有のために救助活動の拠点となる場所へ送受信する場合

が考えられる．しかし，仮設ネットワーク環境ではネットワーク機器やネットワーク機器間

の通信方式の影響により，限られた通信帯域を利用して通信することとなる．そのため，輻

輳によって被災情報などの緊急度の高い情報の遅延が発生する可能性がある．その結果，動

画や音声のリアルタイム送受信に支障が生まれる．そのため，ネットワーク機器の持つ機能

として緊急度の高い情報を優先的に転送する必要がある．

図 1.1の様に，救急隊員が持ち運ぶことの出来る可搬性の高いネットワーク機器を利用し，

かつ，被災情報などの緊急度の高い情報には広い通信帯域を提供し，その他の緊急度の低い

– 1 –

1.2 問題点の解決方法

情報には狭い帯域を提供する仮設ネットワーク環境が求められる．

1.2 問題点の解決方法

仮設ネットワーク環境で使用するネットワーク機器として，シングルボードコンピュータ

である Raspberry Piの使用を検討する．この Raspberry Piにソフトウェアスイッチであ

る Open vSwitch[5] を導入することで，小型で可搬性に優れたネットワーク機器として運

用できる．

また，ネットワーク機器として Raspberry Piを利用してスイッチング及び優先度の高い

情報を優先的に転送するために QoS 機能の搭載が必要となる．そのため SDN を実現する

ためのネットワーク制御技術である OpenFlow[6]を利用する．OpenFlowの特徴に，既存

のネットワーク機器とは異なり，コントロールプレーンとデータプレーンを分離している点

が挙げられる．それぞれをOpenFlowコントローラ，OpenFlowスイッチが役割を持つ．こ

の OpenFlowコントローラ内のアプリケーションを設計，実装することで目的となる QoS

制御が可能となる．

– 2 –

1.2 問題点の解決方法

被災情報 被災情報

その他その他

図 1.1 仮設ネットワーク環境の概要図

– 3 –

第 2章

仮設ネットワーク環境の検討

2.1 仮設ネットワーク環境への要件

仮設ネットワーク環境の実装方法を検討する際に求められる要件を表 2.1にまとめる．緊

急度の高い情報を優先的に送信するために，QoS機能を搭載する必要がある．QoS機能に

より，特定の端末，特定のパケットに対し一定の通信帯域を保証することが可能となる．各

スイッチ間の接続，速度を保証することが出来ないため，経路選択機能を搭載する必要があ

る．経路選択機能により，ネットワーク機器間の接続状況や混雑状況をもとにネットワーク

機器間の経路の変更が可能となる．その結果より安定した通信を行うことができる．ネット

ワーク機器を人が携帯することを検討しているため，機器が小型であり，電池，ポータブル

バッテリーでの動作が可能である必要がある．

検討した仮設ネットワーク環境のネットワーク構成を図 2.1に示す．仮設ネットワーク環

境は，SDNを実現するための技術である OpenFlowを導入する．各 OpenFlowスイッチは

1つの OpenFlowコントローラによって制御されている．端末は無線通信を使用して APへ

接続し通信を行う．端末から送信されたパケットはOpenFlowスイッチを経由しアプリケー

ションサーバへ送られる．各 OpenFlowスイッチ間は無線通信によって接続される．

各 OpenFlowスイッチは受信したパケットのヘッダ部を OpenFlowコントローラへ送信

する．OpenFlowコントローラは受け取ったパケットを解析し，OpenFlowスイッチへ制御

情報を送信する．制御情報を受け取った OpenFlow スイッチは情報を基に設定の追加，変

更を行う．

– 4 –

2.1 仮設ネットワーク環境への要件

表 2.1 仮設ネットワーク環境に求められる要件

要件 必要機能

緊急度の高い情報を優先的に送信す

る必要が有るため

QoS機能の搭載

各ネットワーク機器間の接続，速度

を保証する事ができないため

経路選択機能の搭載

ネットワーク機器を人が携帯するこ

とを検討しているため

ネットワーク機器の小型化

電池やポータブルバッテリーでの動作

AP端末

OpenFlowスイッチ

AP端末

OpenFlowスイッチ

OpenFlowコントローラ サーバ

OpenFlowスイッチ

図 2.1 仮設ネットワークの構成図

– 5 –

2.2 仮設ネットワーク環境実現の方針

2.2 仮設ネットワーク環境実現の方針

2.1から，仮設ネットワーク環境実現の方針を決定する．使用するハードウェア，ソフト

ウェアを表 2.2にまとめる．これらのハードウェア，ソフトウェアの概要を次節で述べる．

2.2.1 Raspberry Pi概要

Raspberry Piはラズベリーパイ財団によって開発されているシングルボードコンピュー

タである．縦 56.5mm，横 85.6mm と一般的な名刺サイズのコンピュータであり，CPU

に ARM プロセッサを採用している．現在 Raspberry Pi は Raspberry Pi 1 Model A+，

Raspberry Pi 1 Model 1 Model B+, Raspberry Pi 2 Model Bが販売されており，それぞ

れ CPUやメモリ，USBポート数，LANポートの有無などの違いがあげられる．モデルご

との主要な仕様の差を表 2.3に示す．

OSは公式サポートとして Debianベースで開発されている Raspbian，サードパーティ製

に Ubuntu Mate，Snappy Ubuntu Core，Windows 10 IoT Coreなどが提供されている．

2.2.2 Ryu概要

Ryu SDN FrameworkはNTT研究所発のオープンソースソフトウェアである [7]．ハード

ウェアではなくソフトウェアを用いてネットワーク構成や機能を制御できる SDN(Software

Defined Networking)を実現する．図 2.2に概要図を示す．Ryuは，SDNアプリケーショ

ンの開発に必要なライブラリやツールを提供するフレームワークである．OpenFlowコント

ローラの機能を持ち，Ryuのライブラリを利用することで OpenFlowスイッチを用いたア

プリケーションの開発が容易に行える．OpenFlowのバージョンには 1.0，1.2，1.3，1.4に

対応している．Ryuにはサンプルアプリケーションが予め同梱されており，オーソドックス

な機能であるスイッチやルータ，ファイアウォール，リンクアグリゲーション，スパニング

ツリーなどが用意されている．Ryuは Pythonで開発されており，アプリケーションの開発

も Pythonで行う．

– 6 –

2.3 Ryuでの QoS

2.2.3 Open vSwitch概要

Open vSwitchは Apache 2ライセンスでオープンソースで開発されているマルチレイヤ

ソフトウェアスイッチである．VM環境での仮想スイッチとして機能させることも想定され

ており，複数の物理サーバ間への分配をサポートするよう設計されている．加えて，仮想

ネットワーク層に標準的な制御機能と可視性のあるインタフェースを持っている．大半の

コードはプラットフォームに依存しない C で書かれているため，他の環境に移植すること

が容易である．現在のバージョンである Open vSwitch 2.4では以下の機能をサポートして

いる．

• トランクポート及びアクセスポートを持った標準な 802.1Q VLAN機能

• アップストリームスイッチでの LACPの有り無しに関わらない NICボンディング機能

• NetFlowや sFlow，視認性を高めるためのミラーリング

• QoS構成，とそのポリシング機能

• GENEVE，GRE，GRE over IPSEC，VXLAN，LISPトンネリング機能

• 802.1ag準拠のネットワーク監視，運用，保守支援機能

• OpenFlowに対応

• Cと Pythonのバインディングを持つトランザクション構成データベース

• Linux Kernelモジュールを使用した高性能フォワーディング

2.3 RyuでのQoS

Quality of Service(QoS)はパケットの内容に応じて送信を制御するサービスである．制

御は主に優先制御と帯域制御に分けることが出来る．OpenFlow では帯域制御による QoS

を実現することが出来る．Ryuに同梱されている RESTアプリケーションによって実現で

きる帯域制御方法を以下に示す．

• フロー単位の QoS

– 7 –

2.3 Ryuでの QoS

• DiffServによる QoS

• Meter Tableを使用した QoS

フロー単位の QoS は，各スイッチに Queue の設定とパケット内容に対するルールを追

加し帯域幅を割り当てる方法により実現する．これにより，帯域制限によるトラフィックの

シェービングと帯域保証を行うことが出来る．

DiffServはフロー単位の QoSとは異なり，複数のフローをクラスとして纏めクラスごと

の制御を行う．フロー毎に QoSを行った場合，フローが増えるにつれスイッチに設定する

必要があるためスケーラビリティが低い．DiffServではこの点が改善される．DiffServでは

まず，入り口のルータでフローを幾つかのクラスに割り当てる．IPヘッダの ToSフィール

ド内の DSCP値を利用し其の値を元に転送を行う．

Meter Table は OpenFlow1.3 にて導入された QoS を実現するための新しいテーブルで

ある．Meter Tableではレートを超えたパケットをドロップするアクションを使用する．こ

れにより通信帯域を制限するポリシングを実現することが出来る．

この実装ではソフトウェアスイッチとして Open vSwitchを使用するが，Open vSwitch

はMeter Tableに対応していないためフロー単位の QoSを行う．

– 8 –

2.3 Ryuでの QoS

表 2.2 使用するハードウェア，及びソフトウェア

ハード，ソフト 用途

Raspberry Pi 2 Model B OpenFlowスイッチ用コンピュータ

Ryu OpenFlowフレームワーク (OpenFlowコントローラ)

Open vSwitch OpenFlowソフトウェアスイッチ

表 2.3 Raspberry Piのモデルによる仕様の違い

モデル Raspberry Pi 1

Model A+

Raspberry Pi 1

Model B+

Raspberry Pi 2

Model B

CPUクロック周波数 700 MHz 700 MHz 900 MHz

CPUコア数 1 1 4

メモリ 256 MB 512 MB 1 GB

USB ポート 1 4 4

RJ45コネクタ 0 1 1

– 9 –

2.3 Ryuでの QoS

Ryuアプリケーション

Ryu SDN Framework

API

OpenFlowスイッチ

図 2.2 Ryu SDN Framework概要図

– 10 –

第 3章

仮設ネットワーク環境の実装

3.1 プロトタイプ構成

仮設ネットワーク環境の提案にあたり，基本的な性能の評価を行うためにプロトタイプシ

ステムを構築，実装する．プロトタイプ構成図を図 3.1に示す．OpenFlowスイッチには 2

つの LANポートを搭載し，クライアント端末と L2スイッチが有線で接続されている．ま

た，L2スイッチには OpenFlowスイッチとサーバ機，OpenFlowコントローラが接続され

ている．

次に，使用するハードウェアを表 3.1 に示す．OpenFlow コントローラは仮想マシン上

で実行させる．ソフトは VMware Workstation 12 Playerを利用し，OSは Ubuntu 14.04

Server，CPU割り当てを 1コア，メインメモリ割り当てを 1GBに設定した．

3.2 QoS機能プログラム

3.2.1 プログラム概要

QoS機能プログラムは以下の機能を持つ．

1. RESTによるスイッチへの QoS設定を行うための初期処理

2. 予め定義した Queueの登録

3. 予め定義したルールの追加

4. スイッチから受け取ったパケットの解析

5. スイッチが転送したパケットの合計サイズが閾値を上回った場合に帯域を制御するため

– 11 –

3.2 QoS機能プログラム

OpenFlowスイッチ

L2スイッチ

サーバ

OpenFlowコントローラ

クライアント

図 3.1 プロトタイプ構成図

表 3.1 プロトタイプ構成におけるハードウェア

ハードウェア 用途 性能 備考

Raspberry Pi 2

model B

OpenFlow

スイッチ

fastEthernet，USB2.0 ポー

トを搭載

OS は Raspbian

jessieを使用

VAIO

VPCZ21AGJ

ノートパソコン

OpenFlow

コントロー

ラ

intel core i5-2410M，メイン

メモリ 4GB，GigabitEther-

netを搭載

コントローラは

VMware Work-

station内で実行

Buffalo LUA4-

U3-AGT

USBLAN

ポート

USB3.0，GigabitEthernet

に対応

Raspberry Piに

接続する

– 12 –

3.2 QoS機能プログラム

にルールを追加する機能

3.2.2 初期化処理

初期化処理は，RESTを使用してスイッチへ QoS設定を行うための設定と予め定義した

Queueとルールをスイッチへ追加する．初めに，スイッチへ QoS設定を行うための設定を

行う．

処理は，スイッチがネットワークに接続されコントローラと Featureメッセージのやり取

りを行った後に行う．そのため以下のようにメソッドのデコレートを行う．

メソッドのデコレート� �@set_ev_cls(ofp_event.EventOFPSwitchFeatures, CONFIG_DISPATCHER)

def _init_set_queues(self, ev):� �次にコントローラへ REST で QoS 設定を行うために必要なスイッチの情報を送信する．

指定された URL へ JSON 形式でフォーマットしたデータを HTTP で送信する．送信は

SSHでスイッチへ接続し，スイッチから curlコマンドでコントローラへ HTTPリクエスト

を行う．

スイッチ情報の送信� �url = self.cont_url+"v1.0/conf/switches/"+dpid+"/ovsdb_addr"

send_data = json.dumps("tcp:192.168.0.4:6632")

command = "curl -X PUT -d \’"+send_data+"\’ "+url

self.connect_ssh(command)� �Queue 情報，ルールの設定もスイッチの設定と同じように，指定された URL へ JSON

形式でフォーマットしたデータを HTTPで送信する．

– 13 –

3.2 QoS機能プログラム

3.2.3 パケット解析処理

パケット解析処理はスイッチから PacketInメッセージを受信した際に実行する．そのた

め以下のようにメソッドのデコレートを行う．

メソッドのデコレート� �@set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER)

def _packet_in_handler(self, ev):� �次にスイッチから受け取った情報の解析を行う．パケット情報は ev.msg.dataに格納され

ている．このデータを Packetメソッドを利用して必要な情報を抜き出す．

msg.dataの操作� �msg = ev.msg

dpid = str(datapath.id)

pkt = packet.Packet(msg.data)� �Packet メソッドで取り出したデータは，get protocol メソッドで指定したプロトコルの

情報を抜き出すことができる．解析するパケットは Ethernetかつ IPv4を想定しているた

め，それ以外のパケットの場合は処理を終了する．

– 14 –

3.2 QoS機能プログラム

get protocolメソッド� �pkt = packet.Packet(msg.data)

pkt_eth = pkt.get_protocol(ethernet.ethernet)

if not pkt_eth:

# non ethernet

return

pkt_ipv4 = pkt.get_protocol(ipv4.ipv4)

if not pkt_ipv4:

# non ipv4

return

proto = pkt_ipv4.proto

if proto != 6 and proto != 17:

# !TCP and !UDP

return

dst_addr = pkt_ipv4.dst� �その後受け取ったパケットのサイズを取得し，リストに辞書型で格納する．パケットサ

イズはパケットを受け取る度に加算したものを保持する．パケットサイズの合計は，TCP，

UDPで別々に保持する．最後に HTTPリクエスト処理を行うメソッドへ取得したデータを

渡す．

3.2.4 HTTPリクエスト処理

パケット解析処理から受け取ったデータを元にルール追加設定の判定やデータの形成を行

う．初めに，予め定義したサイズと受け取った合計サイズを比較し，定義したサイズを上

– 15 –

3.2 QoS機能プログラム

回っていればルールの追加設定を送信するメソッドを呼び出す．そうでなければ処理を終了

する．

サイズ判定処理� �if size > limit_size:

self.sending_post(dpid, addr, proto, base_time)

return� �次に，ルールを追加するために必要な情報を JSON形式で形成する．送信先 IPアドレス

と TCPか UDPのプロトコルの情報を元にルールを作成する．

JSON形式データ形成� �def convert_into_json(self, addr, proto):

data = OrderedDict({"match":{}, "actions":{}})

data["match"]["nw_dst"] = addr

data["match"]["nw_proto"] = proto

data["actions"]["queue"] = "2"

return json.dumps(data)� �最後に指定されている URLに JSON形式のデータを HTTPで送信する．送信する際は

SSHでスイッチへ接続し，スイッチから curlコマンドを使用して HTTPリクエストを送信

する．

– 16 –

3.3 Ryuアプリケーション

sending post� �def sending_post(self, dpid, addr, proto):

json_data = self.convert_into_json(addr, proto)

url = self.cont_url+"qos/rules/"+"0000000000000002"

command = "curl -X POST -d \’"+json_data+"\’ "+url

self.connect_ssh(command)� �connect ssh� �

def connect_ssh(self, command):

client = SSHClient()

client.set_missing_host_key_policy(AutoAddPolicy())

client.connect(hostname, username=username,

password=password, port=port)

stdin, stdout, stderr = client.exec_command(command)

for l in stdout.read().split("\n"):

print l

client.close()

return� �3.3 Ryuアプリケーション

QoS 機能プログラムは，予め用意されている Ryu アプリケーションのサンプルアプリ

ケーションと組み合わせて使用する．以下に利用する Ryuサンプルアプリケーションとそ

の機能を示す．

• simple switch 13.py

• rest qos.py

• rest conf switch.py

– 17 –

3.3 Ryuアプリケーション

simple switch 13.pyは基本的な L2スイッチの機能を提供するアプリケーションである．

OpenFlow1.3 に対応している．rest qos.py はスイッチへ QoS 設定を行うための REST

APIを提供するアプリケーションである．Queueやルール，Meterテーブルの削除や追加，

参照を行うことが出来る．rest conf switch.pyは rest qos.pyなどで提供されている REST

APIを利用する前に必要な処理を行う REST APIを提供する．

– 18 –

第 4章

評価

4.1 評価項目

評価は以下の項目に沿って行う．

• Raspberry Piを利用した際の性能評価

• 帯域制御機能の動作確認

• 帯域切り替えに掛かる時間の評価

まず，一般的な PCに比べ性能の劣る Raspberry Piで実現する OpenFlowスイッチの実

用性を検証する．そのため，Raspberry Piを利用した際のオーバーヘッド計測と評価を行

う．次に実装した QoS機能プログラムの動作確認のために，帯域切り替え前から帯域切り

替え後までの間にスループット測定を行う．最後に，QoS機能プログラムにおいて，帯域切

り替え時に掛かる時間が情報の送受信にどの程度影響を与えているのかを検証する．そのた

め，帯域切り替えに掛かる時間を計測し評価する．

4.2 Raspberry Piを利用した際の性能評価

4.2.1 評価内容

Raspberry Pi とデスクトップ型 PC のスループットをトラフィック観測ツールである

Iperfを使用して計測する．Iperfクライアント，Iperfサーバでそれぞれ実行するコマンド

を以下に示す．

– 19 –

4.2 Raspberry Piを利用した際の性能評価

Iperfクライアント側でのコマンド� �iperf -s -u -p 5002� �Iperfサーバ側でのコマンド� �iperf -c 192.168.0.2 -p 5002 -u -b 1G -t 10� �サーバからクライアントへ，UDPを使用して 1Gbpsのトラフィックを 10秒間送信した．

4.2.2 評価環境

それぞれのマシン性能を以下に示す．

デスクトップ型 PCには，パケット転送を実現するために USB2.0ポートへ LANアダプ

タを 2機接続する．また，どちらの機器もソフトウェアスイッチとして Open vSwitchを使

用する．Ryuアプリケーションはスイッチ機能を実現する simple switch 13を使用する．

4.2.3 結果

図 4.1，4.2に結果を示す．

4.2.4 考察

比較結果より，通信帯域幅においてデスクトップ型 PC と比べ 10Mbps ほど低い事が分

かった．しかし，音声や動画の送受信に関しては問題ない速度であると考えられる．また，

ネットワーク機器間の無線化を検討すると，採用する無線通信の規格によっては，無線通信

での限界速度でボトルネックが発生する可能性が高い．そのため，末端の Raspberry Piで

のスイッチングに求められる能力としては十分であると考えられる．

– 20 –

4.2 Raspberry Piを利用した際の性能評価

70

75

80

85

90

95

100

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

通信帯域

(Mb

ps)

時間(sec)

Raspberry Pi

デスクトップ型PC

図 4.1 通信帯域の比較結果

9

9.25

9.5

9.75

10

10.25

10.5

10.75

11

11.25

11.5

11.75

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

転送パケット

(MB

ytes

/s)

時間(s)

Raspberry Pi

デスクトップ型PC

図 4.2 毎秒毎のパケット転送量の比較結果

– 21 –

4.3 帯域制御機能の動作確認

4.3 帯域制御機能の動作確認

4.3.1 評価内容

実装した QoS 機能プログラムにおいて，帯域制御機能の動作を Iperf にてスループット

測定を測定することで確認する．Iperfクライアント，Iperfサーバのでそれぞれ実行するコ

マンドを以下に示す．

Iperfクライアント側でのコマンド� �iperf -s -u -i 0.5 -p 5002� �Iperfサーバ側でのコマンド� �iperf -c 192.168.0.10 -p 5002 -u -b 10M -t 10� �サーバからクライアントへ，UDP を使用して 10Mbps のトラフィックを 10 秒間送信

した．

4.3.2 評価環境

評価の際に利用する Ryuアプリケーションを以下に示す．

• simple switch 13

• rest qos

• rest conf switch

• QoS機能プログラム

QoS機能プログラムにて予め定義する Queue及び QoSルールをそれぞれ表 4.2，4.3に

示す．

QueueID 0 の Queue は全てのパケットにて適用される．そのため，全ての転送パケッ

トには最大 10Mbpsの通信帯域が提供される．QueueID 1の Queueは OpenFlowコント

ローラ用に定義されている．設定した QoSルールにより，OpenFlowコントローラからの

送信，及び OpenFlowコントローラへの送信パケットには，最低で 7Mbpsの通信帯域が保

– 22 –

4.4 帯域切り替えに掛かる時間の評価

証される．QueueID 2のQueueは帯域制限用のQueueである．しきい値を超えたパケット

が送信された際に適用され，最大で 1Mbpsの帯域が提供される．しきい値は 10000(byte)

に設定した．

4.3.3 結果

図 4.3に結果を示す．

通常時は 3.5Mbpsから 5Mbps程度，10.5秒から 1Mbpsとなっていることから，意図し

た動作が行われていることが確認できる．

4.4 帯域切り替えに掛かる時間の評価

4.4.1 評価内容

QoS 機能プログラムにおいて，帯域切り替え時に掛かる時間が情報の送受信にどの程度

影響を与えるかを検証するため，帯域切り替えに掛かる時間の評価を行う．

時間の計測は，OpenFlowスイッチからパケットが転送され，そのパケットを OpenFlow

コントローラが受信し，イベントハンドラによって QoS機能プログラム内のメソッドが呼

び出された点から行う．計測の終了は，OpenFlowコントローラへ HTTPリクエストを送

信しその結果を受信，出力が終了した点となる．

4.4.2 評価環境

評価の際に利用する Ryuアプリケーションを以下に示す．

• simple switch 13

• rest qos

• rest conf switch

• QoS機能プログラム

– 23 –

4.4 帯域切り替えに掛かる時間の評価

Queue及び QoSルールの設定は帯域制御機能の動作確認の際に使用した設定を用いる．

時間測定には Python の time モジュール内の clock() を使用する．このメソッドにより

現在の CPU時間を取得し，開始時と終了時の差を算出することで時間を測定する．

4.4.3 結果

5回測定した結果とその平均を図 4.4に示す．

4.4.4 考察

帯域切り替えに掛かる時間は平均で約 0.32 秒という結果となった．実装した QoS 機能

プログラムでは，ある特定の IPアドレスに関して頻繁に帯域切り替えを行うことは想定し

ていない．そのため，0.32 秒程度であれば音声，動画の送受信への影響は少ないと考えら

れる．

帯域切り替え時間の改善として，REST APIを使用する方法を再検討することで時間の

削減ができると考える．現在の実装では OpenFlowコントローラから OpenFlowスイッチ

へ SSH接続を行い，その後 OpenFlowスイッチから OpenFlowコントローラへ HTTPリ

クエストを送信することで実現している．この処理に時間が掛かっていると考えられるた

め，直接 OpenFlowコントローラへ HTTPリクエストを送信し正常に処理される方法を検

討していく必要がある．

– 24 –

4.4 帯域切り替えに掛かる時間の評価

表 4.1 評価環境の性能情報

使用機器 CPU メモリ

Raspberry Pi 2 Model B ARM Cortex-A7 1GB

HP 6300P SFF Intel i3-3240 4GB

表 4.2 Queueの設定

QueueID 最大レート 最小レート

0 10Mbps -

1 - 7Mbps

2 1Mbps -

表 4.3 QoSルールの設定

送信元 IPアドレス 宛先 IPアドレス QueueID

192.168.0.2 - 1

- 192.168.0.2 1

– 25 –

4.4 帯域切り替えに掛かる時間の評価

0.00

0.50

1.00

1.50

2.00

2.50

3.00

3.50

4.00

4.50

5.00

0.0

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0

5.5

6.0

6.5

7.0

7.5

8.0

8.5

9.0

9.5

10.0

10.5

11.0

11.5

12.0

12.5

Mbits/sec

時間(sec)

図 4.3 帯域制御機能の動作確認結果

– 26 –

4.4 帯域切り替えに掛かる時間の評価

0.308452

0.366338

0.322077

0.2904160.312941 0.3200448

0

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0.4

1 2 3 4 5 平均

切り替え時間(sec)

試行回数(回)

図 4.4 帯域切り替えに掛かる時間結果

– 27 –

第 5章

おわりに

本研究では，災害時の救助活動に利用できる仮設ネットワーク環境を検討し，実現し

た．この環境により，Raspberry Pi を利用することでネットワーク機器の小型化，また，

OpenFlowを利用しての QoS制御が可能である．QoS機能に関しては，OpenFlowスイッ

チの転送するパケットを解析，そのパケットの送信元 IPアドレスやプロトコルに応じた帯

域制御が可能である．

今後の課題として，消費電力やモバイルバッテリーの考察が挙げられる．現在のモバイル

バッテリーは可搬性を損なわないサイズのもので最大 20000mAh 程度の放電容量を持つ．

このようなバッテリーを使用してどれくらいの時間 Raspberry Piを動作させることが出来

るのか，また，Raspberry Piのクロック周波数を下げた場合どれほど消費電力が下がるの

かといった点を考察する必要があると考える．また，実装を行わなかった経路選択機能の検

討及び実装が課題として挙げられる．経路の切り替えに掛かる時間の検証や，経路選択の際

に使用するアルゴリズムの検討や検証が必要であると考える．

– 28 –

謝辞

本研究を進めるにあたり，ご指導を頂きました指導教員であり主査の横山和俊教授に心よ

り感謝致します．また，本研究の副査をお引き受け頂きました情報学群 吉田真一准教授，植

田和憲講師に心より感謝致します．

大学生活において様々なご助言を頂きました，分散処理 OS研究室の先輩の皆様に心より

感謝致します．また，研究に対しての様々な議論にお付き合い頂きました同期の皆様に心よ

り感謝致します．

最後に，様々な側面から今まで私を支えてくださいました家族に心より感謝致します．

– 29 –

参考文献

[1] 総務省，“平成 23年版 情報通信白書”，2011．

[2] 関野雄人，柴田義孝，内田法彦，白鳥則郎，“OpenFlowをベースとした災害情報ネッ

トワークにおけるリンク切り替え技法の実現に関する研究”，2013．

[3] 菊池瑶介，柴田義孝，“大規模災害を考慮したモバイルクラウド型災害情報共有システ

ム”，2015．

[4] 多幡早紀，上田紘平，福井良太郎，嶋津恵子，重野寛，“OpenFlow を用いたWeb ア

プリケーションベースの災害時救命情報収集機構の検討”，2015.

[5] Open vSwitch，https://www.openvswitch.org/．

[6] OpenFlow，https://www.opennetworking.org/sdn-resources/openflow．

[7] Ryu SDN Framework，https://osrg.github.io/ryu/．

– 30 –