Fresh Take

The Open Network Operating System (ONOS) [1] is a software-defined networking (SDN) platform that aims to open up proprietary, inflexible, and expensive network black boxes. A few high-priced providers have dominated this market for years. The Open Networking Lab (ON.Lab) [2], a nonprofit organization based in Menlo Park, California, provides the primary support for the ONOS project. It is currently working on version 1.7.0 (code-named Hummingbird), which will be the eighth release of ONOS.

The ONOS team includes various other participants, including service providers such as AT&T, China Unicom, and NTT Communications and vendors such as Alcatel-Lucent, Ciena, Cisco, and Ericsson. The ONOS project has also been cooperating with the Linux Foundation [3] since October 2015. Together with OpenDaylight (ODL) [4], ONOS is one of two big beasts in the young SDN ecosystem, thanks to its constant development, up-to-date documentation, community support, and practical applications.

The project describes three main objectives on its website: attracting partners, producing high-quality SDN (network OS) software, and creating open source processes with which employees can work as productively as possible. The project hopes for significant added value from the cooperation of all those participating in the project, initially expressing itself in the form of the carefully authored wiki entries and a well-maintained mailing list, which stood in contrast to the patchy documentation of the ODL Project. In probable pursuit of these goals, ONOS significantly increased the number of its contributors within a few months. Perhaps in response, the ODL Project recently refined its documentation.

Architecture

ONOS is a modular, extensible, and distributed control infrastructure. It is written in Java and covered by an Apache 2.0 license. The project owes its modularity and extensibility to its implementation as an Apache Karaf container [5]. Its distributed platform works thanks to a specially designed architecture. A network operator can have multiple ONOS instances running as a cluster, which automatically synchronizes the services and applications of the SDN devices and visualizes the network as a whole in a summary overview.

ONOS also supports a wide selection of southbound interface protocols, over which SDN controllers and network devices can communicate. These protocols include OpenFlow [6] in versions 1.0 and 1.3 (the variants mainly supported by providers), NETCONF [7], and the Open vSwitch Database (OVSDB) management protocol [8] for device configuration.

As Figure 1 shows, ONOS is constructed from functionally connected layers [9]. The application layer is perched above all else and is a consumer of the northbound API. Network elements collect at the bottom of the pile and talk to ONOS via specific protocols (OpenFlow, NETCONF, etc.), which converts them into providers independent of protocols, forming the southbound API.

In the center ground between northbound and southbound APIs, enclosed within the core element, is a functional unit that offers different services consisting of one or more subsystems (device, host, link, etc.) that, on the one hand, form from information submitted by the providers and, on the other hand, contribute to the application APIs.

Figure 2 shows the subsystem component relationships [9]. The dotted lines represent the northbridge and southbridge APIs. Applications actively request services, manage them, or add listeners for service events. If OpenFlow runs in the network and the OpenFlow provider is active, a new network packet that arrives on a network device creates a PacketIn event.

The listener can register for an event and react to it. An application that consumes such events can be run independent of the protocol version, even if the provider is not active. The manager component mediates between applications, services, and providers. Stores synchronize information between several ONOS instances, making the previously mentioned cluster feature possible.

Programming Intents

One characteristic subsystem of ONOS is the Intent Framework, which you can use to design applications at a higher level of abstraction, simply by telling the network what to do, and not how to accomplish it. For example, a network operator that wants host A to talk to host B just tells ONOS directly: "I want A to communicate with B." Other SDN controllers require you to fiddle with incoming packets and generate a flow entry for each network device in the path.

The Intent Framework subsystem logically collects information from other subsystem components (topology, host) to perform its function. However, it is not yet mature enough, and the developers are working on a richer syntax.

Practical Application

Developers have already implemented several projects with ONOS as an SDN platform. Probably the most relevant is the Central Office Re-architected as a Datacenter (CORD) [11], which was recently split into a separate open source project because of high demand. CORD converts traditional network services and protocols into applications in a cloud environment. For instance, optical line terminals (OLT) are devices used by the telecommunications provider. They are usually made from pure hardware. Recently, however, virtual OLTs (vOLTs ) developed by ONOS have provided the desired functionality. In this way, they can run on non-specialized hardware as services.

Other Controllers

Ryu [12] is a Python-based SDN controller that is very well suited for application development in proof-of-concept scenarios because of its decent documentation and a manageable API. However, the applications still depend on a special southbridge protocol that drives the network, whereas ONOS requires no such preference.

Floodlight [13] is another example of a well-known SDN controller. Its main disadvantage is that it does not activate applications dynamically at run time. Thanks to the Karaf container, ONOS controls this feature, which is designed to load or unload Java bundles as required. The ONOS project uses some of Floodlight's libraries to send, for example, OpenFlow messages. The imports look like this in ONOS code:

import org.projectfloodlight.*

Finally, ODL [4] is the SDN project most similar to ONOS. In fact, both are written in Java, use Karaf as a container, and share some other features: independence from protocols, scalability, a command line, a graphical user interface, a REST API, along with a few more capabilities. One of the major differences, however, is the architecture.

ODL is based on a generalized model-driven service abstraction layer (MD-SAL) [14], on which the developers plan and later implement their models in specific APIs using the YANG [15] data-modeling language. ONOS, on the other hand, comes with a pre-made subsystem architecture that is sufficiently generalized for all possible application types but can be extended as required. Some developers therefore find it easier to develop new applications for ONOS than for ODL, because they have to first develop the APIs for ODL, unlike ONOS, which already has these integrated.

Another difference is in coordinating projects: ODL is fed a diet of multiple projects with different project managers and dependencies. Integrators put these together before a release. ONOS, however, is one major project, directed by a group that takes care of integration.

Last but not least, some SDN experts believe that ODL is more suitable for the cloud and for universal systems (partly because it covers older protocols), whereas ONOS proves more useful for service providers and pure SDN deployments.

Getting Started

To get a first impression of ONOS, you can install the software from the sources. It requires Java 8, Apache Karaf, and Apache Maven [16] to translate the Java bundles. ONOS provides a download page [17] as a package or archive (.tar.gz, .zip, .deb, or .rpm), or as a VM tutorial, found in the Docker Hub. Mininet [18] is the simplest approach for emulating the SDN network.

To start an installed ONOS instance, simply enter ok clean. The ok command stands for "ONOS Karaf," which starts a compiled Karaf container in which ONOS runs. The clean option is typical of Karaf and enables you to start a new session without previous bundles and actions being loaded first.

You can set up a tree network with OpenFlow 1.3 switches using Mininet, as follows:

sudo mn --controller remote,ip=<IP address of ONOS> --topo tree,3,2 --switch ovsk, protocols=OpenFlow13 --mac

You have to match the <IP address of ONOS> with the instance on which ONOS is running. Thanks to the --mac parameter, MAC addresses can be set on the host to small, unique, and easy-to-read IDs after the last bytes of the IP address.

To check which applications are running, the apps command allows you to visualize them from the command line (Figure 3). The devices command shows the devices that ONOS recognizes by numbering the active switches with the aid of their IDs. Alternatively, they can be displayed in the GUI (Figure 4).

The command line recognizes other ONOS commands, which you can list with:

help | grep ONOS

Karaf commands, such as log: display to view log data, are also available. For example, if the reactive forwarding application is active (org.onosproject.fwd), as is usually the case by default, a pingall in Mininet shows all hosts in the GUI, as neatly illustrated in Figure 4.

To (de)activate applications in the case of the reactive forwarding app, use either of:

app activate org.onosproject.fwd
app deactivate org.onosproject.fwd

You can see it in the GUI by typing

http://<IP address of ONOS>:8181/onos/ui/login.html

in the browser and entering karaf as the username and password.

You can also install intents from the command line. The add-host-intent command seeks a path between two hosts. For example, the

add-host-intent 00:00:00:00:00:01/-1 00:00:00:00:00:03/-1

command specifically connects the two instances with the MAC addresses 00:00:00:00:00:01 and 00:00:00:00:00:03. ONOS automatically seeks out the shortest connection between them. However, this does assume that the ONOS host subsystem has previously recognized and registered both hosts. If this is not the case, ONOS saves the intent until the hosts appear. Once installed, intents can be seen (Figure 5).

To close an ONOS instance, type a simple logout or system:shutdown at the command line.

Rich with Potential

ONOS is one of the youngest SDN projects, although the platform could have a very promising future ahead. As one of the two essential free SDN controllers, ONOS predominantly competes with ODL. ONOS does have some advantages. Thanks to the sophisticated APIs, you can build applications fairly simply. ONOS places a clear focus on professional use scenarios in the carrier market, offers significant community support, and is nicely documented.

However, the project started a year later than ODL and still needs some development effort to mature into a full-fledged platform. Only time will tell which of the competing frameworks will call the shots going forward. Perhaps the paths of both projects will cross at some point and merge into a great SDN empire.