--- 1/draft-ietf-ippm-twamp-time-format-01.txt 2017-02-24 15:13:08.180206508 -0800 +++ 2/draft-ietf-ippm-twamp-time-format-02.txt 2017-02-24 15:13:08.196206672 -0800 @@ -1,47 +1,48 @@ Network Working Group G. Mirsky Internet-Draft Intended status: Standards Track I. Meilik -Expires: May 9, 2017 Broadcom - November 8, 2016 +Expires: August 29, 2017 Broadcom + February 25, 2017 Support of IEEE-1588 time stamp format in Two-Way Active Measurement Protocol (TWAMP) - draft-ietf-ippm-twamp-time-format-01 + draft-ietf-ippm-twamp-time-format-02 Abstract This document describes an OPTIONAL feature for active performance - measurement protocols allowing use of time stamp format defined in - IEEE-1588v2-2008. + 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 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 May 6, 2017. + This Internet-Draft will expire on August 29, 2017. Copyright Notice - Copyright (c) 2016 IETF Trust and the persons identified as the + 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -83,35 +84,34 @@ NTP domain or via interprocess communication in multiprocessor 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. Thus, providing option to use more accurate clock as - source of time stamps for IP performance measurement is one of - advantages this proposal helps to achieve. Another advantage 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. + 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. - One of the goals of this proposal is not only allow end-points of a - test session to use other than NTP timestamp but to support backwards - compatibility with nodes that do not yet support this extension. + 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. 1.1. Conventions used in this document 1.1.1. Terminology IPPM: IP Performance Measurement NTP: Network Time Protocol PTP: Precision Time Protocol @@ -126,47 +126,47 @@ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. OWAMP and TWAMP Extensions OWAMP connection establishment follows the procedure defined in Section 3.1 of [RFC4656] and additional steps in TWAMP described in Section 3.1 of [RFC5357]. In these procedures, the Modes field been used to identify and select specific communication capabilities. At - the same time the Modes field been recognized and used as extension - mechanism [RFC6038]. The new feature requires one bit position for - Server and Control-Client to negotiate which timestamp format can be - used in some or all test sessions invoked with this control - connection. The end-point of the test session, Session-Sender and - Session-Receiver or Session-Reflector, that supports this extension - MUST be capable to interpret NTP and PTPv2 timestamp formats. If the - end-point does not support this extension, then the value of PTPv2 - Timestamp flag MUST be 0 because it is in Must Be Zero field. If - value of PTPv2 Timestamp flags is 0, then the advertising node can - use and interpret only NTP timestamp format. + the same time the Modes field has been recognized and used as + extension mechanism [RFC6038]. The new feature requires one bit + position for Server and Control-Client to negotiate which timestamp + format can be used in some or all test sessions invoked with this + control connection. The end-point of the test session, Session- + Sender and Session-Receiver or Session-Reflector, that supports this + extension MUST be capable to interpret NTP and PTPv2 timestamp + formats. If the end-point does not support this extension, then the + value of PTPv2 Timestamp flag MUST be 0 because it is in Must Be Zero + field. If the value of PTPv2 Timestamp flags is 0, then the + advertising node can use and interpret only NTP timestamp format. - Use of PTPv2 Timestamp flags discussed in the following sub-sections. - For details on the assigned values and bit positions see the - Section 3. + Use of PTPv2 Timestamp flags is discussed in the following sub- + sections. For details on the assigned values and bit positions see + the Section 3. 2.1. Timestamp Format Negotiation in Setting Up Connection in OWAMP - In OWAMP-Test [RFC4656] it is the Session-Receiver and/or Fetch- - Client that are interpreting collected timestamps. Thus, announced by - a Server in the Modes field timestamp format indicates 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 per - 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: + 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 @@ -176,63 +176,63 @@ o If the Session-Sender can set timestamp in PTPv2 format, then the Control-Client MUST set the PTPv2 Timestamp flag to 1in 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 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 SHOULD close the TCP + format. Otherwise the Control-Client MUST close the TCP connection associated with the OWAMP-Control session. 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. 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] it is the Session-Sender that is interpreting - collected timestamps. Hence, in the Modes field a Server advertises - timestamp formats that the Session-Reflector can use in TWAMP-Test - message. The choice of the timestamp format to be used by the - Session-Sender is a local decision. The Control-Client inspects the - Modes field and sets timestamp flags values to indicate which format - will be used by the Session-Reflector. The rules of setting and - interpreting flag values are as follows: + 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. + The choice of the timestamp format to be used by the Session-Sender + is a local decision. The Control-Client inspects the Modes field and + sets timestamp flags values to indicate which format will be used by + the Session-Reflector. The rules of setting and interpreting flag + values are as follows: o Server MUST set to 1 value of PTPv2 Timestamp flag in its greeting message if Session-Reflector can set timestamp in PTPv2 format. Otherwise the PTPv2 Timestamp flag MUST be set to 0. o If value of the PTPv2 Timestamp flag in received server greeting message equals 0, then Session-Reflector does not support this extension and will use NTP timestamp format. Control-Client SHOULD set PTPv2 Timestamp flag to 0 in Set-Up-Response message in accordance with [RFC5357]. o Control-Client MUST set PTPv2 Timestamp flag value to 1 in Modes field in the Set-Up-Response message if Server advertised ability of the Session-Reflector to use PTPv2 format for timestamps. Otherwise the flag MUST be set to 0. 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 for timestamps then Server and SHOULD close the - TCP connection associated with the TWAMP-Control session. + 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