Outline - telematica.polito.it · Pag. 2 Software Defined Networking Andrea Bianco –TNG group -...
Transcript of Outline - telematica.polito.it · Pag. 2 Software Defined Networking Andrea Bianco –TNG group -...
Pag. 1
Software Defined Networking
Software Defined Networking - 1Andrea Bianco – TNG group - Politecnico di Torino
Software Defined Networking
(SDN)
Andrea Bianco
http://www.telematica.polito.it/
Software Defined Networking - 2Andrea Bianco – TNG group - Politecnico di Torino
Outline
• SDN
– Motivations, definitions, architecture,
– Flow based forwarding
• Openflow protocol
• Some issues
• Advances
– Distributed controllers
– Stateful switches
Pag. 2
Software Defined Networking
Software Defined Networking - 3Andrea Bianco – TNG group - Politecnico di Torino
Traditional computer networks
• Data plane
– Local algorithms, dealing with packets
• Forwarding, filtering, scheduling, buffering, marking, rate-limiting,
measuring at the packet level
– Packet transmission time scale
• Very fast processing
• Implemented in HW
Rexford – Computer Network class
Software Defined Networking - 4Andrea Bianco – TNG group - Politecnico di Torino
Traditional computer networks
• Control plane
– Distributed algorithms
• Topology discovery, topology tracking, route computation,
installing forwarding rules, traffic engineering
– Seconds time scale, flow time scale
• Slow process
Rexford – Computer Network class
Pag. 3
Software Defined Networking
Software Defined Networking - 5Andrea Bianco – TNG group - Politecnico di Torino
Traditional computer networks
• Management plane
– Local/global algorithms with coordination
• Measurement, configuration, monitoring, protection and
restoration
– Mostly «human» time scale
Rexford – Computer Network class
Software Defined Networking - 6Andrea Bianco – TNG group - Politecnico di Torino
Traditional computer networks
• Features
– Incredible success (from research experiments to global
commercial infrastructure)
– «In principle» complexity at the edge
• «Only» packet forwarding inside
• Complexity at the edge (SW) enables fast innovation
• Host running increasingly complex applications (SW)
– Web, P2P, social networks, virtual reality, video streaming
– Inside the network?
• Closed equipments, SW and HW intermixed, vendor specific
interfaces, many more features beside forwarding, too many
protocols
• Slow and costly development and management
Pag. 4
Software Defined Networking
Software Defined Networking - 7Andrea Bianco – TNG group - Politecnico di Torino
Forwarding HW
OS
Classic network paradigm
Distributed network functions
Forwarding HW
OS
Forwarding HW
OS
State distribution mechanism
(protocols) ensure interoperability
Router/switch/appliance
Capone – Netsoft 2015
Software Defined Networking - 8Andrea Bianco – TNG group - Politecnico di Torino
Closed platform
• Configuration interfaces vary
– Different vendors
– Different devices of the same vendors
– Different firmware versions of the same device
Forwarding HW
OS
AppApp App
L3 Routing, L2 switching, ACL, VPNs, etc…
Control plane
Mngmt plane
Data plane
Protocols guarantee interoperability…
Capone – Netsoft 2015
Pag. 5
Software Defined Networking
Software Defined Networking - 9Andrea Bianco – TNG group - Politecnico di Torino
Too many protocols/standards?
Capone – Netsoft 2015
Software Defined Networking - 10Andrea Bianco – TNG group - Politecnico di Torino
Vendors dominated
Capone – Netsoft 2015
Pag. 6
Software Defined Networking
Software Defined Networking - 11Andrea Bianco – TNG group - Politecnico di Torino
Software Defined Networkig
• “New” key elements
– Clean interface (API) between data and control plane
– Logically centralized control plane
• Control plane out of forwarding devices
• Control plane (SW) may run on general purpose HW
• Global network view
• SDN controller or Network Operating Systems
– Network programmability
– New architecture
– Flow based switching
• Programmed by the centralized controller
• Very flexible flow definition
– Network applications running on top of NOS
Software Defined Networking - 12Andrea Bianco – TNG group - Politecnico di Torino
The new (centralized) model
Data-plane
Control-plane
Data-plane
Control-plane
Data-plane
Control-plane
Switch
Data-plane
Data-plane
Data-plane
Control-
plane
Programmable
switch
Traditional networking
Distributed
Software-Defined Networking
Centralized
Capone – Netsoft 2015
Pag. 7
Software Defined Networking
Software Defined Networking - 13Andrea Bianco – TNG group - Politecnico di Torino
Centralized control
API to the data plane
(e.g., OpenFlow protocol)
Logically-centralized control
Switches
smart
slow
very dumb
fast
Controller
Rexford – Computer Network class
Software Defined Networking - 14Andrea Bianco – TNG group - Politecnico di Torino
SND architecture: interfaces
Simple
forwarding HW
Simple
forwarding HW
Simple
forwarding HW
Simple
forwarding HW
Network OS
App App App
Southbound interface: HW open interface
Northbound interface: Network control API
Capone – Netsoft 2015
Pag. 8
Software Defined Networking
Software Defined Networking - 15Andrea Bianco – TNG group - Politecnico di Torino
A Helpful Analogy
From Nick McKeown’s talk
“Making SDN Work” at the
Open Networking Summit, April 2012
Software Defined Networking - 16Andrea Bianco – TNG group - Politecnico di Torino
Vertically integrated
Closed, proprietary
Slow innovation
Small industry
Specialized
Operating
System
Specialized
Hardware
AppAppAppAppAppAppAppAppAppAppApp
Specialized
Applications
Horizontal
Open interfaces
Rapid innovation
Huge industry
Microprocessor/HW
Open Interface
LinuxMac
OS
Windows
(OS)or or
Open Interface
Mainframes
N. Mc Keown – ONS 2012
Pag. 9
Software Defined Networking
Software Defined Networking - 17Andrea Bianco – TNG group - Politecnico di Torino
Vertically integrated
Closed, proprietary
Slow innovation
AppAppAppAppAppAppAppAppAppAppApp
Horizontal
Open interfaces
Rapid innovation
Control
Plane
Control
Plane
Control
Planeor or
Open Interface
Specialized
Control
Plane
Specialized
Hardware
Specialized
Features
Merchant
Switching Chips
Open Interface
Routers/Switches
N. Mc Keown– ONS 2012
Software Defined Networking - 18Andrea Bianco – TNG group - Politecnico di Torino
Flow-based forwarding
• Protocol-less or protocol-oblivious forwarding
– Not exactly true (set of predefined fields)
• Simple packet-handling rules
– Pattern/rule: match packet header bits
– Actions: drop, forward, modify, send to controller
– Priority: disambiguate overlapping patterns
Pag. 10
Software Defined Networking
Software Defined Networking - 19Andrea Bianco – TNG group - Politecnico di Torino
Flow based forwarding:
table entries
SwitchPort
Ethtype
VLANId
VLAN Ethpcp
MACsrc
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
MACdest
IPToS
OpenFlow/SDN tutorial, Srini Seetharaman
Software Defined Networking - 20Andrea Bianco – TNG group - Politecnico di Torino
Unifies different kinds of “boxes”
• Router
– Match: longest
destination IP prefix
– Action: forward out a
link
• Switch
– Match: destination MAC
address
– Action: forward or flood
• Firewall
– Match: IP addresses
and TCP/UDP port
numbers
– Action: permit or deny
• NAT
– Match: IP address and
TCP/UDP port
– Action: rewrite address
and port
Rexford – Computer Network class
Pag. 11
Software Defined Networking
Software Defined Networking - 21Andrea Bianco – TNG group - Politecnico di Torino
Examples of “boxes”
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 port4
Firewall
*
SwitchPort
MACsrc
MACdst
Ethtype
VLANID
IPSrc
IPDst
IPProt
TCPsport
TCPdport
Action
* * * * * * * * 22 drop
OpenFlow/SDN tutorial, Srini Seetharaman
Software Defined Networking - 22Andrea Bianco – TNG group - Politecnico di Torino
Examples of “boxes”
Routing
*
SwitchPort
MACsrc
MACdst
Ethtype
VLANID
IPSrc
IPDst
IPProt
TCPsport
TCPdport
Action
* * * * * 5.6.7.8 * * * port3
VLAN Switching
*
SwitchPort
MACsrc
MACdst
Ethtype
VLANID
IPSrc
IPDst
IPProt
TCPsport
TCPdport
Action
* * vlan1 * * * * *
port6 port7port9
00:1f..
OpenFlow/SDN tutorial, Srini Seetharaman
Pag. 12
Software Defined Networking
Software Defined Networking - 23Andrea Bianco – TNG group - Politecnico di Torino
… L3_SRC L3_DST L4_SRC L4_DST … Action
Controller to switch interaction
Forwarding
Element
… L3_SRC L3_DST L4_SRC L4_DST … Action
Any 112/8 Any Any Fwd-to: 2
IP_SCR: 10.2.54.1
IP_DST: 112.45.54.176
TCP_SRC: 5433
TCP_DST: 80
IP_SCR: 10.2.54.1
IP_DST: 112.45.54.176
TCP_SRC: 5433
TCP_DST: 80
Controller
Rule to install What should I do?
123
Bifulco talk at ewsdn2014
Software Defined Networking - 24Andrea Bianco – TNG group - Politecnico di Torino
SDN controller:
network programmability
Network OS
Controller Application
Events from switches
Topology changes
Traffic statistics
Arriving packets
Commands to switches
(Un)install rules
Query statistics
Send packets
Southbound interface
Rexford – Computer Network class
Pag. 13
Software Defined Networking
Software Defined Networking - 25Andrea Bianco – TNG group - Politecnico di Torino
Example of applications
• Dynamic access control
• Seamless mobility/migration
• Server load balancing
• Network virtualization
• Using multiple wireless access points
• Traffic engineering
• Energy-efficient networking
• Adaptive traffic monitoring
• Denial-of-Service attack detection
• …….
Rexford – Computer Network class
Software Defined Networking - 26Andrea Bianco – TNG group - Politecnico di Torino
Application:
Dynamic access control• Inspect first packet of a connection
• Consult the access control policy
• Install rules to block or route traffic
Rexford – Computer Network class
Pag. 14
Software Defined Networking
Software Defined Networking - 27Andrea Bianco – TNG group - Politecnico di Torino
Application:
Seamless mobility/migration• See host send traffic at new location
• Modify rules to reroute the traffic
Rexford – Computer Network class
Software Defined Networking - 28Andrea Bianco – TNG group - Politecnico di Torino
Application
Server load balancing• Pre-install load-balancing policy
• Split traffic based on source IP
src=0*
src=1*
Rexford – Computer Network class
Pag. 15
Software Defined Networking
Software Defined Networking - 29Andrea Bianco – TNG group - Politecnico di Torino
Traffic engineering:
difficult with traditional routingHp. Destination based routing
• What if network operator wants
– u-to-z traffic to flow along uvwz
– x-to-z traffic to flow xwyz?
• Need to define link weights so traffic routing algorithm
computes routes (or need a new routing algorithm)
• Does not work
– Modifies many routes
– Cannot change weights to route each individual flow
2
2
13
1
1
2
53
5
v w
u z
yx
Kurose Ross: Computer Networking
Software Defined Networking - 30Andrea Bianco – TNG group - Politecnico di Torino
Traffic engineering:
difficult with traditional routing• What if network operator wants to split u-to-z
traffic along uvwz and uxyz (load balancing)?
• Can’t do it (or need a new routing algorithm)
2
2
13
1
1
2
53
5
v w
u z
yx
Kurose Ross: Computer Networking
Pag. 16
Software Defined Networking
Software Defined Networking - 31Andrea Bianco – TNG group - Politecnico di Torino
yx
wv
z
2
2
13
1
1
2
5
3
5
Traffic engineering:
difficult with traditional routing• What if we wants to route blue and red traffic
differently?
• Can’t do it (with destination based
forwarding, and LS, DV routing)
u
v
x
w
y
z
Kurose Ross: Computer Networking
Software Defined Networking - 32Andrea Bianco – TNG group - Politecnico di Torino
SDN: switches
• Data plane switches
– Fast, simple, commodity
switches implementing
generalized data-plane
forwarding in HW
– Switch flow table computed,
installed by controller
– API for table-based switch
control
• Defines what is controllable
and what is not
– Protocol for communicating
with controllerdataplane
controlplane
SDN Controller(network operating system)
…routing
access control
loadbalance
southbound API
northbound API
SDN-controlled switches
network-control applications
Kurose Ross: Computer Networking
Pag. 17
Software Defined Networking
Software Defined Networking - 33Andrea Bianco – TNG group - Politecnico di Torino
dataplane
controlplane
SDN Controller(network operating system)
…routing
access control
loadbalance
southbound API
northbound API
SDN-controlled switches
network-control applications
SDN controller
• SDN controller
(network OS):
– Maintain network state
information
– Interacts with network
control applications
“above” via northbound
API
– Interacts with network
switches “below” via
southbound API
Kurose Ross: Computer Networking
Software Defined Networking - 34Andrea Bianco – TNG group - Politecnico di Torino
dataplane
controlplane
SDN Controller(network operating system)
…routing
access control
loadbalance
southbound API
northbound API
SDN-controlled switches
network-control applications
SDN application
• Network-control apps:
– “Brains” of control:
implement control
functions using lower-
level services, API
provided by SND
controller
– Unbundled: can be
provided by 3rd party:
distinct from routing
vendor, or SDN
controller
Kurose Ross: Computer Networking
Pag. 18
Software Defined Networking
Software Defined Networking - 35Andrea Bianco – TNG group - Politecnico di Torino
Network-wide distributed, robust state management
Communication to/from controlled devices
Link-state info switch infohost info
statistics flow tables…
…
OpenFlow SNMP…
network graph intent
RESTfulAPI
… Interface, abstractions for network control apps
routing access control
loadbalance
SDN controller components
• Interface layer to network
control apps
– Abstraction API
• State management layer
– Distributed database
• State of network links,
switches etc
• Communication layer
Kurose Ross: Computer Networking
Software Defined Networking - 36Andrea Bianco – TNG group - Politecnico di Torino
SDN: pros and cons
• Potential benefits
– Easier and faster innovation
– Exploits global network view
• Traffic enginering
• Traffic steering
• Security
• ….
– Simpler switches
• Less costly
• Less power hungry
– «Avoids» device
misconfiguration
– Virtual resource management
• Potential drawbacks
– Performance
• Overheads
• Scalability
• Bottleneck
– Single point of failure
– Interoperability
Pag. 19
Software Defined Networking
Software Defined Networking - 37Andrea Bianco – TNG group - Politecnico di Torino
SDN where?
• Campus LAN
• Data center
• WAN (google) to interconnect data centers
• ISP?
• 5G networks
Software Defined Networking - 38Andrea Bianco – TNG group - Politecnico di Torino
The role of the scenario
• Datacenter
– Very large number of devices
• Spatially collocated
– Low and predictable delays between devices
– Dedicated network for control
• Out of band control traffic
• ISP/POP
– Lower number of devices
• Spatially distributed
– High and unpredictable latencies
– Control and data share the same resources
• In band control traffic
Pag. 20
Software Defined Networking
Software Defined Networking - 39Andrea Bianco – TNG group - Politecnico di Torino
Level of aggregation
• Flow Based
– Every flow is individually
set up by controller
– Exact-match flow entries
– Flow table contains one
entry per flow
– Suited for fine grain
control, e.g. campus
networks
• Group Based
– One flow entry covers
large groups of flows
– Wildcard flow entries
– Flow table contains one
entry per category/group
of flows
– Suited for large number
of flows, e.g. ISPs
Software Defined Networking - 40Andrea Bianco – TNG group - Politecnico di Torino
Level of aggregation
• High aggregation level
– Dealing with few large objects
– Reduced occupation of forwarding table
– Reduced signaling overhead and controller load
– Coarse granularity in the control of flow Qos
• A flow steering moves a large amount of traffic
– Less elements to deal with for load balancing but
more difficult to balance
Pag. 21
Software Defined Networking
Software Defined Networking - 41Andrea Bianco – TNG group - Politecnico di Torino
Reactive vs. Proactive
• Reactive
– Flow table empty at boot
– First packet of a flow sent to
the controller
– Controller inserts flow entries
– Dynamic network
– Every flow incurs small (?)
additional flow setup time
– Large control traffic
– Large load on the controller
– Efficient use of flow table
– If control connection lost,
switch has limited utility
• Proactive
– Controller pre-populates flow
table in switch at boot
– Zero additional flow setup
time
– Static network
– Loss of control connection
does not disrupt traffic
– Essentially requires
aggregated (wildcard) rules
• Reduced table size
Software Defined Networking - 42Andrea Bianco – TNG group - Politecnico di Torino
OpenFlow protocol
Andrea Bianco
http://www.telematica.polito.it/
Pag. 22
Software Defined Networking
Software Defined Networking - 43Andrea Bianco – TNG group - Politecnico di Torino
Flow based forwarding
Capone – Netsoft 2015
Software Defined Networking - 44Andrea Bianco – TNG group - Politecnico di Torino
Data Path (Hardware)
Control Path OpenFlow
OpenFlow Controller
OpenFlow Protocol (SSL/TCP)
OpenFlow protocol
OpenFlow/SDN tutorial, Srini Seetharaman
Pag. 23
Software Defined Networking
Software Defined Networking - 45Andrea Bianco – TNG group - Politecnico di Torino
Controller
PC
OpenFlow protocol use
OpenFlow
Switch
OpenFlow
Switch
OpenFlow
Switch
My code
Decision?OpenFlow
Protocol
My Rule
My Rule My Rule
OpenFlow/SDN tutorial, Srini Seetharaman
Software Defined Networking - 46Andrea Bianco – TNG group - Politecnico di Torino
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
An example
OpenFlow/SDN tutorial, Srini Seetharaman
Pag. 24
Software Defined Networking
Software Defined Networking - 47Andrea Bianco – TNG group - Politecnico di Torino
OpenFlow protocol messages
• Controller-to-switch
– Initiated by the controller and used to directly manage or
inspect the state of the switch
• Features, Config, Modify State, Read State, Packet Out, Barrier
• Asynchronous
– Sent to the controller without controller soliciting
• Packet-in, Flow Removed/Expiration, Port status, Error, …
• Symmetric
– Sent without solicitation in any direction
• Hello, Echo, Experimenter/Vendor
Software Defined Networking - 48Andrea Bianco – TNG group - Politecnico di Torino
OpenFlow (main) messages
• Packet_in
– Switch to controller
– Carries a packet copy (possibly only the header)
• What is best?
– Generated by default in case of table miss
• Packet_out
– Controller to switch
– Send the packet out of a specified port
– Carries the full packet or the switch buffer id
• Flow_mod
– Controller to switch
– Modify flow tables
– Carries match-action rule to install
Pag. 25
Software Defined Networking
Software Defined Networking - 49Andrea Bianco – TNG group - Politecnico di Torino
OpenFlow example
Software Defined Networking - 50Andrea Bianco – TNG group - Politecnico di Torino
Packet processing
• Packets arrive and leave through ports
• Packets are matched to flow in flow tables using
classifiers
• Flows contain set of instructions and actions
applied to each packet in the match
Pag. 26
Software Defined Networking
Software Defined Networking - 51Andrea Bianco – TNG group - Politecnico di Torino
Packet lifecycle
• On packet arrival a key is built
– Metadata (arrival time, arrival port, memory location)
– Fields in packet header
• Key is use to select a flow in the table
• Actions associated with the flow are applied
– Drop, mutate, queue, forward, move to next table
Software Defined Networking - 52Andrea Bianco – TNG group - Politecnico di Torino
Packet matching
Pag. 27
Software Defined Networking
Software Defined Networking - 53Andrea Bianco – TNG group - Politecnico di Torino
Openflow switch implementation
OpenFlow Switch Specification Version 1.5.1
1 Introduction
This document describes the requirements of an OpenFlow Logical Switch. Addit ional informat ion
describing OpenFlow and Software Defined Networking is available on the Open Networking Foundat ion
website (https://www.opennetworking.org/). This specificat ion covers the components and the basic
funct ions of the switch, and the OpenFlow switch protocol to manage an OpenFlow switch from a
remote OpenFlow cont roller.
Port
Port
Port
Port
OpenFlow
Channel
Flow
Table
Flow
Table
Flow
Table
Controller
Pipeline
OpenFlow Switch
OpenFlow
Channel Group
Table
Meter
TableControl Channel
Controller
Datapath
Protocol
Figure 1: Main components of an OpenFlow switch.
2 Switch Components
An OpenFlow Logical Switch consists of one or moreflow tables and a group table, which perform packet
lookups and forwarding, and one or more OpenFlow channels to an external cont roller (Figure 1). The
switch communicates with the cont roller and the cont roller manages the switch via the OpenFlow switch
protocol.
Using the OpenFlow switch protocol, the controller can add, update, and delete flow entries in flow
tables, both react ively (in response to packets) and proact ively. Each flow table in the switch contains
a set of flow entries; each flow ent ry consists of match fields, counters, and a set of instructions to apply
to matching packets (see 5.2).
Matching starts at the first flow table and may cont inue to addit ional flow tables of the pipeline (see
5.1). Flow ent ries match packets in priority order, with the first matching entry in each table being
used (see 5.3). I f a matching entry is found, the inst ruct ions associated with the specific flow ent ry are
executed (see 5.5). If no match is found in a flow table, the outcome depends on configurat ion of the
11 © 2015; The Open Networking Foundation
Software Defined Networking - 54Andrea Bianco – TNG group - Politecnico di Torino
OpenFlow switch implementation
OpenFlow Switch Specification Version 1.5.1
I f the table-miss flow entry does not exist , by default packets unmatched by flow entries are dropped
(discarded). A switch configurat ion, for example using the OpenFlow Configurat ion Protocol, may
override this default and specify another behaviour. A flow entry that uses the lowest priority (0) and
has a match that does not wildcards all match fields can be used if the flow table supports it , however
this is not a table-miss flow ent ry. Using such flow ent ry would make sense only if a table-miss flow
entry is not used, because if a table-miss flow entry exists they would overlap and matching is then
undefined. For this reason, it is recommended that the controller does not create non-table-miss flow
entries that use the lowest priority (0).
5.5 Instructions
Match
Find highest
priority
m atching
flow ent ry
Apply-actions
{list of actions} • modify packet
• update match fields
• update pipeline fields
• if output or group
→ clone packet
Clear-actions • empty action set
Write-actions
{set of actions} • merge in action set
Goto-table
{table-id}
Extract
header
fields
Apply Inst ruct ions
Flow Tab le
Pack et
Act ion
Set
Pip e l in e
Fie ld s
EgressPacket clones
Execute
Action
Set
Flow
Table
flow entry
flow entry
flow entry
flow entry
flow entry
table miss
flow entry
Figure 4: Matching and Inst ruct ion execut ion in a flow table.
Each flow ent ry contains a set of inst ruct ions that are executed when a packet matches the ent ry. These
inst ruct ions result in changes to the packet , act ion set and/ or pipeline processing (see Figure 4).
A switch is not required to support all inst ruct ion types, just those marked “Required Instruction”
below. The controller can also query the switch about which of the “Optional Instruction” types it
supports (see 7.3.5.18).
• Optional Instruction: A pply-Act ions action( s) : Applies the specific act ion(s) immediately,
without any change to the Act ion Set . This inst ruct ion may be used to modify the packet between
two tables or to execute mult iple act ions of the same type. The act ions are specified as a list of
act ions (see 5.7).
25 © 2015; The Open Networking Foundation
Pag. 28
Software Defined Networking
Software Defined Networking - 55Andrea Bianco – TNG group - Politecnico di Torino
Openflow versions
• Published by Open Networking Foundation
– No profit
– Funded by Deutsche Telekom, Facebook,
Google, Microsoft, Verizon, etc.
Software Defined Networking - 56Andrea Bianco – TNG group - Politecnico di Torino
SDN architecture in action
Andrea Bianco
http://www.telematica.polito.it/
Pag. 29
Software Defined Networking
Software Defined Networking - 57Andrea Bianco – TNG group - Politecnico di Torino
Link-state info switch infohost info
statistics flow tables…
…
OpenFlow SNMP…
network graph
intentRESTful
API…
1
2
3
4 5
Dijkstra’s link-state Routing
s1s2
s3s4
S1, experiencing link failure using OpenFlow port status message to notify controller
1
SDN controller receives OpenFlow message, updates link status info
2
Dijkstra’s routing algorithm application has previously registered to be called when ever link status changes. It is called.
3
Dijkstra’s routing algorithm access network graph info, link state info in controller, computes new routes
4
An example
From Kurose Ross: Computer Networking
Software Defined Networking - 58Andrea Bianco – TNG group - Politecnico di Torino
Link-state info switch infohost info
statistics flow tables…
…
OpenFlow SNMP…
network graph
intentRESTful
API…
1
2
3
4 5
Dijkstra’s link-state Routing
s1s2
s3s4
Link state routing app interacts with flow-table-computation component in SDN controller, which computes new flow tables needed
5
Controller uses OpenFlow to install new tables in switches that need updating
6
An example
From Kurose Ross: Computer Networking
Pag. 30
Software Defined Networking
Software Defined Networking - 59Andrea Bianco – TNG group - Politecnico di Torino
Distributed controllers
Andrea Bianco
http://www.telematica.polito.it/
Software Defined Networking - 60Andrea Bianco – TNG group - Politecnico di Torino
Centralized vs Distributed Control
Centralized Control
OpenFlow Switch
OpenFlow Switch
OpenFlow Switch
Controller
Distributed Control
OpenFlow Switch
OpenFlow Switch
OpenFlow Switch
Controller
Controller
Controller
Srini Seetharaman, OpenFlow/SDN tutorial
Pag. 31
Software Defined Networking
Software Defined Networking - 61Andrea Bianco – TNG group - Politecnico di Torino
Why distributed/multiple
controllers?• To enhance resilience to failures
– Controller failures can be managed
– Still to deal with failures in data and control plane
• To solve scalability issues
– Faster controllers
• Limited scaling
– More proactive rules to reduce number of requests
• Limited flexibility
– Multiple controllers
• Permit load balancing to reduce processing load
• Permit switch migration
Software Defined Networking - 62Andrea Bianco – TNG group - Politecnico di Torino
Distributed controllers
• Virtual topology among controllers
– to coordinate the operations of the controllers
– peer, hierarchical, master/slave
• Network view maintenance
– different levels of consistency (strong/weak)
among the controllers
– affects the reactivity
– may lead to temporary rule conflicts
Pag. 32
Software Defined Networking
Software Defined Networking - 63Andrea Bianco – TNG group - Politecnico di Torino
Control plane in
distributed controllers• Switch-controller (Sw-Ctr) traffic
– Standardized
• Controller-controller (Ctr-Ctr) traffic (East-West-bound interfaces)
– Proprietary
– To get consistent view
– May be non neglibile
– Critical for reactivity
Sw
itch
-
contr
olle
r
traffic
Inter-controller traffic
Software Defined Networking - 64Andrea Bianco – TNG group - Politecnico di Torino
Data authoritative model
• A single controller is owner of the shared data
– e.g. network graph, association switch to controller
• Single data owner model
– Read/write operations always forwarded by the local
controller to the data owner controller
– distributed architecture only for high availability
– implemented in clustered version of OpenDaylight
• Multiple data owner model
– Read/write operations are local and then forwarded
(asynchronously) to the data owner controller
Pag. 33
Software Defined Networking
Software Defined Networking - 65Andrea Bianco – TNG group - Politecnico di Torino
Inter controller traffic
• Single data owner
• Setting up the shortest path to the source for
all switches
Software Defined Networking - 66Andrea Bianco – TNG group - Politecnico di Torino
Reactivity for
Multi Data Ownership
Switch S1
ResponseUpdate
data
Flood
update
Data owner
controller
TRTR = Sw-Ctr RTT
Data owner
controller Data owner
controller
Pag. 34
Software Defined Networking
Software Defined Networking - 67Andrea Bianco – TNG group - Politecnico di Torino
Reactivity for
Single Data Ownership• Algorithm for strong consistency
Data owner
controller
Switch S1
Raft
request
Log
replicatiom
ResponseUpdate
data
Log
replyLog commit
(on majority)
Controller
Controller
TR
TR = Sw-Ctr RTT+2 Ctr-Ctr RTT
Software Defined Networking - 68Andrea Bianco – TNG group - Politecnico di Torino
Controller placement
• 3 controllers
• each point correspond to a different
controller placement
Pag. 35
Software Defined Networking
Software Defined Networking - 69Andrea Bianco – TNG group - Politecnico di Torino
Control plane: ctr-ctr traffic
• Traffic exchanged (in band) between controllers to
synchronize the shared data structures within a cluster of
SDN controllers
• Topology store in ONOS (fixed topology, LLDP refresh only)
Software Defined Networking - 70Andrea Bianco – TNG group - Politecnico di Torino
Stateful data plane
Andrea Bianco
http://www.telematica.polito.it/
Pag. 36
Software Defined Networking
Software Defined Networking - 71Andrea Bianco – TNG group - Politecnico di Torino
Stateful SDN dataplane
• Stateless approach (OpenFlow)
– Stateless switches, all the states in the controller
– Limited reactivity due to the (logically) centralized approach
• Stateful approach: OpenState, OpenPacketProcessor
(OPP), P4
– Permit some level of stateful processing (e.g., finite state machines)
within switches
• OpenState adds a state table (IF state A THEN IF state B THEN)
• OpenPacketProcessor: state defined with multiple variables, counters,
• P4 much more flexible (description language of HW behavior)
– Enabled by new generation of hardware
• 6.5Tbps Tofino chipset @ Barefoot Networks
Software Defined Networking - 72Andrea Bianco – TNG group - Politecnico di Torino
Hardware implementation
Pag. 37
Software Defined Networking
Software Defined Networking - 73Andrea Bianco – TNG group - Politecnico di Torino
Toy example Naive load balancer
Other examples
– Interaction with a classifier
– Port knocking
controller controller
Traditional SDN Stateful SDN
Stateless switch Stateful switch
FSM
0 1
Forward up
Forward down
State 01
Forward upForward down
FSM
State 0
Forward up
1Forward down
Software Defined Networking - 74Andrea Bianco – TNG group - Politecnico di Torino
Traffic classification
Mirror a pre-defined number of packets to traffic classifier for each flow
Interrupt the mirroring if the flow is identified
Pag. 38
Software Defined Networking
Software Defined Networking - 75Andrea Bianco – TNG group - Politecnico di Torino
Traffic classification
• Two approaches
– Simple Count Down
– Memory purging issued by the controller to avoid
waiting for the timeout
Software Defined Networking - 76Andrea Bianco – TNG group - Politecnico di Torino
Traffic classification
– Compact Count Down
• Countdown interruption envisioned
Pag. 39
Software Defined Networking
Software Defined Networking - 77Andrea Bianco – TNG group - Politecnico di Torino
Port knocking: tables
Software Defined Networking - 78Andrea Bianco – TNG group - Politecnico di Torino
Stateful benefits Improve network reactivity
– Simple local decisions at the switch
– Reduced controller load
– Reduced signaling overhead
Permits to gracefully move functionalities
– Balance central vs distributed control
Not all switches need to be stateful
– State positioning or distribution
Pag. 40
Software Defined Networking
Software Defined Networking - 79Andrea Bianco – TNG group - Politecnico di Torino
Time-based SDN operations
Andrea Bianco
http://www.telematica.polito.it/
Software Defined Networking - 80Andrea Bianco – TNG group - Politecnico di Torino
A toy example
• Enables synchronous operations
• In elastic optical networks (grid based WDM)
permits to reduce the disruption time induced by
lightpath swapping
• If a new request of 2 slots from A to D arrives, to accept it
we need to move currently allocated lightpaths
– If done asynchronously it would imply longer reconfiguration times
Pag. 41
Software Defined Networking
Software Defined Networking - 81Andrea Bianco – TNG group - Politecnico di Torino
Hands on SDN
Andrea Bianco
http://www.telematica.polito.it/
Software Defined Networking - 82Andrea Bianco – TNG group - Politecnico di Torino
Openflow switches
• Openflow hardware switches are still
expensive since aimed at high-professional
market (e.g. data centers, network operators)
• Openflow software switches
– OpenvSwitch
• open-source virtual software switch
• can be installed on a pc, on a VM, within the kernel
• supports Openflow
Pag. 42
Software Defined Networking
Software Defined Networking - 83Andrea Bianco – TNG group - Politecnico di Torino
SDN emulators
• Network emulator
– Mininet
• Network of OF
switches
• Linux hosts
– API to issue
OpenFlow
commands
– Very basic
controller
available
Software Defined Networking - 84Andrea Bianco – TNG group - Politecnico di Torino
SDN controllers
• (too) many controllers are available
– you can easily write your own
Pag. 43
Software Defined Networking
Software Defined Networking - 85Andrea Bianco – TNG group - Politecnico di Torino
SDN Controllers
• Open-source controllers
– POX
• phython, just for test
– OpenDaylight
• vendor-funded project
• “the universal controller” for data centers and TLC operators
• quite complex but flexible
– ONOS
• focused for large telecom networks
• well-documented and relatively simple to use
– Ryu
• good compromise between simplicity and flexibility
Software Defined Networking - 86Andrea Bianco – TNG group - Politecnico di Torino
First hands on Openflow
• Download the VM
– https://github.com/mininet/openflow-tutorial/wiki
• Follow the instructions
• Enjoy!
Pag. 44
Software Defined Networking
Software Defined Networking - 87Andrea Bianco – TNG group - Politecnico di Torino
SDN and NFV
Andrea Bianco
http://www.telematica.polito.it/
Software Defined Networking - 88Andrea Bianco – TNG group - Politecnico di Torino
SDN and virtualization
• Are SDN and virtualization related?
– Yes and no
• Are virtualization and network slicing related?
– Yes and no
• SDN and NFV related?
– Yes and no
• Virtualization/Network slicing/NFV exist without SDN
– Virtualization already available for CPU, resources, disk, virtual
machines, …
• SDN makes it easier to exploit virtualization at the network
level
Pag. 45
Software Defined Networking
Software Defined Networking - 89Andrea Bianco – TNG group - Politecnico di Torino
Definitions
• Virtualization
– Abstraction of resources
• Hiding irrelevant aspects
• Network slicing
– Network partitioning
– Possibly of virtual resource
• NFV
– Exploits virtualization to virtualize nodes and
functions (typically in chain)
Software Defined Networking - 90Andrea Bianco – TNG group - Politecnico di Torino
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
HardwareSimple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
Simple Packet
Forwarding
Hardware
OpenFlow/SDN tutorial, Srini Seetharaman
Pag. 46
Software Defined Networking
Software Defined Networking - 91Andrea Bianco – TNG group - Politecnico di Torino
FlowVisor
• Example of network virtualization with
Openflow (2009)
• Partition the flow tables in each Openflow
switch
– which flow belongs to each controller
• “flowspace” defines a network slice
• Packet header used to identify the flowspace
• FlowVisor acts as a proxy between the
Openflow switches and the controllers
Software Defined Networking - 92Andrea Bianco – TNG group - Politecnico di Torino
FlowVisorFlowVisor Architecture
Custom
Control
Plane
Stub
Control
Plane
Data
Plane
OpenFlow
Protocol
Switch/Router
Server
Network
Servers
OpenFlow
Firmware
Data Path
OpenFlow
Controller
Switch/Router
OpenFlow
Firmware
Data Path
OpenFlow
Controller
OpenFlow
Controller
OpenFlow
Controller
FlowVisor
OpenFlow
OpenFlow
Pag. 47
Software Defined Networking
Software Defined Networking - 93Andrea Bianco – TNG group - Politecnico di Torino
Switch Based Virtualization
Normal L2/L3 Processing
Flow Table
Production VLANs
Research VLAN 1
Controller
Research VLAN 2
Flow Table
Controller
OpenFlow/SDN tutorial, Srini Seetharaman
Software Defined Networking - 94Andrea Bianco – TNG group - Politecnico di Torino
SDN and NFV
• Software-driven networking solution
• Open software and standard hardware
– NFV: run NFs on industry standard hardware
– SDN: run controller and software switch
(vSwitch) on industry standard hardware
Pag. 48
Software Defined Networking
Software Defined Networking - 95Andrea Bianco – TNG group - Politecnico di Torino
Reciprocal support SDN-NFV
• NFV supports SDN
– SDN controller and/or network applications can
run on a VM in a cloud
• leverage reliability and elasticity
• SDN supports NFV
– SDN provides the logical routing across a chain
of functions
– SDN provides network connectivity and provides
end-2-end performance guarantees
Software Defined Networking - 96Andrea Bianco – TNG group - Politecnico di Torino
SDN and NFV differences
• Separation
– NFV aims at decoupling NFs from specialized
hardware
– SDN aims at separating the packet forwarding
from the network control
• Legacy
– NFV can work on existing networks
– SDN needs new network equipment
Pag. 49
Software Defined Networking
Software Defined Networking - 97Andrea Bianco – TNG group - Politecnico di Torino
SDN and NFV differences
• Granularity
– NFV works at service level
• SLA at L7 level
– SDN works at flow level
• OpenFlow at L2-L4 level
• Data plane works at packet-by-packet