ONOS OVERVIEW - Systems GroupSDN seminar 2017, Systems Group DISTRIBUTED TOPOLOGY VIEW In a distributed setting the topology view should ensure: Completeness: controller instances

ONOS OVERVIEWArchitecture, Abstractions & Application

SDN seminar 2017, Systems Group

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.

2


ONOS UNIVERSE

3


ARCHITECTURE PRINCIPLES

High availability, scalability and performance

Strong abstractions and simplicity

Protocol and device behaviour independence

Separation of concerns and modularity

4

https://wiki.onosproject.org/display/ONOS/Overview+of+ONOS+architecture


ONOS ARCHITECTURE

5







6


ONOS ARCHITECTURE

ONOS is partitioned into:

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

7


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

8







9



ONOS ARCHITECTURE


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

10


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.

11


CORE FUNCTIONALITY

Primary services:

Device Subsystem

Link Subsystem

Host Subsystem

12

Topology Subsystem

PathService

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.

X


SERVICE STRUCTURE

13


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.

X


ONOS ARCHITECTURE


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

14







15



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

16


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

17


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

18



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

19



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

20



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

21







22



DISTRIBUTED ARCHITECTURE


How to achieve that? > distributed system

How to keep simplicity of control? > centralized control plane

Combine the two

23

https://wiki.onosproject.org/display/ONOS/Cluster+Coordination



24


DISTRIBUTED ARCHITECTUREDistributed

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.

X



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

X



25


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:

26





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:

27





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.

28



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

29

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.

30

https://wiki.onosproject.org/display/ONOS/Network+Topology+State


SELF STUDY

31

Pick one primary service

Discover and understand its vertical slice (slide 25)

Propose an application that is build on top

What design requirements does your application have concerning:

performance (response time, bandwidth)

scalability

robustness to failures (availability)

Device Subsystem

Link Subsystem

Host Subsystem

Topology Subsystem

PathService

FlowRule Subsystem

Packet Subsystem

Documents

ONOS OVERVIEW - Systems GroupSDN seminar 2017, Systems Group DISTRIBUTED TOPOLOGY VIEW In a distributed setting the topology view should ensure: Completeness: controller instances