FlowVisor, a network virtualization layer

FlowVisor is a special SDN controller which aims at separating one physical SDN into multiple (potentially overlapping) virtual slices. “It acts as a controller for the switches and as an OpenFlow switch for the controllers”[1]. “The Prefix-based Layer 2 Network Virtualization (L2PNV) [7] is an extension of FlowVisor, with the main objective of providing a level 2 virtualization engine without using VLAN, instead basing the virtual networks created in Media Access Control (MAC) on the address of origin and destination”[1].

From FlowVisor’s github project (https://github.com/OPENNETWORKINGLAB/flowvisor/):

• FlowVisor is a special purpose OpenFlow controller that acts as a transparent proxy between OpenFlow switches and multiple OpenFlow controllers
• FlowVisor creates rich slices of network resources and delegates control of each slice to a different controller
• Slices can be defined by any combination of switch ports (layer 1), src/dst ethernet address or type (layer 2), src/dst IP address or type (layer 3), and src/dst TCP/UDP port or ICMP code/type (layer 4).
• FlowVisor enforces isolation between each slice, i.e., one slice cannot control another's traffic

Although FlowVisor setup may be quite long, as it requires a lot of manual configuration, some tutorials are available on the internet to help network administrators deploying FlowVisor (https://github.com/onstutorial/onstutorial/wiki/Flowvisor-Exercise).

While still being effective and functional, FlowVisor is not maintained anymore and should not be run in production networks[2] for two main reasons:

• FlowVisor only supports OpenFlow 1.0, while OpenFlow 1.5 has been released for more than two years now
• It exists several vulnerabilities concerning slices’ isolation[3][4].
• Flowvisor lacks of scalability “since the recommended requirements for operating the FlowVisor are 4 processor cores and 4 GB Java heap.” [1]

Yet, FlowVisor has been used from 2009 and is still being used in multiple research networks where slices’ isolation vulnerabilities may not be a big concern.

“The FlowVisor intercepts OpenFlow messages from guest controllers (1) and, using the user’s slicing policy (2), transparently rewrites (3) the message to control only a slice of the network.” [5]

In both you create slices or tenant which are basically a group of physical network links and devices.

• On Flowvisor, you can distribute the slicing between multiple controller. Ex: Let two slices of the same network named slice1 and slice2 and two controller c1 and c2. c1 handles slice1, c2 handles slice2.
• On VTN, you can not slice the network between multiple controllers. One controller must do all the work. Ex: Let two slices of the same network named slice1 and slice2 and two controllers c1 and c2. c1 handles slice1 and slice2 of the same network. But there is no way of making c2 handles slice1 and slice2 but by recreating the slices.

• [1]. NVP: A Network Virtualization Proxy for Software Defined Networking, B. Pinheiro, E. Cerqueira, A. Abelem, October 2016
• [2]. OpenFlow network virtualization with FlowVisor, 2013, by Sebastian Dabkiewicz.
• [3]. Vulnerabilities and solutions for isolation in FlowVisor-based virtual network environments, 2015, by Victor T. Costa & Luís Henrique M. K. Costa.
• [4]. FlowVisor Vulnerability Analysis, 2017, by Ying Qian, Wanqing You and Kai Qian.
• [5] FlowVisor: A Network Virtualization Layer, 2011 by Rob Sherwood, Glen Gibb, Kok-Kiong Yap, Guido Appenzeller, Martin Casado, Nick McKeown, Guru Parulkar