Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ONOS Platform Architecture


Published on

ONOS platform architecture presentation by Ali Al-Shabibi at the OpenDaylight meetup on March 2, 2015.

Published in: Technology
  • I made $2,600 with this. I already have 7 days with this... ♥♥♥
    Are you sure you want to  Yes  No
    Your message goes here
  • Just got my check for $500, Sometimes people don't believe me when I tell them about how much you can make taking paid surveys online... So I took a video of myself actually getting paid $500 for paid surveys to finally set the record straight. I'm not going to leave this video up for long, so check it out now before I take it down! ◆◆◆
    Are you sure you want to  Yes  No
    Your message goes here
  • Earn $500 for taking a 1 hour paid survey! read more... ■■■
    Are you sure you want to  Yes  No
    Your message goes here

ONOS Platform Architecture

  1. 1. ONOS Open Network Operating System Architecture Overview Ali Al-Shabibi March 2nd OpenDaylight Meetup
  2. 2. ONOS: SDN OS for Service Provider Networks ● Scalability, High Availability & Performance ● Northbound & Southbound Abstractions ● Modularity
  3. 3. Service Provider Networks ● WAN core backbone o Multi-Protocol Label Switching (MPLS) with Traffic Engineering (TE) o 200-500 routers, 5-10K ports ● Metro Networks o Metro cores for access networks o 10-50K routers, 2-3M ports ● Cellular Access Networks o LTE for a metro area o 20-100K devices, 100K-100M ports ● Wired access / aggregation o Access network for homes; DSL/Cable o 10-50K devices, 100K-1M ports
  4. 4. 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!
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. Application Intent Framework ● Application specifies high-level intents; not low-level rules o 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
  10. 10. Intent Example Host to Host Intent
  11. 11. Intent Example COMPILATION Path IntentPath Intent Host to Host Intent
  12. 12. Intent Example COMPILATION INSTALLATION Flow Rule Batch Flow Rule Batch Flow Rule BatchFlow Rule Batch Path IntentPath Intent Host to Host Intent
  13. 13. Distributed Core ● Distributed state management framework o built for high-availability and scale-out ● Different types of state require different types of synchronization o 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
  14. 14. 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
  15. 15. 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
  16. 16. 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.
  17. 17. 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
  18. 18. 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 1 2 3 4 Adapter Component Manager Component AdapterRegistry Adapter AdapterService register & unregistersensing Protocols This is where the magic happens
  19. 19. 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
  20. 20. Modularity Objectives ● Increase architectural coherence, testability and maintainability o 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 users o unit of replacement is a module ● Avoid speciation of the ONOS code-base o APIs setup to encourage extensibility and community code contributions ● Preempt code entanglement, i.e. cyclic dependencies o reasonably small modules serve as firewalls against cycles ● Facilitate pluggable southbound
  21. 21. 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
  22. 22. ONOS Priorities for Feb. Release ● Prove out performance at scale o current release falls short in our own view o testing with real hardware o provide comprehensive assessment ● Continue to increase robustness o 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
  23. 23. Performance Objectives ● Throughput of proactive provisioning actions o 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 state o batching, caching, parallelism o dependency reduction ● Controller vs. Device Responsibilities o defer to devices to do what they do best, e.g low-latency reactivity, backup paths
  24. 24. Performance - CBench
  25. 25. 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
  26. 26. What’s available in ONOS today? ● ONOS with all its key features o high-availability, scalability*, performance* o northbound abstractions (application intents) o southbound abstractions (OpenFlow adapters) o modular code-base o GUI ● Open source o ONOS code-base on GitHub o documentation & infrastructure processes to engage the community ● Use-case demonstrations o SDN-IP, Packet-Optical ● Sample applications o reactive forwarding, mobility, proxy arp
  27. 27. Thank you! Questions?