...
The proposed approach is to use a node type derived from NetworkFunction to represent the PNF’s appearance as a resource 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.
As is typical, PNF devices are pre-populated in inventory before they are assigned for use by services. This makes them a good 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 PNFDevice Capability base type is defined. 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. The resulting relationship would link the network function (PNF resource) to the physical device (PNF device) as a hosted on relationship.
PNF Resources are modeled as peers to VNFs and Allotted Resources, all being derivations of a base “Network Function” node type. There is no explicit node type for PNF Resource. This permits the three types to be used interchangeably in Abstract Node resolution. The three resource types (VNF, PNF, AR) do not require explicit subtypes, but instead are identified by their defined requirements:
- Allotted Resources have a requirement for an Allotted Resource Provider service
- PNF Resources have a requirement for a PNF Device
- VNF Resources have neither A-R Provider nor PNF Device requirements.
...