Towards Programmable Enterprise WLANs With Odin Written By Lalith Suresh, Julius Schulz-Zander, Ruben Merz, Anja Feldmann, and Teresa Vazao Presented By Michael Over

Outline Abstract Introduction Odin Framework Design Applications Odin Framework Implementation Evaluation Conclusion

Abstract Odin – an SDN framework to introduce programmability in enterprise WLANs Enterprise WLANs need to support a wide range of services Unique challenges with WLANs AP de-associations made by clients Association state machine + Broadcast nature of wireless medium = Must keep track of a large number of state changes The authors present Odin, a SDN framework to introduce programmability in enterprise wireless local area networks Enterprise WLANs need to support a wide range of services and functionalities, such as authentication, authorization and accounting, policy, mobility and interference management, and load balancing. 3. WLANs also exhibit unique challenges. 3a. In particular, access point (AP) association decisions are not made by the infrastructure, but by clients. 3b. In addition, the association state machine combined with the broadcast nature of the wireless medium requires keeping track of a large amount of state changes

Abstract To address challenges, Odin builds on a light virtual AP abstraction No client side modifications required, supports WPA2 Enterprise Enterprise WLAN services can be implemented as Odin network applications A prototype implementation demonstrates Odin’s feasibility To this end, Odin builds on a light virtual AP abstraction that greatly simplifies client management. 2. Odin does not require any client side modifications and its design supports WPA2 Enterprise. 3. With Odin, a network operator can implement enterprise WLAN services as network applications 4. A prototype implementation demonstrates Odin’s feasibility.

Outline Introduction Abstract Odin Framework Design Applications Odin Framework Implementation Evaluation Conclusion

Introduction Modern 802.11 Enterprise WLANs range from a few dozen to thousands of APs serving a multitude of client devices Large deployments provide resilience, fault-tolerance, fail-over capabilities, and scalability Common features include authentication, authorization and accounting, policy management, mobility management, interference management with client re-associations, load balancing, and QoS guarantees Centralized management typical 1. Deployments of modern 802.11 enterprise wireless local area networks (WLANs) can range from a few dozen to thousands of access points (AP), serving a multitude of client devices such as smart-phones, laptops or tablets. 2. Large deployments provide resilience, fault-tolerance, fail-over capabilities, and scalability 3. Independent of the size, what most enterprise WLAN deployments have in common is the support for features such as authentication, authorization and accounting (AAA), policy management, mobility management, interference management with dynamic channel reconfigurations or client reassociations, load balancing and providing quality of service guarantees. 4. Their management is usually centralized.

Introduction Odin – a prototype software defined networking (SDN) framework for enterprise WLANs Objective: Empower network operators to program and deploy typical enterprise WLAN services and features as network applications 802.11 Challenges: Clients make AP association decisions Association state machine at AP combined with the broadcast nature of wireless medium requires keeping track of continuous state changes This paper proposes Odin, a prototype software de-fined networking (SDN) framework for enterprise WLANs. 2. The objective of Odin is to empower network operators to program and deploy typical enterprise WLAN services and features as network applications 3. In this context, WLANs exhibit specific challenges 3a. The 802.11 standard lets clients make AP association decisions on the basis of locally made decisions. The infrastructure has no control over these decisions made by the client. 3b. In addition, the association state machine at the AP, combined with the dynamic, broadcast and time-varying nature of the wireless medium can require to keep track of state information changes continuously

Introduction To simplify the programming model, Odin builds on a light virtual access point (LVAP) abstraction LVAPs virtualize association state and separate them from the physical AP Multiple clients connected to an AP are treated as a set of logically isolated clients connected to different ports of a switch Prevents directly handling association state and facilitates mobility management -> handoff clients without triggering the re-association mechanism To simplify the programming model, for instance, to not have to handle callbacks for 802.11 state machine changes, Odin builds on a light virtual access point (LVAP) abstraction 2. LVAPs virtualize association state and separate them from the physical AP 3. For the programmer, multiple clients connected to a single physical AP are treated as a set of logically isolated clients connected to different ports of a switch 4. The LVAP design not only prevents from directly handling the association state, it also greatly facilitates mobility management. 5. It allows for the infrastructure to handoff clients without triggering the re-association mechanism

Introduction Odin is a work in progress Assumption: It targets fully centralized and reasonably sized deployments with one controller No client side modifications required, design supports WPA2 Enterprise Odin is fully transparent to the client Odin is a work in progress as we’ll see there are some missing details from the evaluations they perform 2. It also makes several assumptions, including that it targets fully centralized and reasonably sized deployments with one controller 3. It does not expect any client side modifications and its design supports WPA2 Enterprise 4. Clients connect to an Odin network as regular IEEE 802.11 stations in infrastructure mode. Odin is fully transparent to the client

Outline Odin Framework Design Abstract Introduction Applications Odin Framework Implementation Evaluation Conclusion

Odin Framework Design Simple and powerful abstractions needed for high level services in enterprise WLANs 802.11 clients associate or re-associate with any AP based on local decisions Design Goal: Prevent the programmer from keeping track of such changes Light Virtual Access Points (LVAP) Fixed link between clients and infrastructure To effectively express applications that implement high level services in enterprise WLANs, the programmer needs simple and powerful abstractions. This is essential if the programmer operates on a central view of the entire network 2. However, 802.11 clients associate or re-associate with any AP on the basis of locally-made decisions 3. A design goal of Odin is to prevent the programmer from keeping track of changes to the authorizer, authenticator and client state machines 3a. To shield the programmer from this burden and to simplify the programming model, the authors propose light virtual access points (LVAP) 3b. Typically, the programmer cannot make assumptions about the endpoints of the link between the client and the infrastructure (MAC and IP address). With LVAPs, programmers always see a fixed link between clients and the infrastructure

Odin Framework Design Here is a diagram of the architecture of Odin Odin’s architecture consists of a single master, multiple agents and a set of applications The master itself is an application on top of an OpenFlow controller It has a global view of flows in the network, clients connected to the network, and the infrastructure that comprises the network. Odin agents run on the APs A TCP connection is used between the agent and the master (established at boot time). It serves as Odin’s control channel, and used by the master to invoke commands on the agents and collect statistics from them Applications running on the Odin framework implement network services using interfaces exposed by the master

( ) ) ( ) Odin Framework Design ( ) Probe Request Probe Response (SSID) Association Association Response Access Point (AP) In a typical WLAN with active listening, a client enters a wireless zone and broadcasts a probe request One or more APs will send a probe response with their AP SSID (Service Set Identifier) The client chooses one AP to associate with and sends an association message to that AP The AP sends an association response back Probe Response (SSID) Access Point (AP)

Odin Framework Design Odin makes use of Light Virtual Access Points (LVAPs): Start similar to standard APs with Probe Requests APs respond with Probe Response messages Handshake association occurs with one AP Key Difference: With LVAPs, every client receives a unique BSSID to connect to Each physical AP hosts an LVAP for each connected client Odin makes use of LVAPs, which are a central primitive within the Odin framework 1a. In the same way as before, when Wi-Fi clients in managed mode scan for APs, probe request messages are generated 1b. APs responding with probe response messages become potential association candidates 1c. A client then proceeds to perform a connection handshake with a locally selected AP. 2. With LVAPs, every client receives a unique BSSID to connect to, i.e, every client is given the illusion of owning its own AP. In Odin, the LVAP is the client specific AP 3. Each physical AP hosts an LVAP for each connected client.

Odin Framework Design Removing a client LVAP from a physical AP and spawning it on another achieves a hand off No re-association needed No additional messages No special software or hardware needed at the client Provides clients a consistent link to the network Odin application programmer need not be concerned with how the client’s link to the network changes Endpoint of link always corresponds to client IP and MAC addresses with the unique BSSID assigned by Odin In regular 802.11 networks, if a client moves from one AP to another, it has to perform this whole procedure again – redo the handshake, authentication, etc. With Odin, if a client moves from one AP to another, removing a client LVAP from a physical AP and spawning it on another achieves the effect of handing off a client without: 1a. the client performing a re-association, 1b. generating additional layer 2 or 3 messages, and most importantly, 1c. without requiring any special software or hardware at the client 2. Thus, Odin always provides clients a consistent link to the network 3. the programmer of an Odin application needs not be concerned with how the client’s link to the network changes 3b. The end-point of a link always corresponds to the client IP and MAC addresses and the unique BSSID assigned by Odin

Outline Applications Abstract Introduction Odin Framework Design Odin Framework Implementation Evaluation Conclusion

Applications Seamless Mobility 0. Several applications can be built on top of Odin, one being Seamless Mobility With Odin’s LVAPs, a handoff does not involve any additional message exchanges or state machine changes at the client. This can be leveraged by an Odin based application to implement mobility The application can query various statistics provided by the Odin framework, and invoke handoffs depending on an application specific mobility metric For example, their mobility manager uses the receiver signal strength of the client at all agents that can hear it. The application ensures the client is handed off to the agent where this metric is the highest

Applications Load Balancing – dynamic re-assignment of clients to different APs Most existing work requires special software on the client used by the infrastructure to control associations Handoffs with LVAPs are inexpensive and fast; reassociation based load balancing can be easily implemented Executing handoffs every 100 ms did not result in any TCP throughput degradation at the client For scalability reasons, the load at multiple APs can be balanced by dynamic re-assignment of clients to different APs (according to different metrics) 2. Most existing work employs specialized software on the client, which the infrastructure uses to control client associations 3. Since handoffs with LVAPs are inexpensive and fast, reassociation based load balancing can be easily implemented as an Odin application 4. As an example, the authors try executing these handoffs every 100 ms and it does not result in any TCP perceived throughput degradation at the client.

Applications Hidden Terminal Mitigation Several approaches exist – adaptive RTS/CTS, tight scheduling, … Most require client modifications Odin application: centralized view of the network and control over the association state of a client Can provide per client measurements of link impairments (hidden/exposed terminals, collisions, etc.) Mitigating hidden terminals is a well known and classical problem in enterprise WLANs 2. Several approaches exist to measure and mitigate the impact of hidden terminals in enterprise WLAN environments. They span from adaptive RTS/CTS to tight scheduling. However, most approaches require client modifications. 3. This type of application perfectly suits Odin because of the centralized view of the network and the control over the association state of a client 4. This application could be used to provide per client measurements of link impairments such as hidden and exposed terminals and collisions

Outline Odin Framework Implementation Abstract Introduction Odin Framework Design Applications Odin Framework Implementation Evaluation Conclusion

Odin Framework Implementation Odin Master implemented on top of Floodlight OpenFlow controller Invokes commands on the agents – add/remove LVAPs and query for statistics The master, through Floodlight, uses the OpenFlow protocol to update forwarding tables on the AP and switches Odin applications run as a thread on top of the Odin Master The Odin Master is implemented as an application on top of the Floodlight OpenFlow controller 2. It uses an inband control channel to invoke commands on the agents. In its current form, Odin commands can add and remove LVAPs and query for statistics 3. The master, through Floodlight, uses the OpenFlow protocol to update forwarding tables on the AP and switches 4. Odin applications execute as a thread on top of the Odin Master.

Odin Framework Implementation Odin agents run on physical access points Agents record information about clients and communicate with the Master over the Odin control channel The first step to realize LVAPs is for Odin agents to track probe request frames generated by clients Odin agents run on physical APs, and are implemented with Click elements 2. Agents also record information about clients using radiotap headers, and communicate with the Odin Master over the Odin control channel 3. The first step to assign per-client LVAPs is to have Odin agents track probe request frames generated by clients 4.

Odin Framework Implementation When an agent receives a probe request from a client for which it is not already hosting an LVAP, the agent informs the master If the client is not already associated with the network, the Odin Master spawns an LVAP on the Odin agent which received the probe request (or one of the many agents which received the request). The agent then responds to the client’s probe request with a unique BSSID provided by the master To ensure logical separation between clients and their respective LVAPs, beacons (and probe responses) are unicast to the clients. This causes clients to drop all beacons that are not destined to it. Thus, each client can be presented with a unique BSSID to connect to. From this point onwards, the client connects to the newly spawned LVAP as in standard 802.11. An important implementation detail is to ensure that a client is consistently provided the same BSSID (In its current form, we statically assign BSSIDs to clients, but this is easily remedied by generating a BSSID deterministically for the client on the basis of its MAC address.) In its current form, an LVAP is represented by the following four-tuple {mac_addressclient, ip_v4_addressclient, lvap_bssidclient, lvap_ssidclient} LVAPs are each a maximum of 48 bytes, so hosting an LVAP does not incur a significant memory load on the AP For each frame that the AP generates to a client, a lookup on this hash map is performed in order to obtain the right BSSID value to be used as the source MAC address in the 802.11 frame. Since this lookup is constant time and is not a function of the number of LVAPs, the processing load on the AP will remain a function of the number of packets the agent has to process (as is the case with a regular AP), and not a function of the number of LVAPs LVAP: four-tuple {mac_addressclient, ip_v4_addressclient, lvap_bssidclient, lvap_ssidclient}

Odin Framework Implementation Authentication WPA2 Enterprise – Client handshakes with AP and authentication server to negotiate a session key With Odin, session key can be accounted for in LVAP state; when an AP is to host an LVAP, session key is installed Guest Wi-Fi – Client assigned own LVAP only after it has authenticated against the system The architecture of Odin is compatible with the two most deployed approaches to authentication. 1a. A client is authenticated against the system after it is assigned an LVAP. In WPA2 Enterprise, a client performs a series of handshakes with the AP and an authentication server in order to negotiate a session key. This session key is then used by both the client and the AP to encrypt the connection. 1aa. With Odin, this session key can be accounted for in the LVAP state. Whenever any subsequent AP is to host an LVAP, it installs the corresponding session key into the wireless device key table. In this way, then, the LVAP approach is compatible with existing enterprise authentication schemes. The authors note that this is not currently implemented, but they are working on it. 1b. A client is assigned its own LVAP only after it has authenticated against the system. The authentication mechanism can then return a token to the Odin Master for the client after successful authentication by the latter. The client is then assigned an LVAP.

Outline Evaluation Abstract Introduction Odin Framework Design Applications Odin Framework Implementation Evaluation Conclusion

Evaluation Experiments performed with LVAPs Testbed: a single client, two APs on the same subnet, and servers to run the OpenFlow controller Client is given static IP address and authenticated is disabled; all tests averaged over 10 runs Three experiments: Layer 2 Delay in Re-Association, Single Handoff Impact on HTTP Download, and LVAP-Handoff Benchmark Since LVAPs are a central primitive of Odin, they perform experiments to gauge their effectiveness 2. The testbed for their evaluation comprises a single client, two APs on the same subnet, and servers to run the OpenFlow controller and serve as a traffic end-point. 3. For all tests, the client is given static IP address and authenticated is disabled to exclude DHCP and authentication delays – which, with Odin, only occur on the first connection to the network, NOT with every handoff. Also, all tests are averaged over 10 runs. 4. They perform 3 experiments: Layer 2 Delay in Re-Association, Single Handoff Impact on HTTP Download, and LVAP-Handoff Benchmark

Evaluation First experiment: Layer 2 Delay in Re-association using noisy wireless setting Client is associated with one AP, then handed off to another With Odin, handoff delay is less than 1ms What about a more heavily loaded network? In the first experiment, they measure handoff delays within a noisy wireless setting, with all measurements taken in a typical office environment during normal working hours. 2. The client is made to associate with one AP, and then handed off to another (table) They observe the time delay involved for the client to disconnect from the first AP and complete its association with respect to the second one. The results are shown in the table here. 3. The average handoff delay of approx. 350 ms is in line with other literature. The average delay for a handoff within the same channel is around 190 ms. In Odin, a successful handoff occurs when LVAP messages are delivered at the old and new AP, to which the master already has existing TCP connections to the agents at each. Thus, the time involved is about one RTT, or in the testbed they utilized for this experiment, less than 1 ms.

Evaluation Second experiment: Handoff during HTTP download Handoff corresponds to an Odin LVAP migration Over a regular 802.11 setup, the throughput drops to zero over several seconds before recovering Using Odin, the throughput is unaffected in spite of the LVAP handoff In the second experiment, the client associates to one of the APs and begins a download of a large file. After 13 seconds, the client is made to handoff to the other AP. 2. When using Odin, the handoff corresponds to an LVAP migration 3. Over a regular 802.11 setup, the throughput drops to zero over several seconds before recovering (with DHCP and authentication enabled, this down time would be even longer). 4. Using Odin, the throughput is unaffected in spite of the LVAP handoff as we’ll see on a couple of charts in the next slide.

Evaluation Here we see in first chart, the throughput dropping to zero for several seconds during the handoff and, in the second chart, the throughput being unaffected. However, overall the throughput throughout the download is lower by about 5Mbit/sec when using Odin. They say this is due to a userspace Click on the AP agents which causes slower and jittery forwarding performance, causing TCP to throttle down.

Evaluation Third experiment: Test many handoffs with Odin LVAP-handoffs repeated at a fixed interval Throughput degradation measured In the last experiment, they try to discover how often an LVAP-handoff can be executed against a client without affecting its performance 2. LVAP-handoffs are repeatedly made between the two APs at a fixed interval 3. They then observe the throughput degradation during the repeated LVAP-handoffs, the results are shown on the next slide…

Evaluation Despite repeatedly performing LVAP-handoffs every 10 seconds or even every 100 ms, there is no significant throughput degradation. Although it is unrealistic for an Odin application to perform this many handoffs per second, it illustrates the inexpensive nature of this operation.

Outline Conclusion Abstract Introduction Odin Framework Design Applications Odin Framework Implementation Evaluation Conclusion

Conclusion Odin shows the benefits of introducing programmability into the enterprise WLAN Light Virtual Acess Points (LVAPs) – lightweight, cheap, and be used to develop network services efficiently Future Work: Bigger testbed with more users, indoors and outdoors Further abstractions to support more network apps Fault-tolerance, fail-over capabilities, and policy management Odin shows the benefits of introducing programmability into the enterprise WLAN, by designing the right set of primitives 2. LVAPs are only one such primitive, which are lightweight and cheap and can be used to develop different kinds of network services effciently 3. Future work includes using a bigger testbed with more users, testing both indoors and outdoors, developing further abstractions to support a wider range of network applications, and exploring fault-tolerance, fail-over capabilities, and policy management for Odin

Questions Effect of encryption keys added to LVAPs? No measurements for the effect of increased contention on the channel due to increased beacons? Their system is designed for enterprises but they provide experiments only for simple, trivial networks; no evaluation for enterprise networks which are the target of the system Lower throughput during HTTP download cancels out (and then some) the savings of being unaffected by AP handoff Some questions I had when reading this paper…

Questions? Any other questions?