If 2012 was the year of hype, when Nicira, the poster child of software defined networking (SDN) got snapped up for a dot.com valuation, then 2013 will probably go down as the year when network operators started to evaluate the true potential of SDN against the promises that are being made in its name.
True, it makes for somewhat less attention-grabbing headlines, but the reality of SDN is that it asks as many questions as it tries to answer, as Jonathan Wright, VP for service provider at Interoute explains.
“In all honesty, much as SDN was hailed as a revolution, I think it will end up being an evolution – we are not going to see a quantum leap in the way networks are designed and run in the next two to three years. There is a lot of talk – and the momentum behind SDN gets stronger all the time – but we are not going to see a one-stop offering any time soon,” Wright suggests.
Nigel Stephenson of Juniper Networks agrees.
“Don’t forget that this is a market still very much in its infancy. We still have a lot of things to work out,” he adds.
The end of the router era?
Indeed, one such issue strikes at the very core of SDN philosophy: namely, whether it really is appropriate to strip all the intelligence out of the network and hand it to a controller in the first place.
Stephenson is not so sure: “We’ve spent the last twenty years developing routers that can keep the network up and running, come what may. Does it really make sense to throw all that away?”
Like many discussions around the merits of SDN, one simple premise spawns two complex questions. And so it goes on.
Take the whole question of how a carrier might integrate an SDN solution into its existing infrastructure, for example. Much of the work in rolling out SDN technologies has been within the data centre environment, not least the largest SDN deployment so far, by Google on its data centre backbone last year.
But carriers do not run their networks like data centres: any shift to a software-based network will require a huge sea change both in skill sets and in underlying corporate culture. And as a highly placed network development specialist at one international carrier points out, companies can be slow to change.
“We faced a number of similar issues when we moved over to IP. In the end, you have to trust the leadership. If it’s the right thing to do, then you’ve got to do it,” he says.
Technical support revolution
The specific issue with SDN, he cautions, is that it will require a root-and-branch overhaul of his company’s technical support operation.
“SDN shatters the support model – and the moment you start to touch support, you impact on the livelihoods of a lot of people. So you have to understand exactly what you are doing and why before you set out, or else you will be hit with a million and one reasons why not to do it at all.”
One way to counter the challenges of integration is to pursue a build/operate/transfer (BOT) model, whereby the financing and development risks are initially shouldered by a specialist SDN company. But as the network development executive points out, there are downsides as well as upsides to such an approach.
“Frankly speaking, I have little choice but to go down the BOT route. If I gave this project to our in-house design team, they would try to fold it into our current model and that would be a total disaster – and not just from a cost point of view,” he cautions.
But at the same time, committing to a long-term relationship with a single SDN vendor runs counter to one of the basic fundamentals of SDN in the first place, which is to cut the ties to expensive equipment sellers.
“Telcos don’t usually embrace BOT deals – we like to encourage competitive tension in the tender process. At the moment, I’m doing the sales job for these guys – I’m selling to myself,” the executive adds.
NFV sets the pace for SDN
Another key area where new developments could ultimately set the pace for SDN integration is in network function virtualisation (NFV).
NFV and SDN are very similar concepts. While SDN is all about taking control of the network away from switches and routers, NFV is concerned with taking some of the workload away from them – tasks like load balancing and firewall monitoring.
The idea is to standardise these functions and put them on virtual servers rather than dedicated equipment out in the field, so they are no longer tied to the physical network, but can be moved freely about as and when they are required.
But NFV will not really work unless you can control these virtual functions with an all-seeing computer. This is where SDN comes in.
“NFV is going to set the pace for SDN integration – it’s the real trigger for what’s happening in the SDN world. Telcos are very keen to embrace it because they see it as a way of reducing costs quickly and efficiently,” says Juniper’s Stephenson.
Arguably, the significance of NFV in the evolution of SDN is that it again raises the question of brainpower, and specifically the extent to which any should be left on the hardware of next-generation networks. It is important, not just because it drives the debate around cost, but also because it could dictate the extent to which telcos will need to rip and replace old technology to make way for SDN systems.
“SDN is clearly very disruptive to vendors,” explains Interoute’s Wright. “All that secret sauce in the hardware – that currently makes them money – is the bit that you’re essentially trying to strip out and put on a common platform.”
Instead, Wright believes, there will be a phase of consolidation, lasting anything from three to ten years, during which hardware sellers will gradually cede, bit by painful bit, the control elements of the network to software developers.
This is already happening to some degree. The latest suite of network gear from Brocade, for example, can handle both legacy and new SDN systems, allowing carriers to splice specific SDN applications onto the network without affecting other traffic. This, says Brocade, effectively de-risks any move over to SDN and makes the integration process considerably easier. But it also leaves proprietary Brocade intelligence on the equipment, and that comes at a price.
Future possibilities
While an extended period of consolidation will no doubt frustrate early movers in the SDN sphere, it might at least help the industry agree on an appropriate operating system on which to base all these new software applications.
The hot favourite is OpenDaylight, a consortium of SDN players brought together by Cisco and IBM under the auspices of the Linux Foundation to develop an open source code that anyone can use to develop new SDN applications.
However, OpenDaylight is not without controversy, and some members of the SDN community have intimated that Cisco’s motivations in leading the project might not necessarily be all that transparent. Big Switch Networks, for example, quit the project in June after it emerged that the consortium would build its software around Cisco’s own SDN controller, rather than develop a new programming language with input from other SDN players.
“Thinking about this long and hard, it became clear to us that this isn’t a foundation that we can build on,” Guido Appenzeller, Big Switch’s CEO, said after the move.
By adopting Cisco technology as the foundations of the new language, it has been suggested that the legacy hardware providers will be able to shoehorn enough proprietary software into the end product to keep carriers paying over the odds for network equipment for many years to come.
In the end, the provenance of the source code underpinning the SDN market will be of less concern to carriers than the applications that it spawns. Until telcos can recognise for themselves exactly what those applications are, and more importantly, what revenues they can derive from them, then questions will still hang over the future of the technology.
