References
CPS-1065 - Getting issue details... STATUS
Open Issues & Decisions
| # | Issue | Notes | Decision |
|---|---|---|---|
| 1 | List scenarios | Need to clarify scenarios | Refer to Internal study |
| 2 | Topics | what topics are used in what scenario (topic for each Datastore ?) | See Topics section below.
cm-events topic name should be configurable in deployment settings.
|
| 3 | Handle unknown event schemas | Wrap event? | Unsupported for now. Thrown exception and log error. |
Event Flow Sketch
CM Event Specification Outline
{ "eventId" : "9999", # some generic event uuid generated by DMI Plugin "event": { } |
|---|
RFC 8641 : yang-datastore notification definition
notifications: +---n push-update | +--ro id? sn:subscription-id | +--ro datastore-contents? <anydata> | +--ro incomplete-update? empty +---n push-change-update {on-change}? +--ro id? sn:subscription-id +--ro datastore-changes | +--ro yang-patch | +--ro patch-id string | +--ro comment? string | +--ro edit* [edit-id] | +--ro edit-id string | +--ro operation enumeration | +--ro target target-resource-offset | +--ro point? target-resource-offset | +--ro where? enumeration | +--ro value? <anydata> +--ro incomplete-update? empty |
|---|
'operation' type definition
Event Payload Example
| Proposed CM event |
|---|
{ "eventId" : "9999", # some generic event uuid generated by DMI Plugin "event": { "push-change-update" : { "datastore-changes" : { {
} } } |
CM Change Event Subscription Proposal
Create Subscription
The Create Subscription flow is as follows :
Subscription Steps :
- NCMP is configured at startup with the cm subscription topic information (cm topic name, kafka addressing info).
Some app sends a 'CreateSubscription' event to the public cm subscription topic (cm-event-subscription).
Create Subscription : client app → ncmp Create Example {
"version": "<event type version>",
"eventType": "subscriptionCreated",
"event": {
"subscription": {
"clientID": "<unique identifier for the client >",
"name": "<unique subscription name per client>",
"isTagged": "<yes|no>, optional parameter, default is no"
},
"dataType": {
"dataspace": "<data space>",
"dataCategory": "<data category type>",
"dataProvider": "<data provider type>"
"schemaName": "<schema name>"
"schemaVersion": "<schema version>"
},
"predicates": {
"<parameter>": "<value>",
"param2": [
"value21",
"value22"
]}
}
}{
"version": "1.0",
"eventType": "subscriptionCreated",
"event": {
"subscription": {
"clientID": "SCO-9989752",
"name": "cm-subscription-001"
},
"dataType": {
"dataspace": "ALL",
"dataCategory": "CM",
"dataProvider": "CM-SERVICE"
"schemaName": "org.onap.ncmp.cm-notification-event"
"schemaVersion": "1.0"
},
"predicates": {
"datastore": “passthrough-operational",
"datastore-xpath-filter": "//_3gpp-nr-nrm-gnbdufunction:GNBDUFunction/
_3gpp-nr-nrm-nrcelldu:NRCellDU/ | //_3gpp-nr-nrm-gnbcuupfunction:GNBCUUPFunction// |
//_3gpp-nr-nrm-gnbcucpfunction:GNBCUCPFunction/_3gpp-nr-nrm-nrcelldu:NRCellCU// |
//_3gpp-nr-nrm-nrsectorcarrier:NRSectorCarrier//”}
}
}- NCMP receives consumes the create cm subscription event and processes it as follows :
- Persist the subscription and cm-subscription-filter information to db
- Read all CM handles that match the cm-filter-subscription (model matching, cmhandleId matching)
- If a subscription is already ongoing for a cmhandle then separate them from the list for later processing (after the existing ongoing cmhandle subscription has completed).
- Merge the existing cmhandle filter (if one exists from a previous subscription) with the new cm-filter-subscription
- Record the cmhandles whose existing cm subscription filter has been modified after filter merging in step c)
- For the cmhandle(s) with a new or modified subscription filter, group them according to their controlling dmi-plugin and send one or more bulk subscription request(s) to the appropriate dmi-plugin(s).
- the bulk subscription REST request to each dmi-plugin contains either a 'create' (where no previous subscription exists on the cmhandle) or an 'update' subscription for each cmhandle
- the REST request to the dmi-plugin is asynchronous. The dmi-plugin shall process the each of the subscription requests per cmhandle and send an event only for cmhandles that fail to subscribe successfully.
| Usecase | Participants | Request Schema | Request Example |
|---|---|---|---|
| Register Subscriptions | ncmp → dmi | Protocol : REST { | Protocol : REST { |
5. dmi-plugin loops through the cmhandle subscriptions and creates a new subscription or modifies an existing subscription for the remote 'device' associated with the cmhandle.
6. dmi-plugin calls back to NCMP to notify of the newly created or updated subscription
7. NCMP updates its subscription registry with the new subscription information
| Usecase | participants | Request Schema / Example | NCMP Action |
|---|---|---|---|
| Notify of create subscription request success on passthrough-operational datastore -success case | dmi → ncmp | Protocol : Kafka Event {
} | register the new subscription data with the cmhandle : Store the datastore subscription data in the cmhandle. Also store the administrativeState that may be used to prevent race conditions between parallel subscriptions being applied. cmhandle data in NCMP DB "subscriptions" : { "running" : { # 'local' ncmp subscription is required with the cmhandle - store subId separately? "passthrough-operational" : { "passthrough-running" : { }
|
| Notify of modify subscription request success on passthrough-operational datastore -success case | dmi → ncmp | Protocol : Kafka Event {
} |
8.
Update Subscription
Topics
Topic types
| Topic Name | Description | Direction |
|---|---|---|
| cm-avc[-<targetgroup>] | topic for publication of events from NCMP to clients (suggest to rename existing topic from 'ncmp-events' to cm-avc). In preparation to future needs the there may be separate topics for different security groups. NCMP solution should consider this in its design this upfront. By default cm-avc is the default topic where ALL events are published by default. Different client may subscribe to different topics (ALL and/or target group specific). It is their responsibility to subscribe to the appropriate topics as new target groups come into existance. For now the only topic in scope of this story is the 'cm-avc' topic. | ncmp → client consumer |
| dmi-cm-events | internal topic for communications between dmi-plugin ↔ ncmp for avc and subscription events | ncmp→ dmi |
| cm-avc-subscription | topic for avc event subscriptions. This topic may be (pre)defined external to NCMP. If externally defined topic then it shall be possible to tell NCMP the topic name and where to find it. | client → ncmp |
| cm-avc-dmi-subscription | topic for avc event subscriptions event toward dmi plugin(s). This topic is internally defined by NCMP. All CM AVC subscriptions will be sent from NCMP to DMI plugins via this topic. | ncmp → dmi for subscription LCM dmi → ncmp register device subscription in cmhandle |
Topic partitioning
All events for the same cmhandleId should be sent to the same partition. This will guarantee ordering. Ordering is only guaranteed per topic, not across topic (future consideration).