High-Level Abstractions for Programming Software Defined Networks - PowerPoint PPT Presentation

High level abstractions for programming software defined networks
1 / 48

  • Uploaded on
  • Presentation posted in: General

High-Level Abstractions for Programming Software Defined Networks. Jennifer Rexford Princeton University http:// www.cs.princeton.edu /~ jrex. Joint with Nate Foster, David Walker, Arjun Guha , Rob Harrison, Chris Monsanto, Joshua Reich, Mark Reitblatt , Cole Schlesinger.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

Download Presentation

High-Level Abstractions for Programming Software Defined Networks

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

High level abstractions for programming software defined networks

High-Level Abstractions for Programming Software Defined Networks

Jennifer Rexford

Princeton University


Joint with Nate Foster, David Walker, ArjunGuha, Rob Harrison, Chris Monsanto, Joshua Reich, Mark Reitblatt, Cole Schlesinger

Software defined networks

Software Defined Networks

Software defined networks1

Software Defined Networks

decouple control and data planes

Software defined networks2

Software Defined Networks

decouple control and data planesby providing open standard API

Logically centralized controller

(Logically) Centralized Controller

Controller Platform

Protocols applications

Protocols  Applications

Controller Application

Controller Platform



  • Cheaper equipment

  • Faster innovation

  • Easier management

But how should we program sdns

But How Should We Program SDNs?

Network-wide visibility and control

Controller Application

Controller Platform

Direct control via open interface

Today’s controller APIs are tied to the underlying hardware

Openflow networks

OpenFlow Networks

Data plane packet handling

Data Plane: Packet Handling

  • Simple packet-handling rules

    • Pattern: match packet header bits

    • Actions: drop, forward, modify, send to controller

    • Priority: disambiguate overlapping patterns

    • Counters: #bytes and #packets

  • src=1.2.*.*, dest=3.4.5.*  drop

  • src = *.*.*.*, dest=3.4.*.*  forward(2)

  • 3. src=, dest=*.*.*.*  send to controller

Control plane programmability

Control Plane: Programmability

Controller Application

Controller Platform

Events from switches

Topology changes,

Traffic statistics,

Arriving packets

Commands to switches

(Un)install rules,

Query statistics,

Send packets

E g server load balancing

E.g.: Server Load Balancing

  • Pre-install load-balancing policy

  • Split traffic based on source IP



Seamless mobility migration

Seamless Mobility/Migration

  • See host sending traffic at new location

  • Modify rules to reroute the traffic

Programming abstractions for software defined networks

Programming Abstractions for Software Defined Networks

Network control loop

Network Control Loop

Compute Policy







Reading state

Reading State

SQL-Like Query Language

Reading state multiple rules

Reading State: Multiple Rules

  • Traffic counters

    • Each rule counts bytes and packets

    • Controller can poll the counters

  • Multiple rules

    • E.g., Web server traffic except for source

  • Solution: predicates

    • E.g., (srcip != && (srcport == 80)

    • Run-time system translates into switch patterns

1. srcip =, srcport = 80

2. srcport = 80

Reading state unfolding rules

Reading State: Unfolding Rules

  • Limited number of rules

    • Switches have limited space for rules

    • Cannot install all possible patterns

  • Must add new rules as traffic arrives

    • E.g., histogram of traffic by IP address

    • … packet arrives from source

  • Solution: dynamic unfolding

    • Programmer specifies GroupBy(srcip)

    • Run-time system dynamically adds rules

1. srcip =

2. srcip =

1. srcip =

Reading extra unexpected events

Reading: Extra Unexpected Events

  • Common programming idiom

    • First packet goes to the controller

    • Controller application installs rules


Reading extra unexpected events1

Reading: Extra Unexpected Events

  • More packets arrive before rules installed?

    • Multiple packets reach the controller


Reading extra unexpected events2

Reading: Extra Unexpected Events

  • Solution: suppress extra events

    • Programmer specifies “Limit(1)”

    • Run-time system hides the extra events

not seen by



Frenetic sql like query language

Frenetic SQL-Like Query Language

  • Get what you ask for

    • Nothing more, nothing less

  • SQL-like query language

    • Familiar abstraction

    • Returns a stream

    • Intuitive cost model

  • Minimize controller overhead

    • Filter using high-level patterns

    • Limit the # of values returned

    • Aggregate by #/size of packets

Traffic Monitoring

Select(bytes) *

Where(in:2 & srcport:80) *

GroupBy([dstmac]) *


Learning Host Location

Select(packets) *

GroupBy([srcmac]) *

SplitWhen([inport]) *


Computing policy

Computing Policy

Parallel and Sequential Composition

Abstract Topology Views

Combining many networking tasks

Combining Many Networking Tasks

Monolithic application

Monitor + Route + FW + LB

Controller Platform

Hard to program, test, debug, reuse, port, …

Modular controller applications

Modular Controller Applications

A module for each task





Controller Platform

Easier to program, test, and debug

Greater reusability and portability

Beyond multi tenancy

Beyond Multi-Tenancy

Each module controls a different portion of the traffic


Slice 2

Slice n

Slice 1

Controller Platform

Relatively easy to partition rule space, link bandwidth, and network events across modules

Modules affect the same traffic

Modules Affect the Same Traffic

Each module partially specifies the handling of the traffic





Controller Platform

How to combine modules into a complete application?

Parallel composition icfp 11 popl 12

Parallel Composition [ICFP’11, POPL’12]

srcip =  count

srcip =  count

dstip = 1.2/16  fwd(1)

dstip = 3.4.5/24  fwd(2)

Route on destprefix

Monitor on source IP


Controller Platform

srcip =, dstip = 1.2/16  fwd(1), count

srcip =, dstip = 3.4.5/24  fwd(2), count

srcip =, dstip = 1.2/16  fwd(1), count

srcip =, dstip = 3.4.5/24  fwd(2), count

Example server load balancer

Example: Server Load Balancer

  • Spread client traffic over server replicas

    • Public IP address for the service

    • Split traffic based on client IP

    • Rewrite the server IP address

  • Then, route to the replica


load balancer

server replicas

Sequential composition nsdi 13

Sequential Composition [NSDI’13]

srcip = 0*, dstip=  dstip=

srcip = 1*, dstip=  dstip=

dstip =  fwd(1)

dstip =  fwd(2)


Load Balancer


Controller Platform

srcip = 0*, dstip =  dstip=, fwd(1)

srcip = 1*, dstip =  dstip =, fwd(2)

Dividing the traffic over modules

Dividing the Traffic Over Modules

  • Predicates

    • Specify which traffic traverses which modules

    • Based on input port and packet-header fields




dstport != 80


Load Balancer


dstport = 80

High level architecture

High-Level Architecture


Composition Spec



Controller Platform

Partially specifying functionality

Partially Specifying Functionality

  • A module should not specify everything

    • Leave some flexibility to other modules

    • Avoid tying the module to a specific setting

  • Example: load balancer plus routing

    • Load balancer spreads traffic over replicas

    • … without regard to the network paths


Load Balancer


Avoid custom interfaces between the modules

Abstract topology views nsdi 13

Abstract Topology Views [NSDI’13]

  • Present abstract topology to the module

    • Implicitly encodes the constraints

    • Looks just like a normal network

    • Prevents the module from overstepping

Real network

Abstract view


Separation of concerns

Separation of Concerns

  • Hide irrelevant details

    • Load balancer doesn’t see the internal topology or any routing changes

Routing view

Load-balancer view

High level architecture1

High-Level Architecture

View Definitions


Composition Spec



Controller Platform

Supporting topology views

Supporting Topology Views

  • Virtual ports

    • (V, 1): [(P1,2)]

    • (V, 2): [(P2, 5)]

  • Simple firewall policy

    • in=1 out=2

  • Virtual headers

    • Push virtual ports

    • Route on these ports

    • From (P1,2) to (P2,5)

















Writing state

Writing State

Consistent Updates

Writing policy avoiding disruption

Writing Policy: Avoiding Disruption

  • Invariants

  • No forwarding loops

  • No black holes

  • Access control

  • Traffic waypointing

Writing policy path for new flow

Writing Policy: Path for New Flow

  • Rules along a path installed out of order?

    • Packets reach a switch before the rules do


Must think about all possible packet and event orderings.

Writing policy update semantics

Writing Policy: Update Semantics

  • Per-packet consistency

    • Every packet is processed by

    • … policy P1 or policy P2

    • E.g., access control, no loopsor blackholes

  • Per-flow consistency

    • Sets of related packets are processed by

    • … policy P1 or policy P2,

    • E.g., server load balancer, in-order delivery, …



Writing policy policy update

Writing Policy: Policy Update

  • Simple abstraction

    • Update entire configuration at once

  • Cheap verification

    • If P1 and P2 satisfy an invariant

    • Then the invariant always holds

  • Run-time system handles the rest

    • Constructing schedule of low-level updates

    • Using only OpenFlow commands!



Writing policy two phase update

Writing Policy: Two-Phase Update

  • Version numbers

    • Stamp packet with a version number (e.g., VLAN tag)

  • Unobservable updates

    • Add rules for P2 in the interior

    • … matching on version # P2

  • One-touch updates

    • Add rules to stamp packets with version # P2 at the edge

  • Remove old rules

    • Wait for some time, thenremove all version # P1 rules

Writing policy optimizations

Writing Policy: Optimizations

  • Avoid two-phase update

    • Naïve version touches every switch

    • Doubles rule space requirements

  • Limit scope

    • Portion of the traffic

    • Portion of the topology

  • Simple policy changes

    • Strictly adds paths

    • Strictly removes paths

Frenetic abstractions

Frenetic Abstractions

Policy Composition






Related work

Related Work

  • Programming languages

    • FRP: Yampa, FrTime, Flask, Nettle

    • Streaming: StreamIt, CQL, Esterel, Brooklet, GigaScope

    • Network protocols: NDLog

  • OpenFlow

    • Language: FML, SNAC, Resonance

    • Controllers: ONIX, POX, Floodlight, Nettle, FlowVisor

    • Testing: NICE, FlowChecker, OF-Rewind, OFLOPS

  • OpenFlowstandardization

    • http://www.openflow.org/

    • https://www.opennetworking.org/



  • SDN is exciting

    • Enables innovation

    • Simplifies management

    • Rethinks networking

  • SDN is happening

    • Practice: useful APIs and good industry traction

    • Principles: start of higher-level abstractions

  • Great research opportunity

    • Practical impact on future networks

    • Placing networking on a strong foundation

Frenetic project

Frenetic Project

  • Programming languages meets networking

    • Cornell: Nate Foster, Gun Sirer, ArjunGuha, Robert Soule, ShrutarshiBasu, Mark Reitblatt, Alec Story

    • Princeton: Dave Walker, Jen Rexford, Josh Reich, Rob Harrison, Chris Monsanto, Cole Schlesinger, Praveen Katta, NaydenNedev


Short overview at http://www.cs.princeton.edu/~jrex/papers/frenetic12.pdf

  • Login