Topology discovery full support

[arnout]

Description

For certification, it is sufficient to only support part of topology discovery (cfr. #120, #186). For a fully operational controller, however, it is needed to fully support topology discovery at least in the controller. It is also required in the agent if IEEE 1905.1 compliance is desired.

• [TASK] Topology discovery - controller certification #120 Topology discovery - Controller certification
• 5.3.1 Supported Discovery #186 5.3.1 Supported discovery
• [TASK] Construct topology response message #525 Construct topology response message
• Topology discovery exploration and design #830 Make a design for complete topology discovery support
• [TASK] Per-interface Topology Discovery #1160 per-interface Topology Discovery message
• [TASK] Extend topology database to store neighbor's interface and MAC address #1425 Extend topology database to store neighbor's interface and MAC address
• [TASK] Use neighbor's interface info in Topology Response #1428 Use neighbor's interface info in Topology Response
• [TASK] Add Device Bridging Capability TLV to Topology Response message #701 Add Device Bridging Capability TLV to Topology Response message
• [TASK] Detect topology changes on the network #925 Detect topology changes on the network

Exit criteria

• Topology agent (framework/discovery_agent/) is built
• Topology agent is started by prplmesh_utils.sh
• Topology agent sends a topology notification every 60 seconds
• Topology agent listens for topology query and constructs topology response ([TASK] Construct topology response message #525)

Detailed description

Problem statement

Both the agent and the controller, when operating independently, must perform the topology discovery functions. Therefore, it is not simply possible to implement this functionality in one of them.

Both the agent and the controller need to know some of the topology information. Mainly the controller needs it to discover stations connecting and disconnecting.

Possible solutions

1. The functionality is provided by a library in common or framework and linked with both controller and agent. If a device has both agent and controller, the agent signals its presence to the controller and the controller disables its topology functionality.
2. An additional component takes care of the topology discovery. This component is always running (much like the ieee1905_transport component), in agent, controller, and agent+controller mode.

The second option is conceptually cleaner so that one is chosen.

Components affected

A topology discovery agent already exists in framework/discovery_agent, but it is currently not built and probably broken. So that has to be revived.

The discovery is responsible for sending out notifications regularly. It will also be responsible for most of the rest of the IEEE1905.1 functionality, though that doesn't need to be implemented for EasyMesh certification.

Topology information is needed by agent and controller as well. The topology discovery agent will manage the protocol messages (e.g. sending out regular topology discovery messages and responding with topology query). The other components will keep a local topology database and listen to the relevant CMDUs (e.g. responses to the topology queries sent out by the topology discovery agent) to update that database.

Agent and controller may also emit topology related messages autonomously. For example, the agent emits a topology notification message when a station connects or disconnects. That functionality will stay in the agent.

For now, the topology discovery doesn't need to actually construct a topology database. That will be needed for sending 1905.1 neighbour information, but we don't need that at this time.

[tomereli]

Discovery agent full support