See the License for the specific language governing permissions and
limitations under the License.
-
Monitoring & Management
-----------------------
-This section addresses data collection and event processing functionality that
-is directly dependent on the interfaces provided by the VNFs' or PNFs' APIs.
-These can be in the form of asynchronous interfaces for event, fault
-notifications, and autonomous data streams. They can also be synchronous
-interfaces for on-demand requests to retrieve various performance, usage, and
-other event information. It should be understood that events are well
-structured packages of information, identified by an eventName, which are
-communicated to subscribers who are interested in the eventName. Events are
-simply a way of communicating well-structured packages of information to one
-or more instances of an Event Listener service.
-
-The target direction for these interfaces is to employ APIs that are
-implemented utilizing standardized messaging and modeling protocols over
-standardized transports. Standardized environments (physical, virtual) present
-a tremendous opportunity to eliminate the need for proprietary interfaces while
-removing the traditional boundaries between Network Management Systems and
-Element Management Systems. Additionally, virtualized NFs provide the ability
-to instrument networking applications by creating event records to test and
-monitor end-to-end data flow through the network, similar to what physical or
-virtual probes provide without the need to insert probes at various points in
-the network. Providers must be able to provide the aforementioned set of
-required data directly to the ONAP collection layer using standardized
-interfaces.
-
-
-Data Model for Event Records
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-This section describes the data model for the collection of telemetry data from
-physical or virtual NFs by Service Providers (SPs) to manage NF health and
-run-time life cycle. This data model is referred to as the VES Data Model. The
-VES acronym originally stood for Virtual-function Event Streaming, but VES has
-been generalized to support network-function event streaming, whether
-virtualized or not.
-
-The VES Data Model describes a vendor-agnostic common vocabulary of event
-payloads. Vendor-specific, product-specific or service-specific data is
-supported by the inclusion of a flexible additional information field
-structure. The VES Data Models' common vocabulary is used to drive standard
-and automated data analytics (policy-driven analytics) within the ONAP
-DCAE Framework.
-
-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 OpenStack's internal telemetry to manage
-application (VNFs or PNFs), physical and virtual infrastructure (compute,
-storage, network devices, etc.) and virtual infrastructure managers (cloud
-controllers, SDN controllers). It uses ONAP's VES Agent to generate VES events
-from the NF and Intel's collectD agent to generate infrastructure VES events.
-Note that any configurable parameters for these data records (e.g., frequency,
-granularity, policy-based configuration) will be managed using the
-"Configuration" framework described in the prior sections of this document.
-The infrastructure metrics have been funneled via the ONAP Multi-VIM Project
-and are now included in current specifications.
-
-The Data Model consists of:
-
- - Common Header Record: This data structure precedes each of the
- Technology Independent and Technology Specific records sections of
- the data model.
-
- - Technology Independent Records: This version of the document specifies
- the model for fault, heartbeat, measurement, notification, perf3gpp,
- pnfRegistration, stateChange, syslog, and thresholdCrossingAlert (TCA)
- records. In the future, these may be extended to support other types of
- technology independent records. Each of these records allows additional
- fields (name/value pairs) for extensibility. The NF provider may use these
- NF provider-specific additional fields to provide additional information
- that may be relevant to the managing systems.
-
- - Technology Specific Records: This version of the document specifies the
- model for mobileFlow, sipSignaling and voiceQuality records. In the
- future, these may be extended to support other types of records (e.g.
- Network Fabric, Security records, etc.). Each of these records allows
- additional fields (name/value pairs) for extensibility. The NF provider can
- use these NF-specific additional fields to provide additional information
- that may be relevant to the managing systems. A placeholder for additional
- technology specific areas of interest to be defined in the future documents
- has been depicted.
-
-|image0|
-
-Figure 1. Data Model for Event Records
-
-Event Records - Data Structure Description
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The data structure for event records consists of:
-
-- a Common Event Header block; and
-
-- zero (heartbeat) or more technology independent domain blocks; or
-
- - e.g. fault, measurement, notification, perf3gpp, pnfRegistration,
- stateChange, syslog, TCA, otherFields etc.
-
-- technology specific domain blocks.
-
- - e.g. mobileFlow, sipSignaling, voiceQuality, etc.
-
-Common Event Header
-~~~~~~~~~~~~~~~~~~~~~
-
-The common header that precedes any of the domain-specific records contains
-information identifying the type of record to follow, information about the
-sender and other identifying characteristics related to the domain and event.
-(e.g., name, priority, sequence number, source, timestamp, type, etc.).
+In ONAP, DCAE is responsible of collecting, receiving, and analyzing
+NF monitoring data. This data serves the basis for tracking the health,
+performance, and operational status of the NF. DCAE provides a
+number of predefined interfaces based upon accepted, open standards to support
+monitoring data ingestion. Some of these interfaces collect data by polling or
+pulling data from the NF using standard protocols. Other DCAE interfaces receive
+monitoring data (such as VES events) that are pushed from the NFs.
+
+A NF that produces monitoring data and uses protocols that are compatible with
+ONAP's predefined monitoring ingestion capabilities can easily be integrated
+with ONAP through simple configuration rather than custom development.
+
+This chapter will define the expected requirements for a NF to easily integrate
+with an instance of ONAP.
+
+Monitoring and Fault Protocol Selection
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This section provides the proper guidance on how a NF should determine the
+protocol and data format for providing a specific types of telemetry data to
+ONAP.
.. req::
- :id: R-528866
- :target: VNF
- :introduced: casablanca
- :validation_mode: in_service
- :impacts: dcae
+ :id: R-82909
+ :target: VNF or PNF
:keyword: MUST
- :updated: dublin
+ :introduced: guilin
- The VNF **MUST** produce VES events that include the following mandatory
- fields in the common event header.
-
- * ``domain`` - the event domain enumeration
- * ``eventId`` - the event key unique to the event source
- * ``eventName`` - the unique event name
- * ``lastEpochMicrosec`` - the latest unix time (aka epoch time) associated
- with the event
- * ``priority`` - the processing priority enumeration
- * ``reportingEntityName`` - name of the entity reporting the event or
- detecting a problem in another VNF or PNF
- * ``sequence`` - the ordering of events communicated by an event source
- * ``sourceName`` - name of the entity experiencing the event issue, which
- may be detected and reported by a separate reporting entity
- * ``startEpochMicrosec`` - the earliest unix time (aka epoch time)
- associated with the event
- * ``version`` - the version of the event header
- * ``vesEventListenerVersion`` - Version of the VES event listener API spec
- that this event is compliant with
-
-Technology Independent Records
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The current version of the data model supports the following technology
-independent event records:
-
- * ``fault`` - the fault record, describing a condition in the fault domain,
- contains information about device failures. The fault event provides data
- such as the entity experiencing a fault, the severity, resulting status,
- etc.
-
- * ``heartbeat`` - the heartbeat record provides an optional structure for
- communicating information about device health. Heartbeat records would
- only have the Common Event Header block. An optional heartbeat domain is
- available to specify information such as heartbeat interval and
- recommended action upon missing heartbeat interval. Heartbeat avoids the
- need to ping a device. A communication failure can be determined via
- missing heartbeat events being delivered to DCAE and appropriate action
- (e.g. restart VM, rebuild VNF or create ticket) can be taken by DCAE
- CLAMP.
-
- * ``Measurements`` - the Measurements Record contains information about
- PNF or VNF and PNF or VNF resource structure and its condition to help
- in the management of the resources for purposes of capacity planning,
- elastic scaling, performance management and service assurance. These
- are soft alarms providing an opportunity for proactive maintenance.
-
- * ``Notification`` - the Notification Record provides a structure for
- communicating notification information from the PNF or VNF. It can contain
- notification information related to the current operational state that is
- reported by the PNF or VNF. As an example, when cards or port name of the
- entity have changed state. (e.g., offline -> online) Other use cases
- include notification of file ready for collection using Bulk Data Transfer
- or notification on configuration changes to a device.
-
- * ``Other`` - the Other Record defines fields for events that do not have a
- defined domain but are needed to be collected and sent to DCAE. This
- record provides a mechanism to convey a complex set of fields (possibly
- nested or opaque) and is purely intended to address miscellaneous needs
- such as addressing time-to-market considerations or other proof-of-concept
- evaluations. Hence, use of this record type is discouraged and should be
- minimized. (Note: the Other domain could be used to create and test new
- domain ideas.)
-
- * ``perf3gpp`` - the perf3gpp record provides a structure for communicating
- information that supports 3GPP defined performance metrics. The perf3gpp
- record can contain information from vendors, including measurement name,
- measurement family, measured object class, description, collection method,
- value ranges, unit of measure, triggering conditions and other measurement
- information.
-
- * ``pnfRegistration`` - the pnfRegistration Record provides a structure for
- registration of a physical network function. The pnfRegistration Record
- can contain information about attributes related to the physical network
- function including serial number, software revision, unit type and vendor
- name.
-
- * ``stateChange`` - the State Change Record provides a structure for
- communicating information about data flow through the PNF or VNF. The
- State Change Record can contain information about state change related to
- physical device that is reported by the PNF or VNF. As an example, when
- cards or port name of the entity that has changed state. Note: The
- Notification Domain can also communicate similar information.
-
- * ``Syslog`` - the Syslog Record provides a structure for communicating any
- type of information that may be logged by the PNF or VNF. It can contain
- information about system internal events, status, errors, etc. It is
- recommended that low volume control or session logs are communicated via a
- push mechanism, while other large volume logs should be sent via file
- transfer.
-
- * ``thresholdCrossingAlert`` - the Threshold Crossing Alert (TCA) Record
- provides a structure for communicating information about threshold
- crossing alerts. It uses data from the Measurement or a similar domain to
- watch for a Key Performance Indicator (KPI) threshold that has been
- crossed. TCA provides alert definitions and types, actions, events,
- timestamps and physical or logical details.
-
-
-Technology Specific Records
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ The VNF or PNF **MUST** report faults and alarms using either
+ :ref:`Virtual Function Event Streaming (VES) <ves_monitoring_requirements>`
+ or :ref:`SNMP <snmp_monitoring_requirements>`. (NOTE: See relevant sections
+ for more detailed requirements)
-The current version of the data model supports the following technology
-specific event records:
+.. req::
+ :id: R-554966
+ :target: VNF or PNF
+ :keyword: MUST
+ :introduced: guilin
- * ``Mobile Flow`` - the Mobile Flow Record provides a structure for
- communicating information about data flow through the NF. It can contain
- information about connectivity and data flows between serving elements for
- mobile service, such as between LTE reference points, etc.
+ The VNF or PNF **MUST** report performance metrics using
+ :ref:`Virtual Function Event Streaming (VES) <ves_monitoring_requirements>`
+ or :ref:`bulk_performance_measurement`.
- * ``Signaling`` - the Signaling Record provides a structure for
- communicating information about signaling messages, parameters and
- signaling state. It can contain information about data flows for signaling
- and controlling multimedia communication sessions such as voice and video
- calls.
+.. req::
+ :id: R-69111
+ :target: VNF or PNF
+ :keyword: MUST
+ :introduced: guilin
- * ``Voice Quality`` - the Voice Quality Record provides a structure for
- communicating information about voice quality statistics including media
- connection information, such as transmitted octet and packet counts,
- packet loss, packet delay variation, round-trip delay, QoS parameters and
- codec selection.
+ The VNF or PNF **MUST** report application logs using either
+ :ref:`Virtual Function Event Streaming (VES) <ves_monitoring_requirements>`
+ or Syslog in compliance with
+ `RFC 5424 <https://tools.ietf.org/html/rfc5424>`__ .
- * ``Future Domains`` - the Future Domains Record is a placeholder for
- additional technology specific areas of interest that will be defined and
- described in the future documents.
-Miscellaneous
-~~~~~~~~~~~~~
+.. req::
+ :id: R-209104
+ :target: VNF or PNF
+ :keyword: SHOULD
+ :introduced: guilin
-The event specification contains various extensible structures (e.g. hashMap)
-that enable event publishers to send information that has not been explicitly
-defined.
+ The VNF or PNF producing VES syslog events **SHOULD** restrict these
+ events to those that convey significant errors or warnings needed to support
+ the operation or troubleshooting of the VNF or PNF. It is expected the
+ volume of such events would be lower (e.g. less than 2000 per day) than
+ more detailed events produced in the course of normal operations.
.. req::
- :id: R-283988
- :target: VNF
- :introduced: casablanca
- :validation_mode: in_service
+ :id: R-332680
+ :target: VNF or PNF
+ :keyword: SHOULD
:impacts: dcae
- :keyword: MUST NOT
+ :validation_mode: in_service
+ :introduced: casablanca
+ :updated: guilin
- The VNF, when publishing events, **MUST NOT** send information through
- extensible structures if the event specification has explicitly defined
- fields for that information.
+ The VNF or PNF producing VES events **SHOULD** deliver syslog messages
+ that meet the criteria in R-209104 to the VES Event Listener using the
+ ``syslog`` VES domain.
.. req::
- :id: R-470963
- :target: VNF
+ :id: R-935717
+ :target: VNF or PNF
+ :keyword: MUST
+ :introduced: guilin
+
+ The VNF or PNF **MUST** report heartbeats using
+ :ref:`Virtual Function Event Streaming (VES) <ves_monitoring_requirements>`.
+
+.. req::
+ :id: R-697654
+ :target: VNF or PNF
+ :keyword: MAY
:introduced: casablanca
+ :updated: guilin
+ :impacts: DCAE
:validation_mode: in_service
- :impacts: dcae
- :keyword: MUST
- The VNF, when publishing events, **MUST** leverage camel case to separate
- words and acronyms used as keys that will be sent through extensible fields.
- When an acronym is used as the key, then only the first letter shall be
- capitalized.
+ The VNF or PNF **MAY** leverage ONAP's High Volume VNF Event Streaming
+ (HV-VES) when there is a need to deliver large volumes of real-time
+ performance management metrics. See
+ `HV-VES Collector <https://onap-doc.readthedocs.io/projects/onap-dcaegen2/en/latest/sections/services/ves-hv/index.html>`__
+ service details for more information.
.. req::
- :id: R-408813
- :target: VNF
+ :id: R-857511
+ :target: VNF or PNF PROVIDER
:keyword: MUST
- :introduced: casablanca
+ :introduced: guilin
+ :impacts: DCAE
:validation_mode: none
- :impacts: dcae
- The VNF, when publishing events, **MUST** pass all information it is
- able to collect even if the information field is identified as optional.
- However, if the data cannot be collected, then optional fields can be
- omitted.
+ VNF or PNF Provider **MUST** have agreement with the Service Provider before
+ utilizing the HV-VES option for monitoring as this option does not fully
+ integrate with the ONAP's DCAE event processing capabilities.
+
+.. req::
+ :id: R-908291
+ :target: VNF or PNF
+ :keyword: MAY
+ :introduced: casablanca
+ :impacts: dcae, dmaap
+ :validation_mode: in_service
+ :updated: guilin
+
+ The VNF or PNF **MAY** leverage a bulk VNF or PNF telemetry transmission
+ mechanism in instances where other transmission
+ methods are not practical or advisable.
+
+ NOTE: For additional information and use cases for the Bulk Telemetry
+ Transmission Mechanism, please refer to
+ the :ref:`bulk_performance_measurement` requirements and the
+ `5G - Bulk PM ONAP Development <https://wiki.onap.org/display/DW/5G+-+Bulk+PM>`__
+ Wiki page.
+.. _snmp_monitoring_requirements:
+
+SNMP Monitoring Requirements
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. req::
+ :id: R-261501
+ :target: VNF or PNF
+ :keyword: MUST
+ :introduced: guilin
-Data Structure Specification of the Event Record
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+ If the VNF or PNF is using SNMP, then the VNF or PNF Provider **MUST**
+ provide a Management Information Base (MIB) file that uniquely identifies
+ and describes all SNMP events exposed by the network function.
+
+.. req::
+ :id: R-233922
+ :target: VNF or PNF
+ :keyword: SHOULD
+ :introduced: guilin
+
+ If the VNF or PNF is using SNMP, then the VNF or PNF Provider **SHOULD**
+ provide examples of all SNMP alarms.
+
+.. _ves_monitoring_requirements:
+
+Virtual Function Event Streaming (VES) Client Requirements
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The VES protocol enables NFs to transmit telemetry data in a non-proprietary,
+extensible format to ONAP using the HTTP protocol. This chapter will define
+the requirements for a NF to deliver events to ONAP's VES event listeners in
+a manner that conforms with the appropriate VES Event Listener specifications,
+and ensures the NF can be configured to maximize the reliability of telemetry
+data delivery.
+
+
+Event Definition and Registration
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. req::
:id: R-520802
:introduced: casablanca
:validation_mode: static
:impacts: dcae
- :updated: el alto
+ :updated: guilin
- The VNF or PNF provider **MUST** provide a YAML file formatted in adherence with
- the :ref:`VES Event Registration specification <ves_event_registration_3_2>`
+ If the VNF or PNF is using VES, then the VNF or PNF Provider **MUST** provide
+ a YAML file formatted in adherence with the
+ :ref:`VES Event Registration specification <ves_event_registration_3_2>`
that defines the following information for each event produced by the VNF:
* ``eventName``
:target: VNF or PNF PROVIDER
:keyword: MUST
:introduced: casablanca
+ :updated: guilin
:validation_mode: static
:impacts: dcae
- :updated: el alto
-
- The VNF or PNF provider **MUST** indicate specific conditions that may arise, and
- recommend actions that may be taken at specific thresholds, or if specific
- conditions repeat within a specified time interval, using the semantics and
- syntax described by the :ref:`VES Event Registration specification <ves_event_registration_3_2>`.
-**NOTE:** The Service Provider may override VNF or PNF provider Event
-Registrations using the ONAP SDC Design Studio to finalizes Service
-Provider engineering rules for the processing of the VNF or PNF events.
-These changes may modify any of the following:
+ A VNF or PNF Provider utilizing VES **MUST** indicate specific conditions
+ that may arise, and recommend actions that may be taken at specific
+ thresholds, or if specific conditions repeat within a specified time
+ interval, using the semantics and syntax described by the
+ :ref:`VES Event Registration specification <ves_event_registration_3_2>`.
-* Threshold levels
-* Specified actions related to conditions
+ **NOTE:** The Service Provider may override VNF or PNF provider Event
+ Registrations using the ONAP SDC Design Studio to finalizes Service
+ Provider engineering rules for the processing of the VNF or PNF events.
+ These changes may modify any of the following:
-
-.. req::
- :id: R-570134
- :target: VNF or PNF
- :keyword: MUST
- :introduced: casablanca
- :validation_mode: in_service
- :impacts: dcae
- :updated: frankfurt
-
- The events produced by the VNF or PNF **MUST** be compliant with the
- common event formats defined in either the
- :ref:`VES Event Listener 7.1.1<ves_event_listener_7_1>` or
- :ref:`VES Event Listener 5.4.1<ves_event_listener_5_4_1>`
- specifications. Version 7.1.1 should be preferred, and VES 5.4.1 is only
- provided for backwards compatibility.
+ * Threshold levels
+ * Specified actions related to conditions
.. req::
:id: R-123044
:impacts: dcae
:updated: dublin
- The VNF or PNF Provider **MAY** require that specific events, identified by their
- ``eventName``, require that certain fields, which are optional in the common
- event format, must be present when they are published.
+ The VNF or PNF Provider **MAY** require that specific events, identified by
+ their ``eventName``, require that certain fields, which are optional in the
+ common event format, must be present when they are published.
-
-Transports and Protocols Supporting Resource Interfaces
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Transport mechanisms and protocols have been selected to enable both high
-volume and moderate volume data sets, as well as asynchronous and synchronous
-communications over secure connections. The specified encoding provides
-self-documenting content, so data fields can be changed as needs evolve, while
-minimizing changes to data delivery.
-
-.. req::
- :id: R-798933
- :target: VNF or PNF
- :keyword: SHOULD
- :impacts: dcae
- :validation_mode: in_service
- :introduced: casablanca
- :updated: dublin
-
- The VNF or PNF **SHOULD** deliver event records that fall into the event domains
- supported by VES.
+Event Formatting and Usage
+~~~~~~~~~~~~~~~~~~~~~~~~~~
.. req::
- :id: R-821839
+ :id: R-570134
:target: VNF or PNF
:keyword: MUST
- :impacts: dcae
- :validation_mode: in_service
:introduced: casablanca
- :updated: dublin
-
- The VNF or PNF **MUST** deliver event records to ONAP using the common
- transport mechanisms and protocols defined in this specification.
-
-The term 'Event Record' is used throughout this document to represent various
-forms of telemetry or instrumentation made available by the VNFs or PNFs
-including, faults, status events, various other types of VNF or PNF
-measurements and logs.
-
-Common structures and delivery protocols for other types of data will be given
-in future versions of this document as we gain more insight into data volumes
-and required processing.
-
-In the following sections, we provide options for encoding, serialization and
-data delivery. Agreements between Service Providers and VNF or PNF providers
-determine which encoding, serialization and delivery method to use for
-particular data sets.
-
-.. req::
- :id: R-932071
- :target: VNF or PNF
- :keyword: MUST
+ :updated: guilin
+ :validation_mode: in_service
:impacts: dcae
- :validation_mode: none
- :introduced: casablanca
- :updated: dublin
- The VNF or PNF provider **MUST** reach agreement with the Service Provider on
- the selected methods for encoding, serialization and data delivery
- prior to the on-boarding of the VNF or PNF into ONAP SDC Design Studio.
+ The VES events produced by the VNF or PNF **MUST** be compliant with the
+ common event formats defined in one of the following specifications:
+ * :ref:`VES Event Listener 5.4.1<ves_event_listener_5_4_1>`
+ * :ref:`VES Event Listener 7.1.1<ves_event_listener_7_1>`
+ * :ref:`VES Event Listener 7.2<ves_event_listener_7_2>`
-VNF or PNF Telemetry using VES/JSON Model
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ The latest version (7.2) should be preferred. Earlier versions are
+ provided for backwards compatibility.
.. req::
- :id: R-659655
+ :id: R-528866
:target: VNF or PNF
- :keyword: SHOULD
- :impacts: dcae
- :validation_mode: in_service
:introduced: casablanca
- :updated: dublin
-
- The VNF or PNF **SHOULD** leverage the JSON-driven model, as depicted in Figure 2,
- for data delivery unless there are specific performance or operational
- concerns agreed upon by the Service Provider that would warrant using an
- alternate model.
-
-|image1|
-
-Figure 2. VES/JSON Driven Model
+ :validation_mode: in_service
+ :impacts: dcae
+ :keyword: MUST
+ :updated: guilin
-VNF or PNF Telemetry using Google Protocol Buffers
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ The VES events produced by the VNF or PNF **MUST** conform to the schema and
+ other formatting requirements specified in the relevant VES Event Listener
+ specification.
.. req::
- :id: R-697654
+ :id: R-283988
:target: VNF or PNF
- :keyword: MAY
- :impacts: dcae
- :validation_mode: in_service
:introduced: casablanca
- :updated: dublin
-
- The VNF or PNF **MAY** leverage the Google Protocol Buffers (GPB) delivery model
- depicted in Figure 3 to support real-time performance management (PM) data.
- In this model the VES events are streamed as binary-encoded GBPs over via
- TCP sockets.
-
-|image2|
-
-Figure 3. VNF or PNF Telemetry using Google Protocol Buffers
-
-
-**NOTE:** For high-volume VNF or PNF telemetry, native (binary) Google Protocol
-Buffers (GPB) is the preferred serialization method. While supporting the GPB
-telemetry delivery approach described above, the default delivery method
-is the VES/REST JSON based model in DCAE. The purpose of the diagram above
-is to illustrate the GPB delivery concept only and not to imply a specific
-implementation.
-
-For additional information and uses cases for Real Time Performance
-Management and High Volume Stream Data Collection, please refer to the
-`5G - Real Time PM and High Volume Stream Data Collection ONAP Development <https://wiki.onap.org/display/DW/5G+-+Real+Time+PM+and+High+Volume+Stream+Data+Collection>`__
-Wiki page.
+ :updated: guilin
+ :validation_mode: in_service
+ :impacts: dcae
+ :keyword: MUST NOT
-Bulk Telemetry Transmission
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ A VNF or PNF producing VES events **MUST NOT** send information through
+ extensible structures if the event specification has explicitly defined
+ fields for that information.
.. req::
- :id: R-908291
+ :id: R-470963
:target: VNF or PNF
- :keyword: MAY
:introduced: casablanca
- :impacts: dcae, dmaap
+ :updated: guilin
:validation_mode: in_service
- :updated: dublin
-
- The VNF or PNF **MAY** leverage bulk VNF or PNF telemetry transmission mechanism, as
- depicted in Figure 4, in instances where other transmission methods are not
- practical or advisable.
-
-|image3|
-
-Figure 4. VNF or PNF Telemetry using Bulk Transmission
-
-**NOTE:** An optional VES mapper micro-service can be leveraged to to extract
-measurements and publish them as VES events.
-
-For additional information and use cases for the Bulk Telemetry Transmission
-Mechanism, please refer to the `5G - Bulk PM ONAP Development <https://wiki.onap.org/display/DW/5G+-+Bulk+PM>`__
-Wiki page.
-
-Monitoring & Management Requirements
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+ :impacts: dcae
+ :keyword: SHOULD
-VNF telemetry via standardized interface
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ A VNF or PNF producing VES events **SHOULD** leverage camel case to
+ separate words and acronyms used as keys that will be sent through extensible
+ fields. When an acronym is used as the key, then only the first letter shall
+ be capitalized.
.. req::
- :id: R-821473
+ :id: R-408813
:target: VNF or PNF
:keyword: MUST
:introduced: casablanca
+ :updated: guilin
+ :validation_mode: none
:impacts: dcae
- :validation_mode: in_service
- :updated: dublin
-
- The VNF or PNF MUST produce heartbeat indicators consisting of events containing
- the common event header only per the VES Listener Specification.
+ A VNF or PNF producing VES events **MUST** pass all information it is
+ able to collect even if the information field is identified as optional.
+ However, if the data cannot be collected, then optional fields can be
+ omitted.
-JSON
-~~~~~~~~~~~~~~~~~~
+Configuration Requirements
+~~~~~~~~~~~~~~~~~~~~~~~~~~
-.. req::
- :id: R-19624
- :target: VNF or PNF
- :keyword: MUST
- :updated: dublin
+This section defines the types the configuration options and defaults a NF
+producing VES events should provide to ensure the NF can be configured properly
+for the Service Provider's ONAP environment and ensure reliable delivery of
+VES events.
- The VNF or PNF, when leveraging JSON for events, **MUST** encode and serialize
- content delivered to ONAP using JSON (RFC 7159) plain text format.
- High-volume data is to be encoded and serialized using
- `Avro <http://avro.apache.org/>`_, where the Avro data
- format are described using JSON.
-
-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 VNF scaling and syslogs.
-
- - 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, mobility trace data 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
- 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
- data format, definition and other attributes. Avro content can be
- serialized as JSON tagged text or as binary. In binary format, the JSON
- schema is included as a separate data block, so the content is not tagged,
- further compressing the volume. For streaming data, Avro will read the
- schema when the stream is established and apply the schema to the
- received content.
-
- - In addition to the preferred delivery format (JSON), content delivered
- from PNFs or VNFs to ONAP can be encoded and serialized using Google
- Protocol Buffers (GPB). Please refer to the next section of this document
- for additional information.
-
-In addition to the preferred method (JSON), content can be delivered
-from VNFs or PNFs to ONAP can be encoded and serialized using Google Protocol
-Buffers (GPB).
-
-Google Protocol Buffers (GPB)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+There are several methods available to provide configuration settings to a
+network function. This document does not specify the exact manner in which
+the configuration elements described below must be required. The
+configuration can be provided during instantiation (e.g. preload), provided by
+an ONAP controller action, or provided manually.
.. req::
- :id: R-257367
+ :id: R-460012
:target: VNF or PNF
:keyword: MUST
- :introduced: casablanca
- :validation_mode: in_service
- :updated: dublin
-
- The VNF or PNF, when leveraging Google Protocol Buffers for events, **MUST**
- serialize the events using native Google Protocol Buffers (GPB) according
- to the following guidelines:
+ :introduced: guilin
- * The keys are represented as integers pointing to the system resources
- for the VNF or PNF being monitored
- * The values correspond to integers or strings that identify the
- operational state of the VNF resource, such a statistics counters and
- the state of an VNF or PNF resource.
- * The required Google Protocol Buffers (GPB) metadata is provided in the
- form of .proto files.
+ The VNF or PNF producing VES events **MUST** allow the configuration of
+ the attributes defined in Table 1 and utilize the provided default value
+ (where applicable) when the configuration value is not provided by the
+ Service Provider.
.. req::
- :id: R-978752
- :target: VNF or PNF PROVIDER
+ :id: R-940591
+ :target: VNF or PNF
+ :keyword: SHOULD
+ :introduced: guilin
+
+ A VNF or PNF producing VES events **SHOULD** use the recommended parameter
+ name for the configurable value from Table 1.
+
+.. table:: **Table 1**: VES Configurable Values
+
+ +----------------------+-----------------------------------+----------------+-------------------------------------+
+ |Parameter | Description | Default | Parameter Name (VES 7.2+) |
+ +======================+===================================+================+=====================================+
+ |VES Listener Endpoint | FQDN or IP of the Event Listener | n/a | ves_listener_endpoint |
+ +----------------------+-----------------------------------+----------------+-------------------------------------+
+ |Heartbeat Interval | Frequency in seconds the NF must | 60 | ves_heartbeat_interval_seconds |
+ | | send a heartbeat to the event | | |
+ | | listener | | |
+ +----------------------+-----------------------------------+----------------+-------------------------------------+
+ |Timeout Value | Duration in seconds the NF should | 5 | ves_timeout_seconds |
+ | | wait for ACK from the event | | |
+ | | listener before timeout | | |
+ +----------------------+-----------------------------------+----------------+-------------------------------------+
+ |Measurement Interval | Window size in seconds to use for | 300 | ves_measurement_interval_seconds |
+ | | aggregated measurements | | |
+ +----------------------+-----------------------------------+----------------+-------------------------------------+
+ |HTTP Username | Required if NF supports HTTP | n/a | ves_http_username |
+ | | Basic Authentication with the | | |
+ | | VES Event Listener | | |
+ +----------------------+-----------------------------------+----------------+-------------------------------------+
+ |HTTP Password | Required if NF supports HTTP | n/a | ves_http_password |
+ | | Basic Authentication with the | | |
+ | | VES Event Listener | | |
+ +----------------------+-----------------------------------+----------------+-------------------------------------+
+
+
+VES Listener Endpoint and DNS Resolution
+++++++++++++++++++++++++++++++++++++++++
+
+In a high availability deployment of a VES Event Listener, a round-robin DNS or
+dynamic DNS may be used to either load balance or provide fault tolerance of
+the Event Listener. Adherence to the following requirements ensure the VNF or
+PNF interacts properly with this deployment configuration.
+
+.. req::
+ :id: R-70492
+ :target: VNF or PNF
:keyword: MUST
- :introduced: casablanca
- :validation_mode: static
- :updated: dublin
-
- The VNF or PNF providers **MUST** provide the Service Provider the following
- artifacts to support the delivery of high-volume VNF or PNF telemetry to
- DCAE via GPB over TLS/TCP:
-
- * A valid VES Event .proto definition file, to be used validate and
- decode an event
- * A valid high volume measurement .proto definition file, to be used for
- processing high volume events
- * A supporting PM content metadata file to be used by analytics
- applications to process high volume measurement events
+ :introduced: guilin
-Reporting Frequency
-~~~~~~~~~~~~~~~~~~~~~
+ The VNF or PNF **MUST** support DNS resolution of the VES Listener Endpoint
+ if a Fully Qualified Domain Name (FQDN) is provided.
.. req::
- :id: R-146931
+ :id: R-130645
:target: VNF or PNF
:keyword: MUST
- :introduced: casablanca
- :validation_mode: in_service
- :updated: dublin
-
- The VNF or PNF **MUST** report exactly one Measurement event per period
- per source name.
+ :introduced: guilin
-.. req::
- :id: R-98191
- :target: VNF or PNF
- :keyword: MUST
- :updated: dublin
+ The VNF or PNF **MUST** respect the Time To Live provided by the DNS for
+ the VES Event Listener FQDN.
- The VNF or PNF **MUST** vary the frequency that asynchronous data
- is delivered based on the content and how data may be aggregated or
- grouped together.
-
- Note:
-
- - For example, alarms and alerts are expected to be delivered as
- soon as they appear. In contrast, other content, such as performance
- measurements, KPIs or reported network signaling may have various
- ways of packaging and delivering content. Some content should be
- streamed immediately; or content may be monitored over a time
- interval, then packaged as collection of records and delivered
- as block; or data may be collected until a package of a certain
- size has been collected; or content may be summarized statistically
- over a time interval, or computed as a KPI, with the summary or KPI
- being delivered.
- - We expect the reporting frequency to be configurable depending on
- the virtual network functions needs for management. For example,
- Service Provider may choose to vary the frequency of collection
- between normal and trouble-shooting scenarios.
- - Decisions about the frequency of data reporting will affect
- the size of delivered data sets, recommended delivery method,
- and how the data will be interpreted by ONAP. These considerations
- should not affect deserialization and decoding of the data, which
- will be guided by the accompanying JSON schema or GPB definition
- files.
-
-Addressing and Delivery Protocol
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-ONAP destinations can be addressed by URLs for RESTful data PUT. Future
-data sets may also be addressed by host name and port number for TCP
-streaming, or by host name and landing zone directory for SFTP transfer
-of bulk files.
-
-.. req::
- :id: R-88482
- :target: VNF or PNF
- :keyword: SHOULD
- :updated: dublin
-
- The VNF or PNF **SHOULD** use REST using HTTPS delivery of plain
- text JSON for moderate sized asynchronous data sets, and for high
- volume data sets when feasible.
+Event Delivery Requirements
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. req::
- :id: R-84879
- :target: VNF or PNF
- :keyword: MUST
- :updated: dublin
+ :id: R-06924
+ :target: VNF or PNF
+ :keyword: MUST
+ :updated: guilin
- The VNF or PNF **MUST** have the capability of maintaining a primary
- and backup DNS name (URL) for connecting to ONAP collectors, with the
- ability to switch between addresses based on conditions defined by policy
- such as time-outs, and buffering to store messages until they can be
- delivered. At its discretion, the service provider may choose to populate
- only one collector address for a VNF or PNF. In this case, the network will
- promptly resolve connectivity problems caused by a collector or network
- failure transparently to the VNF or PNF.
+ The VNF or PNF producing VES events **MUST** deliver VES events as it
+ becomes available or according to the configured measurement interval.
.. req::
- :id: R-81777
+ :id: R-655209
:target: VNF or PNF
:keyword: MUST
- :updated: dublin
-
- The VNF or PNF **MUST** be configured with initial address(es) to use
- at deployment time. Subsequently, address(es) may be changed through
- ONAP-defined policies delivered from ONAP to the VNF or PNF using PUTs to a
- RESTful API, in the same manner that other controls over data reporting
- will be controlled by policy.
-
-.. req::
- :id: R-08312
- :target: VNF or PNF
- :keyword: MAY
- :updated: dublin
-
- The VNF or PNF **MAY** use another option which is expected to include REST
- delivery of binary encoded data sets.
-
-.. req::
- :id: R-79412
- :target: VNF or PNF
- :keyword: MAY
- :updated: dublin
-
- The VNF or PNF **MAY** use another option which is expected to include TCP
- for high volume streaming asynchronous data sets and for other high volume
- data sets. TCP delivery can be used for either JSON or binary encoded data
- sets.
-
-.. req::
- :id: R-01033
- :target: VNF or PNF
- :keyword: MAY
- :updated: dublin
+ :introduced: guilin
- The VNF or PNF **MAY** use another option which is expected to include SFTP
- for asynchronous bulk files, such as bulk files that contain large volumes
- of data collected over a long time interval or data collected across many
- VNFs or PNFs. (Preferred is to reorganize the data into more frequent or more focused
- data sets, and deliver these by REST or TCP as appropriate.)
+ The VNF or PNF producing VES events **MUST** respect the configured
+ VES Timeout Value when delivering VES events, and abort any call where
+ the VES Event Listener does not successfully acknowledge the delivery of
+ event(s) within the Timeout Value. These failed transactions should be
+ buffered and retried in accordance with the
+ :ref:`ves_buffering_requirements` Requirements.
.. req::
- :id: R-63229
- :target: VNF or PNF
- :keyword: MAY
- :updated: dublin
+ :id: R-176945
+ :target: VNF or PNF
+ :keyword: SHOULD NOT
+ :introduced: guilin
- The VNF or PNF **MAY** use another option which is expected to include REST
- for synchronous data, using RESTCONF (e.g., for VNF or PNF state polling).
+ The VNF or PNF producing VES events **SHOULD NOT** send syslog events to the
+ VES Event Listener during debug mode, but rather store syslog events locally
+ for access or possible file transfer.
-.. req::
- :id: R-03070
- :target: VNF or PNF
- :keyword: MUST
- :updated: dublin
+.. _ves_buffering_requirements:
- The VNF or PNF **MUST**, by ONAP Policy, provide the ONAP addresses
- as data destinations for each VNF or PNF, and may be changed by Policy while
- the VNF or PNF is in operation. We expect the VNF or PNF to be capable of redirecting
- traffic to changed destinations with no loss of data, for example from
- one REST URL to another, or from one TCP host and port to another.
+Buffering and Redelivery
+~~~~~~~~~~~~~~~~~~~~~~~~
-Asynchronous and Synchronous Data Delivery
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+To maximize the reliable delivery of VES events when the VES Listener becomes
+unavailable or unhealthy, the NF must adhere to these requirements.
.. req::
- :id: R-06924
- :target: VNF or PNF
- :keyword: MUST
- :updated: dublin
+ :id: R-658596
+ :target: VNF or PNF
+ :keyword: MUST
+ :introduced: guilin
- The VNF or PNF **MUST** deliver asynchronous data as data becomes
- available, or according to the configured frequency.
+ A VNF or PNF producing VES events **MUST** buffer events that meet the
+ following criteria if the VES Event Listener is unreachable or the request
+ encounters a timeout.
-.. req::
- :id: R-73285
- :target: VNF or PNF
- :keyword: MUST
- :updated: dublin
-
- The VNF or PNF **MUST** must encode, address and deliver the data
- as described in the previous paragraphs.
+ * Faults with eventSeverity of ``MINOR``, ``MAJOR``, ``NORMAL``, or
+ ``CRITICAL``
+ * Syslog with syslogSev of ``Emergency``, ``Alert``, ``Critical``,
+ ``Error``, or ``Warning``
+ * All measurement events
.. req::
- :id: R-42140
- :target: VNF or PNF
- :keyword: MUST
- :updated: dublin
+ :id: R-636251
+ :target: VNF or PNF
+ :keyword: MUST
+ :introduced: guilin
- The VNF or PNF **MUST** respond to data requests from ONAP as soon
- as those requests are received, as a synchronous response.
+ A VNF or PNF producing VES events **MUST** size the event buffer
+ referenced in R-658596 such that it can buffer a minimum of 1 hours of
+ events under nominal load.
.. req::
- :id: R-34660
- :target: VNF or PNF
- :keyword: MUST
- :updated: dublin
+ :id: R-498679
+ :target: VNF or PNF
+ :keyword: MAY
+ :introduced: guilin
- The VNF or PNF **MUST** use the RESTCONF/NETCONF framework used by
- the ONAP configuration subsystem for synchronous communication.
+ A VNF or PNF producing VES events **MAY** discard buffered events older
+ than a maximum retention period, not less than 1 hour, even if the event
+ was never successfully delivered to the event listener. While discarding
+ based on this retention period is supported for backwards compatibility, it
+ is recommended to retain events until the maximum buffer size is reached per
+ R-346137 as that will maximize the number of events delivered.
.. req::
- :id: R-86586
- :target: VNF or PNF
- :keyword: MUST
- :updated: dublin
+ :id: R-346137
+ :target: VNF or PNF
+ :keyword: MUST
+ :introduced: guilin
- The VNF or PNF **MUST** use the YANG configuration models and RESTCONF
- [RFC8040] (https://tools.ietf.org/html/rfc8040).
+ A VNF or PNF producing VES events that is buffering events per R-658596
+ **MUST** store in-scope events even when the maximum capacity of the
+ buffer (defined in R-636251) has been reached. To make room for new events
+ in this situation, hte oldest event in the buffer shall be removed
+ as necessary. (i.e. First In First Out)
.. req::
- :id: R-11240
- :target: VNF or PNF
- :keyword: MUST
- :updated: dublin
-
- The VNF or PNF **MUST** respond with content encoded in JSON, as
- described in the RESTCONF specification. This way the encoding of a
- synchronous communication will be consistent with Avro.
+ :id: R-379523
+ :target: VNF or PNF
+ :keyword: MUST
+ :introduced: guilin
-.. req::
- :id: R-70266
- :target: VNF or PNF
- :keyword: MUST
- :updated: dublin
+ A VNF or PNF producing VES events that is buffering events due to an
+ unavailable VES Event Listener **MUST** redeliver all buffered events
+ according to the following rules when the VNF or PNF detects the VES Event
+ Listener has become available:
- The VNF or PNF **MUST** respond to an ONAP request to deliver the
- current data for any of the record types defined in
- `Event Records - Data Structure Description`_ by returning the requested
- record, populated with the current field values. (Currently the defined
- record types include fault fields, mobile flow fields, measurements for
- VNF or PNF scaling fields, and syslog fields. Other record types will be added
- in the future as they become standardized and are made available.)
+ * Deliver all previously buffered events before sending new events
+ * Deliver buffered events in the order they were received
.. req::
- :id: R-332680
+ :id: R-818859
:target: VNF or PNF
- :keyword: SHOULD
- :impacts: dcae
- :validation_mode: in_service
- :introduced: casablanca
- :updated: dublin
-
- The VNF or PNF **SHOULD** deliver all syslog messages to the VES Collector per the
- specifications in Monitoring and Management chapter.
-
-.. req::
- :id: R-46290
- :target: VNF or PNF
- :keyword: MUST
- :updated: dublin
+ :keyword: MUST
+ :introduced: guilin
- The VNF or PNF **MUST** respond to an ONAP request to deliver granular
- data on device or subsystem status or performance, referencing the YANG
- configuration model for the VNF or PNF by returning the requested data elements.
+ The VNF or PNF producing VES events **MUST** not allow an unavailable or
+ timing out VES Event Listener to impact the performance, stability, or
+ correct execution of network function.
.. req::
- :id: R-43327
- :target: VNF or PNF
- :keyword: SHOULD
- :updated: dublin
+ :id: R-103464
+ :target: VNF or PNF
+ :keyword: MAY
+ :introduced: guilin
- The VNF or PNF **SHOULD** use `Modeling JSON text with YANG
- <https://tools.ietf.org/html/rfc7951>`_, If YANG models need to be
- translated to and from JSON{RFC7951]. YANG configuration and content can
- be represented via JSON, consistent with Avro, as described in "Encoding
- and Serialization" section.
+ A VNF or PNF producing VES events that is buffering events due to an
+ unavailable VES Event Listener **MAY** leverage to ``publishEventBatch``
+ operation to redeliver buffered events. Please note this can only be
+ used when all buffered events belong to the same domain due to the
+ restrictions in place for the operation.
Security
~~~~~~~~~~
-.. req::
- :id: R-42366
- :target: VNF or PNF
- :keyword: MUST
- :updated: dublin
-
- The VNF or PNF **MUST** support secure connections and transports such as
- Transport Layer Security (TLS) protocol
- [`RFC5246 <https://tools.ietf.org/html/rfc5246>`_] and should adhere to
- the best current practices outlined in
- `RFC7525 <https://tools.ietf.org/html/rfc7525>`_.
-
-.. req::
- :id: R-44290
- :target: VNF or PNF
- :keyword: MUST
- :updated: dublin
-
- The VNF or PNF **MUST** control access to ONAP and to VNFs or PNFs, and creation
- of connections, through secure credentials, log-on and exchange mechanisms.
-
-.. req::
- :id: R-47597
- :target: VNF or PNF
- :keyword: MUST
- :updated: dublin
-
- The VNF or PNF **MUST** carry data in motion only over secure connections.
-
.. req::
:id: R-68165
:target: VNF or PNF
Information (SPI) or certain proprietary data, in addition to applying the
regular procedures for securing access and delivery.
-.. req::
- :id: R-01427
- :target: VNF or PNF
- :keyword: MUST
- :introduced: casablanca
- :updated: el alto
-
- If the VNF or PNF is using Basic Authentication, then the VNF or
- PNF **MUST** support the provisioning of security and authentication
- parameters (HTTP username and password) in order to be able to
- authenticate with DCAE VES Event Listener.
-
- Note: The configuration management and provisioning software
- are specific to a vendor architecture.
-
-.. req::
- :id: R-894004
- :target: VNF or PNF
- :keyword: MUST
- :introduced: casablanca
- :updated: el alto
-
- If the VNF or PNF is using Basic Authentication, then when the VNF
- or PNF sets up a HTTPS connection to the DCAE VES Event Listener,
- the VNF or PNF **MUST** provide a username and password to the
- DCAE VES Event Listener in the Authorization header and the VNF
- or PNF MUST support one-way TLS authentication.
-
- Note: In one-way TLS authentication, the client (VNF or PNF)
- must authentication the server (DCAE) certificate.
-
-.. req::
- :id: R-55634
- :target: VNF or PNF
- :keyword: MUST
- :introduced: el alto
-
- If VNF or PNF is using Basic Authentication, then the VNF or PNF
- **MUST** be in compliance with
- `RFC7617 <https://tools.ietf.org/html/rfc7617>`_ for authenticating HTTPS
- connections to the DCAE VES Event Listener.
-
-.. req::
- :id: R-43387
- :target: VNF or PNF
- :keyword: MUST
- :introduced: el alto
-
- If the VNF or PNF is using Certificate Authentication, the
- VNF or PNF **MUST** support mutual TLS authentication and the Subject
- Name in the end-entity certificate MUST be used according to
- `RFC5280 <https://tools.ietf.org/html/rfc5280>`_.
-
- Note: In mutual TLS authentication, the client (VNF or PNF) must
- authenticate the server (DCAE) certificate and must provide its own
- X.509v3 end-entity certificate to the server for authentication.
.. req::
:id: R-33878
:target: VNF or PNF
:keyword: MUST
:introduced: el alto
+ :updated: guilin
- The VNF or PNF **MUST** support one of the following authentication
- methods for authenticating HTTPS connections to the DCAE VES Event
- Listener:
-
- - The preferred method is Certificate Authentication
-
- - The non-preferred option is Basic Authentication.
+ The VNF or PNF **MUST** utilize one of the authentication methods
+ prescribed by the relevant VES Event Listener specification.
+.. _bulk_performance_measurement:
Bulk Performance Measurement
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. req::
:id: R-841740
The VNF or PNF **SHOULD** support FileReady VES event for event-driven bulk transfer
of monitoring data.
-
.. req::
:id: R-440220
:target: VNF or PNF
Note: Recommended period is at least 24 hours.
-PM Dictionary
-^^^^^^^^^^^^^^
-
-The Performance Management (PM) Dictionary is used by analytics applications
-to interpret and process perf3gpp measurement information from vendors,
-including measurement name, measurement family, measured object class,
-description, collection method, value ranges, unit of measure, triggering
-conditions and other information. The ultimate goal is for analytics
-applications to dynamically process new and updated measurements based on
-information in the PM Dictionary.
-
-The PM dictionary is supplied by NF vendors in two parts:
-
- - PM Dictionary Schema: specifies meta-information about perf3gpp
- measurement events from that vendor. The meta-information is conveyed
- using standard meta-information keywords, and may be extended to include
- vendor-specific meta-information keywords. The PM Dictionary Schema may
- also convey a range of vendor-specific values for some of the keywords.
-
- - PM Dictionary: defines specific perf3gpp measurements sent by vendor VNFs
- or PNFs (each of which is compliant with a referenced PM Dictionary
- Schema).
-
-Note:
-
- - A vendor may provide multiple versions of the PM Dictionary Schema and
- refer to those versions from the PM Dictionary.
-
- - Please refer to the latest version of the VES Event Registration
- specification for the listing of the PM Dictionary schema keywords, PM
- Dictionary Schema example and PM Dictionary example.
-
-
-FM Meta Data
-^^^^^^^^^^^^^^
-
-FM Meta Data enables vendors to provide meta information about FM events using
-a set of standard keywords. FM Meta Data is conveyed in the YAML event
-registration using the YAML Comment qualifier. The FM Meta Data section is
-optional.
-
-FM Meta Data includes Alarm Meta Data and Fault Meta Data:
-
- - FM Meta Data keywords must be provided in 'hash format' as Keyword: Value.
-
- - FM Meta Data values containing whitespace must be enclosed in single
- quotes. Successive keywords must be separated by commas.
-
- - Alarm Meta Data, if provided, shall be placed in the YAML comments
- qualifier at the top of the event registration for the alarm.
-
- - Fault Meta Data, if provided, shall be placed in the YAML comments
- qualifier of faultFields.alarmAdditionalInformation within each alarm.
-
-The above conventions will make machine processing of FM Meta Data Keywords
-easier to perform.
-
-Note:
-
- - Please refer to the latest version of the VES Event Registration
- specification for the listing of the FM Alarm Meta Data keywords, Fault
- Meta Data keywords and FM Meta Data examples.
-
-
.. |image0| image:: ../Data_Model_For_Event_Records.png
.. |image1| image:: ../VES_JSON_Driven_Model.png
Code Review / vnfrqts / requirements.git / blobdiff