The PNF PnP flow is method, which allows to register within ONAP/AAI a PNF resource instance. This PNF resource instance is correlated with an existing service instance.
Once a PNF resource is registered, the infrastructure service instantiation flows are able to continue the service instantiation, by calling controllers, which in turn configure the PNF instance.

While this page was created in the R2 "Beijing" release, it is the "Base" Plug and Play page and applies for R2 through R9 (Honolulu).

OVERVIEW OF PNF Plug and Play

BUSINESS DRIVERS

This section describes Business Drivers of this use case:

Executive Summary - Plug and Play provides a means for a service provider to work with their vendors to have their PNFs be "discovered" by their ONAP deployment through a PNF registration message.

Business Impact - For service providers to discover and deploy a network, Physical Network Functions (PNF) are needed to be deployed and discovered by their network. This serves as a foundation to create a wireless, optical, or wire-line network efficiently. The ability to deploy, discover, manage and incorporate PNFs efficiently is vital to business operations. Without Plug and Play, a service provider and their operator technicians would need to manually create the PNFs into their network which entails a high OPEX and would be very time-consuming and prone to error. For example, Wireless Service Providers will need to roll out tens of thousands of base stations across a nation/world, and the possible and potential business cost savings and expenditures related to rolling out, deploying, and incorporating PNFs to be recognized into a service provider's network encounters vast economies of scale which make Plug and play a vital business imperative.

Business Markets - Plug and Play is applicable to multiple domains, and different kinds of PNFs and applies to any service providers networks.

Funding/Financial Impacts - Without Plug and Play, a service provider and their technicians would need to manually create and deploy PNFs into their network which entails a high OPEX particularly in a 5G RAN wireless network, where it is expected that there will be approximately 10-fold the number of base stations compared to 4G LTE.

Organization Mgmt, Sales Strategies - There is no additional organizational management or sales strategies for this use case outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider.

STAGES OF PLUG AND PLAY

PNF Plug and Play is used to register a PNF when it comes on-line. This use case is intended to be applicable to a variety of PNFs such as routers and 5G base stations. The steps and descriptions have been drafted to be as general as possible and to be applicable to a relatively wide variety of PNFs. However, the use case was originally developed with consideration for 5G PNF Distributed Units (DU).

The following diagram shows the five major phases of PNF Plug and Play.

The following table describes the five stages of Plug and Play

PNP STAGE

DESCRIPTION

STAGE 1:

PNF MODELING

Resources Definition/Services Definition – This is a design time step where the PNF is modeled using SDC. The PNF resource and services are modeled.

SDC: PNF (physical element) Modeling – SDC is used to model the PNF. PNF descriptors and artifacts can be onboarded. The service design is incorporated into the SDC design studio and validated for export.

Distribution of artifacts – The output of design time products is distributed to listeners in other ONAP components.

STAGE 2:

PNF INSTANCE DECLARATION

PNF Infrastructure Service Declaration – A work flow is invoked which will create an A&AI entry for the PNF. The work flow is invoked from a OSS or VID interface.

First part of PNF instantiation – This service instantiation work-flow is invoked which is handled in orchestration with SO.

DCAE & AAI Entry with PNF-name (e.g. MAC address) – The result of this stage of Plug and Play is that an inactive A&AI entry so that ONAP will be prepared when the PNF tries to register.

STAGE 3:

PNF BOOT STRAPPING

PNF Powers up and Boot-straps – Vendor specific steps are performed where the PNF is physically installed, powers up, and performs boot-strapping functions.

PNF performs a “Plug and Play” procedure – The PNF performs vendor specific steps which will allow the PNF to reach a state such that it is ready to contact ONAP.

STAGE 4:

PNF CONTACTS ONAP

PNF connects to ONAP via a Registration Event – The PNF contacts ONAP with a specific sequence of events using a pnfRegistration VES message.

PNF Registration Handler (PRH) processes the event – The PRH receives the VES message and performs ONAP registration functions.

STAGE 5:

PNF ACTIVATION

Connection points configured – ONAP configures transport information.

Second part of PNF service instantiation – The second part of PNF service instantiation is performed and ONAP sends the PNF a service configuration message.

PNF configured and ready to provide service – Any other vendor specific configuration is finished, and the PNF is now ready to provide service.

ACTORS IN PLUG AND PLAY FLOWS

The Actors in the Plug and Play Flow are:

ACTORS	DESCRIPTION
PNF	PHYSICAL NETWORK FUNCTION (PNF) – A Network Function that is hosted on a physical hardware device, not in the cloud infrastructure.
DHCP	DYNAMIC HOST CONFIGURATION PROTOCOL (DHCP) – Protocol to assign IP addresses to a network element (NE). The IP address can be dynamically assigned or static based on MAC address of PNF.
SEGW	SECURITY GATEWAY – Used to set up IPSec tunnels to protects against unsecured traffic entering an internal network of a operator; used by enterprises to protect their users from accessing and being infected by malicious traffic.
CA/RA	CERTIFICATE AUTHORITY / REGISTRATION AUTHORITY – Used to generate a service provider certificate for the PNF.
Initial EM	INITIAL EM – Provides basic configuration and software download services to the PNF. This might be an equipment vendor specific solution. Also, responsible for identifying a PNF.
SDN-C	SOFTWARE DEFINED NETWORK CONTROLLER (SDN-C) – A controller for Layer 0 to 3 devices. Manages transport and network connections.
DCA&E	DATA COLLECTION, ANALYTICS AND EVENTS (DCAE)– Gathers performance, usage, and configuration data from the managed environment. Collect, store data and provides a basis for analytics within ONAP. For PNF Plug and Play can potentially perform analytics on the Plug and Play process, statistics, logs.
A&AI	ACTIVE & AVAILABLE INVENTORY – The PNF is identified as available inventory and tracked through a key which is the PNF-name. When onboarded the PNF gets an entry in A&AI and can then be tracked, requested, and seen by the ONAP components for service requests or other queries.
SO	SERVICE ORCHESTRATOR – Serves as a mediator and coordinator of service requests.
APP-C	APPLICATION CONTROLLER (APP-C) - A controller for Layer 4 to 7 applications. Manages the life cycle of virtual applications, virtual network functions (VNFs), and components. APP-C manages the 5G DU & 4G DU.
PNF Registration Handler	PNF Infrastructure Manager – A microservice in DCAE used during PNF Plug-n-Play to process the PNF Registration event.

COMPONENT INTERACTION VIEW OF PLUG AND PLAY

The following diagram shows a component interaction view of Plug and Play.

Each of the STEP numbers corresponds to the Step numbers in the flow diagrams that follow, and are described in much more detail in each of those steps.

What should be noted is that Plug and Play is a complex interchange of the Functional run-time components within ONAP, such as the PRH (PNF Registration Handler), SO (service orchestrator), SDN-C (PNF Controller), A&AI (Active & available inventory), the DMaaP (Data Movement as a Platform) and the PNF. You can readily see that A&AI plays a central role during the Plug and Play procedure as the PNF A&AI entry is created and checked numerous times throughout the process. Also take note that SO and SDN-C are the two coordinating entities during the procedure. Notice that the PNF plays a central role in steps 26 and 28 when it is periodically sending the pnfRegistration VES event.

DESIGN TIME - PNF PLUG AND PLAY

STAGE 1 - DESIGN TIME PNP OVERVIEW

Design time and Plug and Play

The following describe the Design time flow.

The primary things that happen in Design time are:

Resources Definition/Services Definition – This is a design time step where the PNF is modeled using SDC. The PNF resource and services are modeled.

SDC: PNF (physical element) Modeling – SDC is used to model the PNF. PNF descriptors and artifacts can be onboarded. The service design is incorporated into the SDC design studio and validated for export.

Distribution of artifacts – The output of design time products is distributed to listeners in other ONAP components.

STAGE 1 - DESIGN TIME REQUIREMENTS

STEP 1 RESOURCE DEFINITION – The PNF resource it defined.

PNP-1090 [SDC] - SDC/CDS: Load PNF model & Controller blue-print for PNF orchestration and Network communication. Before R3/Casalanca a Preload interim solution was used for Network Assignments.

PNP-1100 [SDC] – SDC shall support definition for the resource. A user on the VID performs a Resource Declaration. This uses the Service definition created in SDC using the Design Studio. The user on the VID can define known information about the PNF. The user can (optional) provide the following to define the resource definition.

PNF RESOURCE Definition

Resource Type – Type of Resource. NEW type: PNF (pre-defined in SDC)

NAME – Name of the PNF type

CATEGORY – e.g. Infrastructure

TAGS – User-definable tags (default name of the PNF)

DESCRIPTION – Textual description

CONTACT ID – Designer (user of ONAP)

VENDOR – PNF Vendor (e.g. Nokia)

VENDOR RELEASE – Vendor release

VENDOR MODEL NUMBER – PNF Model value (link to A&AI)

EVENTS – Monitoring Event definitions. Define design-time templates.

SOFTWARE VERSION – The PNF Expected Software Version

STEP 2 SERVICE DEFINITION – The Service Definition is defined in SDC.

PNP-1200 [SDC] – The following service definition fields shall be supported. Note: in Casablanca (R3) one specific PNF can only be used in one service. There is a one-to-one cardinality between PNF and a Service. It is envisioned that for a 5G RAN network, one 5G DU PNF will have one 5G Service and a collection of PNFs will comprise a network.

SERVICE Definition (uses a PNF)

NAME – Name of the Service (mandatory)

CATEGORY – e.g. Network L1…L4, VOIP call Control, Mobility

TAGS – User-definable tags (default name of the PNF)

DESCRIPTION – Textual description of service (mandatory)

CONTACT ID – Designer (user of ONAP) (mandatory)

PROJECT CODE – ID (mandatory)

Naming Policy – Policy to be used to assign a name to a service by SO/SDNC

SERVICE TYPE – Type of service

SERVICE ROLE – The Role of this service.

ENVIRONMENTAL CONTEXT – distributed environments

STEP 3 ARTIFACTS DISTRIBUTION – The artifacts that are defined in SDC are distributed to other components in ONAP once validated.

PNP-1300 [SDC] – SDC shall distribute CSAR package which contains the artifacts & PNF model from the design studio to other components in ONAP. Note: This is existing functionality – Test only requirement.

Note: Package has many catalogs, each application. For example, a model to be consumed by APP-C the model defines how this catalog is called. A publication on DMaaP bus informs that there is an available artifact. The receiving components checks the artifacts and knows what to look for. Each ONAP component gets everything and looks within the package to extract relevant artifacts.

Note: in R3, SDC-UI or CSAR package doesn’t support artifact definitions.

Note: In R3, for the PNF PnP to work, it requires a YAML definition to be manually populated by an operator in the monitoring framework of DCAE, because this can't be supported by SDC yet. These YAML definitions are needed to monitor the NF registration. The YAML definitions includes the registration files for all of the events that the NF can emit.

PNP-1310 [SDC] - [FUTURE] (After R3/Casablanca) - Need NF YAML Definition in the NF CSAR Package. The YAML registration event is necessary to validate what is emitted by the PNF is valid.

PNP-1320 [PNF] - [FUTURE R4] The PNF Vendor shall provide a PNF Descriptor for Design time SDC Design Studio input based on ETSI-NFV-IFA014v242 (see 48534348 for more details)

PNP-1330 [PNF] - The PNF Vendor MAY provide software Version(s) to be supported by PNF for SDC Design Studio PNF Model. This is set in the PNF Model property software_versions.

PNP-1340 [PNF] - The following VES Events MUST be supported by the PNF for Plug and Play: pnfRegistration VES Event. These are onboarded via the SDC Design Studio. Note: these VES Events are emitted from the PNF to support PNF Plug and Play. A PNF MUST support the pnfRegistration VES event which is required to integrate with ONAP’s PNF Plug and Play capabilities.

STAGE 1 - PNF MODEL

The following describes the PNF model in SDC in the Beijing (R2) release. The following parameter are already supported in Beijing (R2) but because the PnP Use Case was not delivered, these will see their first operational use in the Casablanca (R3) release.

MODEL PARAMETER	DESCRIPTION
pnfId*	Identifier of this Pnf information element. CORRELATIONID = PNF-NAME (A&AI)
pnfType (template)*	Type of Resource. NEW type: PNF (pre-defined in SDC)
Category*	PNF category, e.g. infrastructure
Vendor (template)*	Identifies the vendor of the PNF.
Name*	Provides the human readable name of the PNF.
vendorrelease *	Vendor release
vendormodelNumber*	PNF Model value (link to A&AI)
functionDescription*	Describes the PNF function

PNP-1400 [SDC] – SOFTWARE VERSION - SDC shall support the SWversionList in the NF Model. This parameter represents a list of Expected Software to be supported by the NF. This is an optional parameter. As a LIST, this parameter shall support a structured list of software versions (as strings).

Note: The actual software running on a PNF instance is kept in an A&AI parameter for the PNF instance. This “detected Software” can be used in conjunction with this modeling parameter.

Note: This parameter may be used for a wide variety of purposes from network analysis, network planning, modeling analysis, trouble shooting, auditing, correlation, modeling informational, error checking, system evolution, network evolution, life cycle management, regional planning, regional analysis, service provider specific analytics, network management, and PNF feature & functional correlation.

STAGE 1 - PNF DESCRIPTOR

The following table is the PNF descriptor

Attribute	Qualifier	Cardinality	Content	Description
pnfdId	M	1	Identifier	Identifier of this Pnfd information element. It uniquely identifies the PNFD.
functionDescription	M	1	String	Describes the PNF function
provider	M	1	String	Identifies the provider of the PNFD.
version	M	1	Version	Identifies the version of the PNFD.
pnfdInvariantId	M	1	Identifier	Identifies a PNFD in a version independent manner. This attribute is invariant across versions of PNFD.
name	M	1	String	Provides the human readable name of the PNFD.
pnfExtCp	M	1 … N	PnfExtCpd	Specifies the characteristics of one or more connection points where to connect the PNF to a VL. See clause 6.6.4.
security	M	0..1	SecurityParameters	Provides a signature to prevent tampering.
geographicalLocationInfo	M	0..1	Not specified	It provides information about the geographical location (e.g. geographic coordinates or address of the building, etc.) of the PNF. The cardinality 0 is used when the location is unknown.

RUN-TIME PNP FLOWS AND REQUIREMENTS

The following sections describe the flows and requirements for the major phases in Plug and Play during run time.

STAGE 2 RUN-TIME SERVICE INSTANTIATION

In the Service instantiation phase of Plug and Play, three main things happen:

PNF Infrastructure Service Declaration – A work flow is invoked by an operator which will create a request for a PNF to be instantiated. This work flow is invoked from a OSS or VID interface.

First part of PNF instantiation – This service instantiation work-flow is received and handled by the service orchestration (SO) component in ONAP.

DCAE & AAI Entry with PNF-name (e.g. MAC address) – The result of this stage of Plug and Play is that an inactive A&AI entry is created so that ONAP will be prepared when the PNF tries to register. It might also be the case that the A&AI entry was previously created from a different interface, in this case the A&A entry will already be in place.

STAGE 2 – SERVICE INSTANTIATION REQUIREMENTS

STEP 15 – WORK ORDER INITIATED - In this step, a Work Order is initiated from an operator using the VID. The Plug and Play flow requires an A&AI entry to be created so that when the PNF registers ONAP will recognize the unit. This requires that an operator be aware of the elements that need to be deployed into their network.

PNP-2000 [OSS/BSS/VID] – WORK ORDER – An operator processes a work order. The PNF service instantiation will be a result of processing the work order. Note: External ONAP APIs may be used to interface with the OSS/BSS.

STEP 16 – SERVICE INSTANTIATION - In this step, a service instantiation is issued from VID to SO. The operator invokes a service instantiation so that SO can take the necessary steps to create or verify that there is an A&AI entry for the PNF which satisfied the work order.

PNP-2100 [VID] – SERVICE INSTANTIATION - VID shall support the ability to invoke a Service Instantiation request to SO for the creation of a PNF. The operator uses VID to instantiate a Service. The Correlation ID = PNF Name = 3 characters of Vendor + PNF Serial Number are provided in the Service Instantiation request to SO.

Note: Other OSS/BSS systems may be used to instantiate a service.

Note: A service provider may choose to use a different identifier than the [Vendor] + [Serial Number], the corresponding PNF would need to also be configured to emit a matching identifier from the pnfRegistration Event.

PNP-2110 [SO] – SO shall decompose the 5G DU PNF Service. Based on the DU resource type, SO shall determine the appropriate SDC PNF Model for the service instantiation. Note: it is also possible that the Plug and Play (PnP) service instantiation may be part of a larger work-flow (e.g. VCPE work flow), during that larger work flow the PnP flow may happen. This would be handled by the service work-flow designer. Note: it is expected that the SO API shall be used for the service instantiation no matter the source (OSS/BSS or VID).

PNP-2120 [SO] – If SO is unable to perform the service instantiation it shall return an error.

STEP 17 – HOMING CHECK - A homing operation can be performed, though in Casablanca this is not used. The homing function by OOF can perform network deployment and network optimization functions. Note: There are optimization use cases that are being invested for development in Casablanca.

PNP-2200 [SO] – SO shall invoke OOF for a homing check.

PNP-2210 [OOF] – OOF shall return an acknowledgement. For the Plug and Play procedure in Casablanca the PNF OOF check has no impact.

STEP 18 – RESOURCE LEVEL FLOW - Resource Level Flow is invoked. The resource level flow is handled by SO to create the A&AI entry for the PNF if necessary.

PNP-2300 [SO] – SO shall invoke a Resource Level flow for the PNF instantiation.

PNP-2310 [SO] – SO checks A&AI for an entry that matches the PNF-Name.

STEP 19 – PNF A&AI ENTRY FOUND - ALT Flow: A&AI Entry found

PNP-2400 [SO] – FUTURE If SO determines that an A&AI entry already exists for the PNF when it performs the query, then SO shall associate the PNF with the service instance and it shall then proceed to step 21.

PNP-2405 [SO] - If SO determines that an A&AI entry already exists for the PNF when it performs the query, and SO will exit out.

PNP-2410 [A&AI] – A&AI shall return a PNF query check using the PNF-Name. If the entry is not found a negative acknowledgement shall be returned.

PNP-2415 FUTURE [SO] - STEP 19A/B (Active/Inactive) A&AI PNF Entry Found

STEP 20 – PNF A&AI ENTRY MISSING - ALT Flow: A&AI Entry missing

PNP-2500 [SO] – SO shall check for the A&AI entry, and SO shall identify if that A&AI entry does not exist, then SO shall proceed to step 21.

PNP-2510 [A&AI] – A&AI shall support responding to a query for an entry for the PNF.

STEP 21 – SUBSCRIBE - Subscribes to VES Event

PNP-2600 [SO] – SO shall subscribe to the DMaaP pnfReady topic. Note: The pnfReady event is published by the PRH after the PNF successfully registers with ONAP (Step 31)

PNP-2610 [SO] – If there is a fault subscribing to the pnfReady topic (DMaaP) the fault shall be logged.

STEP 22 – RESOURCE LEVEL FLOW (RLF) TERMINATES - The Resource Level Flow (RLF) waits

PNP-2700 [SO] – The SO RLF shall terminate and goes into a “wait state” awaiting rehydration after the PRH receives the PNF registration message from the PNF. Note: SO is pending a pnfReady event to be published onto the DMaaP Bus from the PRH to rehydrate this thread.

PNP-2710 [SO] – After SO terminates the RLF, SO shall wait for 2 weeks for the PNF to perform a registration. After 2 weeks passes the Work-flow shall terminate and generate an error which shall be logged and displayed on the OSS.

PNP-2720 [SO] – If there is a fault terminating the RLF, the fault shall be logged.

STAGE 2 - PNF A&AI ENTRY USED BY PNP

ACTIVE & AVAILABLE INVENTORY (A&AI) PNF RECORD
PNF-NAME	“pnf-name”. The pnf-name is the Key in AAI. The pnf-id is the first three letters of the Vendor and the PNF serial number. This is a unique identifier for the PNF instance. It is also referred to as the Correlation ID. It can serve as a unique key for the PNF. Note: The MAC address and serial number are not unique across vendors; but are unique per vendor, hence the Vendor name is added to insure uniqueness. Note: in R4/R6 there was a request to use PNF-id instead of PNF-name but that proposal has been rejected.
EQUIP-TYPE	The equip-type parameter gives the type of the PNF.
EQUIP-VENDOR	The equip-vendor is an optional parameter which indicates the vendor for the PNF. For example, Nokia or Ericsson.
EQUIP-MODEL	The equip-model is an optional parameter which indicates the model of the PNF.
PNF-ID	This is the UUID which is a service provider assigned number from for example a network planner..
IPADDRESS V4-OAM	This is the Manager IP Address in IPv4 for the PNF. For a DU, this might be a CU IP address; (FYI/ ipaddress-v4-loopback-0).
IPADDRESS v6-OAM	This is the Manager IP Address in IPv6 for the PNF. For a DU, this might be a CU IP address;
MAC ADDRESS	This is the MAC address of the PNF. This is a service field.
SERIAL NUMBER	This is the serial number of the PNF. This is a service field.
PROXY IP ADDRESS	This field contains the proxy IP address for the PNF.

ACTIVE & AVAILABLE INVENTORY (A&AI) PNF RECORD ADDITIONS FOR R3 CASABLANCA

ATTRIBUTE

DESCRIPTION

PNFIPADDRESS-v4

This is the IP address (IPv4) for the PNF itself. This is the IPv4 address that the PNF iself can be accessed at.

PNFIPADDRESS-v6

This is the IP address (IPv6) for the PNF itself. This is the IPv4 address that the PNF iself can be accessed at.

SOFTWARE_VERSIONS

This is an Array of software versions that currently installed on the PNF. PNFs can have multiple partitions, and this array represents a list of all of the software versions that are currently installed on the PNF.. The Active SW is a boolean (True/False) that indicates that this specific version if the one that is "active" (if True).

software_versions [1…x] (Array)

{

software_version (String)

activeSw (Boolean)

}

STAGE 3 - PNP BOOTSTRAPPING

Assumption: Physical management connectivity between ONAP and the PNF is assumed to be setup prior to PNF Plug and Play, e.g. dealing with firewalls. etc.

In this stage, the PNF Boot-straps. This is comprised of two steps

PNF Powers up and Boot-straps – Vendor specific steps are performed where the PNF is physically installed, powers up, and performs boot-strapping functions.

PNF performs a “Plug and Play” procedure – The PNF performs vendor specific steps which will allow the PNF to reach a state such that it is ready to contact ONAP.

It is a requirement from ONAP on the equipment (PNF) vendors that the PNF shall have software capable of performing the PNF Registration. This shall be referred to as ONAP-aware software.

See the section on the ONAP needs to be developed by the PNF Vendors section of this document for more details, entitled “Vendor PNF PNP Deliverables”

Vendor PNF requirements in DOC project (the Appendix of “Vendor PNF PnP Deliverables)

PNP-3010 [PNF] - The PNF MUST support & accept the provisioning of an ONAP contact IP address (in IPv4 or IPv6 format).

Note: It is expected that an external EMS would configure & provision the ONAP contact IP address to the PNF (in either IPv4 or IPv6 format). For the PNF Plug and Play Use Case, this IP address is the service provider's "point of entry" to the DCAE VES Listener.

Note: different service provider's network architecture may also require special setup to allow an external PNF to contact the ONAP installation. For example, in the AT&T network, a maintenance tunnel is used to access ONAP.

PNP-3020 [PNF] - The PNF MUST have "ONAP Aware" software which is capable of performing PNF PnP registration with ONAP. The "ONAP Aware" software is capable of performing the PNF PnP Registration with ONAP MUST either be loaded separately or integrated into the PNF software upon physical delivery and installation of the PNF.

Note: It is up to the specific vendor to design the software management functions.

PNF-3030 [PNF] - The PNF MUST support the provisioning of security and authentication parameters (HTTP username and password) in order to be able to authenticate with DCAE (in ONAP).

Note: In R3, a username and password are used with the DCAE VES Event Listener which are used for HTTP Basic Authentication.

Note: The configuration management and provisioning software are specific to a vendor architecture.

STAGE 4 RUN-TIME PNF REGISTRATION

In this phase of Plug and Play the PNF Registers with ONAP

STAGE 4 – PNF REGISTRATION ONAP REQUIREMENTS

This section describes the PNF registration steps. In this stage of the PnP procedure, the PNF is registering with ONAP. The PNF periodically sends up a PNF registration event. PRH is receiving these events and waiting for the SO instantiation to happen.

STEP 25 AUTHENTICATION – In this step a series of steps occur for the PNF to authenticate with ONAP. This may include TLS1.2 security exchanges, certificate exchanges, and User name/password exchanges. This should be tested. the generalized detailed requirements for security are covered in the security sub-committee.

PNP-4100 [AAF] AAF shall authenticate the PNF. Note: This requirement is here for testing purposes, the detailed requirements for PNF to ONAP security shall be detailed in the security sub-committee.

PNP-4110 [AAF] AAF shall be able to inboard the security keys for vendor certificate validation.

PNP-4120 [PNF] - When the PNF sets up a HTTP or HTTPS connection, it MUST provide a username and password to the DCAE VES Collector for HTTP Basic Authentication.

Note: HTTP Basic Authentication has 4 steps: Request, Authenticate, Authorization with Username/Password Credentials, and Authentication Status as per RFC7617 and RFC 2617

PNP-4121 [PNF] - If the PNF set up a TLS connection and mutual (two-way) authentication is being used, then the PNF MUST provide its own X.509v3 Certificate to the DCAE VES Collector for authentication.

Note: This allows TLS authentication by DCAE VES Collector..

Note: The PNF got its X.509 certificate through Enrollment with an operator certificate authority or a X.509 vendor certificate from the vendor factory CA.

Note: In R3 three authentication options are supported:

(1) HTTP with Username & Password and no TLS

(2) HTTP with Username & Password & TLS with two-way certificate authentication;

(3) HTTP with Username & Password & TLS with server-side certificate authentication.

PNP-4130 [DCAE] - DCAE authenticates the HTTP/TLS connection with a certificate. Certificate is X.509v3 issued by the Service Provider CA. Note: in Dublin, no HTTP username or password is needed.

PNP-4140 [DCAE] - VES Collector authenticates the PNF using the a username and password, Certificate, and standard PKI validation.

PNP-4150 [DCAE] - VES uses integrated CADI module to request the role and permissions for the PNF from AAF.

PNP-4160 [AAF] - AAF returns the role and permissions of the PNF to DCAE.

PNP-4170 [DCAE] - DCAE compares the event to the permissions and either accepts or rejects the event.

STEP 26 PNF SENDS PNF REGISTRATION – The PNF (5G DU) sends a PNF registration message which is received by the PNF Registration Handler in ONAP. This message is sent by the PNF periodically.

PNP-4200 [PNF] – The PNF MUST use a IP address to contact ONAP.

Note: it is expected that an ONAP operator can ascertain the ONAP IP address or the security gateway to reach ONAP on the VID or ONAP portal GUI. Note: The ONAP contact IP address has been previously configured and provisioned prior to this step.

Note: The ONAP IP address could be provisioned or resolved through FQDN & DNS.

PNP-4201 [PNF] - The PNF SHOULD support a HTTPS connection to the DCAE VES Event Listener.

PNP-4202 [PNF] - The PNF MAY support a HTTP connection to the DCAE VES Event Listener.

Note: HTTP is allowed but not recommended.

PNP-4210 [PNF] – The PNF MUST support sending a pnfRegistration VES event. This is detailed in the “PNF Registration VES Event” section of the Plug and Play wiki page at: 48534348

Note: See the Vendor PNF PNP Deliverables (in the ONAP DOC Project) URL/Wiki: https://onap.readthedocs.io/en/latest/submodules/vnfrqts/requirements.git/docs/Chapter7/PNF-Plug-and-Play.html

Note: ONAP sends back a "normal" Acknowledgement (ACK) to the pnfRegistration VES event (HTTP or HTTPS)

STEP 26A pnfREGISTRATION EVENT ONTO DMAAP

The pnfRegistration VES Event is published onto DMaaP.

PNP-4220 [DCAE/DMaaP/DR] - When the PNF sends the pnfRegistration Event to the DCAE VES Event Listener, DCAE shall publish the VES event received from the PRH onto the DMaaP/DR. The VES event should be using the pnfRegistration domain (Casablanca)

PNP-4230 [DMaaP] – There shall be created a static pnfRegistration DmaaP Topic. Note: That a static as opposed to a dynamic DMaaP topic is needed because it is not known what PNF service will be needed when the PNF registers.

STEP 26B pnfREGISTRATION EVENT RETRIEVED BY PRH

The pnfRegistration VES Event is retrieved by the PRH.

PNP-4235 [PRH] - PRH shall retrieve the pnfRegistration Event off of the DMaaP Bus. PRH shall periodically check the DMaaP bus for the VES event for the PRH.

PNP-4240 [PRH] – If the PRH is unable to read from DMaaP on the pnfRegistration domain it shall return an error.

PNP-4250 [DMaaP] In DMaaP, end-points need to be configured (topic creation). And PRH needs to have these end-points configured as well. PRH needs to pick up this configuration (cloudify module). And if they are not properly configured, PRH is unable to get the pnfRegistration message off of the DMaaP bus. What would happen is that the DMaaP end-point does not exist; thus an HTTP error response is returned to the PRH. It would require an operator to deduce that this problem has occurred.

PNP-4260 [PRH] - if the PRH is unable to read the pnfRegistration VES message. In this case the schema might be incorrect which results in a mismatch with what the PNF sends and what the PRH expects. Thus, the PRH is unable to process the VES event properly. The PRH shall logs this error.

STEP 27 PRH DOES INVENTORY QUERY – PRH performs an A&AI inventory query when it receives the pnfRegistration VES event from PNF to see if the entry exists.

PNP-4300 [PRH] – The PRH shall perform an A&AI inventory query when it receives the pnfRegistration VES event. In this case, the A&AI entry does not exist yet. PRH will continue to wait, pending the SO resource instantiation flow. Note: The expectation is that the PNF will continue to send VES events periodically. This would be a vendor requirement upon the PNF. Note: ONAP will wait up to 2 weeks for the PNF to register from the point in time that first service instantiation is created for the PNF.

PNP-4310 [PRH] – (Error Case) If the PRH is unable to perform an inventory query from A&AI it shall log the error.

PNP-4320 [PRH] - The PRH shall use the "sourcename" as the index into the A&AI key. This is sent from the pnfRegistration VES event. Note: that this is suggested to be the first three letters of the Vendor & the Serial Number, if a vendor-service provider wishes to use a different string the Service instantiation and the pnfRegistration event's "sourcename" should match. (See requirement PNP-2100)

STEP 28 PNF SENDS PNF REGISTRATION – PNF continues to send a PNF registration event

PNP-4400 [PRH] - PRH shall periodically check the DMaaP bus checking for the pnfRegistration domain for VES events related to PRH handling. Because the PNF is continuing to periodically send pnfRegistration events, PRH should continue to receive them.

PNP-4410 [PNF] The PNF MUST send the pnfRegistration VES event periodically.

PNP-4411 [PNF] - The pnfRegistration VES event periodicity SHOULD be configurable.

Note: The PNF uses the service configuration request as a semaphore to stop sending the pnfRegistration sent. See the requirement PNP-5360 requirement.

PNP-4420 [PNF] - If the PNF encounters an error authenticating, reaching the ONAP DCAE VES Event listener or recieves an error response from sending the pnfRegistration VES Event, it MAY log the error, and notify the operator.

Note: the design of how errors are logged, retrieved and reported will be a vendor-specific architecture. Reporting faults and errors is also a vendor specific design. It is expected that the PNF shall have a means to log an error and notify a user when a fault condition occurs in trying to contact ONAP, authenticate or send a pnfRegistration event.

PNP-4430 [DCAE] – The pnfRegistration VES event from the PRH shall be received by DCAE.

PNP-4440 [DMaaP] – The pnfRegistration VES event shall be published on the DMaaP bus with the appropriate PNF-name on the pnfRegistration domain. The DCAE VES Collector puts the pnfRegistration VES event received by the PNF with the PNF-ID (concatenation of the Vendor & Serial Number) onto the DMaaP bus.

Note: This will have been a statically created domain before this event arrives in ONAP.

PNP-4450 [DCAE] – The VES event that is received by the PNF shall follow the appropriate fields and corresponding information. These are further detailed in the PNF Registration VES Event section. DCAE shall receive the event and check the header in the VES event. Note: The composition of the appropriate VES event is also requirement on the PNF to be developed by the PNF vendor.

STEP 29 INVENTORY QUERY - PRH performs an A&AI inventory query when it receives the VES event to see if exists.

PNP-4500 [PRH] – The PRH shall perform an A&AI inventory query when it receives the pnfRegistration VES event from the PNF. Note: it is expected that the PNF shall continue to send the VES event until it receives the service configuration request. After the Stage 2 Run-Time Service Instantiation occurs, there shall be an inactive A&AI entry for the PNF. This allows PRH to find that inactive A&AI entry and proceed with the rest of the Plug and Play procedure. PRH shall use the PNF-name (or correlation ID) to find the appropriate PNF A&AI entry.

PNP-4510 [A&AI] – A&AI shall return the entry for the PNF-name when queried. If not found A&AI shall return a negative acknowledgement. See the section on the A&AI PNF entry for more details about the fields that are relevant for the PNF.

PNP-4520 [PRH] - The PRH shall use the "sourcename" as the index to A&AI.

STEP 30 UPDATE PNF ENTRY – PRH finds the PNF A&AI entry and updates it with the PNF IP address

PNP-4600 [PRH] – If PRH finds an A&AI entry for the PNF, it shall populate the IP address for that entry with the IP address provided in the pnfRegistration VES event sent from the PNF.

Note: The PNF is the master of its IP address and would over-write the IP address in the PNF A&AI entry with the one provided in the VES event.

PNP-4605 [DUBLIN][PRH] - The PRH shall enter the following information into the A&AI entry for the PNF extracting the corresponding information from the incoming pnfRegistration VES message.

A&AI PNF ENTRY	BASED ON pnfREGISTRATION VES FIELD
serial-number	serialNumber
equip-vendor	vendorName
equip-model	modelNumber
equip-type	unitType
pnf-name	sourceName
pnf-id	(PNF-ID is NOT used)
ipaddress-v4-oam	oamV4IpAddress
ipaddress-v6-oam	oamV6IpAddress
software_versions	software_versions [1] { softwareVersion (from pnfRegistration) activeSw = "True" } Note: During PNF Registration only the Active S/W is reported by the PNF. And so only the entry of the PNF A&AI array with the "activeSw" = True would be updated. The PNF S/W upgrade management U/C will update the entire array through the operations of S/W management.

PNP-4610 [PRH] – If the PRH encounters a situation that there is a PNF entry in A&AI (without IP address), but the VES event itself does not have an PNF IP address it shall log the error. Note: if the PNF does not send its IP address in the VES event this could be from a variety of reasons from a software error to a communication failure.

PNP-4620 [PRH] – (Error Case) If the PRH is unable to update the A&AI entry with the PNF information it shall log the error.

STEP 31 PNF READY EVENT – PRH issues a pnfReady event.

PNP-4700 [PRH] – After the PRH write the IP address of the PNF in the A&AI entry, the PRH shall publish a pnfReady event on the DMaaP topic. Note: This pnfReady event shall be processed by SO to proceed with the Plug and Play procedure.

PNP-4710 [DMaaP] – There shall be created a static pnfReady DMaaP Topic.

PNP-4720 [PRH] – (Error Case) If the PRH is unable to publish the pnfReady event onto the DMaaP topic it shall log the error.

STAGE 3 - PNF REGISTRATION VES EVENT

Field	Type	Required?	Description
Version	number	Yes	Version of the event header (currently: 3.0): 3.0
eventName	string	Yes	pnfRegistration_vendor_pnfName where pnfName is specified by the vendor and is a PNF type; e.g. pnfRegistration_Nokia_gDu
domain	string	Yes	Event domain enumeration: ‘fault’, ‘heartbeat’, ‘measurementsForVfScaling’, ‘mobileFlow’, ‘other’, ‘sipSignaling’, ‘stateChange’, ‘syslog’, ‘thresholdCrossingAlert’, ‘voiceQuality’, ‘pnfRegistration’
eventId	string	Yes	Event key that is unique to the event source registration_yyyyyyyy where yyyyyyyy is an integer starting at 0 and incremented by 1 for every pnfRegistration event sent by this PNF. The key must be unique within notificaiton life cycle similar to EventID from 3GPP. It could be a sequential number, or a composite key formed from the event fields, such as domain_sequence. The eventId should not include whitespace.
eventType	string	No	pnfRegistration
nfcNamingCode	string	No	Network function component type: 3 characters (aligned with vfc naming standards). This is not used
nfNamingCode	string	No	Network function type: 4 characters (aligned with vnf naming standards) Not used
sourceId	string	No	UUID identifying the entity experiencing the event issue (note: the AT&T internal enrichment process shall ensure that this field is populated) Not used
sourceName	string	Yes	Name of the entity experiencing the event issue PNF-name (unique PNF correlation ID = pnf-name stored in AAI ; e.g. NOK6061ZW3)
reportingEntityId	string	No	UUID identifying the entity reporting the event, for example an OAM VM (note: the AT&T internal enrichment process shall ensure that this field is populated) Not used
reportingEntityName	string	Yes	Name of the entity reporting the event, for example, an EMS name. May be the same as the sourceName. For synthetic events generated by DCAE, it is the name of the app generating the event. PNF-name (unique PNF correlation ID = pnf-name stored in AAI ; e.g. NOK6061ZW3)
priority	string	Yes	Processing priority enumeration: ‘High’, ‘Medium’, ‘Normal’, ‘Low’ Normal
startEpochMicrosec	number	Yes	the earliest unix time aka epoch time associated with the event from any component--as microseconds elapsed since 1 Jan 1970 not including leap seconds current time
lastEpochMicrosec	number	Yes	the latest unix time aka epoch time associated with the event from any component--as microseconds elapsed since 1 Jan 1970 not including leap seconds current time
sequence	integer	Yes	Ordering of events communicated by an event source instance (or 0 if not needed) 0
internalHeader Fields	Internal Header Fields	No	Fields (not supplied by event sources) that the VES Event Listener service can use to enrich the event if needed for efficient internal processing. This is an empty object which is intended to be defined separately by each provider implementing the VES Event Listener. Empty. Not used
vesEventListenerVersion	string	Yes	Version of the VES event listener API Spec that this event is compliant with (As "#" or "#.#" or "#.#.#" where # is a digit.
timeZoneOffset	string	No	Offset to GMT to indicate local time zone for device formatted as 'UTC+/-hh.mm'; see https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations for UTC offset examples
Field	Type	Required?	Description
pnfRegistration FieldsVersion	number	Yes	Version of the pnfRegistrationFields block as "#.#", where # is a digit (currently: 1.0). See the VES Event Specification for the correct digits to use.
serialNumber	string	Yes	TS 32.692 serialNumber = serial number of the unit; e.g. 6061ZW3
vendorName	string	Yes	TS 32.692 vendorName = name of manufacturer; e.g. Nokia. Maps to AAI equip-vendor.
oamV4IpAddress	string	No	IPv4 m-plane IP address to be used by the manager to contact the PNF. Maps to AAI ipaddress-v4-oam.
oamV6IpAddress	string	No	IPv6 m-plane IP address to be used by the manager to contact the PNF. Maps to AAI ipaddress-v6-oam.
macAddress	string	No	MAC address of OAM interface of the unit.
unitFamily	string	No	TS 32.692 vendorUnitFamilyType = general type of HW unit; e.g. BBU.
unitType	string	No	TS 32.692 vendorUnitTypeNumber = vendor name for the unit; e.g. Airscale. Maps to AAI equip-type.
modelNumber	string	No	TS 32.692 versionNumber = version of the unit from vendor; e.g. AJ02. Maps to AAI equip-model.
softwareVersion	string	No	TS 32.692 swName = active SW running on the unit; e.g. 5gDUv18.05.201.
manufactureDate	string	No	TS 32.692 dateOfManufacture = manufacture date of the unit in ISO 8601 format; 2016-04-23.
lastServiceDate	string	No	TS 32.692 dateOfLastService = date of last service in ISO 8601 format; e.g. 2017-02-15.
additionalFields	hashMap	No	Additional registration fields if needed, provided as key-value pairs.

STAGE 5 - RUN-TIME PNF ACTIVATION

In the last Stage 5, SO coordinates with the PNF controller and the PNF is given network assignments, configures, and becomes active and available for service.

STAGE 5 - PNF ACTIVATION REQUIREMENTS

This section describes the PNF activation requirements. In this stage of PNP, the PNF has sent the PNF registration event and it has been received by the PRH successfully, and now in the PnP procedure, SO coordinates with the PNF controller and SDN-C to give the network assignments and service configuration for the PNF.

The major outcome of Stage 5 of the Plug and Play procedure is:

Connection points configured – SDN-C in ONAP configures the PNF transport information.

Second part of PNF service instantiation – The second part of PNF service instantiation is performed and ONAP sends the PNF a service configuration message. Also, ONAP updates the network assignment information, starts the service, and monitors the service provided by the PNF.

PNF configured and ready to provide service – Any other vendor specific configuration is finished, and the PNF is now ready to provide service.

STEP 34 UPDATE PNF WORKFLOW – DCAE rehydrates the SO Work-flow. In Step 31, the PRH has published a pnfReady onto the DMaaP Bus.

PNP-5000 [DCAE] - DCAE rehydrates the SO Resource-Level flow. The pnfReady topic on the DMaaP bus is used by SO to rehydrate the Resource-level flow.

PNP-5010 [SO] – SO monitors for the pnfReady topic on the DMaaP bus and shall invoke the update PNF work-flow for the PNF with the PNF-name given in the pnfReady event. This is a "rehydration" of the Resource Level Flow (RLF) that was used in the Service Instantiation in Stage 2.

PNP-5020 [SO] – (Error Case) If there is an error in invoking the Work-flow an error shall be logged.

STEP 34A SO CHECKS A&AI – SO Verifies that the PNF is in A&AI..

PNP-5030 [SO] – SO shall query A&AI upon receipt of the pnfReady Event. SO queries A&AI for a valid PNF entry associated with the pnf-name in the pnfReady event.

STEP 35 NETWORK ASSIGNMENTS – SDN-C performs the Network Assignments

PNP-5105 [SO] - SO shall invoke SDN-C for perform Network Assgnments for the PNF.

PNP-5100 [SDN-C] - SDN-C shall perform the Network Assignments.

STEP 35A UPDATED NETWORK ASSIGNMENTS – Network assignments by SDN-C are updated in A&AI.

PNP-5110 [SDN-C] – SDN-C shall update the Network assignments information into PNF entry in A&AI.

PNP-5120 [A&AI] – A&AI shall support an update of the Network Assignments with the appropriate fields. For more information see the A&AI section on PNF A&AI entry

PNP-5130 [SDN-C] – (Error Case) If there is an error in update it shall log the error.

STEP 35B NETWORK ASSIGNMENTS COMPLETED – SDN-C informs SO

PNP-5130 [SDN-C] – SDN-C informs SO of updated Network Assignments.

STEP ~~(35C)~~ ROLE ASSIGNMENTS - ~~SO Triggers AAF to assign PNF instance to Role~~

~~PNP-5140 [SO]~~[REDACTED] ~~- SO triggers AAF to assign PNF instance to role.~~

~~PNP-5150 [AAF]~~[REDACTED] ~~- AAF assigns PNF instance to PNF-type role. AAF assigns permissions to the PNF-type role, and assigned the PNF to the role for the PNF type. CADI is integrated into DCAE VES Collector.~~

PNP-5145 Role Assignments [DUBLIN][DCAE] - This is no longer needed because the PNF Registration (YML) will serve as a mechanism to "authorize" the PNF. i.e. DCAE knows that it is expecting a VES event from this those PNF types.

~~STEP 35D ROLE ASSIGNMENT COMPLETE~~

~~PNP-5160 [AAF]~~[REDACTED] ~~- Notifies SO that PNF role assignment is complete.~~

STEP 36 CONFIGURE SERVICE – SO configures the Service with a call to the PNF controller

PNP-5200 [SO] – SO shall configure the PNF controller with the information that needs to be sent to the PNF.

Note: for R3 (Casablanca), SO hard-codes the PNF controller. For example, for 5G RAN DU PNFs, SDN-C/SDN-R is the PNF controller.

Note: SO interacts with the PNF controller with the Understanding the the GENERIC-RESOURCE-APIs

Note: For each associated API there is an associated Directed Graph (which playbook should be called).

STEP 37 SERVICE CONFIGURATION – ONAP sends a Service Configuration to the PNF

PNP-5300 [CONTROLLER] – The PNF Controller shall sends a Service Configuration to the PNF.

PNP-5310 [CONTROLLER] – The following parameters are optional parameters that shall be supported by the ONAP Controller that might be sent to the PNF if they are configured.

SERVICE CONFIGURATION PARAMETER	DESCRIPTION
Configuration Parameter (optional)	SDN-R/APP-C gives the Controller IP@ to the DU. In R3, SDN-R/APP-C may pass configuration parameter(s) to the 5G DU, this will also give a configuration parameter (e.g. CU IP@).
OAM IP address (optional)	The permanent OAM IP address is given to the PNF. The IP address may come from vAAA, or drawn local pool of IP addresses. SDN-C performs the IP address selection. SDN-C knows if a permanent IP address should be assigned.
Transport configuration (optional)	Transport configuration is given to the PNF.
Location (optional)	the Location configuration may be given to the PNF.
Software Version (optional)	In Casablanca it could be specified a Software Version.

PNP-5320 (CONTROLLER) – (Error Case) If there is an error encountered trying to send the Service Configuration command exchange to the PNF, the Controller shall log the fault.

PNP-5330 (CONTROLLER) – (Recovery Case) If there is an error encountered trying to send the Service Configuration command exchange to the PNF, the Controller shall attempt to retry.

PNP-5340 (CONTROLLER) – (Recovery Case) If there is not acknowledgment or response from the PNF while trying to perform a service configuration exchange, the controller shall wait for a time-out period before aborting this attempt. Note: This might be caused by a transient network issue.

PNP-5350 [PNF] - The PNF MUST support the Anible protocol for a Service Configuration message exchange between the PNF and PNF Controller (in ONAP).

Note: this exchange may be either Ansible, Chef, or NetConf depending on the PNF. Note: The PNF Controller may be VF-C, APP-C or SDN-C based on the PNF and PNF domain. Note: for R3 (Casablanca) only Ansible is supported.

PNP-5360 [PNF] - When the PNF receives a Service configuration from ONAP, the PNF shall cease sending the pnfRegistration VES Event.

PNP-5370 [PNF] - The PNF MAY support the optional parameters for Service Configuration Parameters.

Note: These are detailed in the Stage 5 PnP Use Case at: 48534348

Note: These parameters are optional, and not all PNFs will support any or all of these parameters, it is up to the vendor and service provider to ascertain which ones are supported up to an including all of the ones that have been defined. Note: It is expected that there will be a growing list of supported configuration parameters in future releases of ONAP.

PNP-5380 [PNF] (Error Case) - If an error is encountered by the PNF during a Service Configuration exchange with ONAP, the PNF MAY log the error and notify an operator.

PNP-5390 [PNF] (Error Case) - The PNF must support a configurable timer to stop the periodicity sending of the pnfRegistration VES event. If this timer expires during a Service Configuration exchange between the PNF and ONAP, it MAY log a time-out error and notify an operator.

Note: It is expected that each vendor will enforce and define a PNF service configuration timeout period. This is because the PNF cannot wait indefinitely as there may also be a technician on-site trying to complete installation & commissioning. The management of the VES event exchange is also a requirement on the PNF to be developed by the PNF vendor.

STEP 38 UPDATE CONFIGURATION INFO – The Controller updates the the PNF A&AI Entry

PNP-5300 [Controller] – The PNF Controller shall update the PNF A&AI Entry with updated configuration information.

STEP 39 SERVICE CONFIGURED – The Controller replies to SO

PNP-5500 [Controller] – The Controller shall return a response to SO after service configuration

STEP 40 SERVICE RUNNING – The PNF service is running and available to provide service

PNP-5600 [SO] – SO shall send a service running on DCAE.

STEP 41 MONITOR SERVICE – ONAP can now monitor the Service

PNP-5700 [DCAE] – DCAE shall monitor the new service

STEP 42 SERVICE MONITORED – DCAE responds with Service Monitored

PNP-5700 [DCAE] – DCAE shall respond to SO that the Service is monitored

STEP 43 INFORM OSS – An operator at the OSS can now see that the service is available.

PNP-5800 [SO] – SO shall inform the OSS that the PNF service is available and ready.

PNF DOWNLOAD & ACTIVATION

The final steps of PNF Plug and Play occur after the PNF has been registered. The ONAP PNF Software Use Case is also executed to update the software if necessary.

STEP 44 CONFIGURATION – The PNF can have additional configuration or parameters that can be sent to the PNF from ONAP or an external Element Management System. Additioanl configuration exchanges can happen between the PNF and ONAP through the standard Defined VES event as introduced by this use case: ONAP/3GPP & O-RAN Alignment-Standards Defined Notifications over VES

STEP 45 PNF SOFTWARE UPGRADE – Software download occurs which is described in this use case: 5G - PNF Software Update

STEP 45 READY FOR SERVICE – The PNF is ready for service.

PNP REREGISTRATION USE CASE

This use case is intended to cover a new Epic or Use Case or "Story" for Plug and Play. In all of these situations for this use case, the PNF will go through Plug and Play registration again, hence "PNF Re-registration". In this case, the PNF has already ungone the basic Plug and Play is registering again with the same PNF registration procedure, except that ONAP already recognizes the PNF and it already has an A&AI entry.

The following diagram depicts basic Re-registration situations:

(1) REHOMING - When a PNF is "rehomed" to a new NMS, or managing region it may go through re-registration. Rehoming can be a logical operation or a physical operation. The PNF may now have a new manager, an external manager. The PNF may also now have a new ONAP installation "home".

(2) DISCONNECTION/RECONNECTION - It is conceivable that a PNF may be powered off for a period of time and then is powered on again. A PNF only goes through base Plug and Play once. So a power cycle, or a disconnection/reconnection should not be considered a brand new Plug and Play. For ONAP purposes, this is tracked by the fact that the A&AI will already have a PNF entry. Note in this case, it is expected that the PNF is in the same physical location as before.

(3) PHYSICAL RELOCATION - For a vareity of reasons, the PNF may be moved to a new physical relocation. This would require the PNF to re-register when it returns to service. Similar to the disconnection/reconnection situation, the PNF would not go through "base" plug and play again, but would re-register. Because the PNF is in a new physical location the associated COMPLEX object that is associated with the PNF would need to beu pdated.

(4) NOMADIC ONT PNF (BBS USE CASE) - For the Broadband Service Use Case, a ONT PNF may also be moved to a different location, this is known as a Nomadic ONT. This use case is described in the wiki: BBS Broadband Service Use Case (Dublin).

The following flow diagram shows the steps for this use case

STEP 1 AUTHENTICATE CONNECTION - The PNF Authenticates its connection

PNP-6000 [AAF] AAF shall authenticate the PNF.

PNP-6010 [AAF] AAF shall be able to inboard the security keys for vendor certificate validation.

PNP-6020 [PNF] - When the PNF sets up a HTTP or HTTPS connection, it MUST provide a username and password to the DCAE VES Collector for HTTP Basic Authentication.

Note: HTTP Basic Authentication has 4 steps: Request, Authenticate, Authorization with Username/Password Credentials, and Authentication Status as per RFC7617 and RFC 2617

PNP-6021 [PNF] - If the PNF set up a TLS connection and mutual (two-way) authentication is being used, then the PNF MUST provide its own X.509v3 Certificate to the DCAE VES Collector for authentication.

Note: This allows TLS authentication by DCAE VES Collector..

Note: The PNF got its X.509 certificate through Enrollment with an operator certificate authority or a X.509 vendor certificate from the vendor factory CA.

Note: In R3 three authentication options are supported:

(1) HTTP with Username & Password and no TLS

(2) HTTP with Username & Password & TLS with two-way certificate authentication;

(3) HTTP with Username & Password & TLS with server-side certificate authentication.

PNP-6030 [DCAE] - DCAE authenticates the HTTP/TLS connection with a certificate. Certificate is X.509v3 issued by the Service Provider CA. Note: in Dublin, no HTTP username or password is needed.

PNP-6040 [DCAE] - VES Collector authenticates the PNF using the a username and password, Certificate, and standard PKI validation.

PNP-6050 [DCAE] - VES uses integrated CADI module to request the role and permissions for the PNF from AAF.

PNP-6060 [AAF] - AAF returns the role and permissions of the PNF to DCAE.

PNP-6070 [DCAE] - DCAE compares the event to the permissions and either accepts or rejects the event.

STEP 2 pnfREGISTRATION EVENT RECIEVED BY VES LISTENER

The pnfRegistration VES Event is published onto DMaaP.

PNP-6080 [DCAE/DMaaP/DR] - When the PNF sends the pnfRegistration Event to the DCAE VES Event Listener, DCAE shall publish the VES event received from the PRH onto the DMaaP/DR. The VES event should be using the pnfRegistration domain (Casablanca)

STEP 3 - pnfREGISTRATION ONTO DMaaP

PNP-6090 [DMaaP] – There shall be created a static pnfRegistration DmaaP Topic. Note: That a static as opposed to a dynamic DMaaP topic is needed because it is not known what PNF service will be needed when the PNF registers.

STEP 4 - pnfREGISTRATION EVENT RETRIEVED BY PRH

The pnfRegistration VES Event is retrieved by the PRH.

PNP-6100 [PRH] - PRH shall retrieve the pnfRegistration Event off of the DMaaP Bus. PRH shall periodically check the DMaaP bus for the VES event for the PRH.

PNP-6110 [PRH] – If the PRH is unable to read from DMaaP on the pnfRegistration domain it shall return an error.

PNP-6120 [DMaaP] In DMaaP, end-points need to be configured (topic creation). And PRH needs to have these end-points configured as well. PRH needs to pick up this configuration (cloudify module). And if they are not properly configured, PRH is unable to get the pnfRegistration message off of the DMaaP bus. What would happen is that the DMaaP end-point does not exist; thus an HTTP error response is returned to the PRH. It would require an operator to deduce that this problem has occurred.

PNP-6130 [PRH] - if the PRH is unable to read the pnfRegistration VES message. In this case the schema might be incorrect which results in a mismatch with what the PNF sends and what the PRH expects. Thus, the PRH is unable to process the VES event properly. The PRH shall logs this error.

STEP 5 – INVENTORY ENTRY QUERY - A&AI Query

PNP-6200 [PRH] – The PRH shall perform an A&AI inventory query when it receives the pnfRegistration VES event from the PNF. Note: it is expected that the PNF shall continue to send the VES event until it receives the service configuration request. After the Stage 2 Run-Time Service Instantiation occurs, there shall be an inactive A&AI entry for the PNF. This allows PRH to find that inactive A&AI entry and proceed with the rest of the Plug and Play procedure. PRH shall use the PNF-name (or correlation ID) to find the appropriate PNF A&AI entry.

PNP-6210 [A&AI] – A&AI shall return the entry for the PNF-id when queried. If not found A&AI shall return a negative acknowledgement. See the section on the A&AI PNF entry for more details about the fields that are relevant for the PNF.

PNP-6220 [PRH] - The PRH shall use the "sourcename" (pnf-ID) as the index to A&AI.

STEP 6 - UPDATE PNF ENTRY - Update PNF Entry in A&AI

PNP-6230 [PRH] – If PRH finds an A&AI entry for the PNF, it shall populate the A&AI PNF object fields with as many parameters received as possible, especially the OAM IP address for that entry with the OAM IP address provided in the pnfRegistration VES event sent from the PNF.
In case of additionalFields received within pnfRegistration event, those fields will not be used to update the PNF object parameters (they`re assumed to be domain-specific, while PRH operates of PNF generic parameters).

LOGICAL LINK OBJECT (BBS use-case specific aspect) - Create object in A&AI: "Logical-Link". Use Relation of the A&AI between the PNF instance and the Logical Link instance. This relation can be used by (BBS) microservice to identify the attachment point and cf. w/ storage in inventory to differentiate the case: registration or re-registration.

Instance: PNF ↔ A&AI: PNF (object) ↔ Relationship (objection) ↔ Logical Link (object)

RE-REGISTRATION CRITERIA: PRH does search in A&AI for the PNF. The Criteria to differentiate between initial registration & re-registration. q.v. PNF Re-Registration criteria so that ONAP Policy or other micro-service may use this mechanism to react in case of re-registration, by implementing changes specific to the domain, where that specific PNF operates.

(To be removed in Dublin) Macro flow building blocks. Migration of sub-W/F. (To be removed in Dublin)

Note: The PNF is the master of its IP address and would over-write the OAM IP address(es) in the PNF A&AI entry with the ones provided in the VES event (there is v4 and v6 addresses provided and stored in AAI for a PNF object).

PNP-6240 [DUBLIN][PRH] - The PRH shall enter the following information into the A&AI entry for the PNF extracting the corresponding information from the incoming pnfRegistration VES message. The PRH shall populate A&AI`s PNF object record with information coming in from the pnfRegistration VES event.

A&AI PNF ENTRY	BASED ON pnfREGISTRATION VES FIELD
serial-number	serialNumber
equip-vendor	vendorName
equip-model	modelNumber
equip-type	unitType
pnf-name	sourceName
pnf-id
ipaddress-v4-oam	oamV4IpAddress
ipaddress-v6-oam	oamV6IpAddress
software_versions	software_versions [1] { softwareVersion (from pnfRegistration) activeSw = "True" }

PNP-6250 [PRH] – If the PRH encounters a situation that there is a PNF entry in A&AI (without IP address), but the VES event itself does not have an PNF IP address it shall log the error.
Note: if the PNF does not send its IP address in the VES event this could be from a variety of reasons from a software error to a communication failure.

PNP-6260 [PRH] – (Error Case) If the PRH is unable to update the A&AI entry with the PNF information it shall log the error.

STEP 7 pnfUpdate EVENT = SERVICE UPDATE PROCEDURE - PRH sends pnfUpdate event

PNP-6270 [PRH] - PRH shall treat a PNF that is sending a pnfRegistration VES Event that already has an A&AI entry as a PNF that is re-registering. If the PRH has been identified as a PNF that is re-registering, PRH shall publish a pnfUpdate event on the DMaaP bus. This will call the Service Update Micro-Service (that is listening for pnfUpdate event). PRH shall pass the pnf-ID of the re-registering PNF so that the Service Update Micro-Service can identify the PNF. The Update Service Micro-service is listening for the pnfUpdate event.

Note: for the BBS Use Case, the additionalFields in the pnfRegistration message contains vital application information that needs to be preserved. This information should either be copied into a new field in the A&AI entry for the PNF, or it should be passed to the UpdateService Micro-service when PRH calls it. This information is copied in to the pnfUpdate event. This is an API change between PRH and consumer of the pnfUpdate event.

Note: The exact criteria, when to classify a pnfRegistration message as "initial registration" or "re-registration" are stored here: PNF Re-Registration criteria

PNP-6410 [DMaaP] – There shall be created a static pnfUpdate DMaaP Topic.

STEP 8 MICROSERVICE ANALYSIS - Microservice is invoked

PNP-6280 [UpdateServiceMSvc] - The purpose of the Update Service Micro-service is that it can identify an associated resource (PNF, VNF) of a service given the identifier, and process a reregistration procedure by updating the service associated with that resource. For example, suppose a PNF have been moved, the associated service needs to be updated. The Update Service Micro-service is listening for the pnfUpdate event.

STEP 9 POLICY USE - A policy framework is invoked

PNP-6290 [Policy] - The Update Service Micro-service issues a special EVENT which will be consumed by POLICY framework. A policy is invoked which performs the service update. The Policy Framework will find a specific policy to handle the request based on the PNF that is being updated. And it will call SO with a (new) Service Update API. The Policy has the responsibility of:

(1) determining that a PNF is reregistering

(2) identifying the PNF with its appropriate PNF-ID

(3) Finding the associated service(s) that is/are associated with the PNF and

(4) updating the service with the information passed from PRH.

(5) Publishing on the DMaaP bus the pnfUpdate Event which will cause SO to update the Service.

STEP 10 MODIFY SERVICE INSTANCE - Policy calls SO through a Modify Service API

PNP-6400 [Policy] – Policy invokes a Modify Service API towards SO. This has the effect to directly calling SO to perform the final steps of the service update associated with the PNF undergoing re-registration.

PNP-6420 [Policy]– (Error Case) If the PRH is unable to publish the pnfReady event onto the DMaaP topic it shall log the error.

STEP 11 QUERY A&AI - A&AI Query

PNP-6430 [SO] – SO shall query A&AI upon invocation of the Modify Service API (from Policy). SO queries A&AI for a valid PNF entry associated with the pnf-Id in the pnfReady event. SO subscribes to certain events, it performs a get off the DMaaP bus, and the pnfUpdate event and has a BPMN recipe associated with that pnfUpdate event. Note: In design-time a service designer creates a (set) of BPMN recipes for SO.

STEP 12 BPMN RECIPE - SO processes the Modify Service request (from Policy) Event

PNP-6440 [SO] -SO will process a BPMN Recipe for the Modify Service request from Policy. The purpose of this is to determine that the PNF is re-registering, and the invoke the appropriate actions to process a the modify service. This means that

(1) it will determine that this is an existing PNF that is reregistering. See the description of the reregistration use case to see why a reregistration occurs: (A) Rehoming (B) Disconnection/Reconnection (C) Physical Relocation (D) Nomadic PNF.

(2) Identify services that are currently depending on this service(s)

(3) Update the states for that PNF. This means that the associated resources of the associated service(s) of that PNF need to be updated (i.e. the PNF is now available). An analysis must be done that says that this PNF is no longer associated with the service (a policy rule with an algorithm assessment would be used to determine this).

(4) Identify the appropriate controller for that PNF.

Note: the Controller might be updated when the PNF re-registered.

STEP 13 RECONFIGURE PNF - PNF configuration is invoked

PNP-6450 [SO] – SO shall lookup through Controller-to-NF association, the appropriate Controller for the PNF. Then, SO shall invoke the PNF controller to request a PNF configuration exchange to happen.

Note: SO interacts with the PNF controller with the Understanding the the GENERIC-RESOURCE-APIs

STEP 14 PNF CONFIGURATION - Controller to PNF interaction

PNP-6500 [CONTROLLER] – The PNF Controller shall sends a Service Configuration to the PNF.

Note: For each associated API there is an associated Directed Graph (which playbook should be called).

PNP-6510 (CONTROLLER) – (Error Case) If there is an error encountered trying to send the Service Configuration command exchange to the PNF, the Controller shall log the fault.

PNP-6520 (CONTROLLER) – (Recovery Case) If there is an error encountered trying to send the Service Configuration command exchange to the PNF, the Controller shall attempt to retry.

PNP-6530 (CONTROLLER) – (Recovery Case) If there is not acknowledgment or response from the PNF while trying to perform a service configuration exchange, the controller shall wait for a time-out period before aborting this attempt. Note: This might be caused by a transient network issue.

PNP-6540 [PNF] - The PNF MUST support the Anible protocol for a Service Configuration message exchange between the PNF and PNF Controller (in ONAP).

Note: this exchange may be either Ansible, Chef, or NetConf depending on the PNF. Note: The PNF Controller may be VF-C, APP-C or SDN-C based on the PNF and PNF domain. Note: for R3 (Casablanca) only Ansible is supported.

PNP-6550 [PNF] - The PNF MUST support the NetConf protocol for a Service Configuration message exchange between the PNF and PNF Controller (in ONAP).

PNP-6560 [PNF] - When the PNF receives a Service configuration from ONAP, the PNF shall cease sending the pnfRegistration VES Event.

PNP-6570 [PNF] - The PNF MAY support the optional parameters for Service Configuration Parameters.

STEP 14A NOTIFICATION FROM PNF

A new notification event is sent from the PNF. This was first used by the BBS Use Case.

After the PNF has received a configuration update, the PNF sends a state change event, which informs ONAP is has successfully connected and serving customer-facing services (CFS).

This is an existing state change notification event (not a new event). An identifier is used within the event.

See the related Wiki pages: CPE Authentication Notification#CPEAuthenticationVESEvent

and CPE Authentication Notification (CPE Authentication Flow)

STEP 15 CONFIGURATION RESPONSE - Configuration Response

PNP-6580 [Controller] – The Controller shall return a response to SO after service configuration

STEP 16 A&AI UPDATE - A&AI Update

PNP-6590 [Controller] – The PNF Controller shall update the PNF A&AI Entry with updated configuration information.

PNF PLUG AND PLAY with LICENSING MANAGEMENT

WHAT: The Licensing Service exchange happens external to ONAP. This solution and message exchange is optional. An external Licensing management solution (e.g. vendor specific solution) will vary with the installed network elements of a vendor and service provider. For more information see the Licensing Management Use Case Page: xNF Licensing Management

WHY: Why is this relevant to Plug and play? Because during the Plug and Play process and registration & orchestration, the xNF can request and obtain licenses from a Licensing services.

WHEN: The interchange can happen any time after stage 3 in the Plug and Play flow.

HOW: The following diagram shows the Licensing Service exchange with the xNF:

The following table describes the steps involved in Licensing Managment.

Note: The interchange can happen any time after stage 3 in the Plug and Play flow

STEP

DESCRIPTION

x

REQUEST LICENSES - The PNF, for example 5G RAN PNF (DU) contacts the License Service to request licenses.

Note: This step is optional. This step is labeled "X" because it can be initiated any time after stage 3 in the Plug and Play flow.

y

RESPONSE WITH LICENSES - The License Service responds to the request for licenses to the originating PNF.

Note: This step is optional. This step is labeled "Y" because it can be initiated any time after stage 3 in the Plug and Play flow.

SUMMARY OF R3 CASABLANCA PLUG AND PLAY ENHANCEMENTS

The follow describes a summary of the Casablanca Enhancements for Plug and Play

TOPIC	DESCRIPTION
PNF Registration Handler (PRH) Improvements	pnfRegistration Domain - New VES Event domain for PNF registration with corresponding support in VES collector, DMaaP and PRH. PRH & AAF Integration – intra-ONAP security improvements Integration – Integration of Beijing software deliveries. DU Simulator Update – Support of new domain and updates to the DU simulator to match changes made in Casablanca.
SO Workflow enhancements	Integration - Introduction of dedicated 5G use case work-flow. While the PnP Work-flow was coded in Beijing it was not delivered in that time frame. PNF Controller Interaction – SO to the PNF controller interaction is developed in Casablanca (R3).
Service Configuration Improvement	PNF Controller – Service configuration improvements from PNF Controller to PNF after PNF registration to PRH. Five optional parameters are requested to be supported with the Casablanca release (R3).
Security Enhancements	Security Enhancements – Authentication, Certificates, User name & password and intra-ONAP security are used by the Plug and Play Use case.
Modeling enhancements	PNF Model – Modeling enhancements to support 5G PNF in ONAP with support for the new SoftwareVersionList parameter.
PNF Onboarding / Package	PNF Package - Defining PNF Onboarding Package. Extending framework to work with PNFs. Defining PNF Package framework. The PNF package artifacts will be delivered in Dublin such as the PM dictionary and FM Yaml dictionary. The definition of these are explored in Casablanca.

Plug and Play Overview Slides, Demos and Talks (R2-R9)

The following table has some of the Plug and Play overview slides, demos and talks

Description

File

PnP Overview Presentation & Talk

(from R7 Guilin Release)

PNFPlugnPlayR7GuiLin_09Sp242020v13.pdf