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

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

3. 3 Background

4. 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 Click Modular Router  Washington University’s Router Plugins  VERA

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

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

7. 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. 8 An MPLS Example

9. 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. 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. 11 Commercial routers Through simple command-line parameters, a complex router application with n ports can be configured in minutes & 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. 12 Achieving Generality We can mimic an existing router CLI in software, but how do we implement arbitrary functionality?

13. 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. 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. 15 Example 1: NAT Firewall (200-300 elements in Click for a complex 16-port NAT firewall)

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

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

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

19. 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. 20 Other Considerations Simulation speed  Native multithreading, message passing, shared memory Estimation of performance  Click has zero notion of time!  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. 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. 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