...

In the following, let's take LumentumWaveReadyDiscovery as an example. Here you can see how the behavior interacts with the TL1 controller. This For example, this is how we fetch the device description:.

// Fetch device description
Tl1Command ddCmd = DefaultTl1Command.builder()
        .withVerb(RTRV)
        .withModifier(NETYPE)
        .withCtag(101)
        .build();
Future<String> dd = ctrl.sendMsg(deviceId, ddCmd);

try {
    String ddResponse = dd.get(TIMEOUT, TimeUnit.MILLISECONDS);

    return new DefaultDeviceDescription(defaultDescription, true, extractAnnotations(ddResponse));
} catch (InterruptedException | ExecutionException | TimeoutException e) {
    log.error("Device description not found", e);
    return defaultDescription;
}

 We do three things: (1) build a TL1Command using a builder pattern, (2) send the message using the controller, and (3) wait for a response to arrive.

After implementing your behaviors, ensure that ONOS knows about them. Here is an example of the lumentum-drivers.xml.

<driver name="lumentum-waveready" manufacturer="Lumentum" hwVersion="WR*">
    <behaviour api="org.onosproject.net.device.DeviceDescriptionDiscovery"
               impl="org.onosproject.drivers.lumentum.LumentumWaveReadyDiscovery"/>
    <behaviour api="org.onosproject.net.optical.OpticalDevice"
               impl="org.onosproject.net.optical.DefaultOpticalDevice"/>
</driver>

...

Missing features / Help wanted

...

• Sending messages using the Tl1Controller uses the following signature. Ideally, we don't want to return a String but a Tl1Message that can easily be parsed.

  Code Block
  CompletableFuture<String> sendMsg(DeviceId deviceId, Tl1Command msg);

• There are no unit tests implemented as of yet.
• The Tl1Listener only has methods to signal device events (deviceConnected device connected and deviceDisconnecteddisconnected). Ideally we want to extend this to also cover other events, such as message and alarm notifications.
• As mentioned, we We need extensive testing to verify correct behavior in multi-instance ONOS deployments.
• Instead of storing login/password in the Tl1Device, use ONOS' DeviceKeyService sub-system dedicated to this job.
• Currently, the Tl1DeviceProvider will only login to the device when that instance becomes the master. In a multi-instance deployment, it's probably a good idea to have (some of) the standby instances logged in, ready to take over when they becomes master. This requires reworking the Tl1DeviceProvider, as well as a way to store multiple accounts per device.

...