Software 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.