SDN Abstractions

SDN Abstractions

• 1.
  The Future ofNetworking,and the Past of ProtocolsScott Shenkerwith Martin Casado, TeemuKoponen, Nick McKeown(and many others….)
• 2.
  Developments in Network“Management”2004: Early work on new management paradigmsRCP, 4D, SANE, Ethane,…..2008: Software-Defined Networking (SDN)NOX Network Operating SystemOpenFlow switch interface2011: Open Networking FoundationOver 30 companies endorsing SDNBoard: Google, Yahoo!, Verizon, DT, Microsoft, FacebookMembers: Cisco, Juniper, HP, Dell, Broadcom, IBM,…..
• 3.
  Software-Defined Networking (SDN)Notjust an idle academic daydreamTapped into some strong market needOne of those rare cases where we “know the future”Still in development, but consensus on inevitabilityMuch more to story than “OpenFlow” trade rag hypeA revolutionary paradigm shift in the network control planeThis talk will “derive” SDN from first principlesBy looking for key network control abstractions
• 4.
  I Will AddressTwo SDN QuestionsWhy 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 IsNot Primarily About SDNMain focus is on:The Role of Abstractionsin Networking
• 6.
  Weaving Together ThreeThemesNetworking currently built on weak foundationLack of fundamental abstractionsNetwork control plane needs three abstractionsLeads to SDN v1 and v2Key abstractions solve other architecture problemsTwo simple abstractions make architectures evolvable
• 7.
  WeakIntellectualFoundationsOS courses teachfundamental principles Mutual exclusion and other synchronization primitivesFiles, file systems, threads, and other building blocks Networking courses teach a big bag of protocolsNo formal principles, just vague design guidelines
• 8.
  WeakPracticalFoundationsComputation and storagehave been virtualizedCreating a more flexible and manageable infrastructureNetworks are still notoriously hard to manageNetwork administrators large share of sysadmin staff
• 9.
  WeakEvolutionaryFoundationsOngoing innovation insystems softwareNew languages, operating systems, etc.Networks are stuck in the pastRouting algorithms change very slowlyNetwork management extremely primitive
• 10.
  Why Are NetworkingFoundations Weak?Networks used to be simpleBasic Ethernet/IP straightforward, easy to manageNew control requirements have led to complexityACLs, VLANs, TE, Middleboxes, DPI,…The infrastructure still works...Only because of our great ability to master complexityAbility to master complexity both blessing and curse
• 11.
  A Story AboutMastering 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 toStoryHis point: The ability to master complexity is not the same as the ability to extract simplicityWhen first getting system to work, focus on formerWhen making system easy to use, focus on latterMy point: Networking has never made the transition!
• 13.
  How Programming Madethe TransitionMachine languages: no abstractionsHad to deal with low-level detailsHigher-level languages: OS and other abstractionsFile system, virtual memory, abstract data types, ...Modern languages: even more abstractionsObject orientation, garbage collection,...Abstractions simplify programmingEasier to write, maintain, reason about programs
• 14.
  Why Are Abstractions/InterfacesUseful?Interfaces are instantiations of abstractionsInterface shields a program’s implementation detailsAllows freedom of implementation on both sidesWhich leads to modular program structureBarbara 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 MainNetwork AbstractionsLayers provide nice data plane service abstractionsIP's best effort deliveryTCP's reliable byte-streamAside: good abstractions, terrible interfacesDon’t sufficiently hide implementation detailsMain Point: Nocontrolplane abstractionsNo sophisticated management/control building blocks
• 16.
  No Abstractions =Increased ComplexityEach control requirement leads to new mechanismTRILL, LISP, etc.We are really good at designing mechanismsSo we never tried to make life easier for ourselvesAnd so networks continue to grow more complexBut this is an unwise course:Mastering complexity cannot be our only focusBecause it helps in short term, but harms in long termWe must shift our attention from mastering complexity to extracting simplicity….
• 17.
  Three Basic Themesof TalkNetworking currently built on weak foundationLack of fundamental abstractionsNetwork control plane needs three abstractionsLeads to SDN v1 and v2Key abstractions solve other architecture problemsTwo simple abstractions make architectures evolvable
• 18.
  How Do WeBuild Control Plane?We define a new protocol from scratchE.g., routingOr we reconfigure an existing mechanismE.g., traffic engineeringOr leave it for manual operator configurationE.g., access control, middleboxes
• 19.
  What Are TheDesign Constraints?Operate within the confines of a given datapathMust live with the capabilities of IPOperate without communication guaranteesA distributed system with arbitrary delays and dropsCompute the configuration of each physical deviceSwitch, router, middleboxFIB, ACLs, etc.This is insanity!
• 20.
  Programming AnalogyWhat ifprogrammers had to:Specify where each bit was storedExplicitly deal with all internal communication errorsWithin a programming language with limited expressabilityProgrammers would redefine problem by:Defining higher level abstractions for memoryBuilding on reliable communication primitivesUsing a more general languageAbstractions divide problem into tractable piecesWhy aren’t we doing this for network control?
• 21.
  Central QuestionWhat abstractionscan simplify the control plane?i.e., how do we separate the problems?Not about designing new mechanisms!We have all the mechanisms we needExtracting simplicity vs mastering complexitySeparating problems vs solving problemsDefining abstractions vs designing mechanisms
• 22.
  Abstractions Must Separate3 ProblemsConstrained forwarding modelDistributed stateDetailed configuration
• 23.
  Forwarding AbstractionControl planeneeds flexible forwarding modelWith behavior specified by control programThis abstracts away forwarding hardwareCrucial for evolving beyond vendor-specific solutionsFlexibility and vendor-neutrality are both valuableBut one economic, the other architecturalPossibilities:General x86 program, MPLS, OpenFlow,…..Different flexibility/performance/deployment tradeoffs
• 24.
  State Distribution AbstractionControlprogram should not have to deal with vagaries of distributed stateComplicated, source of many errorsAbstraction should hide state dissemination/collectionProposed abstraction: global network viewDon’t worry about how to get that view (next slide)Control program operates on network viewInput: global network view (graph)Output: configuration of each network device
• 25.
  Network Operating System(NOS)NOS: distributed system that creates a network viewRuns on servers (controllers) in the networkCommunicates with forwarding elements in networkGets state information from forwarding elementsCommunicates control directives to forwarding elementsUsing forwarding abstractionControl program operates on view of networkControl program is not a distributed systemNOS plus Forwarding Abstraction = SDN (v1)
• 26.
  Current NetworksSoftware-Defined Networking(v1)ProtocolsProtocolsControl ProgramGlobal Network ViewNetwork Operating SystemControl via forwarding interface
• 27.
  Major Change inParadigmNo longer designing distributed control protocolsNow just defining a centralized control functionControl program: Configuration= Function(view)Why is this an advance?Much easier to write, verify, maintain, reason about, ….NOS handles all state dissemination/collectionAbstraction breaks this off as tractable pieceServes as fundamental building block for control
• 28.
  WhatAboutConsistency?NOS must achieveeventual consistencyView eventually consistent with real networkThe configuration is therefore eventually correctSimple function of viewWhat about transient conditions?Hard to ensure good transient behavior with protocolsMuch easier with NOSWhat about distributed NOS (multiple controllers)?Need to split up decisions among controllers sensibly
• 29.
  Why Does ThisApproach Scale?Modification of Control ProgramStrong Consistency0 - 10/sPer Network EventEventual Consistency101 – 103/sPer FlowNo Consistency 103 – 106/sPer PacketNo Consistency106 – 108/s
• 30.
  Is Performance GoodEnough?Architect for simplicity, engineer for performanceMany engineering tricks can help SDN performanceCaching stateBackup paths…..Don’t overly restrict vision of SDNKey SDN principle: configuration derived from global state“Configuration” can include more general device behaviorsSDN ≠ OpenFlow
• 31.
  What Role DoesOpenFlow Play?NOS conveys configuration of global network view to actual physical devicesBut nothing in this picture limits what the meaning of “configuration” isOpenFlow is one possible definition of how to model the configuration of a physical deviceIs it the right one? Absolutely not.Crucial for vendor-independenceBut not the right abstraction (yet)
• 32.
  Alternative SDN ImplementationLinecardforwarding 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 storeMerely an illustration of a richer form of SDNEnables features to emerge in software, migrate to HW
• 33.
  Are We DoneYet?This approach requires control program (or operator) to configure each individual network deviceThis is much more complicated than it should be!NOS eases implementation of functionalityBut does not help specification of functionality!We need a specification abstraction
• 34.
  Specification AbstractionGive controlprogram abstract view of networkWhere abstract view is function of global viewThen, control program is abstract mappingAbstract configuration = Function(abstract view) Model just enough detail to specify goalsDon’t provide information needed to implement goals
• 35.
  One Simple Example:Access ControlAbstract NetworkViewFull Network View
• 36.
  More Detailed ModelServicemodel can generally be described by a table pipelinePacket InPacket OutL2L3ACL
• 37.
  Implementing Specification AbstractionGiven:Abstract Table PipelineL3ACLL2Network Hypervisor (Nypervisor)Compiles abstract pipeline into physical configurationNeed: pipeline operations distributed over network of physical switches
• 38.
  Two ExamplesScale-out router:Abstractview is single routerPhysical network is collection of interconnected switchesNypervisor allows routers to “scale out, not up”Multi-tenant networks:Each tenant has control over their “private” networkNypervisor compiles all of these individual control requests into a single physical configuration“Network Virtualization”
• 39.
  Abstract Network ViewNypervisorControlProgramGlobal Network ViewNetwork Operating SystemMoving from SDNv1 to SDNv2
• 40.
  Clean Separation ofConcernsNetwork control program specifies the behavior it wants on the abstract network viewControl program: maps behavior to abstract viewAbstract model should be chosen so that this is easyNypervisor maps the controls expressed on the abstract view into configuration of the global viewNypervisor: abstract model to global viewModels such as single cross-bar, single “slice”,…NOS distributes configuration to physical switchesNOS: global view to physical switches
• 41.
  Three Basic NetworkInterfacesForwarding interface: abstract forwarding modelShields higher layers from forwarding hardwareDistribution interface: global network viewShields higher layers from state dissemination/collectionSpecification interface: abstract network viewShields control program from details of physical network
• 42.
  Three Basic Themesof TalkNetworking currently built on weak foundationLack of fundamental abstractionsNetwork control plane needs three abstractionsLeads to SDN v1 and v2Key abstractions solve other architecture problemsTwo simple abstractions make architectures evolvable
• 43.
  More General Useof AbstractionsSo far, focus was on network “management”Operator control within a single domainIgnores host and interdomain issuesDid 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 Goalfor Architectural Redesign?A more functional architecture?Pro: We know how to improve security, reliability, etc.Con: Design will be fixed for a generationLike today’s architectureA more evolvable architecture!Pro: Allows functionality to evolve over timeCon: We don’t know how to build oneMuch talk about architectural evolution, no progressTwo simple abstractions sufficient to solve problem
• 45.
  Why Is CurrentArchitecture Rigid?IP is central component of architectureIP is embedded in interdomain routingAnd interdomain routing is hard to changeIP is embedded in applications (via API)And hard to change all applicationsTherefore, very hard to change IP!
• 46.
  The Current InternetApplicationNetworkStackArchitecture is very rigidIPDomainBGPRest of Internet
• 47.
  Insert Two ArchitecturalAbstractionsClean IDR interface:No leakage of intradomain routing across interfaceFlexible route computationClean network API (netAPI)No leakage of network architecture across interfaceFlexible interface semanticsArchitecture is then evolvable!By making both interfaces abstract and extensible!
• 48.
  A More EvolvableInternetApplicationnetAPIExtensible and AbstractNetwork StackNetwork stack and domain have complete freedom to innovateArchitecture is very rigidIPDomainBGPExtensible and AbstractIDRRest of Internet
• 49.
  Two Abstractions EvolvabilityDomainscan independently adopt new protocolsIPv6, AIP, and other network-level protocolsNo need for interdomain agreements on L3New naming systems, APIs can be introducedDONA, CCN, and other data-oriented architecturesNo need to change existing applicationsNew forms of QoS and other path servicesNo need to change interdomain routing
• 50.
  Evolvabilityvs FunctionalityThe IDR/netAPIabstractions help evolvabilitySpecific architectures need functionality abstractionsSockets vsPubSubDelivery models….Once we fix evolution, we can then take our time to get these other abstractions right!
• 51.
  End of ThreeThemes, Back to SDNSDN not about new mechanisms; can use currentForwarding 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 modularityGiving networking the benefits of modular programmingCan reliably build more complicated functionalityNo more designing distributed control protocolsMerely define control programs over abstract modelGiven abstract network, what behavior do you want?
• 52.
  Control Plane ResearchAgendaCreate three modular, tractable piecesNypervisorNetwork Operating SystemDesign and implement forwarding modelBuild control programs over abstract modelsIdentify appropriate models for various applicationsVirtualization, Access Control, TE, Routing,…
• 53.
  Implementations vs AbstractionsSDNis an instantiation of fundamental abstractionsDon’t get distracted by the mechanismsThe abstractions were needed to separate concernsNetwork challenges are now modular and tractableThe abstractions are fundamentalSDN implementations are ephemeralOpenFlow/NOX/etc. particular implementations
• 54.
  Future of Networking,Past of ProtocolsThe future of networking lies in cleaner abstractionsNot in defining complicated distributed protocolsSDN is only the beginning of needed abstractionsTook OS researchers years to find their abstractionsFirst they made it work, then they made it simpleNetworks work, but they are definitely not simpleIt is now networking’s turn to make this transitionOur task: make networking a mature disciplineBy extracting simplicity from the sea of complexity…