The RouterVM Architecture: Motivation and Principles

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

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. 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. 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. Project Goals • Design a high-level environment for writing multiple, coexisting network applications for deployment on a single programmable router • Be able to write powerful applications quickly, yet without writing new code/firmware • The environment should have out-of-the-box functionality as an edge router (e.g. IP routing, switching, VLANs, QoS) • 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 • Network applications should be hardware-independent, while still effectively utilizing the unique hardware provided by the device

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. 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 backplane shuttles packets between line cards A virtual line card is instantiated for every port required by the application A control CPU handles routing protocols and management tasks Blue components are “standard” and are instantiated by default. Yellow components are added and configured on a per-application basis When required, compute engines perform complex, high-latency processing on flows Filters are the key to the flexibility of RouterVM

8. Packet Packet Packet Default filter 1 filter 2 filter filter n L2 Switching L2 Switching Engine w/ARP Engine w/ARP 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:

9. Example: P2P bandwidth throttle

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

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. 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. Packet Packet Packet Default filter 1 filter 2 filter filter n L2 Switching L2 Switching Engine w/ARP Engine w/ARP 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 Compute Engine

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