Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ONOS Summit: ONOS Architecture

ONOS Project
December 09, 2014

ONOS Summit: ONOS Architecture

ONOS Architecture presented at ONOS Summit on Dec 9th, 2014
Presented by: Thomas Vachuska, Chief Architect, ONOS

ONOS Project

December 09, 2014
Tweet

More Decks by ONOS Project

Other Decks in Technology

Transcript

  1. ONOS Open Network Operating System Architecture Overview Thomas Vachuska tom@onlab.us

  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 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!
  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 Apps Apps
  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 Apps Apps
  7. 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
  8. 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
  9. 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
  10. Manager Component ONOS Core Subsystem Structure 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 AdapterService Service AdminService Listener notify register & unregister command command sensing add & remove query & command Store Store Protocols sync & persist Adapter Component AdapterRegistry Adapter AdapterService register & unregister sensing Protocols
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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