A HighLevel Framework for Network Application Design

1

• A High-Level Framework for Network Application
  Design
• Mel Tsai
• mtsai_at_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
• MITs Click Modular Router
• Washington Universitys 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
Token Ring
Error Correction
xDSL
QoS
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
Inverse Multiplexers
Encryption
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
MITs Click

• Push-Pull semantics
• Single-threaded
• Network element database 200 elements
• Tight integration with Linux

7
Clicks 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 dont 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
  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/destinat
ion 10.0.0.1/32 Router/config/ip/traffic-filter/1
/action drop Router/config/ip/traffic-filter/1/ap
ply 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 FrameworkGeneralized 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 DIP10.x.x.x and Dport80
• Sophisticated L7 Filters
• Allow HTTP packets to www.yahoo.com80
• 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 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
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 (its very basic right now)
• Simulation workload generation tools
• Release the software! Has many uses in the
  networking Linux community