Author: Arun

GSOC 2017 – Implement NetJSON output in ubus (OpenWRT/LEDE)

Posted on by Arun

About Me:

I am Arunkumar Ravichandran, about to pursue my MS in Electrical and Computer Engineering at University of California, San Diego. I have almost 2 years of Software Engineering experience at EmbedUR Systems in the Wireless networks domain. I was working on wireless device drivers implementing Network assisted roaming and SDN support for the Linux based Enterprise Access Points and Wireless LAN Controllers.

What I am going to do in GSOC:

The main aim of the project is to bring in support for NETJSON object in the LEDE/OpenWRT Linux distributions. The support for NETJSON is brought in at the interconnect system – ubus. In this project, we need to add support for a new ubus API which allows retrieving these two NetJSON object types: DeviceConfiguration and DeviceMonitoring.

What is NetJSON ?

NetJSON is a data interchange format based on JSON designed to ease the development of software tools for computer networks. This specification defines several types of JSON objects and the manner in which they are combined to represent a network: configuration of devices, monitoring data, network topology and routing information.

Why NetJSON is important to OpenWRT/LEDE ?

Network infrastructure is deeply closed source. Open source won the battle in web development and system administration, but not in network management. The status-quo in networking is closed source software, poor interoperability and poor documentation.
NetJSON aim to challenge the status-quo and improve the openness of internet infrastructure by offering a set of tools (like a framework) which communities and companies can use to build network infrastructure using mainly open source software products.

– Federico Capoano, OpenWisp

  1. NetJSON would allow standardization similar to NETCONF. Since NetJSON uses JSON format, it makes the management of configurations done at a higher scale to be automated easily.
  2. By using NetJSON objects to either produce or collect information, in different vendor’s different hardware, it allows the developers to work on their ideas faster and in a better way.

Project goals:

  • Bring CLI support to accommodate the new parameters: DeviceConfiguration and DeviceMonitoring.
  • Write backend ubus APIs to collect the data and store the data in NetJSON objects: DeviceConfiguration and DeviceMonitoring and display them.
  • Revisit the implementation of JSON plugin in SCAL and try to extend the support for NetJSON. For the missing data models in the JSON plugin, try to write a data parser which uses the scal APIs to get data and convert that into NetJSON format and store in the DeviceConfiguration NetJSON object for outputting it.
  • Adapt the code in node-watcher agent and reuse it in SCAL as a plugin. This plugin should output the monitoring data in a NetJSON DeviceMonitoring format..
  • Writing makefile to compile the files added for supporting NetJSON in the ubus IPC/RPC system in OpenWRT/LEDE distribution.
  • Document the work done, installation guide and usage examples of the new CLIs.

Project Details:

  • CLI support: The CLI should be able to input the required data and display error message if entered wrongly. Generic CLI: ubus call netjson <config | monitor> <general | network | interface | none_to_display_all> <parameter | none_to_display_all> Example CLI: ubus call netjson monitor interface eth0 .The above CLI would display all the statistics related to eth0 in the DeviceMonitoring NetJSON format. CLI depth should be increased for certain commands like the interface and network entries to get the interface name. The cLI backend tool would be a separate API which calls the SCAL plugins.
  • ubus call netjson API support: We should register the namespace netjson in the libubus. This allows the procedures with any number of arguments.
  • NetJSON objects: SCAL is an abstraction layer to push information onto the ubus from the device.  SCAL allows gathering data on the device from UCI, ubus calls, shell commands, etc and publishes it on the ubus using a different datamodel. Already available SCAL JSON plugin takes these data models and convert it into a JSON format. My work involves extension of this plugin to support the NetJSON to be done. Add features to the JSON plugin in C which is needed in order to define the full data model using the NetJSON schema. Also for data formats which doesn’t have support in the SCAL JSON plugin, parse the scal datamodel and then store in a DeviceConfiguration NetJSON object. This is SCAL plugin is created for retrieving the information directly using C.

Timeline:

  • May 30th : GSOC coding officially begins.
  • Task to be completed by the 2nd June: Bring CLI support for the above things to be implemented. Test the CLI and check if error cases are handled by the CLI.
  •  5th June to 8th June: NetJSON DeviceMonitoring and DeviceConfiguration objects/schema structures to be defined in the ubus architecture. ubus call netjson API support is to be implemented in this time period.
  • June 12th till June 16th : Implement the NetJSON DeviceConfiguration to be retrieved for the whole device. The whole NetJSON DeviceConfiguration would be the output. SCAL plugin to be added to support the NetJSON format in C itself.
  • June 19th to 23rd : Making changes to the exisiting JSON plugin available in SCAL to transalate it into the NetJSON format.
  • June 26th : Demo to the OpenWRT/LEDE community apart from the mentors to get feedback. Based on the feedback improve the implementation.
  • June 26th to July 7th : Based on the inputs provided in the CLI, output the DeviceMonitoring NetJSON object. For eg: “ubus call netjson config interface wlan0 status
  • July 8th to July 20th : Implement the NetJSON DeviceMonitoring to be retrieved for the device in whole and display it.
  • July 20th : Demo to the OpenWRT/LEDE community apart from the mentors and get feedback.
  • July 21st to July 27th : Improve the implementation based on the feedback from the community.
  • July 28th : Phase 2 evaluation.
  • July 28th to August 10th : Based on the inputs provided in the CLI, output the NetJSON DeviceMonitoring object. For eg: This CLI would only output monitoring data for wlan0. “ubus call netjson monitor interface wlan0”
  • August 10th to August 21st : Improve upon any possible design based on the Mentor and community feedback.
  • August 21st to August 24th : Code cleanup, final documentation review and possible merge/commit to the LEDE/OpenWRT distribution or ubus.