Embed Size (px)
Citation preview
論 文
Service Controlled NetworkingのためのOpenFlow動的構成方法
木全 崇† 豊村 鉄男† 金 京淑† 是津 耕司†
Dynamic Configuration of Network Flow based on Service-Controlled Networking
Takashi KIMATA†, Tetsuo TOYOMURA†, Kyoung-Sook KIM†, and Koji ZETTSU†
あらまし 新世代ネットワークは，ネットワークの高い処理能力と拡張性を活かして，膨大な分散データを処理したり，多種多様な情報サービスを組み合わせて効率的に実行することを求められている．この目的のために,
我々は，Service-Controlled Networking を提案している．Service-Controlled Networking は，サービスからネットワークに対する要求を宣言的ルール言語で抽象的に記述し，ネットワークサービスの開発を容易にするService-Level Overlay と通信を処理するノードの選定や QoS のコントロールなどのサービスからの要求を物理ネットワークに反映させる Network Control Protocol Stack で構成される．本稿では，Service-Controlled
Networkingの要素技術の内，Network Control Protocol Stackに特に焦点を当てて説明すると共に，OpenFlow
を拡張して実装したプロトタイプシステムについて記述する．
キーワード OpenFlow, Service-Controlled Networking, 新世代ネットワーク,
1. は じ め に
現在のネットワークは自身に流れる通信トラフィッ
クを意識し，どのような情報サービスが接続されても
その基本的な構成を用いて対応してきた。しかし，情
報サービスが新たにサービスを動作させるノードを追
加するなどして，通信トラフィックが多種多様に複雑
化すると，これまでの様な土管としてのネットワーク
では非効率的であるといえる．また，現在のインター
ネットでは，情報サービスやデータ (例えば，音楽デー
タや写真など)がネットワーク上のどのノード上に保
存されているかあらかじめ認識している必要がある．
新世代のネットワークは，情報サービスの要求を的確
かつ適時にネットワークが解釈して，ネットワーク構
成や通信処理を動的に調整し，サービス間のメッセー
ジ交換パターンの特徴に合わせて通信方法を動的に変
化させるたり，情報サービスや必要なデータがどこに
存在していても，ユーザーが素早く，正確ににアクセ
スできるよう情報サービスとより密接に連携し，情報
†独立行政法人情報通信研究機構 ユニバーサルコミュニケーション研究所National Institute of Information and Communications
Technology, 3-5 Hikaridai, Seika-Cho, Souraku-Gun, Kyoto,
619-0289, Kyoto
サービスを用いたコミュニケーションを効率化するた
めの機能を持ったネットワークへと進化することが求
められている [1]。
そのため，我々は，新世代のネットワーク・アーキ
テクチャとして，情報サービスがネットワークと協力
して効率的なネットワーキングを可能にする Service-
Controlled Networking を提案している [2]．
Service-Controlled Networking は，情報サービス
自身が構築するサービスレベルのリンクを抽象的，か
つ宣言的に記述することによって，ネットワークサー
ビスを容易に開発することを可能にする Service-Level
Overlay と Service-Level Overlay が記述した内容を
インタープリットし，通信の処理方法や実際に通信を
処理するノードの選定，QoS のコントロールなどを
物理ネットワークとネゴシエーションし、物理ネット
ワークにサービスからの要求を反映させる Network
Control Protocol Stackの２層からなる．この２層の
レイヤーは，お互いが連携することで，高いユーザビ
リティと可用性，パフォーマンスをユーザーに提供す
ると共に，災害時などの突発的に想定を超えたトラ
フィックが爆発的に流れるような状況において，可能
な限り素早く，通信経路を流れるトラフィックにサー
ビス毎の新たな QoS ポリシーを適用するなど，サー
ビス毎の通信トラフィックを動的に制御する機能を提
第二回 NetSci 研究会 X Vol. Jxx–X No. xx pp. 1–9 c⃝（社）電子情報通信学会 xxxx 1
第二回 NetSci 研究会 xxxx/xx Vol. Jxx–X No. xx
供する．
本論文では，Service-Controlled Netwoking の２層
の内，Network Control Protocol Stack に焦点を当
て，2.節で Service Controlled Netwoking の基本概
念を説明し，3. 節 Network Control Protocol Stack
のプロトタイプ実装，4.節でアプリケーションを使っ
た実証実験の内容を記載し，5.節で，考察と今後の課
題を述べ，本論文のまとめとする．
2. Service-Controlled Networking
Service-Controlled networking という概念は，情
報サービスの観点から見たネットワーク (オーバーレ
イ・ネットワーク)と実際に通信を処理するネットワー
ク (物理ネットワーク)の間にあるギャップを埋めると
いう発想からスタートしている．例えば，Skype や
YouTubeを使って被災地の状況を伝える防災情報サー
ビスを考えると，情報サービスが構成する論理ネット
ワークは，被災地から情報をアップロードする人や機
器などのノード（発信ノード集合），アップロードさ
れた情報を収集し，整理するサーバノード（収集ノー
ド集合），集められた情報を引き出したり閲覧する人
や機器のノード（閲覧ノード集合）で構成される．ま
た、発信ノードと収集ノードの間は，できる限りリア
ルタイムに，かつ正確に情報を伝えるリンクで構成さ
れる一方，収集ノードと閲覧ノードの間は，大量の情
報を効率よくやり取りできるリンクで構成されるな
ど，情報サービスが構成する論理ネットワークは，情
報サービスの要求を強く反映して構成されているが、
実際に通信データが流れる物理ネットワークの構成は，
必ずしもそういった情報サービスの都合を反映して
物理ネットワークを構成しているとはいえない。そこ
で，Service-Controlled Networking では，情報サー
ビスの要求や論理ネットワークの構造をネットワーク
に通知することで，情報サービスから通知された情報
に応じて物理ネットワークの構成を動的に調整する．
また、ネットワーク上に存在する通信相手 (サービス
を提供しているノード)の検索サービスを情報サービ
スに提供することで，ネットワーク上に存在する情報
サービスを柔軟に使うことができる．図 1に Service
Controlled Network のコンセプトデザインを記載し，
Service Controlled Network が提供する機能を以下に
記述する．
（ 1） 様々な情報の収集やデータの蓄積を協調して
行う連携ネットワークをオンデマンドに構成する．
図 1 Concept of Service Controlled Netwoking
（ 2） 情報サービス（ノード）間にアドホック，か
つ高効率な通信を設定する．
（ 3） 情報サービスの種類や利用環境に応じて通信
を論理的に分割可能にする．
例えば，災害時にユーザーは，緊急用のコミュニ
ケーションツールとして Skype のような情報サービ
スを見つけ出し，それらとオンデマンドに非常用通信
サービスを構築したいとする．この場合，ユーザーは
コミュニケーションサービス（この場合は Skype）と
言う抽象的な情報サービスの検索をネットワークに依
頼する．ネットワークは情報サービスからの要求に対
して，目的に一致する情報サービスを探し出し，発見
された情報サービスとの間で論理的に隔離された通信
パスを構築する．さらに，この通信パスに設定された
優先度に従い，ネットワーク処理を行う．
2. 1 Service-Level Overlay
Service-level overlayは，情報サービス側から見た
ネットワークを表している．情報サービスの定義に基
づく論理的なネットワークを情報サービス毎に構成す
る．このような論理的なネットワーク（Overlay）は，
以下の要素から構成される：
（ 1） サービス：情報サービスの中で情報をやり取
りする主体 (entity)を示す．
（ 2） メッセージ：情報サービス間でやり取りされ
る情報そのものを示す．単なるデータから，コマンド・
応答など，情報サービスを実行するのに必要なありと
2
論文／Service Controlled Networking のための OpenFlow 動的構成方法
あらゆる情報が対象となる．
Service-Level Overlayでは，情報サービスから届く
様々な要求を Declarative Networking [5]などのルー
ルベース言語で記述する．上述の例で例えると，情報
サービスから「コミュニケーションサービス」を構成す
るために必要な処理をサービスへの検索要求といった
抽象的なルールとして定義しておく．このルールを必
要に応じて，後に記述するNetwork Control Protocol
Stackを用いてネットワーク側に依頼する．また，検
索結果 (通信相手となる情報サービスの IP Addressや
Application IDなど)に基づいて専用のオーバーレイ
を構築し，同じオーバーレイに属する情報サービスの
生存確認，状態確認，データ転送方式，メッセージパ
ターンなど，情報サービスを連携させる上で必要な状
態の維持や管理を行う．
2. 2 Network Control Protocol Stack
Network Control Protocol Stack(以下，NCPS)は，
Service-Level Overlay で定義されたサービス同士の
繋がりを示す論理ネットワークを，物理ネットワーク
上に反映，展開するための役割を担う．NCPSが提供
する機能を以下に記す．
（ 1） 情報サービスを提供しているノードの位置情
報の特定: Overlay を構築するために必要な情報 (情
報サービスを提供しているノードの IPアドレスや情
報サービスのKeyなど)を，ネットワークから発見し，
それらの情報を Service-Level Overlayに通知する
（ 2） 通信パスの設定: Service-Level Overlayから
通知されるサービス同士のリンク定義と，サービス
特定処理の結果に基づいて，物理ネットワーク上の通
信パスを構成し，サービス間の通信トラフィック毎に
QoSパラメーターを動的に設定する
（ 3） 状態監視:ノードや転送パスの状態を監視し，
必要に応じて通信パスの再構成を行う．
災害などでは，本来潤沢なはずのネットワークリ
ソースが極端に限定され，一部の区間に想定を超えた
通信が突発的に行われる可能性がある．このような状
況下では，被災した現地との音声サービスや動画サー
ビスなどから発生する通信トラフィックと娯楽サービ
スから発生する通信トラフィックを比較し，前者を優
先的に処理するなど，社会的な重要性の変化によって
瞬時にルーティングやQoSポリシーをサービスレベル
で再定義し，物理ネットワークに反映する機能が必要
となる．しかし，従来のネットワークでは，情報サー
ビスが動作するノードへの宛先情報を便りに，通信
パケットを機械的にバケツリレーしていくため、上記
の様な粒度の細かいトラフィックコントロールを要求
されるような場面に対応するのは難しい．このため，
NCPSでは，サービス毎に異なる識別子を設定し物理
ネットワークに登録する．ネットワークは情報サービ
スが通知した IPアドレスと Port番号に加えて，情報
サービスごとに割り当てる識別子の三種類を用いて，
様々な通信パケットによるトラフィックの中から特定
の情報サービスによる通信を識別し対応する．
3. プロトタイプシステム
この節では，Service-Controlled Networking のプ
ロトタイプシステムについて述べる．
本システムは，情報サービスからネットワークへ
サービスからの要求を通知する機構 (Message Send
Architecture)を Declarative Netwokingの JAVA言
語実装である「JOL」を拡張して構築したミドルウェ
アに実装し，ミドルウェアからの要求を受け取り，
ネットワークにそれらの要求を反映させるための制御
機構 (Message Receive Architecture) を OpenFlow
Switch [3]とOpenFlow Controllerを作成するための
フレームワーク NOX [4]を拡張することで実装した．
本プロトタイプシステムはミドルウェアからの要求
に対して，ネットワーク上に存在する情報サービスに
関する情報 (例えば，サービスの名前やサービスを簡
潔に説明したキーワードなど)と位置情報 (IPアドレ
ス)を保持するアーカイブサービスとネットワーク機
器が連動して動作する．
以下に，サービス情報の登録，検索，通信パスなどの
処理手続きを記した図 3を用いて我々がOpenFlowと
ミドルウェア上に実装したNetwork Control Protocol
Stackの処理について解説する．なお，本プロトタイ
プシステムは，情報サービスに関する情報を保持する
アーカイブサービスを OpenFlow Controller が兼ね
る．また，本プロトタイプシステムでは，定期的に各
SWの状態 (生死状態)や各 SWを接続しているリン
クの状態 (遅延，帯域)を取得し保持している．
3. 1 プロトタイプシステムの初期動作
各 OpenFlow Switch（以下，SW）は OpenFlow
Controller(以下，Controller) とのリンクが確率され
た時点で，Initial Ruleを自身にロードする (図 3.1)．
Initial Rule をロードした SW は，Initial Rule の定
義に従って自身に接続された各ノードのゲートウェイ
として動作する．
3
第二回 NetSci 研究会 xxxx/xx Vol. Jxx–X No. xx
!"#
$%&&'()*+,(
$(--+.()/(0&)1,23%4(245,(
!/(0&)6788+0&)$(--+.( "/(0&)129)$(--+.(
":(0;'7<)/<%423
#=(4(2>?()6788+0&)$(--+.(
!7&()@%-4 $12>70
%129
$(--+.()A(2(%?()1,23%4(245,(
$(--+.()A(2(%?()1,23%4(245,( $(--+.()/(0&)1,23%4(245,(
":(0;'7<)1,23%4(245,(
":(0;'7<)1,23%4(245,(
%129129
(245,(
245,(
&A5'()B:&+4()$(--+.(
図 2 NCPS Architecture
Node SW Controller
boot boot boot up
initial rule load
Insert Insert
Create Virtual GateWay
Ack
1
2
Search Search
Ack
1:192.168.1.1
2:192.168.2.1
3:192.168.3.1
Node List
matching
3
createPath createPath
Ack 1:Path1 … …
Flow Table Ack
4
hhCreate Flow Table
1:192.168.1.1
2:192.168.2.1
ada
add Node list
Ack
図 3 NCPS Process on OpenFlow
次に，情報サービスはネットワークに接続された際，
Insert Serviceコマンドを用いて表 1に記した内容を
ブロードキャストでネットワークに通知する (図 3.2)．
ブロードキャストを使ったコマンドを受け取った SW
はコマンドが含まれるメッセージを Controllerに転送
する．転送されたコマンドが Controllerに届いた時点
で，Controllerはノード情報が記載されたリストに登
録し，登録処理が完了したことをサービスに最も近い
SWから Ackメッセージで通知する．この処理によっ
て，Controllerは自身が管理するネットワーク上で動
作する情報サービスの存在を把握することができるよ
うになる．
3. 2 Service Discovery
この項目では，本プロトタイプシステムがユーザー
に提供する検索機能について説明する (図 3.3)．
ユーザーはゲートウェイ (最寄りの SW)に Search
Service コマンドを発行する．Search Service コマン
ドを受信した SW は Controller にコマンドを転送す
る．転送されたコマンドを受信した Controllerは，コ
マンドの引数に含まれるキーワードと自身が保持す
る情報を比較し，一致する情報サービスの位置情報を
ユーザーに最も近い SW から Ack メッセージを用い
て通知する．この処理の際，検索キーワードに合致す
るサービスが複数存在した場合，それら全てのノード
の情報を通知する．
3. 3 通信パスの構築
2. 2節で，各情報サービス毎に識別子を割り当てる
と記載したが，本プロトタイプシステムでは，情報
サービス毎に Type Of Service(TOS) の値を識別子
として割当て，Create Pathコマンドを用いてゲート
ウェイ (最寄りの SW) に通知する (図 3.4)．Create
Pathコマンドを受信した SWは，Cotrollerにコマン
ドを転送し，コマンドを受信した Controllerは，通知
された Create Path コマンドに 含まれる送信元と宛
先，TOSの値から通信ルールを作成し，各 SWに通
知する．各 SWにルールを転送し終わった Controller
はユーザーに直近の SWから通信パスの構築が完了し
たことを Ackメッセージで通知する．Ackメッセージ
受信後，ユーザーは Create Pathコマンドで通知した
TOSの値を用いて通信を行う．
この処理以後，ネットワークはあるノード上に存在
する複数の情報サービスによる通信をTOSの値によっ
て識別することができるようになるため，情報サービ
スごとに異なるポリシーを割当てるなどの細やかな制
御を行うことが可能となる．
また，情報サービスのスケールを狙って新規に情報
サービスを立ち上げるような状況も想定される．こ
のような状況で新規に立ち上げられた情報サービス
にはユーザーから期待される明確なニーズが存在す
ると考えられる．そのようなニーズに対応するため，
ユーザーが Overlogなどのルール言語で記述した情報
サービスに期待する動作をミドルウェア上に実装され
た NCPS を用いて，帯域，遅延などのネットワーク
が解釈できる形に変換しネットワークに反映する．例
えば，最低でも 1時間あたり 1Gbyteのデータを取得
させるために立ち上げたクローラサービスなどを考え
4
論文／Service Controlled Networking のための OpenFlow 動的構成方法
リストが保持する情報 意味SrcIP ノードが待ち受けている IP アドレス
SrcPort 待受ポートKey サービスの Key
NameSpace Name of Service-Level Overlay
Class サービスの状態Attribute サービスが参照可能かどうかBehavior サービスが提供するサービス表 1 Controller が保持するサービス情報
る．NCPSは，情報サービスから通知された要求を実
現するため，この情報サービスの動作に必要な情報を
計算する．この場合，ネットワーク上に処理が完了す
るまでの間，単純にはクローラサービスとデータスト
レージ間で 2.3Mbps の帯域を確保できればよいこと
がわかる．次に，NCPSは，クローラサービスとデー
タストレージ間の全経路の帯域を Conrollerが保持し
ている情報から割り出し，必要な帯域を満たす経路が
存在しない場合，ユーザーにこのことを通知する．必
要な帯域を満たす経路が存在する場合，その経路でク
ローラサービスとデータストレージ間の通信パスを構
築する．また，必要な帯域を満たす経路が複数存在す
る場合は，最も条件の良い経路上に通信パスを構築す
る．通信パスを構築し終えた後は，これまで通り Ack
コマンドで通信パスの構築が完了したことを通知する．
4. 評 価 実 験
この節では，3.節で述べた Service-Controlled Net-
workingのプロトタイプシステムの評価実験について
述べる．
4. 1 実 験 環 境
図 4 にあるように，実験環境には，NCPS を解釈
できるように独自拡張した OpenFlow Switch(以下，
SW) が 4 台と、それらを束ねる 1 台の OpenFlow
Controller(以下，Controller)が存在している．Con-
troller はそれぞれの SW を集中制御すると共に，各
SWの状態 (生死確認，SW間を接続しているリンク
の遅延，使用帯域)をモニタリングしている．各 SW
に接続されている PCは，それぞれ別のネットワーク
セグメントに分割されている．それぞれの PC には、
Network Control Protocol Stack のメッセージを送
受信し，Service-Level Overlayを構築するためのミド
ルウェアがインストールされており，ミドルウェア上
に独立した情報サービス（アプリケーション）が 1つ，
ないしは２つ立ち上がっている．これらの情報サービ
スはお互いに独立しており，自身以外の情報サービス
に関する情報を持っていない．
このような実験環境で，下記内容が正しく適用され
ているか通信実験によって確認する．
（ 1） Overlayを構築し，正常に通信を行えるか
（ 2） 異なるOverlayを構成する別のサービスが同
一ノード上で動作している時であっても，異なるポリ
シーを適用することができるか
（ 3） 情報サービスからの要求をネットワークが解
釈できるように変換し，ネットワークを構成すること
ができるか
4. 1. 1 実 験 1-1
まず始めに、ネットワーク上に存在するサービス群
（表 4 ) からユーザーが記述したルールに従って、必
要なサービスを連携させた 3つのオーバーレイを構築
する．• Overlay1 = 日本語と英語を母国語にするユー
ザーが使用言語の差を意識せずにお互いの母国語で
チャットを行えるように、メッセージを翻訳サービス
によって相手の言語に変換しながらメッセージのやり
とりをすることができる日英翻訳チャット• Overlay2 = ユーザーが youtube からのスト
リーミングデータをリレーノードを経由して受信する
Overlay
• Overlay3 = Twitter の tweet をアーカイブし
ている DBからデータを取得するための Overlay
これらのオーバーレイをサービスとネットワーク
がどの様に連携して構築するのか Overlay1 を例に
説明する．ユーザーはチャット相手と，翻訳サービス
の位置情報を知るために、SearchService コマンドを
Gatewayに送信する．SearchServiceコマンドを受信
したGateway(最寄りの SW)は，SearchServiceコマ
ンドを Controllerに転送する．SearchServiceコマン
ドを受信した Controller は自身が保持するノードと
サービスの情報を記載したファイルと照らし合わせ，
該当するノードとサービスの情報をユーザーに一番近
い SW から SerchServiceAck メッセージで返答する
（該当するノードとサービスが複数存在する場合，リ
スト形式で返答するが，今回の実験では重複する情報
を持つサービスは存在しないため、単一のノードの情
報を返答する）．
サービスは，SerchServiceAckメッセージでチャット
相手と翻訳サービスが動作しているノードの情報（IP
アドレスと Port 番号）を取得すると，自身とチャッ
ト相手と翻訳サービスまでの通信経路を CreatePath
5
第二回 NetSci 研究会 xxxx/xx Vol. Jxx–X No. xx
Overlay1
Overlay2
Overlay3 !"#$%&#'("
)*#'+,%-"+
./#0#$-%-1
)*#'+,%-"+
.2$3&4%*1
!546-"+78 !546-"+)&4-$'
9'"-#:4$3+9-";-"
9'"-#:4$3+)&4-$'
<-&#=
>(?-+8+
@ABCDEFCGHFEEFCI
>(?-+7+
@ABCDECGHFECFCI
J0-$K&(5+
)($'"(&&-"
J0-$K&(5+
9L
)(::M$4N#O($+
A#'*+P
954'N*+E
954'N*+P
Q00&4N#O($R%+
J;-"&#=
)(::M$4N#O($+
A#'*E
(?- 8 >(?- 7954'N*+P954'N*+P
)(::M$4N#O($+
A#'*C
954'
)(::M$4N#O($+
A#'*+S+
954'N* P
>(?-+Q+
@ABCDEFCGHFESFCI+
>(?-+2+
@ABCDEFCGHFEPFCI
>(?-+)+
@ABCDEFCGHFETFCI
954'N*+S 954'N*+C
図 4 実験 1 のトポロジー
コマンドを用いてネットワークへ構築の依頼を行う
（今回の実験では，このオーバーレイを識別するため，
TOSの値を 0に設定した）．CreatePathコマンドを
受信した Switchは，これまでと同様に Controllerに
コマンドを転送し，転送されたコマンドを受信した
Controllerは，CreatePathコマンドで通知されたサー
ビス同士の繋がりと、予め保持する通信を流す経路の
候補から新しい通信の転送ルールを作成する．新しい
ルールを作成後、この新しいルールに関係する SWに
通知する．SWにルールを通知した後，Controllerは
CreatePathAckを SerchServiceコマンドの処理と同
じように直近の SWより通知する．
CreatePathAckメッセージの受信後，このオーバー
レイ専用の通信パスを用いて通信を行うことができる
オーバーレイが正常に通信が行えているについて
順に説明する．まず, Chat User(Japanese)，Trans-
lator 間の通信は，SrcIP が 192.168.23.10,DistIP が
192.168.22.10 を持つパケットで TOS の値が０であ
るパケットと，SrcIP が 192.16 ８ 23.10,DistIP が
192.168.22.10で TOPの値が０のパケットが流れる.
このようなパケットが流れているのは SW1,SW2(表 2
参照)間であることから，Chat,Translator間の通信は
Communication Path４を辿っている（図 4参照）.
同じように，Translator，Chat User(English)間の通
信は SW1，SW3間を辿る Communication Path １
を辿って正常に通信を行っていることがわかる.
4. 1. 2 実 験 1-2
実験 4. 1. 1の内容に加えて，Overlay2を新たに構築
表 2 実験 1 においての各 SW が持つインターフェースを流れるパケットの抜粋
する。Overlay２を構成する手順は実験 4. 1. 1と同様
に，SerchServiceコマンドで通信相手の位置情報を検
索し，自身と相手との通信経路の作成をTOSの値を 4
と設定し，CreatePathコマンドで依頼する．4. 1. 1節
と同じ様に順に見ていく. Streaming Clientと Relay
サービスの通信は，SrcIPが 192.168.23.10,DistIPが
192.168.22.10，かつ TOSの値が４のパケットが発生
する. 表 2 から Streaming Client サービスと Relay
サービス間は SW1,SW3 間を通る Communication
Path 3を使って通信している. また，Relayサービス
と Streaming Server 間の通信は SW1，SW2，SW3
間を通る Communication Path1) で通信を行なって
いることがわかる.
以上のことから Overlay1と Overlay2では，Over-
lay を構成するサービスこそ違うものの，Translator
サービスと Relay サービス，Chat User(English) と
Streaming Server サービスなどのように情報サービ
スが実行されているノードが重複したとしても，IP，
Port，TOSを組み合わせによってOverlay1とOver-
lay2は，異なる通信ポリシーを適用し，通信を行える
ことが確認できる.
4. 2 実 験 2
この節では，NCPSが情報サービスの抽象的な要望
を満たす通信パスを構築していることを確認する実験
を行う．
この環境上では，データを保持しているデータスト
レージサービスとデータストレージサービスからデー
タを取得するクローラサービスが複数存在し，各情報
サービスは，これまでの実験と同様に NCPS が動作
するミドルウェア上で動作している．このような実験
6
論文／Service Controlled Networking のための OpenFlow 動的構成方法
環境に新たにクローラサービス (情報サービス 1)を設
置し，データストレージサービス (データストレージ
サービス 1)から毎分 50Mbyte分のデータを取得する
オーバーレイ (Overlay1) を構築する．設置されたク
ローラサービス 1 は，自身の要望を Overlog などの
ルール言語で記述（この場合，毎分 50Mbyte のデー
タを取得したいという要望をルール化する）し，ミド
ルウェアに通知する．情報サービスからルールを通知
されたミドルウェアは，SerchServiceコマンドで通信
相手 (データストレージサービス 1) の位置情報を取
得する．NCPSで通知されたデータストレージサービ
ス 1 に関する情報が，情報サービスから通知された
ルールの許容範囲内だった場合，通信を行うための準
備を始める．まず，クローラサービス 1から通知され
た要望を満たす条件を計算する．この場合，クローラ
サービス 1 とストレージサービス 1 間の通信パスは
6.7Mbps以上の帯域で構築しなければならないことが
わかる．次に，自身との通信経路に対して TOSの値
(今回の実験では，TOSの値は８とする．)を設定し，
createPathコマンドで 6.7Mbps以上の帯域を持った
通信パスでクローラサービス 1 とデータストレージ
サービス 1の通信パスを繋ぐように依頼する．依頼を
受けた NCPS は，クローラサービス 1 とデータスト
レージ 1間を繋ぐ全経路の帯域を計算し，依頼条件を
満たす経路である通信パス (Communication Path1)
を構築する．
今回新たに構築したオーバーレイが情報サービス
の要求を満たす通信経路上に通信パスが構築されて
いることを確認するため，ストレージサービスから
100Mbyteのデータを取得する時間を計測し，各経路
の帯域を計測した (表 4 参照)．実験の結果から情報
サービスの要望にあわせた通信パスを構築できてい
ることがわかった．今回の実験において，情報サー
ビスの要望を満たした経路は Communication Path1
と Communication Path2 の 2 経路存在していたが，
NCPSはサービスにとってより都合が良い環境になる
よう通信パスを構築するため，Overlay1 はより広帯
域である Communication Path1で構築されている．
また，Comminication Path1で正しく通信している
ことを，4. 1. 1で用いた方法で調べる. 表 3にこの実験
の解析結果を添付した. 表 3から SrcIP192.168.24.10，
DistIPが 192.168.25.10を持つパケットのうち，TOS
の値が 8を持つパケットは Communication Path1 を
通っていることがわかる. 以上から Overlay1 は正し
表 3 実験 2 においての各 SW が持つインターフェースを流れるパケットの抜粋
Overlay1
Node B
IP= 192.168.22.10
Node D
IP=192.168.21.10
OpenFlow
Controller
OpenFlow
Application’s
Overlay
Switch 1
Switch 2
Switch 4
1
1
Storage
Service
1
1
Information
Service
Communication
Path2
Communication
Path1
Switch 1
1
Switch 3
Node C
IP=192.168.25.10
Node A
IP=192.168.23.10
Node E
IP=192.168.24.10
Communication
Path3
図 5 実験 2 のトポロジー
く Communication Path1を通って通信していること
がわかる.
5. まとめと今後の課題
4.節に行った実験の考察と，今後の課題について述
べる．• あらかじめ，Overlay毎に IP，Port以外のネッ
トワークが判断することができる何らかの識別子 (今
回の実装では TOS の値) による組み合わせ等をネッ
トワークに事前に登録することで， 同一ノード上に
存在する複数の情報サービスが異なる通信ポリシーを
適用し，現状の IPと Portによる通信制御よりも繊細
な経路制御を行えることがプロトタイプシステムによ
る動作実験によって確認できた．しかし、今回の実験
7
第二回 NetSci 研究会 xxxx/xx Vol. Jxx–X No. xx
Communication Path 最高値 最低値 平均値Communication Path1 114.600 秒 114.208 秒 114.703 秒Communication Path2 115.529 秒 118.383 秒 117.011 秒Communication Path3 125.499 秒 130.164 秒 128.067 秒表 4 実験 2 の各 Communication Path においての実測値
で用いた TOS による識別は，0～64 ビット分の範囲
内でしか変化をつけることができないため，大規模な
ネットワーク環境に適用するのは適切ではないと考え
ている．このため，TOS 以外の識別子を付与する方
法（例えば，Packetのフォーマットを新たに定義する
など）を検討している．• これまでは，情報サービスからの要望を解釈し，
要望にあわせる形でネットワークの構成を変更する機
能に注力してきたが，ネットワークの状態に加えて，
各ノードの状態 (CPU,メモリの使用状況)を計測，収
集することで，情報サービスの移動や複製を効率的に
行う方法を検討している．• 現在の NCPS が通信パスを決定する際，取り
得る全経路を計算するようになっているが，Internet
などの広域網で利用することを想定した場合，全経路
を計算することは非現実的といえる．従って，例えば，
広帯域な経路を上位１０経路分だけ計算するなどの処
理を検討する必要がある．• 本研究は，新世代ネットワークテストベッドで
ある JGN-X [9] に展開されている仮想化ノードプロ
ジェクト [8] との連携を進め，仮想化ノードの特性を
生かしながら，動的かつ柔軟ネットワーク処理を実現
するためのプロトコルとして発展することを期待され
ている．このため，既存の通信プロトコルと互換性を
持ちながら，効率的に通信を行うための新たなプロト
コルを検討している．
文 献[1] Recommendation ITU-T Y.3001（2011）, Future Net-
works: Objectives and Design Goals.
[2] Tetsuo Toyomura, Takashi Kimata, Kyoung-Sook
Kim, Koji Zettsu, Towards Information Service-
Controlled Networking: The 5th International Uni-
versal Communication Symposium, pp. 155-163, 2011
[3] M. Nick, A. Tom, B. Hari, P. Guru, P. Larry, R.
Jennifer, S. Scot, T. Jonathan, OpenFlow: Enableng
Innovation in Campus Networks, s SIGCOMM Com-
puter Communication Review, pp. 69-74, 2008
[4] NOX, http://noxrepo.org
[5] Boon Thau Loo, Minos Garofalakis, David E.Gay,
Joseph M.Hellerstein, Petros Maniatis, Raghu Ra-
makrishnan, Timothy Roscoe, and Ion Stoica.
Declarative Networking: Language, execution and
optimization. In Proc. ACM SIGMOD, pp. 97-108,
2006.
[6] B. T. Loo, T. Condie, J. M. Hellerstein, P. Maniatis,
T. Roscoe, I Stoica, Implementing declarative over-
lays. In Proc. ACM Symposium on Operating Sys-
tems Principles, pp. 75-90, 2005.
[7] S. Das, Y. Yiakoumis, G. Parulkar, N. McKeown, P.
Singh, D. Getachew, and P. D. Desai, ”Application-
Aware Aggregation and Traffic Engineering in a Con-
verged Packet-Circuit Network,” in National Fiber
Optic Engineers Conference, OSA Technical Digest
(CD) (Optical Society of America, 2011), paper
NThD3.
[8] A. Nakao, Network Virtualization as Foundation for
Enabling New Network Architectures and Applica-
tions, IEICE Trans Commun., Vol. E93-B, No. 3, pp.
454-457, March 2010.
[9] NICT, New Generation Network Testbed JGN-X,
http://www.jgn.nict.go.jp/
（平成 xx 年 xx 月 xx 日受付）
木全 崇 （正員）
独立行政法人 情報通信研究機構ユニバーサルコミュニケーション研究所 情報利活用基盤研究室 有期技術員. 2010 年９月より研修員として独立行政法人 情報通信研究機構けいはんなコミュニケーションセンター 知識処理グループ 研修員 2011 大阪市立大学大学院修士課程を修了 2011 4 月より NICT に有期技術員として現職，現在に至る．情報処理学会会員
豊村 鉄男
独立行政法人情報通信研究機構ユニバーサルコミュニケーション研究所情報利活用基盤研究室 有期技術員．2005 年より民間企業から NICT へ出向し，ユビキタスホームテストベッドの運用管理に従事．2010 年に知識処理グループの有期技術員を経て，2011 年より現在に至る．
金 京淑
Kyoung-Sook Kim is a Researcher in the National In-
stitute of Information and Communications Technology,
Japan. She received her B.S., M.S., and Ph.D. Degrees
in Computer Science from the Pusan National Univer-
sity, Korea in February 1999, February 2001, and August
8
論文／Service Controlled Networking のための OpenFlow 動的構成方法
2007, respectively. Her research interests are including
spatio-temporal databases, query languages, wireless sen-
sor data management and mining, and future networking
technologies.
是津 耕司
是津 耕司（ぜっつ こうじ）独立行政法人情報通信研究機構ユニバーサルコミュニケーション研究所 情報利活用基盤研究室室長．1992 年東京工業大学工学部情報工学科卒業．2005 年京都大学大学院情報学研究科博士課程了．博士（情報学）．1992
年日本 IBM 入社．2003 年通信総合研究所専攻研究員，2005
年情報通信研究機構研究員を経て，2007 年 同知識創成コミュニケーション研究センター知識処理グループ主任研究員，2011
年より現職，現在に至る．けいはんな連携大学院 准教授．新世代ネットワーク推進フォーラム研究開発WG「価値を創造するネットワーク」SWG 主査 (2009-2010 年)．電子情報通信学会データ工学研究専門委員会副委員長 (2011 年より)．データベース，情報検索，Web マイニングに興味を持つ．情報処理学会，日本データベース学会，米国計算機学会 (ACM) 等会員．
9
Abstract The new generation network makes use of the high processing capacity and extensibility of
the network and handles enormous distributed data , and it is demanded that There process to combination
out a great variety of information services effectively. For this purpose, We have proposed the Service-Con-
trolled Networking. Service-Controlled Networking is constructed of two layers. 1st layer, Service-Level
Overlay is abstractly describe by a declarative rule language for network requests from the service, to facil-
itate the development of network services. 2nd layer, Network Control Protocol Stack reflects the demand
from services such as the control of the QoS policy and the choice of the processing node to handle the com-
munication in the physical networks. This Paper focus on Network Control Protocol Stack and Prototype
System on OpenFlow.
Key words OpenFlow, Service-Controlled Networking, New Generation Network
