diff options
Diffstat (limited to 'docs/changes-by-section-guilin.rst')
| -rw-r--r-- | docs/changes-by-section-guilin.rst | 1581 |
1 files changed, 1581 insertions, 0 deletions
diff --git a/docs/changes-by-section-guilin.rst b/docs/changes-by-section-guilin.rst new file mode 100644 index 0000000..cc08426 --- /dev/null +++ b/docs/changes-by-section-guilin.rst @@ -0,0 +1,1581 @@ +.. 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/<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. + + +.. 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: + ``[<Log Level>]: <message>`` + + 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 '<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. + + +.. 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 ``<VNF type>/<Version>/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 <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. + + +.. 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 + ``<VNF type>/<Version>/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 + <https://tools.ietf.org/html/rfc7951>`_, 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 <http://avro.apache.org/>`_, 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 <https://tools.ietf.org/html/rfc5246>`_] and should adhere to + the best current practices outlined in + `RFC7525 <https://tools.ietf.org/html/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 <https://tools.ietf.org/html/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 <https://tools.ietf.org/html/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) <ves_monitoring_requirements>` + or :ref:`bulk_performance_measurement`. + + +.. container:: note + + :need:`R-63105` + + The VNF or PNF **MAY** produce telemetry data using the + :doc:`RESTConf Collector <dcae:sections/services/restconf/index>`, 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) <ves_monitoring_requirements>` + or Syslog in compliance with + `RFC 5424 <https://tools.ietf.org/html/rfc5424>`__ . + + +.. container:: note + + :need:`R-82909` + + The VNF or PNF **MUST** report faults and alarms using either + :ref:`Virtual Function Event Streaming (VES) <ves_monitoring_requirements>` + or :ref:`SNMP <snmp_monitoring_requirements>`. (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 <dcae:sections/services/ves-hv/index>` + 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) <ves_monitoring_requirements>`. + + +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 <dcae:sections/services/ves-hv/index>` + 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 <https://wiki.onap.org/display/DW/5G+-+Bulk+PM>`__ + 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 <ves_event_registration_3_2>`. + + **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 <ves_event_registration_3_2>` + 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 <https://github.com/onap/dcaegen2-collectors-ves/blob/guilin/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 <https://github.com/onap/dcaegen2-collectors-ves/blob/guilin/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<ves_event_listener_5_4_1>` + * :ref:`VES Event Listener 7.1.1<ves_event_listener_7_1>` + * :ref:`VES Event Listener 7.2<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 <https://docs.onap.org/projects/onap-modeling-modelspec/en/latest/ONAP%20Model%20Spec/im/License/LicenseModel.html>`__, + 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 <ves_event_registration_3_2>` + 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** + |