Support of the IEEE 1588 Timestamp Format in a Two-Way Active Measurement Protocol (TWAMP)
Extracted elements (15)
Converting PTP timestamps to NTP format in hardware requires additional resources such as microcode or processing elements. Allowing native PTP timestamp use in TWAMP/OWAMP simplifies data-plane hardware implementation.
PTP (IEEE 1588v2) allows sub-microsecond clock accuracy in the data plane, whereas NTP typically achieves only 5ms–100ms accuracy and synchronizes the control plane, not the data plane. Supporting PTP timestamps in TWAMP/OWAMP enables higher-precision IP performance measurements.
For TWAMP Light mode, this document does not specify how the Session-Sender and Session-Reflector are informed of the timestamp format to use. Configuration is assumed as the mechanism to direct participants to the appropriate format per their capabilities.
An endpoint (Session-Sender, Session-Receiver, or Session-Reflector) that supports this extension MUST be capable of interpreting both NTP and PTPv2 timestamp formats.
As a result of the Z field semantics change, the Sender Error Estimate (TWAMP) or Send Error Estimate (OWAMP) and Receive Error Estimate SHOULD NOT be ignored and MUST be used when calculating delay and delay-variation metrics based on collected timestamps.
If an endpoint does not support this extension, the value of the PTPv2 Timestamp flag MUST be 0, as it resides in a Must Be Zero field. A flag value of 0 indicates the node can use and interpret only NTP timestamp format.
Implementations of OWAMP and/or TWAMP MAY provide a configuration knob to bypass the timestamp format negotiation process and use locally configured values instead.
In OWAMP connection setup, if the Session-Receiver supports this extension, the Server MUST set the PTPv2 Timestamp flag to 1 in the Server Greeting message; otherwise the flag MUST be set to 0.
In OWAMP, if the Control-Client receives a Server Greeting with PTPv2 Timestamp flag set to 1 and the Session-Sender can use PTPv2 format, the Control-Client MUST set the PTPv2 Timestamp flag to 1 in the Set-Up-Response and the Session-Sender MUST use PTPv2 timestamp format.
In TWAMP connection setup, the Server MUST set the PTPv2 Timestamp flag to 1 in its greeting message if the Session-Reflector can produce PTPv2 timestamps; otherwise the flag MUST be set to 0.
In TWAMP, if the PTPv2 Timestamp flag in the Set-Up-Response is 0, the Session-Reflector MUST use the NTP timestamp format. If the Session-Reflector does not support NTP format, the Server MUST close the TCP connection associated with the TWAMP-Control session.
In TWAMP, the Control-Client MUST set the PTPv2 Timestamp flag to 1 in the Set-Up-Response Modes field if the Server advertised PTPv2 capability; otherwise it MUST be set to 0.
The Z field in the Error Estimate (defined in RFC 4656 Section 4.1.2) is repurposed as a 'Timestamp format' indicator: value 0 means NTP 64-bit format; value 1 means PTPv2-truncated format. This field signals the timestamp format used in a collected test packet.
IANA registered a new 'PTPv2 Timestamp Capability' entry in the TWAMP-Modes registry (RFC 5618) at bit position 9, referencing Section 2 of RFC 8186.
Use of a particular timestamp format (NTP or PTPv2) in a test session does not introduce any additional security threats beyond those already present in OWAMP (RFC 4656) and TWAMP (RFC 5357). The general security considerations for active measurement of live networks apply.