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
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.
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