JSONRPC: Configuration and governance

Owned by Richard Kosegi
Mar 25, 2020
2 min read

One of the key problems faced by any RPC extension is how to map a particular API call invocation onto an RPC call.

The JSON-RPC 2.0 plugin in ODL maps these dynamically using the concept of universal path. The universal path is a superset of Yang Instance Identifier (for data), rpc call name and notification name expressed in a uniform anyxml notation as described in draft-yang-json-rpc.

A sparse tree of universal paths is kept in parallel with the yang schema for each JSON RPC plugin instance. The tree is formed from configuration (as described in the plugin yang model) and calls to an external mapping service which we have named governance. Any path in the API calls to the JSON RPC plugin is checked versus the tree of known paths. If it is not known, the tree is walked up to the tree root. If there is no mapping, the call fails. If there is a mapping, it is used as a URI endpoint for the call.

Sessions to a particular endpoint are cached so they can be reused as needed.

As a result a datastore, set of RPCs or notifications which are perceived to be a single "device" by ODL can be distributed over an arbitrary amount of endpoints. This improves scalability compared to 1:1 endpoint mapping protocols like netconf as well as allows to merge multiple devices into a single entity purely by means of configuration.

Known issues:

  • At present there is no way to flush the mapping cache besides remounting an endpoint. Similarly, there is no way to reconfigure it without remounting.

  • While we have always envisaged some notion of TTL for the mappings we have been unable to narrow down the exact semantics for the time being.