Versions Compared

Key

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

Table of Contents

Table of Contents

The SDN-R Websocketmanager is a server which a client can connect to, to receive NETCONF notifications forwarded by the the devicemanagers. To get rid of all old protocol issues we redesigned all the messages.


The user scope registration

This is a full example of a registration for notifications of a specific type. In this case all problem-notification notifications of the node with the node-id node1 implemented in the microwave-model@2018-10-10.yang.

Code Block
{
  "data":"scopes",
  "scopes":[
    {
      "node-id":"node1",
      "schema":{
          "namespace":"onf:params:xml:ns:yang:microwave-model",
          "revision":"2018-10-10",
          "notification":["problem-notification"]   
       }
    }
  ]
}

In fact there are a lot of use cases to receive a lot of different notifications or specific notifications for a bunch of nodes, most properties are optional

propertyoptionaldescription
node-idyesfilter for notifications only from node with node-id
schemayesfilter for specific notifications implemented by a model
schema.namespacenoif schema is set, namespace has to be set, otherwise a schema is not valid
schema.revisionyesfilter for a specific revision of the implemented model
schema.notificationyesfilter for specific notification types of the model
ratioyesmaximum of notifications per minute to receive (format: "[num]/min")

If the user scope registration succeeds you will get a response with your submitted scopes

Code Block
{
  "status": "success",
  "scopes": [
    {
      "node-id":"node1",
      "schema":{
          "namespace":"onf:params:xml:ns:yang:microwave-model",
          "revision":"2018-10-10",
          "notification":["problem-notification"]   
       }
    }
  ]
}

If not you will receive an error message with the cause, e.g.

Code Block
{
  "status": "error",
  "message":"unable to parse scopes"
}

User scope registration examples

Example 1: All notifications for node-id:

Code Block
{
  "data":"scopes",
  "scopes":[
    {
      "node-id":"node1"
    }
  ]
}

Example 2: All notifications for node-id for all yang-models:

Code Block
{
  "data":"scopes",
  "scopes":[
    {
      "node-id":"node1",
      "schema":{
          "namespace":"*" //no placeholder
       }
    }
  ]
}

Example 3: All notifications(every node) for all yang-models:

Code Block
{
  "data":"scopes",
  "scopes":[
    {
      "schema":{
          "namespace":"*" //no placeholder
       }
    }
  ]
}

Example 4: All notifications(every node) implemented in microwave-model:

Code Block
{
  "data":"scopes",
  "scopes":[
    {
      "schema":{
          "namespace":"onf:params:xml:ns:yang:microwave-model"
       }
    }
  ]
}

Example

...

5: All notifications(every node) of type problem-notification of microwave-model:

Code Block
{
  "data":"scopes",
  "scopes":[
    {
      "schema":{
          "namespace":"onf:params:xml:ns:yang:microwave-model",
          "notification":["problem-notification"]   
       }
    }
  ]
}

Example

...

6: All notifications(every node) of type problem-notification of microwave-model@2018-10-10:

Code Block
{
  "data":"scopes",
  "scopes":[
    {
      "schema":{
          "namespace":"onf:params:xml:ns:yang:microwave-model",
          "revision":"2018-10-10",
          "notification":["problem-notification"]   
       }
    }
  ]
}

Example

...

7: All notifications for node-id of type problem-notification of microwave-model@2018-10-10:

Code Block
{
  "data":"scopes",
  "scopes":[
    {
      "node-id":"node1",
      "schema":{
          "namespace":"onf:params:xml:ns:yang:microwave-model",
          "revision":"2018-10-10",
          "notification":["problem-notification"]   
       }
    }
  ]
}

Notifications

A notification has the following structure

Code Block
{
  "event-time": "2021-03-12T05:08:55.3Z",
  "type": {
      "namespace":"urn:opendaylight:params:xml:ns:yang

...

:devicemanager",
      "revision":"2019-01-09",
      "type":"object-creation-notification" 
  },
  "node-id": "SDN-Controller-0",
  "data": {
    "object-id-ref": "sim1",
    "counter": 7,
    "time-stamp": "2021-03-12T05:08:55.2Z"
  }
}


Properties:

propertydescription
node-idnode-id which is the source the notification
event-timetimestamp of the notification
type<namespace>@<revision>:<notification-type>
datanotification itself


OSGi-Service

Inside the opendaylight container the websocketmanager does not implement a yang-generated RPC anymore. Instead ther is nor a more simplified and more generic interface to submit notifications to it.

Code Block
public interface WebsocketManagerService {

    /**
     * Send notification via Websocket to the connected clients.
     * eventTime is extracted out of notification if {@link #EventInstantAware } is implemented
     * @param notification
     * @param nodeId
     * @param eventType
     */
    void sendNotification(Notification notification, String nodeId, QName eventType);
    /**
     * Send notification via Websocket to the connected clients.
     * @param notification
     * @param nodeId
     * @param eventType
     * @param eventTime
     */
    void sendNotification(Notification notification, String nodeId, QName eventType, DateAndTime eventTime);

    /**
     * Send notification via Websocket to the connected clients.
     * @param notification
     * @param nodeId
     * @param eventType
     */
    void sendNotification(DOMNotification notification, String nodeId, QName eventType);
    /**
     * Send notification via Websocket to the connected clients.
     * @param notification
     * @param nodeId
     * @param eventType
     * @param eventTime
     */
    void sendNotification(DOMNotification notification, String nodeId, QName eventType, DateAndTime eventTime);


Notification Rate Limitation

In fact that this interface is also used to provide notifications for a Web-UI like ODLUX and a large amount of notifications can result in a inresponsive UI, there has to be an option to reduce the ratio of notifications per time unit that wanted to be received with the knowledge that this can result in lost notifications for the websocket client. For ODLUX it's not that big problem, because all notifications are also logged in the database and are only lost for live popup notification.


So we like to extend the user scope registration message with an additional property

Code Block
{
	"data":"scopes", 
	"scopes":[ 
	{ 
		"node-id":"node1", 
		"schema":{ 
			"namespace":"onf:params:xml:ns:yang:microwave-model", 
			"revision":"2018-10-10", 
			"notification":["problem-notification"] 
		} 
	}],
    "ratio":"120/min" 
}

So from this point of view it is basically a server side implementation.

Additionally there will be a notification (yang-spec) specified which will be send once a to be specified time frame which tells how much notifications were not send if at least one was not send.

Code Block
{
  "event-time": "2021-03-12T05:08:55.3Z",
  "type": {
      "namespace":"urn:opendaylight:params:xml:ns:yang:websocketmanager",
      "revision":"2019-01-09",
      "type":"items-dropped-notification" 
  },
  "node-id": "SDN-Controller-0",
  "data": {
    "amount": 10
  }
}

Of course only sent, if you registered for this scope