Have questions? Stuck? Please check our FAQ for some common questions and answers.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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

 

Service for locating appropriate drivers for the device

 

  • by driver name

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

  • by supported Behaviour

  • by device ID


 


  • No labels