Mel Tsai mtsai@eecs.berkeley

1. RouterVMA High-Level Programming Model and Virtual Machine Architecture for Next-Generation Programmable Routers Mel Tsai mtsai@eecs.berkeley.edu

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

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

4. Server Load Balancer Content Cache Switch Switch Switch Switch IP Storage Gateway Switch Intrusion Detection Firewall / VPN LinkCompressor New Requirements in the Enterprise 200 Mbps 1 Gbps 1 Gbps SAN 1 Gbps 1 Gbps 1 Gbps 2.5 Gbps 1 Gbps 1 Gbps ClientWorkstations Server Blades 2.5 - 10 Gbps Offsite 1-2.5 Gbps ISP Edge Router 40 Mbps

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

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

7. FILTER 19 SETUP NAME - SIP - SMASK - DIP - DMASK - PROTO - SRC PORT - DST PORT - VLAN - ACTION - example any 255.255.255.255 10.0.0.0 255.255.255.0 tcp,udp any 80 default drop ClassificationParameters Action to bePerformed Generalized Packet Filters (1) • GPFs are based on filters found in commercial routers Packet Packet Packet Default filter 1 filter 2 filter filter n 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! …simple and easy to use, but not very powerful

8. Ethernet Forward TCP/IP lookup IP Drop Intrusion Detect TCP Route NAT HTTP Load Balance Store/Ret. State iSCSI Replace Fields Error Detect FCIP Resize Pkt Checksum MPLS Encrypt Count/Tag ATM Compress …? …? …? Generalized Packet Filters (2) • Key observation: the operation of packet filters can generalize to the following fundamental steps: Infer based on past observations ClassificationParameters Action(s) What if all these options were made available in a packet filter?

9. Generalized Packet Filters (3) 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 • 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

10. GPF Example A Server Load Balancer and L7 Traffic Detector Control Processor Servers Ext. IP = 24.0.5.6 GPF 5: SLB GPF 10: P2P … 10.0.0.1 L2 Switching Engine w/ARP QoS Module Backplane IP Router Engine 10.0.0.2 To Clients 10.35.x.x

11. GPF Example A Server Load Balancer and L7 Traffic Detector Control Processor Servers Ext. IP = 24.0.5.6 GPF 5: SLB GPF 10: P2P … 10.0.0.1 L2 Switching Engine w/ARP QoS Module 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” Backplane IP Router Engine 10.0.0.2 To Clients 10.35.x.x

12. GPF Example A Server Load Balancer and L7 Traffic Detector Control Processor Servers Ext. IP = 24.0.5.6 GPF 5: SLB GPF 10: P2P … GPF 10 Setup 10.0.0.1 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 L2 Switching Engine w/ARP QoS Module Backplane IP Router Engine 10.0.0.2 To Clients 10.35.x.x

13. Formalized GPF Model External compute engines External and/or shared state Packet modification, tagging, messagegeneration Classify Infer Packetbuffer Forwardpacket flow To downstream component Scheduler InternalState GPF statistics and status Config info Config info Config info Redirectedpackets

14. Network Address Translate L3Classifier RateLimiter Load Balancer Intrusion Detection L2 Switching Engine w/ARP QoS Module IP Router Engine GPF Execution Sequences Many paths exist for packets… ?

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

16. Network Address Translate L3Classifier RateLimiter Load Balancer Intrusion Detection L2 Switching Engine w/ARP QoS Module IP Router Engine 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 ?

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 -~]*\\|

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

19. Backup

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

21. …No Existing Solution ? unknown or unable to comment partially or maybe yes Management, Configurability, and Deployment Concerns for Future Programmable Appliances Active Networks Genesis Kernel Inkra Networks RouterVM IP Fabrics Pronto NetKit Scout Click NEPAL XORP NetBind Teja Network Processor Support Considers OtherProgrammable Hardware Supports programmability without writing new code ? Library or API based approach ? Considers multiple apps running simultaneously ? ? ? ? Management and usability is a first-class consideration ? Dynamic reconfiguration support ? ? ? ? ? Out-of-the-box edgerouter features ? ? Ideas can be easily deployedinto existing routers today

22. GPF Hardware Execution Model 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 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

23. ASIC ASIC ASIC ASIC MEM MEM MEM MEM CPU1 CPU1 CPU1 CPU1 PHY PHY PHY PHY A Mapping Example “Mapping distance”is minimized due tostructurally-parallelorganization of RouterVM MANAGEMENTCPU SWITCHFABRIC Typical Switch Hardware Configuration 8-port RouterVM Configuration

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?

25. GPF5 GPF3 GPF2 GPF4 GPF1 Line card A Backplane SDRAM Traffic Mangr. < < < < GbE GbE GbE GbE GbE GbE GbE GbE > > > > PHY PHY PHY PHY MAC MAC MAC MAC Ser X- Ser Ser Ser Ch OC-192 NetworkProcessor Bar Des Des Des Des Proc SearchCoproc TCAM Switch Fabric Line card B SDRAM 10/100 Octal MAC NetworkProcessor SRAM Ch Proc SDRAM 10/100 Octal MAC NetworkProcessor SRAM Mapping to NPU Linecards

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

28. Applications Applications Architecture Instance Applications Mapping Performance Analysis Performance Numbers Optimal Mapping to Hardware Use different Mapping strategies Suggest architectural improvements Rewrite the applications The MESCAL Y-chart Source: unknown memberof the Mescal team