Upload
frank-mason
View
218
Download
0
Tags:
Embed Size (px)
Citation preview
Software Defined Networking:tecnologia e prospettive
Prof. Stefano [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 innovationSDN approach, goals and dreams…A bit of technology: OpenFlowApplication examples
SDN and cloudGoogle’s SDN WANSDN and Network Function Virtualization
2
3
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…
Network ossification
4
• The history is a bit different behind the scene:
–Huge complexity –Few people can innovate–Closed equipment–Network «ossification»
4
Specialized Packet Forwarding Hardware
Feature Feature
Specialized Packet Forwarding Hardware
Specialized Packet Forwarding Hardware
Specialized Packet Forwarding Hardware
Specialized Packet Forwarding Hardware
OperatingSystem
OperatingSystem
OperatingSystem
OperatingSystem
OperatingSystem
Feature Feature
Feature Feature
Feature Feature
Feature Feature
Classical network architecture
• Distributed control plane• Distributed routing protocols: OSPF, IS-IS, BGP, etc.
5
Million of linesof source code
5400 RFCs Barrier to entry
Billions of gates Complex Power Hungry
Closed, vertically integrated, boated, complex, proprietaryMany 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 wantFunctionality defined by standards, put in hardware, deployed on nodes
The Networking Industry (2010s)
Specialized Packet Forwarding Hardware
OperatingSystem
Feature Feature
Routing, management, mobility management, access control, VPNs, …
6
Outline
SDN motivations: Internet ossification, network complexity, barriers to innovationSDN approach, goals and dreams…A bit of technology: OpenFlowApplication examples
SDN and cloudGoogle’s SDN WANSDN and Network Function Virtualization
7
Feature Feature
Network OS
Well-defined open API Constructs a logical mapof the network
Software Defined Network
OpenFlow
Simple PacketForwarding Hardware
Simple PacketForwarding Hardware
Simple PacketForwarding Hardware
Simple PacketForwarding Hardware
Simple PacketForwarding Hardware
Open, vendor-agnostic protocol Southbound
Northbound
17/09/2013 8
Microprocessor
Mainframe industry in the 1980s: Vertically integrated
Closed, proprietarySlow innovationSmall industry
SpecializedOperating
System
SpecializedHardware
AppAppAppAppAppAppAppAppAppAppAppSpecialized
Applications
HorizontalOpen interfacesRapid innovation
Huge industry
Linux MacOS
Windows(OS) or or
Analogy with IT industry:from mainframes to PCs
9
Networking industry in 2010s: Vertically
integratedClosed, proprietary
Slow innovation
AppAppAppAppAppAppAppAppAppAppApp
HorizontalOpen interfacesRapid innovation
ControlPlane
ControlPlane or or
SpecializedControlPlane
SpecializedHardware
SpecializedFeatures
MerchantSwitching Chips
Analogy with IT industry:from closed box to SDN
10
ControlPlane
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
Routing Traffic Engineering
Other Applications
Well-defined API
Network Map Abstraction
Forwarding
Forwarding
Forwarding
Forwarding
Separation of Data and Control Plane
Network Virtualization
Network Operating System or “Controller”
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 innovationSDN approach, goals and dreams…A bit of technology: OpenFlowApplication examples
SDN and cloudGoogle’s SDN WANSDN 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 RouterManagement/Policy plane
Configuration / CLI / GUI
Static routesControl planeOSPF
Neighbor table
Link state database
IP routing table
Forwarding tableData planeData plane
Control planeOSPF
Adjacent Router
Data plane
Control planeOSPF
Routing
Switching
18
Data Path (Hardware)
Control Path OpenFlow
OpenFlow Controller
OpenFlow Protocol (SSL/TCP)
19
OpenFlow Basics
OpenFlow Protocol
Data Path (Hardware)
Control Path OpenFlowEthernet Switch
Network OS
Control Program A Control Program B
OpenFlow Basics
20
Control Program A Control Program B
Network OS
OpenFlow Basics
PacketForwarding
PacketForwarding
PacketForwarding
FlowTable(s)
FlowTable(s)
“If header = p, send to port 4”
“If header = ?, send to me”
“If header = q, overwrite header with r, add header s, and send to ports 5,6”
21
OpenFlow Primitives
• Match arbitrary bits in headers:
– 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
•
HeaderHeader DataData
Match: 1000x01xx0101001x
<Match, Action>
22
General Forwarding Abstraction
Small set of primitives“Forwarding instruction set”
Small set of primitives“Forwarding instruction set”
Protocol independentBackward compatibleProtocol independentBackward compatible
Switches, routers, WiFi APs, basestations, TDM/WDM
Switches, routers, WiFi APs, basestations, TDM/WDM
23
24
Controller
PC
HardwareLayer
SoftwareLayer
Flow Table
MACsrc
MACdst
IPSrc
IPDst
TCPsport
TCPdport Action
OpenFlow Client
**5.6.7.8*** port 1
port 4port 3port 2port 1
1.2.3.45.6.7.8
OpenFlow example
OpenFlow Basics Flow Table Entries
SwitchPort
MACsrc
MACdst
Ethtype
VLANID
IPSrc
IPDst
IPProt
L4sport
L4dport
Rule Action Stats
1. Forward packet to zero or more ports2. Encapsulate and forward to controller3. Send to normal processing pipeline4. Modify Fields5. Any extensions you add!
+ mask what fields to match
Packet + byte counters
25
VLANpcp
IPToS
Examples
Switching
*
SwitchPort
MACsrc
MACdst
Ethtype
VLANID
IPSrc
IPDst
IPProt
TCPsport
TCPdport Action
* 00:1f:.. * * * * * * * port6
Flow Switching
port3
SwitchPort
MACsrc
MACdst
Ethtype
VLANID
IPSrc
IPDst
IPProt
TCPsport
TCPdport Action
00:20.. 00:1f.. 0800 vlan1 1.2.3.4 5.6.7.8 4 17264 80 port6
Firewall
*
SwitchPort
MACsrc
MACdst
Ethtype
VLANID
IPSrc
IPDst
IPProt
TCPsport
TCPdport Action
* * * * * * * * 22 drop
26
Reactive vs. Proactive (pre-populated)
Reactive
• 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
Proactive
• 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
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
Aggregated
• 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
Windows(OS)
Windows(OS)
Linux MacOS
x86(Computer)
Windows(OS)
AppApp
LinuxLinuxMacOS
MacOS
Virtualization layer
App
Controller 1
AppApp
Controller2
Virtualization or “Slicing”
App
OpenFlow
Controller 1NOX(Network OS)
Controller2Network OS
Virtualization trend
Computer Industry Network Industry
29
Simple Packet Forwarding Hardware
Network Operating System 1
Open interface to hardware
Virtualization or “Slicing” Layer
Network Operating System 2
Network Operating System 3
Network Operating System 4
App App App App App App App App
Many operating systems, orMany versions
Open interface to hardware
Isolated “slices”
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 innovationSDN approach, goals and dreams…A bit of technology: OpenFlowApplication examples
SDN and cloudGoogle’s SDN WANSDN and Network Function Virtualization
31
SDN and cloud
32
x 10000…“multi-tenant”multi site
Cloud
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)
34
Nova ComputeService
Virtual Machines
SwiftStorageService
Object Store
Basic Network Connectivity
Nova, Swift, and Neutrum API
Servers Disks
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
NeutrumService
Virtual Networks
Networks
Neutrum service in the OpenStack cloud architecture
35
Compute Service(Nova)
Network Service
(Neutrum)
Tenant API
Internal API Admin API SystemAdmin
Plug-In
User Application – CLI - Horizon Dashboard - Tools
Tenant API
Compute NodeHypervisor
vSwitch
PhysicalNetwork
Router/Switch
Clustered Network
Controller
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
36
Most of them are SDN based !
The zoo of network technologies
37
Data center simplification
38
Traditional Network
Fabric
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
40
• Enables programmability • Improves application
performance • Abstracts the control layer
from the network infrastructure lay
• Complements fabrics • Creates scalable network
virtualization
40
Outline
SDN motivations: Internet ossification, network complexity, barriers to innovationSDN approach, goals and dreams…A bit of technology: OpenFlowApplication examples
SDN and cloudGoogle’s SDN WANSDN 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
49
link utilization
low prio loss
high prio loss
ratiohigh prio /low prio
…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 innovationSDN approach, goals and dreams…A bit of technology: OpenFlowApplication examples
SDN and cloudGoogle’s SDN WANSDN 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
IndependentSoftware Vendors
BRAS
Firewall
DPI
CDN
Tester/QoEmonitor
WANAcceleration
MessageRouter
Radio NetworkController
CarrierGrade NAT
Session BorderController
Classical Network ApplianceApproach
PE Router
SGSN/GGSN
Generic High VolumeEthernet Switches
Generic High Volume Servers
Generic High Volume Storage
Orchestrated,automatic remote install
Network Functions VirtualisationApproach
hypervisors
SDN and NFV(Network Function Virtualization)
56
NFV and SDN are complementary
57
Open Innovation
NetworkFunctions
Virtualisation
Software Defined
Networks
Creates operational flexibilityReduces ReducesCapEx, OpEx, space & power delivery time consumption
Createscontrol
abstractions to foster innovation.
Createscompetitivesupply of innovative applications by third parties
Outline
SDN motivations: Internet ossification, network complexity, barriers to innovationSDN approach, goals and dreams…A bit of technology: OpenFlowApplication examples
SDN and cloudGoogle’s SDN WANSDN and Network Function Virtualization
Final remarks17/09/2013 58
The two paths to SDN (r)evolution
59
• New Abstractions / high level modeling of networks• Disruptive low cost net architectures and open hardware• Open Source Software (for Carriers’ Class nodes) • Open Innovation
Evolutionary path : progressive innovation
Revolutionary path : disruptive innovation
• Seamless integration in current networks, compatibility with legacy • Solutions from traditional Vendors (or even Start-ups) … • Costs Reductions (CAPEX, OPEX)
Thank you for your attention !
Stefano Salsano, Ph. D.Associate Professor
e-mail: [email protected]://netgroup.uniroma2.it/Stefano_Salsano/
Phone: +39 06 7259 7770Fax: +39 06 7259 7435
UNIVERSITY OF ROME “TOR VERGATA”Department of Electronics Engineering
Via del Politecnico, 1 - 00133 Rome - Italy
Questions ?
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/2003http://www.telecomitalia.com/content/dam/telecomitalia/it/archivio/documenti/Innovazione/NotiziarioTecnico/2013/n1-2013/NT1-4-2013.pdf
– N. McKeown et al. «OpenFlow: Enabling Innovation in Campus Networks», CCR 2008http://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, Co-located 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