I had a couple of very interesting discussions recently on SDN, and they point out what I think might be the emerging key issue for the whole concept. That issue is whether SDN is about services or about protocols, and it’s been framed to me recently by discussions on the evolution of OpenDaylight.
The central concept of what most people would call “true” SDN is the OpenFlow protocol, which provides the means for a central controller to manage network routing by managing per-device forwarding tables. Unlike traditional switching/routing which “learns” network topology and reachability by adaptive exchanges with adjacent/connected elements, SDN imposes forwarding rules based on any arbitrary policies it might like.
Interestingly, this definition makes three interdependent but not necessarily tightly bound points. Point one is that there is a protocol—OpenFlow—to control the devices. Point two is that there is a central mechanism for deciding what network routing should be like, and point three is that there is a service conception behind what that central control point decides. In the SDN world, we’ve seen a polarization of solutions based on which of these points are most important. Can you build “SDN” if you can create services—“Networking-as-a-Service” or NaaS—regardless of how you do it? Can you do SDN without central control, without OpenFlow? All valid questions, since buyers of next-gen networking will buy/do what is useful to them, which might be any or all of these things.
What’s interesting about OpenDaylight in this context is that it’s been, at least for the companies I talked with recently, a kind of mind-opening experience. All the people involved in the projects I reviewed had started with the notion of ODL as a model for an OpenFlow controller. All are now questioning whether that’s what’s really important.
OpenDaylight is in fact a controller model, but it takes a different slant on the process. You have higher-layer “northbound” applications that frame some conception of NaaS, and then impose that conception on hardware through what’s essentially a plug-in architecture. Unlike a pure SDN controller, OpenDaylight can speak a theoretically infinite number of control protocols southward into the network equipment/software layer.
What got my conversational partners interested in OpenDaylight beyond OpenFlow was the question of evolution. You can use ODL and OpenFlow to control legacy devices that can support the OpenFlow protocol, but you could also use it to control legacy devices in other ways. So my subjects didn’t like the OpenFlow solution on some of their hardware so they asked the following question: “Could I frame up some notions of NaaS that are meaningful to my business case, then simply adopt them across a mixed infrastructure using whatever protocol was handy.” And that was the start of something big for them.
The companies quickly realized that what was going to make the SDN business case for them was the intersection of two things. First, what useful NaaS models could be identified and applied to current and evolving applications? Second, what is the cost of supporting those useful NaaS models through a full set of network-control options?
One quick realization that came out of these questions was that Cisco’s notion of ACI wasn’t as dumb or manipulative as at least some of these companies had believed. If you take a NaaS-centric view of SDN, you’re really taking a view that depends on API converting goals into network behaviors. How that’s done is secondary (it matters only in a cost sense). If no changes to current devices or practices are an option, then there would be no risk of increases in operations complexity and cost.
The second realization was that the value of stepping beyond an SDN model that simply manipulated current adaptive behavior likely lies in the value of NaaS models that can’t be easily induced from current IP and Ethernet devices behaving in their usual adaptive/cooperative way. These companies all realized that cutting off the option of enhanced NaaS models was taking a risk, so they were looking for a way of managing that risk. Which became the mission for OpenDaylight.
OpenDaylight is essentially a shim layer that operates between NaaS models and infrastructure. If you have NaaS models that map to simple control of legacy IP or Ethernet connectivity, then there is no OpenFlow involved because you don’t need to change forwarding models for NaaS reasons. That would make OpenFlow adoption totally dependent on the credibility of substituting white-box switches for current adaptive switch/routers. That’s a savings in capex with a so-far-difficult-to-quantify accompanying change in opex. In short, it’s a future issue for these SDN planners.
One of the companies is a service provider looking at SDN to redo their access and metro network architecture, and in particular to combine Ethernet and Optics more efficiently. They had been very interested in the evolving OpenFlow for optics specification, but as they got into OpenDaylight as a means of making NaaS evolution more accommodating to new NaaS models, they realized that the OpenDaylight approach could be used to eliminate the need for OpenFlow’s optical extension. Why not just put a plugin at the bottom of OpenDaylight that talks the language of the current optical network? Whether OpenFlow’s optical extension is useful or not (“not” is my own choice), it’s obvious to my carrier friends that in the near term the devices don’t support it. Why invent a new control protocol and refit devices to use it when the old protocols would work via OpenDaylight?
I think that this illustrates an important point about OpenDaylight, which is that we should think of it not as an SDN strategy but as a NaaS strategy. It could be, for networking in general, what OpenStack’s Neutron is to cloud networking. You frame a NaaS in the top layer of ODL’s stack then push control out a plugin at the bottom in a way that’s appropriate to the devices you’re using—new or old.
In NFV terms, this means that you could view OpenDaylight as a kind of Infrastructure Manager that crosses between the two models of IM that the ISG has been kicking around. You could use OpenDaylight as an element of a Virtual Infrastructure Manager to connect cloud elements, essentially an implementation of Neutron. You could also use it as what some are calling a Wide-area Infrastructure Manager (WIM) that’s used to connect NFV data centers or even connect NFV service zones to metro/access and WAN services created through legacy technology.
In terms of industry history, OpenDaylight evolved out of the ONF’s efforts, but I wonder if OpenDaylight might now have surpassed its teacher. Should we be thinking about SDN and NFV and the cloud in terms of NaaS and OpenDaylight and leaving OpenFlow as a device control option? My conversation with some SDN prospects suggests that might be a good plan.