The big question for network operators is less how they might use SDN or NFV but how they might build their next-gen infrastructure to support an evolved business model. That question has been asked for a full decade now, and tellingly it was first called “transformation”. The term reflects a top-down vision that’s absent in most operator plans today. Interestingly, we’re starting to see some of the results of top-down plans, and we need to understand not only what’s happening but why it’s important. The challenge is that top-down is inherently less focused (operators each have their own businesses), and also that there’s a question of where you want the “top” to be.
SDN and NFV are technologies, not services. They are one of a family of stuff (including “IP convergence”) that emerged as technical options and matured through a long process into network deployment. Historically, the operators have started this long process with lab tests run by the Office of the CTO (or a similar title), and only about 15% of the stuff that gets a start ever goes on to be deployed in volume. SDN and NFV are in this lab-trial-by-CTO process now.
About five years ago, we saw a second pathway to change emerging. Some operators, including both US giants AT&T and Verizon, kicked off executive-committee-level projects to rethink how they built networks. To many, especially in the vendor community, these projects seemed rudderless, but what was different about them was that they started at the top, identified business goals, and then tried to work downward to realize them.
You could argue we have a meet-in-the-middle problem now, because the bottom-up CTO stuff has yet to build to a convincing business case, and until very recently the top-down stuff didn’t show any signs of being mapped to something you could buy and install. In 2015, though, we saw some changes in this picture. A few operators advanced, not by bridging the gap between two sets of projects, but by driving the top-down approach to the bottom where it could be deployed.
AT&T and Verizon have both talked publically about their initiatives, though not always in the same top-down way that they were planned. I’ve seen presentations from operators in Europe in Asia that follow the same general model:
- They start with the fact that service competition is really happening not between operators but between all operators and the OTT players.
- They point out that OTTs have the advantage of a very agile fast-fail approach to services, largely because their position in the network stack lets them be software-driven rather than dependent on long-life-cycle devices.
- They postulate an evolution to a software-based model, often calling their goal exactly that or sometimes calling it “virtualization”.
- They frame an approach that is very operations-centric both in focus and in how it evolves.
One thing that emerged from these top-down players in 2015 was a universal recognition that you needed to base future services on abstractions, and that these abstract service components had to first be mapped to legacy infrastructure. That need for legacy mapping is implicit in some operator presentations and very explicit in others, but it is part of every top-down pitch I saw last year. One result is that these operators tend to see “transformation” as being operations-driven rather than technology-driven.
Oracle played this trend quite well in 2015, making itself one of the six who could make a business case for NFV by casting its NFV strategy in an operations mold. Amdocs has just started an even more directed activity, blogging about the value of “intent models” in abstracting elements of services. Huawei, who has a credible NFV story and also an OSS/BSS story, hired away HP’s intent-model guru. These latter two developments happened just this month, which I think shows there’s momentum developing. If we do see OSS/BSS providers adopting intent-model abstraction, it could shift the momentum to them, even for pure NFV applications.
The challenge for operators in balancing “network” and “service” is that somebody has to do the network, and if you’re elected then you have to make the network work efficiently before you worry too much about competing above it. If you carry a loss into the higher layers from the network, when the OTTs dance along on top wild and free, you’re in trouble. A collateral challenge is that the network does provide some services, albeit the traditional ones with declining margins, and some of the service layer requirements would impact network-level service requirements. That’s particularly true when you consider “agility.” Operators have tended to get bogged down in network agility, thinking about composing connections and network features, but not the stuff above, where the OTTs are making the money.
If operators share a weakness of focusing too much on network agility not service agility, they share another in focusing on IoT as a gravy train to ride to 5G revenues as every device on the globe becomes a cellular customer. They have partnerships, including developer partnerships, and they call out analytics as a key element, but they don’t establish an architecture in which IoT could deploy, how it could harness current sensors and controllers, etc. This, from players who emphasize protection of their own assets in a network-level migration!
Despite all of this, operators are really committed to transformation, and in fact many are transforming. From AT&T, for example, we have insightful applications of SDN (and, I hear, eventually NFV) in Carrier Ethernet services and infrastructure. It’s clear that the pathway to agile networks and services is to create virtual networks at the physical level via SDN, partitioning current transport assets. You then pair them with hosted (initially, at least, on the premises) features to create business-level services. We also have their “Smart Cities” initiative, which lacks both transitional and architectural detail. AT&T has done a good job of pushing the limits of SDN and NFV, but it still needs to be pushing services at a higher layer.
AT&T’s initiative seem to meld nicely with the MEF’s “third network” approach. Most operators see broad collaboration among businesses they serve as a fertile opportunity, and Ethernet services could provide the connection reliably providing that the boundaries of the VLAN could be set more dynamically, and that there was a higher-level mechanism for controlling access to applications and information. As I said last week, contextual and collaborative processes seem the way of the future, and one of the network implications could be this “third network” as a connector between contextual process hosting points and IoT information repositories.
Operators’ tendency to focus on “network agility” has aroused media scorn; they say that operators don’t understand how OTTs can set up a service in a minute where operators take a long time. Well, it’s easy to add hosting onto a connection service somebody else is responsible for. Adding functions and processes to the connection services themselves creates major issues in security, privacy, and stability, and challenges in how to mediate development so it becomes symbiotic and not incompatible. Someone who commented on a past blog of mine pointed out an IETF draft from the NFV Research Group that talks about the need to work out connection models for virtual functions and identifies some of the limitations of current models and a suggestion for the future. I agree, of course; I’ve argued that we have a simplistic vision of “service graphs” that draws them but never manages to define the connection process suitably. That’s created what’s likely the largest integration problem for VNFs today.
And it could get even more complicated as we move into “service” agility in a true sense. IoT and other high-layer services are going to look web-like, as microservices, and they’ll need even more architectural order or developers will never be able to use them. Some operators make microservice evolution a part of their goal set, but they don’t define how they’ll get there. AT&T’s IoT framework does include a programming language for analytics access, but there’s still a need to paint the total picture, including how current sensor data and even non-IoT data can be introduced.
Operators know from long experience that you need a very well-defined architecture to build services. I believe that intent modeling and microservices will define that architecture, but it’s not defined yet and it’s not clear to me what processes will define it. In the meantime, operators are continuing with their top-down initiatives, creating network agility and hoping that the rest of the puzzle will come together.
The network-agility focus has rejuvenated some network vendors, who can claim a role in NFV because they can support SDN agility and connectivity and can host functions in an edge device. That, combined with the fact that a network-agility focus necessarily involves network equipment, may be promoting a stronger position for the network vendors at the expense of the IT vendors. But if Oracle and Amdocs work their magic on the operations/abstraction side, even the network vendors would be cut off from the business case, which of course is likely the goal for these two and also for Ericsson.
An OSS/BSS-centric approach creates the very real risk that abstracting infrastructure would actually allow operators to gain efficiency and agility without changing much at the network equipment level. That’s a point I raised in a blog last week, and network vendors might well think this was a good outcome. The problem is that once you wrap functionality in an intent model, it becomes difficult or impossible to differentiate implementations. It’s dark in that black box! That’s why intent modeling is so important for NFV integration; there’s no other way to do it in my view. Vendors may therefore have to balance forces.
Operators are doing that already. We will have transformation projects in 2016 that may include some SDN or NFV, but will be focused higher up. What I’m afraid of is that they will still not focus high enough, that they won’t see future services (including and especially IoT) as a kind of PaaS community that the operators themselves will have to define—using of course intent-model principles and microservices. If we miss that service layer it won’t stall transformation, but it will focus it on network efficiency and agility and perhaps foreclose operators from ever getting a real seat at the new-revenues table.