I’ve once again realized that random reading, though time-consuming, brings, sometimes, interesting info.
This time it is OpenFlow. The OpenFlow is a research oriented “mechanism” , for allowing researchers and network engineers experiment with their networks by adding more programming flexibility to the commercial hardware (mainly routers and switches) through an external controller.
The white paper the authors have posted, explains briefly the concept and shows some real examples.
The solution is mostly oriented at large-scale lab deployments within real production infrastructures (ex. universities). It might be a long way to go till it gets to service provider labs, and even further in the production. However, in such cases as this one, “time to market” – if we can call it that way, is not that important. What’s really important is making more network engineers and researchers aware of its existence and viability. I can think of another couple of ways to use such a controller. Turning on my imagination I start thinking that, if properly designed OpenFlow might become that lacking detail in the puzzle. It would give network engineers granular control over policies without heavily relaying on the hardware vendors. In the end it might prove a proper way to withstand the growth of the Internet and the ever-increasing dependency on development roadmaps.