HV-VES (High Volume VES)
========================
-:Date: 2018-10-05
.. contents::
:depth: 4
+
..
Overview
============
HV-VES is exposed as NodePort service on Kubernetes cluster on port 30222/tcp.
-It uses plain, insecure TCP connection without socket data encryption. In Casablanca release, there is an experimental option to enable SSL/TLS (see :ref:`authorization`).
-Without TLS client authentication/authorization is not possible.
+By default, as of the Frankfurt release, all TCP communications are secured using
+SSL/TLS. Plain, insecure TCP connections without socket data encryption can be enabled if needed.
+ (see ref:`ssl_tls_authorization`).
+
+Without TLS, client authentication/authorization is not possible.
Connections are stream-based (as opposed to request-based) and long-running.
Communication is wrapped with thin Wire Transfer Protocol, which mainly provides delimitation.
.. literalinclude:: VesEvent.proto
:language: protobuf
-HV-VES makes routing decisions based mostly on the content of the **Domain** parameter in the VES Common Event Header.
+HV-VES makes routing decisions based on the content of the **domain** field or **stndDefinedNamespace** field in case of stndDefined events.
The PROTO file, which contains the VES CommonEventHeader, comes with a binary-type Payload (eventFields) parameter, where domain-specific
data should be placed. Domain-specific data are encoded as well with GPB. A domain-specific PROTO file is required to decode the data.
-Domain **perf3gpp**
-===================
-
-The purpose of the **perf3gpp** domain is to deliver performance measurements from a network function (NF) to ONAP in 3GPP format.
-The first application of this domain is frequent periodic delivery of structured RAN PM data commonly referred to as Real Time PM (RTPM).
-The equipment sends an event right after collecting the PM data for a granularity period.
-
-The characteristics of each event in the **perf3gpp** domain:
-
-- Single measured entity, for example, BTS
-- Single granularity period (collection *begin time* and *duration*)
-- Optional top-level grouping in one or more PM groups
-- Grouping in one or more measured objects, for example, cells
-- One or more reported PM values for each measured object
-
-Due to the single granularity period per event, single equipment supporting multiple concurrent granularity periods might send more than one event at a given reporting time.
-
-The **perf3gpp** domain is based on 3GPP specifications:
+API towards DMaaP
+=================
-- `3GPP TS 28.550 <http://www.3gpp.org/ftp//Specs/archive/28_series/28.550/>`_
-- `3GPP TS 32.431 <http://www.3gpp.org/ftp//Specs/archive/32_series/32.431/>`_
-- `3GPP TS 32.436 <http://www.3gpp.org/ftp//Specs/archive/32_series/32.436/>`_
+HV-VES Collector forwards incoming messages to a particular DMaaP Kafka topic based on the domain (or stndDefinedNamespace) and configuration. Every Kafka record is comprised of a key and a value. In case of HV-VES:
-The event structure is changed in comparison to the one presented in 3GPP technical specifications. The 3GPP structure is enhanced to provide support for efficient transport.
+- **Kafka record key** is a GPB-encoded `CommonEventHeader`.
+- **Kafka record value** is a GPB-encoded `VesEvent` (`CommonEventHeader` and domain-specific `eventFields`).
-Definitions for the **perf3gpp** domain are stored in Perf3gppFields.proto and MeasDataCollection.proto, listed below:
+In both cases raw bytes might be extracted using ``org.apache.kafka.common.serialization.ByteArrayDeserializer``. The resulting bytes might be further passed to ``parseFrom`` methods included in classes generated from GPB definitions. WTP is not used here - it is only used in communication between PNF/VNF and the collector.
-.. literalinclude:: Perf3gppFields.proto
- :language: protobuf
+In case of Helm deployment routing is defined in values.yaml file in HV-VES Helm Chart.
-.. literalinclude:: MeasDataCollection.proto
- :language: protobuf
+.. _supported_domains:
-API towards DMaaP
+Supported domains
=================
-HV-VES Collector forwards incoming messages to a particular DMaaP Kafka topic based on the domain and configuration. Every Kafka record is comprised of a key and a value. In case of HV-VES:
+Domains that are currently supported by HV-VES:
-- **Kafka record key** is a GPB-encoded `CommonEventHeader`.
-- **Kafka record value** is a GPB-encoded `VesEvent` (`CommonEventHeader` and domain-specific `eventFields`).
-
-In both cases raw bytes might be extracted using ``org.apache.kafka.common.serialization.ByteArrayDeserializer``. The resulting bytes might be further passed to ``parseFrom`` methods included in classes generated from GPB definitions. WTP is not used here - it is only used in communication between PNF/VNF and the collector.
+- perf3gpp - basic domain to Kafka topic mapping
+- stndDefined - specific routing, when event has this domain, then stndDefinedNamespace field value is mapped to Kafka topic
+For domains descriptions, see :ref:`domains_supported_by_hvves`
.. _hv_ves_behaviors:
.. note:: xNF (VNF/PNF) can split messages bigger than 1 MiB and set `sequence` field in CommonEventHeader accordingly. It is advised to use smaller than 1 MiB messages for GPBs encoding/decoding efficiency.
- Skipped messages (for any of the above reasons) might not leave any trace in HV-VES logs.
+
Code Review / dcaegen2.git / blobdiff