Wireless MAC layer reconfigurability

Report
Platform-independent Wireless
Device Reconfiguration
What can we learn from SDN?
Anything we may hand back to SDN?
Giuseppe Bianchi
CNIT / University of Roma Tor Vergata
Credits to:
Wireless MAC processor
Openstate
Giuseppe Bianchi
 I. Tinnirello, P. Gallo, D. Garlisi, F. Giuliano, F. Gringoli
 M. Bonola, A. Capone, C. Cascone
Software-Defined Radio
from radios with behavior fixed in
hardware to radios with behavior
determined by software
20+ years long research path; excellent
technologies
AirBlue, CalRadio, GNURadio, RUNIC, SORA,
USRP, WARP, …
So far, niche exploitation
E.g. military
But commercial transition seems now here
Giuseppe Bianchi
Software-Defined Radio
Unfortunately… [quoting Partridge, 2011]
… [we] are all imperfectly prepared to take
advantage.
Research on vital questions has been
extremely variable
with wonderful work (such as finding the right mix of
programmable hardware to support high performance
signal processing in radios)
undermined by almost complete neglect - such as
how to describe radio behavior independent
of platform […].
C. Partridge, Realizing the future of Wireless Data communication, 2011
Giuseppe Bianchi
Meanwhile, standards & vendors …
One-size-fits-all protocols
E.g. 802.11 WLAN
Packing as many amendments as possible into one
protocol
802.11e QoS, 802.11p vehicular, 802.11s mesh,
802.11v mgmt, 802.11z direct link enhancements,
802.11aa multimedia, 802.11ae QoS mgmt, 802.11ah
M2M, etc
Rationale: must fit several largely
different contexts and scenarios
Aftermath: years to finalize, backward
compatibility, compromises, …
Giuseppe Bianchi
One size hardly fits all
context matters!
Dynamic spectrum access
Very diverse situations (e.g. countries)
very diverse environmental conditions
» Dense/sparse, hidden terminals, legacy deployments, etc
Different propagation characteristics
» Sub-GHz, THz
Niche environments with specific needs
home, industrial, M2M, …
Adaptation to specific context or applications
Virtualization, access network sharing
Multi-tenancy
Multiple coexisting applications
» M2M and H2H over same access network…
And many more…
Diverse needs  diverse design!
Giuseppe Bianchi
Everything would be much easier if…
Monitor and detect Context
changes (interf., traffic,
hidden nodes, neighbors, etc)
Hello, may I associate?
Here’s
a new this
context
Please Install
radiospecific
protocol
protocol stack!
stack
[using
a legacy protocol, e.g. DCF]
Let’s reconfigure
terminals to best fit
new condition
Whole radio protocol stack
as a sort of JAVA applet
How to make this vision come true?
Either a platform-agnostic radio programming language, or… all devices of the same vendor…
Giuseppe Bianchi
Multi-tenancy would become trivial
Operator A
Change of context conditions
Giuseppe Bianchi
Operator B
Change of context conditions
For instance:
MAC protocols’ time slicing
Time «slice» dedicated to OPA, best effort traffic  chooses DCF-like
Time «slice» dedicated to OPA, guaranteed traffic  chooses TDM-like
trivial idea, isolation guaranteed, any (custom) MAC protocol in any tenant’ slice…
but today hard to implement (and non standard)
Giuseppe Bianchi
In the mean time,
in another (wired) galaxy…
The rise of Software Defined
Networking
OpenFlow, 2008
SDN, 2010
Market hype, 2012
Almost 2 B$ SDN companies acquisition
» Mainly Nicira, but also Contrail, Big Switch, Cariden,
Vyatta, …
Compare timing and $$$ with SDR take up…
Giuseppe Bianchi
Why SDN = $$$
SDN: programmable central control of
network operation and traffic
Open, vendor-netural, APIs
Northbound, southbound (mainly OpenFlow)
Easy and fast deployment and innovation
Net «app»
Controller
Net «app»
Net «OS»
Device-level, standard-based, interface – southbound API
Data plane
Packet
Forwarding
Packet
Forwarding
Packet
Forwarding
Giuseppe Bianchi
Which SDN breakthrough?
 Control/data plane separation?
 Nah…
 A key feature, but not nearly new
Well established in POTS, SNMP, etc
Very well established in wireless as well
» Entrerprise WLAN, CAPWAP since 2003, …
 SDN real breakthrough: viable
vendor-neutral programming
abstractions!
Node behavior
Description
(formal)
Network
Entity
e.g. Switch
Any vendor, any size, any HW/SW platform…
Giuseppe Bianchi
OpenFlow: a compromise
[original quotes: from OF 2008 paper]
Best approach: “persuade commercial name-brand
equipment vendors to provide an open, programmable,
virtualized platform on their switches and routers”
Plainly speaking: open the box!! No way…
Viable approach: “compromise on generality and seek
a degree of switch flexibility that is
High performance and low cost
Capable of supporting a broad range of research
Consistent with vendors’ need for closed
platforms.
A successful compromise, indeed… ask Nicira …
Giuseppe Bianchi
OpenFlow: just one abstraction
good for switches, not for «all»
Programmabile logic
Vendor-implemented
Matching
Rule
Action
1. FORWARD TO PORT
2. ENCAPSULATE&FORWARD
3. DROP
4. …
Extensible
Pre-implemented matching engine
Switch MAC
Port
src
MAC
dst
Eth
type
Giuseppe Bianchi
VLAN
ID
IP
Src
IP
Dst
IP
Prot
TCP
sport
TCP
dport
Back to the wireless galaxy…
Research stuck to the “best approach”: “persuade
commercial name-brand equipment vendors to provide a
same open programmable platform on their Wireless NICs”
Plainly speaking: let’s all use, e.g., WARP!! No way…
Viable approach: “compromise on generality and seek a
degree of Wireless NIC flexibility that is
High performance and low cost
Capable of supporting a broad range of research
Consistent with vendors’ need for closed
platforms.
But which «right compromise»?
Describing a wireless device behavior is NOT
as «easy» as abstracting a flow table…
Giuseppe Bianchi
Let’s focus on MAC protocols
Our work
Infocom 2012, Context 2012, Wintech 2013
Simpler to address than «full» SDR,
but already not nearly trivial
How to provide a platform-agnostic
description of MAC protocols which
Does not require open source devices
Still permits to operate at ms time scales
Must run in the (closed source) NIC…
Giuseppe Bianchi
Learn from computing systems?
 1: Instruction sets
perform elementary tasks on the platform
A-priori given by the platform
Can be VERY rich in special purpose computing platforms
» Crypto accelerators, GPUs, DSPs, etc
MIMIC all
 2: Programming Let’s
languages
sequence of such instructions + conditions
this! or algorithm
 Convey desired platform’s operation
 3: Central Processing Unit (CPU)
execute program over the platform
 Unaware of what the program specifically does
 Fetch/invoke instructions, update registers, etc
Clear decoupling between:
- platform’s vendor
 implements (closed source!) instruction set & CPU
- programmer
 produces SW code in given language
Giuseppe Bianchi
1: Which elementary MAC tasks?
(“our” instruction set!)
 ACTIONS
 frame management, radio control, time scheduling
TX frame, set PHY params, RX frame,
set timer, freeze counter, build header,
forge frame, switch channel, etc
 EVENTS
 available HW/SW signals/interrupts
Busy channel signal, RX indication,
inqueued frame, end timer, etc
 CONDITIONS
 boolean/arithmetic tests on available registers/info
Frame address == X, queue length >0,
ACK received, power level < P, etc
Giuseppe Bianchi
Implemented API
Platform: Broadcom Airforce54g commodity card
Just “one” possible API
convenient on our commodity platform
“others” possible as well
improved/extended
tailored to more capable radio HW
Our point, so far:
have a specified set of actions/events/conditions,
not “which” specific one)
Giuseppe Bianchi
2: How to compose MAC tasks?
(“our” programming language!)
Convenient “language”: XFSM
eXtended Finite State Machines
Compact way for composing available acts/ev/cond
to form a custom MAC protocol logic
Origin
state
EVENT
(condition)
Action()
Destination
state
config action()
Destination
state
Destination
state
Giuseppe Bianchi
XFSM example: legacy DCF
simplified for graphical convenience
Actions:
set_timer, stop_timer,
set_backoff,
resume_backoff,
update_cw,
switch_TX, TX_start
Events:
END_TIMER,
QUEUE_OUT_UP,
CH_DOWN, CH_UP,
END_BK,
MED_DATA_CONF
Conditions:
medium, backoff,
queue
Giuseppe Bianchi
3: How to run a MAC program?
(MAC engine – XFSM onboard executor - our CPU!)
MAC engine: specialized XFSM executor
(unaware of MAC logic)
Fetch state
Receive events
Verify conditions
Perform actions and state transition
Once-for-all implemented in NIC
(no need for open source)
“close” to radio resources = straightforward real-time
handling
Different MAC protocol = different “XFSM program”!
Giuseppe Bianchi
Is this viable?
 Implemented on an ultra-cheap commodity WLAN NIC
 Real world card: Broadcom Airforce54g 4311/4318
 Poor resources: general purpose processor (88 MHz),
4KB data memory, 32 KB code memory
 More recently, also implemented on WARP (but this was not a challenge!)
Implementation at a glance:
 Original 802.11 firmware deleted (we do NOT want yet
another firmware MAC to hack!)
 Replaced with [once for all developed in assembly
language]:
 Implementation of actions, events, conditions
 in part reusing existing HW facilities:
» HW configuration registers for radio resource and event handling
» Frequency, power, channel sensing, frame forging facilities, etc
» Available HW events (packet queued, plcp end, rx end, rx correct frame, crc failure,
timer expiration, carrier sense, etc)
 MAC engine: XFSM executor
 Several annoyting technical hurdles addressed (e.g. lack of support of interrupt
handling)
 Developed “machine language” for MAC engine
Giuseppe Bianchi
MAC Programs
 MAC description:
 XFSM
B
A
MAC protocol specification:
XFSM design
C
 XFSM  tables
A
B
C
C
B
A
(e.g. Eclipse GMF)
Machine-readable code
T(A,B)
T(B,C)
T(C,A)
Custom language compiler
T(C,B)
 Transitions
 «byte»-code event, condition, action
Portable over different vendors’
devices, as long as API is the same!!
 Pack & optimize in WMP «machinelanguage» bytecode
A T(A,B)
B
C
Giuseppe Bianchi
T(B,C)
T(C,A)
Code injection
in radio HW platform
MAC Bytecode
MAC Engine
T(C,B)
Machine Language Example
(DCF, 544 bytes)
Giuseppe Bianchi
Wireless MAC Processor:
Overall architecture
 MAC Engine: XFSM executor
 Memory blocks: data, prog
 Registers: save system state
(conditions);
 Interrupts block passing HW
signals to Engine (events);
 Operations invoked by the
engine for driving the
hardware (actions)
Giuseppe Bianchi
From MAC Programs to MAClets
Upload MAC program on NIC from remote
While another MAC is running
Embed code in ordinary packets
 WMP Control
Primitives
 load(XFSM)
 run(XFSM)
 verify(XFSM)
 switch(XFSM1, XFSM2,
ev, cond)
 Further primitives
 Synchro support for
distributed start of same
MAC operation
 Distribution protocol
“Bios” state machine: DEFAULT protocol (e.g. wifi) which all terminals understand
Giuseppe Bianchi
Multi-threaded MAC
Seamless switch from one MAC program to another in negligible time
less than 0.2 us over such cheap hardware!
(plus channel switching time if required)
Giuseppe Bianchi
AP Virtualization with MAClets
 Two operators on same
AP/infrastructure
 A: wants TDM, fixed rate
 B: wants best effort DCF
Timer expiration
 Trivial with MAClets!
DCF
SUSPEND
 Customers of A/B download
respective TDM/DCF MAClets!
Beacon reception & conversely
 Isolation via MAClet design
 Time slicing DESIGNED INTO the MAClets! (static or dynamic)
Giuseppe Bianchi
Controller’s architecture
used OMF as SDN controller… (!)
Measurement process
Collects statistics for context estimation
Resource Controller
Manages device (load, control)
Experiment Controller
Network-wide orchestration
Giuseppe Bianchi
Public-domain
 Supported by the FLAVIA EU FP7 project
 http://www.ict-flavia.eu/
 Ongoing integration in the CREW EU FP7 federated testbed
 http://www.ict-flavia.eu/
 Public domain release
 Project page: http://wmp.tti.unipa.it
 Download: https://github.com/ict-flavia/Wireless-MAC-Processor
 Developer team:




[email protected]
[email protected]
[email protected]
[email protected]
 Released distribution:
 Binary image for WMP
 You DO NOT need it open source!
Remember the “hard-coded” device philosophy…
 Conveniently mounted and run on Linksis or Alix
 Source code for everything else
 Manual & documentation, sample programs
Giuseppe Bianchi
Back again to the wired galaxy…
Aftermath: XFSM as a very
appropriate abstraction for
wireless MAC protocols’
programming
Openflow: compromise, which
permits «only» to program
stateless flow tables
Crazy idea? OpenFlow + XFSM?
Giuseppe Bianchi
OF’s remote intelligence…
Controller Application
Winning
local (smart = states)
Poor idea for
states/decision, (way!)
Network
OS
better handled
locally
SDN idea for
network-wide states and
«big picture» decisions
(less delay, less signalling load)
Events from switches
Topology changes,
Traffic statistics,
Arriving packets
Commands to switches
(Un)install rules,
Query statistics,
Send packets
Forwarding device (dumb)
The real cause: OF does not permit to «program»
stateful rule changes (remember, OF was a compromise)
Giuseppe Bianchi
Example: how you’d implement
an OF port knocking firewall?
knock «code»: 5123, 6234, 7345, 8456
IPsrc=1.2.3.4
Port=5123
Flow 1.2.3.4:
encapsulate & forward
DROP
Port 5123? Store state,
1° knock OK
controller
Giuseppe Bianchi
Example: how you’d implement
an OF port knocking firewall?
knock «code»: 5123, 6234, 7345, 8456
IPsrc=1.2.3.4
Port=6234
Flow 1.2.3.4:
encapsulate & forward
DROP
Port 6234? Store state,
2° knock OK
controller
Giuseppe Bianchi
Example: how you’d implement
an OF port knocking firewall?
knock «code»: 5123, 6234, 7345, 8456
IPsrc=1.2.3.4
Port=7345
Flow 1.2.3.4:
encapsulate & forward
DROP
Port 7345? Store state,
3° knock OK
controller
Giuseppe Bianchi
Example: how you’d implement
an OF port knocking firewall?
knock «code»: 5123, 6234, 7345, 8456
IPsrc=1.2.3.4
Port=8456
Flow 1.2.3.4:
encapsulate & forward
DROP
Add flow entry for 1.2.3.4:22
Port 8456? Store state,
OPEN
controller
Giuseppe Bianchi
Example: how you’d implement
an OF port knocking firewall?
knock «code»: 5123, 6234, 7345, 8456
IPsrc=any
Port=any
DROP
ALL packets of ALL flows
Must be forwarded to controller!!
Until flow entry installed!
controller
Giuseppe Bianchi
Controller implementation for
port knocking: Mealy Machine
(simpler form of XFSM)
Port!=5123
Drop()
Port=5123
Drop()
DEFA
ULT
Port=7345
Port=6234
Drop()
Drop()
Stage
1
Port!=6234
Drop()
Port=8456
Stage
2
Port!=7345
Drop()
Drop()
Stage
3
Port!=8456
Drop()
Port=22
Forward()
OPEN
Port!=22
Drop()
1 state machine for all flows (same knocking sequence)
N states, one per (active) flow
Giuseppe Bianchi
Can transform in a flow table? Yes!
Match fields
Actions
state
event
action
Next-state
DEFAULT
Port=5123
drop
STAGE-1
STAGE-1
Port=6234
drop
STAGE-2
STAGE-2
Port=7345
drop
STAGE-3
STAGE-3
Port=8456
drop
OPEN
OPEN
Port=22
forward
OPEN
OPEN
Port=*
drop
OPEN
*
Port=*
drop
DEFAULT
Metadata
(any bit string)
Giuseppe Bianchi
Header field
(port #)
If next state were an OF instruction,
this would be a STANDARD
OF1.3+ flow table!
TCAM implementation
And what about flow states?
Flow key
state
IPsrc= … …
…
…
…
Ipsrc= … …
…
…
…
IPsrc=1.2.3.4
STAGE-3
IPsrc=5.6.7.8
OPEN
IPsrc= … …
IPsrc= no match
…
…
…
DEFAULT
Just a (Hash) Table, e.g. dleft/cuckoo hash
No need for TCAM (though useful extension for static matches)
Giuseppe Bianchi
Putting all together
IPsrc=1.2.3.4
Port=8456
State Table
Flow key
IPsrc= … …
Ipsrc= … …
IPsrc=1.2.3.4
IPsrc=5.6.7.8
IPsrc= … …
IPsrc= no match
1) State lookup
state
… … …
… … …
STAGE-3
OPEN
… … …
DEFAULT
XFSM Table
Match fields
Actions
IPsrc=1.2.3.4
Port=8456
STAGE-3
2) XFSM state transition
state
event
action
Next-state
DEFAULT
STAGE-1
STAGE-2
STAGE-3
OPEN
OPEN
*
Port=5123
Port=6234
Port=7345
Port=8456
Port=22
Port=*
Port=*
drop
drop
drop
drop
forward
drop
drop
STAGE-1
STAGE-2
STAGE-3
OPEN
OPEN
OPEN
DEFAULT
State Table
Flow key
IPsrc=1.2.3.4
Port=8456
3) State update
Giuseppe Bianchi
OPEN
IPsrc= … …
Ipsrc= … …
IPsrc=1.2.3.4
IPsrc=5.6.7.8
IPsrc= … …
IPsrc= no match
state
… … …
… … …
Write:OPEN
OPEN
… … …
DEFAULT
Cross-flow state handling
 Yes but what about MAC learning, multi-port
protocols (e.g., FTP), bidirectional flow handling, etc?
MACdst
MACsrc
State Table
lookup
Flow key
state
Port #
48 bit MAC addr
XFSM Table
MACdst
MACsrc
update
state
event
action
Next-state
Port#
*
forward
In-port
State Table
Flow key
48 bit MAC addr
DIFFERENT lookup/update scope
Field 1
Field 2
Flowkey selector
Giuseppe Bianchi
Field N
Read/write signal
state
Port #
Aftermath: a nice surprise!
 OpenFlow can support states and state transitions!
 With marginal modifications!
See Openstate, ACM CCR, April 2014
 Bringing control back inside the switch
At wire speed
Via platform independent abstraction
A new perspective towards SDN control/data plane separation?
» Controller DECIDES, but switch can now ENFORCE! A lot faster!
 Proof of concept implementations
 Software: O(days) on SoftSwitch (OFv1.3)
 Hardware: in progress, first prototype at 10 Gbps without any problems
Reuses existing commodity hardware!
 Extensions:
 bidirectional flow handling!
 Example: to implement learning MAC
Giuseppe Bianchi
Conclusions
 Finite state machines: «the» programming abstraction for
network devices?
 Wireless AND wired!
 Plenty of new research directions in wireless
 How to platform-agnostic program wireless PHY and cross-layer?
 How to exploit programmable devices in the cognitive control loop?
We focuses so far on the «act» phase of the cognitive loop: how and when to
decide MAC protocol reconfiguration?
 And in OpenFlow as well
 So far proof of concept for Mealy Machines only
Can we move towards «full» XFSM?
Network switch = generic computing device?
 And new directions in SDN, as well
 What does control/data plane separation really means?
Giuseppe Bianchi

similar documents