This article is more than 1 year old

Broadcom's Ram Velaga on OpenNSL and silicon

Use-case will reach beyond switch vendors

One of the reasons Facebook has been driving the Open Compute Project is to break the network switch market out of its long habit of being proprietary on the inside. Broadcom's decision to adopt the Open Network Switch Library (OpenNSL) is a big shift in that space, so The Register talked to Ram Velaga, senior VP of Broadcom's network switch group, to fill in the thinking behind the decision.

Velage said the decision to open Broadcom's switch API to OpenNSL sits in the context of a developing strategy to become more open first seen in its decision to adopt OpenFlow Data Plane Abstractions (DPA).

“There are a lot of ecosystems developing around OpenFlow, but trying to map it to silicon that's already out there isn't easy,” Velaga explained. “We developed an abstraction layer so that third party users, end users and OEMs, could leverage the DPA software.”

OpenNSL is, Velaga said, the “next vector” towards enabling more ecosystem development.

At first glance, OpenNSL's use-case is obvious: people using Broadcom's merchant silicon to develop open switches can include the APIs to fit into the OCP – and ultimately other open networking – ecosystem. In return, Broadcom gets a better foothold in the emerging open networking market.

“We've written OS software for monitoring and instrumentation of the network, so an OEM running their own Layer 2 / Layer 3 software can run the new blob – the API exposes the information to the application software.

However, Velaga told El Reg, other use cases are already emerging.

A carrier running a large IP network, he pointed out, gets hardware and software and stacks as what amounts to a black box – but there might be reasons the carrier wants to use a different BGP stack.

“The carrier might tell the vendor 'I want to do business with you, but in this particular application I want a different Layer 3 module'.”

That's difficult if the vendor is under NDA from Broadcom not to expose its interfaces, but with OpenNSL in place, the vendor can say ““yes, you can do this – I can pass the layer 3 APIs to my software, and you can work with another Layer 3 stack there.”

“It's hard to imagine on day one what all the use-cases are. We've had OEMs tell us their customers want to see the switch because they want better instrumentation, better troubleshooting, better load balancing, or because they have a particular SDN controller and they want to program their own routes into it,” he said.

Keeping in mind that Broadcom's OpenNSL APIs were particularly identified as supporting the company's Tomahawk and Trident II chips, Vulture South asked whether there were plans to OpenNSL-enable older silicon, or if this represents a “line in the sand” to which future silicon will comply.

Velaga said the APIs “should” be backwards compatible to a degree. “Our SDK APIs are generally backwards compatible – if we expose an API it benefits multiple generations of the chips.

However, he said, the focus is the future: “we will look at more use-cases, look at what the ecosystem is using” – and that will form the basis of future moves.

Since there remains an air-gap between the APIs exposed in Broadcom's OpenNSL project and what's happening on-chip, The Register asked how Broadcom defines the difference between what it can show the world, and on the other hand, how to protect the “crown jewels” of its on-chip secrets.

“The key for us here is to make sure the implementation of these features is what we want to be careful about not exposing, not the feature itself.

“As we expand the scope of OpenNSL, t's about keeping the implementation separated from the functionality. We're not trying to hide the functionality itself.” ®

More about

More about

More about

TIP US OFF

Send us news


Other stories you might like