Reusability of So/ware- Defined Networking Applica=ons: A Run=me, Mul=- Controller Approach

Transcription

1 Reusability of So/ware- Defined Networking Applica=ons: A Run=me, Mul=- Controller Approach Roberto Doriguzzi Corin (CREATE- NET), Pedro A. Aranda Gu=érrez (Telefonica), Elisa Rojas (Telcaria), Holger Karl (Paderborn University), Elio Salvadori (CREATE- NET) 12th Interna+onal Conference on Network and Service Management (CNSM) Montreal, Quebec, Canada, Oct. 31, 2016

2 Mo=va=ons So/ware- Defined Networking promises to overcome vendor lock- in by enabling a mul=- vendor hardware and so/ware ecosystem in operator networks. However, we observe that this is currently not happening as......different open and closed- source SDN plaworms exist (e.g. OpenDaylight, ONOS, Ryu, Floodlight, etc), all with different Northbound Interfaces (NBI) This causes network applica=ons to depend on the NBI implemented by the SDN plaworm they are wri]en for. Which, in turn, causes similar vendor lock- in for SDN users as they had with network equipment vendors before moving to SDN. Por+ng SDN control applica+ons between SDN plajorms is a desirable target. CNSM

3 virtual Data Centre use case: scenario 1 The system administrator may require to change SDN plaworm. CNSM

4 virtual Data Centre use case: scenario 2 The system administrator may require to ac=vate new network services to the vdc. CNSM

5 virtual Data Centre use case: discussion Two op2ons: Implemen=ng the SDN modules from scratch Re- use exis=ng SDN modules Possible issues: 1: third- party modules may or may not meet all the requirements 2: integra=on of new modules with the exis=ng Network Applica=on is not straighworward 3: What if the exis=ng modules are wri]en for a different SDN controller? CNSM

6 Driving concept: Wine compa=bility layer [1] Running MS Windows applica=ons under Unix- based opera=ng systems (Linux, BSD, OS/X) Emulates a Win32 environment and provides the applica=ons the APIs they expect Translates Windows API calls into Unix calls at run=me [1] h]ps://wiki.winehq.org/wine_developer%27s_guide/architecture_overview CNSM

7 Proposed framework: the NetIDE Network Engine The Backend is an addi=onal SBI for the client controller that interacts with the Coordinates underlying layers SDN modules of the Network based on Engine a via composi=on NetIDE API. specifica=on (XML file) Handles the asynchronous events from the network, such as new flows, port status, etc. The Shim is an applica=on for the Server Controller Composes which the configura2on translates the messages Northbound API generated into NetIDE by the API, SDN exposing modules it to and the checks Network them for Engine. conflicts CNSM

8 Back to the virtual Data Centre use case Scenario 1 Scenario 2 CNSM

9 Composi=on Parallel composi=on Collects all commands and resolves conflicts Composi=on is done only a/er all commands are received Sequen=al composi=on One module is fed with the output of a previous module Covers only a subset of scenarios due to the limita=ons of the OpenFlow protocol. CNSM

10 The FENCE mechanism An applica=on module may respond to a given network event (e.g., an OpenFlow PACKET_IN) with a set of zero, one or mul=ple network commands (e.g., OpenFlow FLOW_MODs and PACKET_OUTs). The FENCE mechanism is a means for the Core to correlate events and commands and to know when the module has finished processing the input event. CNSM

11 Evalua=on Addi=onal latency introduced by the Network Engine on the control channel The latency is generated by message serializa=on/de- serializa=on and by the composi=on/conflict resolu=on CNSM

12 Serializa=on/de- serializa=on Methodology One SDN module 40 new flow/sec No composi=on Overhead on each flow setup Ryu- Ryu 1.79ms Ryu- FL 1.76ms ONOS- Ryu 2.69ms ONOS- FL 2.81ms ODL- Ryu 2.59ms ODL- FL 2.57ms CNSM

13 Parallel composi=on Methodology One SDN module Ryu client controller Ryu server controller 40 new flow/sec Overhead on each flow setup 350μs on average CNSM

14 Sequen=al composi=on Methodology One SDN module Ryu client controller Ryu server controller 40 new flow/sec Overhead on each flow setup 1.25ms on average CNSM

15 Conclusions Take- home messages: Rapid deployment of exis=ng SDN applica=ons on opera=onal networks Complex chains of heterogenous SDN applica=ons Performance penalty that can be tolerated when considering the effort that would be needed to re- implement all modules for a different controller framework Ongoing work: BigFlowtable (proac=ve flow rules), collabora=on with the ONF Englewood project for applying conflict resolu=on to Transport API applica=ons CNSM

16 Thanks!! Ques=ons? net.org