Skip navigation links

ONOS Java API (1.5.1)

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.
CLI implementation for sample application that assigns and manages DHCP leases.
REST APIs for sample application that assigns and manages DHCP leases.
Local event delivery subsystem interfaces & supporting abstractions.
Application to store history of instance local ONOS Events.
Simple application for load testing distributed consensus.
Set of abstractions for dealing with controller mastership related topics.
Mastership load balancer.
Network model entities & service API definitions.
Abstractions of various device configuration or device adaptation behaviours; counterpart to the device driver subsystem.
Subsystem for tracking network environment configuration.
Various basic builtin network configurations.
Infrastructure device model & related services API definitions.
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.
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.
Generic network resource model and services for resource allocation and resource tracking.
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.
Abstractions for reserving network resources.
Services for reserving links and their capacity as network resources, e.g. bandwidth, lambdas.
Service for looking up statistics on links.
Network topology model & related services API definitions.
Application that handles OpenStack Neutron REST calls.
OpenStack networking implementation.
Application for OpenstackRouting.
Application for OpenstackRouting.
OpenStack switch implementation.
OpenStack networking implementation.
Application for bootstrapping Compute/Gateway Node in OpenStack.
Implementation of the ospf api interfaces.
Implementation of the OSPF controller.
Implementation of the OSPF Link state database and Ageing.
Implementation of the OSPF utilities.
Implementation of the OSPF exception types.
Implementation of the OSPF LSA.
Implementation of the ospf TE link types.
Implementation of the OSPF LSA Sub Types.
Implementation of the OSPF Opaque Tlv Types.
Implementation of the OSPF LSA types.
Implementation of the different types of OSPF Packets.
Implementation of the OSPF packet sub types which is used in OSPF packets..
Implementation of the OSPF Packet.
Implementation of the ospf protocol utilities.
Persistence service and builders.
Implementation of the BGP protocol.
CLI handlers for routing commands.
Routing configuration interfaces.
Forwarding Plane Manager (FPM) implementation.
FPM-related CLI commands.
FPM protocol implementation.
Application security constructs.
Abstractions for creating and interacting with distributed stores.
Implementation of distributed applications store.
Implementation of distributed component configuration store.
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 GUI.
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.
Miscellaneous common facilities used for construction of various core and app subsystems.
ANTLR interfaces to be implemented by listener.
Incubator for Network Model & Services 
Package Description
Component management system.
Incubating network model abstractions and APIs.
Various basic builtin network configurations.
Subsystem for network intent domains.
Abstractions for interacting with alarms.
Interface Service.
Service for reserving labels as network resources.
Tunnel model related services and providers API definitions.
Network virtualization data models and services.
Incubating inter-cluster RPC APIs.
gRPC based RemoteServiceProvider implementation.
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.
OLT application api.
API for routing libraries.
Other Packages 
Package Description

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

Copyright © 2016. All rights reserved.