``ConfigModify``: The APPC client is requesting a configuration
update to a subset of the total configuration parameters of an VNF or PNF or to
apply customer specific configurations. The configuration update is
-typically done while the VNF or PNF is in service and should not disrupt traffic.
-This command requires exclusive access rights of the VNF or PNF.
+typically done while the VNF or PNF is in service and should not disrupt
+traffic. This command requires exclusive access rights of the VNF or PNF.
``ConfigBackup``: The APPC client is requesting a backup of the
configuration parameters where the parameters are stored on the VNF or PNF.
the configuration parameters to the VNF or PNF that were saved by ConfigBackup
command. This command is typically requested as part of an orchestration
flow for scenarios such as a software upgrade where the software upgrade
-may have failed and the VNF or PNF needs to be rolled back to the prior configuration.
-When the ConfigRestore command is executed, the VNF or PNF configuration parameters
-which were backed to persistent preserved storage are applied to the VNF or PNF
-(replacing existing parameters). The ConfigRestore is typically done while
-the VNF or PNF is not in service (i.e., in a maintenance state). This command
-requires exclusive access rights of the VNF or PNF.
+may have failed and the VNF or PNF needs to be rolled back to the prior
+configuration.
+When the ConfigRestore command is executed, the VNF or PNF configuration
+parameters which were backed to persistent preserved storage are applied to the
+VNF or PNF (replacing existing parameters). The ConfigRestore is typically done
+while the VNF or PNF is not in service (i.e., in a maintenance state). This
+command requires exclusive access rights of the VNF or PNF.
``ConfigScaleOut``: The APPC/SDN-C client is requesting that a configuration
be applied after the VNF instance has been scaled out (i.e., one or more
**The following commands are needed to support various lifecycle management
flows where the VNF may need to be removed for service.**
-Full details on the APIs can be found in the :doc:`APPC LCM API Guide <../../../../appc.git/docs/APPC LCM API Guide/APPC LCM API Guide>`
+Full details on the APIs can be found in the
+:doc:`APPC LCM API Guide <../../../../appc.git/docs/APPC LCM API Guide/APPC LCM API Guide>`
``DistributeTraffic`` The APPC/SDN-C client is requesting a change to
traffic distribution (redistribution) done by a traffic balancing/distribution
or very low weight to VNF instance). The VNF application remains in an active
state.
-``QuiesceTraffic`` The APPC/SDN-C client is requesting the VNF or PNF gracefully
-stop traffic (aka block and drain traffic). The method for quiescing traffic
-is specific to the VNF or PNF architecture. The action is completed when all
-(in-flight transactions) traffic has stopped. The VNF or PNF remains in an active
-state where the VNF or PNF is able to process traffic (initiated using the
-ResumeTraffic action).
+``QuiesceTraffic`` The APPC/SDN-C client is requesting the VNF or PNF
+gracefully stop traffic (aka block and drain traffic). The method for quiescing
+traffic is specific to the VNF or PNF architecture. The action is completed
+when all (in-flight transactions) traffic has stopped. The VNF or PNF remains
+in an active state where the VNF or PNF is able to process traffic (initiated
+using the ResumeTraffic action).
``ResumeTraffic``: The APPC/SDN-C client is requesting the VNF or PNF resume
processing traffic. The method to resume traffic is specific to the VNF or PNF
processes. The processes can be restarted using the StartApplication command.
``StartApplication``: The APPC client is requesting that the application
-running on the VNF or PNF is started. Get ready to process traffic. Traffic processing
-can be resumed using the ResumeTraffic command.
+running on the VNF or PNF is started. Get ready to process traffic.
+Traffic processing can be resumed using the ResumeTraffic command.
**The following commands are needed to support software upgrades, in-place or
-other type of software upgrade. The VNF or PNF instance may be removed from service
-for the upgrade.**
+other type of software upgrade. The VNF or PNF instance may be removed from
+service for the upgrade.**
``UpgradePrecheck``: The APPC/SDN-C client is requesting a confirmation that
the VNF or PNF can (and needs to) be upgraded to a specific software version
pre-loaded to a specified location.
``UpgradePostCheck``: The APPC/SDN-C client is requesting a confirmation that
-the VNF or PNF software upgrade has been completed successfully (VNF or PNF upgraded to
-the new software version). Checking software installed and running on the VNF or PNF
-matches software version, of the newly upgraded software, is one of the
-recommended checks.
+the VNF or PNF software upgrade has been completed successfully (VNF or PNF
+upgraded to the new software version). Checking software installed and running
+on the VNF or PNF matches software version, of the newly upgraded software, is
+one of the recommended checks.
-``UpgradeBackup``: The APPC/SDN-C client is requesting that the VNF or PNF is backed
-up prior to the UpgradeSoftware.
+``UpgradeBackup``: The APPC/SDN-C client is requesting that the VNF or PNF is
+backed up prior to the UpgradeSoftware.
-``UpgradeBackOut``: The APPC/SDN-C client is requesting that the VNF or PNF upgrade
-is backed out (in the event that the SoftwareUpgrade or UpgradePostCheck
-failed).
+``UpgradeBackOut``: The APPC/SDN-C client is requesting that the VNF or PNF
+upgrade is backed out (in the event that the SoftwareUpgrade or
+UpgradePostCheck failed).
.. req::
:id: R-328086
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
``HealthCheck`` The APPC/SDN-C client is requesting a health check over the
-entire scope of the VNF or PNF. The VNF or PNF must be 100% healthy, ready to take requests
-and provide services, with all VNF or PNF required capabilities ready to provide
-services and with all active and standby resources fully ready with no open
-MINOR, MAJOR or CRITICAL alarms. This is expected to be the default in the
-event that no parameter is passed to the Healthcheck playbook, cookbook, etc.
-
-Some VNFs or PNFs may support and desire to run partial healthchecks and receive a
-successful response when partial health check completes without errors.
-The parameter name used by HealthCheck playbook to request non-default
+entire scope of the VNF or PNF. The VNF or PNF must be 100% healthy, ready to
+take requests and provide services, with all VNF or PNF required capabilities
+ready to provide services and with all active and standby resources fully ready
+with no open MINOR, MAJOR or CRITICAL alarms. This is expected to be the
+default in the event that no parameter is passed to the Healthcheck playbook,
+cookbook, etc.
+
+Some VNFs or PNFs may support and desire to run partial healthchecks and
+receive a successful response when partial health check completes without
+errors. The parameter name used by HealthCheck playbook to request non-default
partial health check is healthcheck_type. Example of health check types
could be healthcheck_type=GuestOS, healthcheck_type=noDB,
healthcheck_type=noConnections, healthcheck_type=IgnoreAlarms, etc..
order to communicate with the VNF or PNF instance. The supported protocols are
NETCONF, Ansible, Chef, and REST.
-NETCONF and REST require the VNF or PNF to implement a server which supports the RPC
-or REST calls.
+NETCONF and REST require the VNF or PNF to implement a server which supports
+the RPC or REST calls.
Ansible and Chef require the use of a Ansible or Chef server which communicates
with the APPC/SDN-C (northbound) and the VNF or PNF VM's (southbound).
industry standards.
VNF or PNF Configuration via NETCONF Requirements
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Configuration Management
+++++++++++++++++++++++++++
:keyword: MUST
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.
+ management (OAM) functions available from the supplier for VNFs or PNFs
+ using the supplied YANG code and associated NETCONF servers.
.. req::
:id: R-60656
:keyword: MUST
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.
+ 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.
Examples of responses when HealthCheck runs and is able to provide a healthy
or unhealthy response:
(https://downloads.chef.io/).
VNF or PNF Configuration via Chef Requirements
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chef Client Requirements
+++++++++++++++++++++++++
:keyword: MUST
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.
+ (roles/cookbooks/recipes) required to execute VNF or PNF actions requested
+ by ONAP for loading on appropriate Chef Server.
.. req::
:id: R-26567
:keyword: MUST NOT
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.
+ for the VNF or PNF in roles/cookbooks/recipes invoked for a VNF or PNF
+ action.
.. req::
:id: R-37929
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).
+ 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).
.. req::
:id: 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).
+ any errors for actions that change state of the VNF or PNF (e.g.,
+ configure).
.. req::
:id: R-65755
tasks which contain all the necessary resources and execution capabilities
to take the necessary action on one or more target VMs (and/or VNFCs)
of the VNF. ONAP will utilize the framework of an Ansible Server that
-will host all Ansible artifacts and run playbooks to manage VNFs or PNFs that support
-Ansible.
+will host all Ansible artifacts and run playbooks to manage VNFs or PNFs that
+support Ansible.
VNF or PNF Configuration via Ansible Requirements
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ansible Client Requirements
+++++++++++++++++++++++++++++
:keyword: MUST
:updated: casablanca
- 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.
+ 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
:keyword: MUST
:introduced: casablanca
- The VNF or PNF **MUST** permit authentication, using root account, only right
- after instantiation and until post-instantiation configuration is
+ The VNF or PNF **MUST** permit authentication, using root account, only
+ right after instantiation and until post-instantiation configuration is
completed.
.. req::
:introduced: casablanca
The VNF or PNF **MUST** provide the ability to remove root access once
- post-instantiation configuration (Configure) is completed.
+ post-instantiation configuration (Configure) is completed.
.. req::
:id: R-91745
:keyword: MUST
:introduced: casablanca
- 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
+ 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.
.. req::
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.
+ Cluster owner of the issued and assigned mechanized user ID.
.. req::
:id: R-94567
:keyword: MUST
:introduced: casablanca
- 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.
+ 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.
.. req::
:id: R-67124
:keyword: MUST
:introduced: casablanca
- 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.
+ 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.
.. req::
:id: R-24482
:keyword: MUST
:introduced: casablanca
- 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.
+ 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.
Ansible Playbook Requirements
+++++++++++++++++++++++++++++++
:introduced: casablanca
The VNF or PNF **MUST** support Ansible playbooks that are compatible with
- Ansible version 2.6 or later.
+ Ansible version 2.6 or later.
.. req::
:id: R-40293
:updated: casablanca
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.
+ 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.
.. req::
:id: R-33280
:keyword: MUST
:updated: casablanca
- 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
+ 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.
+ use, e.g., VNF or PNF instantiation. Recommendation is to avoid these
+ instance specific, manually created in advance of instantiation, files.
The Ansible Server will determine if a playbook invoked to execute an
VNF or PNF action finished successfully or not using the "PLAY_RECAP" summary
:keyword: MUST
:updated: casablanca
- 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.
+ 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.
.. req::
:id: R-51442
:keyword: MUST
:updated: casablanca
- The VNF or PNF **MUST** return control from Ansible Playbooks only after all
- tasks performed by playbook are fully complete, signaling that the
+ 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.
Detailed examples:
``StopApplication Playbook`` – StopApplication Playbook shall return control
-and a completion status response only after VNF or PNF application is fully stopped,
-all processes/services stopped.
+and a completion status response only after VNF or PNF application is fully
+stopped, all processes/services stopped.
``StartApplication Playbook`` – StartApplication Playbook shall return control
-and a completion status only after all VNF or PNF application services are fully up,
-all processes/services started and ready to provide services.
+and a completion status only after all VNF or PNF application services are
+fully up, all processes/services started and ready to provide services.
**NOTE**: Start Playbook should not be declared complete/done after starting
one or several processes that start the other processes.
HealthCheck Playbook:
SUCCESS – HealthCheck success shall be returned (return code 0) by a
-Playbook or Cookbook only when VNF or PNF is 100% healthy, ready to take requests
-and provide services, with all VNF or PNF required capabilities ready to provide
-services and with all active and standby resources fully ready with no
-open MINOR, MAJOR or CRITICAL alarms.
+Playbook or Cookbook only when VNF or PNF is 100% healthy, ready to take
+requests and provide services, with all VNF or PNF required capabilities ready
+to provide services and with all active and standby resources fully ready with
+no open MINOR, MAJOR or CRITICAL alarms.
NOTE: In some cases, a switch may need to be turned on, but a VNF or PNF
reported as healthy, should be ready to take service requests or be
already processing service requests successfully.
A successful execution of a health-check playbook shall create one response
-file (per VNF or PNF) in JSON format, named after the VNF or PNF instance, followed by
-"_results.txt" (<VNF or PNF instance name>_results.txt) to be provided as a response
-to the requestor, indicating health-check was executed and completed
-successfully, example: vfdb9904v_results.txt, with the following contents:
+file (per VNF or PNF) in JSON format, named after the VNF or PNF instance,
+followed by "_results.txt" (<VNF or PNF instance name>_results.txt) to be
+provided as a response to the requestor, indicating health-check was executed
+and completed successfully, example: vfdb9904v_results.txt, with the following
+contents:
.. code-block:: java
**NOTE**: See section 7.3.1.4 for comments on support of partial health checks.
FAILURE – A health check playbook shall return a non-zero return code in
-case VNF or PNF is not 100% healthy because one or more VNF or PNF application processes
-are stopped or not ready to take service requests or because critical or
-non-critical resources are not ready or because there are open MINOR, MAJOR
+case VNF or PNF is not 100% healthy because one or more VNF or PNF application
+processes are stopped or not ready to take service requests or because critical
+or non-critical resources are not ready or because there are open MINOR, MAJOR
or CRITICAL traps/alarms or because there are issues with the VNF or PNF that
need attention even if they do not impact services provided by the VNF or PNF.
A failed health-check playbook shall also create one file (per VNF or PNF), in
-JSON format, named after the VNF or PNF instance name, followed by "_results.txt"
-to indicate health-check was executed and found issues in the health of
-the VNF or PNF. This is to differentiate from failure to run health-check playbook
-or playbook tasks to verify the health of the VNF or PNF,
-example: vfdb9904v_results.txt, with the following contents:
+JSON format, named after the VNF or PNF instance name, followed by
+"_results.txt" to indicate health-check was executed and found issues in the
+health of the VNF or PNF. This is to differentiate from failure to run
+health-check playbook or playbook tasks to verify the health of the VNF or
+PNF, example: vfdb9904v_results.txt, with the following contents:
.. code-block:: java
See `VNF or PNF REST APIs`_ for additional details on HealthCheck.
-Some VNFs or PNFs may support and desire to run partial health checks and receive
-a successful response when partial health check completes without errors.
-The parameter name used by HealthCheck playbook to request non-default
+Some VNFs or PNFs may support and desire to run partial health checks and
+receive a successful response when partial health check completes without
+errors. The parameter name used by HealthCheck playbook to request non-default
partial health check is healthcheck_type. Example of health check types
could be healthcheck_type=GuestOS, healthcheck_type=noDB,
healthcheck_type=noConnections, healthcheck_type=IgnoreAlarms, etc.. This
:keyword: SHOULD
:introduced: casablanca
- 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.
+ 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.
.. req::
:id: R-49911
+-------------+--------------------+--------------------+--------------------+
|**Command** |**NETCONF Support** |**Chef Support** |**Ansible** |
+=============+====================+====================+====================+
-|General |For each RPC, the |VNF or PNF Vendor must |VNF Vendor must |
-|Comments |appropriate RPC |provide any |provide an Ansible |
+|General |For each RPC, the |VNF or PNF Vendor |VNF Vendor must |
+|Comments |appropriate RPC |must provide any |provide an Ansible |
| |operation is listed.|necessary roles, |playbook to retrieve|
| | |cookbooks, recipes |the running |
| | |to retrieve the |configuration from a|
| | |running |VNF and place the |
| | |configuration from |output on the |
-| | |a VNF or PNF and place it |Ansible server in |
-| | |in the respective |a manner aligned |
-| | |Node Objects |with playbook |
-| | |'PushJobOutput' |requirements listed |
-| | |attribute of all |in this document. |
-| | |nodes in NodeList | |
-| | |when triggered |The PlaybookName |
-| | |by a chef-client |must be provided |
-| | |run. |in the JSON file. |
+| | |a VNF or PNF and |Ansible server in |
+| | |place it in the |a manner aligned |
+| | |respective Node |with playbook |
+| | |Objects |requirements listed |
+| | |'PushJobOutput' |in this document. |
+| | |attribute of all | |
+| | |nodes in NodeList |The PlaybookName |
+| | |when triggered by a |must be provided |
+| | |chef-client run. |in the JSON file. |
| | | | |
| | |The JSON file for |NodeList must list |
-| | |this VNF or PNF action is |IP addresses or DNS |
-| | |required to set |supported FQDNs of |
-| | |"PushJobFlag" to |an example VNF |
-| | |"True" and |on which to |
+| | |this VNF or PNF |IP addresses or DNS |
+| | |action is required |supported FQDNs of |
+| | |to set "PushJobFlag"|an example VNF |
+| | |to "True" and |on which to |
| | |"GetOutputFlag" to |execute playbook. |
| | |"True". The "Node" | |
| | |JSON dictionary | |
+-------------+--------------------+--------------------+--------------------+
|Configure, |The <edit-config> |Supported via a |Supported via a |
|ModifyConfig |operation loads all |cookbook that |playbook that |
-| |or part of a |updates the VNF or PNF |updates the VNF |
-| |specified data set |configuration. |configuration. |
+| |or part of a |updates the VNF or |updates the VNF |
+| |specified data set |PNF configuration. |configuration. |
| |to the specified | | |
| |target database. If | | |
| |there is no | | |
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
:need:`R-24482`
an inventory hosts file in a supported format; with site group that shall
be used to add site specific configurations to the target xNF VM(s) as
needed.
-
+
.. container:: note
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
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
The xNF **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 xNF VM authentication.
-
+
.. container:: note
The xNF **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/xNF names.
-
+
.. container:: note
The xNF **MUST** permit authentication, using root account, only right
after instantiation and until post-instantiation configuration is
completed.
-
+
.. container:: note
The xNF **MUST** provide the ability to remove root access once
post-instantiation configuration (Configure) is completed.
-
+
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
xNF 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
**Note**: Ansible Server itself may be used to upload new SSH public
keys onto supported xNFs.
-
+
.. container:: note
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
The xNF **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
instantiation to support Ansible. This may include creating Mechanized user
ID(s) used by the Ansible Server(s) on VNF VM(s) and uploading and
installing new SSH keys used by the mechanized use ID(s).
-
+
Configuration Management > Ansible Standards and Capabilities > xNF Configuration via Ansible Requirements > Ansible Playbook Requirements
------------------------------------------------------------------------------------------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The xNF 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
The xNF **MUST** support Ansible playbooks that are compatible with
Ansible version 2.6 or later.
-
+
.. container:: note
The xNF 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.
-
+
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
input by playbooks, shall be provisioned (and distributed) in advance of
use, e.g., xNF instantiation. Recommendation is to avoid these instance
specific, manually created in advance of instantiation, files.
-
+
.. container:: note
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
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
with the name '<xNF name>_results.txt'. All playbook output results, for
all xNF VMs, to be provided as a response to the request, must be written
to this response file.
-
+
.. container:: note
by invocation of **one** playbook [#7.3.4]_. The playbook will be responsible
for executing all necessary tasks (as well as calling other playbooks)
to complete the request.
-
+
.. container:: note
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
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.
-
+
Configuration Management > Chef Standards and Capabilities > xNF Configuration via Chef Requirements > Chef Roles/Requirements
------------------------------------------------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
(see Section 7.c, APPC/SDN-C APIs and Behavior, for list of xNF
actions and requirements), when triggered by a chef-client run list
in JSON file.
-
+
Configuration Management > Controller Interactions With xNF > Configuration Commands
------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
:need:`R-20741`
The xNF **MUST** support APPC/SDN-C ``Configure`` command.
-
+
.. container:: note
:need:`R-94084`
The xNF **MUST** support APPC/SDN-C ``ConfigScaleOut`` command.
-
+
.. container:: note
:need:`R-32981`
The xNF **MUST** support APPC ``ConfigBackup`` command.
-
+
.. container:: note
:need:`R-48247`
The xNF **MUST** support APPC ``ConfigRestore`` command.
-
+
.. container:: note
:need:`R-56385`
The xNF **MUST** support APPC ``Audit`` command.
-
+
.. container:: note
:need:`R-19366`
The xNF **MUST** support APPC ``ConfigModify`` command.
-
+
Configuration Management > Controller Interactions With xNF > HealthCheck and Failure Related Commands
------------------------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
:need:`R-41430`
The xNF **MUST** support APPC/SDN-C ``HealthCheck`` command.
-
+
Configuration Management > Controller Interactions With xNF > Lifecycle Management Related Commands
---------------------------------------------------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The xNF **MUST**, if serving as a distribution point or anchor point for
steering point from source to destination, support the ONAP Controller's
``DistributeTraffic`` command.
-
+
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
:need:`R-12706`
The xNF **MUST** support APPC/SDN-C ``QuiesceTraffic`` command.
-
+
.. container:: note
:need:`R-49466`
The xNF **MUST** support APPC/SDN-C ``UpgradeSoftware`` command.
-
+
.. container:: note
:need:`R-82811`
The xNF **MUST** support APPC ``StartApplication`` command.
-
+
.. container:: note
:need:`R-07251`
The xNF **MUST** support APPC/SDN-C ``ResumeTraffic`` command.
-
+
.. container:: note
:need:`R-45856`
The xNF **MUST** support APPC/SDN-C ``UpgradePostCheck`` command.
-
+
.. container:: note
:need:`R-65641`
The xNF **MUST** support APPC/SDN-C ``UpgradeBackOut`` command.
-
+
.. container:: note
:need:`R-83146`
The xNF **MUST** support APPC ``StopApplication`` command.
-
+
.. container:: note
:need:`R-97343`
The xNF **MUST** support APPC/SDN-C ``UpgradeBackup`` command.
-
+
.. container:: note
:need:`R-19922`
The xNF **MUST** support APPC/SDN-C ``UpgradePrecheck`` command.
-
+
Configuration Management > NETCONF Standards and Capabilities > xNF Configuration via NETCONF Requirements > NETCONF Server Requirements
----------------------------------------------------------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The xNF **MUST** implement the protocol operation:
``discard-changes()`` - Revert the candidate configuration
data store to the running configuration.
-
+
.. container:: note
The xNF **MUST** implement the protocol operation:
``get-config(source, filter`` - Retrieve a (filtered subset of
a) configuration from the configuration data store source.
-
+
.. container:: note
The xNF **MUST** implement the protocol operation:
``commit(confirmed, confirm-timeout)`` - Commit candidate
configuration data store to the running configuration.
-
+
.. container:: note
``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
The xNF **MUST** implement the protocol operation:
``lock(target)`` - Lock the configuration data store target.
-
+
.. container:: note
The xNF **MUST** implement the protocol operation:
``close-session()`` - Gracefully close the current session.
-
+
.. container:: note
The xNF **MUST** implement the protocol operation:
``kill-session(session``- Force the termination of **session**.
-
+
.. container:: note
The xNF **MUST** implement the protocol operation:
``unlock(target)`` - Unlock the configuration data store target.
-
+
.. container:: note
The xNF **SHOULD** implement the protocol operation:
``delete-config(target)`` - Delete the named configuration
data store target.
-
+
.. container:: note
The xNF **SHOULD** implement the protocol operation:
``copy-config(target, source)`` - Copy the content of the
configuration data store source to the configuration data store target.
-
+
Contrail Resource Parameters > Contrail Network Parameters > External Networks
------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
* **MUST** be declared as type ``string``
* **MUST NOT** be enumerated in the VNF's Heat Orchestration Template's
Environment File
-
+
Heat > Cinder Volumes
---------------------
Requirements Removed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
"outputs" in the volume template for each Cinder volume
resource universally unique identifier (UUID) (i.e. ONAP
Volume Template Output Parameters).
-
+
Heat > Heat Orchestration Template Format > Heat Orchestration Template Structure > resources > metadata
--------------------------------------------------------------------------------------------------------
Requirements Removed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
A VNF's Heat Orchestration Template's OS::Nova::Server
resource **MUST** contain the attribute "metadata".
-
+
Heat > Heat Template Constructs > Heat Files Support (get_file)
---------------------------------------------------------------
Requirements Removed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
When using the intrinsic function get_file, the included files
**MUST** have unique file names within the scope of the VNF.
-
+
Heat > Heat Template Constructs > Nested Heat Template Requirements
-------------------------------------------------------------------
Requirements Removed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The VNF Heat Orchestration Template **MUST** have unique
file names within the scope of the VNF for a nested heat yaml file.
-
+
Heat > Networking > External Networks
-------------------------------------
Requirements Removed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
When a VNF connects to an external network, a network role,
referred to as the '{network-role}' **MUST** be assigned to the
external network for use in the VNF's Heat Orchestration Template.
-
+
Heat > Networking > Internal Networks
-------------------------------------
Requirements Removed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
is created in the same Heat Orchestration Template as the internal network,
then the port resource **MUST** use a 'get_resource' to obtain
the network UUID.
-
+
Heat > ONAP Resource ID and Parameter Naming Convention > Contrail Resource Parameters > Contrail Network Parameters > External Networks
----------------------------------------------------------------------------------------------------------------------------------------
Requirements Removed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
A VNF's Heat Orchestration Template's parameter
'{network-role}_net_fqdn'
**MUST** be declared as type 'string'.
-
+
Heat > ONAP Resource ID and Parameter Naming Convention > Resource: OS::Nova::Server – Metadata Parameters > vm_role
--------------------------------------------------------------------------------------------------------------------
Requirements Removed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
- hard coded in the VNF's Heat Orchestration
Template's OS::Nova::Resource metadata property.
-
+
Heat > ONAP Support of Environment Files
----------------------------------------
Requirements Removed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The VNF Heat Orchestration Template **MUST** have a
corresponding environment file for a Cinder Volume Module.
-
+
.. container:: note
The VNF Heat Orchestration Template **MUST** have a
corresponding environment file for an Incremental module.
-
+
.. container:: note
The VNF Heat Orchestration Template **MUST** have a corresponding
environment file for a Base Module.
-
+
Monitoring & Management > Data Structure Specification of the Event Record
--------------------------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
recommend actions that may be taken at specific thresholds, or if specific
conditions repeat within a specified time interval, using the semantics and
syntax described by the :doc:`VES Event Registration specification<../../../../vnfsdk/module.git/files/VESEventRegistration_3_0>`.
-
+
.. container:: note
The xNF Provider **MAY** require that specific events, identified by their
``eventName``, require that certain fields, which are optional in the common
event format, must be present when they are published.
-
+
.. container:: note
* Required fields
* Optional fields
* Any special handling to be performed for that event
-
+
.. container:: note
event format defined in the
:doc:`VES Event Listener<../../../../vnfsdk/model.git/docs/files/VESEventListener_7_0_1>`
specification.
-
+
Monitoring & Management > Event Records - Data Structure Description > Common Event Header
------------------------------------------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
* ``version`` - the version of the event header
* ``vesEventListenerVersion`` - Version of the VES event listener API spec
that this event is compliant with
-
+
Monitoring & Management > Event Records - Data Structure Description > Miscellaneous
------------------------------------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The VNF, when publishing events, **MUST NOT** send information through
extensible structures if the event specification has explicitly defined
fields for that information.
-
+
.. container:: note
able to collect even if the information field is identified as optional.
However, if the data cannot be collected, then optional fields can be
omitted.
-
+
.. container:: note
words and acronyms used as keys that will be sent through extensible fields.
When an acronym is used as the key, then only the first letter shall be
capitalized.
-
+
Monitoring & Management > Monitoring & Management Requirements > Asynchronous and Synchronous Data Delivery
-----------------------------------------------------------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The xNF **SHOULD** deliver all syslog messages to the VES Collector per the
specifications in Monitoring and Management chapter.
-
+
Monitoring & Management > Monitoring & Management Requirements > Bulk Performance Measurement
---------------------------------------------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The xNF **SHOULD** support File transferring protocol, such as FTPES or SFTP,
when supporting the event-driven bulk transfer of monitoring data.
-
+
.. container:: note
The xNF **SHOULD** support the data schema defined in 3GPP TS 32.435, when
supporting the event-driven bulk transfer of monitoring data.
-
+
.. container:: note
The xNF **SHOULD** support FileReady VES event for event-driven bulk transfer
of monitoring data.
-
+
Monitoring & Management > Monitoring & Management Requirements > Google Protocol Buffers (GPB)
----------------------------------------------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
the state of an xNF resource.
* The required Google Protocol Buffers (GPB) metadata is provided in the
form of .proto files.
-
+
.. container:: note
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
High-volume data is to be encoded and serialized using
`Avro <http://avro.apache.org/>`_, where the Avro [#7.4.1]_ data
format are described using JSON.
-
+
Monitoring & Management > Monitoring & Management Requirements > Reporting Frequency
------------------------------------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The xNF **MUST** report exactly one Measurement event per period
per source name.
-
+
Monitoring & Management > Monitoring & Management Requirements > VNF telemetry via standardized interface
---------------------------------------------------------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The xNF MUST produce heartbeat indicators consisting of events containing
the common event header only per the VES Listener Specification.
-
+
Requirements Removed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The xNF **MUST** provide all telemetry (e.g., fault event
records, syslog records, performance records etc.) to ONAP using the
model, format and mechanisms described in this section.
-
+
Monitoring & Management > Transports and Protocols Supporting Resource Interfaces
---------------------------------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The xNF **SHOULD** deliver event records that fall into the event domains
supported by VES.
-
+
.. container:: note
The xNF **MUST** deliver event records to ONAP using the common transport
mechanisms and protocols defined in this document.
-
+
.. container:: note
The xNF provider **MUST** reach agreement with the Service Provider on
the selected methods for encoding, serialization and data delivery
prior to the on-boarding of the xNF into ONAP SDC Design Studio.
-
+
Monitoring & Management > Transports and Protocols Supporting Resource Interfaces > Bulk Telemetry Transmission
---------------------------------------------------------------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The XNF **MAY** leverage bulk xNF telemetry transmission mechanism, as
depicted in Figure 4, in instances where other transmission methods are not
practical or advisable.
-
+
Monitoring & Management > Transports and Protocols Supporting Resource Interfaces > xNF Telemetry using Google Protocol Buffers
-------------------------------------------------------------------------------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
depicted in Figure 3 to support real-time performance management (PM) data.
In this model the VES events are streamed as binary-encoded GBPs over via
TCP sockets.
-
+
Monitoring & Management > Transports and Protocols Supporting Resource Interfaces > xNF Telemetry using VES/JSON Model
----------------------------------------------------------------------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
for data delivery unless there are specific performance or operational
concerns agreed upon by the Service Provider that would warrant using an
alternate model.
-
+
ONAP Heat Cinder Volumes
------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
* A resource that defines the property ``type`` as a Nested YAML file
(i.e., static nesting) and the Nested YAML contains
an ``OS::Cinder::Volume`` resource
-
+
ONAP Heat Heat Template Constructs > Heat Files Support (get_file)
------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
* more than once in a VNF's Heat Orchestration Template
* in two or more of a VNF's Heat Orchestration Templates
* in a VNF's Heat Orchestration Templates nested YAML file
-
+
.. container:: note
If a VNF's Heat Orchestration Template uses the intrinsic function
``get_file``, the ``get_file`` target **MUST** be referenced in
the Heat Orchestration Template by file name.
-
+
.. container:: note
A VNF's Heat Orchestration Template intrinsic function
``get_file`` **MUST NOT** utilize URL-based file retrieval.
-
+
.. container:: note
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 > Nested Heat Templates > Nested Heat Template Requirements
----------------------------------------------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
A VNF's Heat Orchestration Template **MUST** reference a Nested YAML
file by name. The use of ``resource_registry`` in the VNF's Heat
Orchestration Templates Environment File **MUST NOT** be used.
-
+
ONAP Heat Networking > External Networks
----------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
A VNF **MAY** be connected to zero, one or more than one external
network.
-
+
ONAP Heat Networking > Internal Networks
----------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
for the purpose of reaching VMs in another VNF and/or an
external gateway and/or
external router.
-
+
.. container:: note
A VNF's port connected to an internal network **MUST**
use the port for the purpose of reaching VMs in the same VNF.
-
+
.. container:: note
:need:`R-87096`
A VNF **MAY** contain zero, one or more than one internal network.
-
+
ONAP Heat Orchestration Template Format
---------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
A VNF's Heat Orchestration Template **MUST** be compliant with the
OpenStack Template Guide.
-
+
ONAP Heat Orchestration Template Format > Environment File Format
-----------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
A VNF's Heat Orchestration template **MUST** have a
corresponding environment file.
-
+
.. container:: note
A VNF's Heat Orchestration template's Environment File's
``parameters:`` section **MAY** (or **MAY NOT**) enumerate parameters.
-
+
.. container:: note
A VNF's Heat Orchestration template's Environment File **MUST**
contain the ``parameters:`` section.
-
+
ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > parameters
--------------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
A VNF Heat Orchestration's template's parameter **MUST** be used
in a resource with the exception of the parameters for the
``OS::Nova::Server`` resource property ``availability_zone``.
-
+
.. container:: note
A VNF Heat Orchestration's template's parameter for the
``OS::Nova::Server`` resource property ``availability_zone``
**MAY NOT** be used in any ``OS::Nova::Server``.
-
+
ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > parameters > constraints
----------------------------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
in a non-nested YAML file as type
``number`` **MUST** have a parameter constraint of ``range`` or
``allowed_values`` defined.
-
+
.. container:: note
A VNF's Heat Orchestration Template's parameter defined
in a nested YAML file
**MUST NOT** have a parameter constraint defined.
-
+
.. container:: note
A VNF's Heat Orchestration Template's parameter defined
in a non-nested YAML file as type
``boolean`` **MAY** have a parameter constraint defined.
-
+
.. container:: note
A VNF's Heat Orchestration Template's parameter defined
in a non-nested YAML file as type
``string`` **MAY** have a parameter constraint defined.
-
+
.. container:: note
A VNF's Heat Orchestration Template's parameter defined
in a non-nested YAML file as type
``json`` **MAY** have a parameter constraint defined.
-
+
.. container:: note
A VNF's Heat Orchestration Template's parameter defined
in a non-nested YAML file as
type ``comma_delimited_list`` **MAY** have a parameter constraint defined.
-
+
ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > parameters > default
------------------------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
If a VNF Heat Orchestration Template parameter has a default value,
it **MUST** be enumerated in the environment file.
-
+
ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > parameters > type
---------------------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
* ``json``
* ``comma_delimited_list``
* ``boolean``
-
+
ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > resources
-------------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
A VNF's Heat Orchestration Template's Nested YAML files **MAY**
(or **MAY NOT**) contain the section ``resources:``.
-
+
ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > resources > deletion_policy
-------------------------------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
VNF's Heat Orchestration Template's Resource **MAY** declare the
attribute ``deletion_policy:``.
-
+
ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > resources > external_id
---------------------------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
VNF's Heat Orchestration Template's Resource **MAY** declare the
attribute ``external_id:``.
-
+
ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > resources > metadata
------------------------------------------------------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
A VNF's Heat Orchestration Template's Resource **MAY** declare the
attribute ``metadata``.
-
+
ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > resources > properties
--------------------------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
If a VNF's Heat Orchestration Template resource attribute
``property:`` uses a nested ``get_param``, the nested
``get_param`` **MUST** reference an index.
-
+
ONAP Heat Orchestration Templates Overview > ONAP Heat Orchestration Template Filenames > Base Modules
------------------------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
where ``<text>`` **MUST** contain only alphanumeric characters and
underscores '_' and **MUST NOT** contain the case insensitive word ``base``.
-
+
ONAP Heat Orchestration Templates Overview > ONAP Heat Orchestration Template Filenames > Cinder Volume Modules
---------------------------------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
VNF Heat Orchestration Template's Cinder Volume Module's Environment File
**MUST** be named identical to the VNF Heat Orchestration Template's
Cinder Volume Module with ``.y[a]ml`` replaced with ``.env``.
-
+
.. container:: note
A VNF Heat Orchestration Template's Cinder Volume Module **MUST**
be named identical to the base or incremental module it is supporting with
``_volume`` appended.
-
+
ONAP Heat Orchestration Templates Overview > ONAP Heat Orchestration Template Filenames > Incremental Modules
-------------------------------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
VNF Heat Orchestration Template's Incremental Module file name
**MUST** contain only alphanumeric characters and underscores
'_' and **MUST NOT** contain the case insensitive word ``base``.
-
+
ONAP Heat Orchestration Templates Overview > ONAP Heat Orchestration Template Filenames > Nested Heat file
----------------------------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
VNF Heat Orchestration Template's Nested YAML file name **MUST** contain
only alphanumeric characters and underscores '_' and
**MUST NOT** contain the case insensitive word ``base``.
-
+
ONAP Heat Orchestration Templates Overview > ONAP VNF Modularity Overview
-------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
:need:`R-38474`
A VNF's Base Module **MUST** have a corresponding Environment File.
-
+
.. container:: note
At orchestration time, the VNF's Base Module **MUST**
be deployed first, prior to any incremental modules.
-
+
.. container:: note
:need:`R-53433`
A VNF's Cinder Volume Module **MUST** have a corresponding environment file
-
+
.. container:: note
A VNF's Cinder Volume Module, when it exists, **MUST** be 1:1
with a Base module or Incremental module.
-
+
.. container:: note
an Incremental Module), or
3.) a Cinder Volume Module Heat Orchestration Template (referred to as
Cinder Volume Module).
-
+
.. container:: note
:need:`R-81725`
A VNF's Incremental Module **MUST** have a corresponding Environment File
-
+
.. container:: note
:need:`R-37028`
A VNF **MUST** be composed of one Base Module
-
+
ONAP Heat Orchestration Templates Overview > Output Parameters > ONAP Volume Module Output Parameters
-----------------------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
in the corresponding Base Module or Incremental Module unless the Output
Parameter is of the type ``comma_delimited_list``, then the corresponding
input parameter **MUST** be declared as type ``json``.
-
+
.. container:: note
**MUST** include the
UUID(s) of the Cinder Volumes created in template,
while others **MAY** be included.
-
+
ONAP Heat VNF Modularity
------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
ECOMP will capture the output parameter name and value in the base module
and provide the value to the corresponding parameter(s) in the
incremental module(s).
-
+
ONAP Output Parameter Names > Predefined Output Parameters > OAM Management IP Addresses
----------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
value: {get_param: {vm-type}_{network-role}_ip_{index} }
oam_management_v6_address:
value: {get_param: {vm-type}_{network-role}_v6_ip_{index} }
-
+
.. container:: note
then the parameter **MUST** be obtained by the
resource ``OS::Neutron::Port``
attribute ``ip_address``.
-
+
.. container:: note
database, an output parameter **MUST** be declared in only one of the
VNF's Heat Orchestration Templates and the parameter **MUST** be named
``oam_management_v6_address``.
-
+
ONAP TOSCA VNFD Requirements > TOSCA VNF Descriptor > Capability Types
----------------------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
**tosca.capabilities.nfv.VirtualCompute** and
**tosca.capabilities.nfv.VirtualStorage** includes flavours of VDU
-
+
ONAP TOSCA VNFD Requirements > TOSCA VNF Descriptor > Data Types
----------------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
on TOSCA/YAML constructs specified in draft GS NFV-SOL 001. The node
data definitions/attributes used in VNFD **MUST** comply with the below
table.
-
+
.. container:: note
and is based on TOSCA constructs specified in draft GS NFV-SOL 001.
The LCM configuration data elements used in VNFD **MUST** comply
with the below table.
-
+
ONAP TOSCA VNFD Requirements > TOSCA VNF Descriptor > General
-------------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The following table defines the major TOSCA Types specified in
ETSI NFV-SOL001 standard draft. The VNFD provided by a VNF vendor
**MUST** comply with the below definitions:
-
+
.. container:: note
The VNFD **MAY** include TOSCA/YAML definitions that are not part of
NFV Profile. If provided, these definitions MUST comply with TOSCA
Simple Profile in YAML v.1.2.
-
+
.. container:: note
summarizes the TOSCA definitions agreed to be part of current version
of NFV profile and that VNFD MUST comply with in ONAP Release 2+
Requirements.
-
+
.. container:: note
supported per deployment flavour, and their input parameters;
Note, thatthe actual LCM implementation resides in a different layer,
namely referring to additional template artifacts.
-
+
.. container:: note
The VNFD **MUST** comply with ETSI GS NFV-SOL001 document endorsing
the above mentioned NFV Profile and maintaining the gaps with the
requirements specified in ETSI GS NFV-IFA011 standard.
-
+
ONAP TOSCA VNFD Requirements > TOSCA VNF Descriptor > Interface Types
---------------------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
interface types. An on-boarding entity (ONAP SDC) **MUST** support them.
**tosca.interfaces.nfv.vnf.lifecycle.Nfv** supports LCM operations
-
+
ONAP TOSCA VNFD Requirements > TOSCA VNF Descriptor > Relationship Types
------------------------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
This relationship type represents an association relationship between
the VduCpd's and VirtualLinkDesc node types.
-
+
ONAP TOSCA VNFD Requirements > VNF CSAR Package > VNF Package Contents
----------------------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
identification data must include: an identifier for the VNF, the name
of the VNF as was given by the VNF provider, VNF description, VNF
provider, and version.
-
+
.. container:: note
ETSI GS NFV-SOL004 including Manifest file, VNFD (or Main TOSCA/YAML
based Service Template) and other optional artifacts. CSAR Manifest
file as per SOL004 - for example ROOT\\ **MainServiceTemplate.mf**
-
+
.. container:: note
The VNF provider **MUST** provide their testing scripts to support
testing as specified in ETSI NFV-SOL004 - Testing directory in CSAR
-
+
.. container:: note
Note: Currently, ONAP doesn't have the capability of Image management,
we upload the image into VIM/VNFM manually.
-
+
.. container:: note
their VNF(s) incorporate. CSAR License directory as per ETSI SOL004.
for example ROOT\\Licenses\\ **License_term.txt**
-
+
ONAP TOSCA VNFD Requirements > VNF CSAR Package > VNF Package Structure and Format
----------------------------------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The VNF package **MUST** be arranged as a CSAR archive as specified in
TOSCA Simple Profile in YAML 1.2.
-
+
.. container:: note
**Note:** SDC supports only the CSAR Option 1 in Casablanca. The Option 2
will be considered in future ONAP releases,
-
+
PNF Plug and Play > PNF Plug and Play
-------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
Note: The configuration management and provisioning software are specific
to a vendor architecture.
-
+
.. container:: note
Note: these VES Events are emitted from the PNF to support PNF Plug and
Play, High Volume Measurements, and Fault events respectively.
-
+
.. container:: note
to ascertain which ones are supported up to an including all of the ones
that have been defined. Note: It is expected that there will be a growing
list of supported configuration parameters in future releases of ONAP.
-
+
.. container:: note
Note: this exchange may be either Ansible, Chef, or NetConf depending on
the PNF. Note: The PNF Controller may be VF-C, APP-C or SDN-C based on the
PNF and PNF domain. Note: for R3 (Casablanca) only Ansible is supported.
-
+
.. container:: note
special setup to allow an external PNF to contact the ONAP installation.
For example, in the AT&T network, a maintenance tunnel is used to access
ONAP.
-
+
.. container:: note
have a means to log an error and notify a user when a fault condition
occurs in trying to contact ONAP, authenticate or send a pnfRegistration
event.
-
+
.. container:: note
(Error Case) - If an error is encountered by the PNF during a
Service Configuration exchange with ONAP, the PNF **MAY** log the
error and notify an operator.
-
+
.. container:: note
The PNF Vendor **MAY** provide software version(s) to be supported by PNF
for SDC Design Studio PNF Model. This is set in the PNF Model property
software_versions.
-
+
.. container:: note
The PNF **MAY** support a HTTP connection to the DCAE VES Event Listener.
Note: HTTP is allowed but not recommended.
-
+
.. container:: note
complete installation & commissioning. The management of the VES event
exchange is also a requirement on the PNF to be developed by the PNF
vendor.
-
+
.. container:: note
:need:`R-686466`
The PNF **MUST** support sending a pnfRegistration VES event.
-
+
.. container:: note
When the PNF receives a Service configuration from ONAP, the PNF **MUST**
cease sending the pnfRegistration VES Event.
-
+
.. container:: note
The PNF **MUST** support a HTTPS connection to the DCAE VES Event
Listener.
-
+
.. container:: note
Note: It is up to the specific vendor to design the software management
functions.
-
+
.. container:: note
Note: The ONAP IP address could be provisioned or resolved through
FQDN & DNS.
-
+
.. container:: note
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
(3) HTTP with Username & Password & TLS with server-side
certificate authentication.
-
+
.. container:: note
:need:`R-980039`
The PNF **MUST** send the pnfRegistration VES event periodically.
-
+
.. container:: note
Note: The PNF uses the service configuration request as a semaphore to
stop sending the pnfRegistration sent. See the requirement PNP-5360
requirement.
-
+
Resource IDs
------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
When a VNF's Heat Orchestration Template's resource is associated with a
single internal network, the Resource ID **MUST** contain the text
``int_{network-role}``.
-
+
.. container:: note
external network, the Resource ID **MUST** not contain the ``{vm-type}``
and/or ``{network-role}``/``int_{network-role}``. It also should contain the
term ``shared`` and/or contain text that identifies the VNF.
-
+
.. container:: note
- note that an ``{index}`` value **MAY** separate the ``{vm-type}`` and the
``{network-role}`` and when this occurs underscores **MUST** separate the
three values. (e.g., ``{vm-type}_{index}_{network-role}``).
-
+
.. container:: note
``{vm-type}`` and the ``int_{network-role}`` and when this occurs
underscores **MUST** separate the three values.
(e.g., ``{vm-type}_{index}_int_{network-role}``).
-
+
Resource IDs > Contrail Heat Resources Resource ID Naming Convention > OS::ContrailV2::VirtualNetwork
-----------------------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
Heat Orchestration Template.
Note that option 1 is preferred.
-
+
Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Neutron::Net
----------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
There is no ``{index}`` after ``{network-role}`` because ``{network-role}``
**MUST** be unique in the scope of the VNF's
Heat Orchestration Template.
-
+
Resource: OS::Neutron::Port - Parameters > Introduction > Items to Note
-----------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
* property ``fixed_ips`` map property ``ip_address`` **MUST** be used
* property ``fixed_ips`` map property ``subnet``
**MUST NOT** be used
-
+
.. container:: note
* property ``fixed_ips`` map property ``ip_address`` **MUST NOT** be used
* property ``fixed_ips`` map property ``subnet``
**MAY** be used
-
+
.. container:: note
* property ``fixed_ips`` map property ``ip_address`` **MUST** be used
* property ``fixed_ips`` map property ``subnet``
**MUST NOT** be used
-
+
Resource: OS::Neutron::Port - Parameters > Property: allowed_address_pairs, Map Property: ip_address > VIP Assignment, External Networks, Supported by Automation
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
network
And the parameter **MUST** be declared as type ``string``.
-
+
.. container:: note
network
And the parameter **MUST** be declared as type ``string``.
-
+
Resource: OS::Neutron::Port - Parameters > Property: fixed_ips, Map Property: ip_address
----------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
``{vm-type}_int_{network-role}_ip_{index}``
**MUST** be enumerated in the
VNF's Heat Orchestration Template's Environment File.
-
+
.. container:: note
``{vm-type}_{network-role}_ip_{index}``
**MUST NOT** be enumerated in the
VNF's Heat Orchestration Template's Environment File.
-
+
.. container:: note
``OS::Nova::Server``
* ``{network-role}`` is the {network-role} of the internal
network
-
+
.. container:: note
* ``{network-role}`` is the {network-role} of the internal
network
* the value for ``{index`` must start at zero (0) and increment by one
-
+
.. container:: note
``{vm-type}_int_{network-role}_int_ips``
**MUST** be enumerated in the
VNF's Heat Orchestration Template's Environment File.
-
+
.. container:: note
OS::Nova::Server
* ``{network-role}`` is the {network-role} of the external
network
-
+
.. container:: note
``{vm-type}_{network-role}_v6_ip_{index}``
**MUST NOT** be enumerated in the
VNF's Heat Orchestration Template's Environment File.
-
+
.. container:: note
``{vm-type}_int_{network-role}_v6_ips``
**MUST** be enumerated in the
VNF's Heat Orchestration Template's Environment File.
-
+
.. container:: note
**MUST** be enumerated in the Heat Orchestration
Template's Environment File and IP addresses **MUST** be
assigned.
-
+
.. container:: note
* ``{network-role}`` is the {network-role} of the external
network
* the value for ``{index}`` must start at zero (0) and increment by one
-
+
.. container:: note
``OS::Nova::Server``
* ``{network-role}`` is the {network-role} of the internal
network
-
+
.. container:: note
* ``{network-role}`` is the {network-role} of the external
network
* the value for ``{index}`` must start at zero (0) and increment by one
-
+
.. container:: note
**MUST NOT** be enumerated in the Heat Orchestration
Template's Environment File. ONAP provides the IP address
assignments at orchestration time.
-
+
.. container:: note
``OS::Nova::Server``
* ``{network-role}`` is the {network-role} of the external
network
-
+
.. container:: note
``{vm-type}_int_{network-role}_v6_ip_{index}``
**MUST** be enumerated in the
VNF's Heat Orchestration Template's Environment File.
-
+
.. container:: note
* ``{network-role}`` is the {network-role} of the internal
network
* the value for ``{index}`` must start at zero (0) and increment by one
-
+
Resource: OS::Neutron::Port - Parameters > Property: fixed_ips, Map Property: subnet
------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
Note that the parameter **MUST** be defined as an ``output`` parameter in
the base module.
-
+
.. container:: note
where
* ``{network-role}`` is the network role of the network.
-
+
.. container:: note
``int_{network-role}_v6_subnet_id``
**MUST NOT** be enumerated in the
VNF's Heat Orchestration Template's Environment File.
-
+
.. container:: note
Note that the parameter **MUST** be defined as an ``output`` parameter in
the base module.
-
+
.. container:: note
where
* ``{network-role}`` is the network role of the network.
-
+
.. container:: note
``{network-role}_subnet_id``
**MUST NOT** be enumerated in the
VNF's Heat Orchestration Template's Environment File.
-
+
.. container:: note
``{network-role}_v6_subnet_id``
**MUST NOT** be enumerated in the
VNF's Heat Orchestration Template's Environment File.
-
+
.. container:: note
resource ``OS::Neutron::Port`` property ``fixed_ips``
map property ``subnet`` parameter
**MUST** be declared type ``string``.
-
+
.. container:: note
``int_{network-role}_subnet_id``
**MUST NOT** be enumerated in the
VNF's Heat Orchestration Template's Environment File.
-
+
Resource: OS::Neutron::Port - Parameters > Property: network
------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
property ``network``
parameter **MUST NOT** be enumerated in the Heat Orchestration
Template's Environment File.
-
+
.. container:: note
where ``{network-role}`` is the network-role of the external network
and a ``get_param`` **MUST** be used as the intrinsic function.
-
+
.. container:: note
of the internal network by using the intrinsic function
``get_resource``
and referencing the Resource ID of the internal network.
-
+
.. container:: note
where ``{network-role}`` is the network-role of the internal network and
a ``get_param`` **MUST** be used as the intrinsic function.
-
+
Resource: OS::Nova::Server - Parameters
---------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
**MUST** contain the identical ``{vm-type}``
and **MUST** follow the naming conventions defined
in R-58670, R-45188, R-54171, R-87817, and R-29751.
-
+
Resource: OS::Nova::Server - Parameters > Property: Name
--------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The VNF's Heat Orchestration Template's Resource ``OS::Nova::Server``
property ``name`` value **MUST** be be obtained via a ``get_param``.
-
+
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
``{vm-type}_name_{index}``, where ``{index}`` is a numeric
value that starts at
zero and increments by one.
-
+
.. container:: note
property
``name`` parameter **MUST** be declared as either type ``string``
or type ``comma_delimited_list``.
-
+
Resource: OS::Nova::Server - Parameters > Property: Name > Contrail Issue with Values for OS::Nova::Server Property Name
------------------------------------------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
However, if special characters must be used, the only special characters
supported are: --- \" ! $ ' (\ \ ) = ~ ^ | @ ` { } [ ] > , . _
-
+
Resource: OS::Nova::Server - Parameters > Property: availability_zone
---------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
Resource **MAY** define a parameter for the property
``availability_zone`` that is not utilized in any ``OS::Nova::Server``
resources in the Heat Orchestration Template.
-
+
.. container:: note
``availability_zone_{index}`` where the ``{index}``
**MUST** start at zero and
increment by one.
-
+
Resource: OS::Nova::Server - Parameters > Property: flavor
----------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The VNF's Heat Orchestration Template's Resource ``OS::Nova::Server``
property ``flavor`` value **MUST** be be obtained via a ``get_param``.
-
+
Resource: OS::Nova::Server - Parameters > Property: image
---------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The VNF's Heat Orchestration Template's Resource ``OS::Nova::Server``
property ``image`` value **MUST** be be obtained via a ``get_param``.
-
+
Resource: OS::Nova::Server Metadata Parameters > environment_context
--------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
property
``metadata`` key/value pair ``environment_context`` **MUST NOT**
be enumerated in the Heat Orchestration Template's environment file.
-
+
.. container:: note
property ``metadata``key/value pair ``environment_context``
parameter ``environment_context`` **MUST NOT**
have parameter constraints defined.
-
+
.. container:: note
property ``metadata`` key/value pair ``environment_context``
parameter **MUST** be declared as ``environment_context`` and the
parameter type **MUST** be defined as type: ``string``.
-
+
Resource: OS::Nova::Server Metadata Parameters > vf_module_id
-------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
``metadata`` key/value pair ``vf_module_id`` is passed into a
Nested YAML
file, the key/value pair name ``vf_module_id`` **MUST NOT** change.
-
+
.. container:: note
property ``metadata`` **MUST**
contain the key/value pair ``vf_module_id``
and the value MUST be obtained via a ``get_param``.
-
+
.. container:: note
``metadata`` key/value pair ``vf_module_id`` parameter **MUST**
be declared as ``vf_module_id`` and the parameter **MUST**
be defined as type: ``string``.
-
+
.. container:: note
``metadata`` key/value pair ``vf_module_id`` parameter ``vf_module_id``
**MUST NOT**
have parameter constraints defined.
-
+
.. container:: note
``metadata`` key/value pair ``vf_module_id`` parameter ``vf_module_id``
**MUST NOT**
be enumerated in the Heat Orchestration Template's environment file.
-
+
Resource: OS::Nova::Server Metadata Parameters > vf_module_index
----------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
``metadata`` key/value pair ``vf_module_index`` parameter
``vf_module_index`` **MUST NOT**
be enumerated in the Heat Orchestration Template's environment file.
-
+
.. container:: note
A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
property ``metadata`` key/value pair ``vf_module_index`` **MUST NOT**
have parameter constraints defined.
-
+
.. container:: note
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.
-
+
.. container:: note
resource property ``metadata`` **MAY**
contain the key/value pair ``vf_module_index``
and the value **MUST** be obtained via a ``get_param``.
-
+
.. container:: note
be used in a ``OS::Cinder::Volume`` resource and **MUST NOT** be
used in VNF's Volume template;
it is not supported.
-
+
.. container:: note
``metadata`` key/value pair ``vf_module_index`` parameter **MUST**
be declared as ``vf_module_index`` and the parameter **MUST** be
defined as type: ``number``.
-
+
Resource: OS::Nova::Server Metadata Parameters > vf_module_name
---------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
property ``metadata`` **SHOULD**
contain the key/value pair ``vf_module_name`` and the value **MUST**
be obtained via a ``get_param``.
-
+
.. container:: note
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.
-
+
.. container:: note
property ``metadata`` key/value pair ``vf_module_name``
parameter ``vf_module_name`` **MUST NOT**
be enumerated in the Heat Orchestration Template's environment file.
-
+
.. container:: note
property
``metadata`` key/value pair ``vf_module_name`` parameter ``vf_module_name``
**MUST NOT** have parameter constraints defined.
-
+
.. container:: note
``metadata`` key/value pair ``vf_module_name`` parameter **MUST** be
declared as ``vf_module_name`` and the parameter **MUST**
be defined as type: ``string``.
-
+
Resource: OS::Nova::Server Metadata Parameters > vm_role
--------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
property ``metadata`` key/value pair ``vm_role`` parameter ``vm_role``
**MUST NOT** have parameter constraints defined.
-
+
.. container:: note
property ``metadata`` key/value pair ``vm_role`` is passed into a Nested
YAML
file, the key/value pair name ``vm_role`` **MUST NOT** change.
-
+
.. container:: note
A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
property ``metadata`` key/value pair ``vm_role`` value **MUST**
only contain alphanumeric characters and underscores (i.e., '_').
-
+
.. container:: note
``metadata`` key/value pair ``vm_role`` value is obtained via
``get_param``, the parameter **MUST** be declared as ``vm_role``
and the parameter **MUST** be defined as type: ``string``.
-
+
.. container:: note
- ``get_param``
- hard coded in the key/value pair ``vm_role``.
-
+
Resource: OS::Nova::Server Metadata Parameters > vnf_id
-------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
property
``metadata`` key/value pair ``vnf_id`` is passed into a Nested YAML
file, the key/value pair name ``vnf_id`` **MUST NOT** change.
-
+
.. container:: note
resource property
``metadata`` key/value pair ``vnf_id`` parameter ``vnf_id`` **MUST NOT**
be enumerated in the Heat Orchestration Template's environment file.
-
+
.. container:: note
``metadata`` key/value pair ``vnf_id`` parameter
**MUST** be declared as ``vnf_id`` and the parameter **MUST**
be defined as type: ``string``.
-
+
.. container:: note
resource property ``metadata`` **MUST**
contain the key/value pair ``vnf_id``
and the value **MUST** be obtained via a ``get_param``.
-
+
.. container:: note
resource property
``metadata`` key/value pair ``vnf_id`` parameter ``vnf_id`` **MUST NOT**
have parameter constraints defined.
-
+
Resource: OS::Nova::Server Metadata Parameters > vnf_name
---------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
property ``metadata`` key/value pair ``vnf_name`` parameter
``vnf_name`` **MUST NOT**
be enumerated in the Heat Orchestration Template's environment file.
-
+
.. container:: note
A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource property
``metadata`` **MUST** contain the key/value pair ``vnf_name`` and the
value **MUST** be obtained via a ``get_param``.
-
+
.. container:: note
property ``metadata`` key/value pair ``vnf_name``
parameter ``vnf_name`` **MUST NOT**
have parameter constraints defined.
-
+
.. container:: note
property ``metadata`` key/value pair ``vnf_name`` parameter **MUST**
be declared as ``vnf_name`` and the parameter **MUST** be defined as
type: ``string``.
-
+
.. container:: note
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 Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
parameter **MUST**
be declared as ``workload_context`` and the parameter **MUST**
be defined as type: ``string``.
-
+
.. container:: note
property ``metadata`` key/value pair ``workload_context``
parameter ``workload_context`` **MUST NOT**
be enumerated in the Heat Orchestration Template's environment file.
-
+
.. container:: note
property ``metadata`` key/value pair ``workload_context``
parameter ``workload_context`` **MUST NOT**
have parameter constraints defined.
-
+
.. container:: note
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 > Resource Description
-------------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The VNF package MUST provide :doc:`VES Event Registration <../../../../vnfsdk/module.git/files/VESEventRegistration_3_0>`
for all VES events provided by that xNF.
-
+
.. container:: note
The VNF documentation **MUST** contain a list of the files within the VNF
package that are static during the VNF's runtime.
-
+
VNF On-boarding and package management > Testing
------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The xNF Package **MUST** include documentation describing
the tests that were conducted by the xNF provider and the test results.
-
+
VNF Resiliency > Virtual Function - Container Recovery Requirements
-------------------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
:need:`R-46851`
The VNF **MUST** support ONAP Controller's Evacuate command.
-
+
.. container:: note
:need:`R-48761`
The VNF **MUST** support ONAP Controller's Snapshot command.
-
+
VNF Security > VNF API Security Requirements
--------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
on APIs: Validate that any input file has a correct and valid
Multipurpose Internet Mail Extensions (MIME) type. Input files
should be tested for spoofed MIME types.
-
+
.. container:: note
SQL expressions, may cause the system to execute undesirable and
unauthorized transactions against the database or allow other
inappropriate access to the internal network (injection attacks).
-
+
.. container:: note
The VNF **SHOULD** integrate with the Operator's authentication and
authorization services (e.g., IDAM).
-
+
Requirements Removed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The VNF **MUST** implement all monitoring and logging as
described in the Security Analytics section.
-
+
.. container:: note
The VNF **MUST** restrict changing the criticality level of
a system security alarm to administrator(s).
-
+
.. container:: note
anomalous access patterns that may represent fraudulent access or
other types of attacks, or integrate with tools that implement anomaly
and abuse detection.
-
+
.. container:: note
ensure that the date is within the validity period of the certificate,
check the Certificate Revocation List (CRL), and recognize the identity
represented by the certificate where PKI-based authentication is used.
-
+
.. container:: note
R-23772
The VNF **MUST** validate input at all layers implementing VNF APIs.
-
+
.. container:: note
The VNF **MUST** use certificates issued from publicly
recognized Certificate Authorities (CA) for the authentication process
where PKI-based authentication is used.
-
+
.. container:: note
The VNF **MUST** provide a mechanism to restrict access based
on the attributes of the VNF and the attributes of the subject.
-
+
.. container:: note
The VNF **MUST** support requests for information from law
enforcement and government agencies.
-
+
.. container:: note
The VNF **MUST** comply with NIST standards and industry
best practices for all implementations of cryptography.
-
+
VNF Security > VNF Cryptography Requirements
--------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The VNF **SHOULD** support an automated certificate management protocol
such as CMPv2, Simple Certificate Enrollment Protocol (SCEP) or
Automated Certificate Management Environment (ACME).
-
+
.. container:: note
The VNF **SHOULD** provide the capability to integrate with an
external encryption service.
-
+
.. container:: note
Note: The VNF provider cannot require the use of self-signed certificates
in an Operator's run time environment.
-
+
.. container:: note
The VNF **MUST** support HTTP/S using TLS v1.2 or higher
with strong cryptographic ciphers.
-
+
VNF Security > VNF Data Protection Requirements
-----------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The VNF **MUST** provide the capability of using X.509 certificates
issued by an external Certificate Authority.
-
+
.. container:: note
The VNF **MUST** provide the capability to restrict read
and write access to data handled by the VNF.
-
+
.. container:: note
The VNF **MUST** be capable of protecting the confidentiality and integrity
of data at rest and in transit from unauthorized access and modification.
-
+
.. container:: note
non-volatile memory.Non-volative memory is storage that is
capable of retaining data without electrical power, e.g.
Complementary metal-oxide-semiconductor (CMOS) or hard drives.
-
+
.. container:: note
The VNF **MUST** use NIST and industry standard cryptographic
algorithms and standard modes of operations when implementing
cryptography.
-
+
.. container:: note
The VNF **MUST** support digital certificates that comply with X.509
standards.
-
+
.. container:: note
IPSec, X.509 digital certificates for cryptographic implementations.
These implementations must be purchased from reputable vendors or obtained
from reputable open source communities and must not be developed in-house.
-
+
.. container:: note
The VNF **MUST** provide the ability to migrate to newer
versions of cryptographic algorithms and protocols with minimal impact.
-
+
.. container:: note
Acceptable algorithms can be found in the NIST FIPS publications
(https://csrc.nist.gov/publications/fips) and in the
NIST Special Publications (https://csrc.nist.gov/publications/sp).
-
+
Requirements Removed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The VNF **SHOULD** use commercial algorithms only when there
are no applicable governmental standards for specific cryptographic
functions, e.g., public key cryptography, message digests.
-
+
.. container:: note
The VNF **MUST** provide the capability to restrict access
to data to specific users.
-
+
VNF Security > VNF General Security Requirements
------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
Login access (e.g., shell access) to the operating system layer, whether
interactive or as part of an automated process, **MUST** be through an
encrypted protocol such as SSH or TLS.
-
+
.. container:: note
:need:`R-240760`
The VNF **MUST NOT** contain any backdoors.
-
+
.. container:: note
If SNMP is utilized, the VNF **MUST** support at least SNMPv3 with
message authentication.
-
+
.. container:: note
:need:`R-258686`
The VNF application processes **MUST NOT** run as root.
-
+
.. container:: note
display the last valid login date and time and the number of unsuccessful
attempts since then made with that user's ID. This requirement is only
applicable when the user account is defined locally in the VNF.
-
+
.. container:: note
The VNF **MUST** log any security event required by the VNF Requirements to
Syslog using LOG_AUTHPRIV for any event that would contain sensitive
information and LOG_AUTH for all other relevant events.
-
+
.. container:: note
:need:`R-756950`
The VNF **MUST** be operable without the use of Network File System (NFS).
-
+
.. container:: note
package, that specifies the targetted parameters, e.g. a limited set of
ports, over which the VNF will communicate (including internal, external
and management communication).
-
+
.. container:: note
security techniques that include the use of file and directory permissions.
Ideally, credentials SHOULD rely on a HW Root of Trust, such as a
TPM or HSM.
-
+
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The VNF **MUST** support encrypted access protocols, e.g., TLS,
SSH, SFTP.
-
+
.. container:: note
The VNF **SHOULD** provide the capability for the Operator to run security
vulnerability scans of the operating system and all application layers.
-
+
.. container:: note
The VNF **MUST** provide a mechanism (e.g., access control list) to
permit and/or restrict access to services on the VNF by source,
destination, protocol, and/or port.
-
+
.. container:: note
The VNF **SHOULD** support network segregation, i.e., separation of OA&M
traffic from signaling and payload traffic, using technologies such as
VPN and VLAN.
-
+
.. container:: note
The VNF **MUST** allow the Operator to disable or remove any security
testing tools or programs included in the VNF, e.g., password cracker,
port scanner.
-
+
.. container:: note
The VNF **MUST** support the ability to prohibit remote access to the VNF
via a host based security mechanism.
-
+
.. container:: note
allow the Operator to harden the VNF. Actions taken to harden a system
include disabling all unnecessary services, and changing default values
such as default credentials and community strings.
-
+
.. container:: note
ability to present a warning notice that is set by the Operator. A warning
notice is a formal statement of resource intent presented to everyone
who accesses the system.
-
+
.. container:: note
The VNF **MUST** provide functionality that enables the Operator to comply
with requests for information from law enforcement and government agencies.
-
+
.. container:: note
The VNF **MUST** implement and enforce the principle of least privilege
on all protected interfaces.
-
+
.. container:: note
The VNF **SHOULD** support the use of virtual trusted platform
module.
-
+
.. container:: note
in the VNF as soon as possible. Patching shall be controlled via change
control process with vulnerabilities disclosed along with
mitigation recommendations.
-
+
.. container:: note
The VNF **SHOULD** provide a mechanism that enables the operators to
perform automated system configuration auditing at configurable time
intervals.
-
+
Requirements Removed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The VNF **SHOULD** support the ability to work with aliases
(e.g., gateways, proxies) to protect and encapsulate resources.
-
+
.. container:: note
The VNF **SHOULD** interoperate with various access control
mechanisms for the Network Cloud execution environment (e.g.,
Hypervisors, containers).
-
+
.. container:: note
The VNF **MUST**, if not using the NCSP's IDAM API, comply
with the NCSP's credential management policy.
-
+
.. container:: note
with "password changes (includes default passwords)" policy. Products
will support password aging, syntax and other credential management
practices on a configurable basis.
-
+
.. container:: note
The VNF **MUST**, if not using the NCSP's IDAM API, support
use of common third party authentication and authorization tools such
as TACACS+, RADIUS.
-
+
.. container:: note
the requirements if not using the NCSP's IDAM API, for identification,
authentication and access control of OA&M and other system level
functions.
-
+
.. container:: note
ACLs, stateful firewalls and application layer gateways depending on
manner of deployment. The application is expected to function (and in
some cases, interwork) with these security tools.
-
+
.. container:: note
the ability to support Multi-Factor Authentication (e.g., 1st factor =
Software token on device (RSA SecureID); 2nd factor = User Name+Password,
etc.) for the users.
-
+
.. container:: note
The VNF **MUST** distribute all production code from NCSP
internal sources only. No production code, libraries, OS images, etc.
shall be distributed from publically accessible depots.
-
+
.. container:: note
The VNF **MUST**, if not using the NCSP's IDAM API, support
logging via ONAP for a historical view of "who did what and when."
-
+
.. container:: note
needs to have appropriate connectors to the Identity, Authentication
and Authorization systems that enables access at OS, Database and
Application levels as appropriate.
-
+
.. container:: note
subscriber identifiable data should be encrypted at rest. Other
data protection requirements exist and should be well understood
by the developer.
-
+
VNF Security > VNF Identity and Access Management Requirements
--------------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The VNF **MUST** provide a means for the user to explicitly logout, thus
ending that session for that authenticated user.
-
+
.. container:: note
The VNF **MUST**, if not integrated with the Operator's Identity and Access
Management system, or enforce a configurable "terminate idle sessions"
policy by terminating the session after a configurable period of inactivity.
-
+
.. container:: note
The VNF **MUST NOT** display "Welcome" notices or messages that could
be misinterpreted as extending an invitation to unauthorized users.
-
+
.. container:: note
A failed authentication attempt **MUST NOT** identify the reason for the
failure to the user, only that the authentication failed.
-
+
.. container:: note
manage, and automatically provision user accounts using an Operator
approved identity lifecycle management tool using a standard protocol,
e.g., NETCONF API.
-
+
.. container:: note
The VNF MUST not store authentication credentials to itself in clear
text or any reversible form and must use salting.
-
+
.. container:: note
The VNF **MUST** support account names that contain at least A-Z, a-z,
0-9 character sets and be at least 6 characters in length.
-
+
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The VNF **MUST**, if not integrated with the Operator's identity and
access management system, authenticate all access to protected GUIs, CLIs,
and APIs.
-
+
.. container:: note
The VNF **MUST** provide access controls that allow the Operator
to restrict access to VNF functions and data to authorized entities.
-
+
.. container:: note
The VNF **MUST** integrate with standard identity and access management
protocols such as LDAP, TACACS+, Windows Integrated Authentication
(Kerberos), SAML federation, or OAuth 2.0.
-
+
.. container:: note
When a VNF is added to the network, nothing should be able to use
it until the super user configures the VNF to allow other users
(human and application) have access.
-
+
.. container:: note
The VNF **MUST NOT** allow the assumption of the permissions of another
account to mask individual accountability. For example, use SUDO when a
user requires elevated permissions such as root or admin.
-
+
.. container:: note
The VNF **MUST**, if not integrated with the Operator's Identity and
Access Management system, support configurable password expiration.
-
+
.. container:: note
Each architectural layer of the VNF (eg. operating system, network,
application) **MUST** support access restriction independently of all
other layers so that Segregation of Duties can be implemented.
-
+
.. container:: note
and Access Management system, support the ability to disable the
userID after a configurable number of consecutive unsuccessful
authentication attempts using the same userID.
-
+
.. container:: note
characters that may have command functions, and (6) new passwords must
not contain sequences of three or more characters from the previous
password.
-
+
.. container:: note
The VNF **SHOULD** support OAuth 2.0 authorization using an external
Authorization Server.
-
+
.. container:: note
The VNF **MUST**, if not integrated with the Operator's Identity and
Access Management system, support Role-Based Access Control to enforce
least privilege.
-
+
.. container:: note
The VNF **MUST**, if not integrated with the Operator's Identity and
Access Management system, support the creation of multiple IDs so that
individual accountability can be supported.
-
+
.. container:: note
VNF for use by human users. Strong authentication uses at least two of the
three different types of authentication factors in order to prove the
claimed identity of a user.
-
+
.. container:: note
the assigned permissions associated with an ID in order to support
Least Privilege (no more privilege than required to perform job
functions).
-
+
Requirements Removed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
R-05470
The VNF **MUST** host connectors for access to the database layer.
-
+
.. container:: note
The VNF **MUST** provide or support the Identity and Access
Management (IDAM) based threat detection data for Session Hijacking.
-
+
.. container:: note
The VNF **MUST NOT** include authentication credentials
in security audit logs, even if encrypted.
-
+
.. container:: note
The VNF **MUST** provide Context awareness data (device,
location, time, etc.) and be able to integrate with threat detection system.
-
+
.. container:: note
The VNF **MUST** provide or support the Identity and Access
Management (IDAM) based threat detection data for Password Attacks.
-
+
.. container:: note
The VNF **MUST** provide or support the Identity and Access
Management (IDAM) based threat detection data for XSS / CSRF.
-
+
.. container:: note
The VNF **MUST** subject VNF provider access to privilege
reconciliation tools to prevent access creep and ensure correct
enforcement of access policies.
-
+
.. container:: note
The VNF **MUST** provide or support the Identity and Access
Management (IDAM) based threat detection data for Man in the Middle (MITM).
-
+
.. container:: note
R-45496
The VNF **MUST** host connectors for access to the OS (Operating System) layer.
-
+
.. container:: note
owner of the VNF before provisioning authorization through Role Based
Access Control (RBAC), Attribute Based Access Control (ABAC), or other
policy based mechanism.
-
+
.. container:: note
The VNF **MUST** provide or support the Identity and Access
Management (IDAM) based threat detection data for Replay.
-
+
.. container:: note
The VNF **MUST** provide or support the Identity and Access
Management (IDAM) based threat detection data for Eavesdropping.
-
+
.. container:: note
The VNF **MUST** provide or support the Identity and Access
Management (IDAM) based threat detection data for Malware (Key Logger).
-
+
.. container:: note
The VNF **MUST** provide minimum privileges for initial
and default settings for new user accounts.
-
+
.. container:: note
The VNF **MUST** provide or support the Identity and Access
Management (IDAM) based threat detection data for Phishing / SMishing.
-
+
.. container:: note
authorized personnel only, e.g., least privilege. These controls
could include the use of system configuration or access control
software.
-
+
.. container:: note
The VNF **MUST** conform to approved request, workflow
authorization, and authorization provisioning requirements when
creating privileged users.
-
+
.. container:: note
The VNF **MUST** authenticate system to system access and
do not conceal a VNF provider user's individual accountability for
transactions.
-
+
.. container:: note
utilities capable of capturing or logging data that was not created
by them or sent specifically to them in production, without
authorization of the VNF system owner.
-
+
.. container:: note
R-95105
The VNF **MUST** host connectors for access to the application layer.
-
+
VNF Security > VNF Security Analytics Requirements
--------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
:need:`R-303569`
The VNF **MUST** log the Source IP address in the security audit logs.
-
+
.. container:: note
The VNF **SHOULD** provide the capability of maintaining the integrity of
its static files using a cryptographic method.
-
+
.. container:: note
reporting in log files. It is recommended that Coordinated Universal Time
(UTC) be used where possible, so as to eliminate ambiguity owing to daylight
savings time.
-
+
.. container:: note
The VNF **MUST** have the capability to securely transmit the security logs
and security events to a remote system before they are purged from the
system.
-
+
.. container:: note
The VNF **MUST** log automated remote activities performed with
elevated privileges.
-
+
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The VNF **MUST** log success and unsuccessful creation, removal, or
change to the inherent privilege level of users.
-
+
.. container:: note
The VNF **MUST** support detection of malformed packets due to software
misconfiguration or software vulnerability, and generate an error to the
syslog console facility.
-
+
.. container:: note
The VNF **MUST** be implemented so that it is not vulnerable to OWASP
Top 10 web application security risks.
-
+
.. container:: note
attempts, e.g., authentication associated with a transaction,
authentication to create a session, authentication to assume elevated
privilege.
-
+
.. container:: note
The VNF **SHOULD** operate with anti-virus software which produces alarms
every time a virus is detected.
-
+
.. container:: note
The VNF **MUST** log connections to the network listeners of the
resource.
-
+
.. container:: note
The VNF **MUST** activate security alarms automatically when
it detects the successful modification of a critical system or
application file.
-
+
.. container:: note
The VNF **MUST** activate security alarms automatically when
a configurable number of consecutive unsuccessful login attempts
is reached.
-
+
.. container:: note
The VNF **MUST** restrict changing the criticality level of a
system security alarm to users with administrative privileges.
-
+
.. container:: note
The VNF **MUST** detect when its security audit log storage
medium is approaching capacity (configurable) and issue an alarm.
-
+
.. container:: note
The VNF **MUST** log successful and unsuccessful access to VNF
resources, including data.
-
+
.. container:: note
The VNF **MUST** generate security audit logs that can be sent
to Security Analytics Tools for analysis.
-
+
.. container:: note
The VNF **MUST** activate security alarms automatically when
it detects an unsuccessful attempt to gain permissions
or assume the identity of another user.
-
+
.. container:: note
The VNF **MUST** support the storage of security audit logs for a
configurable period of time.
-
+
Requirements Removed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
R-08598
The VNF **MUST** log successful and unsuccessful changes to a privilege level.
-
+
.. container:: note
The VNF **MUST** provide audit logs that include user ID, dates,
times for log-on and log-off, and terminal location at minimum.
-
+
.. container:: note
The VNF **MUST** support alternative monitoring capabilities
when VNFs do not expose data or control traffic or use proprietary and
optimized protocols for inter VNF communication.
-
+
.. container:: note
R-25094
The VNF **MUST** perform data capture for security functions.
-
+
.. container:: note
The VNF **MUST** support integrated DPI/monitoring functionality
as part of VNFs (e.g., PGW, MME).
-
+
.. container:: note
The VNF **MUST** implement "Closed Loop" automatic implementation
(without human intervention) for Known Threats with detection rate in low
false positives.
-
+
.. container:: note
The VNF **MUST** provide the capability of generating security
audit logs by interacting with the operating system (OS) as appropriate.
-
+
.. container:: note
The VNF **MUST** support event logging, formats, and delivery
tools to provide the required degree of event data to ONAP.
-
+
{network-role}
--------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
only alphanumeric characters and/or underscores '_' and
**MUST NOT** contain any of the following strings:
``_int`` or ``int_`` or ``_int_``.
-
+
.. container:: note
is associated with an internal network **MUST** include
``int_{network-role}`` as part of the parameter name,
where ``int_`` is a hard coded string.
-
+
.. container:: note
A VNF's Heat Orchestration Template's Resource ID that is associated
with an internal network **MUST** include ``int_{network-role}`` as part
of the Resource ID, where ``int_`` is a hard coded string.
-
+
{vm-type}
---------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
``vf_module_name``, ``vm_role``,
``vf_module_index``, ``environment_context``, ``workload_context``)
**MUST NOT** be prefixed with a common ``{vm-type}`` identifier.
-
+
.. container:: note
alphanumeric characters and/or underscores '_' and **MUST NOT**
contain any of the following strings:
``_int`` or ``int_`` or ``_int_``.
-
+
.. container:: note
- Each VM in the "class" **MUST** have the the identical number of
ports connecting to the identical networks and requiring the identical
IP address configuration.
-
+
Code Review / vnfrqts / requirements.git / commitdiff