Slide 1

Handout # 6:Programming Software-Defined NetworksProfessor Yashar GanjaliDepartment of Computer ScienceUniversity of Toronto

yganjali@cs.toronto.eduhttp://www.cs.toronto.edu/~yganjaliCSC 2229 Software-Defined NetworkingSome slides courtesy of J. Rexford (Princeton), N. Foster (Cornell) and N. Feamster (Georgia Tech), all used with permission.

1AnnouncementsFinal project proposal2 pagesDue: Fri. Oct. 9th (5PM)

In class presentationsBooked for next weekEmail me if you want to be next

CSC 2229 - Software-Defined Networking2University of Toronto Fall 20152Programming SDNsThe GoodNetwork-wide visibilityDirect control over the switchesSimple data-plane abstraction

The BadLow-level programming interfaceFunctionality tied to hardwareExplicit resource control

The UglyNon-modular, non-compositionalChallenging distributed programming

Images by Billy PerkinsCSC 2229 - Software-Defined NetworkingUniversity of Toronto Fall 20153Programming OpenFlow is Not EasyOpenFlow and NOX now make it possible to implement exciting new network servicesUnfortunately, they do not make it easy.

Combining different applications is not straightforward

OpenFlow provides a very low level abstraction

We have a two-tier architecture

Network of switches is susceptible to race conditionsCSC 2229 - Software-Defined Networking4University of Toronto Fall 2015Programming OpenFlow is Not EasyOpenFlow and NOX now make it possible to implement exciting new network servicesUnfortunately, they do not make it easy.

Combining different applications is not straightforward

OpenFlow provides a very low level abstraction

We have a two-tier architecture

Network of switches is susceptible to race conditionsCSC 2229 - Software-Defined Networking5University of Toronto Fall 2015Problem 1: Anti-ModularityCombining different applications is challenging

Example: monitor + route + firewall + load balancingHow these applications will work together?How are messages from switches delivered to these applicationsHow are messages from these apps aggregated to be sent to switches?Do OpenFlow and NOX provide a way for each app to perform its job without impacting other apps?

Question: How can we combine these applications?CSC 2229 - Software-Defined Networking6University of Toronto Fall 2015Combining Many Networking TasksCSC 2229 - Software-Defined Networking7University of Toronto Fall 2015Controller PlatformMonitor + Route + FW + LBMonolithic applicationHard to program, test, debug, reuse, port, But, real networks perform a wide variety of tasksRouting, network monitoring, firewalls, server load balancing, etc.7Modular Controller ApplicationsCSC 2229 - Software-Defined Networking8University of Toronto Fall 2015LBRouteMonitorFWEasier to program, test, and debugGreater reusability and portabilityA module for each taskController Platform8Beyond Multi-TenancyCSC 2229 - Software-Defined Networking9University of Toronto Fall 2015Slice 1Slice 2Slice N... Each module controls a different portion of the trafficRelatively easy to partition rule space, link bandwidth, and network events across modulesController PlatformSimple case: multi-tenancyEach module controls a different subset of the trafficRelatively easy to partition traffic, rule space, and bandwidth resources

We want to write a single application out of modules that affect the handling of same traffic9Modules Affect the Same TrafficCSC 2229 - Software-Defined Networking10University of Toronto Fall 2015How to combine modules into a complete application?Each module partially specifies the handling of the trafficController PlatformLBRouteMonitorFW10Consider a simple network

Anti-Modularity ExampleCSC 2229 - Software-Defined Networking11University of Toronto Fall 2015Want to add two applications

Simple repeaterPort 1 Port 2Port 2 Port 1

Web monitorPacket and byte countsIncoming web traffic

Events: switch_join(switch): triggered when switch joins the networkstats_in(switch , xid , pattern , packets , bytes ), triggered when switch returns the packets and bytes counters in response to a request for statistics about rules contained in pattern

Commands:install(switch, pattern, priority, timeout, actions): installs a rule in the flow table of switchquery_stats(switch, pattern): issues a request for statistics from all rules contained in pattern on switch

NOX Events and CommandsCSC 2229 - Software-Defined Networking12University of Toronto Fall 2015Anti-Modularity Example

CSC 2229 - Software-Defined Networking13University of Toronto Fall 2015

Overlapping rules- repeater first: no counting web traffic- Monitor first: no repeatingAnti-Modularity Example

CSC 2229 - Software-Defined Networking14University of Toronto Fall 2015Programming OpenFlow is Not EasyOpenFlow and NOX now make it possible to implement exciting new network servicesUnfortunately, they do not make it easy.

Combining different applications is not straightforward

OpenFlow provides a very low level abstraction

We have a two-tier architecture

Network of switches is susceptible to race conditionsCSC 2229 - Software-Defined Networking15University of Toronto Fall 2015Problem 2: Low-Level APIOpenFlow is a low level programming interfaceDerived from the features of the switch hardwareRather than ease of use

Programmer must describe low-level details that do not affect the overall behavior of the program

Example: to implement simple set difference we requireMultiple rulesPrioritiesAll need to be managed by the programmer

Focusing on the big picture not easyCSC 2229 - Software-Defined Networking16University of Toronto Fall 2015Low-Level API ExampleExtend the repeater and monitoring Monitor all incoming web traffic except traffic destined to 10.0.0.9 (on internal network)We need to express a logical difference of patternsOpenFlow can only express positive constraints CSC 2229 - Software-Defined Networking17University of Toronto Fall 2015

Programming OpenFlow is Not EasyOpenFlow and NOX now make it possible to implement exciting new network servicesUnfortunately, they do not make it easy.

Combining different applications is not straightforward

OpenFlow provides a very low level abstraction

We have a two-tier architecture

Network of switches is susceptible to race conditionsCSC 2229 - Software-Defined Networking18University of Toronto Fall 2015Problem 3: Two-Tiered SystemControl program manages networks by Installing/uninstalling switch-level rules

Programmer needs to specify communication patterns between controller and switchesDeal with tricky concurrency issues

Controller does not have full visibilitySees only packets that the switches do not know how to handle.Previously installed rulesReduce the load on the controller Make it difficult to reason

Detour: proactive vs. reactive rule installation

CSC 2229 - Software-Defined Networking19University of Toronto Fall 2015Two-Tiered Programming ExampleExtending the original repeater Monitor the total amount of incoming trafficBy destination host

Cannot install all of the rules we need in advanceAddress of each host is unknown a priori

The controller must dynamically install rules for the packets seen at run time

CSC 2229 - Software-Defined Networking20University of Toronto Fall 2015Two-Tiered Programming ExampleTwo programs depended on each otherComplex concurrency issues can ariseReading/understanding the code is difficultDetails are sources of significant distractionCSC 2229 - Software-Defined Networking21University of Toronto Fall 2015

Programming OpenFlow is Not EasyOpenFlow and NOX now make it possible to implement exciting new network servicesUnfortunately, they do not make it easy.

Combining different applications is not straightforward

OpenFlow provides a very low level abstraction

We have a two-tier architecture

Network of switches is susceptible to race conditionsCSC 2229 - Software-Defined Networking22University of Toronto Fall 2015

Problem 4: Race ConditionsRace conditions can cause complicationsWe have a distributed systemOf switchesAnd controllers

Example 1: rule install delayOne new flowMultiple packets

CSC 2229 - Software-Defined Networking23University of Toronto Fall 2015Race Conditions ExampleExample 2: firewall applicationRunning on multiple switchesAllow A initiate a flow to BTwo way But, block flows started by B

CSC 2229 - Software-Defined Networking24University of Toronto Fall 2015

Race Conditions ExampleExample 2: firewall applicationRunning on multiple switchesAllow A initiate a flow to BTwo way But, block flows started by B

CSC 2229 - Software-Defined Networking25University of Toronto Fall 2015

Northbound APIProgramming abstraction for applicationsHides low-level detailsHelps orchestrate and combine applications

Example usesPath computationLoop avoidanceRoutingSecurity

CSC 2229 - Software-Defined Networking26University of Toronto Fall 2015

Northbound APISouthbound APIWho Will Use the Northbound API?Service providersSophisticated network operatorsOr, enthusiastic network administratorsVendorsResearchersOr anyone who wants to add new capabilities to their network

CSC 2229 - Software-Defined Networking27University of Toronto Fall 2015Benefits of the Northbound APIVendor independenceAbility to quickly modify or customize control applications through simple programming

Example applications:Large virtual switchSecurity applicationsResource management and controlMiddlebox integration

CSC 2229 - Software-Defined Networking28University of Toronto Fall 2015Frenetic LanguageDeclarative DesignWhat the programmer might wantRather than how the hardware implements it. Modular DesignPrimitives have limited network-wide effects and semantics Independent of the context in which they are used.Single-tier ProgrammingSee-every-packet abstractionRace-free SemanticsAutomatic race detection and packet suppressionCost controlCore query logic can be executed on network switches

CSC 2229 - Software-Defined Networking29University of Toronto Fall 2015Network Control LoopCSC 2229 - Software-Defined NetworkingUniversity of Toronto Fall 2015ReadstateOpenFlowSwitchesWritepolicyCompute Policy3030Language-Based AbstractionsQuery abstractionsOpenFlowSwitchesUpdate abstractionsWriting/combining modulesUniversity of Toronto Fall 2015CSC 2229 - Software-Defined Networking3131Frenetic LanguageAbstractions for querying network state An integrated query languageSelect, filter, group, sample sets of packets or statisticsDesigned 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 policiesTransform, split, merge, filter policies and other streams

ImplementationA collection of Python libraries on top of NOX

CSC 2229 - Software-Defined Networking32University of Toronto Fall 2015Frenetic QueriesCSC 2229 - Software-Defined Networking33University of Toronto Fall 2015

Frenetic QueriesCSC 2229 - Software-Defined Networking34University of Toronto Fall 2015

Policy in OpenFlowDefining policy is complicatedAll rules in all switchesPacket-in handlersPolling of countersProgramming policy is error-proneDuplication between rules and handlersFrequent changes in policy (e.g., flowmods)Policy changes affect packets in flight

CSC 2229 - Software-Defined Networking35University of Toronto Fall 2015Frenetic Forwarding PoliciesCSC 2229 - Software-Defined Networking36University of Toronto Fall 2015Rules are created using the Rule Constructor, which takes a pattern and a list of actions as arguments

Network policies associate rules with switchesDictionaries mapping switches to list of rules

Policy events are infinite, time-indexed streams of values, just like the events generated from queriesPrograms control the installation of policies in a network over time by generating policy eventsListeners are event consumersPrint: send to consoleSend: transfer packet to switch and apply actionsRegister: apply network wide policy

Power of Policy as a FunctionCompositionParallel: Monitor + RouteSequential: Firewall >> RouteA >> (B + C) >> D(A >> P) + (B >> P) (A + B)>>PCSC 2229 - Software-Defined Networking37University of Toronto Fall 2015Frenetic Forwarding Policies

CSC 2229 - Software-Defined Networking38University of Toronto Fall 2015Parallel CompositionCSC 2229 - Software-Defined Networking39University of Toronto Fall 2015Route on destinationMonitor on source+dstip = 1.2.3.4 fwd(1)dstip = 3.4.5.6 fwd(2)srcip = 5.6.7.8 countController PlatformFrom ICFP11 and POPL1239Parallel CompositionCSC 2229 - Software-Defined Networking40University of Toronto Fall 2015Route on destinationMonitor on source+dstip = 1.2.3.4 fwd(1)dstip = 3.4.5.6 fwd(2)srcip = 5.6.7.8 countsrcip = 5.6.7.8, dstip = 1.2.3.4 fwd(1), countsrcip = 5.6.7.8, dstip = 3.4.5.6 fwd(2), countsrcip = 5.6.7.8 countdstip = 1.2.3.4 fwd(1)dstip = 3.4.5.6 fwd(2)Controller PlatformFrom ICFP11 and POPL1240Sequential CompositionCSC 2229 - Software-Defined Networking41University of Toronto Fall 2015RoutingLoad Balancer>>dstip = 10.0.0.1 fwd(1)dstip = 10.0.0.2 fwd(2)srcip = 0*, dstip=1.2.3.4 dstip=10.0.0.1srcip = 1*, dstip=1.2.3.4 dstip=10.0.0.2Controller PlatformLoad balancer splits traffic sent to public IP address over multiple replicas, based on client IP address, and rewrites the IP address41Sequential CompositionCSC 2229 - Software-Defined Networking42University of Toronto Fall 2015RoutingLoad Balancer>>dstip = 10.0.0.1 fwd(1)dstip = 10.0.0.2 fwd(2)srcip = 0*, dstip=1.2.3.4 dstip=10.0.0.1srcip = 1*, dstip=1.2.3.4 dstip=10.0.0.2srcip = 0*, dstip = 1.2.3.4 dstip = 10.0.0.1, fwd(1)srcip = 1*, dstip = 1.2.3.4 dstip = 10.0.0.2, fwd(2)Controller PlatformLoad balancer splits traffic sent to public IP address over multiple replicas, based on client IP address, and rewrites the IP address42Dividing the Traffic Over ModulesPredicatesSpecify which traffic traverses which modulesBased on input port and packet-header fieldsCSC 2229 - Software-Defined Networking43University of Toronto Fall 2015RoutingLoad BalancerMonitorRoutingNon-webdstport != 80Web trafficdstport = 80>>+Program Composition

CSC 2229 - Software-Defined Networking44University of Toronto Fall 2015Frenetic Runtime System

CSC 2229 - Software-Defined Networking45University of Toronto Fall 2015