1. A Programming Model and VM Architecture for Next-Generation Programmable Routers Mel Tsai mtsai@eecs.berkeley.edu

2. 2 Outline The Problem Project Goals VM Architecture Description Generalized Packet Filters Programming and Mapping the VM A Linux Implementation Summary

3. 3 The Problem Application-level processing being pushed into programmable routers and appliances Hardware supports wire-speed packet classification, computation, and state management on thousands/millions of flows Vendors use a wide range of hardware architectures to implement their products  No high-level framework for developing network applications for programmable routers  Developed applications are highly architecture-dependent

4. 4 Project Goals A flexible, high-level environment for implementing and testing network applications Approach does not ignore baseline router functionality! (L2-L4 routing/filtering, VLANs, control-plane protocols, etc.) Virtualized architecture: Applications can be easily simulated before deployment Applications are portable across different architectures, from PCs to multi-gigabit programmable routers Applications and standard routing functions are managed through a CLI The network admin should not have to modify code!

5. 5 A Virtual Machine Architecture

6. 6 Generalized Packet Filters GPFs are the key to flexibility in this approach Extends concept of “filters” normally found on routers A relatively small number of GPFs can be used as building blocks for a large number of apps Ideally, the database of GPFs precludes the writing of new code! Supports flexible classification, computation, and actions GPFs are executed in numeric order L2 Switching Engine w/ARP L2 Switching Engine w/ARP Packet filter 1 Packet filter 2 Packet filter n Default filter Filter 2: name: Std Filter Example mac_s49-3E-2F-33-4A mac_d49-3E-AA-BB-CC srcIP10.x.x.x dstIP128.x.x.x tcp_s33-110 tcp_d33-110 actiondrop

7. 7 GPF Example Simple Traffic Shaper Filter 5: type:generic_counter name: Packet Monitor A srcIP10.x.x.x dstIP128.x.x.x statemodel:private threshold:1000 action1:tag:count = count action2:if threshold, signal CPU1 count action3:if threshold, count = 0 L2 Switching Engine w/ARP L2 Switching Engine Packet Monitor A Default filter Rate Monitor Filter 7: type:rate_monitor name: Rate Monitor srcIPx.x.x.x dstIPx.x.x.x statemodel:private action1:after 0.01 seconds if tag:count > oldcount then signal CPU2 “Rate Monitor” action2:after 0.01 seconds oldcount = tag:count Backplane CPU1 CPU2 L2 Switching Engine w/ARP L2 Switching Engine Packet Monitor B Default filter Rate Monitor

8. 8 Computation with GPFs Cannot put high-latency, complex computation in the fast path Needs to be decoupled to prevent head-of-line blocking How to implement? Simplest way is to include a filter that redirects to a computation engine Similar to Alteon-iSD operation VM model includes the notion of shared and private compute engines L2 Switching Engine w/ARP L2 Switching Engine w/ARP Packet filter 1 Packet filter 2 Packet filter n Default filter Compute Engine

9. 9 Some proposed types of GPFs NAT/basic firewall Traffic shaping and monitoring QoS and packet schedulers Router/server health monitoring Load balancers Encryption/compression engines Content caches Overlay support, DHTs, application-level multicast Storage/iSCSI PNE inter-communication Intrusion detection

10. 10 Programming the VM Start the CLI Define VM parameters # of ports, compute resource characteristics, etc. Configure standard routing functions (MAC/IP tables, OSPF, VLAN port membership, etc.) Instantiate and configure GPFs “Apply” GPFs to desired ports Simulate and test design! Router:/config/vlan/4/ip/create 10.10.140.1/24 Router:/config/vlan/4/ports/add 0-15 Router:/config/vlan/5/ip/create 192.168.2.1/24 Router:/config/vlan/5/ports/add 16-31 Router:/config/gpfs/1/type standard Router:/config/gpfs/1/destination 10.0.0.1/32 Router:/config/gpfs/1/action drop Router:/config/gpfs/1/apply 2,3,6,16-31

11. 11 Mapping the VM to Hardware Mapping is simplified because the VM architecture “looks” like a real router GPFs and other VM components are inherently parallel; serial implementations in C++/Java/Click/etc. require significant effort to parallelize and map to hardware Programmer can direct the mapping process by annotating VM components with their real-world hardware counterparts “Mapping” is basically the process of implementing and exporting all VM components on the target hardware

12. 12 A Linux Implementation A proof-of-concept multithreaded linux implementation of the VM architecture Written in C++ Uses libpcap to tie VM ports to physical ethernet ports on linux machine (Routing performance is not a primary goal) Supports dynamic reassignment of GPFs to threads when router is reconfigured through the CLI Can be used in places where MIT’s Click is currently suitable New GPFs are easily written in C++ for custom use

13. 13 Summary A high-level abstracted way to write network applications for programmable router architectures Applications are constructed by configuring and using GPFs as building blocks A relatively small number of GPFs can implement a large number of interesting applications General computation is supported by the concept of compute engines By design, VM architecture is portable to most hardware