Cisco reveals OpenFlow SDN killer

At Interop this week, Cisco is unveiling an alternative to OpenFlow for software-defined networking and proposing it as a standard, while adding it as a vital component of the company's new programmable architecture.

Cisco's OpFlex protocol is intended to maintain control intelligence in the network infrastructure itself instead of centralizing it in a separate controller, which is the essence of the OpenFlow control/forwarding decoupling model. In so doing, OpFlex seeks to keep network infrastructure hardware as the foundational controlling element of the programmable network rather than just a forwarding servant to the centralized, software-based SDN controller.

In essence, Cisco is re-inventing the OpenFlow wheel, proposing a new protocol where one already exists, though its objective is different. OpFlex will be to Cisco's Application Centric Infrastructure (ACI) programmable networking architecture what OpenFlow is to SDNs.

+ MORE ON NETWORK WORLD: Cisco/Insieme ushering in hardware-defined networks | Hot products at Interop+

"There's no question that just as ACI will be Cisco's favored infrastructure offering for its customers' next-generation data centers, OpFlex will become Cisco's favored southbound protocol," says IDC analyst Brad Casemore. "In Cisco's world, OpenFlow will be for those customers who insist on having it as an option, and who are reluctant to dive into ACI in its entirety. Make no mistake, though: Cisco's priority is ACI and all the technologies that support it, including (the controller) and the southbound and northbound protocols that accompany it."

"The approach required for ACI is fundamentally different from OpenFlow and even OVSDB (the Open vSwitch Database Management protocol)," says Bob Laliberte of Enterprise Systems Group. "So it's not so much that they want to create another OpenFlow, but rather that they need something different to extract the value for ACI."

ACI employs a declarative model of forwarding control vs. OpenFlow's imperative model, Cisco claims. Under the declarative model, application policy is abstracted from the network, not network configuration as in the classical SDN imperative control model, according to Cisco.

When the ACI network receives an application policy from ACI's Application Policy Infrastructure Controller (APIC), the network decides how to configure itself rather than the controller dictating configuration. Cisco says this approach makes APIC more extensible to all network devices and simplifies integration of new infrastructure with a customer's preferred management, automation and cloud orchestration systems for automating the entire infrastructure. Cisco says it also allows the ACI infrastructure to achieve a level of scale and resiliency unattainable by existing SDN solutions.

In the imperative SDN model, applications, operations and infrastructure requirements must be translated to network configuration, making the controller a bottleneck as it manages increasing state, Cisco says. Application developers must still describe their requirements with low level constructs, which impairs ease of use, Cisco says. And classical SDNs support "lowest common denominator" feature sets, such as bridges, ports and tunnels, across a multivendor environment, according to Cisco.

"Cisco says [the declarative model] scales well, is well aligned with application-workload requirements, and is comparatively easy to manage, but there's no question that it also plays to Cisco's strategy of ensuring that network hardware retains autonomous intelligence, and value," says IDC's Casemore. "OpenFlow could not have served this role. It's meant to serve a model where the control and data planes are decoupled, and in which the switch's intelligence is limited to packet forwarding.

"Cisco has been quite consistent in describing this basic construct, so we should have expected something like OpFlex to surface before long," Casemore adds. "Now it's here."

Cisco is lining up ACI partners in physical and virtual switching, and Layer 4-7 network services, to support OpFlex and write to its APIs. Cisco is proposing it as a standard in the IETF and, with partners IBM, Plexxi and Midokura, submitting OpFlex to the OpenDaylight open source SDN project which it co-founded with IBM -- for an ACI-compatible policy model OpenDaylight plans to offer in its upcoming "Helium" release.

That ACI policy model submission will also include a northbound Group Policy API from Cisco's ACI work, the company said.

Cisco and industry partners are all contributing to this release, and OpenDaylight will ensure an "open" approach and transparency to Cisco's policy-based technology, Cisco says. Still, observers note a not-so-subtle Cisco bend in the direction OpenDaylight is taking."Cisco has been heavily involved with ODL from the start, along with IBM," says ESG's Laliberte. "So it's not a surprise that they would continue to shape and drive ODL."

"I don't know whether Cisco is wielding inordinate influence there, but it's clear Cisco is punching its weight in OpenDaylight -- and Cisco can pack quite a punch," adds Casemore. "The company has done stellar work ensuring that the possible outcomes enabled by OpenDaylight as a platform align with Cisco's product roadmaps and strategic initiatives."

In addition to ACI, Cisco plans to support OpFlex in its Nexus 9000 switches the hardware foundation of ACI -- Nexus 1000V virtual switch, ASR 9000 routers, Nexus 7000 switches and SourceFire security products.

Even though Cisco is the dominant networking vendor in the industry and OpFlex could become a de facto standard by default, the company still has its work cut out for it in explaining such a significant deviation from the SDN model embraced by the rest of the industry.

"While we are still early in the SDN transformation, it will be important for Cisco to clearly articulate why OpFlex is different and provide proof points that this approach is gaining traction with technology partners to deliver solutions that provide business value as well as accelerate the standards process as much as possible," says Laliberte.

Jim Duffy has been covering technology for over 27 years, 22 at Network World. He also writes The Cisco Connection blog and can be reached on Twitter @Jim_Duffy.

Read more about lan and wan in Network World's LAN & WAN section.