Neither fish nor fowl, Cisco's Application-Centric Infrastructure seems built to address so-called shortcomings of two main software-defined networking (SDN) camps

Craig Matsumoto, Editor-in-Chief, Light Reading

June 27, 2013

3 Min Read
Cisco's Insieme Doesn't Like Your SDN Model

There are two widely discussed architectures in software-defined networking (SDN) -- controllers and overlays -- and Cisco Systems Inc. spin-in Insieme Networks Inc. doesn't want to go with either of them.

Insieme revealed its "vision" at Cisco Live! on Wednesday but didn't describe what it's actually doing. In talking to Light Reading, officials didn't give any further detail, but they were happy to talk about the shortcomings of both controllers and overlays.

So, it seems Insieme's technology, called the Application-Centric Infrastructure, follows neither approach. Or maybe it mixes both of them. Take your best guess.

"It isn't so much about what you distribute as an overlay or a controller, or not. It's about taking that application view or security view, whatever is important at the time. The implementation of how you do it is less the issue than the end goal," says Ish Limkakeng, an Insieme vice president.

The overlay model involves virtual networks being created and destroyed at will on top of the physical network. That's what Nicira Networks Inc. (owned by VMware Inc.) and startup Plumgrid Inc. are doing. The controller model uses a centralized element or elements to make packet-forwarding decisions; this is how OpenFlow works, and it's what Big Switch Networks and many of the incumbent equipment vendors have been pursuing.

What makes these models so 2010 is the issue of running everything in software, Insieme and Cisco claim. Some visibility is lost; you can't always tell what overlay networks are being created, for instance. And Cisco claims both approaches hit performance limitations at scale, although plenty of SDN startups and non-startups have been working through that issue.

The big problem, Cisco claims, is that these models create new operational problems. For example, virtual structures like firewalls and load balancers don't always get taken down when their jobs are over. The network gets speckled with virtual elements "that everybody's afraid to touch because no one knows which parts are no longer needed, Limkakeng says.

Whatever Insieme is doing, Limkakeng says it involves a common operational model for the entire infrastructure -- or at least, the newer, Insieme-provided part of it.

That model will extend beyond Insieme's gear through APIs, letting other vendors' hardware or software participate in the SDN architecture.

Whatever Insieme is doing, it involves running some functions in ASICs. One such feature, mentioned during Wednesday's press conference, could be the ability to move virtual machines across different network domains, even if those domains don't use the same tunneling protocols for these moves. (VMware's VXLAN versus Microsoft Corp.'s NVGRE, for instance.)

Insieme's gear will be purpose-built for "application-centricity" just as Nexus, as an alternative to the Catalyst line of Ethernet switches, was built for virtualization, Kiran says. Cisco expects Insieme, Nexus and Catalyst to co-exist as ways of addressing different customer preferences for SDN and virtualization, or the lack thereof.

For more

  • Cisco Drops Hints About Insieme & SDN

  • Plumgrid Launches SDN Overlay Platform

  • Big Switch Pulls Back from OpenDaylight

  • Cisco Goes on Offense With SDN



— Craig Matsumoto, Managing Editor, Light Reading

About the Author(s)

Craig Matsumoto

Editor-in-Chief, Light Reading

Yes, THAT Craig Matsumoto – who used to be at Light Reading from 2002 until 2013 and then went away and did other stuff and now HE'S BACK! As Editor-in-Chief. Go Craig!!

Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.

You May Also Like