Can you program a network of multi-vendor switches and routers, all running different operating systems, command line interfaces and configuration routines, to work in concert when it comes to managing flows?
The OpenFlow effort thinks you can.
OpenFlow is an open source project borne of a six year research collaboration between Stanford University and the University of California at Berkeley. It’s a programmatic interface and protocol that enables software-defined networking, which means that users can define flows and determine what paths those flows take through a network via software, regardless of the underlying hardware.
OpenFlow can take control of how traffic flows through a network out of the hands of the infrastructure, the switches and routers, and put it in the hands of the network owner, individual users or individual applications. This capability could allow users to craft policies that find paths with available bandwidth, less latency or congestion, and fewer hops.
Proponents are many: Scores of big name companies that make up the Open Networking Foundation are evangelising OpenFlow-enabled software-defined networks. They and other advocates say it is particularly useful for load balancing, flow control and virtual networking in data centres, private clouds and campus LANs where devices and virtual machines are multiplying and straining network topologies. Some say it’s like VMware for networks in that it unifies control of the network even though it could be made up of a variety of incompatible routers and switches.
But there are skeptics, too. They say there’s still a lot for OpenFlow to prove. Some say it lacks scale for very large networks, fault tolerance and support for standard routing protocols. Others say the programmability benefits and flow control abstraction it proposes are already available in extensible switch and router operating systems that have receptive APIs.
And others say programmable ASICs and network processors that have been available on the market for years can do virtually the same thing as OpenFlow. There’s also the sticky issue of security when opening up the forwarding tables of multiple switches from multiple vendors.
Makers of network ASICs are not worried about OpenFlow. In fact, they are embracing it.
“Broadcom is part of the effort in defining the OpenFlow work,” says Broadcom CTO Nick Ilyadis. “OpenFlow 1.0 and 1.2 are both being run on Broadcom ASIC-based switches. Today, an ASIC-based device is the leading platform for running OpenFlow. OpenFlow does not break the model an ASIC uses for forwarding and filtering.”
OpenFlow today runs on Broadcom’s configurable ASICs, Ilyadis says. He says it changes the programming paradigm but it doesn’t really change the underlying functionality of the switch. The switch is still forwarding packets, inspecting packets, filtering packets and applying access control lists. All OpenFlow has done is provide an open mechanism by which a controller can reach in and configure those in a pre-determined manner. OpenFlow is simply creating a way to program those capabilities.
“We’re seeing a lot of requests for OpenFlow enablement of things inside the ASICs,” Ilyadis says. “But OpenFlow hasn’t gotten to the point where it says, ‘Hey there are things I want to do that our ASICs can’t do.’”
OpenFlow doesn’t define table sizes or flow classifications that switch ASICs can, Ilyadis says. ASIC APIs provide a certain level of abstraction to the hardware and then it’s up to the vendor to either put their drivers on top of that, or take the OpenFlow commands and then map them to API calls inside of the switch.
“OpenFlow is one instance of software defined networking but there are other APIs as well,” Ilyadis says. “OpenFlow is the one that gets all the press but there are other instances of software-defined networking out there that are also getting some traction, or being used by other companies.”
View full post on National Cyber Security