References

Assumptions


IssueNotesSign-off
1on CM Handle Life Cycle Management (LCM) Events will be augmented with Alternate IDs

Out of scope (for this epic) All of below needs be considered for CPS-2008 - Update existing single sync cmhandle APIs to support alternative id (containing FDNs) and CPS-2009 - Update remaining existing/legacy NCMP APIs to support alternateId (FDN)

  1. Events
    1. Data Async Operation (events)
    2. CM Subscription LCM Events
    3. DIM Data AVCs
    4. NCMP Data AVCs (AlternateId could be the attributeName of an AVC)
    5. TrustLevel
  2. Synchronous Requests
    1. data requests
    2. module information requests
    3. cm handle queries (state, properties)
  3. Synchronous Responses e.g. but no limited to) 
    1. CM Data response (payload doesn't include cm handle ids either)
    2. Registration (error) responses
    3. Module Information Requests
    4. Registration updates (e.g. delete by alternate Id)

Issues & Decisions


IssueNotesDecisionSign-off
1

Should version of schema definition be updated (to v2) for lcm-event-schema-v1

Change is backward compatible. So new version not needed?
Can old clients read new messages?!
Typically marshalling can be configured to ignore 'new fields'

(Csaba has checked, clients are ignoring 'unknown' fields)

Keep event name (if possible)

  1. do NOT change version foe legacy event update
  2. do change version when upgradign to CloudEvent format

Toine Siebelink 
Kieran Mccarthy A 

2

CM Handle LCM events are not a cloud events yet

2 components have to be updated, Csaba will check impacts required.
Options

  • Prepare client for Cloud Events
  • backward compatible legacy event first

CPS Team prefers convert to cloud event first  


CPS are to keep Legacy events. Till //EE are ready to take cloud event on their side- CPS-2058

Kolawole Adeolokun Toine Siebelink Kieran Mccarthy A @Peter T  

3The Alternate Id will be available only in the LCM Message (body) not as a header Part of review of proposed cloud event structure
Might want to create a custom extension for 'alternate id' (to be able to filter)



4Should the alternateId be included in the Values (newValues/ oldValues) part of the event? 

In initial implementation alternateId was included in the Values part of the event, so if alternateId is changed from an empty string to some string an empty string should be present in the oldValues and some new string should be present in the newValues. But this isn't the case since the lcm event is only sent when the state is changed e.g going from ADVISED to READY.

This can be replicated with cmHandleProperties.

Topology  consumes LCM event.  We only need NEWvalues

AlternateID would appear as part of the body (Body/old/new)

It's should not appear in the old/new at all.

Should this event be sent if some propoerty changes ? - No 

It's only expected to change when the LCM statechanges

  

  Kolawole Adeolokun Kieran Mccarthy A Jeff Van Dam 

Requirements

Functional

Interface

Requirement

Additional Information

Sign-off
CPS-E-08.ENCMP shall send notification LCM CLOUD events which will include the Alternate Id
  • The Correlation ID will still be populated with the cm-handle id (in Ericsson's case a MD-5 hash)
  • The Alternate ID will be used by Ericsson for storing 3GPPP compliant FDNs

Kolawole Adeolokun Kieran Mccarthy A @Peter T  

Error Handling

No obvious error scenarios that need discussion

Characteristics

No new requirements but as Alternate Ids needs to be looked up it is important to note that producing LCM events (or related responses such as registration) should not be (significantly) delayed by this requirement. The previous Epic already implements a distributed cache for Alternate Ids. Design does not expect any such impacts and no specific performance testing is required. Assume that existing performance regression test in CPS and Client Side will highlight if we are wrong here  

Out-of-scope

  • All other events  and synchronous responses (see details in assumption #2)

Solution Proposal

Current Event Definitions


lcm-event-header=v1 (FYI only, not changing) Expand source
lcm-event-schema-v1 (current) Expand source

Proposed Changes

  1. Add single field to lcm-event-schema-v1 (or v2, see open issue #1):
PayloadalternateIddataStringNoAlterative Identifier for CM Handle (e.g. 3GPP FDN)<free text>oud-alternative-id

Element

Name

Parent

Type

Mandatory

Description

Format

(example) Value

Proposed User stories





1

Add alternatId to lcm-event-schema-v1



Notifications on LCM

Proposal for Notification's Schema

Cloud event Definition


ElementNameParentType   MandatoryDescriptionFormat(example) Value
1Headerid
StringYesrandom id for cloud event header. UUID is suggested

source
StringYessource of informationncmp.<cmhandle-id>ncmp.12ac34e43556e
specversion
StringYescloud event version specfixed value1.0
type
StringYestype of eventfixed valuelcmEvent
dataschema
StringYes

data schema

fixed valueorg.onap.cps.ncmp.events.lcm.1_0_0.LcmEvent:1.0.0
correlationid
StringYesThe cmHandle which is been notified. The value will be similar as we have in the source field<cmhandle-id>12ac34e43556e
2Payloaddata
ObjectYesThe actual data payload. Data details provided below3GPP TS 28.532 standard
cmHandleIddataStringYescmHandle id<cmhandle-id>12ac34e43556e
alternateIddataStringYesAlternative identifier for CM Handle (e.g. 3GPP FDN, blank if not defined)<free text>our-alternative-id
oldValuesdataValuesNoOld values of the state of the cmHandle. Values details provided below

newValuesdataValuesNoNew values of the state of the cmHandle. Values details provided below 

dataSyncEnabledoldValues | newValuesBooleanNoWhether data sync enabled<true | false>true
cmHandleStateoldValues | newValuesStringNoState of cmHandle<enum>READY
cmHandlePropertiesoldValues | newValuesList<Map<String,String>>NocmHandle properties

alternateIdoldValues | newValuesStringNoused when modified only (data.alternateId will always have the latest value)<free text>our-alternative-id
  • No labels