onos platform architecture
TRANSCRIPT
ONOS Open Network Operating System
Architecture Overview
onosproject.org
Ali Al-Shabibi
March 2nd OpenDaylight Meetup
ONOS:SDN OS for Service Provider Networks
● Scalability, High Availability & Performance
● Northbound & Southbound Abstractions
● Modularity
Service Provider Networks
● WAN core backboneo Multi-Protocol Label Switching (MPLS) with Traffic Engineering (TE)
o 200-500 routers, 5-10K ports
● Metro Networkso Metro cores for access networks
o 10-50K routers, 2-3M ports
● Cellular Access Networkso LTE for a metro area
o 20-100K devices, 100K-100M ports
● Wired access / aggregationo Access network for homes; DSL/Cable
o 10-50K devices, 100K-1M ports
Key Performance Requirements
ONOS
AppsApps
Global Network View / StateGlobal Network View / State
high throughput | low latency | consistency | high availability
High Throughput:~500K-1M paths setups / second
~1-2M network state ops / second
High Volume:~10GB of network state data
Difficult challenge!
Distributed Architecture
NB Core API
Distributed Core(state management, notifications, high-availability & scale-out)
SB Core API
Protocols
Adapters
Protocols
Adapters
Protocols
Adapters
Protocols
Adapters
AppsApps
Distributed Architecture
NB Core API
Distributed Core(state management, notifications, high-availability & scale-out)
SB Core API
Protocols
Adapters
Protocols
Adapters
Protocols
Adapters
Protocols
Adapters
AppsApps
ONOS Architecture Tiers
Northbound - Application Intent Framework(policy enforcement, conflict resolution)
OpenFlow NetConf . . .
AppsApps
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
Manager
Component
ONOS Core Subsystem Structure
Adapter
Component
Adapter
Component
App Component
ServiceAdminService
Listener
notify
command
command
sync & persist
add & remove
query &
command
App Component
Adapter
Component
Manager
Component
AdapterRegistry
Adapter
AdapterService
ServiceAdminService
Listener
notify
register & unregister
command
command
sensing
add & remove
query &
command
Store Store
Protocols
sync & persist
Adapter
Component
AdapterRegistry
Adapter
AdapterService
register & unregistersensing
Protocols
Application Intent Framework
● Application specifies high-level intents; not low-level ruleso 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
o e.g. HostToHostIntent compiles into two PathIntents
● Resources required by objectives are then monitored
o e.g. link vanishes, capacity or lambda becomes available
● Intent subsystem reacts by recompiling intent and re-installing
revised objectives
Intent Example
Host to Host Intent
Intent Example
COMPILATION
Path IntentPath Intent
Host to Host Intent
Intent Example
COMPILATION
INSTALLATION
Flow Rule Batch Flow Rule Batch
Flow Rule BatchFlow Rule Batch
Path IntentPath Intent
Host to Host Intent
Distributed Core
● Distributed state management frameworko built for high-availability and scale-out
● Different types of state require different types of synchronizationo fully replicated
o master / slave replicated
o partitioned / distributed
● Novel topology replication technique
o logical clock in each instance timestamps events observed in underlying
network
o logical timestamps ensure state evolves in consistent and ordered fashion
o allows rapid convergence without complex coordination
o applications receive notifications about topology changes
ONOS Distributed Core
● Responsible for all state management concerns
● Organized as a collection of “Stores”
o Ex: Topology, Intents, Link Resources, etc.
● Properties of state guide ACID vs BASE choice
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
Immutable
ONOS Southbound
● ONOS supports multiple
southbound protocols,
enabling a transition to true
SDN.
● Adapters provide
descriptions of dataplane
elements to the core - core
utilizes this information.
● Adapters hide protocol
complexity from ONOS.
Area of focus
● Attempt to be as generic as possible
● Enable partners/contributors to submit their own device/protocol
specific providers
● Providers should be stateless; state may be maintained for
optimization but should not be relied upon
Adapter Pattern
1. Adapter registers with core
a. Core returns a AdapterService bound to the Adapter
2. Adapter uses AdapterService to notify core of new events (device connected, pktin) via
Descriptions
3. Core can use Adapter to issue commands to elements under Adapter control
4. Eventually, the adapter unregisters itself; core will invalidate the AdapterService
12 3
4Adapter
Component
Manager
Component
AdapterRegistry
Adapter
AdapterService
register & unregistersensing
Protocols
This is where the
magic happens
Descriptions
● Serve as scratch pads to
pass information to core
● Descriptions are immutable
and extremely short lived
● Descriptions contains URI for
the object they are
describing
● URI also encode the Adapter
the device is linked to
Modularity Objectives
● Increase architectural coherence, testability and maintainabilityo establish tiers with crisply defined boundaries and responsibilities
o setup code-base to follow and enforce the tiers
● Facilitate extensibility and customization by partners and userso unit of replacement is a module
● Avoid speciation of the ONOS code-baseo APIs setup to encourage extensibility and community code contributions
● Preempt code entanglement, i.e. cyclic dependencieso reasonably small modules serve as firewalls against cycles
● Facilitate pluggable southbound
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 Priorities for Feb. Release
● Prove out performance at scaleo current release falls short in our own view
o testing with real hardware
o provide comprehensive assessment
● Continue to increase robustnesso defects, edge-cases, additional failure scenarios
o continuous testing framework
● Segment Routing use-case
o port to the released version of ONOS
● REST API & Security
● Support for multiple-tables
Performance Objectives
● Throughput of proactive provisioning actionso path flow provisioning
o global optimization or rebalancing of existing path flows
● Latency of responses to topology changes
o path repair in wake of link or device failures
● Throughput of distributing and aggregating stateo batching, caching, parallelism
o dependency reduction
● Controller vs. Device Responsibilitieso defer to devices to do what they do best, e.g low-latency reactivity, backup
paths
Performance - CBench
Performance – Flow Installation
System Environment:
• Server: Dual XeonE5-2670 v2 2.5GHz; 64GB
DDR3; 512GB SSD
• 1Gbps NIC
"Constant-Load" Test Conditions:
• F = 122500 - total # of flows installed
• N: # of neighboring ONOS's for flows to be
installed when ONOS1 is the server installing
flows
• S: #servers installing flows
• SW = 35 - total # of switches (Null Devices)
connected to ONOS cluster evenly distributed to
active ONOS nodes
• FL: # flows to be installed on each switch
What’s available in ONOS today?
● ONOS with all its key featureso high-availability, scalability*, performance*
o northbound abstractions (application intents)
o southbound abstractions (OpenFlow adapters)
o modular code-base
o GUI
● Open sourceo ONOS code-base on GitHub
o documentation & infrastructure processes to engage the community
● Use-case demonstrationso SDN-IP, Packet-Optical
● Sample applicationso reactive forwarding, mobility, proxy arp
Thank you!
Questions?