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/ |