Transcript SDN Switches and Controllers - DPNM Lab

James Won-Ki Hong
Department of Computer Science and Engineering
POSTECH, Korea
[email protected]
POSTECH
CSED702Y: Software Defined Networking
1/62
Outline
 OpenFlow Switches
 OpenFlow Controllers





NOX & POX
Floodlight
Ryu
Open Daylight (ODL)
Open Network Operating System (ONOS)
 Conclusions
POSTECH
CSED702Y: Software Defined Networking
2/62
Introduction to OpenFlow Switches
 Hardware-based OpenFlow Switches
 Commercial hardware switches with OpenFlow capability
• Network abstraction is realized by firmware upgrading
 Show high processing speed
 Have space limitation on saving the flow table entries
• Approximately store 1500 flow entries (due to expensive CAM)
 Not easy to upgrade
• Most switches only support OpenFlow up to version 1.0
 Software-based OpenFlow Switches




OpenFlow enabled software switch (runs on x86 commodity computer)
Performance is relatively low
Store large amount of flow entries with bound (theoretically)
Under active development, support most recent OpenFlow spec.
 Hybrid OpenFlow Switch
 A virtual switch with specialized hardware device
 Much faster than software-based switches
POSTECH
CSED702Y: Software Defined Networking
3/62
Hardware-basd OpenFlow Switches
Juniper MX-series
NEC IP8800
WiMax (NEC)
HP Procurve 5400
Netgear 7324
PC Engines
Pronto 3240/3290
Ciena Coredirector
More coming soon
...
POSTECH
CSED702Y: Software Defined Networking
4/62
Software-based OpenFlow Switches (1/3)
 OpenvSwitch (OVS)
 Overview
• A virtual switch or Virtual Ethernet Bridge (VEB)
• User-space: configuration, control
• Kernel-space: datapath (included in main Linux kernel from v3.3)
 Features
• Support OpenFlow protocol
• Support multiple tunneling protocols
• VxLAN, Ethernet over GRE, IPsec, GRE over IPsec
• Fine-grained QoS
 Main components
•
•
•
•
•
•
•
POSTECH
ovs-vswitchd: a daemon that implements the switch
ovsdb-server: lightweight database server that ovs-vswitch queries to
ovs-vsctl: a utility for querying and updating the config. of ovs-vswitchd
ovs-dpctl: a tool for configuring and monitoring the switch kernel module
ovs-ofctl: a tool for monitoring and administering OpenFlow switches
ovs-controller: a simple OpenFlow controller reference implementation
openvswitch.ko: OpenvSwitch switching datapath
CSED702Y: Software Defined Networking
5/62
Software-based OpenFlow Switches (2/3)
 OpenvSwitch Architecture
POSTECH
CSED702Y: Software Defined Networking
6/62
Software-based OpenFlow Switches (3/3)
 OpenFlow Software Switch




An OpenFlow compatible user-space software switch implementation
The original code is based on the Stanford 1.0 reference switch
Initially developed by Ericsson Research Lab
The implementation is feature-complete, and passes the available
oftest 1.1 test case
• Compatible with most of OpenFlow controllers which support OF 1.1
 CPqD version supports OpenFlow up to v1.3
 Components
•
•
•
•
POSTECH
ofdatapath: the switch implementation
ofprotocol: a secure channel for connecting the switch to the controller
oflib: a library for converting to/from 1.1 wire format
dpctl: a tool for configuring the switch from the console
CSED702Y: Software Defined Networking
7/62
Hybrid OpenFlow Switch (1/3)
 Problems of Software-based Switch
 Cannot fully utilize the hardware resources
• E.g., OVS only exploits single CPU core
 Tightly coupled with the OS kernel
• Increase the management complexity
 Low performance
• Massive RX interrupts handling for NIC device
• Shared data access between threads  competition makes bottleneck
 Hybrid OpenFlow Switch
 Separate the roles of virtual switch into two parties
• Hardware: pure packet processing
• Software: switch abstraction (e.g., flow table)
 Data Plane Development Kit (DPDK)
• A set of libraries and drivers for fast packet processing
• Incorporate with x86 CPU
• Fast network I/O in user space
POSTECH
CSED702Y: Software Defined Networking
8/62
Hybrid OpenFlow Switch (2/3)
 Features of Hybrid OpenFlow Switch
 Polling-based packet handling
 Core assignment
• Assign the polling task to a dedicated CPU core  less context switching
 Reduction of # of access in I/O and memory
 Lockless-queue, batch processing
Hybrid Switch with Intel DPDK
Pure Software-based Switch
packet handling
vswitch
vswitch
Polling-base
packet handling
User space
memory
Socket API
2. system call (read)
DPDK Library
User-mode I/O & HAL
3. system call (write)
Kernel
space
skb_buf
Ethernet Driver API
Ethernet Driver API
POSTECH
Write
4. DMA
1. Interrupt & DMA
NIC
1. Read
packet
buffer
Driver
NIC
packet
buffer
CSED702Y: Software Defined Networking
9/62
Hybrid OpenFlow Switch (3/3)
 Packet Processing using Multi Core CPUs
 Exploit many core CPUs
 Decouple I/O processing and flow processing
 Explicit thread assignment to CPU core
Ring buffer
NIC RX buffer
NIC 1
RX
NIC 2
RX
NIC 3
RX
NIC 4
RX
I/O RX
CPU0
I/O RX
CPU1
Flow lookup
packet processing
CPU2
Flow lookup
packet processing
CPU3
Flow lookup
packet processing
CPU4
Flow lookup
packet processing
CPU5
POSTECH
NIC TX buffer
Ring buffer
CSED702Y: Software Defined Networking
I/O TX
CPU6
I/O TX
CPU7
NIC 1
TX
NIC 2
TX
NIC 3
TX
NIC 4
TX
10/62
Introduction to OpenFlow Controller (1/2)
 Problem Statement
 New functions require new hardware
• E.g., VNTag, TrustSec
 No support for network-wide control or high-level abstractions
 Distributed control reduces the controllability
Management, No Controllability
Network Management
System (NMS)



Monitor: collect network-wide statistics using CLI,
SNMP, NetConf interfaces
Control: No real control of packet/flow forwarding
No much thing to do with monitored data…
Distributed Control:


…
Control
…
Datapath
F1
Switch 1
POSTECH
…
Fn
Per-box control
Config/Mgmt ≠
fine-grained control
HW Functions:



Inflexible
Proprietary
Expensive
Switch n
CSED702Y: Software Defined Networking
11/62
Introduction to OpenFlow Controller (2/2)
 Solution
 Need a Network Operating System (NOS), provide a uniform and
centralized programmatic interface to the entire network
 NOS does not manage the network itself, instead it provides a
programmatic interface
Application Programming Interface (API)
Network Operating System (NOS)
External Controller
Controllability:

…
…
Datapath
F1
Switch 1
POSTECH

Control
Fully remove to
external controller
Centralized control
F2
F3
…
Fn
Switch n
CSED702Y: Software Defined Networking
12/62
Pedigree Chart of OpenFlow Controllers
NOX Classic: C++/Python
NOX: C++
Scalability
Comparison
Cisco
Controller
(Proprietary)
Trema
Full-stack OpenFlow
Framework in
Ruby and C
(Proprietary)
ETRI
Controller
POSTECH
Big Network
Controller
(Proprietary)
CSED702Y: Software Defined Networking
13/62
POSTECH
CSED702Y: Software Defined Networking
14/62
History of NOX
 History




Started from SANE project and applied to Ethane in 2006
Ethane project was announced via SIGCOMM in 2007
Announced the OpenFlow spec 0.1.0 in Nov. 2007, spec 0.8.0 in May, 2008
NOX was initially developed by Nicira side-by-side with OpenFlow, and open
sourced as the first OpenFlow controller in 2008
 NOX was further developed by CPqD to support OpenFlow 1.3 in Nov. 2012
SANE
Ethane
NOX-Classic/NOX NOX-Classic (CPqD)
SANE
…
SANE
Network As a
File System
Policy
Compiler
Host Tracking
Host Tracking
Host Tracking
Host Tracking
Routing
Routing
Routing
Routing
Topology
Topology
Topology
Topology
OpenFlow v -2.0
OpenFlow v -1.0
OpenFlow v 1.0
OpenFlow v 1.3
POSTECH
Ethane
CSED702Y: Software Defined Networking
Ethane
…
15/62
NOX Classic vs NOX (1/2)
 NOX Versions
Version Name
NOX
Classic
(new) NOX
Branch Name
Version No.
Release Date
OF Spec
GUI
Zaku
0.9.0
2010-09-15
v1.0
Support
Destiny
0.9.1
2012-07-20
v1.0
Support
CPqD ver.
N/A
2012-11-10
v1.3
Not support
Verity
0.9.2
2012-05-11
v1.0
Not support
 NOX-Classic
 Original NOX (now, officially deprecated)
 C++ based SDN controller, applications can be developed using Python
• Use SWIG to integrate Python with C++
Sample apps written in C++
Sample apps written in Python
and C++ using SWIG lib
Sample apps written in Python
POSTECH
CSED702Y: Software Defined Networking
16/62
NOX Classic vs NOX (2/2)
 NOX




New NOX, separated from NOX-classic branch
Only support C++ for application development
Fewer default applications than NOX-classic
Enhanced performance and better source readability
• Written on top of Boost library
 No graphic user interface
NOX-Classic Code Snippet
POSTECH
NOX Code Snippet
CSED702Y: Software Defined Networking
17/62
POX Overview
 POX Versions
Controller Name
POX
Branch Name
Version No. Release Date
OF Spec
GUI
Angler
0.0.0
2012 Fall
v1.0
Support
Betta
0.1.0
2013 Spring
v1.0
Support
Carp
0.2.0
2013 Fall
v1.0
Support
Dart
0.3.0
2014 Summer
v1.0
Support
 POX
 NOX’s younger sibling implemented using
Python
 For the rapid development and prototyping
of network control software
 Support all OS (e.g., Linux, Mac, Windows)
 Can bundle with install-free PyPy runtime
 Performs well compared to NOX-classic
Python
• Note that NOX-classic does not support PyPy
runtime
 Used for research and education purpose
POSTECH
CSED702Y: Software Defined Networking
18/62
NOX/POX Overview (1/4)
 Components
Topology
Discovery
VLAN
Tagging
…
Scan
Detection
Network Application Services
 New functions as software services
Northbound API
Northbound API
 Provide interface to network applications
 Not yet standardized
Controller
NOX Controller – Network OS
 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
…
POSTECH
CSED702Y: Software Defined Networking
19/62
NOX/POX Overview (2/4)
 Granularity
 Choosing granularity involves trading off scalability against flexibility
 Observation: provides adequate information and changes slowly
• Includes switch-level topology, does not include the current state of network traffic
 Control: scale to large networks, while providing flexible control
Per-packet control
Per-flow control
Prefix-based routing control
Coarser grained control
Highest performance
Finer grained control
Lowest performance
 Switch Abstraction
 Switch instructions should be independent of the particular HW and
support the flow-level control granularity
 Solution: adopt OpenFlow switch abstraction
POSTECH
CSED702Y: Software Defined Networking
20/62
NOX/POX Overview (3/4)
 Operation
 Observation: construct the network view
• Use DNS, DHCP, LLDP and flow-initiation
 Control: determine whether to forward traffic, and to which route
• Access control, routing and failover applications
Network view generation
Reactive routing
Flow Table
IDX
SRC
DST
SRC P
DST P
153
sw. A
sw. B
p2
p1
SRC
DST
ACT
…
…
…
…
…
h. A
h. B
p1
357
sw. B
sw. A
P1
p2
NOX Controller
…
PACKET_IN
FLOW_MOD
NOX Controller
PACKET_OUT
with LLDP
PACKET_OUT
with LLDP
Host A
OpenFlow
Switch
PACKET_IN
Packet header Host C
p2
p1
with LLDP
SRC: Host A
p2
p1
DST: Host B
LLDP
OpenFlow
OpenFlow
Switch B
Switch A
CSED702Y: Software Defined Networking
POSTECH
p1
p2
Host B
21/62
NOX/POX Overview (4/4)
 Scaling
 Packet level parallelization
• Millions of arrival packets per second
• Packets are handled by individual switches
 Flow level parallelization
• Flow initialization rate is high but lower than
packet arrival rate
• Flow initialization is handled by individual
controller
 Periodic synchronization
• Network view changes slowly enough that can
be maintained centrally
 Public Release
 A PoC of OpenFlow controller
 Follow GPL license
 Many network applications
Source: Comparing OpenFlow Controller Paradigms Scalability: Reactive and Proactive.
International Conference on Advanced Information Networking and Applications
POSTECH
CSED702Y: Software Defined Networking
22/62
NOX/POX Architecture
Components
Common
L3_
learning
L2_Multi
Spanning_
tree
Web
Services
Topology
Discovery
OpenRoads
MAC_
blocker
Packet_
dump
Routing
Host
Tracking
L2_
learning
Authenticator
Core
Component API
Cooperative
Threading
Event
Harness
OpenFlow
API
Asynchronous I/O
Socket I/O
POSTECH
CSED702Y: Software Defined Networking
File I/O
23/62
POSTECH
CSED702Y: Software Defined Networking
24/62
Introduction to Floodlight
 Floodlight
 A completely open, free, OpenFlow controller developed by Big
Switch Network
 Currently supports OpenFlow up to v1.0
Research and commercial friendly
Easy to build, run, and develop
Toolchain
Rich set of build and debugging tools
POSTECH
Community of OpenFlow experts,
access to commercial upgrades, and
frequent testing
CSED702Y: Software Defined Networking
25/62
Floodlight Overview (1/2)
 Floodlight Architecture
Circuit
Pusher (python)
OpenStackQuantum
Plugin (python)
Your Applications
…
REST Applications
REST API (Implement Restlet Routable Interface)
Module Applications
Floodlight Controller
VNF
PortDown
Reconciliation
Forwarding
Hub
Learning
Switch
Java API
Firewall
StaticFlow
EntryPusher
Module
Manager
Thread
Pool
Device
Manager
Topology
Service
Link
Discovery
Jython
Sever
Flow
Cache
Web
UI
Unit
Tests
Storage
Memory
NoSQL
OpenFlow Services
Switches
POSTECH
Packet
Streamer
Controller
Memory
PerfMon
CSED702Y: Software Defined Networking
Trace
Counter
Store
26/62
Floodlight Overview (2/2)
 Application Modules
 Forwarding: default reactive packet forwarding application
 Static Flow Entry Pusher
• Install specific flow entry (match + action) to a specific switch
 Firewall
• An application to apply ACL rules to allow/deny traffic based on specified match
 Port Down Reconciliation: reconcile flows across a network
 Virtual Network Filter (VNF)
• Simple MAC-based network isolation application
 Core REST APIs
 Static Flow Pusher REST API
• Allow the user to proactively insert/delete/list the flows to OpenFlow switch
 Firewall REST API
• Allow the user to insert/delete/list rules for firewall
POSTECH
CSED702Y: Software Defined Networking
27/62
Floodlight Programming Model
 IFloodlightModule
 Java module that runs as part of Floodlight
 Consumes services and events exported by other modules
•
•
•
•
OpenFlow (e.g., Packet-in, Packet-out…)
Switch add / remove
Device add / remove / move
Link discovery
 External Application
External
Application
Ifloodlight
Module
 Communicates with Floodlight via REST
• Static Flow Pusher
REST
Northbound APIs
Floodlight Controller
• Add flow, delete flow,
list flows, removeAll flows
• Normalized network state
vSwitch
• List hosts, list links, list switches,
getStats, getCounters
vSwitch
• Maybe your applications?
vSwitch
vSwitch
POSTECH
CSED702Y: Software Defined Networking
28/62
Module Description
TopologyManager
LinkDiscovery
FloodlightProvider
Forwarding
Maintains state of links in network
Uses LLDP message
Basic reactive packet forwarding module
DeviceManager
Manage the end-host (device) location information
(mac, IP …)
StorageSource
DB style storage for Topology and LinkDiscovery data
RestServer
Implements via Restlets (restlet.org)
REST API modules must implement RestletRoutable
StaticFlowPusher
POSTECH
Maintains the topology information for the controller
Receives information from LinkDiscovery module
Supports the insertion and removal of static flows
CSED702Y: Software Defined Networking
29/62
POSTECH
CSED702Y: Software Defined Networking
30/62
Introduction to Ryu
流
Flow
POSTECH
龍
Oriental Dragion,
A god of water
CSED702Y: Software Defined Networking
31/62
Introduction to Ryu
 Ryu
 A platform for building OpenFlow applications
 Manage “flow” control to enable intelligent networking
 Features
• Generality: vendor-neutral, support open interface
• Agile: not the all-purpose big monolithic “controller”, but
the framework for SDN app dev.
Developed &
Maintained By
 Supportability
• OpenFlow protocol
– OF 1.0, OF 1.2, OF 1.3 and OF-CONFIG 1.1
• Other protocol: NetCONF, SNMP, OVSDB
• Apps/libs
– topology view, firewall, OpenFlow Restful, etc.
• Integration with other project
– OpenStack, HA with Zookeeper, IDS with snort
 License: Apache 2.0
POSTECH
CSED702Y: Software Defined Networking
32/62
Ryu Architecture
 Follow Standard SDN Architecture
SDN apps
SDN apps
SDN apps
Well defined API
(REST, RPC...)
Ryu built-in app
(Tenant Isolation,
Topology Discovery, Firewall …)
Ryu App
Ryu App
...
Event dispatcher
libraries
OpenFlow
Parser/serializer
Protocol support
(OVSDB, VRRP, ...)
Ryu SDN framework
OpenFlow switch
POSTECH
OpenFlow switch
Application layer
Control layer
Open protocols
(OpenFlow,
OF-config,
NETConfig, OVSDB)
Network device
CSED702Y: Software Defined Networking
33/62
Ryu Implementation (1/2)
 Event Driven
 Event source/dispatcher/sink
• Source
• Call methods of the event dispatcher to generate events
• Sink
• Subclass of class RyuApp
• Avoid race condition
Event sink
• Dispatcher
• Decouples event sources/sinks
• Dispatches events based on class of event
• Knows which methods are interested in which event
by methods attributes
RyuApp
RyuApp
queue
RyuApp
RyuApp
queue
Event source
Event
Event dispatcher
Event source
Event
Events are read only because it
is shared with many RyuApps
POSTECH
dispatch
RyuApp
RyuApp
queue
Determine which RyuApp to
deliver based on class of event
CSED702Y: Software Defined Networking
34/62
Ryu Implementation (2/2)
 Connection to OpenFlow Switch
 Receiving loop and sending loop
Sending thread:
Serialize and send
OF packets
OFP
message
Event sink
Receiving thread:
Generates OFPEvents
RyuApp
RyuApp
Event
Send queue
queue
Ryu
OpenFlow switch
POSTECH
CSED702Y: Software Defined Networking
35/62
POSTECH
CSED702Y: Software Defined Networking
36/62
OpenDaylight Scope and Projects
 OpenDaylight Scope
POSTECH
CSED702Y: Software Defined Networking
37/62
OpenDaylight Scope and Projects
 OpenDaylight Projects
 15 projects currently in bootstrap or incubation
Project
Description
Originator
Controller
Modular, extensible, scalable, and multi-protocol SDN controller
based on OSGi
Cisco
YANG Tools
Java-based NETCONF and YANG tooling for OpenDaylight
projects
Cisco
OpenFlow
Protocol Library
OF 1.3 protocol library implementation
Pantheon
OpenFlow Plugin
Integration of OpenFlow protocol library in controller SAL
Ericsson,
IBM, Cisco
Defense4All
DDoS detection and mitigation framework
Radware
OVSDB
OVSDB configuration and management protocol support
Univ. of Kent
ucky
LISP Flow
Mapping
LISP plugin, LISP mapping service
ConteXtrea
m
POSTECH
CSED702Y: Software Defined Networking
38/62
OpenDaylight Scope and Projects
 Project Framework
POSTECH
CSED702Y: Software Defined Networking
39/62
OpenDaylight Controller
 Features of OpenDaylight Controller
 Built using Java OSGi Framework – Equinox
• Provides Modularity & Extensibility
• Bundle Life-cycle management
• In-Service-Software Upgrade (ISSU) & multi-version support
 Service Abstraction Layer (SAL)
• Provides Multi-Protocol Southbound support
• Abstracts/hides southbound protocol specifics from the applications
 High availability & horizontal scaling using clustering
 Releases
 Hydrogen
• Initial release, support OpenFlow 1.0 and 1.3
 Helium
• Current stable release, plan to support OpenFlow 1.5
 Lithium
• The next release (6/25/2015  SR1 8/13  9/24)
• New project  IoT Data Management (IoTDM)
POSTECH
CSED702Y: Software Defined Networking
40/62
Hydrogen Architecture
VTN
Coordinator
Management
GUI/CLI
DDoS
Protection
Network Applications
Orchestration & Services
OpenStack
Neutron
OpenDaylight APIs (REST)
Base Network Service Functions
Topology
Mgr
Stats
Mgr
Switch
Mgr
Host
Tracker
Shortest
Path
Forwarding
Affinity
Service
Network
Config
LISP
Service
OpenStack Service
VTN
Manager
Controller Platform
DOVE Mgr
Service Abstraction Layer (SAL)
(plug-in mgr., capability abstractions, flow programming, inventory, …)
OpenFlow
1.0
1.3
OpenFlow Enabled
Devices
NETCONF
OVSDB
OVSDB enabled devices
Main difference from other OpenFlow-centric
controller platforms
SNMP
BGP-LS
PCEP
LISP
Devices with Proprietary
control plane
Southbound Interfaces
& Protocol Plugins
Data Plane Elements
(Virtual Switches,
Physical Device
Interfaces)
VTN: Virtual Tenant Network
DOVE: Distributed Overlay Virtual Ethernet
DDoS: Distributed Denial Of Service
LISP: Locator/Identifier Separation Protocol
OVSDB: Open vSwitch DataBase Protocol
BGP: Border Gateway Protocol
PCEP: Path Computation Element Communication Protocol
SNMP: Simple Network Management Protocol
41
POSTECH
CSED702Y: Software Defined Networking
41/62
Helium Architecture
VTN
Coordinator
Dlux UI
DDoS
Protection
Network Applications
Orchestration &
Services
SDNi
Wrapper
OpenStack
Neutron
AAA – AuthN filter
OpenDaylight APIs (REST)
Base Network Service Functions
Topology
Mgr
Stats
Mgr
Switch
Mgr
Host
Tracker
OpenFlow
1.3
VTN
Mgr
OVSDB
Neutron
Open
Contrail
GBP
Service
SFC
LISP
Service
L2
switch
AAA
DOCSIS
SNBI
service
SDNI
aggreg
Controller
Platform
Service Abstraction Layer (SAL)
(plug-in mgr., capability abstractions, flow programming, inventory, …)
GBP
renderer
1.0
Flow Rules
Mgr
OpenStack Service
TTP
OVSDB NETCONF
OpenFlow Enabled
Devices
PCMM/
COPS
SNBI
SNMP
OVSDB enabled devices
Main difference from other OpenFlow-centric
controller platforms
BGP-LS
PCEP
LISP
OPEN
CONTRAIL
Devices with Proprietary
control plane
Southbound
Interfaces
& Protocol Plugins
Data Plane Elements
(Virtual Switches,
Physical Device
Interfaces)
VTN: Virtual Tenant Network
DDoS: Distributed Denial Of Service
LISP: Locator/Identifier Separation Protocol
OVSDB: Open vSwitch DataBase Protocol
BGP: Border Gateway Protocol
PCEP: Path Computation Element Communication Protocol
PCMM: Packet Cable MultiMedia
SNMP: Simple Network Management Protocol
42
POSTECH
CSED702Y: Software Defined Networking
42/62
OpenDaylight Controller
 Plugin Build Process
POSTECH
CSED702Y: Software Defined Networking
43/62
OpenDaylight Controller
 Hydrogen OpenFlow Plugin Architecture
POSTECH
CSED702Y: Software Defined Networking
44/62
Model-Driven SAL (1/2)
 Model-Driven Service Abstraction Layer (SAL)
POSTECH
CSED702Y: Software Defined Networking
45/62
Model-Driven SAL (2/2)
 Model-Driven Service Abstraction Layer (SAL)
 Yang tools – supporting for model-driven SAL
 Provides tooling to build Java bindings in yang from
yang models
API-Driven SAL
POSTECH
Model-Driven SAL
CSED702Y: Software Defined Networking
46/62
POSTECH
CSED702Y: Software Defined Networking
47/62
SDN Evolution and ON.LAB
 Non-profit, carrier and vendor
neutral
 Provide technical shepherding,
core team
 Build community
 Many organizations supports
Platform
Development
And Beyond
Demonstrations
Deployments
Invention
2007 – Creation of
SDN Concept
POSTECH
2007 – Ethane
2008 – OpenFlow
2009 – FlowVisor,
Mininet, NOX
2010 – Beacon
2009 – Stanford
2010 – GENI started
and grew to 20
universities
2013 – 20 more camp
uses to be added
2012 –Define SDN
research agenda
for the coming
years
2008-2011 – SIGCOMM
2011 – Open Networking
Summit, Interop
CSED702Y: Software Defined Networking
48/62
Introduction
 ONOS: Open Network Operating System
 SDN OS for service provider networks
 Key features
• Scalability, high availability & performance
• Northbound & southbound abstraction
• Modularity
• Various usage purposes, customization and development
 History
Founded – 2012
ONOS Prototype 1 – 2013
ONOS Prototype 2 – 2013
(scalability, high availability)
(performance)
ONOS VERSION 1 –
Open sourced on Dec 5th, 2014
POSTECH
CSED702Y: Software Defined Networking
49/62
Key Performance Requirements
 Requirements for Supporting Service Provider Networks
 High throughput
• 500K ~ 1M paths setups / second, 3-6M network state operations / second
 High volume
• 500GB ~ 1TB of network state data
POSTECH
CSED702Y: Software Defined Networking
50/62
ONOS Tiers and Distributed Architecture
 Distributed Architecture
 Six tiered architecture
 Each ONOS instance is equipped with the same software stack
instance 1

Northbound Abstraction
• Network graph
• Application intents

Core
• Distributed
• Protocol independent

Southbound Abstraction
• Generalized OpenFlow
• Pluggable & extensive

Adapters
• Multiple southbound
protocol enabling layer
Protocols
• Self-defined protocols using
generalized SDN functions

POSTECH
instance 2
instance 3
CSED702Y: Software Defined Networking
instance 4
51/62
ONOS Graph API
Network Graph
(Eventually
consistent) consistent)
In-memory
Network
Graph (eventually
ONOS
Graph
Abstraction
Titan
Graph
DB
Indexing
Cassandra
RAMCloud
Distributed
Key-Value
Store
Ultra-low
latency distributed
data store
in DRAM
Scale-out
Instance 1
Instance 2
OpenFlow
Manager+
OpenFlow
Manager+
Instance 3
OpenFlow
Manager+
Hazelcast
Zookeeper
Control Application
Event Notifications
Distributed
Network
Graph/State
Control Application
(Strongly
Consistent)
Applications
Distributed Coordination
Registry
ONOS Architecture (Prototype 2)
Host
+ Floodlight
Host
Drivers
Host
POSTECH
CSED702Y: Software Defined Networking
52/62
ONOS Scale-Out
Network Graph
Global network view
Distributed
Network OS
Instance 1
Instance 2
Instance 3
Data plane
An instance is responsible for maintaining a part of network graph
Control capacity can grow with network size or application need
POSTECH
CSED702Y: Software Defined Networking
53/62
ONOS Control Plane Failover
Distributed
Registry
Master
Master
Switch
SwitchAA==ONOS
NONE1
Switch A = ONOS 2
Candidates = ONOS 2,
Candidates = ONOS 3
ONOS 3
Distributed
Network OS
Host
Master
Master
Master
Switch
SwitchAA==ONOS
NONE1
Switch A = ONOS 2
Candidates
Candidates==ONOS
ONOS2,
Candidates = ONOS 3
2,ONOS
ONOS33
Instance 1
A
Instance 2
Instance 3
E
C
B
Master
Master
Switch
SwitchAA==ONOS
NONE1
Switch A = ONOS 2
Candidates = ONOS
ONOS 2,
2,
Candidates = ONOS 3
ONOS 3
D
F
Host
Host
POSTECH
CSED702Y: Software Defined Networking
54/62
ONOS Distributed Core
 Distributed Core
 Responsible for all state management concerns
 Organized as a collection of “STORES”
• E.g., topology, links, link resources and etc.
 State management choices (ACID vs. BASE)
• ACID (Atomicity, Consistency, Isolation, Durability)
• BASE (Basically Available, Soft state, Eventually consistency)
 State and Properties
State
Properties
Network Topology
Eventually consistent, low latency access
Flow Rules, Flow Stats
Eventually consistent, shardable, soft state
Switch – Controller Mapping
Distributed Locks
Strongly consistent, slow changing
Application Intents
Resource Allocations
Strongly consistent, durable
POSTECH
CSED702Y: Software Defined Networking
55/62
Network Topology State
 Global Network View for NB Applications




State  inventory of devices, hosts and links
Goal: closely track the state of physical network
Fully replicated fro scale and low latency access
Causal consistency using logical timestamps (logical clock systems)
Logical clock system
(logical local time,
logical global time)
logical local time
↓
event sequence #
<1,1>
<2,1>
<4,1>
<2,2>
<3,1>
logical global time
↓
mastership term
<mastership term #, seq #>
POSTECH
CSED702Y: Software Defined Networking
56/62
Other States
 States of Flow Rules and Flow Stats
 Switch specific state
• Flow rules  switch specific match-action pairs
• Flow stats  flow specific traffic stats
 Partitioned with current switch master serving as the authoritative copy
• Can be fully replicated for quick failover
 Soft state
• Inconsistencies are reconciled by refreshing from source
 States of Other Elements
 Switch to controller mapping, application intents, resource allocations
 Require strong consistency
 Possible solutions
• Hazelcast based solution
• Used in ONOS version 1.0
• Has some shortcoming on supporting for durability
• Use of Raft consensus algorithm
• Provides all the desired consistency and durability properties
POSTECH
CSED702Y: Software Defined Networking
57/62
Application and Intent Framework
 Intent Framework
 Programming abstraction
• Intents
• Compilers
• Installers
 Execution framework
• Intent service
• Intent store
 Intents
 Provide a high-level interface that focuses on what should be done
rather than how it is specifically programmed
 Abstract network complexity from applications
 Extend easily to produce more complex functionality through
combinations of other intents
POSTECH
CSED702Y: Software Defined Networking
58/62
Intent Example
 Compiler & Installer
 Compiler: produce more specific Intents given the environment
• E.g., find the corresponding paths between two hosts
 Installer: transform Intents into device commands
Host to Host Intent
Compilation
Path Intent
Path Intent
Installation
Flow Rule Batch
Flow Rule Batch
Flow Rule Batch
POSTECH
CSED702Y: Software Defined Networking
Flow Rule Batch
59/62
Intent Framework Design
 Intent Framework
 Translates intents into device instructions (state, policy)
 Reacts to changing network conditions
 Extends dynamically to add, modify functionality (compilers, installers)
POSTECH
CSED702Y: Software Defined Networking
60/62
Representing Networks
 Network Graph
 Graph has basic network objects like switch, port, device and links
 Application computes path by traversing the links from SRC to DST
 Application writes each flow entry for the path
Flow entry
flow
Flow path
inport
flow
Flow entry
outport
switch
switch
port
switch
on
port
port
port
link
port
switch
port
host
POSTECH
on
host
CSED702Y: Software Defined Networking
61/62
Adapter Layer
 Design Consideration of Adapter
 ONOS supports multiple southbound protocols
 Adapters provide descriptions of data plane elements to the core
 Adapters hide protocol complexity from ONOS
 Device Subsystem
 Responsible for discovering and
tracking the devices
 Enable operators and apps to
control the devices
 Core model relies on the Device
and Port model objects
POSTECH
DeviceManager
OFDeviceProvider
Device
OpenFlowSwitch
DeviceId/ElementId
Dpid
Port
OFPortDesc
MastershipRole
RoleState
CSED702Y: Software Defined Networking
62/62
Q&A
POSTECH
CSED702Y: Software Defined Networking
63/62
Comparisons on OpenFlow Controllers
 Remarks
Back
 Python controllers do not support multi-threading, no scalability
 Beacon shows the best scalability
 Scalability discrepancy due to following two reasons:
• Algorithm of distributing incoming messages between threads
• Mechanism or the libraries used for network interaction
Source: Shalimov, Alexander, et al. "Advanced study of SDN/OpenFlow controllers."
Proceedings of the 9th Central & Eastern European Software Engineering Conference in Russia. ACM, 2013.
POSTECH
CSED702Y: Software Defined Networking
64/62