Rethinking the Network

Marten Terpstra

Subscribe to Marten Terpstra: eMailAlertsEmail Alerts
Get Marten Terpstra: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Cloud Computing, Virtualization Magazine, Network Virtualization, SDN Journal

Blog Post

OpenFlow Evolution: Standardized Packet Processing Abstraction Is Hard

OpenFlow is a standardized abstraction of the switch capabilities

With the Open Network Summit 2014 about to start in Santa Clara next week, I realized I had not done much OpenFlow reading recently. It is no secret that Plexxi does not use OpenFlow as the API between our switches and controller due to restrictions in what OpenFlow can do (or in some cases could do when we needed to make architecture and design choices). When I saw the ONS announcement I thought it an opportune moment to sync myself to the latest and greatest in OpenFlow world.

What started out as a mechanism to program flows into network switches and routers in a standard way is evolving into a full blown forwarding engine programming and management specification. In the latest version of the spec (1.4, released in October 2013), the abilities exist to configure properties of optical ports, create semi-atomic changes across multiple switches, table full notifications and several more items that have stepped away from basic programming of flow based forwarding behaviors on a network element. In addition, OF-Config exists specifically for configuration and management. Looking at this paper written by some of the OpenFlow principals, the proposed framework for OpenFlow 2.0 would take that to a next level as a generic and abstracted mechanism to program protocol independent packet processing engines. That same paper lists some of the challenges with the current OpenFlow path, which is what led the authors to put the proposal forward.

There is lots of value in creating a single standard way to make packet switches do what they need to do. From SNMP to “industry standard” CLI possibly wrapped in netconf and everything in between, mechanisms to (remotely) configure a switch in a semi standard way have been around since we have had switches. Anyone that has operated a network would tell you they would love to have a single standard way to manage their network. But this is nothing new. That desire has been around forever. And the technology to do so is also not new. The functionality in the chipsets has been there in one form or another. So you have to ask the question, can it be successful this time around?

Inside each ethernet switch is a packet processor (or a piece of software in a vSwitch that pretends to be a packet processor). This packet processor has an abstraction layer written to abstract the register by register configuration of the functionality of the chip. The abstraction layer provides functions like enabling a port, changing the port speed, creating a VLAN, adding a MAC address to a forwarding table, configuring ACL like rules, etc. The amount of functionality provided in these chips is astounding and growing with each and every technology iteration. Thousands of pages of functional descriptions of the abstraction layers accompany each chip and even with this abstraction layer, configuring the more advanced versions of these chips to do things beyond basic switching is not at all trivial. Yes, the abstraction layers most certainly can use some work.

OpenFlow is a standardized abstraction of the switch capabilities. Starting with the ability to direct specific flows into the switch’s forwarding table, it is now includes broader capabilities to control the switch’s behavior, just like the abstraction layer would. As a consumer of switch chipsets, standardized abstraction is extremely beneficial. Today, switching from one chip vendor to another is a painful exercise. The functionality is slightly different, the abstraction layers hugely different and it takes time and effort to adjust from one chipset to another. If all chipsets had the same method of programming, I could chose whatever chipset I wanted from any vendor with little to no software effort.

The aforementioned paper points out some of the real tough challenges that come with a standard abstraction layer. The abstraction models each of the many protocols the switch supports with all the fields you would like to control and as such becomes unwieldy very quickly. A second and important limitation mentioned is the fact that switches are different. Different vendors implement functionality different, provide different capabilities and there is no easy mechanism to express the differences in these key functions. And these are often the types of functions that make switch buyers select one vendor over another. Creating a standardized superset of all abstraction layers of all hardware and software switches is very hard. From Plexxi’s perspective, one of the reasons we do not use OpenFlow is a need to abstract application workflows and topologies rather than individual or aggregate flows.

Standards are needed, but standards have a tendency to be behind. Especially in networking, so many of the best solutions, those that create differentiation, start with standards, but then have piles of private extensions to make it faster, more scaled, easier. Almost all vendor implementations of TRILL, SPB, PIM, even ISIS, OSPF and BGP have proprietary extensions for that purpose. OpenFlow touches perhaps a few percent of a modern chipset capabilities. Will OpenFlow ever cover enough of a switch’s capability and keep up with its evolution to have enough critical mass to not make it yet another abstraction layer in addition to the ones already there? We completely believe in the underlying movement to standardization and openness, but OpenFlow may well be too large and complex to provide us at Plexxi and others in the industry with all the capabilities we need.

The post OpenFlow Evolution: Standardized Packet Processing Abstraction is Hard appeared first on Plexxi.

Read the original blog entry...

More Stories By Marten Terpstra

Marten Terpstra is a Product Management Director at Plexxi Inc. Marten has extensive knowledge of the architecture, design, deployment and management of enterprise and carrier networks.