Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  • Device and device port types and names
  • Device location, owner, hardware and software versions
  • Wether Whether 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-to-be-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.



  • A subject is a Java object used as an unique identifier for a network object. Its stringified form is used as a JSON field key tied to the configurations associated with the network object.

    Example: A Link can be uniquely identified by a LinkKey (a pair of endpoints), so we use that as its subject. A LinkKey can be represented by a string of format “deviceId/port-deviceId/port”, and conversely, such a string can be used to generate a LinkKey.


  • ConfigOperator implementations are classes that implement the policy for merging information from different sources, and conversions between these sources.

    Example: The BasicLinkOperator defines methods for merging the contents of BasicLinkConfigs and LinkDescriptions, and for converting Link objects and BasicLinkConfigs into LinkDescriptions understood by the core.

Configuration Syntax

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


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 in those two classes.

Using Network Configuration Services

Making objects configurable

The network configuration subsystem can be used to configure arbitrary network objects. For an object to be configurable through this subsystem, you must implement the components described in in Components. Some things to note are:

  • SubjectFactory implementations belong in SubjectFactories. While you may want to use an existing factory for your subject of choice, you may want to implement a new SubjectFactory in addition to an existing one if a different key/creation technique is required for a subject.

  • ConfigFactory must be registered with the NetworkConfigManager. Adding a ConfigFactory to BasicNetworkConfigs will cause it to be registered when the subsystem starts up. Alternatively, you may manually invoke NetworkConfigManager.registerConfigFactory() from the application:

    Code Block
    // in the application:
    @Reference(cardinality = ReferenceCardinality.MANDATORY_UNARY)
    protected NetworkConfigRegistry registry;
    private ConfigFactory configFactory =
            new ConfigFactory(SubjectFactories.FOO_SUBJECT_FACTORY, FooConfig.class, "foo") {
        public FooConfig createConfig() {
            return new FooConfig();
    public void register() {
  • ConfigOperators enforce an order of precedence on information depending on their source. As a general rule, the configs supplied by this subsystem override information supplied by providers.

Using the service from applications

As with other services, the two primary ways that an application can use the network configuration subsystem are: