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&revision=2017-03-24&features=pure-ethernet,hybrid-microwave</capability>
- <capability>urn:ietf:params:xml:ns:netconf:notification:1.0?module=notifications&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
3 Comments
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?
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
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
As example here log with start of collector and showing the received heartbeat message:
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.