If it's not broke, then don't fix it. I may make a living on the cutting edge of technology, but I like that advice. Now, just as we're finally switching from IPv4 to IPv6 for the Internet's master protocol, the newly formed Open Network Foundation (ONF) is proposing that we use the OpenFlow as a new standard on how packets are forwarded through network switches and how we'll manage them.
Was packet switching really broke? Did we need yet another network switch standard? Well, actually, according to the researchers who came up with OpenFlow, we don't. Instead, according to their 2008 white paper, OpenFlow: Enabling Innovation in Campus Networks (PDF Link): "The basic idea is simple: we exploit the fact that most modern Ethernet switches and routers contain flow-tables (typically built from TCAMs [Ternary Content Addressable Memory) that run at line-rate to implement firewalls, NAT [Network Address Translation], QoS [Quality of Service], and to collect statistics. While each vendor's flow-table is different, we've identified an interesting common set of functions that run in many switches and routers. OpenFlow exploits this common set of functions."
In other words, the OpenFlow researchers wanted to standardize what a lot of network vendors were already doing. If this had just stayed an academic standard-making effort, this probably wouldn't have mattered much. But, six companies that own and operate some of the largest networks in the world: Deutsche Telekom, Facebook, Google, Microsoft, Verizon, and Yahoo! and network powerhouses like Cisco and Juniper joined together to promoting this new approach to networking.
Broadly speaking, OpenFlow is a kind of Software-Defined Networking (SDN). An "OpenFlow Switch," according to the white paper, "consists of at least three parts: (1) A Flow Table, with an action associated with each flow entry, to tell the switch how to process the flow, (2) A Secure Channel that connects the switch to a remote control process (called the controller), allowing commands and packets to be sent between a controller and the switch using (3) The OpenFlow Protocol, which provides an open and standard way for a controller to communicate with a switch. By specifying a standard interface (the OpenFlow Protocol) through which entries in the Flow Table can be defined externally."
The point of all this as noted standards lawyer Andrew "Andy" Updegrove sums up is to "adapt network architecture to streamline its interoperation with cloud computing." It works with the cloud because OpenFlow enables network switches, at very high speeds, to move traffic to the most efficient part of the cloud. In short, in a way OpenFlow switches will also work as a standardized way of handling server and network load balancing.
For network administrators, the broad argument for OpenFlow is that it will open up hardware and software routers and switches to give them far more control than they have currently. According to the Times, this will let ISP set "up on-demand 'express lanes' for voice and data traffic that is time-sensitive. Or it might let big telecommunications companies, like Verizon or AT&T, use software to combine several fiber-optic backbones temporarily for particularly heavy information loads and then have them automatically separate when a data rush hour is over. For households, the new capabilities might let Internet service providers offer remote services like home security or energy control."
How much difference will it really make? We'll have to wait and see. The potential is certainly there for making large-scale networks and the Internet easier to manage and more efficient. But, will ISPs use it or will they stick to the enormous work of dealing with the switchover from IPv4 to IPv6? My bet is that the IPv6 conversation will keep them more than busy enough. If they get OpenFlow hardware and software in their hands I'm sure they'll be happy to use it as well, but it can't be their first priority for the next few years.