ONAP Configuration and Persistence Service Po C Proposal

ONAP Configuration and Persistence Service Po. C Proposal And Architecture Overview

Po. C Proposal • Support model-driven support for Configuration Management in RAN, initially for SON use cases • “Current view” of network state - Analyze alignment with “historical view”, differences in performance characteristics and mechanisms for data lifecycle management • Enhance the current code in the CCSDK project • Po. C Proof points: - Demonstrate Create/read operations using YANG fragments against a CPS backed by very simple schema / schema-less repository - Demonstrate ability to deploy / upgrade YANG fragments at runtime - Demonstrate CPS behavior driven by YANG model augmentation - Provide architecture vision and roadmap for a target architecture, supported use cases, non-functional requirements towards an ONAP Project 2

Timing and Resourcing (preliminary planning) • June 2 – July 24 th - Technical analysis and architecture planning - Presentation at DDF, ONAP Arch Forum, Modelling Subcommittee - Ramp up developers in ONAP community (3 x Ericsson) • July 24 th – October (aligned with G release date? ) - Iterative project execution • August 28 th - Project checkpoint & proposal for new ONAP project in H release 3

Po. C steps 1. Augment / modify / create initial code framework according to the target architecture 2. Define generic SQL schema (start of SPI) 3. Provide transformers for YANG (selected subset of capabilities) 4. Write data compliant to YANG, see this in the database 5. Read data from database, display as a YANG tree/doc 6. Validate input (start of API definition) 7. Iterate steps 2 and 5, adding more YANG language capabilities - Enhance the schema and SPI as needed, document findings and limitations - Socialise the approach with the community – in particular the SON / NW Slicing UC developers 4

Basic Po. C approach Yang language features: 1. Simple primitives 2. Parent/child relationships 3. References 4. Augmentation 5. … Yang 2 Java mapping Schema update Language feature support SPI & API update • Iterative development • Balance up-front analyses with coding and demonstrations • Contribute ‘ready’ code/interfaces to main CPS project (CC-SDK or standalone) 5

Configuration & Persistency Service Target Architecture & Po. C Details (preliminary)

CPS in context – Work in progress • Data access - CRUD/REST • Model access - Type safety • Model LCM - @ Runtime • State pass-thru - Reading volatile x. NF state • DBMS integration - Polyglot persistence - License variants 7

CPS – Exploded 1 st level 1/3 – Work in progress • Model - React to CSAR deployment at runtime - REST LCM interface for use by controllers or x. NF discovery at runtime - Model access to help interpret/format received/input data 8

CPS – Exploded 1 st level 2/3 – Work in progress • CRUD/REST - Main interfaces, uses library component internally • CPS library - Core implementation, uses models to drive behavior and validation - Delegates to a ‘stateproxy’ for volatile x. NF data 9

CPS – Exploded 1 st level 3/3 – Work in progress • SPI - Provides abstraction to DBMS - Enables polyglot persistence strategy - Decouples licensing and packaging • DLMS - Moves data to appropriate data repository as indicated by behavior encoded in model 10

DLMS Discussion – Separation of concerns • Auto triggering a write to the historical store is OK • The read interface is sufficiently different to (current store read) that it suggests a separate interface • The CPS be not be the only source of write operations to the historical store – PM; Counter; KPI; … - Could be looked at a means to enrich PM/analytical data with time relevant CM state/information • Complicates Model LCM. When can a model be removed if it is needed to interpret long retained data? Separation of concerns - Loose coupling between DLMS and CPS • Notifications (configured by model) - No implicit read access to historical store via CPS 11

DLMS Discussion – Separation of concerns • Separated deployment of DLMS 12

CPS as a library – Work in progress • For performance reasons it may be desirable to codeploy CPS as a library in other ONAP components. • This is an example of the content and dependencies that would entail 13

Generic schema & Java binding transformation • Analysis of YANG language features - This can take a while to be comprehensive, so we need to analyse/code in parallel • Selection of simple constructs - Basic types; simple references; hierarchy • Selection of simple YANG model to exercise chosen constructs - E. g. SON use case has a simple model • Mapping of YANG primitives to Java types • Mapping of YANG constructs to Java types 14

Example of generic schema for relational DB 15

Data access (and type safety) • CRUD interface design. We need to decide: - Object orientated – the object provides methods to access parents, children, etc. - Behaviour oriented – the interface provides methods to access parents, children, etc of a specified data item - Document – The interface consumes/produces json/yaml/xml fragments - DAO – The interface consumes/produces java objects (possibly with nested structures? ) - REST (service) interface design - Java (library) interface design - Validation (inline; library) 16

Target aware • Use of ‘augmentation’ to decorate YANG (x. NF) models with CPS behaviour characteristics. E. g. : - Pass thru (for volatile state data) - Copy update to time series DB - Access control configuration • Alternative: Use a separate CPS owned model to reference x. NF (runtime added) models, thus capturing behaviour characteristics without ‘polluting’ the x. NF model. 17

Model addition @ runtime • Demonstrate new model deployed causes: - No schema update - No CPS down time - The ability to add/read data related to new model without client restart Supported model sources: 1. Design time (SDC), CSAR via DMaa. P 2. Discovered (Yang model from x. NF) via *controller and REST endpoint for model LCM 18

Future consideration At which stage (maybe now) do we need to consider: 1. Implications of (advanced) YANG features on minimal Schema? • • 2. 3. 4. 5. Augmentation Deviations When Default values (impact on queries? ) Role based Access Control (does this impact minimal schema)? Target based Access Control (does this impact minimal schema)? Data sizes used in minimal schema i. e. 255 characters for an fdn/path? Supported query types • get all children • (non-optimized) attribute value queries • (non-optimized) attribute presence queries (has attribute x) 19

Notes from 2020 -05 -15 • Select concrete real-world YANG models as proof points • Begin by looking at some of the simpler YANG models to prove the capability • Iteratively build up the picture over time • Need to prove that it works with multiple types of YANG models • The YANG model in the SON use case is very simple and should be a good place to start • Need to in parallel look at how these models extend the ONAP architecture / information model • Should not need to review all models in order to support them through ONAP – YANGcompliant models should be supported OOTB for model driven tooling to interact with 20

Interface design Early brainstorming

Interface design: Data access, CRUD • REST interface for: - Low frequency; low volume; shared data model access • Java interface for: - Internal (CPS pod) use - High frequency; high volume model access • Transaction boundaries? - Likely the underlying DBMS is transactional, what if any of these semantics should be exposed - What guarantees will be provided to the user w. r. t. read after write; replication; propagation; …? • Typical data will be x. NF CM data – what impact will this have on the design of the interface? - How to address CM data of specific x. NF instance? - How to distinguish between x. NF instances? • Java, documents, structures - YANG fragment in documents - Data Access Objects (model driven) – when are classes generated? How are they published/loaded? - Library to interpret YANG fragments using model, mapping to primitive java types? • Model driven applications –vs. Highly typed applications - Applications coupled to the low level schema only (YANG types and relations) - Applications coupled to the higher level constructs (Cell; RU, DU, VLAN…) 22

Interface design: Model access • Raw model - The YANG document that describes the model • Model augmentation (or meta-data) - Information added to the YANG document to make it usable to the CPS (and other applications) • Model in specific java format - Offload the interpretation of the native format to a set of java classes that may then be made available to other consumers of the model. This can make documentation and use of models much easier. 23

Interface design: Model LCM • Model LCM Users: - x. NF via controller - CSAR via SDC and DMaa. P - ? ? ? Application providing ‘augmentations’. Example: dynamically tag state from a new x. NF model to be replicated to a time-series DB ? ? ? • Add model - Load model - Generate any entities required; update validation rules - Notify • Remove model - Mark for deletion when model is no longer in use Check for usage Remove Notify 24

Interface design: DBMS, SPI • Essential to keep schema as simple as practicable in order to enable a broad cross-section of DBMS technologies • Decide if any transactional semantics need to be visible ‘above’ this interface. Example: - A single persisted structure that merges data from several sources (syslog; x. NF CM state; …) - Different protocols, languages & models used to source data - Contention, race condition Consistent data in structure, • only want to read fully consistent structure • Need to update structure with related change - Transactional boundaries; Tracking state embedded in structure; … 25

Interface design: Data Lifecycle Management Server • DLMS Invoked by the CPS core library when triggered to do so by meta-data associated with a given model - E. g. when certain information is tagged as relevant to time series analysis, each change is propagated to a 2 nd DBMS together with any contextual information required (such as the source of the change user, x. NF, controller, policy, …) • Purpose is to asynchronously update subordinate DBMS • Non-transactional, best effort? • Uses the same DBMS SPI as the CPS core library? 26

Interface design: State access delegate • When asked (via CRUD interface) for (state) data that is volatile on the x. NF and not persisted locally, the CPS will request (based on model) a delegate to retrieve state data from the correct instance of the x. NF - Transparent to the CRUD user Requires sufficient information to uniquely identify the instance of the x. NF Transactional and other characteristics to be determined? Implementation may be provided by controller or dedicated ONAP component 27