1 / 20

The RouterVM Architecture: Motivation and Principles

The RouterVM Architecture: Motivation and Principles. Mel Tsai mtsai@eecs.berkeley.edu. Outline. Motivation: The Changing Landscape of Routers Project Goals The RouterVM Architecture Generalized Packet Filters GPF considerations Programming with RouterVM RouterVM for Linux Summary.

dane-porter
Download Presentation

The RouterVM Architecture: Motivation and Principles

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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.

More Related