Table of Contents

Overview

This section provides an overview on the NETCONF protocol implementation in ONOS.

Interfaces and Classes

• NetconfController.java, implemented by NetconfControllerImpl.java: tracks all the NETCONF devices, serves as a one stop for connecting and obtaining a device and (un)register listeners on device events.

• NetconfDevice.java implemented by NetconfDeviceImpl.java: represents a NETCONF capable device connected to the ONOS core with his own NetconfSession and his informations saved in an instance of NetconfDeviceInfo
• NetconfSession.java: interface that every type of transport connection to a NETCONF device must implement, represents the single access point for any operation on the device. An example is NetconfSessionImpl: uses an SSH2 Connection and Session to exchange information and perform operations like get/set-config with the physical NETCONF device.
• NetconfDeviceProvider.java: manages any NETCONF device role and all the interactions with the ONOS core.
• NetconfDeviceListener.java implemented by InnerNetconfDeviceListener.java in NetconfDeviceProvider: informs the provider in the ONOS core that a NETCONF device is connected/disconnected.
• NetconfDeviceInfo.java: contains ip,port,protocol,username,password and DeviceId of a NETCONF device; it's used to exchange information about a device without having to pass the device instance itself.
• XMLConfigParser.java: parser for reading and producing XML files to and from the NETCONF device. For now has only configuration reader and edit controllers configuration producer.

Example: Get and Set Controllers.

An example of NETCONF infrastructure usage is getting and setting controllers on a device. These operations are defined in an ONOS Behaviour, in our case the NetconfControllerConfig.java, that implements ControllerConfig general behaviour. To do in the Behaviour you are creating the operations on the devices, you need the NetconfController, which you can obtainthorugh the DriverHandler. The NetconfController instance now gives you access to all the device or a single device. Once you have the device you are interested in based upon the deviceId you provide you can get the NetconfSession object to comunicate with the device and do operations on the physical device, getting the configuration in case of the get controllers or setting a pre-built new one for the setControllers. XmlConfigParser.java offers a method to extract the wanted information from an XML configuration received from the device and another method to produce the correct XML to set one or more controller on a specific device.

You can take a look at the acutal implementation of the get and set controllers operation in the NetconfControllerConfig.java class. For an example of other operations that can be implemented the OVSDB infrastructure provides a good starting point.

To call the getControllers and setControllers methods you need to obtain the ControllerConfig Behaviour nad then call on this instance the methods. The set and get commands are implemented, as an example, in DeviceControllersNetconfCommand.java and DeviceSetControllersNetconfCommand.java that provide, in two CLI commands

onos> device-controllers-netconf 

onos> device-setcontrollers-netconf

Testing infrastructure

To test locally (not on real switches) the NETCONF implementation you need the Mininet machine with of-config installed (link to mininet machine). of-config is wrapper for an openvswitch instance, that uses NETCONF protocol and translates it to OVSDB protocol in order to use that database implementation. 

Infrastructure Setup:

• Start the Mininet machine with of-config installed under Virtual-Box
• start ONOS

• activate the netconf app :

  onos> app activate org.onosproject.netconf

• specify to ONOS that we are using netconf devices:

  $ onos-topo-cfg localhost ~/onos/tools/test/topos/ofc-netconf.json

• call the command or run the app you have written

Future Work

There is much room for improvement and testing, this is only a basic skeleton of the infrastructure. The improvement should be focused on extracting the XML out of the NetconfSessionImpl's methods and testing each operation. In the future the XML can be generated through YANG models.