Using gPTP - Showcase

[adamgeorge309]

Discuss the "Using gPTP" showcase here. Ideas and recommendations are welcome.

[jakobmiserez]

Hi, I'm having some questions regarding the following discussion on gPTP mechanisms.

The showcase states the following:

The spanning tree is created by labeling nodes’ interfaces (called ports) as either a master or a slave, with the slavePort and masterPorts parameters. Sync messages are sent on master ports, and received on slave ports. Master nodes only have master ports, and slave nodes only slave ports (bridge nodes have both). Consequently, since these ports define the spanning tree, each node can have just one slave port.

The gPTP module has the following distinct mechanisms:

• peer delay measurement: Slave and bridge nodes periodically measure link delay by sending peer delay request messages (pDelayReq) up-tree; they receive peer delay response messages (pDelayResp).

So if I understand it correctly: delay measurements are only done on the links of the spanning tree defined by the various master and slave ports. Looking at the implementation, this is what happens.

However, in the IEEE802.1AS-2020 standard, I found the following:

11.1.2 Propagation delay measurement
The measurement of propagation delay on a full-duplex point-to-point PTP Link using the peer-to-peer
delay mechanism is illustrated in Figure 11-1. The mechanism is the same as the peer-to-peer delay
mechanism described in IEEE Std 1588-2019, specialized to a two-step PTP Port14 and sending
the requestReceiptTimestamp and the responseOriginTimestamp separately [see item c) 8) of 11.4.2 in
IEEE Std 1588-2019]. The measurement is made by each port at the end of every full-duplex point-to-point
PTP Link. Thus, both ports sharing a PTP Link will independently make the measurement, and both ports
will know the propagation delay as a result. This allows the time-synchronization information described in
11.1.3 to be transported irrespective of the direction taken by a Sync message. The propagation delay
measurement is made on ports otherwise blocked by non-PTP algorithms (e.g., Rapid Spanning Tree
Protocol) used to eliminate cyclic topologies. This enables either no loss of synchronization or faster
resynchronization, after a reconfiguration, because propagation delays are already known and do not have to
be initially measured when the reconfiguration occurs.

If I understand correctly, this means that the delay measurements take place on all links, and master and slave ports do not matter in this case.

So my question is: is there a reason that the implementation of gPTP in INET does only measures link propagation delays on the spanning tree? Or am I interpreting something wrong?

Thanks!

[levy]

I guess it's simply implemented this way, because it's sufficient for the basic operation of the protocol. Only the slave ports send PdelayReqs towards the master ports along the configured static spanning tree. The spanning tree cannot be changed dynamically in a gPTP domain (i.e. it is static), switching between different gPTP domains means using a different spanning tree but it is still static.

[Abh4git]

Is gPTP support already in AccessPoints? Or is it planned soon?