SDN-R interfacing with Configuration & Persistency Service

related Jira: SDNC-1094 - Getting issue details... STATUS

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)

Commands to SDN-R to get yang modules

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}}

#### Step #1
### @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"
        },

#### Step #2 itter over the node-ids
### @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"
          },

#### Step #3 itter over the capabilities
#### If no revision date is psecified you will get the latest avaialble.
### @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 {

### @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

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;

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.

Sequence Diagram

Status: under discussion 2020-03-01