1 / 35

Towards Programmable Enterprise WLANs With Odin

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.

zia
Download Presentation

Towards Programmable Enterprise WLANs With Odin

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related