InCNTRE's OpenFlow SDN testing lab works toward certified SDN product

Indiana University's InCNTRE SDN lab is conducting conformance testing that will lead to the first OpenFlow 1.0.1 certified product, expected for release this summer.

In the past few months, the SDN market has focused on OpenDaylight and its quest to standardize controller code. Meanwhile, the Open Networking Foundation has continued to develop and standardize OpenFlow, the southbound protocol that is still most likely to be the language spoken from SDN controllers to the rest of the network. This summer, the first ONF-certified OpenFlow 1.0.1 product will reach the market.

Indiana University's Center for Network Translational Research and Education (InCNTRE) has been at the heart of this certification process, using its SDN Interoperability Lab for OpenFlow conformance testing, as well as third-party neutral interoperability and performance testing. InCNTRE will be the first lab testing equipment to be OpenFlow 1.0.1-certified by the Open Networking Foundation (ONF). Once this product emerges, technology buyers could have a clearer roadmap of how to invest in OpenFlow SDN.

Maybe the device conforms, but how well does it perform? That is an area that has not been explored much yet. There are a number of things you would want to know, but it's complicated.

Steve Wallace,
executive director, InCNTRE

InCNTRE Executive Director Steve Wallace sat down with SearchSDN to talk about OpenFlow testing in terms of interoperability, performance parameters and conformance.

What is the state of OpenFlow conformance testing?

Steve Wallace: The testing and interoperability working group [of the ONF is going through a process of defining what it means to be conformant for OpenFlow 1.0.1. That's about to be finalized, and starting in mid to late July, InCNTRE will start doing official testing.

We will have vendors bring in equipment and set it up for OpenFlow, and then leave because they're not allowed to be there during testing exercises. We will test cases and features that the ONF has required to be conformant.

We will provide the test results and a recommendation of our interpretation of whether this device is conformant. The ONF will use that information to determine if the device is OpenFlow-conformant and it will provide that ONF member with some sort of logo that represents conformance.

By late July or early August, we'll see the first product that has the ONF seal of approval for OpenFlow 1.0.1.

What kinds of products are being conformance tested? Are you testing both switches and controllers?

Wallace: The current testing and interoperability working group is focusing on OpenFlow switching devices, not controllers.

At some point will controllers need to be certified?

Wallace: It's not clear whether that's going to be required. The OpenFlow protocol and the abstraction govern the behavior of a switch. What is critical to test is whether there is high fidelity [between the controller] and the behavior of the switch.

Will your testing take into consideration northbound protocols at some point?

Wallace: It is fairly critical that the southbound interface is uniformly implemented, so if you're buying a product, you have assurance that a particular product meets standards.

The northbound interface is the space where vendors can add lots of value, so there will be less requirements for there to be formal certification in that space.

If I were building an OpenFlow controller, I would want to ensure it had a northbound interface that worked well with OpenStack Quantum, but I don't think that will be something the ONF is going to certify. Controller vendors are going to compete in value and there may be a time in the future where there is some standardization of that.

As a testing center, will you eventually look beyond OpenFlow and the ONF and work with other organizations, such as OpenDaylight or the IETF, to test standards?

Wallace: When I think about the southbound interface between a switch and controller, the ONF is a good vehicle [for certification]. The typical environment is one logical controller. But [it's different] when you start thinking about distributed controllers.

Over time there will be advancements in terms of extending the notion of a single controller. I've seen proposals where researchers are looking at different methods and approaches to federating controllers -- provisioning services across domains or having distributed controllers within one domain. All of that [research] might happen in the IETF or in the commercial space, but that is somewhat disconnected from the southbound protocol being worked on by the ONF, and I think that's a good thing.

In what scenario would you need federated controllers?

The Internet2 network has a service built on its 100 GB where you can go into a Web-based portal and create point-to-point service across the country in less than a second using OpenFlow.

The controller that does that has the ability to communicate using an inter-domain control protocol to other networks. The controller that provisions services on the Internet2 network is federated in other networks, and today -- with the right authorization -- can define the circuit that goes from the U.S. to Europe. Also, within a single network, you might have distributed controllers. In Internet2, for example, there are three controllers. If the primary controller goes down, they will vote and elect another to do the job of the primary. So they're using a number of controllers to provide resilient service within a network.

How is OpenFlow being tested and used in networks outside the data center?

Wallace: What's happening in the WAN is bandwidth-on-demand, like with Internet2. Another item is service insertion, which is related to NFV [network functions virtualization]. So for example, for a wireless provider, users may subscribe to a video service that lets them watch videos on their tablets. When it starts raining and the RF [radio frequency] changes, the wireless provider detects that the encoding for the video you are watching was optimized for when it wasn't raining, and now that it is, they want to decode it differently to maximize the experience. They might use OpenFlow to steer that flow to some sort of device that transcodes video based on knowledge from the wireless network. They look at OpenFlow as a technology that allows them to do service insertion to steer that flow to a particular process in the cloud.

More on OpenFlow development and testing

A guide to understanding the OpenFlow protocol

Do ONF fees block engineers from contributing to OpenFlow?

OpenFlow pitfalls and potential

OpenFlow SDN for the campus LAN

They can also use it to provide lawful intercept support, which describes what a provider might have to do in response to a subpoena or other lawful request to intercept data, like on a voice over IP call. Openflow is a tool I can use to build that into my network.

InCNTRE does SDN performance testing. How do you measure performance in an SDN environment? This is not about speeds and feeds anymore, right?

Wallace: Maybe the device conforms, but how well does it perform? That is an area that has not been explored much yet. There are a number of things you would want to know, but it's complicated.

There are two approaches to putting in rules using OpenFlow in switches. One is proactive and the other is reactive. With reactive, when a packet comes into switch and it doesn't have a matching rule, you send the packet to the controller, which then puts a rule in the switch to handle those kinds of packets. If you had an application that did a lot of that, you would want to know what the performance of the switch was in terms of its ability to send packets to the controller, and that can vary greatly by switch.

But if you have [a] proactive [scenario], like with Internet2, you never have packets coming from the switch to the controller, so you don't care at all. You have to be a sophisticated customer to know which metric applies to the application.

Another example would be the rate at which you can install rules in the switch. These are called flow mods. Depending on the application, if you can only do a few per second that might be fine, but in another case, a few per second would be unacceptable.

Another set of issues has to do with the size of the tables. OpenFlow rules populate tables and those tables have limitations in terms of how many entries they can hold. They might be able to hold many of a certain kind of entry and fewer of others. Early adopters need to understand the requirements of their application. If you're an early adopter, you're going to have a conversation with the application developer, the controller vendor and the switch vendor to ensure that even though they all do OpenFlow correctly, their strengths line up with what you need.

Dig deeper on OpenFlow

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchNetworking

SearchEnterpriseWAN

SearchCloudProvider

SearchUnifiedCommunications

SearchSecurity

SearchDataCenter

Close