CPS Participant in CLAMP

Owned by Ramesh Murugan Iyer
Last updated: Feb 13, 2023
3 min read

Requirement:

This is to investigate the CPS participant implementation in CLAMP to interact with CPS-Core component in ONAP.

The participant should be capable of creating and querying  dataspace, schemasets and anchors in CPS-Core  based on the incoming requests. The CPS data can be used by other components in Automation Composition via the CPS participant.

CPS Overview:

The Configuration Persistence Service (CPS) is a platform component that is designed to serve as a data repository for runtime data that needs persistence.

Types of data that is stored:

  • Configuration Parameters

    These are configuration parameters that are used by xNFs during installation & commissioning. Configuration parameters are typically used before the xNF has been brought up or is operational. For example, a 5G Network configuration parameter for a PNFs that sets the mechanical tilt which is a configuration setting upon installation.

  • Operational Parameters

    This operational information could be either an actual state or configuration of a network service or device. These are parameters that are derived, discovered, computed that are used by xNFs during run time AFTER the xNF becomes operational i.e. AFTER it has “booted up”, been installed or configured. For example, in 5G Network, 5G PNFs may need to adjust a tower electrical antenna tilt. These operational parameters are Exo-inventory information, meaning it is information that doesn’t belong in A&AI. In principle, some parameters might be both configuration and operational parameters depending on how they are used.



CPS-Core Modeling:



Basic Concepts

Administrative entities:

  • Dataspace is a primary logical separation of data.

    Any application can define its own dataspace to store the model(s) and data it owns. Dataspace is uniquely identified by it’s name.

  • Schema Set describes a data model(s).

    Schema Set holds reference(s) to single or multiple YANG modules. Schema Set belongs to dataspace and uniquely identified by its name (within its own dataspace). Same YANG resources (source files) can be referenced by multiple schema sets from different dataspaces.

  • Anchor identifies the unique data set (data record) within a dataspace.

    Anchor always references a schema set within same dataspace which describes a data model of associated data. Multiple anchors may reference same schema set. Anchor is uniquely identified by its name (within own dataspace).

Data:

  • Data Node represents a data fragment.

    Each data node can have zero or more descendants and together they form a data instance tree. The data node tree belongs to an anchor.

    Data node is representing a data fragment described in a YANG model as a container and/or a list. The data described as a leaf and/or a leaf-list are stored within a parent data node.

    The data node position within a tree is uniquely identified by the node’s unique xpath which can be used for partial data query.



Open Api specification for CPS-Core:

openapi.yaml

Feasibility of using Http participant for CPS:

Http participant uses spring webclient to asynchronously execute http requests and prints the response in ACM.

CPS-Core exposes REST endpoints for creating and querying CPS data which can be invoked by http participant with few limitations.

Limitations:

  • Creating Schema set

              Creating schema set requires sending multipart file (yang model) in the REST request which is not supported by ACM http participant.

              POST: /v2/dataspaces/{dataspace-name}/schema-sets 

  • Forwarding the queried CPS data to other components is not supported.

               Http participant doesn't forward the response/result to other components. It only executes the request and prints the results. 

  • We may require to perform sequence of REST operations by creating dataspace, schemaset and anchors in CPS for a single microservice. This might increase the complexity of tosca template for http participant.

  • Http participant doesn't support on-request REST call invocation in the ACM RUNNING state. It fires all the requests when initialized and doesn't take any further request during runtime. (Works based on Tosca template, no endpoints exposed)



CPS participant design considerations:

 Require to support multiform data in REST request for creating schema set.

 On-demand support for querying CPS data during runtime ?

 Expose endpoints in CPS participant that are to be used by microservices in ACM ?

 How to make the microservices in ACM talk to the CPS participant for sending CPS requests?