Software Defined Networking, also known as SDN, is the latest 'big thing' in the field of networking. There are currently many approaches to it, but SDN began with the basic idea of decoupling the control plane from the data plane of a network device. This means that, instead of running everything on a single box (switch or router, for example), the control plane runs from somewhere else.
As time passed, SDN evolved to include automation/orchestration, hypervisor switches, overlay networks, APIs, Open Source software running on OEM switches, x86 network acceleration and even WDM. It is now a term with different meanings to different people, although all converge to something related to the ideas mentioned above.
Another technology worth mentioning is NFV, or Network Function Virtualization. It is complementary to, but not dependent on, SDN. It usually means the virtualization of a network device, which in certain ways overlaps with the definition of SDN. Network Function Virtualization originated on the service provider landscape and aims for rapid virtualization of current network services, while SDN is more related to creating new abstractions for the network.
With definitions out of the way, let's see what SDN brings to the table.
Control plane/ Data plane separation
As I mentioned before, this is where it all started. The main protocol behind it is OpenFlow, whereby a controller (control plane) that is running anywhere on your network (physical server, VM, etc) programs one or more switches by installing flow rules on its data plane. With this architecture an OpenFlow controller has the full view of the network instead of relying on distributed routing protocols. This brings better visibility as well as a better pace of innovation, as one could update the controller logic on the fly while keeping the OpenFlow switch the same.
OpenFlow switches are starting to become available with most vendors you know. Pica8 is a new company that solely focuses on OpenFlow switches. There are many different controller softwares as well, the most well-known being OpenDaylight.
As a sidenote, OpenFlow continues to evolve, now with a "core + edge" approach.
This is more related to automation and orchestration. An OpenStack cloud using Neutron (previously called Quantum) could automatically deploy its network requirements by provisioning and configuring vSwitches. The Open vSwitch project is the most well known software for this purpose. Many companies are supporting it as well as OpenFlow. There is also a Cisco Nexus 1000V and VMWare vswitch.
The idea behind this is that the physical network can be simplified and designed with layer 3 protocols, which are scalable and reliable (after all, this is how the internet was built). Another option would be removing Spanning-Tree from the network and running a TRILL fabric. The Overlay Network would run on top of this physical infrastructure, designed with whatever network topology is needed for the task. This is usually done using vSwitches, but a hardware 'exit point' is needed in order to talk with the 'legacy' network.
This type of solution is gaining momentum, especially after the announcement of the VMWare NSX solution. Midokura also has an interesting solution. Protocols used for this are VXLAN, NVGRE and STT. Unfortunately, as of September 2013, these are all still IETF drafts and not finished RFCs, so keep an eye on future developments of these technologies.
The idea is that you can programmatically configure the network by using a reference API across all devices. The concepts and protocols are the same, but instead of having templates and configuring the devices using the CLI, software could instead get the input data and configure all devices, without the operator having to login on each one. The main pusher for this is Cisco with its OnePK platform.
Open Source software running on OEM switches
Its purpose is to do for the network the same that was done to the server environment many years ago. This is an OEM hardware switch that allows you to run an Open Source operating system on it, instead of relying on proprietary and closed source OS. Cumulus Networks is the company leading this effort. This would tie in very well with the vSwitch and OpenFlow controllers, bringing down the hardware price and leaving lots of room for controller innovation.
x86 network acceleration
Intel DPDK is the main contender here. It provides libraries and drivers for fast packet processing on standard x86 platforms. Any vSwitch running on Intel processors will most likely want to take advantage of using this instead of the common Linux drivers. However, DPDK is not a network stack, it simply accelerates the receiving and sending of packets on the hardware.
Plexxi is behind this one. The idea is that we can do a lot with virtual networks, but ultimately the packets must be physically forwarded. By using WDM, the physical network can adapt and assign more or less bandwidth to the required applications over time.
Software Defined Networking is not a solution in itself, nor is it a product that one can buy. Rather, it is a blanket term for all efforts towards better network architectures. Having this fertile environment will make great solutions come together and certainly change the way we do networking.
To find out more about SDN, and gain some hands-on learning, check out the workshop Cybera will be hosting at the 2013 Cyber Summit in Banff this November.