Transcript Slides
A High-Level Framework for Network Application Design Mel Tsai [email protected] 12/5/2002 EE249 Final Project Presentation 1 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 2 Background 3 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 4 Network Application Space Access Wireless Devices Mobile IP 802.11 Error Error Control Correction GbE, 10/100 Ethernet Token Ring Edge Terminators Modems WAN Circuit Switches WAN Bridges QoS IP over DCS ATM over ATM NICs xDSL Firewalls ATM MPLS ATM IP Frame Relay SSL Accelerators Access Multiplexers Encryption High-Speed Backbone Routers X.25, SDMS Servers PBX Devices ISDN WAN Packet Routers NAT Encryption Inverse Multiplexers ISDN IAD / Telephony Devices xDSL MPLS Cable Analog Core VPNs LAN Switches & Routers FDDI Edge Frame Relay IP IP X over QoS MPLS ATM WDM Frame X over Relay SONET Network Management & Accounting Remote Access Load Balancers ATM Voice over X IP DSLAMs Frame Relay SAN Devices NAT L4-7 Routing 5 MIT’s Click • • • • “Push-Pull” semantics Single-threaded Network element database: 200+ elements Tight integration with Linux Ethernet packets Strip(14) IPClassifier(10.0.0.0/24, –) 0 IP packets matching 10.0.0.x 1 Discard 6 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 7 An MPLS Example 8 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 9 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? 10 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 11 Achieving Generality • We can mimic an existing router CLI in software, but how do we implement arbitrary functionality? 12 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 13 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 14 Example 1: NAT Firewall (200-300 elements in Click for a complex 16-port NAT firewall) 15 Example 1: NAT Firewall Shared State (200-300 elements in Click for a complex 16-port NAT firewall) 16 Example 2: RED Congestion Control Policy 17 (75-100 elements in Click) Example 3: Server Load Balancing 18 (??? elements in Click) 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 19 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 20 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! 21 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 22