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
Please note this section was added long after the implementation and focuses on characteristic only. |
Issues | Notes | Decisions | |
---|---|---|---|
1 | 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 |
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 | 2.5 | N/A | 20,000 CM Handles i.e. 100*20.000 = 2MB | TBD will be derived when testing is done in ETH envi ETH/Daniel Hanrahan | TDB | |
4 | CM-handle search with Module filter | 2.5 Run in parallel with #3 | N/A | 20,000 CM Handles i.e. 500*20.000 = 10MB | TBD will be derived when testing is done in ETH envi ETH/Daniel Hanrahan | TDB | |
5 | Synchronous single CM-handle pass-through read | 10 | Awaiting input from eth Csaba Kocsis | 5 KB | 25 (parallel) request/sec | Read are done in parallel with Write | TDB |
6 | Synchronous single CM-handle pass-through write (CUD) | 10 | Awaiting input from eth Csaba Kocsis | 5 KB | 13 (parallel) request/sec | No response is expected | TDB |
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. |
|
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
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]. |
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 :
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 |
|