SDN Abstractions


Published on

Scott Shenker's awesome talk on SDN and building high-level network abstractions.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • This can be pretty much any forwarding element in networks today.
  • The short answer is that it solves a bunch of operational problems today
  • If you don’t do this carefully, just end up with parallel architectures, but even then our framework provides an advantage Applications don’t need to changeInterdomain routing isn’t a constraint on the changeThat’s more than you get out of GENI, or overlays, or other approaches people typically take to innovation.
  • If you don’t do this carefully, just end up with parallel architectures, but even then our framework provides an advantage Applications don’t need to changeInterdomain routing isn’t a constraint on the changeThat’s more than you get out of GENI, or overlays, or other approaches people typically take to innovation.
  • SDN Abstractions

    1. 1. The Future of Networking,and the Past of Protocols<br />Scott Shenker<br />with Martin Casado, TeemuKoponen, Nick McKeown<br />(and many others….)<br />
    2. 2. Developments in Network “Management”<br />2004: Early work on new management paradigms<br />RCP, 4D, SANE, Ethane,…..<br />2008: Software-Defined Networking (SDN)<br />NOX Network Operating System<br />OpenFlow switch interface<br />2011: Open Networking Foundation<br />Over 30 companies endorsing SDN<br />Board: Google, Yahoo!, Verizon, DT, Microsoft, Facebook<br />Members: Cisco, Juniper, HP, Dell, Broadcom, IBM,…..<br />
    3. 3. Software-Defined Networking (SDN)<br />Not just an idle academic daydream<br />Tapped into some strong market need<br />One of those rare cases where we “know the future”<br />Still in development, but consensus on inevitability<br />Much more to story than “OpenFlow” trade rag hype<br />A revolutionary paradigm shift in the network control plane<br />This talk will “derive” SDN from first principles<br />By looking for key network control abstractions<br />
    4. 4. I Will Address Two SDN Questions<br />Why is SDN the right choice for future networks?<br />Obviously efficiency, scalability, security, functionality… <br />Not directly.<br />What are the fundamental aspects of SDN?<br />Obviously OpenFlow… <br />No, quite the opposite.<br />
    5. 5. But Talk Is Not Primarily About SDN<br />Main focus is on:<br />The Role of Abstractions<br />in Networking<br />
    6. 6. Weaving Together Three Themes<br />Networking currently built on weak foundation<br />Lack of fundamental abstractions<br />Network control plane needs three abstractions<br />Leads to SDN v1 and v2<br />Key abstractions solve other architecture problems<br />Two simple abstractions make architectures evolvable<br />
    7. 7. WeakIntellectualFoundations<br />OS courses teach fundamental principles <br />Mutual exclusion and other synchronization primitives<br />Files, file systems, threads, and other building blocks <br />Networking courses teach a big bag of protocols<br />No formal principles, just vague design guidelines<br />
    8. 8. WeakPracticalFoundations<br />Computation and storage have been virtualized<br />Creating a more flexible and manageable infrastructure<br />Networks are still notoriously hard to manage<br />Network administrators large share of sysadmin staff<br />
    9. 9. WeakEvolutionaryFoundations<br />Ongoing innovation in systems software<br />New languages, operating systems, etc.<br />Networks are stuck in the past<br />Routing algorithms change very slowly<br />Network management extremely primitive<br />
    10. 10. Why Are Networking Foundations Weak?<br />Networks used to be simple<br />Basic Ethernet/IP straightforward, easy to manage<br />New control requirements have led to complexity<br />ACLs, VLANs, TE, Middleboxes, DPI,…<br />The infrastructure still works...<br />Only because of our great ability to master complexity<br />Ability to master complexity both blessing and curse<br />
    11. 11. A Story About Mastering Complexity<br />~1985: Don Norman visits Xerox PARC <br />At start of his talk on UI design he asks:<br />“Who in the audience drives a stick shift”<br />After most of the audience raises their hands, he looks sternly out over the crowd and says: <br />“None of you should ever design a user interface<br />
    12. 12. Two Points to Story<br />His point: The ability to master complexity is not the same as the ability to extract simplicity<br />When first getting system to work, focus on former<br />When making system easy to use, focus on latter<br />My point: Networking has never made the transition!<br />
    13. 13. How Programming Made the Transition<br />Machine languages: no abstractions<br />Had to deal with low-level details<br />Higher-level languages: OS and other abstractions<br />File system, virtual memory, abstract data types, ...<br />Modern languages: even more abstractions<br />Object orientation, garbage collection,...<br />Abstractions simplify programmingEasier to write, maintain, reason about programs<br />
    14. 14. Why Are Abstractions/Interfaces Useful?<br />Interfaces are instantiations of abstractions<br />Interface shields a program’s implementation details<br />Allows freedom of implementation on both sides<br />Which leads to modular program structure<br />Barbara Liskov: “Power of Abstractions” talk<br />“Modularity based on abstraction <br />is the way things get done”<br />So, what role do abstractions play in networking?<br />
    15. 15. Layers are Main Network Abstractions<br />Layers provide nice data plane service abstractions<br />IP's best effort delivery<br />TCP's reliable byte-stream<br />Aside: good abstractions, terrible interfaces<br />Don’t sufficiently hide implementation details<br />Main Point: Nocontrolplane abstractions<br />No sophisticated management/control building blocks<br />
    16. 16. No Abstractions = Increased Complexity<br />Each control requirement leads to new mechanism<br />TRILL, LISP, etc.<br />We are really good at designing mechanisms<br />So we never tried to make life easier for ourselves<br />And so networks continue to grow more complex<br />But this is an unwise course:<br />Mastering complexity cannot be our only focus<br />Because it helps in short term, but harms in long term<br />We must shift our attention from mastering complexity to extracting simplicity….<br />
    17. 17. Three Basic Themes of Talk<br />Networking currently built on weak foundation<br />Lack of fundamental abstractions<br />Network control plane needs three abstractions<br />Leads to SDN v1 and v2<br />Key abstractions solve other architecture problems<br />Two simple abstractions make architectures evolvable<br />
    18. 18. How Do We Build Control Plane?<br />We define a new protocol from scratch<br />E.g., routing<br />Or we reconfigure an existing mechanism<br />E.g., traffic engineering<br />Or leave it for manual operator configuration<br />E.g., access control, middleboxes<br />
    19. 19. What Are The Design Constraints?<br />Operate within the confines of a given datapath<br />Must live with the capabilities of IP<br />Operate without communication guarantees<br />A distributed system with arbitrary delays and drops<br />Compute the configuration of each physical device<br />Switch, router, middlebox<br />FIB, ACLs, etc.<br />This is insanity!<br />
    20. 20. Programming Analogy<br />What if programmers had to:<br />Specify where each bit was stored<br />Explicitly deal with all internal communication errors<br />Within a programming language with limited expressability<br />Programmers would redefine problem by:<br />Defining higher level abstractions for memory<br />Building on reliable communication primitives<br />Using a more general language<br />Abstractions divide problem into tractable pieces<br />Why aren’t we doing this for network control?<br />
    21. 21. Central Question<br />What abstractions can simplify the control plane?<br />i.e., how do we separate the problems?<br />Not about designing new mechanisms!<br />We have all the mechanisms we need<br />Extracting simplicity vs mastering complexity<br />Separating problems vs solving problems<br />Defining abstractions vs designing mechanisms<br />
    22. 22. Abstractions Must Separate 3 Problems<br />Constrained forwarding model<br />Distributed state<br />Detailed configuration<br />
    23. 23. Forwarding Abstraction<br />Control plane needs flexible forwarding model<br />With behavior specified by control program<br />This abstracts away forwarding hardware<br />Crucial for evolving beyond vendor-specific solutions<br />Flexibility and vendor-neutrality are both valuable<br />But one economic, the other architectural<br />Possibilities:<br />General x86 program, MPLS, OpenFlow,…..<br />Different flexibility/performance/deployment tradeoffs<br />
    24. 24. State Distribution Abstraction<br />Control program should not have to deal with vagaries of distributed state<br />Complicated, source of many errors<br />Abstraction should hide state dissemination/collection<br />Proposed abstraction: global network view<br />Don’t worry about how to get that view (next slide)<br />Control program operates on network view<br />Input: global network view (graph)<br />Output: configuration of each network device<br />
    25. 25. Network Operating System (NOS)<br />NOS: distributed system that creates a network view<br />Runs on servers (controllers) in the network<br />Communicates with forwarding elements in network<br />Gets state information from forwarding elements<br />Communicates control directives to forwarding elements<br />Using forwarding abstraction<br />Control program operates on view of network<br />Control program is not a distributed system<br />NOS plus Forwarding Abstraction = SDN (v1)<br />
    26. 26. Current Networks<br />Software-Defined Networking (v1)<br />Protocols<br />Protocols<br />Control Program<br />Global Network View<br />Network Operating System<br />Control via forwarding <br />interface<br />
    27. 27. Major Change in Paradigm<br />No longer designing distributed control protocols<br />Now just defining a centralized control function<br />Control program: Configuration= Function(view)<br />Why is this an advance?<br />Much easier to write, verify, maintain, reason about, ….<br />NOS handles all state dissemination/collection<br />Abstraction breaks this off as tractable piece<br />Serves as fundamental building block for control<br />
    28. 28. WhatAboutConsistency?<br />NOS must achieve eventual consistency<br />View eventually consistent with real network<br />The configuration is therefore eventually correct<br />Simple function of view<br />What about transient conditions?<br />Hard to ensure good transient behavior with protocols<br />Much easier with NOS<br />What about distributed NOS (multiple controllers)?<br />Need to split up decisions among controllers sensibly<br />
    29. 29. Why Does This Approach Scale?<br />Modification of Control Program<br />Strong Consistency<br />0 - 10/s<br />Per Network Event<br />Eventual Consistency<br />101 – 103/s<br />Per Flow<br />No Consistency <br />103 – 106/s<br />Per Packet<br />No Consistency<br />106 – 108/s<br />
    30. 30. Is Performance Good Enough?<br />Architect for simplicity, engineer for performance<br />Many engineering tricks can help SDN performance<br />Caching state<br />Backup paths<br />…..<br />Don’t overly restrict vision of SDN<br />Key SDN principle: configuration derived from global state<br />“Configuration” can include more general device behaviors<br />SDN ≠ OpenFlow<br />
    31. 31. What Role Does OpenFlow Play?<br />NOS conveys configuration of global network view to actual physical devices<br />But nothing in this picture limits what the meaning of “configuration” is<br />OpenFlow is one possible definition of how to model the configuration of a physical device<br />Is it the right one? Absolutely not.<br />Crucial for vendor-independence<br />But not the right abstraction (yet)<br />
    32. 32. Alternative SDN Implementation<br />Linecard forwarding model: (per packet behavior)<br />Supports OpenFlow plus x86 (and perhaps GPU)<br />Switch configuration model: (management CPU)<br />Supports JVM (controller can download code)<br />NOS distributed state model: <br />Key-value store<br />Merely an illustration of a richer form of SDN<br />Enables features to emerge in software, migrate to HW<br />
    33. 33. Are We Done Yet?<br />This approach requires control program (or operator) to configure each individual network device<br />This is much more complicated than it should be!<br />NOS eases implementation of functionality<br />But does not help specification of functionality!<br />We need a specification abstraction<br />
    34. 34. Specification Abstraction<br />Give control program abstract view of network<br />Where abstract view is function of global view<br />Then, control program is abstract mapping<br />Abstract configuration = Function(abstract view) <br />Model just enough detail to specify goals<br />Don’t provide information needed to implement goals<br />
    35. 35. One Simple Example: Access Control<br />Abstract Network<br />View<br />Full Network View<br />
    36. 36. More Detailed Model<br />Service model can generally be described by a table pipeline<br />Packet In<br />Packet Out<br />L2<br />L3<br />ACL<br />
    37. 37. Implementing Specification Abstraction<br />Given: Abstract Table Pipeline<br />L3<br />ACL<br />L2<br />Network Hypervisor <br />(Nypervisor)<br />Compiles abstract pipeline <br />into physical configuration<br />Need: pipeline operations distributed <br />over network of physical switches<br />
    38. 38. Two Examples<br />Scale-out router:<br />Abstract view is single router<br />Physical network is collection of interconnected switches<br />Nypervisor allows routers to “scale out, not up”<br />Multi-tenant networks:<br />Each tenant has control over their “private” network<br />Nypervisor compiles all of these individual control requests into a single physical configuration<br />“Network Virtualization”<br />
    39. 39. Abstract Network View<br />Nypervisor<br />Control Program<br />Global Network View<br />Network Operating System<br />Moving from SDNv1 to SDNv2<br />
    40. 40. Clean Separation of Concerns<br />Network control program specifies the behavior it wants on the abstract network view<br />Control program: maps behavior to abstract view<br />Abstract model should be chosen so that this is easy<br />Nypervisor maps the controls expressed on the abstract view into configuration of the global view<br />Nypervisor: abstract model to global view<br />Models such as single cross-bar, single “slice”,…<br />NOS distributes configuration to physical switches<br />NOS: global view to physical switches<br />
    41. 41. Three Basic Network Interfaces<br />Forwarding interface: abstract forwarding model<br />Shields higher layers from forwarding hardware<br />Distribution interface: global network view<br />Shields higher layers from state dissemination/collection<br />Specification interface: abstract network view<br />Shields control program from details of physical network<br />
    42. 42. Three Basic Themes of Talk<br />Networking currently built on weak foundation<br />Lack of fundamental abstractions<br />Network control plane needs three abstractions<br />Leads to SDN v1 and v2<br />Key abstractions solve other architecture problems<br />Two simple abstractions make architectures evolvable<br />
    43. 43. More General Use of Abstractions<br />So far, focus was on network “management”<br />Operator control within a single domain<br />Ignores host and interdomain issues<br />Did not address basic network “architecture”<br />Naming, addressing, interdomain routing, security,…<br />What abstractions describe Internet architecture?<br />Too general a question….<br />How can abstractions help clean-slate redesign?<br />
    44. 44. What is Goal for Architectural Redesign?<br />A more functional architecture?<br />Pro: We know how to improve security, reliability, etc.<br />Con: Design will be fixed for a generation<br />Like today’s architecture<br />A more evolvable architecture!<br />Pro: Allows functionality to evolve over time<br />Con: We don’t know how to build one<br />Much talk about architectural evolution, no progress<br />Two simple abstractions sufficient to solve problem <br />
    45. 45. Why Is Current Architecture Rigid?<br />IP is central component of architecture<br />IP is embedded in interdomain routing<br />And interdomain routing is hard to change<br />IP is embedded in applications (via API)<br />And hard to change all applications<br />Therefore, very hard to change IP!<br />
    46. 46. The Current Internet<br />Application<br />Network Stack<br />Architecture is very rigid<br />IP<br />Domain<br />BGP<br />Rest of Internet<br />
    47. 47. Insert Two Architectural Abstractions<br />Clean IDR interface:<br />No leakage of intradomain routing across interface<br />Flexible route computation<br />Clean network API (netAPI)<br />No leakage of network architecture across interface<br />Flexible interface semantics<br />Architecture is then evolvable!<br />By making both interfaces abstract and extensible!<br />
    48. 48. A More Evolvable Internet<br />Application<br />netAPI<br />Extensible and Abstract<br />Network Stack<br />Network stack and domain have complete freedom to innovate<br />Architecture is very rigid<br />IP<br />Domain<br />BGP<br />Extensible and Abstract<br />IDR<br />Rest of Internet<br />
    49. 49. Two Abstractions Evolvability<br />Domains can independently adopt new protocols<br />IPv6, AIP, and other network-level protocols<br />No need for interdomain agreements on L3<br />New naming systems, APIs can be introduced<br />DONA, CCN, and other data-oriented architectures<br />No need to change existing applications<br />New forms of QoS and other path services<br />No need to change interdomain routing<br />
    50. 50. Evolvabilityvs Functionality<br />The IDR/netAPI abstractions help evolvability<br />Specific architectures need functionality abstractions<br />Sockets vsPubSub<br />Delivery models<br />….<br />Once we fix evolution, we can then take our time to get these other abstractions right!<br />
    51. 51. End of Three Themes, Back to SDN<br />SDN not about new mechanisms; can use current<br />Forwarding primitives (e.g., MPLS)<br />State distribution primitives (e.g., flooding as in OSPF)<br />Operator control programs (e.g., BGP on scale-out router)<br />SDN is all about modularity<br />Giving networking the benefits of modular programming<br />Can reliably build more complicated functionality<br />No more designing distributed control protocols<br />Merely define control programs over abstract model<br />Given abstract network, what behavior do you want?<br />
    52. 52. Control Plane Research Agenda<br />Create three modular, tractable pieces<br />Nypervisor<br />Network Operating System<br />Design and implement forwarding model<br />Build control programs over abstract models<br />Identify appropriate models for various applications<br />Virtualization, Access Control, TE, Routing,…<br />
    53. 53. Implementations vs Abstractions<br />SDN is an instantiation of fundamental abstractions<br />Don’t get distracted by the mechanisms<br />The abstractions were needed to separate concerns<br />Network challenges are now modular and tractable<br />The abstractions are fundamental<br />SDN implementations are ephemeral<br />OpenFlow/NOX/etc. particular implementations<br />
    54. 54. Future of Networking, Past of Protocols<br />The future of networking lies in cleaner abstractions<br />Not in defining complicated distributed protocols<br />SDN is only the beginning of needed abstractions<br />Took OS researchers years to find their abstractions<br />First they made it work, then they made it simple<br />Networks work, but they are definitely not simple<br />It is now networking’s turn to make this transition<br />Our task: make networking a mature discipline<br />By extracting simplicity from the sea of complexity…<br />