Overview

 In ONOS, various abstractions collect configuration information pertaining to the network and network elements and store them in the implementation defined system wide models. But often in the brown fields, applications create or collect similar configuration information  and work with their own individual information models. Often these models are heterogeneous and most of them do not directly confirm to the models/abstraction within ONOS. Purpose of the Dynamic config subsystem is to provide suitable abstractions that would enable ONOS to consume/produce configuration in a structured and extensible manner. Parking such abstracted configuartions within ONOS would also allow opportunities for other abstractions (like drivers, providers etc.) to consume or modify them. 

 Components

The main components of this subsystem include the Dynamic config service and manager, Dynamic config store interface and the distributed config store. Dynamicconfig service is the gateway for applications to inject configs to ONOS. Dynamic config manger implements this service and is responsible for managing the distributed config store; this component also provides an RPC dispatching framework, for the yang based RPCs. The distributed config store implementation is wrapping the Document Tree primitive and is built on top of the ONOS Distributed storage implementation. 

The important abstractions that Dyanmic config subsystem provides, are the DataNode, ResourceId, RpcService, RpcInput and RpcOutput. DataNode is the abstraction to hold any configuration that ONOS (any module within ONOS) would deal with. ResourceId is the globally unique identifier for any such configuration nodes; this is created by abstracting information available in the schema about a given config node. RpcService, input and output provide abstractions for defining an Rpc interface contatining various Rpc methods, their input and output respectively. The dispatcher framework works on these abstractions.

APIs

Dynamicconfig service supports the following APIs currently:

Use Case

In its current state, the following demo use case is planned to be supported (by ONS 2017)

Document Tree primitive

This subsystem makes use of the DocumentTree primitive.  The primitive consists of an implementation of AsyncDocumentTree (AtomixDocumentTree) residing on the client machine which submits commands to the remote Copycat state machine (AtomixDocumentTreeState), responsible for maintaining distributed state.  The commands submitted to the primitive are found in AtomixDocumentTreeCommands, it should be noted that there will not necessarily be a one to one correspondence between the commands provided in the AsyncDocumentTree API and the command classes, in many cases a single command class can encapsulate the functionality of several API calls.

Behavior

The DocumentTree primitive supports a tree structure which allows nodes with arbitrary numbers of children.  The primitive also provides efficient prefix filtering by using qualified names which identify the ancestry of a node (as demonstrated in the image below) which enables listening for notifications from specified subtrees.  The structure supports sequential query consistency but makes no guarantees about the linearizability of queries. 

Next Steps