Skip to content
AndreKutzleb edited this page Nov 10, 2015 · 105 revisions

Welcome to the ZeroSDN wiki!

What is ZSDN?

Zero Software Defined Networking (ZSDN) is a component based SDN controller. The software is fully distributed which means there are no central instances that control the whole network. Instead it consists of multiple modules that are connected by a ZMQ (see http://zeromq.org) message BUS. The communication between modules is handled with google protobuffers. The execution of each module is controlled by an instance of the Zero Module Framework. Currently there exist two versions of this framework: The ZMF which was written in C++ and the JMF which was written in Java. Both of them support the OpenFlow versions 1.0 und 1.3.

ZSDN is published under the Apache License Version 2.0.

Why another SDN-Controller?

We felt that many controllers are either too monolithic, too hard to understand, or not scalable enough.

This is why we created a controller that:

  • Can run on any hardware (Raspberry Pi, Cloud environment, even on SDN switches themselves)

  • Is language independent (currently Java and C++ supported)

  • Can be easily understood and extended.

  • Is highly modularized: every functionality in ZSDN is a single artifact running independently, no matter if on the same machine or distributed: there is no huge monolithic controller instance.

  • Filters events on the sender side: Using hierarchical topic-based subscriptions, we avoid unecessary event-delivery. This includes the Switch itself. If no one wants to receive e.g. UDP packets, the Switch will not even forward them anymore.

  • Outperforms other SDN-controllers: ZSDN won't beat every controller when running locally only, however, we were able to perform very well when scaling out (Tested using CBench, Throughput mode):

ZeroSDN StartUpSelector initial screen

Overview

The ZSDN ModuleFramework controls the execution of a ZSDN module and connects it to the ZSDN system via ZMQ. The ZMF is used by controller modules and switch adapter modules.

An overview of the existing modules can be found here: ZSDN Modules

Installation

Prerequisites

  • Install cmake

  • sudo apt-get install software-properties-common

  • sudo add-apt-repository ppa:george-edison55/cmake-3.x

  • sudo apt-get update

  • sudo apt-get install cmake build-essential

  • Install Java 8

  • sudo add-apt-repository ppa:webupd8team/java

  • sudo apt-get update

  • sudo apt-get install oracle-java8-installer

  • Install Maven

  • sudo apt-get install maven

  • Install Mininet

  • sudo apt-get install mininet

  • Install Git

  • sudo apt-get install git

  • Clone Git Repository

  • git clone https://github.com/zeroSDN/ZSDN-Controller.git

Setup

Once you have downloaded or cloned the ZSDN repository to your local machine, switch to its root directory and run the init-zsdn.sh script. You can do this by opening an console in this folder and type the following:

./init-zsdn.sh 

This starts the installation process of ZSDN which may take some time. When the installation was successful you may run also the build-all.sh script at any time, which rebuilds the executables of the most important project and stores them to the /build directory. They can be used afterwards either by starting them manually via console oder by using our quick start tool.

Quick Start

We provide a start-up tool with which you can easily start and stop instances of ZSDN modules. You can find the executable under "util/startup-selector/target". Once the program is started you should see the UI with the following functions:

ZeroSDN StartUpSelector initial screen

1. Load Modules
Here you can specify a path to a folder from which then all executables of ZSDN Modules are loaded into the application recursively (lists also modules in subdirectories).

2. Add
If you click the button 'add' you also have the possibility to add another module to the list manually. You need to add the additional information, e.g. path to the module, on your own. For details see also how to edit an existing module.

ZeroSDN StartUpSelector initial screen

3. Edit
In the picture above you can see the windows that appears if you want to edit existing module. It looks the same if you want to add a new one. As you can see you can add/change here the following configurations:

  • Module Name: The name the module should carry, for example 'SwitchAdapter'.
  • Description: Here you may add a description of this module that is displayed in the tool afterwards.
  • Path: The path to the folder containing the compiled executable of the module. If you add modules via 'Load Modules', this is filled in automatically.
  • Config File: Every modules needs a config text file which contains the specified configuration the module should be started with. You can find a default config file under "/ZSDN-Controller/config/default.config".
  • Additional Parameters: Your module may need to be started with some additional parameters. You can add theme here, each separated by ' '(space). If you wish no additional parameters, you can leave this field empty.

4. Remove
Here you can remove an existing module from the list.

5. Start All
Press this button to start all modules that are currently in the list. If starting was successful, they will change their state from 'Stopped' to 'Running'.

6. Stop All
This shuts down every module that is currently running. Their state should then change from 'Running' to 'Stopped'.

7. Start
This starts the specific module that you have selected from the list on the left side. Once it is running, you can see it's console- and logging output in the area above.

8. Stop
This shuts down the selected module. You should see a message in the output area that the module has been stopped after you pressed this button.

Saving the list
Additionally you can save the current module list over the File menu on top. It will be saved as an xml file which can be loaded again the next time you start the application.

How to create a module list:

  • Click on "Load Modules" and select a directory containing the modules.
  • Then select the modules in the module list on the left side.
  • Click on "edit"
  • You need to select a config file in order to run a module. We provide a example config file under "/examples/example-configs/zmf_module.config"
  • If needed, also add parameters separated by a blank (e.g. for SwitchAdapter "1.3 6633" for OpenFlow version and port)
  • If you selected a config file and possible parameters, you now can start the module
  • You can also save the created module list by clicking on "File" at the menu bar. You then can save it as a .xml file

Working With ZSDN

Structure Of The Framework

ZeroSDN StartUpSelector initial screen

As the figure shows, the framework consists of several units: the ZMFCore, which encapsulates the main functionality of the framework such as starting and stopping of modules. Also it provides an interface that modules can use for accessing the framework and for connecting to other modules through it. These modules are always derived from the AbstractModule-class.

Furthermore, the ZMFCore controls the execution of two more essential services that are started and stopped with an instance of the ZMF. The first is called the PeerDiscoveryService which subscribes to a multicast group in the network to which all other ZMF instances also subscribe. The service frequently sends out so called heartbeats in form of udp-multicast messages. This way every instance of the ZMF knows about all other module instances that are available at this time and what state the currently have.

The ZMQMessagingService provides functionality to modules that can be used for sending direct ZMQ request messages to other modules and for receiving their replies in the same way. It can also be used to publish ZMQ messages to a certain topic or to receive messages from other modules through a preceding subscription to this topic.

Module applications call the run method of the ZMF framework (eg. from the main method) to start the ZMF instance.

For further information about ZMF see ZMF Wiki.

How to write a Module

See How-To-Write-a-Module

Working with Eclipse

As the JMF requires Java 1.8 you should be using Eclipse Luna or newer, since Luna supports Java 1.8 out of the box. The Java parts of the ZSDN should be imported into Eclipse as Maven projects in the following order: JMF -> zsdn-proto -> RESTAdminModule. This will guarantee the dependencies referencing each other properly.

Cross Compilation

See Crosscompiling_for_ARMRaspberry_Pi

Support

If you need help, don't hesitate to contact us: [email protected]

Participate

You have own ideas or plans concerning ZSDN? Share them with us! Under the following links you may commit your pull requests:

ZMF: https://github.com/zeroSDN/ZMF/compare

JMF: https://github.com/zeroSDN/JMF/compare

ZeroSDN: https://github.com/zeroSDN/ZSDN-Controller/compare

If you are new to github, read here about how to use a pull request:

https://help.github.com/articles/using-pull-requests/

Future Work

ZSDN was created from the ground up in 6 Months. Not all features present in other Controllers are implemented for ZSDN yet.

  • Support for VLAN tags:
    Right now, the SwitchAdapter deduces the packet type (and therefore, the topic it will publish the packet on) by looking at specific fields in the packet. Right now, VLAN-tagged packets confuse this system, as they come before the Ethernet frame, which is the position where the SwitchAdapter normally looks for the Ethertype of an EthernetII frame. Additionally, if the SwitchAdapter would publish packets having VLAN tags prepended, all packet-receiving modules would have to take VLAN-tags into account.

  • Java packet inspection and OpenFlow libraries:
    Currently, the java modules do not come with any packet inspection or OpenFlow libraries. For OpenFlow Java support, we highly recommend the Loxigen API - it is very easy to use. We use the C-variant of this API for all OpenFlow related tasks. Floodlight itself also has Code for packet inspection in Java, which would also be a good place to start if you do not want to use your own Java packet inspection library. (For C++, we currently use Libtins)

  • Event Chains
    By defining topics in a certain way, chain processing can be achieved - modules could republish events, ever-increasing a certain number in the topic, and other modules would listen to their position in that chain,e.g. ModuleA.event().chain_position(0) -> ModuleB.event().chain_position(1) etc.