R # | R Text | VNF Package Requirement | TOSCA |
VNF Resource DM VNFD Construct as agreed in ONAP R2+ Design-Time Resource DM clean version or an artifact of CSAR where applicable | Test exists in VNFSDK, VVP or SDC for Beijing release |
R-01478: | The VNF Package MUST include documentation describing all parameters that are available to monitor the VNF after instantiation (includes all counters, OIDs, PM data, KPIs, etc.) that must be collected for reporting purposes. The documentation must include a list of: | Y | tosca.capabilities.nfv.Metric - type for monitoring monitoring_parameter of above type per VNF/VDU/VLink Note: currently the Metric node definition is empty. Need more discussion in modeling team. | N |
R-01556: | The VNF Package MUST include documentation describing the fault, performance, capacity events/alarms and other event records that are made available by the VNF. The document must include: | Y but more discussions needed | tosca.capabilities.nfv.Metric - type for monitoring monitoring_parameter of above type per VNF/VDU/VLink Notes: - FCAPS related modeling need more discussion about how to use/define this in VNFD.
- Does this requirement belong to API or VNF Descriptor/Package
| N |
R-02454: | The VNF MUST support the existence of multiple major/minor versions of the VNF software and/or sub-components and interfaces that support both forward and backward compatibility to be transparent to the Service Provider usage. | Y - VNF Descriptor |
VDUMore discussions needed | VDU.Compute - tosca.artifacts.nfv.SwImage Virtual Storage - tosca.artifacts.Deployment.Image Notes: - Does the requirement relate to SwImage only?
- tosca.artifacts.nfv.SwImage need more discussion in modeling team
| N |
R-03070: | The VNF MUST, by ONAP Policy, provide the ONAP addresses as data destinations for each VNF, and may be changed by Policy while the VNF is in operation. We expect the VNF to be capable of redirecting traffic to changed destinations with no loss of data, for example from one REST URL to another, or from one TCP host and port to another. |
N | | Y but more discussions needed | tosca.nodes.nfv.VnfExtCp may provide externally modifiable vNIC properties VNF may provide configurable properties that can be modified using the ModifyVnfInfo operation Notes: Need more discussions and clarifications: - VNF package/Descriptor need providing the ONAP addresses as data destinations
- Providing API for changing the address on in external connection point
- tosca.nodes.nfv.VnfExtCp doesn't exist in ONAP R2 DM.
| N |
R-04298: | The VNF provider MUST provide their testing scripts to support testing. | Y |
Testing Testing directory in CSAR supported by ETSI SOL004 | Y |
R-07879: | The VNF Package MUST include all relevant playbooks to ONAP to be loaded on the Ansible Server. | Y |
| The playbooks should be located in a dedicated CSAR directory and may be referred in VNF-D LCM constructs Note: if VNF vendor support this, VNF Package/Descriptor should contain this, otherwise, VNF vendor could ignore this. | N |
R-09467: | The VNF MUST utilize only NCSP standard compute flavors. [5] - compute, virtual storage?
proposed change: The VNF MUST utilize only NCSP standard computing resource profile (CPU, Disk, Memory, etc.) compute flavors. | Y but more discussions needed | tosca.nodes.nfv.VDU.Compute tosca.nodes.nfv.VDU.VirtualStorage? |
R-13390: | The VNF provider MUST provide cookbooks to be loaded on the appropriate Chef Server. | Y | Notes: - In ONAP R2 modeling, we don't use the flavor directly, instead of this, we directly use CPU/Disk/Mem as separated requirement.
- From requirement perspective, we need more discussion on how to define/standardize the flavor in ONAP/VNF Vendors.
|
1606513390: | The VNF provider MUST provide |
configurable parameters (if unable to conform to YANG model) including VNF attributes/parameters and valid values, dynamic attributes and cross parameter dependencies (e.g., customer provisioning data).cookbooks to be loaded on the appropriate Chef Server. proposed change: The VNF Package MUST include a cookbook to be loaded on the appropriate server if the VNF is managed via Chef. | Y- Conditional | The cookbooks should be located in a dedicated CSAR directory and may be referred in VNF-D LCM constructs Note: if VNF vendor support this, VNF Package/Descriptor should contain this, otherwise, VNF vendor could ignore this. |
Y | tosca.datatypes.nfv.VnfcConfigurableProperties16560 VNF MUST conduct a resiliency impact assessment for all inter/intra-connectivity points in the VNF to provide an overall resiliency rating for the VNF to be incorporated into the software design and development of the VNF.VNF provider MUST provide configurable parameters (if unable to conform to YANG model) including VNF attributes/parameters and valid values, dynamic attributes and cross parameter dependencies (e.g., customer provisioning data). | Y | tosca.datatypes.nfv.VnfcConfigurableProperties tosca.datatypes.nfv.VnfConfigurableProperties. | N |
R-XXXXX | All VNF Orchestration parameters should be clearly specified in the relevant service template as part of VDU or other applicable node type definition: - All VNF orchestration parameters should include expected values and constraints
- Numeric parameter constraints should include range and/or allowed values
| Y | Each TOSCA node type may have orchestration parameters/properties that should be tested | N |
R-16560: | The VNF MUST conduct a resiliency impact assessment for all inter/intra-connectivity points in the VNF to provide an overall resiliency rating for the VNF to be incorporated into the software design and development of the VNF. | N/Y | TBD |
|
R-16777 |
N | | R-16777: | The VNF provider MUST provide a JSON file for each supported action for the VNF. The JSON file must contain key value pairs with all relevant values populated with sample data that illustrates its usage. The fields and their description are defined in Appendix B. | Y | | N |
R-18525: | The VNF provider MUST provide a JSON file for each supported action for the VNF. The JSON file must contain key value pairs with all relevant values populated with sample data that illustrates its usage. The fields and their description are defined in Appendix |
A | N | R-22888: | | The JSON files should be located in a dedicated CSAR directory and should be referred by VNF-D LCM actions | N |
R-18525: | The VNF provider MUST provide a JSON file for each supported action for the VNF. The JSON file must contain key value pairs with all relevant values populated with sample data that illustrates its usage. The fields and their description are defined in Appendix A. | Y | Same as R-16777 | N |
R-22888: | The VNF provider MUST provide documentation for the VNF |
The VNF provider MUST provide documentation for the VNF Policy Description to manage the VNF runtime lifecycle. The document must include a description of how the policies (conditions and actions) are implemented in the VNF. | Y |
This should be handled in conjunction with TOSCA policy constructs in VNF-D (element group, affinity/anti-affinity etc.) - TBD in ETSI SOL001 | N |
R-23823: | The VNF Package MUST include appropriate credentials so that ONAP can interact with the Chef Server.
| Y |
| The credentials should be located in a dedicated CSAR directory and their content may be encrypted using a symmetric encryption approach as specified in ETSI SOL004
Note: if VNF vendor support this, VNF Package/Descriptor should contain this, otherwise, VNF vendor could ignore this. |
| N |
R-25238: | The VNF PACKAGE MUST validated YANG code using the open source pyang [3] program using the following commands: | Y |
| N | The YANG code should be located in a dedicated CSAR directory for YANG code and may be referred by TOSCA LCM constructs in VNF-D | N |
R-26567: | The VNF Package MUST include a run list of roles/cookbooks/recipes, for each supported VNF action, that will perform the desired VNF action in its entirety as specified by ONAP (see Section 8.c, ONAP Controller APIs and Behavior, for list of VNF actions and requirements), when triggered by a chef-client run list in JSON file. | Y |
| All run-time scripts should be located in a dedicated CSAR directory for YANG code and should be referred by TOSCA LCM within VNF-D when VNF action is required
Note: if VNF vendor support this, VNF Package/Descriptor should contain this, otherwise, VNF vendor could ignore this. |
| N |
R-26881: | The VNF provider MUST provide the binaries and images needed to instantiate the VNF (VNF and VNFC images). | Y | Local artifact in CSAR: ROOT\Artifacts\ VNF_Image.bin or external referred in Manifest file |
Y | /VNF Descriptor Note: Currently , ONAP doesn't have the capability of Image management, we upload the image into VIM/VNFM manually. | N
|
R-27310: | The VNF Package MUST include all relevant Chef artifacts (roles/cookbooks/recipes) required to execute VNF actions requested by ONAP for loading on appropriate Chef Server. | Y |
Similar to R-26567 | N |
R-27711: | The VNF provider MUST provide an XML file that contains a list of VNF error codes, descriptions of the error, and possible causes/corrective action. | Y |
The XML file should be located in a CSAR directory dedicated to the run-time VNF actions the errors correspond to | N |
R-30278: | The VNF provider MUST provide a Resource/Device YANG model as a foundation for creating the YANG model for configuration. This will include VNF attributes/parameters and valid values/attributes configurable by policy. | Y |
The YANG model should be located in a dedicated CSAR directory for YANG configuration code | N |
R-30654: | The VNF 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 (e.g., configure). | Y | Interface construct tosca.interfaces.nfv.vnf.lifecycle.Nfv with a list of standard LCM operations described in CSAR directory for example ROOT\Artifacts\Informational\Install.csh | N |
R-33280: | The VNF MUST NOT use any instance specific parameters in a playbook. |
|
|
|
|
R-35851: | The VNF Package MUST include VNF topology that describes basic network and application connectivity internal and external to the VNF including Link type, KPIs, Bandwidth, latency, jitter, QoS (if applicable) for each interface. | Y | tosca.nodes.nfv.VNF tosca.nodes.nfv.VduCp tosca.nodes.nfv.VnfExtCp tosca.nodes.nfv.VnfVirtualLink in YAML files as part of CSAR Note: tosca.nodes.nfv.VnfExtCp doesn't exist in ONAP DM. | Partial Currently, VNF Package already have the topology of basic network and CP (both internal and external). |
R-36280: | The VNF provider MUST provide documentation describing VNF Functional Capabilities that are utilized to operationalize the VNF and compose complex services. | Y |
|
| N |
R-37028: | The VNF MUST be composed of one “base” module. |
N | Y | If "one base module" means a TOSCA main service template so the CSAR includes a MainSreviceTemplate.yaml file that is actually a VNF descriptor |
|
|
R-37692: | The VNFC MUST provide API versioning to allow for independent upgrades of VNFC. | Y |
TBD | N |
R-40293: | The VNF MUST make available (or load on VNF Ansible Server) playbooks that conform to the ONAP requirement. | Y |
The Ansible playbooks should be located in a dedicated CSAR directory | N |
R-40827: | The VNF provider MUST enumerate all of the open source licenses their VNF(s) incorporate. | Y | CSAR License directory as per ETSI SOL004 for example ROOT\Licenses\ License_term.txt | N |
R-41215: | The VNF MAY have zero to many “incremental” modules. Is it VNFD/VDU Profile and scaling aspect? | Y - Need more discussions |
tosca.datatypes.nfv.VduProfile and tosca.datatypes.nfv.ScalingAspect |
N | Victor: As we discussed last weekly meeting, “incremental/Base” modules only related heat based VNF. From tosca based VNF perspective, this requirement has similiar concept with Mult-DeploymentFlavor. in ONAP R2, we all agree use 1 DF. |
R-43958: | The VNF Package MUST include documentation describing the tests that were conducted by the VNF provider and the test results. | Y | | N |
R-46567: | The VNF Package MUST include configuration scripts for boot sequence and configuration. | Y | 4859643958: | The VNF Package MUST include documentation describing the |
characteristics for tests that were conducted by the VNF |
reliability and high availabilityprovider and the test results. | Y |
To be part of a standard CSAR directory for all testing related scripts and docs. | N |
R- |
5681546567: | The VNF Package MUST include |
documentation describing supported VNF configuration scripts for boot sequence and configuration. | Y | The scripts should be located in the predefined directory in CSAR and be in sync with boot_order property in tosca.nodes.nfv.Vdu.Compute | N |
R-48596: | The VNF Package MUST include documentation describing the characteristics for the VNF reliability and high availability. | N? | Is it testable? | N |
R-56815: | The VNF Package MUST include documentation describing supported VNF scaling capabilities and capacity limits (e.g., number of users, bandwidth, throughput, concurrent calls). |
Y | | N |
R-58775: | The VNF provider MUST provide software components that can be packaged with/near the VNF, if needed, to simulate any functions or systems that connect to the VNF system under test. This component is necessary only if the existing testing environment does not have the necessary simulators. | Y |
The software components needed for testing should be located in the Testing directory within CSAR | N |
R-66070: | The VNF Package MUST include VNF Identification Data to uniquely identify the resource for a given VNF provider. The identification data must include: an identifier for the VNF, the name of the VNF as was given by the VNF provider, VNF description, VNF provider, and version. | Y | Meta-data section in CSAR Manifest fie and the Meta-data section in VNF-D | Y |
R-69565: | The VNF Package MUST include documentation describing VNF Management APIs. The document must include information and tools for: | Y |
- Need more discussions | The documentation should describe which VNF external connection point nodes tosca.nodes.nfv.VnfExtCp and which protocols are used for management API Note: tosca.nodes.nfv.VnfExtCp doesn't exist in ONAP DM. |
| N |
R-72184: | The VNF MUST have routable FQDNs for all the endpoints (VMs) of a VNF that contain chef-clients which are used to register with the Chef Server. As part of invoking VNF actions, ONAP will trigger push jobs against FQDNs of endpoints for a VNF, if required. | Y |
| N | R-73364: | The VNF MUST support at least tosca.nodes.nfv.VduCp node type for connection points bind with VDU's should include all relevant properties suc as protocol_data etc.
Note: Currently , ONAP doesn't have the capability of Image management, we upload the image into VIM/VNFM manually.
| N |
R-73364: | The VNF MUST support at least two major versions of the VNF software and/or sub-components to co-exist within production environments at any time so that upgrades can be applied across multiple systems in a staggered manner. | Y |
| N | - Need more discussions | tosca.nodes.nfv.VDU.Compute is required to have a virtual_storage capability to keep multiple software versions Victor: This requirement more related API ? | N |
R-74763: | The VNF provider MUST provide an artifact per VNF that contains all of the VNF Event Records supported. The artifact |
R-74763: | The VNF provider MUST provide an artifact per VNF that contains all of the VNF Event Records supported. The artifact should include reference to the specific release of the VNF Event Stream Common Event Data Model document it is based on. (e.g., VES Event Listener) | Y - Need more discussions | In order to support VES event listener (for DCAE) a new TOSCA construct for event driven performance monitoring should be developed | Y |
R-77707: | The VNF provider MUST include a Manifest File that contains a list of all the components in the VNF package. | Y | CSAR Manifest file as per SOL004 for example ROOT\ MainServiceTemplate.mf | Y |
R-77786: | The VNF Package MUST include all relevant cookbooks to be loaded on the ONAP Chef Server. | Y |
| N | The cookbooks should be located in a predefined directory within a CSAR | N |
R |
R-78010: | The VNF MUST use the NCSP’s IDAM API for Identification, authentication and access control of customer or VNF application users. | N |
? - need clarification |
|
|
R-81777: | The VNF MUST be configured with initial address(es) to use at deployment time. After that the address(es) may be changed through ONAP-defined policies delivered from ONAP to the VNF using PUTs to a RESTful API, in the same way that other controls over data reporting will be controlled by policy. | Y |
- need more discussions | tosca.nodes.nfv.VduCp properties such as protocol_data should be initialized with a default attributes for initial addresses Note: how to set initial addresses need more discussion in ONAP IM. |
| N |
R-84366: | The VNF Package MUST include documentation describing VNF Functional APIs that are utilized to build network and application services. This document describes the externally exposed functional inputs and outputs for the VNF, including interface format and protocols supported. |
Y | | N - is documentation testable? |
| N |
R-86758: | The VNF SHOULD provide an automated test suite to validate every new version of the software on the target environment(s). The tests should be of sufficient granularity to independently test various representative VNF use cases throughout its lifecycle. Operations might choose to invoke these tests either on a scheduled basis or on demand to support various operations functions including test, turn-up and troubleshooting. | Y | Testing directory in CSAR supported by ETSI SOL004 |
|
R-96634: | The VNF provider MUST describe scaling capabilities to manage scaling characteristics of the VNF. | Y | tosca.datatypes.nfv.VnfConfigurableProperties, tosca.datatypes.nfv.ScaleInfo | N |
R-97102: | The VNF Package MUST include VM requirements via a Heat template that provides the necessary data for: | Y |
Should it be reflected also in VDU template - HPA? | TBD |
R-98617: | The VNF provider MUST provide information regarding any dependency (e.g., affinity, anti-affinity) with other VNFs and resources. | Y |
| N | Policy scripts as part of a dedicated directory within a CSAR | N |
R-99771: | The VNF MUST provide all code/configuration files in a “Locked down” or hardened state or with documented recommendations for such hardening. All unnecessary services will be disabled. VNF provider default credentials, community strings and other such artifacts will be removed or disclosed so that they can be modified or removed during provisioning. | N | ? |
|
R-43125 | R-43125 The VNF Heat **MUST** indent properties and lists with 1 or more spaces. | Y |
|
| VVP |
R-67888 | R-67888 The VNF Heat **MUST** contain the following - heat_template_version:
- description:
- parameters:
- resources
| Y |
|
| VVP |
R-39402 | R-39402 The VNF Heat **MUST** contain the description section. | Y |
description section. | VVP |
R-35414 | R-35414 The VNF Heat **MUST** contain the parameter section. | Y |
parameter section. | VVP |
R-90279 | R-90279 The VNF Heat **MUST** use in a resource all parameters declared in a template | Y |
|
| VVP |
R-28657 | R-28657 The VNF Heat **MUST** provide the attribute 'type' on parameters per the OpenStack Heat | Y |
attribute 'type' on parameters | VVP |
R-44001 | R-44001 The VNF Heat **MUST** provide the attribute 'description' on parameters. (Note that his attribute is OpenStack optional.) | Y |
attribute 'description' on parameters. | VVP |
R-90526 | R-90526 The VNF Heat **MUST NOT** use the attribute 'default'. | Y |
attribute 'default'. | VVP |
R-88863 | R-88863 The VNF Heat **MUST** have a constraint of range or allowed\_values for a parameter type 'number'. | Y |
allowed\_values for a parameter type 'number'. | VVP |
R-23664 | R-23664 The VNF Heat **MUST** have a resources: section with the decleration of at least one resource. | Y |
resources: section | VVP |
R-16447 | R-16447 The VNF Heat **MUST** have unique resource IDs across all Heat Orchestration Templates that compose the VNF. This requirement also applies when a VNF is composed of more than one Heat Orchestration Template (see ONAP VNF Modularity Overview). | Y |
resource IDs | VVP |
R-97199 | R-97199 The VNF Heat **MUST** use the metadata property for OS::Nova::Server resource type. | Y |
metadata property for OS::Nova::Server resource type. | VVP |
R-03324 | R-03324 The VNF Heat **MUST** contain the following sections in the environment file: parameters: | Y |
|
| VVP |
R-19473 | R-19473 The VNF Heat **MUST** include "base"? in the filename for the base module | Y |
filename | VVP |
R-81339 | R-81339 The VNF Heat **MUST** match one of the following options for the base module file name: - base_<text>.y[a]ml
- <text>_base.y[a]ml
- base.y[a]ml
- <text>_base_<text>.y[a]ml
| Y |
filename | VVP |
R-91342 | R-91342 The VNF Heat **MUST** name the base module's corresponding environment file to be identical to the base module with “.y[a]ml” replaced with “.env”. | Y |
filename | VVP |
R-87247 | R-87247 The VNF Heat **MUST NOT** use any special characters or the word "base"? in the name of the incremental module. | Y |
module name | VVP |
R-94509 | R-94509 The VNF Heat **MUST** name the incremental module’s corresponding environment file to be identical to the incremental module with “.y[a]ml” replaced with “.env”. | Y |
module name | VVP |
R-82732 | R-82732 The VNF Heat **MUST** name the Cinder volume module file name to be the same as the corresponding module it is supporting (base module or incremental module) with “_volume” appended. | Y |
module name | VVP |
R-31141 | R-31141 The VNF Heat **MUST** name the volume module’s corresponding environment file to be identical to the volume module with “.y[a]ml” replaced with “.env”. | Y |
module name | VVP |
R-76057 | R-76057 The VNF Heat **MUST NOT** use special characters or the word “base” in the file name for the nested template. | Y |
filename | VVP |
R-18224 | R-18224 The VNF Heat **MUST** pass in as properties all parameter values associated with the nested heat file in the resource |
definition defined in the parent heat template.Y | | VVP | R-07443 | R-07443 definition defined in the parent heat template. | Y |
| VVP |
R-07443 | R-07443 The VNF Heat **MUST** match the Output parameter name and type with the input parameter name and type unless the Output parameter is of the type comma_delimited_list. | Y | Output parameter name | VVP |
R-23983 | R-23983 The VNF **MUST** pass the external networks into the VNF Heat Orchestration Templates as parameters.- Neutron Network-id (UUID)
- Neutron Network subnet ID (UUID)
- Contrail Network Fully Qualified Domain Name (FQDN)
| Y | external networks | VVP |
R-63345 | R-63345 The VNF Heat **MUST** pass the appropriate external network IDs into nested VM templates when nested Heat is used. | Y | external network IDs | VVP |
R-35666 | R-35666 The VNF Heat **MUST** include the resource(s) to create the internal network. The internal network must be either a Neutron Network or a Contrail Network. | Y |
| VVP |
R-86972 | R-86972 The VNF Heat **MUST** create internal networks in the Base Module, in the modular approach, with their resource IDs exposed as outputs (i.e., ONAP Base Module Output Parameters) for use by all incremental modules. If the Network resource ID is required in the base template, then a get_resource must be used. | Y |
| VVP |
R-68936 | R-68936 The VNF Heat **SHOULD** assign a unique {network-role} in the context of the VNF, when the internal network is created. ONAP Resource ID and Parameter Naming Convention provides additional details. | Y | {network-role} | VVP |
R-01455 | R-01455 The VNF Heat **MUST** assign a VNF unique {vm-type} for each Virtual Machine type (i.e., OS::Nova::Server) instantiated in the VNF. While the {vm-type} must be unique to the VNF, it does not have to be globally unique across all VNFs that ONAP supports. | Y | {vm-type} | VVP |
R-82481 | R-82481 The VNF Heat **MUST** include {vm-type} as part of the parameter name for any parameter that is associated with a unique Virtual Machine type. | Y | {vm-type} | VVP |
R-66729 | R-66729 The VNF Heat **MUST** include {vm-type} as part of the resource ID for any resource ID that is associated with a unique Virtual Machine type in the VNF. | Y | {vm-type} | VVP |
R-32394 | R-32394 The VNF Heat **MUST** use the same case for {vm-type} for all parameter names in the VNF. | Y | {vm-type} | VVP |
R-46839 | R-46839 The VNF Heat **MUST** use the same case for {vm-type} for all Resource IDs in the VNF. | Y | {vm-type} | VVP |
R-05008 | R-05008 The VNF Heat **MUST NOT** be prefixed with a common {vm-type} identifier for the six ONAP Metadata parameters. They are vnf_name, vnf_id, vf_module_id, vf_module_name, vm_role. The ONAP Metadata parameters are described in Resource: OS::Nova::Server – Metadata Parameters. | Y | Metadata parameters vnf_name, vnf_id, vf_module_id, vf_module_name, vm_role. | VVP |
R-15422 | R-15422 The VNF Heat **MUST NOT** |
match the Output parameter name and type with the input parameter name and type unless the Output parameter is of the type comma_delimited_list.be prefixed with a common {vm-type} {vm-type} identifier the parameter referring to the OS::Nova::Server property availability_zone . availability_zone is described in Property: availability_zone. | Y | OS::Nova::Server property availability_zone |
Y | 2398323983 21330 The VNF Heat **MUST** |
pass the external networks into the VNF Heat Orchestration Templates as parameters.- Neutron Network-id (UUID)
- Neutron Network subnet ID (UUID)
- Contrail Network Fully Qualified Domain Name (FQDN)
include {network-role} as part of the parameter name for any parameter that is associated with an external network. | Y | {network-role} |
Y | 6334563345 **MUST** pass the appropriate external network IDs into nested VM templates when nested Heat is used**MUST** include {network-role} as part of the resource ID for any resource ID that is associated with an external network must. | Y |
3566635666 84322 The VNF Heat **MUST** include |
the resource(s) to create the internal network. The internal network must be either a Neutron Network or a Contrail Network.int_{network-role} as part of the parameter name for any parameter that is associated with an internal network. | Y | int_{network-role} |
Y | 8697286972 96983 The VNF Heat **MUST** |
create internal networks in the Base Module, in the modular approach, with their resource IDs exposed as outputs (i.e., ONAP Base Module Output Parameters) for use by all incremental modules. If the Network resource ID is required in the base template, then a get_resource must be used.include int_{network-role} as part of the resource ID for any resource ID that is associated with an internal network. | Y | int_{network-role} |
Y | 6893668936 SHOULD assign a unique use the same case for {network-role} for all parameter names in the |
context of the , when the internal network is created. ONAP Resource ID and Parameter Naming Convention provides additional details 0145501455 The VNF Heat **MUST** assign a VNF unique {vm-type} for each Virtual Machine type (i.e., OS::Nova::Server) instantiated in the VNF. While the {vm-type} must be unique to the VNF, it does not have to be globally unique across all VNFs that ONAP supports.21511 The VNF Heat **MUST** use the same case for {network-role} for all Resource IDs in the VNF. | Y | {network-role} |
Y | 8248182481 59629 The VNF Heat **MUST** |
include {vm-type} as part of the parameter name for any parameter that is associated with a unique Virtual Machine typehave unique resource IDs within the resources section of a Heat Orchestration Template. This is an OpenStack Requirement. | Y |
6672966729 43319 The VNF Heat **MUST** |
include {vm-type} as part of the resource ID for any resource ID that is associated with a unique Virtual Machine type in the VNF.have unique resource IDs across all modules that compose the VNF, when a VNF is composed of more than one Heat Orchestration Template (i.e., modules). | Y | resource IDs |
Y | 3239432394 54517 The VNF Heat **MUST** |
use the same case for include {vm-type} in the resource ID when a resource is associated with a single {vm-type} |
for all parameter names in the VNF 4683946839 96482 The VNF Heat **MUST** |
use the same case for vmtype for all Resource IDs VNFresource ID when a resource is associated with a single external network. | Y |
0500805008 **MUST NOT** be prefixed with a common {vm-type} identifier for the six ONAP Metadata parameters. They are vnf_name, vnf_id, vf_module_id, vf_module_name, vm_role. The ONAP Metadata parameters are described in Resource: OS::Nova::Server – Metadata Parameters.**MUST** include int\_{network-role} in the resource ID when a resource is associated with a single internal network. | Y | resource ID |
Y | 1542215422 82115 The VNF Heat **MUST |
NOT be prefixed with a common {vm-type} {vm-type} identifier the parameter referring to the OS::Nova::Server property availability_zone . availability_zone is described in Property: availability_zone.include both the {vm-type} and {network-role} in the resource ID, when a resource is associated with a single {vm-type} and a single external network. | Y | resource ID |
Y | 2133021330 82551 The VNF Heat **MUST** include both the {vm-type} and int_{network-role} |
as part of the parameter name for any parameter that is associated with an external in the resource ID, when a resource is associated with a single {vm-type} and a single internal network. | Y |
1116811168 69287 The VNF Heat **MUST** |
include {network-role} as part of the resource ID for any resource ID that is associated with an external network mustuse only alphanumeric characters and "_"? underscores in the resource ID. Special characters must not be used. | Y |
8432284322 71152 The VNF Heat **MUST** |
include int_{network-role} as part of declare as type: string the parameter |
name for any parameter that is associated with an internal network 9698396983 91125 The VNF Heat **MUST |
** include int_{network-role} as part of the resource ID for any resource ID that is associated with an internal network** enumerate the parameter for property image in the Heat Orchestration Template environment file. | Y |
5842458424 57282 The VNF Heat **MUST** |
use the same case for {network-role} for all parameter names in the VNFhave a separate parameter for image for Each VM type (i.e., {vm-type}) even if more than one {vm-type} shares the same image. This provides maximum clarity and flexibility. | Y |
2151121511 50436 The VNF Heat **MUST** |
use same case for {network-role} for all Resource IDs in the VNFparamter property for flavor as type: string. | Y |
parameter property for flavor | VVP |
R- |
5962959629 69431 The VNF Heat **MUST** |
have unique resource IDs within the resources section of a Heat Orchestration Template. This is an OpenStack Requirement.enumerate the parameter for property flavor in the Heat Orchestration Template environment file. | Y | parameter property for flavor |
Y | 4331943319 The VNF Heat **MUST** have unique resource IDs across all modules that compose the VNF, when a VNF is composed of more than one Heat Orchestration Template 40499 The VNF Heat **MUST** have a separate parameter for flavor for each VM type (i.e., |
modules){vm-type}) even if more than one {vm-type} shares the same flavor. This provides maximum clarity and flexibility. | Y |
parameter property for flavor | VVP |
R- |
5451754517 22838 The VNF Heat **MUST NOT** |
include {vm-type} in the resource ID when a resource is associated with a single {vm-type} enumerate the parameter for property name in the environment file. | Y |
parameter property name | VVP |
R- |
9648296482 51430 The VNF Heat **MUST** |
include {network-role} in the resource ID when a resource is associated with a single external network.declare the paramter for property name as type: string or type: comma_delimited_list | Y | parameter property name |
Y | 9813898138 98450 The VNF Heat **MUST** |
include int\_{network-role} in the resource ID when a resource is associated with a single internal network.name the parameter availability_zone_{index} in the Heat Orchestration Template. | Y | parameter availability_zone_{index |
Y | 8211582115 13561 The VNF Heat **MUST** |
include both the vm-type} and {network-role} in the resource ID, when a resource is associated with a single {vm-type} and a single external networkindex} at zero. | Y | {index} | VVP |
R- |
8255182551 60204 The VNF Heat **MUST** |
include both vm-type} and int_{network-role} in the resource ID, when a resource is associated with a single {vm-type} and a single internal networkindex} by one. | Y | {index} | VVP |
R- |
6928769287 36887 The VNF Heat **MUST NOT** |
use only alphanumeric characters and "_"? underscores in the resource ID. Special characters must not be used.include the {vm-type} in the parameter name. | Y | parameter name |
Y | 7115271152 17020 The VNF Heat **MUST** |
declare as type: string the parameter for property image.include the following three mandatory metadata parameters for an OS::Nova::Server resource:- vnf_id
- vf_module_id
- vnf_name
| Y | OS::Nova::Server resource |
Y | | VVP | R-91125 | R-91125 The VNF Heat **MUST** enumerate the parameter for property image in the Heat Orchestration Template environment file. | Y | 5728257282 55218 The VNF Heat **MUST NOT** have |
a separate for image for Each VM type (i.e., {vm-type}) even if more than one {vm-type} shares the same image. This provides maximum clarity and flexibility.constraints defined for the OS::Nova::Server metadata parameter vnf_id. | Y | OS::Nova::Server metadata parameter |
Y | 5043650436 20856 The VNF Heat **MUST NOT** |
declare the paramter property for flavor as type: string enumerate the OS::Nova::Server metadata parameter vnf\_id in environment file. | Y |
OS::Nova::Server metadata parameter vnf\_id in environment | VVP |
R- |
6943169431 98374 The VNF Heat **MUST NOT** |
enumerate have parameter constraints defined for the |
parameter for property flavor in the Heat Orchestration Template environment fileOS::Nova::Server metadata parameter vf\_module\_id. | Y | OS::Nova::Server metadata parameter vf\_module\_id. | VVP |
R- |
4049940499 72871 The VNF Heat **MUST NOT** |
have a separate parameter for flavor for each VM type (i.e., {vm-type}) even if more than one {vm-type} shares the same flavor. This provides maximum clarity and flexibility. enumerate the OS::Nova::Server metadata parameter vf\_module\_id in environment file. | Y | OS::Nova::Server metadata parameter vf\_module\_id in environment file. |
Y | 2283822838 44318 The VNF Heat **MUST NOT** have |
enumerate the parameter for property name in the environment fileparameter constraints defined for the OS::Nova::Server metadata parameter vnf\_name. | Y | OS::Nova::Server metadata parameter vnf\_name | VVP |
R- |
5143051430 36542 The VNF Heat **MUST NOT** |
declare the paramter for property name as type: string or type: comma_delimited_list enumerate the OS::Nova::Server metadata parameter vnf\_name in the environment file. | Y | OS::Nova::Server metadata parameter vnf\_name in the environment file. |
Y | 9845098450 72050 The VNF Heat **MUST** |
name the parameter availability_zone_{indexcontain {network-role} in the |
Heat Orchestration Template. contain {network-role} in the parameter name | VVP |
R- |
1356113561 57576 The VNF Heat **MUST** |
start the index} at zeronetwork-role} in the parameter name. | Y | contain int_{network-role} in the parameter name. | VVP |
R- |
6020460204 93272 The VNF Heat **MUST** |
increment the {index} by one.Y | | VVP | R-36887 | R-36887 The VNF Heat **MUST NOT** include the {vm-type} in the parameter name. | Y | | VVP |
R-17020 | R-17020 adhere to the following parameter naming convention in the Heat Orchestration Template, when the parameter associated with the property network is referencing an “external” network:- {network-role}_net_id for the Neutron network ID
- {network-role}_net_name for the network name in OpenStack
| Y | - {network-role}_net_id for the Neutron network ID
- {network-role}_net_name for the network name in OpenStack
| VVP |
R-65373 | R-65373 The VNF Heat **MUST* |
* include following three mandatory metadata parameters for an OS::Nova::Server resource:- vnf_id
- vf_module_id
- vnf_name
following parameter naming convention, when the parameter associated with the property network is referencing an “internal” network:- int_{network-role}_net_id for the Neutron network ID
- int_{network-role}_net_name for the network name in OpenStack
| Y | - int_{network-role}_net_id for the Neutron network ID
- int_{network-role}_net_name for the network name in OpenStack
| VVP |
R-47716 | R-47716 |
Y | | VVP | R-55218 | R-55218 The VNF Heat **MUST NOT** have parameter constraints defined for the OS::Nova::Server metadata parameter vnf_id. | Y | | VVP |
R-20856 | R-20856 NOT enumerate the OS::Nova::Server metadata parameter vnf\_id in environment file.Y | | VVP | R-98374 | R-98374 The VNF Heat **MUST NOT** have parameter constraints defined for the OS::Nova::Server metadata parameter vf\_module\_id. | Y | | VVP |
R-72871 | R-72871 The VNF Heat **MUST NOT** enumerate the OS::Nova::Server metadata parameter vf\_module\_id in environment file. | Y | | VVP |
R-44318 | R-44318 the following parameter naming convention for the property fixed_ips and Map Property subnet_id parameter, when the parameter is referencing a subnet of an “external” network.- {network-role}_subnet_id if the subnet is an IPv4 subnet
- {network-role}_v6_subnet_id if the subnet is an IPv6 subnet
| Y | - {network-role}_subnet_id if the subnet is an IPv4 subnet
- {network-role}_v6_subnet_id if the subnet is an IPv6 subnet
| VVP |
R-20106 | R-20106 The VNF Heat **MUST |
NOT have parameter constraints defined for the OS::Nova::Server metadata parameter vnf\_name.adhere to the following naming convention for the property fixed_ips and Map Property subnet_id parameter, when the parameter is referencing the subnet of an “internal” network:- int_{network-role}_subnet_id if the subnet is an IPv4 subnet
- int_{network-role}_v6_subnet_id if the subnet is an IPv6 subnet
| Y | fixed_ips and Map Property subnet_id parameter | VVP |
R-41177 | R-41177 |
Y | | VVP | R-36542 | R-36542 The VNF Heat **MUST NOT** enumerate the OS::Nova::Server metadata parameter vnf\_name in the environment file. | Y | | VVP |
R-72050 | R-72050 contain include {vm-type} and {network-role} in the parameter |
namename, when a SDN-C IP assignment is made to a port connected to an external network. | Y |
| VVP | R-57576 | R-57576 The VNF Heat **MUST** contain int_ include {vm-type} and {network-role} in the parameter name |
.Y | 9327293272 84898 The VNF Heat **MUST** adhere to the following |
parameter naming convention in the Heat Orchestration Template, when the parameter associated with the property network is referencing an “external” network:naming convention, when the parameter for property fixed_ips and Map Property ip_address is declared type: comma_delimited_list:- {vm-type}_{network-role}_ips for IPv4 address
- {vm-type}_{network-role}_v6_ips for IPv6 address
| Y | property fixed_ips and Map Property ip_address is declared type: comma_delimited_list: |
net_id for the Neutron network ID- ips for IPv4 address
- {vm-type}_{
|
{netname for the network name in OpenStackY | 6537365373 34960 The VNF Heat **MUST** must adhere |
adhere parameter conventionconvention, when the parameter |
associated with the property network is referencing an “internal” network:for property fixed_ips and Map Property ip_address is declared type: string: |
intnetid for the Neutron network ID- {index} for an IPv4 address
- {vm-type}
|
intnetname for the network name in OpenStackY | | VVP | R-47716 | R-47716 The VNF Heat **MUST** adhere to the following parameter naming convention for the - {index} for an IPv6 address
| Y | property fixed_ips and Map Property |
subnet_id parameter, when the parameter is referencing a subnet of an “external” network.ip_address is declared type: string: |
{subnet_id if the subnet is subnet- address
- {vm-type}_{network-role}_v6_
|
subnet_id if the subnet is subnetY | | 2010620106 62584 The VNF Heat **MUST** adhere |
to the to the following naming convention, when the parameter for |
the property fixed_ips and Map Property |
subnet_id parameter, when the parameter is referencing the subnet of an “internal” network:ip_address is declared type: comma_delimited_list:- {vm-type}_int_{network-role}_
|
subnet_id if the subnet is an IPv4 subnetY | | VVP | R-41177 | R-41177 The VNF Heat **MUST** include - ips for IPv4 address
- {vm-type}_int_{network-role}_v6_
|
subnet_id if the subnet is an IPv6 subnet | Y | property fixed_ips and Map Property ip_address is declared type: comma_delimited_list: |
and Y | | in the parameter name, when a SDN-C IP assignment is made to a port connected to an external network.- _ips for IPv4 address
- {vm-type}_int_{network-role}_v6_ips for IPv6 address
|
8489884898 29256 The VNF Heat **MUST** must adhere to |
naming when when the parameter for property fixed_ips and Map Property ip_address is declared type: |
comma_delimited_listrole}_ips for - role}_ip_{index} for an IPv4 address
- {vm-type}_int_{network-role}_v6_ip_
|
ips - {index} for an IPv6 address
| Y |
VVP | R-34960 | R-34960 The VNF Heat **MUST** must adhere to the following naming convention, when the parameter for property fixed_ips and Map Property ip_address is declared type: string:- {vm-type}_int_{network-role}_ip_{index} for an IPv4 address
- {vm-type}_int_{network-role}_v6_ip_{index} for an IPv6 address
|
Y | 6258462584 61282 The VNF Heat **MUST** adhere |
to the to the following naming convention |
, when parameter for fixedips pairs and Map Property ip_address |
is declared type: comma_delimited_list:parameter, when the parameter is referencing an “external” network: |
_int- _{network-role}_floating_
|
ips - ip for an IPv4 address
- {vm-type}
|
_int- _{network-role}_floating_v6_
|
ips | VVP | R-29256 | R-29256 The VNF Heat **MUST** must adhere to the following naming convention, when the parameter for property fixed_ips allowed_address_pairs and Map Property ip_address |
is declared type: string:parameter, when the parameter is referencing an “external” network: |
int_- {network-role}_floating_ip
|
_{index} - for an IPv4 address
- {vm-type}_
|
int_- {network-role}_floating_v6_ip
|
_{index} Y | 6128261282 16805 The VNF Heat **MUST** adhere to the following naming convention for the property allowed_address_pairs and Map Property ip_address parameter |
, when the parameter is referencing an |
“external” :.- {vm-type}_int_{network-role}_floating_ip for an IPv4 address
- {vm-type}_int_{network-role}_floating_v6_ip for an IPv6 address
| Y |
VVP | R-16805 | R-16805 The VNF Heat **MUST** adhere to the following naming convention for the property allowed_address_pairs and Map Property ip_address parameter when the parameter is referencing an “internal” network.- {vm-type}_int_{network-role}_floating_ip for an IPv4 address
- {vm-type}_int_{network-role}_floating_v6_ip for an IPv6 address
|
Y | | VVP |
R-85734 | R-85734 The VNF Heat **MUST** use the intrinsic function str_replace in conjunction with the ONAP supplied metadata parameter vnf_name to generate a unique value, when the property name for a non OS::Nova::Server resources is defined in a Heat Orchestration Template. | Y |
|
| VVP |
R-47788 | R-47788 The VNF Heat **MUST** have a 1:1 scope of a cinder volume module, when it exists, with the Base Module or Incremental Module | Y |
module names | VVP |
R-79531 | R-79531 The VNF Heat **MUST** define "outputs"? in the volume template for each Cinder volume resource universally unique identifier (UUID) (i.e. ONAP Volume Template Output Parameters). | Y |
volume template | VVP |
R-86285 | R-86285 The VNF Heat **MUST** have a corresponding environment file, even if no parameters are required to be enumerated. | Y |
environment file | VVP |
R-67205 | R-67205 The VNF Heat **MUST** have a corresponding environment file for a Base Module. | Y |
environment file | VVP |
R-35727 | R-35727 The VNF Heat **MUST** have a corresponding environment file for an Incremental module. | Y |
environment file | VVP |
R-22656 | R-22656 The VNF Heat **MUST** have a corresponding environment file for a Cinder Volume Module. | Y |
environment file | VVP |
R-89868 | R-89868 The VNF Heat **MUST** have unique file names within the scope of the VNF for a nested heat yaml file. | Y |
filename | VVP |
R-52530 | R-52530 The VNF Heat **MUST NOT** use a directory hierarchy for nested templates. All templates must be in a single, flat directory (per VNF). | Y |
templates | VVP |
R-11041 | R-11041 The VNF Heat **MUST** have the resource calling the nested yaml file pass in as properties all parameters defined in nested yaml file. | Y |
nested yaml file | VVP |
R-61183 | R-61183 The VNF Heat **MUST NOT** change the parameter names, when OS::Nova::Server metadata parameters are past into a nested heat template. | Y |
OS::Nova::Server metadata parameters | VVP |
R-76718 | R-76718 The VNF Heat **MUST** reference the get_files targets in Heat templates by file name, and the corresponding files should be delivered to ONAP along with the Heat templates. | Y |
|
| VVP |
R-41888 | R-41888 The VNE Heat **MUST NOT** use URL-based file retrieval. | Y |
|
| VVP |
R-62177 | R-62177 The VNF Heat **MUST** have unique file names for the included files within the scope of the VNF. | Y |
file names | VVP |
R-87848 | R-87848 The VNF Heat **MUST** have all included files in a single, flat directory per VNF. ONAP does not support a directory hierarchy. | Y |