PNF incorporation into Guidelines and Requirements

Owned by Herb Patten
Last updated: Feb 20, 2018Version comment
2 min read

The Guidelines and Requirements currently have a scope limited to VNFs. PNF's need to also be accommodated, VNFRQTS-160. This requires we update the Guidelines and Requirements document.

The following are suggestions to include PNF's into the Guidelines and Requirements, VNFRQTS-161.



Definition

An agreed upon definition of PNF is needed. This must be consistent with any other use of the term PNF in ONAP. A initial working definition might be:

PNF is a vendor-provided Network Function(s) implemented using a bundled set of hardware and software while VNFs utilize cloud resources to provide Network Functions through virtualized software modules.  PNF can be supplied by a vendor as a Black BOX (provides no knowledge of its internal characteristics, logic, and software design/architecture) or as a White Box (provides detailed knowledge and access of its internal components and logic) or as a Grey Box (provides limited knowledge and access to its internal components).

PNF is a vendor provided network function that has dependencies on vendor specified hardware that is outside of the cloud infrastructure, There could be multiple network functions running on the specified hardware.

Add an agreed upon definition to the Guidelines glossary.

Document Names

Update the document from VNF Provider Guidelines and Requirements to Network Function Provider Guidelines and Requirements

Guideline Changes

Update section 1, 2, 3, and 4 to reflect a broader scope than just VNFs.

Update section 5, VNF Characteristics, to include a section on PNF Characteristics.

Requirement Applicability and Compliance

Requirements that are deemed applicable to a PNF must be met by all new PNF products.  New means products that are under initial development and have not been generally deployed in an operator's network.  Some PNFs that are early in their life cycle need to migrate to support the PNF requirements in a reasonable timeframe assuming that they are SW upgradeable.  PNFs that are near end of life or are very small and such adding software to support ONAP is  impractical may require a mediation function or adaptor to support the most critical ONAP requirements or be managed by current legacy systems.

Requirement Changes

The existing requirements need to be reviewed to determine which of them apply equally to PNFs. Currently, most requirements are phased "The VNF MUST/SHOULD/...

Requirements that equally apply to both VNFs and PNFs could be worded as "The xNF MUST/SHOULD/..."

Requirements that only apply to VNFs would be worded as "The VNF MUST/SHOULD/..."

Requirements that only apply to PNFs would be worded as "The PNF MUST/SHOULD/..."

Example: Design Requirements Updates.pdf

Editing of requirements

Some requirements may apply to both PNFs and VNFs but will need some editing of the text in the requirements such that is broader.



Next Steps

  1. Determine interested parties to collaborate on PNF definition

  2. Define the scope of work to be included in the Beijing release for PNFs

  3. Draft and post the definition of PNF

  4. Review all requirements to identify those that are applicable to PNFs and change to the proposed wording above

  5. Edit requirements that apply to both VNFs and PNFs so that the wording isn't slanted toward VNFs 

Related ONAP Work