Transcript Document

The RouterVM Architecture:
Motivation and Principles
Mel Tsai
[email protected]
Outline








Motivation: The Changing Landscape of Routers
The Goals of RouterVM
The RouterVM Architecture
Generalized Packet Filters
GPF considerations
Programming with RouterVM
RouterVM for Linux
Summary
2
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?
3
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, VoIP gateway, server, 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.
4
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.
5
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 architectureindependent 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”?
6
Proposal: RouterVM


RouterVM: A flexible, high-level platform 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 multigigabit 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
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
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
A control CPU
handles routing
protocols and
management tasks
When required,
compute engines
perform complex,
high-latency
processing on
flows
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

Ideally, the database of GPFs precludes the writing of new code!

Supports flexible classification, computation, and actions

GPFs are executed in numeric order:
Packet
filter 1
Packet
filter 2
Packet
filter n
Default
filter
L2
L2Switching
Switching
Engine
Enginew/ARP
w/ARP
9
Example: A standard GPF
10
Example: P2P bandwidth throttle
11
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
12
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:



Mid-level actions:




drop
allow
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”
13
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
14
Computation with GPFs

Should not put high-latency, complex computation in the fast path


How to implement? One solution: include a filter that redirects to a
computation engine


Needs to be decoupled to prevent head-of-line blocking
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
Packet
filter 1
Packet
filter 2
Packet
filtern
Default
filter
L2
L2Switching
Switching
Engine
Enginew/ARP
w/ARP
15
“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.
16
From RouterVM to Hardware

Mapping is simplified because RouterVM “looks” like a real router

Mapping becomes the process of implementing the RouterVM runtime
and the GPF library on the desired hardware architecture


GPFs and other VM components are structurally parallel


Potentially high startup cost, but worth the effort
Applications written in C++/Java/Click/etc. have no inherent parallelism
and require significant effort to parallelize and map to hardware
Designers can guide (and possibly automate) the mapping process
through VM component annotations:
eth0
ARM9
SDRAM
ARM9
SRAM
MAC
eth1
17
RouterVM for Linux

A proof-of-concept multithreaded linux implementation of the VM
architecture

Written in C++, highly object-oriented



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




Performance is not a primary goal
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”
Can be used in places where MIT’s Click is currently suitable

New GPFs are easily written in C++ for custom use
18
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
19