A Guide to Software Defined Networks
A comprehensive collection of articles, videos and more, hand-picked by our editors
Remember when every large organisation had its own telecoms department? Highly skilled and dedicated engineers who went around installing cabling, terminals and phone sets along with ensuring the key systems (such as the specialised control centre used by the receptionist) were in place and that enough lines were provided for incoming and outgoing calls to meet demand?
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Ever wondered what happened to them? The world changed -- that's what. The world of telecommunications became easier -- driven by the use of voice over IP (VoIP) and the IT department's capability to carry out a lot of the tasks that the old telecommunications group did. Sure, facilities still send out the new handsets -- but the employee is perfectly capable of plugging these into the system themselves and IT then automatically provisions them.
Anyone who sees themselves as anetwork professional should be ensuring that they fully understand what SDN means for them and adapting to ensure that they still have a meaningful part to play in managing the future IT platform.
Historically, the network has provided the foundations for everything above it in the IT stack.
Without a network, no-one would be able to connect to an application being run on a server. No data would be able to flow from one application to another, or from one organisation to another. The network is king, yet it was rapidly becoming the main constraint on the overall platform.
As virtualisation took off, servers and storage moved to being pools of resources that could be allocated and used as needed. Unfortunately, although a TCP /IP network is essentially a virtualised system with packets being routed as needed to ensure delivery, the way the virtualisation was generally implemented was not best suited to supporting the needs of the virtualised servers and storage.
The main issue lay with the hierarchical nature of datacentre networks. Access switches fed into aggregation switches which then fed into core switches. Data flows in what is termed east-west traffic -- between applications on different servers -- and has to travel up and down the hierarchy in order to find paths that are connected between the servers. Attempting to put in place an everything-connected- to-everything topology runs into looping issues -- data paths replicate and get in each other's way.
To get around this, spanning tree protocol (STP ) is used, which automatically shuts down redundant data loops. This leads to physical ports being shut down in the network -- and also to a buildup of data latency in the system. If there was a failure in the network, STP could recover -- but it would take seconds, and would impact the availability of the overall system. Link aggregation groups (LAGs) were designed to provide an alternative failover mechanism, but these are really only suitable for physical systems, as they work against manual policies. Attempts to introduce virtual LAGs (vLAGs) only highlighted the problems with the way networks are implemented. SDN offers a big improvement. It emerged out of Stanford University in the US and provides the capability to move a large proportion of the work a switch does from the switch itself to an abstracted software layer. By taking the management and control planes out of the physical switch and creating a virtualised fabric where decisions can be made on how to deal with data at an abstracted level, the physical switch can concentrate on the data plane activity itself -- and be far more efficient for it. The project was spun off to the Open Networking Foundation (ONF), and the group's instantiation of SDN, OpenFlow, has become the standard for how new generation switches operate.
In simple terms, a switch has three main components when it comes to how it functions -- a data plane, which deals with how the data is moved through the switch's various ports; a management plane, which deals with how data and the overall network topology is managed; and a control plane, which deals with the overall network map of how to deal with different types of data packet and how they should be routed. The idea of a "fabric" network was born -- a flatter system with fewer layers. Top-of-rack and end-of-row switches started to come to market with built-in virtualisation capabilities including Cisco's Nexus and Blade Networking Technologies (now IBM System Networking). Physical ports can be virtualised and aggregated at will, with data flows being more controlled and data loops done away with. Fewer hops means less latency, so east-west data transfers are far speedier and north-south traffic (that from the end-user's device - PC, laptop, slate, tablet or smartphone - to the enterprise applications) is also optimised. The biggest change is that a lot of network moves from the switch operating system (e.g. Cisco's IOS , Juniper's Junos) to a more standardised software environment that can be run on commodity servers. The general IT staff can start to do things with the network that only network professionals could do before.
But what does this mean to the markets? Cisco (both through Nexus and also the acquisition of vCider and Cariden), IBM and other big suppliers have taken to SDN rapidly to try and maintain their hold on their customers, perceiving that a "carry on regardless" strategy would see them lose to those who did embrace SDN. HP and Dell are embracing SDN as well -- both to keep existing customers and also to try and get a foot in the door in organisations where the incumbent could now be under threat. A raft of new switch suppliers is springing up -- companies like Pica8, NoviFlow, Plexxi and Big Switch Networks are launching switches that either make the most of using SDN to provide high speed, high throughput switches or use SDN to enable them to sell relatively simple switch hardware combined with commodity-based SDN software servers to compete against the incumbents such as Cisco and Juniper.
Others are taking a different approach -- Plumgrid and Embrane are focusing more on the software side of things, taking the bet that the "new" network will require new capabilities, and that SDN will enable a crossover between IT and networking. They are looking to provide software that drives this crossover and creates a new network application market.
Another, LineRate, provided network management systems which will carry out the kind of functions that dedicated appliances do now, such as network security, load balancing and firewall capabilities, and was rapidly snapped up by F5 Networks. For established network appliance suppliers, such as Riverbed, SilverPeak, Imprivata, CheckPoint, Barracuda Networks and Palo Alto Networks, SDN could be a major force for change in how they operate, with a move towards a more software-oriented approach layered onto the fabric of the new network.
SDN is also affecting others in the computing market -- VMware acquired Nicira to add SDN capability to its portfolio. Oracle acquired Xsigo. Juniper bought Contrail -- but also made a statement to the markets that it is likely to come up with its own version of an SDN, which may not be an implementation of OpenFlow, although it is to be hoped that it will be compatible at a functional level.
All this activity -- with more predicted to come - shows that SDN is a force that will be hard to stop. It is time to understand SDN and OpenFlow and how this will change the world of network professionals, who can no longer pretend that SDN will not happen. They need to identify how SDN can be used to provide a more flexible and effective overall technology platform for supporting their organisation -- having these skills will add a lot of weight to their CV. By working together with the application and data professionals, the next generation networking guru will be the person who can craft the right kind of SDN software that interoperates and integrates with the stack above it in the best possible way. The hardware will increasingly commoditise -- it is a waste of time focusing there. This brings into play existing network skills -- vendor specific accreditations such as the Cisco Certified Network Associate and Professional (CCN A/P) and Design Associate (CC DA) will have to adapt to reflect a major change from hardware to software focus. Re-training will be needed, as new professionals come through with recognised certifications in SDN skills.
For many, it will be tough to move across the boundary and see the world in the form of functional software items abstracted from the hardware. However, it is the way forward, and an SDN architecture will provide the best flexibility and support for a modern organisation.