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
Agenda
• Network Softwarization
oIntroduction & Motivation
oBackground & Intellectual History
• On Trade-offs in Distributed Systems &Networking
• The P3 trade-offs of softwarized data planes

3. Introduction & Motivation
Network Softwarization

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
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
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
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
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. 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. 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. 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. Background
Background & Intellectual History

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. 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. 16
Innovations of NFV
Source: Adapted from Raj Jain

16. 17
Networking as Learned in School (text books)
Source: Martin Casado CS244 Spring 2013, Lecture 6, SDN

17. 18
Networking in Practice
“in theory,theoryandpracticearethesame;
in practicetheyarenot...”
Source: Martin Casado CS244 Spring 2013, Lecture 6, SDN

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. 20
Trend
Source: ON.LAB

20. 21
SDN to the rescue!

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 38
P4 :: All the way down to programmability

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. 41
P4-Based Workflow

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. On trade-offs in networking
Including discussion on Universal Laws and Architectures

41. 48
Trade-offs :: There are many…

42. 49
Trade-offs :: More…

43. 50
P^3 trade-offs in Network Softwarization
Realm of
the
Impossible
?
Plane of the
Possible?
Performance
Performance
Portability Programmability

44. 51
Slide courtesy: D. Meyer

45. 52
Source: D. Meyer
On Universal Laws and Architectures [Turing]
Performance
Programmability

46. 53
Source: J. Doyle
On Universal Laws and Architectures
Performance
Programmability

47. 54
Overlaying Tradeoffs
Slide courtesy: D. Meyer / J. Doyle
Programmability
Performance

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. 56
Source: J. Doyle
Universal Laws and Architectures

50. 57
Universal Laws and Architectures

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. 60
P3 trade-offs: Programmability, Performance, Portability
Realm of the
Impossible?
How to push the hard limits?

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. 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. 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. 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. 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. 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. 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. 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. Thank you!
Questions?

62. 70
Performance
Programmability
Portability
P3 trade-offs: Programmability, Performance, Portability

63. 71
MACSAD Architecture & Workflow 71

64. BACKUP

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. 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. 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. 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. 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. 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. 79
The missing Principles of Modularity
Source: T. Koponen

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. Different SDN Models
Control-plane component(s) Data-plane component(s)
Canonical/Open SDN
Traditional
Hybrid/Broker Overlay
Compiler

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. Standard Development & Open Source Organizations
Source: SDN IEEE Outreach, http://sdn.ieee.org/outreach
Academia
Industry

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. 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. NFV >>> Accelerating Transformation
Source: Adapted from D. Lopez Telefonica I+D, NFV

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. 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. 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. NFV Growing ecosystem
© Fraunhofer FOKUS
NFVO

83. A growing ecosystem...

84. 5G Related Open Source

85. Experimentation

86. Testbeds
Source: http://www.5g-berlin.org/

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. Example: NTT (TM FORUM 2016)
Source: A Transformation From Legacy Operation to Agile Operation – Makoto Eguchi (TM FORUM 2016)

89. All of This Leads Us To …
Software Defined Networking
DevOps Defined Networking
DevOps
Slide courtesy: Kyle Mestery

90. Detour on Layered Architectures and
Complexity
And what does this have to do with SDN and Open Source

91. Some experiences and ongoing activities

92. More info: Mininet-WiFi: Emulating Software-Defined Wireless Networks
https://github.com/intrig-unicamp/mininet-wifi 100
Mininet-WiFi

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. 10
2
Trade-offs
State
Surface Optimization
Performance
Portability Programmability