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 | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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):
### @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 Provider" 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 “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
|
...
...