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)
10 files changed
tree: 95ef53babbc9bcccf9a85fafdbcfbf16c58a3b3b
  1. .bazelrc
  2. .dockerignore
  3. .github/
  4. .gitignore
  5. .gitreview
  6. BUILD
  7. CODE_OF_CONDUCT.md
  8. Dockerfile
  9. LICENSE.txt
  10. README.md
  11. RELEASES.md
  12. WORKSPACE
  13. apps/
  14. cli/
  15. core/
  16. deps/
  17. docs/
  18. drivers/
  19. models/
  20. pipelines/
  21. protocols/
  22. providers/
  23. tools/
  24. utils/
  25. web/
README.md

ONOS : Open Network Operating System

What is ONOS?

ONOS is the only SDN controller platform that supports the transition from legacy “brown field” networks to SDN “green field” networks. This enables exciting new capabilities, and disruptive deployment and operational cost points for network operators.

Top-Level Features

  • High availability through clustering and distributed state management.
  • Scalability through clustering and sharding of network device control.
  • Performance that is good for a first release, and which has an architecture that will continue to support improvements.
  • Northbound abstractions for a global network view, network graph, and application intents.
  • Pluggable southbound for support of OpenFlow, P4Runtime, and new or legacy protocols.
  • Graphical user interface to view multi-layer topologies and inspect elements of the topology.
  • REST API for access to Northbound abstractions as well as CLI commands.
  • CLI for debugging.
  • Support for both proactive and reactive flow setup.
  • SDN-IP application to support interworking with traditional IP networks controlled by distributed routing protocols such as BGP.
  • IP-Optical use case demonstration.

Getting started

Dependencies

The following packages are required:

  • git
  • zip
  • curl
  • unzip
  • python2.7
  • python3 (needed by Bazel)

Build ONOS from source

ONOS is built with Bazel, an open-source build tool developed by Google. We suggest downloading and installing Bazel using the official instructions.

The minimum required Bazel version is 1.0.0

  1. Clone the code from the ONOS Gerrit repository
$ git clone https://gerrit.onosproject.org/onos
  1. Optionally, you can add the ONOS developer environment to your bash profile. This will provide access to a number of handy commands to run, test and debug ONOS. No need to do this step again if you had done this before:
$ cd onos
$ cat << EOF >> ~/.bash_profile
export ONOS_ROOT="`pwd`"
source $ONOS_ROOT/tools/dev/bash_profile
EOF
$ . ~/.bash_profile
  1. Build ONOS with Bazel
$ cd $ONOS_ROOT
$ bazel build onos

Start ONOS on local machine

To run ONOS locally on the development machine, simply run the following command:

$ bazel run onos-local [-- [clean] [debug]]

Or simpler one, if you have added the ONOS developer environment to your bash profile:

$ ok [clean] [debug]

The above command will create a local installation from the ONOS tarbal (re-building if necessary) and will start the ONOS server in the background. In the foreground, it will display a continuous view of the ONOS (Apache Karaf) log file. Options following the double-dash (–) are passed through to the ONOS Apache Karaf and can be omitted. Here, the clean option forces a clean installation, removing any state from previous executions. The debug option means that the default debug port 5005 will be available for attaching a remote debugger.

Interacting with ONOS

To access ONOS UI, use a browser to open:

http://localhost:8181/onos/ui

Or simpler, use the onos-gui localhost command.

The default username and password is onos/rocks.

To attach to the ONOS CLI console, run:

$ onos localhost

Unit Tests

To run ONOS unit tests, including code Checkstyle validation, run the following command:

$ bazel query 'tests(//...)' | xargs bazel test

Or better yet, to run code Checkstyle and all unit tests use the following convenience alias:

$ ot

Contributing

ONOS code is hosted and maintained using Gerrit.

Code on GitHub is only a mirror. The ONOS project does NOT accept code through pull requests on GitHub.

To contribute to ONOS, please refer to Sample Gerrit Workflow. It should includes most of the things you'll need to get your contribution started!

More information

For more information, please check out our wiki page or mailing lists:

License

ONOS (Open Network Operating System) is published under Apache License 2.0