Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

IEEE HPSR 2017 Keynote: Softwarized Dataplanes and the P^3 trade-offs: Programmability, Performance, Portability

219 views

Published on

The realization of network softwarization, an overarching buzzword to encompass all software-centric developments from the Software-Defined Networking (SDN) and Network Function Virtualization (NFV) trends, is being enabled through a set of innovations in high-speed data plane design and implementation. Recent efforts include te-architecting the hardware-software interfaces and exposing programmatic interfaces (e.g., OpenFlow), programmable hardware-based pipelines (e.g. Protocol Independent Switch Architecture – PISA) along suitabe programming languages (e.g., P4), and multiple advances on low overhead virtualization and fast packet processing libraries (e.g. DPDK, FD.io) for Linux based general purpose processor platforms. This talk provides an overview of relevant ongoing work and discusses the trade-offs of each design and implementation choice of software-defined dataplanes regarding Programmability, Performance, and Portability.

Published in: Technology
  • Be the first to comment

IEEE HPSR 2017 Keynote: Softwarized Dataplanes and the P^3 trade-offs: Programmability, Performance, Portability

  1. 1. Softwarized dataplanes and the P3 trade-offs: Programmability, Performance, Portability Prof. Christian Esteve Rothenberg (DCA/FEEC/UNICAMP) IEEE 18th International Conference on High Performance Switching and Routing 18-21 JUNE 2017 // CAMPINAS, BRAZIL
  2. 2. 2 Agenda • Network Softwarization oIntroduction & Motivation oBackground & Intellectual History • On Trade-offs in Distributed Systems &Networking • The P3 trade-offs of softwarized data planes
  3. 3. Introduction & Motivation Network Softwarization
  4. 4. Network Softwarization i.e., NFV/SDN/xyz Existing • CLIs • Closed Source • Vendor Lead • Classic Network Appliances New • APIs • Open Source • Customer Lead • Virtual Network Functions (NFV) Source: Adapted from Kyle Mestery, Next Generation Network Developer Skills Programmability SW
  5. 5. 5 A means to make the network more flexible and simple by minimising dependence on HW constraints The NFV Concept Source: Adapted from Raj Jain
  6. 6. 6 Network equipment as Black boxes Open interfaces (OpenFlow) for instructing the boxes what to do SDN Boxes with autonomous behaviour Decisions are taken out of the box FEATURE FEATURE OPERATING SYSTEM SPECIALIZED PACKET FORWARDING HARDWAREFEATURE FEATURE OPERATING SYSTEM SPECIALIZED PACKET FORWARDING HARDWARE FEATURE FEATURE OPERATING SYSTEM SPECIALIZED PACKET FORWARDING HARDWAREFEATURE FEATURE OPERATING SYSTEM SPECIALIZED PACKET FORWARDING HARDWARE SDN Adapting OSS to manage black boxes Simpler OSS to manage the SDN controller SDN FEATURE FEATURE OPERATING SYSTEM SPECIALIZED PACKET FORWARDING HARDWAREFEATURE FEATURE OPERATING SYSTEM SPECIALIZED PACKET FORWARDING HARDWARE FEATURE FEATURE OPERATING SYSTEM SPECIALIZED PACKET FORWARDING HARDWAREFEATURE FEATURE OPERATING SYSTEM SPECIALIZED PACKET FORWARDING HARDWARE Software Defined Networking (SDN) Source: Adapted from D. Lopez Telefonica I+D, NFV
  7. 7. 7 NFV vs. SDN SDN ››› flexible forwarding & steering of traffic in a physical or virtual network environment [Network Re-Architecture] NFV ››› flexible placement of virtualized network functions across the network & cloud [Appliance Re-Architecture] (initially) ››› SDN & NFV are complementary tools for achieving full network programmability
  8. 8. 8 SDN & NFV :: Network Programmability / Flexibility Sources: Ahmad Rostami, Ericsson Research (Kista): http://www.itc26.org/fileadmin/ITC26_files/ITC26-Tutorial-Rostami.pdf and Uwe Michel, T-Systems
  9. 9. 10 Why Network Softwarization, i.e., NFV/SDN? 1. Virtualization: Use network resource without worrying about where it is physically located, how much it is, how it is organized, etc. 2. Orchestration: Manage thousands of devices 3. Programmability: Should be able to change behavior on the fly. 4. Dynamic Scaling: Should be able to change size, quantity, as a F(load) 5. Automation: Let machines / software do humans’ work 6. Visibility: Monitor resources, connectivity 7. Performance: Optimize network device utilization 8. Multi-tenancy: Slice the network for different customers (as-a-Service) 9. Service Integration: Let network management play nice with OSS/BSS 10. Openness: Full choice of modular plug-ins Source: Adapted from Raj Jain Portability?
  10. 10. 11 Why Network Softwarization, i.e., NFV/SDN? 1. Virtualization: Use network resource without worrying about where it is physically located, how much it is, how it is organized, etc. 2. Orchestration: Manage thousands of devices 3. Programmability: Should be able to change behavior on the fly. 4. Dynamic Scaling: Should be able to change size, quantity, as a F(load) 5. Automation: Let machines / software do humans’ work 6. Visibility: Monitor resources, connectivity 7. Performance: Optimize network device utilization 8. Multi-tenancy: Slice the network for different customers (as-a-Service) 9. Service Integration: Let network management play nice with OSS/BSS 10. Openness: Full choice of modular plug-ins Source: Adapted from Raj Jain Portability?
  11. 11. 12 Key benefits of programmable forwarding 1. New features: Realize new protocols and behaviors very quickly 2. Reduce complexity: Remove unnecessary features and tables 3. Efficient use of H/W resources: Achieve biggest bang for buck 4. Greater visibility: New diagnostics, telemetry, OAM, etc. 5. Modularity: Compose forwarding behavior from libraries 6. Portability: Specify behavior once; compile to many devices 7. Own your own network: No need to wait for next chips or systems Source: Adapted from SIGCOMM’16 P4 Tutorial
  12. 12. Background Background & Intellectual History
  13. 13. 14 Intellectual History of Programmable Networks Source: N. Feamster, J. Rexford, E. Zegura. The Road to SDN: An Intellectual History of Programmable Networks. SDN NFV
  14. 14. 15 Network Programmability Layers Source: CISCO, Introducing Network Programmability Fundamentals Part#: CTOD-SDN-1.0-017141 https://learningnetworkstore.cisco.com/cyber-monday/introducing-network-programmability-fundamentals-elt-sdnb-1-0-019041
  15. 15. 16 Innovations of NFV Source: Adapted from Raj Jain
  16. 16. 17 Networking as Learned in School (text books) Source: Martin Casado CS244 Spring 2013, Lecture 6, SDN
  17. 17. 18 Networking in Practice “in theory,theoryandpracticearethesame; in practicetheyarenot...” Source: Martin Casado CS244 Spring 2013, Lecture 6, SDN
  18. 18. 19 Tens of Millions of lines of code Closed, proprietary, outdated Hundreds of protocols 6,500 RFCs Billions of gates Power hungry and bloated Vertically integrated, complex, closed, proprietary Not good for network owners and users Specialized Packet Forwarding Hardware Specialized Control Plane Specialized Features Problem with Internet Infrastructure Source: ON.LAB
  19. 19. 20 Trend Source: ON.LAB
  20. 20. 21 SDN to the rescue!
  21. 21. 22 So, What is SDN? “OpenFlow is SDN, but SDN is not OpenFlow” (Does not say much about SDN) ̶̶̶̶̶̶̶̶̶ Networking community “Don’t let humans do machines’ work” (probably right…) ̶̶̶̶̶̶̶̶̶ Networking Professional “Let’s call SDN whatever we can ship today” (aka SDN washing) ̶̶̶̶̶̶̶̶̶ Vendor X “SDN is the magic buzzword that will bring us VC funding” (hmmm… N/A, N/C) ̶̶̶̶̶̶̶̶̶ Startup Y “SDN is the magic that will get my paper/grant accepted” (maybe but not at HPSR?) ̶̶̶̶̶̶̶̶̶ Researcher Z
  22. 22. 23 SDN definitions • With the original (OpenFlow) definition, SDN represented a network architecture where the forwarding state is solely managed by a control plane and is decoupled from the data plane. • The industry, however, has moved on from the original academic purist view of SDN to referring to anything disruptive or fundamentally new as part of SDN. • At least two definitions for SDN: 1.academic (purist view : strict decoupling of the data and control plane) 2.industry (many-fold business-driven views) SDN :: evolving definition
  23. 23. 24 SDN asks (at least) three major questions Where the control plane resides “Distributed vs Centralized” ? How does the Control Plane talk to the Data Plane ? How are Control and Data Planes programmed ? Source: Adapted from T. Nadeu, slides-85-sdnrg-5.pptx
  24. 24. 25 SDN asks (at least) three major questions Where the control plane resides “Distributed vs Centralized” ? • What state belongs in distributed protocols? • What state must stay local to switches? • What state should be centralized? • What are the effects of each on: - State synchronization overhead - Total control plane overhead - System stability and resiliency - Efficiency in resource use - Control loop tightness Source: Adapated from E. Crabbe, slides-85-sdnrg-7.pdf 1
  25. 25. 26 SDN asks (at least) three major questions • Prop. IPC • OpenFlow (with or w/extensions) • Open Source south-bound protocols • Via SDN controller broker and south-bound plug-ins • Other standardized protocols • What are the effects of each on: - Interoperability, Evolvability, Performance - Vendor Lock-in How does the Control Plane talk to the Data Plane ?2 Source: Adapated from E. Crabbe, slides-85-sdnrg-7.pdf
  26. 26. 27 SDN asks (at least) three major questions • Levels of Abstraction • Domain Specific Language • Open APIs • Standardized Protocols • What are the effects of each on: - Data plane flexibility and performance - Integration with legacy - Interoperability (CP / DP) - Vendor lock-in How are Control and Data Planes programmed ?3 Source: Adapated from E. Crabbe, slides-85-sdnrg-7.pdf
  27. 27. 28 V 1.0 :: Single flow table as prioritized list of rules • Priority: disambiguate overlapping patterns • Pattern: match packet header bits • Actions: drop, forward, modify, send to controller • Counters: number of bytes and packets Priority Pattern Actions Counters 3 srcip=1.0.*.* Forward(1) 3, 4500 2 dstip=1.2.3.4, dstport=80 dstip:=10.0.0.1, Forward(2) 5, 6018 1 srcport=25 Send to controller 1, 512 0 * Drop 2, 1024
  28. 28. 29 Enabling New SDN Applications • Wide-area traffic engineering • Network virtualization for multi-tenant data centers • Steering traffic through middleboxes • Seamless mobility and migration • Server load balancing • Dynamic access control • Using multiple wireless access points • Energy-efficient networking • Blocking denial-of-service attacks • Adaptive traffic monitoring • <Your app here!> Source: Image, Xinguard | OpenFlow principle
  29. 29. 30 Limitations of OpenFlow 1.0 • Most switches can do much more • Multiple stages of match-action tables • E.g., Ethernet, IP, access control lists (ACLs) • Many applications need much more • Multiple policies (e.g., ACL, routing, monitoring) • Matching on more header fields • Limited TCAM space in legacy switches • E.g., a few thousand rules in the wide TCAM 30 MAC learning Access control IP Source: J. Rexford / P4
  30. 30. 31 Over the Past Five Years… Version Date # Headers OF 1.0 Dec 2009 12 OF 1.1 Feb 2011 15 OF 1.2 Dec 2011 36 OF 1.3 Jun 2012 40 OF 1.4 Oct 2013 41 • Proliferation of header fields • Multiple stages of heterogeneous tables • Still not enough (e.g., VXLAN, NVGRE, STT, …) • The HW vs. SW divide on OpenFlow v1.x support (+ optional features!)
  31. 31. 32 Future SDN Switches (New generation of switch ASICs) • Configurable packet parser • Not tied to a specific header format • Flexible match+action tables • Multiple tables (in series and/or parallel) • Able to match on all defined fields • General packet-processing primitives • Copy, add, remove, and modify • For both header fields and meta-data PISA : Profocol Independent Switch Architecture P A R S E R Match Action
  32. 32. 34 Datapath Programmability Programmable Network Devices • PISA: Flexible Match+Action ASICs ◦ Intel Flexpipe, Cisco Doppler, Cavium (Xpliant), Barefoot Tofino, • NPU ◦ EZchip, Netronome, … • FPGA ◦ Xilinx, Altera, (Intel) • CPU ◦ Open Vswitch, eBPF, DPDK, VPP... But, programming these chips is hard • Custom, vendor-specific interfaces • Low-level, think microcode programming
  33. 33. 35 Programming Protocol-independent Packet Processors • High Level Abstractions • Protocol Independent • Target Agnostic • Language & Architecture Separation • Multiple ingress/egress pipeline support See http://p4.org/ for code and specs (The current release of the language is P416)
  34. 34. 36 P4 :: Three Goals Protocol independence ◦ Define a packet parser ◦ Define a set of typed match+action tables Target independence ◦ Program without knowledge of packet- processing device details ◦ Let compilers configure the target device In-field Re-configurability ◦ Allow the users to change parsing and processing program in the field P. Bosshart, D. Daly, G. Gibb, M. Izzard, N. McKeown, J. Rexford, C. Schlesinger, D. Talayco, A. Vahdat, G. Varghese, and D. Walker “P4: Programming protocol-independent packet processors,” SIGCOMM CCR, July 2014
  35. 35. 37 P4 :: All the way down to programmability P4 configuration abstractions: • Header – Ordered list of fields with name and width • Parser – State machine traversing the packet to extract header fields (If ethertype == 0x800 then…) • Action functions – Custom functions made of primitive actions (add_field,remove_header, copy, set, increment, checksum, etc…) • Typed tables – What fields are matched in what way (exact match, longest prefix, range, etc...) • Control flow – Table application order, conditionals, functions • Stateful memories – Counters, meters and registers which persist across packets
  36. 36. 38 P4 :: All the way down to programmability
  37. 37. 39 “Classic” OpenFlow (1.x) vs. “OpenFlow 2.0” 39 Target Switch SDN Control Plane Populating Installing and querying rules Target Switch SDN Control Plane Populating: Installing and querying rules Compiler Configuring: Parser, tables, and control flow Parser & Table Configuration Rule Translator
  38. 38. 41 P4-Based Workflow
  39. 39. 42 Legacy Different SDN Models to Program / Refactor the Stack Data Plane Mgm.APIs Distributed L2/L3 Control Plane Managemt Software Southbound Agent (e.g. OF) Network Controller / OS Southbound Protocol (e.g. OF) Business / Control Apps Northbound APIs Mgm. HAL APIs / Drivers Orchestrator APIs Compiler Auto-GeneratedTarget Binary SDN VNF GP-CPU (x86, ARM) HW Resources Virtualization DP CP M g m. NFV VNFM (Manager) VIM (Infra-M) OSS/BSS APIs Southbound APIs/Plugins Mgm. Apps Network OS / Bare Metal Switches
  40. 40. On trade-offs in networking Including discussion on Universal Laws and Architectures
  41. 41. 48 Trade-offs :: There are many…
  42. 42. 49 Trade-offs :: More…
  43. 43. 50 P^3 trade-offs in Network Softwarization Realm of the Impossible ? Plane of the Possible? Performance Performance Portability Programmability
  44. 44. 51 Slide courtesy: D. Meyer
  45. 45. 52 Source: D. Meyer On Universal Laws and Architectures [Turing] Performance Programmability
  46. 46. 53 Source: J. Doyle On Universal Laws and Architectures Performance Programmability
  47. 47. 54 Overlaying Tradeoffs Slide courtesy: D. Meyer / J. Doyle Programmability Performance
  48. 48. 55 Layered architectures make Robustness and Evolvability compatible Source: adapted from D. Meyer / Doyle Think OS Kernel + Libraries/Drivers • Plug-in Architectures • Control Plane Drivers + APIs • Model-Driven Everything SDN / NFV Orchestrator?
  49. 49. 56 Source: J. Doyle Universal Laws and Architectures
  50. 50. 57 Universal Laws and Architectures
  51. 51. 59 P3 trade-offs: Programmability, Performance, Portability :: packets/sec processed (could be normalized per Energy or Cost) :: ability to (re-)define the dataplane behaviour :: ability to easily transfer the dataplane logic to a new platform
  52. 52. 60 P3 trade-offs: Programmability, Performance, Portability Realm of the Impossible? How to push the hard limits?
  53. 53. 61 Dataplane trade-offs: Programmability, Performance Performance Programmability ASIC NPU CPU x86 Cavium TX Ethernet switch Assuming same use case. Normalized for chip technology and transistor count. How big is the difference? Source: Pongracz G, Molnar L, Kis ZL, Turanyi Z. Cheap silicon: a myth or reality? Picking the right data plane hardware for software defined networking. HotSDN13 + +
  54. 54. 62 Programmability Portability P3 trade-offs: Programmability, Performance, Portability ASIC NPU CPU Performance + How portable is the code defining the logic of an ASIC-based dataplane or the SW-based dataplane on an NPU or CPU?
  55. 55. 63 P3 trade-offs: Increasing Performance • Overcoming the memory wall • Structured ASICs • PISA: New generation of switch ASICs • High-performance FPGAs • Fotonics & Packet Optical Integration • Moore’s law goes manycore • Advances in high-performance (virtualized) networking stacks • Fast packet Linux I/O (DPDK, PF_RING, Netamp, VPP…)
  56. 56. 64 P3 trade-offs: Increasing Portability • OpenFlow model not enough • Dataplane abstractions + Open APIs, e.g. ODP • High-level DSL (and IR?) e.g., P4 • Multi-Architecture Compiler toolchains • Model-based everything • e.g., YANG Source: ONF PIF
  57. 57. 65 P3 trade-offs: Increasing Programmability • SDN + NFV • New Programming languages at diferent layers • Automation • New control loops (feat. Analytics/AI) • aka. Knowledge-Defined Networking (KDN) • Open Source • Open source SW, HW (think Open Compute Project) • APIs APIs APIs • Model-driven networking (taming complexity) • https://www.ericsson.com/research-blog/sdn/model-driven-networking-looom/
  58. 58. 66 Limits of human understanding Technological limits Hand Crafted Code Modeling + Code Gen Slide courtesy of Jonathan Lynam (Ericsson), suggested by Attila Takacs (Ericsson, Inspired by Vinod Khosla @ ONS2014 further info: https://www.ericsson.com/research-blog/sdn/model-driven-networking-looom/ Hand Crafted: * Lower apparent barrier to entry * Domain Experts + programmers = ??? Speed, Capacity, Features Complexity Tools Driven * Higher initial complexity * Machinists, not just Tailors + Apprentices Goal: keep curve more flat
  59. 59. 67 Conclusions • Exciting times to be in networking • Software-driven • The future is all about Software Ecosystems • Open Interfaces: Protocols, APIs, Code, Tool Chains / “Best of Breed” markets • Multiple disciplines clashing together • Networking, OS, compilers, computer architectures, HW/SW co-design • Fundamental trade-offs • Technology breakthroughts pushing the hard limits • Intellectual contributions needed • Models and automation • Cost and economic factors as usual will drive winning aproaches
  60. 60. 68 References / Further Reading • John Doyle, Universal laws and architecture • David Meyer, Macro Trends, Architecture, and the Hidden Nature of Complexity (and what does this have to do with SDN?) • Russ White, Tradeoffs in Network Complexity • P4: http://p4.org/ for code and specs (Current release is P416) • A. Capone & C. Cascone, SDN tutorial, IEEE Netsoft 2015 • Jonathan Lynam, Model-driven networking, 2016 • Diego Kreutz et al., "Software-Defined Networking: A Comprehensive Survey." In Proceedings of the IEEE, Vol. 103, Issue 1, Jan. 2015. • Pattam Gyanesh Patra, Christian Esteve Rothenberg, Gergely Pongrácz. "MACSAD: High Performance Dataplane Applications on the Move". In IEEE 18th International Conference on High Performance Switching and Routing (HPSR), Campinas, Brazil, Jun. 2017. • Ahmad Rostami, Katia Obraczka, and Christian Esteve Rothenberg. Tutorial on SDN, NFV and Their Role in 5G. In ACM SIGCOMM Tutorials, Florianopolis, Brazil, Aug. 2016.
  61. 61. Thank you! Questions?
  62. 62. 70 Performance Programmability Portability P3 trade-offs: Programmability, Performance, Portability
  63. 63. 71 MACSAD Architecture & Workflow 71
  64. 64. BACKUP
  65. 65. • Assistant Professor (tenure track) at FEEC/UNICAMP (since 2013) • PI leading the INTRIG lab at DCA/FEEC/UNICAMP INTRIG: Information & Networking Technologies Research & Innovation Group • Currently, supervising 7 PhD, 5 MSc candidates, and 4 undergrad students • Research Scientist at CPqD R&D Center in Telecommunication (2010-2013) • Technical Lead of pioneering SDN/OpenFlow activities in the Converged Networking Division • ONF Research Associate (since Apr/2013) • PhD in Electrical and Computer Engineering (FEEC/UNICAMP, 2010) • MSc in Electrical Eng and Information Technology (Darmstadt University, 2006) • Bachelor Eng Telecommunication (Universidad Politécnica de Madrid, 2004) About: Christian Esteve Rothenberg http://www.dca.fee.unicamp.br/~chesteve/
  66. 66. Research Interests & Results Software Defined Networking Information Centric Networking Network Functions Virtualization • RouteFlow (hybrid IP-SDN) • softswitch13 • libfluid (ONF Driver) • Mininet-WiFi :: Wireless / Mobility • SDN-2-SDN Peering • MD2-NFV (Multi-Domain Distributed) • Mini-CCNx -> Mini-NDNx • LIPSIN (in-packet Bloom filters) • Semantic/Ontology-based SW architectures • 10G+ VNF / Multi-Core Architectures • VNF-a-a-S / Benchmarking
  67. 67. Research Questions on NFV/SDI • VNF Benchmarking Methodology & a-a-S APIs and Lifecycle Workflows • Reproducible Research / R&D / Q&A Practices + Open Source & DevOps • Highest level Network Service Description & Orchestration (aka. NSO, LSO, LCM) • Multi-Domain, Peering, Exchanges :: New business models and Information Modeling • High Performance, Open Source Stacks & Programmable DP (P4)
  68. 68. Open Source minded Research @ • Extensive use of open source in support of research activities. • Etherpad, Owncloud, Docker, Gitlab, etc. • Publish versions of papers (in submission/accepted) • Arxiv.org • Make “source code” of papers available • Overleaf, github • Release all research data to allow third parties to re-use and reproduce • Github, wiki + readme (instructions on how to reproduce the paper experiments) • Highlight the reproducibility aspect in the papers (today: plus, tomorrow: requirement/norm?) • Students use github (private->public) as the research dev repository • Even if no paper accepted or in early • Create community-oriented open source projects
  69. 69. Open Source Research Artifacts Technical lead of successful open source projects (see https://github.com/chesteve & https://github.com/intrig-unicamp): • Mininet-WiFi, Emulator for Software-Defined Wireless Networking • https://github.com/intrig-unicamp/mininet-wifi • libfluid, winner of the ONF Driver Competition (Mar/2014) • http://opennetworkingfoundation.github.io/libfluid/ • Mini-CCNx, fast prototyping and experimentation of CCN networks (2013 - ) • https://github.com/carlosmscabral/mn-ccnx • softswitch13, first OpenFlow 1.2 and 1.3 soft switch, controller, and testing framework [funded and in technical collaboration with Ericsson] (2011 - 2013) • https://github.com/CPqD/ofsoftswitch13 • RouteFlow, first IP routing architecture for SDN (2010 - ) • https://github.com/routeflow/ 77
  70. 70. 78 The high-performance gourmet recipe... ● Fast packet I/O (DPDK, PF_RING, Netamp, PFQ…) ● Concurrency? ○ Many applications are still implemented as single process/thread ● Lock-less programming (no mutexes or spinlock) ○ Lock-free/wait-free algorithm, amortized atomic operations (CAS and all.) ○ Memory Model (C11,C++11)? ● Polling vs latency ● Memory ○ Zero dynamic memory allocations (0-malloc) ○ Reduced true sharing, zero false-sharing of cache-line ○ NUMA and memory-aware applications? Hugepages? ● Affinity ○ Interrupt affinity of multi-queues NICs? ○ Process/thread pinning, cpu isolation and real-time scheduling... Source: Nicola Bonelli, Software acceleration for network applications and multi-core architectures.
  71. 71. 79 The missing Principles of Modularity Source: T. Koponen
  72. 72. One SDN to rule them all Actually not, different reasonable models and approaches to SDN are being pursued One SDN controller to rule them all, with a discovery app to find them, One SDN controller to tell them all, on which switchport to bind them. In the Data Center, where the packets fly. Source Poem: http://dovernetworks.com/?p=83 Further reading: http://theborgqueen.wordpress.com/2014/03/31/the-legend-of-sdn-one-controller-to-rule-them-all/
  73. 73. Different SDN Models Control-plane component(s) Data-plane component(s) Canonical/Open SDN Traditional Hybrid/Broker Overlay Compiler
  74. 74. Why Open Source in Networking? • Higher reliability, more flexibility • Faster, lower cost, and higher quality development • Collaborative decisions about new features and roadmaps • A common environment for users and app developers • Ability for users to focus resources on differentiating development • Opportunity to drive open standards Bottom Line: The open source model significantly accelerates consensus, delivering high performing, peer-reviewed code that forms a basis for an ecosystem of solutions. Source: Open Source in a Closed Network – Prodip Sen (OPNFV Summit 2015)
  75. 75. Standard Development & Open Source Organizations Source: SDN IEEE Outreach, http://sdn.ieee.org/outreach Academia Industry
  76. 76. Foundations : The New Player Target Collaboration • Neutral and non-competing • Legal framework for licensing, copyright, intellectual property management "Companies feel they can collaborate on an open source project through an independent, not-for-profit entity that they trust - this is incredibly important to them," --Allison Randa (Board President of Open Source Initiative)
  77. 77. Recent Events involving Open Source • The Battle for the Hypervisor Switch1 • Open vSwitch vs Nexus1000v vs Hyper-V Virtual Switch • The Battle for the Cloud: Stack Wars • Stack wars: OpenStack v. CloudStack v. Eucalyptus • The Battle for the SDN control platform • OpenDaylight vs Floodlight vs etc. etc. • The Battle for the SDN Northbound APIs • ONF vs OpenDaylight vs OpenStack vs etc. • ONF OpenFlow Driver Competition • An open source driver to accelerate developments 1http://www.networkworld.com/community/blog/battle-hypervisor-switch-and-future-networking
  78. 78. NFV >>> Accelerating Transformation Source: Adapted from D. Lopez Telefonica I+D, NFV
  79. 79. Sisyphus on Different Hills Telco Operators Equipment Vendors SDOs 2-6 Years Demand Drive Standardise Implement Sell Deploy Critical mass of supporters Develop Deploy Publish 2-6 Months Telco Cycle Service Providers Cycle 2-6 years 2-6 months Service Providers AVAILABLE AVAILABLE Idea !! Idea !! Source: Telefonica I+D / ETSI NFV
  80. 80. Open Source SDN/NFV & Standardization Evolving and accelerating the path to standardization Further Reading: • IETF Trends and Observations draft-arkko-ietf-trends-and-observations-00 • Source of table: "When Open Source Meets Network Control Planes." In IEEE Computer (Special Issue on Software-Defined Networking), vol.47, Nov. 2014. • Source of figure: A. Manzalini et al., “ Towards 5G Software-Defined Ecosystems”
  81. 81. Open Source Building Blocks 2015 – 2016: Several New Projects Source: The Open Source NFV Eco-system and OPNFV’s Role Therein – Frank Brockners (OPNFV Summit 2016)
  82. 82. NFV Growing ecosystem © Fraunhofer FOKUS NFVO
  83. 83. A growing ecosystem...
  84. 84. 5G Related Open Source
  85. 85. Experimentation
  86. 86. Testbeds Source: http://www.5g-berlin.org/
  87. 87. Continuous Integration Environment • Continuous Integration tool chain speeds development and facilitates collaboration • Gerrit – code review tool • GitHub - code repository • Jenkins – automated build tool • Maven – code build • Ansible/Chef/Puppet – code deployment tool • Docker/Vagrant – deployment to Containers/VMs Source: Open Source Carrier Networking – Chris Donley (OPNFV Summit 2016)
  88. 88. Example: NTT (TM FORUM 2016) Source: A Transformation From Legacy Operation to Agile Operation – Makoto Eguchi (TM FORUM 2016)
  89. 89. All of This Leads Us To … Software Defined Networking DevOps Defined Networking DevOps Slide courtesy: Kyle Mestery
  90. 90. Detour on Layered Architectures and Complexity And what does this have to do with SDN and Open Source
  91. 91. Some experiences and ongoing activities
  92. 92. More info: Mininet-WiFi: Emulating Software-Defined Wireless Networks https://github.com/intrig-unicamp/mininet-wifi 100 Mininet-WiFi
  93. 93. More info: Demos Video 01: https://www.youtube.com/watch?v=_PtSmhf7Z8s Video 02: https://www.youtube.com/watch?v=H46EPuJDJhc Video 03: https://www.youtube.com/watch?v=WH6bSOKC7Lk Mininet-WiFi :: Use Cases
  94. 94. 10 2 Trade-offs State Surface Optimization Performance Portability Programmability

×