Download SDN and cloud - Networking group

Software Defined Networking:
tecnologia e prospettive
Prof. Stefano Salsano
[email protected]
Seminario nel corso “Advanced Networking and
Internet Modeling„ Prof. Francesco Lo Presti
26 Maggio 2015
Outline
SDN motivations: Internet ossification, network
complexity, barriers to innovation
SDN approach, goals and dreams…
A bit of technology: OpenFlow
Application examples
SDN and cloud
Google’s SDN WAN
SDN and Network Function Virtualization
2
Internet success
• The Internet success is a remarkable story,
from a research infrastructure to a global
network, interconnecting billions of devices
and people
• Innovation looks easy on the Internet as we
witness always new and more powerful
services and applications
– Web, P2P, VoIP, social networks, video streaming…
3
Network ossification
• The history is a bit different behind the scene:
–Huge complexity
–Few people can innovate
–Closed equipment
–Network «ossification»
4
4
Classical network architecture
• Distributed control plane
• Distributed routing protocols: OSPF, IS-IS, BGP, etc.
Feature
Feature
Operating
System
Feature
Specialized Packet
Forwarding Hardware
Feature
Feature
Operating
System
Feature
Specialized Packet
Forwarding Hardware
Operating
System
Feature
Specialized Packet
Forwarding Hardware
Feature
Operating
System
Feature
Feature
Specialized Packet
Forwarding Hardware
Operating
System
Specialized Packet
Forwarding Hardware
5
The Networking Industry (2010s)
Routing, management, mobility management,
access control, VPNs, …
Feature
Feature
Operating
System
Specialized Packet
Forwarding Hardware
Million of lines
of source code
5400 RFCs
Barrier to entry
Billions of gates
Complex
Power Hungry
Closed, vertically integrated, boated, complex, proprietary
Many complex functions baked into the infrastructure
OSPF, BGP, multicast, differentiated services,
Traffic Engineering, NAT, firewalls, MPLS, redundant layers, …
Little ability for non-telco network operators to get what they want
Functionality defined by standards, put in hardware, deployed on nodes
6
Outline
SDN motivations: Internet ossification, network
complexity, barriers to innovation
SDN approach, goals and dreams…
A bit of technology: OpenFlow
Application examples
SDN and cloud
Google’s SDN WAN
SDN and Network Function Virtualization
7
Software Defined Network
Well-defined open API
Feature
Feature
Constructs a logical map
of the network
Northbound
Network OS
Open, vendor-agnostic protocol
Southbound
OpenFlow
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
17/09/2013
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
8
Analogy with IT industry:
from mainframes to PCs
Specialized
Applications
Specialized
Operating
System
Specialized
Hardware
Mainframe industry in the
1980s: Vertically integrated
Closed, proprietary
Slow innovation
Small industry
AppAppAppAppAppAppAppAppAppAppApp
Windows
(OS)
or
Linux
or
Mac
OS
Microprocessor
Horizontal
Open interfaces
Rapid innovation
Huge industry
9
Analogy with IT industry:
from closed box to SDN
Specialized
Features
Specialized
Control
Plane
Specialized
Hardware
Networking industry in
2010s: Vertically
integrated
Closed, proprietary
Slow innovation
AppAppAppAppAppAppAppAppAppAppApp
Control
Plane
or
Control
Plane
or
Control
Plane
Merchant
Switching Chips
Horizontal
Open interfaces
Rapid innovation
10
SDN Concept
• Separate Control plane and Data plane entities
– Network intelligence and state are logically centralized
– The underlying network infrastructure is abstracted from the
applications
• Execute or run Control plane software on general purpose
hardware
– Decouple from specific networking hardware
– Use commodity servers
• Have programmable data planes
– Maintain, control and program data plane state from a central
entity
• An architecture to control not just a networking device
but an entire network
11
Network OS and OpenFlow
• Network OS
– Distributed system that creates a consistent, up-to-date
network view, runs on servers (controllers) in the network
– Uses an open protocol to:
• Get state information from forwarding elements
• Give control directives to forwarding elements
• OpenFlow
– is a protocol for remotely controlling the forwarding table
of a switch or router
– is one element of SDN
12
Abstractions in the Control Plane
Network
Virtualization
Well-defined API
Routing
Traffic
Engineering
Other
Applications
Network Map
Abstraction
Network Operating System or “Controller”
Separation of Data
and Control Plane
Forwarding
Forwarding
Forwarding
Forwarding
13
Forwarding Abstractions
• Purpose: Abstract away forwarding hardware
• Flexible
– Behavior specified by control plane
– Built from basic set of forwarding primitives
• Minimal
– Streamlined for speed and low-power
– Control program not vendor-specific
OpenFlow is an example of such an abstraction
14
SDN promises (or dreams…)
• Innovation
– beyond IP, clean slate approaches…
• Change of paradigm
«Redefining Abstractions» (see Scott Shenker
presentation)
• Openness
– open fast switching hardware, open controllers
15
Outline
SDN motivations: Internet ossification, network
complexity, barriers to innovation
SDN approach, goals and dreams…
A bit of technology: OpenFlow
Application examples
SDN and cloud
Google’s SDN WAN
SDN and Network Function Virtualization
16
Traditional network node: Switch
• Typical Networking Software
– Management plane
– Control Plane – The brain/decision maker
– Data Plane – Packet forwarder
17
Traditional network node: Router
• Router can be partitioned into control and data plane
– Management plane/ configuration
– Control plane / Decision: OSPF (Open Shortest Path First)
– Data plane / Forwarding
Adjacent Router
Routing
Control plane
OSPF
Switching
Data plane
Router
Management/Policy plane
Configuration / CLI / GUI
Static routes
Control plane
OSPF
Neighbor
table
Data plane
Link state
database
Adjacent Router
Control plane
OSPF
IP routing
table
Forwarding table
Data plane
18
OpenFlow Basics
OpenFlow Controller
OpenFlow Protocol (SSL/TCP)
Control Path
OpenFlow
Data Path (Hardware)
19
OpenFlow Basics
Control Program A
Control Program B
Network OS
OpenFlow Protocol
Ethernet
Switch
Control
Path
OpenFlow
Data Path (Hardware)
20
OpenFlow Basics
Control Program A
Control Program B
Network OS
“If header = p, send to port 4”
Packet
Forwarding
Packet
Forwarding
“If header = q, overwrite header with r,
add header s, and send to ports 5,6”
“If header = ?, send to me”
Flow
Table(s)
Packet
Forwarding
21
OpenFlow Primitives
<Match, Action>
• Match arbitrary bits in headers:
Header
Data
Match: 1000x01xx0101001x
– Match on any header, or new header
– Allows any flow granularity
• Action
– Forward to port(s), drop, send to controller
– Overwrite header with mask, push or pop
– Forward at specific bit-rate
22
General Forwarding Abstraction
Small set of primitives
“Forwarding instruction set”
Protocol independent
Backward compatible
Switches, routers, WiFi APs,
basestations, TDM/WDM
23
OpenFlow example
Software
Layer
PC
OpenFlow Client
Controller
Flow Table
Hardware
Layer
MAC
src
MAC
dst
IP
Src
IP
Dst
TCP
TCP
Action
sport dport
*
*
*
5.6.7.8
*
port 1
5.6.7.8
port 2
port 3
*
port 1
port 4
1.2.3.4
24
OpenFlow Basics
Flow Table Entries
Rule
Action
Stats
Packet + byte counters
1.
2.
3.
4.
5.
Switch VLAN
Port
ID
Forward packet to zero or more ports
Encapsulate and forward to controller
Send to normal processing pipeline
Modify Fields
Any extensions you add!
VLAN MAC
pcp src
MAC
dst
Eth
type
IP
Src
IP
Dst
IP
L4
IP
ToS Prot sport
L4
dport
+ mask what fields to match
25
Examples
Switching
Switch MAC
Port src
*
MAC Eth
dst
type
00:1f:.. *
*
VLAN IP
ID
Src
IP
Dst
IP
Prot
TCP
TCP
Action
sport dport
*
*
*
*
IP
Dst
IP
Prot
TCP
TCP
Action
sport dport
*
*
port6
Flow Switching
Switch MAC
Port src
MAC Eth
dst
type
port3 00:20.. 00:1f.. 0800
VLAN IP
ID
Src
vlan1 1.2.3.4 5.6.7.8
4
17264 80
port6
Firewall
Switch MAC
Port src
*
*
MAC Eth
dst
type
*
*
VLAN IP
ID
Src
IP
Dst
IP
Prot
TCP
TCP
Action
sport dport
*
*
*
*
*
22
drop
26
Reactive vs. Proactive (pre-populated)
Reactive
Proactive
• First packet of flow triggers
•
controller to insert flow
entries
• Efficient use of flow table
• Every flow incurs small
additional flow setup time
• If control connection lost,
switch has limited utility
• Extremely simple fault
recovery
•
•
•
Controller pre-populates
flow table in switch
Zero additional flow setup
time
Loss of control connection
does not disrupt traffic
Essentially requires
aggregated (wildcard) rules
27
Microflow vs. Aggregated
Aggregated
Microflow
• Every flow is individually
•
set up by controller
• Exact-match flow entries
• Flow table contains one
entry per flow
•
•
• Good for fine grain control,
•
policy, and monitoring, e.g.
campus
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
28
Virtualization trend
App
App
App
Windows
Windows
Windows
(OS)
(OS)
(OS)
Linux
Linux
Linux
App
App
App
Mac
Mac
Mac
OS
OS
OS
Virtualization layer
x86
(Computer)
Computer Industry
Controller11
NOX
Controller
(Network OS)
Controller
Controller
Network
OS
22
Virtualization or “Slicing”
OpenFlow
Network Industry
29
Isolated “slices”
App
App
Network
Operating
System 1
Many operating systems, or
Many versions
App
App
Network
Operating
System 2
App
App
App
Network
Operating
System 3
App
Network
Operating
System 4
Open interface to hardware
Virtualization or “Slicing” Layer
Open interface to hardware
Simple Packet
Forwarding Hardware
Simple Packet
Forwarding Hardware
Simple Packet
Forwarding Hardware
Simple Packet
Forwarding Hardware
Simple Packet
Forwarding Hardware
17/09/2013
30
Outline
SDN motivations: Internet ossification, network
complexity, barriers to innovation
SDN approach, goals and dreams…
A bit of technology: OpenFlow
Application examples
SDN and cloud
Google’s SDN WAN
SDN and Network Function Virtualization
31
SDN and cloud
Cloud
x 10000…
“multi-tenant”
multi site
32
SDN and cloud
• Cloud computing service providers face the issue of
multi-tenancy at the network level
• IP and Ethernet each have virtual network capability,
but limited in terms of
– how many tenants can be supported
– how isolated each tenant
– configuration and management complexity
• SDN is increasingly accepted as the path to "cloud
networking"
33
Neutron service in the OpenStack
cloud architecture (was Quantum)
Nova, Swift, and Neutrum API
Nova
Compute
Service
Neutrum
Service
Swift
Storage
Service
Virtual
Machines
Virtual
Networks
Object Store
Servers
Networks
Disks
Basic Network Connectivity
Developers have ability to create multiple networks for their
own purposes (multi-tier apps)
May support provisioning of both virtual and physical
networks – differences captured through plugin’s
34
Neutrum service in the
OpenStack cloud architecture
User Application – CLI - Horizon Dashboard - Tools
Tenant API
Tenant API
Compute
Service
(Nova)
Internal API
Network
Service
(Neutrum)
Admin API
System
Admin
Plug-In
Compute Node
Hypervisor
vSwitch
Physical
Network
Router/Switch
Clustered
Network
Controller
35
Available Neutrum plug-ins
•
•
•
•
Open vSwitch
Linux bridge
Nicira NVP
Cisco (Nexus switches and UCS VM-FEX)
– WIP: VXLAN
• NTT Labs Ryu OpenFlow controller
• NEC OpenFlow
• Big Switch Floodlight
Most of them are SDN based !
36
The zoo of network technologies
37
Data center simplification
Traditional Network
Fabric
38
Network Fabric Defined
• Flat network
• Every port virtually connected to every other
• High speed network; 10 Gig-E, roadmap to 40 Gig-E and
100 Gig-E
• Operationally simple
• Optimized for virtual traffic and east west traffic flows
• Optimized packet processing
39
The shift toward SDNs
•
•
•
•
•
•
•
Allows for the network to be in better alignment with the
current data center trends
Brings a high level of agility to the network
Enables programmability
Improves application
performance
Abstracts the control layer
from the network
infrastructure lay
Complements fabrics
Creates scalable network
virtualization
40
40
Outline
SDN motivations: Internet ossification, network
complexity, barriers to innovation
SDN approach, goals and dreams…
A bit of technology: OpenFlow
Application examples
SDN and cloud
Google’s SDN WAN
SDN and Network Function Virtualization
41
Google’s B4: an SDN success story
• In April 2012 Google presented their OpenFlow
based WAN (“B4”), globally interconnecting
the Data Centers
• B4 is based on a SDN architecture using
OpenFlow to control relatively simple switches
built from merchant silicon
• Google engineered the switches and the SDN
architecture
42
B4 worldwide deployment (2011)
43
Typical WAN engineering rules
• WAN links are typically provisioned to 30-40%
average utilization. This can mask virtually all
link or router failures from clients.
• Such overprovisioning give reliability at the
costs of 2-3x bandwidth over-provisioning and
high-end routing gear.
44
Google’s Requirements
• Google fully controls applications and server
using the WAN
• The most bandwidth intensive applications are
large-scale data copies: they can adapt to
available capacity
• The number of data center is limited, making
centralized bandwidth control feasible
45
Traffic Engineering
• Using SDN, B4 simultaneously supports
standard routing protocols and centralized TE
• TE algorithms allow to:
– adjudicate among competing demands during
resource constraint
– use multipath forwarding/tunneling
– dynamically reallocate bandwidth in the face of
link/switch failures
• Many B4 links to run at near 100% utilization
and all links to average 70% utilization
46
The SDN switches
47
SDN based WAN architecture
48
Performance measurements
link
utilization
ratio
high prio /
low prio
low prio loss
high prio loss
49
…and if you are not Google ?
A truly open SDN eco-system will grow,
including controllers/network OS,
management tools, switching equipment, and
“network applications” (e.g. a TE component)
?
Vendors will include SDN concepts in their
solutions, mostly in a proprietary way
50
«SDN washing»
• All main networking equipment vendors are
now offering their SDN products and solutions
• “SDN washing” – when networking vendors
essentially take their existing technologies and
try to re-label them as SDN products
51
OpenDayLight
• Cisco, Juniper, Ericsson, IBM, NEC and other
network vendors are joining up to standardize
SDN (April 2013) with OpenDayLight project
52
OpenDayLight
53
Outline
SDN motivations: Internet ossification, network
complexity, barriers to innovation
SDN approach, goals and dreams…
A bit of technology: OpenFlow
Application examples
SDN and cloud
Google’s SDN WAN
SDN and Network Function Virtualization
54
SDN and NFV
(Network Function Virtualization)
• NVF: a Network-operator-driven specification
group within ETSI.
• Initiated by 13 carriers now grown to 23 members
http://portal.etsi.org/portal/server.pt/community/NFV/367
55
SDN and NFV
(Network Function Virtualization)
Network Functions Virtualisation
Approach
Message
Router
CDN
Session Border
WAN
Controller
Acceleration
Carrier
Grade NAT
DPI
Tester/QoE
monitor
Firewall
SGSN/GGSN
BRAS
PE Router
Radio Network
Controller
Independent
Software Vendors
Orchestrated,
automatic
remote install
hypervisors
Generic High Volume Servers
Generic High Volume Storage
Classical Network Appliance
Approach
Generic High Volume
Ethernet Switches
56
NFV and SDN are complementary
Creates operational flexibility
Reduces
CapEx, OpEx,
delivery time
Network
Functions
Virtualisation
Open
Innovation
Creates
competitive
supply of innovative
applications by third parties
Reduces
space & power
consumption
Software
Defined
Networks
Creates
control
abstractions
to foster innovation.
57
Outline
SDN motivations: Internet ossification, network
complexity, barriers to innovation
SDN approach, goals and dreams…
A bit of technology: OpenFlow
Application examples
SDN and cloud
Google’s SDN WAN
SDN and Network Function Virtualization
Final remarks
17/09/2013
58
The two paths to SDN (r)evolution
•
•
•
•
New Abstractions / high level modeling of networks
Disruptive low cost net architectures and open hardware
Open Source Software (for Carriers’ Class nodes)
Open Innovation
Revolutionary path : disruptive innovation
Evolutionary path : progressive innovation
• Seamless integration in current networks, compatibility with legacy
• Solutions from traditional Vendors (or even Start-ups) …
• Costs Reductions (CAPEX, OPEX)
59
Thank you for your attention !
Questions ?
UNIVERSITY OF ROME “TOR VERGATA”
Department of Electronics Engineering
Via del Politecnico, 1 - 00133 Rome - Italy
Stefano Salsano, Ph. D.
Associate Professor
Phone: +39 06 7259 7770
Fax: +39 06 7259 7435
e-mail: [email protected]
http://netgroup.uniroma2.it/Stefano_Salsano/
Suggested Readings
– A. Manzalini, V. Vercellone, M. Ullio, «Software Defined
Networking: sfide ed opportunità per le reti del futuro»,
Notiziario Tecnico Telecom Italia, n.1/2003
http://www.telecomitalia.com/content/dam/telecomitalia/it/ar
chivio/documenti/Innovazione/NotiziarioTecnico/2013/n12013/NT1-4-2013.pdf
– N. McKeown et al. «OpenFlow: Enabling Innovation in Campus
Networks», CCR 2008
http://www.openflow.org/documents/openflow-wp-latest.pdf
61
Main sources
– Jennifer Rexford “Enabling Innovation Inside the Network”
– Scott Shenker with Martín Casado, Teemu Koponen, Nick
McKeown and others “The Future of Networking, and the Past
of Protocols”
– Rob Sherwood (with help from many others) “An Experimenter’s
Guide to OpenFlow” - GENI Engineering Workshop June 2010
– Brandon Heller, Rob Sherwood, David Erickson, Hideyuki
Shimonishi, Srini Seetharaman, Murphy McCauley, “Tutorial 1:
SDN for Engineers”
– Dan Pitt, “The Open Networking Foundation: OpenFlow & SDN
from lab to market”
– Yeh-Ching Chung, “Network Virtualization - Software Defined
Network”
62
Main sources
– Tom Nolle “The role of software-defined networks in cloud
computing”
– Lew Tucker, “Quantum: What it is and Where it’s going”
– Zeus Kerravala, “The Time for ICT is Now”
– Tom Nollle “Understanding the relationship between SDN and
NFV”
– Bob Briscoe (+ Don Clarke, Pete Willis, Andy Reid, Paul Veitch),
“Network Functions Virtualisation”
– Antonio Manzalini, “Software Will Eat the Networks – Welcome
to the Blue SDN”
63
My work on SDN
– OSHI Open Source Hybrid IP/SDN networking http://netgroup.uniroma2.it/OSHI/
– The DREAMER project http://netgroup.uniroma2.it/DREAMER/
– S. Salsano, P. L. Ventre, F. Lombardo, G. Siracusano, M. Gerola, E. Salvadori, M. Santuari,
M. Campanella, L. Prete “OSHI - Open Source Hybrid IP/SDN networking and Mantoo - a set of
management tools for controlling SDN/NFV experiments”, submitted paper (May 2015)
– S. Salsano, P. L. Ventre, L. Prete, G. Siracusano, M. Gerola, E. Salvadori,
“Open Source Hybrid IP/SDN networking (and its emulation on Mininet and on distributed SDN
testbeds)”, 3rd European Workshop on Software Defined Networks, EWSDN 2014, 1-3 September 2014,
Budapest, Hungary
– M. Gerola, M. Santuari, E. Salvadori, S. Salsano, P. L. Ventre, M. Campanella, F. Lombardo, G. Siracusano,
“ICONA: Inter Cluster ONOS Network Application”, demo paper, 1st IEEE Conference on Network
Softwarization (Netsoft 2015), London, UK, 13-17 April 2015
– N. Blefari-Melazzi, A. Detti, G. Morabito, S. Salsano, L. Veltri, “Information Centric Networking over SDN
and OpenFlow: Architectural Aspects and Experiments on the OFELIA Testbed”, to appear in Elsevier
Computer Networks, Special Issue on Information-Centric Networking (ICN), 2013
– N. Blefari-Melazzi, A. Detti, G. Mazza, G. Morabito, S. Salsano, L. Veltri, “An OpenFlow-based Testbed for
Information Centric Networking”, Future Network & Mobile Summit 2012, 4-6 July 2012, Berlin,
Germany
– L. Veltri, G. Morabito, S. Salsano, N. Blefari-Melazzi, A. Detti, “Supporting Information-Centric
Functionality in Software Defined Networks”, SDN’12: Workshop on Software Defined Networks, Colocated with the IEEE International Conference on Communications (ICC), June 10-15 2012, Ottawa,
Canada
– A. Detti , C. Pisa, S. Salsano, N. Blefari-Melazzi, “Wireless Mesh Software Defined Networks (wmSDN)”,
The 2nd International Workshop on Community Networks and Bottom-up-Broadband (CNBuB 2013),
Lyon, France, October 7th, 2013
17/09/2013
64