The emerging OpenFlow approach to building programmable, scalable networks is continuing to gain traction. The latest vendor to jump into the fray is Juniper Networks with a Software Development Kit (SDK) that enables Juniper users to try out OpenFlow.
“There is a big divide between applications and the network that applications run on,” Mike Bushong Senior Director, Product Management/Marketing at Juniper told InternetNews.com. “If you look at where application are going, they need to be aware of the network and similarly the network has to take advantage of more information that resides in the application. OpenFlow is one of the technologies that allows those two worlds to talk to each other.”
Bushong noted that OpenFlow is still a new effort and requires more use and test cases. That’s why Juniper has built the OpenFlow SDK. Bushong said that by making the OpenFlow SDK available, they’re putting it in the hands of developers that can experiment with the technology.
“The way OpenFlow works is that there is a controller that talks to a number of network devices,” Bushong explained. “So on each of the devices there is an OpenFlow client that talks to the controller.”
The basic idea with OpenFlow is you can connect multiple switches and even networks together to create a flow. What Juniper has done is make an OpenFlow client available for Juniper’s MX and T-series routers. The T-series is Juniper’s flagship core routing platform.
“Yes there will be a need for a controller, but it doesn’t matter who makes that controller,” Bushong said. “We’re trying to be vendor agnostic in terms of how we support the controller.”
Bushong added that the intent is to make sure that all the devices in the network can understand OpenFlow. Longer term there is potential for deeper OpenFlow integration with Juniper’s JUNOS network operating system.
The source code for the Juniper OpenFlow implementation is being made available under an open source Apache v.2 license.
“It makes it essentially free for people to take a look at and build on,” Bushong said.
Bushong noted that Juniper is heavily involved in helping to drive the OpenFlow standard forward. What has been implemented in the SDK is based on the OpenFlow 1.0 release.
“If OpenFlow becomes proprietary, than you lose some of the most interesting aspects of managing a large heterogeneous environment,” Bushong said. “That’s why we support an open standard.”
While Juniper is a support of open standards, they’re also a supporter of their own proprietary networking approaches like Qfabric. Qfabric is Juniper’s approach to flattening network architecture.
“Qfabric and OpenFlow solve different problems,” Bushong said “OpenFlow allows for the programming of the network based on conditions in the application space.”
Bushong noted that the challenge in getting OpenFlow more widely deployed is the simple fact that it’s still very early days for the technology.
“We have to get OpenFlow into the hands of the people that want to use it which is not just customers that want to build a network, but also developers that are building applications,” Bushong said. “That becomes a chicken and egg problem, since if OpenFlow is not spec’ed out, the application guys don’t want to use it and if the application guys don’t want it then OpenFlow won’t be completely spec’ed out.”