Event message是需要生成时间戳的message，General message是不需要生成时间戳的消息。
The computation of offset and propagation time assumes that the master-to-slave and slave-to-master propagation times are equal.
Any asymmetry in propagation time introduces an error in the computed value of the clock offset. The computed mean propagation time differs from the actual propagation times due to the asymmetry.
p2p link delay是各自方向上都计算一次, 而且因为loop被裁剪的端口也要计算，这样当topo变化时可以很快得到delay。
The protocol does not assume that only a single copy of a multicast message sent by one PTP port is received on another PTP port;
however, receipt of duplicate copies may impact the precision of time transfer and therefore networks should be designed to avoid this behavior.
tms = <meanPathDelay> + delayAsymmetry
tsm = <meanPathDelay> ─ delayAsymmetry
In other words, delayAsymmetry is defined to be positive when the master-to-slave or responder-to- requestor propagation time is longer
than the slave-to-master or requestor-to-responder propagation time.
The Follow_Up message should be transmitted as soon as possible after the transmission of the associated Sync message
and shall be transmitted prior to the transmission of a subsequent Sync message to the same destination address.
The Delay_Resp message should be transmitted as soon as possible after the receipt of the associated Delay_Req message.
Pdelay_Resp messages should be transmitted as soon as possible after the receipt of the associated
Pdelay_Req message.
Pdelay_Resp_Follow_Up messages should be transmitted as soon as possible after the transmission of the
associated Pdelay_Resp message.
The specifications in Clause 11 provide mechanisms for conveying timestamps generated at the sources of event messages along with any corrections needed to ensure that
the recipient of the event message receives the most accurate timestamp possible.
Clause 11 specifies:
a) The computation of the offset in time between a slave and a master clock, i.e., <offsetFromMaster>.
b) The delay request-response mechanism: This mechanism measures the <meanPathDelay> between a pair of ports, each of which supports the state machine of 9.2.5.
c) The peer delay mechanism: This mechanism measures the <meanPathDelay> between a pair of ports, each of which supports the peer delay mechanism.
d) The correction for <meanPathDelay> in peer-to-peer transparent clocks.
e) The correction of event messages in transparent clocks based on the measurement of the residence time within a transparent clock, and
f) The correction of timestamps for path asymmetry.
The <offsetFromMaster> value shall be computed by the slave as follows:
a) Upon receipt of a Sync message, the slave shall generate a timestamp <syncEventIngressTimestamp> corrected for latency per 7.3.4.
If the delayAsymmetry (see 7.4.2) of the path connected to the ingress port is known, the corrections of 11.6 shall be made.
b) If the twoStepFlag bit of the flagField of the of the Sync message, is FALSE, indicating that a Follow_Up message will not be received, then the
<offsetFromMaster> = <syncEventIngressTimestamp> ─ <originTimestamp> ─ <meanPathDelay> ─ correctionField of Sync message.
c) If the twoStepFlag bit of the flagField of the of the Sync message is TRUE, indicating that a Follow_Up message will be received, then the
<offsetFromMaster> = <syncEventIngressTimestamp> ─ <preciseOriginTimestamp> ─ <meanPathDelay> ─ correctionField of Sync message ─ correctionField of Follow_Up message.
Delay request-response mechanism operational specifications:
a) The master node prepares and issues a Sync message per 9.5.9. If the node is a two-step clock, it also prepares and issues a Follow_Up message per 9.5.9.4.
b) The slave node shall:
1) Upon receipt of the Sync message from the master generate timestamp t2.
2) If asymmetry corrections are required, modify the correctionField of the received Sync message per 11.6.2.
3) If required to send a Delay_Req message based on the timing requirements of subclause 9.5.11.2:
i) Prepare a Delay_Req message with the correctionField (see 13.3.2.7) set to 0. The originTimestamp shall be set to 0 or
an estimate no worse than ±1 s of the egress time of the Delay_Req message.
ii) If asymmetry corrections are required, modify the correctionField per 11.6.3.
iii) Send the Delay_Req message and generate and save timestamp t3.
c) Upon receipt of the Delay_Req message, the master node shall :
1) Generate timestamp t4
2) Prepare a Delay_Resp message
3) Copy the sequenceId field from the Delay_Req message to the sequenceId field of the Delay_Resp message
4) Copy the sourcePortIdentity field from the Delay_Req message to the requestingPortIdentity field of the Delay_Resp message
5) Copy the domainNumber field from the Delay_Req message to the domainNumber field of the Delay_Resp message
6) Set the correctionField of the Delay_Resp message to 0
7) Add the correctionField of the Delay_Req message to the correctionField of the Delay_Resp message
8) Set the receiveTimestamp field of the Delay_Resp message to the seconds and nanoseconds portion of the time t4
9) Subtract any fractional nanosecond portion of t4 from the correctionField of the Delay_Resp message
10) IssuetheDelay_Respmessage
d) Upon receipt of the Delay_Resp message by the slave:
1) If the received Sync message indicated that a Follow_Up message will not be received, the <meanPathDelay> shall be computed as:
<meanPathDelay> = [(t2 - t3) + (receiveTimestamp of Delay_Resp message – originTimestamp of Sync message) – correctionField of Sync message – correctionField of Delay_Resp message]/2.
2) If the received Sync message indicated that a Follow_Up message will be received, the <meanPathDelay> shall be computed as:
<meanPathDelay> = [(t2 - t3) + (receiveTimestamp of Delay_Resp message – preciseOriginTimestamp of Follow_Up message) – correctionField of Sync message– correctionField of Follow_Up message – correctionField of Delay_Resp message]/2.
Peer delay mechanism operational specifications:
a) The delay requestor, Node-A:
1) Prepares a Pdelay_Req message. The correctionField (see 13.3.2.7) shall be set to 0.
i) If Node-A is an ordinary or boundary clock, then the domainNumber field of the header shall be set to the domain of Node-A.
ii) If Node-A is a syntonized peer-to-peer transparent clock, the domainNumber field of the header should be set to the domain being measured,
either the primary syntonization domain, or one of the alternate domains if syntonization to multiple domains is implemented on Node-A.
iii) If Node-A is not a syntonized peer-to-peer transparent clock, the domainNumber field of the header shall be set to 0.
2) If asymmetry corrections are required, shall modify the correctionField per 11.6.4.
3) Shall set the originTimestamp to 0 or an estimate no worse than ±1 s of the egress timestamp, t1, of the Pdelay_Req message.
4) Shall send the Pdelay_Req message and generate and save timestamp t1
b) If the delay responder, Node-B, is a one-step clock, it shall:
1) Generate timestamp t2 upon receipt of the Pdelay_Req message
2) Prepare a Pdelay_Resp message
3) Copy the sequenceId field from the Pdelay_Req message to the sequenceId field of the Pdelay_Resp message
4) Copy the sourcePortIdentity field from the Pdelay_Req message to the requestingPortIdentity field of the Pdelay_Resp message
5) Copy the domainNumber field from the Pdelay_Req message to the domainNumber field of the Pdelay_Resp message
6) Copy the correctionField from the Pdelay_Req message to the correctionField of the Pdelay_Resp message
7) Then:
i) Set to 0 the requestReceiptTimestamp field of the Pdelay_Resp message
ii) Issue the Pdelay_Resp message and generate timestamp t3 upon sending
iii) After t3 is generated but while the Pdelay_Resp message is leaving the responder, shall add the turnaround time t3 − t2 to the
correctionField of the Pdelay_Resp message and make any needed corrections to checksums or other content-dependent fields of the Pdelay_Resp message
c) If the delay responder is a two-step clock, it shall:
1) Generate timestamp t2 upon receipt of the Pdelay_Req message
2) Prepare a Pdelay_Resp and a Pdelay_Resp_Follow_Up message
3) Copy the correctionField from the Pdelay_Req message to the correctionField of the Pdelay_Resp_Follow_Up message, and set correctionField of the Pdelay_Resp message to 0
4) Copy the sequenceId field from the Pdelay_Req message to the sequenceId field of the Pdelay_Resp and the Pdelay_Resp_Follow_Up messages
5) Copy the sourcePortIdentity field from the Pdelay_Req message to the requestingPortIdentity field of the Pdelay_Resp and the Pdelay_Resp_Follow_Up messages
6) Copy the domainNumber field from the Pdelay_Req message to the domainNumber field of the Pdelay_Resp and Pdelay_Resp_Follow_Up messages
7) Then either:
i) Set to 0 the requestReceiptTimestamp fields of the Pdelay_Resp message
ii) Issue the Pdelay_Resp message and generate timestamp t3 upon sending
iii) In the Pdelay_Resp_Follow_Up message, set the responseOriginTimestamp field to 0, and add the turnaround time t3 − t2 to the correctionField
iv) Issue the Pdelay_Resp_Follow_Up message
8) Or,
i) In the Pdelay_Resp message, set the requestReceiptTimestamp field to the seconds and nanoseconds portion of the time t2,
and subtract any fractional nanosecond portion of t2 from the correctionField
ii) Issue the Pdelay_Resp message and generate timestamp t3 upon sending
iii) In the Pdelay_Resp_Follow_Up message, set the responseOriginTimestamp field to the seconds and nanoseconds portion of the time t3,
and add any fractional nanosecond portion of t3 to the correctionField
iv) Issue the Pdelay_Resp_Follow_Up message
d) The delay requestor, Node-A, shall:
1) Generate timestamp t4 upon receipt of the Pdelay_Resp message
2) If asymmetry corrections are required, modify the correctionField of the Pdelay_Resp message per 11.6.5
3) If the twoStepFlag of the received Pdelay_Resp message is FALSE, indicating that no Pdelay_Resp_Follow_Up message will be received, compute the <meanPathDelay> as:
<meanPathDelay> = [(t4 − t1) − correctionField of Pdelay_Resp]/2
4) If the twoStepFlag of the received Pdelay_Resp message is TRUE indicating that a Pdelay_Resp_Follow_Up will be received, compute the <meanPathDelay> as follows:
<meanPathDelay> = [(t4 − t1) − (responseOriginTimestamp − requestReceiptTimestamp) − correctionField of Pdelay_Resp − correctionField of Pdelay_Resp_Follow_Up]/2
Path delay correction in transparent clocks:
1. Peer-to-peer transparent clocks
A port on a peer-to-peer transparent clock upon receiving a Sync message shall:
a) If the clock is a one-step peer-to-peer clock, add the value of the <meanPathDelay>, as measured by peer delay mechanism for the link connected to the ingress port
on which the Sync message was received to the correctionField of the Sync message prior to the completion of the transmission of the Sync message on each of the egress ports.
b) If the clock is a two-step peer-to-peer clock, add the value of the <meanPathDelay>, as measured by peer delay mechanism, for the link connected to the ingress port
on which the Sync message was received to the correctionField of the associated Follow_Up message prior to the transmission of the Follow_Up message on each of the egress ports.
The <meanPathDelay> shall be added subsequent to any residence time corrections; see 11.5.2.2.
2. End-to-end transparent clocks
An end-to-end transparent clock shall not correct for path delay on either ingress or egress ports.
Two-step transparent clocks 如果接收到one step消息，也要通过two step的方式转发。
Asymmetry correction for PTP version 2 event messages:
把delayAsymmetry加到engress的sync的correctionField
同上，Delay_Req做减法
同上，Pdelay_Req做减法
同上，Pdelay_Resp做加法
residentTime不是delay的一部分，计算出来的delay不包括residentTime。但是计算offset的时候会减去residentTime(包含在sync的correction字段中)。
如果设置了asymmetry，那么在correction中就会包括asymmetry（sync做加法，delay_req做减法）。