1. 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  I. Tinnirello, P. Gallo, D. Garlisi, F. Giuliano, F. Gringoli
Openstate  M. Bonola, A. Capone, C. Cascone

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

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

4. Meanwhile, standards & vendors …
One-size-fits-all protocols
E.g WLAN
Packing as many amendments as possible into one protocol
802.11e QoS, p vehicular, s mesh, v mgmt, z direct link enhancements, aa multimedia, ae QoS mgmt, ah M2M, etc
Rationale: must fit several largely different contexts and scenarios
Aftermath: years to finalize, backward compatibility, compromises, …

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

6. Everything would be much easier if…
Monitor and detect Context changes (interf., traffic, hidden nodes, neighbors, etc)
Here’s a new context specific protocol stack!
Please Install this radio protocol stack
Hello, may I associate?
[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…

7. Multi-tenancy would become trivial
Operator B
Operator A
Change of context conditions
Change of context conditions
Custom stack A
Custom stack B

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

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

10. 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»
Net «app»
Controller
Network-wide, standard-based, interface – northbound API
Net «OS»
Device-level, standard-based, interface – southbound API
Data plane
Packet
Forwarding
Packet
Forwarding
Packet
Forwarding

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

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

13. OpenFlow: just one abstraction good for switches, not for «all»
Programmabile logic
Vendor-implemented
Matching
Rule
Action
FORWARD TO PORT
ENCAPSULATE&FORWARD
DROP …
Extensible
Pre-implemented matching engine
Switch
Port
MAC
src
MAC
dst
Eth
type
VLAN ID IP
Src IP
Dst IP
Prot
TCP
sport
TCP
dport

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

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

16. Learn from computing systems?
Let’s MIMIC all this!
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
2: Programming languages sequence of such instructions + conditions
Convey desired platform’s operation or algorithm
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

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

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

19. 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
Destination state
config action()
EVENT
(condition)
Action()
Destination state
Destination state

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

21. 3: How to run a MAC program
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”!

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

23. MAC Programs MAC description: XFSM XFSM  tables Transitions
«byte»-code event, condition, action
Portable over different vendors’ devices, as long as API is the same!!
Pack & optimize in WMP «machine-language» bytecode A C B
MAC protocol specification:
XFSM design (e.g. Eclipse GMF)
Machine-readable code
Custom language compiler
Code injection in radio HW platform
MAC Engine
MAC Bytecode
T(A,B)
T(B,C)
T(C,A)
T(C,B) A B C
T(A,B)
T(B,C)
T(C,A)
T(C,B) A B C

24. Machine Language Example (DCF, 544 bytes)

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

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

27. Multi-threaded MAC less than 0.2 us over such cheap hardware!
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)

28. AP Virtualization with MAClets
Two operators on same AP/infrastructure
A: wants TDM, fixed rate
B: wants best effort DCF
Trivial with MAClets!
Customers of A/B download respective TDM/DCF MAClets!
Isolation via MAClet design
Time slicing DESIGNED INTO the MAClets! (static or dynamic)
Timer expiration
DCF
SUSPEND
Beacon reception
& conversely

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

30. Public-domain Supported by the FLAVIA EU FP7 project
Ongoing integration in the CREW EU FP7 federated testbed
Public domain release
Project page:
Download:
Developer team:
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

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

32. OF’s remote intelligence…
Winning SDN idea for network-wide states and «big picture» decisions
Poor idea for local states/decision, (way!) better handled locally
(less delay, less signalling load)
Controller Application
(smart = states)
Network OS
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)

33. Port 5123? Store state, 1° knock OK
Example: how you’d implement an OF port knocking firewall? knock «code»: 5123, 6234, 7345, 8456
DROP
IPsrc=
Port=5123
Flow :
encapsulate & forward
Port 5123? Store state, 1° knock OK
controller

34. Port 6234? Store state, 2° knock OK
Example: how you’d implement an OF port knocking firewall? knock «code»: 5123, 6234, 7345, 8456
DROP
IPsrc=
Port=6234
Flow :
encapsulate & forward
Port 6234? Store state, 2° knock OK
controller

35. Port 7345? Store state, 3° knock OK
Example: how you’d implement an OF port knocking firewall? knock «code»: 5123, 6234, 7345, 8456
DROP
IPsrc=
Port=7345
Flow :
encapsulate & forward
Port 7345? Store state, 3° knock OK
controller

36. Example: how you’d implement an OF port knocking firewall
Example: how you’d implement an OF port knocking firewall? knock «code»: 5123, 6234, 7345, 8456
DROP
IPsrc=
Port=8456
Flow :
encapsulate & forward
Add flow entry for :22
Port 8456? Store state, OPEN
controller

37. Example: how you’d implement an OF port knocking firewall
Example: how you’d implement an OF port knocking firewall? knock «code»: 5123, 6234, 7345, 8456
DROP
IPsrc=any
Port=any
ALL packets of ALL flows
Must be forwarded to controller!!
Until flow entry installed!
controller

38. Controller implementation for port knocking: Mealy Machine (simpler form of XFSM)
DEFAULT
Stage 1
Stage 2
Stage 3
OPEN
Port=6234
Drop()
Port!=6234
Port!=5123
Port=5123
Port=7345
Port=8456
Port!=7345
Port!=8456
Port=22
Forward()
Port!=22
1 state machine for all flows (same knocking sequence)
N states, one per (active) flow

39. Can transform in a flow table? Yes!
state
event
DEFAULT
STAGE-1
Port=5123
Port=6234
STAGE-2
STAGE-3
Port=7345
Port=8456
OPEN
Port=22 *
Port=*
Match fields
Actions
action
Next-state
drop
forward
If next state were an OF instruction, this would be a STANDARD
OF1.3+ flow table!
TCAM implementation
Metadata
(any bit string)
Header field
(port #)

40. And what about flow states?
Flow key
state
IPsrc= … …
Ipsrc= … …
… … …
IPsrc=
IPsrc=
STAGE-3
OPEN
IPsrc= no match
DEFAULT
Just a (Hash) Table, e.g. dleft/cuckoo hash
No need for TCAM (though useful extension for static matches)

41. Putting all together State Table 1) State lookup XFSM Table
Flow key
state
IPsrc=
Port=8456
IPsrc= … …
… … …
Ipsrc= … …
… … …
IPsrc=
STAGE-3
IPsrc=
OPEN
1) State lookup
IPsrc= … …
… … …
IPsrc= no match
DEFAULT
XFSM Table
Match fields
Actions
state
event
action
Next-state
DEFAULT
Port=5123
drop
STAGE-1
IPsrc=
Port=8456
STAGE-3
STAGE-1
Port=6234
drop
STAGE-2
STAGE-2
Port=7345
drop
STAGE-3
STAGE-3
Port=8456
drop
OPEN
2) XFSM state transition
OPEN
Port=22
forward
OPEN
OPEN
Port=*
drop
OPEN *
Port=*
drop
DEFAULT
State Table
Flow key
state
IPsrc=
Port=8456
OPEN
IPsrc= … …
… … …
Ipsrc= … …
… … …
IPsrc=
Write:OPEN
3) State update
IPsrc=
OPEN
IPsrc= … …
… … …
IPsrc= no match
DEFAULT

42. Cross-flow state handling
Yes but what about MAC learning, multi-port protocols (e.g., FTP), bidirectional flow handling, etc?
State Table
MACdst
MACsrc
lookup
Flow key
state
48 bit MAC addr
Port #
XFSM Table
state
event
action
Next-state
Port# *
forward
In-port
State Table
MACdst
MACsrc
update
Flow key
state
48 bit MAC addr
Port #
DIFFERENT lookup/update scope
Field 1
Field 2
Field N
Read/write signal
Flowkey selector

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

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