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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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-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
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
++++++++++++++++++++++++++
{
"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
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
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
R-98617 The xNF provider **MUST** provide information regarding any
dependency (e.g., affinity, anti-affinity) with other xNFs and resources.
-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.
R-30278 The xNF provider **MUST** provide a Resource/Device YANG model
as a foundation for creating the YANG model for configuration. This will
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
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
applicable) for each interface.
R-97102 The VNF Package **MUST** include VM requirements via a Heat
-template that provides the necessary data for:
+template that provides the necessary data for VM specifications
+for all VNF components - for hypervisor, CPU, memory, storage.
-- 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.
+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.
R-26881 The xNF provider **MUST** provide the binaries and images
needed to instantiate the xNF (xNF and VNFC images).
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.
R-28545 The xNF **MUST** conform its YANG model to RFC 6060,
“YANG - A Data Modeling Language for the Network Configuration
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.
R-27310 The xNF Package **MUST** include all relevant Chef artifacts
(roles/cookbooks/recipes) required to execute xNF actions requested by
to ONAP upon completion of the chef-client run for any chef-client run
associated with a xNF action.
-- As part of the push job, ONAP will provide two parameters in the
- environment of the push job JSON object:
-
- - ‘RequestId’ a unique Id to be used to identify the request,
- - ‘CallbackUrl’, the URL to post response back.
-
-- If the CallbackUrl field is empty or missing in the push job, then
- the chef-client run need not post the results back via callback.
-
R-15885 The xNF **MUST** Upon completion of the chef-client run,
POST back on the callback URL, a JSON object as described in Table
A2 if the chef-client run list includes a cookbook/recipe that is
be encoded and serialized using `Avro <http://avro.apache.org/>`_,
where the Avro [6]_ 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
will read the schema when the stream is established and apply the
schema to the received content.
-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.
-
+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.
+
+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
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
+R-08312 The xNF **MAY** use another option which is expected to include REST
+delivery of binary encoded data sets.
-- 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-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
.. [7]
Multiple ONAP actions may map to one playbook.
+
Code Review / vnfrqts / requirements.git / commitdiff