diff options
| author |   Hagop Bozawglanian <hagop.bozawglanian@att.com> | 2019-05-29 14:38:49 -0700 |
|---|---|---|
| committer | Hagop Bozawglanian <hagop.bozawglanian@att.com> | 2019-05-29 14:38:49 -0700 |
| commit | ad0e89a88920277386971e7945ede8bab0503967 (patch) | |
| tree | 756eccc21896e6ef823f7e340a047adfd0dcf87a | |
| parent | 6441ccbf69a50f6ea5eff890962215c00b0eefdf (diff) | |
VNFRQTS - Update release notesdublin
Issue-ID: VNFRQTS-621
Signed-off-by: Hagop Bozawglanian <hagop.bozawglanian@att.com>
Change-Id: Ibf41a5f88397ad92db172122015bf4421701ec39
| -rw-r--r-- | docs/Chapter5/Heat/ONAP Heat Orchestration Templates Overview.rst | 6 | ||||
| -rw-r--r-- | docs/Chapter5/Heat/ONAP Heat Template Constructs.rst | 3 | ||||
| -rw-r--r-- | docs/changes-by-section-dublin.rst | 5758 | ||||
| -rw-r--r-- | docs/release-notes.rst | 48 |
4 files changed, 5810 insertions, 5 deletions
diff --git a/docs/Chapter5/Heat/ONAP Heat Orchestration Templates Overview.rst b/docs/Chapter5/Heat/ONAP Heat Orchestration Templates Overview.rst index d7511a1..7e55487 100644 --- a/docs/Chapter5/Heat/ONAP Heat Orchestration Templates Overview.rst +++ b/docs/Chapter5/Heat/ONAP Heat Orchestration Templates Overview.rst @@ -264,7 +264,7 @@ Base Modules :target: VNF :keyword: MUST :validation_mode: static - :updated: casablanca + :updated: dublin A VNF Heat Orchestration Template's Base Module file name **MUST** include case insensitive 'base' in the filename and @@ -302,7 +302,7 @@ Incremental Modules :target: VNF :keyword: MUST :validation_mode: static - :updated: casablanca + :updated: dublin VNF Heat Orchestration Template's Incremental Module file name **MUST** contain only alphanumeric characters and underscores @@ -381,7 +381,7 @@ Nested Heat file :target: VNF :keyword: MUST :validation_mode: static - :updated: casablanca + :updated: dublin VNF Heat Orchestration Template's Nested YAML file name **MUST** contain only alphanumeric characters and underscores '_' and diff --git a/docs/Chapter5/Heat/ONAP Heat Template Constructs.rst b/docs/Chapter5/Heat/ONAP Heat Template Constructs.rst index ea87248..16a2118 100644 --- a/docs/Chapter5/Heat/ONAP Heat Template Constructs.rst +++ b/docs/Chapter5/Heat/ONAP Heat Template Constructs.rst @@ -87,8 +87,7 @@ the second level of nested heat. .. req:: :id: R-708564 :keyword: MUST NOT - :introduced: casablanca - :updated: dublin + :introduced: dublin :validation_mode: static diff --git a/docs/changes-by-section-dublin.rst b/docs/changes-by-section-dublin.rst new file mode 100644 index 0000000..fde3fa8 --- /dev/null +++ b/docs/changes-by-section-dublin.rst @@ -0,0 +1,5758 @@ +.. 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 Dublin +======================================================== + +This document summarizes the requirement changes by section that were +introduced between the Casablanca release and +Dublin release. Click on the requirement number to +navigate to the + +.. contents:: + :depth: 2 + +Summary of Changes +------------------ + +* **Requirements Added:** 64 +* **Requirements Changed:** 275 +* **Requirements Removed:** 40 + + +Configuration Management > Ansible Standards and Capabilities > VNF or PNF Configuration via Ansible Requirements > Ansible Client Requirements +----------------------------------------------------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-94567` + + The VNF or PNF **MUST** provide Ansible playbooks that are designed to run + using an inventory hosts file in a supported format with only IP addresses + or IP addresses and VM/VNF or PNF names. + + +.. container:: note + + :need:`R-82018` + + The VNF or PNF **MUST** load the Ansible Server SSH public key onto VNF or + PNF VM(s) /root/.ssh/authorized_keys as part of instantiation. Alternative, + is for Ansible Server SSH public key to be loaded onto VNF or PNF VM(s) + under /home/<Mechanized user ID>/.ssh/authorized_keys as part of + instantiation, when a Mechanized user ID is created during instantiation, + and Configure and all playbooks are designed to use a mechanized user ID + only for authentication (never using root authentication during Configure + playbook run). This will allow the Ansible Server to authenticate to + perform post-instantiation configuration without manual intervention and + without requiring specific VNF or PNF login IDs and passwords. + + *CAUTION*: For VNFs or PNFs configured using Ansible, to eliminate the need + for manual steps, post-instantiation and pre-configuration, to + upload of SSH public keys, SSH public keys loaded during (heat) + instantiation shall be preserved and not removed by (heat) embedded + (userdata) scripts. + + +.. container:: note + + :need:`R-35401` + + The VNF or PNF **MUST** support SSH and allow SSH access by the + Ansible server to the endpoint VM(s) and comply with the Network + Cloud Service Provider guidelines for authentication and access. + + +.. container:: note + + :need:`R-97451` + + The VNF or PNF **MUST** provide the ability to remove root access once + post-instantiation configuration (Configure) is completed. + + +.. container:: note + + :need:`R-45197` + + The VNF or PNF **MUST** define the "from=" clause to provide the list of IP + addresses of the Ansible Servers in the Cluster, separated by coma, to + restrict use of the SSH key pair to elements that are part of the Ansible + Cluster owner of the issued and assigned mechanized user ID. + + +.. container:: note + + :need:`R-73459` + + The VNF or PNF **MUST** provide the ability to include a "from=" clause in + SSH public keys associated with mechanized user IDs created for an Ansible + Server cluster to use for VNF or PNF VM authentication. + + +.. container:: note + + :need:`R-97345` + + The VNF or PNF **MUST** permit authentication, using root account, only + right after instantiation and until post-instantiation configuration is + completed. + + +.. container:: note + + :need:`R-92866` + + The VNF or PNF **MUST** include as part of post-instantiation configuration + done by Ansible Playbooks the removal/update of the SSH public key from + /root/.ssh/authorized_keys, and update of SSH keys loaded through + instantiation to support Ansible. This may include creating Mechanized user + ID(s) used by the Ansible Server(s) on VNF VM(s) and uploading and + installing new SSH keys used by the mechanized use ID(s). + + +.. container:: note + + :need:`R-67124` + + The VNF or PNF **MUST** provide Ansible playbooks that are designed to run + using an inventory hosts file in a supported format; with group names + matching VNFC 3-character string adding "vip" for groups with virtual IP + addresses shared by multiple VMs as seen in examples provided in Appendix. + + +.. container:: note + + :need:`R-32217` + + The VNF or PNF **MUST** have routable management IP addresses or FQDNs that + are reachable via the Ansible Server for the endpoints (VMs) of a + VNF or PNF that playbooks will target. ONAP will initiate requests to the + Ansible Server for invocation of playbooks against these end + points [#7.3.3]_. + + +.. container:: note + + :need:`R-54373` + + The VNF or PNF **MUST** have Python >= 2.6 on the endpoint VM(s) + of a VNF or PNF on which an Ansible playbook will be executed. + + +.. container:: note + + :need:`R-24482` + + The VNF or PNF **MUST** provide Ansible playbooks that are designed to run + using an inventory hosts file in a supported format; with site group that + shall be used to add site specific configurations to the target VNF or PNF + VM(s) as needed. + + +.. container:: note + + :need:`R-91745` + + The VNF or PNF **MUST** update the Ansible Server and other entities + storing and using the SSH keys for authentication when the SSH + keys used by Ansible are regenerated/updated. + + **Note**: Ansible Server itself may be used to upload new SSH public + keys onto supported VNFs or PNFs. + + +Configuration Management > Ansible Standards and Capabilities > VNF or PNF Configuration via Ansible Requirements > Ansible Playbook Requirements +------------------------------------------------------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-49911` + + The VNF or PNF provider **MUST** assign a new point release to the updated + playbook set. The functionality of a new playbook set must be tested before + it is deployed to the production. + + +.. container:: note + + :need:`R-58301` + + The VNF or PNF **SHOULD NOT** use playbooks that make requests to + Cloud resources e.g. Openstack (nova, neutron, glance, heat, etc.); + therefore, there is no use for Cloud specific variables like Openstack + UUIDs in Ansible Playbook related artifacts. + + **Rationale**: Flows that require interactions with Cloud services e.g. + Openstack shall rely on workflows run by an Orchestrator + (Change Management) or other capability (such as a control loop or + Operations GUI) outside Ansible Server which can be executed by a + APPC/SDN-C. There are policies, as part of Control Loop + models, that send remediation action requests to an APPC/SDN-C; these + are triggered as a response to an event or correlated events published + to Event Bus. + + +.. container:: note + + :need:`R-24189` + + The VNF or PNF provider **MUST** deliver a new set of playbooks that + includes all updated and unchanged playbooks for any new revision to an + existing set of playbooks. + + +.. container:: note + + :need:`R-43353` + + The VNF or PNF **MUST** return control from Ansible Playbooks only after + all tasks performed by playbook are fully complete, signaling that the + playbook completed all tasks. When starting services, return control + only after all services are up. This is critical for workflows where + the next steps are dependent on prior tasks being fully completed. + + +.. container:: note + + :need:`R-51442` + + The VNF or PNF **SHOULD** use playbooks that are designed to + automatically 'rollback' to the original state in case of any errors + for actions that change state of the VNF or PNF (e.g., configure). + + **Note**: In case rollback at the playbook level is not supported or + possible, the VNF or PNF provider shall provide alternative rollback + mechanism (e.g., for a small VNF or PNF the rollback mechanism may rely + on workflow to terminate and re-instantiate VNF VMs and then re-run + playbook(s)). Backing up updated files is also recommended to support + rollback when soft rollback is feasible. + + +.. container:: note + + :need:`R-48698` + + The VNF or PNF **MUST** utilize information from key value pairs that will + be provided by the Ansible Server as "extra-vars" during invocation to + execute the desired VNF or PNF action. The "extra-vars" attribute-value + pairs are passed to the Ansible Server by an APPC/SDN-C as part of the + Rest API request. If the playbook requires files, they must also be + supplied using the methodology detailed in the Ansible Server API, unless + they are bundled with playbooks, example, generic templates. Any files + containing instance specific info (attribute-value pairs), not obtainable + from any ONAP inventory databases or other sources, referenced and used an + input by playbooks, shall be provisioned (and distributed) in advance of + use, e.g., VNF or PNF instantiation. Recommendation is to avoid these + instance specific, manually created in advance of instantiation, files. + + +.. container:: note + + :need:`R-43253` + + The VNF or PNF **MUST** use playbooks designed to allow Ansible + Server to infer failure or success based on the "PLAY_RECAP" capability. + + **Note**: There are cases where playbooks need to interpret results + of a task and then determine success or failure and return result + accordingly (failure for failed tasks). + + +.. container:: note + + :need:`R-50252` + + The VNF or PNF **MUST** write to a response file in JSON format that will + be retrieved and made available by the Ansible Server if, as part of a VNF + or PNF action (e.g., audit), a playbook is required to return any VNF or + PNF information/response. The text files must be written in the main + playbook home directory, in JSON format. The JSON file must be created for + the VNF or PNF with the name '<VNF or PNF name>_results.txt'. All playbook + output results, for all VNF or PNF VMs, to be provided as a response to the + request, must be written to this response file. + + +.. container:: note + + :need:`R-49751` + + The VNF or PNF **MUST** support Ansible playbooks that are compatible with + Ansible version 2.6 or later. + + +.. container:: note + + :need:`R-33280` + + The VNF or PNF **MUST NOT** use any instance specific parameters + in a playbook. + + +.. container:: note + + :need:`R-40293` + + The VNF or PNF **MUST** make available playbooks that conform + to the ONAP requirement. + + +.. container:: note + + :need:`R-02651` + + The VNF or PNF **SHOULD** use available backup capabilities to save a + copy of configuration files before implementing changes to support + operations such as backing out of software upgrades, configuration + changes or other work as this will help backing out of configuration + changes when needed. + + +.. container:: note + + :need:`R-49396` + + The VNF or PNF **MUST** support each APPC/SDN-C VNF or PNF action + by invocation of **one** playbook [#7.3.4]_. The playbook will be + responsible for executing all necessary tasks (as well as calling other + playbooks) to complete the request. + + +Configuration Management > Chef Standards and Capabilities > VNF or PNF Configuration via Chef Requirements > Chef Client Requirements +-------------------------------------------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-47068` + + The VNF or PNF **MAY** expose a single endpoint that is + responsible for all functionality. + + +.. container:: note + + :need:`R-79224` + + The VNF or PNF **MUST** have the chef-client be preloaded with + validator keys and configuration to register with the designated + Chef Server as part of the installation process. + + +.. container:: note + + :need:`R-67114` + + The VNF or PNF **MUST** be installed with Chef-Client >= 12.0 and Chef + push jobs client >= 2.0. + + +.. container:: note + + :need:`R-72184` + + The VNF or PNF **MUST** have routable FQDNs for all the endpoints + (VMs) of a VNF or PNF that contain chef-clients which are used to register + with the Chef Server. As part of invoking VNF or PNF actions, ONAP will + trigger push jobs against FQDNs of endpoints for a VNF or PNF, if required. + + +Configuration Management > Chef Standards and Capabilities > VNF or PNF Configuration via Chef Requirements > Chef Roles/Requirements +------------------------------------------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-37929` + + The VNF or PNF **MUST** accept all necessary instance specific + data from the environment or node object attributes for the VNF or PNF + in roles/cookbooks/recipes invoked for a VNF or PNF action. + + +.. container:: note + + :need:`R-62170` + + The VNF or PNF **MUST** over-ride any default values for + configurable parameters that can be set by ONAP in the roles, + cookbooks and recipes. + + +.. container:: note + + :need:`R-30654` + + The VNF or PNF Package **MUST** have appropriate cookbooks that are + designed to automatically 'rollback' to the original state in case of + any errors for actions that change state of the VNF or PNF (e.g., + configure). + + +.. container:: note + + :need:`R-26567` + + The VNF or PNF Package **MUST** include a run list of + roles/cookbooks/recipes, for each supported VNF or PNF action, that will + perform the desired VNF or PNF action in its entirety as specified by ONAP + (see Section 7.c, APPC/SDN-C APIs and Behavior, for list of VNF or PNF + actions and requirements), when triggered by a chef-client run list + in JSON file. + + +.. container:: note + + :need:`R-27310` + + The VNF or PNF Package **MUST** include all relevant Chef artifacts + (roles/cookbooks/recipes) required to execute VNF or PNF actions requested + by ONAP for loading on appropriate Chef Server. + + +.. container:: note + + :need:`R-44013` + + The VNF or PNF **MUST** populate an attribute, defined as node + ['PushJobOutput'] with the desired output on all nodes in the push job + that execute chef-client run if the VNF or PNF action requires the output + of a chef-client run be made available (e.g., get running configuration). + + +.. container:: note + + :need:`R-15885` + + The VNF or PNF **MUST** Upon completion of the chef-client run, + POST back on the callback URL, a JSON object as described in Table + A2 if the chef-client run list includes a cookbook/recipe that is + callback capable. Failure to POST on the Callback Url should not be + considered a critical error. That is, if the chef-client successfully + completes the VNF or PNF action, it should reflect this status on the Chef + Server regardless of whether the Callback succeeded or not. + + +.. container:: note + + :need:`R-65755` + + The VNF or PNF **SHOULD** support callback URLs to return information + to ONAP upon completion of the chef-client run for any chef-client run + associated with a VNF or PNF action. + + - As part of the push job, ONAP will provide two parameters in the + environment of the push job JSON object: + + - "RequestId" a unique Id to be used to identify the request, + - "CallbackUrl", the URL to post response back. + + - If the CallbackUrl field is empty or missing in the push job, then + the chef-client run need not post the results back via callback. + + +.. container:: note + + :need:`R-98911` + + The VNF or PNF **MUST NOT** use any instance specific parameters + for the VNF or PNF in roles/cookbooks/recipes invoked for a VNF or PNF + action. + + +.. container:: note + + :need:`R-78116` + + The VNF or PNF **MUST** update status on the Chef Server + appropriately (e.g., via a fail or raise an exception) if the + chef-client run encounters any critical errors/failures when + executing a VNF or PNF action. + + +Configuration Management > Controller Interactions With VNF or PNF > Configuration Commands +------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-20741` + + The VNF or PNF **MUST** support APPC/SDN-C ``Configure`` command. + + +.. container:: note + + :need:`R-56385` + + The VNF or PNF **MUST** support APPC ``Audit`` command. + + +.. container:: note + + :need:`R-48247` + + The VNF or PNF **MUST** support APPC ``ConfigRestore`` command. + + +.. container:: note + + :need:`R-94084` + + The VNF or PNF **MUST** support APPC/SDN-C ``ConfigScaleOut`` command. + + +.. container:: note + + :need:`R-19366` + + The VNF or PNF **MUST** support APPC ``ConfigModify`` command. + + +.. container:: note + + :need:`R-32981` + + The VNF or PNF **MUST** support APPC ``ConfigBackup`` command. + + +Configuration Management > Controller Interactions With VNF or PNF > HealthCheck and Failure Related Commands +------------------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-41430` + + The VNF or PNF **MUST** support APPC/SDN-C ``HealthCheck`` command. + + +Configuration Management > Controller Interactions With VNF or PNF > Lifecycle Management Related Commands +---------------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-65641` + + The VNF or PNF **MUST** support APPC/SDN-C ``UpgradeBackOut`` command. + + +.. container:: note + + :need:`R-97343` + + The VNF or PNF **MUST** support APPC/SDN-C ``UpgradeBackup`` command. + + +.. container:: note + + :need:`R-45856` + + The VNF or PNF **MUST** support APPC/SDN-C ``UpgradePostCheck`` command. + + +.. container:: note + + :need:`R-07251` + + The VNF or PNF **MUST** support APPC/SDN-C ``ResumeTraffic`` command. + + +.. container:: note + + :need:`R-19922` + + The VNF or PNF **MUST** support APPC/SDN-C ``UpgradePrecheck`` command. + + +.. container:: note + + :need:`R-49466` + + The VNF or PNF **MUST** support APPC/SDN-C ``UpgradeSoftware`` command. + + +.. container:: note + + :need:`R-82811` + + The VNF or PNF **MUST** support APPC ``StartApplication`` command. + + +.. container:: note + + :need:`R-12706` + + The VNF or PNF **MUST** support APPC/SDN-C ``QuiesceTraffic`` command. + + +.. container:: note + + :need:`R-328086` + + The VNF or PNF **MUST**, if serving as a distribution point or anchor point for + steering point from source to destination, support the ONAP Controller's + ``DistributeTraffic`` command. + + +.. container:: note + + :need:`R-83146` + + The VNF or PNF **MUST** support APPC ``StopApplication`` command. + + +Configuration Management > NETCONF Standards and Capabilities > VNF or PNF Configuration via NETCONF Requirements > Configuration Management +-------------------------------------------------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-95950` + + The VNF or PNF **MUST** provide a NETCONF interface fully defined + by supplied YANG models for the embedded NETCONF server. + + +.. container:: note + + :need:`R-88026` + + The VNF or PNF **MUST** include a NETCONF server enabling + runtime configuration and lifecycle management capabilities. + + +Configuration Management > NETCONF Standards and Capabilities > VNF or PNF Configuration via NETCONF Requirements > NETCONF Server Requirements +----------------------------------------------------------------------------------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-997907` + + The VNF or PNF **SHOULD** support TLS as secure transport for the NETCONF + protocol according to [RFC7589]. + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-26115` + + The VNF or PNF **MUST** follow the data model update rules defined in + [RFC6020] section 10 for YANG 1.0 modules, and [RFC7950] section 11 + for YANG 1.1 modules. All deviations from the aforementioned update + rules shall be handled by a built-in automatic upgrade mechanism. + + +.. container:: note + + :need:`R-10716` + + The VNF or PNF **MUST** support parallel and simultaneous + configuration of separate objects within itself. + + +.. container:: note + + :need:`R-59610` + + The VNF or PNF **MUST** implement the data model discovery and + download as defined in [RFC6022]. + + +.. container:: note + + :need:`R-83790` + + The VNF or PNF **MUST** implement the ``:validate`` capability. + + +.. container:: note + + :need:`R-62468` + + The VNF or PNF **MUST** allow all configuration data to be + edited through a NETCONF <edit-config> operation. Proprietary + NETCONF RPCs that make configuration changes are not sufficient. + + +.. container:: note + + :need:`R-29495` + + The VNF or PNF **MUST** support locking if a common object is + being manipulated by two simultaneous NETCONF configuration operations + on the same VNF or PNF within the context of the same writable running data + store (e.g., if an interface parameter is being configured then it + should be locked out for configuration by a simultaneous configuration + operation on that same interface parameter). + + +.. container:: note + + :need:`R-88031` + + The VNF or PNF **SHOULD** implement the protocol operation: + ``delete-config(target)`` - Delete the named configuration + data store target. + + +.. container:: note + + :need:`R-54190` + + The VNF or PNF **MUST** release locks to prevent permanent lock-outs + when/if a session applying the lock is terminated (e.g., SSH session + is terminated). + + +.. container:: note + + :need:`R-49145` + + The VNF or PNF **MUST** implement ``:confirmed-commit`` If + ``:candidate`` is supported. + + +.. container:: note + + :need:`R-96554` + + The VNF or PNF **MUST** implement the protocol operation: + ``unlock(target)`` - Unlock the configuration data store target. + + +.. container:: note + + :need:`R-22946` + + The VNF or PNF **SHOULD** conform its YANG model to RFC 6536, + "NETCONF Access Control Model". + + +.. container:: note + + :need:`R-01382` + + The VNF or PNF **MUST** allow the entire configuration of the VNF or PNF to be + retrieved via NETCONF's <get-config> and <edit-config>, independently + of whether it was configured via NETCONF or other mechanisms. + + +.. container:: note + + :need:`R-10173` + + The VNF or PNF **MUST** allow another NETCONF session to be able to + initiate the release of the lock by killing the session owning the lock, + using the <kill-session> operation to guard against hung NETCONF sessions. + + +.. container:: note + + :need:`R-08134` + + The VNF or PNF **MUST** conform to the NETCONF RFC 6241, + "NETCONF Configuration Protocol". + + +.. container:: note + + :need:`R-60656` + + The VNF or PNF **MUST** support sub tree filtering. + + +.. container:: note + + :need:`R-29488` + + The VNF or PNF **MUST** implement the protocol operation: + ``get-config(source, filter`` - Retrieve a (filtered subset of + a) configuration from the configuration data store source. + + +.. container:: note + + :need:`R-01334` + + The VNF or PNF **MUST** conform to the NETCONF RFC 5717, + "Partial Lock Remote Procedure Call". + + +.. container:: note + + :need:`R-33946` + + The VNF or PNF **MUST** conform to the NETCONF RFC 4741, + "NETCONF Configuration Protocol". + + +.. container:: note + + :need:`R-25238` + + The VNF or PNF PACKAGE **MUST** validated YANG code using the open + source pyang [#7.3.1]_ program using the following commands: + + .. code-block:: text + + $ pyang --verbose --strict <YANG-file-name(s)> $ echo $! + + +.. container:: note + + :need:`R-10129` + + The VNF or PNF **SHOULD** conform its YANG model to RFC 7223, + "A YANG Data Model for Interface Management". + + +.. container:: note + + :need:`R-33955` + + The VNF or PNF **SHOULD** conform its YANG model to RFC 6991, + "Common YANG Data Types". + + +.. container:: note + + :need:`R-88899` + + The VNF or PNF **MUST** support simultaneous <commit> operations + within the context of this locking requirements framework. + + +.. container:: note + + :need:`R-11235` + + The VNF or PNF **MUST** implement the protocol operation: + ``kill-session(session``- Force the termination of **session**. + + +.. container:: note + + :need:`R-12271` + + The VNF or PNF **SHOULD** conform its YANG model to RFC 7223, + "IANA Interface Type YANG Module". + + +.. container:: note + + :need:`R-90007` + + The VNF or PNF **MUST** implement the protocol operation: + ``close-session()`` - Gracefully close the current session. + + +.. container:: note + + :need:`R-03465` + + The VNF or PNF **MUST** release locks to prevent permanent lock-outs + when the corresponding <partial-unlock> operation succeeds. + + +.. container:: note + + :need:`R-93443` + + The VNF or PNF **MUST** define all data models in YANG 1.0 [RFC6020] or + YANG 1.1 [RFC7950]. A combination of YANG 1.0 and YANG 1.1 modules is + allowed subject to the rules in [RFC7950] section 12. The mapping to + NETCONF shall follow the rules defined in this RFC. + + +.. container:: note + + :need:`R-29324` + + The VNF or PNF **SHOULD** implement the protocol operation: + ``copy-config(target, source)`` - Copy the content of the + configuration data store source to the configuration data store target. + + +.. container:: note + + :need:`R-68990` + + The VNF or PNF **MUST** support the ``:startup`` capability. It + will allow the running configuration to be copied to this special + database. It can also be locked and unlocked. + + +.. container:: note + + :need:`R-80898` + + TThe VNF or PNF **MUST** support heartbeat via a <get> with null filter. + + +.. container:: note + + :need:`R-66793` + + The VNF or PNF **MUST** guarantee the VNF or PNF configuration integrity + for all simultaneous configuration operations (e.g., if a change is + attempted to the BUM filter rate from multiple interfaces on the same + EVC, then they need to be sequenced in the VNF or PNF without locking either + configuration method out). + + +.. container:: note + + :need:`R-11499` + + The VNF or PNF **MUST** fully support the XPath 1.0 specification + for filtered retrieval of configuration and other database contents. + The 'type' attribute within the <filter> parameter for <get> and + <get-config> operations may be set to 'xpath'. The 'select' attribute + (which contains the XPath expression) will also be supported by the + server. A server may support partial XPath retrieval filtering, but + it cannot advertise the ``:xpath`` capability unless the entire XPath + 1.0 specification is supported. + + +.. container:: note + + :need:`R-63935` + + The VNF or PNF **MUST** release locks to prevent permanent lock-outs + when a user configured timer has expired forcing the NETCONF SSH Session + termination (i.e., product must expose a configuration knob for a user + setting of a lock expiration timer). + + +.. container:: note + + :need:`R-63953` + + The VNF or PNF **MUST** have the echo command return a zero value + otherwise the validation has failed. + + +.. container:: note + + :need:`R-26508` + + The VNF or PNF **MUST** support a NETCONF server that can be mounted on + OpenDaylight (client) and perform the operations of: modify, update, + change, rollback configurations using each configuration data element, + query each state (non-configuration) data element, execute each YANG + RPC, and receive data through each notification statement. + + +.. container:: note + + :need:`R-70496` + + The VNF or PNF **MUST** implement the protocol operation: + ``commit(confirmed, confirm-timeout)`` - Commit candidate + configuration data store to the running configuration. + + +.. container:: note + + :need:`R-24269` + + The VNF or PNF **SHOULD** conform its YANG model to RFC 7407, + "A YANG Data Model for SNMP Configuration", if Netconf used to + configure SNMP engine. + + +.. container:: note + + :need:`R-13800` + + The VNF or PNF **MUST** conform to the NETCONF RFC 5277, + "NETCONF Event Notification". + + +.. container:: note + + :need:`R-22700` + + The VNF or PNF **MUST** conform its YANG model to RFC 6470, + "NETCONF Base Notifications". + + +.. container:: note + + :need:`R-78282` + + The VNF or PNF **MUST** conform to the NETCONF RFC 6242, + "Using the Network Configuration Protocol over Secure Shell". + + +.. container:: note + + :need:`R-53317` + + The VNF or PNF **MUST** conform its YANG model to RFC 6087, + "Guidelines for Authors and Reviewers of YANG Data Model specification". + + +.. container:: note + + :need:`R-97529` + + The VNF or PNF **SHOULD** implement the protocol operation: + ``get-schema(identifier, version, format)`` - Retrieve the YANG schema. + + +.. container:: note + + :need:`R-18733` + + The VNF or PNF **MUST** implement the protocol operation: + ``discard-changes()`` - Revert the candidate configuration + data store to the running configuration. + + +.. container:: note + + :need:`R-44281` + + The VNF or PNF **MUST** implement the protocol operation: + ``edit-config(target, default-operation, test-option, error-option, + config)`` - Edit the target configuration data store by merging, + replacing, creating, or deleting new config elements. + + +.. container:: note + + :need:`R-02597` + + The VNF or PNF **MUST** implement the protocol operation: + ``lock(target)`` - Lock the configuration data store target. + + +.. container:: note + + :need:`R-20353` + + The VNF or PNF **MUST** implement both ``:candidate`` and + ``:writable-running`` capabilities. When both ``:candidate`` and + ``:writable-running`` are provided then two locks should be supported. + + +.. container:: note + + :need:`R-10353` + + The VNF or PNF **MUST** conform its YANG model to RFC 6244, + "An Architecture for Network Management Using NETCONF and YANG". + + +.. container:: note + + :need:`R-60106` + + The VNF or PNF **MUST** implement the protocol operation: + ``get(filter)`` - Retrieve (a filtered subset of) the running + configuration and device state information. This should include + the list of VNF or PNF supported schemas. + + +.. container:: note + + :need:`R-87564` + + The VNF or PNF **SHOULD** conform its YANG model to RFC 7317, + "A YANG Data Model for System Management". + + +.. container:: note + + :need:`R-83873` + + The VNF or PNF **MUST** support ``:rollback-on-error`` value for + the <error-option> parameter to the <edit-config> operation. If any + error occurs during the requested edit operation, then the target + database (usually the running configuration) will be left unaffected. + This provides an 'all-or-nothing' edit mode for a single <edit-config> + request. + + +.. container:: note + + :need:`R-73468` + + The VNF or PNF **MUST** allow the NETCONF server connection + parameters to be configurable during virtual machine instantiation + through Heat templates where SSH keys, usernames, passwords, SSH + service and SSH port numbers are Heat template parameters. + + +.. container:: note + + :need:`R-28756` + + The VNF or PNF **MUST** support ``:partial-lock`` and + ``:partial-unlock`` capabilities, defined in RFC 5717. This + allows multiple independent clients to each write to a different + part of the <running> configuration at the same time. + + +.. container:: note + + :need:`R-68200` + + The VNF or PNF **MUST** support the ``:url`` value to specify + protocol operation source and target parameters. The capability URI + for this feature will indicate which schemes (e.g., file, https, sftp) + that the server supports within a particular URL value. The 'file' + scheme allows for editable local configuration databases. The other + schemes allow for remote storage of configuration databases. + + +.. container:: note + + :need:`R-53015` + + The VNF or PNF **MUST** apply locking based on the sequence of + NETCONF operations, with the first configuration operation locking + out all others until completed. + + +.. container:: note + + :need:`R-07545` + + The VNF or PNF **MUST** support all operations, administration and + management (OAM) functions available from the supplier for VNFs or PNFs + using the supplied YANG code and associated NETCONF servers. + + +.. container:: note + + :need:`R-41829` + + The VNF or PNF **MUST** be able to specify the granularity of the + lock via a restricted or full XPath expression. + + +.. container:: note + + :need:`R-49036` + + The VNF or PNF **SHOULD** conform its YANG model to RFC 7277, + "A YANG Data Model for IP Management". + + +.. container:: note + + :need:`R-02616` + + The VNF or PNF **MUST** permit locking at the finest granularity + if a VNF or PNF needs to lock an object for configuration to avoid blocking + simultaneous configuration operations on unrelated objects (e.g., BGP + configuration should not be locked out if an interface is being + configured or entire Interface configuration should not be locked out + if a non-overlapping parameter on the interface is being configured). + + +.. container:: note + + :need:`R-58358` + + The VNF or PNF **MUST** implement the ``:with-defaults`` capability + [RFC6243]. + + +.. container:: note + + :need:`R-04158` + + The VNF or PNF **MUST** conform to the NETCONF RFC 4742, + "Using the NETCONF Configuration Protocol over Secure Shell (SSH)". + + +Configuration Management > NETCONF Standards and Capabilities > xNF Configuration via NETCONF Requirements > NETCONF Server Requirements +---------------------------------------------------------------------------------------------------------------------------------------- + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-28545 + + The xNF **MUST** conform its YANG model to RFC 6060, + "YANG - A Data Modeling Language for the Network Configuration + Protocol (NETCONF)". + + +Configuration Management > VNF or PNF REST APIs > REST APIs +----------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-31809` + + The VNF or PNF **MUST** support the HealthCheck RPC. The HealthCheck + RPC executes a VNF or PNF Provider-defined VNF or PNF HealthCheck over the + scope of the entire VNF or PNF (e.g., if there are multiple VNFCs, then + run a health check, as appropriate, for all VNFCs). It returns a 200 OK if + the test completes. A JSON object is returned indicating state (healthy, + unhealthy), scope identifier, time-stamp and one or more blocks containing + info and fault information. If the VNF or PNF is unable to run the + HealthCheck, return a standard http error code and message. + + +Contrail Resource Parameters > OS::ContrailV2::VirtualMachineInterface Property virtual_machine_interface_allowed_address_pairs > External Networks +--------------------------------------------------------------------------------------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-100280` + + If a VNF's Heat Orchestration Template's resource + ``OS::ContrailV2::VirtualMachineInterface`` + is attaching to an external network (per the + ONAP definition, see Requirement R-57424), the + map property + + ``virtual_machine_interface_allowed_address_pairs``, + + ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair``, + + ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip``, + + ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix`` + + parameter + **MUST NOT** be enumerated in the + VNF's Heat Orchestration Template's Environment File. + + +.. container:: note + + :need:`R-100310` + + When the VNF's Heat Orchestration Template's resource + ``OS::ContrailV2::VirtualMachineInterface`` is attaching to an external + network (per the + ONAP definition, see Requirement R-57424), + and an IPv4 Virtual IP (VIP) + is required to be supported by the ONAP data model, + the map property + + ``virtual_machine_interface_allowed_address_pairs``, + + ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair``, + + ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip``, + + ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix`` + + 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``. + + The ONAP data model can only support one IPv4 VIP address. + + +.. container:: note + + :need:`R-100330` + + When the VNF's Heat Orchestration Template's resource + ``OS::ContrailV2::VirtualMachineInterface`` is attaching to an external + network (per the + ONAP definition, see Requirement R-57424), + and an IPv6 Virtual IP (VIP) + is required to be supported by the ONAP data model, + the map property + + ``virtual_machine_interface_allowed_address_pairs``, + + ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair``, + + ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip``, + + ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix`` + + 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``. + + The ONAP data model can only support one IPv6 VIP address. + + +.. container:: note + + :need:`R-100350` + + When the VNF's Heat Orchestration Template's resource + ``OS::ContrailV2::VirtualMachineInterface`` is attaching to an + external network + (per the ONAP definition, see Requirement R-57424), + and the IPv4 VIP address and/or IPv6 VIP address + is **not** supported by the ONAP data model, + the map property + + ``virtual_machine_interface_allowed_address_pairs``, + + ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair``, + + ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip``, + + ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix`` + + * Parameter name **MAY** use any naming convention. That is, there is no + ONAP mandatory parameter naming convention. + * Parameter **MAY** be declared as type ``string`` or type + ``comma_delimited_list``. + + And the ``OS::ContrailV2::VirtualMachineInterface`` resource + **MUST** contain resource-level ``metadata`` (not property-level). + + And the ``metadata`` format **MUST** must contain the + key value ``aap_exempt`` with a list of all map property + + ``virtual_machine_interface_allowed_address_pairs``, + + ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair``, + + ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip``, + + ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix`` + + parameters **not** supported by the ONAP data model. + + +Contrail Resource Parameters > OS::ContrailV2::VirtualMachineInterface Property virtual_machine_interface_allowed_address_pairs > Internal Networks +--------------------------------------------------------------------------------------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-100360` + + When the VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::VirtualMachineInterface`` is attaching to an + internal network (per the + ONAP definition, see Requirements R-52425 and R-46461), + and an IPv4 Virtual IP (VIP) + address is assigned using the map property, + ``virtual_machine_interface_allowed_address_pairs, + virtual_machine_interface_allowed_address_pairs_allowed_address_pair, + virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip, + virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix`` + , the parameter name **MUST** follow the + naming convention + + * ``{vm-type}_int_{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`` + and **MUST** be enumerated in the environment file. + + OR + + the parameter name **MUST** follow the + naming convention + + * ``{vm-type}_int_{network-role}_floating_ips`` + + 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: comma_delimited_list`` + and **MUST** be enumerated in the environment file. + + +.. container:: note + + :need:`R-100370` + + When the VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::VirtualMachineInterface`` is attaching to an + internal network (per the + ONAP definition, see Requirements R-52425 and R-46461), + and an IPv6 Virtual IP (VIP) + address is assigned + using the map property, + ``virtual_machine_interface_allowed_address_pairs, + virtual_machine_interface_allowed_address_pairs_allowed_address_pair, + virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip, + virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix`` + , the parameter name **MUST** follow the + naming convention + + * ``{vm-type}_int_{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`` + and **MUST** be enumerated in the environment file + + OR + + the parameter name **MUST** follow the + naming convention + + * ``{vm-type}_int_{network-role}_floating_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 + + And the parameter **MUST** be declared as ``type: comma_delimited_list`` + and **MUST** be enumerated in the environment file. + + +Contrail Resource Parameters > Resource OS::ContrailV2::InstanceIp > Resource OS::ContrailV2::InstanceIp Property instance_ip_address +------------------------------------------------------------------------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-100000` + + The VNF's Heat Orchestration Template's + resource ``OS::ContrailV2::InstanceIp`` property ``instance_ip_address`` + parameter + **MUST** be declared as either type ``string`` or type + ``comma_delimited_list``. + + +.. container:: note + + :need:`R-100010` + + When the VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::InstanceIp`` is assigning an IP address + to an external network (per the ONAP definition, see Requirement R-57424), + and an IPv4 address is assigned + using the property ``instance_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 + * ``{index}`` is a numeric value that **MUST** start at zero in a + VNF's Heat Orchestration Template and **MUST** increment by one + + +.. container:: note + + :need:`R-100020` + + The VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::InstanceIp`` property ``instance_ip_address`` + parameter + ``{vm-type}_{network-role}_ip_{index}`` + **MUST NOT** be enumerated in the + VNF's Heat Orchestration Template's Environment File. + + +.. container:: note + + :need:`R-100030` + + When the VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::InstanceIp`` is assigning an IP address + to an external network (per the + ONAP definition, see Requirement R-57424), + and an IPv4 address is assigned + using the property ``instance_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-100040` + + The VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::InstanceIp`` property ``instance_ip_address`` + parameter + ``{vm-type}_{network-role}_ips`` + **MUST NOT** be enumerated in the + VNF's Heat Orchestration Template's Environment File. + + +.. container:: note + + :need:`R-100050` + + When the VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::InstanceIp`` is assigning an IP address + to an external network + (per the + ONAP definition, see Requirement R-57424), + and an IPv6 address is assigned + using the property ``instance_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 + * ``{index}`` is a numeric value that **MUST** start at zero in a + VNF's Heat Orchestration Template and **MUST** increment by one + + +.. container:: note + + :need:`R-100060` + + The VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::InstanceIp`` property ``instance_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-100070` + + When the VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::InstanceIp`` is assigning an IP address + to an external network (per the + ONAP definition, see Requirement R-57424), + and an IPv6 address is assigned + using the property ``instance_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-100080` + + The VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::InstanceIp`` property ``instance_ip_address`` + parameter + ``{vm-type}_{network-role}_v6_ips`` + **MUST NOT** be enumerated in the + VNF's Heat Orchestration Template's Environment File. + + +.. container:: note + + :need:`R-100090` + + When the VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::InstanceIp`` is assigning an IP address + to an internal network (per the + ONAP definition, see Requirements R-52425 and R-46461), + and an IPv4 address is assigned + using the property ``instance_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 + * ``{index}`` is a numeric value that **MUST** start at zero in a + VNF's Heat Orchestration Template and **MUST** increment by one + + +.. container:: note + + :need:`R-100100` + + The VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::InstanceIp`` property ``instance_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-100110` + + When the VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::InstanceIp`` is assigning an IP address + to an internal network (per the + ONAP definition, see Requirements R-52425 and R-46461), + and an IPv4 address is assigned + using the property ``instance_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-100120` + + The VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::InstanceIp`` property ``instance_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-100130` + + When the VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::InstanceIp`` is assigning an IP address to an + internal network (per the + ONAP definition, see Requirements R-52425 and R-46461), + and an IPv6 address is assigned + using the property ``instance_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 + * ``{index}`` is a numeric value that **MUST** start at zero in a + VNF's Heat Orchestration Template and **MUST** increment by one + + +.. container:: note + + :need:`R-100140` + + The VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::InstanceIp`` property ``instance_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-100150` + + When the VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::InstanceIp`` is assigning an IP address to an + internal network (per the + ONAP definition, see Requirements R-52425 and R-46461), + and an IPv6 address is assigned + using the property ``instance_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-100160` + + The VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::InstanceIp`` property ``instance_ip_address`` + 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-100170` + + The VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::InstanceIp`` + property ``instance_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-100180` + + The VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::InstanceIp`` + property ``instance_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. + + +Contrail Resource Parameters > Resource OS::ContrailV2::InstanceIp > Resource OS::ContrailV2::InstanceIp Property subnet_uuid +----------------------------------------------------------------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-100190` + + The VNF's Heat Orchestration Template's + resource ``OS::ContrailV2::InstanceIp`` property ``subnet_uuid`` + parameter + **MUST** be declared type ``string``. + + +.. container:: note + + :need:`R-100200` + + When the VNF's Heat Orchestration Template's + resource ``OS::ContrailV2::InstanceIp`` is assigning an IP address + 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 ``subnet_uuid``, the parameter + **MUST** follow the naming convention + + * ``{network-role}_subnet_id`` + + where + + * ``{network-role}`` is the network role of the network. + + +.. container:: note + + :need:`R-100210` + + The VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::InstanceIp`` property ``subnet_uuid`` + parameter + ``{network-role}_subnet_id`` + **MUST NOT** be enumerated in the + VNF's Heat Orchestration Template's Environment File. + + +.. container:: note + + :need:`R-100220` + + When the VNF's Heat Orchestration Template's + resource ``OS::ContrailV2::InstanceIp`` is assigning an IP address + 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 ``subnet_uuid``, 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-100230` + + The VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::InstanceIp`` property ``subnet_uuid`` + parameter + ``{network-role}_v6_subnet_id`` + **MUST NOT** be enumerated in the + VNF's Heat Orchestration Template's Environment File. + + +.. container:: note + + :need:`R-100240` + + When + + * the VNF's Heat Orchestration Template's + resource ``OS::ContrailV2::InstanceIp`` in an Incremental Module is + assigning an IP address + 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 ``subnet_uuid``, + + 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-100250` + + The VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::InstanceIp`` property ``subnet_uuid`` + parameter + ``int_{network-role}_subnet_id`` + **MUST NOT** be enumerated in the + VNF's Heat Orchestration Template's Environment File. + + +.. container:: note + + :need:`R-100260` + + When + + * the VNF's Heat Orchestration Template's + resource ``OS::ContrailV2::InstanceIp`` 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 ``subnet_uuid``, + + 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-100270` + + The VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::InstanceIp`` property ``subnet_uuid`` + parameter + ``int_{network-role}_v6_subnet_id`` + **MUST NOT** be enumerated in the + VNF's Heat Orchestration Template's Environment File. + + +Monitoring & Management > Data Structure Specification of the Event Record +-------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-120182` + + The VNF or PNF 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 :ref:`VES Event Registration specification <ves_event_registration_3_2>`. + + +.. container:: note + + :need:`R-570134` + + The events produced by the VNF or PNF **MUST** must be compliant with the common + event format defined in the + :ref:`VES Event Listener<ves_event_listener_7_1>` + specification. + + +.. container:: note + + :need:`R-520802` + + The VNF or PNF provider **MUST** provide a YAML file formatted in adherence with + the :ref:`VES Event Registration specification <ves_event_registration_3_2>` + that defines the following information for each event produced by the VNF: + + * ``eventName`` + * Required fields + * Optional fields + * Any special handling to be performed for that event + + +.. container:: note + + :need:`R-123044` + + The VNF or PNF 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. + + +Monitoring & Management > Event Records - Data Structure Description > Common Event Header +------------------------------------------------------------------------------------------ + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. 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 VNF or PNF + * ``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 > Monitoring & Management Requirements > Addressing and Delivery Protocol +------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-84879` + + The VNF or PNF **MUST** have the capability of maintaining a primary + and backup DNS name (URL) for connecting to ONAP collectors, with the + ability to switch between addresses based on conditions defined by policy + such as time-outs, and buffering to store messages until they can be + delivered. At its discretion, the service provider may choose to populate + only one collector address for a VNF or PNF. In this case, the network will + promptly resolve connectivity problems caused by a collector or network + failure transparently to the VNF or PNF. + + +.. container:: note + + :need:`R-88482` + + The VNF or PNF **SHOULD** use REST using HTTPS delivery of plain + text JSON for moderate sized asynchronous data sets, and for high + volume data sets when feasible. + + +.. container:: note + + :need:`R-81777` + + The VNF or PNF **MUST** be configured with initial address(es) to use + at deployment time. Subsequently, address(es) may be changed through + ONAP-defined policies delivered from ONAP to the VNF or PNF using PUTs to a + RESTful API, in the same manner that other controls over data reporting + will be controlled by policy. + + +.. container:: note + + :need:`R-79412` + + The VNF or PNF **MAY** use another option which is expected to include TCP + for high volume streaming asynchronous data sets and for other high volume + data sets. TCP delivery can be used for either JSON or binary encoded data + sets. + + +.. container:: note + + :need:`R-01033` + + The VNF or PNF **MAY** use another option which is expected to include SFTP + for asynchronous bulk files, such as bulk files that contain large volumes + of data collected over a long time interval or data collected across many + VNFs or PNFs. (Preferred is to reorganize the data into more frequent or more focused + data sets, and deliver these by REST or TCP as appropriate.) + + +.. container:: note + + :need:`R-03070` + + The VNF or PNF **MUST**, by ONAP Policy, provide the ONAP addresses + as data destinations for each VNF or PNF, and may be changed by Policy while + the VNF or PNF is in operation. We expect the VNF or PNF to be capable of redirecting + traffic to changed destinations with no loss of data, for example from + one REST URL to another, or from one TCP host and port to another. + + +.. container:: note + + :need:`R-08312` + + The VNF or PNF **MAY** use another option which is expected to include REST + delivery of binary encoded data sets. + + +.. container:: note + + :need:`R-63229` + + The VNF or PNF **MAY** use another option which is expected to include REST + for synchronous data, using RESTCONF (e.g., for VNF or PNF state polling). + + +Monitoring & Management > Monitoring & Management Requirements > Asynchronous and Synchronous Data Delivery +----------------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-73285` + + The VNF or PNF **MUST** must encode, address and deliver the data + as described in the previous paragraphs. + + +.. container:: note + + :need:`R-06924` + + The VNF or PNF **MUST** deliver asynchronous data as data becomes + available, or according to the configured frequency. + + +.. container:: note + + :need:`R-86586` + + The VNF or PNF **MUST** use the YANG configuration models and RESTCONF + [RFC8040] (https://tools.ietf.org/html/rfc8040). + + +.. container:: note + + :need:`R-70266` + + The VNF or PNF **MUST** respond to an ONAP request to deliver the + current data for any of the record types defined in + `Event Records - Data Structure Description`_ by returning the requested + record, populated with the current field values. (Currently the defined + record types include fault fields, mobile flow fields, measurements for + VNF or PNF scaling fields, and syslog fields. Other record types will be added + in the future as they become standardized and are made available.) + + +.. container:: note + + :need:`R-34660` + + The VNF or PNF **MUST** use the RESTCONF/NETCONF framework used by + the ONAP configuration subsystem for synchronous communication. + + +.. container:: note + + :need:`R-332680` + + The VNF or PNF **SHOULD** deliver all syslog messages to the VES Collector per the + specifications in Monitoring and Management chapter. + + +.. container:: note + + :need:`R-46290` + + The VNF or PNF **MUST** respond to an ONAP request to deliver granular + data on device or subsystem status or performance, referencing the YANG + configuration model for the VNF or PNF by returning the requested data elements. + + +.. container:: note + + :need:`R-42140` + + The VNF or PNF **MUST** respond to data requests from ONAP as soon + as those requests are received, as a synchronous response. + + +.. container:: note + + :need:`R-11240` + + The VNF or PNF **MUST** respond with content encoded in JSON, as + described in the RESTCONF specification. This way the encoding of a + synchronous communication will be consistent with Avro. + + +.. container:: note + + :need:`R-43327` + + The VNF or PNF **SHOULD** use `Modeling JSON text with YANG + <https://tools.ietf.org/html/rfc7951>`_, If YANG models need to be + translated to and from JSON{RFC7951]. YANG configuration and content can + be represented via JSON, consistent with Avro, as described in "Encoding + and Serialization" section. + + +Monitoring & Management > Monitoring & Management Requirements > Bulk Performance Measurement +--------------------------------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-807129` + + The VNF or PNF **SHOULD** report the files in FileReady for as long as they are + available at VNF or PNF. + + Note: Recommended period is at least 24 hours. + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-841740` + + The VNF or PNF **SHOULD** support FileReady VES event for event-driven bulk transfer + of monitoring data. + + +.. container:: note + + :need:`R-440220` + + The VNF or PNF **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 VNF or PNF **SHOULD** support the data schema defined in 3GPP TS 32.435, when + supporting the event-driven bulk transfer of monitoring data. + + +Monitoring & Management > Monitoring & Management Requirements > Google Protocol Buffers (GPB) +---------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-257367` + + The VNF or PNF, when leveraging Google Protocol Buffers for events, **MUST** + serialize the events using native Google Protocol Buffers (GPB) according + to the following guidelines: + + * The keys are represented as integers pointing to the system resources + for the VNF or PNF being monitored + * The values correspond to integers or strings that identify the + operational state of the VNF resource, such a statistics counters and + the state of an VNF or PNF resource. + * The required Google Protocol Buffers (GPB) metadata is provided in the + form of .proto files. + + +.. container:: note + + :need:`R-978752` + + The VNF or PNF providers **MUST** provide the Service Provider the following + artifacts to support the delivery of high-volume VNF or PNF telemetry to + DCAE via GPB over TLS/TCP: + + * A valid VES Event .proto definition file, to be used validate and + decode an event + * A valid high volume measurement .proto definition file, to be used for + processing high volume events + * A supporting PM content metadata file to be used by analytics + applications to process high volume measurement events + + +Monitoring & Management > Monitoring & Management Requirements > JSON +--------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-19624` + + The VNF or PNF, when leveraging JSON for events, **MUST** encode and serialize + content delivered to ONAP using JSON (RFC 7159) plain text format. + High-volume data is to be encoded and serialized using + `Avro <http://avro.apache.org/>`_, where the Avro data + format are described using JSON. + + +Monitoring & Management > Monitoring & Management Requirements > Reporting Frequency +------------------------------------------------------------------------------------ + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-98191` + + The VNF or PNF **MUST** vary the frequency that asynchronous data + is delivered based on the content and how data may be aggregated or + grouped together. + + Note: + + - For example, alarms and alerts are expected to be delivered as + soon as they appear. In contrast, other content, such as performance + measurements, KPIs or reported network signaling may have various + ways of packaging and delivering content. Some content should be + streamed immediately; or content may be monitored over a time + interval, then packaged as collection of records and delivered + as block; or data may be collected until a package of a certain + size has been collected; or content may be summarized statistically + over a time interval, or computed as a KPI, with the summary or KPI + being delivered. + - We expect the reporting frequency to be configurable depending on + the virtual network functions needs for management. For example, + Service Provider may choose to vary the frequency of collection + between normal and trouble-shooting scenarios. + - Decisions about the frequency of data reporting will affect + the size of delivered data sets, recommended delivery method, + and how the data will be interpreted by ONAP. These considerations + should not affect deserialization and decoding of the data, which + will be guided by the accompanying JSON schema or GPB definition + files. + + +.. container:: note + + :need:`R-146931` + + The VNF or PNF **MUST** report exactly one Measurement event per period + per source name. + + +Monitoring & Management > Monitoring & Management Requirements > Security +------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-42366` + + The VNF or PNF **MUST** support secure connections and transports such as + Transport Layer Security (TLS) protocol + [`RFC5246 <https://tools.ietf.org/html/rfc5246>`_] and should adhere to + the best current practices outlined in + `RFC7525 <https://tools.ietf.org/html/rfc7525>`_. + + +.. container:: note + + :need:`R-44290` + + The VNF or PNF **MUST** control access to ONAP and to VNFs or PNFs, and creation + of connections, through secure credentials, log-on and exchange mechanisms. + + +.. container:: note + + :need:`R-894004` + + When the VNF or PNF sets up a HTTP or HTTPS connection to the collector, 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-01427` + + The VNF or PNF **MUST** support the provisioning of security and authentication + parameters (HTTP username and password) in order to be able to authenticate + with DCAE (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-68165` + + The VNF or PNF **MUST** encrypt any content containing Sensitive Personal + Information (SPI) or certain proprietary data, in addition to applying the + regular procedures for securing access and delivery. + + +.. container:: note + + :need:`R-47597` + + The VNF or PNF **MUST** carry data in motion only over secure connections. + + +Monitoring & Management > Monitoring & Management Requirements > VNF telemetry via standardized interface +--------------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-821473` + + The VNF or PNF MUST produce heartbeat indicators consisting of events containing + the common event header only per the VES Listener Specification. + + +Monitoring & Management > Transports and Protocols Supporting Resource Interfaces +--------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-821839` + + The VNF or PNF **MUST** deliver event records to ONAP using the common + transport mechanisms and protocols defined in this specification. + + +.. container:: note + + :need:`R-798933` + + The VNF or PNF **SHOULD** deliver event records that fall into the event domains + supported by VES. + + +.. container:: note + + :need:`R-932071` + + The VNF or PNF provider **MUST** reach agreement with the Service Provider on + the selected methods for encoding, serialization and data delivery + prior to the on-boarding of the VNF or PNF into ONAP SDC Design Studio. + + +Monitoring & Management > Transports and Protocols Supporting Resource Interfaces > Bulk Telemetry Transmission +--------------------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-908291` + + The VNF or PNF **MAY** leverage bulk VNF or PNF 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 > VNF or PNF Telemetry using Google Protocol Buffers +-------------------------------------------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-697654` + + The VNF or PNF **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 > VNF or PNF Telemetry using VES/JSON Model +----------------------------------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-659655` + + The VNF or PNF **SHOULD** leverage the JSON-driven model, as depicted in Figure 2, + for data delivery unless there are specific performance or operational + concerns agreed upon by the Service Provider that would warrant using an + alternate model. + + +ONAP Heat Heat Template Constructs > Heat Files Support (get_file) +------------------------------------------------------------------ + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + 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. + + +ONAP Heat Heat Template Constructs > Key Pairs +---------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-100380` + + If a VNF requires the use of an SSH key created by OpenStack, the VNF + Heat Orchestration Template **SHOULD** create the ``OS::Nova::Keypair`` + in the base module, and expose the public key as an output value. + + This allows re-use of the key by ONAP when triggering scale out, recovery, + or other day 1 operations. + + +ONAP Heat Heat Template Constructs > Nested Heat Templates > Nested Heat Template Requirements +---------------------------------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-708564` + + If a VNF's Heat Orchestration Template's resource invokes a nested + YAML file, either statically or dynamically + (via ``OS::Heat::ResourceGroup``), + the names of the parameters associated with the following resource + properties **MUST NOT** change. + + * ``OS::Nova::Server`` property ``flavor`` + * ``OS::Nova::Server`` property ``image`` + * ``OS::Nova::Server`` property ``name`` + * ``OS::Nova::Server`` property metadata key value ``vnf_id`` + * ``OS::Nova::Server`` property metadata key value ``vf_module_id`` + * ``OS::Nova::Server`` property metadata key value ``vnf_name`` + * ``OS::Nova::Server`` property metadata key value ``vf_module_name`` + * ``OS::Nova::Server`` property metadata key value ``vm_role`` + * ``OS::Nova::Server`` property metadata key value ``vf_module_index`` + * ``OS::Nova::Server`` property metadata key value ``workload_context`` + * ``OS::Nova::Server`` property metadata key value ``environment_context`` + * ``OS::Neutron::Port`` property ``fixed_ips``, map property ``ip_address`` + * ``OS::Neutron::Port`` property ``fixed_ips``, map property ``subnet`` + * ``OS::Neutron::Port`` property ``allowed_address_pairs``, map property + ``ip_address`` + * ``OS::Neutron::Port`` property ``network`` + * ``OS::ContrailV2::VirtualMachineInterface`` property + ``virtual_network_refs`` + * ``OS::ContrailV2::VirtualMachineInterface`` property + ``virtual_machine_interface_allowed_address_pairs``, map property + ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair``, + ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip`` + , + ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix`` + * ``OS::ContrailV2::InstanceIP`` property ``instance_ip_address`` + * ``OS::ContrailV2::InstanceIP`` property ``subnet_uuid`` + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-52530 + + A VNF's Heat Orchestration Template's Nested YAML file + **MUST** be in the same directory hierarchy as the VNF's Heat + Orchestration Templates. + + +.. container:: note + + 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 Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-83015 + + A VNF's ``{network-role}`` assigned to an external network **MUST** + be different than the ``{network-role}`` assigned to the VNF's + internal networks, if internal networks exist. + + +ONAP Heat Networking > Internal Networks +---------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-35666` + + If a VNF has an internal network, the VNF Heat Orchestration Template + **MUST** include the heat resources to create the internal network. + + A VNF's Internal Network is created using Neutron Heat Resources + (i.e., ``OS::Neutron::Net``, ``OS::Neutron::Subnet``) and/or + Contrail Heat Resources (i.e., ``OS::ContrailV2::VirtualNetwork``, + ``ContrailV2::NetworkIpam``). + + +.. container:: note + + :need:`R-22688` + + When a VNF's Heat Orchestration Template creates an internal network + (per the ONAP definition, see Requirements R-52425 and R-46461 + and R-35666) and the internal network needs to be shared between modules + within a VNF, the internal network **MUST** be created either in the + + * the base module + * a nested YAML file invoked by the base module + + and the base module **MUST** contain an output parameter that provides + either the network UUID or network name. + + * If the network UUID value is used to reference the network, the output + parameter name in the base module **MUST** follow the naming convention + ``int_{network-role}_net_id`` + * If the network name in is used to reference the network, the output + parameter name in the base template **MUST** follow the naming convention + ``int_{network-role}_net_name`` + + ``{network-role}`` **MUST** be the network-role of the internal network + created in the Base Module. + + The Base Module Output Parameter MUST be declared in the ``parameters:`` + section of the Incremental Module(s) where the ``OS::Neutron::Port`` + resource(s) is attaching to the internal network. + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-32025 + + When a VNF creates two or more internal networks, each internal + network **MUST** be assigned a unique ``{network-role}`` in the context + of the VNF for use in the VNF's Heat Orchestration Template. + + +.. container:: note + + R-68936 + + When a VNF creates an internal network, a network role, referred to as + the ``{network-role}`` **MUST** be assigned to the internal network + for use in the VNF's Heat Orchestration Template. + + +.. container:: note + + R-69874 + + A VNF's ``{network-role}`` assigned to an internal network **MUST** + be different than the ``{network-role}`` assigned to the VNF's external + networks. + + +ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > parameters > constraints +---------------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-00011` + + A VNF's Heat Orchestration Template's parameter defined + in a nested YAML file + **SHOULD NOT** 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`` **MAY** have a parameter constraint defined. + + +ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > resources > properties +-------------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-10834` + + A VNF's Heat Orchestration Template resource attribute ``property:`` + **MUST NOT** use more than two levels of nested ``get_param`` intrinsic + functions when deriving a property value. SDC does not support nested + ``get_param`` with recursive lists (i.e., a list inside list). + The second ``get_param`` in a nested lookup must directly derive its value + without further calls to ``get_param`` functions. + + * Example of valid nesting: + + * ``name: {get_param: [ {vm-type}_names, {get_param : index } ] }`` + + * Examples of invalid nesting. SDC will not support these examples since + there is an array inside array. + + * ``name: {get_param: [ {vm-type}_names, { get_param: [ indexlist, 0 ] } ] }`` + * ``name: {get_param: [ {vm-type}_names, { get_param: [ indexlist1, { get_param: indexlist2 } ] } ] }`` + + +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 string + ``base`` or ``volume``. + + +ONAP Heat Orchestration Templates Overview > ONAP Heat Orchestration Template Filenames > Cinder Volume Modules +--------------------------------------------------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-589037` + + A VNF Heat Orchestration Template's Cinder Volume Module ``resources:`` + section + **MUST** only be defined using one of the following: + + * one of more ``OS::Cinder::Volume`` resources + * one or more ``OS::Heat::ResourceGroup`` resources that call a nested YAML + file that contains only ``OS::Cinder::Volume`` resources + * a resource that calls a nested YAML file (static nesting) that contains + only ``OS::Cinder::Volume`` resources + + +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 string ``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 string ``base``. + + +ONAP Heat Orchestration Templates Overview > ONAP VNF Modularity Overview +------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-90748` + + A VNF's Heat Orchestration Template's Resource ``OS::Cinder::Volume`` + **MAY** be defined in an Incremental Module. + + +.. container:: note + + :need:`R-03251` + + A VNF's Heat Orchestration Template's Resource ``OS::Cinder::Volume`` + **MAY** be defined in a Cinder Volume Module. + + +.. container:: note + + :need:`R-46119` + + A VNF's Heat Orchestration Template's Resource ``OS::Cinder::Volume`` + **MAY** be defined in a Base Module. + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-20974 + + At orchestration time, the VNF's Base Module **MUST** + be deployed first, prior to any incremental modules. + + +ONAP Heat Orchestration Templates Overview > ONAP VNF On-Boarding +----------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-348813` + + The VNF's Heat Orchestration Template's ZIP file **MUST NOT** include + a binary image file. + + +.. container:: note + + :need:`R-511776` + + When a VNF's Heat Orchestration Template is ready + to be on-boarded to ONAP, + all files composing the VNF Heat Orchestration Template + **MUST** be placed in a flat (i.e., non-hierarchical) directory and + archived using ZIP. The resulting ZIP file is uploaded into ONAP. + + +ONAP Heat Orchestration Templates Overview > Output Parameters > ONAP Base Module Output Parameters +--------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-52753` + + VNF's Heat Orchestration Template's Base Module's output parameter's + name and type **MUST** match the VNF's Heat Orchestration Template's + incremental Module's name and type. + + +.. container:: note + + :need:`R-22608` + + When a VNF's Heat Orchestration Template's Base Module's output + parameter is declared as an input parameter in an Incremental Module, + the parameter attribute ``constraints:`` **SHOULD NOT** be declared. + + +ONAP Heat Orchestration Templates Overview > Output Parameters > ONAP Volume Module Output Parameters +----------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-20547` + + When an ONAP Volume Module Output Parameter is declared as an input + parameter in a base or an incremental module Heat Orchestration + Template, parameter constraints **SHOULD NOT** be declared. + + +.. 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. + + +.. 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. + + +ONAP Heat Support of Environment Files +-------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-599443` + + A parameter enumerated in a + VNF's Heat Orchestration Template's environment file **MUST** be declared + in the + corresponding VNF's Heat Orchestration Template's YAML file's + ``parameters:`` section. + + +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 ONAP 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. + + ONAP 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 TOSCA VNFD Requirements > VNF CSAR Package > VNF Package Contents +---------------------------------------------------------------------- + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + 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. + + +ONAP TOSCA VNFD or PNFD Requirements > TOSCA PNF Descriptor > Capability Types +------------------------------------------------------------------------------ + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-177937` + + The PNFD provided by a PNF vendor **MUST** comply with the following + Capabilities Types as specified in ETSI NFV-SOL001 standard: + + - tosca.datatypes.nfv.VirtualLinkable + + +ONAP TOSCA VNFD or PNFD Requirements > TOSCA PNF Descriptor > Data Types +------------------------------------------------------------------------ + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-484843` + + The PNFD provided by a PNF vendor **MUST** comply with the following Data + Types as specified in ETSI NFV-SOL001 standard: + + - tosca.datatypes.nfv.CpProtocolData + + - tosca.datatypes.nfv.AddressData + + - tosca.datatypes.nfv.L2AddressData + + - tosca.datatypes.nfv.L3AddressData + + - tosca.datatypes.nfv.LocationInfo + + - tosca.datatypes.nfv.CivicAddressElement + + +ONAP TOSCA VNFD or PNFD Requirements > TOSCA PNF Descriptor > General +--------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-24632` + + The PNF Descriptor (PNFD) provided by PNF vendor **MUST** comply with + TOSCA/YAML based Service template for PNF descriptor specified in ETSI + NFV-SOL001. + + +ONAP TOSCA VNFD or PNFD Requirements > TOSCA PNF Descriptor > Node Types +------------------------------------------------------------------------ + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-535009` + + The PNFD provided by a PNF vendor **MUST** comply with the following Node + Types as specified in ETSI NFV-SOL001 standard: + + - tosca.nodes.nfv.PNF + + - tosca.nodes.nfv.PnfExtCp + + - tosca.nodes.nfv.Cp + + +ONAP TOSCA VNFD or PNFD Requirements > TOSCA PNF Descriptor > Policy Types +-------------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-596064` + + The PNFD provided by a PNF vendor **MUST** comply with the following Policy + Types as specified in ETSI NFV-SOL001 standard: + + - tosca.datatypes.nfv.SecurityGroupRule + + +ONAP TOSCA VNFD or PNFD Requirements > TOSCA PNF Descriptor > Relationship Types +-------------------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-64064` + + The PNFD provided by a PNF vendor **MUST** comply with the following + Relationship Types as specified in ETSI NFV-SOL001 standard: + + - tosca.datatypes.nfv.VirtualLinksTo + + +ONAP TOSCA VNFD or PNFD Requirements > TOSCA VNF Descriptor > General +--------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-65486` + + The VNFD **MUST** comply with ETSI GS NFV-SOL001 specification endorsing + the above mentioned NFV Profile and maintaining the gaps with the + requirements specified in ETSI GS NFV-IFA011 standard. + + +ONAP TOSCA VNFD or PNFD Requirements > VNF or PNF CSAR Package > VNF Package Contents +------------------------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-146092` + + If one or more non-MANO artifact(s) is included in the VNF or PNF TOSCA CSAR + package, the Manifest file in this CSAR package **MUST** contain: non-MANO + artifact set which MAY contain following ONAP public tag. + + - onap_ves_events: contains VES registration files + + - onap_pm_dictionary: contains the PM dictionary files + + - onap_yang_modules: contains Yang module files for configurations + + - onap_ansible_playbooks: contains any ansible_playbooks + + - onap_others: contains any other non_MANO artifacts, e.g. informational + documents + + +.. container:: note + + :need:`R-221914` + + The VNF or PNF package **MUST** contain a a human-readable change log text + file. The Change Log file keeps a history describing any changes in the VNF + or PNF package. The Change Log file is kept up to date continuously from + the creation of the CSAR package. + + +.. container:: note + + :need:`R-293901` + + The VNF or PNF CSAR PACKAGE with TOSCA-Metadata **MUST** include following + additional keywords pointing to TOSCA files: + + - ETSI-Entry-Manifest + + - ETSI-Entry-Change-Log + + Note: For a CSAR containing a TOSCA-Metadata directory, which includes + the TOSCA.meta metadata file. The TOSCA.meta metadata file includes block_0 + with the Entry-Definitions keyword pointing to a TOSCA definitions YAML + file used as entry for parsing the contents of the overall CSAR archive. + + +.. container:: note + + :need:`R-57019` + + The PNF TOSCA CSAR PACKAGE Manifest file **MUST** start with the PNF + package metadata in the form of a name-value pairs. Each pair shall appear + on a different line. The name is specified as following: + + - pnfd_provider + + - pnfd_name + + - pnfd_release_date_time + + - pnfd_archive_version + + +.. container:: note + + :need:`R-795126` + + The VNF TOSCA CSAR package Manifest file **MUST** start with the VNF + package metadata in the form of a name-value pairs. Each pair shall appear + on a different line. The name is specified as following: + + - vnf_provider_id + + - vnf_product_name + + - vnf_release_date_time + + - vnf_package_version + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-10087` + + The VNF or PNF CSAR package **MUST** include all artifacts required by + ETSI GS NFV-SOL004 including Manifest file, VNFD or PNFD (or Main + TOSCA/YAML based Service Template) and other optional artifacts. + + +.. container:: note + + :need:`R-40820` + + The VNF or PNF TOSCA PACKAGE **MUST** enumerate all of the open source + licenses their VNF(s) incorporate. CSAR License directory as per ETSI + SOL004. + + for example ROOT\\Licenses\\ **License_term.txt** + + +.. container:: note + + :need:`R-01123` + + The VNF or PNF package Manifest file **MUST** contain: VNF or PNF 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. + + +ONAP TOSCA VNFD or PNFD Requirements > VNF or PNF CSAR Package > VNF Package Structure and Format +------------------------------------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-506221` + + The VNF or PNF TOSCA CSAR file **MUST** be a zip file with .csar extension. + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-51347` + + The VNF or PNF CSAR 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 or PNF package provided by a VNF or PNF vendor **MUST** be with + TOSCA-Metadata directory (CSAR Option 1) as specified in + ETSI GS NFV-SOL004. + + **Note:** SDC supports only the CSAR Option 1 in Dublin. The Option 2 + will be considered in future ONAP releases. + + +ONAP TOSCA VNFD or PNFD Requirements > VNF or PNF CSAR Package > VNF or PNF Package Authenticity and Integrity +-------------------------------------------------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-130206` + + If the VNF or PNF CSAR Package utilizes Option 2 for package security, then + the complete CSAR file **MUST** contain a Digest (a.k.a. hash) for each of + the components of the VNF or PNF package. The table of hashes is included + in the package manifest file, which is signed with the VNF or PNF provider + private key. In addition, the VNF or PNF provider MUST include a signing + certificate that includes the VNF or PNF provider public key, following a + TOSCA pre-defined naming convention and located either at the root of the + archive or in a predefined location specified by the TOSCA.meta file with + the corresponding entry named "ETSI-Entry-Certificate". + + +.. container:: note + + :need:`R-787965` + + If the VNF or PNF CSAR Package utilizes Option 2 for package security, then + the complete CSAR file **MUST** be digitally signed with the VNF or PNF + provider private key. The VNF or PNF provider delivers one zip file + consisting of the CSAR file, a signature file and a certificate file that + includes the VNF or PNF provider public key. The certificate may also be + included in the signature container, if the signature format allows that. + The VNF or PNF provider creates a zip file consisting of the CSAR file with + .csar extension, signature and certificate files. The signature and + certificate files must be siblings of the CSAR file with extensions .cms + and .cert respectively. + + +PNF Plug and Play > PNF Plug and Play +------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-256347` + + The PNF **MUST** support one of the protocols for a Service Configuration + message exchange between the PNF and PNF Controller (in ONAP): + a) Netconf/YANG, b) Chef, or c) Ansible. + + Note: The PNF Controller may be VF-C, APP-C or SDN-C based on the + PNF and PNF domain. + + +.. container:: note + + :need:`R-106240` + + The following VES Events **SHOULD** 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. + + +Resource IDs +------------ + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-11690` + + When a VNF's Heat Orchestration Template's Resource ID contains an + ``{index}``, the ``{index}`` is a numeric value that **MUST** start at + zero and **MUST** increment by one. + + As stated in R-16447, + *a VNF's <resource ID> MUST be unique across all Heat + Orchestration Templates and all HEAT Orchestration Template + Nested YAML files that are used to create the VNF*. While the ``{index}`` + will start at zero in the VNF, the ``{index}`` may not start at zero + in a given Heat Orchestration Template or HEAT Orchestration Template + Nested YAML file. + + +Resource IDs > Contrail Heat Resources Resource ID Naming Convention > OS::ContrailV2::InstanceIp +------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-53310` + + A VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::InstanceIp`` Resource ID + that is configuring an IPv4 Address on a virtual machine interface + (i.e., OS::ContrailV2::VirtualMachineInterface) + attached to an external network + **MUST** use the naming convention + + * ``{vm-type}_{vm-type_index}_{network-role}_vmi_{vmi_index}_IP_{index}`` + + where + + * ``{vm-type}`` is the vm-type + * ``{vm-type_index}`` references the instance of the ``{vm-type}`` in + the VNF. The + ``{vm-type_index}`` is a numeric value that **MUST** start at zero + in the VNF and + **MUST** increment by one each time a new instance of a ``{vm-type}`` + is referenced. + * ``{network-role}`` is the network-role of the network that the + virtual machine interface is attached to + * ``{vmi_index}`` references the instance of the virtual machine interface + on the ``{vm-type}`` attached to ``{network-role}`` network. The + ``{vmi_index}`` is a numeric value that **MUST** start at zero on an + instance of a ``{vm-type}`` and **MUST** increment by one each time a + new virtual machine interface is defined on the instance of the + ``{vm-type}`` attached to ``{network-role}`` network. + * ``IP`` signifies that an IPv4 address is being configured + * ``{index}`` references the instance of the IPv4 address configured + on the virtual machine interface. The ``{index}`` is a numeric value + that **MUST** start at zero on an + instance of a virtual machine interface and **MUST** increment by one + each time a new IPv4 address is configured on the + virtual machine interface. + + +.. container:: note + + :need:`R-87563` + + A VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::InstanceIp`` Resource ID + that is configuring an IPv6 Address on a virtual machine interface + (i.e., OS::ContrailV2::VirtualMachineInterface) + attached to an internal network + **MUST** use the naming convention + + * ``{vm-type}_{vm-type_index}_int_{network-role}_vmi_{vmi_index}_v6_IP_{index}`` + + where + + * ``{vm-type}`` is the vm-type + * ``{vm-type_index}`` references the instance of the ``{vm-type}`` in + the VNF. The + ``{vm-type_index}`` is a numeric value that **MUST** start at zero + in the VNF and + **MUST** increment by one each time a new instance of a ``{vm-type}`` + is referenced. + * ``{network-role}`` is the network-role of the network + that the port is attached to + * ``{vmi_index}`` references the instance of the virtual machine interface + on the ``{vm-type}`` attached to ``{network-role}`` network. The + ``{vmi_index}`` is a numeric value that **MUST** start at zero on an + instance of a ``{vm-type}`` and **MUST** increment by one each time a + new virtual machine interface is defined on the instance of the + ``{vm-type}`` attached to ``{network-role}`` network. + * ``v6_IP`` signifies that an IPv6 address is being configured + * ``{index}`` references the instance of the IPv6 address configured + on the virtual machine interface. The ``{index}`` is a numeric value + that **MUST** start at zero on an + instance of a virtual machine interface and **MUST** increment by one + each time a new IPv6 address is configured on the + virtual machine interface. + + +.. container:: note + + :need:`R-62187` + + A VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::InstanceIp`` Resource ID + that is configuring an IPv4 Address on a virtual machine interface + (i.e., OS::ContrailV2::VirtualMachineInterface) + attached to an internal network + **MUST** use the naming convention + + * ``{vm-type}_{vm-type_index}_int_{network-role}_vmi_{vmi_index}_IP_{index}`` + + where + + * ``{vm-type}`` is the vm-type + * ``{vm-type_index}`` references the instance of the ``{vm-type}`` in + the VNF. The + ``{vm-type_index}`` is a numeric value that **MUST** start at zero + in the VNF and + **MUST** increment by one each time a new instance of a ``{vm-type}`` + is referenced. + * ``{network-role}`` is the network-role of the network + that the port is attached to + * ``{vmi_index}`` references the instance of the virtual machine interface + on the ``{vm-type}`` attached to ``{network-role}`` network. The + ``{vmi_index}`` is a numeric value that **MUST** start at zero on an + instance of a ``{vm-type}`` and **MUST** increment by one each time a + new virtual machine interface is defined on the instance of the + ``{vm-type}`` attached to ``{network-role}`` network. + * ``IP`` signifies that an IPv4 address is being configured + * ``{index}`` references the instance of the IPv4 address configured + on the virtual machine interface. The ``{index}`` is a numeric value + that **MUST** start at zero on an + instance of a virtual machine interface and **MUST** increment by one + each time a new IPv4 address is configured on the + virtual machine interface. + + +.. container:: note + + :need:`R-46128` + + A VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::InstanceIp`` Resource ID + that is configuring an IPv6 Address on a virtual machine interface + (i.e., OS::ContrailV2::VirtualMachineInterface) + attached to an external network + **MUST** use the naming convention + + * ``{vm-type}_{vm-type_index}_{network-role}_vmi_{vmi_index}_v6_IP_{index}`` + + where + + * ``{vm-type}`` is the vm-type + * ``{vm-type_index}`` references the instance of the ``{vm-type}`` in + the VNF. The + ``{vm-type_index}`` is a numeric value that **MUST** start at zero + in the VNF and + **MUST** increment by one each time a new instance of a ``{vm-type}`` + is referenced. + * ``{network-role}`` is the network-role of the network + that the port is attached to + * ``{vmi_index}`` references the instance of the virtual machine interface + on the ``{vm-type}`` attached to ``{network-role}`` network. The + ``{vmi_index}`` is a numeric value that **MUST** start at zero on an + instance of a ``{vm-type}`` and **MUST** increment by one each time a + new virtual machine interface is defined on the instance of the + ``{vm-type}`` attached to ``{network-role}`` network. + * ``v6_IP`` signifies that an IPv6 address is being configured + * ``{index}`` references the instance of the IPv6 address configured + on the virtual machine interface. The ``{index}`` is a numeric value + that **MUST** start at zero on an + instance of a virtual machine interface and **MUST** increment by one + each time a new IPv6 address is configured on the + virtual machine interface. + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-20947 + + A VNF's Heat Orchestration Template's Resource ``OS::ContrailV2::InstanceIp`` + that is configuring an IPv4 Address on a sub-interface port attached to a + sub-interface network Resource ID **MUST** use the naming convention + + * ``{vm-type}_{vm-type_index}_subint_{network-role}_vmi_{vmi_index}_IP_{index}`` + + where + + * ``{vm-type}`` is the vm-type + * ``{vm-type_index}`` is the instance of the ``{vm-type}`` + * ``{network-role}`` is the network-role of the network + that the port is attached to + * ``{vmi_index}`` is the instance of the the virtual machine interface + (e.g., port) on the vm-type + attached to the network of ``{network-role}`` + * ``IP`` signifies that an IPv4 address is being configured + * ``{index}`` is the index of the IPv4 address + + +.. container:: note + + R-88540 + + A VNF's Heat Orchestration Template's Resource ``OS::ContrailV2::InstanceIp`` + that is configuring an IPv6 Address on a sub-interface port attached to a + sub-interface network Resource ID **MUST** + use the naming convention + + * ``{vm-type}_{vm-type_index}_subint_{network-role}_vmi_{vmi_index}_v6_IP_{index}`` + + where + + * ``{vm-type}`` is the vm-type + * ``{vm-type_index}`` is the instance of the ``{vm-type}`` + * ``{network-role}`` is the network-role of the network + that the port is attached to + * ``{vmi_index}`` is the instance of the the virtual machine interface + (e.g., port) on the vm-type + attached to the network of ``{network-role}`` + * ``v6_IP`` signifies that an IPv6 address is being configured + * ``{index}`` is the index of the IPv6 address + + +Resource IDs > Contrail Heat Resources Resource ID Naming Convention > OS::ContrailV2::ServiceTemplate +------------------------------------------------------------------------------------------------------ + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-14447` + + A VNF's Heat Orchestration Template's Resource ``OS::ContrailV2::ServiceTemplate`` + Resource ID **MAY** use the naming convention + + * ``{vm-type}_RST_{index}`` + + where + + * ``{vm-type}`` is the vm-type + * ``RST`` signifies that it is the Resource Service Template + * ``{index}`` is the index. + The ``{index}`` starts at zero and increments by one + (as described in R-11690). + + +Resource IDs > Contrail Heat Resources Resource ID Naming Convention > OS::ContrailV2::VirtualMachineInterface +-------------------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-50468` + + A VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::VirtualMachineInterface`` Resource ID + that is attaching to an internal network + **MUST** use the naming convention + + * ``{vm-type}_{vm-type_index}_int_{network-role}_vmi_{vmi_index}`` + + where + + * ``{vm-type}`` is the vm-type + * ``{vm-type_index}`` references the instance of the ``{vm-type}`` in + the VNF. The + ``{vm-type_index}`` is a numeric value that **MUST** start at zero + in the VNF and + **MUST** increment by one each time a new instance of a ``{vm-type}`` + is referenced. + * ``{network-role}`` is the network-role of the network + that the port (i.e. virtual machine interface) is attached to + * ``{vmi_index}`` references the instance of the virtual machine interface + on the ``{vm-type}`` attached to ``{network-role}`` network. The + ``{vmi_index}`` is a numeric value that **MUST** start at zero on an + instance of a ``{vm-type}`` and **MUST** increment by one each time a + new virtual machine interface is defined on the instance of the + ``{vm-type}`` attached to ``{network-role}`` network. + + +.. container:: note + + :need:`R-96253` + + A VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::VirtualMachineInterface`` Resource ID + that is attaching to an external network + **MUST** use the naming convention + + * ``{vm-type}_{vm-type_index}_{network-role}_vmi_{vmi_index}`` + + where + + * ``{vm-type}`` is the vm-type + * ``{vm-type_index}`` references the instance of the ``{vm-type}`` in + the VNF. The + ``{vm-type_index}`` is a numeric value that **MUST** start at zero + in the VNF and + **MUST** increment by one each time a new instance of a ``{vm-type}`` + is referenced. + * ``{network-role}`` is the network-role of the network + that the port (i.e. virtual machine interface) is attached to + * ``{vmi_index}`` references the instance of the virtual machine interface + on the ``{vm-type}`` attached to ``{network-role}`` network. The + ``{vmi_index}`` is a numeric value that **MUST** start at zero on an + instance of a ``{vm-type}`` and **MUST** increment by one each time a + new virtual machine interface is defined on the instance of the + ``{vm-type}`` attached to ``{network-role}`` network. + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-54458 + + A VNF's Heat Orchestration Template's Resource + ``OS::ContrailV2::VirtualMachineInterface`` that is attaching to a sub-interface + network Resource ID **MUST** use the naming convention + + * ``{vm-type}_{vm-type_index}_subint_{network-role}_vmi_{vmi_index}`` + + where + + * ``{vm-type}`` is the vm-type + * ``{vm-type_index}`` is the instance of the ``{vm-type}`` + * ``{network-role}`` is the network-role of the network + that the port (i.e. virtual machine interface) is attached to + * ``{vmi_index}`` is the instance of the the vmi on the vm-type + attached to the network of ``{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 + + * ``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 IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Cinder::Volume +------------------------------------------------------------------------------------------ + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-87004` + + A VNF's Heat Orchestration Template's Resource + ``OS::Cinder::Volume`` + Resource ID + **SHOULD** + use the naming convention + + * ``{vm-type}_volume_{index}`` + + where + + * ``{vm-type}`` is the vm-type + * ``{index}`` starts at zero and increments by one (as described in R-11690) + + +Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Cinder::VolumeAttachment +---------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-86497` + + A VNF's Heat Orchestration Template's Resource + ``OS::Cinder::VolumeAttachment`` + Resource ID + **SHOULD** + use the naming convention + + * ``{vm-type}_volume_attachment_{index}`` + + where + + * ``{vm-type}`` is the vm-type + * ``{index}`` starts at zero and increments by one (as described in R-11690) + + +Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Heat::ResourceGroup +----------------------------------------------------------------------------------------------- + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-64197 + + A VNF's Heat Orchestration Template's Resource ``OS::Heat::ResourceGroup`` + Resource ID that creates sub-interfaces **MUST** use the naming convention + + * ``{vm-type}_{vm-type_index}_subint_{network-role}_port_{port-index}_subinterfaces`` + + where + + * ``{vm-type}`` is the vm-type + * ``{vm-type_index}`` is the instance of the ``{vm-type}`` + * ``{network-role}`` is the network-role of the networks + that the sub-interfaces attach to + * ``{port-index}`` is the instance of the the port on the vm-type + attached to the network of ``{network-role}`` + + +Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Neutron::Port +----------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-68520` + + A VNF's Heat Orchestration Template's Resource ``OS::Neutron::Port`` + that is creating a *Reserve Port* with an IPv6 address Resource ID + **SHOULD** use the naming convention + + * ``reserve_port_{vm-type}_{network-role}_floating_v6_ip_{index}`` + + where + + * ``{vm-type}`` is the vm-type + * ``{network-role}`` is the network-role of the network + that the port is attached to + * ``{index}`` is the instance of the IPv6 *Reserve Port* + for the vm-type attached to the network of ``{network-role}``. + The ``{index}`` starts at zero and increments by one + (as described in R-11690). + + +.. container:: note + + :need:`R-27469` + + A VNF's Heat Orchestration Template's Resource ``OS::Neutron::Port`` + that is creating a *Reserve Port* with an IPv4 address Resource ID + **SHOULD** use the naming convention + + * ``reserve_port_{vm-type}_{network-role}_floating_ip_{index}`` + + where + + * ``{vm-type}`` is the vm-type + * ``{network-role}`` is the network-role of the network + that the port is attached to + * ``{index}`` is the instance of the IPv4 *Reserve Port* + for the vm-type attached to the network of ``{network-role}``. + The ``{index}`` starts at zero and increments by one + (as described in R-11690). + + +.. container:: note + + :need:`R-26351` + + A VNF's Heat Orchestration Template's Resource ``OS::Neutron::Port`` + that is attaching to an internal network Resource ID **MUST** + use the naming convention + + * ``{vm-type}_{vm-type_index}_int_{network-role}_port_{port-index}`` + + where + + * ``{vm-type}`` is the vm-type + * ``{vm-type_index}`` references the instance of the ``{vm-type}`` in + the VNF. The + ``{vm-type_index}`` is a numeric value that **MUST** start at zero + in the VNF and + **MUST** increment by one each time a new instance of a ``{vm-type}`` + is referenced. + * ``{network-role}`` is the network-role of the network + that the port is attached to + * ``{port_index}`` references the instance of the port on the ``{vm-type}`` + attached to ``{network-role}`` network. The + ``{port_index}`` is a numeric value that **MUST** start at zero on an + instance of a ``{vm-type}`` and **MUST** increment by one each time a + new port is defined on the instance of the ``{vm-type}`` attached to + ``{network-role}`` network. + + +.. container:: note + + :need:`R-20453` + + A VNF's Heat Orchestration Template's Resource ``OS::Neutron::Port`` + that is attaching to an external network Resource ID + **MUST** use the naming convention + + * ``{vm-type}_{vm-type_index}_{network-role}_port_{port-index}`` + + where + + * ``{vm-type}`` is the vm-type + * ``{vm-type_index}`` references the instance of the ``{vm-type}`` in + the VNF. The + ``{vm-type_index}`` is a numeric value that **MUST** start at zero + in the VNF and + **MUST** increment by one each time a new instance of a ``{vm-type}`` + is referenced. + * ``{network-role}`` is the network-role of the network + that the port is attached to + * ``{port_index}`` references the instance of the port on the ``{vm-type}`` + attached to ``{network-role}`` network. The + ``{port_index}`` is a numeric value that **MUST** start at zero on an + instance of a ``{vm-type}`` and **MUST** increment by one each time a + new port is defined on the instance of the ``{vm-type}`` attached to + ``{network-role}`` network. + + +Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Neutron::Subnet +------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-59434` + + A VNF's Heat Orchestration Template's Resource ``OS::Neutron::Subnet`` + Resource ID **SHOULD** use the naming convention + + * ``int_{network-role}_subnet_{index}`` + + where + + * ``{network-role}`` is the network-role + * ``{index}`` is the ``{index}`` of the subnet of the network. + The ``{index}`` starts at zero and increments by one + (as described in R-11690). + + +Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Nova::Keypair +----------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-24997` + + A VNF's Heat Orchestration Template's Resource ``OS::Nova::Keypair`` applies to + one ``{vm-type}`` Resource ID **SHOULD** use the naming convention + + * ``{vm-type}_keypair_{index}`` + + where + + * ``{network-role}`` is the network-role + * ``{index}`` is the ``{index}`` of the keypair. + The ``{index}`` starts at zero and increments by one + (as described in R-11690). + + +.. container:: note + + :need:`R-65516` + + A VNF's Heat Orchestration Template's Resource ``OS::Nova::Keypair`` applies to + all Virtual Machines in the VNF, the Resource ID **SHOULD** use the naming + convention + + * ``{vnf-type}_keypair`` + + where + + * ``{vnf-type}`` describes the VNF + + +Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Nova::Server +---------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-29751` + + A VNF's Heat Orchestration Template's Resource ``OS::Nova::Server`` + Resource ID + **MUST** use the naming convention + + * ``{vm-type}_server_{index}`` + + where + + * ``{vm-type}`` is the vm-type + * ``{index}`` is the index. + The ``{index}`` **MUST** starts at zero and increment by one + as described in R-11690. + + +Resource Property “name” +------------------------ + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-85734` + + If a VNF's Heat Orchestration Template contains the property ``name`` + for a non ``OS::Nova::Server`` resource, the intrinsic function + ``str_replace`` **MUST** be used in conjunction with the ONAP + supplied metadata parameter ``vnf_name`` to generate a unique value. + Additional data **MAY** be used in the ``str_replace`` construct + to generate a unique value. + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-32408 + + If a VNF's Heat Orchestration Template property ``name`` + for a non ``OS::Nova::Server`` resource uses the intrinsic function + ``str_replace`` in conjunction with the ONAP + supplied metadata parameter ``vnf_name`` and does not create + a unique value, additional data **MUST** be used in the + ``str_replace`` to create a unique value, such as ``OS::stack_name`` + and/or the ``OS::Heat::ResourceGroup`` ``index``. + + +Resource: OS::Neutron::Port - Parameters > Introduction > Items to Note +----------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-681859` + + A VNF's Heat Orchestration Template's ``OS::Neutron::Port`` resource's + + * Resource ID (defined in R-20453) + * property ``network`` parameter name (defined in R-62983 and + R-86182) + * property ``fixed_ips``, map property ``ip_address`` parameter name + (defined in R-40971, R-04697, R-71577, R-23503, R-78380, R-85235, + R-27818, and R-29765) + * property ``fixed_ips``, map property ``subnet`` parameter name + (defined in R-62802, R-15287, R-84123, R-76160) + * property ``allowed_address_pairs`` parameter name (defined in + R-41492 and R-83418) + + **MUST** contain the identical ``{network-role}``. + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-07577 + + If the VNF's ports connected to a unique network (internal or external) + and the port's IP addresses are cloud assigned IP Addresses, + all the IPv4 Addresses **MUST** be from + the same subnet and all the IPv6 Addresses **MUST** be from the + same subnet. + + +.. container:: note + + R-13841 + + A VNF **MAY** have one or more ports connected to a unique + internal network. All VNF ports connected to the unique internal + network **MUST** have cloud assigned IP Addresses + or **MUST** have statically assigned IP addresses. + + +.. container:: note + + R-93272 + + A VNF **MAY** have one or more ports connected to a unique + external network. All VNF ports connected to the unique external + network **MUST** have cloud assigned IP Addresses + or **MUST** have ONAP SDN-C assigned IP addresses. + + +Resource: OS::Neutron::Port - Parameters > Property: allowed_address_pairs, Map Property: ip_address +---------------------------------------------------------------------------------------------------- + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-62300 + + If a VNF has two or more ports that require a Virtual IP Address (VIP), + a VNF's Heat Orchestration Template's Resource + ``OS::Neutron::Port`` property ``allowed_address_pairs`` + map property ``ip_address`` parameter + **MUST** be used. + + +Resource: OS::Neutron::Port - Parameters > Property: allowed_address_pairs, Map Property: ip_address > VIP Assignment, External Networks +---------------------------------------------------------------------------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-41493` + + 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 the IPv4 VIP address and/or IPv6 VIP address + is **not** supported by the ONAP data model, + the property ``allowed_address_pairs`` map property ``ip_address`` + + * Parameter name **MAY** use any naming convention. That is, there is no + ONAP mandatory parameter naming convention. + * Parameter **MAY** be declared as type ``string`` or type + ``comma_delimited_list``. + + And the ``OS::Neutron::Port`` resource **MUST** contain + resource-level ``metadata`` (not property-level). + + And the ``metadata`` format **MUST** must contain the + key value ``aap_exempt`` with a list of all + ``allowed_address_pairs`` map property ``ip_address`` parameters + **not** supported by the ONAP data model. + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. 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 the IPv6 VIP is required to be supported by the ONAP data model, + the property ``allowed_address_pairs`` map property ``ip_address`` + 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``. + + As noted in the introduction to this section, the ONAP data model + can only support one IPv6 VIP address. + + +.. container:: note + + :need:`R-83412` + + If a 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 + property ``allowed_address_pairs`` + map property ``ip_address`` parameter(s) + **MUST NOT** be enumerated in the + VNF's Heat Orchestration Template's Environment File. + + +.. 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 the IPv4 VIP is required to be supported by the ONAP data model, + the property ``allowed_address_pairs`` map property ``ip_address`` + 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``. + + As noted in the introduction to this section, the ONAP data model + can only support one IPv4 VIP address. + + +Resource: OS::Neutron::Port - Parameters > Property: allowed_address_pairs, Map Property: ip_address > VIP Assignment, External Networks, Supported by Automation +----------------------------------------------------------------------------------------------------------------------------------------------------------------- + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-10754 + + If a VNF has two or more ports that + attach to an external network that require a Virtual IP Address (VIP), + and the VNF requires ONAP automation to assign the IP address, + all the Virtual Machines using the VIP address **MUST** + be instantiated in the same Base Module Heat Orchestration Template + or in the same Incremental Module Heat Orchestration Template. + + +.. container:: note + + R-41956 + + If a VNF requires ONAP to assign a Virtual IP (VIP) Address to + ports connected an external network, the port + **MUST NOT** have more than one IPv6 VIP address. + + +.. container:: note + + R-83418 + + The VNF's Heat Orchestration Template's Resource + ``OS::Neutron::Port`` property ``allowed_address_pairs`` + map property ``ip_address`` parameter + ``{vm-type}_{network-role}_floating_v6_ip`` + **MUST NOT** be enumerated in the + VNF's Heat Orchestration Template's Environment File. + + +.. container:: note + + R-91810 + + If a VNF requires ONAP to assign a Virtual IP (VIP) Address to + ports connected an external network, the port + **MUST NOT** have more than one IPv4 VIP address. + + +.. container:: note + + R-98748 + + The VNF's Heat Orchestration Template's Resource + ``OS::Neutron::Port`` property ``allowed_address_pairs`` + map property ``ip_address`` parameter + **MUST** be declared as type ``string``. + + +Resource: OS::Neutron::Port - Parameters > Property: allowed_address_pairs, Map Property: ip_address > VIP Assignment, Internal Networks +---------------------------------------------------------------------------------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-717227` + + 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 Virtual IP (VIP) + address is assigned using the property ``allowed_address_pairs`` + map property ``ip_address``, + the parameter name **MUST** follow the + naming convention + + * ``{vm-type}_int_{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`` + and **MUST** be enumerated in the environment file. + + OR + + the parameter name **MUST** follow the + naming convention + + * ``{vm-type}_int_{network-role}_floating_ips`` + + 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: comma_delimited_list`` + and **MUST** be enumerated in the environment file. + + +.. container:: note + + :need:`R-805572` + + 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 Virtual IP (VIP) + address is assigned + using the property ``allowed_address_pairs`` + map property ``ip_address``, + the parameter name **MUST** follow the + naming convention + + * ``{vm-type}_int_{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`` + and **MUST** be enumerated in the environment file + + OR + + the parameter name **MUST** follow the + naming convention + + * ``{vm-type}_int_{network-role}_floating_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 + + And the parameter **MUST** be declared as ``type: comma_delimited_list`` + and **MUST** be enumerated in the environment file. + + +Resource: OS::Neutron::Port - Parameters > Property: fixed_ips, Map Property: ip_address +---------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. 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 + * ``{index}`` is a numeric value that **MUST** start at zero in a + VNF's Heat Orchestration Template and **MUST** 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 + * ``{index}`` is a numeric value that **MUST** start at zero in a + VNF's Heat Orchestration Template and **MUST** increment by one + + +.. 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 + * ``{index}`` is a numeric value that **MUST** start at zero in a + VNF's Heat Orchestration Template and **MUST** increment by one + + +.. 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 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 + ``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 + * ``{index}`` is a numeric value that **MUST** start at zero in a + VNF's Heat Orchestration Template and **MUST** increment by one + + +Resource: OS::Neutron::Port - Parameters > Property: network +------------------------------------------------------------ + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-86182` + + When the VNF's Heat Orchestration Template's Resource + ``OS::Neutron::Port`` + is in an incremental module and + is attaching to an internal network (per the + ONAP definition, see Requirements R-52425 and R-46461), + the ``network`` parameter name **MUST** + + * follow the naming convention ``int_{network-role}_net_id`` if the + network UUID value is used to reference the network + * follow the naming convention ``int_{network-role}_net_name`` if the + 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. + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + 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. + + +Resource: OS::Nova::Server - Parameters +--------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-304011` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource's + + * Resource ID (defined in R-29751) + * property ``image`` parameter name (defined in R-58670) + * property ``flavor`` parameter name (defined in R-45188) + * property ``name`` parameter name (defined in R-54171 & R-87817) + * property ``networks`` map property ``port`` value which is a + ``OS::Neutron::Port`` Resource ID (defined in R-20453) + referenced using the intrinsic function ``get_attr`` + + **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. And the ``{index}`` in + the ``OS::Nova::Server`` Resource ID (defined in R-29751) **MUST** match + the ``{vm-type_index}`` defined in + the ``OS::Nova::Server`` property ``networks`` map property ``port`` + referenced ``OS::Neutron::Port`` Resource ID (defined in R-20453). + + +Resource: OS::Nova::Server - Parameters > Property: Name +-------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. 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 **MUST** start at + zero in a VNF's Heat Orchestration Template and **MUST** increment by one. + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + 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}``. + + +.. container:: note + + R-85800 + + When the VNF's Heat Orchestration Template's Resource ``OS::Nova::Server`` + property ``name`` parameter is defined as a ``comma_delimited_list``, + a parameter **MUST** be delcared once for all ``OS::Nova::Server`` resources + associated with the ``{vm-type}``. + + +Resource: OS::Nova::Server - Parameters > Property: availability_zone +--------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. 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 ``{index}`` is a numeric value that **MUST** start at zero + in a VNF's Heat Orchestration Templates and **MUST** + increment by one. + + +Resource: OS::Nova::Server Metadata Parameters > environment_context +-------------------------------------------------------------------- + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-62954 + + If a VNF's Heat Orchestration Template's ``OS::Nova::Server Resource`` + ``metadata`` map value parameter ``environment_context`` is passed into a + Nested YAML + file, the parameter name ``environment_context`` **MUST NOT** change. + + +Resource: OS::Nova::Server Metadata Parameters > vf_module_id +------------------------------------------------------------- + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + 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. + + +Resource: OS::Nova::Server Metadata Parameters > vf_module_index +---------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-100410` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` + resource property ``metadata`` **MAY** + contain the key/value pair ``vf_module_index``. + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-50816` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` + resource property ``metadata`` + key/value pair ``vf_module_index`` + value **MUST** be obtained via a ``get_param``. + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + 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 Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-100400` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource + property metadata **SHOULD** contain the key/value pair ``vf_module_name``. + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-68023` + + A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource + property ``metadata`` key/value pair ``vf_module_name`` + value **MUST** + be obtained via a ``get_param``. + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + 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-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 **MAY** be declared as + + * ``vm_role`` and the parameter defined as ``type: string``. + * ``vm_roles`` and the parameter defined as ``type: comma_delimited_list``. + * ``{vm-type}_vm_role`` and the parameter defined as ``type: string``. + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + 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. + + +Resource: OS::Nova::Server Metadata Parameters > vnf_id +------------------------------------------------------- + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + 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. + + +Resource: OS::Nova::Server Metadata Parameters > vnf_name +--------------------------------------------------------- + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + 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. + + +Resource: OS::Nova::Server Metadata Parameters > workload_context +----------------------------------------------------------------- + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + 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. + + +VNF On-boarding and package management > Compute, Network, and Storage Requirements +----------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-96634` + + The VNF or PNF Provider **MUST** provide human readable documentation + (not in the on-boarding package) to describe scaling capabilities to manage + scaling characteristics of the VNF or PNF. + + +.. container:: note + + :need:`R-26881` + + The VNF provider **MUST** provide the binaries and images + needed to instantiate the VNF (VNF and VNFC images). + + +.. container:: note + + :need:`R-35851` + + The VNF HEAT Package **MUST** include VNF topology that describes basic + network and application connectivity internal and external to the VNF + including Link type, KPIs, Bandwidth, latency, jitter, QoS (if applicable) + for each interface. + + +VNF On-boarding and package management > Licensing Requirements +--------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-44569` + + The VNF or PNF provider **MUST NOT** require additional + infrastructure such as a VNF or PNF provider license server for VNF or PNF provider + functions and metrics. + + +.. container:: note + + :need:`R-40827` + + The VNF or PNF provider **MUST** enumerate all of the open + source licenses their VNF or PNF(s) incorporate. + + +.. container:: note + + :need:`R-44125` + + The VNF or PNF provider **MUST** agree to the process that can + be met by Service Provider reporting infrastructure. The Contract + shall define the reporting process and the available reporting tools. + + +.. container:: note + + :need:`R-97293` + + The VNF or PNF provider **MUST NOT** require audits + of Service Provider's business. + + +.. container:: note + + :need:`R-85991` + + The VNF or PNF provider **MUST** provide a universal license key + per VNF or PNF to be used as needed by services (i.e., not tied to a VM + instance) as the recommended solution. The VNF or PNF provider may provide + pools of Unique VNF or PNF License Keys, where there is a unique key for + each VNF or PNF instance as an alternate solution. Licensing issues should + be resolved without interrupting in-service VNFs or PNFs. + + +.. container:: note + + :need:`R-47849` + + The VNF or PNF provider **MUST** support the metadata about + licenses (and their applicable entitlements) as defined in this + specification for VNF or PNF software, and any license keys required to authorize + use of the VNF or PNF software. This metadata will be used to facilitate + onboarding the VNF or PNF into the ONAP environment and automating processes + for putting the licenses into use and managing the full lifecycle of + the licenses. The details of this license model are described in + Tables C1 to C8 in the Appendix. + + Note: License metadata support in ONAP is not currently available + and planned for 1Q 2018. + + +.. container:: note + + :need:`R-85653` + + The VNF or PNF **MUST** provide metrics (e.g., number of sessions, + number of subscribers, number of seats, etc.) to ONAP for tracking + every license. + + +VNF On-boarding and package management > Resource Configuration +--------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-89571` + + The VNF or PNF **MUST** support and provide artifacts for configuration + management using at least one of the following technologies; + a) Netconf/YANG, b) Chef, or c) Ansible. + + Note: The requirements for Netconf/YANG, Chef, and Ansible protocols + are provided separately and must be supported only if the corresponding + protocol option is provided by the VNF or PNF providor. + + +VNF On-boarding and package management > Resource Configuration > Configuration Management via Ansible +------------------------------------------------------------------------------------------------------ + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-75608` + + The VNF or PNF provider **MUST** provide playbooks to be loaded + on the appropriate Ansible Server. + + +.. container:: note + + :need:`R-16777` + + The VNF or PNF provider **MUST** provide a JSON file for each + supported action for the VNF or PNF. The JSON file must contain key value + pairs with all relevant values populated with sample data that illustrates + its usage. The fields and their description are defined in Table B1 + in the Appendix. + + +.. container:: note + + :need:`R-46567` + + The VNF or PNF Package **MUST** include configuration scripts + for boot sequence and configuration. + + +.. container:: note + + :need:`R-16065` + + The VNF or PNF provider **MUST** provide configurable parameters + (if unable to conform to YANG model) including VNF or PNF attributes/parameters + and valid values, dynamic attributes and cross parameter dependencies + (e.g., customer provisioning data). + + +VNF On-boarding and package management > Resource Configuration > Configuration Management via Chef +--------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-18525` + + The VNF or PNF provider **MUST** provide a JSON file for each + supported action for the VNF or PNF. The JSON file must contain key value + pairs with all relevant values populated with sample data that illustrates + its usage. The fields and their description are defined in Tables A1 + and A2 in the Appendix. + + Note: Chef support in ONAP is not currently available and planned for 4Q 2017. + + +.. container:: note + + :need:`R-13390` + + The VNF or PNF provider **MUST** provide cookbooks to be loaded + on the appropriate Chef Server. + + +VNF On-boarding and package management > Resource Configuration > Configuration Management via NETCONF/YANG +----------------------------------------------------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-30278` + + The VNF or PNF provider **SHOULD** provide a Resource/Device YANG model + as a foundation for creating the YANG model for configuration. + + +VNF On-boarding and package management > Resource Control Loop +-------------------------------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-33904` + + The VNF or PNF Package **MUST** include documentation for each KPI, provide + lower and upper limits. + + +.. container:: note + + :need:`R-69877` + + The VNF or PNF Package **MUST** include documentation for each KPI, + identify the suggested actions that need to be performed when a + threshold crossing alert event is recorded. + + +.. container:: note + + :need:`R-01556` + + The VNF or PNF Documentation Package **MUST** describe the + fault, performance, capacity events/alarms and other event records + that are made available by the VNF or PNF. + + +.. container:: note + + :need:`R-16875` + + The VNF or PNF Documentation Package **MUST** include documentation which must + include a unique identification string for the specific VNF or PNF, a description + of the problem that caused the error, and steps or procedures to perform + Root Cause Analysis and resolve the issue. + + +.. container:: note + + :need:`R-22680` + + The VNF or PNF Documentation Package **MUST** describe + any requirements for the monitoring component of tools for Network + Cloud automation and management to provide these records to components + of the VNF or PNF. + + +.. container:: note + + :need:`R-33694` + + The VNF or PNF Package **MUST** include documentation to when applicable, + provide calculators needed to convert raw data into appropriate reporting + artifacts. + + +.. container:: note + + :need:`R-86235` + + The VNF or PNF Package **MUST** include documentation about the monitoring + parameters that must include latencies, success rates, retry rates, load + and quality (e.g., DPM) for the key transactions/functions supported by + the VNF or PNF and those that must be exercised by the VNF or PNF in order to perform + its function. + + +.. container:: note + + :need:`R-73560` + + The VNF or PNF Package **MUST** include documentation about monitoring + parameters/counters exposed for virtual resource management and VNF or PNF + application management. + + +.. container:: note + + :need:`R-53598` + + The VNF or PNF Documentation Package **MUST**, when relevant, + provide a threshold crossing alert point for each KPI and describe the + significance of the threshold crossing. + + +.. container:: note + + :need:`R-48596` + + The VNF or PNF Documentation Package **MUST** describe + the characteristics for the VNF or PNF reliability and high availability. + + +.. container:: note + + :need:`R-01478` + + The VNF or PNF Documentation Package **MUST** describe all + parameters that are available to monitor the VNF or PNF after instantiation + (includes all counters, OIDs, PM data, KPIs, etc.) that must be + collected for reporting purposes. + + +.. container:: note + + :need:`R-90632` + + The VNF Package **MUST** include documentation about KPIs and + metrics that need to be collected at each VM for capacity planning + and performance management purposes. + + +.. container:: note + + :need:`R-22888` + + The VNF or PNF Documentation Package **MUST** provide the VNF or PNF + Policy Description to manage the VNF or PNF runtime lifecycle. The document + must include a description of how the policies (conditions and actions) + are implemented in the VNF or PNF. + + +.. container:: note + + :need:`R-42018` + + The VNF or PNF Package **MUST** include documentation which must include + all events (fault, measurement for VNF or PNF Scaling, Syslogs, State Change + and Mobile Flow), that need to be collected at each VM, VNFC (defined in `VNF Guidelines <https://onap.readthedocs.io/en/latest/submodules/vnfrqts/guidelines.git/docs/vnf_guidelines.html>`__ ) and for the overall VNF or PNF. + + +.. container:: note + + :need:`R-35960` + + The VNF or PNF Package **MUST** include documentation which must include + all events, severity level (e.g., informational, warning, error) and + descriptions including causes/fixes if applicable for the event. + + +.. container:: note + + :need:`R-56815` + + The VNF or PNF Documentation Package **MUST** describe + supported VNF or PNF scaling capabilities and capacity limits (e.g., number + of users, bandwidth, throughput, concurrent calls). + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-27711 + + The xNF provider **MUST** provide an XML file that contains a + list of xNF error codes, descriptions of the error, and possible + causes/corrective action. + + +.. container:: note + + R-74763 + + The xNF provider **MUST** provide an artifact per xNF that contains + all of the xNF Event Records supported. The artifact should include + reference to the specific release of the xNF Event Stream Common Event + Data Model document it is based on. (e.g., + `VES Event Listener <https://onap.readthedocs.io/en/latest/submodules/vnfsdk/model.git/docs/files/VESEventListener.html>`__) + + +VNF On-boarding and package management > Resource Description +------------------------------------------------------------- + + +Requirements Added +~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-025941` + + The VNF or PNF PROVIDER **MUST** provide FM Meta Data to support the + analysis of fault events delivered to DCAE. The Meta Data must be + included in the VES Registration YAML file with each fault event + supported by that NF at onboarding time and the Meta Data must follow + the VES Event Listener and VES Event Registration Specifications. + + +.. container:: note + + :need:`R-816745` + + The VNF or PNF PROVIDER *MUST* provide the Service Provider with + PM Meta Data (PM Dictionary) to support the analysis of PM events delivered + to DCAE. The PM Dictionary is to be provided as a separate YAML artifact at + onboarding and must follow the VES Event Listener Specification and VES + Event Registration Specification which contain the format and content + required. + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-98617` + + The VNF Provider **MUST** provide documentation regarding any dependency + (e.g. affinity, anti-affinity) the VNF has on other VNFs and resources. + + +.. container:: note + + :need:`R-36280` + + The VNF or PNF Documentation Package **MUST** describe the + VNF or PNF Functional Capabilities that are utilized to operationalize the + VNF or PNF and compose complex services. + + +.. container:: note + + :need:`R-00068` + + The VNF or PNF Documentation Package **MUST** include + a description of parameters that can be monitored for the VNF or PNF + and event records (status, fault, flow, session, call, control + plane, etc.) generated by the VNF or PNF after instantiation. + + +.. container:: note + + :need:`R-69565` + + The VNF or PNF Documentation Package **MUST** describe the VNF or PNF + Management APIs, which must include information and tools for ONAP to + deploy and configure (initially and ongoing) the VNF or PNF application(s) + (e.g., NETCONF APIs) which includes a description of configurable + parameters for the VNF or PNF and whether the parameters can be configured + after VNF or PNF instantiation. + + +.. container:: note + + :need:`R-22346` + + The VNF or PNF package **MUST** provide :ref:`VES Event Registration <ves_event_registration_3_2>` + for all VES events provided by that VNF or PNF. + + +.. container:: note + + :need:`R-384337` + + The VNF Documentation Package **MUST** contain a list of the files within the VNF + package that are static during the VNF's runtime. + + +.. container:: note + + :need:`R-84366` + + The VNF or PNF Documentation Package **MUST** describe the + VNF or PNF Functional APIs that are utilized to build network and + application services. This document describes the externally exposed + functional inputs and outputs for the VNF or PNF, including interface + format and protocols supported. + + +.. container:: note + + :need:`R-00156` + + The VNF or PNF Documentation Package **MUST** describe the VNF or PNF + Management APIs, which must include information and tools for + ONAP to monitor the health of the VNF or PNF (conditions that require + healing and/or scaling responses). + + +.. container:: note + + :need:`R-12678` + + The VNF or PNF Documentation Package **MUST** include a + description of runtime lifecycle events and related actions (e.g., + control responses, tests) which can be performed for the VNF or PNF. + + +.. container:: note + + :need:`R-66070` + + For HEAT package, 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. + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-77707 + + The xNF provider **MUST** include a Manifest File that + contains a list of all the components in the xNF package. + + +VNF On-boarding and package management > Testing +------------------------------------------------ + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-58775` + + The VNF provider **MUST** provide software components that + can be packaged with/near the VNF, if needed, to simulate any functions + or systems that connect to the VNF system under test. This component is + necessary only if the existing testing environment does not have the + necessary simulators. + + +.. container:: note + + :need:`R-43958` + + The VNF Documentation Package **MUST** describe + the tests that were conducted by the VNF provider and the test results. + + +.. container:: note + + :need:`R-04298` + + The VNF provider **MUST** provide their testing scripts to + support testing. + + +VNF Resiliency > Monitoring & Dashboard +--------------------------------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-34957` + + The VNF **MUST** provide a method of metrics gathering for each + layer's performance to identify variances in the allocations so + they can be addressed. + + +{network-role} +-------------- + + +Requirements Changed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + :need:`R-05201` + + When a VNF connects to two or more unique networks, each + network **MUST** be assigned a unique ``{network-role}`` + in the context of the VNF for use in the VNF's Heat Orchestration + Template. + + +.. container:: note + + :need:`R-69014` + + When a VNF's port connects to an internal network or external network, + a network role, referred to + as the ``{network-role}`` **MUST** be assigned to the network for + use in the VNF's Heat Orchestration Template. The ``{network-role}`` + is used in the VNF's Heat Orchestration Template resource IDs + and resource property parameter names. + + +.. 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_`` + * **MUST NOT** end in the string: ``_v6`` + * **MUST NOT** contain the strings ``_#_``, where ``#`` is a number + * **MUST NOT** end in the string: ``_#``, where ``#`` is a number + + +{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 identical number of + ports connecting to the identical networks and requiring the identical + IP address configuration. + + +Requirements Removed +~~~~~~~~~~~~~~~~~~~~ + + +.. container:: note + + R-66729 + + A VNF's Heat Orchestration Template's Resource that is associated with a + unique Virtual Machine type **MUST** include ``{vm-type}`` as part of the + resource ID. + + +.. container:: note + + 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. + diff --git a/docs/release-notes.rst b/docs/release-notes.rst index 834c927..cfbd23d 100644 --- a/docs/release-notes.rst +++ b/docs/release-notes.rst @@ -15,6 +15,54 @@ VNFRQTS Project Release Notes ============================== +Version: 4.0.0 +-------------- + +:Release Date: 2019-5-30 + +A detailed summary of all requirement changes per section can be found +:doc:`here <changes-by-section-dublin>`. + +A higher level summary of changes as well as non-requirement impacting +changes can be found below. + +**New Features** + - Added information for PNF + - Added Release notes to higher level + - Added CICD build to generate requirements and create traceability matrix + - Added Traceability matrix with dynamic links + - Moved VES spec + - Created RST Requirement generator in wiki + +**Bug Fixes** + - Fixed typos + - Fixed metadata errors + - Fixed XNF -> PNF or VNF + - Cleaning requirements for TOSCA/HEAT + - Cleaning requirements for VNF or PNF + +**Known Issues** + - Links that refer to "latest" version are static. Please report + any broken links. + - Wiki RST generator has been disabled, please use local make_ids.py + to create new requirements. + - Traceability matrix table rendering issues. + +**Security Issues** + - None + +**Upgrade Notes** + - If you would like to add requirements, you **MUST** follow + `instructions on Wiki <https://wiki.onap.org/display/DW/VNFRQTS+How+to+Contribute>`__. + - If you would like to see a list of JIRA tickets closed in Dublin, + `please click here <https://jira.onap.org/projects/VNFRQTS/versions/10474>`_. + +**Deprecation Notes** + - None + +**Other** + - None + Version: 3.0.1 -------------- |