diff options
| -rw-r--r-- | docs/Chapter4.rst | 8 | ||||
| -rw-r--r-- | docs/Chapter5.rst | 106 |
2 files changed, 57 insertions, 57 deletions
diff --git a/docs/Chapter4.rst b/docs/Chapter4.rst index da9f622..2aa951d 100644 --- a/docs/Chapter4.rst +++ b/docs/Chapter4.rst @@ -270,7 +270,7 @@ Integration and operation within a robust security environment is necessary and * 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). @@ -308,7 +308,7 @@ Identity and Access Management Requirements * 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. @@ -504,7 +504,7 @@ Data Protection Requirements d. VNF Modularity ================= -ONAP Heat Orchestration Templates: Overview +ONAP Heat Orchestration Templates: Overview ------------------------------------------- ONAP supports a modular Heat Orchestration Template design pattern, @@ -878,7 +878,7 @@ f. VNF Develop Steps ======================= 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 diff --git a/docs/Chapter5.rst b/docs/Chapter5.rst index 4c2490e..2c37fb2 100644 --- a/docs/Chapter5.rst +++ b/docs/Chapter5.rst @@ -9,8 +9,8 @@ Introduction ------------- 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. @@ -25,26 +25,26 @@ Intended Audience ----------------- 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. @@ -59,7 +59,7 @@ self-defined node or other extensions. 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 @@ -84,7 +84,7 @@ Node Template references a Node Type and adds usage constraints, such as 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 -------------------------------------- @@ -653,7 +653,7 @@ Definition 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 | @@ -770,12 +770,12 @@ Properties +-------------------------------+------------+------------------------------------------+---------------+----------------------------------------------------------+ -| 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 @@ -1578,25 +1578,25 @@ https://docs.openstack.org/developer/heat/template_guide/hot_spec.html. .. 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 @@ -2344,7 +2344,7 @@ When the internal network is created, it should be assigned a unique {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. @@ -3078,8 +3078,8 @@ In this example, the {vm-role} is enumerated in the environment file. 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 @@ -3502,7 +3502,7 @@ The parameter must not be enumerated in the Heat environment file. .. 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 @@ -3844,7 +3844,7 @@ an oam network and the {vm-type} has been defined as db for database. 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 @@ -4086,15 +4086,15 @@ ONAP Output Parameter Names 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. @@ -4225,8 +4225,8 @@ ONAP requires the parameter names of certain Contrail Resources to 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. @@ -4393,7 +4393,7 @@ represent an oam protected network and the {vm-type} has been defined as virtual_network_refs: - get_param: oam_protected_net_fqdn subnet_uuid: { get_param: oam_protected_subnet_id } - + Cinder Volume Templates ----------------------- @@ -4997,8 +4997,8 @@ balancer and db for database. 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: @@ -5067,7 +5067,7 @@ oam server. 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 @@ -5097,14 +5097,14 @@ c. VNFM Driver Develop Steps ============================== 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 @@ -5113,7 +5113,7 @@ the VNF vendor self. 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. @@ -5149,4 +5149,4 @@ POST /openoapi/microservices/v1/services ] - }
\ No newline at end of file + } |