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://wiki.onap.org/download/attachments/81396544/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:
HTTP/1.1 200 OK
Content-Encoding: gzip
Content-Type: text/plain
Date: Wed, 09 Aug 2023 16:57:08 GMT
Server: nginx
X-Frame-Options: SAMEORIGIN
Connection: close
Transfer-Encoding: chunked
module o-ran-sync {
yang-version 1.1;
namespace "urn:o-ran:sync:1.0";
prefix o-ran-sync;
import ietf-interfaces {
prefix if;
}
import o-ran-interfaces {
prefix o-ran-int;
[...]