Embed Size (px)
Citation preview
Giuseppe Bianchi
Network Programmability:A holistic perspective
Giuseppe BianchiCNIT / University of Roma Tor Vergata
Credits to: Wireless MAC processor I. Tinnirello, P. Gallo, D. Garlisi, F. Giuliano, F. GringoliOpenstate M. Bonola, A. Capone, C. Cascone, S. Pontarelli
EU Support
Giuseppe Bianchi
Innovation via standards…Way too many standards?
Source: IETF
Giuseppe Bianchi
Giuseppe Bianchi
Vendors dominated?
IETF
Stats even more biased towards vendors in wireless fora
Giuseppe Bianchi
Network protocolstandardization: the aftermath
It takes YEARS to standardize No difference if wired or wireless Remember 802.11e?
«One size hardly fits all»: the amendmentsmultiplication nightmare E.g. 802.11 WLAN, think to the «non PHY» (soft) amendments
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
Are standards always the best possibleideas/solutions? Are those who drive standardization always the best scientists? How many clever and compelling solutions remain on paper?
Cost & deployment issues, delay, security gaps, rollout and compatibility issues,…
Giuseppe Bianchi
The «obvious» solution
Get rid of standardized protocols!
Not nearly a new insight! e.g. recall the title of a 2011 Scott Shenker’s talk
The future of networking, and the past of protocols All active networking research in the mid 90ies
In principle obvious, as well: Shift from
«protocol standardization» to
«protocol programming interface standardization»
In practice… Which interfaces/APIs? Which control/deployment means?
Giuseppe Bianchi
SDN to the rescue
Data-plane
Control-plane
Data-plane
Control-plane
Data-plane
Control-plane
Switch Data-plane
Data-plane
Data-plane
Control-plane
Programmableswitch
Traditional networking Software-Defined Networking
dumb, fast
smart, slow, (logically) centralized
API to the data plane
(e.g., OpenFlow)
Giuseppe Bianchi
SDN to the rescue???
Data-plane
Control-plane Problems:
1) Slow2) Centralized
Poorly expressive API to the data plane (e.g., OpenFlow)
Centralized controlGreat idea for network-wide states and «big picture» decisionsPoor idea for local states/decisions, (way!) better handled locally
Many network control functions require promptreaction (e.g. packet level time frame)Control latency in O(100 ms) may be an overkill!!!
100 ms = up to 300.000.000 packets lost @ 100 gbps
Remote controller Signalling overhead
Giuseppe Bianchi
Distributed controllersthe «common» way to address such cons
A non-solution! still slow path latency!!
Proprietary controller extensions?Back to Babel?
«true» fast path solution: update forwarding rules in 1 packettime – 3 ns @ 40B x 100 Gbps
3 ns = 60cm signal propagation…
Giuseppe Bianchi
SDN foundation: SW-repurposable HW
Node behavior
Description
(formal)
Network Entitye.g. Switch, device, etc
Any vendor, any size, any HW/SW platform…
Key requirement: platform-independence!
Giuseppe Bianchi
Wired networks: the OpenFlow 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.
Giuseppe Bianchi
OpenFlow match/action abstraction
SwitchPort
MACsrc
MACdst
Ethtype
VLANID
IPSrc
IPDst
IPProt
TCPsport
TCPdport
MatchingRule Action
1. FORWARD TO PORT2. ENCAPSULATE&FORWARD3. DROP4. …Extensible
Vendor-implementedProgrammable logic
Pre-implemented matching engine
Giuseppe Bianchi
ExampleDescription
Port MAC src
MACdst
Eth type
VLAN ID
IP Src IP Dest
TCP sport
TCP dport
Action
L2switching
* * 00:1f:..
* * * * * * Port6
L3 routing * * * * * * 5.6.*.* * * Port6
Micro-flow handling
3 00:20..
00:1f.. 0x800
Vlan1 1.2.3.4
5.6.7.8
4 17264 Port4
Firewall * * * * * * * * 22 Drop
VLAN switching
* * 00:1f.. * Vlan1 * * * * Port6,port7, port8
Readily implemented in legacy TCAMTernary Content Addressable Memory
Giuseppe Bianchi
In search of greater flexibility: which programming abstractions?
Wired world: mostly openflowOpenFlow not nearly a “programming language” for protocol
developmentAll complexity so far in controllers OpenFlow “patches” to fix major shortcomings
Recent initiatives: POF (2013+), P4 (2014+)mostly on improving matching flexibility (header parsing)
Wireless world: up to 2011, almost complete neglect[quoting C. Partridge, 2011, talking about the rise of practical SDR:
…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 […].
Giuseppe Bianchi
controller
Our target (wireless LAN scenario)
Please Install this radio protocolstack
Hello, may I associate?
[using a legacy protocol, e.g. DCF]
Monitor and detect Contextchanges (interf., traffic, hidden nodes, neighbors, etc)
Here’s a new context specificprotocol stack! Let’s reconfigure
terminals to best fitnew condition
Crucial issue: WHICH platform-agnostic radio behavior progr. language?!
Giuseppe Bianchi
Our solution for programmableMAC protocols
FLAVIA project (2010-2013)Also with IITPRestricted to MAC
A pragmatic compromise!Identify elementary primitives implemented in the NIC
Not programmable, similar philosophy as OpenFlow Actions
Find a formal and abstract way to compose them into a programmer-desired radio behaviorOur key idea: XFSM
Transform NIC into an «XFSM executor»Called «wireless MAC processor»
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
CONDITIONSboolean/arithmetic tests on available registers/info
Frame address == X, queue length >0, ACK received, power level < P, etc
Elementary primitives
Giuseppe Bianchi
Actually Implemented APIPlatform: Broadcom Airforce54g commodity card
Giuseppe Bianchi
eXtended Finite State Machines
Our “programming language”
Originstate
Destinationstate
config action()
Destinationstate
EVENT(condition)Action()
Destinationstate
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 DCFsimplified for graphical convenience
Giuseppe Bianchi
MAC engine: specialized XFSM executor inside the NIC (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 = real-time handling Different MAC protocols = “XFSM program”! Two platforms:
Broadcom Airforce54g 4311/4318WARP SDR
“machine language” for MAC engine
Control agent for dynamic upload/reconfiguration of “MAClets”
Our “processor”
MAC protocol specification:XFSM design
(e.g. Eclipse GMF)
Machine-readable code
Custom language compiler
Code injectionin radio HW platform
MAC Engine
MAC Bytecode
Public domain Code & details @
http://wmp.tti.unipa.it
Giuseppe Bianchi
Back to wired SDN switches…
Aftermath: XFSM = very appropriate abstractionfor wireless MAC protocols’ programming
Openflow: compromise, which permits «only» to program stateless flow tables in wired network switches
Crazy idea? OpenFlow + XFSM?Problem: wire speed… we cannot rely on CPUs on the fast path!
Our surprising finding: an OpenFlow switchalready contains most of the HW needed to turn it into an XFSM executor!!With almost marginal (!) architecture modification
Details: ACM CCR 2014, IEEE HPSR 2015
Giuseppe Bianchi
Remember OF match/action API
SwitchPort
MACsrc
MACdst
Ethtype
VLANID
IPSrc
IPDst
IPProt
TCPsport
TCPdport
MatchingRule Action
1. FORWARD TO PORT2. ENCAPSULATE&FORWARD3. DROP4. …Extensible
Vendor-implementedProgrammabile logic
Pre-implemented matching engine
Giuseppe Bianchi
What is the OF abstraction, formally?
Packet header match = “Input Symbol” in a finite set I={i1, i2, …, iM}. One input symbol = any possible header match Possible matches pre-implemented; cardinality depends on match
implementation Theoretically, it is irrelevant how the Input Symbols’ set I is established
i.e. each input symbol = Cartesian combination of multiple header field matches, further including “wildcard” matches;
E.s. incoming packet destination port = 5238 AND source IP address is 160.80.82.1, and the VLAN tag is 1111, etc.
OpenFlow actions = “Output Symbols” in finite set O={o1, o2, …, oN} Pre-implemented actions
OpenFlow’s match/action abstraction: a map T : I O all what the third party programmer can specify!
Giuseppe Bianchi
Reinterpreting the SAME OF abstraction
OpenFlow map is trivially recognized to be a very special and trivial case of a Mealy Finite State Machine
T : {default-state}× I {default-state}× O,
i.e. a Finite State Machine with output, where we only have one single (default) state!
Let’s turn it into a more general Mealy machine!
Giuseppe Bianchi
Example: Port Knocking firewallknock «code»: 5123, 6234, 7345, 8456
IPsrc=1.2.3.4 Port=5123 Drop(); 1.2.3.4 1° knock OK
IPsrc=1.2.3.4 Port=6234 Drop(); 1.2.3.4 2° knock OK
IPsrc=1.2.3.4 Port=7345 Drop(); 1.2.3.4 3° knock OK
IPsrc=1.2.3.4 Port=8456 Drop(); 1.2.3.4 OPEN port SSH
IPsrc=1.2.3.4 Port=22 Forward()
Giuseppe Bianchi
Port Knocking @ controller
IPsrc=any Port=anyDROP
controller
Encapsulate & forwardALL packets of ALL flows
IPsrc=any Port=any
Maintain Knock state per flow
When knock sequencefinalized, add entry <Ipsrc, port=22; forward>
Lots of overhead!! Needed as no «knock» state handled in switch
Giuseppe Bianchi
«Abstract» description for port knocking: Mealy Machine
DEFAULT
Stage 1
Stage 2
Stage 3
OPEN
Port=6234Drop()
Port!=6234Drop()
Port!=5123Drop()
Port=5123Drop()
Port=7345Drop()
Port=8456Drop()
Port!=7345Drop()
Port!=8456Drop()
Port=22Forward()
Port!=22Drop()
Giuseppe Bianchi
Can transform in a flow table? Yes: MATCH: <state, port> ACTION: <drop/forward, state_transition>
Plus a state lookup/update
state event
DEFAULT
STAGE-1
Port=5123
Port=6234
STAGE-2
STAGE-3
Port=7345
Port=8456
OPEN Port=22
OPEN
*
Port=*
Port=*
Match fields Actions
action Next-state
drop
drop
STAGE-1
STAGE-2
drop
drop
STAGE-3
OPEN
forward OPEN
drop
drop
OPEN
DEFAULT
IPsrc PortMetadata:State-label
State DB
State DB
IpsrcOPEN
Ipsrc: ??
Giuseppe Bianchi
Putting all together
Flow key stateIPsrc= … …Ipsrc= … …
… … …… … …
IPsrc=1.2.3.4IPsrc=5.6.7.8
STAGE-3OPEN
IPsrc= no match DEFAULT
IPsrc= … …
State Table
… … …
IPsrc=1.2.3.4 Port=8456
1) State lookup
state eventDEFAULTSTAGE-1
Port=5123Port=6234
STAGE-2STAGE-3
Port=7345Port=8456
OPEN Port=22OPEN
*Port=*Port=*
XFSM Table
Match fields Actionsaction Next-state
dropdrop
STAGE-1STAGE-2
dropdrop
STAGE-3OPEN
forward OPENdropdrop
OPENDEFAULT
IPsrc=1.2.3.4 Port=8456STAGE-3
2) XFSM state transition
IPsrc=1.2.3.4 Port=8456
OPEN
3) State update
write
Write: OPEN
1 «program» XFSM table for all flows(same knocking sequence)
N states, one per (active) flow
Giuseppe Bianchi
Cross-flow state handling
MACdst MACsrc
Flow key state48 bit MAC addr Port #
lookupState Table
MACdst MACsrc
Flow key state48 bit MAC addr Port #
updateState Table
state eventPort# *
action Next-stateforward In-port
XFSM Table
DIFFERENT lookup/update scope
Field 1 Field 2 Field N
Flowkey selector Read/write signal
Yes but what about MAC learning, multi-port protocols (e.g., FTP), bidirectional flow handling, etc?
Giuseppe Bianchi
Proof of concept
SW implementation: Trivial modifications to SoftSwitch, Public domain
HW implementation: 5 clock (2 SRAM read + 2 TCAM + 1 SRAM write) 10 Gbps just requires 156 MHz clock TCAM, trivial Optimization in progress (pipelining) for 100 Gbps.
Mixer
Mixer
delay queue
Ingress queues
Look-up
extractor
Look-up
extractor
D-leftHash Table
D-leftHash Table
TCAM1
TCAM1
RAM1RAM1
TCAM2
TCAM2
RAM2RAM2
next state
action
Flow table
XFSM table
update
extractor
update
extractor
Action BlockAction Block
egress queues
update
lookup
lookup+state
HW Details in HPSR 2015, Pontarelli, Bonola, Bianchi, Capone, Cascone
Giuseppe Bianchi
Applications
DONE: Port Knocking MAC learning Label/address
advertisement learning Reverse Path Forwarding Flow-consistent Load
Balancing DDoS multi-stage flow
marking …
Our challenge: towards an open «flow processor»?
CHALLENGE: IDS/DPI TCP flow processing Monitoring …
Need new «actions»Need extra logic (full XFSM)
All (!) otherwise not possible without explicitcontroller’s involvement or custom distrib.
control…
Giuseppe Bianchi
Data-plane
Control-plane
OpenFlowswitch
OpenFlow / SDN
Forwarding rules(match/action tables)
SMART!
DUMB!
A new way to think to SDN
Our view / SDN
Data-plane
Control-plane
OpenStateswitch
Forwarding behavior(XFSMs):
Forwarding rules ANDhow they should changeor adapt to «events»
SMART!
SMART!
in a nutshell: ability to program LOCAL CONTROL TASKS down in the switch
Smart switches can dynamicallyupdate flow tablesat wire speed
Central control still decides howswitches shall«behave»
Giuseppe Bianchi
Conclusions
Extended Finite state machines: the «right» network programming abstraction?Wireless AND wired!Towards a unifying, holistic, programming model?
Many further technical challengesOpenFlow extensions: From Mealy FSM to full XFSM?Which appropriate action sets? Is this model viable for LTE/5G BS?
Rethinking control-data plane SDN separation?Control = Decide! Not decide+enforce!Back to active networking 2.0? (but now with a clearcut abstraction in mind)
