CPS-2166: Forwarding CM Data Notifications based on Subscription

References

CPS-2166 - Getting issue details... STATUS

	Assumption	Notes
1	Topic name extracted from Subscription ID
2	One client can have multiple subs
3	Topic is setup correct and can write
4	CM Events contain CM Handle IDs (and NOT alternate IDs) so the correct subscriptions can be identified

Issue

Notes

Decision

1

Choose alternative for forwarding

Alternatives
NCMP forwards the CM Data Notification:

as multiple CM Data Notifications on a common external topic with a special header indicating the client-id so the client can filter
as one CM Data Notification on a common external topic with a special header containing ALL client-ids (Array or String with special token separation)
to topic(s) registered by client(s) during Subscription creation

Option 3 further expanded as functional requirements 1 &2

2

Even if clients specify the topic upon subscription creation, can multiple client share the same topic?

Only applies to alternative #3 above

Req

Functional

	Requirement	Additional Information	Signoff
1	Topic used for forwarding notification should be based on the client-id which can be extracted from the subscription-id	Need to agree and document the format of the subscription-id	tbc, kieran mccarthy / Csaba Kocsis to review and comeback
2	Client application shall ONLY receive notification they subscribed on
3	Client application shall not see notification they did not subscribed on
4
5	~~Subscription-id shall be in the event header~~	~~Also, this mean multiple event to the same topic.~~	~~tbc~~ ~~kieran mccarthy /~~ ~~Csaba Kocsis to review and comeback this requirement as it may also impact performance~~

	Parameter	Expectation	Notes	Signoff
1	Each NCMP instance shall support 150M CM notification change events per day
2	NCMP shall support horizontal scaling to support > 150M CM notification change events (Daily)
3	NCMP shall support processing CM notification change events with the following subscription profile : 40% of subscriptions shall process 5% of all network change notification events 30% of subscriptions shall process 10% of all network change notification events 15% of subscriptions shall process 30% of all network change notification events 9% of subscriptions shall process 50% of all network change notification events 5% of subscriptions shall process 70% of all network change notification events 1% of subscriptions shall process 100% of all network change notification events
4	Upto a 150M cm-handle is incoming the outgoing should not exceed >200m CM handle per NCMP
5	Overlapping CH-Handle


1

Subscription Merge Example

CM Data Notifications Overview
Which are of interest to which Client (subscription ID)

	Cm Handle	Path	A-10	B-52
1	CH-1	/p/c1	Yes	No
2	CH-1	/p/c2	Yes	Yes
3	CH-1	/p/c3	No	Yes
4	CH-4	/p/c2	No	Yes
5	CH-4	/p/c3	No	Yes
6	CH-1	/p/c4	No	No

NCMP (currently) listens to all CM Data Notifications (on an 'internal' topic
NCMP queries its own persistence service to find out which Client(s) are interested in the notifications A-10 and/or B-52
(3 alternatives, see issue #2)