Service Model Principles

Owned by Anatoly Katzman
Last updated: Aug 15, 2018
2 min read

See also: Complex Service Example (TOSCA)

The ONAP internal DM (R4+) establishes the following convention for modeling services:

  • The global TOSCA node type onap.nodes.Service as part of the DM core:

    • one node type for all types of services

    • an abstract type, never used directly to type a node, never explicitly mentioned in a substitution_mappings

    • very few TOSCA properties and attributes, no requirements or capabilities (will be defined as part of derived node types)

    • TOSCA interfaces related to ONAP service, with default implementations

  • For each specific service in the catalog, ONAP maintains:

    • An “ONAP interface type” - a concrete TOSCA node type which is derived from onap.nodes.Service

      • adds requirements and capabilities specific for this service

      • extends the set of properties and attributes

      • overloads the default operations in the interfaces defined for onap.nodes.Services

    • an implementing topology that includes

      • inputs

      • nodes – to represent NFs, resources, VLs; policies, groups, etc.

      • a substitution_mappings construct

      • refers to the concrete service node type

      • maps the “public” capabilities and requirements of the concrete service node type to the “internal” caps&reqs inside the topology

      • maps the “public” properties of the concrete service node type to the input parameters of the topology

      • maps the “public” interface operations to their internal implementations



An ONAP service is distributed as a self-contained CSAR file that contains:

  • Global TOSCA type definitions of the ONAP DM

  • The interface node type definition of the service

  • The implementation topology of the service

  • For all VNFs used by the service – their interface node type definitions and implementation 


The “Service A embeds Service B” situation is modeled as following:

  • Both Service A and Service B have their ONAP interface node types and implementation topologies

  • Service A’s implementation topology includes a node(s) of the ServiceB’s interface type

  • The Service A model is distributed as a CSAR that contains the interface-implementation pairs for both Service A and Service B, and all interface-implementation pairs for all VNFs used in these services