Description

Proposed approach is to use a “PNF Resource” node type (network function) representing the PNF’s appearance in services, and a separate “PNF Device” node type to represent the device itself (in the model and in inventory).  TOSCA requirements and capabilities are used to map the PNF Resources within services to their corresponding PNF Devices.

Note that currently, all PNF devices are pre-populated in inventory before they are assigned for use by services.  This makes them a perfect candidate for Requirements/Capabilities logic, where the PNF Resource has a dangling requirement for a PNF Device.  The mapping would be established at run-time by selecting which pre-deployed (and inventoried) PNF Device is to be used.

In this model, a new Capability base type is defined for PNF Devices.  Individual PNF devices would declare this capability (or one derived from it).  Their matching PNF Resource types would declare a requirement for its PNF Device capability.

PNF Resources are modelled as peers to VNFs and Allotted Resources, all being derivations of a base “Network Function” node type.  This would permit the three types to be used interchangeably in Abstract Node resolution.

Properties

Attributes

Capabilities

Requirements

TOSCA Definition

node_types:
  onap.nodes.PNFDevice:
    derived_from: tosca.nodes.Root
    description: Declaration of being a device which can host a PNF Resource
    valid_source_types: []
    properties:
      # TBD
    attributes:
      # TBD

Examples

capabilities_types:
  vendor.capabilities.pnfDevice.MyFirewall:
    derived_from: onap.capabilities.PNFDevice
    description: Declaration of being a specific PNF device 


node_types:
  vendor.nodes.devices.pnfs.MyFirewall:
    derived_from: onap.nodes.PNFDevice
    description: A PNF Firewall Derive from vendor and preinstalled in the network
    properties:
      # as needed
    attributes:
      # as needed
    capabilities:
      pnf_device:
        type: vendor.capabilities.pnfDevice.MyFirewall
    

...