| Table of Contents |
|---|
| Jira | ||||||||
|---|---|---|---|---|---|---|---|---|
|
...
| title | Work In Progress |
|---|
The purpose of this spike is to be able to identify the APIs we need in order to talk to SDNC for doing CRUD operations on the models that are mounted as nodes on a particular installation.
Assumptions
| # | Assumption | Note |
|---|---|---|
| 1 | rests bundle is pre-deployed | |
| 2 | NCMP/DMI-Plugin is not responsible for mounting nodes |
Issues & Decisions
| # | Issue Description | Notes | Decision |
|---|
Decisions
Description
| 1 | Bundle to use | It also supports actions. | "rests" bundle supports MIME type "application/yang-data+json" and is chosen as the bundle to use. Supports parameters like fields and depth (details below) |
Assumptions
...
| 2 | Differentiation between config false and config=true data | The NCMP and DMI interface will use the concept of datastores like 'operational' and 'running' to possible request config=true or all data. Currently it is unclear if the RESTConf/ODL parameter of 'content' works as intended to make this distinction. Currently on the simulator the available "datastores" observed are startup, persist and running. Rel I only aiming at non-NMDA devices. |
Spike Findings
Sample Model
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
module gnodeb {
yang-version 1.1;
namespace "urn:gnodeb:test";
prefix gnb;
description
"Yang model for gnodeb";
revision "2019-12-03" {
description
"initial version";
}
container cells {
list cellinfolist {
key cell-id;
leaf cell-id {
type uint16;
}
leaf cell-uuid {
type uint32;
}
leaf cell-description {
type string;
description
"Possible name or description";
}
leaf connected-users {
type uint32;
config false;
default 10;
}
}
container antenna {
leaf a-id {
type uint16;
}
leaf antenna-description {
type string;
}
}
container measurements {
config false;
leaf speed {
type uint16;
default 20;
}
}
}
} |
| Info |
|---|
For this use case we do not need to worry about creating mount points or supplying our models, as these would be made available beforehand. For this spike we have used the NETCONF Plug-and-Play Simulator which enables the creation of NETCONF-enabled devices i.e, xNF. |
...
Credentials : - admin / Kp8bJ4SXszM0WXlhak3eHlcse2gAw84vaoGGmJvUy2U
Interface Usage
Once the above model is added to a mount point ( say PNFDemo ) on SDNC this model should show up on the GUI, with methods for operating on all public leaves as below.
...
All of these are well documented with examples in the Swagger UI as below :
...
Postman sample URLs
GET all cells - http://localhost:8282/restconf/config/network-topology:network-topology/topology/topology-netconf/node/PNFDemo/yang-ext:mount/gnodeb:cells
...
...
Query Config data
The "content" query parameter controls how descendant nodes of the requested data nodes will be processed in the reply of a GET request.
Possible values are config, nonconfig and all, with all being the default.
| Code Block | ||||
|---|---|---|---|---|
| ||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<rpc message-id="m-441" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter xmlns:ns0="urn:ietf:params:xml:ns:netconf:base:1.0" ns0:type="subtree">
<cells xmlns="urn:gnodeb:test"/>
</filter>
</get>
</rpc> |
| Code Block | ||||
|---|---|---|---|---|
| ||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<rpc message-id="m-442" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter xmlns:ns0="urn:ietf:params:xml:ns:netconf:base:1.0" ns0:type="subtree">
<cells xmlns="urn:gnodeb:test"/>
</filter>
</get-config>
</rpc> |
| Code Block | ||||
|---|---|---|---|---|
| ||||
Request 1:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<rpc message-id="m-464" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter xmlns:ns0="urn:ietf:params:xml:ns:netconf:base:1.0" ns0:type="subtree">
<cells xmlns="urn:gnodeb:test"/>
</filter>
</get>
</rpc>
Request 2 :
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<rpc message-id="m-444" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
<source>
<running/>
</source>
<filter xmlns:ns0="urn:ietf:params:xml:ns:netconf:base:1.0" ns0:type="subtree">
<cells xmlns="urn:gnodeb:test"/>
</filter>
</get-config>
</rpc> |
E2E Test Findings on config filtering
Response Read use-cases
| DataStore(filter) | Simulator | Model Contains | ||
|---|---|---|---|---|
| config:true | config:false | both | ||
| passthrough-running (config=true) | NetConf PnP | config-true | 404 Error from SDN-C wrapped inside 500 error by DMI* | Not tested** |
| Honeycomb*** | ||||
| passthrough-operational (config=all) | NetConf PnP | config-true | config-false | Not tested** |
| Honeycomb*** | ||||
* need to decide on expected response from DMI in this case: empty result, 404, 500
** having issues creating/deploying a model with both config true and false data
*** Honeycomb results have been recorded but need to be add here
Other available parameters :
Recording
...
| Initial Spike Demo Recording | 31/05/2021 |
|---|