|author||Jan Kundrát <firstname.lastname@example.org>||Tue Oct 15 22:44:19 2019 +0200|
|committer||Andrea Campanella <email@example.com>||Wed Jan 22 08:59:19 2020 +0000|
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
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.
The following packages are required:
The minimum required Bazel version is 1.0.0
$ git clone https://gerrit.onosproject.org/onos
$ cd onos $ cat << EOF >> ~/.bash_profile export ONOS_ROOT="`pwd`" source $ONOS_ROOT/tools/dev/bash_profile EOF $ . ~/.bash_profile
$ cd $ONOS_ROOT $ bazel build onos
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.
To access ONOS UI, use a browser to open:
Or simpler, use the
onos-gui localhost command.
The default username and password is
To attach to the ONOS CLI console, run:
$ onos localhost
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:
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!
For more information, please check out our wiki page or mailing lists:
ONOS (Open Network Operating System) is published under Apache License 2.0