Towards Programmable Enterprise WLANs With Odin

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

2. Outline • Abstract • Introduction • Odin Framework Design • Applications • Odin Framework Implementation • Evaluation • Conclusion

3. 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

4. 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

5. Outline • Abstract • Introduction • Odin Framework Design • Applications • Odin Framework Implementation • Evaluation • Conclusion

6. 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

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

8. 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

9. 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

10. Outline • Abstract • Introduction • Odin Framework Design • Applications • Odin Framework Implementation • Evaluation • Conclusion

11. 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

12. Odin Framework Design

13. Odin Framework Design Probe Request ( ) ) ( ) ( ) Probe Response (SSID) Association Association Response Access Point (AP) Probe Response (SSID) Access Point (AP)

14. 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

15. 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

16. Outline • Abstract • Introduction • Odin Framework Design • Applications • Odin Framework Implementation • Evaluation • Conclusion

17. Applications • Seamless Mobility

18. 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

19. 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.)

20. Outline • Abstract • Introduction • Odin Framework Design • Applications • Odin Framework Implementation • Evaluation • Conclusion

21. 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

22. 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

23. Odin Framework Implementation LVAP: four-tuple {mac_addressclient, ip_v4_addressclient, lvap_bssidclient, lvap_ssidclient}

24. 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

25. Outline • Abstract • Introduction • Odin Framework Design • Applications • Odin Framework Implementation • Evaluation • Conclusion

26. 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

27. 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?

28. 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

29. Evaluation

30. Evaluation • Third experiment: Test many handoffs with Odin • LVAP-handoffs repeated at a fixed interval • Throughput degradation measured

31. Evaluation

32. Outline • Abstract • Introduction • Odin Framework Design • Applications • Odin Framework Implementation • Evaluation • Conclusion

33. 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

34. 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

35. Questions?