1. TOSCA Native Service Orchestration SO State of the Union
Dec. 12 , 2017
Santa Clara, CA
DeWayne Filppi, Cloudify CTO Office

2. Agenda R1 Review: What happened, what didn’t R2 Preview: What’s next
TOSCA Service Orchestration Modeling
ONAP TOSCA Service Orchestration Modeling
TOSCA in SO Trajectory

3. ONAP R1 SO TOSCA - Delivered
Requirements and R1 Contributions
ARIA must be callable from Camunda and/or seed code
Contribution: REST API
Contribution: ARIA Java Binding
ARIA needs to fit in ONAP deployment model & be a microservice
Contribution: ARIA Docker Image
ARIA needs to communicate with MultiVIM service
Contribution: ARIA ONAP MultiVIM plugin
vCPE use case
TOSCA VNF vCPE infrastructure template (HEAT equiv)

4. TOSCA Orchestrator in SO: ARIA
ARIA TOSCA App Developer SDK
ARIA Command Line Interface
TOSCA App Development Guide
CSAR Packager
TOSCA Reference Example Templates
ARIA Parser
ARIA Store
ARIA Workflow Engine
TOSCA Simple Profile 1.0
Models Store
Graph Declarative Workflows
Imperative Workflows
Artifacts Store
TOSCA for NFV Profile 1.0(csd03)
Built-in Declarative
Workflows
Storage Driver
(sqlalchemy)
ARIA Plugins
Execution Plugins
IaaS Plugins
SDN Plugins
NFV Plugins

5. ARIA DOCKER CONTAINER Made available on Dockerhub: cloudifyco:aria
Features:
Lightweight, uses Alpine base image
Exposes REST API
Built with Cloudify ARIA extensions
Includes Cloudify plugins:
Openstack
AWS
Will be available in Nexus Docker repo soon.
May move outside of SO.

6. ONAP R1 SO TOSCA - Ambitions
TOSCA Service Modeling
Many tentacles/dependencies
Modeling, SDC
Internal (SO) discussions
TOSCA VNF Infra Modeling
HOT equivalent role
Late compromise
ECOMP merge

7. ONAP R2 SO TOSCA Minimum - HEAT ONAP Equivalence
TOSCA VNF infra template in place of existing HOTs
Inputs derived from TOSCA CSAR containing package
Support of layered templates (TOSCA VF modules)
IAAS
Parent template
Child template
IAAS API
Outputs
Inputs
MultiVIM

8. ONAP R2 SO TOSCA Full Integration With Core BPMN
Approach: Post SDNC/OF fork
Implications:
ONAP TOSCA types for AAI, MultiVIM, APPC
Python APPC/DMaaP API
SDC ONAP Base type integration (potentially)
SDNC & OF ONAP types recognition/compatibility
SO/ARIA BPMN recognition and handoff (via inputs)
includes mapping tenant info to ARIA template names & processing outputs
ONAP aware workflows (at least install/uninstall)
DCAE init ( BPMN or TOSCA workflow )
Enhance/complete ARIA REST API, improve microservice impl
Minimum proof of work: pure TOSCA vCPE install/uninstall

9. The Critical Role of Modeling Standards
In order to have model driven, you need:
Models
Models for services and VNFs
Clear definition of VNF orchestration (VNFM?)
ONAP TOSCA type definitions/vocabulary
Without models, either:
Model driven won’t happen, or
Model driven will be hacked, or
Model driven success will be declared

10. TOSCA Service Orchestration Modeling
Higher level than VNF modeling
“Plane” thinking meets traversal orientation
Data plane
Control plane
Infrastructure “plane”
Networking “plane”
App “plane”
Critical consideration for ONAP

11. TOSCA Service Orchestration Modeling
TOSCA implicitly defines a designer role
Opposing pressures: what is visible to designer vs what does platform supply
TOSCA capable of modeling arbitrary level
Long running processes
Designer
Types
Template
Main theme here is that there is a balance between service designer and service platform. Platform understanding of designer can determine which components will be meaningful for design.
Horizon
Hidden System Internals

12. TOSCA Service Orchestration in ONAP
TOSCA typically models APIs as components
Nouns are types
Adjectives are properties
Verbs are operations
ONAP has many APIs, and many potential types/components
SNDC, OF, MultiVIM, APPC, AAI, etc…
Naive approach: TOSCA types for everything
Designer
AAI
SDNC OF
APPC
DCAE
MultiVIM
IAAS

13. TOSCA Service Orchestration in ONAP
Naive Approach Problems
Exposes internals
Knowledge problem
Binding problem
AAI connected to all
SDNC & OF need entire template as input

14. Realistic TOSCA Service Orchestration in ONAP
Need orchestrations that are correct but designable
Designer shouldn’t have to care about ONAP internals
Hiding places:
Base types
TOSCA Orchestrator Workflows
Behind the scenes BPMN
Other ONAP internal code (e.g. adapters)
Service orchestrations need to be constructable with knowledge of ONAP internals. Then the question becomes where to hide ONAP.

15. Realistic TOSCA Service Orchestration in ONAP
AAI Hiding
AAI interactions are ubiquitous
Service instance creation
First step in SO service orchestration
Adapter, BPMN, or TOSCA workflow hiding
MultiVIM interactions
Either in MultiVIM, or in TOSCA base types
Uber base type?
SDNC/OF Hiding
Requires complete TOSCA model as input
MultiVIM : TOSCA base types
APPC & others: TOSCA base types
This slide describes specific approaches for various projects that SO touches

16. Realistic TOSCA Service Orchestration in ONAP
TOSCA ONAP base types in depth
A base type provides interfaces workflows recognize
An interface for AAI related components might include operations
register
unregister
with default implementations
A base type provides common properties
A base type for APPC might include connection information (with defaults)
A VNF base type would have properties common to all VNFs
User supplied config via template inputs
MultiVIM types include IAAS basics (image, instance, network, etc..)
This slide describes specific approaches for various projects that SO touches

17. Realistic TOSCA Service Orchestration in ONAP
Potential flow: SO
SDC
Template/CSAR
DCAE
TOSCA Orch.
BPMN
ONAP TOSCA Types
VID
ONAP TOSCA Types
Get assgns
Get assgns
APPC
ONAP TOSCA Types
This slide describes specific approaches for various projects that SO touches
AAI
MultiVIM
User Inputs
SDNC OF

18. ONAP SO TOSCA Trajectory
Validate/explore via other use/edge cases
Track MultiVIM enhancements to true multi-cloud
Enhance ARIA container for use as Kubernetes service
Enhance ARIA availability/failure recovery
Healing/Scaling/CLAMP integration
Day 2+ custom workflow support
Downstream/southbound BPMN operation invocation

19. THANK YOU