冗長経路を利用した OpenFlow 制御ネットワークの自動構築 橋本 直樹 † 廣津 登志夫 ‡ 概要 OpenFlow プロトコルでは，ネットワーク機器における経路制御部とパケット転送部のうち，制御部をコン トローラとして分離して，複数のネットワーク機器に対して一括した制御を可能としている．この OpenFlow の 枠組みは，自由度が高く柔軟なネットワーク制御を実現する一方，コントローラとスイッチをつなぐ制御ネット ワークを別に構築するコストが問題点としてあった．これまでの研究で制御ネットワークをスイッチ間接続に よって構成されるデータネットワーク上に自動構築することを可能とする制御手法を提案した．本研究ではデー タネットワークの冗長経路を利用し，前述の環境において制御チャンネルの安定性を向上する手法を提案する． 1 はじめに しかし，この自動構築手順においては特殊な制御メッ 近年，サービスの多様化およびそれを利用する大量 セージが必要であり，OpenFlow スイッチとコントロー のユーザの爆発的増加によって，インターネット設計 ラに改造が必要であった．これに対して，これまでに 当初に想定されていたような端末間通信や単純なサー 通常のトラフィック操作のみで制御ネットワークをス バークライアント型のシステムとは異なる，複雑なネッ イッチ間接続によって構成されるデータネットワーク トワーク接続環境と複数レイヤに跨がるアプリケーショ 上に自動構築することを可能とする制御手法 [2] を提 ン志向の通信制御の必要性が生じている．日進月歩で進 案し，OpenFlow の制御メッセージが TCP/IP 通信を 化していくサービスにより生まれる新たな要求に即座 用いることを利用することで仮想スイッチにより構成 に応え，多種多様なサービスの展開を加速させるネット された OpenFlow ネットワーク上に実装した結果につ ワークを実現するための技術として Software Defined いて報告した．しかし，データネットワーク上で回線 Network (SDN) [1] が注目されている．現在主流となっ 断などの障害が発生すると制御メッセージの交換が阻 ている TCP/IP や Ethernet といった Internet を構成 害され，以降のパケット転送と経路制御の両者に影響 するネットワーク技術では，機器のソフトウェアとハー を与えてしまう可能性があった．そこで本研究では， ドウェアが一体となっているため，機器ベンダーが想 データネットワークの冗長経路を利用し，接続経路に 定するアーキテクチャ以外のネットワーク構成は実現 変更があった場合でも制御メッセージを極力失わない しにくいという問題があった．SDN では個々のネッ ためのフェイルオーバーについて考察する． トワーク機器に設定するのではなく，各装置を集めた 2 ネットワーク全体を一つの単位として一括で制御する． OpenFlow プロトコル Software-Defined Networking (SDN) はネットワー OpenFlow はこの SDN における代表的なアーキテク ク制御機能とデータ転送機能が分離し，プログラムに チャの一つである． OpenFlow は制御とデータ転送を別の装置に分離し よりネットワークの制御が実現できる新しいアプロー た機構を持つため，制御ネットワークとデータネット チを持つネットワークである．プログラマブルである ワークを別々に構築しなければならない．これについ ことによって動的に，かつ抽象化されたネットワーク て従来の研究で制御ネットワークをデータネットワー 制御が可能となった．また長く各ベンダーの独自実装 ク上に自動構築するための手法が提案されている [3]． であった制御機構が標準化されたことで，ネットワー ク管理者自身が個々の環境に適した設定が可能となり， † Hashimoto Naoki, Hosei University ‡ Hirotsu Toshio, Hosei University 柔軟性や管理における利便性が高まった． 1 OpenFlow は SDN ソリューションを構築するための indirect 特定の一つのポート 基本要素の一つであり，従来のネットワーク機器にお fast failover アクティブな最初のポート けるパケット転送処理を行うスイッチと，アドレス学習 インストラクションは，フローに対する処理定義で やルーティングなど経路制御機能を担うコントローラ あるアクションの集合である．マッチフィールドに一致 の 2 種の装置によって構成される．これにより機器の した通信を受け取った OpenFlow スイッチは，アクショ 制御がコントローラによって一元管理されるため中央 ンの記述に従って通信を制御するが，複数のフローテー 集権型のアーキテクチャを実現可能であるという特徴 ブルを跨ぐような処理はアクションセットとしてプー を持つ．スイッチとコントローラの接続は OpenFlow ルされ，行われるべき全アクションの追加が終わった チャンネルと呼ばれる通信によって実現され，MAC ア 時点で実行される．主なアクションには「出力，フィー ドレスや IP アドレス，ポート番号などのフィールド ルドの書き換え，キュー，ドロップ」がある． 情報によって決定される一連の通信単位であるフロー カウンタはテーブル，フロー，ポート毎に管理され， に対してアクションを指定し経路制御を行う．このフ パケット数やバイト数，当該フローが OpenFlow スイッ ローは任意の層を扱うことができ，スイッチは指定さ チ上に生成されてからの時間などの情報を記憶する． れた振る舞いのみを処理するためネットワーク全体を カウンタの値によって，ネットワーク情報の可視化，ト 高速かつ柔軟に制御することが出来る． 2.1 ラフィックの流量に応じたフローごとの帯域制御，ト ラフィックの傾向に応じた転送パスの切り替えなどを フローエントリー 行うことができる．これらの情報はコントローラがス フローエントリーはマッチフィールド，インストラ イッチに要求することで出力される． クション，カウンタ，優先度，タイムアウト，クッキー の 6 つの要素で構成される．OpenFlow コントローラ 2.2 は各スイッチが複数保持しているフローテーブルに， OpenFlow メッセージ OpenFlow プロトコルは 3 種類のメッセージタイプ フローとインストラクションの組であるフローエント (Controller-to-Switch, 非同期，同期) をサポートして リーを設定する． いる．これらのメッセージは前述のマッチフィールド， マッチフィールドはスイッチがフローを受信した際に アクション，統計情報などを保持している．主な内容 トラフィックを識別し特定するためのルールで，Open- としては，機能やバージョン確認を行うための情報交 Flow 1.3[4] では 40 種，レイヤー 1-4 層相当のフィール 換 (Hello)，スイッチのポート状況など状態監視，フ ドとその依存関係が定義されている．さらに書き込む ローテーブルでマッチするエントリーがない場合のコ テーブルも複数存在しており，テーブルと優先度を合 ントローラへの転送 (Packet-In)，フローテーブルの わせた組み合わせによって今までの枠組みに縛られな 追加や変更，削除 (Flow-Mod)，カウンターの収集が い通信の制御が可能となっている．マッチングに失敗 挙げられる．コントローラはこれらの通信で各スイッ したフローについては破棄もしくはコントローラへの チを管理し，適切な設定を与える．本研究で使用する 通知のどちらかを予め指定しておくことが可能である． メッセージについて説明する． OpenFlow1.1 以降はポートのグループ化によって，コ 2.2.1 ントローラとの通信を挟まずに簡易的な複数経路やマ Packet-In メッセージ フローエントリーにマッチしないパケット，あるい ルチキャストを実現可能である．グループのタイプと は出力先が CONTROLLER となっているフローにつ して以下 4 つが定義されている． いて，スイッチがコントローラへ通知するために送信 all 同グループに属す全てのポート される．スイッチに十分な記憶領域があるときには， select 定義された選択アルゴリズムに基づいて選択 Packet-In の際に対象フローをバッファリングした上 されたポート で，ヘッダ情報の一部をコントローラに送信する． 2 2.2.2 Flow-Mod・Group-Mod メッセージ フローテーブルやグループテーブルに対してフロー エントリー及びグループ情報を設定するため，コント ローラが各スイッチに対して送信する．フローエント リーにはオプションとして idle- time out と hard-time out を指定できる．前者は最後にマッチしてからの経過 図 1: OpenFlow チャンネルのオーバーレイ 時間，後者は該当エントリーがスイッチに追加されて からの指定時間が経過するとエントリーテーブルから にもコントローラによって定義されたフローエントリ 削除される．またこれらオプションによりエントリー に従って該当するパケットを転送するが，後者は全て が期限切れになった時に，スイッチがコントローラに のパケットをドロップする． 削除されたことを通知するかどうかを設定することも できる．また，グループはポートを抽象化する機能で 3 あり，登録された複数のポートの中から指定されたタ 文献 [3] では，OpenFlow ネットワークの制御ネット イプによって出力元が選択される． 2.2.3 既存研究 ワークにおける問題点である，コントローラとスイッ Echo メッセージ チ間の到達性を保障することによる柔軟性の低下や制 スイッチ，コントローラのいずれかが相手の装置に 御ネットワークを別途用意することによるコストの増 送信し，接続が継続していることを確認する．受け取っ 大による適用範囲の制約を解決するため，図 1 のよう た装置は必ずリプライメッセージを返さなければなら に制御ネットワークをデータネットワーク上に重ねて ない．コントローラとスイッチの間の遅延と帯域の測 作る，OpenFlow チャンネルのオーバーレイ化が提案 定に使用することができる． されている．この手法では，EtherType フィールドを 2.3 0xF103 とする特殊フレームを用いて既存の TCP/IP OpenFlow チャンネル プロトコル上で通信する．このフレームは計 4 種類 OpenFlow チャンネルは，各 OpenFlow スイッチと で，スイッチ間の接続関係を把握するための Request コントローラの間を接続する通信路である．OpenFlow と Reply メッセージ，コントローラとスイッチ間のセ スイッチはデータプレーンのみの機能を持つため，既 キュアチャンネルをトンネリングするための Setup・ 存のネットワーク機器群のようなその装置自身による Tunneling メッセージがある．この特殊なフレームの 経路制御が行われず，単体でコントローラとの到達性 解釈のために，スイッチ，コントローラ両装置に対す を確保できないため，通常は OpenFlow プロトコルに る変更を必要とする． よらない制御のための通信チャンネルを設定する必要 これに対して著者らは図 2 に示した物理接続と，ス がある． イッチの起動と同時に予め設定するフラッディングベー この接続を確立する手順としては，まずスイッチが スの「起動時エントリー」，どの物理ポートがコント TLS または TCP セッションをコントローラに対して ローラへ通じているかを Packet-In によって取得する 開始する．次に Hello メッセージによって互いのバー 「初期エントリー」，各スイッチからコントローラへの ジョンを確認し， 続いて Feature，Configuration を 制御経路を決定する「確立エントリー」，コントローラ 送受信してスイッチの情報を取得，設定を完了すると とスイッチが直接接続されておらず，別のスイッチを OpenFlow チャンネルが確立される．定期的に Echo 中継する場合に設定する「中継エントリー」の 4 種を追 メッセージを送受信して接続が継続していることを確認 加することによって制御ネットワークをデータネット し，仮に接続が切断されている時スイッチは fail secure ワーク上に構築した．これによって OpenFlow 本来の もしくは fail standalone に切り替わる．前者は切断時 仕様に一切変更を加えることなく，既存のプロトコル 3 トワークである．本章で示す改良は，OpenFlow チャ ンネルのコネクションが利用する制御経路が変更され たときにコントローラが各スイッチのフローテーブル を書き換える際に生じる遅延への対処と冗長経路設定 の 2 点である． 4.2 書換時の遅延への対処 接続したスイッチや回線の障害が発生すると，Open- Flow スイッチはポートのリンクダウンを検知し PortStatus メッセージによってコントローラへ通知する．こ れによりリンクダウンがポートのコンフィグ情報の変 図 2: スイッチの接続構成 更として伝わるので，コントローラはその変更に適用す を用いた物理的なネットワークに依存しないシステム るように新たな経路を計算し，各スイッチに Flow-Mod を構築する手法を示した．この環境において制御ネッ メッセージで設定の変更を行う．ここで，OpenFlow トワークが構成された後にネットワーク障害によって チャンネルをデータネットワーク上に構築する著者ら ネットワークのトポロジが変更された場合，障害が発生 の提案する手法では，OpenFlow チャンネルの経路上 した物理リンクが OpenFlow チャンネルのコネクショ に障害が発生すると，OpenFlow チャンネルに関するフ ンに関係しないならば Port-Status メッセージを使っ ローエントリーが書き換わるまでの間，制御メッセージ てリンクダウンを確認することができるが，関係する のトラフィックが遮断されてしまう．そのため，Open- 場合はコネクションを維持できず，障害経路に関係す Flow チャンネルに関するフローエントリーの書き換え るフローエントリーが初期化される必要がある．この も行うことができず，スイッチ側から OpenFlow チャ 設計では，時間経過によってフローエントリーが削除 ンネルを再接続するまでの間は当該スイッチが制御不 されることを待つか，定期的に LLDP と呼ばれるトポ 能となる．この対策として，障害が発生したときに他 ロジー検出用のパケットを送出して接続情報を収集し のポートからパケットを送出するようなフローエント なければならないという問題点があった． リーを各スイッチに事前に設定しておくことが考えら れる．しかし，各フローに対してマッチングするフロー 4 4.1 提案手法 エントリーは一つに限られるため，OpenFlow1.0 の仕 概要 様内だけで二つのフローエントリーを同時に適用する ことは難しかった．ただし，OpenFlow1.1 以降で実装 本研究の主眼は OpenFlow プロトコルで定義された されたポートのグループ機能によって提供される Fast メッセージを用いて，スイッチやコントローラの実装 Failover を用いることで，スイッチがアクティブなポー に対してを一切変更を加えることなく制御ネットワー トを自発的に選択することが可能となった．必要なフ クとデータネットワークを統合することにある．著者 ローエントリを図 4 に示す． らは提案した手法 [2] では，データネットワークの冗 図 3 のネットワークトポロジーを用いて障害時の動 長性をあまり利用できていなかった．本研究では，接 作手順を説明する．ここでは SW1 と SW3 の間で障害 続経路に変更があった場合でも制御メッセージを極力 が発生する場合について考える．まず，障害が発生し 失わず，またスイッチがコントローラへの問い合わせ ていない時には，各スイッチからダイクストラ法によ を待たずに通信経路を変更することを目的として提案 る最短経路の方向に OpenFlow チャンネルのフロー制 手法の改良を行う．ただし，ここで対象とする環境は 御エントリーが設定されている．そのため，SW6 で発 OpenFlow 対応のスイッチのみによって構成されたネッ 4 生した制御メッセージは SW3 - SW1 と伝わってコン トローラに届く．さらに，各スイッチには OpenFlow チャンネルのフローエントリー方向のポートに障害が 発生したときのために，そのポートと他の経路によっ てコントローラへ到達することが可能なポートを Port Group として構成し Fast Failover の設定を行う．SW6 で発生した制御メッセージは一度 SW3 に送信される 図 3: 冗長経路の例 が，コントローラへ向かうポートに障害が発生してい るため，Fast Failover によって冗長経路である SW6 へ 戻される．SW6 ではコントローラへ送出したメッセー ジがコントローラ方向のポートから戻ってくると，そ の先で何らかの異常が発生していることが推定できる． 図 4: 最終的なエントリーテーブル そこで，コントローラ方向のポートからコントローラ 向けのパケットが流入してくるという条件に対して， 冗長経路への送出を指示するフローエントリを設定し イッチの直近が冗長経路として算出されることを許可 ておけば，自動的に障害時の冗長経路の切替が実現で する．図 3 において，SW5 が SW4 - SW8 - SW2 の経 きる．このような設定を全てのスイッチに用意してお 路を制御経路としている場合を例に挙げる．このとき けば，冗長経路向けに送出したパケットはどこかで通 SW5 は SW6 もしくは SW9 を通る冗長経路を持つが， 常のコントローラ向けのフローエントリを持つスイッ SW6 の経路の方が経路の重なりが少ないため SW9 が チに到達し，通信が維持される． 冗長経路として選ばれることはない．また SWA，SWB のようにループ接続を持たないスイッチは計算の対象 4.3 冗長経路の算出 外とする． 確立・中継エントリーで利用するコントローラ方向 の物理ポート以外を対象として最もコスト (中継経路 実装 5 との重なり，経路のホップ数) の低い経路を算出して 5.1 冗長経路とする．前節で検出した制御経路の異常の際 環境 4 章で述べた手法を，OpenFlow スイッチからなる にネットワーク全体のフローエントリーが更新完了す ネットワークに実装して動作を確認する．ここでは，仮 るまで利用される． 想環境上にソフトウェアスイッチを用いて環境を実現 1. 探索元のスイッチで制御経路に利用しているポー した．1 台のスイッチをコントローラと直接接続し，残 トは対象から除外する りのスイッチはそれまでに接続されたスイッチに対し 2. コントローラ方向のポート以外に直接接続された て順繰りに接続していく．最後に，あるスイッチから スイッチが ないならば、冗長経路はない 別のスイッチに接続することでループ接続を実現する． 3. 探索元のスイッチから直接接続の別スイッチから， 予め必要なフローエントリーはスイッチに設定し，コン 自身が中継スイッチとなるものは候補から外す トローラとスイッチ間は Hello，echo メッセージのみを 4. 最もコストの低い順にソートしてトップを選択 やりとりする．グループ機能に対応した Trema-edge， 5. 3,4 を繰り替えす Open vSwitch を利用した． 冗長経路は到達性の維持を最優先とするため，経路 のホップ数よりも重なりコストの比重を重くする．た だし同じスイッチを複数回経由しないならば，対象ス 5 の冗長性を利用するためのフローエントリを固定的に 設定し， 「スイッチからコントローラへの Echo リクエス トメッセージが転送されること」を接続されていると 定義し，スイッチからコントローラへの制御メッセー ジが失われないためのルールのみを考察した．しかし， 本来であればコントローラとスイッチのメッセージ交 換は継続して行わなければならない．スイッチとコン トローラの接続を保持するためには Echo メッセージ が返却される必要があるため，制御経路の修復はこれ 図 5: テスト接続環境 5.2 よりも早くなければならない． 今後の課題として，本研究で提案したルールを適用 導通実験 したコントローラを実装し，OpenFlow を利用したネッ 5.1 節の環境を最も簡略化させ，図 5 のようにスイッ トワークの自動構築にかかる時間やネットワーク障害 チをコントローラから見て 3 段になるような直列接続 時の復旧について調査する必要がある． のトポロジを構成した．SW1 と SW3 の間に冗長経路 を付与し，この経路のコストを上げることで制御経路 参考文献 を調整した．監視には tshark を用いて，監視対象とな [1] OPEN る冗長経路で利用されているイーサアダプタの上を流 NETWORKING 「Software-Defined れるパケットをキャプチャリングした．制御経路のた Networking: FOUNDATION The New Norm for Netwroks White Paper」April 13, 2012. めに設定されるフローエントリは冗長経路を利用せず にコントローラと通信できることを予め確認している． [2] 橋本直樹，廣津登志夫 「OpenFlow ネットワーク ここで SW1 と SW2 の間で障害が発生したと仮定 における制御ネットワークの自動構築」 日本ソフ し，SW2 側で SW1 と接続されているイーサアダプタ トウェア科学会 第 14 回インターネットテクノロ を ifconfig によってダウンする．ダウンしたアダプタ ジーワークショップ でパケットの疎通がなくなることを確認し，SW3 の [3] 小出俊夫，下西英之 「OpenFlow ネットワークに 冗長経路に接続されたアダプタを監視する．このとき おける制御ネットワークの構築自動化に関する一検 SW2 と SW3 で生成されたメッセージが確認されたた 討」 電子情報通信学会 信学技報 (NS2012-168) め，SW2 で転送に失敗したパケットが SW3 へ返却さ p.133-138. れ，冗長経路へと再転送されたことを確認できた． [4] 「OpenFlow Switch Specification Version 1.3.2 6 まとめ Implemented (Wire Protocol 0x04)」 Apr 25, 著者らの，OpenFlow 本来の仕様に変更を加えずに 2013 制御ネットワークをデータネットワーク上に構築する システムについて，本研究ではデータネットワークの 冗長経路を利用し，制御パケットの到達性を向上する 手法を追加提案した．これによって，データネットワー クの冗長性を制御ネットワークが併用できるため柔軟 性を担保できることを示した． 本研究では，制御メッセージがデータネットワーク 6
© Copyright 2024 Paperzz
