The application-policy engine at the heart of Cisco‘s software-defined networking strategy is going open-source, and the reason is simple. In order to be a truly effective agent of change, the Application Policy Infrastructure Controller (APIC) is going to need someone to talk to.
What’s partly driving this is the fact that Cisco’s SDN approach, the Application-Centric Infrastructure (ACI), differs so much from what most of the industry has been discussing as “SDN.” That’s becoming clear as Cisco announces further ACI deals today at Interop in Las Vegas.
As a result, Cisco is trying to turn the industry’s attention toward policy-based SDN. It’s contributed the APIC to the OpenDaylight Project. And within OpenDaylight, Cisco has joined with IBM, Midokura, and Plexxi to propose a Group Policy model.
Moreover, Cisco wants to standardize the southbound protocol, OpFlex, that APIC uses to talk to network elements.
Cisco Pops OpFlex
Here’s what Cisco is announcing today:
- OpFlex, as mentioned above, is the southbound interface that APIC uses to communicate with network elements.Cisco hadn’t discussed this before.
- Cisco is submitting OpFlex to the IETF for standardization.
- Cisco is writing an OpFlex agent for Open vSwitch, to show how non-Cisco products can be included in the ACI framework. The OVS agent should be ready toward the end of the third quarter, says Shashi Kiran, a Cisco director of marketing.
- Several vendors are pledging to support OpFlex: Canonical, Citrix, Embrane, F5, IBM, Microsoft, and Red Hat. (Also Sourcefire, which Cisco now owns.)
- Then there’s the Group Policy proposal, which Cisco hopes to get into OpenDaylight’s Helium release in September. It would be ACI-compatible, of course.
Within the Cisco portfolio, OpFlex will be supported on the Nexus 9000 family (the primary vehicles for the ACI strategy), the Nexus 1000V virtual switch, the ASR 9000 edge routers, the Nexus 7000 data center switches, and the Sourcefire security products.
The Promise of Promise Theory
Since introducing ACI in November, Cisco has made it clear that the architecture revolves around policy. But there’s a radical implication that Cisco is spelling out today — namely: ACI, unlike OpenFlow and overlay networks, doesn’t configure network elements. Rather, it communicates policy information to them, via the APIC, and lets them configure themselves.
The user just tells the network she wants to deploy an app. She might define a few parameters, such as which pieces of the app need to communicate to one another. It would be up to ACI to decide how to make the necessary network connections happen.
The key here is that the user doesn’t have to know where particular VMs are located, what hypervisors are involved, or what versions of software are running out in the network, “because the policy is defined completely differently (separately) from where the infrastructure is,” says Mike Cohen, a director of product management who joined Cisco through its Insieme spin-in.
That model is based a computer-science discipline called promise theory, or the declarative model, and it represents a whole different way of running a network.
The regular way of doing things is the imperative model, where you’re telling equipment what to do, step by step. OpenFlow, which sends packet-forwarding instructions to switches, would be an example; for that matter, so is the general SDN idea of separating the control and data planes, Cohen says.
Cohen likens it to drawing a square on paper. Traditional networking is analogous to having someone tell you to draw one line, then a second line perpendicular to it, then — well, you get the idea.
Under promise theory, you’d get told to draw a square, and it would be up to you how to do it. You’d tell the requester that it can be done (the promise) and execute the command — or, if it couldn’t be done, you’d simply say so.
Insieme preferred this model partly because traditional networking resorts to “a least-common-denominator set of features” when it comes to interoperability, Cohen says. “If you look at network overlays, that’s effectively what happens: We make each network device a bridge with a couple of ports. With those three primitives, you can define compatibility, but you can’t do much else.”
The catch is that under promise theory, the two sides need a shared information model; they have to agree what “draw a square” means.
And that’s why Cisco is so determined to get OpFlex into the hands of OpenDaylight and the IETF. Cisco needs the industry to have a standardized interface for declarative control, and it needs a common information model to speak to. Otherwise, it could end up with an SDN framework that doesn’t talk to anybody else’s network, aside from speaking normal routing protocols at the edge. Cisco wants to have a deeper impact than that.
It would also help if OpFlex and ACI could spread to Cisco’s older equipment. Cisco has mentioned this before, but it’s going to be a challenge. In today’s announcements, all Cisco is saying about this issue is that it’s being worked on.
An Actual Customer
Who would implement ACI if it’s so different? Maybe a customer that’s got a new project that can be built in a nearly greenfield fashion.
Acxiom is evaluating ACI for its Audience Operating System (AOS) project, a software-as-a-service (SaaS) play that launched in September. It involves giving marketers and ad agencies access to mounds of audience data, and Acxiom would like to use SDN to scale the associated network up and down with demand.
Acxiom has deployed Nexus 9500 and 9300 switches already, running them in standalone mode (that is, using them as regular switches rather than as part of ACI). APIC is slated to come available in June, making full ACI deployment possible; Acxiom plans to test it out, throwing its hardest-to-deploy application at APIC as an initial test. If all goes well, a full ACI deployment could happen in January, according to Acxiom representatives who are here at Interop.
Cisco will be bringing out other Nexus and ACI customers to share the Interop stage as well.