04 September 2013
| Richard Irving
The long march towards software defined networking (SDN) appears to pose more questions than it answers. Richard Irving reports on what carriers really need to know.
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
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
"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
"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
NFV sets the pace for SDN
Another key area where new developments could ultimately set
the pace for SDN integration is in network function
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
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
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
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.
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
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
software defined networking,