We’re in the throes of one show involving SDN and NFV and in less than 2 weeks, the SDN World Congress event where NFV was launched in the first place will be underway. It’s not surprising we’re getting a lot of SDN and NFV action, so let’s take a look at some of the main stories in more detail.
AT&T’s main spokesperson on things SDN and NFV, Margaret Chiosi, is calling for SDN APIs to support the abstractions at the service and network level. This to me is the best news of the day, even the week, because it is a comment beyond the usual hype and drivel we see on SDN/NFV these days. What takes it beyond is the “abstractions” reference.
You can’t have service without a service model. SDN has to be defined at the top by the services it presents, and these services then have to be mooshed against the network topology to create specific forwarding requirements. Absent any specific mechanism to describe either of these, the layers of SDN that I’ve called the “Cloudifier” (services) and the “Topologizer” (network) have no clear input and thus no clear mechanism for connection to software, networks, or much of anything.
We have specific examples of “Cloudifier” abstractions with OpenStack’s Neutron, but these abstractions are too server-specific and the process of enhancing them or adding to them isn’t flexible enough or tied enough to the general needs of telecom. We have a number of ways of describing network topology, but the only way we have to exchange topology in a reliable way comes from the adaptive behavior of devices and their advertising of routes. The purist center of SDN thinking is trying to eliminate both these things, so we surely need to know what replaces them.
Perhaps the lack of APIs, which would seem table stakes for software-defining any sort of network, is why Ciena is reported in LightReading as saying that we don’t take SDN seriously enough; “under-hyped” is the term reported. I’m reluctant to say that anything in this industry is under-hyped or even admit that state is possible to achieve, but the point Ciena is making is that new optical capacity can’t be used to direct bandwidth where it’s needed and thus some of the capacity improvements technology could bring are wasted.
Nay, I say. The problem isn’t getting bandwidth where it’s needed, it’s getting it to where somebody will pay for it. The challenge of SDN is that technology that impacts delivery can only impact costs. Technology that impacts experience can impact revenue, but the great masses of network service consumers won’t pay for “experiences” that are only improvements in capacity or network performance. In some cases, like here in the US, there are regulatory impediments to doing anything to make the Internet recognize premium handling.
This is what takes this back to the issue of APIs. If SDN could be made to offer service models that would enhance higher-level experiences it could actually link increased capacity to increased revenue. Content delivery is an example; the FCC exempts content delivery networks from net neutrality, so we’d be free to build one that extends close to the access point and offer premium handling on it. Can a content delivery network be built with current IP or Ethernet service models? Clearly it can, but if SDN is really valuable then it would have to be true that we could build a better one by building in custom forwarding rules—a new service model. That means APIs capable of supporting that, right Margaret?
At some levels, you could say that HP’s SDN ecosystem and Alcatel-Lucent’s NFV ecosystem, already announced, could address this, but that may be a stretch. Developer ecosystems are built around APIs more than they build the API. It is possible that the experiences gained by the two parties in their respective ecosystems would uncover the need for the kind of abstraction-tuned APIs that are essential to service models, but it’s far from certain. It’s also possible that competing vendors like Cisco, Ericsson, Huawei, Juniper, and NSN—or even IBM, Microsoft, or Oracle—could come up with the right answer here, but that’s even less certain. The dynamic of the network industry today is to fight like hell for the near-term dollar and let the future take care of itself. I don’t see how SDN is going to create enough near-term dollars without the ecosystem in place, which won’t happen till those APIs are popularized.
Another point that’s being raised, this one in an article by InformationWeek is that conflicting views of SDN implementation are at least now being recognized and explored. The article, about the conflict between physical and virtual visions of SDN, points out that some vendors (not surprisingly, network hardware vendors among them) view SDN control as applying to both physical and virtual devices while others say that ties one of SDN’s legs to a tree before the race.
Here again we have some good points, but not necessarily good discussions. I’ve said for months that SDN to succeed has to be made a two-layer model, where the top layer is totally virtual and agile and is directly controlled by software, and the bottom layer is controlled by policy to provide services to the top. This is actually the SDN model that gets the most deployment, but because we’re still not thinking in these terms, we’re not answering the critical questions. One is how the two layers interact—the boundary functions exposed by the bottom as services—and the other is how the policies are enforced onto the real infrastructure.
Which I think gets back to service models. We’re messing up a whole industry here because we can’t think in modern terms about the product of a network—the service model. I’m hoping that the SDN World Congress will at least raise awareness of that issue so we can get it behind us.