By Saurabh Sandhir

Software Defined Networking (SDN) is disrupting the networking industry as never before. SDN started as an academic exercise to separate the control plane from the data plane in networking devices but found it’s bearing as a way to automate and instantiate network state in highly scaled and dynamic datacenter/cloud environments. The use cases for SDN in the datacenter span from IaaS, PaaS and Service Chaining to Datacenter Interconnect, Hybrid cloud and NFV (Network Functions Virtualization).

Beyond those use-cases, SDN found it’s 2^nd home in the WAN (Wide Area Network). SD-WAN is a way of replacing or augmenting traditional enterprise VPN service (such as MPLS or VPLS) with a secure automated connectivity model that can work on any access network (MPLS, Internet or 3G/LTE) and a policy and network state is programmed into standardized end devices (x86 based CPEs) by a cloud based management and policy plane. Some of the most common use cases for SD-WAN include Hybrid WAN (ability to use multiple access networks simultaneously), Value Added Services for the branch, seamless interconnectivity to public clouds, Off-net extension services (ability to connect “external” branch sites over the internet to “internal” branch locations bonded by L2/L3 VPN). SDN is also showing its relevance in other network domains such as Security, IoT, Core Transport and Mobile Backhaul.

The fundamental proposition of SDN is to automate network provisioning, management and control via centralized software based policy/control engines controlling network endpoints. These centralized engine exposes network state to end users via APIs and abstractions, simplifying the whole process and making it agile, dynamic and highly responsive. The benefits include simplified operations, real time network responsiveness, reduced network complexity and ability to create new service offerings quickly and offer them as on-demand services to the end-user. The benefits reflect themselves in reduced OpEx & CapEx as well as higher top line growth via new services that are deployed faster regardless of where the end-user is connected.

The rise of SDN has coincided with an increase in the number of players in the market offering SDN solutions. They span everyone from traditional network equipment vendors to startups to enterprise software companies. Everyone is touting the benefits and differentiation of their approach and promising a new dawn. Navigating this labyrinth can be a challenging exercise for any enterprise or service provider looking to adopt SDN. So what should you look for in a SDN solution before investing? What are the standout properties of an offering that will stand the test of time, not just from a technology, but also from an operational and total cost of ownership (TCO) perspective? There are 4 principles (or tests) that you can apply to vet out the SDN offerings. Once you shortlist the vendors that meet these 4 principles, you can move into the next stage of properly evaluating the technical and business case fit for each of them before picking the one the most suitable solution that addresses your short-term as well as long-term needs. The four principles of SDN solution are:

Invest in a platform (rather than a Silo’ed single point solution)

The applicability of SDN spans network domains from DC to WAN to IoT to Security, from virtual end points to physical switches. While your requirements today reflects your most pressing need in a single area (say DC or WAN), it is more than likely that your use cases will expand across domains over time. This is where it helps to buy into an SDN platform that supports a series of network domains and can expand to support additional domains as the technology and adoption evolves. This platform should have two components (A) a policy plane, which contains constructs for managing the network with database of network state and data model to abstract the low level network details and (B) a control plane or SDN controller, that maintains the forwarding and routing state of the underlying network. If these two components are built to support only one domain (say WAN), then any expansion into a new domain (say DC) will require a new platform or set of components. This “silo’ed” approach will prove to be expensive in terms of direct capex and opex investments but also from a perspective of training, proliferation of APIs and GUIs. Furthermore, this approach will limit automation of use cases that require seamless connection and policy across domains. Example – to have an ACL that redirects particular traffic from a branch to a VM endpoint in DC, you will need to manually program and provision multiple elements across domain boundaries touching gateways and PE devices. The approach is to think of our mobile or personal computing devices (smartphones, laptops etc). The software that runs on these is a platform (Windows, IOS, Linux, OS X etc). It allows us to build multiple applications on top for our ever changing use cases and needs. The SDN platform needs to have the same characteristics. Buying an SDN solution that does ONLY DC or ONLY SD-WAN is limiting your options and may not evolve as your business needs will.

Service Assurance and Traffic insight matter (and matter the most when the going gets tough)

The promise of SDN is built upon abstractions and overlays that hide underlying physical device and physical network complexity. This is fabulous when the network is working as desired and there are no “faults”. But as soon as a there is a network break or failure, you need to be able to drill into the physical level to be able to isolate faults and correlate physical layer errors to virtual network failures. The network error could be a physical failure, a configuration error, a software failure or an external network event. In order to support this, troubleshooting an SDN solution needs to be able to visualize the network topology and monitor its health using a combination of network protocols (BGP, OSPF etc), network logs and network management protocols (SNMP/Netconf). It can then correlate  physical paths with virtual overlays, physical alarms with virtual endpoint alarms and present a single view of the  health for both overlay and underlay networks.

From an operator’s perspective, especially at larger scale, this level of assurance is critical in order to operate and remediate SDN driven virtual networks in all failure scenarios.

Traffic insight is another element of a solution that can help an operator deal with catastrophic failures including security breaches. It is imperative to have a full view of network flows not just in north-south direction but also for east-west flows within a domain. The flow state should further be augmented by network event views that include ACL breaches, Threshold alerts, TCP SYN flows etc. By extracting this flow and event data and presenting it via a big data analytics engine, an SDN solution can offer valuable insight into the nature of traffic in the network and allow automation of appropriate actions (redirect, quarantine, mirror etc.) based on specific patterns and alerts. In the absence of this functionality, the user will be required to deploy additional systems for traffic and flow monitoring, analysis and automation resulting in escalating costs, complex integration processes, and perhaps inadvertently introducing more chance for human errors, and as result increased risk.

Ecosystem is openness and extensibility 

In the vendor community, it is a cliché to claim that a SDN solution is open. But what does this openness mean and what type of openness should an end user or customer care about? From a user perspective, the type of openness that matters the most is the ability to utilize the SDN solution with a diverse set of multi-vendor environments, use cases and avoid proprietary lock-ins. In the DC, this means the freedom to use any CMS (cloud management system) (from OpenStack to CloudStack to VmWare to Microsoft SCVMM to Kubernetes, Mesos, Openshift) with any hypervisor (ESXi, KVM, Hyper-V etc) with any combination of workloads (VMs, Container, Baremetel). Furthermore, the solution should support a broad range of switches and gateways (HW VTEPs) not just a single vendor’s switch fabric. This ecosystem of supported partners defines if you are going to be locked into a single set of surrounding systems or will you have flexibility to optimize your design according to cost, fit and availability for your specific needs. A range of Virtual Network Functions (firewalls, load balancers, IDP/IDS etc) that can be chained or managed jointly using the SDN platform is another ecosystem axis that defines openness. In an SD-WAN environment, the same ecosystem metrics apply but the nature of CPE hardware (x86 commodity vs special purpose proprietary) and VNFs that can be hosted on site (single party only or diverse 3^rd party) also define how open the solution is. 

In the end, the diversity of the ecosystem will define the flexibility and extensibility of the SDN solution you choose and ensure the continuous evolution of the platform with your business needs

Support and Services convert a POC into deployment 

The move to SDN is more than a technology transition. It involves organizational and skillset transformation along with a well-defined and focused business case. A successful transition from a Proof of Concept (PoC) to a real deployment requires varying degrees of consulting services, solution design, resident engineer support as well as training and certification for employees. Technical support,including fulfillment across geographies, are key to determining how fast and wide the SDN solution can be adopted within the telco or enterprise organization. It is easy to underestimate the impact of these support and services functions in the early stages of validating a SDN product, but they will determine whether the product transforms your organization or remains a flash in the pan. 

Summary

SDN is here and now. It’s power, in the form of policy driven automation, is going to be a factor in network buying decisions for the foreseeable future. However, selecting the right vendor and solution is of paramount importance, else you will find yourself locked into a limited solution without expansion and flexibility and having to repeat the evaluation process for another set of solutions. The 4 principles that you need to focus on are:

1. A) SDN platform vs Standalone application
2. B) Service assurance and traffic insight
3. C) Openness via a diverse ecosystem 
4. D) Service and Support

This combination provides a ready metric against which to measure SDN solutions under consideration. Detailed technical analysis and cost/business diligence need to follow soon after.

Author bio 

Saurabh Sandhir

Nuage Networks

Saurabh Sandhir leads the Product Management team at Nuage Networks. Saurabh brings over 16 years of experience leading cross-functional engineering, product management and marketing teams focussed on networking software products. Most recently, Saurabh was Head of Technology Strategy, CTO office at Ericsson. Prior to his role at Ericsson, Saurabh held a variety of leadership roles during his 13 year tenure at Juniper Networks.  He was the head of the NFV platform product line for both engineering and product management functions. Saurabh also headed the Network Programmability (Junos SDK) product line at Juniper and the development of the industry’s first network API toolkit for developers. This group was also instrumental in defining the marketing blueprint for the introduction of software products in a thus so far hardware centric industry. Saurabh played key roles in building Juniper’s SDN partner and channel programs and defining the SDN architecture/strategy leading to the acquisition of Contrail Systems. 

Saurabh has an undergraduate degree in Computer Science from the Indian Institute of Technology, Delhi, a Masters in Computer Science from Purdue University and an MBA from University of California, Berkeley.