idnits 2.17.1 draft-ietf-ippm-twamp-time-format-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 12, 2017) is 2571 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.1588.2008' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Mirsky 3 Internet-Draft ZTE Corp. 4 Intended status: Standards Track I. Meilik 5 Expires: October 14, 2017 Broadcom 6 April 12, 2017 8 Support of IEEE-1588 time stamp format in Two-Way Active Measurement 9 Protocol (TWAMP) 10 draft-ietf-ippm-twamp-time-format-06 12 Abstract 14 This document describes an OPTIONAL feature for active performance 15 measurement protocols allowing use of the Precision Time Protocol 16 time stamp format defined in IEEE-1588v2-2008, as an alternative to 17 the Network Time Protocol that is currently used. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 14, 2017. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Conventions used in this document . . . . . . . . . . . . 3 55 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 56 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 57 2. OWAMP and TWAMP Extensions . . . . . . . . . . . . . . . . . 3 58 2.1. Timestamp Format Negotiation in Setting Up Connection in 59 OWAMP . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.2. Timestamp Format Negotiation in Setting Up Connection in 61 TWAMP . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.3. OWAMP-Test and TWAMP-Test Update . . . . . . . . . . . . 5 63 2.3.1. Consideration for TWAMP Light mode . . . . . . . . . 6 64 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 67 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 One-Way Active Measurement Protocol (OWAMP) [RFC4656] defines that 73 only the NTP [RFC5905] format of a time stamp can be used in OWAMP- 74 Test protocol. Two-Way Active Measurement Protocol (TWAMP) [RFC5357] 75 adopted the OWAMP-Test packet format and extended it by adding a 76 format for a reflected test packet. Both the sender's and 77 reflector's packets time stamps are expected to follow the 64-bit 78 long NTP format [RFC5905]. NTP, when used over Internet, typically 79 achieves clock accuracy of about 5ms to 100ms. Surveys conducted 80 recently suggest that 90% devices achieve accuracy of better than 100 81 ms and 99% - better than 1 sec. It should be noted that NTP 82 synchronizes clocks on the control plane, not on data plane. 83 Distribution of clock within a node may be supported by independent 84 NTP domain or via interprocess communication in multiprocessor 85 distributed system. Any of the mentioned solutions will be subject 86 to additional queuing delays that negatively affect data plane clock 87 accuracy. 89 Precision Time Protocol (PTP) [IEEE.1588.2008] has gained wide 90 support since the development of OWAMP and TWAMP. PTP, using on-path 91 support and other mechanisms, allows sub-microsecond clock accuracy. 92 PTP is now supported in multiple implementations of fast forwarding 93 engines and thus accuracy achieved by PTP is the accuracy of clock in 94 data plane. An option to use a more accurate clock as a source of 95 time stamps for IP performance measurements is one of this 96 specification's advantages. Another advantage is realized by 97 simplification of hardware in data plane. To support OWAMP or TWAMP 98 test protocol time stamps must be converted from PTP to NTP. That 99 requires resources, use of micro-code or additional processing 100 elements, that are always limited. To address this, this document 101 proposes optional extensions to Control and Test protocols to support 102 use of IEEE-1588v2 time stamp format as optional alternative to the 103 NTP time stamp format. 105 One of the goals of this specification is not only to allow end- 106 points of a test session to use timestamp format other than NTP but 107 to support backwards compatibility with nodes that do not yet support 108 this extension. 110 1.1. Conventions used in this document 112 1.1.1. Terminology 114 IPPM: IP Performance Measurement 116 NTP: Network Time Protocol 118 PTP: Precision Time Protocol 120 TWAMP: Two-Way Active Measurement Protocol 122 OWAMP: One-Way Active Measurement Protocol 124 1.1.2. Requirements Language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in 129 [RFC2119]. 131 2. OWAMP and TWAMP Extensions 133 OWAMP connection establishment follows the procedure defined in 134 Section 3.1 of [RFC4656] and additional steps in TWAMP described in 135 Section 3.1 of [RFC5357]. In these procedures, the Modes field has 136 been used to identify and select specific communication capabilities. 137 At the same time the Modes field has been recognized and used as 138 extension mechanism [RFC6038]. The new feature requires one bit 139 position for Server and Control-Client to negotiate which timestamp 140 format can be used in some or all test sessions invoked with this 141 control connection. The end-point of the test session, Session- 142 Sender and Session-Receiver or Session-Reflector, that supports this 143 extension MUST be capable to interpret NTP and PTPv2 timestamp 144 formats. If the end-point does not support this extension, then the 145 value of PTPv2 Timestamp flag MUST be 0 because it is in Must Be Zero 146 field. If the value of PTPv2 Timestamp flags is 0, then the 147 advertising node can use and interpret only NTP timestamp format. 148 Implementations of OWAMP and/or TWAMP MAY provide a configuration 149 knob to bypass the timestamp format negotiation process and to use 150 the locally configured values instead. 152 Use of PTPv2 Timestamp flags is discussed in the following sub- 153 sections. For details on the assigned values and bit positions see 154 the Section 3. 156 2.1. Timestamp Format Negotiation in Setting Up Connection in OWAMP 158 In OWAMP-Test [RFC4656] the Session-Receiver and/or Fetch-Client 159 interpret collected timestamps. Thus, the Server uses the Modes 160 field timestamp format to indicate which formats the Session-Receiver 161 is capable to interpret. The Control-Client inspects values set by 162 the Server for timestamp formats and sets values in the Modes field 163 of the Set-Up-Response message according to timestamp formats 164 Session-Sender can use. The rules of setting timestamp flags in 165 Modes field in server greeting and Set-Up-Response messages and 166 interpreting them are as follows: 168 o If the Session-Receiver supports this extension, then the Server 169 that establishes test sessions on its behalf MUST set PTPv2 170 Timestamp flag to 1 in the server greeting message per the 171 requirement listed in Section 2. Otherwise, the PTPv2 Timestamp 172 flag will be set to 0 to indicate that the Session-Receiver 173 interprets only NTP format. 175 o If the Control-Client receives greeting message with the PTPv2 176 Timestamp flag set to 0, then the Session-Sender MUST use NTP 177 format for timestamp in the test session and Control-Client SHOULD 178 set PTPv2 Timestamp flag to 0 in accordance with [RFC4656]. If 179 the Session-Sender cannot use NTP timestamps, then the Control- 180 Client SHOULD close the TCP connection associated with the OWAMP- 181 Control session. 183 o If the Control-Client receives greeting message with the PTPv2 184 Timestamp flag set to 1 and the Session-Sender can set timestamp 185 in PTPv2 format, then the Control-Client MUST set the PTPv2 186 Timestamp flag to 1 in Modes field in the Set-Up-Response message 187 and the Session-Sender MUST use PTPv2 timestamp format. 189 o If the Session-Sender doesn't support this extension and can set 190 timestamp only in NTP format, then the PTPv2 Timestamp flag in 191 Modes field in the Set-Up-Response message will be set to 0 as 192 part of Must Be Zero and the Session-Sender use NTP format. 194 If OWAMP-Control uses Fetch-Session commands, then selection and use 195 of one or another timestamp format is local decision for both 196 Session-Sender and Session-Receiver. 198 2.2. Timestamp Format Negotiation in Setting Up Connection in TWAMP 200 In TWAMP-Test [RFC5357] the Session-Sender interprets collected 201 timestamps. Hence, in the Modes field a Server advertises timestamp 202 formats that the Session-Reflector can use in TWAMP-Test message. 203 The choice of the timestamp format to be used by the Session-Sender 204 is a local decision. The Control-Client inspects the Modes field and 205 sets timestamp flags values to indicate which format will be used by 206 the Session-Reflector. The rules of setting and interpreting flag 207 values are as follows: 209 o Server MUST set to 1 value of PTPv2 Timestamp flag in its greeting 210 message if Session-Reflector can set timestamp in PTPv2 format. 211 Otherwise the PTPv2 Timestamp flag MUST be set to 0. 213 o If value of the PTPv2 Timestamp flag in received server greeting 214 message equals 0, then Session-Reflector does not support this 215 extension and will use NTP timestamp format. Control-Client 216 SHOULD set PTPv2 Timestamp flag to 0 in Set-Up-Response message in 217 accordance with [RFC5357]. 219 o Control-Client MUST set PTPv2 Timestamp flag value to 1 in Modes 220 field in the Set-Up-Response message if Server advertised ability 221 of the Session-Reflector to use PTPv2 format for timestamps. 222 Otherwise the flag MUST be set to 0. 224 o If the values of PTPv2 Timestamp flag in the Set-Up-Response 225 message equals 0, then that means that Session-Sender can only 226 interpret NTP timestamp format. Then the Session-Reflector MUST 227 use NTP timestamp format. If the Session-Reflector does not 228 support NTP format then Server and MUST close the TCP connection 229 associated with the TWAMP-Control session. 231 2.3. OWAMP-Test and TWAMP-Test Update 233 Participants of a test session need to indicate which timestamp 234 format being used. The specification is to use Z field in Error 235 Estimate defined in Section 4.1.2 of [RFC4656]. The new 236 interpretation of the Error Estimate is in addition to it specifying 237 error estimate and synchronization, Error Estimate indicates format 238 of a collected timestamp. And this specification changes the 239 semantics of the Z bit field, the one between S and Scale fields, to 240 be referred as Timestamp format and value MUST be set per the 241 following: 243 o 0 - NTP 64 bit format of a timestamp; 245 o 1 - PTPv2 truncated format of a timestamp. 247 As result of this value of the Z field from Error Estimate, Sender 248 Error Estimate or Send Error Estimate and Receive Error Estimate 249 SHOULD NOT be ignored and MUST be used when calculating delay and 250 delay variation metrics based on collected timestamps. 252 2.3.1. Consideration for TWAMP Light mode 254 This document does not specify how Session-Sender and Session- 255 Reflector in TWAMP Light mode are informed of timestamp format to be 256 used. It is assumed that, for example, configuration could be used 257 to direct Session-Sender and Session-Reflector respectively to use 258 timestamp format per their capabilities and rules listed in 259 Section 2.2. 261 3. IANA Considerations 263 The TWAMP-Modes registry defined in [RFC5618]. 265 IANA is requested to reserve a new PTPv2 Timestamp as follows: 267 +--------------+------------------+---------------------+-----------+ 268 | Value | Description | Semantics | Reference | 269 +--------------+------------------+---------------------+-----------+ 270 | TBA1 | PTPv2 Timestamp | bit position TBA2 | This | 271 | (proposed | Capability | (proposed 8) | document | 272 | 256) | | | | 273 +--------------+------------------+---------------------+-----------+ 275 Table 1: New Timestamp Capability 277 4. Security Considerations 279 Use of particular format of a timestamp in test session does not 280 appear to introduce any additional security threat to hosts that 281 communicate with OWAMP and/or TWAMP as defined in [RFC4656], 282 [RFC5357] respectively. The security considerations that apply to 283 any active measurement of live networks are relevant here as well. 284 See the Security Considerations sections in [RFC4656] and [RFC5357]. 286 5. Acknowledgements 288 The authors would like to thank Lakshmikanthan and Suchit Bansal for 289 their insightful suggestions. The authors would like to thank David 290 Allan for his thorough review and thoughtful comments. 292 6. Normative References 294 [IEEE.1588.2008] 295 "Standard for a Precision Clock Synchronization Protocol 296 for Networked Measurement and Control Systems", 297 IEEE Standard 1588, March 2008. 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, 301 DOI 10.17487/RFC2119, March 1997, 302 . 304 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 305 Zekauskas, "A One-way Active Measurement Protocol 306 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 307 . 309 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 310 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 311 RFC 5357, DOI 10.17487/RFC5357, October 2008, 312 . 314 [RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the 315 Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, 316 DOI 10.17487/RFC5618, August 2009, 317 . 319 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 320 "Network Time Protocol Version 4: Protocol and Algorithms 321 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 322 . 324 [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement 325 Protocol (TWAMP) Reflect Octets and Symmetrical Size 326 Features", RFC 6038, DOI 10.17487/RFC6038, October 2010, 327 . 329 Authors' Addresses 330 Greg Mirsky 331 ZTE Corp. 333 Email: gregimirsky@gmail.com 335 Israel Meilik 336 Broadcom 338 Email: israel@broadcom.com