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

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

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

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

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

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
To simplify the programming model, for instance, to not have to handle callbacks for 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

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
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 stations in infrastructure mode. Odin is fully transparent to the client

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

11. Odin Framework Design
Simple and powerful abstractions needed for high level services in enterprise WLANs
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, 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

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

13. ( ) ) ( ) 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)

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

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
In regular 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

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

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

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

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

20. Outline Odin Framework Implementation 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
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.

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

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

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

25. Outline Evaluation 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
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

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

28. Evaluation Second experiment: Handoff during HTTP download
Handoff corresponds to an Odin LVAP migration
Over a regular 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 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.

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

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

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

32. Outline Conclusion 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
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

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
Some questions I had when reading this paper…

35. Questions?
Any other questions?