There are a number of myths surrounding OpenFlow, including that there is a delay on the first packet of a flow to perform a lookup and that the controller is a single point of failure. Both are easily addressed through sound management practices. In fact, the upsides of using OpenFlow--such as simplified traffic management, policy-based networking that creates paths through the network based on higher-level decisions than the destination address, and software-defined networking where there is tight integration between applications and network configuration--can far outweigh any downsides. The IBM and NEC announcement describes how enterprises are overcoming these obstacles in OpenFlow on their production networks
One customer of the combined IBM and NEC products is Selerity which provides financial information from primary sources to their subscribers. Their service-level commitments are on the order of microseconds, required so that all subscribers receive the same information at the same time. In addition, Selerity has to manage subscription entitlements to its customers to ensure they are getting what they paid for. Selerity's entitlement application needs to make those decisions and dispatch the data in near real time. The challenge Selerity faces in meeting all of those competing goals is in maintaining low latency and traffic separation.
Selerity satisfied those requirements using a convoluted set of VLANs and high-end firewalls to forward traffic to the proper locations, or by using an application-level process to make the forwarding decisions. In either case, the solution was complex, inflexible and expensive. Adding a new subscription to a customer meant making a number of changes to networking equipment, which took time and was error-prone.
Using OpenFlow on NEC's Programmable Flow Controller, Selerity was able to move the forwarding decision off the servers and firewall/switch layer into an OpenFlow-controlled network. Using flow rules defined once on the Programmable Flow Controller, the UDP packets coming from Selerity's servers are rewritten, added to a multicast group and forwarded to the destination ports corresponding with individual customers in a few micro-seconds. Selerity ensures that the correct data goes only to intended customers and that all of the customers receive the data at the same time. Selerity was also able to easily add more redundancy to its delivery network since an OpenFlow network isn't hobbled by Ethernet constraints like having a loop-free network.
Selerity's application and SLA requirements are unique to the financial industry, but many enterprises have similar demands that could be addressed using an OpenFlow-managed network.
IBM and NEC also described unnamed customers using OpenFlow to solve common issues such as forwarding network traffic to multiple analysis devices and forwarding traffic to load balancers. Companies like Anue Systems, Gigamon and NetOptics offer in-line network taps that can combine many network connections into a single output or split a single input into many outputs, either replicating all frames across all output ports or slicing the output stream based on data in the frame like addresses and port numbers. These taps work well but are expensive and require that they sit in-line with the monitored link. The security customer connected taps and switch span ports to an IBM G8264 OpenFlow switch, ran the traffic though a deep packet inspection engine and then forwarded the flows to one or more analysis tools. The monitoring is much more flexible than a fixed tap.
More vendors are hopping on the OpenFlow bandwagon, including networking giants Cisco and HP. Juniper Networks added OpenFlow to its Junos SDK in 2011, while OpenFlow controller vendor Big Switch introduced an open source OpenFlow controller early this year. We will continue to see interesting use cases of OpenFlow in production environments.
Learn more about OpenFlow vs. Traditional Networks by subscribing to Network Computing Pro Reports (free, registration required).