Reasoning about - PowerPoint Presentation

Slide1

Reasoning about Software Defined Networks

Mooly Sagivmsagiv@acm.org03-640-7606Tel Aviv UniversityThursday 16-18 (Physics 105)Monday 14-16 Schrieber 317Adviser: Michael ShapiraHebrew University

http://www.cs.tau.ac.il/~msagiv/courses/rsdn.htmlSlide2

ContentChallenges in SDNs

Programming Language AbstractionsProgramming Language TechniquesProgram Language Tools Other useful tools Slide3

Challenges in SDNProgramming complexity

ReliabiltySlide4

The Internet: A Remarkable Story

Tremendous successFrom research experiment to global infrastructureBrilliance of under-specifyingNetwork: best-effort packet deliveryHosts: arbitrary applicationsEnables innovation in applicationsWeb, P2P, VoIP, social networks, virtual worldsBut, change is easy only at the edge… 4Slide5

Inside the ‘Net: A Different Story…

Closed equipmentSoftware bundled with hardwareVendor-specific interfacesOver specifiedSlow protocol standardizationFew people can innovateEquipment vendors write the codeLong delays to introduce new features5

Impacts performance, security, reliability, cost…Slide6

Do We Need Innovation Inside?

6Many boxes (routers, switches, firewalls, …), with different interfaces.Slide7

How Hard are Networks to Manage?

Operating a network is expensiveMore than half the cost of a networkYet, operator error causes most outagesBuggy software in the equipmentRouters with 20+ million lines of codeCascading failures, vulnerabilities, etc.The network is “in the way”Especially a problem in data centers… and home networks7Slide8

Creating Foundation for Networking

A domain, not a disciplineAlphabet soup of protocolsHeader formats, bit twiddlingPreoccupation with artifactsFrom practice, to principlesIntellectual foundation for networkingIdentify the key abstractions… and support them efficientlyTo build networks worthy of society’s trust8Slide9

Rethinking the “Division of Labor”

9Slide10

Traditional Computer Networks

10

Data plane:

Packet streaming

Forward, filter, buffer, mark,

rate-limit, and measure packetsSlide11

Traditional Computer Networks

11

Track topology changes, compute routes, install forwarding rules

Control plane:

Distributed algorithmsSlide12

Traditional Computer Networks

12

Collect measurements and configure the equipment

Management plane:

Human time scaleSlide13

Shortest-Path RoutingManagement

: set the link weightsControl: compute shortest pathsData: forward packets to next hop13

1

1

3

1

1Slide14

Shortest-Path RoutingManagement

: set the link weightsControl: compute shortest pathsData: forward packets to next hop14

1

1

3

1

1Slide15

Inverting the Control PlaneTraffic engineering

Change link weights… to induce the paths… that alleviate congestion15

5

1

3

1

1Slide16

Avoiding Transient AnomaliesDistributed protocol

Temporary disagreement among the nodes… leaves packets stuck in loopsEven though the change was planned!16

1



5

1

3

1

1Slide17

Death to the Control Plane!Simpler management

No need to “invert” control-plane operationsFaster pace of innovationLess dependence on vendors and standardsEasier interoperabilityCompatibility only in “wire” protocolsSimpler, cheaper equipmentMinimal software17Slide18

Software Defined Networking (SDN)

18

API to the data plane

(e.g., OpenFlow)

Logically-centralized control

Switches

Smart,

slow

Dumb,

fastSlide19

OpenFlow Networks

19Slide20

Data-Plane: Simple Packet HandlingSimple packet-handling rules

Pattern: match packet header bitsActions: drop, forward, modify, send to controller Priority: disambiguate overlapping patternsCounters: #bytes and #packets20src=1.2.*.*, dest=3.4.5.*  drop src = *.*.*.*, dest=3.4.*  forward(2)3. src=10.1.2.3, dest=*.*.*.*  send to controllerSlide21

Controller: Programmability

21Network OSApp #1App #2

App #3

Events from switches

Topology changes,

Traffic statistics,

Arriving packets

Commands to switches

(Un)install rules,

Query statistics,

Send packetsSlide22

OpenFlow in the Wild

Open Networking FoundationCreating Software Defined Networking standardsGoogle, Facebook, Microsoft, Yahoo, Verizon, Deutsche Telekom, and many other companiesCommercial OpenFlow switchesHP, NEC, Quanta, Dell, IBM, Juniper, …Network operating systemsNOX, Beacon, Floodlight, Nettle, ONIX, POX, FreneticNetwork deploymentsEight campuses, and two research backbone networksCommercial deployments22Slide23

Dynamic Access Control

Inspect first packet of each connectionConsult the access control policyInstall rules to block or route traffic23Slide24

Seamless Mobility/Migration

See host sending traffic at new locationModify rules to reroute the traffic24Slide25

Example Applications

Dynamic access controlSeamless mobility/migrationServer load balancingUsing multiple wireless access pointsEnergy-efficient networkingAdaptive traffic monitoringDenial-of-Service attack detectionNetwork virtualization25See http://www.openflow.org/videos/Slide26

Challenges of Programming Software Defined Networks

26Slide27

Programming OpenFlow Networks

OpenFlow makes programming possibleNetwork-wide view at controllerDirect control over data planeThe APIs do not make it easyLow level of abstractionChallengesCompositionConcurrencyCorrectnessTesting27Controller

SwitchesSlide28

A Simple example: FirewallA switch connected to two kind of hosts

Trusted hosts via port 1Untrusted hosts via port 2Trusted hosts can freely send packets to untrusted hostsAn unstrusted host can only send to a trusted destination which previously sent messages to this hostSlide29

Firewall

1

2Slide30

Firewall Controller Pseudo-code

rel trusted(SW, HO) packetIn(s, p, 1)  # packets from trusted hosts send(s, p, 2) # forward the packet to untrusted hosts trusted.insert(s, p.dst) # insert the target of p into trusted controller memory ft.insert(s, p, 1, 2) # insert a per-flow rule to forward future packets packetIn(s, p, 2) -> # packets from untrusted hosts if trusted(s, p.src) then { send(s, p, 1) # forward the packet to trusted hosts ft.insert

(s, p, 2, 1) # insert a per-flow rule to forward future packets

}Slide31

Firewall Controller Pseudo-code(2)

packetIn(s, p, 1)  # packets from trusted hosts send(s, p, 2) # forward the packet to untrusted hosts ft.insert(s, src:p.src, 1, 2) # insert a general rule to forward future packets ft.insert(s, dst:p.dst, 2, 1) # allow future packets from 2Slide32

A Learning Switch

Ttwo hosts (A & B) An OpenFlow switch with 3 portsHost A is connected to port 1and Host B is connected to port 2Gradually install forwarding rulesUpdate upon relocationHost ASwitch1

2

Host BSlide33

‘A’ sends a message to ‘B’

Host ASwitch12

Host B

TCP

syn

dst

=BSlide34

Forward to the Controller

Host ASwitch12

Host B

TCP

syn

dst

=B

3

send TCP

syn

dst

=B on port 2

send TCP

syn

dst

=B on port 3

learn that A is connected via port 1Slide35

‘B’ sends a message to ‘A’

Host ASwitch12

Host B

TCP

ack

dst

=ASlide36

Forward to the Controller

Host ASwitch12

Host B

TCP

ack

dst

=A

3

send TCP

ack

dst

=A on port 1

learn that B is connected via port 2

Install a rule to forward packets from B to A on port 1Slide37

‘A’ sends another message to ‘B’

Host ASwitch12

Host B

dst

=BSlide38

Forward to the Controller

Host ASwitch12

Host B

dst

=B

3

Send

dst

=B on port 2

Install a rule to forward packets from A to B to port 2Slide39

Learning Switch Pseudo-code

rel connected (SW, PR, HO)PacketIn(s, p, e) -> connect.insert (s, e, p.src) if connect(s, o, p.dst) then { send (s, p, o) ft.insert(s, p, e, o) } else foreach o in {1, 2, 3} – p # Flood send (s, p, o) Slide40

Reasoning about Programs

DebuggingTestingModel checkingProgramming language supportAbstractionCompositionEase of useProgram verificationAbstractionSlide41

Seminar BenefitsA cool topic

ReasoningCritically read an articleLearn to present an articleSlide42

Seminar RequirementsCompilers

Read an article (2 weeks)Prepare presentation (1 week)Participate in lectures Slide43

Tentative Schedule

October 24Michael Shapira Introduction to SDNOctober 31Mooly SagivIntroduction to Program ReasoningNovember 7??November 14??