Versions Compared

Old Version 8

changes.mady.by.user Marc De Leenheer

Saved on

compared with

New Version 9

changes.mady.by.user Marc De Leenheer

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Implementations of all these interfaces are prefixed with Default, for instance DefaultTl1Controller holds the implementation of the Tl1Controller interface.

Tl1Controller

We provider here some more details on the implementation of the TL1 controller. In 

Device Provider

The ONOS TL1 southbound is implemented in the Tl1DeviceProvider. This class implements the ONOS SB interface, and most importantly, will connect to the device when it is assigned the master role (in all other cases the instance will disconnect from the device). When a device is connected, the device provider will use the DeviceDescriptionDiscovery to fetch and update the device/port description.

Adding devices to ONOS is done by injecting them into the device provider, more specifically Here is an example JSON, that you will inject into ONOS using onos-netcfg $OC1 tl1.json.

...

  • 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);
  • We do not support autonomous messages (alarms, notifications) from the device to the controller. Only request/reply pattern is currently implemented.
  • There are no unit tests implemented as of yet.
  • The Tl1Listener only has methods to signal device events (device connected and disconnected). Ideally we want to extend this to also cover other events, such as message and alarm notifications.
  • 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.

...