ONAP Centralised Parser Distribution Atul Purohit Vodafone Date

ONAP – Centralised Parser Distribution Atul Purohit - Vodafone Date , 15 November 2017

Table of content • Present Operator Scenario(s) • Present ONAP Understanding • Parser Externalization Proposal • Some additional details from proposal

Present Operator Scenario(s) Vodafone Platforms BPMN 2. 0 Service Models ONAP Addressable Stack TMF Open Digital Architecture 3

Present Operator Scenario(s) Different Geographies / Operating Companies Different Stacks / Multiple Legacy Stacks 4

Present ONAP Understanding Deployment Model Run Time / Execution of Service Instance(s) or Operational Environment Design Time / Definition of Service Design BPEL HEAT RESTCONF BPEL ODL HEAT TOSCA Controller DG NETCONF YANG EMF is Eclipse Modeling Framework for Data Modeling - Supported in Eclipse IDE Neon (plugin might be required) I’m not familiar with SUPA – found in google that it’s one of IETF like YANG (might be a policy abstraction) DG is Data Graph based on Node JS / Node Red NFVO SVNFM YANG SDN SWIFT GVNFM EMS Service Conf. HEAT GLANCE DCAE YANG FCAPS OPENSTACK NEUTRON CINDER YANG Management Network Device Model EMF VNF in DC VNF in Core (lb, fw…) (EPC, IMS…) TOSCA EMF YANG HEAT YANG Policy TOSCA L 4 -L 7 L 1 -L 3 Runtime VNF-C APP-C Infra-C Network-C BPEL EMF A&AI DG YANG DG DG YANG SO HEAT SDC TOSCA Policy TOSCA Link to OASIS/TOSCA parsers: https: //wiki. oasisopen. org/tosca/TOSCA-implementations YANG

Present ONAP Understanding TOSCA-based Orchestration: Option 1 Execution Time Design Time Request SDC Service Orchestrator Tools for Declarative & Imperative Model Design Invo k Imp e Ope r lem ent ation atio n For each BPMN work step that delegates to the TOSCA Orchestrator: • Determine the associated TOSCA Service Template and associated Inputs • load into the TOSCA Orchestrator • Call TOSCA Orchestrator to perform the relevant action TOSCA Orchestrator Resource Model Rainy Day Option: Invoke Inverse Metadata Model Driven Orchestration Success/Fail Service Model Invoke Model Distribution Load Resource Model Runtime Catalog BPMN Determine toplevel workflow Design Catalog Service Model Preference to keep as simple as possible, to promote Declarative processing approach Upon receipt of a SO request, initiate appropriate top-level BPMN workflow. The TOSCA Orchestrator uses the Service Template to determine the proper Operations and sequencing thereof on the various Node Types

Present ONAP Understanding ONAP TOSCA-based Orchestration Proposal: Option 2 Execution Time Design Time Request Upon receipt of a SO request, initiate appropriate top-level BPMN workflow. SDC Domain Service Orchestrator Determine toplevel workflow Tools for Imperative Model Design Catalog Metadata Model Driven Orchestration Resource Model BPMN Service Model Success/Fail Resource Model Model Distribution Invoke Service Model Runtime Catalog Service Agnostic WFs Service Specific WFs For each service agnostic work step that delegates to the next level of workflow: • Determine the associated service workflow and associated Inputs • perform the relevant action The same BPMN workflow engine executes the two layer service workflows.

Parser Externalization Proposal (1/2) Under Lens : As – Is Proposal From Linux Foundation - Use both Declarative and Imperative workflow patterns for Service and Domain Orchestration Engines - Parser to be used inside execution engines, specific to component consuming models Design Catalog Runtime Catalog Service Model Resource Model Resource Model Service Orchestration Engine Domain Orchestration Engine ARIA Parser Design Service Templates Decode / Parse Service Templates & Distribute to Execution / Operational Platforms 8

Parser Externalization Proposal (2/2) Micro Service / API For Acquiring Parser (not a run time activity, but a definition push time activity) https: //wiki. oasisopen. org/tosca/TOSCA • Enhance “Design Time” TOSCA Templates to include models needed by A&AI, FCAPS Analytics, and all other modules in ONAP implementations • Enhance “Design Time” TOSCA Templates to include “Decoding” Parser Needed By Consumer(s) • Build a micro service in “Common Services Layer” to call OASIS / External Parser Validation Tool • As Long as Consumer has access to this common service call and a centralized mechanism to call requires parser, it can understand execute the required workflow / intent • Provides a commonality with external non ONAP components 9

Parser Externalization Proposal – Derived Requirements • Req. 1: Model consumers (SO, AAI, SDN-C etc. ) shall not maintain multiple parsers for consumed models • Req. 2: SDC provides a centralized distribution of models and parsers URI’s for both types of consumers: ONAP and non-ONAP • Req. 3: Micro-Service/API should be called for acquiring a parser - MS can be used for both internal and external models - MS can be consumed by both ONAP and non-ONAP components Proposal is to include Req. 1, 2 and 3 as part of the Carrier Grade Requirements list 10

Additional details from proposal (1/2) The Details Potential Challenges TOSCA Definition : Enhance to Mention Parser Version / Location / Name Space Flexibility of TOSCA Constructs to Define Additional Details Introduce Staging / Fetching Micro service to get TOSCA Parser Definition Response Times, Design Time or Publish Time Activity Micro service Invocation Conditions To Be Determined Service Version Change or Parser Version Chance (2 – Way Invocation) Target Release 2 or 3 (Work Out Roadmap) Detailed Proposal & Impact Assessment To Be Elaborated, Collect Feedback from Partners / Members Benefit 1 : Shared Intent With Existing & ONAP Stack Benefit 2 : Existing Stacks Conforms / Migrates To TOSCA Intents Benefit 3 : Global Parser Hosting / Management (OASIS, OPNFV, Apache etc…) Benefit 4 : Global Service Model Definitions, Inter – Op Between Existing B/OSS and ONAP 11

Additional details from proposal (2/2) • NS Package is created and includes Model and Parser URI per consumer - Models and Parser URI’s are distributed to all consumers by SDC - A consumer calls MS for retrieving an applicable parser from parsers repository Note: SDC R&D currently develops a parser based on the Open Stack parser and it may also be arranged as a MS • For Outside-ONAP components - Operator on-boards models and parser URI’s for consumers outside ONAP - SDC while parsing NS package recognizes the artifacts to be forwarded to consumers outside ONAP 12