Roadmap

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, we encourage you to work with us to accelerate these roadmap items.

Roadmap at a Glance

Thomas Vachuska presented information about the 2017 ONOS roadmap at the ONOS Build event in Paris in November 2016.

The major items on the roadmap are below.  For more details about each item, please scroll down the page.

• 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

Initiatives

The following are high-level narratives describing the use-cases and features comprising the various ONOS platform initiatives. After each narrative is also the proposed breakdown of work into buckets that are scoped to fit inside a single release and that illustrate the progression towards the goal set for each initiative. Each of these buckets will be tracked as a JIRA Epic within an ONOS release.

Dynamic Configuration

Provide a YANG model-driven configuration architecture to enable declarative data and service definitions.  This work would encompass an auto-generated RESTCONF NB, a distributed tree-based datastore in the Core, and a vendor agnostic SB that would enable ease of interactions with NETCONF devices.  It will leverage the YANG Utils and YMS work previously contributed to enable parsing of the YANG definitions to provide auto-generated Java constructs.

Phase 1: Target ONS 2017 (April, 2017) - Demo 1, Demo 2

Ibis

• APIs definitions for YANG Compiler, YANG Runtime, and Dynamic Config subsystem

Junco

• Refactoring & code restructuring: YANG Compiler, YMS -> YANG Runtime,

• Implementation of Dynamic Config subsystem (including store & RPC dispatch)

• Implementation of RESTCONF & NETCONF Apps

• Sharding of subtrees will be opportunistic

Phase 2: Demo 3 (Multi Vendor Device)

"K"

• Sharding of subtrees

• Transactional updates

• Performance optimizations

             “L”

• Driver model based on Behaviors

Demos

Demo 1: Single vendor’s device configuration

• The configuration of devices by supporting arbitrary device models.  Shows that framework can digest any device model and allow configuration via a NB.  Does not provide multiple vendor device abstraction support via NB.

• Demonstrate:

• Ingestion of arbitrary device models

• Support for distributed persistence (sharding of device data on device mastership)

• Support configuration & operational data/subtrees

Demo 2: Single service on single vendor’s device configuration.

• The initial thought on service is L3VPN.

• Demonstrate

• Definition of service via a YANG model

• Installation of application that supports that model

• Interacting with application using RESTCONF

Brigade

There is an active brigade around this roadmap item.  See the Dynamic Configuration Brigade wiki page for more details.

Virtualization

Virtualization focuses on enabling the creation of SDN capable virtual networks, allowing them to fully participate in control plane policies with southbound abstractions optimizing application to the physical topology.

Use Cases

1. Creating virtual SDN networks for tenants

2. Slicing regions of networks for use by different tenants (M-CORD)

3. Federation - exposing abstracted view to peer/parent controllers (E-CORD)

Ibis

• Initial implementation of a virtual network, leveraging existing virtualization APIs.

• Incubate OF as the first realization of a southbound implementation of a VN.

Junco

• Complete support of OF as the first realization of a southbound implementation of a VN.

• Support OF agent as NBI for external controllers

K

• External connectivity (e.g. Internet) for VNs

• Add support for virtual network pausing and snapshotting to enable backup and restore of a VN.

• Support virtual network embedding to allow the user to define a general structure of a vnet without specifying how it maps to the underlying network. This floating structure then needs to be embedded/mapped onto the underlying network before the vnet can be realized. This can be done either manually or computationally based on the current structure/utilization of the underlying network.

• Openstack integration - adapting the Neutron APIs to the Virtual Networks APIs

L

• Support additional southbound implementations of a VN.

• Virtual network resilience

Brigade

There is an active brigade around this roadmap item.  See the Virtualization Brigade wiki page for more details.

GUI v2.0

GUI 2.0 will provide enhancements to the WebUI to support enhanced scale and usability via region-based topology views, context sensitive help, and global search.  Additional incremental changes will be made to improve overall user experience.

Ibis

• Implementation of Region-aware Topology View (basic functionality: regions / devices / links / hosts)

• Plan is to have T1 and T2 coexist for a period of time so that application developers have time to migrate such things as topo overlays.  

• Added functionality to Intents View (resubmit withdrawn intent / purge withdrawn intents)

• Supports the ability to withdraw intents as of the Hummingbird release.  Adding addition actions of re-submitting and purging of intents.

• Enhance existing table views -- Details panel for selected items

• Migrate the following tables:

• Flows view

• Cluster view

• Context sensitive help button

Junco

• Region-aware Topology View -- reinstatement of Traffic Overlay

• Enhance Intent table with detailed panel for selected item

• Keyboard navigation of tables (up/dn arrow selection)

• Reimplement “dark” theme

• Pending graphic designer to put together a color palette

• Dark theme was available previously, but disabled in Hummingbird pending redefinition of palette

• Investigate design for indexed-global-search subsystem (GUI, CLI, REST)

K

• Implement Partitions View (visualization of cluster partitioning)

• Implementation of the indexed-global-search subsystem

NOTE: The WebUI is intended to be tool that provides read-only/limited config feature state/preview, not intended to be parity with CLI

Brigade

 There is an active brigade around this roadmap item.  See the GUI Brigade wiki page for more details.

In-Service Software Upgrade

• Mechanism for gradually upgrading an ONOS cluster

• upgrades cluster one node at a time without downtime

• Requires portable serialization for cluster comms

• upgraded nodes must be able to speak the “old” language (possible dependency/relationship on gRPC)

gRPC APIs

• Allow fine-grained & high-performance interactions between ONOS and off-platform apps

• presently available only for on-platform apps via Java API

• REST API suitable only for relatively low-frequency & coarse interactions

• Enables apps to be run on or off platform

• permits compute resource isolation

• off-platform apps as micro-services

• Allows ONOS apps to be written in other languages

Federation

• Coordination mechanism for multiple ONOS clusters

• permits peer-to-peer & hierarchical arrangements

• aims to support different administrative domains

• Peer-to-peer variant being developed by GEANT

Deployments

The goal of the deployment brigade is to create a concrete stack of software that can be deployed in networks, around the world. The stack would provide Layer 1-3 functionalities, convergence of packet-optical resources, compatibility with the MEF standards for the allocation and management of Layer2 VPNs, compatibility with the NSI framework - commonly used by RENs for multi-domain resource provisioning.

Ibis

• SDN-IP + VPLS integration

• ProxyARP re-design (NeighbourHandler service)

• Create new VPLS to support connection of interfaces using different VLAN IDs

• Integration of SDN-IP and VPLS with new NeighbourHandler Service

• Support in VPLS for untagged interfaces (meaning access ports / physical ports)

• Support for encapsulation in VPLS

Junco

• New VPLS CLI

• Introduce bandwidth reservation mechanism in the resource manager

• Introduce bandwidth reservation mechanism in the intent framework

• Introduce bandwidth reservation mechanism in VPLS

• Encapsulation support in SDN-IP

• Integrate BoD (for NSI support) into the stack

• Integrate SDN-IP and VPLS with PacketOptical (PoC)

K

• Integrate MEF standards into VPLS

• Dependencies on Kostis - from Huawei, Marc and Yuta

• Let VPLS connect multiple E-CORD sites

• Depends on the epic above

Brigade

 There is an active brigade around this roadmap item.  See the Deployments Brigade wiki page for more details.

Intent v2.0

Intent 2.0 will focus on enhancing 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.

List of specific requirements from Packet/Optical and E-CORD initiatives:

• Decompile phase: intents right now get compiled, but when we remove them there is no decompilation, needed to clean up (most notably, release resource reservations)

• Domain-specific intents that do not compile into flow rules but can be used to drive networks where we don’t control devices but talk to a NMS (network mgmt system)

• Consumable/layered intents: intent compilation should not just try to install, but try to re-use existing intents with available resources (see next item). We also need to track parent to child and vice versa relationships.

• Bandwidth/resource tracking for intents: intents should track which and how many resources they are consuming on their parent

• Transactional behavior: if flow installation on a single device fails, stop trying and remove all other intents (roll back)

• Protected intents: don’t try to recompile, the device will try recovery. For this we also require an additional intent state

Work on Intent v2.0 was deferred in Ibis to focus on enabling dynamic configuration.  Incremental additions to the Intent framework is occurring due to dependencies from Deployment, such as:

• Support multiple selectors and treatments for multi-point intents

• Support of encapsulation in multi-point intents

• Convergence of compilers (for h2h, p2p, sp2mp, mp2sp) to a unique compiler: LinkCollectionIntentCompiler

• From sp2sp, sp2mp, mp2sp intents to a unique intent type: mp2mp intent

• BW tracking and enforcement

Disaggregation of ONOS code-base

• Separate the distributed network-agnostic platform from the network-aware core subsystems

• presently the separation is logical, but there exist some (albeit weak) ties between the two

• Separate contributing projects into their own repositories

• provides basis for various flavours of ONOS

• provides basis for better scaling ONOS code-base which also spans various contributing projects

• Requests for such platform from Fermi & Oakridge Labs, among others

• provides significant benefits in context of SDN as well