Sorry

SDN — An Apology

SorryOK.  I admit it.  When I first started looking into SDN, I fell for it.  Hook, line, sinker… in fact. the fishing rod and the fisherman as well.  The simplicity of it all was so dazzling that I suspended my normal cynicism and went for it.  SDN was going to change the world — Cisco, Juniper, and other intelligent switch manufacturers were dead, and we’d all be using $50 boxes within months as all the intelligence went to the software layer.

Well, hopefully I wasn’t that bad, and I have raised plenty of issues along the way, but I did miss one tiny little problem.  I’m OK with the idea of multiple planes, and I’m OK with two of them being as defined within the SDN environment.  However, there is one that still niggles: the control plane.

The data plane has to stay down at the hardware level.  If it wasn’t there, then the data couldn’t be moved around.  This could be filed under “a statement of the obvious”.

The management layer can, and should, be moved to the software layer.  The rules and policies to do with how data should be dealt with are better served by being up in the software layer, as a lot of the actions are dependent on what is happening at that level.

Great — we have two layers sorted.  Now the thorny issue of the control plane.  With SDN this is meant to be abstracted to the software layer too, but it just won’t work unless there is a great deal of intelligence at the hardware layer.  However, the hardware layer is meant to have little to no intelligence in an SDN environment.

The problem is that if every packet has to be dealt with via the control plane, then it needs to jump from the hardware to the software layer and back down again, introducing large amounts of latency into the system.  This may not be a problem for many commercial data centers, but it is a complete no-no for service providers.

So, to get around the latency issue, only those packets that need action taking on them should be sent up to the software layer.  This could work, but something has to decide what packets should go up to the software layer.  This would be something along the lines of, oh, I don’t know… how about a switch operating system and some clever ASICs or FPGAs? And while we’re at it, we may as well get rid of that last problem of SDN latency by not sending any of the packets to the software layer and do everything at the hardware layer — it is far more efficient and effective.

In other words, a switch as we already know it.

Does this mean that SDN is dead?  By no means.  Getting the management plane as an abstraction makes a great deal of sense.  Ensuring that the messages that the management plane sends down to the hardware and the messages the hardware sends back to the management plane are streamlined and effective will be key.  All switch manufacturers will need to support a common set of standards such that the entire network estate appears as a single resource pool and everything can be driven from software management layer.

Hardware manufacturers will still be able to differentiate on capabilities within their operating system and silicon, which may be good for the market anyway as this will still drive network innovation. SDN isn’t dead — it may be different to what I envisaged originally, but it will still change the world through driving a more standardized network, and in allowing the network to be integrated into the overall IT platform with greater ease.

Image credit: butupa (flickr)

About the author
Clive Longbottom
  • Lukas

    OpenFlow switches send to control plane only those packets that are not matched by any matching rule. So the slow communication overhead with control plane will happen only when something new appears in the communication going through the switch.

    It is generally not true that “every packet has to be dealt with via the control plane”.

  • Clive Longbottom

    Which sums up the piece – switches will still have to have a lot of intelligence within them to minimise the transfer of packets up and down the abstraction layer to minimise latency as an introduced issue. Therefore, you can still have an “OpenFlow” switch – but with the merchant silicon carrying out more bespoke actions – leading to the possibilities/probabilities of operability issues across what is meant to be an open standardised environment.