Network Evolution

Building the infrastructure for the changing face of IT


News Stay informed about the latest enterprise technology news and product updates.

Building on OpenFlow, FlowVisor offers path towards open network virtualization

Network virtualization tool FlowVisor boosts software defined networking by allowing easy slicing of physical networks into multiple logical pieces.

FlowVisor, a network virtualization platform that builds on OpenFlow, moves open software-defined networking (SDN) up the stack by allowing easy slicing of a physical network into multiple logical networks. It gives administrators the power to manage with broadly defined rules rather than by tweaking a collection of routers and switches.

Installed on commodity hardware, FlowVisor is a special OpenFlow controller that acts as a transparent proxy between a network of OpenFlow switches and other standard OpenFlow controllers. While still considered experimental and lacking some basic features, such as command-line management tools, FlowVisor has been deployed in production environments at scale, including powering Stanford's campus network since 2009. FlowVisor slices up physical networks through an abstraction layer that is equivalent to how a hypervisor sits between server hardware and software, allowing multiple virtualized operating systems to run. FlowVisor sits between a set of switches -- and the software defined network or networks -- and manages bandwidth, CPU utilization and flow tables.

Just as a hypervisor relies on a standardized x86 instruction set to virtualize servers, FlowVisor manages OpenFlow switches using the standardized OpenFlow instruction set, which sets low-level rules about how packets are forwarded based on characteristics found in the packets' header tables.

Because all these rules are defined with flow tables, the network virtualization adds minimal or no overhead, either in bandwidth or CPU usage, although separate out-of-band physical controllers that set and modify flow table rules are needed.

Slicing and dicing toward SDN

The basic elements of the FlowVisor-enabled network are the network slices, which are defined by a set of text configuration files that contain rules that govern a range of network activity. Possible rules include allow, read-only and deny, while ranges can include a flow's origin IP address, port number or packet header information.

For example, a network manager can partition secure Telnet traffic (which defaults to port 992) into its own slice, while assigning traffic from the executive team's IP addresses into another slice. He can then create a third, default slice for all other traffic and establish a final "read-only" slice that monitors the other three slices for diagnostic purposes. The network manager can dynamically reassign and independently manage these slices, ensuring that a receptionist browsing YouTube does not negatively affect Telnet-driven applications and executive team bandwidth.

Slice isolation is a critical part of FlowVisor's virtualization, but it is also an evolving area for the experimental platform. An academic paper published describing FlowVisor's vision and implementation, for example, calls for tight switch-CPU isolation, a feature which is currently limited at best since switch CPUs are only indirectly manageable through OpenFlow. Given these evolving limitations and capabilities, FlowVisor works to virtualize and isolate along five key dimensions, as defined by the OpenFlow technical report:

  • Bandwidth: Each slice should have its own dedicated percentage of the total available bandwidth.
  • Topology: Each slice should have its own view of network nodes, including both physical and virtual switches and routers. The elements of a slice should be unaware of the slicing: To a controller, FlowVisor looks like an ordinary switch; from an OpenFlow switch's perspective, FlowVisor appears as a controller.
  • Traffic: Traffic should be tightly and consistently isolated to a specific slice or slices, based on the rules set as described above.
  • Device CPU: Overloaded physical switches can drop slow-path packets. The network manager should update OpenFlow statistics counters and rules, so FlowVisor takes into account CPU resources when rate limiting intensive commands.
  • Forwarding Tables: Since forwarding tables are often constrained on physical devices, the network manager should ensure that one slice does not overwhelm any given device's forwarding table, forcing it to drop the rules of another slice.

Is FlowVisor ready for prime time?

Like its building block OpenFlow, FlowVisor was created as a tool for researchers to quickly and flexibly experiment with new SDN ideas and tools in a large production environment. FlowVisor has been deployed in production environments around the country, particularly in large university campuses, such as Stanford, as well as by participants in the Global Environment for Network Innovations (GENI) and Internet2, two large, research-focused networks.

That does not mean it is coming to a business network near you any time soon, however. The platform is very stable at this point, but has a long way to go, according to Ali Al-Shabibi, a postdoctoral researcher at Stanford, employee at the Open Networking Laboratory and a current developer of FlowVisor.

"There's still a lot of work that needs to be done to bring FlowVisor to enterprise quality," he said. Primarily, it needs some polishing around end-user ease of use. For example, it currently offers no prompt command-line interface or Web-based administration, leaving users to manage configuration files in order to push changes out.

FlowVisor's network virtualization use cases

Rob Sherwood, who led FlowVisor development at Stanford for three years before taking a job at OpenFlow startup Big Switch Networks, said FlowVisor's value extends well beyond experimental networks to practical services, such as a service providers offering plug-and-play optimizations on a per-user basis to its customers (think enhanced video streaming that speeds up your kitten video downloads, or dedicated slices for VoIP calling, both for an additional charge from your Internet service provider).

Sherwood also said it could prove useful to large Internet companies looking to more efficiently or securely manage large amounts of traffic.

"You can imagine Google, with multiple internal services, sending Gmail traffic and YouTube traffic across the same network, but using different policies for them," he said. "Right now, they use different physical networks because they can't say, 'YouTube take this path and Gmail take this path.'"

Risks and advantages of FlowVisor network virtualization

The fine-grained capability to define and redefine networks comes at a price. Sam Barnett, a data center and cloud analyst with Infonetics, thinks it will be too high for most IT shops.

"If you put OpenFlow in the hands of an uneducated community … it's akin to giving a toddler a loaded gun, cocking it and telling them to put it in their mouth and pull the trigger," he warned. "When I was in the carrier world, at MCI for many years, if I had something like OpenFlow, it would've solved so many problems. This would be great there."

But outside of carriers and the most bold network tweakers, Barnett said too much flexibility just asks for trouble with very little upside.

Al-Shabibi agreed with that assessment, but noted that enterprises will have commercial options for using the technology.

"Smaller IT shops won't write their own solutions, but what they're probably going to do is go to Big Switch or Nicira or another OpenFlow-compatible vendor and buy a solution from them that they can drop into their network," he said.

A bright future for FlowVisor networking ahead

Since FlowVisor builds upon OpenFlow controllers, Al-Shabibi said the former's adoption will remain a subset of the latter's success. But both are likely to see continued acceptance. "We hope that as OpenFlow sees more uptake in the industry, so will FlowVisor," he said. "It really is one of SDN's 'killer apps'. Being able to isolate your services in your network is a pretty awesome feature."

Sherwood said that FlowVisor could eventually have just as big an impact as OpenFlow has had in recent years.

"We are trying to get FlowVisor code into the spotlight," he said, noting the project had landed a Google Summer of Code intern to help polish and boost its profile. "As the ecosystem fills, people will see the value in being able to slice up the network."

Article 1 of 5

Dig Deeper on Software-defined networking

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

Have you ever used flowvisor to test with a physical openflow switch? like NEC PF5240?
Because when I used flowvisor with ovs-based swithes, it worked fine.
However, when the flowvisor operated with the NEC PF5240, the flowvisor cannot get the flowentry in the switch. But the rest of the functions(insert/delete flowentry) worked fine.
This confused me a lot, hope you could help me with this.

Get More Network Evolution

Access to all of our back issues View All