PPJ-05

PPJ-05 SDN Challenges
http://eueung.github.io/EL5244/
Software Defined Networking

1. PPJ #5 Virtualization & Software Defined Networking http://eueung.github.io/EL5244/ Dr.-Ing. Eueung Mulyana | 2015H2
2. This material is mainly a derivative and remix work. Most of the texts and illustrations are taken from the talks/lectures given by the referenced networking professors/gurus/ninjas (Credits at the end of the Slide).
3. SDN Challenges
4. Heterogeneous Switches • Number of packet- handling rules • Range of matches and actions • Multi-stage pipeline of packet processing • Offload some control- plane functionality (?) access control MAC look-up IP look-up … of (possibly) different characters
5. Programming Abstractions • Controller APIs are low-level – Thin veneer on the underlying hardware • Need better languages – Composition of modules – Managing concurrency – Querying network state – Network-wide abstractions • Ongoing at Princeton – http://www.frenetic-lang.org/ Controller Switches
6. Controller Delay and Overhead • Controller is much slower the the switch • Processing packets leads to delay and overhead • Need to keep most packets in the “fast path” packets
7. Distributed Controller Network OS Controller Application Network OS Controller Application For scalability and reliability Partition and replicate state ONOS, Ravana (Princeton)
8. Testing and Debugging • SDN/OpenFlow makes programming possible – Network-wide view at controller – Direct control over data plane • Plenty of room for bugs – Still a complex, distributed system • Need for testing techniques – Controller applications – Controller and switches – Rules installed in the switches
9. Challenges for SDN (Core) Programmers
10. SDN Enables New Functionality Network OS Application Switch Switch Switch OpenFlow
11. … at the Risk of Bugs
12. Challenge #1: Two-Tiered Program • Two-tiered application – Controller – Switches • Rules in the switches – Crucial for performance – … but limits visibility Application Switch
13. Challenge #2: Control-Plane Delays • Common programming idiom – First packet goes to the controller – Controller application installs rules packets
14. Challenge #3: Timing and Ordering • Multiple switches – Different delays • Example – Installing rules along a path packets
15. Challenge #4: Overlapping Rules • Semantics of a rule depend on context – Overlapping patterns – Disambiguated by priorities • Example – Initial rule matching srcip==12.1.0.0/16 – Add a rule matching srcip==12.0.0.0/8 • Two scenarios – Overlap: 12.1.0.0/16 with higher priority – Shadowing: 12.0.0.0/8 with higher priority
16. Challenge #5: Conflicting Modules • Modular programs – Multiple modules for different tasks – E.g., firewall and routing • Routing – Match(dstip=12.0.0.0/8)  forward(3) • Firewall – Match(srcip=1.2.3.4, dstip=12.1.1.1)  drop • One rule may conflict with another
17. Challenge #6: Topologies • Many different network topologies – Chain – Tree – Arbitrary graph • Program should work for all topologies • Example – Program that (implicitly) assumes the graph has no cycles
18. Challenge #7: End-to-End Protocols • Internet applications are robust to errors – Retransmission of lost packets – Reordering of out-of- order packets • This can mask some bugs – E.g., forgetting to handle the packet that triggered an event – E.g., forgetting to handle packets that arrive before you install rules in the switches
19. Notes
20. Testing vs. Debugging • Debugging – Fixing a known problem in your program – Locating and fixing bugs – E.g., using tools like gdb • Testing – Convincing yourself that your program (probably) works – Systematically finding inputs that lead to incorrect outputs
21. Testing vs. Debugging • Debugging – What debugging features are useful for SDN programmers? – How can we exploit OpenFlow capabilities to support debugging? • Testing – How to overcome the scalability challenges? – How to detect performance bugs? • Preventing bugs – How can we change the programming environment to prevent bugs? – How can we change the programming environment to make testing easier?
22. MAC Learning App mactable[srcmac] = inport if (dstmac is broadcast address) flood packet else if (dstmac is in mactable) outport = mactable[dstmac] install rule matching (inport, srcmac, dstmac) with action of forwarding packet to outport else flood packet Packet-In Event Handler
23. Closing Notes
24. An Opportunity to Rethink • How should future networks be – Designed – Managed – Programmed • What are the right abstractions – Simple – Powerful – Reusable
25. An Opportunity to Rethink • Rethinking networking – Open interfaces to the data plane – Separation of control and data – Leveraging techniques from distributed systems • Significant momentum – In both research and industry
26. When we look back in 20 years… 1. “Software will eat the world” – SDN and NFV are a natural consequence of a bigger trend. 2. Network infrastructure will be: – Baremetal + open-source infrastructure + proprietary apps 3. Network box vendors will be irrelevant 4. Network operators will have developed and will own proprietary software 5. Standards will have diminished value 6. Networks will be more reliable
27. Credit • Scott Shenker, The Future of Networking and the Past of Protocols • Nick McKeown, Stanford University, Many Talks/Articles • Jennifer Rexford, COS 597E, Princeton University • Mike Freedman, COS 461, Princeton University • Nick Feamster, https://www.coursera.org/course/sdn • Li Erran Li, COMS 6998-10, Univ. of Columbia • Marco Cello, SDN Talk @ CNR, Univ. Genova • Guido Appenzeller, Network Virtualization in Multi- tenant Datacenters, VMware