path: root/docs/changes-by-section-dublin.rst

.. Modifications Copyright © 2017-2018 AT&T Intellectual Property.

.. Licensed under the Creative Commons License, Attribution 4.0 Intl.
   (the "License"); you may not use this documentation except in compliance
   with the License. You may obtain a copy of the License at

.. https://creativecommons.org/licenses/by/4.0/

.. Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.


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::
    :depth: 2

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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-94567`

    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

    :need:`R-82018`

    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.
    

.. container:: note

    :need:`R-35401`

    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

    :need:`R-97451`

    The VNF or PNF **MUST** provide the ability to remove root access once
    post-instantiation configuration (Configure) is completed.
    

.. container:: note

    :need:`R-45197`

    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.
    

.. container:: note

    :need:`R-73459`

    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

    :need:`R-97345`

    The VNF or PNF **MUST** permit authentication, using root account, only
    right after instantiation and until post-instantiation configuration is
    completed.
    

.. container:: note

    :need:`R-92866`

    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).
    

.. container:: note

    :need:`R-67124`

    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.
    

.. container:: note

    :need:`R-32217`

    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]_.
    

.. container:: note

    :need:`R-54373`

    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

    :need:`R-24482`

    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.
    

.. container:: note

    :need:`R-91745`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-49911`

    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

    :need:`R-58301`

    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.
    

.. container:: note

    :need:`R-24189`

    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

    :need:`R-43353`

    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.
    

.. container:: note

    :need:`R-51442`

    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.
    

.. container:: note

    :need:`R-48698`

    The VNF or PNF **MUST** utilize information from key value pairs that will
    be provided by the Ansible Server as "extra-vars" during invocation to
    execute the desired VNF or PNF action. The "extra-vars" attribute-value
    pairs are passed to the Ansible Server by an APPC/SDN-C as part of the
    Rest API request. If the playbook requires files, they must also be
    supplied using the methodology detailed in the Ansible Server API, unless
    they are bundled with playbooks, example, generic templates. Any files
    containing instance specific info (attribute-value pairs), not obtainable
    from any ONAP inventory databases or other sources, referenced and used 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.
    

.. container:: note

    :need:`R-43253`

    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).
    

.. container:: note

    :need:`R-50252`

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

.. container:: note

    :need:`R-49751`

    The VNF or PNF **MUST** support Ansible playbooks that are compatible with
    Ansible version 2.6 or later.
    

.. container:: note

    :need:`R-33280`

    The VNF or PNF **MUST NOT** use any instance specific parameters
    in a playbook.
    

.. container:: note

    :need:`R-40293`

    The VNF or PNF **MUST** make available playbooks that conform
    to the ONAP requirement.
    

.. container:: note

    :need:`R-02651`

    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.
    

.. container:: note

    :need:`R-49396`

    The VNF or PNF **MUST** support each APPC/SDN-C VNF or PNF action
    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

    :need:`R-47068`

    The VNF or PNF **MAY** expose a single endpoint that is
    responsible for all functionality.
    

.. container:: note

    :need:`R-79224`

    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

    :need:`R-67114`

    The VNF or PNF **MUST** be installed with Chef-Client >= 12.0 and Chef
    push jobs client >= 2.0.
    

.. container:: note

    :need:`R-72184`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-37929`

    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

    :need:`R-62170`

    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

    :need:`R-30654`

    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).
    

.. container:: note

    :need:`R-26567`

    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.
    

.. container:: note

    :need:`R-27310`

    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

    :need:`R-44013`

    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).
    

.. container:: note

    :need:`R-15885`

    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.
    

.. container:: note

    :need:`R-65755`

    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.
    

.. container:: note

    :need:`R-98911`

    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

    :need:`R-78116`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. 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

    :need:`R-328086`

    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

    :need:`R-95950`

    The VNF or PNF **MUST** provide a NETCONF interface fully defined
    by supplied YANG models for the embedded NETCONF server.
    

.. container:: note

    :need:`R-88026`

    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

    :need:`R-997907`

    The VNF or PNF **SHOULD** support TLS as secure transport for the NETCONF
    protocol according to [RFC7589].
    

Requirements Changed
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-26115`

    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.
    

.. container:: note

    :need:`R-10716`

    The VNF or PNF **MUST** support parallel and simultaneous
    configuration of separate objects within itself.
    

.. container:: note

    :need:`R-59610`

    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

    :need:`R-62468`

    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

    :need:`R-29495`

    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).
    

.. container:: note

    :need:`R-88031`

    The VNF or PNF **SHOULD** implement the protocol operation:
    ``delete-config(target)`` - Delete the named configuration
    data store target.
    

.. container:: note

    :need:`R-54190`

    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

    :need:`R-49145`

    The VNF or PNF **MUST** implement ``:confirmed-commit`` If
    ``:candidate`` is supported.
    

.. container:: note

    :need:`R-96554`

    The VNF or PNF **MUST** implement the protocol operation:
    ``unlock(target)`` - Unlock the configuration data store target.
    

.. container:: note

    :need:`R-22946`

    The VNF or PNF **SHOULD** conform its YANG model to RFC 6536,
    "NETCONF Access Control Model".
    

.. container:: note

    :need:`R-01382`

    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

    :need:`R-10173`

    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

    :need:`R-08134`

    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

    :need:`R-29488`

    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

    :need:`R-01334`

    The VNF or PNF **MUST** conform to the NETCONF RFC 5717,
    "Partial Lock Remote Procedure Call".
    

.. container:: note

    :need:`R-33946`

    The VNF or PNF **MUST** conform to the NETCONF RFC 4741,
    "NETCONF Configuration Protocol".
    

.. container:: note

    :need:`R-25238`

    The VNF or PNF PACKAGE **MUST** validated YANG code using the open
    source pyang [#7.3.1]_ program using the following commands:

    .. code-block:: text

      $ pyang --verbose --strict <YANG-file-name(s)> $ echo $!
    

.. container:: note

    :need:`R-10129`

    The VNF or PNF **SHOULD** conform its YANG model to RFC 7223,
    "A YANG Data Model for Interface Management".
    

.. container:: note

    :need:`R-33955`

    The VNF or PNF **SHOULD** conform its YANG model to RFC 6991,
    "Common YANG Data Types".
    

.. container:: note

    :need:`R-88899`

    The VNF or PNF **MUST** support simultaneous <commit> operations
    within the context of this locking requirements framework.
    

.. container:: note

    :need:`R-11235`

    The VNF or PNF **MUST** implement the protocol operation:
    ``kill-session(session``- Force the termination of **session**.
    

.. container:: note

    :need:`R-12271`

    The VNF or PNF **SHOULD** conform its YANG model to RFC 7223,
    "IANA Interface Type YANG Module".
    

.. container:: note

    :need:`R-90007`

    The VNF or PNF **MUST** implement the protocol operation:
    ``close-session()`` - Gracefully close the current session.
    

.. container:: note

    :need:`R-03465`

    The VNF or PNF **MUST** release locks to prevent permanent lock-outs
    when the corresponding <partial-unlock> operation succeeds.
    

.. container:: note

    :need:`R-93443`

    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.
    

.. container:: note

    :need:`R-29324`

    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

    :need:`R-68990`

    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

    :need:`R-66793`

    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).
    

.. container:: note

    :need:`R-11499`

    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.
    

.. container:: note

    :need:`R-63935`

    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).
    

.. container:: note

    :need:`R-63953`

    The VNF or PNF **MUST** have the echo command return a zero value
    otherwise the validation has failed.
    

.. container:: note

    :need:`R-26508`

    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.
    

.. container:: note

    :need:`R-70496`

    The VNF or PNF **MUST** implement the protocol operation:
    ``commit(confirmed, confirm-timeout)`` - Commit candidate
    configuration data store to the running configuration.
    

.. container:: note

    :need:`R-24269`

    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

    :need:`R-13800`

    The VNF or PNF **MUST** conform to the NETCONF RFC 5277,
    "NETCONF Event Notification".
    

.. container:: note

    :need:`R-22700`

    The VNF or PNF **MUST** conform its YANG model to RFC 6470,
    "NETCONF Base Notifications".
    

.. container:: note

    :need:`R-78282`

    The VNF or PNF **MUST** conform to the NETCONF RFC 6242,
    "Using the Network Configuration Protocol over Secure Shell".
    

.. container:: note

    :need:`R-53317`

    The VNF or PNF **MUST** conform its YANG model to RFC 6087,
    "Guidelines for Authors and Reviewers of YANG Data Model specification".
    

.. container:: note

    :need:`R-97529`

    The VNF or PNF **SHOULD** implement the protocol operation:
    ``get-schema(identifier, version, format)`` - Retrieve the YANG schema.
    

.. container:: note

    :need:`R-18733`

    The VNF or PNF **MUST** implement the protocol operation:
    ``discard-changes()`` - Revert the candidate configuration
    data store to the running configuration.
    

.. container:: note

    :need:`R-44281`

    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.
    

.. container:: note

    :need:`R-02597`

    The VNF or PNF **MUST** implement the protocol operation:
    ``lock(target)`` - Lock the configuration data store target.
    

.. container:: note

    :need:`R-20353`

    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

    :need:`R-10353`

    The VNF or PNF **MUST** conform its YANG model to RFC 6244,
    "An Architecture for Network Management Using NETCONF and YANG".
    

.. container:: note

    :need:`R-60106`

    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.
    

.. container:: note

    :need:`R-87564`

    The VNF or PNF **SHOULD** conform its YANG model to RFC 7317,
    "A YANG Data Model for System Management".
    

.. container:: note

    :need:`R-83873`

    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.
    

.. container:: note

    :need:`R-73468`

    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.
    

.. container:: note

    :need:`R-28756`

    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.
    

.. container:: note

    :need:`R-68200`

    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.
    

.. container:: note

    :need:`R-53015`

    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

    :need:`R-07545`

    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

    :need:`R-41829`

    The VNF or PNF **MUST** be able to specify the granularity of the
    lock via a restricted or full XPath expression.
    

.. container:: note

    :need:`R-49036`

    The VNF or PNF **SHOULD** conform its YANG model to RFC 7277,
    "A YANG Data Model for IP Management".
    

.. container:: note

    :need:`R-02616`

    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).
    

.. container:: note

    :need:`R-58358`

    The VNF or PNF **MUST** implement the ``:with-defaults`` capability
    [RFC6243].
    

.. container:: note

    :need:`R-04158`

    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

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-31809`

    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
~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-100280`

    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.
    

.. container:: note

    :need:`R-100310`

    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 the ``OS::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.
    

.. container:: note

    :need:`R-100330`

    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 the ``OS::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.
    

.. container:: note

    :need:`R-100350`

    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 ``string`` or type
    ``comma_delimited_list``.

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

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

    ``virtual_machine_interface_allowed_address_pairs``,

    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair``,

    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip``,

    ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix``

    parameters **not** supported by the ONAP data model.
    

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


Requirements Added
~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-100360`

    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.
    

.. container:: note

    :need:`R-100370`

    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
~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-100000`

    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``.
    

.. container:: note

    :need:`R-100010`

    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 the ``OS::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
    

.. container:: note

    :need:`R-100020`

    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.
    

.. container:: note

    :need:`R-100030`

    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}_ips``

      where

      * ``{vm-type}`` is the {vm-type} associated with the
        ``OS::Nova::Server``
      * ``{network-role}`` is the {network-role} of the external
        network
    

.. container:: note

    :need:`R-100040`

    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.
    

.. container:: note

    :need:`R-100050`

    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 the
      ``OS::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
    

.. container:: note

    :need:`R-100060`

    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.
    

.. container:: note

    :need:`R-100070`

    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
    

.. container:: note

    :need:`R-100080`

    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.
    

.. container:: note

    :need:`R-100090`

    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 the
      ``OS::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
    

.. container:: note

    :need:`R-100100`

    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.
    

.. container:: note

    :need:`R-100110`

    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 the
        ``OS::Nova::Server``
      * ``{network-role}`` is the {network-role} of the internal
        network
    

.. container:: note

    :need:`R-100120`

    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.
    

.. container:: note

    :need:`R-100130`

    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 the ``OS::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
    

.. container:: note

    :need:`R-100140`

    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.
    

.. container:: note

    :need:`R-100150`

    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 the
        ``OS::Nova::Server``
      * ``{network-role}`` is the {network-role} of the internal
        network
    

.. container:: note

    :need:`R-100160`

    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.
    

.. container:: note

    :need:`R-100170`

    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.
    

.. container:: note

    :need:`R-100180`

    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
~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-100190`

    The VNF's Heat Orchestration Template's
    resource ``OS::ContrailV2::InstanceIp`` property ``subnet_uuid``
    parameter
    **MUST** be declared type ``string``.
    

.. container:: note

    :need:`R-100200`

    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.
    

.. container:: note

    :need:`R-100210`

    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.
    

.. container:: note

    :need:`R-100220`

    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.
    

.. container:: note

    :need:`R-100230`

    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.
    

.. container:: note

    :need:`R-100240`

    When

      * the VNF's Heat Orchestration Template's
        resource ``OS::ContrailV2::InstanceIp`` in an Incremental Module is
        assigning an IP address
        to an internal network (per the ONAP definition, see
        Requirements R-52425 and R-46461)
        that is created in the Base Module, AND
      * an IPv4 address is being cloud assigned by OpenStack's DHCP Service AND
      * the internal network IPv4 subnet is to be specified
        using the property ``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.
    

.. container:: note

    :need:`R-100250`

    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.
    

.. container:: note

    :need:`R-100260`

    When

      * the VNF's Heat Orchestration Template's
        resource ``OS::ContrailV2::InstanceIp`` in 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, AND
      * an 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.
    

.. container:: note

    :need:`R-100270`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-120182`

    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 :ref:`VES Event Registration specification <ves_event_registration_3_2>`.
    

.. container:: note

    :need:`R-570134`

    The events produced by the VNF or PNF **MUST** must be compliant with the common
    event format defined in the
    :ref:`VES Event Listener<ves_event_listener_7_1>`
    specification.
    

.. container:: note

    :need:`R-520802`

    The VNF or PNF provider **MUST** provide a YAML file formatted in adherence with
    the :ref:`VES Event Registration specification <ves_event_registration_3_2>`
    that defines the following information for each event produced by the VNF:

    * ``eventName``
    * Required fields
    * Optional fields
    * Any special handling to be performed for that event
    

.. container:: note

    :need:`R-123044`

    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

    :need:`R-528866`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-84879`

    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.
    

.. container:: note

    :need:`R-88482`

    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

    :need:`R-81777`

    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.
    

.. container:: note

    :need:`R-79412`

    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.
    

.. container:: note

    :need:`R-01033`

    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.)
    

.. container:: note

    :need:`R-03070`

    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.
    

.. container:: note

    :need:`R-08312`

    The VNF or PNF **MAY** use another option which is expected to include REST
    delivery of binary encoded data sets.
    

.. container:: note

    :need:`R-63229`

    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

    :need:`R-73285`

    The VNF or PNF **MUST** must encode, address and deliver the data
    as described in the previous paragraphs.
    

.. container:: note

    :need:`R-06924`

    The VNF or PNF **MUST** deliver asynchronous data as data becomes
    available, or according to the configured frequency.
    

.. container:: note

    :need:`R-86586`

    The VNF or PNF **MUST** use the YANG configuration models and RESTCONF
    [RFC8040] (https://tools.ietf.org/html/rfc8040).
    

.. container:: note

    :need:`R-70266`

    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.)
    

.. container:: note

    :need:`R-34660`

    The VNF or PNF **MUST** use the RESTCONF/NETCONF framework used by
    the ONAP configuration subsystem for synchronous communication.
    

.. container:: note

    :need:`R-332680`

    The VNF or PNF **SHOULD** deliver all syslog messages to the VES Collector per the
    specifications in Monitoring and Management chapter.
    

.. container:: note

    :need:`R-46290`

    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

    :need:`R-42140`

    The VNF or PNF **MUST** respond to data requests from ONAP as soon
    as those requests are received, as a synchronous response.
    

.. container:: note

    :need:`R-11240`

    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

    :need:`R-43327`

    The VNF or PNF **SHOULD** use `Modeling JSON text with YANG
    <https://tools.ietf.org/html/rfc7951>`_, 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
~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-807129`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-841740`

    The VNF or PNF **SHOULD** support FileReady VES event for event-driven bulk transfer
    of monitoring data.
    

.. container:: note

    :need:`R-440220`

    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

    :need:`R-75943`

    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

    :need:`R-257367`

    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.
    

.. container:: note

    :need:`R-978752`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-19624`

    The VNF or PNF, when leveraging JSON for events, **MUST** encode and serialize
    content delivered to ONAP using JSON (RFC 7159) plain text format.
    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

    :need:`R-98191`

    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.
    

.. container:: note

    :need:`R-146931`

    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

    :need:`R-42366`

    The VNF or PNF **MUST** support secure connections and transports such as
    Transport Layer Security (TLS) protocol
    [`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

    :need:`R-44290`

    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

    :need:`R-894004`

    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.
    

.. container:: note

    :need:`R-01427`

    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.
    

.. container:: note

    :need:`R-68165`

    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

    :need:`R-821473`

    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

    :need:`R-821839`

    The VNF or PNF **MUST** deliver event records to ONAP using the common
    transport mechanisms and protocols defined in this specification.
    

.. container:: note

    :need:`R-798933`

    The VNF or PNF **SHOULD** deliver event records that fall into the event domains
    supported by VES.
    

.. container:: note

    :need:`R-932071`

    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

    :need:`R-908291`

    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

    :need:`R-697654`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-659655`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    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
~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-100380`

    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
~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-708564`

    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::Server`` property ``flavor``
    * ``OS::Nova::Server`` property ``image``
    * ``OS::Nova::Server`` property ``name``
    * ``OS::Nova::Server`` property metadata key value ``vnf_id``
    * ``OS::Nova::Server`` property metadata key value ``vf_module_id``
    * ``OS::Nova::Server`` property metadata key value ``vnf_name``
    * ``OS::Nova::Server`` property metadata key value ``vf_module_name``
    * ``OS::Nova::Server`` property metadata key value ``vm_role``
    * ``OS::Nova::Server`` property metadata key value ``vf_module_index``
    * ``OS::Nova::Server`` property metadata key value ``workload_context``
    * ``OS::Nova::Server`` property metadata key value ``environment_context``
    * ``OS::Neutron::Port`` property ``fixed_ips``, map property ``ip_address``
    * ``OS::Neutron::Port`` property ``fixed_ips``, map property ``subnet``
    * ``OS::Neutron::Port`` property ``allowed_address_pairs``, map property
      ``ip_address``
    * ``OS::Neutron::Port`` property ``network``
    * ``OS::ContrailV2::VirtualMachineInterface`` property
      ``virtual_network_refs``
    * ``OS::ContrailV2::VirtualMachineInterface`` property
      ``virtual_machine_interface_allowed_address_pairs``, map property
      ``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``
    * ``OS::ContrailV2::InstanceIP`` property ``instance_ip_address``
    * ``OS::ContrailV2::InstanceIP`` property ``subnet_uuid``
    

Requirements Removed
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    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.
    

.. container:: note

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-35666`

    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``).
    

.. container:: note

    :need:`R-22688`

    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_id``
    * If the network name in is used to reference the network, the output
      parameter name in the base template **MUST** follow the naming convention
      ``int_{network-role}_net_name``

    ``{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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    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.
    

.. container:: note

    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.
    

.. container:: note

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-00011`

    A VNF's Heat Orchestration Template's parameter defined
    in a nested YAML file
    **SHOULD NOT** have a parameter constraint defined.
    

.. container:: note

    :need:`R-88863`

    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

    :need:`R-10834`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-81339`

    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]ml``

     2.) ``<text>_base.y[a]ml``

     3.) ``base.y[a]ml``

     4.) ``<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
~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-589037`

    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::Volume`` resources
    * one or more ``OS::Heat::ResourceGroup`` resources that call a nested YAML
      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

    :need:`R-87247`

    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

    :need:`R-76057`

    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

    :need:`R-90748`

    A VNF's Heat Orchestration Template's Resource ``OS::Cinder::Volume``
    **MAY** be defined in an Incremental Module.
    

.. container:: note

    :need:`R-03251`

    A VNF's Heat Orchestration Template's Resource ``OS::Cinder::Volume``
    **MAY** be defined in a Cinder Volume Module.
    

.. container:: note

    :need:`R-46119`

    A VNF's Heat Orchestration Template's Resource ``OS::Cinder::Volume``
    **MAY** be defined in a Base Module.
    

Requirements Removed
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    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
~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-348813`

    The VNF's Heat Orchestration Template's ZIP file **MUST NOT** include
    a binary image file.
    

.. container:: note

    :need:`R-511776`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-52753`

    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

    :need:`R-22608`

    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

    :need:`R-20547`

    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

    :need:`R-07443`

    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

    :need:`R-89913`

    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
~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-599443`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-61001`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    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
~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-177937`

    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
~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-484843`

    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
~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-24632`

    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

    :need:`R-535009`

    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
~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-596064`

    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
~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-64064`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-65486`

    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

    :need:`R-146092`

    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
    

.. container:: note

    :need:`R-221914`

    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.
    

.. container:: note

    :need:`R-293901`

    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.
    

.. container:: note

    :need:`R-57019`

    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
    

.. container:: note

    :need:`R-795126`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-10087`

    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

    :need:`R-40820`

    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**
    

.. container:: note

    :need:`R-01123`

    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
~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-506221`

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

Requirements Changed
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-51347`

    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

    :need:`R-87234`

    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
~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-130206`

    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".
    

.. container:: note

    :need:`R-787965`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-256347`

    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.
    

.. container:: note

    :need:`R-106240`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-11690`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-53310`

    A VNF's Heat Orchestration Template's Resource
    ``OS::ContrailV2::InstanceIp`` Resource ID
    that is configuring an IPv4 Address on a virtual machine interface
    (i.e., OS::ContrailV2::VirtualMachineInterface)
    attached to an 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.
    * ``IP`` signifies that an IPv4 address is being configured
    * ``{index}`` references the instance of the IPv4 address configured
      on the virtual machine interface.  The ``{index}`` is a numeric value
      that **MUST** start at zero on an
      instance of a virtual machine interface and **MUST** increment by one
      each time a new IPv4 address is configured on the
      virtual machine interface.
    

.. container:: note

    :need:`R-87563`

    A VNF's Heat Orchestration Template's Resource
    ``OS::ContrailV2::InstanceIp`` Resource ID
    that is configuring an IPv6 Address on a virtual machine interface
    (i.e., OS::ContrailV2::VirtualMachineInterface)
    attached to an 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_IP`` signifies that an IPv6 address is being configured
    * ``{index}`` references the instance of the IPv6 address configured
      on the virtual machine interface.  The ``{index}`` is a numeric value
      that **MUST** start at zero on an
      instance of a virtual machine interface and **MUST** increment by one
      each time a new IPv6 address is configured on the
      virtual machine interface.
    

.. container:: note

    :need:`R-62187`

    A VNF's Heat Orchestration Template's Resource
    ``OS::ContrailV2::InstanceIp`` Resource ID
    that is configuring an IPv4 Address on a virtual machine interface
    (i.e., OS::ContrailV2::VirtualMachineInterface)
    attached to an 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.
    * ``IP`` signifies that an IPv4 address is being configured
    * ``{index}`` references the instance of the IPv4 address configured
      on the virtual machine interface.  The ``{index}`` is a numeric value
      that **MUST** start at zero on an
      instance of a virtual machine interface and **MUST** increment by one
      each time a new IPv4 address is configured on the
      virtual machine interface.
    

.. container:: note

    :need:`R-46128`

    A VNF's Heat Orchestration Template's Resource
    ``OS::ContrailV2::InstanceIp`` Resource ID
    that is configuring an IPv6 Address on a virtual machine interface
    (i.e., OS::ContrailV2::VirtualMachineInterface)
    attached to an 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_IP`` signifies that an IPv6 address is being configured
    * ``{index}`` references the instance of the IPv6 address configured
      on the virtual machine interface.  The ``{index}`` is a numeric value
      that **MUST** start at zero on an
      instance of a virtual machine interface and **MUST** increment by one
      each time a new IPv6 address is configured on the
      virtual machine interface.
    

Requirements Removed
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    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}``
    * ``IP`` signifies that an IPv4 address is being configured
    * ``{index}`` is the index of the IPv4 address
    

.. container:: note

    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_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

    :need:`R-14447`

    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-type
    * ``RST`` signifies 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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-50468`

    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.
    

.. container:: note

    :need:`R-96253`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-99110`

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

    * ``int_{network-role}_network``

    VNF Heat Orchestration Templates can only create 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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-87004`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-86497`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-68520`

    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).
    

.. container:: note

    :need:`R-27469`

    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).
    

.. container:: note

    :need:`R-26351`

    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.
    

.. container:: note

    :need:`R-20453`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-59434`

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

    * ``int_{network-role}_subnet_{index}``

    where

    * ``{network-role}`` is the network-role
    * ``{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

    :need:`R-24997`

    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).
    

.. container:: note

    :need:`R-65516`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-29751`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-85734`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    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
~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-681859`

    A VNF's Heat Orchestration Template's ``OS::Neutron::Port`` resource's

    * Resource ID (defined in R-20453)
    * property ``network`` parameter name (defined in R-62983 and
      R-86182)
    * property ``fixed_ips``, map property ``ip_address`` parameter name
      (defined in R-40971, R-04697, R-71577, R-23503, R-78380, R-85235,
      R-27818, and R-29765)
    * property ``fixed_ips``, map property ``subnet`` parameter name
      (defined in R-62802, R-15287, R-84123, R-76160)
    * property ``allowed_address_pairs`` parameter name (defined in
      R-41492 and R-83418)

    **MUST** contain the identical ``{network-role}``.
    

Requirements Removed
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    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.
    

.. container:: note

    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.
    

.. container:: note

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    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
~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-41493`

    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 ``string`` or type
    ``comma_delimited_list``.

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

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

Requirements Changed
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-35735`

    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 the ``OS::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.
    

.. container:: note

    :need:`R-83412`

    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.
    

.. container:: note

    :need:`R-41492`

    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 the ``OS::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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    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.
    

.. container:: note

    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.
    

.. container:: note

    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.
    

.. container:: note

    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.
    

.. container:: note

    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
~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-717227`

    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.
    

.. container:: note

    :need:`R-805572`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-78380`

    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 the
      ``OS::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
    

.. container:: note

    :need:`R-71577`

    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 the
      ``OS::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
    

.. container:: note

    :need:`R-40971`

    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 the ``OS::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
    

.. container:: note

    :need:`R-27818`

    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 the ``OS::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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-86182`

    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_id`` if the
        network UUID value is used to reference the network
      * follow the naming convention ``int_{network-role}_net_name`` if the
        network name in is used to reference the network.

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

Requirements Removed
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-304011`

    A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource's

    * Resource ID (defined in R-29751)
    * property ``image`` parameter name (defined in R-58670)
    * property ``flavor`` parameter name (defined in R-45188)
    * property ``name`` parameter name (defined in R-54171 & R-87817)
    * property ``networks`` map property ``port`` value which is a
      ``OS::Neutron::Port`` Resource ID (defined in R-20453)
      referenced using the intrinsic function ``get_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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-54171`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    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}``.
    

.. container:: note

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-98450`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    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
~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-100410`

    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

    :need:`R-50816`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    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
~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-100400`

    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

    :need:`R-68023`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-95430`

    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_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

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-96634`

    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

    :need:`R-26881`

    The VNF provider **MUST** provide the binaries and images
    needed to instantiate the VNF (VNF and VNFC images).
    

.. container:: note

    :need:`R-35851`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-44569`

    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

    :need:`R-40827`

    The VNF or PNF provider **MUST** enumerate all of the open
    source licenses their VNF or PNF(s) incorporate.
    

.. container:: note

    :need:`R-44125`

    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

    :need:`R-97293`

    The VNF or PNF provider **MUST NOT** require audits
    of Service Provider's business.
    

.. container:: note

    :need:`R-85991`

    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.
    

.. container:: note

    :need:`R-47849`

    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.
    

.. container:: note

    :need:`R-85653`

    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

    :need:`R-89571`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-75608`

    The VNF or PNF provider **MUST** provide playbooks to be loaded
    on the appropriate Ansible Server.
    

.. container:: note

    :need:`R-16777`

    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.
    

.. container:: note

    :need:`R-46567`

    The VNF or PNF Package **MUST** include configuration scripts
    for boot sequence and configuration.
    

.. container:: note

    :need:`R-16065`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-18525`

    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.
    

.. container:: note

    :need:`R-13390`

    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

    :need:`R-30278`

    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

    :need:`R-33904`

    The VNF or PNF Package **MUST** include documentation for each KPI, provide
    lower and upper limits.
    

.. container:: note

    :need:`R-69877`

    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

    :need:`R-01556`

    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

    :need:`R-16875`

    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.
    

.. container:: note

    :need:`R-22680`

    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.
    

.. container:: note

    :need:`R-33694`

    The VNF or PNF Package **MUST** include documentation to when applicable,
    provide calculators needed to convert raw data into appropriate reporting
    artifacts.
    

.. container:: note

    :need:`R-86235`

    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.
    

.. container:: note

    :need:`R-73560`

    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

    :need:`R-53598`

    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

    :need:`R-48596`

    The VNF or PNF Documentation Package **MUST** describe
    the characteristics for the VNF or PNF reliability and high availability.
    

.. container:: note

    :need:`R-01478`

    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.
    

.. container:: note

    :need:`R-90632`

    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

    :need:`R-22888`

    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.
    

.. container:: note

    :need:`R-42018`

    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

    :need:`R-35960`

    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

    :need:`R-56815`

    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

    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.
    

.. container:: note

    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 <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

    :need:`R-025941`

    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.
    

.. container:: note

    :need:`R-816745`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-98617`

    The VNF Provider **MUST** provide documentation regarding any dependency
    (e.g. affinity, anti-affinity) the VNF has on other VNFs and resources.
    

.. container:: note

    :need:`R-36280`

    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

    :need:`R-00068`

    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.
    

.. container:: note

    :need:`R-69565`

    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.
    

.. container:: note

    :need:`R-22346`

    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

    :need:`R-384337`

    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

    :need:`R-84366`

    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.
    

.. container:: note

    :need:`R-00156`

    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).
    

.. container:: note

    :need:`R-12678`

    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

    :need:`R-66070`

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-58775`

    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.
    

.. container:: note

    :need:`R-43958`

    The VNF Documentation Package **MUST** describe
    the tests that were conducted by the VNF provider and the test results.
    

.. container:: note

    :need:`R-04298`

    The VNF provider **MUST** provide their testing scripts to
    support testing.
    

VNF Resiliency > Monitoring & Dashboard
---------------------------------------


Requirements Changed
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    :need:`R-34957`

    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

    :need:`R-05201`

    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.
    

.. container:: note

    :need:`R-69014`

    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.
    

.. container:: note

    :need:`R-26506`

    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: ``_int`` or ``int_``
      or ``_int_``
    * **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

    :need:`R-01455`

    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::Server`` resource property ``flavor`` value

      2.) ``OS::Nova::Server`` resource property ``image`` value

      3.) 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
~~~~~~~~~~~~~~~~~~~~
    

.. container:: note

    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.
    

.. container:: note

    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::Server`` property ``availability_zone``
     parameter **MUST NOT** be prefixed with a common ``{vm-type}`` identifier,

     2.) The Resource ``OS::Nova::Server`` eight mandatory and optional
     ``metadata``
     parameters (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.