Unsensationalist SDN

SDN – Software Defined Networking – has become one of the trendy Silicon Valley buzzwords. Often abused and misused, it seems that all the marketing folks are looking at ways of passing what they already have on their product roadmaps as being “SDN”, while startups are hoping that it will bring in the latest tranche of VC money. Some folk would even have you believe that SDN can cook your toast, make your coffee and iron your shirts.

People are talking about massively centrally orchestrated networks, a move away from the distributed intelligence which on the wider Internet is one of it’s strong points. Yes, you could have a massive network with a single brain, and very centralised policy control, if that’s what you wanted. For some applications, it’s what you need – for instance in Google’s internal networks. But for others you may really need things to be more distributed. The way some people are talking, they make it sound like SDN is an “all or nothing” proposal.

But, is there a place for SDN between distributed and centralised intelligence that people are missing in the hype?

Put all the excitement to one side for a minute, and we’ll go back to basics.

The majority of large networking equipment today usually already has a distributed architecture, such that when a packet of data arrives that the receiving interface doesn’t know what to do with, it’s forwarded from the high-speed forwarding silicon to software running in a CPU. In some devices, there are multiple CPUs, often arranged in a hierarchy with a “master” CPU in charge of the overall system, and local CPUs delegated to run elements of the system, such as logical or physical groups of interfaces, or specific processes in the system.

When the forwarding hardware sends a packet to the CPU, to get a decision on what to do with it, it’s commonly known as a “CPU punt”.

The software running on the CPU examines the packet based on the configuration of the device, compares it against it’s internal tables and any configured policy, and makes a decision about what to do with it.

It sends the packet back to the forwarding engine, along with an instruction of how to program the forwarding hardware so that it knows what to do with other packets with the same properties (i.e. from the same data stream, or with the same destination address, etc.), whether that be to apply policy, forward it, drop it, etc.

This isn’t that different from how OpenFlow works, but the CPU is abstracted from the device in the data path and resides in a thing known as a “Controller”. Effectively, what were CPU punts now become messages to the OpenFlow Controller. The Controller, by nature of it residing on a more generalised computer, is capable of doing things that are less likely to be easily doable on the software running in a router or switch, in terms of making “special” decisions.

Basically, SDN in some respects looks like the next step in something we’ve been doing for years. It’s an evolution, does it need to be a revolution?

So, here’s where I think what’s currently a “missed trick” lies…

The forwarding hardware used in SDN doesn’t have to or need to be totally dumb. Some decisions you might be happy for it to make for itself. It could pick up details of what those are from the policy in the Controller, and these can be written to the local CPU and the local forwarding silicon.

But, other things you know you do want to “punt” to the Controller, get set up (through applied policy) and handled that way.

I can think of occasions in the past where I would have loved to be able to take the stream of CPU punts in a device that can otherwise happily make a lot of it’s own decisions and be able to farm them out for analysing and processing in such a way which wasn’t possible on the device, and convert this back to policy, config, and ultimately CAM programming. But, to be able to do this without basically lobotomising the device?

Does SDN have to be the “all or nothing” approach which seems to be what’s getting proposed by some of the SDN evangelists? Or is a hybrid approach more realistic and aligned with how we actually build networks?