This article is more than 1 year old

Juniper to build its own software-defined networking stack

Carving up network software even more than OpenFlow

Juniper Networks is not, it turns out, all that enthusiastic about the OpenFlow technology that is at the heart of a lot of software-defined network (SDN) strategies these days. But don't be confused. That does not mean that Juniper doesn't believe in SDN or has not been quietly putting together its own SDN battle plan to take on Cisco, which has its own ideas about SDN, just like other OpenFlow enthusiasts who are trying to break up the network control and forwarding planes and make them more malleable and manageable.

Juniper has been Cisco Systems' main threat in switching, routing, and security appliances for so long that it is hard to remember them not fighting. And the two companies, which have a lot at stake in preserving the current state of the network, are not moving particularly fast in embracing various kinds of software-defined networking (SDN) technologies, particularly the OpenFlow protocol.

And there's a good reason why. Both Cisco and Juniper, as we learned on Tuesday at the company's partner conference in Las Vegas, think they have a better approach to SDN than just slapping OpenFlow inside their physical switches, adding virtual switches to hypervisors, and parking an OpenFlow controller out-of-band to manage the shape-shifting of network traffic.

During his Global Partner Conference keynote address, Juniper CEO Kevin Johnson – formerly a Microsoft big shot – was joined onstage by Bob Muglia, also a former Microsoftie and now executive VP in charge of Juniper's software solutions division. They talked about the broader issues around SDN and how Juniper would spend the next several years transforming its switches and routers, and also break up the network stack even more than the OpenFlow approach does and spread it across a wider variety of devices, including in-house x86 servers and public clouds where this makes sense.

"There's been a lot of hype around software-defined networks, and in fact some people have said that Juniper has been relatively quiet over the past six months," said Johnson. "But behind the scenes, we have been working very hard. We've had our top engineers and our top technical thought-leaders focus on this topic."

The problem with networking is that switches are too brittle. You configure them manually, usually through a command-line interface, and once you get it all working with a device moving traffic from hither to yon, you are really loathe to change it – even if traffic on the network is changing.

Instead, you just put up with poor network performance and overprovision your networks like crazy so you can get decent performance most of the time and take angry phone calls when the network gets slow.

With OpenFlow and other SDN approaches, the idea is to pull the control plane out of the switch and put it on an external controller so that as traffic changes on the network, you can reconfigure the forwarding tables on the fly to shape the network to fit the traffic.

The problem with current OpenFlow technologies, explained Muglia, is that the switches and routers that are managed by OpenFlow still own the gold images of these forwarding tables. And when Juniper gets its software stack out, the table settings stored in its own homegrown controller – which will not support the OpenFlow protocol – will be the masters and the copies active in the switches and routers will be the slaves.

Juniper CEO Kevin Johnson

Juniper CEO Kevin Johnson

You heard that right. Even though Muglia did confirm that Juniper would be adding OpenFlow support into its switches and routers beginning this year, that is being done mainly so its switches can be managed by an OpenFlow controller from a third party such as Big Switch Networks or VMware/Nicira. (More on this in a moment.)

Just for fun, Juniper did a comedy video showing that people don't really know what SDN is – just as a foil against which it could show that its top techies do in fact know – and Muglia spent a great deal of time going over the seven myths of SDN. These myths, which he refuted with Juniper's own definition of SDN, are:

  1. It's only about data-center networking
  2. It's only about reducing capital expenditures
  3. It's only about centralization
  4. It's only about software
  5. It's only about OpenFlow
  6. It's going to happen immediately
  7. It's going to take forever

For Juniper, SDN is about peddling specialized networking hardware with ASICs that can run certain functions on a network device such as a switch or router at least an order of magnitude faster than you could do that function from inside of a virtual machine running on a generic x86 server with a hypervisor.

But, in the cases where you need that functionality to scale independently of the hardware's capability – Muglia gave the example of a switch with intrusion detection, which has plenty of oomph for doing the switching job but loses a lot of its bandwidth to forward packets when intrusion detection is turned on – then maybe you might want to run bits of the network stack on the switch or router and other bits on generic x86 servers or even cloudy infrastructure.

Juniper's approach to SDN, explained Muglia, will break the monolithic software stack inside of switches and routers – for campuses, branches, and service providers and not just for data centers – into four different planes: management, services, control, and forwarding.

By breaking the network into even smaller bits than OpenFlow does, Juniper says it will be able to further optimize these layers by letting customers decide where to deploy them when they are running.

Some of the parts of the Juniper SDN stack will be centralized, such as the management layer where device configuration will be done and analytics will be done in real time on traffic. But other areas, such as the forwarding plane, will continue to be distributed, because this is the best way to make a network responsive on a millisecond-by-millisecond basis to shifting patterns in traffic.

This software will run on a virtualization layer called JunosV App Engine – which sounds a lot like a KVM hypervisor container for an x86 server, but Juniper did not say. This virtualization software will ship later in the first quarter of this year.

Juniper software chief Bob Muglia

Juniper software chief Bob Muglia

This malleability is key to lowering the cost of network configuration and allowing for automated control of network devices.

"We think that the main benefit of SDN will be more agility and lower OpEx for networks," explained Pradeep Sindhu, cofounder and CTO at Juniper, in a question and answer session after the keynotes. Sindhu added that for most customers, the operating expenses for running their networks are anywhere from two to seven times higher than the outlay they have for switching hardware and software. Muglia piped in that SDN would enable the "shift from repetitive manual functions to more process automation" in networks.

But this is not magic, any more than server virtualization was. Sindhu joked that there was a common misconception that SDN would commoditize networking and that some people were talking as if "the controller in the sky" would replace their networks and that all network devices would disappear and "packets would travel over the ether."

The reality is that there will still be switches and routers, and Juniper will be selling them as well as software that runs on them. In fact, the Junos operating system will continue to be bundled on Juniper's switches and routers.

Other software, however, will be broken free of the switches and will be available with utility-style pricing based on a certain amount of throughput over a certain period of time, much like cloud computing and storage capacity is. And to that end, Juniper will change its networking software pricing through a program called Software Advantage to offer consistent pricing per unit of bandwidth on its switches and routers as well as on x86 servers or cloud capacity set up to run it externally from the switches.

The exact pricing and what software modules would be covered under this program were not specified. At the moment, said Muglia, about 10 per cent of Juniper's revenues come from software sales, but over time – just as has happened with servers and storage – you can expect a larger portion of revenues and an even bigger slice of overall profits to come from add-on software that rides on top of Junos or works in conjunction with it.

This new Software Advantage pricing does not affect current products, by the way, and it looks like it is going to take Juniper until 2014 to start rolling out its SDN suite.

Central to that SDN stack is Contrail, a startup that was just getting ready to uncloak last month with its SDN wares when Juniper swept in with $176m in cash and snapped it up. Contrail was founded by a team of networking and software platform experts from Google, Juniper, Cisco, and Aruba Networks, and significantly had former Juniper CTO and chief architect Kireeti Kompella as its CTO. Now Kompella is back at Juniper, and is central to its SDN strategy.

Juniper had a stake in Contrail, but Muglia said that Juniper had not exchanged intellectual property with the company. It was aware of what it was doing in SDN, and liked what it saw enough to snap it up before someone else did.

As it turns out, Muglia confirmed today that Contrail's technology will form the basis of Juniper's SDN controller, which will not be based on OpenFlow but rather on the border gateway protocol (BGP) that is already embedded in Juniper switches and routers as well as devices from other vendors. The Contrail SDN controller also uses XMPP, a protocol for transmitting message-oriented middleware messages, to control the virtual switches inside of hypervisors.

The Juniper stack will also give preferential treatment to the KVM hypervisor, the Open vSwitch virtual switch, and the OpenStack cloud control freak, but Muglia said that Juniper will also talk to virtual switches and hypervisors from VMware and Microsoft.

He did not mention Cisco, and nor would you expect him to. ®

More about

TIP US OFF

Send us news


Other stories you might like