Slides Onos

ONOS OVERVIEW
Architecture, Abstractions & Application

WHAT IS ONOS?
Open Networking Operating System (ONOS) is  

an open source SDN network operating system (controller).
Mission: to enable Service Providers to build real SDN solutions.
SDN seminar 2017, Systems Group 2

ONOS UNIVERSE

ARCHITECTURE PRINCIPLES
High availability, scalability and performance
Strong abstractions and simplicity
Protocol and device behaviour independence
Separation of concerns and modularity
https://wiki.onosproject.org/display/ONOS/Overview+of+ONOS+architecture

ONOS ARCHITECTURE


ONOS ARCHITECTURE
ONOS is partitioned into:

Protocol-aware network-facing modules that interact with the
network

ONOS ARCHITECTURE
Protocols: contain implementation of all features needed by ONOS

to communicate with real devices.
implement specific control and/or management protocols
Examples: OpenFlow, NETCONF, SNMP, etc.
Providers: abstract the low-level configuration, control and

management operations associated to real devices.
execute requests originated from the core
process and notify the core about events originated from the
infrastructure devices


ONOS ARCHITECTURE

Protocol-agnostic system core that tracks and serves
information about network state

CORE FUNCTIONALITY
A service is a unit of functionality.
A service is comprised of multiple components that reside at the

different layers and create a vertical slice.
A service is used by applications to carry out application logic in

the network.
Example: a segment routing application needs to use core services on
topology discovery, flow rules installation, etc.

CORE FUNCTIONALITY
Primary services:
Device Subsystem Topology Subsystem
Link Subsystem PathService
Host Subsystem FlowRule Subsystem
Packet Subsystem

CORE FUNCTIONALITY
ONOS defines several primary services:
Device Subsystem - Manages the inventory of infrastructure devices.
Link Subsystem - Manages the inventory of infrastructure links.
Host Subsystem - Manages the inventory of end-station hosts and their locations on the network.
Topology Subsystem - Manages time-ordered snapshots of network graph views.
PathService - Computes/finds paths between infrastructure devices or between end-station hosts using the
most recent topology graph snapshot.
FlowRule Subsystem - Manages inventory of the match/action flow rules installed on infrastructure devices and
provides flow metrics.
Packet Subsystem - Allows applications to listen for data packets received from network devices and to emit
data packets out onto the network via one or more network devices.
SDN seminar 2017, Systems Group X

SERVICE STRUCTURE

SERVICE STRUCTURE
Provider: responsible for interacting with the network environment using various control and
configuration protocols, and supplying service-specific sensory data to the core.
interface with the network via protocol-specific libraries
interface with the core via the ProviderService
Manager: mediator between the providers (and the network) and the applications
Service interface: applications or other core components learn about a particular aspect of the
network state
AdminService interface: handles administrative commands towards the network state or the system
ProviderRegistry interface: Providers can register with the manager
ProviderService interface: registered Providers can send and receive information to and from the
manager
Listener: Applications consume and manipulate information aggregated by the managers via the
AdminService and Service interfaces.

ONOS ARCHITECTURE

Applications that consume and act upon the information
provided by the core


ONOS ARCHITECTURE
Interfaces
Southbound (provider) API: network-facing modules interact
with the core
abstraction: protocol-neutral means to relay network state
information to the core

ONOS ARCHITECTURE
Interfaces
Northbound (consumer) API: the core interacts with the
applications
abstractions that describe network operation components
application logic expressed as a policy instead of mechanism
NORTHBOUND INTERFACE
Global network topology view

directed, cyclic graph comprising of infrastructure devices, links and
hosts
Intent
network-centric abstraction for programming data-plane in
topology-dependent manner
Flow Objective
device-centric abstraction for programming data-plane flows in
table pipeline

Intent: policy-based declaration of what the applications want the

network to do
supported by the Intent Framework service
focus on what should be done rather than how it is
programmed
abstracts unnecessary network complexity

Installable intent: actionable operations on the network

environment
generated by the core via intent compilation
carried out by intent installation process
examples: provisioning tunnel links, installing flow rules
Built-in and user-defined intents

Flow objective:
supported by the Flow Objective service
focus on how traffic should be handled by a device (switch)
rather than prescribing how the processing pipeline is built
abstracts device specific implementation of the data plane
drivers interpret flow objectives and map them to the tables
pipeline, i.e., install flows accordingly


DISTRIBUTED ARCHITECTURE
How to achieve that? > distributed system
How to keep simplicity of control? > centralized control plane
Combine the two
https://wiki.onosproject.org/display/ONOS/Cluster+Coordination


Distributed
a cluster of instances represents the controller
Symmetric
instances run identical software and are configured the same
Fault-tolerant
node failures do not affect the operation of the cluster because load can be
redistributed
Location transparent
the cluster looks like a single instance to the applications, which physical instance
handles the request is hidden
Dynamic
the cluster can scale up/down to meet the usage demands of applications and
traffic.
Each instance discovers the state of a subsection of the network.
Local state information is disseminated across the cluster as

events.
Events are shared among nodes via a distributed store.
Consistency schemes
eventually consistent
strongly consistent


DISTRIBUTED TOPOLOGY VIEW
In a distributed setting the topology view should ensure:
Completeness: controller instances should work together to ensure

each instance's view reflects the state of the entire network.
Accuracy:  
 
Low latency access: 


Accuracy: each instance’s network view should always expose the

correct state and quickly change to reflect any changes in the
underlying network.
Low latency access: 


Accuracy: each instance’s network view should always expose the

correct state and quickly change to reflect any changes in the
underlying network.
Low latency access: the network topology view is a heavily

consumed piece of state and thus requires low latency access.

Topology consistency is ensured via logical timestamps.
Logical timestamp = controller epoch + sequence number

controller epoch is monotonically increasing number each time the master instance of
a device changes (e.g., after failure)
sequence number is monotonically increasing number for a network event originating
at a single device
https://wiki.onosproject.org/display/ONOS/Network+Topology+State

Topology consistency is ensured via logical timestamps.
Logical timestamp = controller epoch + sequence number

controller epoch is monotonically increasing number each time the master instance of
a device changes (e.g., after failure)
sequence number is monotonically increasing number for a network event originating
at a single device
The master instance sends out topology events and their logical
timestamps
Other instances can detect changes in the topology they did know
about.
https://wiki.onosproject.org/display/ONOS/Network+Topology+State

SELF STUDY
Pick one primary service

Device Subsystem
Discover and understand its vertical slice
Link Subsystem (slide 25)
Host Subsystem Propose an application that is build on top

What design requirements does your
Topology Subsystem application have concerning:
PathService performance (response time,
bandwidth)
FlowRule Subsystem scalability
Packet Subsystem robustness to failures (availability)

Slides Onos

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Slides Onos

Uploaded by

Copyright:

Available Formats

ONOS OVERVIEW

Architecture, Abstractions & Application

Open Networking Operating System (ONOS) is

Mission: to enable Service Providers to build real SDN solutions.

SDN seminar 2017, Systems Group 2

SDN seminar 2017, Systems Group 3

High availability, scalability and performance

Strong abstractions and simplicity

Protocol and device behaviour independence

Separation of concerns and modularity

SDN seminar 2017, Systems Group 4

SDN seminar 2017, Systems Group 5

High availability, scalability and performance

Strong abstractions and simplicity

Protocol and device behaviour independence

Separation of concerns and modularity

SDN seminar 2017, Systems Group 6

ONOS is partitioned into:

SDN seminar 2017, Systems Group 7

Protocols: contain implementation of all features needed by ONOS

Providers: abstract the low-level configuration, control and

SDN seminar 2017, Systems Group 8

High availability, scalability and performance

Strong abstractions and simplicity

Protocol and device behaviour independence

Separation of concerns and modularity

SDN seminar 2017, Systems Group 9

ONOS is partitioned into:

SDN seminar 2017, Systems Group 10

A service is a unit of functionality.

A service is comprised of multiple components that reside at the

A service is used by applications to carry out application logic in

SDN seminar 2017, Systems Group 11

Device Subsystem Topology Subsystem

Link Subsystem PathService

Host Subsystem FlowRule Subsystem

SDN seminar 2017, Systems Group 12

Device Subsystem - Manages the inventory of infrastructure devices.

Link Subsystem - Manages the inventory of infrastructure links.

Topology Subsystem - Manages time-ordered snapshots of network graph views.

SDN seminar 2017, Systems Group X

SDN seminar 2017, Systems Group 13

SDN seminar 2017, Systems Group X

ONOS is partitioned into:

SDN seminar 2017, Systems Group 14

High availability, scalability and performance

Strong abstractions and simplicity

Protocol and device behaviour independence

Separation of concerns and modularity

SDN seminar 2017, Systems Group 15

SDN seminar 2017, Systems Group 16

Global network topology view

SDN seminar 2017, Systems Group 18

Intent: policy-based declaration of what the applications want the

SDN seminar 2017, Systems Group 19

Installable intent: actionable operations on the network

Built-in and user-defined intents

SDN seminar 2017, Systems Group 20

SDN seminar 2017, Systems Group 21

High availability, scalability and performance

Strong abstractions and simplicity

Protocol and device behaviour independence

Separation of concerns and modularity

SDN seminar 2017, Systems Group 22

Open Networking Operating System (ONOS) is  

Low latency access: 

Low latency access: 