The main (EPIC) purpose of the VNF Requirements for the Amsterdam release was to support RFP operations for offline evaluation of candidate VNFs.

To move towards a more automated system, and improve the quality of the VNFs, Mechanisms for automated testing of VNFs are required. 

For the Beijing release, the focus is on those requirements that are testable by inspection of the VNF Package. Much of the VNF Requirments is directed towards developing consistent operational behaviors in the VNFs. Testing of running instances of VNFs is beyond the scope of the Beijing release. 

This implies that either the requirement is either expressly phrased or implied to have some information in the VNF Package, or some constraints on the range of acceptable values for such an information element.

The consolidated list of numbered requirements in the Amsterdam release is available in Appendix 8.d. Note that the Amsterdam release does not have numbered requirements  from the section on HEAT / TOSCA templates. 

The attached spreadsheet identifies the requirements from that list where there may be inspectable content in the VNF Package.

Of the 386 numbered requirements identified in the Amsterdam release, only ~50  seem to have a strong relationship with the VNF Package. These are:

R #R Text
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:
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:
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.
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.
R-04298:The VNF provider MUST provide their testing scripts to support testing.
R-07879:The VNF Package MUST include all relevant playbooks to ONAP to be loaded on the Ansible Server.
R-09467:The VNF MUST utilize only NCSP standard compute flavors. [5]
R-13390:The VNF provider MUST provide cookbooks to be loaded on the appropriate Chef Server.
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).
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.
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.
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.
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.
R-23823:The VNF Package MUST include appropriate credentials so that ONAP can interact with the Chef Server.
R-25238:The VNF PACKAGE MUST validated YANG code using the open source pyang [3] program using the following commands:
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.
R-26881:The VNF provider MUST provide the binaries and images needed to instantiate the VNF (VNF and VNFC images).
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.
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.
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.
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).
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.
R-36280:The VNF provider MUST provide documentation describing VNF Functional Capabilities that are utilized to operationalize the VNF and compose complex services.
R-37028:The VNF MUST be composed of one “base” module.
R-37692:The VNFC MUST provide API versioning to allow for independent upgrades of VNFC.
R-40293:The VNF MUST make available (or load on VNF Ansible Server) playbooks that conform to the ONAP requirement.
R-40827:The VNF provider MUST enumerate all of the open source licenses their VNF(s) incorporate.
R-41215:The VNF MAY have zero to many “incremental” modules.
R-43958:The VNF Package MUST include documentation describing the tests that were conducted by the VNF provider and the test results.
R-46567:The VNF Package MUST include configuration scripts for boot sequence and configuration.
R-48596:The VNF Package MUST include documentation describing the characteristics for the VNF reliability and high availability.
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).
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.
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.
R-69565:The VNF Package MUST include documentation describing VNF Management APIs. The document must include information and tools for:
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.
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.
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)
R-77707:The VNF provider MUST include a Manifest File that contains a list of all the components in the VNF package.
R-77786:The VNF Package MUST include all relevant cookbooks to be loaded on the ONAP Chef Server.
R-78010:The VNF MUST use the NCSP’s IDAM API for Identification, authentication and access control of customer or VNF application users.
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.
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.
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.
R-96634:The VNF provider MUST describe scaling capabilities to manage scaling characteristics of the VNF.
R-97102:The VNF Package MUST include VM requirements via a Heat template that provides the necessary data for:
R-98617:The VNF provider MUST provide information regarding any dependency (e.g., affinity, anti-affinity) with other VNFs and resources.
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.
R-nnnnn:**The VNF MUST have a corresponding environment file for a Cinder Volume Module.


(** The Amsterdam release had a bug where a requirement number was not assigned, this was identfied in JIRA VNFRQTS-156 and the patch merged with the master (Beijing) in  merge Change 28815.)

This provides a base set of requirments which we can look more closely at for testability.  One approach to testability is to indentify whether specific information Elements associated with the requirement are present, and have values within allowable ranges. The Information model project has been defining a number of information elements associated with VNFs. 

  • No labels

9 Comments

  1. wenyao guan

    Herb and I planed to have meetings to discuss these items, but not once achieved. It will be code freeze soon and this could be a risk if this discussing not completed before that. Hope a consensus can be reached soon.

    1. Herb Patten

      A meeting was scheduled and several people joined the call. There was misunderstanding about whether the call could continue and abruptly ended. Scheduling a follow up call has been challenging due to time zones. Several proposed times have not been mutually successful. This issue wasn't raised on the most recent VNF Requirements call.

      1. Herb Patten

        A call has been proposed for 3/26

  2. Andrei Kojukhov

    Please take into account that the results of the discussion may affect the VNFRQTS-28 and VNFRQTS-105/107.

  3. wenyao guan

    Though we had a discussing during the meeting  last Friday (March. 23), none consensus  reached. An obvious issue is the VNF package definition was not clear.

  4. Herb Patten

    In the meeting there were a number of items discussed:

    1. The requirements in the ONAP "VNF Requirements Documentation" are intended to be ones that VNFs are expected to meet
    2. There is always opportunity to clarify the requirements and making the wording cleared. This can be done and has been done by submitting bug reports in JIRA. See example VNFRQTS-184 - Getting issue details... STATUS
    3. What we know is that only the requirements associated with Heat are truly being tested.
    4. Whether or not the requirements are being tested or in a format that allows automated testing, the requirements are still valid ones to expect of VNFs
    5. The "risk" mentioned hasn't been well defined. This "risk" needs to be better defined and associated with a specific project and deliverable.
    6. We have provided feedback to wenyao and team on the questions that they raised
    7. The term package is described in Chapter 7 of the requirements. I understand it is a future goal to provide a specific schema/model for the package to provide a more precise definition.

  5. Weitao Gao

    Hi Steven:

        some question here?

    • what's the definition of "base"/ "incremental" module? #R-37028 and #R-41215
    • I think both chef/Ansible just kind of choices for configuration, should we replace the related requirement from "MUST" to "Suggest"?
    • #09467: does this means VNF requirement will define some "fixed/hardcode" flavors?

  6. Herb Patten

    section 5.2.5 talks about base/incremental module. also 4.4.3 discusses this.

    Chef/Ansible/NetConf are all options for VNFs. I understand the concern that if a VNF is not using Chef than the Chef requirements listed as "MUST" are really not required. I don't think we have terminology that allows "suggest". Another option would be to specify or clarify that the requirement is only a MUST if using Chef etc.

    09467 - It is expected that service providers will have a list of approved "flavors". It would be great it ONAP could agree on a common list of "flavors" as well but I am not sure that we are that mature yet.

    1. Weitao Gao

      Hi Herb,

          Thank you for your answer.

          If i understanding correctly: base module/ incremental module only relate heat based VNF, tosca based VNF could ignore this, right?