AUSTIN, Texas — Telcos want to virtualize. AT&T, with its goals of 75 percent virtualization and 105 data centers by year's end, is a prime example. But their take on the distributed cloud has some wrinkles that ordinary data centers don't face.

That was the thesis behind an OpenStack Summit talk on Wednesday by Tobias Ford, AT&T's assistant vice president of cloud infrastructure, and Marco Rodrigues, a Juniper systems engineer. While telcos are moving functions into software, just like anybody else, they've got some unique requirements for their virtual network functions (VNFs) – not all of them driven by the five-nines obsession.

The goal is to create a world of cloud-native applications, Ford said. Here's what he meant by that:

• Scale. "If I'm getting more load in, the way to scale up is to add more virtual machines or containers, and I can do that infinitely." Obviously, you can't do that with physical equipment.
• Resilience. This gets back to telecom's five-nines (99.999 percent uptime) obsession. Cloud-native applications would run on servers, which aren't five-nines themselves. (Ford actually talked about six nines rather than five.) The way around this is to get resilience by hosting VNFs in multiple places – something many of them aren't built to do, he said.
• Modularity. Applications have to work "in an API model, where you're allowing yourself to be just a module in a virtual framework." That's a new world, where vendors have to give up some control of the stack – as do carriers, because they can't control the entire stack any more.

Those requirements are common to most applications that are moving to the cloud, even if they don't strictly need the five-nines part. But telecom does have a few problems with VNFs that seem unique to the service providers' realm, and those made up the bulk of the talk.

1. Getting performance out of general-purpose chips. Intel's x86 processors, in particular, weren't made for packet processing – a key function that telcos want to see in virtual form. One ongoing question is whether it's sensible to rely on single-root I/O virtualization (SR-IOV), which bypasses the server's x86 and offloads packet processing to a network interface card (NIC).

Part of what's missing is a standardized way to test and benchmark all the variables involved, Ford said. "That's been a lot harder than you can imagine."

2. Getting routers to truly scale out. This isn't just about getting virtual routers to work. "It's a lot about automation and configuration management and maybe not having a command line to log into your router."

The cloud might also be a chance to "refactor and simplify" the idea of what a router does, said Ford. "If we take a packet from the virtual machine [and send it] out of the building, you don't want to be opening it up and doing something too many times. Maybe there's a way to consolidate routing functions or consolidate load balancing and NAT'ing functions together."

3. Dealing with brownfield networks. This could be the most obvious of the telcos' problems: They can't just unplug the networks that are still serving customers, and those networks don't easily "cloudify."

The strategy here is to migrate networks to a virtualized form – running on servers rather than specialized networking equipment – as smoothly as practical, Rodrigues said. The burden for that rests on the cloud platform. Technologies that a physical network provides, such as a way to ping a function to see how it's doing, "are mechanisms that all these VNFs are going to want to be using" and must therefore be supported by the underlying cloud.

One thing to note about traditional networking gear is that each box came with its own orchestration tool, Ford said. "How do I take all of those things and transition them to a more common approach? It's one of the things we'd like to see the community do more of."

4. Telling people what carriers actually want. Ford admitted that carriers, as a group, haven't been great at this. OPNFV is meant to amend that, so he gave a quick pitch for the open source project.

"I want to sell everyone on the concept of OPNFV. There needs to be someone somewhere who brings it all together," he said. "We're doing everything we possibly can to document and enumerate what we're needing."

Another factor that would help would be to develop APIs and data models that are common across the industry. "You've got to get everyone talking, literally, the same structured language," Rodrigues said.