blob: dfe94976a520449be8440447f7be03d361a31989 [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 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
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
Andrea Campanella077cd5e2021-04-16 11:12:41 +020064-----------------
Matteo Scandoloef5d6f42020-07-27 16:46:38 -070065
66Bandwidth profiles control the allocation Bandwidth for a particular subscriber.
Andrea Campanella077cd5e2021-04-16 11:12:41 +020067They are defined in the `sadis` application.
68VOLTHA supports both the MEF and IETF definition of Bandwidth Profile.
69More information on the different definitions can be found on the `MEF wiki <https://wiki.mef.net/display/CESG/Bandwidth+Profile>`_.
70
71MEF:
Matteo Scandoloef5d6f42020-07-27 16:46:38 -070072
73.. code-block:: json
74
75 {
76 "id" : "Default",
77 "cir" : 1000000,
78 "cbs" : 1001,
79 "eir" : 1002,
80 "ebs" : 1003,
81 "air" : 1004
82 }
83
Andrea Campanella077cd5e2021-04-16 11:12:41 +020084IETF:
85
86.. code-block:: json
87
88 {
89 "id" : "Default",
90 "pir": 1168192,
91 "pbs": 0,
92 "cir": 0,
93 "cbs": 0,
94 "gir": 0
95 }
96
Matteo Scandoloef5d6f42020-07-27 16:46:38 -070097Each bandwidth profile is then translated into an OpenFlow Meter for configuration on the OLT.
98
Andrea Campanella077cd5e2021-04-16 11:12:41 +020099Each OpenFlow Meter is then translated to a different TCONT type in the `openolt-adapter`.
100VOLTHA supports all 5 TCONT types.
101
102The translation of Bandwidth profile parameters to TCONT types happens as follows:
103
104- | `Type-1`: If CIR > 0, CIR = PIR, additional_bw_eligibility = none --> set guaranteed_bw = maximum_bw = CBR_RT_BW
105 | (or CBR_NRT_BW) = CIR and alloc_type=none. (alloc_type is inferred from the other parameters)
106- | `Type-2`: If CIR = 0, GIR or AIR > 0, GIR or AIR = PIR, additional_bw_eligibility = none --> set guaranteed_bw =
107 | maximum_bw = AIR, CBR_RT_BW = 0 and CBR_NRT_BW = 0 and alloc_type = NSR (alloc_type is set to NSR by default)
108- | `Type-3`: If CIR = 0, GIR or AIR > 0, PIR > GIR or AIR, additional_bw_eligibility = non_assured -->
109 | guaranteed_bw = AIR, maximum_bw = PIR, CBR_RT_BW = 0 and CBR_NRT_BW = 0 and alloc_type = NSR and send
110 | these parameters to BAL. (alloc_type is set to NSR by default)
111- | `Type-4`: if CIR = 0, GIR or AIR = 0, PIR > 0, additional_bw_eligibility = best_effort --> set
112 | guaranteed_bw = 0, maximum_bw = PIR, CBR_RT_BW = 0 and CBR_NRT_BW = 0 and alloc_type = NSR and send
113 | (alloc_type is set to NSR by default)
114- | `Type-5`: if CIR > 0, PIR >= CIR + GIR or AIR, additional_bw_eligibility = non_assured or
115 | best_effort --> set guaranteed_bw = CIR+AIR, maximum_bw = PIR, CBR_RT_BW = 0 (or CBR_NRT_BW) = CIR
116 | and alloc_type = NSR. (alloc_type is set to NSR by default)
117
118Further implementation details can be found in `this document <https://docs.google.com/document/d/1HipmsHD5LEQlOc-Y2tYV7DHD1fn7-_1lehBgp79sRwU/edit#>`_.
119
Matteo Scandoloef5d6f42020-07-27 16:46:38 -0700120Flow management
Andrea Campanella077cd5e2021-04-16 11:12:41 +0200121---------------
Matteo Scandoloef5d6f42020-07-27 16:46:38 -0700122
123Flows are managed in ONOS by the `olt` application. Through the configuration of
124this application you can define whether your setup will create:
125
126- An `EAPOL` trap flow
127- A `DHCP` trap flow
128- An `IGMP` trap flow
129
130in addition to the default data plane flows.
131
132Group management
Andrea Campanella077cd5e2021-04-16 11:12:41 +0200133----------------
Matteo Scandoloef5d6f42020-07-27 16:46:38 -0700134
135Groups are managed in ONOS by the `mcast` application. Through the configuration of
136this application you can achieve multicast for services such as IpTV.