Page History

Requirements

Functional

...

Requirement

...

• Prevent unnecessary subscription updates to nodes already involved in a subscription to the same path
• For possible combinations, see table below

...

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

...

Error Handling

...

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

...

Characteristics

...

Out-of-scope

1. 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. 
2. Retry: NCMP wil only report when actions are pending or rejected. NCMP will not implement a retry mechanism
3. 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
4. Dynamic Topic: Topic for CM Data Notifications back to client will be hardcode for now

Assumptions

...

Issues & Decisions

...

• 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

...

1. none
2. xpath-parser
3. model check
4. instance check

...

...

Solution Proposals 

Current state handling for 'basic' (not merged) subscription create/delete (under development)

...

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)

...

NCMP Send messge 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 witin 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 diagram shows and example for two subscriptions with party overlapping CM Handles and XPaths.

* Note: 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!

Delete Combinations

...

...

...

...

...

...

...

Error-Upon-Error Combinations

...

Performance considerations

Below options (partly) explored dring CPS teem meeting 02 Aug 2023 could explore further once we know the characteristics, see issue #8 !

• 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 intsances
• use many small messages reduce need for amalgamation
• amalgamated string-based solution.... 

Proposed JIRAs

...

This study is now included in CM Data Notification Subscription LCM (incl. merge)