OpenFlow: Enterprise Use Cases

One of the comments I usually get about OpenFlow is “sounds great and I’m positive Yahoo! and Google will eventually use it, but I see no enterprise use case.” (see also this blog post). Obviously nobody would go for a full-blown native OpenFlow deployment and we’ll probably see hybrid (ships-in-the-night) approach more often in research labs than in enterprise networks, but there’s always the integrated mode that allows you to add OpenFlow-based functionality on top of existing networking infrastructure.

Leaving aside the pretentious claims how OpenFlow will solve hard problems like global load balancing, there are four functions you can easily implement with OpenFlow (Tony Bourke wrote about them in more details):

  • packet filters flow classifier followed by a drop or normal action;
  • policy based routing flow classifier followed by outgoing interface and/or VLAN tag push;
  • static routes flow classifiers using only destination IP prefix and
  • NAT – some OpenFlow switches might support source/destination IP address/port rewrites.

Combine that with the ephemeral nature of OpenFlow (whatever controller downloads into the networking device does not affect running/startup configuration and disappears when it’s no longer needed), and the ability to use the same protocol with multiple product families, either from one or multiple vendors, and you have a pretty interesting combo.

Actually, I don’t care if the mechanism to change networking devices’ forwarding tables is OpenFlow or something completely different, as long as it’s programmable, multi-vendor and integrated with the existing networking technologies. As I wrote a number of times, OpenFlow is just a TCAM/FIB/packet classifier download tool.

Remember one of OpenFlow’s primary use cases: “add functionality where vendor is lacking it” (see Igor Gashinsky’s presentation from OpenFlow Symposium for a good coverage of that topic).

Now stop for a minute and remember how many times you badly needed some functionality along the lines of the four functions I mentioned above (packet filters, PBR, static routes, NAT) that you couldn’t implement at all, or that required a hodgepodge of expect scripts (or XML/Netconf requests if you’re Junos automation fan) that you have to modify every time you deploy a different device type or a different software release.

Here are a few ideas I got in the first 30 seconds (if you get other ideas, please do write a comment):

  • User authentication for devices that don’t support 802.1X;
  • Per-user access control (I guess NAC is the popular buzzword) that works identically on dial-up, VPN, wireless and wired access devices;
  • Push user into a specific VLAN based on whatever he’s doing (or based on customized user authentication);
  • Give users controlled access to a single application in another VLAN (combine that with NAT to solve return path problems);
  • Layer-2 service insertion, be it firewall, IDS/IPS, WAAS or some yet-unknown device;

Looking at my short list, it seems @beaker was right: security just might be the killer app for OpenFlow/SDN – OpenFlow could be used either to implement some security features (packet filters and traffic steering), to help integrate traditional security functions with the rest of the network, or to implement dynamic security services insertion at any point in the network – something we badly need but almost never get.

1 comment:

  1. The bottom line is there are similarities between OpenFlow and CAPWAP (used for communication between wireless access points and WLAN controllers). The analogy isn't used enough. Cisco sold hard against a centralized WLAN years ago, then the next thing you know, they buy Airespace and offer both models of centralized (using non standard LWAPP) and IOS de-centralized (IOS) Access Points. Now, even with the controller model, one can run HREAP per SSID. For the data plane, you choose which traffic stays local to the LAN switch or which traffic is tunneled back to the controller. Control plane traffic always comes back to the controller. With all that being said, who had every killer app for wireless when Airespace came onto the scene? No one. It was for the simplification of deployment and management AFAIK, but now with all of this data being collected in a central location now, we have applications such as location tracking, enhanced wireless IPS, integration with RFID tools, etc. and then it allowed for a focal point to implement policy, be it ACLs, NAC, etc. <--- one design where NAC is "easy" to deploy.

    Another point is that CAPWAP was developed so there was an IEEE standard protocol for communication between APs and controllers vs. Cisco LWAPP. Now, without knowing all the details, who's ever tested/deployed an Aruba AP working with a Cisco controller, or vice versa? They are both running the same IEEE protocol, right? Why will OF (or any interface) change that? One protocol, one solution...Would WLAN benefit from OF being used instead of CAPWAP? I don't know :) seems to make sense.

    I do agree NAC/security may just be the killer app...in addition to simplified management and day 2 operations.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.