Matteo Scandolo | ef5d6f4 | 2020-07-27 16:46:38 -0700 | [diff] [blame] | 1 | .. _workflows: |
| 2 | |
| 3 | Operator workflows |
| 4 | ================== |
| 5 | |
| 6 | ``Workflow`` is a term that spilled from the SEBA Reference Design (RD) into VOLTHA. |
| 7 | |
Andrea Campanella | 882cfcc | 2021-02-04 10:53:57 +0100 | [diff] [blame] | 8 | In SEBA a workflow is a collection of subscriber management items like identification, location, |
| 9 | and bandwidth profile. In addition each workflows maps to a service type which translates to a technology profile, |
| 10 | and an operator desired flow of operations (i.e state-machine). |
| 11 | The workflow is implemented by a selection of ONOS apps, XOS services (in SEBA) |
| 12 | and a set of configurations (sadis, etcd, netcfg). Those apps paired with the configuration specified by the |
| 13 | workflow (e.g. need EAPOL) in turn create low level flows, groups, meters, schedulers, queues etc. |
| 14 | A workflow is then triggered by a particular set of APIs, for example the request to add a subscriber. |
Matteo Scandolo | ef5d6f4 | 2020-07-27 16:46:38 -0700 | [diff] [blame] | 15 | |
Andrea Campanella | 882cfcc | 2021-02-04 10:53:57 +0100 | [diff] [blame] | 16 | A full description of the different operator's workflows can be |
| 17 | `found here <https://drive.google.com/drive/folders/1MfxwoDSvAR_rgFHt6n9Sai7IuiJPrHxF>`_. |
Matteo Scandolo | ef5d6f4 | 2020-07-27 16:46:38 -0700 | [diff] [blame] | 18 | |
| 19 | A big part of the workflow in SEBA is defined within NEM (Network Edge Mediator). |
Andrea Campanella | 882cfcc | 2021-02-04 10:53:57 +0100 | [diff] [blame] | 20 | Given that NEM is not available in a plain VOLTHA deployment the user has to ensure proper config in the right places, |
| 21 | and then triggering of api's themselves. |
Matteo Scandolo | ef5d6f4 | 2020-07-27 16:46:38 -0700 | [diff] [blame] | 22 | |
Andrea Campanella | 882cfcc | 2021-02-04 10:53:57 +0100 | [diff] [blame] | 23 | To deploy a specific workflow follow the steps in the voltha-helm-charts |
| 24 | `README <./../voltha-helm-charts/README.md#deploying-a-different-workflow>`_. |
Matteo Scandolo | ef5d6f4 | 2020-07-27 16:46:38 -0700 | [diff] [blame] | 25 | |
Andrea Campanella | 882cfcc | 2021-02-04 10:53:57 +0100 | [diff] [blame] | 26 | What does the workflow entail in VOLTHA? |
Matteo Scandolo | ef5d6f4 | 2020-07-27 16:46:38 -0700 | [diff] [blame] | 27 | ---------------------------------------- |
| 28 | |
| 29 | Customer tag allocation |
| 30 | *********************** |
| 31 | |
| 32 | The 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` |
| 34 | and is the ONOS application responsible to store and distribute Subscriber information. |
| 35 | |
| 36 | Information on different ``sadis`` configurations can be found here: |
| 37 | https://docs.google.com/document/d/1JLQ51CZg4jsXsBQcrJn-fc2kVvXH6lw0PYoyIclwmBs |
| 38 | |
| 39 | Technology profile |
| 40 | ****************** |
| 41 | |
| 42 | Technology profiles describes technology specific attributes required to implement |
| 43 | Subscriber Services on an OpenFlow managed Logical Switch overlaid upon an OLT |
| 44 | or other technology specific platform. |
| 45 | |
| 46 | More on Technology profiles here: |
| 47 | https://wiki.opencord.org/display/CORD/Technology+Profiles#TechnologyProfiles-IntroductiontoTechnologyProfiles |
| 48 | |
| 49 | Technology profiles in VOLTHA are stored in ETCD. If you want to load a custom |
| 50 | Technology 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 |
| 59 | the default id of the technology profile. If you want to use a technology profile |
| 60 | that is not the default for a particular subscriber that needs to be configured |
| 61 | in `sadis`.* |
| 62 | |
| 63 | Bandwidth profile |
| 64 | ***************** |
| 65 | |
| 66 | Bandwidth profiles control the allocation Bandwidth for a particular subscriber. |
| 67 | They are defined in the `sadis`. |
| 68 | An 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 | |
| 81 | Each bandwidth profile is then translated into an OpenFlow Meter for configuration on the OLT. |
| 82 | |
| 83 | Flow management |
| 84 | *************** |
| 85 | |
| 86 | Flows are managed in ONOS by the `olt` application. Through the configuration of |
| 87 | this 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 | |
| 93 | in addition to the default data plane flows. |
| 94 | |
| 95 | Group management |
| 96 | **************** |
| 97 | |
| 98 | Groups are managed in ONOS by the `mcast` application. Through the configuration of |
| 99 | this application you can achieve multicast for services such as IpTV. |