1 / 43

Reasoning about Software Defined Networks

Reasoning about Software Defined Networks. Mooly Sagiv msagiv@acm.org 03-640-7606 Tel Aviv University Thursday 16-18 (Physics 105) Monday 14-16 Schrieber 317 Adviser: Michael Shapira Hebrew University. http://www.cs.tau.ac.il/~msagiv/courses/rsdn.html. Content. Challenges in SDNs

apu
Download Presentation

Reasoning about 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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Reasoning about Software Defined Networks MoolySagiv msagiv@acm.org 03-640-7606 Tel Aviv University Thursday 16-18 (Physics 105) Monday 14-16 Schrieber 317 Adviser: Michael Shapira Hebrew University http://www.cs.tau.ac.il/~msagiv/courses/rsdn.html

  2. Content • Challenges in SDNs • Programming Language Abstractions • Programming Language Principles • Program Language Tools • Other useful tools Beyond SDNs

  3. Challenges in SDN • Programming complexity • Modularity • Composing operations • Handling Updates • Reliability • Performance • Testing • Productivity • Non-expert programmers

  4. How hard is it to program networks • Routers with 20+ million lines of code • Cascading failures, vulnerabilities, etc • Low level programming • No abstractions • Virtual memory • Operating Systems • Resource Allocations • Libraries • Types

  5. Modularity: Simple Repeater Simple Repeater def repeater(switch): # Repeat Port 1 to Port 2 pat1 = {in_port:1} act1 = [forward(2)] install(switch, pat1, DEFAULT, act1) # Repeat Port 2 to Port 1 pat2 = {in_port:2} act2 = [forward(1)] install(switch, pat2, DEFAULT, act2) Controller 1 2 When a switch joins the network, install two forwarding rules.

  6. Composition: Web Traffic Monitor Monitor Web (“port 80”) traffic def web_monitor(switch)): # Web traffic from Internet pat = {inport:2,tp_src:80} install(switch, pat, DEFAULT, []) query_stats(switch, pat) def stats_in(switch, pat, bytes, …) print bytes sleep(30) query_stats(switch, pat) 1 2 Web traffic When a switch joins the network, install one monitoring rule.

  7. Composition: Repeater + Monitor Repeater + Monitor def switch_join(switch): pat1 = {inport:1} pat2 = {inport:2} pat2web = {in_port:2, tp_src:80} install(switch, pat1, DEFAULT, None, [forward(2)]) install(switch, pat2web, HIGH, None, [forward(1)]) install(switch, pat2, DEFAULT, None, [forward(1)]) query_stats(switch, pat2web) def stats_in(switch, xid, pattern, packets, bytes): print bytes sleep(30) query_stats(switch, pattern) Must think about both tasks at the same time.

  8. Concurrency: Switch-Controller Delays • Common programming idiom • First packet goes to the controller • Controller installs rules packets

  9. Concurrency: Switch-Controller Delays • More packets arrive before rules installed? • Multiple packets reach the controller packets

  10. Concurrency: Switch-Controller Delays • Rules along a path installed out of order? • Packets reach a switch before the rules do packets Must think about all possible packet and event orderings.

  11. Debugging is hard[Kazemian’NSDI’13] • Distributed switch tables • Varied delays • Cascading effects on switch tables • Multiple protocols • Human interaction • …

  12. SDN Performance • Given an SDN controller code • Estimate the cost of routing per packet • Length of the path • Weight of the path • Number of controller interventions

  13. Programming Language Abstractions • Hide the implementation • Interpreter/Compiler guarantees performance • Benefits • Portability • Ease of use • Reliability • Compositionality • Productivity

  14. Language Abstractions • Procedures • Abstract data types • Objects • Resources • Memory management • Garbage collection • Control abstractions • Exceptions • Iterators • Tree Pattern Matching • Higher order functions • Continuation • Lazy evaluation • Monads • Libraries • Domain specific languages • Declarative programming

  15. Programming Language Principles • Rigorously define the meaning of programs • Supports abstraction • Prove compiler correctness • Prove that two SDN programs are observationally equivalent • The same packet transmissions

  16. A Simple Example • Numeric Expressions • <exp> ::= <exp> + <exp> | < exp> * <exp> | number • The semantic of expressions is a numberE: <exp> int • Inductively defined • En = n • Ee1+ e2 = Ee1 + Ee2 • Ee1* e2 = Ee1 * Ee2 • Compositional • Fully abstract • e1 e2iff Ee1 = Ee2 • 5 + 6  7 + 3 + 1

  17. A Simple Example + Var • Numeric Expressions • <exp> ::= <exp> + <exp> | <exp> * <exp> | number | id • Need to introduce statesVar Int • Examples • [x 2, y3] x = • [x 2, y3] z = 2 • [x 2, y3][z  5] = [x 2, y3,z  5] • [x 2, y3][x  5] = [x 5, y3] • [x 2, y3][x  5]x = 5 • [x 2, y3][x  5]y = 2

  18. A Simple Example + Var • Numeric Expressions • <exp> ::= <exp> + <exp> | <exp> * <exp> | number | id • The semantic of expressions is a function from states to numbersE: exp (Var Int)  Int • Inductively defined • En= n • Ee1+ e2 = Ee1+ Ee2 • Ee1* e2 = Ee1* Ee2 • Eid = id • Ex+2[x 5] =Ex[x 5] + E2 [x 5] = [x 5]x + 2 = 5 + 2 =7 • x + x  2 * x

  19. Benefits of formal semantics • Can be done for arbitrary languages • Automatically generate interpreters • Rational language design • Formal proofs of language properties • Observational equivalence • Type safety • Correctness of tools • Interpreter • Compiler • Static Analyzer • Model Checker

  20. A Simple Controller Language • No packet changes • No priorities • No statistics • Simple updates • Per-flow installation

  21. A Simple Controller Language • <controller> ::= <reld>* <evnt> • <reld> ::= rel <rid> (<tid>*) // auxiliary relations • <evnt> ::= packetIn (sid, pid, <pr>)  <com>* • <pr> ::= port(int) • <com> ::= send(<pr>) | install (sid, pid, <pr>, <opr>) // update flow table |id.insert(<pred>*) // update auxiliary relations| ifrid(<exp>*)then <com>* else <com>* | ifrid(<exp>*) then <com>* | <com> ; < com> • <opr> ::= <pr>|none // drop the package • <exp> ::= id | id (exp) | <pr>

  22. Learning Switch with 3 ports rel connected (Sw, Pr, Ho) PacketIn(s, p, port(1)) -> connected.insert (s, port(1), p.src) if connected(s, port(2), p.dst) then { send(s, p, port(2)) install(s, p, port(1), port(2)) } else if connected(s, port(3), p.dst) then { send (port(3)) install(s, p, port(1), port(3)) } else { // flood send (port(2)) send (port(3)) } PacketIn(s, p, port(2)) -> … PacketIn(s, p, port(3)) -> …

  23. The semantics of the controller • What is the meaning of package sent by a given host? • A set of paths • Example: Learning Switch  1 a   2 3

  24. The semantics of the controller • What is the meaning of package sent by a given host? • A set of paths • Dynamically changed • Even for fixed topology • Unbounded length • But can it be defined?

  25. The State of a switch • The switch table is a relation on ports • FT= Sw  P(Pk Pr  Pr  {none}) • Updated by the controller • Actual nodes depend on the topology graph input port output port

  26. The Semantics of Expressions • <exp> ::= id | id (exp) | <Pr> • Val = Int Pr {P(Tt1  …Ttk | t1, …, tkare valid types} • Controller State  such that : Var  Val • E id   =  id • Eid(e)  =Fid (Ee) • Eport(n) = n

  27. The Meaning of Commands • <com> ::= send(<pr>) | install (<pr>, <opr>) |id.insert(<exp>*) | ifRID(<exp>*)then <com>* else <com>* | ifRID(<exp>*) then <com>* | <com> ; < com> • <opr> ::= <pr>|none • C: <com> (Sw  Pk  Pr)  (  FT)  (  FT P(Pr {none}) input-state output event

  28. Atomic Commands • Csend(pr)sw, pk, ip , ft = , ft, {Epr}  • Cinstall(s, p, prin,prout)sw, pk, ip , ft = , ft  {pk, Eprin, Eprout},  • Cr.insert(e) sw, pk, ip , ft = [r  r  { Ee}], ft, 

  29. Conditional Commands • Cif r(e) then c1else c2 ev , ft = C c1 ev , ft If Ee  r C c2 ev , ft If Ee  r

  30. Sequential Composition • Cc1 ; c2 ev , ft = let ’, ft’, prs1 = Cc1ev , ft ”, ft”, prs2 = Cc2ev ’, ft’ in ”, ft”, prs1 prs2

  31. Semantics of Events • G: <evnt>  (Sw  Pk  Pr)  P((  FT)  (  FT  P(Pr {none})) • GpacketIn(s, p, i)  c sw, pk, ip = Rwhere , ft R ’, ft’, ports iff ip = Ei  (op : Pr. pk, ip, op  ft)  Cc sw, pk, ip [ssw, ppk], ft = ’, ft’, sp

  32. System State • Comprises of: • Single state of the controller • Flow-table for each switch • FTS = Sw  FT

  33. Packet Histories • Packets can influence the routing of other packets • Histories can be seen as sequences of packet transmissions • HST= (SW  PR  PK  (PR  {none}))*

  34. Small-step semantics (Controller) • ctrl : (  FTS  HST)  (  FTS  HST) • , fts, h ctrl ’, fts’, h’ iff sw : Sw, pk : Pk, ip : Pr, sp : P(Pr), ft’ : FT . , ftssw (Gevnt sw, pk, ip) ’, ft’, sp fts’ = fts[sw ft’]  h’ = h  sw, ip, pk, jj sp or (sp =  and j=none)

  35. Small-step Semantics (Switch) • sw : (  FTS  HST)  (  FTS  HST) • , fts, h sw ’, fts’, h’ iff =’ fts=fts’  sw : Sw, pk : Pk, ip : Pr, op : Pr  {none}. pk, ip, op  ftssw  h’ = h  sw, ip, pk, op

  36. Executions • Combined step semantics: • = ctrl  sw • A sequence of event processing steps has the from • a1  a2  …  an

  37. Feasible Histories • Given a topology graph G over V = Ho  (Sw  Pr) • A history h is feasibleiff for any packet pk  Pk, • any two consecutive entries for p in h: • sw1, ip1, pk, op1 and sw2, ip2, pk, op2 • there exists an edge between sw1, op1and sw2, ip2

  38. Example  connected = 1 a   2 3

  39. Example  connected = 1 a   2 3

  40.  •  Example  connected = 1 a   2 3

  41.  •  Example   connected = 1 a   2 3 

  42. Useful Programming Language Tools • Interpreter • Compiler • Parser • Type Checker • Static Program Analysis • Verification Tool • Dynamic Program Analysis • Model checker

  43. Interesting Network Properties

More Related