blob: 61407206278eb2b0e216c8e840083df4b9c01a4d [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 Campanellac18d1182021-09-10 12:01:38 +020023To deploy a specific workflow follow the steps under `deploying-a-different-workflow` in the `voltha-helm-charts
24README <../voltha-helm-charts/README.md>`_.
Matteo Scandoloef5d6f42020-07-27 16:46:38 -070025
Andrea Campanella077cd5e2021-04-16 11:12:41 +020026A workflow in VOLTHA entails different elements: Customer tag allocation, Technology profile, Bandwidth profile,
27Flow and Group Management
Matteo Scandoloef5d6f42020-07-27 16:46:38 -070028
29Customer tag allocation
Andrea Campanella077cd5e2021-04-16 11:12:41 +020030-----------------------
Matteo Scandoloef5d6f42020-07-27 16:46:38 -070031
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
Andrea Campanella077cd5e2021-04-16 11:12:41 +020040------------------
Matteo Scandoloef5d6f42020-07-27 16:46:38 -070041
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
Andrea Campanellac18d1182021-09-10 12:01:38 +020046More information on Technology profiles can be found here:
Joey Armstrongb9a172d2023-01-06 11:05:13 -050047`2018/03/22 VOLTHA TST on Technology profile <https://www.youtube.com/watch?v=L0JBJ3R1Mag&feature=youtu.be>`_
Andrea Campanellac18d1182021-09-10 12:01:38 +020048`VOLTHA technical notes on Technology profile <https://wiki-archive.opencord.org/attachments/4981667/4981671.docx>`_
49`VOLTHA Implementation of Technology profiles <https://wiki-archive.opencord.org/attachments/4981667/4981670.docx>`_
50`Technology profile instance example <https://wiki-archive.opencord.org/Technology-Profile-Instance_4982088.html>`_
Matteo Scandoloef5d6f42020-07-27 16:46:38 -070051
52Technology profiles in VOLTHA are stored in ETCD. If you want to load a custom
53Technology profile in your stack you can do so by:
54
55.. code:: bash
56
57 ETCD_POD=$(kubectl get pods | grep etcd | awk 'NR==1{print \$1}')
58 kubectl cp <my-tech-profile>.json $ETCD_POD:/tmp/tp.json
59 kubectl exec -it $ETCD_POD -- /bin/sh -c 'cat /tmp/tp.json | ETCDCTL_API=3 etcdctl put service/voltha/technology_profiles/XGS-PON/64'
60
61*Note that `XGS-PON` represents the technology of your OLT device and `64` is
62the default id of the technology profile. If you want to use a technology profile
63that is not the default for a particular subscriber that needs to be configured
64in `sadis`.*
65
66Bandwidth profile
Andrea Campanella077cd5e2021-04-16 11:12:41 +020067-----------------
Matteo Scandoloef5d6f42020-07-27 16:46:38 -070068
69Bandwidth profiles control the allocation Bandwidth for a particular subscriber.
Andrea Campanella077cd5e2021-04-16 11:12:41 +020070They are defined in the `sadis` application.
71VOLTHA supports both the MEF and IETF definition of Bandwidth Profile.
72More information on the different definitions can be found on the `MEF wiki <https://wiki.mef.net/display/CESG/Bandwidth+Profile>`_.
73
74MEF:
Matteo Scandoloef5d6f42020-07-27 16:46:38 -070075
76.. code-block:: json
77
78 {
79 "id" : "Default",
80 "cir" : 1000000,
81 "cbs" : 1001,
82 "eir" : 1002,
83 "ebs" : 1003,
84 "air" : 1004
85 }
86
Andrea Campanella077cd5e2021-04-16 11:12:41 +020087IETF:
88
89.. code-block:: json
90
91 {
92 "id" : "Default",
93 "pir": 1168192,
94 "pbs": 0,
95 "cir": 0,
96 "cbs": 0,
97 "gir": 0
98 }
99
Matteo Scandoloef5d6f42020-07-27 16:46:38 -0700100Each bandwidth profile is then translated into an OpenFlow Meter for configuration on the OLT.
101
Andrea Campanella077cd5e2021-04-16 11:12:41 +0200102Each OpenFlow Meter is then translated to a different TCONT type in the `openolt-adapter`.
103VOLTHA supports all 5 TCONT types.
104
105The translation of Bandwidth profile parameters to TCONT types happens as follows:
106
107- | `Type-1`: If CIR > 0, CIR = PIR, additional_bw_eligibility = none --> set guaranteed_bw = maximum_bw = CBR_RT_BW
108 | (or CBR_NRT_BW) = CIR and alloc_type=none. (alloc_type is inferred from the other parameters)
109- | `Type-2`: If CIR = 0, GIR or AIR > 0, GIR or AIR = PIR, additional_bw_eligibility = none --> set guaranteed_bw =
110 | maximum_bw = AIR, CBR_RT_BW = 0 and CBR_NRT_BW = 0 and alloc_type = NSR (alloc_type is set to NSR by default)
111- | `Type-3`: If CIR = 0, GIR or AIR > 0, PIR > GIR or AIR, additional_bw_eligibility = non_assured -->
112 | guaranteed_bw = AIR, maximum_bw = PIR, CBR_RT_BW = 0 and CBR_NRT_BW = 0 and alloc_type = NSR and send
113 | these parameters to BAL. (alloc_type is set to NSR by default)
114- | `Type-4`: if CIR = 0, GIR or AIR = 0, PIR > 0, additional_bw_eligibility = best_effort --> set
115 | guaranteed_bw = 0, maximum_bw = PIR, CBR_RT_BW = 0 and CBR_NRT_BW = 0 and alloc_type = NSR and send
116 | (alloc_type is set to NSR by default)
117- | `Type-5`: if CIR > 0, PIR >= CIR + GIR or AIR, additional_bw_eligibility = non_assured or
118 | best_effort --> set guaranteed_bw = CIR+AIR, maximum_bw = PIR, CBR_RT_BW = 0 (or CBR_NRT_BW) = CIR
119 | and alloc_type = NSR. (alloc_type is set to NSR by default)
120
121Further implementation details can be found in `this document <https://docs.google.com/document/d/1HipmsHD5LEQlOc-Y2tYV7DHD1fn7-_1lehBgp79sRwU/edit#>`_.
122
Matteo Scandoloef5d6f42020-07-27 16:46:38 -0700123Flow management
Andrea Campanella077cd5e2021-04-16 11:12:41 +0200124---------------
Matteo Scandoloef5d6f42020-07-27 16:46:38 -0700125
126Flows are managed in ONOS by the `olt` application. Through the configuration of
127this application you can define whether your setup will create:
128
129- An `EAPOL` trap flow
130- A `DHCP` trap flow
131- An `IGMP` trap flow
132
133in addition to the default data plane flows.
134
135Group management
Andrea Campanella077cd5e2021-04-16 11:12:41 +0200136----------------
Matteo Scandoloef5d6f42020-07-27 16:46:38 -0700137
138Groups are managed in ONOS by the `mcast` application. Through the configuration of
139this application you can achieve multicast for services such as IpTV.