A High-Level Framework for Network Application Design Mel Tsai mtsai@eecs.berkeley 12/5/2002

1. A High-Level Framework for Network Application Design Mel Tsai mtsai@eecs.berkeley.edu 12/5/2002 EE249 Final Project Presentation

2. Outline • Motivation: modular routers • Real-world routers & applications • The problem: a productivity mismatch • A solution: a high-level framework for router application design • The generalized packet filter concept • Results and status • Conclusion

3. Background

4. Modular Routers • Goal • Provide a software framework to quickly design & test any network protocol, service, or algorithm running on a server, network appliance, or router • Existing Systems • MIT’s ClickModular Router • Washington University’s Router Plugins • VERA

5. Network Application Space Access Edge Core VPNs LAN Switches & Routers Wireless Devices FDDI WAN Circuit Switches WAN Bridges Mobile IP GbE, 10/100 Ethernet 802.11 Error Control Error Correction Token Ring QoS xDSL ISDN High-Speed Backbone Routers MPLS IP over ATM Edge Terminators WAN Packet Routers DCS over ATM Firewalls NICs X.25, SDMS NAT Modems ATM Encryption Inverse Multiplexers Frame Relay MPLS IP IP xDSL Cable X over WDM QoS Servers MPLS ATM ISDN Frame Relay ATM X over SONET PBX Devices IP Analog Network Management & Accounting Frame Relay Remote Access SSL Accelerators IAD / Telephony Devices Access Multiplexers Load Balancers Encryption ATM IP SAN Devices Voice over X DSLAMs L4-7 Routing NAT Frame Relay

6. MIT’s Click • “Push-Pull” semantics • Single-threaded • Network element database: 200+ elements • Tight integration with Linux

7. Click’s Shortcommings • Complexity scales with the number of ports • Difficult to modify or augment behavior without restructuring • 50+ elements just for a basic 2-port IPv4 router: does not include several desirable features • Steep learning curve and implementation time

8. An MPLS Example

9. Some Observations • The goal of modular routers is to quickly prototype & develop network router applications • Actually very cumbersome in Click to implement moderately complex functions • You don’t get “out of the box” router functionality • Implementing new functionality usually requires rewriting or adding new elements • Functionality cannot easily be changed, and implementation complexity scales with # of ports and application size

10. A New Model • High productivity high-level design • Current modular routers are very fine-grained • Atomic elements: queues, classifiers, basic routers, etc. • Key questions: • Is a fine-grained approach necessary? • Instead, how can we achieve a high-level framework for router application design, while maintaining generality and performance?

11. Commercial routers • Through simple command-line parameters, a complex router application with n ports can be configured inminutes & hours, not days & weeks • Firewall rules, NAPT, VLANs, OSPF, RIP, L2 switching, L3 routing, L4-7 load balancing, port trunking, bandwidth rate limiting Router:/config/vlan/4/ip/create 10.10.140.1/24 Router:/config/vlan/4/ports/add 0-15 Router:/config/vlan/5/ip/create 192.168.2.1/24 Router:/config/vlan/5/ports/add 16-31 Router:/config/ip/traffic-filter/1/destination 10.0.0.1/32 Router:/config/ip/traffic-filter/1/action drop Router:/config/ip/traffic-filter/1/apply 2,3,6

12. Achieving Generality • We can mimic an existing router CLI in software, but how do we implement arbitrary functionality?

13. A New Framework:Generalized Packet Filters • Existing routers have predefined “filter rules” that can be enabled/disabled per port via globally-unique names • Can be extended to support arbitrary packet operations

14. Packet Filters • Actions • Allow, drop, redirect, tag, forward to control plane • Basic L2-L4 Filters • “Drop packets with DIP=10.x.x.x and Dport=80” • Sophisticated L7 Filters • “Allow HTTP packets to www.yahoo.com:80” • Arbitrary Filters • Network address translation, MPLS, iSCSI, ATM, Frame Relay

15. Example 1:NAT Firewall (200-300 elements in Click for a complex 16-port NAT firewall)

16. Example 1:NAT Firewall Shared State (200-300 elements in Click for a complex 16-port NAT firewall)

17. Example 2:RED Congestion Control Policy (75-100 elements in Click)

18. Example 3:Server Load Balancing (??? elements in Click)

19. Implementing the Framework • One possible communication model for filters: Dataflow Process Networks with bounded buffers • Inherently supports multithreading & distributed hardware implementation • Simple C++ interface for implementing packet filters • Programming model • CLI-based configuration does most of the work • If new exotic functionality is required, just write a new packet filter in C++ • Linux runtime • Linux pcap library • CLI-based configuration

20. Other Considerations • Simulation speed • Native multithreading, message passing, shared memory • Estimation of performance • Click has zero notion oftime! • Filters & components in this framework can be annotated with performance estimates • Runtime environment can estimate overall performance • Clear path to HW/SW implementation • Click may still be better for: • WSIWYG • (Very) small examples & experiments

21. Summary & Conclusion • This approach allows you to design, test, and implement general network applications at a much higher level than Click, with higher productivity • Achieves out-of-the-box functionality that mimics the desired structure of most interesting applications • Supports fine-grained packet processing without the limitations of a fine-grained environment • Whenever you need to modify or extend functionality beyond existing capabilities, add a new filter!

22. Future Work • Generalized packet filter concept is unique, fits well with my personal research agenda • Need to implement: • More of the out-of-box functionality (e.g. OSPF, VLANs, RiP) • More types of filters • Better multithreading • Extend the CLI (it’s very basic right now) • Simulation & workload generation tools • Release the software! Has many uses in the networking & Linux community