.. Copyright 2017 AT&T Intellectual Property. All rights reserved.
-**ONAP Management Requirements**
-=====================================
+ONAP Management Requirements
+============================
The ONAP platform is the part of the larger Network Function
Virtualization/Software Defined Network (NFV/SDN) ecosystem that
Resource Description
^^^^^^^^^^^^^^^^^^^^^^
-* R-77707 The VNF provider **MUST** include a Manifest File that
- contains a list of all the components in the VNF package.
+* 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. The document must include information and
- tools for:
-
- - ONAP to deploy and configure (initially and ongoing) the xNF
- application(s) (e.g., NETCONF APIs). Includes description of
- configurable parameters for the xNF and whether the parameters
- can be configured after xNF instantiation.
- - ONAP to monitor the health of the xNF (conditions that require
- healing and/or scaling responses). 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.
- - Runtime lifecycle events and related actions (e.g., control
- responses, tests) which can be performed for the xNF.
-
+* 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
Resource Configuration
^^^^^^^^^^^^^^^^^^^^^^^
-* R-89571 The xNF **MUST** support and provide artifacts for
- configuration management using at least one of the following
- technologies:
-
- - NETCONF/YANG
- - Chef
- - Ansible
+* 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.
+ 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-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 Appendix A.
+ 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.
* 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 Appendix B.
+ 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.
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. The document 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.
- - All events, severity level (e.g., informational, warning, error)
- and descriptions including causes/fixes if applicable for the event.
- - 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.
-
+ 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. The documentation must include a list of:
-
- - Monitoring parameters/counters exposed for virtual resource
- management and xNF application management.
- - KPIs and metrics that need to be collected at each VM for capacity
- planning and performance management purposes.
- - The monitoring parameters 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.
- - For each KPI, provide lower and upper limits.
- - When relevant, provide a threshold crossing alert point for
- each KPI and describe the significance of the threshold crossing.
- - For each KPI, identify the suggested actions that need to be
- performed when a threshold crossing alert event is recorded.
- - Describe any requirements for the monitoring component of tools
- for Network Cloud automation and management to provide these records
- to components of the xNF.
- - When applicable, provide calculators needed to convert raw data
- into appropriate reporting artifacts.
-
+ (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).
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.
- - Network connections, interface connections, internal and external to VNF.
- - High availability redundancy model.
- - Scaling/growth VM specifications.
-
- Note: Must comply with the *Heat requirements in 5.b*.
+ 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 VNF provider **MUST** describe scaling capabilities
- to manage scaling characteristics of the VNF.
+* R-96634 The xNF provider **MUST** describe scaling capabilities
+ to manage scaling characteristics of the xNF.
Testing
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
- Appendix C. Note: License metadata support in ONAP is not currently
- available and planned for 1Q 2018.
+ Tables C1 to C8 in the Appendix. Note: License metadata support in
+ ONAP is not currently available and planned for 1Q 2018.
Configuration Management
---------------------------------------------------
* R-65641 The xNF **MUST** support ONAP Controller’s **UpgradeBackOut**
command.
+Virtual Function - Container Recovery Requirements
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+As part of life cycle management, for Cloud environment, VNFs need to
+support a set of basic recovery capabilities to maintain the health
+and extend the life of the VNF, eliminating and reducing the frequency
+that an entire VNF needs to be rebuilt or re-instantiated to recover one
+or more of its containers. For instance, a VNF in an Openstack environment
+is composed of one or more containers called VMs (Virtual Machines). During
+the life of a VNF it is expected that Cloud infrastructure hardware will
+fail or they would need to be taken down for maintenance or hardware and
+software upgrades (e.g. firmware upgrades, HostOS (Hypervisor), power
+maintenance, power outages, etc.) To deal with such life cycle events
+without having to rebuild entire VNFs or even entire sites these basic
+recovery capabilities of individual containers, Virtual Machines or other,
+must be supported.
+
+* R-11790 The VNF **MUST** support ONAP Controller’s
+ **Restart (stop/start or reboot)** command.
+* R-56218 The VNF **MUST** support ONAP Controller’s Migrate command that
+ moves container (VM) from a live Physical Server / Compute Node to
+ another live Physical Server / Compute Node.
+
+NOTE: Container migrations MUST be transparent to the VNF and no more
+intrusive than a stop, followed by some down time for the migration to
+be performed from one Compute Node / Physical Server to another, followed
+by a start of the same VM with same configuration on the new Compute
+Node / Physical Server.
+
+* R-38001 The VNF MUST support ONAP Controller’s **Rebuild** command.
+* R-76901 VNF MUST support a container rebuild mechanism based on existing
+ image (e.g. Glance image in Openstack environment) or a snapshot.
+
HealthCheck and Failure Related Commands
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[RFC6243].
* R-59610 The xNF **MUST** implement the data model discovery and
download as defined in [RFC6022].
-* R-87662 The xNF **SHOULD** implement the NETCONF Event Notifications
- [RFC5277].
* R-93443 The xNF **MUST** define all data models in YANG [RFC6020],
and the mapping to NETCONF shall follow the rules defined in this RFC.
* R-26115 The xNF **MUST** follow the data model upgrade rules defined
the supplied YANG code and associated NETCONF servers.
* R-60656 The xNF **MUST** support sub tree filtering.
* R-80898 The xNF **MUST** support heartbeat via a <get> with null filter.
-* R-06617 The xNF **MUST** support get-schema (ietf-netconf-monitoring)
- to pull YANG model over session.
* R-25238 The xNF PACKAGE **MUST** validated YANG code using the open
source pyang [1]_ program using the following commands:
* R-63953 The xNF **MUST** have the echo command return a zero value
otherwise the validation has failed
-* R-26508 The xNF **MUST** support NETCONF server that can be
- mounted on OpenDaylight (client) and perform the following operations:
-
- - Modify, update, change, rollback configurations using each
- configuration data element.
- - Query each state (non-configuration) data element.
- - Execute each YANG RPC.
- - Receive data through each notification statement.
-
+* R-26508 The xNF **MUST** support a NETCONF server that can be mounted on
+ OpenDaylight (client) and perform the operations of: modify, update,
+ change, rollback configurations using each configuration data element,
+ query each state (non-configuration) data element, execute each YANG
+ RPC, and receive data through each notification statement.
The following requirements provides the Yang models that suppliers must
* R-28545 The xNF **MUST** conform its YANG model to RFC 6060,
“YANG - A Data Modeling Language for the Network Configuration
Protocol (NETCONF)”
-* R-29967 The xNF **MUST** conform its YANG model to RFC 6022,
- “YANG module for NETCONF monitoring”.
* R-22700 The xNF **MUST** conform its YANG model to RFC 6470,
“NETCONF Base Notifications”.
* R-10353 The xNF **MUST** conform its YANG model to RFC 6244,
* R-87564 The xNF **SHOULD** conform its YANG model to RFC 7317,
“A YANG Data Model for System Management”.
* R-24269 The xNF **SHOULD** conform its YANG model to RFC 7407,
- “A YANG Data Model for SNMP Configuration”.
+ “A YANG Data Model for SNMP Configuration”, if Netconf used to
+ configure SNMP engine.
The NETCONF server interface shall fully conform to the following
NETCONF RFCs.
trigger push jobs against FQDNs of endpoints for a xNF, if required.
* R-47068 The xNF **MAY** expose a single endpoint that is
responsible for all functionality.
-* R-67114 The xNF **MUST** be installed with:
-
- - Chef-Client >= 12.0
- - Chef push jobs client >= 2.0
+* R-67114 The xNF **MUST** be installed with Chef-Client >= 12.0 and
+ Chef push jobs client >= 2.0.
Chef Roles/Requirements
++++++++++++++++++++++++++
* R-35401 The xNF **MUST** support SSH and allow SSH access by the
Ansible server for the endpoint VM(s) and comply with the Network
Cloud Service Provider guidelines for authentication and access.
-* R-82018 The VNF **MUST** load the Ansible Server SSH public key onto VNF
+* R-82018 The xNF **MUST** load the Ansible Server SSH public key onto xNF
VM(s) as part
of instantiation. This will allow the Ansible Server to authenticate
to perform post-instantiation configuration without manual intervention
- and without requiring specific VNF login IDs and passwords.
+ and without requiring specific xNF login IDs and passwords.
CAUTION: For VNFs 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.
-* R-92866 The VNF **MUST** include as part of post-instantiation
- configuration done by Ansible Playbooks the removal/update of SSH
- public keys loaded through instantiation to support Ansible. This may
- include download and install of new SSH public keys.
-* R-91745 The VNF **MUST** update the Ansible Server and other entities
+* R-92866 The xNF **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 download and install of
+ new SSH keys and new mechanized IDs.
+* R-91745 The xNF **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.
re-instantiate VNF VMs and then re-run playbook(s)). Backing up updated
files also recommended to support rollback when soft rollback is feasible.
-* R-58301 The VNF **SHOULD NOT** use playbooks that make requests to
+* R-58301 The xNF **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 Playbooks.
action requests to APPC; these are triggered as a response to an event
or correlated events published to Event Bus.
-* R-02651 The VNF **SHOULD** use the Ansible backup feature to save a
+* R-02651 The xNF **SHOULD** use the Ansible backup feature 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.
-* R-43353 The VNF **MUST** return control from Ansible Playbooks only
+* R-43353 The xNF **MUST** return control from Ansible Playbooks only
after tasks 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
{
"identifier": "VNF",
"state": "unhealthy",
- "info": "Error in following VM(s). Check hcstatus files under /tmp/ccfx9901v for details",
+ "info": "Error in following VM(s). Check hcstatus files
+ under /tmp/ccfx9901v for details",
"fault": [
"vfdb9904vm001",
"vfdb9904vm002"
{
"identifier": "VNF",
"state": "unhealthy",
- "info": "Error in following VM(s). Check hcstatus files under /tmp/ccfx9901v for details",
+ "info": "Error in following VM(s). Check hcstatus files
+ under /tmp/ccfx9901v for details",
"fault": [
"vfdb9904vm001",
"vfdb9904vm002"
JSON
~~~~~~~~~~~~~~~~~~
-* R-19624 The xNF **MUST** encode and serialize content delivered to ONAP using JSON (RFC 7159) plain text format. High-volume data
+* R-19624 The xNF **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 [5]_ data format are described using JSON.
+ Note:
+
- JSON plain text format is preferred for moderate volume data sets
(option 1), as JSON has the advantage of having well-understood simple
processing and being human-readable without additional decoding. Examples
* R-98191 The xNF **MUST** vary the frequency that asynchronous data
is delivered based on the content and how data may be aggregated or
- grouped together. 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.
-
+ 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 function’s needs for management. For example,
Service Provider may choose to vary the frequency of collection between
only one collector address for a xNF. In this case, the network will
promptly resolve connectivity problems caused by a collector or network
failure transparently to the xNF.
-* R-81777 The VNF **MUST** be configured with initial address(es) to use
+* R-81777 The xNF **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 using PUTs to a
+ ONAP-defined policies delivered from ONAP to the xNF using PUTs to a
RESTful API, in the same manner that other controls over data reporting
will be controlled by policy.
-* R-08312 The xNF **MAY** use other options which are expected to include:
-
- - REST delivery of binary encoded data sets.
- - 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.
- - 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 xNFs. This is not preferred. Preferred is to
- reorganize the data into more frequent or more focused data sets, and
- deliver these by REST or TCP as appropriate.
- - REST for synchronous data, using RESTCONF (e.g., for xNF state polling).
-
+* R-08312 The xNF **MAY** use another option which is expected to include REST
+ delivery of binary encoded data sets.
+* R-79412 The xNF **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.
+* R-01033 The xNF **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 xNFs.
+ (Preferred is to reorganize the data into more frequent or more focused data
+ sets, and deliver these by REST or TCP as appropriate.)
+* R-63229 The xNF **MAY** use another option which is expected to include REST
+ for synchronous data, using RESTCONF (e.g., for xNF state polling).
* R-03070 The xNF **MUST**, by ONAP Policy, provide the ONAP addresses
as data destinations for each xNF, and may be changed by Policy while
the xNF is in operation. We expect the xNF to be capable of redirecting
as those requests are received, as a synchronous response.
* R-34660 The xNF **MUST** use the RESTCONF/NETCONF framework used by
the ONAP configuration subsystem for synchronous communication.
-* R-86585 The VNF **MUST** use the YANG configuration models and RESTCONF
+* R-86586 The xNF **MUST** use the YANG configuration models and RESTCONF
[RFC8040] (https://tools.ietf.org/html/rfc8040).
* R-11240 The xNF **MUST** respond with content encoded in JSON, as
described in the RESTCONF specification. This way the encoding of a
This option is not currently supported in ONAP and it is currently
under consideration.
-.. [6]
- https://wiki.opnfv.org/display/PROJ/VNF+Event+Stream
-
.. |image0| image:: Data_Model_For_Event_Records.png
:width: 7in
:height: 8in
.. |image3| image:: Protocol_Buffers_Driven_Model.png
:width: 4.74in
:height: 3.3in
+
Code Review / vnfrqts / requirements.git / blobdiff