Hubbard Talks AT&T's SDN Strategy

Early last year, AT&T CEO John Donovan blogged that AT&T is "becoming a software company." SDN-related developments since then demonstrate that Ma Bell 2.0 is putting its money where its mouth is.

Since Donovan's March 2015 blogpost, software-defined digital transformation has -- well -- defined AT&T Inc. (NYSE: T) and its networks. Between AT&T Integrated Cloud (AIC), AT&T FlexWare (née "Network on Demand"), and even SD-WAN integration with AT&T's Multiprotocol Label Switching ("MPLS") network, the telco has hyper-focused on virtualization.

Telco Transformation reached out to Rick Hubbard, AT&T's senior vice president of network product management, to talk SDN deployments, strategy, and modus operandi.

Here, in Part 1 of his Q&A with Telco Transformation (edited lightly for clarity and length), Hubbard outlines AT&T's present SDN projects, their cost benefits for customers, and how they aid in DevOps. Later, in Part 2, Hubbard will address AT&T's tactics for dealing with security perceptions of SDN, forging virtualization partnerships, particular verticals' demand for SDN solutions, and scaling up platforms with SDN.

Telco Transformation: Where does AT&T already use SDN technologies, and where is AT&T looking to deploy and/or expand SDN in the future?

Rick Hubbard: We introduced a product a few months ago called AT&T Collaborate. It's our hosted voice product where we have created 17 VNFs ourselves to facilitate voice through our infrastructure… It is definitely the underpinning -- taking our core, purpose-built infrastructure and moving it into a more virtualized cloud base. Our Network on Demand platform that started with an Internet product on demand -- as we call it, "switched Ethernet on Demand" -- was our first instance, followed quickly thereafter by NFV, which we have named FlexWare. … And then the third is our new hybrid SD-WAN product that we announced last week. The whole of SDN-enabling is not only important to our own infrastructure for us to get our own flexibility, development costs, and price points that we need, but then we're taking that learning and turning it around into finished goods for the market. (See .)

TT: What are the cost savings to be seen with your SDN deployments?

RH: Customers are looking to upgrade their access to get higher speeds, and SD-WAN enables them to get higher-speed access at a lower price for speed by combining with MPLS. We believe pretty strongly in our MPLS. We're the market leader in MPLS; we've got a big base of customers globally. Customers are not all going to be moving overnight from an MPLS architecture to a complete over-the-top SD-WAN architecture. However, what they are gonna do is ask: "How are we gonna get more speed per location as I get more applications coming on to my endpoint?" If you site-type your network, then you have a couple of choices. On the very important sites, you might want to put dual MPLS links in. On medium-importance sites, you might want to do an MPLS link plus a broadband link, and that is one of the major promises of SD-WAN, because previously a customer that used an MPLS link may have upgraded the MPLS link to get more speed. Now what they may do is keep the MPLS link at a given speed, augment it with an Internet link, put it in with an SD-WAN technology, and now they can run their most important traffic over their MPLS network. They can drain the less important traffic onto the Internet locally. If the customers are truly looking for access-economics savings, then SD-WAN is a promising technology.

With the other SDN features, it really gets down to software development. That's the part where there's more of a debate.

TT: Then let's talk about that in terms of DevOps. How do you see SDN and other virtualization technologies enabling developers and DevOps?

RH: To us, it's a speed-to-market favorability. As we take the core of our network and we turn it into a cloud-based infrastructure, we've got a platform and other people can develop to it. If it becomes an ecosystem where you get more developers that are writing to the way you set your platform up, it's a significant time-to-market improvement.

Let's take one of our products, which we've virtualized, like a voice product. I may only need four nodes in order to get complete redundancy across the US -- and then tomorrow I want to take that product and make it global. It's the exact same AIC infrastructure that you would have overseas. Historically, you may have a different DevOps project; just … take your product and put it in … London and put it in Frankfurt. Tomorrow, you already have the bulk of that development done because you've standardized on a platform. That's going to be one of the keys. As folks standardize on a platform, the speed to market is already markedly better than it was under a hard-coded DevOps model.

— Joe Stanganelli, Contributing Writer, Telco Transformation