ONAP Data Modeling Proposal for Casablanca ONAP Resource

ONAP Data Modeling Proposal for Casablanca

ONAP Resource Data Model Recommendation for Casablanca • Separation of On-boarding Model (e. g. , SOL 001) from Internal ONAP Resource Data Model for Design-Time and Run-Time • Need to also consider multiple alternative for VNF On-boarding, both now (e. g. , HEAT, TOSCA), and in the future (e. g. , YANG, etc. ) • On-boarding artifacts will be accessible within ONAP to support ONAPETSI points of interoperability and adaptor mediation • Internal ONAP Data Model will be guided by ETSI SOL 001 VNFD and the ONAP Resource Information Model - Mapping Internal ONAP Data Model with ETSI SOL 001 and ONAP IM maintained. - Internal ONAP DM may provide an ONAP optimized representation - Open-source velocity and agility requires that ONAP extensions be identified (e. g. , PNFs, ANFs) and fully modeled within ONAP - Feed ONAP extensions back to ETSI for consideration

ONAP as a Black Box VNF Provider ETSI SOL 004/SOL 001 On-Board & Refinement Service Designer enriches on-boarded VNFDs; Artifacts preserved Service Designer Creates Service Descriptor ONAP YANG, SOL 004/SOL 006 Open. Stack HEAT • ONAP has a broader functional scope than ETSI MANO (i. e. Service Orchestration and full Lifecycle Management), therefore the ETSI Data Model is not sufficient to drive ONAP behavior • ONAP needs to be agile and move quickly • ONAP as a Black Box supports Standards at the edges (e. g. , ETSI, TM Forum, MEF, HEAT) and preserves on-boarding artifacts BSS/OSS Service Creation and Lifecycle Management MEF LSO TM Forum Cross Domain VNFM Adaptor * Adaptors apply SOL 003 artifacts ETSI Compliant 3 rd Party VNFM * Use of VNFM Adaptor is only one use case

ONAP Needs Beyond ETSI-MANO • ONAP services many not all have VNFs • ONAP services may be customer facing or infrastructure • ONAP supports allotted resources (using part of service B as a resource in service A) • ONAP will support abstract resolution at runtime (e. g. , a Firewall might be a PNF, VNF, or Allotted NF) • ONAP will manage the service lifecycle (where service != ETSI network service but instead is a service in support of a customer facing product)

Improve end to end model driven behavior ONAP DM Goals: Evolve the Platform • Improve service and platform development and management velocity - Flexible creation of services - Clear correlation between design time and instance model - Automation, leveraging machine learning and AI • Reassure vendors that standards will be supported - Standard are good, there could be more than one, they evolve (so even within one there may be multiple versions) - Ensure the onboarded asset is available end to end • Use an internal platform data model which is predictable and consistent • Lay groundwork for advanced features like runtime abstract resolution of node types

Achieving the Goals: Evolve the Platform via ONAP-Owned Model Evolution • Replace custom logic, arbitrary conventions, and initial lesssophisticated designs using industry-standard cloud computing semantics • Ensure that industry-standard VNF assets work with ONAP end to end through lossless translation and preservation of onboarded assets • ONAP has its own internal data model evolved by those who plan to apply it - Introduce very simple type hierarchy needed for future runtime abstract resolution (VNF, PNF, ANF) - Add instance attributes to types without cluttering up the design-time view to result in instance data model - Different operators could use different additional instance attributes to support their LCM world • Introduce uniform ONAP interfaces and workflows

Click edit Hierarchy Master title style Initial ONAP Data Model Concepts Basicto. Type Showing Effective node types tosca. node s. Root Add Service node type A-R requires provider service tosca. capabil ities. Root <<trait>> identity <<trait>> states onap. nodes. Resource onap. nodes. Co nnection. Point PNF requires PNF Device onap. nodes. PNFDevice onap. nodes. Ne twork. Function onap. nodes. Netw ork. Function. Comp onent onap. nodes. Service onap. nodes. Virtual. Link onap. capabilities. Allotted. Resource Provider

Standards on the Outside, ONAP DM on the Inside ETSI – one standardization organization Goal – creation of a standard… … supported by all vendors … providing comprehensive VNF description … compatible with multiple platforms (not only ONAP) … promotes its own architectural vision ONAP – a software development collaboration Goal – creation of a software product… … able to run in commercial environments … open to multiple input standards (not only ETSI) … cost-effective in creation, and operation of services - by being model-driven, by freedom of architectural decisions SDC Vendor Package VNF Onboarding Refinement Service And VNF Modeling e. g. , SOL 001 -> ONAP DM ETSI SOL 001, others ETSI VNFDs (SOL 001): one onboarding format, a solid base for extensions in ONAP, vendors should not have to deal with divergence Distribution To Runtime Components ONAP DM + original Artifacts ONAP model: drives the platform, higher velocity of change, multiple onboarded formats Lossless Transformation: preservation of the vendor-provided information as a requirement; The vendor provided VNF Package (including VNFD) remain available across ONAP DM Vendor Package

Examples/Specifics

Leverage Native TOSCA Semantics • Replace custom logic for lifecycle with uniform reusable interfaces and workflows • Use requirements, capabilities, and relationship types - to express accurate relationships between nodes - to guide declarative workflows - to replace arbitrary coding conventions, e. g. , network-role mapping • Preference for well-defined data types - to allow TOSCA node filters - to have model driven property validations

Type Hierarchy • Use inheritance in a simple way to enable runtime resolution of types but avoid the complications of inheritance • <New> Introduce a Service node type for all SDC-defined ONAP services - Common properties/attributes for all service-instance runtime objects - Composition (nesting) into higher-order services via substitution - Service-level workflows via life cycle management (LCM) interfaces • Service instances made up of resource instances and/or other service instances • Resources are the building blocks of services - Principal subcategories are network functions and virtual links, but others may exist - Resource-level workflows via life cycle management (LCM) interfaces • <New> Network Functions encompass virtual (VNF), physical (PNF) and allotted (ANF) - Categorization based on requirements/capabilities (not sub-types) • Physical requires a PNF Device • Allotted requires a providing service • Virtual requires neither - Composed of Network Function Components

Runtime “Effective” Types • Runtime Types are effectively the Design Time types plus associated instance attributes • Runtime Components can base API payloads and platform logic on the Effective Types in a predictable way • Specific additions in derived type can be handled in a common, declarative way • One approach: the illustrative concept of Traits - groupings of one or more attributes which, through configuration, get related to the node types which should include them - keeps design time types clean • Runtime Catalog will be responsible for combining the design time TOSCA node types with the traits to create the effective node types • Expectation that the CSAR distributed from the runtime catalog is based on the effective types

Allotted Resource • Allotted Resources represents a portion of a service which is allotted for use by another service • Current (R 2) implementation has flaws - Uses a custom allotted resource base node type which prohibits abstract resolution at run-time - Uses metadata to identify a node type as an allotted resource - Uses a property to store a foreign key reference to the providing service type (via metadata) • Instead use requirements/capabilities (TOSCA semantics) - “Allotted Resource Provider” capability on providing service node types - Dangling requirement on Allotted Resource node types for an Allotted Resource Provider - Run-time selection of providing service instance by OOF (SNIRO) - Facilitates abstract resolution at run-time

Runtime Abstract Resolution • Allows a Service Designer can choose a concrete or abstract component • Support abstract node types for pre-defined network function abstractions, e. g. , firewall, router, etc. • Concrete node types derive from the abstract type, allowing for their use as a runtime replacement -- Use TOSCA type-based abstract node resolution • VNFs, PNFs, and Allotted Resources may all derive from the same abstraction • OOF(SNIRO) resolves which concrete node type to use, based on specific optimization criteria, e. g. , performance/throughput, target cloud, supported features, etc. • SO orchestrates the resulting concrete node type in place of the abstraction

ONAP Lifecycle Interfaces • Define a uniform ONAP lifecycle interface - Based on the specific NFV domain of ONAP, with the established orchestration pattern of assignment, creation, configuration, and activation of resources - Define on Service and Resource node types. - Do not extend to atomic cloud elements (VNFCs, Ports, etc. ) at this time • ONAP lifecycle operations - Orchestration: assign, create, configure, activate, delete, unassign - Scaling: scale-in, scale-out - Others TBD as needed • Well defined mapping between ONAP and ETSI lifecycle operations • Allows declarative workflows based on TOSCA topology traversal - Common SO workflows will work with any service model in a standard traversal - Custom SO workflows for individual service types may be defined as needed, based on the same operations.

Left for future releases • APIs • Layers – Monitoring • Flavors