This section describes the organization of the major subsystems found in ONOS.
As mentioned in the previous section, ONOS is architected with tiers of functionality. We present the following figure as a summary of the discussions in the next few sections :
A service is a unit of functionality that is comprised of multiple components that create a vertical slice through the tiers as a software stack. We refer to the collection of components making up the service as a subsystem. We use the terms 'service' and 'subsystem' interchangeably in this guide.
ONOS defines several primary services:
Each of a subsystem's components resides in one of the three main tiers, and can be identified by one or more Java Interfaces that they implement.
The figure below summarizes the relationships of the subsystem components.
The lowest tier of the ONOS stack, Providers interface with the network via protocol-specific libraries, and with the core via the ProviderService interface.
The protocol-aware providers are responsible for interacting with the network environment using various control and configuration protocols, and supplying service-specific sensory data to the core. Providers may also collect data from other subsystems, converting them into service-specific data.
Some providers may also need to accept control edicts from the core and apply them to the network using the appropriate protocol-specific means. These are fed into the Provider via the ProviderService interface.
A Provider is associated with a ProviderId. The main purpose of the ProviderId is to provide an externalizable identity of a family of providers, which allows devices and other model entities to remain associated with the identity of the provider responsible for their existence even after the provider is uninstalled/unloaded.
The ProviderId carries a URI scheme designation to allow for loosely pairing devices with providers from an alternate provider family, and for this to be possible without access to the Provider itself.
A component residing in the core, the Manager receives information from Providers and serves it to applications and other services. It exposes several interfaces :
AdminService interface for taking administrative commands and applying them onto the network state or the systemProviderRegistry interface through which Providers can register with the manager, so that it may interact with itProviderService interface presented to a registered Provider, through which it may send and receive information to and from the managerThe consumers of a Manager's service interface may receive information both synchronously by querying the service, and asynchronously as an event listener (e.g. by implementing an EventListener interface).
Also within the core and associated closely with the Manager, Stores have the task of indexing, persisting and synchronizing the information received by the Manager. This includes ensuring consistency and robustness of information across multiple ONOS instances by directly communicating with stores on other ONOS instances through the StoreDelegate interface.
Applications consume and manipulate information aggregated by the managers via the AdminService and Service interfaces. Applications have a wide range of functionality, ranging from displaying network topologies in a web browser to setting up paths for network traffic.
Each application is associated with a unique ApplicationId. This identifier is used by ONOS to track context associated with an application (e.g. tasks and objectives such as intents and flow rules). To obtain a valid ID, applications register with the CoreService, providing their name which is expected to follow the reverse DNS notation, e.g. org.onlab.onos.fwd.
Not all subsystems possess all of these components, and not all components strictly adhere to these functions. For example, |