Alcatel-Lucent CTO Marcus Weldon qualifies the innocuous industry concensus that there is no universal definition of Software Defined Networking with a frank observation: “Everyone wants to make SDN whatever it is that they’re currently doing.” And as if that wasn’t knowing enough, he adds: “So I will give you the answer for what we think it should be and, yes, that’s the direction we’re moving in.”
For Weldon SDN is part of a wider change in approach that should allow telecom oprators to finally start deriving revenue streams from the companies that generate the traffic the networks have to carry; the web, application and content providers.
Before he gets to how this works, though, Weldon offers up some background observations. Like his opposite numbers he sees the value of SDN in the data centre. But he is sceptical about the benefits of transplanting the model to carrier networks.
First, he says, it is important to understand how Alcatel- Lucent builds its routers, particularly the fact that the control plane and bearer boards are separate within the cabinet. Some within the industry have a “pathological” attachment to separation of control and data planes as a starting point for SDN, he says, and while it is possible to take the already separate control planes and put them in a different box, it would be “illogical” to do so.
The purpose of separation in SDN is to remove and centralise the control plane and, for operator networks, he doesn’t see the point. “There is no logical value because, in many cases you will end up having to forward a lot of flow information and the flows themselves to be inspected by the control plane because there’s no intelligence in the bearer,” he says.
This type of centralisation creates points of failure out of “omniscient locations” to which huge volumes of traffic must be sent in order to make a decision about what to do at the edge of the network. For Weldon this amounts to trying to fix something that ain’t broke.
“We already have separate control plane and bearer plane so you can scale the two independently,” he says. “And the control plane is the cheaper part of the box, compared to the bearer, so if you were going to look at the router and decide what within it to commoditise, you wouldn’t separate the control plane anyway.”
In a typical datacentre things are different. Here, with a mass of “dumb, cheap switches that are relatively unmanageable” which are not required to perform functions like QoS and which exist within a defined perimeter, separation makes sense, he says.
And yet there remains enthusiasm for exporting this kind of model to the carrier network environment. Proponents of such a move are “getting carried away”, assuming that because they have found a small number of scenarios in which it might be beneficial that it offers a universal solution, he says.
“Our view, quite clearly, is that this is not the universal answer. It’s an interesting and rational approach for datacentres but it is an irrational answer for WANs. With WANS you’re starting from a completely different point; highly QoS-enabled, highly scalable distributed control plane networks that are working well today and are not where most of the cost of the network sits.”
For Weldon it’s the ‘S’ in ‘SDN’ that needs to be addressed. ‘Software’ is “too low level, too much like the nuts and bolts,” and the Openflow specification that focuses on the protocol between the controller and the bearer is “a relatively uninteresting interface,” he says.
“People are wrongly focused on the low-level elements as where the value and effort need to be. That’s easy work, that’s what operators and vendors have always been good at; working out how to write interfaces between management systems and boxes.”
If the ‘S’ is swapped out for an ‘A’, for which read ‘application’, then the potentional for real innovation increases dramatically. “The interesting part of SDN is the northbound interface; exposing the capability to configure the network and optimise the delivery, end to end,” he says. “You let that propagate through the network and expose it to applications. That’s what we think of as Application Driven Networking.”
SDN is an important part of this, he says, in the datacentre. Conventional network management approaches could be used to tie in the the network and then the two combined and exposed northbound so that the application can drive the network. Each application is able to define what it needs from the network and that, says Weldon, will allow operators to “fix their business model problem”.
The combination of the datacenter and the network is necessary as QoS becomes increasingly important to cloud services, Weldon says. Operators should address the enterprise market with a QoS-enabled cloud that includes both the path inside the datacentre and the network, offering a dynamic connection that allows the enterprise to “burst into” the operator data centre with a performance SLA that isn’t available from public cloud vendors, he argues.
The extension of this is that operators can host consumer apps and services on behalf of internet players. “You could turn that into a business where you offer the web companies a hosting service with guaranteed delivery. They are paying for hosting anyway but, this way, the money flows back to the operator that owns the infrastructure.”
For this to work, he says, operators need set templates for different applications that can be appled in their Application Driven Networking archictectures. “A gaming service would need a gaming application template that defaults to what the service needs; it’s a way to map the requirement into network parameters. That does use an SDN controller inside the datacentre so SDN is clearly part of it.”
Scale is essential, though. “If we get agreement across operators on the existence of these templates so that they are the same for all operators we will create federation—a global reach that doesn’t require a partitioning of the market on geographical boundaries.”
This all sounds a little like the GSMA’s One API programme but Weldon argues that One API, like SDN in isolation, was too “low-level”. One API was “trying to expose very rudimentary APIs like QoS, presence and location. No application wants that level of information; what they want is the delivery service for the type of application that they are.
“It’s easier to get operators to agree about high level APIs but it’s very difficult to get agreement on low level APIs because that means operators have to change how they’ve implemented their network. So if we go up to that level and define these service templates and federate those APIs then we’re at Nirvana,” he says.
‘Nirvana’ is an interesting choice of word. Colloquially it has come to denote an ideal or desired state but its original meaning involves the achievement of bliss through the extinction of individual existence and desire. There’s a hint of that spiritual definition about Weldon’s desire to see operators alight on a shared set of application templates that could end the division of the market on geographical boundaries, and about the merging of the network and the datacentre. But it seems unlikely that operators will find bliss through the loss of individuality—every vendor’s messaging is built on the need to differentiate, after all.