- These requirements are specific to the Amsterdam release of ONAP. It is the initial release of requirements based on a merge of the Open-O and OpenECOMP requirements.
- Requirements are identified as either MUST, MUST NOT, SHOULD, SHOULD NOT, or MAY as defined in RFC 2119.
- Chapter 4 contains the VNF requirements involving the design and development of VNFs. These requirements help VNFs operate efficiently within a cloud environment. Requirements cover design, resiliency, security, modularity and DevOps.
-- Chapter 5 describes the different data models the vendor needs to understand. There are currently 2 models described in this document
+- Chapter 5 describes the different data models the VNF provider needs to understand. There are currently 2 models described in this document
- The first model is the onboarding package data model. This is a TOSCA model that will describe how all the elements passed from the VNF Provider to the Service provider should be formatted and packaged.
- The second model is HEAT template used for orchestrating and instantiating virtual resources in an OpenStack environment. At this time the HEAT files will be passed to the Service provider as a data element within the TOSCA onboarding package.
- Chapter 6 details the requirements specific to an implementation. The current implementations documented are OpenStack and Azure.
packaging and deploying VNFs as needed for the service. It enables
grouping functions in a common cloud data center to minimize
inter-component latency. The VNFs should be designed with a goal of
-being modular and reusable to enable using best-in-breed vendors
+being modular and reusable to enable using best-in-breed vendors.
Section 5.a VNF Design in *VNF Guidelines* describes
the overall guidelines for designing VNFs from VNF Components (VNFCs).
following sections:
- **VNF General Security**: This section addresses general security
- requirements for the VNFs that the vendors will need to address.
+ requirements for the VNFs that the VNF provide will need to address.
- **VNF Identity and Access Management**: This section addresses
security requirements with respect to Identity and Access Management
* R-23882 The VNF **SHOULD** be scanned using both network scanning and application scanning security tools on all code, including underlying OS and related configuration. Scan reports shall be provided. Remediation roadmaps shall be made available for any findings.
* R-46986 The VNF **SHOULD** have source code scanned using scanning tools (e.g., Fortify) and provide reports.
* R-55830 The VNF **MUST** distribute all production code from NCSP internal sources only. No production code, libraries, OS images, etc. shall be distributed from publically accessible depots.
-* 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. Vendor default credentials, community strings and other such artifacts will be removed or disclosed so that they can be modified or removed during provisioning.
+* 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 provide default credentials, community strings and other such artifacts will be removed or disclosed so that they can be modified or removed during provisioning.
* R-19768 The VNF **SHOULD** support L3 VPNs that enable segregation of traffic by application (dropping packets not belonging to the VPN) (i.e., AVPN, IPSec VPN for Internet routes).
* R-33981 The VNF **SHOULD** interoperate with various access control mechanisms for the Network Cloud execution environment (e.g., Hypervisors, containers).
* R-40813 The VNF **SHOULD** support the use of virtual trusted platform module, hypervisor security testing and standards scanning tools.
* R-98391 The VNF **MUST**, if not using the NCSP’s IDAM API, support Role-Based Access Control to permit/limit the user/application to performing specific activities.
* R-63217 The VNF **MUST**, if not using the NCSP’s IDAM API, support logging via ONAP for a historical view of “who did what and when”.
* R-62498 The VNF **MUST**, if not using the NCSP’s IDAM API, encrypt OA&M access (e.g., SSH, SFTP).
-* R-79107 The VNF **MUST**, if not using the NCSP’s IDAM API, enforce a configurable maximum number of Login attempts policy for the users. VNF vendor must comply with "terminate idle sessions" policy. Interactive sessions must be terminated, or a secure, locking screensaver must be activated requiring authentication, after a configurable period of inactivity. The system-based inactivity timeout for the enterprise identity and access management system must also be configurable.
+* R-79107 The VNF **MUST**, if not using the NCSP’s IDAM API, enforce a configurable maximum number of Login attempts policy for the users. VNF provider must comply with "terminate idle sessions" policy. Interactive sessions must be terminated, or a secure, locking screensaver must be activated requiring authentication, after a configurable period of inactivity. The system-based inactivity timeout for the enterprise identity and access management system must also be configurable.
* R-35144 The VNF **MUST**, if not using the NCSP’s IDAM API, comply with the NCSP’s credential management policy.
* R-75041 The VNF **MUST**, if not using the NCSP’s IDAM API, expire passwords at regular configurable intervals.
* R-46908 The VNF **MUST**, if not using the NCSP’s IDAM API, comply with "password complexity" policy. When passwords are used, they shall be complex and shall at least meet the following password construction requirements: (1) be a minimum configurable number of characters in length, (2) include 3 of the 4 following types of characters: upper-case alphabetic, lower-case alphabetic, numeric, and special, (3) not be the same as the UserID with which they are associated or other common strings as specified by the environment, (4) not contain repeating or sequential characters or numbers, (5) not to use special characters that may have command functions, and (6) new passwords must not contain sequences of three or more characters from the previous password.
* R-99174 The VNF **MUST** comply with Individual Accountability (each person must be assigned a unique ID) when persons or non-person entities access VNFs.
* R-42874 The VNF **MUST** comply with Least Privilege (no more privilege than required to perform job functions) when persons or non-person entities access VNFs.
* R-71787 The VNF **MUST** comply with Segregation of Duties (access to a single layer and no developer may access production without special oversight) when persons or non-person entities access VNFs.
-* R-86261 The VNF **MUST NOT** allow vendor access to VNFs remotely.
-* R-49945 The VNF **MUST** authorize vendor access through a client application API by the client application owner and the resource owner of the VNF before provisioning authorization through Role Based Access Control (RBAC), Attribute Based Access Control (ABAC), or other policy based mechanism.
-* R-31751 The VNF **MUST** subject vendor VNF access to privilege reconciliation tools to prevent access creep and ensure correct enforcement of access policies.
+* R-86261 The VNF **MUST NOT** allow VNF provider access to VNFs remotely.
+* R-49945 The VNF **MUST** authorize VNF provider access through a client application API by the client application owner and the resource owner of the VNF before provisioning authorization through Role Based Access Control (RBAC), Attribute Based Access Control (ABAC), or other policy based mechanism.
+* R-31751 The VNF **MUST** subject VNF provider access to privilege reconciliation tools to prevent access creep and ensure correct enforcement of access policies.
* R-34552 The VNF **MUST** provide or support the Identity and Access Management (IDAM) based threat detection data for OWASP Top 10.
* R-29301 The VNF **MUST** provide or support the Identity and Access Management (IDAM) based threat detection data for Password Attacks.
* R-72243 The VNF **MUST** provide or support the Identity and Access Management (IDAM) based threat detection data for Phishing / SMishing.
* R-44032 The VNF **MUST** provide or support the Identity and Access Management (IDAM) based threat detection data for Man in the Middle (MITM).
* R-58977 The VNF **MUST** provide or support the Identity and Access Management (IDAM) based threat detection data for Eavesdropping.
* R-24825 The VNF **MUST** provide Context awareness data (device, location, time, etc.) and be able to integrate with threat detection system.
-* R-59391 The VNF vendor **MUST**, where a VNF vendor requires the assumption of permissions, such as root or administrator, first log in under their individual user login ID then switch to the other higher level account; or where the individual user login is infeasible, must login with an account with admin privileges in a way that uniquely identifies the individual performing the function.
-* R-85028 The VNF **MUST** authenticate system to system access and do not conceal a VNF vendor user’s individual accountability for transactions.
-* R-80335 The VNF **MUST** make visible a Warning Notices: A formal statement of resource intent, i.e., a warning notice, upon initial access to a VNF vendor user who accesses private internal networks or Company computer resources, e.g., upon initial logon to an internal web site, system or application which requires authentication.
+* R-59391 The VNF provider **MUST**, where a VNF provider requires the assumption of permissions, such as root or administrator, first log in under their individual user login ID then switch to the other higher level account; or where the individual user login is infeasible, must login with an account with admin privileges in a way that uniquely identifies the individual performing the function.
+* R-85028 The VNF **MUST** authenticate system to system access and do not conceal a VNF provider user’s individual accountability for transactions.
+* R-80335 The VNF **MUST** make visible a Warning Notices: A formal statement of resource intent, i.e., a warning notice, upon initial access to a VNF provider user who accesses private internal networks or Company computer resources, e.g., upon initial logon to an internal web site, system or application which requires authentication.
* R-73541 The VNF **MIST** use access controls for VNFs and their supporting computing systems at all times to restrict access to authorized personnel only, e.g., least privilege. These controls could include the use of system configuration or access control software.
* R-64503 The VNF **MUST** provide minimum privileges for initial and default settings for new user accounts.
* R-86835 The VNF **MUST** set the default settings for user access to sensitive commands and data to deny authorization.
* R-95864 The VNF **MUST** use commercial tools that comply with X.509 standards and produce x.509 compliant keys for public/private key generation.
* R-12110 The VNF **MUST NOT** use keys generated or derived from predictable functions or values, e.g., values considered predictable include user identity information, time of day, stored/transmitted data.
* R-52060 The VNF **MUST** provide the capability to configure encryption algorithms or devices so that they comply with the laws of the jurisdiction in which there are plans to use data encryption.
-* R-69610 The VNF **MUST** provide the capability of using certificates issued from a Certificate Authority not provided by the VNF vendor.
+* R-69610 The VNF **MUST** provide the capability of using certificates issued from a Certificate Authority not provided by the VNF provider.
* R-83500 The VNF **MUST** provide the capability of allowing certificate renewal and revocation.
* R-29977 The VNF **MUST** provide the capability of testing the validity of a digital certificate by validating the CA signature on the certificate.
* R-24359 The VNF **MUST** provide the capability of testing the validity of a digital certificate by validating the date the certificate is being used is within the validity period for the certificate.
e. VNF Devops
=============
-This section includes guidelines for vendors to ensure that a Network
+This section includes guidelines for VNF providers to ensure that a Network
Cloud Service Provider’s operations personnel have a common and
consistent way to support VNFs and VNFCs.
f. VNF Develop Steps
=======================
-Aid to help the VNF vendor to fasten the integration with the GVNFM, the
+Aid to help the VNF provider to fasten the integration with the GVNFM, the
ONAP provides the VNF SDK tools, and the documents. In this charter,
-the develop steps for VNF vendors will be introduced.
+the develop steps for VNF providers will be introduced.
First, using the VNF SDK tools to design the VNF with TOSCA model and
output the VNF TOSCA package. The VNF package can be validated, and
tested.
-Second, the VNF vendor should provide the VNF Rest API to integrate with
+Second, the VNF provider should provide the VNF Rest API to integrate with
the GVNFM if needed. The VNF Rest API is aligned to the ETSI IFA
document.
Overview
---------
-The document includes three charters to help the VNF vendors to use the
+The document includes three charters to help the VNF providers to use the
VNF model design tools and understand the VNF package structure and VNF
TOSCA templates.
In the ONAP, VNF Package and VNFD template can be designed by manually
or via model designer tools. VNF model designer tools can provide the
-GUI and CLI tools for the VNF vendor to develop the VNF Package and VNFD
+GUI and CLI tools for the VNF provider to develop the VNF Package and VNFD
template.
The VNF package structure is align to the NFV TOSCA protocol, and
c. VNFM Driver Development Steps
================================
-Refer to the ONAP documentation for VNF vendor instructions on integrating
+Refer to the ONAP documentation for VNF providerr instructions on integrating
special VNFM adaptors with VF-C. The VNF driver development steps are
highlighted below.
the VNF TOSCA package. Using the VNF SDK tools, the VNF package can be
validated and tested.
-2. The VNF vendor can provide a special VNFM driver in ONAP, which
+2. The VNF provider can provide a special VNFM driver in ONAP, which
is a microservice providing a translation interface from VF-C to
the special VNFM. The interface definitions of special VNFM adaptors are provided by
-the VNF vendors themselves.
+the VNF providers themselves.
d. Creating Special VNFM Adaptor Microservices
==============================================
**Design Definition**
The ONAP Design Time Framework provides the ability to design NFV
-resources including VNFs, Services, and products. The vendor must
+resources including VNFs, Services, and products. The VNF provider must
provide VNF packages that include a rich set of recipes, management and
functional interfaces, policies, configuration parameters, and
infrastructure requirements that can be utilized by the ONAP Design
**Resource Description**
-* R-77707 The VNF Vendor **MUST** include a Manifest File that contains a list of all the components in the VNF package.
-* R-66070 The VNF Package **MUST** include VNF Identification Data to uniquely identify the resource for a given Vendor. The identification data must include: an identifier for the VNF, the name of the VNF as was given by the VNF Vendor, VNF description, VNF Vendor, and version.
+* R-77707 The VNF provide **MUST** include a Manifest File that contains a list of all the components in the VNF package.
+* 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:
- ONAP to deploy and configure (initially and ongoing) the VNF application(s) (e.g., NETCONF APIs). Includes description of configurable parameters for the VNF and whether the parameters can be configured after VNF instantiation.
- Runtime lifecycle events and related actions (e.g., control responses, tests) which can be performed for the VNF.
* 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-36280 The VNF Vendor **MUST** provide documentation describing VNF Functional Capabilities that are utilized to operationalize the VNF and compose complex services.
-* R-98617 The VNF Vendor **MUST** provide information regarding any dependency (e.g., affinity, anti-affinity) with other VNFs and resources.
+* R-36280 The VNF provider **MUST** provide documentation describing VNF Functional Capabilities that are utilized to operationalize the VNF and compose complex services.
+* R-98617 The VNF provider **MUST** provide information regarding any dependency (e.g., affinity, anti-affinity) with other VNFs and resources.
**Resource Configuration**
- Chef
- Ansible
- Note: The requirements for Netconf/YANG, Chef, and Ansible protocols are provided separately and must be supported only if the corresponding protocol option is provided by the vendor.
+ Note: The requirements for Netconf/YANG, Chef, and Ansible protocols are provided separately and must be supported only if the corresponding protocol option is provided by the VNF providor.
**Configuration Management via Netconf/YANG**
- * R-30278 The VNF Vendor **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-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.
**Configuration Management via Chef**
- * R-13390 The VNF Vendor **MUST** provide cookbooks to be loaded on the appropriate Chef Server.
- * R-18525 The VNF Vendor **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-13390 The VNF provider **MUST** provide cookbooks to be loaded on the appropriate Chef Server.
+ * 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.
Note: Chef support in ONAP is not currently available and planned for 4Q 2017.
**Configuration Management via Ansible**
- * R-75608 The VNF Vendor **MUST** provide playbooks to be loaded on the appropriate Ansible Server.
- * R-16777 The VNF Vendor **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-75608 The VNF provider **MUST** provide playbooks to be loaded on the appropriate Ansible Server.
+ * 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-46567 The VNF Package **MUST** include configuration scripts for boot sequence and configuration.
-* R-16065 The VNF Vendor **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-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).
**Resource Control Loop**
-* R-22888 The VNF Vendor **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-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-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:
- A unique identification string for the specific VNF, a description of the problem that caused the error, and steps or procedures to perform Root Cause Analysis and resolve the issue.
- All events, severity level (e.g., informational, warning, error) and descriptions including causes/fixes if applicable for the event.
- All events (fault, measurement for VNF Scaling, Syslogs, State Change and Mobile Flow), that need to be collected at each VM, VNFC (defined in *VNF Guidelines for Network Cloud and ONAP*) and for the overall VNF.
-* R-27711 The VNF Vendor **MUST** provide an XML file that contains a list of VNF error codes, descriptions of the error, and possible causes/corrective action.
+* 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-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:
- Monitoring parameters/counters exposed for virtual resource management and VNF application management.
* 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-48596 The VNF Package **MUST** include documentation describing the characteristics for the VNF reliability and high availability.
-* R-74763 The VNF Vendor **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 <https://github.com/att/evel-test-collector/tree/master/docs/att_interface_definition>`__)
+* 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 <https://github.com/att/evel-test-collector/tree/master/docs/att_interface_definition>`__)
**Compute, Network, and Storage Requirements**
Note: Must comply with the *Heat requirements in 5.b*.
-* R-26881 The VNF Vendor **MUST** provide the binaries and images needed to instantiate the VNF (VNF and VNFC images).
-* R-96634 The VNF Vendor **MUST** describe scaling capabilities to manage scaling characteristics of the VNF.
+* R-26881 The VNF provider **MUST** provide the binaries and images needed to instantiate the VNF (VNF and VNFC images).
+* R-96634 The VNF provider **MUST** describe scaling capabilities to manage scaling characteristics of the VNF.
**Testing**
-* R-43958 The VNF Package **MUST** include documentation describing the tests that were conducted by the Vendor and the test results.
-* R-04298 The VNF Vendor **MUST** provide their testing scripts to support testing.
-* R-58775 The VNF Vendor **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-43958 The VNF Package **MUST** include documentation describing the tests that were conducted by the VNF providor and the test results.
+* R-04298 The VNF provider **MUST** provide their testing scripts to support testing.
+* 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.
**Licensing Requirements**
* R-85653 The VNF **MUST** provide metrics (e.g., number of sessions, number of subscribers, number of seats, etc.) to ONAP for tracking every license.
-* R-44125 The VNF Vendor **MUST** agree to the process that can be met by Service Provider reporting infrastructure. The Contract shall define the reporting process and the available reporting tools.
-* R-40827 The VNF Vendor **MUST** enumerate all of the open source licenses their VNF(s) incorporate.
-* R-97293 The VNF Vendor **MUST NOT** require audits of Service Provider’s business.
-* R-44569 The VNF Vendor **MUST NOT** require additional infrastructure such as a vendor license server for Vendor functions and metrics..
+* R-44125 The VNF provider **MUST** agree to the process that can be met by Service Provider reporting infrastructure. The Contract shall define the reporting process and the available reporting tools.
+* R-40827 The VNF provider **MUST** enumerate all of the open source licenses their VNF(s) incorporate.
+* R-97293 The VNF provider **MUST NOT** require audits of Service Provider’s business.
+* R-44569 The VNF provider **MUST NOT** require additional infrastructure such as a VNF provider license server for VNF provider functions and metrics.
* R-13613 The VNF **MUST** provide clear measurements for licensing purposes to allow automated scale up/down by the management system.
-* R-27511 The VNF Vendor **MUST** provide the ability to scale up a vendor supplied product during growth and scale down a vendor supplied product during decline without “real-time” restrictions based upon vendor permissions.
-* R-85991 The VNF Vendor **MUST** provide a universal license key per VNF to be used as needed by services (i.e., not tied to a VM instance) as the recommended solution. The vendor may provide pools of Unique VNF License Keys, where there is a unique key for each VNF instance as an alternate solution. Licensing issues should be resolved without interrupting in-service VNFs.
-* R-47849 The VNF Vendor **MUST** support the metadata about licenses (and their applicable entitlements) as defined in this document for VNF software, and any license keys required to authorize use of the VNF software. This metadata will be used to facilitate onboarding the VNF into the ONAP environment and automating processes for putting the licenses into use and managing the full lifecycle of the licenses. The details of this license model are described in Appendix C. Note: License metadata support in ONAP is not currently available and planned for 1Q 2018.
+* R-27511 The VNF provider **MUST** provide the ability to scale up a VNF provider supplied product during growth and scale down a VNF provider supplied product during decline without “real-time” restrictions based upon VNF provider permissions.
+* R-85991 The VNF provider **MUST** provide a universal license key per VNF to be used as needed by services (i.e., not tied to a VM instance) as the recommended solution. The VNF provider may provide pools of Unique VNF License Keys, where there is a unique key for each VNF instance as an alternate solution. Licensing issues should be resolved without interrupting in-service VNFs.
+* R-47849 The VNF provider **MUST** support the metadata about licenses (and their applicable entitlements) as defined in this document for VNF software, and any license keys required to authorize use of the VNF software. This metadata will be used to facilitate onboarding the VNF into the ONAP environment and automating processes for putting the licenses into use and managing the full lifecycle of the licenses. The details of this license model are described in Appendix C. Note: License metadata support in ONAP is not currently available and planned for 1Q 2018.
c. Configuration Management
===========================
over HTTP(s).
The port number, url, and other authentication information is provided
-by the VNF vendor.
+by the VNF provider.
**REST APIs**
-* R-31809 The VNF **MUST** support the HealthCheck RPC. The HealthCheck RPC executes a vendor-defined VNF Healthcheck over the scope of the entire VNF (e.g., if there are multiple VNFCs, then run a health check, as appropriate, for all VNFCs). It returns a 200 OK if the test completes. A JSON object is returned indicating state (healthy, unhealthy), scope identifier, time-stamp and one or more blocks containing info and fault information. If the VNF is unable to run the HealthCheck, return a standard http error code and message.
+* R-31809 The VNF **MUST** support the HealthCheck RPC. The HealthCheck RPC executes a VNF Provider-defined VNF Healthcheck over the scope of the entire VNF (e.g., if there are multiple VNFCs, then run a health check, as appropriate, for all VNFCs). It returns a 200 OK if the test completes. A JSON object is returned indicating state (healthy, unhealthy), scope identifier, time-stamp and one or more blocks containing info and fault information. If the VNF is unable to run the HealthCheck, return a standard http error code and message.
Examples:
* R-50252 The VNF **MUST** write to a specific set of text files that will be retrieved and made available by the Ansible Server if, as part of a VNF action (e.g., audit), a playbook is required to return any VNF information. The text files must be written in the same directory as the one from which the playbook is being executed. A text file must be created for each host the playbook run targets/affects, with the name ‘<hostname>_results.txt’ into which any desired output from each respective VM/VNF must be written.
* R-51442 The VNF **SHOULD** use playbooks that are designed to automatically ‘rollback’ to the original state in case of any errors for actions that change state of the VNF (e.g., configure).
- NOTE: In case rollback at the playbook level is not supported or possible, vendor shall provide alternative locking mechanism (e.g., for a small VNF the rollback mechanism may rely on workflow to terminate and re-instantiate VNF VMs and then re-run playbook(s)). Backing up updated files also recommended to support rollback when soft rollback is feasible.
+ NOTE: In case rollback at the playbook level is not supported or possible, the VNF provider shall provide alternative locking mechanism (e.g., for a small VNF the rollback mechanism may rely on workflow to terminate and re-instantiate VNF VMs and then re-run playbook(s)). Backing up updated files also recommended to support rollback when soft rollback is feasible.
* R-NNNNN The VNF **SHOULD NOT** use playbooks that make requests to Cloud resources e.g. Openstack (nova, neutron, glance, heat, etc.); therefore, there is no use for Cloud specific variables like Openstack UUIDs in Ansible Playbooks.
| | | |
| Status | | |
+---------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| Audit, Sync | VNF Vendor must provide any necessary roles, cookbooks, recipes to retrieve the running configuration from a VNF and place it in the respective Node Objects ‘PushJobOutput’ attribute of all nodes in NodeList when triggered by a chef-client run. | VNF Vendor must provide an Ansible playbook to retrieve the running configuration from a VNF and place the output on the Ansible server in a manner aligned with playbook requirements listed in this document. |
+| Audit, Sync | VNF provider must provide any necessary roles, cookbooks, recipes to retrieve the running configuration from a VNF and place it in the respective Node Objects ‘PushJobOutput’ attribute of all nodes in NodeList when triggered by a chef-client run. | VNF provider must provide an Ansible playbook to retrieve the running configuration from a VNF and place the output on the Ansible server in a manner aligned with playbook requirements listed in this document. |
| | | |
| | The JSON file for this VNF action is required to set “PushJobFlag” to “True” and “GetOutputFlag” to “True”. The “Node” JSON dictionary must have the run list populated with the necessary sequence of roles, cookbooks, recipes. | The PlaybookName must be provided in the JSON file. |
| | | |
| | | |
| CheckLock | | |
+---------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| Configure, | VNF Vendor must provide any necessary roles, cookbooks, recipes to apply configuration attributes to the VNF when triggered by a chef-client run. All configurable attributes must be obtained from the Environment and Node objects on the Chef Server. | VNF Vendor must provide an Ansible playbook that can configure the VNF with parameters supplied by the Ansible Server. |
+| Configure, | VNF provider must provide any necessary roles, cookbooks, recipes to apply configuration attributes to the VNF when triggered by a chef-client run. All configurable attributes must be obtained from the Environment and Node objects on the Chef Server. | VNF provider must provide an Ansible playbook that can configure the VNF with parameters supplied by the Ansible Server. |
| | | |
| ConfigModify | The JSON file for this VNF action should include all configurable attributes in the Environment and/or Node JSON dictionary. | The PlaybookName must be provided in the JSON file. |
| | | |
| | | |
| Check | | |
+---------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| StartApplication, | VNF Vendor must provide roles, cookbooks, recipes to start an application on the VNF when triggered by a chef-client run. If application does not start, the run must fail or raise an exception. If application is already started, or starts successfully, the run must finish successfully. | VNF Vendor must provide an Ansible playbook to start the application on the VNF. If application does not start, the playbook must indicate failure. If application is already started, or starts successfully, the playbook must finish successfully. |
+| StartApplication, | VNF provider must provide roles, cookbooks, recipes to start an application on the VNF when triggered by a chef-client run. If application does not start, the run must fail or raise an exception. If application is already started, or starts successfully, the run must finish successfully. | VNF provider must provide an Ansible playbook to start the application on the VNF. If application does not start, the playbook must indicate failure. If application is already started, or starts successfully, the playbook must finish successfully. |
| | | |
| StopApplication | For StopApplication, the application must be stopped gracefully (no loss of traffic). | For StopApplication, the application must be stopped gracefully (no loss of traffic). |
+---------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ConfigBackup, | VNF Vendor must provide roles, cookbooks, recipes to backup or restore the configuration parameters on the VNF when triggered by an ECOMP request. | VNF Vendor must provide an Ansible playbook to backup or restore the configuration parameters on the VNF when triggered by an ECOMP request. |
+| ConfigBackup, | VNF provider must provide roles, cookbooks, recipes to backup or restore the configuration parameters on the VNF when triggered by an ECOMP request. | VNF provider must provide an Ansible playbook to backup or restore the configuration parameters on the VNF when triggered by an ECOMP request. |
| | | |
| | When the ConfigBackup command is executed, the current VNF configuration parameters are copied over to the Ansible or Chef server (if there is an existing set of backed up parameters, they are overwritten). When the ConfigRestore command is executed, the VNF configuration parameters | When the ConfigBackup command is executed, the current VNF configuration parameters are copied over to the Ansible or Chef server (if there is an existing set of backed up parameters, they are overwritten). When the ConfigRestore command is executed, the VNF configuration parameters |
| ConfigRestore | which are backed up on the Ansible or Chef server are applied to the VNF (replacing existing parameters). It can be assumed that the VNF is not in service when a ConfigRestore command is executed. | which are backed up on the Ansible or Chef server are applied to the VNF (replacing existing parameters). It can be assumed that the VNF is not in service when a ConfigRestore command is executed. |
The target direction for VNF interfaces is to employ APIs that are implemented
utilizing standardized messaging and modeling protocols over standardized transports.
Migrating to a virtualized environment presents a tremendous opportunity to eliminate
-the need for proprietary interfaces for vendor equipment while removing the traditional
+the need for proprietary interfaces for VNF provider equipment while removing the traditional
boundaries between Network Management Systems and Element Management Systems. Additionally,
VNFs provide the ability to instrument the networking applications by creating event
records to test and monitor end-to-end data flow through the network, similar to what
physical or virtual probes provide without the need to insert probes at various points
-in the network. The VNF vendors must be able to provide the aforementioned set of required
+in the network. The VNF providers must be able to provide the aforementioned set of required
data directly to the ONAP collection layer using standardized interfaces.
Data Model for Event Records
name used in JSON specification) records. In the future, these may be
extended to support other types of technology independent records. Each
of these records allows additional fields (name/ value pairs) for extensibility.
- The vendors can use these vendor-specific additional fields to provide
+ The VNF provider can use these VNF Provider-specific additional fields to provide
additional information that may be relevant to the managing systems.
- Technology Specific Records: This version of the document specifies the model
for Mobile Flow records, Signaling and Voice Quality records. In the future,
these may be extended to support other types of records (e.g. Network Fabric,
Security records, etc.). Each of these records allows additional fields
- (name/value pairs) for extensibility. The VNF vendors can use these VNF-specific
+ (name/value pairs) for extensibility. The VNF providers can use these VNF-specific
additional fields to provide additional information that may be relevant to the
managing systems. A placeholder for additional technology specific areas of
interest to be defined in the future documents has been depicted.
volumes and required processing.
In the following sections, we provide options for encoding, serialization and data
-delivery. Agreements between Service Providers and VNF vendors shall determine which
+delivery. Agreements between Service Providers and VNF providers shall determine which
encoding, serialization and delivery method to use for particular data sets. The selected
methods must be agreed to prior to the on-boarding of the VNF into ONAP design studio.
Figure 2. VES/JSON Driven Model
-VNF vendors will provide a YAML artifact to the Service Provider that describes:
+VNF providers will provide a YAML artifact to the Service Provider that describes:
* standard VES/JSON model information elements (key/values) that the VNF provides
* any additional non-standard (custom) VES/JSON model information elements (key/values) that the VNF provides
-Using the semantics and syntax supported by YAML, vendors will indicate specific conditions that may
+Using the semantics and syntax supported by YAML, VNF providers will indicate specific conditions that may
arise, and recommend actions that should be taken at specific thresholds, or if specific conditions
repeat within a specified time interval.
-Based on the vendor’s recommendations, the Service Provider may create additional YAML artifacts
+Based on the VNF provider’s recommendations, the Service Provider may create additional YAML artifacts
(using ONAP design Studio), which finalizes Service Provider engineering rules for the processing of
-the vendor’s events. The Service Provider may alter the threshold levels recommended by the vendor,
+the VNF events. The Service Provider may alter the threshold levels recommended by the VNF providor,
and may modify and more clearly specify actions that should be taken when specified conditions arise.
The Service Provider-created version of the YAML artifact will be distributed to ONAP applications
by the Design framework.
Figure 3. YANG Driven Model
-VNF vendors will provide to the Service Provider the following YANG model artifacts:
+VNF providers will provide to the Service Provider the following YANG model artifacts:
* common IETF YANG modules that support the VNF
-* native (vendor-supplied) YANG modules that support the VNF
+* native (VNF provider-supplied) YANG modules that support the VNF
* open (OpenConfig) YANG modules and the following configuration-related information, including:
* telemetry configuration and operational state data; such as:
* YANG helper or decoder functions that automate the conversion between YANG model data types to VES/JSON information elements
* OPTIONAL: YANG Telemetry modules in JSON format per RFC 7951
-Using the semantics and syntax supported by YANG, vendors will indicate specific conditions that may
+Using the semantics and syntax supported by YANG, VNF providers will indicate specific conditions that may
arise, and recommend actions that should be taken at specific thresholds, or if specific conditions
repeat within a specified time interval.
-Based on the vendor’s recommendations, the Service Provider may create additional YAML artifacts
+Based on the VNF provider’s recommendations, the Service Provider may create additional YAML artifacts
(using ONAP design Studio), which finalizes Service Provider engineering rules for the processing
-of the vendor’s events. The Service Provider may alter the threshold levels recommended by the
-vendor, and may modify and more clearly specify actions that should be taken when specified
+of the VNF events. The Service Provider may alter the threshold levels recommended by the
+VNF provider, and may modify and more clearly specify actions that should be taken when specified
conditions arise. The Service Provided-created version of the YAML will be distributed to ONAP
applications by the Design framework.
In addition to the data delivery models described above, support for delivery of VNF telemetry
using Google Protocol Buffers (GPB) can also be supported, as depicted in Figure 4.
-VNF vendors will provide to the Service Provider the additional following artifacts to
+VNF providers will provide to the Service Provider the additional following artifacts to
support the delivery of VNF telemetry to DCAE via the open-source gRPC mechanism using
Google's Protocol Buffers:
* keys are strings that correspond to the path of the system resources for the VNF being monitored.
* values correspond to integers or strings that identify the operational state of the VNF resource, such a statistics counters and the state of a VNF resource.
-* VNF vendors must supply valid KV-GPB definition file(s) to allow for the decoding of all KV-GPB encoded telemetry messages.
+* VNF providers must supply valid KV-GPB definition file(s) to allow for the decoding of all KV-GPB encoded telemetry messages.
* Native Google Protocol Buffers (GPB) is also known as compact GPB:
* keys are represented as integers pointing to the system resources for the VNF being monitored.
* values correspond to integers or strings that identify the operational state of the VNF resource, such a statistics counters and the state of a VNF resource.
-* Google Protocol Buffers (GPB) requires metadata in the form of .proto files. VNF vendors must supply the necessary GPB .proto files such that GPB telemetry messages can be encoded and decoded.
+* Google Protocol Buffers (GPB) requires metadata in the form of .proto files. VNF providers must supply the necessary GPB .proto files such that GPB telemetry messages can be encoded and decoded.
* In the future, we may consider support for other types of encoding & serialization methods based on industry demand
“GetOutputFlag” : “False”
}
-The example JSON file provided by the vendor for each VNF action will be
+The example JSON file provided by the VNF provider for each VNF action will be
turned into a template by ONAP, that can be updated with instance
specific values at run-time.
+------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+---------------------------------------------------------------------+
| **Field Name** | **Description** | **Type** | **Comment** |
+==================+============================================================================================================================================================================================================================================================================================+=============+=====================================================================+
-| PlaybookName | VNF Vendor must list name of the playbook used to execute the VNF action. | Mandatory | |
+| PlaybookName | VNF providor must list name of the playbook used to execute the VNF action. | Mandatory | |
+------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+---------------------------------------------------------------------+
| Action | Name of VNF action. | Optional | |
+------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+---------------------------------------------------------------------+
Table C1. Required Fields for General Information
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-+--------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+-------------+
-| **Field Name** | **Description** | **Data Type** | **Type** |
-+================================+===========================================================================================================================================================================================================================================================================================================+===================+=============+
-| Vendor Name | The name of the vendor. | String | Mandatory |
-+--------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+-------------+
-| Vendor Product | The name of the product to which this agreement applies. | String | Mandatory |
-| | | | |
-| | Note: a contract/agreement may apply to more than one vendor product. In that case, provide the metadata for each product separately. | | |
-+--------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+-------------+
-| Vendor Product Description | A general description of vendor software product. | String | Optional |
-+--------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+-------------+
-| Export Control | ECCNs are 5-character alpha-numeric designations used on the Commerce Control List (CCL) to identify dual-use items for export control purposes. An ECCN categorizes items based on the nature of the product, i.e. type of commodity, software, or technology and its respective technical parameters. | String | Mandatory |
-| | | | |
-| Classification Number (ECCN) | | | |
-+--------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+-------------+
-| Reporting Requirements | A list of any reporting requirements on the usage of the software product. | List of strings | Optional |
-+--------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+-------------+
++---------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+-------------+
+| **Field Name** | **Description** | **Data Type** | **Type** |
++=============================================+===========================================================================================================================================================================================================================================================================================================+===================+=============+
+| VNF Provider Name | The name of the VNF provider. | String | Mandatory |
++---------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+-------------+
+| VNF Provider Product | The name of the product to which this agreement applies. | String | Mandatory |
+| | | | |
+| | Note: a contract/agreement may apply to more than one VNF provider product. In that case, provide the metadata for each product separately. | | |
++---------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+-------------+
+| VNF Provider Product Description | A general description of VNF provider software product. | String | Optional |
++---------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+-------------+
+| Export Control Classification Number (ECCN) | ECCNs are 5-character alpha-numeric designations used on the Commerce Control List (CCL) to identify dual-use items for export control purposes. An ECCN categorizes items based on the nature of the product, i.e. type of commodity, software, or technology and its respective technical parameters. | String | Mandatory |
++---------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+-------------+
+| Reporting Requirements | A list of any reporting requirements on the usage of the software product. | List of strings | Optional |
++---------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+-------------+
1. Entitlements
Table C2. Required Fields for Entitlements
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-+-----------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+---------------+
-| **Field Name** | **Description** | **Data Type** | **Type** |
-+=====================================================+=======================================================================================================================================================================================+===================+===============+
-| Vendor Part Number / Manufacture Reference Number | Identifier for the entitlement as described by the vendor in their price list / catalog / contract. | String | Mandatory |
-+-----------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+---------------+
-| Description | Verbiage that describes the entitlement. | String | Optional |
-+-----------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+---------------+
-| Entitlement Identifier | Each entitlement defined must be identified by a unique value (e.g., numbered 1, 2, 3….) | String | Mandatory |
-+-----------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+---------------+
-| Minimum Order Requirement | The minimum number of entitlements that need to be purchased. For example, the entitlements must be purchased in a block of 100. If no minimum is required, the value will be zero. | Number | Mandatory |
-+-----------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+---------------+
-| Unique Reporting Requirements | A list of any reporting requirements on the usage of the software product. (e.g.: quarterly usage reports are required) | List of Strings | Optional |
-+-----------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+---------------+
-| License Type | Type of license applicable to the software product. (e.g.: fixed-term, perpetual, trial, subscription.) | String | Mandatory |
-+-----------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+---------------+
-| License Duration | Valid values: | String | Conditional |
-| | | | |
-| | **year**, **quarter**, **month**, **day**. | | |
-| | | | |
-| | Not applicable when license type is Perpetual. | | |
-+-----------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+---------------+
-| License Duration Quantification | Number of years, quarters, months, or days for which the license is valid. | Number | Conditional |
-| | | | |
-| | Not applicable when license type is Perpetual. | | |
-+-----------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+---------------+
-| Limits | see section C.4 for possible values | List | Optional |
-+-----------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+---------------+
++---------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+---------------+
+| **Field Name** | **Description** | **Data Type** | **Type** |
++=========================================================+=======================================================================================================================================================================================+===================+===============+
+| VNF Provider Part Number / Manufacture Reference Number | Identifier for the entitlement as described by the VNF provider in their price list / catalog / contract. | String | Mandatory |
++---------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+---------------+
+| Description | Verbiage that describes the entitlement. | String | Optional |
++---------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+---------------+
+| Entitlement Identifier | Each entitlement defined must be identified by a unique value (e.g., numbered 1, 2, 3….) | String | Mandatory |
++---------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+---------------+
+| Minimum Order Requirement | The minimum number of entitlements that need to be purchased. For example, the entitlements must be purchased in a block of 100. If no minimum is required, the value will be zero. | Number | Mandatory |
++---------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+---------------+
+| Unique Reporting Requirements | A list of any reporting requirements on the usage of the software product. (e.g.: quarterly usage reports are required) | List of Strings | Optional |
++---------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+---------------+
+| License Type | Type of license applicable to the software product. (e.g.: fixed-term, perpetual, trial, subscription.) | String | Mandatory |
++---------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+---------------+
+| License Duration | Valid values: | String | Conditional |
+| | | | |
+| | **year**, **quarter**, **month**, **day**. | | |
+| | | | |
+| | Not applicable when license type is Perpetual. | | |
++---------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+---------------+
+| License Duration Quantification | Number of years, quarters, months, or days for which the license is valid. | Number | Conditional |
+| | | | |
+| | Not applicable when license type is Perpetual. | | |
++---------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+---------------+
+| Limits | see section C.4 for possible values | List | Optional |
++---------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+---------------+
1. License Keys
+------------------------+---------------------------------------------------------------------------------------------------------------------+------------------+-------------+
| Limit Type | Valid values: **city, county, state, country, region, MSA, BTA, CLLI** | String | Mandatory |
+------------------------+---------------------------------------------------------------------------------------------------------------------+------------------+-------------+
-| Limit List | List of locations where the Vendor Product can be used or needs to be restricted from use | List of String | Mandatory |
+| Limit List | List of locations where the VNF provider Product can be used or needs to be restricted from use | List of String | Mandatory |
+------------------------+---------------------------------------------------------------------------------------------------------------------+------------------+-------------+
| Limit Set Type | Indicates if the list is an inclusion or exclusion. | String | Mandatory |
| | | | |
+------------------------+-------------------------------------------------------------------------------------------------------------------------------+------------------+---------------+
| Limit Type | Valid values: **duration, date** | String | Mandatory |
+------------------------+-------------------------------------------------------------------------------------------------------------------------------+------------------+---------------+
-| Limit List | List of times for which the Vendor Product can be used or needs to be restricted from use | List of String | Mandatory |
+| Limit List | List of times for which the VNF Provider Product can be used or needs to be restricted from use | List of String | Mandatory |
+------------------------+-------------------------------------------------------------------------------------------------------------------------------+------------------+---------------+
| Duration Units | Required when limit type is duration. Valid values: **perpetual, year, quarter, month, day, minute, second, millisecond** | String | Conditional |
+------------------------+-------------------------------------------------------------------------------------------------------------------------------+------------------+---------------+
+------------------------+--------------------------------------------------------------------------------------------------------------+------------------+-------------+
| Limit Type | Valid values: **product line, organization, internal customer, external customer** | String | Mandatory |
+------------------------+--------------------------------------------------------------------------------------------------------------+------------------+-------------+
-| Limit List | List of entities for which the Vendor Product can be used or needs to be restricted from use | List of String | Mandatory |
+| Limit List | List of entities for which the VNF Provider Product can be used or needs to be restricted from use | List of String | Mandatory |
+------------------------+--------------------------------------------------------------------------------------------------------------+------------------+-------------+
| Limit Set Type | Indicates if the list is an inclusion or exclusion. | String | Mandatory |
| | | | |
R-42207: The VNF **MUST** design resiliency into a VNF such that the resiliency deployment model (e.g., active-active) can be chosen at run-time.
-R-98617: The VNF Vendor **MUST** provide information regarding any dependency (e.g., affinity, anti-affinity) with other VNFs and resources.
+R-98617: The VNF provider **MUST** provide information regarding any dependency (e.g., affinity, anti-affinity) with other VNFs and resources.
R-62498: The VNF **MUST**, if not using the NCSP’s IDAM API, encrypt OA&M access (e.g., SSH, SFTP).
R-57271: The VNF **MUST** provide the capability of generating security audit logs by interacting with the operating system (OS) as appropriate.
-R-44569: The VNF Vendor **MUST NOT** require additional infrastructure such as a vendor license server for Vendor functions and metrics..
+R-44569: The VNF provider **MUST NOT** require additional infrastructure such as a VNF provider license server for VNF providor functions and metrics..
R-67918: The VNF **MUST** handle replication race conditions both locally and geo-located in the event of a data base instance failure to maintain service continuity.
R-58977: The VNF **MUST** provide or support the Identity and Access Management (IDAM) based threat detection data for Eavesdropping.
-R-59391: The VNF vendor **MUST**, where a VNF vendor requires the assumption of permissions, such as root or administrator, first log in under their individual user login ID then switch to the other higher level account; or where the individual user login is infeasible, must login with an account with admin privileges in a way that uniquely identifies the individual performing the function.
+R-59391: The VNF provider **MUST**, where a VNF provider requires the assumption of permissions, such as root or administrator, first log in under their individual user login ID then switch to the other higher level account; or where the individual user login is infeasible, must login with an account with admin privileges in a way that uniquely identifies the individual performing the function.
R-93443: The VNF **MUST** define all data models in YANG [RFC6020], and the mapping to NETCONF shall follow the rules defined in this RFC.
R-46908: The VNF **MUST**, if not using the NCSP’s IDAM API, comply with "password complexity" policy. When passwords are used, they shall be complex and shall at least meet the following password construction requirements: (1) be a minimum configurable number of characters in length, (2) include 3 of the 4 following types of characters: upper-case alphabetic, lower-case alphabetic, numeric, and special, (3) not be the same as the UserID with which they are associated or other common strings as specified by the environment, (4) not contain repeating or sequential characters or numbers, (5) not to use special characters that may have command functions, and (6) new passwords must not contain sequences of three or more characters from the previous password.
-R-86261: The VNF **MUST NOT** allow vendor access to VNFs remotely.
+R-86261: The VNF **MUST NOT** allow VNF provider access to VNFs remotely.
R-75343: The VNF **MUST** provide the capability of testing the validity of a digital certificate by recognizing the identity represented by the certificate — the "distinguished name".
R-10173: The VNF **MUST** allow another NETCONF session to be able to initiate the release of the lock by killing the session owning the lock, using the <kill-session> operation to guard against hung NETCONF sessions.
-R-36280: The VNF Vendor **MUST** provide documentation describing VNF Functional Capabilities that are utilized to operationalize the VNF and compose complex services.
+R-36280: The VNF provider **MUST** provide documentation describing VNF Functional Capabilities that are utilized to operationalize the VNF and compose complex services.
R-15671: The VNF **MUST NOT** provide public or unrestricted access to any data without the permission of the data owner. All data classification and access controls must be followed.
R-97445: The VNF **MUST** log the field “date/time” in the security audit logs.
-R-16777: The VNF Vendor **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-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-08134: The VNF **MUST** conform to the NETCONF RFC 6241, “NETCONF Configuration Protocol”.
R-42140: The VNF **MUST** respond to data requests from ONAP as soon as those requests are received, as a synchronous response.
-R-27511: The VNF Vendor **MUST** provide the ability to scale up a vendor supplied product during growth and scale down a vendor supplied product during decline without “real-time” restrictions based upon vendor permissions.
+R-27511: The VNF provider **MUST** provide the ability to scale up a VNF provider supplied product during growth and scale down a VNF provider supplied product during decline without “real-time” restrictions based upon VNF provider permissions.
R-05470: The VNF **MUST** host connectors for access to the database layer.
R-63217: The VNF **MUST**, if not using the NCSP’s IDAM API, support logging via ONAP for a historical view of “who did what and when”.
-R-44125: The VNF Vendor **MUST** agree to the process that can be met by Service Provider reporting infrastructure. The Contract shall define the reporting process and the available reporting tools.
+R-44125: The VNF provider **MUST** agree to the process that can be met by Service Provider reporting infrastructure. The Contract shall define the reporting process and the available reporting tools.
R-22700: The VNF **MUST** conform its YANG model to RFC 6470, “NETCONF Base Notifications”.
R-73285: The VNF **MUST** must encode the delivered data using JSON or Avro, addressed and delivered as described in the previous paragraphs.
-R-85028: The VNF **MUST** authenticate system to system access and do not conceal a VNF vendor user’s individual accountability for transactions.
+R-85028: The VNF **MUST** authenticate system to system access and do not conceal a VNF provider user’s individual accountability for transactions.
R-28545: The VNF **MUST** conform its YANG model to RFC 6060, “YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)”
R-49145: The VNF **MUST** implement **:confirmed-commit** If **:candidate** is supported.
-R-04298: The VNF Vendor **MUST** provide their testing scripts to support testing.
+R-04298: The VNF provider **MUST** provide their testing scripts to support testing.
R-92935: The VNF **SHOULD** minimize the propagation of state information across multiple data centers to avoid cross data center traffic.
R-32217: The VNF **MUST** have routable FQDNs that are reachable via the Ansible Server for the endpoints (VMs) of a VNF on which playbooks will be executed. ONAP will initiate requests to the Ansible Server for invocation of playbooks against these end points [4]_.
-R-47849: The VNF Vendor **MUST** support the metadata about licenses (and their applicable entitlements) as defined in this document for VNF software, and any license keys required to authorize use of the VNF software. This metadata will be used to facilitate onboarding the VNF into the ONAP environment and automating processes for putting the licenses into use and managing the full lifecycle of the licenses. The details of this license model are described in Appendix C. Note: License metadata support in ONAP is not currently available and planned for 1Q 2018.
+R-47849: The VNF provider **MUST** support the metadata about licenses (and their applicable entitlements) as defined in this document for VNF software, and any license keys required to authorize use of the VNF software. This metadata will be used to facilitate onboarding the VNF into the ONAP environment and automating processes for putting the licenses into use and managing the full lifecycle of the licenses. The details of this license model are described in Appendix C. Note: License metadata support in ONAP is not currently available and planned for 1Q 2018.
R-85419: The VNF **SHOULD** use REST APIs exposed to Client Applications for the implementation of OAuth 2.0 Authorization Code Grant and Client Credentials Grant, as the standard interface for a VNF.
R-48917: The VNF **MUST** monitor for and alert on (both sender and receiver) errant, running longer than expected and missing file transfers, so as to minimize the impact due to file transfer errors.
-R-79107: The VNF **MUST**, if not using the NCSP’s IDAM API, enforce a configurable maximum number of Login attempts policy for the users. VNF vendor must comply with "terminate idle sessions" policy. Interactive sessions must be terminated, or a secure, locking screensaver must be activated requiring authentication, after a configurable period of inactivity. The system-based inactivity timeout for the enterprise identity and access management system must also be configurable.
+R-79107: The VNF **MUST**, if not using the NCSP’s IDAM API, enforce a configurable maximum number of Login attempts policy for the users. VNF provider must comply with "terminate idle sessions" policy. Interactive sessions must be terminated, or a secure, locking screensaver must be activated requiring authentication, after a configurable period of inactivity. The system-based inactivity timeout for the enterprise identity and access management system must also be configurable.
R-75850: The VNF **SHOULD** decouple persistent data from the VNFC and keep it in its own datastore that can be reached by all instances of the VNFC requiring the data.
R-64768: The VNF **MUST** limit the size of application data packets to no larger than 9000 bytes for SDN network-based tunneling when guest data packets are transported between tunnel endpoints that support guest logical networks.
-R-75608: The VNF Vendor **MUST** provide playbooks to be loaded on the appropriate Ansible Server.
+R-75608: The VNF provider **MUST** provide playbooks to be loaded on the appropriate Ansible Server.
R-61354: The VNF **MUST** implement access control list for OA&M services (e.g., restricting access to certain ports or applications).
R-20974: The VNF **MUST** deploy the base module first, prior to the incremental modules.
-R-69610: The VNF **MUST** provide the capability of using certificates issued from a Certificate Authority not provided by the VNF vendor.
+R-69610: The VNF **MUST** provide the capability of using certificates issued from a Certificate Authority not provided by the VNF provider.
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-31412: The VNF **MUST** provide or support the Identity and Access Management (IDAM) based threat detection data for XSS / CSRF.
-R-58775: The VNF Vendor **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-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-45496: The VNF **MUST** host connectors for access to the OS (Operating System) layer.
R-49308: The VNF **SHOULD** test for adherence to the defined resiliency rating recommendation at each layer, during each delivery cycle with delivered results, so that the resiliency rating is measured and the code is adjusted to meet software resiliency requirements.
-R-74763: The VNF Vendor **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 <https://github.com/att/evel-test-collector/tree/master/docs/att_interface_definition>`__)
+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 <https://github.com/att/evel-test-collector/tree/master/docs/att_interface_definition>`__)
R-77786: The VNF Package **MUST** include all relevant cookbooks to be loaded on the ONAP Chef Server.
R-58421: The VNF **SHOULD** be decomposed into granular re-usable VNFCs.
-R-27711: The VNF Vendor **MUST** provide an XML file that contains a list of VNF error codes, descriptions of the error, and possible causes/corrective action.
+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-78282: The VNF **MUST** conform to the NETCONF RFC 6242, “Using the Network Configuration Protocol over Secure Shell”.
R-33981: The VNF **SHOULD** interoperate with various access control mechanisms for the Network Cloud execution environment (e.g., Hypervisors, containers).
-R-26881: The VNF Vendor **MUST** provide the binaries and images needed to instantiate the VNF (VNF and VNFC images).
+R-26881: The VNF provider **MUST** provide the binaries and images needed to instantiate the VNF (VNF and VNFC images).
R-69565: The VNF Package **MUST** include documentation describing VNF Management APIs. The document must include information and tools for:
R-29967: The VNF **MUST** conform its YANG model to RFC 6022, “YANG module for NETCONF monitoring”.
-R-80335: The VNF **MUST** make visible a Warning Notices: A formal statement of resource intent, i.e., a warning notice, upon initial access to a VNF vendor user who accesses private internal networks or Company computer resources, e.g., upon initial logon to an internal web site, system or application which requires authentication.
+R-80335: The VNF **MUST** make visible a Warning Notices: A formal statement of resource intent, i.e., a warning notice, upon initial access to a VNF provider user who accesses private internal networks or Company computer resources, e.g., upon initial logon to an internal web site, system or application which requires authentication.
R-48596: The VNF Package **MUST** include documentation describing the characteristics for the VNF reliability and high availability.
R-15659: The VNF **MUST** restrict changing the criticality level of a system security alarm to administrator(s).
-R-96634: The VNF Vendor **MUST** describe scaling capabilities to manage scaling characteristics of the VNF.
+R-96634: The VNF provider **MUST** describe scaling capabilities to manage scaling characteristics of the VNF.
R-32641: The VNF **MUST** provide the capability to encrypt data on non-volatile memory.
R-89474: The VNF **MUST** log the field “Login ID” in the security audit logs.
-R-13390: The VNF Vendor **MUST** provide cookbooks to be loaded on the appropriate Chef Server.
+R-13390: The VNF provider **MUST** provide cookbooks to be loaded on the appropriate Chef Server.
R-24825: The VNF **MUST** provide Context awareness data (device, location, time, etc.) and be able to integrate with threat detection system.
R-27995: The VNF **SHOULD** include control loop mechanisms to notify the consumer of the VNF of their exceeding SLA thresholds so the consumer is able to control its load against the VNF.
-R-31809: The VNF **MUST** support the HealthCheck RPC. The HealthCheck RPC, executes a vendor-defined VNF Healthcheck over the scope of the entire VNF (e.g., if there are multiple VNFCs, then run a health check, as appropriate, for all VNFCs). It returns a 200 OK if the test completes. A JSON object is returned indicating state (healthy, unhealthy), scope identifier, time-stamp and one or more blocks containing info and fault information. If the VNF is unable to run the HealthCheck, return a standard http error code and message.
+R-31809: The VNF **MUST** support the HealthCheck RPC. The HealthCheck RPC, executes a VNF providor-defined VNF Healthcheck over the scope of the entire VNF (e.g., if there are multiple VNFCs, then run a health check, as appropriate, for all VNFCs). It returns a 200 OK if the test completes. A JSON object is returned indicating state (healthy, unhealthy), scope identifier, time-stamp and one or more blocks containing info and fault information. If the VNF is unable to run the HealthCheck, return a standard http error code and message.
R-25401: The VNF **MUST** use asymmetric keys of at least 2048 bits in length.
R-51883: The VNF **MUST** provide or support the Identity and Access Management (IDAM) based threat detection data for Replay.
-R-66070: The VNF Package **MUST** include VNF Identification Data to uniquely identify the resource for a given Vendor. The identification data must include: an identifier for the VNF, the name of the VNF as was given by the VNF Vendor, VNF description, VNF Vendor, and version.
+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-19804: The VNF **MUST** validate the CA signature on the certificate, ensure that the date is within the validity period of the certificate, check the Certificate Revocation List (CRL), and recognize the identity represented by the certificate where PKI-based authentication is used.
R-22645: The VNF **SHOULD** use commercial algorithms only when there are no applicable governmental standards for specific cryptographic functions, e.g., public key cryptography, message digests.
-R-22888: The VNF Vendor **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-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-78066: The VNF **MUST** support requests for information from law enforcement and government agencies.
R-41252: The VNF **MUST** support the capability of online storage of security audit logs.
-R-77707: The VNF Vendor **MUST** include a Manifest File that contains a list of all the components in the VNF package.
+R-77707: The VNF provider **MUST** include a Manifest File that contains a list of all the components in the VNF package.
R-20860: The VNF **MUST** be agnostic to the underlying infrastructure (such as hardware, host OS, Hypervisor), any requirements should be provided as specification to be fulfilled by any hardware.
R-46986: The VNF **SHOULD** have source code scanned using scanning tools (e.g., Fortify) and provide reports.
-R-97293: The VNF Vendor **MUST NOT** require audits of Service Provider’s business.
+R-97293: The VNF provider **MUST NOT** require audits of Service Provider’s business.
-R-16065: The VNF Vendor **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-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-34484: The VNF **SHOULD** create a single component VNF for VNFCs that can be used by other VNFs.
-R-30278: The VNF Vendor **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-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-35401: The VNF **MUST** must support SSH and allow SSH access to the Ansible server for the endpoint VM(s) and comply with the Network Cloud Service Provider guidelines for authentication and access.
R-37028: The VNF **MUST** be composed of one “base” module.
-R-40827: The VNF Vendor **MUST** enumerate all of the open source licenses their VNF(s) incorporate.
+R-40827: The VNF provider **MUST** enumerate all of the open source licenses their VNF(s) incorporate.
R-95950: The VNF **MUST** provide a NETCONF interface fully defined by supplied YANG models for the embedded NETCONF server.
R-34957: The VNF **MUST** provide a method of metrics gathering for each layer's performance to identify/document variances in the allocations so they can be addressed.
-R-43958: The VNF Package **MUST** include documentation describing the tests that were conducted by the Vendor and the test results.
+R-43958: The VNF Package **MUST** include documentation describing the tests that were conducted by the VNF provider and the test results.
R-61648: The VNF **MUST** support event logging, formats, and delivery tools to provide the required degree of event data to ONAP
-R-18525: The VNF Vendor **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-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-99174: The VNF **MUST** comply with Individual Accountability (each person must be assigned a unique ID) when persons or non-person entities access VNFs.
-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. Vendor default credentials, community strings and other such artifacts will be removed or disclosed so that they can be modified or removed during provisioning.
+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-58358: The VNF **MUST** implement the **:with-defaults** capability [RFC6243].
R-41215: The VNF **MAY** have zero to many “incremental” modules.
-R-85991: The VNF Vendor **MUST** provide a universal license key per VNF to be used as needed by services (i.e., not tied to a VM instance) as the recommended solution. The vendor may provide pools of Unique VNF License Keys, where there is a unique key for each VNF instance as an alternate solution. Licensing issues should be resolved without interrupting in-service VNFs.
+R-85991: The VNF provider **MUST** provide a universal license key per VNF to be used as needed by services (i.e., not tied to a VM instance) as the recommended solution. The VNF provider may provide pools of Unique VNF License Keys, where there is a unique key for each VNF instance as an alternate solution. Licensing issues should be resolved without interrupting in-service VNFs.
R-52085: The VNF **MUST**, if not using the NCSP’s IDAM API, provide the ability to support Multi-Factor Authentication (e.g., 1st factor = Software token on device (RSA SecureID); 2nd factor = User Name+Password, etc.) for the users.
R-29495: The VNF **MUST** support locking if a common object is being manipulated by two simultaneous NETCONF configuration operations on the same VNF within the context of the same writable running data store (e.g., if an interface parameter is being configured then it should be locked out for configuration by a simultaneous configuration operation on that same interface parameter).
-R-31751: The VNF **MUST** subject vendor VNF access to privilege reconciliation tools to prevent access creep and ensure correct enforcement of access policies.
+R-31751: The VNF **MUST** subject VNF provider VNF access to privilege reconciliation tools to prevent access creep and ensure correct enforcement of access policies.
R-48698: The VNF **MUST** utilize information from key value pairs that will be provided by the Ansible Server as extra-vars during invocation to execute the desired VNF action. If the playbook requires files, they must also be supplied using the methodology detailed in the Ansible Server API.
R-59610: The VNF **MUST** implement the data model discovery and download as defined in [RFC6022].
-R-49945: The VNF **MUST** authorize vendor access through a client application API by the client application owner and the resource owner of the VNF before provisioning authorization through Role Based Access Control (RBAC), Attribute Based Access Control (ABAC), or other policy based mechanism.
+R-49945: The VNF **MUST** authorize VNF provider access through a client application API by the client application owner and the resource owner of the VNF before provisioning authorization through Role Based Access Control (RBAC), Attribute Based Access Control (ABAC), or other policy based mechanism.
R-20912: The VNF **MUST** support alternative monitoring capabilities when VNFs do not expose data or control traffic or use proprietary and optimized protocols for inter VNF communication.
some cases corresponds to the stack name for the VNF when VNF instance
is built based on a single module, single stack. Example of VNF instance
name: vfdb9904v. All VNF performing this function, running the same
-software, coming from the same vendor will start with the same 4
+software, coming from the same VNF provider will start with the same 4
characters, in this example, vfdb.
VNF type, determined through these 4 characters, is also known as VNF
8. Upload any SSH keys referenced on hosts file to appropriate
directory.
-NOTE: HOT templates used by heat to instantiate VNF configured by these
+NOTE: HOT templates used by Heat to instantiate VNF configured by these
playbooks shall include the same SSH key to be installed as part of
instantiation.
-Other non-vendor specific playbook tasks need to be incorporated on
+Other non-VNF provider specific playbook tasks need to be incorporated on
overall post-instantiation configuration playbooks or company Playbooks
-need to be uploaded and executed after VNF vendor provided or internally
+need to be uploaded and executed after VNF provided or internally
developed playbooks for the VNF.
Code Review / vnfrqts / requirements.git / commitdiff