SDN 2019 PDF

So#ware
Defined
Network: SDN
Khalid EL BAAMRANI
ENSA de Marrakech
So#ware Defined
Network: SDN
Khalid EL BAAMRANI
ENSA de Marrakech
1
Agenda
•  General introduc.on to SDN
•  SDN Basics
•  SDN Concepts
•  OpenFlow Protocole
•  OpenFlow Switchs
•  OpenFlow Controllers
•  QoS in SDN
•  SDN Security
•  Mininet
2 SDN
Agenda
•  General introduc.on to SDN
•  SDN Basics
•  SDN Concepts
•  OpenFlow Protocole
•  OpenFlow Switchs
•  OpenFlow Controllers
•  QoS in SDN
•  SDN Security
•  Mininet
2 SDN
Traditional-Based Networking
Vendor-based solutions with

closed hardware and
closed software (not that
there is anything wrong with
that – scalability, cost?)
Separate device
configurations
Each year more devices, more complexity, more

configurations
Vendor-based solutions with

closed hardware and
closed software (not that
there is anything wrong with
that – scalability, cost?)
Separate device
configurations
Each year more devices, more complexity, more

configurations
And what is on these devices?
Multi layer multi

Protocols region
Firewall
IPV6 IPSec
Protocols Router
multicast
le IP
Mobi HELLO
Protocols
OSPF-TE So>ware HELLO
Control L2 V
VPLN
AN
HELLO
Hardware
RSVP-TE
Datapath
Protocols
And what is on these devices?
Multi layer multi

Protocols region
Firewall
IPV6 IPSec
Protocols Router
multicast
le IP
Mobi HELLO
Protocols
OSPF-TE So>ware HELLO
Control L2 V
VPLN
AN
HELLO
Hardware
RSVP-TE
Datapath
Protocols
So what does a Network Engineer ? do…
Network device
configuration,
configuration,
configuration,
and more
configuration
Followed by…
troubleshooting
misconfigurations
Configuration-Based Networking
So what does a Network Engineer ? do…

Network device
configuration,
configuration,
configuration,
and more
configuration
Followed by…
troubleshooting
misconfigurations
Configuration-Based Networking
Networking Industry
Source: Nick Mckeown, Stanford
Specialized
Features
Specialized
Control
Plane
Specialized
Hardware
Closed Boxes
7 SDN
Networking Industry
Specialized
Features
Specialized
Control
Plane
Specialized
Hardware
Closed Boxes
7 SDN
Computer Industry
AppAppAppAppAppAppAppAppAppAppApp
Specialized
Open Interface
Applications
Specialized Windows Mac
or Linux or
Operating (OS) OS
System
Open Interface
Specialized
Hardware Microprocessor
Vertically integrated Horizontal

Closed, proprietary Open interfaces
Slow innovation Rapid innovation
8 Small industry Huge industry SDN
Computer Industry
Specialized
Open Interface
Applications
Specialized Windows Mac
or Linux or
Operating (OS) OS
System
Open Interface
Specialized
Hardware Microprocessor

8 Small industry Huge industry SDN
Networking Industry
Rou.ng, management, mobility management,

access control, VPNs, …
Feature Feature
Million of lines 6000 RFCs
of source code
Operating
System
Specialized Packet Billions of gates

Forwarding Hardware
Closed, ver.cally integrated, closed, complex, proprietary

Many complex func.ons baked into the infrastructure
OSPF, BGP, mul,cast, differen,ated services,
Traffic Engineering, NAT, firewalls, MPLS, redundant layers, …

9 Func.onality defined by standards, put in hardware, deployed on nodes SDN
Networking Industry
Rou.ng, management, mobility management,

access control, VPNs, …
Feature Feature
Million of lines 6000 RFCs
of source code
Operating
System
Specialized Packet Billions of gates

Forwarding Hardware
Closed, ver.cally integrated, closed, complex, proprietary

Many complex func.ons baked into the infrastructure
OSPF, BGP, mul,cast, differen,ated services,
Traffic Engineering, NAT, firewalls, MPLS, redundant layers, …

9 Func.onality defined by standards, put in hardware, deployed on nodes SDN

Control plane and data plane
l  Control plane of a network
–  The functions of a network that control the behavior of the
network
l  E.g.: Which path to take for a packet? Which port to forward a
packet? Should the packet be dropped?
–  Control plane functions are typically realized by software
such as routing protocols, firewall code, etc.
l  Data plane of a network
–  The functions of a network that actually forward or drop
packets.
–  Data plane functions are typically realized by hardware
l  Control plane and data plane are vertically integrated
in traditional networking equipment
–  Separating software from hardware à separating control
plane from data plane.
11 SDN
Control plane and data plane

l  Control plane of a network
–  The functions of a network that control the behavior of the
network
l  E.g.: Which path to take for a packet? Which port to forward a
packet? Should the packet be dropped?
–  Control plane functions are typically realized by software
such as routing protocols, firewall code, etc.
l  Data plane of a network
–  The functions of a network that actually forward or drop
packets.
–  Data plane functions are typically realized by hardware
l  Control plane and data plane are vertically integrated
in traditional networking equipment
–  Separating software from hardware à separating control
plane from data plane.
11 SDN
Networking Industry
Specialized Open Interface

Features
Control Control Control
or or
Specialized Plane Plane Plane
Control
Plane Open Interface
Specialized Merchant
Hardware Switching Chips

12 SDN
Networking Industry
Specialized Open Interface

Features
Control Control Control
or or
Specialized Plane Plane Plane
Control
Plane Open Interface
Specialized Merchant
Hardware Switching Chips

12 SDN
Computing systems now
•  Open interfaces
Open Interface •  Fast innovation
o  Everyone can
Windows Mac
or Linux or participate
(OS) OS
•  Hugh industry
Open Interface •  Software is now
Microprocessor part of everything.
13 SDN
Computing systems now

•  Open interfaces
Open Interface •  Fast innovation
o  Everyone can
Windows Mac
or Linux or participate
(OS) OS
•  Hugh industry
Open Interface •  Software is now
Microprocessor part of everything.
13 SDN
Ideal networking system for innovation
AppAppAppAppAppAppAppAppAppAppApp Network apps
Open Interface API of Net OS

Control Control
Control
Plane or or Plane Network Operating Systems
Plane
Open Interface API for controlling

Network hardware
Network hardware
14 SDN
AppAppAppAppAppAppAppAppAppAppApp Network apps
Open Interface API of Net OS

Control Control
Control
Plane or or Plane Network Operating Systems
Plane
Open Interface API for controlling

Network hardware
Network hardware
14 SDN
l  Separate hardware
from software
Open Interface
l  Standardize the
Control
Control
Control interface
Plane or or Plane
–  Each layer provides an
Plane
abstrac.on
Open Interface l  Innova.on is possible
for anyone just like
so>ware development
for a compu.ng system.
This is the vision of SDN
15 SDN
l  Separate hardware
from software
Open Interface
l  Standardize the
Control
Control
Control interface
Plane or or Plane
–  Each layer provides an
Plane
abstrac.on
Open Interface l  Innova.on is possible
for anyone just like
so>ware development
for a compu.ng system.
This is the vision of SDN
15 SDN
So#ware Defined Network (SDN)
SDN now: separate forwarding hardware from controlling software
Firewall, virtual network, routing, etc
Open Interface Northbound API

Control Control
Control SDN controllers (floodlight, nox, etc)
Plane or or Plane
Plane
Open Interface Southbound API

OpenFlow: standardized for
Ethernet/IP/TCP
OpenFlow enabled switches/routers

simple hardware doing forwarding only
forwarding table can be set by other
entity through OpenFlow
16 SDN

SDN now: separate forwarding hardware from controlling software
Firewall, virtual network, routing, etc
Open Interface Northbound API

Control Control
Control SDN controllers (floodlight, nox, etc)
Plane or or Plane
Plane
Open Interface Southbound API

OpenFlow: standardized for
Ethernet/IP/TCP
OpenFlow enabled switches/routers

simple hardware doing forwarding only
forwarding table can be set by other
entity through OpenFlow
16 SDN
Trend
App App App

App App App
Controller
Controller Controller
Controller
Windows
Windows Mac NOX
11
Mac
Windows
(OS)
(OS)
Linux
Linux
Linux
Mac
OS
OS (Network OS) 22
Network OS
(OS) OS
Virtualization layer Virtualization or “Slicing”
x86 Open Interface

(Computer) e.g. OpenFlow
Computer Industry Network Industry
17 SDN
Trend
App App App

App App App
Controller
Controller
Windows
Windows Mac NOX
11
Mac
Windows
(OS)
(OS)
Linux
Linux
Linux
Mac
OS
OS (Network OS) 22
Network OS
(OS) OS
Virtualization layer Virtualization or “Slicing”
x86 Open Interface

(Computer) e.g. OpenFlow
Computer Industry Network Industry
17 SDN
Consequences
More innovation in network services

–  Owners, operators, developers, researchers can
improve the network
–  E.g. energy management, data center management,
policy routing, access control, denial of service, mobility
Lower barrier to entry for competition

–  New players
18 SDN
Consequences
More innovation in network services

–  Owners, operators, developers, researchers can
improve the network
–  E.g. energy management, data center management,
policy routing, access control, denial of service, mobility
Lower barrier to entry for competition

–  New players
18 SDN
Classical network architecture
l  Distributed control plane
–  Distributed routing protocols: OSPF, IS-IS, BGP, etc.
l  Software for the control plane cannot be separated from the
forwarding hardware in the data plane.
–  Vertically integrated, complex, closed, proprietary
l  Innovation is only possible if one has access to the router box.
–  No significant innovation
Feature Feature
in the past 40 years.

Operating Feature Feature
System
Specialized Packet Operating
Forwarding System
Hardware
Feature Feature Specialized Packet
Forwarding
Hardware
Operating
System
Feature Feature
Specialized Packet
Forwarding
Operating
Hardware
System
Specialized Packet
Forwarding
Feature Feature
Hardware
Operating
System
Specialized Packet
Forwarding
19 Hardware SDN
Classical network architecture

–  Distributed routing protocols: OSPF, IS-IS, BGP, etc.
l  Software for the control plane cannot be separated from the
forwarding hardware in the data plane.
–  Vertically integrated, complex, closed, proprietary
l  Innovation is only possible if one has access to the router box.
–  No significant innovation
Feature Feature
in the past 40 years.

Operating Feature Feature
System
Specialized Packet Operating
Forwarding System
Hardware
Feature Feature Specialized Packet
Forwarding
Hardware
Operating
System
Feature Feature
Specialized Packet
Forwarding
Operating
Hardware
System
Specialized Packet
Forwarding
Feature Feature
Hardware
Operating
System
Specialized Packet
Forwarding
19 Hardware SDN
The network is changing
Feature Feature
Network OS
Feature Feature
OS
Feature Feature
Custom Hardware
OS
Feature Feature
Custom Hardware
OS
Feature Feature
Custom Hardware
OS
Feature Feature Custom Hardware
OS
Custom Hardware
20 SDN
The network is changing

Feature Feature
Network OS
Feature Feature
OS
Feature Feature
Custom Hardware
OS
Feature Feature
Custom Hardware
OS
Feature Feature
Custom Hardware
OS
Feature Feature Custom Hardware
OS
Custom Hardware
20 SDN

3. Consistent, up-to-date global network view 2. At least one Network OS
probably many.
Open- and closed-source
Feature Feature
Network OS
1. Open interface to packet forwarding
Packet
Forwarding
Packet
Forwarding

Packet
Forwarding
Packet
Forwarding
Packet
Forwarding
21 SDN

3. Consistent, up-to-date global network view 2. At least one Network OS
probably many.
Open- and closed-source
Feature Feature
Network OS
1. Open interface to packet forwarding
Packet
Forwarding
Packet
Forwarding

Packet
Forwarding
Packet
Forwarding
Packet
Forwarding
21 SDN
What is software defined networking?
l  Software-defined networking (SDN) is an approach to
computer networking that separate data plane from
control plane. It allows network administrators to
manage network services through abstraction of lower-
level functionality.
l  SDN is
–  Directly programmable: network control is programmable
because it is decoupled from forwarding functions
–  Agile: administrator can dynamically adjust network-wide
traffic flow to meet changing needs.
–  Centrally managed: network intelligence is logically
centralized.
–  Open standards-based and vendor-neutral
22 SDN
What is software defined networking?

l  Software-defined networking (SDN) is an approach to
computer networking that separate data plane from
control plane. It allows network administrators to
manage network services through abstraction of lower-
level functionality.
l  SDN is
–  Directly programmable: network control is programmable
because it is decoupled from forwarding functions
–  Agile: administrator can dynamically adjust network-wide
traffic flow to meet changing needs.
–  Centrally managed: network intelligence is logically
centralized.
–  Open standards-based and vendor-neutral
22 SDN
SDN Concept
l  Separate Control plane and Data plane entities
–  Network intelligence and state are logically centralized
–  The underlying network infrastructure is abstracted from
the applications
l  Execute or run Control plane software on general
purpose hardware
–  Decouple from speci@ic networking hardware
–  Use commodity servers
l  Have programmable data planes
–  Maintain, control and program data plane state from a
central entity
l  An architecture to control not just a networking
device but an entire network
23 SDN
SDN Concept
l  Separate Control plane and Data plane entities
–  Network intelligence and state are logically centralized
–  The underlying network infrastructure is abstracted from
the applications
l  Execute or run Control plane software on general
purpose hardware
–  Decouple from speci@ic networking hardware
–  Use commodity servers
l  Have programmable data planes
–  Maintain, control and program data plane state from a
central entity
l  An architecture to control not just a networking
device but an entire network
23 SDN
Network OS
Network OS: distributed system that creates a

consistent, up-to-date network view
–  Runs on servers (controllers) in the network
–  Floodlight, POX, Ryu, ONOS, Beacon, … + more
–  Input: global network view (graph/database)
–  Output: configura.on of each network device
–  Get state informa.on from forwarding elements

–  Give control direc.ves to forwarding elements

24 SDN
Network OS
Network OS: distributed system that creates a

consistent, up-to-date network view
–  Runs on servers (controllers) in the network
–  Floodlight, POX, Ryu, ONOS, Beacon, … + more
–  Input: global network view (graph/database)
–  Output: configura.on of each network device
–  Get state informa.on from forwarding elements

–  Give control direc.ves to forwarding elements

24 SDN
So#ware Defined Networks Architecture
25 SDN
25 SDN
l  Write a simple program to configure a simple
model
–  Configuration merely a way to specify what you want
l  Examples
–  ACLs: who can talk to who
–  Isolation: who can hear my broadcasts
–  Routing: only specify routing to the degree you care
–  QoS: specify in terms of quality of service, not routes
l  Controller “compiles” these requirements
–  Produces suitable configuration of actual network
devices
l  Controller then transmits these settings to physical
boxes
26 SDN

l  Write a simple program to configure a simple
model
–  Configuration merely a way to specify what you want
l  Examples
–  ACLs: who can talk to who
–  Isolation: who can hear my broadcasts
–  Routing: only specify routing to the degree you care
–  QoS: specify in terms of quality of service, not routes
l  Controller “compiles” these requirements
–  Produces suitable configuration of actual network
devices
l  Controller then transmits these settings to physical
boxes
26 SDN
Northbound API
l  The northbound API interface enables applications
and the overall management system to program
the network and request services from it
l  No standards have been ratified for northbound
APIs, with several open and proprietary protocols
being developed using different northbound APIs.
–  REST
–  RESTfu l
–  RESTConf
27 SDN
Northbound API
l  The northbound API interface enables applications
and the overall management system to program
the network and request services from it
l  No standards have been ratified for northbound
APIs, with several open and proprietary protocols
being developed using different northbound APIs.
–  REST
–  RESTfu l
–  RESTConf
27 SDN
RESTful APIs
RESTful API is an
application program interface
(API) that uses HTTP requests
to GET, PUT, POST and
DELETE data.
Data returned in a format such

as JSON or XML.
RESTful APIs
RESTful API is an
application program interface
(API) that uses HTTP requests
to GET, PUT, POST and
DELETE data.
Data returned in a format such

as JSON or XML.
Data Formats
Data Formats
Southbound API
l  The southbound API defines the programming
interface between the controller and the
network switches
–  SNMP
–  BGP
–  Netconf
–  Openflow
l  OpenFlow is one of the most widely accepted
standard for the Southbound API
30 SDN
Southbound API
l  The southbound API defines the programming
interface between the controller and the
network switches
–  SNMP
–  BGP
–  Netconf
–  Openflow
l  OpenFlow is one of the most widely accepted
standard for the Southbound API
30 SDN
SDN vs Conventional network
SDN Conventional
Controller may not be in the Forwarding hardware and
same box as the forwarding its control are in the same
hardware box
Centralized routing Distributed routing algorithm
algorithm with logically
global view
Network functions are Network functions must be
realized with a global view realized in a distributed
manner, subject to error
31 SDN
SDN vs Conventional network
SDN Conventional
Controller may not be in the Forwarding hardware and
same box as the forwarding its control are in the same
hardware box
Centralized routing Distributed routing algorithm
algorithm with logically
global view
Network functions are Network functions must be
realized with a global view realized in a distributed
manner, subject to error
31 SDN
Open Networking FoundaDon
l  Open Networking Founda.on (ONF)

–  New non-profit standards organiza.on (Mar 2011)
–  Defining standards for SDN, star.ng with OpenFlow
–  Board of Directors
l  Google, Facebook, Microso>, Yahoo, DT, Verizon
–  39 Member Companies
l  Cisco, VMware, IBM, Juniper, HP, Broadcom, Citrix, NTT,
Intel, Ericsson, Dell, Huawei, …
32 SDN
l  Open Networking Founda.on (ONF)

–  New non-profit standards organiza.on (Mar 2011)
–  Defining standards for SDN, star.ng with OpenFlow
–  Board of Directors
l  Google, Facebook, Microso>, Yahoo, DT, Verizon
–  39 Member Companies
l  Cisco, VMware, IBM, Juniper, HP, Broadcom, Citrix, NTT,
Intel, Ericsson, Dell, Huawei, …
32 SDN
33 SDN
33 SDN
How SDN changing Industry?
Data Center
Cost Control
200,000 servers
Fanout of 20 è 10,000 switches More flexible control
$5k vendor switch = $50M Adapt network for services
$1k commodity switch = $10M Quickly improve and innovate

Savings in 10 data centers = $400M

34 SDN
Data Center
Cost Control
200,000 servers
Fanout of 20 è 10,000 switches More flexible control
$5k vendor switch = $50M Adapt network for services
$1k commodity switch = $10M Quickly improve and innovate

Savings in 10 data centers = $400M

34 SDN
SDN is used by the biggest companies
–  Google B4: deployed SDN to manage cross data center
traffic
–  Microsoft SWAN: software defined WAN
–  Facebook: infrastructure exploring SDN
–  Vmware: Nicira, overlay approach to SDN
–  Intel: OpenFlow switch
–  Cisco: OpenFlow switch
–  …
35 SDN

SDN is used by the biggest companies
–  Google B4: deployed SDN to manage cross data center
traffic
–  Microsoft SWAN: software defined WAN
–  Facebook: infrastructure exploring SDN
–  Vmware: Nicira, overlay approach to SDN
–  Intel: OpenFlow switch
–  Cisco: OpenFlow switch
–  …
35 SDN
Startups
–  Big Switch Networks: OpenFlow-based SDN switches, controllers and
monitoring tools
–  Embrane: layer 3-7 SDN services to enterprises and service providers.
April 13, 2015 – Cisco annonced that has acquired Embrane
–  Accelera: software defined wireless networks funded by Stanford
Professor Andrea Goldsmith
–  Nicira: was founded in 2007 by Martin Casado, Nick McKeown and
Scott Shenker that their mission is to virtualize the network. On July 23,
2012, VMware announced they intended to acquire Nicira for $1.26
billion
–  Nov 6, 2013: Cisco buys Insieme for $838M
–  Viptela provides Software-Defined Wide Area Network (SD-WAN)
technology that allows global companies to build cost-effective WANs.
August 2017 – Cisco announced that it has completed the acquisition of
Viptela for 610M$
–  Augest 1, 2017: Cisco buys Viptela for $610M
36 SDN

Startups
–  Big Switch Networks: OpenFlow-based SDN switches, controllers and
monitoring tools
–  Embrane: layer 3-7 SDN services to enterprises and service providers.
April 13, 2015 – Cisco annonced that has acquired Embrane
–  Accelera: software defined wireless networks funded by Stanford
Professor Andrea Goldsmith
–  Nicira: was founded in 2007 by Martin Casado, Nick McKeown and
Scott Shenker that their mission is to virtualize the network. On July 23,
2012, VMware announced they intended to acquire Nicira for $1.26
billion
–  Nov 6, 2013: Cisco buys Insieme for $838M
–  Viptela provides Software-Defined Wide Area Network (SD-WAN)
technology that allows global companies to build cost-effective WANs.
August 2017 – Cisco announced that it has completed the acquisition of
Viptela for 610M$
–  Augest 1, 2017: Cisco buys Viptela for $610M
36 SDN
How SDN changing Research?
Ease of trying new ideas

–  Exis.ng tools: NOX, Beacon, switches, Mininet
–  More rapid technology transfer
–  GENI, OFELIA and many more
A stronger founda.on to build

–  Provable proper.es of forwarding
–  New languages and specifica.on tools
37 SDN
Ease of trying new ideas

–  Exis.ng tools: NOX, Beacon, switches, Mininet
–  More rapid technology transfer
–  GENI, OFELIA and many more
A stronger founda.on to build

–  Provable proper.es of forwarding
–  New languages and specifica.on tools
37 SDN
l  Research activities
–  Open Networking Summit started in 2011
–  ACM HotSDN workshop started in 2012
–  The Symposium on SDN Research (SOSR)
–  ONF Connect
38 SDN

l  Research activities
–  Open Networking Summit started in 2011
–  ACM HotSDN workshop started in 2012
–  The Symposium on SDN Research (SOSR)
–  ONF Connect
38 SDN
Market Report
SDN Market
SDN and NFV Market Size Report 2015
NETWORK MARKET TAM

$140
$120
$100
Revenue Value ($ Billions)
$80
Source: SDxCentral report,

$60 2015
$40
$20
$0
2015 2016 2017 2018 2019 2020
Optical Network (L2/L3) Network Functions (L4-7) NMS
Total addressable market (TAM), also called total available market, is a term that is
typically used to reference the revenue opportunity available for a product or service.
39 The base numbers are derived in part from publicly available data on market sizes and estimated market growth. SDN
Where there were multiple sources, data was blended using additional market research conducted by SDxCentral’s
researcher. Where there was incomplete or no data available, SDxCentral research filled the gaps.
Market Report
Forecasting the SDN and NFV Markets
SDN Market
The objective of forecasting the size of the SDxN market is to estimate the amount of network spend that will be
directly influenced by these new technologies. To put it simply, the goal is to ascertain when SDN, NFV, network
virtualization or white/gray/brite boxes are a meaningful part of the selection/decision criterion (either for immediate
or for future deployment). This forecasting is not intended to predict the rate of SDxN deployments in production
NETWORK MARKET TAM
environments, though it is a reasonable follow-on conclusion that these technologies will become a part of virtualized
network$140
deployment plans in the future.
And therefore for our marketing sizing methodology, because we model the SDN and NFV impact through purchase
criterion, our estimates will trend higher than actual SDN and NFV deployments.
$120
Regardless, we have seen that customers are considering how any networking solution they procure today will operate
in an SDxN environment over the life of that equipment. In the case of software, buyers are examining the committed
roadmaps$100
and extensibility of solutions to ensure they can integrate with future virtualized environments.
$80
© 2015 SDNCentral. All Rights Reserved. Page 2
Source: SDxCentral report,

$60 2015
$40
$20
$0
2015 2016 2017 2018 2019 2020
Total addressable market (TAM), also called total available market, is a term that is
typically used to reference the revenue opportunity available for a product or service.
39 The base numbers are derived in part from publicly available data on market sizes and estimated market growth. SDN
Where there were multiple sources, data was blended using additional market research conducted by SDxCentral’s
researcher. Where there was incomplete or no data available, SDxCentral research filled the gaps.
SDN Market
This overall networking TAM was determined by looking at the following
constituent elements:
l  Optical (MSPP/SDH, Optical Switch/OXC/NG Core Switch, WDM including
POTP, MWDM, LHDWDM)
l  Wireline (FTTx access, copper line access, CMTS access, DSL modem &
home gateways), cable CPE)
l  Core (IP core routers)
l  Edge Aggregation (IP edge routers, carrier edge Ethernet)
l  Wireless Access (3G & LTE small cells, CSP hot spots)
l  Enterprise (traditional routing, Ethernet switching, WLAN)
l  Network Functions (Firewall/VPN, IDS/IPS, integrated threat management,
network access control, SSL VPN gateway, security information event
management, specialized threat analysis & protection, data leak prevention,
content security gateways, WAN Optimization Controllers, Application Delivery
Controllers, SP deep packet inspection, mobile packet core, transparent
caching, DDI, Sessions Border Controllers)
l  NMS (Network Management Systems – primarily made up of policy elements)
40 SDN
SDN Market
This overall networking TAM was determined by looking at the following
constituent elements:
l  Optical (MSPP/SDH, Optical Switch/OXC/NG Core Switch, WDM including
POTP, MWDM, LHDWDM)
l  Wireline (FTTx access, copper line access, CMTS access, DSL modem &
home gateways), cable CPE)
l  Core (IP core routers)
l  Edge Aggregation (IP edge routers, carrier edge Ethernet)
l  Wireless Access (3G & LTE small cells, CSP hot spots)
l  Enterprise (traditional routing, Ethernet switching, WLAN)
l  Network Functions (Firewall/VPN, IDS/IPS, integrated threat management,
network access control, SSL VPN gateway, security information event
management, specialized threat analysis & protection, data leak prevention,
content security gateways, WAN Optimization Controllers, Application Delivery
Controllers, SP deep packet inspection, mobile packet core, transparent
caching, DDI, Sessions Border Controllers)
l  NMS (Network Management Systems – primarily made up of policy elements)
40 SDN
Market Report
Quantifying the SDN and NFV Impact

SDN Market Assuming that SDxN spending is largely substitutive for that of existing networking solutions, the general networking
TAM provides the overall market from which SDxN will pull. As we’ve discussed before, the server virtualization market
provides a timeframe in which the SDxN market is likely to emerge.
SDX NETWORKING MARKET FORECAST

BY PRODUCT CATEGORY
$120
$15B in 2015 to
$100
nearly $105B by
2020
$80
$60
$40
$20
$0
2015 2016 2017 2018 2019 2020
Our model shows potential SDxN revenues growing from less than $15B in 2015 to nearly $105B by 2020. This growth
41 Source:by
is driven primarily SDxCentral report,
the network (L2/3)2015 SDN
and network functions (L4/7) categories. The L2/3 contribution is expected
Market
to exceedReport
$10B in 2015 and grow to more than $105B by 2020, while the network functions layer will grow from under
SDN andto NFV
$5B in 2015 $32B byMarket
2020. TheSize
SDxN Report 2015 to have a CAGR of 44% over the 5 years from 2015 to
market is projected
2020, eight times the growth rate of the broader TAM. The portion of network purchases influenced by virtualization
is anticipated to increase from 16% in 2015 to almost 80% by 2020.
Quantifying the SDN and NFV Impact

SDN Market Assuming that SDxN spending is largely substitutive for that of existing networking solutions, the general networking
TAM provides the overall market from which SDxN will pull. As we’ve discussed before, the server virtualization market
provides a timeframe in which the SDxN market is likely to emerge.
SDX NETWORKING MARKET FORECAST

BY PRODUCT CATEGORY
$120
$15B in 2015 to
$100
nearly $105B by© 2015 SDNCentral. All Rights Reserved.
Page 7
2020
$80
$60
$40
$20
$0
2015 2016 2017 2018 2019 2020
Our model shows potential SDxN revenues growing from less than $15B in 2015 to nearly $105B by 2020. This growth
41 Source:by
is driven primarily SDxCentral report,
the network 2015
(L2/3) SDN
and network functions (L4/7) categories. The L2/3 contribution is expected
to exceed $10B in 2015 and grow to more than $105B by 2020, while the network functions layer will grow from under
$5B in 2015 to $32B by 2020. The SDxN market is projected to have a CAGR of 44% over the 5 years from 2015 to
2020, eight times the growth rate of the broader TAM. The portion of network purchases influenced by virtualization
Market Report
SDN
SDN and Market
NFV Market Size Report 2015
PORTION OF NETWORK PURCHASES INFLUENCED BY SDX NETWORKING
100%
90%
80%
70%
60%
Percent of TAM
50%
40%
30%
20%
20%
10%
0%
2015 2016 2017 2018 2019 2020
SDx Networks Traditional Networks
42 Source: SDxCentral report, 2015 SDN

In addition, a major portion of L2/L3 spend will migrate from HW spend to a new suite of software-only networking
applications. We estimate that by 2020, the market for just L2-3 networking SW apps will be $14B. These will appear
as applications running on controllers or integrated into provisioning or orchestration systems, or in some situations
run partially as VNFs on NFV infrastructure (e.g. virtual route reflectors).
Market Report
SDN
SDN and Market
NFV Market Size Report 2015
PORTION OF NETWORK PURCHASES INFLUENCED BY SDX NETWORKING
100%
90% ENJOYING THE INSIGHTS OF THE REPORT

SO FAR? CLICK TO SHARE WITH OTHERS!
80%
70%
60%
Percent of TAM
50%
40%
30%
20%
20%
10%
0%
2015 2016 2017 2018 2019 2020
SDx Networks Traditional Networks

In addition, a major portion of L2/L3 spend will migrate from HW spend to a new suite of software-only networking
applications. We estimate that by 2020, the market for just L2-3 networking SW apps will be $14B. These will appear
as applications running on controllers or integrated into provisioning or orchestration systems, or in some situations
SDN Market
43 SDN
SDN Market
43 SDN
SDN Market
44 SDN
SDN Market
44 SDN
SDN Market
45 SDN
SDN Market
45 SDN
Market Report
SDN Market
SHIFT FROM TRADITIONAL L2-3 HARDWARE TO SOFTWARE

14000
12000
10000
Revenue Value ($ Millions)
8000
6000
4000
2000
$0
2015 2016 2017 2018 2019 2020
L2-3 Networking SW Apps

Mapping Impact to Customer Segments
Having quantified the impact of SDN and NFV, we will next take two different views into this market forecast. We’ll
start by mapping the product categories we described at the beginning of this report to what is used in each of the
following customer segments and sub segments:
Market Report
• Enterprise
SDN Market
SDN• Global
and NFV500 Market Size Report 2015
• Very Large (>10000 employees)
• Large (>1000 employees)
• Medium (>100 employees)
SHIFT FROM TRADITIONAL L2-3 HARDWARE TO SOFTWARE
• Small (<100 employees)
14000
• Public Sector
• Telco
•12000
Wireline
• Wireless
• Managed Service Provider
10000
Revenue Value ($ Millions)
8000
6000
4000
2000
$0
2015 2016 2017 2018 2019 2020
L2-3 Networking SW Apps

Mapping Impact to Customer Segments
Having quantified the impact of SDN and NFV, we will next take two different views into this market forecast. We’ll
start by mapping the product categories we described at the beginning of this report to what is used in each of the
47 SDN
47 SDN
SDxCentral: 2017 Open Source Networking Report
HAVE YOU DEPLOYED ANY TYPE OF OPEN SOURCE

NETWORKING SOLUTION?
48 SDN
HAVE YOU DEPLOYED ANY TYPE OF OPEN SOURCE

NETWORKING SOLUTION?
48 SDN
When probed on all the places they are deploying or plan to deploy open source solutions, the majority (64%)
said in a private cloud. 40% said they were using or going to use open source in their mobile and WAN
networks, while 38% said they are integrating or are looking to integrate open-source networking solutions in
their public cloud environments.
IN WHAT ENVIRONMENT HAVE YOU OR ARE YOU PLANNING TO

IN WHAT ENVIRONMENT HAVE YOU OR ARE YOU PLANNING TO IMPLEMENT OPEN
IMPLEMENT OPEN SOURCE
SOURCE NETWORKING NETWORKING SOLUTIONS?
SOLUTIONS?
Private Cloud 64%
WAN 40%
Mobile Networks 40%
Public Cloud 38%
Campus 19%
In Building Products to Sell 14%

(OEM, ODM, Technology Vendors)
In Building Services to Sell

10%
(SIs, MSPs, etc.)
No Plans to Deploy 7%
Other 5%
0 10 30 50 70
INDUSTRY REPORT | 2017 Open Source in Networking
49 market summary SDN
sdxcentral.com
When probed on all the places they are deploying or plan to deploy open source solutions, the majority (64%)
said in a private cloud. 40% said they were using or going to use open source in their mobile and WAN
networks, while 38% said they are integrating or are looking to integrate open-source networking solutions in
their public cloud environments.
IN WHAT ENVIRONMENT HAVE YOU OR ARE YOU PLANNING TO

IN WHAT ENVIRONMENT HAVE YOU OR ARE YOU PLANNING TO IMPLEMENT OPEN
IMPLEMENT OPEN SOURCE
SOURCE NETWORKING NETWORKING SOLUTIONS?
SOLUTIONS?
Private Cloud 64%
WAN 40%
Mobile Networks 40%
© 2017 SDNCentral LLC. All Rights

Public Cloud Reserved. 38% Page 31
Campus 19%
In Building Products to Sell 14%

(OEM, ODM, Technology Vendors)
In Building Services to Sell

10%
(SIs, MSPs, etc.)
No Plans to Deploy 7%
Other 5%
0 10 30 50 70
49 SDN
sdxcentral.com
market summary
The most popular open-source networking solutions being deployed or considered are OpenStack solutions
SDxCentral: 2017
(55%), OpenvSwitch (55%), Open
OpenDaylight Source
(38%), DPDK Networking
(36%), ONAP Report
(29%) and OpenSwitch (29%).
WHICH
WHICHOF THE
OF THE FOLLOWING
FOLLOWING POPULAR
POPULAR OPEN OPEN SOURCE
SOURCE NETWORKING NETWORKING
SOLUTIONS HAVE YOU
SOLUTIONS HAVE YOU DEPLOYED/ARE YOU CONSIDERING?
DEPLOYED/ARE YOU CONSIDERING?
NFV Solutions 67%
SDN Networking 57%
Openstack Networking (Neutron) 55%
OpenvSwitch 55%
OpenDaylight 38%
DPDK 36%
ONAP 29%
OpenSwitch 29%
ONOS 21%
CORD 19%
FD.io 12%
Free-Range Routing/Quagga 12%
Other 12%
Ryu 10%
OSM 10%
ONIE 10%
Project Calico 7%
OpenDataPlane 5%
50 SDN
0
INDUSTRY REPORT | 2017 Open Source in Networking 10 30 50 70
market summary
sdxcentral.com
SDxCentral: 2017
(55%), OpenvSwitch (55%), Open
OpenDaylight Source
(38%), DPDK Networking
(36%), ONAP Report
(29%) and OpenSwitch (29%).
WHICH
WHICHOF THE
OF THE FOLLOWING
FOLLOWING POPULAR
SOLUTIONS HAVE YOU
NFV Solutions 67%
SDN Networking 57%
© 2017 SDNCentral LLC. All Rights Reserved.

OpenvSwitch 55% Page 32
OpenDaylight 38%
DPDK 36%
ONAP 29%
OpenSwitch 29%
ONOS 21%
CORD 19%
FD.io 12%
Other 12%
Ryu 10%
OSM 10%
ONIE 10%
Project Calico 7%
OpenDataPlane 5%
50 SDN
0 10 30 50 70
Vendor and System Integrator Implementations
The survey asked technology vendors and system integrators (SIs) if they had incorporated any open-sour
networking projects into their products or solutions. 80% said “yes,” while 13% said they were currently test
qualifying open source solutions. The 7% who haven’t incorporated open source are researching solutions,
plans to implement in the next year.
HAVE YOU INCORPORATED ANY OPEN SOURCE NETWORKING

PROJECTS
HAVEINTO YOUR PRODUCTS
YOU INCORPORATED ANY OPENOR SOLUTIONS?
SOURCE NETWORKING
PROJECTS INTO YOUR PRODUCTS OR SOLUTIONS?
No, But Interested
7%
No, But
Testing
13%
Yes
80%
sdxcentral.com
51 market summary
66% of the survey vendor/SI participants have deployed or are planning on deploying OpenStack
SDN
solutions
networking projects (Neutron), 56% are deploying general SDN networking solutions (including controllers
while 54% are deploying network function virtualization solutions. The specific solutions include mentioned
most were OpenDaylight, at 50%, OpenvSwitch, at 47%, and DPDK, at 46%.
Vendor and System Integrator Implementations
Drivers for Open Source in Networking
The survey asked technology vendors and system integrators (SIs) if they had incorporated any open-sour
networking projects into their products said
or solutions.
they are 80%
usingsaid “yes,” while 13%using
said open-source
they were currently test
The main reason
qualifyingisopen
solutions
end-user
source
to reduce costs
respondents
solutions.
(71%).The 7%
They who
felt haven’t
“saving
or thinking
incorporated
money by using open
about
sourcevalidated
a pre-built, are researching
networking
solutions,
codebase” was th
plans to business
primary implement in the
driver. Ofnext year.
those end-users who have already deployed open source solutions, 32% said th
were seeing 25% – 50% savings over commercial solutions. A quarter of the respondents saw 25% savings,
HAVEanother
YOUquarter
INCORPORATED ANY
said they really didn’t seeOPEN SOURCE
a difference NETWORKING
in total costs between open source and commercial
PROJECTSHAVEINTO
solutions. YOUR PRODUCTS
YOU INCORPORATED ANY OPENOR SOLUTIONS?
SOURCE NETWORKING
PROJECTS INTO YOUR PRODUCTS OR SOLUTIONS?
Other important reasons to adopt open source solutions, according to respondents, who could check all th
No, Butvendor/product
answers they felt applied, were to “prevent Interested lock-in,” at 69%, ensure “interoperability with a
7%
common source-base,” at 60%, “velocity – accelerating time to market” at 57%, “reliability,” at 45%, and “fe
richness,” at 33%. Interestingly, 33% also noted there was a compelling community effect associated with u
open-source networking – participating in the open-source ecosystem can have recruiting and marketing
benefits.
No, But
Testing
13%
Yes
80%
sdxcentral.com
51 66% of the survey vendor/SI participants have deployed or are planning on deploying OpenStackSDN
solutions
networking projects (Neutron), 56% are deploying general SDN networking solutions (including controllers
while 54% are deploying network function virtualization solutions. The specific solutions include mentioned
most were OpenDaylight, at 50%, OpenvSwitch, at 47%, and DPDK, at 46%.
market summary
WHAT ARE
WHAT ARE THE THE MOST IMPORTANT
MOST IMPORTANT BUSINESS
BUSINESS DRIVERS DRIVERS
FOR OPEN SOURCE
NETWORKING?
FOR OPEN SOURCE NETWORKING?
Reducing Costs 71%
Prevent Lock-In 69%
Interoperability 60%
Accelerating Time-to-Market 57%
Increased Reliability 45%
Feature Richness 33%
Supporting Open Source 31%
No Advantage 2%
52 Other 2%
SDN
0 15 30 45 60 75

sdxcentral.com
market summary
Technology vendors and system integrator respondents had a slightly different take on what they saw as the
most important business drivers for using open source in their solutions. They indicated ensuring
WHAT ARE THE MOST IMPORTANT BUSINESS DRIVERS
WHAT AREwith
“interoperability THE MOST
other IMPORTANT
systems” BUSINESS
was the primary DRIVERS
driver, FOR OPEN
at 65%, followed SOURCEdeployment costs” at
by “reducing
63%,NETWORKING?
and “velocity - accelerating time-to-market,” at 62%. Interestingly, there is a marketing value for vendors/
FOR OPEN SOURCE NETWORKING?
SIs too – 43% felt that the “open-source ecosystem makes customers feel more comfortable and helps project
‘open’ image.”
When probed onReducing Costs

the cost savings vendors/SIs who have deployed open source solutions71%
are seeing, 31%
indicated it was between 25% and 50%. Another 31% noted it was less than 25%, and 23% found the costs were
similar between open source solutions and the solutions they are developing in-house.
Prevent Lock-In 69%
© 2017 SDNCentral LLC. All Rights Reserved. Page 34
Accelerating Time-to-Market 57%
Increased Reliability 45%
Feature Richness 33%
Supporting Open Source 31%
No Advantage 2%
52 Other 2%
SDN
0 15 30 45 60 75
Barriers to Using Open Source
End-user participants were asked what they saw as the biggest challenges associated with adopting
open-source networking solutions. 52% responded that “lack of in-house talent” was their biggest hurdle, while
“lack of enterprise level support – no support” topped the list for 29% and “interoperability concerns with
existing infrastructure” for 21%.
WHAT DO YOU
WHAT SEE
DO YOU AS
SEE AS THE 2 MOST
THE 2 MOST CHALLENGING
CHALLENGING BARRIERS
BARRIERS TO OPEN SOURCE?
TO OPEN SOURCE?
Lack of In-House Talent 52%
No Support 29%
Immaturity of Code 24%
Security Concerns 19%
Too Many Choices 14%
Lack of Performance 14%
No Roadmap 10%
Other 10%
53 market summary
Not Qualified 7% SDN
0 10 20 30 40 50 60
Barriers to Using Open Source
End-user participants were asked what they saw as the biggest challenges associated with adopting
open-source networking solutions. 52% responded that “lack of in-house talent” was theirsdxcentral.com
biggest hurdle, while
“lack of enterprise level support – no support” topped the list for 29% and “interoperability concerns with
existing infrastructure” for 21%.
WHAT DO YOU
WHAT SEE
DO YOU AS
SEE AS THE 2 MOST
THE 2 MOST CHALLENGING
CHALLENGING BARRIERS
BARRIERS TO OPEN SOURCE?
TO OPEN SOURCE?
© 2017 SDNCentral LLC. All Rights Reserved. Page 35
Lack of In-House Talent 52%
No Support 29%
Immaturity of Code 24%
Security Concerns 19%
Too Many Choices 14%
Lack of Performance 14%
No Roadmap 10%
Other 10%
53 Not Qualified 7% SDN
0 10 20 30 40 50 60
OCP
https://www.opencompute.org/
https://www.opencompute.org/wiki/Networking/SpecsAndDesigns
54 SDN
OCP
https://www.opencompute.org/
https://www.opencompute.org/wiki/Networking/SpecsAndDesigns
54 SDN
OPENFLOW
55 SDN
OPENFLOW
55 SDN
What is OpenFlow
l  OpenFlow
–  is a protocol for remotely controlling the
forwarding table of a switch or router
–  is one element of SDN
56 SDN
What is OpenFlow
l  OpenFlow
–  is a protocol for remotely controlling the
forwarding table of a switch or router
–  is one element of SDN
56 SDN
What is OpenFlow
l  OpenFlow is similar to an x86 instruction set for the network
l  Provide open interface to “black box” networking node
–  (ie. Routers, L2/L3 switch) to enable visibility and openness in
network
l  Separation of control plane and data plane.
–  The datapath of an OpenFlow Switch consists of a Flow Table, and
an action associated with each flow entry
–  The control path consists of a controller which programs the flow entry
in the flow table
l  OpenFlow is based on an Ethernet switch, with an internal flow-
table, and a standardized interface to add and remove flow
entries
l  Openflow defines the standard interface to add and remove
flow entries in the table
57 SDN
What is OpenFlow
l  OpenFlow is similar to an x86 instruction set for the network
l  Provide open interface to “black box” networking node
–  (ie. Routers, L2/L3 switch) to enable visibility and openness in
network
l  Separation of control plane and data plane.
–  The datapath of an OpenFlow Switch consists of a Flow Table, and
an action associated with each flow entry
–  The control path consists of a controller which programs the flow entry
in the flow table
l  OpenFlow is based on an Ethernet switch, with an internal flow-
table, and a standardized interface to add and remove flow
entries
l  Openflow defines the standard interface to add and remove
flow entries in the table
57 SDN
What is OpenFlow
l  An Openflow switch (Ethernet switch) has an
internal flow table.
–  If a packet matches an entry in the flow table,
perform the actions (e.g. forward to port 10)
according to the flow table.
–  If a packet does not match any entry in the flow
table. Send it to the Openflow controller
l  The controller will figure out what to do with such packet
l  The controller will then respond to the switch, informing how
to handle such a packet so that the switch would know how
to deal with such packets next time.
l  For each flow, ideally the controller will be queried once.
58 SDN
What is OpenFlow
l  An Openflow switch (Ethernet switch) has an
internal flow table.
–  If a packet matches an entry in the flow table,
perform the actions (e.g. forward to port 10)
according to the flow table.
–  If a packet does not match any entry in the flow
table. Send it to the Openflow controller
l  The controller will figure out what to do with such packet
l  The controller will then respond to the switch, informing how
to handle such a packet so that the switch would know how
to deal with such packets next time.
l  For each flow, ideally the controller will be queried once.
58 SDN
Controller: Programmability
Controller Application
Network OS
events from switches commands to switches

topology changes, (un)install rules,
traffic statistics, query statistics,
arriving packets send packets
59 SDN
Controller: Programmability
Controller Application
Network OS
events from switches commands to switches

topology changes, (un)install rules,
traffic statistics, query statistics,
arriving packets send packets
59 SDN
OpenFlow Basics
Control Program A Control Program B
Network OS
“If header = p, send to port 4”
Packet OpenFlow “If header = q, overwrite header with r,
Forwarding and send to ports 5,6”
Protocol
“If header = ?, send to me”
Flow
Packet Table(s)
Forwarding Packet
Forwarding

60 SDN
OpenFlow Basics
Control Program A Control Program B
Network OS
“If header = p, send to port 4”
Packet OpenFlow “If header = q, overwrite header with r,
Forwarding and send to ports 5,6”
Protocol
“If header = ?, send to me”
Flow
Packet Table(s)
Forwarding Packet
Forwarding

60 SDN
OpenFlow Usage
Controller
OpenFlow
program
Install rule;
Default: forward
forward
to controller
packet
Host A Host B
Packet
Switch 1 Switch 2
Flow Table
Rule 1
Rule 2
Match Actions Counters
Dst: Host B Fwd: Switch 2 pkts / bytes
Rule N
61 SDN
OpenFlow Usage
Controller
OpenFlow
program
Install rule;
Default: forward
forward
to controller
packet
Host A Host B
Packet
Switch 1 Switch 2
Flow Table
Rule 1
Rule 2
Match Actions Counters
Dst: Host B Fwd: Switch 2 pkts / bytes
Rule N
61 SDN
OpenFlow Usage
Controller
Processing
PC
OpenFlow
Rule Switch
Action Statistics
Install rule
Default: forward
to controller
OpenFlow OpenFlow
Rule Action Statistics Rule Action Statistics
Switch Switch
62 SDN
OpenFlowSwitch.org
OpenFlow Usage
Controller
Processing
PC
OpenFlow
Rule Switch
Action Statistics
Install rule
Default: forward
to controller
OpenFlow OpenFlow
Rule Action Statistics Rule Action Statistics
Switch Switch
62 SDN
OpenFlowSwitch.org
History of OpenFlow
l  2006: Martin Casado, a PhD student at Stanford propose a
clean-slate security architecture (SANE) which defines a
centralized control of security. Ethane generalizes it to all access
policies.
l  2007: Martin Casado co-founds Nicira
l  2008, Nicira Networks released NOX platform.
l  April 2008: OpenFlow paper in ACM SIGCOMM CCR
l  2009: Stanford publishes OpenFlow V1.0.0 specs
l  March 2011: Open Networking Foundation is formed
l  Oct 2011: First Open Networking Summit.
l  2012 ONF released OpenFlow 1.3
l  Dec. 19th, 2014, ONF released OpenFlow 1.5
l  April 2015: The current version of OpenFlow is 1.5.1.
l  September 2016: version 1.6 has been available but accessible
63 only to ONF's members. SDN
History of OpenFlow
l  2006: Martin Casado, a PhD student at Stanford propose a
clean-slate security architecture (SANE) which defines a
centralized control of security. Ethane generalizes it to all access
policies.
l  2007: Martin Casado co-founds Nicira
l  2008, Nicira Networks released NOX platform.
l  April 2008: OpenFlow paper in ACM SIGCOMM CCR
l  2009: Stanford publishes OpenFlow V1.0.0 specs
l  March 2011: Open Networking Foundation is formed
l  Oct 2011: First Open Networking Summit.
l  Dec. 19th, 2014, ONF released OpenFlow 1.5
l  April 2015: The current version of OpenFlow is 1.5.1.
l  September 2016: version 1.6 has been available but accessible
63 only to ONF's members. SDN
Components of OpenFlow Network
l  Controller
–  OpenFlow protocol
messages
–  Controlled channel
–  Processing
l  Packet Matching
l  Instructions & Action Set
l  OpenFlow switch
–  Secure Channel (SC)
–  Flow Table
l  Flow entry
64 SDN
Components of OpenFlow Network
l  Controller
messages
–  Controlled channel
–  Processing
l  Packet Matching
l  Instructions & Action Set
l  OpenFlow switch
–  Secure Channel (SC)
–  Flow Table
l  Flow entry
64 SDN
Secure Channel (SC)
l  SC is the interface that connects each OpenFlow switch to

controller
l  A controller configures and manages the switch via this
interface.
–  Receives events from the switch
–  Send packets out the switch
l  SC establishes and terminates the connection between
OpenFlow Switch and the controller using the procedures
–  Connection Setup
–  Connection Interrupt
l  The SC connection is a TLS connection. Switch and
controller mutually authenticate by exchanging certificates
signed by a site-specific private key.
65 SDN
Secure Channel (SC)
l  SC is the interface that connects each OpenFlow switch to

controller
l  A controller configures and manages the switch via this
interface.
–  Receives events from the switch
–  Send packets out the switch
l  SC establishes and terminates the connection between
OpenFlow Switch and the controller using the procedures
–  Connection Setup
–  Connection Interrupt
l  The SC connection is a TLS connection. Switch and
controller mutually authenticate by exchanging certificates
signed by a site-specific private key.
65 SDN
Flow Table
Rule Ac.on Stats
Packet + byte counters

1.  Forward packet to zero or more ports
2.  Encapsulate and forward to controller
3.  Send to normal processing pipeline
4.  Modify Fields
5.  Any extensions you add!
Switch VLAN VLAN MAC MAC Eth IP IP IP IP L4 L4

Port ID prt src dst type Src Dst ToS Prot sport dport
+ mask what fields to match

66 SDN
Flow Table
Rule Ac.on Stats
Packet + byte counters

1.  Forward packet to zero or more ports
2.  Encapsulate and forward to controller
4.  Modify Fields
5.  Any extensions you add!
Switch VLAN VLAN MAC MAC Eth IP IP IP IP L4 L4

Port ID prt src dst type Src Dst ToS Prot sport dport
+ mask what fields to match

66 SDN
Flow Entry
l  A flow entry consists of

–  Rule
l  Match against packets
–  Action
l  Modify the action set or pipeline processing
–  Stats Rule Action Stats
l  Update the matching packets
TCP
Src Dst Eth Vlan IP TCP Dst MPLS
In Port IP Tos IP Src IP Dst Src
MAC MAC Type Id Proto Port Label
Port
Layer 2 Layer 3 Layer 4
1.  Forward packet to port(s)

2.  Encapsulate and forward to 1. Packet
controller 2. Byte counters
3.  Drop packet
67 SDN
Flow Entry
l  A flow entry consists of

–  Rule
l  Match against packets
–  Action
l  Modify the action set or pipeline processing
–  Stats Rule Action Stats
l  Update the matching packets
TCP
Src Dst Eth Vlan IP TCP Dst MPLS
In Port IP Tos IP Src IP Dst Src
MAC MAC Type Id Proto Port Label
Port
Layer 2 Layer 3 Layer 4
1.  Forward packet to port(s)

2.  Encapsulate and forward to 1. Packet
controller 2. Byte counters
3.  Drop packet
67 SDN
Flow Table
l  Flow table in switches, routers, and chipsets
Flow Entry 1. Rule

Action Statistics
(exact & wildcard)
Flow Entry 2. Rule

Action Statistics
(exact & wildcard)
Flow Entry 3. Rule

Action Statistics
(exact & wildcard)
Rule
Flow Entry N. Default Action Statistics
(exact & wildcard)
68 SDN
Flow Table
l  Flow table in switches, routers, and chipsets
Flow Entry 1. Rule

Action Statistics
(exact & wildcard)
Flow Entry 2. Rule

Action Statistics
(exact & wildcard)
Flow Entry 3. Rule

Action Statistics
(exact & wildcard)
Rule
Flow Entry N. Default Action Statistics
(exact & wildcard)
68 SDN
Examples
Switching
Switch MAC MAC Eth VLAN IP IP IP TCP TCP

Ac.on
Port src dst type ID Src Dst Prot sport dport
* * 00:1f:.. * * * * * * * port6
Flow Switching

Ac.on
port3 00:20.. 00:1f.. 0800 vlan1 1.2.3.4 5.6.7.8 4 17264 80 port8
Firewall

Ac.on
* * * * * * * * * 22 drop
69 SDN
Examples
Switching

Ac.on
* * 00:1f:.. * * * * * * * port6
Flow Switching

Ac.on
port3 00:20.. 00:1f.. 0800 vlan1 1.2.3.4 5.6.7.8 4 17264 80 port8
Firewall

Ac.on
* * * * * * * * * 22 drop
69 SDN
Examples
Rou.ng

Ac.on
* * * * * * 5.6.7.8 * * * port6
VLAN Switching

Ac.on
port7,
* * 00:1f.. * vlan1 * * * * * port8,
port9
70 SDN
Examples
Rou.ng

Ac.on
* * * * * * 5.6.7.8 * * * port6
VLAN Switching

Ac.on
port7,
* * 00:1f.. * vlan1 * * * * * port8,
port9
70 SDN
Flow Table (Openflow 1.5)
Match
Priority Counters Instruc.on Timeouts Cookie Flags
Fields
•  Match fields : To match against packets.

•  Priority : matching precedence of the flow entries.
•  Counters : updated when packets are matched.
•  Instruction : to modify the action set of pipeline processing.
•  Timeouts : maximum time of idle time before flow is expired
•  Cookie: opaque data value chosen by the controller. May be
used by the controller to filter flow entries affected by flow
statistics, flow modification and flow deletion requests. Not
used when processing packets.
•  flags: flags alter the way flow entries are managed, for
example the flag OFPFF_SEND_FLOW_REM triggers flow
removed messages for that flow entry.
71 SDN
Flow Table (Openflow 1.5)

Match
Priority Counters Instruc.on Timeouts Cookie Flags
Fields
•  Match fields : To match against packets.

•  Priority : matching precedence of the flow entries.
•  Counters : updated when packets are matched.
•  Instruction : to modify the action set of pipeline processing.
•  Timeouts : maximum time of idle time before flow is expired
•  Cookie: opaque data value chosen by the controller. May be
used by the controller to filter flow entries affected by flow
statistics, flow modification and flow deletion requests. Not
used when processing packets.
•  flags: flags alter the way flow entries are managed, for
example the flag OFPFF_SEND_FLOW_REM triggers flow
removed messages for that flow entry.
71 SDN
Centralized vs Distributed Control
Both models are possible with OpenFlow
Centralized Control Distributed Control

OpenFlow OpenFlow
Switch Switch
Controller
OpenFlow OpenFlow Controller

Switch Switch
OpenFlow OpenFlow
Switch Switch
72 SDN
Centralized vs Distributed Control

Centralized Control Distributed Control

OpenFlow OpenFlow
Switch Switch
Controller
OpenFlow OpenFlow Controller

Switch Switch
OpenFlow OpenFlow
Switch Switch
72 SDN
ReacDve vs. ProacDve (pre-populated)
Reactive Proactive
•  First packet of flow triggers •  Controller pre-populates
controller to insert flow flow table in switch
entries •  Zero additional flow setup
•  Efficient use of flow table time
•  Every flow incurs small •  Loss of control connection
additional flow setup time does not disrupt traffic
•  If control connection lost, •  Essentially requires
switch has limited utility aggregated (wildcard) rules
OpenFlow
h1 h2 p2 acquire Controller
route
insert
flow
1 2 1 2
73 host1 switch1 (reactive) switch2 (proactive) host2 SDN
ReacDve vs. ProacDve (pre-populated)

Reactive Proactive
•  First packet of flow triggers •  Controller pre-populates
controller to insert flow flow table in switch
entries •  Zero additional flow setup
•  Efficient use of flow table time
•  Every flow incurs small •  Loss of control connection
additional flow setup time does not disrupt traffic
•  If control connection lost, •  Essentially requires
switch has limited utility aggregated (wildcard) rules
OpenFlow
h1 h2 p2 acquire Controller
route
insert
flow
1 2 1 2
73 host1 switch1 (reactive) switch2 (proactive) host2 SDN

Flow RouDng vs. AggregaDon
Flow-Based Aggregated

•  Every flow is individually •  One flow entry covers
set up by controller large groups of flows
•  Exact-match flow entries •  Wildcard flow entries
•  Flow table contains one •  Flow table contains one
entry per flow entry per category of
•  Good for fine grain flows
control, e.g. campus •  Good for large number of
networks flows, e.g. backbone
74 SDN
Flow RouDng vs. AggregaDon

Flow-Based Aggregated

•  Every flow is individually •  One flow entry covers
set up by controller large groups of flows
•  Exact-match flow entries •  Wildcard flow entries
•  Flow table contains one •  Flow table contains one
entry per flow entry per category of
•  Good for fine grain flows
control, e.g. campus •  Good for large number of
networks flows, e.g. backbone
74 SDN
Openflow specifications
l  From 1.0.0 to 1.5.0
l  Briefly introduce concepts in versions 1.0.0 to

1.2.0
75 SDN
Openflow specifications
l  From 1.0.0 to 1.5.0
l  Briefly introduce concepts in versions 1.0.0 to

1.2.0
75 SDN
Openflow 1.0 concepts
l  Messaging between controller and switch
l  Actions and packet forwarding
l  Flow table
l  Packet matching
76 SDN

l  Messaging between controller and switch
l  Actions and packet forwarding
l  Flow table
l  Packet matching
76 SDN
l  Multiple flow tables
l  Groups
l  MPLS and VLAN tag support
l  Virtual ports
77 SDN

l  Multiple flow tables
l  Groups
l  MPLS and VLAN tag support
l  Virtual ports
77 SDN
1.2.0 concepts
l  IPv6
l  Multiple controller enhancements
l  Etc.
l  Later versions of Openflow specification supports

more necessary functions.
–  1.3, 1.4, 1.5, 1.6 (2016)
78 SDN
1.2.0 concepts
l  IPv6
l  Multiple controller enhancements
l  Etc.
l  Later versions of Openflow specification supports

more necessary functions.
–  1.3, 1.4, 1.5, 1.6 (2016)
78 SDN
OpenFlow Group Table
l  Group Table & Types (version 1.1) Group Table
–  All: multicast Action
Bucket
–  Select: load sharing
–  Indirect: simple indirection
–  Fast-failover: rerouting Table 0 Table 1 …… Table n
Instruction Instruction Instruction
/Action /Action /Action
Group table
Group ID Group type Counter Action buckets

Multicast Load sharing 100 all Port1 : output
Port3 : output
Port5 : output
………
Match field Counter Action Flow table

Dst IP= 224.2.3.9 Group 100
Indirection Rerouting

l  Group Table & Types (version 1.1) Group Table
–  All: multicast Action
Bucket
–  Select: load sharing
–  Indirect: simple indirection
–  Fast-failover: rerouting Table 0 Table 1 …… Table n
Instruction Instruction Instruction
/Action /Action /Action
Group table
Group ID Group type Counter Action buckets

Multicast Load sharing 100 all Port1 : output
Port3 : output
Port5 : output
………
Match field Counter Action Flow table

Dst IP= 224.2.3.9 Group 100
Indirection Rerouting
l  Multicast Group Table
Group ID Group Type Counter Action Buckets
–  Type=all
100 All 999 Port2, Port3, Port4
Flow Table
Switch MAC sr MAC dst Ether Typ VLAN I Src IP Dst IP Proto TCP S TCP D Action
Port c e D No. Port Port
* * 00:FF:.. * * * * * * * Port 6
Group
Port 1 * * 0800 * 224… 224… 4 4566 6633
100
2
1
3
4

l  Multicast Group Table
Group ID Group Type Counter Action Buckets
–  Type=all
100 All 999 Port2, Port3, Port4
Flow Table
Switch MAC sr MAC dst Ether Typ VLAN I Src IP Dst IP Proto TCP S TCP D Action
Port c e D No. Port Port
* * 00:FF:.. * * * * * * * Port 6
Group
Port 1 * * 0800 * 224… 224… 4 4566 6633
100
2
1
3
4
Table-miss flow entry
l  Specifies how to process packets unmatched by
other flow entries in the flow table
–  Example: send packets to the controller, drop packets…
l  Identified by its match and priority

–  wildcards all match fields
–  has the lowest priority (0)
l  Has a similar behaviour to other flow entries:
–  it does not exist by default in a flow table,
–  Can be add or remove by the controller at any time
–  It may expire
l  If no table-miss flow entry exists, unmatched packets
are dropped
81 SDN
Table-miss flow entry

l  Specifies how to process packets unmatched by
other flow entries in the flow table
–  Example: send packets to the controller, drop packets…
l  Identified by its match and priority

–  wildcards all match fields
–  has the lowest priority (0)
l  Has a similar behaviour to other flow entries:
–  it does not exist by default in a flow table,
–  Can be add or remove by the controller at any time
–  It may expire
l  If no table-miss flow entry exists, unmatched packets
are dropped
81 SDN
Pipeline processing (Introduced in 1.1)
l  A switch can have multiple flow tables that are

matched in a pipeline fashion.
82 SDN
Pipeline processing (Introduced in 1.1)
l  A switch can have multiple flow tables that are

matched in a pipeline fashion.
82 SDN
Per table packet processing
83 SDN
Per table packet processing
83 SDN
Pipelining processing
l  The flow tables of a switch are sequentially numbered, starting at 0
l  A packet is processed sequentially in multiple flow tables (version 1.1)
–  If a flow entry is found, the instruction set included in that flow entry is executed
–  Instructions may explicitly direct the packet to another flow table (“goto-table”)
–  Pipeline processing can only go forward and not backward
l  Two stage pipeline processing (version 1.5)
–  Ingress processing
l  Mandatory, performed before egress processing, use the rules specified in ingress
tables
–  Egress processing
l  Optional, performed in the context of output port, use the rules specified in egress
tables
l  Useful to manage complicated processing
–  E.g., table 1 for VLAN processing, table 2 for multicast group processing
Ingress processing Egress processing

Flow Flow Flow Flow
Packet In Table 0 … Table n Table e … Table e+m Packet Out
Instructio Instructio Instructio Instruction/
n/Action n/Action n/Action Action
Pipelining processing
l  The flow tables of a switch are sequentially numbered, starting at 0
l  A packet is processed sequentially in multiple flow tables (version 1.1)
–  If a flow entry is found, the instruction set included in that flow entry is executed
–  Instructions may explicitly direct the packet to another flow table (“goto-table”)
–  Pipeline processing can only go forward and not backward
l  Two stage pipeline processing (version 1.5)
–  Ingress processing
l  Mandatory, performed before egress processing, use the rules specified in ingress
tables
–  Egress processing
l  Optional, performed in the context of output port, use the rules specified in egress
tables
l  Useful to manage complicated processing
–  E.g., table 1 for VLAN processing, table 2 for multicast group processing
Ingress processing Egress processing

Flow Flow Flow Flow
Packet In Table 0 … Table n Table e … Table e+m Packet Out
Instructio Instructio Instructio Instruction/
n/Action n/Action n/Action Action
Packet Processing
Packet In
Yes
Update counters Yes
Execute instruction set:
•  Update action set Execute action set: Group
Match in Yes •  Update packet headers Goto- No •  Update packet headers action?
table n? •  Update match set fields Table n? •  Update match set fields
•  Update pipeline fields •  Update pipeline fields
No
•  As needed, clone
No packet to egress
Yes Output
Table-miss Yes action?
flow entry
exists?
Yes Switch No
No has egress
tables? Drop packet
Drop packet
No Ingress
Start egress processing: Egress

•  Action set = {output port}
•  Start at first egress table
Update counters
Execute instruction set: Yes
•  Update action set Execute action set:
Match in Yes •  Update packet headers Goto- No •  Update packet headers
No packet to egress
Table-miss Yes No Output
flow entry Drop packet
action?
exists?
No Yes
Drop packet Packet Out
Packet Processing
Packet In
Yes
Update counters Yes
Execute instruction set:
•  Update action set Execute action set: Group
Match in Yes •  Update packet headers Goto- No •  Update packet headers action?
No
No packet to egress
Yes Output
Table-miss Yes action?
flow entry
exists?
Yes Switch No
No has egress
tables? Drop packet
Drop packet
No Ingress
Start egress processing: Egress

•  Action set = {output port}
•  Start at first egress table
Update counters
Execute instruction set: Yes
•  Update action set Execute action set:
Match in Yes •  Update packet headers Goto- No •  Update packet headers
No packet to egress
Table-miss Yes No Output
flow entry Drop packet
action?
exists?
No Yes
Drop packet Packet Out
Openflow Messages
l  Controller-to-switch messages are initiated by the
controller and used to directly manage or inspect the
state of the switch
–  Features, config, modify state, read state, packet-out,
etc
l  Asynchronous messages are initiated by the switch
and used to update the controller of network events
and changes to the switch state
l  Packet-in, flow removed/expired, port status, error, etc
l  Symmetric messages are initiated by either the switch
or the controller and sent without solicitation
l  Hello, Echo, etc.
87 SDN
Openflow Messages
l  Controller-to-switch messages are initiated by the
controller and used to directly manage or inspect the
state of the switch
–  Features, config, modify state, read state, packet-out,
etc
l  Asynchronous messages are initiated by the switch
and used to update the controller of network events
and changes to the switch state
l  Packet-in, flow removed/expired, port status, error, etc
l  Symmetric messages are initiated by either the switch
or the controller and sent without solicitation
l  Hello, Echo, etc.
87 SDN
Controller-to-switch Messages
l  Features: The controller may request the capabilities
of a switch by sending a features request; the switch
must respond with a features reply that specifies the
capabilities of the switch. This is commonly
performed upon establishment of the OpenFlow
channel.
l  Configuration: The controller can set and query
configuration parameters in the switch
l  Modify-State: Modify-State messages are sent by the
controller to manage state on the switches. Their
primary purpose is to add/delete and modify flows in
the OpenFlow tables and to set switch port
properties
88 SDN
l  Features: The controller may request the capabilities
of a switch by sending a features request; the switch
must respond with a features reply that specifies the
capabilities of the switch. This is commonly
performed upon establishment of the OpenFlow
channel.
l  Configuration: The controller can set and query
configuration parameters in the switch
l  Modify-State: Modify-State messages are sent by the
controller to manage state on the switches. Their
primary purpose is to add/delete and modify flows in
the OpenFlow tables and to set switch port
properties
88 SDN
l  Read-State: Read-State messages are used by
the controller to collect statistics from the
switch.
l  Packet-out: Used by the controller to send
packets out of a specified port on the switch,
and to forward packets received via Packet-in
messages
l  Barrier: Barrier request/reply messages are used
by the controller to receive notifications for
completed operations
89 SDN
l  Read-State: Read-State messages are used by
the controller to collect statistics from the
switch.
l  Packet-out: Used by the controller to send
packets out of a specified port on the switch,
and to forward packets received via Packet-in
messages
l  Barrier: Barrier request/reply messages are used
by the controller to receive notifications for
completed operations
89 SDN
Asynchronous Messages
l  Packet-in: For all packets that do not have a matching
flow entry, a packet-in event may be sent to the controller
l  Flow-Removed: When a flow entry is added to the switch
by a flow modify message, an idle timeout value indicates
when the entry should be removed due to a lack of
activity, as well as a hard timeout value that indicates
when the entry should be removed when the flow expires,
regardless of activity.
l  Port-status: The switch is expected to send port-status
messages to the controller as port configuration state
changes (for example down/up).
l  Error: The switch is able to notify the controller of
90
problems using error messages.
SDN
Asynchronous Messages
l  Packet-in: For all packets that do not have a matching
flow entry, a packet-in event may be sent to the controller
l  Flow-Removed: When a flow entry is added to the switch
by a flow modify message, an idle timeout value indicates
when the entry should be removed due to a lack of
activity, as well as a hard timeout value that indicates
when the entry should be removed when the flow expires,
regardless of activity.
l  Port-status: The switch is expected to send port-status
messages to the controller as port configuration state
changes (for example down/up).
l  Error: The switch is able to notify the controller of
90
problems using error messages.
SDN
Symmetric Messages
l  Hello: Hello messages are exchanged between
the switch and controller upon connection
startup.
l  Echo: Echo request/reply messages can be sent
from either the switch or the controller, and must
return an echo reply.
l  Experimenter: Experimenter messages provide a
standard way for OpenFlow switches to offer
additional functionality within the OpenFlow
message type space. This is a staging area for
features meant for future OpenFlow revisions.
91 SDN
Symmetric Messages
l  Hello: Hello messages are exchanged between
the switch and controller upon connection
startup.
l  Echo: Echo request/reply messages can be sent
from either the switch or the controller, and must
return an echo reply.
l  Experimenter: Experimenter messages provide a
standard way for OpenFlow switches to offer
additional functionality within the OpenFlow
message type space. This is a staging area for
features meant for future OpenFlow revisions.
91 SDN
Openflow Messages
92 SDN
Openflow Messages
92 SDN
Openflow Messages
93 SDN
Openflow Messages
93 SDN
SDN Stack
o>race oflops
Monitoring/
openseer
debugging tools
ENVI (GUI) LAVI n-Cas.ng … Applica.ons
NOX Beacon Trema Maestro … Controller
FlowVisor Slicing
Console FlowVisor So>ware
Commercial Switches
So>ware Broadcom
NetFPGA
HP, NEC, Pronto, Ref. Switch Ref. Switch OpenFlow
Juniper.. and
many more PCEngine
Open vSwitch
Switches
OpenWRT
WiFi AP
94 94 SDN
SDN Stack
o>race oflops
Monitoring/
openseer
debugging tools
ENVI (GUI) LAVI n-Cas.ng … Applica.ons
NOX Beacon Trema Maestro … Controller
FlowVisor Slicing
Console FlowVisor So>ware
Commercial Switches
So>ware Broadcom
NetFPGA
HP, NEC, Pronto, Ref. Switch Ref. Switch OpenFlow
Juniper.. and
many more PCEngine
Open vSwitch
Switches
OpenWRT
WiFi AP
94 94 SDN
OPENFLOW SWITCHES
95 SDN
OPENFLOW SWITCHES
95 SDN
Introduction to OpenFlow Switches
l  Hardware-based OpenFlow Switches
–  Commercial hardware switches with OpenFlow capability
–  Show high processing speed
–  Have space limitation on saving the flow table entries
l  due to expensive CAM
–  Not easy to upgrade
l  Software-based OpenFlow Switches
–  OpenFlow enabled software switch (runs on x86 commodity
computer)
–  Performance is relatively low
–  Store large amount of flow entries
–  Under active development, support most recent OpenFlow spec.
l  Hybrid OpenFlow Switch
–  A virtual switch with specialized hardware device
96 –  Faster than software-based switches SDN
Introduction to OpenFlow Switches

l  Hardware-based OpenFlow Switches
–  Commercial hardware switches with OpenFlow capability
–  Show high processing speed
–  Have space limitation on saving the flow table entries
l  due to expensive CAM
–  Not easy to upgrade
l  Software-based OpenFlow Switches
–  OpenFlow enabled software switch (runs on x86 commodity
computer)
–  Performance is relatively low
–  Store large amount of flow entries
–  Under active development, support most recent OpenFlow spec.
l  Hybrid OpenFlow Switch
–  A virtual switch with specialized hardware device
96 –  Faster than software-based switches SDN
Current SDN hardware (as of ~2010)

Juniper MX-series NEC IP8800 WiMax (NEC)
HP Procurve 5400 Netgear 7324 PC Engines
Pronto 3240/3290 Ciena Coredirector
https://www.opennetworking.org/products-listing 97
97 SDN
Current SDN hardware (as of ~2010)

Juniper MX-series NEC IP8800 WiMax (NEC)
HP Procurve 5400 Netgear 7324 PC Engines
Pronto 3240/3290 Ciena Coredirector
https://www.opennetworking.org/products-listing 97
97 SDN
Hardware OpenFlow Switches
l  Arista 7050
l  Brocade MLXe, Brocade CER, Brocade CES
l  Extreme Summit x440, x460, x670
l  Huawei openflow-capable router platforms
l  HP 3500, 3500yl, 5400zl, 6200yl, 6600, and 8200zl (the old-
style L3 hardware match platform)
l  HP V2 line cards in the 5400zl and 8200zl (the newer L2
hardware match platform)
l  IBM 8264
l  Juniper (MX, EX)
l  NEC IP8800, NEC PF5240, NEC PF5820
l  NetGear 7328SO, NetGear 7352SO
l  Pronto (3290, 3295, 3780) - runs the shipping pica8 software
98 SDN
Hardware OpenFlow Switches

l  Arista 7050
l  Brocade MLXe, Brocade CER, Brocade CES
l  Extreme Summit x440, x460, x670
l  Huawei openflow-capable router platforms
l  HP 3500, 3500yl, 5400zl, 6200yl, 6600, and 8200zl (the old-
style L3 hardware match platform)
l  HP V2 line cards in the 5400zl and 8200zl (the newer L2
hardware match platform)
l  IBM 8264
l  Juniper (MX, EX)
l  NEC IP8800, NEC PF5240, NEC PF5820
l  NetGear 7328SO, NetGear 7352SO
l  Pronto (3290, 3295, 3780) - runs the shipping pica8 software
98 SDN
Software OpenFlow Switches
l  Indigo: Open source implementation that runs on
physical switches and uses features of the ASICs to run
OpenFlow
l  LINC: Open source implementation that runs on Linux, Solaris,
Windows, MacOS, and FreeBSD
l  Pantou: Turns a commercial wireless router/access point to an
OpenFlow enabled switch. Supports generic Broadcom and some
models of LinkSys and TP-Link access points with Broadcom and
Atheros chipsets.
l  Of13softswitch: User-space software switch based on Ericsson
TrafficLab 1.1 softswitch
l  XORPlus: Open source switching software to drive high-
performance ASICs. Supports STP/RSTP/MSTP, LCAP, QoS,
VLAN, LLDP, ACL, OSPF/ECMP, RIP, IGMP, IPv6, PIM-SM
l  OpenvSwitch: Open Source Virtual Switch
99 SDN
Software OpenFlow Switches

l  Indigo: Open source implementation that runs on
physical switches and uses features of the ASICs to run
OpenFlow
l  LINC: Open source implementation that runs on Linux, Solaris,
Windows, MacOS, and FreeBSD
l  Pantou: Turns a commercial wireless router/access point to an
OpenFlow enabled switch. Supports generic Broadcom and some
models of LinkSys and TP-Link access points with Broadcom and
Atheros chipsets.
l  Of13softswitch: User-space software switch based on Ericsson
TrafficLab 1.1 softswitch
l  XORPlus: Open source switching software to drive high-
performance ASICs. Supports STP/RSTP/MSTP, LCAP, QoS,
VLAN, LLDP, ACL, OSPF/ECMP, RIP, IGMP, IPv6, PIM-SM
l  OpenvSwitch: Open Source Virtual Switch
99 SDN
OPEN VSWITCH
100 SDN
OPEN VSWITCH
100 SDN
What is Open vSwitch ?
l  Open vSwitch is an open source OpenFlow
capable virtual switch that is typically used with
hypervisor to interconnect virtual machines within
a host and virtual machines between different host
across the network.
l  Open vSwitch licenced under Apache 2.0
l  it is also used on some dedicated switching
hardware.
l  OVS can be a critical in an SDN solutions.
101 SDN
What is Open vSwitch ?

l  Open vSwitch is an open source OpenFlow
capable virtual switch that is typically used with
hypervisor to interconnect virtual machines within
a host and virtual machines between different host
across the network.
l  Open vSwitch licenced under Apache 2.0
l  it is also used on some dedicated switching
hardware.
l  OVS can be a critical in an SDN solutions.
101 SDN
OVS Features
l  LACP (IEEE 802.1AX-2008)
l  Standard 802.1Q VLAN model with trunking
l  BFD and 802.1ag link monitoring
l  STP (IEEE 802.1D-1998)
l  Fine-grained QoS control
l  Support for HFSC qdisc
l  Per VM interface traffic policing
l  NIC bonding with source-MAC load balancing, active backup, and L4 hashing
l  OpenFlow protocol support (including many extensions for virtualization)
l  IPv6 support
l  Multiple tunneling protocols (GRE, VXLAN, IPsec, GRE and VXLAN over IPsec)
l  Remote configuration protocol with C and Python bindings
l  Kernel and user-space forwarding engine options
l  Multi-table forwarding pipeline with flow-caching engine
l  Forwarding layer abstraction to ease porting to new software and hardware platforms
l  Visibility into inter-VM communication via NetFlow, sFlow(R), IPFIX, SPAN, RSPAN,
and GRE-tunneled mirrors
102 The newest version is 2.3.0 SDN
OVS Features
l  LACP (IEEE 802.1AX-2008)
l  Standard 802.1Q VLAN model with trunking
l  BFD and 802.1ag link monitoring
l  STP (IEEE 802.1D-1998)
l  Fine-grained QoS control
l  Support for HFSC qdisc
l  Per VM interface traffic policing
l  NIC bonding with source-MAC load balancing, active backup, and L4 hashing
l  OpenFlow protocol support (including many extensions for virtualization)
l  IPv6 support
l  Multiple tunneling protocols (GRE, VXLAN, IPsec, GRE and VXLAN over IPsec)
l  Remote configuration protocol with C and Python bindings
l  Kernel and user-space forwarding engine options
l  Multi-table forwarding pipeline with flow-caching engine
l  Forwarding layer abstraction to ease porting to new software and hardware platforms
l  Visibility into inter-VM communication via NetFlow, sFlow(R), IPFIX, SPAN, RSPAN,
and GRE-tunneled mirrors
102 The newest version is 2.3.0 SDN

Main Component
103 SDN
Main Component
103 SDN
ovsdb - server
l  Database that holds switch-level configuration.

–  Bridge, Interface, tunnel definision.
l  Configuration is stored on disk and survives a
reboot.
l  Log based (good for debugging)
–  ovsdb-tool: command-line tool to manage the database
–  ovsdb: persist the data across reboots. Configures
ovs-vswitchd
104 SDN
ovsdb - server
l  Database that holds switch-level configuration.

–  Bridge, Interface, tunnel definision.
l  Configuration is stored on disk and survives a
reboot.
l  Log based (good for debugging)
–  ovsdb-tool: command-line tool to manage the database
–  ovsdb: persist the data across reboots. Configures
ovs-vswitchd
104 SDN
ovs-vswitchd
l  Core component in the system:
–  Communicates with outside world using OpenFlow
–  Communicates with ovsdb server using management
protocol (ovsdb)
–  Communicates with kernel module over netlink
l  Support multiple independent datapaths (bridges)
l  Implements mirroring, bonding, and VLANs
through modifications of the same flow table
exposed through OF.
105 SDN
ovs-vswitchd
l  Core component in the system:
–  Communicates with outside world using OpenFlow
–  Communicates with ovsdb server using management
protocol (ovsdb)
–  Communicates with kernel module over netlink
l  Support multiple independent datapaths (bridges)
l  Implements mirroring, bonding, and VLANs
through modifications of the same flow table
exposed through OF.
105 SDN
openvswitch_mod.ko
l  Kernel module
•  Handles switching and tunneling
•  Designed to be fast and simple.
•  If flow found, actions are executed otherwise passed
to the user space.
•  Implements tunnels and caches flows.
106 SDN
openvswitch_mod.ko
l  Kernel module
•  Handles switching and tunneling
•  Designed to be fast and simple.
•  If flow found, actions are executed otherwise passed
to the user space.
•  Implements tunnels and caches flows.
106 SDN
Some OVS utility
l  ovs-ofctl – management utility for openflow
l  ovs-dpctl – Open vSwitch datapath management
utility
l  ovs-vsctl – manage the switch through interaction
with ovsdb-server
l  ovs-appctl – utility for managing logging levels
l  ovsdb-client – monitoring OVS database.
107 SDN
Some OVS utility

l  ovs-ofctl – management utility for openflow
l  ovs-dpctl – Open vSwitch datapath management
utility
l  ovs-vsctl – manage the switch through interaction
with ovsdb-server
l  ovs-appctl – utility for managing logging levels
l  ovsdb-client – monitoring OVS database.
107 SDN
OPENFLOW CONTROLLERS
108 SDN
OPENFLOW CONTROLLERS
108 SDN
OpenFlow Controllers
l  NOX
l  POX
l  Beacon
l  Floodlight
l  Ryu
l  OpenDaylight
l  Open Network Operating System (ONOS)
109 SDN
l  NOX
l  POX
l  Beacon
l  Floodlight
l  Ryu
l  OpenDaylight
l  Open Network Operating System (ONOS)
109 SDN
NOX Classic: C++/Python
NOX: C++
Cisco
Controller
Trema (Proprietary)
Full-stack OpenFlow
Framework in
Ruby and C
(Proprietary)
ETRI Big Network

110 (Proprietary) SDN
NOX Classic: C++/Python
NOX: C++
Cisco
Controller
Trema (Proprietary)
Full-stack OpenFlow
Framework in
Ruby and C
(Proprietary)
ETRI Big Network

110 (Proprietary) SDN
NOX
l  One of the first open source OpenFlow controllers
l  Developed by Nicira and donated to research
community in 2008
l  Supported by ON.LAB at Stanford and by UC Berkeley
l  Provides a C++ API for OpenFlow 1.0
l  Both a controller and a framework for developing
OpenFlow applications
l  Includes sample components for topology discovery,
learning switch, network-wide switch
l  NOX was further developed by CPqD to support
OpenFlow 1.3 in Nov. 2012
111 SDN
NOX
l  One of the first open source OpenFlow controllers
l  Developed by Nicira and donated to research
community in 2008
l  Supported by ON.LAB at Stanford and by UC Berkeley
l  Provides a C++ API for OpenFlow 1.0
l  Both a controller and a framework for developing
OpenFlow applications
l  Includes sample components for topology discovery,
learning switch, network-wide switch
l  NOX was further developed by CPqD to support
OpenFlow 1.3 in Nov. 2012
111 SDN
POX
l  Python-based newer version of NOX.
l  Platform for rapid development of network control
software using Python
l  OpenFlow controller plus a framework for
interacting with OpenFlow switches, debugging,
network virtualization, ...
l  Reusable components for path selection, topology
discovery
l  Runs on Linux, MAC OS, Windows
l  Can be bundled with install-free PyPy runtime for
easy deployment
112 SDN
POX
l  Python-based newer version of NOX.
l  Platform for rapid development of network control
software using Python
l  OpenFlow controller plus a framework for
interacting with OpenFlow switches, debugging,
network virtualization, ...
l  Reusable components for path selection, topology
discovery
l  Runs on Linux, MAC OS, Windows
l  Can be bundled with install-free PyPy runtime for
easy deployment
112 SDN
NOX/POX Overview
l  Components
Network Application Services
Topology VLAN
Discovery Tagging … Routing §  New functions as software services
Northbound API
Northbound API §  Provide interface to network applications
§  Not yet standardized
NOX/POX Controller – Network OS
Controller §  Provide system-wide abstractions
§  Turn networking into a software problem
Southbound API
§  Standardized OpenFlow protocol
§  Controller, switch interoperability
… OpenFlow Enabled Switches

§  New functions as software services
…
113 SDN
NOX/POX Overview
l  Components
Network Application Services
Topology VLAN
Discovery Tagging … Routing §  New functions as software services
Northbound API
Northbound API §  Provide interface to network applications
§  Not yet standardized
NOX/POX Controller – Network OS
Controller §  Provide system-wide abstractions
§  Turn networking into a software problem
Southbound API
§  Standardized OpenFlow protocol
§  Controller, switch interoperability
… OpenFlow Enabled Switches

§  New functions as software services
…
113 SDN
NOX/POX Architecture
Components
Common
L3_ Spanning_ Web Topology

L2_Multi OpenRoads
learning tree Services Discovery
MAC_ Packet_ Host L2_

Routing Authenticator
blocker dump Tracking learning
Core
Component API
Cooperative Event OpenFlow

Threading Harness API
Asynchronous I/O
114
Socket I/O File I/O
SDN
NOX/POX Architecture
Components
Common
L3_ Spanning_ Web Topology

L2_Multi OpenRoads
learning tree Services Discovery
MAC_ Packet_ Host L2_

Routing Authenticator
blocker dump Tracking learning
Core
Component API
Cooperative Event OpenFlow

Threading Harness API
Asynchronous I/O
114
Socket I/O File I/O
SDN
Beacon
l  Open source OpenFlow controller implemented in Java
l  Developed at Stanford University
l  Stable - Beacon has been in development since early 2010, and has
been used in several research projects, networking classes, and trial
deployments. Beacon currently powers a 100-vswitch, 20-physical
switch experimental data center and has run for months without
downtime.
l  Dynamic - Code bundles in Beacon can be started/stopped/refreshed/
installed at runtime, without interrupting other non-dependent bundles
(ie replace your running Learning Switch application without
disconnecting switches).
l  Rapid Development - Beacon is easy to get up and running. Java and
Eclipse simplify development and debugging of your applications.
l  Web UI - Beacon optionally embeds the Jetty enterprise web server
and a custom extensible UI framework
115 SDN
Beacon
l  Open source OpenFlow controller implemented in Java
l  Developed at Stanford University
l  Stable - Beacon has been in development since early 2010, and has
been used in several research projects, networking classes, and trial
deployments. Beacon currently powers a 100-vswitch, 20-physical
switch experimental data center and has run for months without
downtime.
l  Dynamic - Code bundles in Beacon can be started/stopped/refreshed/
installed at runtime, without interrupting other non-dependent bundles
(ie replace your running Learning Switch application without
disconnecting switches).
l  Rapid Development - Beacon is easy to get up and running. Java and
Eclipse simplify development and debugging of your applications.
l  Web UI - Beacon optionally embeds the Jetty enterprise web server
and a custom extensible UI framework
115 SDN
Floodlight
l  Java based OpenFlow controller based on Beacon
l  Works with physical- and virtual- switches that
speak the OpenFlow protocol
l  Open source: Floodlight is developed by an open
community of developers.
l  Easy to Use: Floodlight is simple to build and run.
l  Tested and Supported: Floodlight is actively tested
and improved by a community of professional
developers
116
l  A number of real-world networking applications SDN
Floodlight
l  Java based OpenFlow controller based on Beacon
l  Works with physical- and virtual- switches that
speak the OpenFlow protocol
l  Open source: Floodlight is developed by an open
community of developers.
l  Easy to Use: Floodlight is simple to build and run.
l  Tested and Supported: Floodlight is actively tested
and improved by a community of professional
developers
116
l  A number of real-world networking applications SDN
Floodlight
l  Floodlight Architecture
Circuit OpenStackQuantum Your Applications

Pusher (python) Plugin (python) …J REST Applications
REST API (Implement Restlet Routable Interface)
Module Applications Floodlight Controller
VNF Module Thread Packet Jython Web Unit

StaticFlow Manager Pool Streamer Sever UI Tests
EntryPusher
Firewall
Java API
Device Topology Link Flow Storage

PortDown Manager Service Discovery Cache Memory
Forwarding
Reconciliation
NoSQL
OpenFlow Services
Learning
Hub
Switch
Controller Counter
Switches PerfMon Trace
Memory Store
117 SDN
Floodlight
l  Floodlight Architecture
Circuit OpenStackQuantum Your Applications

Pusher (python) Plugin (python) …J REST Applications
REST API (Implement Restlet Routable Interface)
Module Applications Floodlight Controller
VNF Module Thread Packet Jython Web Unit

StaticFlow Manager Pool Streamer Sever UI Tests
EntryPusher
Firewall
Java API
Device Topology Link Flow Storage

PortDown Manager Service Discovery Cache Memory
Forwarding
Reconciliation
NoSQL
OpenFlow Services
Learning
Hub
Switch
Controller Counter
Switches PerfMon Trace
Memory Store
117 SDN
Floodlight
l  Application Modules
–  Forwarding: default reactive packet forwarding
application
–  Static Flow Entry Pusher
l  Install specific flow entry (match + action) to a specific switch
–  Firewall
l  An application to apply ACL rules to allow/deny traffic based on
specified match
–  Virtual Network Filter (VNF)
l  Simple MAC-based network isolation application
118 SDN
Floodlight
l  Application Modules
–  Forwarding: default reactive packet forwarding
application
–  Static Flow Entry Pusher
l  Install specific flow entry (match + action) to a specific switch
–  Firewall
l  An application to apply ACL rules to allow/deny traffic based on
specified match
–  Virtual Network Filter (VNF)
l  Simple MAC-based network isolation application
118 SDN
Floodlight
l  Module Description
Maintains the topology information for the controller

TopologyManager
Receives information from LinkDiscovery module
Maintains state of links in network

LinkDiscovery
Uses LLDP message
FloodlightProvider
Forwarding Basic reactive packet forwarding module
Manage the end-host (device) location information

DeviceManager
(mac, IP …)

StorageSource DB style storage for Topology and LinkDiscovery data
StaticFlowPusher Supports the insertion and removal of static flows
119 SDN
Floodlight
l  Module Description
Maintains the topology information for the controller

TopologyManager
Receives information from LinkDiscovery module
Maintains state of links in network

LinkDiscovery
Uses LLDP message
FloodlightProvider
Forwarding Basic reactive packet forwarding module
Manage the end-host (device) location information

DeviceManager
(mac, IP …)

StorageSource DB style storage for Topology and LinkDiscovery data
StaticFlowPusher Supports the insertion and removal of static flows
119 SDN
Ryu
l  Supports various versions of OpenFlow,
l  License: Apache 2.0
l  Developed by NTT laboratories
l  Can easily setup a multi-node OpenStack environment
using pre-configured Ryu VM image file
l  Supportability
l  OF 1.0, OF 1.2, OF 1.3
–  Other protocol: NetCONF, SNMP
–  Apps/libs
l  topology view, firewall, etc.
–  Integration with other project
l  OpenStack, IDS with snort, …
121 SDN
Ryu
l  Supports various versions of OpenFlow,
l  License: Apache 2.0
l  Developed by NTT laboratories
l  Can easily setup a multi-node OpenStack environment
using pre-configured Ryu VM image file
l  Supportability
l  OF 1.0, OF 1.2, OF 1.3
–  Other protocol: NetCONF, SNMP
–  Apps/libs
l  topology view, firewall, etc.
–  Integration with other project
l  OpenStack, IDS with snort, …
121 SDN
Ryu Architecture
l  Follow Standard SDN Architecture
SDN apps SDN apps SDN apps
Well defined API
(REST, RPC...)
Ryu built-in app Ryu App Ryu App
...
(Tenant Isolation, Application layer
Topology Discovery, Firewall …)
Event dispatcher libraries

Control layer
OpenFlow Protocol support
Parser/serializer (OVSDB, VRRP, ...)
Ryu SDN framework Open protocols
(OpenFlow,
OF-config,
NETConfig, SNMP)
OpenFlow switch OpenFlow switch Network device
122 SDN
Ryu Architecture
l  Follow Standard SDN Architecture
SDN apps SDN apps SDN apps
Well defined API
(REST, RPC...)
Ryu built-in app Ryu App Ryu App
...
(Tenant Isolation, Application layer
Topology Discovery, Firewall …)
Event dispatcher libraries

Control layer
OpenFlow Protocol support
Parser/serializer (OVSDB, VRRP, ...)
Ryu SDN framework Open protocols
(OpenFlow,
OF-config,
NETConfig, SNMP)
OpenFlow switch OpenFlow switch Network device
122 SDN
Open Controllers
Name Lang Platform License Original Notes
Author
NOX Python, Linux GPL Nicira actively developed
C++
POX Python Any
Beacon Java Win, Mac, GPL David runtime modular, web UI

Linux, Erickson framework, regression test
Android (Stanford) framework
Maestro Java Win, Mac, GPL Zheng Cai

Linux (Rice)
Trema Ruby, Linux GPL NEC includes emulator, regression test

C framework
Floodlight Java Any BigSwitch,

based on
123 Beacon SDN
Open Controllers
Name Lang Platform License Original Notes
Author
NOX Python, Linux GPL Nicira actively developed
C++
POX Python Any
Beacon Java Win, Mac, GPL David runtime modular, web UI

Linux, Erickson framework, regression test
Android (Stanford) framework
Maestro Java Win, Mac, GPL Zheng Cai

Linux (Rice)
Trema Ruby, Linux GPL NEC includes emulator, regression test

C framework
Floodlight Java Any BigSwitch,

based on
123 Beacon SDN
Comparisons on OpenFlow Controllers
l  Remarks
–  Beacon shows the best scalability
–  Scalability discrepancy due to following two reasons:
l  Algorithm of distributing incoming messages between threads
l  Mechanism or the libraries used for network interaction
The average throughput

achieved with different
number of threads (with
32 switches,105 hosts
per switch)
124 Source: Shalimov, Alexander, et al. "Advanced study of SDN/OpenFlow controllers.” , ACM, 2013. SDN
Comparisons on OpenFlow Controllers

l  Remarks
–  Beacon shows the best scalability
–  Scalability discrepancy due to following two reasons:
l  Algorithm of distributing incoming messages between threads
l  Mechanism or the libraries used for network interaction
The average throughput

achieved with different
number of threads (with
32 switches,105 hosts
per switch)
124 Source: Shalimov, Alexander, et al. "Advanced study of SDN/OpenFlow controllers.” , ACM, 2013. SDN
OPENDAYLIGHT
125 SDN
OPENDAYLIGHT
125 SDN
OpenDaylight
l  OpenDaylight (ODL) is an Open Source Software
project under the Linux Foundation with the goal
of accelerating the adoption and innovation of
Software Defined Networking (SDN).
l  Founded by industry leaders and open to all
126 SDN
OpenDaylight
l  OpenDaylight (ODL) is an Open Source Software
project under the Linux Foundation with the goal
of accelerating the adoption and innovation of
Software Defined Networking (SDN).
l  Founded by industry leaders and open to all
126 SDN
OpenDaylight Project Scope
l  The OpenDaylight controller
l  Software for forwarding elements
l  Southbound plugins to enable the controller to speak to the
OpenDaylight supplied and other network elements
l  Northbound plugins to expose interfaces to those writing
applications to the controller
l  Network services and applications intended to run on top of
the controller, integration between the controller and other
elements,
l  Support projects such as tools, infrastructure, or testing.
l  Plugins for inter-controller communication
127 SDN
OpenDaylight Project Scope

l  The OpenDaylight controller
l  Software for forwarding elements
l  Southbound plugins to enable the controller to speak to the
OpenDaylight supplied and other network elements
l  Northbound plugins to expose interfaces to those writing
applications to the controller
l  Network services and applications intended to run on top of
the controller, integration between the controller and other
elements,
l  Support projects such as tools, infrastructure, or testing.
l  Plugins for inter-controller communication
127 SDN
OpenDaylight Project Goals
l  Code: To create a robust, extensible, open source
code base that covers the major common components
required to build an SDN solution
l  Acceptance: To get broad industry acceptance
amongst vendors and users
–  Using OpenDaylight code directly or through vendor products
–  Vendors using OpenDaylight code as part of commercial
products
l  Community: To have a growing technical community
contributing to the code base, using the code in
commercial products, and adding value above, below
and around
128 SDN
OpenDaylight Project Goals

l  Code: To create a robust, extensible, open source
code base that covers the major common components
required to build an SDN solution
l  Acceptance: To get broad industry acceptance
amongst vendors and users
–  Using OpenDaylight code directly or through vendor products
–  Vendors using OpenDaylight code as part of commercial
products
l  Community: To have a growing technical community
contributing to the code base, using the code in
commercial products, and adding value above, below
and around
128 SDN
OpenDaylight Community
l  OpenDaylight is the preferred open source
controller platform
l  Supports >1 Billion subscribers
l  Founded 2013 - most mature open networking
project
l  Broadest range of SDN use cases
l  Largest commercial ecosystem
l  1k+ contributors, 5k+ members in community
l  7 platinum, 3 gold and 39 silver vendors
l  Contributing service providers add innovations to
code base to increase run time and inhibit lock-in
129 SDN
OpenDaylight Community
l  OpenDaylight is the preferred open source
controller platform
l  Supports >1 Billion subscribers
l  Founded 2013 - most mature open networking
project
l  Broadest range of SDN use cases
l  Largest commercial ecosystem
l  1k+ contributors, 5k+ members in community
l  7 platinum, 3 gold and 39 silver vendors
l  Contributing service providers add innovations to
code base to increase run time and inhibit lock-in
129 SDN
OpenDaylight Community (Members)
Continuous
Growth to 41
Members
130 SDN
OpenDaylight Community (Members)
Continuous
Growth to 41
Members
130 SDN
market summary
OpenDaylight
(55%), OpenvSwitch (55%), OpenDaylight (38%), DPDK (36%), ONAP (29%) and OpenSwitch (29%).
WHICH
WHICHOF THE
OF THE FOLLOWING
FOLLOWING POPULAR
SOLUTIONS HAVE YOU
NFV Solutions 67%
SDN Networking 57%
OpenvSwitch 55%
OpenDaylight 38%
DPDK 36%
ONAP 29%
OpenSwitch 29%
ONOS 21%
CORD 19%
FD.io 12%
Other 12%
Ryu 10%
OSM 10%
ONIE 10%
Project Calico 7%
OpenDataPlane 5%
131 SDN
0
INDUSTRY REPORT | 2017 Open Source in Networking 10 30 50 70
market summary
sdxcentral.com
OpenDaylight
(55%), OpenvSwitch (55%), OpenDaylight (38%), DPDK (36%), ONAP (29%) and OpenSwitch (29%).
WHICH
WHICHOF THE
OF THE FOLLOWING
FOLLOWING POPULAR
SOLUTIONS HAVE YOU
NFV Solutions 67%
SDN Networking 57%

OpenvSwitch 55% Page 32
OpenDaylight 38%
DPDK 36%
ONAP 29%
OpenSwitch 29%
ONOS 21%
CORD 19%
FD.io 12%
Other 12%
Ryu 10%
OSM 10%
ONIE 10%
Project Calico 7%
OpenDataPlane 5%
131 SDN
0 10 30 50 70
Project comparisons
LOC contributors
OpenStack 1.67M 1,974
CloudStack 1.5M 250

Eclipse
2.67M 404
platform
OpenDaylight 1.05M 154
Floodlight 97K 52
contrail- 19K
vrouter 258K 15
contrail 53
controller
132 Source: https://www.openhub.net/p/opendaylight

SDN
Project comparisons
LOC contributors
OpenStack 1.67M 1,974
CloudStack 1.5M 250

Eclipse
2.67M 404
platform
OpenDaylight 1.05M 154
Floodlight 97K 52
contrail- 19K
vrouter 258K 15
contrail 53
controller
132 Source: https://www.openhub.net/p/opendaylight

SDN
OpenDaylight code volume
133 Source: https://www.openhub.net/p/opendaylight SDN
OpenDaylight code volume
133 Source: https://www.openhub.net/p/opendaylight SDN

What People are Saying
“OpenDaylight is quickly evolving into something formidable with good

potential for mainstream relevancy.” – Andrew Lerner, Gartner
“OpenDaylight is making steady progress cultivating a growing community

of developers and users interested in adopting an open, common SDN
controller platform.” – Brad Casemore, IDC Research Director for
Datacenter Networks
An open source approach to so>ware-defined networking (SDN)

moved several steps closer this week to becoming a de facto standard.
– Mike Vizard, IT Business Edge
134 SDN
What People are Saying
“OpenDaylight is quickly evolving into something formidable with good

potential for mainstream relevancy.” – Andrew Lerner, Gartner
“OpenDaylight is making steady progress cultivating a growing community

of developers and users interested in adopting an open, common SDN
controller platform.” – Brad Casemore, IDC Research Director for
Datacenter Networks
An open source approach to so>ware-defined networking (SDN)

moved several steps closer this week to becoming a de facto standard.
– Mike Vizard, IT Business Edge
134 SDN
OpenDaylight Releases
l  Hydrogen (first release)
–  February 2014
–  13 projects, 1.3m lines of code
l  Helium (second release)
–  October 2014
l  Lithium (third release)
–  June 2015
l  Beryllium (forth release)
l  Boron (Fith release)
–  September 2016
–  56 projects , 3.6m lines of code
l  Carbon April 2017
–  75+ projects
l  Fluorine (Current Release)

–  August 2018
135 SDN
OpenDaylight Releases
l  Hydrogen (first release)
l  Helium (second release)
–  October 2014
l  Lithium (third release)
–  June 2015
l  Beryllium (forth release)
l  Boron (Fith release)
–  September 2016
–  56 projects , 3.6m lines of code
l  Carbon April 2017
–  75+ projects
l  Fluorine (Current Release)

–  August 2018
135 SDN
OpenDaylight Architecture
136 SDN
136 SDN
l  Southbound support multiple protocols as plugins.
l  Modules linked dynamically into a Service
Abstraction layer (SAL)
l  Main function in the controller: topology manager –
topology, device capabilities, and reachability, etc
with many supporting modules
137 SDN
l  Southbound support multiple protocols as plugins.
l  Modules linked dynamically into a Service
Abstraction layer (SAL)
l  Main function in the controller: topology manager –
topology, device capabilities, and reachability, etc
with many supporting modules
137 SDN
Service Abstraction Layer
l  Allow for multiple southbound protocols to present the
same northbound service interfaces.
l  SAL exposes basic services from the plugins
l  SAL maps service request to the appropriate plugins.
l  Plugins are independent and loosely coupled with SAL.
138 SDN
Service Abstraction Layer

l  Allow for multiple southbound protocols to present the
same northbound service interfaces.
l  SAL exposes basic services from the plugins
l  SAL maps service request to the appropriate plugins.
l  Plugins are independent and loosely coupled with SAL.
138 SDN
OpenDaylight REST API
l  REST : Representational State Transfer, is a style
of architecture based on a set of principles that
describe how networked resources are defined
and addressed.
l  The REST API provides access to the network
database that includes configuration data for the
controller (e.g. static flow table entries), data for
dynamically discovered network entities (e.g.
switches, hosts), and statistics and logging data.
139 SDN
OpenDaylight REST API

l  REST : Representational State Transfer, is a style
of architecture based on a set of principles that
describe how networked resources are defined
and addressed.
l  The REST API provides access to the network
database that includes configuration data for the
controller (e.g. static flow table entries), data for
dynamically discovered network entities (e.g.
switches, hosts), and statistics and logging data.
139 SDN
OpenDaylight platform
Graphical User Interface Applica=on and Toolkit (DLUX / NeXT UI)
Independent Network Applica=ons
AAA Authoriza=on Filter
OpenDaylight APIs REST/RESTCONF/NETCONF/AMQP
Control Plane Func=ons Embedded Controller Applica=ons Network Abstrac=ons

•  AAA (Policy/Intent)
•  Host Tracker •  Atrium Router •  NetIDE
•  Infrastructure U=li=es •  Cardinal •  NetVirt •  ALTO Protocol Manager Controller PlaUorm
•  L2 Switch Neutron Northbound •  Fabric as a Service Services/Applica=ons
•  Cen=nel – Streaming Data Hdlr • 
•  LISP Service •  Group Based Policy Service
•  Link Aggrega=on Control •  Controller Shield •  OVSDB Neutron
•  NEMO
Protocol •  Device Discovery, ID & Mgmt •  SN Integra=on Aggregator •  Network Intent Composi=on
•  Open Flow Forwarding Rules •  DOCSIS Abstrac=on •  Service Func=on Chaining
Manager Time Series Data Repository
•  Eman • 
•  OpenFlow Stats Manager
•  OpenFlow Switch Manager •  Genius •  Unified Secure Channel Mgr
•  Topology Processing •  NAT Applica=on •  User Network Interface Mgr
•  Virtual Tenant Network Mgr
Data Store (Config & Opera)onal) Service Abstrac)on Layer/Core Messaging (No)fica)ons / RPCs)
OpenFlow IoT PCMM/ Southbound Interfaces &

OF-Config OVSDB NETCONF LISP BGP PCEP CAPWAP OCP OPFLEX SXP SNMP USC SNBI LACP
H^p/CoAP COPS Protocol Plugins
Data Plane Elements

OpenFlow Enabled Addi=onal Virtual &
Open vSwitches (Virtual Switches, Physical
Devices Physical Devices
Device Interfaces)
140 SDN
Graphical User Interface Applica=on and Toolkit (DLUX / NeXT UI)
Independent Network Applica=ons
AAA Authoriza=on Filter
OpenDaylight APIs REST/RESTCONF/NETCONF/AMQP
Control Plane Func=ons Embedded Controller Applica=ons Network Abstrac=ons

•  AAA (Policy/Intent)
•  Host Tracker •  Atrium Router •  NetIDE
•  Infrastructure U=li=es •  Cardinal •  NetVirt •  ALTO Protocol Manager Controller PlaUorm
•  L2 Switch Neutron Northbound •  Fabric as a Service Services/Applica=ons
•  Cen=nel – Streaming Data Hdlr • 
•  LISP Service •  Group Based Policy Service
•  Link Aggrega=on Control •  Controller Shield •  OVSDB Neutron
•  NEMO
Protocol •  Device Discovery, ID & Mgmt •  SN Integra=on Aggregator •  Network Intent Composi=on
•  Open Flow Forwarding Rules •  DOCSIS Abstrac=on •  Service Func=on Chaining
Manager Time Series Data Repository
•  Eman • 
•  OpenFlow Stats Manager
•  OpenFlow Switch Manager •  Genius •  Unified Secure Channel Mgr
•  Topology Processing •  NAT Applica=on •  User Network Interface Mgr
•  Virtual Tenant Network Mgr
Data Store (Config & Opera)onal) Service Abstrac)on Layer/Core Messaging (No)fica)ons / RPCs)
OpenFlow IoT PCMM/ Southbound Interfaces &

OF-Config OVSDB NETCONF LISP BGP PCEP CAPWAP OCP OPFLEX SXP SNMP USC SNBI LACP
H^p/CoAP COPS Protocol Plugins
Data Plane Elements

OpenFlow Enabled Addi=onal Virtual &
Open vSwitches (Virtual Switches, Physical
Devices Physical Devices
Device Interfaces)
140 SDN
Life of a packet
1.  A packet arriving at Switch1 will be
sent to the appropriate plugin
managing the switch
2.  The plugin will parse the packet,
generate an event for SAL
3.  SAL will dispatch the packet to the
modules listening for DataPacket
4.  Module handles packet and sends
packet_out through
IDataPacketService
5.  SAL dispatches the packet to the
6.  OpenFlow message sent to
141
appropriate switch
SDN
Life of a packet
1.  A packet arriving at Switch1 will be
sent to the appropriate plugin
managing the switch
2.  The plugin will parse the packet,
generate an event for SAL
3.  SAL will dispatch the packet to the
4.  Module handles packet and sends
packet_out through
IDataPacketService
5.  SAL dispatches the packet to the
6.  OpenFlow message sent to
141
appropriate switch
SDN
OpenDaylight Platform Overview
l  Services Architecture
–  ODL employs an approach to describe the network, the
functions to be performed on it and the resulting state
–  With SAL, any approach function can be bundled into a
service that is then loaded into the controller.
–  Only install the protocols and services you need
–  Fine-grained services to be created then combined together
to solve more complex problems.
l  Multiprotocol Support
–  ODL supports OpenFlow , OpenFlow extensions, NETCONF,
BGP/PCEP, OVSDB, SNMP and many more.
l  Integraion with Other Open Source projects
–  OpenStack, OPNFV
142 SDN
OpenDaylight Platform Overview

l  Services Architecture
–  ODL employs an approach to describe the network, the
functions to be performed on it and the resulting state
–  With SAL, any approach function can be bundled into a
service that is then loaded into the controller.
–  Only install the protocols and services you need
–  Fine-grained services to be created then combined together
to solve more complex problems.
l  Multiprotocol Support
–  ODL supports OpenFlow , OpenFlow extensions, NETCONF,
BGP/PCEP, OVSDB, SNMP and many more.
l  Integraion with Other Open Source projects
–  OpenStack, OPNFV
142 SDN
Where Can We Use OpenDaylight?
Routing Consistent SDN

Application Service Application
ZTI App
Service Call Home
Database Server
SDN Powered by SDN Powered by SDN Powered by

Controller OpenDaylight™ Controller OpenDaylight™ Controller OpenDaylight™
Software
Config
Switched Routed Target

Domain Domain Branch CPE Network 1 Network 2
Office Device
SD-Core Zero Touch Installation Easy Adaption

Traffic sharing Automated set up of the Integrates legacy systems
between the switched software profile and services and new SDN equipment in
and routed domains configuration one network with plug-ins
143 SDN
Routing Consistent SDN

Application Service Application
ZTI App
Service Call Home
Database Server
SDN Powered by SDN Powered by SDN Powered by

Controller OpenDaylight™ Controller OpenDaylight™ Controller OpenDaylight™
Software
Config
Switched Routed Target

Domain Domain Branch CPE Network 1 Network 2
Office Device
SD-Core Zero Touch Installation Easy Adaption

Traffic sharing Automated set up of the Integrates legacy systems
between the switched software profile and services and new SDN equipment in
and routed domains configuration one network with plug-ins
143 SDN
Alarm
Analytics Policy Notification
Application
Templates Policy
NOC
Actions
sFlow
Switch
Network Configuration Network Analytics Alarming and

and Management and Policy Control Notification
Manage network devices with Automates analysis and action Maps underlying device
a single, consistent interface for pre-defined policies data to normalized models
144 SDN
Alarm
Analytics Policy Notification
Application
Templates Policy
NOC
Actions
sFlow
Switch
Network Configuration Network Analytics Alarming and

and Management and Policy Control Notification
Manage network devices with Automates analysis and action Maps underlying device
a single, consistent interface for pre-defined policies data to normalized models
144 SDN
OpenStack Integration
OpenStack Neutron l  OpenDaylight exposes a single

common OpenStack Service
Neutron ML2 Northbound
MechanismDriver –  API exposed matches Neutron API
precisely
–  multiple implementations of
Neutron networks in OpenDaylight
OpenDaylight APIs (REST)
Neutron Service
l  OpenDaylight OpenStack
Neutron Plugin simply passes
through
VTN
Provider
DOVE
Provider
OVSDB
Provider
–  simplifies OpenStack plugin
–  pushes complexity to OpenDaylight
OpenDaylight
145 SDN
OpenStack Integration
OpenStack Neutron l  OpenDaylight exposes a single

common OpenStack Service
Neutron ML2 Northbound
MechanismDriver –  API exposed matches Neutron API
precisely
–  multiple implementations of
Neutron networks in OpenDaylight
OpenDaylight APIs (REST)
Neutron Service
l  OpenDaylight OpenStack
Neutron Plugin simply passes
through
VTN
Provider
DOVE
Provider
OVSDB
Provider
–  simplifies OpenStack plugin
–  pushes complexity to OpenDaylight
OpenDaylight
145 SDN
OpenDaylight Web Interface
146 SDN
OpenDaylight Web Interface
146 SDN
OpenDaylight
l  Pull the code and review documentation at wiki.opendaylight.org

l  Connect with active developers in the community on the
#opendaylight IRC channel at webchat.freenode.net
l  Join the conversation through
lists.opendaylight.org and ask.opendaylight.org
l  Propose a new project at
wiki.opendaylight.org/view/Project_Proposals:Main
147 SDN
OpenDaylight
l  Pull the code and review documentation at wiki.opendaylight.org

l  Connect with active developers in the community on the
#opendaylight IRC channel at webchat.freenode.net
l  Join the conversation through
lists.opendaylight.org and ask.opendaylight.org
l  Propose a new project at
wiki.opendaylight.org/view/Project_Proposals:Main
147 SDN
ONOS
148 SDN
ONOS
148 SDN
ONOS
l  Open Network Operating System (ONOS) is an
open source SDN network operating system.
l  Focus on service provider networks, but not
limited to it
l  Provides abstractions to make it easy to create
apps and service to control a network.
149 SDN
ONOS
l  Open Network Operating System (ONOS) is an
open source SDN network operating system.
l  Focus on service provider networks, but not
limited to it
l  Provides abstractions to make it easy to create
apps and service to control a network.
149 SDN
Service Provider Networks
l  WAN core backbone u  High Throughput:
~500K-1M paths setups / second
–  200-500 routers, 5-10K ports
~3-6M network state ops /
MAN Access
Service Provider Networks second
l 
Metro cores for access
–  networks High Volume: u 
–  10-50K routers, 2-3M ports ~500GB-1TB of network state

data
●  WAN core backbone
l  Cellular Access Networks u  Difficult challenge!
o  Multi-Protocol Label Switching
–  LTE for a metro area
(MPLS) with Traffic Engineering (TE)
o  200-500 routers, 5-10K ports
–  20-100K devices, 100K-100M ports
●  Metro Networks
l  Wired access / aggregation
o  Metro cores for access networks
–  Access network for homes;
o  10-50K routers, 2-3M ports
DSL/Cable
●  Cellular Access Networks
–  10-50K devices, 100K-1M
o  LTE for a metro
ports area
o  20-100K devices, 100K-100M ports
●  Wired access / aggregation
o  150
Access network for homes; DSL/Cable SDN
Service Provider Networks

l  WAN core backbone u  High Throughput:
~500K-1M paths setups / second
–  200-500 routers, 5-10K ports
~3-6M network state ops /
MAN Access
Service Provider Networks second
l 
Metro cores for access
–  networks High Volume: u 
–  10-50K routers, 2-3M ports ~500GB-1TB of network state

data
●  WAN core backbone
l  Cellular Access Networks u  Difficult challenge!
o  Multi-Protocol Label Switching
–  LTE for a metro area
(MPLS) with Traffic Engineering (TE)
o  200-500 routers, 5-10K ports
–  20-100K devices, 100K-100M ports
●  Metro Networks
l  Wired access / aggregation
o  Metro cores for access networks
–  Access network for homes;
o  10-50K routers, 2-3M ports
DSL/Cable
●  Cellular Access Networks
–  10-50K devices, 100K-1M
o  LTE for a metro
ports area
●  Wired access / aggregation

o  150
Access network for homes; DSL/Cable SDN

Architectural Principals
l  High-availability, scalability and performance
–  required to sustain demands of service provider &
enterprise networks
l  Strong abstractions and simplicity
–  required for development of apps and solutions
l  Protocol and device behaviour independence
–  Avoid deformation due to protocol specifics
151 SDN
Architectural Principals
l  High-availability, scalability and performance
–  required to sustain demands of service provider &
enterprise networks
l  Strong abstractions and simplicity
–  required for development of apps and solutions
l  Protocol and device behaviour independence
–  Avoid deformation due to protocol specifics
151 SDN
ONOS Ecosystem
152 SDN
ONOS Ecosystem
152 SDN
ONOS Releases
Avocet December 5, 2014
Blackbird February 28, 2015
Cardinal May 31, 2015
Drake September 18, 2015
Emu December 18, 2015
Falcon March 10, 2016
Goldeneye June 24, 2016
Hummingbird September 23, 2016
Ibis December 9, 2016
Junco February 28, 2017
Kingfisher June 5, 2017
Loon September 8, 2017
Magpie December 2017
Nightingale May 2018
153
Owl Spetember 2018
SDN
ONOS Releases
Avocet December 5, 2014
Blackbird February 28, 2015
Cardinal May 31, 2015
Drake September 18, 2015
Emu December 18, 2015
Falcon March 10, 2016
Goldeneye June 24, 2016
Hummingbird September 23, 2016
Ibis December 9, 2016
Junco February 28, 2017
Kingfisher June 5, 2017
Loon September 8, 2017
Magpie December 2017
Nightingale May 2018
153
Owl Spetember 2018
SDN
Architecture
154 SDN
Architecture
154 SDN
ONOS Core Subsystems
155 SDN
ONOS Core Subsystems
155 SDN
Southbound overview
l  Southbound protocols:
–  OpenFlow
–  OVSDB
–  NETCONF + YANG
–  SNMP
–  BGP, ISIS, OSPF
–  PCEP
–  REST
–  LISP
–  …
157 SDN
Southbound overview
l  Southbound protocols:
–  OpenFlow
–  OVSDB
–  NETCONF + YANG
–  SNMP
–  BGP, ISIS, OSPF
–  PCEP
–  REST
–  LISP
–  …
157 SDN
Example Applications
l  SDN-IP Peering
–  Connect internal BGP software daemon to external BGP routers
–  Install learned routes to forward IP traffic to appropriate egress
point
l  Multi-level (IP / Optical) Provisioning
–  Provision optical paths/tunnels with constraints
l  Content Acquisition / Video Streaming (DirecTV)
–  Establish multicast forwarding from a sender to set of receivers
l  Virtual Network Gateway (vBNG)
–  Provide connectivity between a private host and the Internet
l  Bandwidth Calendaring
–  Establish tunnels with bandwidth guarantees between two points at
a given time
158 SDN
Example Applications
l  SDN-IP Peering
–  Connect internal BGP software daemon to external BGP routers
–  Install learned routes to forward IP traffic to appropriate egress
point
l  Multi-level (IP / Optical) Provisioning
–  Provision optical paths/tunnels with constraints
l  Content Acquisition / Video Streaming (DirecTV)
–  Establish multicast forwarding from a sender to set of receivers
l  Virtual Network Gateway (vBNG)
–  Provide connectivity between a private host and the Internet
l  Bandwidth Calendaring
–  Establish tunnels with bandwidth guarantees between two points at
a given time
158 SDN
Global SDN Deployment Powered by ONOS
159 SDN
Global SDN Deployment Powered by ONOS
159 SDN
Further reading
l  ONOS website:
http://onosproject.org
l  Tutorials, documentation and general reading at:
https://wiki.onosproject.org/
l  ONOS Github:
https://github.com/opennetworkinglab/onos
l  Setup Tutorial
https://wiki.onosproject.org/display/ONOS/Installing+and
+Running+ONOS
l  Screencasts:
https://wiki.onosproject.org/display/ONOS/Screencasts
160 SDN
Further reading
l  ONOS website:
http://onosproject.org
l  Tutorials, documentation and general reading at:
https://wiki.onosproject.org/
l  ONOS Github:
https://github.com/opennetworkinglab/onos
l  Setup Tutorial
https://wiki.onosproject.org/display/ONOS/Installing+and
+Running+ONOS
l  Screencasts:
https://wiki.onosproject.org/display/ONOS/Screencasts
160 SDN
ONOS versus OPENDAYLIGHT comparison
161 SDN
ONOS versus OPENDAYLIGHT comparison
161 SDN
QOS IN SDN
162 SDN
QOS IN SDN
162 SDN
QoS soluDons in SDN
163 SDN
QoS soluDons in SDN
163 SDN
SDN: QoS
l  Some SDN/QoS Frameworks
–  FlowQoS (2014)
–  EuQoS (2014)
–  OpenQoS (2012)
–  QoSFlow (2013)
–  PolicyCop (2013)
–  HiQoS (2015)
164 SDN
SDN: QoS
l  Some SDN/QoS Frameworks
–  FlowQoS (2014)
–  EuQoS (2014)
–  OpenQoS (2012)
–  QoSFlow (2013)
–  PolicyCop (2013)
–  HiQoS (2015)
164 SDN
FlowQoS(2014)
•  Facilitates con@iguration of QoS on home routers based on

applications and devices using SDN according to a set of rate
shaping policies de@ined by the user
•  Control logic:
–  Performs application identi@ication
–  Uses @low-table rules to forward traf@ic through the appropriate
rate shapers on a home router
165 SDN
FlowQoS(2014)
•  Facilitates con@iguration of QoS on home routers based on

applications and devices using SDN according to a set of rate
shaping policies de@ined by the user
•  Control logic:
–  Performs application identi@ication
–  Uses @low-table rules to forward traf@ic through the appropriate
rate shapers on a home router
165 SDN
FlowQoS
•  FlowQoS Architecture
166 SDN
FlowQoS
•  FlowQoS Architecture
166 SDN
FlowQoS
•  Users de@ine the max allowed bandwidth for speci@ic high-level

applications (video, VoIP) in the home network using a web
con@iguration tool
•  The web tool con@igures the rate shaper
•  The rate shaper has 2 components:

–  The @low classi@ier
–  The rate controller
167 SDN
FlowQoS
•  Users de@ine the max allowed bandwidth for speci@ic high-level

applications (video, VoIP) in the home network using a web
con@iguration tool
•  The web tool con@igures the rate shaper
•  The rate shaper has 2 components:

–  The @low classi@ier
–  The rate controller
167 SDN
FlowQoS
•  Flow classifier: classi@ies @lows using 2 modules:

–  The 1st module performs initial classi@ication of web traf@ic
•  HTTP & HTTPS determined by the ports 80 & 443
–  The 2nd module classi@ies the remaining traf@ic

•  non HTTP/HTTPS @lows based on the application layer protocol identi@ication (relies
on src IP/port, dst IP/port, transport protocol , the sent and received payload sizes,
…).
•  Rate controller: assigns each @low to the appropriate rate
168 SDN
FlowQoS
•  Flow classifier: classi@ies @lows using 2 modules:

–  The 1st module performs initial classi@ication of web traf@ic
•  HTTP & HTTPS determined by the ports 80 & 443
–  The 2nd module classi@ies the remaining traf@ic

•  non HTTP/HTTPS @lows based on the application layer protocol identi@ication (relies
on src IP/port, dst IP/port, transport protocol , the sent and received payload sizes,
…).
•  Rate controller: assigns each @low to the appropriate rate
168 SDN
FlowQoS
•  The different connections between the 2 switches

–  Configured via Linux’s TC utility
–  TC (traf@ic control) is the utility program used to con@igure the Linux
packet scheduler.
–  Assigned different rates specified by the controller, prede@ined by the user
170 SDN
FlowQoS
•  The different connections between the 2 switches

–  Configured via Linux’s TC utility
–  TC (traf@ic control) is the utility program used to con@igure the Linux
packet scheduler.
–  Assigned different rates specified by the controller, prede@ined by the user
170 SDN
FlowQoS
•  When a new @low arrives at the switch, it is redirected to the

appropriate @low classi@ier
•  The classi@ier identi@ies the application type for the @low
•  The controller installs OpenFlow rules into the OVS
•  The switch refers to its existing rules to determine which inter-

switch connection corresponds to that traf@ic class
•  The new @low is forwarded on the virtual links with the

appropriate shaping parameters
171 SDN
FlowQoS
•  When a new @low arrives at the switch, it is redirected to the

appropriate @low classi@ier
•  The classi@ier identi@ies the application type for the @low
•  The controller installs OpenFlow rules into the OVS
•  The switch refers to its existing rules to determine which inter-

switch connection corresponds to that traf@ic class
•  The new @low is forwarded on the virtual links with the

appropriate shaping parameters
171 SDN
HiQoS (2015)
•  HiQoS provides QoS guarantees using SDN

–  Uses multiple paths between src & dst
–  Utilizes queuing mechanisms to guarantee QoS for different types

of traf@ic
–  Recovers from link failure by rerouting traf@ic from failed path to

other available path
172 SDN
HiQoS (2015)
•  HiQoS provides QoS guarantees using SDN

–  Uses multiple paths between src & dst
–  Utilizes queuing mechanisms to guarantee QoS for different types

of traf@ic
–  Recovers from link failure by rerouting traf@ic from failed path to

other available path
172 SDN
HiQoS
•  HiQoS architecture
173 SDN
HiQoS
•  HiQoS architecture
173 SDN
HiQoS
•  HiQoS is divided into two components:

–  Differentiated services:
•  Classi@ies user traf@ic into video stream with high bandwidth
requirements, interactive audio/video with low delay
requirements and normal data stream as best effort services
•  Provides different bandwidth guarantees to different services
through OF integrated queuing mechanisms on the OF switches
–  Multipath routing:
•  Finds multiple paths meeting certain QoS constraints between the
src & dst nodes (modified Dijkstra algorithm)
•  Calculates the optimal path for each @low by real time monitoring
of the network state
174 SDN
HiQoS
•  HiQoS is divided into two components:

–  Differentiated services:
•  Classi@ies user traf@ic into video stream with high bandwidth
requirements, interactive audio/video with low delay
requirements and normal data stream as best effort services
•  Provides different bandwidth guarantees to different services
through OF integrated queuing mechanisms on the OF switches
–  Multipath routing:
•  Finds multiple paths meeting certain QoS constraints between the
src & dst nodes (modified Dijkstra algorithm)
•  Calculates the optimal path for each @low by real time monitoring
of the network state
174 SDN
HiQoS
•  HiQoS work@low
175 SDN
HiQoS
•  HiQoS work@low
175 SDN
PolicyCop (2013)
•  PolicyCop is a QoS policy management framework for

OpenFlow/SDN
–  Provides an interface for specifying QoS-based SLAs
–  Enforces SLAs via OpenFlow API
–  Monitors the network
–  Readjusts network parameters to satisfy customer SLAs
40
176 SDN
PolicyCop (2013)
•  PolicyCop is a QoS policy management framework for

OpenFlow/SDN
–  Provides an interface for specifying QoS-based SLAs
–  Enforces SLAs via OpenFlow API
–  Monitors the network
–  Readjusts network parameters to satisfy customer SLAs
40
176 SDN
PolicyCop (2013)
•  PolicyCop architecture
•  NB API:
NorthBound
API
177 SDN
PolicyCop (2013)
•  PolicyCop architecture
•  NB API:
NorthBound
API
177 SDN
PolicyCop (2013)
•  PolicyCop requires:
–  A database for storing control rules
•  Rule DB
–  4 control applications:
•  Admission Control
•  Routing
•  Device tracker
•  Statistics collector
–  A management plane
178 SDN
PolicyCop (2013)
•  PolicyCop requires:
–  A database for storing control rules
•  Rule DB
–  4 control applications:
•  Admission Control
•  Routing
•  Device tracker
•  Statistics collector
–  A management plane
178 SDN
PolicyCop (2013)
•  PolicyCop control applications:
1.  Admission control:
•  Receives resource provisioning requests from the management plane
•  Accepts or rejects the request depending on ressources availabilty
2.  Routing:
•  Determines path availability
•  Calculates routes based on the control rules in Rule DB
3.  Statistics Collector:
•  Uses a mix of passive/active monitoring techniques to measure different
network metrics (bandwidth usage, packet loss, …)
•  These data are used to define the suitability of route by the routing
application
1.  Device Tracker:
•  Tracks the up/down status of network switches & their ports
•  Listens to the asynchronous status messages exchanged
179 SDN
PolicyCop (2013)
•  PolicyCop control applications:
1.  Admission control:
•  Receives resource provisioning requests from the management plane
•  Accepts or rejects the request depending on ressources availabilty
2.  Routing:
•  Determines path availability
•  Calculates routes based on the control rules in Rule DB
3.  Statistics Collector:
•  Uses a mix of passive/active monitoring techniques to measure different
network metrics (bandwidth usage, packet loss, …)
•  These data are used to define the suitability of route by the routing
application
1.  Device Tracker:
•  Tracks the up/down status of network switches & their ports
•  Listens to the asynchronous status messages exchanged
179 SDN
PolicyCop (2013)
•  PolicyCop’s management plane consist of:

–  A network manager
•  Specifies policies that are stored in the Policy DB
–  Policy DB
•  A general purpose database for storing policies
–  Policy Validator
•  monitors the network to detect policy violations
–  Policy Enforcer
•  adapts control plane rules based on network conditions and policies
180 SDN
PolicyCop (2013)
•  PolicyCop’s management plane consist of:

–  A network manager
•  Specifies policies that are stored in the Policy DB
–  Policy DB
•  A general purpose database for storing policies
–  Policy Validator
•  monitors the network to detect policy violations
–  Policy Enforcer
•  adapts control plane rules based on network conditions and policies
180 SDN
PolicyCop (2013)
•  Policy Validator consists of 3 modules:
–  Traf@ic Monitor:
•  Collects the active policies from Policy DB
•  Determines appropriate monitoring interval, network segments & metrics
to be monitored
•  Utilizes the statistics collector application to collect data
–  Policy Checker:
•  Identify policy violations
•  Collects data from Policy DB and Traf@ic Monitor
•  Identify policy violations and forwards them to the Event Handler
–  Event Handler:
•  Examines the violation events
•  Uses a pre-speci@ied list of “Event Types” to determine the severity of a
violation event
•  Depending on the event type, an action request is either forwarded to the
network manager for manual action or to the policy adaptation module for
autonomic action
181 SDN
PolicyCop (2013)
•  Policy Validator consists of 3 modules:
–  Traf@ic Monitor:
•  Collects the active policies from Policy DB
•  Determines appropriate monitoring interval, network segments & metrics
to be monitored
•  Utilizes the statistics collector application to collect data
–  Policy Checker:
•  Identify policy violations
•  Collects data from Policy DB and Traf@ic Monitor
•  Identify policy violations and forwards them to the Event Handler
–  Event Handler:
•  Examines the violation events
•  Uses a pre-speci@ied list of “Event Types” to determine the severity of a
violation event
•  Depending on the event type, an action request is either forwarded to the
network manager for manual action or to the policy adaptation module for
autonomic action
181 SDN
PolicyCop (2013)
•  Policy Enforcer consists of 4 modules:
–  Topology Manager:
•  Collects data from the device tracker application
•  Maintains a complete view of the network,
•  The network view is used by the policy adaptation to make resource re-
provisioning decisions
–  Resource Manager:
•  Keeps track of currently allocated resources in the network
•  Uses the admission control & statistics collector
–  Policy Adaptation:
•  Consists of a set of Policy Adaptation Actions (PAAs)
•  PAAs are distinguished by the type of metric that has been violated
–  Resource Provisioning:
•  Re-provisions network resources when a policy violation occurs
•  Invoked by the policy adaptation module
•  Allocates more resources &/or releases existing ones based on the violation
event
182 SDN
PolicyCop (2013)
•  Policy Enforcer consists of 4 modules:
–  Topology Manager:
•  Collects data from the device tracker application
•  Maintains a complete view of the network,
•  The network view is used by the policy adaptation to make resource re-
provisioning decisions
–  Resource Manager:
•  Keeps track of currently allocated resources in the network
•  Uses the admission control & statistics collector
–  Policy Adaptation:
•  Consists of a set of Policy Adaptation Actions (PAAs)
•  PAAs are distinguished by the type of metric that has been violated
–  Resource Provisioning:
•  Re-provisions network resources when a policy violation occurs
•  Invoked by the policy adaptation module
•  Allocates more resources &/or releases existing ones based on the violation
event
182 SDN
PolicyCop (2013)
•  PolicyCop work@low
183 SDN
PolicyCop (2013)
•  PolicyCop work@low
183 SDN
Based on EuQoS (2014)
•  Enables QoS for business customer flows and make it possible to

prioritize them on demand using SDN
•  Based on EuQoS project:

–  end-to-end QoS over heterogeneous networks
–  resource management follows the forwarding path of the IP
packets, across multiple AS, as determined by BGP or OSPF.
–  Connection admission control is implemented using packet shapers
or policers.
–  Along the path, capacity management is implemented only at
bottleneck points (interconnections and edges).
184 SDN
Based on EuQoS (2014)
•  Enables QoS for business customer flows and make it possible to

prioritize them on demand using SDN
•  Based on EuQoS project:

–  end-to-end QoS over heterogeneous networks
–  resource management follows the forwarding path of the IP
packets, across multiple AS, as determined by BGP or OSPF.
–  Connection admission control is implemented using packet shapers
or policers.
–  Along the path, capacity management is implemented only at
bottleneck points (interconnections and edges).
184 SDN
Based on EuQoS
•  Implementation of the framework based on EuQoS
185 SDN
Based on EuQoS
•  Implementation of the framework based on EuQoS
185 SDN
Based on EuQoS
•  1 AS is controlled by 1 controller
•  The controller runs OpenFlow and OVSDB protocol
•  A bandwidth broker and the controller are able to communicate

with each other through a northbound API
•  Routing inter/intra-ASs is done via RouteFlow
186 SDN
Based on EuQoS
•  1 AS is controlled by 1 controller
•  The controller runs OpenFlow and OVSDB protocol
•  A bandwidth broker and the controller are able to communicate

with each other through a northbound API
•  Routing inter/intra-ASs is done via RouteFlow
186 SDN
Based on EuQoS
•  This framework’s concept is based on these steps:
•  Step 1: ConIiguration of 3 default queues

–  The controller establishes an OpenFlow session with a switch
–  Con@igures 3 default queues on each port of the switch using
OVSDB protocol
•  1st queue: is for control traf@ic and has the highest priority
•  2nd queue: is for high-priority traffic (de@ined by TOS @ield)
•  3rd queue: is for best-effort traf@ic
187 SDN
Based on EuQoS
•  This framework’s concept is based on these steps:
•  Step 1: ConIiguration of 3 default queues

–  The controller establishes an OpenFlow session with a switch
–  Con@igures 3 default queues on each port of the switch using
OVSDB protocol
•  1st queue: is for control traf@ic and has the highest priority
•  2nd queue: is for high-priority traffic (de@ined by TOS @ield)
•  3rd queue: is for best-effort traf@ic
187 SDN
Based on EuQoS
•  Step 2: Running a routing protocol

–  The controller runs standard routing protocols (OSPF, BGP) for
each OpenFlow switch using RouteFlow
–  Then sends the control traf@ic of the routing protocol using the 1st
queue configured at Step 1.
•  Step 3: Establishment of Flow Entries

–  For each new routing @low the controller de@ines 2 @low entries:
•  The 1st @low entry is for high-priority traffic (has TOS enabled and the
same dst IP as the routing entry’s) to be redirected to the 2nd queue of
the outport given by the routing entry
•  The 2nd @low entry is for best-effort traf@ic (has TOS disabled and the
same dst IP as the routing entry’s) to be redirected to the 3rd queue of
188 SDN
Based on EuQoS
•  Step 2: Running a routing protocol

–  The controller runs standard routing protocols (OSPF, BGP) for
each OpenFlow switch using RouteFlow
–  Then sends the control traf@ic of the routing protocol using the 1st
queue configured at Step 1.
•  Step 3: Establishment of Flow Entries

–  For each new routing @low the controller de@ines 2 @low entries:
•  The 1st @low entry is for high-priority traffic (has TOS enabled and the
same dst IP as the routing entry’s) to be redirected to the 2nd queue of
•  The 2nd @low entry is for best-effort traf@ic (has TOS disabled and the
same dst IP as the routing entry’s) to be redirected to the 3rd queue of
188 SDN
Based on EuQoS
•  Step 4: Availability of network resources for high-priority trafIic

–  A business customer requests assigning a certain amount of
bandwidth
–  The bandwidth broker checks for the availability of network
resources or SLAs validation by contacting the controller and the
neighboring bandwidth broker
–  In multiple AS, the SLA validation between the bandwidth brokers
is done via NSIS (signaling protocol de@ined by IETF)
–  If the requested resources are available or SLAs are validated, the
next step is performed. Else, the customer receives an error
message
189 SDN
Based on EuQoS
•  Step 4: Availability of network resources for high-priority trafIic

–  A business customer requests assigning a certain amount of
bandwidth
–  The bandwidth broker checks for the availability of network
resources or SLAs validation by contacting the controller and the
neighboring bandwidth broker
–  In multiple AS, the SLA validation between the bandwidth brokers
is done via NSIS (signaling protocol de@ined by IETF)
–  If the requested resources are available or SLAs are validated, the
next step is performed. Else, the customer receives an error
message
189 SDN
Based on EuQoS
•  Step 5: ConIiguring a rate limiter queue for high-priority trafIic

–  The controller @inds the edge router for high-priority traf@ic and
configures a rate limiter queue
–  The rate of the queue is negotiated between the bandwidth broker
and the business customer
•  Step 6: Establishing a Flow Entry for high-priority trafIic

–  The controller receives a @low entry on the edge router from the
business customer
–  The @low TOS @ield is enabled to classify the traf@ic as high-priority
–  Then this @low is redirected to the rate limiter queue
190 SDN
Based on EuQoS
•  Step 5: ConIiguring a rate limiter queue for high-priority trafIic

–  The controller @inds the edge router for high-priority traf@ic and
configures a rate limiter queue
–  The rate of the queue is negotiated between the bandwidth broker
and the business customer
•  Step 6: Establishing a Flow Entry for high-priority trafIic

–  The controller receives a @low entry on the edge router from the
business customer
–  The @low TOS @ield is enabled to classify the traf@ic as high-priority
–  Then this @low is redirected to the rate limiter queue
190 SDN
Based on EuQoS
•  Step 7: Re-establishing Flow Entries and the rate limiter Queues

–  This step is performed as a failure recovery
–  The controller removes the failed entries (due to the routing
protocols timeouts)
–  When the controller receives new routing entries
•  It establishes 2 Flow Entries per routing entry in the corresponding
routers
•  For the edge router, it recon@igures the rate limiter queue
(corresponding to the new path)
191 SDN
Based on EuQoS
•  Step 7: Re-establishing Flow Entries and the rate limiter Queues

–  This step is performed as a failure recovery
–  The controller removes the failed entries (due to the routing
protocols timeouts)
–  When the controller receives new routing entries
•  It establishes 2 Flow Entries per routing entry in the corresponding
routers
•  For the edge router, it recon@igures the rate limiter queue
(corresponding to the new path)
191 SDN
SDN APPLICATIONS
192 SDN
SDN APPLICATIONS
192 SDN
SDN Applications
l  Campus Netowrk:
–  Procera
l  Cellular Network:
–  SoftRan
–  SoftCell
–  OpenRoads
l  For more informations:

–  Diego Kreutz et all. « Software-Defined Networking: A
Comprehensive Survey »
–  https://www.opennetworking.org/sdn-resources/sdn-
reading-list
193 SDN
SDN Applications
l  Campus Netowrk:
–  Procera
l  Cellular Network:
–  SoftRan
–  SoftCell
–  OpenRoads
l  For more informations:

–  Diego Kreutz et all. « Software-Defined Networking: A
Comprehensive Survey »
–  https://www.opennetworking.org/sdn-resources/sdn-
reading-list
193 SDN
SOFTRAN : SOFTWARE DEFINED
RAN
194 SDN
SOFTRAN : SOFTWARE DEFINED

RAN
194 SDN
LTE - Radio Access Network
SGW 1 I
Client1 BS1 N
PGW
T
E
Client2
BS2 R
N
E
Client3 BS3 T
SGW 2
Client4 Core Network

Radio Access Network
RAN
195 SDN
LTE - Radio Access Network
SGW 1 I
Client1 BS1 N
PGW
T
E
Client2
BS2 R
N
E
Client3 BS3 T
SGW 2
Client4 Core Network

Radio Access Network
RAN
195 SDN
RAN Actions: Radio Resource Management
1. Assign each client to a base station
Flow 1 Flow 2 dB
dB
time time dB dB
dB
frequency frequency
2. Assign resource blocks (time- 3. Assign transmit powers to be
frequency slots) to each flow used for each resource block
196 SDN
RAN Actions: Radio Resource Management
1. Assign each client to a base station
Flow 1 Flow 2 dB
dB
time time dB dB
dB
frequency frequency
2. Assign resource blocks (time- 3. Assign transmit powers to be
frequency slots) to each flow used for each resource block
196 SDN
RAN Challenges
l  Increasing demand on wireless resources
–  Dense deployments of small cells
Radio Resource
Management gets coupled
across base stations
197 SDN
RAN Challenges
l  Increasing demand on wireless resources
–  Dense deployments of small cells
Radio Resource
Management gets coupled
across base stations
197 SDN
RAN Challenges
l  Coupled Radio Resource Management: Interference
BS2
BS1
Client1
Client2
l  Power used by BS1 affects interference at Client 2

l  Interference at Client 2 affects power reqd. at BS2
198 SDN
RAN Challenges
l  Coupled Radio Resource Management: Interference
BS2
BS1
Client1
Client2
l  Power used by BS1 affects interference at Client 2

l  Interference at Client 2 affects power reqd. at BS2
198 SDN
RAN Challenges
l  Coupled Radio Resource Management: Mobility
BS2
BS1
Client1
Client1
l  Dense deployments
–  Higher frequency of handovers
–  More candidate base stations
–  Coordinating handovers critical
199 SDN
RAN Challenges
l  Coupled Radio Resource Management: Mobility
BS2
BS1
Client1
Client1
l  Dense deployments
–  Higher frequency of handovers
–  More candidate base stations
–  Coordinating handovers critical
199 SDN
RAN Challenges
In dense deployments,
Radio Resource Management
needs to be tightly
coordinated
200 SDN
RAN Challenges
In dense deployments,
Radio Resource Management
needs to be tightly
coordinated
200 SDN
LTE-RAN: Current Architecture
l  Control signaling grows with density
l  Tight coordination becomes infeasible with density
–  Huge demands on the backhaul network
l  Inefficient radio resource management
l  Hard to manage in a dense network
201 SDN
LTE-RAN: Current Architecture

l  Control signaling grows with density
l  Tight coordination becomes infeasible with density
–  Huge demands on the backhaul network
l  Inefficient radio resource management
l  Hard to manage in a dense network
201 SDN
SoftRAN: Big Base Station Abstraction
Big Base Station
Radio Element 1
time
controller
frequency
Radio Element 2 Radio Element 3
time time
time
frequency frequency
202 SDN
SoftRAN: Big Base Station Abstraction
Big Base Station
Radio Element 1
time
controller
frequency
Radio Element 2 Radio Element 3
time time
time
frequency frequency
202 SDN
Radio Resource Allocation
Flows 3D Resource Grid
.me
203 SDN
Radio Resource Allocation
Flows 3D Resource Grid

.me
203 SDN
SoftRAN: SDN Approach to RAN
Coordination :
X2 Interface
Control Algo
Control Algo
OS
OS
Packet Tx/Rx Control Algo
Packet Tx/Rx
OS
Packet Tx/Rx
BS1
BS3
Control Algo Control Algo
OS
BS5
OS
Packet Tx/Rx Packet Tx/Rx
BS2 BS4
204 SDN
Coordination :
X2 Interface
Control Algo
Control Algo
OS
OS
Packet Tx/Rx Control Algo
Packet Tx/Rx
OS
Packet Tx/Rx
BS1
BS3
Control Algo Control Algo
OS
BS5
OS
BS2 BS4
204 SDN
Control Algorithm Operator Inputs
Network OS
Packet Tx/Rx
Packet Tx/Rx
Packet Tx/Rx
BS1
BS3
BS5
BS2 BS4
205 SDN
Control Algorithm Operator Inputs
Network OS
Packet Tx/Rx
Packet Tx/Rx
Packet Tx/Rx
BS1
BS3
BS5
BS2 BS4
205 SDN
SoftRAN Architecture
CONTROLLER
RAN Information Base

Periodic Updates Controller
•  Bytes Network
API •  Rate Operator
•  Queue Inputs
RADIO ELEMENTS Size
Interference Flow QoS
Map Records Constraints
3D Resource Grid
Radio Element
Radio Radio Resource

Element Management
API POWER
FLOW Algorithm
Frequency
206 SDN
SoftRAN Architecture
CONTROLLER
RAN Information Base

Periodic Updates Controller
•  Bytes Network
API •  Rate Operator
•  Queue Inputs
RADIO ELEMENTS Size
Interference Flow QoS
Map Records Constraints
3D Resource Grid
Radio Element
Radio Radio Resource

Element Management
API POWER
FLOW Algorithm
Frequency
206 SDN
SoftRAN Architecture: Updates
l  Radio element -> controller (updates)

–  Flow information (downlink and uplink)
–  Channel states (observed by clients)
l  Network operator -> controller (inputs)

–  QoS requirements
–  Flow preferences
207 SDN
SoftRAN Architecture: Updates
l  Radio element -> controller (updates)

–  Flow information (downlink and uplink)
–  Channel states (observed by clients)
l  Network operator -> controller (inputs)

–  QoS requirements
–  Flow preferences
207 SDN
SoftRAN Architecture: Controller Design
l  RAN information base (RIB)

–  Update and maintain global network view
l  Interference map
l  Flow records
l  Radio resource management

–  Given global network view: maximize global utility
–  Determine RRM at each radio element
208 SDN
SoftRAN Architecture: Controller Design
l  RAN information base (RIB)

–  Update and maintain global network view
l  Interference map
l  Flow records
l  Radio resource management

–  Given global network view: maximize global utility
–  Determine RRM at each radio element
208 SDN
SoftRAN Architecture: Radio Element API
l  Controller -> radio element

–  Handovers to be performed
–  RF configuration per resource block
l  Power allocation and flow allocation
–  Relevant information about neighboring radio
elements
l  Transmit Power being used
209 SDN
SoftRAN Architecture: Radio Element API
l  Controller -> radio element

–  Handovers to be performed
–  RF configuration per resource block
l  Power allocation and flow allocation
–  Relevant information about neighboring radio
elements
l  Transmit Power being used
209 SDN
SoftRAN Advantages
l  Logically centralized control plane:
–  Global view on interference and load
l  Easier coordination of radio resource management
l  Efficient use of wireless resources
–  Plug-and-play control algorithms

l  Simplified network management
–  Smoother handovers
l  Better user-experience
210 SDN
SoftRAN Advantages
l  Logically centralized control plane:
–  Global view on interference and load
l  Easier coordination of radio resource management
l  Efficient use of wireless resources
–  Plug-and-play control algorithms

l  Simplified network management
–  Smoother handovers
l  Better user-experience
210 SDN
SoftRAN: Evolving the RAN
l  Switching off radio elements based on load
–  Energy savings
l  Dynamically splitting the network into Big-BSs
–  Handover radio elements between Big-BSs
211 SDN
SoftRAN: Evolving the RAN

l  Switching off radio elements based on load
–  Energy savings
l  Dynamically splitting the network into Big-BSs
–  Handover radio elements between Big-BSs
211 SDN
SoftRAN: Implementation
l  Incrementally deployable on current

infrastructure
–  No modification to Base Station – client interface
–  New API definitions for Base Station
212 SDN
SoftRAN: Implementation
l  Incrementally deployable on current

infrastructure
–  No modification to Base Station – client interface
–  New API definitions for Base Station
212 SDN
PROCERA
213 SDN
PROCERA
213 SDN
Procera
l  A northbound interface that provides the ability to
specify and implement reactive policies.
l  It allows operators to express high-level policies
and translates such polices into a set of forwarding
rules, which are used to enforce the policy on the
underlying network infrastructure, using
OpenFlow.
l  Serves as a glue between high-level network
policies and low-level network configuration.
214 SDN
Procera
l  A northbound interface that provides the ability to
specify and implement reactive policies.
l  It allows operators to express high-level policies
and translates such polices into a set of forwarding
rules, which are used to enforce the policy on the
underlying network infrastructure, using
OpenFlow.
l  Serves as a glue between high-level network
policies and low-level network configuration.
214 SDN
Procera
l  Procera offers a set of control domains that
operators can use to set certain conditions and assign
appropriate packet forwarding actions corresponding
to each condition.
l  Operators can also combine control domains to
implement rich network policies
215 SDN
Procera
l  Procera offers a set of control domains that
operators can use to set certain conditions and assign
appropriate packet forwarding actions corresponding
to each condition.
l  Operators can also combine control domains to
implement rich network policies
215 SDN
Procera Architecture
216 SDN
216 SDN
l  Event source: network components or middleboxes
that can send dynamic events to the procera
controller. e.g.: IDS, Authentication systems, SNMP
l  Policy engine: responsible for analyzing the network
policy expressed with a policy language, also
processing various events that come from event
sources
l  Policy Language: allows operators to specify
complex network policies in a simple language.
l  Controller: Procera has a controller that makes all
traffic forwarding decisions and updates low-level
network switch flow- table entries according to this
policy.
217 SDN
l  Event source: network components or middleboxes
that can send dynamic events to the procera
controller. e.g.: IDS, Authentication systems, SNMP
l  Policy engine: responsible for analyzing the network
policy expressed with a policy language, also
processing various events that come from event
sources
l  Policy Language: allows operators to specify
complex network policies in a simple language.
l  Controller: Procera has a controller that makes all
traffic forwarding decisions and updates low-level
network switch flow- table entries according to this
policy.
217 SDN
Use Case: Campus Network
Campus network deployment status
218 SDN

Campus network deployment status
218 SDN
l  The deployment spans three buildings in the
Georgia Tech campus. For packet forwarding, they
use five OpenFlow-capable network switches.
l  There are two wireless access points deployed in
building 3, through which end-host devices can
connect to through a broadcasted SSID.
l  The authentication web portal, intrusion detection
system, and scanner, which are event sources,
are located in the data closet in building 2.
219 SDN

l  The deployment spans three buildings in the
Georgia Tech campus. For packet forwarding, they
use five OpenFlow-capable network switches.
l  There are two wireless access points deployed in
building 3, through which end-host devices can
connect to through a broadcasted SSID.
l  The authentication web portal, intrusion detection
system, and scanner, which are event sources,
are located in the data closet in building 2.
219 SDN
l  It requires every unregistered end-host device to
undergo an authentication process via an
authentication web portal.
l  After successful authentication, the device is
scanned for possible vulnerabilities.
l  If none are found, the device is finally granted
access to the internal network (VLAN) and the
Internet.
l  Other events: 5 hours’ inactivity & infection.
220 SDN

l  It requires every unregistered end-host device to
undergo an authentication process via an
authentication web portal.
l  After successful authentication, the device is
scanned for possible vulnerabilities.
l  If none are found, the device is finally granted
access to the internal network (VLAN) and the
Internet.
l  Other events: 5 hours’ inactivity & infection.
220 SDN
Transitions and events in campus network
221 SDN
Transitions and events in campus network
221 SDN
Lithium State
Use Case: Machine
Campus for Campus
Network
Network
Infection removed or manually fixed
Failed Authentication Quarantined
Registration
Successful
Authentication
Clean after update

Operation
Authenticated
Vulnerability detected
12
222 SDN
Lithium State
Use Case: Machine
Campus for Campus
Network
Network
Infection removed or manually fixed
Failed Authentication Quarantined
Registration
Successful
Authentication
Clean after update

Operation
Authenticated
Vulnerability detected
12
222 SDN
l  Implementing such complex policy relies on many
technologies.
–  eg. VLAN, firewall rules, routing tables, etc.
l  in traditional ways, administrators should
independently configure all the network policies in
multiple different components, including
middleboxes, management servers …
223 SDN

l  Implementing such complex policy relies on many
technologies.
–  eg. VLAN, firewall rules, routing tables, etc.
l  in traditional ways, administrators should
independently configure all the network policies in
multiple different components, including
middleboxes, management servers …
223 SDN
l  Procera simplifies the setting-up process by
introducing SDN ideas
–  All the network configuration policies are moved a
central controller,
–  Administrators use software programs to dynamically
control traffic forwarding and perform VLAN separation
on underlying OpenFlow-enabled switches.
–  In addition to traffic management, authentication has
also been changed to a SDN application running on the
central controller.
224 SDN

l  Procera simplifies the setting-up process by
introducing SDN ideas
–  All the network configuration policies are moved a
central controller,
–  Administrators use software programs to dynamically
control traffic forwarding and perform VLAN separation
on underlying OpenFlow-enabled switches.
–  In addition to traffic management, authentication has
also been changed to a SDN application running on the
central controller.
224 SDN
FIN
225 SDN
FIN
225 SDN

SDN 2019 PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

SDN 2019 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

So#ware

Vendor-based solutions with

Each year more devices, more complexity, more

Vendor-based solutions with

Each year more devices, more complexity, more

And what is on these devices?

Multi layer multi

And what is on these devices?

Multi layer multi

So what does a Network Engineer ? do…

Vertically integrated Horizontal

Vertically integrated Horizontal

Rou.ng, management, mobility management,

Specialized Packet Billions of gates

Closed, ver.cally integrated, closed, complex, proprietary

Rou.ng, management, mobility management,

Specialized Packet Billions of gates

Closed, ver.cally integrated, closed, complex, proprietary

Control plane and data plane

Specialized Open Interface

Vertically integrated Horizontal

Specialized Open Interface

Vertically integrated Horizontal

Computing systems now

AppAppAppAppAppAppAppAppAppAppApp Network apps

Open Interface API of Net OS

Open Interface API for controlling

Ideal networking system for innovation

AppAppAppAppAppAppAppAppAppAppApp Network apps

Open Interface API of Net OS

Open Interface API for controlling

This is the vision of SDN

Ideal networking system for innovation

This is the vision of SDN

Open Interface Northbound API

Open Interface Southbound API

OpenFlow enabled switches/routers

So#ware Deﬁned Network (SDN)

Open Interface Northbound API

Open Interface Southbound API

OpenFlow enabled switches/routers

App App App

Virtualization layer Virtualization or “Slicing”

x86 Open Interface

Computer Industry Network Industry

App App App

Virtualization layer Virtualization or “Slicing”

x86 Open Interface

Computer Industry Network Industry

More innovation in network services

Lower barrier to entry for competition

More innovation in network services

Lower barrier to entry for competition

in the past 40 years.

Classical network architecture

in the past 40 years.

Feature Feature Custom Hardware

The network is changing

Feature Feature Custom Hardware

So#ware Deﬁned Network (SDN)

Source: Nick Mckeown, Stanford

So#ware Deﬁned Network (SDN)

What is software defined networking?

–  Get state informa.on from forwarding elements

–  Get state informa.on from forwarding elements

l  Open Networking Founda.on (ONF)

l  Open Networking Founda.on (ONF)