In my most recent survey of enterprises, more than two thirds indicated they had trouble making a business case for SDN. Thatís troubling news for vendors and even for the media, whose enthusiasm for SDN is considerable, but it may also be bad news for enterprises themselves. Why? Because most probably could make the business case rather easily if they went about it in a systematic way, based on just what value models exist for SDN.
The most obvious way to benefit from software-defined networking (SDN) is simply to substitute hosted switching/routing for custom devices. There are a number of open source and commercial software switch/routers available, and enterprises could almost always save some money by using a commodity server and a software switch/router in place of a branch device, or even as a data center gateway. Users who have tried this report cutting their hardware and support costs almost in half.
The key to making this work is to be sure to pick a product that has the level of support needed -- commercial products have support agreements, whereas many open source ones donít have any available -- and to be sure that the product is compatible with the management system already used for your legacy switch/routers. That lets you change out aging equipment for hosted switch/routers on a case-by-case basis, which eliminates the need to write down any current equipment assets.
The next SDN benefit model to explore is using SDN to simplify and lower costs for data center connectivity. Most enterprises wonít need "multi-tenant" control because they donít share their data centers with others, but many value segmenting data center networks by application. That can improve application security and also manage performance by preferencing mission-critical applications in periods of congestion. SDN facilitates effective and lower-cost data center networks in three ways, all of which could be useful.
SDN virtual networking can take application connection and performance management out of the hardware domain, substituting vSwitches or overlay network services for traditional Ethernet connectivity. This lets you control your connections and sometimes your traffic balancing without changing any hardware at all, and itís particularly valuable for data centers moving to virtualization or private cloud.
As your data center switching ages, SDN supports migration in two directions -- toward "white box" lower-cost switches and toward agile any-to-any or "fabric" connectivity. Because the OpenFlow protocol developed for SDN can normally be used to control legacy switches as well as both white-box and fabric products, OpenFlow can bridge you from your current hardware to a new configuration with minimal impact on operations practices and costs, and with no need to displace current equipment until it reaches end of life.
To get the most out of this model, look for an SDN controller that supports all of your current devices and also any new device options you may want to consider. OpenDaylight controllers are the best option here, in my view, because they not only support OpenFlow (the SDN standard control protocol) but also a variety of vendor-specific protocols used to control legacy devices. The more devices your controller can support, the more options it will open for you in migration. OpenDaylight also has a robust architecture for building management and service control applications above the controller, which is critical for the final step in SDN value-building.
Benefits Beyond Capex
The greatest benefit SDN can provide in the long term is opening up new models of packet forwarding -- models that modify, extend, or even supplant normal Ethernet and IP. SDN doesnít need to discover paths; it can get central topology and forwarding instructions from the controller. It can relieve restrictions on Ethernet forwarding imposed by spanning tree, provide seamless route changes in IP networks without impacting routing tables far from the area of impact, and even do load-balancing without the support of custom "Level 4" logic. These capabilities would spread SDN's benefits beyond capital costs to operations costs, and even support new application and service models.
Almost all of the new models for creating application and business services from SDN will be applications utilizing those now-famous SDN "northbound APIs." Itís hard to visualize what a new service model might look like, and harder to review the dry details of APIs to uncover what might be done with them. The best approach is to look at the application-layer examples of SDN controllers to understand how Ethernet and IP services are created and how these services might then evolve to something new and even more useful. Without strong current applications for those northbound APIs to demonstrate their potential, an SDN controller solution could end up being just a lab exercise.
Iíve presented a tip for optimizing each of the three primary SDN business cases, but itís probably clear by now that the ideal strategy for most enterprises is to plan SDN business cases in parallel and implement them serially. There is only one "enterprise network," so SDN deployment should build from the early commitments to the final benefit of creating new service models. To make sure that happens, you have to engage vendors across all the value models for SDN. That way, your first SDN project will build your path to an optimum SDN future.
— Tom Nolle, President/Founder/Principal Analyst, CIMI Corp.