Notes On OpenFlow
May 24, 2011 3 Comments
OpenFlow has attracted significant attention in the past three months. Part of the reason is the announcement of ONF. The OpenFlow Lab of Interop also helped pushing up the interest level. Well, inevitably, there also comes many doubts whether OpenFlow deserves such a high interest.
While OpenFlow is not our only focus in our Open Switching Software Architecture, we see it as a very potential technology that may change how we control and configure the network in the future. We would like to share our view on this technology.
Let’s be clear. Can OpenFlow solve all network problems?
Not likely, at least not in the short term.
OpenFlow is an control interface (or API) to program the switch data plane. It does not define new frame type (yet) or new way for switches to distribute the traffic. This means OpenFlow is still limited by whatever data plane capability that existing Ethernet can support. For example, with OpenFlow, Ethernet will still lose packets when congestion occurs.
OpenFlow is just a control protocol, what is new?
OpenFlow is in fact more like an API to program the switch data plane directly.
In the traditional network administration, users configure the protocols through CLI (or other configuration interfaces), then the protocols figure out how to control the data plane. With OpenFlow, administrators or software can directly control the data plane through OpenFlow interface.
Programming the data plane without protocol’s help used to be a no-no. So, what has changed?
Most of the L2/L3 switching technology was designed to respond to the changes of topology. Protocols are designed to handle addition, removal, and failure of nodes in the network. While this requirement is still quite important to many networks, some operators start to realize these protocols add tremendous complexity to the network management.
Take data center as an example. In today’s data centers, switches and cables are part of the infrastructure, which is well planned and laid out long before the actual servers are installed. In this type of network, the topology is fixed, ie. no need for STP to figure out the “best path” or OSPF to find the “shortest path”. All traffic and routes can be pre-determined.
In this case, if network administrators or software can directly program the data plane, either statically or dynamically, it will be much simpler than trying to distribute the traffic through ECMP or Trill from multiple vendors (or even different product lines from the same vendor).
So, what if failure occurs in the network? Well, since the topology is pre-determined, the error handling can be pre-programmed as well. There is really no need for individual switches to try to figure out the alternative route after the failure happens, especially in the case the failure is local to a handful or servers and most of the switches should not even care.
Practically, where can people use OpenFlow?
While still at R&D stage, OpenFlow is showing some interesting signs of solving real problems.
One particular potential area is to build a dynamic virtual network in data centers. With GRE or similar tunneling technology, OpenFlow can build a virtual network on top of fixed cables. This allows data center administrators to dynamically associate resources through this virtual network. Randy Bias of CloudScaling has published an insightful white paper on this architecture.
Another interesting area is to build an MPLS network through OpenFlow. Ericsson Research has build a Wiki to explain how this can be done.
An interesting coincidence in the two examples is they are both trying to use OpenFlow to program data traffic that tunnels through existing network. Well, it definitely helps to get through trial gap if OpenFlow does not require users to replace all existing equipments.
Finally, is OpenFlow a hype?
It does not feel like a hype yet.
While a group of people is over-excited about this new technology and another group of people is eager to dismiss it, most of the developers and network specialists are still investigating how OpenFlow is going to evolve.
Some people predicts it will only evolves into a niche. Well, compared to Ethernet, aren’t new switching technology, such as FCoE and Trill, all eventually become a niche?