Integrate FlowVisor into Switch

Ivan Pepelnjak gives the following 4 OpenFlow models in his November 02, 2011 ipSpace blog:

  1. Native OpenFlow
  2. Native OpenFlow with extensions
  3. Ships in the night
  4. Integrated OpenFlow

Here, we propose an architecture which allows users to configure the OpenFlow switch to be one of the above 4 models. The key to achieve the flexibility is to integrate FlowVisor into the OpenFlow switch. It is named FlowVisor switch in this page.

Originally, FlowVisor is a special purpose OpenFlow controller that acts as a transparent proxy between OpenFlow switches and multiple OpenFlow controllers.  In this proposed architecture, FlowVisor performs the functions to virtualize the network for each controller by creating a “slice” of the network resources and delegates control of the “slice” to the controller. The rules for each “slice” are defined in the controller’s Slice Policy.

The following figure provides the logical view of this architecture.

Figure to Integrate FlowVisor into Switch

In the above figure, Controller 0 is a special controller which resides in the FlowVisor switch. Controller 0 and its corresponding Slice Policy play the major role to define the model to the FlowVisor switch to function.

Controller 1 to Controller n are remote controllers which resides in the remote servers. Native OpenFlow performs the OpenFlow switch functions and Traditional Control Plane performs the traditional L2/L3 switch functions.

Here are the models that can be performed by the FlowVisor switch:

  1. It is a traditional switch if there are no remote controllers and the Controller 0 does nothing.
  2. It is a “Native OpenFlow” model if the Controller 0 instructs the Traditional Control Plane to enter pass-through mode. In this mode, Traditional Control Plane forwards the incoming packets to Native OpenFlow directly.
  3. It is a “Native OpenFlow with extensions” model if the Controller 0 instructs the Traditional Control Plane to support L2 and L2.5 protocols (such as TRILL, LACP, LLDP, …).
  4. It is a “Ships in the night” model if there are no overlaps between Slice Policy 0 and other Slice Policies.
  5. It is a “Integrated OpenFlow” model if there are overlaps between Slice Policy 0 and other Slice Policies.

If this architecture does make sense for future development, we will continue to work on the design of the communication between Native OpenFlow and Traditional Control Plane.