Overview

This section provides a high-level view of ONOS, and its general design points. 

Design Goals

ONOS is a multi-module project whose modules are managed as OSGi bundles. ONOS is designed with a few points in mind:

• Modularity : It should be possible to introduce new functionalities as self-contained units.
• Configurability : It should be possible to load and unload various features, wether it be at startup or at runtime.
• Separation of Concern : There should be boundaries between different subsystems, in the form of APIs
• Protocol agnosticism : It, and its applications, should not be bound to specific protocol libraries or implementations.

We take a succinct look at each below.

Run-Time Extensibility

ONOS is written to leverage Apache Karaf as its OSGi framework. In addition to dependency resolution at startup and dynamic module loading at runtime, Karaf provides the following:

• Enable use of standard JAX-RS API to develop our REST APIs and make them secure
• The notion of features as a set of bundles allowing assembly of custom setups
• Strict semantic versioning of code bundles, including third-party dependencies
• Local and remote ssh console with easily extensible CLI
• The notion of run-time log levels

Code Organization and Modularity

The project is comprised of a set of sub-projects, each with their own source tree that can be built independently. To do this, the ONOS source tree is organized in a hierarchical fashion that takes advantage of Maven's notion of a hierarchical POM file organization. Each sub-project has its own pom.xml file, and intermediate directories have parent aggregate pom.xml files. The latter contains shared dependencies and configurations for those sub-projects, enabling them to be built independent of unrelated sub-projects. The ONOS root contains the top-level pom file used to build the full project and all of its modules.

Separation of Concern

ONOS is partitioned into :

1. Protocol-aware network-facing modules (providers) that interact with the network
2. Protocol-agnostic system core that tracks and serves information about network state, and
   
3. Applications that consume and act upon the information provided by the core

Each of the above are tiers in a layered architecture, where providers interact with the core via a southbound (provider) API, and the core with the applications via the northbound (consumer) API. The southbound API defines protocol-neutral means for providers to relay network state information to the core, and for the core to interact with the network via the providers. The northbound API provides applications with abstractions that describe network components and properties, so that they may define their desired actions in terms of policy instead of mechanism. 

The aim of this clear separation of concern is greater extensibility and modularity. 

Protocol Agnosticism

If ONOS needs to support a new protocol, a provider may be built against the southbound API as a plugin that may be loaded into the system.

The Remaining Sections 

The remaining sections of the Architecture Guide elaborate on the design and implementation of the subsystems that make up the above-mentioned tiers, and the OpenFlow provider that ships with ONOS.