Doc updates for London

[dcaegen2.git] / docs / sections / apis / ves-hv / index.rst

diff --git a/docs/sections/apis/ves-hv/index.rst b/docs/sections/apis/ves-hv/index.rst
index b477ba1..88a240e 100644 (file)
--- a/docs/sections/apis/ves-hv/index.rst
+++ b/docs/sections/apis/ves-hv/index.rst
@@ -5,7 +5,6 @@
 HV-VES (High Volume VES)
 ========================
 
-:Date: 2018-10-05
 
 .. contents::
     :depth: 4
@@ -25,8 +24,11 @@ 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 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.
@@ -39,7 +41,7 @@ Payload is binary-encoded, using Google Protocol Buffers (GPB) representation of
 .. 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.
@@ -47,25 +49,27 @@ data should be placed. Domain-specific data are encoded as well with GPB. A doma
 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 defined domain->topic mapping looks as follows:
+In case of Helm deployment routing is defined in values.yaml file in HV-VES Helm Chart.
 
-- perf3gpp -> HV_VES_PERF3GPP
+
+.. _supported_domains:
 
 Supported domains
 =================
 
-Domains supported by **HV-VES**:
+Domains that are currently supported by HV-VES:
 
-- perf3gpp
+- 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:`supported_domains`
+For domains descriptions, see :ref:`domains_supported_by_hvves`
 
 .. _hv_ves_behaviors: