Introducing Odin: an SDN framework for enterprise WLANs

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!


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’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. 🙂


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


19 thoughts on “Introducing Odin: an SDN framework for enterprise WLANs

  1. Etienne

    Hi , i was just reading this article and wne through your thesis and i must say that they are very informative. One thing which i must ask using Odin and Openflow did you manage to improve the roaming latency of a client between the AP’s ? I am writing aswell my bachelors thesis and I would like to tackle this issue where in normali life this is only accomplished using proprietry hardware such as Cisco Controllers. What do you think ?

    1. lalithsuresh Post author

      Hi Etienne,

      We did write an RSSI-based mobility-manager application to handle roaming. From a client’s point of view, an LVAP handoff does not perturb its TCP flows (you can see the numbers regarding that in the thesis). I had made some rough measurements for the time it takes to perform the LVAP handoff itself, and it’s negligible: less than 1-2ms, primarily dominated by network round-trip delay.

      What do you really plan on doing for your thesis?

      Hope this helps.

      1. Etienne

        Hi Lalith ,

        Thanks for your reply appreciate it! Well what i have in mind is basically try and improve the roaming which a client takes to roam from AP1 to AP2. Basically I want to try to improve this because of the implications of timing which VOIP has. I’ve already measured this latency on a normal network averaging to 1 sec /0.5 sec. Now i must try and improve it on an Openflow network. I am planning to use floodlight and as a switch I am using a mikrotik 450G which has openflow package onto it. As Access points I have two TP-Link TL-WR1043ND, which will be flashed and Openwrt with OPenflow will sit onto them. Now actually i dont know if this is achievable without touching the clients ( i dont want to install any special drivers etc on the clients ). The main problem which i’ve identified is that the main limitation is that the probe request is the first thing which should be improved because there is the point where the main latency occurs so a virtual AP should be setup so that for the client , the same AP is always present. As for the authentication for the thesis i’ve decided to leave it as open authentication because its just a testbed using Openflow and I would like to show the potential which Openflow has.

        Any thoughts about this approach ?

        Thanks for your help,

      2. lalithsuresh Post author

        Hi again Etienne,

        Your setup and testbed sounds good and should allow you to play with Odin.

        Note that in Odin, an LVAP handoff does not involve any singalling between the client and the concerned APs. Basically, the client initially associates with an LVAP (identified by a unique BSSID), and we migrate the LVAP between physical APs after that to realise the effect of a handoff. Since there is no BSSID change involved, the client is oblivious to this.

        Does this fit your scenario?

      3. Etienne

        Hi Lalith,

        It sounds perfect the way it works as you described it. Infact many technologies use the concept of presenting a virtual device instead of the physical one just like load balancers or the way Cisco uses this concept in HSRP where a virtual IP is presented and uses it to do a provide redundant routers/default gateways. It is really interesting how the agent and master communicate, I’ll give a through look to your thesis and implementation of Odin. It fits perfectly to what i would like to achieve, basically I want to show the true capabilities that Openflow offers towards the SDN culture in a way of providing a prgrammatical network which is customizable according to the needs.

        Perfect 🙂 I’m glad that I’ve stumbled accross your blog and I was particular happy in reading other topics namely “Afraid of code? Don’t be” 🙂 ! Right now i’m working on some assignements, then will concentrate on this project.

        Thanks again for your time and help, i’m really grateful for this, will keep you updated on the progress and surely will credit you if I succeed !!

      4. lalithsuresh Post author

        Thanks! And happy to know you’ll be giving Odin a spin. I look forward to your progress with it. And if you end up with some patches, do send them across. 🙂

  2. moorray

    Hi! I’m planning on using Odin in my university project as well! Let’s hope it will result in some code flowing back to you 😉
    Unfortunately the supervisor of my work wants me to describe at least three WiFi-SDN-mobility-controller-like solutions and then justify why Odin is the best. I managed to find OpenRadio, which seems similar enough to describe and then say that it doesn’t suit the project 😉 but I cannot find the third one. Could you please point me to any other even vaguely similar project?

    1. lalithsuresh Post author

      A WLAN controller with mobility support (using the one-BSSID-per-client concept like Odin) is the product from Meru networks.

      You can also check out OpenRoads which attempts to solve some of these problems by using only OpenFlow (and is thus limited in what it can achieve).

      1. moorray

        We have Meru setup at my faculty, but I didn’t think about describing it because it lacks the SDN part (as far as I know, I’ll try to investigate). On a second thought it won’t hurt to describe it actually.
        OpenRoads seems like a perfect fit. Following the key phrases describing OpenRoads I also came across something called CloudMAC – unfortunately I can’t find the source code of that project.
        Thank you very much!

  3. Santiago

    This is very interesting work. I was trying to implement Odin. I was getting following error. Could you please help me to sort-out.
    root@labo:~/Downloads/click-master/userlevel$ click-align | click &
    [1] 2079
    root@labo:~/Downloads/click-master/userlevel$ unknown element class ‘AvailableRates’ unknown element class ‘SetTXRate’ unknown element class ‘RadiotapEncap’ unknown element class ‘RadiotapDecap’ unknown element class ‘ExtraDecap’ unknown element class ‘FilterPhyErr’ unknown element class ‘FilterTX’ unknown element class ‘WifiDupeFilter’ unknown element class ‘WifiDecap’ unknown element class ‘RXStats’

    1. lalithsuresh Post author

      Hi Mooray,

      This is great news!

      About the licensing, it’s basically under an open license so feel free to release your code. The Odin Master basically builds upon Floodlight, so it’ll follow that it goes with the Apache License. The patch to the AP falls under the GPL-v2 license of the Linux Kernel. And about the Click code running on the AP, I haven’t explicitly licensed it, but I believe Click is based on the MIT license.

      A bit of a mess due to all the different parts we’ve had to use but it’s open. 🙂

      Hope this helps.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s