Requirement Changes Introduced in Dublin
This document summarizes the requirement changes by section that were introduced between the Casablanca release and Dublin release. Click on the requirement number to navigate to the
Contents
Requirement Changes Introduced in Dublin
Configuration Management > Controller Interactions With VNF or PNF > Configuration Commands
Monitoring & Management > Data Structure Specification of the Event Record
Monitoring & Management > Event Records - Data Structure Description > Common Event Header
Monitoring & Management > Monitoring & Management Requirements > Addressing and Delivery Protocol
Monitoring & Management > Monitoring & Management Requirements > Bulk Performance Measurement
Monitoring & Management > Monitoring & Management Requirements > Google Protocol Buffers (GPB)
Monitoring & Management > Monitoring & Management Requirements > JSON
Monitoring & Management > Monitoring & Management Requirements > Reporting Frequency
Monitoring & Management > Monitoring & Management Requirements > Security
Monitoring & Management > Transports and Protocols Supporting Resource Interfaces
Summary of Changes
Requirements Added: 64
Requirements Changed: 275
Requirements Removed: 40
Configuration Management > Ansible Standards and Capabilities > VNF or PNF Configuration via Ansible Requirements > Ansible Client Requirements
Requirements Changed
The VNF or PNF MUST provide Ansible playbooks that are designed to run using an inventory hosts file in a supported format with only IP addresses or IP addresses and VM/VNF or PNF names.
The VNF or PNF MUST load the Ansible Server SSH public key onto VNF or PNF VM(s) /root/.ssh/authorized_keys as part of instantiation. Alternative, is for Ansible Server SSH public key to be loaded onto VNF or PNF VM(s) under /home/<Mechanized user ID>/.ssh/authorized_keys as part of instantiation, when a Mechanized user ID is created during instantiation, and Configure and all playbooks are designed to use a mechanized user ID only for authentication (never using root authentication during Configure playbook run). This will allow the Ansible Server to authenticate to perform post-instantiation configuration without manual intervention and without requiring specific VNF or PNF login IDs and passwords.
CAUTION: For VNFs or PNFs configured using Ansible, to eliminate the need for manual steps, post-instantiation and pre-configuration, to upload of SSH public keys, SSH public keys loaded during (heat) instantiation shall be preserved and not removed by (heat) embedded (userdata) scripts.
The VNF or PNF MUST support SSH and allow SSH access by the Ansible server to the endpoint VM(s) and comply with the Network Cloud Service Provider guidelines for authentication and access.
The VNF or PNF MUST provide the ability to remove root access once post-instantiation configuration (Configure) is completed.
The VNF or PNF MUST define the “from=” clause to provide the list of IP addresses of the Ansible Servers in the Cluster, separated by coma, to restrict use of the SSH key pair to elements that are part of the Ansible Cluster owner of the issued and assigned mechanized user ID.
The VNF or PNF MUST provide the ability to include a “from=” clause in SSH public keys associated with mechanized user IDs created for an Ansible Server cluster to use for VNF or PNF VM authentication.
The VNF or PNF MUST permit authentication, using root account, only right after instantiation and until post-instantiation configuration is completed.
The VNF or PNF MUST include as part of post-instantiation configuration done by Ansible Playbooks the removal/update of the SSH public key from /root/.ssh/authorized_keys, and update of SSH keys loaded through instantiation to support Ansible. This may include creating Mechanized user ID(s) used by the Ansible Server(s) on VNF VM(s) and uploading and installing new SSH keys used by the mechanized use ID(s).
The VNF or PNF MUST provide Ansible playbooks that are designed to run using an inventory hosts file in a supported format; with group names matching VNFC 3-character string adding “vip” for groups with virtual IP addresses shared by multiple VMs as seen in examples provided in Appendix.
The VNF or PNF MUST have routable management IP addresses or FQDNs that are reachable via the Ansible Server for the endpoints (VMs) of a VNF or PNF that playbooks will target. ONAP will initiate requests to the Ansible Server for invocation of playbooks against these end points [#7.3.3]_.
The VNF or PNF MUST have Python >= 2.6 on the endpoint VM(s) of a VNF or PNF on which an Ansible playbook will be executed.
The VNF or PNF MUST provide Ansible playbooks that are designed to run using an inventory hosts file in a supported format; with site group that shall be used to add site specific configurations to the target VNF or PNF VM(s) as needed.
The VNF or PNF MUST update the Ansible Server and other entities storing and using the SSH keys for authentication when the SSH keys used by Ansible are regenerated/updated.
Note: Ansible Server itself may be used to upload new SSH public keys onto supported VNFs or PNFs.
Configuration Management > Ansible Standards and Capabilities > VNF or PNF Configuration via Ansible Requirements > Ansible Playbook Requirements
Requirements Changed
The VNF or PNF provider MUST assign a new point release to the updated playbook set. The functionality of a new playbook set must be tested before it is deployed to the production.
The VNF or PNF SHOULD NOT use playbooks that make requests to Cloud resources e.g. Openstack (nova, neutron, glance, heat, etc.); therefore, there is no use for Cloud specific variables like Openstack UUIDs in Ansible Playbook related artifacts.
Rationale: Flows that require interactions with Cloud services e.g. Openstack shall rely on workflows run by an Orchestrator (Change Management) or other capability (such as a control loop or Operations GUI) outside Ansible Server which can be executed by a APPC/SDN-C. There are policies, as part of Control Loop models, that send remediation action requests to an APPC/SDN-C; these are triggered as a response to an event or correlated events published to Event Bus.
The VNF or PNF provider MUST deliver a new set of playbooks that includes all updated and unchanged playbooks for any new revision to an existing set of playbooks.
The VNF or PNF MUST return control from Ansible Playbooks only after all tasks performed by playbook are fully complete, signaling that the playbook completed all tasks. When starting services, return control only after all services are up. This is critical for workflows where the next steps are dependent on prior tasks being fully completed.
The VNF or PNF SHOULD use playbooks that are designed to automatically ‘rollback’ to the original state in case of any errors for actions that change state of the VNF or PNF (e.g., configure).
Note: In case rollback at the playbook level is not supported or possible, the VNF or PNF provider shall provide alternative rollback mechanism (e.g., for a small VNF or PNF the rollback mechanism may rely on workflow to terminate and re-instantiate VNF VMs and then re-run playbook(s)). Backing up updated files is also recommended to support rollback when soft rollback is feasible.
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 an 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 use playbooks designed to allow Ansible Server to infer failure or success based on the “PLAY_RECAP” capability.
Note: There are cases where playbooks need to interpret results of a task and then determine success or failure and return result accordingly (failure for failed tasks).
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 or PNF VMs, to be provided as a response to the request, must be written to this response file.
The VNF or PNF MUST support Ansible playbooks that are compatible with Ansible version 2.6 or later.
The VNF or PNF MUST NOT use any instance specific parameters in a playbook.
The VNF or PNF MUST make available playbooks that conform to the ONAP requirement.
The VNF or PNF SHOULD use available backup capabilities to save a copy of configuration files before implementing changes to support operations such as backing out of software upgrades, configuration changes or other work as this will help backing out of configuration changes when needed.
Configuration Management > Chef Standards and Capabilities > VNF or PNF Configuration via Chef Requirements > Chef Client Requirements
Requirements Changed
The VNF or PNF MAY expose a single endpoint that is responsible for all functionality.
The VNF or PNF MUST have the chef-client be preloaded with validator keys and configuration to register with the designated Chef Server as part of the installation process.
The VNF or PNF MUST be installed with Chef-Client >= 12.0 and Chef push jobs client >= 2.0.
The VNF or PNF MUST have routable FQDNs for all the endpoints (VMs) of a VNF or PNF that contain chef-clients which are used to register with the Chef Server. As part of invoking VNF or PNF actions, ONAP will trigger push jobs against FQDNs of endpoints for a VNF or PNF, if required.
Configuration Management > Chef Standards and Capabilities > VNF or PNF Configuration via Chef Requirements > Chef Roles/Requirements
Requirements Changed
The VNF or PNF MUST accept all necessary instance specific data from the environment or node object attributes for the VNF or PNF in roles/cookbooks/recipes invoked for a VNF or PNF action.
The VNF or PNF MUST over-ride any default values for configurable parameters that can be set by ONAP in the roles, cookbooks and recipes.
The VNF or PNF Package MUST have appropriate cookbooks that are designed to automatically ‘rollback’ to the original state in case of any errors for actions that change state of the VNF or PNF (e.g., configure).
The VNF or PNF Package MUST include a run list of roles/cookbooks/recipes, for each supported VNF or PNF action, that will perform the desired VNF or PNF action in its entirety as specified by ONAP (see Section 7.c, APPC/SDN-C APIs and Behavior, for list of VNF or PNF actions and requirements), when triggered by a chef-client run list in JSON file.
The VNF or PNF Package MUST include all relevant Chef artifacts (roles/cookbooks/recipes) required to execute VNF or PNF actions requested by ONAP for loading on appropriate Chef Server.
The VNF or PNF MUST populate an attribute, defined as node [‘PushJobOutput’] with the desired output on all nodes in the push job that execute chef-client run if the VNF or PNF action requires the output of a chef-client run be made available (e.g., get running configuration).
The VNF or PNF MUST Upon completion of the chef-client run, POST back on the callback URL, a JSON object as described in Table A2 if the chef-client run list includes a cookbook/recipe that is callback capable. Failure to POST on the Callback Url should not be considered a critical error. That is, if the chef-client successfully completes the VNF or PNF action, it should reflect this status on the Chef Server regardless of whether the Callback succeeded or not.
The VNF or PNF SHOULD support callback URLs to return information to ONAP upon completion of the chef-client run for any chef-client run associated with a VNF or PNF action.
As part of the push job, ONAP will provide two parameters in the environment of the push job JSON object:
“RequestId” a unique Id to be used to identify the request,
“CallbackUrl”, the URL to post response back.
If the CallbackUrl field is empty or missing in the push job, then the chef-client run need not post the results back via callback.
The VNF or PNF MUST NOT use any instance specific parameters for the VNF or PNF in roles/cookbooks/recipes invoked for a VNF or PNF action.
The VNF or PNF MUST update status on the Chef Server appropriately (e.g., via a fail or raise an exception) if the chef-client run encounters any critical errors/failures when executing a VNF or PNF action.
Configuration Management > Controller Interactions With VNF or PNF > Configuration Commands
Requirements Changed
The VNF or PNF MUST support APPC/SDN-C Configure command.
The VNF or PNF MUST support APPC Audit command.
The VNF or PNF MUST support APPC ConfigRestore command.
The VNF or PNF MUST support APPC/SDN-C ConfigScaleOut command.
The VNF or PNF MUST support APPC ConfigModify command.
The VNF or PNF MUST support APPC ConfigBackup command.
Configuration Management > NETCONF Standards and Capabilities > VNF or PNF Configuration via NETCONF Requirements > Configuration Management
Requirements Changed
The VNF or PNF MUST provide a NETCONF interface fully defined by supplied YANG models for the embedded NETCONF server.
The VNF or PNF MUST include a NETCONF server enabling runtime configuration and lifecycle management capabilities.
Configuration Management > NETCONF Standards and Capabilities > VNF or PNF Configuration via NETCONF Requirements > NETCONF Server Requirements
Requirements Added
The VNF or PNF SHOULD support TLS as secure transport for the NETCONF protocol according to [RFC7589].
Requirements Changed
The VNF or PNF MUST follow the data model update rules defined in [RFC6020] section 10 for YANG 1.0 modules, and [RFC7950] section 11 for YANG 1.1 modules. All deviations from the aforementioned update rules shall be handled by a built-in automatic upgrade mechanism.
The VNF or PNF MUST support parallel and simultaneous configuration of separate objects within itself.
The VNF or PNF MUST implement the data model discovery and download as defined in [RFC6022].
The VNF or PNF MUST implement the :validate capability.
The VNF or PNF MUST allow all configuration data to be edited through a NETCONF <edit-config> operation. Proprietary NETCONF RPCs that make configuration changes are not sufficient.
The VNF or PNF MUST support locking if a common object is being manipulated by two simultaneous NETCONF configuration operations on the same VNF or PNF within the context of the same writable running data store (e.g., if an interface parameter is being configured then it should be locked out for configuration by a simultaneous configuration operation on that same interface parameter).
The VNF or PNF SHOULD implement the protocol operation:
delete-config(target) - Delete the named configuration
data store target.
The VNF or PNF MUST release locks to prevent permanent lock-outs when/if a session applying the lock is terminated (e.g., SSH session is terminated).
The VNF or PNF MUST implement :confirmed-commit If
:candidate is supported.
The VNF or PNF MUST implement the protocol operation:
unlock(target) - Unlock the configuration data store target.
The VNF or PNF SHOULD conform its YANG model to RFC 6536, “NETCONF Access Control Model”.
The VNF or PNF MUST allow the entire configuration of the VNF or PNF to be retrieved via NETCONF’s <get-config> and <edit-config>, independently of whether it was configured via NETCONF or other mechanisms.
The VNF or PNF MUST allow another NETCONF session to be able to initiate the release of the lock by killing the session owning the lock, using the <kill-session> operation to guard against hung NETCONF sessions.
The VNF or PNF MUST conform to the NETCONF RFC 6241, “NETCONF Configuration Protocol”.
The VNF or PNF MUST support sub tree filtering.
The VNF or PNF MUST implement the protocol operation:
get-config(source, filter - Retrieve a (filtered subset of
a) configuration from the configuration data store source.
The VNF or PNF MUST conform to the NETCONF RFC 5717, “Partial Lock Remote Procedure Call”.
The VNF or PNF MUST conform to the NETCONF RFC 4741, “NETCONF Configuration Protocol”.
The VNF or PNF PACKAGE MUST validated YANG code using the open source pyang [#7.3.1]_ program using the following commands:
$ pyang --verbose --strict <YANG-file-name(s)> $ echo $!
The VNF or PNF SHOULD conform its YANG model to RFC 7223, “A YANG Data Model for Interface Management”.
The VNF or PNF SHOULD conform its YANG model to RFC 6991, “Common YANG Data Types”.
The VNF or PNF MUST support simultaneous <commit> operations within the context of this locking requirements framework.
The VNF or PNF MUST implement the protocol operation:
kill-session(session- Force the termination of session.
The VNF or PNF SHOULD conform its YANG model to RFC 7223, “IANA Interface Type YANG Module”.
The VNF or PNF MUST implement the protocol operation:
close-session() - Gracefully close the current session.
The VNF or PNF MUST release locks to prevent permanent lock-outs when the corresponding <partial-unlock> operation succeeds.
The VNF or PNF MUST define all data models in YANG 1.0 [RFC6020] or YANG 1.1 [RFC7950]. A combination of YANG 1.0 and YANG 1.1 modules is allowed subject to the rules in [RFC7950] section 12. The mapping to NETCONF shall follow the rules defined in this RFC.
The VNF or PNF SHOULD implement the protocol operation:
copy-config(target, source) - Copy the content of the
configuration data store source to the configuration data store target.
The VNF or PNF MUST support the :startup capability. It
will allow the running configuration to be copied to this special
database. It can also be locked and unlocked.
TThe VNF or PNF MUST support heartbeat via a <get> with null filter.
The VNF or PNF MUST guarantee the VNF or PNF configuration integrity for all simultaneous configuration operations (e.g., if a change is attempted to the BUM filter rate from multiple interfaces on the same EVC, then they need to be sequenced in the VNF or PNF without locking either configuration method out).
The VNF or PNF MUST fully support the XPath 1.0 specification
for filtered retrieval of configuration and other database contents.
The ‘type’ attribute within the <filter> parameter for <get> and
<get-config> operations may be set to ‘xpath’. The ‘select’ attribute
(which contains the XPath expression) will also be supported by the
server. A server may support partial XPath retrieval filtering, but
it cannot advertise the :xpath capability unless the entire XPath
1.0 specification is supported.
The VNF or PNF MUST release locks to prevent permanent lock-outs when a user configured timer has expired forcing the NETCONF SSH Session termination (i.e., product must expose a configuration knob for a user setting of a lock expiration timer).
The VNF or PNF MUST have the echo command return a zero value otherwise the validation has failed.
The VNF or PNF MUST support a NETCONF server that can be mounted on OpenDaylight (client) and perform the operations of: modify, update, change, rollback configurations using each configuration data element, query each state (non-configuration) data element, execute each YANG RPC, and receive data through each notification statement.
The VNF or PNF MUST implement the protocol operation:
commit(confirmed, confirm-timeout) - Commit candidate
configuration data store to the running configuration.
The VNF or PNF SHOULD conform its YANG model to RFC 7407, “A YANG Data Model for SNMP Configuration”, if Netconf used to configure SNMP engine.
The VNF or PNF MUST conform to the NETCONF RFC 5277, “NETCONF Event Notification”.
The VNF or PNF MUST conform its YANG model to RFC 6470, “NETCONF Base Notifications”.
The VNF or PNF MUST conform to the NETCONF RFC 6242, “Using the Network Configuration Protocol over Secure Shell”.
The VNF or PNF MUST conform its YANG model to RFC 6087, “Guidelines for Authors and Reviewers of YANG Data Model specification”.
The VNF or PNF SHOULD implement the protocol operation:
get-schema(identifier, version, format) - Retrieve the YANG schema.
The VNF or PNF MUST implement the protocol operation:
discard-changes() - Revert the candidate configuration
data store to the running configuration.
The VNF or PNF MUST implement the protocol operation:
edit-config(target, default-operation, test-option, error-option,
config) - Edit the target configuration data store by merging,
replacing, creating, or deleting new config elements.
The VNF or PNF MUST implement the protocol operation:
lock(target) - Lock the configuration data store target.
The VNF or PNF MUST implement both :candidate and
:writable-running capabilities. When both :candidate and
:writable-running are provided then two locks should be supported.
The VNF or PNF MUST conform its YANG model to RFC 6244, “An Architecture for Network Management Using NETCONF and YANG”.
The VNF or PNF MUST implement the protocol operation:
get(filter) - Retrieve (a filtered subset of) the running
configuration and device state information. This should include
the list of VNF or PNF supported schemas.
The VNF or PNF SHOULD conform its YANG model to RFC 7317, “A YANG Data Model for System Management”.
The VNF or PNF MUST support :rollback-on-error value for
the <error-option> parameter to the <edit-config> operation. If any
error occurs during the requested edit operation, then the target
database (usually the running configuration) will be left unaffected.
This provides an ‘all-or-nothing’ edit mode for a single <edit-config>
request.
The VNF or PNF 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.
The VNF or PNF MUST support :partial-lock and
:partial-unlock capabilities, defined in RFC 5717. This
allows multiple independent clients to each write to a different
part of the <running> configuration at the same time.
The VNF or PNF MUST support the :url value to specify
protocol operation source and target parameters. The capability URI
for this feature will indicate which schemes (e.g., file, https, sftp)
that the server supports within a particular URL value. The ‘file’
scheme allows for editable local configuration databases. The other
schemes allow for remote storage of configuration databases.
The VNF or PNF MUST apply locking based on the sequence of NETCONF operations, with the first configuration operation locking out all others until completed.
The VNF or PNF MUST support all operations, administration and management (OAM) functions available from the supplier for VNFs or PNFs using the supplied YANG code and associated NETCONF servers.
The VNF or PNF MUST be able to specify the granularity of the lock via a restricted or full XPath expression.
The VNF or PNF SHOULD conform its YANG model to RFC 7277, “A YANG Data Model for IP Management”.
The VNF or PNF MUST permit locking at the finest granularity if a VNF or PNF needs to lock an object for configuration to avoid blocking simultaneous configuration operations on unrelated objects (e.g., BGP configuration should not be locked out if an interface is being configured or entire Interface configuration should not be locked out if a non-overlapping parameter on the interface is being configured).
The VNF or PNF MUST implement the :with-defaults capability
[RFC6243].
The VNF or PNF MUST conform to the NETCONF RFC 4742, “Using the NETCONF Configuration Protocol over Secure Shell (SSH)”.
Configuration Management > NETCONF Standards and Capabilities > xNF Configuration via NETCONF Requirements > NETCONF Server Requirements
Requirements Removed
R-28545
The xNF MUST conform its YANG model to RFC 6060, “YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)”.
Configuration Management > VNF or PNF REST APIs > REST APIs
Requirements Changed
The VNF or PNF MUST support the HealthCheck RPC. The HealthCheck RPC executes a VNF or PNF Provider-defined VNF or PNF HealthCheck over the scope of the entire VNF or PNF (e.g., if there are multiple VNFCs, then run a health check, as appropriate, for all VNFCs). It returns a 200 OK if the test completes. A JSON object is returned indicating state (healthy, unhealthy), scope identifier, time-stamp and one or more blocks containing info and fault information. If the VNF or PNF is unable to run the HealthCheck, return a standard http error code and message.
Contrail Resource Parameters > OS::ContrailV2::VirtualMachineInterface Property virtual_machine_interface_allowed_address_pairs > External Networks
Requirements Added
If a VNF’s Heat Orchestration Template’s resource
OS::ContrailV2::VirtualMachineInterface
is attaching to an external network (per the
ONAP definition, see Requirement R-57424), 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.
When the VNF’s Heat Orchestration Template’s resource
OS::ContrailV2::VirtualMachineInterface is attaching to an external
network (per the
ONAP definition, see Requirement R-57424),
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 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 external
network (per the
ONAP definition, see Requirement R-57424),
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 external network
And the parameter MUST be declared as type string.
The ONAP data model can only support one IPv6 VIP address.
When the VNF’s Heat Orchestration Template’s resource
OS::ContrailV2::VirtualMachineInterface is attaching to an
external network
(per the ONAP definition, see Requirement R-57424),
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
stringor 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.
Contrail Resource Parameters > OS::ContrailV2::VirtualMachineInterface Property virtual_machine_interface_allowed_address_pairs > Internal Networks
Requirements Added
When the VNF’s Heat Orchestration Template’s Resource
OS::ContrailV2::VirtualMachineInterface is attaching to an
internal network (per the
ONAP definition, see Requirements R-52425 and R-46461),
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 external 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 external 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
internal network (per the
ONAP definition, see Requirements R-52425 and R-46461),
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 external 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 external 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 Added
The VNF’s Heat Orchestration Template’s
resource OS::ContrailV2::InstanceIp property instance_ip_address
parameter
MUST be declared as either type string or type
comma_delimited_list.
When the VNF’s Heat Orchestration Template’s Resource
OS::ContrailV2::InstanceIp is assigning an IP address
to an external network (per the ONAP definition, see Requirement R-57424),
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 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::ContrailV2::InstanceIp property instance_ip_address
parameter
{vm-type}_{network-role}_ip_{index}
MUST NOT be enumerated in the
VNF’s Heat Orchestration Template’s Environment File.
When the VNF’s Heat Orchestration Template’s Resource
OS::ContrailV2::InstanceIp is assigning an IP address
to an external network (per the
ONAP definition, see Requirement R-57424),
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}_ipswhere
{vm-type}is the {vm-type} associated with theOS::Nova::Server
{network-role}is the {network-role} of the external network
The VNF’s Heat Orchestration Template’s Resource
OS::ContrailV2::InstanceIp property instance_ip_address
parameter
{vm-type}_{network-role}_ips
MUST NOT be enumerated in the
VNF’s Heat Orchestration Template’s Environment File.
When the VNF’s Heat Orchestration Template’s Resource
OS::ContrailV2::InstanceIp is assigning an IP address
to an external network
(per the
ONAP definition, see Requirement R-57424),
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 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::ContrailV2::InstanceIp property instance_ip_address
parameter
{vm-type}_{network-role}_v6_ip_{index}
MUST NOT be enumerated in the
VNF’s Heat Orchestration Template’s Environment File.
When the VNF’s Heat Orchestration Template’s Resource
OS::ContrailV2::InstanceIp is assigning an IP address
to an external network (per the
ONAP definition, see Requirement R-57424),
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 external network
The VNF’s Heat Orchestration Template’s Resource
OS::ContrailV2::InstanceIp property instance_ip_address
parameter
{vm-type}_{network-role}_v6_ips
MUST NOT be enumerated in the
VNF’s Heat Orchestration Template’s Environment File.
When the VNF’s Heat Orchestration Template’s Resource
OS::ContrailV2::InstanceIp is assigning an IP address
to an internal network (per the
ONAP definition, see Requirements R-52425 and R-46461),
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 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
{vm-type}_int_{network-role}_ip_{index}
MUST be enumerated in the
VNF’s Heat Orchestration Template’s Environment File.
When the VNF’s Heat Orchestration Template’s Resource
OS::ContrailV2::InstanceIp is assigning an IP address
to an internal network (per the
ONAP definition, see Requirements R-52425 and R-46461),
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 internal network
The VNF’s Heat Orchestration Template’s Resource
OS::ContrailV2::InstanceIp property instance_ip_address
parameter
{vm-type}_int_{network-role}_int_ips
MUST be enumerated in the
VNF’s Heat Orchestration Template’s Environment File.
When the VNF’s Heat Orchestration Template’s Resource
OS::ContrailV2::InstanceIp is assigning an IP address to an
internal network (per the
ONAP definition, see Requirements R-52425 and R-46461),
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 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
{vm-type}_int_{network-role}_v6_ip_{index}
MUST be enumerated in the
VNF’s Heat Orchestration Template’s Environment File.
When the VNF’s Heat Orchestration Template’s Resource
OS::ContrailV2::InstanceIp is assigning an IP address to an
internal network (per the
ONAP definition, see Requirements R-52425 and R-46461),
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 internal network
The VNF’s Heat Orchestration Template’s Resource
OS::ContrailV2::InstanceIp property instance_ip_address
map property ip_address parameter
{vm-type}_int_{network-role}_v6_ips
MUST be enumerated in the
VNF’s Heat Orchestration Template’s Environment File.
The VNF’s Heat Orchestration Template’s Resource
OS::ContrailV2::InstanceIp
property instance_ip_address
parameter associated with an 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.
The VNF’s Heat Orchestration Template’s Resource
OS::ContrailV2::InstanceIp
property instance_ip_address
parameter associated with an 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 Added
The VNF’s Heat Orchestration Template’s
resource OS::ContrailV2::InstanceIp property subnet_uuid
parameter
MUST be declared type string.
When the VNF’s Heat Orchestration Template’s
resource OS::ContrailV2::InstanceIp is assigning an IP address
to an external network (per the ONAP definition, see
Requirement R-57424),
and an IPv4 address is being cloud assigned by OpenStack’s DHCP Service
and the 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 network.
The VNF’s Heat Orchestration Template’s Resource
OS::ContrailV2::InstanceIp property subnet_uuid
parameter
{network-role}_subnet_id
MUST NOT be enumerated in the
VNF’s Heat Orchestration Template’s Environment File.
When the VNF’s Heat Orchestration Template’s
resource OS::ContrailV2::InstanceIp is assigning an IP address
to an external network (per the ONAP definition, see
Requirement R-57424),
and an IPv6 address is being cloud assigned by OpenStack’s DHCP Service
and the 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 network.
The VNF’s Heat Orchestration Template’s Resource
OS::ContrailV2::InstanceIp property subnet_uuid
parameter
{network-role}_v6_subnet_id
MUST NOT be enumerated in the
VNF’s Heat Orchestration Template’s Environment File.
When
the VNF’s Heat Orchestration Template’s resource
OS::ContrailV2::InstanceIpin an Incremental Module is assigning an IP address to an internal network (per the ONAP definition, see Requirements R-52425 and R-46461) 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
subnet_uuid,
the parameter MUST follow the naming convention
int_{network-role}_subnet_id
where
{network-role}is the network role of the internal network
Note that the parameter MUST be defined as an output parameter in
the base module.
The VNF’s Heat Orchestration Template’s Resource
OS::ContrailV2::InstanceIp property subnet_uuid
parameter
int_{network-role}_subnet_id
MUST NOT be enumerated in the
VNF’s Heat Orchestration Template’s Environment File.
When
the VNF’s Heat Orchestration Template’s resource
OS::ContrailV2::InstanceIpin an Incremental Module is attaching to an internal network (per the ONAP definition, see Requirements R-52425 and R-46461) that is created in the Base Module, ANDan IPv6 address is being cloud assigned by OpenStack’s DHCP Service AND
the 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 internal network.
Note that the parameter MUST be defined as an output parameter in
the base module.
The VNF’s Heat Orchestration Template’s Resource
OS::ContrailV2::InstanceIp property subnet_uuid
parameter
int_{network-role}_v6_subnet_id
MUST NOT be enumerated in the
VNF’s Heat Orchestration Template’s Environment File.
Monitoring & Management > Data Structure Specification of the Event Record
Requirements Changed
The VNF or PNF provider MUST indicate specific conditions that may arise, and recommend actions that may be taken at specific thresholds, or if specific conditions repeat within a specified time interval, using the semantics and syntax described by the VES Event Registration specification.
The events produced by the VNF or PNF MUST must be compliant with the common event format defined in the VES Event Listener specification.
The VNF or PNF provider MUST provide a YAML file formatted in adherence with the VES Event Registration specification that defines the following information for each event produced by the VNF:
eventNameRequired fields
Optional fields
Any special handling to be performed for that event
The VNF or PNF Provider MAY require that specific events, identified by their
eventName, require that certain fields, which are optional in the common
event format, must be present when they are published.
Monitoring & Management > Event Records - Data Structure Description > Common Event Header
Requirements Changed
The VNF MUST produce VES events that include the following mandatory fields in the common event header.
domain- the event domain enumeration
eventId- the event key unique to the event source
eventName- the unique event name
lastEpochMicrosec- the latest unix time (aka epoch time) associated with the event
priority- the processing priority enumeration
reportingEntityName- name of the entity reporting the event or detecting a problem in another VNF or PNF
sequence- the ordering of events communicated by an event source
sourceName- name of the entity experiencing the event issue, which may be detected and reported by a separate reporting entity
startEpochMicrosec- the earliest unix time (aka epoch time) associated with the event
version- the version of the event header
vesEventListenerVersion- Version of the VES event listener API spec that this event is compliant with
Monitoring & Management > Monitoring & Management Requirements > Addressing and Delivery Protocol
Requirements Changed
The VNF or PNF MUST have the capability of maintaining a primary and backup DNS name (URL) for connecting to ONAP collectors, with the ability to switch between addresses based on conditions defined by policy such as time-outs, and buffering to store messages until they can be delivered. At its discretion, the service provider may choose to populate only one collector address for a VNF or PNF. In this case, the network will promptly resolve connectivity problems caused by a collector or network failure transparently to the VNF or PNF.
The VNF or PNF SHOULD use REST using HTTPS delivery of plain text JSON for moderate sized asynchronous data sets, and for high volume data sets when feasible.
The VNF or PNF MUST be configured with initial address(es) to use at deployment time. Subsequently, address(es) may be changed through ONAP-defined policies delivered from ONAP to the VNF or PNF using PUTs to a RESTful API, in the same manner that other controls over data reporting will be controlled by policy.
The VNF or PNF MAY use another option which is expected to include TCP for high volume streaming asynchronous data sets and for other high volume data sets. TCP delivery can be used for either JSON or binary encoded data sets.
The VNF or PNF MAY use another option which is expected to include SFTP for asynchronous bulk files, such as bulk files that contain large volumes of data collected over a long time interval or data collected across many VNFs or PNFs. (Preferred is to reorganize the data into more frequent or more focused data sets, and deliver these by REST or TCP as appropriate.)
The VNF or PNF MUST, by ONAP Policy, provide the ONAP addresses as data destinations for each VNF or PNF, and may be changed by Policy while the VNF or PNF is in operation. We expect the VNF or PNF to be capable of redirecting traffic to changed destinations with no loss of data, for example from one REST URL to another, or from one TCP host and port to another.
The VNF or PNF MAY use another option which is expected to include REST delivery of binary encoded data sets.
The VNF or PNF MAY use another option which is expected to include REST for synchronous data, using RESTCONF (e.g., for VNF or PNF state polling).
Monitoring & Management > Monitoring & Management Requirements > Asynchronous and Synchronous Data Delivery
Requirements Changed
The VNF or PNF MUST must encode, address and deliver the data as described in the previous paragraphs.
The VNF or PNF MUST deliver asynchronous data as data becomes available, or according to the configured frequency.
The VNF or PNF MUST use the YANG configuration models and RESTCONF [RFC8040] (https://tools.ietf.org/html/rfc8040).
The VNF or PNF MUST respond to an ONAP request to deliver the current data for any of the record types defined in `Event Records - Data Structure Description`_ by returning the requested record, populated with the current field values. (Currently the defined record types include fault fields, mobile flow fields, measurements for VNF or PNF scaling fields, and syslog fields. Other record types will be added in the future as they become standardized and are made available.)
The VNF or PNF MUST use the RESTCONF/NETCONF framework used by the ONAP configuration subsystem for synchronous communication.
The VNF or PNF SHOULD deliver all syslog messages to the VES Collector per the specifications in Monitoring and Management chapter.
The VNF or PNF MUST respond to an ONAP request to deliver granular data on device or subsystem status or performance, referencing the YANG configuration model for the VNF or PNF by returning the requested data elements.
The VNF or PNF MUST respond to data requests from ONAP as soon as those requests are received, as a synchronous response.
The VNF or PNF MUST respond with content encoded in JSON, as described in the RESTCONF specification. This way the encoding of a synchronous communication will be consistent with Avro.
The VNF or PNF SHOULD use Modeling JSON text with YANG, If YANG models need to be translated to and from JSON{RFC7951]. YANG configuration and content can be represented via JSON, consistent with Avro, as described in “Encoding and Serialization” section.
Monitoring & Management > Monitoring & Management Requirements > Bulk Performance Measurement
Requirements Added
The VNF or PNF SHOULD report the files in FileReady for as long as they are available at VNF or PNF.
Note: Recommended period is at least 24 hours.
Requirements Changed
The VNF or PNF SHOULD support FileReady VES event for event-driven bulk transfer of monitoring data.
The VNF or PNF SHOULD support File transferring protocol, such as FTPES or SFTP, when supporting the event-driven bulk transfer of monitoring data.
The VNF or PNF SHOULD support the data schema defined in 3GPP TS 32.435, when supporting the event-driven bulk transfer of monitoring data.
Monitoring & Management > Monitoring & Management Requirements > Google Protocol Buffers (GPB)
Requirements Changed
The VNF or PNF, when leveraging Google Protocol Buffers for events, MUST serialize the events using native Google Protocol Buffers (GPB) according to the following guidelines:
The keys are represented as integers pointing to the system resources for the VNF or PNF being monitored
The values correspond to integers or strings that identify the operational state of the VNF resource, such a statistics counters and the state of an VNF or PNF resource.
The required Google Protocol Buffers (GPB) metadata is provided in the form of .proto files.
The VNF or PNF providers MUST provide the Service Provider the following artifacts to support the delivery of high-volume VNF or PNF telemetry to DCAE via GPB over TLS/TCP:
A valid VES Event .proto definition file, to be used validate and decode an event
A valid high volume measurement .proto definition file, to be used for processing high volume events
A supporting PM content metadata file to be used by analytics applications to process high volume measurement events
Monitoring & Management > Monitoring & Management Requirements > JSON
Requirements Changed
Monitoring & Management > Monitoring & Management Requirements > Reporting Frequency
Requirements Changed
The VNF or PNF MUST vary the frequency that asynchronous data is delivered based on the content and how data may be aggregated or grouped together.
Note:
For example, alarms and alerts are expected to be delivered as soon as they appear. In contrast, other content, such as performance measurements, KPIs or reported network signaling may have various ways of packaging and delivering content. Some content should be streamed immediately; or content may be monitored over a time interval, then packaged as collection of records and delivered as block; or data may be collected until a package of a certain size has been collected; or content may be summarized statistically over a time interval, or computed as a KPI, with the summary or KPI being delivered.
We expect the reporting frequency to be configurable depending on the virtual network functions needs for management. For example, Service Provider may choose to vary the frequency of collection between normal and trouble-shooting scenarios.
Decisions about the frequency of data reporting will affect the size of delivered data sets, recommended delivery method, and how the data will be interpreted by ONAP. These considerations should not affect deserialization and decoding of the data, which will be guided by the accompanying JSON schema or GPB definition files.
The VNF or PNF MUST report exactly one Measurement event per period per source name.
Monitoring & Management > Monitoring & Management Requirements > Security
Requirements Changed
The VNF or PNF MUST support secure connections and transports such as Transport Layer Security (TLS) protocol [RFC5246] and should adhere to the best current practices outlined in RFC7525.
The VNF or PNF MUST control access to ONAP and to VNFs or PNFs, and creation of connections, through secure credentials, log-on and exchange mechanisms.
When the VNF or PNF sets up a HTTP or HTTPS connection to the collector, it MUST provide a username and password to the DCAE VES Collector for HTTP Basic Authentication.
Note: HTTP Basic Authentication has 4 steps: Request, Authenticate, Authorization with Username/Password Credentials, and Authentication Status as per RFC7617 and RFC 2617.
The VNF or PNF MUST support the provisioning of security and authentication parameters (HTTP username and password) in order to be able to authenticate with DCAE (in ONAP).
Note: In R3, a username and password are used with the DCAE VES Event Listener which are used for HTTP Basic Authentication.
Note: The configuration management and provisioning software are specific to a vendor architecture.
The VNF or PNF MUST encrypt any content containing Sensitive Personal Information (SPI) or certain proprietary data, in addition to applying the regular procedures for securing access and delivery.
The VNF or PNF MUST carry data in motion only over secure connections.
Monitoring & Management > Monitoring & Management Requirements > VNF telemetry via standardized interface
Requirements Changed
The VNF or PNF MUST produce heartbeat indicators consisting of events containing the common event header only per the VES Listener Specification.
Monitoring & Management > Transports and Protocols Supporting Resource Interfaces
Requirements Changed
The VNF or PNF MUST deliver event records to ONAP using the common transport mechanisms and protocols defined in this specification.
The VNF or PNF SHOULD deliver event records that fall into the event domains supported by VES.
The VNF or PNF provider MUST reach agreement with the Service Provider on the selected methods for encoding, serialization and data delivery prior to the on-boarding of the VNF or PNF into ONAP SDC Design Studio.
Monitoring & Management > Transports and Protocols Supporting Resource Interfaces > Bulk Telemetry Transmission
Requirements Changed
The VNF or PNF MAY leverage bulk VNF or PNF telemetry transmission mechanism, as depicted in Figure 4, in instances where other transmission methods are not practical or advisable.
Monitoring & Management > Transports and Protocols Supporting Resource Interfaces > VNF or PNF Telemetry using Google Protocol Buffers
Requirements Changed
The VNF or PNF MAY leverage the Google Protocol Buffers (GPB) delivery model depicted in Figure 3 to support real-time performance management (PM) data. In this model the VES events are streamed as binary-encoded GBPs over via TCP sockets.
Monitoring & Management > Transports and Protocols Supporting Resource Interfaces > VNF or PNF Telemetry using VES/JSON Model
Requirements Changed
The VNF or PNF SHOULD leverage the JSON-driven model, as depicted in Figure 2, for data delivery unless there are specific performance or operational concerns agreed upon by the Service Provider that would warrant using an alternate model.
ONAP Heat Heat Template Constructs > Heat Files Support (get_file)
Requirements Removed
R-87848
When using the intrinsic function get_file, ONAP does not support
a directory hierarchy for included files. All files must be in a
single, flat directory per VNF. A VNF’s Heat Orchestration
Template’s get_file target files MUST be in the same
directory hierarchy as the VNF’s Heat Orchestration Templates.
ONAP Heat Heat Template Constructs > Key Pairs
Requirements Added
If a VNF requires the use of an SSH key created by OpenStack, the VNF
Heat Orchestration Template SHOULD create the OS::Nova::Keypair
in the base module, and expose the public key as an output value.
This allows re-use of the key by ONAP when triggering scale out, recovery, or other day 1 operations.
ONAP Heat Heat Template Constructs > Nested Heat Templates > Nested Heat Template Requirements
Requirements Added
If a VNF’s Heat Orchestration Template’s resource invokes a nested
YAML file, either statically or dynamically
(via OS::Heat::ResourceGroup),
the names of the parameters associated with the following resource
properties MUST NOT change.
OS::Nova::ServerpropertyflavorOS::Nova::ServerpropertyimageOS::Nova::ServerpropertynameOS::Nova::Serverproperty metadata key valuevnf_idOS::Nova::Serverproperty metadata key valuevf_module_idOS::Nova::Serverproperty metadata key valuevnf_nameOS::Nova::Serverproperty metadata key valuevf_module_nameOS::Nova::Serverproperty metadata key valuevm_roleOS::Nova::Serverproperty metadata key valuevf_module_indexOS::Nova::Serverproperty metadata key valueworkload_contextOS::Nova::Serverproperty metadata key valueenvironment_contextOS::Neutron::Portpropertyfixed_ips, map propertyip_addressOS::Neutron::Portpropertyfixed_ips, map propertysubnetOS::Neutron::Portpropertyallowed_address_pairs, map propertyip_addressOS::Neutron::PortpropertynetworkOS::ContrailV2::VirtualMachineInterfacepropertyvirtual_network_refsOS::ContrailV2::VirtualMachineInterfacepropertyvirtual_machine_interface_allowed_address_pairs, map propertyvirtual_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_prefixOS::ContrailV2::InstanceIPpropertyinstance_ip_addressOS::ContrailV2::InstanceIPpropertysubnet_uuid
Requirements Removed
R-52530
A VNF’s Heat Orchestration Template’s Nested YAML file MUST be in the same directory hierarchy as the VNF’s Heat Orchestration Templates.
R-70112
A VNF’s Heat Orchestration Template MUST reference a Nested YAML
file by name. The use of resource_registry in the VNF’s Heat
Orchestration Templates Environment File MUST NOT be used.
ONAP Heat Networking > External Networks
Requirements Removed
R-83015
A VNF’s {network-role} assigned to an external network MUST
be different than the {network-role} assigned to the VNF’s
internal networks, if internal networks exist.
ONAP Heat Networking > Internal Networks
Requirements Changed
If a VNF has an internal network, the VNF Heat Orchestration Template MUST include the heat resources to create the internal network.
A VNF’s Internal Network is created using Neutron Heat Resources
(i.e., OS::Neutron::Net, OS::Neutron::Subnet) and/or
Contrail Heat Resources (i.e., OS::ContrailV2::VirtualNetwork,
ContrailV2::NetworkIpam).
When a VNF’s Heat Orchestration Template creates an internal network (per the ONAP definition, see Requirements R-52425 and R-46461 and R-35666) and the internal network needs to be shared between modules within a VNF, the 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_idIf 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
{network-role} MUST be the network-role of the 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 internal network.
Requirements Removed
R-32025
When a VNF creates two or more internal networks, each internal
network MUST be assigned a unique {network-role} in the context
of the VNF for use in the VNF’s Heat Orchestration Template.
R-68936
When a VNF creates an internal network, a network role, referred to as
the {network-role} MUST be assigned to the internal network
for use in the VNF’s Heat Orchestration Template.
R-69874
A VNF’s {network-role} assigned to an internal network MUST
be different than the {network-role} assigned to the VNF’s external
networks.
ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > parameters > constraints
Requirements Changed
A VNF’s Heat Orchestration Template’s parameter defined in a nested YAML file SHOULD NOT have a parameter constraint defined.
A VNF’s Heat Orchestration Template’s parameter defined
in a non-nested YAML file as type
number MAY have a parameter constraint defined.
ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > resources > properties
Requirements Changed
A VNF’s Heat Orchestration Template resource attribute property:
MUST NOT use more than two levels of nested get_param intrinsic
functions when deriving a property value. SDC does not support nested
get_param with recursive lists (i.e., a list inside list).
The second get_param in a nested lookup must directly derive its value
without further calls to get_param functions.
Example of valid nesting:
name: {get_param: [ {vm-type}_names, {get_param : index } ] }
Examples of invalid nesting. SDC will not support these examples since there is an array inside array.
name: {get_param: [ {vm-type}_names, { get_param: [ indexlist, 0 ] } ] }name: {get_param: [ {vm-type}_names, { get_param: [ indexlist1, { get_param: indexlist2 } ] } ] }
ONAP Heat Orchestration Templates Overview > ONAP Heat Orchestration Template Filenames > Base Modules
Requirements Changed
A VNF Heat Orchestration Template’s Base Module file name MUST include case insensitive ‘base’ in the filename and MUST match one of the following four formats:
1.)
base_<text>.y[a]ml2.)
<text>_base.y[a]ml3.)
base.y[a]ml4.)
<text>_base_<text>.y[a]ml
where <text> MUST contain only alphanumeric characters and
underscores ‘_’ and MUST NOT contain the case insensitive string
base or volume.
ONAP Heat Orchestration Templates Overview > ONAP Heat Orchestration Template Filenames > Cinder Volume Modules
Requirements Added
A VNF Heat Orchestration Template’s Cinder Volume Module resources:
section
MUST only be defined using one of the following:
one of more
OS::Cinder::Volumeresourcesone or more
OS::Heat::ResourceGroupresources that call a nested YAML file that contains onlyOS::Cinder::Volumeresourcesa resource that calls a nested YAML file (static nesting) that contains only
OS::Cinder::Volumeresources
ONAP Heat Orchestration Templates Overview > ONAP Heat Orchestration Template Filenames > Incremental Modules
Requirements Changed
VNF Heat Orchestration Template’s Incremental Module file name
MUST contain only alphanumeric characters and underscores
‘_’ and MUST NOT contain the case insensitive string base.
ONAP Heat Orchestration Templates Overview > ONAP Heat Orchestration Template Filenames > Nested Heat file
Requirements Changed
VNF Heat Orchestration Template’s Nested YAML file name MUST contain
only alphanumeric characters and underscores ‘_’ and
MUST NOT contain the case insensitive string base.
ONAP Heat Orchestration Templates Overview > ONAP VNF Modularity Overview
Requirements Changed
A VNF’s Heat Orchestration Template’s Resource OS::Cinder::Volume
MAY be defined in an Incremental Module.
A VNF’s Heat Orchestration Template’s Resource OS::Cinder::Volume
MAY be defined in a Cinder Volume Module.
A VNF’s Heat Orchestration Template’s Resource OS::Cinder::Volume
MAY be defined in a Base Module.
Requirements Removed
R-20974
At orchestration time, the VNF’s Base Module MUST be deployed first, prior to any incremental modules.
ONAP Heat Orchestration Templates Overview > ONAP VNF On-Boarding
Requirements Added
The VNF’s Heat Orchestration Template’s ZIP file MUST NOT include a binary image file.
When a VNF’s Heat Orchestration Template is ready to be on-boarded to ONAP, all files composing the VNF Heat Orchestration Template MUST be placed in a flat (i.e., non-hierarchical) directory and archived using ZIP. The resulting ZIP file is uploaded into ONAP.
ONAP Heat Orchestration Templates Overview > Output Parameters > ONAP Base Module Output Parameters
Requirements Changed
VNF’s Heat Orchestration Template’s Base Module’s output parameter’s name and type MUST match the VNF’s Heat Orchestration Template’s incremental Module’s name and type.
When a VNF’s Heat Orchestration Template’s Base Module’s output
parameter is declared as an input parameter in an Incremental Module,
the parameter attribute constraints: SHOULD NOT be declared.
ONAP Heat Orchestration Templates Overview > Output Parameters > ONAP Volume Module Output Parameters
Requirements Changed
When an ONAP Volume Module Output Parameter is declared as an input parameter in a base or an incremental module Heat Orchestration Template, parameter constraints SHOULD NOT be declared.
A VNF’s Heat Orchestration Templates’ Cinder Volume Module Output Parameter’s name and type MUST match the input parameter name and type in the corresponding Base Module or Incremental Module.
A VNF’s Heat Orchestration Template’s Cinder Volume Module Output Parameter(s) MUST include the UUID(s) of the Cinder Volumes created in template.
ONAP Heat Support of Environment Files
Requirements Added
A parameter enumerated in a
VNF’s Heat Orchestration Template’s environment file MUST be declared
in the
corresponding VNF’s Heat Orchestration Template’s YAML file’s
parameters: section.
ONAP Heat VNF Modularity
Requirements Changed
A shared Heat Orchestration Template resource is a resource that MUST be defined in the base module and will be referenced by one or more resources in one or more incremental modules.
The UUID of the shared resource (created in the base module) MUST be
exposed by declaring a parameter in the
outputs section of the base module.
For ONAP to provided the UUID value of the shared resource to the
incremental module, the parameter name defined in the outputs
section of the base module MUST be defined as a parameter
in the parameters section of the incremental module.
ONAP will capture the output parameter name and value in the base module and provide the value to the corresponding parameter(s) in the incremental module(s).
ONAP TOSCA VNFD Requirements > VNF CSAR Package > VNF Package Contents
Requirements Removed
R-26885
The VNF provider MUST provide the binaries and images needed to instantiate the VNF (VNF and VNFC images) either as:
Local artifact in CSAR: ROOT\Artifacts\ VNF_Image.bin
externally referred (by URI) artifact in Manifest file (also may be referred by VNF Descriptor)
Note: Currently, ONAP doesn’t have the capability of Image management, we upload the image into VIM/VNFM manually.
ONAP TOSCA VNFD or PNFD Requirements > TOSCA PNF Descriptor > Capability Types
Requirements Added
The PNFD provided by a PNF vendor MUST comply with the following Capabilities Types as specified in ETSI NFV-SOL001 standard:
tosca.datatypes.nfv.VirtualLinkable
ONAP TOSCA VNFD or PNFD Requirements > TOSCA PNF Descriptor > Data Types
Requirements Added
The PNFD provided by a PNF vendor MUST comply with the following Data Types as specified in ETSI NFV-SOL001 standard:
tosca.datatypes.nfv.CpProtocolData
tosca.datatypes.nfv.AddressData
tosca.datatypes.nfv.L2AddressData
tosca.datatypes.nfv.L3AddressData
tosca.datatypes.nfv.LocationInfo
tosca.datatypes.nfv.CivicAddressElement
ONAP TOSCA VNFD or PNFD Requirements > TOSCA PNF Descriptor > General
Requirements Added
The PNF Descriptor (PNFD) provided by PNF vendor MUST comply with TOSCA/YAML based Service template for PNF descriptor specified in ETSI NFV-SOL001.
ONAP TOSCA VNFD or PNFD Requirements > TOSCA PNF Descriptor > Node Types
Requirements Added
The PNFD provided by a PNF vendor MUST comply with the following Node Types as specified in ETSI NFV-SOL001 standard:
tosca.nodes.nfv.PNF
tosca.nodes.nfv.PnfExtCp
tosca.nodes.nfv.Cp
ONAP TOSCA VNFD or PNFD Requirements > TOSCA PNF Descriptor > Policy Types
Requirements Added
The PNFD provided by a PNF vendor MUST comply with the following Policy Types as specified in ETSI NFV-SOL001 standard:
tosca.datatypes.nfv.SecurityGroupRule
ONAP TOSCA VNFD or PNFD Requirements > TOSCA PNF Descriptor > Relationship Types
Requirements Added
The PNFD provided by a PNF vendor MUST comply with the following Relationship Types as specified in ETSI NFV-SOL001 standard:
tosca.datatypes.nfv.VirtualLinksTo
ONAP TOSCA VNFD or PNFD Requirements > TOSCA VNF Descriptor > General
Requirements Changed
The VNFD MUST comply with ETSI GS NFV-SOL001 specification endorsing the above mentioned NFV Profile and maintaining the gaps with the requirements specified in ETSI GS NFV-IFA011 standard.
ONAP TOSCA VNFD or PNFD Requirements > VNF or PNF CSAR Package > VNF Package Contents
Requirements Added
If one or more non-MANO artifact(s) is included in the VNF or PNF TOSCA CSAR package, the Manifest file in this CSAR package MUST contain: non-MANO artifact set which MAY contain following ONAP public tag.
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_others: contains any other non_MANO artifacts, e.g. informational documents
The VNF or PNF package MUST contain a 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 VNF or PNF CSAR PACKAGE with TOSCA-Metadata MUST include following additional keywords pointing to TOSCA files:
ETSI-Entry-Manifest
ETSI-Entry-Change-Log
Note: For a CSAR containing a TOSCA-Metadata directory, which includes the TOSCA.meta metadata file. The TOSCA.meta metadata file includes block_0 with the Entry-Definitions keyword pointing to a TOSCA definitions YAML file used as entry for parsing the contents of the overall CSAR archive.
The PNF TOSCA 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
The VNF TOSCA 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
Requirements Changed
The VNF or PNF CSAR package MUST include all artifacts required by ETSI GS NFV-SOL004 including Manifest file, VNFD or PNFD (or Main TOSCA/YAML based Service Template) and other optional artifacts.
The VNF or PNF TOSCA 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 or PNF 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, an algorithm to calculate a digest and a digest result calculated on the content of each artifacts, as specified in ETSI GS NFV-SOL004.
ONAP TOSCA VNFD or PNFD Requirements > VNF or PNF CSAR Package > VNF Package Structure and Format
Requirements Added
The VNF or PNF TOSCA CSAR file MUST be a zip file with .csar extension.
Requirements Changed
The VNF or PNF CSAR package MUST be arranged as a CSAR archive as specified in TOSCA Simple Profile in YAML 1.2.
The VNF or PNF 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.
ONAP TOSCA VNFD or PNFD Requirements > VNF or PNF CSAR Package > VNF or PNF Package Authenticity and Integrity
Requirements Added
If the VNF or PNF CSAR Package utilizes Option 2 for package security, then the complete CSAR file MUST contain a Digest (a.k.a. hash) for each of the components of the VNF or PNF package. The table of hashes is included in the package manifest file, which is signed with the VNF or PNF provider private key. In addition, the VNF or PNF provider MUST include a signing certificate that includes the VNF or PNF provider public key, following a TOSCA pre-defined naming convention and located either at the root of the archive or in a predefined location specified by the TOSCA.meta file with the corresponding entry named “ETSI-Entry-Certificate”.
If the VNF or PNF CSAR Package utilizes Option 2 for package security, then the complete CSAR file MUST be digitally signed with the VNF or PNF provider private key. The VNF or PNF provider delivers one zip file consisting of the CSAR file, a signature file and a certificate file that includes the VNF or PNF provider public key. The certificate may also be included in the signature container, if the signature format allows that. The VNF or PNF provider creates a zip file consisting of the CSAR file with .csar extension, signature and certificate files. The signature and certificate files must be siblings of the CSAR file with extensions .cms and .cert respectively.
PNF Plug and Play > PNF Plug and Play
Requirements Changed
The PNF MUST support one of the protocols for a Service Configuration message exchange between the PNF and PNF Controller (in ONAP): a) Netconf/YANG, b) Chef, or c) Ansible.
Note: The PNF Controller may be VF-C, APP-C or SDN-C based on the PNF and PNF domain.
The following VES Events SHOULD be supported by the PNF: pnfRegistration VES Event, HVol VES Event, and Fault VES Event. These are onboarded via he SDC Design Studio.
Note: these VES Events are emitted from the PNF to support PNF Plug and Play, High Volume Measurements, and Fault events respectively.
Resource IDs
Requirements Changed
When a VNF’s Heat Orchestration Template’s Resource ID contains an
{index}, the {index} is a numeric value that MUST start at
zero and MUST increment by one.
As stated in R-16447,
a VNF’s <resource ID> MUST be unique across all Heat
Orchestration Templates and all HEAT Orchestration Template
Nested YAML files that are used to create the VNF. While the {index}
will start at zero in the VNF, the {index} may not start at zero
in a given Heat Orchestration Template or HEAT Orchestration Template
Nested YAML file.
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 external network
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 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.IPsignifies 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 internal network
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 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_IPsignifies 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 internal network
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 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.IPsignifies 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 external network
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 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_IPsignifies 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.
Requirements Removed
R-20947
A VNF’s Heat Orchestration Template’s Resource OS::ContrailV2::InstanceIp
that is configuring an IPv4 Address on a sub-interface port attached to a
sub-interface network Resource ID MUST use the naming convention
{vm-type}_{vm-type_index}_subint_{network-role}_vmi_{vmi_index}_IP_{index}
where
{vm-type}is the vm-type{vm-type_index}is the instance of the{vm-type}{network-role}is the network-role of the network that the port is attached to{vmi_index}is the instance of the the virtual machine interface (e.g., port) on the vm-type attached to the network of{network-role}IPsignifies that an IPv4 address is being configured{index}is the index of the IPv4 address
R-88540
A VNF’s Heat Orchestration Template’s Resource OS::ContrailV2::InstanceIp
that is configuring an IPv6 Address on a sub-interface port attached to a
sub-interface network Resource ID MUST
use the naming convention
{vm-type}_{vm-type_index}_subint_{network-role}_vmi_{vmi_index}_v6_IP_{index}
where
{vm-type}is the vm-type{vm-type_index}is the instance of the{vm-type}{network-role}is the network-role of the network that the port is attached to{vmi_index}is the instance of the the virtual machine interface (e.g., port) on the vm-type attached to the network of{network-role}v6_IPsignifies that an IPv6 address is being configured{index}is the index of the IPv6 address
Resource IDs > Contrail Heat Resources Resource ID Naming Convention > OS::ContrailV2::ServiceTemplate
Requirements Changed
A VNF’s Heat Orchestration Template’s Resource OS::ContrailV2::ServiceTemplate
Resource ID MAY use the naming convention
{vm-type}_RST_{index}
where
{vm-type}is the vm-typeRSTsignifies that it is the Resource Service Template{index}is the index. The{index}starts at zero and increments by one (as described in R-11690).
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 internal network
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 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 external network
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 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.
Requirements Removed
R-54458
A VNF’s Heat Orchestration Template’s Resource
OS::ContrailV2::VirtualMachineInterface that is attaching to a sub-interface
network Resource ID MUST use the naming convention
{vm-type}_{vm-type_index}_subint_{network-role}_vmi_{vmi_index}
where
{vm-type}is the vm-type{vm-type_index}is the instance of the{vm-type}{network-role}is the network-role of the network that the port (i.e. virtual machine interface) is attached to{vmi_index}is the instance of the the vmi on the vm-type attached to the network of{network-role}
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 internal networks.
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::Cinder::Volume
Requirements Changed
A VNF’s Heat Orchestration Template’s Resource
OS::Cinder::Volume
Resource ID
SHOULD
use the naming convention
{vm-type}_volume_{index}
where
{vm-type}is the vm-type{index}starts at zero and increments by one (as described in R-11690)
Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Cinder::VolumeAttachment
Requirements Changed
A VNF’s Heat Orchestration Template’s Resource
OS::Cinder::VolumeAttachment
Resource ID
SHOULD
use the naming convention
{vm-type}_volume_attachment_{index}
where
{vm-type}is the vm-type{index}starts at zero and increments by one (as described in R-11690)
Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Heat::ResourceGroup
Requirements Removed
R-64197
A VNF’s Heat Orchestration Template’s Resource OS::Heat::ResourceGroup
Resource ID that creates sub-interfaces MUST use the naming convention
{vm-type}_{vm-type_index}_subint_{network-role}_port_{port-index}_subinterfaces
where
{vm-type}is the vm-type{vm-type_index}is the instance of the{vm-type}{network-role}is the network-role of the networks that the sub-interfaces attach to{port-index}is the instance of the the port on the vm-type attached to the network of{network-role}
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 creating a Reserve Port with an IPv6 address 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 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 creating a Reserve Port with an IPv4 address 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 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).
A VNF’s Heat Orchestration Template’s Resource OS::Neutron::Port
that is attaching to an internal network 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 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 attaching to an external network 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 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.
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{index}is the{index}of the subnet of the 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 applies to
one {vm-type} Resource ID SHOULD use the naming convention
{vm-type}_keypair_{index}
where
{network-role}is the network-role{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 applies to
all Virtual Machines in the VNF, the Resource ID SHOULD use the naming
convention
{vnf-type}_keypair
where
{vnf-type}describes the VNF
Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Nova::Server
Requirements Changed
A VNF’s Heat Orchestration Template’s Resource OS::Nova::Server
Resource ID
MUST use the naming convention
{vm-type}_server_{index}
where
{vm-type}is the vm-type{index}is the index. The{index}MUST starts at zero and increment by one as described in R-11690.
Resource Property “name”
Requirements Changed
If a VNF’s Heat Orchestration Template contains the property name
for a non OS::Nova::Server resource, the intrinsic function
str_replace MUST be used in conjunction with the ONAP
supplied metadata parameter vnf_name to generate a unique value.
Additional data MAY be used in the str_replace construct
to generate a unique value.
Requirements Removed
R-32408
If a VNF’s Heat Orchestration Template property name
for a non OS::Nova::Server resource uses the intrinsic function
str_replace in conjunction with the ONAP
supplied metadata parameter vnf_name and does not create
a unique value, additional data MUST be used in the
str_replace to create a unique value, such as OS::stack_name
and/or the OS::Heat::ResourceGroup index.
Resource: OS::Neutron::Port - Parameters > Introduction > Items to Note
Requirements Added
A VNF’s Heat Orchestration Template’s OS::Neutron::Port resource’s
Resource ID (defined in R-20453)
property
networkparameter name (defined in R-62983 and R-86182)property
fixed_ips, map propertyip_addressparameter name (defined in R-40971, R-04697, R-71577, R-23503, R-78380, R-85235, R-27818, and R-29765)property
fixed_ips, map propertysubnetparameter name (defined in R-62802, R-15287, R-84123, R-76160)property
allowed_address_pairsparameter name (defined in R-41492 and R-83418)
MUST contain the identical {network-role}.
Requirements Removed
R-07577
If the VNF’s ports connected to a unique network (internal or external) and the port’s IP addresses are cloud assigned IP Addresses, all the IPv4 Addresses MUST be from the same subnet and all the IPv6 Addresses MUST be from the same subnet.
R-13841
A VNF MAY have one or more ports connected to a unique internal network. All VNF ports connected to the unique internal network MUST have cloud assigned IP Addresses or MUST have statically assigned IP addresses.
R-93272
A VNF MAY have one or more ports connected to a unique external network. All VNF ports connected to the unique external network MUST have cloud assigned IP Addresses or MUST have ONAP SDN-C assigned IP addresses.
Resource: OS::Neutron::Port - Parameters > Property: allowed_address_pairs, Map Property: ip_address
Requirements Removed
R-62300
If a VNF has two or more ports that require a Virtual IP Address (VIP),
a VNF’s Heat Orchestration Template’s Resource
OS::Neutron::Port property allowed_address_pairs
map property ip_address parameter
MUST be used.
Resource: OS::Neutron::Port - Parameters > Property: allowed_address_pairs, Map Property: ip_address > VIP Assignment, External Networks
Requirements Added
When the VNF’s Heat Orchestration Template’s resource
OS::Neutron::Port is attaching to an external network
(per the ONAP definition, see Requirement R-57424),
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
stringor 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.
Requirements Changed
When the VNF’s Heat Orchestration Template’s resource
OS::Neutron::Port is attaching to an external network
(per the ONAP definition, see Requirement R-57424),
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 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.
If a VNF’s Heat Orchestration Template’s resource
OS::Neutron::Port is attaching to an external network (per the
ONAP definition, see Requirement R-57424), 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 external network
(per the ONAP definition, see Requirement R-57424),
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 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.
Resource: OS::Neutron::Port - Parameters > Property: allowed_address_pairs, Map Property: ip_address > VIP Assignment, External Networks, Supported by Automation
Requirements Removed
R-10754
If a VNF has two or more ports that attach to an external network that require a Virtual IP Address (VIP), and the VNF requires ONAP automation to assign the IP address, all the Virtual Machines using the VIP address MUST be instantiated in the same Base Module Heat Orchestration Template or in the same Incremental Module Heat Orchestration Template.
R-41956
If a VNF requires ONAP to assign a Virtual IP (VIP) Address to ports connected an external network, the port MUST NOT have more than one IPv6 VIP address.
R-83418
The VNF’s Heat Orchestration Template’s Resource
OS::Neutron::Port property allowed_address_pairs
map property ip_address parameter
{vm-type}_{network-role}_floating_v6_ip
MUST NOT be enumerated in the
VNF’s Heat Orchestration Template’s Environment File.
R-91810
If a VNF requires ONAP to assign a Virtual IP (VIP) Address to ports connected an external network, the port MUST NOT have more than one IPv4 VIP address.
R-98748
The VNF’s Heat Orchestration Template’s Resource
OS::Neutron::Port property allowed_address_pairs
map property ip_address parameter
MUST be declared as type string.
Resource: OS::Neutron::Port - Parameters > Property: allowed_address_pairs, Map Property: ip_address > VIP Assignment, Internal Networks
Requirements Added
When the VNF’s Heat Orchestration Template’s Resource
OS::Neutron::Port is attaching to an internal network (per the
ONAP definition, see Requirements R-52425 and R-46461),
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 external 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 external 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 internal network (per the
ONAP definition, see Requirements R-52425 and R-46461),
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 external 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 external 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 internal network (per the
ONAP definition, see Requirements R-52425 and R-46461),
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 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 external network (per the
ONAP definition, see Requirement R-57424),
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 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 external network (per the
ONAP definition, see Requirement R-57424),
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 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 internal network (per the
ONAP definition, see Requirements R-52425 and R-46461),
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 internal network{index}is a numeric value that MUST start at zero in a VNF’s Heat Orchestration Template and MUST increment by one
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 internal network (per the
ONAP definition, see Requirements R-52425 and R-46461),
the network parameter name MUST
follow the naming convention
int_{network-role}_net_idif the network UUID value is used to reference the networkfollow the naming convention
int_{network-role}_net_nameif the network name in is used to reference the network.
where {network-role} is the network-role of the internal network and
a get_param MUST be used as the intrinsic function.
Requirements Removed
R-93177
When the VNF’s Heat Orchestration Template’s resource
OS::Neutron::Port is attaching to an internal network (per the
ONAP definition, see Requirements R-52425 and R-46461),
and the internal network is created in the
same Heat Orchestration Template as the OS::Neutron::Port,
the network property value MUST obtain the UUID
of the internal network by using the intrinsic function
get_resource
and referencing the Resource ID of the internal network.
Resource: OS::Nova::Server - Parameters
Requirements Changed
A VNF’s Heat Orchestration Template’s OS::Nova::Server resource’s
Resource ID (defined in R-29751)
property
imageparameter name (defined in R-58670)property
flavorparameter name (defined in R-45188)property
nameparameter name (defined in R-54171 & R-87817)property
networksmap propertyportvalue which is aOS::Neutron::PortResource ID (defined in R-20453) referenced using the intrinsic functionget_attr
MUST contain the identical {vm-type}
and MUST follow the naming conventions defined
in R-58670, R-45188, R-54171, R-87817, and R-29751. And the {index} in
the OS::Nova::Server Resource ID (defined in R-29751) MUST match
the {vm-type_index} defined in
the OS::Nova::Server property networks map property port
referenced OS::Neutron::Port Resource ID (defined in R-20453).
Resource: OS::Nova::Server - Parameters > Property: Name
Requirements Changed
When the VNF’s Heat Orchestration Template’s Resource OS::Nova::Server
property name parameter is defined as a string,
the parameter name MUST follow the naming convention
{vm-type}_name_{index}
where {index} is a numeric value that MUST start at
zero in a VNF’s Heat Orchestration Template and MUST increment by one.
Requirements Removed
R-40899
When the VNF’s Heat Orchestration Template’s Resource OS::Nova::Server
property name parameter is defined as a string, a parameter
MUST be delcared for
each OS::Nova::Server resource associated with the {vm-type}.
R-85800
When the VNF’s Heat Orchestration Template’s Resource OS::Nova::Server
property name parameter is defined as a comma_delimited_list,
a parameter MUST be delcared once for all OS::Nova::Server resources
associated with the {vm-type}.
Resource: OS::Nova::Server - Parameters > Property: availability_zone
Requirements Changed
The VNF’s Heat Orchestration Template’s Resource OS::Nova::Server
property availability_zone parameter name
MUST follow the naming convention
availability_zone_{index}
where {index} is a numeric value that MUST start at zero
in a VNF’s Heat Orchestration Templates and MUST
increment by one.
Resource: OS::Nova::Server Metadata Parameters > environment_context
Requirements Removed
R-62954
If a VNF’s Heat Orchestration Template’s OS::Nova::Server Resource
metadata map value parameter environment_context is passed into a
Nested YAML
file, the parameter name environment_context MUST NOT change.
Resource: OS::Nova::Server Metadata Parameters > vf_module_id
Requirements Removed
R-86237
If a VNF’s Heat Orchestration Template’s OS::Nova::Server resource
property
metadata key/value pair vf_module_id is passed into a
Nested YAML
file, the key/value pair name vf_module_id MUST NOT change.
Resource: OS::Nova::Server Metadata Parameters > vf_module_index
Requirements Added
A VNF’s Heat Orchestration Template’s OS::Nova::Server
resource property metadata MAY
contain the key/value pair vf_module_index.
Requirements Changed
A VNF’s Heat Orchestration Template’s OS::Nova::Server
resource property metadata
key/value pair vf_module_index
value MUST be obtained via a get_param.
Requirements Removed
R-22441
If a VNF’s Heat Orchestration Template’s OS::Nova::Server resource
property metadata key/value pair vf_module_index is passed into a
Nested YAML file, the key/value pair
vf_module_index MUST NOT change.
Resource: OS::Nova::Server Metadata Parameters > vf_module_name
Requirements Added
A VNF’s Heat Orchestration Template’s OS::Nova::Server resource
property metadata SHOULD contain the key/value pair vf_module_name.
Requirements Changed
A VNF’s Heat Orchestration Template’s OS::Nova::Server resource
property metadata key/value pair vf_module_name
value MUST
be obtained via a get_param.
Requirements Removed
R-49177
If a VNF’s Heat Orchestration Template’s OS::Nova::Server resource
property metadata key/value pair vf_module_name is passed into a
Nested YAML
file, the key/value pair name vf_module_name MUST NOT change.
Resource: OS::Nova::Server Metadata Parameters > vm_role
Requirements Changed
If a VNF’s Heat Orchestration Template’s OS::Nova::Server
resource property
metadata key/value pair vm_role value is obtained via
get_param, the parameter MAY be declared as
vm_roleand the parameter defined astype: string.vm_rolesand the parameter defined astype: comma_delimited_list.{vm-type}_vm_roleand the parameter defined astype: string.
Requirements Removed
R-70757
If a VNF’s Heat Orchestration Template’s OS::Nova::Server resource
property metadata key/value pair vm_role is passed into a Nested
YAML
file, the key/value pair name vm_role MUST NOT change.
Resource: OS::Nova::Server Metadata Parameters > vnf_id
Requirements Removed
R-44491
If a VNF’s Heat Orchestration Template’s OS::Nova::Server resource
property
metadata key/value pair vnf_id is passed into a Nested YAML
file, the key/value pair name vnf_id MUST NOT change.
Resource: OS::Nova::Server Metadata Parameters > vnf_name
Requirements Removed
R-16576
If a VNF’s Heat Orchestration Template’s OS::Nova::Server resource
property
metadata key/value pair vnf_name is passed into a Nested YAML
file, the key/value pair name vnf_name MUST NOT change.
Resource: OS::Nova::Server Metadata Parameters > workload_context
Requirements Removed
R-75202
If a VNF’s Heat Orchestration Template’s OS::Nova::Server resource
property metadata key/value pair workload_context
is passed into a Nested YAML
file, the key/value pair name workload_context MUST NOT change.
VNF On-boarding and package management > Compute, Network, and Storage Requirements
Requirements Changed
The VNF or PNF Provider MUST provide human readable documentation (not in the on-boarding package) to describe scaling capabilities to manage scaling characteristics of the VNF or PNF.
The VNF provider MUST provide the binaries and images needed to instantiate the VNF (VNF and VNFC images).
The VNF HEAT Package MUST include VNF topology that describes basic network and application connectivity internal and external to the VNF including Link type, KPIs, Bandwidth, latency, jitter, QoS (if applicable) for each interface.
VNF On-boarding and package management > Licensing Requirements
Requirements Changed
The VNF or PNF provider MUST NOT require additional infrastructure such as a VNF or PNF provider license server for VNF or PNF provider functions and metrics.
The VNF or PNF provider MUST enumerate all of the open source licenses their VNF or PNF(s) incorporate.
The VNF or PNF provider MUST agree to the process that can be met by Service Provider reporting infrastructure. The Contract shall define the reporting process and the available reporting tools.
The VNF or PNF provider MUST NOT require audits of Service Provider’s business.
The VNF or PNF provider MUST provide a universal license key per VNF or PNF to be used as needed by services (i.e., not tied to a VM instance) as the recommended solution. The VNF or PNF provider may provide pools of Unique VNF or PNF License Keys, where there is a unique key for each VNF or PNF instance as an alternate solution. Licensing issues should be resolved without interrupting in-service VNFs or PNFs.
The VNF or PNF provider MUST support the metadata about licenses (and their applicable entitlements) as defined in this specification for VNF or PNF software, and any license keys required to authorize use of the VNF or PNF software. This metadata will be used to facilitate onboarding the VNF or PNF into the ONAP environment and automating processes for putting the licenses into use and managing the full lifecycle of the licenses. The details of this license model are described in Tables C1 to C8 in the Appendix.
Note: License metadata support in ONAP is not currently available and planned for 1Q 2018.
The VNF or PNF MUST provide metrics (e.g., number of sessions, number of subscribers, number of seats, etc.) to ONAP for tracking every license.
VNF On-boarding and package management > Resource Configuration
Requirements Changed
The VNF or PNF MUST support and provide artifacts for configuration management using at least one of the following technologies; a) Netconf/YANG, b) Chef, or c) Ansible.
Note: The requirements for Netconf/YANG, Chef, and Ansible protocols are provided separately and must be supported only if the corresponding protocol option is provided by the VNF or PNF providor.
VNF On-boarding and package management > Resource Configuration > Configuration Management via Ansible
Requirements Changed
The VNF or PNF provider MUST provide playbooks to be loaded on the appropriate Ansible Server.
The VNF or PNF provider MUST provide a JSON file for each supported action for the VNF or PNF. The JSON file must contain key value pairs with all relevant values populated with sample data that illustrates its usage. The fields and their description are defined in Table B1 in the Appendix.
The VNF or PNF Package MUST include configuration scripts for boot sequence and configuration.
The VNF or PNF provider MUST provide configurable parameters (if unable to conform to YANG model) including VNF or PNF attributes/parameters and valid values, dynamic attributes and cross parameter dependencies (e.g., customer provisioning data).
VNF On-boarding and package management > Resource Configuration > Configuration Management via Chef
Requirements Changed
The VNF or PNF provider MUST provide a JSON file for each supported action for the VNF or PNF. The JSON file must contain key value pairs with all relevant values populated with sample data that illustrates its usage. The fields and their description are defined in Tables A1 and A2 in the Appendix.
Note: Chef support in ONAP is not currently available and planned for 4Q 2017.
The VNF or PNF provider MUST provide cookbooks to be loaded on the appropriate Chef Server.
VNF On-boarding and package management > Resource Configuration > Configuration Management via NETCONF/YANG
Requirements Changed
The VNF or PNF provider SHOULD provide a Resource/Device YANG model as a foundation for creating the YANG model for configuration.
VNF On-boarding and package management > Resource Control Loop
Requirements Changed
The VNF or PNF Package MUST include documentation for each KPI, provide lower and upper limits.
The VNF or PNF Package MUST include documentation for each KPI, identify the suggested actions that need to be performed when a threshold crossing alert event is recorded.
The VNF or PNF Documentation Package MUST describe the fault, performance, capacity events/alarms and other event records that are made available by the VNF or PNF.
The VNF or PNF Documentation Package MUST include documentation which must include a unique identification string for the specific VNF or PNF, a description of the problem that caused the error, and steps or procedures to perform Root Cause Analysis and resolve the issue.
The VNF or PNF Documentation Package MUST describe any requirements for the monitoring component of tools for Network Cloud automation and management to provide these records to components of the VNF or PNF.
The VNF or PNF Package MUST include documentation to when applicable, provide calculators needed to convert raw data into appropriate reporting artifacts.
The VNF or PNF Package MUST include documentation about the monitoring parameters that must include latencies, success rates, retry rates, load and quality (e.g., DPM) for the key transactions/functions supported by the VNF or PNF and those that must be exercised by the VNF or PNF in order to perform its function.
The VNF or PNF Package MUST include documentation about monitoring parameters/counters exposed for virtual resource management and VNF or PNF application management.
The VNF or PNF Documentation Package MUST, when relevant, provide a threshold crossing alert point for each KPI and describe the significance of the threshold crossing.
The VNF or PNF Documentation Package MUST describe the characteristics for the VNF or PNF reliability and high availability.
The VNF or PNF Documentation Package MUST describe all parameters that are available to monitor the VNF or PNF after instantiation (includes all counters, OIDs, PM data, KPIs, etc.) that must be collected for reporting purposes.
The VNF Package MUST include documentation about KPIs and metrics that need to be collected at each VM for capacity planning and performance management purposes.
The VNF or PNF Documentation Package MUST provide the VNF or PNF Policy Description to manage the VNF or PNF runtime lifecycle. The document must include a description of how the policies (conditions and actions) are implemented in the VNF or PNF.
The VNF or PNF Package MUST include documentation which must include all events (fault, measurement for VNF or PNF Scaling, Syslogs, State Change and Mobile Flow), that need to be collected at each VM, VNFC (defined in VNF Guidelines ) and for the overall VNF or PNF.
The VNF or PNF Package MUST include documentation which must include all events, severity level (e.g., informational, warning, error) and descriptions including causes/fixes if applicable for the event.
The VNF or PNF Documentation Package MUST describe supported VNF or PNF scaling capabilities and capacity limits (e.g., number of users, bandwidth, throughput, concurrent calls).
Requirements Removed
R-27711
The xNF provider MUST provide an XML file that contains a list of xNF error codes, descriptions of the error, and possible causes/corrective action.
R-74763
The xNF provider MUST provide an artifact per xNF that contains all of the xNF Event Records supported. The artifact should include reference to the specific release of the xNF Event Stream Common Event Data Model document it is based on. (e.g., VES Event Listener)
VNF On-boarding and package management > Resource Description
Requirements Added
The VNF or PNF PROVIDER MUST provide FM Meta Data to support the analysis of fault events delivered to DCAE. The Meta Data must be included in the VES Registration YAML file with each fault event supported by that NF at onboarding time and the Meta Data must follow the VES Event Listener and VES Event Registration Specifications.
The VNF or PNF PROVIDER MUST provide the Service Provider with PM Meta Data (PM Dictionary) to support the analysis of PM events delivered to DCAE. The PM Dictionary is to be provided as a separate YAML artifact at onboarding and must follow the VES Event Listener Specification and VES Event Registration Specification which contain the format and content required.
Requirements Changed
The VNF Provider MUST provide documentation regarding any dependency (e.g. affinity, anti-affinity) the VNF has on other VNFs and resources.
The VNF or PNF Documentation Package MUST describe the VNF or PNF Functional Capabilities that are utilized to operationalize the VNF or PNF and compose complex services.
The VNF or PNF Documentation Package MUST include a description of parameters that can be monitored for the VNF or PNF and event records (status, fault, flow, session, call, control plane, etc.) generated by the VNF or PNF after instantiation.
The VNF or PNF Documentation Package MUST describe the VNF or PNF Management APIs, which must include information and tools for ONAP to deploy and configure (initially and ongoing) the VNF or PNF application(s) (e.g., NETCONF APIs) which includes a description of configurable parameters for the VNF or PNF and whether the parameters can be configured after VNF or PNF instantiation.
The VNF or PNF package MUST provide VES Event Registration for all VES events provided by that VNF or PNF.
The VNF Documentation Package MUST contain a list of the files within the VNF package that are static during the VNF’s runtime.
The VNF or PNF Documentation Package MUST describe the VNF or PNF Functional APIs that are utilized to build network and application services. This document describes the externally exposed functional inputs and outputs for the VNF or PNF, including interface format and protocols supported.
The VNF or PNF Documentation Package MUST describe the VNF or PNF Management APIs, which must include information and tools for ONAP to monitor the health of the VNF or PNF (conditions that require healing and/or scaling responses).
The VNF or PNF Documentation Package MUST include a description of runtime lifecycle events and related actions (e.g., control responses, tests) which can be performed for the VNF or PNF.
For HEAT package, the VNF Package MUST include VNF Identification Data to uniquely identify the resource for a given VNF provider. The identification data must include: an identifier for the VNF, the name of the VNF as was given by the VNF provider, VNF description, VNF provider, and version.
Requirements Removed
R-77707
The xNF provider MUST include a Manifest File that contains a list of all the components in the xNF package.
VNF On-boarding and package management > Testing
Requirements Changed
The VNF provider MUST provide software components that can be packaged with/near the VNF, if needed, to simulate any functions or systems that connect to the VNF system under test. This component is necessary only if the existing testing environment does not have the necessary simulators.
The VNF Documentation Package MUST describe the tests that were conducted by the VNF provider and the test results.
The VNF provider MUST provide their testing scripts to support testing.
VNF Resiliency > Monitoring & Dashboard
Requirements Changed
The VNF MUST provide a method of metrics gathering for each layer’s performance to identify variances in the allocations so they can be addressed.
{network-role}
Requirements Changed
When a VNF connects to two or more unique networks, each
network MUST be assigned a unique {network-role}
in the context of the VNF for use in the VNF’s Heat Orchestration
Template.
When a VNF’s port connects to an internal network or 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 resource IDs
and resource property parameter names.
A VNF’s Heat Orchestration Template’s {network-role} MUST contain
only alphanumeric characters and/or underscores ‘_’ and
MUST NOT contain any of the following strings:
_intorint_or_int_MUST NOT end in the string:
_v6MUST NOT contain the strings
_#_, where#is a numberMUST NOT end in the string:
_#, where#is a number
{vm-type}
Requirements Changed
When a VNF’s Heat Orchestration Template creates a Virtual Machine
(i.e., OS::Nova::Server),
each “class” of VMs MUST be assigned a VNF unique
{vm-type}; where “class” defines VMs that
MUST have the following identical characteristics:
1.)
OS::Nova::Serverresource propertyflavorvalue2.)
OS::Nova::Serverresource propertyimagevalue3.) Cinder Volume attachments
Each VM in the “class” MUST have the identical Cinder Volume configuration
4.) Network attachments and IP address requirements
Each VM in the “class” MUST have the identical number of ports connecting to the identical networks and requiring the identical IP address configuration.
Requirements Removed
R-66729
A VNF’s Heat Orchestration Template’s Resource that is associated with a
unique Virtual Machine type MUST include {vm-type} as part of the
resource ID.
R-82481
A VNF’s Heat Orchestration Template’s Resource property parameter that is
associated with a unique Virtual Machine type MUST include
{vm-type} as part of the parameter name with two exceptions:
1.) The Resource
OS::Nova::Serverpropertyavailability_zoneparameter MUST NOT be prefixed with a common{vm-type}identifier,2.) The Resource
OS::Nova::Servereight mandatory and optionalmetadataparameters (i.e.,vnf_name,vnf_id,vf_module_id,vf_module_name,vm_role,vf_module_index,environment_context,workload_context) MUST NOT be prefixed with a common{vm-type}identifier.