ONOS

Open Network Operating System

Architecture Overview

​

​

​

​

​

onosproject.org

ONOS:

SDN OS for Service Provider Networks

• Scalability, High Availability & Performance

​

• Northbound & Southbound Abstractions

​

• Modularity

Service Provider Networks

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

Key Performance Requirements

ONOS

Apps

Apps

Global Network View / State

Global Network View / State

high throughput | low latency | consistency | high availability

High Throughput:

~500K-1M paths setups / second

~3-6M network state ops / second

​

High Volume:

~500GB-1TB of network state data

​

​

Difficult challenge!

Distributed Architecture

NB Core API

Distributed Core

(state management, notifications, high-availability & scale-out)

SB Core API

Protocols

Providers

Protocols

Providers

Protocols

Providers

Protocols

Providers

Apps

Apps

Distributed Architecture

NB Core API

Distributed Core

(state management, notifications, high-availability & scale-out)

SB Core API

Protocols

Providers

Protocols

Providers

Protocols

Providers

Protocols

Providers

Apps

Apps

ONOS Architecture Tiers

Northbound - Application Intent Framework

(policy enforcement, conflict resolution)

OpenFlow

NetConf

. . .

Apps

Apps

Distributed Core

(scalability, availability, performance, persistence)

Southbound

(discover, observe, program, configure)

Northbound Abstraction:

- network graph

- application intents

​

Core:

- distributed

- protocol independent

​

Southbound Abstraction:

- generalized OpenFlow

- pluggable & extensible

Application Intent Framework

• Application specifies high-level intents; not low-level rules
• focus on what should be done, rather than how it should be done
• Intents are compiled into actionable objectives which are installed into the environment
• e.g. HostToHostIntent compiles into two PathIntents
• Resources required by objectives are then monitored
• e.g. link vanishes, capacity or lambda becomes available
• Intent subsystem reacts by recompiling intent and re-installing revised objectives

Distributed Core

• Distributed state management framework
• built for high-availability and scale-out
• Different types of state require different types of synchronization
• fully replicated
• master / slave replicated
• partitioned / distributed
• Novel topology replication technique
• logical clock in each instance timestamps events observed in underlying network
• logical timestamps ensure state evolves in consistent and ordered fashion
• allows rapid convergence without complex coordination
• applications receive notifications about topology changes

ONOS Subsystems - Today & 2015

Device

Link

Host

Topology

Flow Rule

Path

Packet

Statistics

Intent

Application

Leadership

Messaging

Storage

Region

Mastership

Driver

Group

Security

Flow Objective

Event

OpenFlow

NetConf

OVSDB

Core

Cluster

. . .

Proxy ARP

Mobility

L2 Forwarding

REST API

GUI

CLI

Network Cfg.

SDN IP / BGP

Packet / Optical

Tunnel

. . .

OSGi / Apache Karaf

Network Virt.

Device Cfg.

Config

UI Extension

External Apps

Graph

Discovery

Tenant

. . .

Roadmap items for 2015

Available today

ONOS Core Subsystem Structure

Manager

Component

Adapter

Component

Adapter

Component

App

Component

Service

AdminService

Listener

notify

command

command

sync & persist

add & remove

query &

command

App

Component

Adapter

Component

Manager

Component

AdapterRegistry

Adapter

Providerservice

Service

AdminService

Listener

notify

register & unregister

command

command

sensing

add & remove

query &

command

Store Store

Protocols

sync & persist

Adapter

Component

AdapterRegistry

Adapter

Providerservice

register & unregister

sensing

Protocols

Modularity Objectives

• Increase architectural coherence, testability and maintainability
• establish tiers with crisply defined boundaries and responsibilities
• setup code-base to follow and enforce the tiers
• Facilitate extensibility and customization by partners and users
• unit of replacement is a module
• Avoid speciation of the ONOS code-base
• APIs setup to encourage extensibility and community code contributions
• Preempt code entanglement, i.e. cyclic dependencies
• reasonably small modules serve as firewalls against cycles
• Facilitate pluggable southbound

​

ONOS Modules

• Well-defined relationships
• Basis for customization
• Avoid cyclic dependencies

onos-api

onlab-util-misc

onlab-util-rest

onlab-util-osgi

onos-of-api

onos-of-ctl

. . .

onos-core-net

onos-of-adapter-*

onos-core-store

ONOS 1.0.0 Release Priorities

• Release ONOS with coherent and modular architecture
• Enable and demonstrate high-availability operation
• Enable sustained pursuit of performance and scale objectives
• Enable development of apps and engagement of SDN community
• Demonstrate SDN-IP & Packet-Optical use cases
• User Interface

​

ONOS 1.1.0 Release Priorities

• Prove out performance at scale
• provide comprehensive assessment
• Continue to increase robustness
• defects, edge-cases, additional failure scenarios
• continuous testing framework
• Segment Routing use-case
• port to the released version of ONOS
• REST API & Security
• Support for multiple-tables

Performance Objectives

• Throughput of proactive provisioning actions
• path flow provisioning
• global optimization or rebalancing of existing path flows
• Latency of responses to topology changes
• path repair in wake of link or device failures
• Throughput of distributing and aggregating state
• batching, caching, parallelism
• dependency reduction
• Controller vs. Device Responsibilities
• defer to devices to do what they do best, e.g low-latency reactivity, backup paths

​

​

What’s available in ONOS today?

• ONOS with all its key features
• high-availability, scalability, performance
• northbound abstractions (application intents)
• southbound abstractions (OpenFlow Providers)
• modular code-base
• GUI
• Open source
• ONOS code-base on GitHub
• documentation & infrastructure processes to engage the community
• Use-case demonstrations
• SDN-IP, Packet-Optical
• Sample applications
• reactive forwarding, mobility, proxy arp, ...

Learn more about ONOS and join the community at

onosproject.org

“Software-defined networking can radically reshape the wide area network. The introduction of ONOS provides another open source SDN option designed for service provider networks with the potential to deliver the performance, scale, availability and core features that we value”

​

John Donovan

Senior Executive Vice President

AT&T Technology & Operations

BUILD

USE

CHAMPION