SDN and OpenFlow are not Interchangeable
Published Sep 23, 2013
Version 1.0Was this article helpful?
As an example of the power of SDN, the default OpenStack OVS plugin, in response to cloud management platform messages, uses ovsdb agents to configure the switches (with overlay tunnelling your network topology changes everytime a tenant adds a network and plugs in a guest VM port to a network) and then OpenFlow agents are used to inject flows (at both network creation time and every time a guest VM is created on a compute node) which form a creative mesh of MAC based security rules and forwarding flows eventually pushing the frames into a more standard dynamic MAC learning bridge adjacent to the guest VM. There is no flood to controller once the provisioning is done, because the controller is a 'canned application' in the core OVS plugin. Make no mistake.. it's SDN to the core!
For the above example, SDN builds the ports, SDN builds the security flow rules, and then SDN forwards frames to standard flooding based Ethernet switching which we know works with the guests. None of these stages has to be "all things to all networks", but when they are "flowed" together, we have a ton of functionality and scale. SDN allows you to layer your design for the specific application needs (in this case OpenStack L2 tenant defined networks). Vertically integrated network stacks hide all the layers and you live with the limitations of the weakest link. The virtually integrated stack states..."you'll accept the networking you get and like it"... the SDN controller says "I'll layer your a solution across network functions to scales and responds the way your application needs it." Granted 'what you get' from the virtually integrated network devices has been flexible enough to get us here, but now it is time to let the application designers work through the networking models they need.
With this layered based SDN approach, the silicon based wonders in the network can still be used for what they do best, using their management protocol, and then further nuanced based flows, when required, get pushed to clusters of the "monsters of compute" we call servers (or VIPRIONs!!). That's why SDN is mentioned a ton with NVF. The magic is the SDN application looks like a vertical network stack from the deployed application's perspective, but one that does exactly what it wants.
Just a point of clarity... OpenFlow supports L4 tp_src and tc_dst matching with masks to push/pop flows to the next hop. The real limitation of OpenFlow is it is point-to-point.. as it is supposed to be. You might cripple the capacity of a current generation merchant silicon TOR switch by using matching rules for fields deeper in the frame, but that's the fun you push out and do on the clustered server side. We need to recognize that the switch silicon is rising to meet the market too.. at a price. So too is the server's network silicon getting smarter. All the core networking gear has to do is pass out the flows with the best data it can for an application. For most of that work, you can priori inject a base set of flows policies which are as good if not better than what we were doing with flooding in Ethernet switches today.