Device Driver Subsystem

Overview

The primary purpose of this subsystem is to isolate device-specific code so it does not spread-out throughout the rest of the system. Since such code will be necessary for any foreseeable future, this subsystem provides means to contain it and allow applications to interact with it through well-defined device and protocol independent abstractions. Furthermore, since devices are released and upgraded on different cycles than the rest of the network control/management platforms, the mechanism allows for asynchronous delivery and dynamic loading of the device-specific code. The code can be delivered not only by ON.Lab and its partners, but also by other vendors as necessary.

Recognizing that different families of devices may share features, but also support unique ones, the ONOS driver mechanism avoids monolithic driver approach. Instead, it promotes segmenting different facets of behaviour so that support for features can be selective, can potentially come from different sources and can be shared via inheritance within a product family, whose devices may share similar characteristics.

Driver

In ONOS, a Driver is a representation of a specific family of devices or a specific device. As such, it:

• has a unique name, e.g. com.ciena.foo

• supports set of Behaviour classes

• may “inherit” behaviours from another Driver

• may be “abstract” (?)

DefaultDriver is a class provided by ONOS and it implents the Driver interface.

DriverProvider & DriverAdminService

DriverProvider is an entity capable of providing device drivers and their behaviours:

• Set<Driver> getDrivers()

DriverAdminService is an ONOS service for tracking and managing device drivers indirectly by managing driver providers as follows:

• Set<DriverProvider> getProviders()

• registerProvider(DriverProvider)

• unregisterProvider(DriverProvider)

Note that different driver providers can contribute behaviours to the same driver. This way, drivers for support of OpenFlow table pipelines can come from one source, while support for the PoE configuration of the device can come from another.

DriverService 

DriverService is the principal service that apps and other ONOS subsystems can use to locate appropriate drivers for the device via the following:

• by driver name

• by device manufacturer, H/W version & S/W version

• by supported Behaviour

• by device ID

Behaviours

Different facets of behaviour for either talking about a device or for interacting with a device are modeled as derivatives of Behaviour and HandlerBehaviour interfaces, respectively. The reason for differentiating between the two lies in the slightly different context required.

Contexts

DriverData is a container for data learned about a device in prior interactions. It

• provides Behaviours for talking about a device

• has parent Driver

In this way, even interrogations about different aspects of a device are channeled through abstractions.

Similarly, DriverHandler is a context for interacting with a device.

• provides Behaviours for interacting with a device

• has DriverData

• has parent Driver

So as you can see, in order to talk about a specific aspect of information learned about a device, but in the absence of a connection to the device, one requires access to at least DriverData, which represents the data learned in prior interactions with a device, whereas direct interactions with a device require a slightly more comprehensive DriverHandler context, which include DriverData for recording learned information, but also additional information required for connecting to the device and/or interacting with other ONOS services on behalf of the device.