HV-VES (High Volume VES)
========================
-:Date: 2018-10-05
.. contents::
:depth: 4
+.. toctree::
+ :maxdepth: 1
+
+ ./supported-domains.rst
+
..
Overview
Component description can be found under `HV-VES Collector`_.
-.. _HV-VES Collector: ../../services/ves-hv/index.html
+.. _HV-VES Collector: ../../services/ves-hv/index.rst
+.. _Domains supported by HV-VES: ./supported-domains.rst
.. _tcp_endpoint:
============
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 Dublin release,
-there is an experimental option to enable SSL/TLS (see :ref:`ssl_tls_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:: WTP.asn
- :language: asn
+ :language: text
Payload is binary-encoded, using Google Protocol Buffers (GPB) representation of the VES Event.
.. 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.
API towards DMaaP
=================
-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:
+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:
- **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.
-By default, **HV-VES** will use routing defined in **k8s-hv-ves.yaml-template** in **dcaegen2/platform/blueprints project**.
-Currently there is one domain->topic mapping defined: perf3gpp->HV_VES_PERF3GPP
+In case of Helm deployment routing is defined in values.yaml file in HV-VES Helm Chart.
.. _supported_domains:
Supported domains
=================
-As for now **HV-VES** supports only **perf3gpp** domain
+Domains that are currently supported by HV-VES:
+
+- 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`
.. 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