Home
Welcome to the ZeroSDN wiki!
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.
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
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.
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.
See Crosscompiling_for_ARMRaspberry_Pi
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.