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 | |
| 8 | In SEBA a workflow is defined as the set of operations that control the lifecycle |
| 9 | of a subscriber, authentication logic, customer tag management etc... Such workflow is operator specific. |
| 10 | |
| 11 | A full description of the workflows can be `found here <https://drive.google.com/drive/folders/1MfxwoDSvAR_rgFHt6n9Sai7IuiJPrHxF>`_. |
| 12 | |
| 13 | A big part of the workflow in SEBA is defined within NEM (Network Edge Mediator). |
| 14 | Given that NEM is not available in a plain VOLTHA deployment the definition |
| 15 | of workflow is a subset of the SEBA one, and comprises: |
| 16 | |
| 17 | - Customer tags allocation |
| 18 | - Technology profile |
| 19 | - Bandwidth profile |
| 20 | - Flow management (EAPOL/DHCP/Data path) |
| 21 | - Group management |
| 22 | |
| 23 | The `workflows` are often referred to as `use-cases` and the two words are interchangeable |
| 24 | in the VOLTHA environment. |
| 25 | |
| 26 | To deploy a specific workflow through ``kind-voltha`` please visit :ref:`quickstart`. |
| 27 | |
| 28 | How is the workflow defined in VOLTHA? |
| 29 | ---------------------------------------- |
| 30 | |
| 31 | Customer tag allocation |
| 32 | *********************** |
| 33 | |
| 34 | The vlan tags for a particular subscriber are defined in the ``sadis`` configuration. |
| 35 | `Sadis <https://github.com/opencord/sadis>`_ stands for `Subscriber and Device Information Service` |
| 36 | and is the ONOS application responsible to store and distribute Subscriber information. |
| 37 | |
| 38 | Information on different ``sadis`` configurations can be found here: |
| 39 | https://docs.google.com/document/d/1JLQ51CZg4jsXsBQcrJn-fc2kVvXH6lw0PYoyIclwmBs |
| 40 | |
| 41 | Technology profile |
| 42 | ****************** |
| 43 | |
| 44 | Technology profiles describes technology specific attributes required to implement |
| 45 | Subscriber Services on an OpenFlow managed Logical Switch overlaid upon an OLT |
| 46 | or other technology specific platform. |
| 47 | |
| 48 | More on Technology profiles here: |
| 49 | https://wiki.opencord.org/display/CORD/Technology+Profiles#TechnologyProfiles-IntroductiontoTechnologyProfiles |
| 50 | |
| 51 | Technology profiles in VOLTHA are stored in ETCD. If you want to load a custom |
| 52 | Technology profile in your stack you can do so by: |
| 53 | |
| 54 | .. code:: bash |
| 55 | |
| 56 | ETCD_POD=$(kubectl get pods | grep etcd | awk 'NR==1{print \$1}') |
| 57 | kubectl cp <my-tech-profile>.json $ETCD_POD:/tmp/tp.json |
| 58 | kubectl exec -it $ETCD_POD -- /bin/sh -c 'cat /tmp/tp.json | ETCDCTL_API=3 etcdctl put service/voltha/technology_profiles/XGS-PON/64' |
| 59 | |
| 60 | *Note that `XGS-PON` represents the technology of your OLT device and `64` is |
| 61 | the default id of the technology profile. If you want to use a technology profile |
| 62 | that is not the default for a particular subscriber that needs to be configured |
| 63 | in `sadis`.* |
| 64 | |
| 65 | Bandwidth profile |
| 66 | ***************** |
| 67 | |
| 68 | Bandwidth profiles control the allocation Bandwidth for a particular subscriber. |
| 69 | They are defined in the `sadis`. |
| 70 | An example: |
| 71 | |
| 72 | .. code-block:: json |
| 73 | |
| 74 | { |
| 75 | "id" : "Default", |
| 76 | "cir" : 1000000, |
| 77 | "cbs" : 1001, |
| 78 | "eir" : 1002, |
| 79 | "ebs" : 1003, |
| 80 | "air" : 1004 |
| 81 | } |
| 82 | |
| 83 | Each bandwidth profile is then translated into an OpenFlow Meter for configuration on the OLT. |
| 84 | |
| 85 | Flow management |
| 86 | *************** |
| 87 | |
| 88 | Flows are managed in ONOS by the `olt` application. Through the configuration of |
| 89 | this application you can define whether your setup will create: |
| 90 | |
| 91 | - An `EAPOL` trap flow |
| 92 | - A `DHCP` trap flow |
| 93 | - An `IGMP` trap flow |
| 94 | |
| 95 | in addition to the default data plane flows. |
| 96 | |
| 97 | Group management |
| 98 | **************** |
| 99 | |
| 100 | Groups are managed in ONOS by the `mcast` application. Through the configuration of |
| 101 | this application you can achieve multicast for services such as IpTV. |