An Approach to Exposing and Sharing Network Services in. Software-Defined Networking*. R. Doriguzzi-Corin, E. Salvadori, M. Gerola, M. Santuari.
An Approach to Exposing and Sharing Network Services in Software-Defined Networking* R. Doriguzzi-Corin, E. Salvadori, M. Gerola, M. Santuari CREATE-NET, Trento - Italy
{rdoriguzzi, esalvadori, mgerola, msantuari}@create-net.org
1.
INTRODUCTION
The ecosystem of SDN controllers and programmable devices is extremely fragmented: a number of controller platforms and companion tools is available, each of them based on a very different set of features. Moreover, most of the SDN controller frameworks provide a limited set of functionalities to applications that can be deployed on top (usually leveraging on a set of northbound APIs). The selection of a certain controller platform to develop applications tailored to some network-specific requirements can be an extremely difficult task since each framework has its own strengths and weaknesses. While platforms like Ryu, Floodlight and Beacon are aimed at facilitating the rapid prototyping of SDN applications, others frameworks are less agile but provide a much richer environment: OpenDaylight [2] includes a Service Abstraction Layer which provides a large collection of dynamically pluggable modules to perform several network tasks; ONOS (Open Network Operating System) [3] defines a set of subsystems providing several primary services available for the network applications. In such a scenario, a network administrator who operates an infrastructure leveraging on a number of applications running on top of some SDN framework may likely bump into the dilemma of getting “locked-in" within such a framework or disrupting everything (i.e. re-implement all the applications from scratch) in case she plans to evolve toward more features-rich platforms. Finding effective solutions to address this unpleasant situation is one of the major goals of an European research project called NetIDE [1]. Within such project, several architectural solutions are being investigated to remove such lock-in effect happening at controller level. Among them, one of the most viable one leverages on a compatibility layer, called Network Engine [4], that allows network applications written for certain controller platforms to be re-used “as is” on top of alternative platforms. However, while in [4] the overall architecture is described and a preliminary version is discussed, in this demo we have extended the usage of the Network Engine to show how it can be exploited to empower (virtually) any SDN platform with the advanced functionalities offered by other frameworks. In particular, we will show how applications developed for Ryu controller can be effectively executed on top of ONOS, while inheriting some of the enhanced features enabled by this emerging framework.
2.
PROPOSED ARCHITECTURE
As shown in Fig. 1, the proposed architecture consists of three main layers: (i) the Server Controller layer, represented by ONOS, which drives the network and provides advanced services such as redundancy, topology management, etc., (ii) the Client Controller *This work is partially supported by the EU FP7 NetIDE project [1], grant agreement 619543.
Figure 1: Software architecture. layer where the applications that control the network traffic are executed and (iii) the Network Engine that acts as “glue” between these two layers. The proposed architecture follows the layered SDN controller approach proposed by the Open Networking Foundation. It integrates a Client Controller layer that executes the modules that compose a Network Application and interfaces with a Server SDN Controller layer that drives the underlying infrastructure. Fig. 1 highlights some of the internal components of the Network Engine. The Backend and the Shim Layer, implemented by using controller-specific libraries and APIs1 , allow the interaction between Client and Server controllers through an application layer protocol on top of TCP. On the other hand, the Core Layer is a platform–independent component that implements the Network Engine’s core functions with the purpose of minimizing the complexity of the two aforementioned controller-specific components, the Backend and the Shim Layer, and of reducing the implementation burden each time a new platform needs to be supported by the Network Engine. The Core Layer interfaces to supplementary tools that allow the inspection/debugging of the control channel and the management of the network resources, and coordinates the multiple Client Controllers that may run in parallel on top of the Network Engine. ONOS is a distributed system designed primarily for scalability and high-availability. ONOS runs in the so-called “multi-instance” mode, where one or multiple instances of ONOS (an ONOS cluster) 1 The Backend is an additional module for the Client Controller while the Shim is an application for the Server Controller
run the same set of modules, share the network state and each instance acts as the exclusive master controller for a subset of switches. ONOS leverages on Apache Karaf [7], a java OSGi based runtime, which provides a container onto which various components, such as the proposed Shim Layer, can be deployed. ONOS also provides several additional commands accessible from the Karaf Command Line Interface to do state checks, debugging and to install new flow rules and intents.
3.
DEMONSTRATION
The demo setup consists of a ONOS cluster running on top of a network simulator (Mininet). As illustrated in Fig. 2, the cluster is composed of two instances of ONOS (acting as Server Controllers), each of them executing the Shim layer in form of an OSGi bundle with the upper layers on top of it (the Backend and the Client Controller). As can be noticed, different colors are used to highlight that each instance acts as master controller for a subset of switches, although the switch mastership may be different during the execution of the demonstration. For this demo, the Network Engine includes Ryu as Client controller with its Backend layer underneath, while the services provided by the Core Layer are not used. In our demo scenario, the network driven by the ONOS cluster is logically composed by a Protected Zone (a common Local Area Network (LAN)) and by a Demilitarized Zone (DMZ) which includes one Network Element acting as a firewall and one web server (WWW in Fig. 2). Hosts in the Protected Zone (BOB and Charlie in the figure) can freely communicate with each other, access the Internet and browse the content available on the internal web server. Traffic from the Untrusted Zone can access the web site but not the rest of the LAN. This scenario is implemented with a Network Application for Ryu composed of two sub-modules: a learning switch and a firewall/router. With this demo setup we aim at demonstrating two different concepts: (i) the Network Engine allows non-distributed frameworks such as Ryu to leverage on ONOS services in order to implement a distributed and fault-tolerant SDN architecture (Fig. 2(a) and 2(b)); (ii) referring to Fig. 2(c), the Network Engine allows applications written for different SDN platforms to cooperate on managing the network traffic. The demonstration is executed in three steps: (a) First we demonstrate how each of the two Ryu instances correctly detects the entire network topology, including the nodes that are not under direct visibility and influence of the respective ONOS instance. This global view is delivered by the ONOS Topology Management system that aggregates and synchronizes the portions of the topology discovered by each instance. (b) Then, we stop one instance of ONOS in order to demonstrate how the Ryu application running on top of other instance takes the full control of the network and the hosts can continue communicating without disruption and the access rules are still applied.
4.
(c) As an additional step of the demonstration, we show how the applications written for different controller platforms running on top of the Network Engine can coexist with the native services and applications of the Server Controller. In this scenario, we replace the learning switch module written for Ryu with native ONOS applications and flow rules or host-intents installed from the ONOS CLI. However, for preserving the security of the LAN, we decide to keep our “reliable” Ryu firewall application.
[1] “NetIDE web site.” [Online]. Available: www.netide.eu [2] “OpenDaylight.” [Online]. Available: www.opendaylight.org [3] P. Berde, M. Gerola et al., “ONOS: Towards an Open, Distributed SDN OS,” in Proceedings of HotSDN, 2014. [4] R. Doriguzzi Corin et al., “NetIDE: Removing Vendor Lock-in in SDN,” in Proceedings of NetSoft, Apr 2015. [5] “Ryu.” [Online]. Available: osrg.github.com/ryu [6] “Floodlight.” [Online]. Available: www.projectfloodlight.org [7] “Apache Karaf.” [Online]. Available: karaf.apache.org
Figure 2: The three steps of the demonstration.
REFERENCES
