What the Cisco XNC Controller Tells Us About OpenDaylight (Craig Matsumoto, SDxCentral)

Posted · Add Comment

Source: SDxCentral

The Cisco Extensible Network Controller (XNC) continues to be one of the most frequently viewed products in the SDxCentral directory. But you might have noticed that for some time, Cisco has been talking about its Open SDN Controller instead.

So, where did XNC go?

It’s been retired — and so have other controllers based on Hydrogen, the inaugural OpenDaylight code release. What happened has less to do with XNC and more with a fundamental change in the OpenDaylight architecture, one that was pushed by Cisco, among other vendors.

The Heart of OpenDaylight

The change was in the service abstraction layer, the part of the controller platform that sits just above southbound interfaces such as OpenFlow. It’s meant to insulate those interfaces from the northbound side, where the applications reside. That way, both sides — the applications and the network equipment — can talk to this abstraction layer, meaning you don’t need to worry if an application knows how to speak to a specific piece of equipment.

Hydrogen — OpenDaylight’s first code release, which came out in early 2014 — used an API-driven service abstraction layer (AD-SAL), built from Cisco’s XNC. But the AD-SAL had limitations — specifically, it would need to know about every type of device in the network. The introduction of a new interface would force an update to the device’s drivers and controllers.

The AD-SAL was too device-minded, in other words. “You would need an inventory of drivers to support a variety of devices and technologies: TL1, SNMP, Netconf, OpenFlow,” writes Mathieu Lemay, CEO of Inocybe, in an email to SDxCentral.

The key was that interfaces besides OpenFlow were coming into play. So even as Hydrogen was rolling out, Cisco helped push for an alternative: a model-driven service abstraction layer (MD-SAL), which Cisco representatives presented at the OpenDaylight Summit in February 2014. With MD-SAL, the authority figures are Yang models rather than device APIs. Applications can request changes to the model, and the abstraction layer forwards those requests to the network devices, as described in this Inocybe video:

With this model, the controller doesn’t have to account for the types of equipment installed in the network. A few people have told me it also has the effect of making OpenDaylight more modular; development teams can work more independently, and it’s easier to make their pieces or code operate together.

“This model-driven approach is what allows OpenDaylight to be a bunch of puzzle pieces to solve business cases of network agility and emerging services,” Lemay writes.

Submarines and Bathtubs

Here’s where Cisco XNC comes in: To accommodate MD-SAL, which first became available with OpenDaylight’sHelium release in late 2014, all OpenDaylight-based controller infrastructure would have to be tweaked. (AD-SAL was still usable at that point, but MD-SAL was clearly OpenDaylight’s future.)

Vendors that didn’t produce a Hydrogen-based controller were unaffected — Brocade, for example, didn’t issue a controller until Helium was out and therefore took advantage of MD-SAL right away.

Others had work to do. NEC, for instance, recently finished porting Virtual Tenant Networks, its network virtualization software, to accommodate MD-SAL, a spokeswoman notes. (The company doesn’t currently have an OpenDaylight-based controller shipping.)

HP, to pick another example, is still working on its OpenDaylight controller — although, in the meantime, the company has picked up some OpenDaylight-based code with the acquisition of ConteXtream.

In the latest OpenDaylight release, Lithium, AD-SAL was “depricated” — that’s the word Neela Jacques used in hisOpenDaylight Summit keynote earlier this week. And it will be gone entirely in Beryllium, the next release, which should arrive in early 2016.

Why does any of this matter? For one thing, MD-SAL is now a core element of OpenDaylight. It reflects the model-driven behavior you’ll get from any SDN controller built on the platform.

It’s also an example of how the OpenDaylight Project’s open model of collaboration works, because the MD-SAL wasn’t a slam dunk. People fought the idea, as Jacques explained in his keynote. They called it too complicated, like using “a submarine to cross a bathtub,” he said.

In the end, though, he’s proud that OpenDaylight struggled through the debates.

“This is the right long-term solution,” he said about MD-SAL. “It solves the problem in a fundamental way.”

Leave a Reply