Network functions virtualization (NFV) is at the heart of some major transformations for telecom operators, but it’s only going to work if it remains as open as possible, said Axel Clauberg, vice president of IP architecture and design at Deutsche Telekom.
Clauberg was talking this morning as a keynote speaker opening the Big Telecom Event, being put on by Light Reading in Chicago. He described how DT’s long-term plan helped feed the creation of NFV and also pointed out the thorny patches that still exist in that plan.
One concern for him is that vendors’ enthusiasm for NFV is leading to “a zoo of orchestrators,” where each vendor proposes its own variety of NFV management. What’s needed is a unified approach, one where all services are managed end-to-end.
The key to getting there, Clauberg thinks, is the use of open-source code. “This is a key focus area on my team,” he said. “We need open standards moving forward in this space — open standards and running code, and rough consensus, to take a third one from the IETF, are all things that have to come together.”
At the same time, Clauberg realizes NFV isn’t an easy change for equipment vendors.
“When we started the discussions around virtualizing network functions with our vendors, they were laughing at us: ‘Good proposal, but we’re never going to do it,'” he said. The reason was that the vendors would have to move to a software business model — a pretty serious lifestyle change.
But DT persisted. “For us, there’s no alternative. We had to force our vendors through,” Clauberg said. That’s partly why DT and other carriers formed the ETSI (ISG) for NFV; it was a way to push the NFV idea onto the industry.
Don’t underestimate how unusual that is. As Steve Saunders, Light Reading’s CEO, noted in an introductory talk today, NFV marks the first time that the service-provider technologists, rather than the vendors, are setting the technology agenda.
The rise of NFV doesn’t mean the death of hardware, Clauberg added. DT will still need specialized boxes such as core routers.
“Yes, a lot of the midrange [routers] will move into the infrastructure cloud, but we need the high end,” he said. His conclusion was that NFV “will be for the benefit of both sides. It’s just taking some time.”
The Software-Defined Operator
NFV is part of a bigger plan that DT and Clauberg have been pushing for a few years now: the idea of creating the software-defined operator.
Clauberg sees this model depending on three interlocking parts: an all-IP network, a set of telco-grade data centers (the aforementioned infrastructure cloud), and a real-time OSS.
On the surface, “all-IP” means that DT will replace its traditional telephone network. But Clauberg wants to go a step further, asking whether other data protocols could be retired, too.
There are lots of protocols in the telecom network today — “protocol bubbles,” Clauberg called them — and he thinks all of them could be eliminated in favor of an IP network. OTN, for optical transport, could be one candidate. More radically, he thinks MPLS could go, and with it, all its related protocols. He also thinks IPv4 could be chased out of the core network.
DT would still have to produce services based on some of these protocols, IPv4 most notably, so that’s where the infrastructure data center comes in. In addition to housing services, the data center would be the home for virtualized versions of these protocols, called up as needed. (So, yes, the infrastructure data center is very much tied to the NFV concept). Other functions already being virtualized include the broadband remote access server (B-RAS) and the IP Multimedia Subsystem infrastructure (IMS), Clauberg said.
There’s more to this than just replicating the telecom network in software. For example, the telecom requirement for high availability, which usually means building two of everything, can now be provided by just shifting work to other data centers if something goes sour. These data centers also need to be fully automated, Clauberg added, because otherwise, they just provide a new layer of complexity and cost.
The piece that might be most important, though, is the advent of a real-time OSS. It would represent a new way of running the network, not to mention a simplification over the hundreds of OSSs some telcos have amassed, and Clauberg thinks it’s necessary for bringing out the potential of NFV and the data center.
DT has been working on this for two years and is not nearly done with the job, he said. Some of the progress so far has been based on Yang data models — using Yang northbound, toward the billing support system (BSS) as well as southbound, into the network elements. “There’s a huge momentum right now on Yang and we see it as an opportunity even to get rid of element managers,” Clauberg said.
The DevOps Capper
All of this is capped off by a DevOps approach, naturally, and Clauberg gave the usual nods in that direction.
“The biggest problem for us as an operator is not technology. It’s: How do we make that happen with our teams?” Clauberg said. “We need a completely new skill mix” that includes IP, data-center operations, and programming, among other skills.
That’s a challenge on the human front, obviously, but it means the organization has to change, too. The agile processes that telecom needs — which involve iteration and backtracking as necessary — run counter to the “waterfall” approach of service creation that operators are accustomed to, Clauberg said. While Clauberg didn’t linger on that point, it might be the most crucial factor to overcome if DT, or anybody else, is to truly become a software-defined operator.