Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
...
- 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 different subsystems, in the form of APIssubsystems to facilitate modularity.
- Protocol agnosticism : It, and its applications, should not be bound to specific protocol libraries or implementations.
...
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 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. We begin with the lowest tier and work our way upby introducing the concept of services, a unit of functionality within ONOS.