.. Modifications Copyright © 2017-2018 AT&T Intellectual Property. .. Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License"); you may not use this documentation except in compliance with the License. You may obtain a copy of the License at .. https://creativecommons.org/licenses/by/4.0/ .. Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. 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:: :depth: 2 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 ~~~~~~~~~~~~~~~~~~~~ .. container:: note :need:`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. .. container:: note :need:`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. .. container:: note :need:`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. .. container:: note :need:`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//.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. .. container:: note :need:`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 ~~~~~~~~~~~~~~~~~~ .. container:: note :need:`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. .. container:: note :need:`R-444446` The VNF or PNF Provider's Ansible playbooks **SHOULD** issue log messages in the same format as Ansible's default messages: ``[]: `` Example: ``[WARNING]: Ansible version 2.9.3 does not match a known, tested version: 2.8.1, 2.8.2`` .. container:: note :need:`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 ~~~~~~~~~~~~~~~~~~~~ .. container:: note :need:`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. .. container:: note :need:`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. .. container:: note :need:`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. .. container:: note :need:`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. .. container:: note :need:`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. .. container:: note :need:`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 '_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. .. container:: note :need:`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. .. container:: note :need:`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 ``//ansible/vars`` directory. .. container:: note :need:`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 _...json or _...xml when labs and production use different passwords and/or secrets. The is discovered from the environment ``/etc/ansible/ansible.cfg`` where the playbook runs. .. container:: note :need:`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. .. container:: note :need:`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. .. container:: note :need:`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. .. container:: note :need:`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). .. container:: note :need:`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. .. container:: note :need:`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`` .. container:: note :need:`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. .. container:: note :need:`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. .. container:: note :need:`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. .. container:: note :need:`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. .. container:: note :need:`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 ``//ansible/vars`` directory. .. container:: note :need:`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 ~~~~~~~~~~~~~~~~~~~~ .. container:: note R-40293 The VNF or PNF **MUST** make available playbooks that conform to the ONAP requirement. .. container:: note 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 ~~~~~~~~~~~~~~~~~~~~ .. container:: note :need:`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 ~~~~~~~~~~~~~~~~~~~~ .. container:: note 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.) .. container:: note 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. .. container:: note R-08312 The VNF or PNF **MAY** use another option which is expected to include REST delivery of binary encoded data sets. .. container:: note 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). .. container:: note 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. .. container:: note 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. .. container:: note 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. .. container:: note 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 ~~~~~~~~~~~~~~~~~~~~ .. container:: note 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. .. container:: note R-34660 The VNF or PNF **MUST** use the RESTCONF/NETCONF framework used by the ONAP configuration subsystem for synchronous communication. .. container:: note R-42140 The VNF or PNF **MUST** respond to data requests from ONAP as soon as those requests are received, as a synchronous response. .. container:: note 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. .. container:: note 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. .. container:: note 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.) .. container:: note R-73285 The VNF or PNF **MUST** must encode, address and deliver the data as described in the previous paragraphs. .. container:: note 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 ~~~~~~~~~~~~~~~~~~~~ .. container:: note 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. .. container:: note 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 ~~~~~~~~~~~~~~~~~~~~ .. container:: note 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 ~~~~~~~~~~~~~~~~~~~~ .. container:: note R-146931 The VNF or PNF **MUST** report exactly one Measurement event per period per source name. .. container:: note 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 ~~~~~~~~~~~~~~~~~~~~ .. container:: note 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. .. container:: note 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 `_. .. container:: note 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. .. container:: note 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. .. container:: note R-47597 The VNF or PNF **MUST** carry data in motion only over secure connections. .. container:: note 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. .. container:: note 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 ~~~~~~~~~~~~~~~~~~~~ .. container:: note 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 ~~~~~~~~~~~~~~~~~~ .. container:: note :need:`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. .. container:: note :need:`R-554966` The VNF or PNF **MUST** report performance metrics using :ref:`Virtual Function Event Streaming (VES) ` or :ref:`bulk_performance_measurement`. .. container:: note :need:`R-63105` The VNF or PNF **MAY** produce telemetry data using the :doc:`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. .. container:: note :need:`R-69111` The VNF or PNF **MUST** report application logs using either :ref:`Virtual Function Event Streaming (VES) ` or Syslog in compliance with `RFC 5424 `__ . .. container:: note :need:`R-82909` The VNF or PNF **MUST** report faults and alarms using either :ref:`Virtual Function Event Streaming (VES) ` or :ref:`SNMP `. (NOTE: See relevant sections for more detailed requirements) .. container:: note :need:`R-857511` VNF or PNF Provider **MUST** have agreement with the Service Provider before utilizing the :doc:`HV-VES option ` for monitoring as this option does not fully integrate with the ONAP's DCAE event processing capabilities. .. container:: note :need:`R-935717` The VNF or PNF **MUST** report heartbeats using :ref:`Virtual Function Event Streaming (VES) `. Requirements Changed ~~~~~~~~~~~~~~~~~~~~ .. container:: note :need:`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 :doc:`HV-VES collector ` service details for more information. .. container:: note :need:`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. .. container:: note :need:`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 :ref:`bulk_performance_measurement` requirements and the `5G - Bulk PM ONAP Development `__ Wiki page. Monitoring & Management > SNMP Monitoring Requirements ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Requirements Added ~~~~~~~~~~~~~~~~~~ .. container:: note :need:`R-233922` If the VNF or PNF is using SNMP, then the VNF or PNF Provider **SHOULD** provide examples of all SNMP alarms. .. container:: note :need:`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 ~~~~~~~~~~~~~~~~~~~~ .. container:: note R-798933 The VNF or PNF **SHOULD** deliver event records that fall into the event domains supported by VES. .. container:: note R-821839 The VNF or PNF **MUST** deliver event records to ONAP using the common transport mechanisms and protocols defined in this specification. .. container:: note 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 ~~~~~~~~~~~~~~~~~~~~ .. container:: note 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 ~~~~~~~~~~~~~~~~~~ .. container:: note :need:`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. .. container:: note :need:`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) .. container:: note :need:`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 .. container:: note :need:`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. .. container:: note :need:`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. .. container:: note :need:`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 .. container:: note :need:`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 ~~~~~~~~~~~~~~~~~~ .. container:: note :need:`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. .. container:: note :need:`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 ~~~~~~~~~~~~~~~~~~ .. container:: note :need:`R-130645` The VNF or PNF **MUST** respect the Time To Live provided by the DNS for the VES Event Listener FQDN. .. container:: note :need:`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 ~~~~~~~~~~~~~~~~~~~~ .. container:: note :need:`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 :ref:`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 .. container:: note :need:`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 :ref:`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 ~~~~~~~~~~~~~~~~~~ .. container:: note :need:`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. .. container:: note :need:`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 :ref:`ves_buffering_requirements` Requirements. Requirements Changed ~~~~~~~~~~~~~~~~~~~~ .. container:: note :need:`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 ~~~~~~~~~~~~~~~~~~ .. container:: note :need:`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. .. container:: note :need:`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. .. container:: note :need:`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 `_. .. container:: note :need:`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. .. container:: note :need:`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 ~~~~~~~~~~~~~~~~~~~~ .. container:: note :need:`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. .. container:: note :need:`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: * :ref:`VES Event Listener 5.4.1` * :ref:`VES Event Listener 7.1.1` * :ref:`VES Event Listener 7.2` The latest version (7.2) should be preferred. Earlier versions are provided for backwards compatibility. .. container:: note :need:`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. .. container:: note :need:`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. .. container:: note :need:`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 ~~~~~~~~~~~~~~~~~~~~ .. container:: note :need:`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 ~~~~~~~~~~~~~~~~~~~~ .. container:: note :need:`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 ~~~~~~~~~~~~~~~~~~~~ .. container:: note :need:`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 ~~~~~~~~~~~~~~~~~~~~ .. container:: note :need:`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 ~~~~~~~~~~~~~~~~~~~~ .. container:: note :need:`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 ~~~~~~~~~~~~~~~~~~~~ .. container:: note :need:`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 ~~~~~~~~~~~~~~~~~~~~ .. container:: note :need:`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. .. container:: note :need:`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. .. container:: note :need:`R-13613` The VNF **MUST** provide clear measurements for licensing purposes if needed to allow automated scale up/down by the management system. .. container:: note :need:`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. .. container:: note :need:`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 ~~~~~~~~~~~~~~~~~~~~ .. container:: note 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. .. container:: note 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 ~~~~~~~~~~~~~~~~~~~~ .. container:: note :need:`R-22346` The VNF or PNF Provider **MUST** provide :ref:`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 ~~~~~~~~~~~~~~~~~~~~ .. container:: note :need:`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**