Overview

Process disaggregation in relation to ONOS is the separation of ONOS into multiple processes such that capabilities can evolve, test, scale, and fail independently. This represents a transition from the existing model where everything is executing in a single process space although they are logically separated using the Karaf/OSGi technology.

Boundaries

Process disaggregation implies that there are process boundaries over which communication must happen in order for a solution to meet customers' needs. The interfaces between these boundaries need to be considered in terms of granularity and latency. For example, a provisioning interface that calculates which flows need to be pushed to a device and that is executed in frequently has different requirements from an interface used for reactive decisions in the data path.

The layered architecture of ONOS still holds and has value in terms of process disaggregation, and some of those layer boundaries will likely represent process boundaries. It is likely the ONOS project can learn from the example of the vOLTHA project in terms of the process boundaries to support adaption to devices via multiple protocols.

Over Simplified

From an over simplified perspective the disaggregated ONOS might look something like this image. Things like security/trust are left out, but need to be part of the picture. This would represent a simple deployment, perhaps something like a lab trial. Key aspects would be:

• All boxes are separate processes (containers?)
• The flow API is essentially a translation from the the system API to adapted to the correct adapter for the target device. Thus some level of mapping between the two are needed
• The flow API essentially something like flow objectives, i.e. a relatively simply model to which all managed switches must comply (still need to figure out legacy)
• There can be several protocol adaptors for APIs, including CLI (SSH)
• Higher level concepts like Intents, VTN, etc are implemented as apps and external processes that leverage the other components via APIs
• Application needs a way to surface their UI and APIs through the common UI and API services
• Left out of the picture is some level of message bus which will be needed for async events, monitoring, etc.
• Left out of the picture is UI, which will be another processes that utilizes the API.
  • As each app will likely augment a common topology, table, display, etc understanding how to manage that and present from a single container (proxying to the app specific stuff?) needs to be studied

Scaling Up (but still over simplified)

When scaling up in this scenario you can replicate groupings of processes (containers) at a location and provide a hierarchical solution, or move toward a model where it is a peer relationship and a coordinator (distribution) process is shared between instances. In short there are various ways to support HA / scale based on the containers being deployed in a given scenario.

Nothing So Far is Specific to Process Disaggregation

That is true, you could do most of this stuff while maintaining the single process model. Where that becomes not true is when you apply the following:

• Each component could be written in a language that best meets the needs of the component: Java, Python, Go, C++, Erlang, etc.
• You could scale each component independently, so that if you need more adaptors for a specific vendor at a site you can scale just that
• Failure isolation, if an adaptor fails you don't lose the entire system, restart the adaptor in a known good state
• Each component could be release independently on different schedules

Complexity

There is an inherent complexity as you move toward an environment such as this. This can be somewhat eased by the use of containers and technologies like Docker Swarm, Kubernetes, Mesos, etc. as they provide concepts on deploying a group of containers as an single app, dependencies between those containers, and the ability to scale the set of containers in various ways. 

It should still be the goal to be able to start the controller with a simple command such as `docker-compose -f onos-compose up -d` as an example using Docker. once up you should be able to `ssh` or browser to the controller much like you can today.