Download
1 / 28
280 likes | 509 Vues
To serve these functions, recent hardware advancements allow application-level ... tag
E N D
Slide 1:RouterVM A High-Level Programming Model and Virtual Machine Architecture for Next-Generation Programmable Routers
Mel Tsai mtsai@eecs.berkeley.edu
Slide 2:Outline
The Changing Landscape of Routers Technical goals of RouterVM The RouterVM Architecture Generalized Packet Filters Properties Formalized Model GPF Examples Property Guarantees through Restrictions Experimental Features
Slide 3:Changing Landscape of Routers
Today we see enhanced network functionality as an enterprise requirement Increased security requirements Managing and prioritizing traffic Balancing load Offloading functionality that is too data intensive for servers To serve these functions, recent hardware advancements allow application-level processing to be incorporated into router-like devices Routers are no longer “dumb…” Hardware can support wire-speed packet classification, computation, and state management on thousands/millions of flows
Slide 4:New Requirements in the Enterprise
ISP Edge Router Server Blades SAN Client Workstations 200 Mbps 2.5 Gbps 1 Gbps 1 Gbps 1 Gbps 1 Gbps 1 Gbps 1 Gbps 1 Gbps 40 Mbps Offsite 1-2.5 Gbps 2.5 - 10 Gbps
Slide 5:New Challenges
How does the vendor seamlessly integrate a large number of applications onto one device? How to present an intuitive, unified management interface that properly hides the complexity of integrating multiple functions while simultaneously minimizing potential for errors? How to achieve end-user flexibility and programmability? Vendors are reluctant to expose interfaces and allow open programmability of devices Can customers implement new functions, collect new statistics, or reconfigure functions in ways for which the device was not intended? More generally, can programmability be achieved through a high-level interface, without requiring customers to write new code? Can the vendor’s development framework and integrated application solution effectively target the underlying programmable hardware? Network processors, ASICs, specialized function units, FPGAs
Slide 6:Technical Goals of RouterVM
Support the “programming” of functionality through a high-level, expressive, and functionally-complete building block called generalized packet filters (GPFs) Show how an integrated management interface for GPFs on programmable hardware has the potential to reduce management complexity and minimize errors To complement a set of standard out-of-the-box edge router functions, implement an example library of GPFs and show that it is representative of network routing and appliance applications Formally and experimentally analyze the properties of the GPFs and the RouterVM execution model to understand its completeness, expressiveness, ease of specification, and other characteristics Through formal analysis and by building prototype implementations, show that GPFs and the execution model can be effectively mapped onto existing and future programmable router hardware
Slide 7:Generalized Packet Filters (1)
GPFs are based on filters found in commercial routers Packet filter 1 Packet filter 2 Packet filter n Default filter …simple and easy to use, but not very powerful Notice how a user configures relatively high-level parameters to specify the filter characteristics. New code and general programmability is not required, because in most cases, users of typical routers and switches don’t need much more flexibility here!
Slide 8:Generalized Packet Filters (2)
Key observation: the operation of packet filters can generalize to the following fundamental steps: Classification Parameters Infer based on past observations Action(s) What if all these options were made available in a packet filter?
Slide 9:Generalized Packet Filters (3)
While maintaining the parameterized and high-level specification interface of a normal packet filter, a GPF also has: A widely expanded set of classification criteria Normal header fields Application-level headers such as URLs Regular Expressions Multiple combinations of the above The ability to maintain information about packet flows E.g., information sharing among GPFs A widely expanded set of actions Allow, drop, load balance, replace fields, encrypt, storage virtualize, NAT, compress, tag The ability to implement arbitrary sequences of control flow among other GPFs NAT, traffic shaping and monitoring L7 traffic detection (Kazaa, HTTP, AIM, POP3, etc.) QoS and packet scheduling Intrusion detection Spam filtering Protocol conversion (e.g. IPv6) Content caching Load balancing Router/server health monitoring Storage, Fibre Channel to IP, iSCSI XML preprocessing TCP offload (TOE) Encryption/compression, VPNs Multicast, Overlays, DHTs
Slide 10:GPF Example
Backplane Control Processor QoS Module L2 Switching Engine w/ARP IP Router Engine GPF 5: SLB GPF 10: P2P … Servers To Clients A Server Load Balancer and L7 Traffic Detector 10.0.0.1 10.0.0.2 Ext. IP = 24.0.5.6 10.35.x.x
Slide 11:GPF Example
Backplane Control Processor QoS Module L2 Switching Engine w/ARP IP Router Engine GPF 5: SLB GPF 10: P2P … Servers To Clients A Server Load Balancer and L7 Traffic Detector 10.0.0.1 10.0.0.2 Ext. IP = 24.0.5.6 GPF 5 Setup name -algorithm - flowid - sip - smask - dip - dmask - proto - action1 - action2 - action3 - Server Load Balancer equal flows sip, sport any any 24.0.5.6 255.255.255.255 udp, tcp slb nat 10.0.0.1, 10.0.0.2 log connections, file = log.txt tag “skip Yahoo Messenger Filter” 10.35.x.x
Slide 12:GPF Example
Backplane Control Processor QoS Module L2 Switching Engine w/ARP IP Router Engine GPF 5: SLB GPF 10: P2P … Servers To Clients A Server Load Balancer and L7 Traffic Detector 10.0.0.1 10.0.0.2 Ext. IP = 24.0.5.6 GPF 10 Setup name - type - pattern - timeout - flowid - sip - smask - dip - dmask - proto - action1 - action2 - Yahoo Messenger Filter yahoomessenger ^(ymsg|ypns|yhoo).?.?.?.?.?.?.?(w|t).*\xc0\x80 10 min sip, dip, sport, dport any any 10.35.0.0 255.255.0.0 tcp limit 1 kbps email root 10.35.x.x
Slide 13:Formalized GPF Model
Forward packet flow Redirected packets Packet buffer Classify Infer Packet modification, tagging, message generation External and/or shared state Internal State To downstream component External compute engines Config info Config info Config info GPF statistics and status Scheduler
Slide 14:GPF Execution Sequences
? Many paths exist for packets…
Slide 15:Performance and Reliability Guarantees through Restrictions
Goal: be able to understand and analyze the formal properties of the RouterVM paradigm Difficult with a fully general framework… Guarantees are more readily achieved by restricting the GPFs functionality and control flow flexibility Examples Explicit declarations of shared tables and strict hardware enforcement of access and consistency Logically or physically restricting packet buffers to one line card? Allow only well-defined and small packet tags that makes only small adjustments to packet control flow I.e. references to shared data structures, extracted fields, QoS priorities
Slide 16:Limits on Control Flow
Allowing only forward jumps eliminates deadlock and livelock Alternative might be implementing an in-router TTL Bonus: achieves the property that multiple packets can be in-flight in the filter chain, but the processing is still analyzable and more-or-less deterministic ?
Slide 17:Limits on Regular Expressions
Complex regular expressions may be intractable on most hardware, and may not even be necessary for most apps Limiting searches to simple/simpler expressions allows you to bound processing time Complex examples: snmp: ^\\x02\\x01\\x04.+([\\xa0-\\xa3]\\x02[\\x01-\\x04].?.?.?.?\\x02\\x01.?\\x02\\x01.?\\x30)|(\\xa4\\x06.+\\x40\\x04.?.?.?.?\\x02\\x01.?\\x02\\x01.?\\x43) Java DirectConnect: \\$mynick[\\x09-\\x0d -~]*\\|\\$lock[\\x09-\\x0d -~]*\\||\\$lock[ \\x09-\\x0d -~]*pk=[\\x09-\\x0d -~]*\\|\\$hubname[\\x09-\\x0d -~]*\\||\\$key[\\x09-\\x0d -~]*\\|\\$validatenick[\\x09- \\x0d -~]*\\|
Slide 18:Experimental Features
More general and user-friendly interface to look-up tables and databases Examples: Access to an email white list for a GPF-based spam filter List of “cachable” pages in a content cache “Define your own” classification field A typedef for GPF classification fields? Conditional actions, conditional classification fields Conditional execution of one or more actions (potentially AND’ed / OR’ed together) based on classification results “Switch” actions: A variety of actions can be performed based on a certain field, but you don’t need to write a filter for each case Also gives you a “default” action when nothing matches
Slide 19:Backup
Slide 20:Management Concerns
Separate appliances create a management headache… If an organization uses 10 appliances, then Network admins must learn 10 interfaces Expensive rack space is consumed by 10 devices Software updates come from 10 sources under 10 service contracts Pinpointing failures involves 10 devices Changing the network topology involves reorganization of 10 devices Separate appliances do not communicate or share information Because the applications are often similar, they duplicate work waste resources, and can interact with undesirable results E.g., firewall is accidentally configured to block “good” traffic that is destined to a load balancer SNMP-based management approaches (e.g. HP OpenView) may not be enough Still has the problem of duplicate resources Cannot always trust vendor interoperability Hardware does not have consistent capabilities, e.g. ability to report statistics and status
Slide 21:…No Existing Solution
Network Processor Support Supports programmability without writing new code Considers Other Programmable Hardware Considers multiple apps running simultaneously Management and usability is a first-class consideration Dynamic reconfiguration support Out-of-the-box edge router features Ideas can be easily deployed into existing routers today NetBind Click Scout NEPAL Library or API based approach Teja IP Fabrics Active Networks Genesis Kernel NetKit Inkra Networks RouterVM XORP Pronto partially or maybe yes unknown or unable to comment ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Management, Configurability, and Deployment Concerns for Future Programmable Appliances
Slide 22:GPF Hardware Execution Model
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. GPFs are configured and installed on a per-application basis
Slide 23:A Mapping Example
SWITCH FABRIC MANAGEMENT CPU 8-port RouterVM Configuration Typical Switch Hardware Configuration “Mapping distance” is minimized due to structurally-parallel organization of RouterVM
Slide 24:Limited Hardware Resources
Hardware is not infinitely fast with infinite resources; it is generally limited in the following ways: Number and type of computational units Available parallelism (separate CPUs, hardware threads, SIMD, VLIW, etc.) Special-purpose engines (search coprocessors, table lookup, hash units) Communication bandwidth (between computation units, between units and memory, between memory and I/O) Memory (SRAM, SDRAM, local registers, cache) Memory controllers (SDRAM controllers, DMA) Certain GPFs, and even configurations of GPFs, may not effectively map to certain hardware at the required performance Future work is to determine where the overheads are, how to determine whether performance can meet hardware abilities, etc. Open question: when and how does RouterVM inform the user when performance cannot be met? By what mechanism does it determine this?
Slide 25:Mapping to NPU Linecards
Slide 26:Enriched Features through Packet Tagging
Tags are an interesting way to enhance the functionality of GPFs Tags can contain extracted link layer, IPv4, TCP, iSCSI, or HTTP fields A different way of transferring state… Useful e.g. when hardware filters perform extraction, while software-only filters use it downstream Tags can be mini-instructions that affect control flow: “This packet is special, ignore downstream filters of type {X, Y, and Z}” “This packet is low-priority, downstream filters can drop this if resources are low” “Ignore this packet’s L2 header and route only based on its IP header” Tags can contain application-specific data such: Useful statistics SCSI block numbers in IP storage Flags for an out-of-order stream Symbolic references to downstream router resources
Slide 28:Optimal Mapping to Hardware
Suggest architectural improvements Rewrite the applications Use different Mapping strategies The MESCAL Y-chart Source: unknown member of the Mescal team
