Presentation is loading. Please wait.

Presentation is loading. Please wait.

Giuseppe Bianchi Platform-independent Wireless Device Reconfiguration What can we learn from SDN? Anything we may hand back to SDN? Giuseppe Bianchi CNIT.

Similar presentations


Presentation on theme: "Giuseppe Bianchi Platform-independent Wireless Device Reconfiguration What can we learn from SDN? Anything we may hand back to SDN? Giuseppe Bianchi CNIT."— Presentation transcript:

1 Giuseppe Bianchi 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 Giuseppe Bianchi 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 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

4 Giuseppe Bianchi Meanwhile, standards & vendors …  One-size-fits-all protocols  E.g WLAN  Packing as many amendments as possible into one protocol  e 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 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!

6 Giuseppe Bianchi Everything would be much easier if… Please Install this radio protocol stack Whole radio protocol stack as a sort of JAVA applet Hello, may I associate? [using a legacy protocol, e.g. DCF] Monitor and detect Context changes (interf., traffic, hidden nodes, neighbors, etc) Here’s a new context specific protocol stack! Let’s reconfigure terminals to best fit new condition How to make this vision come true ? Either a platform-agnostic radio programming language, or… all devices of the same vendor…

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

8 Giuseppe Bianchi For instance: MAC protocols’ time slicing Time «slice» dedicated to OP A, best effort traffic  chooses DCF-like trivial idea, isolation guaranteed, any (custom) MAC protocol in any tenant’ slice… but today hard to implement (and non standard) Time «slice» dedicated to OP A, guaranteed traffic  chooses TDM-like

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

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

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

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

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

14 Giuseppe Bianchi 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 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  s time scales  Must run in the (closed source) NIC…

16 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  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 Let’s MIMIC all this!

17 Giuseppe Bianchi  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 1: Which elementary MAC tasks? (“our” instruction set!)

18 Giuseppe Bianchi 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) Implemented API Platform: Broadcom Airforce54g commodity card

19 Giuseppe Bianchi  Convenient “language”: XFSM eXtended Finite State Machines  Compact way for composing available acts/ev/cond to form a custom MAC protocol logic 2: How to compose MAC tasks? (“our” programming language!) Origin state Destination state config action () Destination state EVENT (condition) Action () Destination state

20 Giuseppe Bianchi 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 XFSM example: legacy DCF simplified for graphical convenience

21 Giuseppe Bianchi  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”! 3: How to run a MAC program? (MAC engine – XFSM onboard executor - our CPU!)

22 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 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 Giuseppe Bianchi 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 T(A,B) T(B,C) T(C,A)T(C,B) A B C A B C T(A,B) T(B,C) T(C,A)T(C,B) A B C 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

24 Giuseppe Bianchi Machine Language Example (DCF, 544 bytes)

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

26 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

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

28 Giuseppe Bianchi 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) DCF SUSPEND Timer expiration Beacon reception & conversely

29 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

30 Giuseppe Bianchi Public-domain  Supported by the FLAVIA EU FP7 project   Ongoing integration in the CREW EU FP7 federated testbed   Public domain release  Project page:  Download: https://github.com/ict-flavia/Wireless-MAC-Processorhttps://github.com/ict-flavia/Wireless-MAC-Processor  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 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?

32 Giuseppe Bianchi OF’s remote intelligence… Network OS Controller Application (smart = states) Events from switches Topology changes, Traffic statistics, Arriving packets Commands to switches (Un)install rules, Query statistics, Send packets Forwarding device (dumb) 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) The real cause: OF does not permit to «program» stateful rule changes (remember, OF was a compromise)

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

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

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

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

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

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

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

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

41 Giuseppe Bianchi Putting all together IPsrc= Flow keystate IPsrc= … … Ipsrc= … … … … … IPsrc= IPsrc= STAGE-3 OPEN IPsrc= no matchDEFAULT IPsrc= … … State Table … … … Port=8456 stateevent DEFAULT STAGE-1 Port=5123 Port=6234 STAGE-2 STAGE-3 Port=7345 Port=8456 OPENPort=22 OPEN * Port=* XFSM Table Match fieldsActions actionNext-state drop STAGE-1 STAGE-2 drop STAGE-3 OPEN forwardOPEN drop OPEN DEFAULT IPsrc= Port=8456STAGE-3 OPEN Flow keystate IPsrc= … … Ipsrc= … … … … … IPsrc= IPsrc= Write:OPEN OPEN IPsrc= no matchDEFAULT IPsrc= … … State Table … … … IPsrc= Port=8456 1) State lookup 2) XFSM state transition 3) State update

42 Giuseppe Bianchi Cross-flow state handling MACdstMACsrc Flow keystate 48 bit MAC addr Port # lookup State Table MACdstMACsrc Flow keystate 48 bit MAC addr Port # update State Table stateevent Port# * actionNext-state forward In-port XFSM Table DIFFERENT lookup/update scope Field 1Field 2Field N Flowkey selector Read/write signal  Yes but what about MAC learning, multi-port protocols (e.g., FTP), bidirectional flow handling, etc?

43 Giuseppe Bianchi 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 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?


Download ppt "Giuseppe Bianchi Platform-independent Wireless Device Reconfiguration What can we learn from SDN? Anything we may hand back to SDN? Giuseppe Bianchi CNIT."

Similar presentations


Ads by Google