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

wilton
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 Techniques • Program Language Tools • Other useful tools

  3. Challenges in SDN • Programming complexity • Reliabilty

  4. The Internet: A Remarkable Story • Tremendous success • From research experiment to global infrastructure • Brilliance of under-specifying • Network: best-effort packet delivery • Hosts: arbitrary applications • Enables innovation in applications • Web, P2P, VoIP, social networks, virtual worlds • But, change is easy only at the edge… 

  5. Inside the ‘Net: A Different Story… • Closed equipment • Software bundled with hardware • Vendor-specific interfaces • Over specified • Slow protocol standardization • Few people can innovate • Equipment vendors write the code • Long delays to introduce new features Impacts performance, security, reliability, cost…

  6. Do We Need Innovation Inside? Many boxes (routers, switches, firewalls, …), with different interfaces.

  7. How Hard are Networks to Manage? • Operating a network is expensive • More than half the cost of a network • Yet, operator error causes most outages • Buggy software in the equipment • Routers with 20+ million lines of code • Cascading failures, vulnerabilities, etc. • The network is “in the way” • Especially a problem in data centers • … and home networks

  8. Creating Foundation for Networking • A domain, not a discipline • Alphabet soup of protocols • Header formats, bit twiddling • Preoccupation with artifacts • From practice, to principles • Intellectual foundation for networking • Identify the key abstractions • … and support them efficiently • To build networks worthy of society’s trust

  9. Rethinking the “Division of Labor”

  10. Traditional Computer Networks Data plane: Packet streaming • Forward, filter, buffer, mark, • rate-limit, and measure packets

  11. Traditional Computer Networks Control plane: Distributed algorithms • Track topology changes, compute routes, install forwarding rules

  12. Traditional Computer Networks Management plane: Human time scale • Collect measurements and configure the equipment

  13. Shortest-Path Routing • Management: set the link weights • Control: compute shortest paths • Data: forward packets to next hop 1 1 1 1 3

  14. Shortest-Path Routing • Management: set the link weights • Control: compute shortest paths • Data: forward packets to next hop 1 1 1 1 3

  15. Inverting the Control Plane • Traffic engineering • Change link weights • … to induce the paths • … that alleviate congestion 5 1 1 1 3

  16. Avoiding Transient Anomalies • Distributed protocol • Temporary disagreement among the nodes • … leaves packets stuck in loops • Even though the change was planned! 1  5 1 1 1 3

  17. Death to the Control Plane! • Simpler management • No need to “invert” control-plane operations • Faster pace of innovation • Less dependence on vendors and standards • Easier interoperability • Compatibility only in “wire” protocols • Simpler, cheaper equipment • Minimal software

  18. Software Defined Networking (SDN) Logically-centralized control Smart, slow API to the data plane (e.g., OpenFlow) Dumb, fast Switches

  19. OpenFlow Networks

  20. Data-Plane: Simple 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=10.1.2.3, dest=*.*.*.*  send to controller

  21. Controller: Programmability App #1 App #2 App #3 Network OS Events from switches Topology changes, Traffic statistics, Arriving packets Commands to switches (Un)install rules, Query statistics, Send packets

  22. OpenFlow in the Wild • Open Networking Foundation • Creating Software Defined Networking standards • Google, Facebook, Microsoft, Yahoo, Verizon, Deutsche Telekom, and many other companies • Commercial OpenFlow switches • HP, NEC, Quanta, Dell, IBM, Juniper, … • Network operating systems • NOX, Beacon, Floodlight, Nettle, ONIX, POX, Frenetic • Network deployments • Eight campuses, and two research backbone networks • Commercial deployments

  23. Dynamic Access Control • Inspect first packet of each connection • Consult the access control policy • Install rules to block or route traffic

  24. Seamless Mobility/Migration • See host sending traffic at new location • Modify rules to reroute the traffic

  25. Example Applications • Dynamic access control • Seamless mobility/migration • Server load balancing • Using multiple wireless access points • Energy-efficient networking • Adaptive traffic monitoring • Denial-of-Service attack detection • Network virtualization See http://www.openflow.org/videos/

  26. Challenges of Programming Software Defined Networks

  27. Programming OpenFlow Networks • OpenFlow makes programming possible • Network-wide view at controller • Direct control over data plane • The APIs do not make it easy • Low level of abstraction • Challenges • Composition • Concurrency • Correctness • Testing Controller Switches

  28. A Simple example: Firewall • A switch connected to two kind of hosts • Trusted hosts via port 1 • Untrusted hosts via port 2 • Trusted hosts can freely send packets to untrusted hosts • An unstrusted host can only send to a trusted destination which previously sent messages to this host

  29. Firewall 1 2

  30. 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 }

  31. 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 2

  32. A Learning Switch • Ttwo hosts (A & B) • An OpenFlow switch with 3 ports • Host A is connected to port 1 • and Host B is connected to port 2 • Gradually install forwarding rules • Update upon relocation Host A 1 Switch Host B 2

  33. ‘A’ sends a message to ‘B’ Host A TCP syndst=B 1 Switch Host B 2

  34. Forward to the Controller Host A TCP syndst=B 1 Switch Host B 2 3 send TCP syndst=B on port 2 send TCP syndst=B on port 3 learn that A is connected via port 1

  35. ‘B’ sends a message to ‘A’ Host A 1 Switch Host B 2 TCP ackdst=A

  36. Forward to the Controller Host A TCP ackdst=A 1 Switch Host B 2 3 send TCP ackdst=A on port 1 learn that B is connected via port 2 Install a rule to forward packets from B to A on port 1

  37. ‘A’ sends another message to ‘B’ Host A dst=B 1 Switch Host B 2

  38. Forward to the Controller Host A dst=B 1 Switch Host B 2 3 Send dst=B on port 2 Install a rule to forward packets from A to B to port 2

  39. 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)

  40. Reasoning about Programs • Debugging • Testing • Model checking • Programming language support • Abstraction • Composition • Ease of use • Program verification • Abstraction

  41. Seminar Benefits • A cool topic • Reasoning • Critically read an article • Learn to present an article

  42. Seminar Requirements • Compilers • Read an article (2 weeks) • Prepare presentation (1 week) • Participate in lectures

  43. Tentative Schedule

More Related