The document discusses TOSCA concepts and their application to service orchestration modeling in ONAP. It proposes using TOSCA to model ONAP's various APIs as components while hiding internal details from designers. Base types and workflows could abstract interactions with AAI, MultiVIM, APPC, and other ONAP components. The approach aims to allow correct orchestrations while avoiding exposing ONAP internals to designers.

1. TOSCA Native Service
Orchestration Design
DeWayne Filppi, Cloudify

2. 2
Agenda
• Declarative vs Imperative Approaches
• Brief TOSCA Concept Review
• Service Orchestration Modeling
• ONAP Service Orchestration Modeling
• R1 Review
• R2 and Beyond

3. 3
Declarative vs Imperative : The false choice
• Declarative separates what from how
• Declarative defines a model (what) and an orchestrator (how)
• Model provides enough info for orchestrator to remain generic
• Pros
- The allure of no coding
- Orchestrator implementation hidden
- Simple versionable artifact(s)
- Designer focus on value/solution
• Examples: HOT, CloudFormation,
TOSCA, Kubernetes, Docker
Compose, etc...

4. 4
TOSCA Concepts
• Defines modeler and orchestrator roles
• Object modeling basis ( Java like )
• Binds models to implementations (APIs)
• Imperative workflows in orchestrator interpret runtime model instance
VM
Port
Net
Generic Install Workflow
1
3
2

5. 5
TOSCA Concepts - Types
• Types can be viewed as OO classes
• Concrete instances are called nodes
• Service templates/models consists of nodes and relationships
• Types are defined by:
- A name
- Optional properties
- Runtime properties (attributes)
- Interfaces (the connection to type
specific imperative processing)
- Requirements & Capabilities /
Relationships
web_app:
type: WebApp
properties:
port: 9090
requirements:
- host: web_server
interfaces:
Standard:
configure: scripts/configure.sh
start: scripts/start.sh
stop: scripts/stop.sh

6. 6
TOSCA Concepts - Interfaces & Operations
• Nodes can have behavior ( imperative )
• Interfaces are the means. Interfaces have:
- Names (e.g. tosca.interfaces.Standard )
- Operations, which have
• An operation name
• A code reference (e.g. path to script)
• Workflows recognize interfaces
VM
Port
Net
Generic Install Workflow
1
3
2
Recognizes implemented
interface
tosca.interfaces.Standard

7. 7
TOSCA Concepts - Relationships
• Relationships can be implicit or explicit
• Types in their own right
• Used by workflows to order operations
• Used to execute arbitrary code
VM
Port
Net
Generic Install Workflow
1
3
2
Order operation execution
based on relationships

8. 8
TOSCA Concepts - Service Templates
• Service templates are node graphs
( DAGs)
• Service templates can define
inputs/parameters
• Service instances are created from
the combination of inputs and
service templates
• Service instances have runtime
state (attributes)
Inputs
Service
Template
Service+

9. 9
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

10. 10
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
Horizon
Hidden System
Internals

11. 11
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
APPC
OF
MultiVIM
IAAS
DCAE

12. 12
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

13. 13
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)

14. 14
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
• SDNC/OF Hiding
- Requires complete TOSCA model as input
- Adapter, BPMN, or TOSCA workflow hiding
• MultiVIM : TOSCA base types
• APPC & others: TOSCA base types

15. 15
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..)

16. 16
Realistic TOSCA Service Orchestration in ONAP
Potential flow:
SDC
ONAP
TOSCA
Types
ONAP
TOSCA
Types
ONAP
TOSCA
Types
Template/
CSAR
SO
VID
User
Inputs
BPMN
Get
assgns
Get
assgns
TOSCA
Orch.
SDNC OF
AAI MultiVIM
APPC
DCAE

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

18. 18
ONAP R1 SO TOSCA
▪
○ https://gerrit.onap.org/r/gitweb?p=so.git;a=tree;f=aria/aria-rest-server
○
https://gerrit.onap.org/r/gitweb?p=so.git;a=tree;f=aria/aria-rest-java-client
▪
○
https://gerrit.onap.org/r/gitweb?p=so.git;a=blob;f=packages/docker/src/main/docker/docker-files/Dockerfile.aria
▪
○
https://gerrit.onap.org/r/gitweb?p=so.git;a=tree;f=aria/multivim-plugin
▪
○
https://gerrit.onap.org/r/gitweb?p=demo.git;a=blob;f=tosca/vCPE/infra/base_vcpe_infra_rackspace_tosca.yaml
Requirements and R1 Contributions

19. 19
ONAP R2 SO TOSCA
Full Integration With Core BPMN
• Approach: Post SDNC/OF fork
• Implications:
- ONAP Base 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

20. 20
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

21. THANK YOU