| R # | R Text | VNF Package Requirement | TOSCA 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:
| 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 More discussions needed | VDU.Compute - tosca.artifacts.nfv.SwImage Virtual Storage - tosca.artifacts.Deployment.Image Notes:
| 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. | 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:
| N |
| R-04298: | The VNF provider MUST provide their testing scripts to support testing. | Y | 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.) | Y but more discussions needed | tosca.nodes.nfv.VDU.Compute tosca.nodes.nfv.VDU.VirtualStorage? Notes:
| N |
| R-13390: | The VNF provider MUST provide 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. | N |
| R-16065: | 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). | 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:
| 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: | 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 | 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 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 | 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/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. | 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 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. | N |
| R-43958: | The VNF Package MUST include documentation describing the tests that were conducted by the VNF provider and the test results. | Y | To be part of a standard CSAR directory for all testing related scripts and docs. | N |
| R-46567: | The VNF Package MUST include 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). | N | Is it testable? | 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 | 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 - 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 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 | The cookbooks should be located in a predefined directory within a CSAR | N |
| 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. | 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 | 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
| 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:
| 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 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.
| 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** 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 | VVP |
| R-21330 | R-21330 The VNF Heat **MUST** include {network-role} as part of the parameter name for any parameter that is associated with an external network. | Y | {network-role} | VVP |
| R-11168 | R-11168 The VNF Heat **MUST** include {network-role} as part of the resource ID for any resource ID that is associated with an external network must. | Y | {network-role} | VVP |
| R-84322 | R-84322 The VNF Heat **MUST** include int_{network-role} as part of the parameter name for any parameter that is associated with an internal network. | Y | int_{network-role} | VVP |
| R-96983 | R-96983 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. | Y | int_{network-role} | VVP |
| R-58424 | R-58424 The VNF Heat **MUST** use the same case for {network-role} for all parameter names in the VNF. | Y | {network-role} | VVP |
| R-21511 | R-21511 The VNF Heat **MUST** use the same case for {network-role} for all Resource IDs in the VNF. | Y | {network-role} | VVP |
| R-59629 | R-59629 The VNF Heat **MUST** have unique resource IDs within the resources section of a Heat Orchestration Template. This is an OpenStack Requirement. | Y | resource IDs | VVP |
| R-43319 | R-43319 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 (i.e., modules). | Y | resource IDs | VVP |
| R-54517 | R-54517 The VNF Heat **MUST** include {vm-type} in the resource ID when a resource is associated with a single {vm-type}. | Y | resource ID | VVP |
| R-96482 | R-96482 The VNF Heat **MUST** include {network-role} in the resource ID when a resource is associated with a single external network. | Y | resource ID | VVP |
| R-98138 | R-98138 The VNF Heat **MUST** include int\_{network-role} in the resource ID when a resource is associated with a single internal network. | Y | resource ID | VVP |
| R-82115 | R-82115 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 network. | Y | resource ID | VVP |
| R-82551 | R-82551 The VNF Heat **MUST** include both the {vm-type} and int_{network-role} in the resource ID, when a resource is associated with a single {vm-type} and a single internal network. | Y | resource ID | VVP |
| R-69287 | R-69287 The VNF Heat **MUST** use only alphanumeric characters and "_"? underscores in the resource ID. Special characters must not be used. | Y | resource ID | VVP |
| R-71152 | R-71152 The VNF Heat **MUST** declare as type: string the parameter for property image. | Y | property image | VVP |
| R-91125 | R-91125 The VNF Heat **MUST** enumerate the parameter for property image in the Heat Orchestration Template environment file. | Y | property image | VVP |
| R-57282 | R-57282 The VNF Heat **MUST** have 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 | image | VVP |
| R-50436 | R-50436 The VNF Heat **MUST** declare the paramter property for flavor as type: string. | Y | parameter property for flavor | VVP |
| R-69431 | R-69431 The VNF Heat **MUST** enumerate the parameter for property flavor in the Heat Orchestration Template environment file. | Y | parameter property for flavor | VVP |
| R-40499 | R-40499 The VNF Heat **MUST** 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. | Y | parameter property for flavor | VVP |
| R-22838 | R-22838 The VNF Heat **MUST NOT** enumerate the parameter for property name in the environment file. | Y | parameter property name | VVP |
| R-51430 | R-51430 The VNF Heat **MUST** declare the paramter for property name as type: string or type: comma_delimited_list | Y | parameter property name | VVP |
| R-98450 | R-98450 The VNF Heat **MUST** name the parameter availability_zone_{index} in the Heat Orchestration Template. | Y | parameter availability_zone_{index | VVP |
| R-13561 | R-13561 The VNF Heat **MUST** start the {index} at zero. | Y | {index} | VVP |
| R-60204 | R-60204 The VNF Heat **MUST** increment the {index} by one. | Y | {index} | VVP |
| R-36887 | R-36887 The VNF Heat **MUST NOT** include the {vm-type} in the parameter name. | Y | parameter name | VVP |
| R-17020 | R-17020 The VNF Heat **MUST** include the following three mandatory metadata parameters for an OS::Nova::Server resource:
| Y | OS::Nova::Server resource | VVP |
| R-55218 | R-55218 The VNF Heat **MUST NOT** have parameter constraints defined for the OS::Nova::Server metadata parameter vnf_id. | Y | OS::Nova::Server metadata parameter | VVP |
| R-20856 | R-20856 The VNF Heat **MUST NOT** enumerate the OS::Nova::Server metadata parameter vnf\_id in environment file. | Y | OS::Nova::Server metadata parameter vnf\_id in environment | 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 | OS::Nova::Server metadata parameter vf\_module\_id. | VVP |
| R-72871 | R-72871 The VNF Heat **MUST NOT** 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. | VVP |
| R-44318 | R-44318 The VNF Heat **MUST NOT** have parameter constraints defined for the OS::Nova::Server metadata parameter vnf\_name. | Y | OS::Nova::Server metadata parameter vnf\_name | VVP |
| R-36542 | R-36542 The VNF Heat **MUST NOT** 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. | VVP |
| R-72050 | R-72050 The VNF Heat **MUST** contain {network-role} in the parameter name | Y | contain {network-role} in the parameter name | VVP |
| R-57576 | R-57576 The VNF Heat **MUST** contain int_{network-role} in the parameter name. | Y | contain int_{network-role} in the parameter name. | VVP |
| R-93272 | R-93272 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:
| Y |
| VVP |
| R-65373 | R-65373 The VNF Heat **MUST* adhere to the following parameter naming convention, when the parameter associated with the property network is referencing an “internal” network:
| Y |
| VVP |
| R-47716 | R-47716 The VNF Heat **MUST** adhere to 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.
| Y |
| VVP |
| R-20106 | R-20106 The VNF Heat **MUST** 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:
| Y | fixed_ips and Map Property subnet_id parameter | VVP |
| R-41177 | R-41177 The VNF Heat **MUST** include {vm-type} and {network-role} in the parameter name, when a SDN-C IP assignment is made to a port connected to an external network. | Y | include {vm-type} and {network-role} in the parameter name | VVP |
| R-84898 | R-84898 The VNF Heat **MUST** adhere to the following naming convention, when the parameter for property fixed_ips and Map Property ip_address is declared type: comma_delimited_list:
| Y | property fixed_ips and Map Property ip_address is declared type: comma_delimited_list:
| 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:
| Y | property fixed_ips and Map Property ip_address is declared type: string:
| VVP |
| R-62584 | R-62584 The VNF Heat **MUST** adhere to the following naming convention, when the parameter for property fixed_ips and Map Property ip_address is declared type: comma_delimited_list:
| Y | property fixed_ips and Map Property ip_address is declared type: comma_delimited_list:
| VVP |
| R-29256 | R-29256 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:
| Y | property fixed_ips and Map Property ip_address is declared type: string:
| VVP |
| R-61282 | R-61282 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” network:
| Y | allowed_address_pairs and Map Property ip_address parameter, when the parameter is referencing an “external” network:
| 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.
| Y | allowed_address_pairs and Map Property ip_address parameter when the parameter is referencing an “internal” network.
| 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 | file names | VVP |
Overview
Content Tools
11 Comments
maopeng zhang
As I get the information from Victor Gao, the VNF package requirements are written from VNFSDK project aspect. I suggest to update the column name in the page (VNFSDK R2 or R3+) and make it more clear for the page usage.
Andrei Kojukhov
I agree that the VNF package testability requirements are mostly for VNF-SDK project however SDC that on-boards VNF packages should be also aware of these requirements so the scope of this page is not only VNF-SDK project.
maopeng zhang
Yes. the requirements effect not only VNF SDK, but also other projects.
I think this page information now comes from the VNFSDK project and make the input source clear. Some other projects also can add a column to feedback the information. But the colunmn 3 name is not very clear now.
Weitao Gao
I really encourage everyone who want contribute VNF requirement project join the discussion every weekly meeting. last weekly meeting we agree R2 will focus on design-time (VNFSDK/SDC) , so this page is the input for future discussion.
Andrei Kojukhov
I also propose to make a number of changes in VNF package requirement column. My understanding is that most of hose you assigned as N are actually part of VNF package and can be tested.
Did you make changes versus the list of requirements in VNFRQTS-105/107?
Weitao Gao
hi Andrei?
VNFRQTS-105/107 mostly about Resource model and CSAR structure, I suggest you could help us update the corresponding model into latest R2 model spec. You can refer this: ONAP R2+ Design-Time Resource DM clean version.
BR
Victor
Andrei Kojukhov
Hi Victor,
I'm aware of the R2+ Design Time model development. Actually the R2 Resource DM model should be a basis for VNF tests where we would like to test some (if not all) of the VNF-D model constructs. That was an idea behind the VNFRQTS-105/107. The VNF validation/certification tool after testing the constituents of the VNF package may proceed to further stages of VNF non-functional tests such as LCM tests based on VNF-D constituents.
BR
Andrei
Herb Patten
I added in the numbered Heat requirements
Andrei Kojukhov
I added the relevant TOSCA YAML CSAR and NFV Profile constructs as agreed by TOSCA R2 Resource DM (reference is available) as per VNFRQTS-105 and VNFRQTS-107.
Andrei Kojukhov
Hi Victor,
Tks for reviewing the table. I will color your comments that I agree (we agree) to green color and keep the red color on those there is no agreement or more discussion is needed.
Main question: how comes the tosca.nodes.nfv.VnfExtCp is not part of R2 clean version? How the modeling of external connection point is done otherwise?
Andrei
Andrei Kojukhov
I added a requirement for VNF Orchestration parameters similar to that defined for HEAT: