Embed Size (px)
Citation preview
2
OutlineMotivation: The Changing Landscape of RoutersProject GoalsThe RouterVM ArchitectureGeneralized Packet FiltersGPF considerationsProgramming with RouterVMRouterVM for LinuxSummary
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 flowsParadigm 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 Goals1. 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
8
RouterVMA 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
QoS ModuleQoS ModuleL2 Switching
Engine w/ ARP
L2 SwitchingEngine w/ ARP
IP Router Engine
IP Router Engine
ControlProcessor
ControlProcessor
Packet filter 1
Packet filter 2
Packet filter n
Default filter
EthernetPort
QoS ModuleQoS Module
Backp
laneBackp
lane
L2 SwitchingEngine w/ ARP
L2 SwitchingEngine w/ ARP
IP Router Engine
IP Router Engine
Packet filter 1
Packet filter 2
Packet filter n
Default filter
EthernetPort
ComputeEngine
ComputeEngine
ComputeEngine
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 line card is instantiated for every
port required by the application
A virtual backplane shuttles packets between line cards
A control CPU handles routing protocols and management tasks
When required, compute engines perform complex, high-latency processing on flows
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
10
Generalized Packet FiltersGPFs are the key to flexibility in this approach
Extends concept of “filters” normally found on routersA 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:
L2 SwitchingEngine w/ARPL2 SwitchingEngine w/ARP
Packet filter 1
Packet filter 2
Packet filter n
Default filter
11
Example: P2P bandwidth throttle
12
Some proposed types of GPFs
Traffic shaping and monitoringL7 traffic detection (Kazaa, HTTP, AIM, POP3, etc.)QoS and packet schedulingNATIntrusion detectionProtocol conversion (e.g. IPv6)Content cachingLoad balancingRouter/server health monitoringStorage, Fibre Channel to IP, iSCSIXML preprocessingTCP offload (TOE)Mobile host management, 802.11Encryption/compression, VPNsMulticast, Overlays, DHTs
13
GPF ConsiderationsClassification 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: dropallow
Mid-level actions: jump filter 43bandwidth limit 1k/secverify checksum
Complex actions:Decrypt SSL flow using Engine1if (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 parallelApplications 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 LinuxA proof-of-concept multithreaded linux implementation of the VM architecture
Written in C++, highly object-orientedPerformance 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 deletedMaintains two sets of data virtually everywhere: one for the runtime, and one that is being edited at the CLIDetects 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
SummaryRouterVM
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 memoryEasier for VM component implementers to deal withImplications for tables that are shared across GPFs, e.g. in a NAT filter or IPv4-IPv6 gatewayIf 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 GPFsShould 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
L2 SwitchingEngine w/ARPL2 SwitchingEngine w/ARP
Packet filter 1
Packet filter 2
Packet filter n
Default filter
Compute Engine
20
“Programming” with RouterVM
With a handful of GPFs, very interesting functionality can be implemented at the CLI, even by non-programmersA 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.
