Transcript Document

The RouterVM Architecture:
Motivation and Principles
Mel Tsai
[email protected]
Outline
Motivation: The Changing Landscape of Routers
Project Goals
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 wirespeed 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, 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.
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
Project Goals
1.
Design a high-level environment for writing multiple, coexisting
network applications for deployment on a single programmable
router
2.
Be able to write powerful applications quickly, yet without writing
new code
3.
New and existing applications can be written by network
administrators, not application engineers
4.
Management of applications and standard routing functions should
be intuitive. The environment should maximize flexibility and
minimize configuration errors through detection and learning
5.
Network applications should be hardware-independent, while still
effectively utilizing the unique hardware provided by the device
7
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
8
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, highlatency
processing on
flows
9
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
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:
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”
13
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:
eth0
ARM9
SDRAM
ARM9
SRAM
MAC
eth1
14
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
15
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
16
Backup
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
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
Packet
filter 1
Packet
filter 2
Packet
filtern
Default
filter
L2
L2Switching
Switching
Engine
Enginew/ARP
w/ARP
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 welldefined framework for implementing any new functionality. Similarly,
Java programmers write applications for the JVM, not for a PC.
20