From dumb to smarter switches in software

From dumb to smarter switches in software
ECOOP 2015, NetPL, Prague, July 6
From dumb to smarter switches in software defined networks: towards a stateful data plane
Antonio Capone
Politecnico di Milano – ANTLab
joint work with: G. Bianchi, M. Bonola, S. Pontarelli
– Univ. Rome Tor Vergata
C. Cascone, L. Pollini, D. Sanvito
– Politecnico di Milano
A. Capone: ECOOP -­‐ NetPL 2 015
supported by EU project
Beba
BEhavioural BAsed forwarding
www.beba-­‐project.eu
Outline
1) Switches cannot remain dumb: ➔ Data plane evolution. ¤ How far should we go?
2) Not too much not too little: ➔ OpenState and stateful data planes
3) Applied smartness: stateful applications
¤ How to incorporate statefulness in languages?
A. Capone: ECOOP -­‐ NetPL 2 015
2
Setting the scene: OpenFlow and dataplane abstraction
The future has already arrived. It's just not evenly distributed yet. [William Gibson]
A. Capone: ECOOP -­‐ NetPL 2 015
3
Classic network paradigm
Distributed network functions
OS
Forwarding HW
OS
OS
Forwarding HW
Router/switch/appliance
A. Capone: ECOOP -­‐ NetPL 2 015
State distribution mechanism
(standard protocols)
Closed platform!
Forwarding HW
4
SDN paradigm
App
App
App
Programming interface
N
Network OS
W
E
S
Data plane abstraction
Simple forwarding HW
(protocol for enforcement and notifications)
Simple forwarding HW
Simple forwarding HW
Simple forwarding HW
A. Capone: ECOOP -­‐ NetPL 2015
5
Several attempts …
Active Networks, IETF ForCES, …
… but one winner
OpenFlow
A. Capone: ECOOP -­‐ NetPL 2 015
6
OpenFlow
• OpenFlow has been proposed as a clean slate approach for new generation network
• … bit it is actually a pragmatic approach to SDN based on a simple HW abstraction that can be implemented with current HW commercial platforms
A. Capone: ECOOP -­‐ NetPL 2 015
OpenFlow controller
OpenFlow Protocol
7
HW vs SW switches
• Soft switching based on general CPU
• Switching based on network processors
• Switching based on dedicated chips
A. Capone: ECOOP -­‐ NetPL 2 015
10x
10x
8
Data plane abstraction: Flow table
Match
Actions
Counters
Bytes + packets
1.
2.
3.
4.
5.
6.
7.
Switch
Port
VLAN
ID
Forward (one or more ports)
Drop
Encapsulate and send to controller
Header rewrite
Push/pop MPLS label / VLAN tag
Queues + bitrate limiter (bit/s)
Etc..
VLAN
pcp
MAC
src
MAC
dst
Eth
type
IP
Src
IP
Dst
IP
ToS
IP
Prot
L4
sport
L4
dport
Slide courtesy: Rob Sherwood
A. Capone: ECOOP -­‐ NetPL 2 015
9
Dataplane Abstraction
OF1.0: Single Match Table (SMT)
Redirect to controller
Packet
TCAM
Apply actions, forward
Flow table
Ternary Content Addressable Memory
Drop
OF1.1: Multiple Match Table (MMT)
OpenFlow Switch Specification
Version 1.1.0 Implemented
OpenFlow Switch
Packet
In
Ingress
port
Action
Set = {}
Table
0
Packet +
ingress port +
metadata
Action
Set
Table
1
...
Table Packet
n
Action
Set
Execute
Action
Set
Packet
Out
(a) Packets are matched against multiple tables in the pipeline
➀ Find highest-priority matching flow entry
➁ Match fields:
Match fields:
Ingress port +
metadata +
pkt hdrs
Flow
Table
➁ Apply instructions:
Ingress port +
metadata +
pkt hdrs
A. Capone: ECOOP Action
-­‐ NetPL 2 015
set
Action set
➀
➂
i. Modify packet & update match fields
(apply actions instruction)
ii. Update action set (clear actions and/or
write actions instructions)
iii. Update metadata
➂ Send match data and action set to
next table
10
Switches cannot remain dumb: Data plane evolution
One man alone can be pretty dumb sometimes, but for real bona fide stupidity, there ain't nothin' can beat teamwork. [Edward Abbey]
A. Capone: ECOOP -­‐ NetPL 2 015
11
Models can be perfect and clean, reality is dirty!
• The match/action model can ideally be used to program any network behavior and to get rid of protocol limitations at any level
• But unfortunately, with OF:
– Matches can be done only on a set of predefined header fields (Ethernet, IPv4, MPLS, VLAN tag, etc.)
– Actions are limited to a rather small set
– Header manipulation (like adding label/tags, rewriting of fields, etc.) is limited to standard schemes
• As a result, OF is not really protocol independent and standards (including OF standards) are still necessary
A. Capone: ECOOP -­‐ NetPL 2 015
12
Breaking the limitation of specialized pipelines
Logical Stage 1
age 1
Logical
Stage N
Global states
Switch State
(metadata)
State
Recombine
...
Packets
K
Header re-­‐write with very Programmable (a) parser
RMT model as a sequence
of ilogical
Match-Action
long nstruction word (stages.
VLIW)
Logical Stage 2
Packet
Header
Vector
VLIW Instruction Memory
Packet
Header
Vector
other examples: FlexPipe™ (Intel), …
Src 1
Src 2
Action
Unit
(c) VLIW action architecture.
OP code
(from inst
mem)
...
Logical
Stage N
Src 3
Action
Unit
Ctrl
...
Action Input Selector (Crossbar)
OP code
...
Src 3
Src 2
Very Wide
Header Bus
Action
Memory
Src 2
RMT -­‐ Reconfigurable Match Table
Src 1
Packet
Header
Vector
Src 1
Action
Unit
Match
Tables
Match
Results
OP code
(from inst
mem)
Output
Channels
Configurable queues
Physical
Stage M
...
Logical Stage 1
Action
Unit
...
Packet
Header
Vector
Src 2
Physical
Stage Src
23
Action Input Selector (Crossbar)
Physical
Stage 1
1
...
...
Output
Channels
3 H orowitz, “Forwarding [BOS13] P. Bosshart, G. Gibb, H.-­‐S. Kim, G. Varghese, N. McKeown, M. I zzard, F. Mujica, andSrcM. e 1: RMT model architecture.
urce Waste:
g., CPU,
can vary
all ACLs,
d an edge
ing phys-
New Header
Select
...
Configurable
Output
Queues
Src 1
Very Wide
Header Bus
al
VLIW
Action
1
K
Payload
...
Input
Channels
s a sequence of logical
Match-Action
K stages.
State
Match
Tables
Packets
...
Prog.
Parser
...
1
Header
Packets
Recombine
...
...
Configurable
Output
Queues
New Header
VLIW
Action
Statistics
Logical Stage N
Action
metamorphosis: Fast programmable match-­‐action processing in hardware for SDN”, in ACM SIGCOMM 2013.
Match
Memory
delays can be ameliorated by pipelining, the ultimate challenge
such a E
design
is wiring:
unless
the current match
A. Cin
apone: COOP -­‐ NetPL 2 015
and action widths (1280 bits) are reduced, running so many
Ingress
logical
: Egress
logical
wires between :every
stage
and every memory may well
be
impossible.
match tables
match tables
In sum, the advantage of Figure 1b is that it uses a tiled
Match Results
Tables
OP code
Ctrl
VLIW Instruction Memory
13
• Reconfigurability. The controller should be able to rein di↵erent forwarding devices (e.g., Ethernet switches, loaddefine the packet parsing and processing in the field.
balancers, routers) and by di↵erent technologies (e.g., fixed• Protocol independence. The switch should not be tied
function switch ASICs, NPUs, reconfigurable switches, softto specific packet formats. Instead, the controller should
ware switches, FPGAs). This allows us to devise a combe able to specify (i) a packet parser for extracting header
mon language (P4) to represent how packets are processed
fields with particular names and types and (ii) a collection
in terms of our common abstract model. Hence, programof typed match+action tables that process these headers.
mers can create target-independent programs that a com• Target independence. Just as a C programmer does
piler can map to a variety of di↵erent forwarding devices,
not need to know the specifics of the underlying CPU, the
ranging from relatively slow software switches to the fastest
controller programmer should not need to know the deASIC-based switches.
tails of the underlying switch. Instead, a compiler should
take the switch’s capabilities into account when turning
a target-independent description (written in P4) into a
target-dependent program (used to configure the switch).
The outline of the paper is as follows. We begin by introducing an abstract switch forwarding model. Next, we
explain the need for a new language to describe protocolindependent packet processing. We then present a simple
motivating example where a network operator wants to support a new packet-header field and process packets in multiple stages. We use this to explore how the P4 program
specifies headers, the packet parser, the multiple match+
action tables, and the control flow through these tables. Finally, we discuss how a compiler can map P4 programs to
target switches.
Related work. In 2011, Yadav et al. [4] proposed an abstract forwarding model for OpenFlow, but with less emphaother example: POF (Huawei)
Figure 2: The
abstract
forwarding model.
sis on a compiler. Kangaroo [1] introduced the notion of programmable parsing. Recently, Song [5] proposed protocolforwarding
is controlled
by two types
of oper- A.
[BOS14] P. Bosshart, D. Daly, . Gibb, M. Izzard, cKeown, J. Rmodel
exford, C. Schlesinger, D. Talayco, oblivious
forwarding
which shares
our Ggoal
of protocol
in- N. MThe
ations: Configure and Populate. Configure operations prodependence,
targeted more
network
procesVahdat, but
G. Visarghese, and towards
D. Walker “P4: Programming protocol-­‐independent packet processors,” gram the parser, set the order of match+action stages, and
sors. The ONF introduced table typing patterns to express
SIGCOMM CCR, July 2014
specify the header fields processed by each stage. Configthe matching capabilities of switches [6]. Recent work on
uration determines which protocols are supported and how
NOSIX [7] shares our goal of flexible specification of match+
the switch may process packets. Populate operations add
action tables,
but Edoes
not
consider
A. Capone: COOP -­‐ NetPL 2 015protocol-independence
14
(and remove) entries to the match+action tables that were
or propose a language for specifying the parser, tables, and
specified during configuration. Population determines the
control flow. Other recent work proposes a programmatic inpolicy applied to packets at any given time.
Target programmability: P4
• OpenFlow 2.0 proposal by McKeown, Rexford et al. [BOS14]
• 3 goals: Protocol independence, Target independence, Reconfigurability
Not too much not too little: OpenState and stateful data planes
Too clever is dumb.
[Ogden Nash]
A. Capone: ECOOP -­‐ NetPL 2 015
15
Looking for the “right” abstraction
• Programmability and real world viability
– High levels of (deep) programmability in the data and control planes since ages
• Active Networks
• IETF ForCES
• Keywords for success:
– Pragmatism
– Compromise
– “Right” mix of programmability: right level of abstraction
• Many wonderful programmable platforms buried in the “lab world”
A. Capone: ECOOP -­‐ NetPL 2 015
16
Remember: OF meant to be 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. Capone: ECOOP -­‐ NetPL 2 015
17
OF forces separation of data and control
Logically-centralized control
SMART!
DUMB!
A. Capone: ECOOP -­‐ NetPL 2 015
Commands to switches
(Un)install rules,
Query statistics,
Send packets
Events from switches
Topology changes,
Traffic statistics,
Arriving packets
18
Centralized Control: pros and cons
• PROS:
– Central view of the network as a whole
• Network states, etc
– One-­‐click network config/deploy
• Platform agnostic switch API is key -­‐ e.g. OpenFlow forwarding abstraction
• CONS:
– Control latency!!!
Great idea for network-­‐wide states
and «big picture» decisions
Poor idea for local
states/decision, (way!) better
handled locally
(less delay, less load)
• O(second)
1s = 300M packets lost @ 100 gbps
– Signalling overhead
A. Capone: ECOOP -­‐ NetPL 2 015
19
Our vision
SMART!
Events from switches & central rule updates
Restricted to those of interest
for GLOBAL decisions
Decision on how network should operate
remains at the controller (SDN vision)
But “execution” of forwarding plane
updates can be locally delegated
Inject “switch control programs”
Change forwarding behavior as
SMART!
specified by “this program” IF
(local) events occur
Local processing: Ultra low Latency:
o(nanosec) versus o(sec)
Local states: lower signalling
A. Capone: ECOOP -­‐ NetPL 2 015
20
Stateless vs. Stateful data plane
Stateful model
Stateless model
(e.g. OpenFlow)
Controller
Global + local states
Control
enforcing
Event
notifications
Switch
Stateless
A. Capone: ECOOP -­‐ NetPL 2 015
Controller
SMART!
DUMB!
Global states
Control
delegation
Auto-­‐
adaption
SMART!
Event
notifications
Switch
Local states
SMART!
21
Easier said than done
• We need a switch architecture and API which is…
– High performance: state management tasks executed at wire-­‐
speed (packet-­‐based events)
– Platform-­‐independent: consistent with vendors’ needs for closed platforms
– Low cost and immediately viable: based on commodity HW
Apparently, far beyond OpenFlow switches…
Our (perhaps surprising?) finding: much closer to OF abstraction than expected!!
A. Capone: ECOOP -­‐ NetPL 2 015
22
Our approach: OpenState
[CCR14] G. Bianchi, M. Bonola, A. Capone, C. Cascone, “OpenState: programming platform-­‐
independent stateful OpenFlow applications inside the switch”, ACM Computer Communication Review, vol. 44, no. 2, April 2014.
[HPSR15] S. Pontarelli, M. Bonola, G. Bianchi, A. Capone, C. Cascone, “Stateful Openflow: Hardware Proof of Concept”, IEEE HPSR 2015, Budapest, July 1-­‐4, 2015.
[DRCN15] A. Capone, C. Cascone, A.Q.T. Nguyen, B. Sansò, "Detour Planning for Fast and Reliable Failure Recovery in SDN with OpenState", IEEE DRCN 2015, Kansas City, USA, March 24-­‐27, 2015 – BEST PAPER RUNNER UP.
[ARX14] G. Bianchi, M. Bonola, A. Capone, C. Cascone, S. Pontarelli, “Towards Wire-­‐speed Platform-­‐agnostic Control of OpenFlow Switches”, available on ArXiv, 2014.
A. Capone: ECOOP -­‐ NetPL 2 015
23
Example: Port Knocking firewall
knock «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
A. Capone: ECOOP -­‐ NetPL 2 015
Forward()
24
Port Knocking @ controller
IPsrc=any
DROP
Port=any
When knock sequence finalized, add entry <Ipsrc, port=22; forward>
Encapsulate & forward ALL packets of ALL flows
IPsrc=any
Port=any
controller
Lots of overhead!! Maintain Knock state per flow
Can we move the state machine in the switch?
A. Capone: ECOOP -­‐ NetPL 2 015
25
Can transform in a flow table? Yes: Ipsrc: ??
MATCH: <state, port> à ACTION: <drop/forward, state_transition>
Plus a state lookup/update
State DB
Metadata:
State-­‐label
IPsrc
Port
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
A. Capone: ECOOP -­‐ NetPL 2 015
IpsrcàOPEN
State DB
26
Putting all together
1) State lookup
IPsrc=1.2.3.4
2) XFSM state transition
Port=8456
STAGE-3
IPsrc= … …
Ipsrc= … …
IPsrc=1.2.3.4
IPsrc=5.6.7.8
IPsrc= … …
IPsrc= no match
state
… … …
… … …
Write:
STAGE-3
OPEN
OPEN
… … …
DEFAULT
write
Port=8456
XFSM Table
State Table
Flow key
IPsrc=1.2.3.4
Match fields
Actions
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
3) State update
OPEN
IPsrc=1.2.3.4
Port=8456
1 «program» XFSM table for all flows
(same knocking sequence)
N states, one per (active) flow
A. Capone: ECOOP -­‐ NetPL 2 015
27
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
48 bit MAC addr
state
Port #
XFSM Table
MACdst
MACsrc
update
state
event
action
Next-state
Port#
*
forward
In-port
State Table
Flow key
48 bit MAC addr
state
Port #
DIFFERENT lookup/update scope
Field 1
Field 2
Flowkey selector
A. Capone: ECOOP -­‐ NetPL 2 015
Field N
Read/write signal
28
Wrapping up
Proof of concept
• SW implementation: – Public domain: openstate-­‐sdn.org
• HW implementation:
– S. Pontarelli, M. Bonola, G. Bianchi, A. Capone, C. Cascone, “Stateful Openflow: Hardware Proof of Concept”, IEEE HPSR 2015, Budapest, July 1-­‐4, 2015.
Switch: ofsoftswitch13; Controller: Ryu
State Machines
• Events: matches, times, all-­‐flow states, meters, …
• Machine instantiations: One table/machine per set of flows, parallel machines for different set of flows, multiple stateful stages
A. Capone: ECOOP -­‐ NetPL 2 015
29
Applied smartness: How to incorporate statefulness in languages?
There are science and the applications of science, bound together as the fruit of the tree which bears it. [Louis Pasteur]
A. Capone: ECOOP -­‐ NetPL 2 015
30
Stateful applications
DONE:
• Port Knocking
• MAC learning
• Label/address advertisement learning
• Reverse Path Forwarding
• Flow-­‐consistent Load Balancing
• Failure recovery
• DDoS multi-­‐stage flow marking
• …
CHALLENGE:
• IDS/DPI
• TCP flow processing
• Monitoring • …
Need new «actions»
Need extra logic (full XFSM)
All (!) otherwise not possible without explicit controller’s involvement
Custom implementation in the controller using the OpenState extension of OF1.3
A. Capone: ECOOP -­‐ NetPL 2 015
31
SDN languages for applications
• Example: Frenetic/Pyretic
Policy
Reconf.
Network
Policy
Policy
Dynamic
Adaptation
Policy enforcement
Compiler
OF commands
A. Capone: ECOOP -­‐ NetPL 2 015
Queries
Network
Status
Notifications
32
Open question
• How can we use a stateful dataplane in programming languages for SDN?
• Easy solutions: create a library of switch state machines to be used as functions in the language
• Can we automatically discover local state machines in a network policy and instantiate them (compiler)?
• Is it a parallelization problem of a global state machine with local and global states and events?
• How much of this parallelization problem should be exposed to the programmer?
A. Capone: ECOOP -­‐ NetPL 2 015
33
Thanks
Antonio Capone Email: [email protected]
OpenState: openstate-­‐sdn.org
EU project BEBA – http://www.beba-­‐project.eu
Extended slide-­‐set is available on OpenState web site!
A. Capone: ECOOP -­‐ NetPL 2 015
34
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement