draft-ietf-ippm-twamp-time-format-06.txt   rfc8186.txt 
Network Working Group G. Mirsky Internet Engineering Task Force (IETF) G. Mirsky
Internet-Draft ZTE Corp. Request for Comments: 8186 ZTE Corp.
Intended status: Standards Track I. Meilik Category: Standards Track I. Meilik
Expires: October 14, 2017 Broadcom ISSN: 2070-1721 Broadcom
April 12, 2017 June 2017
Support of IEEE-1588 time stamp format in Two-Way Active Measurement Support of the IEEE 1588 Timestamp Format in a
Protocol (TWAMP) Two-Way Active Measurement Protocol (TWAMP)
draft-ietf-ippm-twamp-time-format-06
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 that allows use of the Precision Time Protocol
time stamp format defined in IEEE-1588v2-2008, as an alternative to timestamp format defined in IEEE 1588v2, as an alternative to the
the Network Time Protocol that is currently used. Network Time Protocol that is currently used.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on October 14, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8186.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions used in this document . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3
1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3
1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3
2. OWAMP and TWAMP Extensions . . . . . . . . . . . . . . . . . 3 2. OWAMP and TWAMP Extensions . . . . . . . . . . . . . . . . . 3
2.1. Timestamp Format Negotiation in Setting Up Connection in 2.1. Timestamp Format Negotiation in OWAMP Connection Setup . 4
OWAMP . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Timestamp Format Negotiation in TWAMP Connection Setup . 5
2.2. Timestamp Format Negotiation in Setting Up Connection in 2.3. OWAMP-Test and TWAMP-Test Updates . . . . . . . . . . . . 5
TWAMP . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3.1. Consideration for TWAMP Light Mode . . . . . . . . . 6
2.3. OWAMP-Test and TWAMP-Test Update . . . . . . . . . . . . 5
2.3.1. Consideration for TWAMP Light mode . . . . . . . . . 6
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 5. Normative References . . . . . . . . . . . . . . . . . . . . 7
6. Normative References . . . . . . . . . . . . . . . . . . . . 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
One-Way Active Measurement Protocol (OWAMP) [RFC4656] defines that The One-Way Active Measurement Protocol (OWAMP) [RFC4656] defines
only the NTP [RFC5905] format of a time stamp can be used in OWAMP- that only the NTP format [RFC5905] of a timestamp can be used in the
Test protocol. Two-Way Active Measurement Protocol (TWAMP) [RFC5357] OWAMP-Test protocol. The Two-Way Active Measurement Protocol (TWAMP)
adopted the OWAMP-Test packet format and extended it by adding a [RFC5357] adopted the OWAMP-Test packet format and extended it by
format for a reflected test packet. Both the sender's and 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 reflector's packets timestamps are expected to follow the 64-bit-long
long NTP format [RFC5905]. NTP, when used over Internet, typically NTP format [RFC5905]. NTP, when used over the Internet, typically
achieves clock accuracy of about 5ms to 100ms. Surveys conducted achieves clock accuracy within 5 ms to 100 ms. Surveys conducted
recently suggest that 90% devices achieve accuracy of better than 100 recently suggest that 90% of devices achieve accuracy better than 100
ms and 99% - better than 1 sec. It should be noted that NTP ms and 99% of devices achieve accuracy better than 1 sec. It should
synchronizes clocks on the control plane, not on data plane. be noted that NTP synchronizes clocks on the control plane, not on
Distribution of clock within a node may be supported by independent data plane. Distribution of clock within a node may be supported by
NTP domain or via interprocess communication in multiprocessor an independent NTP domain or via interprocess communication in a
distributed system. Any of the mentioned solutions will be subject multiprocessor distributed system. Any of the mentioned solutions
to additional queuing delays that negatively affect data plane clock will be subject to additional queuing delays that negatively affect
accuracy. data-plane clock accuracy.
Precision Time Protocol (PTP) [IEEE.1588.2008] has gained wide The Precision Time Protocol (PTP) [IEEE.1588] has gained wide support
support since the development of OWAMP and TWAMP. PTP, using on-path since the development of OWAMP and TWAMP. PTP, using on-path support
support and other mechanisms, allows sub-microsecond clock accuracy. and other mechanisms, allows sub-microsecond clock accuracy. PTP is
PTP is now supported in multiple implementations of fast forwarding now supported in multiple implementations of fast-forwarding engines;
engines and thus accuracy achieved by PTP is the accuracy of clock in thus, accuracy achieved by PTP is the accuracy of the clock in the
data plane. An option to use a more accurate clock as a source of data plane. Having an option to use a more accurate clock as a
time stamps for IP performance measurements is one of this source of timestamps for IP performance measurements is one of the
specification's advantages. Another advantage is realized by advantages of this specification. Another advantage is realized by
simplification of hardware in data plane. To support OWAMP or TWAMP simplification of hardware in the data plane. To support OWAMP or
test protocol time stamps must be converted from PTP to NTP. That TWAMP, test protocol timestamps must be converted from PTP to NTP.
requires resources, use of micro-code or additional processing That requires resources, use of microcode or additional processing
elements, that are always limited. To address this, this document elements, that are always limited. To address this, this document
proposes optional extensions to Control and Test protocols to support proposes optional extensions to Control and Test protocols to support
use of IEEE-1588v2 time stamp format as optional alternative to the use of the IEEE 1588v2 timestamp format as an optional alternative to
NTP time stamp format. the NTP timestamp format.
One of the goals of this specification is not only to allow end- One of the goals of this specification is not only to allow endpoints
points of a test session to use timestamp format other than NTP but of a test session to use a timestamp format other than NTP, but to
to support backwards compatibility with nodes that do not yet support support backwards compatibility with nodes that do not yet support
this extension. this extension.
1.1. Conventions used in this document 1.1. Conventions Used in This Document
1.1.1. Terminology 1.1.1. Terminology
IPPM: IP Performance Measurement
NTP: Network Time Protocol NTP: Network Time Protocol
PTP: Precision Time Protocol PTP: Precision Time Protocol
TWAMP: Two-Way Active Measurement Protocol TWAMP: Two-Way Active Measurement Protocol
OWAMP: One-Way Active Measurement Protocol OWAMP: One-Way Active Measurement Protocol
1.1.2. Requirements Language 1.1.2. Requirements Language
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]. BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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 has Section 3.1 of [RFC5357]. In these procedures, the Modes field has
been used to identify and select specific communication capabilities. been used to identify and select specific communication capabilities.
At 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 an
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 the Server and Control-Client to negotiate which
format can be used in some or all test sessions invoked with this timestamp format can be used in some or all test sessions invoked
control connection. The end-point of the test session, Session- with this control connection. The endpoint of the test session,
Sender and Session-Receiver or Session-Reflector, that supports this Session-Sender and Session-Receiver (for OWAMP) or Session-Reflector
extension MUST be capable to interpret NTP and PTPv2 timestamp (for TWAMP), that supports this extension MUST be capable of
formats. If the end-point does not support this extension, then the interpreting the NTP and PTPv2 timestamp formats. If the endpoint
value of PTPv2 Timestamp flag MUST be 0 because it is in Must Be Zero does not support this extension, then the value of the PTPv2
field. If the value of PTPv2 Timestamp flags is 0, then the Timestamp flag MUST be 0 because it is in Must Be Zero field. If the
advertising node can use and interpret only NTP timestamp format. value of the PTPv2 Timestamp flag is 0, then the advertising node can
Implementations of OWAMP and/or TWAMP MAY provide a configuration use and interpret only the NTP timestamp format. Implementations of
knob to bypass the timestamp format negotiation process and to use OWAMP and/or TWAMP MAY provide a configuration knob to bypass the
the locally configured values instead. timestamp format negotiation process and use the locally configured
values instead.
Use of PTPv2 Timestamp flags is discussed in the following sub- Use of PTPv2 Timestamp flags is discussed in the following
sections. For details on the assigned values and bit positions see subsections. For details on the assigned values and bit positions,
the Section 3. see the Section 3.
2.1. Timestamp Format Negotiation in Setting Up Connection in OWAMP 2.1. Timestamp Format Negotiation in OWAMP Connection Setup
In OWAMP-Test [RFC4656] the Session-Receiver and/or Fetch-Client In OWAMP-Test [RFC4656], the Session-Receiver and/or Fetch-Client
interpret collected timestamps. Thus, the Server uses the Modes interpret collected timestamps. Thus, the Server uses the Modes
field timestamp format to indicate which formats the Session-Receiver field timestamp format to indicate which formats the Session-Receiver
is capable to interpret. The Control-Client inspects values set by is capable of interpreting. The Control-Client inspects values set
the Server for timestamp formats and sets values in the Modes field by the Server for timestamp formats and sets values in the Modes
of the Set-Up-Response message according to timestamp formats field of the Set-Up-Response message according to the timestamp
Session-Sender can use. The rules of setting timestamp flags in formats the Session-Sender can use. The rules for setting timestamp
Modes field in server greeting and Set-Up-Response messages and flags in the Modes field in Server Greeting and Set-Up-Response
interpreting them are as follows: messages and interpreting them are as follows:
o If the Session-Receiver supports this extension, then the Server o If the Session-Receiver supports this extension, then the Server
that establishes test sessions on its behalf MUST set PTPv2 that establishes test sessions on its behalf MUST set the PTPv2
Timestamp flag to 1 in the server greeting message per the Timestamp flag to 1 in the Server Greeting message per the
requirement listed in Section 2. Otherwise, the PTPv2 Timestamp requirement listed in Section 2. Otherwise, the PTPv2 Timestamp
flag will be set to 0 to indicate that the Session-Receiver flag will be set to 0 to indicate that the Session-Receiver
interprets only NTP format. interprets only the NTP format.
o If the Control-Client receives greeting message with the PTPv2 o If the Control-Client receives a greeting message with the PTPv2
Timestamp flag set to 0, then the Session-Sender MUST use NTP Timestamp flag set to 0, then the Session-Sender MUST use the NTP
format for timestamp in the test session and Control-Client SHOULD format for the timestamp in the test session, and the Control-
set PTPv2 Timestamp flag to 0 in accordance with [RFC4656]. If Client SHOULD set the PTPv2 Timestamp flag to 0 in accordance with
the Session-Sender cannot use NTP timestamps, then the Control- [RFC4656]. If the Session-Sender cannot use NTP timestamps, then
Client SHOULD close the TCP connection associated with the OWAMP- the Control-Client SHOULD close the TCP connection associated with
Control session. the OWAMP-Control session.
o If the Control-Client receives greeting message with the PTPv2 o If the Control-Client receives a greeting message with the PTPv2
Timestamp flag set to 1 and the Session-Sender can set timestamp Timestamp flag set to 1 and the Session-Sender can set the
in PTPv2 format, then the Control-Client MUST set the PTPv2 timestamp in PTPv2 format, then the Control-Client MUST set the
Timestamp flag to 1 in Modes field in the Set-Up-Response message PTPv2 Timestamp flag to 1 in the Modes field in the Set-Up-
and the Session-Sender MUST use PTPv2 timestamp format. Response message and the Session-Sender MUST use PTPv2 timestamp
format.
o If the Session-Sender doesn't support this extension and can set o If the Session-Sender doesn't support this extension and can set
timestamp only in NTP format, then the PTPv2 Timestamp flag in the timestamp in NTP format only, then the PTPv2 Timestamp flag in
Modes field in the Set-Up-Response message will be set to 0 as the 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. part of the Must Be Zero field and the Session-Sender will use the
NTP format.
If OWAMP-Control uses Fetch-Session commands, then selection and use If OWAMP-Control uses Fetch-Session commands, then selection and use
of one or another timestamp format is local decision for both of one timestamp format or another is a local decision for both
Session-Sender and Session-Receiver. Session-Sender and Session-Receiver.
2.2. Timestamp Format Negotiation in Setting Up Connection in TWAMP 2.2. Timestamp Format Negotiation in TWAMP Connection Setup
In TWAMP-Test [RFC5357] the Session-Sender interprets collected In TWAMP-Test [RFC5357], the Session-Sender interprets collected
timestamps. Hence, in the Modes field a Server advertises timestamp timestamps. Hence, in the Modes field, a Server advertises timestamp
formats that the Session-Reflector can use in TWAMP-Test message. formats that the Session-Reflector can use in the TWAMP-Test message.
The choice of the timestamp format to be used by the Session-Sender 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 is a local decision. The Control-Client inspects the Modes field and
sets timestamp flags values to indicate which format will be used by sets timestamp flag values to indicate the format that will be used
the Session-Reflector. The rules of setting and interpreting flag by the Session-Reflector. The rules of setting and interpreting flag
values are as follows: values are as follows:
o Server MUST set to 1 value of PTPv2 Timestamp flag in its greeting o The Server MUST set the PTPv2 Timestamp flag value to 1 in its
message if Session-Reflector can set timestamp in PTPv2 format. greeting message if the Session-Reflector can set the timestamp in
Otherwise the PTPv2 Timestamp flag MUST be set to 0. the PTPv2 format. Otherwise, the PTPv2 Timestamp flag MUST be set
to 0.
o If value of the PTPv2 Timestamp flag in received server greeting o If the value of the PTPv2 Timestamp flag in the received Server
message equals 0, then Session-Reflector does not support this Greeting message is 0, then the Session-Reflector does not support
extension and will use NTP timestamp format. Control-Client this extension and will use the NTP timestamp format. The
SHOULD set PTPv2 Timestamp flag to 0 in Set-Up-Response message in Control-Client SHOULD set the PTPv2 Timestamp flag to 0 in the
accordance with [RFC5357]. Set-Up-Response message in accordance with [RFC4656].
o Control-Client MUST set PTPv2 Timestamp flag value to 1 in Modes o The Control-Client MUST set the PTPv2 Timestamp flag value to 1 in
field in the Set-Up-Response message if Server advertised ability the Modes field in the Set-Up-Response message if the Server
of the Session-Reflector to use PTPv2 format for timestamps. advertised that the Session-Reflector has the ability to use the
Otherwise the flag MUST be set to 0. 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 o If the value of the PTPv2 Timestamp flag in the Set-Up-Response
message equals 0, then that means that Session-Sender can only message is 0, then that means that the Session-Sender can only
interpret NTP timestamp format. Then the Session-Reflector MUST interpret the NTP timestamp format. Therefore, the Session-
use NTP timestamp format. If the Session-Reflector does not Reflector MUST use the NTP timestamp format. If the Session-
support NTP format then Server and MUST close the TCP connection Reflector does not support the NTP format, then the Server MUST
associated with the TWAMP-Control session. close the TCP connection associated with the TWAMP-Control
session.
2.3. OWAMP-Test and TWAMP-Test Update 2.3. OWAMP-Test and TWAMP-Test Updates
Participants of a test session need to indicate which timestamp Participants of a test session need to indicate which timestamp
format being used. The specification is to use Z field in Error format is being used. Currently, the Z field in the Error Estimate
Estimate defined in Section 4.1.2 of [RFC4656]. The new defined in Section 4.1.2 of [RFC4656] is used for this purpose.
interpretation of the Error Estimate is in addition to it specifying However, this document extends the Error Estimate to indicate the
error estimate and synchronization, Error Estimate indicates format format of a collected timestamp, in addition to the estimate of error
of a collected timestamp. And this specification changes the and synchronization. This specification also changes the semantics
semantics of the Z bit field, the one between S and Scale fields, to of the Z bit field (the field between S and Scale fields) to be
be referred as Timestamp format and value MUST be set per the referred to as the Timestamp format; the value MUST be set as
following: follows:
o 0 - NTP 64 bit format of a timestamp; o 0 - NTP 64-bit format of a timestamp.
o 1 - PTPv2 truncated 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 As a result of this value of the Z field from the Error Estimate, the
Error Estimate or Send Error Estimate and Receive Error Estimate Sender Error Estimate (in TWAMP) or Send Error Estimate (in OWAMP)
SHOULD NOT be ignored and MUST be used when calculating delay and and Receive Error Estimate SHOULD NOT be ignored and MUST be used
delay variation metrics based on collected timestamps. when calculating delay and delay-variation metrics based on collected
timestamps.
2.3.1. Consideration for TWAMP Light mode 2.3.1. Consideration for TWAMP Light Mode
This document does not specify how Session-Sender and Session- This document does not specify how the Session-Sender and Session-
Reflector in TWAMP Light mode are informed of timestamp format to be Reflector in TWAMP Light mode are informed of the timestamp format to
used. It is assumed that, for example, configuration could be used be used. It is assumed that, for example, configuration could be
to direct Session-Sender and Session-Reflector respectively to use used to direct the Session-Sender and Session-Reflector to use the
timestamp format per their capabilities and rules listed in timestamp format per their capabilities and rules listed in
Section 2.2. Section 2.2.
3. IANA Considerations 3. IANA Considerations
The TWAMP-Modes registry defined in [RFC5618]. IANA has registered a new PTPv2 Timestamp in the "TWAMP-Modes"
registry [RFC5618] as follows:
IANA is requested to reserve a new PTPv2 Timestamp as follows:
+--------------+------------------+---------------------+-----------+ +------+-----------------------------+-----------+------------------+
| Value | Description | Semantics | Reference | | Bit | Description | Semantics | Reference |
+--------------+------------------+---------------------+-----------+ | Pos | | | |
| TBA1 | PTPv2 Timestamp | bit position TBA2 | This | +------+-----------------------------+-----------+------------------+
| (proposed | Capability | (proposed 8) | document | | 9 | PTPv2 Timestamp Capability | Section 2 | RFC 8186 (this |
| 256) | | | | | | | | document) |
+--------------+------------------+---------------------+-----------+ +------+-----------------------------+-----------+------------------+
Table 1: New Timestamp Capability Table 1: New Timestamp Capability
4. Security Considerations 4. Security Considerations
Use of particular format of a timestamp in test session does not Use of a particular timestamp format in a test session does not
appear to introduce any additional security threat to hosts that appear to introduce any additional security threat to hosts that
communicate with OWAMP and/or TWAMP as defined in [RFC4656], communicate with OWAMP and/or TWAMP as defined in [RFC4656] and
[RFC5357] respectively. The security considerations that apply to [RFC5357], respectively. The security considerations that apply to
any active measurement of live networks are relevant here as well. any active measurement of live networks are relevant here as well.
See the Security Considerations sections in [RFC4656] and [RFC5357]. See the Security Considerations sections in [RFC4656] and [RFC5357].
5. Acknowledgements 5. Normative References
The authors would like to thank Lakshmikanthan and Suchit Bansal for
their insightful suggestions. The authors would like to thank David
Allan for his thorough review and thoughtful comments.
6. Normative References
[IEEE.1588.2008] [IEEE.1588]
"Standard for a Precision Clock Synchronization Protocol IEEE, "IEEE Standard for a Precision Clock Synchronization
for Networked Measurement and Control Systems", Protocol for Networked Measurement and Control Systems",
IEEE Standard 1588, March 2008. IEEE Std 1588-2008, DOI 10.1109/IEEESTD.2008.4579760.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
<http://www.rfc-editor.org/info/rfc4656>. <http://www.rfc-editor.org/info/rfc4656>.
skipping to change at page 7, line 48 skipping to change at page 7, line 42
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>. <http://www.rfc-editor.org/info/rfc5905>.
[RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement
Protocol (TWAMP) Reflect Octets and Symmetrical Size Protocol (TWAMP) Reflect Octets and Symmetrical Size
Features", RFC 6038, DOI 10.17487/RFC6038, October 2010, Features", RFC 6038, DOI 10.17487/RFC6038, October 2010,
<http://www.rfc-editor.org/info/rfc6038>. <http://www.rfc-editor.org/info/rfc6038>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <http://www.rfc-editor.org/info/rfc8174>.
Acknowledgements
The authors would like to thank Ramanathan Lakshmikanthan and Suchit
Bansal for their insightful suggestions. The authors would also like
to thank David Allan for his thorough review and thoughtful comments.
Authors' Addresses Authors' Addresses
Greg Mirsky Greg Mirsky
ZTE Corp. ZTE Corp.
Email: gregimirsky@gmail.com Email: gregimirsky@gmail.com
Israel Meilik Israel Meilik
Broadcom Broadcom
Email: israel@broadcom.com Email: israel@broadcom.com
 End of changes. 50 change blocks. 
180 lines changed or deleted 184 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/