...
Follow principles/patterns of RESTCONF RFC-8040 https://datatracker.ietf.org/doc/html/rfc8040
Follow principles/patterns of yang-patch RFC-8072 https://datatracker.ietf.org/doc/html/rfc8040
Follow principles/patterns of RESTCONF NMDA RFC-8527 https://datatracker.ietf.org/doc/html/rfc8527
...
Issues &
...
Decisions
...
Issues |
---|
...
Description
Notes |
---|
...
Decisions |
---|
1 |
...
Currently, we wrap the response of GET operations using the data node wrapper.
...
we should mainly support yang-data/json
controlled by "accept-header"
...
e.g. http://localhost:8080/ncmp/v1/data
http://localhost:8080/ncmp/v1/operation
...
This only applies to pass-through
yes, we will distinguish between data and operation
...
Parent data resource identifier can handle any path using the same query parameter
- cpsPath
- RESTConf Path (pass-through)
- Proprietary Path (pass-through)
...
Yml should include return types and examples of the payload
...
Legacy and new API documentation needs to include output examples.
Task created, see
Jira | ||||||
---|---|---|---|---|---|---|
|
...
We will use a dash for param names e.g. cm-handle (although it has since been agreed we use 'ch' in this particular case)
See no.3 https://restfulapi.net/resource-naming/
...
- Add child and its descendants (supported in cps core)
- Add all list elements (supported in cps core)
- Replace child and its descendants (supported in cps core)
- Replace all list elements (pending in cps core)
- Update single leaf (new)
- Add list entry (new)
...
Priority is pass-through only so it depends on the RETSConf protocol that is supported.
In Jakarta or if required by other projects more fine-grained 'operation' datastore update options can be implemented
...
Proposed syntax by CPS team
<OP>/ncmp/<v{v-number}>/ch/<cm-handle>/<data|operations|{ncmp-operation}>/ds/{datastore}/[rp:]{resource-path}?{query}
...
HTTP Header Limitations
Some servers put size limitations on HTTP headers, making them unsuitable for storing cmHandle information.
LIMITATION NOTE: server implementations put size limits on the headers meaning header contents should be designed carefully :
Apache - 8K
Nginx - 4K-8K
IIS - 8K-16K
Tomcat - 8K – 48K
KPI for De-registration of 100 CM-handles | This was mentioned. Was this ever agreed, is this a valid use case that needs to be covered together with the Registration ? | Not priority for now, but acceptable if we match the registration req. | |
2 | DMI delay | Could we get some feedback on DMI-delays for other use cases as not mentioned in FS document | Awaiting for ETH feedback AP On Kolawole Adebisi-Adeolokun and Csaba Kocsis Provided |
3 | Number of instances In some cases, ETH have used 2 instances, can we verify the number of instances for each use case. Some of the req were defined per instance and resources used : Identify which of these ? | Agreed to; CPS use 1 instance currently, but should focus on aligning performance with 2 instances for all use case | |
4 | Input Load Distribution the CM-handle search and ID search | Currently has 5 parallel request between them distributed at 2.5 each. This fractional distribution isn't feasible for parallel processing; the load should be allocated as whole numbers. Load needs to be distributed at. Would it be acceptable to adjust this distribution to either 2 or 3 parallel requests each (and vice versa ) without any negative repercussions? Agreed to do 6 parallel request combined total and divide the load to 3 parallel request each | |
5 | Regarding CM-handle search and ID search | FS only identified Module performance, are there any testing done towards a combined search of properties and modules in a single query Confirmed no other testing was previously done on this..... CPS have the capabilities to do mixed testing. ETH tbc on if they want to consider this ( Csaba Kocsis ) |
Requirements
Note |
---|
Please note this section was added long after the implementation and focuses on characteristic and enhancements after this study only. |
Characteristics
It is proposed that reported characteristics will be used as a baseline for NCMP when agreed and sign-off.
Operation | Concurrent requests/parallel | DMI Delay | Response size | Performance Requirement (Blue Stone tablet KPI) | Notes | Sign-Off | |
---|---|---|---|---|---|---|---|
1 | Registration of 20,000 CM-handles (in batches of 100) | 1 (requests are sequential) | 100 ms to get module references | N/A |
|
| |
2 | De-registration of 100 CM-handles | 1 (requests are sequential) | No Module delays | N/A |
| De-registration is currently not mentioned in Stone Tablet KPI or FS, however we have agreed to match the performance of registration for now as de-reg is also not a priority at this point in time | |
3 | CM-handle ID search with Module filter | 3 | N/A | 20,000 CM Handles i.e. 100*20.000 = 2MB | As provided byCsaba Kocsis 0.625 seconds/Operation | FS stated 5 parallel request for both ID search and search. CPS to run with 3 parallel each for both ID search and Search meaning a combine total of 6 parallel request | |
4 | CM-handle search with Module filter | 3 Run in parallel with #3 | N/A | 20,000 CM Handles i.e. 500*20.000 = 10MB | As provided by Csaba Kocsis 13 seconds/Operation | FS stated 5 parallel request for both ID search and search. CPS to test with 3 parallel each for both ID search and Search meaning a combine total of 6 parallel request | |
5 | Synchronous single CM-handle pass-through read | 10 | 300 ms Csaba Kocsis | 5 KB | 25 (parallel) request/sec | Read are done in parallel with Write | |
6 | Synchronous single CM-handle pass-through write (CUD) | 10 | 670 msCsaba Kocsis | 5 KB | 13 (parallel) request/sec | No response is expected | |
7 | Batch/Bulk Read | 1 read request with 200 cmHandles per second | 150 cmhandles/sec | The batch data operation is asynchronous. NCMP returns the response on the ncmp-async-m2m kafka topic. |
Notes
- This is for mixed TCs
- Single KPIs will be monitored in NCMP owned pipeline with our performance every day(2 hrs interval) - Performance
Synchronous single cm-handle pass-through (read) requests
Parameter | Expectation | Notes | Sign-Off | ||
---|---|---|---|---|---|
Average Response Size | 5KB | Shall not exceed 5KB | |||
Concurrent request | 12 clients requests toward 1 NCMP simultaneously DMI also support 12 simultaneous requests | 40ms of overhead on top of DMI latency for each requests, at most for NCMP request. This shall remain within 40ms for 12 parallel requests. Given the DMI delay below; this means up to 240 request per second | |||
DMI Delay | 10ms | This is not in control of CPS. Assume DMI is 1.25 seconds average DMI response time for high latency, low latency =10 ms, this should also work for DMI Plugin. I.e 40ms ontop of the DMI. 1.25seconds+40ms= 1.29seconds | |||
Test Environment |
| ||||
Security | Disable Basic Authentication in Springboot | If configurable from application yaml, then it’s acceptable. |
Open Issues & Decisions
Expand | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
RESTCONF/NETCONF relationship
NCMP URI
NCMP URI format to follow below pattern
<OP>/ncmp/<v{vNumber}>/ch/<cmHandle>/<data|operations|{ncmpAction}>/ds/{datastore}?[rp:]{resourcePath}&{options}
Below table shows the proposed interface, actual implementation might deviate from this but can be accessed from
- Gerrit Source
- Read-the-docs: https://docs.onap.org/projects/onap-cps/en/latest/design.html#offered-apis
URI | Mandatory or Optional | |
---|---|---|
<OP> | the HTTP method | Mandatory |
ncmp / | the ncmp root resource | Mandatory |
<v{vNumber}> | version of the ncmp interface <path> is the target resource URI <query> is the query parameter list | Mandatory |
ch/<cmHandle> | unique (string) identifier of a yang tree instance. | Mandatory |
<data|operations|{ncmpAction}> | request category - yang data, rpc operation or a (non-modelled) ncmp api action. this could be data, operations or ncmpAction (e.g. 'sync-data') | Mandatory |
ds/{datastore} | Mandatory | |
<resourceIdentifier> | the path expression identifying the resource that is being accessed by the operation. If this field is not present, then the target resource is the API itself. | Optional |
<options> | Parameters with the familiar form of "name=value" pairs. Query parameters are optional to implement by the server and optional to use by the client. Each optional query parameter is identified by a URI | Optional DMI should be able to support (/pass through) ANY parameter associated with the RESTCONF message; see Section 3.4 of [RFC3986]. |
Datastores
New datastores are defined for ncmp to access the CPS 'running' or 'operational' datastore.
Alternatively, the request can be sent directly to the 'device' itself (bypassing CPS datastores) using one of the 'passthrough-*' datastores options as below
The new ncmp datastores required for ONAP Release I include :
Excerpt Include | ||||
---|---|---|---|---|
|
Excerpt | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Datastore, Paths and Format Combinations for Read Operations
*Note Convert cpsPath to RESTConfPath wil only support 'absolute' cpsPath for conversion no query-type paths Read Example
Works Items for above.
Datastore, Paths and Format Combinations for Write Operations
Write Example
|
Sync & Model API
Expand | ||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
The plugin will not do transformation or validation of paths in the case of pass-through:running
...
- not supported (ignored, not rejects, nice for future compatibility)
- treat as 'no descendants' (low cost)
- use to filter cached data
...
&Fields parameter will be ignored for 'cached' data in Istanbul timeframe
long term expectation is to have support following RESTConf/ODL behavior as much as possible
...
- not supported (ignored, not rejects, nice for future compatibility)
- treat as 'no descendants' (low cost)
- translate (insert module names) and forward
...
A spike
Jira | ||||||
---|---|---|---|---|---|---|
|
...
RESTCONF/NETCONF relationship
NCMP URI
NCMP URI format to follow below pattern
<OP>/ncmp/<v{v-number}>/ch/<cm-handle>/<data|operations|{ncmp-operation}>/ds/{datastore}/[rp:]{resource-path}?{query}
...
the set of parameters associated with the RESTCONF message; see Section 3.4 of [RFC3986]. RESTCONF parameters have the familiar form of "name=value" pairs. Most query parameters are optional to implement by the server and optional to use by the client. Each optional query parameter is identified by a URI
...
Datastores
New datastores are defined for ncmp to access the CPS 'intent' or 'operational' datastore.
Alternatively, the request can be sent directly to the 'device' itself (bypassing CPS datastores) using one of the 'passthrough-*' datastores options as below
The new ncmp datastores required for ONAP Release I include :
...
Future datastores to be supported by NCMP might include :
...
If datastore (ds/{datastore}) is omitted from URI, the datastore from cmhandle is used
If datastore (ds/{datastore}) is omitted from URI AND the model/moduleSet exists, the datastore defaults to ncmp-datastores:running
Yang data resource actions and RPC operations are run directly on the 'device' meaning ncmp-datastores:passthrough-running is used for these request
...
Datastore, paths and format combinations
...
Expected Resource-Path
format
...
Fields
(filter)
...
Included DataNodes
(config)
...
Not Specified
...
N/A
...
Not supported
...
NCMP does not parse
...
Resolve DMI plugin
Forward request to plugin
...
The DMI plugin may error if the RP or accept header are not supported.
...
Resolve DMI plugin
Forward request to plugin
...
Read from cache
output: application/yang-data+json
...
Read from cache
output: application/json
...
to be determined in spike, see issue #28
...
Resolve DMI plugin
Convert cpsPath to RESTConfPath
Forward request to plugin | Read from DMI plugin
Output application/yang-data+json
...
config +
non-config
...
Resolve DMI plugin
Convert cpsPath to RESTConfPath
Forward request to plugin | Read from DMI plugin
Output application/yang-data+json
...
Works Items for above.
...
REST API
Expand | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
# | Req/usecase | REST MethodURI / Payload Request/Response Example | Status | Release I | 1 | Async read of a data resource getting GET | {ncmp-root}/ncmp/v1/ch/<cm-handle>/{dataresource-identifier}?fields={fields}&topic={topicId} Note 'topic' and 'fields' are only supported in passthrough mode at this time (ONAP Release I). If not passthrough then an exception is thrown from NCMP at this time.Accept : application/json Always return the yang-data+json in the "data" event payload The ONAP plugin (for initial inventory) may need an ODL mountpoint which will be created outside CPS and DMI plugin Scenario : Read the GNBCUCPFunction for cm-handle "335ff" as passthrough Method : GET URI : {ncmp-root}/ncmp/v1/ch/335ff/data/ds/GNBCUCPFunction?fields=pLMNId;gNBId;gNBIdLength;syncStatus&topic=anr-app:anr24234234:v2 OR {ncmp-root}/ncmp/v1/ch/335ff/data/ds/ncmp-datastores:passthrough-running?fields=_3gpp-common-managed-element:ManagedElement/_3gpp-nr-nrm-gnbcucpfunction:GNBCUCPFunction(pLMNId;gNBId;gNBIdLength)&topic=anr-app:anr24234234:v2 Header : Response : Event Response: { passthrough-running is supported in Istanbul using
Note 'topic' and 'fields' are only supported in passthrough mode at this time (ONAP Release I). If not passthrough then an exception is thrown from NCMP at this time. Always return the yang-data+json in the "data" event payload yes | 2 | Read of a data resource getting specific GET | {ncmp-root}/ncmp/v1/ch/<cm-handle>/data/{data-resource-identifier}?fields={fields} Scenario : Method: GET URI : {ncmp-root}/ncmp/v1/ch/335ff/data Header : Response: HTTP/1.1 200 OK passthrough-running is supported in Istanbul using
3 | Read a data resource directly from Synchronous call GET | {ncmp-root}/ncmp/v1/data/ch/{data-resource-identifier}?fields={fields} Accept: application/yang-data+json Scenario : Read the Method : GET URI :{ncmp-root}/ncmp/v1/ch/335ff/data Header : Response: HTTP/1.1 200 OK { passthrough-running is supported in Istanbul using
Yes | 4 | Create a data resource for a cmhandle | POST | cmp-root}/ncmp/v1/ch/<cm-handle>/data/{parent-data-resource-identifier} { Scenario : Create Method : POST URI : {ncmp-root}/ncmp/v1/ch/34l5k32/data/ Header : Body : passthrough-running is supported in Istanbul using
ncmp-datastores:running is not supported in Istanbul 5 | Update a data resource for a cmhandle with plain-patch update PATCH | {ncmp-root}/ncmp/v1/ch/<cmhandle>/data/{data-resource-identifier} { Content: application/yang-data+json Behaves as a merge - merge with existing if it exists or create if it does not exist. Scenario : Method : PATCH URI :{ncmp-root}/ncmp/v1/ch/34l5k32/data/Header : Body : { NOTE : If not passthrough then ALL attributes MUST be supplied for the patch at this time. Otherwise, other attributes are removed from CPS. passthrough-running is supported in Istanbul using
ncmp-datastores:running is not supported in Istanbul this will be treated as a merge 6 | Update a data resource with multiple | edits for a cmhandle with yang-patch update PATCH | {ncmp-root}/ncmp/v1/ch/<cm-handle>/data/{data-resource-identifier} { Content: application/yang-data+json If using yang-patch content then ds/ncmp-datastore-passthrough-running mus be used by rad apps until full Scenario : Update _3gpp-common-managed-element:ManagedElement=Kista-001/_3gpp-nr-nrm-gnbdufunction:GNBDUFunction=1 with multiple operations on the tree Method : PATCH Header : Body : {"ietf-restconf:yang-patch" : { "patch-id" : "change-cell-and-carriers", "edit" : [ { "edit-id" : 1, "operation" : "create", "target" : "/_3gpp-nr-nrm-nrcelldu:NRCellDU=1", "value" : { "_3gpp-nr-nrm-nrcelldu:NRCellDU" : { "id" : 1, "cId" : 511, "userLabel" : "some-cell-label", ... } } }, { "edit-id" : 2, "operation" : "create", "target" : "/_3gpp-nr-nrm-nrcelldu:NRCellDU=2", "value" : { "_3gpp-nr-nrm-nrcelldu:NRCellDU" : { "id" : 2, "cId" : 512, "userLabel" : "some-other-cell-label", ... } } }, { "edit-id" : 3, "operation" : "merge", "target" : "/_3gpp-nr-nrm-nrcelldu:NRCellDU=3", "value" : { "_3gpp-nr-nrm-nrcelldu:NRCellDU" : { "cId" : 412, "userLabel" : "yet-another-cell-label", ... } } }, { "edit-id" : 4, "operation" : "merge", "target" : "_3gpp-nr-nrm-nrcelldu:NRCellDU=4", "value" : { "_3gpp-nr-nrm-nrcelldu:NRCellDU" : { "cId" : 412, "userLabel" : "yet-another-cell-label", ... } } } ] } } Response : HTTP/1.1 200 OK Date: Thu, 26 Jan 2017 20:56:30 GMT Server: example-server Last-Modified: Thu, 26 Jan 2017 20:56:30 GMT Content-Type: application/yang-patch+json { "ietf-yang-patch:yang-patch-status" : { "patch-id" : "change-cell-and-carriers", "ok" : [null] } } NOTE : Passthrough only. Not supported in ONAP Release I. 7 | Delete a data resource for a cmhandle DELETE {ncmp-root}/ncmp/v1/ch/<cm-handle>/data/{data-resource-identifier} Scenario: Delete Method : DELETE URI : {ncmp-root}/ncmp/v1/ch/34l5k32/data/Header : Accept: application/json Body : {} passthrough-running is supported in Istanbul using
ncmp-datastores:running is not supported in Istanbul for delete 8 | Get all cmhandles that support a given | module GET | {ncmp-root}/ncmp/v1/data/ch?module={module-name} | Content: application/json Scenario : Get the all cmhandles that support a given module Response: 9 | Get model info for CMHandle GET | {ncmp-root}/ncmp/v1/ch/{cm-handle}/data/ietf-yang-library:modules-set Scenario : Get the model data for CMHandle Method : GET URI :{ncmp-root}/ncmp/v1/ch/2334dedf/data/ietf-yang-library:modules-set Header : Response: { passthrough-running is supported in Istanbul using
ncmp-datastores:running is not supported in Istanbul for delete 10 | Execute a yang action POST | {ncmp-root}/ncmp/v1/ch/<cm-handle>/data/ds/ncmp-datastores:passthrough-running/{data-resource-identifier}/{action} Note : If the "action" statement Method : POST URI : {ncmp-root}/ncmp/v1/ch/3445fff/data/ds/ncmp-datastores:passthrough-operational/ Header : Body : passthrough-running is supported in Istanbul using
ncmp-datastores:running is not supported in Istanbul 11 | Execute an rpc operation POST | {ncmp-root}/ncmp/v1/operations/ch//operations /ds/ncmp-datastores :passthrough-operational/{module-name}:{action} { Note : If there is no "input" Method : POST URI : {ncmp-root}/ncmp/v1/operations/ch/3445fff/ds/ncmp-datastores:passthrough-operational/_3gpp-common-managed-element:resetDevice (dummy action) Header : Body : Response : passthrough-running is supported in Istanbul using
ncmp-datastores:running is not supported in Istanbul 12 | Read descendant data resources with GET | {ncmp-root}/ncmp/v1/ch/<cm-handle>/{data-resource-identifier}?fields={fields-expression} options
Scenario : Read all NRCellDU MOs with attributes userLabel and id under the _3gpp-nr-nrm-gnbdufunction:GNBDUFunction MO Method : GET URI :{ncmp-root}/ncmp/v1/ch/3445fff/data/ManagedElement[@id=Kista-001] Header : Response : HTTP/1.1 200 OK { _3gpp-nr-nrm-nrcelldu:NRCellDU=1 { _3gpp-nr-nrm-nrcelldu:NRCellDU=4 { _3gpp-nr-nrm-nrcelldu:NRCellDU=5 { passthrough-running is supported in Istanbul using
13 | Read data resources to a given depth POST {ncmp-root}/ncmp/v1/ch/<cm-handle>{data-resource-identifier}?depth={level}
Method : POST URI : {ncmp-root}/ncmp/v1/ch/3445fff/ManagedElement[@id=Kista-001]/GNBDUFunction[@id=1]?depth=4 Header : Body: Response : HTTP/1.1 200 OK _3gpp-nr-nrm-nrsectorcarrier: _3gpp-nr-nrm-nrsectorcarrier:NRSectorCarrier=3{ _3gpp-nr-nrm-nrsectorcarrier:NRSectorCarrier=4 { _3gpp-nr-nrm-nrcelldu:NRCellDU=1 { _3gpp-nr-nrm-nrcelldu:NRCellDU=4 { _3gpp-nr-nrm-nrcelldu:NRCellDU=5 { passthrough-running is supported in Istanbul using
ncmp-datastores:running is not supported in Istanbul 14 | Replace a data resource for a cmhandle PUT ncmp-root}/ncmp/v1/ch/<cm-handle>/data/{data-resource-identifier} { <yang-data-resource-identifier> } Scenario : Replace _3gpp-nr-nrm-nrsectorcarrier:NRSectorCarrier=4 txDirection Method : PUT URI : {ncmp-root}/ncmp/v1/ch/34l5k32/data/ManagedElement[@id=Kista-001] Header : Body : { passthrough-running is supported in Istanbul using
ncmp-datastores:running is not supported in Istanbul 15 | Async Requests GET/ | POST/ PATCH /PUT/ DELETE {ncmp-root}/ncmp/v1/ch/<cmhandle>/data/ds/ncmp-datastores:passthrough-running/ {xpath}?topic=<dmaap-topic-Identifier> **Async communication channel is DMaaP Immediate response with a requestId is sent to the caller and the CRUD request is executed asynchronously where data is returned via the provided topic identifier. Scenario : Async request to NCMP Method : GET/POST/PATCH/PUT/DELETE URI : {ncmp-root}/ncmp/v1/ch/de3455/data/ManagedElement[@id=Kista-001]/GNBDUFunction[@id=1]?topic=5G:SectorCarrierOrchestrator-0012391:12 Body : // Include body where required Response : response data is published on the topic identified by <topicIdentifier> keyed on request. Event Successful Reponse : 16 | Request (trigger) Data Sync | GET | {ncmp-root}/ncmp/v1/ch/node123/operations/sync | YesScenario : Client requests to sync a node Method : GET URI : {ncmp-root}/ncmp/v1/ch/node123/operations/sync Response : |
NCMP / DMI Overview
Expand | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...