P4 for OVS with Zero Changes

A programmer’s son asks his father:
– Dad, why does the Sun rise in the east and set in the west?
– Son, it’s working, don’t touch it!

Being armed with a set of powerful weapons, including OpenFlow and P4, Software Defined Networking (SDN) is in a constant fight for increasing networks’ flexibility and ease of customization. And the battlefield, where SDN is mustering its forces, is the creation of fully programmable networking solutions with high performance and low overhead.

Open vSwitch, the SDN Street Fighter

I have been involved in the OVS-related projects for the past few years. It is worth admitting that in all use cases I observed, – either pure SDN solutions, hardware acceleration or different types of overlay networking, – OVS proved its maturity and production quality through the years.

Probably the best way to get a clue of what OVS is and what features it provides is to visit the Open vSwitch official website [1] and explore tons of documentation available there. Without further ado, the maturity of this technology can be proved by the range of the platforms it supports:

“OVS can operate both as a soft switch running within the hypervisor, and as the control stack for switching silicon. It has been ported to multiple virtualization platforms and switching chipsets. It is the default switch in XenServer 6.0, the Xen Cloud Platform and also supports Xen, KVM, Proxmox VE and VirtualBox. It has also been integrated into many virtual management systems including OpenStack, openQRM, OpenNebula and oVirt. The kernel datapath is distributed with Linux, and packages are available for Ubuntu, Debian, Fedora and openSUSE. Open vSwitch is also supported on FreeBSD and NetBSD. The Open vSwitch release in development has been ported to DPDK.”

In addition to this, I would like to mention OpenSwitch, the Linux Foundation’s full-featured open source network operating system (NOS) spearheaded by Hewlett Packard Enterprise, which utilizes OVSDB and vswitchd OVS daemons as core components. In a while, OpenSwitch moved to a new codebase [2] but a fork of the original codebase formed the basis of the LibreSwitch project [3].

An Old-School Martial Art of OpenFlow

One of the key components that differentiate OVS from other software switches is the native support of the OpenFlow protocol with multiple extensions. For this reason, OVS can operate either as an L2/L3 switch, a hybrid OpenFlow switch or a pure OpenFlow switch.

Image 1. Open vSwitch datapath schematic architecture

As a result, OVS perfectly suits any SDN scenario (e.g., OpenStack Neutron – network connectivity as a service [4]), where the physical separation of the network control plane from the forwarding plane provides both operational and functional benefits.

But let’s get back to the dinosaur era, to the powerful and dangerous … assembler.
It is not a secret that today’s high level programming language compilers can generate as optimized and efficient binary code as the assembler code written by an experienced engineer.

The following simple example shows the difference between not only two programming languages, but two stages of software evolution.

I believe that P4 and P4Runtime are perfect candidates for the next lap of SDN technology development, providing a new level of flexibility and programmability to tackle the current and upcoming networking challenges. Therefore, there were several attempts to enable P4 support for OVS. The well-known one is the PISCES project [5], – a Programmable, Protocol-Independent Software Switch derived from Open vSwitch, – whose behavior is customized using P4. The purpose for this is quite simple, to decrease development time for new OVS features and protocols. To support a new feature, you should write a P4 program describing this feature, translate the program into C code with a specific P4 compiler and compile OVS with newly generated C extension.

This might be what you need. But to be sure about that, you may want to answer a few simple questions below:

1. How often do you need to add a new protocol support?
2. Are you ready to face the risks and challenges caused by the code change?
3. Does your environment (cloud platform, hypervisor, switch silicon’s SDK) depend on a particular version of OVS?
4. Are you ready to reinstall OVS each time you modify P4 code for it?

Probably the most common cases when you have to get your hands dirty with OVS are either porting of a new SDN application (load balancer, NAT, etc) on top of OVS, i.g. define OpenFlow rules, or the implementation of a new overlay network by means of OVS/OpenFlow. And what is the biggest challenge here? Just think about it.

Meanwhile, let’s take a closer look at the OVS functionality. The OVS manual pages ovs-fields [6] and ovs-actions [7] describe in detail all the OpenFlow matches and actions supported by OVS. Apart from the matches and actions that can be used to operate on standard Ethernet/IP/MPLS packet fields (early versions of the OpenFlow protocol), the latest versions of OVS support many features and extensions that significantly expand the capabilities of the OVS pipeline: conjunctive match fields, 4/8/16 byte registers, connection tracking fields, encap/decap actions, resubmit action, multipath actions, stack push/pop actions and many more.

Wait a minute! Registers? Stack?!.. Can’t we program OpenFlow pipeline in a different, a more natural way? Yes, we can. Without going into detail, just feel the difference:

P4 Technology, an Army Knife for OVS

Simply imagine that you write your application program in the high level P4 language, while the P4 compiler does the rest for you: generates the appropriate default OpenFlow rules and defines the templates for P4Runtime interface. No dependency on the OVS version, no need to recompile your code or reinstall the application. The dataplane configuration is still performed via OpenFlow protocol, but, this time, the rules are injected by the daemon-mediator that translates the P4Runtime messages into OpenFlow rules based on the templates generated by the P4 compiler.

Image 2. Open vSwitch datapath with P4 V1Model mapped into OpenFlow pipeline

As you can see, this approach has some limitations coming from OpenFlow itself. For example, it is possible to either operate with the packet fields and actions defined by the OpenFlow specification, or implement the vendor extensions for the new protocols or actions. So if you really need to add the support of new protocols often (Question #1 from the previous section), PISCES or a similar project can be your perfect choice. However,  if you want to get a mature OVS-based version-agnostic platform for flexible prototyping of SDN applications without deep-diving into the OpenFlow wilds, then P4 to OpenFlow Mapping Approach is something you simply cannot miss.

Let the Sun rise in the east and set in the west!

For those who would like to have a better understanding of what P4 is, I would recommend watching the presentation delivered by Vladimir Gurevich, consisting of two parts:

• Introduction to P4_16. Part 1
• Introduction to P4_16. Part 2

Also, to get familiar with the P4 V1Model Architecture and get prepared for upcoming episodes of this series of posts, you can look through the P4-14 Language Specification [8], which (from P4-16 language perspective) actually describes the V1Model Architecture behaviour.

Let’s get ready to rumble!