Your SlideShare is downloading. ×
SDN Abstractions
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

SDN Abstractions

29,326
views

Published on

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

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

Published in: Technology

0 Comments
26 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
29,326
On Slideshare
0
From Embeds
0
Number of Embeds
17
Actions
Shares
0
Downloads
1,247
Comments
0
Likes
26
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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.
  • Transcript

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