One document matched: draft-mirsky-ippm-time-format-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC4656 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4656.xml">
<!ENTITY RFC5618 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5618.xml">
<!ENTITY RFC5357 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5357.xml">
<!ENTITY RFC5905 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5905.xml">
<!ENTITY RFC6038 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6038.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" ipr="trust200902" docName="draft-mirsky-ippm-time-format-02">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<front>
<title abbrev='1588 time stamp format in TWAMP'>Support of IEEE-1588 time stamp format in Two-Way Active Measurement Protocol (TWAMP)</title>
<author initials='G.' surname="Mirsky" fullname='Greg Mirsky'>
<organization>Ericsson</organization>
<address>
<email>gregory.mirsky@ericsson.com</email>
</address>
</author>
<author initials='S.' surname="Bansal" fullname='Suchit Bansal'>
<organization>Ericsson</organization>
<address>
<email>suchit.bansal@ericsson.com</email>
</address>
</author>
<author initials='R.' surname="Lakshmikanthan" fullname='Ramanathan Lakshmikanthan'>
<organization></organization>
<address>
<email>ramlak@gmail.com</email>
</address>
</author>
<author fullname="Israel Meilik" initials="I" surname="Meilik">
<organization>Broadcom</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<email>israel@broadcom.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date day="4" month="January" year="2016" />
<area>Transport</area>
<workgroup>Network Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>IPPM</keyword>
<keyword>TWAMP </keyword>
<keyword>IEEE-1588</keyword>
<abstract>
<t>
This document describes an OPTIONAL feature for active performance measurement protocols
allowing use of time stamp format defined in IEEE-1588v2-2008.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
One-Way Active Measurement Protocol (OWAMP) <xref target ="RFC4656"/> defines that only the NTP <xref target="RFC5905"/> format
of a time stamp can be used in OWAMP-Test protocol.
Two-Way Active Measurement Protocol (TWAMP) <xref target="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 <xref target="RFC5905"/>.
</t>
<t>
Precision Time Protocol (PTP) <xref target="IEEE.1588.2008"/> has gained wide support since the development of OWAMP and TWAMP.
PTP is now supported in multiple implementations of fast forwarding engines. As result, 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.
</t>
<t>
One of the goals of this proposal is not only allow end-points of a test session to use other than NTP timestamp but to support
backwards compatibility with nodes that do not yet support this extension.
</t>
<section title="Conventions used in this document">
<section title="Terminology">
<t>IPPM: IP Performance Measurement
</t>
<t>NTP: Network Time Protocol</t>
<t>PTP: Precision Time Protocol</t>
<t>TWAMP: Two-Way Active Measurement Protocol
</t>
<t>OWAMP: One-Way Active Measurement Protocol
</t>
</section>
<section title="Requirements Language">
<t>
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
<xref target="RFC2119"></xref>.
</t>
</section>
</section>
</section>
<section anchor="owamp-twamp-extensions" title="OWAMP and TWAMP Extensions">
<t>
OWAMP connection establishment follows the procedure defined in
Section 3.1 of <xref target="RFC4656"/> and additional steps in TWAMP described
in Section 3.1 of <xref target="RFC5357"/>. In these procedures the Modes field
been used to identify and select specific communication capabilities. At the same time
the Modes field been recognized and used as extension mechanism <xref target="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 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 value of
PTPv2 Timestamp flags is 0, then the advertising node can use and interpret only NTP
timestamp format.
</t>
<t>
Use of PTPv2 Timestamp flags discussed in the following sub-sections. For details on the
assigned values and bit positions see
the <xref target="iana-consider"/>.
</t>
<section anchor="owamp-conn-setup" title="Timestamp Format Negotiation in Setting Up Connection in OWAMP">
<t>
In OWAMP-Test <xref target="RFC4656"/> it is the Session-Receiver and/or Fetch-Client that are interpreting collected
timestamps. Thus announced by a Server in the Modes field timestamp format indicates 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 is capable of using. The rules of setting timestamp flags in Modes field in server greeting and
Set-Up-Response messages and interpreting them are as follows:
<list style="symbols">
<t>
The Server that establishes test sessions for Session-Receiver that supports this extension MUST set
PTPv2 Timestamp flag to 1 in the server greeting message according to the requirement
listed in <xref target="owamp-twamp-extensions"/>.
</t>
<t>
If PTPv2 Timestamp flag of the server greeting message that the 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
<xref target="RFC4656"/>. If the Session-Sender cannot use NTP timestamps, then the Control-Client
SHOULD close the TCP connection associated with the OWAMP-Control session.
</t>
<t>
If the Session-Sender can set timestamp in PTPv2 format, then the Control-Client MUST set the PTPv2
Timestamp flag to 1in Modes field in the Set-Up-Response message and the Session-Sender MUST
set timestamp in PTPv2 timestamp format. Otherwise the Control-Client MUST set the PTPv2 Timestamp
flag in the Set-Up-Response message to 0.
</t>
<!--<t>
If the value of the PTPv2 Timestamp flag in the Set-Up-Response message is 1, then the Control-Client
MUST set the NTP Timestamp flag in the Set-Up-Response message to 0.
</t>-->
<t>
Otherwise, if the Session-Sender can set timestamp in NTP format, then the Session-Sender MUST set timestamp
in NTP timestamp format. Otherwise the Control-Client SHOULD close the TCP connection associated with
the OWAMP-Control session..
</t>
</list>
</t>
<t>
If values of both NTP and PTPv2 Timestamp flags in the Set-Up-Response message are equal to 0, then that
indicates that the Control-Client can set timestamp only in NTP format.
</t>
<t>
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.
</t>
</section>
<section anchor="twamp-conn-setup" title="Timestamp Format Negotiation in Setting Up Connection in TWAMP">
<t>
In TWAMP-Test <xref target="RFC5357"/> it is the Session-Sender that is interpreting 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:
<list style="symbols">
<!--<t>
Server MUST set to 1 value of NTP Timestamp flag in the greeting message if Session-Reflector can set timestamp
in NTP format. Otherwise the NTP Timestamp flag MUST be set to 0.
</t>-->
<t>
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.
</t>
<t>
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 <xref target="RFC5357"/>.
</t>
<t>
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.
</t>
<!--<t>
Control-Client MUST set NTP Timestamp flag value to 1 in Modes field in the Set-Up-Response message
if Server advertised ability of the Session-Reflector to use NTP format for timestamps. Otherwise the flag MUST be
set to 0.
</t>-->
<t>
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 for timestamps then Server
and SHOULD close the TCP connection associated with the TWAMP-Control session.
</t>
</list>
</t>
</section>
<section anchor="test-update" title="OWAMP-Test and TWAMP-Test Update">
<t>
Participants of a test session need to indicate which timestamp format being used. The proposal is
to use Z field in Error Estimate defined in Section 4.1.2 of <xref target="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 proposal changes the semantics of the Z bit field, the one between S
and Scale fields, to be referred as Timestamp format and value MUST be set according to the following:
<list style="symbols">
<t>0 - NTP 64 bit format of a timestamp;</t>
<t>1 - PTPv2 truncated format of a timestamp.</t>
</list>
</t>
<t>
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.
</t>
<section anchor="twamp-light-aspect" title="Consideration for TWAMP Light mode">
<t>
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 according to their capabilities
and rules listed in <xref target="twamp-conn-setup"/>.
</t>
</section>
</section>
</section>
<section anchor="iana-consider" title="IANA Considerations">
<t>
The TWAMP-Modes registry defined in <xref target="RFC5618"/>.
</t>
<t>
IANA is requested to reserve a new PTPv2 Timestamp as follows:
</t>
<texttable anchor="timestamp-table" title="New Timestamp Capability">
<ttcol align='left'>Value</ttcol>
<ttcol align='left'>Description</ttcol>
<ttcol align='left'>Semantics</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>TBA1 (proposed 256)</c>
<c>PTPv2 Timestamp Capability </c>
<c>bit position TBA2 (proposed 8)</c>
<c>This document</c>
</texttable>
</section>
<section anchor="security" title="Security Considerations">
<t>
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 <xref target="RFC4656"/>, <xref target="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 <xref target="RFC4656"/> and
<xref target="RFC5357"/>.
</t>
</section>
<section title="Acknowledgements">
<t>
The authors would like to thank David Allan for his thorough review and thoughtful comments.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC4656;
&RFC5618;
&RFC5357;
&RFC5905;
&RFC6038;
<reference anchor="IEEE.1588.2008">
<front>
<title>Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems</title>
<author>
<organization/>
</author>
<date month="March" year="2008"/>
</front>
<seriesInfo name="IEEE" value="Standard 1588"/>
</reference>
</references>
<!--
<references title="Informative References">
&RFC2629;
&RFC5226;
</references>
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:30:18 |