https://goo.gl/zDrZ1i

ONOS Open Network Operating System Andrea Campanella & Carmelo Cascone ONF P4 Brigade Work Days, Seoul, South Korea September 18, 2017

What is ONOS? Open Network Operating System (ONOS) is an open source SDN network operating system. Our mission is to enable Service Providers to build real SDN/NFV Solutions.

Quarterly Releases, Loon (1.11.0) - released 2017-10

2

Architectural Tenets ● High-availability, scalability and performance ○

required to sustain demands of service provider & enterprise networks

● Strong abstractions and simplicity ○

required for development of apps and solutions

● Protocol and device behaviour independence ○

avoid contouring and deformation due to protocol specifics

● Separation of concerns and modularity ○

allow tailoring and customization without speciating the code-base

3

ONOS Distributed Architecture Apps Apps NB Core API

Distributed Core (state management, notifications, high-availability & scale-out) SB Core API

Providers

Providers

Providers

Providers

Protocols

Protocols

Protocols

Protocols

4

Southbound Protocols and Drivers

Southbound overview Southbound protocols in 1.11.0: ● ● ● ● ● ● ● ● ● ● ●

OpenFlow until 1.3 + optical extension, 1.5 is implemented and under testing OVSDB NETCONF + YANG → Yang tools and Yang management system SNMP P4 on bmv2 softswitch → p4Runtime BGP, ISIS, OSPF → interoperability with legacy network. PCEP → Path computation element protocol (IETF) REST and RESTCONF LISP TL1 gRPC 6

ONOS drivers • Device specific driver • collection of behaviors • on-demand activation

File:-drivers.xml e.g microsemi

• Behaviours encapsulate specific logic and code: Ports,controller,flowrule,power…

• API: interface that all subsystem use • setLed

• Impl: device specific implementation to get the required result done. • Netconf: XML payload to do edit-config to change led Light

ONOS

api=InterfacePath impl=ImpementationPath />

App

Driver

Driver

Protocol

Protocol

7

Network Programming API

ONOS Core Subsystems External Apps REST API

...

gRPC

Proxy ARP

Mobility

L2 Forwarding

CLI

SDN IP / BGP

GUI

Packet / Optical

...

Application

UI Extension

Security

Device Cfg.

Discovery

Network Virt.

Tenant

...

Config

Storage

Region

Driver

Path

Tunnel

Intent

Statistics

Core

Cluster

Leadership

Mastership

Topology

Network Cfg.

Flow Objective

Group

Event

Messaging

Graph

Device

Link

Host

Flow Rule

Packet

OSGi / Apache Karaf

OpenFlow

NETCONF

OVSDB

...

ONOS provides a flexible and extensible API with multiple layers of abstraction for both network programming and configuration.

Key Northbound Abstractions ● Flow Rules ○ Pipeline specific flows

● Flow Objective ○ Pipeline independent and agnostic flow rule

● Intent ○ Topology independent, network-centric abstraction

Network Programming Abstract to concrete

Intent Host-Host

Single-Point to Multi-point

Protected Intent

Flow Objective OFDPA Pipeline

Single Table Pipeline

P4 program Defined Pipeline

Flow Rule Mapping through drivers OF

P4Runtime

Netconf

TL1 12

Flow Objectives

Flow Objective Architecture Device driver is used to translate objectives to the specific flow rules for a given device and pipeline

Apps Flow Objective

FlowObjective Service

C O N T R O L L E R Physical Device

Pipeliner API D E V I C E

D R I V E R S

Corsa Pipeliner

Juniper Pipeliner

OFDPA Pipeliner

OFFLowRuleProvider

Juniper FlowRuleProgrammable

OFFLowRuleProvider

Open Flow 1.0 Rule Corsa Pipeline

Netconf XML Juniper Pipeline

Open Flow 1.3 Rule HP Pipeline

Flow Objective Summary ● Flow Objective: abstraction for applications to be pipeline unaware while benefiting from multi-table architectures ● Enable app portability ○ interoperability between different type of pipelines coexisting in heterogenous networks. ○ Support for a new pipeline is achieved through a new pipeliner behaviour in a driver. The new pipeline is then programmable from all existing applications.

Flow Objective example Peering Router

Match on Switch port, MAC address, VLAN, IP FlowObjective Service CorsaPipeliner

OFDPA Pipeliner

CorsaPipeline

OFDPA Pipeline

Northbound Abstraction for APPs ● FlowObjective and Intents express proper API: ○ ○ ○ ○ ○ ○ ○ ○ ○

Reduced application complexity Application Reusability Application Portability Easiness of network programmability Heterogeneous networks Device-agnostic behavior Protocol-agnostic behavior Pipeline-agnostic behavior High availability, scalability and performance 17

Example

Building Network Applications Needs of a network application, API for: ● Topology ● Path computation ● Traffic routing ● State management and distribution ● Network events (e.g. Link faliures) Example: Reactive Forwarding App H1 ping H2 Automatic rule installation Host 1

Host 2

Building Network Applications Network events ● Packet In→ PacketProcessor Listener Mechanism ○ ○ ○

Application registers a packet processor Receive all packets sent to the controller. Receives a packet from H1 directed to H2 Reactive FWD Packet Service

Host 1

Host 2

Building Network Applications Topology Discover the topology → .currentTopology() of TopologyService. Topology is built by ONOS from: Devices, Hosts, Links through Device query, packets ARP or LLDP/BDDP Provided algorithms: ● DijkstraGraphSearch Path (default) Path from H1 to H2 → PathService → .getPath(H1, H2) ● BellmanFordGraphSearch ● ● ●

Reactive FWD Path Service

Host 1

Host 2

BreadthFirstSearch KShortestPathsSearch ……

Building Network Applications 3) Route traffic → FlowObjective (single table match action rules) 4) State management and distribution ● Install rules in consistent way → FlowObjective Service ● Translation into pipeline specific → Pipeliner ● Maintain Rule state across all controller instances ○ Flow state → PENDING_ADD, ADDED, DELETED Reactive FWD

FlowObjectives

Host 1

Traffic flows between H1 and H2

Host 2

Building Network Applications Network events: Topology changes → *Service Listeners Mechanism ○ Application can listen to switch, port, link and host events → *Listener React to device down event: ● Compute new path and new flow objectives ● Leverage or remove old flows Reactive FWD Device Service

Host 1

Traffic still flows between H1 and H2

Host 2

Building Network Applications 5) Network events ● Controller instance Failure ○ ○

Transition of devices to standby instance → Mastership Service State replication → *Store and ClusterService

ONOS Applications • Creating and deploying and ONOS App • Creating and deploying and ONOS App (video) • Template application tutorial

Takeaway ONOS makes it easy to develop SDN application that are: ● ● ● ● ● ●

Reusable on heterogeneous networks, Scalable, Resistant to failures, Distributed Optimized Device/Protocol/Pipeline agnostic

This result is achieved through: ● ● ●

Proper APIs and abstractions that are device, protocol and pipeline agnostic (FlowObjectives, Intents, Behaviours) Existing basic network services (Topology, Devices, Mastership, etc) Distributed Platform for resiliency (Store and Services)

27

Further reading ONOS website: http://onosproject.org

Tutorials, documentation and general reading at: https://wiki.onosproject.org/

ONOS is on Github at: https://github.com/opennetworkinglab/onos

Setup Tutorial https://wiki.onosproject.org/display/ONOS/Installing+and+Running+ONOS

Screencasts: https://wiki.onosproject.org/display/ONOS/Screencasts 28

[email protected] 29

Join the journey @ onosproject.org

30

Backup Slides

Flow Objective Abstraction Need for an agnostic abstraction to device type, protocol and pipeline so apps don’t have to be rewritten for every specific set of hardware and it’s pipeline → Application portability and independence Each app has it’s own intelligence and it’s very tailored 1:1 app to device

App

App

Controller

App

Controller offers a unique set of API with the needed abstractions N:N apps to devices

App

App

Controller

App

ONOS Core Subsystem Structure Application Component command

Application Component

Listener query & command notify

AdminService

command

register & unregister

notify

AdminService

Service

Manager Component

Listener query & command

Store

Service

Manager Component

Store

sync & persist

register & unregister

sync & persist

ProviderRegistry command

environment events

register & unregister

ProviderService

Drivers

command

environment events

Provider

register & unregister

Provider

Provider Component query & command

ProviderRegistry

Provider Component query & command

Protocols

query & command

Drivers

query & command

Protocols

ONOS instance

ONOS instance

ProviderService

33

Intent State Machine app request InstallReq add/update topo event

compile started Compiling

compile failed Failed

compile succeeded

app request

Recompiling

Installing install failed install succeeded

WithdrawReq Installed

remove topo or flow event

app request

compile failed or same result

Withdrawing

Removed from store

Withdrawn

withdraw succeeded

Failures in Intents Switch down: DEVICE_DOWN event

35

Reaction to failures for intents Each intent has the network resources registered (org.onosproject.net.intent.impl.ObjectiveTracker), so that all the intents that are involved in the failure will be re-compiled (org.onosproject.net.intent.impl.ObjectiveTracker.TopologyChangeHandler)

The recompilation process is a multi-threading process that: 1. removes the old failed intents 2. finds a new entire path from source to destination 3. generates new Installable Intents (i.e., FlowRule/FlowObjective Intent)

36

Extensible The Intent Framework can be easily extendable: - new intents - new compilers - new routing paths

37

Routing decisions

ONOS CORE Behaviours

APIs ● DeviceDescritpionDiscovery → Device’s Description and Ports. ● FlowRuleProgrammable → Translates to and from ONOS core FR abstraction in device specific calls ● PacketProgrammable → Emit a given packet from a device. ● GroupProgrammable → Translates to and from ONOS Groups ● PortStatisticsDiscovery → Statistics of Device Ports. ● Pipeliner → Pipeline abstraction, FlowObjectives to pipeline specific FR Recently Introduced ● DeviceHandshaker → device handshake for GeneralDeviceProvider. ● PipelineProgrammable → Installs a Programmable Pipeline on the Device.

39

Northbound Routing applications Applications can query the network topology, calculate a path and inject the configuration using FlowRule and FlowObjective abstractions Intent Subsystem/Application getPath PathService API

FlowRules FlowRule API