Application-centric networking? More like Cisco-centric networking

Call it the un-SDN, if you will. Cisco’s new Application-Centric Infrastructure (ACI) initiative promises to tackle networking problems only partially addressed by current software-defined networking.

Cisco does have a good sense of the problem at hand. Networks still have lousy notions of which applications run across them and can’t really tell what those apps need. Inspecting packets is slow and error-prone. There has to be a better way — ergo, says Cisco, ACI.

But is it the only better way?

The idea behind ACI is twofold. First, you have a piece of hardware (in this case, the newly introduced Nexus 9000 switch) that can run either with Cisco-native silicon or third-party chips that supply any number of standard SDN APIs. (Yes, OpenFlow is a third-party option.) Second, you have a software policy controller to define service levels and access privileges for applications using the network hardware. This approach spans both the physical and virtual domains, touted by Cisco as a big advantage.

Cisco claims the SDN problem can’t be solved by simply abstracting everything away from the hardware since that’s where the actual problems lie. But not everyone agrees with ACI as an answer, and not simply because it consists largely of (what else?) more Cisco hardware.

Cisco’s hardware vs. competitors’ SDN software

That hardware — mainly, the Nexus 9000 data center switch — comes from Cisco’s $800 million-plus spin-in purchase of Insieme Networks. It’s a startup Cisco funded for the sake of creating market-specific network products that flank rather than eclipse Cisco’s existing line and are solidly welded to Cisco’s bigger business plans.

That’s why it’s crucial to look at this in the light of Cisco’s competition — mainly VMware, HP, and the rest of the folks who’ve sunk heavily into OpenFlow as the pill for all SDN ills. Cisco doesn’t want to lose out to folks that can market generic switches with software overlays or ODM switches running Linux, nor does it want to be beaten to markets it’s yet to penetrate (such as storage and Layer 4-7 hardware) or areas where it’s feeling pressure from upstarts like Arista (high-speed low-latency switching).

But ignore the fact that Cisco is pushing more of its hardware as the solution to this problem. What’s still hazy about ACI, and one of its biggest possible drawbacks, is how it’s meant to be implemented with the very applications it’s supposed to help. Only a few details have emerged so far. As Jim Duffy reported in Network World, there’s a RESTful API, which implies that the applications themselves have to advertise intent to the controller.

It’s unclear if this requires reworking existing apps to be fully functional. If “the network is to be application aware” instead of vice versa, as Insieme’s senior director of technical marketing and solutions engineering Frank D’Agostino claimed, we need to see sooner rather than later how it works. Unfortunately, as Dan O’Shea of Light Reading notes, “Those wanting definitive answers may have to wait a little longer, as some aspects of the ACI portfolio will not be available until well into 2014.”

Physical and virtual networking need each other

Cisco isn’t alone in proposing an approach to fill in the gaps left by SDN. Another possible angle comes courtesy of network hardware outfit Plexxi, which also sees physical and virtual networking as being complementary and not exclusionary.

Mat Matthews, Plexxi’s co-founder and VP of product management, uses the term “affinity networking” to describe what it’s doing instead of “application-based networking.” Plexxi, too, supplies a hardware switch that’s driven by a software controller. But instead of using policies to determine the network, its system can also harvest information about what applications may be running by way of common automation tools (such as Puppet) and configure itself accordingly.

“We like Cisco’s approach,” Matthews said. “It’s good that one of the major [network hardware] incumbents has said that we need to do more with what applications need.” To him, this is far more complex than “programming a flow table from a switch based on an API,” and the OpenFlow approach, while interesting, “is not what we find the most interesting part of SDN. How the controller talks to the network is for us the last part of the equation.” Cisco is right, he attests, in the “need to create networking in both physical and virtual worlds.”

True enough. And if Cisco’s approach revolves more around protecting its 60 percent-plus market share as a network hardware vendor and striking pre-emptively at its competitors — and less about solving the very real problems that SDN is only beginning to address — Cisco’s going to find out the hard way it’s not the only one that can radically rethink SDN.

This article, “Application-centric networking? More like Cisco-centric networking,” was originally published at InfoWorld.com. Get the first word on what the important tech news really means with the InfoWorld Tech Watch blog. For the latest business technology news, follow InfoWorld.com on Twitter.