Quantum Multi-Switch Plugin Framework

Objective
An L2 network may have multiple switches (physical and virtual), and these switches could be a combination of different types/technologies. Moreover, the L2 network consisting of these switches and the end hosts may be connected in an arbitrary topology.

It is desirable to have a plugin framework which can handle these generic requirements, and reference implementation of this plugin be provided.
Design
The above objectives can be achieved with a hierarchical structure of modules. The description below takes the example of Cisco UCS 6120 and Nexus switches.

• L2-Network Plugin: The base plugin module which serves as an oracle in the system. It has knowledge of the network topology, network technologies used, the devices, and hosts present in the system. The L2-Network Plugin manages the state of the entire system relevant to the tenant, network, and port abstractions (but not the device specific state). It also provides the implementation for the extensions exposed via the extensions framework.

• Device-category-specific Plugins: The L2-Network Plugin relies on device-category-specific plugins to perform the configuration on each device. For example, we have a UCS plugin, and a Nexus plugin. This second level of plugins know how to realize the abstractions for a particular device/technology. For instance, in the case of the UCS plugin, the create-network operation results in creating a VLAN in UCSM. Similarly, in the case of the Nexus plugin it results in the creation of a VLAN on the Nexus switch and also the configuration of specific interfaces to allow that VLAN. These plugins manage the device-specific state.

• Device-category-specific Drivers: The device-category-specific plugins in turn use drivers to communicate with the actual devices. For instance the UCS plugin uses a UCSM driver to communicate with the UCSM using XML API.