Skip to main content

Support of IEEE-1588 time stamp format in Two-Way Active Measurement Protocol (TWAMP)
draft-mirsky-ippm-time-format-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Greg Mirsky , Ramanathan Lakshmikanthan , Suchit Bansal , Israel Meilik
Last updated 2015-01-16
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-mirsky-ippm-time-format-00
Network Working Group                                          G. Mirsky
Internet-Draft                                         R. Lakshmikanthan
Intended status: Standards Track                               S. Bansal
Expires: July 20, 2015                                          Ericsson
                                                               I. Meilik
                                                                Broadcom
                                                        January 16, 2015

  Support of IEEE-1588 time stamp format in Two-Way Active Measurement
                            Protocol (TWAMP)
                    draft-mirsky-ippm-time-format-00

Abstract

   This document describes an OPTIONAL feature for active performance
   measurement protocols allowing use of time stamp format defined in
   IEEE-1588v2-2008.

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 July 20, 2015.

Copyright Notice

   Copyright (c) 2015 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, et al.            Expires July 20, 2015                 [Page 1]

Internet-Draft       1588 time stamp format in TWAMP        January 2015

   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  . . . . . . . . . . . .   6
       2.3.1.  Consideration for TWAMP Light mode  . . . . . . . . .   6
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

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].

   Precision Time Protocol (PTP) [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.

   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.

Mirsky, et al.            Expires July 20, 2015                 [Page 2]

Internet-Draft       1588 time stamp format in TWAMP        January 2015

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 been
   used to identify and select specific communication capabilities.  At
   the same time the Modes field been recognized and used as extension
   mechanism [RFC6038].  The new feature requires two bit positions 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 NTP
   Timestamp and PTPv2 Timestamp flags MUST be 0 because it is in Must
   Be Zero field.  If value of both NTP and PTPv2 Timestamp flags is 0,
   then the advertising node can use and interpret only NTP timestamp
   format.

   Use of two other flags, NTP Timestamp and PTPv2 Timestamp flags
   discussed in the following sub-sections.  For details on the assigned
   values and bit positions see the Section 3.

Mirsky, et al.            Expires July 20, 2015                 [Page 3]

Internet-Draft       1588 time stamp format in TWAMP        January 2015

2.1.  Timestamp Format Negotiation in Setting Up Connection in OWAMP

   In OWAMP-Test [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:

   o  The Server that establishes test sessions for Session-Receiver
      that supports this extension MUST set NTP Timestamp and PTPv2
      Timestamp flags to 1 in the server greeting message according to
      the requirement listed in Section 2.

   o  If NTP Timestamp and PTPv2 Timestamp flags of the server greeting
      message that the Control-Client receives each has value 0, then
      the Session-Sender MUST use NTP format for timestamp in the test
      session and Control-Client SHOULD set NTP Timestamp and PTPv2
      Timestamp flags 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
      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.

   o  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.

   o  Otherwise, if the Session-Sender can set timestamp in NTP format,
      then the Control-Client MUST set the NTP Timestamp flag in the
      Set-Up-Response message to 1 and 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..

   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.

Mirsky, et al.            Expires July 20, 2015                 [Page 4]

Internet-Draft       1588 time stamp format in TWAMP        January 2015

   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] 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:

   o  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.

   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 values of both NTP Timestamp and PTPv2 Timestamp flags in
      received server greeting message each equals 0, then Session-
      Reflector does not support this extension and will use NTP
      timestamp format.  Control-Client SHOULD set NTP Timestamp and
      PTPv2 Timestamp flags 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  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.

   o  If the values of both NTP Timestamp and PTPv2 Timestamp flags in
      the in the Set-Up-Response message are both equal 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.

Mirsky, et al.            Expires July 20, 2015                 [Page 5]

Internet-Draft       1588 time stamp format in TWAMP        January 2015

2.3.  OWAMP-Test and TWAMP-Test Update

   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 [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:

   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 according to 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 NTP Timestamp and PTPv2 Timestamp
   as follows:

   +--------------+------------------+---------------------+-----------+
   | Value        | Description      | Semantics           | Reference |
   +--------------+------------------+---------------------+-----------+
   | TBA1         | NTP Timestamp    | bit position TBA2   | This      |
   | (proposed    | Capability       | (proposed 8)        | document  |
   | 256)         |                  |                     |           |
   | TBA2         | PTPv2 Timestamp  | bit position TBA4   | This      |
   | (proposed    | Capability       | (proposed 9)        | document  |
   | 512)         |                  |                     |           |
   +--------------+------------------+---------------------+-----------+

                     Table 1: New Timestamp Capability

Mirsky, et al.            Expires July 20, 2015                 [Page 6]

Internet-Draft       1588 time stamp format in TWAMP        January 2015

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].

5.  Acknowledgements

   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, March 1997.

   [RFC4656]  Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
              Zekauskas, "A One-way Active Measurement Protocol
              (OWAMP)", RFC 4656, September 2006.

   [RFC5357]  Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
              Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
              RFC 5357, October 2008.

   [RFC5618]  Morton, A. and K. Hedayat, "Mixed Security Mode for the
              Two-Way Active Measurement Protocol (TWAMP)", RFC 5618,
              August 2009.

   [RFC5905]  Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
              Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, June 2010.

   [RFC6038]  Morton, A. and L. Ciavattone, "Two-Way Active Measurement
              Protocol (TWAMP) Reflect Octets and Symmetrical Size
              Features", RFC 6038, October 2010.

Mirsky, et al.            Expires July 20, 2015                 [Page 7]

Internet-Draft       1588 time stamp format in TWAMP        January 2015

Authors' Addresses

   Greg Mirsky
   Ericsson

   Email: gregory.mirsky@ericsson.com

   Ramanathan Lakshmikanthan
   Ericsson

   Email: ramanathan.lakshmikanthan@ericsson.com

   Suchit Bansal
   Ericsson

   Email: suchit.bansal@ericsson.com

   Israel Meilik
   Broadcom

   Email: israel@broadcom.com

Mirsky, et al.            Expires July 20, 2015                 [Page 8]