SDN :: Software Defined Networking –2017 Executive Overview

SDN :: Software Defined Networking –
2017 Executive Overview
PI: Prof. Christian Esteve Rothenberg
19/10/2017 @ Padtec, Campinas
Department of Computer Engineering and Industrial Automation (DCA)
Faculty of Electrical and Computer Engineering (FEEC)
University of Campinas (UNICAMP)

2
What is SDN (Software-Defined Networking)?

3
So, what is SDN?
“OpenFlow is SDN, but SDN is not OpenFlow” ̶̶̶̶̶̶̶̶̶ Networking community
(Does not say much about SDN)
“Don’t let humans do machines’ work” ̶̶̶̶̶̶̶̶̶ Networking Professional
(probably right…)
“Let’s call SDN whatever we can ship today” ̶̶̶̶̶̶̶̶̶ Vendor X
(aka SDN washing)
“SDN is the magic buzzword that will bring us VC funding” ̶̶̶̶̶̶̶̶̶ Startup Y
(hmmm… N/A, N/C)
“SDN is the magic acronym that will get my paper/grant accepted” ̶̶̶̶̶̶̶̶̶ Researcher Z
(maybe but not at tier 1 conferences / funding agencies)

5
SDN evolving 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 innovative as part of SDN.
• At least two classes of definitions for SDN:
1.academic or purist view :: strict decoupling of the data & control planes
2.industry :: many-fold business-driven views

6
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 (and vendors?)
Specialized Packet
Forwarding Hardware
Specialized Control
Plane
Specialized Features
Problem with Networking Infrastructure
Source: ON.LAB

7
When you need a new feature…
Source: Nick McKeown. “Programmable forwarding planes are here to stay”. In ACM SIGCOMM NetPL 2017

8
When you need a new feature…
1. Equipment vendor can’t just send you a software upgrade
2. New forwarding features take years to develop
3. By then, you’ve figured out a kludge to work around it
4. Your network gets more complicated, more brittle
5. Eventually, when the upgrade is available, it either
• No longer solves your problem, or
• You need a fork-lift upgrade, at huge expense.

10
Networking & Domain Specific Processors
CPU
Computers
Java
Compiler
GPU
Graphics
OpenCL
Compiler
DSP
Signal
Processing
Matlab
Compiler
Machine
Learning
?
TPU
TensorFlow
Compiler
Networking
?
Language
Compiler>>> ?

11
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
FORWARDINGHARDWAREFEATURE FEATURE
OPERATING SYSTEM
SPECIALIZED PACKET
FORWARDINGHARDWARE
FEATURE FEATURE
OPERATING SYSTEM
SPECIALIZED PACKET
FORWARDINGHARDWAREFEATURE FEATURE
OPERATING SYSTEM
SPECIALIZED PACKET
FORWARDINGHARDWARE
Software Defined Networking (SDN) : Concepts
Source: Adapted from D. Lopez Telefonica I+D, NFV

12
Whitebox SDN :: Shift to Open & Flexible
Source: Adapted from Chris Rice (AT&T Labs), Whitebox and Autonomous Networks
Open Interfaces

13
Whitebox :: Disaggregation of Network Elements
Source: *Chris Rice (AT&T Labs), Whitebox and Autonomous Networks

14
Whitebox :: Opportunity & Benefits
Opportunity
• Not Custom Built
• Open Platform/Interfaces
• Off-the-Shelf Technology
• Multi-Vendor Sourced
• Network ASIC Data Plane
Source: Chris Rice (AT&T Labs), Whitebox and Autonomous Networks, Open Source Summit North America 2017

15
Whitebox :: Opportunity & Benefits
Benefits
• Modular with Open Interfaces
• Built on Merchant Silicon
• Lower CAPEX and OPEX for the
new solution
• Better visibility and input into
silicon roadmap
• Using original design
manufacturers (ODMs) for
hardware configurations
• A growing, open hardware
ecosystem in communities like the
Open Compute Project (OCP)
Source: Chris Rice (AT&T Labs), Whitebox and Autonomous Networks, Open Source Summit North America 2017

17
Challenge: Current hardware-centric path is unsustainable*
Source (Adapted) : Chris Rice (AT&T Labs), Whitebox and Autonomous Networks, Open Source Summit North America 2017
+ Operate

18
NFV :: Sisyphus on Different Hills
Source: Telefonica I+D / ETSI NFV

19
A means to make the network more flexible and simple by
minimising dependence on HW constraints
Network Functions Virtualization (NFV) : Main Concept
Source: ETSI NFV ISG

20
SDN & NFV :: Strategic Paradigms for Network Operators
Source: ETSI NFV ISG

21 SDN & NFV :: Network Programmability / Flexibility
Source: Ahmad Rostami (Ericsson Research) [http://www.itc26.org/fileadmin/ITC26_files/ITC26-Tutorial-Rostami.pdf] and Uwe Michel (T-Systems)

23
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, advanced telemetry > ML/AI
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

24
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

25
How (data plane) programmability is being used
• Subtract features: Reducing complexity
• Add proprietary features: Invent, differentiate, own
• Silicon independence: Breaking a lock-in
• Telemetry & measurement: Breaking a lock-in + enabling ML/Analytics
Source: Nick McKeown. “Programmable forwarding planes are here to stay”. In ACM SIGCOMM NetPL 2017)

26
Domain Specific Processors
CPU
Computers
Java
Compiler
GPU
Graphics
OpenCL
Compiler
DSP
Signal
Processing
Matlab
Compiler
Machine
Learning
?
TPU
TensorFlow
Compiler
PISA
Networking
P4
Compiler>>>

27
Barefoot Tofino 6.5Tb/s Switch (Dec. 2016)
65 x 100GE (or 260 x 25GE)
[Same power and cost as fixed-function switches]
Source: Nick McKeown. “Programmable forwarding planes are here to stay”. In ACM SIGCOMM NetPL 2017)

28
Network Softwarization (i.e., NFV/SDN/xyz)
Existing / Old
• CLIs
• Closed Source
• Vendor Lead
• Classic Network Appliances (HW)
New
• APIs
• Open Source
• Customer Lead
• Virtual Network Functions (NFV/SW)
Source: Adapted from Kyle Mestery, Next Generation Network Developer Skills

29
* e.g., https://www.sdxcentral.com/directory/nfv-sdn/comprehensive-list-of-sdn-apis/
Characteristics & Driving Forces / Trends
• APIs*
• Programmability (in-house + 3rd party features after purchase)
not just Configuration
• Model-based networking (YANG/Netconf, P4, TOSCA)
• Power of choice (modularity + commodization)
• Open Source
• Enables broad programmability
• Lowers entry barriers and moves the value proposition up the stack
(cf. Linux found. networking projects)
• Impact on standardization forces, PoCs, and in-house DevOps

30
SDN/NFV Open Source & Standardization
Evolving and accelerating the path to standardization
Further Reading:
• IETF Trends and Observations draft-arkko-ietf-trends-and-observations-00
• A. Manzalini et al., “Towards 5G Software-Defined Ecosystems”
• Source of table: "When Open Source Meets Network Control Planes." In IEEE Computer (Special Issue
on Software-Defined Networking), vol.47, Nov. 2014.

31
Standard Development & Open Source Organizations
Source: SDN IEEE Outreach, http://sdn.ieee.org/outreach

Open Source Building Blocks
2015 – 2017: Several New Foundation-incubated Projects
Source: The Open Source NFV Eco-system and OPNFV’s Role Therein – Frank Brockners (OPNFV Summit 2016)

33
Challenges: Closed vs. Open
Source: Open Source in a Closed Network – Prodip Sen (OPNFV Summit 2015)

34
* https://www.networkworld.com/article/2162002/lan-wan/chambers--cisco-will-be-more-of-a-software-and-services-company.html
Characteristics & Driving Forces / Trends
• Customer Lead
• Roadmap and PoC definition
• Differentiation through in-house DevOps
• Impact on Standardization and open source Foundations
• Virtual Network Functions (NFV: pure SW over commodity server)
• Software-minded networking companies and strategies
(e.g., 2012, Chambers*: “Cisco will be more of a software and services company -
The company's not just about boxes anymore”)
• Network-wide / Service / SW-Centric vs. HW/Box-centric deployments
• Cloud-like service offering and consumption (incl. as-a-Service / Pay-as-you-go
revenue models vs. traditional sales)

SDN ocean :: Technologies for multiple problems
Source: B. Briscoe, slides-84-sdnrg-0.pdf

36
Network Programmability :: Layers & Scope
Source: CISCO, Network Programmability Specialist
https://learningnetwork.cisco.com/community/certifications/network-programmability

37
Network Programmability
– Industry Job Role Evolution and Certifications
https://learningnetwork.cisco.com/thread/62683
https://learningnetwork.cisco.com/community/certifications/network-programmability

38
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

39
Different SDN Models Control-plane component(s) Data-plane component(s)
Canonical/Open SDN
Traditional
Hybrid/Broker Overlay
Compiler
Source: C. Rothenberg (INTRIG/UNICAMP)

40
Legacy
Different 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 (SO/RO/LCM)
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
Source: C. Rothenberg (INTRIG/UNICAMP)

Software-Defined Knowledge Plane
Source: http://knowledgedefinednetworking.org

Autonomous (Zero-Touch) Networks :: ML/AI + SDN + BIG DATA
Source (Adapted) : Chris Rice (AT&T Labs), Whitebox and Autonomous Networks, Open Source Summit North America 2017
Advanced Telemetry (beyond SNMP!)

43
ZTN (Zero-Touch Network) [Google]
Source: 2017 Google Networking Research Summit Keynote Talks, https://www.youtube.com/watch?v=5N7QS5vP68o

44
Limits of
human understanding
Technological limits
Hand Crafted Code
Modeling + Code Gen
+ ML/AI (?)
Slide courtesy adapted from 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 (Manual):
* Lower apparent barrier to entry
* Domain Experts + programmers = ???
Speed, Capacity, Features
Complexity
(SW) Tools Driven (Automation)
* Higher initial complexity
* Machinists, not just Tailors + Apprentices
Goal: keep curve more flat
The critical role of SW to drive the network

45Source: Optical Network Virtualisation using Multi-technology
Monitoring and SDN-enabled Optical Transceiver,

46Source: Optical Network Virtualisation using Multi-technology
Monitoring and SDN-enabled Optical Transceiver,

Thanks! Obrigado! (More) Questions?
chesteve@dca.fee.unicamp.br
http://www.intrig.dca.fee.unicamp.br

• 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 8 PhD, 4 MSc candidates, and 2 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
• PhD in Electrical and Computer Engineering (FEEC/UNICAMP, 2010)
• Visiting Researcher at Ericsson, Jorvas & EU FP7 PSIRP (2S/2008)
• 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/

Research Interests & Results*
Software
Defined
Networking
Information
Centric
Networking
Network
Functions
Virtualization
• RouteFlow
(hybrid IP-SDN)
• softswitch13
• libfluid
(ONF Driver)
• Mininet-WiFi :: Wireless SDN
• SDN-2-SDN Peering
• MD2-NFV
(Multi-Domain Distributed)
• Mini-CCNx -> Mini-NDNx
• LIPSIN (in-packet Bloom filters)
• Semantic/Ontology-based SW methods
• 10G+ VNF / Multi-Core Architectures
• VNF-a-a-S / Benchmarking
• Gym: Automated Testing Framework
* https://scholar.google.com.br/citations?user=8PxuHPkAAAAJ

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 software 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/
50

Open Source minded Research
• Extensive use of open source tools in support of research activities.
• Etherpad, Owncloud, Docker, Gitlab, etc.
• Students use github (private->public) as the research dev repository
• Even if no paper accepted or in early stages
• Pro-active, open sharing of papers (in submission/accepted)
• Arxiv.org
• Make “full paper source code” available
• Overleaf, github, gnuplot
• 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?)
• Create community-oriented open source projects

52
Intellectual History of Programmable Networks
Source: N. Feamster, J. Rexford, E. Zegura. The Road to SDN: An Intellectual History of Programmable Networks.
SDN NFV

55
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

56
• Prop. IPC
• OpenFlow (with or w/extensions)
• Open Source south-bound protocols
• Via SDN controller broker and south-bound plug-ins
• Other standardized protocols
- 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.pd

57
• Levels of Abstraction
• Domain Specific Language
• Open APIs
• Standardized Protocols
- 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.pd

58
Towards one pragmatic definition
SDN functionally
• enables the network to be accessed by operators
programmatically;
• allowing for automated management and orchestration
techniques;
• application of configuration policy across multiple
routers, switches, and servers;
• decoupling of the application that performs these
operations from the network device’s operating system.

Broad/Generalized SDN definition
• Architectural approach that optimizes and simplifies network operations by
more closely binding the interaction (i.e., provisioning, messaging, and
alarming) among applications and network services and devices, whether they
be real or virtualized.
• Often is achieved by employing a point of logically centralized network control—
which is often realized as an SDN controller—which then orchestrates, mediates,
and facilitates communication btw applications wishing to interact with network
elements and
network elements wishing to convey information to those apps.
• The controller then exposes and abstracts network functions and operations via
modern, application-friendly and bidirectional programmatic interfaces.

What do we get from SDN?
• An architecture that
• brings the network and networking data closer to the application layer,
• And the applications closer to the networking layer.
• As practiced in SOA (service-oriented architectures) in IT :
• no longer need for a human element or scripting languages to act as humans to distribute data
and information bidirectionally
• APIs and tooling now have evolved in a way that this can be delivered in a secure and scalable
way via open interfaces and interoperability.
• Data in the network
(e.g., stats, state, subscriber info, service state, security, peering, etc.) can be
analyzed and used by an application to create policy intent and program the
network into a new configuration.
• It can be programmed this way persistently or only ephemerally.

Network Programmability
• One of the major parts of what SDN and OpenFlow proponents are trying to achieve is
greater and more flexible network device programmability.
• This does not necessarily have anything to do with the location (where) of the network
control and data planes;
• it is concerned with how they are programmed.
• One of the motivations for creating SDN and OpenFlow was the flexibility of how one
could program a network device, not just where it is programmed.
• E.g., ongoing work at IETF I2RS
(allow for real-time interaction with RIB and the RIB manager)
• Once you have the hardware its all about code
It is allabout APIs
http://www.sdncentral.com/comprehensive-list-of-sdn-apis/

62https://learningnetwork.cisco.com/thread/62683

63
AT&T Whitebox :: NOS Open Architecture

64
Whitebox :: Common Infrastructure Data

65

66

67
Declarative Network Configuration

68
Model-driven network management
Source: J. George, A. Shaikh (Google), Better management of large-scale, heterogeneous networks toward a programmable management plane, NANOG 64

69
OpenConfig tooling examples available

70
Challenges in thinking “model-driven”
• CLI habits are hard to break
• implementations are often very different
(occasionally for a good reason)
• models for machines or humans
• what to leave out of the model
• how to test for compliance by an implementation

71
Model-based automation in practice
• Operationalizing models -- many problems to be solved
• protocol-agnostic RPC specification for encoding, delivering, and receiving data
• handling mixed-schema operation (OpenConfig + native)
• model updates and versioning in the NMS and on devices
• Engaging with vendors
• this is all new for vendors -- close engineering engagements required
• must have their own internal model; decouple model iterations from major
releases
• investment in infrastructure to support externally defined models is critical
• Maturity of Tools
• being developed by users and vendors (e.g. RFC 6087,
https://github.com/openconfig/public)

72
Google ZTN (Zero-Touch Network)

73
Intent-based networking system
• Translation and Validation– The system takes a higher-level business policy
(what) as input from end users and converts it to the necessary network
configuration (how). The system then generates and validates the resulting
design and configuration for correctness.
• Automated Implementation – The system can configure the appropriate network
changes (how) across existing network infrastructure. This is typically done via
network automation and/or network orchestration.
• Awareness of Network State – The system ingests real-time network status for
systems under its administrative control, and is protocol- and transport-agnostic.
• Assurance and Dynamic Optimization/Remediation– The system continuously
validates (in real time) that the original business intent of the system is being
met, and can take corrective actions (such as blocking traffic, modifying network
capacity or notifying) when desired intent is not met.
Source: https://blogs.gartner.com/andrew-lerner/2017/02/07/intent-based-networking/

74
Intent-based networking system
Source:

75
NETWORK TELEMETRY AND AUTOMATION
Juniper Networks Junos Automation with Gurudatt Shenoy - YouTube
Juniper Networks Streaming Telemetry with Dmitry Shokarev – YouTube
http://www.openconfig.net/projects/telemetry/
https://xrdocs.github.io/telemetry/tutorials/2016-07-25-configuring-model-driven-telemetry-mdt-with-yang/
http://ix.br/pttforum/9/slides/ixbr9-telemetry.pdf

76
SDON :: : Packet-fixed-flexible Demonstration
Software-Defined Optical Networks Technology and Infrastructure: Enabling Software-Defined Optical Network Operations. M .Channegowda, R. Nejabati, and D. Simeonidou

Starting point: P4 Model & Targets

78
P4 Runtime Open-source project to remotely control P4 switches1
Remote Control Plane
Switch
OS
Switch
OS
Switch
OS
Switch
OS
Top of Rack
P4 Switches
P4
Runtime
P4
Runtime
OpenConfig
gRPC
P4
Runtime
P4
Runtime
OpenConfig
gRPC
P4
Runtime
P4
Runtime
OpenConfig
gRPC
P4
Runtime
P4
Runtime
OpenConfig
gRPC
P4 Runtime API is:
• Silicon Independent
• Program Independent
[1] “P4 Program-dependent Controller Interface for SDN Applications”, Samar Abdi et al (Google), P4 Workshop 2017

79
Universal Laws and Architectures

80
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

81
P^3 trade-offs in Network Softwarization
Realm of
the
Impossibl
e?
Plane of
the
Possible?
Performance
Performance
Portability Programmability

82
Programmability
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?

83
How to push the hard limits?

SDN :: Software Defined Networking –2017 Executive Overview

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a SDN :: Software Defined Networking –2017 Executive Overview

Similar a SDN :: Software Defined Networking –2017 Executive Overview (20)

Más de Christian Esteve Rothenberg

Más de Christian Esteve Rothenberg (20)

Último

Último (20)

SDN :: Software Defined Networking –2017 Executive Overview