Towards Programmable Enterprise WLANs With Odin Written By Lalith Suresh, Julius Schulz-Zander, Ruben Merz, Anja Feldmann, and Teresa Vazao Presented By Michael Over 1 Outline Abstract Introduction Odin Framework Design Applications Odin Framework Implementation Evaluation Conclusion 2 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 3 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 4 Outline Abstract Introduction Odin Framework Design Applications Odin Framework Implementation Evaluation Conclusion 5 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 reassociations, load balancing, and QoS guarantees Centralized management typical 6 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 7 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 8 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 9 Outline Abstract Introduction Odin Framework Design Applications Odin Framework Implementation Evaluation Conclusion 10 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 11 Odin Framework Design 12 Odin Framework Design Probe Request ( (( )) ) Probe Response (SSID) Association Association Response Access Point (AP) Probe Response (SSID) Access Point (AP) 13 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 14 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 15 by Odin Outline Abstract Introduction Odin Framework Design Applications Odin Framework Implementation Evaluation Conclusion 16 Applications Seamless Mobility 17 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 18 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.) 19 Outline Abstract Introduction Odin Framework Design Applications Odin Framework Implementation Evaluation Conclusion 20 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 21 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 22 Odin Framework Implementation LVAP: four-tuple {mac_addressclient, ip_v4_addressclient, lvap_bssidclient, lvap_ssidclient} 23 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 24 Outline Abstract Introduction Odin Framework Design Applications Odin Framework Implementation Evaluation Conclusion 25 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 ReAssociation, Single Handoff Impact on HTTP Download, and LVAP-Handoff Benchmark 26 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? 27 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 28 Evaluation 29 Evaluation Third experiment: Test many handoffs with Odin LVAP-handoffs repeated at a fixed interval Throughput degradation measured 30 Evaluation 31 Outline Abstract Introduction Odin Framework Design Applications Odin Framework Implementation Evaluation Conclusion 32 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 33 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 34 Questions? 35