Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Current »

See also: Complex Service Example

The ONAP internal DM 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


  • No labels