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.
...
- Device Subsystem - Manages the inventory of infrastructure devices.
- Link Subsystem - Manages the inventory of infrastructure links.
- Host Subsystem - Manages the inventory of end-station hosts and their locations on the network.
- Topology Subsystem - Manages time-ordered snapshots of network graph views.
- PathService - Computes/finds paths between infrastructure devices or between end-station hosts using the most recent topology graph snapshot.
- FlowRule Subsystem - Manages inventory of the match/action flow rules installed on infrastructure devices and provides flow metrics.
- Packet Subsystem - Allows applications to listen for data packets received from network devices and to emit data packets out onto the network via one or more network devices.
Network representation
As their names suggest, each subsystem acts upon a specific aspect of the network. ONOS maintains both protocol-specific and protocol-agnostic representations of various network elements and properties, albeit in different tiers (Provider and Core, respectively).
Additionally, some elements are built from other elements. These derivative elements may not have a protocol-specific representation. One example is the Topology, built from Devices and Links.
Further discussion of network representation can be found in [Network Representation].
Subsystem Structure
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 top and bottom dotted lines in the figure represent the inter-tier boundaries created by the northbound and southbound APIs, respectively.
Provider
The lowest tier of the ONOS stack, Providers interface with the network via protocol-specific libraries, and with the core via the ProviderService interface.
...
A component residing in the core, the Manager receives information from Providers and serves it to applications and other services. It exposes several interfaces :
- A north-bound northbound Service interface through which applications or other core components can learn about a particular aspect of the network state
- An
AdminServiceinterface for taking administrative commands and applying them onto the network state or the system - A south-bound southbound
ProviderRegistryinterface through which Providers can register with the manager, so that it may interact with it - A south-bound, southbound
ProviderServiceinterface presented to a registered Provider, through which it may send and receive information to and from the manager
...
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.
| Info |
|---|
Not all subsystems possess all of these components, and not all components strictly adhere to these functions. For example, |
Events and Descriptions
Two fundamental units of information distribution within ONOS are Events and Descriptions. As with services, Events and Descriptions are associated with specific network elements and concepts. Both are immutable once created.
Descriptions
Descriptions are used to pass information about a element across the southbound API. For example, a HostDescription contains information about a host's MAC and IP Addresses and its location in the network (VLAN ID and device/port attachment point).
Events
A Description is transcribed into an Event once it enters the system core. Events are used by Managers to notify its listeners about changes in the network, and by Stores to notify their peers of events that should be known globally. For example, a DeviceEvent can be used to notify DeviceListeners that a device has been detected (DEVICE_ADDED), lost (DEVICE_REMOVED), or some aspect of it has changed (DEVICE_UPDATED), among others.
Events are generated by the Store, and dispatched by the Manager via the EventDeliveryService.