blob: fb550e20d4ad1308201f397afdae15ceae7c7b65 [file] [log] [blame]
Matteo Scandoloef5d6f42020-07-27 16:46:38 -07001.. _workflows:
2
3Operator workflows
4==================
5
6``Workflow`` is a term that spilled from the SEBA Reference Design (RD) into VOLTHA.
7
Andrea Campanella882cfcc2021-02-04 10:53:57 +01008In SEBA a workflow is a collection of subscriber management items like identification, location,
9and bandwidth profile. In addition each workflows maps to a service type which translates to a technology profile,
10and an operator desired flow of operations (i.e state-machine).
11The workflow is implemented by a selection of ONOS apps, XOS services (in SEBA)
12and a set of configurations (sadis, etcd, netcfg). Those apps paired with the configuration specified by the
13workflow (e.g. need EAPOL) in turn create low level flows, groups, meters, schedulers, queues etc.
14A workflow is then triggered by a particular set of APIs, for example the request to add a subscriber.
Matteo Scandoloef5d6f42020-07-27 16:46:38 -070015
Andrea Campanella882cfcc2021-02-04 10:53:57 +010016A full description of the different operator's workflows can be
17`found here <https://drive.google.com/drive/folders/1MfxwoDSvAR_rgFHt6n9Sai7IuiJPrHxF>`_.
Matteo Scandoloef5d6f42020-07-27 16:46:38 -070018
19A big part of the workflow in SEBA is defined within NEM (Network Edge Mediator).
Andrea Campanella882cfcc2021-02-04 10:53:57 +010020Given that NEM is not available in a plain VOLTHA deployment the user has to ensure proper config in the right places,
21and then triggering of api's themselves.
Matteo Scandoloef5d6f42020-07-27 16:46:38 -070022
Andrea Campanella882cfcc2021-02-04 10:53:57 +010023To deploy a specific workflow follow the steps in the voltha-helm-charts
24`README <./../voltha-helm-charts/README.md#deploying-a-different-workflow>`_.
Matteo Scandoloef5d6f42020-07-27 16:46:38 -070025
Andrea Campanella882cfcc2021-02-04 10:53:57 +010026What does the workflow entail in VOLTHA?
Matteo Scandoloef5d6f42020-07-27 16:46:38 -070027----------------------------------------
28
29Customer tag allocation
30***********************
31
32The vlan tags for a particular subscriber are defined in the ``sadis`` configuration.
33`Sadis <https://github.com/opencord/sadis>`_ stands for `Subscriber and Device Information Service`
34and is the ONOS application responsible to store and distribute Subscriber information.
35
36Information on different ``sadis`` configurations can be found here:
37https://docs.google.com/document/d/1JLQ51CZg4jsXsBQcrJn-fc2kVvXH6lw0PYoyIclwmBs
38
39Technology profile
40******************
41
42Technology profiles describes technology specific attributes required to implement
43Subscriber Services on an OpenFlow managed Logical Switch overlaid upon an OLT
44or other technology specific platform.
45
46More on Technology profiles here:
47https://wiki.opencord.org/display/CORD/Technology+Profiles#TechnologyProfiles-IntroductiontoTechnologyProfiles
48
49Technology profiles in VOLTHA are stored in ETCD. If you want to load a custom
50Technology profile in your stack you can do so by:
51
52.. code:: bash
53
54 ETCD_POD=$(kubectl get pods | grep etcd | awk 'NR==1{print \$1}')
55 kubectl cp <my-tech-profile>.json $ETCD_POD:/tmp/tp.json
56 kubectl exec -it $ETCD_POD -- /bin/sh -c 'cat /tmp/tp.json | ETCDCTL_API=3 etcdctl put service/voltha/technology_profiles/XGS-PON/64'
57
58*Note that `XGS-PON` represents the technology of your OLT device and `64` is
59the default id of the technology profile. If you want to use a technology profile
60that is not the default for a particular subscriber that needs to be configured
61in `sadis`.*
62
63Bandwidth profile
64*****************
65
66Bandwidth profiles control the allocation Bandwidth for a particular subscriber.
67They are defined in the `sadis`.
68An example:
69
70.. code-block:: json
71
72 {
73 "id" : "Default",
74 "cir" : 1000000,
75 "cbs" : 1001,
76 "eir" : 1002,
77 "ebs" : 1003,
78 "air" : 1004
79 }
80
81Each bandwidth profile is then translated into an OpenFlow Meter for configuration on the OLT.
82
83Flow management
84***************
85
86Flows are managed in ONOS by the `olt` application. Through the configuration of
87this application you can define whether your setup will create:
88
89- An `EAPOL` trap flow
90- A `DHCP` trap flow
91- An `IGMP` trap flow
92
93in addition to the default data plane flows.
94
95Group management
96****************
97
98Groups are managed in ONOS by the `mcast` application. Through the configuration of
99this application you can achieve multicast for services such as IpTV.