TOSCA specifications are rapidly advancing in 2017 to become the premier framework for deploying and orchestrating NFV workloads (VNFs and Network Services). At the same time, adoption requires more than standard specifications - and open source projects such as ARIA are stepping up to this challenge. Gaps in the specifications, many identified by implementations in open source projects, are being actively analyzed and addressed by an energized cross-section community of individuals/companies engaged in both standards activities and open-source projects. This cross-pollination gives industry confidence that TOSCA-as-a-living-standard has a real chance to accelerate the realization of many of the promises of NFV.

1. May 3, 2017
Why NFV Needs
TOSCA
Michael Brenner, Chief Architect NFV, GigaSpaces
michael@gigaspaces.com

2. NFV paradigm (un)settling
questions
Are NFV-impacting standards settled?
Have open source communities produced a
complete NFV solution?
Does any vendor have a market-dominant
complete NFV solution?
Does any Operator have a major NFV
deployment in production ?

3. A “right”-sized standards
approach
With NFV still settling … we need:
- direction-setting specifications
- under-specification
- flexible/extensible frameworks
- iterative implementation
- feedback to standards
With NFV still settling … we should not:
- mandate compliance to yet-to-be-
proven/un-tested standards

4. TOSCA – right-sized for NFV,
and growing with it
Designed broadly for deployment and
orchestration of Cloud Workloads (and beyond)
Lightweight/under-specified as a philosophy
Extensible … “on a clear day one can see
forever”
Ideal for iterative implementations
Driven by a receptive and energetic standards
community
… and it does not mandate much 

5. What is TOSCA and what
does it address?
TOSCA is a data modeling framework
that supports defining interoperable
description of applications; including their
components, relationships, dependencies,
requirements, and capabilities….
…thereby enabling portability and
automated management across cloud
providers regardless of underlying
platform or infrastructure thus expanding
customer choice, improving reliability,
and reducing cost and time-to-value.
TOSCA addresses
critical Cloud
Challenges:
- Speed and accuracy moving
apps to Cloud
- Agility adapting to change
- Consumer choice of Cloud
vendor and technology

6. TOSCA philosophy
These concepts lead to application-centric, holistic, unified model
• Reusable models extend investments by making it easy to
compose more valuable and complex apps from existing apps
• Models can be validated by automation to ensure app-aware,
policy-aligned configuration, deployment and operational
semantics
TOSCA Application
Model
Web Server
Tier
Web Server
Web App
PHP
Script
Module
Database
Server Tier
DB Server
Database
Containment
Connectivity
Containment and
Connectivity concepts
support Composition
and Reuse.

7. So why is TOSCA good for
NFV?
1. What’s good for Cloud Workloads is also good for NFV
… because VNFs and Network Services composed with
VNFs are in fact specialized cloud workloads/applications.
2. TOSCA specific extensions for NFV are taking shape in
2017, and will support ETSI NFV information model while
avoiding being locked into it.
4. TOSCA is a living and growing framework, and it will find
its way in Operators’ NFV++ (i.e. crossing the current NFV
boundaries defined in ETSI NFV)
3. TOSCA is supported by living Open Source
implementations in demand in Open Source projects, and
between adoption and its conduciveness to iteration, will
converge faster than any other standard into the right-sized
specification.
TOSCA is used first
and foremost to
describe the topology
of the deployment
view for cloud
applications and
services.

8. (NFV) Topology and
Composition (1)
Tier
source_resource
Node_Type_A
target_resource
Node_Type_B
Requirement
connect_relationship
ConnectsTo
Capability
Node templates to describe
components in the topology
structure
Relationship templates to
describe connections,
dependencies, deployment
ordering
Requirement - Capability
Relationships can be customized to
match specific source requirements
to target capabilities
TOSCA is used first
and foremost to
describe the topology
of the deployment
view for cloud
applications and
services.

9. (NFV) Topology and
Composition (2)
Orchestrators can “substitute” for abstract nodes…
… as long as all declared “requirements” are met:
• Monitoring Service can be substituted in Cloud Application
• Analytics Service can be substituted in Monitoring Service
Any node in a TOSCA
topology can be an
abstraction of another
layer or sub-topology.

10. (NFV) Policy
my_app_1
Compute
Capabilities
Container
..
.
Lifecycle
create
configure
..
.
Policy
• Type
• Event, Condition
• Action
my_scaling_group
backend_
app
Compute
Policy
• Type
• Event, Condition
• Action
my
database
Compute
web-app
Compute
Policy
• Type
• Event, Condition
• Action
1
2
3
Scaling
Policies can be declared independently and attached to various
points in your models
1. That can be attached to Interfaces or specific Operations,
2. Nodes and
3. Groups of Nodes
Policies are non-
functional requirements
independent of nodes,
e.g. wrt
placement/affinity,
scaling and
performance
Orchestrators can evaluate Conditions based on Events that
trigger Automatic or Imperative Actions

11. (NFV) Workflows
A
CB
D
E
F
‒ Declarative workflows: automatically generated based on the
INTENT derived from the description of nodes, relationships, and
groups defined in the topology
‒ Imperative workflows: manually specified TASKS by the
author of the topology
TOSCA defines two
different kinds of
workflows that can be
used to deploy a
TOSCA
topology.
Defining sequence of operations in an imperative workflow
• Using on_success to define steps ordering
• Every step that doesn’t define any successor is considered as
final. When all the final nodes executions are completed then the
workflow is considered as completed.

12. Matching (NFV)
infrastructure requirements
Cloud
Provider C
Cloud
Provider B
Portable
Choice
Best Fit
TOSCA App
Cloud
Provider A
• TOSCA Apps can be designed to be portable to any cloud
(including hybrid) that meets the application’s requirements
Each cloud provider competes by offering their “best fit” of
unique capabilities, features and services that match the
application’s requirements – and avoid the “lowest common
denominator” approach
TOSCA supports
automated matching
of application
requirements to
provider capabilities
and choice of
provide that “best
fits” your application.

13. Architects
Model services,
policies &
requirements
Development
Teams
Develop, unit test
scripts, plans &
artifacts for
planned releases,
patches, fixes
QA Teams
Build & Test
releases,
updates &
configurations
Operations
Deploy, manage
& monitor
application
lifecycle
Cloud
Provider
A
Cloud
Provider
C
Cloud
Provider
B
TOSCATemplate
Cloud Application Lifecycle with TOSCA
TOSCATemplate
TOSCATemplate
TOSCATemplate
TOSCATemplate
Infrastructure
Changes
Hot Packs
Strategic
Requests
Operational
Requests
Business
Conditions
TOSCA Templates Agnostic to Cloud Infrastructure Changes
Cloud Application (VNF/NS)
lifecycle management
TOSCA templates
communicate and
drive app-centric
Dev-Ops/CICD

14. NFV specific extensions –
work-in-progress: VDU
TOSCA NFV/SDN
ad-hoc group is
working on a
TOSCA profile for
NFV. Extensions
that help mapping to
ETSI NFV VNF
model are specified.
The NFV Virtualization Deployment Unit (VDU) compute node type represents a
VDU entity which describes the deployment and operational behavior of a VNF
component (VNFC), as defined by ETSI NFV IFA011.

15. NFV specific extensions –
work-in-progress: VNFD
example
TOSCA NFV/SDN
ad-hoc group is
working on a TOSCA
profile for NFV. This
spec will support the
definition of an (ETSI
NFV) VNF Descriptor
This defines a VNFD example which contains three different types of VDUs,
interconnected by two virtual link descriptors. The type of VDU C is not defined within
the same VNFD service template file, but rather in a separate service template file.

16. TOSCA Open Source
implementations for NFV
TOSCA spec alone
is insufficient to fulfill
portability & inter-
operability for NFV.
Open Source
implementations are
rising to the
challenge.
Service Orchestration & Management
http://getcloudify.org/
https://wiki.openstack.org/
Heat-Translator (IaaS, App Orchestration)
Tacker (Network Function Orchestration)
Senlin (Clustering & Policy (on roadmap))
App Catalogs (Community & Murano)
Parser (standalone)
http://ariatosca.org//
Multi-Cloud Orchestration
(Amazon, Azure, VMware, OpenStack)
Open Sourced from Cloudify
Deployment Template Translation
Parser
https://wiki.opnfv.org/display/parser/Parser
UBICITY
Cloud-based template validator
http://ubicity.com/validator.html

17. ARIA: a TOSCA
implementation like no other
ARIA: a one-stop
shop for all your
TOSCA needs:
- TOSCA Parser
- Library for NFV TOSCA-
based orchestration products
- TOSCA SDK for specifying
VNFs
- CLI Tool for orchestrating
TOSCA templates
Uses ARIA for TOSCA orchestration
TOSCA Spec
Implementation
TOSCA Spec
Definition
Uses ARIA for TOSCA orchestration
Others
Spec
Definition
Use
Cases
& Models
Open Source
Apache 2.0 License
Open Governance
Apache Software Foundation

18. TOSCA for NFV++
TOSCA for Cloud Native applications
TOSCA for Micro-Services
TOSCA for General Orchestrators
TOSCA for Serverless Architectures
TOSCA for zero-touch/zero-outage interactions
(OSS/BSS)
Unleash TOSCA:
- It’s flexible
- It’s dynamic
- It’s adopted
- It’s both
lightweight and
right-sized for
automation

19. Thank You