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
Requirement Changes Introduced in Frankfurt
Contrail Resource Parameters > Contrail Network Parameters > ONAP External Networks
Monitoring & Management > Data Structure Specification of the Event Record
ONAP Heat Heat Template Constructs > Nested Heat Templates > Nested Heat Template Requirements
ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > parameters
ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > resources
Resource IDs > Contrail Heat Resources Resource ID Naming Convention > OS::ContrailV2::InstanceIp
Resource IDs > Contrail Heat Resources Resource ID Naming Convention > OS::ContrailV2::NetworkIpam
Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Neutron::Net
Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Neutron::Port
Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Neutron::SecurityGroup
Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Neutron::Subnet
Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Nova::Keypair
Resource: OS::Neutron::Port - Parameters > Introduction > Items to Note
Resource: OS::Neutron::Port - Parameters > Property: fixed_ips, Map Property: ip_address
Resource: OS::Neutron::Port - Parameters > Property: fixed_ips, Map Property: subnet
Resource: OS::Neutron::Port - Parameters > Property: network
Resource: OS::Nova::Server Metadata Parameters > vf_module_index
VNF Security > VNF Identity and Access Management Requirements
VNF and PNF On-boarding and package management > Resource Configuration
VNF or PNF CSAR Package > VNF or PNF Package Structure and Format
Summary of Changes
Requirements Added: 22
Requirements Changed: 129
Requirements Removed: 6
Configuration Management
Requirements Added
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
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
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.
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”
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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
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
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
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
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
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 typecomma_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.
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 theOS::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.
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 theOS::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.
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
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.
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
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 theOS::Nova::Server
{network-role}
is the {network-role} of the ONAP internal network
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 theOS::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
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 theOS::Nova::Server
{network-role}
is the {network-role} of the ONAP internal network
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 theOS::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
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 theOS::Nova::Server
{network-role}
is the {network-role} of the ONAP external network
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 theOS::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
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.
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
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 theOS::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
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
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.
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.
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, ANDan 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.
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, ANDan 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
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
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
A VNF MAY be connected to zero, one or more than one ONAP external network.
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
An ONAP external network MUST have one subnet. An external network MAY have more than one subnet.
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
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
).
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.
A VNF’s ONAP internal network MUST have one subnet. A VNF’s ONAP internal network MAY have more than one subnet.
A VNF SHOULD create the ONAP internal network in the VNF’s Heat Orchestration Template’s Base Module.
A VNF’s port connected to an ONAP internal network MUST use the port for the purpose of reaching VMs in the same VNF.
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.
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
A VNF Heat Orchestration’s template’s base module MAY (or MAY NOT)
contain the section parameters:
.
Requirements Changed
A VNF Heat Orchestration’s template’s incremental module and volume module
MUST contain the section parameters:
.
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
A VNF’s Heat Orchestration template’s base module
MAY (or MAY NOT)
contain the section resources:
.
Requirements Changed
A VNF’s Heat Orchestration template’s incremental
module and volume module MUST
contain the section resources:
.
Resource IDs
Requirements Changed
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 theint_{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 theint_{network-role}
and when this occurs underscores MUST separate the three values. (e.g.,{vm-type}_{index}_int_{network-role}
).
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.
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}
.
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}
).
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}
.
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
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.
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.
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.
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
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
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.
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
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
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
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.
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).
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.
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
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
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
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
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
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
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
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
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 theOS::Nova::Server
{index}
is the{index}
of the keypair. The{index}
starts at zero and increments by one (as described in R-11690).
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
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.
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.
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 propertyip_address
MUST be usedproperty
fixed_ips
map propertysubnet
MUST NOT be used
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 propertyip_address
MUST be usedproperty
fixed_ips
map propertysubnet
MUST NOT be used
Resource: OS::Neutron::Port - Parameters > Property: allowed_address_pairs, Map Property: ip_address > VIP Assignment, ONAP External Networks
Requirements Changed
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 theOS::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.
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.
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.
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 theOS::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
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.
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
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 theOS::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
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 theOS::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
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 theOS::Nova::Server
{network-role}
is the {network-role} of the ONAP external network
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 theOS::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
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
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 theOS::Nova::Server
{network-role}
is the {network-role} of the ONAP internal network
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.
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 theOS::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
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.
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 theOS::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
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, ANDan 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 propertysubnet
,
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.
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.
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.
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, ANDan 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 propertysubnet
,
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
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 networkfollow 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.
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 networkfollow 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
A VNF’s Heat Orchestration Template’s parameter vf_module_index
MUST NOT be used for indexing an:
OS::Nova::Server
propertyname
parameter (when defined as acomma_delimited_list
).OS::Neutron::Port
propertyfixed_ips
map propertyip_address
parameter (when defined as acomma_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
propertyinstance_ip_address
parameter (when defined as acomma_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
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.
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
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.
The VNF MUST not contain undocumented functionality.
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).
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.
The VNF MUST be able to authenticate and authorize all remote access.
The VNF MUST support only encrypted access protocols, e.g., TLS, SSH, SFTP.
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
The VNF MUST provide explicit confirmation of a session termination such as a message, new page, or rerouting to a login page.
The VNF MUST support at least the following roles: system administrator, application administrator, network function O&M.
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
The VNF MUST set the default settings for user access to deny authorization, except for a super user type of account.
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.
The VNF MUST provide a means to explicitly logout, thus ending that session.
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.
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.
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.
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).
The VNF MUST NOT identify the reason for a failed authentication, only that the authentication failed.
The VNF MUST, if not integrated with the Operator’s identity and access management system, authenticate all access to protected resources.
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.
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.
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
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
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
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
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
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
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.
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
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
The VNF or PNF CSAR file MUST be a zip file with .csar extension.
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
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.
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.
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.
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.
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.