Table of Contents |
---|
Jira | ||||||||
---|---|---|---|---|---|---|---|---|
|
...
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 |
---|---|---|---|
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) |
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. |
To access local SDNC use - http://localhost:8282/apidoc/explorer/index.html
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.
where :
topology-netconf - is the topology
PNFDemo - is the node
gnodeb - is the model used
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
...
For Field filtering we can use RESTConf "fields" option :
Check RESTConf fields filtering for examples on using filtering option on RESTConf.
Sample Some sample URLS :
...
GET multiple fields with filtering - http://localhost:8282/rests/data/network-topology:network-topology/topology=topology-netconf/node=PNFDemo/yang-ext:mount/gnodeb:cells/cellinfolist=1?fields=cell-uuid;cell-id
Limiting subtree depth
For Field filtering we can use RESTConf "depth" option for GET requests.
The "depth" query parameter is used to limit the depth of subtrees returned by the server.
Data nodes with a "depth" value greater than the "depth" parameter are not returned in a response for a GET method
If the "fields" parameter is used to select descendant data nodes, then these nodes and all of their ancestor nodes have a "depth" value of "1".
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
Spike Demo Recording | 31/05/2021 |
---|