--- 1/draft-ietf-ippm-twamp-time-format-03.txt 2017-03-03 17:13:08.981537102 -0800 +++ 2/draft-ietf-ippm-twamp-time-format-04.txt 2017-03-03 17:13:09.001537573 -0800 @@ -1,20 +1,20 @@ Network Working Group G. Mirsky Internet-Draft ZTE Corp. Intended status: Standards Track I. Meilik -Expires: September 3, 2017 Broadcom - March 2, 2017 +Expires: September 4, 2017 Broadcom + March 3, 2017 Support of IEEE-1588 time stamp format in Two-Way Active Measurement Protocol (TWAMP) - draft-ietf-ippm-twamp-time-format-03 + draft-ietf-ippm-twamp-time-format-04 Abstract This document describes an OPTIONAL feature for active performance measurement protocols allowing use of the Precision Time Protocol time stamp format defined in IEEE-1588v2-2008, as an alternative to the Network Time Protocol that is currently used. Status of This Memo @@ -24,21 +24,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 3, 2017. + This Internet-Draft will expire on September 4, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -85,33 +85,34 @@ distributed system. And of mentioned solutions will be subject to additional queuing delays that negatively affect data plane clock accuracy. Precision Time Protocol (PTP) [IEEE.1588.2008] has gained wide support since the development of OWAMP and TWAMP. PTP, using on-path support and other mechanisms, allows sub-microsecond clock accuracy. PTP is now supported in multiple implementations of fast forwarding engines and thus accuracy achieved by PTP is the accuracy of clock in data plane. An option to use a more accurate clock as a source of - time stamps for IP performance measurements is one of this proposal?s - advantages. Another advantage is realized by simplification of - hardware in data plane. To support OWAMP or TWAMP test protocol time - stamps must be converted from PTP to NTP. That requires resources, - use of micro-code or additional processing elements, that are always - limited. To address this, this document proposes optional extensions - to Control and Test protocols to support use of IEEE-1588v2 time - stamp format as optional alternative to the NTP time stamp format. + time stamps for IP performance measurements is one of this + specification's advantages. Another advantage is realized by + simplification of hardware in data plane. To support OWAMP or TWAMP + test protocol time stamps must be converted from PTP to NTP. That + requires resources, use of micro-code or additional processing + elements, that are always limited. To address this, this document + proposes optional extensions to Control and Test protocols to support + use of IEEE-1588v2 time stamp format as optional alternative to the + NTP time stamp format. - One of the goals of this proposal is not only to allow end-points of - a test session to use timestamp format other than NTP but to support - backwards compatibility with nodes that do not yet support this - extension. + One of the goals of this specification is not only to allow end- + points of a test session to use timestamp format other than NTP but + to support backwards compatibility with nodes that do not yet support + this extension. 1.1. Conventions used in this document 1.1.1. Terminology IPPM: IP Performance Measurement NTP: Network Time Protocol PTP: Precision Time Protocol @@ -154,48 +155,45 @@ In OWAMP-Test [RFC4656] the Session-Receiver and/or Fetch-Client interpret collected timestamps. Thus, the Server uses the Modes field timestamp format to indicate which formats the Session-Receiver is capable to interpret. The Control-Client inspects values set by the Server for timestamp formats and sets values in the Modes field of the Set-Up-Response message according to timestamp formats Session-Sender can use. The rules of setting timestamp flags in Modes field in server greeting and Set-Up-Response messages and interpreting them are as follows: - o The Server that establishes test sessions for Session-Receiver - that supports this extension MUST set PTPv2 Timestamp flag to 1 in - the server greeting message per the requirement listed in - Section 2. - - o If PTPv2 Timestamp flag of the server greeting message that the - Control-Client receives has value 0, then the Session-Sender MUST - use NTP format for timestamp in the test session and Control- - Client SHOULD set PTPv2 Timestamp flag to 0 in accordance with - [RFC4656]. If the Session-Sender cannot use NTP timestamps, then - the Control-Client SHOULD close the TCP connection associated with - the OWAMP-Control session. + o If the Session-Receiver supports this extension, then the Server + that establishes test sessions on its behalf MUST set PTPv2 + Timestamp flag to 1 in the server greeting message per the + requirement listed in Section 2. Otherwise, the PTPv2 Timestamp + flag will be set to 0 to indicate that the Session-Receiver + interprets only NTP format. - o If the Session-Sender can set timestamp in PTPv2 format, then the - Control-Client MUST set the PTPv2 Timestamp flag to 1 in Modes - field in the Set-Up-Response message and the Session-Sender MUST - set timestamp in PTPv2 timestamp format. Otherwise the Control- - Client MUST set the PTPv2 Timestamp flag in the Set-Up-Response - message to 0. + o If the Control-Client receives greeting message with the PTPv2 + Timestamp flag set to 0, then the Session-Sender MUST use NTP + format for timestamp in the test session and Control-Client SHOULD + set PTPv2 Timestamp flag to 0 in accordance with [RFC4656]. If + the Session-Sender cannot use NTP timestamps, then the Control- + Client SHOULD close the TCP connection associated with the OWAMP- + Control session. - o Otherwise, if the Session-Sender can set timestamp in NTP format, - then the Session-Sender MUST set timestamp in NTP timestamp - format. Otherwise the Control-Client MUST close the TCP - connection associated with the OWAMP-Control session. + o If the Control-Client receives greeting message with the PTPv2 + Timestamp flag set to 1 and the Session-Sender can set timestamp + in PTPv2 format, then the Control-Client MUST set the PTPv2 + Timestamp flag to 1 in Modes field in the Set-Up-Response message + and the Session-Sender MUST use PTPv2 timestamp format. - If values of both NTP and PTPv2 Timestamp flags in the Set-Up- - Response message are equal to 0, then that indicates that the - Control-Client can set timestamp only in NTP format. + o If the Session-Sender doesn't support this extension and can set + timestamp only in NTP format, then the PTPv2 Timestamp flag in + Modes field in the Set-Up-Response message will be set to 0 as + part of Must Be Zero and the Session-Sender use NTP format. If OWAMP-Control uses Fetch-Session commands, then selection and use of one or another timestamp format is local decision for both Session-Sender and Session-Receiver. 2.2. Timestamp Format Negotiation in Setting Up Connection in TWAMP In TWAMP-Test [RFC5357] the Session-Sender interprets collected timestamps. Hence, in the Modes field a Server advertises timestamp formats that the Session-Reflector can use in TWAMP-Test message. @@ -223,27 +221,28 @@ o If the values of PTPv2 Timestamp flag in the Set-Up-Response message equals 0, then that means that Session-Sender can only interpret NTP timestamp format. Then the Session-Reflector MUST use NTP timestamp format. If the Session-Reflector does not support NTP format then Server and MUST close the TCP connection associated with the TWAMP-Control session. 2.3. OWAMP-Test and TWAMP-Test Update Participants of a test session need to indicate which timestamp - format being used. The proposal is to use Z field in Error Estimate - defined in Section 4.1.2 of [RFC4656]. The new interpretation of the - Error Estimate is in addition to it specifying error estimate and - synchronization, Error Estimate indicates format of a collected - timestamp. And this proposal changes the semantics of the Z bit - field, the one between S and Scale fields, to be referred as - Timestamp format and value MUST be set per the following: + format being used. The specification is to use Z field in Error + Estimate defined in Section 4.1.2 of [RFC4656]. The new + interpretation of the Error Estimate is in addition to it specifying + error estimate and synchronization, Error Estimate indicates format + of a collected timestamp. And this specification changes the + semantics of the Z bit field, the one between S and Scale fields, to + be referred as Timestamp format and value MUST be set per the + following: o 0 - NTP 64 bit format of a timestamp; o 1 - PTPv2 truncated format of a timestamp. As result of this value of the Z field from Error Estimate, Sender Error Estimate or Send Error Estimate and Receive Error Estimate SHOULD NOT be ignored and MUST be used when calculating delay and delay variation metrics based on collected timestamps.