Objective

Represent abstraction in TOSCA using correct TOSCA syntax and semantics so that ONAP can decide, either at design time or run time, which concrete implementation of a network function to choose.  An important goal is that the replacement nodes (the concrete implementation) should be derivable from all network function types (i.e. VNFs, PNFs, and allotted resources) interchangeably.

Modelling Abstract and Concrete Nodes

This material draws on the TOSCA Simple Profile in YAML Version 1.2 specification, specifically section 14.3 (Abstract Node Template Matching).  That document describes the allowable replacements for an abstract node template, based on:

  • Derive from the abstract node type, to identify potential replacement node types
  • Match against property (and capability property) constraints, to narrow allowable replacements

Once a matching node type has been selected, orchestration continues by using that node type in place of the abstraction.

Note that this is not substitution mapping, which allows a complex topology template to be represented as a single node type in a containing service.  In that case, the substituting template is “expanded” in place of the “substitutable” node template.  With abstraction, the abstract node template is replaced with another node type [concrete], which is then acted upon in place of the abstraction.

Type-based replacement

  • Define an abstract node type for a NF type abstraction (e.g. firewall, router, etc.)
  • Concrete node types derive from the abstract type, allowing for their use as a run-time replacement.  VNFs, PNFs and Allotted Resources may be defined to derive from the same abstraction.
  • Selection can be filtered based on abstract node properties (including capability properties) matched against concrete node constraints.
  • Selection may be limited to node types distributed in the service CSAR.  This allows the designer to specify the set of available choices.

Properties and/or capabilities relevant to the abstraction can also be defined on the abstract class for reference by other node templates, allowing them to interact in meaningful ways.

The use of property-based filtering could, in some future iteration, allow for more generic matching by defining an abstract node template whose type is a generic “network function” (from which all NFs derive).

In ONAP, OOF would make the run-time selection of which concrete node type to use, based on specific optimization criteria (e.g. performance/throughput, supported protocols, target cloud, etc.).  Upon receipt of the OOF response, SO would orchestrate the selected concrete node template in place of the abstraction via existing logic.

An example of abstraction is shown in the Network Function description here

Possible Usage Scenarios

  • Selection from multiple vendor implementations of a well-known network function (e.g. firewall, router)
  • Selection from virtual, physical, or allotted resources based on optimization criteria
  • Selection from multiple NF implementations for different target clouds



  • No labels

1 Comment

  1. Chris Lauwers

    I know that Chapter 14 of the TOSCA spec gives examples of replacing the type of an (abstract) node template with another type (presumably a derived type), but that is extremely bad practice in my opinion. It will result in unpredictable behavior as more types get added ("onboarded") into the catalog that is used by the orchestrator to search for "compatible" types.

    A better approach, in my opinion, is to always rely on substitution mapping as the only mechanism to replace abstract node templates with concrete implementations, since this results in improved control:

    • Substitution mapping must be defined explicitly. This means that only service templates that were explicitly designed as "implementations" of abstract node types will be considered for substitution.
    • The language includes features to allow service template designers to control which substituting template is selected when multiple options are available.