Versions Compared

Version Old Version 12 New Version 13
Changes made by

Kolawole Adebisi-Adeolokun

Kolawole Adebisi-Adeolokun

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

References

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyCPS-2166

Assumptions


AssumptionNotesSign-off
1One client can have multiple subs

kieran mccarthy, Toine Siebelink  

2Topic is setup correctly (by clients) and NCMP will have write accessMaybe not by client but definitely NOT NCMP responsibility

kieran mccarthy, Toine Siebelink  

3CM Events contain CM Handle IDs (and NOT alternate IDs) so the correct  subscriptions can be identified This could change in the future but has lower priority

kieran mccarthy 

Issues & Decisions


IssueNotes Decision
1Choose alternative for forwarding

Alternatives
NCMP forwards the CM Data Notification:

  1. as multiple CM Data Notifications on a common external topic with a special header indicating the client-id so the client can filter
  2. 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)
  3. to topic(s) registered by client(s) during Subscription creation

kieran mccarthy and Toine Siebelink

Option 3 further expanded as functional requirements 2 & 3

2Even if clients specify the topic upon subscription creation, can multiple client share the same topic?Only applies to alternative #3 above

kieran mccarthy NO, see also assumption 1

3Characteristics wil be discussed  after functional delivery and some performance testKakfa is assume NOT to be a limiting factor

kieran mccarthy , Toine Siebelink 

Requirements

Functional


InterfaceRequirementAdditional InformationSignoff
1Client-defined topic

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


Proposed by CPS

"<topic-name>---<unique-id>

 

eg. a client then would create (or own) a topic 'our.cm-channel'

then by convention they can create subscription ids like so:

 

'our.cm-channel---0001'

'our.cm-channel---0002'

'our.cm-channel---4g-cell-subscription'

'our.cm-channel---5g-cell-subscription"


Assumption - We'll get a subscriptionId and topicname


tbc, kieran mccarthy / Csaba Kocsis  to review and come back.

Currently NCMP receives event and it doesn't contain Topic name.

Issue - NCMP still need topic name.
 kieran mccarthy to confirm and revert 

 

Event format shall be subscriptionId and topicnamekieran mccarthy Kolawole Adebisi-Adeolokun Priyank Maheshwari Csaba Kocsis 

long term focus shall be on the rest interface(push) for rapps

2Client-defined topic

Client application shall ONLY receive notification they subscribed on


kieran mccarthy Toine Siebelink  

3Client-defined topicClient application shall not see notification they did not subscribed on

kieran mccarthy Toine Siebelink 

4Client-defined topicSubscription-id shall be in the event headerAlso, this mean multiple event to the same topic. 

agreed NOT to support this for performance reasons and clients can always create multiple subs. if needed

Error Handling


ScenarioExpected BehaviorNotes
1Subscription ID format not correct i.e. cannot extract out a valid topic name


2topic does not exist


3no write access to topic


4cannot find subscription  based on cm handle/path in event


Characteristics


ParameterExpectationNotesSignoff
1

incoming CM notification change events

150M Events / day~1,736 Events / second! per NCMP instance! 
2

outgoing CM notification change events

200M Events / daycaused by overlapping subscriptions 
3

NCMP shall support horizontal scaling to support >> 150M CM notification change events (Daily)


  1. Do we need to define a maximum ?
  2. Do we need to define an acceptable overhead ie 2 instance will  (probably) NOT process 2 x 150M = 300M Events day

4

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

This breakdown does NOT really affect NCMP performance and does not need to be 'mocked' or simulated exactly for testing purposes
BUT we should test with multiple subscription and 1 out of 3 events wil go to 2 different topics (as per #2)
5

Consider Peak load ? ie. 100M events in 1h





Overview

Gliffy
size1200
displayNameSubscription Merge Example
nameSubscription Merge Example
pageid177080337

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


Cm HandlePathA-10B-52
1CH-1/p/c1YesNo
2CH-1/p/c2YesYes
3CH-1/p/c3NoYes
4CH-4/p/c2NoYes
5CH-4/p/c3NoYes
6CH-1/p/c4NoNo




Solution Proposal

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