Transcript Odin - WordPress.com

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