• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
SDN Abstractions

SDN Abstractions



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.



Total Views
Views on SlideShare
Embed Views



25 Embeds 10,420

http://networkheresy.com 4941
https://www.opennetworking.org 2876
http://networkheresy.wordpress.com 2146
http://s23a121.dm1.oii.oki.co.jp 86
url_unknown 67
http://onf.r3d2.de 60
http://j25.manipaldigital.in 51
http://www.hillos.org 51
http://test.opennetworking.org 44
http://www.slideshare.net 23
http://localhost 22
http://www.linkedin.com 17
http://onfa.amsl.com 7
https://test.opennetworking.org 5
http://irq.tumblr.com 5
http://manipaldigital.in 4
https://twitter.com 4
https://www.openflow.org 3
http://translate.googleusercontent.com 2
http://www.docseek.net 1 1 1
https://openflow.org 1
http://webcache.googleusercontent.com 1
https://onfa.amsl.com 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • 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 SDN Abstractions Presentation Transcript

  • The Future of Networking,and the Past of Protocols
    Scott Shenker
    with Martin Casado, TeemuKoponen, Nick McKeown
    (and many others….)
  • 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,…..
  • 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
  • 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.
  • But Talk Is Not Primarily About SDN
    Main focus is on:
    The Role of Abstractions
    in Networking
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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!
  • 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
  • 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?
  • 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
  • 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….
  • 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
  • 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
  • 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!
  • 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?
  • 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
  • Abstractions Must Separate 3 Problems
    Constrained forwarding model
    Distributed state
    Detailed configuration
  • 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
    General x86 program, MPLS, OpenFlow,…..
    Different flexibility/performance/deployment tradeoffs
  • 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
  • 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)
  • Current Networks
    Software-Defined Networking (v1)
    Control Program
    Global Network View
    Network Operating System
    Control via forwarding
  • 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
  • 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
  • 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
  • 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
  • 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)
  • 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
  • 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
  • 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
  • One Simple Example: Access Control
    Abstract Network
    Full Network View
  • More Detailed Model
    Service model can generally be described by a table pipeline
    Packet In
    Packet Out
  • Implementing Specification Abstraction
    Given: Abstract Table Pipeline
    Network Hypervisor
    Compiles abstract pipeline
    into physical configuration
    Need: pipeline operations distributed
    over network of physical switches
  • 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”
  • Abstract Network View
    Control Program
    Global Network View
    Network Operating System
    Moving from SDNv1 to SDNv2
  • 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
  • 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
  • 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
  • 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?
  • 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
  • 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!
  • The Current Internet
    Network Stack
    Architecture is very rigid
    Rest of Internet
  • 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!
  • A More Evolvable Internet
    Extensible and Abstract
    Network Stack
    Network stack and domain have complete freedom to innovate
    Architecture is very rigid
    Extensible and Abstract
    Rest of Internet
  • 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
  • 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!
  • 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?
  • Control Plane Research Agenda
    Create three modular, tractable pieces
    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,…
  • 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
  • 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…