path: root/docs/Chapter7/VNF-On-boarding-and-package-management.rst

.. This work is licensed under a Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
.. Copyright 2017 AT&T Intellectual Property.  All rights reserved.


VNF On-boarding and package management
--------------------------------------

Design Definition
^^^^^^^^^^^^^^^^^^

The ONAP Design Time Framework provides the ability to design NFV
resources including VNFs, Services, and products. The VNF provider must
provide VNF packages that include a rich set of recipes, management and
functional interfaces, policies, configuration parameters, and
infrastructure requirements that can be utilized by the ONAP Design
module to onboard and catalog these resources. Initially this
information may be provided in documents, but in the near future a
method will be developed to automate as much of the transfer of data as
possible to satisfy its long term requirements.

The current VNF Package Requirement is based on a subset of the
Requirements contained in the ETSI Document: ETSI GS NFV-MAN 001 v1.1.1
and GS NFV IFA011 V0.3.0 (2015-10) - Network Functions Virtualization
(NFV), Management and Orchestration, VNF Packaging Specification.

Resource Description
^^^^^^^^^^^^^^^^^^^^^^

* R-77707 The xNF provider **MUST** include a Manifest File that
  contains a list of all the components in the xNF package.
* R-66070 The xNF Package **MUST** include xNF Identification Data to
  uniquely identify the resource for a given xNF provider. The identification
  data must include: an identifier for the xNF, the name of the xNF as was
  given by the xNF provider, xNF description, xNF provider, and version.
* R-69565 The xNF Package **MUST** include documentation describing xNF
  Management APIs, which must include information and tools for ONAP to
  deploy and configure (initially and ongoing) the xNF application(s)
  (e.g., NETCONF APIs) which includes a description of configurable
  parameters for the xNF and whether the parameters can be configured
  after xNF instantiation.
* R-00156 The xNF Package **MUST** include documentation describing xNF
  Management APIs, which must include information and tools for ONAP
  to monitor the health of the xNF (conditions that require healing
  and/or scaling responses).
* R-00068 The xNF Package **MUST** include documentation which includes
  a description of parameters that can be monitored for the xNF and
  event records (status, fault, flow, session, call, control plane,
  etc.) generated by the xNF after instantiation.
* R-12678 The xNF Package **MUST** include documentation which includes a
  description of runtime lifecycle events and related actions (e.g.,
  control responses, tests) which can be performed for the xNF.
* R-84366 The xNF Package **MUST** include documentation describing
  xNF Functional APIs that are utilized to build network and
  application services. This document describes the externally exposed
  functional inputs and outputs for the xNF, including interface
  format and protocols supported.
* R-36280 The xNF provider **MUST** provide documentation describing
  xNF Functional Capabilities that are utilized to operationalize the
  xNF and compose complex services.
* R-98617 The xNF provider **MUST** provide information regarding any
  dependency (e.g., affinity, anti-affinity) with other xNFs and resources.

Resource Configuration
^^^^^^^^^^^^^^^^^^^^^^^

* R-89571 The xNF **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 xNF providor.

Configuration Management via NETCONF/YANG
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

* R-30278 The xNF provider **MUST** provide a Resource/Device YANG model
  as a foundation for creating the YANG model for configuration. This will
  include xNF attributes/parameters and valid values/attributes configurable
  by policy.

Configuration Management via Chef
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

* R-13390 The xNF provider **MUST** provide cookbooks to be loaded
  on the appropriate Chef Server.
* R-18525 The xNF provider **MUST** provide a JSON file for each
  supported action for the xNF.  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.

Configuration Management via Ansible
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

* R-75608 The xNF provider **MUST** provide playbooks to be loaded
  on the appropriate Ansible Server.
* R-16777 The xNF provider **MUST** provide a JSON file for each
  supported action for the xNF.  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.

* R-46567 The xNF Package **MUST** include configuration scripts
  for boot sequence and configuration.
* R-16065 The xNF provider **MUST** provide configurable parameters
  (if unable to conform to YANG model) including xNF attributes/parameters
  and valid values, dynamic attributes and cross parameter dependencies
  (e.g., customer provisioning data).

Resource Control Loop
^^^^^^^^^^^^^^^^^^^^^^^

* R-22888 The xNF provider **MUST** provide documentation for the xNF
  Policy Description to manage the xNF runtime lifecycle. The document
  must include a description of how the policies (conditions and actions)
  are implemented in the xNF.
* R-01556 The xNF Package **MUST** include documentation describing the
  fault, performance, capacity events/alarms and other event records
  that are made available by the xNF.
* R-16875 The xNF Package **MUST** include documentation which must include
  a unique identification string for the specific xNF, a description of
  the problem that caused the error, and steps or procedures to perform
  Root Cause Analysis and resolve the issue.
* R-35960 The xNF 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.
* R-42018 The xNF Package **MUST** include documentation which must include
  all events (fault, measurement for xNF Scaling, Syslogs, State Change
  and Mobile Flow), that need to be collected at each VM, VNFC (defined in `VNF Guidelines <http://onap.readthedocs.io/en/latest/submodules/vnfrqts/guidelines.git/docs/vnf_guidelines/vnf_guidelines.html#a-glossary>`__ ) and for the overall xNF.
* R-27711 The xNF provider **MUST** provide an XML file that contains a
  list of xNF error codes, descriptions of the error, and possible
  causes/corrective action.
* R-01478 The xNF Package **MUST** include documentation describing all
  parameters that are available to monitor the xNF after instantiation
  (includes all counters, OIDs, PM data, KPIs, etc.) that must be
  collected for reporting purposes.
* R-73560 The xNF Package **MUST** include documentation about monitoring
  parameters/counters exposed for virtual resource management and xNF
  application management.
* R-90632 The xNF Package **MUST** include documentation about KPIs and
  metrics that need to be collected at each VM for capacity planning
  and performance management purposes.
* R-86235 The xNF 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 xNF and those that must be exercised by the xNF in order to perform
  its function.
* R-33904 The xNF Package **MUST** include documentation for each KPI, provide
  lower and upper limits.
* R-53598 The xNF Package **MUST** include documentation to, when relevant,
  provide a threshold crossing alert point for each KPI and describe the
  significance of the threshold crossing.
* R-69877 The xNF Package **MUST** include documentation for each KPI,
  identify the suggested actions that need to be performed when a
  threshold crossing alert event is recorded.
* R-22680 The xNF Package **MUST** include documentation that describes
  any requirements for the monitoring component of tools for Network
  Cloud automation and management to provide these records to components
  of the xNF.
* R-33694 The xNF Package **MUST** include documentation to when applicable,
  provide calculators needed to convert raw data into appropriate reporting
  artifacts.
* R-56815 The xNF Package **MUST** include documentation describing
  supported xNF scaling capabilities and capacity limits (e.g., number
  of users, bandwidth, throughput, concurrent calls).
* R-48596 The xNF Package **MUST** include documentation describing
  the characteristics for the xNF reliability and high availability.
* 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://github.com/att/evel-test-collector/tree/master/docs/att_interface_definition>`__)

Compute, Network, and Storage Requirements
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

* R-35851 The xNF Package **MUST** include xNF topology that describes
  basic network and application connectivity internal and external to the
  xNF including Link type, KPIs, Bandwidth, latency, jitter, QoS (if
  applicable) for each interface.
* R-97102 The VNF Package **MUST** include VM requirements via a Heat
  template that provides the necessary data for VM specifications
  for all VNF components - for hypervisor, CPU, memory, storage.
* R-20204 The VNF Package **MUST** include VM requirements via a Heat
  template that provides the necessary data for network connections,
  interface connections, internal and external to VNF.
* R-44896 The VNF Package **MUST** include VM requirements via a Heat
  template that provides the necessary data for high availability
  redundancy model.
* R-55802 The VNF Package **MUST** include VM requirements via a Heat
  template that provides the necessary data for scaling/growth VM
  specifications.

  Note: Must comply with the *Heat requirements in 5.b*.

* R-26881 The xNF provider **MUST** provide the binaries and images
  needed to instantiate the xNF (xNF and VNFC images).
* R-96634 The xNF provider **MUST** describe scaling capabilities
  to manage scaling characteristics of the xNF.


Testing
^^^^^^^^^^

* R-43958 The xNF Package **MUST** include documentation describing
  the tests that were conducted by the xNF providor and the test results.
* R-04298 The xNF provider **MUST** provide their testing scripts to
  support testing.
* R-58775 The xNF provider **MUST** provide software components that
  can be packaged with/near the xNF, if needed, to simulate any functions
  or systems that connect to the xNF system under test. This component is
  necessary only if the existing testing environment does not have the
  necessary simulators.

Licensing Requirements
^^^^^^^^^^^^^^^^^^^^^^^

* R-85653 The xNF **MUST** provide metrics (e.g., number of sessions,
  number of subscribers, number of seats, etc.) to ONAP for tracking
  every license.
* R-44125 The xNF 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.
* R-40827 The xNF provider **MUST** enumerate all of the open
  source licenses their xNF(s) incorporate.
* R-97293 The xNF provider **MUST NOT** require audits of
  Service Provider’s business.
* R-44569 The xNF provider **MUST NOT** require additional
  infrastructure such as a xNF provider license server for xNF provider
  functions and metrics.
* R-13613 The VNF **MUST** provide clear measurements for licensing
  purposes to allow automated scale up/down by the management system.
* R-27511 The VNF provider **MUST** provide the ability to scale
  up a VNF provider supplied product during growth and scale down a
  VNF provider supplied product during decline without “real-time”
  restrictions based upon VNF provider permissions.
* R-85991 The xNF provider **MUST** provide a universal license key
  per xNF to be used as needed by services (i.e., not tied to a VM
  instance) as the recommended solution. The xNF provider may provide
  pools of Unique xNF License Keys, where there is a unique key for
  each xNF instance as an alternate solution. Licensing issues should
  be resolved without interrupting in-service xNFs.
* R-47849 The xNF provider **MUST** support the metadata about
  licenses (and their applicable entitlements) as defined in this
  document for xNF software, and any license keys required to authorize
  use of the xNF software.  This metadata will be used to facilitate
  onboarding the xNF 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.

.. |image0| image:: Data_Model_For_Event_Records.png
      :width: 7in
      :height: 8in

.. |image1| image:: VES_JSON_Driven_Model.png
      :width: 5in
      :height: 3in

.. |image2| image:: YANG_Driven_Model.png
      :width: 5in
      :height: 3in

.. |image3| image:: Protocol_Buffers_Driven_Model.png
      :width: 4.74in
      :height: 3.3in