You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 7, 2020. It is now read-only.
The agent should collect link metrics for Ethernet links.
Specific neighbor at wired backhaul link (i.e. controller)
Invalid neighbor and other neighbors (requires topology database to be available)
All neighbors (requires topology database to be available)
Exit criteria
A mechanism exists to collect link metrics from the Ethernet interfaces registered in the agent.
LinkMetricsResponse TLVs are filled in with the correct data.
Test flow with dummy link metrics.
Manually tested on Turris Omnia.
Detailed description
To be decided how to collect link metrics. We may need to do it separately for wired and wireless links. Probably the cleanest is to have a separate abstraction library for it, even for wireless. Somehow, it should allow for different implementations for different interfaces. Link metric collection for WiFi links will be treated in a sibling task.
It's not very clear how this is going to be implemented for Ethernet links, because there is no way to know which part of the traffic goes to which 1905 neighbour - we only have the total traffic per port. I guess we'll just assume there are no non-1905 bridges/switches on the Ethernet link.
Finally, it has to be decided who is responsible for the link metric collection. Is it the agent or the topology manager?
The text was updated successfully, but these errors were encountered:
Description
The agent should collect link metrics for Ethernet links.
Exit criteria
Detailed description
To be decided how to collect link metrics. We may need to do it separately for wired and wireless links. Probably the cleanest is to have a separate abstraction library for it, even for wireless. Somehow, it should allow for different implementations for different interfaces. Link metric collection for WiFi links will be treated in a sibling task.
It's not very clear how this is going to be implemented for Ethernet links, because there is no way to know which part of the traffic goes to which 1905 neighbour - we only have the total traffic per port. I guess we'll just assume there are no non-1905 bridges/switches on the Ethernet link.
Finally, it has to be decided who is responsible for the link metric collection. Is it the agent or the topology manager?
The text was updated successfully, but these errors were encountered: