Page History

Introduction

TODO: architecture overview (providers, drivers, protocol)

Providers

ONOS interacts with the underlying network with the help of its Providers. Providers in ONOS are standalone ONOS applications based on OSGi components that can be dynamically activated and deactivated at runtime. The main purpose of providers is to abstract the configuration, control and management operations of a specific family of devices (e.g. OpenFlow, SNMP, Netconf, etc.).

Providers offer means to:

• execute requests originated from the core, such as install/get flow rules in OpenFlow, set/get MIB parameters in SNMP, set/get port status in Netconf, etc;

• process and notify the core about events originated from the infrastructure devices or manually injected in the system using the net-cfg service. Examples of environment event that are relevant to ONOS operations are: an OpenFlow switch connection request or packet-in, a BGP route advertisement, a SNMP trap, etc.

Requests from the core are usually originated from the managers (e.g. the DeviceManager, PacketManager, LinkManager, etc.), while providers can notify the core about events using the ProviderService API.

Providers implementation is used to generalize the logic of operating on a device of a given family, when it comes to actually performing a specific operation on a specific device instance, in order to allow support for different flavors of the same device (e.g. different support of the OpenFlow 1.3 specification), providers can call drivers to abstract the device-specific logic. On the other hand, when dealing with external events, a good practice is to have a server or controller component implemented in the protocol module and have providers register for event listeners. Similarly a provider can register for net-cfg events, so that users or external applications can inject informations using JSON-formatted messages, such as the IP address and port of the control agent of device, links, and so on.

Usually, there exist multiple providers for the same device family, each one devoted to provide control abstractions and environment sensing over physical and logical infrastructure entities, such as devices, links, flow rules, packets, etc. As an example, the following providers can be defined for the same device family (here the complete list of currently available Provider interfaces in ONOS):

• DeviceProvider: responsible of notifying the core through the DeviceProviderService API about the discovery of new devices and their description (such as vendor/model, available ports, hardware/software version, etc.), as long as exposing method to DeviceManager in order to perform operations such as setting a port operational state (up or down).
• PacketProvider: responsible of notifying the core through the PacketProviderService API of a packet-in event received from the data plane, as long as exposing methods to PacketManager in order to generate packet-outs at the data plane.
• LinkProvider: is responsible of notifying the core through the LinkProviderService API of the discovery of new links, while not methods are exposed to any manager since it would make no sense to perform an operation on a logical entity such as a link.

Code walk-trough

WIP