1 A High-Level Framework for Network Application Design Mel Tsai [email protected] 12/5/2002 EE249 Final Project Presentation

1

A High-Level Framework for Network Application Design

Mel [email protected]

12/5/2002

EE249 Final Project Presentation

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

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

5

Network Application Space

AccessAccess

LAN Switche

s & Routers

GbE, 10/100 Ethernet

802.11Error

ControlToken Ring

FDDI Wireless

Devices

Edge Terminato

rs

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 Bridg

es

IP over ATM

Firewalls

DCS over ATM

Servers

L4-7 Routing

Network Management &

Accounting

High-Speed Backbone Routers

ATM

IP

Frame Relay

EdgeEdge CoreCore

WAN Circuit

Switches

xDSL ISDN

Error Correction

Mobile IP

PBX Devices

DSLAMs Frame Relay

IPATM

Inverse Multiplexers

Frame Relay

IPATM

VPNs

MPLS

QoS

SSL Accelerators

SAN Devices

Load Balancers

NATEncryption

NAT

Encryption

Remote Access

QoS X over WDM

X over SONET

MPLS

NICs

6

MIT’s Click

• “Push-Pull” semantics

• Single-threaded

• Network element database: 200+ elements

• Tight integration with Linux

Ethernetpackets Strip(14)

Discard

IP packetsmatching 10.0.0.x

IPClassifier(10.0.0.0/24,–)

0

1

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 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/24Router:/config/vlan/4/ports/add 0-15

Router:/config/vlan/5/ip/create 192.168.2.1/24Router:/config/vlan/5/ports/add 16-31

Router:/config/ip/traffic-filter/1/destination 10.0.0.1/32Router:/config/ip/traffic-filter/1/action dropRouter:/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?

ForwardingEngine

ForwardingEngine

BackplaneBackplane

ForwardingEngine

ForwardingEngine

ForwardingEngine

ForwardingEngine

ControlProcessor

ControlProcessor

Lin

e C

ard

ATM

Lin

e C

ard

ATM

Lin

e C

ard

ATM

Lin

e C

ard

POS

Lin

e C

ard

POS

Lin

e C

ard

POS

Lin

e C

ard

POS

Lin

e C

ard

GbE

Lin

e C

ard

GbE

Lin

e C

ard

10/ 100

Lin

e C

ard

10/ 100

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

QoS ModuleQoS Module

Backp

lane

Backp

lane

L2 SwitchingEngine w/ ARP


IP Router Engine

IP Router Engine

ControlProcessor

ControlProcessor

Packet filter 1

Packet filter 2

Packet filter n

Default filter

EthernetPort

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

QoS Module

QoS Module

Backp

lane

Backp

lane



IP Router Engine

IP Router Engine

Packet filter 1

NAT Packet Filter 3

Packet filter 33

Default filter

EthernetPort

ControlProcessor

ControlProcessor

QoS Module

QoS Module



IP Router Engine

IP Router Engine

Packet filter 1

NAT Packet Filter 3

Packet filter 48

Default filter

EthernetPort

(200-300 elements in Click for a complex 16-port NAT firewall)

16

Example 1: NAT Firewall

QoS Module

QoS Module

Backp

lane

Backp

lane



IP Router Engine

IP Router Engine

Packet filter 1

NAT Packet Filter 3

Packet filter 33

Default filter

EthernetPort

ControlProcessor

ControlProcessor

QoS Module

QoS Module



IP Router Engine

IP Router Engine

Packet filter 1

NAT Packet Filter 3

Packet filter 48

Default filter

EthernetPort

(200-300 elements in Click for a complex 16-port NAT firewall)

Shared State

17

Example 2: RED Congestion Control Policy

RED QoSModule

RED QoSModule

Backp

lane

Backp

lane



IP Router Engine

IP Router Engine

Packet filter 1

Packet

Filter 3

Packet filter 33

Default filter

EthernetPort

RED QoS Module

RED QoS Module



IP Router Engine

IP Router Engine

ControlProcessor

ControlProcessorPacket

filter 16Packet filter 99

Default filter

EthernetPort

(75-100 elements in Click)

18

Example 3: Server Load Balancing

(??? elements in Click)

QoS Module

QoS Module

Backp

lane

Backp

lane



IP Router Engine

IP Router Engine

Packet filter 1

Weighted Scheduler

Packet filter 33

Default filter

EthernetPort

ControlProcessor

ControlProcessor

QoS Module

QoS Module



IP Router Engine

IP Router Engine

Packet filter 1

Packet filter 48

Default filter

EthernetPort

Counters

Weighted Scheduler

Counters

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 (it’s very basic right now) Simulation & workload generation tools

• Release the software! Has many uses in the networking & Linux community

Documents

1 A High-Level Framework for Network Application Design Mel Tsai [email protected] 12/5/2002 EE249 Final Project Presentation