Requirement Changes Introduced in Frankfurt

This document summarizes the requirement changes by section that were introduced between the El Alto release and Frankfurt release. Click on the requirement number to navigate to the

Contents

Summary of Changes

  • Requirements Added: 22

  • Requirements Changed: 129

  • Requirements Removed: 6

Configuration Management

Requirements Added

(R-305645)

The VNF or PNF MUST support configuration management including life cycle management (LCM) using at least one of the following protocols a)NETCONF/YANG, b)Ansible and c)Chef.

Configuration Management > Ansible Standards and Capabilities > VNF or PNF Configuration via Ansible Requirements > Ansible Client Requirements

Requirements Changed

(R-54373)

The VNF or PNF Provider MUST provide Ansible playbooks that are compatible with the Operator’s deployed versions of Ansible and Python. As the Ansible runtime itself is not deployed as part of ONAP, the ONAP project cannot dictate the specific versions supported.

Configuration Management > Ansible Standards and Capabilities > VNF or PNF Configuration via Ansible Requirements > Ansible Playbook Requirements

Requirements Added

(R-09209)

The VNF or PNF Provider MUST store any playbook configuration data that requires encryption (passwords, secrets, etc.) in a JSON (.json), YAML (.yaml|.yml) or INI (.ini) file, which will be placed in <VNF type>/<Version>/ansible/vars directory.

(R-20988)

The VNF or PNF provider MUST develop playbooks that do not log or display passwords and other attributes that must remain secret when running playbook in debug mode.

NOTE: Use “no_log: True”

(R-39003)

The VNF or PNF provider MUST store passwords and other attributes that must remain secret in JSON, YAML or INI files that can be encrypted/decrypted using Ansible Vault capabilities.

(R-42333)

The VNF or PNF playbooks targeting a subset of VMs (or servers/blades) part of a VNF (or PNF) instance MUST be designed to use the VNF or PNF inventory host file and to use a parameter named target_vm_list to provide the subset of VMs in the VNF instance specifically targeted by the playbook.

NOTE: Example of such playbooks would be playbooks used to configure VMs added to a VNF instance as part of a scale-out/up or scale-in/down operation. Such playbook is expected to also need to perform configuration/reconfiguration tasks part of the base VNF instance build.

(R-46823)

The VNF or PNF provider MUST store passwords and other attributes that must remain secret in JSON, YAML or INI with differentiated names when passwords and secrets vary from environment to environment. Example, name must include <Mechanized user ID>_…json or <Mechanized user ID>_…xml when labs and production use different passwords and/or secrets. The <Mechanized user ID> is discovered from the environment /etc/ansible/ansible.cfg where the playbook runs.

(R-53245)

The VNF or PNF provider MUST provide playbooks that do not require passwords or secrets to be passed in clear text in the command line or Rest API request to run the playbook.

(R-56988)

The VNF or PNF Provider MUST load any playbook configuration data that requires encryption (passwords, secrets, etc.) in a JSON (.json), YAML (.yaml|.yml) or INI (.ini) file, from the <VNF type>/<Version>/ansible/vars directory.

(R-78640)

The VNF or PNF provider SHOULD provide a single YAML or JSON file with all the passwords and secrets to reduce the number of files to be decrypted/encrypted before on-boarding into the central repository.

(R-83092)

The VNF or PNF provider MUST develop playbooks that load passwords and other attributes that must remain secret from JSON, YAML or INI files that can be encrypted/decrypted using Ansible Vault capabilities.

(R-88002)

The VNF or PNF provider MUST use a pre-agreed upon password to encrypt the Ansible Vault file, or provide the vault password used to encrypt the file to the customer, in a secure manner, to allow the customer to decrypt/encrypt (rekey) Ansible Vault files before they are checked into the central repository for distribution.

(R-88786)

The VNF or PNF provider SHOULD place the passwords and secrets to be edited at the top of the single YAML or JSON file with all the secrets, and the (default) ones that are to remain unchanged towards the bottom, with commentary separating them.

Requirements Changed

(R-48698)

The VNF or PNF 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 or PNF action. The “extra-vars” attribute-value pairs are passed to the Ansible Server by an APPC/SDN-C as part of the Rest API request. If the playbook requires files, they must also be supplied using the methodology detailed in the Ansible Server API, unless they are bundled with playbooks, example, generic templates. Any files containing instance specific info (attribute-value pairs), not obtainable from any ONAP inventory databases or other sources, referenced and used as input by playbooks, shall be provisioned (and distributed) in advance of use, e.g., VNF or PNF instantiation. Recommendation is to avoid these instance specific, manually created in advance of instantiation, files.

(R-50252)

The VNF or PNF MUST write to a response file in JSON format that will be retrieved and made available by the Ansible Server if, as part of a VNF or PNF action (e.g., audit), a playbook is required to return any VNF or PNF information/response. The text files must be written in the main playbook home directory, in JSON format. The JSON file must be created for the VNF or PNF with the name ‘<VNF or PNF name>_results.txt’. All playbook output results, for all VNF VMS or PNF Server/Blades, to be provided as a response to the request, must be written to this response file.

Configuration Management > NETCONF Standards and Capabilities > VNF or PNF Configuration via NETCONF Requirements > LCM Operations via NETCONF

Requirements Added

(R-246519)

As alternative to Ansible, Chef or REST, a VNF or PNF MAY support YANG models allowing execution of standard controller LCM operations including HealthCheck. Note: To support vendor YANG models for LCM operations, the controller is responsible for performing VNF/PNF specific translation of north-bound API requests into one or more south-bound NETCONF requests.

Configuration Management > NETCONF Standards and Capabilities > VNF or PNF Configuration via NETCONF Requirements > NETCONF Server Requirements

Requirements Changed

(R-73468)

The VNF MUST allow the NETCONF server connection parameters to be configurable during virtual machine instantiation through Heat templates where SSH keys, usernames, passwords, SSH service and SSH port numbers are Heat template parameters.

Contrail Resource Parameters > Contrail Network Parameters > ONAP External Networks

Requirements Changed

(R-02164)

When a VNF’s Heat Orchestration Template’s Contrail resource OS::ContrailV2::InstanceIp and/or OS::ContrailV2::VirtualMachineInterface contains the property virtual_network_refs that references an ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968), the property value MUST be obtained by a get_param and the property parameter

  • MUST follow the format {network-role}_net_fqdn

  • MUST be declared as type string

(R-92193)

A VNF’s Heat Orchestration Template’s Contrail resource OS::ContrailV2::InstanceIp and/or OS::ContrailV2::VirtualMachineInterface property virtual_network_refs parameter {network-role}_net_fqdn MUST NOT be enumerated in the VNF’s Heat Orchestration Template’s Environment File.

Contrail Resource Parameters > OS::ContrailV2::VirtualMachineInterface Property virtual_machine_interface_allowed_address_pairs > ONAP External Networks

Requirements Changed

(R-100350)

When the VNF’s Heat Orchestration Template’s resource OS::ContrailV2::VirtualMachineInterface is attaching to an ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968), and the IPv4 VIP address and/or IPv6 VIP address is not supported by the ONAP data model, the map property

virtual_machine_interface_allowed_address_pairs,

virtual_machine_interface_allowed_address_pairs_allowed_address_pair,

virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip,

virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix

  • Parameter name MAY use any naming convention. That is, there is no ONAP mandatory parameter naming convention.

  • Parameter MAY be declared as type string or type comma_delimited_list.

And the OS::ContrailV2::VirtualMachineInterface resource MUST contain resource-level metadata (not property-level).

And the metadata format MUST must contain the key value aap_exempt with a list of all map property

virtual_machine_interface_allowed_address_pairs,

virtual_machine_interface_allowed_address_pairs_allowed_address_pair,

virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip,

virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix

parameters not supported by the ONAP data model.

(R-100310)

When the VNF’s Heat Orchestration Template’s resource OS::ContrailV2::VirtualMachineInterface is attaching to an ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968), and an IPv4 Virtual IP (VIP) is required to be supported by the ONAP data model, the map property

virtual_machine_interface_allowed_address_pairs,

virtual_machine_interface_allowed_address_pairs_allowed_address_pair,

virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip,

virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix

parameter name MUST follow the naming convention

  • {vm-type}_{network-role}_floating_ip

where

  • {vm-type} is the {vm-type} associated with the OS::Nova::Server

  • {network-role} is the {network-role} of the ONAP external network

And the parameter MUST be declared as type string.

The ONAP data model can only support one IPv4 VIP address.

(R-100330)

When the VNF’s Heat Orchestration Template’s resource OS::ContrailV2::VirtualMachineInterface is attaching to an ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968), and an IPv6 Virtual IP (VIP) is required to be supported by the ONAP data model, the map property

virtual_machine_interface_allowed_address_pairs,

virtual_machine_interface_allowed_address_pairs_allowed_address_pair,

virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip,

virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix

parameter name MUST follow the naming convention

  • {vm-type}_{network-role}_floating_v6_ip

where

  • {vm-type} is the {vm-type} associated with the OS::Nova::Server

  • {network-role} is the {network-role} of the ONAP external network

And the parameter MUST be declared as type string.

The ONAP data model can only support one IPv6 VIP address.

(R-100280)

If a VNF’s Heat Orchestration Template’s resource OS::ContrailV2::VirtualMachineInterface is attaching to an ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968), the map property

virtual_machine_interface_allowed_address_pairs,

virtual_machine_interface_allowed_address_pairs_allowed_address_pair,

virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip,

virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix

parameter MUST NOT be enumerated in the VNF’s Heat Orchestration Template’s Environment File.

Contrail Resource Parameters > OS::ContrailV2::VirtualMachineInterface Property virtual_machine_interface_allowed_address_pairs > ONAP Internal Networks

Requirements Changed

(R-100360)

When the VNF’s Heat Orchestration Template’s Resource OS::ContrailV2::VirtualMachineInterface is attaching to an ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666), and an IPv4 Virtual IP (VIP) address is assigned using the map property, virtual_machine_interface_allowed_address_pairs, virtual_machine_interface_allowed_address_pairs_allowed_address_pair, virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip, virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix , the parameter name MUST follow the naming convention

  • {vm-type}_int_{network-role}_floating_ip

where

  • {vm-type} is the {vm-type} associated with the OS::Nova::Server

  • {network-role} is the {network-role} of the ONAP internal network

And the parameter MUST be declared as type: string and MUST be enumerated in the environment file.

OR

the parameter name MUST follow the naming convention

  • {vm-type}_int_{network-role}_floating_ips

where

  • {vm-type} is the {vm-type} associated with the OS::Nova::Server

  • {network-role} is the {network-role} of the ONAP internal network

And the parameter MUST be declared as type: comma_delimited_list and MUST be enumerated in the environment file.

(R-100370)

When the VNF’s Heat Orchestration Template’s Resource OS::ContrailV2::VirtualMachineInterface is attaching to an ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666), and an IPv6 Virtual IP (VIP) address is assigned using the map property, virtual_machine_interface_allowed_address_pairs, virtual_machine_interface_allowed_address_pairs_allowed_address_pair, virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip, virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix , the parameter name MUST follow the naming convention

  • {vm-type}_int_{network-role}_floating_v6_ip

where

  • {vm-type} is the {vm-type} associated with the OS::Nova::Server

  • {network-role} is the {network-role} of the ONAP internal network

And the parameter MUST be declared as type: string and MUST be enumerated in the environment file

OR

the parameter name MUST follow the naming convention

  • {vm-type}_int_{network-role}_floating_v6_ips

where

  • {vm-type} is the {vm-type} associated with the OS::Nova::Server

  • {network-role} is the {network-role} of the ONAP internal network

And the parameter MUST be declared as type: comma_delimited_list and MUST be enumerated in the environment file.

Contrail Resource Parameters > Resource OS::ContrailV2::InstanceIp > Resource OS::ContrailV2::InstanceIp Property instance_ip_address

Requirements Changed

(R-100150)

When the VNF’s Heat Orchestration Template’s Resource OS::ContrailV2::InstanceIp is assigning an IP address to an ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666), and an IPv6 address is assigned using the property instance_ip_address and the parameter type is defined as a comma_delimited_list, the parameter name MUST follow the naming convention

  • {vm-type}_int_{network-role}_v6_ips

where

  • {vm-type} is the {vm-type} associated with the OS::Nova::Server

  • {network-role} is the {network-role} of the ONAP internal network

(R-100010)

When the VNF’s Heat Orchestration Template’s Resource OS::ContrailV2::InstanceIp is assigning an IP address to an ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968), and an IPv4 address is assigned using the property instance_ip_address and the parameter type is defined as a string, the parameter name MUST follow the naming convention

  • {vm-type}_{network-role}_ip_{index}

where

  • {vm-type} is the {vm-type} associated with the OS::Nova::Server

  • {network-role} is the {network-role} of the ONAP external network

  • {index} is a numeric value that MUST start at zero in a VNF’s Heat Orchestration Template and MUST increment by one

(R-100110)

When the VNF’s Heat Orchestration Template’s Resource OS::ContrailV2::InstanceIp is assigning an IP address to an ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666), and an IPv4 address is assigned using the property instance_ip_address and the parameter type is defined as a comma_delimited_list, the parameter name MUST follow the naming convention

  • {vm-type}_int_{network-role}_ips

where

  • {vm-type} is the {vm-type} associated with the OS::Nova::Server

  • {network-role} is the {network-role} of the ONAP internal network

(R-100050)

When the VNF’s Heat Orchestration Template’s Resource OS::ContrailV2::InstanceIp is assigning an IP address to an ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968), and an IPv6 address is assigned using the property instance_ip_address and the parameter type is defined as a string, the parameter name MUST follow the naming convention

  • {vm-type}_{network-role}_v6_ip_{index}

where

  • {vm-type} is the {vm-type} associated with the OS::Nova::Server

  • {network-role} is the {network-role} of the ONAP external network

  • {index} is a numeric value that MUST start at zero in a VNF’s Heat Orchestration Template and MUST increment by one

(R-100030)

When the VNF’s Heat Orchestration Template’s Resource OS::ContrailV2::InstanceIp is assigning an IP address to an ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968), and an IPv4 address is assigned using the property instance_ip_address and the parameter type is defined as a comma_delimited_list, the parameter name MUST follow the naming convention

  • {vm-type}_{network-role}_ips

where

  • {vm-type} is the {vm-type} associated with the OS::Nova::Server

  • {network-role} is the {network-role} of the ONAP external network

(R-100090)

When the VNF’s Heat Orchestration Template’s Resource OS::ContrailV2::InstanceIp is assigning an IP address to an ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666), and an IPv4 address is assigned using the property instance_ip_address and the parameter type is defined as a string, the parameter name MUST follow the naming convention

  • {vm-type}_int_{network-role}_ip_{index}

where

  • {vm-type} is the {vm-type} associated with the OS::Nova::Server

  • {network-role} is the {network-role} of the ONAP internal network

  • {index} is a numeric value that MUST start at zero in a VNF’s Heat Orchestration Template and MUST increment by one

(R-100170)

The VNF’s Heat Orchestration Template’s Resource OS::ContrailV2::InstanceIp property instance_ip_address parameter associated with an ONAP external network, i.e.,

  • {vm-type}_{network-role}_ip_{index}

  • {vm-type}_{network-role}_v6_ip_{index}

  • {vm-type}_{network-role}_ips

  • {vm-type}_{network-role}_v6_ips

MUST NOT be enumerated in the Heat Orchestration Template’s Environment File. ONAP provides the IP address assignments at orchestration time.

(R-100070)

When the VNF’s Heat Orchestration Template’s Resource OS::ContrailV2::InstanceIp is assigning an IP address to an ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968), and an IPv6 address is assigned using the property instance_ip_address and the parameter type is defined as a comma_delimited_list, the parameter name MUST follow the naming convention

  • {vm-type}_{network-role}_v6_ips

where

  • {vm-type} is the {vm-type} associated with the OS::Nova::Server

  • {network-role} is the {network-role} of the ONAP external network

(R-100130)

When the VNF’s Heat Orchestration Template’s Resource OS::ContrailV2::InstanceIp is assigning an IP address to an ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666), and an IPv6 address is assigned using the property instance_ip_address and the parameter type is defined as a string, the parameter name MUST follow the naming convention

  • {vm-type}_int_{network-role}_v6_ip_{index}

where

  • {vm-type} is the {vm-type} associated with the OS::Nova::Server

  • {network-role} is the {network-role} of the ONAP internal network

  • {index} is a numeric value that MUST start at zero in a VNF’s Heat Orchestration Template and MUST increment by one

(R-100180)

The VNF’s Heat Orchestration Template’s Resource OS::ContrailV2::InstanceIp property instance_ip_address parameter associated with an ONAP internal network, i.e.,

  • {vm-type}_int_{network-role}_ip_{index}

  • {vm-type}_int_{network-role}_v6_ip_{index}

  • {vm-type}_int_{network-role}_ips

  • {vm-type}_int_{network-role}_v6_ips

MUST be enumerated in the Heat Orchestration Template’s Environment File and IP addresses MUST be assigned.

Contrail Resource Parameters > Resource OS::ContrailV2::InstanceIp > Resource OS::ContrailV2::InstanceIp Property subnet_uuid

Requirements Changed

(R-100220)

When the VNF’s Heat Orchestration Template’s resource OS::ContrailV2::InstanceIp is assigning an IP address to an ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968), and an IPv6 address is being cloud assigned by OpenStack’s DHCP Service and the ONAP external network IPv6 subnet is to be specified using the property subnet_uuid, the parameter MUST follow the naming convention

  • {network-role}_v6_subnet_id

where

  • {network-role} is the network role of the ONAP external network.

(R-100200)

When the VNF’s Heat Orchestration Template’s resource OS::ContrailV2::InstanceIp is assigning an IP address to an ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968), and an IPv4 address is being cloud assigned by OpenStack’s DHCP Service and the ONAP external network IPv4 subnet is to be specified using the property subnet_uuid, the parameter MUST follow the naming convention

  • {network-role}_subnet_id

where

  • {network-role} is the network role of the ONAP external network.

(R-100260)

When

  • the VNF’s Heat Orchestration Template’s resource OS::ContrailV2::InstanceIp in an Incremental Module is attaching to an ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666) that is created in the Base Module, AND

  • an IPv6 address is being cloud assigned by OpenStack’s DHCP Service AND

  • the ONAP internal network IPv6 subnet is to be specified using the property subnet_uuid,

the parameter MUST follow the naming convention

  • int_{network-role}_v6_subnet_id

where {network-role} is the network role of the ONAP internal network.

Note that the parameter MUST be defined as an output parameter in the base module.

(R-100240)

When

  • the VNF’s Heat Orchestration Template’s resource OS::ContrailV2::InstanceIp in an Incremental Module is assigning an IP address to an ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666) that is created in the Base Module, AND

  • an IPv4 address is being cloud assigned by OpenStack’s DHCP Service AND

  • the ONAP internal network IPv4 subnet is to be specified using the property subnet_uuid,

the parameter MUST follow the naming convention

  • int_{network-role}_subnet_id

where

  • {network-role} is the network role of the ONAP internal network

Note that the parameter MUST be defined as an output parameter in the base module.

Monitoring & Management > Data Structure Specification of the Event Record

Requirements Changed

(R-570134)

The events produced by the VNF or PNF MUST be compliant with the common event formats defined in either the VES Event Listener 7.1.1 or VES Event Listener 5.4.1 specifications. Version 7.1.1 should be preferred, and VES 5.4.1 is only provided for backwards compatibility.

ONAP Heat Heat Template Constructs > Nested Heat Templates > Nested Heat Template Requirements

Requirements Changed

(R-17528)

A VNF’s Heat Orchestration Template’s first level Nested YAML file MUST NOT contain more than one OS::Nova::Server resource. A VNF’s Heat Orchestration Template’s second level Nested YAML file MUST NOT contain any heat resources.

ONAP Heat Networking > External Networks

Requirements Changed

(R-00606)

A VNF MAY be connected to zero, one or more than one ONAP external network.

(R-57424)

A VNF’s port connected to an ONAP external network MAY use the port for the purpose of

  • Connecting a VM in the VNF to VMs in another VNF and/or

  • Connecting a VM in the VNF to an external gateway or external router and/or

  • Connecting a VM in the VNF to other VMs in the same VNF

(R-99794)

An ONAP external network MUST have one subnet. An external network MAY have more than one subnet.

(R-16968)

A VNF’s Heat Orchestration Templates MUST NOT include heat resources to create an ONAP external network.

An ONAP external network MUST be instantiated by using VID or by invoking SO directly.

ONAP Heat Networking > Internal Networks

Requirements Changed

(R-35666)

If a VNF has an ONAP internal network, the VNF’s Heat Orchestration Template MUST include the heat resources to create the ONAP internal network.

A VNF’s ONAP internal network is created using Neutron Heat Resources (e.g., OS::Neutron::Net, OS::Neutron::Subnet, OS::Neutron::ProviderNet) and/or Contrail Heat Resources (e.g., OS::ContrailV2::VirtualNetwork, OS::ContrailV2::NetworkIpam).

(R-46461)

A VNF’s port connected to an ONAP internal network MUST NOT use the port for the purpose of reaching VMs in another VNF and/or an external gateway and/or external router.

(R-16241)

A VNF’s ONAP internal network MUST have one subnet. A VNF’s ONAP internal network MAY have more than one subnet.

(R-86972)

A VNF SHOULD create the ONAP internal network in the VNF’s Heat Orchestration Template’s Base Module.

(R-52425)

A VNF’s port connected to an ONAP internal network MUST use the port for the purpose of reaching VMs in the same VNF.

(R-22688)

When a VNF’s Heat Orchestration Template creates an ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666) and the ONAP internal network needs to be shared between modules within a VNF, the ONAP internal network MUST be created either in the

  • the base module

  • a nested YAML file invoked by the base module

and the base module MUST contain an output parameter that provides either the network UUID or network name.

  • If the network UUID value is used to reference the network, the output parameter name in the base module MUST follow the naming convention int_{network-role}_net_id

  • If the network name in is used to reference the network, the output parameter name in the base template MUST follow the naming convention int_{network-role}_net_name

The {network-role} MUST be the network-role of the ONAP internal network created in the Base Module.

The Base Module Output Parameter MUST be declared in the parameters: section of the Incremental Module(s) where the OS::Neutron::Port resource(s) is attaching to the ONAP internal network.

(R-87096)

A VNF MAY contain zero, one or more than one ONAP internal network.

ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > parameters

Requirements Added

R-35413

A VNF Heat Orchestration’s template’s base module MAY (or MAY NOT) contain the section parameters:.

Requirements Changed

(R-35414)

A VNF Heat Orchestration’s template’s incremental module and volume module MUST contain the section parameters:.

(R-90279)

A VNF Heat Orchestration’s template’s parameter MUST be used

  • in a resource AND/OR

  • in a output parameter (in the outputs section)

with the exception of the parameters for the OS::Nova::Server resource property availability_zone.

ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > resources

Requirements Added

(R-23663)

A VNF’s Heat Orchestration template’s base module MAY (or MAY NOT) contain the section resources:.

Requirements Changed

(R-23664)

A VNF’s Heat Orchestration template’s incremental module and volume module MUST contain the section resources:.

Resource IDs

Requirements Changed

(R-82551)

When a VNF’s Heat Orchestration Template’s resource is associated with a single {vm-type} and a single ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666), the Resource ID MUST contain both the {vm-type} and the int_{network-role} and

  • the {vm-type} MUST appear before the int_{network-role} and MUST be separated by an underscore ‘_’

    • (e.g., {vm-type}_int_{network-role}, {vm-type}_{index}_int_{network-role})

  • note that an {index} value MAY separate the {vm-type} and the int_{network-role} and when this occurs underscores MUST separate the three values. (e.g., {vm-type}_{index}_int_{network-role}).

(R-27970)

When a VNF’s Heat Orchestration Template’s resource is associated with more than one {vm-type} and/or more than one ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666) and/or ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968), the Resource ID MAY contain the term shared and/or MAY contain text that identifies the VNF.

(R-67793)

When a VNF’s Heat Orchestration Template’s resource is associated with more than one {vm-type} and/or more than one ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666) and/or ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968), the Resource ID MUST NOT contain the {vm-type} and/or {network-role}/int_{network-role}.

(R-82115)

When a VNF’s Heat Orchestration Template’s resource is associated with a single {vm-type} and a single ONAP external network, the Resource ID text MUST contain both the {vm-type} and the {network-role}

  • the {vm-type} MUST appear before the {network-role} and MUST be separated by an underscore ‘_’

    • e.g., {vm-type}_{network-role}, {vm-type}_{index}_{network-role}

  • note that an {index} value MAY separate the {vm-type} and the {network-role} and when this occurs underscores MUST separate the three values. (e.g., {vm-type}_{index}_{network-role}).

(R-98138)

When a VNF’s Heat Orchestration Template’s resource is associated with a single ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666), the Resource ID MUST contain the text int_{network-role}.

(R-96482)

When a VNF’s Heat Orchestration Template’s resource is associated with a single ONAP external network, the Resource ID MUST contain the text {network-role}.

Resource IDs > Contrail Heat Resources Resource ID Naming Convention > OS::ContrailV2::InstanceIp

Requirements Changed

(R-62187)

A VNF’s Heat Orchestration Template’s Resource OS::ContrailV2::InstanceIp Resource ID that is configuring an IPv4 Address on a virtual machine interface (i.e., OS::ContrailV2::VirtualMachineInterface) attached to an ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666) MUST use the naming convention

  • {vm-type}_{vm-type_index}_int_{network-role}_vmi_{vmi_index}_IP_{index}

where

  • {vm-type} is the vm-type

  • {vm-type_index} references the instance of the {vm-type} in the VNF. The {vm-type_index} is a numeric value that MUST start at zero in the VNF and MUST increment by one each time a new instance of a {vm-type} is referenced.

  • {network-role} is the network-role of the ONAP internal network that the port is attached to

  • {vmi_index} references the instance of the virtual machine interface on the {vm-type} attached to {network-role} network. The {vmi_index} is a numeric value that MUST start at zero on an instance of a {vm-type} and MUST increment by one each time a new virtual machine interface is defined on the instance of the {vm-type} attached to {network-role} network.

  • IP signifies that an IPv4 address is being configured

  • {index} references the instance of the IPv4 address configured on the virtual machine interface. The {index} is a numeric value that MUST start at zero on an instance of a virtual machine interface and MUST increment by one each time a new IPv4 address is configured on the virtual machine interface.

(R-87563)

A VNF’s Heat Orchestration Template’s Resource OS::ContrailV2::InstanceIp Resource ID that is configuring an IPv6 Address on a virtual machine interface (i.e., OS::ContrailV2::VirtualMachineInterface) attached to an ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666) MUST use the naming convention

  • {vm-type}_{vm-type_index}_int_{network-role}_vmi_{vmi_index}_v6_IP_{index}

where

  • {vm-type} is the vm-type

  • {vm-type_index} references the instance of the {vm-type} in the VNF. The {vm-type_index} is a numeric value that MUST start at zero in the VNF and MUST increment by one each time a new instance of a {vm-type} is referenced.

  • {network-role} is the network-role of the ONAP internal network that the port is attached to

  • {vmi_index} references the instance of the virtual machine interface on the {vm-type} attached to {network-role} network. The {vmi_index} is a numeric value that MUST start at zero on an instance of a {vm-type} and MUST increment by one each time a new virtual machine interface is defined on the instance of the {vm-type} attached to {network-role} network.

  • v6_IP signifies that an IPv6 address is being configured

  • {index} references the instance of the IPv6 address configured on the virtual machine interface. The {index} is a numeric value that MUST start at zero on an instance of a virtual machine interface and MUST increment by one each time a new IPv6 address is configured on the virtual machine interface.

(R-53310)

A VNF’s Heat Orchestration Template’s Resource OS::ContrailV2::InstanceIp Resource ID that is configuring an IPv4 Address on a virtual machine interface (i.e., OS::ContrailV2::VirtualMachineInterface) attached to an ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968) MUST use the naming convention

  • {vm-type}_{vm-type_index}_{network-role}_vmi_{vmi_index}_IP_{index}

where

  • {vm-type} is the vm-type

  • {vm-type_index} references the instance of the {vm-type} in the VNF. The {vm-type_index} is a numeric value that MUST start at zero in the VNF and MUST increment by one each time a new instance of a {vm-type} is referenced.

  • {network-role} is the network-role of the ONAP external network that the virtual machine interface is attached to

  • {vmi_index} references the instance of the virtual machine interface on the {vm-type} attached to {network-role} network. The {vmi_index} is a numeric value that MUST start at zero on an instance of a {vm-type} and MUST increment by one each time a new virtual machine interface is defined on the instance of the {vm-type} attached to {network-role} network.

  • IP signifies that an IPv4 address is being configured

  • {index} references the instance of the IPv4 address configured on the virtual machine interface. The {index} is a numeric value that MUST start at zero on an instance of a virtual machine interface and MUST increment by one each time a new IPv4 address is configured on the virtual machine interface.

(R-46128)

A VNF’s Heat Orchestration Template’s Resource OS::ContrailV2::InstanceIp Resource ID that is configuring an IPv6 Address on a virtual machine interface (i.e., OS::ContrailV2::VirtualMachineInterface) attached to an ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968) MUST use the naming convention

  • {vm-type}_{vm-type_index}_{network-role}_vmi_{vmi_index}_v6_IP_{index}

where

  • {vm-type} is the vm-type

  • {vm-type_index} references the instance of the {vm-type} in the VNF. The {vm-type_index} is a numeric value that MUST start at zero in the VNF and MUST increment by one each time a new instance of a {vm-type} is referenced.

  • {network-role} is the network-role of the ONAP external network that the port is attached to

  • {vmi_index} references the instance of the virtual machine interface on the {vm-type} attached to {network-role} network. The {vmi_index} is a numeric value that MUST start at zero on an instance of a {vm-type} and MUST increment by one each time a new virtual machine interface is defined on the instance of the {vm-type} attached to {network-role} network.

  • v6_IP signifies that an IPv6 address is being configured

  • {index} references the instance of the IPv6 address configured on the virtual machine interface. The {index} is a numeric value that MUST start at zero on an instance of a virtual machine interface and MUST increment by one each time a new IPv6 address is configured on the virtual machine interface.

Resource IDs > Contrail Heat Resources Resource ID Naming Convention > OS::ContrailV2::NetworkIpam

Requirements Changed

(R-30753)

A VNF’s Heat Orchestration Template’s Resource OS::ContrailV2::NetworkIpam Resource ID MUST contain the {network-role} of the ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666) that the resource is associated with.

Resource IDs > Contrail Heat Resources Resource ID Naming Convention > OS::ContrailV2::VirtualMachineInterface

Requirements Changed

(R-50468)

A VNF’s Heat Orchestration Template’s Resource OS::ContrailV2::VirtualMachineInterface Resource ID that is attaching to an ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666) MUST use the naming convention

  • {vm-type}_{vm-type_index}_int_{network-role}_vmi_{vmi_index}

where

  • {vm-type} is the vm-type

  • {vm-type_index} references the instance of the {vm-type} in the VNF. The {vm-type_index} is a numeric value that MUST start at zero in the VNF and MUST increment by one each time a new instance of a {vm-type} is referenced.

  • {network-role} is the network-role of the ONAP internal network that the port (i.e. virtual machine interface) is attached to

  • {vmi_index} references the instance of the virtual machine interface on the {vm-type} attached to {network-role} network. The {vmi_index} is a numeric value that MUST start at zero on an instance of a {vm-type} and MUST increment by one each time a new virtual machine interface is defined on the instance of the {vm-type} attached to {network-role} network.

(R-96253)

A VNF’s Heat Orchestration Template’s Resource OS::ContrailV2::VirtualMachineInterface Resource ID that is attaching to an ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968) MUST use the naming convention

  • {vm-type}_{vm-type_index}_{network-role}_vmi_{vmi_index}

where

  • {vm-type} is the vm-type

  • {vm-type_index} references the instance of the {vm-type} in the VNF. The {vm-type_index} is a numeric value that MUST start at zero in the VNF and MUST increment by one each time a new instance of a {vm-type} is referenced.

  • {network-role} is the network-role of the ONAP external network that the port (i.e. virtual machine interface) is attached to

  • {vmi_index} references the instance of the virtual machine interface on the {vm-type} attached to {network-role} network. The {vmi_index} is a numeric value that MUST start at zero on an instance of a {vm-type} and MUST increment by one each time a new virtual machine interface is defined on the instance of the {vm-type} attached to {network-role} network.

Resource IDs > Contrail Heat Resources Resource ID Naming Convention > OS::ContrailV2::VirtualNetwork

Requirements Changed

(R-99110)

A VNF’s Heat Orchestration Template’s Resource OS::ContrailV2::VirtualNetwork Resource ID MUST use the naming convention

  • int_{network-role}_network

VNF Heat Orchestration Templates can only create ONAP internal networks (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666). There is no {index} after {network-role} because {network-role} MUST be unique in the scope of the VNF’s Heat Orchestration Template.

Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Neutron::Net

Requirements Changed

(R-25720)

A VNF’s Heat Orchestration Template’s Resource OS::Neutron::Net Resource ID MUST use the naming convention

  • int_{network-role}_network

VNF Heat Orchestration Templates can only create ONAP internal networks (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666). There is no {index} after {network-role} because {network-role} MUST be unique in the scope of the VNF’s Heat Orchestration Template.

Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Neutron::Port

Requirements Changed

(R-20453)

A VNF’s Heat Orchestration Template’s Resource OS::Neutron::Port that is attaching to an ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968), the OS::Neutron::Port Resource ID MUST use the naming convention

  • {vm-type}_{vm-type_index}_{network-role}_port_{port-index}

where

  • {vm-type} is the vm-type

  • {vm-type_index} references the instance of the {vm-type} in the VNF. The {vm-type_index} is a numeric value that MUST start at zero in the VNF and MUST increment by one each time a new instance of a {vm-type} is referenced.

  • {network-role} is the network-role of the ONAP external network that the port is attached to

  • {port_index} references the instance of the port on the {vm-type} attached to {network-role} network. The {port_index} is a numeric value that MUST start at zero on an instance of a {vm-type} and MUST increment by one each time a new port is defined on the instance of the {vm-type} attached to {network-role} network.

(R-68520)

A VNF’s Heat Orchestration Template’s Resource OS::Neutron::Port that is creating a Reserve Port with an IPv6 address, the OS::Neutron::Port Resource ID SHOULD use the naming convention

  • reserve_port_{vm-type}_{network-role}_floating_v6_ip_{index}

where

  • {vm-type} is the vm-type

  • {network-role} is the network-role of the ONAP external network that the port is attached to

  • {index} is the instance of the IPv6 Reserve Port for the vm-type attached to the network of {network-role}. The {index} starts at zero and increments by one (as described in R-11690).

(R-26351)

A VNF’s Heat Orchestration Template’s Resource OS::Neutron::Port that is attaching to an ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666), the OS::Neutron::Port Resource ID MUST use the naming convention

  • {vm-type}_{vm-type_index}_int_{network-role}_port_{port-index}

where

  • {vm-type} is the vm-type

  • {vm-type_index} references the instance of the {vm-type} in the VNF. The {vm-type_index} is a numeric value that MUST start at zero in the VNF and MUST increment by one each time a new instance of a {vm-type} is referenced.

  • {network-role} is the network-role of the ONAP internal network that the port is attached to

  • {port_index} references the instance of the port on the {vm-type} attached to {network-role} network. The {port_index} is a numeric value that MUST start at zero on an instance of a {vm-type} and MUST increment by one each time a new port is defined on the instance of the {vm-type} attached to {network-role} network.

(R-27469)

A VNF’s Heat Orchestration Template’s Resource OS::Neutron::Port that is creating a Reserve Port with an IPv4 address, the OS::Neutron::Port Resource ID SHOULD use the naming convention

  • reserve_port_{vm-type}_{network-role}_floating_ip_{index}

where

  • {vm-type} is the vm-type

  • {network-role} is the network-role of the ONAP external network that the port is attached to

  • {index} is the instance of the IPv4 Reserve Port for the vm-type attached to the network of {network-role}. The {index} starts at zero and increments by one (as described in R-11690).

Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Neutron::SecurityGroup

Requirements Changed

(R-17334)

A VNF’s Heat Orchestration Template’s Resource OS::Neutron::SecurityGroup that is applicable to one {vm-type} and one ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968), the OS::Neutron::SecurityGroup Resource ID SHOULD use the naming convention

  • {vm-type}_{network-role}_security_group

where

  • {vm-type} is the vm-type

  • {network-role} is the network-role of the ONAP external network

(R-08775)

A VNF’s Heat Orchestration Template’s Resource OS::Neutron::SecurityGroup that is applicable to one {vm-type} and more than one network (ONAP internal network and/or ONAP external network), the OS::Neutron::SecurityGroup Resource ID SHOULD use the naming convention

  • {vm-type}_security_group

where

  • {vm-type} is the vm-type

(R-03595)

A VNF’s Heat Orchestration Template’s Resource OS::Neutron::SecurityGroup that is applicable to more than one {vm-type} and one ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968), the OS::Neutron::SecurityGroup Resource ID SHOULD use the naming convention

  • {network-role}_security_group

where

  • {network-role} is the network-role of the ONAP external network

(R-14198)

A VNF’s Heat Orchestration Template’s Resource OS::Neutron::SecurityGroup that is applicable to one {vm-type} and one ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666), the OS::Neutron::SecurityGroup Resource ID SHOULD use the naming convention

  • {vm-type}_int_{network-role}_security_group

where

  • {vm-type} is the vm-type

  • {network-role} is the network-role of the ONAP internal network

(R-30005)

A VNF’s Heat Orchestration Template’s Resource OS::Neutron::SecurityGroup that is applicable to more than one {vm-type} and more than one network (internal and/or external), the OS::Neutron::SecurityGroup Resource ID MAY use the naming convention

  • shared_security_group

or

  • {vnf-type}_security_group

where

  • {vnf-type} describes the VNF

(R-73213)

A VNF’s Heat Orchestration Template’s Resource OS::Neutron::SecurityGroup that is applicable to more than one {vm-type} and one ONAP internal network, (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666), the OS::Neutron::SecurityGroup Resource ID SHOULD use the naming convention

  • int_{network-role}_security_group

where

  • {network-role} is the network-role of the ONAP internal network

Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Neutron::Subnet

Requirements Changed

(R-59434)

A VNF’s Heat Orchestration Template’s Resource OS::Neutron::Subnet Resource ID SHOULD use the naming convention

  • int_{network-role}_subnet_{index}

where

  • {network-role} is the network-role of the ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666).

  • {index} is the {index} of the subnet of the ONAP internal network. The {index} starts at zero and increments by one (as described in R-11690).

Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Nova::Keypair

Requirements Changed

(R-24997)

A VNF’s Heat Orchestration Template’s Resource OS::Nova::Keypair that applies to one {vm-type}, the OS::Nova::Keypair Resource ID SHOULD use the naming convention

  • {vm-type}_keypair_{index}

where

  • {vm-type} is the vm-type of the OS::Nova::Server

  • {index} is the {index} of the keypair. The {index} starts at zero and increments by one (as described in R-11690).

(R-65516)

A VNF’s Heat Orchestration Template’s Resource OS::Nova::Keypair that applies to all Virtual Machines in the VNF, the OS::Nova::Keypair Resource ID SHOULD use the naming convention

  • {vnf-type}_keypair

where

  • {vnf-type} describes the VNF

Resource: OS::Neutron::Port - Parameters > Introduction > Items to Note

Requirements Changed

(R-18001)

If the VNF’s ports connected to a unique ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666) and the port’s IP addresses are statically assigned IP addresses, the IPv4 addresses MAY be from different subnets and the IPv6 addresses MAY be from different subnets.

(R-63956)

If the VNF’s ports connected to a unique ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968) and the port’s IP addresses are ONAP SDN-C assigned IP addresses, the IPv4 addresses MAY be from different subnets and the IPv6 addresses MAY be from different subnets.

(R-48880)

If a VNF’s Port is attached to an ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968) and the port’s IP addresses are assigned by ONAP’s SDN-Controller, the OS::Neutron::Port Resource’s

  • property fixed_ips map property ip_address MUST be used

  • property fixed_ips map property subnet MUST NOT be used

(R-70964)

If a VNF’s Port is attached to an ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666) and the port’s IP addresses are statically assigned by the VNF’s Heat Orchestration Template (i.e., enumerated in the Heat Orchestration Template’s environment file), the OS::Neutron::Port Resource’s

  • property fixed_ips map property ip_address MUST be used

  • property fixed_ips map property subnet MUST NOT be used

Resource: OS::Neutron::Port - Parameters > Property: allowed_address_pairs, Map Property: ip_address > VIP Assignment, ONAP External Networks

Requirements Changed

(R-41492)

When the VNF’s Heat Orchestration Template’s resource OS::Neutron::Port is attaching to an ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968), and the IPv4 VIP is required to be supported by the ONAP data model, the property allowed_address_pairs map property ip_address parameter name MUST follow the naming convention

  • {vm-type}_{network-role}_floating_ip

where

  • {vm-type} is the {vm-type} associated with the OS::Nova::Server

  • {network-role} is the {network-role} of the ONAP external network

And the parameter MUST be declared as type string.

As noted in the introduction to this section, the ONAP data model can only support one IPv4 VIP address.

(R-83412)

If a VNF’s Heat Orchestration Template’s resource OS::Neutron::Port is attaching to an ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968), the property allowed_address_pairs map property ip_address parameter(s) MUST NOT be enumerated in the VNF’s Heat Orchestration Template’s Environment File.

(R-41493)

When the VNF’s Heat Orchestration Template’s resource OS::Neutron::Port is attaching to an ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968), and the IPv4 VIP address and/or IPv6 VIP address is not supported by the ONAP data model, the property allowed_address_pairs map property ip_address

  • Parameter name MAY use any naming convention. That is, there is no ONAP mandatory parameter naming convention.

  • Parameter MAY be declared as type string or type

comma_delimited_list.

And the OS::Neutron::Port resource MUST contain resource-level metadata (not property-level).

And the metadata format MUST must contain the key value aap_exempt with a list of all allowed_address_pairs map property ip_address parameters not supported by the ONAP data model.

(R-35735)

When the VNF’s Heat Orchestration Template’s resource OS::Neutron::Port is attaching to an ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968), and the IPv6 VIP is required to be supported by the ONAP data model, the property allowed_address_pairs map property ip_address parameter name MUST follow the naming convention

  • {vm-type}_{network-role}_floating_v6_ip

where

  • {vm-type} is the {vm-type} associated with the OS::Nova::Server

  • {network-role} is the {network-role} of the ONAP external network

And the parameter MUST be declared as type string.

As noted in the introduction to this section, the ONAP data model can only support one IPv6 VIP address.

Resource: OS::Neutron::Port - Parameters > Property: allowed_address_pairs, Map Property: ip_address > VIP Assignment, ONAP Internal Networks

Requirements Changed

(R-717227)

When the VNF’s Heat Orchestration Template’s Resource OS::Neutron::Port is attaching to an ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666), and an IPv4 Virtual IP (VIP) address is assigned using the property allowed_address_pairs map property ip_address, the parameter name MUST follow the naming convention

  • {vm-type}_int_{network-role}_floating_ip

where

  • {vm-type} is the {vm-type} associated with the OS::Nova::Server

  • {network-role} is the {network-role} of the ONAP internal network

And the parameter MUST be declared as type: string and MUST be enumerated in the environment file.

OR

the parameter name MUST follow the naming convention

  • {vm-type}_int_{network-role}_floating_ips

where

  • {vm-type} is the {vm-type} associated with the OS::Nova::Server

  • {network-role} is the {network-role} of the ONAP internal network

And the parameter MUST be declared as type: comma_delimited_list and MUST be enumerated in the environment file.

(R-805572)

When the VNF’s Heat Orchestration Template’s Resource OS::Neutron::Port is attaching to an ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666), and an IPv6 Virtual IP (VIP) address is assigned using the property allowed_address_pairs map property ip_address, the parameter name MUST follow the naming convention

  • {vm-type}_int_{network-role}_floating_v6_ip

where

  • {vm-type} is the {vm-type} associated with the OS::Nova::Server

  • {network-role} is the {network-role} of the ONAP internal network

And the parameter MUST be declared as type: string and MUST be enumerated in the environment file

OR

the parameter name MUST follow the naming convention

  • {vm-type}_int_{network-role}_floating_v6_ips

where

  • {vm-type} is the {vm-type} associated with the OS::Nova::Server

  • {network-role} is the {network-role} of the ONAP internal network

And the parameter MUST be declared as type: comma_delimited_list and MUST be enumerated in the environment file.

Resource: OS::Neutron::Port - Parameters > Property: fixed_ips, Map Property: ip_address

Requirements Changed

(R-27818)

When the VNF’s Heat Orchestration Template’s Resource OS::Neutron::Port is attaching to an ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666), and an IPv6 address is assigned using the property fixed_ips map property ip_address and the parameter type is defined as a string, the parameter name MUST follow the naming convention

  • {vm-type}_int_{network-role}_v6_ip_{index}

where

  • {vm-type} is the {vm-type} associated with the OS::Nova::Server

  • {network-role} is the {network-role} of the ONAP internal network

  • {index} is a numeric value that MUST start at zero in a VNF’s Heat Orchestration Template and MUST increment by one

(R-40971)

When the VNF’s Heat Orchestration Template’s Resource OS::Neutron::Port is attaching to an ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968), and an IPv4 address is assigned using the property fixed_ips map property ip_address and the parameter type is defined as a string, the parameter name MUST follow the naming convention

  • {vm-type}_{network-role}_ip_{index}

where

  • {vm-type} is the {vm-type} associated with the OS::Nova::Server

  • {network-role} is the {network-role} of the ONAP external network

  • {index} is a numeric value that MUST start at zero in a VNF’s Heat Orchestration Template and MUST increment by one

(R-04697)

When the VNF’s Heat Orchestration Template’s Resource OS::Neutron::Port is attaching to an ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968), and an IPv4 address is assigned using the property fixed_ips map property ip_address and the parameter type is defined as a comma_delimited_list, the parameter name MUST follow the naming convention

  • {vm-type}_{network-role}_ips

where

  • {vm-type} is the {vm-type} associated with the OS::Nova::Server

  • {network-role} is the {network-role} of the ONAP external network

(R-78380)

When the VNF’s Heat Orchestration Template’s Resource OS::Neutron::Port is attaching to an ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666), and an IPv4 address is assigned using the property fixed_ips map property ip_address and the parameter type is defined as a string, the parameter name MUST follow the naming convention

  • {vm-type}_int_{network-role}_ip_{index}

where

  • {vm-type} is the {vm-type} associated with the OS::Nova::Server

  • {network-role} is the {network-role} of the ONAP internal network

  • {index} is a numeric value that MUST start at zero in a VNF’s Heat Orchestration Template and MUST increment by one

(R-23503)

When the VNF’s Heat Orchestration Template’s Resource OS::Neutron::Port is attaching to an ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968), and an IPv6 address is assigned using the property fixed_ips map property ip_address and the parameter type is defined as a comma_delimited_list, the parameter name MUST follow the naming convention

  • {vm-type}_{network-role}_v6_ips

where

  • {vm-type} is the {vm-type} associated with the OS::Nova::Server

  • {network-role} is the {network-role} of the ONAP external network

(R-85235)

When the VNF’s Heat Orchestration Template’s Resource OS::Neutron::Port is attaching to an ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666), and an IPv4 address is assigned using the property fixed_ips map property ip_address and the parameter type is defined as a comma_delimited_list, the parameter name MUST follow the naming convention

  • {vm-type}_int_{network-role}_ips

where

  • {vm-type} is the {vm-type} associated with the OS::Nova::Server

  • {network-role} is the {network-role} of the ONAP internal network

(R-93496)

The VNF’s Heat Orchestration Template’s Resource OS::Neutron::Port property fixed_ips map property ip_address parameter associated with an ONAP internal network, i.e.,

  • {vm-type}_int_{network-role}_ip_{index}

  • {vm-type}_int_{network-role}_v6_ip_{index}

  • {vm-type}_int_{network-role}_ips

  • {vm-type}_int_{network-role}_v6_ips

MUST be enumerated in the Heat Orchestration Template’s Environment File and IP addresses MUST be assigned.

(R-71577)

When the VNF’s Heat Orchestration Template’s Resource OS::Neutron::Port is attaching to an ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968), and an IPv6 address is assigned using the property fixed_ips map property ip_address and the parameter type is defined as a string, the parameter name MUST follow the naming convention

  • {vm-type}_{network-role}_v6_ip_{index}

where

  • {vm-type} is the {vm-type} associated with the OS::Nova::Server

  • {network-role} is the {network-role} of the ONAP external network

  • {index} is a numeric value that MUST start at zero in a VNF’s Heat Orchestration Template and MUST increment by one

(R-62590)

The VNF’s Heat Orchestration Template’s Resource OS::Neutron::Port property fixed_ips map property ip_address parameter associated with an ONAP external network, i.e.,

  • {vm-type}_{network-role}_ip_{index}

  • {vm-type}_{network-role}_v6_ip_{index}

  • {vm-type}_{network-role}_ips

  • {vm-type}_{network-role}_v6_ips

MUST NOT be enumerated in the Heat Orchestration Template’s Environment File. ONAP provides the IP address assignments at orchestration time.

(R-29765)

When the VNF’s Heat Orchestration Template’s Resource OS::Neutron::Port is attaching to an ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666), and an IPv6 address is assigned using the property fixed_ips map property ip_address and the parameter type is defined as a comma_delimited_list, the parameter name MUST follow the naming convention

  • {vm-type}_int_{network-role}_v6_ips

where

  • {vm-type} is the {vm-type} associated with the OS::Nova::Server

  • {network-role} is the {network-role} of the ONAP internal network

Resource: OS::Neutron::Port - Parameters > Property: fixed_ips, Map Property: subnet

Requirements Changed

(R-76160)

When

  • the VNF’s Heat Orchestration Template’s resource OS::Neutron::Port in an Incremental Module is attaching to an ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666) that is created in the Base Module, AND

  • an IPv6 address is being cloud assigned by OpenStack’s DHCP Service AND

  • the ONAP internal network IPv6 subnet is to be specified using the property fixed_ips map property subnet,

the parameter MUST follow the naming convention

  • int_{network-role}_v6_subnet_id

where {network-role} is the network role of the ONAP internal network.

Note that the parameter MUST be defined as an output parameter in the base module.

(R-15287)

When the VNF’s Heat Orchestration Template’s resource OS::Neutron::Port is attaching to an ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968), and an IPv6 address is being cloud assigned by OpenStack’s DHCP Service and the ONAP external network IPv6 subnet is to be specified using the property fixed_ips map property subnet, the parameter MUST follow the naming convention

  • {network-role}_v6_subnet_id

where

  • {network-role} is the network role of the ONAP external network.

(R-62802)

When the VNF’s Heat Orchestration Template’s resource OS::Neutron::Port is attaching to an ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968), and an IPv4 address is being cloud assigned by OpenStack’s DHCP Service and the ONAP external network IPv4 subnet is to be specified using the property fixed_ips map property subnet, the parameter MUST follow the naming convention

  • {network-role}_subnet_id

where

  • {network-role} is the network role of the ONAP external network.

(R-84123)

When

  • the VNF’s Heat Orchestration Template’s resource OS::Neutron::Port in an Incremental Module is attaching to an ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666) that is created in the Base Module, AND

  • an IPv4 address is being cloud assigned by OpenStack’s DHCP Service AND

  • the internal network IPv4 subnet is to be specified using the property fixed_ips map property subnet,

the parameter MUST follow the naming convention

  • int_{network-role}_subnet_id

where

  • {network-role} is the network role of the ONAP internal network

Note that the parameter MUST be defined as an output parameter in the base module.

Resource: OS::Neutron::Port - Parameters > Property: network

Requirements Changed

(R-86182)

When the VNF’s Heat Orchestration Template’s Resource OS::Neutron::Port is in an incremental module and is attaching to an ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666), the network parameter name MUST

  • follow the naming convention int_{network-role}_net_id if the network UUID value is used to reference the network

  • follow the naming convention int_{network-role}_net_name if the network name in is used to reference the network.

where {network-role} is the network-role of the ONAP internal network and a get_param MUST be used as the intrinsic function.

(R-62983)

When the VNF’s Heat Orchestration Template’s Resource OS::Neutron::Port is attaching to an ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968), the network parameter name MUST

  • follow the naming convention {network-role}_net_id if the Neutron network UUID value is used to reference the network

  • follow the naming convention {network-role}_net_name if the OpenStack network name is used to reference the network.

where {network-role} is the network-role of the ONAP external network and a get_param MUST be used as the intrinsic function.

Resource: OS::Nova::Server Metadata Parameters > vf_module_index

Requirements Added

(R-55307)

A VNF’s Heat Orchestration Template’s parameter vf_module_index MUST NOT be used for indexing an:

  • OS::Nova::Server property name parameter (when defined as a comma_delimited_list).

  • OS::Neutron::Port property fixed_ips map property ip_address parameter (when defined as a comma_delimited_list) when the port is attaching to an ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968)

  • OS::ContrailV2::InstanceIp property instance_ip_address parameter (when defined as a comma_delimited_list) when the port (i.e, OS::ContrailV2::VirtualMachineInterface) is attaching to an ONAP external network (per the ONAP definition, see Requirement R-57424 and R-16968)

VNF Security > VNF General Security Requirements

Requirements Added

(R-353637)

Containerized components of VNFs SHOULD follow the recommendations for Container Base Images and Build File Configuration in the latest available version of the CIS Docker Community Edition Benchmarks to ensure that containerized VNFs are secure. All non-compliances with the benchmarks MUST be documented.

(R-381623)

Containerized components of VNFs SHOULD execute in a Docker run-time environment that follows the Container Runtime Configuration in the latest available version of the CIS Docker Community Edition Benchmarks to ensure that containerized VNFs are secure. All non-compliances with the benchmarks MUST be documented.

Requirements Changed

(R-842258)

The VNF MUST include a configuration (e.g. a heat template or CSAR package) that specifies the targeted parameters (e.g. a limited set of ports) over which the VNF will communicate; including internal, external and management communication.

(R-19082)

The VNF MUST not contain undocumented functionality.

(R-46986)

The VNF provider MUST follow GSMA vendor practices and SEI CERT Coding Standards when developing the VNF in order to minimize the risk of vulnerabilities. See GSMA NESAS Network Equipment Security Assurance Scheme – Development and Lifecycle Security Requirements Version 1.0 (https://www.gsma.com/ security/wp-content/uploads/2019/11/FS.16-NESAS-Development-and-Lifecycle-Security- Requirements-v1.0.pdf) and SEI CERT Coding Standards (https://wiki.sei.cmu.edu/ confluence/display/seccode/SEI+CERT+Coding+Standards).

(R-19768)

The VNF SHOULD support the separation of (1) signaling and payload traffic (i.e., customer facing traffic), (2) operations, administration and management traffic, and (3) internal VNF traffic (i.e., east-west traffic such as storage access) using technologies such as VPN and VLAN.

(R-86261)

The VNF MUST be able to authenticate and authorize all remote access.

(R-62498)

The VNF MUST support only encrypted access protocols, e.g., TLS, SSH, SFTP.

(R-56904)

The VNF MUST interoperate with the ONAP (SDN) Controller so that it can dynamically modify the firewall rules, ACL rules, QoS rules, virtual routing and forwarding rules. This does not preclude the VNF providing other interfaces for modifying rules.

Requirements Removed

R-23882

The VNF SHOULD provide the capability for the Operator to run security vulnerability scans of the operating system and all application layers.

R-343842

The VNF MUST, after a successful login at command line or a GUI, display the last valid login date and time and the number of unsuccessful attempts since then made with that user’s ID. This requirement is only applicable when the user account is defined locally in the VNF.

R-40813

The VNF SHOULD support the use of virtual trusted platform module.

VNF Security > VNF Identity and Access Management Requirements

Requirements Added

(R-251639)

The VNF MUST provide explicit confirmation of a session termination such as a message, new page, or rerouting to a login page.

(R-358699)

The VNF MUST support at least the following roles: system administrator, application administrator, network function O&M.

(R-373737)

The VNF MUST, if not integrated with the operator’s IAM system, provide a mechanism for assigning roles and/or permissions to an identity.

Requirements Changed

(R-86835)

The VNF MUST set the default settings for user access to deny authorization, except for a super user type of account.

(R-814377)

The VNF MUST have the capability of allowing the Operator to create, manage, and automatically provision user accounts using one of the protocols specified in Chapter 7.

(R-231402)

The VNF MUST provide a means to explicitly logout, thus ending that session.

(R-81147)

The VNF MUST, if not integrated with the Operator’s Identity and Access Management system, support multifactor authentication on all protected interfaces exposed by the VNF for use by human users.

(R-78010)

The VNF MUST support LDAP in order to integrate with an external identity and access manage system. It MAY support other identity and access management protocols.

(R-79107)

The VNF MUST, if not integrated with the Operator’s Identity and Access Management system, support the ability to lock out the userID after a configurable number of consecutive unsuccessful authentication attempts using the same userID. The locking mechanism must be reversible by an administrator and should be reversible after a configurable time period.

(R-42874)

The VNF MUST allow the Operator to restrict access to protected resources based on the assigned permissions associated with an ID in order to support Least Privilege (no more privilege than required to perform job functions).

(R-581188)

The VNF MUST NOT identify the reason for a failed authentication, only that the authentication failed.

(R-23135)

The VNF MUST, if not integrated with the Operator’s identity and access management system, authenticate all access to protected resources.

(R-479386)

The VNF MUST provide the capability of setting a configurable message to be displayed after successful login. It MAY provide a list of supported character sets.

(R-931076)

The VNF MUST support account names that contain at least A-Z, a-z, and 0-9 character sets and be at least 6 characters in length.

(R-45719)

The VNF MUST, if not integrated with the Operator’s Identity and Access Management system, enforce a configurable “terminate idle sessions” policy by terminating the session after a configurable period of inactivity.

Requirements Removed

R-15671

The VNF MUST provide access controls that allow the Operator to restrict access to VNF functions and data to authorized entities.

R-71787

Each architectural layer of the VNF (eg. operating system, network, application) MUST support access restriction independently of all other layers so that Segregation of Duties can be implemented.

R-85419

The VNF SHOULD support OAuth 2.0 authorization using an external Authorization Server.

VNF and PNF On-boarding and package management > Resource Configuration

Requirements Changed

(R-89571)

The VNF or PNF PROVIDER MUST provide artifacts for configuration management using at least one of the following technologies; a) Netconf/YANG, b) Chef, or c) Ansible.

VNF or PNF CSAR Package > VNF or PNF Package Contents

Requirements Added

(R-972082)

If the Manifest file in the PNF CSAR package includes “onap_pnf_sw_information” as a non-MANO artifact set identifiers, then the PNF software information file is included in the package and it MUST be compliant to:

  • The file extension which contains the PNF software version must be .yaml

  • The PNF software version information must be specified as following:

pnf_software_information:

 - pnf_software_version:  "<version>"

Requirements Changed

(R-40820)

The VNF or PNF CSAR PACKAGE MUST enumerate all of the open source licenses their VNF(s) incorporate. CSAR License directory as per ETSI SOL004.

for example ROOT\Licenses\ License_term.txt

(R-795126)

The VNF CSAR package Manifest file MUST start with the VNF package metadata in the form of a name-value pairs. Each pair shall appear on a different line. The name is specified as following:

  • vnf_provider_id

  • vnf_product_name

  • vnf_release_date_time

  • vnf_package_version

(R-01123)

The VNF or PNF CSAR package Manifest file MUST contain: VNF or PNF package meta-data, a list of all artifacts (both internal and external) entry’s including their respected URI’s, as specified in ETSI GS NFV-SOL 004

(R-221914)

The VNF or PNF CSAR package MUST contain a human-readable change log text file. The Change Log file keeps a history describing any changes in the VNF or PNF package. The Change Log file is kept up to date continuously from the creation of the CSAR package.

(R-57019)

The PNF CSAR PACKAGE Manifest file MUST start with the PNF package metadata in the form of a name-value pairs. Each pair shall appear on a different line. The name is specified as following:

  • pnfd_provider

  • pnfd_name

  • pnfd_release_date_time

  • pnfd_archive_version

(R-146092)

If one or more non-MANO artifact(s) is included in the VNF or PNF CSAR package, the Manifest file in this CSAR package MUST contain one or more of the following ONAP non-MANO artifact set identifier(s):

  • onap_ves_events: contains VES registration files

  • onap_pm_dictionary: contains the PM dictionary files

  • onap_yang_modules: contains Yang module files for configurations

  • onap_ansible_playbooks: contains any ansible_playbooks

  • onap_pnf_sw_information: contains the PNF software information file

  • onap_others: contains any other non_MANO artifacts, e.g. informational documents

NOTE: According to ETSI SOL004 v.2.6.1, every non-MANO artifact set shall be identified by a non-MANO artifact set identifier which shall be registered in the ETSI registry. Approved ONAP non-MANO artifact set identifiers are documented in the following page https://wiki.onap.org/display/DW/ONAP+Non-MANO+Artifacts+Set+Identifiers

VNF or PNF CSAR Package > VNF or PNF Package Structure and Format

Requirements Changed

(R-506221)

The VNF or PNF CSAR file MUST be a zip file with .csar extension.

(R-87234)

The VNF or PNF CSAR package provided by a VNF or PNF vendor MUST be with TOSCA-Metadata directory (CSAR Option 1) as specified in ETSI GS NFV-SOL004.

Note: SDC supports only the CSAR Option 1 in Dublin. The Option 2 will be considered in future ONAP releases.

{network-role}

Requirements Changed

(R-21330)

A VNF’s Heat Orchestration Template’s Resource property parameter that is associated with an ONAP external network MUST include the {network-role} as part of the parameter name.

(R-84322)

A VNF’s Heat Orchestration Template’s Resource property parameter that is associated with an ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666) MUST include int_{network-role} as part of the parameter name, where int_ is a hard coded string.

(R-96983)

A VNF’s Heat Orchestration Template’s Resource ID that is associated with an ONAP internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666) MUST include int_{network-role} as part of the Resource ID, where int_ is a hard coded string.

(R-11168)

A VNF’s Heat Orchestration Template’s Resource ID that is associated with an ONAP external network MUST include the {network-role} as part of the resource ID.

(R-69014)

When a VNF’s port connects to an ONAP internal network or ONAP external network, a network role, referred to as the {network-role} MUST be assigned to the network for use in the VNF’s Heat Orchestration Template. The {network-role} is used in the VNF’s Heat Orchestration Template’s resource IDs and resource property parameter names.