SDN Rationales

Software-defined networking (SDN) is frankly a somewhat nebulous idea. It describes a concept more than detailed product standards, at least for the moment. To understand what is involved in SDN and its potential, we have to look at the various communities that use the SDN term and figure out their needs and motivations.

To be sure, there's been a good amount of pure hype about SDN, although that phase of its lifecycle is going away. It's clear some marketing people liked the term, but applied it to products that basically were little different from the prior year's crop. Hype unfortunately clouded the picture for a while, with some claims with more fiction than fact and roadmaps that lacked direction.

The next step in SDN's evolution involved companies like Cisco, which believed that software defined meant "software defined but the software runs on our switches." In other words, this was a standard product with an API for third-party code.

Heated discussion around the Cisco approach has helped clarify SDN in general. A model showing the control and data services layers of the network software stack separated from the "bare-metal" of the actual switch has become the accepted description of SDN. The control services software is treated as a virtual function in the network, with it residing in a server VM instance.

This model meets a number of needs. First, it is close to the models used by mega cloud services providers such as Google and AWS to control their networks. With home-grown solutions to orchestrate network configuration, they have for some years been learning to resolve large- scale cloud needs for network configuration by the users.

Second, it falls in line with so-called merchant silicon switch solutions, which use inexpensive hardware to create the switching function. Switch nodes using this silicon are coming to market from a variety of Chinese ODMs and their lack of ties to traditional vendors will change the sourcing logistics and price-points of switch considerably over the next few years.

Third, we are developing a new market for switching service modules and control overlays that will be fed by a combination of startup companies and the existing major players. Because the code is no longer tied tightly to hardware embodiments, the pace of development and the agility of the ISVs will be much higher than the present model of monolithic switch-based solutions.

At the same time, the use of standards for APIs should permit strong competition, which in turn will keep prices down and competition active. This should result in both a spurt in new feature availability and in configurations that can be built with the switching "Lego" model.

The model for the private/hybrid cloud has to be very similar to that for the public cloud, with the internal cloud service provider renting services to cloud users. This puts the private/hybrid cloud network administrators in the position of either managing all the connections or finding a way to both reduce their workload and increase agility/response dramatically.

Organizations building hybrid clouds will need SDN to build and manage seamless solutions. All but small, static clouds need automated orchestration of networking. The cloud admins' aim of having cloud space renters fully able to manage their own VPNs can be realized, taking almost all of the networking burden and moving it to the renters of the cloud. The renters, in turn, will use policy-based configuration management to ease their work and to speed up setup as the instance pools they are using change.

Looking at the SDN question from the viewpoint of each of the participating communities should clarify the definition of what it is, and where the development journey should take it. The concept has a lot of promise, and we are at last beginning to see a coherent direction, but there is still a lot to be done to ease deployment and vendor lock-in issues.