ONOS Platform Architecture
•Download as PPTX, PDF•
9 likes•5,454 views
ONOS platform architecture presentation by Ali Al-Shabibi at the OpenDaylight meetup on March 2, 2015.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to ONOS Platform Architecture
Similar to ONOS Platform Architecture (20)
More from OpenDaylight
More from OpenDaylight (9)
Recently uploaded
Recently uploaded (20)
ONOS Platform Architecture
- 1. ONOS Open Network Operating System Architecture Overview onosproject.org Ali Al-Shabibi March 2nd OpenDaylight Meetup
- 2. ONOS: SDN OS for Service Provider Networks ● Scalability, High Availability & Performance ● Northbound & Southbound Abstractions ● Modularity
- 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. 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. 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. 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. 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. 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. 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. Intent Example Host to Host Intent
- 11. Intent Example COMPILATION Path IntentPath Intent Host to Host Intent
- 12. Intent Example COMPILATION INSTALLATION Flow Rule Batch Flow Rule Batch Flow Rule BatchFlow Rule Batch Path IntentPath Intent Host to Host Intent
- 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
- 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. 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
Editor's Notes
- To be more concrete, I would like to illustrate this using a simple example. We begin with a high level object defined by the application that requests connectivity is established between specific hosts. That object is transformed into more specific intent objects through a process called compilation. Once the intents that contain enough information that they can be programmed, we convert these lower-level intents into resource reservations and work in a process called installation.
- To be more concrete, I would like to illustrate this using a simple example. We begin with a high level object defined by the application that requests connectivity is established between specific hosts. That object is transformed into more specific intent objects through a process called compilation. Once the intents that contain enough information that they can be programmed, we convert these lower-level intents into resource reservations and work in a process called installation.
- To be more concrete, I would like to illustrate this using a simple example. We begin with a high level object defined by the application that requests connectivity is established between specific hosts. That object is transformed into more specific intent objects through a process called compilation. Once the intents that contain enough information that they can be programmed, we convert these lower-level intents into resource reservations and work in a process called installation.
- Hi, This is Madan Jampani. I’ll briefly talk about the role of the distributed core subsystem in ONOS and how it is architected. As Thomas alluded to in his presentation, the core subsystem’s primary responsibility is to manage state and do so in a highly available and performant manner. To that end and to better align with our modularity objectives, the core is organized as a collection of stores with each store serving the persistence needs of a specific service. Topology store, Store for intents are couple of examples. The idea here is for the specific store to abstract away all the gory details of replication, fault-tolerance, etc. Now, as Thomas mentioned, we assume there is no such thing as a one-stop-solution when it comes to state management and therefore the approach we take and choices we make for each store is dictated by the properties of the associated state. For example some state mandates ACID semantics, some state is eventually consistent and so on.
- In this slide is a partial listing of some of the state that is tracked inside ONOS and the associated properties. As you can see, there are some similarities as well as some differences. Some state is eventually consistent whereas some state needs stronger guarantees. Even for stuff at the same consistency level, the number of replicas could be dictated by the nature of read/write access and desired level of durability and performance.