SDN is set to be a boon for telecom, though real-world benefits could be mixed
When software-defined networking first exploded onto the technology scene it was billed as a “holy grail” solution that would revolutionize operations by eliminating the barriers to centralized control over a truly dynamic network. But implementation proved more difficult than many thought and its popularity started to wane.
Even the latest Gartner “Hype Cycle” on networking says SDN has hit rock bottom.
But not all technologists and networking specialists seem to agree. Clearly telecom customers are interested and SDN continues to provoke debates globally.
According to Transparency Market Research, the annual growth rate of the SDN market has been estimated at 61.5% since 2012. If this trend continues, it will mean network vendors will invest $3.52 billion in the idea by 2018.
There is no doubt the projects initiated by the innovators at Google and Facebook have many convinced SDN will deliver the highly sought after benefits:
–Better software and hardware integration.
–More agility in network operations.
–Cost overhead reductions (capital expense and operating expense).
–The ability to rapidly launch new services to new markets.
In theory, SDN is designed to free us all from the shackles of closed networks. But Gartner has a valid point: network operators aren’t yet able to enjoy the benefits of SDN. Unfortunately, widespread frustration is casting a dark shadow over today’s approaches and the technology as a whole.
The real problem lies in the fact many of the principles of SDN passed down by theoretical technologists don’t work in practice and need quite some adaptation.
Ultimately, SDN will prevail, but not in the way you might think.
We will examine some of the factors that are preventing the wide spread adoption of SDN and discuss potential solutions that will allow the industry as a whole to move forward towards an open, dynamic networking model – one with a fully programmable data plane governed by a powerful control plane.
Why SDN theory has failed so far
IT/CT departments have been eager to try to set up SDN solutions and implement an open, programmable data path, even in the absence of adequate standardization and available solutions. Without a proven model to guide the work, most have fallen short. There are several factors that are contributing to this problem:
Lack of real-time control
One of the biggest reasons for the failure of SDN is the industry’s naïve idea of a single, centralized controller. To date, no solution has emerged that can fully mediate between the application layer (switches, routers, firewalls and load balancers) and the physical network layer in a manner that is fast enough to enable dynamic networking in real time.
With the current set of fixed systems and dedicated appliances, deploying a centralized controller would only slow traffic flows across the network, even when policies are in place to govern quality of service. As an organization matures and the demand for IT/CT services increases, the network must be able to quickly scale to accommodate the added strain. The concept of having a single controller has hindered this effort, making it virtually impossible to realize without a total network retrofit.
Inadequate equipment
While the foundation of SDN lies in virtualization, openness and complete interoperability, the majority of today’s networking elements remain closed, highly proprietary systems. As such, many technologists believe network vendors should build their networking components using commodity appliances, servers and blades.
Unfortunately, standard appliances that use application-specific integrated circuits for packet forwarding have not yet shown their ability to deliver in accordance with today’s networking requirements. These appliances simply do not exist or are not optimized for the tasks they are required to perform, especially when the complexities of mobile and cloud communications are factored into the equation.
Many of the companies that tried this approach encountered too much latency to proceed.
An incomplete standard
Standards committees have set definitive goals for SDN:
–Separation of the control plane from the data plane.
–Centralized controller and view of the network.
–Programmability of the network by external applications.
Standards committees, for SDN as well as for other aspects, have lofty goals. With so many requirements to fulfill and competing interests to reconcile, it’s not surprising the specifications have yet to provide a viable answer for SDN that will work for the industry as a whole.
Limited use cases
Today, the only complete implementation of SDN can be found in the data center; keep in mind this took hundreds of the industry’s greatest thinkers over a decade to complete.
For example, over many years Google has contributed innovations in networking:
(2006) Google, Global Cache, how content is delivered, including videos and static content from points across the world.
(2008) Watchtower.
(2010) Onix, BwE, B4. Google’s software-defined WAN that connects all their data centers together across the world.
(2012) Jupiter, high bandwidth data center scale networking.
(2014) Andromeda, QUIC, GRPC, network virtualization and multiplatform RPC used for load balancing, application flow control, call cancellation, serialization, open source and HTTP/2.
The point is it took Google a significant amount of time, technologists, money and development work to enjoy the benefits of an SDN-powered architecture.
Lack of true industry support
Although almost every networking vendor claims to provide SDN management and orchestration tools, true interoperability has not yet materialized. In truth, existing networking vendors need to make a significant investment in research and development to enable full virtualization and ensure their equipment can communicate effectively with a central controller and with other devices.
For many, the return on investment is questionable at best, as many can’t justify abandoning their proprietary implementations that gave them a competitive advantage and ensured customers were locked in. To get around this issue, many are either trying to provide (and control) the entire SDN solution stack or partner with other types of IT vendors to produce controllers that meet certain minimum requirements.
Either way, this of course creates roadblocks and limits the implementation of a completely open data path.
Bottom line: it’s time to rethink SDN
Today, most companies still require a significant, environmental upgrade before they will even consider deploying a centralized SDN controller. Even with network-wide policies in place, most will still experience delays and roadblocks as they try to define and utilize a programmable data plane.
Of course, this type of radical network transformation requires a significant financial investment and years of work. Cutting corners will likely only lead to frustration and limited functionality, as it has for many organizations already.
And yet the move towards SDN seems inevitable. It is where the future of networking lies. The global market is rapidly growing and technologists worldwide, who believe in the idea, are continuously trying new methodologies to make it happen. Nevertheless, some fundamental changes are needed before the promise of SDN can begin to materialize.
Enhancing the standards process
Because SDN is such a transformational technology, its development really needs to be fast tracked. While the standards committees are making progress, there is still quite a bit of work to be done. Unfortunately, the current version of the standards does not account for the existing infrastructure. Right now, SDN is only viable for newly deployed cloud environments – it does not hold up in the “traditional” networking environments that could benefit most from its implementation.
The industry as a whole must find a way to integrate legacy equipment – service providers and enterprises have too much invested to be able to flip the switch on a new approach overnight.
The industry may want to take a cue from the test programs underway at many service providers where they are openly collaborating with multiple vendors to find a workable SDN solution for existing environments. Instead of a “think and try” approach to creating standards, embracing a “work and try” methodology should be considered.
Concentrate on creating a truly open network
It is clear “open” is a prerequisite for the dynamic, programmable networks of the future. If technologists want to continuously ensure optimized resource use, the SDN elements need to be free to create the most efficient path between all required resources – at all times.
Open networks require four integrated pillars:
1. Open interfaces – an obvious choice, as equipment of different vendors will be required to work together.
2. Open hardware – again while this seems obvious, this is often the most complex aspect, since there is still the question of what will happen to legacy hardware, which is closed by default.
3. Open ecosystems – if only one vendor is open, this will neither enable choice nor vendor “unlocking.”
4. Open source will need to become a strategic pillar. What most don’t understand is it is not enough to base the appliances on open source. Rather the variety of controllers, hardware and management systems will need to continually fuel an open source community. The minute a function is tailored (and not fed back into the community) it becomes proprietary by default.
If SDN is to gain widespread industry support any time soon, the community needs to prioritize the creation of a truly open network, able to dynamically route traffic in real time.
Revise the centralized controller concept
While the holy grail of SDN may be a centralized switch that controls the entire network, it hasn’t proven to be as practical as the industry had hoped. The model in which a single switch has a global view of the network that can calculate and optimize paths and manage traffic flows just doesn’t scale well. There is too much latency. This kind of real-time dynamic flow only works in very small networks.
In order for SDN to work in large networking environments, companies need to consider taking a hybrid approach. The idea is to keep the global view and management controls for creating network-wide policies, load balancing algorithms and application prioritization in the centralized controller. Once the policies are set, it would send the data – local derivations – to local switches for faster execution.
Without a more distributed approach and a standard method for sending optimized behaviors to switches throughout the environment, the practical limitations of an SDN solution will continue to prevent its widespread adoption in large networks.
The spirit of SDN lives on, even if it has only been validated in the most innovative of environments. As the industry continues to rethink, revise and reinvent SDN technology, it will become a viable option for more and more organizations as they transform their networks for greater agility, programmability and efficiency.
Editor’s Note: The RCR Wireless News Reality Check section is where C-level executives and advisory firms from across the mobile industry share unique insights and experiences.
