True revolutions are pretty rare, especially these days when hype seems to get a decade or more out in front of reality, tapping off all the interest before there’s even anything to buy or deploy. Evolution is something that you generally don’t have to worry (or write) about; timelines are long enough to allow for orderly accommodation by normal business means. Sometimes it’s the stuff in between (an “evrevolution?”) that can be really interesting, and we have an example of two in-betweens today in the SDN and NFV space.
In the SDN space, I’ve been saying that there are two models or layers emerging—the “shallow” SDN that supports tunnel-overlay software-based virtual networks and the “deep” SDN that actually involves network devices and (perhaps) new protocols like OpenFlow. One of the things that I think is a key differentiating point for SDN is end-to-end support, meaning the ability to extend an SDN from the classical data center starting-point to an arbitrary user access point. For shallow SDN, this presents a challenge because the access point would have to be equipped with a software agent to terminate the tunnels and support the protocols used. For deep SDN, the challenge is that the wider the scope of an SDN domain the less experience we have with creating and managing one.
What now seems to be emerging, according to both network operators and some larger enterprises, is a notion of “long-tailed” SDN. With long-tailed SDN, you adopt deep-SDN principles in the data center or perhaps across multiple data centers, and you may even overlay this deep SDN with shallow-SDN-based virtual partitioning of applications/users. But instead of pushing either the deep or shallow SDN models out to branch offices, for example, you rely on policy management based on information about applications you’ve gathered at the data center. You apply policies in the “tail” connections of SDN to extend your knowledge of traffic and user needs without extending SDNs physically and facing some of the challenges I’ve already noted. In the enterprise space, long-tailed SDN seems to have some real potential, but the challenge is creating some real utility. Absent some means of managing QoS in the WAN services used, enterprises can’t do much more with a long-tailed SDN concept than they could do with application performance management or acceleration. Which, I thinkwhere long-tailed SDN policy management marries with VPN services.
The other potentially interesting development is in the NFV space, where we have news that Akamai will be pushing the technology it acquired with Verivue last year to go after cable companies. Now one might wonder what this has to do with NFV, and the answer is that Verivue was the most cloud-ready of all of the CDN technologies, which makes it the most NFV-ready. And guess what? CDN was one of the target areas identified by the NFV white paper last year.
What I’m hearing is that there is a linkage, at least, between cable-CDN needs and federation, and between federation and WiFi roaming as a mobile broadband competitive strategy. MSOs generally don’t want to deploy their own cellular services but they do want to exploit their content to multiple devices. That leaves them with a hole; how to exploit mobile content when you don’t have 3G/4G services, and WiFi is the solution. But for most cable companies, WiFi deployment in a federated relationship with other cable companies is a better approach than spreading hot spots like Johnny Appleseed reputedly spread trees. However, to do this, you have to not only federate access, you have to federate CDNs. The reason is that you don’t want to deliver content traffic from your home area to a customer on another cable hot spot when that other cable company also has the content cached—perhaps a mile or less from your customer.
How stuff gets federated has been a major question, but it’s especially an NFV question because when you move to virtual function hosting as the basis for services, you have options to “virtually install” a “virtual function” in somebody else’s real infrastructure, and to otherwise share functionality in ways that would be impossible if your services were based on hard-wired devices. So the question here, given the explicit link between federation and Akamai’s offering to MSOs, is whether Akamai has some ideas. Might these guys be drivers in the federation area?
The unifying theme here? Well, we are likely seeing attempts to harmonize standards processes that weren’t launched top-down as the likely should have been with market realities that always start at the top, where the money is. Will SDN or NFV respond? We’ll see.