The initial thrust of software-defined networking was to allow software to affect what the network does, primarily in order to increase the rate of innovation. It was not really about how to operate the network, assuming that the classic network management solutions would suffice for this.
It was envisioned that to do that, the control plane should be detached from the data plane and a “language” created to facilitate conversations between the centralized control plane and the data plane devices themselves; language here being OpenFlow protocol. This was generally the spirit in which the ONOS controller platform was developed.
Of course, it was recognized by the ONOS team that, unlike for the existing NMS-based solutions, it was far more critical for the controller to remain available and to maintain good performance; hence the distributed architecture of ONOS that provides a logically centralized, yet physically distributed control platform. Also, it was recognized early on that some layers of adaptations were required as there were multiple versions of OpenFlow, and more critically, there were differences between the devices in how they implemented various OpenFlow features.
Control
Of course, different devices also structured their table pipelines in unique ways, depending on the target market or intended placement within the network. The control platform, and ultimately the control applications, were then exposed to these differences and, without any means to prescribe the structure of the pipeline, were left to cope with them. The ONOS platform provided some level of isolation for apps in this regard by effectively introducing its own pipeline and offering an additional abstraction (Flow Objective) that together with the pipeline-specific drivers allowed apps to program the pipeline efficiently, but in a pipeline independent manner.
This certainly achieved its intended goal, but - as is the case with nearly everything - there are some drawbacks to this approach; there are additional layers of indirection in the entire system, and while the applications may have an air-cushioned ride, they also have lesser feel for the road, so to speak. The story changes dramatically however, with the ability to prescribe - or at least describe - the data-plane pipeline, which is what P4 offers.
Even though ONOS architecture pre-dates P4, the ONOS team was able to elegantly adapt and to extend the platform, thus giving applications the ability to program the P4-based devices using either pipeline independent (the “air-cushioned ride”) approach or pipeline-specific (the “sport ride”) approach. We are happy with how this turned out - and you can see different demonstrations of this for yourselves - but we are seeing even more opportunities to further exploit the capabilities provided by P4 and P4Runtime… and this is one place where µONOS - the evolution in the ONOS architecture - comes in.
With µONOS, the control subsystem of ONOS is shifting towards native support of P4/P4Runtime. This will allow applications and solutions to achieve hardware independence, and at the same time provide a more direct and stronger connection to the actual device capabilities with fewer intervening adaptive abstraction layers. While this will offer the greatest benefit for devices with programmable (prescribed) data-plane, it will work quite well even with devices whose data-plane can be merely described via P4.
µONOS, being based on micro-services, will offer P4Runtime proxy interface as its northbound to allow applications (also running as micro-services or external entities) to program network-wide pipeline. We intend to extend the existing P4 toolchain to generate language artifacts and APIs that will allow application developers to program pipe-line specific apps with ease - especially when coupled with IDEs (such as GoLand) that offer API-sensitive auto-completion. This will not only make app development simpler and faster, it will also make it safer because the structure of the pipeline-specific programming constructs can be validated at build-time rather than at run-time.
Of course, µONOS will continue the tradition of the ONOS brand and allow adapters to continue to program the data-plane using OpenFlow or any other southbound protocols. This shift is merely a re-calibration of the APIs and abstractions to center them on what we fully expect to become the norm in the not-so-distant future - a fully programmable data-plane.
Configuration and Monitoring
Thus far, we described how the ONOS controller carried forward the original vision of the SDN forwarding plane and on how we plan to take it into the next generation. However, that is merely one part of the story; an important part to be sure, but just a part nonetheless.
Developing and deploying SDN solutions into production provided everyone a clear reminder that there are other critical aspects involved in setting up a network, maintaining it and evolving it; aspects which are as critical as allowing control over the forwarding: configuration, monitoring, verification, and zero-touch provisioning in general.
While ONOS today allows configuration of devices using various means, including NETCONF, RESTCONF and gNMI (and in compliance with YANG models, such as OpenConfig), there are some capabilities that are lacking. Among these are atomic multi-device configuration, rollback capabilities, and network-wide configuration validation, such as making sure that peer ports are configured in a compatible manner. To remedy these limitations and to position ONOS better to offer applications with the means to both affect the forwarding plane and to configure it, the µONOS architecture upgrade is shifting to native support of gNMI as a northbound proxy interface for network-wide configuration.
This shift allows ONOS configuration subsystem to focus on maintaining a version history of device configurations, with proper validation using compiled YANG models, augmentations and deviations specific to each device, yet in a network-wide context. It also gives application developers the option to use languages of their choice with support from an open-source ygot and pyang toolchains.
Of course, the principal models emphasized by ONOS will be OpenConfig and IETF, but any other models supplied by the vendors are supported just the same. It is up to the applications and orchestrators that engage in configuration activities to understand the vendor specific models and to make sure that configuration changes result in a coherent network behavior.
Among the many benefits of using gNMI is that it allows for very efficient means of gathering telemetry and state data from the devices via its subscription mechanism. Similarly, on the northbound, it gives the applications interfacing with the ONOSwith ONOS configuration subsystem the means to learn the state changes within the network in an efficient, timely manner.
So in this way, ONOS will provide the applications with an encompassing repertoire of means to engage with the network: to configure the network devices, to shape and program their forwarding plane, and to efficiently monitor their operation. This will allow a new crop of applications and use-cases to be built.
Zero-Touch Provisioning and Network Operation
One such application is a zero-touch provisioning app that can apply initial configuration and P4 prescribed pipeline onto newly added network devices in accordance with their intended role in the network.
Similarly, to facilitate smooth network operation, solutions should be provided for dealing - in an automated way - with scenarios such as taking a misbehaving device off-line or adding new devices to the existing network topology. Such solutions will require access to both control and configuration operations so that they can divert the flow of traffic away from the problem device and then isolate the device by disabling ports or reconfiguring a replaced line-card before re-introducing the device into the network.
These are just a few examples of network aware orchestration that operators have been vying for and that will be made possible with the next generation ONOS platform. By increasing the level of automation and reducing the need for manual interference, network operators will be able to reduce their operational expenses and scale their operations much more efficiently.
Zero-Touch Provisioning of ONOS
ONOS and apps can be provisioned using established toolchains such as Kubernetes, Helm Charts, etc. It means that ONOS and apps can be seamlessly orchestrated as parts of a larger solution, e.g., SD-RAN/SEBA/VOLTHA/Trellis/ONOS… in a modular and easily tailored manner.
Depending on the needs of a particular deployment, various parts of the ONOS-based solution can be scaled out appropriately to cope with the various work loads. The off-the-shelf capabilities of Kubernetes can provide monitoring and safeguarding of each separate component, providing on-demand scaling of services, monitoring of operation, restart on failure, and rolling upgrade capabilities… all within a well established and well-documented set of tools.
Furthermore, by being cloud-native, ONOS deployments can be hosted not only in private cloud, but also in various public-cloud offerings, such as Google Cloud or EC2, among others.
Example of µONOS deployment
Summary
The µONOS project represents another step in the evolution of the platform by making ONOS and its applications even easier to orchestrate, to operate, and to integrate with the existing operator ecosystems. It does so by adopting the latest established toolchain and proven technologies, e.g., Kubernetes, Helm, Golang, and gRPC. µONOS also continues to carry the next-generation SDN flag even farther up the field by providing native support for gNMI, gNOI and P4Runtime, among others. And as always, the platform will continue to carry the standard for great performance, high-availability, and scalability that was established by the ONOS brand.
