OASIS: Enabling Services with Programmable Networks

1. George Porter Mel Tsai Li Yin Randy Katz OASIS: Enabling Services with Programmable Networks

2. Outline • Overview • Introduction to PNEs • Motivation: PNEs and Network Appliances • Research Opportunities • Understanding Applications for PNEs • Programming PNEs • Our Current Testbed • Experimental Plan • Q&A with Audience

3. Overview • This presentation is a brief summary of our whitepaper, • “The OASIS Group at U.C. Berkeley: Research Summary and Future Directions” • Sahara is focused on services in the network… • The goal of OASIS is to enable new services using programmable networks

4. Introduction • A programmable network element (PNE) is a router that can perform flexible, complex, and application-level computation on packets in the fast path Basic PNE Functionality OutputPackets InputPackets Infer Classify Act State Info

5. 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 …? …? …? Classify-Infer-Act • A server and router in “one” • Tight integration between packet processing and routing • High bandwidth (routers) and computation (servers) Infer Classify Act

6. PNEs: The Big Picture • PNEs are a new technology and present many new opportunities • We’re not exactly sure how they will be deployed, or what they are useful for! • Nonetheless, the hardware cost is small and thus adding network programmability is basically free

7. F5 Networks BIG-IP LoadBalancer Web server load balancer Network Appliance NetCache Localized content delivery platform Packeteer PacketShaper Traffic monitor and shaper Cisco SN 5420 IP-SAN storage gateway Ingrian i225 SSL offload appliance Nortel Alteon Switched Firewall CheckPoint firewall and L7 switch Cisco IDS 4250-XL Intrusion detection system NetScreen 500 Firewall and VPN Extreme Networks SummitPx1 L2-L7 application switch Network Appliances The increasing push towards in-the-networkprocessing

8. Motivation for PNEs • Network appliances are generally fixed-function devices • PNEs can consolidate functionality to reduce management costs and rack space • PNEs can be reconfigured to support new applications Firewall IP Storage Gateway IntrusionDetector ??? Server Load Balancer

9. Motivation for PNEs (cont.) • PNEs offer the flexibility required to implement distributed applications by composition

10. PNE Hardware • PNEs are enabled by silicon and technology advances • Processor arrays, network processors, configurable hardware (e.g., FPGAs), specialized memories, custom ASIC accelerators, fast and cheap storage • Fast-path computational power: • A modest PNE comprising an array of sixteen generic 1 GHz processors can theoretically sustain nearly 32,000 instructions per packet at 1 Gbit/sec (assuming 256-byte packets on average) • Network processors and custom hardware can vastly improve this • The bottleneck: memory bandwidth and state retrieval

11. State retrieval and management • (insert picture showing a computation element wishing to make a decision based on a large amount of previously recorded data) • (insert picture showing shared, frequently updated, frequently accessed resource) • (insert picture showing packet reordering and head-of-line blocking)

12. PNE Placement • Where will PNEs reside in the network? We can see applications for virtually anywhere… Access Edge Core Access Edge The data rate affects the achievable complexity of PNE applications

13. Research Opportunities in PNEs • What makes an application suitable for PNEs? What are their characteristics? • What about overlays? • What is the ideal programming model for a PNE? A network of PNEs? • How do you efficiently handle local and distributed state? (Is this a hardware issue, a software issue, or both?) • How do you quantify a PNE’s flexibility and reliability?

14. Applications Suitable for PNEs • Proposed properties of an application can benefit from the programmability and flexibility of a PNE when: • the filtering or computation accesses nearly every bit in every packet • The data rates overload a server architecture and computational tasks overload a router • the application is not fully general-purpose • At least some part of the application has a classify-infer-act structure • the application has geographically distributed state that must be quickly aggregated • a non-trivial conversion between protocols is required • past occurrences affect future filtering and computations on flows • the application changes over time

15. Programming PNEs • A good programming model is critical for writing highly reliable and flexible applications • PNEs require a good programming model for both a single-PNE and an ensemble of PNEs • Our basic single-PNE approach: create a router virtual machine and program the machine. Apps can then be portable and platform-independent • Basic primitive: the generalized packet filter • Highly flexible and powerful operator • Uses “packet tags” to distribute state and implement control-flow between virtual machine components

16. Virtual Machine Example common configuration exported VM interface PNE hardware

17. Our Current Testbed

18. Experimental Plan • Expand our testbed! • Measurement and monitoring: a key function of PNEs • In progress: prototype of the single-PNE programming model on Linux • Experiment with apps that require distributed state • One possible test application: cooperative SAN-to-SAN cache

19. Overall Research Impact • Applications will be more reliable and efficient by taking advantage of new network services • Per-flow and per-packet level processing and state management will power new forms of measurement, monitoring, and actuation • New understanding for how to manage state and processing in distributed, programmable networks

20. Audience Q&A (1) • What are the key applications for programmable networks and PNEs? • What new apps could make use of the technology?

21. Audience Q&A (2) • What makes an application ammenable to implementation in programmable networks? What parts run at the endpoints, and what parts in the network? • Network appliances and proxy applications have enjoyed recent success. “Build it and they will come”? • Is it something about the frequency of processing? Stateful processing? • the filtering or computation accesses nearly every bit in every packet • the application is not fully general-purpose • the application has geographically distributed state that must be quickly aggregated • a non-trivial conversion between protocols is required • past occurrences affect future filtering and computations on flows • the application changes over time

22. Audience Q&A (3) • What are the important security and trust issues in programmable networks? • Remember, we are not advocating open, “instruction in every packet” systems ala active networks of a few years ago • Can a network of PNEs be shared between (potentially competing) organizations?

23. Audience Q&A (4) • What is the best way to configure and manage an ensemble of PNEs? • What are the most important issues in terms of reliability? (E.g., graphically visualizing a configuration?)