SDN - Outlook

The value proposition of Software Defined Networks (SDN) begs the question, what is the promise versus what is the reality? Most of the current literature states SDNs value proposition in list format without clear, well-defined use cases as to where it can directly benefit today's complex enterprise networks. To state it another way, SDN may be an panacea, but the path to get there from today's reality is obfuscated.

That leaves us with two main points:

1. uptake will probably be phased, adopting pieces of SDN architecture that provide clear and immediate benefits with little disruptive change to existing infrastructure, and
2. know what problem you are trying to solve and use SDN architecture concepts if they are the right fit.

Enterprise networks have certainly undergone substantial transformation in the last decade (roughly 2001 - 2010) with the introduction of virtualization, centralized storage, mobility (BYOD), cloud, video, convergence, etc. It could be argued the enterprise LAN of today should be more concerned about wireless than wired access. Identity management is more important today than remote VPN access as employees use multiple devices to access corporate resources both locally and remotely.

No space has changed more than the data center. Provisioning times have gone from weeks to minutes with the deployment of virtualization. The difficulty that arose from this practice is the virtual resources still have to have a physical connection point to the network. That interface can't be virtualized nor were the protocols that govern it updated to accommodate for the mobility inherent in virtualization. If a virtual machine migrated to a host that didn't have the same physical to logical connection configured, the virtual machine was inaccessible.

This spurred an evolution in data center switching from the incumbents. For example, Cisco's Nexus fabric design flattens the data center network and allows for VM mobility, faster switching and inter-data center connectivity for remote hosting and live migration BC/DR scenarios. Juniper's Q-Fabric uses controllers to orchestrate switch connectivity across data centers at scale not previously possible.

The problem with this approach is that it is proprietary at this point. You can't mix Cisco Nexus switches and extend their fabric to Juniper edge switches. Also, while it's one way to solve the VM mobility problem, it introduces different complexities and there are several competing options to achieve that goal.

SDN architecture seeks to minimize complexity while increasing the ease of provisioning and operations while also driving down cost. Lofty goals, but SDN is a higher level architecture concept. In solving today's problems, we look to today's available technologies and the reality is many technologies exist that can affect that change without a complete re-architecture. That is, careful deployment of SDN architecture concepts (standards-based, programmability, compatibility through server-switch-network domains) can produce results today.

Programmability

The programmability of networks can be examined in two parts: forwarding and forwarding guarantees (QoS). For path routing, today's vendor independent distributed routing protocols (e.g., BGP, IS-IS) due a good job providing resiliency over redundant paths. While there are some proprietary protocols (e.g., EIGRP, HSRP, PAgP), there are also vendor independent standards to fall back on (e.g., OSPF, VRRP, LACP). It's important to note that the protocols are industry standard. The implementation is industry standard. The only "proprietary" aspect are the configuration commands between vendors.

The issues not addressed are real-time feedback and path selection based on current performance metrics. Today, to force traffic down a non-optimal path (as determined by dynamic routing protocol) we use policy based routing or at worst static routes. This is highly complex, not dynamic and difficult to maintain. As conditions in the network change, there is little that can be done to dynamically update these non-optimal paths while still providing acceptable service levels for the traffic on these paths as well as the "normal" optimal paths.

This is as important in disadvantaged communications (e.g., low-speed, wireless) networks as it is in high-speed, high volume networks passing traffic with different requirements (e.g., bulk data transfer versus real-time voice).

This brings up Quality of Service (QoS). The ability of applications themselves to request network resources already exists in Resource Reservation Protocol (RSVP) and it is rarely implemented. Differentiated services (DSCP) where the network controls admission, classification, priority and queuing, has basically won out (for several reasons) over the integrated services model. The network can classify and prioritize traffic based on many signature factors and enforce policy. Deployment of this service is sometimes difficult and requires end-to-end participation for enforceable service delivery targets.

Provisioning

The advantage of SDN provisioning in a single domain is certainly an advantage. Having a centralized point to configure and provision capabilities and services across a domain does reduce complexity. Today, we configure a VLAN, configure trunks across switches, provision a Layer 3 routing instance, update routing protocols and update access lists for access or QoS. This may be done across several devices and vendor platforms. The SDN controller will abstract these individual configuration tasks into an orchestrated policy.

It's important to remember this is reserved for a single domain of control. Provisioning and orchestration for servers has moved to a service model where an end user can simply access a portal, request an image, provide some basic configuration and payment and get a running server fit for purpose in minutes. The complex orchestration of providing the operating system, addressing, DNS, network access, etc. is invisible. In some cases, the network provisioning is limited to port / VLAN activation. With SDN, the promise is to make more network functions like access controls, accounting, QoS and other policies more programmable and easier to initially provision - as well as dynamically update during normal operations. The dream of provisioning an application from end to end with a single click may still be just that even with SDN if carrier MPLS networks and managed security services lie in the path.

The move to a single domain is more likely a move to achieve clarity and agility within one of several domains. Many IT groups have lost clarity to policy based routing and giant access lists which no one understands. The first step will be to clean house of bad practices and let network automation serve the enterprise once again.

Cost

There is no argument for or against the vendor choice claim - it is what it is. As long as vendors develop in this space there will be vendor choice. The "promise" of SDN is the use of open protocols, so the software controlling the switches will be independent from the switch vendor. In the current model, I can't buy a Cisco switch and run JUNOS on it. In the SDN model, that (albeit, not exact) example will be possible.

Short term will see the development of standards and incorporation of them into vendor offerings as well as vertically integrated proprietary vendor offerings throughout their product lines. The long term view is for interoperability between vendors using standards without the need for proprietary technologies to complete the solution.

There isn't a simple worksheet that will show SDN Return on Investment in concise quantifiable terms. Acquisition costs may be lower if commodity switches and open standard (not necessarily open source) software can be used. The intelligent controllers will certainly not come cheap. A large scale deployment may have advantages as more commodity switches are added to a bill of materials in lieu of today's smart (i.e., expensive) switches. However, temper this with the fact that enterprises have already made (in some cases, substantial) investments in switch infrastructure for LAN and data center. It's clear finding value is easier in a green field deployment.

There are also the operating costs. Measuring time to configure and deploy new services "the old way" versus the SDN-way and translating that into dollars addresses the costs savings due to the improved operations and provisioning promises. Obviously, a highly competent, technical support staff will be required for a technology not yet at a state of maturity. Also, the capabilities of the support staff will be widely varied from today's network professionals. Programming skills (think Python, XML-RPC or other API knowledge) will be a job requirement in addition to understanding vendor-specific configuration interfaces (e.g., Cisco IOS or Juniper JUNOS).

As enterprises look to follow the CAPEX shift to OPEX and acquire everything-as-a-service, buying an SDN service from a provider is somewhat nebulous as SDN isn't yet well-defined and can mean many different things to many different people. Consider a customer that is maintaining their own infrastructure; there may cost savings to be had if there is no existing or an already depreciated infrastructure. However, the acquisition cost savings needs to be measured against the skilled services and labor required to design, implement and operate a new, early-stage technology deployment.

And this complexity argument can also be applied to an enterprise that subdivides their increasingly converged network back into traditional LAN, WAN and data center silos and outsources to disparate managed service providers. Many of the previously discussed benefits of SDN are stifled when artificial domains are set based on the traditional network model - not the new SDN architecture.

Looking Ahead

So what's happening today? How are service providers incorporating SDN architectures? What are some use cases?

Network Functions Virtualization (NFV) is a European Telecommunications Standards Institute (ETSI) working group to investigate virtualizing network services like edge routing, WAN acceleration, firewall, load balancing, storage, etc. We can think of NFV as a specialized version of SDN at the network access edge virtualizing services that were traditionally deployed in hardware / appliances. These virtualized functions can then be "service chained" - dynamically connected through network paths - to allow traffic to pass correctly and predictably through the system.

Application of NFV can be in service provider CPE where instead of deploying several physical boxes, servers or appliances, a single commodity server can be deployed and all functions run as virtual instances. This is possible because advances in commodity hardware and virtualization make the virtual instances perform on par with their hardware / appliance counterparts. This also presents advantages in shortening deployment times, reduced costs and new business opportunities (e.g., try-before-buy, app store approach to services).

NFV does present some challenges with existing processes. For the most part, virtual instance management can be incorporated into existing OSS systems for hardware, but the physical host remains to be managed and that is outside the scope of OSS systems designed for the particular hardware / vendor they are marketed by. Initial deployment times cannot be reduced since a physical host still needs to be installed, but subsequent upgrades / additions are pushed in software. But who / which group to deploy and managed the physical host?

Outlook

In summary, the existing installation depreciation time frame coupled with the infancy / lack of maturity of the SDN solution means typical enterprise customers (read: conservative [risk-averse], limited budget [more with less, cut cost], require definitive business case [RoI]) will likely wait 1 to 2 years. In that time, incumbents like Cisco and Juniper (both ONF members) will likely have software programmable characteristics in their offerings changing the SDN landscape from old incumbent vendors versus open network upstarts to a somewhat more consolidated market. Additionally, open protocols - traditionally more slower to evolve - will make their way into the leading (read: Cisco, Juniper, etc.) vendor offerings.

During this time, early adopters will have tried and either failed or succeeded and lessons learned will be available. More clear cut problem statement /solution descriptions will be codified and business leaders will be able to make more informed decisions for adoption. And with the approach of a new refresh cycle, the option for operational model is again on the table (on-premise or outsourced). Perhaps managed service provider SDN offerings will be an option at this point.

"When considering an SDN solution, you should be clear on what problem you are trying to solve and over which period of time you will roll out your SDN solution. Since this is an emerging market and many players and solutions are first generation, you should also assess the level of risk you and your organization are willing to assume" (SDNCentral.com).

Disclaimer: Retroactively posted from a work research paper done in May 2014.