Page History

...

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

• Code 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 clear boundaries between subsystems to facilitate modularity. 
• Protocol agnosticism : It, and its applications, should not be bound to specific protocol libraries or implementations.

...

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 network-facing modules 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  to relay network state information to the core, and for the core to interact with the network via the providersnetwork-facing modules. 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. 

...

If ONOS needs to support a new protocol, a provider may be built against it should be possible to build a new network-facing module against the southbound API as a plugin that may be loaded into the system.

...

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.

Some conventions terms used in the rest of the guide are:

• "infrastructure" refers to the network controlled by ONOS, and may be physical, virtual, or emulated.
• A "device" is a network node, such as a switch, router, access point, or middle box. They usually have multiple interfaces, and may be software or hardware switch.
• A "path" is a set of adjacent links.one or more links. The links must be adjacent. 

It is impossible to avoid referring back to the codebase when we speak of implementation. The following conventions are used with regards to code:

• Class and Object names are monotype, e.g. DeviceManager.
• Method names are monotype and end in parenthesis, e.g. emit().
• Inlined package names are surrounded by square brackets, e.g. [org.onlab.onos.net.DeviceId]