JNT Visual - Fotolia


IO Visor challenges Open vSwitch

An alternative to Open vSwitch aims to execute software upgrades without disrupting network services. Expert Keith Townsend explains how the technology works.

Network functions virtualization (NFV) has enabled both agility and cost savings, triggering plenty of interest...

and activity in both the enterprise and service provider spaces. As the market begins to mature and organizations operationalize both NFV and software-defined networking (SDN), questions around nonstop operations arise. An area of recent focus is how do you provide nonstop operations during infrastructure code upgrades? The IO Visor Project claims it can implement nondisruptive upgrades unlike competitor Open vSwitch.

The fundamental challenge IO Visor tries to address is the operational impact of coupling input/output (I/O) with networking services. For example, if an OVS user wants to install a new version of OVS that adds packet inspection, a service disruption to the basic network I/O functionality is required.

IO Visor claims to solve this problem by decoupling the I/O functionality from services. The IO Visor framework starts with the IO Visor Engine -- an in-kernel virtual machine (VM) that runs in Linux and provides the foundation of an extensible networking system. At the heart of the IO Visor Engine is Extended Berkley Packet Filter (eBPF). EBPF provides a foundation for developers to create in-kernel I/O modules and load and unload the modules without rebooting the host.

It's worth noting that in-kernel I/O normally results in greater performance than solutions that run in user space. For example, the ability to run an IO Visor-based firewall should hypothetically offer performance increases over a firewall running in user space.

Use case

Is IO Visor in search of a problem that doesn’t exist, or are projects like this one the future of network function virtualization?

The IO Visor project provided this use case: In a typical OVS environment today, updating the firewall function requires a restart of OVS or even a host reboot. Leveraging the IO Visor plug-in architecture, on the other hand, the in-kernel firewall plug-in would simply unload and reload. The bridging, router and Network Address Translation (NAT) functions would continue to operate.

It’s early days for IO Visor, while OVS is mature and stable. Currently operational across thousands of environments, OVS provides carrier-grade performance. Most SDN users have reliably leveraged OVS and its extensive network of contributors and commercial products. In contrast, PLUMgrid is the only production-ready IO Visor-based platform I’m aware of.

With all this said, I’m intrigued by the idea of abstracting I/O from network functions. The abstraction of I/O coupled with network function plug-ins adds flexibility to virtualized network architecture. I’ll be watching the project closely. What do you think: Is IO Visor in search of a problem that doesn’t exist, or are projects like this one the future of network function virtualization? 

Next Steps

PLUMgrid builds SDN platform on IO Visor

Building an Open vSwitch test network

Do you have a virtual switch strategy?

This was last published in November 2015

Dig Deeper on Network virtualization technology