ResilientFlow: Deployments of Distributed Control Channel Maintenance Modules to Recover SDN from Unexpected Failures.

Talk at DRCN 2015, Kansas, MO, USA.

Transcript

1. ResilientFlow: Deployments of Distributed Control Channel Maintenance Modules to Recover SDN from Unexpected Failures
   1 †Takuma Watanabe, †T.Omizo, *T.Akiyama, †K.Iida DRCN2015 Kansas, MO USA 2015-03-27 †Tokyo Institute of Technology *Kyoto Sangyo University
2. Introduction •  SDN(Software-Defined Networking) goes widely accepted [1] •  Current SDN lacks the reliability [2] •  Especially against large-scale, unexpected link failure • What we did: •  Add SDN the resiliency agaist multiple link failure •  Through adding SDN switches a self-healing module (CCMM) •  Design, Implement, Experiment of CCMM 2 [1] B. Nunes, M. Mendonca, X. Nguyen and K. Obraczka, “A Survey of Software-Defined Networking: Past, Present, and Future of Programmable Networks”, IEEE Communications Surveys & Tutorials, vol. 16, no. 3, pp. 1617–1634, Third quarter, 2014. [2] B.J. Asten, et al., “Scalability and Resilience of Software-Defined Networking: An Overview,” arXiv:1408.6760v1 [cs.NI], Technical report, Cornell Univ., Aug. 2014.
3. Background: Wide adoption of SDN •  Strong needs on manageability and flexibility •  Multifarious resource demands from applications •  Inflation of operational tasks on network administrators Applications Dynamic controlling 3 •  Wide adoption of SDN (Software-Defined Networking) which promises manageable, flexible networking Networking Infrastructure
4. Background: Design of SDN •  Separation of control plane and data plane •  Centralization of control plane into controller 4 Control  Plane   Data   Plane   Data   Plane   Data   Plane   Control   Plane   Control   Plane   Data   Plane   Data   Plane   Switch   Switch   Switch   Controller   Conven&onal  Architecture   SDN  Architecture   Control  Channel   Control Plane ・Collecting topology ・Calculating routing entries Data Plane ・Forwarding packets
5. Background: Reliability of SDN •  Problem: Reliability of Control Plane •  Entire SDN switch relies on controllers. •  A failure on control channel and/or controller leads to corruption of entire network 5 Switch   Switch   Switch   Oops! Controller   •  Research Issue: Bring reliability against link failure or controller failure [2] !
6. Background: Related works •  Standardized Specs: •  OpenFlow [3]: Wide-adopted SDN specification •  Fail secure/standalone mode (since 1.1) •  Fast failover specification (since 1.1) •  Multiple controller (since 1.2) •  Regarding Controller Failure: •  State sync method proposal for backup controllers [4] •  Regarding Control Channel Failure: •  Link down failover proposal using central controller [6] •  Which are targeting fast failover (within 50ms) 6 [3] N. McKeown, et. al., “OpenFlow: Enabling Innovation in Campus Networks,” ACM SIGCOMM Computer Communication Review, Mar. 2008. [4] P. Fonseca, et al., “A Replication Component for Resilient OpenFlow-based Networking,” IEEE NOMS, 2012. [6] S. Sharma, et al., “Fast Failure Recovery for In-band OpenFlow Networks,” IEEE DRCN, 2013.
7. Our goal and proposal •  Issues on Current Researches: •  Not targeting multiple, unexpected link failure •  Limited failover capability relying on centralized controller Lack of capability against large-scale failure (e.g. earthquake) 7 •  Goal: •  Bring SDN a self-healing capability of control channel against large-scale, unexpected link failure •  Proposal: ResilientFlow •  Self-healing mechanism on control channel
8. Approach of ResilientFlow 8 •  Approach: •  Using distributed method •  Independent from centralized controller •  Only targeting control channel failover •  Adding module for distributed control channel self-healing •  CCMM (Control Channel Maintenance Module) •  Issues on Current Researches: •  Not targeting multiple, unexpected link failure •  Limited failover capability relying on centralized controller
9. Overview of ResilientFlow •  Enables switches to manage their own control channel S   S   C   S   M M M S   S   C   S   M M M ✗   Before  Link  Failure   A9er  Link  Failure   Controller   Switch   CCMM(proposed)   S   C   M   9 ・Detects link failure ・Sets up a new path
10. Requirements and Design of ResilientFlow (1) Disconnection Detection •  Switches should detect their control channel disconnection (2) Path Calculation •  Switches should calculate an alternative path to the controllers (3) Establishing New Control Channel •  Switches should be able to restore control channel through modifying their own flow table S   S   C   S   M   M   M   ✗   Controller   Switch   CCMM(proposed)   S   C   M   10 Establishing new path
11. Design of ReslientFlow 11 Physical  Ports   Flow  Table   Control  Channel   End  point   Control  Channel   Maintenance  Module   Neighboring   CCMMs   Controllers   (3)   3)  Installs  Flow   Entries   (1)  Monitors  Link  St (2)  Exchg.  Topo  Map (1)   (2)   S   M   S   M   S   M   C   (1) Heartbeat (2) Topo Map
12. Implementation of ResilientFlow (1/2) (1) Disconnection Detection •  Switches should detect their control channel disconnection (2) Path Calculation •  Switches should calculate an alternative path to the controllers (3) Establishing New Control Channel •  Switches should be able to restore control channel through modifying their own flow table 12 Normal Link-State Routing represents these; We use Quagga OSPF daemon Implement Flow Installer using Python
13. Implementation of ResilientFlow (2/2) 13 Switch  Node  (Linux)   Flow  Entry  Installer   Linux  kernel’s   RouMng  Table   OSPF  daemon   Open  vSwitch   Installs   Flow  Entries   External  Ports   Internal  Ports   Hello Packets and Topo.
14. Experimental Evaluation •  Objectives: •  Feasibility study and performance evaluation •  Feasibility (validity): •  Works with any type of control channel (in Scenario 1) •  Works with multiple, unexpected link failure (in Scenario 2) •  Performance: •  Switch restoration time (in Scenario 1) •  Network restoration time (in Scenario 2) •  Method: •  Network emulation with modified Mininet [11] 14 [11] B. Lantz, et al., “A Network in a Laptop: Rapid Prototyping for Software-Defined Networks,” Proc. ACM SIGCOMM Workshop on Hot Topics in Networks (Hotnets-IX), pp. 19:1–19:6, Oct. 2010.
15. Experimental Evaluation › Scenario 1 •  Feasibility (validity): •  Works with any type of control channel •  Types of control channel: 2 types Controller   Switch   Switch   Indirect  (In-­‐band)   Direct(Out-­‐of-­‐band)   15
16. Experimental Evaluation › Scenario 1 •  Topology: 4 nodes, 6 links •  1000 Mb/s with 5ms delay •  1 is a target switch 16 •  Types: 3 case •  Out-of-band → In-band •  In-band → In-band •  In-band → In-band (mid-path) •  Measured time: 5 events •  Network topology map generated •  Control Channel Restoration •  … C 1 2 3
17. C
    1
    2
    3
    C
    1
    2
    3
    C
    1
    2
    3
    C
    1
    2
    3
    C
    1
    2
    3
     C
    1
    2
    3
     (a) Out-to-in (b) In-to-in (c) In-to-in-middle Figure 5.3: Three failure cases in single specified link failure experiments chronously collects the network topology map, calculates the path, and installs the fl entries. This is considered to happen due to the reason that the in-to-in and the in-to middle case take a longer path than the other cases after the disconnection. After all switch alongside the path from the switch to the controller are configured, the switc can restore the connectivity to the controller. This describes the time between the tim C
    1
    2
    3
    C
    1
    2
    3
    C
    1
    2
    3
    C
    1
    2
    3
    C
    1
    2
    3
     C
    1
    2
    3
     (a) Out-to-in (b) In-to-in (c) In-to-in-middle Figure 5.3: Three failure cases in single specified link failure experiments chronously collects the network topology map, calculates the path, and installs the fl entries. This is considered to happen due to the reason that the in-to-in and the in-to middle case take a longer path than the other cases after the disconnection. After all switch alongside the path from the switch to the controller are configured, the switc Out-to-in In-to-in In-to-in-mid 211.5 ± 0.3 [ms] 246.3 ± 7.0 [ms] 211.5 ± 0.6 [ms] 279.3 ± 23.9 [ms] 217.9 ± 8.7 [ms] 292.7 ± 9.3 [ms] Topology Generation Control Channel Res. After Disconnection Before Disconnection 17 •  Restoration time is under 300 [ms] •  Latter two cases take longer restoration time. •  More nodes in the topology may impact on OSPF stabilization Experimental Evaluation › Scenario 1
18. [13] S. Knight, H. Nguyen, N. Falkner, R. Bowden and M. Roughan, “The Internet Topology Zoo,” IEEE Journal on Selected Areas in Communications, vol. 29, no. 9, pp. 1765–1775, Oct. 2011. [14] The University of Adelaide, “The Internet Topology Zoo,” http://www. topology-zoo.org/, last accessed at 21 Oct. 2014. From Topology Zoo [13][14] 18 Feasibility (validity) Works with multiple, unexpected link failure •  Real-world topology from Topology Zoo[13][14] •  36 nodes, 76 links •  1 controller (with highest deg.) •  35 switches •  Measured time: Against link failure rate, •  # of controller- reachable switches •  Network restoration time Experimental Evaluation › Scenario 2
19. Experimental Evaluation › Scenario 2 •  Network restoration time goes the peak, approx. 13 [s] where link disconnection rate is 40% •  Network Restoration Time •  Controller-Reachable Switches 19 0 10 20 30 40 50 60 70 80 90 100 Link  failure  rate  [%] 0 2 4 6 8 10 12 14 16 Network  restoration  time  [s] 0 10 20 30 40 50 60 70 80 90 100 Link  failure  rate  [%] 0 5 10 15 20 25 30 35 40 #  of  controller-­reachable  switches
20. Conclusion • We Add SDN the resiliency agaist multiple link failure •  Through adding SDN switches a self-healing module (CCMM) •  Design of CCMM •  (1) monitors link status (2) exchange topology map and (3) establish new control channel via alternative path •  Implementation of CCMM •  Simple and practical application of OSPF with our Flow Entry Installer •  Experiments of CCMM 1.  Validity: Works on any type of control channel 2.  Performance: ≦ 300 [ms] in the small topology, 13 seconds in the large, real-world topology. •  Future Work •  Further analysis on experimentation (OSPF tuning, etc…) •  Further extension for split-domain (where no path to the controller is available) 20
21. APPENDIX A: SDN 21
22. Architectural  Comparison Control  Plane   Data   Plane   Data   Plane   Data   Plane   Control   Plane   Control   Plane   Data   Plane   Data   Plane   ApplicaMons   Switch   Switch   Switch   Switch   Switch   Controller   ConvenMonal  Architecture   SDN  Architecture   Control  Channel   Northbound  API   Southbound  API   22
23. SDN Switch Design Physical  Ports   Flow  Table   To  the  Controllers   Control  Channel   End  point   Datapath   Matching Rule 1 Action(s) 1 Matching Rule 2 Action(s) 2 … … 23
24. SDN Switch-Controller Connection 24 Controller   Switch   Switch   Indirect  (In-­‐band)   Direct(Out-­‐of-­‐band)  
25. SDN and OpenFlow 25 Switches Controllers Applications Northbound API Southbound API (OpenFlow protocol) SDN OpenFlow
26. Comparison of Traditional Arch. vs O.F. Arch. 26 Data plane Control plane •  Collecting Topologies •  Generating Routing Entries •  etc… •  Forwarding Packets Switch
27. Comparison of Traditional Arch. vs O.F. Arch. 27 Data plane Control plane Switch OpenFlow protocol / TCP or TLS or UDP or DTLS Controller •  Collecting Topologies •  Generating Routing Entries •  etc… •  Forwarding Packets
28. OpenFlow Controller OpenFlow (Logical) Switch Control Channel Datapath OpenFlow Protocol 28
29. OpenFlow Controller OpenFlow (Logical) Switch Control Channel Datapath OpenFlow Protocol FlowTable( s) GroupTabl e Port(s) OpenFlow Protocol (must) ------------------------- TCP / TLS / UDP / DTCP (any of these OpenFlow Channel 29
30. OS Protocol Stack OS Protocol Stack OpenFlow Controller OpenFlow (Logical) Switch Control Channel Datapath 30
31. APPENDIX B: SDN’S RELIABILITY 31
32. Reliability  of  Control  Plane   Reliability  of  Data  Plane   Reliability  in  SDN Switch   Switch   Switch   Controller   Control  Channel   32
33. 既存研究 33 •  SDNの信頼性向上について •  切断の防止という観点 •  あらかじめ用意したバックアップコントローラへ切替 [4][5] Controller Switch Controller [4] P. Fonseca, et al., “A replication com- ponent for resilient openflow-based networking,” IEEE NOMS, 2012. [5] Kuroki, et al., “OpenFlow Controllerの冗長化に関する検討”, 電子情報通信学会 ネットワーク仮想化時限研究専門委員会 第5回専門 委員会, 2013.
34. 既存研究 34 •  SDNの信頼性向上について •  切断の防止という観点 •  あらかじめ設定したバックアップ経路へ高速切替 [6][7][8] Controller Switch [6] S. Sharma, et al., “Openflow: meeting carrier-grade recovery requirements,” Computer Communications, 2012. [7] N. L. M. van Adrichem, et al., “Fast recovery in software-defined networks,” IEEE EWSDN, 2014. [8] A. Sgambelluri, et al., “Openflow-based segment protection in ethernet networks,” IEEE/OSA JOCN, 2013.
35. 既存研究 35 •  SDNの信頼性向上について •  切断からの回復という観点 •  バックアップ経路を自動セットアップ [9] [9] S. Sharma, et al., “Fast failure recovery for in-band openflow networks,” IEEE DRCN, 2013. Controller Switch Switch Switch Switch ✗
36. 既存研究 36 [10] 水越, et al., “B-6-7 モバイルネットワークの動的再構成(1) : 大規模災害時における移動通信網の動的トラヒック制御方式の検討(B-6. ネットワークシステム,一般セッション)”, 電子情報通信学会ソサイエティ大会講演論文集 2012年(通信_2), 2012.
37. APPENDX C: IMPLEMENTATION 37
38. Design of CCMM-enabled switch Physical(Ports( Switch(Design( Flow(Table( Control(Channel( End(point( Control(Channel( Maintenance(Module( Neighboring( CCMMs( Controllers( (3)( 3)(Installs(Flow(Entries( 1)(Monitors(Link(Status( 2)(Exchanges( ((Network(Topology(Map( (1)( (2)( S( M( S( M( S( M( C( (1)(Heartbeat( (2)(Topology(Map
    38
39. Implementation of CCMM-enabled switch ΠϝʔδΛදࣔͰ͖·ͤΜɻϝϞϦෆ଍ͷͨΊʹΠϝʔδΛ։͘͜ͱ͕Ͱ͖ͳ͍͔ɺΠϝʔδ͕ഁଛ͍ͯ͠ΔՄೳੑ͕͋Γ·͢ɻίϯϐϡʔλʔΛ࠶ىಈͯ͠࠶౓ϑΝΠϧΛ։͍͍ͯͩ͘͞ɻͦΕͰ΋੺͍ x ͕දࣔ͞ΕΔ৔߹͸ɺΠϝʔδΛ࡟আͯ͠ૠೖ͍ͯͩ͘͠͞ɻ 39
40. Switch Implementation: Internal Ports Normal  SituaMon   OSPF daemon Physical Ports Interfaces Seen by applications With  Open  vSwitch  SituaMon   OSPF daemon Physical Ports Interfaces Seen by applications Bridge (Open vSwitch Bridge) OSPF daemon cannnot handle each ports separately 40
41. Switch Implementation: Internal Ports With Open vSwitch Situation (Fixed) (1)   OSPF daemon Physical Ports Interfaces Bridge ・Create the same number of Internal Ports With Open vSwitch Situation (Fixed) (2)   OSPF daemon Physical Ports Interfaces ・Insert OSPF-passthrough flow entries 41
42. 実装 •  実装上の特記事項 •  フロー制御タイミングを常時とした •  切断検知後の場合、ブートストラップ(通知・状態同期)が必要になり複雑化 •  また、ブートストラップにも時間がかかり、復旧時間の悪化が想定される •  SDNスイッチとOSPFデーモンソフトウェアを共存させるための設計 •  内部ポートの応用 •  パススルーフローエントリの制御(ARP+OSPF) •  OSPFデーモンの吐き出した経路表が ノード上のアプリケーション(含SDNスイッチの制御リンク)経路制御に 影響を及ぼさないための設計 •  マルチプルルーティングテーブルの適用 •  経路表のフローエントリへの変換と制御 •  挿入タイミングの計算 (ルーティングテーブルの監視) •  フローエントリへの変換処理 •  ARPテーブル + ルーティングエントリの参照 •  フローエントリの挿入 42
43. APPENDIX D: EVALUATION 43
44. Experimental Evaluation with Mininet Host Linux Node LXC Controller Controller Interface OSPFd LXC Switch (OvS) Flow Installer Switch 1 OSPFd LXC Switch (OvS) Switch n OSPFd 44 TC Link Flow Installer ・Creates Network Topology ・Manages Nodes Mininet
45. 実験環境 •  実機エミュレーション環境を用いた •  柔軟な設計・実装の変更 •  大規模なデプロイ •  Mininetをフレームワークに独自実装 •  SDNスイッチとOSPFデーモンを動作させるために スイッチに特別な改造を施した •  これにより、Mininetについても リンクの切断処理に特別な改造を施した •  全スイッチノードにおいて以下を行うシナリオプログラムを作成 •  SDNスイッチの設定ファイル生成・起動 •  OSPFデーモンの設定ファイル生成・起動 •  フローエントリ生成プログラムの起動 •  制御チャネル復旧時間測定プログラムの設定・起動 45
46. 実験 › 小規模シナリオ 46 •  切断ケースごとに性能をみることが主眼 •  3種類の切断ケースを用意 •  切断時刻を0とし、以下の時間を測定 •  トポロジマップ生成時刻 •  フローエントリ挿入開始時刻 •  フローエントリ挿入終了時刻 •  制御チャネル復旧時刻 •  制御チャネルの再接続について、ログを監視
47. 実験 › 小規模シナリオ 47 •  ベースとなるトポロジ •  4ノード(1コントローラ、3スイッチ)、6リンク
48. 実験 › 小規模シナリオ 48 •  Out-to-in ケースの結果
49. 実験 › 小規模シナリオ 49 •  In-to-in ケースの結果
50. 実験 › 小規模シナリオ 50 •  In-to-in-middle ケースの結果
51. An example timeline of the restoration on Large Topology Scenario 00 01 02 03 04 05 06 07 08 09 10 11 12 13 Time from link down [s] 0 5 10 15 20 25 30 35 # of restored switches 0.0 0.2 0.4 0.6 0.8 1.0 Ratio of restored switches to total switches 51
52. An example topology after disconnection on Large Topology Scenario 25 26 27 28 21 22 23 24 29 30 2 1 4 3 6 5 8 7 10 9 12 11 14 13 16 15 18 17 20 19 32 31 36 35 34 33 52
53. Another example topology after disconnection on Large Topology Scenario 25 26 27 28 21 22 23 24 29 30 2 1 4 3 6 5 8 7 10 9 12 11 14 13 16 15 18 17 20 19 32 31 36 35 34 33 53
54. APPENDIX E: FURTHER EXTENSION OF CCMM 54
55. 拡張と追実験 (1/4) •  大規模トポロジ、高いリンクダウン率において、 ドメインが分割されるケースが散見された 55 S   Before  Links  are  Disconnected   Reachable  domain   Controller   Switch   S   C   C   S   S   S   S   S   S   S   C   S   S   S   S   S   S   ✗ ✗ Unreachable  domain   Unreachable  domain   A9er  Links  are  Disconnected  
56. 拡張と追実験 (2/4) •  CCMMはフローエントリを制御する能力がある •  拡張すれば、コントローラとして用いることが出来るのではないか？ •  切断されたドメイン内の緊急的な代替コントローラとして用いる •  拡張 •  (1) コントローラとしてのインタフェイスを備える •  (2) ドメイン内のスイッチ群から代替コントローラを選出 •  (3) スイッチに、代替コントローラへの再接続を指示 56
57. 拡張と追実験 (3/4) •  実現可能性の検証 •  切断されたドメインにて、 スイッチ群が代替コントローラに集約されるかを検証 57 3   1   ϦϯΫ੾அલ   2   ɾϦϯΫ੾அޙ   Controller   Switch   CCMM   S   C   M   M M M C   3   1   2   M M M C   ✗  
58. 拡張と追実験 (4/4) •  結果 •  適切に全スイッチが集約されることを確認 •  復旧時間は 1618 ± 499 [ms] 58
59. APPENDIX F: DISCUSSIONS 59
60. 考察 (1/4) •  CCMM–Controller Coordination Problem •  SDN Domain-Splitting Problem •  SDN Bootstrapping Problem 60
61. 考察 (2/4) •  CCMM–Controller Coordination Problem •  SDNでは、コントローラはネットワークを掌握する必要がある •  CCMMはフローエントリを制御する •  CCMMとコントローラの協調機構が必要 •  どのアドレス空間をOSPF用に用いてよいか •  どのフローテーブルを制御してよいか •  どのようなフローエントリが編集されたか 61
62. 考察 (3/4) •  SDN Domain-Splitting Problem •  コントローラへの接続性を完全に失うドメインが出現 •  緊急的な代替コントローラとしてCCMMが応用可能 •  代替コントローラの選出アルゴリズムが重要となる •  Hellerらは、平均往復時間が最小となるノードを選出する手法を提案 [11] •  また、アプリケーションとの協調機構も重要 62 [11] B. Heller, et al., “The Controller Placement Problem,” ACM SIGCOMM Computer Communication Review, vol. 42, no. 4, pp. 473–478, Sep. 2012.
63. 考察 (4/4) •  SDN Bootstrapping Problem •  「スイッチをコントローラに接続する前、 どのようにスイッチをコントローラに接続するよう設定するか？」 •  SDN標準化のひとつ、OpenFlowでは、仕様の範囲外 •  CCMMは自律的・自動的なフローテーブルの制御が可能 •  →本問題への応用が可能 •  ただし、一般的なOSPFの設定は依然必要 63
64. MISC 64
65. Implementation of ResilientFlow: Overview •  Underlying Environment •  SDN Protocol and Standardization •  Most widely adopted OpenFlow •  SDN Switch •  Linux based Open vSwitch •  CCMM Functionality and its implementation •  (1) Disconnection Detection 　　 through Heart-beat exchange •  (2) Topology Exchanging and Calculating Alternative Path •  (3) Establishing New Control Channel by Modifying Flow Entries 65 Link-State Routing Mechanism represents the same behaviour; We apply Quagga OSPFd Implement our Flow Installer using Python
66. •  ネットワークエミュレーションソフトウェア: Mininet [6] •  単一のLinux ノード内に仮想的な軽量コンテナで構築した ネットワークを用いた実験が可能 •  実験のための拡張事項 •  ネットワーク機能を独立にした仮想コンテナの立ち上げ •  外部ポートと内部ポートを連動させたインタフェースのアップダウン •  評価手法 •  コントロールチャネル切断からの復旧時間を測定 •  コントロールチャネルを通じて行う通信であるPacket-inを十分短い時間間隔で送信 •  リンク切断からコントローラでのPacket-in受信再開までの時間を復旧時間と定義 •  Packet-inの送信にはNping・受信コントローラにはRyuを用いた実装を利用 評価実験 ― 評価手法 ― 2015/3/10 ిࢠ৘ใ௨৴ֶձ ૯߹େձˏ૲௡ 66 [6] Mininet Team, “Mininet: An Instant Virtual Network on Your Laptop (or Other PC) ― Mininet,” http://mininet.org/. S C S C S C
67. 評価実験 ― プロトタイプ実装および評価環境 ― 2015/3/10 ిࢠ৘ใ௨৴ֶձ ૯߹େձˏ૲௡ 67
68. 設計 目的: ・制御チャネルの自律復旧 必要な機能: (1)経路計算のため、 　・トポロジ情報の交換 (2)切断検知のため、 　リンク状態の監視 　　　　↓ (3) 切断時に 　フローエントリ編集し 　制御チャネルを確立 CCMM(Func=onality(1( S( M S( M He’s(alive
    CCMM(Func=onality(2( S( M S( M CCMM(Func=onality(3( S( M S( M S( M ✗( ✗( ✓( C( Control(Channel( via(new(path
    68 (3) (2) (1) 2015/3/10 ిࢠ৘ใ௨৴ֶձ ૯߹େձˏ૲௡
69. 機能: (1)リンク状態の監視 (2)トポロジの交換と経路計算 (3)フローエントリの生成・制御 (制御タイミングの計算含) 実装: (1)(2): 通常の LS型経路計算手法と同等 → OSPFが適用可能 (3): 必要な情報収集と 　　　フローの計算 → 新規に実装 (挿入タイミングは常時) 実装 実装上の特記事項は論文を参照 69 CCMM(Func=onality(2( S( M S( M CCMM(Func=onality(3( S( M S( M S( M ✗( ✗( ✓( C( Control(Channel( via(new(path
    (3) (2) CCMM(Func=onality(1( S( M S( M He’s(alive
    (3)  ৽نʹ࣮૷   (1) (1)  (2)  OSPF  Λར༻   2015/3/10 ిࢠ৘ใ௨৴ֶձ ૯߹େձˏ૲௡
70. ResilientFlowの実装 ― 実装上の特記事項 ― •  内部ポートと外部ポート •  外部の物理的なポート （外部ポート）はOpen vSwitchの傘下に置かれる •  OSPF側で外部ポートを 動作対象ポートとして 設定不可 •  外部ポートと同数の 内部ポートを用意し対応 •  外部ポートと対応する内部 ポートの通信は透過できる ようなフローエントリの設定 2015/3/10 ిࢠ৘ใ௨৴ֶձ ૯߹େձˏ૲௡ 70 Linux  ϊʔυ   ϑϩʔΤϯτϦ   ొ࿥ϓϩάϥϜ   Linux  Χʔωϧ   ܦ࿏ද   OSPFσʔϞϯ   (Quagga  OSPFd)   Open  vSwitch   ܦ࿏දͷੜ੒   ܦ࿏දͷऔಘ   (ip-­‐monitor)   ϑϩʔΤϯτϦͷ   ొ࿥  (ovs-­‐ofctl)   ֎෦ϙʔτ   ಺෦ϙʔτ   ϦϯΫঢ়ଶͷ؂ࢹ  (Hello)   τϙϩδ৘ใͷऩू  (LSA)  
71. その他特記事項 ― Mininetスクリプトの動作 ― •  トポロジファイルの読み込み •  Topology Zoo上のGraphMLファイルを使用 •  スイッチとコントローラの立ち上げ •  各スイッチとコントローラのインスタンスを構成 •  設定ファイルの生成とデーモンの起動 •  Open vSwitchの起動コマンド列 •  内部ポートの生成とOpen vSwitchへの割付け •  Quagga ospfd/zebraの設定ファイルをインタフェースリスト等から自動生成 •  事前フローエントリ挿入 •  Quagga OSPF用のOSPF送出・受信用フローエントリ •  上記に関係するARP送出・受信用フローエントリ •  CCMMにおけるフローエントリ登録プログラムの起動 •  OpenFlowプロトコル送出・受信用フローエントリ •  実験用フローエントリの追加 •  nPingで生成したパケットをPacket-inとしてコントローラに流すエントリ 2015/3/10 ిࢠ৘ใ௨৴ֶձ ૯߹େձˏ૲௡ 71