Controller Projects' Modules/Bundles and Interfaces
This needs to be updated. Please bear that in mind when reading the content and feel free to help update it.
This is a list of the modules/bundles in each controller, the interfaces they export, the backing implementations of those interfaces, and a brief description of the functionality provided. The three controllers currently sketched out are: the OpenDaylight controller and the OpenDaylight net-virt-platform. (For posterity's sake, a similar analysis of the Floodlight open source controller can be found at the bottom of the page.)
The current lists are a work in progress and may be either incomplete or out of date. For net-virt-platform, the list of modules, interfaces and implementations should be complete as of 4/30/2013. The similar list of package/bundles and interfaces (but not implementations) for controller should be complete as of 4/30/2013.
The lists were generated by searching for implementations of org.sdnplatform.core.module.IModule.getModuleServices() in net-virt-platform and all calls to org.osgi.framework.ServiceRegistration.Component.setInterface() in controller. Note that there are two implementations of the second function: one that takes a single interface and one that takes a list.
The net-virt-platform code is presented in a hierarchy of package => module => interface => implementation since that was pretty fairly easy to extract from the code.
The controller code is presented in a hierarchy of package/bundle => interface. In practice, there is a 1:1 correspondence between packages and bundles in the code, so that's fine. However, there is no real notion of a "module" which is easy to pull out. The result is that there is only currently per-bundle information.
In reality, it seems like there's something of a concept of a module in the Daylight code, but it's weakly codified. Basically, in implementations of org.opendaylight.controller.sal.core.ComponentActivatorAbstractBase.configureInstance() and org.opendaylight.controller.sal.core.ComponentActivatorAbstractBase.configureGlobalInstance(), they pass the particular implementation being activated and based on that they change the interfaces. In some cases, the package/bundle only has one such expected implementation and thus they don't ever use it. In other cases it has multiple, which are effectively modules, and it modifies it's behavior depending on which implementation is passed back.
Hopefully, this will provide at least a sound technical backing for discussions going forward.
|Package/OSGi Bundle||Exported Interfaces||Description|
||Component responsible for learning about host location. It achieve to goal by looking at the ARP conversation between an host and the controller. This is an application that show case a possible host tracking mechanism, especially useful in the cases like OpenFlow where the controller can see all the packets if instructed to.|
||Allow to other components of the controller to allocate/deallocate clustered ConcurrentMap. Also provides a set of utility functions to know about the configuration of the cluster and for interacting with the Java transaction manager|
||Stub version of the cluster manager, to be used mostly in integration tests.|
||Provide configuration services to the other bundles. Via this bundle the components can manage their configuration need and just worry about the data to be persisted without worrying about location of where the data will be persisted.|
||Provide the implementation of "default" container for the controller.|
||Provide the necessary hooks to inject in the area controlled by the controller, routes to reach traditional IP networks.|
||Manager of all the Forwarding Rules, this component take case of forwarding rules and is the one that manage conflicts between them.|
||Track the location of the host relatively to the SDN network.|
||Protocol plugin for OpenFlow 1.0. Include the openflowJ library as well the necessary glue logic to adapt to SAL layer along with a discovery mechanism for learning the graph of the OpenFlow network portion.|
||Sample Protocol plugin|
||Implementation of Dijkstra routing algorithm over the network graph as seen by the topology manager. The component keeps a cache of the topology in order to save on calculation time. Make use of the Jung2 third-party library for the calculation.|
||Implements the services that SAL export to the applications using it as well to the protocol plugins. It essentially implements the necessary logic to mux all the notifications from the protocol plugins toward the applications, and demux the requests from applications sitting on SAL toward the correct protocol plugin.|
||Implementation of a simple load-balancer. This component wants to show case the usage of the functional modules.|
||Sample implementation of an application simulating a traditional IP network. This component wants to show case the usage of the functional modules.|
||Component in charge of using the ReadService from SAL, in order to collect several statistics from the SDN network.|
||Component holding the inventory information for all the known nodes in the controller. All the components that wants to have access to let say a port name or node name or any inventory information, will find them via query to this component.|
||Component holding the whole network graph. Provide notifications on edges updates to who wants to listen about it.|
||Component taking care of user management. Every component in a need of user authentication/authorization and accounting will use the services of this component.|
|org.opendaylight.controller.security||Fragment of the embedded Tomcat web server, interacting with the usermanager in order to validate the incoming REST/UI calls to be coming from valid users.|
|org.opendaylight.controller.*.northbound||JAXRS implementation of REST API for several modules. There are several component implementing the REST API because each component can be removed or upgraded independent from others.|
||Host for the root UI as well component in charge of tracking the several pieces of the UI depending on bundles installed on the system.|
||Bundles implementing the several pieces of the UI.|
Net Virt Platform
|Package||Module/Interface Class - Implementation Class||Description|
||Manages devices with overlapping identifiers (e.g., allows two hosts with the same MAC to live in different address spaces). For multi-tenancy.|
|Core control loops for OpenFlow switches, HA, application registration and message dispatch.|
|Interface for handling counters and relevant operations on them.|
|Maintains a unique ID for each device and any associated state, e.g., it's attachment point in the network, discovered IP addresses, vlans, and MAC addresses.|
|A packet forwarding module that determines the shortest path between two hosts (Dijkstra) and lays down a path with flows accordingly.|
|org.sdnplatform.hub||Hub||A packet forwarding module implemented to function like a hub|
|org.sdnplatform.jython||JythonDebugInterface||A debug module that launches a Jython debug server.|
||A simple load balancer module for ping, tcp, and udp flows. This module is exposed via a REST API and is defined closely to the OpenStack Quantum LBaaS (Load-balancer-as-a-Service) v1.0 API proposal. See http://wiki.openstack.org/Quantum/LBaaS.|
||Defines a REST API server implementation and provides an interface for modules that wish to expose REST APIs.|
||A service that is exposed internally as well as externally via a REST API. It allows for other modules or users to easily insert flows into an OpenFlow network.|
||Abstract platform storage service.|
||Concrete Cassandra-based NoSql storage service (extends NoSqlStorageSource).|
||Abstract NoSql storage service (extends AbstractStorageSource).|
||Concrete, memory-based NoSql storage service (extends NoSqlStorageSource).|
||Implements platform's thread pooling service. By default it creates an ScheduledExecutorService with 15 threads. The thread pool can be used to schedule commands to run after the caller-specified delay or to be executed periodically.|
packages => modules => exported interfaces