I want to draw the line in the sand right off the bat and tell you that OpenFlow != SDN. OpenFlow is an open API that allows some intelligent device (an OpenFlow controller) to program the data plane of an OpenFlow enabled device. That’s it. SDN on the other hand, at least to me, stands for something entirely different. SDN means a revolution in how we manage networks as a whole. A Software Defined Network would provide programmatic interfaces to the networking infrastructure that would allow for a very high degree of automation and management. In addition these software defined networks would be more easily aligned with other infrastructure. From a provisioning perspective, this is a natural progression in the network joining other silos (think storage and compute) to become what I like to call ‘common infrastructure’. In the end, we want one platform that can manage all of the common infrastructure.
Arguably, this is going to require many building blocks to accomplish. For instance, let’s take a brief look at OpenStack so I can clarify the difference. OpenStack is being advertised as a CMS or Cloud Management System. CMS systems are designed largely to deliver on the promise of IaaS (Infrastructure As A Service). That being said, to truly deliver IaaS, you’d need to manage all of the pieces of the ‘common infrastructure’ as one logical unit. This being said, OpenStack provides different components for each application. The Nova component handles compute, the Swift component handles storage, and the Quantum component to handle the network. The natural progression of thought here might lead you to believe that Quantum would use OpenFlow to program the network layer. This assumption would be wrong and the OpenStack example provides an excellent example of the difference between SDN and OpenFlow. For instance…
While admittedly, this is a VERY basic model I think it makes my point rather clear (also, keep in mind there are other pieces of OpenStack that I’m not showing like the Glance component). The Quantum component of OpenStack itself leans on what is referred to as a OpenFlow plug-in to talk directly to a OpenFlow controller. This communication is NOT OpenFlow. In other words, the OpenFlow plug-in provides an API to an existing OpenFlow controller. The OpenFlow controller is what talks OpenFlow (depicted with red lines) to any capable OpenFlow switch. This could be a physical device which I would still consider to be part of the Quantum stack or a Open vSwitch that lives on the compute hardware. This solidifies my initial statement, OpenFlow is not SDN. Rather, OpenFlow is a building block of a SDN solution that facilitates the programming of a switching devices data plane. So without going to much further off course, let’s dive into what OpenFlow is…
A common definition of OpenFlow found on the internet will read something like this… “OpenFlow separates a switches control and data plane”.
But let’s be clear about that definition. OpenFlow does not imply that the device’s control plane is now non-existent. Rather, it means that the source of information which the control plane uses to program the forwarding plane has changed, or been added to. Traditional (non-OpenFlow) switches rely on control plane processes (BGP, OSPF, etc) to build the switches IP routing table. From the routing table, the control plane then builds the forwarding table. The forwarding table is then sent to the data plane so it knows how to forward the frames and packets it is processing.
In the case of a OpenFlow, the switch get’s it’s information from an external source commonly referred to as an OpenFlow controller. This device sends flow information to the OpenFlow switch and populates what is referred to as a flow table. Much like the IP routing routing table on traditional switches, the flow table on OpenFlow switches is then used by the devices control plane to program the forwarding table. This being said, the data plane doesn’t really change between a standard switch and an OpenFlow switch. Regardless of where the data comes from (local control plane or OpenFlow controller) the switch still needs to build and maintain a forwarding plane to be able to forward packets and frames.
This being said a more accurate definition might read “An OpenFlow switch uses a remote source (OpenFlow Controller) to build it’s local FIB”. More wordy, but also more accurate.
To understand OpenFlow, we need to understand it’s goal in regards to forwarding. OpenFlow builds a new data structure on a router called a flow table. These flow tables can either be proactively or reactively programmed. That is, they can be pre-populated by a controller or packets can be sent to the controller in order for a forwarding decision to be made reactively. Both scenarios have their own merits in certain situations but we won’t dwell on that too much in this post. Just know that the flow table exists and it’s programmed in one of those two fashions for now.
Note: In this post we are focusing on OpenFlow v1.0 since the hardware I’m using currently supports only that version.
Version 1.0 of OpenFlow supports what’s called 12 tuple matching. A tuple is a fancy computer science term which can really be boiled down to “an ordered list of 12 items”. The 12 items that the 1.0 spec can match on are…
Ethernet Source (Layer 2 source)
Ethernet Destination (Layer 2 Destination)
TCP/UDP Source Port
TCP/UDP Destination Port
These 12 items, can be separated into layer 2 specific criteria (blue) and layer 3 specific criteria (green). I make the distinction here since the particular gear I’m testing on requires that an OpenFlow enabled port either be configured in either layer 2 or layer 3 mode. That is, it currently only supports matching on one or the other. This doesn’t truly meet the OpenFlow spec, but it’s a start and I understand the next gen of code (coming this month I believe) will support full 12 tuple matching. Knowing the limitations that I have, let’s look at an example flow table entry for a layer2 port…
Here you can see a flow entry that’s using the layer 2 information I outline above. This rule would read like this…
“If a frame enters port 1/4 with no dot1q header, a source MAC of 0024.38a8.a603, and a destination MAC of 0024.38a7.5d01, forward it out port 1/2.”
Pretty simple isn’t it? As you can imagine, these flow rules can get pretty specific, or be rather generic. Much like routes to prefixes, the more specific matches will be used first.
We’ll take a look at some more complex examples in my next set of posts where I cover configuring the Brocade MLX for OpenFlow. For now, I just wanted to plant the seed as to what OpenFlow is.