Software defined networks (SDN) reduce the importance of networking hardware. So why is hardware maker Juniper Networks so keen on the idea? We decided to ask someone who would know.
For a long while, enterprise networks have been dominated by specialised hardware. Along with the switches, a host of specialised appliances for everything from caching to security have come along. This is a mistake, and is holding back the industry, according to SDN player Infoblox, which sees SDN arriving to correct the error of over-dependence on hardware, and usher in a new era.
In this brave new world, the “control plane” of the router is separated from the “forwarding plane” which handles actual data packets. Hardware becomes a standard commodity, and all network functions are implemented in software, using a standardised protocol called OpenFlow, to accesses the hardware features.
If that’s really the story, though, why are some of the biggest supporters of SDN themselves hardware vendors?
Cisco, which has the mightiest empire of network hardware, is endorsing the concept, albeit in its own fashion. Cisco’s support has a strong flavour of “embracing and extending standards created elsewhere, so that Cisco customers never quite want to leave Cisco’s proprietary world. “SDN is a subset of what we do,” Cisco’s CTO Padmasree Warrior told TechWeekEurope in January, strongly implying the SDN effort might achieve some small successes, but Cisco’s own work would always be superior.
Other network vendors, including Brocade, Extreme, Force10 and HP are also on board the OpenFlow bandwagon.
Despite having its own hardware kingdom, Juniper seems to be particularly proactive, opening up services associated with its Junos software. As one major SDN announcement arrived, we took some time with Mike Marcellin, senior vice president of strategy and marketing at Juniper, and asked him: isn’t supporting SDN a bit like turkeys voting for Christmas?
“Not at all,” said Marcellin. “We have had a software development kit (SDK) for our network since 2007 so third parties can write apps for our networks, and we we funded OpenFlow as a Stanford research project in 2008.”
Juniper has been a strong player in enterprise security for some years (thanks to purchases such as NetScreen) as well as networking. “We are a relatively small player in enterprise routing and switching and so we have a lot of incentive to innovate around SDN for our customers,” he said. “There is a lot of motivation for us to pursue this.”
From this perspective, he said SDN is an opportunity to position the network as a platform, with one operating system and common APIs, so that new and better applications can be delivered across it. “It is a tremendous opportunity, if we can really deliver the benefits of SDN to our customers and other partners.”
But turning the hardware into a commodity platform must reduce the network vendor’s margins, and push towards a division, where network hardware and software are sold separately, by separate experts, we suggest. Which way would Juniper go when software and hardware divide?
“We have to be active in both,” he replied. Although SDN pushes towards standard network hardware, there is always going to be a need for very fast kit built from special silicon. “There are applications and use cases which can all run on an x86 server. But when we talk to enterprises running data centres, there are elements in the network which will still require purpose built silicon for the level of performance it can bring, for the foreseeable future. Look at the customer silicon we create: it delivers anything up to 10x or 100x what can be achieved on x86.”
Even this fast hardware can benefit from SDN, he said: “It doesn’t mean I need to run all the control and management bolted in and tethered to the hardware. We want to have clean separation of the two. If you want to run it on the box, or run it separately on a rack of x86 virtualised servers, that is fine.”
He added: “We would expect we will still have an opportunity for significant differentiation in hardware for the high performance networking customers we serve – and also an untethered set of services management application and controllers.”
That means Juniper is ready if, “in ten or twenty years”, x86 hardware catches up, with a strong software base that can run on those too, he said.
SDN allows network managers to orchestrate many different services, he added. “I need to perform a variety of services on each packet. I need to know which apps to apply, whether to run security on it to make sure it is not malicious, or run a load balancer on it. I don’t always need to do all of them.”
But the network does need centralised control – and by extracting out the software, SDN allows this, he said.
How does SDN affect the way network software is licensed then? “In the world of appliances, if I want a firewall I have dedicated hardware and the software is licensed, but embedded in the appliance and not transferable,” he said. “When we centralise and virtualise services, we give you as much flexibility as possible. You can the software on a dedicated device, but you may also need to run it on a different device, or on a virtual machine in any existing server infrastructure.”
What SDN does, he says, is “taking the way business software is licensed and applying that to networks.”
OK – but we expect Juniper has a similar policy to Cisco’s “superset” idea. Does the company limit itself to the basic OpenFlow protocols, or add its own proprietary extensions?
He concedes, of course, that this is what Juniper does. “If we waited for things to be completely standardised, we would be pretty late to the game. SDN is being deployed in global networks before it is fully standardised – and it’s all a little bit nuanced.”
What Juniper does, he says, is “focus on standards where possible” and use other existing standards.
“If we can do that and talk to customers about protocols they are using, then they can have a level of comfort that they won’t be locked in down the road.”
Do you understand the language of the Internet? Try our quiz!
Fourth quarter results beat Wall Street expectations, as overall sales rise 6 percent, but EU…
Hate speech non-profit that defeated Elon Musk's lawsuit, warns X's Community Notes is failing to…
Good luck. Russia demands Google pay a fine worth more than the world's total GDP,…
Google Cloud signs up Spotify, Paramount Global as early customers of its first ARM-based cloud…
Facebook parent Meta warns of 'significant acceleration' in expenditures on AI infrastructure as revenue, profits…
Microsoft says Azure cloud revenues up 33 percent for September quarter as capital expenditures surge…
View Comments
I like the strategy of separating services from the underlying hardware, and I completely agree that this is more opportunity than risk for just about every vendor in the space aside from the dominant incumbent, Cisco. It's good to see some of the larger bankrolls pursuing new technology.
I still would like to see a crisper delineation between SDN and NFV, though. I think these are different (albeit related). The ability to separate services from hardware is really an NFV thing. The part of the NFV conversation that hasn't really hit mainstream yet (but is talked about in places) is the need for service abstractions that are vendor agnostic (minimally) and technology agnostic where possible. Once you have pools of servers applying services, you need a way of orchestrating those without vendor-specific management solutions.
This abstraction will be key to making this work in the real world. But getting past the religious hurdle of being tied to hardware is an excellent, excellent, excellent first step. Nice to see Juniper leading the big guys here.