Set of abstractions for managing network control applications.
Set of abstractions for centrally managing component configurations.
Set of abstractions for dealing with controller cluster related topics.
Base JSON codec abstraction and a service for tracking various JSON codecs.
ONOS Core API definitions.
Service for looking up control message stats.
Local event delivery subsystem interfaces & supporting abstractions.
Set of abstractions for dealing with controller mastership related topics.
Network model entities & service API definitions.
Abstractions of various device configuration or device adaptation behaviours; counterpart to the device driver subsystem.
Protection behaviour and related classes.
Subsystem for tracking network environment configuration.
Various basic builtin network configurations.
Network configurations for "inject" provider.
Infrastructure device model & related services API definitions.
Domain intent package.
Set of facilities to allow the platform to be extended with device specific behaviours and to allow modeling device (and other entity) behaviours while hiding details of specific driver implementations.
Service for interacting with network edge.
Flow rule model & related services API definitions.
Traffic selection criteria model.
Traffic treatment model.
Abstractions for objective-based flow programming of data plane without requiring device pipeline structure awareness. This subsystem is experimental and its interfaces will change in the upcoming release.
Abstractions for interacting with device port groups.
End-station host model & related services API definitions.
Set of abstractions for conveying high-level intents for treatment of selected network traffic by allowing applications to express the what rather than the how.
Definitions of constraints used to refine intent specifications.
Package supports intent northbound apis providing utility classes.
Device key data model and services.
Infrastructure link model & related services API definitions.
External model entities of the multicast RIB.
Flow meter model and related services.
Mechanism for processing inbound packets intercepted from the data plane and for emitting outbound packets onto the data plane.
Base abstractions related to network entity providers and their brokers.
Base abstractions related to the proxy arp service.
Subsystem for tracking inventory of network control regions.
Generic network resource model and services for resource allocation and resource tracking.
Service for looking up statistics on links.
Network topology model & related services API definitions.
Persistence service and builders.
Base abstractions and utilities for developing REST APIs.
Routing configuration interfaces.
Application security constructs.
Abstractions for creating and interacting with distributed stores.
Cluster messaging APIs for the use by the various distributed stores.
Interfaces for creating various distributed primitives.
Distributed core state management services.
Mechanism for managing dynamically registered user interface extensions.
Facilities for creating chart models of data for the Web UI.
Server-side modeling of UI entities.
Server-side modeling of Topology View UI entities.
Facilities for creating tabular models of data for the GUI.
Set of table cell renderers and comparators for use by GUI apps.
Mechanism for dynamically extending topology view with information and behaviour overlays.
Component management system.
Abstractions for interacting with the elastic configuration subsystem.
Incubating network model abstractions and APIs.
Various basic builtin network configurations.
Subsystem for network intent domains.
Subsystem for dpi statistics service.
Abstractions for interacting with alarms.
Neighbour message (ARP, NDP) handling.
Service for reserving labels as network resources.
Unicast routing service.
Tunnel model related services and providers API definitions.
Network virtualization data models and services.
Virtual network event delivery subsystem interfaces & supporting abstractions.
Network virtualization provider interfaces and implementation.
Incubating inter-cluster RPC APIs.
Graph abstractions and graph path finding algorithms.
Utilities to assist in developing JUnit tests.
Misc utils for various performance metrics.
Facilities for building testable components in OSGi independent fashion.
Utilities for decoding and encoding packets of various network protocols and encapsulations.
Utilities for decoding and encoding IPv6 extension headers.
Utilities for decoding and encoding packets of Neighbor Discovery Protocol for IPv6 (RFC 4861).
Utilities for managing PIM packets.
Facilities for building JAX-RS web resources.
Various exception mappers to map errors to proper response status codes.
Miscellaneous domain-agnostic utilities.
An application that manages the control plane.
Sample application that assigns and manages DHCP leases.
API for routing libraries.
ONOS architecture is strictly segmented into a protocol-agnostic system
core tier and the protocol-aware providers tier as shown in
the figure below:
The ONOS core is responsible for tracking information about the network environment and distributing it to the applications either synchronously via query or asynchronously via listener callbacks. The core is also responsible for persisting select state and synchronizing state among the cluster peers.
The protocol-aware providers are responsible for interacting with the network environment using various control and configuration protocols and supplying such sensory data to the core. Some providers may also need to accept control edicts from the core and apply them to the environment using the appropriate protocol-specific means.
The figure below provides a visual inventory of the various ONOS subsystems.
The ones with the gray outline represent either work in progress features
planned for release in 2015.
The following diagram describes the general structure of each ONOS subsystem:
For example, the device-subsystem comprises of a core
which exposes a north-bound
DeviceService through which applications or other core components
can learn about the global infrastructure device inventory and through
which they can also subscribe for asynchronous
notifications via the
DeviceListener mechanism. A set of
administrative actions can be performed via
e.g. setting mastership role, removing a decommissioned device.
On the south-bound side, the core
DeviceProviderRegistry through which any number of
DeviceProvider entities can register and in turn obtain a
DeviceProviderService. Device and port information can then be
supplied to the core by each provider through the provider service issued
to them. When a provider unregisters, its
will be invalidated and can no longer be used for interacting with the
Within the core, the tasks of indexing, persisting and synchronizing the
global device and port state with the cluster peers falls on the
Similar structure applies to the link subsystem, host subsystem and others.
More information to come later...