Versions Compared

Old Version 1

changes.mady.by.user Simon Hunt

Saved on

compared with

New Version 2

changes.mady.by.user Simon Hunt

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

This page describes the proposed architecture for the ONOS Web UI to support "federated ONOS". Right now it is just capturing initial thoughts...

 

Web UI Connection Protocol

It is proposed that the Web UI is enhanced to implement a "connection protocol" after the establishment of the web socket connection to the ONOS controller. This is to allow the controller to inform the UI about the "mode" in which it is running.

Single Cluster Deployment

For a (traditional) single-cluster deployment the initial message exchange should look something like this:

UI --> controllerController –> UI
{
  "conn": "main"
}
 
 
{
  "deployment": "single"
}

The UI is informing the controller to which it is connecting that this is a "main" connection.

The controller is informing the UI that this is a "single cluster" deployment.

From here, everything else as before...

 

Federated Deployment

For a federation of ONOS clusters, (either hierarchical or peer-peer), the initial message exchange would look a little different.

Consider the following figure (connections between ONOS clusters and Uber controller not shown):

Image Added

 

First, (1), the UI informs the Uber controller (to which it is connecting) that this is a main connection.

The Uber controller responds that this is a federated deployment, and provides contact information for the other clusters.

UI --> UberUber --> UI
{
  "conn": "main"
}
 
 
{
  "deployment": "federated",
  "clusters": [
    {
      "name": "Cluster A",
      "ip": "10.0.21.1"
    },
    {
      "name": "Cluster B",
      "ip": "10.0.22.1"
    },
    {
      "name": "Cluster C",
      "ip": "10.0.23.1"
    }
  ]
}

 

Second, (2), the UI opens up web sockets to the controllers listed in the above exchange, informing each that they are an auxiliary UI connection.

The controller acknowledges the auxiliary connection.

UI --> Controller A|B|CController A|B|C --> UI
{
  "conn": "aux"
}
 
 
{
  "aux": "ok"
}

 

Modifications to existing UiWebSocket class

The UiWebSocket class would need to be enhanced to track the notion of whether the connection was MAIN or AUX. In this way, the UI resources / message handlers would be able to modify their behavior if needed.