draft-ietf-ippm-twamp-time-format-04.txt   draft-ietf-ippm-twamp-time-format-05.txt 
Network Working Group G. Mirsky Network Working Group G. Mirsky
Internet-Draft ZTE Corp. Internet-Draft ZTE Corp.
Intended status: Standards Track I. Meilik Intended status: Standards Track I. Meilik
Expires: September 4, 2017 Broadcom Expires: September 13, 2017 Broadcom
March 3, 2017 March 12, 2017
Support of IEEE-1588 time stamp format in Two-Way Active Measurement Support of IEEE-1588 time stamp format in Two-Way Active Measurement
Protocol (TWAMP) Protocol (TWAMP)
draft-ietf-ippm-twamp-time-format-04 draft-ietf-ippm-twamp-time-format-05
Abstract Abstract
This document describes an OPTIONAL feature for active performance This document describes an OPTIONAL feature for active performance
measurement protocols allowing use of the Precision Time Protocol measurement protocols allowing use of the Precision Time Protocol
time stamp format defined in IEEE-1588v2-2008, as an alternative to time stamp format defined in IEEE-1588v2-2008, as an alternative to
the Network Time Protocol that is currently used. the Network Time Protocol that is currently used.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 41 skipping to change at page 2, line 41
adopted the OWAMP-Test packet format and extended it by adding a adopted the OWAMP-Test packet format and extended it by adding a
format for a reflected test packet. Both the sender's and format for a reflected test packet. Both the sender's and
reflector's packets time stamps are expected to follow the 64-bit reflector's packets time stamps are expected to follow the 64-bit
long NTP format [RFC5905]. NTP, when used over Internet, typically long NTP format [RFC5905]. NTP, when used over Internet, typically
achieves clock accuracy of about 5ms to 100ms. Surveys conducted achieves clock accuracy of about 5ms to 100ms. Surveys conducted
recently suggest that 90% devices achieve accuracy of better than 100 recently suggest that 90% devices achieve accuracy of better than 100
ms and 99% - better than 1 sec. It should be noted that NTP ms and 99% - better than 1 sec. It should be noted that NTP
synchronizes clocks on the control plane, not on data plane. synchronizes clocks on the control plane, not on data plane.
Distribution of clock within a node may be supported by independent Distribution of clock within a node may be supported by independent
NTP domain or via interprocess communication in multiprocessor NTP domain or via interprocess communication in multiprocessor
distributed system. And of mentioned solutions will be subject to distributed system. Any of the mentioned solutions will be subject
additional queuing delays that negatively affect data plane clock to additional queuing delays that negatively affect data plane clock
accuracy. accuracy.
Precision Time Protocol (PTP) [IEEE.1588.2008] has gained wide Precision Time Protocol (PTP) [IEEE.1588.2008] has gained wide
support since the development of OWAMP and TWAMP. PTP, using on-path support since the development of OWAMP and TWAMP. PTP, using on-path
support and other mechanisms, allows sub-microsecond clock accuracy. support and other mechanisms, allows sub-microsecond clock accuracy.
PTP is now supported in multiple implementations of fast forwarding PTP is now supported in multiple implementations of fast forwarding
engines and thus accuracy achieved by PTP is the accuracy of clock in 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 data plane. An option to use a more accurate clock as a source of
time stamps for IP performance measurements is one of this time stamps for IP performance measurements is one of this
specification's advantages. Another advantage is realized by specification's advantages. Another advantage is realized by
skipping to change at page 3, line 43 skipping to change at page 3, line 43
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
2. OWAMP and TWAMP Extensions 2. OWAMP and TWAMP Extensions
OWAMP connection establishment follows the procedure defined in OWAMP connection establishment follows the procedure defined in
Section 3.1 of [RFC4656] and additional steps in TWAMP described 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 Section 3.1 of [RFC5357]. In these procedures, the Modes field has
used to identify and select specific communication capabilities. At been used to identify and select specific communication capabilities.
the same time the Modes field has been recognized and used as At the same time the Modes field has been recognized and used as
extension mechanism [RFC6038]. The new feature requires one bit extension mechanism [RFC6038]. The new feature requires one bit
position for Server and Control-Client to negotiate which timestamp position for Server and Control-Client to negotiate which timestamp
format can be used in some or all test sessions invoked with this format can be used in some or all test sessions invoked with this
control connection. The end-point of the test session, Session- control connection. The end-point of the test session, Session-
Sender and Session-Receiver or Session-Reflector, that supports this Sender and Session-Receiver or Session-Reflector, that supports this
extension MUST be capable to interpret NTP and PTPv2 timestamp extension MUST be capable to interpret NTP and PTPv2 timestamp
formats. If the end-point does not support this extension, then the 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 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 field. If the value of PTPv2 Timestamp flags is 0, then the
advertising node can use and interpret only NTP timestamp format. advertising node can use and interpret only NTP timestamp format.
 End of changes. 5 change blocks. 
9 lines changed or deleted 9 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/