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.
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 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 SND 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 SND 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.
No comments:
Post a Comment