It’s another of those recap Fridays, to pick up news that was pushed aside by other developments and to try to drag some cohesion out of the general muddle of news. I think the theme of earnings calls for the week has been “an industry in transition” and so I’ll stay with that theme and fill in some interesting developments and rumors.
One rumor I particularly like is that Oracle is looking to develop a cloud-based voice service leveraging its Tekelec and Acme assets. The service would be, says the rumor, offered by Oracle directly at a wholesale level to operators who didn’t want to run their own voice networks, offered as a product package for operator replacement of legacy voice, or both.
Voice services are an increasing burden to operators, particularly in the wireless space. The problem is that you can do Google Voice or Skype or other free options over Internet dialtone, and in any event the younger generation doesn’t want to call at all—they text. The net result is that you have a fairly expensive infrastructure in place to serve a market that is only going to become less profitable and less a source of competitive differentiation. Most people in our surveys, speaking for themselves personally as voice users, say that if they didn’t have to worry about 911 service they’d probably not have paid voice service at all if the option existed. No surprise, a 911 solution is part of Oracle’s rumored plans.
A second development that’s not a rumor is some interesting concepts contributed to OpenDaylight. Recall that in that framework, and pretty much all OpenFlow controller architectures, there’s a northbound API set that connects what I’ll call “service applications” to OpenFlow. A service application is one that creates a connection network to support application/user needs; IP and Ethernet are legacy models of service connection networks, but other models are possible. Two are now being proposed by Plexxi and ConteXstream.
Plexxi is contributing its core Affinity concept, which is a dynamic way of visualizing connectivity needs at the virtual level, independent of actual network topology or physical infrastructure. It might be interesting to consider a framework for SDN that started with base-level adaptive forwarding and then built virtual network overlays based on Affinities. The key would be getting service properties pushed down as needed to create aggregate traffic handling rules. ConteXstream is contributing an application of Cisco’s proposed Location/Identifier Separation Protocol (LISP, another of those overloaded tech acronyms), which makes it possible to have assigned logical addresses and independent physical locators. This is yet another example of an SDN overlay mechanism, but it has interesting potential for mobility. Both demonstrate that SDN’s biggest value may lie in its ability to define “services” in a whole new way, unfettered by network hardware or legacy concepts.
Needless to say, none of these things are going to change the world overnight. Network virtualization faces both a conceptual and a practical barrier, and it’s not yet clear how either will be overcome. On the conceptual side, virtualization of networking opens a major can of worms regarding service assurance and management. If nothing is real, how do you send a tech to fix a problem, or even decide where the problem might lie? On the practical side, the services of the network will in today’s world be substantially constrained by the need to support current IP/Ethernet endpoints (or you have no users) and the need to support an orderly evolution from currently installed (and long-lived in depreciation terms) network assets. There’s also a both-issues question; how do you define middlebox functions in a virtual service? We depend on these functions for much of networking today. NFV might offer some answers, but the standards process there is ongoing.
You can argue that Oracle’s rumored service is an example of a virtual PSTN, and obviously the real developments I’ve cited here are also linked to virtualization. You can only pass real traffic on real links, so virtualization must inevitably map to the real world. You can only generate and deliver traffic to real users and applications, so there’s another real-world mapping. What is in between, in OSI terms, are the higher protocol layers. In network equipment terms, it’s the transport infrastructure. I think it’s clear that if we redefine the notion of “services” to take advantage of the agility of virtualization, we make the transport network a supporter of virtualization and not a supporter of users. What does that do to network equipment? My model says that in the next two years (through 2015) we’ll see an expansion in network capex driven primarily by metro build-out and cloud deployment but also by the opticalization of the core. After that, we’ll see a world where virtual missions for network devices gradually shifts value up to the stuff that does the virtualizing.
Amazon’s numbers may be a reflection of this same transition. The company has a heady stock price, one that could not possibly be sustained by its online retail business. The Street wants growth, which only the cloud and cloud-based services can bring. Amazon is going to have to lead the service charge to justify its P/E multiple, and that means investing to prepare for the mission, which raises costs and lowers profits. Their believers haven’t fled after unexpectedly bad profit news, likely because they realize that you have to bleed to heal, strategy-wise. Amazon is redefining the relationship between devices and networks, and that is what everyone has to accommodate over time. Along the way, they may end up redefining what we mean by SDN.