SDN-R is able to handle NetConf notification from connected NetConf Servers. To receive NetConf notifications a mountpoint object (network-topology/netconf/node) must exist in MD-SAL and its (clustered-)connection-status must be "connected".

There are in prinipal two ways to create a mountpoint within MD-SAL:

  • via a NetConf or RestConf message
  • via NetConf-Call-Home

The deviceManager component on SDN-R is listening to the connection-status changes for NetConf mountpoints. If the connection-status changes to "connected" the NetConf create-subscription message for netconf notifications is send to the NetConf-server. From now on the NetConf client service is sending NetConf notifications to SDN-R (ODL) devicemanager listener. Every listener on NetConf Notification for this NetConf-Server will trigger the specific handler to process the message.

There are two ODL Listerner interfaces used by devicemanger:

  • ODL Netconf Client related 
    • After subscription of NetConf notification stream for mountPoint, using org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.netconf.notification._1._0.rev080714.NotificationsService, notifications are forwarded to the listener.
    • Related interface class: org.opendaylight.yang.gen.v1.urn.onf.params.xml.ns.yang.microwave.model.rev170324.MicrowaveModelListener extends org.opendaylight.yangtools.yang.binding.NotificationListener extends java.util.EventListener
  • ODL MDSAL DataTree related
    • After regsitration of the listern, all Data Tree changes of related elements are forwarded to the listerner.
    • Object id for nodes is specified like this: 
      private static final InstanceIdentifier<Node> NETCONF_NODE_TOPO_IID = InstanceIdentifier
       .create(NetworkTopology.class)
       .child(Topology.class, new TopologyKey(new TopologyId(TopologyNetconf.QNAME.getLocalName())))
       .child(Node.class);

    • Related interface class: org.opendaylight.controller.md.sal.binding.api.ClusteredDataTreeChangeListener<Node>

The PNF NetConf Server needs to support capabilites to provide notifications. The related YANG specs are: 

  • <capability>urn:onf:params:xml:ns:yang:microwave-model?module=microwave-model&amp;revision=2017-03-24&amp;features=pure-ethernet,hybrid-microwave</capability>

  • <capability>urn:ietf:params:xml:ns:netconf:notification:1.0?module=notifications&amp;revision=2008-07-14</capability>

Websocket (WS) based notifications, are provided by different services.

  • Via port 8185 the ODL MDSAL DataTree offers a WS service for changes in the DataTree, like Creation/Deletion/Change of a mountpoint.
  • Via port 8085 the 

NetConf-Notification-Handling


  • No labels

3 Comments

  1. Damian Nowak

    Question to the last line (interaction) in the sequence diagram "Forward event as VES".
    Is there any reference available, how that VES event looks like? Any example Header + body? Which domain is used? Anything?

  2. Herbert Eiselt

    Here a reference to further information regarding VES: https://wiki.opnfv.org/display/ves/VES+Home

    Here an answer for SDN-R Implementation:

    Using the collector as test entity: https://github.com/att/evel-test-collector 

    • with script "~/odl/evel-test-collector/scripts/linux/go-collector.sh
    • Configuration adapted in "evel-test-collector/config/collector.conf" for last lines to provide credentials:
    • vel_domain = 127.0.0.1
      vel_port = 30000
      vel_path =
      vel_username = admin
      vel_password = admin
      vel_topic_name =

    Related configuration in SDN-R is here $ODL_HOME/etc/devicemanager.properties

    [dcae]
    dcaeUrl=http://192.168.178.164:30000/eventListener/v3
    dcaeUserCredentials=admin:admin
    dcaeHeartbeatPeriodSeconds=120

    As example here log with start of collector and showing the received heartbeat message:

    herbert@devherbert:~/odl/evel-test-collector/scripts/linux$ ./go-collector.sh 
    Logfile: ../../logs/collector.log
    Verbose mode on
    Registering for GET at /eventListener/v3
    Registering for POST at /eventListener/v3
    Registering for GET at /eventListener/v3/clientThrottlingState
    Registering for POST at /eventListener/v3/clientThrottlingState
    Registering for POST at /testControl/v3/commandList
    Registering for GET at /testControl/v3/commandList
    Serving on port 30000...
    ==== Fri Jul 12 19:10:24 2019 =================================================
    Valid JSON body (no schema checking) decoded:
    {
    "event": {
    "commonEventHeader": {
    "domain": "heartbeat",
    "eventId": "testpattern-ab305d54-85b4-a31b-7db2-fb6b9e546015",
    "eventName": "heartbeat_Controller",
    "eventType": "Controller",
    "lastEpochMicrosec": 360782828936,
    "priority": "Low",
    "reportingEntityId": "",
    "reportingEntityName": "sdnr",
    "sequence": 0,
    "sourceId": "",
    "sourceName": "sdnr",
    "startEpochMicrosec": 360782828936,
    "version": 3.0
    },
    "heartbeatFields": {
    "additionalFields": [
    {
    "name": "eventTime",
    "value": "2019-07-12T17:10:24.7Z"
    }
    ],
    "heartbeatFieldsVersion": 1.0,
    "heartbeatInterval": 120
    }
    }
    }
    Authenticated OK
    172.18.0.2 - - [12/Jul/2019 19:10:24] "POST /eventListener/v3 HTTP/1.1" 202 0

  3. Damian Nowak

    Herbert Eiselt Thanks a lot for that example of HeartBeat!
    What I noticed there is, that Event Listener v3 is used. It might make sense to update to v5 - or even better -to v7 (corresponds to VES 7.x spec).

    There might be some additional features and domains defined in v7, which would support those VES mappings better, than with v3.