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

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

3. 3 Changing Landscape of Routers 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 How should designers think about this new, highly- programmable datapath? Trend towards “commodity” 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 What if these devices converged into one box?

4. 4 Changing Landscape of Routers (cont) Many network reliability and security problems are due to router and server misconfiguration (or bugs that make it through the development phase) Can applications be developed and verified in an architecture-independent way? Can a network admin (not just application engineers) maintain the highly programmable box? Vendors use a wide range of hardware architectures to implement their products General-purpose CPUs, hardwired ASICs, FPGAs, programmable network processors 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

5. 5 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/firmware 3. The environment should have out-of-the-box functionality as an edge router (e.g. IP routing, switching, VLANs, QoS) 4. Management of applications and standard routing functions should be intuitive. The environment should maximize flexibility and productivity, while 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

6. 6 RouterVM (Router Virtual Machine) A flexible, high-level environment for developing and testing network applications RouterVM is a virtual machine runtime that abstracts the details of the underlying programmable network hardware Provides a consistent view of the hardware resources of any architecture Like Java, applications (RouterVM configurations) are portable across different architectures, from PCs to multi-gigabit programmable routers Applications can be easily simulated before deployment Applications and standard routing functions are managed through a flexible CLI RouterVM implements a basic functional unit (the generalized packet filter, or GPF) that allows new applications and functions to be implemented and configured through the CLI With a small library of GPFs ported to a programmable architecture, most new functionality can be implemented without writing new code

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

8. 8 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 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

9. 9 Example: P2P bandwidth throttle

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

11. 11 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 a lot gained 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:

12. 12 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 many types of configuration errors (e.g. 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

13. 13 Evaluation Criteria Flexibility How to quantify? A development environment is not “flexible” merely because you can revert to programming in C++ Ease of use Which applications can be quickly implemented, and which are infeasible or impractical? Metric for “programmer productivity”? To what extent does the CLI ease or hinder the user? Performance Some apps may be limited by hardware, but not RouterVM. How to detect this? Robustness Should non-cooperating GPFs be sandboxed? How? Ability to target many types of hardware Fundamental ability to minimize configuration errors

14. 14 Future Work Continue to flesh-out the Linux prototype, improve the command line interface Add more edge-router functions Port RouterVM to new hardware Network processor based router? Develop new GPFs Better understand the uses of tagging New thoughts on ways to evaluate

15. 15 Backup

16. 16 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”

17. 17 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

18. 18 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

19. 19 “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.

20. 20 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