The network configuration subsystem allows applications to inject attribute and configuration information for various network components into the models used for network representation. Examples include (but are not limited to):

The configurations may refer to a component that may or may not already exist in the network representation (i.e., the system may/may not have discovered it in the network). This implies that an application can offer hints about a yet-discovered component, as well as modify a known component’s attributes.

This subsystem likewise serves as a shim between the system’s network representation, and the means to configure it. Currently, JSON is the preferred means to describe component configurations.




The relationship between the subject, config, subject key, and config key are summarized by the following JSON tree:

      subject key 1 : {
          subject 1 : {
              config key : {
                  config fields
          subject 2 : {
      subject key 2 {

where config fields above are key:value entries following the JSON format. Each field in a Config with an attribute accessor is represented by such a key:value pair.

For example, a configuration for a single device might look like the following:

     "devices" : {
        "of:0000ffffffffff0a" : {
            "basic": {
                "driver": "linc-oe",
                "type": "ROADM",
                "latitude": 33.8,
                "name": "ATL-S10",
                "longitude": -84.1


Indeed, if you were to take a look at BasicDeviceConfig and its superclass, you will find all of the fields within the “basic” clause above defined amongst the two classes.

Using Network Configuration Services


The NetworkConfigWebResource implements the REST calls for the network configuration subsystem. Its functionalities will eventually replace that of ConfigWebResource.

The following example uses the REST API to upload a configuration file:


curl --user onos:rocks -X POST -H "Content-Type: application/json" -d @/tmp/cfg.json


The above assumes a running instance at, and a configuration file at /tmp/cfg.json. They should be replaced with appropriate values.

Likewise, the user:password vaues may differ with your setup; Other common values are karaf:karaf and onos:onos.


Network Configuration Loader

The NetworkConfigLoader reads JSON files from a known location and attempts to load them as network configurations.

Currently, a file named network-cfg.json is picked up from ${ONOS_ROOT}/tools/package/config/ and placed in ${KARAF_ROOT}../config/ (currently fixed) at deployment. When the remote instance boots, its network configuration loader runtime will read this file.

The Network Configuration Loader is implemented as a listener for Network Configuration events (NetworkConfigEvents). It attempts to use the knwon Configs in order to generate or update entities in the network model once it is notified that the Configs are available.