draft-ietf-ippm-twamp-time-format-00.txt   draft-ietf-ippm-twamp-time-format-01.txt 
Network Working Group G. Mirsky Network Working Group G. Mirsky
Internet-Draft Ericsson Internet-Draft
Intended status: Standards Track I. Meilik Intended status: Standards Track I. Meilik
Expires: December 19, 2016 Broadcom Expires: May 9, 2017 Broadcom
June 17, 2016 November 8, 2016
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-00 draft-ietf-ippm-twamp-time-format-01
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 time stamp format defined in measurement protocols allowing use of time stamp format defined in
IEEE-1588v2-2008. IEEE-1588v2-2008.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 December 19, 2016. This Internet-Draft will expire on May 6, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 37 skipping to change at page 2, line 37
only the NTP [RFC5905] format of a time stamp can be used in OWAMP- only the NTP [RFC5905] format of a time stamp can be used in OWAMP-
Test protocol. Two-Way Active Measurement Protocol (TWAMP) [RFC5357] Test protocol. Two-Way Active Measurement Protocol (TWAMP) [RFC5357]
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 wiitin 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. And of mentioned solutions will be subject to
additional queuing delays that negatively affect data plane clock 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. Thus providing option to use more accurate clock as data plane. Thus, providing option to use more accurate clock as
source of time stamps for IP performance measurement is one of source of time stamps for IP performance measurement is one of
advantages this proposal helps to achive. Another advantage realized advantages this proposal helps to achieve. Another advantage realized
by simplification of hardware in data plane. To support OWAMP or by simplification of hardware in data plane. To support OWAMP or
TWAMP test protocol time stamps must be converted from PTP to NTP. TWAMP test protocol time stamps must be converted from PTP to NTP.
That requires resources, use of micro-code or additional processing That requires resources, use of micro-code 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 IEEE-1588v2 time stamp format as optional alternative to the
NTP time stamp format. NTP time stamp format.
One of the goals of this proposal is not only allow end-points of a One of the goals of this proposal is not only allow end-points of a
skipping to change at page 3, line 40 skipping to change at page 3, line 40
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 been
used to identify and select specific communication capabilities. At used to identify and select specific communication capabilities. At
the same time the Modes field been recognized and used as extension the same time the Modes field been recognized and used as extension
mechanism [RFC6038]. The new feature requires one bit position for mechanism [RFC6038]. The new feature requires one bit position for
Server and Control-Client to negotiate which timestamp format can be Server and Control-Client to negotiate which timestamp format can be
used in some or all test sessions invoked with this control used in some or all test sessions invoked with this control
connection. The end-point of the test session, Session-Sender and connection. The end-point of the test session, Session-Sender and
Session-Receiver or Session-Reflector, that supports this extension Session-Receiver or Session-Reflector, that supports this extension
MUST be capable to interpret NTP and PTPv2 timestamp formats. If the MUST be capable to interpret NTP and PTPv2 timestamp formats. If the
end-point does not support this extension, then the value of PTPv2 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 Timestamp flag MUST be 0 because it is in Must Be Zero field. If
value of PTPv2 Timestamp flags is 0, then the advertising node can value of PTPv2 Timestamp flags is 0, then the advertising node can
use and interpret only NTP timestamp format. use and interpret only NTP timestamp format.
Use of PTPv2 Timestamp flags discussed in the following sub-sections. Use of PTPv2 Timestamp flags discussed in the following sub-sections.
For details on the assigned values and bit positions see the For details on the assigned values and bit positions see the
Section 3. Section 3.
2.1. Timestamp Format Negotiation in Setting Up Connection in OWAMP 2.1. Timestamp Format Negotiation in Setting Up Connection in OWAMP
In OWAMP-Test [RFC4656] it is the Session-Receiver and/or Fetch- In OWAMP-Test [RFC4656] it is the Session-Receiver and/or Fetch-
Client that are interpreting collected timestamps. Thus announced by Client that are interpreting collected timestamps. Thus, announced by
a Server in the Modes field timestamp format indicates which formats a Server in the Modes field timestamp format indicates which formats
the Session-Receiver is capable to interpret. The Control-Client the Session-Receiver is capable to interpret. The Control-Client
inspects values set by the Server for timestamp formats and sets inspects values set by the Server for timestamp formats and sets
values in the Modes field of the Set-Up-Response message according to values in the Modes field of the Set-Up-Response message per
timestamp formats Session-Sender is capable of using. The rules of timestamp formats Session-Sender can use. The rules of setting
setting timestamp flags in Modes field in server greeting and Set-Up- timestamp flags in Modes field in server greeting and Set-Up-
Response messages and interpreting them are as follows: Response messages and interpreting them are as follows:
o The Server that establishes test sessions for Session-Receiver o The Server that establishes test sessions for Session-Receiver
that supports this extension MUST set PTPv2 Timestamp flag to 1 in that supports this extension MUST set PTPv2 Timestamp flag to 1 in
the server greeting message according to the requirement listed in the server greeting message per the requirement listed in
Section 2. Section 2.
o If PTPv2 Timestamp flag of the server greeting message that the o If PTPv2 Timestamp flag of the server greeting message that the
Control-Client receives has value 0, then the Session-Sender MUST Control-Client receives has value 0, then the Session-Sender MUST
use NTP format for timestamp in the test session and Control- use NTP format for timestamp in the test session and Control-
Client SHOULD set PTPv2 Timestamp flag to 0 in accordance with Client SHOULD set PTPv2 Timestamp flag to 0 in accordance with
[RFC4656]. If the Session-Sender cannot use NTP timestamps, then [RFC4656]. If the Session-Sender cannot use NTP timestamps, then
the Control-Client SHOULD close the TCP connection associated with the Control-Client SHOULD close the TCP connection associated with
the OWAMP-Control session. the OWAMP-Control session.
o If the Session-Sender can set timestamp in PTPv2 format, then the o If the Session-Sender can set timestamp in PTPv2 format, then the
Control-Client MUST set the PTPv2 Timestamp flag to 1in Modes Control-Client MUST set the PTPv2 Timestamp flag to 1in Modes
field in the Set-Up-Response message and the Session-Sender MUST field in the Set-Up-Response message and the Session-Sender MUST
set timestamp in PTPv2 timestamp format. Otherwise the Control- set timestamp in PTPv2 timestamp format. Otherwise the Control-
Client MUST set the PTPv2 Timestamp flag in the Set-Up-Response Client MUST set the PTPv2 Timestamp flag in the Set-Up-Response
message to 0. message to 0.
o Otherwise, if the Session-Sender can set timestamp in NTP format, o Otherwise, if the Session-Sender can set timestamp in NTP format,
then the Session-Sender MUST set timestamp in NTP timestamp then the Session-Sender MUST set timestamp in NTP timestamp
format. Otherwise the Control-Client SHOULD close the TCP format. Otherwise the Control-Client SHOULD close the TCP
connection associated with the OWAMP-Control session.. connection associated with the OWAMP-Control session.
If values of both NTP and PTPv2 Timestamp flags in the Set-Up- If values of both NTP and PTPv2 Timestamp flags in the Set-Up-
Response message are equal to 0, then that indicates that the Response message are equal to 0, then that indicates that the
Control-Client can set timestamp only in NTP format. Control-Client can set timestamp only in 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 or another timestamp format is 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 Setting Up Connection in TWAMP
skipping to change at page 5, line 47 skipping to change at page 5, line 47
2.3. OWAMP-Test and TWAMP-Test Update 2.3. OWAMP-Test and TWAMP-Test Update
Participants of a test session need to indicate which timestamp Participants of a test session need to indicate which timestamp
format being used. The proposal is to use Z field in Error Estimate format being used. The proposal is to use Z field in Error Estimate
defined in Section 4.1.2 of [RFC4656]. The new interpretation of the defined in Section 4.1.2 of [RFC4656]. The new interpretation of the
Error Estimate is in addition to it specifying error estimate and Error Estimate is in addition to it specifying error estimate and
synchronization, Error Estimate indicates format of a collected synchronization, Error Estimate indicates format of a collected
timestamp. And this proposal changes the semantics of the Z bit timestamp. And this proposal changes the semantics of the Z bit
field, the one between S and Scale fields, to be referred as field, the one between S and Scale fields, to be referred as
Timestamp format and value MUST be set according to the following: Timestamp format and value MUST be set per the following:
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 result of this value of the Z field from Error Estimate, Sender
Error Estimate or Send Error Estimate and Receive Error Estimate Error Estimate or Send Error Estimate and Receive Error Estimate
SHOULD NOT be ignored and MUST be used when calculating delay and SHOULD NOT be ignored and MUST be used when calculating delay and
delay variation metrics based on collected timestamps. 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 Session-Sender and Session-
Reflector in TWAMP Light mode are informed of timestamp format to be Reflector in TWAMP Light mode are informed of timestamp format to be
used. It is assumed that, for example, configuration could be used used. It is assumed that, for example, configuration could be used
to direct Session-Sender and Session-Reflector respectively to use to direct Session-Sender and Session-Reflector respectively to use
timestamp format according to 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]. The TWAMP-Modes registry defined in [RFC5618].
IANA is requested to reserve a new PTPv2 Timestamp as follows: IANA is requested to reserve a new PTPv2 Timestamp as follows:
+--------------+------------------+---------------------+-----------+ +--------------+------------------+---------------------+-----------+
| Value | Description | Semantics | Reference | | Value | Description | Semantics | Reference |
skipping to change at page 7, line 45 skipping to change at page 7, line 45
<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>.
Authors' Addresses Authors' Addresses
Greg Mirsky Greg Mirsky
Ericsson
Email: gregory.mirsky@ericsson.com Email: gregimirsky@gmail.com
Israel Meilik Israel Meilik
Broadcom Broadcom
Email: israel@broadcom.com Email: israel@broadcom.com
 End of changes. 16 change blocks. 
19 lines changed or deleted 18 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/