Putting OpenFlow to the Test
On July 24 the Open Networking Foundation (ONF) announced its conformance-testing program for products implementing the OpenFlow protocol. Let's look at why that matters.
First, here is what the program encompasses. In June the ONF Board of Directors approved the OpenFlow 1.0.1 Test Specification, a document that describes 212 test cases in 10 categories that determine the conformance of an OpenFlow 1.0.1-enabled switch. OpenFlow 1.0.1 is the 1.0 version of the OpenFlow protocol that was produced at Stanford, with slight corrections from ONF. Other referenced documents include the 1.0.1 specification, trademark usage guidelines, and a policy document on the use of ONF and OpenFlow logos. (Stanford transferred the trademark rights to OpenFlow to ONF when we formed, and ONF has registered the mark around the world.)
Testing of products is conducted by independent test labs sanctioned by ONF that maintain ISO 17025 certification. (Thus far ONF has sanctioned one lab in the US and is close to announcing a second one outside the US.) No money flows between ONF and these labs; they set their own fees for companies seeking to test their products. The ONF program includes certificates corresponding to three different degrees of conformance and ONF awards these to specific products from our member companies; again, no money changes hands between ONF and these companies for this certification.
Why engage in conformance testing?
Both product developers and their customers benefit from conformance testing. The ultimate goal of any conformance-testing program is consumer protection. Network operators gain confidence that the products they purchase do indeed conform to the OpenFlow standard and thus will perform as expected. (Many purchasing organizations stipulate standards-conforming products in their requirements.) Product developers gain independent, third-party confirmation of their products' claims, and this can lead to competitive advantage. Conformance testing helps ONF maintain the integrity of the OpenFlow protocol, an important element of our mission to accelerate the adoption of open SDN.
Also important to network operators is interoperability between products of different vendors. This is not guaranteed even among OpenFlow-conformant products, but it's a lot easier to achieve with conformant ones than non-conformant ones. ONF maintains an extensive interoperability-testing program (the Plugfests) that we conduct with the help of our member companies and the Testing & Interoperability Working Group. All told, we want to build market confidence in OpenFlow products, sustain a level playing field among vendors, and bring the benefits of OpenFlow-based SDN to all those who operate and use networks.
Where does the OpenFlow protocol stand in the grand scheme of things?
Let's put the OpenFlow protocol in perspective. This is the protocol that launched the SDN movement. Designed as a simple mechanism for conveying flow-table entries (match criteria and resultant actions) from controllers to switches, it opens the door to the logical and physical separation of control and forwarding elements in a network and to network programmability itself. It abstracts the network to a match-action model and allows policy, security, compliance, traffic engineering, and any other factor that governs how a network should behave to be independently determined by the network operator, not built into the forwarding elements by their manufacturer. In theory, it's nirvana. In practice, it's an enabler of great things contributed by other parts of an SDN ecosystem.
In ONF, we like to talk about the OpenFlow substrate, the foundation of controllers and switches that constitute the data-movement infrastructure heeding the commands of governing software. Above the OpenFlow substrate live all those things that come in close contact with the network operator's business objectives. Here reside services, policies, orchestration, automation, virtualization, and actual content, typically embodied in a computing infrastructure. Business owners care a lot about these things because they constitute the essence of a business and translate directly to revenues and profits. The networking part is just a means to an end, and SDN enables a more direct path to that end.
Sometimes the OpenFlow substrate is described as a southbound interface (from a controller), which it is. It's not the only one, but it's the only standardized one and indeed was the first one, simply because it is a byproduct of the very notion of having a southbound interface. It's not easy to make the transition from the status quo that the networking industry (vendors and customers alike) has become accustomed to, so we are seeing alternative southbound interfaces pop up, mostly in the use of pre-existing protocols that were designed for some other purpose. These generally are not as widely applicable to different scenarios as the OpenFlow protocol, and they don't have nearly the adoption profile among vendors, but they can help ease a customer toward open SDN.
We at ONF believe the OpenFlow protocol will continue to improve, proliferate among products, and increasingly serve as the foundation of service-provider, datacenter, and enterprise networks. We are already working on conformance-testing specifications for OpenFlow 1.3, as this is proving to be the most popular next version after 1.0. We encourage network operators to try the latest version available as they learn what it can do for them. And we encourage product developers to focus their attention on the software and services that ride on the OpenFlow substrate, rather than on short-term alternatives for the southbound interface. Customers understand business-relevant software and services, and they pay for them. The OpenFlow substrate enables them.
ONF will continue to accelerate the adoption of open SDN by building out the OpenFlow substrate to support services above by supplying missing high-leverage pieces of the larger SDN ecosystem and by mapping out migration paths for network operators -- as well as generally hosting the deep conversations about SDN as it is and as it will be.
— Dan Pitt, Executive Director, Open Networking Foundation