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.
draw.io Diagram | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
related Jira:
Jira | ||||||
---|---|---|---|---|---|---|
|
related links:
Commands to SDN-R to get yang modules
The RestConf commands are available as vsCode REST Client format:
/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):
### @namegetAllNodeIds
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
Code Block |
---|
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:
### @namegetConnectionStatus
@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
Code Block |
---|
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.
### @namegetASingleYangModuleNoRevision
@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
Code Block |
---|
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 .
### @namegetASingleYangModule
@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:
Code Block |
---|
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;
[...] |
Sequence Diagram
Status: under discussion 2020-03-01
PlantUML Macro |
---|
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ' Copyright 2020 highstreet technologies GmbH ' Licensed under the Apache License, Version 2.0 (the "License"); ' you may not use this file except in compliance with the License. ' You may obtain a copy of the License at ' ' http://www.apache.org/licenses/LICENSE-2.0 ' ' Unless required by applicable law or agreed to in writing, software ' distributed under the License is distributed on an "AS IS" BASIS, ' WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. ' See the License for the specific language governing permissions and ' limitations under the License. @startuml ' Diagram title ONAP SDN-R Interfacing with Configuration & Persistency Service (CPS) end title box "ONAP CCSDK/SDNC/SDN-R cluster" #lightpink participant "NetConf providerProvider" as ncs end box box "ONAP CCSDK/SDNC/SDN-R cluster" #gold participant "ODL NetConf Client" as ncc database "md-sal\nfile-system" as mdsal participant "RestConf Server" as rcs participant "DMaaP Consumer" as ctrldc participant "DMaaP Provider" as ctrldp end box participant "DMaaP" as mb box “RunTimeDB; ConfigDB, CONFucius”“Configuration & Persistency Service (CPS)” #lightblue participant "DMaaP Consumer" as dbdc ' participant "DMaaP Provider" as dbdp participant "YANG-to-SQL" as y2s participant "A1-REST-to-SQL (?)" as a2s database SQL as sql end box autonumber 10 10 "<b>[000]" == start, idling == dbdc -> mb: subscribe for topic(s) - topic-names? y2s -> rcs: synch-request y2s <- rcs: synch-response (MountPoints, ConnectionStatus,YANG-Capabilities) y2s -> rcs: download of new intersting YANG modules y2s <- rcs: YANG modules y2s -> y2s: process YANG modules y2s -> sql: Create INDEX, TABLE, ASSOCCIATION ctrldc -> mb: subscribe for topic(s) - topic-names? loop every 5s dbdc -> mb: poll for updates dbdc <- mb: response (empty or new message) end loop loop every 5s ctrldc -> mb: poll for updates ctrldc <- mb: response (empty or new message) end loop == New YANG revision (e.g. atfer xNF Software upgrade) == ncc <-> ncs: Establish NetConf session ncc -> ncs: Hello Message ncc <- ncs: Capabilites (yang modules) ncc -> ncs: download new YANG revision ncc <- ncs: new YANG module ncc -> mdsal: new YANG module ncc -> mdsal: mountpoint operation update mdsal -> ctrldp: mountpoint operation update ctrldp -> mb: mountpoint operation update mb-> dbdc: mountpoint operation update dbdc -> y2s: mountpoint operation update y2s -> y2s: analyse new YANG capabilities y2s -> rcs: download new YANG revision rcs -> mdsal: read new YANG revision rcs <- mdsal: YANG module y2s <- rcs: YANG module y2s -> y2s: process YANG modules y2s -> sql: Create INDEX, TABLE, ASSOCCIATION == READ data from network (proposed, to be discussed) == dbdc -> rcs: RESTCONF HTTP-GET data from network (pnf-id; filter) rcs -> ncc: trigger <get> ro <get-config> ncc -> ncs: NetConf <get> ro <get-config> ncc <- ncs: NetConf <response> rcs <- ncc: forward data dbdc <- rcs: RESTCONF response dbdc -> y2s: forward data y2s -> sql: strore data == SET data on network (???) == y2s <-> mb: TO BE DEFINED ' End Diagram ' Format header <b><font color=#8888ff>License</font></b> <b><font color=#8888ff>Apache 2.0</font></b> end header right footer Thanks to plantUml! 2020-03-01 | wiki.onap.org end footer skinparam backgroundColor #fefefe 'skinparam handwritten true skinparam roundcorner 15 skinparam componentStyle uml2 skinparam databaseBorderColor #444444 skinparam databaseBackgroundColor #fefefe skinparam databaseFontColor #444444 skinparam component { BorderColor #666666 BackgroundColor #fefefe } skinparam database { BorderColor #666666 BackgroundColor #ffffdd } skinparam interface { BorderColor #666666 BackgroundColor #fefefe FontColor #fefefe } skinparam node { FontColor #ffffff } skinparam sequence { MessageAlign left ArrowColor #2277dd ArrowFontColor #444444 ActorBorderColor #444444 LifeLineBorderColor #444444 LifeLineBackgroundColor #eeeeee BoxBorderColor #444444 GroupBorderColor #444444 GroupBackgroundColor #eeeeee ParticipantBorderColor #444444 ParticipantBackgroundColor #ffffdd ParticipantFontColor #444444 ActorBackgroundColor #ffffdd 'ActorFontColor DeepSkyBlue 'ActorFontSize 17 'ActorFontName Aapex } @enduml |