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.

Figure 1: The ONOS architecture [10] is agnostic when it comes to protocols; the applications based on the platform use the northbound 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.

Figure 2: The stack component relationships [10]. The applications can activate listeners that respond to events.

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.