[VOL-1084] Fixing voltha documentation linting
Change-Id: Ibd7ef78910b6698c2c70d7c1f3ddb3041aabce30
diff --git a/docs/manuals/user/README.md b/docs/manuals/user/README.md
index 0fa2e19..d763dd2 100644
--- a/docs/manuals/user/README.md
+++ b/docs/manuals/user/README.md
@@ -28,4 +28,3 @@
## How can you help?
Contributions, small and large, are welcome. Minor contributions and bug fixes are always welcome in form of pull requests. For larger work, the best is to check in with the existing developers to see where help is most needed and to make sure your solution is compatible with the general philosophy of Voltha.
-
diff --git a/docs/manuals/user/SUMMARY.md b/docs/manuals/user/SUMMARY.md
index 383d771..7e81506 100644
--- a/docs/manuals/user/SUMMARY.md
+++ b/docs/manuals/user/SUMMARY.md
@@ -1,47 +1,45 @@
# Summary
-This is the TOC file used by the gitbook generator.
-To generate and serve static content, run:
+This is the TOC file used by the gitbook generator. To generate and serve static content, run:
- ```
- gitbook serve
- ```
+```shell
+gitbook serve
+```
* [Introduction](README.md)
* [Overview of Voltha](labtests/README.md)
* [Recommended Lab Test Scenarios](labtests/README.md)
- * [Requirements](labtests/requirements.md)
- * [Preparation](labtests/preparations.md)
- * [Voltha Bringup Tests](labtests/V00_voltha.md)
- * [V1 - Deploy Voltha and Verify its Vital Signs](labtests/V01_voltha_bringup_deploy.md)
- * [V2 - Connect to Voltha with REST and Web Browser](labtests/V02_voltha_bringup_rest.md)
- * [V3 - Connect to Voltha via its CLI](labtests/V03_voltha_bringup_cli.md)
- * [V4 - View Voltha Async Events with Kafkacat](labtests/V04_voltha_bringup_async.md)
- * [PONSIM OLT Tests](labtests/S00_ponsim_tests.md)
- * [S1 - Preprovision and Activate OLT](labtests/S01_ponsim_tests_launch_and_activate.md)
- * [S2 - Launch ONOS](labtests/S02_ponsim_tests_onos.md)
- * [S3 - Verify RG Authentication Scenario (EAPOL)](labtests/S03_ponsim_eapol_auth.md)
- * [S4 - Verify DHCP Lookup](labtests/S04_ponsim_verify_dhcp.md)
- * [S5 - Verify Unicast Access](labtests/S05_ponsim_tests_unicast.md)
- * [S6 - Verify IGMP Handling](labtests/S06_ponsim_tests_multicast.md)
- * [Tibit OLT Tests](labtests/T00_tibit_olt_tests.md)
- * [T1 - Preprovision and Activate OLT](labtests/T01_tibit_olt_tests_activate_olt.md)
- * [T2 - Launch ONOS](labtests/T02_tibit_olt_tests_onos.md)
- * [T3 - Verify EAPOL RG Authentication Scenario](labtests/T03_tibit_olt_eapol_auth.md)
- * [T4 - Verify DHCP Lookup](labtests/T04_tibit_verify_dhcp.md)
- * [T5 - Verify Unicast Access](labtests/T05_tibit_tests_unicast.md)
- * [T6 - Verify IGMP Handling](labtests/T06_tibit_tests_multicast.md)
- * [Maple OLT Tests](labtests/M00_maple_olt_tests.md)
- * [M1 - Preprovision and Activate OLT](labtests/M01_maple_olt_tests_activate_olt.md)
- * [M2 - Launch ONOS](labtests/M02_maple_olt_tests_onos.md)
- * [M3 - Verify EAPOL RG Authentication Scenario](labtests/M03_maple_olt_tests_eapol_auth.md)
- * [M4 - Verify DHCP Lookup](labtests/M04_maple_olt_tests_verify_dhcp.md)
- * [M5 - Verify Unicast Access](labtests/M05_maple_olt_tests_unicast.md)
- * [M6 - Verify IGMP Handling](labtests/M06_maple_olt_tests_multicast.md)
- * [Netconf Tests](labtests/N00_netconf.md)
+ * [Requirements](labtests/requirements.md)
+ * [Preparation](labtests/preparations.md)
+ * [Voltha Bringup Tests](labtests/V00_voltha.md)
+ * [V1 - Deploy Voltha and Verify its Vital Signs](labtests/V01_voltha_bringup_deploy.md)
+ * [V2 - Connect to Voltha with REST and Web Browser](labtests/V02_voltha_bringup_rest.md)
+ * [V3 - Connect to Voltha via its CLI](labtests/V03_voltha_bringup_cli.md)
+ * [V4 - View Voltha Async Events with Kafkacat](labtests/V04_voltha_bringup_async.md)
+ * [PONSIM OLT Tests](labtests/S00_ponsim_tests.md)
+ * [S1 - Preprovision and Activate OLT](labtests/S01_ponsim_tests_launch_and_activate.md)
+ * [S2 - Launch ONOS](labtests/S02_ponsim_tests_onos.md)
+ * [S3 - Verify RG Authentication Scenario (EAPOL)](labtests/S03_ponsim_eapol_auth.md)
+ * [S4 - Verify DHCP Lookup](labtests/S04_ponsim_verify_dhcp.md)
+ * [S5 - Verify Unicast Access](labtests/S05_ponsim_tests_unicast.md)
+ * [S6 - Verify IGMP Handling](labtests/S06_ponsim_tests_multicast.md)
+ * [Tibit OLT Tests](labtests/T00_tibit_olt_tests.md)
+ * [T1 - Preprovision and Activate OLT](labtests/T01_tibit_olt_tests_activate_olt.md)
+ * [T2 - Launch ONOS](labtests/T02_tibit_olt_tests_onos.md)
+ * [T3 - Verify EAPOL RG Authentication Scenario](labtests/T03_tibit_olt_eapol_auth.md)
+ * [T4 - Verify DHCP Lookup](labtests/T04_tibit_verify_dhcp.md)
+ * [T5 - Verify Unicast Access](labtests/T05_tibit_tests_unicast.md)
+ * [T6 - Verify IGMP Handling](labtests/T06_tibit_tests_multicast.md)
+ * [Maple OLT Tests](labtests/M00_maple_olt_tests.md)
+ * [M1 - Preprovision and Activate OLT](labtests/M01_maple_olt_tests_activate_olt.md)
+ * [M2 - Launch ONOS](labtests/M02_maple_olt_tests_onos.md)
+ * [M3 - Verify EAPOL RG Authentication Scenario](labtests/M03_maple_olt_tests_eapol_auth.md)
+ * [M4 - Verify DHCP Lookup](labtests/M04_maple_olt_tests_verify_dhcp.md)
+ * [M5 - Verify Unicast Access](labtests/M05_maple_olt_tests_unicast.md)
+ * [M6 - Verify IGMP Handling](labtests/M06_maple_olt_tests_multicast.md)
+ * [Netconf Tests](labtests/N00_netconf.md)
* [N1 - Deploy Netconf and Verify its Vital Signs](labtests/N01_netconf_bringup_deploy.md)
* [N2 - Connect to Netconf with a Netconf Browser](labtests/N02_netconf_client_connect.md)
* [N3 - Retrieve YANG Modules](labtests/N03_netconf_client_retrieve_YANG_modules.md)
* [N4 - Get VolthaInstance info](labtests/N04_netconf_client_get_volthainstance.md)
* [N5 - Get List of Adapters](labtests/N05_netconf_client_get_adapters.md)
-
diff --git a/docs/manuals/user/backup_restore/backup-restore.md b/docs/manuals/user/backup_restore/backup-restore.md
index 987e0d0..87fc2b2 100644
--- a/docs/manuals/user/backup_restore/backup-restore.md
+++ b/docs/manuals/user/backup_restore/backup-restore.md
@@ -1,4 +1,5 @@
-## Backup and Restore
+# Backup and Restore
+
The strategy for backup and restore for the entire Voltha cluster is
depicted in the diagram below.
@@ -8,7 +9,7 @@
For PoC-3, the strategy is to backup and restore Consul data manually.
-#### Backing Up Consul Data
+## Backing Up Consul Data
There are two sets of data that could be backup and restored from Consul:
@@ -22,21 +23,24 @@
The steps below show the basic backup and restore procedure. Consul provides
additional options, e.g. authentication, to use during these operations.
-##### Backup
+## Backup
-###### Prerequisites
+### Backup prerequisites
+
* Consul is running
-###### Steps
+#### Backup steps
* Get the IP and port number of one of the running consul node.
-
* Enter the voltha/tools container on one of the cluster node:
+
```angular2html
docker exec -it <containerid> bash
cd /home/tools
```
+
* Initiate the backup as a json file (consul_backup.json is just an example).
+
```angular2html
consul kv export -http-addr=http://<Consul_IP>:<Consul_PORT></Consul_PORT>
service/voltha > consul_backup.json
@@ -48,50 +52,53 @@
back_file will need to be uniquely identified for each backup,
preferably using a timestamp)
+## Restore
-##### Restore
+### Restore prerequisites
-###### Prerequisites
* The consul backup file exists and accesible from the voltha/tools container
-###### Steps
+#### Restore steps
Restoring a Consul backup implies that the current consul data needs to be
overwritten. This is typically a disaster recovery scenario.
-* Stop all the running voltha vcore instances as well as the consul
-instances. This should be performed from a docker swarm manager node.
+* Stop all the running voltha vcore instances as well as the consul instances. This should be performed from a docker swarm manager node.
+
```angular2html
docker service rm vcore_vcore
docker service rm consul_consul
```
+
* Start the consul service
```angular2html
docker stack deploy -c /cord/incubator/voltha/compose/docker-compose-consul-cluster.yml consul
```
+
* Ensure all consul agents are running. There should be 3/3 instances running
+
```angular2html
docker service ls consul_consul
```
* Get the IP and port number of one of the running consul node.
-
* Enter the voltha/tools container on one of the cluster machine:
+
```angular2html
docker exec -it <containerid> bash
cd /home/tools
```
-* Initiate the restore from a json file (consul_backup.json is just an
-example).
+
+* Initiate the restore from a json file (consul_backup.json is just an example).
+
```angular2html
consul kv import -http-addr=http://<Consul_IP>:<Consul_PORT></Consul_PORT> @consul_backup.json
```
* The backup data has been restored into Consul
+* Start the voltha instances. This should be performed from a docker swarm manager node.
-* Start the voltha instances. This should be performed from a docker swarm
-manager node.
```angular2html
docker stack deploy -c /cord/incubator/voltha/compose/docker-compose-voltha-swarm.yml vcore
```
diff --git a/docs/manuals/user/labtests/M00_maple_olt_tests.md b/docs/manuals/user/labtests/M00_maple_olt_tests.md
index aac09c9..c619280 100644
--- a/docs/manuals/user/labtests/M00_maple_olt_tests.md
+++ b/docs/manuals/user/labtests/M00_maple_olt_tests.md
@@ -1,11 +1,10 @@
# Maple OLT Tests
-These tests assume access to a Maple-based OLT PON system in the test
-POD.
+These tests assume access to a Maple-based OLT PON system in the test POD.
* [M1 - Preprovision and Activate OLT and ONU](M01_maple_olt_tests_activate_olt.md)
* [M2 - Launch ONOS](M02_maple_olt_tests_onos.md)
* [M3 - Verify EAPOL RG Authentication](M03_maple_olt_tests_eapol_auth.md)
* [M4 - Verify DHCP Lookup](M04_maple_olt_tests_verify_dhcp.md)
* [M5 - Verify Unicast Access](M05_maple_olt_tests_unicast.md)
-* [M6 - Verify IGMP Handling](M06_maple_olt_tests_multicast.md)
+* [M6 - Verify IGMP Handling](M06_maple_olt_tests_multicast.md)
diff --git a/docs/manuals/user/labtests/M01_maple_olt_tests_activate_olt.md b/docs/manuals/user/labtests/M01_maple_olt_tests_activate_olt.md
index 5e5ec71..7f84bfc 100644
--- a/docs/manuals/user/labtests/M01_maple_olt_tests_activate_olt.md
+++ b/docs/manuals/user/labtests/M01_maple_olt_tests_activate_olt.md
@@ -1,25 +1,24 @@
-## M1 - Preprovision and Activate OLT
+# M1 - Preprovision and activate OLT
-### Test Objective
+## Test Objective
* Purpose of this test is to verify a new OLT can be added and activated from VOLTHA
-* VOLTHA will connect with the OLT physical device and create a
- logical device with initial ports in its data store
+* VOLTHA will connect with the OLT physical device and create a logical device with initial ports in its data store
* VOLTHA will send Event notifications to ONOS and PON Manager for the newly added OLT
-### Test Configuration
+## Test Configuration
* The test setup is as shown in earlier sections
* Maple OLT should be reachable from VOLTHA on VLAN 4092
-#### Temporary Configuration
+## Temporary Configuration
* The following commands are temporary and will be removed when full
support in added to VOLTHA. The following commands add and verify
the VLAN 4092 interface to VOLTHA along with an IP address in the
subnet used to communicate with the Maple OLT.
-```
+```shell
docker exec -ti compose_voltha_1 bash
ip link add link eth1 name eth1.4092 type vlan id 4092
ip addr add 192.168.24.20/24 brd + dev eth1.4092
@@ -27,20 +26,18 @@
apt install -y iputils-ping
ping 192.168.24.10
exit
-
```
-
* Start the VOLTHA CLI
-**Step 1: If not yet running, launch the Voltha CLI:**
+## Step 1: If not yet running, launch the Voltha CLI
-```
+```shell
cd $VOLTHA_BASE
./cli/main.py -L
```
-```
+```shell
_ _ _ ___ _ ___
__ _____| | |_| |_ __ _ / __| | |_ _|
\ V / _ \ | _| ' \/ _` | | (__| |__ | |
@@ -49,14 +46,14 @@
(voltha)
```
-### Test Procedure
+## Test Procedure
* Issue CLI commands in the VOLTHA CLI to simulate an “Add-OLT device”
message coming from the PON Manager to VOLTHA
* Note: for the purposes of this document the OLT IP address is assumed
to be 192.168.24.10
-```
+```shell
preprovision_olt --device-type=maple_olt --ip-address=192.168.24.10
```
@@ -64,13 +61,13 @@
device in the device table. Executing the following command will
display known devices
-```
+```shell
devices
```
* The output should appear as follows
-```
+```shell
Devices:
+--------------+-----------+---------------+----------------+
| id | type | ipv4_address | admin_state |
@@ -81,25 +78,25 @@
* To activate the OLT, execute the following command
-```
+```shell
enable
```
+
* VOLTHA should initiate a connection and activation request to the Maple OLT
* VOLHA will create the logical OpenFlow device and ports and notify ONOS
* VOLTHA will send an OLT-Activated event notification to the PON Manager
* VOLTHA will automatically provision and activate a single ONU
-* Note: the automatic provisioning and activation of the single ONU is only
- temporary and will be replaced by ONU discovery and activation in a future
- release.
+* Note: the automatic provisioning and activation of the single ONU is only temporary and will be replaced by ONU discovery and activation in a future release.
* Verify the OLT and ONU status on device console with the following command
-```
+```shell
devices
```
+
* The output should appear similar to the following
-```
+```shell
Devices:
+--------------+--------------+------+--------------+------+---------------+-------------+-------------+----------------+----------------+-------------------------+--------------------------+
| id | type | root | parent_id | vlan | ipv4_address | admin_state | oper_status | connect_status | parent_port_no | proxy_address.device_id | proxy_address.channel_id |
@@ -116,36 +113,33 @@
forwarding rules is temporary and will be driven by flow rules in
a future release.
-Now that this OLT has provisioned all forwarding rules, it should continue
-to drop all traffic since ONOS is not running. We can verify this by starting
-the RG emulator and observing that EAPOL authentication does not succeed.
-To do this start our RG docker container.
+Now that this OLT has provisioned all forwarding rules, it should continue to drop all traffic since ONOS is not running. We can verify this by starting the RG emulator and observing that EAPOL authentication does not succeed. To do this start our RG docker container.
-```
+```shell
docker run --net=host --privileged --name RG -it voltha/tester bash
```
this should land you in a command prompt that looks like
-```
+```shell
root@8358ef5cad0e:/#
```
and at this prompt issue the following command
-```
+```shell
/sbin/wpa_supplicant -Dwired -ieno1 -c /etc/wpa_supplicant/wpa_supplicant.conf
```
this should hang with the following output. You will need to interrupt it with Ctrl-C.
-```
+```shell
Successfully initialized wpa_supplicant
eno1: Associated with 01:80:c2:00:00:03
WMM AC: Missing IEs
```
-### Pass/Fail Criteria
+## Pass/Fail Criteria
* OLT / ONUs status can be seen from Device Console
* Confirm OLT and ONUs have "oper_status" of ACTIVE
diff --git a/docs/manuals/user/labtests/M02_maple_olt_tests_onos.md b/docs/manuals/user/labtests/M02_maple_olt_tests_onos.md
index 35c215b..1a829de 100644
--- a/docs/manuals/user/labtests/M02_maple_olt_tests_onos.md
+++ b/docs/manuals/user/labtests/M02_maple_olt_tests_onos.md
@@ -1,37 +1,37 @@
-## M2 - Attach the Maple OLT to ONOS
+# M2 - Attach the Maple OLT to ONOS
-### Test Objective
+## Test Objective
Observe that ONOS has identified the OLT device and displays the correct number of ONU ports
-### Test Configuration
+## Test Configuration
* VOLTHA ensemble up and running.
* Maple configured with an OLT and one or more ONUs
-### Test Procedure
+## Test Procedure
First, start the onos container.
-```
+```shell
docker-compose -f compose/docker-compose-auth-test.yml up -d onos
```
this should output
-```
+```shell
Creating compose_onos_1
```
Make sure that ONOS is running
-```
+```shell
docker-compose -f compose/docker-compose-auth-test.yml ps
```
which shows
-```
+```shell
Name Command State Ports
------------------------------------------------------------------------------------------------------------------------------
compose_onos_1 ./bin/onos-service Up 0.0.0.0:6653->6653/tcp, 0.0.0.0:8101->8101/tcp, 0.0.0.0:8181->8181/tcp, 9876/tcp
@@ -39,14 +39,14 @@
Now, let's login to ONOS.
-```
+```shell
sudo apt install sshpass # may not be necessary
sshpass -p karaf ssh -o StrictHostKeyChecking=no -p 8101 karaf@localhost
```
this should land you at the ONOS prompt
-```
+```shell
Welcome to Open Network Operating System (ONOS)!
____ _ ______ ____
/ __ \/ |/ / __ \/ __/
@@ -68,25 +68,25 @@
Let's have a look at the devices that ONOS sees, to do this enter the following at the ONOS prompt.
-```
+```shell
devices
```
this will output the following
-```
+```shell
id=of:0000000000000001, available=true, role=MASTER, type=SWITCH, mfr=cord porject, hw=n/a, sw=logical device for Maple-based PON, serial=82126dceaa0b47f9ace655efcf7e97b4, driver=voltha, channelId=172.25.0.1:57746, managementAddress=172.25.0.1, name=of:0000000000000001, protocol=OF_13
```
next let's have a look at the ports that onos sees. Remember that ONOS sees the PON system as a logical device so ONU are represented as ports to ONOS. So let's see the ports in ONOS.
-```
+```shell
ports
```
which returns the following
-```
+```shell
id=of:0000000000000001, available=true, role=MASTER, type=SWITCH, mfr=cord porject, hw=n/a, sw=logical device for Maple-based PON, serial=82126dceaa0b47f9ace655efcf7e97b4, driver=voltha, channelId=172.25.0.1:57746, managementAddress=172.25.0.1, name=of:0000000000000001, protocol=OF_13
port=0, state=enabled, type=fiber, speed=0 , portName=nni, portMac=00:00:00:00:00:81
port=1025, state=enabled, type=fiber, speed=0 , portName=uni-1025, portMac=00:00:00:00:04:01
@@ -94,7 +94,7 @@
This correctly shows three ports. Yay!
-### Pass/Fail Criteria
+## Pass/Fail Criteria
* OLT observed in ONOS
* ONUs observed in ONOS as ports
diff --git a/docs/manuals/user/labtests/M03_maple_olt_tests_eapol_auth.md b/docs/manuals/user/labtests/M03_maple_olt_tests_eapol_auth.md
index a847a70..8959967 100644
--- a/docs/manuals/user/labtests/M03_maple_olt_tests_eapol_auth.md
+++ b/docs/manuals/user/labtests/M03_maple_olt_tests_eapol_auth.md
@@ -1,48 +1,48 @@
-## M3 - Verify EAPOL Remote Gateway Authentication
+# M3 - Verify EAPOL Remote Gateway Authentication
-### Test Objective
+## Test Objective
* Purpose of this test is to verify that 802.1X EAPOL messages are forwarded to the ONOS from VOLTHA
- * Correct Maple OLT and ONU PON environment
- * Logical device visible in VOLTHA CLI
+ * Correct Maple OLT and ONU PON environment
+ * Logical device visible in VOLTHA CLI
-### Test Configuration
+## Test Configuration
* VOLTHA ensemble running as per [deployment instructions](V01_voltha_bringup_deploy.md).
* Start the freeradius container
-```
+```shell
docker-compose -f compose/docker-compose-auth-test.yml up -d freeradius
```
* Maple OLT and ONUs registered as ACTIVE in VOLTHA
-### Test Procedure
+## Test Procedure
Now that this OLT is ACTIVE in VOLTHA, it should forward EAPOL
traffic. We can verify this by starting the RG emulator and observing
that EAPOL authentication does not succeed. To do this start our RG
docker container.
-```
+```shell
docker run --net=host --privileged --name RG -it voltha/tester bash
```
this should land you in a command prompt that looks like
-```
+```shell
root@8358ef5cad0e:/#
```
and at this prompt issue the following command
-```
+```shell
/sbin/wpa_supplicant -Dwired -ien01 -c /etc/wpa_supplicant/wpa_supplicant.conf
```
This should pass with the following output
-```
+```shell
Successfully initialized wpa_supplicant
ens9f1: Associated with 01:80:c2:00:00:03
WMM AC: Missing IEs
@@ -52,7 +52,6 @@
ens9f1: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
```
-
-### Pass/Fail Criteria
+## Pass/Fail Criteria
* EAPOL Authentication should pass
diff --git a/docs/manuals/user/labtests/M04_maple_olt_tests_verify_dhcp.md b/docs/manuals/user/labtests/M04_maple_olt_tests_verify_dhcp.md
index 28bcee1..368044d 100644
--- a/docs/manuals/user/labtests/M04_maple_olt_tests_verify_dhcp.md
+++ b/docs/manuals/user/labtests/M04_maple_olt_tests_verify_dhcp.md
@@ -1,42 +1,42 @@
-## M4 - Verify DHCP successfully obtains an IP address
+# M4 - Verify DHCP successfully obtains an IP address
-### Test Objective
+## Test Objective
* Purpose of this test is to verify that the Dynamic Host Configuration Protocol (DHCP)
- * Correct Maple OLT and ONU PON environment
- * Logical device visible in VOLTHA CLI
+ * Correct Maple OLT and ONU PON environment
+ * Logical device visible in VOLTHA CLI
-### Test Configuration
+## Test Configuration
* VOLTHA ensemble running as per [deployment instructions](V01_voltha_bringup_deploy.md).
* Note: The DHCP server is contained within ONOS.
* Maple OLT and ONUs registered as ACTIVE in VOLTHA
-### Test Procedure
+## Test Procedure
To start this procedure, execute the "ifconfig" command on the interface that will be getting assigned an IP address over DHCP and verify that IP address has not been assigned.
-```
+```shell
ifconfig eno1
```
Next, execute the following command to obtain an IP address from ONOS.
-```
+```shell
dhclient eno1
```
Note: When the dhclient command completes a common error message is displayed as follows. This mesage can safely be ignored.
-```
+```shell
dhclient: cannot move '/etc/*.conf' to '/etc/resolve.conf'
```
Then verify that an IP address was dynamically assigned to your interface
-```
+```shell
ifconfig eno1
```
-### Pass/Fail Criteria
+## Pass/Fail Criteria
* IP address assigned to interface
diff --git a/docs/manuals/user/labtests/M05_maple_olt_tests_unicast.md b/docs/manuals/user/labtests/M05_maple_olt_tests_unicast.md
index 8e214fa..01d37aa 100644
--- a/docs/manuals/user/labtests/M05_maple_olt_tests_unicast.md
+++ b/docs/manuals/user/labtests/M05_maple_olt_tests_unicast.md
@@ -1,33 +1,33 @@
-## M5 - Verify unicast traffic flow
+# M5 - Verify unicast traffic flow
-### Test Objective
+## Test Objective
* Purpose of this test is to verify that unicast traffic flows through the system
- * Correct Maple PON environment
- * Logical device visible in VOLTHA cli
+ * Correct Maple PON environment
+ * Logical device visible in VOLTHA cli
-### Test Configuration
+## Test Configuration
* VOLTHA ensemble running as per [deployment instructions](V01_voltha_bringup_deploy.md).
* Maple OLT and ONUs registered as ACTIVE in VOLTHA
-### Test Procedure
+## Test Procedure
Execute the following command from the RG side
-```
+```shell
ping -I eno1 1.2.3.4
```
Meanwhile tcpdump on the VOLTHA server.
-```
+```shell
sudo tcpdump -nei eno2
```
which will output
-```
+```shell
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pon1_0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:53:44.328260 06:0c:49:94:35:7e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 50: vlan 1025, p 0, ethertype 802.1Q, vlan 1025, p 0, ethertype ARP, Request who-has 1.2.3.4 tell 10.1.11.63, length 28
@@ -38,6 +38,6 @@
13:53:49.322517 06:0c:49:94:35:7e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 50: vlan 1025, p 0, ethertype 802.1Q, vlan 1025, p 0, ethertype ARP, Request who-has 1.2.3.4 tell 10.1.11.63, length 28
```
-### Pass/Fail Criteria
+## Pass/Fail Criteria
Ping completes successfully
diff --git a/docs/manuals/user/labtests/M06_maple_olt_tests_multicast.md b/docs/manuals/user/labtests/M06_maple_olt_tests_multicast.md
index 335ac5c..b396c7a 100644
--- a/docs/manuals/user/labtests/M06_maple_olt_tests_multicast.md
+++ b/docs/manuals/user/labtests/M06_maple_olt_tests_multicast.md
@@ -1,20 +1,20 @@
-## M6 - Test IGMP and multicast (Video) streams
+# M6 - Test IGMP and multicast (Video) streams
-### Test Objective
+## Test Objective
Verify that VOLTHA punts IGMP packets to ONOS and that ONOS provisions the right multicast rules
-### Test Configuration
+## Test Configuration
* VOLTHA ensemble up and running.
* Maple configured with an OLT with one or more ONUs
* An authenticated RG
-### Test Procedure
+## Test Procedure
At this point ONOS should show the following rules:
-```
+```shell
deviceId=of:0000000000000001, flowRuleCount=7
ADDED, bytes=0, packets=0, table=0, priority=10000, selector=[IN_PORT:128, ETH_TYPE:ipv4, IP_PROTO:2], treatment=[immediate=[OUTPUT:CONTROLLER]]
ADDED, bytes=0, packets=0, table=0, priority=1000, selector=[IN_PORT:128, ETH_TYPE:eapol], treatment=[immediate=[OUTPUT:CONTROLLER]]
@@ -29,13 +29,13 @@
So now let's send an IGMP packet from the RG up the ONU. To do this run the following in the RG container.
-```
+```shell
igmp.py -j -i eno1 -m 229.0.0.1
```
this will return
-```
+```shell
.
Sent 1 packets.
```
@@ -44,13 +44,13 @@
Let us now check the state in ONOS, starting with the group information. Run the following in the ONOS prompt.
-```
+```shell
groups
```
which returns
-```
+```shell
deviceId=of:0000000000000001, groupCount=1
id=0x1, state=ADDED, type=ALL, bytes=0, packets=0, appId=org.onosproject.cordmcast
id=0x1, bucket=1, bytes=0, packets=0, actions=[VLAN_POP:unknown, OUTPUT:128]
@@ -60,13 +60,13 @@
For a group to be useful a flow must point to this group. So let's check in ONOS whether a flow exists.
-```
+```shell
flows -s
```
and find a flow which looks like
-```
+```shell
ADDED, bytes=0, packets=0, table=0, priority=500, selector=[IN_PORT:0, ETH_TYPE:ipv4, VLAN_VID:140, IPV4_DST:229.0.0.1/32], treatment=[immediate=[GROUP:0x1]]
```
@@ -74,14 +74,14 @@
Now let's check whether we find this state in the logical device in VOLTHA. Let's run the following in the VOLTHA CLI.
-```
+```shell
logical_device
flows
```
which will return
-```
+```shell
Logical Device 1 (type: n/a)
Flows (10):
+----------+----------+-----------+---------+----------+----------+----------+-----------+---------+---------+----------+--------------+----------+-----------+-------+------------+------------+
@@ -104,13 +104,13 @@
Let's now look at the physical device level. Still in the Voltha CLI run the following.
-```
+```shell
devices
```
this returns
-```
+```shell
Devices:
+--------------+------------+------+--------------+------+-------------+-------------+----------------+----------------+------------------+-------------------------+--------------------------+
| id | type | root | parent_id | vlan | admin_state | oper_status | connect_status | parent_port_no | host_and_port | proxy_address.device_id | proxy_address.channel_id |
@@ -124,14 +124,14 @@
Identify the ONU which sent the IGMP packet (128) and copy its device id (56a6fc8b859f in this case). Next run the following in the Voltha CLI.
-```
+```shell
device 56a6fc8b859f
flows
```
which returns
-```
+```shell
Device 56a6fc8b859f (type: ponsim_onu)
Flows (6):
+----------+----------+-----------+---------+----------+----------+-----------+--------------+----------+-----------+--------+
@@ -150,7 +150,7 @@
Let us now try this out for real with a real packet. Let's first build a multicast frame and send it down the nni port, we can do this with scapy.
-```
+```shell
sudo scapy
mc = Ether(src="00:00:00:00:00:01")/Dot1Q(vlan=4000)/IP(dst="229.0.0.1", proto=17)
sendp(mc, iface="eno2")
@@ -158,13 +158,13 @@
Meanwhile run tcpdump in the RG container:
-```
+```shell
tcpdump -nei eno1
```
in he RG container while tcpdump'ing we should see the following output.
-```
+```shell
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
08:09:43.004776 00:00:00:00:00:01 > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 34: 10.0.2.15 > 229.0.0.1: [|udp]
@@ -172,7 +172,7 @@
Woohoo!
-### Pass/Fail Criteria
+## Pass/Fail Criteria
* Flows and groups installed in ONOS
* Flows and groups installed in Voltha
diff --git a/docs/manuals/user/labtests/M09_maple_olt_tests_verify_authentication.md b/docs/manuals/user/labtests/M09_maple_olt_tests_verify_authentication.md
index 8cf0beb..62ef62c 100644
--- a/docs/manuals/user/labtests/M09_maple_olt_tests_verify_authentication.md
+++ b/docs/manuals/user/labtests/M09_maple_olt_tests_verify_authentication.md
@@ -1,10 +1,11 @@
-## M9 - Verify RG Authentication Scenario
+# M9 - Verify RG Authentication Scenario
-### Test Objective
+## Test Objective
* Purpose of this test is to verify RG authentication is successful with Radius / EAP method
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Maple OLT should be reachable to VOLTHA over IP interface over VLAN 4092
* Maple OLT should be in active state on VOLTHA
@@ -13,7 +14,8 @@
* Radius Server is in service and configured to authenticate RG
* DHCP Server should be down
-### Test Procedure
+## Test Procedure
+
* Start EAP authentication process from RG by resetting RG.
* RG should send EAP-Start message and verify it reaches VOLTHA/ONOS
* EAP message exchange should happen between RG and VOLTHA/ONOS on Management VLAN 4091.
@@ -26,7 +28,7 @@
* VOLTHA/ ONOS should send IGMP Forwarding Flow to OLT and ONU
* OLT/ONU will be able to forward DHCP, Unicast and IGMP packets from RG
-### Pass/Fail Criteria
+## Pass/Fail Criteria
* RG is successfully authenticated based on its credentials in Radius Server
* DHCP, Unicast and IGMP forwarding flows are setup on OLT/ONU
diff --git a/docs/manuals/user/labtests/M10_maple_olt_tests_verify_dhcp.md b/docs/manuals/user/labtests/M10_maple_olt_tests_verify_dhcp.md
index 9ff81a2..a45f3ad 100644
--- a/docs/manuals/user/labtests/M10_maple_olt_tests_verify_dhcp.md
+++ b/docs/manuals/user/labtests/M10_maple_olt_tests_verify_dhcp.md
@@ -1,10 +1,11 @@
-## M10 - Verify DHCP Lookup
+# M10 - Verify DHCP Lookup
-### Test Objective
+## Test Objective
* Purpose of this test is to verify RG can successfully setup DHCP session
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Maple OLT should be reachable to VOLTHA over IP interface over VLAN 4092
* Maple OLT should be in active state on VOLTHA
@@ -13,14 +14,15 @@
* DHCP, Unicast and IGMP forwarding flows are setup on OLT and ONU
* DHCP Server is running
-### Test Procedure
+## Test Procedure
+
* Enable DHCP on RG by either resetting or enable/disable port
* DHCP Request from should be forwarded by VOLTHA/ONOS to DHCP Server
* OLT will send and receive DHCP Messages with SVID 4091 towards VOLTHA/ONOS
* DHCP should succeed and RG should have IP address
* Verify ARP, PING and Traceroute succeeds from RG to DHCP server (Not planned on it will be additional step)
-### Pass/Fail Criteria
+## Pass/Fail Criteria
+
* RG can receive IP address from DHCP server
* ARP, Ping and Traceroute is successful between RG and DHCP server
-
diff --git a/docs/manuals/user/labtests/M11_maple_olt_tests_verify_unicast.md b/docs/manuals/user/labtests/M11_maple_olt_tests_verify_unicast.md
index 0a0f789..9d07b8b 100644
--- a/docs/manuals/user/labtests/M11_maple_olt_tests_verify_unicast.md
+++ b/docs/manuals/user/labtests/M11_maple_olt_tests_verify_unicast.md
@@ -1,20 +1,23 @@
-## M11 - Verify Unicast Access
+# M11 - Verify Unicast Access
-### Test Objective
+## Test Objective
* Purpose of this test is to verify OLT and ONU can pass double tagged traffic
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Maple OLT and ONU is activated using VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA
-### Test Procedure
+## Test Procedure
+
* On Spirent, configure double tagged traffic in downstream direction (1025,1025)
* On Spirent, send untagged traffic in upstream direction
* On the both ports capture traffic and verify the stream
-### Pass/Fail Criteria
+## Pass/Fail Criteria
+
* Upstream:
* Traffic coming out of OLT is double tagged 1025 ,1025
* Downstream:
diff --git a/docs/manuals/user/labtests/M12_maple_olt_tests_verify_multicast.md b/docs/manuals/user/labtests/M12_maple_olt_tests_verify_multicast.md
index 84b7c54..709a946 100644
--- a/docs/manuals/user/labtests/M12_maple_olt_tests_verify_multicast.md
+++ b/docs/manuals/user/labtests/M12_maple_olt_tests_verify_multicast.md
@@ -1,10 +1,11 @@
-## M12 - Verify Multicast Access
+# M12 - Verify Multicast Access
-### Test Objective
+## Test Objective
* To verify video service on RG
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Maple OLT should be reachable to VOLTHA over IP interface on VLAN 4092
* Maple OLT should be in active state on VOLTHA
@@ -12,12 +13,14 @@
* RG is authenticated with Radius and RG has IP address from DHCP
* VLC streaming server is active, VLC Video Client is connected to RG
-### Test Procedure
+## Test Procedure
+
* Enable Multicast Video Stream from VLC server
* Multicast Video stream should be tagged with VLAN ID 140
* From VLC client initiate connection to streaming Multicast channel
* Packet Capture at OLT port should show IGMP join message
* Observe Video quality on TV
-### Pass/Fail Criteria
+## Pass/Fail Criteria
+
* Video is displayed on TV
diff --git a/docs/manuals/user/labtests/M13_maple_olt_tests_verify_cvid_upstream.md b/docs/manuals/user/labtests/M13_maple_olt_tests_verify_cvid_upstream.md
index 9fbfaca..269e30e 100644
--- a/docs/manuals/user/labtests/M13_maple_olt_tests_verify_cvid_upstream.md
+++ b/docs/manuals/user/labtests/M13_maple_olt_tests_verify_cvid_upstream.md
@@ -1,14 +1,15 @@
-## M13 - Spirent - Verify Re-Write C-VID Upstream
+# M13 - Spirent - Verify Re-Write C-VID Upstream
-### Test Objective
+## Test Objective
* The purpose of this test is to verify ONU can re-write Priority tagged frames (VLAN ID 0) with single c-VID in upstream to wards OLT
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Maple OLT and ONU is activated using VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA
-### Test Procedure
+## Test Procedure
-### Pass/Fail Criteria
+## Pass/Fail Criteria
diff --git a/docs/manuals/user/labtests/M14_maple_olt_tests_verify_cvid_downstream.md b/docs/manuals/user/labtests/M14_maple_olt_tests_verify_cvid_downstream.md
index f4fd4af..f14f646 100644
--- a/docs/manuals/user/labtests/M14_maple_olt_tests_verify_cvid_downstream.md
+++ b/docs/manuals/user/labtests/M14_maple_olt_tests_verify_cvid_downstream.md
@@ -1,13 +1,15 @@
-## M14 - Spirent - Verify Re-Write C-VID Downstream
+# M14 - Spirent - Verify Re-Write C-VID Downstream
-### Test Objective
+## Test Objective
+
* The Purpose of this test is to verify ONU can re-write single C-VID frames as priority tagges frames in downstream towards RG
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Maple OLT and ONU is activated using VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA
-### Test Procedure
+## Test Procedure
-### Pass/Fail Criteria
+## Pass/Fail Criteria
diff --git a/docs/manuals/user/labtests/M15_maple_olt_tests_verify_qinq_upstream.md b/docs/manuals/user/labtests/M15_maple_olt_tests_verify_qinq_upstream.md
index bec0b50..6a94d51 100644
--- a/docs/manuals/user/labtests/M15_maple_olt_tests_verify_qinq_upstream.md
+++ b/docs/manuals/user/labtests/M15_maple_olt_tests_verify_qinq_upstream.md
@@ -1,21 +1,23 @@
-## M15 - Spirent - Verify 802.1ad (QinQ) Upstream
+# M15 - Spirent - Verify 802.1ad (QinQ) Upstream
-### Test Objective
+## Test Objective
* Purpose of this test is to verify OLT can insert second VLAN tag (SVID) in upstream direction
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Maple OLT and ONU is activated using VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA
-### Test Procedure
+## Test Procedure
+
* On Spirent, send untagged traffic in upstream direction
* On the receiving port end, capture traffic and verify the VLAN parameters
-### Pass/Fail Criteria:
-* Upstream:
-o configure on the Spirent side to send untagged traffic (NO vlan configure)
-o OLT and ONT will add 1025 ,1025 respectively (i.e. 1025,1025)
-o Captured frame should contain 1025, 1025 vlan
+## Pass/Fail Criteria
+* Upstream:
+ * configure on the Spirent side to send untagged traffic (NO vlan configure)
+ * OLT and ONT will add 1025 ,1025 respectively (i.e. 1025,1025)
+ * Captured frame should contain 1025, 1025 vlan
diff --git a/docs/manuals/user/labtests/M16_maple_olt_tests_verify_qinq_downstream.md b/docs/manuals/user/labtests/M16_maple_olt_tests_verify_qinq_downstream.md
index c3007ae..bfe6bfb 100644
--- a/docs/manuals/user/labtests/M16_maple_olt_tests_verify_qinq_downstream.md
+++ b/docs/manuals/user/labtests/M16_maple_olt_tests_verify_qinq_downstream.md
@@ -1,20 +1,23 @@
-## M16 - Spirent - Verify 802.1ad (QinQ) Downstream
+# M16 - Spirent - Verify 802.1ad (QinQ) Downstream
-### Test Objective
+## Test Objective
* Purpose of this test is to verify OLT (DNX) can strip SVID from the incoming packets and forward only with CVID to ONU
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Maple OLT and ONU is activated using VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA
-### Test Procedure
+## Test Procedure
+
* On Spirent, configure double tagged traffic in downstream direction (1025,1025)
* On the receiving port, capture traffic and verify the VLAN parameters
-### Pass/Fail Criteria
+## Pass/Fail Criteria
+
* Downstream:
- * configure on the Spirent side to send traffic with 1025,1025
- * OLT will strip the 1025 and send traffic to corresponding ONT ( i.e. 1025 to ONT)
- * Captured frame should contain only one VLAN tag (1025 VLAN)
+ * configure on the Spirent side to send traffic with 1025,1025
+ * OLT will strip the 1025 and send traffic to corresponding ONT ( i.e. 1025 to ONT)
+ * Captured frame should contain only one VLAN tag (1025 VLAN)
diff --git a/docs/manuals/user/labtests/M17_maple_olt_tests_verify_ipv4_downstream.md b/docs/manuals/user/labtests/M17_maple_olt_tests_verify_ipv4_downstream.md
index 5935365..1bd1c8b 100644
--- a/docs/manuals/user/labtests/M17_maple_olt_tests_verify_ipv4_downstream.md
+++ b/docs/manuals/user/labtests/M17_maple_olt_tests_verify_ipv4_downstream.md
@@ -1,24 +1,26 @@
-## M17 - Spirent - Verify IPv4 Unicast Streams Downstream
+# M17 - Spirent - Verify IPv4 Unicast Streams Downstream
-### Test Objective
+## Test Objective
* Purpose of this test is to verify OLT and ONU can handle double tagged traffic
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Maple OLT and ONU is activated using VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA
-### Test Procedure
+## Test Procedure
+
* On Spirent, configure double tagged traffic in downstream direction (1025,1025)
* On Spirent, send untagged traffic in upstream direction
* On the both ports capture traffic and verify the stream
-### Pass / Fail Criteria
-* Upstream:
- * configure on the Spirent side to send traffic with NO vlan
- * OLT and ONT will add 1025 ,1025 respectively (i.e. 1025,1025)
-* Downstream:
- * configure on the Spirent side to send traffic with 1025,1025
- * OLT will strip the 1025 and send traffic to corresponding ONT ( i.e. 1025 to ONT)
+## Pass / Fail Criteria
+* Upstream:
+ * configure on the Spirent side to send traffic with NO vlan
+ * OLT and ONT will add 1025 ,1025 respectively (i.e. 1025,1025)
+* Downstream:
+ * configure on the Spirent side to send traffic with 1025,1025
+ * OLT will strip the 1025 and send traffic to corresponding ONT ( i.e. 1025 to ONT)
diff --git a/docs/manuals/user/labtests/M18_maple_olt_tests_verify_ipv4_downstream_case2.md b/docs/manuals/user/labtests/M18_maple_olt_tests_verify_ipv4_downstream_case2.md
index a58e3d6..7d50096 100644
--- a/docs/manuals/user/labtests/M18_maple_olt_tests_verify_ipv4_downstream_case2.md
+++ b/docs/manuals/user/labtests/M18_maple_olt_tests_verify_ipv4_downstream_case2.md
@@ -1,17 +1,20 @@
-## M18 - Spirent - Verify IPv4 Unicast Streams Downstream Case2
+# M18 - Spirent - Verify IPv4 Unicast Streams Downstream Case2
-### Test Objective
+## Test Objective
* Purpose of this test is to verify P-BIT parameter is propagated to C-VID when sending downstream traffic to ONU
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Maple OLT and ONU is activated using VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA
-### Test Procedure
+## Test Procedure
+
* On Spirent, configure P-BIT for CVID. ex: set P-BIT value to 3
* On the Receive port end, capture traffic and verify the P-BIT parameter on SVID in Up stream direction
-### Pass / Fail Criteria
+## Pass / Fail Criteria
+
* P-BIT value s-VID is copied to C-VID in downstream direction
diff --git a/docs/manuals/user/labtests/M19_maple_olt_tests_ranging.md b/docs/manuals/user/labtests/M19_maple_olt_tests_ranging.md
index 9c5d42c..42d380e 100644
--- a/docs/manuals/user/labtests/M19_maple_olt_tests_ranging.md
+++ b/docs/manuals/user/labtests/M19_maple_olt_tests_ranging.md
@@ -1,19 +1,21 @@
-## M19 - 10k and 20k ONU Ranging
+# M19 - 10k and 20k ONU Ranging
-### Test Objective
+## Test Objective
* Purpose of this test is to verify ONU can range with 10km and 20 KM distance
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
-### Test Procedure
+## Test Procedure
+
* Place the ONU Using 10KM fiber pool, Activate the OLT and ONU using VOLTHA
* Place the ONU Using 20KM fiber pool, Activate the OLT and ONU using VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA and send traffic
-### Pass / Fail Criteria
+## Pass / Fail Criteria
+
* OLT can range the ONU successfully with 10 KM distance
* OLT can range the ONU successfully with 20 KM distance
* Traffic flows successfully with 20 KM distance without any drops
-
diff --git a/docs/manuals/user/labtests/M20_maple_olt_tests_mib.md b/docs/manuals/user/labtests/M20_maple_olt_tests_mib.md
index 0f1fad9..eb5e82d 100644
--- a/docs/manuals/user/labtests/M20_maple_olt_tests_mib.md
+++ b/docs/manuals/user/labtests/M20_maple_olt_tests_mib.md
@@ -1,15 +1,17 @@
-## M20 - MIB Download and Upload
+# M20 - MIB Download and Upload
-### Test Objective
+## Test Objective
* Purpose of this test is to verify OMCI MIB is downloaded from OLT to ONU and vice versa as part of ONU ranging process
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
-### Test Procedure
+## Test Procedure
+
* Activate the Maple OLT and ONU using VOLTHA
-### Pass / Fail Criteria
-* Once the ONU ranges, OMCI MIB is downloaded from OLT to ONU and vice versa
+## Pass / Fail Criteria
+* Once the ONU ranges, OMCI MIB is downloaded from OLT to ONU and vice versa
diff --git a/docs/manuals/user/labtests/M21_maple_olt_tests_2000_byte_frames.md b/docs/manuals/user/labtests/M21_maple_olt_tests_2000_byte_frames.md
index df44060..dcc33f4 100644
--- a/docs/manuals/user/labtests/M21_maple_olt_tests_2000_byte_frames.md
+++ b/docs/manuals/user/labtests/M21_maple_olt_tests_2000_byte_frames.md
@@ -1,17 +1,19 @@
-## M21 - 2000 byte Frames
+# M21 - 2000 byte Frames
-### Test Objective
+## Test Objective
* Purpose of this test is to verify OLT and ONU can accept and forward traffic when frame size of 2000 bytes
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Maple OLT and ONU is activated using VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA
-### Test Procedure
+## Test Procedure
+
* Send data/unicast traffic with frame size of 2000 Bytes in upstream and downstream direction
-### Pass / Fail Criteria
-* OLT & ONU can accept and forward frames of size 2000 Bytes successfully
+## Pass / Fail Criteria
+* OLT & ONU can accept and forward frames of size 2000 Bytes successfully
diff --git a/docs/manuals/user/labtests/M22_maple_olt_tests_data_and_video.md b/docs/manuals/user/labtests/M22_maple_olt_tests_data_and_video.md
index c551928..7f6646a 100644
--- a/docs/manuals/user/labtests/M22_maple_olt_tests_data_and_video.md
+++ b/docs/manuals/user/labtests/M22_maple_olt_tests_data_and_video.md
@@ -1,17 +1,20 @@
-## M22 - Simultaneous Data and Video Streams
+# M22 - Simultaneous Data and Video Streams
-### Test Objective
+## Test Objective
* Purpose of this test is to verify OLT and ONU can handle data and multicast traffic
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Maple OLT and ONU is activated using VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA
* Provision Multicast/IGMP service on the ONU from VOLTHA
-### Test Procedure
+## Test Procedure
+
* Send bi-directional data traffic and multicast traffic on the ONU
-### Expected Result
+## Expected Result
+
* Bi-directional data Traffic and Multicast traffic on the ONU went through successfully
diff --git a/docs/manuals/user/labtests/M23_maple_olt_tests_overnight.md b/docs/manuals/user/labtests/M23_maple_olt_tests_overnight.md
index e076e73..56bd592 100644
--- a/docs/manuals/user/labtests/M23_maple_olt_tests_overnight.md
+++ b/docs/manuals/user/labtests/M23_maple_olt_tests_overnight.md
@@ -1,17 +1,20 @@
-## M23 - Overnight Traffic Test
+# M23 - Overnight Traffic Test
-### Test Objective
+## Test Objective
* Purpose of this test is to verify overnight traffic test went through successfully with zero drops
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Maple OLT and ONU is activated using VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA
* Provision Multicast/IGMP service on the ONU from VOLTHA
-### Test Procedure
+## Test Procedure
+
* Send bi-directional data and multicast traffic over night and monitor for traffic drops
-### Pass / Fail Criteria:
+## Pass / Fail Criteria
+
* Bi-directional traffic went through overnight and no traffic drops
diff --git a/docs/manuals/user/labtests/M24_maple_olt_tests_ha_fiber_disconnect.md b/docs/manuals/user/labtests/M24_maple_olt_tests_ha_fiber_disconnect.md
index 6ac6a93..607dada 100644
--- a/docs/manuals/user/labtests/M24_maple_olt_tests_ha_fiber_disconnect.md
+++ b/docs/manuals/user/labtests/M24_maple_olt_tests_ha_fiber_disconnect.md
@@ -1,18 +1,21 @@
-## M24 - Traffic Recovers After Fiber Disconnect (Best Effort)
+# M24 - Traffic Recovers After Fiber Disconnect (Best Effort)
-### Test Objective
+## Test Objective
* Purpose of this test is to verify pull & re-insert of PON cable can resume the traffic on the ONU
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Maple OLT and ONU is activated using VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA
-### Test Procedure
+## Test Procedure
+
* Now manually pull the fiber cable the from ONU
* Re-insert the fiber cable to the ONU and verify ONU is ranges and traffic restores
-### Pass / Fail Criteria
+## Pass / Fail Criteria
+
* Traffic stopped when cable is pulled from ONU
* After cable insert, ONU is ranged back and traffic starts flowing automatically on the ONU
diff --git a/docs/manuals/user/labtests/M25_maple_olt_tests_ha_onu_reset.md b/docs/manuals/user/labtests/M25_maple_olt_tests_ha_onu_reset.md
index 585139f..05e289c 100644
--- a/docs/manuals/user/labtests/M25_maple_olt_tests_ha_onu_reset.md
+++ b/docs/manuals/user/labtests/M25_maple_olt_tests_ha_onu_reset.md
@@ -1,19 +1,21 @@
-## M25 - Traffic Recovers After ONU Reset (Best Effort)
+# M25 - Traffic Recovers After ONU Reset (Best Effort)
-### Test Objective
+## Test Objective
* Purpose of this test is to verify reset/reboot of ONU is able to recover the traffic on the ONU
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Maple OLT and ONU is activated using VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA
-### Test Procedure
+## Test Procedure
+
* Now manually reset /reboot the ONU
* Verify whether ONU ranges and traffic is restored successfully
-### Pass / Fail Criteria
+## Pass / Fail Criteria
+
* Traffic should stop flowing when ONU is restarted
* After ONU is up, traffic restores automatically on the ONU
-
diff --git a/docs/manuals/user/labtests/M26_maple_olt_tests_ha_olt_reset.md b/docs/manuals/user/labtests/M26_maple_olt_tests_ha_olt_reset.md
index 69ec6e6..d13e95a 100644
--- a/docs/manuals/user/labtests/M26_maple_olt_tests_ha_olt_reset.md
+++ b/docs/manuals/user/labtests/M26_maple_olt_tests_ha_olt_reset.md
@@ -1,21 +1,20 @@
-## M26 - Traffic Recovers After OLT Reset (Best Effort)
+# M26 - Traffic Recovers After OLT Reset (Best Effort)
-### Test Objective
+## Test Objective
* Purpose of this test is to verify reset/reboot of ONU is able to recover the traffic on the ONU
-### Test Configuration
+## Test Configuration
* Test Setup as shown in Section – 7
* Maple OLT and ONU is activated using VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA
-### Test Procedure
+## Test Procedure
* Now reset /reboot the OLT
* Verify OLT is up, ONU ranges and traffic is restored successfully
-### Pass / Fail Criteria
+## Pass / Fail Criteria
* When OLT is up, ONU ranges back and traffic restores automatically on the ONU
-
diff --git a/docs/manuals/user/labtests/M27_maple_olt_tests_ha_tor_switch_reset.md b/docs/manuals/user/labtests/M27_maple_olt_tests_ha_tor_switch_reset.md
index 2d6c247..0177d88 100644
--- a/docs/manuals/user/labtests/M27_maple_olt_tests_ha_tor_switch_reset.md
+++ b/docs/manuals/user/labtests/M27_maple_olt_tests_ha_tor_switch_reset.md
@@ -1,18 +1,20 @@
-## M27 - Traffic Recovers After ToR Switch Reset (Best Effort)
+# M27 - Traffic Recovers After ToR Switch Reset (Best Effort)
-### Test Objective
+## Test Objective
* Purpose of this test is to verify reset/reboot of TOR switch is able to recover the traffic
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Maple OLT and ONU is activated using VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA
-### Test Procedure
+## Test Procedure
+
* Now reset /reboot the TOR switch
* Verify TOR is up, Traffic is restored successfully
-### Pass / Fail Criteria
-* Traffic should stop flowing when TOR switch is restarted. Once the TOR switch is up, Traffic restored successfully on the ONU
+## Pass / Fail Criteria
+* Traffic should stop flowing when TOR switch is restarted. Once the TOR switch is up, Traffic restored successfully on the ONU
diff --git a/docs/manuals/user/labtests/N00_netconf.md b/docs/manuals/user/labtests/N00_netconf.md
index 61c6dad..a7e14dc 100644
--- a/docs/manuals/user/labtests/N00_netconf.md
+++ b/docs/manuals/user/labtests/N00_netconf.md
@@ -5,13 +5,10 @@
1. Deploys Netconf and its companion containers
2. Verifies base-line operation of Netconf Server
3. Introduces the tester to a subset of Netconf operations, which are
- * SSH connection
- * Retrieve Voltha YANG modules
- * Initiate a GET command on a Voltha Instance
- * Retrieve the list of adapters
-
-
+ * SSH connection
+ * Retrieve Voltha YANG modules
+ * Initiate a GET command on a Voltha Instance
+ * Retrieve the list of adapters
+
Running these test cases will require a Netconf Browser. The MG Soft
- Netconf Browser will be used. A free 30-day trial of that browser can be
- obtained from ```http://www.mg-soft.com/download
- .html?product=netconfbrowser```.
+ Netconf Browser will be used. A free 30-day trial of that browser can be obtained from <http://www.mg-soft.com/download.html?product=netconfbrowser>.
diff --git a/docs/manuals/user/labtests/N01_netconf_bringup_deploy.md b/docs/manuals/user/labtests/N01_netconf_bringup_deploy.md
index c79a8a3..e15f6d1 100644
--- a/docs/manuals/user/labtests/N01_netconf_bringup_deploy.md
+++ b/docs/manuals/user/labtests/N01_netconf_bringup_deploy.md
@@ -1,32 +1,25 @@
-## N1 - Deploy Netconf and Verify its Vital Signs
+# N1 - Deploy Netconf and Verify its Vital Signs
-### Test Objective
+## Test Objective
-* Purpose of this test is to launch Netconf together with all of its
-dependencies and verify that all are in working condition.
+* Purpose of this test is to launch Netconf together with all of its dependencies and verify that all are in working condition.
-### Test Configuration and Procedure
+## Test Configuration and Procedure
-* Since Netconf is deployed as part of Voltha ensemble, follow the
-instructions from [Voltha](V01_voltha_bringup_deploy.md)
+* Since Netconf is deployed as part of Voltha ensemble, follow the instructions from [Voltha](V01_voltha_bringup_deploy.md)
+## Pass/Fail Criteria (Installation Checkpoint)
-### Pass/Fail Criteria (Installation Checkpoint)
+* The Pass/Fail criteria in [Voltha](V01_voltha_bringup_deploy.md) applies here as well.
+* Verify Netconf server is up and listening on port 1830. Issue the following commands in the same Linux terminal:
-* The Pass/Fail criteria in [Voltha](V01_voltha_bringup_deploy.md)
-applies here as well.
-
-* Verify Netconf server is up and listening on port 1830. Issue the
-following commands in the same Linux terminal:
+```shell
+docker-compose -f compose/docker-compose-system-test.yml logs netconf | grep 1830
+```
- ```
- docker-compose -f compose/docker-compose-system-test.yml logs netconf | grep 1830
- ```
+Expected output are:
- Expected output are:
-
- ```
- netconf_1 | <time> DEBUG nc_server.start_ssh_server {port: 1830, event: starting, instance_id: compose_netconf_1}
- netconf_1 | <time DEBUG nc_server.start_ssh_server {port: 1830, event: started, instance_id: compose_netconf_1}
-
- ```
\ No newline at end of file
+```shell
+netconf_1 | <time> DEBUG nc_server.start_ssh_server {port: 1830, event: starting, instance_id: compose_netconf_1}
+netconf_1 | <time DEBUG nc_server.start_ssh_server {port: 1830, event: started, instance_id: compose_netconf_1}
+```
diff --git a/docs/manuals/user/labtests/N02_netconf_client_connect.md b/docs/manuals/user/labtests/N02_netconf_client_connect.md
index fcc35c1..e679ae7 100644
--- a/docs/manuals/user/labtests/N02_netconf_client_connect.md
+++ b/docs/manuals/user/labtests/N02_netconf_client_connect.md
@@ -1,74 +1,64 @@
-## N2 - Connect to Netconf Server using a Netconf Browser
+# N2 - Connect to Netconf Server using a Netconf Browser
-### Test Objective
+## Test Objective
-* The purpose of this test is to verify the SSH connectivity between the
-Netconf Browser and the Netconf Server
+* The purpose of this test is to verify the SSH connectivity between the Netconf Browser and the Netconf Server
-### Test Configuration
+## Test Configuration
* Preparatory steps completed
* Test-case N01 completed successfully
-* A netconf browser is available. MG Soft Netconf Browser will be used in
-the subsequent test procedures
+* A netconf browser is available. MG Soft Netconf Browser will be used in the subsequent test procedures
-### Test Procedure
+## Test Procedure
-* Connect to the Netconf Server
-
+* Connect to the Netconf Server
* Open a Netconf Browser (MG Soft in our case).
- * From the ```File``` menu select ```connect``` option.
+ * From the *File* menu select *connect* option.
* Use the following values when prompted:
- ```
- Host : <server-ip-or-hostname>
- Port : 830
- Username : voltha
- ```
-
- Do not select ```Public Key Authentication ```. While the server
- supports this authentication method the client key will need to be
- added to the Netconf server first. For ease of the test procedure
- we will only use username/password. The picture below shows the
- connect window.
-
- 
-
- * Select ```connect``` from the pop-up window
- * When prompted for the password, enter ```voltha```
+```shell
+Host : <server-ip-or-hostname>
+Port : 830
+Username : voltha
+```
-### Pass/Fail Criteria
+Do not select *Public Key Authentication*. While the server supports this authentication method the client key will need to be added to the Netconf server first. For ease of the test procedure we will only use username and password. The picture below shows the connect window.
-After successfully authenticating the user, the NETCONF session
-handshake occurs where the server and client exchange the Hello messages with
-the NETCONF capabilities they support. When the capabilities are successfully
-exchanged, the NETCONF session is established.
+
+
+* Select *connect* from the pop-up window
+* When prompted for the password, enter *voltha*
+
+## Pass/Fail Criteria
+
+After successfully authenticating the user, the NETCONF session handshake occurs where the server and client exchange the Hello messages with the NETCONF capabilities they support. When the capabilities are successfully exchanged, the NETCONF session is established.
* The status bar on the Netconf Browser should display :
- ```
- Connected To [SSH]voltha@<server-ip>:830 using NETCONF version 1.1
- ```
+```shell
+Connected To [SSH]voltha@<server-ip>:830 using NETCONF version 1.1
+```
-* Select the ```capabilities``` widget in the output window. The following
-server capabilities should be displayed:
+* Select the *capabilities* widget in the output window. The following server capabilities should be displayed:
- ```
- urn:ietf:params:netconf:base:1.0
- urn:ietf:params:netconf:base:1.1
- urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring
- urn:opencord:params:xml:ns:voltha:ietf-adapter
- urn:opencord:params:xml:ns:voltha:ietf-annotations
- urn:opencord:params:xml:ns:voltha:ietf-any
- urn:opencord:params:xml:ns:voltha:ietf-common
- urn:opencord:params:xml:ns:voltha:ietf-device
- urn:opencord:params:xml:ns:voltha:ietf-empty
- urn:opencord:params:xml:ns:voltha:ietf-health
- urn:opencord:params:xml:ns:voltha:ietf-logical_device
- urn:opencord:params:xml:ns:voltha:ietf-meta
- urn:opencord:params:xml:ns:voltha:ietf-openflow_13
- urn:opencord:params:xml:ns:voltha:ietf-voltha
- ```
+```xml
+urn:ietf:params:netconf:base:1.0
+urn:ietf:params:netconf:base:1.1
+urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring
+urn:opencord:params:xml:ns:voltha:ietf-adapter
+urn:opencord:params:xml:ns:voltha:ietf-annotations
+urn:opencord:params:xml:ns:voltha:ietf-any
+urn:opencord:params:xml:ns:voltha:ietf-common
+urn:opencord:params:xml:ns:voltha:ietf-device
+urn:opencord:params:xml:ns:voltha:ietf-empty
+urn:opencord:params:xml:ns:voltha:ietf-health
+urn:opencord:params:xml:ns:voltha:ietf-logical_device
+urn:opencord:params:xml:ns:voltha:ietf-meta
+urn:opencord:params:xml:ns:voltha:ietf-openflow_13
+urn:opencord:params:xml:ns:voltha:ietf-voltha
+```
+
* Below is a picture of a connected Netconf Browser.
- 
+
diff --git a/docs/manuals/user/labtests/N03_netconf_client_retrieve_YANG_modules.md b/docs/manuals/user/labtests/N03_netconf_client_retrieve_YANG_modules.md
index 4535c2d..c69c96f 100644
--- a/docs/manuals/user/labtests/N03_netconf_client_retrieve_YANG_modules.md
+++ b/docs/manuals/user/labtests/N03_netconf_client_retrieve_YANG_modules.md
@@ -1,84 +1,66 @@
-## N3 - Retrieve and Load the Voltha YANG Modules
+# N3 - Retrieve and Load the Voltha YANG Modules
-### Test Objective
+## Test Objective
-* The purpose of this test is to retrieve and load the voltha YANG modules
-from the Netconf Server
+* The purpose of this test is to retrieve and load the voltha YANG modules from the Netconf Server
-### Test Configuration
+## Test Configuration
* Preparatory steps completed
* Test-cases N01 and N02 completed successfully
* The Netconf client/server connection is up
-* No Voltha YANG modules has been loaded into MG Soft. If the modules were
-loaded from a prior test, then select ```Unload All Modules``` from the
-```Module``` menu to clear them.
+* No Voltha YANG modules has been loaded into MG Soft. If the modules were loaded from a prior test, then select *Unload All Modules* from the *Module* menu to clear them.
-### Test Procedure
+## Test Procedure
* Retrieve voltha schemas
+ * From the *Tools* menu select *Get Schema...* option. A window will be displayed with a list of schemas.
- * From the ```Tools``` menu select ```Get Schema...``` option.
-
- A window will be displayed with a list of schemas.
-
- 
-
- * On the displayed window:
- * check the ```Download all``` box
- * under ```options``` enter the location where the YANG modules
- will be download to (```Download To```)
- * select the ```Download``` button
-
-
- The YANG modules will be downloaded to the specified location. If the
- modules were downloaded before then the user will be prompted to allow
- for overwrite.
-
- * After the download is complete, select the ```close``` button from
- the displayed window.
-
- The Netconf Browser will show the following screens.
-
- 
-
-
-* Load the YANG Modules
+
+ * On the displayed window:
+ * check the *Download all* box
+ * under *options* enter the location where the YANG modules will be download to (*Download To*)
+ * select the *Download* button
+
+The YANG modules will be downloaded to the specified location. If the modules were downloaded before then the user will be prompted to allow for overwrite.
+
+* After the download is complete, select the *close* button from the displayed window.
+
+The Netconf Browser will show the following screens.
+
+
+
+* Load the YANG Modules
* From the ```Module``` menu select ```Load Module...``` option.
* On the displayed window:
* browse to the location where the YANG modules were downloaded
* select all the following files:
-
- ```
- ietf-adapter@2016-11-15
- ietf-annotations@2016-11-15
- ietf-any@2016-11-15
- ietf-common@2016-11-15
- ietf-device@2016-11-15
- ietf-empty@2016-11-15
- ietf-health@2016-11-15
- ietf-logical_device@2016-11-15
- ietf-meta@2016-11-15
- ietf-openflow_13@2016-11-15
- ietf-voltha@2016-11-15
- ```
- * select the ```open button```
-
- 
- The Netconf Browser will scan, validate and load the modules. On
- successful loading, the modules will be displayed on the left
- window pane of the Browser:
-
- 
-
- At this point you can view the content of the Voltha YANG Modules by
- browsing through them.
+```shell
+ietf-adapter@2016-11-15
+ietf-annotations@2016-11-15
+ietf-any@2016-11-15
+ietf-common@2016-11-15
+ietf-device@2016-11-15
+ietf-empty@2016-11-15
+ietf-health@2016-11-15
+ietf-logical_device@2016-11-15
+ietf-meta@2016-11-15
+ietf-openflow_13@2016-11-15
+ietf-voltha@2016-11-15
+```
+* select the *open button*
+
-### Pass/Fail Criteria
+The Netconf Browser will scan, validate and load the modules. On successful loading, the modules will be displayed on the left window pane of the Browser:
-This test case should be considered passing if all the demonstrated behavior
-works with similar (but not necessarily identical) output.
\ No newline at end of file
+
+
+At this point you can view the content of the Voltha YANG Modules by browsing through them.
+
+## Pass/Fail Criteria
+
+This test case should be considered passing if all the demonstrated behavior works with similar (but not necessarily identical) output.
diff --git a/docs/manuals/user/labtests/N04_netconf_client_get_volthainstance.md b/docs/manuals/user/labtests/N04_netconf_client_get_volthainstance.md
index 7b1ffe6..398a1f8 100644
--- a/docs/manuals/user/labtests/N04_netconf_client_get_volthainstance.md
+++ b/docs/manuals/user/labtests/N04_netconf_client_get_volthainstance.md
@@ -1,182 +1,175 @@
-## N4 - Get VolthaInstance info
+# N4 - Get VolthaInstance info
-### Test Objective
+## Test Objective
-* The purpose of this test is to run a simple GET command that would
-retrieve the ```VolthaInstance``` info
+* The purpose of this test is to run a simple GET command that would retrieve the *VolthaInstance* info.
-### Test Configuration
+## Test Configuration
* Preparatory steps completed
* Test-cases N01, N02 and N03 completed successfully
* The Netconf client/server connection is up
+## Test Procedure
-### Test Procedure
+* Execute the GET command on the VolthaInstance
+ * Expand the *ietf-voltha@2016-11-15* module on the left pane of the Netconf Browser
+ * Select the *VolthaInstance* container
+ * Right click and select *get(execute)* command
-* Execute the GET command on the VolthaInstance
-
- * Expand the ```ietf-voltha@2016-11-15``` module on the left pane of
- the Netconf Browser
- * Select the ```VolthaInstance``` container
- * Right click and select ```get(execute)``` command
-
-
-### Pass/Fail Criteria
+## Pass/Fail Criteria
Upon successful execution of the command, the similar output as below will be
displayed:
* In the logs windows:
- ```
- Command 404d0eb7-4008-48b1-a0e5-10596a3a421f:15; get was successful (took 75 ms).
-
- ```
-* In the output pane, the ```Output XML``` would be similar to:
+```shell
+Command 404d0eb7-4008-48b1-a0e5-10596a3a421f:15; get was successful (took 75 ms).
+```
- ```
- <?xml version="1.0" encoding="utf-8"?>
- <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
- <VolthaInstance xmlns="urn:opencord:params:xml:ns:voltha:ietf-voltha">
+* In the output pane, the *Output XML* would be similar to:
+
+```xml
+<?xml version="1.0" encoding="utf-8"?>
+ <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
+ <VolthaInstance xmlns="urn:opencord:params:xml:ns:voltha:ietf-voltha">
+ <log_level>INFO</log_level>
+ <device_types>
+ <adapter>broadcom_onu</adapter>
+ <accepts_bulk_flow_update>True</accepts_bulk_flow_update>
+ <id>broadcom_onu</id>
+ <accepts_add_remove_flow_updates>False</accepts_add_remove_flow_updates>
+ </device_types>
+ <device_types>
+ <adapter>maple_olt</adapter>
+ <accepts_bulk_flow_update>True</accepts_bulk_flow_update>
+ <id>maple_olt</id>
+ <accepts_add_remove_flow_updates>False</accepts_add_remove_flow_updates>
+ </device_types>
+ <device_types>
+ <adapter>microsemi</adapter>
+ <accepts_bulk_flow_update>True</accepts_bulk_flow_update>
+ <id>microsemi</id>
+ <accepts_add_remove_flow_updates>False</accepts_add_remove_flow_updates>
+ </device_types>
+ <device_types>
+ <adapter>ponsim_olt</adapter>
+ <accepts_bulk_flow_update>True</accepts_bulk_flow_update>
+ <id>ponsim_olt</id>
+ <accepts_add_remove_flow_updates>False</accepts_add_remove_flow_updates>
+ </device_types>
+ <device_types>
+ <adapter>ponsim_onu</adapter>
+ <accepts_bulk_flow_update>True</accepts_bulk_flow_update>
+ <id>ponsim_onu</id>
+ <accepts_add_remove_flow_updates>False</accepts_add_remove_flow_updates>
+ </device_types>
+ <device_types>
+ <adapter>simulated_olt</adapter>
+ <accepts_bulk_flow_update>True</accepts_bulk_flow_update>
+ <id>simulated_olt</id>
+ <accepts_add_remove_flow_updates>False</accepts_add_remove_flow_updates>
+ </device_types>
+ <device_types>
+ <adapter>simulated_onu</adapter>
+ <accepts_bulk_flow_update>True</accepts_bulk_flow_update>
+ <id>simulated_onu</id>
+ <accepts_add_remove_flow_updates>False</accepts_add_remove_flow_updates>
+ </device_types>
+ <device_types>
+ <adapter>tibit_olt</adapter>
+ <accepts_bulk_flow_update>True</accepts_bulk_flow_update>
+ <id>tibit_olt</id>
+ <accepts_add_remove_flow_updates>False</accepts_add_remove_flow_updates>
+ </device_types>
+ <device_types>
+ <adapter>tibit_onu</adapter>
+ <accepts_bulk_flow_update>True</accepts_bulk_flow_update>
+ <id>tibit_onu</id>
+ <accepts_add_remove_flow_updates>False</accepts_add_remove_flow_updates>
+ </device_types>
+ <instance_id>compose_voltha_1</instance_id>
+ <version>0.9.0</version>
+ <health>
+ <state>HEALTHY</state>
+ </health>
+ <adapters>
+ <config>
<log_level>INFO</log_level>
- <device_types>
- <adapter>broadcom_onu</adapter>
- <accepts_bulk_flow_update>True</accepts_bulk_flow_update>
- <id>broadcom_onu</id>
- <accepts_add_remove_flow_updates>False</accepts_add_remove_flow_updates>
- </device_types>
- <device_types>
- <adapter>maple_olt</adapter>
- <accepts_bulk_flow_update>True</accepts_bulk_flow_update>
- <id>maple_olt</id>
- <accepts_add_remove_flow_updates>False</accepts_add_remove_flow_updates>
- </device_types>
- <device_types>
- <adapter>microsemi</adapter>
- <accepts_bulk_flow_update>True</accepts_bulk_flow_update>
- <id>microsemi</id>
- <accepts_add_remove_flow_updates>False</accepts_add_remove_flow_updates>
- </device_types>
- <device_types>
- <adapter>ponsim_olt</adapter>
- <accepts_bulk_flow_update>True</accepts_bulk_flow_update>
- <id>ponsim_olt</id>
- <accepts_add_remove_flow_updates>False</accepts_add_remove_flow_updates>
- </device_types>
- <device_types>
- <adapter>ponsim_onu</adapter>
- <accepts_bulk_flow_update>True</accepts_bulk_flow_update>
- <id>ponsim_onu</id>
- <accepts_add_remove_flow_updates>False</accepts_add_remove_flow_updates>
- </device_types>
- <device_types>
- <adapter>simulated_olt</adapter>
- <accepts_bulk_flow_update>True</accepts_bulk_flow_update>
- <id>simulated_olt</id>
- <accepts_add_remove_flow_updates>False</accepts_add_remove_flow_updates>
- </device_types>
- <device_types>
- <adapter>simulated_onu</adapter>
- <accepts_bulk_flow_update>True</accepts_bulk_flow_update>
- <id>simulated_onu</id>
- <accepts_add_remove_flow_updates>False</accepts_add_remove_flow_updates>
- </device_types>
- <device_types>
- <adapter>tibit_olt</adapter>
- <accepts_bulk_flow_update>True</accepts_bulk_flow_update>
- <id>tibit_olt</id>
- <accepts_add_remove_flow_updates>False</accepts_add_remove_flow_updates>
- </device_types>
- <device_types>
- <adapter>tibit_onu</adapter>
- <accepts_bulk_flow_update>True</accepts_bulk_flow_update>
- <id>tibit_onu</id>
- <accepts_add_remove_flow_updates>False</accepts_add_remove_flow_updates>
- </device_types>
- <instance_id>compose_voltha_1</instance_id>
- <version>0.9.0</version>
- <health>
- <state>HEALTHY</state>
- </health>
- <adapters>
- <config>
- <log_level>INFO</log_level>
- </config>
- <version>0.4</version>
- <vendor>Voltha project</vendor>
- <id>broadcom_onu</id>
- </adapters>
- <adapters>
- <config>
- <log_level>INFO</log_level>
- </config>
- <version>0.4</version>
- <vendor>Voltha project</vendor>
- <id>maple_olt</id>
- </adapters>
- <adapters>
- <config>
- <log_level>INFO</log_level>
- </config>
- <version>0.1</version>
- <vendor>Microsemi / Celestica</vendor>
- <id>microsemi</id>
- </adapters>
- <adapters>
- <config>
- <log_level>INFO</log_level>
- </config>
- <version>0.4</version>
- <vendor>Voltha project</vendor>
- <id>ponsim_olt</id>
- </adapters>
- <adapters>
- <config>
- <log_level>INFO</log_level>
- </config>
- <version>0.4</version>
- <vendor>Voltha project</vendor>
- <id>ponsim_onu</id>
- </adapters>
- <adapters>
- <config>
- <log_level>INFO</log_level>
- </config>
- <version>0.1</version>
- <vendor>Voltha project</vendor>
- <id>simulated_olt</id>
- </adapters>
- <adapters>
- <config>
- <log_level>INFO</log_level>
- </config>
- <version>0.1</version>
- <vendor>Voltha project</vendor>
- <id>simulated_onu</id>
- </adapters>
- <adapters>
- <config>
- <log_level>INFO</log_level>
- </config>
- <version>0.1</version>
- <vendor>Tibit Communications Inc.</vendor>
- <id>tibit_olt</id>
- </adapters>
- <adapters>
- <config>
- <log_level>INFO</log_level>
- </config>
- <version>0.1</version>
- <vendor>Tibit Communications Inc.</vendor>
- <id>tibit_onu</id>
- </adapters>
- </VolthaInstance>
- </data>
- ```
-
-* In the output pane, the ```Output Tree``` would display a well formed tree
- as per the YANG module definition.
-
- 
+ </config>
+ <version>0.4</version>
+ <vendor>Voltha project</vendor>
+ <id>broadcom_onu</id>
+ </adapters>
+ <adapters>
+ <config>
+ <log_level>INFO</log_level>
+ </config>
+ <version>0.4</version>
+ <vendor>Voltha project</vendor>
+ <id>maple_olt</id>
+ </adapters>
+ <adapters>
+ <config>
+ <log_level>INFO</log_level>
+ </config>
+ <version>0.1</version>
+ <vendor>Microsemi / Celestica</vendor>
+ <id>microsemi</id>
+ </adapters>
+ <adapters>
+ <config>
+ <log_level>INFO</log_level>
+ </config>
+ <version>0.4</version>
+ <vendor>Voltha project</vendor>
+ <id>ponsim_olt</id>
+ </adapters>
+ <adapters>
+ <config>
+ <log_level>INFO</log_level>
+ </config>
+ <version>0.4</version>
+ <vendor>Voltha project</vendor>
+ <id>ponsim_onu</id>
+ </adapters>
+ <adapters>
+ <config>
+ <log_level>INFO</log_level>
+ </config>
+ <version>0.1</version>
+ <vendor>Voltha project</vendor>
+ <id>simulated_olt</id>
+ </adapters>
+ <adapters>
+ <config>
+ <log_level>INFO</log_level>
+ </config>
+ <version>0.1</version>
+ <vendor>Voltha project</vendor>
+ <id>simulated_onu</id>
+ </adapters>
+ <adapters>
+ <config>
+ <log_level>INFO</log_level>
+ </config>
+ <version>0.1</version>
+ <vendor>Tibit Communications Inc.</vendor>
+ <id>tibit_olt</id>
+ </adapters>
+ <adapters>
+ <config>
+ <log_level>INFO</log_level>
+ </config>
+ <version>0.1</version>
+ <vendor>Tibit Communications Inc.</vendor>
+ <id>tibit_onu</id>
+ </adapters>
+ </VolthaInstance>
+ </data>
+```
+* In the output pane, the ```Output Tree``` would display a well formed tree as per the YANG module definition.
+
+
diff --git a/docs/manuals/user/labtests/N05_netconf_client_get_adapters.md b/docs/manuals/user/labtests/N05_netconf_client_get_adapters.md
index ab99dbb..f0cc745 100644
--- a/docs/manuals/user/labtests/N05_netconf_client_get_adapters.md
+++ b/docs/manuals/user/labtests/N05_netconf_client_get_adapters.md
@@ -1,121 +1,116 @@
-## N5 - Get List of Adapters
+# N5 - Get List of Adapters
-### Test Objective
+## Test Objective
* The purpose of this test is to retrieve the list of adapters
-### Test Configuration
+## Test Configuration
* Preparatory steps completed
* Test-cases N01, N02 and N03 completed successfully
* The Netconf client/server connection is up
-
-### Test Procedure
+## Test Procedure
* Execute the GET command on the VolthaInstance/adapters
-
- * Expand the ```ietf-voltha@2016-11-15``` module on the left pane of
+ * Expand the *ietf-voltha@2016-11-15* module on the left pane of
the Netconf Browser
- * Expand the ```VolthaInstance``` container
- * Select the ```adapters``` grouping
- * Right click and select ```get(execute)``` command
-
+ * Expand the *VolthaInstance* container
+ * Select the *adapters* grouping
+ * Right click and select *get(execute)* command
-### Pass/Fail Criteria
+## Pass/Fail Criteria
-Upon successful execution of the command, the similar output as below will be
-displayed:
+Upon successful execution of the command, the similar output as below will be displayed:
* In the logs windows:
- ```
- Command 404d0eb7-4008-48b1-a0e5-10596a3a421f:17; get was successful (took 76 ms).
-
- ```
-* In the output pane, the ```Output XML``` would be similar to:
+```shell
+Command 404d0eb7-4008-48b1-a0e5-10596a3a421f:17; get was successful (took 76 ms).
+```
- ```
- <?xml version="1.0" encoding="utf-8"?>
- <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
- <VolthaInstance xmlns="urn:opencord:params:xml:ns:voltha:ietf-voltha">
- <adapters>
- <config>
- <log_level>INFO</log_level>
- </config>
- <version>0.4</version>
- <vendor>Voltha project</vendor>
- <id>broadcom_onu</id>
- </adapters>
- <adapters>
- <config>
- <log_level>INFO</log_level>
- </config>
- <version>0.4</version>
- <vendor>Voltha project</vendor>
- <id>maple_olt</id>
- </adapters>
- <adapters>
- <config>
- <log_level>INFO</log_level>
- </config>
- <version>0.1</version>
- <vendor>Microsemi / Celestica</vendor>
- <id>microsemi</id>
- </adapters>
- <adapters>
- <config>
- <log_level>INFO</log_level>
- </config>
- <version>0.4</version>
- <vendor>Voltha project</vendor>
- <id>ponsim_olt</id>
- </adapters>
- <adapters>
- <config>
- <log_level>INFO</log_level>
- </config>
- <version>0.4</version>
- <vendor>Voltha project</vendor>
- <id>ponsim_onu</id>
- </adapters>
- <adapters>
- <config>
- <log_level>INFO</log_level>
- </config>
- <version>0.1</version>
- <vendor>Voltha project</vendor>
- <id>simulated_olt</id>
- </adapters>
- <adapters>
- <config>
- <log_level>INFO</log_level>
- </config>
- <version>0.1</version>
- <vendor>Voltha project</vendor>
- <id>simulated_onu</id>
- </adapters>
- <adapters>
- <config>
- <log_level>INFO</log_level>
- </config>
- <version>0.1</version>
- <vendor>Tibit Communications Inc.</vendor>
- <id>tibit_olt</id>
- </adapters>
- <adapters>
- <config>
- <log_level>INFO</log_level>
- </config>
- <version>0.1</version>
- <vendor>Tibit Communications Inc.</vendor>
- <id>tibit_onu</id>
- </adapters>
- </VolthaInstance>
- </data>
- ```
-
-* In the output pane, the ```Output Tree``` would display a well formed tree
- as per the YANG module definition
+* In the output pane, the *Output XML* would be similar to:
- 
+```xml
+<?xml version="1.0" encoding="utf-8"?>
+<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
+ <VolthaInstance xmlns="urn:opencord:params:xml:ns:voltha:ietf-voltha">
+ <adapters>
+ <config>
+ <log_level>INFO</log_level>
+ </config>
+ <version>0.4</version>
+ <vendor>Voltha project</vendor>
+ <id>broadcom_onu</id>
+ </adapters>
+ <adapters>
+ <config>
+ <log_level>INFO</log_level>
+ </config>
+ <version>0.4</version>
+ <vendor>Voltha project</vendor>
+ <id>maple_olt</id>
+ </adapters>
+ <adapters>
+ <config>
+ <log_level>INFO</log_level>
+ </config>
+ <version>0.1</version>
+ <vendor>Microsemi / Celestica</vendor>
+ <id>microsemi</id>
+ </adapters>
+ <adapters>
+ <config>
+ <log_level>INFO</log_level>
+ </config>
+ <version>0.4</version>
+ <vendor>Voltha project</vendor>
+ <id>ponsim_olt</id>
+ </adapters>
+ <adapters>
+ <config>
+ <log_level>INFO</log_level>
+ </config>
+ <version>0.4</version>
+ <vendor>Voltha project</vendor>
+ <id>ponsim_onu</id>
+ </adapters>
+ <adapters>
+ <config>
+ <log_level>INFO</log_level>
+ </config>
+ <version>0.1</version>
+ <vendor>Voltha project</vendor>
+ <id>simulated_olt</id>
+ </adapters>
+ <adapters>
+ <config>
+ <log_level>INFO</log_level>
+ </config>
+ <version>0.1</version>
+ <vendor>Voltha project</vendor>
+ <id>simulated_onu</id>
+ </adapters>
+ <adapters>
+ <config>
+ <log_level>INFO</log_level>
+ </config>
+ <version>0.1</version>
+ <vendor>Tibit Communications Inc.</vendor>
+ <id>tibit_olt</id>
+ </adapters>
+ <adapters>
+ <config>
+ <log_level>INFO</log_level>
+ </config>
+ <version>0.1</version>
+ <vendor>Tibit Communications Inc.</vendor>
+ <id>tibit_onu</id>
+ </adapters>
+ </VolthaInstance>
+</data>
+```
+
+* In the output pane, the *Output Tree* would display a well formed tree as per the YANG module definition
+
+
diff --git a/docs/manuals/user/labtests/P01_Performance_Management_Configuration.md b/docs/manuals/user/labtests/P01_Performance_Management_Configuration.md
old mode 100755
new mode 100644
index 66ba4d3..301ff26
--- a/docs/manuals/user/labtests/P01_Performance_Management_Configuration.md
+++ b/docs/manuals/user/labtests/P01_Performance_Management_Configuration.md
@@ -1,487 +1,489 @@
-## P01 - Performance Management Configuration
-
-### Test Objective
-
-To demonstrate the ability to configure performance management using the `simulated-olt`.
-
-- Demonstrate the ability to change the frequency with which the stats are sampled and posted to kafka
-- Demonstrate the ability to selectively disable and enable specific stats
-- Demonstrate how the stats can be queried.
-
-### Test Configuration
-
-- The Voltha enseble is running per the deployment instructions.
-
-### Test procedure
-
-Start the voltha cli and add the simulated OLT.
-```
- ./cli/main.py -L
- _ _ _ ___ _ ___
-__ _____| | |_| |_ __ _ / __| | |_ _|
-\ V / _ \ | _| ' \/ _` | | (__| |__ | |
- \_/\___/_|\__|_||_\__,_| \___|____|___|
-(to exit type quit or hit Ctrl-D)
-(voltha)
-```
-Ensure that voltha is operating correctly:
-```
-health
-{
- "state": "HEALTHY"
-}
-(voltha)
-```
-
-Preprovision and enable the simulated OLT
-
-```
-(voltha) preprovision_olt
-success (device id = eecd8f5327bc)
-(voltha) enable
-enabling eecd8f5327bc
-waiting for device to be enabled...
-success (logical device id = 1)
-(voltha)
-```
-
-The device Id will be different from the device id shown above.
-
-In a different window, verify that the simulated stats are now being posted to the Kafak bus. First determine the port hosting the kafka broker:
-```
-docker inspect compose_kafka_1 | jq -r '.[0].NetworkSettings.Ports["9092/tcp"][0]["HostPort"]'
-```
-
-```
-32778
-```
-
-Using this port, query the kafka broker for topics
-
-```
-kafkacat -b localhost:32778 -L
-Metadata for all topics (from broker -1: localhost:32778/bootstrap):
- 1 brokers:
- broker 1001 at 10.0.2.15:32778
- 5 topics:
- topic "voltha.alarms" with 1 partitions:
- partition 0, leader 1001, replicas: 1001, isrs: 1001
- topic "voltha.kpis" with 1 partitions:
- partition 0, leader 1001, replicas: 1001, isrs: 1001
- topic "voltha.events" with 1 partitions:
- partition 0, leader 1001, replicas: 1001, isrs: 1001
- topic "voltha.heartbeat" with 1 partitions:
- partition 0, leader 1001, replicas: 1001, isrs: 1001
-```
-
-The topic of interest for this test is the voltha.kpis topic. So now query the topic to ensure that the simulated OLT is generating stats.
-```
-kafkacat -b localhost:32778 -C -o -1 -c 1 -t voltha.kpis | jq '.prefixes'
-```
-
-```
-{
- "voltha.simulated_olt.eecd8f5327bc.pon": {
- "metrics": {
- "rx_256_511": 47629,
- "tx_128_255": 33976,
- "tx_256_511": 47606,
- "tx_bytes": 51704532,
- "rx_bytes": 51757379,
- "rx_pkts": 51646,
- "rx_128_255": 33901,
- "tx_64": 28552,
- "rx_64": 28590,
- "tx_pkts": 51668,
- "rx_1519_9k": 28502,
- "tx_512_1023": 50295,
- "rx_1024_1518": 33998,
- "tx_65_127": 31313,
- "rx_65_127": 31280,
- "tx_1519_9k": 28505,
- "tx_1024_1518": 34027,
- "rx_512_1023": 50307
- }
- },
- "voltha.simulated_olt.eecd8f5327bc": {
- "metrics": {
- "cpu_util": 24.542841249401473,
- "buffer_util": 18.404615469439612
- }
- },
- "voltha.simulated_olt.eecd8f5327bc.nni": {
- "metrics": {
- "rx_256_511": 47649,
- "tx_128_255": 34071,
- "tx_256_511": 47569,
- "tx_bytes": 51634215,
- "rx_bytes": 51665858,
- "rx_pkts": 51686,
- "rx_128_255": 34038,
- "tx_64": 28592,
- "rx_64": 28489,
- "tx_pkts": 51621,
- "rx_1519_9k": 28591,
- "tx_512_1023": 50345,
- "rx_1024_1518": 34075,
- "tx_65_127": 31255,
- "rx_65_127": 31238,
- "tx_1519_9k": 28546,
- "tx_1024_1518": 33967,
- "rx_512_1023": 50252
- }
- }
-}
-```
-Once the generation of simulated statistics has been confirmed we validate how often the stats are being posted to kafka prior to the next step which is to change the frequency with which the stats are bing sampled. The following command will establish the sampling interval.
-
-```
-avg=0;last=0;for i in `kafkacat -b localhost:32778 -C -o -10 -c 10 -t voltha.kpis | grep 'simulated_olt' | jq -r '.ts'`; do if [ $last -eq 0 ]; then last=$i; else if [ $avg -eq 0 ]; then avg=`expr $i - $last`; else avg=`expr \( $avg + $i - $last \) \/ 2`; fi; last=$i; fi; done; echo $avg; unset avg; unset last
-```
-```
-15
-```
-The default set by the simulated OLT is to pretend to sample metrics every 15 seconds and publish them to kafka. This can be changed by using the performance monitoring configuration functionality. Swithch back to the window running the voltha cli and enter device command mode for the simulated OLT.
-
-```
-(voltha) devices
-```
-
-```
-Devices:
-+--------------+---------------+-------------------+-------------+-------------+----------------+
-| id | type | mac_address | admin_state | oper_status | connect_status |
-+--------------+---------------+-------------------+-------------+-------------+----------------+
-| eecd8f5327bc | simulated_olt | 00:0c:e2:31:40:00 | ENABLED | ACTIVE | REACHABLE |
-+--------------+---------------+-------------------+-------------+-------------+----------------+
-(voltha)
-```
-
-Using the value in the id column, enter device command mode for the device
-```
-(voltha) device eecd8f5327bc
-```
-
-```
-(device eecd8f5327bc)
-```
-
-Now display the current performance management configuration of the device. Your device id will be different than the one used throughout these examples.
-
-```
-(device eecd8f5327bc) perf_config
-```
-
-```
-PM Config:
-+---------------+-------+
-| field | value |
-+---------------+-------+
-| default_freq | 150 |
-| grouped | False |
-| freq_override | False |
-+---------------+-------+
-Supported metrics:
-+--------------+---------+---------+
-| name | enabled | type |
-+--------------+---------+---------+
-| rx_1024_1518 | True | COUNTER |
-| rx_128_255 | True | COUNTER |
-| rx_1519_9k | True | COUNTER |
-| rx_256_511 | True | COUNTER |
-| rx_512_1023 | True | COUNTER |
-| rx_64 | True | COUNTER |
-| rx_65_127 | True | COUNTER |
-| rx_bytes | True | COUNTER |
-| rx_pkts | True | COUNTER |
-| tx_1024_1518 | True | COUNTER |
-| tx_128_255 | True | COUNTER |
-| tx_1519_9k | True | COUNTER |
-| tx_256_511 | True | COUNTER |
-| tx_512_1023 | True | COUNTER |
-| tx_64 | True | COUNTER |
-| tx_65_127 | True | COUNTER |
-| tx_bytes | True | COUNTER |
-| tx_pkts | True | COUNTER |
-+--------------+---------+---------+
-(device eecd8f5327bc)
-```
-
-As shown, the default_freq which is the sampling frequency is set to 150 10^ths^ of a second. View the help to determine how to change that.
-
-```
-(device eecd8f5327bc) help perf_config
-```
-
-```
-perfo_config [show | set | commit | reset] [-f <default frequency>] [-e <metric/group
- name>] [-d <metric/group name>] [-o <metric/group name> <override
- frequency>]
-Changes made by set are held locally until a commit or reset command is issued.
-A commit command will write the configuration to the device and it takes effect
-immediately. The reset command will undo any changes sinc the start of the
-device session.
-
-If grouped is true then the -d, -e and -o commands refer to groups and not
-individual metrics.
-(device eecd8f5327bc)
-```
-
-As shown in the help using set with the -f option will change the default_freq so lets set that to 5 seconds or 50 10^ths^ of a second.
-
-```
-(device eecd8f5327bc) perf_config set -f 50
-```
-
-```
-Success
-(device eecd8f5327bc)
-```
-
-Lets verify that the chnages have indeed been saved to the edit buffer.
-
-```
-(device eecd8f5327bc) perf_config show
-```
-
-```
-PM Config:
-+---------------+-------+
-| field | value |
-+---------------+-------+
-| default_freq | 50 |
-| grouped | False |
-| freq_override | False |
-+---------------+-------+
-Supported metrics:
-+--------------+---------+---------+
-| name | enabled | type |
-+--------------+---------+---------+
-| rx_1024_1518 | True | COUNTER |
-| rx_128_255 | True | COUNTER |
-| rx_1519_9k | True | COUNTER |
-| rx_256_511 | True | COUNTER |
-| rx_512_1023 | True | COUNTER |
-| rx_64 | True | COUNTER |
-| rx_65_127 | True | COUNTER |
-| rx_bytes | True | COUNTER |
-| rx_pkts | True | COUNTER |
-| tx_1024_1518 | True | COUNTER |
-| tx_128_255 | True | COUNTER |
-| tx_1519_9k | True | COUNTER |
-| tx_256_511 | True | COUNTER |
-| tx_512_1023 | True | COUNTER |
-| tx_64 | True | COUNTER |
-| tx_65_127 | True | COUNTER |
-| tx_bytes | True | COUNTER |
-| tx_pkts | True | COUNTER |
-+--------------+---------+---------+
-(device eecd8f5327bc)
-```
-
-The default_freq is now set to 5o 10^ths^ of a second. This change has not been applied yet. In order to apply the change, it must be committed. Lets do that now.
-
-```
-(device eecd8f5327bc) perf_config commit
-```
-
-```
-PM Config:
-+---------------+-------+
-| field | value |
-+---------------+-------+
-| default_freq | 50 |
-| grouped | False |
-| freq_override | False |
-+---------------+-------+
-Supported metrics:
-+--------------+---------+---------+
-| name | enabled | type |
-+--------------+---------+---------+
-| rx_1024_1518 | True | COUNTER |
-| rx_128_255 | True | COUNTER |
-| rx_1519_9k | True | COUNTER |
-| rx_256_511 | True | COUNTER |
-| rx_512_1023 | True | COUNTER |
-| rx_64 | True | COUNTER |
-| rx_65_127 | True | COUNTER |
-| rx_bytes | True | COUNTER |
-| rx_pkts | True | COUNTER |
-| tx_1024_1518 | True | COUNTER |
-| tx_128_255 | True | COUNTER |
-| tx_1519_9k | True | COUNTER |
-| tx_256_511 | True | COUNTER |
-| tx_512_1023 | True | COUNTER |
-| tx_64 | True | COUNTER |
-| tx_65_127 | True | COUNTER |
-| tx_bytes | True | COUNTER |
-| tx_pkts | True | COUNTER |
-+--------------+---------+---------+
-(device eecd8f5327bc)
-```
-
-Now after waiting 30 seconds or so to ensure we don't average in any older sampling intervals let's go back to a linux window and check and see how often the metrics are being sampled.
-
-```
-voltha$ avg=0;last=0;for i in `kafkacat -b localhost:32778 -C -o -10 -c 10 -t voltha.kpis | grep 'simulated_olt' | jq -r '.ts'`; do if [ $last -eq 0 ]; then last=$i; else if [ $avg -eq 0 ]; then avg=`expr $i - $last`; else avg=`expr \( $avg + $i - $last \) \/ 2`; fi; last=$i; fi; done; echo $avg; unset avg; unset last
-```
-
-```
-5
-voltha$
-```
-
-The change has taken effect and the metrics are now being sampled every 5 seconds. Now lets show how certain metrics can be disabled from the kafka output. Lets say that we no longer want to see any jumbo frame counters. Go back to the voltha cli window and get the help for the `perf_config` command again. Looking at the command using set with the -d options disables metrics and using the set command with -e options enables metrics. To disable both rx and tx metrics for 1519_9k issue the following command in the voltha cli.
-
-```
-(device eecd8f5327bc) perf_config set -d rx_1519_9k -d tx_1519_9k
-```
-
-```
-Success
-(device eecd8f5327bc)
-```
-
-Now view the configuration to validate that the requested changes have been applied to the edit buffer.
-
-```
-(device eecd8f5327bc) perf_config show
-```
-
-```
-PM Config:
-+---------------+-------+
-| field | value |
-+---------------+-------+
-| default_freq | 50 |
-| grouped | False |
-| freq_override | False |
-+---------------+-------+
-Supported metrics:
-+--------------+---------+---------+
-| name | enabled | type |
-+--------------+---------+---------+
-| rx_1024_1518 | True | COUNTER |
-| rx_128_255 | True | COUNTER |
-| rx_1519_9k | False | COUNTER |
-| rx_256_511 | True | COUNTER |
-| rx_512_1023 | True | COUNTER |
-| rx_64 | True | COUNTER |
-| rx_65_127 | True | COUNTER |
-| rx_bytes | True | COUNTER |
-| rx_pkts | True | COUNTER |
-| tx_1024_1518 | True | COUNTER |
-| tx_128_255 | True | COUNTER |
-| tx_1519_9k | False | COUNTER |
-| tx_256_511 | True | COUNTER |
-| tx_512_1023 | True | COUNTER |
-| tx_64 | True | COUNTER |
-| tx_65_127 | True | COUNTER |
-| tx_bytes | True | COUNTER |
-| tx_pkts | True | COUNTER |
-+--------------+---------+---------+
-(device eecd8f5327bc)
-```
-
-The changes are there as expected. Now commit them using the commit command.
-
-```
-(device eecd8f5327bc) perf_config commit
-```
-
-```
-PM Config:
-+---------------+-------+
-| field | value |
-+---------------+-------+
-| default_freq | 50 |
-| grouped | False |
-| freq_override | False |
-+---------------+-------+
-Supported metrics:
-+--------------+---------+---------+
-| name | enabled | type |
-+--------------+---------+---------+
-| rx_1024_1518 | True | COUNTER |
-| rx_128_255 | True | COUNTER |
-| rx_1519_9k | False | COUNTER |
-| rx_256_511 | True | COUNTER |
-| rx_512_1023 | True | COUNTER |
-| rx_64 | True | COUNTER |
-| rx_65_127 | True | COUNTER |
-| rx_bytes | True | COUNTER |
-| rx_pkts | True | COUNTER |
-| tx_1024_1518 | True | COUNTER |
-| tx_128_255 | True | COUNTER |
-| tx_1519_9k | False | COUNTER |
-| tx_256_511 | True | COUNTER |
-| tx_512_1023 | True | COUNTER |
-| tx_64 | True | COUNTER |
-| tx_65_127 | True | COUNTER |
-| tx_bytes | True | COUNTER |
-| tx_pkts | True | COUNTER |
-+--------------+---------+---------+
-(device eecd8f5327bc)
-```
-
-Now lets validate that the metrics that have been set to false will no longer be published to kafka. Moving back to the Linux window use the following command:
-
-```
-voltha$ kafkacat -b localhost:32778 -C -o -1 -c 1 -t voltha.kpis | jq '.prefixes'
-```
-
-```
-{
- "voltha.simulated_olt.eecd8f5327bc.pon": {
- "metrics": {
- "rx_256_511": 66994,
- "tx_128_255": 47787,
- "tx_256_511": 66965,
- "tx_pkts": 72684,
- "rx_bytes": 72795037,
- "rx_pkts": 72708,
- "rx_128_255": 47700,
- "tx_64": 40156,
- "rx_64": 40172,
- "tx_512_1023": 70724,
- "rx_1024_1518": 47800,
- "tx_65_127": 44018,
- "rx_65_127": 44011,
- "tx_bytes": 72736980,
- "tx_1024_1518": 47854,
- "rx_512_1023": 70773
- }
- },
- "voltha.simulated_olt.eecd8f5327bc": {
- "metrics": {
- "cpu_util": 23.933588409473266,
- "buffer_util": 12.861151886751806
- }
- },
- "voltha.simulated_olt.eecd8f5327bc.nni": {
- "metrics": {
- "rx_256_511": 67001,
- "tx_128_255": 47860,
- "tx_256_511": 66834,
- "tx_pkts": 72637,
- "rx_bytes": 72658405,
- "rx_pkts": 72718,
- "rx_128_255": 47833,
- "tx_64": 40188,
- "rx_64": 40123,
- "tx_512_1023": 70768,
- "rx_1024_1518": 47852,
- "tx_65_127": 43975,
- "rx_65_127": 43933,
- "tx_bytes": 72669736,
- "tx_1024_1518": 47736,
- "rx_512_1023": 70703
- }
- }
-}
-```
-
-As expected both rx_1519_9k and tx_1519_9k are no longer being reported for any interface on the device.
-
-
-This concludes this section of the test plan.
\ No newline at end of file
+# P01 - Performance management configuration
+
+## Test objective
+
+To demonstrate the ability to configure performance management using the *simulated-olt*.
+
+* Demonstrate the ability to change the frequency with which the stats are sampled and posted to kafka
+* Demonstrate the ability to selectively disable and enable specific stats
+* Demonstrate how the stats can be queried.
+
+## Test configuration
+
+* The Voltha enseble is running per the deployment instructions.
+
+## Test procedure
+
+Start the voltha cli and add the simulated OLT.
+
+```shell
+ ./cli/main.py -L
+ _ _ _ ___ _ ___
+__ _____| | |_| |_ __ _ / __| | |_ _|
+\ V / _ \ | _| ' \/ _` | | (__| |__ | |
+ \_/\___/_|\__|_||_\__,_| \___|____|___|
+(to exit type quit or hit Ctrl-D)
+(voltha)
+```
+
+Ensure that voltha is operating correctly:
+
+```shell
+health
+```
+
+```json
+{
+ "state": "HEALTHY"
+}
+```
+
+Preprovision and enable the simulated OLT
+
+```shell
+(voltha) preprovision_olt
+success (device id = eecd8f5327bc)
+(voltha) enable
+enabling eecd8f5327bc
+waiting for device to be enabled...
+success (logical device id = 1)
+(voltha)
+```
+
+The device Id will be different from the device id shown above.
+
+In a different window, verify that the simulated stats are now being posted to the Kafak bus. First determine the port hosting the kafka broker:
+
+```shell
+$ docker inspect compose_kafka_1 | jq -r '.[0].NetworkSettings.Ports["9092/tcp"][0]["HostPort"]'
+32778
+```
+
+Using this port, query the kafka broker for topics
+
+```shell
+kafkacat -b localhost:32778 -L
+Metadata for all topics (from broker -1: localhost:32778/bootstrap):
+ 1 brokers:
+ broker 1001 at 10.0.2.15:32778
+ 5 topics:
+ topic "voltha.alarms" with 1 partitions:
+ partition 0, leader 1001, replicas: 1001, isrs: 1001
+ topic "voltha.kpis" with 1 partitions:
+ partition 0, leader 1001, replicas: 1001, isrs: 1001
+ topic "voltha.events" with 1 partitions:
+ partition 0, leader 1001, replicas: 1001, isrs: 1001
+ topic "voltha.heartbeat" with 1 partitions:
+ partition 0, leader 1001, replicas: 1001, isrs: 1001
+```
+
+The topic of interest for this test is the voltha.kpis topic. So now query the topic to ensure that the simulated OLT is generating stats.
+
+```shell
+kafkacat -b localhost:32778 -C -o -1 -c 1 -t voltha.kpis | jq '.prefixes'
+```
+
+```json
+{
+ "voltha.simulated_olt.eecd8f5327bc.pon": {
+ "metrics": {
+ "rx_256_511": 47629,
+ "tx_128_255": 33976,
+ "tx_256_511": 47606,
+ "tx_bytes": 51704532,
+ "rx_bytes": 51757379,
+ "rx_pkts": 51646,
+ "rx_128_255": 33901,
+ "tx_64": 28552,
+ "rx_64": 28590,
+ "tx_pkts": 51668,
+ "rx_1519_9k": 28502,
+ "tx_512_1023": 50295,
+ "rx_1024_1518": 33998,
+ "tx_65_127": 31313,
+ "rx_65_127": 31280,
+ "tx_1519_9k": 28505,
+ "tx_1024_1518": 34027,
+ "rx_512_1023": 50307
+ }
+ },
+ "voltha.simulated_olt.eecd8f5327bc": {
+ "metrics": {
+ "cpu_util": 24.542841249401473,
+ "buffer_util": 18.404615469439612
+ }
+ },
+ "voltha.simulated_olt.eecd8f5327bc.nni": {
+ "metrics": {
+ "rx_256_511": 47649,
+ "tx_128_255": 34071,
+ "tx_256_511": 47569,
+ "tx_bytes": 51634215,
+ "rx_bytes": 51665858,
+ "rx_pkts": 51686,
+ "rx_128_255": 34038,
+ "tx_64": 28592,
+ "rx_64": 28489,
+ "tx_pkts": 51621,
+ "rx_1519_9k": 28591,
+ "tx_512_1023": 50345,
+ "rx_1024_1518": 34075,
+ "tx_65_127": 31255,
+ "rx_65_127": 31238,
+ "tx_1519_9k": 28546,
+ "tx_1024_1518": 33967,
+ "rx_512_1023": 50252
+ }
+ }
+}
+```
+
+Once the generation of simulated statistics has been confirmed we validate how often the stats are being posted to kafka prior to the next step which is to change the frequency with which the stats are bing sampled. The following command will establish the sampling interval.
+
+```shell
+avg=0;last=0;for i in `kafkacat -b localhost:32778 -C -o -10 -c 10 -t voltha.kpis | grep 'simulated_olt' | jq -r '.ts'`; do if [ $last -eq 0 ]; then last=$i; else if [ $avg -eq 0 ]; then avg=`expr $i - $last`; else avg=`expr \( $avg + $i - $last \) \/ 2`; fi; last=$i; fi; done; echo $avg; unset avg; unset last
+```
+
+```shell
+15
+```
+
+The default set by the simulated OLT is to pretend to sample metrics every 15 seconds and publish them to kafka. This can be changed by using the performance monitoring configuration functionality. Swithch back to the window running the voltha cli and enter device command mode for the simulated OLT.
+
+```shell
+(voltha) devices
+
++--------------+---------------+-------------------+-------------+-------------+----------------+
+| id | type | mac_address | admin_state | oper_status | connect_status |
++--------------+---------------+-------------------+-------------+-------------+----------------+
+| eecd8f5327bc | simulated_olt | 00:0c:e2:31:40:00 | ENABLED | ACTIVE | REACHABLE |
++--------------+---------------+-------------------+-------------+-------------+----------------+
+```
+
+Using the value in the id column, enter device command mode for the device
+```shell
+(voltha) device eecd8f5327bc
+```
+
+```shell
+(device eecd8f5327bc)
+```
+
+Now display the current performance management configuration of the device. Your device id will be different than the one used throughout these examples.
+
+```shell
+(device eecd8f5327bc) perf_config
+```
+
+```shell
+PM Config:
++---------------+-------+
+| field | value |
++---------------+-------+
+| default_freq | 150 |
+| grouped | False |
+| freq_override | False |
++---------------+-------+
+
+Supported metrics:
++--------------+---------+---------+
+| name | enabled | type |
++--------------+---------+---------+
+| rx_1024_1518 | True | COUNTER |
+| rx_128_255 | True | COUNTER |
+| rx_1519_9k | True | COUNTER |
+| rx_256_511 | True | COUNTER |
+| rx_512_1023 | True | COUNTER |
+| rx_64 | True | COUNTER |
+| rx_65_127 | True | COUNTER |
+| rx_bytes | True | COUNTER |
+| rx_pkts | True | COUNTER |
+| tx_1024_1518 | True | COUNTER |
+| tx_128_255 | True | COUNTER |
+| tx_1519_9k | True | COUNTER |
+| tx_256_511 | True | COUNTER |
+| tx_512_1023 | True | COUNTER |
+| tx_64 | True | COUNTER |
+| tx_65_127 | True | COUNTER |
+| tx_bytes | True | COUNTER |
+| tx_pkts | True | COUNTER |
++--------------+---------+---------+
+(device eecd8f5327bc)
+```
+
+As shown, the default_freq which is the sampling frequency is set to 150 10^ths^ of a second. View the help to determine how to change that.
+
+```shell
+(device eecd8f5327bc) help perf_config
+```
+
+```shell
+perfo_config [show | set | commit | reset] [-f <default frequency>] [-e <metric/group name>] [-d <metric/group name>] [-o <metric/group name> <override frequency>]
+
+Changes made by set are held locally until a commit or reset command is issued.
+A commit command will write the configuration to the device and it takes effect
+immediately. The reset command will undo any changes sinc the start of the
+device session.
+
+If grouped is true then the -d, -e and -o commands refer to groups and not
+individual metrics.
+(device eecd8f5327bc)
+```
+
+As shown in the help using set with the -f option will change the default_freq so lets set that to 5 seconds or 50 10^ths^ of a second.
+
+```shell
+(device eecd8f5327bc) perf_config set -f 50
+```
+
+```shell
+Success
+(device eecd8f5327bc)
+```
+
+Lets verify that the chnages have indeed been saved to the edit buffer.
+
+```shell
+(device eecd8f5327bc) perf_config show
+```
+
+```shell
+PM Config:
++---------------+-------+
+| field | value |
++---------------+-------+
+| default_freq | 50 |
+| grouped | False |
+| freq_override | False |
++---------------+-------+
+
+Supported metrics:
++--------------+---------+---------+
+| name | enabled | type |
++--------------+---------+---------+
+| rx_1024_1518 | True | COUNTER |
+| rx_128_255 | True | COUNTER |
+| rx_1519_9k | True | COUNTER |
+| rx_256_511 | True | COUNTER |
+| rx_512_1023 | True | COUNTER |
+| rx_64 | True | COUNTER |
+| rx_65_127 | True | COUNTER |
+| rx_bytes | True | COUNTER |
+| rx_pkts | True | COUNTER |
+| tx_1024_1518 | True | COUNTER |
+| tx_128_255 | True | COUNTER |
+| tx_1519_9k | True | COUNTER |
+| tx_256_511 | True | COUNTER |
+| tx_512_1023 | True | COUNTER |
+| tx_64 | True | COUNTER |
+| tx_65_127 | True | COUNTER |
+| tx_bytes | True | COUNTER |
+| tx_pkts | True | COUNTER |
++--------------+---------+---------+
+(device eecd8f5327bc)
+```
+
+The default_freq is now set to 5o 10^ths^ of a second. This change has not been applied yet. In order to apply the change, it must be committed. Lets do that now.
+
+```shell
+(device eecd8f5327bc) perf_config commit
+```
+
+```shell
+PM Config:
++---------------+-------+
+| field | value |
++---------------+-------+
+| default_freq | 50 |
+| grouped | False |
+| freq_override | False |
++---------------+-------+
+
+Supported metrics:
++--------------+---------+---------+
+| name | enabled | type |
++--------------+---------+---------+
+| rx_1024_1518 | True | COUNTER |
+| rx_128_255 | True | COUNTER |
+| rx_1519_9k | True | COUNTER |
+| rx_256_511 | True | COUNTER |
+| rx_512_1023 | True | COUNTER |
+| rx_64 | True | COUNTER |
+| rx_65_127 | True | COUNTER |
+| rx_bytes | True | COUNTER |
+| rx_pkts | True | COUNTER |
+| tx_1024_1518 | True | COUNTER |
+| tx_128_255 | True | COUNTER |
+| tx_1519_9k | True | COUNTER |
+| tx_256_511 | True | COUNTER |
+| tx_512_1023 | True | COUNTER |
+| tx_64 | True | COUNTER |
+| tx_65_127 | True | COUNTER |
+| tx_bytes | True | COUNTER |
+| tx_pkts | True | COUNTER |
++--------------+---------+---------+
+(device eecd8f5327bc)
+```
+
+Now after waiting 30 seconds or so to ensure we don't average in any older sampling intervals let's go back to a linux window and check and see how often the metrics are being sampled.
+
+```shell
+voltha$ avg=0;last=0;for i in `kafkacat -b localhost:32778 -C -o -10 -c 10 -t voltha.kpis | grep 'simulated_olt' | jq -r '.ts'`; do if [ $last -eq 0 ]; then last=$i; else if [ $avg -eq 0 ]; then avg=`expr $i - $last`; else avg=`expr \( $avg + $i - $last \) \/ 2`; fi; last=$i; fi; done; echo $avg; unset avg; unset last 5
+```
+
+The change has taken effect and the metrics are now being sampled every 5 seconds. Now lets show how certain metrics can be disabled from the kafka output. Lets say that we no longer want to see any jumbo frame counters. Go back to the voltha cli window and get the help for the `perf_config` command again. Looking at the command using set with the -d options disables metrics and using the set command with -e options enables metrics. To disable both rx and tx metrics for 1519_9k issue the following command in the voltha cli.
+
+```shell
+(device eecd8f5327bc) perf_config set -d rx_1519_9k -d tx_1519_9k
+```
+
+```shell
+Success
+(device eecd8f5327bc)
+```
+
+Now view the configuration to validate that the requested changes have been applied to the edit buffer.
+
+```shell
+(device eecd8f5327bc) perf_config show
+```
+
+```shell
+PM Config:
++---------------+-------+
+| field | value |
++---------------+-------+
+| default_freq | 50 |
+| grouped | False |
+| freq_override | False |
++---------------+-------+
+
+Supported metrics:
++--------------+---------+---------+
+| name | enabled | type |
++--------------+---------+---------+
+| rx_1024_1518 | True | COUNTER |
+| rx_128_255 | True | COUNTER |
+| rx_1519_9k | False | COUNTER |
+| rx_256_511 | True | COUNTER |
+| rx_512_1023 | True | COUNTER |
+| rx_64 | True | COUNTER |
+| rx_65_127 | True | COUNTER |
+| rx_bytes | True | COUNTER |
+| rx_pkts | True | COUNTER |
+| tx_1024_1518 | True | COUNTER |
+| tx_128_255 | True | COUNTER |
+| tx_1519_9k | False | COUNTER |
+| tx_256_511 | True | COUNTER |
+| tx_512_1023 | True | COUNTER |
+| tx_64 | True | COUNTER |
+| tx_65_127 | True | COUNTER |
+| tx_bytes | True | COUNTER |
+| tx_pkts | True | COUNTER |
++--------------+---------+---------+
+(device eecd8f5327bc)
+```
+
+The changes are there as expected. Now commit them using the commit command.
+
+```shell
+(device eecd8f5327bc) perf_config commit
+```
+
+```shell
+PM Config:
++---------------+-------+
+| field | value |
++---------------+-------+
+| default_freq | 50 |
+| grouped | False |
+| freq_override | False |
++---------------+-------+
+
+Supported metrics:
++--------------+---------+---------+
+| name | enabled | type |
++--------------+---------+---------+
+| rx_1024_1518 | True | COUNTER |
+| rx_128_255 | True | COUNTER |
+| rx_1519_9k | False | COUNTER |
+| rx_256_511 | True | COUNTER |
+| rx_512_1023 | True | COUNTER |
+| rx_64 | True | COUNTER |
+| rx_65_127 | True | COUNTER |
+| rx_bytes | True | COUNTER |
+| rx_pkts | True | COUNTER |
+| tx_1024_1518 | True | COUNTER |
+| tx_128_255 | True | COUNTER |
+| tx_1519_9k | False | COUNTER |
+| tx_256_511 | True | COUNTER |
+| tx_512_1023 | True | COUNTER |
+| tx_64 | True | COUNTER |
+| tx_65_127 | True | COUNTER |
+| tx_bytes | True | COUNTER |
+| tx_pkts | True | COUNTER |
++--------------+---------+---------+
+(device eecd8f5327bc)
+```
+
+Now lets validate that the metrics that have been set to false will no longer be published to kafka. Moving back to the Linux window use the following command:
+
+```shell
+voltha$ kafkacat -b localhost:32778 -C -o -1 -c 1 -t voltha.kpis | jq '.prefixes'
+```
+
+```json
+{
+ "voltha.simulated_olt.eecd8f5327bc.pon": {
+ "metrics": {
+ "rx_256_511": 66994,
+ "tx_128_255": 47787,
+ "tx_256_511": 66965,
+ "tx_pkts": 72684,
+ "rx_bytes": 72795037,
+ "rx_pkts": 72708,
+ "rx_128_255": 47700,
+ "tx_64": 40156,
+ "rx_64": 40172,
+ "tx_512_1023": 70724,
+ "rx_1024_1518": 47800,
+ "tx_65_127": 44018,
+ "rx_65_127": 44011,
+ "tx_bytes": 72736980,
+ "tx_1024_1518": 47854,
+ "rx_512_1023": 70773
+ }
+ },
+ "voltha.simulated_olt.eecd8f5327bc": {
+ "metrics": {
+ "cpu_util": 23.933588409473266,
+ "buffer_util": 12.861151886751806
+ }
+ },
+ "voltha.simulated_olt.eecd8f5327bc.nni": {
+ "metrics": {
+ "rx_256_511": 67001,
+ "tx_128_255": 47860,
+ "tx_256_511": 66834,
+ "tx_pkts": 72637,
+ "rx_bytes": 72658405,
+ "rx_pkts": 72718,
+ "rx_128_255": 47833,
+ "tx_64": 40188,
+ "rx_64": 40123,
+ "tx_512_1023": 70768,
+ "rx_1024_1518": 47852,
+ "tx_65_127": 43975,
+ "rx_65_127": 43933,
+ "tx_bytes": 72669736,
+ "tx_1024_1518": 47736,
+ "rx_512_1023": 70703
+ }
+ }
+}
+```
+
+As expected both rx_1519_9k and tx_1519_9k are no longer being reported for any interface on the device.
+
+This concludes this section of the test plan.
+
diff --git a/docs/manuals/user/labtests/P01_previews_kpi_collection.md b/docs/manuals/user/labtests/P01_previews_kpi_collection.md
index 22c5b62..89a9bd2 100644
--- a/docs/manuals/user/labtests/P01_previews_kpi_collection.md
+++ b/docs/manuals/user/labtests/P01_previews_kpi_collection.md
@@ -1,3 +1,3 @@
-## P1 - KPI Collection Through Voltha
+# P1 - KPI Collection Through Voltha
[Nathan to help when Tibit is submitting KPI metrics]
diff --git a/docs/manuals/user/labtests/P02_previews_yang_and_netconf.md b/docs/manuals/user/labtests/P02_previews_yang_and_netconf.md
index da356e5..9fb99ef 100644
--- a/docs/manuals/user/labtests/P02_previews_yang_and_netconf.md
+++ b/docs/manuals/user/labtests/P02_previews_yang_and_netconf.md
@@ -1,3 +1,3 @@
-## P2 - Voltha's Netconf API and Yang Definitions
+# P2 - Voltha's Netconf API and Yang Definitions
[Khen to fill with content]
diff --git a/docs/manuals/user/labtests/P03_previews_scale_out.md b/docs/manuals/user/labtests/P03_previews_scale_out.md
index eedfe2f..f6580d7 100644
--- a/docs/manuals/user/labtests/P03_previews_scale_out.md
+++ b/docs/manuals/user/labtests/P03_previews_scale_out.md
@@ -1 +1 @@
-## P3 - Voltha's Partial Readiness for Scale-out
+# P3 - Voltha's Partial Readiness for Scale-out
diff --git a/docs/manuals/user/labtests/README.md b/docs/manuals/user/labtests/README.md
index d4e34d6..215eb72 100644
--- a/docs/manuals/user/labtests/README.md
+++ b/docs/manuals/user/labtests/README.md
@@ -2,56 +2,44 @@
## Purpose
-The purpose of this section is to assist in potential lab testing of Voltha
-and Voltha-certified PON hardware solutions.
+The purpose of this section is to assist in potential lab testing of Voltha and Voltha-certified PON hardware solutions.
## Approach and Outline
-Test exercises are currently grouped based on scope. Although a few tests require nothing more
-that a single Linux server, most tests require a hardware installation, a
-"test POD," available.
+Test exercises are currently grouped based on scope. Although a few tests require nothing more than a single Linux server, most tests require a hardware installation, a "test POD," available.
Specifically, we structure the test process as follows:
* [Test POD and requirements](requirements.md)
* [Preparations](preparations.md)
* [Voltha deployment and related readiness tests](V00_voltha.md)
-* [Voltha operating on a software simulated PON network ("ponsim")](S00_ponsim_tests.md)
- -- (optional) this is useful if no real PON hardware is available and it provides
- a dataplane capable PON network which is simulated in software
+* [Voltha operating on a software simulated PON network ("ponsim")](S00_ponsim_tests.md) (optional) this is useful if no real PON hardware is available and it provides a dataplane capable PON network which is simulated in software
* [Voltha working with Broadcom Maple based OLT and Broadcom ONU(s)](M00_maple_olt_tests.md)
* [Voltha working with Tibit MicroOLT and certified ONUs](T00_tibit_olt_tests.md)
* [Additional tests show-casing upcoming features of Voltha based PON solutions](P00_previews.md)
-
## Recommended Test Method
-Most of the activation steps desribed in the test procedure can be directly
-copy-pasted from the test document to the respecive test terminal window.
+Most of the activation steps desribed in the test procedure can be directly copy-pasted from the test document to the respecive test terminal window.
-For best outcome, we recommend bringing up this test documentation on-line.
-There are two ways of doing that:
+For best outcome, we recommend bringing up this test documentation on-line. There are two ways of doing that:
-1. In a PDF document viewer
-1. (Recommended) In a Web browser in gitbook reading mode. To do this, you
-need access to the HTML-compiled version of this gitbook document. You can
-easily do it on a Voltha development host, following these steps:
+* In a PDF document viewer
+* (Recommended) In a Web browser in gitbook reading mode. To do this, you need access to the HTML-compiled version of this gitbook document. You can easily do it on a Voltha development host, following these steps:
- ```
- cd $VOLTHA_BASE
- cd docs
- make serve
- ```
+```shell
+cd $VOLTHA_BASE
+cd docs
+make serve
+```
- This will build the documentation into an HTML dir structure and will start
- serving it up on the [http://localhost:4000](http://localhost:4000) URL.
+This will build the documentation into an HTML dir structure and will start serving it up on the <http://localhost:4000> URL.
- If you need remote access from the browser to the server where the doc is
- generated, Ctrl-C the ```make serve``` line, and instead do as follows:
+If you need remote access from the browser to the server where the doc is generated, Ctrl-C the *make serve* line, and instead do as follows:
- ```
- cd _book
- python -m SimpleHTTPServer.py 4000
- ```
- You shall now be able to reach the docs using the http://localhost:4000
- URL.
+```shell
+cd _book
+python -m SimpleHTTPServer.py 4000
+```
+
+You shall now be able to reach the docs using the <http://localhost:4000> URL.
diff --git a/docs/manuals/user/labtests/S00_ponsim_tests.md b/docs/manuals/user/labtests/S00_ponsim_tests.md
index 545db80..b0c1d49 100644
--- a/docs/manuals/user/labtests/S00_ponsim_tests.md
+++ b/docs/manuals/user/labtests/S00_ponsim_tests.md
@@ -5,4 +5,4 @@
* [S3 - Verify EAPOL RG Authentication](S03_ponsim_eapol_auth.md)
* [S4 - Verify DHCP Lookup](S04_ponsim_verify_dhcp.md)
* [S5 - Verify Unicast Access](S05_ponsim_tests_unicast.md)
-* [S6 - Verify IGMP Handling](S06_ponsim_tests_multicast.md)
+* [S6 - Verify IGMP Handling](S06_ponsim_tests_multicast.md)
diff --git a/docs/manuals/user/labtests/S00_ponsim_tests_original.md b/docs/manuals/user/labtests/S00_ponsim_tests_original.md
index 2fc79cf..019bf70 100644
--- a/docs/manuals/user/labtests/S00_ponsim_tests_original.md
+++ b/docs/manuals/user/labtests/S00_ponsim_tests_original.md
@@ -1,9 +1,9 @@
# PONSIM Tests
-
The tests are grouped into the following categories:
Manual step-by-step provisioning:
+
* [S1 - Preprovision and Activate OLT](S01_ponsim_tests_launch_and_activate.md)
* [M3 - Manually Install EAPOL Forwarding Flows](S02_ponsim_tests_eapol_install.md)
* [M4 - Test EAPOL In/Out Forwarding with OLT-OFTEST](S03_ponsim_tests_eapol_in_out.md)
@@ -12,6 +12,7 @@
* [M7 - Test IGMP and multicast (Video) streams](S06_ponsim_tests_multicast.md)
ONOS-base System Test
+
* [M8 - Reset Manually Added Flows and Launch ONOS](M08_maple_olt_tests_start_onos.md)
* [M9 - Verify RG Authentication Scenario](M09_maple_olt_tests_verify_authentication.md)
* [M10 - Verify DHCP Lookup](M10_maple_olt_tests_verify_dhcp.md)
diff --git a/docs/manuals/user/labtests/S01_ponsim_tests_launch_and_activate.md b/docs/manuals/user/labtests/S01_ponsim_tests_launch_and_activate.md
index d7ec9b3..039d7e8 100644
--- a/docs/manuals/user/labtests/S01_ponsim_tests_launch_and_activate.md
+++ b/docs/manuals/user/labtests/S01_ponsim_tests_launch_and_activate.md
@@ -1,20 +1,20 @@
-## S1 - Preprovision and Activate PONSIM Voltha
+# S1 - Preprovision and Activate PONSIM Voltha
-### Test Objective
+## Test Objective
* Purpose of this test is to verify new PONSIM OLT can be added and activated from VOLTHA, including;
- * Correct simulated PON environment
- * Logical device visible in VOLTHA CLI
+ * Correct simulated PON environment
+ * Logical device visible in VOLTHA CLI
-### Test Configuration
+## Test Configuration
* VOLTHA ensemble running as per [deployment instructions](V01_voltha_bringup_deploy.md).
-### Test Procedure
+## Test Procedure
Start off by starting ponsim, make sure you do this as root as ponsim creates virtual interfaces and adds some of them into the _ponmgmt_ bridge on the system.
-```
+```shell
sudo -s
. ./env.sh
./ponsim/main.py -v
@@ -22,13 +22,13 @@
PONSIM should now be running; check this by doing the following.
-```
+```shell
sudo netstat -uteap | grep python
```
-and you should see;
+and you should see
-```
+```shell
tcp6 0 0 [::]:50060 [::]:* LISTEN root 256217 19162/python
```
@@ -36,21 +36,20 @@
Next, let's check that PONSIM initialized correctly and added the correct interfaces to the _ponmgmt_ bridge.
-```
- brctl show ponmgmt
+```shell
+brctl show ponmgmt
```
This should return the following output:
-```
-bridge name bridge id STP enabled interfaces
-ponmgmt 8000.02429b8631d5 no pon1_0
- veth24f4706 (<- name may vary)
+```shell
+bridge name bridge id STP enabled interfaces
+ponmgmt 8000.02429b8631d5 no pon1_0veth24f4706 (<- name may vary)
```
At this point we are ready to launch the voltha CLI and add the simulated OLT and ONU.
-```
+```shell
./cli/main.py -L
_ _ _ ___ _ ___
__ _____| | |_| |_ __ _ / __| | |_ _|
@@ -62,13 +61,13 @@
We have now a CLI to voltha, let's check if voltha is healthy. Enter the following at the CLI prompt.
-```
- health
+```shell
+health
```
which should return;
-```
+```json
{
"state": "HEALTHY"
}
@@ -76,13 +75,13 @@
Now we can provision the PONSIM OLT and ONU in voltha. This is done in the voltha CLI.
-```
+```shell
preprovision_olt -t ponsim_olt -H 172.17.0.1:50060
```
This tells voltha to provision an olt of type ponsim_olt. You should see the following output.
-```
+```shell
success (device id = dece8e843be5)
```
@@ -90,26 +89,26 @@
Next, we need to activate the OLT in voltha.
-```
+```shell
enable
```
which returns
-```
+```shell
activating dece8e843be5
success (logical device id = 1)
```
This has now activated both a ponsim olt and onu as can be seem by running the following command at the CLI.
-```
+```shell
devices
```
and the output should be
-```
+```shell
+--------------+------------+------+--------------+------+-------------+-------------+----------------+----------------+------------------+-------------------------+--------------------------+
| id | type | root | parent_id | vlan | admin_state | oper_status | connect_status | parent_port_no | host_and_port | proxy_address.device_id | proxy_address.channel_id |
+--------------+------------+------+--------------+------+-------------+-------------+----------------+----------------+------------------+-------------------------+--------------------------+
@@ -120,13 +119,13 @@
Also we can observe similar output at the REST API. To use the REST, open a new shell to the server and run the following command. Note: The port number needs to be the recorded port number from the VOLTHA installation.
-```
+```shell
curl -s http://localhost:32863/api/v1/logical_devices | jq .
```
and the output should be
-```
+```json
{
"items": [
{
@@ -155,26 +154,25 @@
Now that this OLT has not received any forwarding rules, it should drop all traffic. We can verify this by starting the RG emulator and observing that EAPOL authentication does not succeed. To do this start our RG docker container.
-
-```
+```shell
docker run --net=host --privileged --name RG -it voltha/tester bash
```
this should land you in a command prompt that looks like
-```
+```shell
root@8358ef5cad0e:/#
```
and at this prompt issue the following command
-```
+```shell
/sbin/wpa_supplicant -Dwired -ipon1_128 -c /etc/wpa_supplicant/wpa_supplicant.conf
```
this should hang with the following output. You will need to interrupt it with Ctrl-C.
-```
+```shell
Successfully initialized wpa_supplicant
eth1: Associated with 01:80:c2:00:00:03
WMM AC: Missing IEs
@@ -182,7 +180,7 @@
and in the ponsim console you should see
-```
+```shell
20170113T053529.328 DEBUG frameio.recv {iface: pon1_128sim, hex: 0180c20000037a61e2a73004888e01010000, len: 18, event: frame-received, instance_id: pon1}
20170113T053529.329 DEBUG frameio.recv {event: frame-dispatched, instance_id: pon1}
20170113T053529.329 DEBUG frameio._dispatch {frame: 0180c20000037a61e2a73004888e01010000, event: calling-publisher, instance_id: pon1}
@@ -191,8 +189,7 @@
20170113T053529.330 DEBUG ponsim.ingress {logical_port_no: 128, name: onu0, event: dropped, instance_id: pon1}
```
-
-### Pass/Fail Criteria
+## Pass/Fail Criteria
* OLT is successfully detected and activated on VOLTHA
* Logical device and port list is created on VOLTHA
diff --git a/docs/manuals/user/labtests/S02_ponsim_tests_eapol_install.md b/docs/manuals/user/labtests/S02_ponsim_tests_eapol_install.md
index cc33ebc..c793ef1 100644
--- a/docs/manuals/user/labtests/S02_ponsim_tests_eapol_install.md
+++ b/docs/manuals/user/labtests/S02_ponsim_tests_eapol_install.md
@@ -1,9 +1,9 @@
-## S2 - Manually Install EAPOL Forwarding Flows
+# S2 - Manually Install EAPOL Forwarding Flows
-### Test Objective
+## Test Objective
-### Test Configuration
+## Test Configuration
-### Test Procedure
+## Test Procedure
-### Pass/Fail Criteria
+## Pass/Fail Criteria
diff --git a/docs/manuals/user/labtests/S02_ponsim_tests_onos.md b/docs/manuals/user/labtests/S02_ponsim_tests_onos.md
index a3596d5..cb59d53 100644
--- a/docs/manuals/user/labtests/S02_ponsim_tests_onos.md
+++ b/docs/manuals/user/labtests/S02_ponsim_tests_onos.md
@@ -1,37 +1,37 @@
-## S2 - Attach the PONSIM OLT to ONOS
+# S2 - Attach the PONSIM OLT to ONOS
-### Test Objective
+## Test Objective
Observe that ONOS has identified the OLT device and displays the correct number of ONU ports
-### Test Configuration
+## Test Configuration
* VOLTHA ensemble up and running.
* PONSIM configured with an OLT with multiple ONUs
-### Test Procedure
+## Test Procedure
First, start the onos container.
-```
+```shell
docker-compose -f compose/docker-compose-auth-test.yml up -d onos
```
this should output
-```
+```shell
Creating compose_onos_1
```
Make sure that ONOS is running
-```
+```shell
docker-compose -f compose/docker-compose-auth-test.yml ps
```
which shows
-```
+```shell
Name Command State Ports
------------------------------------------------------------------------------------------------------------------------------
compose_onos_1 ./bin/onos-service Up 0.0.0.0:6653->6653/tcp, 0.0.0.0:8101->8101/tcp, 0.0.0.0:8181->8181/tcp, 9876/tcp
@@ -39,14 +39,14 @@
Now, let's login to ONOS.
-```
+```shell
sudo apt install sshpass # may not be necessary
sshpass -p karaf ssh -o StrictHostKeyChecking=no -p 8101 karaf@localhost
```
this should land you at the ONOS prompt
-```
+```shell
Welcome to Open Network Operating System (ONOS)!
____ _ ______ ____
/ __ \/ |/ / __ \/ __/
@@ -68,25 +68,25 @@
Let's have a look at the devices that ONOS sees, to do this enter the following at the ONOS prompt.
-```
+```shell
devices
```
this will output the following
-```
+```shell
id=of:0000000000000001, available=true, role=MASTER, type=SWITCH, mfr=cord porject, hw=simualted pon, sw=simualted pon, serial=46da01fd646d4bb08140fc09b1bc4926, driver=voltha, channelId=172.25.0.1:35866, managementAddress=172.25.0.1, name=of:0000000000000001, protocol=OF_13
```
next let's have a look at the ports that onos sees. Remember that ONOS sees the PON system as a logical device so ONU are represented as ports to ONOS. So let's see the ports in ONOS.
-```
+```shell
ports
```
which returns the following
-```
+```shell
id=of:0000000000000001, available=true, role=MASTER, type=SWITCH, mfr=cord porject, hw=simualted pon, sw=simualted pon, serial=46da01fd646d4bb08140fc09b1bc4926, driver=voltha, channelId=172.25.0.1:35866, managementAddress=172.25.0.1, name=of:0000000000000001, protocol=OF_13
port=0, state=enabled, type=fiber, speed=0 , portName=nni, portMac=00:00:00:00:00:00
port=128, state=enabled, type=fiber, speed=0 , portName=uni-128, portMac=00:00:00:00:00:80
@@ -96,7 +96,7 @@
This correctly shows three ports. Yay!
-### Pass/Fail Criteria
+## Pass/Fail Criteria
* OLT observed in ONOS
* ONUs observed in ONOS as ports
diff --git a/docs/manuals/user/labtests/S03_ponsim_eapol_auth.md b/docs/manuals/user/labtests/S03_ponsim_eapol_auth.md
index de685f7..dbdee08 100644
--- a/docs/manuals/user/labtests/S03_ponsim_eapol_auth.md
+++ b/docs/manuals/user/labtests/S03_ponsim_eapol_auth.md
@@ -1,33 +1,33 @@
-## S3 - Verify EAPOL Remote Gateway Authentication
+# S3 - Verify EAPOL Remote Gateway Authentication
-### Test Objective
+## Test Objective
* Purpose of this test is to verify that 802.1X EAPOL messages are forwarded to the ONOS from VOLTHA
- * Correct simulated PON environment
- * Logical device visible in VOLTHA CLI
+ * Correct simulated PON environment
+ * Logical device visible in VOLTHA CLI
-### Test Configuration
+## Test Configuration
* VOLTHA ensemble running as per [deployment instructions](V01_voltha_bringup_deploy.md).
* Start the freeradius container
-```
+```shell
docker-compose -f compose/docker-compose-auth-test.yml up -d freeradius
```
* PONSIM OLT and ONUs registered as ACTIVE in VOLTHA
-### Test Procedure
+## Test Procedure
Execute the following command
-```
+```shell
/sbin/wpa_supplicant -Dwired -ipon1_128 -c /etc/wpa_supplicant/wpa_supplicant.conf
```
This should pass with the following output
-```
+```shell
Successfully initialized wpa_supplicant
pon1_128: Associated with 01:80:c2:00:00:03
WMM AC: Missing IEs
@@ -37,7 +37,6 @@
pon1_128: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
```
-
-### Pass/Fail Criteria
+## Pass/Fail Criteria
* EAPOL Authentication should pass
diff --git a/docs/manuals/user/labtests/S03_ponsim_tests_eapol_in_out.md b/docs/manuals/user/labtests/S03_ponsim_tests_eapol_in_out.md
index dba961e..71a5fa7 100644
--- a/docs/manuals/user/labtests/S03_ponsim_tests_eapol_in_out.md
+++ b/docs/manuals/user/labtests/S03_ponsim_tests_eapol_in_out.md
@@ -1,9 +1,9 @@
-## S3 - Test EAPOL In/Out Forwarding with OLT-OFTEST
+# S3 - Test EAPOL In/Out Forwarding with OLT-OFTEST
-### Test Objective
+## Test Objective
-### Test Configuration
+## Test Configuration
-### Test Procedure
+## Test Procedure
-### Pass/Fail Criteria
+## Pass/Fail Criteria
diff --git a/docs/manuals/user/labtests/S04_ponsim_tests_install_all_flows.md b/docs/manuals/user/labtests/S04_ponsim_tests_install_all_flows.md
index c6edee9..bcbf313 100644
--- a/docs/manuals/user/labtests/S04_ponsim_tests_install_all_flows.md
+++ b/docs/manuals/user/labtests/S04_ponsim_tests_install_all_flows.md
@@ -1,9 +1,9 @@
-## S4 - Manually Install All Forwarding Flows
+# S4 - Manually Install All Forwarding Flows
-### Test Objective
+## Test Objective
-### Test Configuration
+## Test Configuration
-### Test Procedure
+## Test Procedure
-### Pass/Fail Criteria
+## Pass/Fail Criteria
diff --git a/docs/manuals/user/labtests/S04_ponsim_verify_dhcp.md b/docs/manuals/user/labtests/S04_ponsim_verify_dhcp.md
index 6b4c282..b198db5 100644
--- a/docs/manuals/user/labtests/S04_ponsim_verify_dhcp.md
+++ b/docs/manuals/user/labtests/S04_ponsim_verify_dhcp.md
@@ -1,46 +1,45 @@
-## S4 - Verify DHCP successfully obtains an IP address
+# S4 - Verify DHCP successfully obtains an IP address
-### Test Objective
+## Test Objective
* Purpose of this test is to verify that the Dynamic Host Configuration Protocol (DHCP)
- * Correct simulated PON environment
- * Logical device visible in VOLTHA cli
+ * Correct simulated PON environment
+ * Logical device visible in VOLTHA cli
-### Test Configuration
+## Test Configuration
* VOLTHA ensemble running as per [deployment instructions](V01_voltha_bringup_deploy.md).
* Note: The DHCP server is contained within ONOS.
* PONSIM OLT and ONUs registered as ACTIVE in VOLTHA
-### Test Procedure
+## Test Procedure
To start this procedure, execute the "ifconfig" command on the
interface that will be getting assigned an IP address over DHCP and
verify that IP address has not been assigned.
-```
+```shell
ifconfig pon1_128
```
Execute the following command
-```
+```shell
dhclient pon1_128
```
Note: When the dhclient command completes a common error message is displayed as follows. This mesage can safely be ignored.
-```
+```shell
dhclient: cannot move '/etc/*.conf' to '/etc/resolve.conf'
```
Then verify that an IP address was dynamically assigned to your interface
-```
+```shell
ifconfig pon1_128
```
-
-### Pass/Fail Criteria
+## Pass/Fail Criteria
* IP address assigned to interface
diff --git a/docs/manuals/user/labtests/S05_ponsim_tests_unicast.md b/docs/manuals/user/labtests/S05_ponsim_tests_unicast.md
index 951d008..e4ab0ab 100644
--- a/docs/manuals/user/labtests/S05_ponsim_tests_unicast.md
+++ b/docs/manuals/user/labtests/S05_ponsim_tests_unicast.md
@@ -1,33 +1,33 @@
-## S5 - Verify unicast traffic flow
+# S5 - Verify unicast traffic flow
-### Test Objective
+## Test Objective
* Purpose of this test is to verify that unicast traffic flows through the system
- * Correct simulated PON environment
- * Logical device visible in VOLTHA cli
+ * Correct simulated PON environment
+ * Logical device visible in VOLTHA cli
-### Test Configuration
+## Test Configuration
* VOLTHA ensemble running as per [deployment instructions](V01_voltha_bringup_deploy.md).
* PONSIM OLT and ONUs registered as ACTIVE in VOLTHA
-### Test Procedure
+## Test Procedure
Execute the following command
-```
+```shell
ping -I pon1_128 1.2.3.4
```
Meanwhile tcpdump on the host machine on pon1_0.
-```
+```shell
sudo tcpdump -nei pon1_0
```
which will output
-```
+```shell
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pon1_0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:53:44.328260 06:0c:49:94:35:7e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 50: vlan 1000, p 0, ethertype 802.1Q, vlan 128, p 0, ethertype ARP, Request who-has 1.2.3.4 tell 10.1.11.63, length 28
@@ -38,6 +38,6 @@
13:53:49.322517 06:0c:49:94:35:7e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 50: vlan 1000, p 0, ethertype 802.1Q, vlan 128, p 0, ethertype ARP, Request who-has 1.2.3.4 tell 10.1.11.63, length 28
```
-### Pass/Fail Criteria
+## Pass/Fail Criteria
Ping completes successfully
diff --git a/docs/manuals/user/labtests/S06_ponsim_tests_multicast.md b/docs/manuals/user/labtests/S06_ponsim_tests_multicast.md
index d1f6fb6..9c140bf 100644
--- a/docs/manuals/user/labtests/S06_ponsim_tests_multicast.md
+++ b/docs/manuals/user/labtests/S06_ponsim_tests_multicast.md
@@ -1,20 +1,20 @@
-## S6 - Test IGMP and multicast (Video) streams
+# S6 - Test IGMP and multicast (Video) streams
-### Test Objective
+## Test Objective
Verify that VOLTHA punts IGMP packets to ONOS and that ONOS provisions the right multicast rules
-### Test Configuration
+## Test Configuration
* VOLTHA ensemble up and running.
* PONSIM configured with an OLT with multiple ONUs
* An authenticated RG
-### Test Procedure
+## Test Procedure
At this point ONOS should show the following rules:
-```
+```shell
deviceId=of:0000000000000001, flowRuleCount=7
ADDED, bytes=0, packets=0, table=0, priority=10000, selector=[IN_PORT:128, ETH_TYPE:ipv4, IP_PROTO:2], treatment=[immediate=[OUTPUT:CONTROLLER]]
ADDED, bytes=0, packets=0, table=0, priority=1000, selector=[IN_PORT:128, ETH_TYPE:eapol], treatment=[immediate=[OUTPUT:CONTROLLER]]
@@ -27,13 +27,13 @@
So now let's send an IGMP packet from the RG up the ONU. To do this run the following in the RG container.
-```
+```shell
igmp.py -j -i pon1_128 -m 229.0.0.1
```
this will return
-```
+```shell
.
Sent 1 packets.
```
@@ -42,13 +42,13 @@
Let us now check the state in ONOS, starting with the group information. Run the following in the ONOS prompt.
-```
+```shell
groups
```
which returns
-```
+```shell
deviceId=of:0000000000000001, groupCount=1
id=0x1, state=ADDED, type=ALL, bytes=0, packets=0, appId=org.onosproject.cordmcast
id=0x1, bucket=1, bytes=0, packets=0, actions=[VLAN_POP:unknown, OUTPUT:128]
@@ -58,13 +58,13 @@
For a group to be useful a flow must point to this group. So let's check in ONOS whether a flow exists.
-```
+```shell
flows -s
```
and find a flow which looks like
-```
+```shell
ADDED, bytes=0, packets=0, table=0, priority=500, selector=[IN_PORT:0, ETH_TYPE:ipv4, VLAN_VID:140, IPV4_DST:229.0.0.1/32], treatment=[immediate=[GROUP:0x1]]
```
@@ -72,14 +72,14 @@
Now let's check whether we find this state in the logical device in VOLTHA. Let's run the following in the VOLTHA CLI.
-```
+```shell
logical_device
flows
```
which will return
-```
+```shell
Logical Device 1 (type: n/a)
Flows (10):
+----------+----------+-----------+---------+----------+----------+----------+-----------+---------+---------+----------+--------------+----------+-----------+-------+------------+------------+
@@ -102,13 +102,13 @@
Let's now look at the physical device level. Still in the Voltha CLI run the following.
-```
+```shell
devices
```
this returns
-```
+```shell
Devices:
+--------------+------------+------+--------------+------+-------------+-------------+----------------+----------------+------------------+-------------------------+--------------------------+
| id | type | root | parent_id | vlan | admin_state | oper_status | connect_status | parent_port_no | host_and_port | proxy_address.device_id | proxy_address.channel_id |
@@ -122,14 +122,14 @@
Identify the ONU which sent the IGMP packet (128) and copy its device id (56a6fc8b859f in this case). Next run the following in the Voltha CLI.
-```
+```shell
device 56a6fc8b859f
flows
```
which returns
-```
+```shell
Device 56a6fc8b859f (type: ponsim_onu)
Flows (6):
+----------+----------+-----------+---------+----------+----------+-----------+--------------+----------+-----------+--------+
@@ -148,7 +148,7 @@
Let us now try this out for real with a real packet. Let's first build a multicast frame and send it down the nni port, we can do this with scapy.
-```
+```shell
sudo scapy
mc = Ether(src="00:00:00:00:00:01")/Dot1Q(vlan=140)/IP(dst="229.0.0.1", proto=17)
sendp(mc, iface="pon1_0")
@@ -156,13 +156,13 @@
Meanwhile run tcpdump in the RG container:
-```
+```shell
tcpdump -nei pon1_128
```
in he RG container while tcpdump'ing we should see the following output.
-```
+```shell
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pon1_128, link-type EN10MB (Ethernet), capture size 262144 bytes
08:09:43.004776 00:00:00:00:00:01 > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 34: 10.0.2.15 > 229.0.0.1: [|udp]
@@ -170,7 +170,7 @@
Woohoo!
-### Pass/Fail Criteria
+## Pass/Fail Criteria
* Flows and groups installed in ONOS
* Flows and groups installed in Voltha
diff --git a/docs/manuals/user/labtests/T00_tibit_olt_tests.md b/docs/manuals/user/labtests/T00_tibit_olt_tests.md
index 23de6ca..eefab69 100644
--- a/docs/manuals/user/labtests/T00_tibit_olt_tests.md
+++ b/docs/manuals/user/labtests/T00_tibit_olt_tests.md
@@ -8,4 +8,4 @@
* [T3 - Verify EAPOL RG Authentication](T03_tibit_olt_eapol_auth.md)
* [T4 - Verify DHCP Lookup](T04_tibit_verify_dhcp.md)
* [T5 - Verify Unicast Access](T05_tibit_tests_unicast.md)
-* [T6 - Verify IGMP Handling](T06_tibit_tests_multicast.md)
+* [T6 - Verify IGMP Handling](T06_tibit_tests_multicast.md)
diff --git a/docs/manuals/user/labtests/T01_tibit_olt_tests_activate_olt.md b/docs/manuals/user/labtests/T01_tibit_olt_tests_activate_olt.md
index 05ec86f..142d714 100644
--- a/docs/manuals/user/labtests/T01_tibit_olt_tests_activate_olt.md
+++ b/docs/manuals/user/labtests/T01_tibit_olt_tests_activate_olt.md
@@ -1,26 +1,26 @@
-## T1 - Preprovision and Activate OLT
+# T1 - Preprovision and Activate OLT
-### Test Objective
+## Test Objective
* Purpose of this test is to verify new OLT can be added and activated from VOLTHA
* VOLTHA will connect with the OLT physical device and create a
logical device with initial ports in its data store
* VOLTHA will send Event notifications to ONOS and PON Manager for the newly added OLT
-### Test Configuration
+## Test Configuration
* The test setup is as shown in earlier sections
* Tibit OLT should be reachable from VOLTHA on VLAN 4090
* Start the VOLTHA CLI
-**Step 1: If not yet running, launch the Voltha CLI:**
+## Step 1: If not yet running, launch the Voltha CLI
-```
+```shell
cd $VOLTHA_BASE
./cli/main.py -L
```
-```
+```shell
_ _ _ ___ _ ___
__ _____| | |_| |_ __ _ / __| | |_ _|
\ V / _ \ | _| ' \/ _` | | (__| |__ | |
@@ -29,14 +29,14 @@
(voltha)
```
-### Test Procedure
+## Test Procedure
* Issue CLI commands in the VOLTHA CLI to simulate an “Add-OLT device”
message coming from the PON Manager to VOLTHA
* Note: Please refer to the label for "MAC 0" printed on the side of
the Tibit evaluation device to record the MAC address of the OLT
-```
+```shell
preprovision_olt --device-type tibit_olt --mac-address 00:0c:e2:31:40:00
```
@@ -44,13 +44,13 @@
device in the device table. Executing the following command will
display known devices
-```
+```shell
devices
```
* The output should appear as follows
-```
+```shell
Devices:
+--------------+-----------+-------------------+----------------+
| id | type | mac_address | admin_state |
@@ -61,22 +61,23 @@
* To activate the OLT, execute the following command
-```
+```shell
enable
```
+
* VOLTHA should initiate a connection and activation request to the Tibit OLT
* VOLHA will create the logical OpenFlow device and ports and notify ONOS
* VOLTHA will send an OLT-Activated event notification to the PON Manager
-* VOLTHA will also query the OLT for the number of ONUs connected and attempt
-to activate all ONUs
+* VOLTHA will also query the OLT for the number of ONUs connected and attempt to activate all ONUs
* Verify the OLT and ONU status on device console with the following command
-```
+```shell
devices
```
+
* The output should appear similar to the following
-```
+```shell
Devices:
+--------------+-----------+------+------+-------------------+-------------+-------------+...
| id | type | root | vlan | mac_address | admin_state | oper_status |...
@@ -86,36 +87,33 @@
+--------------+-----------+------+------+-------------------+-------------+-------------+...
```
-Now that this OLT has not received any forwarding rules, it should
-drop all traffic. We can verify this by starting the RG emulator and
-observing that EAPOL authentication does not succeed. To do this start
-our RG docker container.
+Now that this OLT has not received any forwarding rules, it should drop all traffic. We can verify this by starting the RG emulator and observing that EAPOL authentication does not succeed. To do this start our RG docker container.
-```
+```shell
docker run --net=host --privileged --name RG -it voltha/tester bash
```
this should land you in a command prompt that looks like
-```
+```shell
root@8358ef5cad0e:/#
```
and at this prompt issue the following command
-```
+```shell
/sbin/wpa_supplicant -Dwired -ieno4.2023 -c /etc/wpa_supplicant/wpa_supplicant.conf
```
this should hang with the following output. You will need to interrupt it with Ctrl-C.
-```
+```shell
Successfully initialized wpa_supplicant
eth1: Associated with 01:80:c2:00:00:03
WMM AC: Missing IEs
```
-### Pass/Fail Criteria
+## Pass/Fail Criteria
* OLT / ONUs status can be seen from Device Console
* Confirm OLT and ONUs have "oper_status" of ACTIVE
diff --git a/docs/manuals/user/labtests/T02_tibit_olt_tests_onos.md b/docs/manuals/user/labtests/T02_tibit_olt_tests_onos.md
index 6770131..dae9730 100644
--- a/docs/manuals/user/labtests/T02_tibit_olt_tests_onos.md
+++ b/docs/manuals/user/labtests/T02_tibit_olt_tests_onos.md
@@ -1,43 +1,43 @@
-## T2 - Attach the Tibit OLT to ONOS
+# T2 - Attach the Tibit OLT to ONOS
-### Test Objective
+## Test Objective
Observe that ONOS has identified the OLT device and displays the correct number of ONU ports
-### Test Configuration
+## Test Configuration
* VOLTHA ensemble up and running.
* Tibit configured with an OLT and one or more ONUs
-### Test Procedure
+## Test Procedure
First, start the onos container.
-```
+```shell
docker-compose -f compose/docker-compose-auth-test.yml up -d onos
```
this should output
-```
+```shell
Creating compose_onos_1
```
Note: You may see a docker compose warning that states the following. This warning can be ignored.
-```
+```shell
WARNING: Found orphan containers (compose_shovel_1, compose_registrator_1, compose_kafka_1, ...)
```
Make sure that ONOS is running
-```
+```shell
docker-compose -f compose/docker-compose-auth-test.yml ps
```
which shows
-```
+```shell
Name Command State Ports
------------------------------------------------------------------------------------------------------------------------------
compose_onos_1 ./bin/onos-service Up 0.0.0.0:6653->6653/tcp, 0.0.0.0:8101->8101/tcp, 0.0.0.0:8181->8181/tcp, 9876/tcp
@@ -45,14 +45,14 @@
Now, let's login to ONOS.
-```
+```shell
sudo apt install sshpass # may not be necessary
sshpass -p karaf ssh -o StrictHostKeyChecking=no -p 8101 karaf@localhost
```
this should land you at the ONOS prompt
-```
+```shell
Welcome to Open Network Operating System (ONOS)!
____ _ ______ ____
/ __ \/ |/ / __ \/ __/
@@ -74,25 +74,25 @@
Let's have a look at the devices that ONOS sees, to do this enter the following at the ONOS prompt.
-```
+```shell
devices
```
this will output the following
-```
+```shell
id=of:0000000000000001, available=true, role=MASTER, type=SWITCH, mfr=cord porject, hw=simualted pon, sw=simualted pon, serial=46da01fd646d4bb08140fc09b1bc4926, driver=voltha, channelId=172.25.0.1:35866, managementAddress=172.25.0.1, name=of:0000000000000001, protocol=OF_13
```
next let's have a look at the ports that onos sees. Remember that ONOS sees the PON system as a logical device so ONU are represented as ports to ONOS. So let's see the ports in ONOS.
-```
+```shell
ports
```
which returns the following
-```
+```shell
id=of:0000000000000001, available=true, role=MASTER, type=SWITCH, mfr=cord porject, hw=simualted pon, sw=simualted pon, serial=46da01fd646d4bb08140fc09b1bc4926, driver=voltha, channelId=172.25.0.1:35866, managementAddress=172.25.0.1, name=of:0000000000000001, protocol=OF_13
port=0, state=enabled, type=fiber, speed=0 , portName=nni, portMac=00:00:00:00:00:00
port=128, state=enabled, type=fiber, speed=0 , portName=uni-128, portMac=00:00:00:00:00:80
@@ -102,7 +102,7 @@
This correctly shows three ports. Yay!
-### Pass/Fail Criteria
+## Pass/Fail Criteria
* OLT observed in ONOS
* ONUs observed in ONOS as ports
diff --git a/docs/manuals/user/labtests/T03_tibit_olt_eapol_auth.md b/docs/manuals/user/labtests/T03_tibit_olt_eapol_auth.md
index 9f0e218..bd6f772 100644
--- a/docs/manuals/user/labtests/T03_tibit_olt_eapol_auth.md
+++ b/docs/manuals/user/labtests/T03_tibit_olt_eapol_auth.md
@@ -1,48 +1,48 @@
-## T3 - Verify EAPOL Remote Gateway Authentication
+# T3 - Verify EAPOL Remote Gateway Authentication
-### Test Objective
+## Test Objective
* Purpose of this test is to verify that 802.1X EAPOL messages are forwarded to the ONOS from VOLTHA
- * Correct Tibit OLT and ONU PON environment
- * Logical device visible in VOLTHA CLI
+ * Correct Tibit OLT and ONU PON environment
+ * Logical device visible in VOLTHA CLI
-### Test Configuration
+## Test Configuration
* VOLTHA ensemble running as per [deployment instructions](V01_voltha_bringup_deploy.md).
* Start the freeradius container
-```
+```shell
docker-compose -f compose/docker-compose-auth-test.yml up -d freeradius
```
* Tibit OLT and ONUs registered as ACTIVE in VOLTHA
-### Test Procedure
+## Test Procedure
Now that this OLT is ACTIVE in VOLTHA, it should forward EAPOL
traffic. We can verify this by starting the RG emulator and observing
that EAPOL authentication does not succeed. To do this start our RG
docker container.
-```
+```shell
docker run --net=host --privileged --name RG -it voltha/tester bash
```
this should land you in a command prompt that looks like
-```
+```shell
root@8358ef5cad0e:/#
```
and at this prompt issue the following command
-```
+```shell
/sbin/wpa_supplicant -Dwired -iens9f1 -c /etc/wpa_supplicant/wpa_supplicant.conf
```
This should pass with the following output
-```
+```shell
Successfully initialized wpa_supplicant
ens9f1: Associated with 01:80:c2:00:00:03
WMM AC: Missing IEs
@@ -54,11 +54,10 @@
Note: The wpa_supplicant application will not terminate on its own. After the EAP authentication has completed, it is appropriate to terminate the wpa_supplicant application.
-```
+```shell
Ctrl-C
```
-
-### Pass/Fail Criteria
+## Pass/Fail Criteria
* EAPOL Authentication should pass
diff --git a/docs/manuals/user/labtests/T04_tibit_verify_dhcp.md b/docs/manuals/user/labtests/T04_tibit_verify_dhcp.md
index 7cd3a9d..b0faac8 100644
--- a/docs/manuals/user/labtests/T04_tibit_verify_dhcp.md
+++ b/docs/manuals/user/labtests/T04_tibit_verify_dhcp.md
@@ -1,42 +1,42 @@
-## T4 - Verify DHCP successfully obtains an IP address
+# T4 - Verify DHCP successfully obtains an IP address
-### Test Objective
+## Test Objective
* Purpose of this test is to verify that the Dynamic Host Configuration Protocol (DHCP)
- * Correct Tibit OLT and ONU PON environment
- * Logical device visible in VOLTHA CLI
+ * Correct Tibit OLT and ONU PON environment
+ * Logical device visible in VOLTHA CLI
-### Test Configuration
+## Test Configuration
* VOLTHA ensemble running as per [deployment instructions](V01_voltha_bringup_deploy.md).
* Note: The DHCP server is contained within ONOS.
* Tibit OLT and ONUs registered as ACTIVE in VOLTHA
-### Test Procedure
+## Test Procedure
To start this procedure, execute the "ifconfig" command on the interface that will be getting assigned an IP address over DHCP and verify that IP address has not been assigned.
-```
+```shell
ifconfig ens9f1
```
Next, execute the following command to obtain an IP address from ONOS.
-```
+```shell
dhclient ens9f1
```
Note: When the dhclient command completes a common error message is displayed as follows. This mesage can safely be ignored.
-```
+```shell
mv: cannot move '/etc/resolv.conf.dhclient-new*' to '/etc/resolve.conf'
```
Then verify that an IP address was dynamically assigned to your interface
-```
+```shell
ifconfig ens9f1
```
-### Pass/Fail Criteria
+## Pass/Fail Criteria
* IP address assigned to interface
diff --git a/docs/manuals/user/labtests/T05_tibit_tests_unicast.md b/docs/manuals/user/labtests/T05_tibit_tests_unicast.md
index e95b4f5..81fcc57 100644
--- a/docs/manuals/user/labtests/T05_tibit_tests_unicast.md
+++ b/docs/manuals/user/labtests/T05_tibit_tests_unicast.md
@@ -1,33 +1,33 @@
-## T5 - Verify unicast traffic flow
+# T5 - Verify unicast traffic flow
-### Test Objective
+## Test Objective
* Purpose of this test is to verify that unicast traffic flows through the system
- * Correct Tibit PON environment
- * Logical device visible in VOLTHA cli
+ * Correct Tibit PON environment
+ * Logical device visible in VOLTHA cli
-### Test Configuration
+## Test Configuration
* VOLTHA ensemble running as per [deployment instructions](V01_voltha_bringup_deploy.md).
* Tibit OLT and ONUs registered as ACTIVE in VOLTHA
-### Test Procedure
+## Test Procedure
Execute the following command from the RG side
-```
+```shell
ping -I ens9f1 1.2.3.4
```
Meanwhile tcpdump on the VOLTHA server.
-```
+```shell
sudo tcpdump -nei ens9f0
```
which will output
-```
+```shell
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pon1_0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:53:44.328260 06:0c:49:94:35:7e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 50: vlan 1000, p 0, ethertype 802.1Q, vlan 128, p 0, ethertype ARP, Request who-has 1.2.3.4 tell 10.1.11.63, length 28
@@ -38,6 +38,6 @@
13:53:49.322517 06:0c:49:94:35:7e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 50: vlan 1000, p 0, ethertype 802.1Q, vlan 128, p 0, ethertype ARP, Request who-has 1.2.3.4 tell 10.1.11.63, length 28
```
-### Pass/Fail Criteria
+## Pass/Fail Criteria
Ping completes successfully
diff --git a/docs/manuals/user/labtests/T06_tibit_tests_multicast.md b/docs/manuals/user/labtests/T06_tibit_tests_multicast.md
index 8593a4d..0d379f0 100644
--- a/docs/manuals/user/labtests/T06_tibit_tests_multicast.md
+++ b/docs/manuals/user/labtests/T06_tibit_tests_multicast.md
@@ -1,24 +1,24 @@
-## T6 - Test IGMP and multicast (Video) streams
+# T6 - Test IGMP and multicast (Video) streams
-### Test Objective
+## Test Objective
Verify that VOLTHA punts IGMP packets to ONOS and that ONOS provisions the right multicast rules
-### Test Configuration
+## Test Configuration
* VOLTHA ensemble up and running.
* Tibit configured with an OLT with one or more ONUs
* An authenticated RG
-### Test Procedure
+## Test Procedure
At this point ONOS should show the following rules. Type flows at the 'onos>' prompt comfirm.
-```
+```shell
flows
```
-```
+```shell
deviceId=of:0000000000000001, flowRuleCount=7
ADDED, bytes=0, packets=0, table=0, priority=10000, selector=[IN_PORT:128, ETH_TYPE:ipv4, IP_PROTO:2], treatment=[immediate=[OUTPUT:CONTROLLER]]
ADDED, bytes=0, packets=0, table=0, priority=1000, selector=[IN_PORT:128, ETH_TYPE:eapol], treatment=[immediate=[OUTPUT:CONTROLLER]]
@@ -33,19 +33,19 @@
Before starting the IGMP test, execute the 'groups' command within ONOS to verify that no groups have been created.
-```
+```shell
groups
```
Now let's send an IGMP packet from the RG up the ONU. To do this run the following in the RG container.
-```
+```shell
igmp.py -j -i ens9f1 -m 229.0.0.1
```
this will return
-```
+```shell
.
Sent 1 packets.
```
@@ -54,13 +54,13 @@
Let us now check the state in ONOS, starting with the group information. Run the following in the ONOS prompt.
-```
+```shell
groups
```
which returns
-```
+```shell
deviceId=of:0000000000000001, groupCount=1
id=0x1, state=ADDED, type=ALL, bytes=0, packets=0, appId=org.onosproject.cordmcast
id=0x1, bucket=1, bytes=0, packets=0, actions=[VLAN_POP:unknown, OUTPUT:128]
@@ -70,13 +70,13 @@
For a group to be useful a flow must point to this group. So let's check in ONOS whether a flow exists.
-```
+```shell
flows -s
```
and find a flow which looks like
-```
+```shell
ADDED, bytes=0, packets=0, table=0, priority=500, selector=[IN_PORT:0, ETH_TYPE:ipv4, VLAN_VID:140, IPV4_DST:229.0.0.1/32], treatment=[immediate=[GROUP:0x1]]
```
@@ -84,14 +84,14 @@
Now let's check whether we find this state in the logical device in VOLTHA. Let's run the following in the VOLTHA CLI.
-```
+```shell
logical_device
flows
```
which will return
-```
+```shell
Logical Device 1 (type: n/a)
Flows (10):
+----------+----------+-----------+---------+----------+----------+----------+-----------+---------+---------+----------+--------------+----------+-----------+-------+------------+------------+
@@ -114,13 +114,13 @@
Let's now look at the physical device level. Still in the Voltha CLI run the following.
-```
+```shell
devices
```
this returns
-```
+```shell
Devices:
+--------------+------------+------+--------------+------+-------------+-------------+----------------+----------------+------------------+-------------------------+--------------------------+
| id | type | root | parent_id | vlan | admin_state | oper_status | connect_status | parent_port_no | host_and_port | proxy_address.device_id | proxy_address.channel_id |
@@ -134,14 +134,14 @@
Identify the ONU which sent the IGMP packet (128) and copy its device id (56a6fc8b859f in this case). Next run the following in the Voltha CLI.
-```
+```shell
device 56a6fc8b859f
flows
```
which returns
-```
+```shell
Device 56a6fc8b859f (type: ponsim_onu)
Flows (6):
+----------+----------+-----------+---------+----------+----------+-----------+--------------+----------+-----------+--------+
@@ -160,7 +160,7 @@
Let us now try this out for real with a real packet. Let's first build a multicast frame on the server and send it down the nni port to the OLT, we can do this with scapy.
-```
+```shell
sudo scapy
mc = Ether(src="00:00:00:00:00:01")/Dot1Q(vlan=140)/IP(dst="229.0.0.1", proto=17)
sendp(mc, iface="ens9f0")
@@ -168,13 +168,13 @@
Meanwhile run tcpdump in the RG container:
-```
+```shell
tcpdump -nei ens9f1
```
in he RG container while tcpdump'ing we should see the following output.
-```
+```shell
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno2.2021, link-type EN10MB (Ethernet), capture size 262144 bytes
08:09:43.004776 00:00:00:00:00:01 > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 34: 10.0.2.15 > 229.0.0.1: [|udp]
@@ -182,7 +182,7 @@
Woohoo!
-### Pass/Fail Criteria
+## Pass/Fail Criteria
* Flows and groups installed in ONOS
* Flows and groups installed in Voltha
diff --git a/docs/manuals/user/labtests/T09_tibit_olt_tests_verify_authentication.md b/docs/manuals/user/labtests/T09_tibit_olt_tests_verify_authentication.md
index e0733e0..10c1398 100644
--- a/docs/manuals/user/labtests/T09_tibit_olt_tests_verify_authentication.md
+++ b/docs/manuals/user/labtests/T09_tibit_olt_tests_verify_authentication.md
@@ -1,10 +1,11 @@
-## T9 - Verify RG Authentication Scenario
+# T9 - Verify RG Authentication Scenario
-### Test Objective
+## Test Objective
* Purpose of this test is to verify RG authentication is successful with Radius / EAP method
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Tibit OLT should be reachable to VOLTHA over IP interface over VLAN 4090
* Tibit OLT should be in active state on VOLTHA
@@ -13,7 +14,8 @@
* Radius Server is in service and configured to authenticate RG
* DHCP Server should be down
-### Test Procedure
+## Test Procedure
+
* Start EAP authentication process from RG by resetting RG.
* RG should send EAP-Start message and verify it reaches VOLTHA/ONOS
* EAP message exchange should happen between RG and VOLTHA/ONOS on Management VLAN 4091.
@@ -26,7 +28,7 @@
* VOLTHA/ ONOS should send IGMP Forwarding Flow to OLT and ONU
* OLT/ONU will be able to forward DHCP, Unicast and IGMP packets from RG
-### Pass/Fail Criteria
+## Pass/Fail Criteria
* RG is successfully authenticated based on its credentials in Radius Server
* DHCP, Unicast and IGMP forwarding flows are setup on OLT/ONU
diff --git a/docs/manuals/user/labtests/T10_tibit_olt_tests_verify_dhcp.md b/docs/manuals/user/labtests/T10_tibit_olt_tests_verify_dhcp.md
index b438191..a66aa21 100644
--- a/docs/manuals/user/labtests/T10_tibit_olt_tests_verify_dhcp.md
+++ b/docs/manuals/user/labtests/T10_tibit_olt_tests_verify_dhcp.md
@@ -1,10 +1,11 @@
-## T10 - Verify DHCP Lookup
+# T10 - Verify DHCP Lookup
-### Test Objective
+## Test Objective
* Purpose of this test is to verify RG can successfully setup DHCP session
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Tibit OLT should be reachable to VOLTHA over IP interface over VLAN 4090
* Tibit OLT should be in active state on VOLTHA
@@ -13,14 +14,15 @@
* DHCP, Unicast and IGMP forwarding flows are setup on OLT and ONU
* DHCP Server is running
-### Test Procedure
+## Test Procedure
+
* Enable DHCP on RG by either resetting or enable/disable port
* DHCP Request from should be forwarded by VOLTHA/ONOS to DHCP Server
* OLT will send and receive DHCP Messages with SVID 4091 towards VOLTHA/ONOS
* DHCP should succeed and RG should have IP address
* Verify ARP, PING and Traceroute succeeds from RG to DHCP server (Not planned on it will be additional step)
-### Pass/Fail Criteria
+## Pass/Fail Criteria
+
* RG can receive IP address from DHCP server
* ARP, Ping and Traceroute is successful between RG and DHCP server
-
diff --git a/docs/manuals/user/labtests/T11_tibit_olt_tests_verify_unicast.md b/docs/manuals/user/labtests/T11_tibit_olt_tests_verify_unicast.md
index 172b63c..8cfee13 100644
--- a/docs/manuals/user/labtests/T11_tibit_olt_tests_verify_unicast.md
+++ b/docs/manuals/user/labtests/T11_tibit_olt_tests_verify_unicast.md
@@ -1,20 +1,23 @@
-## T11 - Verify Unicast Access
+# T11 - Verify Unicast Access
-### Test Objective
+## Test Objective
* Purpose of this test is to verify OLT and ONU can pass double tagged traffic
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Tibit OLT and ONU is activated using VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA
-### Test Procedure
+## Test Procedure
+
* On Spirent, configure double tagged traffic in downstream direction (1025,1025)
* On Spirent, send untagged traffic in upstream direction
* On the both ports capture traffic and verify the stream
-### Pass/Fail Criteria
+## Pass/Fail Criteria
+
* Upstream:
* Traffic coming out of OLT is double tagged 1025 ,1025
* Downstream:
diff --git a/docs/manuals/user/labtests/T12_tibit_olt_tests_verify_multicast.md b/docs/manuals/user/labtests/T12_tibit_olt_tests_verify_multicast.md
index 177901d..78ba00e 100644
--- a/docs/manuals/user/labtests/T12_tibit_olt_tests_verify_multicast.md
+++ b/docs/manuals/user/labtests/T12_tibit_olt_tests_verify_multicast.md
@@ -1,10 +1,11 @@
-## T12 - Verify Multicast Access
+# T12 - Verify Multicast Access
-### Test Objective
+## Test Objective
* To verify video service on RG
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Tibit OLT should be reachable to VOLTHA over IP interface on VLAN 4090
* Tibit OLT should be in active state on VOLTHA
@@ -12,12 +13,14 @@
* RG is authenticated with Radius and RG has IP address from DHCP
* VLC streaming server is active, VLC Video Client is connected to RG
-### Test Procedure
+## Test Procedure
+
* Enable Multicast Video Stream from VLC server
* Multicast Video stream should be tagged with VLAN ID 140
* From VLC client initiate connection to streaming Multicast channel
* Packet Capture at OLT port should show IGMP join message
* Observe Video quality on TV
-### Pass/Fail Criteria
+## Pass/Fail Criteria
+
* Video is displayed on TV
diff --git a/docs/manuals/user/labtests/T13_tibit_olt_tests_verify_cvid_upstream.md b/docs/manuals/user/labtests/T13_tibit_olt_tests_verify_cvid_upstream.md
index 5a39613..3241f89 100644
--- a/docs/manuals/user/labtests/T13_tibit_olt_tests_verify_cvid_upstream.md
+++ b/docs/manuals/user/labtests/T13_tibit_olt_tests_verify_cvid_upstream.md
@@ -1,14 +1,15 @@
-## T13 - Spirent - Verify Re-Write C-VID Upstream
+# T13 - Spirent - Verify Re-Write C-VID Upstream
-### Test Objective
+## Test Objective
* The purpose of this test is to verify ONU can re-write Priority tagged frames (VLAN ID 0) with single c-VID in upstream to wards OLT
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Tibit OLT and ONU is activated using VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA
-### Test Procedure
+## Test Procedure
-### Pass/Fail Criteria
+## Pass/Fail Criteria
diff --git a/docs/manuals/user/labtests/T14_tibit_olt_tests_verify_cvid_downstream.md b/docs/manuals/user/labtests/T14_tibit_olt_tests_verify_cvid_downstream.md
index f480568..a37c4bd 100644
--- a/docs/manuals/user/labtests/T14_tibit_olt_tests_verify_cvid_downstream.md
+++ b/docs/manuals/user/labtests/T14_tibit_olt_tests_verify_cvid_downstream.md
@@ -1,13 +1,15 @@
-## T14 - Spirent - Verify Re-Write C-VID Downstream
+# T14 - Spirent - Verify Re-Write C-VID Downstream
-### Test Objective
+## Test Objective
+
* The Purpose of this test is to verify ONU can re-write single C-VID frames as priority tagges frames in downstream towards RG
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Tibit OLT and ONU is activated using VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA
-### Test Procedure
+## Test Procedure
-### Pass/Fail Criteria
+## Pass/Fail Criteria
diff --git a/docs/manuals/user/labtests/T15_tibit_olt_tests_verify_qinq_upstream.md b/docs/manuals/user/labtests/T15_tibit_olt_tests_verify_qinq_upstream.md
index 32728a2..9455371 100644
--- a/docs/manuals/user/labtests/T15_tibit_olt_tests_verify_qinq_upstream.md
+++ b/docs/manuals/user/labtests/T15_tibit_olt_tests_verify_qinq_upstream.md
@@ -1,21 +1,23 @@
-## T15 - Spirent - Verify 802.1ad (QinQ) Upstream
+# T15 - Spirent - Verify 802.1ad (QinQ) Upstream
-### Test Objective
+## Test Objective
* Purpose of this test is to verify OLT can insert second VLAN tag (SVID) in upstream direction
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Tibit OLT and ONU is activated using VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA
-### Test Procedure
+## Test Procedure
+
* On Spirent, send untagged traffic in upstream direction
* On the receiving port end, capture traffic and verify the VLAN parameters
-### Pass/Fail Criteria:
-* Upstream:
-o configure on the Spirent side to send untagged traffic (NO vlan configure)
-o OLT and ONT will add 1025 ,1025 respectively (i.e. 1025,1025)
-o Captured frame should contain 1025, 1025 vlan
+## Pass/Fail Criteria
+* Upstream:
+ * configure on the Spirent side to send untagged traffic (NO vlan configure)
+ * OLT and ONT will add 1025 ,1025 respectively (i.e. 1025,1025)
+ * Captured frame should contain 1025, 1025 vlan
diff --git a/docs/manuals/user/labtests/T16_tibit_olt_tests_verify_qinq_downstream.md b/docs/manuals/user/labtests/T16_tibit_olt_tests_verify_qinq_downstream.md
index 3724dc3..d7cfe1d 100644
--- a/docs/manuals/user/labtests/T16_tibit_olt_tests_verify_qinq_downstream.md
+++ b/docs/manuals/user/labtests/T16_tibit_olt_tests_verify_qinq_downstream.md
@@ -1,20 +1,23 @@
-## T16 - Spirent - Verify 802.1ad (QinQ) Downstream
+# T16 - Spirent - Verify 802.1ad (QinQ) Downstream
-### Test Objective
+## Test Objective
* Purpose of this test is to verify OLT (DNX) can strip SVID from the incoming packets and forward only with CVID to ONU
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Tibit OLT and ONU is activated using VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA
-### Test Procedure
+## Test Procedure
+
* On Spirent, configure double tagged traffic in downstream direction (1025,1025)
* On the receiving port, capture traffic and verify the VLAN parameters
-### Pass/Fail Criteria
+## Pass/Fail Criteria
+
* Downstream:
- * configure on the Spirent side to send traffic with 1025,1025
- * OLT will strip the 1025 and send traffic to corresponding ONT ( i.e. 1025 to ONT)
- * Captured frame should contain only one VLAN tag (1025 VLAN)
+ * configure on the Spirent side to send traffic with 1025,1025
+ * OLT will strip the 1025 and send traffic to corresponding ONT ( i.e. 1025 to ONT)
+ * Captured frame should contain only one VLAN tag (1025 VLAN)
diff --git a/docs/manuals/user/labtests/T17_tibit_olt_tests_verify_ipv4_downstream.md b/docs/manuals/user/labtests/T17_tibit_olt_tests_verify_ipv4_downstream.md
index 226a9ea..33807ee 100644
--- a/docs/manuals/user/labtests/T17_tibit_olt_tests_verify_ipv4_downstream.md
+++ b/docs/manuals/user/labtests/T17_tibit_olt_tests_verify_ipv4_downstream.md
@@ -1,24 +1,27 @@
-## T17 - Spirent - Verify IPv4 Unicast Streams Downstream
+# T17 - Spirent - Verify IPv4 Unicast Streams Downstream
-### Test Objective
+## Test Objective
* Purpose of this test is to verify OLT and ONU can handle double tagged traffic
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Tibit OLT and ONU is activated using VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA
-### Test Procedure
+## Test Procedure
+
* On Spirent, configure double tagged traffic in downstream direction (1025,1025)
* On Spirent, send untagged traffic in upstream direction
* On the both ports capture traffic and verify the stream
-### Pass / Fail Criteria
+## Pass / Fail Criteria
+
* Upstream:
- * configure on the Spirent side to send traffic with NO vlan
- * OLT and ONT will add 1025 ,1025 respectively (i.e. 1025,1025)
+ * configure on the Spirent side to send traffic with NO vlan
+ * OLT and ONT will add 1025 ,1025 respectively (i.e. 1025,1025)
* Downstream:
- * configure on the Spirent side to send traffic with 1025,1025
- * OLT will strip the 1025 and send traffic to corresponding ONT ( i.e. 1025 to ONT)
+ * configure on the Spirent side to send traffic with 1025,1025
+ * OLT will strip the 1025 and send traffic to corresponding ONT ( i.e. 1025 to ONT)
diff --git a/docs/manuals/user/labtests/T18_tibit_olt_tests_verify_ipv4_downstream_case2.md b/docs/manuals/user/labtests/T18_tibit_olt_tests_verify_ipv4_downstream_case2.md
index c176c99..09b933c 100644
--- a/docs/manuals/user/labtests/T18_tibit_olt_tests_verify_ipv4_downstream_case2.md
+++ b/docs/manuals/user/labtests/T18_tibit_olt_tests_verify_ipv4_downstream_case2.md
@@ -1,17 +1,20 @@
-## T18 - Spirent - Verify IPv4 Unicast Streams Downstream Case2
+# T18 - Spirent - Verify IPv4 Unicast Streams Downstream Case2
-### Test Objective
+## Test Objective
* Purpose of this test is to verify P-BIT parameter is propagated to C-VID when sending downstream traffic to ONU
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Tibit OLT and ONU is activated using VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA
-### Test Procedure
+## Test Procedure
+
* On Spirent, configure P-BIT for CVID. ex: set P-BIT value to 3
* On the Receive port end, capture traffic and verify the P-BIT parameter on SVID in Up stream direction
-### Pass / Fail Criteria
+## Pass / Fail Criteria
+
* P-BIT value s-VID is copied to C-VID in downstream direction
diff --git a/docs/manuals/user/labtests/T19_tibit_olt_tests_ranging.md b/docs/manuals/user/labtests/T19_tibit_olt_tests_ranging.md
index 57a4c6c..c64d2c2 100644
--- a/docs/manuals/user/labtests/T19_tibit_olt_tests_ranging.md
+++ b/docs/manuals/user/labtests/T19_tibit_olt_tests_ranging.md
@@ -1,13 +1,15 @@
-## T19 - 10k and 20k ONU Ranging
+# T19 - 10k and 20k ONU Ranging
-### Test Objective
+## Test Objective
* Purpose of this test is to verify ONU can range with 10km and 20 KM distance
-### Test Configuration
+## Test Configuration
+
* Test Setup is as shown in earlier sections
-### Test Procedure
+## Test Procedure
+
* Register the ONU with the OLT across a 10KM fiber spool
* Activate the OLT and ONU using VOLTHA
* Confirm OLT and ONU have the oper_status of ```ACTIVE``` in VOLTHA
@@ -16,8 +18,8 @@
* Confirm OLT and ONU have the oper_status of ```ACTIVE``` in VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA and send traffic
-### Pass / Fail Criteria
+## Pass / Fail Criteria
+
* OLT can range the ONU successfully with 10 KM distance
* OLT can range the ONU successfully with 20 KM distance
* Traffic flows successfully with 20 KM distance without any drops
-
diff --git a/docs/manuals/user/labtests/T20_tibit_olt_tests_mib.md b/docs/manuals/user/labtests/T20_tibit_olt_tests_mib.md
index 0055aeb..76dab12 100644
--- a/docs/manuals/user/labtests/T20_tibit_olt_tests_mib.md
+++ b/docs/manuals/user/labtests/T20_tibit_olt_tests_mib.md
@@ -1,15 +1,17 @@
-## T20 - MIB Download and Upload
+# T20 - MIB Download and Upload
-### Test Objective
+## Test Objective
* Purpose of this test is to verify OMCI MIB is downloaded from OLT to ONU and vice versa as part of ONU ranging process
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
-### Test Procedure
+## Test Procedure
+
* Activate the Tibit OLT and ONU using VOLTHA
-### Pass / Fail Criteria
-* Once the ONU ranges, OMCI MIB is downloaded from OLT to ONU and vice versa
+## Pass / Fail Criteria
+* Once the ONU ranges, OMCI MIB is downloaded from OLT to ONU and vice versa
diff --git a/docs/manuals/user/labtests/T21_tibit_olt_tests_2000_byte_frames.md b/docs/manuals/user/labtests/T21_tibit_olt_tests_2000_byte_frames.md
index a319aa4..db5cb59 100644
--- a/docs/manuals/user/labtests/T21_tibit_olt_tests_2000_byte_frames.md
+++ b/docs/manuals/user/labtests/T21_tibit_olt_tests_2000_byte_frames.md
@@ -1,19 +1,20 @@
-## T21 - 9200 byte Frames
+# T21 - 9200 byte Frames
-### Test Objective
+## Test Objective
* Purpose of this test is to verify OLT and ONU can accept and forward
traffic when the frame size of equals 9200 bytes
-### Test Configuration
+## Test Configuration
* Test Setup is as shown in earlier sections
* Tibit OLT and ONU is activated using VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA
-### Test Procedure
+## Test Procedure
+
* Send data/unicast traffic with frame size of 9200 Bytes in upstream and downstream direction
-### Pass / Fail Criteria
-* OLT & ONU can accept and forward frames of size 9200 Bytes successfully
+## Pass / Fail Criteria
+* OLT & ONU can accept and forward frames of size 9200 Bytes successfully
diff --git a/docs/manuals/user/labtests/T22_tibit_olt_tests_data_and_video.md b/docs/manuals/user/labtests/T22_tibit_olt_tests_data_and_video.md
index 0a15749..73412d6 100644
--- a/docs/manuals/user/labtests/T22_tibit_olt_tests_data_and_video.md
+++ b/docs/manuals/user/labtests/T22_tibit_olt_tests_data_and_video.md
@@ -1,17 +1,20 @@
-## T22 - Simultaneous Data and Video Streams
+# T22 - Simultaneous Data and Video Streams
-### Test Objective
+## Test Objective
* Purpose of this test is to verify OLT and ONU can handle data and multicast traffic
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Tibit OLT and ONU is activated using VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA
* Provision Multicast/IGMP service on the ONU from VOLTHA
-### Test Procedure
+## Test Procedure
+
* Send bi-directional data traffic and multicast traffic on the ONU
-### Expected Result
+## Expected Result
+
* Bi-directional data Traffic and Multicast traffic on the ONU went through successfully
diff --git a/docs/manuals/user/labtests/T23_tibit_olt_tests_overnight.md b/docs/manuals/user/labtests/T23_tibit_olt_tests_overnight.md
index 5c07be6..977f171 100644
--- a/docs/manuals/user/labtests/T23_tibit_olt_tests_overnight.md
+++ b/docs/manuals/user/labtests/T23_tibit_olt_tests_overnight.md
@@ -1,17 +1,20 @@
-## T23 - Overnight Traffic Test
+# T23 - Overnight Traffic Test
-### Test Objective
+## Test Objective
* Purpose of this test is to verify overnight traffic test went through successfully with zero drops
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Tibit OLT and ONU is activated using VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA
* Provision Multicast/IGMP service on the ONU from VOLTHA
-### Test Procedure
+## Test Procedure
+
* Send bi-directional data and multicast traffic over night and monitor for traffic drops
-### Pass / Fail Criteria:
+## Pass / Fail Criteria
+
* Bi-directional traffic went through overnight and no traffic drops
diff --git a/docs/manuals/user/labtests/T24_tibit_olt_tests_ha_fiber_disconnect.md b/docs/manuals/user/labtests/T24_tibit_olt_tests_ha_fiber_disconnect.md
index 1042f54..8c48bd9 100644
--- a/docs/manuals/user/labtests/T24_tibit_olt_tests_ha_fiber_disconnect.md
+++ b/docs/manuals/user/labtests/T24_tibit_olt_tests_ha_fiber_disconnect.md
@@ -1,18 +1,21 @@
-## T24 - Traffic Recovers After Fiber Disconnect (Best Effort)
+# T24 - Traffic Recovers After Fiber Disconnect (Best Effort)
-### Test Objective
+## Test Objective
* Purpose of this test is to verify pull & re-insert of PON cable can resume the traffic on the ONU
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Tibit OLT and ONU is activated using VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA
-### Test Procedure
+## Test Procedure
+
* Now manually pull the fiber cable the from ONU
* Re-insert the fiber cable to the ONU and verify ONU is ranges and traffic restores
-### Pass / Fail Criteria
+## Pass / Fail Criteria
+
* Traffic stopped when cable is pulled from ONU
* After cable insert, ONU is ranged back and traffic starts flowing automatically on the ONU
diff --git a/docs/manuals/user/labtests/T25_tibit_olt_tests_ha_onu_reset.md b/docs/manuals/user/labtests/T25_tibit_olt_tests_ha_onu_reset.md
index fcc8bb4..cd8ebce 100644
--- a/docs/manuals/user/labtests/T25_tibit_olt_tests_ha_onu_reset.md
+++ b/docs/manuals/user/labtests/T25_tibit_olt_tests_ha_onu_reset.md
@@ -1,19 +1,21 @@
-## T25 - Traffic Recovers After ONU Reset (Best Effort)
+# T25 - Traffic Recovers After ONU Reset (Best Effort)
-### Test Objective
+## Test Objective
* Purpose of this test is to verify reset/reboot of ONU is able to recover the traffic on the ONU
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Tibit OLT and ONU is activated using VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA
-### Test Procedure
+## Test Procedure
+
* Now manually reset /reboot the ONU
* Verify whether ONU ranges and traffic is restored successfully
-### Pass / Fail Criteria
+## Pass / Fail Criteria
+
* Traffic should stop flowing when ONU is restarted
* After ONU is up, traffic restores automatically on the ONU
-
diff --git a/docs/manuals/user/labtests/T26_tibit_olt_tests_ha_olt_reset.md b/docs/manuals/user/labtests/T26_tibit_olt_tests_ha_olt_reset.md
index eed3f98..1f59252 100644
--- a/docs/manuals/user/labtests/T26_tibit_olt_tests_ha_olt_reset.md
+++ b/docs/manuals/user/labtests/T26_tibit_olt_tests_ha_olt_reset.md
@@ -1,21 +1,21 @@
-## T26 - Traffic Recovers After OLT Reset (Best Effort)
+# T26 - Traffic Recovers After OLT Reset (Best Effort)
-### Test Objective
+## Test Objective
* Purpose of this test is to verify reset/reboot of ONU is able to recover the traffic on the ONU
-### Test Configuration
+## Test Configuration
* Test Setup as shown in Section – 7
* Tibit OLT and ONU is activated using VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA
-### Test Procedure
+## Test Procedure
* Now reset /reboot the OLT
* Verify OLT is up, ONU ranges and traffic is restored successfully
-### Pass / Fail Criteria
+## Pass / Fail Criteria
* When OLT is up, ONU ranges back and traffic restores automatically on the ONU
diff --git a/docs/manuals/user/labtests/T27_tibit_olt_tests_ha_tor_switch_reset.md b/docs/manuals/user/labtests/T27_tibit_olt_tests_ha_tor_switch_reset.md
index 87cd8d2..8250c0b 100644
--- a/docs/manuals/user/labtests/T27_tibit_olt_tests_ha_tor_switch_reset.md
+++ b/docs/manuals/user/labtests/T27_tibit_olt_tests_ha_tor_switch_reset.md
@@ -1,18 +1,20 @@
-## T27 - Traffic Recovers After ToR Switch Reset (Best Effort)
+# T27 - Traffic Recovers After ToR Switch Reset (Best Effort)
-### Test Objective
+## Test Objective
* Purpose of this test is to verify reset/reboot of TOR switch is able to recover the traffic
-### Test Configuration
+## Test Configuration
+
* Test Setup as shown in Section – 7
* Tibit OLT and ONU is activated using VOLTHA
* Provision HSIA/unicast service on the OLT and connected ONU from VOLTHA
-### Test Procedure
+## Test Procedure
+
* Now reset /reboot the TOR switch
* Verify TOR is up, Traffic is restored successfully
-### Pass / Fail Criteria
-* Traffic should stop flowing when TOR switch is restarted. Once the TOR switch is up, Traffic restored successfully on the ONU
+## Pass / Fail Criteria
+* Traffic should stop flowing when TOR switch is restarted. Once the TOR switch is up, Traffic restored successfully on the ONU
diff --git a/docs/manuals/user/labtests/V00_voltha.md b/docs/manuals/user/labtests/V00_voltha.md
index 17956c4..76bcffd 100644
--- a/docs/manuals/user/labtests/V00_voltha.md
+++ b/docs/manuals/user/labtests/V00_voltha.md
@@ -2,11 +2,11 @@
Test steps in this section serve the following purpose:
-1. Deploys Voltha and its companion containers
-1. Verifies base-line operation of Voltha
-1. Introduces the tester to basic Voltha operations, such as
- * curl/web browser based REST APIs
- * Swagger UI
- * Craft CLI
- * Log streams and log collection
- * Asynchronous events published by Voltha
+* Deploys Voltha and its companion containers
+* Verifies base-line operation of Voltha
+* Introduces the tester to basic Voltha operations, such as
+ * curl/web browser based REST APIs
+ * Swagger UI
+ * Craft CLI
+ * Log streams and log collection
+ * Asynchronous events published by Voltha
diff --git a/docs/manuals/user/labtests/V00_voltha_bringup.md b/docs/manuals/user/labtests/V00_voltha_bringup.md
index 4495021..2f81095 100644
--- a/docs/manuals/user/labtests/V00_voltha_bringup.md
+++ b/docs/manuals/user/labtests/V00_voltha_bringup.md
@@ -1,2 +1 @@
# Voltha Bringup
-
diff --git a/docs/manuals/user/labtests/V01_voltha_bringup_deploy.md b/docs/manuals/user/labtests/V01_voltha_bringup_deploy.md
index 2667d56..c6c69af 100644
--- a/docs/manuals/user/labtests/V01_voltha_bringup_deploy.md
+++ b/docs/manuals/user/labtests/V01_voltha_bringup_deploy.md
@@ -1,130 +1,116 @@
-## V1 - Deploy Voltha and Verify its Vital Signs
+# V1 - Deploy Voltha and Verify its Vital Signs
-### Test Objective
+## Test Objective
-* Purpose of this test is to launch Voltha together with all of its dependencies
- and verify that all are in working condition,
+* Purpose of this test is to launch Voltha together with all of its dependencies and verify that all are in working condition,
-### Test Configuration
+## Test Configuration
-* This test setup requires only the test server and it should have been prepared
- as described in the [preparation](preparations.md) section.
+* This test setup requires only the test server and it should have been prepared as described in the [preparation](preparations.md) section.
* Voltha has not been running yet (will verify it in the process)
* Test server has been prepared as above
-### Test Procedure
+## Test Procedure
* Login to the test server with standard user credentials
* Navigate to the Voltha installation directory. For example:
- ```
- cd cord/incubator/voltha
- ```
+```shell
+cd cord/incubator/voltha
+```
* Source the environment:
-
- ```
- source env.sh
- ```
-
+
+```shell
+source env.sh
+```
+
* Verify that no docker containers are running on the server:
-
- ```
- docker ps -a
- ```
-
- This shall show only a title line, but no containers. If any containers
- are running, you can terminate them as follows:
-
- ```
- docker ps -a | grep -v CONT | awk '{print $1}' | xargs docker rm -f
- ```
-
-* Launch Voltha and it companion containers (the "test deployment ensemble")
- using docker-compose in the background:
-
- ```
- docker-compose -f compose/docker-compose-system-test.yml up -d
- ```
-
- Note: The expected outcome is show below. Order is not important.
-
- ```
- Creating compose_fluentd_1
- Creating compose_consul_1
- Creating compose_registrator_1
- Creating compose_voltha_1
- Creating compose_ofagent_1
- Creating compose_chameleon_1
- Creating compose_netconf_1
- Creating compose_zookeeper_1
- Creating compose_kafka_1
- Creating compose_grafana_1
- Creating compose_shovel_1
- ```
- Note: We need to make sure the ponmgmt bridge can forward multicast mac addresses
+```shell
+docker ps -a
+```
- ```
- echo 8 > /sys/class/net/ponmgmt/bridge/group_fwd_mask
- ```
+This shall show only a title line, but no containers. If any containers
+are running, you can terminate them as follows:
-### Pass/Fail Criteria (Installation Checkpoint)
+```shell
+docker ps -a | grep -v CONT | awk '{print $1}' | xargs docker rm -f
+```
+
+* Launch Voltha and it companion containers (the "test deployment ensemble")using docker-compose in the background:
+
+```shell
+docker-compose -f compose/docker-compose-system-test.yml up -d
+```
+
+Note: The expected outcome is show below. Order is not important.
+
+```shell
+Creating compose_fluentd_1
+Creating compose_consul_1
+Creating compose_registrator_1
+Creating compose_voltha_1
+Creating compose_ofagent_1
+Creating compose_chameleon_1
+Creating compose_netconf_1
+Creating compose_zookeeper_1
+Creating compose_kafka_1
+Creating compose_grafana_1
+Creating compose_shovel_1
+```
+
+Note: We need to make sure the ponmgmt bridge can forward multicast mac addresses
+
+```shell
+echo 8 > /sys/class/net/ponmgmt/bridge/group_fwd_mask
+```
+
+## Pass/Fail Criteria (Installation Checkpoint)
* The installation steps to this point should complete without errors.
-* Please check that docker-compose shows all containers as running. In the same
-Linux terminal, please issue the following command:
-
- ```
- docker-compose -f compose/docker-compose-system-test.yml ps
- ```
-
- This shall list all containers being in the "Up" state. Expected output (lines are
- truncated omitting the long port mapping information):
-
- ```
- Name Command State ...
- -------------------------------------------------------------------------...
- compose_chameleon_1 /chameleon/chameleon/main. ... Up 0.0.0.0:...
- compose_consul_1 docker-entrypoint.sh agent ... Up 0.0.0.0:...
- compose_fluentd_1 /bin/sh -c exec fluentd -c ... Up 0.0.0.0:...
- compose_grafana_1 /usr/bin/supervisord Up 0.0.0.0:...
- compose_kafka_1 start-kafka.sh Up 0.0.0.0:...
- compose_netconf_1 /netconf/netconf/main.py - ... Up 0.0.0.0:...
- compose_ofagent_1 /ofagent/ofagent/main.py - ... Up
- compose_registrator_1 /bin/registrator -ip=10.0. ... Up
- compose_shovel_1 /shovel/shovel/main.py --k ... Up
- compose_voltha_1 /voltha/voltha/main.py -v ... Up 0.0.0.0:...
- compose_zookeeper_1 /bin/sh -c /usr/sbin/sshd ... Up 0.0.0.0:...
- ```
-
- Shovel is known to have some startup race condition issues. If it is shown
- in the "Exited" state, a single attempt can be made to restart it, after which
- it should be healthy. To restart it, execute:
-
- ```
- docker-compose -f compose/docker-compose-system-test.yml scale shovel=1
- ```
-
- and repeat the above "ps" command to view the ensemble state:
-
- ```
- docker-compose -f compose/docker-compose-system-test.yml ps
- ```
-
-* Point a Web Browser to the Consul UI to verify that all components are properly
-registered.
+* Please check that docker-compose shows all containers as running. In the same Linux terminal, please issue the following command:
- Point your browser to ```http://<server-ip-or-hostname>:8500/ui```
-using the actual IP address or valid DNS name of your Voltha
-server. The expected view is similar to the following:
+```shell
+docker-compose -f compose/docker-compose-system-test.yml ps
+```
- 
+This shall list all containers being in the "Up" state. Expected output (lines are truncated omitting the long port mapping information):
- Here every single exposed service end-point is shown (some components expose
- multiple end-points, while others expose no public endpoints).
-
- Clicking on any of the items reveal further information like the specific IP
- address(es) and port number(s) for the service.
+```shell
+ Name Command State ...
+-------------------------------------------------------------------------...
+compose_chameleon_1 /chameleon/chameleon/main. ... Up 0.0.0.0:...
+compose_consul_1 docker-entrypoint.sh agent ... Up 0.0.0.0:...
+compose_fluentd_1 /bin/sh -c exec fluentd -c ... Up 0.0.0.0:...
+compose_grafana_1 /usr/bin/supervisord Up 0.0.0.0:...
+compose_kafka_1 start-kafka.sh Up 0.0.0.0:...
+compose_netconf_1 /netconf/netconf/main.py - ... Up 0.0.0.0:...
+compose_ofagent_1 /ofagent/ofagent/main.py - ... Up
+compose_registrator_1 /bin/registrator -ip=10.0. ... Up
+compose_shovel_1 /shovel/shovel/main.py --k ... Up
+compose_voltha_1 /voltha/voltha/main.py -v ... Up 0.0.0.0:...
+compose_zookeeper_1 /bin/sh -c /usr/sbin/sshd ... Up 0.0.0.0:...
+```
+Shovel is known to have some startup race condition issues. If it is shown in the "Exited" state, a single attempt can be made to restart it, after which it should be healthy. To restart it, execute:
+
+```shell
+docker-compose -f compose/docker-compose-system-test.yml scale shovel=1
+```
+
+and repeat the above "ps" command to view the ensemble state:
+
+```shell
+docker-compose -f compose/docker-compose-system-test.yml ps
+```
+
+* Point a Web Browser to the Consul UI to verify that all components are properly registered.
+
+Point your browser to <http://<server-ip-or-hostname>:8500/ui> using the actual IP address or valid DNS name of your Voltha server. The expected view is similar to the following:
+
+
+
+Here every single exposed service end-point is shown (some components expose multiple end-points, while others expose no public endpoints).
+
+Clicking on any of the items reveal further information like the specific IP address(es) and port number(s) for the service.
diff --git a/docs/manuals/user/labtests/V02_voltha_bringup_rest.md b/docs/manuals/user/labtests/V02_voltha_bringup_rest.md
index d3cfa08..6d0fd49 100644
--- a/docs/manuals/user/labtests/V02_voltha_bringup_rest.md
+++ b/docs/manuals/user/labtests/V02_voltha_bringup_rest.md
@@ -1,153 +1,142 @@
-## V2 - Connect to Voltha with REST and Web Browser or Curl
+# V2 - Connect to Voltha with REST and Web Browser or Curl
-### Test Objective
+## Test Objective
* The purpose of this test is to verify REST-based HTTPS connectivity to Voltha, including
- * Swagger UI access for exploring APIs
- * Command-line REST requests using curl
+ * Swagger UI access for exploring APIs
+ * Command-line REST requests using curl
-### Test Configuration
+## Test Configuration
* Preparatory steps completed
* Test-case V1 completed successfully
-### Test Procedure
+## Test Procedure
-To conveniently explore the REST APIs exposed by Voltha, point your browser to the default REST port on the
-Voltha integrartion server's Swagger end-point using the URL
-```https://<server>:<chameleon-port>/#/VolthaLocalService```, where
+To conveniently explore the REST APIs exposed by Voltha, point your browser to the default REST port on the Voltha integrartion server's Swagger end-point using the URL ```https://<server>:<chameleon-port>/#/VolthaLocalService```, where:
-* ```<server>``` is the IP address or hostname of your Voltha integration server,
-* ```<chameleon-port``` is the TCP port assigned to the Chameleon REST front-end.
-In a real depoyment this port will be served by a load balancer using a fixed port
-number, but in the integration setup this port number is a port assigned by Docker.
+* *server* is the IP address or hostname of your Voltha integration server
+* *chameleon-port* is the TCP port assigned to the Chameleon REST front-end
+
+In a real depoyment this port will be served by a load balancer using a fixed port number, but in the integration setup this port number is a port assigned by Docker.
+
To find out what the port is, do either of the following:
- You can look up the port number using docker. On the integration server, run:
-
- ```
- docker inspect compose_chameleon_1 | \
- jq -r '.[0].NetworkSettings.Ports["8881/tcp"][0].HostPort'
- ```
-
- This should print the port number that is mapped to the Chameleon internal
- REST port. In our case it printed the following:
-
- ```
- 32794
- ```
-
- Alternatively, you can use a DNS lookup. The Consul process in the Voltha
- ensamble also works as a DNS server and supports service record lookup. So
- you can use ```dig``` to lookup the port number. One way to do this is to issue
- the following command on *the integration server*:
-
- ```
- dig @localhost -p 8600 +short chameleon-rest.service.consul SRV
- ```
-
- This basically requests for the service record (SRV) for the service
- registered with Consul as ```chameleon-rest``` end-point. Example output:
-
- ```
- 1 1 32794 0a00020f.addr.dc1.consul.
- ```
-
- The 3rd field is the port number.
-
- Either way, make note of the port-number and use this to talk to the REST APIs.
-
- Using the proper URL, which in our case was
- ```https://10.100.198.220:32794/#/VolthaLocalService``` shall lead you to the
- following view in your browser:
+You can look up the port number using docker. On the integration server, run:
- 
+```shell
+docker inspect compose_chameleon_1 | jq -r '.[0].NetworkSettings.Ports["8881/tcp"][0].HostPort'
+```
- Swagger allows the user to browse in the APIs and try any of the APIs with
- relative ease. For instance, to list all adapters registered with Voltha, open
- up the ```/api/v1/local/adapters``` entry:
+This should print the port number that is mapped to the Chameleon internal REST port. In our case it printed the following:
- 
+```shell
+32794
+```
- To try this API, click on the *Try it out!* button. The response will show
- up below it:
+Alternatively, you can use a DNS lookup. The Consul process in the Voltha ensamble also works as a DNS server and supports service record lookup. So you can use ```dig``` to lookup the port number. One way to do this is to issuethe following command on *the integration server*:
- 
+```shell
+dig @localhost -p 8600 +short chameleon-rest.service.consul SRV
+```
-* The REST API can be consumed via any REST client. Here we verify that the Unix
- tool ```curl``` can be used. Here are a couple of examples:
-
- For convenience, setup an env var for the b ase URL:
-
- ```
- export VOLTHAURL='https://10.100.198.220:32794/api/v1/local'
- ```
-
- To show the health status of Voltha:
-
- ```
- curl -k -s $VOLTHAURL/health | jq '.'
- ```
- Expect to see:
+This basically requests for the service record (SRV) for the service
+registered with Consul as ```chameleon-rest``` end-point. Example output:
+
+```shell
+1 1 32794 0a00020f.addr.dc1.consul.
+```
+
+The 3rd field is the port number.
+
+Either way, make note of the port-number and use this to talk to the REST APIs.
+
+Using the proper URL, which in our case was <https://10.100.198.220:32794/#/VolthaLocalService> shall lead you to the following view in your browser:
+
+
+
+Swagger allows the user to browse in the APIs and try any of the APIs with relative ease. For instance, to list all adapters registered with Voltha, open up the */api/v1/local/adapters* entry:
- ```
+
+
+To try this API, click on the *Try it out!* button. The response will show up below it:
+
+
+
+* The REST API can be consumed via any REST client. Here we verify that the Unix tool *curl* can be used. Here are a couple of examples:
+
+For convenience, setup an env var for the b ase URL:
+
+```shell
+export VOLTHAURL='https://10.100.198.220:32794/api/v1/local'
+```
+
+To show the health status of Voltha:
+
+```shell
+curl -k -s $VOLTHAURL/health | jq '.'
+```
+
+Expect to see:
+
+```json
{
"state": "HEALTHY"
}
- ```
-
- To show the list of loaded adapters in Voltha
-
- ```
- curl -k -s $VOLTHAURL/adapters | jq '.'
- ```
- Expect to see a list similar to this snippet (we show here only the beginning):
-
- ```
- {
- "items": [
- {
- "config": {
- "log_level": "INFO"
- },
- "version": "0.1",
- "vendor": "Voltha project",
- "id": "broadcom_onu",
- "logical_device_ids": []
- },
- {
- "config": {
- "log_level": "INFO"
- },
- "version": "0.1",
- "vendor": "Voltha project",
- "id": "maple_olt",
- "logical_device_ids": []
- },
- ...
- ...
- ```
-
- You can list only the names of the adapters:
-
- ```
- curl -k -s $VOLTHAURL/adapters | jq '.items[].id'
- ```
-
- This will show something like:
-
- ```
- "broadcom_onu"
- "maple_olt"
- "ponsim_olt"
- "ponsim_onu"
- "simulated_olt"
- "simulated_onu"
- "tibit_olt"
- "tibit_onu"
- ```
+```
-### Pass/Fail Criteria
+To show the list of loaded adapters in Voltha
-This test case should be considered passing if all the demonstrated behavior
-works with similar (but not necessarily identical) output.
+```shell
+curl -k -s $VOLTHAURL/adapters | jq '.'
+```
+
+Expect to see a list similar to this snippet (we show here only the beginning):
+
+```json
+{
+ "items": [
+ {
+ "config": {
+ "log_level": "INFO"
+ },
+ "version": "0.1",
+ "vendor": "Voltha project",
+ "id": "broadcom_onu",
+ "logical_device_ids": []
+ },
+ {
+ "config": {
+ "log_level": "INFO"
+ },
+ "version": "0.1",
+ "vendor": "Voltha project",
+ "id": "maple_olt",
+ "logical_device_ids": []
+ },
+ ...
+ ...
+```
+
+You can list only the names of the adapters:
+
+```shell
+curl -k -s $VOLTHAURL/adapters | jq '.items[].id'
+```
+
+This will show something like:
+
+```shell
+"broadcom_onu"
+"maple_olt"
+"ponsim_olt"
+"ponsim_onu"
+"simulated_olt"
+"simulated_onu"
+"tibit_olt"
+"tibit_onu"
+```
+
+## Pass/Fail Criteria
+
+This test case should be considered passing if all the demonstrated behavior works with similar (but not necessarily identical) output.
diff --git a/docs/manuals/user/labtests/V03_voltha_bringup_cli.md b/docs/manuals/user/labtests/V03_voltha_bringup_cli.md
index 836437f..93be3e5 100644
--- a/docs/manuals/user/labtests/V03_voltha_bringup_cli.md
+++ b/docs/manuals/user/labtests/V03_voltha_bringup_cli.md
@@ -1,26 +1,25 @@
-## V3 - Connect to Voltha via its CLI
+# V3 - Connect to Voltha via its CLI
-### Test Objective
+## Test Objective
* Verify Voltha CLI is available
-* Provide an introduction to the CLI, since it is used in many of the other
- testcases
+* Provide an introduction to the CLI, since it is used in many of the other testcases
-### Test Configuration
+## Test Configuration
* Voltha ensemble is instantiated (V1)
-### Test Procedure
+## Test Procedure
Start the Voltha CLI:
-```
+```shell
cd $VOLTHA_BASE
./cli/main.py -L
```
You should see it launched:
-```
+```shell
_ _ _ ___ _ ___
__ _____| | |_| |_ __ _ / __| | |_ _|
\ V / _ \ | _| ' \/ _` | | (__| |__ | |
@@ -29,18 +28,17 @@
(voltha)
```
-This places the user into normal mode, signified by the ```(voltha)``` prompt.
+This places the user into normal mode, signified by the *(voltha)* prompt.
To check connectivity to Voltha and to check if Voltha is "healthy", run:
-```
+```shell
health
```
The expected output is:
-```
-(voltha) health
+```json
{
"state": "HEALTHY"
}
@@ -48,14 +46,13 @@
To list all Voltha adapters, type:
-```
+```shell
adapters
```
This should show the loaded adapters:
-```
-(voltha) adapters
+```shell
Adapters:
+---------------+---------------------------+---------+------------------+
| id | vendor | version | config.log_level |
@@ -72,15 +69,15 @@
```
There are many more commands available in the CLI. To list all commands
-in ```voltha``` mode, type:
+in *voltha* mode, type:
-```
+```shell
help
```
This will show the available commands:
-```
+```shell
(voltha) help
Documented commands (type help <topic>):
@@ -96,21 +93,19 @@
EOF eof exit help quit
```
-### Brief Reference of Frequently Used CLI Commands
+## Brief Reference of Frequently Used CLI Commands
-*Please note at this point in the test sequence there are no OLTs/ONUs,
-hence the output of these commands will in fact show empty tables; some commands
-are not even available.*
+* Please note at this point in the test sequence there are no OLTs/ONUs, hence the output of these commands will in fact show empty tables; some commands are not even available.
To list all logical devices:
-```
+```shell
logical_devices
```
*Example* output:
-```
+```shell
(voltha) logical_devices
Logical devices:
+----+-------------+----------------+----------------------------------+---------------------------+--------------------------+
@@ -122,13 +117,13 @@
To list all physical devices:
-```
+```shell
devices
```
*Example* output:
-```
+```shell
(voltha) devices
Devices:
+--------------+---------------+------+--------------+------+-------------------+-------------+-------------+----------------+----------------+-------------------------+--------------------------+
@@ -144,26 +139,26 @@
To pre-provision an OLT of a certain type (e.g., maple with given IP address):
-```
+```shell
preprovision_olt -t maple_olt -i 10.11.12.13
```
*Example* output:
-```
+```shell
(voltha) preprovision_olt -t maple_olt -i 10.11.12.13
success (device id = 5a324e1c3996)
```
To activate the last pre-provisioned OLT:
-```
+```shell
enable
```
*Example* output:
-```
+```shell
(voltha) enable
activating 5a324e1c3996
waiting for device to be activated...
@@ -172,13 +167,13 @@
To activate an OLT given by its ID:
-```
+```shell
enable <ID>
```
*Example* output:
-```
+```shell
(voltha) enable
activating 5a324e1c3996
waiting for device to be activated...
@@ -187,30 +182,30 @@
To enter into a logical device context/mode:
-```
+```shell
logical_device <logical-device-ID>
```
*Example* output:
-```
+```shell
(voltha) logical_device 1
(logical device 1)
```
-This will change the prompt to ```(logical device <ID>)```.
+This will change the prompt to (logical device ```<ID>```).
Subcommands of logical device mode:
To show more info:
-```
+```shell
show
```
*Example* output:
-```
+```shell
(logical device 1) show
Logical device 1
+------------------------------+----------------------------------+
@@ -234,13 +229,13 @@
To list all ports of the logical device:
-```
+```shell
ports
```
*Example* output:
-```
+```shell
(logical device 1) ports
Logical device ports:
+-----+--------------+----------------+-----------+------------------+----------------------+---------------+----------------+---------------+---------------------+
@@ -256,13 +251,13 @@
To list all flows defined:
-```
+```shell
flows
```
*Example* output:
-```
+```shell
(logical device 1) flows
Logical Device 1 (type: n/a)
Flows (11):
@@ -286,26 +281,26 @@
To exit logical device mode:
-```
+```shell
exit
```
*Example* output:
-```
+```shell
(logical device 1) exit
(voltha)
```
To enter into a device context/mode:
-```
+```shell
device <device-ID>
```
*Example* output:
-```
+```shell
(voltha) device 5a324e1c3996
(device 5a324e1c3996)
```
@@ -314,13 +309,13 @@
To show device info:
-```
+```shell
show
```
*Example* output:
-```
+```shell
(device 5a324e1c3996) show
Device 5a324e1c3996
+------------------+----------------------------------+
@@ -352,7 +347,7 @@
*Example* output:
-```
+```shell
(device 45de16e1c63b) ports
Device ports:
+---------+--------------------------+--------------+-------------+-------------+--------------+------------------------------------------------+
@@ -365,13 +360,13 @@
To show all flows defined on device:
-```
+```shell
flows
```
*Example* output:
-```
+```shell
(device 5a324e1c3996) flows
Device 5a324e1c3996 (type: simulated_olt)
Flows (7):
@@ -390,7 +385,7 @@
To exit device mode:
-```
+```shell
exit
```
@@ -398,7 +393,7 @@
To enter "test" mode from normal CLI mode:
-```
+```shell
test
```
@@ -406,31 +401,31 @@
To install just the EAPOL upstream forwarding flow:
-```
+```shell
install_eapol_flow [<logical-device-ID>]
```
To install all controller bound forwarding flows:
-```
+```shell
install_all_controller_bound_flows [<logical-device-ID>]
```
To install all flows relevant in our use-case (upstream forwarding rules, unicast data flows, and a few multicast flows):
-```
+```shell
install_all_sample_flows [<logical-device-ID>]
```
To remove all flows from a logical device:
-```
+```shell
delete_all_flows [<logical-device-ID>]
```
Here is a sample CLI command sequence that preprovisions and activates an OLT, then downloads all sample flows and check the flows installed on the OLT device:
-```
+```shell
test
preprovision_olt -t maple_olt -i 10.11.12.13
enable
@@ -441,7 +436,7 @@
exit
```
-### Pass/Fail Criteria
+## Pass/Fail Criteria
* CLI should start
* Health should show "HEALTHY"
diff --git a/docs/manuals/user/labtests/V04_voltha_bringup_async.md b/docs/manuals/user/labtests/V04_voltha_bringup_async.md
index bd613ad..f5a4a10 100644
--- a/docs/manuals/user/labtests/V04_voltha_bringup_async.md
+++ b/docs/manuals/user/labtests/V04_voltha_bringup_async.md
@@ -1,6 +1,6 @@
-## V4 - View Voltha Async Events with Kafkacat
+# V4 - View Voltha Async Events with Kafkacat
-### Test Objective
+## Test Objective
* Demonstrate and verify the async event stream (output) from Voltha
@@ -8,62 +8,45 @@
There are four types of events emitted by Kafka, using four separate Kafka
"topics":
-* *heartbeat*: Voltha emits a periodic heart-beat through this channel. By default
-the Kafka topic name for this channel is ```voltha.heartbeat```
-* *kpi/performance metrics*: Voltha uses this channel to send out consolidated
- performance metric data about its internal components as well as about the
- devices managed by Voltha. While the channel is live, the metrics are limited
- to a few sample metrics at the moment (work in progress). By default the
- Kafka topic name for this channel is ```voltha.kpis```.
-* *alarms*: Voltha uses this channel to send out consolidated alarm signals,
-covering the devices it manages as well as alarms about its internal operation.
- This is not used yet, albeit the internal plumbing in Voltha exists. By default
- the Kafka topic name for this channel is ```voltha/alarms```.
-* *events*: Voltha uses this channel to send out consolidated async events
- (other than alarms), covering the devices it manages as well as events about
- its internal operation. This is not used yet, albeit the internal plumbing
- in Voltha exists.
- By default the Kafka topic name for this channel is ```voltha/events```.
+* *heartbeat*: Voltha emits a periodic heart-beat through this channel. By default the Kafka topic name for this channel is *voltha.heartbeat*.
+* *kpi/performance metrics*: Voltha uses this channel to send out consolidated performance metric data about its internal components as well as about the devices managed by Voltha. While the channel is live, the metrics are limited to a few sample metrics at the moment (work in progress). By default the Kafka topic name for this channel is *voltha.kpis*.
+* *alarms*: Voltha uses this channel to send out consolidated alarm signals, covering the devices it manages as well as alarms about its internal operation. This is not used yet, albeit the internal plumbing in Voltha exists. By default the Kafka topic name for this channel is *voltha/alarms*.
+* events*: Voltha uses this channel to send out consolidated async events (other than alarms), covering the devices it manages as well as events about its internal operation. This is not used yet, albeit the internal plumbing in Voltha exists. By default the Kafka topic name for this channel is *voltha/events*.
In a production deployment it is expected that other subsystems will consume
these Kafka topics.
Our goal here is to demonstrate and verify that Voltha is working as expected.
-
-### Test Configuration
+## Test Configuration
* Voltha ensemble is launched (V1)
-### Test Procedure
+## Test Procedure
-In order to show the Kafka channels, we use a command line tool ```kafkacat```
-to "tune into" the channels.
-To run kafkacat we need to know the port number of the kafka broker. Use the
- following command to retrieve the assigned port to Kafka:
+In order to show the Kafka channels, we use a command line tool *kafkacat* to "tune into" the channels.
+To run kafkacat we need to know the port number of the kafka broker. Use the following command to retrieve the assigned port to Kafka:
-```
-docker inspect compose_kafka_1 | \
- jq -r '.[0].NetworkSettings.Ports["9092/tcp"][0]["HostPort"]'
+```shell
+docker inspect compose_kafka_1 | jq -r '.[0].NetworkSettings.Ports["9092/tcp"][0]["HostPort"]'
```
For example, it may say:
-```
+```shell
32769
```
This is the port number Kafka is reacheable at the integration server.
-To show the topics that have data, run the command (make sure you use the
-port number that you retreived in the above step):
+To show the topics that have data, run the command (make sure you use the port number that you retreived in the above step):
-```
+```shell
kafkacat -b localhost:32769 -L
```
Here is what you should see:
-```
+```shell
(venv-linux) ubuntu@voltha:/voltha$ kafkacat -b localhost:32769 -L
Metadata for all topics (from broker -1: localhost:32769/bootstrap):
1 brokers:
@@ -81,18 +64,15 @@
In order to show data published to the heartbeat channel, use the following
command (*Make sure you use the correct port number!*):
-```
-kafkacat -b localhost:32769 -C -t voltha.heartbeat \
- -f 'Topic %t [%p] at offset %o: key %k: %s\n'
+```shell
+kafkacat -b localhost:32769 -C -t voltha.heartbeat -f 'Topic %t [%p] at offset %o: key %k: %s\n'
```
-The above will show all existing data in the queue and will stay connected
-and print messages as they arrive ("tail" the channel). You can use Ctrl-C
-to interrupt the tailing and return to the Linux prompt.
+The above will show all existing data in the queue and will stay connected and print messages as they arrive ("tail" the channel). You can use Ctrl-C to interrupt the tailing and return to the Linux prompt.
Example output, showing only the first few lines:
-```
+```shell
(venv-linux) ubuntu@voltha:/voltha$ kafkacat -b localhost:32769 -C -t voltha.heartbeat -f 'Topic %t [%p] at offset %o: key %k: %s\n'
Topic voltha.heartbeat [0] at offset 0: key : {"ip": "172.18.0.9", "type": "heartbeat", "voltha_instance": "compose_voltha_1", "ts": 1484291374}
Topic voltha.heartbeat [0] at offset 1: key : {"ip": "172.18.0.9", "type": "heartbeat", "voltha_instance": "compose_voltha_1", "ts": 1484291384}
@@ -107,16 +87,13 @@
Similarly, you can watch KPI metrics as follows:
-```
-kafkacat -b localhost:32769 -C -t voltha.kpis \
- -f 'Topic %t [%p] at offset %o: key %k: %s\n'
+```shell
+kafkacat -b localhost:32769 -C -t voltha.kpis -f 'Topic %t [%p] at offset %o: key %k: %s\n'
```
-This may show only two Voltha metrics, yet it still verifies the proper operation
- of the KPI metric collection mechanism. A sample output is as follows, truncated
- to only the first 15 lines:
+This may show only two Voltha metrics, yet it still verifies the proper operation of the KPI metric collection mechanism. A sample output is as follows, truncated to only the first 15 lines:
-```
+```shell
(venv-linux) ubuntu@voltha:/voltha$ kafkacat -b localhost:32769 -C -t voltha.kpis -f 'Topic %t [%p] at offset %o: key %k: %s\n'
Topic voltha.kpis [0] at offset 0: key : {"data": {"voltha.internal.compose_voltha_1": {"deferreds": 20, "rss-mb": 79}}, "type": "slice", "ts": 1484291374}
Topic voltha.kpis [0] at offset 1: key : {"data": {"voltha.internal.compose_voltha_1": {"deferreds": 173, "rss-mb": 79}}, "type": "slice", "ts": 1484291389}
@@ -135,7 +112,6 @@
Topic voltha.kpis [0] at offset 14: key : {"data": {"voltha.internal.compose_voltha_1": {"deferreds": 173, "rss-mb": 79}}, "type": "slice", "ts": 1484291584}
```
-### Pass/Fail Criteria
+## Pass/Fail Criteria
-* The above feeds (topics) should exist in Kafka and have data in both
-topics.
+* The above feeds (topics) should exist in Kafka and have data in both topics.
diff --git a/docs/manuals/user/labtests/old/M00_maple_olt_tests_original.md b/docs/manuals/user/labtests/old/M00_maple_olt_tests_original.md
index 4efb93c..a327ebf 100644
--- a/docs/manuals/user/labtests/old/M00_maple_olt_tests_original.md
+++ b/docs/manuals/user/labtests/old/M00_maple_olt_tests_original.md
@@ -1,11 +1,11 @@
# Maple OLT Tests
-These tests (obviously) assume access to a Maple-based OLT PON system in the test
-POD.
+These tests (obviously) assume access to a Maple-based OLT PON system in the test POD.
The tests are grouped into the following categories:
Manual step-by-step provisioning:
+
* [M1 - Preprovision and Activate OLT](M01_maple_olt_tests_activate_olt.md)
* [M2 - Activate ONU](M02_maple_olt_tests_activate_onu.md)
* [M3 - Manually Install EAPOL Forwarding Flows](M03_maple_olt_tests_eapol_install.md)
@@ -15,6 +15,7 @@
* [M7 - Test IGMP and multicast (Video) streams](M07_maple_olt_tests_multicast.md)
ONOS-base System Test
+
* [M8 - Reset Manually Added Flows and Launch ONOS](M08_maple_olt_tests_start_onos.md)
* [M9 - Verify RG Authentication Scenario](M09_maple_olt_tests_verify_authentication.md)
* [M10 - Verify DHCP Lookup](M10_maple_olt_tests_verify_dhcp.md)
@@ -22,6 +23,7 @@
* [M12 - Verify Multicast Access](M12_maple_olt_tests_verify_multicast.md)
Spirent-base Functional Traffic Tests
+
* [M13 - Spirent - Verify Re-Write C-VID Upstream](M13_maple_olt_tests_verify_cvid_upstream.md)
* [M14 - Spirent - Verify Re-Write C-VID Downstream](M14_maple_olt_tests_verify_cvid_downstream.md)
* [M15 - Spirent - Verify 802.1ad (QinQ) Upstream](M15_maple_olt_tests_verify_qinq_upstream.md)
@@ -30,6 +32,7 @@
* [M18 - Spirent - Verify IPv4 Unicast Streams Downstream Case2](M18_maple_olt_tests_verify_ipv4_downstream_case2.md)
Miscellaneous Randing Tests
+
* [M19 - 10k and 20k ONU Ranging](M19_maple_olt_tests_ranging.md)
* [M20 - MIB Download and Upload](M20_maple_olt_tests_mib.md)
* [M21 - 2000 byte Frames](M21_maple_olt_tests_2000_byte_frames.md)
@@ -37,7 +40,8 @@
* [M23 - Overnight Traffic Test](M23_maple_olt_tests_overnight.md)
Robustness Testing
+
* [M24 - Traffic Recovers After Fiber Disconnect (Best Effort)](M24_maple_olt_tests_ha_fiber_disconnect.md)
* [M25 - Traffic Recovers After ONU Reset (Best Effort)](M25_maple_olt_tests_ha_onu_reset.md)
* [M26 - Traffic Recovers After OLT Reset (Best Effort)](M26_maple_olt_tests_ha_olt_reset.md)
-* [M27 - Traffic Recovers After ToR Switch Reset (Best Effort)](M27_maple_olt_tests_ha_tor_switch_reset.md)
+* [M27 - Traffic Recovers After ToR Switch Reset (Best Effort)](M27_maple_olt_tests_ha_tor_switch_reset.md)
diff --git a/docs/manuals/user/labtests/old/M01_maple_olt_tests_activate_olt.md b/docs/manuals/user/labtests/old/M01_maple_olt_tests_activate_olt.md
index 8bccb8f..ed976eb 100644
--- a/docs/manuals/user/labtests/old/M01_maple_olt_tests_activate_olt.md
+++ b/docs/manuals/user/labtests/old/M01_maple_olt_tests_activate_olt.md
@@ -1,17 +1,17 @@
-## M1 - Preprovision and Activate OLT
+# M1 - Preprovision and Activate OLT
-### Test Objective
+## Test Objective
* Purpose of this test is to verify new OLT can be added and activated from VOLTHA
* VOLTHA will connect with OLT physical device and create a logical device with initial ports in its data store.
* VOLTHA will send Event notifications to ONOS and PON Manager for the newly added OLT
-### Test Configuration
+## Test Configuration
* Test Setup is as shown in Section – 7
* Maple OLT should be reachable to VOLTHA over IP interface on VLAN 4092
-### Test Procedure
+## Test Procedure
* Issue commands to VOLTHA to simulate “Add-OLT device” message coming from PON Manager on VOLTHA
* VOLTHA should initiate connect / activate request to Maple OLT
@@ -21,9 +21,8 @@
* Verify OLT/ONU Status on Device Console
* ONU should drop all the traffic coming from RG
-### Pass/Fail Criteria
+## Pass/Fail Criteria
* OLT is successfully detected and activated on VOLTHA
* Logical device and port list is created on VOLTHA and ONOS
* OLT / ONU status can be seen from Device Console
-
diff --git a/docs/manuals/user/labtests/old/M03_maple_olt_tests_eapol_install.md b/docs/manuals/user/labtests/old/M03_maple_olt_tests_eapol_install.md
index e547263..44c010e 100644
--- a/docs/manuals/user/labtests/old/M03_maple_olt_tests_eapol_install.md
+++ b/docs/manuals/user/labtests/old/M03_maple_olt_tests_eapol_install.md
@@ -1,32 +1,35 @@
-## M3 - Manually Install EAPOL Forwarding Flows
+# M3 - Manually Install EAPOL Forwarding Flows
-### Test Objective
+## Test Objective
+
* Use Voltha CLI to manually download EAPOL forwarding rule to PON network
-### Test Configuration
+## Test Configuration
+
* TBF
-### Test Procedure
+## Test Procedure
-**Step 1: If not yet running, launch Voltha CLI:**
-```
+### Step 1: If not yet running, launch Voltha CLI
+
+```shell
cd $VOLTHA_BASE
./cli/main.py -L
```
-(Note, the ```-L``` option is needed if Voltha was launched as
-a container using docker-compose.)
+(Note, the *-L* option is needed if Voltha was launched as a container using docker-compose.)
-**Step 2: Note the device ID**
-
+### Step 2: Note the device ID
+
Note the Voltha logical device ID of the PON network being tested.
If in doubt, use the following Voltha CLI command to list all devices:
-```
+
+```shell
devices
```
The output may be something like this (lines are truncated):
-```
+```shell
(voltha) devices
Devices:
+--------------+---------------+------+--------------+------+--------------...
@@ -37,20 +40,19 @@
+--------------+---------------+------+--------------+------+--------------...
```
-In this case the OLT's device id was ```25dadc44a847```
-and the logical device id shown as the parent_id for the OLT.
-In this case the logical device id is ```1```.
+In this case the OLT's device id was *25dadc44a847* and the logical device id shown as the parent_id for the OLT. In this case the logical device id is *1*.
-**Step 3: Download EAPOL forwarding rules to the PON**
+### Step 3: Download EAPOL forwarding rules to the PON
Using the test mode of the CLI, download the rules:
-```
+
+```shell
test
install_eapol_flow 1
```
-where you must use the logical device ID. The CLI provides
-TAB completion that can help too.
-### Pass/Fail Criteria
+where you must use the logical device ID. The CLI provides TAB completion that can help too.
+
+## Pass/Fail Criteria
[Zsolt to finish]
diff --git a/docs/manuals/user/labtests/preparations.md b/docs/manuals/user/labtests/preparations.md
index 1826524..613a0ce 100644
--- a/docs/manuals/user/labtests/preparations.md
+++ b/docs/manuals/user/labtests/preparations.md
@@ -6,58 +6,54 @@
Before you start, please ensure the following requirements have been met.
-* You have access to a server that was already set up for Voltha development
- and test deployments. We will call this the "Voltha server."
-* The Voltha server has access to the Internet. This is needed to download the
-latest dependencies and the latest Voltha code base.
+* You have access to a server that was already set up for Voltha development and test deployments. We will call this the "Voltha server."
+* The Voltha server has access to the Internet. This is needed to download the latest dependencies and the latest Voltha code base.
* You have local or remote access to the server.
-* In case of remote access, you know the IP address or qualified DNS name of
- the server, and can reach it.
+* In case of remote access, you know the IP address or qualified DNS name of the server, and can reach it.
* You can login using non-root account.
* Your account is sudo-ready.
-### Upgrade Steps
+## Upgrade Steps
-**Step 1: Login to server and navigate to Voltha base directory**
+* Step 1: Login to server and navigate to Voltha base directory
Assuming remote access, ssh into the server and then execute the following commands.
-```
+```shell
ssh <username>@<server-address> # and use your credentials
```
Navigate to the Voltha base dir and source the environment. For example:
-```
+```shell
cd cord/incubator/voltha
source env.sh
```
-Your exact path may differ. After the above step, the prompt should include
- the term ```venv-linux``` now.
+Your exact path may differ. After the above step, the prompt should include the term ```venv-linux``` now.
-**Step 2: Upgrade to latest Python dependencies**
+* Step 2: Upgrade to latest Python dependencies
Execute:
-```
+```shell
pip install -r requirements.txt
```
-**Step 3: Install some additional system packages needed for testing**
+* Step 3: Install some additional system packages needed for testing
Execute:
-```
+```shell
sudo apt install -y wireshark tshark npm nodejs-legacy bridge-utils
```
-**Step 4: Install oftest and olt-oftest, needed for PON-level system tests**
+* Step 4: Install oftest and olt-oftest, needed for PON-level system tests
This step is needed only if you intend to run the automated PON-level
tests. Execute:
-```
+```shell
cd $VOLTHA_BASE # if you don't have this, go back to Step 1
# Now, go up a directory so that we don't install in the voltha repo
cd ..
@@ -66,16 +62,16 @@
./mininet/util/install.sh # this may ask for your password
```
-**Step 5: Fetch latest Docker image preprequisites**
+* Step 5: Fetch latest Docker image preprequisites
-```
+```shell
cd $VOLTHA_BASE
make fetch
```
-**Step 6: Rebuild the Voltha Docker Image Combo**
+* Step 6: Rebuild the Voltha Docker Image Combo
-```
+```shell
cd $VOLTHA_BASE
make
```
@@ -83,15 +79,12 @@
At this point your Voltha components shall be ready for local Docker
deployment.
-
## Verify Network Access From Server to OLTs
Confirm that you have connectivity from the VOLTHA server to the OLT chassis or device.
-### VLAN forwarding
+## VLAN forwarding
-Any L2 switches participating in connecting the Voltha test server to the PON
-components need to be configured to pass specific VLAN-tagged traffic. The
-details are POD and device specific. Please consult with your vendor.
+Any L2 switches participating in connecting the Voltha test server to the PON components need to be configured to pass specific VLAN-tagged traffic. The details are POD and device specific. Please consult with your vendor.
Please continue with next section of the document.
diff --git a/docs/manuals/user/labtests/requirements.md b/docs/manuals/user/labtests/requirements.md
index d986b26..cd4aa33 100644
--- a/docs/manuals/user/labtests/requirements.md
+++ b/docs/manuals/user/labtests/requirements.md
@@ -2,8 +2,7 @@
## Test PODs
-A Test POD suitable for testing Voltha and Voltha-assisted PON networks usually
-contain at least the following hardware components:
+A Test POD suitable for testing Voltha and Voltha-assisted PON networks usually contains at least the following hardware components:
* One or more disaggregated OLT devices
* One or more ONU/ONT devices per OLT
@@ -20,6 +19,4 @@
## Supported Specific Test PODs
At this early phase, test PODs are being defined and developed by a select set
-of commercial vendors who are members of the Voltha project. Once the PODs are stable
-enough, their details will be described here. Until then, please contact your
-(preferred) vendor for test POD specifications, BOMs, and other details.
+of commercial vendors who are members of the Voltha project. Once the PODs are stable enough, their details will be described here. Until then, please contact your (preferred) vendor for test POD specifications, BOMs, and other details.
diff --git a/docs/manuals/user/old/SUMMARY_ORIG.md b/docs/manuals/user/old/SUMMARY_ORIG.md
index 0c47be7..de3e059 100644
--- a/docs/manuals/user/old/SUMMARY_ORIG.md
+++ b/docs/manuals/user/old/SUMMARY_ORIG.md
@@ -3,84 +3,84 @@
This is the TOC file used by the gitbook generator.
To generate and serve static content, run:
- ```
- gitbook serve
- ```
+```shell
+gitbook serve
+```
* [Introduction](README.md)
* [Overview of Voltha]()
* [Recommended Lab Test Scenarios](labtests/README.md)
- * [Requirements](labtests/requirements.md)
- * [Preparation](labtests/preparations.md)
- * [Voltha Bringup Tests](labtests/V00_voltha.md)
- * [V1 - Deploy Voltha and Verify its Vital Signs](labtests/V01_voltha_bringup_deploy.md)
- * [V2 - Connect to Voltha with REST and Web Browser](labtests/V02_voltha_bringup_rest.md)
- * [V3 - Connect to Voltha via its CLI](labtests/V03_voltha_bringup_cli.md)
- * [V4 - View Voltha Async Events with Kafkacat](labtests/V04_voltha_bringup_async.md)
- * [PONSIM Tests](labtests/S00_ponsim_tests.md)
- * [S1 - Launch PONSIM and Activate it From Voltha](labtests/S01_ponsim_tests_launch_and_activate.md)
- * [S2 - Manually Install EAPOL Forwarding Flows](labtests/S02_ponsim_tests_eapol_install.md)
- * [S3 - Test EAPOL In/Out Forwarding with OLT-OFTEST](labtests/S03_ponsim_tests_eapol_in_out.md)
- * [S4 - Manually Install All Forwarding Flows](labtests/S04_ponsim_tests_install_all_flows.md)
- * [S5 - Test unicast (Internet) access](labtests/S05_ponsim_tests_unicast.md)
- * [S6 - Test IGMP and multicast (Video) streams](labtests/S06_ponsim_tests_multicast.md)
- * [Maple OLT Tests](labtests/M00_maple_olt_tests.md)
- * [M1 - Preprovision and Activate OLT](labtests/M01_maple_olt_tests_activate_olt.md)
- * [M2 - Activate ONU](labtests/M02_maple_olt_tests_activate_onu.md)
- * [M3 - Manually Install EAPOL Forwarding Flows](labtests/M03_maple_olt_tests_eapol_install.md)
- * [M4 - Test EAPOL In/Out Forwarding with OLT-OFTEST](labtests/M04_maple_olt_tests_eapol_in_out.md)
- * [M5 - Manually Install All Forwarding Flows](labtests/M05_maple_olt_tests_install_all_flows.md)
- * [M6 - Test unicast (Internet) access](labtests/M06_maple_olt_tests_unicast.md)
- * [M7 - Test IGMP and multicast (Video) streams](labtests/M07_maple_olt_tests_multicast.md)
- * [M8 - Reset Manually Added Flows and Launch ONOS](labtests/M08_maple_olt_tests_start_onos.md)
- * [M9 - Verify RG Authentication Scenario](labtests/M09_maple_olt_tests_verify_authentication.md)
- * [M10 - Verify DHCP Lookup](labtests/M10_maple_olt_tests_verify_dhcp.md)
- * [M11 - Verify Unicast Access](labtests/M11_maple_olt_tests_verify_unicast.md)
- * [M12 - Verify Multicast Access](labtests/M12_maple_olt_tests_verify_multicast.md)
- * [M13 - Spirent - Verify Re-Write C-VID Upstream](labtests/M13_maple_olt_tests_verify_cvid_upstream.md)
- * [M14 - Spirent - Verify Re-Write C-VID Downstream](labtests/M14_maple_olt_tests_verify_cvid_downstream.md)
- * [M15 - Spirent - Verify 802.1ad (QinQ) Upstream](labtests/M15_maple_olt_tests_verify_qinq_upstream.md)
- * [M16 - Spirent - Verify 802.1ad (QinQ) Downstream](labtests/M16_maple_olt_tests_verify_qinq_downstream.md)
- * [M17 - Spirent - Verify IPv4 Unicast Streams Downstream](labtests/M17_maple_olt_tests_verify_ipv4_downstream.md)
- * [M18 - Spirent - Verify IPv4 Unicast Streams Downstream Case2](labtests/M18_maple_olt_tests_verify_ipv4_downstream_case2.md)
- * [M19 - 10k and 20k ONU Ranging](labtests/M19_maple_olt_tests_ranging.md)
- * [M20 - MIB Download and Upload](labtests/M20_maple_olt_tests_mib.md)
- * [M21 - 2000 byte Frames](labtests/M21_maple_olt_tests_2000_byte_frames.md)
- * [M22 - Simultaneous Data and Video Streams](labtests/M22_maple_olt_tests_data_and_video.md)
- * [M23 - Overnight Traffic Test](labtests/M23_maple_olt_tests_overnight.md)
- * [M24 - Traffic Recovers After Fiber Disconnect (Best Effort)](labtests/M24_maple_olt_tests_ha_fiber_disconnect.md)
- * [M25 - Traffic Recovers After ONU Reset (Best Effort)](labtests/M25_maple_olt_tests_ha_onu_reset.md)
- * [M26 - Traffic Recovers After OLT Reset (Best Effort)](labtests/M26_maple_olt_tests_ha_olt_reset.md)
- * [M27 - Traffic Recovers After ToR Switch Reset (Best Effort)](labtests/M27_maple_olt_tests_ha_tor_switch_reset.md)
- * [Tibit OLT Tests](labtests/T00_tibit_olt_tests.md)
- * [T1 - Preprovision and Activate OLT](labtests/T01_tibit_olt_tests_activate_olt.md)
- * [T2 - Activate ONU](labtests/T02_tibit_olt_tests_activate_onu.md)
- * [T3 - Manually Install EAPOL Forwarding Flows](labtests/T03_tibit_olt_tests_eapol_install.md)
- * [T4 - Test EAPOL In/Out Forwarding with OLT-OFTEST](labtests/T04_tibit_olt_tests_eapol_in_out.md)
- * [T5 - Manually Install All Forwarding Flows](labtests/T05_tibit_olt_tests_install_all_flows.md)
- * [T6 - Test unicast (Internet) access](labtests/T06_tibit_olt_tests_unicast.md)
- * [T7 - Test IGMP and multicast (Video) streams](labtests/T07_tibit_olt_tests_multicast.md)
- * [T8 - Reset Manually Added Flows and Launch ONOS](labtests/T08_tibit_olt_tests_start_onos.md)
- * [T9 - Verify RG Authentication Scenario](labtests/T09_tibit_olt_tests_verify_authentication.md)
- * [T10 - Verify DHCP Lookup](labtests/T10_tibit_olt_tests_verify_dhcp.md)
- * [T11 - Verify Unicast Access](labtests/T11_tibit_olt_tests_verify_unicast.md)
- * [T12 - Verify Multicast Access](labtests/T12_tibit_olt_tests_verify_multicast.md)
- * [T13 - Spirent - Verify Re-Write C-VID Upstream](labtests/T13_tibit_olt_tests_verify_cvid_upstream.md)
- * [T14 - Spirent - Verify Re-Write C-VID Downstream](labtests/T14_tibit_olt_tests_verify_cvid_downstream.md)
- * [T15 - Spirent - Verify 802.1ad (QinQ) Upstream](labtests/T15_tibit_olt_tests_verify_qinq_upstream.md)
- * [T16 - Spirent - Verify 802.1ad (QinQ) Downstream](labtests/T16_tibit_olt_tests_verify_qinq_downstream.md)
- * [T17 - Spirent - Verify IPv4 Unicast Streams Downstream](labtests/T17_tibit_olt_tests_verify_ipv4_downstream.md)
- * [T18 - Spirent - Verify IPv4 Unicast Streams Downstream Case2](labtests/T18_tibit_olt_tests_verify_ipv4_downstream_case2.md)
- * [T19 - 10k and 20k ONU Ranging](labtests/T19_tibit_olt_tests_ranging.md)
- * [T20 - MIB Download and Upload](labtests/T20_tibit_olt_tests_mib.md)
- * [T21 - 2000 byte Frames](labtests/T21_tibit_olt_tests_2000_byte_frames.md)
- * [T22 - Simultaneous Data and Video Streams](labtests/T22_tibit_olt_tests_data_and_video.md)
- * [T23 - Overnight Traffic Test](labtests/T23_tibit_olt_tests_overnight.md)
- * [T24 - Traffic Recovers After Fiber Disconnect (Best Effort)](labtests/T24_tibit_olt_tests_ha_fiber_disconnect.md)
- * [T25 - Traffic Recovers After ONU Reset (Best Effort)](labtests/T25_tibit_olt_tests_ha_onu_reset.md)
- * [T26 - Traffic Recovers After OLT Reset (Best Effort)](labtests/T26_tibit_olt_tests_ha_olt_reset.md)
- * [T27 - Traffic Recovers After ToR Switch Reset (Best Effort)](labtests/T27_tibit_olt_tests_ha_tor_switch_reset.md)
- * [Previews of Upcoming Features](labtests/P00_previews.md)
- * [P1 - KPI Collection Through Voltha](labtests/P01_previews_kpi_collection.md)
- * [P2 - Voltha's Netconf API and Yang Definitions](labtests/P02_previews_yang_and_netconf.md)
- * [P3 - Voltha's Partial Readiness for Scale-out](labtests/P03_previews_scale_out.md)
+ * [Requirements](labtests/requirements.md)
+ * [Preparation](labtests/preparations.md)
+ * [Voltha Bringup Tests](labtests/V00_voltha.md)
+ * [V1 - Deploy Voltha and Verify its Vital Signs](labtests/V01_voltha_bringup_deploy.md)
+ * [V2 - Connect to Voltha with REST and Web Browser](labtests/V02_voltha_bringup_rest.md)
+ * [V3 - Connect to Voltha via its CLI](labtests/V03_voltha_bringup_cli.md)
+ * [V4 - View Voltha Async Events with Kafkacat](labtests/V04_voltha_bringup_async.md)
+ * [PONSIM Tests](labtests/S00_ponsim_tests.md)
+ * [S1 - Launch PONSIM and Activate it From Voltha](labtests/S01_ponsim_tests_launch_and_activate.md)
+ * [S2 - Manually Install EAPOL Forwarding Flows](labtests/S02_ponsim_tests_eapol_install.md)
+ * [S3 - Test EAPOL In/Out Forwarding with OLT-OFTEST](labtests/S03_ponsim_tests_eapol_in_out.md)
+ * [S4 - Manually Install All Forwarding Flows](labtests/S04_ponsim_tests_install_all_flows.md)
+ * [S5 - Test unicast (Internet) access](labtests/S05_ponsim_tests_unicast.md)
+ * [S6 - Test IGMP and multicast (Video) streams](labtests/S06_ponsim_tests_multicast.md)
+ * [Maple OLT Tests](labtests/M00_maple_olt_tests.md)
+ * [M1 - Preprovision and Activate OLT](labtests/M01_maple_olt_tests_activate_olt.md)
+ * [M2 - Activate ONU](labtests/M02_maple_olt_tests_activate_onu.md)
+ * [M3 - Manually Install EAPOL Forwarding Flows](labtests/M03_maple_olt_tests_eapol_install.md)
+ * [M4 - Test EAPOL In/Out Forwarding with OLT-OFTEST](labtests/M04_maple_olt_tests_eapol_in_out.md)
+ * [M5 - Manually Install All Forwarding Flows](labtests/M05_maple_olt_tests_install_all_flows.md)
+ * [M6 - Test unicast (Internet) access](labtests/M06_maple_olt_tests_unicast.md)
+ * [M7 - Test IGMP and multicast (Video) streams](labtests/M07_maple_olt_tests_multicast.md)
+ * [M8 - Reset Manually Added Flows and Launch ONOS](labtests/M08_maple_olt_tests_start_onos.md)
+ * [M9 - Verify RG Authentication Scenario](labtests/M09_maple_olt_tests_verify_authentication.md)
+ * [M10 - Verify DHCP Lookup](labtests/M10_maple_olt_tests_verify_dhcp.md)
+ * [M11 - Verify Unicast Access](labtests/M11_maple_olt_tests_verify_unicast.md)
+ * [M12 - Verify Multicast Access](labtests/M12_maple_olt_tests_verify_multicast.md)
+ * [M13 - Spirent - Verify Re-Write C-VID Upstream](labtests/M13_maple_olt_tests_verify_cvid_upstream.md)
+ * [M14 - Spirent - Verify Re-Write C-VID Downstream](labtests/M14_maple_olt_tests_verify_cvid_downstream.md)
+ * [M15 - Spirent - Verify 802.1ad (QinQ) Upstream](labtests/M15_maple_olt_tests_verify_qinq_upstream.md)
+ * [M16 - Spirent - Verify 802.1ad (QinQ) Downstream](labtests/M16_maple_olt_tests_verify_qinq_downstream.md)
+ * [M17 - Spirent - Verify IPv4 Unicast Streams Downstream](labtests/M17_maple_olt_tests_verify_ipv4_downstream.md)
+ * [M18 - Spirent - Verify IPv4 Unicast Streams Downstream Case2](labtests/M18_maple_olt_tests_verify_ipv4_downstream_case2.md)
+ * [M19 - 10k and 20k ONU Ranging](labtests/M19_maple_olt_tests_ranging.md)
+ * [M20 - MIB Download and Upload](labtests/M20_maple_olt_tests_mib.md)
+ * [M21 - 2000 byte Frames](labtests/M21_maple_olt_tests_2000_byte_frames.md)
+ * [M22 - Simultaneous Data and Video Streams](labtests/M22_maple_olt_tests_data_and_video.md)
+ * [M23 - Overnight Traffic Test](labtests/M23_maple_olt_tests_overnight.md)
+ * [M24 - Traffic Recovers After Fiber Disconnect (Best Effort)](labtests/M24_maple_olt_tests_ha_fiber_disconnect.md)
+ * [M25 - Traffic Recovers After ONU Reset (Best Effort)](labtests/M25_maple_olt_tests_ha_onu_reset.md)
+ * [M26 - Traffic Recovers After OLT Reset (Best Effort)](labtests/M26_maple_olt_tests_ha_olt_reset.md)
+ * [M27 - Traffic Recovers After ToR Switch Reset (Best Effort)](labtests/M27_maple_olt_tests_ha_tor_switch_reset.md)
+ * [Tibit OLT Tests](labtests/T00_tibit_olt_tests.md)
+ * [T1 - Preprovision and Activate OLT](labtests/T01_tibit_olt_tests_activate_olt.md)
+ * [T2 - Activate ONU](labtests/T02_tibit_olt_tests_activate_onu.md)
+ * [T3 - Manually Install EAPOL Forwarding Flows](labtests/T03_tibit_olt_tests_eapol_install.md)
+ * [T4 - Test EAPOL In/Out Forwarding with OLT-OFTEST](labtests/T04_tibit_olt_tests_eapol_in_out.md)
+ * [T5 - Manually Install All Forwarding Flows](labtests/T05_tibit_olt_tests_install_all_flows.md)
+ * [T6 - Test unicast (Internet) access](labtests/T06_tibit_olt_tests_unicast.md)
+ * [T7 - Test IGMP and multicast (Video) streams](labtests/T07_tibit_olt_tests_multicast.md)
+ * [T8 - Reset Manually Added Flows and Launch ONOS](labtests/T08_tibit_olt_tests_start_onos.md)
+ * [T9 - Verify RG Authentication Scenario](labtests/T09_tibit_olt_tests_verify_authentication.md)
+ * [T10 - Verify DHCP Lookup](labtests/T10_tibit_olt_tests_verify_dhcp.md)
+ * [T11 - Verify Unicast Access](labtests/T11_tibit_olt_tests_verify_unicast.md)
+ * [T12 - Verify Multicast Access](labtests/T12_tibit_olt_tests_verify_multicast.md)
+ * [T13 - Spirent - Verify Re-Write C-VID Upstream](labtests/T13_tibit_olt_tests_verify_cvid_upstream.md)
+ * [T14 - Spirent - Verify Re-Write C-VID Downstream](labtests/T14_tibit_olt_tests_verify_cvid_downstream.md)
+ * [T15 - Spirent - Verify 802.1ad (QinQ) Upstream](labtests/T15_tibit_olt_tests_verify_qinq_upstream.md)
+ * [T16 - Spirent - Verify 802.1ad (QinQ) Downstream](labtests/T16_tibit_olt_tests_verify_qinq_downstream.md)
+ * [T17 - Spirent - Verify IPv4 Unicast Streams Downstream](labtests/T17_tibit_olt_tests_verify_ipv4_downstream.md)
+ * [T18 - Spirent - Verify IPv4 Unicast Streams Downstream Case2](labtests/T18_tibit_olt_tests_verify_ipv4_downstream_case2.md)
+ * [T19 - 10k and 20k ONU Ranging](labtests/T19_tibit_olt_tests_ranging.md)
+ * [T20 - MIB Download and Upload](labtests/T20_tibit_olt_tests_mib.md)
+ * [T21 - 2000 byte Frames](labtests/T21_tibit_olt_tests_2000_byte_frames.md)
+ * [T22 - Simultaneous Data and Video Streams](labtests/T22_tibit_olt_tests_data_and_video.md)
+ * [T23 - Overnight Traffic Test](labtests/T23_tibit_olt_tests_overnight.md)
+ * [T24 - Traffic Recovers After Fiber Disconnect (Best Effort)](labtests/T24_tibit_olt_tests_ha_fiber_disconnect.md)
+ * [T25 - Traffic Recovers After ONU Reset (Best Effort)](labtests/T25_tibit_olt_tests_ha_onu_reset.md)
+ * [T26 - Traffic Recovers After OLT Reset (Best Effort)](labtests/T26_tibit_olt_tests_ha_olt_reset.md)
+ * [T27 - Traffic Recovers After ToR Switch Reset (Best Effort)](labtests/T27_tibit_olt_tests_ha_tor_switch_reset.md)
+ * [Previews of Upcoming Features](labtests/P00_previews.md)
+ * [P1 - KPI Collection Through Voltha](labtests/P01_previews_kpi_collection.md)
+ * [P2 - Voltha's Netconf API and Yang Definitions](labtests/P02_previews_yang_and_netconf.md)
+ * [P3 - Voltha's Partial Readiness for Scale-out](labtests/P03_previews_scale_out.md)
diff --git a/docs/manuals/user/old/olt-oftest-notes.md b/docs/manuals/user/old/olt-oftest-notes.md
index d76c398..006f39c 100644
--- a/docs/manuals/user/old/olt-oftest-notes.md
+++ b/docs/manuals/user/old/olt-oftest-notes.md
@@ -4,11 +4,11 @@
Steps:
-### Bring up dev host and install prerequisites
+## Bring up dev host and install prerequisites
Assuming a fresh Vagrant machine:
-```
+```shell
cd ~/voltha # whatever location your Voltha repo dir is
rm -fr venv-linux # to make sure we don't have residues
vagrant destroy -f # ditto
@@ -22,11 +22,11 @@
pip install pypcap
```
-### Build Voltha proto derivatives and start Voltha
+## Build Voltha proto derivatives and start Voltha
On the above Vagrant box:
-```
+```shell
cd /voltha
. env.sh
make protos
@@ -38,7 +38,7 @@
Open three terminals on the Vagrant host. In terminal one, start voltha:
-```
+```shell
cd /voltha
. env.sh
./voltha/main.py --kafka=@kafka
@@ -46,7 +46,7 @@
In the second terminal, start chameleon:
-```
+```shell
cd /voltha
. env.sh
./chameleon/main.py
@@ -54,7 +54,7 @@
In the third terminal, start ofagent:
-```
+```shell
cd /voltha
. env.sh
./ofagent/main.py
@@ -64,25 +64,25 @@
To see we can reach Voltha via REST:
-```
+```shell
curl -s http://localhost:8881/health | jq '.'
```
and
-```
+```shell
curl -s -H 'Get-Depth: 2' http://localhost:8881/api/v1/local | jq '.'
```
To verify we have exactly one logical device (this is important for olt-oftest, which assumes this):
-```
+```shell
curl -s http://localhost:8881/api/v1/local/logical_devices | jq '.items'
```
Check in the output that there is one entry in the logical device list, along these lines:
-```
+```json
[
{
"datapath_id": "1",
@@ -110,32 +110,31 @@
To verify that the above logical device has all three logical ports, run this:
-```
+```shell
curl -s http://localhost:8881/api/v1/local/logical_devices/simulated1/ports | jq '.items'
```
-This shall have three entries, one OLT NNI port and two ONU (UNI) ports. Make note of the corresponding
-```of_port.port_no``` numbers. They shall be as follows:
+This shall have three entries, one OLT NNI port and two ONU (UNI) ports. Make note of the corresponding *of_port.port_no* numbers. They shall be as follows:
-* For OLT port (```id=olt1```): ```ofp_port.port_no=129```
-* For ONU1 port (```id=onu1```): ```ofp_port.port_no=1```
-* For ONU2 port (```id=onu2```): ```ofp_port.port_no=2```
+* For OLT port (*id=olt1*): *ofp_port.port_no=129*
+* For ONU1 port (*id=onu1*): *ofp_port.port_no=1*
+* For ONU2 port (*id=onu2*): *ofp_port.port_no=2*
If they are different, you will need to adjust olt-oftest input arguments accordingly.
Finally, check the flow and flow_group tables of the logical device; they should both be empty at this point:
-```
+```shell
curl -s http://localhost:8881/api/v1/local/logical_devices/simulated1/flows | jq '.items'
curl -s http://localhost:8881/api/v1/local/logical_devices/simulated1/flow_groups | jq '.items'
```
-### Create fake interfaces needed by olt-oftest
+## Create fake interfaces needed by olt-oftest
Despite that we will run olt-oftest with "fake_dataplane" mode, meaning that it will not attempt to send/receive dataplane traffic, it still wants to be able to open its usual dataplane interfaces. We will make it happy by creating a few veth interfaces:
-```
+```shell
sudo ip link add type veth
sudo ip link add type veth
sudo ip link add type veth
@@ -146,9 +145,9 @@
sudo ifconfig veth6 up
```
-### Start olt-oftest in fake_dataplane mode
+## Start olt-oftest in fake_dataplane mode
-```
+```shell
cd /voltha
sudo -s
export PYTHONPATH=/voltha/voltha/adapters/tibit_olt:/voltha/mininet
@@ -161,5 +160,3 @@
```
The above shall finish with OK (showing seven (7) or more tests completed).
-
-
diff --git a/docs/manuals/user/old/pon-requirements.md b/docs/manuals/user/old/pon-requirements.md
index b6c78f7..6b0a378 100644
--- a/docs/manuals/user/old/pon-requirements.md
+++ b/docs/manuals/user/old/pon-requirements.md
@@ -1,6 +1,4 @@
-# PON Capability Requirements
-
-v0.3
+# PON Capability Requirements (v0.3)
This document summarizes high level functional requirements of a PON system to make it compatible with Voltha and the CORD-based disaggregated access design.
@@ -29,21 +27,21 @@
We define the following reference points:
-**(Pa) Voltha Adapter Interface**
+### (Pa) Voltha Adapter Interface
Uniform, abstract, vendor agnostic programmatic (Python) interface between Voltha's Core and a vendor's OLT Adapter for Voltha.
Purpose:
* Downstream:
- * Invoking management- and control-plane operations _on_ the OLT.
- * Passing management operation protocol frames on behalf of an ONU Adapter to the ONU _via_ the OLT
- * Forwarding control protocol frames to be injected by the OLT toward the RG (e.g., 802.1x, IGMP)
+ * Invoking management- and control-plane operations _on_ the OLT.
+ * Passing management operation protocol frames on behalf of an ONU Adapter to the ONU _via_ the OLT
+ * Forwarding control protocol frames to be injected by the OLT toward the RG (e.g., 802.1x, IGMP)
* Upstream:
- * Signaling asynchronous events to Voltha Core (e.g., OLT discovered, ONU activated, alarms, and performance metric data)
- * Forwarding control-plane messages diverted from the PON network toward the SDN controller (e.g., 802.1x, IGMP)
-
-**(Pc) Control and Management channels**
+ * Signaling asynchronous events to Voltha Core (e.g., OLT discovered, ONU activated, alarms, and performance metric data)
+ * Forwarding control-plane messages diverted from the PON network toward the SDN controller (e.g., 802.1x, IGMP)
+
+### (Pc) Control and Management channels
This interface carries management and control protocol communication between Voltha and the PON complex. This can include protocols terminated by the OLT, by the ONU, or by the RG. Encapsulation of these protocols at Pc can be OLT vendor specific, but their payload may be specific to the vendor of the respective device. The management protocols targeting the OLT can be completely specific to the OLT vendor.
@@ -52,51 +50,53 @@
Purpose:
* Downstream:
- * Invoke OLT management operations using possibly proprietary protocols, specific to the OLT vendor. Examples: configure OLT device attributes; disable an ONU port.
- * Invoke ONU management operations using protocols specific to the ONU (OMCI, EOAM, etc.), and tunneled by the OLT Adapter and OLT so that it may be encapsulated at Pc in ways specific to the OLT vendor.
- * Carry control plane messages to be forwarded toward the RG. If the injection of such frames into the PON is done by the OLT, the encapsulation method of these frames at Pc can be OLT vendor specific. Thus, the OLT Adapter and the OLT play a tunneling/forwarding role.
+ * Invoke OLT management operations using possibly proprietary protocols, specific to the OLT vendor. Examples: configure OLT device attributes; disable an ONU port.
+ * Invoke ONU management operations using protocols specific to the ONU (OMCI, EOAM, etc.), and tunneled by the OLT Adapter and OLT so that it may be encapsulated at Pc in ways specific to the OLT vendor.
+ * Carry control plane messages to be forwarded toward the RG. If the injection of such frames into the PON is done by the OLT, the encapsulation method of these frames at Pc can be OLT vendor specific. Thus, the OLT Adapter and the OLT play a tunneling/forwarding role.
* Upstream:
- * Respond to OLT management operations
- * Carry ONU management protocol responses from the ONU to the ONU Adapter via the OLT Adapter
- * Carry control plane protocol messages isolated by the OLT and to be destined to the SDN controller. The encapsulation of such messages can be OLT vendor specific at Pc, but must encode/preseve the source (e.g., ONU port number) so that the source of the message can be identified.
-
-**(Pd) Data plane channels**
+ * Respond to OLT management operations
+ * Carry ONU management protocol responses from the ONU to the ONU Adapter via the OLT Adapter
+ * Carry control plane protocol messages isolated by the OLT and to be destined to the SDN controller. The encapsulation of such messages can be OLT vendor specific at Pc, but must encode/preseve the source (e.g., ONU port number) so that the source of the message can be identified.
+
+### (Pd) Data plane channels
This reference point carries all unicast and multicast "payload" data flows of the subscriber, flows with which Voltha is not be concerned, including the subscriber's Internet, VoIP and multicast-based video (TV) traffic. Thus, it can include both unicast and multicast flows. It can also include control and management plane flows for protocols not involving Voltha and the SDN controller.
-**(Po) OLT upstream-facing interface**
+### (Po) OLT upstream-facing interface
This is the interface with which an OLT device is connected to the access aggregation network, i.e., to an upstream data network and to its control- and management systems. This interface thus carries the payload of both Pd and Pc. Pc and Pd flows may be carried via the same OLT physical port (in-band management and control). In the in-band case, flows of Pd vs Pc are typically isolated by VLANs. In the case of out-of band management and control Pc and Pd may be isolated via dedicated physical ports (e.g., when Pc as a whole or portions of Pc protocols access the OLT via its management port).
-**(Pr) ONU residential-facing interface**
+### (Pr) ONU residential-facing interface
This is typically a L2 (Ethernet) interface carrying control plane and data plane flows to and from the RG. This includes all subscriber "payload" flows, such as Internet, VoIP and video service traffic, but it also includes control protocol flows terminated by Voltha or the SDN controller. However this distinction is invisible at this reference point, as the RG must be able to behave in the same way irregardless of being used in a disaggregated (Voltha-based) PON network or in a conventional legacy PON network.
## Minimal Phase 1 Requirements
+
While Voltha is designed to cater for a growing set of requirements and tries to approach the access devices with certain degree of genericness, in the first phase of the implementation it focuses on a specific feature set and behavior. For an OLT/ONT combo to operate with Voltha, the following is expected. Note that VOLTHA does not prescribe the functional breakdown of these requirements between the OLT Adapter and the OLT device, only that the two jointly must yield the desired functionality.
-### OLT and OLT Adapter Requirements
+## OLT and OLT Adapter Requirements
+
* [R-1] OLT Adapter SHOULD be able to auto-discover new OLT devices and notify Voltha CORE about these. In the integrated case (Voltha runs on the OLT device), this is a trivial task. In the compute based implementation this requires the OLTs to regularly transmit a "beacon" signal (e.g., on a specific VLAN) and the adapter to "listen" on the given VLAN and look for OLTs not yet registered with Voltha.
* [R-2] OLT Adapter MUST be able to establish a control communication channel with the OLT. This may or may not be done in a connection oriented fashion, however, the Adapter must be able to use a heart-beat mechanism to monitor the availability of the channel and detect if communication is lost to the device. Any change in status must be signaled to Voltha core via the appropriate API.
* [R-3] Upon request from Voltha Core, the Adapter MUST be able to perform the initial activation of an OLT device. This may involve any or all of the following and must result in a state where all remaining requirements listed below (R-4, R-5, ...) are satisfiable:
- * Upgrade device to desired software level
- * Reset device to a known initial configuration
- * Download and activate "golden" device configuration
- * Gather all inventory information from device
- * Start monitoring device health and setup alarm forwarding to Adapter and Voltha Core
- * Start monitoring control communication to device and signal state changes to Voltha Core
- * Start detection of connected ONUs and notify Voltha Core on arrival/departure events
+ * Upgrade device to desired software level
+ * Reset device to a known initial configuration
+ * Download and activate "golden" device configuration
+ * Gather all inventory information from device
+ * Start monitoring device health and setup alarm forwarding to Adapter and Voltha Core
+ * Start monitoring control communication to device and signal state changes to Voltha Core
+ * Start detection of connected ONUs and notify Voltha Core on arrival/departure events
* [R-4] The OLT MUST be able to "range" ONUs and detection of a new ONU MUST be signaled to Voltha Core via the appropriate API. This API call SHALL provide a minimalistic type information on the ONU, enough to allow Voltha to associate the appropriate ONU Adapter for the ONU.
* [R-5] The OLT MUST be able to detect loss of communication with an ONU and signal the loss as well as recovery events to Voltha Core via the Adapter.
* [R-6] Upon API request, the OLT Adapter must be able to perform OLT-side activation procedures associated to a given ONU. This includes establishing a default PON channel dedicated to the ONU, as well as the installation of a small set of forwarding rules which allows any and all 802.1x (EA-POL) upstream messages to be redirected toward Voltha via the help of the OLT Adapter. It is important that the Adapter can reconstruct the source ONU port before the message is passed to Voltha Core. The mode and encapsulation of such forwarded messages from the OLT to the Adapter is up to the Adapter and the OLT. Nevertheless, here are two examples how this can be accomplished:
- * The redirected frame is handled by the control and management proxy residing on the OLT and passed up as a custom message to the Adapter. The encapsulation methods may contain any and all metadata such as source port ID.
- * A dedicated VLAN is used for all redirected packets and an additional (inner) VLAN tag is used to identify the source port. The former can be used allow the adapter to receive such frames, while the latter can be used by the adapter to reconstruct the port ID before the frame is passed up to Voltha Core.
+ * The redirected frame is handled by the control and management proxy residing on the OLT and passed up as a custom message to the Adapter. The encapsulation methods may contain any and all metadata such as source port ID.
+ * A dedicated VLAN is used for all redirected packets and an additional (inner) VLAN tag is used to identify the source port. The former can be used allow the adapter to receive such frames, while the latter can be used by the adapter to reconstruct the port ID before the frame is passed up to Voltha Core.
* [R-7] The Adapter and OLT MUST allow Voltha to send and receive OMCI management frames to and from an ONU. This allows Voltha to complete the ONU-side part of the ONU activation.
* [R-8] The Adapter MUST allow Voltha to send 802.1x frames back toward the ONU via the Adapter and OLT. Voltha will use logical port numbers to address the ONU/RG, and the Adapter and OLT MUST be able to map this information to whatever is needed on the Adapter to OLT link. The injection of the EA-POL frames MUST be done such that the RG receives the frame without knowing that the 802.1x authentication happened outside of the OLT device (transparent operation).
* [R-9] The Adapter and OLT MUST allow Voltha to establish unicast forwarding of subscriber traffic upstream (toward the aggregation network) and downstream (from the aggregation network toward the subscriber). In Phase 1 at least one such channel must be supported. Frames on the uplink side may be untagged, tagged with an OLT-specific pre-configured VLAN, or dual tagged with an OLT-specific VLAN and a subscriber specific VLAN ID. In the uplink direction, selection of a static CoS bit SHALL be possible.
* [R-10] The Adapter and OLT MUST support the activation of additional control plane packet redirection, including at least for the following frame types (note that in the same way as for 802.1x, the source port MUST be conveyed such that the Adapter can identify it before the frame is passed into Voltha Core) :
- * IGMP v3 messages
- * DHCP IPv4 and IPv6 messages
+ * IGMP v3 messages
+ * DHCP IPv4 and IPv6 messages
* [R-11] The Adapter and OLT MUST be able support the injection of arbitrary packets by Voltha into the PON network in the downstream direction toward any of the active ONUs.
* [R-12] The Adapter and OLT SHALL allow Voltha to activate additional unicast flows associated with subscriber, with unique CoS mapping and vlan tagging options.
* [R-13] The Adapter and OLT MUST allow Voltha to add/remove ONUs to specific multicast flows (video channels). Multicast is data flows are downstream only and may arrive to the OLT at specific VLAN tags. The OLT may be asked to pop such VLAN headers before forwarding them to the PON. If the OLT maps all multicast flows to the broadcast channel of the PON, than once the generic flow is established, not further actions many be triggered by the changes to multicast flows. However, it is likely that Voltha will need to communicate to the ONUs upon these events and the OLT MUST assist in the tunneling of the needed protocol messages (e.g., OMCI) between Voltha and the ONU (see R-7).
@@ -106,14 +106,15 @@
* [R-17] The Adapter and OLT MUST support the removal of any multicast forwarding flow rules.
* [R-18] The Adapter and OLT MUST support the removal of any unicast flow rules.
-### ONU and ONU Adapter Requirements
+## ONU and ONU Adapter Requirements
+
[TBD]
## Sequence Diagrams
-### Cold Start Activation Sequence
+## Cold Start Activation Sequence
The following diagram captures the sequence of steps following a cold start of all sub-systems. This is the first sequence subject of lab testing.
diff --git a/docs/pon-requirements.md b/docs/pon-requirements.md
index 3fe7a14..b40b432 100644
--- a/docs/pon-requirements.md
+++ b/docs/pon-requirements.md
@@ -1,6 +1,4 @@
-# PON Capability Requirements
-
-v0.3
+# PON Capability Requirements v0.3
This document summarizes high level functional requirements of a PON system to make it compatible with Voltha and the CORD-based disaggregated access design.
@@ -29,21 +27,21 @@
We define the following reference points:
-**(Pa) Voltha Adapter Interface**
+### (Pa) Voltha Adapter Interface
Uniform, abstract, vendor agnostic programmatic (Python) interface between Voltha's Core and a vendor's OLT Adapter for Voltha.
Purpose:
* Downstream:
- * Invoking management- and control-plane operations _on_ the OLT.
- * Passing management operation protocol frames on behalf of an ONU Adapter to the ONU _via_ the OLT
- * Forwarding control protocol frames to be injected by the OLT toward the RG (e.g., 802.1x, IGMP)
+ * Invoking management- and control-plane operations _on_ the OLT.
+ * Passing management operation protocol frames on behalf of an ONU Adapter to the ONU _via_ the OLT
+ * Forwarding control protocol frames to be injected by the OLT toward the RG (e.g., 802.1x, IGMP)
* Upstream:
- * Signaling asynchronous events to Voltha Core (e.g., OLT discovered, ONU activated, alarms, and performance metric data)
- * Forwarding control-plane messages diverted from the PON network toward the SDN controller (e.g., 802.1x, IGMP)
-
-**(Pc) Control and Management channels**
+ * Signaling asynchronous events to Voltha Core (e.g., OLT discovered, ONU activated, alarms, and performance metric data)
+ * Forwarding control-plane messages diverted from the PON network toward the SDN controller (e.g., 802.1x, IGMP)
+
+### (Pc) Control and Management channels
This interface carries management and control protocol communication between Voltha and the PON complex. This can include protocols terminated by the OLT, by the ONU, or by the RG. Encapsulation of these protocols at Pc can be OLT vendor specific, but their payload may be specific to the vendor of the respective device. The management protocols targeting the OLT can be completely specific to the OLT vendor.
@@ -52,51 +50,53 @@
Purpose:
* Downstream:
- * Invoke OLT management operations using possibly proprietary protocols, specific to the OLT vendor. Examples: configure OLT device attributes; disable an ONU port.
- * Invoke ONU management operations using protocols specific to the ONU (OMCI, EOAM, etc.), and tunneled by the OLT Adapter and OLT so that it may be encapsulated at Pc in ways specific to the OLT vendor.
- * Carry control plane messages to be forwarded toward the RG. If the injection of such frames into the PON is done by the OLT, the encapsulation method of these frames at Pc can be OLT vendor specific. Thus, the OLT Adapter and the OLT play a tunneling/forwarding role.
+ * Invoke OLT management operations using possibly proprietary protocols, specific to the OLT vendor. Examples: configure OLT device attributes; disable an ONU port.
+ * Invoke ONU management operations using protocols specific to the ONU (OMCI, EOAM, etc.), and tunneled by the OLT Adapter and OLT so that it may be encapsulated at Pc in ways specific to the OLT vendor.
+ * Carry control plane messages to be forwarded toward the RG. If the injection of such frames into the PON is done by the OLT, the encapsulation method of these frames at Pc can be OLT vendor specific. Thus, the OLT Adapter and the OLT play a tunneling/forwarding role.
* Upstream:
- * Respond to OLT management operations
- * Carry ONU management protocol responses from the ONU to the ONU Adapter via the OLT Adapter
- * Carry control plane protocol messages isolated by the OLT and to be destined to the SDN controller. The encapsulation of such messages can be OLT vendor specific at Pc, but must encode/preseve the source (e.g., ONU port number) so that the source of the message can be identified.
-
-**(Pd) Data plane channels**
+ * Respond to OLT management operations
+ * Carry ONU management protocol responses from the ONU to the ONU Adapter via the OLT Adapter
+ * Carry control plane protocol messages isolated by the OLT and to be destined to the SDN controller. The encapsulation of such messages can be OLT vendor specific at Pc, but must encode/preseve the source (e.g., ONU port number) so that the source of the message can be identified.
+
+### (Pd) Data plane channels
This reference point carries all unicast and multicast "payload" data flows of the subscriber, flows with which Voltha is not be concerned, including the subscriber's Internet, VoIP and multicast-based video (TV) traffic. Thus, it can include both unicast and multicast flows. It can also include control and management plane flows for protocols not involving Voltha and the SDN controller.
-**(Po) OLT upstream-facing interface**
+### (Po) OLT upstream-facing interface
This is the interface with which an OLT device is connected to the access aggregation network, i.e., to an upstream data network and to its control- and management systems. This interface thus carries the payload of both Pd and Pc. Pc and Pd flows may be carried via the same OLT physical port (in-band management and control). In the in-band case, flows of Pd vs Pc are typically isolated by VLANs. In the case of out-of band management and control Pc and Pd may be isolated via dedicated physical ports (e.g., when Pc as a whole or portions of Pc protocols access the OLT via its management port).
-**(Pr) ONU residential-facing interface**
+### (Pr) ONU residential-facing interface
This is typically a L2 (Ethernet) interface carrying control plane and data plane flows to and from the RG. This includes all subscriber "payload" flows, such as Internet, VoIP and video service traffic, but it also includes control protocol flows terminated by Voltha or the SDN controller. However this distinction is invisible at this reference point, as the RG must be able to behave in the same way irregardless of being used in a disaggregated (Voltha-based) PON network or in a conventional legacy PON network.
## Minimal Phase 1 Requirements
+
While Voltha is designed to cater for a growing set of requirements and tries to approach the access devices with certain degree of genericness, in the first phase of the implementation it focuses on a specific feature set and behavior. For an OLT/ONT combo to operate with Voltha, the following is expected. Note that VOLTHA does not prescribe the functional breakdown of these requirements between the OLT Adapter and the OLT device, only that the two jointly must yield the desired functionality.
-### OLT and OLT Adapter Requirements
+## OLT and OLT Adapter Requirements
+
* [R-1] OLT Adapter SHOULD be able to auto-discover new OLT devices and notify Voltha CORE about these. In the integrated case (Voltha runs on the OLT device), this is a trivial task. In the compute based implementation this requires the OLTs to regularly transmit a "beacon" signal (e.g., on a specific VLAN) and the adapter to "listen" on the given VLAN and look for OLTs not yet registered with Voltha.
* [R-2] OLT Adapter MUST be able to establish a control communication channel with the OLT. This may or may not be done in a connection oriented fashion, however, the Adapter must be able to use a heart-beat mechanism to monitor the availability of the channel and detect if communication is lost to the device. Any change in status must be signaled to Voltha core via the appropriate API.
* [R-3] Upon request from Voltha Core, the Adapter MUST be able to perform the initial activation of an OLT device. This may involve any or all of the following and must result in a state where all remaining requirements listed below (R-4, R-5, ...) are satisfiable:
- * Upgrade device to desired software level
- * Reset device to a known initial configuration
- * Download and activate "golden" device configuration
- * Gather all inventory information from device
- * Start monitoring device health and setup alarm forwarding to Adapter and Voltha Core
- * Start monitoring control communication to device and signal state changes to Voltha Core
- * Start detection of connected ONUs and notify Voltha Core on arrival/departure events
+ * Upgrade device to desired software level
+ * Reset device to a known initial configuration
+ * Download and activate "golden" device configuration
+ * Gather all inventory information from device
+ * Start monitoring device health and setup alarm forwarding to Adapter and Voltha Core
+ * Start monitoring control communication to device and signal state changes to Voltha Core
+ * Start detection of connected ONUs and notify Voltha Core on arrival/departure events
* [R-4] The OLT MUST be able to "range" ONUs and detection of a new ONU MUST be signaled to Voltha Core via the appropriate API. This API call SHALL provide a minimalistic type information on the ONU, enough to allow Voltha to associate the appropriate ONU Adapter for the ONU.
* [R-5] The OLT MUST be able to detect loss of communication with an ONU and signal the loss as well as recovery events to Voltha Core via the Adapter.
* [R-6] Upon API request, the OLT Adapter must be able to perform OLT-side activation procedures associated to a given ONU. This includes establishing a default PON channel dedicated to the ONU, as well as the installation of a small set of forwarding rules which allows any and all 802.1x (EA-POL) upstream messages to be redirected toward Voltha via the help of the OLT Adapter. It is important that the Adapter can reconstruct the source ONU port before the message is passed to Voltha Core. The mode and encapsulation of such forwarded messages from the OLT to the Adapter is up to the Adapter and the OLT. Nevertheless, here are two examples how this can be accomplished:
- * The redirected frame is handled by the control and management proxy residing on the OLT and passed up as a custom message to the Adapter. The encapsulation methods may contain any and all metadata such as source port ID.
- * A dedicated VLAN is used for all redirected packets and an additional (inner) VLAN tag is used to identify the source port. The former can be used allow the adapter to receive such frames, while the latter can be used by the adapter to reconstruct the port ID before the frame is passed up to Voltha Core.
+ * The redirected frame is handled by the control and management proxy residing on the OLT and passed up as a custom message to the Adapter. The encapsulation methods may contain any and all metadata such as source port ID.
+ * A dedicated VLAN is used for all redirected packets and an additional (inner) VLAN tag is used to identify the source port. The former can be used allow the adapter to receive such frames, while the latter can be used by the adapter to reconstruct the port ID before the frame is passed up to Voltha Core.
* [R-7] The Adapter and OLT MUST allow Voltha to send and receive OMCI management frames to and from an ONU. This allows Voltha to complete the ONU-side part of the ONU activation.
* [R-8] The Adapter MUST allow Voltha to send 802.1x frames back toward the ONU via the Adapter and OLT. Voltha will use logical port numbers to address the ONU/RG, and the Adapter and OLT MUST be able to map this information to whatever is needed on the Adapter to OLT link. The injection of the EA-POL frames MUST be done such that the RG receives the frame without knowing that the 802.1x authentication happened outside of the OLT device (transparent operation).
* [R-9] The Adapter and OLT MUST allow Voltha to establish unicast forwarding of subscriber traffic upstream (toward the aggregation network) and downstream (from the aggregation network toward the subscriber). In Phase 1 at least one such channel must be supported. Frames on the uplink side may be untagged, tagged with an OLT-specific pre-configured VLAN, or dual tagged with an OLT-specific VLAN and a subscriber specific VLAN ID. In the uplink direction, selection of a static CoS bit SHALL be possible.
* [R-10] The Adapter and OLT MUST support the activation of additional control plane packet redirection, including at least for the following frame types (note that in the same way as for 802.1x, the source port MUST be conveyed such that the Adapter can identify it before the frame is passed into Voltha Core) :
- * IGMP v3 messages
- * DHCP IPv4 and IPv6 messages
+ * IGMP v3 messages
+ * DHCP IPv4 and IPv6 messages
* [R-11] The Adapter and OLT MUST be able support the injection of arbitrary packets by Voltha into the PON network in the downstream direction toward any of the active ONUs.
* [R-12] The Adapter and OLT SHALL allow Voltha to activate additional unicast flows associated with subscriber, with unique CoS mapping and vlan tagging options.
* [R-13] The Adapter and OLT MUST allow Voltha to add/remove ONUs to specific multicast flows (video channels). Multicast is data flows are downstream only and may arrive to the OLT at specific VLAN tags. The OLT may be asked to pop such VLAN headers before forwarding them to the PON. If the OLT maps all multicast flows to the broadcast channel of the PON, than once the generic flow is established, not further actions many be triggered by the changes to multicast flows. However, it is likely that Voltha will need to communicate to the ONUs upon these events and the OLT MUST assist in the tunneling of the needed protocol messages (e.g., OMCI) between Voltha and the ONU (see R-7).
@@ -106,7 +106,8 @@
* [R-17] The Adapter and OLT MUST support the removal of any multicast forwarding flow rules.
* [R-18] The Adapter and OLT MUST support the removal of any unicast flow rules.
-### ONU and ONU Adapter Requirements
+## ONU and ONU Adapter Requirements
+
[TBD]
## OLT States and Expected Behavior
@@ -119,23 +120,22 @@
-
-### Not-exist
+## OLT Not-exist
This is an implied state when Voltha does not know about an OLT yet. At this point an OLT can be created in one of two ways:
-1. The OLT is pre-provisioned from the "north", initializing it with the "Pre-provisioned" state.
-2. The OLT is discovered by the OLT Adapter and this is signalled to Voltha Core via an async API call. Voltha will create the OLT record with the "Discovered" state.
+* The OLT is pre-provisioned from the "north", initializing it with the "Pre-provisioned" state.
+* The OLT is discovered by the OLT Adapter and this is signalled to Voltha Core via an async API call. Voltha will create the OLT record with the "Discovered" state.
-### Pre-provisioned
+## OLT Pre-provisioned
In this state the Adapter is expected to seek to establish communication with the OLT either based on a periodic connection attempt or waiting for a beacon signal from the OLT. If communication is established successfully, the Adapter shall signal this to Core via Pa. This allows Voltha to request activation of the OLT via the appropriate API call at Pa.
-### Discovered
+## OLT Discovered
In this state the Adapter has no further duties. Voltha will use explicit NBI acceptance or policy based decision to move the state to Activate, thus signalling the Adapter that the OLT shall be activated.
-### Activate
+## OLT Activate
The Adapter shall activate the OLT. This can involve:
@@ -145,7 +145,7 @@
Successful or failed activation shall be signalled to Core via appropriate API calls. If successful, OLT state will be moved to Active state. If failed, OLT state will be moved to Failed, with appropriate data logs for troubleshooting and alarms.
-### Active
+## OLT Active
This state indicates that the OLT is ready to perform the following:
@@ -160,11 +160,11 @@
Note that ONU-related messages do not change the OLT state, but rather affect the ONU state model as described in the next sub-section.
-### Failed
+## OLT Failed
[TBD]
-### Additional States
+## OLT Additional States
[TBD]
@@ -173,24 +173,23 @@
## ONU States
-### Non-existent
+### ONU Non-existent
-### Discovered
+### ONU Discovered
-### Activate
+### ONU Activate
-### Active
+### ONU Active
-### Rogue/Disabled
+### ONU Rogue/Disabled
-### Failed
+### ONU Failed
-### Additional States
+## ONU Additional States
## Sequence Diagrams
-
-### Cold Start Activation Sequence
+## Cold Start Activation Sequence
The following diagram captures the sequence of steps following a cold start of all sub-systems. This is the first sequence subject of lab testing.
diff --git a/docs/pon-testing/olt-oftest-notes.md b/docs/pon-testing/olt-oftest-notes.md
index aa44710..97d6521 100644
--- a/docs/pon-testing/olt-oftest-notes.md
+++ b/docs/pon-testing/olt-oftest-notes.md
@@ -4,11 +4,11 @@
Steps:
-### Bring up dev host and install prerequisites
+## Bring up dev host and install prerequisites
Assuming a fresh Vagrant machine:
-```
+```shell
cd ~/voltha # whatever location your Voltha repo dir is
rm -fr venv-linux # to make sure we don't have residues
vagrant destroy -f # ditto
@@ -22,11 +22,11 @@
pip install pypcap
```
-### Build Voltha proto derivatives and start Voltha
+## Build Voltha proto derivatives and start Voltha
On the above Vagrant box:
-```
+```shell
cd /voltha
. env.sh
make protos
@@ -38,7 +38,7 @@
Open three terminals on the Vagrant host. In terminal one, start voltha:
-```
+```shell
cd /voltha
. env.sh
./voltha/main.py --kafka=@kafka
@@ -46,7 +46,7 @@
In the second terminal, start chameleon:
-```
+```shell
cd /voltha
. env.sh
/chameleon/main.py -f pki/voltha.crt -k pki/voltha.key
@@ -54,7 +54,7 @@
In the third terminal, start ofagent:
-```
+```shell
cd /voltha
. env.sh
./ofagent/main.py
@@ -64,25 +64,25 @@
To see we can reach Voltha via REST:
-```
+```shell
curl -k -s https://localhost:8881/health | jq '.'
```
and
-```
+```shell
curl -k -s -H 'Get-Depth: 2' https://localhost:8881/api/v1/local | jq '.'
```
To verify we have exactly one logical device (this is important for olt-oftest, which assumes this):
-```
+```shell
curl -k -s https://localhost:8881/api/v1/local/logical_devices | jq '.items'
```
Check in the output that there is one entry in the logical device list, along these lines:
-```
+```json
[
{
"datapath_id": "1",
@@ -107,35 +107,32 @@
]
```
-
To verify that the above logical device has all three logical ports, run this:
-```
+```shell
curl -k -s https://localhost:8881/api/v1/local/logical_devices/simulated1/ports | jq '.items'
```
-This shall have three entries, one OLT NNI port and two ONU (UNI) ports. Make note of the corresponding
-```of_port.port_no``` numbers. They shall be as follows:
+This shall have three entries, one OLT NNI port and two ONU (UNI) ports. Make note of the corresponding *of_port.port_no* numbers. They shall be as follows:
-* For OLT port (```id=olt1```): ```ofp_port.port_no=129```
-* For ONU1 port (```id=onu1```): ```ofp_port.port_no=1```
-* For ONU2 port (```id=onu2```): ```ofp_port.port_no=2```
+* For OLT port (*id=olt1*): *ofp_port.port_no=129*
+* For ONU1 port (*id=onu1*): *ofp_port.port_no=1*
+* For ONU2 port (*id=onu2*): *ofp_port.port_no=2*
If they are different, you will need to adjust olt-oftest input arguments accordingly.
Finally, check the flow and flow_group tables of the logical device; they should both be empty at this point:
-
-```
+```shell
curl -k -s https://localhost:8881/api/v1/local/logical_devices/simulated1/flows | jq '.items'
curl -k -s https://localhost:8881/api/v1/local/logical_devices/simulated1/flow_groups | jq '.items'
```
-### Create fake interfaces needed by olt-oftest
+## Create fake interfaces needed by olt-oftest
Despite that we will run olt-oftest with "fake_dataplane" mode, meaning that it will not attempt to send/receive dataplane traffic, it still wants to be able to open its usual dataplane interfaces. We will make it happy by creating a few veth interfaces:
-```
+```shell
sudo ip link add type veth
sudo ip link add type veth
sudo ip link add type veth
@@ -146,9 +143,9 @@
sudo ifconfig veth6 up
```
-### Start olt-oftest in fake_dataplane mode
+## Start olt-oftest in fake_dataplane mode
-```
+```shell
cd /voltha
sudo -s
export PYTHONPATH=/voltha/voltha/adapters/tibit_olt:/voltha/mininet
@@ -161,5 +158,3 @@
```
The above shall finish with OK (showing seven (7) or more tests completed).
-
-