One of the most powerful aspects of Software Defined Networking (SDN) is its potential to facilitate automation. Rapid and mechanized updates to network behavior and configuration produces not only faster time to service, but faster creation of new services.

Key Aspects of SDN

As a reminder, the three defining characteristics of SDN are:

• Definition of a model for a programmable forwarding plane
• Separation of the forwarding and control planes, with centralization of the control function
• Creation of a protocol or APIs to connect the now-separated control and data planes

Much of the early promotion of SDN has been on the use of OpenFlow protocol used to program the forwarding behavior of the network in a standard and open way.   By deploying OpenFlow-enabled devices, a service provider could develop new services, and even new protocols, without upgrading the network.  This OpenFlow-centric view of SDN has been hampered by the limited support of equipment in the network.  Even so, it does have great promise for the future.

A Larger View of SDN

However, we should consider the key attributes of SDN in a more abstract way.  By doing so we will see a means to centrally and mechanically control the behavior and configuration of the network – even if we can’t arbitrarily control its forwarding.  Such automated control is a big step towards reaching the end goal of full or classic SDN.  OpenFlow is not the only way to skin the proverbial cat.

One alternative to OpenFlow is NETCONF.  NETCONF provides not only a protocol for configuration of network elements, but it also provides an operational model as well as YANG for describing the configurable parameters of network elements.  Some vendors have explicitly described NETCONF as a form of “multi-vendor SDN.”  NETCONF has the advantage of being mature and somewhat widely deployed.

Another alternative to OpenFlow is to use RESTful interfaces for control of network elements.  RESTful interfaces have the benefit of easy programming due to widespread experience and a rich set of tools and libraries.  One drawback is the lack of consistent data models for network elements and services.  Growing interest in the use of RESTful interfaces may spur work in the area of models.

A Realistic Rollout

However we chose to define SDN, one thing that does not change is the fact that its deployment won’t be rapid.  I had a chat with James Feger of Centurlink on this topic, which I captured in “Service Provider Realism About SDN” at SDNCentral.  He noted that as a service provider with customer-serving production networks, CenturyLink cannot simply “go out and replace existing equipment to gain SDN capabilities.”  For service providers, there has to be a measurable benefit of SDN in order for them to spend the money to implement it.  The business case for SDN-type capabilities looks much better if existing network elements can be augmented with the new capabilities.  Additionally, the use of new technologies such as virtualization can also help breathe new life into old networks, and can accelerate the introduction of SDN into service provider networks.