Propagating announce message.

[syedsk]

Does Open-AVB gptp daemon, support propagating announce message after receiving them? If so, how does it work? As an example If I have setup where two GM capable devices are connected to a switch with two ports: GM1---[port1 port2]----GM2 The goal here is that all the ports (GM1 port1 GM2 and port2) should sync to same GM clock(GM1 or GM2 based on bmca). From AVnu_SWAPIs document, 3.2.3.3, "Each non-leaf node is responsible for processing time synchronization data from its parent nodes and sending updated data to its children." How is this done using gptp daemon_cl?

If I run two instances of gptp daemon on port1 and port2 separately, how is the announce message received from GM1 on port1 propagated on port2? Is this through bridge SW? If I bridge these two ports as a linux bridge would that work? Or is it entirely done by the ascapable switch hw? Is there any scenario where I would see path trace tlv length(10.6.3.3.2 section in AS-rev std) > 1 purely using gptp daemon on two i210 ports running linux on PC.

Appreciate any feedback. thanks -syed

[christopher-s-hall]

The short answer is no. Open-AVB doesn't support time-aware bridge functionality. It maybe possible to "hack" together n instances of the gPTP daemon to service n ports. There is however a lot of shared state (e.g. the results of the BMCA would need to be shared).

A slightly better solution would be to take a look at the wireless branch which includes multiport code. I did test (not thoroughly) this with multiple ethernet devices and it did work correctly. Note that there have been a lot of improvements made to the open-avb-next and master branches, in terms of standards compliance, that you'll be missing on this branch.

More specific answers follow:

If I run two instances of gptp daemon on port1 and port2 separately, how is the announce message received from GM1 on port1 propagated on port2? Is this through bridge SW?

No. Propagation is probably the wrong terminology. All 802.1AS messages are regenerated, not forwarded. A non-grandmaster multiport device does propagate information about the grandmaster from the announce slave state machine on one port to the announce master state machine on all of the other ports, but the announce message isn't in any way forwarded.

One simple (at least in my opinion) way of thinking about this is to consider the case where the announce slave receives announce messages at a rate of 1 per second, but the master state machines are requested, through signaling messages, to send at a rate of 2 per second. There is no possible way that forwarding 802.1AS messages would work in this case.

Ordinary data frames would be forwarded in the normal way by Linux. This I have not tested. The OS must not forward 802.1AS frames and instead only deliver them, on receipt, to the gPTP daemon.

[pinealservo]

The example of path trace TLVs makes the same point as different announce rates; there's no way to handle that via the standard bridge forwarding process. You have to read the incoming frame in, then update the TLV before sending it out again.

802.1Q defines the behavior of all conforming LAN bridges, and 8.6 (The Forwarding Process) describes how forwarding works. The table 8-1 in that section includes a set of special MAC addresses with specific meanings to Bridges. The MAC Address used by 802.1AS is listed in table 8-1 as "Individual LAN Scope group address, Nearest Bridge group address" with a footnote: "It is intended that no IEEE 802.1 relay device will be defined that will forward frames that carry this destination address." All conforming bridges have to put these addresses in their filtering table so they're either forwarded to the local management entity or just dropped.

The Linux bridge subsystem works pretty much like 802.1Q describes; it's got a forwarding database and everything. I believe it automatically puts rules in its forwarding database to drop frames addressed to the table 8-1 addresses that shouldn't be forwarded. It knows how to natively handle spanning tree protocol BPDUs (which use one of the addresses from the table), but I'm not sure there's any way to do userspace handling of gPTP or MRP BPDUs for a Linux bridge. Linux-supported hardware bridges generally have a special kind of management interface descriptor or proprietary frame tag (see the net/dsa subdirectory of the Linux source tree) that lets you choose which egress port the management frames will go out on; without that or some fancy VLAN config and forward db reconfiguration, I don't know how you'd get BPDUs forwarded to the management interface and then back out to the correct ports. There may well be a way, but I think the software-defined-networking folks are doing that sort of thing via entirely different kernel components like Open vSwitch.

[syedsk]

Thanks for the excellent feedback. Coming to the choices: A slightly better solution would be to take a look at the wireless branch which includes multiport code. Is anyone actively working on this branch? I would like to use it as a first cut to test our hw for multi-port/TLV support. I would fork and test.

thanks and regards -syed

[syedsk]

Hi christopher-s-hall I tried to build and test wireless branch code. But didn't see any way around the application to "test with multiple ports". It only had one iface as input parameter. I am not sure launching two daemons on two interfaces would talk to each other. Could you give any pointers on how to test quoting your comment " I did test (not thoroughly) this with multiple ethernet devices and it did work correctly."

[christopher-s-hall]

I've only tested this and not released any code.

You'll need to instantiate multiple ports. There's not a lot more to it than this. Look at the addPeer code in the wireless code. It's called from Windows daemon_wl.cpp.

Also, take a look at MediaDependentEtherPort::processSync(). This shows how state is shared between ports for ethernet devices.