CPS-395 - Getting issue details... STATUS

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

#AssumptionNote
1rests bundle is pre-deployed
2NCMP/DMI-Plugin is not responsible for mounting nodes

Issues & Decisions

#

Issue Description

NotesDecision
1Bundle to useIt 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)

2Differentiation 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

Model used for illustration purposes
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;
            }			   
		}
		
		
	}
}

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

PUT add/update cell - http://localhost:8282/restconf/config/network-topology:network-topology/topology/topology-netconf/node/PNFDemo/yang-ext:mount/gnodeb:cells/cellinfolist/{cell-id}

GET particular cell-id - http://localhost:8282/restconf/config/network-topology:network-topology/topology/topology-netconf/node/PNFDemo/yang-ext:mount/gnodeb:cells/cellinfolist/2 

Filtering

This uses a different bundle (notice the URL).

For Field filtering we can use RESTConf "fields" option :

Check RESTConf fields filtering for examples on using filtering option on RESTConf.

Some sample URLS :

GET all - http://localhost:8282/rests/data/network-topology:network-topology/topology=topology-netconf/node=PNFDemo/yang-ext:mount/gnodeb:cells

GET cell details - http://localhost:8282/rests/data/network-topology:network-topology/topology=topology-netconf/node=PNFDemo/yang-ext:mount/gnodeb:cells/cellinfolist=1

GET cell details 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

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


e.g. - http://localhost:8282/rests/data/network-topology:network-topology/topology=topology-netconf/node=PNFDemo/yang-ext:mount/gnodeb:cells?depth=3


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".

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&depth=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.

e.g. http://localhost:8282/rests/data/network-topology:network-topology/topology=topology-netconf/node=PNFDemo/yang-ext:mount/gnodeb:cells?content=nonconfig

Equivalent rpc request
<?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>                                                                               

http://localhost:8282/rests/data/network-topology:network-topology/topology=topology-netconf/node=PNFDemo/yang-ext:mount/gnodeb:cells?content=config

Equivalent rpc request
<?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>

http://localhost:8282/rests/data/network-topology:network-topology/topology=topology-netconf/node=PNFDemo/yang-ext:mount/gnodeb:cells?content=all

Equivalent rpc request
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)SimulatorModel Contains
config:trueconfig:falseboth
passthrough-running
(config=true)
NetConf PnPconfig-true404 Error from SDN-C wrapped inside 500 error by DMI*Not tested**
Honeycomb***


passthrough-operational
(config=all)
NetConf PnPconfig-trueconfig-falseNot 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



  • No labels