The RouterVM Architecture: Motivation and Principles

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

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. 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. 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. 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. 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. 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 • New and existing applications can be written by network administrators, not application engineers • Management of applications and standard routing functions should be intuitive. The environment should maximize flexibility and minimize configuration errors through detection and learning • Network applications should be hardware-independent, while still effectively utilizing the unique hardware provided by the device

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

10. 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 • Ideally, the database of GPFs precludes the writing of new code! • Supports flexible classification, computation, and actions • GPFs are executed in numeric order:

11. Example: P2P bandwidth throttle

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

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

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.