By: Andy Huckridge

Over the past few months I’ve spent a great deal of time discussing software-defined networking (SDN) with industry colleagues, analysts and journalists, and they all agree that there’s a general lack of understanding about its benefits, flaws and potential to help communications service providers (CSPs).

SDN promises to eliminate a large portion of a network’s throughput and service-processing nodes, causing vast amounts of data to shift from one side of the network plane to another with much greater efficiency. It also increases the commodification of the remaining nodes, permitting more networks to come online and resulting in even more data. The question, then, is how to monitor networks that already have immense bandwidth but are facing an influx of data that continues to grow in size, speed and service function.

The answer to this headache is a unified visibility-fabric architecture. Visibility into software-defined networks through the use of key monitoring capabilities should ease concerns about deployment into production environments and promote these new network types so they remain deployed. Most importantly, since the switch to SDN won’t happen overnight, a visibility-fabric architecture lays the groundwork for data visibility across various network topologies, whether physical, virtual or SDN enabled.

The ability to monitor, visualize and troubleshoot is essential in deploying any new technology, and SDN is no different. A pervasive visibility-fabric architecture that bridges the SDN and non-SDN worlds will be necessary if it’s to become an accepted industry reality.

The possibilities

SDN provides a new way to route traffic across the internet as well as an opportunity for CSPs to move back to a more familiar method of provisioning networks—namely, separate control and data planes, allowing for increased efficiency in the movement of data across their networks, thereby facilitating a whole new set of services, or at least service management. Where the latter is concerned, SDN can empower CSPs to speed up service deployment, adjust services to local market needs and develop innovative approaches to ensuring quality of experience and deriving payment models.

We already have a few early, positive reports about the benefits of deploying SDN, from Google announcing large-scale efficiencies in moving traffic to the opposite side of the network plane to Verizon’s initial experiments surrounding video, which are rumored to have gone well. SDN can also help build more secure networks—think back to the days of “phone phreaking” and why the move to separate the control and data planes was a big selling point for Signaling System 7’s SSP, SCP and STP logical nodes.

That said, network engineers are still wondering what other advantages could be gained from SDN. There is talk of uniting various vendors to work in a unified manner through the execution of OpenFlow specifications, to be carried out under the auspices of the Open Networking Foundation (ONF). But therein lies another problem: cross-vendor interoperability.

Speaking as a former chairperson of the MultiService Forum (MSF) and as someone who oversaw global interoperability testing at the GMI (Global MSF Interoperability) events in both 2006 and 2008, it is my opinion—and concern—that we as an industry are heading down a road where vendors are attempting to lock each other out in order to maintain individual market share for existing hardware. Forums with CSP leadership often have to be set up just to overcome this sticking point.