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
.. Copyright 2017 AT&T Intellectual Property, All rights reserved
.. Copyright 2017-2018 Huawei Technologies Co., Ltd.
-.. _ves_event_listener_7_1:
+.. _ves_event_listener_7_2:
-Service: VES Event Listener 7.1.1
----------------------------------
+Service: VES Event Listener 7.2
+-------------------------------
+-----------------------------------------------------------------------------+
| **Legal Disclaimer** |
:Document: VES Event Listener
-:Revision: 7.1.1
-:Revision Date: January 28th, 2020
-:Author: Rich Erickson
+:Revision: 7.2
+:Revision Date: May 6th, 2020
+:Author: Trevor Lovett
+-----------------+-----------------------------+
| Contributors: | **Min Chen – AT&T** |
| | **Tim Verall – Intel** |
| | |
| | **Sumit Verdi – VMWare** |
+| | |
+| | **Trevor Lovett – AT&T** |
+| | |
+| | **Rich Erickson – AT&T** |
+-----------------+-----------------------------+
.. contents:: Table of Contents
Listener. 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 Event Listener is
-capable of receiving any event sent in the VES Common Event Format. The
-Common Event Format is expressed in JSON schema in section 4 of this
-document. In the Common Event Format, an event consists of a required
-Common Event Header block (i.e., object) accompanied by zero or more
-event domain blocks.
+capable of receiving any event sent in the VES
+:ref:`ves_common_event_format_7_2`. In the VES Common Event Format, an event
+consists of a required
+:ref:`Common Event Header <ves_common_event_header_7_2>` (i.e., object)
+accompanied by zero or more event domain blocks.
It should be understood that events are well structured packages of
-information, identified by an eventName, which are asynchronously
-communicated to subscribers who are interested in the eventName. Events
+information, identified by an ``eventName``, which are asynchronously
+communicated to subscribers who are interested in the ``eventName``. Events
can convey measurements, faults, syslogs, threshold crossing alerts and
other types of information. Events are simply a way of communicating
well-structured packages of information to one or more instances of an
-Event Listener service.
-
-This document describes a RESTful connectionless push event listener
-can receive single events or batches of events in the
-Common Event Format. In future, additional documents may describe other
-transports which make use of persistent TCP connections for high volumes
-of streaming events.
-
-Compatibility with ONAP
-~~~~~~~~~~~~~~~~~~~~~~~
-
-Unless otherwise stated, this version of the Event Listener specification is
-compatible with the release of ONAP the specification is released under. In
-other words, if the specification is released under the Frankfurt ONAP Release,
-then the VES Event Collectors provided by DCAE will also be compatible with
-the specification.
-
-Event Registration
-~~~~~~~~~~~~~~~~~~
-
-All events must be compliant with the common event format, but specific
-events identified by their eventNames, may require that certain fields,
-which are optional in the common event format, be present when they are
-published. For example, a specific eventName may require that specific
-name-value pairs be present in the extensible structures provided within
-the Common Event Format.
-
-Events are registered using an extensible YAML format (defined in a
-separate document), which specifies, for each eventName, the fields that
-are required, what field values may be sent, and any special handling
-that should be performed on those eventNames.
-
-Naming Standards for eventName
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-To prevent naming collisions, eventNames sent as part of the
-commonEventHeader, should conform to the following naming convention
-designed to summarize the purpose and type of the event, and to ensure
-the uniqueness of the eventName:
-
- {DomainAbbreviation}\_{PublisherName}\_{Description}
-
-Each underscore-separated subfield above should start with a capital
-letter and use camel-casing to separate words and acronyms. Acronyms
-should capitalize only the first letter of the acronym. Spaces and
-underscores should not appear within any subfield.
-
-The DomainAbbreviation subfield derives from the ‘domain’ field in the
-commonEventHeader, as specified below:
-
-- ‘Fault’ for the fault domain
-
-- ‘Heartbeat’ for the heartbeat domain
-
-- ‘Measurement’ for the measurement domain
-
-- ‘MobileFlow’ for the mobileFlow domain
-
-- ‘Notification’ for the notification domain
-
-- ‘Other’ for the other domain
-
-- ‘Perf3gpp’ for the perf3gpp domain
-
-- ‘PnfReg’ for the pnfRegistration domain
-
-- ‘SipSignaling’ for the sipSignaling domain
-
-- ‘StateChange’ for the stateChange domain
-
-- ‘Syslog’ for the syslog domain
-
-- ‘Tca’ for the thresholdCrossingAlert domain
-
-- ‘VoiceQuality’ for the voiceQuality domain
-
-The PublisherName subfield describes the vendor product or application
-publishing the event. This subfield conforms to the following
-conventions:
-
-- Vendor products are specified as:
-
- {productName}-{vendorName}
-
- For example: Visbc-Metaswitch or Vdbe-Juniper, where a hyphen is
- used to separate the productName and vendorName subfields. Note that
- the productName and vendorName subfields must not include hyphens
- themselves.
-
- Organizing the information in this way will cause an alphabetical
- listing of eventNames to sort similar network functions together,
- rather than to sort them by vendor.
-
- The productName subfield may describe a NF or a NFC. Where NFC names
- may be reused across different NF’s, they should be specified as:
-
- {NfName}:{NfcName}
-
- where a colon is used to separate the NfName and NfcName subfields.
- Note that the NfName and NfcName subfields must not include colons
- themselves.
-
- The ProductName may also describe other types of vendor modules or
- components such as a VM, application or hostname. As with NFs and
- NFCs, parent:child relationships may be communicated using colon as
- a subfield delimiter.
-
-- Service providers who adopt the VES Common Event Format for internal
- use, may provide PublisherName without the vendorName subfield. They
- would typically identify an application, system, service or
- microservice publishing the event (e.g., ‘Policy’, ‘So’,
- ‘MobileCallRecording’ or ‘Dkat’). As with NFs and NFCs, parent:child
- relationships may be communicated using colon as a subfield delimiter
- (e.g., ApplicationName:ApplicationComponent).
-
-The final subfield of the eventName name should describe, in a compact
-camel case format the specific information being conveyed by the event.
-In some cases, this final subfield may not be required (e.g., in the
-case of certain heartbeats).
-
-Examples of eventNames following the naming standards are provided
-below:
-
-- Tca\_Vdbe-Ericsson\_CpuThresholdExceeded
-
-- Heartbeat\_Visbc:Mmc-Metaswitch
-
-- Syslog\_Vdbe-Ericsson
-
-- Fault\_MobileCallRecording\_PilotNumberPoolExhaustion
-
-- Other\_So:WanBonding\_InstantiationPart1Complete
-
-EventId Use Cases Examples
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-
-eventId Examples:
-
-**NOTE**: Please note, the following are only *examples*, and other formats
-can be used provided they meet the requirement that the ``eventId`` is unique
-for all events or unique fault occurrence.
-
-**Example 1**: assumes a unique key for each domain consisting of domain
-followed by an integer domain<n> or domainId<n>, where <n> is a positive integer,
-e.g. fault000001, heartbeat000001, measurement000005,
-notification3gppPerfFileReady0005
-
-**Example 2**: assumes a unique integer key for all events across all domains
-<n>: 000000001, 00000002, 000000003
-
-Rules:
-
-1. All domains except Fault: each time a subsequent event is sent the
- integer part of eventId will increment by 1. Repeat of eventId
- assumes duplicate event. Sequence number is set to 0 for all domains
- except fault.
-
-2. eventId construction for Fault Events:
-
- a. Most likely scenario
-
- * The sourceName on each Fault event is the NF Instance Name
- (pnf-name or vnf-name or vm-name) as entered in A&AI uniquely
- identifying this instance of the NF.
-
- * The eventId on Fault events is the same every time a given
- fault is raised (including onset and re-raise)
-
- 1. The startEpochMicrosec value for the Fault event is the
- timestamp for when the fault onset occurs. Subsequent
- events for the same fault will keep the same startEpochMicrosec
- value.
-
- 2. lastEpochMicrosec indicates the current event time. This value
- will be updated for each subsequent event for a given fault.
-
- 3. The sequence number for each Fault event is set to 1 when the
- fault is raised and increments each time the same
- fault event is raised, until a clear is sent.
-
- * After the fault is cleared, a new eventId is used.
-
- .. image:: Use-Case-1.png
-
- b. **Alternative Scenario**: Network Function When Fault Event Status is Not
- Maintained.
-
- * The sourceName on each Fault event is the NF Instance Name
- (pnf-name or vnf-name or vm-name) as entered in A&AI uniquely
- identifying this instance of the NF.
-
- * The eventId on Fault events is the same every time a given
- fault is raised or cleared, even if it is re-raised after it
- had previously cleared. So, for example, if EMS loses
- contact with a particular device then a Fault event might be
- sent for a raise, re-raise (because EMS has re-tried and
- still can’t contact the device), clear (because EMS has
- re-tried and it can contact the device) and then raise again
- (because EMS has lost contact with the device again). The
- same eventId is used for all 4 of those Fault events.
-
- * The startEpochMicrosec value for each Fault event is the
- timestamp for when that event is generated, not when the
- fault first occurred. So all 4 of the Fault events in the
- previous bullet point would have a different timestamp.
-
- * lastEpochMicrosec indicates the current event time.
-
- * The sequence number for each Fault event is currently set to
- 0 on a raise and 1 on a clear. We could change that so that
- each Fault event is given a new monotonically increasing
- sequence number whether it is a raise or a clear if that is
- helpful (which is reset to 0 if the VM restarts) but they
- won’t be consecutive.
-
- * Normally, a clear is expected for each fault to be sent from a
- network function. However a few fault notification types will never
- be re-raised or cleared. In this case, general rules for VES events
- shall be followed with a new eventId for each event and sequence
- number set to 0.
-
- .. image:: Use-Case-2.png
-
-Measurement Expansion Fields
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-When expansion fields are used, the goal is to avoid custom development
-by the service provider collecting the fields, since custom development
-adds obvious cost, delay and resource overhead. In the domain of
-measurements, it is expected that a high percentage (perhaps as high as
-90 percent) of use cases for extensible fields can be satisfied by using
-the additionalMeasurements arrayOfNamedHashMap data structure in
-combination with a YAML registration file (provided at design time). The
-YAML registration file conveys meta-information about the processing of
-additionalMeasurements. For more information, please see the VES Event
-Registration specification and in particular the aggregationRole, castTo
-and isHomogeneous keywords.
-
-Syslogs
-~~~~~~~~
-
-Syslog’s can be classified as either Control or Session/Traffic. They
-differ by message content and expected volume:
-
-- Control logs are generally free-form human-readable text used for
- reporting errors or warnings supporting the operation and
- troubleshooting of NFs. The volume of these logs is typically less
- than 2k per day.
-
-- Session logs use common structured fields to report normal NF
- processing such as DNS lookups or firewall rules processed. The
- volume of these logs is typically greater than 1k per hour (and
- sometimes as high as 10k per second).
-
-VES supports both classes of syslog, however VES is only recommended for
-control logs or for lower volume session logs, less than 60k per hour.
-High volume session logging should use a file-based transport solution.
-
-Support for Protocols Other Than HTTPS
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-This API specification describes an HTTPS RESTful interface using the
-JSON content-type.
-
-Alternative API specifications may be provided in future using Google
-Protobuf, websockets, or Apache Avro.
-
-Configuration Requirements
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-This section provides network function configuration requirements for
-connectivity to a VES Event Listener via a RESTful API, using a VES JSON event.
-
-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.
-
-* **VES Event Listener IP Addresses or FQDNs resolved via DNS**: Two FQDNs
- and/or IP Addresses are required. NF shall select one of the 2 FQDNs/IP
- Addresses for sending events and if the NF is unable to get an
- acknowledgement within predefined configurable time interval
- or unable to establish a TCP connection due inability to resolve DNS query or
- if the VES Event Listener is unresponsive, then the NF shall attempt to use
- the other FQDN/IP Address to connect to VES Event Listener to deliver the
- VES Events. The events shall only be sent to one VES Event Listener at a time.
- Please note: If a FQDN is used, the DNS query would return a single IP
- address.
-* The active VES Event Listener (either the primary or secondary) will handle
- all VES events regardless of domain.
-* **VES Credentials**: If the NF is using Basic Authentication, then the NF
- must support the provisioning of security and authentication parameters
- (HTTP username and password) in order to be able to authenticate with the
- VES Event Listener. The Username and Password should be set unique per NF
- instance and should be configured during the NF deployment through a
- Controller or other means. The same password must also be configured into VES
- Event Listener instance for successful handshake.
-* **VES Heartbeat Interval**: This must be a configurable parameter; current
- default is 60 seconds. Note: the heartbeat interval should be greater than
- the ack timeout value.
-* **Measurement Interval**: For measurement events, the measurement interval
- must be configurable and a default of 300 seconds.
-* **ACK Timeout Interval**: Configurable, default 5 seconds.
-
-Event Domain Requirements/Expectations
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-* **Heartbeat**: Heartbeat events must be sent to VES Event Listener based on
- configurable parameter.
-* **Faults**: Fault events must be sent to the VES Event Listener as soon as
- they occur.
-* **Measurements**: All measurement events must be sent at the configured
- measurementInterval. If the NF provides both application and GuestOS
- metrics, then they must both use the same measurementInterval.
-* **Syslogs**: Syslog events should be sent to the VES Event Listener as soon as
- created, unless the NF is in debug mode (verbose logging enabled to get
- additional data to diagnose a problem), in which case the syslogs must be
- stored locally in the NF, for later access and possible secure transfer.
-* **Pre-defined Events Formats (Domain: Mobile Flow, TCA, State Chang, etc)**:
- Other events (State change, TCA, Mobile Flow, etc) may use other pre-defined
- VES domains from the VES Common Event Format specification based on the role
- of the NF.
-* **otherFields**: The otherFields Record defines fields for events belonging
- to the otherFields domain of the Technology Independent domain enumeration.
- This record provides a mechanism to convey a complex set of fields
- 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.
-
-Use of Collector FQDNs and/or IP Address
-++++++++++++++++++++++++++++++++++++++++
-
-* The NF must support two configurable endpoints for the VES Event Listener.
- One will be the active, primary event listener endpoint. The other
- will be a standby event listener in the event the active endpoint is
- unavailable.
-* When sending an event (FM, PM, Syslog, HB), the NF shall establish an HTTPS
- connection to one VES Event Listener FQDN/IP Address (if not already
- established) and send a VES event to it. Note that connections are not
- persistent. The events shall only be sent to only one VES Event Listener at a
- time.
-* The NF must be able to detect that a VES Event Listener endpoint is
- unavailable, and trigger the fail-over to the backup endpoint. The mechanism
- for detecting unavailability must be configurable by the Service Operator
- (e.g. number of attempts, timeout value).
-* If the NF is sending events to the VES Event Listener backup endpoint, then
- the NF must poll the primary endpoint on a configurable interval to check
- if the primary endpoint is now available. The NF may use the Heartbeat
- event or another mechanism to test availability. If the primary endpoint
- becomes available, then the NF must fallback to the primary endpoint.
-* A NF must only send a unique event to a single VES Event Listener endpoint
- at a time. In other words, the NF must not send a duplicate event to the
- secondary endpoint unless the delivery to the primary endpoint failed.
-* If both Primary and Secondary endpoints are not available, then the NF shall
- buffer the events locally. Refer to the Buffering of Events section for full
- details.
-* If a NF is unable to establish a connection with a VES Event Listener or does
- not get an acknowledgement within a specified time, then it should log this
- failure and, optionally, send a fault event indicating
- connection/acknowledgement failure via the alternate FQDN/IP Address. The
- intent of this fault is to inform the Service Operator that the VES Event
- Listener endpoint has become unreachable by the NF.
+VES Event Listener service.
+This document describes a RESTful, connectionless, push event listener
+that can receive single events or batches of events in the
+:ref:`ves_common_event_format_7_2`.
Versioning
-~~~~~~~~~~~
+^^^^^^^^^^
Three types of version numbers supported by this specification:
to that block (e.g., a field name is added or text changes are made
to the field descriptions) will increment only the minor number.
+Client Requirements
+^^^^^^^^^^^^^^^^^^^
+
+Any NF or client library that is responsible for delivering VES events
+to a VES Event Listener must comply with this specification to ensure events are
+received, accepted, and processed properly.
+
+Because the VES specification relies on clients to push events to the
+VES Event Listener, the client assumes certain responsibilities such as:
+
+- Providing configuration options supporting integration into a
+ Service Provider environment
+- Ensuring reliable delivery of events
+- Customization of default behaviors based on Service Provider needs
+
+While the documentation of these expectations are beyond the Event Listener
+specification, these requirements are documented in the ONAP VNF Requirements
+for :ref:`VES Monitoring Requirements <ves_monitoring_requirements>`.
+
+
+Compatibility with ONAP
+^^^^^^^^^^^^^^^^^^^^^^^
+
+Unless otherwise stated, this version of the Event Listener specification is
+compatible with the release of ONAP the specification is released under. In
+other words, if the specification is released under the Frankfurt ONAP release,
+then the VES Event Listeners provided by DCAE will also be compatible with
+this specification.
+
+Support for Protocols Other Than HTTPS
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This API specification describes an HTTPS RESTful interface using the
+JSON content-type.
+
+Alternative API specifications may be provided in future using Google
+Protocol Buffers, WebSockets, or Apache Avro.
+
Field Block Versions
-+++++++++++++++++++++
+^^^^^^^^^^^^^^^^^^^^
A summary of the latest field block version enums as of this version of
the API spec is provided below:
- voiceQualityFieldsVersion: 4.0
-Security
-^^^^^^^^
-
-Event sources must identify themselves to the VES Event Listener.
-
-There are 2 methods of HTTP authentication supported: Certificate Authentication
-and Basic Authentication.
-
-Basic authentication is supported in VES Event Listener for backward
-compatibility for existing NFs that are already managed by ONAP. New NFs should
-support Certificate Authentication. Because the security is better, NFs may
-choose to only support Certificate Authentication and not support Basic
-Authentication.
-
-Basic Authentication
-~~~~~~~~~~~~~~~~~~~~
-
-When using Basic Authentication, the event source must not pass credentials on
-the query string. Credentials must be sent in an Authorization header as
-follows:
-
-1. The username and password are formed into one string as
- ``username:password``
-2. The resulting string is Base64 encoded to produce the encoded credential.
-3. The encoded credential is communicated in the header after the string
- ``Authorization: Basic``
-
-Because the credentials are merely encoded but not encrypted, HTTPS (rather
-than HTTP) should be used. HTTPS will also encrypt and protect event contents.
-
-Sample Request and Response
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Sample Request
-++++++++++++++
-
-.. code-block:: http
-
- POST /eventListener/v7 HTTP/1.1
- Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
- content-type: application/json
- content-length: 12345
- {
- "event": {
- "commonEventHeader": {
- "version": "4.1",
- "vesEventListenerVersion": "7.1.1",
- "domain": "heartbeat",
- "eventName": "Heartbeat_vIsbcMmc",
- "eventId": "heartbeat0000249",
- "sequence": 0,
- "priority": "Normal",
- "reportingEntityId": "cc305d54-75b4-431b-adb2-eb6b9e541234",
- "reportingEntityName": "ibcx0001vm002oam001",
- "sourceId": "de305d54-75b4-431b-adb2-eb6b9e546014",
- "sourceName": "ibcx0001vm002ssc001",
- "nfVendorName": "Ericsson",
- "nfNamingCode": "ibcx",
- "nfcNamingCode": "ssc",
- "startEpochMicrosec": 1413378172000000,
- "lastEpochMicrosec": 1413378172000000,
- "timeZoneOffset": "UTC-05:30"
- }
- }
- }
-
-
-Sample Success Response
-++++++++++++++++++++++++
-
-.. code-block:: http
-
- HTTPS/1.1 202 Accepted
- X-MinorVersion: 1
- X-PatchVersion: 1
- X-LatestVersion: 7.1
-
-
-Mutual TLS Certificate Authentication
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-When using Certificate Authentication, the event source must initialize the
-HTTPS connection with TLS 1.2 or higher and execute mutual authentication
-procedures according to `RFC5246 <https://tools.ietf.org/html/rfc5246#section-7.4.6>`__.
-The event source must authenticate the VES Listener certificate and must
-provide its own X.509v3 end-entity certificate to the VES Listener for
-authentication. The Subject Name in the end-entity certificate must be used
-according to `RFC5280 <https://www.ietf.org/rfc/rfc5280.txt>`__. If a
-certificate is provided by the NF but it is invalid, the VES Listener is
-expected to reject the connection and not fall back to basic authentication.
-
-Resource Structure
-^^^^^^^^^^^^^^^^^^
-
-REST resources are defined with respect to a ServerRoot:
-
-ServerRoot = https://{Domain|IP}:{Port}/{optionalRoutingPath}
-
-The resource structure is provided below::
-
- {ServerRoot}
- |
- |--- /eventListener/v{apiVersion}
- |
- |--- /eventBatch
-
-**Figure 1**: REST Resource Structure
-
-The {Port} above is typically 8443.
+.. _ves_common_event_format_7_2:
Common Event Format
^^^^^^^^^^^^^^^^^^^^
A JSON schema describing the Common Event Format is provided below and
is reproduced in the tables that follow.
-:download:`JSON <CommonEventFormat_30.1.1_ONAP.json>`
+:download:`JSON <CommonEventFormat_30.2_ONAP.json>`
Note on optional fields:
Common Event Header Data Types
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.. _ves_common_event_header_7_2:
+
Datatype: commonEventHeader
++++++++++++++++++++++++++++
| | | | cases, eventId must be the same as the |
| | | | initial alarm (along with the same |
| | | | startEpochMicrosec but with a different |
-| | | | sequence number). Note: see section 1.3 |
-| | | | for eventId use case examples. |
+| | | | sequence number). |
+| | | | See :ref:`ves_eventid_usecases_7_2` for |
+| | | | additional guidance on eventId usage. |
+-----------+----------+-----------+-----------------------------------------+
-| eventName | string | Yes | |
+| eventName | string | Yes | See :ref:`ves_eventname_guidelines_7_2`|
+| | | | for additional information on naming |
+| | | | events |
+-----------+----------+-----------+-----------------------------------------+
| eventType | string | No | |
+-----------+----------+-----------+-----------------------------------------+
| | | | digits to use). |
+-----------+----------+-----------+-----------------------------------------+
-Datatype: internalHeaderFields
-++++++++++++++++++++++++++++++
+Datatype: internalHeaderFields
+++++++++++++++++++++++++++++++
+
+The internalHeaderFields datatype is an undefined object which can
+contain arbitrarily complex JSON structures. It is intended to be
+defined separately by each service provider (e.g., AT&T) implementing
+the VES Event Listener. The fields in internalHeaderFields are not
+provided by any event source but instead are added by the VES Event
+Listener service itself as part of an event enrichment process necessary
+for efficient internal processing of events received by the VES Event
+Listener.
+
+
+.. _ves_eventname_guidelines_7_2:
+
+Best Practices for eventName
+++++++++++++++++++++++++++++
+
+To prevent naming collisions, eventNames sent as part of the
+commonEventHeader, should conform to the following naming convention
+designed to summarize the purpose and type of the event, and to ensure
+the uniqueness of the eventName:
+
+ ``{DomainAbbreviation}_{PublisherName}_{Description}``
+
+Each underscore-separated subfield above should start with a capital
+letter and use camel-casing to separate words and acronyms. Acronyms
+should capitalize only the first letter of the acronym. Spaces and
+underscores should not appear within any subfield.
+
+The DomainAbbreviation subfield derives from the ‘domain’ field in the
+commonEventHeader, as specified below:
+
+- ‘Fault’ for the fault domain
+
+- ‘Heartbeat’ for the heartbeat domain
+
+- ‘Measurement’ for the measurement domain
+
+- ‘MobileFlow’ for the mobileFlow domain
+
+- ‘Notification’ for the notification domain
+
+- ‘Other’ for the other domain
+
+- ‘Perf3gpp’ for the perf3gpp domain
+
+- ‘PnfReg’ for the pnfRegistration domain
+
+- ‘SipSignaling’ for the sipSignaling domain
+
+- ‘StateChange’ for the stateChange domain
+
+- ‘Syslog’ for the syslog domain
+
+- ‘Tca’ for the thresholdCrossingAlert domain
+
+- ‘VoiceQuality’ for the voiceQuality domain
+
+The PublisherName subfield describes the vendor product or application
+publishing the event. This subfield conforms to the following
+conventions:
+
+- Vendor products are specified as: ``{productName}-{vendorName}``
+
+ For example: ``Visbc-Metaswitch`` or ``Vdbe-Juniper``, where a hyphen is
+ used to separate the ``productName`` and ``vendorName`` subfields. Note that
+ the ``productName`` and ``vendorName`` subfields must not include hyphens
+ themselves.
+
+ Organizing the information in this way will cause an alphabetical
+ listing of eventNames to sort similar network functions together,
+ rather than to sort them by vendor.
+
+ The ``productName`` subfield may describe a NF or a NFC. Where NFC names
+ may be reused across different NF’s, they should be specified as:
+
+ ``{NfName}:{NfcName}``
+
+ where a colon is used to separate the ``NfName`` and ``NfcName`` subfields.
+ Note that the ``NfName`` and ``NfcName`` subfields must not include colons
+ themselves.
+
+ The ``productName`` may also describe other types of vendor modules or
+ components such as a VM, application or hostname. As with NFs and
+ NFCs, parent:child relationships may be communicated using colon as
+ a subfield delimiter.
+
+- Service providers who adopt the VES Common Event Format for internal
+ use, may provide PublisherName without the vendorName subfield. They
+ would typically identify an application, system, service or
+ microservice publishing the event (e.g., ‘Policy’, ‘So’,
+ ‘MobileCallRecording’ or ‘Dkat’). As with NFs and NFCs, parent:child
+ relationships may be communicated using colon as a subfield delimiter
+ (e.g., ApplicationName:ApplicationComponent).
+
+The final subfield of the eventName name should describe, in a compact
+camel case format the specific information being conveyed by the event.
+In some cases, this final subfield may not be required (e.g., in the
+case of certain heartbeats).
+
+Examples of event names following the naming standards are provided
+below:
+
+- ``Tca_Vdbe-Ericsson_CpuThresholdExceeded``
+
+- ``Heartbeat_Visbc:Mmc-Metaswitch``
+
+- ``Syslog_Vdbe-Ericsson``
+
+- ``Fault_MobileCallRecording_PilotNumberPoolExhaustion``
+
+- ``Other_So:WanBonding_InstantiationPart1Complete``
+
+.. _ves_eventid_usecases_7_2:
+
+EventId Use Cases Examples
+++++++++++++++++++++++++++
+
+``eventId`` Examples:
+
+**NOTE**: Please note, the following are only *examples*, and other formats
+can be used provided they meet the requirement that the ``eventId`` is unique
+for all events or unique fault occurrence.
+
+**Example 1**: assumes a unique key for each domain consisting of domain
+followed by an integer domain<n> or domainId<n>, where <n> is a positive integer,
+e.g. fault000001, heartbeat000001, measurement000005,
+notification3gppPerfFileReady0005
+
+**Example 2**: assumes a unique integer key for all events across all domains
+<n>: 000000001, 00000002, 000000003
+
+Rules:
+
+1. All domains except Fault: each time a subsequent event is sent the
+ integer part of eventId will increment by 1. Repeat of eventId
+ assumes duplicate event. Sequence number is set to 0 for all domains
+ except fault.
+
+2. eventId construction for Fault Events:
+
+ a. Most likely scenario
+
+ * The sourceName on each Fault event is the NF Instance Name
+ (pnf-name or vnf-name or vm-name) as entered in A&AI uniquely
+ identifying this instance of the NF.
+
+ * The eventId on Fault events is the same every time a given
+ fault is raised (including onset and re-raise)
+
+ 1. The startEpochMicrosec value for the Fault event is the
+ timestamp for when the fault onset occurs. Subsequent
+ events for the same fault will keep the same startEpochMicrosec
+ value.
+
+ 2. lastEpochMicrosec indicates the current event time. This value
+ will be updated for each subsequent event for a given fault.
+
+ 3. The sequence number for each Fault event is set to 1 when the
+ fault is raised and increments each time the same
+ fault event is raised, until a clear is sent.
+
+ * After the fault is cleared, a new eventId is used.
+
+ .. image:: Use-Case-1.png
+
+ b. **Alternative Scenario**: Network Function When Fault Event Status is Not
+ Maintained.
+
+ * The sourceName on each Fault event is the NF Instance Name
+ (pnf-name or vnf-name or vm-name) as entered in A&AI uniquely
+ identifying this instance of the NF.
+
+ * The eventId on Fault events is the same every time a given
+ fault is raised or cleared, even if it is re-raised after it
+ had previously cleared. So, for example, if EMS loses
+ contact with a particular device then a Fault event might be
+ sent for a raise, re-raise (because EMS has re-tried and
+ still can’t contact the device), clear (because EMS has
+ re-tried and it can contact the device) and then raise again
+ (because EMS has lost contact with the device again). The
+ same eventId is used for all 4 of those Fault events.
+
+ * The startEpochMicrosec value for each Fault event is the
+ timestamp for when that event is generated, not when the
+ fault first occurred. So all 4 of the Fault events in the
+ previous bullet point would have a different timestamp.
+
+ * lastEpochMicrosec indicates the current event time.
+
+ * The sequence number for each Fault event is currently set to
+ 0 on a raise and 1 on a clear. We could change that so that
+ each Fault event is given a new monotonically increasing
+ sequence number whether it is a raise or a clear if that is
+ helpful (which is reset to 0 if the VM restarts) but they
+ won’t be consecutive.
+
+ * Normally, a clear is expected for each fault to be sent from a
+ network function. However a few fault notification types will never
+ be re-raised or cleared. In this case, general rules for VES events
+ shall be followed with a new eventId for each event and sequence
+ number set to 0.
+
+ .. image:: Use-Case-2.png
-The internalHeaderFields datatype is an undefined object which can
-contain arbitrarily complex JSON structures. It is intended to be
-defined separately by each service provider (e.g., AT&T) implementing
-the VES Event Listener. The fields in internalHeaderFields are not
-provided by any event source but instead are added by the VES Event
-Listener service itself as part of an event enrichment process necessary
-for efficient internal processing of events received by the VES Event
-Listener.
Technology Independent Datatypes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Datatype: measurementFields
****************************
-The measurementFields datatype consists of the following fields:
+The ``measurementFields`` datatype consists of the following fields:
+-------------+--------------+----------+-------------------------------------+
| Field | Type | Required?| Description |
| | | | measurementInterval |
+-------------+--------------+----------+-------------------------------------+
+
+Note on Measurement Expansion Fields
+""""""""""""""""""""""""""""""""""""
+
+The ``measurementFields`` data type provides fields that can be used to
+pass additional data with the event. These fields are listed below and
+referred to as expansion fields:
+
+* ``additionalFields``
+* ``additionalObjects``
+* ``additionalMeasurements``
+
+When expansion fields are used, the goal is to avoid custom development
+by the service provider collecting the fields, since custom development
+adds obvious cost, delay and resource overhead. In the domain of
+measurements, it is expected that a high percentage of use cases for
+extensible fields can be satisfied by using the ``additionalMeasurements``
+``arrayOfNamedHashMap`` data structure in combination with a YAML registration
+file (provided at design time). The YAML registration file conveys
+metadata about the processing of ``additionalMeasurements``. For more
+information, please see the VES Event Registration specification and in
+particular the ``aggregationRole``, ``castTo``, and ``isHomogeneous`` keywords.
+
Datatype: memoryUsage
**********************
| | | | to use. |
+--------------+-------------+----------+-------------------------------------+
+
+RESTful Web Services Definition
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Security
+~~~~~~~~
+
+Event sources must identify themselves to the VES Event Listener.
+
+There are 2 methods of HTTP authentication supported: Certificate Authentication
+and Basic Authentication.
+
+Basic authentication is supported in VES Event Listener for backward
+compatibility for existing NFs that are already managed by ONAP. New NFs should
+support Certificate Authentication. Because the security is better, NFs may
+choose to only support Certificate Authentication and not support Basic
+Authentication.
+
+Basic Authentication
+++++++++++++++++++++
+
+When using Basic Authentication, the event source must not pass credentials on
+the query string. Credentials must be sent in an Authorization header as
+follows:
+
+1. The username and password are formed into one string as
+ ``username:password``
+2. The resulting string is Base64 encoded to produce the encoded credential.
+3. The encoded credential is communicated in the header after the string
+ ``Authorization: Basic``
+
+Because the credentials are merely encoded but not encrypted, HTTPS (rather
+than HTTP) should be used. HTTPS will also encrypt and protect event contents.
+
+Sample Request and Response
++++++++++++++++++++++++++++
+
+Sample Request
+**************
+
+.. code-block:: http
+
+ POST /eventListener/v7 HTTP/1.1
+ Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
+ content-type: application/json
+ content-length: 12345
+ {
+ "event": {
+ "commonEventHeader": {
+ "version": "4.1",
+ "vesEventListenerVersion": "7.2",
+ "domain": "heartbeat",
+ "eventName": "Heartbeat_vIsbcMmc",
+ "eventId": "heartbeat0000249",
+ "sequence": 0,
+ "priority": "Normal",
+ "reportingEntityId": "cc305d54-75b4-431b-adb2-eb6b9e541234",
+ "reportingEntityName": "ibcx0001vm002oam001",
+ "sourceId": "de305d54-75b4-431b-adb2-eb6b9e546014",
+ "sourceName": "ibcx0001vm002ssc001",
+ "nfVendorName": "Ericsson",
+ "nfNamingCode": "ibcx",
+ "nfcNamingCode": "ssc",
+ "startEpochMicrosec": 1413378172000000,
+ "lastEpochMicrosec": 1413378172000000,
+ "timeZoneOffset": "UTC-05:30"
+ }
+ }
+ }
+
+
+Sample Success Response
+***********************
+
+.. code-block:: http
+
+ HTTPS/1.1 202 Accepted
+ X-MinorVersion: 2
+ X-PatchVersion: 0
+ X-LatestVersion: 7.2
+
+
+Mutual TLS Certificate Authentication
++++++++++++++++++++++++++++++++++++++
+
+When using Certificate Authentication, the event source must initialize the
+HTTPS connection with TLS 1.2 or higher and execute mutual authentication
+procedures according to `RFC5246 <https://tools.ietf.org/html/rfc5246#section-7.4.6>`__.
+The event source must authenticate the VES Listener certificate and must
+provide its own X.509v3 end-entity certificate to the VES Listener for
+authentication. The Subject Name in the end-entity certificate must be used
+according to `RFC5280 <https://www.ietf.org/rfc/rfc5280.txt>`__. If a
+certificate is provided by the NF but it is invalid, the VES Listener is
+expected to reject the connection and not fall back to basic authentication.
+
+Resource Structure
+~~~~~~~~~~~~~~~~~~
+
+REST resources are defined with respect to a ServerRoot:
+
+ServerRoot = https://{Domain|IP}:{Port}/{optionalRoutingPath}
+
+The resource structure is provided below::
+
+ {ServerRoot}
+ |
+ |--- /eventListener/v{apiVersion}
+ |
+ |--- /eventBatch
+
+**Figure 1**: REST Resource Structure
+
Exceptions
-^^^^^^^^^^^
+~~~~~~~~~~
RESTful Web Services Exceptions
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
++++++++++++++++++++++++++++++++
RESTful services generate and send exceptions to clients in response to
invocation errors. Exceptions send HTTP status codes (specified later in
+-----------+---------------+-------------+-----------------------------------+
Service Exceptions
-~~~~~~~~~~~~~~~~~~~
+++++++++++++++++++
- When a service is not able to process a request, and retrying the
- request with the same information will also result in a failure, and
- the issue is not related to a service policy issue, then the service
- will issue a fault using the service exception fault message.
- Examples of service exceptions include invalid input, lack of
- availability of a required resource or a processing error.
+When a service is not able to process a request, and retrying the
+request with the same information will also result in a failure, and
+the issue is not related to a service policy issue, then the service
+will issue a fault using the service exception fault message.
+Examples of service exceptions include invalid input, lack of
+availability of a required resource or a processing error.
- A service exception uses the letters 'SVC' at the beginning of the
- message identifier. ‘SVC’ service exceptions used by the VES Event
- Listener API are defined below.
+A service exception uses the letters 'SVC' at the beginning of the
+message identifier. ‘SVC’ service exceptions used by the VES Event
+Listener API are defined below.
+----------+--------------+-----------------------+----------------+----------+
| MessageId| Description | Text | Variables | Parent |
| | | Error code is %2. | %2: error code | |
+----------+--------------+-----------------------+----------------+----------+
- Table - Service Exceptions
+Table - Service Exceptions
Policy Exceptions
-~~~~~~~~~~~~~~~~~~
++++++++++++++++++
- When a service is not able to complete because the request fails to
- meet a policy criteria, then the service will issue a fault using the
- policy exception fault message. To clarify how a policy exception
- differs from a service exception, consider that all the input to an
- operation may be valid as meeting the required input for the
- operation (thus no service exception), but using that input in the
- execution of the service may result in conditions that require the
- service not to complete. Examples of policy exceptions include
- privacy violations, requests not permitted under a governing service
- agreement or input content not acceptable to the service provider.
-
- A Policy Exception uses the letters 'POL' at the beginning of the
- message identifier. ‘POL’ policy exceptions used by the VES Event
- Listener API are defined below.
+When a service is not able to complete because the request fails to
+meet a policy criteria, then the service will issue a fault using the
+policy exception fault message. To clarify how a policy exception
+differs from a service exception, consider that all the input to an
+operation may be valid as meeting the required input for the
+operation (thus no service exception), but using that input in the
+execution of the service may result in conditions that require the
+service not to complete. Examples of policy exceptions include
+privacy violations, requests not permitted under a governing service
+agreement or input content not acceptable to the service provider.
+
+A Policy Exception uses the letters 'POL' at the beginning of the
+message identifier. ‘POL’ policy exceptions used by the VES Event
+Listener API are defined below.
+----------+---------------+-----------------------+---------------+----------+
| MessageId| Description |Text | Variables | Parent |
| | | limit | | |
+----------+---------------+-----------------------+---------------+----------+
- Table - Policy Exceptions
-
-RESTful Web Services Definition
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Table - Policy Exceptions
REST Operation Overview
~~~~~~~~~~~~~~~~~~~~~~~~~
to all requests. Additionally, clients may populate these headers on
requests to indicate the specific version they are interested in.
-- X-MinorVersion: 1
+- X-MinorVersion: 2
-- X-PatchVersion: 1
+- X-PatchVersion: 0
-- X-LatestVersion: 7.1
+- X-LatestVersion: 7.2
If a client requests major version 7 (per the REST resource URL) and
does not specify the above headers, then they will be provided with the
request major version 7 with X-MinorVersion: 1, they will get the latest
patch version of 7.1, which is 7.1.1.
-Buffering of Events
-+++++++++++++++++++
-
-``{ServerRoot}`` is defined in section 3 of this document, which defines the
-REST resource URL. One or more FQDNs may be provisioned in an event source
-when it is instantiated or updated. If an event source is unable to reach any
-of the provisioned FQDNs, it should buffer the event data specified below, up
-to a maximum of 1 hour, and re-transmit them once a connection has been
-established.
-
-The following events should be buffered:
-
-* Faults with eventSeverity of ``MINOR``, ``MAJOR``, ``NORMAL``, or ``CRITICAL``
- with following expected behavior:
-
- * NF keeps a First-In-First-Out buffer.
- * Until the collectors are working again, it is desired that the NF sends
- the final state events only, and not intermediate ones. However, it is
- acceptable to buffer all events and send them over to the collector in
- the same order in which they were generated/received.
-
-* When one VES Event Listener connectivity is re-established, NF should first
- send the buffered events and then start sending the new events.
-
- * Syslog with syslogSev of ``Emergency``, ``Alert``, ``Critical``,
- ``Error``, or ``Warning``
-
-* All measurements events
-
-publishEventBatch Requirements
-******************************
-
-Buffered events can be sent in batch using ``publishEventBatch``. However, a
-NF vendor must only include multiple events for the same domain in the
-``publishEventBatch``. The ``publishEventBatch`` event must also conform to
-event size limits.
-
-``publishEventBatch`` events are handled similarly to a single event. The
-acknowledgement from the VES Event Listener is for the ``publishEventBatch`` and
-not individual events within the ``publishEventBatch``.
-
-Debug Mode
-**********
-
-NFs acting as event sources should not send syslog events to the
-VES Event Listener during debug mode, but should store syslog events locally
-for access, and possible FTP transfer, via the NF console (e.g., command line
-interface).
-
-.. _msg-size:
+.. _ves_msg_size_7_2:
Message Size
++++++++++++
The maximum allowed message size is 2 megabytes of uncompressed text.
-However,messages of this size have been known to cause performance and data
-loss. It is strongly recommended,that messages not exceed 1 megabyte.
+However, messages of this size have been known to cause performance and data
+loss. It is strongly recommended, that messages not exceed 1 megabyte.
In a future version of the specification, a 1 megabyte limit will become
a mandatory requirement.
| | | | message shall be returned. |
+---------------+----------+----------+---------------------------------------+
| Content-length| integer | No | Note that content length is limited to|
-| | | | 2 Megabyte (see :ref:`msg-size`) |
+| | | | 2 Megabyte |
+| | | | (see :ref:`ves_msg_size_7_2`) |
+---------------+----------+----------+---------------------------------------+
| Content-type | string | Yes | Must be set to one of the following |
| | | | values: |
"event": {
"commonEventHeader": {
"version": "4.1",
- "vesEventListenerVersion": "7.1.1",
+ "vesEventListenerVersion": "7.2",
"domain": "fault",
"eventName": "Fault_Vscf:Acs-Ericcson_PilotNumberPoolExhaustion",
"eventId": "fault0000245",
.. code-block:: http
HTTPS/1.1 202 Accepted
- X-MinorVersion: 1
- X-PatchVersion: 1
- X-LatestVersion: 7.1.1
+ X-MinorVersion: 2
+ X-PatchVersion: 0
+ X-LatestVersion: 7.2
Sample Error Responses
************************
Date: Thu, 04 Jun 2009 02:51:59 GMT
X-MinorVersion: 1
X-PatchVersion: 1
- X-LatestVersion: 7.1.1
+ X-LatestVersion: 7.2
{
"requestError": {
Date: Thu, 04 Jun 2009 02:51:59 GMT
X-MinorVersion: 1
X-PatchVersion: 1
- X-LatestVersion: 7.1.1
+ X-LatestVersion: 7.2
{
"requestError": {
- Provides HTTP response codes as well as Service and Policy error
messages
+``publishEventBatch`` events are handled similarly to a single event. The
+acknowledgement from the VES Event Listener is for the ``publishEventBatch`` and
+not individual events within the ``publishEventBatch``.
+
Call Flow
+++++++++++
| | | | returned. |
+---------------+----------+----------+---------------------------------------+
| Content-length| integer | No | Note that content length is limited to|
-| | | | 2 megabyte (see :ref:`msg-size`). |
+| | | | 2 megabyte |
+| | | | (see :ref:`ves_msg_size_7_2`). |
+---------------+----------+----------+---------------------------------------+
| Content-type | string | Yes | Must be set to one of the following |
| | | | values: |
| **Parameter**| **Data Type**| **Required?**| **Brief description** |
+--------------+--------------+--------------+-------------------------------+
| eventList | eventList | Yes | Array of events conforming to |
-| | | | the common event format. |
+| | | | the common event format. All |
+| | | | events must belong to a |
+| | | | single domain. |
+--------------+--------------+--------------+-------------------------------+
Output Parameters
{
"commonEventHeader": {
"version": "4.1",
- "vesEventListenerVersion": "7.1.1",
+ "vesEventListenerVersion": "7.2",
"domain": "fault",
"eventName": "Fault_Vscf:Acs-Ericcson_PilotNumberPoolExhaustion",
"eventId": "fault0000250",
{
"commonEventHeader": {
"version": "4.1",
- "vesEventListenerVersion": "7.1.1",
+ "vesEventListenerVersion": "7.2",
"domain": "fault",
"eventName": " Fault_Vscf:Acs-Ericcson_RecordingServerUnreachable",
"eventId": "fault0000251",
.. code-block:: http
HTTPS/1.1 202 Accepted
- X-MinorVersion: 1
- X-PatchVersion: 1
- X-LatestVersion: 7.1.1
+ X-MinorVersion: 2
+ X-PatchVersion: 0
+ X-LatestVersion: 7.2
Sample Error Responses
************************
content-type: application/json
content-length: 12345
Date: Thu, 04 Jun 2009 02:51:59 GMT
- X-MinorVersion: 1
- X-PatchVersion: 1
- X-LatestVersion: 7.1.1
+ X-MinorVersion: 2
+ X-PatchVersion: 0
+ X-LatestVersion: 7.2
{
"requestError": {
content-type: application/json
content-length: 12345
Date: Thu, 04 Jun 2009 02:51:59 GMT
- X-MinorVersion: 1
- X-PatchVersion: 1
- X-LatestVersion: 7.1.1
+ X-MinorVersion: 2
+ X-PatchVersion: 0
+ X-LatestVersion: 7.2
{
"requestError": {
**APPC (formerly APP-C)**. Application Controller. Handles the life
cycle management of Virtual Network Functions (VNFs).
-**ASDC**. AT&T Service Design and Creation Platform: the original name
-for the SDC. Replaced by SDC.
-
**Common Event Format**. A JSON schema describing events sent to the VES
Event Listener.
‘keyName’, ‘value’: ‘keyValue’} was replaced with {‘keyName’:
‘keyValue’}).
-**ICE**. Incubation and Certification Environment. Facilitates vendors
-and third-party in developing virtual network functions using ONAP and a
-network cloud.
-
**IPMI**. The `Intelligent Platform Management
Interface <https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface>`__.
| | | - Changed the location of the doc to VNF |
| | | Requirements and changed the formatting |
+-----------+---------+-------------------------------------------------------+
-| 1/28/202 | v7.1.1 | - Changed event sizes from 2Mb to 1Mb |
+| 1/28/2020 | v7.1.1 | - Changed event sizes from 2Mb to 1Mb |
| | | - Configuration Requirement comments addressed |
| | | - Changed DCAE Collector to VES Event Listener |
| | | - Replaced VNF with NF where appropriate |
| | | - Relaxed various requirements related to camel |
| | | casing of values from 'must' to 'should' |
+-----------+---------+-------------------------------------------------------+
+| 5/27/2020 | v7.2 | - Re-organized sections to flow more logically |
+| | | - Moved NF requirements to VNF Requirements |
+| | | - Changed DCAE Collector to VES Event Listener |
++-----------+---------+-------------------------------------------------------+
.. _time_zone_abbreviations: https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations
.. _Common_definitions: http://technical.openmobilealliance.org/Technical/release_program/docs/REST_NetAPI_Common/V1_0-20120417-C/OMA-TS-REST_NetAPI_Common-V1_0-20120417-C.pdf
Code Review / vnfrqts / requirements.git / commitdiff
