A Network Programming Language Nate Foster, Mike Freedman, Rob - - PowerPoint PPT Presentation

a network programming language
SMART_READER_LITE
LIVE PREVIEW

A Network Programming Language Nate Foster, Mike Freedman, Rob - - PowerPoint PPT Presentation

A Network Programming Language Nate Foster, Mike Freedman, Rob Harrison, Chris Monsanto, Jen Rexford, Alec Story, and Dave Walker Traditional Networks Operator : Monitors tra ffi c, Con fi gures policy Control Plane (software) : Tracks


slide-1
SLIDE 1

Nate Foster, Mike Freedman, Rob Harrison, Chris Monsanto, Jen Rexford, Alec Story, and Dave Walker

A Network Programming Language

slide-2
SLIDE 2

Traditional Networks

2

Data Plane (hardware): Forwards, filters, buffers, tags, rate-limits; collects stats Control Plane (software): Tracks topology; computes routes; modifies data plane state Operator: Monitors traffic, Configures policy

slide-3
SLIDE 3

Software-Defined Networks

Idea: move control off of switches and onto a separate, general-purpose computer.

3

Data Plane Controller Machine Arbitrary program implements control plane functionality:

  • Monitors traffic,
  • Tracks topology,
  • Selects routes,
  • Installs forwarding rules.
slide-4
SLIDE 4

Momentum

Everyone has signed on

Microsoft, Google, Cisco, Yahoo, Facebook, Deutch Telekom,…

New Applications

  • Host mobility
  • Virtualization
  • Dynamic access control
  • Energy-efficiency
  • Load balancing

4

slide-5
SLIDE 5

New Challenges

OpenFlow makes it possible to program the network, but it does not make it easy!

  • Provides a thin veneer over switch hardware
  • Like programming in assembly

Our goal

  • Develop new abstractions for programming networks

– More convenient – More modular – More reliable – More secure

5

slide-6
SLIDE 6

This Talk

OpenFlow in more depth

  • Existing programming model and problems

Frenetic Language

  • New abstractions for network programming

Frenetic Run-time System

  • Implementation strategy and experience
slide-7
SLIDE 7

OpenFlow Switches

6

Flow Table Pattern Action Bytes Packets 01010 Drop 200 10 010* Forward(n) 100 3 011* Controller priority

Switches

slide-8
SLIDE 8

OpenFlow Controllers (NOX)

7

Controller

Network Events

  • Packets
  • Stats
  • Topology changes

Control Messages

  • Install rules
  • Uninstall rules
  • Query counters

NOX Program

Switches

slide-9
SLIDE 9

Typical OpenFlow Application

Controller Switches

Network Events

  • Forwarding table miss

Control Messages

  • (Un)install rules

8

slide-10
SLIDE 10

Problem I: Anti-Modular

9

Repeater Module

Controller Application

P: Forward 1 → 2 and 2 → 1 1 2

Monitoring Module

Q: Query web traffic P installed Doesn’t work because repeater rules too coarse-grained; monitoring rules don’t forward

slide-11
SLIDE 11

Anti-Modularity: A Closer Look

def 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

def 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 neither

10

slide-12
SLIDE 12

Problem II: Two-tiered Model

Tricky problem:

  • Controller activity is driven

by packets

  • For efficiency, applications

install rules to forward packets in hardware

Constant questions:

  • “Will that packet come to

the controller and trigger my computation?”

  • “Or is it already being

handled invisibly on the switch?”

11

Controller

slide-13
SLIDE 13

Problem III: Network Race Conditions

A challenging sequence of events:

  • Switch

– sends packet to controller

  • Controller

– analyzes packet – updates its state – initiates installation of new packet-processing rules

  • Switch

– hasn’t received new rules – sends new packets to controller

  • Controller

– confused – packets in the same flow handled inconsistently

12

Controller

slide-14
SLIDE 14

Three problems with a common cause

Three problems

  • Anti-modular
  • Two-tiered model
  • Network race conditions

One cause No effective abstractions for reading network state

13

slide-15
SLIDE 15

The Solution

Separate network programming into two parts:

  • Abstractions for querying network state

– Reads have no effect on forwarding policy – Reads able to see every packet

  • Abstractions for specifying a forwarding policy

– Forwarding policy must be separated from implementation mechanism

A natural decomposition that mirrors two fundamental tasks: monitoring and forwarding

14

slide-16
SLIDE 16

This Talk

OpenFlow & Nox in more depth

  • Existing programming model and problems

Frenetic Language

  • New abstractions for network programming

Frenetic Run-time System

  • Implementation strategy and experience
slide-17
SLIDE 17

Frenetic Language

Abstractions for querying network state

  • An integrated query language

– select, filter, group, sample sets of packets or statistics – designed so that computation can occur on data plane

Abstractions for specifying a forwarding policy

  • A functional stream processing library (based on FRP)

– generate streams of network policies – transform, split, merge, filter policies and other streams

Implementation:

  • A collection of Python libraries on top of NOX

15

slide-18
SLIDE 18

Frenetic Queries

16

def ¡web_query(): ¡ ¡ ¡return ¡(Select(sizes) ¡* ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡Where(inport_fp(2) ¡& ¡srcport_fp(80)) ¡* ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡Every(30)) ¡ 1 2

Goal: measure total web traffic on port 2, every 30 seconds Key Property: query semantics is independent of other program parts

slide-19
SLIDE 19

Frenetic Forwarding Policies

17

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})) ¡

Key Property: Policy semantics independent of other queries/policies

slide-20
SLIDE 20

Program Composition

18

def ¡main(): ¡ ¡ ¡web_query() ¡>> ¡Print() ¡ ¡ ¡repeater() ¡>> ¡Register() ¡

Key Property: queries and policies compose Goal: implement both web monitoring and repeater

def ¡host_query(): ¡ ¡ ¡return ¡(Select(counts) ¡* ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡Where(inport_fp(1) ¡* ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡GroupBy([srcmac]) ¡* ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡Every(60)) ¡ ¡ def ¡secure(host_policy_stream): ¡... ¡ def ¡main(): ¡ ¡ ¡web_query() ¡>> ¡Print() ¡ secure(Merge(host_query(), ¡repeater())) ¡>> ¡Register() ¡

slide-21
SLIDE 21

This Talk

OpenFlow & Nox in more depth

  • Existing programming model and problems

Frenetic Language

  • New abstractions for network programming

Frenetic Run-time System

  • Implementation strategy and experience
slide-22
SLIDE 22

Frenetic System Overview

High-level Language

  • Integrated query language
  • Effective support for

composition and reuse

Run-time System

  • Interprets queries, policies
  • Installs rules
  • Tracks stats
  • Handles asynchronous events

19

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 events

slide-23
SLIDE 23

Run-time Activities

NOX

20

Check Rules Install Flow Policy Interpreter 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 Monitoring Loop Stats Request Update Stats Stats In Send Packet Query Interpreter Do Actions

slide-24
SLIDE 24

Preliminary Evaluation

Core Network Applications

  • Learning Switch
  • Spanning Tree
  • Shortest path routing
  • DHCP server
  • Centralized ARP server
  • Generic load balancer

Additional Applications

  • Memcached query router
  • Network scan detector
  • DDOS defensive switch

Micro Benchmarks

  • Coded in Frenetic and NOX

21

slide-25
SLIDE 25

MicroBench: Lines of Code

20 40 60 80 100 120 140 160 180 200 HUB LSW HUB LSW HUB LSW NOX Frenetic

23

No monitoring Heavy Hitters Web Statistics Lines

  • f

Code Forwarding Policy: HUB: Floods out other ports LSW: Learning Switch Monitoring Policy

slide-26
SLIDE 26

MicroBench: Controller Traffic

2 4 6 8 10 12 14 16 HUB LSW HUB LSW HUB LSW NOX Frenetic

24

Traffic to Controller (kB) Forwarding Policy: HUB: Floods out other ports LSW: Learning Switch Monitoring Policy No monitoring Heavy Hitters Web Statistics

slide-27
SLIDE 27

Ongoing and Future Work

Performance evaluation & optimization

  • Measure controller response time and network throughput
  • Wildcard rules and proactive rule installation
  • Support for parallelism

Program Analysis

  • Establish key invariants

Hosts and Services

  • Extend queries & controls to end hosts

More abstractions

  • Virtual network topologies
  • Network updates with improved semantics

25

slide-28
SLIDE 28

Conclusion: An Analogy

26

Concern Assembly Languages Programming Languages x86 NOX Haskell/ML Frenetic++ Resource Allocation Move values to/from registers Install/ uninstall rules

  • n switches

Declare/use program variables Construct/ register policy Resource Tracking Have I spilled that value? Will that packet arrive at the controller? Program variables always accessible Queries can read every packet Coordination Unregulated calling conventions Unregulated rule installation Function calls managed automatically Policies managed automatically Portability Hardware Dependent Hardware Dependent Hardware Independent Hardware Independent

slide-29
SLIDE 29

The Team

Mike Freedman Chris Monsanto Jen Rexford Rob Harrison Dave Walker Nate Foster Alec Story

http://frenetic-lang.org

slide-30
SLIDE 30

Implementation Options

Rule Granularity

  • microflow (exact header match)

– simpler; more rules generated

  • wildcard (multiple header match in single rule)

– more complex; fewer rules (may be) generated

Rule Installation

  • reactive (lazy)

– first packet of each new flow goes to controller

  • proactive (eager)

– new rules pushed to switches

20

Frenetic 1.0 Frenetic 2.0