MPLS-OpenFlow 結合アーキテクチャを用いた迂回制御方式

一般社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS, INFORMATION AND COMMUNICATION ENGINEERS
信学技報
IEICE Technical Report MPLS-OpenFlow 結合アーキテクチャを用いた迂回制御方式 土屋 俊貴†
川原崎 雅敏‡
†筑波大学情報学群情報メディア創成学類
〒305-8550 茨城県つくば市春日 1-2
‡筑波大学図書館情報メディア系 〒305-8550 茨城県つくば市春日 1-2
E-mail:
†[email protected],
‡[email protected]
あらまし IP ネットワークで多く用いられている OSPF のような最短経路ルーチングプロトコルは,網の負荷状態に偏りが
生じやすく,特定リンクに負荷が集中してもそれを分散させることができない.この問題に対し,我々は Relay Node アルゴリ
ズムによる迂回経路制御を提案している.このアルゴリズムは MPLS 網において,Relay Node と呼ぶ迂回ノードを戦略的に決定
し,そのノードを経由する迂回パスを設定して最適化を行うものである.本論文では OpenFlow によって制御される MPLS 網上
で Relay Node アルゴリズムを実行するアーキテクチャを設計し,ファイル転送とストリーミングトラヒックに対する制御特性
の解析・評価を行うと共に,実網における Relay Node アルゴリズムの実装可能性の検証を行う.その結果,迂回制御の有効性
と実装可能性を示す.
キーワード
迂回制御,MPLS,SDN/OpenFlow,Relay Node
Relay Node Based Routing Control Using MPLS-OpenFlow Architecture
Toshiki TSUCHIYA†
Masatoshi KAWARASAKI‡
†College of Media Arts, Science and Technology University of Tsukuba, 1-2 Kasuga, Tsukuba, Japan
‡Faculty of Library, Information and Media Science, University of Tsukuba, 1-2 Kasuga, Tsukuba, Japan
E-mail:
†[email protected],
‡[email protected]
Abstract In IP network that uses the shortest path routing such as OSPF, deviation tends to occur in the loading state of a
network. Furthermore, traffic concentration on a specific link cannot be dispersed. To solve this problem, we have proposed a
detour route control by using Relay Node algorithm. This algorithm performs network optimization by setting the detour path
passing through the Relay Node that is strategically determined in the MPLS network. In this paper, we design the architecture
to run the Relay Node algorithm on MPLS network that is controlled by OpenFlow. We carry out the analysis and evaluation
of the control characteristics for file transfer traffic as well as streaming traffic, and verify implementation possibilities of
Relay Node algorithm in the real network. As a result, we show the effectiveness of detour route control and its
implementation possibility.
Keywords Routing control,MPLS,SDN/OpenFlow, Relay Node
1. は じ め に
ブロードバンド環境やスマートフォンの普及,ネッ
トワークを利用した様々なアプリケーションの増加に
よってインターネットトラヒックは急激に増加してい
る.このような状況に対応するには,網資源を有効に
使い切れるネットワーク制御の実現が重要である.し
か し 現 在 多 く 利 用 さ れ て い る Open Shortest Path First
(OSPF)の よ う な 最 短 経 路 ル ー チ ン グ で は ,網 の 混 雑 状
況に偏りができやすく,特定リンクに負荷が集中して
もそれを分散させることができない.
こ の 問 題 に 対 応 す る 技 術 と し て MPLS (MultiProtocol Label Switching) が あ る . MPLS は Label
Switched Path (LSP)と し て パ ス の 概 念 を 導 入 し , そ の
経路と容量を明示的に指定することで網資源の有効利
用 が 可 能 と な る .し か し LSP の ラ ベ ル 配 布 は 通 常 で は
ルータのルーチングテーブルに従った経路で行われる
た め , 最 短 経 路 ル ー チ ン グ を 使 用 し て い る と , LSP も
最 短 経 路 に 設 定 さ れ て し ま う . こ の 問 題 は MPLS
Traffic Engineering (MPLS-TE)の Explicit Routing (ER)
や Constrained Shortest Path First (CSPF)等 で 対 応 さ れ
る が ,ER で は 経 路 が 固 定 的 で あ り ,CSPF は 故 障 /輻 輳
リンクを枝切りして最短経路を計算するため,経路設
定が不安定になりがちである.そのため効率的な
MPLS パ ス 網 を 設 計 ・ 制 御 す る 技 術 が 必 要 で あ る .
近年,ネットワーク制御とデータ転送を分離し,ソ
フ ト ウ ェ ア で ネ ッ ト ワ ー ク を 制 御 す る Software
Defined Network (SDN)が 注 目 さ れ ,SDN を 実 現 す る イ
ン タ フ ェ ー ス と し て OpenFlow[1]が 開 発 さ れ て い る .
OpenFlow で は , OpenFlow Controller (以 下 Controller)
が OpenFlow Switch (以 下 Switch)に 対 し て フ ロ ー の 処
理方法を指定することで,ネットワークの集中管理を
可能にする.しかし,制御ポリシーや経路計算は実装
者依存となっている.
我 々 は , MPLS を 利 用 し た 迂 回 経 路 制 御 方 式 と し て
Relay Node ア ル ゴ リ ズ ム を 提 案 し て い る [2]. こ れ は ,
最 短 経 路 と は 別 に 戦 略 的 に 設 定 し た Relay Node を 通 る
迂回経路を設定し,トラヒックを最短経路と迂回経路
に分散させることでネットワークの利用効率を高める
も の で あ る . Relay Node ア ル ゴ リ ズ ム に よ り , 線 形 計
画法で求めた理論上の最適解に近い負荷バランスと性
能 向 上 が ,よ り 簡 易 な 計 算 方 法 で 実 現 で き る .し か し ,
Relay Node 方 式 の 検 討 は 数 値 シ ミ ュ レ ー シ ョ ン で 行 っ
たため,パケットレベルの振る舞いや,アプリケーシ
ョン(ファイル転送,ストリーミング等)による網特
性の違いを解析できていなかった.また,その実装方
法についても未検討であった.そこで,本論文では
Relay Node を 用 い た 迂 回 制 御 方 式 に つ い て , パ ケ ッ ト
レベルシミュレーションによる方式評価を行うと共に,
OpenFlow を 用 い た 実 装 方 式 に つ い て 検 討 を 行 う .
This article is a technical report without peer review, and its polished and/or extended version may be published elsewhere.
Copyright ©20●● by IEICE
OpenFlow で は , Controller へ の 負 荷 集 中 に 伴 う ス ケ
ー ラ ビ リ テ ィ が 問 題 と し て 挙 げ ら れ る .改 良 策 と し て ,
Switch が フ ロ ー の 転 送 量 を 独 自 に 判 断 し ,大 容 量 フ ロ
ー の み を Controller で 制 御 す る 方 法 [3], ネ ッ ト ワ ー ク
を 複 数 の ド メ イ ン に 区 切 り , ド メ イ ン 毎 に Controller
を 配 置 す る 方 法 [4]が 提 案 さ れ て い る .
文 献 [5]は MPLS と OpenFlow の ア ー キ テ ク チ ャ 的 な
ト レ ー ド オ フ 関 係 を 論 じ , MPLS は LSP に よ る 軽 量 で
高速なパケット転送を実現するものの,管理者が制御
ポリシーを指定する手段を持たないこと,対して
OpenFlow は 集 中 管 理 ゆ え に 管 理 者 ポ リ シ ー を 反 映 し
や す い が ,各 Switch で は パ ケ ッ ト 毎 に フ ロ ー 条 件 の マ
ッチングを行うため負荷が重くなることを指摘し,双
方の利点を取り入れたアーキテクチャの必要性を述べ
て い る .文 献 [6]は 現 状 の MPLS で は デ ー タ プ レ ー ン と
コントロールプレーンが密結合して複雑化しているこ
と を 指 摘 し ,OpenFlow に よ っ て 両 者 を 明 確 に 分 け る シ
ステムを提案している.
そ こ で 本 論 文 で は , Relay Node ア ル ゴ リ ズ ム を
OpenFlow と MPLS を 融 合 し た ア ー キ テ ク チ ャ で 実 現
し ,Mininet[7]環 境 に お い て 評 価 実 験 を 行 う .実 験 で は
フ ァ イ ル 転 送 を 想 定 し た TCP フ ロ ー と ス ト リ ー ミ ン
グ を 想 定 し た UDP フ ロ ー を 生 成 し ,パ ケ ッ ト レ ベ ル で
の挙動やアプリケーション毎のトラヒック特性を評価
す る と 共 に , Relay Node ア ル ゴ リ ズ ム の 実 ネ ッ ト ワ ー
クにおける実現可能性の検証を行う.
以 下 , 2 章 で 提 案 方 式 と し て Relay Node ア ル ゴ リ
ズ ム の 概 要 と MPLS-OpenFlow 結 合 ア ー キ テ ク チ ャ に
よ る 実 現 方 法 つ い て ,3 章 で は 提 案 方 式 の 評 価 モ デ ル ,
4 章 で提案方式の有効性評価,5 章で提案方式の実装
可能性の評価を述べ,6 章で結論を述べる.
2. 提 案 方 式
本 章 で は OpenFlow と MPLS 網 の 融 合 ア ー キ テ ク チ
ャ に よ る Relay Node 迂 回 制 御 方 式 に つ い て 述 べ る .
2.1. OpenFlow の 構 成
OpenFlow Switch は 図 1 に 示 す よ う に Flow Table に
各 フ ロ ー の 挙 動 を 指 示 す る Flow Entry を 格 納 し て い る .
Flow Entry は Match, Action, Counter の 3 フ ィ ー ル ド で
構 成 さ れ る . Match フ ィ ー ル ド に は フ ロ ー を 識 別 す る
た め の MAC ア ド レ ス や IP ア ド レ ス , MPLS ラ ベ ル 等
を 格 納 す る .Action フ ィ ー ル ド は Match フ ィ ー ル ド の
条件に適合したパケットの処理方法を指定し,
Counter フ ィ ー ル ド は フ ロ ー の 統 計 情 報 を 記 録 す る .
図 1. OpenFlow Switch の 構 成 図
2.2. ネ ッ ト ワ ー ク ア ー キ テ ク チ ャ
提案方式のネットワークアーキテクチャを図 2 に
示 す . Edge Router, Core Router は OpenFlow Switch で
構 成 し , Controller は こ れ ら の Router に 対 し て 動 的 に
Flow Entry の 追 加・削 除 を 行 な う こ と で LSP を 設 定 し ,
ネットワーク制御を行なう.
LSP の 入 口 Edge Router に は , Flow Entry と し て ,
Match フ ィ ー ル ド に IP 5-tuple (送 信 元 IP ア ド レ ス ,送
信 先 IP ア ド レ ス ,送 信 元 ポ ー ト ,送 信 先 ポ ー ト ,プ ロ
コ ル 種 別 ) を , Action フ ィ ー ル ド に MPLS ラ ベ ル の
Push を 指 定 す る . ま た 出 口 Edge Router に は Match フ
ィ ー ル ド に MPLS ラ ベ ル , Action フ ィ ー ル ド に MPLS
ラ ベ ル の Pop を 指 定 し た Flow Entry を 設 定 す る .こ れ
に よ り ,外 部 か ら の 入 力 パ ケ ッ ト を 適 切 な LSP へ 送 出
し , LSP を 通 過 し て き た パ ケ ッ ト を 再 び 外 部 ネ ッ ト ワ
ークへと戻すことができる.
Core Router は ,Match フ ィ ー ル ド に MPLS ラ ベ ル を
指 定 し ,Action に 特 定 ポ ー ト へ の 送 出 を 指 示 す る Flow
Entry を 設 定 す る . こ れ に よ っ て 指 定 さ れ た LSP に よ
るパケット転送が可能となる.
ま た Controller は , 定 期 的 に Router と 交 信 し , ネ ッ
トワーク全体の輻輳状態やリンク利用率の把握,大容
量フローの検出を行なう.
図 2. ネ ッ ト ワ ー ク ア ー キ テ ク チ ャ
2.3. Relay Node ア ル ゴ リ ズ ム
迂 回 経 路 の 探 索 に は Relay Node ア ル ゴ リ ズ ム を 用 い
る . こ れ は デ ー タ の 転 送 元 で あ る Source Node と 転 送
先 の Destination Node の ペ ア (SD Node ペ ア )に 対 し て 迂
回 経 路 の 経 由 ノ ー ド と な る Relay Node を 決 定 す る ア ル
ゴリズムである.
オ リ ジ ナ ル の Relay Node ア ル ゴ リ ズ ム で は ,一 つ の
SD Node ペ ア に 対 し て 複 数 の Relay Node を 設 定 し ,ト
ラヒックを最短経路と複数の迂回経路に均等分散させ
ることで迂回制御を行ったが,本方式では制御負荷を
軽減させるために迂回経路は 1 本とし,大容量フロー
のみを迂回制御の対象とする.
Relay Node に は ,式 (1)の コ ス ト を 最 小 化 す る ノ ー ド
を選択する.
こ こ に , i, j, k は ノ ー ド 番 号 , Umax(i, j, k)は ノ ー ド
k を Relay Node と し て ノ ー ド i か ら ノ ー ド j に 至 る 経
路 の 最 大 リ ン ク 利 用 率 で あ り ,Ohop(i, j, k)は 迂 回 経 路
の ホ ッ プ 数 , Phop(i, j)は 最 短 経 路 の ホ ッ プ 数 を 示 す .
α ,β は リ ン ク 利 用 率 と ホ ッ プ 数 に 対 す る 重 み で あ り ,
αを大きくするとリンク利用率が均等化され,βを大
きくすると最短経路から離れた迂回経路が抑圧される.
SD Node ペ ア に 対 し て , こ の コ ス ト 式 を 適 用 し コ ス
ト が 最 小 と な る ノ ー ド k を Relay Node と し て 選 択 し ,
迂回経路を決定する.
2.4. OpenFlow に よ る 迂 回 経 路 制 御 の 実 装 方 式
本 節 で は OpenFlow を 利 用 し た 迂 回 経 路 制 御 の 実 装
方式について述べる.
2.4.1. ネ ッ ト ワ ー ク 情 報 の 収 集
Controller は 以 下 の 手 順 に よ り 5 秒 間 隔 で Router か
らネットワーク状態を収集し,この情報を元にネット
ワーク全体の状態を把握する.
1. Controller か ら Router に 対 し て ネ ッ ト ワ ー ク 状 態 の
リクエストを送信する.
2. リ ク エ ス ト を 受 信 し た Router は 応 答 と し て ネ ッ ト
ワ ー ク 状 態 を Controller へ 送 信 す る . 送 信 す る 状 態
は指定フローにマッチしたパケット数及びバイト
数 と ,Router の 各 ポ ー ト で の 送 受 信 パ ケ ッ ト 数 ,送
受信バイト数,損失パケット数である.
3. ネ ッ ト ワ ー ク 状 態 を 受 け 取 っ た Controller は , こ の
情報をもとにリンク利用率やパケット損失率の計
算を行う.
Controller は 5 秒 を 経 過 し て も 応 答 が な い 場 合 は ,次
の リ ク エ ス ト を 送 信 せ ず ,10 秒 を 経 過 し て も 応 答 が な
い場合は再リクエストを送信する.正常に応答があっ
た 場 合 で も ,Controller が 把 握 す る ネ ッ ト ワ ー ク 状 態 は
実際の 5 秒前の状態となる.
2.4.2.
迂回制御の実行
リ ン ク 利 用 率 が 設 定 し た 閾 値 を 超 え る と ,Controller
は該当リンクを輻輳状態と判定し,このリンクを通過
し て い る 各 フ ロ ー に 対 し て Relay Node ア ル ゴ リ ズ ム を
適用し,迂回経路を選択する.全てのフローに対して
迂 回 制 御 を 行 う と Controller へ の 負 荷 が 大 き く な っ て
しまうことや,すぐに転送終了してしまう小容量フロ
ーは迂回の有効性が小さいことから,転送量が一定量
を超えた大容量フローのみを迂回制御の対象とした.
迂 回 経 路 が 選 択 さ れ た 後 , Controller は 経 路 上 の
Router に 対 し て , 該 当 フ ロ ー を 迂 回 経 路 に 流 す た め ル
ールを送信し,迂回経路の設定を行う.具体的には以
下のような流れで行なう.
1. 迂 回 経 路 上 の Core Router に 対 し て , 新 た に 設 定 し
た LSP の ラ ベ ル で マ ッ チ ン グ し ,次 の ル ー タ へ パ ケ
ッ ト を 転 送 す る Flow Entry を 送 信 し , 迂 回 経 路 の
LSP を 構 築 す る .
2. 出 口 Edge Router に 対 し て 迂 回 経 路 LSP を 通 っ て き
た パ ケ ッ ト の Pop 処 理 を 行 な う た め の Flow Entry を
送信する.
3. 入 口 Edge Router に 対 し て , 対 象 フ ロ ー の IP-5tuple
を Match フ ィ ー ル ド ,迂 回 経 路 LSP へ パ ケ ッ ト を 流
す た め の ラ ベ ル の Push を Action フ ィ ー ル ド に 設 定
し た Flow Entry を 設 定 し ,迂 回 経 路 に パ ケ ッ ト を 流
すことができるようにする.
1.と 2.の 時 点 で は 迂 回 対 象 の フ ロ ー は 迂 回 経 路 で
は な く 最 短 経 路 の LSP を 流 れ て い る .そ し て 3.の 処 理
が 完 了 し た 時 点 で ,フ ロ ー は 迂 回 経 路 の LSP へ と 流 れ
始める.このような手順で処理を行うことで,フロー
の転送を中断したり,パケット損失が発生したりする
ことがなくパス切り替えを行なうことができる.
フ ロ ー の 2 種 類 と し た . TCP フ ロ ー は フ ァ イ ル 容 量 ,
UDP フ ロ ー は ス ト リ ー ミ ン グ 帯 域 と 持 続 時 間 を パ ラ
メ ー タ と し て 持 つ .今 回 の 評 価 で は TCP フ ロ ー の フ ァ
イ ル 容 量 は 500 kByte,1 Mbyte,5 Mbyte,10 Mbyte の
4 種 類 ,UDP フ ロ ー の 持 続 時 間 は 30 秒 ,60 秒 ,90 秒 ,
120 秒 , 150 秒 の 5 種 類 と し た . ま た UDP フ ロ ー の ス
トリーミング帯域は評価実験に応じて変更した.
フ ロ ー 生 成 は Source Node か ら Destination Node に 対
し て 10 秒 間 隔 で 行 っ た .生 成 す る フ ロ ー は ま ず 始 め に
TCP,UDP の い ず れ か を 一 様 乱 数 で 決 定 し ,そ の 後 TCP
で あ れ ば フ ァ イ ル 容 量 ,UDP で あ れ ば 持 続 時 間 の パ ラ
メータ値を一様乱数によって選択した.
3.3. 評 価 手 法
提 案 方 式 の 評 価 実 験 は Mininet を 利 用 し た エ ミ ュ レ
ー タ に よ っ て 行 っ た . 図 3 で 示 し た COST239 ト ポ ロ
ジ ー の 各 ノ ー ド を OpenFlow ス イ ッ チ と し , ス イ ッ チ
間 の リ ン ク 帯 域 を 10Mbps に 設 定 し た .
性能評価項目として,ネットワーク全体のリンク利
用率,パケット損失率を計測した.さらに,フローご
と の 評 価 と し て は UDP フ ロ ー で は ス ル ー プ ッ ト と ジ
ッ タ ー , TCP フ ロ ー で は 転 送 時 間 を 計 測 し た .
また提案方式の実現可能性の評価として,収集した
ネットワーク状態の正確性,迂回制御の制御遅れを調
査 し た . ネ ッ ト ワ ー ク 状 態 の 正 確 性 は Controller が
Switch か ら 収 集 し た ネ ッ ト ワ ー ク 状 態 と ,ネ ッ ト ワ ー
クインタフェースから収集した状態を比較し,ネット
ワークインタフェースから収集した状態に近いほど正
確であるとした.
4. 性 能 評 価
性 能 評 価 は ,TCP 負 荷 時 , UDP 負 荷 時 ,TCP+ UDP
負荷時について.迂回制御有り・無しの場合の特性比
較 を 行 っ た . な お , フ ロ ー 生 成 は 1000 秒 間 行 っ た .
評 価 実 験 で は ノ ー ド 1, 2 か ら ノ ー ド 8, 9, 10, 11
に 対 し て フ ロ ー を 生 成 し 性 能 評 価 を 行 っ た .図 4,図 5
に ノ ー ド 1,2 か ら の 最 短 経 路 を 示 す .2-8 リ ン ク は 多
くのフローが通るボトルネックリンクとなっている.
3. 評 価 モ デ ル
3.1. ネ ッ ト ワ ー ク モ デ ル
評 価 に は 欧 州 都 市 間 ネ ッ ト ワ ー ク で あ る COST239
ト ポ ロ ジ ー (図 3)を 使 用 し , ノ ー ド 間 距 離 は 全 て 1 と
した.
図 4. ノ ー ド 1 か ら ノ ー ド 8,9,10,11 へ の 最 短 経 路
図 3. Cost239 ト ポ ロ ジ ー
図 5. ノ ー ド 2 か ら ノ ー ド 8,9,10,11 へ の 最 短 経 路
3.2. ト ラ ヒ ッ ク モ デ ル
評価実験で発生させるフローはファイル転送を想
定 し た TCP フ ロ ー と ,ス ト リ ー ミ ン グ を 想 定 し た UDP
4.1. TCP 負 荷 時
発 着 ノ ー ド 間 に TCP フ ロ ー を 生 成 し て 評 価 を 行 っ
た . 式 (1)の 重 み は α =1, β =0.01 と し た .
表 1 に 迂 回 制 御 有 り・無 し に お け る フ ァ イ ル 容 量 毎
のフロー転送時間を示す.またボトルネックリンクの
2-8 リ ン ク で の パ ケ ッ ト 損 失 率 を 図 6 に 示 す .
迂回制御無しでは,最大転送時間・平均転送時間が
非 常 に 長 く な っ て い る . ま た 2-8 リ ン ク で は 常 に パ ケ
ット損失が起きており,再送や輻輳制御が発生して転
送が進まないため,転送時間が大きく伸張していると
考えられる.
対して迂回制御有りの場合は,フローの最大転送時
間が大幅に短縮され,平均転送時間も短縮できた.ま
た 2-8 リ ン ク で の パ ケ ッ ト 損 失 も 減 少 し , 発 生 後 す ぐ
にパケット損失が抑えられている.これはパケット損
失 後 , 迂 回 制 御 が 行 わ れ 2-8 リ ン ク を 通 る 経 路 か ら 別
の経路にフローを移したためである.
表 1 TCP 負 荷 時 の フ ロ ー 転 送 時 間
ファイル
容量
500K
1M
5M
10M
迂回制御無し
最大
最小
平均
256.8
0.4
71.112
469.6
0.9 164.515
1371.1
4.5 561.045
1884.0
9.1 976.942
迂回制御有り
最大
最小
平均
17.4
0.4
4.772
23.6
0.9
7.059
37.7
4.5 14.983
45.5
9.1 21.353
図 8. 40 秒 時 点 で 選 択 さ れ た 迂 回 経 路
4.2. UDP 負 荷 時
こ の 実 験 で は 発 着 ノ ー ド 間 に UDP フ ロ ー を 生 成 し
た . UDP フ ロ ー の ス ト リ ー ミ ン グ 帯 域 は 200kbps, 式
(1)で の 重 み は α =1, β =0.01 と し た .
表 2 に UDP フ ロ ー 負 荷 時 の 迂 回 制 御 有 り ・ 無 し に
おけるスループット,ジッターの計測結果を示す.ま
た 図 9 に ボ ト ル ネ ッ ク リ ン ク で あ る 2-8 リ ン ク の 迂 回
制 御 有 り・無 し に お け る リ ン ク 利 用 率 の 変 動 を ,図 10
にパケット損失率変動を示す.
表 2 UDP 負 荷 時 の 計 測 結 果
迂回制御無し
迂回制御有り
スループット (kbps)
最大
最小
平均
201.0
60.9 182.9
200.0 200.0 200.0
ジッター (ms)
最大
最小
平均
48.1
0.04
2.38
3.5
0.04
0.34
図 6. 2-8 リ ン ク で の パ ケ ッ ト 損 失 率 (TCP 負 荷 時 )
迂 回 制 御 の 様 子 を 見 る た め , 実 行 時 間 20 秒 か ら 100
秒 ま で の リ ン ク 利 用 率 の 変 動 を 図 7 に 示 す .40 秒 時 点
で 2-8 リ ン ク に お い て リ ン ク 利 用 率 が 輻 輳 閾 値 で あ る
80%に 達 し , 大 容 量 フ ロ ー に 対 し て 迂 回 経 路 制 御 が 行
わ れ る .図 8 に 制 御 に よ っ て 選 択 さ れ た 迂 回 経 路 を 示
す . 2-8 リ ン ク を 通 っ て い た 大 容 量 フ ロ ー は リ ン ク 利
用 率 が 0%の 2-3 リ ン ク や 2-5 リ ン ク を 通 る 迂 回 経 路 が
選 択 さ れ , そ の 結 果 45 秒 か ら 50 秒 に か け て , こ れ ら
のリンクのリンク利用率が増加している.迂回が行わ
れた大容量フローは空いている迂回経路の帯域を利用
し,高スループットでフローを転送することが可能と
なるため,フロー転送時間の短縮につながっている.
迂 回 制 御 が 行 わ れ た 後 も 2-8 リ ン ク の リ ン ク 利 用 率 が
下がらない理由は,大容量フローの迂回によって利用
可能帯域が広がり,迂回が行われなかった転送量が
1MByte 以 下 の フ ロ ー の ス ル ー プ ッ ト が 上 が っ た た め
である.
図 9. 2-8 リ ン ク の リ ン ク 利 用 率 変 動 (UDP 負 荷 時 )
図 10. 2-8 リ ン ク の パ ケ ッ ト 損 失 率 変 動 (UDP 負 荷 時 )
図 7. 迂 回 制 御 に よ る リ ン ク 利 用 率 変 動 (TCP 負 荷 時 )
フローの計測結果より,迂回制御を行うことで,全
てのフローが転送ビットレートと同じスループットで
受信することができるようになり,最大ジッターに関
し て も 大 幅 に 短 縮 す る こ と が で き た (表 2). ま た 迂 回
制御無しにおいてボトルネックリンクのパケット損失
率 は 非 常 に 高 く , 25%を 超 え る こ と も あ っ た . こ れ に
対して,迂回制御有りではパケット損失がなくなり,
すべてのフローを損失無しで転送することが可能とな
っ た (図 10).
リ ン ク 利 用 率 変 動 (図 9)を 見 る と , 迂 回 制 御 無 し で
は 常 に ボ ト ル ネ ッ ク リ ン ク の リ ン ク 利 用 率 が 100%近
くになっているのに対し,迂回制御有りでは輻輳閾値
で あ る 80%を 超 え る と , 迂 回 制 御 が 行 わ れ , リ ン ク 利
用率が下がっていることがわかる.
迂回制御が行われる様子を詳しく見るため,実行時
間 30 秒 か ら 180 秒 間 の リ ン ク 利 用 率 の 変 動 を 図 11 に
示 す . ま た , 2-8 リ ン ク に お い て 輻 輳 閾 値 80%を 最 初
に 越 え る 80 秒 時 点 の 迂 回 制 御 に よ っ て 選 択 さ れ る 迂
回 経 路 を 図 12,図 13 に 示 す .80 秒 時 点 で 2-8 リ ン ク
を 通 る 大 容 量 フ ロ ー は 19 本 あ り ,迂 回 制 御 に よ っ て こ
れら全てのフローが迂回経路へと経路変更が行われた.
こ の 制 御 に よ っ て 2-8 リ ン ク を 通 っ て い た フ ロ ー は
1-3, 2-3, 2-5 リ ン ク を 通 る 経 路 へ と 変 更 さ れ る . そ
の た め 80 秒 か ら 85 秒 に か け て , 2-8 リ ン ク の リ ン ク
利用率が下がり,迂回経路として通過するリンクのリ
ン ク 利 用 率 が 上 昇 し て い る こ と が わ か る . 同 様 に 115
秒 時 点 で も 輻 輳 閾 値 80%を 越 え ,迂 回 制 御 に よ っ て リ
ンク利用率が変動している様子がわかる.
プ ッ ト と も に 改 善 し ,ジ ッ タ ー も 短 く な っ て い る .TCP
フローについてもどのファイル容量でも,最大転送時
間・平均転送時間ともに短縮することができ,迂回制
御の有効性を示すことができた.またパケット損失率
の変動についても,迂回制御無しでは最大パケット損
失 率 が 45%程 度 と な っ て い る の に 対 し て 迂 回 制 御 有 り
ではほぼパケット損失が発生していないことがわかる.
しかしコスト式の重みβによる影響はそれほど大きく
な く ,UDP フ ロ ー の 迂 回 ホ ッ プ 数 を 制 限 す る こ と に よ
る性能向上は見られなかった.
表 3 TCP・ UDP 負 荷 時 の UDP フ ロ ー 計 測 結 果
迂回制御無し
迂回制御有り
(UDPβ=0.05)
迂回制御有り
(UDPβ=0.01)
迂回制御有り
(UDPβ=0.1)
スループット (kbps)
最大
最小
平均
508
141 393.8
ジッター (ms)
最大
最小
平均
63.777 0.062 6.403
509
486
500.0
9.771
0.041
0.888
510
487
500.7
11.554
0.039
0.988
509
486
500.1
10.512
0.049
0.887
表 4 TCP・UDP 負 荷 時 の TCP フ ロ ー の 最 大 転 送 時 間
図 11. 迂 回 制 御 に お け る リ ン ク 利 用 率 の 変 動
(UDP 負 荷 時 )
図 12. ノ ー ド 1 か ら の 迂 回 経 路
図 14. TCP・ UDP 負 荷 時 の 2-8 リ ン ク に お け る
パケット損失率変動
5. 実 現 可 能 性 の 評 価
本章では提案方式の実ネットワークにおける実現
可能性の評価について述べる.
図 13. ノ ー ド 2 か ら の 迂 回 経 路
4.3. TCP・ UDP 負 荷 時
こ の 実 験 で は 発 着 ノ ー ド 間 に TCP フ ロ ー と UDP フ
ロ ー を 同 時 に 生 成 し た .UDP フ ロ ー の ス ト リ ー ミ ン グ
帯 域 は 500 kbps と し た . ま た TCP フ ロ ー と UDP フ ロ
ー を 差 別 化 す る た め に , 式 (1)の α ,β を TCP の 場 合 と
UDP の 場 合 で 変 更 し ,コ ス ト 式 の 重 み の 影 響 を 評 価 し
た . 評 価 し た パ ラ メ ー タ は TCP の 重 み α =1, β =0.01,
UDP の 重 み α =1 を 固 定 と し , UDP の 重 み β を 0.01,
0.05, 0.1 の 三 種 類 と し て 評 価 し た . 表 3 に UDP フ ロ
ー の 計 測 結 果 を ,表 4 に TCP フ ロ ー の 最 大 転 送 時 間 ,
平 均 転 送 時 間 を 示 す . ま た 図 14 に ボ ト ル ネ ッ ク リ ン
ク で あ る 2-8 リ ン ク の パ ケ ッ ト 損 失 率 変 動 を 示 す . 迂
回制御無しの場合と迂回制御有りの場合を比較すると,
UDP フ ロ ー に つ い て は 最 小 ス ル ー プ ッ ト ,平 均 ス ル ー
5.1. ネ ッ ト ワ ー ク 状 態 の 収 集
迂回制御に利用するネットワーク全体の状態把握
は Controller が Switch か ら 収 集 し た ネ ッ ト ワ ー ク 状 態
を計算することで行われる.本節ではこのネットワー
ク状態が遅滞なく正確に計測できているかネットワー
クインタフェースから直接計測した情報と比較するこ
と で 検 証 す る . こ こ で Controller に よ る ネ ッ ト ワ ー ク
状態の収集は 5 秒間隔で行い,ネットワークインタフ
ェースによる計測は 1 秒間隔で行った.
図 15 に UDP 負 荷 時 の 迂 回 制 御 有 り で の ,Controller
とネットワークインタフェースによって計測された
2-8 リ ン ク の リ ン ク 利 用 率 を 示 す . 比 較 す る と ,
Controller の 計 測 結 果 は 5 秒 間 隔 で の リ ン ク 利 用 率 と
なるため直線的に増加しているが,ネットワークイン
タフェースでの計測結果は 1 秒間隔のためフローが生
成されてリンク利用率が上がるような段階的な変化が
見られる.そのためリンク利用率の細かい変動は
Controller で は 観 測 で き て い な い こ と が わ か る .し か し
輻 輳 閾 値 の 判 定 条 件 で あ る 80%を 越 え る 点 を 見 る と ネ
ッ ト ワ ー ク イ ン タ フ ェ ー ス に よ る 計 測 で 80%を 越 え て
か ら 10 秒 以 内 に は Controller で も 輻 輳 の 検 出 が 行 わ れ ,
その後のリンク利用率の低下が確認できる.そのため
Controller で の ネ ッ ト ワ ー ク 状 態 の 収 集 は ,迂 回 制 御 に
十分な精度で行われていると考えられる.
図 16 リ ン ク 利 用 率 計 測 結 果 の 比 較 (70 秒 -170 秒 )
6. 結 論
図 15 リ ン ク 利 用 率 計 測 結 果 の 比 較
5.2. 迂 回 制 御 の 制 御 遅 れ に つ い て の 評 価
提案方式において迂回制御は,リンクの輻輳状態を
把握した後に,そのリンクを流れるフローごとに迂回
経 路 を 計 算 し ,経 路 上 の Router に Flow Entry を 送 信 し
て LSP を 構 築 す る こ と で 行 わ れ る . Controller で の リ
ンク利用率の把握は実際の 5 秒後であるため,輻輳リ
ンクの検知も 5 秒後となる.そのため実際に輻輳して
から,迂回制御が行われて輻輳状態が回避できるまで
に制御遅れが発生する可能性がある.本節ではこの制
御 遅 れ に つ い て 節 5.1 で の 制 御 実 行 時 の 挙 動 か ら 評 価
する.
図 16 に 節 5.1 で の 実 験 の 70 秒 か ら 170 秒 ま で の リ
ン ク 利 用 率 の 比 較 を 示 す . 図 16 に お い て ① は ネ ッ ト
ワークインタフェースの計測によりリンク利用率が
80%を 超 え た 点 , ② は Controller の 計 測 で リ ン ク 利 用
率 が 80%を 超 え た 点 , つ ま り Controller が 輻 輳 リ ン ク
を検出した時点である.また③はネットワークインタ
フェースの計測でリンク利用率の低下が見られた点で
あり,迂回制御が実行された点である.
1 回 目 の 迂 回 制 御 (90 秒 か ら 120 秒 あ た り )で は , 97
秒 時 点 で 実 際 の リ ン ク 利 用 率 は 80%を 超 え る .そ の 後
105 秒 時 点 で 2-8 リ ン ク が 輻 輳 し て い る こ と が 検 出 さ
れ , 迂 回 制 御 を 行 な わ れ る . そ の 結 果 108 秒 時 点 で リ
ンク利用率が下がり,迂回制御が行われたことがわか
る . こ の こ と か ら Controller が 輻 輳 を 検 出 し て か ら 迂
回制御が実行されてリンク利用率が下がるまでには 3
秒程度かかっていることがわかる.また,2回目の迂
回 制 御 (140 秒 か ら 170 秒 )で も 輻 輳 検 出 か ら 迂 回 制 御
が実行されるまでには 4 秒程度経過しており,他の迂
回制御においても,輻輳検出から迂回制御が実行され
るまで 5 秒以下であった.
そ の た め 節 5.1 か ら ネ ッ ト ワ ー ク イ ン タ フ ェ ー ス に
よ る 計 測 で 80%を 越 え て か ら 10 秒 以 内 に は Controller
でも輻輳の検出が行われていることから,実際に輻輳
状 態 と な っ て か ら 迂 回 制 御 が 行 わ れ る ま で 15 秒 以 内
であることがわかる.
Cost239 ト ポ ロ ジ ー に お い て TCP フ ロ ー と UDP フ ロ
ーを発生させた結果,提案方式の適用によるパケット
損失率の低下やフローのスループット向上,転送時間
の 短 縮 を 確 認 す る こ と が で き た . Relay Node ア ル ゴ リ
ズムによる迂回制御方式は有効に機能し,輻輳リンク
の負荷を効率よく分散できると言える.
さ ら に Controller で 計 測 し た ネ ッ ト ワ ー ク 状 態 と ,
マシンのネットワークインタフェースから直接取得し
た ネ ッ ト ワ ー ク 状 態 の 比 較 か ら ,Controller で の 計 測 結
果の正確性を確認した.このことから提案アーキテク
チャの実網における実現可能性を示せた.
今 後 の 課 題 と し て , TCP/UDP 混 在 時 に お け る QoS
制 御 と 迂 回 制 御 の 同 時 利 用 特 性 の 解 析 や ,OpenFlow で
大容量フローのみを迂回制御の対象とすることの是非
が挙げられる.また,より大規模網,大規模トラヒッ
クでの実験も課題である.
文
献
[1] M. Nick, et. al., “OpenFlow: enabling innovation in
campus networks”, A C M S I G C O M M C o m p . Com. Rev.,
V o l .3 8 , No.2 , p p 6 9 - 7 4 , 2 0 0 8 .
[2]
Y. Yoshida, M. Kawarasaki, “Relay Node Based Proactive
Load Balancing Method in MPLS Network with Service
Differentiation”, I E E E U - N e t ’ 1 2 , p p 7 0 5 0 - 7 0 5 4 , 2 0 1 2 .
[3]
A. R. Curtis, et al., “DevoFlow: Scaling Flow Management
for High-Performance Networks”, S I G C O M M
'11
pp254-265, 2011.
[4]
A. Tootoonchian, Y. Ganjali, “H y p e r F l o w : a d i s t r i b u t e d
c o n t r o l p l a n e f o r O p e n F l o w ” , INM/WREN'10, 2010.
[5]
M. Casado, et al., “Fabric: A Retrospective on Evolving
SDN”, H o t S D N , pp85-90, 2012.
[6]
S. Das, et al., “MPLS with a Simple OPEN Control Plane”,
OFC/NFOEC, 2011.
[7]
Mininet. http://mininet.org/