The last of the big networking manufacturers has revealed its software-defined networking strategy.
And while Juniper Networks doesn’t have all of the pieces yet, the company says it will have one major component in a few weeks that some customers will be able leverage to begin their SDN voyage.
In an interview Brad Brooks, Juniper’s vice-president of marketing and strategy, said the company’s vision differs from others in its completeness.
“We’re not talking about something that might happen in a couple of years,” he said. “We’ve given explicit steps with a time frame against each step.”
One part of the Juniper plan, for a software controller based on technology from its December purchase of Contrail Systems, won’t be on the market until 2014. Applications that will use the services platform Juniper is creating may be released later this year.
However, industry analysts say Juniper has done a good job in explaining its vision.
Zeus Kerravala, principal of ZK Research, admitted the presentation by Juniper executives left him wanting more detail on upcoming products that will take advantage of the strategy. But, he added, it was better than what a number of other companies have done.
Juniper may not want to tip its hand too soon, he added. He believes the company wants to avoid the problem suffered by its QFabric data centre fabric announcement, which was made long before product capable of delivering on the vision was ready.
Juniper said its strategy for creating an SDN architecture and products is built around six principles:
–Separating networking software into four layers or planes – management, services, control and data forwarding – within networking devices.
That’s more than some approaches, but Brooks said this has to be done to get the value out of SDN;
–Centralizing some management, services and control elements to simplify network design, but leave some of those elements in network devices;
–Using cloud principles for elastic scaling;
–Creating a platform that new applications can be easily built on by Juniper as well as third-party developers;
–Using standardized protocols, including BGP, XMPP and OpenFlow, to link to hardware from other vendors;
–And broadly applying SDN principles from the data centre to the service provider edge.
To give some flesh to these bones, Juniper also set out a path for customers to start their voyage to creating software defined networks.
Initially some of this will require Juniper hardware, but, Brooks said, that will change.
So, it says, organizations can start by
–1. Centralizing network management, either using other software companies’ tools, or Junipers’s Junos Space, a platform for automating the operations of Juniper security and switching networks.
Brooks said Junos Space will be made into an even more robust management tool.
Steps after this, however, will need products or applications not on the market yet.
–2. Extracting networking and security services such as firewalls, network address translation, deep packet inspection and load balancing from appliances, and replacing them with virtual apps that can run on x86 servers.
Juniper will offer this capability by the end of this quarter when the JunosV App Engine is released. The App Engine, which has a Linux operating system and KVM hypervisor, will run these virtual machines.
For the time being, the App Engine will only work with a Juniper MX router. Eventually, Brooks said, the engine will be able connect to other manufacturer’s hardware.
–3. Adding a centralized software controller that allows multiple network and security services to connect to each other.
Juniper’s controller, as mentioned earlier, will be based on technology from its December purchase of Contrail Systems and won’t be on the market until next year.
But, Brooks said, combined with App Engine will allow the creation of “service chains” into the flow of network traffic.
So, for example, a firewall app can be told to look at traffic first, followed by a DPI app and then something else. These could be put in any order, Brooks said, using cloud-based orchestration managers.
Juniper believes this will dramatically reduce the time cost and risk of developing new network and security services.
–4. Using hardware optimized for SDNs. Juniper says its MX and SRX series switches will evolve to do this, in part through its programmable ASIC chips.
To lure customers, Juniper also announced an upcoming software licencing and maintenance scheme for the software components of this vision, which will let customers pay based on traffic throughput. Details will be announced later.
In a conference call with reporters and industry analysts after the announcement, Juniper co-founder and chief technology officer Pradeep Sindh said the real value of SDN won’t be in lower capital expenditures because there will be a “controller in the sky” and all network devices will disappear.
Instead, he said, SDN’s advantage will be in lower operating expenditures thanks to network automation and agility.
Laliberte says that among the strengths of Juniper’s strategy will be having its own software-based controller – a key for SDN — and services. “The only identifiable gap I saw was the lack of a Juniper developed virtual switch environment, which will be critical for the creation of overlay networks,” he wrote. He believes Juniper [NYSE: JNPR] will leverage that from others.
Juniper, he added, is taking a blended or hybrid approach to SDN by having its controller use BGP and XMPP to communicate with their switches. Other manufacturers, like Hewlett-Packard, are more focused on the OpenFlow protocol.
By comparison, he said, Cisco Systems Inc. [Nasdaq: CSCO] has a three-way strategy: Use APIs that open up access to switches (aimed largely for service providers); build a controller with OpenFlow in certain Catalyst switches for higher ed and research customers; and expand capabilities of its Nexus 1000v virtual switch for those who want to get into SDN with overlay networks.