Update the guidelines to include a section on PNF Characteristics:

PNF Characteristics

1.      PNF Characteristics

Physical Network Functions (PNF) are a vendor-provided Network Function(s) implemented using a set of software modules deployed on a dedicated hardware element while VNFs utilize cloud resources to provide Network Functions through virtualized software modules.

PNFs 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). Also note that the PNF hardware and the software running on it could come from the same vendor or different vendors.

 PNFs need to be chained with VNFs to design and deploy more complex end to end services that span across Network Clouds. PNF should have the following characteristics

Cloud Integration

Although the goal is to virtualize network functions within a service chain, there will be certain network functions in the near term or even in the end state that would remain physical (e.g., 5G radio functions, ROADM, vOLT, AR/CR appliances etc.). PNFs must be designed to allow their seamless integration with Network Clouds and complement end to end service requirements for resiliency, scalability, upgrades, and security.

 

PNF Design

A PNF provides one or more network functions on a dedicated hardware box. PNFs are expected to evolve to Virtualized Network Functions and their current design should facilitate their future virtualization. The software modules and corresponding hardware should be packaged together to provide the desired Network Functions. However, it is not required for the software modules and hardware to be provided by a single vendor. PNFs are deployed through Service Provider’s installation and commission procedure. Virtualized instantiation processes flows such as OpenStack HHEAT are not utilized and PNFs are instantiated when they are powered up and connected to ONAP. PNFs must provide access to its software modules and management functions through open APIs.

 

Scaling

Horizontal scaling for PNFs would not be the logical approach and they need to be scaled up vertically by increasing computing hardware resources (e.g. cpu, memory). Vertical scaling of PNFs will need to follow Service Provider’s hardware upgrade processes and procedures. 

 Managing State

Software modules and their interfaces should be able to monitor and manage their state to allow high-reliability, performance, and high-availability (active-active or stand by) as needed by overriding services. At this time, PNF data store should be replicated in the back up hardware to allow fail overs for both active-active and stand by high-availability methods.

 

Resiliency

The PNF is responsible for meeting its resiliency goals with the use of redundant physical infrastructure.  The PNF developer should design the function in such a way that if there is a physical platform problem the PNF will continue working as needed and meet the SLAs of that function. PNFs should be designed to survive single failure platform problems including: processor, memory, NIC, datacenter outages, etc. The PNF should support tools for gracefully meeting the service needs such as methods for migrating traffic between PNF’s and draining traffic from a PNF.

DevOps

The ONAP software development and deployment methodology is evolving toward a DevOps model. PNF development and deployment should evolve in the same direction, enabling agile delivering of end-to-end services.

Testing

PNF packages should provide comprehensive automated regression, performance and reliability testing with PNFs based on open industry standard testing tools and methodologies. PNF packages should provide acceptance and diagnostic tests and in-service instrumentation to be used in production to validate PNF operation.

Build and Deployment Processes¶

PNF packages should include continuous integration and continuous deployment (CI/CD) software artifacts that utilize automated open industry standard system and container build tools. The PNF package should include parameterized configuration variables to enable automated build customization. Don’t create unique (snowflake) PNFs requiring any manual work or human attention to deploy. Do create standardized (Lego™) PNFs that can be deployed in a fully automated way.

ONAP will orchestrate updates and upgrades of PNFs. One method for updates and upgrades is to onboard and validate the new version, then build a new instance with the new version of software, transfer traffic to that instance and kill the old instance. There should be no need for the PNF or its components to provide an update/upgrade mechanism. 

Automation¶

Increased automation is enabled by PNFs and PNF design and composition. PNF should provide the following automation capabilities, as triggered or managed via ONAP:

• Events and alarms
• Lifecycle events
• Zero-Touch rolling upgrades and downgrades
• Configuration

ONAP Ready

PNF and VNF lifecycles are fundamentally managed the same way utilizing ONAP onboarding, configuration, and monitoring capabilities. The main difference is related to the processes and methods used for deployment and instantiation of these resources. PNFs are first installed in the target location utilizing Service Provider’s installation and commission procedures that includes manual activities. Next, any additional software module will be downloaded to the physical hardware and started utilizing the required APIs. On the other had VNF deployment and instantiation are orchestrated by ONAP utilizing the underlying Network Cloud orchestration and APIs.

Design Definition¶

It is intended to onboard PNF packages into ONAP using the same processes and tools as VNFs to reduce the need for customization based on the Network Function underlying infrastructure. The main difference is associated with the content of the Package that describes the required information for lifecycle management of the Network Function. For instance, PNF packages will not include any information related to the Network Cloud infrastructure such as HEAT templates.

Configuration Management

The configuration for both PNFs and VNFs are managed utilizing common orchestration capabilities and standardized resource interfaces supported by ONAP. PNFs must allow direct configuration management interfaces to ONAP without any needs for an EMS support.

Monitoring and Management¶

PNFs must allow ONAP to directly collect event and performance data without the aid of any EMSs to monitor PNF health and behavior. ONAP requires common standardized models and interfaces to support collection of events and data streams for both VNFs and PNFs and the vendors must be able to support these requirements.

Computing Environment¶

Network functions implemented over dedicated physical hardware will eventually be virtualized over Network Cloud infrastructure. However, this transition will take place over time and there is a need to support this integrated network functions in various forms until complete virtualization is achieved. The integrated solution may come in the form of a tightly bundled package from a single provider referred to as black box in this document. In this configuration, the software modules will not be directly managed by an external management system and the bundled package is managed utilizing standardized open APIs provided by the vendor.

In an alternative configuration, the internal software modules are not tightly coupled with physical hardware and can be directly accessed, extended, and managed by an external management system through standardized interfaces. Each software module can be provided by different vendors and loaded onto the underlying hardware. This configuration is referred to as a white box in this document.

A gray box configuration provides direct access and manageability only to a subset of software modules that are loaded on top of a basic bundled package.