commit 815fcd0de728ebeb32d35fa1795d724fff8671ef
author Jan Kundrát <jan.kundrat@cesnet.cz> Tue Oct 15 22:44:19 2019 +0200
committer Sean Condon <sean@opennetworking.org> Fri Jan 24 11:36:16 2020 +0000
tree 95ef53babbc9bcccf9a85fafdbcfbf16c58a3b3b
parent 283cae8419d8b69b9be8c92fe026ad04f1cb85b2

CzechLight ROADM driver

Czech Light is a family of open L0 device designs for building Open Line
Systems for DWDM networks. This driver talks NETCONF, the primary
communication protocol, to the devices and configures Media Channel (MC)
forwarding and provides real-time power readout. Not all features of
these devices are supported -- there's, e.g., detailed live spectrum
scanning, an OTDR functionality, neighbor discovery, etc. These are not
part of this driver.

What works:

- Device discovery for all different ROADM models:
  - Line/Degree w/ 9 Express ports
  - Flex Add/Drop w/ 20 Client ports
  - Coherent Add/Drop w/ 8 Client ports
  - even an Inline Amplifier (which is not a ROADM, but hey)
- Aggregate power readout (everywhere)
  - that's the reason for supporting the Inline Amp
- MC provisioning on all ROADMs:
  - tested on the Line/Degree model
  - including support for flexgrid
- Target power control on WSS-based devices

I noticed that various drivers use a different approach for power
control:

- Lumentum NETCONF reads the target power and pushes it as if it was
attenuation. This does not make sense to me because these values have a
directly opposite effect. Either way, "flows" do not have any info about
attenuation or desired Tx power.

- Oplink ROADM has a concept of target Tx power and it gets stored into
a *flow*.

I think that it would make a lot of sense to push these into the flows
(and also deprecate direct "power control" for ports, then), but I have
no idea how pervasive this is within current ONOS. Perhaps there is code
which makes assumptions about being able to modify port properties?

Limitations:

- The code won't create channels in the channel plan (which might be
important for flexgrid). If a flexgrid channel is already defined (not
necessarily routed, just listed in the list of channels within a channel
plan), then the code can use it just fine. If the channel definition is
missing, the MC won't be provisioned to the device.

- Some of the NETCONF parts could be probably refactored to a reusable
shape. I'm sure that the XPath parsing could be improved by using a
"real" helper of that HierarchicalConfiguration, etc.

- There's no caching, meaning that all queries hit the actual device
(which has an excellent NETCONF throughput if you ask me, though).

- The target Tx power levels when the channels are initially established
are a best effort thing, hoped to work in the majority of situations.
YMMV. They folow manufacturer's suggestions about power levels for
express, and a best guess for line out and client out ports.

- The long-haul connections have a VOA in the Tx path. This is intended
to be used to compensate for shorter spans than the maximal length.
Right now, there's no support for driving this directly from ONOS
because there is no concept for " optical properties applying to the
whole link" as far as I could tell.

- There's no inventory discovery which could be a useful thing.

This is a cleaned up version of the code which powered the demo at the
TIP Summit in Amsterdam, 2019. When testing manually, I was also able to
set up and tead down a MC connection, independently in both directions.
My professional background is not in Java (this is my second Java
project apart from upstream Gerrit at Google) that I contributed to, so
chances are that some of the idioms look weird. I tried to follow some
of the existing drivers, but improvements are certainly welcome!

Change-Id: Id59c5a9e71715d0ca63a7f5babe36b909970eb37
Bug: ONOS-8039
(cherry picked from commit 981fe47ba3870b1181e7ae4bd04de6ea63dd22f6)