Skip to end of metadata
Go to start of metadata

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.

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 5G-PNFPlugandPlay-STAGE1-PNFDESCRIPTOR 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: pnfRegistration VES Event, HVol VES Event, and Fault 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, High Volume Measurements, and Fault events respectively.


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-OAMThis 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

ATTRIBUTEDESCRIPTION
PNFIPADDRESS-v4This is the IP address (IPv4) for the PNF itself. This is the IPv4 address that the PNF iself can be accessed at.
PNFIPADDRESS-v6This 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: 5G-PNFPlugandPlay-STAGE3-PNFREGISTRATIONVESEVENT

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 ENTRYBASED ON pnfREGISTRATION VES FIELD
serial-numberserialNumber
equip-vendorvendorName
equip-modelmodelNumber
equip-typeunitType
pnf-namesourceName
pnf-id(PNF-ID is NOT used)
ipaddress-v4-oamoamV4IpAddress
ipaddress-v6-oamoamV6IpAddress
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

vesEventListenerVersionstringYesVersion of the VES event listener API Spec that this event is compliant with (As "#" or "#.#" or "#.#.#" where # is a digit.
timeZoneOffsetstringNoOffset 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: 5G-PNFPlugandPlay-STAGE5-PNFACTIVATIONREQUIREMENTS

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.


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 ENTRYBASED ON pnfREGISTRATION VES FIELD
serial-numberserialNumber
equip-vendorvendorName
equip-modelmodelNumber
equip-typeunitType
pnf-namesourceName
pnf-id
ipaddress-v4-oamoamV4IpAddress
ipaddress-v6-oamoamV6IpAddress
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.


SUMMARY OF 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.


ROADMAP - PNP Plug and Play Evolution per Release

PnP Flow STEP

BEIJING (R2)

CASABLANCA (R3)

DUBLIN (R4) 5G - PNF Plug and Play (Casablanca carry-over items)

FRANKFURT (R6) PNF PLUG and PLAY in R6 Frankfurt

1 Resource Definition

Initial Development

No S/W Change; First Integration

This is now handled with the PNF Pre-onboarding/Onboarding use case:

5G - PNF Pre-Onboarding & Onboarding


2 Service Definition

Initial Development

SDC: new PNF model parameters



3 Type Modeling Artifacts

Initial Development

No S/W Change; First Integration



4 Resource Declaration

Initial Development

Alt Operator`s Inventory Management system supported



5 Create A&AI PNF Entry

Initial Development

Alt Operator`s Inventory Management system supported

PNF Schema change from PNFID (new) and redacting (PNF-name old)


13 ONAP Compliant S/W

Initial Development

No S/W Change; First Integration



15 Work Order to SO

Initial Development

SO: First R2 Integration

VID enhancements with new Presentation Layer

Controller to NF association architecture (development in El Alto)


16 Service Instantiation

Initial Development

SO: First R2 Integration



17 Homing OOF Sniro

Initial Development

SO: First R2 Integration



18 Resource RLF

Initial Development

SO: First R2 Integration



19 Check A&AI Entry

Initial Development

SO: First R2 Integration

A&AI Schema update using PNF-ID instead of PNF-name


20 Create A&AI Entry

Initial Development

SO: First R2 Integration



21 Subscribe VES Event

Initial Development

SO: First R2 Integration



22 RLF Thread Terminates to Wait State

Initial Development

SO: First R2 Integration



25 Authenticates PNF Connection

Initial Development

Enhanced ONAP Security developed. TLS, Certificate support, Authentication

Certificate Authentication for HTTPS/TLS


26, 28 PNF Registration VES Events

Initial Development

New pnfRegistration domain, Static DMaaP topics

A new EPIC the PNF Re-Registration Use Case is introduced (see this Wiki)

5G-PNFPlugandPlay-PNPREREGISTRATIONUSECASE


27 Inventory Query (A&AI)

Initial Development

New pnfRegistration domain

A&AI Schema update using PNF-ID instead of PNF-name


29 Inventory Query (A&AI)

Initial Development

New pnfRegistration domain



30 Update PNF Entry

Initial Development

New pnfRegistration domain



31 PNF Ready

Initial Development

New pnfRegistration domain



34 Update PNF WF

Initial Development

SO: First R2 Integration



35 Network Assignments

Initial Development

SDN-C: PNF PnP Development



36 Configure

Initial Development

SO: First R2 Integration



37 Service Configuration

Initial Development

PNF Controller development

Controller to NF association architecture (development in El Alto)

New API between SO to SDNC.

NETCONF support for Configuration (see the Netconf Use Case)

5G - Configuration with NETCONF


38 SO Updates w/ Assignments

Initial Development

No S/W Change; First Integration



39 Controller Replies

Initial Development

No S/W Change; First Integration



40 Service Running

Initial Development

No S/W Change; First Integration



41 Monitors Service

Initial Development

No S/W Change; First Integration



42 Inform OSS

Initial Development

No S/W Change; First Integration




The Dublin PnP Enhancements can e found on this wiki:

5G - PNF Plug and Play (Casablanca carry-over items)


DEVELOPMENT STATUS


Development Status

Project

PTL

JIRA

Description

DCAE

Lusheng Ji

DCAEGEN2-390 - Getting issue details... STATUS

PNF PnP - PNF Registration Handler

DCAEGEN2-564 - Getting issue details... STATUS

Support VES Version 6.0 specification and new Registration domain (new Casablanca scope)

DMaaP


Ram Koya


DMAAP-548 - Getting issue details... STATUS

Static set-up of DMaaP topics - PNF PnP (EPIC)

TBDPNF PnP topics: "REGISTRATION" & "PNF_READY" (Story)

VNFRQTS

Steven Wright

VNFRQTS-289 - Getting issue details... STATUS

TBD:
(It is required, that the PNFs, once started, issue Registration requests, compatible with VES 7.0 schema for domain "Registation". Addt`l: Events shall be issues on periodic basis, as long as one of the following occur: a pre-defined timer expires, or a PNF configuration is received and properly applied)

VID

VID-203 - Getting issue details... STATUS

VID Support for PnP Plug and Play, with vCPE Flow.
 VIDOfir Sonsino

VID-289 - Getting issue details... STATUS

 VID Support for Service Instantiation work
 VID

VID-290 - Getting issue details... STATUS

 VID Support for Multi-PNF support.
A&AI

AAI-1489 - Getting issue details... STATUS

R3 PNF Schema updates in A&AI for PnP Use Case
SDC
SDC changes for PNF Model
SDN-CDan Timoney
PNF Controller Support
Security

SECCOM-9 - Getting issue details... STATUS

Security Enhancements that are used by PNF PnP UC.
PRH (Dublin)Damian Nowak

DCAEGEN2-691 - Getting issue details... STATUS

DUBLIN: PRH will fill in A&AI entry from PNF from pnfRegistration VES event


TESTING - PNF PLUG AND PLAY INTEGRATION & TESTING

  1. WHO IS TESTING - what company, team, and people will be doing the testing & responsibilities for testing.
  2. TEST ENVIRONMENT - which does the lab & test environment.
  3. RESOURCES NEEDED - what resources are needed.
  4. WHO IS CONTRIBUTING RESOURCES - what resources will be provided and by whom/what company.
  5. NETWORK CONNECTIVITY - How will a PNF make connectivity to ONAP DCAE VES Event Listener.


DEPLOYMENT DIAGRAM

TEST CASES 

PnP Flow STEP

TEST CASE SECTION

TEST STATUS

1 Resource Definition

PnP1 Resource Definition

NOT TESTED

2 Service Definition

PnP2 Service Definition

NOT TESTED

3 Type Modeling Artifacts

PnP3 Type Modeling Artifacts

NOT TESTED

4 Resource Declaration

PnP4 Resource Declaration

NOT TESTED

5 Create A&AI PNF Entry

PnP5 Create A&AI PNF Entry

NOT TESTED

13 ONAP Compliant S/W

PnP13 ONAP Compliant S/W

NOT TESTED

15 Work Order to SO

PnP15 Work Order to SO

NOT TESTED

16 Service Instantiation

PnP16 Service Instantiation

NOT TESTED

17 Homing OOF Sniro

PnP17 Homing OOF Sniro

NOT TESTED

18 Resource RLF

PnP18 Resource RLF

NOT TESTED

19 Check A&AI Entry

PnP19 Check A&AI Entry

NOT TESTED

20 Create A&AI Entry

PnP20 Create A&AI Entry

NOT TESTED

21 Subscribe VES Event

PnP21 Subscribe VES Event

NOT TESTED

22 RLF Thread Terminates

PnP22 RLF Thread Terminates

NOT TESTED

25 Authenticates PNF Connection

PnP25 Authenticate PNF Connection

NOT TESTED

26 PNF Registration VES Events

PnP26 PNF Registration VES Events

NOT TESTED

27 Inventory Query

PnP27 Inventory Query

NOT TESTED

29 Inventory Query

PnP29 Inventory Query

NOT TESTED

30 Update PNF Entry

PnP30 Update PNF Entry

NOT TESTED

31 PNF Ready

PnP31 PNF Ready

NOT TESTED

34 Update PNF WF

PnP34 Update PNF WF

NOT TESTED

35 Network Assignments

PnP35 Network Assignments

NOT TESTED

36 Configure

PnP36 Configure

NOT TESTED

37 Service Configuration

PnP37 Service Configuration

NOT TESTED

38 SO Updates w/ Assginments

PnP38 SO Updates w/ Assginments

NOT TESTED

39 Controller Replies

PnP39 Controller Replies

NOT TESTED

40 Service Running

PnP40 Service Running

NOT TESTED

41 Monitors Service

PnP41 Monitors Service

NOT TESTED

42 Inform OSS

PnP42 Inform OSS

NOT TESTED


APPENDIX - A VNF TO PNF COMPARISON


TOPIC

VNF

PNF

Concept

Application fulfills the role of a network function.

It is a network element, a physical entity, which can implement the role of a network function.

Physical Characteristic

Application without dedicated hardware; Virtualized applications require specific capabilities; Run on different vendor servers. SRIOV, Inter-PNP-DPDK. Hardware capabilities.

Has an actual physical asset that is deployed and associated directly with the PNF.

On-boarding

To onboard a VNF is to “bring it into ONAP” i.e. the VNF images, component VNF-C provide descriptors of these NFs. Deployment model, # components, functions. Configuration parameters. VNF is not tied or optimized for a specific hardware, only requiring perhaps some capability to be supported.

For PNF provide the descriptors. Only provide the meta-data. PNF S/W specifically optimized to run on dedicated hardware. (Now) Not the software image. (Future) ONAP will provide the software image repository.

Plug and Play

The model triggers the orchestration.

(See this slide package for PNF Plug and Play) at the end of PnP the PNF can provide service.

Characteristics

5G CU could be a VNF since there is no need to have an association to a physical environment.

5G DU must be PNF. PNFs are Elements which may need to interact with the physical environment. PNF is “High-Touch” technology. E.g. Emit radio waves in a geographical area.

Configurability

&

Deployment

Easily adaptable to functions that you expect. E.g. Packet gateway to reconfigure as different NFs. Services easily create instances reconfigures including deployments (for different applications). Use a different instance of the VNF to provide a new service. For a VNF you can easily “delete” and “create” a new VNF to perform a new function. Configured dynamically.

PNF has a “fixed” set of capabilities but can’t easily reconfigure it. One PNF in multiple services. Different capabilities exposed by the PNF. Reuse the same PNF with different services configuration. For a PNF you would not “destroy” a PNF but rather re-configure it. Can be configured dynamically.

ONAP Interaction

ONAP is started with VNF. VNF is “deployed” on-demand. Control from the ONAP perspective when a deployment of a VNF happens.

DCAE – same

Configure – Chef, Ansible

PNF do not “deploy” application. Do not use multi-VIM. Only “configure” the application, the PNF is deployed. A technician goes to site and “deploys” a PNF.

DCAE – same

Configure –Implementation of PNF client. Communication protocol, Client

Design Time Modeling

Model VNF. Templates. Onboarded before. In Run-time. Make sure properly identify specific PNF instance already deployed versus a dynamically created instance. VNF instances could be created & instantiated dynamically. SDC may assumed instantiation of network function.

PNF cannot be instantiated, a PNF is only instantiated when it “powers up” and connects to ONAP. Service Orchestration. PNF is instantiated by nature of a PNF installation & commission procedure.

Service Orchestration

VNF cloud, #VM resources consumption, define components implement different functions. Where & What will be deployed.

Physical location, pre-provisioned capabilities, performance monitoring. Components installed. RUs for specific functions.

Resources

VNF dynamically assigned resources.

PNF statically associated (hardware) resources.

Capacity

VNF Capacity can be dynamically changed

PNF is static (number of cells supported)

APPENDIX B - References & Associated Documentation

The following are references and associated documentation related to Plug and Play or PNF Discovery

DocumentDescriptionSource
Zero TouchIETF definition of Zero Touch Deploymenthttps://tools.ietf.org/html/draft-ietf-netconf-zerotouch-29
Call HomeZTP Call Home RFC (IETF RFC8071)https://tools.ietf.org/html/rfc8071
3GPP TS32-501Defines PnP Use Case (U/C)http://www.3gpp.org/ftp//Specs/archive/32_series/32.501/32501-f00.zip
3GPP TS32-508Defines PnP Procedurehttp://www.3gpp.org/ftp//Specs/archive/32_series/32.508/32508-f00.zip
3GPP TS32-509Defines PnP Formatshttp://www.3gpp.org/ftp//Specs/archive/32_series/32.509/32509-f00.zip

ETSI Zero Touch Network Service Managementhttps://www.etsi.org/technologies/zero-touch-network-service-management

ONAP WIKI PNF ModelExample: PNF in AAI



  • No labels

19 Comments

  1. HI,

    a couple of questions to clarify:

    1) in the roadmap table above I see for Casablanca release:

    SDC: new PNF model parameters.

    Is it an extension for Casablanca respect to Beijing release ? I do not see any JIRA ticket associated in the development status table ?

    2) in the roadmap table above I see for casablanca release:

    Enhanced ONAP Security developed. TLS, Certificate support, Authentication

    is it confirmed ? is it an additional JIRA ticket to be added in the development status ?

    3) in the list of contents for R3 I see:

    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.

    Is it a Casablanca content ? which ONAP components are impacted ?

    BR
    Michela

  2. Michela,

     1) For Roadmap item for new modeling parameters, see the Modeling Slides Section entitled ROADMAP.

    2) You can contact Linda Horn, there is a nice Security Roadmap slideware that has been developed by the Security Subcommittee - these security functions are used by the PnP UC.

    3) The R3/Casa SDC content is the new SWVersionList parameter in the TOSCA model in the PNF Model. For the PNF Onboarding Package (CSAR Package) we have been discussing these for months, can you can see the modeling slides. https://wiki.onap.org/display/DW/Casablanca 

    Best regards,

    -Ben

  3. HI Ben,

    Thanks for your inputs but I think there are some misunderstanding.

    The presence of JIRA tickets in the development status section above, can help to understand contents/prerequisites to be developped to fulfill this UC.This was my understanding of the scope of this section.

    If I see the development  status section above, I do not see any reference to SDC project or SDNC for security aspects in relation to point 1 and 2 that are documents in other sections above.

    It could be good add JiRA tickets in the development status sections.



    About point 3, I was raising that according to slide 19 in modeling sldies you refer (https://wiki.onap.org/download/attachments/35523132/NFModeling-SDCR3-30Jul2018v2.pdf?version=1&modificationDate=1532984605000&api=v2 ) stating in Casablanca release, PNF has no onboarding package. PNF will be modelled only by the ONAP UI screen.

    I´ve just noticed an additional information above clarifying in Casablanca PNF onboarding package is only defined but it will not delivered before Dublin release. 


    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.


  4. I would like to clarify the "Manager IP address".   I think this is the A&AI field updated in Step 30, can you confirm?  This is in fact the IP address that ONAP controller (SDNC) should use for the NETCONF interface with the PNF.  In which case I do not understand why oamV4IpAddress is listed as not required in the VES event. Is it because only oamV4IpAddress OR oamV6IpAddress should be required?  So the IP Address is required but not each specific field, just one of the two?

    1. Benjamin Cheung Could you help clarify IP addresses?  VES event has

      oamV4IpAddress

      string

      No

      IPv4 m-plane IP address to be used by the manager to contact the PNF. 

      Maps to AAI ipaddress-v4-oam.

      which sounds like this would be the PNF IP address that the ONAP Controller should talk to.   Yet I see A&AI now has PNFIPADDRESS-v4 - I don't see anything in VES event for PNF Registration that will populate this.  

      1. Rebecca,

           There is a discussion how to populate this

        -Ben

      2. Rebecca,

        At this moment, the pnf-registration-handler populates the AAI PNF fields: ipaddress-v4-oam and ipaddress-v6-oam, depending on which specific IP address(es) is(are) reported by the PNF in a registration message. A PNF might have a bunch of IP-Addresses dedicated to different operational domains (OAM, Transport, Control,...) - I think, it makes sense to keep the OAM related IP address of a PNF in a dedicated AAI field. If we`re going to populate the PNFIPADDRESS - which of those different possible addresses shall be used (addresses dedicated to different operational domains)?

        1. Hi Damian, so is it correct that the PNFIFADDRESS entries added to A&AI in Casablanca (see bottom of Stage 2 in wiki content above) are not to be used?   ONAP components that need to communicate with a PNF will use ipaddress-v4/v6-oam field (and this is the field that PRH populates).  Maybe we need Benjamin Cheung to clarify the intention of the new IP fields added?  

  5. Suggestion for available "software versions" list in AAI pnf object: https://lists.onap.org/g/onap-discuss/message/11892


    1. How are the available "software versions" in AAI pnf object populated?   I see that PNF registration VES has the "active" version,

      softwareVersion

      string

      No

      TS 32.692 swName = active SW running on the unit; e.g. 5gDUv18.05.201.

      but I don't see a way to have any inactive versions populated.  Benjamin Cheung do you know?

      1. This was a use case we were requested in Casablanca: Casablanca Release Requirements (see 5G/PNF Software Version Reporting).

        You can see from the Software Upgrade Use Case that the desire is that this would be populated in STEP 16: 5G - PNF Software Update ... but in face-to-face meetings this part has been pushed to R4 Dublin.

        So to populate this you would have to manually do it to say integrate/test with it. For example for use with the 5G - PNF Software Upgrade Use Case. There is a A&AI GUI that you can set values

        Hope this helps. -Ben

  6. hello, Benjamin Cheung

    In step 30, "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."

    Question: is it only the IP address which has been populated in Casablanca? What about other received parameters, e.g. software version, MAC address, etc. ? Just try to understand what is implementation. Do you have the Gerrit link of the implementation? 

    By the way, step 28 is missing in the flow picture.

  7. Hi Benjamin Cheung,

    regarding the new PNF reregistration flow, in BBS the service update needs to be triggered only if the PNF, an ONT/CPE, reattaches to a different Access PNF (CPE relocation). One way to check that the CPE has moved is by comparing the content of the 'additionalFields' in the registration VES event message with the one previously stored in AAI (in the relevant service instance). 'additionalFields' contains information about the PON port to which the CPE attaches. If PON port is different, it means that the CPE has moved. Comparing the PON port in additionalFields with the port stored in AAI is BBS specific, so it may make sense to do such analysis in a BBS microservice.

    What about decoupling step 7 and step 8? e.g. PRH identifies that the VES event is a PNF reregistration and publishes a PNF reregistration message in DMaaP with the original VES event as payload, BBS microservice consumes that message and analyzes whether the CPE has moved, if so, the procedure continues with BBS microservice publishing a pnfUpdate message. In this way, we can avoid going all the way up to SO to do the PON port check. 


  8. Hello, Benjamin Cheung Keong Lim Ulas Kozat

    I have 2 questions for PnP for PNF software version,

    1. SDC internal datamodule, there is 'software_version with list type'? why is it list type? is any ONAP compoent to use it? if any, how to use it?
    2. in PnP and A&AI, I see (in dublin) the REGISTRATION VES with below field.

    softwareVersion

    string

    No

    TS 32.692 swName = active SW running on the unit; e.g. 5gDUv18.05.201


    But, in A&AI, with latest aai_schema_v16 , there are few place with software-version for pnf, could you help to colaborate a little more about below 3 elements? As my understanding, REG VEW shall update sw-version in pnf of A&AI. how about 'software-version' and 'software-versions'? 

    -----------------------------------------------------------------------------------------------------------------------------------------------------------

     7194  <xs:element name="software-version">

    7195     <xs:complexType>
    7196       <xs:annotation>
    7197         <xs:appinfo>
    7198           <annox:annotate target="class">@org.onap.aai.annotations.Metadata(description="Software Version",indexedProps="softwareVersionId,isActiveSwVer",dependentOn="pnf",container="pnf",requiredProps="software-version-id,is-active-sw-ver",uriTemplate="/pnf/software-version/{software-version-id}")</annox:annotate>
    7199         </xs:appinfo>
    7200       </xs:annotation>
    7201       <xs:sequence>
    7202         <xs:element name="software-version-id" type="xs:string" minOccurs="0">
    7203           <xs:annotation>
    7204             <xs:appinfo>
    7205               <annox:annotate target="field">@org.onap.aai.annotations.Metadata(isKey=true,description="Identifier of the software version")</annox:annotate>
    7206             </xs:appinfo>
    7207           </xs:annotation>
    7208         </xs:element>
    7209         <xs:element name="is-active-sw-ver" type="xs:boolean" minOccurs="0">
    7210           <xs:annotation>
    7211             <xs:appinfo>
    7212               <annox:annotate target="field">@org.onap.aai.annotations.Metadata(defaultValue="false",description="used to indicate whether or not this software-version is the active one (activeSw = true)")</annox:annotate>
    7213             </xs:appinfo>
    7214           </xs:annotation>
    7215         </xs:element>
    7216       </xs:sequence>
    7217     </xs:complexType>
    7218   </xs:element>
    7219   <xs:element name="software-versions">
    7220     <xs:complexType>
    7221       <xs:annotation>
    7222         <xs:appinfo>
    7223           <annox:annotate target="class">@org.onap.aai.annotations.Metadata(description="Collection of software versions.")</annox:annotate>
    7224         </xs:appinfo>
    7225       </xs:annotation>
    7226       <xs:sequence>
    7227         <xs:element ref="tns:software-version" minOccurs="0" maxOccurs="5000"/>
    7228       </xs:sequence>
    7229     </xs:complexType>
    7230   </xs:element>

    .....

      <xs:element name="pnf">
    ....
    7385         <xs:element name="sw-version" type="xs:string" minOccurs="0">
    7386           <xs:annotation>
    7387             <xs:appinfo>
    7388               <annox:annotate target="field">@org.onap.aai.annotations.Metadata(description="sw-version is the version of SW for the hosted application on the PNF.")</annox:annotate>
    7389             </xs:appinfo>
    7390           </xs:annotation>
    7391         </xs:element>
    ...
    7525         <xs:element ref="tns:software-versions" minOccurs="0"/>
    7526         <xs:element ref="tns:relationship-list" minOccurs="0"/>
    7527         <xs:element ref="tns:p-interfaces" minOccurs="0"/>
    7528         <xs:element ref="tns:lag-interfaces" minOccurs="0"/>
    7529         <xs:element ref="tns:vrfs" minOccurs="0"/>
    7530       </xs:sequence>
    7531     </xs:complexType>
    7532   </xs:element>

    ....

    -----------------------------------------------------------------------------------------------------------------------------------------------------------


    BestRegards

    Fei

    1. Fei Zhang on lines 7195 and 7219 the appearance of "software-versions" and "software-version" is the definition of the schema elements. In AAI, there is always a container which is a list type and there is an individual type as well.

      On line 7385, the pnf has a single software-version attribute which represents the "active software" configured in the pnf.

      On line 7525, the pnf has a sub-object for the list of software-versions that are available to be used, i.e. they were uploaded to the pnf and they can be chosen to be the "active software".


      1. Thanks a lot for your quick response, Keong Lim .  For futher understanding of software version in A&AI, could you help clarify the following questions?

        1. on line 7385, sw-version attibute in pnf is only updagted by REG VES in Dublin, right? Or can be updated by other component like SO/SDC?
        2. how about line 7525 'software-versions' or line 7194 'software-version'? which component shall update it? Is it from initial internal SDC package or somelse? Is it updated by PRH in Dubin or shall be supported in the future?
        3. you can see both 7385 'sw-version' and 7194 'software-version' is for pnf in schema? why do we need 2 different elements for same thing?
        4. are both 7385 'sw-version' and 7194 'software-version' applicable for vnf either?

        Benjamin Cheung or Ulas Kozat , your clairification is also welcomed.

        1. In answer to your questions:


          1. I don't know which ONAP components is considered the "owner" of that sw-version attribute. Any client of AAI can attempt to update it.
          2. Same as above. There are no specific "owners". You may want to announce your intentions on the onap-discuss or search through code repo to find who uses it.
          3. Line 7194 is the definition of the class "software-version". Line 7385 is a string attribute with name "sw-version". They are actually unrelated, except for the name which is similar. The value contained may be derived from the objects of class "software-version" but that is related to the client behaviour, not to AAI behaviour.
          4. As far as I know, these are for pnf software versions only. The generic-vnf has different attributes and maybe the users of the generic-vnf object have their own way to identify software versions, if that is relevant.


          Keong


          1. thanks agian, Keong Lim .

            Benjamin Cheung Ulas Kozat , do you have some details of client behaviour for my above questions in your PnP and 5G-PNF SW upgrade scenario?

  9. Hi, have anyone tried PNF Plug and play with any Vendor or Physical switch? or its just Emulated PNFs and one have to modify according to the needs?