Towards Programmable Enterprise WLANs With Odin
Post on 14-Jan-2016
68 Views
Preview:
DESCRIPTION
Transcript
1
Towards Programmable Towards Programmable Enterprise WLANs With Enterprise WLANs With
OdinOdin
Written By Written By Lalith SureshLalith Suresh, Julius , Julius Schulz-Zander, Ruben Merz, Anja Schulz-Zander, Ruben Merz, Anja
Feldmann, and Teresa VazaoFeldmann, and Teresa Vazao
Presented By Michael OverPresented By Michael Over
2
OutlineOutline
AbstractAbstract IntroductionIntroduction Odin Framework DesignOdin Framework Design ApplicationsApplications Odin Framework ImplementationOdin Framework Implementation EvaluationEvaluation ConclusionConclusion
3
AbstractAbstract
Odin – an SDN framework to introduce Odin – an SDN framework to introduce programmability in enterprise WLANsprogrammability in enterprise WLANs
Enterprise WLANs need to support a Enterprise WLANs need to support a wide range of serviceswide range of services
Unique challenges with WLANsUnique challenges with WLANs AP de-associations made by clientsAP de-associations made by clients Association state machine + Broadcast Association state machine + Broadcast
nature of wireless medium = Must keep nature of wireless medium = Must keep track of a large number of state changestrack of a large number of state changes
4
AbstractAbstract
To address challenges, Odin builds To address challenges, Odin builds on a light virtual AP abstractionon a light virtual AP abstraction
No client side modifications No client side modifications required, supports WPA2 Enterpriserequired, supports WPA2 Enterprise
Enterprise WLAN services can be Enterprise WLAN services can be implemented as Odin network implemented as Odin network applicationsapplications
A prototype implementation A prototype implementation demonstrates Odin’s feasibilitydemonstrates Odin’s feasibility
5
OutlineOutline
AbstractAbstractIntroductionIntroduction Odin Framework DesignOdin Framework Design ApplicationsApplications Odin Framework ImplementationOdin Framework Implementation EvaluationEvaluation ConclusionConclusion
6
IntroductionIntroduction
Modern 802.11 Enterprise WLANs range from Modern 802.11 Enterprise WLANs range from a few dozen to thousands of APs serving a a few dozen to thousands of APs serving a multitude of client devicesmultitude of client devices
Large deployments provide resilience, fault-Large deployments provide resilience, fault-tolerance, fail-over capabilities, and scalabilitytolerance, fail-over capabilities, and scalability
Common features include authentication, Common features include authentication, authorization and accounting, policy authorization and accounting, policy management, mobility management, management, mobility management, interference management with client re-interference management with client re-associations, load balancing, and QoS associations, load balancing, and QoS guaranteesguarantees
Centralized management typicalCentralized management typical
7
IntroductionIntroduction Odin – a prototype software defined Odin – a prototype software defined
networking (SDN) framework for networking (SDN) framework for enterprise WLANsenterprise WLANs
Objective: Empower network operators to Objective: Empower network operators to program and deploy typical enterprise program and deploy typical enterprise WLAN services and features as network WLAN services and features as network applicationsapplications
802.11 Challenges:802.11 Challenges: Clients make AP association decisionsClients make AP association decisions Association state machine at AP combined Association state machine at AP combined
with the broadcast nature of wireless medium with the broadcast nature of wireless medium requires keeping track of continuous state requires keeping track of continuous state changeschanges
8
IntroductionIntroduction To simplify the programming model, Odin To simplify the programming model, Odin
builds on a light virtual access point (LVAP) builds on a light virtual access point (LVAP) abstractionabstraction
LVAPs virtualize association state and LVAPs virtualize association state and separate them from the physical APseparate them from the physical AP
Multiple clients connected to an AP are Multiple clients connected to an AP are treated as a set of logically isolated clients treated as a set of logically isolated clients connected to different ports of a switchconnected to different ports of a switch
Prevents directly handling association state Prevents directly handling association state and facilitates mobility management -> and facilitates mobility management -> handoff clients without triggering the re-handoff clients without triggering the re-association mechanismassociation mechanism
9
IntroductionIntroduction
Odin is a work in progressOdin is a work in progress Assumption: It targets fully Assumption: It targets fully
centralized and reasonably sized centralized and reasonably sized deployments with one controllerdeployments with one controller
No client side modifications No client side modifications required, design supports WPA2 required, design supports WPA2 EnterpriseEnterprise
Odin is fully transparent to the clientOdin is fully transparent to the client
10
OutlineOutline
AbstractAbstract IntroductionIntroductionOdin Framework DesignOdin Framework Design ApplicationsApplications Odin Framework ImplementationOdin Framework Implementation EvaluationEvaluation ConclusionConclusion
11
Odin Framework DesignOdin Framework Design
Simple and powerful abstractions needed Simple and powerful abstractions needed for high level services in enterprise for high level services in enterprise WLANsWLANs
802.11 clients associate or re-associate 802.11 clients associate or re-associate with any AP based on local decisionswith any AP based on local decisions
Design Goal: Prevent the programmer Design Goal: Prevent the programmer from keeping track of such changesfrom keeping track of such changes Light Virtual Access Points (LVAP)Light Virtual Access Points (LVAP) Fixed link between clients and infrastructureFixed link between clients and infrastructure
12
Odin Framework DesignOdin Framework Design
13
Odin Framework DesignOdin Framework Design
AssociationAssociation Response
Access Point (AP)
Access Point (AP)
)( )(
Probe Request
)( ) Probe Response (SSID)
Probe Response (SSID)
14
Odin Framework DesignOdin Framework Design Odin makes use of Light Virtual Access Odin makes use of Light Virtual Access
Points (LVAPs):Points (LVAPs): Start similar to standard APs with Probe Start similar to standard APs with Probe
RequestsRequests APs respond with Probe Response messagesAPs respond with Probe Response messages Handshake association occurs with one APHandshake association occurs with one AP
Key Difference: With LVAPs, every client Key Difference: With LVAPs, every client receives a unique BSSID to connect toreceives a unique BSSID to connect to
Each physical AP hosts an LVAP for Each physical AP hosts an LVAP for each connected clienteach connected client
15
Odin Framework DesignOdin Framework Design Removing a client LVAP from a Removing a client LVAP from a
physical AP and spawning it on physical AP and spawning it on another achieves a hand offanother achieves a hand off No re-association neededNo re-association needed No additional messagesNo additional messages No special software or hardware No special software or hardware
needed at the clientneeded at the client Provides clients a consistent link to Provides clients a consistent link to
the networkthe network Odin application programmer need Odin application programmer need
not be concerned with how the not be concerned with how the client’s link to the network changesclient’s link to the network changes Endpoint of link always corresponds to Endpoint of link always corresponds to
client IP and MAC addresses with the client IP and MAC addresses with the unique BSSID assigned by Odinunique BSSID assigned by Odin
16
OutlineOutline
AbstractAbstract IntroductionIntroduction Odin Framework DesignOdin Framework DesignApplicationsApplications Odin Framework ImplementationOdin Framework Implementation EvaluationEvaluation ConclusionConclusion
17
ApplicationsApplications
Seamless Seamless
MobilityMobility
18
ApplicationsApplications Load Balancing – dynamic re-Load Balancing – dynamic re-
assignment of clients to different APsassignment of clients to different APs Most existing work requires special Most existing work requires special
software on the client used by the software on the client used by the infrastructure to control associationsinfrastructure to control associations
Handoffs with LVAPs are inexpensive Handoffs with LVAPs are inexpensive and fast; reassociation based load and fast; reassociation based load balancing can be easily implementedbalancing can be easily implemented
Executing handoffs every 100 ms did Executing handoffs every 100 ms did not result in any TCP throughput not result in any TCP throughput degradation at the clientdegradation at the client
19
ApplicationsApplications
Hidden Terminal MitigationHidden Terminal Mitigation Several approaches exist – adaptive Several approaches exist – adaptive
RTS/CTS, tight scheduling, … Most RTS/CTS, tight scheduling, … Most require client modificationsrequire client modifications
Odin application: centralized view of Odin application: centralized view of the network and control over the the network and control over the association state of a clientassociation state of a client
Can provide per client Can provide per client measurements of link impairments measurements of link impairments (hidden/exposed terminals, (hidden/exposed terminals, collisions, etc.)collisions, etc.)
20
OutlineOutline
AbstractAbstract IntroductionIntroduction Odin Framework DesignOdin Framework Design ApplicationsApplications
Odin Framework Odin Framework ImplementationImplementation
EvaluationEvaluation ConclusionConclusion
21
Odin Framework Odin Framework ImplementationImplementation
Odin Master implemented on top of Odin Master implemented on top of Floodlight OpenFlow controllerFloodlight OpenFlow controller
Invokes commands on the agents – Invokes commands on the agents – add/remove LVAPs and query for add/remove LVAPs and query for statisticsstatistics
The master, through Floodlight, uses the The master, through Floodlight, uses the OpenFlow protocol to update forwarding OpenFlow protocol to update forwarding tables on the AP and switchestables on the AP and switches
Odin applications run as a thread on top Odin applications run as a thread on top of the Odin Masterof the Odin Master
22
Odin Framework Odin Framework ImplementationImplementation
Odin agents run on physical access Odin agents run on physical access pointspoints
Agents record information about Agents record information about clients and communicate with the clients and communicate with the Master over the Odin control Master over the Odin control channelchannel
The first step to realize LVAPs is for The first step to realize LVAPs is for Odin agents to track probe request Odin agents to track probe request frames generated by clientsframes generated by clients
23
Odin Framework Odin Framework ImplementationImplementation
LVAP: four-tuple {mac_addressclient, ip_v4_addressclient, lvap_bssidclient, lvap_ssidclient}
24
Odin Framework Odin Framework ImplementationImplementation
AuthenticationAuthentication WPA2 Enterprise – Client handshakes WPA2 Enterprise – Client handshakes
with AP and authentication server to with AP and authentication server to negotiate a session keynegotiate a session key With Odin, session key can be accounted With Odin, session key can be accounted
for in LVAP state; when an AP is to host for in LVAP state; when an AP is to host an LVAP, session key is installedan LVAP, session key is installed
Guest Wi-Fi – Client assigned own Guest Wi-Fi – Client assigned own LVAP only after it has authenticated LVAP only after it has authenticated against the systemagainst the system
25
OutlineOutline
AbstractAbstract IntroductionIntroduction Odin Framework DesignOdin Framework Design ApplicationsApplications Odin Framework ImplementationOdin Framework Implementation
EvaluationEvaluation ConclusionConclusion
26
EvaluationEvaluation
Experiments performed with LVAPsExperiments performed with LVAPs Testbed: a single client, two APs on Testbed: a single client, two APs on
the same subnet, and servers to run the same subnet, and servers to run the OpenFlow controllerthe OpenFlow controller
Client is given static IP address and Client is given static IP address and authenticated is disabled; all tests authenticated is disabled; all tests averaged over 10 runsaveraged over 10 runs
Three experiments: Layer 2 Delay in Three experiments: Layer 2 Delay in Re-Association, Single Handoff Re-Association, Single Handoff Impact on HTTP Download, and Impact on HTTP Download, and LVAP-Handoff BenchmarkLVAP-Handoff Benchmark
27
EvaluationEvaluation
First experiment: Layer 2 Delay in Re-First experiment: Layer 2 Delay in Re-association using noisy wireless settingassociation using noisy wireless setting
Client is associated with one AP, then Client is associated with one AP, then handed off to anotherhanded off to another
With Odin, handoff delay is less than 1msWith Odin, handoff delay is less than 1ms What about a more heavily loaded What about a more heavily loaded
network?network?
28
EvaluationEvaluation
Second experiment: Handoff during Second experiment: Handoff during HTTP downloadHTTP download
Handoff corresponds to an Odin LVAP Handoff corresponds to an Odin LVAP migrationmigration
Over a regular 802.11 setup, the Over a regular 802.11 setup, the throughput drops to zero over several throughput drops to zero over several seconds before recoveringseconds before recovering
Using Odin, the throughput is Using Odin, the throughput is unaffected in spite of the LVAP unaffected in spite of the LVAP handoffhandoff
29
EvaluationEvaluation
30
EvaluationEvaluation
Third experiment: Test many Third experiment: Test many handoffs with Odinhandoffs with Odin
LVAP-handoffs repeated at a fixed LVAP-handoffs repeated at a fixed intervalinterval
Throughput degradation measuredThroughput degradation measured
31
EvaluationEvaluation
32
OutlineOutline
AbstractAbstract IntroductionIntroduction Odin Framework DesignOdin Framework Design ApplicationsApplications Odin Framework ImplementationOdin Framework Implementation EvaluationEvaluation
ConclusionConclusion
33
ConclusionConclusion Odin shows the benefits of introducing Odin shows the benefits of introducing
programmability into the enterprise WLAN programmability into the enterprise WLAN Light Virtual Acess Points (LVAPs) – Light Virtual Acess Points (LVAPs) –
lightweight, cheap, and be used to develop lightweight, cheap, and be used to develop network services efficientlynetwork services efficiently
Future Work:Future Work: Bigger testbed with more users, indoors and Bigger testbed with more users, indoors and
outdoorsoutdoors Further abstractions to support more network Further abstractions to support more network
appsapps Fault-tolerance, fail-over capabilities, and Fault-tolerance, fail-over capabilities, and
policy managementpolicy management
34
QuestionsQuestions
Effect of encryption keys added to LVAPs?Effect of encryption keys added to LVAPs? No measurements for the effect of increased No measurements for the effect of increased
contention on the channel due to increased contention on the channel due to increased beacons? beacons?
Their system is designed for enterprises but Their system is designed for enterprises but they provide experiments only for simple, they provide experiments only for simple, trivial networks; no evaluation for enterprise trivial networks; no evaluation for enterprise networks which are the target of the systemnetworks which are the target of the system
Lower throughput during HTTP download Lower throughput during HTTP download cancels out (and then some) the savings of cancels out (and then some) the savings of being unaffected by AP handoffbeing unaffected by AP handoff
35
Questions?Questions?
top related