The RouterVM Architecture: Motivation and Principles

1
The RouterVM Architecture Motivation and
Principles

• Mel Tsai
• mtsai_at_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-dependen
  t 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-independen
  t, 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
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 (dip128.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 dont exist)
• Supports undo
• Although RouterVM has larger scope, it can be
  used in places where MITs 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.)

• RouterVMs 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
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 Nortels 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.