SDN-R interfacing with Configuration & Persistency Service

Design Principals

  • the entire communication between SDN-R and CPS is via DMaaP

  • an exception might be when SDN-R uses CPS as lookup DB to complete a request to the network (lookup)







ONAP internal data  vs. Network Function specific data

For backup or Initial (startup) configuration CPS could store the configuration data according to the Network Function (VNP, PNF) specific data models. 

Such data is most likely not abstracted to be used for multi-vendor, multi-layer, multi-technology use cases and should/could not be used by µServices addressing such use cases.

Multi-vendor, multi-layer, multi-technology µServices require an abstract view of the network. Therefore a translation service is required to translate between ONAP internal data models and Network Function specific data models.

The database technology for the ONAP internal data must be well defined and so that model-translation-functions can be implemented accordingly. SQL based on in the MariaDB implementation seems to be the right choice.

The database technology for Network Function specific data depends on the data and the Network Function specific data schema. If the data model schema bases on YANG, which usually describes a data tree, then a non-SQL database, could be the right choice. 

Commands to SDN-R to get yang modules

The RestConf commands are available as vsCode REST Client format: https://lf-onap.atlassian.net/wiki/download/attachments/16412605/cps-sdn-r-interfaceing.http?api=v2.

To get the yang modules learnt by SDN-R it is recommended to request the yang-capabilites for each node (NetworkFunction).

Environment Variables

@protocol = https
@host = odlux.oam.smo.indigo.cosmos-lab.org
### @host = 10.41.1.2
@port = 443
@sdnrUsername = admin
@sdnrPassword = Kp8bJ4SXszM0WXlhak3eHlcse2gAw84vaoGGmJvUy2U

@baseUrl = {{protocol}}://{{host}}:{{port}}



RestConf Request

Response (partial)

Step #1 is the command to request all known node-ids (network-function-names):


### @name getAllNodeIds
GET {{baseUrl}}/rests/data/network-topology:network-topology/topology=topology-netconf?content=nonconfig&fields=node(node-id)
Authorization: Basic {{sdnrUsername}} {{sdnrPassword}}
Accept: application/yang-data+json



HTTP/1.1 200 OK Content-Length: 166 Content-Type: application/yang-data+json Date: Wed, 09 Aug 2023 16:47:56 GMT Expires: Thu, 01 Jan 1970 00:00:00 GMT Server: nginx Set-Cookie: JSESSIONID=node01ea9dc8np27jcw3vocehlwcwo90929.node0; Path=/,rememberMe=deleteMe; Path=/; Max-Age=0; Expires=Tue, 08-Aug-2023 16:47:56 GMT; SameSite=lax X-Frame-Options: SAMEORIGIN Connection: close { "network-topology:topology": [ { "node": [ { "node-id": "O-RU-11222" }, { "node-id": "O-DU-1122" }, [...]



In Step #2 the code should iterate over the list of node-ids to request the available yang capabilities. Here the example for node-id=O-RU-11222:

### @name getConnectionStatus
@node-id=O-RU-11222
GET {{baseUrl}}/rests/data/network-topology:network-topology/topology=topology-netconf/node={{node-id}}?content=nonconfig&fields=netconf-node-topology:available-capabilities/available-capability/capability
Authorization: Basic {{sdnrUsername}} {{sdnrPassword}}
Accept: application/yang-data+json



HTTP/1.1 200 OK Content-Type: application/yang-data+json Date: Wed, 09 Aug 2023 16:56:05 GMT Expires: Thu, 01 Jan 1970 00:00:00 GMT Server: nginx Set-Cookie: JSESSIONID=node0zsfdafr3nv0m1bi3uymdui3uw90955.node0; Path=/,rememberMe=deleteMe; Path=/; Max-Age=0; Expires=Tue, 08-Aug-2023 16:56:05 GMT; SameSite=lax X-Frame-Options: SAMEORIGIN Connection: close Transfer-Encoding: chunked { "network-topology:node": [ { "netconf-node-topology:available-capabilities": { "available-capability": [ { "capability": "urn:ietf:params:netconf:capability:with-defaults:1.0?basic-mode=explicit&also-supported=report-all,report-all-tagged,trim,explicit" }, { "capability": "urn:ietf:params:netconf:capability:notification:1.0" }, [...]



In Step #3 the capability attribute values must be parsed to identify the yang module name and its revision date. SDN-R provides the latest yang revision of the module, if no revision date is given.

Here an example for the yang module 'o-ran-hardware' without the revision date in the request.

### @name getASingleYangModuleNoRevision
@yangModuleNoRevision=o-ran-hardware
#### from "capability": "(urn:o-ran:hardware:1.0?revision=2022-12-05)o-ran-hardware"
#### .split(')')[1]
GET {{baseUrl}}/yang-schema/{{yangModuleNoRevision}}
Authorization: Basic {{sdnrUsername}} {{sdnrPassword}}
Accept: application/yang-data+json



HTTP/1.1 200 OK Content-Encoding: gzip Content-Type: text/plain Date: Wed, 09 Aug 2023 16:56:36 GMT Server: nginx X-Frame-Options: SAMEORIGIN Connection: close Transfer-Encoding: chunked module o-ran-hardware { yang-version 1.1; namespace "urn:o-ran:hardware:1.0"; prefix o-ran-hw; import ietf-hardware { prefix hw; } import iana-hardware { prefix ianahw; } import ietf-yang-types { [...]



Here an example for the yang module 'o-ran-sync' and the revision '2022-08-15' - such request is recommended, to ensure that the revision implemented by the network-function is used .

### @name getASingleYangModule
@yangModule=o-ran-sync
@revision=2022-08-15
#### from "capability": "(urn:o-ran:sync:1.0?revision=2022-08-15)o-ran-sync"
GET {{baseUrl}}/yang-schema/{{yangModule}}/
Authorization: Basic {{sdnrUsername}} {{sdnrPassword}}
Accept: application/yang-data+json




The entire RESTCONF APIs can be uploaded from SDN-R as OpenAPI specification:





Sequence Diagram

Status: under discussion 2020-03-01







References