Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
NOTE: This page is under construction and will be updated soon with the latest information about the ONOS roadmap. For right now, this is just an outline to help start putting some structure in place for the page.
How to Read This Document
This roadmap is intended to provide information about what is being planned for upcoming ONOS releases and to provide guidance about how you can help us with planning for and delivering these items. If you have any questions, comments or suggestions about this document, please feel free to post to the onos-dev mailing list.
How You Can Help
As an open source project, we welcome contributions from anyone in the community. You are welcome to 'scratch your own itch' and contribute any new feature, bug fix or other contribution that you are interested in. If you're excited about what we're planning for future releases and would like to help get these improvements out more quickly, you are also welcome to join our planning process and work on items on our roadmap.
Roadmap at a Glance
Some major items on our roadmap that you can help with include:
Dynamic Configuration - provide support for configuring devices and network-wide services via YANG model-driven interactions where YANG models can be discovered or registered at run-time
Virtualization - enable use of ONOS as a network hypervisor through the creation of SDN capable virtual networks; networks whose connectivity can be programmed by applications as if they were physical SDN networks
GUI v2.0 - enhance the web UI to improve its usability on large-scale networks via region-based topology views with drill-down, context sensitive help, and global search
Deployments - enhance the existing Intent subsystem to enable ONOS to be deployed in networks around the world by providing the required layer 1-3 functionality
Intent v2.0 - re-design the intent framework to optimize scale and performance, enable conversational style feedback for error resolution on intent install, and add support for domain specific intent definitions and installation
P4 - support awareness of P4 programs including ability to deploy them, and facilitate applications to interact with the program-specific abstractions and controls
Disaggregation of ONOS code-base - separate the network-agnostic distributed applications platform from the network-aware core subsystems
In-Service Software Upgrade - design a mechanism for upgrading ONOS cluster without requiring downtime of control functionality where nodes can be upgraded one at a time
gRPC APIs - provide an efficient API to enable off-platform applications to have access to fine-grained control functionality and to allow off-platform applications to be written in languages other than Java
Federation - provide coordination mechanism for multiple ONOS clusters using either peer-to-peer or hierarchical arrangements to facilitate interactions between different administrative domains
Build & Package infrastructure - tools and processes for building ONOS and publishing the artifacts
OpenFlow 1.5 - upgrade libraries and providers to take advantage of the OF 1.5 protocol and updated libraries
LISP - continue adding support for LISP as SB protocol
Internationalization/Localization (I18N/L10N) - develop a framework for localization of the GUI and produce a set of localized message bundles
- ECOMP/MANO/Open-O Integration - integrations with various orchestrator platforms
We also maintain a set of 'bounty bugs' in JIRA that are issues we want in upcoming releases but don't have owners assigned to them yet. Please feel free to take one of those and we'll be happy to thank you with ONOS swag after completing those tasks.
Motivations
The following are the high-level drivers/requirements which determine the priority of the major initiatives shown above.
Dynamic Configuration
AT&T, Verizon, partners are requesting ability to configure devices using a model-driven approach that somewhat mimics the ODL MD-SAL approach
AT&T wants off-platform apps to drive device configuration and service configuration via RESTCONF at the NB
Generic request to support device configuration via YANG/NETCONF
Virtualization
Verizon, SKT want support of network “slicing” via virtual networks for MCORD
Operators need to support IaaS (like MVNO in the mobile world) - being able to share their infrastructure with other operators. There is not yet a driving partner/use case for this but it has been stated by multiple operators.
Users of OVX (mostly research) want support for SDN capable virtual networks
GUI Scalability
Improve ability to demonstrate use-cases by removing the limitation of showing only one topology layout for the entire network
Generic request to improve usability of visualizing large networks
Deployments
ubiquitous
Intents v2.0
Internal/TST: Address several known limitations of existing intent framework, e.g. lack of conversational API, lack of intent stackability, domain-specific intents
E-CORD: Use same intent primitives in both packet and optical segments of the network, while providing different low-level handling as appropriate for the different regions of the network.
P4
As we show leadership in delivering the promise of SDN - programmable networks - it is important for us to be aligned with and be a first supporter of programmable data planes. We do not have the operator driving a use case yet, so this is purely engineering leadership driven.
In-Service Software Upgrade
Generic request to allow ONOS deployments in production environments where loss-of-control for off-line upgrade is not acceptable
gRPC
Generic request to allow development of ONOS off-platform apps written in other languages
Federation
No active operator requests for federation. It seems federation is assumed to be at the orchestration layer. There is mainly research interest.
Disaggregation of ONOS code-base
Internal/TST: Better scale code contribution process and project lifecycles
- Internal: Better support building & packaging different flavours of ONOS