Cisco is this week 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 centralising 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 centralised, 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 favoured infrastructure offering for its customers’ next-generation data centres, OpFlex will become Cisco’s favoured southbound protocol,” said Brad Casemore, Analyst, IDC. “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),” said Bob Laliberte, 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.
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. And classical SDNs support “lowest common denominator” feature sets, such as bridges, ports and tunnels, across a multivendor environment.
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.”
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.
Related Articles
