diff options
| author |   Lovett, Trevor <trevor.lovett@att.com> | 2018-10-17 14:59:49 -0500 |
|---|---|---|
| committer | Lovett, Trevor <trevor.lovett@att.com> | 2018-10-19 14:04:29 -0500 |
| commit | 3558e4ae816958ead70d2032426ec09ae66b5fd0 (patch) | |
| tree | e264be2ef5da5314b6fb0094199cb24d2b9ce42c /docs/changes-by-section-casablanca.rst | |
| parent | 460a3bce7753bec655426f09eb4765a245082425 (diff) | |
VNFRQTS - Dynamic Release Notes
Also fixed couple formatting issues that were causing errors in the
Sphinx job.
Change-Id: Iae938e41d1d3746aa8faa1edbc652d68d9c7aa6e
Issue-ID: VNFRQTS-447
Signed-off-by: Lovett, Trevor <trevor.lovett@att.com>
Diffstat (limited to 'docs/changes-by-section-casablanca.rst')
| -rw-r--r-- | docs/changes-by-section-casablanca.rst | 4293 |
1 files changed, 4293 insertions, 0 deletions
diff --git a/docs/changes-by-section-casablanca.rst b/docs/changes-by-section-casablanca.rst new file mode 100644 index 0000000..6cc56c5 --- /dev/null +++ b/docs/changes-by-section-casablanca.rst @@ -0,0 +1,4293 @@ +.. 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 Casablanca +======================================================== + +This document summarizes the requirement changes by section that were +introduced between the Beijing release and +Casablanca release. Click on the requirement number to +navigate to the + +.. contents:: + :depth: 2 + +Summary of Changes +------------------ + +* **Requirements Added:** 70 +* **Requirements Changed:** 187 +* **Requirements Removed:** 61 + + +Contrail Resource Parameters > Contrail Network Parameters > External Networks +------------------------------------------------------------------------------ + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-02164` + + When a VNF's Heat Orchestration Template's Contrail resource + has a property that + references an external network that requires the network's + Fully Qualified Domain Name (FQDN), the property parameter + + * **MUST** follow the format ``{network-role}_net_fqdn`` + * **MUST** be declared as type ``string`` + * **MUST NOT** be enumerated in the VNF's Heat Orchestration Template's + Environment File + + +Heat > Cinder Volumes +--------------------- + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-79531 + + The VNF Heat Orchestration Template **MUST** define + "outputs" in the volume template for each Cinder volume + resource universally unique identifier (UUID) (i.e. ONAP + Volume Template Output Parameters). + + +Heat > Heat Orchestration Template Format > Heat Orchestration Template Structure > resources > metadata +-------------------------------------------------------------------------------------------------------- + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-97199 + + A VNF's Heat Orchestration Template's OS::Nova::Server + resource **MUST** contain the attribute "metadata". + + +Heat > Heat Template Constructs > Heat Files Support (get_file) +--------------------------------------------------------------- + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-62177 + + When using the intrinsic function get_file, the included files + **MUST** have unique file names within the scope of the VNF. + + +Heat > Heat Template Constructs > Nested Heat Template Requirements +------------------------------------------------------------------- + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-89868 + + The VNF Heat Orchestration Template **MUST** have unique + file names within the scope of the VNF for a nested heat yaml file. + + +Heat > Networking > External Networks +------------------------------------- + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-29865 + + When a VNF connects to an external network, a network role, + referred to as the '{network-role}' **MUST** be assigned to the + external network for use in the VNF's Heat Orchestration Template. + + +Heat > Networking > Internal Networks +------------------------------------- + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-34726 + + If a VNF's port is connected to an internal network and the port + is created in the same Heat Orchestration Template as the internal network, + then the port resource **MUST** use a 'get_resource' to obtain + the network UUID. + + +Heat > ONAP Resource ID and Parameter Naming Convention > Contrail Resource Parameters > Contrail Network Parameters > External Networks +---------------------------------------------------------------------------------------------------------------------------------------- + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-73228 + + A VNF's Heat Orchestration Template's parameter + '{network-role}_net_fqdn' + **MUST** be declared as type 'string'. + + +Heat > ONAP Resource ID and Parameter Naming Convention > Resource: OS::Nova::Server – Metadata Parameters > vm_role +-------------------------------------------------------------------------------------------------------------------- + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-46823 + + A VNF's Heat Orchestration Template's OS::Nova::Server + Resource metadata map value parameter 'vnf_name' **MUST** be + either + + - enumerated in the VNF's Heat Orchestration + Template's environment file. + + - hard coded in the VNF's Heat Orchestration + Template's OS::Nova::Resource metadata property. + + +Heat > ONAP Support of Environment Files +---------------------------------------- + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-22656 + + The VNF Heat Orchestration Template **MUST** have a + corresponding environment file for a Cinder Volume Module. + + +.. container:: note + + R-35727 + + The VNF Heat Orchestration Template **MUST** have a + corresponding environment file for an Incremental module. + + +.. container:: note + + R-67205 + + The VNF Heat Orchestration Template **MUST** have a corresponding + environment file for a Base Module. + + +Monitoring & Management > Data Structure Specification of the Event Record +-------------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-120182` + + The xNF provider **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 :doc:`VES Event Registration specification<../../../../vnfsdk/module.git/files/VESEventRegistration_3_0>`. + + +.. container:: note + + :need:`R-123044` + + The xNF Provider **MAY** require that specific events, identified by their + ``eventName``, require that certain fields, which are optional in the common + event format, must be present when they are published. + + +.. container:: note + + :need:`R-520802` + + The xNF provider **MUST** provide a YAML file formatted in adherence with + the :doc:`VES Event Registration specification<../../../../vnfsdk/module.git/files/VESEventRegistration_3_0>` + 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 + + +.. container:: note + + :need:`R-570134` + + The events produced by the xNF **MUST** must be compliant with the common + event format defined in the + :doc:`VES Event Listener<../../../../vnfsdk/model.git/docs/files/VESEventListener_7_0_1>` + specification. + + +Monitoring & Management > Event Records - Data Structure Description > Common Event Header +------------------------------------------------------------------------------------------ + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-528866` + + The VNF **MUST** produce VES events that include the following mandatory + fields in the common event header. + + * ``domain`` - the event domain enumeration + * ``eventId`` - the event key unique to the event source + * ``eventName`` - the unique event name + * ``lastEpochMicrosec`` - the latest unix time (aka epoch time) associated + with the event + * ``priority`` - the processing priority enumeration + * ``reportingEntityName`` - name of the entity reporting the event or + detecting a problem in another xNF + * ``sequence`` - the ordering of events communicated by an event source + * ``sourceName`` - name of the entity experiencing the event issue, which + may be detected and reported by a separate reporting entity + * ``startEpochMicrosec`` - the earliest unix time (aka epoch time) + associated with the event + * ``version`` - the version of the event header + * ``vesEventListenerVersion`` - Version of the VES event listener API spec + that this event is compliant with + + +Monitoring & Management > Event Records - Data Structure Description > Miscellaneous +------------------------------------------------------------------------------------ + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-283988` + + The VNF, when publishing events, **MUST NOT** send information through + extensible structures if the event specification has explicitly defined + fields for that information. + + +.. container:: note + + :need:`R-408813` + + The VNF, when publishing 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-470963` + + The VNF, when publishing events, **MUST** 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 > Monitoring & Management Requirements > Asynchronous and Synchronous Data Delivery +----------------------------------------------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-332680` + + The xNF **SHOULD** deliver all syslog messages to the VES Collector per the + specifications in Monitoring and Management chapter. + + +Monitoring & Management > Monitoring & Management Requirements > Bulk Performance Measurement +--------------------------------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-440220` + + The xNF **SHOULD** support File transferring protocol, such as FTPES or SFTP, + when supporting the event-driven bulk transfer of monitoring data. + + +.. container:: note + + :need:`R-75943` + + The xNF **SHOULD** support the data schema defined in 3GPP TS 32.435, when + supporting the event-driven bulk transfer of monitoring data. + + +.. container:: note + + :need:`R-841740` + + The xNF **SHOULD** support FileReady VES event for event-driven bulk transfer + of monitoring data. + + +Monitoring & Management > Monitoring & Management Requirements > Google Protocol Buffers (GPB) +---------------------------------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-257367` + + The xNF, 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 xNF 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 xNF resource. + * The required Google Protocol Buffers (GPB) metadata is provided in the + form of .proto files. + + +.. container:: note + + :need:`R-978752` + + The xNF providers **MUST** provide the Service Provider the following + artifacts to support the delivery of high-volume xNF 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 Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-19624` + + The xNF, 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 [#7.4.1]_ data + format are described using JSON. + + +Monitoring & Management > Monitoring & Management Requirements > Reporting Frequency +------------------------------------------------------------------------------------ + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-146931` + + The xNF **MUST** report exactly one Measurement event per period + per source name. + + +Monitoring & Management > Monitoring & Management Requirements > VNF telemetry via standardized interface +--------------------------------------------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-821473` + + The xNF MUST produce heartbeat indicators consisting of events containing + the common event header only per the VES Listener Specification. + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-51910 + + The xNF **MUST** provide all telemetry (e.g., fault event + records, syslog records, performance records etc.) to ONAP using the + model, format and mechanisms described in this section. + + +Monitoring & Management > Transports and Protocols Supporting Resource Interfaces +--------------------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-798933` + + The xNF **SHOULD** deliver event records that fall into the event domains + supported by VES. + + +.. container:: note + + :need:`R-821839` + + The xNF **MUST** deliver event records to ONAP using the common transport + mechanisms and protocols defined in this document. + + +.. container:: note + + :need:`R-932071` + + The xNF 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 xNF into ONAP SDC Design Studio. + + +Monitoring & Management > Transports and Protocols Supporting Resource Interfaces > Bulk Telemetry Transmission +--------------------------------------------------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-908291` + + The XNF **MAY** leverage bulk xNF telemetry transmission mechanism, as + depicted in Figure 4, in instances where other transmission methods are not + practical or advisable. + + +Monitoring & Management > Transports and Protocols Supporting Resource Interfaces > xNF Telemetry using Google Protocol Buffers +------------------------------------------------------------------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-697654` + + The xNF **MAY** leverage the Google Protocol Buffers (GPB) delivery model + depicted in Figure 3 to support real-time performance management (PM) data. + In this model the VES events are streamed as binary-encoded GBPs over via + TCP sockets. + + +Monitoring & Management > Transports and Protocols Supporting Resource Interfaces > xNF Telemetry using VES/JSON Model +---------------------------------------------------------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-659655` + + The xNF **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. + + +ONAP Heat Cinder Volumes +------------------------ + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-270358` + + A VNF's Heat Orchestration Template's Cinder Volume Template **MUST** + contain either + + * An ``OS::Cinder::Volume`` resource + * An ``OS::Heat::ResourceGroup`` resource that references a Nested YAML + file that contains an ``OS::Cinder::Volume`` resource + * A resource that defines the property ``type`` as a Nested YAML file + (i.e., static nesting) and the Nested YAML contains + an ``OS::Cinder::Volume`` resource + + +ONAP Heat Heat Template Constructs > Heat Files Support (get_file) +------------------------------------------------------------------ + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-76718` + + If a VNF's Heat Orchestration Template uses the intrinsic function + ``get_file``, the ``get_file`` target **MUST** be referenced in + the Heat Orchestration Template by file name. + + +.. container:: note + + :need:`R-41888` + + A VNF's Heat Orchestration Template intrinsic function + ``get_file`` **MUST NOT** utilize URL-based file retrieval. + + +.. container:: note + + :need:`R-87848` + + When using the intrinsic function get_file, ONAP does not support + a directory hierarchy for included files. All files must be in a + single, flat directory per VNF. A VNF's Heat Orchestration + Template's ``get_file`` target files **MUST** be in the same + directory hierarchy as the VNF's Heat Orchestration Templates. + + +.. container:: note + + :need:`R-05050` + + A VNF's Heat Orchestration Templates intrinsic function + ``get_file`` <content key> **MAY** be used: + + * more than once in a VNF's Heat Orchestration Template + * in two or more of a VNF's Heat Orchestration Templates + * in a VNF's Heat Orchestration Templates nested YAML file + + +ONAP Heat Heat Template Constructs > Nested Heat Templates > Nested Heat Template Requirements +---------------------------------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-70112` + + A VNF's Heat Orchestration Template **MUST** reference a Nested YAML + file by name. The use of ``resource_registry`` in the VNF's Heat + Orchestration Templates Environment File **MUST NOT** be used. + + +ONAP Heat Networking > External Networks +---------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-00606` + + A VNF **MAY** be connected to zero, one or more than one external + network. + + +ONAP Heat Networking > Internal Networks +---------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-52425` + + A VNF's port connected to an internal network **MUST** + use the port for the purpose of reaching VMs in the same VNF. + + +.. container:: note + + :need:`R-87096` + + A VNF **MAY** contain zero, one or more than one internal network. + + +.. container:: note + + :need:`R-46461` + + A VNF's port connected to an internal network **MUST NOT** use the port + for the purpose of reaching VMs in another VNF and/or an + external gateway and/or + external router. + + +ONAP Heat Orchestration Template Format +--------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-92635` + + A VNF's Heat Orchestration Template **MUST** be compliant with the + OpenStack Template Guide. + + +ONAP Heat Orchestration Template Format > Environment File Format +----------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-86285` + + A VNF's Heat Orchestration template **MUST** have a + corresponding environment file. + + +.. container:: note + + :need:`R-03324` + + A VNF's Heat Orchestration template's Environment File **MUST** + contain the ``parameters:`` section. + + +.. container:: note + + :need:`R-68198` + + A VNF's Heat Orchestration template's Environment File's + ``parameters:`` section **MAY** (or **MAY NOT**) enumerate parameters. + + +ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > parameters +-------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-90279` + + A VNF Heat Orchestration's template's parameter **MUST** be used + in a resource with the exception of the parameters for the + ``OS::Nova::Server`` resource property ``availability_zone``. + + +.. container:: note + + :need:`R-91273` + + A VNF Heat Orchestration's template's parameter for the + ``OS::Nova::Server`` resource property ``availability_zone`` + **MAY NOT** be used in any ``OS::Nova::Server``. + + +ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > parameters > constraints +---------------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-79817` + + A VNF's Heat Orchestration Template's parameter defined + in a non-nested YAML file as + type ``comma_delimited_list`` **MAY** have a parameter constraint defined. + + +.. container:: note + + :need:`R-00011` + + A VNF's Heat Orchestration Template's parameter defined + in a nested YAML file + **MUST NOT** have a parameter constraint defined. + + +.. container:: note + + :need:`R-96227` + + A VNF's Heat Orchestration Template's parameter defined + in a non-nested YAML file as type + ``json`` **MAY** have a parameter constraint defined. + + +.. container:: note + + :need:`R-88863` + + A VNF's Heat Orchestration Template's parameter defined + in a non-nested YAML file as type + ``number`` **MUST** have a parameter constraint of ``range`` or + ``allowed_values`` defined. + + +.. container:: note + + :need:`R-40518` + + A VNF's Heat Orchestration Template's parameter defined + in a non-nested YAML file as type + ``string`` **MAY** have a parameter constraint defined. + + +.. container:: note + + :need:`R-06613` + + A VNF's Heat Orchestration Template's parameter defined + in a non-nested YAML file as type + ``boolean`` **MAY** have a parameter constraint defined. + + +ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > parameters > default +------------------------------------------------------------------------------------------------------ + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-26124` + + If a VNF Heat Orchestration Template parameter has a default value, + it **MUST** be enumerated in the environment file. + + +ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > parameters > type +--------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-11441` + + A VNF's Heat Orchestration Template's parameter type **MUST** be one of + the following values: + + * ``string`` + * ``number`` + * ``json`` + * ``comma_delimited_list`` + * ``boolean`` + + +ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > resources +------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-40551` + + A VNF's Heat Orchestration Template's Nested YAML files **MAY** + (or **MAY NOT**) contain the section ``resources:``. + + +ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > resources > deletion_policy +------------------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-43740` + + VNF's Heat Orchestration Template's Resource **MAY** declare the + attribute ``deletion_policy:``. + + +ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > resources > external_id +--------------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-78569` + + VNF's Heat Orchestration Template's Resource **MAY** declare the + attribute ``external_id:``. + + +ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > resources > metadata +------------------------------------------------------------------------------------------------------ + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-67386` + + A VNF's Heat Orchestration Template's Resource **MAY** declare the + attribute ``metadata``. + + +ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > resources > properties +-------------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-10834` + + If a VNF's Heat Orchestration Template resource attribute + ``property:`` uses a nested ``get_param``, the nested + ``get_param`` **MUST** reference an index. + + +ONAP Heat Orchestration Templates Overview > ONAP Heat Orchestration Template Filenames > Base Modules +------------------------------------------------------------------------------------------------------ + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-81339` + + A VNF Heat Orchestration Template's Base Module file name **MUST** include + case insensitive 'base' in the filename and + **MUST** match one of the following four + formats: + + 1.) ``base_<text>.y[a]ml`` + + 2.) ``<text>_base.y[a]ml`` + + 3.) ``base.y[a]ml`` + + 4.) ``<text>_base_<text>``.y[a]ml + + where ``<text>`` **MUST** contain only alphanumeric characters and + underscores '_' and **MUST NOT** contain the case insensitive word ``base``. + + +ONAP Heat Orchestration Templates Overview > ONAP Heat Orchestration Template Filenames > Cinder Volume Modules +--------------------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-82732` + + A VNF Heat Orchestration Template's Cinder Volume Module **MUST** + be named identical to the base or incremental module it is supporting with + ``_volume`` appended. + + +.. container:: note + + :need:`R-31141` + + VNF Heat Orchestration Template's Cinder Volume Module's Environment File + **MUST** be named identical to the VNF Heat Orchestration Template's + Cinder Volume Module with ``.y[a]ml`` replaced with ``.env``. + + +ONAP Heat Orchestration Templates Overview > ONAP Heat Orchestration Template Filenames > Incremental Modules +------------------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-87247` + + VNF Heat Orchestration Template's Incremental Module file name + **MUST** contain only alphanumeric characters and underscores + '_' and **MUST NOT** contain the case insensitive word ``base``. + + +ONAP Heat Orchestration Templates Overview > ONAP Heat Orchestration Template Filenames > Nested Heat file +---------------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-76057` + + VNF Heat Orchestration Template's Nested YAML file name **MUST** contain + only alphanumeric characters and underscores '_' and + **MUST NOT** contain the case insensitive word ``base``. + + +ONAP Heat Orchestration Templates Overview > ONAP VNF Modularity Overview +------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-11200` + + A VNF's Cinder Volume Module, when it exists, **MUST** be 1:1 + with a Base module or Incremental module. + + +.. container:: note + + :need:`R-33132` + + A VNF's Heat Orchestration Template **MAY** be + 1.) Base Module Heat Orchestration Template (also referred to as a + Base Module), + 2.) Incremental Module Heat Orchestration Template (referred to as + an Incremental Module), or + 3.) a Cinder Volume Module Heat Orchestration Template (referred to as + Cinder Volume Module). + + +.. container:: note + + :need:`R-37028` + + A VNF **MUST** be composed of one Base Module + + +.. container:: note + + :need:`R-20974` + + At orchestration time, the VNF's Base Module **MUST** + be deployed first, prior to any incremental modules. + + +.. container:: note + + :need:`R-81725` + + A VNF's Incremental Module **MUST** have a corresponding Environment File + + +.. container:: note + + :need:`R-53433` + + A VNF's Cinder Volume Module **MUST** have a corresponding environment file + + +.. container:: note + + :need:`R-38474` + + A VNF's Base Module **MUST** have a corresponding Environment File. + + +ONAP Heat Orchestration Templates Overview > Output Parameters > ONAP Volume Module Output Parameters +----------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-07443` + + A VNF's Heat Orchestration Templates' Cinder Volume Module Output + Parameter's name and type **MUST** match the input parameter name and type + in the corresponding Base Module or Incremental Module unless the Output + Parameter is of the type ``comma_delimited_list``, then the corresponding + input parameter **MUST** be declared as type ``json``. + + +.. container:: note + + :need:`R-89913` + + A VNF's Heat Orchestration Template's Cinder Volume Module Output + Parameter(s) + **MUST** include the + UUID(s) of the Cinder Volumes created in template, + while others **MAY** be included. + + +ONAP Heat VNF Modularity +------------------------ + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-61001` + + A shared Heat Orchestration Template resource is a resource that **MUST** + be defined in the base module and will be referenced by one or + more resources in one or more incremental modules. + + The UUID of the shared resource (created in the base module) **MUST** be + exposed by declaring a parameter in the + ``outputs`` section of the base module. + + For ECOMP to provided the UUID value of the shared resource to the + incremental module, the parameter name defined in the ``outputs`` + section of the base module **MUST** be defined as a parameter + in the ``parameters`` section of the incremental module. + + ECOMP will capture the output parameter name and value in the base module + and provide the value to the corresponding parameter(s) in the + incremental module(s). + + +ONAP Output Parameter Names > Predefined Output Parameters > OAM Management IP Addresses +---------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-48987` + + If the VNF's OAM Management IP Address is cloud assigned and + and the OAM IP Address is required to be inventoried in ONAP A&AI, + then the parameter **MUST** be obtained by the + resource ``OS::Neutron::Port`` + attribute ``ip_address``. + + +.. container:: note + + :need:`R-56287` + + If the VNF's OAM Management IP Address is assigned by ONAP SDN-C and + assigned in the VNF's Heat Orchestration Template's via a heat resource + ``OS::Neutron::Port`` property ``fixed_ips`` map property + ``ip_adress`` parameter (e.g., ``{vm-type}_{network-role}_ip_{index}``, + ``{vm-type}_{network-role}_v6_ip_{index}``) + and the OAM IP Address is required to be inventoried in ONAP A&AI, + then the parameter **MUST** be echoed in an output statement. + + .. code-block:: yaml + + outputs: + oam_management_v4_address: + value: {get_param: {vm-type}_{network-role}_ip_{index} } + oam_management_v6_address: + value: {get_param: {vm-type}_{network-role}_v6_ip_{index} } + + +.. container:: note + + :need:`R-94669` + + If a VNF has one IPv6 OAM Management IP Address and the + IP Address needs to be inventoried in ONAP's A&AI + database, an output parameter **MUST** be declared in only one of the + VNF's Heat Orchestration Templates and the parameter **MUST** be named + ``oam_management_v6_address``. + + +ONAP TOSCA VNFD Requirements > TOSCA VNF Descriptor > Capability Types +---------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-67895` + + The VNFD provided by VNF vendor may use the below described TOSCA + capabilities. An on-boarding entity (ONAP SDC) **MUST** support them. + + **tosca.capabilities.nfv.VirtualBindable** + + A node type that includes the VirtualBindable capability indicates + that it can be pointed by **tosca.relationships.nfv.VirtualBindsTo** + relationship type. + + **tosca.capabilities.nfv.VirtualLinkable** + + A node type that includes the VirtualLinkable capability indicates + that it can be pointed by **tosca.relationships.nfv.VirtualLinksTo** + relationship. + + **tosca.capabilities.nfv.ExtVirtualLinkable** + + A node type that includes the ExtVirtualLinkable capability + indicates that it can be pointed by + **tosca.relationships.nfv.VirtualLinksTo** relationship. + + **Note**: This capability type is used in Casablanca how it does + not exist in the last SOL001 draft + + **tosca.capabilities.nfv.VirtualCompute** and + **tosca.capabilities.nfv.VirtualStorage** includes flavours of VDU + + +ONAP TOSCA VNFD Requirements > TOSCA VNF Descriptor > Data Types +---------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-54356` + + The below table includes the data types used by NFV node and is based + on TOSCA/YAML constructs specified in draft GS NFV-SOL 001. The node + data definitions/attributes used in VNFD **MUST** comply with the below + table. + + +.. container:: note + + :need:`R-54876` + + The below table describes the data types used for LCM configuration + and is based on TOSCA constructs specified in draft GS NFV-SOL 001. + The LCM configuration data elements used in VNFD **MUST** comply + with the below table. + + +ONAP TOSCA VNFD Requirements > TOSCA VNF Descriptor > General +------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-15837` + + The following table defines the major TOSCA Types specified in + ETSI NFV-SOL001 standard draft. The VNFD provided by a VNF vendor + **MUST** comply with the below definitions: + + +.. container:: note + + :need:`R-17852` + + The VNFD **MAY** include TOSCA/YAML definitions that are not part of + NFV Profile. If provided, these definitions MUST comply with TOSCA + Simple Profile in YAML v.1.2. + + +.. container:: note + + :need:`R-35854` + + The VNF Descriptor (VNFD) provided by VNF vendor **MUST** comply with + TOSCA/YAML based Service template for VNF descriptor specified in + ETSI NFV-SOL001. + + **Note**: As the ETSI NFV-SOL001 is work in progress the below tables + summarizes the TOSCA definitions agreed to be part of current version + of NFV profile and that VNFD MUST comply with in ONAP Release 2+ + Requirements. + + +.. container:: note + + :need:`R-46527` + + A VNFD is a deployment template which describes a VNF in terms of + deployment and operational behavior requirements. It contains + virtualized resources (nodes) requirements as well as connectivity + and interfaces requirements and **MUST** comply with info elements + specified in ETSI GS NFV-IFA 011. The main parts of the VNFD are + the following: + + - VNF topology: it is modeled in a cloud agnostic way using virtualized + containers and their connectivity. Virtual Deployment Units (VDU) + describe the capabilities of the virtualized containers, such as + virtual CPU, RAM, disks; their connectivity is modeled with VDU + Connection Point Descriptors (VduCpd), Virtual Link Descriptors + (VnfVld) and VNF External Connection Point Descriptors + (VnfExternalCpd); + + - VNF deployment aspects: they are described in one or more + deployment flavours, including configurable parameters, instantiation + levels, placement constraints (affinity / antiaffinity), minimum and + maximum VDU instance numbers. Horizontal scaling is modeled with + scaling aspects and the respective scaling levels in the deployment + flavours; + + **Note**: The deployment aspects (deployment flavour etc.) are postponed + for future ONAP releases. + + - VNF lifecycle management (LCM) operations: describes the LCM operations + supported per deployment flavour, and their input parameters; + Note, thatthe actual LCM implementation resides in a different layer, + namely referring to additional template artifacts. + + +.. container:: note + + :need:`R-65486` + + The VNFD **MUST** comply with ETSI GS NFV-SOL001 document endorsing + the above mentioned NFV Profile and maintaining the gaps with the + requirements specified in ETSI GS NFV-IFA011 standard. + + +ONAP TOSCA VNFD Requirements > TOSCA VNF Descriptor > Interface Types +--------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-32155` + + The VNFD provided by VNF vendor may use the below described TOSCA + interface types. An on-boarding entity (ONAP SDC) **MUST** support them. + + **tosca.interfaces.nfv.vnf.lifecycle.Nfv** supports LCM operations + + +ONAP TOSCA VNFD Requirements > TOSCA VNF Descriptor > Relationship Types +------------------------------------------------------------------------ + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-95321` + + The VNFD provided by VNF vendor may use the below described TOSCA + relationships. An on-boarding entity (ONAP SDC) **MUST** support them. + + **tosca.relationships.nfv.VirtualBindsTo** + + This relationship type represents an association relationship between + VDU and CP node types. + + **tosca.relationships.nfv.VirtualLinksTo** + + This relationship type represents an association relationship between + the VduCpd's and VirtualLinkDesc node types. + + +ONAP TOSCA VNFD Requirements > VNF CSAR Package > VNF Package Contents +---------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-01123` + + The VNF package Manifest file **MUST** contain: VNF package meta-data, a + list of all artifacts (both internal and external) entry's including + their respected URI's, an algorithm to calculate a digest and a digest + result calculated on the content of each artifacts, as specified in + ETSI GS NFV-SOL004. The VNF Package MUST include VNF Identification + Data to uniquely identify the resource for a given VNF provider. The + identification data must include: an identifier for the VNF, the name + of the VNF as was given by the VNF provider, VNF description, VNF + provider, and version. + + +.. container:: note + + :need:`R-10087` + + The VNF package **MUST** contain all standard artifacts as specified in + ETSI GS NFV-SOL004 including Manifest file, VNFD (or Main TOSCA/YAML + based Service Template) and other optional artifacts. CSAR Manifest + file as per SOL004 - for example ROOT\\ **MainServiceTemplate.mf** + + +.. container:: note + + :need:`R-21322` + + The VNF provider **MUST** provide their testing scripts to support + testing as specified in ETSI NFV-SOL004 - Testing directory in CSAR + + +.. container:: note + + :need:`R-26885` + + The VNF provider **MUST** provide the binaries and images needed to + instantiate the VNF (VNF and VNFC images) either as: + + - Local artifact in CSAR: ROOT\\Artifacts\\ **VNF_Image.bin** + + - externally referred (by URI) artifact in Manifest file (also may be + referred by VNF Descriptor) + + Note: Currently, ONAP doesn't have the capability of Image management, + we upload the image into VIM/VNFM manually. + + +.. container:: note + + :need:`R-40820` + + The VNF provider 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** + + +ONAP TOSCA VNFD Requirements > VNF CSAR Package > VNF Package Structure and Format +---------------------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-51347` + + The VNF package **MUST** be arranged as a CSAR archive as specified in + TOSCA Simple Profile in YAML 1.2. + + +.. container:: note + + :need:`R-87234` + + The VNF package provided by a VNF vendor **MAY** be either with + TOSCA-Metadata directory (CSAR Option 1) or without TOSCA-Metadata + directory (CSAR Option 2) as specified in ETSI GS NFV-SOL004. On-boarding + entity (ONAP SDC) must support both options. + + **Note:** SDC supports only the CSAR Option 1 in Casablanca. The Option 2 + will be considered in future ONAP releases, + + +PNF Plug and Play > PNF Plug and Play +------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-01427` + + The PNF **MUST** support the provisioning of security and authentication + parameters (HTTP username and password) in order to be able to authenticate + with DCAE (in ONAP). + + Note: In R3, a username and password are used with the DCAE VES Event + Listener which are used for HTTP Basic Authentication. + + Note: The configuration management and provisioning software are specific + to a vendor architecture. + + +.. container:: note + + :need:`R-106240` + + The following VES Events **MUST** be supported by the PNF: pnfRegistration + VES Event, HVol VES Event, and Fault VES Event. These are onboarded via + he SDC Design Studio. + + Note: these VES Events are emitted from the PNF to support PNF Plug and + Play, High Volume Measurements, and Fault events respectively. + + +.. container:: note + + :need:`R-17624` + + The PNF **MAY** support the optional parameters for Service + Configuration Parameters. + + Note: These are detailed in the Stage 5 PnP + + Note: These parameters are optional, and not all PNFs will support any + or all of these parameters, it is up to the vendor and service provider + to ascertain which ones are supported up to an including all of the ones + that have been defined. Note: It is expected that there will be a growing + list of supported configuration parameters in future releases of ONAP. + + +.. container:: note + + :need:`R-256347` + + The PNF **MUST** support the Ansible protocol for a Service Configuration + message exchange between the PNF and PNF Controller (in ONAP). + + Note: this exchange may be either Ansible, Chef, or NetConf depending on + the PNF. Note: The PNF Controller may be VF-C, APP-C or SDN-C based on the + PNF and PNF domain. Note: for R3 (Casablanca) only Ansible is supported. + + +.. container:: note + + :need:`R-258352` + + The PNF **MUST** support & accept the provisioning of an ONAP contact IP + address (in IPv4 or IPv6 format). + + Note: For example, it a possibility is that an external EMS would configure + & provision the ONAP contact IP address to the PNF (in either IPv4 or + IPv6 format). For the PNF Plug and Play Use Case, this IP address is the + service provider's "point of entry" to the DCAE VES Listener. + + Note: different service provider's network architecture may also require + special setup to allow an external PNF to contact the ONAP installation. + For example, in the AT&T network, a maintenance tunnel is used to access + ONAP. + + +.. container:: note + + :need:`R-284934` + + If the PNF encounters an error authenticating, reaching the ONAP DCAE VES + Event listener or recieves an error response from sending the pnfRegistration + VES Event, it **MAY** log the error, and notify the operator. + + Note: the design of how errors are logged, retrieved and reported + will be a vendor-specific architecture. Reporting faults and errors + is also a vendor specific design. It is expected that the PNF shall + have a means to log an error and notify a user when a fault condition + occurs in trying to contact ONAP, authenticate or send a pnfRegistration + event. + + +.. container:: note + + :need:`R-378131` + + (Error Case) - If an error is encountered by the PNF during a + Service Configuration exchange with ONAP, the PNF **MAY** log the + error and notify an operator. + + +.. container:: note + + :need:`R-56718` + + The PNF Vendor **MAY** provide software version(s) to be supported by PNF + for SDC Design Studio PNF Model. This is set in the PNF Model property + software_versions. + + +.. container:: note + + :need:`R-579051` + + The PNF **MAY** support a HTTP connection to the DCAE VES Event Listener. + + Note: HTTP is allowed but not recommended. + + +.. container:: note + + :need:`R-638216` + + (Error Case) - The PNF **MUST** support a configurable timer to stop the + periodicity sending of the pnfRegistration VES event. If this timer expires + during a Service Configuration exchange between the PNF and ONAP, it + MAY log a time-out error and notify an operator. + + Note: It is expected that each vendor will enforce and define a PNF + service configuration timeout period. This is because the PNF cannot + wait indefinitely as there may also be a technician on-site trying to + complete installation & commissioning. The management of the VES event + exchange is also a requirement on the PNF to be developed by the PNF + vendor. + + +.. container:: note + + :need:`R-686466` + + The PNF **MUST** support sending a pnfRegistration VES event. + + +.. container:: note + + :need:`R-707977` + + When the PNF receives a Service configuration from ONAP, the PNF **MUST** + cease sending the pnfRegistration VES Event. + + +.. container:: note + + :need:`R-763774` + + The PNF **MUST** support a HTTPS connection to the DCAE VES Event + Listener. + + +.. container:: note + + :need:`R-793716` + + The PNF **MUST** have "ONAP Aware" software which is capable of performing + PNF PnP registration with ONAP. The "ONAP Aware" software is capable of + performing the PNF PnP Registration with ONAP MUST either be loaded + separately or integrated into the PNF software upon physical delivery + and installation of the PNF. + + Note: It is up to the specific vendor to design the software management + functions. + + +.. container:: note + + :need:`R-809261` + + The PNF **MUST** use a IP address to contact ONAP. + + Note: it is expected that an ONAP operator can ascertain the ONAP IP + address or the security gateway to reach ONAP on the VID or ONAP portal + GUI. + + Note: The ONAP contact IP address has been previously configured and + provisioned prior to this step. + + Note: The ONAP IP address could be provisioned or resolved through + FQDN & DNS. + + +.. container:: note + + :need:`R-894004` + + When the PNF sets up a HTTP or HTTPS connection, it **MUST** provide a + username and password to the DCAE VES Collector for HTTP Basic + Authentication. + + Note: HTTP Basic Authentication has 4 steps: Request, Authenticate, + Authorization with Username/Password Credentials, and Authentication Status + as per RFC7617 and RFC 2617. + + +.. container:: note + + :need:`R-952314` + + If the PNF set up a TLS connection and mutual (two-way) authentication is + being used, then the PNF **MUST** provide its own X.509v3 Certificate to + the DCAE VES Collector for authentication. + + Note: This allows TLS authentication by DCAE VES Collector. + + Note: The PNF got its X.509 certificate through Enrollment with an + operator certificate authority or a X.509 vendor certificate from the + vendor factory CA. + + Note: In R3 three authentication options are supported: + + (1) HTTP with Username & Password and no TLS. + + (2) HTTP with Username & Password & TLS with two-way certificate + authentication. + + (3) HTTP with Username & Password & TLS with server-side + certificate authentication. + + +.. container:: note + + :need:`R-980039` + + The PNF **MUST** send the pnfRegistration VES event periodically. + + +.. container:: note + + :need:`R-981585` + + The pnfRegistration VES event periodicity **MUST** be configurable. + + Note: The PNF uses the service configuration request as a semaphore to + stop sending the pnfRegistration sent. See the requirement PNP-5360 + requirement. + + +Resource IDs +------------ + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-82115` + + When a VNF's Heat Orchestration Template's resource is associated with a + single ``{vm-type}`` + and a single external network, the Resource ID text **MUST** contain both + the ``{vm-type}`` + and the ``{network-role}`` + + - the ``{vm-type}`` **MUST** appear before the ``{network-role}`` and + **MUST** be separated by an underscore '_' + + + - e.g., ``{vm-type}_{network-role}``, ``{vm-type}_{index}_{network-role}`` + + + - note that an ``{index}`` value **MAY** separate the ``{vm-type}`` and the + ``{network-role}`` and when this occurs underscores **MUST** separate the + three values. (e.g., ``{vm-type}_{index}_{network-role}``). + + +.. container:: note + + :need:`R-82551` + + When a VNF's Heat Orchestration Template's resource is associated with a + single ``{vm-type}`` and a single internal network, the Resource ID **MUST** + contain both the ``{vm-type}`` and the ``int_{network-role}`` and + + - the ``{vm-type}`` **MUST** appear before the ``int_{network-role}`` and + **MUST** be separated by an underscore '_' + + - (e.g., ``{vm-type}_int_{network-role}``, + ``{vm-type}_{index}_int_{network-role}``) + + - note that an ``{index}`` value **MAY** separate the + ``{vm-type}`` and the ``int_{network-role}`` and when this occurs + underscores **MUST** separate the three values. + (e.g., ``{vm-type}_{index}_int_{network-role}``). + + +.. container:: note + + :need:`R-67793` + + When a VNF's Heat Orchestration Template's resource is associated + with more than one ``{vm-type}`` and/or more than one internal and/or + external network, the Resource ID **MUST** not contain the ``{vm-type}`` + and/or ``{network-role}``/``int_{network-role}``. It also should contain the + term ``shared`` and/or contain text that identifies the VNF. + + +.. container:: note + + :need:`R-98138` + + When a VNF's Heat Orchestration Template's resource is associated with a + single internal network, the Resource ID **MUST** contain the text + ``int_{network-role}``. + + +Resource IDs > Contrail Heat Resources Resource ID Naming Convention > OS::ContrailV2::VirtualNetwork +----------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-99110` + + A VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::VirtualNetwork`` Resource ID **MUST** use the naming convention + + 1) ``int_{network-role}_network`` + + or + + 2) ``int_{network-role}_RVN`` where RVN represents Resource Virtual + Network + + VNF Heat Orchestration Templates can only create internal networks. + There is no ``{index}`` after ``{network-role}`` because ``{network-role}`` + **MUST** be unique in the scope of the VNF's + Heat Orchestration Template. + + Note that option 1 is preferred. + + +Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Neutron::Net +---------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-25720` + + A VNF's Heat Orchestration Template's Resource ``OS::Neutron::Net`` + Resource ID **MUST** use the naming convention + + * ``int_{network-role}_network`` + + VNF Heat Orchestration Templates can only create internal networks. + There is no ``{index}`` after ``{network-role}`` because ``{network-role}`` + **MUST** be unique in the scope of the VNF's + Heat Orchestration Template. + + +Resource: OS::Neutron::Port - Parameters > Introduction > Items to Note +----------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-48880` + + If a VNF's Port is attached to an external network and the port's + IP addresses are assigned by ONAP's SDN-Controller, + the ``OS::Neutron::Port`` Resource's + + * property ``fixed_ips`` map property ``ip_address`` **MUST** be used + * property ``fixed_ips`` map property ``subnet`` + **MUST NOT** be used + + +.. container:: note + + :need:`R-45602` + + If a VNF's Port is attached to a network (internal or external) + and the port's IP addresses are cloud assigned by OpenStack's DHCP + Service, the ``OS::Neutron::Port`` Resource's + + * property ``fixed_ips`` map property ``ip_address`` **MUST NOT** be used + * property ``fixed_ips`` map property ``subnet`` + **MAY** be used + + +.. container:: note + + :need:`R-70964` + + If a VNF's Port is attached to an internal network and the port's + IP addresses are statically assigned by the VNF's Heat Orchestration\ + Template (i.e., enumerated in the Heat Orchestration Template's + environment file), the ``OS::Neutron::Port`` Resource's + + * property ``fixed_ips`` map property ``ip_address`` **MUST** be used + * property ``fixed_ips`` map property ``subnet`` + **MUST NOT** be used + + +Resource: OS::Neutron::Port - Parameters > Property: allowed_address_pairs, Map Property: ip_address > VIP Assignment, External Networks, Supported by Automation +----------------------------------------------------------------------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-41492` + + When the VNF's Heat Orchestration Template's Resource + ``OS::Neutron::Port`` is attaching to an external network (per the + ONAP definition, see Requirement R-57424), + and an IPv4 Virtual IP (VIP) + address is assigned via ONAP automation + using the property ``allowed_address_pairs`` + map property ``ip_address`` and + the parameter name **MUST** follow the + naming convention + + * ``{vm-type}_{network-role}_floating_ip`` + + where + + * ``{vm-type}`` is the {vm-type} associated with the + OS::Nova::Server + * ``{network-role}`` is the {network-role} of the external + network + + And the parameter **MUST** be declared as type ``string``. + + +.. container:: note + + :need:`R-35735` + + When the VNF's Heat Orchestration Template's Resource + ``OS::Neutron::Port`` is attaching to an external network (per the + ONAP definition, see Requirement R-57424), + and an IPv6 Virtual IP (VIP) + address is assigned via ONAP automation + using the property ``allowed_address_pairs`` + map property ``ip_address``, + the parameter name **MUST** follow the + naming convention + + * ``{vm-type}_{network-role}_floating_v6_ip`` + + where + + * ``{vm-type}`` is the {vm-type} associated with the + OS::Nova::Server + * ``{network-role}`` is the {network-role} of the external + network + + And the parameter **MUST** be declared as type ``string``. + + +Resource: OS::Neutron::Port - Parameters > Property: fixed_ips, Map Property: ip_address +---------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-40971` + + When the VNF's Heat Orchestration Template's Resource + ``OS::Neutron::Port`` is attaching to an external network (per the + ONAP definition, see Requirement R-57424), + and an IPv4 address is assigned + using the property ``fixed_ips`` + map property ``ip_address`` and the parameter type is defined as a string, + the parameter name **MUST** follow the + naming convention + + * ``{vm-type}_{network-role}_ip_{index}`` + + where + + * ``{vm-type}`` is the {vm-type} associated with the + ``OS::Nova::Server`` + * ``{network-role}`` is the {network-role} of the external + network + * the value for ``{index}`` must start at zero (0) and increment by one + + +.. container:: note + + :need:`R-98569` + + The VNF's Heat Orchestration Template's Resource + ``OS::Neutron::Port`` property ``fixed_ips`` + map property ``ip_address`` parameter + ``{vm-type}_int_{network-role}_v6_ips`` + **MUST** be enumerated in the + VNF's Heat Orchestration Template's Environment File. + + +.. container:: note + + :need:`R-04697` + + When the VNF's Heat Orchestration Template's Resource + ``OS::Neutron::Port`` is attaching to an external network (per the + ONAP definition, see Requirement R-57424), + and an IPv4 address is assigned + using the property ``fixed_ips`` + map property ``ip_address`` and the parameter type is defined as a + ``comma_delimited_list``, + the parameter name **MUST** follow the + naming convention + + * ``{vm-type}_{network-role}_ips`` + + where + + * ``{vm-type}`` is the {vm-type} associated with the + ``OS::Nova::Server`` + * ``{network-role}`` is the {network-role} of the external + network + + +.. container:: note + + :need:`R-90206` + + The VNF's Heat Orchestration Template's Resource + ``OS::Neutron::Port`` property ``fixed_ips`` + map property ``ip_address`` parameter + ``{vm-type}_int_{network-role}_int_ips`` + **MUST** be enumerated in the + VNF's Heat Orchestration Template's Environment File. + + +.. container:: note + + :need:`R-87123` + + The VNF's Heat Orchestration Template's Resource + ``OS::Neutron::Port`` property ``fixed_ips`` + map property ``ip_address`` parameter + ``{vm-type}_{network-role}_v6_ip_{index}`` + **MUST NOT** be enumerated in the + VNF's Heat Orchestration Template's Environment File. + + +.. container:: note + + :need:`R-93496` + + The VNF's Heat Orchestration Template's Resource ``OS::Neutron::Port`` + property ``fixed_ips`` + map property ``ip_address`` + parameter associated with an internal network, i.e., + + * ``{vm-type}_int_{network-role}_ip_{index}`` + * ``{vm-type}_int_{network-role}_v6_ip_{index}`` + * ``{vm-type}_int_{network-role}_ips`` + * ``{vm-type}_int_{network-role}_v6_ips`` + + + **MUST** be enumerated in the Heat Orchestration + Template's Environment File and IP addresses **MUST** be + assigned. + + +.. container:: note + + :need:`R-85235` + + When the VNF's Heat Orchestration Template's Resource + ``OS::Neutron::Port`` is attaching to an internal network (per the + ONAP definition, see Requirements R-52425 and R-46461), + and an IPv4 address is assigned + using the property ``fixed_ips`` + map property ``ip_address`` and the parameter type is defined as a + ``comma_delimited_list``, + the parameter name **MUST** follow the + naming convention + + * ``{vm-type}_int_{network-role}_ips`` + + where + + * ``{vm-type}`` is the {vm-type} associated with the + ``OS::Nova::Server`` + * ``{network-role}`` is the {network-role} of the internal + network + + +.. container:: note + + :need:`R-23503` + + When the VNF's Heat Orchestration Template's Resource + ``OS::Neutron::Port`` is attaching to an external network (per the + ONAP definition, see Requirement R-57424), + and an IPv6 address is assigned + using the property ``fixed_ips`` + map property ``ip_address`` and the parameter type is defined as a + ``comma_delimited_list``, + the parameter name **MUST** follow the + naming convention + + * ``{vm-type}_{network-role}_v6_ips`` + + where + + * ``{vm-type}`` is the {vm-type} associated with the + OS::Nova::Server + * ``{network-role}`` is the {network-role} of the external + network + + +.. container:: note + + :need:`R-27818` + + When the VNF's Heat Orchestration Template's Resource + ``OS::Neutron::Port`` is attaching to an internal network (per the + ONAP definition, see RRequirements R-52425 and R-46461), + and an IPv6 address is assigned + using the property ``fixed_ips`` + map property ``ip_address`` and the parameter type is defined as a + ``string``, + the parameter name **MUST** follow the + naming convention + + * ``{vm-type}_int_{network-role}_v6_ip_{index}`` + + where + + * ``{vm-type}`` is the {vm-type} associated with the + ``OS::Nova::Server`` + * ``{network-role}`` is the {network-role} of the internal + network + * the value for ``{index}`` must start at zero (0) and increment by one + + +.. container:: note + + :need:`R-71577` + + When the VNF's Heat Orchestration Template's Resource + ``OS::Neutron::Port`` is attaching to an external network (per the + ONAP definition, see Requirement R-57424), + and an IPv6 address is assigned + using the property ``fixed_ips`` + map property ``ip_address`` and the parameter type is defined as a string, + the parameter name **MUST** follow the + naming convention + + * ``{vm-type}_{network-role}_v6_ip_{index}`` + + where + + * ``{vm-type}`` is the {vm-type} associated with the + OS::Nova::Server + * ``{network-role}`` is the {network-role} of the external + network + * the value for ``{index}`` must start at zero (0) and increment by one + + +.. container:: note + + :need:`R-78380` + + When the VNF's Heat Orchestration Template's Resource + ``OS::Neutron::Port`` is attaching to an internal network (per the + ONAP definition, see Requirements R-52425 and R-46461), + and an IPv4 address is assigned + using the property ``fixed_ips`` + map property ``ip_address`` and the parameter type is + defined as a ``string``, + the parameter name **MUST** follow the + naming convention + + * ``{vm-type}_int_{network-role}_ip_{index}`` + + where + + * ``{vm-type}`` is the {vm-type} associated with the + OS::Nova::Server + * ``{network-role}`` is the {network-role} of the internal + network + * the value for ``{index`` must start at zero (0) and increment by one + + +.. container:: note + + :need:`R-28795` + + The VNF's Heat Orchestration Template's Resource + ``OS::Neutron::Port`` property ``fixed_ips`` + map property ``ip_address`` parameter + ``{vm-type}_int_{network-role}_ip_{index}`` + **MUST** be enumerated in the + VNF's Heat Orchestration Template's Environment File. + + +.. container:: note + + :need:`R-62590` + + The VNF's Heat Orchestration Template's Resource ``OS::Neutron::Port`` + property ``fixed_ips`` + map property ``ip_address`` + parameter associated with an external network, i.e., + + * ``{vm-type}_{network-role}_ip_{index}`` + * ``{vm-type}_{network-role}_v6_ip_{index}`` + * ``{vm-type}_{network-role}_ips`` + * ``{vm-type}_{network-role}_v6_ips`` + + + **MUST NOT** be enumerated in the Heat Orchestration + Template's Environment File. ONAP provides the IP address + assignments at orchestration time. + + +.. container:: note + + :need:`R-97201` + + The VNF's Heat Orchestration Template's Resource + ``OS::Neutron::Port`` property ``fixed_ips`` + map property ``ip_address`` parameter + ``{vm-type}_int_{network-role}_v6_ip_{index}`` + **MUST** be enumerated in the + VNF's Heat Orchestration Template's Environment File. + + +.. container:: note + + :need:`R-29765` + + When the VNF's Heat Orchestration Template's Resource + ``OS::Neutron::Port`` is attaching to an internal network (per the + ONAP definition, see Requirements R-52425 and R-46461), + and an IPv6 address is assigned + using the property ``fixed_ips`` + map property ``ip_address`` and the parameter type is defined as a + ``comma_delimited_list``, + the parameter name **MUST** follow the + naming convention + + * ``{vm-type}_int_{network-role}_v6_ips`` + + where + + * ``{vm-type}`` is the {vm-type} associated with the + ``OS::Nova::Server`` + * ``{network-role}`` is the {network-role} of the internal + network + + +.. container:: note + + :need:`R-39841` + + The VNF's Heat Orchestration Template's Resource + ``OS::Neutron::Port`` property ``fixed_ips`` + map property ``ip_address`` parameter + ``{vm-type}_{network-role}_ip_{index}`` + **MUST NOT** be enumerated in the + VNF's Heat Orchestration Template's Environment File. + + +Resource: OS::Neutron::Port - Parameters > Property: fixed_ips, Map Property: subnet +------------------------------------------------------------------------------------ + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-38236` + + The VNF's Heat Orchestration Template's + resource ``OS::Neutron::Port`` property ``fixed_ips`` + map property ``subnet`` parameter + **MUST** be declared type ``string``. + + +.. container:: note + + :need:`R-76160` + + When + + * the VNF's Heat Orchestration Template's + resource ``OS::Neutron::Port`` in an Incremental Module is attaching + to an internal network (per the ONAP definition, see Requirements + R-52425 and R-46461) + that is created in the Base Module, AND + * an IPv6 address is being cloud assigned by OpenStack's DHCP Service AND + * the internal network IPv6 subnet is to be specified + using the property ``fixed_ips`` map property ``subnet``, + + the parameter **MUST** follow the naming convention + ``int_{network-role}_v6_subnet_id``, + where ``{network-role}`` is the network role of the internal network. + + Note that the parameter **MUST** be defined as an ``output`` parameter in + the base module. + + +.. container:: note + + :need:`R-22288` + + The VNF's Heat Orchestration Template's Resource + ``OS::Neutron::Port`` property ``fixed_ips`` + map property ``subnet`` parameter + ``int_{network-role}_v6_subnet_id`` + **MUST NOT** be enumerated in the + VNF's Heat Orchestration Template's Environment File. + + +.. container:: note + + :need:`R-83677` + + The VNF's Heat Orchestration Template's Resource + ``OS::Neutron::Port`` property ``fixed_ips`` + map property ``subnet`` parameter + ``{network-role}_subnet_id`` + **MUST NOT** be enumerated in the + VNF's Heat Orchestration Template's Environment File. + + +.. container:: note + + :need:`R-15287` + + When the VNF's Heat Orchestration Template's + resource ``OS::Neutron::Port`` is attaching + to an external network (per the ONAP definition, see + Requirement R-57424), + and an IPv6 address is being cloud assigned by OpenStack's DHCP Service + and the external network IPv6 subnet is to be specified + using the property ``fixed_ips`` + map property ``subnet``, the parameter + **MUST** follow the naming convention + + * ``{network-role}_v6_subnet_id`` + + where + + * ``{network-role}`` is the network role of the network. + + +.. container:: note + + :need:`R-84123` + + When + + * the VNF's Heat Orchestration Template's + resource ``OS::Neutron::Port`` in an Incremental Module is attaching + to an internal network (per the ONAP definition, see + Requirements R-52425 and R-46461) + that is created in the Base Module, AND + * an IPv4 address is being cloud assigned by OpenStack's DHCP Service AND + * the internal network IPv4 subnet is to be specified + using the property ``fixed_ips`` map property ``subnet``, + + the parameter **MUST** follow the naming convention + + * ``int_{network-role}_subnet_id`` + + where + + * ``{network-role}`` is the network role of the internal network + + Note that the parameter **MUST** be defined as an ``output`` parameter in + the base module. + + +.. container:: note + + :need:`R-80829` + + The VNF's Heat Orchestration Template's Resource + ``OS::Neutron::Port`` property ``fixed_ips`` + map property ``subnet`` parameter + ``{network-role}_v6_subnet_id`` + **MUST NOT** be enumerated in the + VNF's Heat Orchestration Template's Environment File. + + +.. container:: note + + :need:`R-69634` + + The VNF's Heat Orchestration Template's Resource + ``OS::Neutron::Port`` property ``fixed_ips`` + map property ``subnet`` parameter + ``int_{network-role}_subnet_id`` + **MUST NOT** be enumerated in the + VNF's Heat Orchestration Template's Environment File. + + +.. container:: note + + :need:`R-62802` + + When the VNF's Heat Orchestration Template's + resource ``OS::Neutron::Port`` is attaching + to an external network (per the ONAP definition, see + Requirement R-57424), + and an IPv4 address is being cloud assigned by OpenStack's DHCP Service + and the external network IPv4 subnet is to be specified + using the property ``fixed_ips`` + map property ``subnet``, the parameter + **MUST** follow the naming convention + + * ``{network-role}_subnet_id`` + + where + + * ``{network-role}`` is the network role of the network. + + +Resource: OS::Neutron::Port - Parameters > Property: network +------------------------------------------------------------ + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-62983` + + When the VNF's Heat Orchestration Template's Resource + ``OS::Neutron::Port`` is attaching to an external network (per the + ONAP definition, see Requirement R-57424), the + ``network`` parameter name **MUST** + + * follow the naming convention ``{network-role}_net_id`` if the Neutron + network UUID value is used to reference the network + * follow the naming convention ``{network-role}_net_name`` if the + OpenStack network name is used to reference the network. + + where ``{network-role}`` is the network-role of the external network + and a ``get_param`` **MUST** be used as the intrinsic function. + + +.. container:: note + + :need:`R-93177` + + When the VNF's Heat Orchestration Template's resource + ``OS::Neutron::Port`` is attaching to an internal network (per the + ONAP definition, see Requirements R-52425 and R-46461), + and the internal network is created in the + same Heat Orchestration Template as the ``OS::Neutron::Port``, + the ``network`` property value **MUST** obtain the UUID + of the internal network by using the intrinsic function + ``get_resource`` + and referencing the Resource ID of the internal network. + + +.. container:: note + + :need:`R-29872` + + The VNF's Heat Orchestration Template's Resource ``OS::Neutron::Port`` + property ``network`` + parameter **MUST NOT** be enumerated in the Heat Orchestration + Template's Environment File. + + +.. container:: note + + :need:`R-86182` + + When the VNF's Heat Orchestration Template's Resource + ``OS::Neutron::Port`` is attaching to an internal network (per the + ONAP definition, see Requirements R-52425 and R-46461), + and the internal network is created in a + different Heat Orchestration Template than the ``OS::Neutron::Port``, + the ``network`` parameter name **MUST** + + * follow the naming convention ``int_{network-role}_net_id`` if the Neutron + network UUID value is used to reference the network + * follow the naming convention ``int_{network-role}_net_name`` if the + OpenStack network name in is used to reference the network. + + where ``{network-role}`` is the network-role of the internal network and + a ``get_param`` **MUST** be used as the intrinsic function. + + +Resource: OS::Nova::Server - Parameters +--------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-304011` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource's + + * Resource ID + * property ``image`` parameter name + * property ``flavor`` parameter name + * property ``name`` parameter name + + + **MUST** contain the identical ``{vm-type}`` + and **MUST** follow the naming conventions defined + in R-58670, R-45188, R-54171, R-87817, and R-29751. + + +Resource: OS::Nova::Server - Parameters > Property: Name +-------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-663631` + + The VNF's Heat Orchestration Template's Resource ``OS::Nova::Server`` + property ``name`` value **MUST** be be obtained via a ``get_param``. + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-51430` + + The VNF's Heat Orchestration Template's Resource ``OS::Nova::Server`` + property + ``name`` parameter **MUST** be declared as either type ``string`` + or type ``comma_delimited_list``. + + +.. container:: note + + :need:`R-54171` + + When the VNF's Heat Orchestration Template's Resource ``OS::Nova::Server`` + property ``name`` parameter is defined as a ``string``, + the parameter name **MUST** follow the naming convention + ``{vm-type}_name_{index}``, where ``{index}`` is a numeric + value that starts at + zero and increments by one. + + +.. container:: note + + :need:`R-40899` + + When the VNF's Heat Orchestration Template's Resource ``OS::Nova::Server`` + property ``name`` parameter is defined as a ``string``, a parameter + **MUST** be delcared for + each ``OS::Nova::Server`` resource associated with the ``{vm-type}``. + + +Resource: OS::Nova::Server - Parameters > Property: Name > Contrail Issue with Values for OS::Nova::Server Property Name +------------------------------------------------------------------------------------------------------------------------ + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-44271` + + The VNF's Heat Orchestration Template's Resource ``OS::Nova::Server`` + property + ``name`` parameter value **SHOULD NOT** contain special characters + since the Contrail GUI has a limitation displaying special characters. + + However, if special characters must be used, the only special characters + supported are: --- \" ! $ ' (\ \ ) = ~ ^ | @ ` { } [ ] > , . _ + + +Resource: OS::Nova::Server - Parameters > Property: availability_zone +--------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-01359` + + A VNF's Heat Orchestration Template that contains an ``OS::Nova:Server`` + Resource **MAY** define a parameter for the property + ``availability_zone`` that is not utilized in any ``OS::Nova::Server`` + resources in the Heat Orchestration Template. + + +.. container:: note + + :need:`R-98450` + + The VNF's Heat Orchestration Template's Resource ``OS::Nova::Server`` + property + ``availability_zone`` parameter name **MUST** follow the naming convention + ``availability_zone_{index}`` where the ``{index}`` + **MUST** start at zero and + increment by one. + + +Resource: OS::Nova::Server - Parameters > Property: flavor +---------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-481670` + + The VNF's Heat Orchestration Template's Resource ``OS::Nova::Server`` + property ``flavor`` value **MUST** be be obtained via a ``get_param``. + + +Resource: OS::Nova::Server - Parameters > Property: image +--------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-901331` + + The VNF's Heat Orchestration Template's Resource ``OS::Nova::Server`` + property ``image`` value **MUST** be be obtained via a ``get_param``. + + +Resource: OS::Nova::Server Metadata Parameters > environment_context +-------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-56183` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource + property ``metadata``key/value pair ``environment_context`` + parameter ``environment_context`` **MUST NOT** + have parameter constraints defined. + + +.. container:: note + + :need:`R-20308` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource + property ``metadata`` key/value pair ``environment_context`` + parameter **MUST** be declared as ``environment_context`` and the + parameter type **MUST** be defined as type: ``string``. + + +.. container:: note + + :need:`R-13194` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource + property + ``metadata`` key/value pair ``environment_context`` **MUST NOT** + be enumerated in the Heat Orchestration Template's environment file. + + +Resource: OS::Nova::Server Metadata Parameters > vf_module_id +------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-98374` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource property + ``metadata`` key/value pair ``vf_module_id`` parameter ``vf_module_id`` + **MUST NOT** + have parameter constraints defined. + + +.. container:: note + + :need:`R-71493` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource + property ``metadata`` **MUST** + contain the key/value pair ``vf_module_id`` + and the value MUST be obtained via a ``get_param``. + + +.. container:: note + + :need:`R-72871` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource property + ``metadata`` key/value pair ``vf_module_id`` parameter ``vf_module_id`` + **MUST NOT** + be enumerated in the Heat Orchestration Template's environment file. + + +.. container:: note + + :need:`R-86237` + + If a VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource + property + ``metadata`` key/value pair ``vf_module_id`` is passed into a + Nested YAML + file, the key/value pair name ``vf_module_id`` **MUST NOT** change. + + +.. container:: note + + :need:`R-82134` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource property + ``metadata`` key/value pair ``vf_module_id`` parameter **MUST** + be declared as ``vf_module_id`` and the parameter **MUST** + be defined as type: ``string``. + + +Resource: OS::Nova::Server Metadata Parameters > vf_module_index +---------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-37039` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource + property + ``metadata`` key/value pair ``vf_module_index`` parameter + ``vf_module_index`` **MUST NOT** + be enumerated in the Heat Orchestration Template's environment file. + + +.. container:: note + + :need:`R-50816` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` + resource property ``metadata`` **MAY** + contain the key/value pair ``vf_module_index`` + and the value **MUST** be obtained via a ``get_param``. + + +.. container:: note + + :need:`R-09811` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource + property ``metadata`` key/value pair ``vf_module_index`` **MUST NOT** + have parameter constraints defined. + + +.. container:: note + + :need:`R-55306` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource + property ``metadata`` key/value pair ``vf_module_index`` **MUST NOT** + be used in a ``OS::Cinder::Volume`` resource and **MUST NOT** be + used in VNF's Volume template; + it is not supported. + + +.. container:: note + + :need:`R-54340` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource + property + ``metadata`` key/value pair ``vf_module_index`` parameter **MUST** + be declared as ``vf_module_index`` and the parameter **MUST** be + defined as type: ``number``. + + +.. container:: note + + :need:`R-22441` + + If a VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource + property ``metadata`` key/value pair ``vf_module_index`` is passed into a + Nested YAML file, the key/value pair + ``vf_module_index`` **MUST NOT** change. + + +Resource: OS::Nova::Server Metadata Parameters > vf_module_name +--------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-15480` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource + property + ``metadata`` key/value pair ``vf_module_name`` parameter ``vf_module_name`` + **MUST NOT** have parameter constraints defined. + + +.. container:: note + + :need:`R-80374` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource + property ``metadata`` key/value pair ``vf_module_name`` + parameter ``vf_module_name`` **MUST NOT** + be enumerated in the Heat Orchestration Template's environment file. + + +.. container:: note + + :need:`R-39067` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource + property + ``metadata`` key/value pair ``vf_module_name`` parameter **MUST** be + declared as ``vf_module_name`` and the parameter **MUST** + be defined as type: ``string``. + + +.. container:: note + + :need:`R-68023` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource + property ``metadata`` **SHOULD** + contain the key/value pair ``vf_module_name`` and the value **MUST** + be obtained via a ``get_param``. + + +.. container:: note + + :need:`R-49177` + + If a VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource + property ``metadata`` key/value pair ``vf_module_name`` is passed into a + Nested YAML + file, the key/value pair name ``vf_module_name`` **MUST NOT** change. + + +Resource: OS::Nova::Server Metadata Parameters > vm_role +-------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-67597` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource + property ``metadata`` key/value pair ``vm_role`` parameter ``vm_role`` + **MUST NOT** have parameter constraints defined. + + +.. container:: note + + :need:`R-86476` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource + property ``metadata`` key/value pair ``vm_role`` value **MUST** + only contain alphanumeric characters and underscores (i.e., '_'). + + +.. container:: note + + :need:`R-70757` + + If a VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource + property ``metadata`` key/value pair ``vm_role`` is passed into a Nested + YAML + file, the key/value pair name ``vm_role`` **MUST NOT** change. + + +.. container:: note + + :need:`R-95430` + + If a VNF's Heat Orchestration Template's ``OS::Nova::Server`` + resource property + ``metadata`` key/value pair ``vm_role`` value is obtained via + ``get_param``, the parameter **MUST** be declared as ``vm_role`` + and the parameter **MUST** be defined as type: ``string``. + + +.. container:: note + + :need:`R-85328` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource property + ``metadata`` **MAY** + contain the key/value pair ``vm_role`` and the value **MUST** be + obtained either via + + - ``get_param`` + - hard coded in the key/value pair ``vm_role``. + + +Resource: OS::Nova::Server Metadata Parameters > vnf_id +------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-55218` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` + resource property + ``metadata`` key/value pair ``vnf_id`` parameter ``vnf_id`` **MUST NOT** + have parameter constraints defined. + + +.. container:: note + + :need:`R-37437` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` + resource property ``metadata`` **MUST** + contain the key/value pair ``vnf_id`` + and the value **MUST** be obtained via a ``get_param``. + + +.. container:: note + + :need:`R-44491` + + If a VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource + property + ``metadata`` key/value pair ``vnf_id`` is passed into a Nested YAML + file, the key/value pair name ``vnf_id`` **MUST NOT** change. + + +.. container:: note + + :need:`R-07507` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` + resource property + ``metadata`` key/value pair ``vnf_id`` parameter + **MUST** be declared as ``vnf_id`` and the parameter **MUST** + be defined as type: ``string``. + + +.. container:: note + + :need:`R-20856` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` + resource property + ``metadata`` key/value pair ``vnf_id`` parameter ``vnf_id`` **MUST NOT** + be enumerated in the Heat Orchestration Template's environment file. + + +Resource: OS::Nova::Server Metadata Parameters > vnf_name +--------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-36542` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource + property ``metadata`` key/value pair ``vnf_name`` parameter + ``vnf_name`` **MUST NOT** + be enumerated in the Heat Orchestration Template's environment file. + + +.. container:: note + + :need:`R-16576` + + If a VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource + property + ``metadata`` key/value pair ``vnf_name`` is passed into a Nested YAML + file, the key/value pair name ``vnf_name`` **MUST NOT** change. + + +.. container:: note + + :need:`R-44318` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource + property ``metadata`` key/value pair ``vnf_name`` + parameter ``vnf_name`` **MUST NOT** + have parameter constraints defined. + + +.. container:: note + + :need:`R-72483` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource property + ``metadata`` **MUST** contain the key/value pair ``vnf_name`` and the + value **MUST** be obtained via a ``get_param``. + + +.. container:: note + + :need:`R-62428` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource + property ``metadata`` key/value pair ``vnf_name`` parameter **MUST** + be declared as ``vnf_name`` and the parameter **MUST** be defined as + type: ``string``. + + +Resource: OS::Nova::Server Metadata Parameters > workload_context +----------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-34055` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource + property ``metadata`` key/value pair ``workload_context`` + parameter ``workload_context`` **MUST NOT** + have parameter constraints defined. + + +.. container:: note + + :need:`R-75202` + + If a VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource + property ``metadata`` key/value pair ``workload_context`` + is passed into a Nested YAML + file, the key/value pair name ``workload_context`` **MUST NOT** change. + + +.. container:: note + + :need:`R-74978` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource + property ``metadata`` key/value pair ``workload_context`` + parameter **MUST** + be declared as ``workload_context`` and the parameter **MUST** + be defined as type: ``string``. + + +.. container:: note + + :need:`R-02691` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource + property ``metadata`` key/value pair ``workload_context`` + parameter ``workload_context`` **MUST NOT** + be enumerated in the Heat Orchestration Template's environment file. + + +VNF On-boarding and package management > Resource Description +------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-22346` + + The VNF package MUST provide `VES Event Registration <https://onap.readthedocs.io/en/latest/submodules/vnfsdk/model.git/docs/files/VESEventRegistration.html>`_ for all VES events provided by that xNF. + + +VNF On-boarding and package management > Testing +------------------------------------------------ + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-43958` + + The xNF Package **MUST** include documentation describing + the tests that were conducted by the xNF provider and the test results. + + +VNF Resiliency > Virtual Function - Container Recovery Requirements +------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-46851` + + The VNF **MUST** support ONAP Controller's Evacuate command. + + +.. container:: note + + :need:`R-48761` + + The VNF **MUST** support ONAP Controller's Snapshot command. + + +VNF Security > VNF API Security Requirements +-------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-21210` + + The VNF **MUST** implement the following input validation control + on APIs: Validate that any input file has a correct and valid + Multipurpose Internet Mail Extensions (MIME) type. Input files + should be tested for spoofed MIME types. + + +.. container:: note + + :need:`R-54930` + + The VNF **MUST** implement the following input validation controls: + Do not permit input that contains content or characters inappropriate + to the input expected by the design. Inappropriate input, such as + SQL expressions, may cause the system to execute undesirable and + unauthorized transactions against the database or allow other + inappropriate access to the internal network (injection attacks). + + +.. container:: note + + :need:`R-43884` + + The VNF **SHOULD** integrate with the Operator's authentication and + authorization services (e.g., IDAM). + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-02137 + + The VNF **MUST** implement all monitoring and logging as + described in the Security Analytics section. + + +.. container:: note + + R-15659 + + The VNF **MUST** restrict changing the criticality level of + a system security alarm to administrator(s). + + +.. container:: note + + R-19367 + + The VNF **MUST** monitor API invocation patterns to detect + anomalous access patterns that may represent fraudulent access or + other types of attacks, or integrate with tools that implement anomaly + and abuse detection. + + +.. container:: note + + R-19804 + + The VNF **MUST** validate the CA signature on the certificate, + ensure that the date is within the validity period of the certificate, + check the Certificate Revocation List (CRL), and recognize the identity + represented by the certificate where PKI-based authentication is used. + + +.. container:: note + + R-23772 + + The VNF **MUST** validate input at all layers implementing VNF APIs. + + +.. container:: note + + R-25878 + + The VNF **MUST** use certificates issued from publicly + recognized Certificate Authorities (CA) for the authentication process + where PKI-based authentication is used. + + +.. container:: note + + R-37608 + + The VNF **MUST** provide a mechanism to restrict access based + on the attributes of the VNF and the attributes of the subject. + + +.. container:: note + + R-78066 + + The VNF **MUST** support requests for information from law + enforcement and government agencies. + + +.. container:: note + + R-87135 + + The VNF **MUST** comply with NIST standards and industry + best practices for all implementations of cryptography. + + +VNF Security > VNF Cryptography Requirements +-------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-49109` + + The VNF **MUST** support HTTP/S using TLS v1.2 or higher + with strong cryptographic ciphers. + + +.. container:: note + + :need:`R-48080` + + The VNF **SHOULD** support an automated certificate management protocol + such as CMPv2, Simple Certificate Enrollment Protocol (SCEP) or + Automated Certificate Management Environment (ACME). + + +.. container:: note + + :need:`R-93860` + + The VNF **SHOULD** provide the capability to integrate with an + external encryption service. + + +VNF Security > VNF Data Protection Requirements +----------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-58964` + + The VNF **MUST** provide the capability to restrict read + and write access to data handled by the VNF. + + +.. container:: note + + :need:`R-95864` + + The VNF **MUST** support digital certificates that comply with X.509 + standards. + + +.. container:: note + + :need:`R-69610` + + The VNF **MUST** provide the capability of using X.509 certificates + issued by an external Certificate Authority. + + +.. container:: note + + :need:`R-73067` + + The VNF **MUST** use NIST and industry standard cryptographic + algorithms and standard modes of operations when implementing + cryptography. + + +.. container:: note + + :need:`R-32641` + + The VNF **MUST** provide the capability to encrypt data on + non-volatile memory.Non-volative memory is storage that is + capable of retaining data without electrical power, e.g. + Complementary metal-oxide-semiconductor (CMOS) or hard drives. + + +.. container:: note + + :need:`R-70933` + + The VNF **MUST** provide the ability to migrate to newer + versions of cryptographic algorithms and protocols with minimal impact. + + +.. container:: note + + :need:`R-12467` + + The VNF **MUST NOT** use compromised encryption algorithms. + For example, SHA, DSS, MD5, SHA-1 and Skipjack algorithms. + Acceptable algorithms can be found in the NIST FIPS publications + (https://csrc.nist.gov/publications/fips) and in the + NIST Special Publications (https://csrc.nist.gov/publications/sp). + + +.. container:: note + + :need:`R-02170` + + The VNF **MUST** use, whenever possible, standard implementations + of security applications, protocols, and formats, e.g., S/MIME, TLS, SSH, + IPSec, X.509 digital certificates for cryptographic implementations. + These implementations must be purchased from reputable vendors or obtained + from reputable open source communities and must not be developed in-house. + + +.. container:: note + + :need:`R-47204` + + The VNF **MUST** be capable of protecting the confidentiality and integrity + of data at rest and in transit from unauthorized access and modification. + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-22645 + + The VNF **SHOULD** use commercial algorithms only when there + are no applicable governmental standards for specific cryptographic + functions, e.g., public key cryptography, message digests. + + +.. container:: note + + R-99112 + + The VNF **MUST** provide the capability to restrict access + to data to specific users. + + +VNF Security > VNF General Security Requirements +------------------------------------------------ + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-638682` + + The VNF **MUST** log any security event required by the VNF Requirements to + Syslog using LOG_AUTHPRIV for any event that would contain sensitive + information and LOG_AUTH for all other relevant events. + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-21819` + + The VNF **MUST** provide functionality that enables the Operator to comply + with requests for information from law enforcement and government agencies. + + +.. container:: note + + :need:`R-23882` + + The VNF **SHOULD** provide the capability for the Operator to run security + vulnerability scans of the operating system and all application layers. + + +.. container:: note + + :need:`R-92207` + + The VNF **SHOULD** provide a mechanism for performing automated + system configuration auditing at configurable time intervals. + + +.. container:: note + + :need:`R-19082` + + The VNF **MUST** allow the Operator to disable or remove any security + testing tools or programs included in the VNF, e.g., password cracker, + port scanner. + + +.. container:: note + + :need:`R-40813` + + The VNF **SHOULD** support the use of virtual trusted platform + module. + + +.. container:: note + + :need:`R-61354` + + The VNF **MUST** provide a mechanism (e.g., access control list) to + permit and/or restrict access to services on the VNF by source, + destination, protocol, and/or port. + + +.. container:: note + + :need:`R-19768` + + The VNF **SHOULD** support Layer 3 VPNs that enable segregation of + traffic by application (i.e., AVPN, IPSec VPN for Internet routes). + + +.. container:: note + + :need:`R-69649` + + The VNF Provider **MUST** have patches available for vulnerabilities + in the VNF as soon as possible. Patching shall be controlled via change + control process with vulnerabilities disclosed along with + mitigation recommendations. + + +.. container:: note + + :need:`R-99771` + + The VNF **MUST** have all code (e.g., QCOW2) and configuration files + (e.g., HEAT template, Ansible playbook, script) hardened, or with + documented recommended configurations for hardening and interfaces that + allow the Operator to harden the VNF. Actions taken to harden a system + include disabling all unnecessary services, and changing default values + such as default credentials and community strings. + + +.. container:: note + + :need:`R-23740` + + The VNF **MUST** implement and enforce the principle of least privilege + on all protected interfaces. + + +.. container:: note + + :need:`R-62498` + + The VNF **MUST** support encrypted access protocols, e.g., TLS, + SSH, SFTP. + + +.. container:: note + + :need:`R-80335` + + For all GUI and command-line interfaces, the VNF **MUST** provide the + ability to present a warning notice that is set by the Operator. A warning + notice is a formal statement of resource intent presented to everyone + who accesses the system. + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-26586 + + The VNF **SHOULD** support the ability to work with aliases + (e.g., gateways, proxies) to protect and encapsulate resources. + + +.. container:: note + + R-33981 + + The VNF **SHOULD** interoperate with various access control + mechanisms for the Network Cloud execution environment (e.g., + Hypervisors, containers). + + +.. container:: note + + R-39342 + + The VNF **MUST**, if not using the NCSP's IDAM API, comply + with "password changes (includes default passwords)" policy. Products + will support password aging, syntax and other credential management + practices on a configurable basis. + + +.. container:: note + + R-40521 + + The VNF **MUST**, if not using the NCSP's IDAM API, support + use of common third party authentication and authorization tools such + as TACACS+, RADIUS. + + +.. container:: note + + R-42681 + + The VNF **MUST** use the NCSP's IDAM API or comply with + the requirements if not using the NCSP's IDAM API, for identification, + authentication and access control of OA&M and other system level + functions. + + +.. container:: note + + R-49956 + + The VNF **MUST** pass all access to applications (Bearer, + signaling and OA&M) through various security tools and platforms from + ACLs, stateful firewalls and application layer gateways depending on + manner of deployment. The application is expected to function (and in + some cases, interwork) with these security tools. + + +.. container:: note + + R-52085 + + The VNF **MUST**, if not using the NCSP's IDAM API, provide + the ability to support Multi-Factor Authentication (e.g., 1st factor = + Software token on device (RSA SecureID); 2nd factor = User Name+Password, + etc.) for the users. + + +.. container:: note + + R-55830 + + The VNF **MUST** distribute all production code from NCSP + internal sources only. No production code, libraries, OS images, etc. + shall be distributed from publically accessible depots. + + +.. container:: note + + R-63217 + + The VNF **MUST**, if not using the NCSP's IDAM API, support + logging via ONAP for a historical view of "who did what and when." + + +.. container:: note + + R-68589 + + The VNF **MUST**, if not using the NCSP's IDAM API, support + User-IDs and passwords to uniquely identify the user/application. VNF + needs to have appropriate connectors to the Identity, Authentication + and Authorization systems that enables access at OS, Database and + Application levels as appropriate. + + +.. container:: note + + R-85633 + + The VNF **MUST** implement Data Storage Encryption + (database/disk encryption) for Sensitive Personal Information (SPI) + and other subscriber identifiable data. + + Note: Subscribers SPI/data must be encrypted at rest, and other + subscriber identifiable data should be encrypted at rest. Other + data protection requirements exist and should be well understood + by the developer. + + +VNF Security > VNF Identity and Access Management Requirements +-------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-59391` + + The VNF **MUST NOT** not allow the assumption of the permissions of + another account to mask individual accountability. + + +.. container:: note + + :need:`R-15671` + + The VNF **MUST** provide access controls that allow the Operator + to restrict access to VNF functions and data to authorized entities. + + +.. container:: note + + :need:`R-75041` + + The VNF **MUST**, if not integrated the Operator's Identity and Access + Management system, support configurable password expiration. + + +.. container:: note + + :need:`R-99174` + + The VNF **MUST** allow the creation of multiple IDs so that + individual accountability can be supported. + + +.. container:: note + + :need:`R-23135` + + The VNF **MUST** authenticate all access to protected GUIs, CLIs, + and APIs. + + +.. container:: note + + :need:`R-46908` + + The VNF **MUST**, if not integrated with the Operator's Identity + and Access Management system, comply with "password complexity" + policy. When passwords are used, they shall be complex and shall at + least meet the following password construction requirements: (1) be a + minimum configurable number of characters in length, (2) include 3 of + the 4 following types of characters: upper-case alphabetic, lower-case + alphabetic, numeric, and special, (3) not be the same as the UserID + with which they are associated or other common strings as specified + by the environment, (4) not contain repeating or sequential characters + or numbers, (5) not to use special characters that may have command + functions, and (6) new passwords must not contain sequences of three + or more characters from the previous password. + + +.. container:: note + + :need:`R-42874` + + The VNF **MUST** allow the Operator to restrict access based on + the assigned permissions associated with an ID in order to support + Least Privilege (no more privilege than required to perform job + functions). + + +.. container:: note + + :need:`R-98391` + + The VNF **MUST**, if not integrated with the Operator's Identity and + Access Management system, support Role-Based Access Control to enforce + least privilege. + + +.. container:: note + + :need:`R-71787` + + Each layer of the VNF **MUST** support access restriction + independently of all other layers so that Segregation of Duties + can be implemented. + + +.. container:: note + + :need:`R-79107` + + The VNF **MUST**, if not integrated with the Operator's Identity + and Access Management system, support the ability to disable the + userID after a configurable number of consecutive unsuccessful + authentication attempts using the same userID. + + +.. container:: note + + :need:`R-86835` + + The VNF **MUST** set the default settings for user access + to deny authorization, except for a super user type of account. + When a VNF is added to the network, nothing should be able to use + it until the super user configures the VNF to allow other users + (human and application) have access. + + +.. container:: note + + :need:`R-85419` + + The VNF **SHOULD** support OAuth 2.0 authorization using an external + Authorization Server. + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-05470 + + The VNF **MUST** host connectors for access to the database layer. + + +.. container:: note + + R-14025 + + The VNF **MUST** provide or support the Identity and Access + Management (IDAM) based threat detection data for Session Hijacking. + + +.. container:: note + + R-19790 + + The VNF **MUST NOT** include authentication credentials + in security audit logs, even if encrypted. + + +.. container:: note + + R-24825 + + The VNF **MUST** provide Context awareness data (device, + location, time, etc.) and be able to integrate with threat detection system. + + +.. container:: note + + R-29301 + + The VNF **MUST** provide or support the Identity and Access + Management (IDAM) based threat detection data for Password Attacks. + + +.. container:: note + + R-31412 + + The VNF **MUST** provide or support the Identity and Access + Management (IDAM) based threat detection data for XSS / CSRF. + + +.. container:: note + + R-31751 + + The VNF **MUST** subject VNF provider access to privilege + reconciliation tools to prevent access creep and ensure correct + enforcement of access policies. + + +.. container:: note + + R-44032 + + The VNF **MUST** provide or support the Identity and Access + Management (IDAM) based threat detection data for Man in the Middle (MITM). + + +.. container:: note + + R-45496 + + The VNF **MUST** host connectors for access to the OS (Operating System) layer. + + +.. container:: note + + R-49945 + + The VNF **MUST** authorize VNF provider access through a + client application API by the client application owner and the resource + owner of the VNF before provisioning authorization through Role Based + Access Control (RBAC), Attribute Based Access Control (ABAC), or other + policy based mechanism. + + +.. container:: note + + R-51883 + + The VNF **MUST** provide or support the Identity and Access + Management (IDAM) based threat detection data for Replay. + + +.. container:: note + + R-58977 + + The VNF **MUST** provide or support the Identity and Access + Management (IDAM) based threat detection data for Eavesdropping. + + +.. container:: note + + R-58998 + + The VNF **MUST** provide or support the Identity and Access + Management (IDAM) based threat detection data for Malware (Key Logger). + + +.. container:: note + + R-72243 + + The VNF **MUST** provide or support the Identity and Access + Management (IDAM) based threat detection data for Phishing / SMishing. + + +.. container:: note + + R-73541 + + The VNF **MUST** use access controls for VNFs and their + supporting computing systems at all times to restrict access to + authorized personnel only, e.g., least privilege. These controls + could include the use of system configuration or access control + software. + + +.. container:: note + + R-77157 + + The VNF **MUST** conform to approved request, workflow + authorization, and authorization provisioning requirements when + creating privileged users. + + +.. container:: note + + R-85028 + + The VNF **MUST** authenticate system to system access and + do not conceal a VNF provider user's individual accountability for + transactions. + + +.. container:: note + + R-89753 + + The VNF **MUST NOT** install or use systems, tools or + utilities capable of capturing or logging data that was not created + by them or sent specifically to them in production, without + authorization of the VNF system owner. + + +.. container:: note + + R-95105 + + The VNF **MUST** host connectors for access to the application layer. + + +VNF Security > VNF Security Analytics Requirements +-------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-74958` + + The VNF **MUST** activate security alarms automatically when + it detects an unsuccessful attempt to gain permissions + or assume the identity of another user. + + +.. container:: note + + :need:`R-29705` + + The VNF **MUST** restrict changing the criticality level of a + system security alarm to users with administrative privileges. + + +.. container:: note + + :need:`R-43332` + + The VNF **MUST** activate security alarms automatically when + it detects the successful modification of a critical system or + application file. + + +.. container:: note + + :need:`R-41825` + + The VNF **MUST** activate security alarms automatically when + a configurable number of consecutive unsuccessful login attempts + is reached. + + +.. container:: note + + :need:`R-94525` + + The VNF **MUST** log connections to the network listeners of the + resource. + + +.. container:: note + + :need:`R-04492` + + The VNF **MUST** generate security audit logs that can be sent + to Security Analytics Tools for analysis. + + +.. container:: note + + :need:`R-07617` + + The VNF **MUST** log success and unsuccessful creation, removal, or + change to the inherent privilege level of users. + + +.. container:: note + + :need:`R-34552` + + The VNF **MUST** be implemented so that it is not vulnerable to OWASP + Top 10 web application security risks. + + +.. container:: note + + :need:`R-58370` + + The VNF **MUST** operate with anti-virus software which produces + alarms every time a virus is detected. + + +.. container:: note + + :need:`R-63330` + + The VNF **MUST** detect when its security audit log storage + medium is approaching capacity (configurable) and issue an alarm. + + +.. container:: note + + :need:`R-54520` + + The VNF **MUST** log successful and unsuccessful authentication + attempts, e.g., authentication associated with a transaction, + authentication to create a session, authentication to assume elevated + privilege. + + +.. container:: note + + :need:`R-30932` + + The VNF **MUST** log successful and unsuccessful access to VNF + resources, including data. + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-08598 + + The VNF **MUST** log successful and unsuccessful changes to a privilege level. + + +.. container:: note + + R-19219 + + The VNF **MUST** provide audit logs that include user ID, dates, + times for log-on and log-off, and terminal location at minimum. + + +.. container:: note + + R-20912 + + The VNF **MUST** support alternative monitoring capabilities + when VNFs do not expose data or control traffic or use proprietary and + optimized protocols for inter VNF communication. + + +.. container:: note + + R-25094 + + The VNF **MUST** perform data capture for security functions. + + +.. container:: note + + R-31961 + + The VNF **MUST** support integrated DPI/monitoring functionality + as part of VNFs (e.g., PGW, MME). + + +.. container:: note + + R-56786 + + The VNF **MUST** implement "Closed Loop" automatic implementation + (without human intervention) for Known Threats with detection rate in low + false positives. + + +.. container:: note + + R-57271 + + The VNF **MUST** provide the capability of generating security + audit logs by interacting with the operating system (OS) as appropriate. + + +.. container:: note + + R-61648 + + The VNF **MUST** support event logging, formats, and delivery + tools to provide the required degree of event data to ONAP. + + +{network-role} +-------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-96983` + + A VNF's Heat Orchestration Template's Resource ID that is associated + with an internal network **MUST** include ``int_{network-role}`` as part + of the Resource ID, where ``int_`` is a hard coded string. + + +.. container:: note + + :need:`R-26506` + + A VNF's Heat Orchestration Template's ``{network-role}`` **MUST** contain + only alphanumeric characters and/or underscores '_' and + **MUST NOT** contain any of the following strings: + ``_int`` or ``int_`` or ``_int_``. + + +.. container:: note + + :need:`R-84322` + + A VNF's Heat Orchestration Template's Resource property parameter that + is associated with an internal network **MUST** include + ``int_{network-role}`` as part of the parameter name, + where ``int_`` is a hard coded string. + + +{vm-type} +--------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-01455` + + When a VNF's Heat Orchestration Template creates a Virtual Machine + (i.e., ``OS::Nova::Server``), + each "class" of VMs **MUST** be assigned a VNF unique + ``{vm-type}``; where "class" defines VMs that + **MUST** have the following identical characteristics: + + 1.) ``OS::Nova::Server`` resource property ``flavor`` value + + 2.) ``OS::Nova::Server`` resource property ``image`` value + + 3.) Cinder Volume attachments + + - Each VM in the "class" **MUST** have the identical Cinder Volume + configuration + + 4.) Network attachments and IP address requirements + + - Each VM in the "class" **MUST** have the the identical number of + ports connecting to the identical networks and requiring the identical + IP address configuration. + + +.. container:: note + + :need:`R-82481` + + A VNF's Heat Orchestration Template's Resource property parameter that is + associated with a unique Virtual Machine type **MUST** include + ``{vm-type}`` as part of the parameter name with two exceptions: + + 1.) The Resource ``OS::Nova::Server`` property ``availability_zone`` + parameter **MUST NOT** be prefixed with a common ``{vm-type}`` identifier, + + 2.) The Resource ``OS::Nova::Server`` eight mandatory and optional + ``metadata`` + parameters (i.e., ``vnf_name``, ``vnf_id``, ``vf_module_id``, + ``vf_module_name``, ``vm_role``, + ``vf_module_index``, ``environment_context``, ``workload_context``) + **MUST NOT** be prefixed with a common ``{vm-type}`` identifier. + + +.. container:: note + + :need:`R-98407` + + A VNF's Heat Orchestration Template's ``{vm-type}`` **MUST** contain only + alphanumeric characters and/or underscores '_' and **MUST NOT** + contain any of the following strings: + ``_int`` or ``int_`` or ``_int_``. + |