Tangled Network

An Insurmountable Problem for SDN?

Tangled NetworkSoftware defined networking (SDN) is — in theory — a great idea.  By abstracting the control and management functions of a network from the physical boxes, the intelligence that is generally carried out through expensive operating systems and firmware held on proprietary silicon in the form of ASICs and FPGAs in individual network hardware items can be placed on commodity servers. This then provides a common means of dealing with network needs and leaving the switches to deal with the grunt work of actually routing the data packets as required.

As I say, great — in theory.  The problems begin to appear when this is done in practice.

On the whole, SDN should be OK for the average business with an average commercial data center. Data transmission needs can be dealt with through the virtualization of the network and aggregated linking of available bandwidth to provide the high speed links that are required for the movement of data packets between the data plane (the part of the network still being managed by the switches) and the management and control planes (carried out by the more commodity-based servers).

However — put this into a major cloud or other service provider, or a carrier, and the problems start to occur.

Now, performance is not only a key consideration, it is close to being THE consideration.  If every packet of data has to be moved from the main data plane up to a different level and then back down again, the latency that this will create in the network will be too much for the service providers — and its customers — to bear.

What is needed — and what seems to be happening — is more intelligence in how SDN deals with data packets.  As long as a packet of data has been adequately identified, then the data plane should be able to deal with this in a straight-through manner, without the need for the packet to be brought back into the management and control planes.

Simple enough, but this brings with it a raft of other possible issues.  If a blackhat could spoof a packet, then there would be no intelligence in the switches to identify that the packet is bad: once designated as “safe”, the packet would be able to travel at will around a network.

There is an obvious way around this: build intelligence into the switch so that packets can be inspected and ensured as being good while they are at the data plane.

So therein lies the problem.  SDN is a brilliant idea in that it separates out the data plane and the control and management planes.  The problem is that the data plane has little to no intelligence.  To put back the intelligence means moving some of the functions of the control and management planes down to the switch.  And what do you then have?  An intelligent switch — pretty much like we already have from the likes of Cisco, Juniper and others.

Is this an insuperable problem for SDN?  No — what is more likely to be the end result is a range of systems that range from the fully SDN-compliant (switches with little intelligence suited for general network use); systems that are “SDN-lite” (switches that use SDN as an overarching management and control system, but with a degree of intelligence built-in to the switch used for core networking in general commercial use); and SDN-compatible systems (switches that are fully stand-alone in their capabilities, but that will operate as peers within an overall SDN environment, used in core networks in massively high data throughput environments).

Is this totally elegant as a solution?  No — but I believe that it is likely to be the best that we can expect.

Image credit: Bruno Girin (flickr)

About the author
Clive Longbottom
  • Joshua Toon

    Maybe I’m wrong, but I don’t think that anyone has been talking about “per flow” decision making, if you will, for figuring the forwarding path. You are totally right that it would incur a latency cost that was unacceptable. As I understand it the control plane would build a set of rules that would be loaded into a switch that would serve as a “pre-calculated” forwarding decision for most traffic…One assumes that this would include any new service and it’s interop with existing services. Even this would be 100% more agile than the current hands-on configuration steps that need to be taken…and far more scalable than the “all vlan’s to every VMware server” that I keep seeing.

    It also seems like you are thinking about some kind of SDN firewalling system that would need deep packet inspection. I agree that is out of reach with SDN, or anything else. I would say that SDN might allow developers to build more comprehensive identity awareness into the network which would allow much more granular access control…but I’ve seen no one talking about that kind of thing yet. Its still early on in this thing…