1. The RouterVM Architecture: Motivation and Principles Mel Tsai mtsai@eecs.berkeley.edu

2. 2 Outline Motivation: The Changing Landscape of Routers Project Goals The RouterVM Architecture Generalized Packet Filters GPF considerations Programming with RouterVM RouterVM for Linux Summary

3. 3 Changing Landscape of Routers (1) Application-level processing being pushed into routers and network appliances Routers are no longer “dumb…” Hardware can support wire- speed packet classification, computation, and state management on thousands/millions of flows Paradigm shift from servers to routers Implications:  How should designers think about this new, highly-programmable datapath? Examples: At what stage does the computation occur? How to avoid head-of-line blocking during high-latency, complex computation? How “configurable” should the datapath be? How to maintain per-session state and share this across the router?

4. 4 Changing Landscape of Routers (2) Recent trend towards “all-in-one” programmable platforms that can be customized for a variety of applications “Hot” applications: P2P traffic detectors, WAN link compressors, SSL offload, XML preprocessing, server load balancers Implications:  Convergence: customers will soon desire a laundry list of functions in one, easy-to-maintain, easy-to-upgrade box. (Picture a combination router, firewall, IDS/IPS, VoIP gateway, server, VPN, and secure storage array)  Impractical for vendors to write every possible application. Instead, can third-party developers write “plug-and-play” applications for these boxes? If so, a consistent, abstracted view of the any possible hardware will create a market for such plug-ins.

5. 5 Changing Landscape of Routers (3) Vendors use a wide range of hardware architectures to implement their products General-purpose CPUs, hardwired ASICs, FPGAs, programmable network processors Implications:  Development framework is very bottom-up: programmers develop “firmware,” not whole applications. Programmer productivity is low, and application-level problems may be discovered too late  Applications become highly architecture-dependent… Programmers desire a well-defined and consistent view of the underlying hardware resources, yet hardware can change late in the design cycle. Code reuse is challenging.

6. 6 Changing Landscape of Routers (4) Many network reliability and security problems are due to router and server misconfiguration (or bugs that make it through the development phase) Implications:  Can applications be developed and verified in an architecture- independent way?  Once deployed, who maintains and configures an all-in-one network appliance? Desirable to have a user interface that gives network administrators (not just application engineers) the flexibility to implement complex applications, policies, and usage scenarios without writing new code  Can a router become self-maintaining and support features such as “undo”?

7. 7 Project Goals 1. Design a high-level environment for writing multiple, coexisting network applications for deployment on a single programmable router 2. Be able to write powerful applications quickly, yet without writing new code 3. New and existing applications can be written by network administrators, not application engineers 4. Management of applications and standard routing functions should be intuitive. The environment should maximize flexibility and minimize configuration errors through detection and learning 5. Network applications should be hardware-independent, while still effectively utilizing the unique hardware provided by the device

8. 8 RouterVM A flexible, high-level environment for developing and testing network applications Virtualized architecture: Provides a consistent view of the underlying hardware resources of any architecture Applications are portable across different architectures, from PCs to multi-gigabit programmable routers Applications can be easily simulated before deployment Applications, policies, and standard routing functions are managed through a CLI RouterVM implements a basic functional unit (the generalized packet filter) that allows new applications and policies to be implemented and configured through the CLI. Many types of new applications can be implemented without writing new code

9. 9 A Virtual Machine Architecture Virtualized components are representative of a “common” router implementation. Although the VM structure is well-defined, it does not depend on a particular hardware architecture A virtual line card is instantiated for every port required by the application A virtual backplane shuttles packets between line cards A control CPU handles routing protocols and management tasks When required, compute engines perform complex, high- latency processing on flows Blue components are “standard” and are instantiated by default. Yellow components are added and configured on a per-application basis Filters are the key to the flexibility of RouterVM

10. 10 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 applications 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

11. 11 Example: P2P bandwidth throttle

12. 12 Some proposed types of GPFs Traffic shaping and monitoring L7 traffic detection (Kazaa, HTTP, AIM, POP3, etc.) QoS and packet scheduling NAT Intrusion detection Protocol conversion (e.g. IPv6) Content caching Load balancing Router/server health monitoring Storage, Fibre Channel to IP, iSCSI XML preprocessing TCP offload (TOE) Mobile host management, 802.11 Encryption/compression, VPNs Multicast, Overlays, DHTs

13. 13 GPF Considerations Classification criteria is not necessarily stateless Many applications require per-flow state and possibly full TCP stream reassembly Functionality and control flow can be supported with complex actions Simple actions: drop allow Mid-level actions: jump filter 43 bandwidth limit 1k/sec verify checksum Complex actions: Decrypt SSL flow using Engine1 if (dip==128.64.33.0/24) then tag “possible intrusion”

14. 14 From RouterVM to Hardware Mapping is greatly simplified because RouterVM “looks” like a real router “Mapping” == the process of implementing the RouterVM runtime and the GPF library on the desired hardware architecture High startup cost, but worth the effort GPFs and other VM components are structurally parallel Applications written in C++/Java/Click/etc. have no inherent parallelism and require significant effort to parallelize Designers can guide (and possibly automate) the mapping process through VM component annotations:

15. 15 RouterVM for Linux A proof-of-concept multithreaded linux implementation of the VM architecture Written in C++, highly object-oriented Performance is not a primary goal Supports either “simulated” network ports (using packet trace files) or network ports that are bound to real interfaces (e.g. eth0) GPFs can be dynamically reconfigured, installed, or deleted Maintains two sets of data virtually everywhere: one for the runtime, and one that is being edited at the CLI Detects possible configuration errors (such as jumping to filters that don’t exist) Supports “undo” Although RouterVM has larger scope, it can be used in places where MIT’s Click is currently suitable New GPFs are easily written in C++ for custom use

16. 16 Summary RouterVM A high-level, abstracted environment for writing L2-L7 applications for future programmable router architectures GPFs are an elegant way to build interesting router applications Network admins (not firmware engineers) can “program” applications by configuring GPFs Specialized computation is supported by the concept of compute engines and redirection filters RouterVM does not dictate the underlying hardware architecture, but the mapping process is simplified due to its structural parallelism

17. 17 Backup

18. 18 GPF Considerations (cont.) RouterVM’s state model is currently shared memory Easier for VM component implementers to deal with Implications for tables that are shared across GPFs, e.g. in a NAT filter or IPv4-IPv6 gateway If necessary, any hardware that supports message passing can also emulate shared memory How to handle very complex processing in the fast path? Assumption is that the hardware can do it… How should programmers think about complex functionality

19. 19 Computation with GPFs Should not put high-latency, complex computation in the fast path Needs to be decoupled to prevent head-of-line blocking How to implement? One solution: include a filter that redirects to a computation engine Similar to Nortel’s Alteon-iSD operation The underlying architecture and hardware of compute engines is not dictated by RouterVM A primary goal of RouterVM is to be a relatively high-level environment and interface for elegantly specifying L2-L7 applications in routers L2 Switching Engine w/ARP L2 Switching Engine w/ARP Packet filter 1 Packet filter 2 Packet filter n Default filter Compute Engine

20. 20 “Programming” with RouterVM With a handful of GPFs, very interesting functionality can be implemented at the CLI, even by non-programmers A library of GPFs cannot implement every possible application However, RouterVM provides a standardized architecture and a well- defined framework for implementing any new functionality. Similarly, Java programmers write applications for the JVM, not for a PC.