/
David Walker               Princeton University David Walker               Princeton University

David Walker Princeton University - PowerPoint Presentation

danika-pritchard
danika-pritchard . @danika-pritchard
Follow
345 views
Uploaded On 2018-09-21

David Walker Princeton University - PPT Presentation

Joint work with Nate Foster Michael J Freedman Rob Harrison Christopher Monsanto Mark Reitblatt Jennifer Rexford and Alec Story at Princeton and Cornell Universities A Network Programming Language ID: 674168

query switch stats network switch query network stats policy frenetic packet controller def rules nox repeater runtime install packets web port programming

Share:

Link:

Embed:

Download Presentation from below link

Download Presentation The PPT/PDF document "David Walker Princeton Uni..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.


Presentation Transcript

Slide1

David Walker Princeton University Joint work with Nate Foster, Michael J. Freedman, Rob Harrison, Christopher Monsanto, Mark Reitblatt, Jennifer Rexford, and Alec Story at Princeton and Cornell Universities

A Network Programming LanguageSlide2

The Team2

Mike Freedman

Nate Foster

Rob Harrison

Chris Monsanto

Jen Rexford

Mark

Reitblatt

Alec StorySlide3

Traditional Networks3

Data Plane (hardware):

Forward, filter, buffer, mark,

r

ate-limit packets; collect stats

Control Plane (software)

:

Track topology; compute

r

outes; install forwarding tables

Management

:

Monitor traffic

Configure policiesSlide4

A Recent Idea: (Re)Move the Control Plane?Move the control plane out of the switch boxes and in to separate, general-purpose computersCompanies buy the forwarding hardware, but implement their own control software Simpler routers ==> cheaper, more flexible routersthe same hardware box can be a router, a switch, a NAT, a firewall, or some new combinationyou don’t have to buy that special million $ load balancer from the networking company

Accelerated innovation4Slide5

5

Data Plane

Controller Machine

Programs running on general-purpose machines implement control and management planes

Monitor network traffic, track topology, decide on routes, install forwarding tablesSlide6

MomentumNew ApplicationsSeamless host mobilityNetwork virtualizationDynamic access control

Energy efficient datacenter management

Web server load balancingEveryone has signed on:Microsoft, Google, Cisco, Yahoo, Facebook, …

6Slide7

New ChallengesOpenFlow makes programming networks of switches possible, but doesn’t make it easyA thin veneer over the switch hardwareA challenging programming problemOur goals:Develop language support that facilitates network programmingNew abstractionsMore modular

More reliableMore secure

7Slide8

This TalkOpenFlow & NOX in more depthExisting programming model and problemsFrenetic LanguageNew abstractions for network programmingFrenetic Run-time SystemImplementation strategy and experience8Slide9

OpenFlow Switches9

Flow Table

Packet

Header

Pattern

Action

Bytes

Packets

01010

Drop

200

10

010*

Forward(n)

100

3

011*

Controller

0

0

prioritySlide10

NOX: A Controller Platform10Controller

NOX – Controller Platform

Exports Rule-management interface:

Install

O

penFlow

rule

Uninstall OpenFlow ruleAsk for stats associated with rule

Exports Events:Packet inTopology Changes

Controller ApplicationSlide11

OpenFlow ArchitectureController

Switches

Network Events

Forwarding table miss

Control Messages

Add/remove rulesSlide12

Problem I: Modular Programming12

Routing

Module

Controller Application

R: forward port 1 to port 2

1

2

Monitoring

Module

q

uery web traffic?

R installed

Doesn’t work! Repeater rules too

c

oarse-grainedSlide13

Modular Programming: A Different View13def switch_join(switch): repeater(switch)

def repeater(switch): pat1

= {in_port:1} pat2 = {in_port:2} install(switch,pat1,DEFAULT,None,[output(2)])

install(switch,pat2,DEFAULT,None

,[output(1

)])

def

monitor(switch):

pat

= {in_port:2,tp_src:80} install(switch, pat, DEFAULT, None, []) query_stats(switch, pat)

def stats_in(switch, xid, pattern, packets, bytes): print

bytes sleep(30) query_stats(switch, pattern)

Repeater

Web Monitor

d

ef

switch_join

(switch)

repeater_monitor(switch)

def repeater_monitor(switch): pat1

= {in_port:1} pat2 = {in_port:2} pat2web

= {in_port:2, tp_src:80} Install(switch, pat1, DEFAULT, None, [output(2)])

install(switch, pat2web, HIGH, None, [output(1)]) install(switch, pat2,

DEFAULT, None, [output(1)]) query_stats(switch, pat2web)def stats_in

(switch,

xid

, pattern, packets, bytes):

print

bytes

sleep(30

)

query_stats

(switch

, pattern)

Repeater/Monitor

blue = from repeater

red = from web monitor

green = from neitherSlide14

Problem II: Network Race ConditionsA challenging chain of events:Switch sends packet to controllerController analyzes packetupdates its stateinitiates installation of new packet-processing rulesSwitchhasn’t received new rules

sends new packets to controllerControllerconfusedpackets in the same flow handled inconsistently

14

ControllerSlide15

Problem III: Two-tiered Programming ModelTricky problem:Controller activity is driven by packets sent from switchesEfficient applications install rules on switches to forward packets in hardwareConstant questions:“Is that packet going to come to the controller to trigger my computation?” “Or is it already being handled invisibly on the switch?”

15

ControllerSlide16

Three Problems – One Common CauseThree problems:Non-modular programming: Programs can’t be divided into modules for monitoring and forwardingNetwork race conditions: The controller sees more events (packets) than it anticipatesTwo-tiered programming: Will the controller be able to see the appropriate events given the forward rules installed?One common cause:

No effective abstractions for reading network state

164.29.2011Slide17

The SolutionSeparate network programming into two parts:Abstractions for reading network stateReads should have no effect on forwarding policyReads should be able to see every packetAbstractions for specification of forwarding policy Forwarding

policy must be separated from implementation mechanismA natural decomposition that mirrors the two fundamental tasks of network management

Monitoring and forwarding17Slide18

This TalkOpenFlow & NOX in more depthExisting programming model and problemsFrenetic LanguageNew abstractions for network programmingFrenetic Run-time SystemImplementation strategy and experience18Slide19

Frenetic LanguageAbstractions for reading network state:Realized as an integrated network query languageselect, filter, group sets of packets or statisticsdesigned so that most computation can occur on switches in the data planeAbstractions for specification of forwarding policy:Realized as a functional stream processing librarygenerate streams of network policies

transform, split, merge, filter policies & other data streams Current Implementation:A set of python libraries on top of NOX

19Slide20

Frenetic Queries20def

web_query():

return (Select (sizes) * Where (inport_fp

(

2

) &

srcport_fp

(80))

*

Every (30))data to be returned from query (options: sizes, counts, packets)

period: 30 seconds

filter based on packet headers

(web traffic in on port 2)

1

2

Goal: measure the total bytes of web traffic arriving on port 2,

every 30 seconds

Key Property: Query semantics independent of other program partsSlide21

Frenetic Queries21

1

2

Goal: sum the number of packets, per host (

ie

: mac address),

traveling through port 2, every minute

def

host_query

():

return (Select (counts) * Where (

inport_fp(2

)) *

GroupBy ([srcmac

]) *

Every (60))

categorize results by

srcmac

addressSlide22

Frenetic Queries22

Goal: report the hosts connected to each switch port;

report a host each time it moves from one port to the next

def

learning_query

():

return

(

Select (packets) *

GroupBy

([

srcmac

])

*

SplitWhen

([inport]) *

Limit (1))

get packets for analysis

at most one packet per flow

categorize by

srcmac

sub-categorize when the

inport

changes (the host moves)

Key Property:

Query implementation handles network race conditionsSlide23

Using QueriesQuery results, or other streams, are piped in to listeners23

def

web_stats():

web_query

() >> Print()

def

web_query

():

…def

host_query(): …def learning_query(): …

def

all_stats

(): Merge(web_query

(), host_query

()) >> Print()

Key Property: Queries composeSlide24

Frenetic Forwarding Policies24

1

2

Goal: implement a repeater switch

rules = [Rule(

inport_fp

(1), [forward(2)]),

Rule(

inport_fp

(2), [forward(1)])]

def

repeater():

return (SwitchJoin() >> Lift(lambda switch: {switch:rules

}))

packet pattern

(defined over headers)

rule actions

listen for switch joining the network

Key Property: Policy semantics independent of other queries/policies

def

main():

repeater()

>>

register()

register policy with run time

construct repeater policy for that switchSlide25

Program Composition25def

main():

repeater() >> register()

all_stats

()

Key Property: Queries and policies compose

Goal: implement both the stats monitor and the repeaterSlide26

One More Example26Goal: combine the repeater with a security policy

def

filter_ips(

ips

,

policy):

return (

subtract_p

(policy, {

srcips:ips}))

def

main(): secure(repeater()) >> register()

all_stats()

def

secure(policy_strea

m):

return (Pair(bad_ips

(), policy_stream

) >> Lift(

filter_ips))

Key Property: declarative semantics + functional programming = modularitySlide27

This TalkOpenFlow & NOX in more depthExisting programming model and problemsFrenetic LanguageNew abstractions for network programmingFrenetic Run-time SystemImplementation strategy and experience27Slide28

Frenetic System OverviewHigh-level LanguageIntegrated query languageEffective support for composition and reuseRun-time SystemInterprets queries, policiesInstalls rulesTracks statsHandles asynchronous behavior

28

Frenetic User Program

Frenetic Run-time System

NOX

query,

register policy

query response,

status streams

compile policies/

queries,

install rules

manage stats,

filter packets,

process eventsSlide29

Implementation OptionsRule Granularitymicroflow (exact header match)simpler; more rules generatedwildcard (multiple header match in single rule)more complex; fewer rules (may be) generatedRule Installation

reactive (lazy) first packet of each new flow goes to controller

proactive (eager) new rules pushed to switches29

Frenetic 1.0

Frenetic 2.0Slide30

Run-time ActivitiesNOX

30

Check Rules

Do Actions

Install Flow

Register

NOX

Frenetic Program

Frenetic Runtime System

Packet In

Frenetic Program

NOX

Runtime Module

Runtime Data Structure

Dataflow in to Runtime

Dataflow out from Runtime

Packet

PolicySlide31

Run-time ActivitiesNOX

31

Check Rules

Do Actions

Install Flow

Register

NOX

Frenetic Program

Frenetic Runtime System

Packet In

Frenetic Program

NOX

Runtime Module

Runtime Data Structure

Dataflow in to Runtime

Dataflow out from Runtime

Check Subscribers

Query

Stats

Monitoring Loop

Stats Request

Update Stats

Stats In

NOX

Packet

PolicySlide32

Run-time Activities

NOX

32

Check Rules

Do Actions

Install Flow

Register

NOX

Frenetic Program

Frenetic Runtime System

Packet In

Frenetic Program

NOX

Runtime Module

Runtime Data Structure

Dataflow in to Runtime

Dataflow out from Runtime

Check Subscribers

Query

Stats

Monitoring Loop

Stats Request

Update Stats

Stats In

NOX

Policy

Packet

Send Packet

Packet

Policy

Packet

Query

PacketsSlide33

Preliminary EvaluationMicro Benchmarks Coded in Frenetic & NoxCore Network Applications Learning Switch

Spanning Tree Shortest path routing

DHCP server Centralized ARP server Generic load balancer

Additional Apps

Memcached

query router

Network scanner DDOS defensive switch

4.29.201133Slide34

MicroBench: Lines of Code34

No monitoring

Heavy Hitters

Web Statistics

Lines

o

f

Code

Forwarding Policy:

HUB

: Floods out other ports LSW: Learning Switch

Monitoring PolicySlide35

MicroBench: Controller Traffic35

No monitoring

Heavy Hitters

Web Statistics

Traffic

t

o

Controller

(

kB

)Forwarding Policy:

HUB: Floods out other ports LSW: Learning Switch

Monitoring PolicySlide36

Future WorkPerformance evaluation & optimizationMeasure controller response time & network throughputSupport wildcard rules and proactive rule installationParallelismProgram analysis & network invariantsHosts and ServicesExtend queries & controls to end hosts

More abstractionsVirtual network topologies

Network updates with improved semantics 36Slide37

Conclusion: An Analogy37ConcernAssembly Languages

Programming Languages

x86NoxF#/C#/JavaFrenetic++

Resource

Allocation

Move

values in to/out of registers

Install, uninstall, reinstall switch rules

Declare

program variablesDeclareforwarding policyResourceTrackingHave I spilled that value?Will that packet arrive at the controller?

Program variables always accessibleSee every packet abstractionCoordination across program parts

Explicit calling conventionsGlobally shared switch state:rules, priorities, countersFunction call boundaries managed automaticallyForwarding policy and query composition managed automatically

PortabilityHardware DependentHardwareDependentHardware IndependentHardware IndependentSlide38

http://frenetic-lang.org