Architecture Face to Face Planning Meeting ONAP Architecture – Modeling Inter-Relationship Andy Mayer; Deng Hui

ONAP Modeling Subcommittee Role Guide the development ONAP Abstractions and Constructs, and form and document Common Models: Provide a coherent view of shared information Identify common abstractions and constructs across ONAP Capture common terms and definitions with respect to shared information Help identify unplanned redundancy Mapping of information to interactions for common interfaces (and microservices) (Joint with Arch) Identify the primary authority (or Steward) and consumers for each piece of shared information from a functional perspective (Joint with Arch) Form a common Integrated ONAP Information Model and associated Data Models to be used as an integration resource (Federated approach) Define Model Versioning Strategy based on ONAP Common Versioning Strategy

How do we enable Model Driven ONAP? Re-Use 3 1 Use Model Create Model Common shared data Functions work off common model Data translation layer at edge SDC Environment Design Models Design Catalogs Data Dictionary 2 Deploy Model Run-time Models Run-time Catalog Common Model Parsers

Shared Architecture and Modeling Concerns Enablement of Model Driven ONAP Common definitions and models of Shared Information (and data models) across APIs and Microservices (Papyrus). Components identify inputs & outputs Identification of ONAP Components as “Source of Truth” and “Consumers” of Information (wrt ONAP Information Model) Lifecycle Stages of Information (e.g., On-Board, Design, Instantiate, Operate) Modeling of containerized VNFs and Multi-cloud requirements Hybrid Environment (VNFs, PNFs, ANFs) “ONAP of a Black Box” – Standards at the edges, ONAP inside ONAP Modularization Modeling as part of Architectural artifacts (e.g., data models, information models, state models, interaction diagrams, etc.) Participation of ONAP Components in transitioning to a target state