Skip navigation links

ONOS Java API (1.11.0-b1)

ONOS architecture is strictly segmented into a protocol-agnostic system core tier and the protocol-aware providers tier as shown in the figure below:
ONOS architecture tiers

See: Description

Network Model & Services 
Package Description
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 of a protocol-independent packet forwarding pipeline.
Base abstractions fot runtime control of a protocol-independent pipeline.
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.
Utility classes.
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.
Facilities for handling localization of the 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.
Incubator for Network Model & Services 
Package Description
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.
Interface Service.
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.
Package Description
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.
App & Extensions 
Package Description
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:
ONOS architecture tiers

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.
ONOS architecture tiers

The following diagram describes the general structure of each ONOS subsystem:
ONOS subsystem structure
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 DeviceEvent notifications via the DeviceListener mechanism. A set of administrative actions can be performed via DeviceAdminService, e.g. setting mastership role, removing a decommissioned device.

On the south-bound side, the core exposes a 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 DeviceProviderService will be invalidated and can no longer be used for interacting with the core.

Within the core, the tasks of indexing, persisting and synchronizing the global device and port state with the cluster peers falls on the DeviceStore.

Similar structure applies to the link subsystem, host subsystem and others.

More information to come later...

Skip navigation links