1 / 26

SDN & OpenStack

SDN & OpenStack. 邱见 IBM Platform Computing. Outlines. SDN briefing OpenStack network component OpenStack and SDN. A Short History of SDN. ~2004: Research on new management paradigms RCP, 4D [Princeton, CMU,….] SANE, Ethane [Stanford/Berkeley] 2008: Software-Defined Networking (SDN)

Download Presentation

SDN & OpenStack

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. SDN & OpenStack 邱见 IBM Platform Computing

  2. Outlines • SDN briefing • OpenStack network component • OpenStack and SDN

  3. A Short History of SDN ~2004: Research on new management paradigms RCP, 4D [Princeton, CMU,….] SANE, Ethane [Stanford/Berkeley] 2008: Software-Defined Networking (SDN) NOX Network Operating System [Nicira] OpenFlow switch interface [Stanford/Nicira] 2011: Open Networking Foundation (~69 members) Board: Google, Yahoo, Verizon, DT, Microsoft, Facebook, NTT Members: Cisco, Juniper, HP, Dell, Broadcom, IBM,….. 2013: Google deployed SDN on its data center backbone network 3

  4. Why Was SDN Needed? • Networks are hard to manage • Computation and storage have been virtualized • Creating a more flexible and manageable infrastructure • Networks are still notoriously hard to manage • Networks are hard to evolve • 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 • Networks design not based on formal principles • 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 general design guidelines 4

  5. The Two Networking “Planes” • Data plane: processing and delivery of packets with local forwarding state • Forwarding state + packet headerforwarding decision • Control plane: compute the state in routers (forwarding state) • Determines how and where packets are forwarded • Routing, traffic engineering, firewall state, … • Implemented with distributed protocols, manual configuration (and scripting) or centralized computation • These different planes require different abstractions 5

  6. Data Plane Abstractions: Layers Applications …built on… Reliable (or unreliable) transport …built on… Best-effort global packet delivery …built on… Best-effort local packet delivery …built on… Local physical transfer of bits 6

  7. (Too) Many Control Plane Mechanisms • Variety of goals: • Routing: distributed routing algorithms • Isolation: ACLs, VLANs, Firewalls,… • Traffic engineering: adjusting weights, MPLS,… • No modularity, limited functionality • Control Plane: mechanism without abstraction • Too many mechanisms, not enough functionality 7

  8. SDN: Two Control Plane Abstractions • Abstraction: global network view • Provides information about current network • Implementation: “Network Operating System” • Runs on servers in network (replicated for reliability) • Abstraction:forwarding model • Provides standard way of defining forwarding state • This is OpenFlow • Specification of <match,action> flow entries 8

  9. Network of Switches and/or Routers SDN is “Layers” for Control Plane Traditional Control Mechanisms routing, access control, etc. ControlProgram Global Network View Distributedalgorithmrunningbetweenneighbors Network OS (e.g. NOX) Complicatedtask-specific distributedalgorithm Forwarding Model 9

  10. Example: Load Balancing Optimal Load Balancer: Ideally each HTTP request would be sent over a path which is lightly loaded to a server which is lightlyloaded in order to minimize the request 10

  11. Example: Load Balancing Current Load Balancer: it can choose only the lightly loaded server KEMP Technologies LoadMasterTM 2400 11

  12. Example: Load Balancing 12

  13. Network Virtualization • Introduce new abstraction and new SDN layer • Abstraction: Virtual Topology • Allows operator to express requirements and policies • Via a set of logical switches and their configurations • Layer: Network Hypervisor • Translates those requirements into switch configurations • “Compiler” for virtual topologies 13

  14. Virtualization Simplifies Control Program Abstract Network View A AB drop B Hypervisor then inserts flow entries as needed A AB drop Global Network View AB drop B 14

  15. ControlProgram SoftwareDefinedNetwork Virtual Topology Network Hypervisor Global Network View Network OS 15

  16. Does SDNhave larger implications? Asidefromprovidingeasiernetworkmanagement, howwillSDNchangetheworldofnetworking? 16

  17. Control/Data Planes Become Separate • Currently control plane tied to data plane • NOS runs on servers: observes/controls data plane • Changes the deployment and business models • Can buy the control plane separately from the switches • Enabling commodity hardware and 3rd party software • Changes the testing model • Simulator to analyze large-scale control planes 17

  18. Networking Becomes Edge-Oriented • Canimplementmostcontrol functionalityatedge • Access control,QoS, mobility, migration,monitoring… • Networkcoremerelydeliverspacketsedge-to-edge • Current protocolsdo agoodjob (mostly) • Letedgehandleallcomplexity • Complicatedmatching, actions • “Overlay” networkingviatunnels • Thishastwo importantimplications 18

  19. 1. Makes SDN Incrementally Deployable • HostsoftwareoftenhasOpenFlowswitch • Open vSwitch(OVS)inLinux,Xen,… • Theedgebecomesasoftwareswitch • Coreofnetworkcan be legacyhardware • EnablesincrementaldeploymentofSDN • Might never needOpenFlowinhardwareswitches…. 19

  20. 2. Networking Becomes Software-Oriented • Allcomplicated forwardingdoneinsoftware(edge) • Andcontrolplane isaprogram(onaserver)… • …not aprotocol(on aclosedproprietary switch/router) • Weareprogrammingthenetwork,notdesigningit • Focus onmodularityandabstractions, not packetheaders • Innovationatsoftware,nothardware,speeds • Softwarelendsitselftocleanabstractions 20

  21. Neutron in OpenStack 21

  22. Network As A Service • Provides REST APIs to manage network connections for theresources managed by other OpenStack Services (e.g. Nova) • Technology Agnostic (framework based on “plug-ins”) • Multi-tenancy: Isolation, Abstraction, full control over virtualnetworks • Modular Design: API specifies service, vendor provides itsimplementation. Extensions for vendor-specific features. • Standalone Service : It is not exclusive to OpenStack. Neutronis an autonomous service • Exposes vendor-specific network virtualization and SDNtechnologies

  23. Neutron in Compute Node

  24. Neutron in Network Node

  25. Neutron in Network Node • Neutron is not SDN, but a framework to enable SDN functionality • Nicira Network Virtualization Platform (NVP) Plugin • Ryu OpenFlow Controller Plugin • NEC OpenFlow Plugin • Brocade Neutron Plugin Brocade Neutron Plugin • PLUMgrid Plugin • IBM SDN-VE Plugin • Starting with Havana release, Modular Layer 2 (ML2) plugin replaces OVS and LinuxBridge plugins. • type drivers to support multiple networking technologies • mechanism drivers to facilitate the access to the networking configuration in a transactional model

  26. Thanks!

More Related