Accepted Solutions
Hello,
The root cause for this issue is due to :
The TWAMP timestamps can follow two different coding schemes: PTPv2 and NTP.
The coding format is normally defined by a Z-bit in the TWAMP message (rfc8762).
Z=0 => NTP
Z=1 => PTPv2
The ASR9K is sending the TWAMP message using PTPv2 timestamp encoding and this is flagged in rfc8762 with Z=1 as expected.
On the other end, the 7750 is reflecting the TWAMP packet back to the ASR9K using NTP for the timestamp encoding but without changing Z bit from 1 to 0 (Z-bit = 1 meaning PTPv2 encoding is left unchanged).
Encoding is defined by Z-bit value and 7750 doesn’t make the expected update when reflecting the TWAMP packet.
When ASR9K is receiving the TWAMP packet back for processing, it cannot make the right decoding as it thinks this is PTPv2 encoding according to Z bit value instead of NTP.
This is making the results false or unreliable.
This behavior where the z-bit is left unchanged is clearly stated in Nokia documentation, for release versions < 21.5: https://infocenter.nokia.com/public/7750SR222R1A/index.jsp?topic=%2Fcom.nokia.OAM_Guide%2Fprotocol-ai9exgsu5j.html « However, if the session-reflector only reflects the original ‟z-bit” it received from the session-sender and uses a different timestamp format in the packet, the delay calculations are not reliable because of the misinterpretation of the returned timestamp format.
SR OS session-reflectors running Release 21.5 and earlier always reflect the ‟z-bit” received from the session-sender. Regardless of the ‟z-bit”, these session-reflectors always encode an NTP timestamp format in the packet ».
CISCO Sender capture :
NOKIA Response Capture :
Regards
Hello,
The root cause for this issue is due to :
The TWAMP timestamps can follow two different coding schemes: PTPv2 and NTP.
The coding format is normally defined by a Z-bit in the TWAMP message (rfc8762).
Z=0 => NTP
Z=1 => PTPv2
The ASR9K is sending the TWAMP message using PTPv2 timestamp encoding and this is flagged in rfc8762 with Z=1 as expected.
On the other end, the 7750 is reflecting the TWAMP packet back to the ASR9K using NTP for the timestamp encoding but without changing Z bit from 1 to 0 (Z-bit = 1 meaning PTPv2 encoding is left unchanged).
Encoding is defined by Z-bit value and 7750 doesn’t make the expected update when reflecting the TWAMP packet.
When ASR9K is receiving the TWAMP packet back for processing, it cannot make the right decoding as it thinks this is PTPv2 encoding according to Z bit value instead of NTP.
This is making the results false or unreliable.
This behavior where the z-bit is left unchanged is clearly stated in Nokia documentation, for release versions < 21.5: https://infocenter.nokia.com/public/7750SR222R1A/index.jsp?topic=%2Fcom.nokia.OAM_Guide%2Fprotocol-ai9exgsu5j.html « However, if the session-reflector only reflects the original ‟z-bit” it received from the session-sender and uses a different timestamp format in the packet, the delay calculations are not reliable because of the misinterpretation of the returned timestamp format.
SR OS session-reflectors running Release 21.5 and earlier always reflect the ‟z-bit” received from the session-sender. Regardless of the ‟z-bit”, these session-reflectors always encode an NTP timestamp format in the packet ».
CISCO Sender capture :
NOKIA Response Capture :
Regards
