Demystifying SDNs!

"Software-defined networks" have to be built on the three pillars of elasticity, flexibility and interoperability, says Doug Suriano, CTO, Tekelec.

The increasingly mobile and social-media-oriented services driving the digital lifestyle will require that switch-and-router jockeying give way to programmable, virtualised environments in which service providers can classify and route data according to QoS parameters and according to the availability of network resources.

SDNs can empower service providers to apply policy in such a way that they gain intelligent control over frames and packets, while simultaneously achieving scale and flexibility.

The problem is that some of the approaches to SDN in recent announcements are being described as “cloudisations” or “cloudifications” of telecom infrastructure without taking into account the full evolution that has to take place, and the truly “open” pillars on top of which SDNs have to be built.

To the first point, service providers have to implement a truly centralised, independent control layer before they can expect programmability and elasticity through the cloud. They also have to think sooner rather than later about mobile-social environments and how to extend intelligent controls globally across networks, applications and smart, connected devices so that their networks dynamically respond to stimuli.

The crowning achievement with SDNs should be networks that self-organise, self-optimise, and self-determine responses to unprecedented and unpredictable events.

Many of those events will be managed in some way by Diameter signaling messages, a thus-far under-addressed aspect of SDN solutions, even though Diameter traffic will grow three times faster than data traffic over the 2011-2016 period.

Diameter messaging will dictate every what, when, where, how and why of services, including:
1. Policy management and the orchestration of the subscriber experience;

2. Communications among policy servers, charging systems, subscriber databases and gateways; and
3. Mobility management functions, including subscriber authentication onto networks and roaming between partner networks.

To have a software defined mobile network without a sophisticated Diameter network foundation that integrates the Diameter Signaling Routing, Policy and Subscriber Data Management would compromise control over IP and signaling flows, and hence any broader SDN capabilities.

The existence of a Diameter Signaling Router (DSR) in and of itself is not enough, as harmonisation of that DSR with sophisticated policy servers and subscriber data management within an independent control layer will be the only way to build elastic control over service delivery, Quality of Service (QoS), access rights and security parameters, as well as signaling and IP parameters.

And even if all of these components exist in an SDN, they will fail if the spirit of interoperability is not respected from the very beginning of their evolution. Collaborative work within consortia like the Open Networking Foundation, the 3GPP and the OpenFlow/Diameter SDN community will be essential.

When evaluating SDNs, it is important to remember that the very purpose of an SDN is to separate intelligent control from the data path – to centralise intelligence from the mobile packet core gateways.

Operator environments are multi-vendor in nature, and SDNs should remove the complexity of managing those environments, not add to it.

Common middleware and standard hardware has to be central to the SDN strategy.

If a proprietary intelligent control layer is required to orchestrate virtual resources, then it defeats the purpose and spirit of the SDN. The hardware has to be “generally available” to every vendor in order to be a true “SDN”.

Some approaches would evolve the Policy Server (PCRF) to the “SDN controllers”, which isn’t really feasible. Each element requires unique sophisticated rules and a rules engine to write them. The SDN controller has to remain a distinct function within the policy infrastructure (which includes a PCRF, a mobile policy gateway, and an SDN controller) to achieve the flexibility and scalability required. The PCRF will independently manage policy rules among applications and policy enforcement points like access devices, and the Policy-Directed SDN controller manages both IP and signaling flows.

While some may say it doesn’t matter if the SDN has proprietary elements or not, we say it has to matter if mobile operators are to mix and match service bundles and pricing models according to what they learn in real time about subscribers’ usage and preferences, as well as network-resource availability and performance. Operator environments are multi-vendor in nature, and SDNs should remove the complexity of managing those environments, not add to it.



Leave a Reply