One of the people who read my blog sent me an email last week, asking why network operators listed operations efficiency, service agility, and capex reduction as their drivers for SDN and NFV and not “new services”. It’s a good question, insightful because in fact only about 10% of operators in my survey indicated they believed there were “new service” opportunities associated with SDN or NFV. It’s also hard to answer.
One reason it’s a hard question is that it’s obvious that the operators themselves are uncomfortable abandoning their dependence on pushing bits, or even pushing them differently. Over the last eight years, I’ve noticed a higher level of acceptance of new services as a cure for carrier revenue/profit stagnation, but even this has just made the operators interested in technical developments that would permit new services, not so much in driving those services themselves.
From the technology side, the easy starting point is to say that SDN and NFV are “infrastructure-side” technologies driven primarily by those in the operator community are responsible for infrastructure and operations planning. The business development people are typically not involved; in our survey about that same 10% said that they had significant bus-dev involvement in either SDN or NFV. The cloud, in fact, is the technology that is most likely to be associated with incremental service revenue.
That cloud/revenue link is also important in answering the question, because it’s also true that SDN is seen by all the operators as being primarily a cloud-support technology, though about a third give metro applications nearly equal weight. It’s also true that NFV is seen as a way of improving cloud operations and agility by over three-quarters of operators. That in combination frames both SDN and NFV as being subordinate in terms of new revenues.
This raises a couple of questions—first, is this lack of revenue linkage fair, and second is it an impediment to SDN/NFV deployment? The answer to the first question is “Yes” in that we really have not created a direct revenue link for either SDN or NFV that would stand up to serious scrutiny. The best we can do is postulate more revenue yield by shortening service turn-up times. The answer to the second is also “Yes”, and I think the fact that operators are more willing to leap into the cloud than to augment familiar practices and services with SDN or NFV is proof of that.
The second question is whether we could provide a direct link to new service revenues from either SDN or NFV. To answer that we have to remember that users pay for the service experience and not the service technology, so to empower either SDN or NFV with real revenue legs, we have to be able to build unique experiences with them. Can that be done? It’s obviously not being done well now, but could it be?
In the case of SDN, I think the answer is “Yes” if we step back and consider the impact of having atomic-level forwarding control on service behavior. We could create services like “Forward except on Thursdays” or “Quench Route back to the Source”. We could obviously do other services with more thought, services that are fundamentally different from the traditional connectionless or connection-oriented models of LINE, LAN, and TREE that dominate today. All of these represent what I’ve called “service models”, which are links between an experience or behavior that’s visible outside the black box of the service with a recipe for creating it within that box.
I’m sure you can see how my example service models could be created using the classic OpenFlow SDN model. The heavy lifting on the recipes would have to be done with those infamous “northbound APIs” where nobody seems to want to do anything today except replicate what we can do without SDN—Ethernet and IP. But the big problem is socializing those experiences/behaviors in the service buyer community. How do we make people want services they don’t now have and possibly can’t even get their heads around? We have a lot of work to be done in creating a realization that this sort of thing is even possible, and we don’t have much of an appetite for that sort of thing today, given that public network vendors are constrained to kiss Wall Street babies every quarter and don’t want to spend more on R&D and marketing but less.
And NFV is even more complicated. I’ve blogged here about the notion of contextual services and their value, and virtually everyone I’ve talked with agrees that this is likely the future of networking. Contextual services require a new model of application/service workflow, one that composes services extemporaneously based on user requests. Something dynamic and agile like NFV would be ideal for this, but it’s a service concept that’s recognized by its early examples (LBS, contextual search) but somehow not seen as a large iceberg under the current tip. Can the NFV community drive a better vision? Remember that it’s science and operations guys driving the bus.
I really think this is all due to a common, insidious, problem. Because we want to be able to demonstrate immediate implementation and monetization, we start everything at the bottom. We have built SDN from a protocol to control forwarding table entries, and Cisco is presenting a notion of policy-based networks that starts with a protocol that lets us push policies. What policies, what value, what service model lies behind any of this? If we were to say “I can build a service that is totally disconnected from today’s device and protocol limits” would we start by defining protocols and virtual devices? I don’t think so.
My model says there’s nearly a trillion dollars in “new” service opportunities that could be accessed, a pie large enough to make any service provider or network/IT vendor happy and change a lot of lives by introducing the new experiences and capabilities that this new stuff consists of. But we have to turn around a set of very entrenched practices, which isn’t easy without direction and drivers.
I’m convinced that contextual orchestration isn’t a long reach from the data-driven orchestration and management paradigms that seem to be emerging for the cloud, SDN, and NFV. What’s needed is a shift from a pure management vision (set up something and it runs based on internal rules) to the notion of service logic modeling. If the service logic is being assembled based on contextual needs, it’s the assembly part that’s new; once the “order” is completed then committing resources isn’t very different from provisioning except for the dynamism and duration of the commitment. Those impact the efficiency needs more than the basic logic or architecture.
I’d like to see some body take this up, but it’s not clear which would be best. The ONF, or NFV ISG or maybe OASIS or even the TMF? Whoever does it needs to clear their heads of low-level preconceptions though. We’ve had enough of those already.