Tag Archives: openflow

Introducing Odin: an SDN framework for enterprise WLANs

12 Replies

I’ve been putting this off for a while, but I guess it’s high time I blogged about my master’s thesis project. The work is due to be presented at  SIGCOMM ’12; we have a paper accepted at HotSDN ’12, and an accepted demo for the main conference track. So here goes!

Motivation:

We consider the specific case of enterprise WLANs, which have a very diverse set of requirements. Typical enterprise WLAN deployments consist of access points (APs), WLAN controllers, management systems, and a set of network services like mobility managers, load balancers, dynamic channel reconfiguration systems, and mechanisms to enforce policies. Enterprise WLAN vendor solutions today span the entire stack, ranging from AP hardware, to the controllers, and the network services. Unfortunately, these systems are proprietary and closed-source, leading to vendor-lock in, and limited flexibility.

However, the software-defined networking paradigm, enabled greatly through the adoption of OpenFlow by different vendors, allows one to easily introduce new features into a network. One can now write “network applications”, that can programmatically orchestrate the network, thus allowing for greater flexibility with the control plane.

That said, our research has focused on the following question: “What do we need to write network applications for enterprise WLANs?”

The short answer is that OpenFlow alone does not suffice, and that we need some additional plumbing to be able to write network applications that extend into the realm of the 802.11 MAC. Our aim is to come up with useful abstractions that allow a programmer to express typical enterprise WLAN services as network applications, without having to introduce any hardware or software modifications to the 802.11 client.

Light Virtual Access Points (LVAPs):

In a regular WiFi setting, the client associates with an AP on the basis of locally-made decisions. The infrastructure has limited control over the client’s point of association to the network, and cannot instruct a client to handoff to another AP without subjecting the client to a handoff delay (which isn’t a pleasant experience for the user). Additionally, every handoff involves state machine changes at the client, AP, and authentication server. We feel that it would be cumbersome (and error-prone) if the programmer of an enterprise WLAN network application were to handle these state machine changes every now and then. The essence of the problem is basically this: a client’s association is defined by the mac address of the client’s interface, and the mac address of the AP, both of which are physical devices, and of which only one is mobile. To overcome this, we introduce Light Virtual Access Points (LVAPs).

An LVAP is basically a per-client, virtual AP. Every time a client performs a probe scan, a central controller spawns an LVAP on a physical AP close to the client (an analogy would be to spawn a virtual machine on a physical server). The LVAP is what responds to the client’s probe scan with a probe response. The client can then continue the regular 802.11 association handshake with the LVAP. Once this is done, we’ve now formed an association between a client device capable of mobility, and an LVAP. At this point, the client is only concerned with getting ACKs for the data frames it generates, and receiving beacons from its LVAP in a timely fashion. Just like virtual machines in a data center can be migrated to a different physical server, an LVAP can be migrated to another physical AP. If an LVAP is migrated to another physical AP fast enough such that it retains all the necessary state to maintain its associations, and the client continues to receive ACKs and beacon frames, then the client can continue transmitting data frames without having to perform a re-association. Thus, an LVAP migration gives you the effect of a handoff, without actually inducing a state machine change at the client, and if this is done fast enough, the client won’t even notice any period of disconnectivity. This works because the client only cares about the responses it gets from an AP (identified by a BSSID), and is oblivious to the actual physical radio that is generating these responses. LVAPs thus decouple the association state of a WiFi link from the physical APs in the network. This setup makes clients see the same consistent virtual AP regardless of the actual physical AP the client is within range of.

We thus designed Odin, which uses the LVAP abstraction to design network applications. An advantage with using LVAPs is that the programmer always sees a consistent link between the client and the network, defined by the BSSID of the LVAP and the mac address of the client device.

Odin:

Odin’s architecture comprises of a single master, and a set of agents that run on the APs. The master is implemented as an OpenFlow application on top of the awesome Floodlight controller from BigSwitch Networks. The agents are implemented using the Click Modular Router, and run on the APs. The APs run Open vSwitch so that OpenFlow rules can be installed at each AP as well (every LVAP has a set of OpenFlow rules attached to it, which enable faster mobility, and can potentially be used to do access control as well).  Odin applications run atop the master, and control the placement of LVAPs. For instance, a mobility manager would attempt to place the LVAPs as close to the client as possible, and a load balancer would move LVAPs between physical APs such that the APs have an even processing load. Applications written on top of Odin can be both reactive, and proactive. Reactive applications use a pub-sub mechanism to receive notifications for specific MAC layer events that they can subscribe to. Proactive applications merely run within a loop, cycling between sleeping and doing some work.

Current Status:

Odin is currently deployed in the Berlin Open Wireless Lab’s (BOWL) indoor testbed, and is being used by some of our users. I for one, use Odin for my daily network access needs (oh the joy of dog fooding!).

On-going Work:

We’re currently in the process of supporting authentication more cleanly, are aiming for larger deployments, looking at multiple-channel configurations, and are also trying to design new applications and abstractions for Odin. That’s a *lot* of work indeed, but we’re pretty excited about what we’re building. :)

Code:

Odin is available as an open source project on Github. Patches and feedback are more than welcome!

Network Operating System?

8 Replies

I’ve just begun dealing with Software Defined Networks (SDN) for my Master’s thesis, and I’m experimenting on top of Floodlight, an open source OpenFlow controller from Big Switch Networks. In OpenFlow, a logically centralised entity known as the controller can control the forwarding tables of a bunch of switches which speak OpenFlow. OpenFlow applications then talk to the controller using some controller-specific API to ‘program’ the network (manipulate forwarding tables on the switches). The high level architecture looks something like this:

Just like an operating system abstracts away the complexities of the underlying hardware for a user-space application, the controller abstracts away the complexities of the network for OpenFlow applications. For this reason, the controller is often referred to as a “network operating system”. Applications have some API to talk to the network-OS, and it translates those APIs into OpenFlow commands that control the switches.

For my thesis, the plan for my architecture was to have two applications that provide different services to the network, that are expected to run simultaneously. Both of them collect information from the OpenFlow switches and some other framework specific agents situated at the edges of the network to make some optimisation type decisions. But as soon as I implemented one of the applications, it was clear that I had no straightforward way of ensuring that both my applications wouldn’t make decisions that counteract each other. Although I really don’t like the idea of doing this, the easiest way to solve this is to wrap both applications into one. And from the looks of it, this is a problem that hasn’t been solved yet.

Controllers like NOX and Onix make the assumption that only one OpenFlow application is running on a given network at any point of time. This is a reasonable assumption from a systems perspective. But what’s gotten me confused is how OpenFlow applications fit into the “SDN for enterprises” picture. I was under the impression that a network operator using a particular controller could choose between different 3rd party OpenFlow applications to handle different complexities with the network: a load balancing application from vendor A for the edge, a routing daemon application from vendor B, and so forth. While these are relatively orthogonal applications, it looks like it’s possible for two OpenFlow applications to make decisions and choices that adversely affect each other (leading to oscillations in switch state). Floodlight allows you to run multiple applications at the same time, but leaves it to the developer (or user?) to ensure that applications can safely co-exist with each other.

So again, if my observation isn’t mistaken, how do OpenFlow applications fit cleanly into the SDN ecosystem?  How can I manage my network using building blocks of applications from different vendors? Will I need to rely on OneBigApplianceFromBigBadVendor per network? Does this necessitate something analogous to per-process resource allocation as in traditional operating systems? I can see that FlowVisor style slicing is one way to go about it, but will that suffice?

So what *should* the network operating system do here? Let the applications run wild and fight it out? Or provide some mechanism to enforce policies between applications?

If I am indeed mistaken in my assumption, please do let me know what I’m missing here! :)