SDN basics
0 likes193 views
The document provides an overview of Software Defined Networking (SDN), detailing its concepts, the role of OpenFlow, and the architecture of controllers like Floodlight. It contrasts traditional, vertically integrated networking systems with the openness and flexibility offered by SDN, emphasizing the need for better abstractions in networking to keep pace with innovation. The text also discusses various applications of OpenFlow, its limitations, and the evolution of network control models.
SDN basics
- 1. 9/8/14 1 Outline • SDN Basics – Concepts – OpenFlow – Controller: Floodlight – OF-‐Config – Mininet 1 SDN Concepts • What is soCware defined networking? • Why SDN? 2
- 2. 9/8/14 2 Vertically integrated Closed, proprietary Slow innovation Small industry Specialized Operating System Specialized Hardware App App App App App App App App App App App Specialized Applications Horizontal Open interfaces Rapid innovation Huge industry Microprocessor Open Interface Linux Mac OS Windows (OS) or or Open Interface 3 Source: Nick Mckeown, Stanford Vertically integrated Closed, proprietary Slow innovation App App App App App App App App App App App Horizontal Open interfaces Rapid innovation Control Plane Control Plane Control Plane or or Open Interface Specialized Control Plane Specialized Hardware Specialized Features Merchant Switching Chips Open Interface 4 Source: Nick Mckeown, Stanford
- 3. 9/8/14 3 Million of lines of source code 6,000 RFCs Billions of gates Bloated Power Hungry • VerVcally integrated, complex, closed, proprietary • Networking industry with “mainframe” mind-‐set Custom Hardware OS Routing, management, mobility management, access control, VPNs, … Feature Feature 5 Source: Nick Mckeown, Stanford Custom Hardware Custom Hardware Custom Hardware Custom Hardware Custom Hardware OS OS OS OS OS Network OS Feature Feature The network is changing Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature 6 Source: Nick Mckeown, Stanford
- 4. 9/8/14 4 Feature Feature Network OS 1. Open interface to packet forwarding 3. Consistent, up-‐to-‐date global network view 2. At least one Network OS probably many. Open-‐ and closed-‐source SoCware Defined Network (SDN) Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding 7 Source: Nick Mckeown, Stanford Network OS Network OS: distributed system that creates a consistent, up-‐to-‐date network view – Runs on servers (controllers) in the network – Floodlight, POX, PyreVc, Ne_le ONIX, Beacon, … + more Uses forwarding abstracVon to: – Get state informaVon from forwarding elements – Give control direcVves to forwarding elements 8 Source: Nick Mckeown, Stanford
- 5. 9/8/14 5 Control Program A Control Program B Network OS SoCware Defined Network (SDN) Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding 9 Source: Nick Mckeown, Stanford Control Program Control program operates on view of network – Input: global network view (graph/database) – Output: configuraVon of each network device Control program is not a distributed system – AbstracVon hides details of distributed state 10 Source: Nick Mckeown, Stanford
- 6. 9/8/14 6 Forwarding AbstracVon Purpose: Abstract away forwarding hardware Flexible – Behavior specified by control plane – Built from basic set of forwarding primiVves Minimal – Streamlined for speed and low-‐power – Control program not vendor-‐specific OpenFlow is an example of such an abstracVon 11 Source: Nick Mckeown, Stanford Why SDN? Great talk by Scott Shenker http://www.youtube.com/watch?v=WVs7Pc99S7w (Story summarized here)
- 7. 9/8/14 7 Networking Networking is “Intellectually Weak” Networking is behind other fields Networking is about the mastery of complexity Good abstracVons tame complexity Interfaces are instances of those abstracVons No abstracVon => increasing complexity We are now at the complexity limit 13 Source: Nick Mckeown, Stanford By comparison: Programming Machine languages: no abstracVons – Had to deal with low-‐level details Higher-‐level languages: OS and other abstracVons – File system, virtual memory, abstract data types, ... Modern languages: even more abstracVons – Object orientaVon, garbage collecVon,… 14 Source: Nick Mckeown, Stanford
- 8. 9/8/14 8 Programming Analogy What if programmers had to: – Specify where each bit was stored – Explicitly deal with internal communicaVon errors – Within a programming language with limited expressability Programmers would redefine problem by: – Defining higher level abstracVons for memory – Building on reliable communicaVon primiVves – Using a more general language 15 Source: Nick Mckeown, Stanford SpecificaVon AbstracVon Network OS eases implementaVon Next step is to ease specificaVon Provide abstract view of network map Control program operates on abstract view Develop means to simplify specificaVon 16 Source: Nick Mckeown, Stanford
- 9. 9/8/14 9 Control Program A Control Program B SoCware Defined Network (SDN) Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Network OS Global Network View Abstract Network View VirtualizaVon 17 Source: Nick Mckeown, Stanford Outline • SDN Basics – Concepts – OpenFlow – Switches and Controllers – OF-‐Config – Mininet 18
- 10. 9/8/14 10 OpenFlow • Why OpenFlow? • How does OpenFlow work? 19 Why OpenFlow? 20
- 11. 9/8/14 11 Million of lines of source code 5400 RFCs Barrier to entry Billions of gates Bloated Power Hungry Many complex funcVons baked into the infrastructure OSPF, BGP, mul,cast, differen,ated services, Traffic Engineering, NAT, firewalls, MPLS, redundant layers, … An industry with a “mainframe-‐mentality”, reluctant to change The Ossified Network Specialized Packet Forwarding Hardware OperaVng System Feature Feature RouVng, management, mobility management, access control, VPNs, … 21 21 Research StagnaVon • Lots of deployed innovaVon in other areas – OS: filesystems, schedulers, virtualizaVon – DS: DHTs, CDNs, MapReduce – Compilers: JITs, vectorizaVon • Networks are largely the same as years ago – Ethernet, IP, WiFi • Rate of change of the network seems slower in comparison – Need be_er tools and abstracVons to demonstrate and deploy 22
- 12. 9/8/14 12 Closed Systems (Vendor Hardware) • Stuck with interfaces (CLI, SNMP, etc) • Hard to meaningfully collaborate • Vendors starVng to open up, but not usefully • Need a fully open system – a Linux equivalent 23 Open Systems Performance Fidelity Scale Real User Traffic? Complexity Open SimulaVon medium medium no medium yes EmulaVon medium low no medium yes SoCware Switches poor low yes medium yes NetFPGA high low yes high yes Network Processors high medium yes high yes Vendor Switches high high yes low no gap in the tool space none have all the desired a_ributes! 24 Source: Big Switch Networks
- 13. 9/8/14 13 Ethane, a precursor to OpenFlow Centralized, reacVve, per-‐flow control Controller Flow Switch Host A Host B Flow Switch Flow Switch Flow Switch See Ethane SIGCOMM 2007 paper for details 25 OpenFlow: a pragmaVc compromise • + Speed, scale, fidelity of vendor hardware • + Flexibility and control of soCware and simulaVon • Vendors don’t need to expose implementaVon • Leverages hardware inside most switches today (ACL tables) 26
- 14. 9/8/14 14 How does OpenFlow work? h_ps://www.opennetworking.org 27 27 Ethernet Switch 28
- 15. 9/8/14 15 29 OpenFlow Protocol (SSL/TCP) 30
- 16. 9/8/14 16 Controller PC Hardware Layer SoCware Layer Flow Table MAC src MAC dst IP Src IP Dst TCP sport TCP dport AcVon OpenFlow Client * * 5.6.7.8 * * * port 1 port 4 port 3 port 2 port 1 1.2.3.4 5.6.7.8 OpenFlow Example 31 OpenFlow Basics Flow Table Entries Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot L4 sport L4 dport Rule AcVon Stats 1. Forward packet to zero or more ports 2. Encapsulate and forward to controller 3. Send to normal processing pipeline 4. Modify Fields 5. Any extensions you add! + mask what fields to match Packet + byte counters 32 VLAN pcp IP ToS
- 17. 9/8/14 17 Examples Switching * Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport AcVon * 00:1f:.. * * * * * * * port6 Flow Switching port3 Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport AcVon 00:20.. 00:1f.. 0800 vlan1 1.2.3.4 5.6.7.8 4 17264 80 port6 Firewall * Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport AcVon * * * * * * * * 22 drop 33 Examples RouVng * Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport AcVon * * * * * 5.6.7.8 * * * port6 VLAN Switching * Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport AcVon * * vlan1 * * * * * port6, port7, port9 00:1f.. 34
- 18. 9/8/14 18 Centralized vs Distributed Control Both models are possible with OpenFlow Centralized Control OpenFlow Switch OpenFlow Switch OpenFlow Switch Controller Distributed Control OpenFlow Switch OpenFlow Switch OpenFlow Switch Controller Controller Controller 35 Flow RouVng vs. AggregaVon Both models are possible with OpenFlow Flow-‐Based • Every flow is individually set up by controller • Exact-‐match flow entries • Flow table contains one entry per flow • Good for fine grain control, e.g. campus networks Aggregated • One flow entry covers large groups of flows • Wildcard flow entries • Flow table contains one entry per category of flows • Good for large number of flows, e.g. backbone 36
- 19. 9/8/14 19 ReacVve vs. ProacVve (pre-‐populated) Both models are possible with OpenFlow ReacVve • First packet of flow triggers controller to insert flow entries • Efficient use of flow table • Every flow incurs small addiVonal flow setup Vme • If control connecVon lost, switch has limited uVlity ProacVve • Controller pre-‐populates flow table in switch • Zero addiVonal flow setup Vme • Loss of control connecVon does not disrupt traffic • EssenVally requires aggregated (wildcard) rules 37 Usage examples • Alice’s code: – Simple learning switch – Per Flow switching – Network access control/ firewall – StaVc “VLANs” – Her own new rouVng protocol: unicast, mulVcast, mulVpath – Home network manager – Packet processor (in controller) – IPvAlice – VM migraVon – Server Load balancing – Mobility manager – Power management – Network monitoring and visualizaVon – Network debugging – Network slicing … and much more you can create! 38
- 20. 9/8/14 20 What can you not do with OpenFlow ver1.0 • Non-‐flow-‐based (per-‐packet) networking – ex. Per-‐packet next-‐hop selecVon (in wireless mesh) – yes, this is a fundamental limitaVon – BUT OpenFlow can provide the plumbing to connect these systems • Use all tables on switch chips – yes, a major limitaVon (cross-‐product issue) – BUT OpenFlow 1.3 version will expose these 39 What can you not do with OpenFlow ver1.0 • New forwarding primiVves – BUT provides a nice way to integrate them through extensions • New packet formats/field definiVons – BUT a generalized OpenFlow (2.0) is on the horizon • OpVcal Circuits – BUT efforts underway to apply OpenFlow model to circuits • Low-‐setup-‐Vme individual flows – BUT can push down flows proacVvely to avoid delays 40
- 21. 9/8/14 21 Where it’s going • OF v1.3: Spring 2013 – mulVple tables: leverage addiVonal tables – tags and tunnels – mulVpath forwarding – per flow meters • OF v2+ – generalized matching and acVons: protocol independent forwarding 41 Outline • SDN Basics – Concepts – OpenFlow – Switches and Controllers – OF-‐Config – Mininet 42
- 22. 9/8/14 22 Switches and Controllers • OpenFlow switches and vendors • Controllers – Floodlight 43 OpenFlow building blocks Controller NOX Slicing SoCware FlowVisor FlowVisor Console 44 ApplicaVons LAVI ENVI (GUI) Expedient n-‐CasVng NetFPGA SoCware Ref. Switch Broadcom Ref. Switch OpenWRT PCEngine WiFi AP Commercial Switches Stanford Provided OpenFlow Switches SNAC Stanford Provided Monitoring/ debugging tools oflops oCrace openseer OpenVSwitch HP, NEC, Pronto, Juniper.. and many more Beacon Helios Maestro 44
- 23. 9/8/14 23 Ciena Coredirector NEC IP8800 Current SDN hardware More coming soon... Juniper MX-series HP Procurve 5400 Pronto 3240/3290 WiMax (NEC) PC EnginesNetgear 7324 45 45 Commercial Switch Vendors Model Virtualize Notes HP Procurve 5400zl or 6600 1 OF instance per VLAN -‐ LACP, VLAN and STP processing before OpenFlow -‐ Wildcard rules or non-‐IP pkts processed in s/w -‐ Header rewriVng in s/w -‐ CPU protects mgmt during loop NEC IP8800 1 OF instance per VLAN -‐ OpenFlow takes precedence -‐ Most acVons processed in hardware -‐ MAC header rewriVng in h/w Pronto 3240 or 3290 with Pica8 or Indigo firmware 1 OF instance per switch -‐ No legacy protocols (like VLAN and STP) -‐ Most acVons processed in hardware -‐ MAC header rewriVng in h/w 46 46
- 24. 9/8/14 24 Controller Vendors Vendor Notes Nicira’s NOX • Open-‐source GPL • C++ and Python • Researcher friendly Nicira’s ONIX • Closed-‐source • Datacenter networks SNAC • Open-‐source GPL • Code based on NOX0.4 • Enterprise network • C++, Python and Javascript • Currently used by campuses Vendor Notes Stanford’s Beacon • Open-‐source • Researcher friendly • Java-‐based BigSwitch controller • Ha open source version • Based on Beacon • Enterprise network Maestro (from Rice Univ) • Open-‐source • Based on Java FreneVc or Ne_le • Open-‐source • Wri_en in funcVonal programming languages 47 47 Floodlight Architecture 48 Overview – Floodlight is a collecVon of modules – Some modules (not all) export services – All modules in Java – Rich, extensible REST API DeviceManager (IDeviceService) FloodlightProvider (IFloodlightProviderService) TopologyManager (ITopologyManagerService) RestServer (IRestApiService) StorageSource (IStorageSourceService) Forwarding StaVcFlowPusher (IStaVcFlowPusherService) LinkDiscovery (ILinkDiscoveryService) VirtualNetworkFilter (IVirtualNetworkFilterService) Source: Big Switch Networks
- 25. 9/8/14 25 Floodlight Architecture 49 Module descripVons DeviceManager (IDeviceService) FloodlightProvider (IFloodlightProviderService) TopologyManager (ITopologyManagerService) RestServer (IRestApiService) StorageSource (IStorageSourceService) Forwarding StaVcFlowPusher (IStaVcFlowPusherService) LinkDiscovery (ILinkDiscoveryService) VirtualNetworkFilter (IVirtualNetworkFilterService) ! DB style storage (queries, etc) ! Modules can access all data and subscribe to changes 49 • Computes shortest path using Dijsktra • Keeps switch to cluster mappings ! Installs flow mods for end-‐to-‐end rouVng ! Handles island rouVng ! Tracks hosts on the network ! MAC -‐> switch,port, MAC-‐>IP, IP-‐>MAC ! Implements via Restlets (restlet.org) ! Modules export RestletRoutable ! Supports the inserVon and removal of staVc flows ! REST-‐based API ! Maintains state of links in network ! Sends out LLDPs ! Create layer 2 domain defined by MAC address ! Used for OpenStack / Quantum ! Translates OF messages to Floodlight events ! Managing connecVons to switches via Ne_y Source: Big Switch Networks Floodlight Programming Model Northbound APIs Switch Switch vSwitch Switch IFloodlight-‐ Module External ApplicaVon REST IFloodlightModule ! Java module that runs as part of Floodlight ! Consumes services and events exported by other modules ! OpenFlow (ie. Packet-‐in) ! Switch add / remove ! Device add /remove / move ! Link discovery External ApplicaJon ! Communicates with Floodlight via REST ! Quantum / Virtual networks ! Normalized network state ! StaVc flows Floodlight Controller 50
- 26. 9/8/14 26 Network State List Hosts List Links List Switches GetStats (DPID) GetCounters (OFType…) 51 A moving target…but… REST API Reference StaJc Flows Add Flow Delete Flow List Flows RemoveAll Flows Virtual Network Create Network Delete Network Add Host Remove Host User Extensions … Floodlight Controller Switch Switch vSwitch Switch Source: Big Switch Networks • Fine-‐grained ability to push flows over REST • Access to normalized topology and device state • Extensible access to add new APIs 52 Using the REST API Programming Floodlight
- 27. 9/8/14 27 • Handle OpenFlow messages directly (ie. PacketIn) • Expose services to other modules • Add new REST APIs 53 CreaVng a module Programming Floodlight Source: Big Switch Networks Outline • SDN Basics – Concepts – OpenFlow – Switches and Controllers – OF-‐Config – Mininet 54
- 28. 9/8/14 28 55 • Bootstrap OpenFlow network • Switch connects to controller • Controller(s) to connect to must be configured at switches • Allocate resources within switches • Ports • Queues • . . . OpenFlow configuraVon and Management Protocol! controller switch switch switch switch controller 56 • Configuration Point • Source of switch configuration • OpenFlow Capable Switch • Hosts one or more logical switches OpenFlow configuraVon and Management Protocol: Reference Model ! OpenFlow Capable Switch resources (ports, queues) • OpenFlow Controller • OpenFlow Logical Switch • instance of an OpenFlow Switch OF Logical Switch OF Logical Switch ConfiguraVon Point ConfiguraVon Point OF-‐CONFIG ConfiguraVon Point OpenFlow Controller ConfiguraVon Point OpenFlow Controller OpenFlow OpenFlow using IETF Netconf & XML data models
- 29. 9/8/14 29 57 • OF-CONFIG 1.0 (Jan 2012) based on OpenFlow 1.2 • assigning controllers to logical switches • retrieving assignment of resources to logical switches • configuring some properties of ports and queues • OF-CONFIG 1.1 (Apr 2012) based on OpenFlow 1.3 • added controller certificates and resource type "table" • retrieving logical switch capabilities signaled to controller • configuring of tunnel endpoints • OF-CONFIG 1.1.1 (Aug 2012) based on OpenFlow 1.3.1 • consolidation of version 1.1, fixing small inconsistencies • OF-CONFIG 1.2 (early 2013) based on OpenFlow 1.3.1 • features still under discussion, candidates include • retrieving capable switch capabilities, configuring logical switch capab. • assigning resources to logical switches • simple topology detection • event notification OF-‐CONFIG Scope and Releases! WG established in Sep 2011 • Netconf was chosen as management protocol • not necessarily accepted as ideal solution • still discussing alternatives • XML schema was chosen as modeling language • Yang is also used, but XML is normative • normative XML schema generated from Yang code • So far, the focus has been on configuration • bootstrap of an OpenFlow network is the obvious first thing to do • New work items will be more on OAM • incl. event notifications 58 Use of Netconf and Yang!
- 30. 9/8/14 30 Outline • SDN Basics – Concepts – OpenFlow – Switches and Controllers – OF-‐Config – Mininet 59 Mininet • Machine-‐local virtual network – great dev/tesVng tool • Uses linux virtual network features – Cheaper than VMs • Arbitrary topologies, nodes 60
- 31. 9/8/14 31 Mininet (Cont’d) • Rapidly prototype, develop and test – InteresVngly-‐sized networks (16-‐100 nodes) start up in seconds – No lengthy lab reconfiguraVon or rebooVng required – Always-‐accessible network resources, in any topology, at essenVally no cost – Designs that work on Mininet transfer seamlessly to hardware for full speed operaVon 61 Mininet (Cont’d) • Repeatably test, analyze, and predict network behavior – Easy replicaVon of experimental and test results – Examine effects of code or network changes before tesVng/deploying on hardware – Allows automated system-‐level tests and experiments – Recreate real-‐world network and test cases for a variety of topologies and configuraVons 62
- 32. 9/8/14 32 Mininet (Cont’d) • Quickly get up and running – Free and permissively licensed (BSD) – Minimal hardware requirements – Accessible to novices thanks to simple CLI – Smooth learning curve thanks to walkthrough, tutorial, examples and API documentaVon – Strong users and support community 63 QuesVons? 64