Requirement Changes Introduced in Guilin

This document summarizes the requirement changes by section that were introduced between the Frankfurt release and Guilin release. Click on the requirement number to navigate to the

Contents

Summary of Changes

  • Requirements Added: 30

  • Requirements Changed: 51

  • Requirements Removed: 37

Configuration Management > Ansible Standards and Capabilities > VNF or PNF Configuration via Ansible Requirements > Ansible Client Requirements

Requirements Changed

(R-67124)

The VNF or PNF Provider’s Ansible playbooks MUST be designed to run using an inventory hosts file in a supported format; with group names matching VNFC 3-character string adding “vip” for groups with virtual IP addresses shared by multiple VMs as seen in examples provided in Appendix.

(R-94567)

The VNF or PNF Provider’s Ansible playbooks MUST be designed to run using an inventory hosts file in a supported format with only IP addresses or IP addresses and VM/VNF or PNF names.

(R-24482)

The VNF or PNF Provider’s Ansible playbooks MUST be designed to run using an inventory hosts file in a supported format; with site group that shall be used to add site specific configurations to the target VNF or PNF VM(s) as needed.

(R-82018)

The VNF or PNF MUST load the Ansible Server SSH public key onto VNF or PNF VM(s) /root/.ssh/authorized_keys as part of instantiation. Alternative, is for Ansible Server SSH public key to be loaded onto VNF or PNF under /home/<Mechanized user ID>/.ssh/authorized_keys as part of instantiation, when a Mechanized user ID is created during instantiation, and Configure and all playbooks are designed to use a mechanized user ID only for authentication (never using root authentication during Configure playbook run). This will allow the Ansible Server to authenticate to perform post-instantiation configuration without manual intervention and without requiring specific VNF or PNF login IDs and passwords.

CAUTION: For VNFs or PNFs configured using Ansible, to eliminate the need for manual steps, post-instantiation and pre-configuration, to upload of SSH public keys, SSH public keys loaded during (heat) instantiation shall be preserved and not removed by (heat) embedded (userdata) scripts.

(R-92866)

The VNF or PNF Provider MUST include as part of post-instantiation configuration done by Ansible Playbooks the removal/update of the SSH public key from /root/.ssh/authorized_keys, and update of SSH keys loaded through instantiation to support Ansible. This may include creating Mechanized user ID(s) used by the Ansible Server(s) on VNF VM(s) and uploading and installing new SSH keys used by the mechanized use ID(s).

Configuration Management > Ansible Standards and Capabilities > VNF or PNF Configuration via Ansible Requirements > Ansible Playbook Requirements

Requirements Added

(R-195620)

The VNF or PNF Provider’s Ansible playbooks SHOULD compare the version(s) of Ansible that the VNF Provider developed and tested against to the ansible_version.full value during playbook execution, and issue a WARNING message if the operator version is not one of the tested versions.

(R-444446)

The VNF or PNF Provider’s Ansible playbooks SHOULD issue log messages in the same format as Ansible’s default messages: [<Log Level>]: <message>

Example:

[WARNING]: Ansible version 2.9.3 does not match a known, tested version: 2.8.1, 2.8.2

(R-918136)

The VNF or PNF Provider’s Ansible playbooks MUST NOT fail due to a mismatched version check as specified in R-918136. The warning message should be issued, and the playbook execution should continue as normal.

Requirements Changed

(R-49911)

The VNF or PNF Provider MUST assign a new point release to the updated Ansible playbook set. The functionality of a new playbook set must be tested before it is deployed to the production.

(R-24189)

The VNF or PNF Provider MUST deliver a new set of Ansible playbooks that includes all updated and unchanged playbooks for any new revision to an existing set of playbooks.

(R-53245)

The VNF or PNF Provider’s Ansible playbooks MUST NOT require passwords or secrets to be passed in clear text in the command line or Rest API request to run the playbook.

(R-51442)

The VNF or PNF Provider’s Ansible playbooks SHOULD be designed to automatically ‘rollback’ to the original state in case of any errors for actions that change state of the VNF or PNF (e.g., configure).

Note: In case rollback at the playbook level is not supported or possible, the VNF or PNF provider shall provide alternative rollback mechanism (e.g., for a small VNF or PNF the rollback mechanism may rely on workflow to terminate and re-instantiate VNF VMs and then re-run playbook(s)). Backing up updated files is also recommended to support rollback when soft rollback is feasible.

(R-49396)

The VNF or PNF Provider’s Ansible playbooks MUST support each APPC/SDN-C VNF or PNF action by invocation of one playbook [#7.3.4]_. The playbook will be responsible for executing all necessary tasks (as well as calling other playbooks) to complete the request.

(R-50252)

The VNF or PNF Provider’s Ansible playbooks MUST write to a response file in JSON format that will be retrieved and made available by the Ansible Server if, as part of a VNF or PNF action (e.g., audit), a playbook is required to return any VNF or PNF information/response. The text files must be written in the main playbook home directory, in JSON format. The JSON file must be created for the VNF or PNF with the name ‘<VNF or PNF name>_results.txt’. All playbook output results, for all VNF VMS or PNF Server/Blades, to be provided as a response to the request, must be written to this response file.

(R-58301)

The VNF or PNF Provider’s Ansible playbooks SHOULD NOT make requests to Cloud resources e.g. Openstack (nova, neutron, glance, heat, etc.); therefore, there is no use for Cloud specific variables like Openstack UUIDs in Ansible Playbook related artifacts.

Rationale: Flows that require interactions with Cloud services e.g. Openstack shall rely on workflows run by an Orchestrator (Change Management) or other capability (such as a control loop or Operations GUI) outside Ansible Server which can be executed by a APPC/SDN-C. There are policies, as part of Control Loop models, that send remediation action requests to an APPC/SDN-C; these are triggered as a response to an event or correlated events published to Event Bus.

(R-09209)

The VNF or PNF Provider’s Ansible playbooks MUST store any playbook configuration data that requires encryption (passwords, secrets, etc.) in a JSON (.json), YAML (.yaml|.yml) or INI (.ini) file, which will be placed in <VNF type>/<Version>/ansible/vars directory.

(R-46823)

The VNF or PNF Provider’s Ansible playbooks MUST store passwords and other attributes that must remain secret in JSON, YAML or INI with differentiated names when passwords and secrets vary from environment to environment. Example, name must include <Mechanized user ID>_…json or <Mechanized user ID>_…xml when labs and production use different passwords and/or secrets. The <Mechanized user ID> is discovered from the environment /etc/ansible/ansible.cfg where the playbook runs.

(R-48698)

The VNF or PNF Provider’s Ansible playbooks MUST utilize information from key value pairs that will be provided by the Ansible Server as extra-vars during invocation to execute the desired VNF or PNF action. The “extra-vars” attribute-value pairs are passed to the Ansible Server by an APPC/SDN-C as part of the Rest API request. If the playbook requires files, they must also be supplied using the methodology detailed in the Ansible Server API, unless they are bundled with playbooks, example, generic templates. Any files containing instance specific info (attribute-value pairs), not obtainable from any ONAP inventory databases or other sources, referenced and used as input by playbooks, shall be provisioned (and distributed) in advance of use, e.g., VNF or PNF instantiation. Recommendation is to avoid these instance specific, manually created in advance of instantiation, files.

(R-83092)

The VNF or PNF Provider’s Ansible playbooks MUST load passwords and other attributes that must remain secret from JSON, YAML or INI files that can be encrypted/decrypted using Ansible Vault capabilities.

(R-39003)

The VNF or PNF Provider’s Ansible playbooks MUST store passwords and other attributes that must remain secret in JSON, YAML or INI files that can be encrypted/decrypted using Ansible Vault capabilities.

(R-43253)

The VNF or PNF Provider’s Ansible playbooks MUST be designed to allow Ansible Server to infer failure or success based on the “PLAY_RECAP” capability.

Note: There are cases where playbooks need to interpret results of a task and then determine success or failure and return result accordingly (failure for failed tasks).

(R-78640)

The VNF or PNF Provider’s Ansible playbooks SHOULD provide a single YAML or JSON file with all the passwords and secrets to reduce the number of files to be decrypted/encrypted before on-boarding into the central repository.

(R-20988)

The VNF or PNF Provider’s Ansible playbooks MUST not log or display passwords and other attributes that must remain secret when running playbook in debug mode.

NOTE: Use no_log: True

(R-42333)

The VNF or PNF Provider’s Ansible playbooks that target a subset of VMs (or servers/blades) part of a VNF (or PNF) instance MUST be designed to use the VNF or PNF inventory host file and to use a parameter named target_vm_list to provide the subset of VMs in the VNF instance specifically targeted by the playbook.

NOTE: Example of such playbooks would be playbooks used to configure VMs added to a VNF instance as part of a scale-out/up or scale-in/down operation. Such playbook is expected to also need to perform configuration/reconfiguration tasks part of the base VNF instance build.

(R-43353)

The VNF or PNF Provider’s Ansible playbooks MUST return control only after all tasks performed by playbook are fully complete, signaling that the playbook completed all tasks. When starting services, return control only after all services are up. This is critical for workflows where the next steps are dependent on prior tasks being fully completed.

(R-88786)

The VNF or PNF Provider’s Ansible playbooks SHOULD place the passwords and secrets to be edited at the top of the single YAML or JSON file with all the secrets, and the (default) ones that are to remain unchanged ‘ towards the bottom, with commentary separating them.

(R-33280)

The VNF or PNF Provider’s Ansible playbooks MUST NOT contain instance specific values that can not be provided by a parameter to the playbook.

(R-56988)

The VNF or PNF Provider’s Ansible playbooks MUST load any configuration data that requires encryption (passwords, secrets, etc.) in a JSON (.json), YAML (.yaml|.yml) or INI (.ini) file, from the <VNF type>/<Version>/ansible/vars directory.

(R-02651)

The VNF or PNF Provider’s Ansible playbooks SHOULD use available backup capabilities to save a copy of configuration files before implementing changes to support operations such as backing out of software upgrades, configuration changes or other work as this will help backing out of configuration changes when needed.

Requirements Removed

R-40293

The VNF or PNF MUST make available playbooks that conform to the ONAP requirement.

R-49751

The VNF or PNF MUST support Ansible playbooks that are compatible with Ansible version 2.6 or later.

Monitoring & Management > Bulk Performance Measurement

Requirements Changed

(R-75943)

The VNF or PNF SHOULD support the data schema defined in 3GPP TS 32.435 or 3GPP TS 28.532, when supporting the event-driven bulk transfer of monitoring data.

Monitoring & Management > Monitoring & Management Requirements > Addressing and Delivery Protocol

Requirements Removed

R-01033

The VNF or PNF MAY use another option which is expected to include SFTP for asynchronous bulk files, such as bulk files that contain large volumes of data collected over a long time interval or data collected across many VNFs or PNFs. (Preferred is to reorganize the data into more frequent or more focused data sets, and deliver these by REST or TCP as appropriate.)

R-03070

The VNF or PNF MUST, by ONAP Policy, provide the ONAP addresses as data destinations for each VNF or PNF, and may be changed by Policy while the VNF or PNF is in operation. We expect the VNF or PNF to be capable of redirecting traffic to changed destinations with no loss of data, for example from one REST URL to another, or from one TCP host and port to another.

R-08312

The VNF or PNF MAY use another option which is expected to include REST delivery of binary encoded data sets.

R-63229

The VNF or PNF MAY use another option which is expected to include REST for synchronous data, using RESTCONF (e.g., for VNF or PNF state polling).

R-79412

The VNF or PNF MAY use another option which is expected to include TCP for high volume streaming asynchronous data sets and for other high volume data sets. TCP delivery can be used for either JSON or binary encoded data sets.

R-81777

The VNF or PNF MUST be configured with initial address(es) to use at deployment time. Subsequently, address(es) may be changed through ONAP-defined policies delivered from ONAP to the VNF or PNF using PUTs to a RESTful API, in the same manner that other controls over data reporting will be controlled by policy.

R-84879

The VNF or PNF MUST have the capability of maintaining a primary and backup DNS name (URL) for connecting to ONAP collectors, with the ability to switch between addresses based on conditions defined by policy such as time-outs, and buffering to store messages until they can be delivered. At its discretion, the service provider may choose to populate only one collector address for a VNF or PNF. In this case, the network will promptly resolve connectivity problems caused by a collector or network failure transparently to the VNF or PNF.

R-88482

The VNF or PNF SHOULD use REST using HTTPS delivery of plain text JSON for moderate sized asynchronous data sets, and for high volume data sets when feasible.

Monitoring & Management > Monitoring & Management Requirements > Asynchronous and Synchronous Data Delivery

Requirements Removed

R-11240

The VNF or PNF MUST respond with content encoded in JSON, as described in the RESTCONF specification. This way the encoding of a synchronous communication will be consistent with Avro.

R-34660

The VNF or PNF MUST use the RESTCONF/NETCONF framework used by the ONAP configuration subsystem for synchronous communication.

R-42140

The VNF or PNF MUST respond to data requests from ONAP as soon as those requests are received, as a synchronous response.

R-43327

The VNF or PNF SHOULD use Modeling JSON text with YANG, If YANG models need to be translated to and from JSON{RFC7951]. YANG configuration and content can be represented via JSON, consistent with Avro, as described in “Encoding and Serialization” section.

R-46290

The VNF or PNF MUST respond to an ONAP request to deliver granular data on device or subsystem status or performance, referencing the YANG configuration model for the VNF or PNF by returning the requested data elements.

R-70266

The VNF or PNF MUST respond to an ONAP request to deliver the current data for any of the record types defined in `Event Records - Data Structure Description`_ by returning the requested record, populated with the current field values. (Currently the defined record types include fault fields, mobile flow fields, measurements for VNF or PNF scaling fields, and syslog fields. Other record types will be added in the future as they become standardized and are made available.)

R-73285

The VNF or PNF MUST must encode, address and deliver the data as described in the previous paragraphs.

R-86586

The VNF or PNF MUST use the YANG configuration models and RESTCONF [RFC8040] (https://tools.ietf.org/html/rfc8040).

Monitoring & Management > Monitoring & Management Requirements > Google Protocol Buffers (GPB)

Requirements Removed

R-257367

The VNF or PNF, when leveraging Google Protocol Buffers for events, MUST serialize the events using native Google Protocol Buffers (GPB) according to the following guidelines:

  • The keys are represented as integers pointing to the system resources for the VNF or PNF being monitored

  • The values correspond to integers or strings that identify the operational state of the VNF resource, such a statistics counters and the state of an VNF or PNF resource.

  • The required Google Protocol Buffers (GPB) metadata is provided in the form of .proto files.

R-978752

The VNF or PNF providers MUST provide the Service Provider the following artifacts to support the delivery of high-volume VNF or PNF telemetry to DCAE via GPB over TLS/TCP:

  • A valid VES Event .proto definition file, to be used validate and decode an event

  • A valid high volume measurement .proto definition file, to be used for processing high volume events

  • A supporting PM content metadata file to be used by analytics applications to process high volume measurement events

Monitoring & Management > Monitoring & Management Requirements > JSON

Requirements Removed

R-19624

The VNF or PNF, when leveraging JSON for events, MUST encode and serialize content delivered to ONAP using JSON (RFC 7159) plain text format. High-volume data is to be encoded and serialized using Avro, where the Avro data format are described using JSON.

Monitoring & Management > Monitoring & Management Requirements > Reporting Frequency

Requirements Removed

R-146931

The VNF or PNF MUST report exactly one Measurement event per period per source name.

R-98191

The VNF or PNF MUST vary the frequency that asynchronous data is delivered based on the content and how data may be aggregated or grouped together.

Note:

  • For example, alarms and alerts are expected to be delivered as soon as they appear. In contrast, other content, such as performance measurements, KPIs or reported network signaling may have various ways of packaging and delivering content. Some content should be streamed immediately; or content may be monitored over a time interval, then packaged as collection of records and delivered as block; or data may be collected until a package of a certain size has been collected; or content may be summarized statistically over a time interval, or computed as a KPI, with the summary or KPI being delivered.

  • We expect the reporting frequency to be configurable depending on the virtual network functions needs for management. For example, Service Provider may choose to vary the frequency of collection between normal and trouble-shooting scenarios.

  • Decisions about the frequency of data reporting will affect the size of delivered data sets, recommended delivery method, and how the data will be interpreted by ONAP. These considerations should not affect deserialization and decoding of the data, which will be guided by the accompanying JSON schema or GPB definition files.

Monitoring & Management > Monitoring & Management Requirements > Security

Requirements Removed

R-01427

If the VNF or PNF is using Basic Authentication, then the VNF or PNF MUST support the provisioning of security and authentication parameters (HTTP username and password) in order to be able to authenticate with DCAE VES Event Listener.

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

R-42366

The VNF or PNF MUST support secure connections and transports such as Transport Layer Security (TLS) protocol [RFC5246] and should adhere to the best current practices outlined in RFC7525.

R-43387

If the VNF or PNF is using Certificate Authentication, the VNF or PNF MUST support mutual TLS authentication and the Subject Name in the end-entity certificate MUST be used according to RFC5280.

Note: In mutual TLS authentication, the client (VNF or PNF) must authenticate the server (DCAE) certificate and must provide its own X.509v3 end-entity certificate to the server for authentication.

R-44290

The VNF or PNF MUST control access to ONAP and to VNFs or PNFs, and creation of connections, through secure credentials, log-on and exchange mechanisms.

R-47597

The VNF or PNF MUST carry data in motion only over secure connections.

R-55634

If VNF or PNF is using Basic Authentication, then the VNF or PNF MUST be in compliance with RFC7617 for authenticating HTTPS connections to the DCAE VES Event Listener.

R-894004

If the VNF or PNF is using Basic Authentication, then when the VNF or PNF sets up a HTTPS connection to the DCAE VES Event Listener, the VNF or PNF MUST provide a username and password to the DCAE VES Event Listener in the Authorization header and the VNF or PNF MUST support one-way TLS authentication.

Note: In one-way TLS authentication, the client (VNF or PNF) must authentication the server (DCAE) certificate.

Monitoring & Management > Monitoring & Management Requirements > VNF telemetry via standardized interface

Requirements Removed

R-821473

The VNF or PNF MUST produce heartbeat indicators consisting of events containing the common event header only per the VES Listener Specification.

Monitoring & Management > Monitoring and Fault Protocol Selection

Requirements Added

(R-209104)

The VNF or PNF producing VES syslog events SHOULD restrict these events to those that convey significant errors or warnings needed to support the operation or troubleshooting of the VNF or PNF. It is expected the volume of such events would be lower (e.g. less than 2000 per day) than more detailed events produced in the course of normal operations.

(R-554966)

The VNF or PNF MUST report performance metrics using Virtual Function Event Streaming (VES) or Bulk Performance Measurement.

(R-63105)

The VNF or PNF MAY produce telemetry data using the RESTConf Collector, but this requires additional coordination with the operator to appropriately map the data internally to a VES-like structure used within ONAP. If this option is needed, then the VNF or PNF Provider must coordinate with with the Operator for the data to be successfully collected and processed by DCAE.

(R-69111)

The VNF or PNF MUST report application logs using either Virtual Function Event Streaming (VES) or Syslog in compliance with RFC 5424 .

(R-82909)

The VNF or PNF MUST report faults and alarms using either Virtual Function Event Streaming (VES) or SNMP. (NOTE: See relevant sections for more detailed requirements)

(R-857511)

VNF or PNF Provider MUST have agreement with the Service Provider before utilizing the HV-VES option for monitoring as this option does not fully integrate with the ONAP’s DCAE event processing capabilities.

(R-935717)

The VNF or PNF MUST report heartbeats using Virtual Function Event Streaming (VES).

Requirements Changed

(R-697654)

The VNF or PNF MAY leverage ONAP’s High Volume VNF Event Streaming (HV-VES) when there is a need to deliver large volumes of real-time performance management metrics. See HV-VES collector service details for more information.

(R-332680)

The VNF or PNF producing VES events SHOULD deliver syslog messages that meet the criteria in R-209104 to the VES Event Listener using the syslog VES domain.

(R-908291)

The VNF or PNF MAY leverage a bulk VNF or PNF telemetry transmission mechanism in instances where other transmission methods are not practical or advisable.

NOTE: For additional information and use cases for the Bulk Telemetry Transmission Mechanism, please refer to the Bulk Performance Measurement requirements and the 5G - Bulk PM ONAP Development Wiki page.

Monitoring & Management > SNMP Monitoring Requirements

Requirements Added

(R-233922)

If the VNF or PNF is using SNMP, then the VNF or PNF Provider SHOULD provide examples of all SNMP alarms.

(R-261501)

If the VNF or PNF is using SNMP, then the VNF or PNF Provider MUST provide a Management Information Base (MIB) file that uniquely identifies and describes all SNMP events exposed by the network function.

Monitoring & Management > Transports and Protocols Supporting Resource Interfaces

Requirements Removed

R-798933

The VNF or PNF SHOULD deliver event records that fall into the event domains supported by VES.

R-821839

The VNF or PNF MUST deliver event records to ONAP using the common transport mechanisms and protocols defined in this specification.

R-932071

The VNF or PNF provider MUST reach agreement with the Service Provider on the selected methods for encoding, serialization and data delivery prior to the on-boarding of the VNF or PNF into ONAP SDC Design Studio.

Monitoring & Management > Transports and Protocols Supporting Resource Interfaces > VNF or PNF Telemetry using VES/JSON Model

Requirements Removed

R-659655

The VNF or PNF SHOULD leverage the JSON-driven model, as depicted in Figure 2, for data delivery unless there are specific performance or operational concerns agreed upon by the Service Provider that would warrant using an alternate model.

Monitoring & Management > Virtual Function Event Streaming (VES) Client Requirements > Buffering and Redelivery

Requirements Added

(R-103464)

A VNF or PNF producing VES events that is buffering events due to an unavailable VES Event Listener MAY leverage to publishEventBatch operation to redeliver buffered events. Please note this can only be used when all buffered events belong to the same domain due to the restrictions in place for the operation.

(R-346137)

A VNF or PNF producing VES events that is buffering events per R-658596 MUST store in-scope events even when the maximum capacity of the buffer (defined in R-636251) has been reached. To make room for new events in this situation, hte oldest event in the buffer shall be removed as necessary. (i.e. First In First Out)

(R-379523)

A VNF or PNF producing VES events that is buffering events due to an unavailable VES Event Listener MUST redeliver all buffered events according to the following rules when the VNF or PNF detects the VES Event Listener has become available:

  • Deliver all previously buffered events before sending new events

  • Deliver buffered events in the order they were received

(R-498679)

A VNF or PNF producing VES events MAY discard buffered events older than a maximum retention period, not less than 1 hour, even if the event was never successfully delivered to the event listener. While discarding based on this retention period is supported for backwards compatibility, it is recommended to retain events until the maximum buffer size is reached per R-346137 as that will maximize the number of events delivered.

(R-636251)

A VNF or PNF producing VES events MUST size the event buffer referenced in R-658596 such that it can buffer a minimum of 1 hours of events under nominal load.

(R-658596)

A VNF or PNF producing VES events MUST buffer events that meet the following criteria if the VES Event Listener is unreachable or the request encounters a timeout.

  • Faults with eventSeverity of MINOR, MAJOR, NORMAL, or CRITICAL

  • Syslog with syslogSev of Emergency, Alert, Critical, Error, or Warning

  • All measurement events

(R-818859)

The VNF or PNF producing VES events MUST not allow an unavailable or timing out VES Event Listener to impact the performance, stability, or correct execution of network function.

Monitoring & Management > Virtual Function Event Streaming (VES) Client Requirements > Configuration Requirements

Requirements Added

(R-460012)

The VNF or PNF producing VES events MUST allow the configuration of the attributes defined in Table 1 and utilize the provided default value (where applicable) when the configuration value is not provided by the Service Provider.

(R-940591)

A VNF or PNF producing VES events SHOULD use the recommended parameter name for the configurable value from Table 1.

Monitoring & Management > Virtual Function Event Streaming (VES) Client Requirements > Configuration Requirements > VES Listener Endpoint and DNS Resolution

Requirements Added

(R-130645)

The VNF or PNF MUST respect the Time To Live provided by the DNS for the VES Event Listener FQDN.

(R-70492)

The VNF or PNF MUST support DNS resolution of the VES Listener Endpoint if a Fully Qualified Domain Name (FQDN) is provided.

Monitoring & Management > Virtual Function Event Streaming (VES) Client Requirements > Event Definition and Registration

Requirements Changed

(R-120182)

A VNF or PNF Provider utilizing VES MUST indicate specific conditions that may arise, and recommend actions that may be taken at specific thresholds, or if specific conditions repeat within a specified time interval, using the semantics and syntax described by the VES Event Registration specification.

NOTE: The Service Provider may override VNF or PNF provider Event Registrations using the ONAP SDC Design Studio to finalizes Service Provider engineering rules for the processing of the VNF or PNF events. These changes may modify any of the following:

  • Threshold levels

  • Specified actions related to conditions

(R-520802)

If the VNF or PNF is using VES, then the VNF or PNF Provider MUST provide a YAML file formatted in adherence with the VES Event Registration specification that defines the following information for each event produced by the VNF:

  • eventName

  • Required fields

  • Optional fields

  • Any special handling to be performed for that event

Monitoring & Management > Virtual Function Event Streaming (VES) Client Requirements > Event Delivery Requirements

Requirements Added

(R-176945)

The VNF or PNF producing VES events SHOULD NOT send syslog events to the VES Event Listener during debug mode, but rather store syslog events locally for access or possible file transfer.

(R-655209)

The VNF or PNF producing VES events MUST respect the configured VES Timeout Value when delivering VES events, and abort any call where the VES Event Listener does not successfully acknowledge the delivery of event(s) within the Timeout Value. These failed transactions should be buffered and retried in accordance with the Buffering and Redelivery Requirements.

Requirements Changed

(R-06924)

The VNF or PNF producing VES events MUST deliver VES events as it becomes available or according to the configured measurement interval.

Monitoring & Management > Virtual Function Event Streaming (VES) Client Requirements > Event Formatting and Usage

Requirements Added

(R-408814)

The VNF or a PNF producing VES stndDefined domain events to report standards-organization defined events to ONAP, MUST set the event.stndDefinedNamespace property. By default, ONAP ships with support for the following:

  • 3GPP-Provisioning

  • 3GPP-Heartbeat

  • 3GPP-FaultSupervision

  • 3GPP-PerformanceAssurance

Another namespace, outside of the list provided, needs to registered in ONAP in coordination with the operator before it can be used.

(R-408815)

If the VNF or PNF producing VES stndDefined domain events provides the event.stndDefinedFields.schemaReference then it MUST set its value to the publicUrl value in DCAE’s VES Collector etc/externalRepo/schema-map.json that describes the data being sent in event.stndDefinedFields.data.

(R-408816)

If the VNF or PNF producing VES stndDefined domain events provides the event.stndDefinedFields.schemaReference then it MUST only pass events that conform to schema references previously registered with DCAE otherwise the event will be rejected. By default, ONAP ships with support for schemas found in DCAE’s VES Collector etc/externalRepo/schema-map.json.

(R-408817)

The VNF or PNF Provider producing stndDefined events MUST coordinate with the operator, willing to validate stndDefined events, to configure DCAE to accept any new event schema prior to sending those events or the events will be rejected.

(R-408818)

If the VNF or PNF producing VES stndDefined domain events provides the event.stndDefinedFields.schemaReference then it MUST set the event.stndDefined.schemaReference property to an exact structure, from supported schemaReference, describing the notification within an openAPI specification, using JSON Pointer as URI fragment e.g. “https://forge.3gpp.org/…/faultMnS.yaml#/components/schemas/notifyNewAlarm

Requirements Changed

(R-408813)

A VNF or PNF producing VES events MUST pass all information it is able to collect even if the information field is identified as optional. However, if the data cannot be collected, then optional fields can be omitted.

(R-570134)

The VES events produced by the VNF or PNF MUST be compliant with the common event formats defined in one of the following specifications:

The latest version (7.2) should be preferred. Earlier versions are provided for backwards compatibility.

(R-283988)

A VNF or PNF producing VES events MUST NOT send information through extensible structures if the event specification has explicitly defined fields for that information.

(R-528866)

The VES events produced by the VNF or PNF MUST conform to the schema and other formatting requirements specified in the relevant VES Event Listener specification.

(R-470963)

A VNF or PNF producing VES events SHOULD leverage camel case to separate words and acronyms used as keys that will be sent through extensible fields. When an acronym is used as the key, then only the first letter shall be capitalized.

Monitoring & Management > Virtual Function Event Streaming (VES) Client Requirements > Security

Requirements Changed

(R-33878)

The VNF or PNF MUST utilize one of the authentication methods prescribed by the relevant VES Event Listener specification.

ONAP Heat VNF Modularity

Requirements Changed

(R-610030)

A VNF’s Heat Orchestration Template’s Incremental Module MUST declare

  • one or more OS::Nova::Server resources OR

  • one or more OS::Cinder::Volume resources.

An OS::Nova::Server MAY be created in the incremental module or a nested yaml file invoked by the incremental module.

An OS::Cinder::Volume MAY be created in the incremental module or a nested yaml file invoked by the incremental module.

PNF Plug and Play > PNF Plug and Play

Requirements Changed

(R-106240)

A PNF MUST support the pnfRegistration VES event which is required to integrate with ONAP’s PNF Plug and Play capabilities.

TOSCA PNF Descriptor > Capability Types

Requirements Changed

(R-177937)

The PNFD provided by a PNF vendor MUST comply with the following Capabilities Types as specified in ETSI NFV-SOL001 standard:

  • tosca.capabilities.nfv.VirtualLinkable

TOSCA PNF Descriptor > Policy Types

Requirements Changed

(R-596064)

The PNFD provided by a PNF vendor MUST comply with the following Policy Types as specified in ETSI NFV-SOL001 standard:

  • tosca.policies.nfv.SecurityGroupRule

TOSCA PNF Descriptor > Relationship Types

Requirements Changed

(R-64064)

The PNFD provided by a PNF vendor MUST comply with the following Relationship Types as specified in ETSI NFV-SOL001 standard:

  • tosca.relations.nfv.VirtualLinksTo

VNF and PNF On-boarding and package management > Licensing Requirements

Requirements Changed

(R-85991)

If the VNF or PNF requires a license then the VNF or PNF provider MUST provide a universal license key per VNF or PNF to be used as needed by services (i.e., not tied to a VM instance) as the recommended solution. The VNF or PNF provider may provide pools of Unique VNF or PNF License Keys, where there is a unique key for each VNF or PNF instance as an alternate solution. In all cases, licensing issues should be resolved without interrupting in-service VNFs or PNFs.

(R-44569)

If ONAP licensing management solution is used, then the VNF or PNF provider MUST NOT require additional infrastructure such as a VNF or PNF provider license server for VNF or PNF provider functions and metrics.

(R-13613)

The VNF MUST provide clear measurements for licensing purposes if needed to allow automated scale up/down by the management system.

(R-47849)

If ONAP licensing management solution is used, then the VNF or PNF provider MUST support the metadata about licenses (and their applicable entitlements) as defined in the ONAP License Management Information Model, and any license keys required to authorize use of the VNF or PNF software. This metadata will be used to facilitate onboarding the VNF or PNF into the ONAP environment and automating processes for putting the licenses into use and managing the full lifecycle of the licenses.

(R-85653)

If ONAP licensing management solution is used, then the VNF or PNF MUST provide metrics (e.g., number of sessions, number of subscribers, number of seats, etc.) to ONAP for tracking every license.

Requirements Removed

R-44125

The VNF or PNF provider MUST agree to the process that can be met by Service Provider reporting infrastructure. The Contract shall define the reporting process and the available reporting tools.

R-97293

The VNF or PNF provider MUST NOT require audits of Service Provider’s business.

VNF and PNF On-boarding and package management > Resource Description

Requirements Changed

(R-22346)

The VNF or PNF Provider MUST provide VES Event Registration for all VES events provided by that VNF or PNF.

VNF or PNF CSAR Package > VNF or PNF Package Contents

Requirements Changed

(R-40820)

The VNF CSAR PACKAGE MUST enumerate all of the open source licenses their VNF(s) incorporate. CSAR License directory as per ETSI SOL004.

for example ROOT\Licenses\ License_term.txt