The PNF PnP flow is method, which allows to register within ONAP/AAI a PNF resource instance. This PNF resource instance is correlated with an existing service instance.
Once a PNF resource is registered, the infrastructure service instantiation flows are able to continue the service instantiation, by calling controllers, which in turn configure the PNF instance.
While this page was created in the R2 "Beijing" release, it is the "Base" Plug and Play page and applies for R2 through R9 (Honolulu).
Table of Contents |
---|
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 – Anyother 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 for Plug and Play: pnfRegistration VES Event. These are onboarded via the SDC Design Studio. Note: these VES Events are emitted from the PNF to support PNF Plug and Play. A PNF MUST support the pnfRegistration VES event which is required to integrate with ONAP’s PNF Plug and Play capabilities.
STAGE 1 - PNF MODEL
The following describes the PNF model in SDC in the Beijing (R2) release. The following parameter are already supported in Beijing (R2) but because the PnP Use Case was not delivered, these will see their first operational use in the Casablanca (R3) release.
MODEL PARAMETER | DESCRIPTION |
pnfId* | Identifier of this Pnf information element. CORRELATIONID = PNF-NAME (A&AI) |
pnfType (template)* | Type of Resource. NEW type: PNF (pre-defined in SDC) |
Category* | PNF category, e.g. infrastructure |
Vendor (template)* | Identifies the vendor of the PNF. |
Name* | Provides the human readable name of the PNF. |
vendorrelease * | Vendor release |
vendormodelNumber* | PNF Model value (link to A&AI) |
functionDescription* | Describes the PNF function |
PNP-1400 [SDC] – SOFTWARE VERSION - SDC shall support the SWversionList in the NF Model. This parameter represents a list of Expected Software to be supported by the NF. This is an optional parameter. As a LIST, this parameter shall support a structured list of software versions (as strings).
Note: The actual software running on a PNF instance is kept in an A&AI parameter for the PNF instance. This “detected Software” can be used in conjunction with this modeling parameter.
Note: This parameter may be used for a wide variety of purposes from network analysis, network planning, modeling analysis, trouble shooting, auditing, correlation, modeling informational, error checking, system evolution, network evolution, life cycle management, regional planning, regional analysis, service provider specific analytics, network management, and PNF feature & functional correlation.
STAGE 1 - PNF DESCRIPTOR
The following table is the PNF descriptor
Attribute | Qualifier | Cardinality | Content | Description |
pnfdId | M | 1 | Identifier | Identifier of this Pnfd information element. It uniquely identifies the PNFD. |
functionDescription | M | 1 | String | Describes the PNF function |
provider | M | 1 | String | Identifies the provider of the PNFD. |
version | M | 1 | Version | Identifies the version of the PNFD. |
pnfdInvariantId | M | 1 | Identifier | Identifies a PNFD in a version independent manner. This attribute is invariant across versions of PNFD. |
name | M | 1 | String | Provides the human readable name of the PNFD. |
pnfExtCp | M | 1 … N | PnfExtCpd | Specifies the characteristics of one or more connection points where to connect the PNF to a VL. See clause 6.6.4. |
security | M | 0..1 | SecurityParameters | Provides a signature to prevent tampering. |
geographicalLocationInfo | M | 0..1 | Not specified | It provides information about the geographical location (e.g. geographic coordinates or address of the building, etc.) of the PNF. The cardinality 0 is used when the location is unknown. |
RUN-TIME PNP FLOWS AND REQUIREMENTS
The following sections describe the flows and requirements for the major phases in Plug and Play during run time.
STAGE 2 RUN-TIME SERVICE INSTANTIATION
In the Service instantiation phase of Plug and Play, three main things happen:
PNF Infrastructure Service Declaration – A work flow is invoked by an operator which will create a request for a PNF to be instantiated. This work flow is invoked from a OSS or VID interface.
First part of PNF instantiation – This service instantiation work-flow is received and handled by the service orchestration (SO) component in ONAP.
DCAE & AAI Entry with PNF-name (e.g. MAC address) – The result of this stage of Plug and Play is that an inactive A&AI entry is created so that ONAP will be prepared when the PNF tries to register. It might also be the case that the A&AI entry was previously created from a different interface, in this case the A&A entry will already be in place.
STAGE 2 – SERVICE INSTANTIATION REQUIREMENTS
STEP 15 – WORK ORDER INITIATED - In this step, a Work Order is initiated from an operator using the VID. The Plug and Play flow requires an A&AI entry to be created so that when the PNF registers ONAP will recognize the unit. This requires that an operator be aware of the elements that need to be deployed into their network.
PNP-2000 [OSS/BSS/VID] – WORK ORDER – An operator processes a work order. The PNF service instantiation will be a result of processing the work order. Note: External ONAP APIs may be used to interface with the OSS/BSS.
STEP 16 – SERVICE INSTANTIATION - In this step, a service instantiation is issued from VID to SO. The operator invokes a service instantiation so that SO can take the necessary steps to create or verify that there is an A&AI entry for the PNF which satisfied the work order.
PNP-2100 [VID] – SERVICE INSTANTIATION - VID shall support the ability to invoke a Service Instantiation request to SO for the creation of a PNF. The operator uses VID to instantiate a Service. The Correlation ID = PNF Name = 3 characters of Vendor + PNF Serial Number are provided in the Service Instantiation request to SO.
Note: Other OSS/BSS systems may be used to instantiate a service.
Note: A service provider may choose to use a different identifier than the [Vendor] + [Serial Number], the corresponding PNF would need to also be configured to emit a matching identifier from the pnfRegistration Event.
PNP-2110 [SO] – SO shall decompose the 5G DU PNF Service. Based on the DU resource type, SO shall determine the appropriate SDC PNF Model for the service instantiation. Note: it is also possible that the Plug and Play (PnP) service instantiation may be part of a larger work-flow (e.g. VCPE work flow), during that larger work flow the PnP flow may happen. This would be handled by the service work-flow designer. Note: it is expected that the SO API shall be used for the service instantiation no matter the source (OSS/BSS or VID).
PNP-2120 [SO] – If SO is unable to perform the service instantiation it shall return an error.
STEP 17 – HOMING CHECK - A homing operation can be performed, though in Casablanca this is not used. The homing function by OOF can perform network deployment and network optimization functions. Note: There are optimization use cases that are being invested for development in Casablanca.
PNP-2200 [SO] – SO shall invoke OOF for a homing check.
PNP-2210 [OOF] – OOF shall return an acknowledgement. For the Plug and Play procedure in Casablanca the PNF OOF check has no impact.
STEP 18 – RESOURCE LEVEL FLOW - Resource Level Flow is invoked. The resource level flow is handled by SO to create the A&AI entry for the PNF if necessary.
PNP-2300 [SO] – SO shall invoke a Resource Level flow for the PNF instantiation.
PNP-2310 [SO] – SO checks A&AI for an entry that matches the PNF-Name.
STEP 19 – PNF A&AI ENTRY FOUND - ALT Flow: A&AI Entry found
PNP-2400 [SO] – FUTURE If SO determines that an A&AI entry already exists for the PNF when it performs the query, then SO shall associate the PNF with the service instance and it shall then proceed to step 21.
PNP-2405 [SO] - If SO determines that an A&AI entry already exists for the PNF when it performs the query, and SO will exit out.
PNP-2410 [A&AI] – A&AI shall return a PNF query check using the PNF-Name. If the entry is not found a negative acknowledgement shall be returned.
PNP-2415 FUTURE [SO] - STEP 19A/B (Active/Inactive) A&AI PNF Entry Found
STEP 20 – PNF A&AI ENTRY MISSING - ALT Flow: A&AI Entry missing
PNP-2500 [SO] – SO shall check for the A&AI entry, and SO shall identify if that A&AI entry does not exist, then SO shall proceed to step 21.
PNP-2510 [A&AI] – A&AI shall support responding to a query for an entry for the PNF.
STEP 21 – SUBSCRIBE - Subscribes to VES Event
PNP-2600 [SO] – SO shall subscribe to the DMaaP pnfReady topic. Note: The pnfReady event is published by the PRH after the PNF successfully registers with ONAP (Step 31)
PNP-2610 [SO] – If there is a fault subscribing to the pnfReady topic (DMaaP) the fault shall be logged.
STEP 22 – RESOURCE LEVEL FLOW (RLF) TERMINATES - The Resource Level Flow (RLF) waits
PNP-2700 [SO] – The SO RLF shall terminate and goes into a “wait state” awaiting rehydration after the PRH receives the PNF registration message from the PNF. Note: SO is pending a pnfReady event to be published onto the DMaaP Bus from the PRH to rehydrate this thread.
PNP-2710 [SO] – After SO terminates the RLF, SO shall wait for 2 weeks for the PNF to perform a registration. After 2 weeks passes the Work-flow shall terminate and generate an error which shall be logged and displayed on the OSS.
PNP-2720 [SO] – If there is a fault terminating the RLF, the fault shall be logged.
STAGE 2 - PNF A&AI ENTRY USED BY PNP
ACTIVE & AVAILABLE INVENTORY (A&AI) PNF RECORD | |
PNF-NAME | “pnf-name”. The pnf-name is the Key in AAI. The pnf-id is the first three letters of the Vendor and the PNF serial number. This is a unique identifier for the PNF instance. It is also referred to as the Correlation ID. It can serve as a unique key for the PNF. Note: The MAC address and serial number are not unique across vendors; but are unique per vendor, hence the Vendor name is added to insure uniqueness. Note: in R4/R6 there was a request to use PNF-id instead of PNF-name but that proposal has been rejected. |
EQUIP-TYPE | The equip-type parameter gives the type of the PNF. |
EQUIP-VENDOR | The equip-vendor is an optional parameter which indicates the vendor for the PNF. For example, Nokia or Ericsson. |
EQUIP-MODEL | The equip-model is an optional parameter which indicates the model of the PNF. |
PNF-ID | This is the UUID which is a service provider assigned number from for example a network planner.. |
IPADDRESS V4-OAM | This is the Manager IP Address in IPv4 for the PNF. For a DU, this might be a CU IP address; (FYI/ ipaddress-v4-loopback-0). |
IPADDRESS v6-OAM | This is the Manager IP Address in IPv6 for the PNF. For a DU, this might be a CU IP address; |
MAC ADDRESS | This is the MAC address of the PNF. This is a service field. |
SERIAL NUMBER | This is the serial number of the PNF. This is a service field. |
PROXY IP ADDRESS | This field contains the proxy IP address for the PNF. |
ACTIVE & AVAILABLE INVENTORY (A&AI) PNF RECORD ADDITIONS FOR R3 CASABLANCA
ATTRIBUTE | DESCRIPTION |
---|---|
PNFIPADDRESS-v4 | This is the IP address (IPv4) for the PNF itself. This is the IPv4 address that the PNF iself can be accessed at. |
PNFIPADDRESS-v6 | This is the IP address (IPv6) for the PNF itself. This is the IPv4 address that the PNF iself can be accessed at. |
SOFTWARE_VERSIONS | This is an Array of software versions that currently installed on the PNF. PNFs can have multiple partitions, and this array represents a list of all of the software versions that are currently installed on the PNF.. The Active SW is a boolean (True/False) that indicates that this specific version if the one that is "active" (if True). software_versions [1…x] (Array) { software_version (String) activeSw (Boolean) } |
STAGE 3 - PNP BOOTSTRAPPING
Assumption: Physical management connectivity between ONAP and the PNF is assumed to be setup prior to PNF Plug and Play, e.g. dealing with firewalls. etc.
In this stage, the PNF Boot-straps. This is comprised of two steps
PNF Powers up and Boot-straps – Vendor specific steps are performed where the PNF is physically installed, powers up, and performs boot-strapping functions.
PNF performs a “Plug and Play” procedure – The PNF performs vendor specific steps which will allow the PNF to reach a state such that it is ready to contact ONAP.
It is a requirement from ONAP on the equipment (PNF) vendors that the PNF shall have software capable of performing the PNF Registration. This shall be referred to as ONAP-aware software.
See the section on the ONAP needs to be developed by the PNF Vendors section of this document for more details, entitled “Vendor PNF PNP Deliverables”
Vendor PNF requirements in DOC project (the Appendix of “Vendor PNF PnP Deliverables)
PNP-3010 [PNF] - The PNF MUST support & accept the provisioning of an ONAP contact IP address (in IPv4 or IPv6 format).
Note: It is expected that an external EMS would configure & provision the ONAP contact IP address to the PNF (in either IPv4 or IPv6 format). For the PNF Plug and Play Use Case, this IP address is the service provider's "point of entry" to the DCAE VES Listener.
Note: different service provider's network architecture may also require special setup to allow an external PNF to contact the ONAP installation. For example, in the AT&T network, a maintenance tunnel is used to access ONAP.
PNP-3020 [PNF] - The PNF MUST have "ONAP Aware" software which is capable of performing PNF PnP registration with ONAP. The "ONAP Aware" software is capable of performing the PNF PnP Registration with ONAP MUST either be loaded separately or integrated into the PNF software upon physical delivery and installation of the PNF.
Note: It is up to the specific vendor to design the software management functions.
PNF-3030 [PNF] - The PNF MUST support the provisioning of security and authentication parameters (HTTP username and password) in order to be able to authenticate with DCAE (in ONAP).
Note: In R3, a username and password are used with the DCAE VES Event Listener which are used for HTTP Basic Authentication.
Note: The configuration management and provisioning software are specific to a vendor architecture.
STAGE 4 RUN-TIME PNF REGISTRATION
In this phase of Plug and Play the PNF Registers with ONAP
STAGE 4 – PNF REGISTRATION ONAP REQUIREMENTS
This section describes the PNF registration steps. In this stage of the PnP procedure, the PNF is registering with ONAP. The PNF periodically sends up a PNF registration event. PRH is receiving these events and waiting for the SO instantiation to happen.
STEP 25 AUTHENTICATION – In this step a series of steps occur for the PNF to authenticate with ONAP. This may include TLS1.2 security exchanges, certificate exchanges, and User name/password exchanges. This should be tested. the generalized detailed requirements for security are covered in the security sub-committee.
PNP-4100 [AAF] AAF shall authenticate the PNF. Note: This requirement is here for testing purposes, the detailed requirements for PNF to ONAP security shall be detailed in the security sub-committee.
PNP-4110 [AAF] AAF shall be able to inboard the security keys for vendor certificate validation.
PNP-4120 [PNF] - When the PNF sets up a HTTP or HTTPS connection, it MUST provide a username and password to the DCAE VES Collector for HTTP Basic Authentication.
Note: HTTP Basic Authentication has 4 steps: Request, Authenticate, Authorization with Username/Password Credentials, and Authentication Status as per RFC7617 and RFC 2617
PNP-4121 [PNF] - If the PNF set up a TLS connection and mutual (two-way) authentication is being used, then the PNF MUST provide its own X.509v3 Certificate to the DCAE VES Collector for authentication.
Note: This allows TLS authentication by DCAE VES Collector..
Note: The PNF got its X.509 certificate through Enrollment with an operator certificate authority or a X.509 vendor certificate from the vendor factory CA.
Note: In R3 three authentication options are supported:
(1) HTTP with Username & Password and no TLS
(2) HTTP with Username & Password & TLS with two-way certificate authentication;
(3) HTTP with Username & Password & TLS with server-side certificate authentication.
PNP-4130 [DCAE] - DCAE authenticates the HTTP/TLS connection with a certificate. Certificate is X.509v3 issued by the Service Provider CA. Note: in Dublin, no HTTP username or password is needed.
PNP-4140 [DCAE] - VES Collector authenticates the PNF using the a username and password, Certificate, and standard PKI validation.
PNP-4150 [DCAE] - VES uses integrated CADI module to request the role and permissions for the PNF from AAF.
PNP-4160 [AAF] - AAF returns the role and permissions of the PNF to DCAE.
PNP-4170 [DCAE] - DCAE compares the event to the permissions and either accepts or rejects the event.
STEP 26 PNF SENDS PNF REGISTRATION – The PNF (5G DU) sends a PNF registration message which is received by the PNF Registration Handler in ONAP. This message is sent by the PNF periodically.
PNP-4200 [PNF] – The PNF MUST use a IP address to contact ONAP.
Note: it is expected that an ONAP operator can ascertain the ONAP IP address or the security gateway to reach ONAP on the VID or ONAP portal GUI. Note: The ONAP contact IP address has been previously configured and provisioned prior to this step.
Note: The ONAP IP address could be provisioned or resolved through FQDN & DNS.
PNP-4201 [PNF] - The PNF SHOULD support a HTTPS connection to the DCAE VES Event Listener.
PNP-4202 [PNF] - The PNF MAY support a HTTP connection to the DCAE VES Event Listener.
Note: HTTP is allowed but not recommended.
PNP-4210 [PNF] – The PNF MUST support sending a pnfRegistration VES event. This is detailed in the “PNF Registration VES Event” section of the Plug and Play wiki page at: 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 ENTRY | BASED ON pnfREGISTRATION VES FIELD |
---|---|
serial-number | serialNumber |
equip-vendor | vendorName |
equip-model | modelNumber |
equip-type | unitType |
pnf-name | sourceName |
pnf-id | (PNF-ID is NOT used) |
ipaddress-v4-oam | oamV4IpAddress |
ipaddress-v6-oam | oamV6IpAddress |
software_versions | software_versions [1] { softwareVersion (from pnfRegistration) activeSw = "True" } Note: During PNF Registration only the Active S/W is reported by the PNF. And so only the entry of the PNF A&AI array with the "activeSw" = True would be updated. The PNF S/W upgrade management U/C will update the entire array through the operations of S/W management. |
PNP-4610 [PRH] – If the PRH encounters a situation that there is a PNF entry in A&AI (without IP address), but the VES event itself does not have an PNF IP address it shall log the error. Note: if the PNF does not send its IP address in the VES event this could be from a variety of reasons from a software error to a communication failure.
PNP-4620 [PRH] – (Error Case) If the PRH is unable to update the A&AI entry with the PNF information it shall log the error.
STEP 31 PNF READY EVENT – PRH issues a pnfReady event.
PNP-4700 [PRH] – After the PRH write the IP address of the PNF in the A&AI entry, the PRH shall publish a pnfReady event on the DMaaP topic. Note: This pnfReady event shall be processed by SO to proceed with the Plug and Play procedure.
PNP-4710 [DMaaP] – There shall be created a static pnfReady DMaaP Topic.
PNP-4720 [PRH] – (Error Case) If the PRH is unable to publish the pnfReady event onto the DMaaP topic it shall log the error.
STAGE 3 - PNF REGISTRATION VES EVENT
Field | Type | Required? | Description |
Version | number | Yes | Version of the event header (currently: 3.0): 3.0 |
eventName | string | Yes | pnfRegistration_vendor_pnfName where pnfName is specified by the vendor and is a PNF type; e.g. pnfRegistration_Nokia_gDu |
domain | string | Yes | Event domain enumeration: ‘fault’, ‘heartbeat’, ‘measurementsForVfScaling’, ‘mobileFlow’, ‘other’, ‘sipSignaling’, ‘stateChange’, ‘syslog’, ‘thresholdCrossingAlert’, ‘voiceQuality’, ‘pnfRegistration’ |
eventId | string | Yes | Event key that is unique to the event source registration_yyyyyyyy where yyyyyyyy is an integer starting at 0 and incremented by 1 for every pnfRegistration event sent by this PNF. The key must be unique within notificaiton life cycle similar to EventID from 3GPP. It could be a sequential number, or a composite key formed from the event fields, such as domain_sequence. The eventId should not include whitespace. |
eventType | string | No | pnfRegistration |
nfcNamingCode | string | No | Network function component type: 3 characters (aligned with vfc naming standards). This is not used |
nfNamingCode | string | No | Network function type: 4 characters (aligned with vnf naming standards) Not used |
sourceId | string | No | UUID identifying the entity experiencing the event issue (note: the AT&T internal enrichment process shall ensure that this field is populated) Not used |
sourceName | string | Yes | Name of the entity experiencing the event issue PNF-name (unique PNF correlation ID = pnf-name stored in AAI ; e.g. NOK6061ZW3) |
reportingEntityId | string | No | UUID identifying the entity reporting the event, for example an OAM VM (note: the AT&T internal enrichment process shall ensure that this field is populated) Not used |
reportingEntityName | string | Yes | Name of the entity reporting the event, for example, an EMS name. May be the same as the sourceName. For synthetic events generated by DCAE, it is the name of the app generating the event. PNF-name (unique PNF correlation ID = pnf-name stored in AAI ; e.g. NOK6061ZW3) |
priority | string | Yes | Processing priority enumeration: ‘High’, ‘Medium’, ‘Normal’, ‘Low’ Normal |
startEpochMicrosec | number | Yes | the earliest unix time aka epoch time associated with the event from any component--as microseconds elapsed since 1 Jan 1970 not including leap seconds current time |
lastEpochMicrosec | number | Yes | the latest unix time aka epoch time associated with the event from any component--as microseconds elapsed since 1 Jan 1970 not including leap seconds current time |
sequence | integer | Yes | Ordering of events communicated by an event source instance (or 0 if not needed) 0 |
internalHeader Fields | Internal Header Fields | No | Fields (not supplied by event sources) that the VES Event Listener service can use to enrich the event if needed for efficient internal processing. This is an empty object which is intended to be defined separately by each provider implementing the VES Event Listener. Empty. Not used |
vesEventListenerVersion | string | Yes | Version of the VES event listener API Spec that this event is compliant with (As "#" or "#.#" or "#.#.#" where # is a digit. |
timeZoneOffset | string | No | Offset to GMT to indicate local time zone for device formatted as 'UTC+/-hh.mm'; see https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations for UTC offset examples |
Field | Type | Required? | Description |
pnfRegistration FieldsVersion | number | Yes | Version of the pnfRegistrationFields block as "#.#", where # is a digit (currently: 1.0). See the VES Event Specification for the correct digits to use. |
serialNumber | string | Yes | TS 32.692 serialNumber = serial number of the unit; e.g. 6061ZW3 |
vendorName | string | Yes | TS 32.692 vendorName = name of manufacturer; e.g. Nokia. Maps to AAI equip-vendor. |
oamV4IpAddress | string | No | IPv4 m-plane IP address to be used by the manager to contact the PNF. Maps to AAI ipaddress-v4-oam. |
oamV6IpAddress | string | No | IPv6 m-plane IP address to be used by the manager to contact the PNF. Maps to AAI ipaddress-v6-oam. |
macAddress | string | No | MAC address of OAM interface of the unit. |
unitFamily | string | No | TS 32.692 vendorUnitFamilyType = general type of HW unit; e.g. BBU. |
unitType | string | No | TS 32.692 vendorUnitTypeNumber = vendor name for the unit; e.g. Airscale. Maps to AAI equip-type. |
modelNumber | string | No | TS 32.692 versionNumber = version of the unit from vendor; e.g. AJ02. Maps to AAI equip-model. |
softwareVersion | string | No | TS 32.692 swName = active SW running on the unit; e.g. 5gDUv18.05.201. |
manufactureDate | string | No | TS 32.692 dateOfManufacture = manufacture date of the unit in ISO 8601 format; 2016-04-23. |
lastServiceDate | string | No | TS 32.692 dateOfLastService = date of last service in ISO 8601 format; e.g. 2017-02-15. |
additionalFields | hashMap | No | Additional registration fields if needed, provided as key-value pairs. |
STAGE 5 - RUN-TIME PNF ACTIVATION
In the last Stage 5, SO coordinates with the PNF controller and the PNF is given network assignments, configures, and becomes active and available for service.
STAGE 5 - PNF ACTIVATION REQUIREMENTS
This section describes the PNF activation requirements. In this stage of PNP, the PNF has sent the PNF registration event and it has been received by the PRH successfully, and now in the PnP procedure, SO coordinates with the PNF controller and SDN-C to give the network assignments and service configuration for the PNF.
The major outcome of Stage 5 of the Plug and Play procedure is:
Connection points configured – SDN-C in ONAP configures the PNF transport information.
Second part of PNF service instantiation – The second part of PNF service instantiation is performed and ONAP sends the PNF a service configuration message. Also, ONAP updates the network assignment information, starts the service, and monitors the service provided by the PNF.
PNF configured and ready to provide service – Anyother 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.
PNF DOWNLOAD & ACTIVATION
The final steps of PNF Plug and Play occur after the PNF has been registered. The ONAP PNF Software Use Case is also executed to update the software if necessary.
STEP 44 CONFIGURATION – The PNF can have additional configuration or parameters that can be sent to the PNF from ONAP or an external Element Management System. Additioanl configuration exchanges can happen between the PNF and ONAP through the standard Defined VES event as introduced by this use case: ONAP/3GPP & O-RAN Alignment-Standards Defined Notifications over VES
STEP 45 PNF SOFTWARE UPGRADE – Software download occurs which is described in this use case: 5G - PNF Software Update
STEP 45 READY FOR SERVICE – The PNF is ready for service.
PNP REREGISTRATION USE CASE
This use case is intended to cover a new Epic or Use Case or "Story" for Plug and Play. In all of these situations for this use case, the PNF will go through Plug and Play registration again, hence "PNF Re-registration". In this case, the PNF has already ungone the basic Plug and Play is registering again with the same PNF registration procedure, except that ONAP already recognizes the PNF and it already has an A&AI entry.
The following diagram depicts basic Re-registration situations:
(1) REHOMING - When a PNF is "rehomed" to a new NMS, or managing region it may go through re-registration. Rehoming can be a logical operation or a physical operation. The PNF may now have a new manager, an external manager. The PNF may also now have a new ONAP installation "home".
(2) DISCONNECTION/RECONNECTION - It is conceivable that a PNF may be powered off for a period of time and then is powered on again. A PNF only goes through base Plug and Play once. So a power cycle, or a disconnection/reconnection should not be considered a brand new Plug and Play. For ONAP purposes, this is tracked by the fact that the A&AI will already have a PNF entry. Note in this case, it is expected that the PNF is in the same physical location as before.
(3) PHYSICAL RELOCATION - For a vareity of reasons, the PNF may be moved to a new physical relocation. This would require the PNF to re-register when it returns to service. Similar to the disconnection/reconnection situation, the PNF would not go through "base" plug and play again, but would re-register. Because the PNF is in a new physical location the associated COMPLEX object that is associated with the PNF would need to beu pdated.
(4) NOMADIC ONT PNF (BBS USE CASE) - For the Broadband Service Use Case, a ONT PNF may also be moved to a different location, this is known as a Nomadic ONT. This use case is described in the wiki: BBS Broadband Service Use Case (Dublin).
The following flow diagram shows the steps for this use case
STEP 1 AUTHENTICATE CONNECTION - The PNF Authenticates its connection
PNP-6000 [AAF] AAF shall authenticate the PNF.
PNP-6010 [AAF] AAF shall be able to inboard the security keys for vendor certificate validation.
PNP-6020 [PNF] - When the PNF sets up a HTTP or HTTPS connection, it MUST provide a username and password to the DCAE VES Collector for HTTP Basic Authentication.
Note: HTTP Basic Authentication has 4 steps: Request, Authenticate, Authorization with Username/Password Credentials, and Authentication Status as per RFC7617 and RFC 2617
PNP-6021 [PNF] - If the PNF set up a TLS connection and mutual (two-way) authentication is being used, then the PNF MUST provide its own X.509v3 Certificate to the DCAE VES Collector for authentication.
Note: This allows TLS authentication by DCAE VES Collector..
Note: The PNF got its X.509 certificate through Enrollment with an operator certificate authority or a X.509 vendor certificate from the vendor factory CA.
Note: In R3 three authentication options are supported:
(1) HTTP with Username & Password and no TLS
(2) HTTP with Username & Password & TLS with two-way certificate authentication;
(3) HTTP with Username & Password & TLS with server-side certificate authentication.
PNP-6030 [DCAE] - DCAE authenticates the HTTP/TLS connection with a certificate. Certificate is X.509v3 issued by the Service Provider CA. Note: in Dublin, no HTTP username or password is needed.
PNP-6040 [DCAE] - VES Collector authenticates the PNF using the a username and password, Certificate, and standard PKI validation.
PNP-6050 [DCAE] - VES uses integrated CADI module to request the role and permissions for the PNF from AAF.
PNP-6060 [AAF] - AAF returns the role and permissions of the PNF to DCAE.
PNP-6070 [DCAE] - DCAE compares the event to the permissions and either accepts or rejects the event.
STEP 2 pnfREGISTRATION EVENT RECIEVED BY VES LISTENER
The pnfRegistration VES Event is published onto DMaaP.
PNP-6080 [DCAE/DMaaP/DR] - When the PNF sends the pnfRegistration Event to the DCAE VES Event Listener, DCAE shall publish the VES event received from the PRH onto the DMaaP/DR. The VES event should be using the pnfRegistration domain (Casablanca)
STEP 3 - pnfREGISTRATION ONTO DMaaP
PNP-6090 [DMaaP] – There shall be created a static pnfRegistration DmaaP Topic. Note: That a static as opposed to a dynamic DMaaP topic is needed because it is not known what PNF service will be needed when the PNF registers.
STEP 4 - pnfREGISTRATION EVENT RETRIEVED BY PRH
The pnfRegistration VES Event is retrieved by the PRH.
PNP-6100 [PRH] - PRH shall retrieve the pnfRegistration Event off of the DMaaP Bus. PRH shall periodically check the DMaaP bus for the VES event for the PRH.
PNP-6110 [PRH] – If the PRH is unable to read from DMaaP on the pnfRegistration domain it shall return an error.
PNP-6120 [DMaaP] In DMaaP, end-points need to be configured (topic creation). And PRH needs to have these end-points configured as well. PRH needs to pick up this configuration (cloudify module). And if they are not properly configured, PRH is unable to get the pnfRegistration message off of the DMaaP bus. What would happen is that the DMaaP end-point does not exist; thus an HTTP error response is returned to the PRH. It would require an operator to deduce that this problem has occurred.
PNP-6130 [PRH] - if the PRH is unable to read the pnfRegistration VES message. In this case the schema might be incorrect which results in a mismatch with what the PNF sends and what the PRH expects. Thus, the PRH is unable to process the VES event properly. The PRH shall logs this error.
STEP 5 – INVENTORY ENTRY QUERY - A&AI Query
PNP-6200 [PRH] – The PRH shall perform an A&AI inventory query when it receives the pnfRegistration VES event from the PNF. Note: it is expected that the PNF shall continue to send the VES event until it receives the service configuration request. After the Stage 2 Run-Time Service Instantiation occurs, there shall be an inactive A&AI entry for the PNF. This allows PRH to find that inactive A&AI entry and proceed with the rest of the Plug and Play procedure. PRH shall use the PNF-name (or correlation ID) to find the appropriate PNF A&AI entry.
PNP-6210 [A&AI] – A&AI shall return the entry for the PNF-id when queried. If not found A&AI shall return a negative acknowledgement. See the section on the A&AI PNF entry for more details about the fields that are relevant for the PNF.
PNP-6220 [PRH] - The PRH shall use the "sourcename" (pnf-ID) as the index to A&AI.
STEP 6 - UPDATE PNF ENTRY - Update PNF Entry in A&AI
PNP-6230 [PRH] – If PRH finds an A&AI entry for the PNF, it shall populate the A&AI PNF object fields with as many parameters received as possible, especially the OAM IP address for that entry with the OAM IP address provided in the pnfRegistration VES event sent from the PNF.
In case of additionalFields received within pnfRegistration event, those fields will not be used to update the PNF object parameters (they`re assumed to be domain-specific, while PRH operates of PNF generic parameters).
LOGICAL LINK OBJECT (BBS use-case specific aspect) - Create object in A&AI: "Logical-Link". Use Relation of the A&AI between the PNF instance and the Logical Link instance. This relation can be used by (BBS) microservice to identify the attachment point and cf. w/ storage in inventory to differentiate the case: registration or re-registration.
Instance: PNF ↔ A&AI: PNF (object) ↔ Relationship (objection) ↔ Logical Link (object)
RE-REGISTRATION CRITERIA: PRH does search in A&AI for the PNF. The Criteria to differentiate between initial registration & re-registration. q.v. PNF Re-Registration criteria so that ONAP Policy or other micro-service may use this mechanism to react in case of re-registration, by implementing changes specific to the domain, where that specific PNF operates.
(To be removed in Dublin) Macro flow building blocks. Migration of sub-W/F. (To be removed in Dublin)
Note: The PNF is the master of its IP address and would over-write the OAM IP address(es) in the PNF A&AI entry with the ones provided in the VES event (there is v4 and v6 addresses provided and stored in AAI for a PNF object).
PNP-6240 [DUBLIN][PRH] - The PRH shall enter the following information into the A&AI entry for the PNF extracting the corresponding information from the incoming pnfRegistration VES message. The PRH shall populate A&AI`s PNF object record with information coming in from the pnfRegistration VES event.
A&AI PNF ENTRY | BASED ON pnfREGISTRATION VES FIELD |
---|---|
serial-number | serialNumber |
equip-vendor | vendorName |
equip-model | modelNumber |
equip-type | unitType |
pnf-name | sourceName |
pnf-id | |
ipaddress-v4-oam | oamV4IpAddress |
ipaddress-v6-oam | oamV6IpAddress |
software_versions | software_versions [1] { softwareVersion (from pnfRegistration) activeSw = "True" } |
PNP-6250 [PRH] – If the PRH encounters a situation that there is a PNF entry in A&AI (without IP address), but the VES event itself does not have an PNF IP address it shall log the error.
Note: if the PNF does not send its IP address in the VES event this could be from a variety of reasons from a software error to a communication failure.
PNP-6260 [PRH] – (Error Case) If the PRH is unable to update the A&AI entry with the PNF information it shall log the error.
STEP 7 pnfUpdate EVENT = SERVICE UPDATE PROCEDURE - PRH sends pnfUpdate event
PNP-6270 [PRH] - PRH shall treat a PNF that is sending a pnfRegistration VES Event that already has an A&AI entry as a PNF that is re-registering. If the PRH has been identified as a PNF that is re-registering, PRH shall publish a pnfUpdate event on the DMaaP bus. This will call the Service Update Micro-Service (that is listening for pnfUpdate event). PRH shall pass the pnf-ID of the re-registering PNF so that the Service Update Micro-Service can identify the PNF. The Update Service Micro-service is listening for the pnfUpdate event.
Note: for the BBS Use Case, the additionalFields in the pnfRegistration message contains vital application information that needs to be preserved. This information should either be copied into a new field in the A&AI entry for the PNF, or it should be passed to the UpdateService Micro-service when PRH calls it. This information is copied in to the pnfUpdate event. This is an API change between PRH and consumer of the pnfUpdate event.
Note: The exact criteria, when to classify a pnfRegistration message as "initial registration" or "re-registration" are stored here: PNF Re-Registration criteria
PNP-6410 [DMaaP] – There shall be created a static pnfUpdate DMaaP Topic.
STEP 8 MICROSERVICE ANALYSIS - Microservice is invoked
PNP-6280 [UpdateServiceMSvc] - The purpose of the Update Service Micro-service is that it can identify an associated resource (PNF, VNF) of a service given the identifier, and process a reregistration procedure by updating the service associated with that resource. For example, suppose a PNF have been moved, the associated service needs to be updated. The Update Service Micro-service is listening for the pnfUpdate event.
STEP 9 POLICY USE - A policy framework is invoked
PNP-6290 [Policy] - The Update Service Micro-service issues a special EVENT which will be consumed by POLICY framework. A policy is invoked which performs the service update. The Policy Framework will find a specific policy to handle the request based on the PNF that is being updated. And it will call SO with a (new) Service Update API. The Policy has the responsibility of:
(1) determining that a PNF is reregistering
(2) identifying the PNF with its appropriate PNF-ID
(3) Finding the associated service(s) that is/are associated with the PNF and
(4) updating the service with the information passed from PRH.
(5) Publishing on the DMaaP bus the pnfUpdate Event which will cause SO to update the Service.
STEP 10 MODIFY SERVICE INSTANCE - Policy calls SO through a Modify Service API
PNP-6400 [Policy] – Policy invokes a Modify Service API towards SO. This has the effect to directly calling SO to perform the final steps of the service update associated with the PNF undergoing re-registration.
PNP-6420 [Policy]– (Error Case) If the PRH is unable to publish the pnfReady event onto the DMaaP topic it shall log the error.
STEP 11 QUERY A&AI - A&AI Query
PNP-6430 [SO] – SO shall query A&AI upon invocation of the Modify Service API (from Policy). SO queries A&AI for a valid PNF entry associated with the pnf-Id in the pnfReady event. SO subscribes to certain events, it performs a get off the DMaaP bus, and the pnfUpdate event and has a BPMN recipe associated with that pnfUpdate event. Note: In design-time a service designer creates a (set) of BPMN recipes for SO.
STEP 12 BPMN RECIPE - SO processes the Modify Service request (from Policy) Event
PNP-6440 [SO] -SO will process a BPMN Recipe for the Modify Service request from Policy. The purpose of this is to determine that the PNF is re-registering, and the invoke the appropriate actions to process a the modify service. This means that
(1) it will determine that this is an existing PNF that is reregistering. See the description of the reregistration use case to see why a reregistration occurs: (A) Rehoming (B) Disconnection/Reconnection (C) Physical Relocation (D) Nomadic PNF.
(2) Identify services that are currently depending on this service(s)
(3) Update the states for that PNF. This means that the associated resources of the associated service(s) of that PNF need to be updated (i.e. the PNF is now available). An analysis must be done that says that this PNF is no longer associated with the service (a policy rule with an algorithm assessment would be used to determine this).
(4) Identify the appropriate controller for that PNF.
Note: the Controller might be updated when the PNF re-registered.
STEP 13 RECONFIGURE PNF - PNF configuration is invoked
PNP-6450 [SO] – SO shall lookup through Controller-to-NF association, the appropriate Controller for the PNF. Then, SO shall invoke the PNF controller to request a PNF configuration exchange to happen.
Note: SO interacts with the PNF controller with the Understanding the the GENERIC-RESOURCE-APIs
STEP 14 PNF CONFIGURATION - Controller to PNF interaction
PNP-6500 [CONTROLLER] – The PNF Controller shall sends a Service Configuration to the PNF.
Note: For each associated API there is an associated Directed Graph (which playbook should be called).
PNP-6510 (CONTROLLER) – (Error Case) If there is an error encountered trying to send the Service Configuration command exchange to the PNF, the Controller shall log the fault.
PNP-6520 (CONTROLLER) – (Recovery Case) If there is an error encountered trying to send the Service Configuration command exchange to the PNF, the Controller shall attempt to retry.
PNP-6530 (CONTROLLER) – (Recovery Case) If there is not acknowledgment or response from the PNF while trying to perform a service configuration exchange, the controller shall wait for a time-out period before aborting this attempt. Note: This might be caused by a transient network issue.
PNP-6540 [PNF] - The PNF MUST support the Anible protocol for a Service Configuration message exchange between the PNF and PNF Controller (in ONAP).
Note: this exchange may be either Ansible, Chef, or NetConf depending on the PNF. Note: The PNF Controller may be VF-C, APP-C or SDN-C based on the PNF and PNF domain. Note: for R3 (Casablanca) only Ansible is supported.
PNP-6550 [PNF] - The PNF MUST support the NetConf protocol for a Service Configuration message exchange between the PNF and PNF Controller (in ONAP).
PNP-6560 [PNF] - When the PNF receives a Service configuration from ONAP, the PNF shall cease sending the pnfRegistration VES Event.
PNP-6570 [PNF] - The PNF MAY support the optional parameters for Service Configuration Parameters.
STEP 14A NOTIFICATION FROM PNF
A new notification event is sent from the PNF. This was first used by the BBS Use Case.
After the PNF has received a configuration update, the PNF sends a state change event, which informs ONAP is has successfully connected and serving customer-facing services (CFS).
This is an existing state change notification event (not a new event). An identifier is used within the event.
See the related Wiki pages: CPE Authentication Notification#CPEAuthenticationVESEvent
and CPE Authentication Notification (CPE Authentication Flow)
STEP 15 CONFIGURATION RESPONSE - Configuration Response
PNP-6580 [Controller] – The Controller shall return a response to SO after service configuration
STEP 16 A&AI UPDATE - A&AI Update
PNP-6590 [Controller] – The PNF Controller shall update the PNF A&AI Entry with updated configuration information.
PNF PLUG AND PLAY with LICENSING MANAGEMENT
WHAT: The Licensing Service exchange happens external to ONAP. This solution and message exchange is optional. An external Licensing management solution (e.g. vendor specific solution) will vary with the installed network elements of a vendor and service provider. For more information see the Licensing Management Use Case Page: xNF Licensing Management
WHY: Why is this relevant to Plug and play? Because during the Plug and Play process and registration & orchestration, the xNF can request and obtain licenses from a Licensing services.
WHEN: The interchange can happen any time after stage 3 in the Plug and Play flow.
HOW: The following diagram shows the Licensing Service exchange with the xNF:
The following table describes the steps involved in Licensing Managment.
Note: The interchange can happen any time after stage 3 in the Plug and Play flow
STEP | DESCRIPTION |
---|---|
x | REQUEST LICENSES - The PNF, for example 5G RAN PNF (DU) contacts the License Service to request licenses. Note: This step is optional. This step is labeled "X" because it can be initiated any time after stage 3 in the Plug and Play flow. |
y | RESPONSE WITH LICENSES - The License Service responds to the request for licenses to the originating PNF. Note: This step is optional. This step is labeled "Y" because it can be initiated any time after stage 3 in the Plug and Play flow. |
SUMMARY OF R3 CASABLANCA PLUG AND PLAY ENHANCEMENTS
The follow describes a summary of the Casablanca Enhancements for Plug and Play
TOPIC | DESCRIPTION |
PNF Registration Handler (PRH) Improvements | pnfRegistration Domain - New VES Event domain for PNF registration with corresponding support in VES collector, DMaaP and PRH. PRH & AAF Integration – intra-ONAP security improvements Integration – Integration of Beijing software deliveries. DU Simulator Update – Support of new domain and updates to the DU simulator to match changes made in Casablanca. |
SO Workflow enhancements | Integration - Introduction of dedicated 5G use case work-flow. While the PnP Work-flow was coded in Beijing it was not delivered in that time frame. PNF Controller Interaction – SO to the PNF controller interaction is developed in Casablanca (R3). |
Service Configuration Improvement | PNF Controller – Service configuration improvements from PNF Controller to PNF after PNF registration to PRH. Five optional parameters are requested to be supported with the Casablanca release (R3). |
Security Enhancements | Security Enhancements – Authentication, Certificates, User name & password and intra-ONAP security are used by the Plug and Play Use case. |
Modeling enhancements | PNF Model – Modeling enhancements to support 5G PNF in ONAP with support for the new SoftwareVersionList parameter. |
PNF Onboarding / Package | PNF Package - Defining PNF Onboarding Package. Extending framework to work with PNFs. Defining PNF Package framework. The PNF package artifacts will be delivered in Dublin such as the PM dictionary and FM Yaml dictionary. The definition of these are explored in Casablanca. |
Plug and Play Overview Slides, Demos and Talks (R2-R9)
The following table has some of the Plug and Play overview slides, demos and talks
Description | File |
---|---|
PnP Overview Presentation & Talk (from R7 Guilin Release) | |
PnP Overview Presentation & Talk | Use Case Realization Call: February 19, 2020 |
ROADMAP - PNP Plug and Play Evolution per Release (R2 Beijing - R8 Honolulu)
The following table are Links to the PnP in different releases:
Release | Wiki Link |
---|---|
R2/R3 Beijing Casablanca | 5G - PNF Plug and Play (This base page) |
R4 Dublin | 5G - PNF Plug and Play (Casablanca carry-over items) |
R5 El Alto | Maintenance Release |
R6 Frankfurt | PNF PLUG and PLAY in R6 Frankfurt |
R7 Guilin | R7 PNF Plug and Play PnP |
R8 Honolulu | R8 PNF Plug and Play Use Case |
R9 Istanbul | (No new development) |
R10 Jakarta | (No new development) |
R11 Kohn | (No new development) |
The following table show the PnP Roadmap
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: | |
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) | |
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) | |
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 |
DEVELOPMENT STATUS
Development Status
Project | PTL | JIRA | Description | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
DCAE |
| PNF PnP - PNF Registration Handler | |||||||||||
| Support VES Version 6.0 specification and new Registration domain (new Casablanca scope) | ||||||||||||
DMaaP |
| Static set-up of DMaaP topics - PNF PnP (EPIC) | |||||||||||
TBD | PNF PnP topics: "REGISTRATION" & "PNF_READY" (Story) | ||||||||||||
VNFRQTS | TBD: | ||||||||||||
VID |
| VID Support for PnP Plug and Play, with vCPE Flow. | |||||||||||
VID | Ofir Sonsino |
| VID Support for Service Instantiation work | ||||||||||
VID |
| VID Support for Multi-PNF support. | |||||||||||
A&AI |
| R3 PNF Schema updates in A&AI for PnP Use Case | |||||||||||
SDC | SDC changes for PNF Model | ||||||||||||
SDN-C | Dan Timoney | PNF Controller Support | |||||||||||
Security |
| Security Enhancements that are used by PNF PnP UC. | |||||||||||
PRH (Dublin) | user-063b3 |
| DUBLIN: PRH will fill in A&AI entry from PNF from pnfRegistration VES event |
TESTING - PNF PLUG AND PLAY INTEGRATION & TESTING
- WHO IS TESTING - what company, team, and people will be doing the testing & responsibilities for testing.
- TEST ENVIRONMENT - which does the lab & test environment.
- RESOURCES NEEDED - what resources are needed.
- WHO IS CONTRIBUTING RESOURCES - what resources will be provided and by whom/what company.
- NETWORK CONNECTIVITY - How will a PNF make connectivity to ONAP DCAE VES Event Listener.
TEST & INTEGRATION
PNF PnP Integration Test Cases | 5G - PNF PnP - Integration Test Cases |
Testing Status | Dublin 5G - PNF PnP - Test Status |
R6 Integration Status Page | 2: Frankfurt Release Integration Testing Status |
DEPLOYMENT DIAGRAM
TEST CASES
PnP Flow STEP | TEST CASE SECTION | TEST STATUS | ||||
1 Resource Definition | PnP1 Resource Definition |
| ||||
2 Service Definition | PnP2 Service Definition |
| ||||
3 Type Modeling Artifacts | PnP3 Type Modeling Artifacts |
| ||||
4 Resource Declaration | PnP4 Resource Declaration |
| ||||
5 Create A&AI PNF Entry | PnP5 Create A&AI PNF Entry |
| ||||
13 ONAP Compliant S/W | PnP13 ONAP Compliant S/W |
| ||||
15 Work Order to SO | PnP15 Work Order to SO |
| ||||
16 Service Instantiation | PnP16 Service Instantiation |
| ||||
17 Homing OOF Sniro | PnP17 Homing OOF Sniro |
| ||||
18 Resource RLF | PnP18 Resource RLF |
| ||||
19 Check A&AI Entry | PnP19 Check A&AI Entry |
| ||||
20 Create A&AI Entry | PnP20 Create A&AI Entry |
| ||||
21 Subscribe VES Event | PnP21 Subscribe VES Event |
| ||||
22 RLF Thread Terminates | PnP22 RLF Thread Terminates |
| ||||
25 Authenticates PNF Connection | PnP25 Authenticate PNF Connection |
| ||||
26 PNF Registration VES Events | PnP26 PNF Registration VES Events |
| ||||
27 Inventory Query | PnP27 Inventory Query |
| ||||
29 Inventory Query | PnP29 Inventory Query |
| ||||
30 Update PNF Entry | PnP30 Update PNF Entry |
| ||||
31 PNF Ready | PnP31 PNF Ready |
| ||||
34 Update PNF WF | PnP34 Update PNF WF |
| ||||
35 Network Assignments | PnP35 Network Assignments |
| ||||
36 Configure | PnP36 Configure |
| ||||
37 Service Configuration | PnP37 Service Configuration |
| ||||
38 SO Updates w/ Assginments | PnP38 SO Updates w/ Assginments |
| ||||
39 Controller Replies | PnP39 Controller Replies |
| ||||
40 Service Running | PnP40 Service Running |
| ||||
41 Monitors Service | PnP41 Monitors Service |
| ||||
42 Inform OSS | PnP42 Inform OSS |
|
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
Document | Description | Source |
---|---|---|
Zero Touch | IETF definition of Zero Touch Deployment | https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-29 |
Call Home | ZTP Call Home RFC (IETF RFC8071) | https://tools.ietf.org/html/rfc8071 |
3GPP TS32-501 | Defines PnP Use Case (U/C) | http://www.3gpp.org/ftp//Specs/archive/32_series/32.501/32501-f00.zip |
3GPP TS32-508 | Defines PnP Procedure | http://www.3gpp.org/ftp//Specs/archive/32_series/32.508/32508-f00.zip |
3GPP TS32-509 | Defines PnP Formats | http://www.3gpp.org/ftp//Specs/archive/32_series/32.509/32509-f00.zip |
ETSI Zero Touch Network Service Management | https://www.etsi.org/technologies/zero-touch-network-service-management | |
ONAP WIKI PNF Model | Example: PNF in AAI |
...
- WHO IS TESTING - what company, team, and people will be doing the testing & responsibilities for testing.
- TEST ENVIRONMENT - which does the lab & test environment.
- RESOURCES NEEDED - what resources are needed.
- WHO IS CONTRIBUTING RESOURCES - what resources will be provided and by whom/what company.
PnP Flow STEP
TEST CASE SECTION
RELEASE
1 Resource Definition
PnP1 Resource Definition
R2 (Beijing)
2 Service Definition
PnP2 Service Definition
R3 (SDC: new PNF model)
3 Type Modeling Artifacts
PnP3 Type Modeling Artifacts
R2 (Beijing)
4 Resource Declaration
PnP4 Resource Declaration
R3 (Alt Operator`s Inventory Management system)
5 Create A&AI PNF Entry
PnP5 Create A&AI PNF Entry
R3 (ibid)
13 ONAP Compliant S/W
PnP13 ONAP Compliant S/W
R2 (Beijing)
15 Work Order to SO
PnP15 Work Order to SO
R3 (SO R2 Integration)
16 Service Instantiation
PnP16 Service Instantiation
R3 (SO R2 Integration)
17 Homing OOF Sniro
PnP17 Homing OOF Sniro
R3 (SO R2 Integration)
18 Resource RLF
PnP18 Resource RLF
R3 (SO R2 Integration)
19 Check A&AI Entry
PnP19 Check A&AI Entry
R3 (SO R2 Integration)
20 Create A&AI Entry
PnP20 Create A&AI Entry
R3 (SO R2 Integration)
21 Subscribe VES Event
PnP21 Subscribe VES Event
R3 (SO R2 Integration)
22 RLF Thread Terminates
PnP22 RLF Thread Terminates
R3 (SO R2 Integration)
25 Authenticates PNF Connection
PnP25 Authenticate PNF Connection
R3 (Casablanca)
26 PNF Registration VES Events
PnP26 PNF Registration VES Events
R3 (pnfRegistration domain)
27 Inventory Query
PnP27 Inventory Query
R3 (pnfRegistration domain)
29 Inventory Query
PnP29 Inventory Query
R3 (pnfRegistration domain)
30 Update PNF Entry
PnP30 Update PNF Entry
R3 (pnfRegistration domain)
31 PNF Ready
PnP31 PNF Ready
R3 (pnfRegistration domain)
34 Update PNF WF
PnP34 Update PNF WF
R3 (SO R2 Integration)
35 Network Assignments
PnP35 Network Assignments
R3 (SO R2 Integration)
36 Configure
PnP36 Configure
R3 (SO R2 Integration)
37 Service Configuration
PnP37 Service Configuration
R3 (controller updates)
38 SO Updates w/ Assginments
PnP38 SO Updates w/ Assginments
R2 (Beijing)
39 Controller Replies
PnP39 Controller Replies
R2 (Beijing)
40 Service Running
PnP40 Service Running
R2 (Beijing)
41 Monitors Service
PnP41 Monitors Service
42 Inform OSS