Mar 9, 2015
Three-legged stools can be found all over the place – bar stools, children’s stools, farmers’ milking stools are just a few. This isn’t because having three legs is cheaper than 4: it is actually that three legs are better than four in many cases. Take those four-legged chairs that you often find yourself having to wedge with beer mats or similar to stop them rocking – this doesn’t happen with 3 legs. 3 legs ensure that everything is in balance – even when the underlying floor is not so level.
And the same is true with networking. The initial promise of a single leg of Software-Defined Networking (SDN) has not been borne out: the need for data to bounce backward and forward between the data plane in hardware and the control and management planes in software has just proven too unusable for many in the high-speed data space.
This is why the operators and service providers had to come up with Network Functions Virtualization (NFV). By aggregating a set of network functions together as a single operation, the concept of SDN could be used, but with less chatter of data between software and hardware levels. Performance is improved as more operations can be carried out without referring back to either the control or management planes.
For super-high-speed data needs, however, this has proven to still not be enough. Where a bank needs to run real-time fraud detection, a pharmaceutical company needs to deal with terabytes of data in its hunt for the next new chemical or molecular entity, or an oil and gas exploration company needs to analyze the data from its seismic tests, line speed functionality becomes important.
To provide the sort of data speed required for high-performance computing requires at least some level of referring back to the hardware. Network operating systems, such as Cisco’s IOS and Juniper’s JunOS, were developed to deal with all aspects of the data – management, control, and data transfer. Although this meant that the switch or router could be tuned for the best data transfer rates, it did also mean that if one supplier did things in a different way to another, data transport became difficult. A lowest common denominator was required so that a switch from Vendor A could interoperate with a switch from Vendor B, and this often led to the need for specific software that could manage the potential loss of transport fidelity.
What is becoming apparent is that all these approaches are right… when used at the right time. For some network activity, SDN is just right – it is highly granular, highly flexible, and any network transport changes can be managed on commodity hardware through relatively simple software. NFV comes in where less granularity is required: it can aggregate SDN functions into larger network services, enabling faster processing of common data such as video, voice, and others where real-time is more important. By basing NFV on SDN, changes to SDN components can reflect through to NFV functions easily – far more quickly and effectively than having to change flash PROM, ASIC, or FPGA firmware code at the network hardware level itself.
However, that third leg of hardware intelligence will still be needed. Only by allowing some functions to be operated at line speed without the need to leave the network itself can the ultimate speed required by an increasing number of workloads be attained.
To make sure that this all works together, something has to have ultimate control. This is not going to be best served at the hardware level, as it would be far too tempting for the network vendors to fall back into the old ways of designing such that everything works better in a homogeneous environment of just their hardware. Nor will it be best served at the NFV level, as the level of granularity is too rough for the levels of control required.
It will be best served through SDN tools layered over the software-abstracted management plane. However, local area networks (LANs) have to talk to each other: here, SDN needs to extend across the wide area network (WAN).
To prevent the three-legged stool from becoming four-legged, it will be necessary to ensure that the software abstraction of network functions in the LAN & those in the WAN are functionally identical, and are managed through one single interface.
Therefore, the Software-Defined WAN (SD-WAN) has to be a sub-set of SDN.
By ensuring that SDN with SD-WAN works hand-in-glove with NFV and that the hardware retains an openness to work with the controls required by the abstract software planes, we will have a stable and comfortable network platform. If, however, each area is allowed to go its own way, then the resulting platform will be like a chair with many, different length legs: uncomfortable, prone to problems, and unloved by the occupier: the organization.