Model discovery at runtime

Owned by Tony Finnerty
Last updated: Sept 11, 2020 by Benjamin Cheung
2 min read

By making the coupling that occurs in the data lake explicit, the concept of model ownership is introduced.

This essentially means that control of model and data access will be distributed. 

The distributed nature of model and data access control raises the question of how will a data user know what data is available and where to get permission to access it.

This was driven from a 5G use case need: Model & Access Flows

Decision

The scope of the CPS will include a 'Registry Service'

Details

  1. µService A provides its model to C&PS. Models may come from design time. There is a page on model ingestion: Flow of models into the system

  2. µService A registers its model with the 'Registry Service'. The registration includes details of the owning service and meta data that can be used in queries for models. Some examples might be "antenna", "3GPP", "SON", "5G NRM". It might be meta-data extracted from the model itself by µService A. These are essentially "contracts" between µService A and µService B. The concept is that the meta-data characterizes the model. It declares that it has ownership of this type of information.

  3. µService A retrieves data from an xNF (e.g. PNF#106)

  4. µService A stores data related to the xNF (and compliant to the model) in the CPS

  5. µService B queries the registry to determine if (a) matching models exist and (b) which µServices own them. Assumption is that Registry Service has a list of the model meta-data keywords, like "dictionary/directory/index" of meta-data words.

  6. 'Registry Service', provides a list of matching µServices

  7. µService B requests access to model and data from µService A. µService B is aware of the Yang Model. There is a "standardized" interface between µService A & B. The asking for permission establishes a inter-dependency of the µServices.

  8. µService A grants (or denies) access to models and data – E.g. permission in the form of a secure token. the design of the security token management will incorporate the concept of how often, when, and if µService B can access the data, which could effectively resolve the problem of race conditions.

  9. µService B uses the permission (e.g. token) to access the CPS.

  10. The CPS provides data related to the xNF compliant with the model

Q: A snap shot of dependencies? Auditing & mapping.

Q: GeoLocation → xNF#106 → A&AI → Place object → Geolocation ... C&PS → index xNF#106 → A&AI → Place object

Discussion

This issue was discussed during the weekly meeting Sep 4, 2020