Internet DRAFT - draft-ietf-ippm-twamp-time-format
draft-ietf-ippm-twamp-time-format
Network Working Group G. Mirsky
Internet-Draft ZTE Corp.
Intended status: Standards Track I. Meilik
Expires: October 14, 2017 Broadcom
April 12, 2017
Support of IEEE-1588 time stamp format in Two-Way Active Measurement
Protocol (TWAMP)
draft-ietf-ippm-twamp-time-format-06
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
This Internet-Draft is submitted in full conformance with the
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
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 October 14, 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
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
Mirsky & Meilik Expires October 14, 2017 [Page 1]
Internet-Draft 1588 time stamp format in TWAMP April 2017
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
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 Setting Up Connection in
OWAMP . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Timestamp Format Negotiation in Setting Up Connection in
TWAMP . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. OWAMP-Test and TWAMP-Test Update . . . . . . . . . . . . 5
2.3.1. Consideration for TWAMP Light mode . . . . . . . . . 6
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
6. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
One-Way Active Measurement Protocol (OWAMP) [RFC4656] defines that
only the NTP [RFC5905] format of a time stamp can be used in OWAMP-
Test protocol. 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 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. 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
Mirsky & Meilik Expires October 14, 2017 [Page 2]
Internet-Draft 1588 time stamp format in TWAMP April 2017
specification's advantages. Another advantage is realized by
simplification of hardware in data plane. To support OWAMP or TWAMP
test protocol time stamps must be converted from PTP to NTP. That
requires resources, use of micro-code or additional processing
elements, that are always limited. To address this, this document
proposes optional extensions to Control and Test protocols to support
use of IEEE-1588v2 time stamp format as optional alternative to the
NTP time stamp format.
One of the goals of this specification is not only to allow end-
points of a test session to use timestamp format other than NTP but
to support backwards compatibility with nodes that do not yet support
this extension.
1.1. Conventions used in this document
1.1.1. Terminology
IPPM: IP Performance Measurement
NTP: Network Time Protocol
PTP: Precision Time Protocol
TWAMP: Two-Way Active Measurement Protocol
OWAMP: One-Way Active Measurement Protocol
1.1.2. Requirements Language
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 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
Mirsky & Meilik Expires October 14, 2017 [Page 3]
Internet-Draft 1588 time stamp format in TWAMP April 2017
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.
Implementations of OWAMP and/or TWAMP MAY provide a configuration
knob to bypass the timestamp format negotiation process and to use
the locally configured values instead.
Use of PTPv2 Timestamp flags is discussed in the following sub-
sections. For details on the assigned values and bit positions see
the Section 3.
2.1. Timestamp Format Negotiation in Setting Up Connection in OWAMP
In OWAMP-Test [RFC4656] the Session-Receiver and/or Fetch-Client
interpret collected timestamps. Thus, the Server uses the Modes
field timestamp format to indicate which formats the Session-Receiver
is capable to interpret. The Control-Client inspects values set by
the Server for timestamp formats and sets values in the Modes field
of the Set-Up-Response message according to timestamp formats
Session-Sender can use. The rules of setting timestamp flags in
Modes field in server greeting and Set-Up-Response messages and
interpreting them are as follows:
o If the Session-Receiver supports this extension, then the Server
that establishes test sessions on its behalf MUST set PTPv2
Timestamp flag to 1 in the server greeting message per the
requirement listed in Section 2. Otherwise, the PTPv2 Timestamp
flag will be set to 0 to indicate that the Session-Receiver
interprets only NTP format.
o If the Control-Client receives greeting message with the PTPv2
Timestamp flag set to 0, then the Session-Sender MUST use NTP
format for timestamp in the test session and Control-Client SHOULD
set PTPv2 Timestamp flag to 0 in accordance with [RFC4656]. If
the Session-Sender cannot use NTP timestamps, then the Control-
Client SHOULD close the TCP connection associated with the OWAMP-
Control session.
o If the Control-Client receives greeting message with the PTPv2
Timestamp flag set to 1 and the Session-Sender can set timestamp
in PTPv2 format, then the Control-Client MUST set the PTPv2
Timestamp flag to 1 in Modes field in the Set-Up-Response message
and the Session-Sender MUST use PTPv2 timestamp format.
o If the Session-Sender doesn't support this extension and can set
timestamp only in NTP format, then the PTPv2 Timestamp flag in
Mirsky & Meilik Expires October 14, 2017 [Page 4]
Internet-Draft 1588 time stamp format in TWAMP April 2017
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.
If OWAMP-Control uses Fetch-Session commands, then selection and use
of one or another timestamp format is local decision for both
Session-Sender and Session-Receiver.
2.2. Timestamp Format Negotiation in Setting Up Connection in TWAMP
In TWAMP-Test [RFC5357] the Session-Sender interprets collected
timestamps. Hence, in the Modes field a Server advertises timestamp
formats that the Session-Reflector can use in TWAMP-Test message.
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
sets timestamp flags values to indicate which format will be used by
the Session-Reflector. The rules of setting and interpreting flag
values are as follows:
o Server MUST set to 1 value of PTPv2 Timestamp flag in its greeting
message if Session-Reflector can set timestamp in PTPv2 format.
Otherwise the PTPv2 Timestamp flag MUST be set to 0.
o If value of the PTPv2 Timestamp flag in received server greeting
message equals 0, then Session-Reflector does not support this
extension and will use NTP timestamp format. Control-Client
SHOULD set PTPv2 Timestamp flag to 0 in Set-Up-Response message in
accordance with [RFC5357].
o Control-Client MUST set PTPv2 Timestamp flag value to 1 in Modes
field in the Set-Up-Response message if Server advertised ability
of the Session-Reflector to use 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
message equals 0, then that means that Session-Sender can only
interpret NTP timestamp format. Then the Session-Reflector MUST
use NTP timestamp format. If the Session-Reflector does not
support NTP format then Server and MUST close the TCP connection
associated with the TWAMP-Control session.
2.3. OWAMP-Test and TWAMP-Test Update
Participants of a test session need to indicate which timestamp
format being used. The specification is to use Z field in Error
Estimate defined in Section 4.1.2 of [RFC4656]. The new
interpretation of the Error Estimate is in addition to it specifying
error estimate and synchronization, Error Estimate indicates format
of a collected timestamp. And this specification changes the
Mirsky & Meilik Expires October 14, 2017 [Page 5]
Internet-Draft 1588 time stamp format in TWAMP April 2017
semantics of the Z bit field, the one between S and Scale fields, to
be referred as Timestamp format and value MUST be set per the
following:
o 0 - NTP 64 bit 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
Error Estimate or Send Error Estimate and Receive Error Estimate
SHOULD NOT be ignored and MUST be used when calculating delay and
delay variation metrics based on collected timestamps.
2.3.1. Consideration for TWAMP Light mode
This document does not specify how Session-Sender and Session-
Reflector in TWAMP Light mode are informed of timestamp format to be
used. It is assumed that, for example, configuration could be used
to direct Session-Sender and Session-Reflector respectively to use
timestamp format per their capabilities and rules listed in
Section 2.2.
3. IANA Considerations
The TWAMP-Modes registry defined in [RFC5618].
IANA is requested to reserve a new PTPv2 Timestamp as follows:
+--------------+------------------+---------------------+-----------+
| Value | Description | Semantics | Reference |
+--------------+------------------+---------------------+-----------+
| TBA1 | PTPv2 Timestamp | bit position TBA2 | This |
| (proposed | Capability | (proposed 8) | document |
| 256) | | | |
+--------------+------------------+---------------------+-----------+
Table 1: New Timestamp Capability
4. Security Considerations
Use of particular format of a timestamp in test session does not
appear to introduce any additional security threat to hosts that
communicate with OWAMP and/or TWAMP as defined in [RFC4656],
[RFC5357] respectively. The security considerations that apply to
any active measurement of live networks are relevant here as well.
See the Security Considerations sections in [RFC4656] and [RFC5357].
Mirsky & Meilik Expires October 14, 2017 [Page 6]
Internet-Draft 1588 time stamp format in TWAMP April 2017
5. Acknowledgements
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]
"Standard for a Precision Clock Synchronization Protocol
for Networked Measurement and Control Systems",
IEEE Standard 1588, March 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
<http://www.rfc-editor.org/info/rfc4656>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, DOI 10.17487/RFC5357, October 2008,
<http://www.rfc-editor.org/info/rfc5357>.
[RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the
Two-Way Active Measurement Protocol (TWAMP)", RFC 5618,
DOI 10.17487/RFC5618, August 2009,
<http://www.rfc-editor.org/info/rfc5618>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>.
[RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement
Protocol (TWAMP) Reflect Octets and Symmetrical Size
Features", RFC 6038, DOI 10.17487/RFC6038, October 2010,
<http://www.rfc-editor.org/info/rfc6038>.
Authors' Addresses
Mirsky & Meilik Expires October 14, 2017 [Page 7]
Internet-Draft 1588 time stamp format in TWAMP April 2017
Greg Mirsky
ZTE Corp.
Email: gregimirsky@gmail.com
Israel Meilik
Broadcom
Email: israel@broadcom.com
Mirsky & Meilik Expires October 14, 2017 [Page 8]
