blob: acb49e00844520f836adc5400afd2dc2a17a1398 [file] [log] [blame]
Andrea Campanella71221c82021-02-01 14:40:48 +01001VOLTHA Architecture Overview
2=============================
3
4.. figure:: ./../_static/voltha_diagram.svg
5 :alt: VOLTHA Component Diagram
6 :width: 50%
7 :align: center
8
9 VOLTHA Component Diagram
10
11A VOLTHA and ONOS deployment is comprised of two main groups of services, the ``infrastructure`` made of storage,
12message bus and SDN controller and a number of voltha stacks, each including voltha core, adapters and openflow agent.
13
14All the components in the VOLTHA project are containerized and the default deployment environment is ``kubernetes``,
15where they are installed through ``helm`` charts.
16The location of the ``kubernetes`` cluster is not of a concern of the VOLTHA project per se, it can be deployed in a
17data center, on the cloud or on the OLT box itself if the hardware is powerful enough, e.g. multi-chassis OLTs.
18Proper considerations should be made by the operator around failure and resiliency of the system in any of these
19different deployments. ONF recommends to deploy the ``kubernetes`` cluster on a 3 node bare metal cluster located
20close to the OLT(s) location, e.g. operator's Central Office.
21
22Alongside VOLTHA and ONOS, the Device Manager, a (optional) component which implements the
23`Device Management Interface <https://github.com/opencord/device-management-interface>`_,
24can be deployed to support non VOLTHA related operations, e.g. OLT software update, through standard APIs.
25
26Infrastructure
27---------------
28
29The Infrastructure for a VOLTHA deployment contains, at the bare minimum:
30
Andrea Campanella8245ff52021-10-06 11:50:03 +020031 - A ``kafka`` cluster. `Kafka <https://kafka.apache.org>`_ is the messaging bus system used publish events to the
32 outside listeners, such as the Operator's OSS/BSS. The recommended deployment size is 3 nodes for failure and
33 resiliency, but can also be a single node.
Andrea Campanella71221c82021-02-01 14:40:48 +010034 - An ``etcd`` cluster. `ETCD <https://etcd.io>`_ is used as data store by the different VOLTHA
35 components. The recommended deployment size is 3 nodes for failure and resiliency,
36 but can also be a single node.
37 - ``ONOS`` SDN Controller. `ONOS <https://github.com/opennetworkinglab/onos>`_ manages the VOLTHA abstracted
38 switch, installs traffic forwarding rules and handles different type of failures, e.g. port down events.
39 ONOS comes with it's own storage in the form of an ``Atomix`` cluster.
40 The recommended deployment size is 3 nodes for ONOS and 3 nodes for Atomix to achieve high avaliability and
41 resiliency, but can also be a single node with no atomix.
42 - [Optional] ``radius`` server. A radius server is required for the ATT workflow for EAPOL based authentication.
43 - [Optional] ``Jaeger`` tracing. Jaeger allows you to perform end-to-end distributed tracing of transactions across
44 the different microservices, allowing for easier monitoring and troubleshooting.
45 - [Optional] ``EFK (Elastic, Fluentd, Kibana)`` stack. EFK allows enhanced log management. Fluentd will collect the
46 logs and send it to Elasticsearch which will save them in its database. Kibana will fetch the logs from
47 Elasticsearch and display it on a web UI.
48
49An infrastructure comprised of 3 node clusters of each of the components (ETCD, KAFKA, ONOS) can support up to
5010 VOLTHA stacks, where each stack is connected up to 1024 subscribers, located on a single OLT or divided over a
51handful of them.
52
53VOLTHA Stack
54-------------
55
56A single VOLTHA stack contains several components, each interacting with one another through open APIs defined in
57protobuf within the `voltha-protos <https://github.com/opencord/voltha-protos>`_ repo:
58
59 - ``voltha-core``. The `VOLTHA core <https://github.com/opencord/voltha-go>`_ is the heart of the VOLTHA
60 components. It receives requests from the Northbound, divides them in the proper sub-set of
61 operations for each of adapters. Handles registration of the adapters and configuration information
62 of ONUs and OLTs which it stores in ETCD, such as ports, flows, groups and other dataplane constructs.
63 It also abstracts the OLT and ONU pairs as a switch in the form of a ``logical device``. Flows from the SDN
64 controller are stored, decomposed by the core and sent as specific instructions to the correct adapter(s).
65 - ``OpenFlow Agent``. The `ofAgent <https://github.com/opencord/ofagent-go>`_ as it is also known is responsible
66 of establishing the connection between the SDN controller and VOLTHA core. It is the glue between the VOLTHA data
67 model and the SDN controller, converting events coming from VOLTHA and instructions coming from ONOS
68 between OpenFlow and gRPC calls. It's completely stateless.
69 - ``OLT adapter``. The OLT adapter is the key component for importing an OLT of any model into VOLTHA. The main
70 purpose of this component is to interact with the physical OLT, receive it's information, events and status and
71 report them to the core, while at the same time receive requests from the core and issue them to the device.
72 The olt adapter also abstracts the technology of the OLTs, e.g GPON, XGS-PON, EPON.
73 The interface to the core is standardized in the `voltha-protos <https://github.com/opencord/voltha-protos>`_
74 and must be common for any adapter by any OLT vendor.
75 The southbound interface towards the OLT and its software can be proprietary as it's not seen by upper layers
76 of the system. An opensource implementation exists in the form of the `open-olt-adapter <https://github.com/opencord/voltha-openolt-adapter>`_) which uses
77 gRPC and the `openolt.proto <https://github.com/opencord/voltha-protos/blob/master/protos/voltha_protos/openolt.proto>`_
78 API as its means of communication to the ``open-olt-agent``. Closed source adapter
79 that use different SB protocols to the device, such as NETCONF, have been have been proven to work with VOLTHA
80 with no changes required to the system.
81 - ``ONU Adapter``. The ONU adapter is responsible for all the interactions and commands towards the ONU via OMCI,
82 such as discovery, MIB upload, ME configuration, T-CONT and GEM port configuration and so on.
83 The existing open source implementation `voltha-openonu-adapter-go <https://github.com/opencord/voltha-openonu-adapter-go>`_)
84 includes a virtualized openOMCI stack, fully compliant withe `G.988 spec <https://www.itu.int/rec/T-REC-G.988/en>`_
85 stack. Any openOMCI compliant ONU can thus be connected to VOLTHA with no additional effort.
86 For other technologies (e.g. EPON) or other Vendors other onu adapters that adhere to the
87 `voltha-protos <https://github.com/opencord/voltha-protos>`_ can be brought in.
88
89A VOLTHA stack is intended to be deployed for 1 up to a handful of OLTs with a total of 1024 subscribers connected.
90For multiple OLT scenarios many VOLTHA stacks can be connected to the same infrastructure, thus sharing storage,
91message bus and SDN controller.
92
93Device Management Interface
94----------------------------
95
96The `Device Management Interface <https://github.com/opencord/device-management-interface>`_
97is a protobuf Open API to allow an Operator OSS/BBS to manage aspects of the OLTs that are not under the control
98and pertinence of VOLTHA, for example software upgrade or component inventory.
99In a VOLTHA deployment one can (optionally) deploy a component implementing the Device Management Interface.
100The component of the architecture that implements the DMI interface can live in different places:
101
102 - on hardware, in which case it's a process running on the pyhsical OLT leveraging platfrom APIs (e.g. ONLP)
103 to report information.
104 - in the same kubernetes cluster as VOLTHA and the VOLTHA infrastructure, possibly leveraging
105 the same Kafka Bus for events as well. In this case is will leverage some form of protocol (e.g. NETCONF)
106 to communicate to the physical OLT
107
108An exemplar implementation of the DMI with option 1 deployment can be seen on
109`BBSIM <https://github.com/opencord/bbsim/blob/master/docs/source/DMI_Server_README.md>`_
110