Much like cloud in the data centre a half decade back, software defined networking (SDN) is poised to revolutionize networking. A programmable interface that enables new levels of control over hardware infrastructure, SDN promises to ease the bottleneck to the acceleration of cloud computing that networking had become. But like any technology in its nascent stage, SDN is variously interpreted by different groups, claimed as an original concept by multiple vendors — each more ‘open’ than the next — and not well understood in the user community. Despite its potential, broader adoption of SDN will depend on greater user education in the technology benefits, and on efforts to simplify and standardize deployment. On each of these scores, HP’s Sarwar Raza is making a difference. Director of cloud networking and SDN in the advanced technology group at HP Networking, Raza is a fount of information on the origins and operation of SDN, and on HP innovation aimed at simplifying implementation. As chair of the Northbound Interfaces Working Group of the One Networking Foundation, Raza is also pushing for SDN standardization in specific use cases, encouraging consolidation of the proliferation of interfaces that currently exist in the SDN world as a means of reducing deployment complexity. InsightaaS editor Mary Allen had an opportunity to speak with Raza at this year’s Interop event about the SDN innovation process and HP’s role in it. An edited transcript of this conversation follows below.
Mary Allen: HP is recognized as an innovator in the field of SDN. What do you think HP’s major contribution has been?
Sarwar Raza: If you take a look back into the history of SDN, at who the prophets and pundits of SDN supposedly are, you will hear about the crowd from Stanford and Berkeley — the folks who formed the company Nicera that was eventually bought by VMware. The genesis for all that work was in an academic project at Stanford called Ethane, which HP had supported since 2004. One of the outputs of that project was a proposal called OpenFlow. It was still an academic sort of project, but when we looked at it, we said, “Hey, this thing has promise. Let’s put some muscle behind it.” Between our business unit [HP networking] and HP Labs, we provided some early resources; we provided hardware for an implementation of OpenFlow for these researchers to use. So we had the very first OpenFlow implementation on a switch specifically for researchers who were still working out the kinks. This was probably circa 2007 or so, and then in 2008-2009, we were the first to actually decide “this thing has legs, let’s put it on our products.” We made a board decision, saying “Yes, we know it’s a v1 spec but we’re going to put it in our products.”
We haven’t looked back since. All our products support OpenFlow, all our switching and our routing products are also coming up to speed now. We’re a very big believer in open standards. Our contribution has been intellectual and we also provided support for the researchers who came up with the idea. And then last but not least, I think we’ve done more to bring this technology into the mainstream, earlier than anyone else, and we’re still leaders in this space. No other vendor has got a footprint or a portfolio that’s as broad and OpenFlow-enabled us.
Allen: That initial academic project that you provided hardware for — did you also provide intellectual resources? Did researchers from HP Labs collaborate on the Ethane project?
Raza: Yes. HP Labs regularly collaborates with academia, so yes, we did work on several lab projects in the SDN space. To this day, if you look at the OpenFlow standard, the gentleman who maintains and manages that standard at the ONF [Open Networking Foundation] is an HP Lab researcher. His name is Jean Tourrilhes, he works at HP but he is the keeper of the OpenFlow standard. He writes the OpenFlow standards.
Allen: There are other open protocols though. OpenFlow is not the only open standard, even in networking.
Raza: Of course not. But OpenFlow is the very first networking protocol that decouples the control plane, the data plane in the hardware from the control plane in the software. So you’re right, it’s not the only protocol and in fact it’s not the ultimate solution to all your networking woes. It solves a set of use cases very well today, it’s still an evolving standard. We’re up to v. 1.5 now, and people are starting to look forward to OpenFlow 2.0 now. The standard will evolve, and there will be other standards, but what OpenFlow did was it actually really catalyzed this SDN movement. It was the proof point that this can be done, that allowed vendors, led by HP, to rally around it and say, “Yes, we think this makes sense.” But it makes sense not just because it’s cool technology but because customers are asking for it. Customers want the kind of flexibility that OpenFlow offers — that’s why we jumped in.
Allen: So you’re a strong supporter of the ONF too? I believe that body formed to commercialize the technology. Is that right?
Raza: Yes. We’re a founding member of the ONF and its charter is to standardize and commercialize the OpenFlow. Its remit is slightly broader than OpenFlow though, as it’s the go-to organization for SDN in general. OpenFlow just happens to be where there’s a lot of focus now, because it is early days still. We’ve been involved with the group right from the start, and we’ve got people in most of the working groups. We have my colleague Jean Tourrilhes, who chairs the Extensibility Group, and I chair the Northbound Interfaces Group.
Allen: Within these groups, are there different vendors or different individual who are following divergent paths who might challenge OpenFlow? Or is the community in agreement that OpenFlow is the way to go?
Raza: I think there are some detractors of OpenFlow, folks who think it can be done better or can be done differently. And that’s always been the case in networking. Whether you’re looking at the work being done in ONF or ITM or IEEE, there are always camps of people who support one thing or the other. ONF, in general, has been growing and is now up to 130 members. What’s unique about the ONF is that it’s not vendor driven. All the authority in ONF is actually invested in the hands of end users. The board members are Facebook and Yahoo! and Google and Goldman Sachs and Deutsche Telecom — not HP, or pick your favorite vendor. What you see is a community of folks who have come together to work on this, and I think there’s a very deep appreciation that it solves a lot of challenges. It doesn’t solve every issue but that because it’s early days still. ONF has been around for three years, it’s growing very fast, but still a very young organization. There are always competing interests and competing agendas in any sort of body. So as you would at ITM or IEEE or any other standards body, you work it out.
Allen: I think in some ways it keeps you honest and keeps you answering questions, and that’s actually good for the health for any line of intellectual inquiry. Can we move now to Northbound Interfaces? Can you explain their significance?
Raza: If you consider the fact that SDN opens up the network, that it actually provides a new programmatic surface to the network that didn’t exist before, the question becomes what exactly are you exposing to the users and the applications that want to consume those services? If we provide an interface into the network that basically requires application programmers to have knowledge of vLANs and details of the systems underneath, we have failed. We’ve absolutely, completely failed. The idea behind Northbound Interfaces is to provide suitable, appropriate abstractions that allow network services to be consumed in a way that hasn’t been possible before. When we talk about Northbound Interfaces, we’re typically talking about a set of programmatic abstractions provided by an SDN controller that can then be consumed by an application in an automation framework — a cloud orchestrator like OpenStack. At its simplest level, what you’ve done is talk down to every individual network node, saying, “Talk to the controller, tell it what you want,” and the controller will figure out how to disseminate those commands down to the network.
If you start with this notion of centralizing your command logic for the network in once place, you need to provide a way for applications to express their requirements. Take it a step further so that you now want to communicate with the network at a fairly high level. In an ideal case — we’re in fact showing this with one of our demos here [at Interop] — you want to be able to request from the network capability for a high bandwidth video conversation between me and you. I know what the two endpoints are, I know it’s going to be video with this particular codec, and I haven’t pre-provisioned the network. I haven’t gone out and said “there’s always got to be a one MB link between me and Mary because who knows when I need to make a video call.” That would be wasteful, right? With SDN, when I click on my desktop and say I want to start a video call, that application signals to the network, saying, “Hey, they’re trying to start a video call, here’s the starting point, here’s the endpoint, do your thing.” That’s essentially the level that you want to get to. You want to provide a level of abstraction that specifies that this user gets a gold level of service because they’re a VP, this person gets a silver level of service and for this person, it doesn’t matter if the first time they click on the video it fails and they have to try two or three times. For the CEO it better work every time. So you can do this for different classes of applications that might have high priority traffic. The job of the Northbound Interfaces is to work on those abstractions, those information or data models that allow application intent to be transmitted to the network without getting to the details of the vLAN, etc.
Allen: I’m trying to visualize a network administrator or a developer who is trying to use this. Is there a programming language, or are policies set for different types of traffic?
Raza: That’s actually a very interesting question and I would say the answer is it depends on the class of user. If you were a hyper scale user or a user that’s got the expertise to program to these frameworks yourself, then you’re looking for that language level access. You would want a Java library or a Python library or something that your developers can go to town on. If you’re a typical SME at a typical enterprise, you won’t have a staff of developers. You would have an IT person who is looking for a canned solution that works as advertised so that if something goes wrong, he/she can pick up the phone and call someone to de-bug it. In that situation, what you would want is a more shrink-wrapped solution, like the ones we’re demoing here. For example, we have a Network Application Optimizer for Microsoft Lync that you can use without knowing what the MDI is or what the language underneath it is. All you tell us is “my enterprise uses Microsoft Link and I have a problem with QoS and I’d like to use your application with your SDN controller.” We deliver it to you. You install it, and it just works. So there are people who will consume in a sort of solution form, and there will be people who will want to get at the shell and program it to their will. We have to be able to accommodate both.
Allen: That’s pretty interesting. So the shrink wrapped applications are what you would see in the HP SDN App Store, such as the Protector security application that was announced?
Raza: Yes. To a great extent, that’s the mass market approach.
Allen: If you wanted to do your own programming and you had development staff, it would be open source programming languages that you would use?
Raza: Today we provide a Java API and a REST API that you can use, and as customers require it, we can add more language binding. If you want a Python interface or you want a C interface, those are all things we can add on. But we’re not inventing a language. There are some efforts in academia to come up with a programming language or a framework to express SDN policies, but I think that work is several years from any sort of maturity.
Allen: Can we take this out one more level? We have moved in the discussion from the network to a level of abstraction to a level of control — through either programming or a shrink wrapped application. How does this help the business person who’s thinking about performance of a particular business application?
Raza: At root, what SDN enables is much more granular control over your network resources. In the past, you were at the mercy of this black box operating system sitting on each box that you had very little control over: you didn’t quite know how things were implemented and you couldn’t really get into the forwarding tables to do what you wanted to, even if you were so inclined. SDN allows businesses that need to extract every little bit out of the network hardware to exercise the most granular level of control. SDN gives you the ability to either write an app or deploy an app that is more fine tuned to your particular use case. If you look at one of the better known use cases for OpenFlow, Google announced with the ONF a couple of years back that they were using it in their WAN backbone. They had a particular traffic engineering example for it. If you look at the business advantage that Google garnered from it, they were looking at 98-99% utilization of their links, which is huge. So depending on the type of application that you’re providing, you would be able to achieve either a quantitative or qualitative measure of improvement.
If you look at our Microsoft Lync demo, there’s actually a marked difference in the user quality of experience between a generic infrastructure with typical QoS markings and one where we used SDN to almost set up a customized network path and QoS setting for our call — where we say, “I want to have a chat with her and it’s got to be HD video,” and the network says, “okay, I’ll set it up right now” and we use it. When the call is done, SDN tears the connection away so that we’re no longer using that resource. That’s better than the average case which says, “Oh, maybe he’ll use video, maybe he won’t use video, let me provision it for the average case.” In some cases, you might see a hard ROI that you can measure in terms of utilization; in other cases, it might be a little more squishier. It could be, “Hey look, my video performance is so much better,” or, “My calls don’t drop anymore.” I think either case is just as valuable.
Allen: So you have a specific mandate, mission statement or outcome that you have defined for this particular working group?
Raza: Our first goal is to create a catalogue of the most compelling use cases that require a Northbound Interface and to begin making strides towards standardizing these interfaces. One of the problems today is that there are 18 controllers in the market and 18 different interfaces. The app vendors are tearing their hair out. So we want to try and come up with a framework to enable some consolidation. The second goal we are pushing for is to drive implementation for at least a couple of those use cases into open source this year. We’re looking to create an information model, a data model that can be implemented in an open source controller and into a commercial controller, and then throw it out there and see if it sticks.
Allen: When you’re talking to your boss, how do you explain that this work that you do in the working group helps HP?
Raza: At HP, the conversation around our need to participate in the standards party is a very easy one because we’ve always been about open standards as opposed to proprietary lock in. So we are really just building on work that we would typically do, this is really just an extension of how we usually operate. We do it in the open, we do it with partners, and we do it with users, so it’s not a hard sell to my bosses at all.
Allen: I just have one last question. Over the years I’ve been exposed to HP messaging around converged infrastructure and one of the things I often heard was that yes, HP is open, but if you have all HP components then converged infrastructure works better and you get better results. It seems to me that with SDN, your messaging is a little different — you start with the ‘open’ message as the key benefit and advantage of the offering. How do you reconcile this from a marketing perspective, and is there a technical challenge in the fact that you’ve got a whole bunch of components that work really well together, and then you have another line of SDN products that are really important in the data center that are open to working with everybody?
Raza: In general, I don’t think that these things are mutually exclusive. If you look at HP’s converged infrastructure story, it’s built around open standards-based components. We’re looking at cross-phase servers, at standards based switches and storage architecture. When we talk about converged infrastructure for customers who give us the chance to serve them in all these silos, it’s that we’re able to better package and manage those things via our orchestration and management frameworks because we have a better understanding of how the components work. If you wanted to take apart pieces of our HP server infrastructure and run it with a third-party network or vice versa, you’d find we’re best of breed in either case. But of course when you put it together, we’re able to do things that other people can’t and that’s just a function of how we’re close to the product and to the customer. If you look at some of the recent things we’ve announced around One View, it’s basically a consolidated management view for your infrastructure where if you started mixing and matching components from different vendors, you would still get partial benefit from the solution, using it to manage just the HP pieces. But you wouldn’t be as well integrated or get the same benefit as you would if you had our entire stack. That’s just part of the HP differentiation.
