SDN
環境での定量的性能評価方法に関する一検討
山本 成一a),b) 西形 渉c),a) 上田 耕佑a) 河合 栄治a),d) A study of quantitative performance measurement on SDN environment Seiichi YAMAMOTOa),b), Wataru NISHIGATAc),a), Kosuke UEDAa),
and Eiji KAWAIa),d)
あらまし 現在，広く利用されている SDN 環境である OpenFlow では，そのコントロール環境 (処理系) と して ryu,trema 等が知られている．これらの処理系は利用者にコントロールプレーンを抽象化したネットワーク 操作環境 (API) を提供している．よって，ネットワーク管理者は普及したプログラミング言語を利用して，制御 アルゴリズムを容易に変更できる．一般的にソフトウェアの品質や性能は，利用するアルゴリズムに大きく影響 する．SDN 環境でも同様に，適正なアルゴリズムの利用が望まれる．また，SDN を実環境で利用する際には， 物理的な制約も考慮する必要がある．本稿では，コントローラソフトウェアの挙動に注目し，SDN が物理環境 上で稼働する際の性能を定量的に比較する手法を提案する． 1. SDN環境の評価 従来のネットワークは，ネットワークスイッ チやルータで構成されている．これらの機器 はIP ルーティングやイーサネットスイッチ ング等の標準化された機構で動作し，その挙 動はネットワーク利用前の個別設定で規定さ れる． 具体的には，IPルーティングではIPパケッ トの宛先IPアドレスが識別子として利用さ れ，IPルータにて転送先の選択がされる．ま た，イーサネットスイッチングはイーサネッ トフレームの宛先MACアドレスが識別子と なりイーサネットスイッチにて転送先の選択 がされる．つまり，いずれの場合も宛先情報 を利用した経路選択がされる機構となって いる． 以下に，コントロールプレーンとデータプ レーンの挙動に注目して，IPルーティング a)情報通信研究機構
National Institute of Information and Communications Tech-nology
b)東京大学 生産技術研究所
Institute of Industrial science, The University of Tokyo c)イクシアコミュニケーションズ株式会社
Ixia Communications K.K. d)奈良先端科学技術大学院大学
Nara Institute of Science and Technology
およびイーサネットスイッチングでの動作概 要を説明する． 転送先選択の判断に利用されるデータベー スは，経路表と呼ばれる．IPルーティング の場合は，個々のルータが保持する経路表を 手動で静的に設定するか，またはルーティン グプロトコルを利用して，ルータ間にて経路 情報の伝播をさせ，動的な更新を行う． ルーティングプロトコルはいくつかの種 類が存在する．ユニキャストにおいては， RIP,OSPF,ISIS,BGP等の種類が存在するが， トポロジを生成する際のアルゴリズムや，利 用可能なルータ数，設定可能なパラメタ(メ トリック)数，等のデータプレーンのトポロ ジを構成するための手法やパラメタに違い がある．一方，一旦トポロジが決まってしま えば，いずれのルーティングプロトコルを利 用した場合も，データプレーンパケットが宛 先情報を利用して転送される方式に違いは ない． 一方，マルチキャストは，送信ホストから のトラフィックを受信を希望するホストにの み届ける技術である．”１つの送信ホストか ら多数の受信ホスト宛にトポロジ上を分岐し
てトラフィックが流れる様”が，木の根本か ら枝を経由し葉に向かうように見えるため， ツリー上のトポロジを構成すると言われてい る．マルチキャストのルーティングプロトコ ルは，PIM-SM,PIM-SSM,PIM-DM,MOSPF 等がある．利用するルーティングプロトコル に応じ，データプレーントポロジの構成手 法が異なり，ツリーの状態を作る最適化(余 計な枝葉の部分を取り除く”枝刈り”)の方法 や，初回の通信で送信ホストからのデータプ レーンパケットと，受信ホストからの受信要 求(コントロールプレーンパケット)を集め る場所(ランデブーポイント)を利用するか 否か，マルチキャスト専用の経路交換を行う か否か，等での違いがある．マルチキャスト は受信ホストの受信希望を契機にトポロジを 作成する都合，コントロールプレーンの構成 と，データプレーンのパケット転送が複雑に 関係しており，利用するルーティングプロト コルによってデータプレーントポロジの構成 手法のみならず，データプレーンの挙動も変 化する． 次に，イーサネットスイッチ(以下，スイッ チ)で行われるイーサネットスイッチングの 動作順序を説明する． （1） スイッチは，転送が初回のデータプ レーンフレームはフラッドさせ全てのポート に転送させる． （2） スイッチは，転送したフレームの， 送信元MACアドレスと送信元ポートを経路 表(FDB:フォワーディングデータベース)に 記録する． （3） この記録により，スイッチは特定の MACアドレス宛のフレームはどのポートに 転送すればよいかの選択が可能になる． この動作により，スイッチは，他のポート からデータプレーンフレームを受信した場合 は，そのフレームの宛先MACアドレスを経 路表内で検索し，見つかった場合は宛先ポー ト向けにデータプレーンフレームを転送す る．データプレーンフレームが，経路表内で は見つからなかった場合はフラッドさせる． これらの動作を繰り返すことで，経路表の更 新(学習)を行う．このように，IPルーティ ングのように特定のルーティングプロトコル を用いた経路情報交換は行わない． しかし，イーサネットスイッチングではト ポロジに冗長性をもたせる目的で，スパニン グツリープロトコルが存在する． スパニングツリープロトコルを利用する と，複数個のスイッチの接続にて，意図的に 物理的なループ(環)をつくった際に，一定 箇所で，論理的にフレーム転送を停止した状 態のポート(ブロックポート)ができる．ブ ロックポートが動作した状態で通常利用を行 う．この状態にて，ループ状トポロジの一部 で障害が発生し切断された場合，ブロックし ていたポートが解除され，迂回路が現れる． この迂回路を利用することでトポロジが変 化し，障害発生時においても通信が可能とな る仕組みである．（注 1）このようにして，コン トロールプレーンとして常に各リンクの正 常性確認の通信が動作することでデータプ レーンが利用するトポロジを決定している． この状態にて，各スイッチ自身が経路表を更 新し，データプレーンフレームの転送を行っ ている．なお，イーサネットスイッチングに おいても，一部機器では静的な経路表設定が 可能である．（注 2）
一方，SDN(Software Defined Network)環 境では，コントロールプレーンとデータプ
（注1）：詳しくは，ツリー状トポロジを生成する仕組みであるが，ここで は割愛する
（注2）：具体的には，スイッチの経路表に対し，宛先MACアドレスと宛 先ポートを手動設定する．
レーンが分離され，コントローラが中央集権 的にネットワーク内の各トラフィックの挙動 を制御する．この際にコントローラの挙動 は特定のアルゴリズムに制限されず，ネット ワーク管理者が作成するソフトウェアにより 自由な定義が可能である． 例えば，現在，広く利用されている SDN 環境であるOpenFlow [1] では，IPパケット またはイーサネットフレームのヘッダ情報の 組み合わせを元に，フローを定義し，フロー 毎に処理の定義が可能である．具体的には， 以下の挙動となる． （1） 接続ホストXより接続ホストY宛 にデータプレーンパケットを送出する． （2） OpenFlowスイッチは，収容ホスト が送信したデータプレーンパケットについて， スイッチ内のフロー情報キャッシュに該当し ないものを受信した場合に，OpenFlowコン トローラへ，処理伺いのコントロールプレー
ンパケット(packet in)を送付する．
Open-Flowコントローラは，packet inを受け取り，
コントローラプログラム内で，ネットワーク 管理者が規定した処理を選択する．
（3） OpenFlowコントローラは，選択さ れた処理内容を処理指示のコントロールプ
レーンパケット(flow mod)にて，OpenFlow
スイッチへ伝える，また， OpenFlowコン
トローラは，処理待ちとなっているパケット 内容と指示を伝えるコントロールプレーン パケット(packet out)を，OpenFlowスイッ
チへ伝えるなお，packet outを受け取った OpenFlowスイッチは，処理待ちになってい たデータプレーンパケットに対し，指定され た処理を行う．また，フローキャッシュを更 新し，キャッシュの有効期限が切れるまでは， 同一フローのパケットを受信した場合に，再 度packet inは生成せず，キャッシュに記載 された処理を行う． （4） 接続ホストYにデータプレーンパ ケットが到着する． 図1にOpenFlowシステムの概要図を示す． 図 1 OpenFlowシステムの概要 OpenFlow のコントロール環境（処理系) として ryu [2],trema [3] 等が知られている． これらの処理系は利用者にデータプレーンを 抽象化したネットワーク操作環境(API) を 提供している．よって，ネットワーク管理者 は普及したプログラミング言語の利用や，多 くのサンプルを組み合わせにより，制御アル ゴリズムを容易に変更できる． 一般的にソフトウェアの品質や性能は，利 用するアルゴリズムが大きく影響する．SDN 環境も同様であるため，目的とする動作や性 能についての条件を満たすべく，適正なアル ゴリズムの利用が望まれる．また，SDN を 実環境で利用するにあたっては，物理的制約 事項を考慮する必要がある． 本稿では，コントローラソフトウェアの挙 動に注目し，SDN環境の特性評価のため，性 能指標が定義された場合に，その指標を定量 的に求める手法を提案する． 2. 提 案 手 法 SDN 環境の性能測定について先行する手 法を示す． cbench [4] は，OpenFlow スイッチをエミ ュレーションするソフトウェア実装である．
cbench は測定対象となるコントローラに対 し，packet in メッセージを送付する．コン トローラはflow modメッセージで応答する． コントロール処理系のベンチマーク測定と して，flow mod を計測することで，スルー プットやレイテンシを算出する．このように して，異なるコントロール処理系の性能を定 量的に比較する． OFCBenchmark [5] は OFCBenchmark ク ライアント(OC)と，OFCBenchmarkコン トロールセンター(OCC) で構成されるサー バクライアント型のソフトウェア実装であ る．OCC からの指示を受け，OCは接続す る仮想スイッチにトラフィックを生成する． これにより，広域な OpenFlow ネットワー クにてOCが連携してトラフィック送受信を 行い，性能測定を行っている．cbench およ びOFCBenchmarkはソフトウェア実装であ るため，実機を用意せずとも評価環境を構築 できるというメリットがある． Ixia 社の IxNetwork [6]は計測用のソフト ウェア実装である．IxNetworkは同社のハー ドウェア計測器を利用して，OpenFlow ス イッチのエミュレーション環境を構築できる． IxNetwork は cbench で計測する flow mod に加え，packet outの計測も可能である．ま た，ハードウェアで動作するため，測定精度 が高いというメリットがある． 上記の３方式は特定のアルゴリズムで制御 される機構を測定対象としており，任意のア ルゴリズムを測定対象とすることができな い．また，実環境のデータプレーンを利用し ないため，実利用から離れた環境となり，実 環境の制約事項を見逃す可能性が大きくなる というデメリットがある． このため，本稿では，SDN 環境の性能測 定を，実環境に近い形で実現する事を目標と し，1)コントローラで任意のアルゴリズム が選択できること，2)ネットワークには任意 のトラフィック転送ができること，を要求事 項とする． よって，コントロールプレーンメッセージ を計測する手法は採用せず，特定のネット ワークフローを生成し，それが意図どおり流 れたことを確認する，データプレーントラ フィックを観測する手法を提案する． 図 2 提案システム概要 3. 評 価 提案手法を利用した場合の，特定環境の評 価例を示す．本評価例では，特定の環境下で の利用シナリオを考慮し，環境に影響する 主要なパラメタと，性能値の定義を行った． そして，パラメタを変化させた際に得られる 性能値の測定を行い，特定環境の特性を考察 した． 3. 1 OFSを1台とした場合の評価 OpenFlow では，その仕様よりpacket in を用いて，OFSからOFCへ新規フローの処 理に関する問い合わせが必須であり，問い合 わせ中は，OFSに到着する該当フローのパ ケットは処理待ちの状態となり，通信が停止 してしまう．特に連続してpacket inが発生 する場合は，OFC,OFSともにフロー毎に処 理待ちの状態を保持しなければならず，高い 負荷となることが想定される． この状態が通信に与える影響を調査するた
め，等間隔で新規フローを生成する環境に て，生成した全てのフローについての処理に かかる時間をレイテンシと定義し，フロー数 を増加させた場合の，レイテンシ変化を観測 した． また，packet in の処理時に意図的に一定 の遅延を挿入した．この遅延を変更すること で，OpenFlowネットワークの転送制御アル ゴリズムの変更と見立て，転送制御アルゴリ ズムが変更された際の影響についても観測 した． 評価環境を以下に示す．OpenFlow コント
ローラをOFC，OpenFlowスイッチをOFS， 評価用のデータプレーントラフィックの発生 源となるホストを Host A，評価用のデータ プレーントラフィックの折り返し地点となる ホストを Host Bとし，（注 3）図3の形で構成 した．これは，最小単位のOpenFlowネット ワークの特性を評価するため，ホスト2台 と，の間にスイッチを挟むトポロジとした． 図 3 測定システム OFC の 制 御 ア ル ゴ リ ズ ム と し て ，ryu にサンプルで付属するスイッチ実装
(sim-ple switch.py)を用いた．遅延挿入はpython の”time.sleep()“関数を利用した．Host B で
（注3）：測定に用いたハードウェアおよびソフトウェアの名称等を以下に 記す．
• OFCサーバ,Host A,Host B: Aopen XC mini(Intel Mobile CPU Core i5-560M, Mem 8GM, Ubuntu Linux 14.04)
• OFC: ryu 3.23.2 (python 2.7.6)
• OFS: NEC PF5240 (OS-F3PA Ver. V5.1.1.0)
は”ip address” コマンドでmacvlanを利用
し，異なるmacアドレスとIPアドレスの組 を1000個用意した．Host A はタイムアウ ト10秒，送信間隔25 msec としたfpingで データプレーントラフィックを送信した．こ のトラフィックでは，宛先のHost BのIPア ドレスを変更する事で，フロー数を変化さ せた．Host A で実行するfpingの実行時間 を”time”コマンドで測定し，レイテンシの 測定を行った． 本評価時のシステムの動作は以下となる． （1） ホストAは，データプレーンパケッ ト(以下，対象パケット)として，ホストBの IPアドレスを解決するためのARP request を収容しているOFSへ送信する． （2） OFSはホストAからの対象パケッ トを受信し，OFC宛に packet in を送付し， 対象パケット処理の指示を待つ．
（3） OFCはOFSからのpacket in を受
信すると，挿入した遅延 (30msec)分待機 する． （4） OFCは packet in で届いた対象パ ケットの送信元MACアドレス(src mac)に ついてFDBの学習を行う． （5） OFCは，対象パケットの宛先MAC アドレス(dst mac)とFDBを対比する．対 比により， • 学習済みにて宛先ポートが判別した 場合は，“対象パケットのヘッダ情報で定義 されるフロー(以下，定義フロー)はその宛 先ポート向けに転送せよ”と指示する内容の
flow mod をOFSへ送付する．
• 宛先が判別しない場合は，OFSへ，
“定義フローはフラッドせよ”と指示する内
容の flow modを OFSへ送付する．
（注 4）また宛先の判別可否にかかわらず，“処理
待ちであった対象パケットの転送”を指示す るpacket out を OFSへ送付する．
（6） OFSはflow modを受け取り，定義 フローの転送指示をキャッシュする．また， packet outを受け取ることで，対象パケット をホストBへ転送する(本構成ではトポロジ 上，flow mod の指示内容によらず，ホスト Bへの転送となる) （7） 対象パケットがホストBに到着す ると，ホストBは新規の対象パケットとし て，ホストA宛にARP replyを送信する． （8） 以降は，ホストBからホストA向 けに上記と同様の手順を繰り返す． （9） ホストBからのARP replyがホス トAに届き，ARP解決処理が終了した後は， ホストAからホストB宛の対象パケットが
ICMP echo request，ホストBからホストA
宛の対象パケットが，ICMP echo reply と
なって，上記と同様の手順を繰り返す． 遅 延 挿 入 な し の 場 合 と ，最 小 の 遅 延 (30msec) を挿入した場合での，フロー数に 対するレイテンシ変化，およびレイテンシ差 分の変化を図4に示す．なお，試行は3回実 施し，算術平均を採用した．レイテンシ差分 は，フロー数が 100 までの間は挿入分相当 (0.03sec) である．フロー数が100を超える とレイテンシ差分が単調増加となっている． このため，対象システムは一定量の遅延処理 がボトルネックとなることが判明した． 次に，挿入遅延時間を変更した場合のレイ テンシ変化を図5に示す．なお，試行は3回 実施し，算術平均を採用した．これより，評 価対象システムは，フロー数(F )とレイテ レスとなっているため，“宛先が判別しない場合”の扱いとなりフラッドさ れる．一方，ARP reply，ICMP echo reply, ICMP echo requestは， 宛先MACアドレスがユニキャストアドレスになり，“学習済みにて宛先 ポートが判別した場合”の扱いとなり宛先ポート向けのみに転送される． これはARP replyはARP requestの返信であること，ICMPパケッ トはARP解決がされた後に生成されることより，宛先MACアドレス が自明となる為である． 図 4 遅延挿入によるレイテンシ増加の傾向 図 5 遅延挿入時間を変更した場合のレイテンシ変化 ンシ(L)は，挿入遅延(D)と定数(K)を用 いて， log L = D log F + K1 (1) L = eK1FD (2) L = K2FD (3) で近似できる特性を有することが判明した． レイテンシがフロー数の冪関数となる理由 は，ボトルネックで発生する遅延が累積し， 逐次処理されるフローを遅延させている為と 考えられる． 3. 2 複数のOFSを用いた場合の評価 次に，構成を変化させた時の影響を測定し た．より複雑な構成とした場合の基本形とし て，複数のOFSを用いながらも単純なトポ ロジとして，OFSを数珠つなぎ状に増加さ せていく場合のレイテンシ変化を測定した．
表 1 フロー数に対するレイテンシ変化への近似曲線適用 OFS台数 近似曲線式 1 L = 2.24F1.46F 2 L = 4.52F1.44F 4 L = 22.2F1.17F 8 L = 74.4F1.46F なおOFCは単一の構成とした．その他の条 件は，3. 2と同一のソフトウェアおよびハー ドウェア構成とした．概要図を図6に示す． こ の 構 成 に て ，OFC で の 遅 延 挿 入 を 30msec とし，フロー数を変化させた場合 の結果を図7に示す．なお，3. 2と同様に試 行は3回実施し，算術平均を採用した． フロー数を100から800まで変化させたと ころ，レイテンシは，両対数軸グラフでほぼ 直線的にプロットすることができた．このプ ロットに対し，近似曲線を生成した場合，表 1のパラメタが得られた．（注 5） なお，複数のOFS用いた構成では，1台の 物理的なOFS上に，仮想的な複数のOFSを 図 6 OFSを複数台にした測定システム概要 図 7 OFSを複数台にした際のフロー数に対するレイテ ンシの変化 (遅延挿入 30msec) （注5）：近似曲線の適用には，Microsoft社製Excel 2016の グラフオ プションの近似曲線機能にて，累乗近似を指定し，有効数字3桁を利用 した． 動作させた．これらの仮想OFSは，物理的 に1台のスイッチのポート同士をUTPケー ブルでループ状に接続するハードループ接続 で構成した．図8に物理構成図を，図9に論 理構成図を示す． 図 8 測定システムの物理構成図 図 9 測定システムの論理構成図 複数のOFSを利用した構成にて，システ ムの動作はのOFSを1台とした場合とほぼ 同じであり，違いはOFSが隣接している部 分の処理のみとなる．違いがある部分(6)を 以下に示す．
（6） OFS は flow mod を受け取り，定 義フローの転送指示をキャッシュする．また， packet out を受け取ることで，対象パケッ トをホストB側に隣接するOFSへ転送する (本構成ではトポロジ上，flow modの指示内 容によらず，隣接機器への転送となる)．(2) から(6)までを対象パケットがホストBに到 着するまで，繰り返す． この構成において，OFSの統計情報で確認
する限り，packet in packet outを含め，パ ケットドロップやエラーの発生は見られな
かった．よって，仮想OFSを利用しても，本
実験でデータが得られた範囲ではボトルネッ クとなる箇所は無かったと考える．
4. ま と め 本稿ではSDN 環境の定量的な性能評価方 法として，測定フレームワークに関する一方 法の提案を行った．本方式の評価例として， OpenFlow環境を対象とした性能測定につい て，一定数のデータプレーントラフィックフ ローに対し，システム全体での転送にかかる 時間を指標としての比較を行い，特性を考察 するケースを紹介した． 今後はハードウェア測定器を活用し，取得 可能な評価値の精度を向上や，異なる指標を 利用しての比較方法を検討予定である．加え て，SDN 環境における性能測定方法として の要素の検討と，方法論としての議論を行う 予定である． 参 考 文 献
[1] McKeown, Nick and Anderson, Tom and Balakrish-nan, Hari and Parulkar, Guru and Peterson, Larry and Rexford, Jennifer and Shenker, Scott and Turner, Jonathan. OpenFlow: Enabling Innovation in Cam-pus Networks. SIGCOMM Comput. Commun. Rev., 38(2):69–74, March 2008.
[2] Ryu SDN Framework Community. Ryu SDN Frame-work. http://osrg.github.io/ryu/. Accessed: 2015-09-01.
[3] Yasuhito Takamiya, et al. Trema, Full-Stack Openflow Framework in Ruby and C. http://trema.github.io/ trema/. Accessed: 2015-09-01.
[4] Amin Tootoonchian, Sergey Gorbunov, Yashar Gan-jali, Martin Casado, and Rob Sherwood. On controller performance in software-defined networks. In USENIX
Workshop on Hot Topics in Management of Internet, Cloud, and Enterprise Networks and Services (Hot-ICE), volume 54, 2012.
[5] Michael Jarschel, Frank Lehrieder, Zsolt Magyari, and Rastin Pries. A flexible openflow-controller bench-mark. In Software Defined Networking (EWSDN),
2012 European Workshop on, pages 48–53. IEEE,
2012.
[6] Ixia. IxNetworkTMOpenFlow Solution. https://www. ixiacom.com/sites/default/files/resources/datasheet/ ixnetwork_openflow.pdf. Accessed: 2015-09-01.
