The Network Configuration Subsystem

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):

• Device and device port types and names
• Device location, owner, hardware and software versions
• Wether components are allowed or denied inclusion in the network model

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.

Terminology

• A subject is a reference to, or a placeholder for, an object to be configured via this subsystem. Example: a DeviceId for a network device, or a ConnectPoint for a device port.
• A config is a set of exposed tunables for a given object. Example: A BasicDeviceConfig allows a device’s type and southbound driver to be set/changed.
• A key, or subject key, is a string name for a subject. It is used as the key for the JSON field containing the configuration values. Example: Device configurations can be found in the field with key “devices”.
• A config key is a string name for a configuration class. It is also used as a JSON field key. Example: the key “basic” refers to the general configurations allowed for a device. The value associated with it may be a JSON representation of config values.

Components

• Config subclasses implement the tunables for a subject as a set of getters and setters (attribute accessors) to JSON object constructs (ObjectNodes). Example: An OpticalPortConfig is defined as:

   

  public class OpticalPortConfig extends Config<ConnectPoint>

   

  meaning that it manipulates the configurations associated with ConnectPoint subjects (optical ports). Some of its attribute accessors include the port’s string and numeric names, and the number of channels that the port supports.

• SubjectFactory ties a subject to its subject key, and generates objects that represent the subject. Example: the factory that generates ConnectPoints is instantiated as:

   

  public static final SubjectFactory<ConnectPoint> CONNECT_POINT_SUBJECT_FACTORY = 
  		new SubjectFactory<ConnectPoint>(ConnectPoint.class, "ports") { 
  			@Override public ConnectPoint createSubject(String key) {
              		 return ConnectPoint.deviceConnectPoint(key); 
  			} 
  		};

   

  meaning that the key for the JSON field containing port information is keyed on string “ports”, and the factory can create ConnectPoints from a “deviceId:port” string (the argument to createSubject).

• ConfigFactory ties a subject to its config and config key, and generates Configs. Example: The ConfigFactory for OpticalPortConfig is defined as:

   

  // ConfigFactory<S, C extends Config<S>> 
  new ConfigFactory<ConnectPoint, OpticalPortConfig>(CONNECT_POINT_SUBJECT_FACTORY, OpticalPortConfig.class, "basic") {
  		@Override public OpticalPortConfig createConfig() {
  return new OpticalPortConfig(); 
  } 
  }

   

  indicating that the ConfigFactory can generate OpticalPortConfigs, and the configuration information for a given optical port can be fetched from the subsystem’s manager using its associated subject (a ConnectPoint in this case). In the JSON structure, the key “basic” can be used to fetch out the values set by the OpticalPortConfig.

Syntax

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

• Via CLI or REST API
• By loading a file from a fixed location using the
• ConfigFactory required for what needs to be parsed
• ConfigFactory registered with NetworkConfigManager, either by adding it to BasicNetworkConfigs which will load it when it starts up, or by manually invoking NetworkConfigManager.registerConfigFactory() from the application
• Register application as a NetworkConfigListener

curl --user onos:rocks -X POST -H "Content-Type: application/json" http://192.168.56.111:8181/onos/v1/network/configuration/ -d @/tmp/cfg.json