The downside of SDN
Is software-defined networking positioned for large-scale conflict with legacy networking technology?
One of the so-called emerging architectures in the networking arena is SDN - software-defined networking. While SDN began as a conceptual extension of data centre virtualisation, it has advanced to the point where it is now able to orchestrate a reconfiguration of the network fabric, separating the network's control plane from the data plane in network switches and routers.
With SDN, the control plane is now implemented in software located in the network's servers, and applications on the servers now define how data packets are switched through the network. As a result, the 'intelligence' in the network is divorced from the hardware.
This trend has been hailed as a boon for the consolidated data centre, a 'big data' concept which renders small data centres inconsequential in favour of much larger, consolidated facilities on a global scale.
Making use of infrastructure as a service and other virtualisation technologies, the consolidated data centre is said to allow large organisations to take advantage of the systems management capabilities and high-speed data communications facilities associated with massive data centres, while reducing staffing requirements and real estate costs to a minimum.
However, against this backdrop, SDN is revealing an increasingly apparent downside.
Dumb and dumber
Because SDN effectively decouples network control - the vital learning and forwarding decisions central to the network's operation - from essential network topology, including routers and switches, there is a move towards a significant 'dumbing-down' of these devices from design and quality perspectives.
An even smaller gap needs to be bridged before 'mass produced' and 'made in China' epithets can be added to them.
Without the intrinsic intelligence of a feature-rich control plane, it will not be long before routers, switches and other hardware are commoditised. From there, it is but a short leap for 'commoditisation' to be translated as 'cheap, off-the-shelf'. An even smaller gap needs to be bridged before 'mass produced' and 'made in China' epithets can be added to them.
Perhaps one of the less commendable goals of the SDN protagonists is to undermine the merits of the often proprietary intelligence found in leading-edge products.
This is done under the banner of 'vendor neutrality'. Those carrying it point to apparent cost savings and use bloated phrases such as 'improved asset utilisation', 'dynamically managed traffic flows' and 'improved traffic engineering' to justify their ideals.
In reality, I believe they are seeking to negate the competitive advantage linked to the technical functionality of some of today's leading switch and router offerings presented by companies with multimillion-dollar R&D budgets.
It's called minimalism, dahling
One such campaigner is reported to have said: "If we are to strive for vendor neutrality, then we need an absolute minimal amount of features."
Is SDN positioned for a large-scale conflict with legacy networking technology? Why not let the marketplace decide?
If vendors add sophistication and the benefits of advanced software to their offerings, they are obviously looking for a competitive advantage via these unique and innovative features, for which the user will be asked to pay extra in order to reap the rewards of said technology.
If there is reluctance - a marketplace push-back, for example - then there are sure to be vendors that will focus on cost as their competitive advantage, even on their supposedly 'premier' products.
Should SDN ideology prevail, I believe end-users will be the losers in the final analysis. As most cutting-edge technology and features initially designed for high-end equipment and networks eventually filter down and find their way into the rest of the product portfolios, their absence will result in a general downgrading of all networks over time.
Perhaps the marketplace will come to realise that, as data centre consolidation is not a concept suited to the average-sized company, so SDN should be left to the players in the 'hyper-scale data centre' arena.
For them, considerations such as mean time between failure (MTBF) figures on low-budget products are not important, as replacements can be made without thought to downtime, thanks to massive (and costly) built-in redundancy inherent in their facilities.
Perhaps one of the more cheerless challenges made by SDN is its threat to the hardware vendors' skills base. Because innovation does not come from the production line, many thousands of technical jobs will be at risk if SDN gains a foothold in the medium enterprise sector.
Will vendors be able to redirect their specialists towards other opportunities where they will be unfettered by the need to reduce technology to its lowest common denominator?
Finally, despite the propaganda build-up surrounding SDN, it's not a new idea. In fact, SDN has its roots in ATM (asynchronous transfer mode), TDM (time-division networking), frame relay and other long-forgotten technologies of the 1980s, in which the building of software-defined networks were key objectives. What lessons have been learnt since then?
Technology specialist at Duxbury Networking.
In his role as CTO, Andy Robb is Duxbury Networking's chief technologist and technical advisor, responsible for the company's strategic technical direction. Robb oversees quality of service delivery and product management.
He holds a number of industry product-related qualifications as well as continuing with further tertiary qualifications.
Prior to becoming CTO, Robb held a variety of positions at Duxbury Networking, including technical manager, product manager and senior systems engineer. He has been with Duxbury Networking since 2000.
In his role as CTO, Andy Robb is Duxbury Networking's chief technologist and technical advisor, responsible for the company's strategic technical direction. Robb oversees quality of service delivery and product management. He holds a number of industry product-related qualifications as well as continuing with further tertiary qualifications. Prior to becoming CTO, Robb held a variety of positions at Duxbury Networking, including technical manager, product manager and senior systems engineer. He has been with Duxbury Networking since 2000.