Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Cisco reveals OpenFlow SDN killer

Jim Duffy | April 3, 2014
OpFlex protocol for ACI offered to IETF, OpenDaylight.

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.

"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.


1  2  Next Page 

Sign up for CIO Asia eNewsletters.