* R-85633 The VNF **MUST** implement Data Storage Encryption (database/disk encryption) for Sensitive Personal Information (SPI) and other subscriber identifiable data. Note: subscriber’s SPI/data must be encrypted at rest, and other subscriber identifiable data should be encrypted at rest. Other data protection requirements exist and should be well understood by the developer.
* R-92207 The VNF **SHOULD** implement a mechanism for automated and frequent "system configuration (automated provisioning / closed loop)" auditing.
* 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-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-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-95105 The VNF **MUST** host connectors for access to the application layer.
* R-45496 The VNF **MUST** host connectors for access to the OS (Operating System) layer.
* R-05470 The VNF **MUST** host connectors for access to the database layer.
-* R-77737 The VNF **MUST**
+* R-77737 The VNF **MUST**
* 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.
d. VNF Modularity
=================
-ONAP Heat Orchestration Templates: Overview
+ONAP Heat Orchestration Templates: Overview
-------------------------------------------
ONAP supports a modular Heat Orchestration Template design pattern,
=======================
Aid to help the VNF vendor to fasten the integration with the GVNFM, the
-OpenO provides the VNF SDK tools, and the documents. In this charter,
+ONAP provides the VNF SDK tools, and the documents. In this charter,
the develop steps for VNF vendors will be introduced.
First, using the VNF SDK tools to design the VNF with TOSCA model and
-------------
This reference document is the VNF TOSCA Template Requirements for
-OpenO, which provides recommendations and standards for building VNF
-TOSCA templates compatible with OpenO– initial implementations of
+ONAP, which provides recommendations and standards for building VNF
+TOSCA templates compatible with ONAP initial implementations of
Network Cloud. It has the following features:
1. VNF TOSCA template designer supports GUI and CLI.
-----------------
This document is intended for persons developing VNF TOSCA templates
-that will be orchestrated by OpenO.
+that will be orchestrated by ONAP.
-Scope
-------
+Scope
+-----
-OpenO implementations of Network Cloud supports TOSCA Templates, also
+ONAP implementations of Network Cloud supports TOSCA Templates, also
referred to as TOSCA in this document.
-OpenO requires the TOSCA Templates to follow a specific format. This
+ONAP requires the TOSCA Templates to follow a specific format. This
document provides the mandatory, recommended, and optional requirements
associated with this format.
-Overview
+Overview
---------
The document includes three charters to help the VNF vendors to use the
VNF model design tools and understand the VNF package structure and VNF
TOSCA templates.
-In the OPENO, VNF Package and VNFD template can be designed by manually
+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
template.
NFV TOSCA Template
------------------
-TOSCA templates supported by OPENO must follow the requirements
+TOSCA templates supported by ONAP must follow the requirements
enumerated in this section.
TOSCA Introduction
how many times the component can occur.
|image1|
-Figure 1: Structural Elements of Service Template and their Relations
+Figure 1: Structural Elements of Service Template and their Relations
TOSCA Modeling Principles & Data Model
--------------------------------------
Artifact
^^^^^^^^
+-----------+------------+-------------------------------+---------------+------------------------------------------------+
-| Name | Required | Type | Constraints | Description |
+| Name | Required | Type | Constraints | Description |
+===========+============+===============================+===============+================================================+
| SwImage | Yes | tosca.artifacts.nfv.SwImage | | Describes the software image which is |
| | | | | directly realizing this virtual storage |
+-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
-| Name | Required | Type | Constraints | Description |
+| Name | Required | Type | Constraints | Description |
+===============================+============+==========================================+==========================================================================+
-| bitrate_requirement | no | integer | | Bitrate requirement on this connection point. |
+| bitrate_requirement | no | integer | | Bitrate requirement on this connection point. |
+-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
| virtual\_network\_interface_\ | no | VirtualNetworkInterfaceRequirements | | Specifies requirements on a virtual network |
-| requirements | | | | realising the CPs instantiated from this CPD |
+| requirements | | | | realising the CPs instantiated from this CPD |
+-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+
Attributes
.. code-block:: python
- heat_template_version: <date>
-
- description:
- # a description of the template
-
- parameter_groups:
- # a declaration of input parameter groups and order
-
- parameters:
- # declaration of input parameters
-
- resources:
- # declaration of template resources
-
- outputs:
- # declaration of output parameters
-
- conditions:
- # declaration of conditions
+ heat_template_version: <date>
+
+ description:
+ # a description of the template
+
+ parameter_groups:
+ # a declaration of input parameter groups and order
+
+ parameters:
+ # declaration of input parameters
+
+ resources:
+ # declaration of template resources
+
+ outputs:
+ # declaration of output parameters
+
+ conditions:
+ # declaration of conditions
Heat Orchestration templates for ONAP must contain the following
{network-role} in the context of the VNF. `ONAP Resource ID and Parameter Naming Convention`_ provides additional
details.
-VNFs may use **Cloud assigned IP addresses** or
+VNFs may use **Cloud assigned IP addresses** or
**predetermined static IPs** when attaching VMs to an internal network.
- A Cloud assigned IP address is assigned by OpenStack’s DHCP Service.
metadata:
vm_role: { get_param: vm_role }
-Example
-~~~~~~~~
+Example
+~~~~~~~
The example below depicts part of a Heat Orchestration Template that
uses the five of the OS::Nova::Server metadata parameter discussed in
.. code-block:: python
parameters:
-
+
{vm-type}_{network-role}_ips:
type: comma_delimited_list
description: Fixed IPv4 assignments for {vm-type} VMs on the {Network-role} network
db_oam_floating_ip:
type: string
description: VIP IP for db VMs on the oam network
-
+
resources:
db_0_port_0:
type: OS::Neutron::Port
ONAP defines three types of Output Parameters as detailed in `Output Parameters`_.
-ONAP Base Module Output Parameters:
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ONAP Base Module Output Parameters:
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ONAP Base Module Output Parameters do not have an explicit naming
convention. The parameter name must contain {vm-type} and {network-role}
when appropriate.
-ONAP Volume Template Output Parameters:
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ONAP Volume Template Output Parameters:
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ONAP Base Module Output Parameters do not have an explicit naming
convention. The parameter name must contain {vm-type} when appropriate.
follow specific naming conventions. This section provides these
requirements.
-Contrail Network Parameters
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Contrail Network Parameters
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
Contrail based resources may require references to a Contrail network
using the network FQDN.
virtual_network_refs:
- get_param: oam_protected_net_fqdn
subnet_uuid: { get_param: oam_protected_subnet_id }
-
+
Cinder Volume Templates
-----------------------
scheduler_hints:
group: {get_resource: lb_server_group}
-Resource Data Synchronization
-------------------------------
+Resource Data Synchronization
+-----------------------------
For cases where synchronization is required in the orchestration of Heat
resources, two approaches are recommended:
mountpoint: /dev/vdb
instance_uuid: {get_resource: oam_server_01}
-High Availability
+High Availability
-----------------
VNF/VM parameters may include availability zone IDs for VNFs that
==============================
Aid to help the VNF vendor to fasten the integration with the NFVO via
-Special VNFM, the OpenO provides the documents. In this charter, the
+Special VNFM, the ONAP provides the documents. In this charter, the
develop steps for VNF vendors 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 SVNFM Driver in the OpenO, which
+Second, the VNF vendor should provide SVNFM Driver in the ONAP, which
is a micro service and in duty of translation interface from NFVO to
SVNFM. The interface of NFVO is aligned to the ETSI IFA interfaces and
can be gotten in the charter 5.5. The interface of SVNFM is provided by
d. Create SVNFM Adaptor Mircoservice
=======================================
-Some vnfs are managed by special vnfm, before add svnfm to openo, a
+Some vnfs are managed by special vnfm, before add svnfm to ONAP, a
svnfm adaptor must be added to openo to adapter the interface of nfvo
and svnfm.
]
- }
\ No newline at end of file
+ }
Code Review / vnfrqts / requirements.git / commitdiff