How Software Will Redefine Networking

The idea is to implement the intelligence in networking devices that are not forwarding. Have the switch handle forwarding while some remote device programs its tables via openflow. It's a logical extension to what IEEE and MEF have been working towards with the TE protocols(PBB-TE, MPLS-TE).<p>The general idea being that a centralized computer handles logical path creation through the network while the hardware just forwards packets. It obviates the need for static configuration of logical overlay paths by using whatever intelligence is programmed into the openflow controller. It also means you can do really neat stuff like distributed loadbalancing.<p>My question is how well does it handle convergence? Is this openflow controller just going to fall over at the first link that decides to flap 100 times a second?

For some reason the whitepaper link on the main OpenFlow website is broken, so here is:<p>- a Coral cache version (<a href="http://preview.tinyurl.com/5sr9vsc" rel="nofollow">http://preview.tinyurl.com/5sr9vsc</a>) - the Google cache version put through Quick View (<a href="http://tinyurl.com/6hxyxz2" rel="nofollow">http://tinyurl.com/6hxyxz2</a>)<p>The GigaOM article was far too basic and vague for me, so the white paper proved to be a breath of fresh air! Whereas the GigaOM article flounders over explaining potential commercial applications for OpenFlow, the whitepaper takes a far more humble approach:<p>"Today, there is almost no practical way to experiment with new network protocols (e.g. new routing protocols, or alternative to IP) in sufficiently realistic settings (e.g. at scale carrying real traffic) to gain the confidence needed for their widespread deployment...a more promising approach [then contemporary commerical and research solutions] is to compromise on generality and to seek a degree of switch flexibility that is:<p>- Amenable to high-performance and low-cost implementations. - Capable of supporting a broad range of research. - Assured to isolate experimental traffic from production traffic. - Consistent with vendors' needs for closed platforms.<p>This paper describes the OpenFlow Switch - a specification that is an initial attempt to meet these four goals."

I don't get it. It's a protocol for managing router forwarding rules. Except every provider out there already implements this in the way that suits them best, and that's the kind of capitalist outlook that made the internet as big and useful as it is today.<p>I don't see how this will redefine anything for anyone, though it might make routing protocols a little bit simpler to manage. Which I guess might be important if you're a huge corporation having problems keeping your clouds from disappearing now and then.

I have not read the specification but it seems like they reinvented Quality of Service and the protocols surrounding it like RSVP and DiffServ. Of course it gives them flexibility to do a lot more than just QoS control but that is the one that stands out to me. Big data users might be able to change their bandwidth capacity in real-time.<p>It will be interesting to see the implementation/deployment scenarios. Does it mean that the ISPs will be giving the bigger consumers control over the percentage of bandwidth they use when needed? It will certainly be added revenue for the ISPs and Cisco and others should like it a lot too.