Control Loop Roadmap Control Loop Objectives Control Loops

Control Loop Roadmap

Control Loop Objectives • Control Loops should be able to be added deleted or modified outside the Development Cycle • Control Loops should be able to operate in either a Closed or Open fashion - Closed Control Loops trigger action directly through an orchestrator or controller to make modifications to the VNF - Open Control Loops notify an operator that something needs to be done 2

Frankfurt SSCL Policy Development: Developer defines Policy in a Tosca model Service Designer Component Spec Designer-Editable parameters (Not changeable post-deployment) DCAE Designer GUI Source-atdeployment parameters (Not changeable post-deployment) Policy Model ID used by the m. S Policy developer Set parameter values (minimize to none if possible) Policy model ID included in BP Deployment Flow Artifact Post-Deployment Runtime DCAE Inventory Ops API Ops OOM m. S developer Onboarding API m. S Development: Developer defines parameters & classifies them into 3 categories in spec. json: 1. Designer-editable 2. Source-at-deployment 3. Policy model ID Each parameter value can be set by the developer with default, and given restrictions: • No default value (empty field) or a default value (a value in the field) • Additional restrictions • A specific set of values (e. g. , 1, 3, 5, 7) • A range of values (1. . 10) Design time El Alto BPG Development time CLAMP GUI Set/override Policy parameter values Develop & Onboard policy model (Tosca) policy 3

Control Loop Run Time Flow OSS / BSS / Ticketing 5 4 3 Policy DCAE 5 SO 6 Controller 7 VNF 1 2 1. 2. 3. 4. 5. 5. 6. VNF data exhaust DCAE analyzes VNF Data If a policy is triggered then event sent to Policy Analyze event against other policies (Closed) Send result to orchestrator or controller (Open) Send to OSS/BSS/Ticketing system If result is sent to orchestrator then SO orchestrates action through controller 7. Controller modifies VNF as appropriate 4

Control Loop Artifacts Data collectors within DCAE • These are responsible for collecting performance and metric data from the VNFs Analytic Micro. Services within DCAE microservice Blueprints • These are responsible for doing the analysis of the data that was collected from the VNFs • Microservice Blueprints describe the microservice and are held within the DCAE Platform. The blueprints are used when it is time to deploy the microservices into their runtime environments DCAE Workflows Policies Policy Models • DCAE Workflows are used to describe how the microservices are linked together and how data flows from one microservice to the next. • Policies basically tell ONAP what to do if a certain event takes place. These are model based and may be added, deleted, or modified outside of development cycles • These describe the content of Policy Types. The actual content may change without affecting the model 5

ONAP Control Loops • Service Specific • May contain multiple analytics • May contain multiple policies • May trigger actions directly with a controller or may use SO for more complex orchestration. • Control Loops are objects that are designed and configured within CLAMP • Since Control Loops are service specific their piece parts must be distributed with the service. - Some pieces are built and described within DCAE and later linked to the service via CLAMP 6

Roadmap Where we have been Where we are going • Beijing: Subcommittee kickoff • Dublin: Model Driven Control Loops, • Self Serve Control Loops • TOSCA Compliant Policy Types • Policy Update Notifications • CLAMP Deployment of Policies to PDP Groups • CDS as a Control Loop Actor • Control Loop Tutorial • Blueprint refactoring to support shared microservices • BPG for TOSCA workflows • CLAMP support of PNFs • Policy design using filters and triggers • VES Event Registration • Standard CL Event format to VES • Event Based Common API for CL Operations • Distributed Control Loop Deployment 7

s