What is Oasis TOSCA?

Topology and Orchestration Specification for Cloud Applications (TOSCA), is an OASIS standard language to describe a topology of cloud based web services, their components, relationships, and the processes that manage them.^[1] This in turn provides portability and agnostic automation management across cloud providers regardless of underlying platform or infrastructure.^[2]

Or in other words, TOSCA allows you to model an entire application into a single template, and then use it to deploy your application across 3rd party infrastructures (i.e cloud).

Components

So how does TOSCA model an entire application?

We start with a Service Template. A Service Template is used to specify the structure (Topology Template) and orchestration (Plans) of the application.

Figure 1 - Structural overview of a Service Template.^[3]

Next, we have Node Types and Relationship Types.

• Node Types - A component within the Topology such as Compute, Database, Network etc.
• Relationship Types - Describes how nodes are connected to one another.

Both Node Type and Relationship Type contain Properties and Interfaces.

• Properties - Properties of the Node Type. i.e if the Node Type is Compute, then the properties would include RAM, CPUs, disk, etc.
• Interfaces - This is an entry point used by the TOSCA orchestrator to perform operations (such as lifecycle operations like "deploy," "patch," "scale-out," etc.)

Now that we have the building blocks, the Topology Template can be built. This is built from Node Templates and Relationship Templates. A Template is an instance of a Type, i.e. the Node Template (instance) is an occurrence of a Node Type (class).

In addition, outside of the Service Template, there are Policies and Workflows.

• Policy - Defines a condition or a set of actions for a Node. The orchestrator evaluates the conditions within the Policy against events that trigger. The required actions are then performed against the corresponding Interfaces.
• Workflows - Allows you to define a set of manually defined tasks to run in a sequential order.

Finally, TOSCA supports a feature called substitution mapping. This basically allows you to take an entire Service Template and reuse it within another. For instance, Figure 2 shows an example via the reuse of the database.

Figure 2 - Substitution Mapping.^[4]

TOSCA NFV

You may be asking - How does this apply to NFV?

TOSCAs flexibility around reusability (i.e substitution mapping) makes it ideal in describing network topologies. Not only this, but its ability to define Workflows (think VNF lifecycle) along with Policies (VNF monitoring/scaling) makes it extremely well suited to NFV.

In addition, TOSCA specifies a NFV specific data model, based upon ETSI MANO. This provides the ability to model the various entities within MANO, such as Network Services, VNFs, VNFFGs, etc.

Within Figure 3 we can see an example of a VNFD built using the TOSCA NFV standards. This VNFD would build a VNF with 1 vCPU, 512Mb RAM, 1Gb disk, along with a single management interface with anti-spoofing disabled.

tosca_definitions_version: tosca_simple_profile_for_nfv_1_0_0

metadata:
  template_name: sample-tosca-vnfd

topology_template:
  node_templates:
    VDU1:
      type: tosca.nodes.nfv.VDU.Tacker
      capabilities:
        nfv_compute:
          properties:
            num_cpus: 1
            mem_size: 512 MB
            disk_size: 1 GB
      properties:
        image: ciscoasa9.8
        config: |
          param0: key1

    CP1:
      type: tosca.nodes.nfv.CP.Tacker
      properties:
        management: true
        order: 0
        anti_spoofing_protection: false
      requirements:
        - virtualLink:
            node: VL1
        - virtualBinding:
            node: VDU1

    VL1:
      type: tosca.nodes.nfv.VL
      properties:
        network_name: net_mgmt

Figure 3 - Simple TOSCA VNFD.^[5]

References