.. 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
+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.
+* 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 Appendix A.
+* 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 Appendix B.
+* 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.
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
---------------------------------------------------
-ONAP interacts directly with VNFs through its Network and Application
-Adapters to perform configuration activities within NFV environment.
-These activities include service and resource
-configuration/reconfiguration, automated scaling of resources, service
-and resource removal to support runtime lifecycle management of VNFs and
-services. The Adapters employ a model driven approach along with
-standardized APIs provided by the VNF developers to configure resources
-and manage their runtime lifecycle.
+Controller Interactions With VNF
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+ONAP Controllers (such as APPC) expose a northbound API to clients
+(such as SO) in order for the clients to initiate an activity
+(aka command) on a VNF. ONAP controllers interact with VNFs through
+Network and Application Adapters to perform configuration and other
+lifecycle management activities within NFV environment.
+The standardized models, protocols and mechanisms by which network
+functions are configured are equally applicable to VNFs and PNFs.
+
+This section describes the list of commands that should be supported
+by the VNF. The following sections describe the standard protocols
+that are supported (NETCONF, Chef, Ansible, and REST).
+
+The commands below are expected to be supported on all VNF’s, unless
+noted otherwise, either directly (via the NETCONF or REST interface)
+or indirectly (via a Chef Cookbook or Ansible server). Note that there
+are additional commands offered to northbound clients that are not shown
+below, as these commands either act internally on the Controller itself
+or depend upon network cloud components for implementation (thus, these
+actions do not put any special requirement on the VNF provider).
+
+The commands allow for parametric data to be passed from the controller
+to the VNF or Ansible/Chef server in the request. The format of the
+parameter data can be either xml (for NETCONF) or JSON (for Ansible,
+Chef, or REST).
+
+Configuration Commands
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**Configure**: The Controller client is requesting that a post-instantiation
+configuration be applied to the target VNF instance. After the Configure
+action is completed, the VNF instance should be ready for service.
+Note that customer specific configurations may need to be applied using
+the ConfigModify action.
+
+**ConfigModify**: The Controller client is requesting a configuration
+update to a subset of the total configuration parameters of a VNF or to
+apply customer specific configurations. The configuration update is
+typically done while the VNF is in service and should not disrupt traffic.
+
+**ConfigBackup**: The Controller client is requesting a backup of the
+configuration parameters where the parameters are stored on the VNF.
+This command is typically requested as part of an orchestration flow
+for scenarios such as a software upgrade. The ConfigBackup is typically
+done while the VNF is not in service (i.e., in a maintenance state).
+When the ConfigBackup command is executed, the current VNF configuration
+parameters are saved in storage that is preserved (if there is an existing
+set of backed up parameters, they are overwritten).
+
+**ConfigRestore**: The Controller client is requesting a restore action of
+the configuration parameters to the VNF that were saved by ConfigBackup
+command. This command is typically requested as part of an orchestration
+flow for scenarios such as a software upgrade where the software upgrade
+may have failed and the VNF needs to be rolled back to the prior configuration.
+When the ConfigRestore command is executed, the VNF configuration parameters
+which were backed to persistent preserved storage are applied to the VNF
+(replacing existing parameters). The ConfigRestore is typically done while
+the VNF is not in service (i.e., in a maintenance state).
+
+**ConfigScaleOut**: The Controller client is requesting that a configuration
+be applied after the VNF instance has been scaled out (i.e., one or more
+additional VM’s instantiated to increase capacity). For some VNF’s,
+ConfigScaleOut is not needed because the VNF is auto-configured after
+scale-out. This command is being introduced in the Beijing release.
+
+**Audit**: The Controller client is requesting that the current (last known
+configuration update) is audited against the running configuration on the VNF.
+
+* R-20741 The xNF **MUST** support ONAP Controller’s **Configure** command.
+* R-19366 The xNF **MUST** support ONAP Controller’s **ConfigModify** command.
+* R-32981 The xNF **MUST** support ONAP Controller’s **ConfigBackup** command.
+* R-48247 The xNF **MUST** support ONAP Controller’s **ConfigRestore** command.
+* R-94084 The xNF **MUST** support ONAP Controller’s **ConfigScaleOut**
+ command.
+* R-56385 The xNF **MUST** support ONAP Controller’s **Audit** command.
+
+LifeCycle Management Related Commands
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**The following commands are needed to support various lifecycle management
+flows where the VNF may need to be removed for service.**
+
+**QuiesceTraffic**: The Controller client is requesting the VNF gracefully
+stop traffic (aka block and drain traffic). The method for quiescing traffic
+is specific to the VNF architecture. The action is completed when all
+(in-flight transactions) traffic has stopped. The VNF remains in an active
+state where the VNF is able to process traffic (initiated using the
+StartTraffic action).
+
+**ResumeTraffic**: The Controller client is requesting the VNF resume
+processing traffic. The method to resume traffic is specific to the VNF
+architecture.
+
+**StopApplication**: The Controller client is requesting that the application
+running on the VNF is stopped gracefully (i.e., without traffic loss).
+This is equivalent to quiescing the traffic and then stopping the application
+processes. The processes can be restarted using the StartApplication command.
+
+**StartApplication**: The Controller client is requesting that the application
+running on the VNF is started. Get ready to process traffic.
+
+**The following commands are needed to support software upgrades, in-place or
+other type of software upgrade. The VNF instance may be removed from service
+for the upgrade.**
+
+**UpgradePrecheck**: The Controller client is requesting a confirmation that
+the VNF can (and needs to) be upgraded to a specific software version
+(specified in the request).
+
+**UpgradeSoftware**: The Controller client is requesting that a (in-place)
+software upgrade be performed on the VNF. The software to be applied is
+pre-loaded to a specified location.
+
+**UpgradePostCheck**: The Controller client is requesting a confirmation that
+the VNF software upgrade has been completed successfully (VNF upgraded to
+the new software version).
+
+**UpgradeBackup**: The Controller client is requesting that the VNF is backed
+up prior to the UpgradeSoftware.
+
+**UpgradeBackOut**: The Controller client is requesting that the VNF upgrade
+is backed out (in the event that the SoftwareUpgrade or UpgradePostCheck
+failed).
+
+* R-12706 The xNF **MUST** support ONAP Controller’s **QuiesceTraffic**
+ command.
+* R-07251 The xNF **MUST** support ONAP Controller’s **ResumeTraffic**
+ command.
+* R-83146 The xNF **MUST** support ONAP Controller’s **StopApplication**
+ command.
+* R-82811 The xNF **MUST** support ONAP Controller’s **StartApplication**
+ command.
+* R-19922 The xNF **MUST** support ONAP Controller’s **UpgradePrecheck**
+ command.
+* R-49466 The xNF **MUST** support ONAP Controller’s **UpgradeSoftware**
+ command.
+* R-45856 The xNF **MUST** support ONAP Controller’s **UpgradePostCheck**
+ command.
+* R-97343 The xNF **MUST** support ONAP Controller’s **UpgradeBackup**
+ command.
+* 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
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**HealthCheck**: The Controller client is requesting a health check over the
+entire scope of the VNF. The VNF must be 100% healthy, ready to take requests
+and provide services, with all VNF required capabilities ready to provide
+services and with all active and standby resources fully ready with no open
+MINOR, MAJOR or CRITICAL alarms.
+
+Note: In addition to the commands above, the Controller supports a set of
+Openstack failure recovery related commands that are executed on-demand or via
+Control Loop at the VM level. The VNF must support these commands in a fully
+automated fashion.
+
+* R-41430 The xNF **MUST** support ONAP Controller’s **HealthCheck**
+ command.
+
+Notes On Command Support Using Controller Southbound Protocols
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The ONAP Controllers are designed to support a standard set of protocols in
+order to communicate with the VNF instance. The supported protocols are
+NETCONF, Ansible, Chef, and REST.
+
+NETCONF and REST require the VNF to implement a server which supports the RPC
+or REST calls.
+
+Ansible and Chef require the use of a Ansible or Chef server which communicates
+with the Controller (northbound) and the VNF VM’s (southbound).
+
+The vendor must select which protocol to support for the commands listed above.
+Notes:
+
+* NETCONF is most suitable for configuration related commands
+
+* Ansible and Chef are suitable for any command.
+ Ansible has the advantage that it is agentless.
+
+* REST is specified as an option only for the HealthCheck.
+
Additional details can be found in the `ONAP Application Controller (APPC) API Guide <http://onap.readthedocs.io/en/latest/submodules/appc.git/docs/APPC%20API%20Guide/APPC%20API%20Guide.html>`_, `ONAP VF-C project <http://onap.readthedocs.io/en/latest/submodules/vfc/nfvo/lcm.git/docs/index.html>`_ and the `ONAP SDNC project <http://onap.readthedocs.io/en/latest/submodules/sdnc/northbound.git/docs/index.html>`_.
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.
-* R-20353 The xNF **MUST** implement at least one of the capabilities
- **:candidate** or **:writable-running**. If both **:candidate** and
+* R-20353 The xNF **MUST** implement both **:candidate** and
+ **:writable-running** capabilities. When both **:candidate** and
**:writable-running** are provided then two locks should be supported.
* R-11499 The xNF **MUST** fully support the XPath 1.0 specification
for filtered retrieval of configuration and other database contents.
[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.
VNF REST APIs
^^^^^^^^^^^^^^^
-Healthcheck is a command for which no NETCONF support exists.
+HealthCheck is a command for which no NETCONF support exists.
Therefore, this must be supported using a RESTful interface
(defined in this section) or with a Chef cookbook/Ansible playbook
(defined in sections `Chef Standards and Capabilities`_ and
be ready to take service requests or be already processing service
requests successfully.
-The VNF must provide a REST formatted GET RPCs to support Healthcheck
+The VNF must provide a REST formatted GET RPCs to support HealthCheck
queries via the GET method over HTTP(s).
The port number, url, and other authentication information is provided
~~~~~~~~~
* R-31809 The xNF **MUST** support the HealthCheck RPC. The HealthCheck
- RPC executes a xNF Provider-defined xNF Healthcheck over the scope of
+ RPC executes a xNF Provider-defined xNF HealthCheck over the scope of
the entire xNF (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
information. If the xNF is unable to run the HealthCheck, return a
standard http error code and message.
-Examples:
+Examples of responses when HealthCheck runs and is able to provide a healthy
+or unhealthy response:
.. code-block:: java
- 200
{
"identifier": "scope represented",
"state": "healthy",
"time": "01-01-1000:0000"
}
- 200
{
"identifier": "scope represented",
"state": "unhealthy",
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
++++++++++++++++++++++++++
- ‘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
+- 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.
* R-15885 The xNF **MUST** Upon completion of the chef-client run,
Ansible allows agentless management of VNFs/VMs/VNFCs via execution
of ‘playbooks’ over ssh. The ‘playbooks’ are a structured set of
-tasks which contain all the necessary data and execution capabilities
+tasks which contain all the necessary resources and execution capabilities
to take the necessary action on one or more target VMs (and/or VNFCs)
of the VNF. ONAP will utilize the framework of an Ansible Server that
-will host and run playbooks to manage VNFs that support Ansible.
+will host all Ansible artifacts and run playbooks to manage VNFs that support
+Ansible.
VNF Configuration via Ansible Requirements
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the Ansible Server for the endpoints (VMs) of a xNF on which playbooks
will be executed. ONAP will initiate requests to the Ansible Server
for invocation of playbooks against these end points [3]_.
-* R-54373 The xNF **MUST** have Python >= 2.7 on the endpoint VM(s)
+* R-54373 The xNF **MUST** have Python >= 2.6 on the endpoint VM(s)
of a xNF on which an Ansible playbook will be executed.
-* R-35401 The xNF **MUST** support SSH and allow SSH access to the
- Ansible server for the endpoint VM(s) and comply with the Network
+* 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 **SHOULD** load the SSH key onto VNF VM(s) as part
+* 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 keys, SSH keys loaded during (heat) instantiation shall be
- preserved and not removed by (heat) embedded scripts.
+ 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 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.
-* R-92866 The VNF **MUST** include as part of post-instantiation
- configuration done by Ansible Playbooks the removal/update of SSH
- keys loaded through instantiation to support Ansible. This may
- include download and install of new SSH keys.
-* R-91745 The VNF **MUST** update the Ansible Server and other entities
- storing and using the SSH key for authentication when the SSH key used
- by Ansible is regenerated/updated.
+ NOTE: Ansible Server itself may be used to upload new SSH public keys
+ onto supported VNFs.
Ansible Playbook Requirements
+++++++++++++++++++++++++++++++
* R-40293 The xNF **MUST** make available playbooks that conform
to the ONAP requirement.
-* R-49396 The xNF **MUST** support each xNF action by invocation of
- **one** playbook [4]_. The playbook will be responsible for executing
+* R-49396 The xNF **MUST** support each ONAP (APPC) xNF action
+ by invocation of **one** playbook [4]_. The playbook will be responsible
+ for executing
all necessary tasks (as well as calling other playbooks) to complete
the request.
* R-33280 The xNF **MUST NOT** use any instance specific parameters
in a playbook.
* R-48698 The xNF **MUST** utilize information from key value pairs
- that will be provided by the Ansible Server as extra-vars during
+ that will be provided by the Ansible Server as "extra-vars" during
invocation to execute the desired xNF action. If the playbook requires
files, they must also be supplied using the methodology detailed in
- the Ansible Server API.
+ the Ansible Server API, unless they are bundled with playbooks, example,
+ generic templates.
The Ansible Server will determine if a playbook invoked to execute a
xNF action finished successfully or not using the “PLAY_RECAP” summary
* R-43253 The xNF **MUST** use playbooks designed to allow Ansible
Server to infer failure or success based on the “PLAY_RECAP” capability.
-* R-50252 The xNF **MUST** write to a specific set of text files that
+ 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).
+* R-50252 The xNF **MUST** write to a specific one text files that
will be retrieved and made available by the Ansible Server if, as part
of a xNF action (e.g., audit), a playbook is required to return any
xNF information. The text files must be written in the same directory as
the one from which the playbook is being executed. A text file must be
- created for each host the playbook run targets/affects, with the name
- ‘<hostname>_results.txt’ into which any desired output from each
+ created for the xNF playbook run targets/affects, with the name
+ ‘<VNFname>_results.txt’ into which any desired output from each
respective VM/xNF must be written.
* R-51442 The xNF **SHOULD** use playbooks that are designed to
automatically ‘rollback’ to the original state in case of any errors
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.
Rationale: Flows that require interactions with Cloud services
- e.g. Openstack shall rely on workflows run by an Orchestrator or
+ 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 Controller such as APPC.
There are policies, as part of Control Loop models, that send remediation
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
already processing service requests successfully.
A successful execution of a health-check playbook shall also create one
- file per VNF VM, named using IP address or VM name followed by
- “_results.txt (<hostname>_results.txt) to indicate health-check was
- executed and completed successfully, example: 1xx.2yy.zzz.105_results.txt,
+ file per VNF VM, named after the VNF instance name followed by
+ “_results.txt (<vnf_instance>_results.txt) to indicate health-check was
+ executed and completed successfully, example: vfdb9904v_results.txt,
with the following contents:
- "status”:"healthy”
+.. code-block:: java
- Example:
+ {
+ "identifier": "VNF",
+ "state": "healthy",
+ "time": "2018-03-16:1139"
+ }
+
+Example:
- $ cat 1xx.2yy.zzz.105_results.txt
+.. code-block:: java
- "status”:"healthy”
+ $ cat vfdb9904v_results.txt
+ {
+ "identifier": "VNF",
+ "state": "healthy",
+ "time": "2018-03-16:1139"
+ }
+..
FAILURE – A health check playbook shall return a non-zero return code in
case VNF is not 100% healthy because one or more VNF application processes
or CRITICAL traps/alarms or because there are issues with the VNF that
need attention even if they do not impact services provided by the VNF.
- A failed health-check playbook shall also create one file per VNF VM,
- named using Playbook Name plus IP address or VM name, followed by
+ A failed health-check playbook shall also create one file per VNF,
+ named after the VNF instance name, followed by
“_results.txt to indicate health-check was executed and found issues
in the health of the VNF. This is to differentiate from failure to
- run health-check playbook or tasks to verify the health of the VNF,
- example: 1xx.2yy.zzz.105_results.txt, with the following contents:
+ run health-check playbook or playbook tasks to verify the health of the VNF,
+ example: vfdb9904v_results.txt, with the following contents:
- "status”:"unhealthy”
+.. code-block:: java
+
+ {
+ "identifier": "VNF",
+ "state": "unhealthy",
+ "info": "Error in following VM(s). Check hcstatus files
+ under /tmp/ccfx9901v for details",
+ "fault": [
+ "vfdb9904vm001",
+ "vfdb9904vm002"
+ ],
+ "time": "2018-03-16:4044"
+ }
+..
Example:
- $ cat 1xx.2yy.zzz.105_results.txt
+.. code-block:: java
- "status”:"unhealthy”
+ $ cat vfdb9904v_results.txt
+ {
+ "identifier": "VNF",
+ "state": "unhealthy",
+ "info": "Error in following VM(s). Check hcstatus files
+ under /tmp/ccfx9901v for details",
+ "fault": [
+ "vfdb9904vm001",
+ "vfdb9904vm002"
+ ],
+ "time": "2018-03-16:4044"
+ }
+..
See `VNF REST APIs`_ for additional details on HealthCheck.
process the request.
-ONAP Controller APIs and Behavior
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Support of Controller Commands And Southbound Protocols
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-ONAP Controllers such as APPC expose a northbound API to clients
-which offer a set of commands. The following commands are expected
-to be supported on all VNF’s if applicable, either directly (via the
-Netconf interface) or indirectly (via a Chef or Ansible server).
-There are additional commands offered to northbound clients that are
-not listed here, as these commands either act internally on the Controller
-itself or depend upon network cloud components for implementation
-(thus, these actions do not put any special requirement on the VNF provider).
-
-The following table summarizes how the VNF must act in response to
-commands from ONAP.
+The following table summarizes the commands and possible protocols selected.
+Note that the HealthCheck can also be supported via REST.
Table 8. ONAP Controller APIs and NETCONF Commands
-+---------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| **Action** | **Description** | **NETCONF Commands** |
-+=====================+==================================================================================================================================================================================================================================================================================+===============================================================================================================================================================================================================================+
-| Action | Queries ONAP Controller for the current state of a previously submitted runtime LCM (Lifecycle Management) action. | There is currently no way to check the request status in NETCONF so action status is managed internally by the ONAP controller. |
-| | | |
-| Status | | |
-+---------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| Audit, Sync | Compare active (uploaded) configuration against the current configuration in the ONAP controller. Audit returns failure if different. Sync considers the active (uploaded) configuration as the current configuration. | The <get-config> operation is used to retrieve the running configuration from the VNF. |
-+---------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| Lock, | Returns true when the given VNF has been locked. | There is currently no way to query lock state in NETCONF so VNF locking and unlocking is managed internally by the ONAP controller. |
-| | | |
-| Unlock, | | |
-| | | |
-| CheckLock | | |
-+---------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| Configure, | Configure applies a post-instantiation configuration the target VNF or VNFC. ConfigModify updates only a subset of the total configuration parameters of a VNF. | The <edit-config> operation loads all or part of a specified configuration data set to the specified target database. If there is no <candidate/> database, then the target is the <running/> database. A <commit> follows. |
-| | | |
-| ConfigModify | | |
-+---------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| Health | Executes a VNF health check and returns the result. A health check is VNF-specific. | This command has no existing NETCONF RPC action. It must be supported either by REST (see `VNF REST APIs`_) or using Ansible or Chef. |
-| | | |
-| Check | | |
-+---------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| StartApplication, | ONAP requests application to be started or stopped on the VNF. These actions do not need to be supported if (1) the application starts automatically after Configure or if the VM’s are started and (2) the application gracefully shuts down if the VM’s are stopped. | These commands have no specific NETCONF RPC action. |
-| | | |
-| StopApplication | | If applicable, these commands must be supported using Ansible or Chef (see Table 9 below). |
-+---------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ConfigBackup, | ONAP requests the VNF configuration parameters to be backed up or restored (replacing existing configuration parameters on the VNF). | These commands have no specific NETCONF RPC action. |
-| | | |
-| ConfigRestore | | They can be supported using Ansible or Chef (see Table 9 below). |
-+---------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-
-Table 9 lists the required Chef and Ansible support for commands from
-ONAP.
-
-Table 9. ONAP Controller APIs and Chef/Ansible Support
-
-+---------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| **Action** | **Chef** | **Ansible** |
-+=====================+==================================================================================================================================================================================================================================================================================================+=============================================================================================================================================================================================================================================================================================+
-| Action | Not needed. ActionStatus is managed internally by the ONAP controller. | Not needed. ActionStatus is managed internally by the ONAP controller. |
-| | | |
-| Status | | |
-+---------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| Audit, Sync | VNF provider must provide any necessary roles, cookbooks, recipes to retrieve the running configuration from a VNF and place it in the respective Node Objects ‘PushJobOutput’ attribute of all nodes in NodeList when triggered by a chef-client run. | VNF provider must provide an Ansible playbook to retrieve the running configuration from a VNF and place the output on the Ansible server in a manner aligned with playbook requirements listed in this document. |
-| | | |
-| | The JSON file for this VNF action is required to set “PushJobFlag” to “True” and “GetOutputFlag” to “True”. The “Node” JSON dictionary must have the run list populated with the necessary sequence of roles, cookbooks, recipes. | The PlaybookName must be provided in the JSON file. |
-| | | |
-| | The Environment and Node values should contain all appropriate configuration attributes. | NodeList must list FQDNs of an example VNF on which to execute playbook. |
-| | | |
-| | NodeList must list sample FQDNs that are required to conduct a chef-client run for this VNF Action. | |
-+---------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| Lock, | Not needed. VNF locking and unlocking is managed internally by the ONAP controller. | Not needed. VNF locking and unlocking is managed internally by the ONAP controller. |
-| | | |
-| Unlock, | | |
-| | | |
-| CheckLock | | |
-+---------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| Configure, | VNF provider must provide any necessary roles, cookbooks, recipes to apply configuration attributes to the VNF when triggered by a chef-client run. All configurable attributes must be obtained from the Environment and Node objects on the Chef Server. | VNF provider must provide an Ansible playbook that can configure the VNF with parameters supplied by the Ansible Server. |
-| | | |
-| ConfigModify | The JSON file for this VNF action should include all configurable attributes in the Environment and/or Node JSON dictionary. | The PlaybookName must be provided in the JSON file. |
-| | | |
-| | The “PushJobFlag” must be set to “True”. | The “EnvParameters” and/or “FileParameters” field values should be provided and contain all configurable parameters for the VNF. |
-| | | |
-| | The “Node” JSON dictionary must have the run list populated with necessary sequence of roles, cookbooks, recipes. This action is not expected to return an output. | NodeList must list FQDNs of an example VNF on which to execute playbook. |
-| | | |
-| | “GetOutputFlag” must be set to “False”. | |
-| | | |
-| | NodeList must list sample FQDNs that are required to conduct a chef-client run for this VNF Action. | |
-+---------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| Health | The VNF level HealthCheck run a check over the entire scope of the VNF (for more details, see `VNF REST APIs`_). It can be supported either via a REST interface or with Chef roles, cookbooks, and recipes. | The VNF level HealthCheck run a check over the entire scope of the VNF (for more details, see `VNF REST APIs`_). It can be supported either via a REST interface or with an Ansible playbook. |
-| | | |
-| Check | | |
-+---------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| StartApplication, | VNF provider must provide roles, cookbooks, recipes to start an application on the VNF when triggered by a chef-client run. If application does not start, the run must fail or raise an exception. If application is already started, or starts successfully, the run must finish successfully. | VNF provider must provide an Ansible playbook to start the application on the VNF. If application does not start, the playbook must indicate failure. If application is already started, or starts successfully, the playbook must finish successfully. |
-| | | |
-| StopApplication | For StopApplication, the application must be stopped gracefully (no loss of traffic). | For StopApplication, the application must be stopped gracefully (no loss of traffic). |
-+---------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ConfigBackup, | VNF provider must provide roles, cookbooks, recipes to backup or restore the configuration parameters on the VNF when triggered by an ECOMP request. | VNF provider must provide an Ansible playbook to backup or restore the configuration parameters on the VNF when triggered by an ECOMP request. |
-| | | |
-| | When the ConfigBackup command is executed, the current VNF configuration parameters are copied over to the Ansible or Chef server (if there is an existing set of backed up parameters, they are overwritten). When the ConfigRestore command is executed, the VNF configuration parameters | When the ConfigBackup command is executed, the current VNF configuration parameters are copied over to the Ansible or Chef server (if there is an existing set of backed up parameters, they are overwritten). When the ConfigRestore command is executed, the VNF configuration parameters |
-| ConfigRestore | which are backed up on the Ansible or Chef server are applied to the VNF (replacing existing parameters). It can be assumed that the VNF is not in service when a ConfigRestore command is executed. | which are backed up on the Ansible or Chef server are applied to the VNF (replacing existing parameters). It can be assumed that the VNF is not in service when a ConfigRestore command is executed. |
-| | | |
-| | If either command fails, the run must fail or raise an exception. | If either command fails, the run must fail or raise an exception. |
-+---------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-
-For information purposes, the following ONAP controller functions are
-planned in the future:
-
-Table 10. Planned ONAP Controller Functions
-
-+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| Action | Description |
-+==================+=================================================================================================================================================================================+
-| UpgradeSoftware | Upgrades the target VNF to a new software version. |
-+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| QuiesceTraffic, | Quiesces traffic (stops traffic gracefully) and resume traffic on the VNF. These commands do not stop the application processes (which is done using StopApplication). |
-| ResumeTraffic | |
-+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-
++-------------+--------------------+--------------------+--------------------+
+|**Command** |**NETCONF Support** |**Chef Support** |**Ansible** |
++=============+====================+====================+====================+
+|General |For each RPC, the |VNF Vendor must |VNF Vendor must |
+|Comments |appropriate RPC |provide any |provide an Ansible |
+| |operation is listed.|necessary roles, |playbook to retrieve|
+| | |cookbooks, recipes |the running |
+| | |to retrieve the |configuration from a|
+| | |running |VNF and place the |
+| | |configuration from |output on the |
+| | |a VNF and place it |Ansible server in |
+| | |in the respective |a manner aligned |
+| | |Node Objects |with playbook |
+| | |‘PushJobOutput’ |requirements listed |
+| | |attribute of all |in this document. |
+| | |nodes in NodeList | |
+| | |when triggered |The PlaybookName |
+| | |by a chef-client |must be provided |
+| | |run. |in the JSON file. |
+| | | | |
+| | |The JSON file for |NodeList must list |
+| | |this VNF action is |IP addresses or DNS |
+| | |required to set |supported FQDNs of |
+| | |“PushJobFlag” to |an example VNF |
+| | |“True” and |on which to |
+| | |“GetOutputFlag” to |execute playbook. |
+| | |“True”. The “Node” | |
+| | |JSON dictionary | |
+| | |must have the run | |
+| | |list populated | |
+| | |with the necessary | |
+| | |sequence of roles, | |
+| | |cookbooks, recipes. | |
+| | | | |
+| | |The Environment | |
+| | |and Node values | |
+| | |should contain all | |
+| | |appropriate | |
+| | |configuration | |
+| | |attributes. | |
+| | | | |
+| | |NodeList must | |
+| | |list sample FQDNs | |
+| | |that are required to| |
+| | |conduct a | |
+| | |chef-client run for | |
+| | |this VNF Action. | |
++-------------+--------------------+--------------------+--------------------+
+|Audit |The <get-config> is |Supported via a |Supported via a |
+| |used to return the |cookbook that |playbook that |
+| |running |returns the running |returns the running |
+| |configuration. |configuration. |configuration. |
++-------------+--------------------+--------------------+--------------------+
+|Configure, |The <edit-config> |Supported via a |Supported via a |
+|ModifyConfig |operation loads all |cookbook that |playbook that |
+| |or part of a |updates the VNF |updates the VNF |
+| |specified data set |configuration. |configuration. |
+| |to the specified | | |
+| |target database. If | | |
+| |there is no | | |
+| |<candidate/> | | |
+| |database, then the | | |
+| |target is the | | |
+| |<running/> database.| | |
+| |A <commit> follows. | | |
++-------------+--------------------+--------------------+--------------------+
+|Other |This command has no |Supported via a |Supported via a |
+|Configuration|existing NETCONF RPC|cookbook that |playbook that |
+|Commands |action. |performs |performs |
+| | |the action. |the action. |
++-------------+--------------------+--------------------+--------------------+
+|Lifecycle |This command has no |Supported via a |Supported via a |
+|Management |existing NETCONF RPC|cookbook that |playbook that |
+|Commands |action. |performs |performs |
+| | |the action. |the action. |
++-------------+--------------------+--------------------+--------------------+
+|Health Check |This command has no |Supported via a |Supported |
+| |existing NETCONF RPC|cookbook |via a |
+| |action. |that |playbook |
+| | |performs |that |
+| | |a HealthCheck and |performs |
+| | |returns the results.|the |
+| | | |HealthCheck |
+| | | |and returns |
+| | | |the |
+| | | |results. |
++-------------+--------------------+--------------------+--------------------+
Monitoring & Management
--------------------------------------------------
Streaming (VES) specifications. While this document is focused on
specifying some of the records from the ONAP perspective, there may
be other external bodies using the same framework to specify additional
-records. For example, OPNFV has a VES project that is looking to specify
+records. For example, OPNFV has a VES project that is looking to specify
records for OpenStack’s internal telemetry to manage Application (VNFs),
physical and virtual infrastructure (compute, storage, network devices),
and virtual infrastructure managers (cloud controllers, SDN controllers).
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.
- - JSON plain text format is preferred for moderate volume data sets
+ 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
of moderate volume data sets include the fault alarms and performance
alerts, heartbeat messages, measurements used for xNF scaling and syslogs.
- - Binary format using Avro is preferred for high volume data sets
+ - Binary format using Avro is preferred for high volume data sets
(option 2) such as mobility flow measurements and other high-volume
streaming events (such as mobility signaling events or SIP signaling)
or bulk data, as this will significantly reduce the volume of data
to be transmitted. As of the date of this document, all events are
reported using plain text JSON and REST.
- - Avro content is self-documented, using a JSON schema. The JSON schema is
+ - Avro content is self-documented, using a JSON schema. The JSON schema is
delivered along with the data content
(http://avro.apache.org/docs/current/ ). This means the presence and
position of data fields can be recognized automatically, as well as the
* 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.
-
- - 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
- 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.
+ 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
+ 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.
Addressing and Delivery Protocol
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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