• 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!

  • Masters, check!

    I successfully defended my master's thesis last Friday, and with that, I've now officially completed a two year Msc programme in Distributed Computing. If I were to describe the programme with three words, it would be fun, beer, and bananas.

    Headed back to Berlin on an airplane, by a window seat, in a reflective mood that would be fitting for a sepia filter, I've made a list of the lessons I've learnt over this latest epoch of my life:

    • It's one thing to read about different cultures, it's another thing to experience them.
    • Dreams don't always work out. Be prepared to fail hard.
    • Don't chase achievements. Focus on doing good work, and opportunities will come to you.
    • There are always elements outside your realm of control. As my supervisor tells me, it's called life.
    • Be patient. Very patient.
    • Beer *always* works out.

    Darned window seat, making me reflective and all.

  • Academic Code Quality

  • Chasing the Thesis Carrot

    My thesis defense is scheduled for the 22nd of June, so I've been in writing mode since the last two weeks. In parallel though, I've been evaluating my system, which seems to be producing pretty graphs for the time being.

    I'm both surprised and sad at my ability to be distracted when writing my thesis. I've always had an attention span within the order of microseconds, but this is an all time low.

    Here's how my typical weekday seems to go off late:

    • 8.30: Wake up.
    • 8.30 - 9:00: Ponder about the mysteries of the universe whilst showering.
    • 9:00 - 9:30: Have breakfast, and watch a full episode of the Simpsons or Family Guy.
    • 10:00: Reach the lab. Setup laptop, mouse, keyboard, and extra monitor. Open window for some fresh air. Go grab coffee.
    • 11:30: Done checking my mail, zero-unread-ing my feed of web comics, browsing through HN, Slashdot, and some other news sites (and a few "Oooh! Cat picture!" moments).
    • 11:30 - 12:30: Lunch.
    • 12:30 - 13:30: Post-lunch-procrastination (see 11:30).
    • 13:30 - 14:30: Body has begun processing lunch, so feeling drowsy -- Need. More. Coffee.
    • 14:30: Open up editor for writing thesis. The "let's settle this once and for all!" feeling surges through my body.
    • 14:31 - 14:45: Check Facebook.
    • (The above two repeats for a while)
    • 15:30: "This is boring! I think I'll do something that matters. Like code!"
    • 15:31: Implement new feature! "Byzantine-fault-tolerant-key-value-based-scalable-elastic-hadoop-LTE-fabric-on-the-cloud!"
    • 16:00: Realise that new feature broke all unit and system tests.
    • 16:01: git reset --hard HEAD
    • 16:01 - 16:02: Check Google+. Doesn't take that long though because there's nothing there.
    • 16:30: "That's it! I'm going to do more experiments! Nothing like graphs to make you feel like a scientist!" * challenge-accepted-rage-face *
    • 16:45: Fire shell script and watch as the whole testbed dances to your bidding, cables filling with packets, WiFi waves flowing through space. You feel empowered, like you're about to introduce a tear in the fabric of space.
    • 16:47: Realise that you misconfigured everything.
    • 16:49: Repeat experiment. Pretty sure it's correct this time, so need to do something useful for an hour.
    • 16:50: Continue with writing thesis.
    • 17:00: Time for more coffee.
    • 17:05: Back to desk, "What was I doing again?".
    • 17:06: Facebook time.
    • 17:08: Booooored.
    • 17:10: Write a few more lines of related work. "Previous work by Joe et al [10] has been known to suck".
    • 17:15: Discover some feature in text editor. Optimise key bindings for maximum productivity.
    • 17:49: Experiment's over. Fire SQL queries to extract data from measurements database, and pass it through gnuplot.
    • 17:50: Add graphs to thesis. Defend weird results with "Proof-of-concept".
    • 18:00: "Woah! Is it warm here in the lab or what? Screw you guys! I'm going home so that I can write comfortably!"
    • 18:30: At home. Have dinner with the company of Homer or Peter.
    • 19:00: Feel sleepy. Idle around.
    • 23:00: Sleep.
    • Repeat.

    And I wonder why the carrot's never getting closer.

  • Murali