Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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.
-
+
.. container:: note
upload of SSH public keys, SSH public keys loaded during (heat)
instantiation shall be preserved and not removed by (heat) embedded
(userdata) scripts.
-
+
.. container:: note
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.
-
+
.. container:: note
The VNF or PNF **MUST** provide the ability to remove root access once
post-instantiation configuration (Configure) is completed.
-
+
.. container:: note
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.
-
+
.. container:: note
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.
-
+
.. container:: note
The VNF or PNF **MUST** permit authentication, using root account, only
right after instantiation and until post-instantiation configuration is
completed.
-
+
.. container:: note
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).
-
+
.. container:: note
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.
-
+
.. container:: note
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]_.
-
+
.. container:: note
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.
-
+
.. container:: note
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.
-
+
.. container:: note
**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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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.
-
+
.. container:: note
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.
-
+
.. container:: note
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.
-
+
.. container:: note
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.
-
+
.. container:: note
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.
-
+
.. container:: note
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.
-
+
.. container:: note
**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).
-
+
.. container:: note
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.
-
+
.. container:: note
The VNF or PNF **MUST** support Ansible playbooks that are compatible with
Ansible version 2.6 or later.
-
+
.. container:: note
The VNF or PNF **MUST NOT** use any instance specific parameters
in a playbook.
-
+
.. container:: note
The VNF or PNF **MUST** make available playbooks that conform
to the ONAP requirement.
-
+
.. container:: note
operations such as backing out of software upgrades, configuration
changes or other work as this will help backing out of configuration
changes when needed.
-
+
.. container:: note
by invocation of **one** playbook [#7.3.4]_. The playbook will be
responsible for executing all necessary tasks (as well as calling other
playbooks) to complete the request.
-
+
Configuration Management > Chef Standards and Capabilities > VNF or PNF Configuration via Chef Requirements > Chef Client Requirements
--------------------------------------------------------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The VNF or PNF **MAY** expose a single endpoint that is
responsible for all functionality.
-
+
.. container:: note
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.
-
+
.. container:: note
The VNF or PNF **MUST** be installed with Chef-Client >= 12.0 and Chef
push jobs client >= 2.0.
-
+
.. container:: note
(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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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.
-
+
.. container:: note
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.
-
+
.. container:: note
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).
-
+
.. container:: note
(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.
-
+
.. container:: note
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.
-
+
.. container:: note
['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).
-
+
.. container:: note
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.
-
+
.. container:: note
- 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.
-
+
.. container:: note
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.
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
:need:`R-20741`
The VNF or PNF **MUST** support APPC/SDN-C ``Configure`` command.
-
+
.. container:: note
:need:`R-56385`
The VNF or PNF **MUST** support APPC ``Audit`` command.
-
+
.. container:: note
:need:`R-48247`
The VNF or PNF **MUST** support APPC ``ConfigRestore`` command.
-
+
.. container:: note
:need:`R-94084`
The VNF or PNF **MUST** support APPC/SDN-C ``ConfigScaleOut`` command.
-
+
.. container:: note
:need:`R-19366`
The VNF or PNF **MUST** support APPC ``ConfigModify`` command.
-
+
.. container:: note
:need:`R-32981`
The VNF or PNF **MUST** support APPC ``ConfigBackup`` command.
-
+
Configuration Management > Controller Interactions With VNF or PNF > HealthCheck and Failure Related Commands
-------------------------------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
:need:`R-41430`
The VNF or PNF **MUST** support APPC/SDN-C ``HealthCheck`` command.
-
+
Configuration Management > Controller Interactions With VNF or PNF > Lifecycle Management Related Commands
----------------------------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
:need:`R-65641`
The VNF or PNF **MUST** support APPC/SDN-C ``UpgradeBackOut`` command.
-
+
.. container:: note
:need:`R-97343`
The VNF or PNF **MUST** support APPC/SDN-C ``UpgradeBackup`` command.
-
+
.. container:: note
:need:`R-45856`
The VNF or PNF **MUST** support APPC/SDN-C ``UpgradePostCheck`` command.
-
+
.. container:: note
:need:`R-07251`
The VNF or PNF **MUST** support APPC/SDN-C ``ResumeTraffic`` command.
-
+
.. container:: note
:need:`R-19922`
The VNF or PNF **MUST** support APPC/SDN-C ``UpgradePrecheck`` command.
-
+
.. container:: note
:need:`R-49466`
The VNF or PNF **MUST** support APPC/SDN-C ``UpgradeSoftware`` command.
-
+
.. container:: note
:need:`R-82811`
The VNF or PNF **MUST** support APPC ``StartApplication`` command.
-
+
.. container:: note
:need:`R-12706`
The VNF or PNF **MUST** support APPC/SDN-C ``QuiesceTraffic`` command.
-
+
.. container:: note
The VNF or PNF **MUST**, if serving as a distribution point or anchor point for
steering point from source to destination, support the ONAP Controller's
``DistributeTraffic`` command.
-
+
.. container:: note
:need:`R-83146`
The VNF or PNF **MUST** support APPC ``StopApplication`` command.
-
+
Configuration Management > NETCONF Standards and Capabilities > VNF or PNF Configuration via NETCONF Requirements > Configuration Management
--------------------------------------------------------------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The VNF or PNF **MUST** provide a NETCONF interface fully defined
by supplied YANG models for the embedded NETCONF server.
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The VNF or PNF **SHOULD** support TLS as secure transport for the NETCONF
protocol according to [RFC7589].
-
+
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
[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.
-
+
.. container:: note
The VNF or PNF **MUST** support parallel and simultaneous
configuration of separate objects within itself.
-
+
.. container:: note
The VNF or PNF **MUST** implement the data model discovery and
download as defined in [RFC6022].
-
+
.. container:: note
:need:`R-83790`
The VNF or PNF **MUST** implement the ``:validate`` capability.
-
+
.. container:: note
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.
-
+
.. container:: note
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).
-
+
.. container:: note
The VNF or PNF **SHOULD** implement the protocol operation:
``delete-config(target)`` - Delete the named configuration
data store target.
-
+
.. container:: note
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).
-
+
.. container:: note
The VNF or PNF **MUST** implement ``:confirmed-commit`` If
``:candidate`` is supported.
-
+
.. container:: note
The VNF or PNF **MUST** implement the protocol operation:
``unlock(target)`` - Unlock the configuration data store target.
-
+
.. container:: note
The VNF or PNF **SHOULD** conform its YANG model to RFC 6536,
"NETCONF Access Control Model".
-
+
.. container:: note
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.
-
+
.. container:: note
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.
-
+
.. container:: note
The VNF or PNF **MUST** conform to the NETCONF RFC 6241,
"NETCONF Configuration Protocol".
-
+
.. container:: note
:need:`R-60656`
The VNF or PNF **MUST** support sub tree filtering.
-
+
.. container:: note
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.
-
+
.. container:: note
The VNF or PNF **MUST** conform to the NETCONF RFC 5717,
"Partial Lock Remote Procedure Call".
-
+
.. container:: note
The VNF or PNF **MUST** conform to the NETCONF RFC 4741,
"NETCONF Configuration Protocol".
-
+
.. container:: note
.. code-block:: text
$ pyang --verbose --strict <YANG-file-name(s)> $ echo $!
-
+
.. container:: note
The VNF or PNF **SHOULD** conform its YANG model to RFC 7223,
"A YANG Data Model for Interface Management".
-
+
.. container:: note
The VNF or PNF **SHOULD** conform its YANG model to RFC 6991,
"Common YANG Data Types".
-
+
.. container:: note
The VNF or PNF **MUST** support simultaneous <commit> operations
within the context of this locking requirements framework.
-
+
.. container:: note
The VNF or PNF **MUST** implement the protocol operation:
``kill-session(session``- Force the termination of **session**.
-
+
.. container:: note
The VNF or PNF **SHOULD** conform its YANG model to RFC 7223,
"IANA Interface Type YANG Module".
-
+
.. container:: note
The VNF or PNF **MUST** implement the protocol operation:
``close-session()`` - Gracefully close the current session.
-
+
.. container:: note
The VNF or PNF **MUST** release locks to prevent permanent lock-outs
when the corresponding <partial-unlock> operation succeeds.
-
+
.. container:: note
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.
-
+
.. container:: note
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.
-
+
.. container:: note
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.
-
+
.. container:: note
:need:`R-80898`
TThe VNF or PNF **MUST** support heartbeat via a <get> with null filter.
-
+
.. container:: note
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).
-
+
.. container:: note
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.
-
+
.. container:: note
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).
-
+
.. container:: note
The VNF or PNF **MUST** have the echo command return a zero value
otherwise the validation has failed.
-
+
.. container:: note
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.
-
+
.. container:: note
The VNF or PNF **MUST** implement the protocol operation:
``commit(confirmed, confirm-timeout)`` - Commit candidate
configuration data store to the running configuration.
-
+
.. container:: note
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.
-
+
.. container:: note
The VNF or PNF **MUST** conform to the NETCONF RFC 5277,
"NETCONF Event Notification".
-
+
.. container:: note
The VNF or PNF **MUST** conform its YANG model to RFC 6470,
"NETCONF Base Notifications".
-
+
.. container:: note
The VNF or PNF **MUST** conform to the NETCONF RFC 6242,
"Using the Network Configuration Protocol over Secure Shell".
-
+
.. container:: note
The VNF or PNF **MUST** conform its YANG model to RFC 6087,
"Guidelines for Authors and Reviewers of YANG Data Model specification".
-
+
.. container:: note
The VNF or PNF **SHOULD** implement the protocol operation:
``get-schema(identifier, version, format)`` - Retrieve the YANG schema.
-
+
.. container:: note
The VNF or PNF **MUST** implement the protocol operation:
``discard-changes()`` - Revert the candidate configuration
data store to the running configuration.
-
+
.. container:: note
``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.
-
+
.. container:: note
The VNF or PNF **MUST** implement the protocol operation:
``lock(target)`` - Lock the configuration data store target.
-
+
.. container:: note
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.
-
+
.. container:: note
The VNF or PNF **MUST** conform its YANG model to RFC 6244,
"An Architecture for Network Management Using NETCONF and YANG".
-
+
.. container:: note
``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.
-
+
.. container:: note
The VNF or PNF **SHOULD** conform its YANG model to RFC 7317,
"A YANG Data Model for System Management".
-
+
.. container:: note
database (usually the running configuration) will be left unaffected.
This provides an 'all-or-nothing' edit mode for a single <edit-config>
request.
-
+
.. container:: note
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.
-
+
.. container:: note
``: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.
-
+
.. container:: note
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.
-
+
.. container:: note
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.
-
+
.. container:: note
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.
-
+
.. container:: note
The VNF or PNF **MUST** be able to specify the granularity of the
lock via a restricted or full XPath expression.
-
+
.. container:: note
The VNF or PNF **SHOULD** conform its YANG model to RFC 7277,
"A YANG Data Model for IP Management".
-
+
.. container:: note
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).
-
+
.. container:: note
The VNF or PNF **MUST** implement the ``:with-defaults`` capability
[RFC6243].
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
parameter
**MUST NOT** be enumerated in the
VNF's Heat Orchestration Template's Environment File.
-
+
.. container:: note
And the parameter **MUST** be declared as type ``string``.
The ONAP data model can only support one IPv4 VIP address.
-
+
.. container:: note
And the parameter **MUST** be declared as type ``string``.
The ONAP data model can only support one IPv6 VIP address.
-
+
.. container:: note
``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
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
And the parameter **MUST** be declared as ``type: comma_delimited_list``
and **MUST** be enumerated in the environment file.
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
parameter
**MUST** be declared as either type ``string`` or type
``comma_delimited_list``.
-
+
.. container:: note
* ``{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
-
+
.. container:: note
``{vm-type}_{network-role}_ip_{index}``
**MUST NOT** be enumerated in the
VNF's Heat Orchestration Template's Environment File.
-
+
.. container:: note
``OS::Nova::Server``
* ``{network-role}`` is the {network-role} of the external
network
-
+
.. container:: note
``{vm-type}_{network-role}_ips``
**MUST NOT** be enumerated in the
VNF's Heat Orchestration Template's Environment File.
-
+
.. container:: note
* ``{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
-
+
.. container:: note
``{vm-type}_{network-role}_v6_ip_{index}``
**MUST NOT** be enumerated in the
VNF's Heat Orchestration Template's Environment File.
-
+
.. container:: note
OS::Nova::Server
* ``{network-role}`` is the {network-role} of the external
network
-
+
.. container:: note
``{vm-type}_{network-role}_v6_ips``
**MUST NOT** be enumerated in the
VNF's Heat Orchestration Template's Environment File.
-
+
.. container:: note
* ``{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
-
+
.. container:: note
``{vm-type}_int_{network-role}_ip_{index}``
**MUST** be enumerated in the
VNF's Heat Orchestration Template's Environment File.
-
+
.. container:: note
``OS::Nova::Server``
* ``{network-role}`` is the {network-role} of the internal
network
-
+
.. container:: note
``{vm-type}_int_{network-role}_int_ips``
**MUST** be enumerated in the
VNF's Heat Orchestration Template's Environment File.
-
+
.. container:: note
* ``{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
-
+
.. container:: note
``{vm-type}_int_{network-role}_v6_ip_{index}``
**MUST** be enumerated in the
VNF's Heat Orchestration Template's Environment File.
-
+
.. container:: note
``OS::Nova::Server``
* ``{network-role}`` is the {network-role} of the internal
network
-
+
.. container:: note
``{vm-type}_int_{network-role}_v6_ips``
**MUST** be enumerated in the
VNF's Heat Orchestration Template's Environment File.
-
+
.. container:: note
**MUST NOT** be enumerated in the Heat Orchestration
Template's Environment File. ONAP provides the IP address
assignments at orchestration time.
-
+
.. container:: note
**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
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
resource ``OS::ContrailV2::InstanceIp`` property ``subnet_uuid``
parameter
**MUST** be declared type ``string``.
-
+
.. container:: note
where
* ``{network-role}`` is the network role of the network.
-
+
.. container:: note
``{network-role}_subnet_id``
**MUST NOT** be enumerated in the
VNF's Heat Orchestration Template's Environment File.
-
+
.. container:: note
where
* ``{network-role}`` is the network role of the network.
-
+
.. container:: note
``{network-role}_v6_subnet_id``
**MUST NOT** be enumerated in the
VNF's Heat Orchestration Template's Environment File.
-
+
.. container:: note
Note that the parameter **MUST** be defined as an ``output`` parameter in
the base module.
-
+
.. container:: note
``int_{network-role}_subnet_id``
**MUST NOT** be enumerated in the
VNF's Heat Orchestration Template's Environment File.
-
+
.. container:: note
Note that the parameter **MUST** be defined as an ``output`` parameter in
the base module.
-
+
.. container:: note
``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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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 :ref:`VES Event Registration specification <ves_event_registration_3_2>`.
-
+
.. container:: note
event format defined in the
:ref:`VES Event Listener<ves_event_listener_7_1>`
specification.
-
+
.. container:: note
* Required fields
* Optional fields
* Any special handling to be performed for that event
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
* ``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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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.
-
+
.. container:: note
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.
-
+
.. container:: note
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.
-
+
.. container:: note
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.
-
+
.. container:: note
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.)
-
+
.. container:: note
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.
-
+
.. container:: note
The VNF or PNF **MAY** use another option which is expected to include REST
delivery of binary encoded data sets.
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The VNF or PNF **MUST** must encode, address and deliver the data
as described in the previous paragraphs.
-
+
.. container:: note
The VNF or PNF **MUST** deliver asynchronous data as data becomes
available, or according to the configured frequency.
-
+
.. container:: note
The VNF or PNF **MUST** use the YANG configuration models and RESTCONF
[RFC8040] (https://tools.ietf.org/html/rfc8040).
-
+
.. container:: note
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.)
-
+
.. container:: note
The VNF or PNF **MUST** use the RESTCONF/NETCONF framework used by
the ONAP configuration subsystem for synchronous communication.
-
+
.. container:: note
The VNF or PNF **SHOULD** deliver all syslog messages to the VES Collector per the
specifications in Monitoring and Management chapter.
-
+
.. container:: note
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.
-
+
.. container:: note
The VNF or PNF **MUST** respond to data requests from ONAP as soon
as those requests are received, as a synchronous response.
-
+
.. container:: note
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.
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
available at VNF or PNF.
Note: Recommended period is at least 24 hours.
-
+
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The VNF or PNF **SHOULD** support FileReady VES event for event-driven bulk transfer
of monitoring data.
-
+
.. container:: note
The VNF or PNF **SHOULD** support File transferring protocol, such as FTPES or SFTP,
when supporting the event-driven bulk transfer of monitoring data.
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
the state of an VNF or PNF resource.
* The required Google Protocol Buffers (GPB) metadata is provided in the
form of .proto files.
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
High-volume data is to be encoded and serialized using
`Avro <http://avro.apache.org/>`_, where the Avro data
format are described using JSON.
-
+
Monitoring & Management > Monitoring & Management Requirements > Reporting Frequency
------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
should not affect deserialization and decoding of the data, which
will be guided by the accompanying JSON schema or GPB definition
files.
-
+
.. container:: note
The VNF or PNF **MUST** report exactly one Measurement event per period
per source name.
-
+
Monitoring & Management > Monitoring & Management Requirements > Security
-------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
[`RFC5246 <https://tools.ietf.org/html/rfc5246>`_] and should adhere to
the best current practices outlined in
`RFC7525 <https://tools.ietf.org/html/rfc7525>`_.
-
+
.. container:: note
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.
-
+
.. container:: note
Note: HTTP Basic Authentication has 4 steps: Request, Authenticate,
Authorization with Username/Password Credentials, and Authentication Status
as per RFC7617 and RFC 2617.
-
+
.. container:: note
Note: The configuration management and provisioning software are specific
to a vendor architecture.
-
+
.. container:: note
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.
-
+
.. container:: note
:need:`R-47597`
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The VNF or PNF **MUST** deliver event records to ONAP using the common
transport mechanisms and protocols defined in this specification.
-
+
.. container:: note
The VNF or PNF **SHOULD** deliver event records that fall into the event domains
supported by VES.
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix``
* ``OS::ContrailV2::InstanceIP`` property ``instance_ip_address``
* ``OS::ContrailV2::InstanceIP`` property ``subnet_uuid``
-
+
Requirements Removed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
A VNF's Heat Orchestration Template's Nested YAML file
**MUST** be in the same directory hierarchy as the VNF's Heat
Orchestration Templates.
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
(i.e., ``OS::Neutron::Net``, ``OS::Neutron::Subnet``) and/or
Contrail Heat Resources (i.e., ``OS::ContrailV2::VirtualNetwork``,
``ContrailV2::NetworkIpam``).
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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.
-
+
.. container:: note
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.
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
A VNF's Heat Orchestration Template's parameter defined
in a nested YAML file
**SHOULD NOT** have a parameter constraint defined.
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
* ``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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
file that contains only ``OS::Cinder::Volume`` resources
* a resource that calls a nested YAML file (static nesting) that contains
only ``OS::Cinder::Volume`` resources
-
+
ONAP Heat Orchestration Templates Overview > ONAP Heat Orchestration Template Filenames > Incremental Modules
-------------------------------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
A VNF's Heat Orchestration Template's Resource ``OS::Cinder::Volume``
**MAY** be defined in an Incremental Module.
-
+
.. container:: note
A VNF's Heat Orchestration Template's Resource ``OS::Cinder::Volume``
**MAY** be defined in a Cinder Volume Module.
-
+
.. container:: note
A VNF's Heat Orchestration Template's Resource ``OS::Cinder::Volume``
**MAY** be defined in a Base Module.
-
+
Requirements Removed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The VNF's Heat Orchestration Template's ZIP file **MUST NOT** include
a binary image file.
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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.
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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.
-
+
.. container:: note
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.
-
+
.. container:: note
Parameter(s)
**MUST** include the
UUID(s) of the Cinder Volumes created in template.
-
+
ONAP Heat Support of Environment Files
--------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
in the
corresponding VNF's Heat Orchestration Template's YAML file's
``parameters:`` section.
-
+
ONAP Heat VNF Modularity
------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
- tosca.datatypes.nfv.LocationInfo
- tosca.datatypes.nfv.CivicAddressElement
-
+
ONAP TOSCA VNFD or PNFD Requirements > TOSCA PNF Descriptor > General
---------------------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
- tosca.nodes.nfv.PnfExtCp
- tosca.nodes.nfv.Cp
-
+
ONAP TOSCA VNFD or PNFD Requirements > TOSCA PNF Descriptor > Policy Types
--------------------------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
- onap_others: contains any other non_MANO artifacts, e.g. informational
documents
-
+
.. container:: note
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.
-
+
.. container:: note
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.
-
+
.. container:: note
- pnfd_release_date_time
- pnfd_archive_version
-
+
.. container:: note
- vnf_release_date_time
- vnf_package_version
-
+
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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.
-
+
.. container:: note
SOL004.
for example ROOT\\Licenses\\ **License_term.txt**
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
:need:`R-506221`
The VNF or PNF TOSCA CSAR file **MUST** be a zip file with .csar extension.
-
+
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The VNF or PNF CSAR package **MUST** be arranged as a CSAR archive as
specified in TOSCA Simple Profile in YAML 1.2.
-
+
.. container:: note
**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
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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".
-
+
.. container:: note
.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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
Note: The PNF Controller may be VF-C, APP-C or SDN-C based on the
PNF and PNF domain.
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
instance of a virtual machine interface and **MUST** increment by one
each time a new IPv4 address is configured on the
virtual machine interface.
-
+
.. container:: note
instance of a virtual machine interface and **MUST** increment by one
each time a new IPv6 address is configured on the
virtual machine interface.
-
+
.. container:: note
instance of a virtual machine interface and **MUST** increment by one
each time a new IPv4 address is configured on the
virtual machine interface.
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
attached to the network of ``{network-role}``
* ``IP`` signifies that an IPv4 address is being configured
* ``{index}`` is the index of the IPv4 address
-
+
.. container:: note
attached to the network of ``{network-role}``
* ``v6_IP`` signifies 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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
* ``{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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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.
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
* ``{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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
* ``{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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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).
-
+
.. container:: note
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).
-
+
.. container:: note
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.
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
* ``{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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
* ``{index}`` is the ``{index}`` of the keypair.
The ``{index}`` starts at zero and increments by one
(as described in R-11690).
-
+
.. container:: note
where
* ``{vnf-type}`` describes the VNF
-
+
Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Nova::Server
----------------------------------------------------------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
* ``{index}`` is the index.
The ``{index}`` **MUST** starts at zero and increment by one
as described in R-11690.
-
+
Resource Property “name”
------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
R-41492 and R-83418)
**MUST** contain the identical ``{network-role}``.
-
+
Requirements Removed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
all the IPv4 Addresses **MUST** be from
the same subnet and all the IPv6 Addresses **MUST** be from the
same subnet.
-
+
.. container:: note
internal network. All VNF ports connected to the unique internal
network **MUST** have cloud assigned IP Addresses
or **MUST** have statically assigned IP addresses.
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
``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
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
As noted in the introduction to this section, the ONAP data model
can only support one IPv6 VIP address.
-
+
.. container:: note
map property ``ip_address`` parameter(s)
**MUST NOT** be enumerated in the
VNF's Heat Orchestration Template's Environment File.
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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.
-
+
.. container:: note
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.
-
+
.. container:: note
``{vm-type}_{network-role}_floating_v6_ip``
**MUST NOT** be enumerated in the
VNF's Heat Orchestration Template's Environment File.
-
+
.. container:: note
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.
-
+
.. container:: note
``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
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
And the parameter **MUST** be declared as ``type: comma_delimited_list``
and **MUST** be enumerated in the environment file.
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
* ``{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
-
+
.. container:: note
* ``{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
-
+
.. container:: note
* ``{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
-
+
.. container:: note
* ``{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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
where ``{network-role}`` is the network-role of the internal network and
a ``get_param`` **MUST** be used as the intrinsic function.
-
+
Requirements Removed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
property ``name`` parameter is defined as a ``string``, a parameter
**MUST** be delcared for
each ``OS::Nova::Server`` resource associated with the ``{vm-type}``.
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
``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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
``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
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
A VNF's Heat Orchestration Template's ``OS::Nova::Server``
resource property ``metadata`` **MAY**
contain the key/value pair ``vf_module_index``.
-
+
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
resource property ``metadata``
key/value pair ``vf_module_index``
value **MUST** be obtained via a ``get_param``.
-
+
Requirements Removed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
property metadata **SHOULD** contain the key/value pair ``vf_module_name``.
-
+
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
property ``metadata`` key/value pair ``vf_module_name``
value **MUST**
be obtained via a ``get_param``.
-
+
Requirements Removed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
* ``vm_role`` and the parameter defined as ``type: string``.
* ``vm_roles`` and the parameter defined as ``type: comma_delimited_list``.
* ``{vm-type}_vm_role`` and the parameter defined as ``type: string``.
-
+
Requirements Removed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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.
-
+
.. container:: note
The VNF provider **MUST** provide the binaries and images
needed to instantiate the VNF (VNF and VNFC images).
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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.
-
+
.. container:: note
The VNF or PNF provider **MUST** enumerate all of the open
source licenses their VNF or PNF(s) incorporate.
-
+
.. container:: note
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.
-
+
.. container:: note
The VNF or PNF provider **MUST NOT** require audits
of Service Provider's business.
-
+
.. container:: note
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.
-
+
.. container:: note
Note: License metadata support in ONAP is not currently available
and planned for 1Q 2018.
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The VNF or PNF provider **MUST** provide playbooks to be loaded
on the appropriate Ansible Server.
-
+
.. container:: note
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.
-
+
.. container:: note
The VNF or PNF Package **MUST** include configuration scripts
for boot sequence and configuration.
-
+
.. container:: note
(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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
and A2 in the Appendix.
Note: Chef support in ONAP is not currently available and planned for 4Q 2017.
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The VNF or PNF Package **MUST** include documentation for each KPI, provide
lower and upper limits.
-
+
.. container:: note
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.
-
+
.. container:: note
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.
-
+
.. container:: note
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.
-
+
.. container:: note
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.
-
+
.. container:: note
The VNF or PNF Package **MUST** include documentation to when applicable,
provide calculators needed to convert raw data into appropriate reporting
artifacts.
-
+
.. container:: note
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.
-
+
.. container:: note
The VNF or PNF Package **MUST** include documentation about monitoring
parameters/counters exposed for virtual resource management and VNF or PNF
application management.
-
+
.. container:: note
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.
-
+
.. container:: note
The VNF or PNF Documentation Package **MUST** describe
the characteristics for the VNF or PNF reliability and high availability.
-
+
.. container:: note
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.
-
+
.. container:: note
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.
-
+
.. container:: note
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.
-
+
.. container:: note
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 <https://onap.readthedocs.io/en/latest/submodules/vnfrqts/guidelines.git/docs/vnf_guidelines.html>`__ ) and for the overall VNF or PNF.
-
+
.. container:: note
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.
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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.
-
+
.. container:: note
reference to the specific release of the xNF Event Stream Common Event
Data Model document it is based on. (e.g.,
`VES Event Listener <https://onap.readthedocs.io/en/latest/submodules/vnfsdk/model.git/docs/files/VESEventListener.html>`__)
-
+
VNF On-boarding and package management > Resource Description
-------------------------------------------------------------
Requirements Added
~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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.
-
+
.. container:: note
onboarding and must follow the VES Event Listener Specification and VES
Event Registration Specification which contain the format and content
required.
-
+
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
The VNF Provider **MUST** provide documentation regarding any dependency
(e.g. affinity, anti-affinity) the VNF has on other VNFs and resources.
-
+
.. container:: note
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.
-
+
.. container:: note
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.
-
+
.. container:: note
(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.
-
+
.. container:: note
The VNF or PNF package **MUST** provide :ref:`VES Event Registration <ves_event_registration_3_2>`
for all VES events provided by that VNF or PNF.
-
+
.. container:: note
The VNF Documentation Package **MUST** contain a list of the files within the VNF
package that are static during the VNF's runtime.
-
+
.. container:: note
application services. This document describes the externally exposed
functional inputs and outputs for the VNF or PNF, including interface
format and protocols supported.
-
+
.. container:: note
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).
-
+
.. container:: note
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.
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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.
-
+
.. container:: note
The VNF Documentation Package **MUST** describe
the tests that were conducted by the VNF provider and the test results.
-
+
.. container:: note
The VNF provider **MUST** provide their testing scripts to
support testing.
-
+
VNF Resiliency > Monitoring & Dashboard
---------------------------------------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
network **MUST** be assigned a unique ``{network-role}``
in the context of the VNF for use in the VNF's Heat Orchestration
Template.
-
+
.. container:: note
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.
-
+
.. container:: note
* **MUST NOT** end in the string: ``_v6``
* **MUST NOT** contain the strings ``_#_``, where ``#`` is a number
* **MUST NOT** end in the string: ``_#``, where ``#`` is a number
-
+
{vm-type}
---------
Requirements Changed
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
- 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
~~~~~~~~~~~~~~~~~~~~
-
+
.. container:: note
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.
-
+
.. container:: note
``vf_module_name``, ``vm_role``,
``vf_module_index``, ``environment_context``, ``workload_context``)
**MUST NOT** be prefixed with a common ``{vm-type}`` identifier.
-
+
Code Review / vnfrqts / requirements.git / commitdiff