Support of the IEEE 1588 Timestamp Format in a Two-Way Active Measurement Protocol (TWAMP)
RFC 8186
|
| Document |
Type |
|
RFC - Proposed Standard
(June 2017; No errata)
|
|
Last updated |
|
2017-06-08
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
|
Reviews |
|
OPSDIR,
SECDIR,
GENART
will not review this version
|
| Stream |
WG state
|
|
Submitted to IESG for Publication
|
|
Document shepherd |
|
Bill Cerveny
|
|
Shepherd write-up |
|
Show
(last changed 2017-02-02)
|
| IESG |
IESG state |
|
RFC 8186 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Yes
|
|
Telechat date |
|
|
|
Responsible AD |
|
Spencer Dawkins
|
|
Send notices to |
|
"Bill Cerveny" <ietf@wjcerveny.com>
|
| IANA |
IANA review state |
|
IANA OK - Actions Needed
|
|
IANA action state |
|
RFC-Ed-Ack
|
Internet Engineering Task Force (IETF) G. Mirsky
Request for Comments: 8186 ZTE Corp.
Category: Standards Track I. Meilik
ISSN: 2070-1721 Broadcom
June 2017
Support of the IEEE 1588 Timestamp Format in a
Two-Way Active Measurement Protocol (TWAMP)
Abstract
This document describes an OPTIONAL feature for active performance
measurement protocols that allows use of the Precision Time Protocol
timestamp format defined in IEEE 1588v2, as an alternative to the
Network Time Protocol that is currently used.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
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 (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
described in the Simplified BSD License.
Mirsky & Meilik Standards Track [Page 1]
RFC 8186 1588 Timestamp Format in TWAMP June 2017
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3
1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3
2. OWAMP and TWAMP Extensions . . . . . . . . . . . . . . . . . 3
2.1. Timestamp Format Negotiation in OWAMP Connection Setup . 4
2.2. Timestamp Format Negotiation in TWAMP Connection Setup . 5
2.3. OWAMP-Test and TWAMP-Test Updates . . . . . . . . . . . . 5
2.3.1. Consideration for TWAMP Light Mode . . . . . . . . . 6
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. Normative References . . . . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
The One-Way Active Measurement Protocol (OWAMP) [RFC4656] defines
that only the NTP format [RFC5905] of a timestamp can be used in the
OWAMP-Test protocol. The Two-Way Active Measurement Protocol (TWAMP)
[RFC5357] 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 timestamps are expected to follow the 64-bit-long
NTP format [RFC5905]. NTP, when used over the Internet, typically
achieves clock accuracy within 5 ms to 100 ms. Surveys conducted
recently suggest that 90% of devices achieve accuracy better than 100
ms and 99% of devices achieve accuracy 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
an independent NTP domain or via interprocess communication in a
multiprocessor distributed system. Any of the mentioned solutions
will be subject to additional queuing delays that negatively affect
data-plane clock accuracy.
The Precision Time Protocol (PTP) [IEEE.1588] 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;
thus, accuracy achieved by PTP is the accuracy of the clock in the
data plane. Having an option to use a more accurate clock as a
source of timestamps for IP performance measurements is one of the
Show full document text