Software Defined Networking (SDN), ironically, is a concept that has yet to have a truly well defined definition. That’s a situation that Juniper Networks is aiming to solve today with the official introduction of the company’s full strategy and vision for what SDN really should enable.
Bob Muglia, executive vice president, Software Solutions Division at Juniper Networks, told Enterprise Networking Planet that there has been a lot of hype and confusion surrounding SDN so far. Muglia wants to dispel that confusion with a clearly articulated vision for what defines SDN.
“By separating the networking planes and centralizing, SDN allows you to optimize every element of the network and simplify network design, ultimately lowering the operating cost of the network,” Muglia said.
To date, Muglia noted that the way networking software has been built is by using traditional embedded software development approaches which directly tie the software to the underlying hardware. While hardware is abstracted in an SDN approach, hardware remains a core component, especially for a networking vendor like Juniper.
“I don’t believe that SDN commoditizes network hardware,” Muglia said. “When you pull out the functions and services out of network devices you can then optimize the software to do what it does best and optimize the hardware to do what it does best.”
At the core of Juniper’s approach to SDN is the concept of Service Chaining. To date, much of the discussion around SDN has been related to the OpenFlow protocol, which does not enable service chaining.
“Today people service chain all the time in networking – they buy boxes, they wire cables between them and they configure each one of them manually,” Muglia said. “The idea of software-based service chaining is a new concept.”
For example, network traffic can first go through a stateful firewall to insure security and then the traffic can go through an Application Delivery Controller (ADC) to distribute the load across servers. In the physical networking world, that service chain is manually configured. In the Juniper SDN approach, the service chain is configured and administered all in software that can adapt as the services need to adapt.
Muglia explained that the Service Chaining approach can be thought of as a form of a VLAN.
“It is a VLAN that is targeted at allowing multiple links or services to be inserted in a chain,” Muglia said.
Actual VLANs however are limited in that they can only provide up to 4092 domains, which isn’t enough for modern cloud scale virtual environments. That’s why vendors such as VMware’s Nicira division have come up with other network virtualization approaches that supersede existing VLANs. As it turns out, Juniper’s approach is similar to the one that Nicira has already taken.
“The concept is similar to what Nicira is doing, the biggest distinction between what they are doing and what we are doing is they talk about an overlay and an underlay network,” Muglia said. “We have generalized the concept of an overlay network into a service chain and are applying it much more broadly.”
From a product perspective, Juniper will be rolling out a number of new products and enhancements to existing products in support the company’s SDN vision. One of the key new additions will be an SDN controller.
“In today’s networks truth lives in boxes and that’s a problem because there are a lot of boxes and a lot of truths,” Muglia said. “If you can put truth in one central place you change the way an organization manages the network.”
One of the mechanisms that Juniper will use to deliver network truth will be via a new controller based on technology acquired from Contrail in December of 2012 for $176 million.
“We’re using our Contrail asset to create the links across the service chain,” Muglia said.
Juniper’s formal SDN strategy follows similar effort from rivals including the Cisco ONE effort, HP and Alcatel-Lucent.
Sean Michael Kerner is a senior editor at InternetNews.com, the news service of the IT Business Edge Network, the network for technology professionals Follow him on Twitter @TechJournalist.