Dan Pitt offers his thoughts on recent coverage and dispels some of the myths raised about OpenFlow.
You may have read SearchSDN’s recent article discussing the multiple SDN protocols within the market today, suggesting that their emergence dims the importance of OpenFlow® and reflects its failure. As you might have guessed, we didn’t agree with the article. We do acknowledge that other SDN protocols have come to the marketplace or been put into use since OpenFlow’s inception. But protocol innovation does not mean that OpenFlow® has lost its importance. Simply put: OpenFlow® is vital to the acceleration and deployment of open SDN. Let me explain.
SDN is by far the biggest change in the networking industry in the past three decades. And in the last four years of SDN’s development, OpenFlow® has played a key role in three different areas:
1. As an Architecture
OpenFlow® is an architecture based on the central principle of the physical separation of control and forwarding planes. This is the universally accepted characteristic of SDN and the key to making networks programmable and infrastructure flexible.
2. As a Model
OpenFlow® is also a model, depicting the match-action abstraction of the forwarding plane and standardized definition of switch behavior. This abstraction has fostered the acceleration of technology innovation in the forwarding plane and leads to superior operator choice in building best-of-breed networks.
3. As an Interface
OpenFlow® is the interface between these two planes, in the form of the well-known protocol that very simply conveys flow-table information from controllers to switches.
Since OpenFlow® has been part of the networking scene, no other protocol has emerged to challenge any of its roles. While some industry players continue to argue over alternatives to OpenFlow, a wide range of network operators – including major service providers, Internet companies, and enterprises – currently benefits from the controller and vendor independence this open protocol provides. At the recent Open Networking Summit, we heard from various network operators about their current OpenFlow® deployments and plans. These are by no means small players, either; major companies and organizations deploying OpenFlow® include Google, Alibaba, AT&T, the U.S. National Security Agency (NSA), and Microsoft, among many others. Knowing that major brands are deploying OpenFlow® today is further proof that the protocol is alive and well.
The article also suggests that switch makers are not using the OpenFlow® protocol. We challenge the authors to find a commercial-grade Ethernet switch (or router) on the market today that does not have an OpenFlow® client. What we are seeing now is a surge in support of OpenFlow® v1.3+ in hardware switches. We most recently demonstrated interoperable, hardware-based OpenFlow® v1.3 implementations by Centec Networks, Corsa Technology, Netronome, NoviFlow, and Pica8 as part of our software distribution, Atrium. These examples employ the gamut of packet-switching technologies, from merchant silicon to NPUs to FPGAs.
There are two aspects to interoperability, and the author’s general point that interoperability has been elusive is correct. The first aspect has to do with the controller market, the second with switch features. A market for universal SDN controllers did not appear as expected back in 2011 – 2013. Therefore most OpenFlow® switch vendors started producing their own controllers, single-vendor switch-controller solutions became the norm, and some of the switch vendors liked it that way. The justification for these single-vendor solutions was strengthened by the large number of options and extensions for OpenFlow® versions beyond 1.0 (and mainly from 1:3). The selection of features supported among the hardware, chip-based switching technologies varied widely, and it even varied among switches built from the same merchant silicon. This variety resulted in the non-interchangeability of switches; however, one reason there was so much variety is that, in the early days of SDN, network operators brought different use cases to the table, and wanted to experiment with different features. As the industry gains more experience, we will see which features become popular, and we expect widely accepted feature groupings to lead to more common implementations and greater interoperability.
Now, OpenFlow® interoperability has shifted and we are seeing new approaches to solve interoperability, such as through the industry’s development of critical mass around some common (and open-source) controller frameworks (OpenDaylight and ONOS most prominently) and through Table Type Patterns (TTPs), which in essence are abstract descriptions of a sequence (pipeline) of match-action tables in the switches. We recently saw this approach come to life with ONF’s release of Atrium, with the five branded switches mentioned above and two white-box switches implementing a common OpenFlow® feature set (essentially an implied TTP) established in ONOS. We are also seeing other organizations work with TTPs for interoperability, such as Broadcom with their OpenFlow® Data Plane Abstraction (OF-DPA) software. The OF-DPA software enables the development and deployment of scalable and high-performance OpenFlow-based SDN applications on widely deployed Broadcom-based switches. This means that any OpenFlow® v1.3.1-compliant controller and agent can be integrated with OF-DPA to enable popular SDN use cases such as Virtual Tenant Networks, Network Virtualization, Traffic Engineering, and Service Chaining. Other switch and switching-chip vendors are exploring defining their pipelines according to either TTPs they define or ones the community defines (as is happening in ONF). As the industry gains experience with SDN, popular use cases requiring certain OpenFlow® features sets will drive common implementations in both switches and controllers, thereby achieving interoperability.
SearchSDN pointed to “rival” protocols including BGP, NETCONF, XMPP, OVSDB, and MPLS-TP, and suggested that one of these will become dominant in the marketplace. The truth of the matter is that the use of alternative southbound protocols reflects two realities. One is the desire of some network operators to migrate to the upper layers of SDN with their legacy switching equipment vendors; this desire we sympathize with. The other is the desire of some switch vendors to avoid OpenFlow® because it so radically alters their business models (a change the operators have been clamoring for); this desire we do not sympathize with.
This is also comparing apples to oranges. BGP is one of a number of peer-peer routing protocols that can be used if desired to compute the routes that OpenFlow® conveys to the switches. Indeed, we use it in Atrium. NETCONF is a networking configuration protocol, and it’s great for that (we use it in the OpenFlow® Configuration Protocol), but it is not suited for programming forwarding tables. (Moreover, NETCONF implementations are highly vendor-specific and not interoperable. Fortunately, where NETCONF does make sense the industry is making good progress on defining common Yang models to represent what NETCONF conveys.) OVSDB is the companion configuration protocol to OVS, which uses OpenFlow. Lastly, XMPP is used by all of one vendor, which recently apologized to a group of network operators for the late state of their OpenFlow® v1.3 development. While OpenFlow® may not be the only protocol in use today, it is tough to call these protocols true rivals as there is no other protocol that is challenging OpenFlow, either in terms of widespread adoption or suitability for SDN. The others are limited, interim solutions force-fit to this role. In short, OpenFlow® is already the dominant (southbound) protocol for SDN.
As with any game-changing technology, we’re in a period of innovation. This industry innovation is taking place beyond the southbound interface, where ONF has developed standards. That’s why we are seeing fantastic new optical and packet switching technologies, open-source network operating systems, and automation and orchestration solutions for firewalls, load balancers, WAN optimizers, and so many more virtualized network functions. We are also seeing service-creation tools and platforms, freeing network operators to develop unique solutions as opposed to the box-based ones that their competitors can access.
Competition in the SDN market is heating up. This is a good thing, as competition breeds innovation. Since SDN’s emergence, we’ve seen many aspects of the networking industry evolve and change for the better. The disaggregation of the monolithic, mainframe router alone has fostered a new crop of startups along with novel solutions by incumbents, too. We are starting to see the same phenomenon with service provider OSS and BSS products. The simple abstraction of the network that OpenFlow® articulated started this whole revolution and continues to underpin it.
What are your thoughts on OpenFlow? Have you deployed OpenFlow® in your network? I know many of you are working hard to foster interoperability in a variety of ways. Please share your experiences and thoughts in the comment section below.
- Dan Pitt, Executive Director
