draft-ietf-ippm-twamp-time-format-03.txt   draft-ietf-ippm-twamp-time-format-04.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 3, 2017 Broadcom Expires: September 4, 2017 Broadcom
March 2, 2017 March 3, 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-03 draft-ietf-ippm-twamp-time-format-04
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 3, 2017. This Internet-Draft will expire on September 4, 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 51 skipping to change at page 2, line 51
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. 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 proposal?s time stamps for IP performance measurements is one of this
advantages. Another advantage is realized by simplification of specification's advantages. Another advantage is realized by
hardware in data plane. To support OWAMP or TWAMP test protocol time simplification of hardware in data plane. To support OWAMP or TWAMP
stamps must be converted from PTP to NTP. That requires resources, test protocol time stamps must be converted from PTP to NTP. That
use of micro-code or additional processing elements, that are always requires resources, use of micro-code or additional processing
limited. To address this, this document proposes optional extensions elements, that are always limited. To address this, this document
to Control and Test protocols to support use of IEEE-1588v2 time proposes optional extensions to Control and Test protocols to support
stamp format as optional alternative to the NTP time stamp format. use of IEEE-1588v2 time stamp format as optional alternative to the
NTP time stamp format.
One of the goals of this proposal is not only to allow end-points of One of the goals of this specification is not only to allow end-
a test session to use timestamp format other than NTP but to support points of a test session to use timestamp format other than NTP but
backwards compatibility with nodes that do not yet support this to support backwards compatibility with nodes that do not yet support
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 IPPM: IP Performance Measurement
NTP: Network Time Protocol NTP: Network Time Protocol
PTP: Precision Time Protocol PTP: Precision Time Protocol
skipping to change at page 4, line 24 skipping to change at page 4, line 25
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 to interpret. The Control-Client inspects values set by
the Server for timestamp formats and sets values in the Modes field the Server for timestamp formats and sets values in the Modes field
of the Set-Up-Response message according to timestamp formats of the Set-Up-Response message according to timestamp formats
Session-Sender can use. The rules of setting timestamp flags in Session-Sender can use. The rules of setting timestamp flags in
Modes field in server greeting and Set-Up-Response messages and Modes field in server greeting and Set-Up-Response messages and
interpreting them are as follows: interpreting them are as follows:
o The Server that establishes test sessions for Session-Receiver o If the Session-Receiver supports this extension, then the Server
that supports this extension MUST set PTPv2 Timestamp flag to 1 in that establishes test sessions on its behalf MUST set PTPv2
the server greeting message per the requirement listed in Timestamp flag to 1 in the server greeting message per the
Section 2. requirement listed in Section 2. Otherwise, the PTPv2 Timestamp
flag will be set to 0 to indicate that the Session-Receiver
o If PTPv2 Timestamp flag of the server greeting message that the interprets only NTP format.
Control-Client receives has value 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 Session-Sender can set timestamp in PTPv2 format, then the o If the Control-Client receives greeting message with the PTPv2
Control-Client MUST set the PTPv2 Timestamp flag to 1 in Modes Timestamp flag set to 0, then the Session-Sender MUST use NTP
field in the Set-Up-Response message and the Session-Sender MUST format for timestamp in the test session and Control-Client SHOULD
set timestamp in PTPv2 timestamp format. Otherwise the Control- set PTPv2 Timestamp flag to 0 in accordance with [RFC4656]. If
Client MUST set the PTPv2 Timestamp flag in the Set-Up-Response the Session-Sender cannot use NTP timestamps, then the Control-
message to 0. Client SHOULD close the TCP connection associated with the OWAMP-
Control session.
o Otherwise, if the Session-Sender can set timestamp in NTP format, o If the Control-Client receives greeting message with the PTPv2
then the Session-Sender MUST set timestamp in NTP timestamp Timestamp flag set to 1 and the Session-Sender can set timestamp
format. Otherwise the Control-Client MUST close the TCP in PTPv2 format, then the Control-Client MUST set the PTPv2
connection associated with the OWAMP-Control session. Timestamp flag to 1 in Modes field in the Set-Up-Response message
and the Session-Sender MUST use PTPv2 timestamp format.
If values of both NTP and PTPv2 Timestamp flags in the Set-Up- o If the Session-Sender doesn't support this extension and can set
Response message are equal to 0, then that indicates that the timestamp only in NTP format, then the PTPv2 Timestamp flag in
Control-Client can set timestamp only in NTP format. 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 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
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 TWAMP-Test message.
skipping to change at page 5, line 45 skipping to change at page 5, line 45
o If the values of PTPv2 Timestamp flag in the Set-Up-Response o If the values of PTPv2 Timestamp flag in the Set-Up-Response
message equals 0, then that means that Session-Sender can only message equals 0, then that means that Session-Sender can only
interpret NTP timestamp format. Then the Session-Reflector MUST interpret NTP timestamp format. Then the Session-Reflector MUST
use NTP timestamp format. If the Session-Reflector does not use NTP timestamp format. If the Session-Reflector does not
support NTP format then Server and MUST close the TCP connection support NTP format then Server and MUST close the TCP connection
associated with the TWAMP-Control session. associated with the TWAMP-Control session.
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 specification is to use Z field in Error
defined in Section 4.1.2 of [RFC4656]. The new interpretation of the Estimate defined in Section 4.1.2 of [RFC4656]. The new
Error Estimate is in addition to it specifying error estimate and interpretation of the Error Estimate is in addition to it specifying
synchronization, Error Estimate indicates format of a collected error estimate and synchronization, Error Estimate indicates format
timestamp. And this proposal changes the semantics of the Z bit of a collected timestamp. And this specification changes the
field, the one between S and Scale fields, to be referred as semantics of the Z bit field, the one between S and Scale fields, to
Timestamp format and value MUST be set per the following: be referred as 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.
 End of changes. 10 change blocks. 
48 lines changed or deleted 47 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/