software defined networking - polito.it · pag. 5 software defined networking andrea bianco –tng...

Pag. 1

Software Defined Networking

Software Defined Networking - 1Andrea Bianco – TNG group - Politecnico di Torino


(SDN)

Andrea Bianco

[email protected]

http://www.telematica.polito.it/


Outline

• SDN

– Motivations, definitions, architecture,

– Flow based forwarding

• Openflow protocol

• Some issues

• Advances

– Distributed controllers

– Stateful switches


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

Pag. 2




• Control plane

– Distributed algorithms

• Topology discovery, topology tracking, route computation,

installing forwarding rules, traffic engineering

– Seconds time scale, flow time scale

• Slow process




• Management plane

– Local/global algorithms with coordination

• Measurement, configuration, monitoring, protection and

restoration

– Mostly «human» time scale




• 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. 3



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


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…



Too many protocols/standards?


Pag. 4



Vendors dominated



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


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


Pag. 5



Centralized control

API to the data plane

(e.g., OpenFlow protocol)

Logically-centralized control

Switches

smart

slow

very dumb

fast

Controller



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



A Helpful Analogy

From Nick McKeown’s talk

“Making SDN Work” at the

Open Networking Summit, April 2012

Pag. 6



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


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


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. 7



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


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



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


Pag. 8



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..



… 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


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


Pag. 9



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

• …….



Application:

Dynamic access control• Inspect first packet of a connection

• Consult the access control policy

• Install rules to block or route traffic



Application:

Seamless mobility/migration• See host send traffic at new location

• Modify rules to reroute the traffic


Pag. 10



Application

Server load balancing• Pre-install load-balancing policy

• Split traffic based on source IP

src=0*

src=1*



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



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


Pag. 11



yx

wv

z

2

2

13

1

1

2

5

3

5


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



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



dataplane

controlplane


…routing

access control

loadbalance

southbound API

northbound API



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


Pag. 12



dataplane

controlplane


…routing

access control

loadbalance

southbound API

northbound API



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



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



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. 13



SDN where?

• Campus LAN

• Data center

• WAN (google) to interconnect data centers

• ISP?

• 5G networks


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


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

Pag. 14



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


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


OpenFlow protocol

Andrea Bianco

[email protected]


Pag. 15



Flow based forwarding



Data Path (Hardware)

Control Path OpenFlow

OpenFlow Controller

OpenFlow Protocol (SSL/TCP)

OpenFlow protocol



Controller

PC

OpenFlow protocol use

OpenFlow

Switch

OpenFlow

Switch

OpenFlow

Switch

My code

Decision?OpenFlow

Protocol

My Rule

My Rule My Rule


Pag. 16



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 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


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. 17



OpenFlow example


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


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

Pag. 18



Packet matching


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


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. 19



Openflow versions

• Published by Open Networking Foundation

– No profit

– Funded by Deutsche Telekom, Facebook,

Google, Microsoft, Verizon, etc.


SDN architecture in action

Andrea Bianco

[email protected]





…

OpenFlow SNMP…


RESTfulAPI

…

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

Pag. 20





…

OpenFlow SNMP…


RESTfulAPI

…

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


Some issue?

Andrea Bianco

[email protected]



Topology discovery

• Through LLDP

– Link Layer Discovery

Protocol

Pag. 21



Topology discovery

• Controller view is not always complete.

• For instance, what does the controller see

here?

Internet

Host

A

X YNon-OF

switch

Non-OF

switch

OF

switch

OF

switch

Host

B

Host

C



Protection/restoration

• Current network heavily rely on SDH

– Ring based topology

– Fast automatic reconfiguration

• SDN centralized approach may be slow

– Alternative port can be specified

• Need to ensure consistency while modifying

a policy


OpenFlow traffic:

an (extreme) example• Given a network application and a topology, empirical model

to evaluate the Openflow traffic

• Based on real controllers (ONOS / OpenDaylight) and

applications (layer 2 fwd)

• Goal: evaluate impact of (in band) control traffic in real

networks

Pag. 22



Distributed controllers

Andrea Bianco

[email protected]



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


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

Pag. 23



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


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

-

co

ntr

olle

r

tra

ffic

Inter-controller traffic


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. 24



Inter controller traffic

• Single data owner

• Setting up the shortest path to the source for

all switches


Reactivity for

Multi Data Ownership

Switch S1

ResponseUpdate

data

Flood

update

Data owner

controller

TRTR = Sw-Ctr RTT

Data owner

controller Data owner

controller


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

Pag. 25



Controller placement

• 3 controllers

• each point correspond to a different

controller placement


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)


Stateful data plane

Andrea Bianco

[email protected]


Pag. 26



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


Hardware implementation


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

Pag. 27



Traffic classification

Mirror a pre-defined number of packets to traffic classifier for each flow

Interrupt the mirroring if the flow is identified



• Two approaches

– Simple Count Down

– Memory purging issued by the controller to avoid

waiting for the timeout



– Compact Count Down

• Countdown interruption envisioned

Pag. 28



Port knocking: tables


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


Time based operation

Andrea Bianco

[email protected]


Pag. 29



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


Hands on SDN

Andrea Bianco

[email protected]



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. 30



SDN emulators

• Network emulator

– Mininet

• Network of OF

switches

• Linux hosts

– API to issue

OpenFlow

commands

– Very basic

controller

available


SDN controllers

• (too) many controllers are available

– you can easily write your own


SDN Controllers

• Open-source controllers

– POX

• phython, just for test

– OpenDaylight

• vendor-funded project

• “the universal controller” for data centers and TLC operator

• quite complex but flexible

– ONOS

• focused for large telecom networks

• well-documented and relatively simple to use

– Ryu

• good compromise between simplicity and flexibility

Pag. 31



First hands on Openflow

• Download the VM

– https://github.com/mininet/openflow-tutorial/wiki

• Follow the instructions

• Enjoy!


SDN and NFV

Andrea Bianco

[email protected]



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. 32



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)


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

Ap

p

Ap

p

Ap

p

Ap

p

Ap

p

Ap

p

Ap

p

Ap

p

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



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

Pag. 33



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


Switch Based Virtualization

Normal L2/L3 Processing

Flow Table

Production VLANs

Research VLAN 1

Controller

Research VLAN 2

Flow Table

Controller



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. 34



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


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


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

software defined networking - polito.it · pag. 5 software defined networking andrea bianco –tng...

Documents