SDNは間違いなく現在のネットワーク業界において最もホットな研究テーマの一つです。 SDNは制御と転送の分離の原則を体現し、ネットワークとサービスの革新に旺盛な活力と活力をもたらします。この論文では、OpenDayLightコントローラとMininetスイッチングシミュレータを組み合わせたテスト環境を構築することで、SDN環境におけるレイヤ2/3ネットワークスイッチングのフォワーディングメカニズムと特性を研究し、ネットワークにおけるSDNアプリケーションのアイデアを提唱します。
I. SDN実験環境の選定と構築
Software Defined Networking はスタンフォード大学の clean slate 研究グループによって最初に提案されました。SDN の核心は制御とベアラの分離で、ネットワークのオープン性を実現し、トラフィックを柔軟に制御できるようにし、ビジネスやアプリケーションの上位レイヤにより最適化されたサービスを提供することです。2010年、Open Networking Foundation ONF が設立され、ONF はコントローラとスイッチ間のサウスバウンドインターフェースを標準化する OpenFlow プロトコルの開発に取り組んでおり、現在リリースされている最新バージョンは 1.4 です。Networking Foundation ONFが設立され、ONFはコントローラとスイッチ間のサウスバウンドインターフェースを標準化するOpenFlowプロトコルの開発に取り組んでおり、現在リリースされている最新バージョンは1.4です。
コントローラだけでは完全な SDN ネットワークを構成することはできませんが、現在のハードウェア SDN スイッチはまだほとんどありません。幸い、Mininet がスイッチのソフトウェアエミュレーションに基づいて導入されています。 Mininet プロジェクトはオープンソースソフトウェアでもあり、Mininet を通して Linux ホストで複数の SDN スイッチと端末を構築しエミュレートすることができます。Python スクリプトを使って、ユーザはより複雑な SDN ネットワークトポロジを設定することもできます。同時に、Mininetはまた、SDNの開発者と学習者の開発と研究を容易にするためにWireSharkパケットキャプチャソフトウェアを装備しています。
II.OpenDayLight SDN レイヤ2/3転送メカニズム分析
1) SDN ネットワークトポロジの作成と起動
1台のOpenDayLightコントローラ、2台のスイッチ、各SWはそれぞれ2台のホスト、合計4台のホストに接続され、これらのホストは2つの異なるネットワークセグメントに属し、スイッチとコントローラの間でOpenFlowプロトコルが使用されています。トポロジーはFig：
図1：テスト・トポロジー
sudo mn -custom /mnt/shared/topo2_2.py -topo mytopo,-controller=remote ip= 192.168.56.1.192.168.56.1.
SWからControllerへの登録プロセスは、パケットキャプチャソフトWireSharkを起動することで確認できます。登録プロセスでは、Controller から SW に対して、OpenFlow のバージョン番号や接続されているポートの状態などが要求されます。図のように、SW1は接続している4ポートの状態をControllerに報告し（Controllerに接続しているポートも含む）、同様にSW2も自身の状態を報告します。
図2：SWはOF:Statsリレーを介して、自身の状態とインターフェースをコントローラに報告します。
SW デバイスのデバイス登録が完了すると、Controller はネットワークトポロジ ディスカバリまたはアップデートを実行します。新しい SW がネットワークにアクセスすると、 コントローラは OF Packet Out コマンドにより、 SW1 に対して、 その全ポートで LLDP（Link Layer Discovery Protocol、 EEE802.1ab）リンクプローブパケットの送信を要求します。LLDP の送信元 MAC はコントローラによって割り当てられ、 ここでは 00:00:00:00:00:00:01（各スイッチに対して、 コントローラは SW 識別子としてこのような MAC を 1 つ割り当てます）、 LLDP の宛先 MAC アドレスはマルチキャストアドレスです。隣接する SW2 は LLDP を受信し、 SW2 はこのストリームを識別できないため、 OF プロトコルをコントローラに再送信します。LLDP の送受信により、 コントローラはスイッチ間のトポロジカルな関係を計算することができ、 ネットワークのトポロジカルな関係は、 転送フローテーブルの生成やネットワークの可視化の基礎として利用することができます。
図 3: LLDP プロービングに基づくネットワーク・トポロジーの発見と計算
2) SDNネットワークの2つの転送メカニズム
ネットワークトポロジを作成した後、コントローラでレイヤ 3 セグメントごとにゲートウェイアドレスを設定し、スイッチのインタフェースをレイヤ 3 ゲートウェイに関連付けます。ここでは、SW1 のポート 2 と SW3 のポート 2 をそれぞれゲートウェイ 10.0.0.254、SW1 のポート 3 と SW3 のポート 3 をゲートウェイ 20.0.0.254 に関連付けます。このプロセスは SDN 内でレイヤ 3 セグメントを分割し、デバイスの物理インターフェースをレイヤ 3 にマッピングすることに似ています。
図 4: OpenDayLight Web インターフェースでのスイッチのポートとレイヤ 3 ゲートウェイの関連付け
次に、Mininetプロンプトで以下のように、各ホストのIPアドレス、サブネットマスク、デフォルトゲートウェイを1つずつ設定します：
パケットキャプチャソフトウェアを使用している間、次のプロセスを得ることができます：
図5：OpenDayLight SDNレイヤー2転送メカニズムの図解
SDNネットワークでは、ホストの末端にあるホストは、それが接続されているネットワークがSDNであることを知りません、ホストが別のホストにパケットを送信するには、まだIPからMACアドレスへのARP解決を実行する必要があります。しかし、SDN の処理メカニズムは通常のレイヤ 2 イーサネットスイッチのフラッディング + MAC アドレス学習のメカニズムとは大きく異なり、次のようになります：
ソースホスト h1 (10.0.0.1) が ARP 解決 h2 (10.0.0.2) を送信すると、スイッチ SW1 はパケットを転送する方法を知らないので、OF メッセージで処理のためにコントローラに送信します。
コントローラは、このARPメッセージがh1(10,0,0.1)から送信されていることを確認し、同時にh1の位置情報も取得します。この時点で、コントローラはネットワークトポロジーを計算し、各ノードからネットワーク上の10.0.0.1までの転送経路を取得し、OF Flow Modifyメッセージによって各スイッチに転送フローテーブルをプッシュすることができます。
ARPを受信したので、Controllerは各SWに対応する10.0.0.0/8セグメント上の非SWインターコネクトポートに、10.0.0.2のMACアドレスを要求するARPを発行するよう依頼します。ここで、Controllerは受信したARPをそのまま発行するのではなく、ソースIPをControllerで先に設定したゲートウェイIPアドレスである10.0.0.254に変更して発行します。
h3(10.0.0.2)だけがARPに応答し、ARPレスポンスをSW2に送信します。SW2もそれをどうすればいいかわからないので、OFプロトコルでカプセル化されたARPをコントローラに送信します。コントローラは、これがARPレスポンスであり、10.0.0.1が送信したのと同じARPリクエストであることを発見します。SW1はこのアクションを実行します。
また、h3からARPを受信したコントローラは、10.0.0.2の位置を学習し、ネットワークトポロジーから10.0.0.2に到達するためのネットワーク全体の転送経路を計算し、OF Flow Modifyメッセージで各スイッチにフローテーブルをプッシュします。
h1はARP Responseを受信し、ARP解決プロセスを完了した後、ICMG PING Requestパケットを構築します。ここで、送信元と宛先のMACはそれぞれh1とh2のMACであり、送信元と宛先のIPはそれぞれh1とh2のIPです。パケットは問題なくh2に送信されます。
h2は、それがICMP PING Requestであり、ソースがh1であることを発見しますが、この時点ではまだh1のMACを持っていないので、別のARP解決を実行する必要があります。 SW2は、h1のMACについて学習したControllerに再びARPを送信し、Controllerは直接応答し、ARP結果とOF経由でSW2に送信する必要があるポートを返すことができます。
h2はARPを学習した後、ICMPレスポンス・パケットを作成してSW2に送信し、SW2はそれをh1の宛先アドレス一致転送テーブルに従ってSW1に転送し、SW1はそれをh1の宛先アドレス一致転送テーブルに従ってh1の対応するポートに送信します。 h1からh2への双方向チャネルはこれで完全に開通しました。
3) SDNネットワークのレイヤ3転送メカニズム
レイヤ 2 のフォワーディングメカニズムを分析した後、トポロジを再起動して初期状態に戻し、2つの異なるネットワークセグメント上のホスト間で SDN がどのようにフォワーディングを実装しているかをテストします。WireShark を使ってパケットをキャプチャしながら h1 ping h4 と入力すると、以下の結果が得られます：
レイヤ3転送では、ホストはまず、宛先IPが自分と同じネットワークセグメントにないと判断し、デフォルトゲートウェイにパケットを送信し、そこでゲートウェイのMACを解決する必要があります。h1はゲートウェイのMAC、10.0.0.254を要求するARPを送信します。
Controllerにはゲートウェイアドレス10.0.0.254が設定されているため、ARPに対して自身のMACアドレスで応答し、h1に接続されているインタフェースにARP応答を送信するようSW1に指示します。同時にControllerはh1の存在を認識し、パス計算により各スイッチから10.0.0.1へのパスを取得し、OF Flow Modifyにより各スイッチにフローテーブルをプッシュします。
ホストh1はゲートウェイからARPを受信し、送信元と宛先のMACをh1とゲートウェイ10.0.0.254のMAC、送信元と宛先のIPをそれぞれh1とh4のIPとするICMP PING Requestパケットを構築し、このパケットをSW1に送信します。
SW1には20.0.0.2に到達するフローテーブルがないため、このパケットをキャッシュします。同時に、SW1はこのパケットをOFプロトコルでControllerに送信します。Controllerは、このパケットが20.0.0.2に向かっており、この宛先ホストの位置が不明であることを発見します。そこでControllerは、20.0.0.0/8セグメントに対応する各SWの非SWインターコネクトポートに対して、20.0.0.2のMACアドレスを要求するARPを発行するよう要求します。ARPのソースIPは、20.0.0.0/8のゲートウェイアドレス20.0.0.0.254です。
SW2はこのARP Responseを受信すると同時に、h4の位置がSW2のポートの1つ下にあることを確認します。コントローラは、パス計算によって各スイッチの20.0.0.2までのフローテーブルを取得し、OF Flow Modifyメッセージによって各スイッチにフローテーブルをプッシュします。
SW1はフローテーブルをロードした後、キャッシュされたICMPパケットを正しいインタフェースに転送することができ、もちろんSW2は問題なく転送することができます。
図6：20.0.0.2宛先アドレスのフローテーブルダウン
注：ホストに隣接するスイッチSWの場合、ホストに対応するストリームの発信ポートを参照するだけでなく、宛先MACアドレスをホストMACに一致するように書き換える必要があるため、ダウンストリームフローテーブルで2つのアクションが発生します。
このときh4はICMP Requestを受信し、それが異なるネットワークセグメントのホストからのICMP Requestであることがわかるので、ARPを通して自身のデフォルトゲートウェイを解析する必要があります。このリクエストはSW2に送信された後、OFプロトコルでコントローラに転送され、コントローラは自分のMACで応答し、OFプロトコルでSW2に送信し、最後にh4に送信されます。
ホストh4はARPを受信し、送信元と宛先MACがh4とゲートウェイ20.0.0.254のMACであり、送信元と宛先IPがそれぞれh4とh1のIPであるICMP PINGレスポンスを構築することができます。このパケットはSW2に送信された後、SW1を通過し、同様にSW1は宛先MACアドレスをh1のMACに変更してから宛先ポートに転送します。その後、h1とh4の間のチャネルは完全にオープンされます。
図 7: OpenDayLight SDN レイヤ 3 転送メカニズムの図解
ネットワークの全てのホストが一度通信を終えると、SDN コントローラは全てのネットワークノードの状態を検知します。コントローラによって提供されるインターフェースを通して、与えられたネットワークトポロジーと全く同じネットワークの視覚的なビューを見ることができます！
図 8: OpenDayLight SDN 制御インターフェースによって描かれた SDN のネットワークトポロジー
各スイッチのフローテーブルを観察し、各スイッチに正しいフローテーブ ルがロードされていることを確認します。SW は、マッチするストリームの数、転送されたバイト数、ライブ時間など、ストリー ムのステータスを定期的にコントローラに報告します。これらのストリームとそのステータスは、OpenDayLight のコンソールで確認できます：
SDNにおけるネットワークスイッチの転送フローテーブル
4) 特殊なネットワーク構造におけるSDNの転送能力の解析
従来のイーサネットでは、ループが存在することはありえず、仮に存在したとしても、ネットワークデバイスはスパニングツリー（Spanning Tree）プロトコルによって遮蔽されます。OpenDayLightコントローラはネットワークトポロジー発見機能を持ち、そのアルゴリズムでループを回避することができます。
テストの図に示すように、リングトポロジーに接続された5台のスイッチと5台のホストを構築。テストを通じて、トラフィックの転送間のホストが正常であることを示しており、ブロードキャストストームやループが表示されませんが、各スイッチのフローテーブルをチェックし、最短パスを使用して宛先アドレスに示されています。
図 9: OpenDayLight SDN はループのあるレイヤー2ネットワークトポロジーをサポートします。
加えて、OpenDayLight の制御下にある SDN ネットワークはスタティックルーティングの方法で外部ネットワークとのインターワーキングをサポートすることもできますが、このテストはソフトウェアスイッチエミュレーションに基づいていたため、この機能をテストすることはできませんでした。
要約
OpenDayLight 制御下での SDN ネットワークのフォワーディング動作の分析に基づくとわかります：
OpenDayLightのシンプルなフォワーディング機能は、ネットワーク全体のトポロジーに基づいています。 コントローラは、ホスト間やホストとゲートウェイ間のARPメッセージを処理することで各ホストの位置を取得し、最短経路優先アルゴリズムを用いて宛先ホストに到達するためのフローテーブルを計算し、ネットワーク内の各スイッチに送ります。
OpenDayLightのシンプルな転送機能では、フローは宛先IPアドレスのみに基づいてマッチングされ、すべての5タプルのフィールドと優先順位フィールドではなく、この点は従来のレイヤー3機器に近い、あなたは大幅にフローテーブルのサイズを減らすことができ、実際の生産環境に近いです。
OpenDayLight はレイヤ2フォワーディングだけでなく、ループやブロードキャストストームを回避するレイヤ3フォワーディングもサポートできます。
OpenDayLight はコントロールとベアラの分離を実現し、ネットワーク上のレイヤー2/3デバイス間の区別はなくなり、ネットワークは完全にフラット化されました。従って、同じ SDN の中で、ホストは理論的には許可されたアドレス範囲の中で利用可能な IP アドレスを割り当てることができます。このやり方はホストの位置と IP セグメントの物理的な位置との密接な結合を切り離し、IP アドレスセグメントの断片を利用できないという恥ずかしい事態を回避します。また、スイッチ間で多数の相互接続IPアドレスを設定する必要もなくなり、アドレス空間を節約できます。
OpenDayLightは、外部の非SDNネットワークとのレイヤー2/3インターワーキングをサポートしています。
要約すると、OpenDayLight の基本バージョンは伝統的なレイヤー2/3スイッチの基本的な転送機能を実現し、あらゆるネットワークトポロジーと最適パス転送をサポートし、実用段階に達しました、BGP、ファイアウォールや他のネットワークアプリケーションを実装し、従来のネットワークデバイスに匹敵する十分な制御を持つ SDN コントローラになります。
SDN はデータセンターの仮想化、メトロのレイヤ 2/3 フォワーディングと VPN、ネットワークセキュリティとトラフィッククレンジングをサポートする上で輝くでしょう。
