Transaction Processing, Functional Applications & Integration
Functional approach to packet processing
-
Upload
nicola-bonelli -
Category
Software
-
view
547 -
download
1
description
Transcript of Functional approach to packet processing
A purely functional approach to packet processing
Nicola Bonelli
Nicola Bonelli, Stefano Giordano, Gregorio Procissi University of Pisa
Luca Abeni University of Trento
2
Facts on Linux ● Linux is a general purpose operating system often used
to create middleboxes o large amount of open source software o a feature-rich subsystem of networking
● The kernel provides o network stack supports a large amount of protocols o traffic control (tc), firewall (netfilter) o routing (iproute2), bridging o monitoring facilities (AF_PACKET and BPF filters)
● Open-source kernel modules o PF_RING-DNA / Netmap (accelerated drivers) o PFQ framework for multi-core architectures
3
Motivation ● What’s wrong with Linux as a middlebox?
o Components are designed to be configurable ! programmability is not fully addressed
● only low level libraries enable tools to communicate to the kernel
o Interoperability among heterogeneous components? ! components are statically linked to each other ! what about bridging packets that satisfy a given BPF ?
o With no virtual machines, the configuration is system-wide ! Multiple applications can concurrently manage the networking for different
purposes?
4
Objective ● Design a new language for programmable middleboxes
that: o at high level enables reusability and interoperability among kernel components
! interfaces, kernel and sockets are end-points o is multi-thread oriented by design
! allows concurrent execution of networking applications o as much close as possible to NICs
● But where to implement it? o Use PFQ as underlying architecture
5
Why PFQ? ● Multi-language framework
o C, C++11-14, Haskell o compliant with a plethora of device drivers o line-speed with Intel vanilla drivers (14.8Mpps)
● Flexible parallelism o decouple software from hardware parallelism
● Address multi-core architectures o scale almost linearly in any possible configuration
● Best practices of concurrent programming o no mutexes, no spinlocks in fast data-path o amortized atomic operations
6
PFQ/lang overview ● PFQ/lang as a functional language
! DLS describing networking application as a sequence of elementary operations (functions)
! simple firewall, bridge, load balancer, etc. ! early stage of monitoring applications (dispatcher)
● A PFQ/lang program consists of a functional composition o takes a packet and return a packet enriched with a context
! information about the distribution (Fanout) ! state, annotation (State) etc. ! possible side effect (IO)
7
PFQ/lang features ● strongly typed language ● high-order functions
o functions that take functions as argument (i.e. conditional expressions) ● currying
o Used to bind arguments in user-space " string, vectors, trivially copyable objects in C++ " storable types, storable tuples, list in Haskell
● immutability of data o COW (copy-on-write)
● deterministic garbage collector (GC) o Value semantic with no impact on performance
8
PFQ/lang principles ● PFQ/lang computations are defined in user-space
o C++11/Haskell eDSL ● AST is transferred to kernel module for a group of
endpoints o runtime strict type-checking (to avoid kernel panic)
● Converted into an executable data structure by a runtime linker o structure with data and pointers to functions
● … and executed on top of network device drivers
9
PFQ/lang current state ● In-kernel functions are implemented in C language
o reusability of Linux kernel functions o about a hundred of functions ready to use o functional library eases the implementation
● The runtime linker is extensible o users can add custom functions and make them available
in the DLS
● What is missing... o grammar parser for computations from text o PFQ/lang native compiler
10
PFQ/lang theory (in short) ● Fanout, State and IO can be seen as mathematical abstractions
called monads (category theory) ● Monads are data structures that represent computations
o extend pure functions with side effect ● PFQ/Lang elementary operations are monadic functions
o Action: fanout monad, IO monad and state monad.
● Functional composition of monadic functions with the Kleisli operator
11
Monads: fanout and state ● Fanout monad is designed to model packet dispatching
o fanout values can be: Drop, Pass, Broadcast, Steer, Deliver and Dispatch
Drop => drop the packet Pass => pass this packet to the next function Broadcast => broadcast this packet to all the endpoints of this group Deliver => send the packet to the endpoints of the given class Steer => send the packet to an endpoint by means of a hash (random) Dispatch => combination of Deliver + Steer
● State monad is designed to model a mutable state o the state is associated with the computation
simple state, used to mark packets o persistent state assiciated with flows
12
IO monad ● IO monad (+GC) is used to implement packet
forwarding o lazy implementation
carried out after the computation is evaluated
● Lazy means faster! o A shallow copy per packet forwarding o The last forward can be done without the copy o A posteriori with lazy forwarding we can save
the last skb_clone
13
PFQ/lang simple functions ● Simple functions are divided into the following categories:
o predicates: ! is_ip, is_udp, is_tcp, is_icmp, is_ip6, is_udp6, is_tcp6, is_flow,
is_frag, is_first_frag, is_more_frag, has_port, has_src_port, has_dst_port, has_vlan, has_vid, bloom etc...
o combinators: ! ||, &&, ^^ (binary), not (unary)
o properties: ! ip_tos, ip_tot_len, ip_id, ip_frag, ip_ttl, tcp_src, tcp_dst,
tcp_hdrlen, udp_src, udp_dst, udp_len, icmp_type, icmp_code...
o comparators: ! >, >=, <, <=, ==, /=, any_bit, all_bit
14
PFQ/lang monadic functions ● Monadic functions are divided into the following categories:
o filters: ! ip, ip6, udp, tcp, udp6, tcp6, icmp, icmp6, flow, rtp, no_frag,
no_more_frag, vlan_filter, bloom_filter, etc.
o steering functions: ! steer_link, steer_vlan, steer_ip, steer_ip6, steer_flow, steer_rtp,
steer_net, steer_field
o conditionals: ! when, unless, conditional
o others: ! kernel, forward, bridge, tee, tap, inv, par, log_msg,
log_packet,etc.
15
PFQ/lang example Haskell: comp = ip >-‐> forward "eth1" >-‐> log_msg "IP packet" >-‐>
addr "192.168.0.0" 16 >-‐> (when’ is_icmp log_packet) >-‐> kernel
C++11: auto comp = ip >> forward ("eth1") >> log_msg ("IP packet") >>
addr ("192.168.0.0",16) >> when(is_icmp, log_packet) >> kernel;
16
PFQ/lang use cases Port mirroring
forward "eth1" >-‐> kernel
Smart Bridging (when is_udp (forward "eth1")) >-‐> kernel
tap "eth2" is_rtp >-‐> kernel
Load Balancer steer_flow
ip >-‐> steer_link
17
PFQ/lang use cases Stateless Firewall
(when has_port 22 && !address("131.114.0.0", 16) drop) >-‐> kernel
when (bloom 16 ["192.168.0.1", "192.168.0.2" ...]) kernel
Monitoring (early stage application)
conditional is_rtp (class 0 >-‐> steer_flow) class 1
18
Performance Speed test: 10Gb link, 64B packets, Xeon 6 cores x5650 (Nehalem) @2.67Ghz, 16G Ram + Intel
82599 10G (Debian Wheezy)
19
Performance Conditional: (when is_tcp steer_flow) bridge: tap is_udp “eth2”
20
Performance speed test: comparisons of different computations
21
PFQ wiki and download
http://www.pfq.io
https://github.com/pfq/PFQ/wiki