Open-O Mini-Summit - TOSCA and YANG Data Modeling for NFV, Sivan Barzily, GigaSpaces

1. TOSCA and YANG Data
Modeling for NFV
Sivan Barzily, GigaSpaces
June 2016

2. Agenda
What is TOSCA?
• Community
• Key modeling concepts
• NFV angle
TOSCA & YANG
Modeling VNFs (vDNS example)
Modeling services (composition)

3. 3
Deploy
Install
Configure
Monitor
Manage Provision
The Application Deployment Lifecycle
TOSCA
Blueprint

4. An important Open standard, that is enabling a unique Cloud eco-
system supported by a large and growing number of international
industry leaders
TOSCA uses a domain-specific language (DSL) to define interoperable
descriptions of :
• Cloud applications, services, platforms, infrastructure and data
components, along with their relationships, requirements,
capabilities, configurations and operational policies…
• …thereby enabling portability and automated management
across cloud providers regardless of underlying platform or
infrastructure thus expanding customer choice, improving
reliability and time-to-value while reducing costs.
4

5. Associated Companies• TOSCA Version 1.0 Specification approved as an OASIS Standard
— publishedNov 2013, XML format
• TOSCA Simple Profile v1.0 Specification (YAML format)
— final public review, ended March 2016, towards OASIS Standard
— TOSCA Simple Profile v1.1 Specification (target: June 2016)
 Supports Domain-Specific Profile Specifications:
– Network Function Virtualization (NFV) Profile v1.0
• Government and Corporate Awareness:
– OASIS: 600+ participant organizations.
5000+ participants spanning 65+ countries
– TOSCA Committee: 170+ people 45+ companies/orgs
– International Standards & Research: ISO/IEC JTC 1 liaison, EU
FP7, ETSI NFV liaison, etc.
• Multi-company Interoperability Demonstrated:
– EuroCloud 2013, Open Data Center Alliance 2014, OSCON 2015,
OpenStack Summit 2016 (Indigo DataCloud)
5
Includes contributors, reviewers, implementers, users
or supporters of the TOSCA Standard via OASIS

6. incorporates both Data and Information Model features and concepts …
… but brings unique orchestration concepts focus in Lifecycle mgmt. and State
Information Models
Typically, used to model a
constrained domain that can be
described by a closed set of entity
types, properties, relationships
and operations.
Data Models
Typically, describe the structure
(format), enabling manipulation
(via interfaces) of the data stored
in data management systems
assuring integrity.
• Topology
• Composition
• Requirements - Capabilities
• State (Nodes, Relationships)
• Lifecycle (Management)
• Policy
Intent Model Adds:
TOSCA is an Intent Model which is declarative (integration points for imperative)
• Structure
• Format
• interfaces
• Types,
Relationships
• Properties
• Operations
 TOSCA can work with
imperative scripts
(e.g., Ansible, Chef,
Bash, Ant, etc.)
 TOSCA can
include other data
models (e.g.,
JSON, YANG)

7. TOSCA for NFV modeling
TOSCA is an object oriented modeling language:
• Normative, Extendable, Abstractable, and Composable
• TOSCA natively allows integrating nested models like YANG
Suited for NFV
• Generic Normative Node Types (portability, implementation agnostic, multi VIM)
• TOSCA NFV Profile (forwarding graphs, virtual links, etc)
• TOSCA as a modelling Language
• Inheritance and abstraction (reusable models for VNFs, NS, and more…)
• Extendable Node types (custom code)
• Policies (SLAs, QoS)

8. TOSCA & YANG
YANG
Modules
TOSCA
Types
YANG MODEL
TRANSLATOR
NETCONF
TOSCA
Blueprint

9. TOSCA
Defines and Refines
TOSCA SPEC
GigaSpaces
Cloudify
Tacker
(TOSCA-Parser)
Other Proprietary
softwareOther Proprietary
softwareOther Proprietary
software

10. Reference Implementation
Of OASIS TOSCA
TOSCA
Defines and Refines
TOSCA SPEC
Open Source Reference
Implementation of TOSCA
Apache Software Foundation
Orchestration driven by:
Embeddable
Python Libraries
Command Line Interface

11. 11
OPEN-O projects proposal (Release 1)
Common
Service
Micro-Service
Bus
Auth.
Log
Workflow
Catalog
SDN-O
SDN
Res.
Mgr.
Abstract NBI
Abstract SBI
NFV-O
NFV Res. Mgr.
NFV Monitor
Model Designer
NS Lifecycle Mgr.
Abstract NBI
Abstract SBI
GUI Portal
TOOLs
Foreman
…
Ansible
GS-O
Service
Decomposer
Service
Lifecycle Mgr.
Abstract NBI
VPN
SDN Lifecycle Mgr.
Traffic
Optimize
SDN
Monitor
Common
(TOSCA)
Runtime engine
Common
Parser
Compass
Protocol Stack
HA
Driver ACCESS/WAN SDN
Controller Drivers
EMS/NMS
Drivers
VNFM
Drivers
VIM
Drivers
NFV SDN
Controller Drivers
Driver
GUI Portal
GUI Portal
Service layer

12. Orchestrator
SDN
API
API/NETCONF
IaaSIaaS
Modelling a DNS Service with OpenStack VIM
Allows VNF Modelling via TOSCA
blueprint
SDN Modelling via
NETCONF/YANG Plugin
Multi-Vim support via IaaS Plugins
OpenStack
VMware
VNF Service
TOSCA(+YANG)

13. DNS Service
Keyspair
Floating
IP
Port
Security
Group
GW FW
(YANG)
Bind9_host
Type: openstack.nodes.Server
Bind9
Type: application.nodes.Bind9
Modelling a DNS Service

14. TOSCA VNF Blueprint Aria-OpenStack-Plugin
...
cloudify.openstack.nodes.Server
Properties:
Interfaces:
cloudify.interfaces.lifecycle:
create:
Implementation:
openstack.nova_plugin.server.create
...
OpenStack-Plugin.yaml
...
def create(.. **kwargs):
s = nova_client.servers.create(**server)
..
nova_plugin/server.py
Modelling a DNS Service with OpenStack VIM
...
bind9_host:
type: cloudify.openstack.nodes.Server
…
bind9:
type: application.nodes.Bind9
Relationships:
contained_in
target: bind9_host
bind9-blueprint.yaml

15. TOSCA Composition for service chaining
vRouter
Blueprint
DNS Service
Blueprint
Firewall
Blueprint

16. TOSCA Composition for service chaining
vRouter
Blueprint
DNS Service
Blueprint
Firewall
Blueprint

17. vRouter:
type: cloudify.openstack.nodes.Server
properties:
use_external_resource: False
resource_id: router1
install_agent: false
server:
image: { get_input: router1_image_id }
flavor_name: { get_input: flavor_name }
management_network_name: { get_property:
[management_network, resource_id] }
relationships:
- target: management_network
type: cloudify.relationships.connected_to
- target: management_subnet
type: cloudify.relationships.depends_on
- target: edge_router_inbound
type: cloudify.relationships.connected_to
- target: edge_router_subnet
type: cloudify.relationships.depends_on
- target: vFW_inbound
type: cloudify.relationships.connected_to
- target: vFW_subnet
type: cloudify.relationships.depends_on
vFW:
type: cloudify.openstack.nodes.Server
properties:
use_external_resource: False
resource_id: vFW1
install_agent: false
server:
image: { get_input: vFW1_image_id }
flavor_name: { get_input: flavor_name }
management_network_name: { get_property:
[management_network, resource_id] }
relationships:
- target: vFW_management_port
type: cloudify.relationships.connected_to
- target: vFW_inbound
type: cloudify.relationships.connected_to
- target: vFW_subnet
type: cloudify.relationships.depends_on
- target: vFW_outbound
type: cloudify.relationships.connected_to
- target: vFW_subnet
type: cloudify.relationships.depends_on

18. Thanks