You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 35 Next »

References

Requirements

Functional


Interface

Requirement

Additional Information

Signoff
1CPS-E-08eNCMP will forward 'CM Notifications Subscription' LCM Create events to the appropriate DMI Plugins responsible for the CM Handles (ids) defined in the LCM Events. 
The message sent to DMI should include the private properties for each CM-Handle

 

2CPS-E-08eNCMP will forward 'CM Notifications Subscription' LCM Delete events to the appropriate DMI Plugins responsible for the CM Handles is defined in the LCM Events. 
The message sent to DMI should include the private properties for each CM-Handle

'Basic' delete we be implemented followed by a more advanced delete operation depending on Merge functionality:  CPS-1812 - Getting issue details... STATUS


3CPS-E-08eNCMP responds using Kafka message(s) with the result of the LCM operation
These messages wil use agreed status fields:
  • StatusCode  (to be included in documentation)
  • StatusMessage
  • result
  • errorInfo  (NEW to be fleshed out)
Action: Define error details later


4CPS-E-08eAll events should use Cloud Events formathttps://cloudevents.io/

5CPS-E-08eMessages should be processed in the order they are created (received)It will depend on DMIs responding within 30s.
Subscription-id should be used as Kafka 'key' to ensure this.

6CPS-E-08.eNCMP is to merge CM Notification Subscriptions create request and forward those to DMI plugin. (Interface to be added).
  • Prevent unnecessary subscription updates to nodes already involved in a subscription to the same path and datastore.
  • For possible combinations, see table below

7CPS-E-08.e

Last lights out: upon subscription Delete request only when there is no more subscription for a cm-handle & xpath & datastore combination a subscription-delete request will be sent to the relevant DMI(s).


8CPS-E-08.eA single client subscription request should result into a maximum of one request per DMI. Of course there can be several messages if more than 1 DMI is involved.

9CPS-E-08.eAmalgamate response should include rejected/accepted/pending DMI responses received within 30 seconds. A client shall be notified of available DMI subscription information after 30 seconds.  Subsequent DMI subscription updates shall be notified to clients as they become available.
  • Same schema for all notifications.
  • Subsequent notifications contains the state of all cmhandles involved in the subscription. 

10CPS-NCMP-I-01CM Handle deletion should NOT update subscription details. Do NOT delete dmi-subscription entry until owning subscription is deleted, see issue #4 below

11CPS-E-08.eBackward compatible with 'basic' created/delete operations.. 


Error Handling ( To be captured as part of  CPS-1865 - Getting issue details... STATUS )


Error Scenario

Expected behavior

Sign-off

1Non responding DMIs (configurable timeout)An error message listing the 'pending' CM Handle IDs and statusMessage as "partially applied subscription" with relevant statuscode.
2Non Existing or non-valid CM Handle IdsAn error message listing the 'rejected' CM Handle IDs 
3DMI Plugin without CM Event subscription supportAn error message listing the 'rejected' CM Handle IDs 
4Late Response (after timeout defined in #1) from DMIA message contain the status message as "fully applied subscription" with relevant status code.
5Create for existing subscription id

6delete for non-existing cm handle id(silently?) ignore
7delete for non-existing subscription id

8Error upon error

An error scenario on a second subscription for the same cm-handle/xpath as a previous subscription which did not complete successfully (yet)

to be discussed, see Error Upon Error Combinations


Characteristics


Parameter

Expectation

Notes

Sign-off

1Frequency of LCM EventsNo high volume of such events is expected
For testing purposed 1 LCM event per minute would suffice

2Number of SubscriptionsMax: 200

kieran mccarthy confirmed

3CM Handles per Subscription

Avg: 200

Max: 500 (document only)

kieran mccarthy to confirm
Note: consider limit and future 'simple' ALL (wildcard) option when above that limit

4Xpaths per Cm HandleAvg: 10

kieran mccarthy 

5Status update processing time(Order of 30) seconds (NCMP side)

kieran mccarthy 

Out-of-scope

  1. Subscription Update scenarios for an ongoing subscription.
  2. CM Notification Forwarding Check: When forwarding CM Notification NCMP will not check the content to see if the is a valid active subscription. It is assumed that the DMI Plugin as acted on the 'delete subscription' request (that request is NCMPs responsibility). And of course there wil be timing issues it also possible a CM Notification was send just after the subscription-delete was send (from client) but before the whole change had acted upon that. 
  3. Retry: NCMP will only report when actions are pending or rejected. NCMP will not implement a retry mechanism
  4. Wildcards: Wildcards or similar functionality where one string represent 0 or more xpaths is not covered as part of this requirement but it should be kept in mind as a future possibility
  5. Dynamic Topic: Topic for CM Data Notifications back to client will be hardcode for now. 
    Study should consider compatibility with an 'ALL' cm handles options

Assumptions


Assumption

Notes

1Targets is a collection of xpathscan be implemented as a json array of strings
2for the DMI plugin cm-handle-id, datastore and xpath are the key to a unique subscriptionthe client-id and subscription name are not relevant for the DMI (should not be included in the request) as this would break the concept of merging!

Issues & Decisions


IssueNotes Decision
1Is it intended that CM Notification subscription request  cover (all) descendants of the given xpath too?!e.g.. if a child is removed and there is a subscription for the parent node, will a notification be send (grandchild, child leaf updates etc.) I hope NOT!
Consider:
  • Risk of client effectively subscribing to ALL data in a cm handle by specifying top level datanode(s)
  • Complexity (i.e. cost of) of merge operation. It might even required NCMP to check relevant dat model
  • Future use of wildcards, could be a viable alternative for including descendants

2Could xpath point to an element that does not exist (yet)if not how, how can I client be informed about a create event? 

3Should NCMP support re-homing, moving of a CM Handle from one DMI to another?assume only trough delete & create 

4CM Handle Delete: Should DMI or Clients be sent a subscription update 

do NOT delete dmi-subscription entry until owning subscription is deleted
(just ignore upon future delete if cm handle is gone altogether)

Note. LCM is already broadcast (today) 


  • Need to upgrade to CloudEevent format
  • Add subscription id (name+client id) to header (so client can filter)
5Validation of xpathoptions order of implement and also performance cost!
  1. none
  2. xpath-parser
  3. model check
  4. instance check

6can DMI plugin 'reject' a subscription create (for a given cm-handle-xpath combination)As NCMP might not validate as per issue#5 the DMI=plugin or component further down might have to reject an invalid xpath...

Priyank Maheshwari 

yes currently DMI can use response to say which cm handles are not accepted i.e. rejected' (but not 'pending') 

7implementation question: should 'rejected' DMI-subscriptions be storednot needed as whole subscription should be rejected

8Dimensioning of DB depends on #cm handles, #subscriptions and #xpaths per subscription, this could be too big for fast processing of updates! Need to agree maximum and possibly realistic average/total number of entries based on the characteristics  above
The team is blocked until this becomes clear as it wil affect the way the data needs to be modelled exactly		ongoing but not completed!
9Maximum (error) message sizetheoretically all cm handles and all xpaths combinations could be rejected or pending leading to a very large error message!

10can each CM-Handle have different set of xpath(s) per subscriptionthe  current 'basic' solution only supports a common set of datastore/xpaths (filter)

11can the same cm handle/xpath have different subscriptions with different datastores, does that affect the cm data notifications send (which datastore applies)
  • can register on any (passthrough) datastore
    • running
    • operational

  • compulsory, validation needed
  • part of KEY (unique entry) so cmHandle+datastore+xpath is the key 


Although this wiki-page will not be updated where cmHandle+xpath is mentioned as  unique entry etc. this should now include a third field: datastore as well.

12Will migration from 'basic' be supportedPreferred to ask customers to create new subscriptions

13list v list instances filtering

/p/c1
/p/c1[@key=23]
Are these different paths or not (from ncmp point of view)
*List instances might not always be supported, depending DMI Plugin impl.

14confirm subscription id (currently subscription name + client id)


15what subscription details should be send when there is a change (in the union)
  1. just delta
  2. just union
  3. union and delta (delta flagged) 

16one DMI rejects whole (see decision #6) subscription (affected cmhandles) but other DMI accepts the same subscription, is this possible how to handle

17What all datastores are supported ?

ncmp-datastore:passthrough-running or ncmp-datastore:passthrough-operational ??

or both?


Solution Proposal

State handling for initial (basic)subscription create/delete use cases (not using concept of 'merging')

Scenario 1
1) Create Sub from Client: CH-1, CH-2
2) All handled by DM1
3) NCMP to DMI request Create sub:  CH-1, CH-2
DMI responds within 30 seconds: Status OK

NCMP Send message to client: Statsu OK (no list with Rejected/Pending)


Scenario 2
1) Create Sub from Client: CH-1, CH-2
2) All handled by DM1
3) NCMP to DMI request Create sub:  CH-1, CH-2
DMI does NOT respond with 30 seconds

NCMP Send message to client: Pending [CH-1, CH-2]

Scenario 3
1) Create Sub from Client: CH-1, CH-2
2) All handled by DM1
3) NCMP to DMI request Create sub:  CH-1, CH-2
DMI responds within 30 seconds: Rejected [CH-2]

NCMP Send message to client: Rejected [CH-2]

Scenario 4:
4 different DMIs each handling 2 Cm Handles, create sub for all CHs 

Scenario 4-part a
DMI1 CH-1, CH-2 All accepted within 30 secs
DMI2 CH-3, CH-4 Mixed result within 30 seconds e.g. Rejected [CH-4]
DMI3 CH-5, CH-6 No result after 30 seconds
DMI4 CH-7, CH-8 No result after 30 seconds

NCMP -> Client : Rejected [CH-4], Pending [ CH-5, CH-6, CH-7, CH-8 ]

4-part b
DMI3 PLugin responds after 40 seconds; status OK
NCMP -> Client : Rejected [CH-4], Pending [ CH-7, CH-8 ]

4-part c
DMI4 PLugin responds after 50 seconds; Rejected [CH-7]
NCMP -> Client : Rejected [CH-4, CH-7]

Note. The above algorithm depends ons storing (in DB using yang modelled data) a cm-handle status for each cm-handle for each subscription!

Merge → Split

  • NCMP treats a Client Subscription as one or more (small) DMI Subscriptions, each of which wil have there own state.
    Each DMI Subscription is related to 1 or more client subscriptions.
    If there is no more related client subscription the DMI Subscription can be deleted (once accepted by DMI Plugin)!

Data Model (not a great diagram...)

 

Create Combinations

Below examples demonstrate what should happen when two separate subscriptions operations are performed:

  1. an operation on subscription 'A' for client id '10
  2. an operation on subscription 'B' for client id '52'
#Existing Subscription A-10Client Create Subscription B-52 RequestDMI Sub Create RequestData Model Before (2nd) CreateData Model After Create
1CH-1, [ /p/c1, /p/c2 ]CH-1, [ /p/c1 ]None
Client  Subscription
DMI Subscription
nameclient-idcm-handlexpathsubscribers
A10CH-1/p/c1[ A-10 ]


CH-1/p/c2[ A-10 ]
Client  Subscription
DMI Subscription
nameclient-idcm-handlexpathsubscribers
A10CH-1/p/c1[ A-10, B-52 ]
B52CH-1/p/c2[ A-10 ]
2CH-1, [ /p/c1, p/c2 ]CH-1, [ /p/c2, /p/c3 ]CH-1, [ /p/c2, /p/c3 ]
Client  Subscription
DMI Subscription
nameclient-idcm-handlexpathsubscribers
A10CH-1/p/c1[ A-10 ]

CH-1/p/c2[ A-10 ]
Client  Subscription
DMI Subscription
nameclient-idcm-handlexpathsubscribers
A10CH-1/p/c1[ A-10 ]
B52CH-1/p/c2[ A-10, B-52 ]

CH-1/p/c3[ B-52 ]
3CH-1, [ /p/c1]
CH-2, [ /p/c1]		CH-2, [ /p/c1]
CH-3, [ /p/c1]		CH-3, [ /p/c1]
Client  Subscription
DMI Subscription
nameclient-idcm-handlexpathsubscribers
A10CH-1/p/c1[ A-10 ]

CH-2/p/c1[ A-10 ]
Client  Subscription
DMI Subscription
nameclient-idcm-handlexpathsubscribers
A10CH-1/p/c1[ A-10 ]
B52CH-2/p/c1[ A-10, B-52 ]

CH-3/p/c1[ B-52 ]
4CH-1, [ /p/c1]CH-1, [ /p/c1/gc1 ]

CH-1, [ /p/c1/gc1 ]

*as per decision 1 the xpath to a parent does NOT include any children...

Client  Subscription
DMI Subscription
nameclient-idcm-handlexpathsubscribers
A10CH-1/p/c1[ A-10 ]
Client  Subscription
DMI Subscription
nameclient-idcm-handlexpathsubscribers
A10CH-1/p/c1[ A-10 ]
B52CH-1/p/c1/gc1[ B-52 ]

Create 'Merge' Diagram

Below diagram shows and example for two subscriptions with party overlapping CM Handles and XPaths.

Subscription Merge Example

* Note 1: given the possible combinations the message to DMI needs to be able to specify different xpaths per cm-handle. So a more complex structure is needed for this even ie. an array of CM Handles objects each having their own list of (target) xpaths!
Note 2: as per decision #11'datastore' should be included in all messages as well

Delete Combinations

#Existing Subscription A-10Existing Subscription  B-52Client Delete A-10 RequestDMI Sub update/delete requestData Model* Before BeforeData Model* After Delete
1CH-1, [ /p/c1, p/c2 ]CH-1, [ /p/c1 ]
CH-1, [ p/c2 ]
Client  Subscription
DMI Subscription
nameclient-idcm-handlexpathsubscribers
A10CH-1/p/c1[ A-10, B-52 ]
B52CH-1/p/c2[ A-10 ]
Client  Subscription
DMI Subscription
nameclient-idcm-handlexpathsubscribers
A10CH-1/p/c1[ A-10 ]

CH-1/p/c2[ A-10 ]
2CH-1, [ /p/c1]
CH-2, [ /p/c1]		CH-2, [ /p/c1]
CH-3, [ /p/c1]

CH-1, [ /p/c1]


Client  Subscription
DMI Subscription
nameclient-idcm-handlexpathsubscribers
A10CH-1/p/c1[ A-10 ]
B52CH-2/p/c1[ A-10, B-52]

CH-3/p/c1[ B-52 ]
Client  Subscription
DMI Subscription
nameclient-idcm-handlexpathsubscribers
B52CH-2/p/c1[ B-52 ]

CH-3/p/c1[ B-52 ]
3CH-1, [ /p/c1]

CH-1, [ /p/c1]
CH-2, [ /p/c1]
None
Client  Subscription
DMI Subscription
nameclient-idcm-handlexpathsubscribers
A10CH-1/p/c1[ A-10 ]
B52CH-1/p/c2[ A-10, B-52 ]
Client  Subscription
DMI Subscription
nameclient-idcm-handlexpathsubscribers
B52CH-2/p/c1[ B-52 ]

* Note:  as per decision #11'datastore' should be included in the 'DMI susbcription' data model too now. 

Error-Upon-Error Combinations


Previous InteractionCurrent InteractionExpectationNotes
1any operation on rejected for non-existing cm-handleoperation for same non-existing cm-handlelisted in 'rejected' immediatelybehavior as normal
2create operation rejected by DMIcreate for same cm-handle/xpathtry again ?!
3create pendingcreate for same cm-handle/xpathTBD send again or just remain pending?!
4create pendingdelete for same cm-handle/xpath

5delete pendingdelete for same cm-handle/xpath

6delete pendingcreate for same cm-handle/xpath

Client-Schema Update

Based on Issue#10 , the incoming schema from DME to NCMP should

  • A single subscription contains multiple predicates
  • Predicates should be an array of Predicates ( currently a single instance )
    • Each predicate contains an array of targets ( cmhandles) - as is.
    • Each predicate contains a single datastore (mandatory) 
    • datastore-xpath-filter should become an array of xpath-filters (instead of pipe separated single string)

Performance considerations

Below options (partly) explored dring CPS teem meeting

  • DMI record could reach in millions of instances
  • In memory solution (ie hazelcast) can handle 10s - 100s of Megabytes (add some sample calc)
    • still need persistence if we don't have enough instances
  • use many small messages reduce need for amalgamation
  • amalgamated string-based solution.... 

Storage Solutions

Proposed Data Storage

Use a combination of

  1. Database (yang modelled) for permanent subscription details, subscribers, predicates
  2. In-Memory (hazelcast) for transient subscription details:  state (acceptep, rejected, pending)

Example Flow 1: First Subscription

  • We have the below configuration managed by CPS-NCMP

    #cmhandledmi-plugin
    1ch-1dmi-1
    2ch-2dmi-1
    3ch-3dmi-2
    4ch-4dmi-2
    5ch-5non-responding-dmi

  1. We get a Subscription Create Request with unique subscription-id and a list of predicates(list of targets , datastore and list of filters)

    Subscription Create Message 
    {
"subscriptionId" : "A-10",
"predicates" : [
  {
    "targets": [ch-1,ch-2],
    "datastore" : "ncmp-datastore:passthrough-operational",
    "datastore-xpath-filter" : ["p1/c1","p2/c2"]
    },
  { "targets": [ch-3],
    "datastore" : "ncmp-datastore:passthrough-operational",
    "datastore-xpath-filter" : ["p3/c3"]
    }
]
 
}
  2. We persist the incoming request as is in our persistent store using a relevant subscription model ( this model also needs to be revised )

  3. We also maintain a distributed datastructure in Hazelcast to keep track of the request and response to the client.

    SubscriptionIddmi-pluginaffectedCmHandlesstatus
    A-10dmi-1["ch-1","ch-2"]PENDING
    A-10dmi-2["ch-3"]PENDING
  4. Read the requests from the distributed data structure and form the request for the DMI-Plugin and publish it to the internal kafka channel.
  5. If the DMI-Plugin responds back within the configured time , so the request will either be ACCEPTED or REJECTED.
    1. if whole subscription request is ACCEPTED , update the distributed data structure and then store the subscription to the ActiveSubscriptions in cps-cache.
    2. if whole subscription request is REJECTED , update the distributed data structure and send back the response to the client.

    3. if the DMI Plugin fails to respond then the status would remain PENDING only as there is no change.


      SubscriptionIddmi-pluginaffectedCmHandlesstatus
      A-10dmi-1["ch-1","ch-2"]ACCEPTED
      A-10dmi-2["ch-3"]REJECTED

  6. We store the "ActiveSubscriptions" using a new model which will look like below.

    SubscriptionIdcmHandlefilterdatastore
    A-10ch-1p1/c1ncmp-datastore:passthrough-operational
    A-10ch-1p2/c2ncmp-datastore:passthrough-operational
    A-10ch-2p1/c1ncmp-datastore:passthrough-operational
    A-10ch-2p2/c2ncmp-datastore:passthrough-operational

  7. Now based on whatever we have in the distributed map , we will send the response to the clients and may be clear the in-memory structure if required.

Example Flow 2: Second Subscription (merge)


  1. We get a new subscription create request.

    2nd Subscription Create Message 
    {
"subscriptionId" : "B-52",
"predicates" : [
  {
    "targets": [ch-2],
    "datastore" : "ncmp-datastore:passthrough-operational",
    "datastore-xpath-filter" : ["p2/c2" , "p3/c3"]
    }
]
}

  2. We now look at the "ActiveSubscriptions"  if we already have an active subscription either for a combination of "cmhandle and xpath filter and the datastore".

    Current view of ActiveSubscriptions

    SubscriptionIdcmHandlefilterdatastore
    A-10ch-1p1/c1ncmp-datastore:passthrough-operational
    A-10ch-1p2/c2ncmp-datastore:passthrough-operational
    A-10ch-2p1/c1ncmp-datastore:passthrough-operational
    A-10ch-2p2/c2ncmp-datastore:passthrough-operational
    Check if we have ch-2 , p2/c2 and ncmp-datastore:passthrough-operational then directly add to the ActiveSubscription.Similarly check for ch-3 , p3/c3 and ncmp-datastore:passthrough-operational ( which in this case will not be directly to the active subscription)

  3. Now the state of ActiveSubscription is :

    SubscriptionIdcmHandlefilterdatastore
    A-10ch-1p1/c1ncmp-datastore:passthrough-operational
    A-10ch-1p2/c2ncmp-datastore:passthrough-operational
    A-10ch-2p1/c1ncmp-datastore:passthrough-operational
    A-10ch-2p2/c2ncmp-datastore:passthrough-operational
    B-52ch-2p2/c2ncmp-datastore:passthrough-operational

    and state of the in-memory data structure is as follows.

    SubscriptionIddmi-pluginaffectedCmHandlesstatus
    B-52dmi-1["ch-2"]PENDING
  4. Now we send the request to DMI plugin (dmi-1) with just the private properties of the ch-2 with the delta xpath.
    1. DMI Plugin could either apply the whole subscription request or reject the whole subscription. i.e respond with accepted/rejected

  5. Based on the response from DMI plugin the in-memory structure is updated and response is sent back to the clients.

    if DMI says it is accepted then : 

    SubscriptionIddmi-pluginaffectedCmHandlesstatus
    B-52dmi-1["ch-2"]ACCEPTED


    if DMI says it is rejected then : 

    SubscriptionIddmi-pluginaffectedCmHandlesstatus
    B-52dmi-1["ch-2"]REJECTED


    if we get no response within the configured time then :

    SubscriptionIddmi-pluginaffectedCmHandlesstatus
    B-52dmi-1["ch-2"]PENDING


    But we still send some response within the pre-configured time.

  6. if the above request was accepted then we should add it to the list of "ActiveSubscriptions" as well.

    SubscriptionIdcmHandlefilterdatastore
    A-10ch-1p1/c1ncmp-datastore:passthrough-operational
    A-10ch-1p2/c2ncmp-datastore:passthrough-operational
    A-10ch-2p1/c1ncmp-datastore:passthrough-operational
    A-10ch-2p2/c2ncmp-datastore:passthrough-operational
    B-52ch-2p2/c2ncmp-datastore:passthrough-operational
    B-52ch-2p3/c3ncmp-datastore:passthrough-operational
  7. If the status was accepted/rejected then after sending the response to the client we can clear the in-memory structure for subscriptionId B-52.

Kafka Topics

#Topic NameEnvironment VariableSourceDestinationNotes
1
subscription
NCMP_CM_AVC_SUBSCRIPTION
DMEDME/Client-Apps
2
ncmp-dmi-cm-avc-subscription-<dmi-name>
NCMP_FORWARD_CM_AVC_SUBSCRIPTION
NCMPDMI Plugin
3
dmi-ncmp-cm-avc-subscription
NCMP_RESPONSE_CM_AVC_SUBSCRIPTION
DMI PluginNCMP
4
subscription-response
NCMP_OUTCOME_CM_AVC_SUBSCRIPTION
NCMPDME/Client-Apps
5dmi-cm-events
DMI_CM_EVENTS_TOPIC
DMI PluginNCMPactual data notifications as per the subscriptions
6cm-events
NCMP_CM_EVENTS_TOPIC
NCMPDME/Client-AppsNCMP to forward the notifications to the client-apps.

Operation Specific Impl. Proposals

Create

Delete

  • No labels