1 The Computer is the Network: The Emergence of Programmable Network Elements Randy H. Katz Computer Science Division Electrical Engineering and Computer.

1

The Computer is the Network:The Emergence of

Programmable Network Elements

Randy H. KatzComputer Science Division

Electrical Engineering and Computer Science DepartmentUniversity of California, Berkeley

Berkeley, CA 94720-1776

2

Presentation Outline

• Motivation• OASIS Project• RouterVM• COPS• Summary and Conclusions

3



4

Edge Network

WideArea

Network

ServerServer

ServerServer

Managing Edge Network Services and Applications

• Not shrink wrap software—but cascaded “appliances”• Data Center in-a-box blade servers, network storage• Brittle to traffic surges and shifts, yielding network

disruption

FirewallIDSTrafficShaper

EgressChecker

LoadBalancer

Blades

Edge Network Middleboxes

5

Appliances Proliferate:Management Nightmare!

F5 Networks BIG-IP LoadBalancerWeb server load balancer

Packeteer PacketShaperTraffic monitor and shaper

Ingrian i225SSL offload appliance

Network Appliance NetCacheLocalized content delivery platform

Nortel Alteon Switched FirewallCheckPoint firewall and L7 switch

Cisco IDS 4250-XLIntrusion detection system

Cisco SN 5420IP-SAN storage gateway

Extreme Networks SummitPx1L2-L7 application switch

NetScreen 500Firewall and VPN

6

Network Support for Tiered Applications

LAN LAN LAN WideArea

Network

ServerAppTier

EgressChecker

ServerServerWebTier

ServerServer

ServerDatabaseTier

Firewall

LoadBalancer

Datacenter Network(s)

Unified LAN

WideArea

Network

ServerServer

ServerServerson

Demand

LoadBalancer

+Firewall

+Egress

CheckerBlades

ServerServer

ServerServerson

DemandConfigure servers, storage, connectivitynet functionality as needed

7

“The Computer is the Network”

• Emergence of Programmable Network Elements– Network components where net services/applications execute– Virtualization (hosts, storage, nets) and flow filtering (blocking,

delaying)

• Computation-in-the-Network is NOT Unlimited– Packet handling complexity limited by latency/processing

overhead– NOT arbitrary per packet programming (aka active networking)– Allocate general computation like proxies to network blades

• Beyond Per Packet Processing: Network Flows– Managing/configuring network for performance and resilience– Adaptation based on Observe (Monitor), Analyze (Detect,

Diagnose), Act (Redirect, Reallocate, Balance, Throttle)

8

Key Technical Challenge: Network Reliability

• Berkeley Campus Network– Unanticipated traffic surges render the network

unmanageable (and may cause routers to fail)– Denial of service attacks, latest worm, or the newest file

sharing protocol largely indistinguishable– In-band control channel is starved, making it difficult to

manage and recover the network

• Berkeley EECS Department Network (12/04)– Suspected denial-of-service attack against DNS– Poorly implemented/configured spam appliance adds to

DNS overload– Traffic surges render it impossible to access Web or

mount file systems

• Network problems contribute to brittleness of distributed systems

9



10

Overlays and

Active

Services for

Inter-networked

Storage

11

Vision• Better network management of

services/applications to achieve good performance and resilience even in the face of network stress

– Self-aware network environment– Observing and responding to traffic changes– While sustaining the ability to control the network

• Packet flow manipulations at L4-L7 made possible by new programmable network elements

• New service building blocks– Flow extraction– Packet annotation– Packet translation– Resource management

12

Generic Network Element Architecture

InterconnectionFabric

Inp

ut

Port

s

Outp

ut

Port

s

Buffers

Buffers

Buffers

“Tag”Mem

CPCPCPAP

ActionProcessor

CPCPCPCP

ClassificationProcessor

Rules &Programs

13

SoftwareRouter

Linux-based,Click, etc.

HardwareAssist for

GeneralizedInspection

TCAMFPGAState

Machine

“Basic” RouterForwarding,IP Filtering

Edge

Core

Extended RouterDeeper Inspection

Generalized Actions

SAN, FW, IDS,Traffic Shaper,L7 Switch, …

NetApps

PacketProcessingSoftware

NPUs,Blade

s

RouterVM Generalized Filteringand Composition

cPredicates Packet/Flow Segregation

OASIS Framework

Applications Network Service Protection

ControlPlane

A-Layer+

EventManager

14

E.g., Application-Specific QoSfor Three-Tier Systems

• Composable building blocks to build web services– Web containers, various app/ejb containers, persistent state via

automatically managed DB pools

• Problem: Open control loop/requests driven by users– Flash traffic, increased workload can overload components of

the web service– Hard to provision; hard to make performance guarantees;

seemingly broken behavior to the end user

• TrafficOperation Classification– Ants: Lightweight processing, touch few components– Elephants: Heavyweight processing, cross-layer, many

components– Hard to distinguish statically, but can be determined through

statistical techniques– Correlate request patterns with measured system parameters

(web + db CPU, disk activity, OS process switches, etc.) to identify elephants vs. ants

15

Identifying RuBIS Elephant Flows for Admission Control/QoS

SLOWDOWN

NoNetworkVisibility

Servers

/dbLookup.php SLOWDOWN

/storeBid.php

/lightRequest.php

/lightRequest.php

HTTPHeaderVisibility

Servers

16

Request Time Distribution with

Preferential Scheduling

stock adm controltotal requests 756137 1143264correlated URLs 112521 105964req/sec (avg) 462 782session time (avg) 670 872max request time 154.7 32.7

Blocking phenomenonSession time goes upBut worst case goes way down

Uncontrolled Controlled

17



18

RouterVM

• High-level specification environment for describing packet processing

• Virtualized: abstracted view of underlying hardware resources of target PNEs

– Portable across diverse architectures– Simulate before deployment

• Services, policies, and standard routing functions managed thru composed packet filters

– Generalized packet filter: trigger + action bundle, cascaded, allows new services and policies to be implemented / configured thru GUI

– New services can be implemented without new code through library building blocks

Mel Tsai

19

QoS ModuleQoS ModuleL2 Switching

Engine w/ ARP

L2 SwitchingEngine w/ ARP

IP Router Engine

IP Router Engine

ControlProcessor

ControlProcessor

Packet filter 1

Packet filter 2

Packet filter n

Default filter

EthernetPort

QoS ModuleQoS Module

Backp

laneBackp

lane



IP Router Engine

IP Router Engine

Packet filter 1

Packet filter 2

Packet filter n

Default filter

EthernetPort

ComputeEngine

ComputeEngine

ComputeEngine

Extended Router Architecture• Virtualized components representative of a

“common” router implementation• Structure independent of particular hardware

Virtual line card instantiated for every

port required by application

Virtual backplane shuttles packets between line cards

CPU handles routing protocols & mgmt tasks

Compute engines perform complex, high-latency processing on flows

Blue “standard” components

Yellow components added & configured per-application

Filters are key to flexibility

Mel Tsai

20

Generalized Packet Filters

• Key to flexibility– Extend router “filter” concept– Small # of GPF building blocks yield

large number of apps» Compose/parameterize filters» No code writing

– Supports flexible classification, computation, and actions

– Executed in numeric order– How “complete” is this

formalization?

• Examples:– Traffic shaping and monitoring– L7 traffic detection

(Kazaa, HTTP, AIM, POP3, etc.)– QoS and packet scheduling– NAT– Intrusion detection– Protocol conversion (e.g. IPv6)– Content caching– Load balancing– Router/server health monitoring– Storage– Fibre Channel to IP– iSCSI– XML preprocessing– TCP offload (TOE)– Mobile host management, 802.11– Encryption/compression. VPNs– Multicast, Overlays, DHTs

L2 SwitchingEngine w/ARPL2 SwitchingEngine w/ARP

Packet filter 1

Packet filter 2

Packet filter n

Default filter

Mel Tsai

21

GPF Example

Back

pla

ne

Back

pla

ne

ControlProcessor

ControlProcessor


L2 SwitchingEngine w/ARP


IP Router Engine

IP Router Engine

GPF 5:

SLB

GPF 10:

P2P…

Servers

To Clients

A Server Load Balancer and L7 Traffic Detector

10.0.0.1

10.0.0.2

Ext. IP = 24.0.5.6

10.35.x.x

22

GPF Example

Back

pla

ne

Back

pla

ne

ControlProcessor

ControlProcessor




IP Router Engine

IP Router Engine

GPF 5:

SLB

GPF 10:

P2P…

Servers

To Clients


10.0.0.1

10.0.0.2

Ext. IP = 24.0.5.6

GPF 5 Setup

name -algorithm -

flowid -sip -

smask - dip -

dmask - proto -

action1 -action2 -action3 -

Server Load Balancerequal flowssip, sportanyany24.0.5.6255.255.255.255udp, tcpslb nat 10.0.0.1, 10.0.0.2log connections, file = log.txttag “skip Yahoo Messenger Filter”

10.35.x.x

23

GPF Example

Back

pla

ne

Back

pla

ne

ControlProcessor

ControlProcessor




IP Router Engine

IP Router Engine

GPF 5:

SLB

GPF 10:

P2P…

Servers

To Clients


10.0.0.1

10.0.0.2

Ext. IP = 24.0.5.6

GPF 10 Setup

name - type -

pattern -

timeout - flowid -

sip - smask -

dip - dmask -

proto - action1 -

action2 -

Yahoo Messenger Filteryahoomessenger^(ymsg|ypns|yhoo).?.?.?.?.?.?.?(w|t).*\xc0\x8010 minsip, dip, sport, dportanyany10.35.0.0255.255.0.0tcplimit 1 kbpsemail root 10.35.x.x

24

GPF “Fill-in” Specification

“Packet filter” as high-level, programmable building-block

for network appliance apps

FILTER 19 SETUP

NAME - SIP -

SMASK - DIP -

DMASK -PROTO -

SRC PORT -DST PORT -

VLAN - ACTION -

exampleany255.255.255.25510.0.0.0255.255.255.0tcp,udpany80defaultdrop

ClassificationParameters

Action

Traditional Filter

RouterVM Generalized Packet Filter (type L7)

26

GPF Action Language

• Basic set of assignments, evaluations, expressions, control-flow operators, and “physical” actions on packets/flows– Control-flow: If-then-else, if-not– Evaluation: ==, <=, >=, !=– Packet flow control: Allow, unallow, drop, skip filter, jump filter– Packet manipulation: Field rewriting (ip_src == blah,

tcp_src = blah), truncation, header additions– Actions: NAT, loadbalance, ratelimit, (perhaps others)– Meta actions: packet generation, logging, statistics gathering

• Higher level of abstraction than C/C++ or packet processing language

27

Implemented GPF Libraries

• Basic Filter– Simple L2-L4 header classifications– Any RouterVM actions

• L7 Filter– Adds regular expressions, TCP termination, ADU reconstruction

• NAT Filter– Adds a few more capabilities beyond the simple NAT action that is

available to all GPFs

• Content Caching– Builds on the L7 filter functionality

• WAN Link Compression– Relatively simple to specify, but requires lots of computation

• IP-to-FC Gateway– Requires its own table format & processing

• XML Preprocessing– Not very well documented, and difficulty is unknown…

28

GPF Expressiveness Analysis

Expressiveness at the app layers depends on thebreadth of GPF library and GPFs for specific apps

29

GPF Performance: Complex Filters

L2-L4 Headers “Retreat” 25 bytes of char ‘X’ “Retreat” 25 bytes of char ‘X’ “Retreat” Padding with ‘X’

Lesson: try to use start-of-buffer

indicators ^ and avoid *’s…

Many apps can be identified with simple start-of-

buffer expressions

Regex involves payload copying, which might be

avoidable

30



31

Observations and Motivations

• Internet reasonably robust to point problems like link and router failures (“fail stop”)

• Successfully operates under a wide range of loading conditions and over diverse technologies

• During 9/11/01, Internet worked reasonable well, under heavy traffic conditions and with some major facilities failures in Lower Manhattan

32

Why and How Networks Fail

• Complex phenomenology of failure• Recent Berkeley experience suggests that traffic

surges render enterprise networks unusable• Indirect effects of DoS traffic on network

infrastructure: role of unexpected traffic patterns– Cisco Express Forwarding: random IP addresses flood route

cache forcing all traffic to go through router slow path—high CPU utilization yields inability to manage router table updates

– Route Summarization: powerful misconfigured peer overwhelms weaker peer with too many router table entries

– SNMP DoS attack: overwhelm SNMP ports on routers– DNS attack: response-response loops in DNS queries generate

traffic overload

33

COPSChecking

Observing

Protecting

Services

34

Check

• Checkable Protocols: Maintain invariants and techniques for checking and enforcing protocols

– Listen & Whisper: well-formed BGP behavior– Traffic Rate Control: Self-Verifiable Core Stateless Fair

Queuing (SV-CSFQ)

• Existing work requires changes to protocol end points or routers on the path

– Difficult to retrofit checkability to existing protocols without embedded processing in PNEs

– Building blocks for new protocols » Observable protocol behavior» Cryptographic techniques» Statistical methods

35

Protect

• Protect Crucial Services– Minimize and mitigate effects of attacks and traffic

surges– Classify traffic into good, bad, and ugly (suspicious)

» Good: standing patterns and operator-tunable policies

» Bad: evolves faster, harder to characterize» Ugly: that which cannot immediately be determined

as good or bad– Filter the bad, slow the suspicious, maintain resources

for the good (e.g., control traffic)» Sufficient to reduce false positives» Some suspicious-looking good traffic may be slowed

down, but won’t be blocked

36

Observe

• Observation (and Action) Points– Network points where control is exercised, traffic

classified, resources allocated– Routers + End Hosts + Inspection-and-Action Boxes

(iBoxes)» Prototyped on commercial PNEs» Placed at Internet and Server edges of enterprise

net» Cascaded with existing routers to extend their

functionality

37

iBox Placement for Observation and Action

AccessTier

AccessTier

AccessTier

R R

R R

I nternet orWAN Edge

RDistribution

Tier

I

EE

EE

EE

EE

EE

EE

UserEnd Hosts

ServerEnd Hosts

Network ServicesEnd Hosts

I

I

I R I

R

iBoxes strategically placed near entry/exit points within the Enterprise network

38

Annotation Layer:Between Routing and

Transport

• Marking vs. rewriting approach– E.g., mark packets as internally vs. externally sourced using

IP header options

• Prioritize internal vs. external access to services solves some but not all traffic surge problems

iBoxBoundaryRouter

NetworkServices

iBoxI nternalRouter

Enterprise Network

External Traffi c

I nternal Traffi c

Packet

PacketLabel PacketLabel

PacketLabel

Action: Markpackets

Detect load and trigger action: Slow traffi c with “external” labels

39

Annotation Layer:iBox Piggybacked Control

Plane• Problem: Control plane starvation• Use A-layer for iBox-to-iBox communication

– Passively piggyback on existing flows– “Busy” parts of network have lots of control plane b/w– Actively inject control packets to less active parts– Embedded control info authenticated and sent

redundantly– Priority given to packets w/control when net under stress

• Network monitoring and statistics collection and dissemination subsystem currently being designed and prototyped

40

Observe and Protect

iBoxes implemented on commercial PNEs

– Don’t: route or implement (full) protocol stacks

– Do: protect routers and shield network services

» Classify packets» Extract flows» Redirect traffic» Log, count, collect stats» Filter/shape traffic

42



43

OASIS

• Processing-in-the-Network is real– Networking plus processing in switched and routed

infrastructures– Configuration and management of packet processing

cast onto programmable network elements (network appliances and blades)

• Unifying Framework– Methods to specify functionality and processing

» RouterVM: Filtering, Redirecting, Transformation » cPredicates: Control extraction and execution

based on packet applications content

• Application-specific network processing based on session extraction

44

COPS

• PNEs: foundation of a pervasive infrastructure for observation and action at the network level

– iBoxes Observation and Action points– Annotation Layer for marking and control

• Check-Observe-Protect paradigm for protecting critical resources when network is under stress

• Functionality eventually migrates into future generations of routers

– E.g., Blades embedded in routers

45

The Computer is the Network:

The Emergence of Programmable

Network Elements

Randy H. Katz

Thank You!

1 The Computer is the Network: The Emergence of Programmable Network Elements Randy H. Katz Computer Science Division Electrical Engineering and Computer.

Documents

network blades

network support

network unmanageable

network storage brittle

edge network services

vpn slide

throttle slide

needed slide