Taking advantage of TOSCA expressiveness

The ETSI information model is all defined in terms of information elements and their attributes. TOSCA proposes a much richer and more flexible meta-model; besides nodes and their properties, it offers to a designer such constructs as capabilities, requirements, relationships, policies, artifacts, interfaces, relationships, etc.

ETSI & ONAP Information Elements

TOSCA Constructs

Descriptors: NSD, VNFD, PNFD

Topology Template to describe the internal composition and other implementation details;

Node Type to express the “interface”;

Node Template to represent an occurrence of the service/function within a higher-level composition (see Modelling Complex Resources)

VLD, CpD

Normative Node Types and Node Templates based on these types (see Modelling Simple Resources)

Information Elements

Data Types

Naming, Scaling, Affinity

Policies

Lifecycle, Operations

Interfaces

Operation scripts, software images, etc.

Artifacts









Properties vs. Metadata Fields

Property

Metadata Field

Has to do with the core business purpose of the model object, what the model does.

Tells how the model object is maintained, stored, displayed, handled by business logic, etc.


Examples: IP address, required amount of memory, virtualization container type

Examples: Author name, release number, change timestamp, ID in the data store

Populated by vendor, designer

Populated by the infrastructure logic

Inherited by derived types

-

Used by functions (i.e. get_property())

-

Has a data type, including constraints to observe

No structure, just a loose string


Design-time resource instances

Today ECOMP uses the term “instance” to designate a usage of a resource within a higher-level composition in design time. Should we introduce another term for such a design-time usage in order to prevent confusion with the run-time instances?

A resource occurrence maybe?

Modelling Simple Resources

A simple resource is a resource that cannot be decomposed into a topology of lower-layer component resources. Possible ways for a resource to be simple:

  1. The resource definition includes a complete set of artifacts which is sufficient for the orchestrator to create instances of this resource
  2. The resource is so basic and well-known that any orchestrator just knows what to do with it without any artifacts provided.

The following TOSCA constructs are used through this data model to represent simple resources:

  1. A TOSCA node type is used to model the simple resource definition.
  2. TOSCA node templates of this node type are used to represent occurrences (design-time instances) of this resource within a higher-level composition topology.

Modelling Complex Resources

A complex resource is a resource that is backed by a topology of lower-level component resources. The following TOSCA constructs are used through this data model to represent complex resources:

  1. A TOSCA topology template to describe the internal composition and other implementation details
  2. A TOSCA node type to express the “interface” capabilities, requirements, and properties of this resource
  3. A TOSCA substitution_mappings clause wires the capabilities, requirements and properties of this interface node type to the capabilities, requirements and properties of the component nodes inside the implementing topology template
  4. TOSCA node templates of the “interface” node type are used to represent occurrences of this complex resources within a higher-level composition

 

  • No labels

3 Comments

  1. shitao li

    Can you explain more about "Node Type to express the “interface" "?


    Another question is what is naming policy you mentioned in the table?


  2. Priya TG

    The hyperlinks don't work, can you please fix them.

    1. Anatoly Katzman

      Fixed, thank you