--- 1/draft-ietf-ippm-twamp-time-format-04.txt 2017-03-12 13:13:11.188472595 -0700 +++ 2/draft-ietf-ippm-twamp-time-format-05.txt 2017-03-12 13:13:11.208473069 -0700 @@ -1,20 +1,20 @@ Network Working Group G. Mirsky Internet-Draft ZTE Corp. Intended status: Standards Track I. Meilik -Expires: September 4, 2017 Broadcom - March 3, 2017 +Expires: September 13, 2017 Broadcom + March 12, 2017 Support of IEEE-1588 time stamp format in Two-Way Active Measurement Protocol (TWAMP) - draft-ietf-ippm-twamp-time-format-04 + draft-ietf-ippm-twamp-time-format-05 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 4, 2017. + This Internet-Draft will expire on September 13, 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 @@ -75,22 +75,22 @@ adopted the OWAMP-Test packet format and extended it by adding a format for a reflected test packet. Both the sender's and reflector's packets time stamps are expected to follow the 64-bit long NTP format [RFC5905]. NTP, when used over Internet, typically achieves clock accuracy of about 5ms to 100ms. Surveys conducted recently suggest that 90% devices achieve accuracy of better than 100 ms and 99% - better than 1 sec. It should be noted that NTP synchronizes clocks on the control plane, not on data plane. Distribution of clock within a node may be supported by independent 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 + distributed system. Any of the 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 specification's advantages. Another advantage is realized by @@ -125,23 +125,23 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "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 has been recognized and used as + Section 3.1 of [RFC5357]. In these procedures, the Modes field has + been used to identify and select specific communication capabilities. + At 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.