Figure 1 illustrates the high-level CoVisor architecture. CoVisor serves as a transparent layer between controllers and the physical network. Each of the five applications shown at the top of Figure 1 is an unmodified SDN program running on its own controller; each controller outputs OpenFlow rules for the virtual topology shown below it, without any knowledge that this virtual topology does not physically exist. CoVisor intercepts the OpenFlow rules output by all five controllers and compiles them into a single policy for the physical network.
At the far left of Figure 1, we see that CoVisor takes configuration input from the administrator. These configuration responsibilities are threefold:
- define how the policies of the controllers should be assembled;
- create each controller’s virtual network by specifying the components to be included and the physical-virtual mapping; and
- state access control limitations for each controller.
CoVisor is built on top of OpenVirteX (OVX).
In OVX, one or more
PhysicalSwitches map to a single
controller's view of the network comprises the network of
OVXNetwork). To support one-physical-to-many-virtual topology
abstraction, we add the
PlumbingGraph layer between the
PhysicalSwitch and the
OVXNetwork. In CoVisor, each
PhysicalSwitch maps to a single
PlumbingSwitch in the
PlumbingGraph maps to
one or more
OVXSwitches. If a single
OVXSwitches, the administrator must specify how the
OVXSwitches' flowtables are composed to create a single
PlumbingSwitch flowtable. Finally, each controller sees the network
as comprising whichever
OVXSwitches it is connected to, though in
reality every controller is connected to CoVisor.
PlumbingGraph, and red indicates the controller's view. Solid lines are network connections, and dashed lines indicate abstract mappings.