Why is OpenFlow focused on L2-4?

Another great question I got from David Le Goff:

So far, SDN is relying or stressing mainly the L2-L3 network programmability (switches and routers). Why are most of the people not mentioning L4-L7 network services such as firewalls or ADCs. Why would those elements not have to be SDNed with an OpenFlow support for instance?

To understand the focus on L2/L3 switching, let’s go back a year and a half to the laws-of-physics-changing big bang event.

OpenFlow started as a research project used by academics working on clean-slate network architectures, and it was not the first or the only approach to distributed control/data plane architecture (for more details, watch Ed Crabbe’s presentation from the OpenFlow Symposium). However, suddenly someone felt the great urge to get OpenFlow monetized, had to invent a fancy name, and thus SDN was born.

The main proponents of OpenFlow/SDN (in the Open Networking Foundation sense) are still the Googles of the world and what they want is the ability to run their own control-plane on top of commodity switching hardware. They don't care that much about L4-7 appliances, or people who’d like to program those appliances from orchestration software. They have already solved the L4-7 appliance problem with existing open-source tools running on commodity x86 hardware.

Does OpenFlow/SDN make sense in L4-7 world?

It makes perfect sense to offer programmable APIs in L4-7 appliances, and an ever-increasing number of vendors is doing that, from major vendors like F5’s Open API to startups like LineRate Systems. However, appliance configuration and programming is a totally different problem that cannot be solved with OpenFlow. OpenFlow is not a generic programming language but a simple protocol that allows you to download forwarding information from controller to data plane residing in a networking element.

Is OpenFlow still useful in L4-7 world?

If you really want to use OpenFlow to implement a firewall or a load balancer (not that it’s always a good idea), you can use the same architecture Cisco used to implement fast path in its Virtual Security Gateway (VSG) firewalls: send all traffic to the central controller, until the controller decides it has enough information to either block or permit the flow, at which time the flow information (5-tuple) is installed in the forwarding elements. Does this sound like Multi-Layer Switching, the technology every Catalyst 5000 user loved to death? Sure it does. Does it make sense? Well, it failed miserably the first time, but maybe we’ll get luckier with the next attempt.


  1. Hi Ivan

    There is a use case for openflow for SLB.
    I agree it is not for full L4-L7 SLB but for L4 only SLB openflow can create 400Gbps SLB for 20K$.
    You can take a look at FlowScale for example

  2. Not been talked about much but the major ADC vendors (A10, Brocade, CISCO, Citrix and F5) are members of the ONF.
  3. At my employer (old) we used route-maps to implement load balancing into our server farms for selected traffic. We didn't pass all traffic through because of througput would kill the LBs.. I could see openflow working perfectly for this. If I could have the LB manager program the flows instead of having to do it via route-maps that would be ideal.

    Cisco was going to come out with SIA, but that has been a pipedream for a few years now.
  4. Ivan,
    thanks for editing our chat. Actually, you state something interesting to debate:
    "However, appliance configuration and programming is a totally different problem that cannot be solved with OpenFlow."

    So far I agree, but to my mind, having an evolution of the openflow architecture and protocols to take care about L4-L7 services would be something to look at as a standardization.

    Carriers would love focusing on L4-L7 standardization to enable the network monetization and provide differentiation.
    Getting L2-L3 programmibility as an openflow standard is fine and can give you TCO savings but for the business growth, network monetization associated with L4-L7 programmibility is even better.
    In the 3GPP world, there is the PCC technical specification TS23.203 which standardizes the policy/rule management control (PCRF) from the enforcement function (PCEF). I would love seeing a discussion in the openflow to converge both worlds.
    Anyway, I am pushing for this in the ONF :)
  5. Zdravo Ivan !
    It is the best networking blog I know! Reflecting your deep understanding of modern networks...
    As far as I understand we can expect Cisco Controller to have Plugins that will program any virtual device, like virtual appliances..
  6. working for Radware - i think that SDN offers a great opportunity to leverage network assets in such a way that greatly enhances the scalability of a load balancing solution. L4 can certainly be offloaded to the network (similarly to FlowScale) and upper layers continue to run through ADC appliances.
    the game is not an API to the appliance. the game is about an application that works together with the appliance and programs the SDN. that is where customers will start seeing the value of SDN.
Add comment